RFC 4094

RFC 4094: Analysis of Existing Quality-of-Service Signaling Protocols ✨

Okay bestie, here's the vibe check on this one 🎀 It's by J. Manner and X. Fu, it's dated May 2005, and it's an Informational doc, so it's sharing knowledge rather than setting a standard 💅 It doesn't obsolete or update anything (there are no Obsoletes or Updates lines in the header).

Status of This Memo

Quick legal-ish bit 🫶 This memo is here to give information to the Internet community. It is not a standard of any kind, and anyone can share it freely 🌸

Copyright Notice

Copyright (C) The Internet Society (2005). 🔥

Abstract

Okay, the whole point of this doc 💖 It looks at some of the QoS (Quality of Service) signaling protocols that already exist for IP networks. We want to learn from them, dodge the common misconceptions, and not repeat old mistakes when anyone designs a new protocol in this space ✨

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 🧚

Okay so this doc is looking at some of the existing QoS signaling protocols for IP networks 💅 The goal is to learn from them, avoid the common misconceptions, and not make mistakes when designing any new protocol here, because nobody wants that 😭

There have been a bunch of historic attempts to get QoS or generic signaling onto the Internet. Back in the early days, everyone thought multicast was going to be the main thing for most communication, so both RSVP and the earlier ST-II were built multicast-first 🌈

ST-II was made as a reservation protocol for point-to-multipoint communication. The catch? It's sender-initiated, so it doesn't scale with the number of receivers in a multicast group, and the processing is kinda complex 💀 Every sender has to set up its own reservation, so the total amount of reservation state gets really big. RSVP came next to support multipoint-to-multipoint reservation setup in a more efficient way. Still, people have criticized its complexity, its scalability, and how well it handles new requirements 🙈

YESSIR (YEt another Sender Session Internet Reservations) [PS98] and Boomerang [FNM+99] are protocols that came after RSVP and were designed to be simpler than it. YESSIR is an extension to RTCP, and Boomerang works with ICMP 🦋

A lot of work has also gone into making a brand new signaling protocol for resource control. Istvan Cselenyi suggested a QoSSIG BOF at IETF47 to figure out the problems in QoS signaling, but didn't get enough support [URL1]. Some people said, "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 felt "new knowledge and requirements" made RSVP not enough. Some concluded there's no simpler way to solve the same problem than RSVP 🤷‍♀️

Michael Welzl organized a special session called "ABR to the Internet" at SCI 2001, and gathered input to request an "ABR to the Internet" BOF at IETF#51. It was meant to bring explicit rate-feedback mechanisms to the Internet (e2e, edge2edge), but it failed because of "missing community interest" 😢

OPENSIG [URL2] has been involved with Internet signaling for years. Ping Pan started a SIGLITE [URL3] BOF mailing list to look into lightweight Internet signaling. Eventually the NSIS BOF worked out, and the NSIS WG got formed 🎉

The most mature and original protocols get their own sections, and the other QoS signaling protocols show up in later subsections. The protocols featured were picked based on how relevant they are to the NSIS work. The aim isn't to review every single existing protocol ✨

2. RSVP and RSVP Extensions 👑

RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96] grew out of ST-II to give end-to-end QoS signaling for application data streams. Hosts use RSVP to ask the network for a specific quality of service (QoS) for particular application flows. Routers use RSVP to pass those QoS requests along to all the routers on the data path. RSVP can also maintain and refresh state for a requested QoS application flow 💖

By its original design, RSVP fits nicely into the Integrated Services (IntServ) framework [RFC2210] [BEBH96], with a certain amount of modularity and scalability 🦋

Here's how it works: RSVP carries QoS signaling messages through the network and visits every node on the data path. To make a reservation at a node, the RSVP module talks to two local decision modules, admission control and policy control. Admission control checks whether the node has enough available resources to supply the requested QoS. Policy control handles authorization for the QoS request. If either check fails, the RSVP module sends an error notification back to the application process that started the request. If both checks pass, the RSVP module sets the parameters in a packet classifier and packet scheduler to get the QoS that was asked for ✨

2.1. Basic Design

RSVP's design stands out in a few fundamental ways: soft state management, two-pass signaling message exchanges, receiver-based resource reservation, and separation of QoS signaling from routing 🌸

2.1.1. Signaling Model

RSVP's signaling model is built around a special way of handling multicast. The sender of a multicast flow advertises the traffic characteristics to the receivers periodically through "Path" messages. When a receiver gets one of those advertisements, it may generate a "Resv" message to reserve resources along the flow path from the sender. Receiver reservations may be heterogeneous 🧁 To support multipoint-to-multipoint multicast applications, RSVP was designed to handle a vector of reservation attributes called the "style". A style describes whether all senders in a multicast group share one reservation, and which receiver it applies to. The "Scope" object also gives 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 delivery paths might change during the life of an application flow, RSVP takes a soft-state approach 🫧 It creates and removes the protocol states (Path and Resv states) in routers and hosts bit by bit over time. RSVP sends periodic refresh messages (Path and Resv) to keep its states alive and to recover from the occasional lost message. If refresh messages stop arriving, the RSVP states time out automatically and get deleted. States can also be deleted explicitly by a PathTear, a PathErr with the Path_State_Removed flag, or a ResvTear message 💀

2.1.3. Two-Pass Signaling Message Exchanges

The receiver in an application flow is the one responsible for requesting the QoS it wants from the sender 🎀 To do that, the receiver issues an RSVP QoS request on behalf of its local application. The request travels to all the routers in the reverse direction of the data paths, heading back toward the sender. Along the way, RSVP requests might get merged, which is why it scales really well when there are lots of receivers 🔥

2.1.4. Receiver-Based Resource Reservation 🎀

okay so receiver-initiation is literally critical for RSVP when you want to set up multicast sessions with a ton of heterogeneous receivers 😭 A receiver starts a reservation request at a leaf of the multicast distribution tree, and it travels toward the sender 🦋 Whenever a reservation already exists in a node in the distribution tree, the new request gets merged with that existing reservation ✨ This can mean fewer signaling operations for the RSVP nodes near the sender in the multicast tree 💅 but it could introduce a restriction to receiver-initiation 🙈

2.1.5. Separation of QoS Signaling from Routing 🌸

RSVP messages follow normal IP routing, and this is the part people mix up 💀 RSVP is not a routing protocol 🙅‍♀️ It's designed to work with current and future unicast and multicast routing protocols 🧚 The routing protocols are the ones responsible for choosing the routes used to forward packets, and RSVP consults local routing tables to get those routes. RSVP is responsible only for reservation setup along a data path. Main character energy, but only for one job 👑

