draft-ietf-mobileip-qos-requirements-02.txt   draft-ietf-mobileip-qos-requirements-03.txt 
IETF Mobile IP Working Group Hemant Chaskar IETF Mobile IP Working Group Hemant Chaskar
INTERNET-DRAFT Editor INTERNET-DRAFT Editor
Nokia Research Center Nokia Research Center
10 February 2002 30 July 2002
Requirements of a QoS Solution for Mobile IP Requirements of a QoS Solution for Mobile IP
draft-ietf-mobileip-qos-requirements-02.txt draft-ietf-mobileip-qos-requirements-03.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 4, line 12 skipping to change at page 4, line 12
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 Seamoby working groups. particularly in Mobile IP and Seamoby working groups.
Examples are Fast Handover [8, 9], Regional Registrations [10], Examples are fast handover [8, 9], localized mobility management
Hierarchical MIPv6 [11], Context Transfer [12] etc. The QoS [10, 11], context transfer [12] etc. The QoS mechanism for
mechanism for Mobile IP SHOULD take advantage of these mobility Mobile IP SHOULD take advantage of these mobility protocols for the
protocols for the optimized operation. However, the QoS scheme optimized operation. However, the QoS scheme MUST have provisions
MUST have provisions to accomplish its tasks even if one or more to accomplish its tasks even if one or more of these mobility
of these mobility protocols are not used. protocols are not used.
2. Interoperability with heterogeneous packet paths as 2. Interoperability with heterogeneous packet paths as
regards QoS paradigms: regards QoS paradigms:
The new path after handover, of the MN's packet stream, may The new path after handover, of the MN's packet stream, may
traverse network domains employing different QoS paradigms traverse network domains employing different QoS paradigms
compared to those along the old path. The QoS mechanism for Mobile compared to those along the old path. The QoS mechanism for Mobile
IP SHOULD be able to establish proper QoS forwarding treatment for IP SHOULD be able to establish proper QoS forwarding treatment for
the MN's packet stream along the packet paths deploying different the MN's packet stream along the packet paths deploying different
QoS paradigms (best current practices), in a manner consistent QoS paradigms (best current practices), in a manner consistent
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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, reverse temporary tunnel between old and new access routers, reverse
tunnel from the new access router (Foreign Agent) to HA etc. A QoS 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 mobility management, policy, location external mechanisms such as mobility management, policy, location
privacy requirement and so on. Further, the same QoS mechanism privacy requirement and so on. Further, the same QoS mechanism
may not be able to support all these paths. may not be able to support all these paths.
2. Interactions with link-layer support for QoS: 2. Interactions with wireless link-layer support for QoS:
The QoS mechanism MAY provide some information to the link Since a vast number of devices using Mobile IP will be connected to
layers for them to support the required QoS. Since a vast number the Internet via wireless links, the QoS mechanism for Mobile IP
of devices using Mobile IP will be connected to the Internet via MAY provide some information to the wireless link layers for them
wireless links, QoS parameters relevant for wireless links, such to support the required QoS.
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 An example scenario that may benefit from such information
levels of error protection at the link layer. For such cases, an is that of the two UDP streams associated with the same media, but
IP-layer QoS mechanism may indicate some generic parameters such requiring different levels of error protection at the wireless link
as acceptable IP packet loss rate to link layers. 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 3.4. Standard requirements
The QoS solution for Mobile IP SHOULD satisfy standard The QoS solution for Mobile IP SHOULD satisfy standard
requirements such as scalability, security, conservation of requirements such as scalability, security, conservation of
wireless bandwidth, low processing overhead on mobile terminals, wireless bandwidth, low processing overhead on mobile terminals,
providing hooks for authorization and accounting, and robustness providing hooks for authorization and accounting, and robustness
against failures of any Mobile IP-specific QoS components in the against failures of any Mobile IP-specific QoS components in the
network. While it is not possible to set quantitative targets for network. While it is not possible to set quantitative targets for
these desirable properties, the QoS solution MUST be evaluated these desirable properties, the QoS solution MUST be evaluated
skipping to change at page 6, line 7 skipping to change at page 6, line 25
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 (Megisto) and Michael (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael
Thomas (Cisco) for their input during the preparation of Thomas (Cisco) for their input during the preparation of
this document. this document.
6 References 6 References
[1] IP mobility support, C. Perkins (Editor), RFC 2002, October 1996. [1] ``IP mobility support for IPv4", C. Perkins (Editor), RFC 3220,
January 2002.
[2] Mobility support in IPv6, D. Johnson and C. Perkins, [2] ``Mobility support in IPv6", D. Johnson, C. Perkins, and J. Arkko,
draft-ietf-mobileip-ipv6-13.txt, draft-ietf-mobileip-ipv6-18.txt,
work in progress, November 2000. work in progress, July 2002.
[3] Issues in Candidate Access Router discovery for seamless IP [3] ``Issues in Candidate Access Router discovery for seamless IP
handoffs, D. Trossen et. al., handoffs", D. Trossen et. al.,
draft-ietf-seamoby-cardiscovery-issues-00.txt, draft-ietf-seamoby-cardiscovery-issues-03.txt,
work in progress, July 2001. work in progress, June 2002.
[4] QoS support in Mobile IP version 6, H. Chaskar and R. Koodli, [4] ``QoS support in Mobile IP version 6", H. Chaskar and R. Koodli,
IEEE Broadband Wireless Summit (Networld+Interop), May 2001. IEEE Broadband Wireless Summit (Networld+Interop), May 2001.
[5] A Framework for Integrated Services operation over Diffserv [5] ``A Framework for Integrated Services operation over Diffserv
networks, Y. Bernet et. al., RFC 2998, November 2000. networks", Y. Bernet et. al., RFC 2998, November 2000.
[6] Analysis of Mobile IP and RSVP interactions, M. Thomas, [6] ``Analysis of Mobile IP and RSVP interactions", M. 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.
[7] 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.
[8] Low latency handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, [8] ``Low latency handoffs in Mobile IPv4", MIPv4 Handoffs Design
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, Team, draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt,
work in progress, February 2001. work in progress, June 2002.
[9] Fast handovers for Mobile IPv6, MIPv6 Handover Design Team, [9] ``Fast handovers for Mobile IPv6", G. Dommety (Editor),
draft-ietf-mobileip-fast-mipv6-01.txt, draft-ietf-mobileip-fast-mipv6-04.txt,
work in progress, April 2001. work in progress, March 2002.
[10] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le, and [10] ``Localized mobility management requirements, C. Williams
C. Perkins, draft-malinen-mobileip-regreg6-01.txt, (Editor), draft-ietf-mobileip-lmm-requirements-02.txt,
work in progress, March 2001. work in progress, June 2002.
[11] Hierarchical MIPv6 mobility management, H. Soliman, [11] ``Hierarchical MIPv6 mobility management (HMIPv6)", H. Soliman
C. Castelluccia, K. El-Malki, and L. Bellier, et. al., draft-ietf-mobileip-hmipv6-06.txt,
draft-ietf-mobileip-hmipv6-02.txt, work in progress, July 2002.
work in progress, February 2001.
[12] Problem description: Reasons for performing context transfers [12] ``Problem description: Reasons for performing context transfers
between nodes in an IP Access Network, edited by J. Kempf, between nodes in an IP Access Network", edited by J. Kempf,
draft-ietf-seamoby-context-transfer-problem-stat-04.txt, draft-ietf-seamoby-context-transfer-problem-stat-04.txt,
work in progress, May 2002. work in progress, May 2002.
7 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 Megisto Nokia Corporation Megisto
6000 Connection Drive 20251 Century Blvd, Suite 120 6000 Connection Drive 20251 Century Blvd, Suite 120
skipping to change at page 7, line 25 skipping to change at page 8, line 5
Questions about this memo can be directed to the editor: 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 Appendix: Changes Made from 00 Version:
Few editorial changes were made from 00 version based on the Few editorial changes were made from 00 version based on the
working group feedback received on the Mobile IP mailing list. working group feedback received on the Mobile IP mailing list.
1. A clarification is added at the beginning of Section 3, which 1. A clarification is added at the beginning of Section 3, which
states that QoS-capability negotiations that may affect states that QoS-capability negotiations that may affect
handover decision are outside the scope of this document. handover decision are outside the scope of this document.
2. Section 3.1.2 was reworded for better clarity. 2. Section 3.1.2 was reworded for better clarity.
3. Section 3.2.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 4. Section 3.4 is now called "Standard Requirements" rather than
"Obvious Requirements". "Obvious Requirements".
5. Section 4 is now called "Recommendation" rather than 5. Section 4 is now called "Recommendation" rather than
"Concluding Remarks". "Concluding Remarks".
Changes Made from 01 Version Changes Made from 01 Version
The following changes were made from 01 version in response to The following changes were made from 01 version in response to
IESG comments. IESG comments:
1. Requirement 3.2(2) is changed from MUST to SHOULD. 1. Requirement 3.2(2) is changed from MUST to SHOULD.
2. IESG was concerned about the references to too many individual 2. IESG was concerned about the references to too many individual
submissions in the 01 version. Now, individual submission submissions in the 01 version. Now, individual submission
references 4 and 12 in 01 version are replaced by a reference references 4 and 12 in 01 version are replaced by a reference
to IEEE conference paper and Seamoby WG document, respectively. to IEEE conference paper and Seamoby WG document, respectively.
However, no alternatives could be found for 6, 10 and 11. However, no alternatives could be found for 6, 10 and 11.
Nevertheless the content in these individual submissions is Nevertheless the content in these individual submissions is
important to understand certain requirements. Hence, these important to understand certain requirements. Hence, these
references are not removed. references are not removed.
Changes was made from 02 version
1. Section 3.3.2 is revised for better clarity.
2. References updated.
 End of changes. 

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