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

Versions: 00 01 02 03                                                   
IETF Mobile IP Working Group                          Hemant Chaskar
INTERNET-DRAFT                                                Editor
                                               Nokia Research Center
                                                    10 February 2002


               Requirements of a QoS Solution for Mobile IP

                draft-ietf-mobileip-qos-requirements-02.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

   Mobile IP ensures correct routing of packets to mobile node as the
   mobile node changes its point of attachment to the Internet.
   However, it is also required to provide proper QoS forwarding
   treatment to mobile node's packet stream at the intermediate nodes
   in the network, so that QoS-sensitive IP services can be supported
   over Mobile IP. This document describes requirements for an IP QoS
   mechanism for its satisfactory operation with Mobile IP.









Hemant Chaskar                                               [Page i]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


1  Introduction

   Mobile IP is a technology that allows a "mobile node" (MN) to
   change its point of attachment to the Internet while
   communicating with the "correspondent node" (CN) using IP. The
   formal description of Mobile IP can be found in [1, 2]. Mobile IP
   primarily addresses the correct routing of packets to MN's current
   point of attachment with the Internet.

   It is also essential to provide proper Quality of Service (QoS)
   forwarding treatment to the packets sent by or destined to MN as
   they propagate along different routes in the network due to node
   mobility. This document will identify the requirements that Mobile
   IP places on an IP QoS mechanism.

1.1 Problem statement

   When an MN using Mobile IP undergoes handover from one access
   router to another, the path traversed by MN's packet stream in the
   network may change. Such a change may be limited to a small
   segment of the end-to-end path near the extremity, or it could
   also have an end-to-end impact. Further, the packets belonging to
   MN's ongoing session may start using a new care-of address after
   handover. Hence, they may not be recognized by some forwarding
   functions in the nodes even along that segment of the end-to-end
   path that remains unaltered after handover. Finally, handover may
   occur between the subnets that are under different
   administrative control.

   In the light of this scenario, it is essential to establish proper
   QoS support for the MN's packet stream along the new packet path.

1.2 An approach for solving QoS problem in Mobile IP

   There are four important steps involved in solving the QoS problem
   for Mobile IP. They are as follows: (1) List the requirements that
   Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS
   solutions against these requirements, (3) Decide if current
   solutions need to be extended, or if new ones need to be defined,
   and (4) Depending on the result of step 3, define new solutions or
   fix the old ones.

   Of these, the first step, i.e. the requirements step, is addressed
   in this draft. The last three steps are not dealt with here in
   detail. However, so as to create useful insight into the Mobile IP
   QoS problem, at times this document highlights the shortcomings of
   some well known current proposals for establishing QoS support for
   the packet stream in the network, when directly used with
   Mobile IP.



Hemant Chaskar                                               [Page 1]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


2  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.


3  Requirements of a QoS solution for Mobile IP

   This section describes the requirements for a QoS solution for its
   satisfactory operation with Mobile IP. Conversely, note that only
   Mobile IP-specific requirements are described here. We do not
   assume any particular version (4 or 6) of IP while describing the
   requirements. Solutions can be designed for IPv4 and IPv6
   independently, or a single solution can be designed to work with
   both versions.

   In this document, we assume that the target access router for
   MN's handover is already pinned down by other protocols. For
   example, Seamoby working group has started work on the candidate
   access router discovery protocols [3]. Thus, any QoS-capability
   specific negotiations that may affect the handover decision are
   outside the scope of QoS solution as such, rather need to be
   performed by candidate and target access router selection
   protocols.

3.1 Performance requirements

   1. Minimize the interruption in QoS at the time of handover:

   At the time of handover, interruption in QoS would occur if the
   packets sent by or destined to the MN arrive at the intermediate
   node in the new packet path without that node having information
   about their QoS forwarding requirement. Then, those packets will
   receive default forwarding treatment. Such QoS interruption MUST
   be minimized. A good metric for this performance is the number of
   packets that may potentially get served with the "default" QoS at
  the time of handover. The number of such packets MUST be minimized.

   As an example, this performance metric is computed in [4] for the
   case of end-to-end RSVP signaling [5] with Mobile IPv6. It is
   shown there that when the end-to-end path of packets changes at
   large after handover or when the care-of address changes after
   handover, OPWA (One Pass With Advertisement) model of reservation
   used by RSVP causes the latency of about one round-trip time
   between the MN and the CN before QoS can be established along the
   new packet path. In other words, the packets using the new care-of
   address that would be released by the MN or the CN during one
   round-trip time, after these nodes are ready to use the new
   care-of address, may get default forwarding treatment at the


