tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3209

 
 
 

RSVP-TE: Extensions to RSVP for LSP Tunnels

Part 3 of 3, p. 43 to 61
Prev RFC Part

 


prevText      Top      Up      ToC       Page 43 
4.7. Session Attribute Object

   The Session Attribute Class is 207.  Two C_Types are defined,
   LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1.  The
   LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL
   C-Type.  Additionally it carries resource affinity information.  The
   formats are as follows:

4.7.1. Format without resource affinities

   SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //          Session Name      (NULL padded display string)      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Setup Priority

         The priority of the session with respect to taking resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         The Setup Priority is used in deciding whether this session can
         preempt another session.

      Holding Priority

         The priority of the session with respect to holding resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         Holding Priority is used in deciding whether this session can
         be preempted by another session.

Top      Up      ToC       Page 44 
      Flags

         0x01  Local protection desired

               This flag permits transit routers to use a local repair
               mechanism which may result in violation of the explicit
               route object.  When a fault is detected on an adjacent
               downstream link or node, a transit router can reroute
               traffic for fast service restoration.

         0x02  Label recording desired

               This flag indicates that label information should be
               included when doing a route record.

         0x04  SE Style desired

               This flag indicates that the tunnel ingress node may
               choose to reroute this tunnel without tearing it down.
               A tunnel egress node SHOULD use the SE Style when
               responding with a Resv message.

      Name Length

         The length of the display string before padding, in bytes.

      Session Name

         A null padded string of characters.

Top      Up      ToC       Page 45 
4.7.2. Format with resource affinities

    SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Exclude-any                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Include-any                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Include-all                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //          Session Name      (NULL padded display string)      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Exclude-any

         A 32-bit vector representing a set of attribute filters
         associated with a tunnel any of which renders a link
         unacceptable.

      Include-any

         A 32-bit vector representing a set of attribute filters
         associated with a tunnel any of which renders a link acceptable
         (with respect to this test).  A null set (all bits set to zero)
         automatically passes.

      Include-all

         A 32-bit vector representing a set of attribute filters
         associated with a tunnel all of which must be present for a
         link to be acceptable (with respect to this test).  A null set
         (all bits set to zero) automatically passes.

      Setup Priority

         The priority of the session with respect to taking resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         The Setup Priority is used in deciding whether this session can
         preempt another session.

Top      Up      ToC       Page 46 
      Holding Priority

         The priority of the session with respect to holding resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         Holding Priority is used in deciding whether this session can
         be preempted by another session.

      Flags

         0x01  Local protection desired

               This flag permits transit routers to use a local repair
               mechanism which may result in violation of the explicit
               route object.  When a fault is detected on an adjacent
               downstream link or node, a transit router can reroute
               traffic for fast service restoration.

         0x02  Label recording desired

               This flag indicates that label information should be
               included when doing a route record.

         0x04  SE Style desired

               This flag indicates that the tunnel ingress node may
               choose to reroute this tunnel without tearing it down.
               A tunnel egress node SHOULD use the SE Style when
               responding with a Resv message.

      Name Length

         The length of the display string before padding, in bytes.

      Session Name

         A null padded string of characters.

4.7.3. Procedures applying to both C-Types

   The support of setup and holding priorities is OPTIONAL.  A node can
   recognize this information but be unable to perform the requested
   operation.  The node SHOULD pass the information downstream
   unchanged.

   As noted above, preemption is implemented by two priorities.  The
   Setup Priority is the priority for taking resources.  The Holding
   Priority is the priority for holding a resource.  Specifically, the

