rfc3212.txt

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

         engineering and provide a solid foundation for performing more
         general constraint-based routing.

      2. Build on already specified functionality that meets the
         requirements whenever possible.  Hence, this specification is
         based on [1].




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


      3. Keep the solution simple.

   In this document, support for unidirectional point-to-point CR-LSPs
   is specified.  Support for point-to-multipoint, multipoint-to-point,
   is for further study (FFS).

   Support for constraint-based routed LSPs in this specification
   depends on the following minimal LDP behaviors as specified in [1]:

      -  Use of Basic and/or Extended Discovery Mechanisms.
      -  Use of the Label Request Message defined in [1] in downstream
         on demand label advertisement mode with ordered control.
      -  Use of the Label Mapping Message defined in [1] in downstream
         on demand mode with ordered control.
      -  Use of the Notification Message defined in [1].
      -  Use of the Withdraw and Release Messages defined in [1].
      -  Use of the Loop Detection (in the case of loosely routed
         segments of a CR-LSP) mechanisms defined in [1].

   In addition, the following functionality is added to what's defined
   in [1]:

      -  The Label Request Message used to setup a CR-LSP includes one
         or more CR-TLVs defined in Section 4.  For instance, the Label
         Request Message may include the ER-TLV.

      -  An LSR implicitly infers ordered control from the existence of
         one or more CR-TLVs in the Label Request Message.  This means
         that the LSR can still be configured for independent control
         for LSPs established as a result of dynamic routing.  However,
         when a Label Request Message includes one or more of the CR-
         TLVs, then ordered control is used to setup the CR-LSP.  Note
         that this is also true for the loosely routed parts of a CR-
         LSP.

      -  New status codes are defined to handle error notification for
         failure of established paths specified in the CR-TLVs.  All of
         the new status codes require that the F bit be set.

   Optional TLVs MUST be implemented to be compliant with the protocol.
   However, they are optionally carried in the CR-LDP messages to signal
   certain characteristics of the CR-LSP being established or modified.

   Examples of CR-LSP establishment are given in Appendix A to
   illustrate how the mechanisms described in this document work.






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


3.1 Required Messages and TLVs

   Any Messages, TLVs, and procedures not defined explicitly in this
   document are defined in the LDP Specification [1].  The reader can
   use [7] as an informational document about the state transitions,
   which relate to CR-LDP messages.

   The following subsections are meant as a cross-reference to the [1]
   document and indication of additional functionality beyond what's
   defined in [1] where necessary.

   Note that use of the Status TLV is not limited to Notification
   messages as specified in Section 3.4.6 of [1].  A message other than
   a Notification message may carry a Status TLV as an Optional
   Parameter.  When a message other than a Notification carries a Status
   TLV the U-bit of the Status TLV should be set to 1 to indicate that
   the receiver should silently discard the TLV if unprepared to handle
   it.

3.2 Label Request Message

   The Label Request Message is as defined in 3.5.8 of [1] with the
   following modifications (required only if any of the CR-TLVs is
   included in the Label Request Message):

      -  The Label Request Message MUST include a single FEC-TLV
         element. The CR-LSP FEC TLV element SHOULD be used.  However,
         the other FEC- TLVs defined in [1] MAY be used instead for
         certain applications.

      -  The Optional Parameters TLV includes the definition of any of
         the Constraint-based TLVs specified in Section 4.

      -  The Procedures to handle the Label Request Message are
         augmented by the procedures for processing of the CR-TLVs as
         defined in Section 4.















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


   The encoding for the CR-LDP Label Request Message is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Request (0x0401)   |      Message Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LSPID TLV            (CR-LDP, mandatory)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ER-TLV               (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic  TLV         (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Pinning TLV          (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Resource Class TLV (CR-LDP, optional)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Preemption  TLV      (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3 Label Mapping Message

   The Label Mapping Message is as defined in 3.5.7 of [1] with the
   following modifications:

      -  The Label Mapping Message MUST include a single Label-TLV.

      -  The Label Mapping Message Procedures are limited to downstream
         on demand ordered control mode.

   A Mapping message is transmitted by a downstream LSR to an upstream
   LSR under one of the following conditions:

      1. The LSR is the egress end of the CR-LSP and an upstream mapping
         has been requested.

      2. The LSR received a mapping from its downstream next hop LSR for
         an CR-LSP for which an upstream request is still pending.









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


   The encoding for the CR-LDP Label Mapping Message is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Mapping (0x0400)   |      Message Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Label Request Message ID TLV                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LSPID TLV            (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic  TLV         (CR-LDP, optional)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.4 Notification Message

   The Notification Message is as defined in Section 3.5.1 of [1] and
   the Status TLV encoding is as defined in Section 3.4.6 of [1].
   Establishment of an CR-LSP may fail for a variety of reasons.  All
   such failures are considered advisory conditions and they are
   signaled by the Notification Message.

   Notification Messages carry Status TLVs to specify events being
   signaled.  New status codes are defined in Section 4.11 to signal
   error notifications associated with the establishment of a CR-LSP and
   the processing of the CR-TLV.  All of the new status codes require
   that the F bit be set.

   The Notification Message MAY carry the LSPID TLV of the corresponding
   CR-LSP.

   Notification Messages MUST be forwarded toward the LSR originating
   the Label Request at each hop and at any time that procedures in this
   specification - or in [1] - specify sending of a Notification Message
   in response to a Label Request Message.










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


   The encoding of the notification message is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status (TLV)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.5 Release , Withdraw, and Abort Messages

   The Label Release , Label Withdraw, and Label Abort Request Messages
   are used as specified in [1].  These messages MAY also carry the
   LSPID TLV.

4. Protocol Specification

   The Label Request Message defined in [1] MUST carry the LSPID TLV and
   MAY carry one or more of the optional Constraint-based Routing TLVs
   (CR-TLVs) defined in this section.  If needed, other constraints can
   be supported later through the definition of new TLVs.  In this
   specification, the following TLVs are defined:

      -  Explicit Route TLV
      -  Explicit Route Hop TLV
      -  Traffic Parameters TLV
      -  Preemption TLV
      -  LSPID TLV
      -  Route Pinning TLV
      -  Resource Class TLV
      -  CR-LSP FEC TLV

4.1 Explicit Route TLV (ER-TLV)

   The ER-TLV is an object that specifies the path to be taken by the
   LSP being established.  It is composed of one or more Explicit Route
   Hop TLVs (ER-Hop TLVs) defined in Section 4.2.









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


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|         Type = 0x0800     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ER-Hop TLV 1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ER-Hop TLV 2                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          ............                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ER-Hop TLV n                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
         A fourteen-bit field carrying the value of the ER-TLV
         Type = 0x0800.

   Length
         Specifies the length of the value field in bytes.

   ER-Hop TLVs
         One or more ER-Hop TLVs defined in Section 4.2.

4.2 Explicit Route Hop TLV (ER-Hop TLV)

   The contents of an ER-TLV are a series of variable length ER-Hop
   TLVs.

   A node receiving a label request message including an ER-Hop type
   that is not supported MUST not progress the label request message to
   the downstream LSR and MUST send back a "No Route" Notification