RFC 3210 (rfc3210) - Page 3 of 8

Applicability Statement for Extensions to RSVP for LSP-Tunnels

RFC 3210        Applicability Statement for Extensions     December 2001


     (5) tracking of the actual route traversed by an LSP-tunnel
     (6) diagnostics on LSP-tunnels
     (7) the concept of nodal abstraction
     (8) preemption options that are administratively controllable

   The RSVP-TE specification introduces several new RSVP objects,
   including the LABEL-REQUEST object, the RECORD-ROUTE object, the
   LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects.
   New error messages are defined to provide notification of exception
   conditions.  All of the new objects defined in RSVP-TE are optional
   with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL
   objects, which are both mandatory for the establishment of LSP-
   tunnels.

   Two fundamental aspects distinguish the RSVP-TE specification [1]
   from the original RSVP protocol [3].

   The first distinguishing aspect is the fact that the RSVP-TE
   specification [1] is intended for use by label switching routers (as
   well as hosts) to establish and maintain LSP-tunnels and to reserve
   network resources for such LSP-tunnels.  The original RSVP
   specification [3], on the other hand, was intended for use by hosts
   to request and reserve network resources for micro-flows.

   The second distinguishing aspect is the fact that the RSVP-TE
   specification generalizes the concept of "RSVP flow." The RSVP-TE
   specification essentially allows an RSVP session to consist of an
   arbitrary aggregation of traffic (based on local policies) between
   the originating node of an LSP-tunnel and the egress node of the
   tunnel.  To be definite, in the original RSVP protocol [3], a session
   was defined as a data flow with a particular destination and
   transport layer protocol.  In the RSVP-TE specification, however, a
   session is implicitly defined as the set of packets that are assigned
   the same MPLS label value at the originating node of an LSP-tunnel.
   The assignment of labels to packets can be based on various criteria,
   and may even encompass all packets (or subsets thereof) between the
   endpoints of the LSP-tunnel.  Because traffic is aggregated, the
   number of LSP-tunnels (hence the number of RSVP sessions) does not
   increase proportionally with the number of flows in the network.
   Therefore, the RSVP-TE specification [1] addresses a major scaling
   issue with the original RSVP protocol [3], namely the large amount of
   system resources that would otherwise be required to manage
   reservations and maintain state for potentially thousands or even
   millions of RSVP sessions at the micro-flow granularity.

   The reader is referred to [1] for a technical description of the
   RSVP-TE protocol specification.




Awduche, et. al.             Informational