Top      Up      ToC       Page 47 
   Holding Priority is the priority at which resources assigned to this
   session will be reserved.  The Setup Priority SHOULD never be higher
   than the Holding Priority for a given session.

   The setup and holding priorities are directly analogous to the
   preemption and defending priorities as defined in [9].  While the
   interaction of these two objects is ultimately a matter of policy,
   the following default interaction is RECOMMENDED.

   When both objects are present, the preemption priority policy element
   is used.  A mapping between the priority spaces is defined as
   follows.  A session attribute priority S is mapped to a preemption
   priority P by the formula P = 2^(14-2S).  The reverse mapping is
   shown in the following table.

         Preemption Priority     Session Attribute Priority

               0 - 3                         7
               4 - 15                        6
              16 - 63                        5
              64 - 255                       4
             256 - 1023                      3
            1024 - 4095                      2
            4096 - 16383                     1
           16384 - 65535                     0

   When a new Path message is considered for admission, the bandwidth
   requested is compared with the bandwidth available at the priority
   specified in the Setup Priority.

   If the requested bandwidth is not available a PathErr message is
   returned with an Error Code of 01, Admission Control Failure, and an
   Error Value of 0x0002.  The first 0 in the Error Value indicates a
   globally defined subcode and is not informational.  The 002 indicates
   "requested bandwidth unavailable".

   If the requested bandwidth is less than the unused bandwidth then
   processing is complete.  If the requested bandwidth is available, but
   is in use by lower priority sessions, then lower priority sessions
   (beginning with the lowest priority) MAY be preempted to free the
   necessary bandwidth.

   When preemption is supported, each preempted reservation triggers a
   TC_Preempt() upcall to local clients, passing a subcode that
   indicates the reason.  A ResvErr and/or PathErr with the code "Policy
   Control failure" SHOULD be sent toward the downstream receivers and
   upstream senders.

Top      Up      ToC       Page 48 
   The support of local-protection is OPTIONAL.  A node may recognize
   the local-protection Flag but may be unable to perform the requested
   operation.  In this case, the node SHOULD pass the information
   downstream unchanged.

   The recording of the Label subobject in the ROUTE_RECORD object is
   controlled by the label-recording-desired flag in the
   SESSION_ATTRIBUTE object.  Since the Label subobject is not needed
   for all applications, it is not automatically recorded.  The flag
   allows applications to request this only when needed.

   The contents of the Session Name field are a string, typically of
   display-able characters.  The Length MUST always be a multiple of 4
   and MUST be at least 8.  For an object length that is not a multiple
   of 4, the object is padded with trailing NULL characters.  The Name
   Length field contains the actual string length.

4.7.4. Resource Affinity Procedures

   Resource classes and resource class affinities are described in [3].
   In this document we use the briefer term resource affinities for the
   latter term.  Resource classes can be associated with links and
   advertised in routing protocols.  Resource class affinities are used
   by RSVP in two ways.  In order to be validated a link MUST pass the
   three tests below.  If the test fails a PathErr with the code "policy
   control failure" SHOULD be sent.

   When a new reservation is considered for admission over a strict node
   in an ERO, a node MAY validate the resource affinities with the
   resource classes of that link.  When a node is choosing links in
   order to extend a loose node of an ERO, the node MUST validate the
   resource classes of those links against the resource affinities.  If
   no acceptable links can be found to extend the ERO, the node SHOULD
   send a PathErr message with an error code of "Routing Problem" and an
   error value of "no route available toward destination".

   In order to be validated a link MUST pass the following three tests.

   To precisely describe the tests use the definitions in the object
   description above.  We also define

      Link-attr      A 32-bit vector representing attributes associated
                     with a link.

Top      Up      ToC       Page 49 
   The three tests are

      1. Exclude-any

         This test excludes a link from consideration if the link
         carries any of the attributes in the set.

         (link-attr & exclude-any) == 0

      2. Include-any

         This test accepts a link if the link carries any of the
         attributes in the set.

         (include-any == 0) | ((link-attr & include-any) != 0)

      3. Include-all

         This test accepts a link only if the link carries all of the
         attributes in the set.

         (include-all == 0) | (((link-attr & include-all) ^ include-
         all) == 0)

   For a link to be acceptable, all three tests MUST pass.  If the test
   fails, the node SHOULD send a PathErr message with an error code of
   "Routing Problem" and an error value of "no route available toward
   destination".

   If a Path message contains multiple SESSION_ATTRIBUTE objects, only
   the first SESSION_ATTRIBUTE object is meaningful.  Subsequent
   SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.

   All RSVP routers, whether they support the SESSION_ATTRIBUTE object
   or not, SHALL forward the object unmodified.  The presence of non-
   RSVP routers anywhere between senders and receivers has no impact on
   this object.

