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 
                     <draft-needham-obast-qos-00.txt> 
 
                    
 
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 <youremail>" 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]