rfc3209.txt

RFC 的详细文档！

   LABEL class = 16, C_Type = 1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           (top label)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents of a LABEL is a single label, encoded in 4 octets.  Each
   generic MPLS label is an unsigned integer in the range 0 through
   1048575.  Generic MPLS labels and FR labels are encoded right aligned
   in 4 octets.  ATM labels are encoded with the VPI right justified in
   bits 0-15 and the VCI right justified in bits 16-31.

4.1.1. Handling Label Objects in Resv messages

   In MPLS a node may support multiple label spaces, perhaps associating
   a unique space with each incoming interface.  For the purposes of the
   following discussion, the term "same label" means the identical label
   value drawn from the identical label space.  Further, the following
   applies only to unicast sessions.

   Labels received in Resv messages on different interfaces are always
   considered to be different even if the label value is the same.

4.1.1.1. Downstream

   The downstream node selects a label to represent the flow.  If a
   label range has been specified in the label request, the label MUST
   be drawn from that range.  If no label is available the node sends a
   PathErr message with an error code of "routing problem" and an error
   value of "label allocation failure".

   If a node receives a Resv message that has assigned the same label
   value to multiple senders, then that node MAY also assign a single
   value to those same senders or to any subset of those senders.  Note




Awduche, et al.             Standards Track                    [Page 17]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


   that if a node intends to police individual senders to a session, it
   MUST assign unique labels to those senders.

   In the case of ATM, one further condition applies.  Some ATM nodes
   are not capable of merging streams.  These nodes MAY indicate this by
   setting a bit in the label request to zero.  The M-bit in the
   LABEL_REQUEST object of C-Type 2, label request with ATM label range,
   serves this purpose.  The M-bit SHOULD be set by nodes which are
   merge capable.  If for any senders the M-bit is not set, the
   downstream node MUST assign unique labels to those senders.

   Once a label is allocated, the node formats a new LABEL object.  The
   node then sends the new LABEL object as part of the Resv message to
   the previous hop.  The node SHOULD be prepared to forward packets
   carrying the assigned label prior to sending the Resv message.  The
   LABEL object SHOULD be kept in the Reservation State Block.  It is
   then used in the next Resv refresh event for formatting the Resv
   message.

   A node is expected to send a Resv message before its refresh timers
   expire if the contents of the LABEL object change.

4.1.1.2. Upstream

   A node uses the label carried in the LABEL object as the outgoing
   label associated with the sender.  The router allocates a new label
   and binds it to the incoming interface of this session/sender.  This
   is the same interface that the router uses to forward Resv messages
   to the previous hops.

   Several circumstance can lead to an unacceptable label.

      1. the node is a merge incapable ATM switch but the downstream
         node has assigned the same label to two senders

      2. The implicit null label was assigned, but the node is not
         capable of doing a penultimate pop for the associated L3PID

      3. The assigned label is outside the requested label range

   In any of these events the node send a ResvErr message with an error
   code of "routing problem" and an error value of "unacceptable label
   value".








Awduche, et al.             Standards Track                    [Page 18]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


4.1.2. Non-support of the Label Object

   Under normal circumstances, a node should never receive a LABEL
   object in a Resv message unless it had included a LABEL_REQUEST
   object in the corresponding Path message.  However, an RSVP router
   that does not recognize the LABEL object sends a ResvErr with the
   error code "Unknown object class" toward the receiver.  This causes
   the reservation to fail.

4.2. Label Request Object

   The Label Request Class is 19.  Currently there are three possible
   C_Types.  Type 1 is a Label Request without label range.  Type 2 is a
   label request with an ATM label range.  Type 3 is a label request
   with a Frame Relay label range.  The LABEL_REQUEST object formats are
   shown below.

4.2.1. Label Request without Label Range

   Class = 19, C_Type = 1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.















Awduche, et al.             Standards Track                    [Page 19]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


4.2.2. Label Request with ATM Label Range

   Class = 19, C_Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M| Res |    Minimum VPI        |      Minimum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |    Maximum VPI        |      Maximum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved (Res)

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

      M

         Setting this bit to one indicates that the node is capable of
         merging in the data plane

      Minimum VPI (12 bits)

         This 12 bit field specifies the lower bound of a block of
         Virtual Path Identifiers that is supported on the originating
         switch.  If the VPI is less than 12-bits it MUST be right
         justified in this field and preceding bits MUST be set to zero.

      Minimum VCI (16 bits)

         This 16 bit field specifies the lower bound of a block of
         Virtual Connection Identifiers that is supported on the
         originating switch.  If the VCI is less than 16-bits it MUST be
         right justified in this field and preceding bits MUST be set to
         zero.








Awduche, et al.             Standards Track                    [Page 20]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


      Maximum VPI (12 bits)

         This 12 bit field specifies the upper bound of a block of
         Virtual Path Identifiers that is supported on the originating
         switch.  If the VPI is less than 12-bits it MUST be right
         justified in this field and preceding bits MUST be set to zero.

      Maximum VCI (16 bits)

         This 16 bit field specifies the upper bound of a block of
         Virtual Connection Identifiers that is supported on the
         originating switch.  If the VCI is less than 16-bits it MUST be
         right justified in this field and preceding bits MUST be set to
         zero.

4.2.3. Label Request with Frame Relay Label Range

   Class = 19, C_Type = 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |DLI|                     Minimum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved        |                     Maximum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

      DLI

         DLCI Length Indicator.  The number of bits in the DLCI.  The
         following values are supported:

                   Len    DLCI bits

                    0        10
                    2        23



Awduche, et al.             Standards Track                    [Page 21]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


      Minimum DLCI

         This 23-bit field specifies the lower bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI MUST be right justified in this
         field and unused bits MUST be set to 0.

      Maximum DLCI

         This 23-bit field specifies the upper bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI MUST be right justified in this
         field and unused bits MUST be set to 0.

4.2.4. Handling of LABEL_REQUEST

   To establish an LSP tunnel the sender creates a Path message with a
   LABEL_REQUEST object.  The LABEL_REQUEST object indicates that a
   label binding for this path is requested and provides an indication
   of the network layer protocol that is to be carried over this path.
   This permits non-IP network layer protocols to be sent down an LSP.
   This information can also be useful in actual label allocation,
   because some reserved labels are protocol specific, see [5].

   The LABEL_REQUEST SHOULD be stored in the Path State Block, so that
   Path refresh messages will also contain the LABEL_REQUEST object.
   When the Path message reaches the receiver, the presence of the
   LABEL_REQUEST object triggers the receiver to allocate a label and to
   place the label in the LABEL object for the corresponding Resv
   message.  If a label range was specified, the label MUST be allocated
   from that range.  A receiver that accepts a LABEL_REQUEST object MUST
   include a LABEL object in Resv messages pertaining to that Path
   message.  If a LABEL_REQUEST object was not present in the Path
   message, a node MUST NOT include a LABEL object in a Resv message for