INTERNET-DRAFT J. Loughney (Editor) Internet Engineering Task Force Nokia D. Blair Cisco P. Hazy/H. Li/M. Jaseemuddin G. Tardy Nortel O. H. Levkowetz ABNW J. Manner University of Helsinki P. Neumiller 3Com Corporation R. Ramjee Lucent Issued: February 23, 2001 Expires: August 23, 2001 SeaMoby Micro Mobility Problem Statement Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 obsoleted 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. Abstract Seamless mobility requires preserving the capability, security, and quality of service offered to a mobile node during handovers. To achieve seamlessness, low (ideally no) latency and low (ideally zero) packet loss handover protocols are needed. Limiting the effect of handovers has the potential to improve handover performance in terms of latency and packet loss. This draft identifies the problem area for seamless mobility and defines the scope of the work for the SeaMoby work group. Internet Draft SeaMoby MM Problem Statement February 23, 2001 Abstract..............................................................1 1 Introduction........................................................3 1.1 Scope ...........................................................3 1.2 Problem Statement ...............................................4 1.3 Terminology .....................................................4 1.4 Architectural Diagram.............................................6 2 Overview............................................................7 2.1 Goals ...........................................................8 3 Interaction / Comparison With Other Protocols.......................8 3.1 Comparison with Mobile IP .......................................8 3.1.1 Scalability & Performance Related Issues .....................9 3.2 MANET / Ad-Hoc Networking Comparison ...........................10 4 Scenarios..........................................................10 4.1 Intra-domain mobility ..........................................10 4.1.1 Handover Within a Subnet ....................................10 4.1.2 Seamless Intra-domain Mobility With Optimized Routing. ......11 4.1.3 Confidentiality and Optimal Path When Roaming ...............11 4.1.4 Mobile Network and Route Aggregation ........................11 4.2 Inter-domain mobility ..........................................11 4.2.1 Local Mobility Spanning Multiple Domains ....................11 4.2.2 Local mobility restricted to a single domain ................12 4.3 Local-mobility protocol deployment scenarios ...................12 4.3.1 Options to Deploy Local-mobility Protocol in Routers ........12 4.3.2 Ease of Deployment by Allowing Plug and Play Capability .....12 4.3.3 Local-mobility Protocol in Different ADs ....................12 4.4 Summary ........................................................13 5 Next Steps.........................................................13 6 Security Considerations............................................13 7 IANA Considerations................................................14 8 Acknowledgments....................................................14 9 Author's Addresses.................................................14 10 References........................................................15 Full Copyright Statement.............................................16 Loughney (editor) [Page 2 Internet Draft SeaMoby MM Problem Statement February 23, 2001 1 Introduction The convergence of wireless networking and IP networking requires solutions for transporting realtime application data to IP enabled mobile devices and mobile networks. Current IP mobility solutions tend to focus primarily on best effort data transport to and from a mobile device where the routable IP address (for example, Mobile IP Care-of Address) of the Mobile Device changes during handover. Seamless handover for realtime applications imposes strict requirements on latency and packet loss. Packet drops should be minimized when moving from one access router to another. Latency due to the handover from one access router to another should be minimized so as not to impact the applications running on a mobile device or mobile network. The assumption is that a local protocol can address these goals by limiting its applicability to a smaller domain thus reducing the amount of signaling needed that should improve performance. This assumption may require that the scope of a local mobility protocol be restricted to the case of mobility support of a mobile host whose routable IP address does not change. In this draft, the term 'local mobility' is used in place of micromobility. 1.1 Scope The scope of mobility will be developed as part of the solution space. Possibilities include: Mobility where the User's routable IP address does not change Where the mobility may be: Within a subnet. Within an administrative domain. Between administrative domains. Within a limited number of hops This is not meant to be an exhaustive survey, but to point in the direction for further analysis. For example, source-based routing [DSR] and tunneling [2002] are two possible solutions for mobility. Some source routing schemes [DSR] allow: "... packet routing to be trivially loop-free, avoids the need for up-to-date routing information in the intermediate nodes through which packets are forwarded, and allows nodes forwarding or overhearing packets to cache the routing information in them for their own future use." Loughney (editor) [Page 3 Internet Draft SeaMoby MM Problem Statement February 23, 2001 Tunnel-based approaches [2002][MIPv6] may have better scaling properties, but this may not be an issue with local mobility domains. 1.2 Problem Statement There are many proposals for adding and enhancing mobility in IP networks, for example Mobile IP [2002][MIPv6]. There are a number of proposals to optimize Mobile IP signaling to allow fast handovers [FAST MIPv6]. However, none of these completely address the complex interaction of parameters and protocols needed for Seamless Handovers. A local mobility mechanism, which localizes processing and signaling, thus enabling less latency, should allow better scalability, performance and reliability resulting in seamless handovers. Moreover, a lightweight approach, customized to the exact requirements of local mobility while interoperable with a more general mobility mechanism (e.g. vanilla Mobile-IP [2002]), would allow an easier deployment in situations where local mobility is sufficient, or several general mobility mechanisms are involved. Applicability of the above might be useful for networks with multiple layer 3 access points with unreliable connectivity between the mobile and those access points, for example. While studying solutions for seamless handovers, the SEAMOBY Working Group should include the following considerations: * Mobility maintaining the same routable IP address of a mobile node or mobile network. * Handover between heterogeneous networks. For example, 802.11, Bluetooth and 3G cellular. * How to discover a new Access Link and the Access Router serving the new Access Link. * How to discover the bandwidth, cost, error rate (and other properties) of candidate Access Links. * Involving QoS characteristics as part of the handover process. * Optimize the path for mobile-to-mobile communications. * Enable plug and play capabilities for Mobile Devices, Access Routers/Access Links. * Support for mobility of mobile hosts and mobile networks Prioritization of, additions to, and details of the above items will be worked out during the requirements phase. 1.3 Terminology See [SM Terms] for additional terminology. Local Mobility The movement of an IP device without requiring a change to its routable IP address. Although Loughney (editor) [Page 4 Internet Draft SeaMoby MM Problem Statement February 23, 2001 its point of attachment may change during the move, the IP address used to reach the device (both its home and IP subnet routable IP address) do not change. Seamless Handover A handover procedure which does not result in any change in service capability, security, or quality. This procedure has strict timing requirement for the execution and low (zero) packet loss. Subnet A range of IP address designated by a common prefix constitutes a subnet. A subnet exists when no IP routing is required to reach the intended host. Examples: For IPv4: 10.1.1.0/24 (subnet mask is 255.255.255.0), for IPv6: 1234:5678:90AB:CDEF::/64 Network A Network is characterized by a range of IP address designated by a common prefix and may contain one or more adjacent subnets interconnected by IP routers. Administrative Domain A collection of networks under the same administrative control and grouped together for administrative purposes. [2753] Local Mobility Domain A Local Mobility Domain contains one or more IP subnets, networks, or Administrative Domains. Within the Local Mobility Domain, the routable IP address assigned to a Mobile Host or Mobile Router serving a Mobile Network does not change. Mobile Node (MN) An IP node capable of changing its point of attachment to the network. The MN can be either a mobile end-node or a mobile router serving an arbitrarily complex mobile network. Mobile Host (MH) An IP node capable of changing its point of attachment to the network. The MH only refers to an end-node without further routing support. Mobile Router (MR) An IP Router that may change its point of attachment to an IP network. Mobile Network An IP network where one or more Mobile Routers are used to access a larger IP network. Loughney (editor) [Page 5 Internet Draft SeaMoby MM Problem Statement February 23, 2001 Access Point (AP) A layer 2 device, which is connected to one or more Access Routers and offers the wireless link connection to the MH. Access Points are sometimes called 'base stations'. Note that this usage differs from that used by some Access Router vendors, who call their boxes 'Access Points'. Access Router (AR) An IP router residing in an Access Network and connected to one or more access points. An AR offers connectivity to MNs. The router may include intelligence beyond simple forwarding service offered by ordinary IP routers. An AR communicates with one or more Access Points. Access Network Gateway (ANG) An IP gateway that separates the Access Network from a third party network. Access Network (AN) An IP network that includes one or more ARs and ANGs. Radio Cell An area associated with each AP, where there is radio coverage, i.e. where radio communication between a MN and the specific AP is possible. 1.4 Architectural Diagram The following diagram proposes an example architecture, for reference. It is not meant to impose any restriction upon mobility, but for use to better visualize the problem space. Loughney (editor) [Page 6 Internet Draft SeaMoby MM Problem Statement February 23, 2001 +-+ | | ---+ +-+ | AP1 | | +-+ | +-----+ +-----+ | |<--> | | ---+---| AR1 |-------------------| | | [] +-+ | +-----+ \ /| ANG |--| MN AP2 | \ / | | | | \ / +-----+ | +-+ | \ / | | |----+ X | +-+ / \ | AP3 / \ | / \ +-----+ | +-+ +-----+ / \| | | |<--> | |-------| AR2 |--------------------| ANG |--| [] +-+ +-----+ | | | MR AP4 +-----+ | | Administrative Domain (AD) 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|- Administrative Domain (AD) 2 | | | +-+ +-----+ +-----+ | |<--> | | -------| AR3 |-------------------| | | [] +-+ /+-----+ /| ANG |--| MH AP5 / / | | | / / +-----+ | +-+ / / | | |---- / | +-+ / | AP6 / | / | +-+ +-----+ / | | |-------| AR4 |----------- | +-+ \ +-----+ / | AP7 \ / | \ / | \ +-----+ / | --| AR5 |------ | +-----+ | Figure 1: Architectural Diagram for Local Mobility 2 Overview Local Mobility should also consider if the new access router (ARn+1) provides the same 'services' (QoS, etc.) as expected by the user. A local mobility solution should (a) ensure that ARn+1 provides the Loughney (editor) [Page 7 Internet Draft SeaMoby MM Problem Statement February 23, 2001 same QoS as ARn or (b) alert applications that QoS is changing or has changed. 2.1 Goals Below are listed a number of issues, which any local mobility solution should address. The exact nature shall be detailed in a requirements for micromobility document. * Mobility without changing the routable IP address * Use Mobile IP WG protocols for mobility between local mobility domains * The solution is IP version neutral, although implementation details may differ for IPv4 and IPv6 * Handover to new AR that can provide the same quality and security of service as the old AR or alert the application if change occurs * Scale well with the size of the local mobility domain * Inter-technology/heterogeneous mobility support * Mobility support for mobile hosts and mobile networks * Use MIP for signaling from the MN. * Enable optimized routing for MN to MN communications. * Inter-operate with existing QoS protocols (i.e. RSVP) * Plug and play (automatic setup and recovery, handle failures gracefully) * Allow a progressive deployment * Bandwidth optimization, maximizing throughput e.g. with a smart handover algorithm * User location confidentiality * Support connectivity to multiple Access Routers simultaneously (IP diversity / load balancing) * Allow simple ad-hoc networking These goals should serve as input to local mobility requirements. 3 Interaction / Comparison With Other Protocols Local Mobility will interwork with Context Transfer. This work will define the areas of intersection (and non- intersection) between SeaMoby and the following: * Mobile IP [2002], [MIPv6] * Fast Handovers [Fast IP6] * Hierarchical MIPv4 / MIPv6 * Regional Registrations for IPv6 * Mobility management in other networks 3.1 Comparison with Mobile IP Goals Solution based on Mobile IP Loughney (editor) [Page 8 Internet Draft SeaMoby MM Problem Statement February 23, 2001 1) Seamlessness: Fast/Proactive Handover work 2) Scalability: Hierarchical Mobile IP work 3) Efficiency: Requires tunneling; Route Optimization work; For localized updates, Hierarchical Mobile IP 4) Configurability: Plug & Play of ARs/APs not addressed. Autoconfiguration is addressed in IPv6, but capabilities of the APs is not addressed by Mobile IP. 5) Reliability: HA/GFA (MIPv4); MAPs (MIPv6) need redundancy, failover capability 6) QoS: controversial; tunneling complicates QoS support. 7) Paging: controversial; not addressed 8) AAA/Registration: controversial; speed of (re)authentication and/or (re)registration during cross-AD handover may require expedited techniques or credential development. 9) Security/Message controversial; speed of message (e.g., Authentication: context transfer) authentication during cross-AD handover may require expedited techniques (e.g., key or ticket infrastructure). 10) Mobile Network Optimized Routing in IPv4 does not Support: support mobile routing; nor does MIPv6 sufficiently define interoperable support for mobile networks. Thus, Mobile IP WG does not completely cover the solution space for Seamless mobility. More detailed analysis should be done to determine the applicability of Mobile IP to local mobility and to identify Mobile IP's shortcomings. 3.1.1 Scalability & Performance Related Issues For MIPv4, there is a concern that a GFA/FA in every AR may not scale or even be desirable in extremely inexpensive AR devices. Also, there is a concern that putting an FA essentially everywhere would add complication to what could be a relatively simple micro- mobility handover. Interactions between Mobile IP and QoS mechanisms (for example RSVP) are complex and may not work fast enough. [MIP RSVP] They introduce additional signaling. It has been suggested that in order to scale MIP, Hierarchical / Regional FAs, GFAs, MAPs and other such "in the middle of the network boxes" are needed. This may be considered a limitation of MIP. This begins to chip away at some fundamental philosphies of the internet, such as making the network robust against single points of failures; that intelligence exists at the edge and so on. Loughney (editor) [Page 9 Internet Draft SeaMoby MM Problem Statement February 23, 2001 3.2 MANET / Ad-Hoc Networking Comparison The MANET WG in the IETF has an important charter to create a protocol for mobiles arranged in arbitrary and highly dynamic associations. This work is striving for robust and highly scalable routing solutions. Currently, MANET is not considering fast or seamless handover. In many instances, for example small residential networks found in the home, the network may be relatively small and has far less dynamics. The network may still have a requirement for fast and/or seamless handovers. For this reason there may be some overlap between SeaMoby and ad-hoc networking solutions. Therefore, SeaMoby MUST be able to co-exist gracefully with any MANET solutions algorithm that does become standardized. 4 Scenarios This section is intended as to provide some simple, descriptive examples of the problem. The network is based on Figure 1, in section 1.4. In the scenarios, the term mobile node (MN) is used, but the node could be a mobile host, mobile router, etc. I work for company X that controls and manages its intra-net AD1 in Figure 1. Employees at my work use mobile hosts to roam within AD1. In the city, I can be reached through ISP Y's cellular network, AD2 in Figure 1. 4.1 Intra-domain mobility Company X provides mobility service to its employees within the intra-net AD1. The IP address of a mobile host remains fixed regardless of its attachment point within the administrative domain. 4.1.1 Handover Within a Subnet The MN moves out of AP3 (802.11) coverage area, and can select AP2 (802.11) or AP1 (Bluetooth), which are all connected on the same subnet (e.g. - Ethernet) to AR1. On each handover, the new access point must ensure sufficient capacity to support traffic related to the mobile node aside of pre- existing connections. In this example, the Bluetooth access point AP1 experiences temporary environmental noise (e.g. - an oven), and the corresponding loss of available capacity. Therefore, a handover to AP2 is selected. This is an intra-AR handover between APs of the same technology. In this case Inter-AP protocol (e.g. - 802.11 IAPP) will be used to do handover. Loughney (editor) [Page 10 Internet Draft SeaMoby MM Problem Statement February 23, 2001 Later, the MN moves to an area that is only covered by AP1 (Bluetooth), so an inter-technology handover occurs between AP2 (802.11) to AP1 (Bluetooth) 4.1.2 Seamless Intra-domain Mobility With Optimized Routing. A user establishes a video phone call with a colleague. During the call both parties move around the building; their Mobile Nodes hop between subnets while changing their attachment point. However, there is no degradation in the quality of the video phone call. The network continuously maintains an optimized communication path between the two mobile nodes. More precisely, the path for a session between two mobile hosts should be ideally the same as the path selected if the mobile nodes were fixed devices. This is an instance of seamless intra-domain mobility with optimized routing. 4.1.3 Confidentiality and Optimal Path When Roaming An IETF member wants to download drafts while moving between several work group meetings. The IETF Member would like to maintain confidentiality, while doing so. Binding Updates (BU) will reveal location, and home agent (HA) produce triangular routing. Therefore, it would be very useful to have a local-mobility solution supporting location confidentiality within the administrative domain while providing optimal communication path. 4.1.4 Mobile Network and Route Aggregation An ISP provides wireless service for users travelling on the city train. The trains have an IP network installed to provide Internet access to the users on the train. There might be one or more mobile routers that have radio interfaces to communicate with the AP's of the ISP. To reach the hosts on the moving train, it is desirable to have an aggregate route for all the hosts in the train. This is an instance where an ISP provides local mobility for route aggregates. 4.2 Inter-domain mobility Service providers may make agreements allowing local mobility to span different administrative districts, or may simply provide roaming between these ADs. This can produce the following scenarios. 4.2.1 Local Mobility Spanning Multiple Domains When I drive to the supermarket, I enter Y's domain. My company X has an agreement with Y that allows me to make fast hand-off to Y's domain with the same IP address that I used to roam within X domain. The ISP Y provides under this agreement best effort connectivity to me (using the IP address assigned by X) for some time, before it requires me to perform Mobile-IP, e.g. for negotiating new IP address, issuing BUs, doing AAA, etc. As a result of Mobile-IP processing, I will get a new IP address for roaming within Y's Loughney (editor) [Page 11 Internet Draft SeaMoby MM Problem Statement February 23, 2001 domain, and other contracted services, such as QoS. The ISP Y provides best effort connectivity for the transitory period, because it must perform authentication and authorization, and retrieve user's service (QoS) profile, before providing QoS and other contracted services. This is an instance of fast handover handled by local mobility protocol first, then an inter-domain mechanism (e.g. Mobile-IP)is invoked for AAA and contracted services. 4.2.2 Local mobility restricted to a single domain When I drive to the supermarket, I enter Y's domain. My company X has an agreement with Y that allows me to roam within Y's cellular network and receive my contracted services. The ISP Y first assigns me a new IP address before providing me connectivity. Hence, as soon as I discover that I am in Y's domain, I must initiate Mobile-IP processing to perform inter-domain hand-off. 4.3 Local-mobility protocol deployment scenarios 4.3.1 Options to Deploy Local-mobility Protocol in Routers The local mobility protocol may be deployed in all the nodes or a selected set of the nodes in a network. The network nodes with local-mobility routing capability can be named as Mobile Location Aware Nodes (MLAN). If all the nodes in a network are MLAN, each node knows how to forward the data packets towards a mobile device. If only a subset of the network nodes are MLAN, tunnels can be used to connect the MLANs so that the data packets can be tunneled through the non-MLANs between a pair of MLANs. Therefore, we can think that the local-mobility protocol is applicable among the MLANs for local-mobility routing in the network. Conceptually, there should be no difference for the protocol whether it is used in the network routers or mobile agents. 4.3.2 Ease of Deployment by Allowing Plug and Play Capability A service provider may want to temporally setup wireless service in a location, or the service provider want to expand its wireless service to a new area. When the new equipment connected to the network, the new routers/agents can learn how to forward data packets by automatically learning from neighbors or other sources. A new access point should learn the capability of its neighboring APs. This automatic learning process enables plug and play capability 4.3.3 Local-mobility Protocol in Different ADs The local mobility domain can have one-to-one mapping to the administrative domain. In this deployment case, a handover between two ADs requires change of the routable IP address of the mobile node. In this case a macro-mobility protocol, such as Mobile IP, is needed inter-domain handover. Loughney (editor) [Page 12 Internet Draft SeaMoby MM Problem Statement February 23, 2001 A local mobility domain can span multiple ADs if a trust relationship exists between them allowing the use of the same routable IP address across ADs. 4.4 Summary AD Administrative Domain MD Mobility Domain SN Subnet X -> Applicable | intra-SN | inter-AD |inter-AD |intra-tech|inter-tech|inter-SN|intra-MD|inter-MD -------------------+----------+----------+--------+--------+-------- inter-AP prot | X | | | | local mobility prot| X | X | X | X | Mobile-IP | X | X | X | X | X |Inter-AP prot | local mob. Prot | MIP ------------------------+--------------+-----------------+---------- optimized route | X | X | location confidentiality| X (1) | X (2) | X (3) QoS Support | x (5) | X | Context Transfer | x (5) | X | X (4) Transparent | L3+ | L4+ | L4+ Plug & Play | X | X | (1)except for those participating in the inter-AP protocol in the same subnet (2)transparent at least to anyone outside of the MD (3)transparent to the CN, and only if reverse tunneling is used (4) proprietary at the moment (5) may be redundant in some cases where the L2 provides similar/same mechanisms. 5 Next Steps It is proposed that the next steps be: * Setting of requirements for local mobility * Proposal of solutions * Analysis of solutions * Recommendation of micromobility solution In the analysis, a critical piece will be to identify the shortcomings of Mobile IP. 6 Security Considerations This type of non-protocol document does not directly affect the security of the Internet. Loughney (editor) [Page 13 Internet Draft SeaMoby MM Problem Statement February 23, 2001 7 IANA Considerations This document does not directly affect IANA. 8 Acknowledgments The authors would like to thank Kulwinder Atwal, Peter Lei, Charlie Perkins, Michael A. Ramalho, Philip Roberts, Luca Salgarelli, Hesham Soliman, Michael Thomas, George Tsirtsis, and Mika Ylianttila for their comments and contributions to this document. 9 Author's Addresses John Loughney (editor) Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland john.loughney@nokia.com Dana Blair Cisco dblair@cisco.com Peter Hazy Nortel Networks 100 Constellation Crescent Nepean, ON K2G 6J8 Canada Phone: 1-613-768-2969 Muhammad Jaseemuddin Nortel Networks 100 Constellation Crescent Nepean, ON K2G 6J8 Canada Phone: 1-613-765-7520 jaseem@nortelnetworks.com O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista Sweden henrik.levkowetz@abrandnewworld.se Hongyi Li Nortel Networks 100 Constellation Crescent Nepean, ON K2G 6J8 Canada Phone: 1-613-763-5966 Loughney (editor) [Page 14 Internet Draft SeaMoby MM Problem Statement February 23, 2001 hyli@nortelnetworks.com Jukka Manner Department of Computer Science, University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND jmanner@cs.Helsinki.fi Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA phil_neumiller@3com.com Ram Ramjee, Bell Labs, Lucent Technologies, 101 Crawfords Corner Road, Holmdel, NJ 07733 USA Phone: 1-732-949-3306 Fax: 1-732-949-4513 ramjee@bell-labs.com Guilhem Tardy Nortel Networks 100 Constellation Crescent Nepean, ON K2G 6J8 Canada Phone: 1-613-763-1953 guilhem.tardy@nortelnetworks.com 10 References [2002] Perkins, C., "IP Mobility Support". Internet Engineering Task Force, Request for Comments (RFC) 2002, October 1996. [2460] Deering, S., and Hinden, R. (Editors); "Internet Protocol, Version 6 (IPv6) Specification"; RFC 2460, December 1998. [2753] Yavatkar, R., Pendarakis, D., Guerin, R.; "A Framework for Policy-based Admission Control"; RFC 2753; January 2000. [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, April 2000. Loughney (editor) [Page 15 Internet Draft SeaMoby MM Problem Statement February 23, 2001 [SM Terms] Manner, J. et al; "Mobility Related Terminology"; ; Work In Progress; January 12, 2001. [Fast MIP6] Tsirtsis, G. (Editor), "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-00.txt, a work in progress; February 2001. [DSR] Johnson, D. et al. "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks"; ; Work in Progress; November 17, 2000. [TORA] Park, V. et al. "Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification"; ; Work in Progress; November 24, 2000. [2501] Corson, S.; Macker, J.; "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations"; RFC 2501; January 1999. [MIP RSVP] Thomas, M.; "Analysis of Mobile IP and RSVP Interactions"; ; work in progress; February 12, 2001. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 assigns. 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 Loughney (editor) [Page 16 Internet Draft SeaMoby MM Problem Statement February 23, 2001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Loughney (editor) [Page 17]