doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3583.txt b/doc/rfc/rfc3583.txt
new file mode 100644
index 0000000..b5502e4
--- /dev/null
+++ b/doc/rfc/rfc3583.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                    H. Chaskar, Ed.
+Request for Comments: 3583                         Nokia Research Center
+Category: Informational                                   September 2003
+
+
+   Requirements of a Quality of Service (QoS) Solution for Mobile IP
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Mobile IP ensures correct routing of packets to a mobile node as the
+   mobile node changes its point of attachment to the Internet.
+   However, it is also required to provide proper Quality of Service
+   (QoS) forwarding treatment to the 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chaskar                      Informational                      [Page 1]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Problem Statement. . . . . . . . . . . . . . . . . . . .  2
+       1.2.  An approach for solving QoS problem in Mobile IP . . . .  3
+   2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Requirements of a QoS solution for Mobile IP . . . . . . . . .  3
+       3.1.  Performance requirements . . . . . . . . . . . . . . . .  4
+       3.2.  Interoperability requirements. . . . . . . . . . . . . .  5
+       3.3.  Miscellaneous requirements . . . . . . . . . . . . . . .  6
+       3.4.  Standard requirements. . . . . . . . . . . . . . . . . .  7
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  7
+   5.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       7.1.  Normative References . . . . . . . . . . . . . . . . . .  8
+       7.2.  Informative References . . . . . . . . . . . . . . . . .  8
+   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
+
+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, 6].  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.
+
+
+
+
+Chaskar                      Informational                      [Page 2]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+   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 the 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 document.  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 BCP 14, RFC 2119 [2].
+
+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 [7].  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.
+
+
+
+
+
+
+
+
+Chaskar                      Informational                      [Page 3]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+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 [8] for the
+      case of end-to-end RSVP signaling [3] 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.
+
+
+
+
+
+Chaskar                      Informational                      [Page 4]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+      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 [9] 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 [4] 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 [10, 11], localized mobility management [12,
+      13], context transfer [5] 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
+
+
+
+Chaskar                      Informational                      [Page 5]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+      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
+
+
+
+Chaskar                      Informational                      [Page 6]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+      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.  Security Considerations
+
+   The QoS (re)establishment triggered by node mobility MUST be guarded
+   against security attacks.  Such attacks could be launched by
+   malicious nodes that spoof the QoS signaling to make it appear to the
+   intermediate nodes that the MN has undergone handover.  Such an
+   attack could disrupt the QoS offered to MN's ongoing sessions as the
+   intermediate nodes may then tear down the QoS along some segments of
+   the true packet paths between MN and CN.  The malicious nodes may
+   also request a reduced level of QoS or supply fake packet
+   classifiers, thereby affecting QoS over some segments (e.g., that do
+   not get affected by the spoofed handover) of the true packet paths
+   between MN and CN.  Further, network resources may be wasted or used
+   in an unauthorized manner by the malicious nodes that spoof MN's
+   handover.  To prevent this, QoS mechanism MUST provide means for
+   intermediate nodes to verify the authenticity of handover-induced QoS
+   (re)establishment.
+
+
+
+
+
+Chaskar                      Informational                      [Page 7]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+5.  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.
+
+6.  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, Brian Carpenter (IBM), Marc Greis
+   (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael
+   Thomas (Cisco) for their input during the preparation of this
+   document.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344,
+        August 2002.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer,
+        M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A
+        Framework for Integrated Services Operation over Diffserv
+        Networks", RFC 2998, November 2000.
+
+   [4]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
+        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
+        Specification", RFC 2205, September 1997.
+
+   [5]  Kempf, J., Ed., "Problem description: Reasons for performing
+        context transfers between nodes in an IP Access Network", RFC
+        3374, September 2002.
+
+7.2.  Informative References
+
+   [6]  Johnson, D., Perkins, C. and J. Arkko, "Mobility support in
+        IPv6", Work in Progress, May 2003.
+
+
+
+
+
+
+Chaskar                      Informational                      [Page 8]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+   [7]  Trossen, D., et al., "Issues in Candidate Access Router
+        discovery for seamless IP handoffs", Work in Progress, October
+        2002.
+
+   [8]  Chaskar, H. and R. Koodli, "QoS support in Mobile IP version 6",
+        IEEE Broadband Wireless Summit (Networld+Interop), May 2001.
+
+   [9]  Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work
+        in Progress, February 2001.
+
+   [10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile
+        IPv4", Work in Progress, June 2002.
+
+   [11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in
+        Progress, March 2003.
+
+   [12] Williams, C., Ed., "Localized mobility management requirements",
+        Work in Progress, March 2003.
+
+   [13] Soliman, H., et al., "Hierarchical MIPv6 mobility management
+        (HMIPv6)", Work in Progress, October 2002.
+
+8.  Authors' Addresses
+
+   The working group can be contacted via the current chair:
+
+   John Loughney
+   Nokia Research Center
+   11-13 Italahdenkatu
+   00180 Helsinki
+   Finland
+
+   EMail: john.loughney@nokia.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
+
+
+
+
+
+
+
+
+Chaskar                      Informational                      [Page 9]
+
+RFC 3583              Mobile IP QoS Requirements          September 2003
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chaskar                      Informational                     [Page 10]
+