5. Hello Extension

   The RSVP Hello extension enables RSVP nodes to detect when a
   neighboring node is not reachable.  The mechanism provides node to
   node failure detection.  When such a failure is detected it is
   handled much the same as a link layer communication failure.  This
   mechanism is intended to be used when notification of link layer
   failures is not available and unnumbered links are not used, or when
   the failure detection mechanisms provided by the link layer are not
   sufficient for timely node failure detection.

Top      Up      ToC       Page 50 
   It should be noted that node failure detection is not the same as a
   link failure detection mechanism, particularly in the case of
   multiple parallel unnumbered links.

   The Hello extension is specifically designed so that one side can use
   the mechanism while the other side does not.  Neighbor failure
   detection may be initiated at any time.  This includes when neighbors
   first learn about each other, or just when neighbors are sharing Resv
   or Path state.

   The Hello extension is composed of a Hello message, a HELLO REQUEST
   object and a HELLO ACK object.  Hello processing between two
   neighbors supports independent selection of, typically configured,
   failure detection intervals.  Each neighbor can autonomously issue
   HELLO REQUEST objects.  Each request is answered by an
   acknowledgment.  Hello Messages also contain enough information so
   that one neighbor can suppress issuing hello requests and still
   perform neighbor failure detection.  A Hello message may be included
   as a sub-message within a bundle message.

   Neighbor failure detection is accomplished by collecting and storing
   a neighbor's "instance" value.  If a change in value is seen or if
   the neighbor is not properly reporting the locally advertised value,
   then the neighbor is presumed to have reset.  When a neighbor's value
   is seen to change or when communication is lost with a neighbor, then
   the instance value advertised to that neighbor is also changed.  The
   HELLO objects provide a mechanism for polling for and providing an
   instance value.  A poll request also includes the sender's instance
   value.  This allows the receiver of a poll to optionally treat the
   poll as an implicit poll response.  This optional handling is an
   optimization that can reduce the total number of polls and responses
   processed by a pair of neighbors.  In all cases, when both sides
   support the optimization the result will be only one set of polls and
   responses per failure detection interval.  Depending on selected
   intervals, the same benefit can occur even when only one neighbor
   supports the optimization.

5.1. Hello Message Format

   Hello Messages are always sent between two RSVP neighbors.  The IP
   source address is the IP address of the sending node.  The IP
   destination address is the IP address of the neighbor node.

   The HELLO mechanism is intended for use between immediate neighbors.
   When HELLO messages are being the exchanged between immediate
   neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be
   set to 1.

Top      Up      ToC       Page 51 
   The Hello message has a Msg Type of 20.  The Hello message format is
   as follows:

      <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                              <HELLO>

5.2. HELLO Object formats

   The HELLO Class is 22.  There are two C_Types defined.

5.2.1. HELLO REQUEST object

   Class = HELLO Class, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Src_Instance                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Dst_Instance                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.2. HELLO ACK object

   Class = HELLO Class, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Src_Instance                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Dst_Instance                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Src_Instance: 32 bits

      a 32 bit value that represents the sender's instance.  The
      advertiser maintains a per neighbor representation/value.  This
      value MUST change when the sender is reset, when the node reboots,
      or when communication is lost to the neighboring node and
      otherwise remains the same.  This field MUST NOT be set to zero
      (0).

      Dst_Instance: 32 bits

      The most recently received Src_Instance value received from the
      neighbor.  This field MUST be set to zero (0) when no value has
      ever been seen from the neighbor.

