Ivancic W. Ivancic Internet Draft NASA Expires: March 2007 September 18, 2006 Multi-Domained, Multi-Homed Mobile Networks draft-ivancic-mobile-platforms-problem-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 This Internet-Draft will expire on March 18, . Abstract This document describes numerous problems associated with deployment of multi-homed mobile platforms consisting of multiple networks and traversing large geographical areas. The purpose of this document is to provide insight to real-world deployment issues and provide information to working groups that are addressing many issues related to multi-homing, policy-base routing, route optimization and mobile security. Ivancic Expires March 18, 2007 [Page 1] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 Conventions used in this document 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 Error! Reference source not found.RFC2119]. Table of Contents 1. Introduction...................................................2 2. Mobility solution space........................................4 2.1. Host-based Solutions......................................4 2.2. Radio-link layer mobility.................................5 2.3. Transport layer mobility..................................5 2.4. Routing Protocols for Mobile Networks.....................5 2.5. NEtworks in MOtion (NEMO).................................9 3. Policy-based routing..........................................10 4. Radio Operations..............................................13 4.1. Layer-2 Triggers.........................................13 4.2. Multiplexing Links.......................................14 4.2.1. Multiplexing at the Radio...........................14 4.2.2. Multiplexing at the Router..........................15 5. Network Access (auto-login)...................................16 5.1. Cellular Access..........................................16 5.2. Satellite Access.........................................17 5.3. WiFi Access..............................................17 6. Costs.........................................................17 7. Security Considerations.......................................18 8. IANA Considerations...........................................18 9. Acknowledgments...............................................18 10. References...................................................20 10.1. Normative References....................................20 10.2. Informative References..................................21 Author's Addresses...............................................21 Intellectual Property Statement..................................21 Disclaimer of Validity...........................................22 Copyright Statement..............................................22 Acknowledgment...................................................22 1. Introduction The purpose of this document is to provide insight to real-world deployment issues and provide information to working groups that are addressing many issues related to multi-homing, policy-based routing, route optimization and mobile security. Ivancic Expires March 18, 2007 [Page 2] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 This document describes numerous problems associated with deployment of multi-homed, mobile platforms consisting of multiple networks in multiple domains and traversing large geographical areas. These multi-networked, multi-homed, multi-domained mobile networks are often large platforms such as planes, trains, or ships and even automobiles and spacecraft. One key characteristic that separates them from general "networks in motion" (NEMOs) is that these platforms have multiple networks that are generally owned and operated by different parties (domains). Because of the various network domains, policy-based routing and security have some different issues and concerns relative to single-domained systems. Three examples of multi-domained, multi-networked systems include: defense systems, aeronautics systems and space systems. In all of these systems there are critical control systems that reside in a particular network that requires highly reliable links and time- critical information, but limited bandwidth. We shall call this network the "command and control" domain. A second network may be present for operations and maintenance. This "operations and maintenance" domain requires little bandwidth. In addition, information is not as time-critical and reliability is relaxed. The third network is the "user domain". This network generally requires much more bandwidth than does command and control network or operations and maintenance. However, this network, to date, is generally not required to have data reach its destination within a guaranteed time. In the aeronautical industry, all critical air traffic control (ATC) is performed via a closed network. Currently the air/ground link is not Internet-based, but this is expected to change in the future. All ATC traffic is time-critical and the links must be highly reliable. However, these links require relatively little bandwidth in the order of 10s of kilobits per second. This domain, to date, has been a closed network with all infrastructure effectively owned or controlled by the civil air authorities. In the United States of America, this civil air authority is the Federal Aviation Administration (FAA). The second domain is the used for aircraft operations and maintenance and is call the airline operational communications (AOC) network. Information that may run on this network includes passenger lists, aircraft fuel and weight and other operations and maintenance information. This link is not as safety critical and the information carried over this link is generally not time-critical. Like the ATC domain, the AOC domain is closed although traditionally it has resided within the same closed network as ATC. Ivancic Expires March 18, 2007 [Page 3] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 The third domain is the passenger domain. This domain is used for in-flight entertainment (IFE) services and communication. To date, the IFE network has not been allowed to carry any time critical ATC communications. This policy is in place in part for security and in part because the IFE network has not been specified and certified to the same time-critical information transfer and reliability as the ATC network. However that does not imply that the IFE network could not meet those requirements. A second example of multi-domained, multi-networked systems is the deployment of Internet technologies for the United States National Aeronautics and Space Administration (NASA) space program. Three domains of interest for a spacecraft are: ground operations located in Florida; mission control located in Texas; and the general science community. Both ground operations and mission control require reliable, time-critical commanding but do not require large amounts of bandwidth - assuming video in sent on its own links. The user network (scientific community) has greatly relaxed reliability requirements and does not require time-critical information. However, this network is expected to transport large volumes of data. Each of these networks is effectively owned and operated by a different community of interest on different domains. Other multi-domained, multi-networked systems might be found in military operations, the global shipping industry, taxi and limousine services, and perhaps even in the general automotive industry. 2. Mobility solution space Mobility here is the ability to move between radio systems and networks without having to reestablish session. Mobility can be performed as a host-based or network based solution. Mobility can also be performed at various layers including the radio-link, transport and network layers. Two network layer technologies are applicable include routing protocols or mobile-ip based solutions such as NEMO. 2.1. Host-based Solutions Host-based solutions include: SCTP [RFC3286] at the transport layer, HIP [RFC4423] as a shim between the network and transport layers and mobile-ip at the network layer [RFC3344] [RFC3775]. A major problem with host-based where a large number of hosts are sharing the same low-rate radio link is that a binding update storm will occur when a network is traversed. All hosts have to inform all of their corresponding nodes as well as their location managers (e.g. home agent for mobile-ip, DNS or some other location manager for SCTP, and Ivancic Expires March 18, 2007 [Page 4] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 rendezvous servers for HIP) when their location has changed. This can saturate the RF link. Thus host-based solutions have a scalability problem for this situation. 2.2. Radio-link layer mobility Radio-link layer mobility is currently deployed in cellular systems and work effectively over relatively large geographical areas (i.e. countries and continents). Use of radio-link handoffs for mobility provides a partial solution over a limited space. Radio-link layer handoffs only solve mobility problems for a single link. It does not address multihoming nor is it scalable over extremely large geographic areas (i.e. globally). Since multiple providers, possibly with multiple access link technologies, are usually required for global connectivity, link-layer mobility solutions alone are not feasible for global mobility. 2.3. Transport layer mobility Transport layer mobility using Stream Control Transport Protocol (SCTP) provides route optimization and potentially could provide good convergence times. As with any non-routing protocol, transport layer mobility requires some sort of location manager to enable a corresponding node to initiate communications. The location manager is used by the mobile node to register its current location. Use of Domain Name Servers (DNS) has been shown to functionally perform this function using "do not cache" options. However, the reliability and convergence time for updating the DNS has not been proven operationally as often times the "do not cache" option is ignored [Pan2004]. SCTP-based transport layer mobility and has been implemented as a host-based solution. This solution currently is not applicable for large mobile networks. However, research is being performed to use one-to-one address translation to provide network-based SCTP whereby one host acts and an SCTP proxy for all hosts behind it performing SCTP for all hosts behind it. Conceptually this effectively performs transport-layer mobile routing. However, even if SCTP can be adapted to handle many nodes, binding update storms may still be a problem. 2.4. Routing Protocols for Mobile Networks Routing protocols provide route optimization as that is their job. There are a number of problems with using routing protocols to solve the multi-domained, multi-homed mobile network problem including: convergence time, inability to share network infrastructure, Ivancic Expires March 18, 2007 [Page 5] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 addressing, scalability and the applicability of some routing protocols for particular applications. Figures 1 and 2 illustrate some of the major issues with using routing protocols for mobile networks. Figure 1 shows how the current International Organization for Standardization (ISO) standards based Aeronautical Telecommunication Network (ATN) as specified by the International Civil Aviation Organization (ICAO). Figure 2 shows a conceptual migration to use of internet protocols (IP) to perform the same function. O---------O O---------O |Mobile RD| |Mobile RD| O------+--O O----+----O \ / .--+--------------------------+-------. | `--+ ATN Backbone / | | +-+-.------------------+----+ | | | ,-`---. ,--+--. | | | | (ATN TRD)-------(ATN TRD) | | | | `---+-' `---+-' | | O---------O | +-----+----------------:----+ | |Mobile RD|-+. / \ | O---------O | `-. ,-+---. \ | | `-ATN TRD--. .----+--. | | `--+--' `--------|ATN ERD| | | ; `-------' | | / | | / | | .---+---. | | |ATN ER | ATN Island RDC | | `-------' | `-------------------------------------' ERD - End Routing Domain RD - Routing Domain RDC - Routing Domain Confederation TRD - Transit Routing Domain Figure 1 Aeronautical Telecommunication Network Island Ivancic Expires March 18, 2007 [Page 6] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 Air | Ground | | | +--------+ | )-|BGP/OSPF|\ +----+ | +--------+ `. .------. |BPG |-( | \| OSPF | +----+ | /|AREA 1|`. Mobile-1 | +--------+ .' `------' `. | )-|BGP/OSPF|/ `. | +--------+ .------. +----+ | | OSPF | |BPG |-( | |AREA 0| +----+ | +--------+ `------' Mobile-2 | )-|BGP/OSPF|`. .' | +--------+ \ .------. / | `.| OSPF | .' | .'|AREA N|' +----+ | +--------+ / `------' |BPG |-( | )-|BGP/OSPF|.' +----+ | +--------+ Mobile-N | | Figure 2 Internet Protocol Based Aeronautical Network For mobile networks that require time-critical command and control, fast convergence time is essential. Take, for example, the ATC problem with aircraft takeoff and landing. This is the most crucial portion of a flight. One cannot wait 30 to 90 seconds or a few minutes for routes to converge. The same is true for a spacecraft during launch when it is passing numerous ground stations in a short time. In order to control the convergence time in aeronautical networks, the ISO Inter Domain Routing Protocol (IDRP) is used [ISO10747]. To further improve convergence time, the network is constructed as a highly controlled two tier architecture consisting of transit routing domains and backbone interconnectivity. The concept is that route propagation will occur quickly in the transit- domain where information is time-critical [Sig1998]. Route propagation to geographically distant areas will occur over the backbone where route propagation is not time-critical [Figure 1]. In the IP implementation of figure 2, BPG-4 [RFC4271] is seen as an external route to the OSPF network [RFC2328]. Since the aeronautics network is relatively small and currently a closed network operated Ivancic Expires March 18, 2007 [Page 7] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 jointly by various civil aviation authorities, OSPF can be used globally. When a BGP route is advertised to the OSPF network, the OSPF network will immediately propagate the route into the nearest OSPF area thereby provide good convergence time locally where it matters most [Iva2006]. In figures 1 and 2, IDRP and BGP are also used to provide policy- based routing capability. This is of interest and a current requirement for the aeronautics community in order to have time- critical command and control flow through one link while other traffic such as air operations flows through another. Although this requirement has existed within the ICOA ATN specification from the beginning [ICAO9739] [ICAO9705], its use has seen limited deployment to date and is operationally untested for the following reasons: there currently are not enough ATN users to tax the system; system deployment is minimal; and, the airlines generally only have one link active for cost reasons. For example, satellite links are not turned on unless needed due to the high cost. Furthermore, two simultaneous VHF radios are not active simultaneously. When using BGP or other routing protocols for mobility, additional problems arise due to addressing. Routing protocols generally assume the interface connections on the routers are not dynamically changing. Thus, two routes connected are assumed to be on the same subnet. One may be able to use "un-numbered" serial interfaces to alleviate this problem, but to date, this has not been proven to work. Thus, all mobile platforms must reside in the same network or sub-network. It may be possible to achieve this by having the mobile platform obtain its WAN interface address from the ground using PPP, DHCP, or IPv6 auto configuration. Regarding use of an inter-autonomous system protocol such as BGP, scalability issues arise due to the need to configure peering. Each BGP router has to have a configuration for each autonomous system (AS) peer that wishes to communicate with. Thus, each mobile has to have preconfigured for each radio station router it will communicate with. Likewise, each radio station router will have to be preconfigured for each mobile. As the number of ground stations or mobile platforms grows, this quickly becomes unmanageable. As new mobile platforms or ground stations are added, all configurations must be updated. Furthermore, if the mobile platforms have multiple- domains, the question of who is authorized to update systems becomes an issue. Using general routing protocols for mobility make it very difficult to share infrastructure. In order to run routing protocols, one generally has to either own all of the assets or pre-arrange peering Ivancic Expires March 18, 2007 [Page 8] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 agreements. For security reasons, one cannot simple inject routes into another's network. Furthermore, allowing relatively small mobile networks to inject routes that do not conform to some form of route aggregation will result in route table explosion and is therefore not scalable or desirable 2.5. NEtworks in MOtion (NEMO) Networks in Motion (NEMO) protocols have been designed specifically to manage the mobility of an entire network (or networks), which changes, as a unit, its point of attachment to the Internet and thus its reachability in the topology [RFC3963]. NEMO protocols also address multihomed networks which may be either a single mobile router (MR) that has multiple attachments to the internet, or may use multiple MRs that attach the mobile network to the Internet. NEMO protocols, by design, avoid many of the problems associated with using general routing protocols for mobile networks including: convergence time, the need for two communicating routers to reside on the same subnet and the need to pre-configure peering relationships. Mobile-ip based solutions such as NEMO solutions have relatively fast convergence times as mobile-ip based protocols simply redirecting the default-route pointer. However, if one wishes to pass routing protocols down a mobile-ip tunnel, then convergence issues may still exists. NEMO solutions also allow one to easily share. NEMO solutions do not require the mobile to inject routes into another's network. Rather, for each radio link one simply contracts with an Internet Service Provider (ISP) for bandwidth and access. The ISP provides a care-of- address once radio-link access is granted. The user can use the bandwidth however they wish. (Note, this model may change if mobile network users dominate use of the IPS's network. At that point, the cost model may change whereby a mobile network user pays an appropriate usage fee relative to the capacity used.) Two areas that NEMO protocols have yet to mature in are support for route optimization and policy-based routing. Current NEMO support requires a bi-directional tunnel between the mobile router and the home agent. This can result in significant delays when the mobile unit traverses large distances. These distances can be global distances (or beyond for space systems). It is highly desirable to have route optimization at least to the point of being able to bind a mobile node to a geographically closer home Ivancic Expires March 18, 2007 [Page 9] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 agent. Route optimization is expected to be the next area of work being performed by the NEMO working group. Another area of route optimization relative to mobile-ip and NEMO is network-based local mobility management (netlmm). Local mobility involves movements across some administratively and geographically contiguous set of subnets. When a mobile node moves from one access router to another, the access routers send a route update to the mobility anchor point. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the access router about mobile node movement, no specific mobile node to network protocol will be required for localized mobility management itself. Netlmm technology may prove useful for common radio systems owned and operated by a single entity. In the aeronautics community, netlmm may be useful for connecting all of the VHF radios in a given control area. For a space mission, netlmm between tracking ground stations may greatly improve performance for time critical commanding. Past implementations of NEMO IPv4 or IPv6 protocols only allow for binding to one care-of-address. In this situation, a multihomed mobile router can only use one link at a time. It is not capable of using two or more links even if they are available. Use of multiple links simultaneously is desirable for a number of reasons including load balancing and policy-base routing. The problem of policy-base routing is currently being investigated by Mobile Nodes and Multiple Interfaces in IPv6 (monami6) working group. Two topics being investigated that of interest to multi-domained, multi-homed mobile networks are: . A protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) to support the registration of multiple Care-of- Addresses at a given Home Agent address [Wak2006]. . A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address [Sol2006]. 3. Policy-based routing Figures 3 through 6 illustrate the advantages of policy-based routing in a mobile aeronautical network. Consider the mobile network having three links available. One link is classified as highly reliable but relatively low rate. This link is reserved for command and control. The second link is a low-latency, low-bandwidth link. The third link Ivancic Expires March 18, 2007 [Page 10] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 is high-rate for passenger services. Assume it is possible to set policy with the following rules: . Only ATC traffic is allowed to use the reliable link. . Data precedence is set such that ATC is highest priority, AOC is next highest and passenger traffic has lowest priority. . ATC and AOC traffic are allowed to use the low-latency link . ATC, AOC and passenger traffic are allowed to use the high-rate link. . Link preference for ATC is reliable link - highest, low-latency link - middle, high-rate - last. . Link preference for AOC is low-latency followed by high-rate. Figure 3 shows all links active. Figure 4 shows that ATC traffic can be delivered even if all other links are unavailable. Figure 5 shows that ATC and AOC traffic have precedence over passenger traffic and could use the high-rate link if their preferred links are unavailable. Figure 5 is of greatest interest because one could conceivably make this the preferred link for all traffic if safety- of-flight QoS requirements could be met. Doing so would release spectrum to ATC and AOC as many users could be using the high-rate links when available. (For aeronautical communications, RF spectrum is a precious and limited resource.) | | Ivancic Expires March 18, 2007 [Page 11] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 +-+-+ +-+-+ |P-3| |P-3| +-+-+ +-+-+ | | +-+-+ High-Speed Link | +-+-+ |P-2| +---+ +---+ | |P-1 +-+-+ |P-3|============|P-3|=+ +-+-+ | +---+ +---+ | | +-+-+ / | +-+-+ |P-1| / Low Latency Link | .-- --. |P-2 +-+-+ .--+---. +---+ | |Home | +-+-+ +-------|Router|========|P-2|========+-|Agent|-----+ +-+-+ `--.---' +---+ | `-- --' +-+-+ |P-3| `. | |P-3 +-+-+ `. +---+ | +-+-+ | `=|P-1|==============+ | +---+ | Reliable Link | Figure 3 Policy-Based Routing, All Links Active | | +-+-+ | |P-3| | +-+-+ | | | +-+-+ High-Speed Link | |P-2| +---+ \ / | | +-+-+ |P-3|==============+===+ | | +---+ / \ | | +-+-+ / | +-+-+ |P-1| / Low Latency Link | .-----. |P-1| +-+-+ .--+---. +---+ \ / | |Home | +-+-+ +-------|Router|========|P-2|====+===+-|Agent|-----+ +-+-+ `--.---' +---+ / \ | `-----' | |P-3| `. | | +-+-+ `. +---+ | | | `=|P-1|==============| | +---+ | Reliable Link Figure 4 Policy-Based Routing, Critical Link Active Ivancic Expires March 18, 2007 [Page 12] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 | | +-+-+ +-+-+ |P-3| |P-3| +-+-+ +-+-+ | | | +-+-+ High-Speed Link | +-+-+ |P-2| +---+ +---+ +---+ +---+ | |P-3| +-+-+ |P-3|=|P-3|==|P-2|=|P-1|=+ +-+-+ | +---+ +---+ +---+ +---+ | | +-+-+ / | +-+-+ |P-1| / Low Latency Link | .-----. |P-2| +-+-+ .--+---. \ / | |Home | +-+-+ +-------|Router|===========+===========+-|Agent|-----+ +-+-+ `--.---' / \ | `-----' +-+-+ |P-3| `. | |P-1| +-+-+ `. \ / | +-+-+ | `=================+====+ | / \ | Reliable Link | Figure 5 Policy-Based Routing, User Link Active 4. Radio Operations Mobile networks are wireless and may utilize many types of radio systems. It is imperative to understand the interaction between particular radio systems and the routing and transport protocols. For example, the Transmission Control Protocol (TCP) has algorithms to enable it to probe the network for capacity and adjust accordingly. Streaming video or rate-based protocols do not and can easily saturate a link if not properly controlled. Two techniques that can be used to control non-congestion-friendly protocols are policy-base routing and queue management. 4.1. Layer-2 Triggers For low rate (10s of kbps) radio links such as current avionics links some minimal quality-of-service can be accomplished via message prioritization. When link capacity is low there is little need to have a feedback mechanism between the radio and the router to enhance QoS. Current and future high-rate links would benefit greatly by having a standardized feedback mechanism between the radio systems and the router. Such mechanism could indicate if a link is available and the quality and bandwidth of the link. The former is important for fast handovers between links. The latter is of Ivancic Expires March 18, 2007 [Page 13] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 particular importance for bandwidth-on-demand systems. For instance, the Boeing Connexion outbound radio link can operate from approximately 16 kbps up to 1 or 2 Mbps in 16 kbps increments. This rate is continually varying depending on outbound traffic demands and satellite network congestion. Assuming the interface between the router and Connexion radio is an Ethernet connection, some type of layer-2 trigger or feedback to the router is necessary to determine the available data rate. If the interface is serial, having the radio provide the clock may solve the data rate problem. 4.2. Multiplexing Links When building a robust mobile communication system, it is highly desirable to have multiple radio types to ensure communication (e.g. cellular, WiFi, satellite). Each of these radio link technologies operates at different frequencies and has different antenna technologies that must be incorporated into the system design. Radio systems and their associated antenna systems can add significant size, mass and power to communication systems. Thus, although it is highly desirable to have multiple radio systems, there is a practical limit to what can be deployed. One most certainly does not want to have to deploy multiple radios of the same technology. Rather one will multiplex communications over similar radios. 4.2.1. Multiplexing at the Radio Figure 6 illustrates multiplexing communications at the radio link. For each link, all information must be queued and prioritized in the "MUX" box. This is not overly difficult. One of the main problems with multiplexing at the radios is that the MUX box must obtain or be configured for addressing on the various wireless networks. The MUX box must pass this addressing on to the NEMO routers. For example, the MUX on the WiFi network may obtain its Wide Area Network (WAN) address via DHCP. The MUX must now provide addressing to the various NEMO routers attached to the ingress side. Does the WiFi MUX provide different addresses to each NEMO router or the same address? How is this done? One would like this to be a standardized method. One advantage that the architecture in figure 6 provides is physical separation of the NEMOs. Thus, security issues for this architecture may be accomplished using a conventional approach. However, if each NEMO is getting the same WAN address, this is certainly not conventional. Ivancic Expires March 18, 2007 [Page 14] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 +--------+ +---------+..........,-----. ,----------.-'''"""| NEMO-1 | | NEMO-1 |. .( MUX )---| Satellite|\ /| HA | +---------+ \ / `-----' '----------* \ / +--------+ \ `. .' / | \ /,' \ `. / `. X | \' `. `/ ,' / \ / \ /|,'\ +---------+' \| `,-----. ,----------./ `| \+--------+ | NEMO-2 |-----+---( MUX )---| WiFi |..,:...| NEMO-2 | +---------+. /\ .'`-----' '----------*\,'`. | HA | \ / \/ ,' | /+--------+ `. .'\ | \ ;; / X \ ,' X `. / .' `. \ ' ," \ | +---------+ / \ ,-----. ,----------./ \`+--------+ | NEMO-3 |' `( MUX )---| VHF | \| NEMO-3 | +---------+--------- `-----' '----------*-......| HA | +--------+ Figure 6 Multiplexing at the Radio 4.2.2. Multiplexing at the Router Figure 7 illustrates combining information in the router rather than a special MUX box per figure 6. Here, multiple NEMOs are configured in a single router. There are many advantages to this architecture over the one in figure 6. First, there is no need for MUX boxes. Second, only one router interface is necessary for each radio system; therefore, traditional forms of acquiring a WAN address can be used(i.e. DHCP, PPP, Auto-configuration, manual configuration) and the same address is not assigned to multiple interfaces. Third, only one router is required for multiple NEMOs versus use of multiple NEMOs, one for each domain. Thus, there is potential for mass, power, volume and cost savings. Furthermore, this architecture is potentially much easier to manage. A definite security concern with multiplexing NEMOs and radios at the router is that various domains may be cross connected if configurations are not tightly controlled. Ivancic Expires March 18, 2007 [Page 15] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 _____+--------+ ,----------.--------------| NEMO-1 | | Satellite|`. ,"| HA | ," '----------*\ `. ," /+--------+ ,-" \ `. ," / +----------+ ," \ ;; / | |,-" `," `./ | NEMO-1 | ," \ /`. | | ,----------.," \ / `.+--------+ | NEMO-2 |-----------| WiFi |......,;......| NEMO-2 | | | '----------*`. / \ | HA | | NEMO-3 |`. `./ \ ,"+--------+ | | `. /`. ,-; +----------+ \ / `," \ `. / ," `. \ `. ,----------. ,-" `. +--------+ `.| VHF |," `.| NEMO-3 | '----------*............. | HA | `+--------+ Figure 7 Multiplexing at the Router 5. Network Access (auto-login) Obtaining access to a wireless network may be non-trivial for a mobile platform, depending on the wireless technology being deployed. A mobile platform SHOULD be able to obtain network access in an automated manner. 5.1. Cellular Access For cellular systems, access is usually accomplished via prearranged security and access agreements. A user contracts for bandwidth with a service provider and obtains a cellular modem that has a corresponding electronic serial number. When the modem (phone) makes a call, it transmits the ESN and the Mobile Identification Number (MIN)- also referred to as MSID (Mobile Station Identification)- to the network at the beginning of the call. The MIN/ESN pair is a unique tag for each modem and is used to establish the system's credentials and allow access to the wireless network. PPP or some other protocol can then be used to obtain a care-of-address. Ivancic Expires March 18, 2007 [Page 16] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 5.2. Satellite Access Satellite radio network access may be performed in a similar manner to cellular radio systems depending on the provider. In some satellite modems a form of electronic serial number or media access control (MAC) address is associated with a modem. Once the ESN (or MAC) is validated, the user obtains access to the network. Network addresses are obtained using PPP or statically configured addresses. 5.3. WiFi Access WiFi radio access is somewhat different than cellular or satellite access. Three basic modes of wireless network access are used: open network, preconfigured and negotiated. For open networks, any radio simply scans for a radio network and obtains access. Layer-3 address is usually provided via DHCP. Such radio and layer-3 access works well for a machine access (i.e. mobile router access). A preconfigured access will work for machine-to-machine operations. Such pre-configurations are usually found on private networks. Here, a pre-placed key may be used along with a security protocol such as Wired Equivalent Privacy (WEP) (802.11 encryption protocol). Media Access Control physical addresses may also be configured into access list to limit what radios are allowed to connect to the network. As security and accountability concerns grow, radio network access is moving toward negotiated access. Here, a user/name and password or some type of token ID and password are required for access. Such secure radio network access techniques include Extensible Authentication Protocol (EAP), and WiFi Protected Access (WPA). Currently such systems focus on the needs of the human mobile user who is in need of short term network access. Machine-to-machine negotiation of radio network access is not part of this operational scenario. Such concepts are new and businesses cases have yet to be considered. For NEMOs to take advantage of WiFi networks, techniques that allow for machine-to-machine radio access without the need for human intervention are imperative. 6. Costs Although not a protocol issue, the ISP cost model plays a significant role in the ability to deploy large mobile networks especially if they are multi-domained, multi-homed mobile networks. Fixed rate network access is essential to make it viable to budget for a mobile network. Paying a fixed price for a fixed amount of bandwidth works Ivancic Expires March 18, 2007 [Page 17] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 well as end users can budget for this cost model. If one has to pay by the amount of data that transitions a given network or connect time, it becomes extremely difficult to budget operations. For large-capacity users as it is extremely difficult to project how much data one will transfer over the link from one month to the next. Likewise, if one is being charged for connect time, one needs to deploy a mechanism that only brings a link up when it is needed. This results in a system that is out-bound oriented. Peer-to-peer communications only occurs when the links are turned on. Thus, in order for a corresponding node to initiate communications with the mobile node, some sort of back-channel has to be used to the mobile node to turn on the link of interest. 7. Security Considerations Having a single router operating in multiple domains either via generic routing protocols or use of mobile-ip based NEMO protocols has serious security issues. The possibility of having a single mobile router connected to multiple home agents residing in various domains implies that these domains could be inadvertently connected if the mobile router is misconfigured. Similarly, unless great care is taken to configure mobile platform routers that use generic routing, cross-domain connectivity can easily occur. Management of multi-domain routers is an interesting policy problem. "Who has authority to configure and control the mobile unit? ISPs often implement security mechanisms that break NEMO and mobile- ip. One example of this is deployment of administrative filtering. Here, an ISP may decide to have an out-bound only policy such that all traffic must have originated from within their network. At least one GPRS ISP has such a policy in place. One explanation provided for such a policy is to keep potentially hostile Internet traffic off the network. Probing the GPRS system address space not only posses a threat to customers, but, more importantly steals precious GPRS bandwidth from the users [Iva2003]. 8. IANA Considerations There are no IANA considerations as this is an informational document. 9. Acknowledgments The author would like to thank Terry Bell, Wesley Eddy, David Stewart and Terry Davis for their review and comments. The author would like to thank Joe Touch for his Microsoft Word template [Tou2006]. The Ivancic Expires March 18, 2007 [Page 18] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 author would particularly like to thank Markus Gebhard - a picture is worth a thousand words. Ivancic Expires March 18, 2007 [Page 19] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 10. References 10.1. Normative References [ICAO9705]"Manual of Technical Provisions for Aeronautical Telecommunication Network (ATN) - 3rd Edition", June 2002 [ICAO9739]"Comprehensive Aeronautical Telecommunication Network (ATN)", September 2000 [ISO10747]ISO/IEC 10747:1994, Protocol for Exchange of Inter-Domain Routing Information among Intermediate Systems to Support Forwarding of ISO/IEC 8473 PDUS. Error! Reference source not found.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy., J., "OSPF Version 2", RFC 2328. April 1998 [RFC3286] Ong, L., Yoakum, J., "An Introduction to the Stream Control Transmission Protocol (SCTP)", RFC 3286, May 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3344 June 2004. [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4423] Moskowitz, R., Nikander, P., "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [Sol2006] Soliman, H., Montavont, N., Fikouras, N., Kuladinithi, K., "Flow Bindings in Mobile IPv6", draft-soliman-monami6-flow- binding-01.txt, work in progress, expires December 2006 [Wak2006] Wakikawa, R., Nagami, K., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, work in progress, expires December 2006 Ivancic Expires March 18, 2007 [Page 20] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 10.2. Informative References [Iva2003] Ivancic, W., "Administrative Filtering", September 2003, http://roland.grc.nasa.gov/~ivancic/papers_presentations/20 03/administrative_filtering.pdf [Iva2006] Ivancic, W., "Aircraft Mobility using a combination of Internet Standards", ICAO Aeronautical Communications Panel(Acp)Working Group N - Networking Subgroup N1 - Internet Communications Services ACP/WG N/SG N1 Paper 801, May 2006, http://roland.grc.nasa.gov/~ivancic/papers_presentations/20 06/ICAO_WG-N_SG-N1_WP-801.pdf [Pan2004] Pang, J., Akella, A., Shaikh, A., Krishnamurthy, B., Seshan, S.,"On the Responsiveness of DNS-based Network Control",Proceedings of the Internet Measurement Conference 2004, October 2004. [Sig1998] Signore, T., Girard, M., "The Aeronautical Telecommunication Network (ATN)", IEEE 0-7803-4902-4/98/, 1998 [Tou2006] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", draft-touch-msword- template-v2.0-04.txt, work in progress expires August 2006 Author's Addresses William D. Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, OH 44135 Phone: +1 (216) 433-3494 Email: William.D.Ivancic@nasa.gov Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information Ivancic Expires March 18, 2007 [Page 21] Internet-Draft Multi-Domained Multi-Homed Mobile Networks September 2006 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ivancic Expires March 18, 2007 [Page 22]