Hemant Chaskar                                               [Page 2]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


   intermediate nodes. Such a latency in QoS programming may be
   acceptable at the time of session initiation, but it is not
   acceptable in the middle of an active session as would be the case
   with handover.

   2. Localize the QoS (re)establishment to the affected parts of the
   packet path in the network:

   In many cases, handover changes only a small segment of the
   end-to-end path of MN's packet stream near the extremity. Then,
   the QoS mechanism MUST limit the extent of QoS (re)establishment
   to the affected segment of the end-to-end path only.

   However, note that handover may sometimes cause the end-to-end
   path of MN's packet stream in the network to change at large. This
   may happen, for example, in the case of handover between different
   administrative domains. If the QoS mechanism used to establish QoS
   support for the MN's packet stream along the new packet path in
   the network is based on the explicit end-to-end provisioning as
   such, it MUST perform so at the time of such handover.

   When the care-of address changes upon handover, it may be required
   to perform some signaling even over the unchanged part of the
   end-to-end path if the path contains any QoS mechanisms that use
   IP address as a key to forwarding functions. Examples are
   FILTER SPECs in the IntServ nodes or packet classifiers at the
   edges of DiffServ networks. However, double provisioning of
   resources over the unchanged part of the packet path
   MUST be avoided.

   Note that the QoS signaling protocol such as RSVP [6] can localize
   the QoS signaling to the affected parts of the end-to-end path if
   the care-of address does not change upon handover. However, if the
   care-of address changes upon handover, RSVP as currently defined
   [7] fails to localize the QoS signaling. In addition, it will
   cause double reservations on the part of end-to-end path that
   remains unchanged after handover.

   3. Releasing after handover the QoS state (if any) along the old
   packet path:

   The QoS mechanism MUST provide some means (explicit or
   timer-based) to release any QoS state along the old packet path
   that is not required after handover. It is desirable that the
   unwarranted QoS states, if any, along the old path are released as
   quickly as possible at the time of handover. Note that, during
   handover, the MN may not always get a chance to send explicit tear
   down message along the old path because of the loss of link layer
   connectivity with the old access router.



Hemant Chaskar                                               [Page 3]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


3.2 Interoperability requirements

   1. Interoperability with mobility protocols:

   A number of mobility protocols that are complementary to Mobile IP
   are already defined or may be defined in future in IETF,
   particularly in Mobile IP and Seamoby working groups.
   Examples are Fast Handover [8, 9], Regional Registrations [10],
   Hierarchical MIPv6 [11], Context Transfer [12] etc. The QoS
   mechanism for Mobile IP SHOULD take advantage of these mobility
   protocols for the optimized operation. However, the QoS scheme
   MUST have provisions to accomplish its tasks even if one or more
   of these mobility protocols are not used.

   2. Interoperability with heterogeneous packet paths as
   regards QoS paradigms:

   The new path after handover, of the MN's packet stream, may
   traverse network domains employing different QoS paradigms
   compared to those along the old path. The QoS mechanism for Mobile
   IP SHOULD be able to establish proper QoS forwarding treatment for
   the MN's packet stream along the packet paths deploying different
   QoS paradigms (best current practices), in a manner consistent
   with the QoS mechanism deployed along those paths.

   As an illustration, suppose that the MN is currently attached to
   an access router which is the edge router of a DiffServ network,
   and that the packet classifier and traffic policer for the MN's
   flows are presently programmed in this access router. Now, suppose
   that the MN needs to be handed over to the access router which is
   at the edge of an IntServ network. The new access network would
   expect the exchange of RSVP messages so that proper QoS
   forwarding treatment can be established for the MN's packet stream
   in that access network. QoS mechanism for Mobile IP SHOULD have
   provisions to handle such heterogeneity as regards the QoS
   mechanisms deployed along different packet paths.

3.3 Miscellaneous requirements

   1. QoS support along multiple packet paths:

   After MN undergoes handover from one access router to another,
   potentially, there could be multiple paths over which MN's packet
   may propagate. Examples of these path are: route-optimized path
   between the MN and its CN, triangle route via Home Agent (HA),
   temporary tunnel between old and new access routers, reverse
   tunnel from the new access router (Foreign Agent) to HA etc. A QoS
   mechanism SHOULD be able to support QoS along the different
   potential packet paths. However, whether all paths are supported
   or only a subset of them is supported will be determined by


Hemant Chaskar                                               [Page 4]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


   external mechanisms such as mobility management, policy, location
   privacy requirement and so on. Further, the same QoS mechanism
   may not be able to support all these paths.

2. Interactions with link-layer support for QoS:

   The QoS mechanism MAY provide some information to the link
   layers for them to support the required QoS. Since a vast number
   of devices using Mobile IP will be connected to the Internet via
   wireless links, QoS parameters relevant for wireless links, such
   as error rate, MAY have to be included in the set of IP-level QoS
   parameters to be possibly considered by the underlying link layer.

   An example scenario will be two UDP streams requiring different
   levels of error protection at the link layer. For such cases, an
   IP-layer QoS mechanism may indicate some generic parameters such
   as acceptable IP packet loss rate to link layers.

