Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) (RFC3612)

IP.com Disclosure Number: IPCOM000019352D
Original Publication Date: 2003-Sep-01
Included in the Prior Art Database: 2003-Sep-12
Document File: 17 page(s) / 36K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Farrel: AUTHOR

Abstract

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".

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 10% of the total text.

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 Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

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".

1. Introduction

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

issues.

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

be disrupted.

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...