| TOC |
|
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.
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 May 13, 2007.
Copyright © The Internet Society (2006).
This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements.
1.
Introduction
2.
Architectural Components
2.1.
Mobile Network (NEMO)
2.2.
Mobile Subnet
2.3.
Mobile Router (MR)
2.4.
Egress Interface
2.5.
Ingress Interface
2.6.
Mobile Network Prefix (MNP)
2.7.
Mobile Network Node (MNN)
2.8.
Correspondent Node (CN)
2.9.
Correspondent Router (CR)
2.10.
Correspondent Entity (CE)
3.
Functional Terms
3.1.
Local Fixed Node (LFN)
3.2.
Visiting Mobile Node (VMN)
3.3.
Local Mobile Node (LMN)
3.4.
NEMO-enabled node (NEMO-node)
3.5.
MIPv6-enabled (MIPv6-node)
4.
Nested Mobility Terms
4.1.
Nested Mobile Network (nested-NEMO)
4.2.
Root-NEMO
4.3.
Parent-NEMO
4.4.
Sub-NEMO
4.5.
Root-MR
4.6.
Parent-MR
4.7.
Sub-MR
4.8.
Depth
5.
Multihoming Terms
5.1.
Multihomed host or MNN
5.2.
Multihomed Mobile Router
5.3.
Multihomed Mobile Network (multihomed-NEMO)
5.4.
Nested Multihomed Mobile Network
5.5.
Split-NEMO
5.6.
Illustration
6.
Home Network Model Terms
6.1.
Home Link
6.2.
Home Network
6.3.
Home Address
6.4.
Mobile Home Network
6.5.
Distributed Home Network
6.6.
Mobile Aggregated Prefix
6.7.
Aggregated Home Network
6.8.
Extended Home Network
6.9.
Virtual Home Network
7.
Mobility Support Terms
7.1.
Host Mobility Support
7.2.
Network Mobility Support (NEMO Support)
7.3.
NEMO Basic Support
7.4.
NEMO Extended Support
7.5.
NEMO Routing Optimization (NEMO RO)
7.6.
MRHA Tunnel
7.7.
Pinball Route
8.
Security Considerations
9.
IANA Considerations
10.
Acknowledgments
11.
References
11.1.
Normative References
11.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Network mobility support is concerned with managing the mobility of an entire network. This arises when a router connecting a network to the Internet dynamically changes its point of attachment to the fixed infrastructure, thereby causing the reachability of the entire network to be changed in relation to the fixed Internet topology. Such a network is referred to as a mobile network. Without appropriate mechanisms to support network mobility, sessions established between nodes in the mobile network and the global Internet cannot be maintained after the mobile router changes its point of attachment. As a result, existing sessions would break and connectivity to the global Internet would be lost.
This document defines the specific terminology needed to describe the problem space, the design goals [1] (Ernst, T., “Network Mobility Support Goals and Requirements,” November 2006.), and the solutions for network mobility support. This terminology aims to be consistent with the usual IPv6 terminology [2] (Deering, S. and R. Hinden, “Internet Protocol Version 6 (IPv6),” December 1998.) and the generic mobility-related terms already defined in the Mobility Related Terminology [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.) and in the Mobile IPv6 specification [4] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). Some terms introduced in this document may only be useful for defining the problem scope and functional requirements of network mobility support.
Note that the abbreviation NEMO stands for either "a NEtwork that is MObile" or "NEtwork MObility". The former (see Section 2.1 (Mobile Network (NEMO))) is used as a noun, e.g. "a NEMO" meaning "a mobile network". The latter (see Section 7 (Mobility Support Terms)) refers to the concept of "network mobility" as in "NEMO Basic Support" and is also the working group's name.
Section 2 (Architectural Components) introduces terms to define the architecture while terms needed to emphasize the distinct functionalities of those architectural components are described in Section 3 (Functional Terms). Section 4 (Nested Mobility Terms), Section 5 (Multihoming Terms) and Section 6 (Home Network Model Terms) describe terms pertaining to nested mobility, multihoming and different configurations of mobile networks at home, respectively. The different types of mobility are defined in Section 7 (Mobility Support Terms). The last section lists miscellaneous terms which do not fit in any other section.
| TOC |
A mobile network is composed of one or more mobile IP-subnets and is viewed as a single unit. This network unit is connected to the Internet by means of one or more mobile routers (MRs). Nodes behind the MR (referred to as MNNs) primarily comprise fixed nodes (nodes unable to change their point of attachment while maintaining ongoing sessions), and possibly mobile nodes (nodes able to change their point of attachment while maintaining ongoing sessions). In most cases, the internal structure of the mobile network will be stable (no dynamic change of the topology), but this is not always true.
Figure 1 (Mobile Network on the Home Link) illustrates the architectural components involved in network mobility and defined in the following paragraphs: Mobile Router (MR), Mobile Network (NEMO), Mobile Network Node (MNN), "ingress interface", "egress interface", and Correspondent Node (CN). The other terms "access router" (AR), "Fixed Node (FN)", "Mobile Node (MN)", "home agent" (HA), "home link" and "foreign link" are not terms specific to network mobility and thus are defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.).
_
CN ->|_|-| Internet
| _____
|-| | |<- home link
_ | |-| _ | _
|-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent)
| \ | _
foreign link ->| ^ |-|_|<- MR (Mobile Router)
.. AR (access ___|___
router) _| |_
|_| |_|
^ ^
MNN1 MNN2
| Figure 1: Mobile Network on the Home Link |
Figure 2 (Single Mobile Subnet on a Foreign Link) shows a single mobile subnet. Figure 3 (Larger Mobile Network Made of 2 Mobile Subnets) illustrates a larger mobile network comprising several subnetworks, attached to a foreign link.
_
CN ->|_|-|
| _____
_ | |-| | |<- home link
|_|-| _ | _ | |-| _ | _
2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA
|_|-| . | \ \ |
| . |<- foreign ^AR
mobile subnet -> . link
.
^ MR
| Figure 2: Single Mobile Subnet on a Foreign Link |
_
CN->|_|-|
mobile subnet->| | _____
_ | |-| | |<- home link
MNN1->|_|-|'i'_'e'| _ | |-| _ | _
|--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA
'i'| | \ |
____|__ |
mobile subnet-^ _| . |<- foreign
|_| . link
MNN2 -^ .
^
MR
'i': MR's ingress interface
'e': MR's egress interface
| Figure 3: Larger Mobile Network Made of 2 Mobile Subnets |
At the network layer, MRs get access to the global Internet from the Access Router(s) (AR) on a visited link. An MR maintains the Internet connectivity for the entire mobile network. A given MR has one or more egress interface and one or more ingress interface. When forwarding a packet to the Internet, the packet is transmitted upstream through one of the MR's egress interfaces to the AR; when forwarding a packet from the AR down to the mobile network, the packet is transmitted downstream through one of the MR's ingress interfaces.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed of one or more IP-subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR.
Re-arrangement of the mobile network and changing the attachment point of the egress interface to the foreign link are orthogonal processes and do no affect each other.
| TOC |
A link (subnet) which comprises, or is located within, the mobile network.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
A router capable of changing its point of attachment to the Internet, moving from one link to another link. The MR is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which it does packet forwarding.
An MR acts as a gateway between an entire mobile network and the rest of the Internet, and has one or more egress interface and one or more ingress interface. Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interfaces; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interfaces.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
The network interface of an MR attached to the home link if the MR is at home, or attached to a foreign link if the MR is in a foreign network.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
The interface of an MR attached to a link inside the mobile network.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All nodes in a mobile network necessarily have an address containing this prefix.
| TOC |
As defined in [3] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.):
Any node (host or router) located within a mobile network, either permanently or temporarily. A Mobile Network Node may either be a fixed node (LFN) or a mobile node (VMN or LMN).
| TOC |
Any node that is communicating with one or more MNNs. A CN could be either located within a fixed network or within another mobile network, and could be either fixed or mobile.
| TOC |
Refers to the entity which is capable of terminating a Route Optimization session on behalf of a Correspondent Node (see also NEMO Route Optimization in Section 7.5 (NEMO Routing Optimization (NEMO RO))).
| TOC |
Refers to the entity which a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity maybe a Correspondent Node or Correspondent Router (see also NEMO Route Optimization in Section 7.5 (NEMO Routing Optimization (NEMO RO)))
| TOC |
Within the term Mobile Network Node (MNN), we can distinguish between Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN) and Local Mobile Nodes (LMN). The distinction is a property of how different types of nodes can move in the topology and is necessary to discuss issues related to mobility management and access control; however it does not imply that network mobility or host mobility should be handled differently. Nodes are classified according to their function and capabilities with the rationale that nodes with different properties may have different requirements.
Figure 4 (LFN vs LMM vs VMN) illustrates a VMN changing its point of
attachment from its home link located outside the mobile network to
within a mobile network. The figure also illustrates a LMN changing
its point of attachment within the mobile network.
mobile subnet 1 | _ +++++++<<<+++++++++++
|-|_|-| + +
++<<<LMN-| \ | + |-MR
+ | + _____ | _ HA_MR
+ | _ | + | |-|-|_|
+ LMN _ |-|_|-| _ | _ | | _
++++>|_|-| \ |--|_|--|-|_|-|_____|-|-|_|
| | ^ | \ | HA_VMN
VMN _ | MR |
|_|-| |-VMN
^ mobile subnet 2 +
+ +
++++++++<<<+++++++++++++++++++++++++
+++>>>+++ = changing point of attachment
| Figure 4: LFN vs LMM vs VMN |
In a typical use case of NEMO Basic Support [5] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.), only the MR and the HA are NEMO-enabled. LFNs are not MIPv6-enabled nor NEMO-enabled. On the other hand, a VMN or a LMN acting as a mobile router may be NEMO-enabled whereas a VMN or a LMN acting as a mobile node may be MIPv6-enabled.
For NEMO Extended Support, details of the capabilities are not known yet at the time of this writing, but NEMO-enabled nodes may be expected to implement some sort of Route Optimization.
| TOC |
A fixed node (FN), either a host or a router, that belongs to the mobile network and is unable to change its point of attachment while maintaining ongoing sessions. Its address is taken from an MNP.
| TOC |
Either a mobile node (MN) or a mobile router (MR), assigned to a home link that doesn't belong to the mobile network and which is able to change its point of attachment while maintaining ongoing sessions. A VMN that is temporarily attached to a mobile subnet (used as a foreign link) obtains an address on that subnet (i.e. the address is taken from an MNP).
| TOC |
Either a mobile node (MN) or a mobile router (MR), assigned to a home link belonging to the mobile network and which is able to change its point of attachment while maintaining ongoing sessions. Its address is taken from an MNP.
| TOC |
A node that has been extended with network mobility support capabilities as described in NEMO specifications.
| TOC |
A node which has been extended with host mobility support capabilities as defined in the Mobile IPv6 specification [4] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
| TOC |
Nested mobility occurs when there is more than one level of mobility, i.e. when a mobile network acts as an access network and allows visiting nodes to attach to it. There are two cases of nested mobility:
For the second case, we introduce the following terms:
| TOC |
A mobile network is said to be nested when a mobile network (sub-NEMO) is attached to a larger mobile network (parent-NEMO). The aggregated hierarchy of mobile networks becomes a single nested mobile network (see Figure 5 (Nested Mobility: a sub-NEMO attached to a larger mobile network)).
| TOC |
The mobile network at the top of the hierarchy connecting the aggregated nested mobile networks to the Internet (see Figure 5 (Nested Mobility: a sub-NEMO attached to a larger mobile network)).
| TOC |
The upstream mobile network providing Internet access to another mobile network further down the hierarchy (see Figure 5 (Nested Mobility: a sub-NEMO attached to a larger mobile network)).
| TOC |
The downstream mobile network attached to another mobile network up in the hierarchy. It becomes subservient of the parent-NEMO. The sub-NEMO is getting Internet access through the parent-NEMO and does not provide Internet access to the parent-NEMO (see Figure 5 (Nested Mobility: a sub-NEMO attached to a larger mobile network)).
| TOC |
The MR(s) of the root-NEMO used to connect the nested mobile network to the fixed Internet (see Figure 5 (Nested Mobility: a sub-NEMO attached to a larger mobile network)).
| TOC |
The MR(s) of the parent-NEMO.
| TOC |
The MR(s) of the sub-NEMO which is connected to a parent-NEMO
| TOC |
In a nested NEMO indicates the number of sub-MRs a packet has to cross between a MNN and the root-MR.
A MNN in the root-NEMO is at depth 1. If there are multiple root-NEMOs, a different depth is computed from each root-MR.
_____
_ | _ | |
_ |-|_|-| _ |-|_|-|-| |-| _
_ |-|_|-| \ |-|_|-| \ | |_____| | _ |-|_|
_ |-|_|-| | | | |-|_|-|
|_|-| \ | \ |
|
MNN AR sub-MR AR root-MR AR AR HA
<--------------><----------><----><---------><-------->
sub-NEMO root-NEMO fl Internet Home Network
| Figure 5: Nested Mobility: a sub-NEMO attached to a larger mobile network |
| TOC |
Multihoming, as currently defined by the IETF, covers site-multihoming [10] (Abley, J., Black, B., and V. Gill, “Goals for IPv6 Site-Multihoming Architectures,” August 2003.) and host multihoming. We enlarge this terminology to include "multihomed mobile router" and "multihomed mobile network". The specific configurations and issues pertaining to multihomed mobile networks are covered in [6] (Ng, C., Paik, Ernst, and C. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” June 2006.).
| TOC |
A host (e.g. an MNN) is multihomed when it has several addresses to choose between, i.e. in the following cases when it is either:
| TOC |
From the definition of a multihomed host, it follows that a mobile router is multihomed when it has several addresses to choose between, i.e. in the following cases when the MR is either:
_____
_ _ | |
|_|-| _ |-|_|-| |-| _
_ |-|_|=| \ |_____| | _ |-|_|
|_|-| | |-|_|-|
\ |
MNNs MR AR Internet AR HA
| Figure 6: Multihoming: MR with multiple E-faces |
| TOC |
A mobile network is multihomed when either a MR is multihomed or there are multiple MRs to choose between (see the corresponding analysis in [6] (Ng, C., Paik, Ernst, and C. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” June 2006.)).
MR1
_ |
_ |-|_|-| _____
|_|-| |-| |
MNNs _ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
| |
MR2
| Figure 7: Multihoming: NEMO with Multiple MRs |
| TOC |
A nested mobile network is multihomed when either a root-MR is multihomed or there are multiple root-MRs to choose between.
| TOC |
Split-NEMO refers to the case where a mobile network becomes two or more independent mobile networks due to the separation of Mobile Routers which are handling the same MNP (or MNPs) in the original mobile network before the separation.
| TOC |
Figure 6 (Multihoming: MR with multiple E-faces) and Figure 7 (Multihoming: NEMO with Multiple MRs) show two examples of multihomed mobile networks. Figure 8 (Nested Multihomed NEMO) shows two independent mobile networks. NEMO-1 is single-homed to the Internet through MR1. NEMO-2 is multihomed to the Internet through MR2a and MR2b. Both mobile networks offer access to visiting nodes and networks through an AR.
Let's consider the two following nested scenarios in Figure 8 (Nested Multihomed NEMO):
- Scenario 1: What happens when MR2a's egress interface is attached to AR1 ?
- NEMO-2 becomes subservient of NEMO-1
- NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for the aggregated nested mobile network
- NEMO-2 becomes the sub-NEMO
- MR1 is the root-MR for the aggregated nested mobile network
- MR2a is a sub-MR in the aggregated nested mobile network
- NEMO-2 is still multihomed to the Internet through AR1 and ARz
- The aggregated nested mobile network is not multihomed, since NEMO-2 cannot be used as a transit network for NEMO-1
- Scenario 2: What happens when MR1's egress interface is attached to AR2 ?
- NEMO-1 becomes subservient of NEMO-2
- NEMO-1 becomes the sub-NEMO
- NEMO-2 becomes the parent_NEMO for NEMO-1 and also the root-NEMO for the aggregated nested mobile network
- MR2a and MR2b are both root-MRs for the aggregated nested mobile network
- MR1 is a sub-MR in the aggregated nested mobile network
- NEMO-1 is not multihomed
- The aggregated nested mobile network is multihomed
_ | _ |
|_|-|-|_|-| _ _____
NEMO-1 MNNs _ | MR1 |-|_|-| |
|_|-| ARx | |-| _
AR1 \ | | _ | | | _ |-|_|
_ |-|_|-| | |-|_|-|
_ |-|_|-| ARy | | |
|_|-| MR2a _ | |
NEMO-2 MNNs _ | |-|_|-| |
|_|-| _ | ARz |_____|
\ |-|_|-|
AR2 MR2b
| Figure 8: Nested Multihomed NEMO |
| TOC |
The terms in this section are useful to describe the possible configurations of mobile networks at the home. For a better understanding of the definitions, the reader is recommended to read [7] (Thubert, P., Wakikawa, R., and V. Devarapalli, “NEMO Home Network Models,” February 2006.) where such configurations are detailed
| TOC |
The link attached to the interface at the Home Agent on which the Home Prefix is configured. The interface can be a virtual interface, in which case the Home Link is a Virtual Home Link.
| TOC |
The Network formed by the application of the Home Prefix to the Home Link. With NEMO, the concept of Home Network is extended as explained below.
| TOC |
With Mobile IPv6, a Home Address is derived from the Home Network prefix. This is generalized in NEMO, with some limitations: A Home Address can be derived either from the Home Network or from one of the Mobile Router's MNPs.
| TOC |
A Mobile Network (NEMO) that is also a Home Network. The MR or one of the MR(s) that owns the MNP may act as the Home Agent for the mobile nodes in the Mobile Home Network.
| TOC |
A Distributed Home Network is a Home Network that is distributed geographically between sites. The aggregated Home Prefix is partitioned between the sites and advertised by all sites.
This aggregated Home Prefix can be further aggregated within a service provider network or between service providers, to form a prefix that is announced into the Internet by the service provider(s) from multiple points.
The sites may be connected using a mesh of private links and tunnels. A routing protocol is used within and between sites to exchange routes to the subnets associated to the sites, and, eventually, to Mobile Routers registered off-site.
| TOC |
An aggregation of Mobile Network Prefixes.
| TOC |
The Home Network associated with a Mobile Aggregated Prefix. This Aggregation is advertised as a subnet on the Home Link, and thus used as Home Network for NEMO purposes.
| TOC |
The network associated with the aggregation of one or more Home Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home Network that is a subnet, the extended Home Network is an aggregation and is further subnetted.
| TOC |
An aggregation of Mobile Network Prefixes that is in turn advertised as the Home Link Prefix. The Extended Home Network and the Aggregated Home Network can be configured as Virtual Home Network.
| TOC |
| TOC |
Host Mobility Support is a mechanism which maintains session continuity between mobile nodes and their correspondents upon the mobile host's change of point of attachment. It can be achieved using Mobile IPv6 or other mobility support mechanisms.
| TOC |
Network Mobility Support is a mechanism which maintains session continuity between mobile network nodes and their correspondents upon a mobile router's change of point of attachment. Solutions for this problem are classified into NEMO Basic Support, and NEMO Extended Support.
| TOC |
NEMO Basic Support is a solution to preserve session continuity by means of bi-directional tunneling between MRs and their HAs much like what is done with Mobile IPv6 [4] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) for mobile nodes when Routing Optimization is not used. Only the HA and the MR are NEMO-enabled.
RFC 3963 [5] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) is the solution specified by the NEMO Working Group for NEMO Basic Support.
| TOC |
NEMO Extended support is to provide the necessary optimization, including routing optimization between arbitrary MNNs and CNs.
| TOC |
The term "Route Optimization" is accepted in a broader sense than already defined for IPv6 Host Mobility in [4] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node.
For more information about NEMO Route Optimization in the NEMO context, see the problem statement [8] (Ng, C., Thubert, P., Watari, M., and F. Zhao, “Network Mobility Route Optimization Problem Statement,” September 2006.) and the solution space analysis [9] (Ng, C., Zhao, F., Watari, M., and P. Thubert, “Network Mobility Route Optimization Solution Space Analysis,” September 2006.).
| TOC |
The bi-directional tunnel between a Mobile Router and its Home Agent.
| TOC |
A pinball route refers to the non-direct path taken by packets, which are routed via one or more Home Agents, as they transit between a Mobile Network Node and a Correspondent Node.
A packet following a pinball route would appear like a ball bouncing off one or more Home Agents before reaching its final destination.
| TOC |
As this document only provides terminology and describes neither a protocol nor an implementation or a procedure, there are no security considerations associated with it.
| TOC |
This document requires no IANA actions.
| TOC |
The material presented in this document takes most of the text from internet-drafts initially submitted to the former MobileIP WG and the MONET BOF and was published as part of a PhD dissertation [11] (Ernst, T., “Network Mobility Support in IPv6,” October 2001.). The authors would therefore like to thank both Motorola Labs Paris and INRIA (PLANETE team, Grenoble, France) where this terminology originated, for the opportunity to bring it to the IETF, and particularly Claude Castelluccia for his advice, suggestions, and direction, Alexandru Petrescu and Christophe Janneteau. We also acknowledge input from Erik Nordmark, Hesham Soliman, Mattias Petterson, Marcelo Bagnulo, TJ Kniveton, Masafumi Watari, Chan-Wah Ng, JinHyeock Choi and numerous other people from the NEMO Working Group. The Home Network Model section is contributed by Pascal Thubert, Ryuji Wakikawa and Vijay Devaparalli.
| TOC |
| TOC |
| [1] | Ernst, T., “Network Mobility Support Goals and Requirements,” draft-ietf-nemo-requirements-06 (work in progress), November 2006. |
| [2] | Deering, S. and R. Hinden, “Internet Protocol Version 6 (IPv6),” RFC 2460, December 1998. |
| [3] | Manner, J. and M. Kojo, “Mobility Related Terminology,” RFC 3753, June 2004. |
| [4] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004. |
| [5] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005. |
| [6] | Ng, C., Paik, Ernst, and C. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” draft-ietf-nemo-multihoming-issues-06 (work in progress), June 2006. |
| [7] | Thubert, P., Wakikawa, R., and V. Devarapalli, “NEMO Home Network Models,” draft-ietf-nemo-home-network-models-06 (work in progress), February 2006. |
| [8] | Ng, C., Thubert, P., Watari, M., and F. Zhao, “Network Mobility Route Optimization Problem Statement,” draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. |
| [9] | Ng, C., Zhao, F., Watari, M., and P. Thubert, “Network Mobility Route Optimization Solution Space Analysis,” draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. |
| TOC |
| [10] | Abley, J., Black, B., and V. Gill, “Goals for IPv6 Site-Multihoming Architectures,” RFC 3582, August 2003. |
| [11] | Ernst, T., “Network Mobility Support in IPv6,” PhD's Thesis. , Universite Joseph Fourier, Grenoble, France , October 2001. |
| TOC |
| Thierry Ernst | |
| INRIA | |
| INRIA Rocquencourt | |
| Domaine de Voluceau B.P. 105 | |
| Le Chesnay, 78153 | |
| France | |
| Phone: | +33 1 39 63 59 30 |
| Fax: | +33 1 39 63 54 91 |
| Email: | thierry.ernst@inria.fr |
| URI: | http://www-rocq.inria.fr/imara |
| Hong-Yon Lach | |
| Motorola Labs Paris | |
| Espace Technologique - Saint Aubin | |
| Gif-sur-Yvette Cedex, 91 193 | |
| France | |
| Phone: | +33-169-35-25-36 |
| Fax: | |
| Email: | hong-yon.lach@motorola.com |
| URI: |
| TOC |
Copyright © 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.
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.
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 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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).