idnits 2.17.1 draft-ietf-nemo-terminology-04.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 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 897. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (October 24, 2005) is 6758 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '6') == Outdated reference: A later version (-03) exists of draft-ietf-nemo-ro-problem-statement-01 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-04 Summary: 8 errors (**), 0 flaws (~~), 6 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 Keio University / WIDE 4 Expires: April 27, 2006 H-Y. Lach 5 Motorola Labs 6 October 24, 2005 8 Network Mobility Support Terminology 9 draft-ietf-nemo-terminology-04 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 April 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines a terminology for discussing network mobility 43 issues and solution requirements. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Architectural Components . . . . . . . . . . . . . . . . . . . 5 50 2.1. Mobile Network (NEMO) . . . . . . . . . . . . . . . . . . 6 51 2.2. Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 6 52 2.3. Egress Interface (E-face) . . . . . . . . . . . . . . . . 7 53 2.4. Ingress Interface (I-face) . . . . . . . . . . . . . . . . 7 54 2.5. Mobile Network Prefix (MNP) . . . . . . . . . . . . . . . 7 55 2.6. NEMO-link . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.7. Mobile Network Node (MNN) . . . . . . . . . . . . . . . . 7 57 2.8. Correspondent Node (CN) . . . . . . . . . . . . . . . . . 7 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) . . . . . . . . . . . . . . . . . . 9 63 3.2. Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . 9 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 77 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. Multihomed host or MNN . . . . . . . . . . . . . . . . . . 13 79 5.2. Multihomed Mobile Router . . . . . . . . . . . . . . . . . 13 80 5.3. Multihomed Mobile Network (multihomed-NEMO) . . . . . . . 14 81 5.4. Nested Multihomed Mobile Network . . . . . . . . . . . . . 14 82 5.5. Illustration . . . . . . . . . . . . . . . . . . . . . . . 14 84 6. Home Network Model Terms . . . . . . . . . . . . . . . . . . . 17 85 6.1. Home Link . . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.2. Home Network . . . . . . . . . . . . . . . . . . . . . . . 17 87 6.3. Home Address . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.4. Mobile Home Network . . . . . . . . . . . . . . . . . . . 17 89 6.5. Distributed Home Network . . . . . . . . . . . . . . . . . 17 90 6.6. Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . 17 91 6.7. Aggregated Home Network . . . . . . . . . . . . . . . . . 17 92 6.8. Extended Home Network . . . . . . . . . . . . . . . . . . 18 93 6.9. Virtual Home Network . . . . . . . . . . . . . . . . . . . 18 95 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 19 96 7.1. Host Mobility Support . . . . . . . . . . . . . . . . . . 19 97 7.2. Network Mobility Support (NEMO Support) . . . . . . . . . 19 98 7.3. NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 19 99 7.4. NEMO Extended Support . . . . . . . . . . . . . . . . . . 19 100 7.5. MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 19 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 112 Appendix A. Change Log From Earlier Versions . . . . . . . . . . 24 113 A.1. Changes since draft-nemo-terminology-03.txt . . . . . . . 24 114 A.2. Changes since draft-nemo-terminology-02.txt . . . . . . . 24 115 A.3. Changes since draft-nemo-terminology-01.txt . . . . . . . 24 116 A.4. Changes since draft-nemo-terminology-00.txt . . . . . . . 25 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 119 Intellectual Property and Copyright Statements . . . . . . . . . . 27 121 1. Introduction 123 Network mobility support is concerned with managing the mobility of 124 an entire network. This arises when a router connecting a network to 125 the Internet dynamically changes its point of attachment to the fixed 126 infrastructure, thereby causing the reachability of the entire 127 network to be changed in relation to the fixed Internet topology. 128 Such a network is referred to as a mobile network. Without 129 appropriate mechanisms to support network mobility, sessions 130 established between nodes in the mobile network and the global 131 Internet cannot be maintained after the mobile router changes its 132 point of attachment. As a result, existing sessions would break and 133 connectivity to the global Internet would be lost. 135 This document defines the specific terminology needed to describe the 136 problem space, the design goals [1], and the solutions for network 137 mobility support. This terminology aims to be consistent with the 138 usual IPv6 terminology [2] and the generic mobility-related terms 139 already defined in the Mobility Related Terminology [3] and in the 140 Mobile IPv6 specification [4]. Some terms introduced in this 141 document may only be useful for defining the problem scope and 142 functional requirements of network mobility support. 144 Note that the abbreviation NEMO stands for either "a NEtwork that is 145 MObile" or "NEtwork MObility". The former (see Section 2.1) is used 146 as a noun, e.g. "a NEMO" meaning "a mobile network". The latter (see 147 Section 7) refers to the concept of "network mobility" as in "NEMO 148 Basic Support" and is also the working group's name. 150 Section 2 introduces terms to define the architecture while terms 151 needed to emphasize the distinct functionalities of those 152 architectural components are described in Section 3. Section 4, 153 Section 5 and Section 6 describe terms pertaining to nested mobility, 154 multihoming and different configurations of mobile networks at home, 155 respectively. The different types of mobility are defined in 156 Section 7. The last section lists miscellaneous terms which do not 157 fit in any other section. 159 2. Architectural Components 161 A mobile network is composed of one or more mobile IP-subnets (NEMO- 162 link) and is viewed as a single unit. This network unit is connected 163 to the Internet by means of one or more mobile routers (MRs). Nodes 164 behind the MR (referred to as MNNs) primarily comprise fixed nodes 165 (nodes unable to change their point of attachment while maintaining 166 ongoing sessions), and possibly mobile nodes (nodes able to change 167 their point of attachment while maintaining ongoing sessions). In 168 most cases, the internal structure of the mobile network will be 169 stable (no dynamic change of the topology), but this is not always 170 true. 172 Figure 1 illustrates the architectural components involved in network 173 mobility and defined in the following paragraphs: Mobile Router (MR), 174 NEMO-link, Mobile Network Node (MNN), "ingress interface", "egress 175 interface", and Correspondent Node (CN). The other terms "access 176 router" (AR), "Fixed Node (FN)", "Mobile Node (MN)", "home agent" 177 (HA), "home link" and "foreign link" are not terms specific to 178 network mobility and thus are defined in [3]. 180 _ 181 CN ->|_|-| Internet 182 | _____ 183 |-| | |<- home link 184 _ | |-| _ | _ 185 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent) 186 | \ | _ 187 foreign link ->| ^ |-|_|<- MR (Mobile Router) 188 .. AR (access ___|___ 189 router) _| |_ 190 |_| |_| 191 ^ ^ 192 MNN1 MNN2 194 Figure 1: Mobile Network on the Home Link 196 Figure 2 shows a single mobile subnetwork. Figure 3 illustrates a 197 larger mobile network comprising several subnetworks, attached to a 198 foreign link. 200 _ 201 CN ->|_|-| 202 | _____ 203 _ | |-| | |<- home link 204 |_|-| _ | _ | |-| _ | _ 205 2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA 206 |_|-| . | \ \ | 207 | . |<- foreign ^AR 208 single NEMO-link -> . link 209 . 210 ^ MR 212 Figure 2: Single Mobile Subnetwork on a Foreign Link 214 At the network layer, MRs get access to the global Internet from the 215 Access Router(s) (AR) on a visited link. An MR maintains the 216 Internet connectivity for the entire mobile network. A given MR has 217 one or more egress interface and one or more ingress interface. When 218 forwarding a packet to the Internet, the packet is transmitted 219 upstream through one of the MR's egress interfaces to the AR; when 220 forwarding a packet from the AR down to the mobile network, the 221 packet is transmitted downstream through one of the MR's ingress 222 interfaces. 224 2.1. Mobile Network (NEMO) 226 As defined in [3]: 228 An entire network, moving as a unit, which dynamically changes its 229 point of attachment to the Internet and thus its reachability in the 230 topology. The mobile network is composed of one or more IP-subnets 231 and is connected to the global Internet via one or more Mobile 232 Routers (MR). The internal configuration of the mobile network is 233 assumed to be relatively stable with respect to the MR. 235 Re-arrangement of the mobile network and changing the attachment 236 point of the egress interface to the foreign link are orthogonal 237 processes and do no affect each other. 239 2.2. Mobile Router (MR) 241 As defined in [3]: 243 A router capable of changing its point of attachment to the Internet, 244 moving from one link to another link. The MR is capable of 245 forwarding packets between two or more interfaces, and possibly 246 running a dynamic routing protocol modifying the state by which it 247 does packet forwarding. 249 An MR acts as a gateway between an entire mobile network and the rest 250 of the Internet, and has one or more egress interface and one or more 251 ingress interface. Packets forwarded upstream to the rest of the 252 Internet are transmitted through one of the MR's egress interfaces; 253 packets forwarded downstream to the mobile network are transmitted 254 through one of the MR's ingress interfaces. 256 2.3. Egress Interface (E-face) 258 As defined in [3]: 260 The network interface of an MR attached to the home link if the MR is 261 at home, or attached to a foreign link if the MR is in a foreign 262 network. 264 2.4. Ingress Interface (I-face) 266 As defined in [3]: 268 The interface of an MR attached to a link inside the mobile network. 270 2.5. Mobile Network Prefix (MNP) 272 As defined in [3]: 274 A bit string that consists of some number of initial bits of an IP 275 address which identifies the entire mobile network within the 276 Internet topology. All nodes in a mobile network necessarily have an 277 address containing this prefix. 279 2.6. NEMO-link 281 A link (subnet) which comprises, or is located within, the mobile 282 network. 284 2.7. Mobile Network Node (MNN) 286 As defined in [3]: 288 Any node (host or router) located within a mobile network, either 289 permanently or temporarily. A Mobile Network Node may either be a 290 fixed node (LFN) or a mobile node (VMN or LMN). 292 2.8. Correspondent Node (CN) 294 Any node that is communicating with one or more MNNs. A CN could be 295 either located within a fixed network or within another mobile 296 network, and could be either fixed or mobile. 298 2.9. Correspondent Router (CR) 300 This refers to the entity which is capable of terminating a Route 301 Optimization [7] session on behalf of a Correspondent Node. 303 2.10. Correspondent Entity (CE) 305 This refers to the entity which a Mobile Router or Mobile Network 306 Node attempts to establish a Route Optimization session with. 307 Depending on the Route Optimization approach [7], the Correspondent 308 Entity maybe a Correspondent Node or Correspondent Router. 310 3. Functional Terms 312 _ 313 CN->|_|-| 314 NEMO-link 1->| | _____ 315 _ | |-| | |<- home link 316 MNN1->|_|-|'i'_'e'| _ | |-| _ | _ 317 |--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA 318 'i'| | \ | 319 ____|__ | 320 NEMO-link 2-^ _| . |<- foreign 321 |_| . link 322 MNN2 -^ . 323 ^ 324 MR 326 'i': MR's ingress interface 327 'e': MR's egress interface 329 Figure 3: Larger Mobile Network with 2 subnets 331 Within the term Mobile Network Node (MNN), we can distinguish between 332 Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN) and Local Mobile 333 Nodes (LMN). The distinction is a property of how different types of 334 nodes can move in the topology and is necessary to discuss issues 335 related to mobility management and access control; however it does 336 not imply that network mobility or host mobility should be handled 337 differently. Nodes are classified according to their function and 338 capabilities with the rationale that nodes with different properties 339 may have different requirements. 341 3.1. Local Fixed Node (LFN) 343 A fixed node (FN), either a host or a router, that belongs to the 344 mobile network and is unable to change its point of attachment while 345 maintaining ongoing sessions. Its address is located within an MNP. 347 3.2. Visiting Mobile Node (VMN) 349 Either a mobile node (MN) or a mobile router (MR), assigned to a home 350 link that doesn't belong to the mobile network and which is able to 351 change its point of attachment while maintaining ongoing sessions. A 352 VMN that is temporarily attached to a NEMO-link (used as a foreign 353 link) obtains an address on that link (i.e. the address is taken from 354 an MNP). Figure 4 illustrates a VMN changing its point of attachment 355 from its HA to within a mobile network. 357 3.3. Local Mobile Node (LMN) 359 Either a mobile node (MN) or a mobile router (MR), assigned to a home 360 link belonging to the mobile network and which is able to change its 361 point of attachment while maintaining ongoing sessions. Its address 362 is taken from an MNP. Figure 4 illustrates a LMN changing its point 363 of attachment within the mobile network. 365 3.4. NEMO-enabled node (NEMO-node) 367 A node that has been extended with network mobility support 368 capabilities as described in NEMO specifications. 370 In NEMO Basic Support [5], only the MR and the HA are NEMO-enabled. 372 For NEMO Extended Support, details of the capabilities are not known 373 yet at the time of this writing, but NEMO-enabled nodes may be 374 expected to implement some sort of Route Optimization. 376 NEMO-link 1 | _ +++++++<<<+++++++++++ 377 |-|_|-| + + 378 ++<<|_|-| \ |--|_|--|-|_|-|_____|-|-|_| 383 | | ^ | \ | HA_VMN 384 VMN _ | MR | 385 |_|-| |-VMN 386 ^ NEMO-link 2 + 387 + + 388 ++++++++<<<+++++++++++++++++++++++++ 390 +++>+++ = changing point of attachment 392 Figure 4: LFN vs LMM vs VMN 394 3.5. MIPv6-enabled (MIPv6-node) 396 A node which has been extended with host mobility support 397 capabilities as defined in the Mobile IPv6 specification [4]. 399 4. Nested Mobility Terms 401 Nested mobility occurs when there is more than one level of mobility, 402 i.e. when a mobile network acts as an access network and allows 403 visiting nodes to attach to it. There are two cases of nested 404 mobility: 406 o The attaching node is a single VMN (see Figure 4). For instance, 407 when a passenger carrying a mobile phone gets Internet access from 408 the public access network deployed on a bus. 410 o The attaching node is a MR with nodes behind it, i.e. a mobile 411 network (see Figure 5). For instance, when a passenger carrying a 412 PAN gets Internet access from the public access network deployed 413 on a bus. 415 For the second case, we introduce the following terms: 417 4.1. Nested Mobile Network (nested-NEMO) 419 A mobile network is said to be nested when a mobile network (sub- 420 NEMO) is attached to a larger mobile network (parent-NEMO). The 421 aggregated hierarchy of mobile networks becomes a single nested 422 mobile network (see Figure 5). 424 4.2. root-NEMO 426 The mobile network at the top of the hierarchy connecting the 427 aggregated nested mobile networks to the Internet (see Figure 5). 429 4.3. parent-NEMO 431 The upstream mobile network providing Internet access to another 432 mobile network further down the hierarchy (see Figure 5). 434 4.4. sub-NEMO 436 The downstream mobile network attached to another mobile network up 437 in the hierarchy. It becomes subservient of the parent-NEMO. The 438 sub-NEMO is getting Internet access through the parent-NEMO and does 439 not provide Internet access to the parent-NEMO (see Figure 5). 441 4.5. root-MR 443 The MR(s) of the root-NEMO used to connect the nested mobile network 444 to the fixed Internet (see Figure 5). Note: was referred to as 445 "TMLR" (Top-Level Mobile Router) in former versions of this document 446 . 448 4.6. parent-MR 450 The MR(s) of the parent-NEMO. 452 4.7. sub-MR 454 The MR(s) of the sub-NEMO which is connected to a parent-NEMO 456 _____ 457 _ | _ | | 458 _ |-|_|-| _ |-|_|-|-| |-| _ 459 _ |-|_|-| \ |-|_|-| \ | |_____| | _ |-|_| 460 _ |-|_|-| | | | |-|_|-| 461 |_|-| \ | \ | 462 | 464 MNN AR sub-MR AR root-MR AR AR HA 466 <--------------><----------><----><---------><--------> 467 sub-NEMO root-NEMO fl Internet Home Network 469 Figure 5: Nested Mobility: a sub-NEMO attached to a larger mobile 470 network 472 5. Multihoming Terms 474 Multihoming, as currently defined by the IETF, covers site- 475 multihoming [8] and host multihoming. We enlarge this terminology to 476 include "multihomed mobile router" and "multihomed mobile network". 477 The specific configurations and issues pertaining to multihomed 478 mobile networks are covered in [9]. 480 5.1. Multihomed host or MNN 482 A host (e.g. an MNN) is multihomed when it has several IPv6 addresses 483 to choose between, i.e. in the following cases when it is either: 485 Multi-prefixed: multiple prefixes are advertised on the link(s) 486 the host is attached to, or 488 Multi-interfaced: the host has multiple interfaces to choose 489 between, on the same link or not. 491 5.2. Multihomed Mobile Router 493 From the definition of a multihomed host, it follows that a mobile 494 router is multihomed when it has several IPv6 addresses to choose 495 between, i.e. in the following cases when the MR is either: 497 Multi-prefixed: multiple prefixes are advertised on the link(s) an 498 MR's egress interface is attached to, or. 500 Multi-interfaced: the MR has multiple egress interfaces to choose 501 between, on the same link or not (see Figure 6). 503 _____ 504 _ _ | | 505 |_|-| _ |-|_|-| |-| _ 506 _ |-|_|=| \ |_____| | _ |-|_| 507 |_|-| | |-|_|-| 508 \ | 509 MNNs MR AR Internet AR HA 511 Figure 6: Multihoming: MR with multiple E-faces 513 5.3. Multihomed Mobile Network (multihomed-NEMO) 515 A mobile network is multihomed when either a MR is multihomed or 516 there are multiple MRs to choose between, or multiple prefixes are 517 advertised in the mobile network. 519 MR1 520 _ | 521 _ |-|_|-| _____ 522 |_|-| |-| | 523 MNNs _ | | |-| _ 524 |_|-| _ |-|_____| | _ |-|_| 525 |-|_|-| |-|_|-| 526 | | 527 MR2 529 Figure 7: Multihoming: Single NEMO-link with Multiple MRs 531 5.4. Nested Multihomed Mobile Network 533 A nested mobile network is multihomed when either a root-MR is 534 multihomed or there are multiple root-MRs to choose between or 535 multiple prefixes are advertised in the nested mobile network. 537 5.5. Illustration 539 Figure 6 and Figure 7 show two examples of multihomed mobile 540 networks. Figure 8 shows two independent mobile networks. NEMO-1 is 541 single-homed to the Internet through MR1. NEMO-2 is multihomed to 542 the Internet through MR2a and MR2b. Both mobile networks offer 543 access to visiting nodes and networks through an AR. 545 Let's consider the two following nested scenarios in Figure 8: 547 Scenario 1: What happens when MR2a's egress interface is attached to 548 AR1 ? 550 * NEMO-2 becomes subservient of NEMO-1 552 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 553 the aggregated nested mobile network 555 * NEMO-2 becomes the sub-NEMO 557 * MR1 is the root-MR for the aggregated nested mobile network 559 * MR2a is a sub-MR in the aggregated nested mobile network 561 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 563 * The aggregated nested mobile network is not multihomed, since 564 NEMO-2 cannot be used as a transit network for NEMO-1 566 Scenario 2: What happens when MR1's egress interface is attached to 567 AR2 ? 569 * NEMO-1 becomes subservient of NEMO-2 571 * NEMO-1 becomes the sub-NEMO 573 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the root- 574 NEMO for the aggregated nested mobile network 576 * MR2a and MR2b are both root-MRs for the aggregated nested 577 mobile network 579 * MR1 is a sub-MR in the aggregated nested mobile network 581 * NEMO-1 is not multihomed 583 * The aggregated nested mobile network is multihomed 585 _ | _ | 586 |_|-|-|_|-| _ _____ 587 NEMO-1 MNNs _ | MR1 |-|_|-| | 588 |_|-| ARx | |-| _ 589 AR1 \ | | _ | | | _ |-|_| 590 _ |-|_|-| | |-|_|-| 591 _ |-|_|-| ARy | | | 592 |_|-| MR2a _ | | 593 NEMO-2 MNNs _ | |-|_|-| | 594 |_|-| _ | ARz |_____| 595 \ |-|_|-| 596 AR2 MR2b 598 Figure 8: Nested Multihomed NEMO 600 6. Home Network Model Terms 602 The terms in this section are useful to describe the possible 603 configurations of mobile networks at the home. Such configurations 604 are detailed in [6] 606 6.1. Home Link 608 The link attached to the interface at the Home Agent on which the 609 Home Prefix is configured. The interface can be a virtual interface, 610 in which case the Home Link is a Virtual Home Link. 612 6.2. Home Network 614 The Network formed by the application of the Home Prefix to the Home 615 Link. With NEMO, the concept of Home Network is extended as 616 explained below. 618 6.3. Home Address 620 With Mobile IPv6, a Home Address is derived from the Home Network 621 prefix. This is generalized in NEMO, with some limitations: A Home 622 Address can be derived either from the Home Network or from one of 623 the Mobile Router's MNPs. 625 6.4. Mobile Home Network 627 A Mobile Network that hosts a Home Agent and mobile nodes. The 628 Mobile Network serves as the Home Network for the mobile nodes in the 629 Mobile Network. The MR that owns the MNP acts as the Home Agent for 630 the Mobile Home Network. 632 6.5. Distributed Home Network 634 A Distributed Home Network is a collection of geographically 635 distributed Home Networks each served by a Home Agent. The same home 636 prefix is advertised in all the Home Networks. The distributed Home 637 Networks maybe connected using a mesh of IPsec protected tunnels. 639 6.6. Mobile Aggregated Prefix 641 An aggregation of Mobile Network Prefixes that is in turn advertised 642 as the Home Link Prefix. 644 6.7. Aggregated Home Network 646 The Home Network associated with a Mobile Aggregated Prefix. This 647 Aggregation is advertised as a subnet on the Home Link, and thus used 648 as Home Network for NEMO purposes. 650 6.8. Extended Home Network 652 The network associated with the aggregation of one or more Home 653 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 654 Network that is a subnet, the extended Home Network is an aggregation 655 and is further subnetted. 657 6.9. Virtual Home Network 659 An aggregation of Mobile Network Prefixes that is in turn advertised 660 as the Home Link Prefix. The Extended Home Network and the 661 Aggregated Home Network can be configured as Virtual Home Network. 663 7. Mobility Support Terms 665 7.1. Host Mobility Support 667 Host Mobility Support is a mechanism which maintains session 668 continuity between mobile nodes and their correspondents upon the 669 mobile host's change of point of attachment. It can be achieved 670 using Mobile IPv6 or other mobility support mechanisms. 672 7.2. Network Mobility Support (NEMO Support) 674 Network Mobility Support is a mechanism which maintains session 675 continuity between mobile network nodes and their correspondents upon 676 a mobile router's change of point of attachment. Solutions for this 677 problem are classified into NEMO Basic Support, and NEMO Extended 678 Support. 680 7.3. NEMO Basic Support 682 NEMO Basic Support is a solution to preserve session continuity by 683 means of bi-directional tunneling between MRs and their HAs much like 684 what is done with Mobile IPv6 [4] for mobile nodes when Routing 685 Optimization is not used. Only the HA and the MR are NEMO-enabled. 686 The solution for doing this is solely specified in [5]. 688 7.4. NEMO Extended Support 690 NEMO Extended support is to provide the necessary optimization, 691 including routing optimization between arbitrary MNNs and CNs. 693 7.5. MRHA Tunnel 695 The bi-directional tunnel between a Mobile Router and its Home Agent. 697 8. Security Considerations 699 As this document only provides terminology and describes neither a 700 protocol nor an implementation or a procedure, there are no security 701 considerations associated with it. 703 9. IANA Considerations 705 This document requires no IANA actions. 707 10. Acknowledgments 709 The material presented in this document takes most of the text from 710 internet-drafts submitted to the former MobileIP WG and the MONET 711 BOF. The authors would therefore like to thank both Motorola Labs 712 Paris and INRIA (PLANETE team, Grenoble, France) where this 713 terminology originated, for the opportunity to bring it to the IETF, 714 and particularly Claude Castelluccia for his advice, suggestion, and 715 direction, Alexandru Petrescu and Christophe Janneteau. We also 716 acknowledge input from Hesham Soliman, Mattias Petterson, Marcelo 717 Bagnulo, TJ Kniveton and numerous other people from the NEMO Working 718 Group. The Home Network Model section is contributed by Pascal 719 Thubert, Ryuji Wakikawa and Vijay Devaparalli. 721 11. References 723 11.1. Normative References 725 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 726 draft-ietf-nemo-requirements-05 (work in progress), 727 October 2005. 729 [2] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 730 IETF RFC 2460, December 1998. 732 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 733 RFC 3753, June 2004. 735 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 736 IPv6", RFC 3775, June 2004. 738 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 739 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 740 January 2005. 742 [6] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 743 Network Models", draft-ietf-nemo-home-network-models-05 (work in 744 progress), June 2005. 746 11.2. Informative References 748 [7] Ng, C., "Network Mobility Route Optimization Problem Statement", 749 draft-ietf-nemo-ro-problem-statement-01 (work in progress), 750 October 2005. 752 [8] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 753 Multihoming Architectures", RFC 3582, August 2003. 755 [9] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 756 Multihoming in Network Mobility Support", 757 draft-ietf-nemo-multihoming-issues-04 (work in progress), 758 October 2005. 760 Appendix A. Change Log From Earlier Versions 762 The discussions behind the changes in the lattest versions of this 763 documents are reflected in the "issue" web page: 764 http://www.sfc.wide.ad.jp/~ernst/nemo/ 766 A.1. Changes since draft-nemo-terminology-03.txt 768 Updated the Home Network Model section with new definitions provided 769 by Vijay 771 Added definitions of CR and CE as suggested by the RO PB Statement 772 and Analysis authors [7] 774 A.2. Changes since draft-nemo-terminology-02.txt 776 - Issue A18: Redesigned Figure 3 778 - Issue A22: The follolwing comment added in the definition of 779 "Mobile Network": "Re-arrangement of the mobile network and changing 780 the attachment point of the egress interface to the foreign link are 781 orthogonal processes and do no affect each other." (as suggested by 782 TJ) 784 - Issue A23: Clarified in definition of "NEMO-link" that the link may 785 comprise the mobile network: "A link (subnet) which comprises, or is 786 located within, the mobile network." (as suggested by TJ) 788 - Issue A24: Removed definition of CR (as suggested by TJ) 790 - Issue A25: Removed the miscellaneous terms "Idle MNN" and "Idle 791 mobile network" (as suggested by TJ) 793 - Issue A26: English brush up. 795 A.3. Changes since draft-nemo-terminology-01.txt 797 - Shorten abstract. 799 - Reshaped some figures. 801 - LFN, VMN, LMN: said that the node is able/unable to move while 802 maintaining/not maintaining ongoing sessions. Text already 803 appareared in the document, but not in the definition itself. 805 - NEMO-enabled: said that MR and HA are the only NEMO-enabled nodes 806 in NEMO Basic Support 807 - Removed "NEMO-enabled MR" as this definition is self-contained into 808 "NEMO-enabled Node" 810 - Rephrased the definition of "multihomed host", "multihomed router", 811 "multihomed mobile network" and removed the terms multi-addressed and 812 multi-sited, multi-rooted-NEMO, etc. Such terms were not so useful, 813 and somewhat too long. 815 - Added the case "multiple MNPs are advertised" to the definition of 816 mobile network 818 - Copy-pasted terms defined from RFC 3753 so that the document is 819 self-contained 821 - Updated References 823 - Added new term "Correspondent Router" 825 - Permanently removed NEMO-Prefix. Only MNP will be used 827 - Added terms "Mobile Home Network" and "Distributed Home Network" in 828 the Home Network Model section. These 2 terms were provided by 829 Pascal Thubert on July 30th 2004 831 A.4. Changes since draft-nemo-terminology-00.txt 833 - NEMO will be used either as the concept for NEtwork MObility and a 834 noun meaning "NEtwork that is MObile" 836 - Deprecated TMLR and MONET. 838 - Added NEMO-prefix, NEMO-link, NEMO-enabled MR. 840 - Precision that IP address of LFN, LMN, or VMN is taken from a MNP 842 - Added abbreviation E-face (Egress interface) and I-face (Ingress 843 interface) 845 - Some re-ordering of terms, and a few typos. 847 - Added some text from the usage draft-thubert-usages (now home 848 network model draft-ietf-nemo-home-network-models) 850 Authors' Addresses 852 Thierry Ernst 853 Keio University / WIDE 854 Jun Murai Lab., Keio University. 855 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 856 Kawasaki, Kanagawa 212-0054 857 Japan 859 Phone: +81-44-580-1600 860 Fax: +81-44-580-1437 861 Email: ernst@sfc.wide.ad.jp 862 URI: http://www.sfc.wide.ad.jp/~ernst/ 864 Hong-Yon Lach 865 Motorola Labs Paris 866 Espace Technologique - Saint Aubin 867 Gif-sur-Yvette Cedex, 91 193 868 France 870 Phone: +33-169-35-25-36 871 Fax: 872 Email: hong-yon.lach@motorola.com 873 URI: 875 Intellectual Property Statement 877 The IETF takes no position regarding the validity or scope of any 878 Intellectual Property Rights or other rights that might be claimed to 879 pertain to the implementation or use of the technology described in 880 this document or the extent to which any license under such rights 881 might or might not be available; nor does it represent that it has 882 made any independent effort to identify any such rights. Information 883 on the procedures with respect to rights in RFC documents can be 884 found in BCP 78 and BCP 79. 886 Copies of IPR disclosures made to the IETF Secretariat and any 887 assurances of licenses to be made available, or the result of an 888 attempt made to obtain a general license or permission for the use of 889 such proprietary rights by implementers or users of this 890 specification can be obtained from the IETF on-line IPR repository at 891 http://www.ietf.org/ipr. 893 The IETF invites any interested party to bring to its attention any 894 copyrights, patents or patent applications, or other proprietary 895 rights that may cover technology that may be required to implement 896 this standard. Please address the information to the IETF at 897 ietf-ipr@ietf.org. 899 Disclaimer of Validity 901 This document and the information contained herein are provided on an 902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 904 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 905 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 906 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 909 Copyright Statement 911 Copyright (C) The Internet Society (2005). This document is subject 912 to the rights, licenses and restrictions contained in BCP 78, and 913 except as set forth therein, the authors retain all their rights. 915 Acknowledgment 917 Funding for the RFC Editor function is currently provided by the 918 Internet Society.