Graceful Restart Mechanism for Label Distribution Protocol
RFC 3478
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2003; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3478 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Scott Bradner
|
|
Send notices to |
|
(None)
|
Network Working Group M. Leelanivas
Request for Comments: 3478 Y. Rekhter
Category: Standards Track Juniper Networks
R. Aggarwal
Redback Networks
February 2003
Graceful Restart Mechanism for Label Distribution Protocol
Status of this Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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.
Leelanivas, et al. Standards Track [Page 1]
RFC 3478 Graceful Restart Mechanism for LDP February 2003
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.
Specification of Requirements
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 BCP 14, RFC 2119
[RFC2119].
1. Motivation
For the sake of brevity in the context of this document, by "the
control plane" we mean "the LDP component of the control plane".
For the sake of brevity in the context of this document, by "MPLS
forwarding state" we mean either <incoming label -> (outgoing label,
next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)>
(ingress case) mapping.
In the case where a Label Switching Router (LSR) could preserve its
MPLS forwarding state across restart of its control plane,
specifically its LDP component [LDP], it is desirable not to perturb
the LSPs going through that LSR (specifically, the LSPs established
by LDP). In this document, we describe a mechanism, termed "LDP
Graceful Restart", that allows the accomplishment of this goal.
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 need 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. Clearly this is the
minimum amount of state that has to be preserved across the restart
Show full document text