A number of messages and objects have been defined for the protocol. The full breakdown is in [RFC2205] 📖

2.2. RSVP Extensions 🌈

okay bestie, 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 never really showed up, even though a lot of people pictured it as one of the key Internet apps that would benefit from network-wide RSVP deployment 😭 Instead, RSVP-TE [RFC3209], which is an RSVP extension for traffic engineering, has been widely deployed by a large number of network providers to support MPLS applications ✨ Plot twist, but it slaps 🔥

There are a large number of protocol extensions based on RSVP 🧚 Some add features like security and scalability to the original protocol. Some introduce additional interfaces to other services, such as DiffServ. And some just define new applications, such as MPLS and GMPLS, which are completely irrelevant from the protocol's original intent 💀

In this section, we only list 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 lets RSVP make reservations across all IP-in-IP tunnels. Basically, it works 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 can't interpret the POLICY_DATA objects are called policy-ignorant nodes (PINs). The content of the POLICY_DATA object itself is protected only between PEPs, so it 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 the 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 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. The document also describes how to give the host encoded session authorization information as a POLICY_DATA object 🔑

2.2.4. Refresh Reduction 🔄

[RFC2961] describes mechanisms to reduce the processing overhead of refresh messages, eliminate the state synchronization latency that happens when an RSVP message is lost, and refresh state without transmitting 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 made up of one or more standard RSVP messages. Bundle messages help scale RSVP by reducing 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 the 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, so the number of individual RSVP sessions can go down 📉 The protocol type gets swapped from RSVP to RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf messages when they enter the aggregation region, and it gets swapped back when they leave 🔁 On top of 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 aggregating E2E RSVP reservations 👯 The only difference is that E2E RSVP signaling doesn't happen and therefore can't be used as a trigger, so some additional knowledge is required to set 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 travels through 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 carries the Layer-2 address (L2ADDR) of the previous hop, complementing the L3 address information in the RSVP_HOP object (RSVP_HOP_L3 address).

To give you enough info 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 for interworking with the ATM (Forum) UNI 3.x/4.0 🌐 [RFC2380] states that the RSVP (control) messages and the 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 doesn't already exist), which can let RSVP-triggered VCs 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's 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 a 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 they're 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] lets applications identify themselves to network QoS policy agents using RSVP signaling, but it doesn't 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's included with the PATH message. A new TSPEC corresponding to the new service type is added to the SENDER_TSPEC. On top of that, the RSVP sender will typically include policy objects with the PATH message that identify the user, application, and sub-flow, which network nodes use to manage the corresponding traffic flow 🎯

2.2.10. MPLS Traffic Engineering ✨

Okay so RSVP-TE [RFC3209] is the big glow-up pack for RSVP 💅 It's the core set of extensions that lets RSVP do the signaling for constraint-based explicitly routed LSPs in MPLS networks. 🦋 It's built for label switching routers (and hosts too, bestie!) to set up and maintain LSP-tunnels and to reserve network resources for them. Iconic, no cap.

RFC3209 defines a new Hello message (for rapid node failure detection). 🫶 Fast failure detection? Main character energy.

RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. 🎀 So a session here is basically the group of LSPs that together support the LSP-tunnel. And the traffic on an LSP can be sorted into the set of packets that get the same MPLS label value at the originating node of the LSP-tunnel. It's giving organized 🍓

The following 5 new objects are also defined:

1. EXPLICIT_ROUTE object (ERO), which gets slotted into RSVP Path messages and holds a concatenation of hops that makes up the explicitly routed path. 🧚 With this one, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, completely independently of conventional IP routing. Not me planning my own route 😭
2. LABEL_REQUEST object. To set up 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. That's a hard rule, bestie 🔥
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 help with session identification and diagnostics. It also carries extra control info like setup and holding priorities, resource affinities, and local-protection. 👑
5. RECORD_ROUTE object (RRO). The RECORD_ROUTE object may show up in both Path and Resv messages. It collects detailed path info and is useful for loop detection and diagnostics. 🔍

Section 5 of [RFC3270] goes further and specifies the RSVP extensions for setting up LSPs that support DiffServ in MPLS networks. It introduces a new DIFFSERV object (applicable in the Path messages) and uses pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]). Layers on layers, I'm obsessed 🌈

RSVP-TE also gives you a way to indicate an unnumbered link in its Explicit Route and Record Route Objects through [RFC3477]. ⭐ That spec adds:

• 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, and it's a whole vibe. 🦋 It enables provisioning of data-paths within networks that support a variety of switching types: packet and cell switching networks, layer two networks, TDM networks, and photonic networks. Every network type, invited.

It defines the new Notify message (for general event notification). A Notify message can carry notifications being sent, for each listed LSP, both upstream and downstream. 📣 These are great for expedited notification of failures and other events to the nodes in charge of restoring failed LSPs. Quick heads-up, fast fix. A Notify message is sent without the router alert option. 🙈

GMPLS RSVP-TE defines a bunch of new RSVP-TE (sub)objects 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);
• 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).

That's a LOT of objects, periodt 💅

---

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. 🎉 Zero new stuff needed, so chill. See [OVERLAY].

---

2.2.13. MPLS and GMPLS Future Extensions 🔮

At the time of writing, the MPLS and CCAMP Working Groups are extending MPLS and GMPLS to support additional sophisticated functions. ✨ This will inevitably lead to new C-Types for existing objects, and to the need for new objects (CNums). New messages might show up too, so stay tuned 👀

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.

Future-proof era, I'm so excited 🌈

---

2.2.14. ITU-T H.323 Interface 📞

ITU-T H.323 ([H.323]) recommends the IntServ resource reservation procedure using RSVP. 💖 Whether an endpoint supports RSVP should be conveyed during the H.245 [H.245] capability exchange phase, by setting the appropriate qOSMode fields. If both endpoints are RSVP-capable, then 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 endpoint sets the timer for waiting on the ResvConf message. If that timer expires, or the RSVP reservation fails at any point during an H.323 call, what happens next is up to the vendor 🤷‍♀️ Once a ResvConf message is sent or received, the endpoints should stop the reservation timers and resume with the H.323 call procedures.

Only explicit release of reservations is supported in [H.323]. 🫧 Before sending a closeLogicalChannel message for a stream, a sender should send a PathTear message if an RSVP session was previously created for that stream. After receiving a closeLogicalChannel, a receiver should similarly send a ResvTear. Only the FF style is supported, even for point-to-multipoint calls. Tidy and minimal, very on brand 💅

---

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) on 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. 🚪 Policy checks at the door, iykyk 🫶

2.3. Extensions for New Deployment Scenarios

