Path Condition Change Marking using BFD
draft-dunbar-bfd-path-condition-change-marking-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Linda Dunbar | ||
| Last updated | 2010-01-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
There are times that an LSP source node needs to know change(s) has occurred along the originally established LSP path. This is especially true in the Mobile Backhaul environment where microwave transport is widely deployed. The bandwidth provided by the microwave transport can change with weather. The source LSR, e.g. LTE's eNodeB, needs to adjust its admission rate or shift more load to alternative paths when the backhaul transport path condition is changed. This draft describes a simple mechanism for transit LSRs to notify Source LSR of the path condition changes. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 0.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)