Network Working Group Jyh-Cheng Chen INTERNET-DRAFT Anthony McAuley Internet Engineering Task Force Armando Caro draft-itsumo-wireless-diffserv-00.txt Telcordia Technologies Date: July 2000 Expires: January 2001 Shinichi Baba Yoshihiro Ohba Toshiba America Research Inc. Parameswaran Ramanathan University of Wisconsin, Madison QoS Architecture Based on Differentiated Services for Next Generation Wireless IP Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of sections 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a QoS architecture framework with preliminary protocol specifications for next generation wireless IP networks. The architecture is based on differentiated services in that traffic are aggregated and forwarded in backbone network based on per hop behaviors. In the proposed architecture, there is at least one global server and several local nodes in each administration domain. The server is referred to as the QoS Global Server (or QGS), and local nodes are referred to as QoS local nodes (or QLN). QLNs are ingress nodes of the DS (Differentiated Service) domain. They reside generally in the edge of wired backbone networks. The QGS retains the global information of the domain, and informs QLNs what to do when traffic comes in. The J.-C. Chen et al Expires January 2001 [Page 1] Internet Draft Wireless Diffserv July 2000 mobile station (MS) has the QoS signaling with QGS only. Once the QoS signaling is done, the QGS updates the QoS profile in each QLN. The MS is then free to move within the same domain without other QoS signaling. The actual traffic generated by MS goes through QLN only. The QGS is in control plane and QLNs are in transport plane. By retaining the global information in central server and separating control and transport, the architecture is flexible, easy to add new services, and more efficient for mobile environment. 1. Introduction 1.1. Purpose and scope There are two forces driving the trend towards third generation (and beyond) wireless IP technology. Users' demand perpetual ubiquitous access to the Internet and providers' desire to deploy a flexible wireless and wireline IP platform that supports heterogeneous services economically, which will allow them to capture a share of this growing market. Furthermore, the current wisdom is that the existing circuit switched and 2G (second generation) wireless systems will eventually evolve/morph into an end-to-end IP platform that provides ubiquitous real-time as well as non-real-time services. ITSUMO [ITSUMO00] is a research project that focuses on the design of next generation IP networks. It envisions an end-to-end wireless/wireline IP platform for supporting real-time and non-real-time multimedia services in the future. Its goal is to use IP and next generation wireless technologies to design a wireless platform that allows mobile users to access all services on a next generation Internet. The objective of this document is to present a QoS architecture based on differentiated services (diffserv) [DIFF98] and ITSUMO architecture for next generation wireless IP networks, and present the preliminary specifications of the protocols built upon the proposed wireless and mobile QoS architecture. This document focuses more on architecture framework rather than detailed protocols, which will be presented in other document(s). 1.2. Architecture of a next generation wireless IP network Figure 1 depicts the end-to-end packet platform of ITSUMO's all IP wireless/wireline network, which comprises all IP wireless access networks and a packet switched IP backbone network. The IP backbone network is an end-to-end wireline IP infrastructure that will comprise regional providers' wireline IP networks that are connected through the Internet. Besides mobile stations/terminals, a wireless access network also comprises a radio access network (RAN), and an edge router and controller (ERC) [ITSUMO99]. In order to support the needs of its users, a wireless access network interacts with the network control entities that are shown as Domain Control Agent (DCA) in Figure 1. What follows is a brief description of these elements and their functions. 1.2.1. Mobile Station (MS) J.-C. Chen et al Expires January 2001 [Page 2] Internet Draft Wireless Diffserv July 2000 It is the user mobile terminal that allows users to communicate, and also provides means of interactions and control between users and the network. 1.2.2. Radio Access Network (RAN) The radio access network (RAN) represents the wireless and back-haul infrastructure that provides MSs with wireless access to the wireline infrastructure. A RAN usually comprises a set of base stations and base station controllers. In IMT-2000 [IMT97], RANs use programmable software radios to provide flexibility across frequency bands at the MS and across the RAN. ITSUMO strives to remain independent from the underlying RAN technology and to minimize the restriction (or requirements) that it places on (or expects from) a RAN. 1.2.3. Edge Router & Controller (ERC) An ERC is a routing and control system that connects a wireless access network to a regional wireline IP network. Although Figure 1 depicts one RAN per ERC, in practice, each ERC may support several RANs. An ERC comprises two functional entities, an edge router (ER) and an edge control agent (ECA). The ER is an IP router, while the ECA is an intelligent agent that interacts with the domain control agent (DCA) to control the RANs as well as support necessary network-wide control tasks. In the IP parlance, each ERC is the default gateway of all IP MSs that are supported by RANs that are connected to it. 1.2.4. Domain Control Agent (DCA) The domain control agent (DCA) provides connection management as well as means for interaction between users and network control system and interaction among network control entities. Furthermore, the DCA also supports: (1) Mobility management, (2) Authentication, Authorization, and Accounting (AAA), and (3) QoS management (MAAAQ) functions for mobile users. These functional entities usually reside on the wireline backbone, and are part of the overall control system of the end-to-end platform. As Figure 1 indicates the home and visiting DCA entities may either interact directly or via a third party Inter-Domain Control Agent (IDCA) on the global Internet. In the latter case, the IDCA entity serves as a trusted broker between the home and visiting network DCAs. <-- Visiting Network --> <---- Home Network ----> +---------------+ | Inter-Domain | | Control Agent | +---------------+ | | +---------------+ | +---------------+ | Domain | | | Domain | | Control Agent | | | Control Agent | J.-C. Chen et al Expires January 2001 [Page 3] Internet Draft Wireless Diffserv July 2000 +---------------+ | +---------------+ | | | ___|___ ___|___ ___|___ / \ / \ / \ / \ / \ / \ /Regional IP\___________/ Internet \___________/Regional IP\ \ Network / \ / \ Network / \ / \ / \ / ---\_______/--- \_______/ ---\_______/--- | | | | +-----+ +-----+ +-----+ +-----+ | ERC | | ERC | | ERC | | ERC | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | __|__ __|__ __|__ __|__ / \ / \ / \ / \ / Radio \ / Radio \ / Radio \ / Radio \ / Access \ / Access \ / Access \ / Access \ \ Network / \ Network / \ Network / \ Network / \ / \ / \ / \ / \_____/ \_____/ \_____/ \_____/ | | | | v v v v +----+ +----+ +----+ +----+ | MS | | MS | | MS | | MS | +----+ +----+ +----+ +----+ FIGURE 1: ITSUMO long term network architecture 1.3. Related ITSUMO documents The overall architecture of ITSUMO is presented in [ITSUMO00]. The Signaling of ITSUMO can be found in [ITSUMO00] too. [DRCP99] presents the dynamic registration and configuration in mobile environment. Host mobility management based on SIP [SIP99] is the topic in [HMMP99]. Authentication, Authorization, and Accounting (AAA) is the focus in [3AREQ00]. The ITSUMO evolutionary architecture to interconnect legacy networks is shown in [ITSUMO99] and [ITSUMO00]. 1.4. Overview The QoS architecture proposed in this document is based on Differenticiated Services. Two key characteristics of the architecture are: (1) there is a central server which has global information of the whole administration domain, and several local ingress nodes which feed the local information to the central server; and (2) the QoS signaling and transport are separated in that the central server deals with the QoS signaling and local nodes handle actual transport traffic. Based on these two characteristics, many QoS requirements in next generation mobile environment can be achieved efficiently. It also provides flexibility for different QoS session management which can be either based on reservation or provisioning. The architecture is J.-C. Chen et al Expires January 2001 [Page 4] Internet Draft Wireless Diffserv July 2000 also easy to integrate with other protocols. This document presents the QoS architecture framework with high level view of the necessary protocols. The architecture are depicted, but the detailed protocols will be presented in other documents. 1.5. Organization of the document Rest of the document is organized as follows. Section 2 describes the QoS requirements for next generation wireless IP networks. Section 3 presents the QoS architecture including the preliminary protocol specifications. Section 4 states how the architecture could potentially meet the requirements listed in Section 2. Section 5 summarizes the documents with concluding remarks. 2. QoS Requirements for Next Generation Wireless IP Networks 2.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ97]. 2.2. Requirements We envision that the followings are the QoS requirements in next generation wireless IP networks. 2.2.1. It MUST support mobility. Since the users in next generation wireless networks are expected to be highly mobile, the mobility support SHOULD NOT be based on static provisioning. It MUST support certain types of critical services, such as E911, anytime anywhere for anyone. 2.2.2. It MUST be able to change the SLS (Service Level Specification) dynamically. The dynamic SLS MUST be able to be done per session. The services provided MUST not tie to a fixed path/location. 2.2.3. It MUST support tight end-to-end QoS guarantees for certain types of services, such as IP telephony or video conferencing. It MUST guarantee strict end-to-end QoS (delay, loss, etc.) for certain types of services. 2.2.4. It MUST support QoS for multiple classes of traffic with different QoS requirements. The support of multiple classes of traffic MUST not depend on the traffic load. 2.2.5. It MUST be interoperable and administrable between different service providers and with legacy networks. 2.2.6. It MUST be scalable. 2.2.7. It SHOULD support multicast. Multicast will potentially save the bandwidth which is particularly critical in wireless networks. J.-C. Chen et al Expires January 2001 [Page 5] Internet Draft Wireless Diffserv July 2000 2.2.8. It SHOULD be simple. It SHOULD be easy to implement. 2.2.9. It SHOULD not incur too much overhead. For example, round-trip delay for QoS setup and frequency for QoS update SHOULD be minimized. 2.2.10. It SHOULD interoperate with other IETF protocols. It SHOULD integrate with other functionality in the whole system. For example, QoS negotiation can be integrated with call signaling and/or registration. QoS SHOULD interoperate with AAA. 2.2.11. It MAY support both aggregated and per-flow QoS guarantee. 2.2.12. It MAY support both receiver-initiated and sender-initiated QoS. 2.2.13. It MAY interoperate/integrate with link layer. 3. QoS Architecture for Next Generation Wireless IP Networks Based on the requirements listed in last section, we proposed a QoS architecture for next generation wireless networks based on diffserv model. The proposed model is based on the ITSUMO architecture in which there is at least one global server and several local nodes in each administration domain. The server is referred to as the QoS Global Server (or QGS), and local nodes are referred to as QoS local nodes (or QLN). QLNs are ingress nodes of the DS (Differentiated Service) domain. They reside generally in the edge of wired backbone networks. The QGS retains the global information of the domain, and informs QLNs what to do when traffic comes in. The mobile station (MS) has the QoS signaling with QGS. Once the QoS signaling is done, actual traffic generated by MS goes through QLNs. Therefore the QGS is in control plane and QLNs are in transport plane. By separating control and transport, the architecture is flexible, easy to add new services, and more efficient for mobile environment. The following sections detail the architecture, services, and protocols. <----------- DOMAIN 1 -----------> <---------- DOMAIN 2 -------------> +--------------+ +---------------+ | QoS Global | | QoS Global | | Server (QGS) | | Server (QGS) | +--------------+ +---------------+ | | ___|___ _______ ___|___ / \ / \ / \ / \ / \ / \ /Regional IP\__________/ Global IP \__________/Regional IP\ \ Network / \ Network / \ Network / \ /---------\ \ / ----------\ / --\_______/--- \ \_______/ | \_______/----- | | \ | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | QLN | | QLN | | QLN | | QLN | | QLN | | QLN | J.-C. Chen et al Expires January 2001 [Page 6] Internet Draft Wireless Diffserv July 2000 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ __|__ __|__ __|__ __|__ __|__ __|__ / \ / \ / \ / \ / \ / \ / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ / Access \ / Access \ / Access \ / Access \ / Access \ / Access \ \ Network / \ Network / \ Network / \ Network / \ Network / \ Network / \ / \ / \ / \ / \ / \ / \_____/ \_____/ \_____/ \_____/ \_____/ \_____/ | | | | | | v v v v v v +----+ | MS | --> +----+ FIGURE 2: QoS architecture 3.1. Architecture and Components The overall architecture is depicted in Figure 2. In addition to other necessary components in the system such as DHCP[DHCP97]/DRCP[DRCP99] server, AAA, etc., there are three major QoS components: 3.1.1. MS (mobile station): MS is the device that allows users to communicate, and also provides means of interaction between users and the networks. Traffic is generated/received by MS and may be queued in the MS while waiting for transmission/reception. 3.1.2. QGS (QoS global server): As shown in Figure 2, there is one logical QGS in each administration domain. The QGS has the global information about the resources available in the whole domain. The MS interacts with QGS, if necessary, when the MS requests certain degrees of QoS in this domain. The QGS is the entity for QoS negotiation and signaling between MS and the network control system, i.e. it is for QoS control. The QGS decides what services are available for each MS and sends the decisions to particular QLNs. Thus, the QGS is an intelligent entity residing in the control plane for QoS negotiation and signaling. 3.1.3. QLN (QoS local node): QLN is the ingress node of the DS domain. QLN generally resides in the edge of the network. Figure 2 depicts that QLN could be part of ERC (Edge Router & Controller), or could reside in a component inside RAN (radio access network) such as BS (base station). QLN has the local information about the resources in the local domain. However QLN does not interact with MS directly for QoS negotiation and signaling. In stead, this local information is provided to QGS periodically. QLN maintains a table which is then updated by QGS periodically too. Based on this table, QLN will mark, police, shape, etc. the traffic going through it. It is the entity for transporting. Comparing to QGS, it is less intelligent. Please note, the QGSs in domain 1 and domain 2 may contact with each other directly, or through a public QGS which may attach to J.-C. Chen et al Expires January 2001 [Page 7] Internet Draft Wireless Diffserv July 2000 the "Global IP Network" in Figure 2. 3.2. Services Without lost of generality, we use the following different types of service classes for illustration. Each class is mapped to a combination of two QoS parameters: latency and loss. The entire spectrum of possible combinations is illustrated in Figure 3. The figure shows X and Y axes which represent latency and loss, respectively. Hence, every plot maps to a particular class. For example, a QoS parameter combination consisting of moderate latency and low loss maps to Class-B1. High 3 -|- | | | L Moderate 2 -| O | S | S | Low 1 -|- | | | None 0 -|--------|---------|---------|- A B C Low Moderate High LATENCY FIGURE 3: Spectrum of service classes and their mapped QoS Table 1 presents some example application(s) for each service class explained below. N/A in the table is used to indicate that "no application is identified". 3.2.1. Class-A0: Class-A0 is considered to be a class of mission critical traffic such as network control and E911 traffic. This kind of traffic cannot be lost or delayed. 3.2.2. Class-A1: Class-A1 is considered to be a class of real-time traffic (i.e., low delay) that only tolerates low levels of packet loss. This would include telephony, video conferencing, and real-time audio/video. These types of transmissions are able to deliver adequate levels of quality while experiencing low levels of packet loss. 3.2.3. Class-A2: Similar to Class-A1, Class-A2 is considered to be a class of real-time traffic. However, this type of traffic allows more moderate levels of loss. This could again include video conferencing and real-time video, but perhaps J.-C. Chen et al Expires January 2001 [Page 8] Internet Draft Wireless Diffserv July 2000 not telephony or real-time audio. In some scenarios, users may accept the video quality provided at moderate levels of packet loss. Telephony and audio, on the other hand, usually are not acceptable unless the packet loss is kept low. 3.2.4. Class-A3: Class-A3 is considered to be a class that tolerates only low levels of delay, but high levels of packet loss. 3.2.5. Class-B0: Class-B0 is considered to be a class which tolerates some moderate delay in transmission, but packet loss is unacceptable. File transfer and remote login are example applications that may require such a classification. 3.2.6. Class-B1: Class-B1 is considered to be a class which is a little more lenient than Class-B0. In addition to tolerating moderate latency, it will also allow some low levels of packet loss. Web browsing is an application that fits nicely into this class. In addition, it may sometimes be adequate for remote logins to have low levels of loss. 3.2.7. Class-B2: Class-B2 is considered to be a class which tolerates moderate levels of delay and loss. 3.2.8. Class-B3: Class-B3 is considered to be a class which tolerates moderate levels of delay and high levels of loss. 3.2.9. Class-C0: Class-C0 is considered to be a class which can tolerate high levels of delay, but absolutely no packet loss. Applications such as email, network news, paging services fit this classification perfectly. File transfer may also be classified into this type of traffic if the user does not mind waiting long periods of time for the completion of transfers. 3.2.10. Class-C1: Class-C1 is considered to be a class which tolerates high levels of delay and low levels of packet loss. Some users may not consider their pages to be critical and will accept that their paging services have some loss. For example, a medical surgeon's pages are very critical and should therefore not be classified into Class-C1, but instead into Class-C0. 3.2.11. Class-C2: Class-C2 is considered to be a class which tolerates high levels of delay and moderate levels of loss. 3.2.12. Class-C3: Class-C3 is considered to be a class which tolerates high levels of delay and loss. ============================================ SERVICE CLASS EXAMPLE APPLICATION(S) ============================================ Class-A0 | Control traffic | E911 -----------------+-------------------------- Class-A1 | Telephony J.-C. Chen et al Expires January 2001 [Page 9] Internet Draft Wireless Diffserv July 2000 | Video conferencing | Real-time audio/video -----------------+-------------------------- Class-A2 | Video conferencing | Real-time video | -----------------+-------------------------- Class-A3 | N/A -----------------+-------------------------- Class-B0 | File transfer | Remote login -----------------+-------------------------- Class-B1 | Web browsing | Remote login -----------------+-------------------------- Class-B2 | N/A -----------------+-------------------------- Class-B3 | N/A -----------------+-------------------------- Class-C0 | Email | Network News | Paging | File transfer -----------------+-------------------------- Class-C1 | Paging -----------------+-------------------------- Class-C2 | N/A -----------------+-------------------------- Class-C3 | N/A -----------------+-------------------------- TABLE 1: Example application(s) 3.3. Protocols and Algorithms Based on the architecture and services defined above, this section first describes the protocol for "Dynamic SLS", then the protocols and algorithms for each class of traffic. The mobility support is embedded in each sub-section as well. 3.3.1 Dynamic SLS The SLS (Service Level Specification) is usually agreed by both the user and the service provider when a user signs up with a service provider. To change the SLS in wired network, usually a user has to contact with the authority of the service provider. Once the negotiation is done, the user can utilize the new SLS. It is expected that the changing of SLS will be more often in next generation wireless IP networks due to the dynamics of the mobile environments. In addition, the change in SLS should be known by all ingress nodes in the DS domain so that the user can fully utilize the new SLS without exchanging any new messages while roaming. The dynamic SLS must be able to be done per session. Since the QGS has global information, dynamic SLS can be achieved easily and efficiently in our architecture. With the global information, the QGS allows MS dynamically negotiate SLS with it. J.-C. Chen et al Expires January 2001 [Page 10] Internet Draft Wireless Diffserv July 2000 The QGS may need to consult with home QGS and/or other servers, such as AAA, etc. Once the negotiation between the MS and the QGS is done, the QGS multicasts the decision to all QLNs in the same administration domain. The MS therefore is capable of utilizing the new SLS anywhere while it is moving within the same administration domain. Thus, dynamic SLS for mobile environment is achieved with only one negotiation in the same administration domain. After that, all QLNs know the new QoS profile. This saves the wireless bandwidth significantly. This dynamic SLS can also be done in different granularity, for example, per session, per hour, or per day, etc. Figure 4 depicts an example flow for dynamic SLS. QLNi represent all QLNs in the domain when the QGS multicasts the new SLS to all QLNs. QLNi means only the QLN(s) the actual traffic goes through when the MS transmits/receives the actual data. In Figure 4, messages with all capital letters are traffic in control plan, other messages are traffic in transport plan. The same convention will be used in the subsequent figures. AAA MS QGS Server QLNi | SLS UPDATE | | | |------------------>| | | | | AAA REQUEST | | | |------------------->| | | | AAA RESPOND | | | |<-------------------| | | | | | | | | | | NEW SLS | | |---------------------------------------->| | | ACK | | |<----------------------------------------| | SLS ACCEPT | | |<------------------| | | SLS ACK | | |------------------>| | | | | | | | actual traffic | |<----------------------------------------------------------->| | | QLNi: i = 1, ..., N, where N is the total number of QLN in the domain FIGURE 4: Example flow for dynamic SLS 3.3.2. Protocol 1 -- mission critical traffic In Section 3.2, Class-A0 is defined as a class of mission critical J.-C. Chen et al Expires January 2001 [Page 11] Internet Draft Wireless Diffserv July 2000 traffic which cannot be lost or delayed. The amount of this kind of traffic is usually predictable and is among a small portion of the total bandwidth. Since it is critical, there is no admission or connection control for it. Since it is predictable and the amount is small, we reserve a specific portion of bandwidth for it. The bandwidth reserved for Class-A0 is much larger than the predicted traffic. Therefore, it is reasonable to assume that the bandwidth for Class-A0 is never exhausted. The reserved bandwidth can be adjusted dynamically, and the unused bandwidth for this class can be allocated to other classes of traffic in temporary basis. As mentioned above, there is a global QGS and several local QLNs. QLN has the local information about the resources in local domain, and this local information is provided to QGS periodically. Based on the local information and the mobility pattern, the QGS envisions how much bandwidth should be reserved in each QLN for Class-A0. QGS then sends this information to QLN. As described before, the bandwidth reserved for Class-A0 is much larger than the expected Class-A0 traffic. When a MS pops up, it first performs registration and configuration to get an IP address. This can be done, for example, by DHCP or DRCP. When it wants to send Class-A0 traffic, it does not perform QoS negotiation and signaling with QGS. There is no admission or connection control. The Class-A0 traffic can always go through QLN directly to enter the DS domain. When the MS moves to other local domain of QLN, it gets a new IP address, if necessary. The Class-A0 traffic can go through the new QLN without any QoS negotiation and signaling as that in previous QLN. Figure 5 shows an example call flow for protocol 1. When a MS is turned on, it first acquires an IP address by DHCP protocol. Once the MS gets the IP address, it can transmit/receive Class-A0 traffic to/from QLN, the ingress node of the DS domain. This QLN provides new local traffic information to the QGS. The QGS then, for example, instructs the QLN to increase the reserved bandwidth for Class-A0, if the traffic of Class-A0 exceeds a certain threshold. When the MS moves to a new subnet, similarly it asks for a new IP address. After that, Class-A0 traffic still can go through the new QLN. DHCP MS Server QLNi QGS | DHCP DISCOVER | | | |---------------------->| | | | DHCP OFFER | | | |<----------------------| | | | DHCP REQUEST | | | |---------------------->| | | | DHCP ACK | | | |<----------------------| | | | | | | | | | | actual traffic | | |<-------------------------------------->| | J.-C. Chen et al Expires January 2001 [Page 12] Internet Draft Wireless Diffserv July 2000 | | NEW INFO | | |----------------->| | | UPDATE | | |<-----------------| | | ACK | | |----------------->| FIGURE 5: Example call flow for protocol 1 3.3.3. Protocol 2 -- real-time traffic Real-time services usually require low delay. The loss of packet could be either low or moderate depending on the nature of the traffic. Class-A1 and Class-A2 in Section 3.2 can use the protocols in this section. For this class of traffic, the MS must perform the QoS signaling with QGS for QoS request. Similar to Class-A0, the MS first performs registration and configuration with DHCP to get an IP address when it pops up. Before the MS sends actual traffic, it initiates the QoS signaling with the QGS. This QoS signaling may be part of SIP or AAA protocol. The QGS will also interact with AAA or other servers if necessary. Based on the interaction with other servers, the global information in QGS, mobility pattern, and the service level agreement and specification, the QGS will either admit or reject the QoS request. Since the QGS has the global information (bandwidth in each QLN, mobility pattern, etc.), the QGS will admit the request only when the bandwidth in potential QLNs the MS will roam to is available. Depending on mobility pattern and how strong the guarantee is required, the QGS will decide how many QLNs should be included in the initial set of potential QLNs. Typically, potential QLNs the MS will roam to while still maintains the same real-time session are the adjacent QLNs of current QLN. The MS is admitted only when there are bandwidths available in potential QLNs. The decision made by the QGS is multicast to current QLN and all potential QLNs. When the MS is roaming inside the same administration domain, i.e., the domain serving by the same QGS, the MS only needs to get a new IP address if changing subnet. It does not need to have any QoS signaling since the decision made by the QGS has been sent to all potential QLNs. Since the interaction between QGS and QLNs are updated periodically. The set of potential QLNs may be changed dynamically while the MS is moving. Thus the MS can transmit/receive real-time traffic through QLNs without initiating new QoS signaling while it is moving within the same administration domain. This saves the wireless bandwidth. Please note the bandwidth reserved ahead for real-time traffic in QLNs can be allocated to other classes of traffic in temporary basis as that in Class-A0. When the MS moves to a new administration domain, it must initiate the QoS signaling with the new QGS. The new QGS may consult with the new AAA server, old AAA server, and the old QGS to decide whether it should admit or reject the QoS request. After that, it J.-C. Chen et al Expires January 2001 [Page 13] Internet Draft Wireless Diffserv July 2000 is similar to what described above. Figures 6(a)-6(c) present example call flows for real-time traffic in different scenarios. In Figure 6(a), the MS uses DHCP to get an IP address for this subnet in the initial set-up. It then make a QoS request for the real-time session with the QGS. As described above, the QGS will make the decision based on several factors then decides to admit the request or not. Figure 6(a) shows that the QGS decides to admit the request. The QGS informs the potential QLNs (QLNi in Figure 6(a) represents the potential QLNs), and sends the QoS OFFER to the MS. After that the actual traffic can go through the QLN which is the ingress node of the DS domain. When the MS roams inside the same subnet, it does not need to do anything even though the QLN may be changed. If it roams to a new subnet, Figure 6(b) indicates that the MS only needs to acquire a new IP address. There is no need for new QoS signaling since the QLN has the QoS profile of the MS already. Figure 6(b) also shows that the information exchange between QGS and QLNs is done periodically. Therefore the potential QLNs and the QoS profile in each QLN can be changed dynamically. Figure 6(c) shows an example call flow when the MS roams to a new domain. For example, the MS roams from domain 1 to domain 2 in Figure 2. Similar to the case in Figure 6(a), the MS needs to contact with the DHCP server and the QGS. The difference is that the QGS in new domain may need to consult with previous QGS and other servers such as AAA server. After that, the MS is free to roam within the same domain without any QoS signaling as that before. DHCP AAA MS Server QGS Server QLNi | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | | QOS REQUEST | | | |---------------------------->| | | | | AAA REQUEST | | | |------------>| | | | AAA RESPOND | | | |<------------| | | | | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| J.-C. Chen et al Expires January 2001 [Page 14] Internet Draft Wireless Diffserv July 2000 | | | | QOS OFFER | | |<----------------------------| | | | | | | | | | actual traffic | |<------------------------------------------------------>| | | FIGURE 6(a): Example call flow for protocol 2a -- initial set-up DHCP AAA MS Server QGS Server QLNi | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | | | | | | | | | actual traffic | |<------------------------------------------------------>| | | | | | | | NEW INFO | | |<-------------------------| | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| FIGURE 6(b): Example call flow for protocol 2a -- changing subnet within the same domain New DHCP New New Previous Previous New MS Server QGS AAA QGS AAA QLNi | | | | | | | | DHCP | | | | | | | DISCOVER| | | | | | J.-C. Chen et al Expires January 2001 [Page 15] Internet Draft Wireless Diffserv July 2000 |-------->| | | | | | | DHCP | | | | | | | OFFER | | | | | | |<--------| | | | | | | DHCP | | | | | | | REQUEST | | | | | | |-------->| | | | | | | DHCP | | | | | | | ACK | | | | | | |<--------| | | | | | | | | | | | | QOS REQUEST | | | | | |------------------>| | | | | | | AAA | | | | | | REQUEST | | | | | |-------->| | | | | | AAA REQUEST | | | | |------------------>| | | | | AAA RESPOND | | | | |<------------------| | | | AAA | | | | | RESPOND | | | | |<--------| | | | | | | | | | SLS REQUEST | | | | |------------------>| | | | | SLS OFFER | | | | |<------------------| | | | | | | | | | | | | UPDATE | | |-------------------------------------->| | | ACK | | |<--------------------------------------| | QOS OFFER | | |<------------------| | | | | | | | actual traffic | |<--------------------------------------------------------->| | | FIGURE 6(c): Example call flow for protocol 2a -- roaming to a new domain 3.3.3.1. Alternative The protocol presented above can potentially save the wireless bandwidth. This is because it does not need new QoS signaling when the MS is moving within the same domain once the request is admitted. By looking at Figures 6(a)-6(c), one can see that QoS signaling between MS and network is only limited to the initial set-up or when roaming to a new administration domain. It also reduces the handoff blocking probability because the bandwidth in potential QLNs has been reserved before moving. It however may J.-C. Chen et al Expires January 2001 [Page 16] Internet Draft Wireless Diffserv July 2000 increase the connection blocking probability because the MS is admitted only when the bandwidth is available in potential QLNs. An alternative for real-time traffic based on the same QoS architecture is presented as follows. Similar to that described in last section, the MS gets a new IP address and performs QoS signaling with QGS. The QGS makes the admission control only based on the local information provided by the serving QLN. Instead of admitting the request based on the bandwidths in all potential QLNs, the connection request is admitted only if the bandwidth in current serving QLN is available. The decision made by the QGS is sent to the serving QLN. All other QLNs have certain bandwidth reserved for potential traffic of this class handed over from adjacent QLNs. When the MS moves to a new QLN, the MS performs the new QoS signaling with QGS. The QGS admits the handoff to the new QLN only when the reserved bandwidth for handoff in the new QLN is still available. If not, the connection is lost. The reserved bandwidth for handoff in QLNs can be carefully provisioned so that the handoff blocking probability can be minimized. Since QGS has the global information, it can decide the reserved bandwidth for handoff in each QLN more efficient. Similar to that in Class-A0, QGS can instruct the QLNs to dynamically change the reservation based on the global information. The merit of this alternative is to reduce the connection blocking probability. It however increases the messages for QoS signaling and may increase the handoff blocking probability. Figures 7(a) to 7(c) show example call flows for this alternative. Figure 7(a) and 7(c) are similar to Figure 6(a) and 6(c) except that the QGS only updates one specific QLN in Figure 7(a) and 7(c). When the MS moves within the same domain, Figure 7(b) indicates that the MS needs to initiate the QoS signaling similar to that in Figure 7(a) except that the QGS does not need to consult with the AAA server. Based on the local information, this protocol although has more QoS signaling messages when the MS moves and may increase the handoff blocking probability, it reduces the connection blocking probability. Because of admitting more connection requests, it may allow more real-time sessions comparing to protocol 2a. Based on the SLS with the user, the QGS can decide which protocol to use for real-time traffic. DHCP AAA MS Server QGS Server QLN | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | J.-C. Chen et al Expires January 2001 [Page 17] Internet Draft Wireless Diffserv July 2000 | QOS REQUEST | | | |---------------------------->| | | | | AAA REQUEST | | | |------------>| | | | AAA RESPOND | | | |<------------| | | | | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| | | | | QOS OFFER | | |<----------------------------| | | | | | | | | | actual traffic | |<------------------------------------------------------>| | | FIGURE 7(a): Example call flow for protocol 2b -- initial set-up DHCP AAA MS Server QGS Server QLN | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | | QOS REQUEST | | | |---------------------------->| | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| | | | | QOS OFFER | | |<----------------------------| | | | | | | | actual traffic | |<------------------------------------------------------>| | | | | | J.-C. Chen et al Expires January 2001 [Page 18] Internet Draft Wireless Diffserv July 2000 | | NEW INFO* | | |<-------------------------| | | | | | UPDATE* | | |------------------------->| | | ACK* | | |<-------------------------| *These messages are sent periodically between QGS and ALL QLNs. FIGURE 7(b): Example call flow for protocol 2b -- changing subnet within the same domain New DHCP New New Previous Previous New MS Server QGS AAA QGS AAA QLN | | | | | | | | DHCP | | | | | | | DISCOVER| | | | | | |-------->| | | | | | | DHCP | | | | | | | OFFER | | | | | | |<--------| | | | | | | DHCP | | | | | | | REQUEST | | | | | | |-------->| | | | | | | DHCP | | | | | | | ACK | | | | | | |<--------| | | | | | | | | | | | | QOS REQUEST | | | | | |------------------>| | | | | | | AAA | | | | | | REQUEST | | | | | |-------->| | | | | | AAA REQUEST | | | | |------------------>| | | | | AAA RESPOND | | | | |<------------------| | | | AAA | | | | | RESPOND | | | | |<--------| | | | | | | | | | SLS REQUEST | | | | |------------------>| | | | | SLS OFFER | | | | |<------------------| | | | | | | | | | | | | UPDATE | | |-------------------------------------->| | | ACK | | |<--------------------------------------| | QOS OFFER | | J.-C. Chen et al Expires January 2001 [Page 19] Internet Draft Wireless Diffserv July 2000 |<------------------| | | | | | | | actual traffic | |<--------------------------------------------------------->| | | FIGURE 7(c): Example call flow for protocol 2b -- roaming to a new domain 3.3.4. Protocol 3 -- non-real-time traffic For traffic generated by Class-B0 to Class-B3 and Class-C0 to Class-C3, there is no need for admission and/or connection control. When the MS first pops up, it performs registration and configuration to get an IP address as described above. The QoS profile and SLS of the user have been stored in the home QGS and/or QLNs when the user subscribes to the service provider. The MS does not need to perform QoS negotiation with the QGS unless the user wants to change the SLS, which can be done by the protocol in 3.3.1 - Dynamic SLS. However, the MS needs to inform the QGS about its presence when it first appears in the domain. The QGS then multicasts the QoS profile of the MS to all QLNs in the same administration domain, if necessary. The MS then can transmit/receive traffic regardless where the MS is moving. By this way, the new QLN does not need to ask the QoS profile from previous QLN each time when the MS is moving. If the MS moves to a new administration domain, the new QGS has to interact with the old QGS as that described in section 3.3.3. Based on the SLS, the QLN will perform necessary mechanisms such as policing, shaping, etc. The traffic therefore may be queued or dropped. Figure 8(a) indicates an example flow for protocol 3. When a MS is first present in the domain, it first asks an IP address from the DHCP server. It then notifies the QGS its existence. The QGS then consults with the AAA server and updates the QoS profiles in QLNs, followed by issuing ACK back to the MS. The consultation with AAA server and update with QLNs may not be necessary if QGS has performed the same procedure before. After the MS gets the ACK, it can transmit/receive actual traffic. Once the MS acquires an IP address successfully, the MS and QGS does not need to perform any specific QoS tasks when the MS moves within the same domain, except the MS may need to get a new IP address when it crosses subnet. This is shown in Figure 8(b). Figure 8(b) also shows that the QGS and QLNs exchange information periodically as that explained before. Figure 8(c) presents an example flow when the MS roams to a new domain, for example, from domain 1 to domain 2 in Figure 2. Similarly, the MS informs the new QGS about its presence. The new QGS then may need to consult with the new AAA server, old AAA server, and old QGS. Once the new QGS updates the QoS profiles in all QLNs, the MS is free to roam in the new domain without any new J.-C. Chen et al Expires January 2001 [Page 20] Internet Draft Wireless Diffserv July 2000 QoS tasks. DHCP AAA MS Server QGS Server QLNi | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | NOTICE | | | |---------------------------->| | | | | AAA REQUEST | | | |------------>| | | | AAA RESPOND | | | |<------------| | | | | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| | ACK | | |<----------------------------| | | | | | | | actual traffic | |<------------------------------------------------------>| | | FIGURE 8(a): Example flow for protocol 3 -- initial set-up DHCP AAA MS Server QGS Server QLNi | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | | | | | | J.-C. Chen et al Expires January 2001 [Page 21] Internet Draft Wireless Diffserv July 2000 | | | actual traffic | |<------------------------------------------------------>| | | | | | | | NEW INFO | | |<-------------------------| | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| FIGURE 8(b): Example flow for protocol 3 -- changing subnet within the same domain New DHCP New New Previous Previous New MS Server QGS AAA QGS AAA QLNi | | | | | | | | DHCP | | | | | | | DISCOVER| | | | | | |-------->| | | | | | | DHCP | | | | | | | OFFER | | | | | | |<--------| | | | | | | DHCP | | | | | | | REQUEST | | | | | | |-------->| | | | | | | DHCP | | | | | | | ACK | | | | | | |<--------| | | | | | | | | | | | | NOTICE | | | | | |------------------>| | | | | | | AAA | | | | | | REQUEST | | | | | |-------->| | | | | | AAA REQUEST | | | | |------------------>| | | | | AAA RESPOND | | | | |<------------------| | | | AAA | | | | | RESPOND | | | | |<--------| | | | | | | | | | SLS REQUEST | | | | |------------------>| | | | | SLS OFFER | | | | |<------------------| | | | | | | | | | | | | UPDATE | | |-------------------------------------->| J.-C. Chen et al Expires January 2001 [Page 22] Internet Draft Wireless Diffserv July 2000 | | ACK | | |<--------------------------------------| | ACK | | |<------------------| | | | | | | | actual traffic | |<--------------------------------------------------------->| | | FIGURE 8(c): Example flow for protocol 3 -- roaming to a new domain 4. How the Model Could Potentially Meet the Requirements 4.1. Mobility support The users in next generation wireless networks are expected to be highly mobile. In addition to support mobility, the proposed model also significantly reduces the QoS signaling messages while the MS is moving. This also potentially reduces the handoff delay. If the amount of QoS signaling messages is not the major consideration and the MS can tolerate small percentage of handoff blocking rate, the model is flexible enough to use provisioning scheme to increase the number of admitted MS. 4.2. Dynamic SLS Since the QGS has global information, dynamic SLS can be achieved easily and efficiently. The MS only needs to negotiate with the QGS once. After that, all QLNs will know the new QoS profile. In the proposed model, the dynamic SLS can be done in any granularity as well. 4.3. Tight end-to-end QoS guarantees By careful reservation, the proposed model can use diffserv to guarantee traffic like Class-A0. For real-time traffic, the model potentially can meet the QoS requirements qualitatively. The tight quantitative end-to-end QoS guarantee requires other mechanisms in the core network. Some study for tight quantitative end-to-end QoS based on diffserv has been reported in the literature. How to adapt them to our model is for future study. 4.4. Support QoS for multiple classes of traffic The proposed model explicitly considers the QoS support for multiple classes of traffic. 4.5. Interoperable and administrable between different service providers and with legacy networks Since the proposed model is based on diffserv, it is interoperable and administrable for all service providers which deploy diffserv. To interoperate with legacy networks, the IP networks usually J.-C. Chen et al Expires January 2001 [Page 23] Internet Draft Wireless Diffserv July 2000 connect with legacy networks by "media gateway" (MG) which is controlled by "media gateway controller" (MGC). The MG is for transport, and the MGC is for control. The proposed model fits this model well. 4.6. Scalability The proposed model is based on diffserv. Therefore the traffic is aggregated in the core network. By separating the control and transport, both QGS and QLN handle only part of the QoS functionality. Although all classes of transport traffic go through QLN, QLN should be able to handle them because each QLN only serves a local domain. The potential traffic going through QGS is the QoS signaling message. This QoS signaling may only need to be done once when the MS first pops up. Other traffic to QGS includes dynamic SLS negotiation and communications between QGS and QLN. If one QGS is not enough, multiple QGS can be deployed. This is similar to the scalability problem in MG and MGC. 4.7. Multicast This is for future study. 4.8. Simple and easy to implement The core network is based on diffserv, so the core network should be simple and easy to implement. The separation of control and transport makes the mobility support easy to deploy and maintain. When new services are needed, only QGS needs to be upgraded. There is no need to upgrade all QLNs in the edge of the network. If something wrong, mostly it is in QGS which resides on central office. QLNs only need to be diagnosed after QGS. 4.9. It should not incur too much overhead. The proposed model can potentially reduce the QoS signaling overhead since the MS mostly only needs one QoS signaling in the same administration domain. The QoS signaling can be further integrated with other signaling/registration protocols to reduce more overhead. 4.10. Interoperate with other IETF protocols The design of the proposed model follows the spirit of other IETF protocols. The integration with other IETF protocols is explicitly considered in the proposed model. 4.11. Support both aggregated and per-flow QoS guarantee This is for future study. 4.12. Support both receiver-initiated and sender-initiated QoS. This is for future study. J.-C. Chen et al Expires January 2001 [Page 24] Internet Draft Wireless Diffserv July 2000 4.13. Interoperate/integrate with link layer. This is for future study. 5. Summary and Concluding Remarks This document presents a QoS architecture and preliminary specifications to support mobility. The QoS requirements for next generation wireless IP networks are identified. Services are classified. QoS architecture and protocols are presented. Some example flows are shown. The design of the proposed architecture and protocols is to provide an efficient and flexible way to support QoS in mobile environment. The architecture separates the control and transport so that the QGS handles the QoS signaling, and the QLN deals with the transporting of actual traffic. The QLN provides the local information to the central QGS, thus the QGS retains the global information of the domain. The merit of the architecture includes flexibility, less QoS signaling message, integration with other protocols, and ease to adjust the reservation bandwidth and provisioning bandwidth and in each local domain. 6. Acknowledgments The authors wish to acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia Technologies (P. Agrawal, S. Das, A. Dutta, D. Famolari, S. Madhani, F. Vakil, H. Sherry and R. Wolff) and Toshiba America Research Incorporated (T. Kodama, T. Maeda, N. Nakajima, S. Shiomotsuji, and Y. Shobatake). (TM): ITSUMO (Internet Technology Supporting Universal Mobile Operation) is a trademark of Telcordia. It is a joint research project of Telcordia Technologies and Toshiba America Research Inc. (TARI). It envisions an end-to-end wireless/wireline IP platform for supporting real-time and non-real-time multimedia services in the future. Its goal is to use IP and third generation wireless technologies to design a wireless platform that allows mobile users to access multimedia services on a next generation Internet. In Japanese, ITSUMO means anytime, always. 7. References [3AREQ00] S. Das, A. McAuley, S. Baba, and Y. Shobatake, "Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP", Internet Draft, , work in progress, March 2000. [DHCP97] R. Droms, "Dynamic Host Configuration Protocol", IETF RFC 2131, Mar 1997. [DIFF98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [DRCP99] A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic Registration and Configuration Protocol for Mobile Hosts", J.-C. Chen et al Expires January 2001 [Page 25] Internet Draft Wireless Diffserv July 2000 Internet Draft, , work in progress, October 1999. [HMMP99] F. Vakil, A. Dutta, J.-C. Chen, S. Baba, and Y. Shobatake, "Host Mobility Management Protocol: Extending SIP to 3G-IP Networks", Internet Draft, , work in progress, October 1999. [IMT97] ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000 (IMT-2000)", 1997. [ITSUMO99] ITSUMO Group, "Evolution of Wireless Telephony Towards Voice over 3G-IP", 3GPP2-P00-19990824-010, August 23, 1999. [ITSUMO00] ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless Architecture", mwif2000.028, January 28, 2000. [REQ97] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997. [SIP99] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", IETF RFC 2543, March 1999. 8. Authors' Addresses Jyh-Cheng Chen Telcordia Technologies 445 South Street, MCC-1G236B Morristown, NJ 07960-6438 Phone: +1 973 829 4067 Email: jcchen@research.telcordia.com Anthony J. McAuley Telcordia Technologies 445 South Street, MCC-1C235B Morristown, NJ 07960-6438 Phone: +1 973 829 4698 Email: mcauley@research.telcordia.com Armando L. Caro Jr. Telcordia Technologies 445 South Street, MCC-1C157B Morristown, NJ 07960-6438 Phone: +1 973 829 4319 Email: acaro@research.telcordia.com Shinichi Baba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 4759 Email: sbaba@tari.toshiba.com Yoshihiro Ohba Toshiba America Research Inc. P.O. Box 136 J.-C. Chen et al Expires January 2001 [Page 26] Internet Draft Wireless Diffserv July 2000 Convent Station, NJ 07961-0136 Phone: +1 973 829 5174 Email: yohba@tari.toshiba.com Parameswaran Ramanathan Dept. of Electrical & Computer Engineering University of Wisconsin, Madison Madison, WI 53706-1691 Phone: +1 608 263 0557 Email: parmesh@ece.wisc.edu J.-C. Chen et al Expires January 2001 [Page 27]