Top      Up      ToC       Page 52 
5.3. Hello Message Usage

   The Hello Message is completely OPTIONAL.  All messages may be
   ignored by nodes which do not wish to participate in Hello message
   processing.  The balance of this section is written assuming that the
   receiver as well as the sender is participating.  In particular, the
   use of MUST and SHOULD with respect to the receiver applies only to a
   node that supports Hello message processing.

   A node periodically generates a Hello message containing a HELLO
   REQUEST object for each neighbor who's status is being tracked.  The
   periodicity is governed by the hello_interval.  This value MAY be
   configured on a per neighbor basis.  The default value is 5 ms.

   When generating a message containing a HELLO REQUEST object, the
   sender fills in the Src_Instance field with a value representing it's
   per neighbor instance.  This value MUST NOT change while the agent is
   exchanging Hellos with the corresponding neighbor.  The sender also
   fills in the Dst_Instance field with the Src_Instance value most
   recently received from the neighbor.  For reference, call this
   variable Neighbor_Src_Instance.  If no value has ever been received
   from the neighbor or this node considers communication to the
   neighbor to have been lost, the Neighbor_Src_Instance is set to zero
   (0).  The generation of a message SHOULD be suppressed when a HELLO
   REQUEST object was received from the destination node within the
   prior hello_interval interval.

   On receipt of a message containing a HELLO REQUEST object, the
   receiver MUST generate a Hello message containing a HELLO ACK object.
   The receiver SHOULD also verify that the neighbor has not reset.
   This is done by comparing the sender's Src_Instance field value with
   the previously received value.  If the Neighbor_Src_Instance value is
   zero, and the Src_Instance field is non-zero, the
   Neighbor_Src_Instance is updated with the new value.  If the value
   differs or the Src_Instance field is zero, then the node MUST treat
   the neighbor as if communication has been lost.

   The receiver of a HELLO REQUEST object SHOULD also verify that the
   neighbor is reflecting back the receiver's Instance value.  This is
   done by comparing the received Dst_Instance field with the
   Src_Instance field value most recently transmitted to that neighbor.
   If the neighbor continues to advertise a wrong non-zero value after a
   configured number of intervals, then the node MUST treat the neighbor
   as if communication has been lost.

   On receipt of a message containing a HELLO ACK object, the receiver
   MUST verify that the neighbor has not reset.  This is done by
   comparing the sender's Src_Instance field value with the previously

Top      Up      ToC       Page 53 
   received value.  If the Neighbor_Src_Instance value is zero, and the
   Src_Instance field is non-zero, the Neighbor_Src_Instance is updated
   with the new value.  If the value differs or the Src_Instance field
   is zero, then the node MUST treat the neighbor as if communication
   has been lost.

   The receiver of a HELLO ACK object MUST also verify that the neighbor
   is reflecting back the receiver's Instance value.  If the neighbor
   advertises a wrong value in the Dst_Instance field, then a node MUST
   treat the neighbor as if communication has been lost.

   If no Instance values are received, via either REQUEST or ACK
   objects, from a neighbor within a configured number of
   hello_intervals, then a node MUST presume that it cannot communicate
   with the neighbor.  The default for this number is 3.5.

   When communication is lost or presumed to be lost as described above,
   a node MAY re-initiate HELLOs.  If a node does re-initiate it MUST
   use a Src_Instance value different than the one advertised in the
   previous HELLO message.  This new value MUST continue to be
   advertised to the corresponding neighbor until a reset or reboot
   occurs, or until another communication failure is detected.  If a new
   instance value has not been received from the neighbor, then the node
   MUST advertise zero in the Dst_instance value field.

