rfc3212.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,633 行 · 第 1/5 页

Network Working Group               B. Jamoussi, Editor, Nortel Networks
Request for Comments: 3212                       L. Andersson, Utfors AB
Category: Standards Track                    R. Callon, Juniper Networks
                                           R. Dantu, Netrake Corporation
                                                    L. Wu, Cisco Systems
                                         P. Doolan, OTB Consulting Corp.
                                                              T. Worster
                                                   N. Feldman, IBM Corp.
                                             A. Fredette, ANF Consulting
                                                M. Girish, Atoga Systems
                                                      E. Gray, Sandburst
                                        J. Heinanen, Song Networks, Inc.
                                      T. Kilty, Newbridge Networks, Inc.
                                               A. Malis, Vivace Networks
                                                            January 2002


                 Constraint-Based LSP Setup using LDP

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 (2002).  All Rights Reserved.

Abstract

   This document specifies mechanisms and TLVs (Type/Length/Value) for
   support of CR-LSPs (constraint-based routed Label Switched Path)
   using LDP (Label Distribution Protocol).

   This specification proposes an end-to-end setup mechanism of a CR-LSP
   initiated by the ingress LSR (Label Switching Router).  We also
   specify mechanisms to provide means for reservation of resources
   using LDP.

   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 RFC 2119 [6].






Jamoussi, et al.            Standards Track                     [Page 1]

RFC 3212          Constraint-Based LSP Setup using LDP      January 2002


Table of Contents

   1. Introduction....................................................3
   2. Constraint-based Routing Overview...............................4
   2.1 Strict and Loose Explicit Routes...............................5
   2.2 Traffic Characteristics........................................5
   2.3 Preemption.....................................................5
   2.4 Route Pinning..................................................6
   2.5 Resource Class.................................................6
   3. Solution Overview...............................................6
   3.1 Required Messages and TLVs.....................................7
   3.2 Label Request Message..........................................7
   3.3 Label Mapping Message..........................................9
   3.4 Notification Message..........................................10
   3.5 Release , Withdraw, and Abort Messages........................11
   4. Protocol Specification.........................................11
   4.1 Explicit Route TLV (ER-TLV)...................................11
   4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................12
   4.3 Traffic Parameters TLV........................................13
   4.3.1 Semantics...................................................15
   4.3.1.1 Frequency.................................................15
   4.3.1.2 Peak Rate.................................................16
   4.3.1.3 Committed Rate............................................16
   4.3.1.4 Excess Burst Size.........................................16
   4.3.1.5 Peak Rate Token Bucket....................................16
   4.3.1.6 Committed Data Rate Token Bucket..........................17
   4.3.1.7 Weight....................................................18
   4.3.2 Procedures..................................................18
   4.3.2.1 Label Request Message.....................................18
   4.3.2.2 Label Mapping Message.....................................18
   4.3.2.3 Notification Message......................................19
   4.4 Preemption TLV................................................19
   4.5 LSPID TLV.....................................................20
   4.6 Resource Class (Color) TLV....................................21
   4.7 ER-Hop semantics..............................................22
   4.7.1. ER-Hop 1: The IPv4 prefix..................................22
   4.7.2. ER-Hop 2: The IPv6 address.................................23
   4.7.3. ER-Hop 3:  The autonomous system number....................24
   4.7.4. ER-Hop 4: LSPID............................................24
   4.8. Processing of the Explicit Route TLV.........................26
   4.8.1. Selection of the next hop..................................26
   4.8.2. Adding ER-Hops to the explicit route TLV...................27
   4.9 Route Pinning TLV.............................................28
   4.10 CR-LSP FEC Element...........................................28
   5. IANA Considerations............................................29
   5.1 TLV Type Name Space...........................................29
   5.2 FEC Type Name Space...........................................30
   5.3 Status Code Space.............................................30



Jamoussi, et al.            Standards Track                     [Page 2]

RFC 3212          Constraint-Based LSP Setup using LDP      January 2002


   6. Security Considerations........................................31
   7. Acknowledgments................................................31
   8. Intellectual Property Consideration............................31
   9. References.....................................................32
   Appendix A: CR-LSP Establishment Examples.........................33
   A.1 Strict Explicit Route Example.................................33
   A.2 Node Groups and Specific Nodes Example........................34
   Appendix B. QoS Service Examples..................................36
   B.1 Service Examples..............................................36
   B.2 Establishing CR-LSP Supporting Real-Time Applications.........38
   B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.38
   Author's Addresses................................................39
   Full Copyright Statement..........................................42

1. Introduction

   Label Distribution Protocol (LDP) is defined in [1] for distribution
   of labels inside one MPLS domain.  One of the most important services
   that may be offered using MPLS in general and LDP in particular is
   support for constraint-based routing of traffic across the routed
   network.  Constraint-based routing offers the opportunity to extend
   the information used to setup paths beyond what is available for the
   routing protocol.  For instance, an LSP can be setup based on
   explicit route constraints, QoS constraints, and other constraints.
   Constraint-based routing (CR) is a mechanism used to meet Traffic
   Engineering requirements that have been proposed by, [2] and [3].
   These requirements may be met by extending LDP for support of
   constraint-based routed label switched paths (CR-LSPs).  Other uses
   for CR-LSPs include MPLS-based VPNs [4].  More information about the
   applicability of CR-LDP can be found in [5].

   The need for constraint-based routing (CR) in MPLS has been explored
   elsewhere [2], and [3].  Explicit routing is a subset of the more
   general constraint-based routing function.  At the MPLS WG meeting
   held during the Washington IETF (December 1997) there was consensus
   that LDP should support explicit routing of LSPs with provision for
   indication of associated (forwarding) priority.  In the Chicago
   meeting (August 1998), a decision was made that support for explicit
   path setup in LDP will be moved to a separate document.  This
   document provides that support and it has been accepted as a working
   document in the Orlando meeting (December 1998).










