State-updating mechanism in RSVP-TE for MPLS network
draft-gao-mpls-teas-rsvpte-state-update-02
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jun Gao , Jinyou Dai | ||
| Last updated | 2021-05-02 (Latest revision 2020-10-29) | ||
| Stream | (None) | ||
| Formats |
Expired & archived
plain text
htmlized
pdfized
bibtex
|
||
| 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) |
https://www.ietf.org/archive/id/draft-gao-mpls-teas-rsvpte-state-update-02.txt
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.)