[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MIP-QOS] Draft version of MIP QoS Requirements Draft
Hello everybody:
Here is the draft version of the MIP QoS Requirements Draft based on the
discussion we had on this mailing list. Please provide your comments on it.
The intent is to have this draft approved by the QoS mailing list
participants and then to post it on the general MIP mailing list, say,
before the end of next week. Thanks.
Hemant
<<draft-chaskar-mobileip-qos-requirements-00.txt>>
IETF Mobile IP Working Group Hemant Chaskar
INTERNET-DRAFT Editor
Expires: November 2001 Nokia Research Center
May 2001
Requirements of a QoS Solution for Mobile IP
draft-chaskar-mobileip-qos-requirements-00.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 protocol ensures correct routing of mobile node's
packets as the mobile node changes its point of attachment with
the Internet. However, it is also required to provide proper QoS
forwarding treatment to mobile node's packets at the intermediate
nodes in the network, so that QoS-sensitive IP services can be
supported over Mobile IP. This document describes requirements of
a QoS mechanism for its satisfactory operation with Mobile IP.
Hemant Chaskar [Page i]
INTERNET-DRAFT Mobile IP QoS Requirements May, 2001
1.0 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 mobile node's packets
to its current point of attachment with the Internet.
It is also essential to provide proper Quality of Service (QoS)
forwarding treatment to MN's packets as they propagate along
different routes in the network due to node mobility. This
document will identify, describe, and discuss the functional and
performance requirements that Mobile IP places on QoS mechanisms.
1.1 Problem Statement
When a 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 end, or it could also have
an end-to-end impact. Further, the packets belonging to MN's
ongoing session may start using the new care-of address after
handover, and hence, may not be recognized by some forwarding
functions along the old path that use IP address as a key.
In the light of this scenario, it is essential to design a
mechanism that can establish proper QoS support at the
intermediate nodes in the new end-to-end path of the MN's packet
stream.
2.0 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.0 Requirements of a QoS solution for Mobile IP
This section describes the requirements of a QoS solution for
Mobile IP. Conversely, note that only Mobile IP-specific
requirements are described here. The requirements have been
classified into five categories, namely performance,
interoperability, exception conditions, miscellaneous requirements
and obvious requirements. Further, 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.
Hemant Chaskar [Page 1]
INTERNET-DRAFT Mobile IP QoS Requirements May, 2001
3.1 Performance requirements
1. Minimize the interruption in QoS at the time of handover:
Interruption in QoS would occur if the MN's packets arrive at the
intermediate node in the new end-to-end path without that node
having information about their QoS forwarding requirement. Such
QoS interruption MUST be minimized. A good metric for this
performance is the number of packets that get served with
"default" QoS at the time of handover. The number of such packets
should be minimized. As an example, this performance metric is
computed for RSVP in [3].
2. Localize the QoS (re)programming to the affected parts of the
packet path in the network:
In many cases, handover affects only a small segment of the
end-to-end path of MN's packet stream. Then, the QoS mechanism
MUST limit the extent of QoS (re)programming to the affected
segment of the end-to-end path only. This will reduce the volume
of QoS signaling traffic (if any) as well as decrease the QoS
interruption. Of course, if the end-to-end path changes at large
after handover, the programming for QoS forwarding MAY be done on
end-to-end scale.
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 packet path before
handover, that is not required after handover.
3.2 Interoperability requirements
1. Interoperability with mobility protocols:
The QoS mechanism MUST coexist with other mobility protocols
related to Mobile IP that are already defined or that may be
standardized in future in the Mobile IP working group. Examples
are Fast Handover [4, 5], Regional Registrations [6], Hierarchical
MIPv6 [7], Context Transfer [8] and Reverse Tunneling [9]. It MUST
be possible to use the QoS solution with or without the
above protocols.
2. Interoperability with heterogeneous QoS paradigms:
The new end-to-end path of MN's packet stream may encounter
network domains employing a variety of QoS paradigms, such as
IntServ, DiffServ and MPLS. The QoS mechanism for Mobile IP MUST
be able to program appropriate QoS forwarding treatment for the
Hemant Chaskar [Page 2]
INTERNET-DRAFT Mobile IP QoS Requirements May, 2001
MN's packet stream in these QoS-heterogeneous network domains in
the end-to-end path.
Further, it will be a useful feature of the QoS solution if it
does not require the MN to have an explicit knowledge of the QoS
mechanism deployed in the access network as well. This is because
there may be scenarios where the MN initiates a QoS-sensitive call
when it is attached to, say, DiffServ access network, and is later
handed over to, say, IntServ access network.
3.3 Exception conditions requirements
1. Inability to support old QoS agreement after handover:
The new end-to-end path may not support the old QoS agreement
because one or more routers or links are already at capacity or
for some other reason such as policy. The QoS mechanism MUST have
provisions to handle this situation. It MAY be required to inform
the MN about the impending QoS degradation. The action taken in
response to this situation (adapt, re-negotiate or tear down) and
the decision point (MN or network) of the action are solution
specific issues.
Note that, in the above requirement we assume that the target
access router for handover is already determined by some external
means. These methods to determine appropriate target access router
are a part of the service discovery problem and are not within the
scope of this document.
3.4 Miscellaneous requirements
1. 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 etc. A QoS
mechanism SHOULD be able to support QoS along the different
potential paths. However, whether all paths are supported or only
a subset of them is supported will be determined by external
mechanisms such as, say, mobility management, policy, location
privacy requirement etc. Further, the same QoS mechanism may not
be able to support all the three alternatives.
2. The QoS mechanism MAY provide some information to the link
layers for them to support the required QoS. This is essentially a
wireless link-specific feature, but a vast number of devices using
Mobile IP will indeed be connected to the Internet via wireless
links. 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
Hemant Chaskar [Page 3]
INTERNET-DRAFT Mobile IP QoS Requirements May, 2001
parameters such as acceptable IP packet loss rate to link layers.
3.5. Obvious requirements
The QoS solution for Mobile IP MUST satisfy obvious 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.
4.0 Concluding Remarks
In this document, we described the requirements of a QoS solution
for Mobile IP. The expectation is that the appropriate working
group will use this requirements document to design a QoS solution
for Mobile IP.
5.0 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.
6.0 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] A Framework for QoS Support in Mobile IPv6, H. Chaskar and
R. Koodli, draft-chaskar-mobileip-qos-01.txt,
work in progress, March 2001.
[4] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team,
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
work in progress, February 2001.
[5] Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team,
draft-ietf-mobileip-fast-mipv6-01.txt,
work in progress, April 2001.
[6] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and
C. Perkins, draft-malinen-mobileip-regreg6-01.txt,
work in progress, March 2001.
Hemant Chaskar [Page 4]
INTERNET-DRAFT Mobile IP QoS Requirements May, 2001
[7] 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.
[8] Context Transfer Framework for Seamless Mobility, R. Koodli and
C. Perkins, draft-koodli-seamoby-ctv6-00.txt,
work in progress, February 2001.
[9] Reverse Tunneling for Mobile IP, revised, G. Montenegro, Editor,
RFC 3024, January 2001.
7.0 Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation
6000 Connection Drive
M/S M8-540
Irving, Texas 75039, USA
Phone: +1 972-894-6709 Phone:
EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com
Questions about this memo can be directed to the authors:
Hemant Chaskar
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA
Phone: +1 781-993-3785
EMail: hemant.chaskar@nokia.com
Hemant Chaskar [Page 5]