Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 3209

RSVP-TE: Extensions to RSVP for LSP Tunnels

Pages: 61
Proposed Standard
Errata
Updated by:  393644204874515154205711678067907274
Part 3 of 3 – Pages 43 to 61
First   Prev   None

Top   ToC   RFC3209 - Page 43   prevText

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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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.