okay so RSVP is super well-acknowledged on the Internet 🌐✨ and people keep expecting it to give a more generic service for all kinds of signaling apps. but RSVP messages were designed to do end-to-end QoS signaling really well 💅. so now it needs to handle host-to-edge and edge-to-edge signaling too, and serve other signaling purposes on top of end-to-end QoS. RSVP needs a glow-up to be way more flexible and applicable for generic signaling 🦋

RSVP proxies [BEGD02] are the move 🫶. they extend RSVP by originating or receiving RSVP messages on behalf of the end node(s), so apps can still benefit from reservations that aren't truly end-to-end. but ngl there are definitely scenarios where an app wants to explicitly send its non-QoS data (as well as QoS data) from a host into the network, or from an ingress node to an egress node of an administrative domain 🙈. and it has to do that without burdening the network with excess messaging overhead. typical examples are an end host wanting 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 that don't support RSVP get traversed transparently, which is giving main character energy. unfortunately, like other IP options, RSVP messages implemented by way of the IP alert option may be dropped by some routers [FJ02] 😭. and even though applications need to be built with RSVP libraries, one article presents a mechanism that would let any host benefit from RSVP mechanisms without the apps being aware of it [MHS02] 🌸.

a somewhat similar deployment benefit comes from Localized RSVP (LRSVP) [JR03] [MSK+04] 🎀. these documents present the concept of local RSVP-based reservation that can alone be used to trigger reservation within an access network. so an end-host can request QoS from its own access network without the cooperation of a correspondent node outside that network. this is especially helpful when the correspondent node is unaware of RSVP. a proxy node responds to the messages the end host sends and enables both upstream and downstream reservations. the scheme also 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 handle the signaling can introduce unnecessary overhead 💀. one article [Kars01] proposes creating a remote API so the daemon would actually run on the end-host's default router, and the end-host application would send its requests to that daemon 🧚‍♀️.

another potential problem is 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 gets fragmented by IP and reassembled at the recipient node 🥺.

---

2.4. Conclusion

bestie, 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 need more careful re-evaluation 🤔.

RSVP was originally targeted at multicast applications, and the result is that message processing inside nodes is kinda heavy, mainly because of flow merging 🌀. still, merging rules shouldn't appear in the specification, since they're QoS-specific.

RSVP has a comprehensive set of filtering styles, including Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE) 🎀, and it isn't 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's no clear layering or separation between the signaled data and the signaling protocol 🫠.

RSVP uses a soft state mechanism to maintain states, and it 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, so a mobile node may be left without a reservation for up to the length of the refresh timer 😩.

furthermore, RSVP doesn't work properly with changing end-point identifiers. if one of a mobile node's IP addresses 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 or protection against message deletion, and the two-way peer authentication and key management procedures are still missing 🚨.

finally, since the RSVP standard was published, 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 the IP alert option may be dropped by some routers. also, the maximal size of an 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

okay, so 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 doesn't 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 an RSVP extension in [RFC2961] 🦋. the staged refresh timer mechanism retransmits RSVP messages until the receiving node acknowledges them. it can address the reliability problem in RSVP 🫶.

but during the mechanism's implementation, a lot of effort had to go into per-session timer maintenance, message retransmission (e.g., avoiding message bursts), and message sequencing 🥵. we also have to make an effort 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 with a reasonably large number of RSVP sessions, this constraint imposes a heavy processing burden on the routers 😩. many router OSes are based on UNIX, and [PS00] showed that 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. on one deployed router platform, the bundling mechanism improved the number of RSVP sessions a router can handle from 2,000 to over 7,000 🚀.

3.3. MTU Problem

RSVP does not support message fragmentation and reassembly at the protocol level 🙅‍♀️. if the size of an RSVP message is larger than the link MTU, the message will be fragmented, and 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 MTU sizes 🌸. for example, on some routers, a Frame Relay interface can support a link MTU size of 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's different from what the original RSVP was designed for. in MPLS networks, the RSVP sessions used to support Label-Switched Paths (LSPs) don't change frequently 🧚.

in fact, network operators typically set up MPLS LSPs so that they can't switch too quickly 🙅‍♀️. for example, 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 doesn't 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, so routers can simply exchange the IDs to refresh RSVP sessions 🔥. with the full implementation of RFC2961, MPLS routers don't have any RSVP scaling issues. 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 that require a signaling protocol, the user session duration can be relatively short 🦋. the dynamics of adding and dropping user sessions could introduce a large number of "triggered" messages into the network. this can clearly add 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? 🦋

okay so a good signaling protocol should be transparent to the applications 🫶 but the design also has to think about the intended AND potential applications. both things, no cap.

With RFC2961 added, RSVP-TE is sufficient to support its intended application, MPLS, within the backbone ✨. There's no significant transport-layer problem that needs solving, periodt 💅

Lowkey, though, a bunch of new applications have popped up over the last several years that are proposed to need IP signaling, way beyond the classic quality of service and resource allocation stuff. On-path firewall control/NAT traversal (synergistic with the midcom design of [RFC3303]) is one of these 🔥. Then there are far-out ones, like 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 😭.

So if a new transport protocol is needed, it 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 it takes to handle messages belonging to a reservation session 🧠. This is the processing on top of what's already needed for routing an (ordinary) IP packet. The processing overhead of RSVP comes from two major issues:

1) Complexity of the protocol elements. First, RSVP itself is per-flow based, so 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. So even though the 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, so 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 ✨.

So 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 short refresh periods, the local routing protocol module can notify the RSVP process of route changes for particular destinations. The RSVP process should use this information to trigger a quick refresh of state for these destinations, using the new route (Section 3.6, [RFC2205]). However, not all local mobility protocols affect routing directly in routers (not even Mobile IP), and thus mobility may not be noticed at RSVP routers. Therefore, it may take a relatively long time before a reservation is refreshed following a handover 🐢.

There have been several designs for extensions to RSVP to allow for more seamless mobility 🌈. One solution is presented in [MSK+04], in which one section discusses the coupling of RSVP and the mobility management mechanisms and proposes small extensions to RSVP to handle the handover event better, among other things. The extension allows the mobile host to request a Path for the downstream reservation when a handover has happened.

Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension to standard RSVP. It is based on advance reservations, where neighboring access points keep resources reserved for mobile nodes moving to their coverage area. When a mobile node requests resources, the neighboring access points are checked, too, and a passive reservation is done around the mobile nodes' current location 🛰️.

The problem with the various "advance reservation" schemes is that they require topological information of the access network and, usually, advance knowledge of the handover event. Furthermore, the way the resources reserved in advance are used in the neighboring service areas is an open issue. A good overview of these different schemes can be found in [MA01] 📚.

