State-updating mechanism in RSVP-TE for MPLS network
draft-gao-mpls-teas-rsvpte-state-update-06
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Jun Gao , Jinyou Dai | ||
| Last updated | 2023-12-30 (Latest revision 2023-06-28) | ||
| 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
RSVP-TE has the following advantages: source routing capability, and the ability to reserve resources hop by hop along the LSP path. The two advantages are used by Deterministic Networking (DetNet) to provide DetNet Quality of Service (QoS) in a fully distributed control plane utilizing dynamic signaling protocols or in a Combined Control Plane (partly centralized, partly distributed). RSVP takes a "soft state" approach to manage 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.)