idnits 2.17.00 (12 Aug 2021) /tmp/idnits30180/draft-ietf-nemo-terminology-05.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 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1002. ** 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 (March 6, 2006) is 5920 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: draft-ietf-nemo-requirements has been published as RFC 4886 ** 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: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '6') == Outdated reference: draft-ietf-nemo-home-network-models has been published as RFC 4887 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '7') == Outdated reference: draft-ietf-nemo-ro-problem-statement has been published as RFC 4888 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-ro-problem-statement (ref. '8') == Outdated reference: draft-ietf-nemo-ro-space-analysis has been published as RFC 4889 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-ro-space-analysis (ref. '9') Summary: 11 errors (**), 0 flaws (~~), 7 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: September 7, 2006 H-Y. Lach 5 Motorola Labs 6 March 6, 2006 8 Network Mobility Support Terminology 9 draft-ietf-nemo-terminology-05 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 September 7, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 Subnet . . . . . . . . . . . . . . . . . . . . . . 7 52 2.3. Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 7 53 2.4. Egress Interface . . . . . . . . . . . . . . . . . . . . . 7 54 2.5. Ingress Interface . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 17 93 6.7. Aggregated Home Network . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . 19 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 Appendix A. Change Log From Earlier Versions . . . . . . . . . . 25 117 A.1. Changes since draft-nemo-terminology-04.txt . . . . . . . 25 118 A.2. Changes since draft-nemo-terminology-03.txt . . . . . . . 26 119 A.3. Changes since draft-nemo-terminology-02.txt . . . . . . . 26 120 A.4. Changes since draft-nemo-terminology-01.txt . . . . . . . 26 121 A.5. Changes since draft-nemo-terminology-00.txt . . . . . . . 27 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 124 Intellectual Property and Copyright Statements . . . . . . . . . . 29 126 1. Introduction 128 Network mobility support is concerned with managing the mobility of 129 an entire network. This arises when a router connecting a network to 130 the Internet dynamically changes its point of attachment to the fixed 131 infrastructure, thereby causing the reachability of the entire 132 network to be changed in relation to the fixed Internet topology. 133 Such a network is referred to as a mobile network. Without 134 appropriate mechanisms to support network mobility, sessions 135 established between nodes in the mobile network and the global 136 Internet cannot be maintained after the mobile router changes its 137 point of attachment. As a result, existing sessions would break and 138 connectivity to the global Internet would be lost. 140 This document defines the specific terminology needed to describe the 141 problem space, the design goals [1], and the solutions for network 142 mobility support. This terminology aims to be consistent with the 143 usual IPv6 terminology [2] and the generic mobility-related terms 144 already defined in the Mobility Related Terminology [3] and in the 145 Mobile IPv6 specification [4]. Some terms introduced in this 146 document may only be useful for defining the problem scope and 147 functional requirements of network mobility support. 149 Note that the abbreviation NEMO stands for either "a NEtwork that is 150 MObile" or "NEtwork MObility". The former (see Section 2.1) is used 151 as a noun, e.g. "a NEMO" meaning "a mobile network". The latter (see 152 Section 7) refers to the concept of "network mobility" as in "NEMO 153 Basic Support" and is also the working group's name. 155 Section 2 introduces terms to define the architecture while terms 156 needed to emphasize the distinct functionalities of those 157 architectural components are described in Section 3. Section 4, 158 Section 5 and Section 6 describe terms pertaining to nested mobility, 159 multihoming and different configurations of mobile networks at home, 160 respectively. The different types of mobility are defined in 161 Section 7. The last section lists miscellaneous terms which do not 162 fit in any other section. 164 2. Architectural Components 166 A mobile network is composed of one or more mobile IP-subnets and is 167 viewed as a single unit. This network unit is connected to the 168 Internet by means of one or more mobile routers (MRs). Nodes behind 169 the MR (referred to as MNNs) primarily comprise fixed nodes (nodes 170 unable to change their point of attachment while maintaining ongoing 171 sessions), and possibly mobile nodes (nodes able to change their 172 point of attachment while maintaining ongoing sessions). In most 173 cases, the internal structure of the mobile network will be stable 174 (no dynamic change of the topology), but this is not always true. 176 Figure 1 illustrates the architectural components involved in network 177 mobility and defined in the following paragraphs: Mobile Router (MR), 178 Mobile Network (NEMO), Mobile Network Node (MNN), "ingress 179 interface", "egress interface", and Correspondent Node (CN). The 180 other terms "access router" (AR), "Fixed Node (FN)", "Mobile Node 181 (MN)", "home agent" (HA), "home link" and "foreign link" are not 182 terms specific to network mobility and thus are defined in [3]. 184 _ 185 CN ->|_|-| Internet 186 | _____ 187 |-| | |<- home link 188 _ | |-| _ | _ 189 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent) 190 | \ | _ 191 foreign link ->| ^ |-|_|<- MR (Mobile Router) 192 .. AR (access ___|___ 193 router) _| |_ 194 |_| |_| 195 ^ ^ 196 MNN1 MNN2 198 Figure 1: Mobile Network on the Home Link 200 Figure 2 shows a single mobile subnet. Figure 3 illustrates a larger 201 mobile network comprising several subnetworks, attached to a foreign 202 link. 204 _ 205 CN ->|_|-| 206 | _____ 207 _ | |-| | |<- home link 208 |_|-| _ | _ | |-| _ | _ 209 2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA 210 |_|-| . | \ \ | 211 | . |<- foreign ^AR 212 mobile subnet -> . link 213 . 214 ^ MR 216 Figure 2: Single Mobile Subnet on a Foreign Link 218 _ 219 CN->|_|-| 220 mobile subnet->| | _____ 221 _ | |-| | |<- home link 222 MNN1->|_|-|'i'_'e'| _ | |-| _ | _ 223 |--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA 224 'i'| | \ | 225 ____|__ | 226 mobile subnet-^ _| . |<- foreign 227 |_| . link 228 MNN2 -^ . 229 ^ 230 MR 232 'i': MR's ingress interface 233 'e': MR's egress interface 235 Figure 3: Larger Mobile Network Made of 2 Mobile Subnets 237 At the network layer, MRs get access to the global Internet from the 238 Access Router(s) (AR) on a visited link. An MR maintains the 239 Internet connectivity for the entire mobile network. A given MR has 240 one or more egress interface and one or more ingress interface. When 241 forwarding a packet to the Internet, the packet is transmitted 242 upstream through one of the MR's egress interfaces to the AR; when 243 forwarding a packet from the AR down to the mobile network, the 244 packet is transmitted downstream through one of the MR's ingress 245 interfaces. 247 2.1. Mobile Network (NEMO) 249 As defined in [3]: 251 An entire network, moving as a unit, which dynamically changes its 252 point of attachment to the Internet and thus its reachability in the 253 topology. The mobile network is composed of one or more IP-subnets 254 and is connected to the global Internet via one or more Mobile 255 Routers (MR). The internal configuration of the mobile network is 256 assumed to be relatively stable with respect to the MR. 258 Re-arrangement of the mobile network and changing the attachment 259 point of the egress interface to the foreign link are orthogonal 260 processes and do no affect each other. 262 2.2. Mobile Subnet 264 A link (subnet) which comprises, or is located within, the mobile 265 network. 267 2.3. Mobile Router (MR) 269 As defined in [3]: 271 A router capable of changing its point of attachment to the Internet, 272 moving from one link to another link. The MR is capable of 273 forwarding packets between two or more interfaces, and possibly 274 running a dynamic routing protocol modifying the state by which it 275 does packet forwarding. 277 An MR acts as a gateway between an entire mobile network and the rest 278 of the Internet, and has one or more egress interface and one or more 279 ingress interface. Packets forwarded upstream to the rest of the 280 Internet are transmitted through one of the MR's egress interfaces; 281 packets forwarded downstream to the mobile network are transmitted 282 through one of the MR's ingress interfaces. 284 2.4. Egress Interface 286 As defined in [3]: 288 The network interface of an MR attached to the home link if the MR is 289 at home, or attached to a foreign link if the MR is in a foreign 290 network. 292 2.5. Ingress Interface 294 As defined in [3]: 296 The interface of an MR attached to a link inside the mobile network. 298 2.6. Mobile Network Prefix (MNP) 300 As defined in [3]: 302 A bit string that consists of some number of initial bits of an IP 303 address which identifies the entire mobile network within the 304 Internet topology. All nodes in a mobile network necessarily have an 305 address containing this prefix. 307 2.7. Mobile Network Node (MNN) 309 As defined in [3]: 311 Any node (host or router) located within a mobile network, either 312 permanently or temporarily. A Mobile Network Node may either be a 313 fixed node (LFN) or a mobile node (VMN or LMN). 315 2.8. Correspondent Node (CN) 317 Any node that is communicating with one or more MNNs. A CN could be 318 either located within a fixed network or within another mobile 319 network, and could be either fixed or mobile. 321 2.9. Correspondent Router (CR) 323 Refers to the entity which is capable of terminating a Route 324 Optimization session on behalf of a Correspondent Node (see also NEMO 325 Route Optimization in Section 7.5). 327 2.10. Correspondent Entity (CE) 329 Refers to the entity which a Mobile Router or Mobile Network Node 330 attempts to establish a Route Optimization session with. Depending 331 on the Route Optimization approach, the Correspondent Entity maybe a 332 Correspondent Node or Correspondent Router (see also NEMO Route 333 Optimization in Section 7.5) 335 3. Functional Terms 337 Within the term Mobile Network Node (MNN), we can distinguish between 338 Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN) and Local Mobile 339 Nodes (LMN). The distinction is a property of how different types of 340 nodes can move in the topology and is necessary to discuss issues 341 related to mobility management and access control; however it does 342 not imply that network mobility or host mobility should be handled 343 differently. Nodes are classified according to their function and 344 capabilities with the rationale that nodes with different properties 345 may have different requirements. 347 Figure 4 illustrates a VMN changing its point of attachment from its 348 home link located outside the mobile network to within a mobile 349 network. The figure also illustrates a LMN changing its point of 350 attachment within the mobile network. 352 mobile subnet 1 | _ +++++++<<<+++++++++++ 353 |-|_|-| + + 354 ++<<|_|-| \ |--|_|--|-|_|-|_____|-|-|_| 359 | | ^ | \ | HA_VMN 360 VMN _ | MR | 361 |_|-| |-VMN 362 ^ mobile subnet 2 + 363 + + 364 ++++++++<<<+++++++++++++++++++++++++ 366 +++>>>+++ = changing point of attachment 368 Figure 4: LFN vs LMM vs VMN 370 In a typical use case of NEMO Basic Support [5], only the MR and the 371 HA are NEMO-enabled. LFNs are not MIPv6-enabled nor NEMO-enabled. 372 On the other hand, a VMN or a LMN acting as a mobile router may be 373 NEMO-enabled whereas a VMN or a LMN acting as a mobile node may be 374 MIPv6-enabled. 376 For NEMO Extended Support, details of the capabilities are not known 377 yet at the time of this writing, but NEMO-enabled nodes may be 378 expected to implement some sort of Route Optimization. 380 3.1. Local Fixed Node (LFN) 382 A fixed node (FN), either a host or a router, that belongs to the 383 mobile network and is unable to change its point of attachment while 384 maintaining ongoing sessions. Its address is taken from an MNP. 386 3.2. Visiting Mobile Node (VMN) 388 Either a mobile node (MN) or a mobile router (MR), assigned to a home 389 link that doesn't belong to the mobile network and which is able to 390 change its point of attachment while maintaining ongoing sessions. A 391 VMN that is temporarily attached to a mobile subnet (used as a 392 foreign link) obtains an address on that subnet (i.e. the address is 393 taken from an MNP). 395 3.3. Local Mobile Node (LMN) 397 Either a mobile node (MN) or a mobile router (MR), assigned to a home 398 link belonging to the mobile network and which is able to change its 399 point of attachment while maintaining ongoing sessions. Its address 400 is taken from an MNP. 402 3.4. NEMO-enabled node (NEMO-node) 404 A node that has been extended with network mobility support 405 capabilities as described in NEMO specifications. 407 3.5. MIPv6-enabled (MIPv6-node) 409 A node which has been extended with host mobility support 410 capabilities as defined in the Mobile IPv6 specification [4]. 412 4. Nested Mobility Terms 414 Nested mobility occurs when there is more than one level of mobility, 415 i.e. when a mobile network acts as an access network and allows 416 visiting nodes to attach to it. There are two cases of nested 417 mobility: 419 o The attaching node is a single VMN (see Figure 4). For instance, 420 when a passenger carrying a mobile phone gets Internet access from 421 the public access network deployed on a bus. 423 o The attaching node is a MR with nodes behind it, i.e. a mobile 424 network (see Figure 5). For instance, when a passenger carrying a 425 PAN gets Internet access from the public access network deployed 426 on a bus. 428 For the second case, we introduce the following terms: 430 4.1. Nested Mobile Network (nested-NEMO) 432 A mobile network is said to be nested when a mobile network (sub- 433 NEMO) is attached to a larger mobile network (parent-NEMO). The 434 aggregated hierarchy of mobile networks becomes a single nested 435 mobile network (see Figure 5). 437 4.2. Root-NEMO 439 The mobile network at the top of the hierarchy connecting the 440 aggregated nested mobile networks to the Internet (see Figure 5). 442 4.3. Parent-NEMO 444 The upstream mobile network providing Internet access to another 445 mobile network further down the hierarchy (see Figure 5). 447 4.4. Sub-NEMO 449 The downstream mobile network attached to another mobile network up 450 in the hierarchy. It becomes subservient of the parent-NEMO. The 451 sub-NEMO is getting Internet access through the parent-NEMO and does 452 not provide Internet access to the parent-NEMO (see Figure 5). 454 4.5. Root-MR 456 The MR(s) of the root-NEMO used to connect the nested mobile network 457 to the fixed Internet (see Figure 5). 459 4.6. Parent-MR 461 The MR(s) of the parent-NEMO. 463 4.7. Sub-MR 465 The MR(s) of the sub-NEMO which is connected to a parent-NEMO 467 4.8. Depth 469 In a nested NEMO indicates the number of sub-MRs a packet has to 470 cross between a MNN and the root-MR. 472 A MNN in the root-NEMO is a depth 1. If there are multiple root- 473 NEMOs, a different depth is computed from each root-MR. 475 _____ 476 _ | _ | | 477 _ |-|_|-| _ |-|_|-|-| |-| _ 478 _ |-|_|-| \ |-|_|-| \ | |_____| | _ |-|_| 479 _ |-|_|-| | | | |-|_|-| 480 |_|-| \ | \ | 481 | 483 MNN AR sub-MR AR root-MR AR AR HA 485 <--------------><----------><----><---------><--------> 486 sub-NEMO root-NEMO fl Internet Home Network 488 Figure 5: Nested Mobility: a sub-NEMO attached to a larger mobile 489 network 491 5. Multihoming Terms 493 Multihoming, as currently defined by the IETF, covers site- 494 multihoming [10] and host multihoming. We enlarge this terminology 495 to include "multihomed mobile router" and "multihomed mobile 496 network". The specific configurations and issues pertaining to 497 multihomed mobile networks are covered in [6]. 499 5.1. Multihomed host or MNN 501 A host (e.g. an MNN) is multihomed when it has several addresses to 502 choose between, i.e. in the following cases when it is either: 504 Multi-prefixed: multiple prefixes are advertised on the link(s) 505 the host is attached to, or 507 Multi-interfaced: the host has multiple interfaces to choose 508 between, on the same link or not. 510 5.2. Multihomed Mobile Router 512 From the definition of a multihomed host, it follows that a mobile 513 router is multihomed when it has several addresses to choose between, 514 i.e. in the following cases when the MR is either: 516 Multi-prefixed: multiple prefixes are advertised on the link(s) an 517 MR's egress interface is attached to, or. 519 Multi-interfaced: the MR has multiple egress interfaces to choose 520 between, on the same link or not (see Figure 6). 522 _____ 523 _ _ | | 524 |_|-| _ |-|_|-| |-| _ 525 _ |-|_|=| \ |_____| | _ |-|_| 526 |_|-| | |-|_|-| 527 \ | 528 MNNs MR AR Internet AR HA 530 Figure 6: Multihoming: MR with multiple E-faces 532 5.3. Multihomed Mobile Network (multihomed-NEMO) 534 A mobile network is multihomed when either a MR is multihomed or 535 there are multiple MRs to choose between (see the corresponding 536 analysis in [6]). 538 MR1 539 _ | 540 _ |-|_|-| _____ 541 |_|-| |-| | 542 MNNs _ | | |-| _ 543 |_|-| _ |-|_____| | _ |-|_| 544 |-|_|-| |-|_|-| 545 | | 546 MR2 548 Figure 7: Multihoming: NEMO with Multiple MRs 550 5.4. Nested Multihomed Mobile Network 552 A nested mobile network is multihomed when either a root-MR is 553 multihomed or there are multiple root-MRs to choose between. 555 5.5. Split NEMO 557 TBD. See the "issue" web page http://www.sfc.wide.ad.jp/~ernst/nemo/ 559 5.6. Illustration 561 Figure 6 and Figure 7 show two examples of multihomed mobile 562 networks. Figure 8 shows two independent mobile networks. NEMO-1 is 563 single-homed to the Internet through MR1. NEMO-2 is multihomed to 564 the Internet through MR2a and MR2b. Both mobile networks offer 565 access to visiting nodes and networks through an AR. 567 Let's consider the two following nested scenarios in Figure 8: 569 Scenario 1: What happens when MR2a's egress interface is attached to 570 AR1 ? 572 * NEMO-2 becomes subservient of NEMO-1 573 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 574 the aggregated nested mobile network 576 * NEMO-2 becomes the sub-NEMO 578 * MR1 is the root-MR for the aggregated nested mobile network 580 * MR2a is a sub-MR in the aggregated nested mobile network 582 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 584 * The aggregated nested mobile network is not multihomed, since 585 NEMO-2 cannot be used as a transit network for NEMO-1 587 Scenario 2: What happens when MR1's egress interface is attached to 588 AR2 ? 590 * NEMO-1 becomes subservient of NEMO-2 592 * NEMO-1 becomes the sub-NEMO 594 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the root- 595 NEMO for the aggregated nested mobile network 597 * MR2a and MR2b are both root-MRs for the aggregated nested 598 mobile network 600 * MR1 is a sub-MR in the aggregated nested mobile network 602 * NEMO-1 is not multihomed 604 * The aggregated nested mobile network is multihomed 605 _ | _ | 606 |_|-|-|_|-| _ _____ 607 NEMO-1 MNNs _ | MR1 |-|_|-| | 608 |_|-| ARx | |-| _ 609 AR1 \ | | _ | | | _ |-|_| 610 _ |-|_|-| | |-|_|-| 611 _ |-|_|-| ARy | | | 612 |_|-| MR2a _ | | 613 NEMO-2 MNNs _ | |-|_|-| | 614 |_|-| _ | ARz |_____| 615 \ |-|_|-| 616 AR2 MR2b 618 Figure 8: Nested Multihomed NEMO 620 6. Home Network Model Terms 622 The terms in this section are useful to describe the possible 623 configurations of mobile networks at the home. For a better 624 understanding of the definitions, the reader is recommended to read 625 [7] where such configurations are detailed 627 6.1. Home Link 629 The link attached to the interface at the Home Agent on which the 630 Home Prefix is configured. The interface can be a virtual interface, 631 in which case the Home Link is a Virtual Home Link. 633 6.2. Home Network 635 The Network formed by the application of the Home Prefix to the Home 636 Link. With NEMO, the concept of Home Network is extended as 637 explained below. 639 6.3. Home Address 641 With Mobile IPv6, a Home Address is derived from the Home Network 642 prefix. This is generalized in NEMO, with some limitations: A Home 643 Address can be derived either from the Home Network or from one of 644 the Mobile Router's MNPs. 646 6.4. Mobile Home Network 648 A Mobile Network that hosts a Home Agent and mobile nodes. The 649 Mobile Network serves as the Home Network for the mobile nodes in the 650 Mobile Network. The MR that owns the MNP acts as the Home Agent for 651 the Mobile Home Network. 653 6.5. Distributed Home Network 655 A Distributed Home Network is a collection of geographically 656 distributed Home Networks each served by a Home Agent. The same home 657 prefix is advertised in all the Home Networks. The distributed Home 658 Networks maybe connected using a mesh of IPsec protected tunnels. 660 6.6. Mobile Aggregated Prefix 662 An aggregation of Mobile Network Prefixes that is in turn advertised 663 as the Home Link Prefix. 665 6.7. Aggregated Home Network 667 The Home Network associated with a Mobile Aggregated Prefix. This 668 Aggregation is advertised as a subnet on the Home Link, and thus used 669 as Home Network for NEMO purposes. 671 6.8. Extended Home Network 673 The network associated with the aggregation of one or more Home 674 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 675 Network that is a subnet, the extended Home Network is an aggregation 676 and is further subnetted. 678 6.9. Virtual Home Network 680 An aggregation of Mobile Network Prefixes that is in turn advertised 681 as the Home Link Prefix. The Extended Home Network and the 682 Aggregated Home Network can be configured as Virtual Home Network. 684 7. Mobility Support Terms 686 7.1. Host Mobility Support 688 Host Mobility Support is a mechanism which maintains session 689 continuity between mobile nodes and their correspondents upon the 690 mobile host's change of point of attachment. It can be achieved 691 using Mobile IPv6 or other mobility support mechanisms. 693 7.2. Network Mobility Support (NEMO Support) 695 Network Mobility Support is a mechanism which maintains session 696 continuity between mobile network nodes and their correspondents upon 697 a mobile router's change of point of attachment. Solutions for this 698 problem are classified into NEMO Basic Support, and NEMO Extended 699 Support. 701 7.3. NEMO Basic Support 703 NEMO Basic Support is a solution to preserve session continuity by 704 means of bi-directional tunneling between MRs and their HAs much like 705 what is done with Mobile IPv6 [4] for mobile nodes when Routing 706 Optimization is not used. Only the HA and the MR are NEMO-enabled. 707 The solution for doing this is solely specified in [5]. 709 7.4. NEMO Extended Support 711 NEMO Extended support is to provide the necessary optimization, 712 including routing optimization between arbitrary MNNs and CNs. 714 7.5. NEMO Routing Optimization (NEMO RO) 716 The term "Route Optimization" is accepted in a broader sense than 717 already defined for IPv6 Host Mobility in [4] to loosely refer to any 718 approach that optimizes the transmission of packets between a Mobile 719 Network Node and a Correspondent Node. 721 For more information about NEMO Route Optimization in the NEMO 722 context, see the problem statement [8] and the solution space 723 analysis [9]. 725 7.6. MRHA Tunnel 727 The bi-directional tunnel between a Mobile Router and its Home Agent. 729 7.7. Pinball Route 731 A pinball route refers to the non-direct path taken by packets, which 732 are routed via one or more Home Agents, as they transit between a 733 Mobile Network Node and a Correspondent Node. 735 A packet following a pinball route would appear like a ball bouncing 736 off one or more home agents before reaching its final destination. 738 8. Security Considerations 740 As this document only provides terminology and describes neither a 741 protocol nor an implementation or a procedure, there are no security 742 considerations associated with it. 744 9. IANA Considerations 746 This document requires no IANA actions. 748 10. Acknowledgments 750 The material presented in this document takes most of the text from 751 internet-drafts initially submitted to the former MobileIP WG and the 752 MONET BOF and was published as part of a PhD dissertation [11]. The 753 authors would therefore like to thank both Motorola Labs Paris and 754 INRIA (PLANETE team, Grenoble, France) where this terminology 755 originated, for the opportunity to bring it to the IETF, and 756 particularly Claude Castelluccia for his advice, suggestions, and 757 direction, Alexandru Petrescu and Christophe Janneteau. We also 758 acknowledge input from Erik Nordmark, Hesham Soliman, Mattias 759 Petterson, Marcelo Bagnulo, TJ Kniveton, Masafumi Watari, Chan-Wah 760 Ng, JinHyeock Choi and numerous other people from the NEMO Working 761 Group. The Home Network Model section is contributed by Pascal 762 Thubert, Ryuji Wakikawa and Vijay Devaparalli. 764 11. References 766 11.1. Normative References 768 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 769 draft-ietf-nemo-requirements-05 (work in progress), 770 October 2005. 772 [2] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 773 IETF RFC 2460, December 1998. 775 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 776 RFC 3753, June 2004. 778 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 779 IPv6", RFC 3775, June 2004. 781 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 782 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 783 January 2005. 785 [6] Ng, C., "Analysis of Multihoming in Network Mobility Support", 786 draft-ietf-nemo-multihoming-issues-05 (work in progress), 787 February 2006. 789 [7] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 790 Network Models", draft-ietf-nemo-home-network-models-05 (work in 791 progress), June 2005. 793 [8] Ng, C., Pascal, P., Masafumi, M., and F. Fan, "Network Mobility 794 Route Optimization Problem Statement", 795 draft-ietf-nemo-ro-problem-statement-01 (work in progress), 796 October 2005. 798 [9] Ng, C., Fan, F., Masafumi, M., and P. Pascal, "Network Mobility 799 Route Optimization Solution Space Analysis", 800 draft-ietf-nemo-ro-space-analysis-01 (work in progress), 801 October 2005. 803 11.2. Informative References 805 [10] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 806 Multihoming Architectures", RFC 3582, August 2003. 808 [11] Ernst, T., "Network Mobility Support in IPv6", PhD's Thesis. , 809 Universite Joseph Fourier, Grenoble, France , October 2001. 811 Appendix A. Change Log From Earlier Versions 813 The discussions behind the changes in the lattest versions of this 814 documents are reflected in the "issue" web page: 815 http://www.sfc.wide.ad.jp/~ernst/nemo/ 817 A.1. Changes since draft-nemo-terminology-04.txt 819 In Section 3, added in the introduction a note about NEMO-enabled and 820 MIP6-enabled (part of this text was in the definition of NEMO- 821 enabled): 823 Removed Abbreviation "i-face" and "e-face" 825 Replaced "HA" with "home link located outside the mobile network" in 826 the definition of VMN 828 Replaced "address located within a MNP" with "address taken from a 829 MNP" [or derived is better ?] in the definitions of LFN and LMN 831 Replaced term NEMO-Link with Mobile Subnet 833 Figure 4 illustrates a VMN changing its point of attachment from 834 its home link located outside the mobile network to within a 835 mobile network. The figure also illustrates a LMN changing its 836 point of attachment within the mobile network. 838 In a typical use case of NEMO Basic Support [5], only the MR and 839 the HA are NEMO-enabled. LFNs are not MIPv6-enabled nor NEMO- 840 enabled. On the other hand, a VMN or a LMN acting as a mobile 841 router may be NEMO-enabled whereas a VMN or a LMN acting as a 842 mobile node may be MIPv6-enabled. 844 For NEMO Extended Support, details of the capabilities are not 845 known yet at the time of this writing, but NEMO-enabled nodes may 846 be expected to implement some sort of Route Optimization. 848 Removed this note from the definition of "root-MR": "note: this term 849 was referred to as Top-Level Mobile Router, or TLMR in short in 850 former versions of this document).". 852 Added term "Depth" 854 Removed "IPv6" in front of "address" in the definition of a 855 multihomed host and a multihomed mobile router 857 Removed "or multiple prefixes are advertised in the mobile network" 858 from the definition of a multihomed NEMO (5.3) and nested multihomed 859 NEMO (5.4) 861 Added definition for "Routing Optimization" (see Section 7.5). 863 Added definition "Pinball Route" following the discussion on the ML 864 in Dec.05 866 Added reference to [11] in the ACK section 868 A.2. Changes since draft-nemo-terminology-03.txt 870 Updated the Home Network Model section with new definitions provided 871 by Vijay 873 Added definitions of CR and CE as suggested by the RO PB Statement 874 and Analysis authors [8] 876 Completed figure improvement 878 A.3. Changes since draft-nemo-terminology-02.txt 880 - Issue A18: Redesigned Figure 3 882 - Issue A22: The follolwing comment added in the definition of 883 "Mobile Network": "Re-arrangement of the mobile network and changing 884 the attachment point of the egress interface to the foreign link are 885 orthogonal processes and do no affect each other." (as suggested by 886 TJ) 888 - Issue A23: Clarified in definition of "NEMO-link" that the link may 889 comprise the mobile network: "A link (subnet) which comprises, or is 890 located within, the mobile network." (as suggested by TJ) 892 - Issue A24: Removed definition of CR (as suggested by TJ) 894 - Issue A25: Removed the miscellaneous terms "Idle MNN" and "Idle 895 mobile network" (as suggested by TJ) 897 - Issue A26: English brush up. 899 A.4. Changes since draft-nemo-terminology-01.txt 901 - Shorten abstract. 903 - Reshaped some figures. 905 - LFN, VMN, LMN: said that the node is able/unable to move while 906 maintaining/not maintaining ongoing sessions. Text already 907 appareared in the document, but not in the definition itself. 909 - NEMO-enabled: said that MR and HA are the only NEMO-enabled nodes 910 in NEMO Basic Support 912 - Removed "NEMO-enabled MR" as this definition is self-contained into 913 "NEMO-enabled Node" 915 - Rephrased the definition of "multihomed host", "multihomed router", 916 "multihomed mobile network" and removed the terms multi-addressed and 917 multi-sited, multi-rooted-NEMO, etc. Such terms were not so useful, 918 and somewhat too long. 920 - Added the case "multiple MNPs are advertised" to the definition of 921 mobile network 923 - Copy-pasted terms defined from RFC 3753 so that the document is 924 self-contained 926 - Updated References 928 - Added new term "Correspondent Router" 930 - Permanently removed NEMO-Prefix. Only MNP will be used 932 - Added terms "Mobile Home Network" and "Distributed Home Network" in 933 the Home Network Model section. These 2 terms were provided by 934 Pascal Thubert on July 30th 2004 936 A.5. Changes since draft-nemo-terminology-00.txt 938 - NEMO will be used either as the concept for NEtwork MObility and a 939 noun meaning "NEtwork that is MObile" 941 - Deprecated TLMR and MONET. 943 - Added NEMO-prefix, NEMO-link, NEMO-enabled MR. 945 - Precision that IP address of LFN, LMN, or VMN is taken from a MNP 947 - Added abbreviation E-face (Egress interface) and I-face (Ingress 948 interface) 950 - Some re-ordering of terms, and a few typos. 952 - Added some text from the usage draft-thubert-usages (now home 953 network model draft-ietf-nemo-home-network-models) 955 Authors' Addresses 957 Thierry Ernst 958 Keio University / WIDE 959 Jun Murai Lab., Keio University. 960 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 961 Kawasaki, Kanagawa 212-0054 962 Japan 964 Phone: +81-44-580-1600 965 Fax: +81-44-580-1437 966 Email: ernst@sfc.wide.ad.jp 967 URI: http://www.sfc.wide.ad.jp/~ernst/ 969 Hong-Yon Lach 970 Motorola Labs Paris 971 Espace Technologique - Saint Aubin 972 Gif-sur-Yvette Cedex, 91 193 973 France 975 Phone: +33-169-35-25-36 976 Fax: 977 Email: hong-yon.lach@motorola.com 978 URI: 980 Intellectual Property Statement 982 The IETF takes no position regarding the validity or scope of any 983 Intellectual Property Rights or other rights that might be claimed to 984 pertain to the implementation or use of the technology described in 985 this document or the extent to which any license under such rights 986 might or might not be available; nor does it represent that it has 987 made any independent effort to identify any such rights. Information 988 on the procedures with respect to rights in RFC documents can be 989 found in BCP 78 and BCP 79. 991 Copies of IPR disclosures made to the IETF Secretariat and any 992 assurances of licenses to be made available, or the result of an 993 attempt made to obtain a general license or permission for the use of 994 such proprietary rights by implementers or users of this 995 specification can be obtained from the IETF on-line IPR repository at 996 http://www.ietf.org/ipr. 998 The IETF invites any interested party to bring to its attention any 999 copyrights, patents or patent applications, or other proprietary 1000 rights that may cover technology that may be required to implement 1001 this standard. Please address the information to the IETF at 1002 ietf-ipr@ietf.org. 1004 Disclaimer of Validity 1006 This document and the information contained herein are provided on an 1007 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1008 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1009 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1010 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1011 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1012 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1014 Copyright Statement 1016 Copyright (C) The Internet Society (2006). This document is subject 1017 to the rights, licenses and restrictions contained in BCP 78, and 1018 except as set forth therein, the authors retain all their rights. 1020 Acknowledgment 1022 Funding for the RFC Editor function is currently provided by the 1023 Internet Society.