3.4. Standard requirements

   The QoS solution for Mobile IP SHOULD satisfy standard
   requirements such as scalability, security, conservation of
   wireless bandwidth, low processing overhead on mobile terminals,
   providing hooks for authorization and accounting, and robustness
   against failures of any Mobile IP-specific QoS components in the
   network. While it is not possible to set quantitative targets for
   these desirable properties, the QoS solution MUST be evaluated
   against these criteria.


4  Recommendation

   In this document, we described the requirements for a QoS solution
   for its satisfactory operation with Mobile IP. The expectation is
   that the appropriate working group will use this requirements
   document to provide a QoS solution for Mobile IP.


5  Acknowledgment

   I would like to acknowledge the participants of the mailing list
   that was set up to discuss the above requirements. Their
   contributions and active participation in the discussion on the
   mailing list were very useful in the preparation of this document.
   Special thanks are due to, in alphabetical order, Marc Greis
   (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael
   Thomas (Cisco) for their input during the preparation of
   this document.




Hemant Chaskar                                               [Page 5]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002



6  References

[1] IP mobility support, C. Perkins (Editor), RFC 2002, October 1996.

[2] Mobility support in IPv6, D. Johnson and C. Perkins,
    draft-ietf-mobileip-ipv6-13.txt,
    work in progress, November 2000.

[3] Issues in Candidate Access Router discovery for seamless IP
    handoffs, D. Trossen et. al.,
    draft-ietf-seamoby-cardiscovery-issues-00.txt,
    work in progress, July 2001.

[4] QoS support in Mobile IP version 6, H. Chaskar and R. Koodli,
    IEEE Broadband Wireless Summit (Networld+Interop), May 2001.

[5] A Framework for Integrated Services operation over Diffserv
    networks, Y. Bernet et. al., RFC 2998, November 2000.

[6] Analysis of Mobile IP and RSVP interactions, M. Thomas,
    draft-thomas-seamoby-rsvp-analysis-00.txt,
    work in progress, February 2001.

[7] Resource ReSerVation Protocol -- Version 1 Functional
    Specification, R. Braden et. al., RFC 2750, September 1997.

[8] Low latency handoffs in Mobile IPv4, MIPv4 Handoffs Design Team,
    draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
    work in progress, February 2001.

[9] Fast handovers for Mobile IPv6, MIPv6 Handover Design Team,
    draft-ietf-mobileip-fast-mipv6-01.txt,
    work in progress, April 2001.

[10] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le, and
    C. Perkins, draft-malinen-mobileip-regreg6-01.txt,
    work in progress, March 2001.

[11] Hierarchical MIPv6 mobility management, H. Soliman,
    C. Castelluccia, K. El-Malki, and L. Bellier,
    draft-ietf-mobileip-hmipv6-02.txt,
    work in progress, February 2001.

[12] Problem description: Reasons for performing context transfers
     between nodes in an IP Access Network, edited by J. Kempf,
     draft-ietf-seamoby-context-transfer-problem-stat-04.txt,
     work in progress, May 2002.




Hemant Chaskar                                               [Page 6]


INTERNET-DRAFT         Mobile IP QoS Requirements        10 Feb, 2002


7  Addresses

   The working group can be contacted via the current chairs:

    Basavaraj Patil                     Phil Roberts
    Nokia Corporation                   Megisto
    6000 Connection Drive               20251 Century Blvd, Suite 120
    Irving, Texas 75039, USA            Germantown, MD 20874
    Phone:  +1 972-894-6709             Phone:  +1 847-202-9314
    EMail:  Basavaraj.Patil@nokia.com   EMail:  proberts@MEGISTO.com

  Questions about this memo can be directed to the editor:

   Hemant Chaskar
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone: +1 781-993-3785
   EMail: hemant.chaskar@nokia.com


Appendix: Changes Made from 00 Version

   Few editorial changes were made from 00 version based on the
   working group feedback received on the Mobile IP mailing list.

   1. A clarification is added at the beginning of Section 3, which
      states that QoS-capability negotiations that may affect
      handover decision are outside the scope of this document.
   2. Section 3.1.2 was reworded for better clarity.
   3. Section 3.2.2 was reworded for better clarity.
   4. Section 3.4 is now called "Standard Requirements" rather than
      "Obvious Requirements".
   5. Section 4 is now called "Recommendation" rather than
      "Concluding Remarks".

          Changes Made from 01 Version

   The following changes were made from 01 version in response to
   IESG comments.

   1. Requirement 3.2(2) is changed from MUST to SHOULD.
   2. IESG was concerned about the references to too many individual
      submissions in the 01 version. Now, individual submission
      references 4 and 12 in 01 version are replaced by a reference
      to IEEE conference paper and Seamoby WG document, respectively.
      However, no alternatives could be found for 6, 10 and 11.
      Nevertheless the content in these individual submissions is
      important to understand certain requirements. Hence, these
      references are not removed.


Hemant Chaskar                                               [Page 7]