Request for Comments: 4094 X. Fu
Category: Informational May 2005
Analysis of Existing Quality-of-Service Signaling Protocols
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document reviews some of the existing Quality of Service (QoS)
signaling protocols for an IP network. The goal here is to learn
from them and to avoid common misconceptions. Further, we need to
avoid mistakes during the design and implementation of any new
protocol in this area.
Table of Contents
1. Introduction ....................................................3
2. RSVP and RSVP Extensions ........................................4
2.1. Basic Design ...............................................4
2.1.1. Signaling Model .....................................4
2.1.2. Soft State ..........................................5
2.1.3. Two-Pass Signaling Message Exchanges ................5
2.1.4. Receiver-Based Resource Reservation .................5
2.1.5. Separation of QoS Signaling from Routing ............5
2.2. RSVP Extensions ............................................6
2.2.1. Simple Tunneling ....................................6
2.2.2. IPsec Interface .....................................6
2.2.3. Policy Interface ....................................6
2.2.4. Refresh Reduction ...................................7
2.2.5. RSVP over RSVP ......................................8
2.2.6. IEEE 802-Style LAN Interface ........................8
2.2.7. ATM Interface .......................................9
2.2.8. DiffServ Interface ..................................9
2.2.9. Null Service Type ...................................9
2.2.10. MPLS Traffic Engineering ..........................10
2.2.11. GMPLS and RSVP-TE .................................11
2.2.12. GMPLS Operation at UNI and E-NNI Reference
Points ............................................12
2.2.13. MPLS and GMPLS Future Extensions ..................12
2.2.14. ITU-T H.323 Interface .............................13
2.2.15. 3GPP Interface ....................................13
2.3. Extensions for New Deployment Scenarios ...................14
2.4. Conclusion ................................................15
3. RSVP Transport Mechanism Issues ................................16
3.1. Messaging Reliability .....................................16
3.2. Message Packing ...........................................17
3.3. MTU Problem ...............................................17
3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
3.5. What Would Be a Better Alternative? .......................18
4. RSVP Protocol Performance Issues ...............................19
4.1. Processing Overhead .......................................19
4.2. Bandwidth Consumption .....................................20
5. RSVP Security and Mobility .....................................21
5.1. Security ..................................................21
5.2. Mobility Support ..........................................22
6. Other QoS Signaling Proposals ..................................23
6.1. Tenet and ST-II ...........................................23
6.2. YESSIR ....................................................24
6.2.1. Reservation Functionality ..........................24
6.2.2. Conclusion .........................................25
6.3. Boomerang .................................................25
6.3.1. Reservation Functionality ..........................25
6.3.2. Conclusions ........................................26
6.4. INSIGNIA ..................................................26
7. Inter-Domain Signaling .........................................27
7.1. BGRP ......................................................27
7.2. SICAP .....................................................27
7.3. DARIS .....................................................28
8. Security Considerations ........................................30
9. Summary ........................................................30
10. Contributors ..................................................31
11. Acknowledgements ..............................................31
12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
13. Normative References ..........................................38
14. Informative References ........................................38
1. Introduction
This document reviews some of the existing QoS signaling protocols
for an IP network. The goal here is to learn from them and to avoid
common misconceptions. Further, we need to avoid mistakes during the
design and implementation of any new protocol in this area.
There have been a number of historic attempts to deliver QoS or
generic signaling to the Internet. In the early years, it was
believed that multicast would be popular for the majority of
communications; thus, both RSVP and earlier ST-II were designed in a
way that is multicast-oriented.
ST-II was developed as a reservation protocol for point-to-multipoint
communication. However, since it is sender-initiated, it does not
scale with the number of receivers in a multicast group. Its
processing is fairly complex. Since every sender needs to set up its
own reservation, the total amount of reservation states is large.
RSVP was then designed to provide support for multipoint-to-
multipoint reservation setup in a more efficient way. However, its
complexity, scalability, and ability to meet new requirements have
been criticized.
YESSIR (YEt another Sender Session Internet Reservations) [PS98] and
Boomerang [FNM+99] are examples of protocols designed after RSVP.
Both were meant to be simpler than RSVP. YESSIR is an extension to
RTCP, whereas Boomerang is used with ICMP.
Previously, a lot of work has been targeted at creating a new
signaling protocol for resource control. Istvan Cselenyi suggested
having a QoSSIG BOF in IETF47, for identifying problems in QoS
signaling, but failed to get enough support [URL1]. Some people
argued, "in many ways, RSVP improved upon ST-2, and it did start out
simpler, but it resulted in a design with complexity and
scalability", while others thought that "new knowledge and
requirements" made RSVP insufficient. Some concluded that there is
no simpler way to handle the same problem than RSVP.
Michael Welzl organized a special session "ABR to the Internet" in
SCI 2001, and gathered some inputs for requesting an "ABR to the
Internet" BOF in IETF#51, which was intended to introduce explicit
rate-feedback-related mechanisms for the Internet (e2e, edge2edge).
This failed because of "missing community interest".
OPENSIG [URL2] has been involved in the Internet signaling for years.
Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate
lightweight Internet signaling. Finally, NSIS BOF was successful,
and the NSIS WG was formed.
The most mature and original protocols are presented in their own
sections, and other QoS signaling protocols are presented in later
subsections. The presented protocols are chosen based on relevance
to the work within NSIS. The aim is not to review every existing
protocol.
2. RSVP and RSVP Extensions
RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96]
has evolved from ST-II to provide end-to-end QoS signaling services
for application data streams. Hosts use RSVP to request a specific
quality of service (QoS) from the network for particular application
flows. Routers use RSVP to deliver QoS requests to all routers along
the data path. RSVP also can maintain and refresh states for a
requested QoS application flow.
By original design, RSVP fits well into the framework of the
Integrated Services (IntServ) [RFC2210] [BEBH96] with certain
modularity and scalability.
RSVP carries QoS signaling messages through the network, visiting
each node along the data path. To make a resource reservation at a
node, the RSVP module communicates with two local decision modules,
admission control and policy control. Admission control determines
whether the node has sufficient available resources to supply the
requested QoS. Policy control provides authorization for the QoS
request. If either check fails, the RSVP module returns an error
notification to the application process that originated the request.
If both checks succeed, the RSVP module sets parameters in a packet
classifier and packet scheduler to obtain the desired QoS.
2.1. Basic Design
The design of RSVP distinguished itself by a number of fundamental
ways; particularly, soft state management, two-pass signaling message
exchanges, receiver-based resource reservation, and separation of QoS
signaling from routing.
2.1.1. Signaling Model
The RSVP signaling model is based on a special handling of multicast.
The sender of a multicast flow advertises the traffic characteristics
periodically to the receivers via "Path" messages. Upon receipt of
an advertisement, a receiver may generate a "Resv" message to reserve
resources along the flow path from the sender. Receiver reservations
may be heterogeneous. To accommodate the multipoint-to-multipoint
multicast applications, RSVP was designed to support a vector of
reservation attributes called the "style". A style describes whether
all senders of a multicast group share a single reservation and which
receiver is applied. The "Scope" object additionally provides the
explicit list of senders.
2.1.2. Soft State
Because the number of receivers in a multicast flow is likely to
change, and the flow of delivery paths might change during the life
of an application flow, RSVP takes a soft-state approach in its
design, creating and removing the protocol states (Path and Resv
states) in routers and hosts incrementally over time. RSVP sends
periodic refresh messages (Path and Resv) to maintain its states and
to recover from occasional lost messages. In the absence of refresh
messages, the RSVP states automatically time out and are deleted.
States may also be deleted explicitly by PathTear, PathErr with
Path_State_Removed flag, or ResvTear Message.
2.1.3. Two-Pass Signaling Message Exchanges
The receiver in an application flow is responsible for requesting the
desired QoS from the sender. To do this, the receiver issues an RSVP
QoS request on behalf of the local application. The request
propagates to all routers in reverse direction of the data paths
toward the sender. In this process, RSVP requests might be merged,
resulting in a protocol that scales well when there are a large
number of receivers.
2.1.4. Receiver-Based Resource Reservation
Receiver-initiation is critical for RSVP to set up multicast sessions
with a large number of heterogeneous receivers. A receiver initiates
a reservation request at a leaf of the multicast distribution tree,
traveling toward the sender. Whenever a reservation is found to
already exist in a node in the distribution tree, the new request
will be merged with the existing reservation. This could result in
fewer signaling operations for the RSVP nodes in the multicast tree
close to the sender but could introduce a restriction to receiver-
initiation.
2.1.5. Separation of QoS Signaling from Routing
RSVP messages follow normal IP routing. RSVP is not a routing
protocol, but rather is designed to operate with current and future
unicast and multicast routing protocols. The routing protocols are
responsible for choosing the routes to use to forward packets, and
RSVP consults local routing tables to obtain routes. RSVP is
responsible only for reservation setup along a data path.
A number of messages and objects have been defined for the protocol.
A detailed description is given in [RFC2205].
2.2. RSVP Extensions
RSVP [RFC2205] was originally designed to support real-time
applications over the Internet. Over the past several years, the
demand for multicast-capable real-time teleconferencing, which many
people had envisioned to be one of the key Internet applications that
could benefit from network-wide deployment of RSVP, has never
materialized. Instead, RSVP-TE [RFC3209], a RSVP extension for
traffic engineering, has been widely deployed by a large number of
network providers to support MPLS applications.
There are a large number of protocol extensions based on RSVP. Some
provide additional features, such as security and scalability, to the
original protocol. Some introduce additional interfaces to other
services, such as DiffServ. And some simply define new applications,
such as MPLS and GMPLS, that are completely irrelevant from
protocol’s original intent.
In this section, we list only IETF-based RFCs and a limited set of
other organizations’ specifications. Informational RFCs (e.g.,
RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not
covered here.
2.2.1. Simple Tunneling
[RFC2746] describes an IP tunneling enhancement mechanism that allows
RSVP to make reservations across all IP-in-IP tunnels, basically by
recursively applying RSVP over the tunnel portion of the path.
2.2.2. IPsec Interface
RSVP can support IPsec on a per-address, per-protocol basis instead
of on a per flow basis. [RFC2207] extends RSVP by using the IPsec
Security Parameter Index (SPI) in place of the UDP/TCP-like ports.
This introduces a new FILTER_SPEC object, which contains the IPsec
SPI, and a new SESSION object.
2.2.3. Policy Interface
[RFC2750] specifies the format of POLICY_DATA objects and RSVP’s
handling of policy events. It introduces objects that are
interpreted only by policy-aware nodes (PEPs) that interact with
policy decision points (PDPs). Nodes that are unable to interpret
the POLICY_DATA objects are called policy-ignorant nodes (PINs). The
content of the POLICY_DATA object itself is protected only between
PEPs and therefore provides end-to-middle or middle-to-middle
security.
[RFC2749] specifies the usage of COPS policy services in RSVP
environments. [RFC3181] specifies a preemption priority policy
element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object.
[RFC3520] describes how authorization provided by a separate protocol
(such as SIP) can be reused with the help of an authorization token
within RSVP. The token might therefore contain either the authorized
information itself (e.g., QoS parameters) or a reference to those
values. The token might be unprotected (which is strongly
discouraged) or protected based on symmetric or asymmetric
cryptography. Moreover, the document describes how to provide the
host with encoded session authorization information as a POLICY_DATA
object.
2.2.4. Refresh Reduction
[RFC2961] describes mechanisms to reduce processing overhead
requirements of refresh messages, eliminate the state synchronization
latency incurred when an RSVP message is lost, and refresh state
without the transmission of whole refresh messages. It defines the
following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK,
MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST
objects. Three new RSVP message types are defined:
1) Bundle messages consist of a bundle header followed by a body
consisting one or more standard RSVP messages. Bundle messages
help in scaling RSVP to reduce processing overhead and bandwidth
consumption.
2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK
objects. ACK messages are sent between neighboring RSVP nodes to
detect message loss and to support reliable RSVP message delivery
on a per-hop basis.
3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
SRC_LIST, and MESSAGE_ID MCAST_LIST objects. They correspond to
Path and Resv messages that establish the states. Srefresh
messages are used to refresh RSVP states without transmitting
standard Path or Resv messages.
2.2.5. RSVP over RSVP
[RFC3175] allows installation of one or more aggregated reservations
in an aggregation region; thus, the number of individual RSVP
sessions can be reduced. The protocol type is swapped from RSVP to
RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf
messages when they enter the aggregation region, and is swapped back
when they leave. In addition to a new PathErr code
(NEW_AGGREGATE_NEEDED), three new objects are introduced:
1) SESSION object, which contains two values: the IP Address of the
aggregate session destination, and the Differentiated Services
Code Point (DSCP) that it will use on the E2E data the reservation
contains.
2) SENDER_TEMPLATE object, which identifies the aggregating router
for the aggregate reservation.
3) FILTER_SPEC object, which identifies the aggregating router for
the aggregate reservation, and is syntactically identical to the
SENDER_TEMPLATE object.
From the perspective of RSVP signaling and the handling of data
packets in the aggregation region, these cases are equivalent to that
of aggregating E2E RSVP reservations. The only difference is that
E2E RSVP signaling does not take place and cannot therefore be used
as a trigger, so some additional knowledge is required for setting up
the aggregate reservation.
2.2.6. IEEE 802-Style LAN Interface
[RFC2814] introduces an RSVP LAN_NHOP address object that keeps track
of the next L3 hop as the PATH message traverses an L2 domain between
two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3
addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is
used to include the Layer-2 address (L2ADDR) of the previous hop,
complementing the L3 address information included in the RSVP_HOP
object (RSVP_HOP_L3 address).
To provide sufficient information for debugging or resource
management, RSVP diagnostic messages (DREQ and DREP) are defined in
[RFC2745] to collect and report RSVP state information along the path
from a receiver to a specific sender.
2.2.7. ATM Interface
[RFC2379] and [RFC2380] define RSVP over ATM implementation
guidelines and requirements to interwork with the ATM (Forum) UNI
3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP
associated data packets must not be sent on the same virtual circuits
(VCs), and that an explicit release of RSVP associated QoS VCs must
be performed once the VC for forwarding RSVP control messages
terminates. Although a separate control VC is also possible for
forwarding RSVP control messages, [RFC2379] recommends creating a
best-effort short-cut first (if one does not exist), which can allow
setting up RSVP-triggered VCs to use the best-effort end-point. (A
short-cut is a point-to-point VC where the two end-points are located
in different IP subnets.) For data flows, the subnet senders must
establish all QoS VCs, and the RSVP-enabled subnet receiver must be
able to accept incoming QoS VCs. RSVP must request that the
configurable inactivity timers of VCs be set to "infinite". If it is
too complex to do this at the VC receiver, RSVP over ATM
implementations are required not to use an inactivity timer to clear
any received connections. For dynamic QoS, the replacement of VC
should be done gracefully.
2.2.8. DiffServ Interface
RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated
Services Code Points (DSCPs) in RSVP message objects. If the network
element determines that the RSVP request is admissible to the
DiffServ network, one or more DSCPs corresponding to the behavior
aggregate are determined, and will be carried by the DCLASS Object
added to the RESV message upstream toward the RSVP sender.
2.2.9. Null Service Type
For some applications, service parameters are specified by the
network, not by the application; e.g., enterprise resource planning
(ERP) applications. The Null Service [RFC2997] allows applications
to identify themselves to network QoS policy agents using RSVP
signaling, but does not require them to specify resource
requirements. QoS policy agents in the network respond by applying
QoS policies appropriate for the application (as determined by the
network administrator). The RSVP sender offers the new service type,
’Null Service Type’, in the ADSPEC that is included with the PATH
message. A new TSPEC corresponding to the new service type is added
to the SENDER_TSPEC. In addition, the RSVP sender will typically
include with the PATH message policy objects identifying the user,
application and sub-flow, which will be used for network nodes to
manage the correspondent traffic flow.
2.2.10. MPLS Traffic Engineering
RSVP-TE [RFC3209] specifies the core extensions to RSVP for
establishing constraint-based explicitly routed LSPs in MPLS networks
using RSVP as a signaling protocol. RSVP-TE 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.
RFC3209 defines a new Hello message (for rapid node failure
detection).
RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and
LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC
objects. Here, a session is the association of LSPs that support the
LSP-tunnel. The traffic on an LSP can be classified as the set of
packets that are assigned the same MPLS label value at the
originating node of an LSP-tunnel.
The following 5 new objects are also defined:
1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path
messages, encapsulating a concatenation of hops that constitutes
the explicitly routed path. Using this object, the paths taken by
label-switched RSVP-MPLS flows can be pre-determined independently
of conventional IP routing.
2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can
create a Path message with a LABEL_REQUEST object. A node that
sends a LABEL_REQUEST object MUST be ready to accept and correctly
process a LABEL object in the corresponding Resv messages.
3) LABEL object. Each node that receives a Resv message containing a
LABEL object uses that label for outgoing traffic associated with
this LSP tunnel.
4) SESSION_ATTRIBUTE object, which can be added to Path messages to
aid in session identification and diagnostics. Additional control
information, such as setup and holding priorities, resource
affinities, and local-protection, are also included in this
object.
5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in
both Path and Resv messages. It is used to collect detailed path
information and is useful for loop detection and for diagnostics.
Section 5 of [RFC3270] further specifies the extensions to RSVP to
establish LSPs supporting DiffServ in MPLS networks, introducing a
new DIFFSERV Object (applicable in the Path messages), and using
pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
RSVP-TE provides a way to indicate an unnumbered link in its Explicit
Route and Record Route Objects through [RFC3477]. This specifies the
following extensions:
- An Unnumbered Interface ID Subobject, which is a subobject of the
Explicit Route Object (ERO) used to specify unnumbered links.
- An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
form or use an identifier for an unnumbered Forwarding Adjacency.
- A new subobject of the Record Route Object, used to record that the
LSP path traversed an unnumbered link.
2.2.11. GMPLS and RSVP-TE
GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the
provisioning of data-paths within networks supporting a variety of
switching types including packet and cell switching networks, layer
two networks, TDM networks, and photonic networks.
It defines the new Notify message (for general event notification),
which may contain notifications being sent, with respect to each
listed LSP, both upstream and downstream. Notify messages can be
used for expedited notification of failures and other events to nodes
responsible for restoring failed LSPs. A Notify message is sent
without the router alert option.
A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for
general uses of MPLS:
- a Generalized Label Request Object;
- a Generalized Label Object;
- a Suggested Label Object;
- a Label Set Object (to restrict label choice);