Internet DRAFT - draft-itsumo-wireless-diffserv
draft-itsumo-wireless-diffserv
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,
<draft-ietf-dhc-aaa-requirements-00.txt>, 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, <draft-itsumo-drcp-00.txt>, 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, <draft-itsumo-hmmp-00.txt>, 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]
