Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
RFC 4206

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                        K. Kompella
Request for Comments: 4206                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                            October 2005

               Label Switched Paths (LSP) Hierarchy with
          Generalized Multi-Protocol Label Switching (GMPLS)
                        Traffic Engineering (TE)

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 (2005).

Abstract

   To improve scalability of Generalized Multi-Protocol Label Switching
   (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by
   creating a hierarchy of such LSPs.  A way to create such a hierarchy
   is by (a) a Label Switching Router (LSR) creating a Traffic
   Engineering Label Switched Path (TE LSP), (b) the LSR forming a
   forwarding adjacency (FA) out of that LSP (by advertising this LSP as
   a Traffic Engineering (TE) link into the same instance of ISIS/OSPF
   as the one that was used to create the LSP), (c) allowing other LSRs
   to use FAs for their path computation, and (d) nesting of LSPs
   originated by other LSRs into that LSP (by using the label stack
   construct).

   This document describes the mechanisms to accomplish this.

Kompella & Rekhter          Standards Track                     [Page 1]
RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Table of Contents

   1. Overview ........................................................2
   2. Specification of Requirements ...................................3
   3. Routing Aspects .................................................4
      3.1. Traffic Engineering Parameters .............................4
           3.1.1. Link Type (OSPF Only) ...............................5
           3.1.2. Link ID (OSPF Only) .................................5
           3.1.3. Local and Remote Interface IP Address ...............5
           3.1.4. Local and Remote Link Identifiers ...................5
           3.1.5. Traffic Engineering Metric ..........................5
           3.1.6. Maximum Bandwidth ...................................5
           3.1.7. Unreserved Bandwidth ................................5
           3.1.8. Resource Class/Color ................................5
           3.1.9. Interface Switching Capability ......................6
           3.1.10. SRLG Information ...................................6
   4. Other Considerations ............................................6
   5. Controlling FA-LSPs Boundaries ..................................7
      5.1. LSP Regions ................................................7
   6. Signalling Aspects ..............................................8
      6.1. Common Procedures ..........................................8
           6.1.1. RSVP-TE .............................................8
           6.1.2. CR-LDP ..............................................9
      6.2. Specific Procedures .......................................10
      6.3. FA-LSP Holding Priority ...................................11
   7. Security Considerations ........................................11
   8. Acknowledgements ...............................................12
   9. Normative References ...........................................12
   10. Informative References ........................................13

1.  Overview

   An LSR uses Generalized MPLS (GMPLS) TE procedures to create and
   maintain an LSP.  The LSR then may (under local configuration
   control) announce this LSP as a Traffic Engineering (TE) link into
   the same instance of the GMPLS control plane (or, more precisely, its
   ISIS/OSPF component) as the one that was used to create the LSP.  We
   call such a link a "forwarding adjacency" (FA).  We refer to the LSP
   as the "forwarding adjacency LSP", or just FA-LSP.  Note that an FA-
   LSP is both created and used as a TE link by exactly the same
   instance of the GMPLS control plane.  Thus, the concept of an FA is
   applicable only when an LSP is both created and used as a TE link by
   exactly the same instance of the GMPLS control plane.  Note also that
   an FA is a TE link between two GMPLS nodes whose path transits zero
   or more (G)MPLS nodes in the same instance of the GMPLS control
   plane.

Kompella & Rekhter          Standards Track                     [Page 2]
RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

   The nodes connected by a 'basic' TE link may have a routing
   adjacency; however, the nodes connected by an FA would not usually