rfc3212.txt

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

         A fourteen-bit field carrying the value of the ER-Hop 3, AS
         Number, Type = 0x0803

   Length
         Specifies the length of the value field in bytes = 4.

   L Bit
         Set to indicate Loose hop.
         Cleared to indicate a strict hop.

   Reserved
         Zero on transmission.  Ignored on receipt.

   AS Number
         Autonomous System number

4.7.4. ER-Hop 4: LSPID

   The LSPID is used to identify the tunnel ingress point as the next
   hop in the ER.  This ER-Hop allows for stacking new CR-LSPs within an
   already established CR-LSP.  It also allows for splicing the CR-LSP
   being established with an existing CR-LSP.

   If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may
   splice the CR-LSP of the incoming Label Request to the CR-LSP that
   currently exists with this LSPID.  This is useful, for example, at
   the point at which a Label Request used for local repair arrives at
   the next ER-Hop after the loosely specified CR-LSP segment.  Use of
   the LSPID Hop in this scenario eliminates the need for ER-Hops to
   keep the entire remaining ER-TLV at each LSR that is at either
   (upstream or downstream) end of a loosely specified CR-LSP segment as
   part of its state information.  This is due to the fact that the





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


   upstream LSR needs only to keep the next ER-Hop and the LSPID and the
   downstream LSR needs only to keep the LSPID in order for each end to
   be able to recognize that the same LSP is being identified.

   If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
   remove the LSP-ID Hop and forward the remaining ER-TLV in a Label
   Request message using an LDP session established with the LSR that is
   the specified CR-LSP's egress.  That LSR will continue processing of
   the CR-LSP Label Request Message.  The result is a tunneled, or
   stacked, CR-LSP.

   To support labels negotiated for tunneled CR-LSP segments, an LDP
   session is required [1] between tunnel end points - possibly using
   the existing CR-LSP.  Use of the existence of the CR-LSP in lieu of a
   session, or other possible session-less approaches, is FFS.

   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|          0x0804           |      Length = 8               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|          Reserved           |               Local LSPID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Ingress LSR Router ID                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
         A fourteen-bit field carrying the value of the ER-Hop 4, LSPID,
         Type = 0x0804

   Length
         Specifies the length of the value field in bytes = 8.

   L Bit
         Set to indicate Loose hop.
         Cleared to indicate a strict hop.

   Reserved
         Zero on transmission.  Ignored on receipt.

   Local LSPID
         A 2 byte field indicating the LSPID which is unique with
         reference to its Ingress LSR.

   Ingress LSR Router ID
         An LSR may use any of its own IPv4 addresses in this field.





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


4.8. Processing of the Explicit Route TLV

4.8.1. Selection of the next hop

   A Label Request Message containing an explicit route TLV must
   determine the next hop for this path.  Selection of this next hop may
   involve a selection from a set of possible alternatives.  The
   mechanism for making a selection from this set is implementation
   dependent and is outside of the scope of this specification.
   Selection of particular paths is also outside of the scope of this
   specification, but it is assumed that each node will make a best
   effort attempt to determine a loop-free path.  Note that such best
   efforts may be overridden by local policy.

   To determine the next hop for the path, a node performs the following
   steps:

      1. The node receiving the Label Request Message must first
         evaluate the first ER-Hop.  If the L bit is not set in the
         first ER-Hop and if the node is not part of the abstract node
         described by the first ER-Hop, it has received the message in
         error, and should return a "Bad Initial ER-Hop Error" status.
         If the L bit is set and the local node is not part of the
         abstract node described by the first ER-Hop, the node selects a
         next hop that is along the path to the abstract node described
         by the first ER-Hop.  If there is no first ER-Hop, the message
         is also in error and the system should return a "Bad Explicit
         Routing TLV Error" status using a Notification Message sent
         upstream.

      2. If there is no second ER-Hop, this indicates the end of the
         explicit route.  The explicit route TLV should be removed from
         the Label Request Message.  This node may or may not be the end
         of the LSP.  Processing continues with section 4.8.2, where a
         new explicit route TLV may be added to the Label Request
         Message.

      3. If the node is also a part of the abstract node described by
         the second ER-Hop, then the node deletes the first ER-Hop and
         continues processing with step 2, above.  Note that this makes
         the second ER-Hop into the first ER-Hop of the next iteration.

      4. The node determines if it is topologically adjacent to the
         abstract node described by the second ER-Hop.  If so, the node
         selects a particular next hop which is a member of the abstract
         node.  The node then deletes the first ER-Hop and continues
         processing with section 4.8.2.




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


      5. Next, the node selects a next hop within the abstract node of
         the first ER-Hop that is along the path to the abstract node of
         the second ER-Hop.  If no such path exists then there are two
         cases:

         5.a If the second ER-Hop is a strict ER-Hop, then there is an
             error and the node should return a "Bad Strict Node Error"
             status.

         5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then the
             node selects any next hop that is along the path to the
             next abstract node.  If no path exists within the MPLS
             domain, then there is an error, and the node should return
             a "Bad Loose Node Error" status.

      6. Finally, the node replaces the first ER-Hop with any ER-Hop
         that denotes an abstract node containing the next hop.  This is
         necessary so that when the explicit route is received by the
         next hop, it will be accepted.

      7. Progress the Label Request Message to the next hop.

