rfc3209.txt

RFC 的详细文档！

   that Path message's session and PHOP.

   A node that sends a LABEL_REQUEST object MUST be ready to accept and
   correctly process a LABEL object in the corresponding Resv messages.

   A node that recognizes a LABEL_REQUEST object, but that is unable to
   support it (possibly because of a failure to allocate labels) SHOULD
   send a PathErr with the error code "Routing problem" and the error
   value "MPLS label allocation failure."  This includes the case where
   a label range has been specified and a label cannot be allocated from
   that range.






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


   A node which receives and forwards a Path message each with a
   LABEL_REQUEST object, MUST copy the L3PID from the received
   LABEL_REQUEST object to the forwarded LABEL_REQUEST object.

   If the receiver cannot support the protocol L3PID, it SHOULD send a
   PathErr with the error code "Routing problem" and the error value
   "Unsupported L3PID."  This causes the RSVP session to fail.

4.2.5. Non-support of the Label Request Object

   An RSVP router that does not recognize the LABEL_REQUEST object sends
   a PathErr with the error code "Unknown object class" toward the
   sender.  An RSVP router that recognizes the LABEL_REQUEST object but
   does not recognize the C_Type sends a PathErr with the error code
   "Unknown object C_Type" toward the sender.  This causes the path
   setup to fail.  The sender should notify management that a LSP cannot
   be established and possibly take action to continue the reservation
   without the LABEL_REQUEST.

   RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers.  However, obviously, non-RSVP routers
   cannot convey labels via RSVP.  This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."  This same message SHOULD be sent, if a router receives a
   LABEL_REQUEST object in a message from a non-RSVP capable router.
   See [1] for a description of how a downstream router can determine
   the presence of non-RSVP routers.

4.3. Explicit Route Object

   Explicit routes are specified via the EXPLICIT_ROUTE object (ERO).
   The Explicit Route Class is 20.  Currently one C_Type is defined,
   Type 1 Explicit Route.  The EXPLICIT_ROUTE object has the following
   format:













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


   Class = 20, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subobjects

   The contents of an EXPLICIT_ROUTE object are a series of variable-
   length data items called subobjects.  The subobjects are defined in
   section 4.3.3 below.

   If a Path message contains multiple EXPLICIT_ROUTE objects, only the
   first object is meaningful.  Subsequent EXPLICIT_ROUTE objects MAY be
   ignored and SHOULD NOT be propagated.

4.3.1. Applicability

   The EXPLICIT_ROUTE object is intended to be used only for unicast
   situations.  Applications of explicit routing to multicast are a
   topic for further research.

   The EXPLICIT_ROUTE object is to be used only when all routers along
   the explicit route support RSVP and the EXPLICIT_ROUTE object.  The
   EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb.
   RSVP routers that do not support the object will therefore respond
   with an "Unknown Object Class" error.

4.3.2. Semantics of the Explicit Route Object

   An explicit route is a particular path in the network topology.
   Typically, the explicit route is determined by a node, with the
   intent of directing traffic along that path.

   An explicit route is described as a list of groups of nodes along the
   explicit route.  In addition to the ability to identify specific
   nodes along the path, an explicit route can identify a group of nodes
   that must be traversed along the path.  This capability allows the
   routing system a significant amount of local flexibility in
   fulfilling a request for an explicit route.  This capability allows
   the generator of the explicit route to have imperfect information
   about the details of the path.





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


   The explicit route is encoded as a series of subobjects contained in
   an EXPLICIT_ROUTE object.  Each subobject identifies a group of nodes
   in the explicit route.  An explicit route is thus a specification of
   groups of nodes to be traversed.

   To formalize the discussion, we call each group of nodes an abstract
   node.  Thus, we say that an explicit route is a specification of a
   set of abstract nodes to be traversed.  If an abstract node consists
   of only one node, we refer to it as a simple abstract node.

   As an example of the concept of abstract nodes, consider an explicit
   route that consists solely of Autonomous System number subobjects.
   Each subobject corresponds to an Autonomous System in the global
   topology.  In this case, each Autonomous System is an abstract node,
   and the explicit route is a path that includes each of the specified
   Autonomous Systems.  There may be multiple hops within each
   Autonomous System, but these are opaque to the source node for the
   explicit route.

4.3.3. Subobjects

   The contents of an EXPLICIT_ROUTE object are a series of variable-
   length data items called subobjects.  Each subobject has the form:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   |L|    Type     |     Length    | (Subobject contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.

      Type

         The Type indicates the type of contents of the subobject.
         Currently defined values are:

                   1   IPv4 prefix
                   2   IPv6 prefix
                  32   Autonomous system number






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


      Length

         The Length contains the total length of the subobject in bytes,
         including the L, Type and Length fields.  The Length MUST be at
         least 4, and MUST be a multiple of 4.

4.3.3.1. Strict and Loose Subobjects

   The L bit in the subobject is a one-bit attribute.  If the L bit is
   set, then the value of the attribute is 'loose.'  Otherwise, the
   value of the attribute is 'strict.'  For brevity, we say that if the
   value of the subobject attribute is 'loose' then it is a 'loose
   subobject.'  Otherwise, it's a 'strict subobject.'  Further, we say
   that the abstract node of a strict or loose subobject is a strict or
   a loose node, respectively.  Loose and strict nodes are always
   interpreted relative to their prior abstract nodes.

   The path between a strict node and its preceding node MUST include
   only network nodes from the strict node and its preceding abstract
   node.

   The path between a loose node and its preceding node MAY include
   other network nodes that are not part of the strict node or its
   preceding abstract node.

4.3.3.2. Subobject 1:  IPv4 prefix

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|    Type     |     Length    | IPv4 address (4 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 address (continued)      | Prefix Length |      Resvd    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.

      Type

         0x01  IPv4 address






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


      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.  The Length is always 8.

      IPv4 address

         An IPv4 address.  This address is treated as a prefix based on
         the prefix length value below.  Bits beyond the prefix are
         ignored on receipt and SHOULD be set to zero on transmission.

      Prefix length

         Length in bits of the IPv4 prefix

      Padding

         Zero on transmission.  Ignored on receipt.

   The contents of an IPv4 prefix subobject are a 4-octet IPv4 address,
   a 1-octet prefix length, and a 1-octet pad.  The abstract node
   represented by this subobject is the set of nodes that have an IP
   address which lies within this prefix.  Note that a prefix length of
   32 indicates a single IPv4 node.

4.3.3.3. Subobject 2:  IPv6 Prefix

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|    Type     |     Length    | IPv6 address (16 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)      | Prefix Length |      Resvd    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.




Awduche, et al.             Standards Track                    [Page 27]

RFC 3209           Extensions