RFC 3210 (rfc3210) - Page 3 of 8
Applicability Statement for Extensions to RSVP for LSP-Tunnels
Alternative Format: Original Text Document
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