4.8.2. Adding ER-Hops to the explicit route TLV

   After selecting a next hop, the node may alter the explicit route in
   the following ways.

   If, as part of executing the algorithm in section 4.8.1, the explicit
   route TLV is removed, the node may add a new explicit route TLV.

   Otherwise, if the node is a member of the abstract node for the first
   ER-Hop, then a series of ER-Hops may be inserted before the first
   ER-Hop or may replace the first ER-Hop.  Each ER-Hop in this series
   must denote an abstract node that is a subset of the current abstract
   node.

   Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary
   series of ER-Hops may be inserted prior to the first ER-Hop.













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


4.9 Route Pinning TLV

   Section 2.4 describes the use of route pinning. The encoding of the
   Route Pinning TLV 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|0|          Type = 0x0823    |      Length = 4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P|                        Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
         A fourteen-bit field carrying the value of the Pinning-TLV
         Type = 0x0823

   Length
         Specifies the length of the value field in bytes = 4.

   P Bit
         The P bit is set to 1 to indicate that route pinning is
         requested.
         The P bit is set to 0 to indicate that route pinning is not
         requested

   Reserved
         Zero on transmission.  Ignored on receipt.

4.10 CR-LSP FEC Element

   A new FEC element is introduced in this specification to support CR-
   LSPs.  A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a
   CR-LSP FEC TLV.  The CR-LSP FEC Element is an opaque FEC to be used
   only in Messages of CR-LSPs.

   A single FEC element MUST be included in the Label Request Message.
   The FEC Element SHOULD be the CR-LSP FEC Element.  However, one of
   the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be
   in CR-LDP messages instead of the CR-LSP FEC Element for certain
   applications.  A FEC TLV containing a FEC of Element type CR-LSP
   (0x04) is a CR-LSP FEC TLV.

         FEC Element     Type    Value
         Type name

         CR-LSP         0x04    No value; i.e., 0 value octets;




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


   The CR-LSP FEC TLV encoding 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|0|          Type = 0x0100    |      Length = 1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CR-LSP (4)    |
   +-+-+-+-+-+-+-+-+

   Type
         A fourteen-bit field carrying the value of the FEC TLV
         Type = 0x0100

   Length
         Specifies the length of the value field in bytes = 1.

   CR-LSP FEC Element Type

         0x04

5. IANA Considerations

   CR-LDP defines the following name spaces, which require management:

         -  TLV types.
         -  FEC types.
         -  Status codes.

   The following sections provide guidelines for managing these name
   spaces.

5.1 TLV Type Name Space

   RFC 3036 [1] defines the LDP TLV name space.  This document further
   subdivides the range of RFC 3036 from that TLV space for TLVs
   associated with the CR-LDP in the range 0x0800 - 0x08FF.

   Following the policies outlined in [IANA], TLV types in this range
   are allocated through an IETF Consensus action.











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


   Initial values for this range are specified in the following table:

         TLV