Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) (RFC3612)
Original Publication Date: 2003-Sep-01
Included in the Prior Art Database: 2003-Sep-12
Internet Society Requests For Comment (RFCs)
This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".
Network Working Group A. Farrel
Request for Comments: 3612 Old Dog Consulting
Category: Informational September 2003
Applicability Statement for Restart Mechanisms
for the Label Distribution Protocol (LDP)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document provides guidance on when it is advisable to implement
some form of Label Distribution Protocol (LDP) restart mechanism and
which approach might be more suitable. The issues and extensions
described in this document are equally applicable to RFC 3212,
"Constraint-Based LSP Setup Using LDP".
Multiprotocol Label Switching (MPLS) systems are used in core
networks where system downtime must be kept to a minimum. Similarly,
where MPLS is at the network edges (e.g., in Provider Edge (PE)
routers) [RFC2547], system downtime must also be kept to a minimum.
Many MPLS Label Switching Routers (LSRs) may, therefore, exploit
Fault Tolerant (FT) hardware or software to provide high availability
of the core networks.
The details of how FT is achieved for the various components of an FT
LSR, including the switching hardware and the TCP stack, are
implementation specific. How the software module itself chooses to
implement FT for the state created by the LDP is also implementation
specific. However, there are several issues in the LDP specification
[RFC3036] that make it difficult to implement an FT LSR using the LDP
protocols without some extensions to those protocols.
Proposals have been made in [RFC3478] and [RFC3479] to address these
Farrel Informational [Page 1]
RFC 3612 Applicability for LDP Restart Mechanisms September 2003
2. Requirements of an LDP FT System
Many MPLS LSRs may exploit FT hardware or software to provide high
availability (HA) of core networks. In order to provide HA, an MPLS
system needs to be able to survive a variety of faults with minimal
disruption to the Data Plane, including the following fault types:
- failure/hot-swap of the switching fabric in an LSR,
- failure/hot-swap of a physical connection between LSRs,
- failure of the TCP or LDP stack in an LSR,
- software upgrade to the TCP or LDP stacks in an LSR.
The first two examples of faults listed above may be confined to the
Data Plane. Such faults can be handled by providing redundancy in
the Data Plane which is transparent to LDP operating in the Control
Plane. However, the failure of the switching fabric or a physical
link may have repercussions in the Control Plane since signaling may
The third example may be caused by a variety of events including
processor or other hardware failure, and software failure.
Any of the last three examples may impact the Control Plane and will
require action in the Control Plane to recover. Such action should
be designed to avoid di...