A new Request for Comments is now available in online RFC libraries.
RFC 3478
Title: Graceful Restart Mechanism for Label Distribution
Protocol
Author(s): M. Leelanivas, Y. Rekhter, R. Aggarwal
Status: Standards Track
Date: February 2003
Mailbox: manoj@juniper.net, yakov@juniper.net,
rahul@redback.com
Pages: 12
Characters: 29248
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-mpls-ldp-restart-06.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3478.txt
This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by Label Switching Router's
(LSR's) control plane restart, specifically by the restart of its
Label Distribution Protocol (LDP) component, on LSRs that are capable
of preserving the MPLS forwarding component across the restart.
The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during LDP
restart and those without (although the latter needs to implement only
a subset of the mechanism described in this document). Supporting (a
subset of) the mechanism described here by the LSRs that can not
preserve their MPLS forwarding state across the restart would not
reduce the negative impact on MPLS traffic caused by their control
plane restart, but it would minimize the impact if their neighbor(s)
are capable of preserving the forwarding state across the restart of
their control plane and implement the mechanism described here.
The mechanism makes minimalistic assumptions on what has to be
preserved across restart - the mechanism assumes that only the actual
MPLS forwarding state has to be preserved; the mechanism does not
require any of the LDP-related states to be preserved across the
restart.
The procedures described in this document apply to downstream
unsolicited label distribution. Extending these procedures to
downstream on demand label distribution is for further study.
This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
- <ftp://ftp.isi.edu/in-notes/rfc3478.txt>
-
