A survey of internet QoS signaling <s> BACKGROUND <s> This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation. <s> BIB001 </s> A survey of internet QoS signaling <s> BACKGROUND <s> In this paper we propose a two-tier resource management model for the global Internet. Our solution resembles the current two-tier routing hierarchy and allows individual administrative domains to independently make their own decisions on strategies and protocols to use for internal resource management and QoS support. The aggregate traffic crossing domain borders is served according to relatively stable, long-lived bilateral agreements. End-to-end QoS support is achieved through the concatenation of such bilateral agreements. We describe in detail a realization of this two-tier model, where a bandwidth broker (BB) acts as the resource manager for each administrative domain, neighboring bandwidth brokers communicate with each other to establish inter-domain resource agreements. As an illustrative example in this paper we used a simplified RSVP as an intradomain resource allocation protocol for the aggregate traffic between border routers. Our simulation results show that this two-tier design can provide effective end-to-end QoS support for user applications. <s> BIB002
The Internet community soon realized the vision of end-toend QoS services and introduced the Integrated Services (IntServ) architecture BIB001 to implement this vision into specifications. IntServ supports end-to-end signaling, QoS state establishment, and management for per-flow differentiated treatment in intermediate routers along the data path. The signaling protocol that emerged to meet the integrated services requirements is RSVP (Resource reSerVation Protocol)  . The IntServ architecture was designed to facilitate every QoS element (router functionality, signaling, and accounting) in a fine-grained manner. To achieve this goal, IntServ was founded on the underlying assumption that a homogeneous Internet environment equipped with IntServ-enabled routers and end hosts would be the common case. The IntServ architecture in general and the RSVP protocol in particular received criticism, mainly due to the scalability issues raised by the state maintenance for every data flow in intermediate routers across the end-to-end path. Therefore, the Internet community considered other alternatives to the QoS provision problem. This time the target was a lightweight QoS architecture putting as little burden on the routers as possible and providing coarse-grained traffic prioritization based on the statically contracted service level agreements (SLAs) between users and the network. SLAs specify the amount and types of traffic each side has agreed to send and receive. The outcome was DiffServ (Differentiated Architecture)  . DiffServ networks are statically configured to support a small set of QoS levels (per hop behaviors (PHBs)) and do not use any QoS signaling for state establishment and maintenance in routers. DiffServ routers prioritize the data packets according to a six-bit field in the IP packet header (DiffServ code point (DSCP)) that reflects the requested QoS level. This procedure results in aggregating reservations for different users sharing the same QoS level. Appropriate packet marking takes place either at end-hosts or at DiffServ edge routers before the traffic enters the DiffServ network. In addiition, DiffServ edge routers perform traffic classification and traffic conditioning procedures (including metering, marking, shaping, and policing) based on the contracted SLAs. The DiffServ model is simple and avoids processing complexity and signaling overhead in network routers (especially in interior routers). Furthermore, it does not mandate any specific QoS protocol implementation to the end-user application. DiffServ, however, is rather rigid since the users cannot dynamically change the amount of reserved resources according to their current traffic requirements. Moreover, the aggregation of different flows belonging to the same QoS level can result in an unfair distribution of resources among the flows inside the same aggregate (e.g., due to the aggressiveness of some bursty flows). For all the aforementioned reasons, statically configured QoS domains, unless being highly over-provisioned, may fail to offer the agreed QoS to the users. Furthermore, the realization of the fact that the Internet is a concatenation of technologically and administratively different domains (autonomous systems (ASs)) led to the identification of separate QoS techniques for the efficient support of intra-and inter-domain QoS. Thus, a two-tier resource management model was proposed in BIB002 , with the intra-domain QoS signaling performing resource management inside a domain, and the inter-domain signaling managing resource allocation between domains. The two tiers must be closely coordinated to enable provision of the necessary end-to-end QoS support. The two-tier model increases the degrees of freedom regarding end-to-end QoS support, since each domain is free to choose any QoS support mechanism for allocating resources internally, as long as proper co-operation takes place with the respective inter-domain signaling protocol.