- an Upstream_Label object (to support bidirectional LSPs);
- a Label ERO subobject;
- IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in
out-of-band signaling or in bundled links);
- IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in
out-of-band signaling or in bundled links);
- an Acceptable Label Set object (to support negotiation of label
values in particular for bidirectional LSPs)
- a Notify Request object (may be inserted in a Path or Resv message
to indicate where a notification of LSP failure is to be sent)
- a Restart_Cap Object (used on Hello messages to identify recovery
capabilities)
- an Admin Status Object (to notify each node along the path of the
status of the LSP, and to control that state).
2.2.12. GMPLS Operation at UNI and E-NNI Reference Points
The ITU-T defines network reference points that separate
administrative or operational parts of the network. The reference
points are designated as:
- User to Network Interfaces (UNIs) if they lie between the user or
user network and the core network, or
- External Network to Network Interfaces (E-NNIs) if they lie between
peer networks, network domains, or subnetworks.
GMPLS is applicable to the UNI and E-NNI without further
modification, and no new messages, objects, or C-Types are required.
See [OVERLAY].
2.2.13. MPLS and GMPLS Future Extensions
At the time of writing, MPLS and GMPLS are being extended by the MPLS
and CCAMP Working Groups to support additional sophisticated
functions. This will inevitably lead to the introduction of new
C-Types for existing objects, and to the requirement for new objects
(CNums). It is possible that new messages will also be introduced.
Some of the key features and functions being introduced include the
following:
- Protection and restoration. Features will be developed to provide
- end-to-end protection
- segment protection
- various protection schemes (1+1, 1:1, 1:n)
- support of extra traffic on backup LSPs
- Diverse path establishment for protection and load sharing.
- Establishment of point-to-multipoint paths.
- Inter-area and inter-AS path establishment with
- explicit path control
- bandwidth reservation
- path diversity
- Support for the requirements of Automatic Switched Optical Network
(ASON) signaling as defined by the ITU-T, including call and
connection separation.
- Crankback during LSP setup.
2.2.14. ITU-T H.323 Interface
ITU-T H.323 ([H.323]) recommends the IntServ resource reservation
procedure using RSVP. The information as to whether an endpoint
supports RSVP should be conveyed during the H.245 [H.245] capability
exchange phase, by setting appropriate qOSMode fields. If both
endpoints are RSVP-capable, when opening an H.245 logical channel, a
receiver port ID should be conveyed to the sender by the
openLogicalChannelAck message. Only after that can a "Path - Resv -
ResvConf" process take place. The timer of waiting for ResvConf
message will be set by the endpoint. If this timer expires or RSVP
reservation fails at any point during an H.323 call, the action is up
to the vendor. Once a ResvConf message is sent or received, the
endpoints should stop reservation timers and resume with the H.323
call procedures. Only explicit release of reservations are supported
in [H.323]. Before sending a closeLogicalChannel message for a
stream, a sender should send a PathTear message if an RSVP session
has been previous created for that stream. After receiving a
closeLogicalChannel, a receiver should send a ResvTear similarly.
Only the FF style is supported, even for point-to-multipoint calls.
2.2.15. 3GPP Interface
Third Generation Partnership Project (3GPP) TS 23.207
([3GPP-TS23207]) specifies the QoS signaling procedure with policy
control within the Universal Mobile Telecommunications System (UMTS)
end-to-end QoS architecture. When using RSVP, the signaling source
and/or destination are the User Equipments (UEs, devices that allow
users access to network services) that locate in the Mobile
Originating (MO) side and the Mobile Terminating (MT) side. An RSVP
signaling process can either trigger or be triggered by the (COPS)
PDP Context establishment/modification process. The operation of
refreshing states is not specified in [3GPP-TS23207]. If a
bidirectional reservation is needed, the RSVP signaling exchange must
be performed twice between the end-points. The authorization token
and flow identifier(s) in a policy data object should be included in
the RSVP messages sent by the UE, if the token is available in the
UE. When both RSVP and Service-based Local Policy are used, the
Gateway GPRS Support Node (GGSN, the access point of the network)
should use the policy information to decide whether to accept and
forward Path/Resv messages.
2.3. Extensions for New Deployment Scenarios
As a well-acknowledged protocol in the Internet, RSVP is expected
more and more to provide a more generic service for various signaling
applications. However, RSVP messages were designed in a way to
support end-to-end QoS signaling optimally. To meet the increasing
demand that a signaling protocol also operate in host-to-edge and
edge-to-edge ways, and that it serve for some other signaling
purposes in addition to end-to-end QoS signaling, RSVP needs to be
made more flexible and applicable for more generic signaling.
RSVP proxies [BEGD02] extend RSVP by originating or receiving the
RSVP message on behalf of the end node(s), so that applications may
still benefit from reservations that are not truly end-to-end.
However, there are certainly scenarios where an application would
want to explicitly convey its non-QoS purposed (as well as QoS) data
from a host into the network, or from an ingress node to an egress
node of an administrative domain. It must do so without burdening
the network with excess messaging overhead. Typical examples are an
end host desiring a firewall service from its provider’s network and
MPLS label setup within an MPLS domain.
RSVP requires support from network routers and user space
applications. Domains not supporting RSVP are traversed
transparently. Unfortunately, like other IP options, RSVP messages
implemented by way of IP alert option may be dropped by some routers
[FJ02]. Although applications need to be built with RSVP libraries,
one article presents a mechanism that would allow any host to benefit
from RSVP mechanisms without applications’ awareness [MHS02].
A somewhat similar deployment benefit can be gained from the
Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the
concept of local RSVP-based reservation that alone can be used to
trigger reservation within an access network. In those cases, an
end-host may request QoS from its own access network without the
cooperation of a correspondent node outside the access network. This
would be especially helpful when the correspondent node is unaware of
RSVP. A proxy node responds to the messages sent by the end host and
enables both upstream and downstream reservations. Furthermore, the
scheme allows for faster reservation repairs following a handover by
triggering the proxy to assist in an RSVP local repair.
Still, in end-hosts that are low in processing power and
functionality, having an RSVP daemon run and take care of the
signaling may introduce unnecessary overhead. One article [Kars01]
proposes to create a remote API so that the daemon would in fact run
on the end-host’s default router and the end-host application would
send its requests to that daemon.
Another potential problem lies in the limited size of signaled data
due to the limitation of message size. An RSVP message must fit
entirely into a single non-fragmented IP datagram. Bundle messages
[RFC2961] can aggregate multiple RSVP messages within a single PDU,
but they still only occupy one IP datagram (i.e., approximately 64K).
If it exceeds the MTU, the datagram is fragmented by IP and
reassembled at the recipient node.
2.4. Conclusion
A good signaling protocol should be transparent to the applications.
RSVP has proven to be a very well designed protocol. However, it has
a number of fundamental protocol design issues that require more
careful re-evaluation.
The design of RSVP was originally targeted at multicast applications.
The result has been that the message processing within nodes is
somewhat heavy, mainly due to flow merging. Still, merging rules
should not appear in the specification as they are QoS-specific.
RSVP has a comprehensive set of filtering styles, including
Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE),
and is not tied to certain QoS objects. (RSVP is not tied to IntServ
Guaranteed Service/Controlled Load (GS/CL) specifications.) Objects
were designed to be modular, but Xspecs (TSPEC, etc.) are more or
less QoS-specific and should be more generalized; there is no clear
layering/separation between the signaled data and signaling protocol.
RSVP uses a soft state mechanism to maintain states and allows each
node to define its own refresh timer. The protocol is also
independent of underlying routing protocols. Still, in mobile
networks the movement of the mobile nodes may not properly trigger a
reservation refresh for the new path, and therefore a mobile node may
be left without a reservation up to the length of the refresh timer.
Furthermore, RSVP does not work properly with changing end-point
identifiers; that is, if one of the IP addresses of a mobile node
changes, the filters may not be able to identify the flow that had a
reservation.
From the security point of view, RSVP does provide the basic building
blocks for deploying the protocol in various environments to protect
its messages from forgery and modification. Hop-by-hop protection is
provided. However, the current RSVP security mechanism does not
provide non-repudiation and protection against message deletion; the
two-way peer authentication and key management procedures are still
missing.
Finally, since the publication of the RSVP standard, tens of
extensions have emerged that allow for much wider deployment than
RSVP was originally designed for -- for instance, the Subnet
Bandwidth Manager, the NULL service type, aggregation, operation over
tunneling, and MPLS, as well as diagnostic messages.
Domains not supporting RSVP are traversed transparently by default.
Unfortunately, like other IP options, RSVP messages implemented by
way of IP alert option may be dropped by some routers. Also, the
maximal size of RSVP message is limited.
The transport mechanisms, performance, security, and mobility issues
are detailed in the following sections.
3. RSVP Transport Mechanism Issues
3.1. Messaging Reliability
RSVP messages are defined as a new IP protocol (that is, a new ptype
in the IP header). RSVP Path messages must be delivered end-to-end.
For the transit routers to intercept the Path messages, a new IP
Router Alert option [RFC2113] was introduced. This design is simple
to implement and efficient to run. As shown from the experiments in
[PS00], with minor kernel changes IP option processing introduces
very little overhead on a Free BSD box.
However, RSVP does not have a good message delivery mechanism. If a
message is lost on the wire, the next re-transmit cycle by the
network would be one soft-state refresh interval later. By default,
a soft-state refresh interval is 30 seconds.
To overcome this problem, [PS97] introduced a staged refresh timer
mechanism, which has been defined as a RSVP extension in [RFC2961].
The staged refresh timer mechanism retransmits RSVP messages until
the receiving node acknowledges. It can address the reliability
problem in RSVP.
However, during the mechanism’s implementation, a lot of effort had
to be spent on per-session timer maintenance, message retransmission
(e.g., avoid message bursts), and message sequencing. In addition,
we have to make an effort to try to separate the transport functions
from protocol processing. For example, if a protocol extension
requires a natural RSVP session time-out (such as RSVP-TE one-to-one
fast-reroute [FAST-REROUTE]), we have to turn off the staged refresh
timers.
3.2. Message Packing
According to RSVP [RFC2205], each RSVP message can only contain
information for one session. In a network that has a reasonably
large number of RSVP sessions, this constraint imposes a heavy
processing burden on the routers. Many router OSes are based on
UNIX. [PS00] showed that the UNIX socket I/O processing is not very
sensitive to packet size. In fact, processing small packets takes
almost as much CPU overhead as processing large ones. However,
processing too many individual messages can easily cause congestion
at socket I/O interfaces.
To overcome this problem, RFC2961 introduced the message bundling
mechanism. The bundling mechanism packs multiple RSVP messages
between two adjacent nodes into a single packet. In one deployed
router platform, the bundling mechanism has improved the number of
RSVP sessions that a router can handle from 2,000 to over 7,000.
3.3. MTU Problem
RSVP does not support message fragmentation and reassembly at
protocol level. If the size of a RSVP message is larger than the
link MTU, the message will be fragmented. The routers simply cannot
detect and process RSVP message fragments.
There is no solution for the MTU problem. Fortunately, at places
where RSVP-TE has been used, either the amount of per-session RSVP
data is never too large, or the link MTU is adjustable; PPP and Frame
Relay can always increase or decrease the MTU sizes. For example, on
some routers, a Frame Relay interface can support a link MTU size up
to 9600 bytes. Currently, the RSVP MTU problem is not a realistic
concern in MPLS networks.
However, when and if RSVP is used for end-user applications, for
which network security is an essential and critical concern, it is
possible that the size of RSVP messages can be larger than the link
MTU. Note that end-users will most likely have to deal with a small
1500-byte Ethernet MTU.
3.4. RSVP-TE vs. Signaling Protocol for RT Applications
RSVP-TE works in an environment that is different from what the
original RSVP has been designed for: in MPLS networks, the RSVP
sessions that are used to support Label-Switched Paths (LSPs) do not
change frequently.
In fact, the network operators typically set up the MPLS LSPs so that
they cannot switch too quickly. For example, the operators often
regulate the Constraint-based Shortest Path First (CSPF) computation
interval to prevent or delay a large volume of user traffic from
shifting from one session to another during LSP path optimization.
(CSPF is a routing algorithm that operates from the network edge to
compute the "most" optimal routes for the LSPs.) As a result, RSVP-
TE does not have to handle a large amount of "triggered" (new or
modified) messages. Most of the messages are refresh messages,
which can be handled by the mechanisms introduced in RFC2961. In
particular, in the Summary Refresh extension [RFC2961], each RSVP
refresh message can be represented as a 4-byte ID. The routers can
simply exchange the IDs to refresh RSVP sessions. With the full
implementation of RFC2961, MPLS routers do not have any RSVP scaling
issue. On one deployed router platform, it can support over 50,000
RSVP sessions in a stable backbone network.
On the other hand, in many of the new applications for which a
signaling protocol is required, the user session duration can be
relatively short. The dynamics of adding/dropping user sessions
could introduce a large number of "triggered" messages in the
network. This can clearly introduce a substantial amount of
processing overhead to the routers. This is one area where a new
signaling protocol may be needed to reduce the processing complexity
in the resource reservation process.
3.5. What Would Be a Better Alternative?
A good signaling protocol should be transparent to the applications.
On the other hand, the design of a signaling protocol must take the
intended and potential applications into consideration.
With the addition of RFC2961, RSVP-TE is sufficient to support its
intended application, MPLS, within the backbone. There is no
significant transport-layer problem that needs to be solved.
In the last several years, a number of new applications have emerged
that are proposed to need IP signaling, beyond the traditional ones
associated with quality of service and resource allocation. On-path
firewall control/NAT traversal (synergistic with the midcom design of
[RFC3303]) is one of these. There are far-out applications such as
depositing active network code in network devices. Next-generation
signaling protocols dealing with novel applications, with network
security requirements, and with the MTU problems described above,
will prevent the re-use of the existing RSVP transport mechanism.
If a new transport protocol is needed, the protocol must be able to
handle the following:
- reliable messaging;
- message packing;
- the MTU problem;
- small triggered message volume.
4. RSVP Protocol Performance Issues
4.1. Processing Overhead
By "processing overhead" we mean the amount of processing required to
handle messages belonging to a reservation session. This is the
processing required in addition to the processing needed for routing
an (ordinary) IP packet. The processing overhead of RSVP originates
from two major issues:
1) Complexity of the protocol elements. First, RSVP itself is per-
flow based; thus the number of states is proportional to RSVP
session number. Path and Resv states have to be maintained in
each RSVP router for each session (and Path state also has to
record the reverse route for the correspondent Resv message).
Second, being receiver-initiated, RSVP optimizes various merging
operations for multicast reservations while the Resv message is
processed. To handle multicast, other mechanisms such as
reservation styles, scope object, and blockade state, are also
required to be presented in the basic protocol. This not only
adds sources of failures and errors, but also complicates the
state machine [Fu02]. Third, the same RSVP signaling messages are
used not only for maintaining the state, but also for dealing with
recovery of signaling message loss and discovery of route change.
Thus, although protocol elements that represent the actual data
(e.g., QoS parameters) specification are separated from signaling
elements, the processing overhead needed for all RSVP messages is
not marginal. Finally, the possible variations of the order and
existence of objects increases the complexity of message parsing
and internal message and state representation.
2) Implementation-specific Overhead. There are two ways to send and
receive RSVP messages: either as "raw" IP datagrams with protocol
number 46, or as encapsulated UDP datagrams, which increase the
efficiency of RSVP processing. Typical RSVP implementations are
user-space daemons interacting with the kernel; thus, state
management, message sending, and reception would affect the
efficiency of the protocol processing. For example, in the recent
version of the implementation described in [KSS01], the relative
execution costs for the message sending/reception system calls
"sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%,
individually, of the total execution cost. [KSS01] also found
that state (memory) management can use up to 17-18% of the total
execution cost, but it is possible to decrease that cost to 6-7%,
if appropriate action is taken to replace the standard memory
management with dedicated memory management for state information.
RSVP/routing, RSVP/policy control, and RSVP/traffic control
interfaces can also pose different overhead depending on
implementation. For example, the RSVP/routing overhead has been
measured to be approximately 11-12% of the total execution cost
[KSS01].
4.2. Bandwidth Consumption
By "bandwidth consumption" we mean the amount of bandwidth used
during the lifetime of a session: to set up a reservation session, to
keep the session alive, and finally to close it.
RSVP messages are sent either to trigger a new reservation or to
refresh an existing reservation. In standard RSVP, Path/Resv
messages are used for triggering and refreshing/recovering
reservations, identically, which results in an increased size of
refresh messages. The hop-by-hop refreshment may reduce the
bandwidth consumption for RSVP, but could result in more sources of
error/failure events. [RFC2961] presents a way to bundle standard
RSVP messages and reduces the refreshment redundancy by Srefresh
message.
Thus, the following formula represents the bandwidth consumption in
bytes for an RSVP session lasting n seconds:
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
bP: IP payload size of Path message
bR: IP payload size of Resv message
bPt: IP payload size of Path Tear message
Ri: refresh interval
For example, for a simple Controlled Load reservation without
security and identification requirements (where bP is 172 bytes, bR
is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth
consumption would be as follows:
F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
= 308 + (264n/30) bytes
5. RSVP Security and Mobility
5.1. Security
To allow a process on a system to securely identify the owner and the
application of the communicating process (e.g., user id) and to
convey this information in RSVP messages (PATH or RESV) in a secure
manner, [RFC3182] specifies the encoding of identities as RSVP
POLICY_DATA Object. However, to provide ironclad security
protection, cryptographic authentication combined with authorization
has to be provided. Such a functionality is typically offered by
authentication and key exchange protocols. Solely including a user
identifier is insufficient.
To provide hop-by-hop integrity and authentication of RSVP messages,
an RSVP message may contain an INTEGRITY object ([RFC2747]) using a
keyed message digest. Since intermediate routers need to modify and
process the content of the signaling message, a hop-by-hop security
architecture based on a chain-of-trust is used. However, with the
different usage of RSVP as described throughout this document and
with new requirements, a re-evaluation of the original assumptions
might be necessary.
RFC2747 provides protection against forgery and message modification.
However, this does not provide non-repudiation or protect against
message deletion. In the current RSVP security scheme, the two-way
peer authentication and key management procedures are still missing.
The security issues have been well analyzed in [Tsch03].
5.2. Mobility Support
Two issues raise concern when a mobile node (MN) uses RSVP: the flow
identifier and reservation refresh. When an MN changes locations, it
may need to change one of its assigned IP addresses. An MN may have
an IP address by which it is reachable by nodes outside the access
network, and an IP address used to support local mobility management.
Depending on the mobility management mechanism, a handover may force
a change in any of these addresses. As a consequence, the filters
associated with a reservation may not identify the flow anymore, and
the resource reservation is ineffective until a refresh with a new
set of filters is initialized.
The second issue relates to following the movement of a mobile node.
RFC2205 defines that Path messages can perform a local repair of
reservation paths. When the route between the communicating end
hosts changes, a Path message will set the state of the reservation
on the new route, and a subsequent Resv message will make the
resource reservation. Therefore, by sending a Resv message a host
cannot alone update the reservation, and thus it cannot perform a
local repair before a Path message has passed. Also, in order to
provide fast adaptation to routing changes without the overhead of