IETF INTERNET-DRAFT Thierry Ernst, WIDE and INRIA October 2002 "Network Mobility Support Requirements" draft-ernst-nemo-requirements-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or 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 The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts only (host mobility support). In contrast, network mobility support (NEMO support) deals with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. In this situation, mobility support is to provide continuous Internet sessions not only to the router connecting the mobile network to the global Internet, but also to nodes behind the mobile router. This document tries to identify what constraints limit the implementation and the deployment of a potentially and ideally good solution, and what requirements solutions must comply with. Our main aim is to raise the discussion on the mailing list. Ernst Expires May 2003 [Page 1] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Contents Status of This Memo Abstract 1. Introduction 2. Overview 2.1. Potential Configurations 2.2. Observations and Constraints O1: Structure of the mobile network O2: Mobile Router is a transit point O3: Dog-leg Routing O4: Ad-Hoc Network O5: Scalability O6: Deployment and Backward Compatibility O7: Routers in the Mobile Network O8: Addressing Constraints 3. High-Level Requirements 3.1. Migration Transparency 3.2. Operational Transparency 3.3. Performance Transparency (Seamless Mobility) 3.4. Layers Independence 3.5. NEMO Support Transparency for MNNs 3.7. Minimum Signaling Overload 3.12. No impact on CNs or Internet routing 3.13. Security 3.13.1. Confidentiality 3.13.2. Authentication 3.13.3. Authorization 3.13.4. Location Privacy 3.14. Access Control 3.14.1. Access Control for VMNs 3.14.2. Access Control Architecture 3.14.3. Access Control in the Fixed Network 3.15. Internet-wide Mobility 3.16. Unified Solution 3.17. Mobile CNs 3.18. Addressing Constraints 4. Basic Support Requirements 5. Extended Support Requirements Acknowledgments References Author's Addresses Ernst Expires May 2003 [Page 2] INTERNET-DRAFT Network Mobility Support Requirements February 2002 1. Introduction Traditional work on mobility support is to provide continuous Internet connectivity to mobile hosts only (host mobility support). In contrast, network mobility support (NEMO support) deals with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. In this situation, mobility support is to provide continuous Internet sessions not only to the router connecting the mobile network to the global Internet, but also to nodes behind the mobile router. The purpose of the present document is to raise discussion in order to identify what constraints limit the implementation and the deployment of a potentially and ideally good solution, and what requirements solutions must comply to. Most constraints and requirements that we have listed are equally applicable to host mobility support and network mobility support. Some of them have been debated in the literature as far as host mobility support was concerned; we have extended this list to include those related to network mobility support. Other requirements are discussed in [REQUIREMENTS-1], [REQUIREMENTS-2}, [REQUIREMENTS-3] and [REQUIREMENTS-4]. All requirements may not be satisfied by a single solution. For the sake of modularity, we may decide to use separate solutions for different aspects of the problem space. Note that most requirements discussed for host mobility support, like for instance in [Bhagwat96], [Myles93], [Castelluccia97], [Caceres96] or many other papers, are equally applicable to NEMO support. However, they must be extended and refined to meet the needs of NEMO support. We assume that the reader is familiar with the terminology defined in [TERMINOLOGY]. In order to understand the rationale that drives to the requirements, in section 2, we describe potential network mobility configurations and we make a number of observations that may constraint the forthcoming solutions. In section 3, we list some high level requirements. In section 4 and 5, the high-level requirements are refined in a more explicit manner for basic support and extended support. This list is not exhaustive and should be combined with the requirements found in the other drafts. Ernst Expires May 2003 [Page 3] INTERNET-DRAFT Network Mobility Support Requirements February 2002 2. Overview 2.1 Potential Configurations Network mobility support deals with entire networks of computers that change their point of attachment to the global Internet and need to maintain continuous Internet connectivity. Cases of mobile networks include networks attached to people (Personal Area Networks or PAN), and networks of sensors and access networks deployed in vehicles (aircrafts, boats, cars, trains, etc). A PAN may be connected to the Internet via a 802.11b WLAN (e.g. user in a shopping mall) and is likely to change its point of attachment very frequently, while an aircraft or a boat may be connected to the Internet via the same satellite link for a couple of hours. Some mobile networks may not move at all or may be kept in some sort of home network for a large amount of time In case mobile networks are access networks providing Internet access, IP devices carried by people (laptop, camera, mobile phone, etc) would get access to the Internet via the mobile network they are located in. In some cases, PANs may also be carried in the mobile network, in which case there are mobile networks visiting a larger mobile network. There is thus a need to achieve two levels of mobility: node mobility and network mobility. As people would by definition move from bus to train, thus from a mobile network to another, mobile nodes and mobile networks belonging to potentially different administrative domains would get attached to a mobile network. Since cases of mobile networks suck like trains, cars, aircrafts are themselves most likely to cross country boundaries, they are to move between topologically distant parts of the Internet thus between ISP boundaries. A mobile network may attach to very distant parts of the Internet topology, provided it is granted access to it. In this situation, an Internet-wide mobility scheme, providing both intra-domain and inter-domain mobility, would be requested. The train example is particularly interesting because it shows we need to consider potentially large mobile networks containing hundreds of hosts and several routers. Since each mobile network node (MNN) may be communicating with a few correspondent nodes (CNs), the total number of CNs could be several times as large as Ernst Expires May 2003 [Page 4] INTERNET-DRAFT Network Mobility Support Requirements February 2002 the number of MNNs and scale up to a few thousands. Not to say, a single server deployed in a vehicle may itself have thousands of CNs, or even more. Moreover, whatever the situation, CNs are also most likely to be sparsely distributed in the Internet. From the above scenarios, at least the following configurations of mobile networks seem to be desirable: - mobile networks of any size, ranging from a sole subnet with a few IP devices to a collection of subnets with hundreds of IP devices. - mobile networks with a potentially large number of correspondent nodes, sparsely distributed in different administrative domains, - simultaneous access to the Internet provided via distinct (likely wireless), - distinct cases of mobile networks moving with distinct mobility frequencies, - mobile networks displaced within a domain boundary (intra-domain mobility) or between domain boundaries (inter-domain mobility), - foreign mobile nodes that attach to the mobile network, - nodes that change their point of attachment within the mobile network, - nested mobile networks 2.2. Observations and Constraints In order to drive the discussion on the requirements, this section lists a number of observations that may constraint or limit the deployment of a solution which looks potentially good on the paper. O1: Structure of the mobile network A MR changing its point of attachment does not **cause** the MNNs behind the MR to change their own physical point of attachment. MNNs MAY appear to move from the point of view of an observer in the Internet, but their point of attachment in the mobile network is not modified as a **result** of the mobile network changing its own point of attachment. In most cases, the internal structure of the mobile network will in effect be relatively stable (no dynamic change of the topology), but this is not a general assumption (see Ernst Expires May 2003 [Page 5] INTERNET-DRAFT Network Mobility Support Requirements February 2002 section "Ad-hoc networks") O2: Mobile Router is a transit point All packets sent between MNNs and a CN outside the mobile network necessarily transit through one of the MRs of the mobile network. In the case of nested mobility, packets transit through the root- NEMO, thus through one of the TLMRs. O3: Dog-leg Routing As a result of mobility, routing between a CN in the global Internet and a mobile node may not be optimal. Packets usually transit via the home link of the mobile node if no routing optimization is explicitly performed. In network mobility, multiple dog-leg routing may be introduced by nested mobility. In this case, packets intended to a VMN may first transit by the VMN's home link, then being rerouted to the MR's home link. Non-optimal routing increases bandwidth consumption and transmission delays. The amount of traffic intended for the mobile network is understandably more significant than in the case of a single mobile node (see section "scalability"), then non-optimal routing is to be considered with more care than for host mobility support. However, efficient routing is usually performed at the expense of increased signaling. Thus, the gain of optimal routing has to be balanced against the incurred signaling cost. O4: Ad-Hoc Network A mobile network as defined in the IETF NEMO Working Group is not to be confused with an Ad-hoc network as defined in the IETF MANET Working Group. In the MANET WG, an ad-hoc network is an autonomous system made of mobile nodes (i.e. routers) connected by wireless links. The routers are free to move randomly and to organize themselves arbitrary. Topologies are highly dynamic and there is no fixed infrastructure. Solutions produced by the MANET WG aim at maintaining routes between highly dynamic nodes. The MANET WG is also considering how to provide Internet access to the mobile nodes in the ad-hoc network, but the gateway between the ad-hoc network and the Internet does not change its point of attachment, so the MANET WG is not concerned with the mobility management of an entire network changing its point of attachment. In the NEMO WG, some routers may effectively move arbitrary, but this is not a common case. NEMO aims at providing Internet Ernst Expires May 2003 [Page 6] INTERNET-DRAFT Network Mobility Support Requirements February 2002 reachability to nodes in the mobile network and at maintaining session continuity after the mobile network has changed its point of attachment in the topology. Thus, the NEMO WG and the MANET WG do not have the same objectives. However, an Ad-hoc network which gateways to the Internet would change their point of attachment is likely to be considered as a special instance of a mobile network and would thus rely on NEMO solutions to manage the change of the point of attachment, while routing within the mobile network is only to be considered by MANET. O5: Scalability Scalability has always been considered in the design of new protocols. This particularly includes signaling load and memory consumption which must thus be minimized. For single hosts, host mobility support had to take into consideration a growing number of mobile hosts and should even assume that a major part of the nodes composing the Internet would be mobile in the near future. Thus, it has to scale to an important number of mobile nodes. The scalability parameters in NEMO support differ from host mobility. NEMO support has to scale to: o a large number of mobile networks (e.g. each vehicle, each person carrying a PAN) o a large mobile networks comprising several subnetworks and a large number of MNNs on each subnetwork (e.g. a train) o the number of CNs, which is somewhat a function of the size of the mobile network; the more MNNs a mobile network has, the more CNs the mobile network is most likely to have. (e.g. each MNN in a train communicating with a few CNs) O6: Deployment and Backward Compatibility In IPv4, minimizing the impact on the already deployed infrastructure was an important issue since it was not possible to require all hosts to implement new features. On the other hand, in IPv6, an important number of specifications has for sure already been defined, but IPv6 deployment is only dawning, so, it's theoretically still possible to impose new capabilities on all hosts. However, it is not desirable. The rule of thumb for any new protocol is to make use of the existing ones whenever Ernst Expires May 2003 [Page 7] INTERNET-DRAFT Network Mobility Support Requirements February 2002 possible, to require no changes on them, and to impose extensions only when necessary. The solution for NEMO support must thus be backward compatible with all existing IPv6 standards. If necessary, it will have to provide the necessary extensions to maintain backward compatibility with existing protocols. So, for instance: o Mobile IPv6: host mobility support in IPv6 is achieved by Mobile IPv6. NEMO support MUST not prevent the proper operation of Mobile IPv6. o IGMP (Mutlticast group membership): any IPv6 router is supposed to allow hosts on its attached subnetworks to participate in multicast sessions. Group membership is gathered by the IGMP protocol. It is also desirable to minimize infrastructure installation costs and complexity. So, the solution cannot be orthogonally different. O7: Routers in the Mobile Network All routers in the Internet are considered to run a number of protocols such as a routing protocol, Neighbor Discovery, ICMP, and others. This seems also to apply to routers deployed in mobile networks, but we have to figure out to what extend, and how. O8: Addressing Constraints The IP address is used for routing and to identify the subnetwork where an interface is attached to. Each interface on a subnetwork must therefore be configured with the network prefix of that subnetwork. 3. High Level Requirements This section details a number of high level requirements that should be met by the solutions. 3.1. Migration Transparency In order to provide migration transparency, a permanent and continuous Internet connectivity must be provided to all MNNs, without disruption of service. MNNs must always be reachable regardless of the point of attachment of the MR, and sessions must be maintained after the MR has changed its point of attachment. Ernst Expires May 2003 [Page 8] INTERNET-DRAFT Network Mobility Support Requirements February 2002 3.2. Operational Transparency In order to be transparent to the applications and the users, NEMO support must be performed at the network layer. 3.3. Performance Transparency (Seamless Mobility) NEMO support SHOULD exhibit low latency, incur little or no data loss, minimum delays, minimum signaling load, and minimum bandwidth consumption for packet delivery. It should be performed as seamlessly as host mobility is supported (no abrupt degradation of service). 3.4. Layers Independence Handover of IP sessions is performed at the network layer. With respect to the layer separation of the Internet protocol suite, handover MUST be managed at the network layer only and transparently to upper layers, despite the migration of the mobile network in the network topology. Therefore, a change of topological location MUST not have an impact on layers above the network layer other than a transient loss of performance, as depicted in the above paragraph. If this is respected, compatibility with existing transport and application layers is maintained. In practice, the identifiers used at the transport layer should be independent from the physical IP addresses used at the network layer for routing. If upper layer protocols require a location independent and invariant identifier, the network layer MUST provide it with an identifier irrespective of the actual topological location. 3.5. NEMO Support Transparency for MNNs In section "observation O1", we have seen that "MNNs don't change their own point of attachment as a result of the mobile network's displacement in the Internet topology. NEMO support SHOULD therefore be performed transparently to MNNs and keep them away from participating in NEMO support. Although MNNs may encounter variable delays of transmission and loss with their respective CNs as the network is moving. This is not considered a lack of transparency. However, receiving movement information may be useful to hosts able to understand it, so this could be allowed as an option, and LMNs and VMNs, which are able to change their own point of attachment must manage their own mobility. 3.7. Minimum Signaling Overload Mobility management is usually performed at the cost of control Ernst Expires May 2003 [Page 9] INTERNET-DRAFT Network Mobility Support Requirements February 2002 traffic. In order to be scalable, NEMO support MUST minimize this control traffic. 3.12. No impact on CN or Internet routing Session continuity between a MNN and arbitrary CNs anywhere in the Internet SHOULD NOT assume any changes to existing CNs or the Internet routing architecture. On the other hand, optimizations for performance enhancement MAY involve some changes to CNs, provided that such optimizations would not cause any disruption to ongoing sessions, if not supported by CNs (i.e. backward compatible). [THIS IS TO BE DISCUSSED (in light of the observation made in section "Minimum Impact on the Existing Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED]. 3.13. Security NEMO support must comply with usual IPv6 security policies and standardized protocols. In addition, and unlike fixed nodes, MNNs are more exposed to security threats, particularly identity usurpation. NEMO support must provide MNNs and their CNs with at least as good security as for fixed nodes and mobile hosts. It particularly shouldn't leave more room for intruders to usurp an identify nor to perpetrate any kind of attack against the MNNs nor the CNs. In practice, all control messages required by NEMO support must be exchanged in a secure manner and must ensure the following: 3.13.1. Confidentiality All control messages transmitted in the network MUST ensure MNNs' confidentiality. Only the recipient of the control message may be able to decrypt the content of the datagram. 3.13.2. Authentication All control messages MUST be authenticated by recipients in order to prevent intruders to usurp the identity of a MNN. 3.13.3. Authorization The recipient of a control message MUST ensure that the sender is effectively authorized to perform the mobility support operation indicated in the control message. 3.13.4. Location Privacy Ernst Expires May 2003 [Page 10] INTERNET-DRAFT Network Mobility Support Requirements February 2002 NEMO support may provide means for MNNs to hide their location to any third party. It shouldn't be possible to determine the succession of topological location of a mobile network or a particular MNN by monitoring the exchange of control messages. In practice, MNNs may wish to hide their location to some or all of their CNs, or anyone else but the CNs. It may also be desirable to hide the location of the entire mobile network to all CNs without discrimination between MNNs. 3.14. Access Control 3.14.1. Access Control for VMNs Mobile Networks MUST be able to authenticate and authorize VMNs to gain access to the Internet via the mobile network infrastructure (MRs). 3.14.2. Access Control Architecture To be able to comply with the current access control mechanisms and achieve a scalable solution, the final solution MUST NOT assume that the fixed network would authenticate VMNs. VMN authentication and authorization MUST be the responsibility of the mobile network. 3.14.3. Access Control in the Fixed Network AAA solutions MUST allow for authenticating an entire network. This MAY simply be done by ensuring that the Authentication and Authorization is not necessarily performed for a single IP address. This is particularly important for IPv6 as each node may configure multiple addresses. 3.15. Internet-wide mobility In order to ensure permanent and uninterrupted Internet-wide mobility, mobile network should be able to roam between access networks belonging to distinct ISPs and corporate networks (distinct administrative domains, i.e. inter-domain mobility) and via any available access technology (distinct technologies:802.11b WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous mobility). Indeed, nothing but administrative and security policies should prevent a mobile network to attach anywhere in the Internet topology. So, the solution must technically allow this kind of scenario. In addition, NEMO support must also accommodate to CNs deployed in distinct administrative domains. 3.16. Unified Solution Ernst Expires May 2003 [Page 11] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Should different schemes be proposed, a unified mobility support scheme is required. A situation where distinct NEMO support schemes are deployed and unable to inter-operate with each other must be avoided. 3.17. Mobile CNs NEMO support MUST be optimized to handle the case where the CN is MIPv6-enabled and/or itself located in a mobile network (particularly if it is a VMN). It must perform efficiently in both cases. 4. Requirements for Basic Support In this section, the high-level requirements are refined in a more explicit manner for basic support. This list is not exhaustive and should be combined with the requirements found in the other drafts. Requirements follow from our observations and high-level requirements in section 2 and 3. Basic support is to maintain session continuity between nodes in the mobile network and nodes in the global Internet. The solution will have to meet the following requirements [TO BE DISCUSSED ON THE LIST - THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR GRANTED]: R1: The solution MUST provide permanent Internet connectivity and reachability to all nodes behind the MR R2: The solution MUST maintain continuous sessions between nodes behind the MR and arbitrary CNs after IP handover of the MR R3: All the potential configurations MUST be treated the same way (any number of subnets and MNN, nested mobile networks, multihomed mobile networks) R4: The solution MUST support LFNs, VMNs, and LMNs. R5: CNs and MNNs must comply with the requirements for IPv6 nodes defined in [IPv6-NODE] R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to MNNs) R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) R8: A VMN that gets attached to a link within the mobile network Ernst Expires May 2003 [Page 12] INTERNET-DRAFT Network Mobility Support Requirements February 2002 obtains an address on that link. R9: The solution MUST support nested mobile networks with any number of mobility levels R10: The solution MUST support multi-homed mobile network R10.1 : The solution MUST support mobile networks with multiple MRs R10.2: The solution MUST support MR with multiple interfaces R11: The solution MUST NOT prevent the use of existing protocols R11.1: The solution MUST allow MNNs to operate the "CN functionality" of Mobile IPv6 R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs R11:3: The solution will ensure that mechanisms related to multi-homing (defined within other WGs in IETF) will be useful for NEMO" R12: The solution MUST support a large number of mobile networks R12: The solution MUST support a large number of CNs R13: The solution MUST support vertical handoff R14: The solution MUST support horizontal handoff R15: The solution SHOULD support fast handoff R16: The solution MUST support inter-domain mobility R17: The solution MUST support heterogeneous mobility R18: The solution MUST minimize control traffic 5. Requirements for Extended Support In this section, the high-level requirements are refined in a more explicit manner for extended support. This list is not exhaustive and should be combined with the requirements found in the other drafts. Ernst Expires May 2003 [Page 13] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Extended support is to optimize routing between CNs and arbitrary MNNs and must support the following requirements (non exhaustive list, to be completed later) R1: The solution for Extended support must seat on top of Basic support. This means it must comply with the requirements defined under "Basic support" and co-exist with it without disturbing it or any of the nodes that do not need/understand it. R2: MNNs and CNs MAY be NEMO-enabled as a means to improve routing. As such be notified and take action upon the change of point of attachment of the MR. R3: The solution must preserve route aggregation in the Internet R4: The solution must minimize control traffic. RXXXX: To be continued. Many more to be added later. Ernst Expires May 2003 [Page 14] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Acknowledgments The material presented in this document takes most of the text from our former internet-drafts submitted to MobileIP WG and to the former MONET BOF, co-authored with Hong-Yon Lach, which where themselves based on original text from [Ernst01]. The author would therefore like to thank both Motorola Labs Paris and INRIA (PLANETE team, Grenoble, France), for the opportunity to bring this topic to the IETF since 2000, and particularly Hong-Yon Lach (Motorola) and Claude Castelluccia (INRIA) for their advices, suggestions, and direction. We also acknowledge the contribution from Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Hesham Soliman (Ericsson), Mattias Petterson (Ericsson) and Keisuke Uehara (Keio University). We are grateful to people in the InternetCAR team (Keio University) and all the people on the NEMO (formerly MONET) mailing list for their comments and suggestions on the NEMO ML which helped to improve this draft (Greg Daley, Pascal Thubert, James Kempf, TJ Kniveton, and other we may have forgot to include here) References [Bhagwat96] P. Bhagwat, S. Tripathi, and C. Perkins. "Network Layer Mobility: an Architecture and Survey" IEEE Personal Communications, 3(3):54, June 1996. [Caceres96] R. Caceres and V.N. Padmanabhan. "Fast and scalable handoffs for wireles internetworks" In Proc. of the Second ACM/IEEE MOBICOM, New-York, USA, November 1996. [Castelluccia98] Claude Castelluccia. "A Hierarchical Mobility Management Scheme for IPv6. Third Symposium on Computers and Communications (ISCC'98), Athens, Greece, June 1998. http://www.inrialpes.fr/planete [Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier Grenoble, France. October 2001. http://www.inria.fr/rrrt/tu-0714.html [IPv6-NODE] John Loughney "IPv6 Node Requirements" draft-ietf-ipv6-node-requirements-01.txt July 2002, Work in progress. Ernst Expires May 2003 [Page 15] INTERNET-DRAFT Network Mobility Support Requirements February 2002 [MIPv6] David B. Johnson and C. Perkins. "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-18.txt, July 2002. Work in progress. [Myles93] Andrew Myles and David Skellern. "Comparing Four IP Based Mobile Host Protocols" In Joint- European Networking Conference. Macquarie University, Sydney, Australia, May 1993. [PSBU] T. Ernst et al. "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)" draft-ernst-mobileip-v6-network-03.txt, March 2002. Work in progress [RFC1122] R. Braden (editor). "Requirements for Internet Hosts - Communication Layers". IETF RFC 1122, October 1989. [RFC2460] S. Deering and R. Hinden. "Internet Protocol Version 6 (IPv6) Specification" IETF RFC 2460, December 1998. [REQUIREMENTS-1] Hesham Soliman "Problem Scope", Internet-Draft draft-soliman-monet-scope-00.txt, February 2002. Expired [REQUIREMENTS-2] H.-Y. Lach, C. Janneteau, A. Petrescu "Mobile Network Scenarios, Scope and Requirements", draft-lach-nemo-requirements-00.txt, October 2002. [REQUIREMENTS-3] T.J. Kniveton, A. Yegin "Problem Scope and Requirements for Mobile Networks Working Group" draft-kniveton-monet-requirements.txt, February 2002. Expired [REQUIREMENTS-4] C. W. Ng, and T. Tanaka "Usage Scenario and Requirements for AAA in Network Mobility Support" draft-ng-nemo-aaa-use-00.txt October 2002. Work in progress [TERMINOLOGY] Thierry Ernst and Hong-Yon Lach "Terminology for Network Mobility Support", Ernst Expires May 2003 [Page 16] INTERNET-DRAFT Network Mobility Support Requirements February 2002 draft-ernst-nemo-terminology-00.txt, October 2002. Work in progress. Author's Addresses Questions about this document can be directed to the authors: Thierry Ernst, WIDE Project and INRIA Jun Murai lab. Faculty of Environmental Information, Keio University. 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ Ernst Expires May 2003 [Page 17]