INTERNET DRAFT Expires January 2001 Michael L. Needham Steve Gilbert Phillip D. Neumiller Motorola, Inc. July, 2000 Quality of Service Support in an OBAST Architecture Status of This Memo ------------------- This document is an Internet-Draft and is in full conformance with all provisions of Section 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 obsoleted 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 outlines some of the fundamental requirements and issues related to the control and maintenance of quality of service (QoS) in an Open Base Station Transport (OBAST) architecture. It begins with a review of a baseline OBAST architecture, highlighting those elements that are particularly relevant to QoS provisioning, then discusses the requirements for QoS within this framework. In particular, the requirements for control and maintenance of QoS during mobility handoffs, and for support of adaptive applications, is addressed. 1. Introduction ====================== This document addresses some of the requirements and issues for the control and maintenance of quality of service (QoS) in an Open Base Station Transport (OBAST) architecture. OBAST refers to a protocol set Needham et al. Expires January 2001 [Page 1] INTERNET DRAFT QoS Support in an OBAST Architecture July 2000 designed to enable access points and/or base stations, of different radio access network types, to communicate with each such that seamless handovers may occur between these radio nodes. A mailing list has been set up for OBAST at majordomo@cig.mot.com; simply put "subscribe obast-list " in the body of a message sent to this address. 1.1 Terminology --------------------- AAA = authentication, authorization and accounting AD = administrative domain AP = access point BTS = base transceiver station OBAST = Open Base Station Transport Macro-mobility = inter-IP domain mobility MH = Mobile Host Micro-mobility = intra-IP domain mobility MNAC = Mobile Network Access Clients MNAS = Mobile Network Access Servers QoS = quality of service 2. Baseline OBAST Implied Architecture --------------------------------------------- The OBAST approach attempts to promote a simplifying architecture for the provisioning of wireless Internet services with seamless mobility across heterogeneous access networks. This architecture has three component types: routers that make up the global Internet and local administrative domain (AD) networks, "Mobile Network Access Servers" (MNASs), and "Mobile Network Access Clients" (MNACs). MNASs correspond to edge router devices that are OBAST compliant, and, in a wireless network, are either directly attached to, or are themselves, radio access nodes in the network (for example, BTSs in a cellular network, or APs in a W-LAN). The MNASs communicate with MNACs that are also OBAST compliant, and which reside in the Mobile Hosts (MHs). The figure below shows the relationship between these components. (Global Internet) | | | | | | | .______________________________________. | | ._______________________________. | | .______. | | | | | | Administrative Domain 1 .... Administrative Domain (n) | | | | | | | | MNAS (1) ... MNAS (j) MNAS(1) ... MNAS(k) / \ MNACs = Mobile Network Access Clients We note that the radio coverage of an OBAST network BTS may engulf that of an AP, implying a vertical handover being required in this scenario. Needham et al. Expires January 2001 [Page 2] INTERNET DRAFT QoS Support in an OBAST Architecture July 2000 OBAST must facilitate vertical, horizontal, soft and hard handovers at the radio and at the servicing network layer when required or optimal. We also consider the possibility that MNASs may serve as proxies to wireless hosts, and as such, may serve as termination points for IP connections. 3. QoS Control and Maintenance in an OBAST Architecture -------------------------------------------------------------- Below we outline various functionalities that need to be supported for the control and maintenance of QoS in an OBAST architecture. QoS quantities that the network may guarantee include packet throughput, delay, delay jitter, and loss. Guarantees may be "hard" (i.e., absolute, or within specified bounds) or "soft" (i.e., statistical, or for limited time periods). The latter apply especially to wireless networks. Mechanisms in the network that may be used to control or manage QoS include admission control, resource allocation, congestion control, packet prioritization, and packet dropping. 3.1 Support for End-to-end QoS mechanisms ----------------------------------------------- Existing and future end-to-end QoS control mechanisms and signaling that are employed in the wired Internet should be supported in OBAST architectures without substantial modification. This would include, for example, end-to-end RSVP signaling that would take place between a MH and a remote host, or SIP signaling between hosts and proxies. For the case in which the MNAS acts as a proxy to wireless hosts (i.e., terminating IP connections), end-to-end mechanisms may exist between MNASs and other edge devices. 3.2 Support for MNAC-to-MNAS QoS mechanisms ------------------------------------------------- Protocols and procedures for QoS control on the radio access side of the OBAST architecture, between the MNAC and its associated MNAS, need to be supported. These QoS controls would be done in coordination with whatever end-to-end mechanisms are used. QoS control mechanisms here would include the processing of resource requests and the allocation of wireless link resources to accommodate various levels of QoS guarantees. The MNAS would act as the resource manager to perform the allocation function. Because of the differences between various link types and the need for high efficiency in link resource utilization, the protocols and procedures used at the wireless resource level would in general be specific and perhaps proprietary to the wireless access network. However, at a higher level, some commonality of procedure would be needed in order allow the negotiation and coordination of QoS guarantees with other entities in the OBAST architecture, for instance, to allow QoS negotiated vertical handoffs between different access networks. Communication with a QoS policy or authentication server in the network may also be part of these procedures. In particular, common means of specifying and communicating the capabilities of the end user application and of the access network would be needed. The QoS Needham et al. Expires January 2001 [Page 3] INTERNET DRAFT QoS Support in an OBAST Architecture July 2000 procedures at this level would work in conjunction with other protocols and procedures supported by OBAST, including micro-mobility procedures for handoff, AAA procedures for registration, and others. 3.3 Support for MNAS-to-MNAS QoS mechanisms ------------------------------------------------- Protocols and procedures for QoS control between MNAS elements in the same AD (for intra-domain resource coordination) and different ADs (for inter-domain resource coordination) need to be supported. The OBAST protocol set would be the means for this control signaling (although proprietary signaling between MNASs would also be possible, if supported by IP). These control mechanisms would be needed for handoff between wireless APs (soft, hard, or seamless), as well as coordination of resources between MNASs to allow, for instance, advance resource reservation in anticipation of handoff, resource coordination (e.g., load balancing) across the wireless system, or the establishment of data paths between MNASs to support seamless micro-mobility. Such coordination between MNASs may require the designation of one MNAS as the coordination point or anchor. As discussed in the previous section, common procedures for negotiation and coordination of QoS, and common means for specifying and communicating QoS capabilities, would be needed. Accounting information that may be needed for QoS provisioning across administrative domains may also be required in the inter-MNAS signaling. 3.4 Support for Edge-to-Core QoS mechanisms ------------------------------------------------- The OBAST architecture is consistent with an Edge-Core QoS architectural approach, in which relatively stateful QoS mechanisms (e.g., per-flow QoS guarantees) may be supported at the edge of a network domain, while relatively stateless QoS mechanisms (e.g., diffserv, or other proposed core-stateless mechanisms [1], [2]) exist in the core of the network. In this model, the MNAS acts as an edge device, and would provide support for such edge-core functionality as packet marking (e.g., DSCP marking in diffserv, or other marking as specified in core-stateless proposals), as well as the coordination of edge and core QoS mechanisms (e.g., the mapping of per-flow QoS guarantees at the edge to packet markings in the core). 3.5 Support for adaptive QoS mechanisms --------------------------------------------- IP-based packet networks that provide integrated communication services (i.e., multiple services over shared packet links) must be able to accommodate a wide variety of applications and users with widely varying QoS requirements and expectations (including varying expectations on the predictability of network service availability, QoS, or pricing). In addition, wireless access networks are often subject to high levels of variability in available resources, due to handoffs in and out of wireless cells, wide variances in channel bandwidth between different cells, and wide variations in wireless channel quality. As such, support for adaptation by applications, including mechanisms in the Needham et al. Expires January 2001 [Page 4] INTERNET DRAFT QoS Support in an OBAST Architecture July 2000 network to perform reallocation of resources, is highly desirable. Such support would include the determination of adaptation preferences corresponding to an application flow (e.g., the range over which it may adapt, the value it may attach to different quantities of allocated resource, tolerance to re-allocations during a call or session, cost objectives, or the priority of the flow or portions of the flow). Such information may be provided by the application itself, or may come from some other entity in the network that can specify the QoS policies and preferences for a specific user or application type. In either case, common means for specifying this information, and protocols and procedures for conveying this information to the MNAS (which is responsible for QoS control and resource allocation on the wireless side of the architecture), would be needed. The specification of network capabilities and policies with respect to resource sharing (e.g., fair sharing, weighted fair sharing, classes of service, or per-flow resource allocation) would also be needed to allow the MNASs to coordinate the adaptation. Mechanisms which support pricing policies used by the network for different levels of QoS would be included as well. Finally, mechanisms by which the MNAS does QoS coordination with other MNASs, based on the adaptation policy, would be needed in the OBAST protocol set (again, this does not exclude additional proprietary signaling supported by IP). End-to-end and edge-to-core mechanisms that support adaptive QoS, while not necessarily part of OBAST itself, would also need to be accommodated. 4. References -------------------- 1. I. Stoika and H. Zhang, "Providing Guaranteed Services Without Per- Flow Management," Proc. Of SIGCOMM '99, Sept. 1999. 2. S. Raghupathy, T. Kim, N. Venkitaraman, and V. Bharghavan, "Achieving Per-flow Weighted Rate Fairness in a Core-Stateless Network," Proc. Of ICDCS '00, April 2000. 4. Authors' Addresses ---------------------------- Michael L. Needham Motorola, Inc. 1301 E. Algonquin Rd. Schaumburg, IL 60196 Phone: (847) 576-3803 Email: needham@rsch.comm.mot.com Steve Gilbert Motorola, Inc. 1301 E. Algonquin Rd. Schaumburg, IL 60196 Phone: (847) 576-2313 Email: gilbert@rsch.comm.mot.com Needham et al. Expires January 2001 [Page 5] INTERNET DRAFT QoS Support in an OBAST Architecture July 2000 Phillip D. Neumiller 50 E. Commerce Dr. Schaumburg, IL 60173 Phone: (847) 576-9624 Email: Phillip.Neumiller@motorola.com Needham et al. Expires January 2001 [Page 6]