5.4. Multi-Link Considerations

   As previously noted, the Hello extension is targeted at detecting
   node failures not per link failures.  When there is only one link
   between neighboring nodes or when all links between a pair of nodes
   fail, the distinction between node and link failures is not really
   meaningful and handling of such failures has already been covered.
   When there are multiple links shared between neighbors, there are
   special considerations.  When the links between neighbors are
   numbered, then Hellos MUST be run on each link and the previously
   described mechanisms apply.

   When the links are unnumbered, link failure detection MUST be
   provided by some means other than Hellos.  Each node SHOULD use a
   single Hello exchange with the neighbor.  The case where all links
   have failed, is the same as the no received value case mentioned in
   the previous section.

Top      Up      ToC       Page 54 
5.5. Compatibility

   The Hello extension does not affect the processing of any other RSVP
   message.  The only effect is to allow a link (node) down event to be
   declared sooner than it would have been.  RSVP response to that
   condition is unchanged.

   The Hello extension is fully backwards compatible.  The Hello class
   is assigned a class value of the form 0bbbbbbb.  Depending on the
   implementation, implementations that do not support the extension
   will either silently discard Hello messages or will respond with an
   "Unknown Object Class" error.  In either case the sender will fail to
   see an acknowledgment for the issued Hello.

6. Security Considerations

   In principle these extensions to RSVP pose no security exposures over
   and above RFC 2205[1].  However, there is a slight change in the
   trust model.  Traffic sent on a normal RSVP session can be filtered
   according to source and destination addresses as well as port
   numbers.  In this specification, filtering occurs only on the basis
   of an incoming label.  For this reason an administration may wish to
   limit the domain over which LSP tunnels can be established.  This can
   be accomplished by setting filters on various ports to deny action on
   a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7)
   or LSP_TUNNEL_IPv6 (8).

7. IANA Considerations

   IANA assigns values to RSVP protocol parameters.  Within the current
   document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are
   defined.  Each of these objects contain subobjects.  This section
   defines the rules for the assignment of subobject numbers.  This
   section uses the terminology of BCP 26 "Guidelines for Writing an
   IANA Considerations Section in RFCs" [15].

   EXPLICIT_ROUTE Subobject Type

      EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies
      the function of the subobject.  There are no range restrictions.
      All possible values are available for assignment.

      Following the policies outlined in [15], subobject types in the
      range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus
      action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as
      First Come First Served, and codes in the range 96 - 127 (0x60 -
      0x7F) are reserved for Private Use.

Top      Up      ToC       Page 55 
   ROUTE_RECORD Subobject Type

      ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
      function of the subobject.  There are no range restrictions.  All
      possible values are available for assignment.

      Following the policies outlined in [15], subobject types in the
      range 0 - 127 (0x00 - 0x7F) are allocated through an IETF
      Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are
      allocated as First Come First Served, and codes in the range 192 -
      255 (0xC0 - 0xFF) are reserved for Private Use.

      The following assignments are made in this document.

7.1. Message Types

   Message Message
   Number  Name

     20    Hello

7.2. Class Numbers and C-Types

   Class   Class
   Number  Name

     1     SESSION

           Class Types or C-Types:

                  7       LSP Tunnel IPv4
                  8       LSP Tunnel IPv6

     10    FILTER_SPEC

           Class Types or C-Types:

                  7       LSP Tunnel IPv4
                  8       LSP Tunnel IPv6

     11    SENDER_TEMPLATE

           Class Types or C-Types:

                  7       LSP Tunnel IPv4
                  8       LSP Tunnel IPv6

Top      Up      ToC       Page 56 
     16    RSVP_LABEL

           Class Types or C-Types:

                  1       Type 1 Label

     19    LABEL_REQUEST

           Class Types or C-Types:

                  1       Without Label Range
                  2       With ATM Label Range
                  3       With Frame Relay Label Range

     20    EXPLICIT_ROUTE

           Class Types or C-Types:

                  1       Type 1 Explicit Route

     21    ROUTE_RECORD

           Class Types or C-Types:

                  1       Type 1 Route Record

     22    HELLO

           Class Types or C-Types:

                  1       Request
                  2       Acknowledgment


    207    SESSION_ATTRIBUTE

           Class Types or C-Types:

                  1       LSP_TUNNEL_RA
                  7       LSP Tunnel