Jamoussi, et al.            Standards Track                     [Page 3]

RFC 3212          Constraint-Based LSP Setup using LDP      January 2002


   This specification proposes an end-to-end setup mechanism of a
   constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. We
   also specify mechanisms to provide means for reservation of resources
   using LDP.

   This document introduce TLVs and procedures that provide support for:

         -  Strict and Loose Explicit Routing
         -  Specification of Traffic Parameters
         -  Route Pinning
         -  CR-LSP Preemption though setup/holding priorities
         -  Handling Failures
         -  LSPID
         -  Resource Class

   Section 2 introduces the various constraints defined in this
   specification.  Section 3 outlines the CR-LDP solution.  Section 4
   defines the TLVs and procedures used to setup constraint-based routed
   label switched paths.  Appendix A provides several examples of CR-LSP
   path setup.  Appendix B provides Service Definition Examples.

2. Constraint-based Routing Overview

   Constraint-based routing is a mechanism that supports the Traffic
   Engineering requirements defined in [3].  Explicit Routing is a
   subset of the more general constraint-based routing where the
   constraint is the explicit route (ER).  Other constraints are defined
   to provide a network operator with control over the path taken by an
   LSP.  This section is an overview of the various constraints
   supported by this specification.

   Like any other LSP a CR-LSP is a path through an MPLS network.  The
   difference is that while other paths are setup solely based on
   information in routing tables or from a management system, the
   constraint-based route is calculated at one point at the edge of
   network based on criteria, including but not limited to routing
   information.  The intention is that this functionality shall give
   desired special characteristics to the LSP in order to better support
   the traffic sent over the LSP.  The reason for setting up CR-LSPs
   might be that one wants to assign certain bandwidth or other Service
   Class characteristics to the LSP, or that one wants to make sure that
   alternative routes use physically separate paths through the network.









Jamoussi, et al.            Standards Track                     [Page 4]

RFC 3212          Constraint-Based LSP Setup using LDP      January 2002


2.1 Strict and Loose Explicit Routes

   An explicit route is represented in a Label Request Message as a list
   of nodes or groups of nodes along the constraint-based route. When
   the CR-LSP is established, all or a subset of the nodes in a group
   may be traversed by the LSP.  Certain operations to be performed
   along the path can also be encoded in the constraint-based route.

   The capability to specify, in addition to specified nodes, groups of
   nodes, of which a subset will be traversed by the CR-LSP, allows the
   system a significant amount of local flexibility in fulfilling a
   request for a constraint-based route.  This allows the generator of
   the constraint-based route to have some degree of imperfect
   information about the details of the path.

   The constraint-based route is encoded as a series of ER-Hops
   contained in a constraint-based route TLV.  Each ER-Hop may identify
   a group of nodes in the constraint-based route.  A constraint-based
   route is then a path including all of the identified groups of nodes
   in the order in which they appear in the TLV.

   To simplify the discussion, we call each group of nodes an "abstract
   node".  Thus, we can also say that a constraint-based route is a path
   including all of the abstract nodes, with the specified operations
   occurring along that path.

2.2 Traffic Characteristics

   The traffic characteristics of a path are described in the Traffic
   Parameters TLV in terms of a peak rate, committed rate, and service
   granularity.  The peak and committed rates describe the bandwidth
   constraints of a path while the service granularity can be used to
   specify a constraint on the delay variation that the CR-LDP MPLS
   domain may introduce to a path's traffic.

2.3 Preemption

   CR-LDP signals the resources required by a path on each hop of the
   route.  If a route with sufficient resources can not be found,
   existing paths may be rerouted to reallocate resources to the new
   path.  This is the process of path preemption.  Setup and holding
   priorities are used to rank existing paths (holding priority) and the
   new path (setup priority) to determine if the new path can preempt an
   existing path.

   The setupPriority of a new CR-LSP and the holdingPriority attributes
   of the existing CR-LSP are used to specify priorities.  Signaling a
   higher holding priority express that the path, once it has been



Jamoussi, et al.            Standards Track                     [Page 5]

RFC 3212          Constraint-Based LSP Setup using LDP      January 2002


   established, should have a lower chance of being preempted. Signaling
   a higher setup priority expresses the expectation that, in the case
   that resource are unavailable, the path is more likely to preempt
   other paths.  The exact rules determining bumping are an aspect of
   network policy.

   The allocation of setup and holding priority values to paths is an
   aspect of network policy.

   The setup and holding priority values range from zero (0) to seven
   (7).  The value zero (0) is the priority assigned to the most
   important path.  It is referred to as the highest priority.  Seven
   (7) is the priority for the least important path.  The use of default
   priority values is an aspect of network policy.  The recommended
   default value is (4).

   The setupPriority of a CR-LSP should not be higher (numerically less)
   than its holdingPriority since it might bump an LSP and be bumped by
   the next "equivalent" request.

2.4 Route Pinning

   Route pinning is applicable to segments of an LSP that are loosely
   routed - i.e. those segments which are specified with a next hop with
   the "L" bit set or where the next hop is an abstract node.  A CR-LSP
   may be setup using route pinning if it is undesirable to change the
   path used by an LSP even when a better next hop becomes available at
   some LSR along the loosely routed portion of the LSP.

2.5 Resource Class

   The network operator may classify network resources in various ways.
   These classes are also known as "colors" or "administrative groups".
   When a CR-LSP is being established, it's necessary to indicate which
   resource classes the CR-LSP can draw from.

3. Solution Overview

   CR-LSP over LDP Specification is designed with the following goals:

      1. Meet the requirements outlined in [3] for performing traffic