Network Mobility Working Group Behcet Sarikaya Internet Draft Alcatel USA Document:draft-sarikaya-nemo-archreqs-00.txt Category: Informational October 2002 Architectural Requirements for Base Network Mobility Using Bidirectional Tunneling draft-sarikaya-nemo-archreqs-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. Distribution of this memo is unlimited. Abstract While traditional mobility support deals with providing continuous Internet connectivity to mobile hosts (host mobility support), network mobility support means dealing with situations where an entire network changes its point of attachment to the Internet. Such a network is called a mobile network. This document identifies architectural entities of network mobility and nested network mobility. Sarikaya 1 Architectural Requirements for Basic NEMO October 2002 Table of Contents Status of this Memo..................................... .........1 Abstract................................................. ........1 Table of Contents........................................ ........2 1. Introduction..................................... ......... ...3 2. Architecture ...... ...... ...... .................... ........3 2.1 Generic Architecture .........................................3 2.2 Mobile IPv4 Considerations ...................................6 3. Security Considerations........................................7 4. References.............................................. ......7 5. Authors' Addresses....................... . ..................8 Sarikaya Expires March 2003 2 Architectural Requirements for Basic NEMO October 2002 1. Introduction This document assumes that the reader is familiar with the terminology defined in [1] and problem description in [2] and Mobile IPv4 based description in Section 4.5 of [3]. The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts (host mobility support). In contrast, network mobility support is concerned with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. We shall refer to such a network as a mobile network. Cases of mobile networks include networks attached to people (Personal Area Networks or PAN), and networks of sensors deployed in aircrafts, boats, busses, cars, train, etc that need a permanent Internet connection. Those mobile networks may also provide Internet access to devices carried by people (laptop, camera, mobile phone, etc, and PAN). There is a desire to achieve two levels of mobility: node mobility and network mobility. A passenger is a mobile node which visits a mobile network (VMN in a NEMO), and passengers may themselves be mobile IP-subnets (NEMO in a NEMO), for example when carrying a PAN. Since people move from a NEMO to another, and since instances of NEMOs like trains, car, aircrafts cross country boundaries, both VMNs and NEMOs are also most likely to cross ISP boundaries and therefore to move between topologically distant parts of the Internet. This means we must allow VMNs belonging to potentially different administrative domains to visit the NEMO. These instances also justify the need to consider potentially large NEMOs containing hundreds of hosts and several routers. The train example highlights that the number of correspondent nodes could also be very large, and that these may be sparsely distributed in the Internet. It also justifies the need for true worldwide mobility in the Internet. A NEMO may attach to very distant parts of the Internet topology, provided it is granted access to it, therefore requiring both Local- Area Mobility support and Wide-Area Mobility support. The document continues in Section 2 with general requirements on architecture. 2. Architecture 2.1 Generic architecture A new architectural entity called mobile router (MR) is needed to support network mobility. The mobile router (MR) connects the mobile network to the home link. In order to provide session continuity to the nodes in its network, MR needs a Mobile IP Home Agent (HA) [4]. MR may have several internal links to which local fixed (LFN) and mobile (LMN) nodes are connected (Figure 1). MR and HA together provide support for network mobility. HA MUST know that MR is not a basic mobile node but a router. Sarikaya Expires March 2003 3 Architectural Requirements for Basic NEMO October 2002 +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ | | Access | | | | | AR | Router | AR | | HA | | | | | | | +----+ +----+ +----+ foreign | link | home link | ------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | | +----+ | | internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 1. A Mobile Network at its Home Link MR has an egress interface to its home link. MR MAY have several ingress interfaces to its internal links. The mobile network MAY move in its entirety and MAY attach itself to another link, e.g. foreign link. This situation is shown in Figure 2. MR MUST provide session continuity to all the nodes in its network. The correspondent node (CN) MAY be communicating with a mobile node (LMN) or with a fixed node (LFN). Base network mobility support MUST not require any changes to the correspondent nodes. Sarikaya Expires March 2003 4 Architectural Requirements for Basic NEMO October 2002 +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ | | Access | | | HA | | AR | Router | AR | | | | | | | | | +----+ +----+ +----+ foreign | link |home link | --------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | | +----+ | | internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 2. Mobile Network at a Foreign Link A mobile router becomes the visiting mobile router (VMR) if it connects to another network in mobility. This is called nested mobility. An architecture for nested mobility is shown in Figure 3. A visiting mobile router (VMR) connects itself to the network in mobility by attaching to one of the links, e.g. local link 2. The visiting network in mobility may have its own links to which several fixed and mobile nodes are connected. HA1 is the home agent for MR and HA2 is for VMR. Sarikaya Expires March 2003 5 Architectural Requirements for Basic NEMO October 2002 +----+ | | | CN | | | +----+ | +----+ +------------------------+ | HA | | | | 2| | | +----+ | Internet | | | | ------>| | +------------------------+ | | +----+ +----+ +----+ | | Access | | | | | AR | Router | AR | | HA | | | | | | 1| +----+ +----+ +----+ foreign | link |home link | ------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | +---+ | +----+ |LFN| | | | internal link 1 | |----| +---+ | -------------------- +---+ |-|VMR|-| | | | +---+ + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 3. Nested Mobility 2.2 Mobile IPv4 Considerations In Mobile IPv4, LMNs as well as MR MAY have a Foreign Agent (FA). The FA for LMNs MUST be on the internal link(s). MR MAY act as a FA to LMNs only if one of MRÆs interfaces directly connect to the internal links in the mobile network. Figure 4 shows the use of Mobile IPv4 when the network in mobility is on a foreign link. MR uses a local FA as its foreign agent while serving as FA to LMNs on the links attached to its interfaces. Sarikaya Expires March 2003 6 Architectural Requirements for Basic NEMO October 2002 +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ +----+ | | | | Access | | | | | FA | | AR | Router | AR | | HA | | mr| | | | | | | +----+ +----+ +----+ +----+ | foreign | link |home link | --------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--|(FA)| | +----+ | |internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 4. Network mobility and Mobile IPv4 3. Security Considerations To be addressed in a separate draft. 4. References 1 Thierry Ernst, Hong-Yon Lach, "Network Mobility Support Terminology ", draft-ernst-nemo-terminology-00.txt, October 2002, Work in progress. 2 Hesham Soliman "Problem Scope" IETF internet-draft draft-soliman- nemo-scope-00.txt, October 2002, Work in progress. 3 Charlie Perkins, "IP Mobility Support for IPv4", IETF RFC 3344, August 2002. Sarikaya Expires March 2003 7 Architectural Requirements for Basic NEMO October 2002 4 David Johnson, Charlie E. Perkins, Jari Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-19.txt, work in progress, October 2002. 5. Author's Addresses The working group can be contacted via the current chairs: Thierry Ernst, WIDE Project 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/ Timothy J. Kniveton Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1 650 625-2025 Fax: +1 650 625-2502 EMail: Timothy.Kniveton@Nokia.com Questions about this memo can also be directed to: Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Rd. Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477-2794 Fax: (972) 519-2460 Sarikaya Expires March 2003 8