[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]