draft-ietf-mobileip-qos-requirements-03.txt   draft-ietf-mobileip-qos-requirements-04.txt 
IETF Mobile IP Working Group Hemant Chaskar This draft has been replaced by draft-ietf-nsis-qos-requirements-00.txt.
INTERNET-DRAFT Editor For more information or a copy of the document, contact the author directly.
Nokia Research Center
30 July 2002
Requirements of a QoS Solution for Mobile IP
draft-ietf-mobileip-qos-requirements-03.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.
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.
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
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.
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], localized mobility management
[10, 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
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 wireless link-layer support for QoS:
Since a vast number of devices using Mobile IP will be connected to
the Internet via wireless links, the QoS mechanism for Mobile IP
MAY provide some information to the wireless link layers for them
to support the required QoS.
An example scenario that may benefit from such information
is that of the two UDP streams associated with the same media, but
requiring different levels of error protection at the wireless link
layer due to certain characteristics of their respective encoding
schemes. The packets of these two streams are equally delay
sensitive (so as to maintain playout synchronization at the
receiver), and hence, may be treated equally (as regards queuing)
by IP layer. But they may need to be transmitted on wireless
channels of different error characteristics (say different FEC
coding or power levels).
The QoS information included for the benefit of wireless link
layers SHOULD be such that it is meaningful both ways: to
applications that reside over IP so that they can choose the IP
service of certain QoS characteristics and to wireless link QoS
managers so that they can then map this information to the details
of lower layer mechanisms and their parameters.
In the example scenario described above, such a QoS information
could be expressed as the acceptable loss rate of IP packets in the
UDP stream. This parameter enables the UDP application to choose
the IP service having QoS that matches its requirements, and it
also enables the wireless link QoS managers to choose the right
wireless channel to transmit the packets of this UDP stream.
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.
6 References
[1] ``IP mobility support for IPv4", C. Perkins (Editor), RFC 3220,
January 2002.
[2] ``Mobility support in IPv6", D. Johnson, C. Perkins, and J. Arkko,
draft-ietf-mobileip-ipv6-18.txt,
work in progress, July 2002.
[3] ``Issues in Candidate Access Router discovery for seamless IP
handoffs", D. Trossen et. al.,
draft-ietf-seamoby-cardiscovery-issues-03.txt,
work in progress, June 2002.
[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-04.txt,
work in progress, June 2002.
[9] ``Fast handovers for Mobile IPv6", G. Dommety (Editor),
draft-ietf-mobileip-fast-mipv6-04.txt,
work in progress, March 2002.
[10] ``Localized mobility management requirements, C. Williams
(Editor), draft-ietf-mobileip-lmm-requirements-02.txt,
work in progress, June 2002.
[11] ``Hierarchical MIPv6 mobility management (HMIPv6)", H. Soliman
et. al., draft-ietf-mobileip-hmipv6-06.txt,
work in progress, July 2002.
[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.
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.
Changes was made from 02 version Draft Author(s):
1. Section 3.3.2 is revised for better clarity. H. Chaskar: hemant.chaskar@nolia.com
2. References updated.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/