draft-ietf-mobileip-qos-requirements-00.txt   draft-ietf-mobileip-qos-requirements-01.txt 
IETF Mobile IP Working Group Hemant Chaskar IETF Mobile IP Working Group Hemant Chaskar
INTERNET-DRAFT Editor INTERNET-DRAFT Editor
Expires: November 2001 Nokia Research Center Nokia Research Center
June 2001 20 August 2001
Requirements of a QoS Solution for Mobile IP Requirements of a QoS Solution for Mobile IP
draft-ietf-mobileip-qos-requirements-00.txt draft-ietf-mobileip-qos-requirements-01.txt
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet other groups may also distribute working documents as Internet
Drafts. Drafts.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Mobile IP protocol ensures correct routing of packets to mobile Mobile IP protocol ensures correct routing of packets to mobile
node as the mobile node changes its point of attachment with the node as the mobile node changes its point of attachment with the
Internet. However, it is also required to provide proper QoS Internet. However, it is also required to provide proper QoS
forwarding treatment to mobile node's packet stream at the forwarding treatment to mobile node's packet stream at the
intermediate nodes in the network, so that QoS-sensitive IP intermediate nodes in the network, so that QoS-sensitive IP
services can be supported over Mobile IP. This document describes services can be supported over Mobile IP. This document describes
requirements of an IP QoS mechanism for its satisfactory operation requirements of an IP QoS mechanism for its satisfactory operation
with Mobile IP. with Mobile IP.
1.0 Introduction 1 Introduction
Mobile IP is a technology that allows a "mobile node" (MN) to Mobile IP is a technology that allows a "mobile node" (MN) to
change its point of attachment to the Internet while change its point of attachment to the Internet while
communicating with the "correspondent node" (CN) using IP. The communicating with the "correspondent node" (CN) using IP. The
formal description of Mobile IP can be found in [1, 2]. Mobile IP formal description of Mobile IP can be found in [1, 2]. Mobile IP
primarily addresses the correct routing of packets to MN's current primarily addresses the correct routing of packets to MN's current
point of attachment with the Internet. point of attachment with the Internet.
It is also essential to provide proper Quality of Service (QoS) It is also essential to provide proper Quality of Service (QoS)
forwarding treatment to the packets sent by or destined to MN forwarding treatment to the packets sent by or destined to MN
skipping to change at page 1, line 71 skipping to change at page 1, line 71
Mobile IP places on an IP QoS mechanism. Mobile IP places on an IP QoS mechanism.
1.1 Problem statement 1.1 Problem statement
When a MN using Mobile IP undergoes handover from one access When a MN using Mobile IP undergoes handover from one access
router to another, the path traversed by MN's packet stream in the 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 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 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 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 MN's ongoing session may start using the new care-of address after
handover, and hence, may not be recognized by some forwarding handover. Hence, they may not be recognized by some forwarding
functions along the old path that use IP address as a key. 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 Finally, handover may occur between the subnets that are under
different administrative control. different administrative control.
In the light of this scenario, it is essential to establish proper In the light of this scenario, it is essential to establish proper
QoS support at the intermediate nodes in the new end-to-end path QoS support for the MN's packet stream along the new packet path.
of the MN's packet stream.
1.2 An approach for solving QoS problem in Mobile IP 1.2 An approach for solving QoS problem in Mobile IP
There are four important steps involved in solving the QoS problem There are four important steps involved in solving the QoS problem
for Mobile IP. They are as follows: (1) List the requirements that for Mobile IP. They are as follows: (1) List the requirements that
Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS
solutions against the requirements, (3) Decide if current solutions against the requirements, (3) Decide if current
solutions need to be extended, or if new ones need to be solutions need to be extended, or if new ones need to be
defined, and (4) Depending on the result of step 3, define new defined, and (4) Depending on the result of step 3, define new
solutions or fix the old ones. solutions or fix the old ones.
Of these, the first step, i.e. the requirements step, is addressed 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 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 detail. However, so as to create useful insight into the Mobile IP
QoS problem, wherever relevant, this draft highlights the QoS problem, at times this document highlights the
shortcomings of some popular current practices (proposals) for shortcomings of some well known current proposals for
establishing QoS support along the packet path, in the light of establishing QoS support for the packet stream in the network,
the requirements imposed by Mobile IP. with respect to the requirements imposed by Mobile IP.
2 0 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
3 0 Requirements of a QoS solution for Mobile IP 3 Requirements of a QoS solution for Mobile IP
This section describes the requirements of a QoS solution for This section describes the requirements of a QoS solution for
Mobile IP. Conversely, note that only Mobile IP-specific Mobile IP. Conversely, note that only Mobile IP-specific
requirements are described here. We do not assume any particular requirements are described here. We do not assume any particular
version (4 or 6) of IP while describing the requirements. version (4 or 6) of IP while describing the requirements.
Solutions can be designed for IPv4 and IPv6 independently, or a Solutions can be designed for IPv4 and IPv6 independently, or a
single solution can be designed to work with both versions. 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 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 3.1 Performance requirements
1. Minimize the interruption in QoS at the time of handover: 1. Minimize the interruption in QoS at the time of handover:
At the time of handover, interruption in QoS would occur if the At the time of handover, interruption in QoS would occur if the
packets sent by or destined to the MN arrive at the intermediate packets sent by or destined to the MN arrive at the intermediate
node in the new end-to-end packet path without that node having node in the new packet path without that node having
information about their QoS forwarding requirement. Then, those information about their QoS forwarding requirement. Then, those
packets will receive default forwarding treatment. Such QoS packets will receive default forwarding treatment. Such QoS
interruption MUST be minimized. A good metric for this performance interruption MUST be minimized. A good metric for this performance
is the number of packets that get served with "default" QoS at the 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. time of handover. The number of such packets MUST be minimized.
As an example, this performance metric is computed in [3] for the As an example, this performance metric is computed in [4] for the
case of end-to-end RSVP signaling [4] with Mobile IPv6. It is 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 shown there that when the end-to-end path of packets changes at
large after handover or when the care-of address changes after large after handover or when the care-of address changes after
handover, OPWA (One Pass With Advertisement) model of reservation handover, OPWA (One Pass With Advertisement) model of reservation
used by RSVP causes the latency of about one round-trip time 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 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 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 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 round-trip time, after these nodes are ready to use the new
care-of address, may get default forwarding treatment at the care-of address, may get default forwarding treatment at the
intermediate nodes. Such a latency in QoS programming may be intermediate nodes. Such a latency in QoS programming may be
acceptable at the time of session initiation, but is not acceptable at the time of session initiation, but it is not
acceptable in the middle of an active session as would be the case acceptable in the middle of an active session as would be the case
with handover. with handover.
2. Localize the QoS (re)establishment to the affected parts of the 2. Localize the QoS (re)establishment to the affected parts of the
packet path in the network: packet path in the network:
In many cases, handover changes only a small segment of the In many cases, handover changes only a small segment of the
end-to-end path of MN's packet stream near the extremity. Then, end-to-end path of MN's packet stream near the extremity. Then,
the QoS mechanism MUST limit the extent of QoS (re)establishment the QoS mechanism MUST limit the extent of QoS (re)establishment
to the affected segment of the end-to-end path only. Of course, if to the affected segment of the end-to-end path only.
the end-to-end path changes at large after handover, the QoS
mechanism MUST be able to address that in a manner that is
consistent with the QoS scheme(s) used along the new
end-to-end packet path.
Note that the QoS signaling protocol such as RSVP [5] can localize However, note that handover may sometimes cause the end-to-end
the QoS signaling to the affected parts of the end-to-end path if path of MN's packet stream in the network to change at large. This
the care-of address does not change upon handover. However, if the may happen, for example, in the case of handover between different
care-of address changes upon handover, RSVP as currently defined administrative domains. If the QoS mechanism used to establish QoS
fails to localize the QoS signaling [see 6]. In addition, it will support for the MN's packet stream along the new packet path in
cause double reservations on the part of end-to-end path that the network is based on the explicit end-to-end provisioning as
remains unchanged after handover. such, it MUST perform so at the time of such handover.
When the care-of address changes upon handover, it may be When the care-of address changes upon handover, it may be required
required to perform some signaling even over the unchanged part of to perform some signaling even over the unchanged part of the
the end-to-end path if the path contains any QoS mechanisms that end-to-end path if the path contains any QoS mechanisms that use
use IP address as a key to forwarding functions. Examples are IP address as a key to forwarding functions. Examples are
FILTER SPECs in the IntServ nodes or packet classifiers at the FILTER SPECs in the IntServ nodes or packet classifiers at the
edges of DiffServ networks. However, double provisioning of edges of DiffServ networks. However, double provisioning of
resources over the unchanged part of the packet path resources over the unchanged part of the packet path
MUST be avoided. 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 3. Releasing after handover the QoS state (if any) along the old
packet path: packet path:
The QoS mechanism MUST provide some means (explicit or The QoS mechanism MUST provide some means (explicit or
timer-based) to release any QoS state along the old packet path timer-based) to release any QoS state along the old packet path
that is not required after handover. It is desirable that the that is not required after handover. It is desirable that the
unwarranted QoS states, if any, along the old path are released as unwarranted QoS states, if any, along the old path are released as
quickly as possible at the time of handover. Note that, during quickly as possible at the time of handover. Note that, during
handover, the MN may not always get a chance to send explicit tear 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 down message along the old path because of the loss of link layer
connectivity with the old access router. connectivity with the old access router.
3.2 Interoperability requirements 3.2 Interoperability requirements
1. Interoperability with mobility protocols: 1. Interoperability with mobility protocols:
A number of mobility protocols that are complementary to Mobile IP A number of mobility protocols that are complementary to Mobile IP
are already defined or may be defined in future in IETF, are already defined or may be defined in future in IETF,
particularly in Mobile IP and Seamless Mobility working groups. particularly in Mobile IP and Seamoby working groups.
Examples are Fast Handover [7, 8], Regional Registrations [9], Examples are Fast Handover [8, 9], Regional Registrations [10],
Hierarchical MIPv6 [10], Context Transfer [11] etc. The QoS Hierarchical MIPv6 [11], Context Transfer [12] etc. The QoS
mechanism for Mobile IP SHOULD take advantage of these mobility mechanism for Mobile IP SHOULD take advantage of these mobility
protocols for 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 end-to-end packet paths as 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: regards QoS paradigms:
The new end-to-end path of MN's packet stream may encounter The new path after handover, of the MN's packet stream, may
network domains employing a variety of QoS paradigms, such as traverse network domains employing different QoS paradigms
IntServ, DiffServ and MPLS. Each of the networks/routers along compared to those along the old path. The QoS mechanism for
this path may require a different kind of information about the
MN's packet stream, so that proper QoS forwarding treatment can
be established for the MN's packet stream. The QoS mechanism for
Mobile IP MUST be able to establish proper QoS forwarding Mobile IP MUST be able to establish proper QoS forwarding
treatment for the MN's packet stream in these QoS-heterogeneous treatment for the MN's packet stream along the packet paths
network domains in the new end-to-end path. 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 As an illustration, suppose that the MN is currently attached to
an access router which is the edge router of a DiffServ network, an access router which is the edge router of a DiffServ network,
and that the packet classifier and traffic policer for the MN's and that the packet classifier and traffic policer for the MN's
flows are somehow programmed in this access router. Further, flows are presently programmed in this access router. Now, suppose
assume that the QoS policy in this access network takes care of that the MN needs to be handed over to the access router which is
SLAs with other networks that it attaches to. Now, suppose that at the edge of an IntServ network. The new access network would
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 expect the exchange of RSVP messages so that proper QoS
forwarding treatment can be established for the MN's packet stream forwarding treatment can be established for the MN's packet stream
in that access network. Here is another example of in that access network. QoS mechanism for Mobile IP MUST have
cross-QoS-technology handover. Suppose that the MN is currently provisions to handle such heterogeneity as regards the QoS
attached to an access router that is a part of access network X mechanisms deployed along different packet paths.
and is to be handed over to the access router that is a part of
access network Y. In network X, the access router acts as a proxy
(and possibly communicates with some QoS agent in the network) to
program (possibly end-to-end) QoS forwarding treatment for the
MN's packet stream. On the other hand, network Y expects the end
hosts attached to it to send explicit QoS request messages along
the data path.
The QoS solution for Mobile IP MUST be able to establish QoS
support for MN's packet stream over the packet paths that use
diverse (best current practices) end-to-end QoS mechanisms.
3.3 Miscellaneous requirements 3.3 Miscellaneous requirements
1. QoS support along multiple paths: 1. QoS support along multiple packet paths:
After MN undergoes handover from one access router to another, After MN undergoes handover from one access router to another,
potentially, there could be multiple paths over which MN's packet potentially, there could be multiple paths over which MN's packet
may propagate. Examples of these path are: route-optimized path may propagate. Examples of these path are: route-optimized path
between the MN and its CN, triangle route via Home Agent (HA), between the MN and its CN, triangle route via Home Agent (HA),
temporary tunnel between old and new access routers etc. A QoS 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 mechanism SHOULD be able to support QoS along the different
potential packet paths. However, whether all paths are supported potential packet paths. However, whether all paths are supported
or only a subset of them is supported will be determined by or only a subset of them is supported will be determined by
external mechanisms such as, say, mobility management, policy, external mechanisms such as mobility management, policy, location
location privacy requirement etc. Further, the same QoS mechanism privacy requirement and so on. Further, the same QoS mechanism
may not be able to support all the three alternatives. may not be able to support all these paths.
2. Interactions with link-layer support for QoS: 2. Interactions with link-layer support for QoS:
The QoS mechanism MAY provide some information to the link The QoS mechanism MAY provide some information to the link
layers for them to support the required QoS. Since a vast number layers for them to support the required QoS. Since a vast number
of devices using Mobile IP will be connected to the Internet via of devices using Mobile IP will be connected to the Internet via
wireless links, wireless link significant QoS parameters such as wireless links, QoS parameters relevant for wireless links, such
error rate MAY have to be included in the set of QoS parameters to as error rate, MAY have to be included in the set of IP-level QoS
be possibly considered and supported by the underlying link layer. parameters to be possibly considered by the underlying link layer.
An example scenario will be two UDP streams requiring different An example scenario will be two UDP streams requiring different
levels of error protection at the link layer. For such cases, an levels of error protection at the link layer. For such cases, an
IP-layer QoS mechanism may indicate some generic parameters such IP-layer QoS mechanism may indicate some generic parameters such
as acceptable IP packet loss rate to link layers. as acceptable IP packet loss rate to link layers.
3.4. Obvious requirements 3.4. Standard requirements
The QoS solution for Mobile IP SHOULD satisfy obvious requirements The QoS solution for Mobile IP SHOULD satisfy standard
such as scalability, security, conservation of wireless bandwidth, requirements such as scalability, security, conservation of
low processing overhead on mobile terminals, providing hooks for wireless bandwidth, low processing overhead on mobile terminals,
authorization and accounting, and robustness against failures of providing hooks for authorization and accounting, and robustness
any Mobile IP-specific QoS components in the network. While it is against failures of any Mobile IP-specific QoS components in the
not possible to set quantitative targets for these desirable network. While it is not possible to set quantitative targets for
properties, the QoS solution MUST be evaluated against these these desirable properties, the QoS solution MUST be evaluated
criteria. against these criteria.
4.0 Concluding Remarks 4 Recommendation
In this document, we described the requirements of a QoS solution In this document, we described the requirements of a QoS solution
for Mobile IP. The expectation is that the appropriate working for Mobile IP. The expectation is that the appropriate working
group will use this requirements document to provide a QoS group will use this requirements document to provide a QoS
solution for Mobile IP. solution for Mobile IP.
5.0 Acknowledgment 5 Acknowledgment
I would like to acknowledge the participants of the mailing list I would like to acknowledge the participants of the mailing list
that was set up to discuss the above requirements. Their that was set up to discuss the above requirements. Their
contributions and active participation in the discussion on the contributions and active participation in the discussion on the
mailing list were very useful in the preparation of this document. mailing list were very useful in the preparation of this document.
Special thanks are due to, in alphabetical order, Marc Greis Special thanks are due to, in alphabetical order, Marc Greis
(Nokia), Glenn Morrow (Nortel), Phil Roberts and Michael Thomas (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael
(Cisco) for their comments during the preparation of this document. Thomas (Cisco) for their comments during the preparation of
this document.
6.0 References 6 References
[1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996.
[2] Mobility Support in IPv6, D. Johnson and C. Perkins, [2] Mobility Support in IPv6, D. Johnson and C. Perkins,
draft-ietf-mobileip-ipv6-13.txt, draft-ietf-mobileip-ipv6-13.txt,
work in progress, November 2000. work in progress, November 2000.
[3] A Framework for QoS Support in Mobile IPv6, H. Chaskar and [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] A Framework for QoS Support in Mobile IPv6, H. Chaskar and
R. Koodli, draft-chaskar-mobileip-qos-01.txt, R. Koodli, draft-chaskar-mobileip-qos-01.txt,
work in progress, March 2001. work in progress, March 2001.
[4] A Framework for Integrated Services Operation over Diffserv [5] A Framework for Integrated Services Operation over Diffserv
Networks, Yoram Bernet et. al., RFC 2998, November 2000. Networks, Yoram Bernet et. al., RFC 2998, November 2000.
[5] Analysis of Mobile IP and RSVP Interactions, Michael Thomas, [6] Analysis of Mobile IP and RSVP Interactions, Michael Thomas,
draft-thomas-seamoby-rsvp-analysis-00.txt, draft-thomas-seamoby-rsvp-analysis-00.txt,
work in progress, February 2001. work in progress, February 2001.
[6] Resource ReSerVation Protocol -- Version 1 Functional [7] Resource ReSerVation Protocol -- Version 1 Functional
Specification, R. Braden et. al., RFC 2750, September 1997. Specification, R. Braden et. al., RFC 2750, September 1997.
[7] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, [8] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team,
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
work in progress, February 2001. work in progress, February 2001.
[8] Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team, [9] Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team,
draft-ietf-mobileip-fast-mipv6-01.txt, draft-ietf-mobileip-fast-mipv6-01.txt,
work in progress, April 2001. work in progress, April 2001.
[9] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and [10] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and
C. Perkins, draft-malinen-mobileip-regreg6-01.txt, C. Perkins, draft-malinen-mobileip-regreg6-01.txt,
work in progress, March 2001. work in progress, March 2001.
[10] Hierarchical MIPv6 Mobility Management, H. Soliman, [11] Hierarchical MIPv6 Mobility Management, H. Soliman,
C. Castelluccia, K. El-Malki, and L. Bellier, C. Castelluccia, K. El-Malki, and L. Bellier,
draft-ietf-mobileip-hmipv6-02.txt, draft-ietf-mobileip-hmipv6-02.txt,
work in progress, February 2001. work in progress, February 2001.
[11] Context Transfer Framework for Seamless Mobility, R. Koodli and [12] Context Transfer Framework for Seamless Mobility, R. Koodli and
C. Perkins, draft-koodli-seamoby-ctv6-00.txt, C. Perkins, draft-koodli-seamoby-ctv6-00.txt,
work in progress, February 2001. work in progress, February 2001.
7.0 Addresses 7 Addresses
The working group can be contacted via the current chairs: The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts Basavaraj Patil Phil Roberts
Nokia Corporation Nokia Corporation Megisto
6000 Connection Drive 20251 Century Blvd 6000 Connection Drive 20251 Century Blvd, Suite 120
M/S M8-540 Suite 120
Irving, Texas 75039, USA Germantown, MD 20874 Irving, Texas 75039, USA Germantown, MD 20874
Phone: +1 972-894-6709 Phone: +1 847-202-9314 Phone: +1 972-894-6709 Phone: +1 847-202-9314
EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com
Questions about this memo can be directed to the authors: Questions about this memo can be directed to the editor:
Hemant Chaskar Hemant Chaskar
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803, USA Burlington, MA 01803, USA
Phone: +1 781-993-3785 Phone: +1 781-993-3785
EMail: hemant.chaskar@nokia.com 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".
 End of changes. 

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