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]