Top      Up      ToC       Page 57 
7.3. Error Codes and Globally-Defined Error Value Sub-Codes

   The following list extends the basic list of Error Codes and Values
   that are defined in [RFC2205].

   Error Code    Meaning

     24          Routing Problem

                 This Error Code has the following globally-defined
                 Error Value sub-codes:

                  1       Bad EXPLICIT_ROUTE object
                  2       Bad strict node
                  3       Bad loose node
                  4       Bad initial subobject
                  5       No route available toward
                           destination
                  6       Unacceptable label value
                  7       RRO indicated routing loops
                  8       MPLS being negotiated, but a
                          non-RSVP-capable router stands
                            in the path
                  9       MPLS label allocation failure
                 10       Unsupported L3PID

     25          Notify Error

                This Error Code has the following globally-defined
                Error Value sub-codes:

                  1       RRO too large for MTU
                  2       RRO Notification
                  3       Tunnel locally repaired

7.4. Subobject Definitions

   Subobjects of the EXPLICIT_ROUTE object with C-Type 1:

          1       IPv4 prefix
          2       IPv6 prefix
         32       Autonomous system number

Top      Up      ToC       Page 58 
   Subobjects of the RECORD_ROUTE object with C-Type 1:

          1       IPv4 address
          2       IPv6 address
          3       Label

8. Intellectual Property Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

9. Acknowledgments

   This document contains ideas as well as text that have appeared in
   previous Internet Drafts.  The authors of the current document wish
   to thank the authors of those drafts.  They are Steven Blake, Bruce
   Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun
   Viswanathan.  We also wish to thank Bora Akyol, Yoram Bernet and Alex
   Mondrus for their comments on this document.

10. References

   [1]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
        Specification", RFC 2205, September 1997.

   [2]  Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
        Switching Architecture", RFC 3031, January 2001.

   [3]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
        "Requirements for Traffic Engineering over MPLS", RFC 2702,
        September 1999.

   [4]  Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", RFC 2211, September 1997.

   [5]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
        Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
        January 2001.

   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [7]  Almquist, P., "Type of Service in the Internet Protocol Suite",
        RFC 1349, July 1992.

Top      Up      ToC       Page 59 
   [8]  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

   [9]  Herzog, S., "Signaled Preemption Priority Policy Element", RFC
        2751, January 2000.

   [10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
        for Extensions to RSVP for LSP-Tunnels", RFC 3210, December
        2001.

   [11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
        RFC 2210, September 1997.

   [12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        September 1981.

   [13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
        November 1990.

   [14] Conta, A. and S. Deering, "Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
        December 1998.

   [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null
        Service Type", RFC 2997, November 2000.

Top      Up      ToC       Page 60 
11. Authors' Addresses

   Daniel O. Awduche
   Movaz Networks, Inc.
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102
   Voice: +1 703-298-5291
   EMail: awduche@movaz.com


   Lou Berger
   Movaz Networks, Inc.
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102
   Voice: +1 703 847 1801
   EMail: lberger@movaz.com


   Der-Hwa Gan
   Juniper Networks, Inc.
   385 Ravendale Drive
   Mountain View, CA 94043
   EMail: dhg@juniper.net


   Tony Li
   Procket Networks
   3910 Freedom Circle, Ste. 102A
   Santa Clara CA 95054
   EMail: tli@procket.com


   Vijay Srinivasan
   Cosine Communications, Inc.
   1200 Bridge Parkway
   Redwood City, CA 94065
   Voice: +1 650 628 4892
   EMail: vsriniva@cosinecom.com


   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Voice: +1 978 244 8143
   EMail: swallow@cisco.com

Top      Up      ToC       Page 61 
12.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.