The interactions of RSVP and Mobile IP have been well documented in [Thom02] 💜.

6. Other QoS Signaling Proposals ✨

6.1. Tenet and ST-II 💖

okay so Tenet and ST-II are two original QoS signaling protocols for the Internet, the OGs 👑 no cap they're iconic

In the original Tenet architecture [BFM+96], the receiver sends a reservation request toward the source 📨 each network node along the way makes the reservation. Once the request reaches the source, the source sends a Relax message back toward the receiver, and it gets to modify the previous reservation at each node if it wants 🦋

ST-II [RFC1819] basically works like this: a sender starts a Connect message to a set of receivers 🌸 each intermediate node figures out the next hop subnets and reserves stuff on the links going to those next hops. When a receiver gets a Connect indication, it has to send back either an Accept or a Refuse message to the sender. If it sends an Accept, the receiver can shrink the resource request by updating the returned flow specifications ✨

ST-II is made of two protocols: ST for data transport, and the Stream Control Message Protocol (SCMP) for all the control functions 🧚 ST is super simple and has only a single PDU format, which is built for fast, efficient data forwarding so communication delays stay low. SCMP packets get carried inside ST packets 💅

ST-II has no built-in soft states, so it needs the network to be responsible for correctness 🙈 it's sender-initiated, and the overhead for ST-II to handle group membership dynamics is higher than it is for RSVP [MESZ94]. ST-II does not provide security, but [RFC1819] describes some objects related to charging 💀

6.2. YESSIR 🎀

YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a resource reservation protocol that wants to make setting up reserved flows way easier while still keeping a bunch of the cool features RSVP introduced 🫶 simplicity gets measured by control message processing, data packet processing, and user-level flexibility. Robustness, advertising network service availability, and resource sharing among multiple senders are also supported, so it's not missing out 🌈

The proposed mechanism has senders generate reservation requests to cut down on processing overhead. It's built as an extension to the Real-Time Transport Control Protocol (RTCP), and it takes advantage of the Real-Time Protocol (RTP) 🦋 YESSIR also brings in partial reservation, which means that for certain types of applications, reservation requests can be passed on to the next hop even when a local node doesn't have enough resources. The local node can rely on optimized retries to finish the reservations ⭐

6.2.1. Reservation Functionality ✨

YESSIR [PS98] was designed for one-way, sender-initiated end-to-end resource reservation 💜 it also uses soft state to maintain states. It supports resource query (similar to the RSVP diagnosis message), advertising (similar to RSVP ADSPEC), shared reservation, partial reservations, and flow merging. Iconic lineup 😭

To support multicast, YESSIR simplifies the reservation styles down to individual and shared reservation styles 🍓 individual reservations are made separately for each sender, whereas shared reservations allocate resources that every sender in an RTP session can use. Here's the twist: although RSVP supports shared reservation (SE and WF styles) from the receiver's side, YESSIR handles the shared reservation style from the sender's side. So new receivers can re-use the existing reservation of the previous sender 🔥

The YESSIR one-pass reservation model has better performance and lower processing cost than a regular two-way signaling protocol like RSVP [PS98], and that's been shown 👑 the bandwidth consumption of YESSIR is somewhat lower than something like RSVP, because it doesn't need extra IP and transport headers. Its bandwidth consumption is limited to the extension header size 🎀

YESSIR doesn't have any particular support for mobility, and its security relies on RTP/RTCP security measures 🙈

6.2.2. Conclusion 🌸

YESSIR needs support in applications since it's an integral part of RTCP 🫶 similarly, it needs network routers to inspect RTCP packets to spot reservation requests and refreshes. Routers that don't know about YESSIR just forward the RTCP packets transparently 🦋

6.3. Boomerang 🪃

Boomerang [FNM+99] is another resource reservation protocol for IP networks 💅 it has only one message type and a single signaling loop for reservation setup and teardown, and it has no requirements on the far end node. Instead, it puts all the smarts in the Initiating Node (IN) 🧠

Boomerang also lets you do sender- or receiver-oriented reservations, plus resource query ✨ flows are identified with the common 5-tuple, and the QoS can be specified by various means, e.g., service class and bit rate. In the initial implementation, Boomerang messages ride inside ICMP ECHO/REPLY messages 🧚

6.3.1. Reservation Functionality 💖

Boomerang can only be used for unicast sessions, so no multicast support exists 🙈 the requested QoS can be specified in various ways, and both ends of a communication session can make a reservation for the flow they transmit 🦋

The authors of Boomerang show in [FNS02] that the processing of the protocol is considerably lower than that of the ISI RSVP daemon implementation. Still, that's mainly because Boomerang does way less than RSVP does 🤷‍♀️

Boomerang messages are quite short and eat up a relatively low amount of link bandwidth 🍓 that's because of its limited functionality. For example, no security-specific information or policy-based interaction is provided. Since it's sender oriented, the bandwidth consumption mostly hits the downstream direction, from the sender to the receiver 💜

Because Boomerang is sender oriented, there's no need to store backward information, and that cuts down the signaling required ✨ the rest of the issues identified with RSVP still apply to Boomerang. No security mechanism is specified for Boomerang 💀

The Boomerang protocol has deployment issues similar to any host-network-host protocol 😭 it needs an implementation at both communicating nodes and in routers. Boomerang-unaware routers should be able to forward Boomerang messages transparently. Still, firewalls often drop ICMP packets, which makes the protocol useless 💀

6.3.2. Conclusions 🌈

Boomerang seems to be a very lightweight protocol and efficient in its own scenarios 🫶 however, the apparent low processing overhead and bandwidth consumption come from the limited functionality. No support for multicast or any security features is present, which gives it a different functionality than RSVP, the thing the authors like to compare Boomerang to 👑

6.4. INSIGNIA 🌸

INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism for supporting QoS in mobile ad-hoc networks ⭐ it skips separate signaling entirely by carrying the QoS signaling data along with the normal data in IP packets, using IP packet header options. This approach, known as "in-band signaling", is proposed as more suitable for the rapidly changing environment of mobile networks, since the signaled QoS information isn't tied to a particular path. It also lets flows get set up fast, so it's a good fit for short-lived and dynamic flows 🦋

INSIGNIA aims to minimize signaling by reducing the number of parameters provided to the network 🧚 it assumes real-time flows may tolerate some loss, but are very delay sensitive, so the only QoS information needed is the required minimum and maximum bandwidth 🍓

