State-updating mechanism in RSVP-TE for MPLS network
draft-gao-mpls-teas-rsvpte-state-update-02
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Jun Gao , Jinyou Dai | ||
| Last updated | 2021-05-02 (Latest revision 2020-10-29) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| 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
RSVP-TE has the following advantages: source routing capability, and the ability to reserve resources hop by hop along the LSP path. RSVP takes a "soft state" approach to managing the reservation state in routers and hosts. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling. This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages. These extension present no backwards compatibility issues.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)