A survey of internet QoS signaling <s> SINGLE-TIER QOS SIGNALING <s> RSVP has been designed to support resource reservation in the Internet. However, it has two major problems: complexity and scalability. The former results in large message processing overhead at end systems and routers, and inefficient firewall processing at the edge of the network. The latter implies that in a backbone environment, the amount of bandwidth consumed by refresh messages and the storage space that is needed to support a large number of flows at a router are too large. We have developed a new reservation mechanism that simplifies the process of establishing reserved flows while preserving many unique features introduced by RSVP. Simplicity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability and resource sharing among multiple senders are also supported in the proposal.The proposed mechanism, YESSIR (YEt another Sender Session Internet Reservations) generates reservation requests by senders to reduce the processing overhead, builds on top of RTCP, uses soft state to maintain reservation states, supports shared reservation and associated flow merging and is compatible with the IETF Integrated Services models.YESSIR extends the all-or-nothing reservation model to support partial reservations that improve over the duration of the session.To address the scalability issue, we investigate the possibility of using YESSIR for per-stream reservation and RSVP for aggregate reservation. <s> BIB001 </s> A survey of internet QoS signaling <s> SINGLE-TIER QOS SIGNALING <s> We present the design, implementation, and evaluation of INSIGNIA, an IP-based quality of service framework that supports adaptive services in mobile ad hoc networks. The framework is based on an in-band signaling and soft-state resource management approach that is well suited to supporting mobility and end-to-end quality of service in highly dynamic environments where the network topology, node connectivity, and end-to-end quality of service are time varying. Architecturally INSIGNIA is designed to support fast reservation, restoration, and end-to-end adaptation based on the inherent flexibility and robustness and scalability found in IP networks. We evaluate the framework, paying particular attention to the performance of the in-band signaling system, which helps counter time-varying network dynamics in support of the delivery of adaptive services. Our results show the benefit of our framework under diverse mobility, traffic, and channel conditions. <s> BIB002 </s> A survey of internet QoS signaling <s> SINGLE-TIER QOS SIGNALING <s> The COPS protocol has been designed to enable communication on the interface between the policy decision administrator and the policy enforcement devices in a policy-based networking environment. It can be recognized that on the same interface there is the need to transfer information related to the request of resource by QoS clients and for the allocation of resources by resource allocation servers (e.g., bandwidth broker) in a DiffServ network. Hence, it is sensible to add this resource allocation functionality in the COPS framework. In particular, there are at least two cases where it is sensible to use COPS. The first case is on the interface between an edge node and a resource control node for handling resource allocation in a network provider domain. The second case is on the interface between a customer (client of a QoS enabled network) and the network provider: here COPS can be used as a protocol to signal dynamic admission control requests. In this article we present the definition of a new COPS client type to support the above-mentioned functionality, then describe an application scenario where SIP-based IP telephony applications can use Diffserv-based QoS networks. Simple backward-compatible enhancements to SIP are needed to interact with COPS/Diffserv QoS. A testbed implementation of the proposed solutions is finally described. <s> BIB003
Single-tier signaling offers end-to-end QoS guarantees assuming a homogeneous QoS architecture for the Internet, where all routers support the same QoS mechanisms. Single-tier signaling traverses the end-to-end path between the communicating users following standard IP routing, and establishes and maintains a QoS state in every intermediate IP router. The subsequent data packets follow the same route with the QoS signaling and take advantage of the specific QoS behavior that the signaling has configured in routers along the path (Fig. 1) . A major representative of single-tier signaling is RSVP, designed for application in a homogeneous end-to-end IntServ architecture. RSVP provides uni-directional reservation of resources for each application data flow, and adopts a receiver-based resource reservation approach for QoS sessions, suited for handling reservations in a multicast environment. Resources are reserved and respective soft states are installed for each data flow on RSVP-aware routers along the path, using a two-pass signaling scheme (Fig. 2) . The sender initi-ates the signaling procedure by sending an end-to-end PATH message (message 1 in Fig. 2 ) toward the receiver, in order to inform the receiver about the traffic shape of the data flow and the available resources of routers along the path. The traffic characteristics of the source and the requested QoS service type are represented by specific objects inside the RSVP messages. The PATH message installs route-specific soft states in all traversing routers, in order to enable the response messages to follow the reverse path back to the sender. The receiver responds with a RESV message (message 2 in Fig. 2 ) that performs the actual reservation of resources along the path. Admission and policy control takes place in each traversed RSVP router. The RESV message is sent hop-by-hop between routers following the reverse path, according to the route-specific state established by the PATH message. Merging of the various reservation messages heading for the same sender takes place along the route, allowing for efficient multicast reservations. As a result of the aforementioned signaling procedure, reservation and signaling soft states are installed in all RSVP-enabled routers along the path, which are maintained by periodic end-to-end refresh messages. While RSVP succeeds in assuring QoS separately for each data flow, it has received criticism regarding the complexity and the processing overhead it implies in routers. Since the amount of states stored in each router increases linearly with the number of traversing QoS flows, the number of states stored inside routers can raise scalability issues, especially in backbone routers that handle a large volume of traffic. Moreover, the use of refresh messages transmitted periodically for each flow has been accounted for contributing to signaling and processing overhead inside the network. The latter has been addressed in  where, among other optimizations, the use of a Bundle message is proposed, which consists of a bundle header and a body carrying multiple RSVP messages dealing with separate sessions. As an alternative to RSVP, YESSIR (YEt another Sender Session Internet Reservation) BIB001 is proposed for uni-directional per-flow reservation within the IntServ QoS model. YESSIR is built as an extension of the RTCP (Real Time Control Protocol) protocol, an in-band control protocol for RTP flows. The YESSIR design is based on the assumption that a large fraction of applications requiring guaranteed quality of service are real-time applications, and as such will use the RTP (Real-time Transport Protocol) to deliver their data. RTCP is used for the transportation of the YESSIR reservation messages. Soft reservation states are installed on each router along the path, as the RTCP/YESSIR message travels from the sender to the receiver (Fig. 3) . Reservations are installed along the path following a one-pass sender-based reservation mechanism. YESSIR seems to perform better than RSVP in terms of reservation set-up time, signaling processing, and message overhead. Measurements BIB001 indicate that YESSIR reservation setup time is three times faster than that of RSVP, and that the YESSIR refresh message processing overhead is approximately half of that of RSVP refresh. Moreover, YESSIR is designed to take advantage of the RTP and RTCP protocol features and avoids the implementation of an independent reservation protocol. Boomerang  is another reservation protocol designed with simplicity in mind. Boomerang establishes per-flow bidirectional reservations, using a single protocol message. The Boomerang reservation message is sent by the initiating node (which may be the sender or the receiver) to the far-end node, where it is echoed back to the initiating node. Resources are allocated hop-by-hop (using soft states) in all routers traversed by the reservation message in both directions (Fig. 4) . When the initiating node receives the Boomerang message, it verifies the success of the reservation by examining the appropriate message flags set in the message by the routers along the path. Reservation messages are then sent periodically from the initiating to the far-end node to keep the reservation alive along the upstream and downstream paths. The Boomerang message is routed according to standard routing procedures. This ensures that the reservation will be made along the correct path for both upstream and downstream traffic and eliminates the need for storage of routespecific states along the path. Signaling states are also eliminated from the routers, due to the use of a single reservation message. However, per-flow reservation states are still installed in each router along the path. Boomerang's short messages, along with the elimination of routing and signaling states, contribute to an enhanced protocol performance, especially in terms of processing overhead. Based on implementation results  , Boomerang signaling overhead (in terms of bytes/sec) is about four to six times lower than that of RSVP. Boomerang also results in lower memory and processing requirements in routers when compared to RSVP. The Boomerang memory gain is around 400 bytes/flow and the processing gain ranges between two and four, depending on the specific type of message processed. Similar to RSVP, both YESSIR and Boomerang propose the storage of per-flow QoS states in all routers along the path, which is a major point of criticism due to scalability reasons. Regarding Boomerang, however, a protocol extension has been proposed in  for aggregating per-flow states in routers, when necessary. In addition, both YESSIR and Boomerang follow the soft state approach introduced by RSVP. As a result, they use refresh mechanisms for keeping the reservations alive, which adds to the signaling overhead. Moreover, YESSIR caters to RTP traffic only. INSIGNIA BIB002 is a QoS protocol proposed for the support of adaptive services in mobile ad-hoc networks. INSIGNIA is an in-band signaling system that supports restoration and adaptation of the reserved resources to the continuously changing conditions of the ad-hoc networks. The INSIGNIA control messages are transported inside IP data packets (using IP header options), which follow the dynamic routing protocols proposed for ad-hoc networks, and install per-flow soft states in traversed routers. In general, in-band signaling systems are considered to be well suited to the rapidly changing environment of mobile ad-hoc networks, enabling fast resource reservation and restoration after topology changes. Simulation results study the effect of mobility on the INSIGNIA network performance (i.e., percentage of packets delivered as QoS packets, as best-effort packets, or being lost) and show that INSIGNIA supports relatively constant QoS delivery (approximately 80 percent of packets receive QoS) under slow and moderate mobility conditions (between three/six and 18 km/h) BIB002 . Overall, single-tier signaling assumes a homogeneous QoS architecture being applied end-to-end in the Internet, which is not usually the case. This simplified assumption, however, eliminates any interworking issues between different QoS protocols in the domain boundaries, adding to the simplicity of the QoS protocol implementation. The simplicity of this signaling category is further emphasized by the use of standard routing procedures throughout the network for routing the QoS signaling messages. Concluding this section, we would also like to present an alternative method for supporting QoS that does not, however, directly involve the reservation of resources. This proposal suggests the use of the Session Initiation Protocol (SIP)  . SIP is a request-response protocol for initiating and managing communications sessions in the Internet. SIP intentionally does not involve itself with the reservation of resources and can, in principle, work independently from the resource reservation protocol that may be used along the data path. Regarding QoS, SIP could provide the transport mechanism enabling QoS negotiation, policy, and AAA (authentication, authorization, and accounting) enforcement. QoS negotiation is enabled via the transport inside the SIP messages of Session Description Protocol  objects that describe the capabilities of the end-hosts and the characteristics of the connection (e.g., media, bandwidth codec, etc.). Regarding AAA/policy enforcement, SIP provides a universal transport means to carry AAA/policy requests to the local AAA/policy server, which has the authority to grant or deny access to local (edge router) or remote resources (through brokering with peer servers). SIP does not perform the actual reservation of resources, which is assured by the underlying reservation protocol (e.g., RSVP). It is important, however, that appropriate coordination exists between the two protocols so that requested resources are reserved before the data communication between the end systems begins  . Moreover, to alleviate the user terminal from QoS resource functionality implementation, SIP extensions are proposed in BIB003 (Q-SIP protocol). These extensions allow for terminal QoS request information to be transported inside Q-SIP messages. Q-SIP messages are addressed to specially designed proxies inside the network that are responsible for performing the actual reservation of resources.