The INSIGNIA protocol operates at the network layer and assumes that link status sensing and access schemes are provided by lower-layer entities 💅 the usefulness of the scheme depends on the MAC layers, but that's undefined, so INSIGNIA can run over any MAC layer. The protocol requires that each router maintains per-flow state 🔥

The INSIGNIA system implicitly supports mobility ✨ a near-minimal amount of information gets exchanged with the network. To achieve this, INSIGNIA makes lots of assumptions about the nature of traffic a source will send, which may also simplify admission control and buffer allocation. Basically, the system assumes "real-time" will be defined as a maximum delay, and the user can simply request real-time service for a particular quantity of traffic 💜

After handover, data that was transmitted to the old base station can be forwarded to the new base station, so no data loss should occur 🫶 however, there's no way to tell re-routed traffic apart from new traffic, so priority can't be given to handover traffic, for example 🙈

INSIGNIA, however, (completely) lacks a security framework. It doesn't investigate how to secure signaled QoS data in an ad-hoc network, where relatively weak trust or even no trust exists between the participating nodes 💀 therefore, authorization and charging especially might be a challenge. The security protection of in-band signaling is costly, since the data delivery itself gets increased latency if security processing is done hop-by-hop. And because the QoS signaling information is encoded into the flow label and end-to-end addressing is used, it's very difficult to provide security other than IPsec in tunnel mode 😭

---

7. Inter-Domain Signaling 🌍

This section gives a short overview of protocols designed for inter-domain signaling 💖

7.1. BGRP 🪽

Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling protocol for inter-domain aggregated resource reservation for unicast traffic ✨ BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. BGRP maintains these aggregated reservations using soft state and relies on Differentiated Services for data forwarding 🦋

In terms of message processing load, BGRP scales state storage and bandwidth 🧠 because backbone routers only maintain the sink tree information, the total number of reservations at each router scales linearly with the number of Internet domains 🌈

7.2. SICAP ✨

Okay bestie, SICAP (Shared-segment Inter-domain Control Aggregation protocol) [SGV03] is an inter-domain signaling solution that does shared-segment aggregation [SGV02] on the Autonomous System (AS) level 💅. Its whole goal is to cut down the state needed at Boundary Routers (BRs) 🫶. It aggregates based on path segments that different reservations share, so reservations can get merged into aggregates that don't have to stretch all the way to the reservation's destination 🦋. Shorter aggregates are iconic for two reasons. First, they're easier to fit future requests into. Second, fewer aggregates get created, which means less state to manage for the reservations that already exist 🧚.

Here's the catch, though 😭. Unlike the sink-tree approach (used by BGRP [BGRP]), the shared-segment approach adds intermediate de-aggregation locations. These are ASes where aggregates can experience "re-aggregation." At those spots, the routers doing the aggregation (AS egress routers) have to keep track of the mapping between reservations and aggregates. One option is to store each reservation identifier and its resources at every aggregator, but that's a huge state penalty 💀. SICAP dodges that penalty by tracking the mapping between aggregates and reservations at the level of destination domains, instead of mapping each individual reservation to an aggregate 👑. In other words, SICAP keeps, for each aggregate, a list of the destination prefixes advertised by the destination AS that the aggregate gives access to 🌸.

Pan et al. show that BGRP scales well in terms of control state, message processing, and bandwidth efficiency, compared to RSVP without aggregation 💜. BUT, partly because BGRP was the first approach to dig into inter-domain control aggregation in detail, they didn't compare it against other aggregation protocols 🙈.

SICAP and BGRP messaging sequences are similar, so these protocols end up with the same signaling load 🎀. That load is exactly the same as what you'd get from proposals that don't aggregate at all, since SICAP and BGRP exchange messages per individual reservation. On bandwidth, both protocols provision aggregates with the exact bandwidth their merged reservations need ✨. So the major difference between SICAP and BGRP is the state kept at BRs, and SICAP makes that way smaller 🍓. Honestly, the point isn't that SICAP is a better alternative to BGRP. It's about quantifying how much performance improvement might still be available in the research field of control path aggregation 🔥. Last but not least, to deal with the possible problem of signaling load, SICAP uses an over-reservation mechanism [SGV03b], and its design took into consideration a possible support for BGRP 🫶💖.

---

7.3. DARIS 🌈

Dynamic Aggregation of Reservations for Internet Services (DARIS) [Bless02] [Bless04] is an inter-domain aggregation scheme for resource reservations, and it's giving main character energy 👑. Basically, it aggregates reservations along Autonomous System (AS) paths (or parts of them) 🦋. A set of reservations whose data paths share a common sequence of ASes gets integrated into a joint reservation aggregate along that shared sub-path 💅. Everyone inside the aggregate, except the aggregate's starting and end points, can delete the state information of the individual reservations they include, which saves state 🧚. They only need to hold the info about the encompassing aggregate. And those intermediate ASes stop being involved in signaling for the aggregated reservations, so that's less signaling work too 🙌. If more aggregate resources get reserved than were actually needed, the capacity of the aggregate doesn't have to be adapted with every new or released reservation, which cuts down on message exchanges 🌸.

An aggregate between two ASes gets created as soon as a threshold k is exceeded, where k describes the number of active unidirectional reservations between them 🎀. It's also possible to apply different aggregation triggers ✨. DARIS allows aggregates to be nested hierarchically, so shorter aggregates don't stop longer (and therefore more efficient) aggregates from being created, and vice versa 💜. An evaluation of recent BGP routing information in [Bless02] showed that 92% of all end-to-end paths contain at least four ASes 😳. That means an aggregate from edge AS to edge AS can span four or more ASes, saving state and signaling message processing in at least two ASes 🔥.

Now for the drama 😭. There's a small chance that a reservation can't be included in a new aggregate, because it was already aggregated somewhere else. This so-called "aggregation conflict" happens because state information for individual reservations was removed earlier, inside the intermediate ASes of the encompassing aggregate. It can also cause trouble if reservations or aggregates get re-routed between ASes 🙈. If you're thinking about sophisticated adaptation techniques for these special cases, be careful, because they seem to get very complex fast 💀.

