idnits 2.17.1 draft-ietf-nemo-terminology-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 879. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2006) is 6379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group T. Ernst 3 Internet-Draft INRIA 4 Intended status: Informational H-Y. Lach 5 Expires: May 13, 2007 Motorola Labs 6 November 9, 2006 8 Network Mobility Support Terminology 9 draft-ietf-nemo-terminology-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 13, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines a terminology for discussing network mobility 43 (NEMO) issues and solution requirements. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Architectural Components . . . . . . . . . . . . . . . . . . . 5 50 2.1. Mobile Network (NEMO) . . . . . . . . . . . . . . . . . . 7 51 2.2. Mobile Subnet . . . . . . . . . . . . . . . . . . . . . . 7 52 2.3. Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 7 53 2.4. Egress Interface . . . . . . . . . . . . . . . . . . . . . 7 54 2.5. Ingress Interface . . . . . . . . . . . . . . . . . . . . 8 55 2.6. Mobile Network Prefix (MNP) . . . . . . . . . . . . . . . 8 56 2.7. Mobile Network Node (MNN) . . . . . . . . . . . . . . . . 8 57 2.8. Correspondent Node (CN) . . . . . . . . . . . . . . . . . 8 58 2.9. Correspondent Router (CR) . . . . . . . . . . . . . . . . 8 59 2.10. Correspondent Entity (CE) . . . . . . . . . . . . . . . . 8 61 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . 10 63 3.2. Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . 10 64 3.3. Local Mobile Node (LMN) . . . . . . . . . . . . . . . . . 10 65 3.4. NEMO-enabled node (NEMO-node) . . . . . . . . . . . . . . 10 66 3.5. MIPv6-enabled (MIPv6-node) . . . . . . . . . . . . . . . . 10 68 4. Nested Mobility Terms . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Nested Mobile Network (nested-NEMO) . . . . . . . . . . . 11 70 4.2. Root-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.3. Parent-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.4. Sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.5. Root-MR . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.6. Parent-MR . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.7. Sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.8. Depth . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. Multihomed host or MNN . . . . . . . . . . . . . . . . . . 13 80 5.2. Multihomed Mobile Router . . . . . . . . . . . . . . . . . 13 81 5.3. Multihomed Mobile Network (multihomed-NEMO) . . . . . . . 14 82 5.4. Nested Multihomed Mobile Network . . . . . . . . . . . . . 14 83 5.5. Split-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.6. Illustration . . . . . . . . . . . . . . . . . . . . . . . 14 86 6. Home Network Model Terms . . . . . . . . . . . . . . . . . . . 17 87 6.1. Home Link . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Home Network . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.3. Home Address . . . . . . . . . . . . . . . . . . . . . . . 17 90 6.4. Mobile Home Network . . . . . . . . . . . . . . . . . . . 17 91 6.5. Distributed Home Network . . . . . . . . . . . . . . . . . 17 92 6.6. Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . 18 93 6.7. Aggregated Home Network . . . . . . . . . . . . . . . . . 18 94 6.8. Extended Home Network . . . . . . . . . . . . . . . . . . 18 95 6.9. Virtual Home Network . . . . . . . . . . . . . . . . . . . 18 97 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 19 98 7.1. Host Mobility Support . . . . . . . . . . . . . . . . . . 19 99 7.2. Network Mobility Support (NEMO Support) . . . . . . . . . 19 100 7.3. NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 19 101 7.4. NEMO Extended Support . . . . . . . . . . . . . . . . . . 19 102 7.5. NEMO Routing Optimization (NEMO RO) . . . . . . . . . . . 19 103 7.6. MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 19 104 7.7. Pinball Route . . . . . . . . . . . . . . . . . . . . . . 20 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 110 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 117 Intellectual Property and Copyright Statements . . . . . . . . . . 26 119 1. Introduction 121 Network mobility support is concerned with managing the mobility of 122 an entire network. This arises when a router connecting a network to 123 the Internet dynamically changes its point of attachment to the fixed 124 infrastructure, thereby causing the reachability of the entire 125 network to be changed in relation to the fixed Internet topology. 126 Such a network is referred to as a mobile network. Without 127 appropriate mechanisms to support network mobility, sessions 128 established between nodes in the mobile network and the global 129 Internet cannot be maintained after the mobile router changes its 130 point of attachment. As a result, existing sessions would break and 131 connectivity to the global Internet would be lost. 133 This document defines the specific terminology needed to describe the 134 problem space, the design goals [1], and the solutions for network 135 mobility support. This terminology aims to be consistent with the 136 usual IPv6 terminology [2] and the generic mobility-related terms 137 already defined in the Mobility Related Terminology [3] and in the 138 Mobile IPv6 specification [4]. Some terms introduced in this 139 document may only be useful for defining the problem scope and 140 functional requirements of network mobility support. 142 Note that the abbreviation NEMO stands for either "a NEtwork that is 143 MObile" or "NEtwork MObility". The former (see Section 2.1) is used 144 as a noun, e.g. "a NEMO" meaning "a mobile network". The latter (see 145 Section 7) refers to the concept of "network mobility" as in "NEMO 146 Basic Support" and is also the working group's name. 148 Section 2 introduces terms to define the architecture while terms 149 needed to emphasize the distinct functionalities of those 150 architectural components are described in Section 3. Section 4, 151 Section 5 and Section 6 describe terms pertaining to nested mobility, 152 multihoming and different configurations of mobile networks at home, 153 respectively. The different types of mobility are defined in 154 Section 7. The last section lists miscellaneous terms which do not 155 fit in any other section. 157 2. Architectural Components 159 A mobile network is composed of one or more mobile IP-subnets and is 160 viewed as a single unit. This network unit is connected to the 161 Internet by means of one or more mobile routers (MRs). Nodes behind 162 the MR (referred to as MNNs) primarily comprise fixed nodes (nodes 163 unable to change their point of attachment while maintaining ongoing 164 sessions), and possibly mobile nodes (nodes able to change their 165 point of attachment while maintaining ongoing sessions). In most 166 cases, the internal structure of the mobile network will be stable 167 (no dynamic change of the topology), but this is not always true. 169 Figure 1 illustrates the architectural components involved in network 170 mobility and defined in the following paragraphs: Mobile Router (MR), 171 Mobile Network (NEMO), Mobile Network Node (MNN), "ingress 172 interface", "egress interface", and Correspondent Node (CN). The 173 other terms "access router" (AR), "Fixed Node (FN)", "Mobile Node 174 (MN)", "home agent" (HA), "home link" and "foreign link" are not 175 terms specific to network mobility and thus are defined in [3]. 177 _ 178 CN ->|_|-| Internet 179 | _____ 180 |-| | |<- home link 181 _ | |-| _ | _ 182 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent) 183 | \ | _ 184 foreign link ->| ^ |-|_|<- MR (Mobile Router) 185 .. AR (access ___|___ 186 router) _| |_ 187 |_| |_| 188 ^ ^ 189 MNN1 MNN2 191 Figure 1: Mobile Network on the Home Link 193 Figure 2 shows a single mobile subnet. Figure 3 illustrates a larger 194 mobile network comprising several subnetworks, attached to a foreign 195 link. 197 _ 198 CN ->|_|-| 199 | _____ 200 _ | |-| | |<- home link 201 |_|-| _ | _ | |-| _ | _ 202 2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA 203 |_|-| . | \ \ | 204 | . |<- foreign ^AR 205 mobile subnet -> . link 206 . 207 ^ MR 209 Figure 2: Single Mobile Subnet on a Foreign Link 211 _ 212 CN->|_|-| 213 mobile subnet->| | _____ 214 _ | |-| | |<- home link 215 MNN1->|_|-|'i'_'e'| _ | |-| _ | _ 216 |--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA 217 'i'| | \ | 218 ____|__ | 219 mobile subnet-^ _| . |<- foreign 220 |_| . link 221 MNN2 -^ . 222 ^ 223 MR 225 'i': MR's ingress interface 226 'e': MR's egress interface 228 Figure 3: Larger Mobile Network Made of 2 Mobile Subnets 230 At the network layer, MRs get access to the global Internet from the 231 Access Router(s) (AR) on a visited link. An MR maintains the 232 Internet connectivity for the entire mobile network. A given MR has 233 one or more egress interface and one or more ingress interface. When 234 forwarding a packet to the Internet, the packet is transmitted 235 upstream through one of the MR's egress interfaces to the AR; when 236 forwarding a packet from the AR down to the mobile network, the 237 packet is transmitted downstream through one of the MR's ingress 238 interfaces. 240 2.1. Mobile Network (NEMO) 242 As defined in [3]: 244 An entire network, moving as a unit, which dynamically changes its 245 point of attachment to the Internet and thus its reachability in the 246 topology. The mobile network is composed of one or more IP-subnets 247 and is connected to the global Internet via one or more Mobile 248 Routers (MR). The internal configuration of the mobile network is 249 assumed to be relatively stable with respect to the MR. 251 Re-arrangement of the mobile network and changing the attachment 252 point of the egress interface to the foreign link are orthogonal 253 processes and do no affect each other. 255 2.2. Mobile Subnet 257 A link (subnet) which comprises, or is located within, the mobile 258 network. 260 2.3. Mobile Router (MR) 262 As defined in [3]: 264 A router capable of changing its point of attachment to the Internet, 265 moving from one link to another link. The MR is capable of 266 forwarding packets between two or more interfaces, and possibly 267 running a dynamic routing protocol modifying the state by which it 268 does packet forwarding. 270 An MR acts as a gateway between an entire mobile network and the rest 271 of the Internet, and has one or more egress interface and one or more 272 ingress interface. Packets forwarded upstream to the rest of the 273 Internet are transmitted through one of the MR's egress interfaces; 274 packets forwarded downstream to the mobile network are transmitted 275 through one of the MR's ingress interfaces. 277 2.4. Egress Interface 279 As defined in [3]: 281 The network interface of an MR attached to the home link if the MR is 282 at home, or attached to a foreign link if the MR is in a foreign 283 network. 285 2.5. Ingress Interface 287 As defined in [3]: 289 The interface of an MR attached to a link inside the mobile network. 291 2.6. Mobile Network Prefix (MNP) 293 As defined in [3]: 295 A bit string that consists of some number of initial bits of an IP 296 address which identifies the entire mobile network within the 297 Internet topology. All nodes in a mobile network necessarily have an 298 address containing this prefix. 300 2.7. Mobile Network Node (MNN) 302 As defined in [3]: 304 Any node (host or router) located within a mobile network, either 305 permanently or temporarily. A Mobile Network Node may either be a 306 fixed node (LFN) or a mobile node (VMN or LMN). 308 2.8. Correspondent Node (CN) 310 Any node that is communicating with one or more MNNs. A CN could be 311 either located within a fixed network or within another mobile 312 network, and could be either fixed or mobile. 314 2.9. Correspondent Router (CR) 316 Refers to the entity which is capable of terminating a Route 317 Optimization session on behalf of a Correspondent Node (see also NEMO 318 Route Optimization in Section 7.5). 320 2.10. Correspondent Entity (CE) 322 Refers to the entity which a Mobile Router or Mobile Network Node 323 attempts to establish a Route Optimization session with. Depending 324 on the Route Optimization approach, the Correspondent Entity maybe a 325 Correspondent Node or Correspondent Router (see also NEMO Route 326 Optimization in Section 7.5) 328 3. Functional Terms 330 Within the term Mobile Network Node (MNN), we can distinguish between 331 Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN) and Local Mobile 332 Nodes (LMN). The distinction is a property of how different types of 333 nodes can move in the topology and is necessary to discuss issues 334 related to mobility management and access control; however it does 335 not imply that network mobility or host mobility should be handled 336 differently. Nodes are classified according to their function and 337 capabilities with the rationale that nodes with different properties 338 may have different requirements. 340 Figure 4 illustrates a VMN changing its point of attachment from its 341 home link located outside the mobile network to within a mobile 342 network. The figure also illustrates a LMN changing its point of 343 attachment within the mobile network. 345 mobile subnet 1 | _ +++++++<<<+++++++++++ 346 |-|_|-| + + 347 ++<<|_|-| \ |--|_|--|-|_|-|_____|-|-|_| 352 | | ^ | \ | HA_VMN 353 VMN _ | MR | 354 |_|-| |-VMN 355 ^ mobile subnet 2 + 356 + + 357 ++++++++<<<+++++++++++++++++++++++++ 359 +++>>>+++ = changing point of attachment 361 Figure 4: LFN vs LMM vs VMN 363 In a typical use case of NEMO Basic Support [5], only the MR and the 364 HA are NEMO-enabled. LFNs are not MIPv6-enabled nor NEMO-enabled. 365 On the other hand, a VMN or a LMN acting as a mobile router may be 366 NEMO-enabled whereas a VMN or a LMN acting as a mobile node may be 367 MIPv6-enabled. 369 For NEMO Extended Support, details of the capabilities are not known 370 yet at the time of this writing, but NEMO-enabled nodes may be 371 expected to implement some sort of Route Optimization. 373 3.1. Local Fixed Node (LFN) 375 A fixed node (FN), either a host or a router, that belongs to the 376 mobile network and is unable to change its point of attachment while 377 maintaining ongoing sessions. Its address is taken from an MNP. 379 3.2. Visiting Mobile Node (VMN) 381 Either a mobile node (MN) or a mobile router (MR), assigned to a home 382 link that doesn't belong to the mobile network and which is able to 383 change its point of attachment while maintaining ongoing sessions. A 384 VMN that is temporarily attached to a mobile subnet (used as a 385 foreign link) obtains an address on that subnet (i.e. the address is 386 taken from an MNP). 388 3.3. Local Mobile Node (LMN) 390 Either a mobile node (MN) or a mobile router (MR), assigned to a home 391 link belonging to the mobile network and which is able to change its 392 point of attachment while maintaining ongoing sessions. Its address 393 is taken from an MNP. 395 3.4. NEMO-enabled node (NEMO-node) 397 A node that has been extended with network mobility support 398 capabilities as described in NEMO specifications. 400 3.5. MIPv6-enabled (MIPv6-node) 402 A node which has been extended with host mobility support 403 capabilities as defined in the Mobile IPv6 specification [4]. 405 4. Nested Mobility Terms 407 Nested mobility occurs when there is more than one level of mobility, 408 i.e. when a mobile network acts as an access network and allows 409 visiting nodes to attach to it. There are two cases of nested 410 mobility: 412 o The attaching node is a single VMN (see Figure 4). For instance, 413 when a passenger carrying a mobile phone gets Internet access from 414 the public access network deployed on a bus. 416 o The attaching node is a MR with nodes behind it, i.e. a mobile 417 network (see Figure 5). For instance, when a passenger carrying a 418 PAN gets Internet access from the public access network deployed 419 on a bus. 421 For the second case, we introduce the following terms: 423 4.1. Nested Mobile Network (nested-NEMO) 425 A mobile network is said to be nested when a mobile network (sub- 426 NEMO) is attached to a larger mobile network (parent-NEMO). The 427 aggregated hierarchy of mobile networks becomes a single nested 428 mobile network (see Figure 5). 430 4.2. Root-NEMO 432 The mobile network at the top of the hierarchy connecting the 433 aggregated nested mobile networks to the Internet (see Figure 5). 435 4.3. Parent-NEMO 437 The upstream mobile network providing Internet access to another 438 mobile network further down the hierarchy (see Figure 5). 440 4.4. Sub-NEMO 442 The downstream mobile network attached to another mobile network up 443 in the hierarchy. It becomes subservient of the parent-NEMO. The 444 sub-NEMO is getting Internet access through the parent-NEMO and does 445 not provide Internet access to the parent-NEMO (see Figure 5). 447 4.5. Root-MR 449 The MR(s) of the root-NEMO used to connect the nested mobile network 450 to the fixed Internet (see Figure 5). 452 4.6. Parent-MR 454 The MR(s) of the parent-NEMO. 456 4.7. Sub-MR 458 The MR(s) of the sub-NEMO which is connected to a parent-NEMO 460 4.8. Depth 462 In a nested NEMO indicates the number of sub-MRs a packet has to 463 cross between a MNN and the root-MR. 465 A MNN in the root-NEMO is at depth 1. If there are multiple root- 466 NEMOs, a different depth is computed from each root-MR. 468 _____ 469 _ | _ | | 470 _ |-|_|-| _ |-|_|-|-| |-| _ 471 _ |-|_|-| \ |-|_|-| \ | |_____| | _ |-|_| 472 _ |-|_|-| | | | |-|_|-| 473 |_|-| \ | \ | 474 | 476 MNN AR sub-MR AR root-MR AR AR HA 478 <--------------><----------><----><---------><--------> 479 sub-NEMO root-NEMO fl Internet Home Network 481 Figure 5: Nested Mobility: a sub-NEMO attached to a larger mobile 482 network 484 5. Multihoming Terms 486 Multihoming, as currently defined by the IETF, covers site- 487 multihoming [10] and host multihoming. We enlarge this terminology 488 to include "multihomed mobile router" and "multihomed mobile 489 network". The specific configurations and issues pertaining to 490 multihomed mobile networks are covered in [6]. 492 5.1. Multihomed host or MNN 494 A host (e.g. an MNN) is multihomed when it has several addresses to 495 choose between, i.e. in the following cases when it is either: 497 o Multi-prefixed: multiple prefixes are advertised on the link(s) 498 the host is attached to, or 500 o Multi-interfaced: the host has multiple interfaces to choose 501 between, on the same link or not. 503 5.2. Multihomed Mobile Router 505 From the definition of a multihomed host, it follows that a mobile 506 router is multihomed when it has several addresses to choose between, 507 i.e. in the following cases when the MR is either: 509 o Multi-prefixed: multiple prefixes are advertised on the link(s) an 510 MR's egress interface is attached to, or. 512 o Multi-interfaced: the MR has multiple egress interfaces to choose 513 between, on the same link or not (see Figure 6). 515 _____ 516 _ _ | | 517 |_|-| _ |-|_|-| |-| _ 518 _ |-|_|=| \ |_____| | _ |-|_| 519 |_|-| | |-|_|-| 520 \ | 521 MNNs MR AR Internet AR HA 523 Figure 6: Multihoming: MR with multiple E-faces 525 5.3. Multihomed Mobile Network (multihomed-NEMO) 527 A mobile network is multihomed when either a MR is multihomed or 528 there are multiple MRs to choose between (see the corresponding 529 analysis in [6]). 531 MR1 532 _ | 533 _ |-|_|-| _____ 534 |_|-| |-| | 535 MNNs _ | | |-| _ 536 |_|-| _ |-|_____| | _ |-|_| 537 |-|_|-| |-|_|-| 538 | | 539 MR2 541 Figure 7: Multihoming: NEMO with Multiple MRs 543 5.4. Nested Multihomed Mobile Network 545 A nested mobile network is multihomed when either a root-MR is 546 multihomed or there are multiple root-MRs to choose between. 548 5.5. Split-NEMO 550 Split-NEMO refers to the case where a mobile network becomes two or 551 more independent mobile networks due to the separation of Mobile 552 Routers which are handling the same MNP (or MNPs) in the original 553 mobile network before the separation. 555 5.6. Illustration 557 Figure 6 and Figure 7 show two examples of multihomed mobile 558 networks. Figure 8 shows two independent mobile networks. NEMO-1 is 559 single-homed to the Internet through MR1. NEMO-2 is multihomed to 560 the Internet through MR2a and MR2b. Both mobile networks offer 561 access to visiting nodes and networks through an AR. 563 Let's consider the two following nested scenarios in Figure 8: 565 Scenario 1: What happens when MR2a's egress interface is attached to 566 AR1 ? 567 * NEMO-2 becomes subservient of NEMO-1 569 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 570 the aggregated nested mobile network 572 * NEMO-2 becomes the sub-NEMO 574 * MR1 is the root-MR for the aggregated nested mobile network 576 * MR2a is a sub-MR in the aggregated nested mobile network 578 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 580 * The aggregated nested mobile network is not multihomed, since 581 NEMO-2 cannot be used as a transit network for NEMO-1 583 Scenario 2: What happens when MR1's egress interface is attached to 584 AR2 ? 586 * NEMO-1 becomes subservient of NEMO-2 588 * NEMO-1 becomes the sub-NEMO 590 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the root- 591 NEMO for the aggregated nested mobile network 593 * MR2a and MR2b are both root-MRs for the aggregated nested 594 mobile network 596 * MR1 is a sub-MR in the aggregated nested mobile network 598 * NEMO-1 is not multihomed 600 * The aggregated nested mobile network is multihomed 601 _ | _ | 602 |_|-|-|_|-| _ _____ 603 NEMO-1 MNNs _ | MR1 |-|_|-| | 604 |_|-| ARx | |-| _ 605 AR1 \ | | _ | | | _ |-|_| 606 _ |-|_|-| | |-|_|-| 607 _ |-|_|-| ARy | | | 608 |_|-| MR2a _ | | 609 NEMO-2 MNNs _ | |-|_|-| | 610 |_|-| _ | ARz |_____| 611 \ |-|_|-| 612 AR2 MR2b 614 Figure 8: Nested Multihomed NEMO 616 6. Home Network Model Terms 618 The terms in this section are useful to describe the possible 619 configurations of mobile networks at the home. For a better 620 understanding of the definitions, the reader is recommended to read 621 [7] where such configurations are detailed 623 6.1. Home Link 625 The link attached to the interface at the Home Agent on which the 626 Home Prefix is configured. The interface can be a virtual interface, 627 in which case the Home Link is a Virtual Home Link. 629 6.2. Home Network 631 The Network formed by the application of the Home Prefix to the Home 632 Link. With NEMO, the concept of Home Network is extended as 633 explained below. 635 6.3. Home Address 637 With Mobile IPv6, a Home Address is derived from the Home Network 638 prefix. This is generalized in NEMO, with some limitations: A Home 639 Address can be derived either from the Home Network or from one of 640 the Mobile Router's MNPs. 642 6.4. Mobile Home Network 644 A Mobile Network (NEMO) that is also a Home Network. The MR or one 645 of the MR(s) that owns the MNP may act as the Home Agent for the 646 mobile nodes in the Mobile Home Network. 648 6.5. Distributed Home Network 650 A Distributed Home Network is a Home Network that is distributed 651 geographically between sites. The aggregated Home Prefix is 652 partitioned between the sites and advertised by all sites. 654 This aggregated Home Prefix can be further aggregated within a 655 service provider network or between service providers, to form a 656 prefix that is announced into the Internet by the service provider(s) 657 from multiple points. 659 The sites may be connected using a mesh of private links and tunnels. 660 A routing protocol is used within and between sites to exchange 661 routes to the subnets associated to the sites, and, eventually, to 662 Mobile Routers registered off-site. 664 6.6. Mobile Aggregated Prefix 666 An aggregation of Mobile Network Prefixes. 668 6.7. Aggregated Home Network 670 The Home Network associated with a Mobile Aggregated Prefix. This 671 Aggregation is advertised as a subnet on the Home Link, and thus used 672 as Home Network for NEMO purposes. 674 6.8. Extended Home Network 676 The network associated with the aggregation of one or more Home 677 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 678 Network that is a subnet, the extended Home Network is an aggregation 679 and is further subnetted. 681 6.9. Virtual Home Network 683 An aggregation of Mobile Network Prefixes that is in turn advertised 684 as the Home Link Prefix. The Extended Home Network and the 685 Aggregated Home Network can be configured as Virtual Home Network. 687 7. Mobility Support Terms 689 7.1. Host Mobility Support 691 Host Mobility Support is a mechanism which maintains session 692 continuity between mobile nodes and their correspondents upon the 693 mobile host's change of point of attachment. It can be achieved 694 using Mobile IPv6 or other mobility support mechanisms. 696 7.2. Network Mobility Support (NEMO Support) 698 Network Mobility Support is a mechanism which maintains session 699 continuity between mobile network nodes and their correspondents upon 700 a mobile router's change of point of attachment. Solutions for this 701 problem are classified into NEMO Basic Support, and NEMO Extended 702 Support. 704 7.3. NEMO Basic Support 706 NEMO Basic Support is a solution to preserve session continuity by 707 means of bi-directional tunneling between MRs and their HAs much like 708 what is done with Mobile IPv6 [4] for mobile nodes when Routing 709 Optimization is not used. Only the HA and the MR are NEMO-enabled. 711 RFC 3963 [5] is the solution specified by the NEMO Working Group for 712 NEMO Basic Support. 714 7.4. NEMO Extended Support 716 NEMO Extended support is to provide the necessary optimization, 717 including routing optimization between arbitrary MNNs and CNs. 719 7.5. NEMO Routing Optimization (NEMO RO) 721 The term "Route Optimization" is accepted in a broader sense than 722 already defined for IPv6 Host Mobility in [4] to loosely refer to any 723 approach that optimizes the transmission of packets between a Mobile 724 Network Node and a Correspondent Node. 726 For more information about NEMO Route Optimization in the NEMO 727 context, see the problem statement [8] and the solution space 728 analysis [9]. 730 7.6. MRHA Tunnel 732 The bi-directional tunnel between a Mobile Router and its Home Agent. 734 7.7. Pinball Route 736 A pinball route refers to the non-direct path taken by packets, which 737 are routed via one or more Home Agents, as they transit between a 738 Mobile Network Node and a Correspondent Node. 740 A packet following a pinball route would appear like a ball bouncing 741 off one or more Home Agents before reaching its final destination. 743 8. Security Considerations 745 As this document only provides terminology and describes neither a 746 protocol nor an implementation or a procedure, there are no security 747 considerations associated with it. 749 9. IANA Considerations 751 This document requires no IANA actions. 753 10. Acknowledgments 755 The material presented in this document takes most of the text from 756 internet-drafts initially submitted to the former MobileIP WG and the 757 MONET BOF and was published as part of a PhD dissertation [11]. The 758 authors would therefore like to thank both Motorola Labs Paris and 759 INRIA (PLANETE team, Grenoble, France) where this terminology 760 originated, for the opportunity to bring it to the IETF, and 761 particularly Claude Castelluccia for his advice, suggestions, and 762 direction, Alexandru Petrescu and Christophe Janneteau. We also 763 acknowledge input from Erik Nordmark, Hesham Soliman, Mattias 764 Petterson, Marcelo Bagnulo, TJ Kniveton, Masafumi Watari, Chan-Wah 765 Ng, JinHyeock Choi and numerous other people from the NEMO Working 766 Group. The Home Network Model section is contributed by Pascal 767 Thubert, Ryuji Wakikawa and Vijay Devaparalli. 769 11. References 771 11.1. Normative References 773 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 774 draft-ietf-nemo-requirements-06 (work in progress), 775 November 2006. 777 [2] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 778 RFC 2460, December 1998. 780 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 781 RFC 3753, June 2004. 783 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 784 IPv6", RFC 3775, June 2004. 786 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 787 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 788 January 2005. 790 [6] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in 791 Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 792 (work in progress), June 2006. 794 [7] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 795 Network Models", draft-ietf-nemo-home-network-models-06 (work in 796 progress), February 2006. 798 [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 799 Route Optimization Problem Statement", 800 draft-ietf-nemo-ro-problem-statement-03 (work in progress), 801 September 2006. 803 [9] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 804 Route Optimization Solution Space Analysis", 805 draft-ietf-nemo-ro-space-analysis-03 (work in progress), 806 September 2006. 808 11.2. Informative References 810 [10] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 811 Multihoming Architectures", RFC 3582, August 2003. 813 [11] Ernst, T., "Network Mobility Support in IPv6", PhD's Thesis. , 814 Universite Joseph Fourier, Grenoble, France , October 2001. 816 Authors' Addresses 818 Thierry Ernst 819 INRIA 820 INRIA Rocquencourt 821 Domaine de Voluceau B.P. 105 822 Le Chesnay, 78153 823 France 825 Phone: +33 1 39 63 59 30 826 Fax: +33 1 39 63 54 91 827 Email: thierry.ernst@inria.fr 828 URI: http://www-rocq.inria.fr/imara 830 Hong-Yon Lach 831 Motorola Labs Paris 832 Espace Technologique - Saint Aubin 833 Gif-sur-Yvette Cedex, 91 193 834 France 836 Phone: +33-169-35-25-36 837 Fax: 838 Email: hong-yon.lach@motorola.com 839 URI: 841 Full Copyright Statement 843 Copyright (C) The Internet Society (2006). 845 This document is subject to the rights, licenses and restrictions 846 contained in BCP 78, and except as set forth therein, the authors 847 retain all their rights. 849 This document and the information contained herein are provided on an 850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 852 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 853 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 854 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 857 Intellectual Property 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. Information 865 on the procedures with respect to rights in RFC documents can be 866 found in BCP 78 and BCP 79. 868 Copies of IPR disclosures made to the IETF Secretariat and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementers or users of this 872 specification can be obtained from the IETF on-line IPR repository at 873 http://www.ietf.org/ipr. 875 The IETF invites any interested party to bring to its attention any 876 copyrights, patents or patent applications, or other proprietary 877 rights that may cover technology that may be required to implement 878 this standard. Please address the information to the IETF at 879 ietf-ipr@ietf.org. 881 Acknowledgment 883 Funding for the RFC Editor function is provided by the IETF 884 Administrative Support Activity (IASA).