RFC 5150

Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE), February 2008

File formats:
icon for text file icon for PDF icon for HTML icon for inline errata
Status:
PROPOSED STANDARD
Authors:
A. Ayyangar
K. Kompella
JP. Vasseur
A. Farrel
Stream:
IETF
Source:
ccamp (rtg)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC5150

Discuss this RFC: Send questions or comments to the mailing list ccamp@ietf.org

Other actions: View Errata  |  Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 5150


Abstract

In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.

It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.




Advanced Search