The signaling protocol DMSP (Domain Manager Signaling Protocol) supports aggregation through special extensions 🫶. In some cases, those extensions cut the reservation setup time by more than one round-trip time (for example, if an aggregate's capacity has to be increased before a new reservation can be included) 🚀. Details are in [Bless02] 🍓.

The DARIS concept was evaluated with a simulation using a topology derived from real BGP routing table information, which comprised more than 5500 ASes 🌍. Compared to a non-aggregated scenario, the number of saved states landed in the range of one to two orders of magnitude, and similar results showed up for the number of signaling messages 🤯. [Bless02] describes DARIS in the context of distributed Domain Management entities (similar to a bandwidth broker), but it can also be applied in a router-based resource management environment 🦋. That gets an even higher degree of distribution, which is beneficial for large, highly interconnected ASes 👑.

A general issue with aggregation is that it isn't the aggregating and de-aggregating ASes that profit from the aggregates they start. It's all the intermediate ASes within an aggregate 🙃. So some incentive for aggregate creation has to be given. This may lead to novel cost models that have to be developed for aggregation concepts in the future 💅✨.

---

8. Security Considerations 🔐

This document does not present new technology or protocols. Thus, there are no explicit security issues 🙂. Still, individual protocols include different levels of security issues, and those are highlighted in the relevant sections and references 🚨.

9. Summary 💜

Supporting flow-based soft state reservations has been proven useful ✨. Still, there have been different ways to improve performance, including refresh reduction and aggregation 🦋. However, some of the main concerns with these signaling protocols are the complexity of the protocol, which affects implementations and processing overhead, and the security of the signaling 😬. Especially, a proper scheme to handle authentication and authorization of QoS resource requests, and a framework for providing signaling message security, seem to be missing from most protocols 🫠. RSVP has a mechanism to protect signaling messages based on manually distributed keys, plus concepts for authorization, but they seem to be insufficient for a dynamic and mobile environment 🙅‍♀️. [Tsch03] provides more details on the security properties provided by RSVP 📚. Moreover, secure and efficient signaling to and from mobile nodes has been one of the critical challenges that existing protocols haven't fully met 🚨.

Moving QoS signaling protocols into a generic messenger can provide much adoption 🌈. It's expected that the development of future protocols should learn from the lessons of existing ones 🧠. Nevertheless, the tradeoffs between expected functionality and protocol complexity/performance would still be taken into account 💅. For example, RSVP uses the two-way signaling mechanism, whereas YESSIR employs only one-pass signaling 🔁. Both can be shown to outperform the other in specific, carefully chosen signaling scenarios 👑.

10. Contributors 🫶

This document is part of the work done in the NSIS Working Group 🌸. The document was initially written by Jukka Manner and Xiaoming Fu 🎀. Since the first version, Martin Karsten has provided text about the processing overhead of RSVP, and Hannes Tschofenig has provided text about various security issues in the protocols ✨. Henning Schulzrinne and Ping Pan have provided more information on RSVP transportation after the second revision 🦋. Kireeti Kompella and Adrian Farrel provided a review and updates to the discussion on RSVP-TE and GMPLS 💖.

11. Acknowledgements 🙏

We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments 🫶🌟

12. Appendix A: Comparison of RSVP to the NSIS Requirements ✨

okay bestie, this appendix lines RSVP up against the NSIS requirements from [RFC3726] 💅 The numbering follows that requirements doc, so you can flip between the two easily 🧚

5.1. Architecture and Design Goals

5.1.1. NSIS SHOULD Provide Availability Information on Request

RSVP doesn't do query-type operations on its own 😭 but the RSVP diagnosis messages extension [RFC2745] gives it a way to check resource availability 🔍

5.1.2. NSIS MUST Be Designed Modularly

RSVP was built to be modular with TLV objects 🧩 but people feel it isn't extensible enough across different kinds of signaling applications.

5.1.3. NSIS MUST Decouple Protocol and Information

RSVP is decoupled from the IntServ QoS specifications 🎀 still, RSVP's idea of sessions is kind of tangled up with the information it carries.

5.1.4. NSIS MUST Support Independence of Signaling and Network Control Paradigm

The IntServ information RSVP carries doesn't tie down the QoS provisioning mechanisms ✨

5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects

RSVP supports this ✅

5.2. Signaling Flows

5.2.1. The Placement of NSIS Initiator, Forwarder, and Responder Anywhere in the Network MUST Be Allowed

Standard RSVP only works end-to-end 🙈 though the RSVP proxy [BEGD02] and Localized RSVP [MSK+04] loosen that up a bit. RSVP relies on the receiver starting QoS reservations (receiver-initiation) 🦋

5.2.2. NSIS MUST support Path-Coupled and MAY Support Path-Decoupled Signaling

Standard RSVP is path-coupled, but the Subnet Bandwidth Manager (SBM) work makes RSVP somewhat path-decoupled 🌸

5.2.3. Concealment of Topology and Technology Information SHOULD Be Possible

RSVP doesn't provide this by itself 🙃

5.2.4. Transparent Signaling through Networks SHOULD Be Possible

RSVP messages get intercepted and evaluated at every RSVP router, so they can't slip past certain RSVP routers unnoticed 👀 Still, the message processing rules let unknown RSVP messages be forwarded without harm 🫶

5.3. Messaging

5.3.1. Explicit Erasure of State MUST Be Possible

Handled by the PathTear and ResvTear messages 🧹

5.3.2. Automatic Release of State After Failure MUST Be Possible

On error, reservation states get torn down with PathTear messages 💥

5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream

RSVP has two notifications: one confirms a reservation was set up, and the other tears down reservation states as a result of errors 📣

5.3.4. Establishment and Refusal To Set Up State MUST Be Notified

PathErr and ResvErr messages cover refusal to set up state in RSVP 🚫

5.3.5. NSIS MUST Allow for Local Information Exchange

The RSVP NULL service type [RFC2997] provides this 🌈

5.4. Control Information

5.4.1. Mutability Information on Parameters SHOULD Be Possible

Rspec and Adspec are mutable, while Tspec is (generally) end-to-end and not mutable 🧠

5.4.2. It SHOULD Be Possible To Add and Remove Local Domain Information

RSVP aggregation [RFC3175] and the NULL service type [RFC2997] can provide this 💜

5.4.3. State MUST Be Addressed Independent of Flow Identification

RSVP states are tied to the flows, so this one isn't met 😔

5.4.4. Modification of Already Established State SHOULD Be Seamless

Modifying a reservation is possible with RSVP 🔧

5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be Provided

Aggregated RSVP and RFC2961 allow this 🧁

5.5. Performance

5.5.1. Scalability

RSVP scales linearly with the number of reservation states 📈

5.5.2. NSIS SHOULD Allow for Low Latency in Setup

Setting up an RSVP reservation takes one round-trip time, plus the processing time at each RSVP router ⏱️

5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling Protocol

The initial reservation messages cannot be compressed 🙁 but you can adjust the refresh interval to consume less bandwidth, at the cost of possibly inefficient resource usage ⚖️

5.5.4. NSIS SHOULD Allow To Constrain Load on Devices

See the discussions on RSVP performance (section 4) 📚

5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization

This depends on the IntServ service types. Controlled Load can provide better overall utilization than Guaranteed Service 🍓

5.6. Flexibility

5.6.1. Flow Aggregation

Aggregated RSVP and RFC2961 allow this 💖

5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder

RSVP allows the receiver to be the initiator of reservations 🎯

5.6.3. Flexibility in the Initiation of State Change

RSVP receivers can initiate the state change during its refreshment 🔄

5.6.4. SHOULD Support Network-Initiated State Change

Because RSVP supports hop-by-hop refreshment, this is made possible ✨

5.6.5. Uni / Bi-Directional State Setup

RSVP is only uni-directional ➡️

5.7. Security

okay this section is where things get serious 🔐 the security stuff below is the real deal, so read it carefully!

5.7.1. Authentication of Signaling Requests

Authentication is available in RSVP 🪪

5.7.2. Request Authorization

Authorization with a PDP is possible in RSVP 🗝️

5.7.3. Integrity Protection

The INTEGRITY Object is available in RSVP 🛡️

5.7.4. Replay Protection

The INTEGRITY Object provides replay protection for the content of signaling messages between two RSVP nodes 🔁

5.7.5. Hop-By-Hop Security

The RSVP security model only works hop by hop 🙇‍♀️

5.7.6. Identity Confidentiality and Network Topology Hiding

The INTEGRITY Object can be used for this purpose 🫣

5.7.7. Denial-Of-Service Attacks

This one is challenging with RSVP 😬

5.7.8. Confidentiality of Signaling Messages

Not supported by RSVP 🙈

5.7.9. Ownership of State

This one is challenging with RSVP too 😩

5.8. Mobility

5.8.1. Allow Efficient Service Re-Establishment After Handover

This works for upstream, but it might not be achieved for downstream if mobility isn't noticed at the cross-over router 📡

5.9. Interworking with Other Protocols and Techniques

5.9.1. MUST Interwork with IP Tunneling

RFC 2746 discusses these issues 🚇

5.9.2. MUST NOT Constrain either to IPv4 or IPv6

RSVP supports both IP versions 🌐

5.9.3. MUST Be Independent from Charging Model

RSVP does not discuss this 🤷‍♀️

5.9.4. SHOULD Provide Hooks for AAA Protocols

COPS and RSVP work together 🤝

5.9.5. SHOULD Work with Seamless Handoff Protocols

Not supported by RSVP. Still, [RFC2205] suggests that route changes should be indicated to the local RSVP daemon, which can then initiate state refresh 🔗

5.9.6. MUST Work with Traditional Routing

RSVP expects traditional routing 🛣️

5.10. Operational

5.10.1. Ability to Assign Transport Quality to Signaling Messages

This is a network design issue, but it is possible with DiffServ 🎨

5.10.2. Graceful Fail Over

RSVP supports this 🪂

5.10.3. Graceful Handling of NSIS Entity Problems

RSVP itself does not support this 🥲

13. Normative References

• [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.

14. Informative References

• [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service (QoS) Concept and Architecture, Release 5, December 2002.
• [BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D. Zappala, "The Design of the RSVP Protocol", ISI Final Technical Report, July 1996.
• [BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP Proxy", Work in Progress, March 2002.
• [BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. Zhang, "The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences", IEEE/ACM Transactions on Networking, Volume 4, Issue 1, February 1996, pp. 1-10.
• [BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based Aggregation Protocol for Inter-domain Reservations", Journal of Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167.
• [Bless02] R. Bless, "Dynamic Aggregation of Reservations for Internet Services", Proceedings of the Tenth International Conference on Telecommunication Systems - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38, October 3-6 2002, Monterey, California, available at http://www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdf.
• [Bless04] R. Bless, "Towards Scalable Management of QoS-based End-to- End Services" (PDF), Proceedings of NOMS 2004 (IEEE/IFIP 2004 Network Operations and Management Symposium), April 2004, Seoul, Korea.
• [FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Work in Progress, January 2004.
• [FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for Resource Reservation in IP Networks", IEEE RTAS, 1999.
• [FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance evaluation framework for IP resource reservation signalling". Performance Evaluation 48 (2002), pp. 131-156.
• [FJ02] P. Fransson and A. Jonsson, "The need for an alternative to IPv4-options", in RVK (RadioVetenskap och Kommunikation), Stockholm, Sweden, pp. 162-166, June 2002.
• [Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP Regarding Multicast". Technical Report No. IFI-TB-2002-001, ISSN 1611-1044, Institute for Informatics, University of Goettingen, Oct 2002.
• [H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia Communication, July 2000.
• [H.323] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, Nov. 2000.
• [JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS Management for Multimedia Applications in Wireless Access Networks". IASTED International Conference on Internet and Multimedia Systems and Applications (IMSA 2003), August, 2003, pp. 193-200.
• [Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany, June 2001.
• [KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, "Implementation and Evaluation of the KOM RSVP Engine", IEEE Infocom 2001.

   [LGZC00]       S. Lee, A. Gahng-Seop, X. Zhang, A.
                  Campbell,"INSIGNIA: An IP-Based Quality of Service
                  Framework for Mobile Ad Hoc Networks".  Journal of
                  Parallel and Distributed Computing (Academic Press),
                  Special issue on Wireless and Mobile Computing and
                  Communications, Vol. 60, Number 4, April, 2000, pp.
                  374-406.

   [MA01]         B. Moon, and H. Aghvami, "RSVP Extensions for Real-
                  Time Services in Wireless Mobile Networks".  IEEE
                  Communications Magazine, December 2001, pp. 52-59.

   [MESZ94]       D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An
                  Architectural Comparison of ST-II and RSVP", Infocom
                  1994.

   [MHS02]        Y Miao, W. Hwang, and C. Shieh, "A transparent
                  deployment method of RSVP-aware applications on UNIX".
                  Computer Networks, 40 (2002), pp. 45-56.

   [MSK+04]       J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
                  Raatikainen, "Localized RSVP", Work in Progress,
                  September 2004.

   [OVERLAY]      G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter,
                  "GMPLS UNI: RSVP Support for the Overlay Model", Work
                  in Progress, February 2004.

   [PS97]         P. Pan and H. Schulzrinne, "Staged refresh timers for
                  RSVP", Global Internet, Phoenix, Arizona, November
                  1997.

   [PS98]         P. Pan, and H. Schulzrinne, "YESSIR: A Simple
                  Reservation Mechanism for the Internet". Proceedings
                  of NOSSDAV, Cambridge, UK, July 1998.

   [PS00]         P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel
                  extension for IP option packet processing", Technical
                  Memorandum 10009669-02TM, Bell Labs, Lucent
                  Technologies, Murray Hill, NJ, June 2000.

   [RFC1819]      Delgrossi, L. and L. Berger, "Internet Stream Protocol
                  Version 2 (ST2) Protocol Specification - Version
                  ST2+", RFC 1819, August 1995.

   [RFC2113]      Katz, D., "IP Router Alert Option", RFC 2113, February
                  1997.

   [RFC2205]      Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                  Jamin, "Resource ReSerVation Protocol (RSVP) --
                  Version 1 Functional Specification", RFC 2205,
                  September 1997.

   [RFC2207]      Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
                  Data Flows", RFC 2207, September 1997.

   [RFC2210]      Wroclawski, J., "The Use of RSVP with IETF Integrated
                  Services", RFC 2210, September 1997.

   [RFC2379]      Berger, L., "RSVP over ATM Implementation Guidelines",
                  BCP 24, RFC 2379, August 1998.

   [RFC2380]      Berger, L., "RSVP over ATM Implementation
                  Requirements", RFC 2380, August 1998.

   [RFC2745]      Terzis, A., Braden, B., Vincent, S., and L. Zhang,
                  "RSVP Diagnostic Messages", RFC 2745, January 2000.

   [RFC2746]      Terzis, A., Krawczyk, J., Wroclawski, J., and L.
                  Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
                  January 2000.

   [RFC2747]      Baker, F., Lindell, B., and M. Talwar, "RSVP
                  Cryptographic Authentication", RFC 2747, January 2000.

   [RFC2749]      Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
                  R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
                  January 2000.

   [RFC2750]      Herzog, S., "RSVP Extensions for Policy Control", RFC
                  2750, January 2000.

   [RFC2814]      Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and
                  M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol
                  for RSVP-based Admission Control over IEEE 802-style
                  networks", RFC 2814, May 2000.

   [RFC2961]      Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
                  F., and S. Molendini, "RSVP Refresh Overhead Reduction
                  Extensions", RFC 2961, April 2001.

   [RFC2996]      Bernet, Y., "Format of the RSVP DCLASS Object", RFC
                  2996, November 2000.

   [RFC2997]      Bernet, Y., Smith, A., and B. Davie, "Specification of
                  the Null Service Type", RFC 2997, November 2000.

   [RFC2998]      Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
                  L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
                  and E. Felstaine, "A Framework for Integrated Services
                  Operation over Diffserv Networks", RFC 2998, November
                  2000.

   [RFC3175]      Baker, F., Iturralde, C., Le Faucheur, F., and B.
                  Davie, "Aggregation of RSVP for IPv4 and IPv6
                  Reservations", RFC 3175, September 2001.

   [RFC3181]      Herzog, S., "Signaled Preemption Priority Policy
                  Element", RFC 3181, October 2001

   [RFC3182]      Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
                  T., Herzog, S., and R. Hess, "Identity Representation
                  for RSVP", RFC 3182, October 2001.

   [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                  LSP Tunnels", RFC 3209, December 2001.

   [RFC3270]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                  Vaananen, P., Krishnan, R., Cheval, P., and J.
                  Heinanen, "Multi-Protocol Label Switching (MPLS)
                  Support of Differentiated Services", RFC 3270, May
                  2002.

   [RFC3303]      Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
                  and A. Rayhan, "Middlebox communication architecture
                  and framework", RFC 3303, August 2002.

   [RFC3473]      Berger, L., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
                  RFC 3473, January 2003.

   [RFC3477]      Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                  Links in Resource ReSerVation Protocol - Traffic
                  Engineering (RSVP-TE)", RFC 3477, January 2003.

   [RFC3520]      Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
                  "Session Authorization Policy Element", RFC 3520,
                  April 2003.

   [SGV02]        R. Sofia, R. Guerin, and P. Veiga, "An Investigation
                  of Inter-Domain Control Aggregation Procedures",
                  International Conference on Networking Protocols, ICNP
                  2002, Paris, France, November 2002.

   [SGV03]        R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-
                  segment Inter-domain Control Aggregation Protocol.
                  High Performance Switching and Routing, HPSR 2003,
                  Turin, Italy, June 2003.

   [SGV03b]       R. Sofia, R. Guerin, and P. Veiga. A Study of Over-
                  reservation for Inter-Domain Control Aggregation
                  Protocols. Technical report (short version under
                  submission), University of Pennsylvania, May 2003,
                  available at http://einstein.seas.upenn.edu/mnlab/
                  publications.html.

   [TBA01]        A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A
                  Resource Reservation Protocol for an Integrated
                  Services Network with Mobile Hosts", Wireless
                  Networks, vol. 7, no. 1, pp. 5-19, 2001.

   [Thom02]       M. Thomas, "Analysis of Mobile IP and RSVP
                  Interactions", Work in Progress, October 2002.

   [Tsch03]       H. Tschofenig, "RSVP Security Properties", Work in
                  Progress, February 2004.

   [ZDSZ93]       L. Zhang, S. Deering, D. Estrin, and D. Zappala,
                  "RSVP: A New Resource Reservation Protocol", IEEE
                  Network, Volume 7, Pages 8-18, September 1993.

   [URL1]         http://www.atm.tut.fi/list-archive/diffserv/thrd3.html

   [URL2]         OPENSIG http://comet.columbia.edu/opensig/

   [URL3]         SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
                  siglite.html

---

Authors' Addresses 🎀

okay, the authors are finally getting their moment 🥹 here's where you can find them, bestie 💖

   Jukka Manner
   Department of Computer Science
   University of Helsinki
   P.O. Box 68 (Gustav Hallstrominkatu 2b)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-191-51298
   Fax:   +358-9-191-51120
   EMail: jmanner@cs.helsinki.fi


   Xiaoming Fu
   Institute for Informatics
   Georg-August-University of Goettingen
   Lotzestrasse 16-18
   37083 Goettingen
   Germany

   Phone: +49-551-39-14411
   Fax:   +49-551-39-14403
   EMail: fu@cs.uni-goettingen.de

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2005). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors keep their rights, but only as BCP 78 spells out 💅

This document and the information in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim everything below. Read this part carefully, bestie, it's serious 😭

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🦋

The IETF doesn't take a side on whether any Intellectual Property Rights, or other rights someone might claim, are valid or in scope for the technology in this document. It also doesn't say whether a license for those rights is available, or whether one could be. And it hasn't independently looked for any such rights, so no promises there ✨ For the rules on rights in RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. Implementers and users can look there too 🙈

The IETF also invites anyone interested to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Bring receipts 📮

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to the Internet Society for keeping the RFC Editor running, you're a real one 🌈👑