[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]