IETF Mobile IP Working Group Hemant Chaskar
INTERNET-DRAFT Rajeev Koodli
Expires: September 2001 Nokia Research Center
March 2001
A Framework for QoS Support in Mobile IPv6
draft-chaskar-mobileip-qos-01.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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 made 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.
Copyright Notice
Copyright (c) The Internet Society (2001). All rights reserved.
Abstract
This draft describes a solution to perform QoS signaling along
the new network path, when mobile node using Mobile IPv6
acquires a new care-of address. The solution is based on the
definition of new option called QoS OBJECT OPTION. This option
is included in the hop-by-hop extension header of certain
packets, preferably the ones carrying binding messages,
propagating between mobile node and correspondent node
or between mobile node and regional mobility agent(s). Such an
approach takes advantage of mobility signaling inherent in
Mobile IPv6 to program QoS forwarding treatment as well, along
the new network path. It naturally blends in with micro-mobility
techniques. Further, compared to using RSVP, our solution has
much smaller latency until QoS forwarding treatment is
programmed over the new network path after handover.
Chaskar, Koodli [Page i]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
Contents
Status of This Memo i
Abstract i
1.0 Introduction 1
1.1 Problem statement
1.2 Solution overview
2.0 Terminology and Abbreviations 2
3.0 Composition of QoS OBJECT OPTION 3
4.0 Inclusion of QoS OBJECT OPTION in hop-by-hop extension header 4
4.1 Basic Mobile IPv6
4.2 Micro-mobility scenarios
5.0 Performance Considerations (Comparison with RSVP) 6
6.0 Processing of QoS OBJECT OPTION at Intermediate Networks 7
6.1 IntServ domain
6.2 MPLS domain
6.3 DiffServ domain
7.0 Security considerations (TBD) 9
8.0 Acknowledgment 9
9.0 References 10
10.0 Addresses 11
Chaskar, Koodli [Page ii]
INTERNET-DRAFT QoS Support in Mobile IPv6 March,2001
1.0 Introduction
While Mobile IP [1] ensures correct and efficient routing of
mobile node's (MN) packets as the MN changes its point of
attachment with the Internet, the issue of Quality of Service
(QoS) for MN's packet streams is not addressed yet. This document
describes the problem statement, outlines a solution and provides
comparison with existing (mobility-unaware) approaches such as
RSVP [2] to QoS signaling.
1.1 Problem statement
As an MN moves from one access router (AR) to another, the paths
traversed by MN's packet streams with its correspondent nodes
(CNs), may change. This is always true for the path in the access
network to which MN is attached. In addition, handover between
ARs in different access networks may cause the path traversed by
MN's packet streams in the core network to change as well. If the
MN's packet streams are QoS-sensitive, a mechanism is needed to
signal desired QoS forwarding treatment along the new paths in
the network. It is important to note that while the routing
aspect of mobility has been addressed in Mobile IPv6, the problem
of maintaining desired QoS forwarding treatment in the light of
mobility has not been addressed.
Subsequent to handover, the new end-to-end path between CN(s) and
MN may span a number of networks (access and core) employing a
variety of QoS schemes, notably IntServ [3] in access and
MPLS [4] and DiffServ [5] in core. There may as well be best
effort networks in the end-to-end path. Thus, as a basic
requirement, mobility-aware QoS signaling mechanism must be
capable of providing QoS forwarding information for MN's packet
streams to relevant routers in different networks in the
end-to-end path. The QoS signaling mechanism must have fast
response time so that the latency between the time packets using
the new care-of address (CoA) are released into the network and
the time QoS forwarding information is signaled along the new
path should be minimized. In other words, the mechanism must be
able to make use of intrinsic handover signaling to minimize
"QoS alignment" latency for MN's packet streams. Furthermore,
any mobility-aware QoS signaling mechanism should be able to
exploit micro-mobility [6,7] and fast handover [8] solutions in
order to localize the extent of signaling to affected branches of
the network only. Finally, such a mechanism should impose minimal
requirements on the end terminals with limited processing power,
memory and battery resources.
1.2 Solution overview
Our solution is based on the use of new option called QoS OBJECT
OPTION. It may contain a number of QoS OBJECTs, each of which
corresponds to one unidirectional QoS-sensitive packet stream of
Chaskar, Koodli [Page 1]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
MN. The basic idea is to include QoS OBJECT OPTION in IPv6
hop-by-hop extension header along with packets propagating in
the same direction as the QoS-sensitive packet streams of MN.
Since binding update (BU) is sent as soon as the data
transmission from the new CoA is ready to begin, the QoS
OBJECT OPTION sent along with it in hop-by-hop extension
header, promptly triggers the necessary actions to set up QoS
forwarding treatment along the new path. Same is true regarding
binding acknowledgment (BA) when the packet streams in the
direction from CN(s) to MN are considered. With basic Mobile
IPv6, the binding messages travel end-to-end. Thus, the QoS
object processing also spans end-to-end network path. With
micro-mobility solutions, these messages travel only as far as
the nearest mobility agent that needs to update its route table
entry. Note that the QoS OBJECT OPTION also needs to travel only
as far as the nearest node requiring an update to its route
entry. Thus, by combining the transmission of QoS OBJECT OPTION
with binding messages, a natural optimization is achieved with
micro-mobility solutions. However, note that QoS object option
may be included in hop-by-hop extension header of any other
packet propagating in the same direction as QoS-sensitive packet
stream.
The actions taken by intermediate routers upon examining the QoS
OBJECT OPTION in hop-by-hop extension header depend on
the QoS scheme employed by their network domains. Generally, in
access networks, QoS OBJECTs in QoS OBJECT OPTION will be used by
all routers to program QoS forwarding treatment for MN's packets.
In the core network, typically edge routers process the QoS
OBJECT OPTION, while internal routers ignore it.
Note that our approach does not relay on round-trip signaling
such as PATH/RESV of RSVP, but rather performs programing of QoS
forwarding treatment along the new network path in one pass.
Also, this is done ahead of the time the packets using new CoA
arrive at intermediate routers along the new end-to-end path.
This minimizes the number of packets that would get default
forwarding treatment at intermediate nodes due to lack of
QoS forwarding information in those nodes after handover.
2.0 Terminology and Abbreviations
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.
MN: Mobile node
CN: Correspondent node
QoS: Quality of service
CoA: Care-of-address
HoA: Home address
AR: Access router
Chaskar, Koodli [Page 2]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
BU/BA: Binding update/Binding acknowledgment
ER: Edge router of network domain
IR: Interior router of network domain
MPLS: Multi-protocol label switching
FEC: Forwarding equivalence class
DiffServ: Differentiated services
IntServ: Integrated services
Uplink/Downlink direction: From MN/Towards MN
3.0 Composition of QoS OBJECT OPTION
The QoS signaling solution described here uses a new IPv6
extension header option called QoS OBJECT OPTION. The
composition of QoS OBJECT OPTION is shown in Figure 1. It
contains zero or more QoS OBJECTs in TLV format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |0|0|1| Opt Type| Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Reserved | One or more QoS OBJECTs in TLV format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Composition of QoS OBJECT OPTION
The composition of a QoS OBJECT is shown in Figure 2. A QoS
OBJECT is an extension of RSVP QoS and FILTER_SPEC objects.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Reserved | Object Length |QoS Requirement|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Max Delay (16-bit integer) ms |Delay Jitter (16-bit integer)ms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Average Data Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Peak Data Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Minimum Policed Unit (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Maximum Packet Size (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | |
| |
| Values of Packet Classification Parameters |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Composition of a QoS OBJECT
Chaskar, Koodli [Page 3]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
o QoS Requirement: This field describes the QoS requirement of
the MN's packet stream in terms of traffic class. An example is
the QoS specification in terms of delay sensitivity, such as
interactive-delay sensitive, non-interactive delay sensitive or
delay insensitive, as in UMTS QoS specification [9]. Another
example is specification in terms of DiffServ PHB classes such
as EF or AF. Yet another alternative is QoS specification in
terms of IntServ classes such as guaranteed service or
controlled load service. Some examples are,
00000xxx: DiffServ EF PHB
00001xxx: DiffServ AF PHB
00010xxx: IntServ guaranteed service
00011xxx: IntServ controlled load service
00100xxx: UMTS traffic class
o Delay specification: The fields "Max Delay" and "Delay Jitter"
specify the end-to-end values of respective quantities in
milliseconds that the packet stream can tolerate.
o Traffic Volume: The fields Average Data Rate, Burstiness, Peak
Data Rate, Minimum Policed Unit and Maximum Packet Size
describe the volume and nature of traffic that the
corresponding packet stream is expected to generate.
o Packet Classification Parameters: This field provides values
for parameters in packet headers that can be used for packet
classification. In particular, it specifies a subset of TCP/UDP
port numbers, IPv6 flow label and SPI corresponding to
particular packet stream. Typically, source and destination IP
addresses to be used for packet classification can be inferred
from header of packet carrying QoS OBJECT OPTION.
4.0 Inclusion of QoS OBJECT OPTION in hop-by-hop extension header
The basic idea here is to include QoS OBJECT OPTION containing
QoS OBJECTs corresponding to MN's packet stream(s), in the
hop-by-hop extension header along with the packet that
propagates in the same direction as the corresponding packet
stream(s). QoS OBJECTs in this option can then inform the routers
at the intermediate network domains about the QoS forwarding
requirement of the relevant packet streams. Routers make use of
this information, in a manner that is consistent with the QoS
scheme employed by their network domains (see Section 6), to
immediately program proper QoS forwarding treatment for those
packet stream(s).
Chaskar, Koodli [Page 4]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
4.1 Basic Mobile IPv6
In basic Mobile IPv6, MN sends BU to CN as soon as it is ready to
use new CoA. QoS OBJECT OPTION containing QoS OBJECT(s)
corresponding to uplink packet stream(s) SHOULD be included in
hop-by-hop extension header with this BU. QoS OBJECT OPTION
promptly triggers necessary processing at the intermediate
routers so as to offer proper QoS forwarding treatment to MN's
uplink packet streams along the new end-to-end path.
By the same reasoning, QoS OBJECT OPTION containing QoS OBJECT(s)
corresponding to downlink packet stream(s), SHOULD be included in
hop-by-hop extension header along with BA that is sent
from CN to MN.
Note however that QoS OBJECT OPTION can be included in the
hop-by-hop extension header of any packet that propagates
in the same direction as the corresponding packet stream(s).
4.2 Micro-mobility scenarios
Micro-mobility solutions introduce local mobility agents, such as
a Gateway Mobility Agent (GMA) in Regional Registration or
Mobility Anchor Point (MAP) in Hierarchical Mobile IPv6 approach
for proxying a regional CoA. Regional CoA remains constant while
the MN moves inside the visited domain. This approach alleviates
the need for sending BUs to all the CNs for every handover. This
conserves wireless bandwidth as well as reduces the signaling
load caused by binding messages outside the visited domain. It
decreases the latency associated with binding messages as they
are sent only up to the local mobility agent.
The proposed solution readily makes use of micro-mobility
mechanisms, facilitating QoS modification along only those
segments of end-to-end forwarding path that are affected by the
MNÆs movement. The QoS OBJECT OPTION would be carried in the BU
to the regional mobility agent, and the routers in the path
traversed by BU process this hop-by-hop option, making
modifications to their QoS forwarding engines as necessary.
The BA from the regional mobility agent would trigger similar
adjustments for QoS forwarding treatment for packets destined
to the MN.
We observe some significant performance benefits in combining QoS
signaling with micro-mobility. First, the QoS signal
itself would travel only as far as what is deemed necessary by
the particular micro-mobility mechanism. This reduces the
round-trip signaling latency. Incidentally, we note that with
Regional Registrations for Mobile IPv6, this distance is up to
the cross-over router, where as with HMIPv6, it is the number of
hops up to MAP. Second, QoS object option with micro-mobility
greatly enhances existing state re-usage. That is, the existing
Chaskar, Koodli [Page 5]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
QoS state beyond the GMA or the MAP need not be modified at all
when the mobile nodeÆs movement is limited to the visited domain
(implying that the Regional CoA does not change). Regional
Registrations further extends this state re-use to the nodes
within the visited domain itself. For example, when the mobility
limits route changes to a node below the GMA in hierarchy, such
as a cross-over router, the existing state above the cross-over
state can be re-used, since those nodes do not perceive a change
in the source address in the packets.
5.0 Performance Considerations (Comparison with RSVP)
In this section, we compare the performance of QoS signaling
approach proposed in this document to that of using RSVP for QoS
signaling upon handover. The performance metric used is the
latency between the time nodes (MN or CN) are ready to use new
CoA and the time QoS forwarding requirement is signaled over the
new forwarding path.
We observe that RSVP introduces latency of about one round-trip
time (between the MN and the CN) from the time packets using new
CoA are released into the network until the time QoS forwarding
treatment is programmed over the new path. Note that one
end-to-end round-trip may involve, in the worst case, four
traversals of wireless links. The worst case happens when both MN
and CN are attached via low bandwidth wireless links. In that
case, the packets released into the network during this time
period would get default forwarding treatment at intermediate
network domains. On the contrary, in our approach, programming
of QoS forwarding treatment along the new end-to-end path is
immediate. This is shown by the following illustration.
Suppose MN is currently at CoA1. Consider data traffic from the
CN towards the MN (downlink direction). The following events
occur:
o MN moves to CoA2 and sends BU from CoA2 to CN. BU reaches CN.
CN sends BA to MN at CoA2.
RSVP | HOP-by-HOP QoS OBJECT OPTION
CN initiates RSVP signaling | QoS OBJECT OPTION for downlink
to program QoS forwarding | packet stream(s) is included in
treatment for downlink traffic | HOP-by-HOP OPTIONS EXTENSION
over the new network path. For | HEADER along with the BA.
this, CN sends RSVP PATH to MN |
at CoA2. |
o CN may start sending MN's packets to CoA2. These packets
contain CoA2 as destination address.
Chaskar, Koodli [Page 6]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
RSVP | HOP-by-HOP QoS OBJECT OPTION
Note that QoS forwarding | QoS OBJECT OPTION precedes these
treatment for these packets is | these packets and programs QoS
not yet programmed along the | forwarding treatment along the
new network path. This is | new network path. The processing
certainly true for the segment | time of QoS OBJECT OPTION along
of end-to-end path that was | the new network path would
not present in the old | determine how quickly proper QoS
end-to-end path. Even over |forwarding treatment is offered.
that segment of the end-to-end |In RSVP, this latency is at least
path which remains unchanged |one round-trip time plus the
after handover, these packets |processing time of PATH and RESV
would get default forwarding |messages along the new end-to-end
treatment. This is because, |network path.
RSVP session is primarily |
identified by destination |
address which now has changed |
from CoA1 to CoA2. |
----[One way end-to-end delay ellapses, then]----
o BA reaches MN at CoA2.
RSVP PATH reaches MN at CoA2. |
MN sends RSVP RESV to CN. |
----[One way end-to-end delay ellapses, then]----
RSVP |
o RSVP RESV reaches CN. |
|
It is at this time that the |
proper QoS forwarding |
treatment is programmed at the|
intermediate nodes for packets|
destined to CoA2. |
It is worth noting that the above drawback of RSVP's OPWA (One
Pass with Advertisement) method is also observed in [10].It is
shown in [10] that under certain assumptions, the severity of
this drawback can be reduced. However, validity of those
assumptions is not obvious.
6.0 Processing of QoS OBJECT OPTION at Intermediate Networks
When QoS OBJECT OPTION is included in the HOP-by-HOP OPTIONS
EXTENSION HEADER in IPv6 packet, intermediate routers MUST
examine this option. The purpose of this is to obtain information
about QoS forwarding requirement about MN's packet streams.
Chaskar, Koodli [Page 7]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
Typically, there are multiple and possibly heterogeneous (in
terms of QoS mechanism employed) network domains in the
end-to-end path. Here, a network domain is defined as a
collection of network nodes (routers) that implements a
particular QoS mechanism independently and under the same control
framework. There are edge routers (ER) at the edge of these
domains and internal routers (IR) inside the domains. Each of
these domains may be a best-effort domain or may employ QoS
mechanisms such as MPLS, DiffServ or IntServ. Typically, access
networks would employ flow-based QoS mechanisms such as IntServ,
while core network will use aggregate-based schemes such as MPLS
and DiffServ. Note that QoS OBJECT contains enough information so
that any of these QoS schemes can extract the information
relevant to them from the QoS OBJECT. The actual mapping between
QoS object parameters to the parameters used by different QoS
schemes is implementation specific, and thus beyond the scope
of this document. In the following, we outline the semantics of
processing QoS OBJECT OPTION at ERs and IRs of these network
domains.
6.1 IntServ domain
In IntServ domain, there are two ways to process the QoS OBJECT
OPTION. According to one method which fully complies with One
Pass with Advertisement (OPWA) model of RSVP, ingress ER
examines the QoS OBJECT OPTION in hop-by-hop extension header
to determine QoS forwarding requirement of MN's packet
streams. It also determines the egress ER of that network domain
where MN's packets will be forwarded. Ingress ER sends RSVP PATH
message to egress ER. Ingress ER MAY include (a version of) QoS
OBJECT OPTION in _destination_ extension header of the
packet carrying RSVP PATH message. This will provide egress ER
with the information necessary to determine the actual resources
that are required to be reserved. Egress ER sends RSVP RESV to
ingress ER. Once ingress ER receives RESV from egress ER, it
forwards the packet containing QoS OBJECT OPTION through the
network domain. IRs in the network domain simply ignore the QoS
OBJECT OPTION.
The above method has the following drawback that is intrinsic to
OPWA model of resource reservation of RSVP, when it is used in
mobile environment. It takes one round trip time in the network
domain before QoS forwarding treatment is programmed at the
routers in the network domain. In other words, MN's packets that
arrive at the ingress ER get default forwarding treatment until
the time RESV reaches ingress ER. This drawback is eliminated if
the following method of resource reservation is used instead.
Ingress ER of IntServ network domain examines the QoS OBJECT
OPTION and immediately performs reservation of resources such as
buffer, bandwidth, priority etc. at that router. Ingress ER then
Chaskar, Koodli [Page 8]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
forwards the packet containing QoS OBJECT OPTION to next IR in
the network domain. IR examines the QoS OBJECT OPTION and
immediately performs resource reservation at that router. IR then
forwards the packet to next IR in the network domain. This
continues until the packet reaches egress ER which performs
resource reservation at that router, and forwards the packet to
next network domain.
6.2 MPLS domain
Ingress ER at MPLS domain (often called edge label switching
router (edge LSR)) determines the forwarding equivalence class
(FEC) to which the packets of MN's packet stream(s) should belong
to in that domain. This decision is based on the destination IP
address of the packet and QoS forwarding requirement of packet
stream(s). FEC translates to label switching path (LSP) over
which the packets should be forwarded through that domain.
Ingress ER may also use traffic volume parameters in QoS
OBJECT(s) to perform admission control over those LSPs. Ingress
ER creates FEC mapping context that would map subsequent packets
of MN's packet stream(s) onto appropriate LSPs. Packet
classification parameters in the QoS OBJECT(s) are used to set up
FEC mapping context.
Ingress ER then forwards the packet containing QoS OBJECT OPTION
through the network domain using label based forwarding paradigm.
As a result of this, IRs do not even see the IP header, and
hence, do not process any hop-by-hop options.
6.3 DiffServ domain
Ingress ER at DiffServ domain uses QoS OBJECT(s) in QoS OBJECT
OPTION to program packet classification context for the packets
of MN's packet stream(s). This context would assign appropriate
differentiated services code point (DSCP) to subsequent packets
of these packet stream(s). ER may also perform admission control
to ensure that service level agreement (SLA) is not violated by
the volume of traffic generated by these packet stream(s).
IRs in DiffServ domain simply ignore the QoS OBJECT OPTION.
7.0 Security considerations
To be discussed.
8.0 Acknowledgment
Thanks are due to Charlie Perkins (Nokia) for his useful
comments during the revision of this document.
Chaskar, Koodli [Page 9]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
9.0. References
[1] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet
Draft, Internet Engineering Task Force.
draft-ietf-mobileip-ipv6-12.txt. April 2000.
[2] R. Braden and L. Zhang. Resource ReSerVation Protocol (RSVP):
Version 1 Functional Specification. Request for Comments
(Standards track) 2205. September 1997.
[3] R. Braden, D. Clark, and S. Shenker. Integrated Services
in the Internet Architecture: An Overview. Request for
Comments (Informational) 1633. June 1994.
[4] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label
Switching Architecture. Internet Draft, Internet Engineering
Task Force. draft-ietf-mpls-arch-06.txt. July 2000.
[5] S. Blake et. al. An Architecture for Differentiated Services.
Request for Comments (Informational) 2475. December 1998.
[6] J. Malinen and C. Perkins. Mobile IPv6 Regional
Registrations. Internet Draft, Internet Engineering Task
Force. draft-malinen-mobileip-regreg6-00.txt. July 2000.
[7] H. Soliman et. al. Hierarchical MIPv6 mobility management.
Internet Draft, Internet Engineering Task Force.
draft-soliman-mobileip-hmipv6-01.txt. September 2000.
[8] C. Perkins et. al. Fast Handovers for Mobile IPv6. Internet
Draft, Internet Engineering Task Force.
draft-perkins-mobileip-handover-00.txt. November 2000.
[9] 3GPP Technical Specification 23.107, Version 3.2.0: QoS
Concept and Architecture, March 2000.
[10] Michael Thomas. Analysis of Mobile IP and RSVP Interactions.
Internet Draft, Internet Engineering Task Force.
draft-thomas-seamoby-rsvp-analysis-00.txt. February 2001.
Chaskar, Koodli [Page 10]
INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001
10.0 Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
Questions about this memo can be directed to the authors:
Hemant Chaskar
Communication Systems Laboratory
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA
Phone: +1 781-993-3785
EMail: hemant.chaskar@nokia.com
Rajeev Koodli
Communication Systems Laboratory
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043, USA
Phone: +1 650-625-2359
EMail: rajeev.koodli@nokia.com
Chaskar, Koodli [Page 11]