idnits 2.17.1 draft-ietf-nemo-terminology-03.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 886. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 39 characters in excess of 72. 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 (February 21, 2005) is 7003 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) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '1') ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '4') == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '6') ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '8') Summary: 16 errors (**), 0 flaws (~~), 5 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 WIDE at Keio University 4 Expires: August 25, 2005 H-Y. Lach 5 Motorola Labs 6 February 21, 2005 8 Network Mobility Support Terminology 9 draft-ietf-nemo-terminology-03 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document defines a terminology for discussing network mobility 45 issues and solution requirements. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Architectural Components . . . . . . . . . . . . . . . . . . . 4 52 2.1 Mobile Network (NEMO) . . . . . . . . . . . . . . . . . . 6 53 2.2 Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 6 54 2.3 Egress Interface (E-face) . . . . . . . . . . . . . . . . 7 55 2.4 Ingress Interface (I-face) . . . . . . . . . . . . . . . . 7 56 2.5 Mobile Network Prefix (MNP) . . . . . . . . . . . . . . . 7 57 2.6 NEMO-link . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.7 Mobile Network Node (MNN) . . . . . . . . . . . . . . . . 7 59 2.8 Correspondent Node (CN) . . . . . . . . . . . . . . . . . 7 61 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1 Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . 8 63 3.2 Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . 8 64 3.3 Local Mobile Node (LMN) . . . . . . . . . . . . . . . . . 9 65 3.4 NEMO-enabled node (NEMO-node) . . . . . . . . . . . . . . 9 66 3.5 MIPv6-enabled (MIPv6-node) . . . . . . . . . . . . . . . . 10 68 4. Nested Mobility Terms . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.7 sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 16 85 6.1 Home Link . . . . . . . . . . . . . . . . . . . . . . . . 16 86 6.2 Home Network . . . . . . . . . . . . . . . . . . . . . . . 16 87 6.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 17 93 6.9 Virtual Home Network . . . . . . . . . . . . . . . . . . . 17 95 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 17 96 7.1 Host Mobility Support . . . . . . . . . . . . . . . . . . 17 97 7.2 Network Mobility Support (NEMO Support) . . . . . . . . . 18 98 7.3 NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 18 99 7.4 NEMO Extended Support . . . . . . . . . . . . . . . . . . 18 100 7.5 MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 18 102 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 108 A. Change Log From Earlier Versions . . . . . . . . . . . . . . . 20 109 A.1 Changes since draft-nemo-terminology-02.txt . . . . . . . 20 110 A.2 Changes since draft-nemo-terminology-01.txt . . . . . . . 20 111 A.3 Changes since draft-nemo-terminology-00.txt . . . . . . . 21 113 Intellectual Property and Copyright Statements . . . . . . . . 22 115 1. Introduction 117 Network mobility support is concerned with managing the mobility of 118 an entire network. This arises when a router connecting a network to 119 the Internet dynamically changes its point of attachment to the fixed 120 infrastructure, thereby causing the reachability of the entire 121 network to be changed in relation to the fixed Internet topology. 122 Such a network is referred to as a mobile network. Without 123 appropriate mechanisms to support network mobility, sessions 124 established between nodes in the mobile network and the global 125 Internet cannot be maintained after the mobile router changes its 126 point of attachment. As a result, existing sessions would break and 127 connectivity to the global Internet would be lost. 129 This document defines the specific terminology needed to describe the 130 problem space, the design goals [4], and the solutions for network 131 mobility support. This terminology aims to be consistent with the 132 usual IPv6 terminology [7] and the generic mobility-related terms 133 already defined in the Mobility Related Terminology [1] and in the 134 Mobile IPv6 specification [2]. Some terms introduced in this 135 document may only be useful for defining the problem scope and 136 functional requirements of network mobility support. 138 Note that the abbreviation NEMO stands for either "a NEtwork that is 139 MObile" or "NEtwork MObility". The former (see Section 2.1) is used 140 as a noun, e.g. "a NEMO" meaning "a mobile network". The latter 141 (see Section 7) refers to the concept of "network mobility" as in 142 "NEMO Basic Support" and is also the working group's name. 144 Section 2 introduces terms to define the architecture while terms 145 needed to emphasize the distinct functionalities of those 146 architectural components are described in Section 3. Section 4, 147 Section 5 and Section 6 describe terms pertaining to nested mobility, 148 multihoming and different configurations of mobile networks at home, 149 respectively. The different types of mobility are defined in 150 Section 7. The last section lists miscellaneous terms which do not 151 fit in any other section. 153 2. Architectural Components 155 A mobile network is composed of one or more mobile IP-subnets 156 (NEMO-link) and is viewed as a single unit. This network unit is 157 connected to the Internet by means of one or more mobile routers 158 (MRs). Nodes behind the MR (referred to as MNNs) primarily comprise 159 fixed nodes (nodes unable to change their point of attachment while 160 maintaining ongoing sessions), and possibly mobile nodes (nodes able 161 to change their point of attachment while maintaining ongoing 162 sessions). In most cases, the internal structure of the mobile 163 network will be stable (no dynamic change of the topology), but this 164 is not always true. 166 Figure 1 illustrates the architectural components involved in network 167 mobility and defined in the following paragraphs: Mobile Router (MR), 168 NEMO-link, Mobile Network Node (MNN), "ingress interface", "egress 169 interface", and Correspondent Node (CN). The other terms "access 170 router" (AR), "Fixed Node (FN)", "Mobile Node (MN)", "home agent" 171 (HA), "home link" and "foreign link" are not terms specific to 172 network mobility and thus are defined in [1]. 174 _ 175 CN ->|_|-| Internet 176 | _____ 177 |-| | |<- home link 178 _ | |-| _ | _ 179 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent) 180 | ^ | _ 181 foreign link ->| . |-|_|<- MR (Mobile Router) 182 .. AR (access ___|___ 183 router) _| |_ 184 |_| |_| 185 ^ ^ 186 MNN1 MNN2 188 Figure 1: Mobile Network on the Home Link 190 Figure 2 shows a single mobile subnetwork. Figure 3 illustrates a 191 larger mobile network comprising several subnetworks, attached to a 192 foreign link. 194 _ 195 CN ->|_|-| 196 | _____ 197 _ | |-| | |<- home link 198 |_|-| _ | _ | |-| _ | _ 199 2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA 200 |_|-| . | . | 201 | . |<- foreign . 202 single NEMO-link -> . link ^ AR 203 . 204 ^ MR 206 Figure 2: Single Mobile Subnetwork on a Foreign Link 208 At the network layer, MRs get access to the global Internet from the 209 Access Router(s) (AR) on a visited link. An MR maintains the 210 Internet connectivity for the entire mobile network. A given MR has 211 one or more egress interface and one or more ingress interface. When 212 forwarding a packet to the Internet, the packet is transmitted 213 upstream through one of the MR's egress interfaces to the AR; when 214 forwarding a packet from the AR down to the mobile network, the 215 packet is transmitted downstream through one of the MR's ingress 216 interfaces. 218 2.1 Mobile Network (NEMO) 220 As defined in [1]: 222 An entire network, moving as a unit, which dynamically changes its 223 point of attachment to the Internet and thus its reachability in the 224 topology. The mobile network is composed of one or more IP-subnets 225 and is connected to the global Internet via one or more Mobile 226 Routers (MR). The internal configuration of the mobile network is 227 assumed to be relatively stable with respect to the MR. 229 Re-arrangement of the mobile network and changing the attachment 230 point of the egress interface to the foreign link are orthogonal 231 processes and do no affect each other. 233 2.2 Mobile Router (MR) 235 As defined in [1]: 237 A router capable of changing its point of attachment to the Internet, 238 moving from one link to another link. The MR is capable of 239 forwarding packets between two or more interfaces, and possibly 240 running a dynamic routing protocol modifying the state by which it 241 does packet forwarding. 243 An MR acts as a gateway between an entire mobile network and the rest 244 of the Internet, and has one or more egress interface and one or more 245 ingress interface. Packets forwarded upstream to the rest of the 246 Internet are transmitted through one of the MR's egress interfaces; 247 packets forwarded downstream to the mobile network are transmitted 248 through one of the MR's ingress interfaces. 250 2.3 Egress Interface (E-face) 252 As defined in [1]: 254 The network interface of an MR attached to the home link if the MR is 255 at home, or attached to a foreign link if the MR is in a foreign 256 network. 258 2.4 Ingress Interface (I-face) 260 As defined in [1]: 262 The interface of an MR attached to a link inside the mobile network. 264 2.5 Mobile Network Prefix (MNP) 266 As defined in [1]: 268 A bit string that consists of some number of initial bits of an IP 269 address which identifies the entire mobile network within the 270 Internet topology. All nodes in a mobile network necessarily have an 271 address containing this prefix. 273 2.6 NEMO-link 275 A link (subnet) which comprises, or is located within, the mobile 276 network. 278 2.7 Mobile Network Node (MNN) 280 As defined in [1]: 282 Any node (host or router) located within a mobile network, either 283 permanently or temporarily. A Mobile Network Node may either be a 284 fixed node (LFN) or a mobile node (VMN or LMN). 286 2.8 Correspondent Node (CN) 288 Any node that is communicating with one or more MNNs. A CN could be 289 either located within a fixed network or within another mobile 290 network, and could be either fixed or mobile. 292 3. Functional Terms 294 _ 295 CN->|_|-| 296 NEMO-link 1->| | _____ 297 _ | |-| | |<- home link 298 MNN1->|_|-|'i'_'e'| _ | |-| _ | _ 299 |--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA 300 'i'| | | 301 NEMO-link 2->____|__ | 302 _| . |<- foreign 303 MNN2> |_| . link 304 . 305 ^ 306 MR 308 'i': MR's ingress interface 'e': MR's egress interface 310 Figure 3: Larger Mobile Network with 2 subnets 312 Within the term Mobile Network Node (MNN), we can distinguish between 313 Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN) and Local Mobile 314 Nodes (LMN). The distinction is a property of how different types of 315 nodes can move in the topology and is necessary to discuss issues 316 related to mobility management and access control; however it does 317 not imply that network mobility or host mobility should be handled 318 differently. Nodes are classified according to their function and 319 capabilities with the rationale that nodes with different properties 320 may have different requirements. 322 3.1 Local Fixed Node (LFN) 324 A fixed node (FN), either a host or a router, that belongs to the 325 mobile network and is unable to change its point of attachment while 326 maintaining ongoing sessions. Its address is located within an MNP. 328 3.2 Visiting Mobile Node (VMN) 330 Either a mobile node (MN) or a mobile router (MR), assigned to a home 331 link that doesn't belong to the mobile network and which is able to 332 change its point of attachment while maintaining ongoing sessions. A 333 VMN that is temporarily attached to a NEMO-link (used as a foreign 334 link) obtains an address on that link (i.e. the address is taken 335 from an MNP). 337 3.3 Local Mobile Node (LMN) 339 Either a mobile node (MN) or a mobile router (MR), assigned to a home 340 link belonging to the mobile network and which is able to change its 341 point of attachment while maintaining ongoing sessions. Its address 342 is taken from an MNP. Figure 4 illustrates a LMN changing its point 343 of attachment within the mobile network. 345 3.4 NEMO-enabled node (NEMO-node) 347 A node that has been extended with network mobility support 348 capabilities as described in NEMO specifications. 350 In NEMO Basic Support [3], only the MR and the HA are NEMO-enabled. 352 For NEMO Extended Support, details of the capabilities are not known 353 yet at the time of this writing, but NEMO-enabled nodes may be 354 expected to implement some sort of Route Optimization. 356 ________________________ 357 | | 358 | | 359 | Internet | 360 | | 361 |________________________| 362 __|_ __|_ 363 | | Access | | 364 | AR | Router | AR | 365 |____| |____| 366 __|_ _____|_____________ foreign 367 | | _|__ link 368 | MN | | | | 369 |____| _____ |__| MR | Mobile Router 370 | |__| |____| 371 |--> | LMN | | __|_____________ NEMO-link 1 372 | |_____| | __|__ | 373 | _____ | | | 374 | | |__| | LFN | 375 | | LFN | | |_____| | 376 | |_____| | | 377 | | NEMO-link 2 | 378 | | 379 |------------------------------| 381 Figure 4: LFN versus LMN 383 3.5 MIPv6-enabled (MIPv6-node) 385 A node which has been extended with host mobility support 386 capabilities as defined in the Mobile IPv6 specification [2]. 388 4. Nested Mobility Terms 390 Nested mobility occurs when there is more than one level of mobility, 391 i.e. when a mobile network acts as an access network and allows 392 visiting nodes to attach to it. There are two cases of nested 393 mobility: 395 o The attaching node is a single VMN (see figure 4). For instance, 396 when a passenger carrying a mobile phone gets Internet access from 397 the public access network deployed on a bus. 399 o The attaching node is a MR with nodes behind it, i.e. a mobile 400 network (see figure 5). For instance, when a passenger carrying a 401 PAN gets Internet access from the public access network deployed 402 on a bus. 404 For the second case, we introduce the following terms: 406 4.1 Nested Mobile Network (nested-NEMO) 408 A mobile network is said to be nested when a mobile network 409 (sub-NEMO) is attached to a larger mobile network (parent-NEMO). The 410 aggregated hierarchy of mobile networks becomes a single nested 411 mobile network. 413 4.2 root-NEMO 415 The mobile network at the top of the hierarchy connecting the 416 aggregated nested mobile networks to the Internet. 418 4.3 parent-NEMO 420 The upstream mobile network providing Internet access to another 421 mobile network further down the hierarchy. 423 4.4 sub-NEMO 425 The downstream mobile network attached to another mobile network up 426 in the hierarchy. It becomes subservient of the parent-NEMO. The 427 sub-NEMO is getting Internet access through the parent-NEMO and does 428 not provide Internet access to the parent-NEMO. 430 4.5 root-MR 432 The MR(s) of the root-NEMO used to connect the nested mobile network 433 to the fixed Internet. Was referred to as "TMLR" (Top-Level Mobile 434 Router) in former versions of this document. 436 4.6 parent-MR 438 The MR(s) of the parent-NEMO. 440 4.7 sub-MR 442 The MR(s) of the sub-NEMO which is connected to a parent-NEMO 443 ________________________ 444 | | 445 | | 446 | Internet | 447 | | 448 |________________________| 449 __|_ __|_ 450 | | Access | | 451 | AR | Router | AR | 452 |____| |____| 453 _____|_____________ home 454 | _|__ link 455 | | | | 456 | _____ |__| MR | Mobile Router 457 | | |__| |____| 458 ----------> | VMN | | __|_____________ NEMO-link 1 459 |_____| | __|__ __|__ 460 _____ | | | | | 461 | |__| | LFN | | LMN | 462 | LFN | | |_____| |_____| 463 |_____| | 464 | NEMO-link 2 466 Figure 5: Nested Mobility: a single VMN attached to a mobile network 468 _____ 469 _ | | 470 _ |--|_|-| |-| _ 471 _ |--|_|--| |_____| | _ |-|_| 472 _ |--|_|--| | |-|_|-| 473 |_|-| | | 474 | 476 MNN sub-MR root-MR AR AR HA 478 <--------><------><-------><------><------------> 479 sub-NEMO root-NEMO fl Internet Home Network 481 Figure 6: 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 487 site-multihoming [8] and host multihoming. We enlarge this 488 terminology to include "multihomed mobile router" and "multihomed 489 mobile network". The specific configurations and issues pertaining 490 to multihomed mobile networks are covered in [5]. 492 5.1 Multihomed host or MNN 494 A host (e.g. an MNN) is multihomed when it has several IPv6 495 addresses to choose between, i.e. in the following cases when it is 496 either: 498 Multi-prefixed: multiple prefixes are advertised on the link(s) 499 the host is attached to, or 501 Multi-interfaced: the host has multiple interfaces to choose 502 between, on the same link or not. 504 5.2 Multihomed Mobile Router 506 From the definition of a multihomed host, it follows that a mobile 507 router is multihomed when it has several IPv6 addresses to choose 508 between, i.e. in the following cases when the MR is either: 510 Multi-prefixed: multiple prefixes are advertised on the link(s) an 511 MR's egress interface is attached to, or. 513 Multi-interfaced: the MR has multiple egress interfaces to choose 514 between, on the same link or not. 516 _____ 517 _ _ | | 518 |_|-| _ |-|_|-| |-| _ 519 _ |-|_|=| |_____| | _ |-|_| 520 |_|-| | |-|_|-| 521 | 522 MNNs MR AR Internet AR HA 524 Figure 7: MR with multiple E-faces 526 5.3 Multihomed Mobile Network (multihomed-NEMO) 528 A mobile network is multihomed when either a MR is multihomed or 529 there are multiple MRs to choose between, or multiple prefixes are 530 advertised in the mobile network. 532 MR1 533 _ | 534 _ |-|_|-| _____ 535 |_|-| |-| | 536 MNNs _ | | |-| _ 537 |_|-| _ |-|_____| | _ |-|_| 538 |-|_|-| |-|_|-| 539 | | 540 MR2 542 Figure 8: Single NEMO-link with Multiple MRs 544 5.4 Nested Multihomed Mobile Network 546 A nested mobile network is multihomed when either a root-MR is 547 multihomed or there are multiple root-MRs to choose between or 548 multiple prefixes are advertised in the nested mobile network. 550 5.5 Illustration 552 Figure 7 and Figure 8 show two examples of multihomed mobile 553 networks. Figure 9 shows two independent mobile networks. NEMO-1 is 554 single-homed to the Internet through MR1. NEMO-2 is multihomed to 555 the Internet through MR2a and MR2b. Both mobile networks offer 556 access to visiting nodes and networks through an AR. 558 Let's consider the two following nested scenarios in Figure 9: 560 Scenario 1: What happens when MR2a's egress interface is attached to 561 AR1 ? 563 * NEMO-2 becomes subservient of NEMO-1 565 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 566 the aggregated nested mobile network 568 * NEMO-2 becomes the sub-NEMO 570 * MR1 is the root-MR for the aggregated nested mobile network 572 * MR2a is a sub-MR in the aggregated nested mobile network 574 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 576 * The aggregated nested mobile network is not multihomed, since 577 NEMO-2 cannot be used as a transit network for NEMO-1 579 Scenario 2: What happens when MR1's egress interface is attached to 580 AR2 ? 582 * NEMO-1 becomes subservient of NEMO-2 584 * NEMO-1 becomes the sub-NEMO 586 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the 587 root-NEMO for the aggregated nested mobile network 589 * MR2a and MR2b are both root-MRs for the aggregated nested 590 mobile network 592 * MR1 is a sub-MR in the aggregated nested mobile network 594 * NEMO-1 is not multihomed 596 * The aggregated nested mobile network is multihomed 597 _____________________________ 598 | | 599 | | 600 | Internet | 601 | | 602 |_____________________________| 603 __|__ __|__ __|__ 604 | | | | | | 605 | ARx | | ARy | | ARz | 606 |_____| |_____| |_____| 607 ______|__ ____|____ ___|____ 608 __|__ __|___ __|___ 609 | | | | | | 610 | MR1 | | MR2a | | MR2b | 611 |_____| |______| |______| 612 NEMO-1 _____|____ ___|__________|___ NEMO-2 613 __|__ __|__ 614 | | | | 615 | LFN | AR1 | LFN | AR2 616 |_____| |_____| 618 Figure 9: Nested Multihomed Mobile Network 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. Such configurations 624 are detailed in [6] 626 6.1 Home Link 628 The link attached to the interface at the Home Agent on which the 629 Home Prefix is configured. The interface can be a virtual interface, 630 in which case the Home Link is a Virtual Home Link. 632 6.2 Home Network 634 The Network formed by the application of the Home Prefix to the Home 635 Link. With NEMO, the concept of Home Network is extended as 636 explained below. 638 6.3 Home Address 640 With Mobile IPv6, a Home Address is derived from the Home Network 641 prefix. This is generalized in NEMO, with some limitations: A Home 642 Address can be derived either from the Home Network or from one of 643 the Mobile Router's MNPs. 645 6.4 Mobile Home Network 647 A Mobile Network that also serves as a Home Network. The MR that 648 owns the MNP acts as a Home Agent for it. 650 6.5 Distributed Home Network 652 A Distributed Home Network is advertised by several sites that are 653 geographically distributed and meshed using tunnels in a VPN fashion. 655 6.6 Mobile Aggregated Prefix 657 An aggregation of Mobile Network Prefixes. 659 6.7 Aggregated Home Network 661 The Home Network associated with a Mobile Aggregated Prefix. This 662 Aggregation is advertised as a subnet on the Home Link, and thus used 663 as Home Network for Nemo purposes. 665 6.8 Extended Home Network 667 The network associated with the aggregation of one or more Home 668 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 669 Network that is a subnet, the extended Home Network is an aggregation 670 and is further subnetted. 672 6.9 Virtual Home Network 674 The Home Network associated with a Virtual Network. The Extended 675 Home Network and the Aggregated Home Network can be configured as 676 Virtual Home Network. 678 7. Mobility Support Terms 680 7.1 Host Mobility Support 682 Host Mobility Support is a mechanism which maintains session 683 continuity between mobile nodes and their correspondents upon the 684 mobile host's change of point of attachment. It can be achieved 685 using Mobile IPv6 or other mobility support mechanisms. 687 7.2 Network Mobility Support (NEMO Support) 689 Network Mobility Support is a mechanism which maintains session 690 continuity between mobile network nodes and their correspondents upon 691 a mobile router's change of point of attachment. Solutions for this 692 problem are classified into NEMO Basic Support, and NEMO Extended 693 Support. 695 7.3 NEMO Basic Support 697 NEMO Basic Support is a solution to preserve session continuity by 698 means of bi-directional tunneling between MRs and their HAs much like 699 what is done with Mobile IPv6 [2] for mobile nodes when Routing 700 Optimization is not used. Only the HA and the MR are NEMO-enabled. 701 The solution for doing this is solely specified in [3]. 703 7.4 NEMO Extended Support 705 NEMO Extended support is to provide the necessary optimization, 706 including routing optimization between arbitrary MNNs and CNs. 708 7.5 MRHA Tunnel 710 The bi-directional tunnel between a Mobile Router and its Home Agent. 712 8. Acknowledgments 714 The material presented in this document takes most of the text from 715 internet-drafts submitted to the former MobileIP WG and the MONET 716 BOF. The authors would therefore like to thank both Motorola Labs 717 Paris and INRIA (PLANETE team, Grenoble, France) where this 718 terminology originated, for the opportunity to bring it to the IETF, 719 and particularly Claude Castelluccia for his advice, suggestion, and 720 direction, Alexandru Petrescu and Christophe Janneteau. We also 721 acknowledge input from Hesham Soliman, Mattias Petterson, Marcelo 722 Bagnulo, TJ Kniveton and numerous other people from the NEMO Working 723 Group. The Home Network Model section is contributed by Pascal 724 Thubert, Ryuji Wakikawa and Vijay Devaparalli. 726 9. References 728 [1] Manner, J. and M. Kojo, "Mobility Related Terminology", 729 RFC 3753, June 2004. 731 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 732 IPv6", RFC 3775, June 2004. 734 [3] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 735 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 736 January 2005. 738 [4] Ernst, T., "Network Mobility Support Goals and Requirements", 739 Internet-Draft draft-ietf-nemo-requirements-04, February 2005. 741 [5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in 742 Network Mobility Support", 743 Internet-Draft draft-ietf-nemo-multihoming-issues-02, February 744 2005. 746 [6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network 747 Models", Internet-Draft draft-ietf-nemo-home-network-models-01, 748 October 2004. 750 [7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 751 IETF RFC 2460, December 1998. 753 [8] Abley, J., Black, B. and V. Gill, "Goals for IPv6 754 Site-Multihoming Architectures", RFC 3582, August 2003. 756 Authors' Addresses 758 Thierry Ernst 759 WIDE at Keio University 760 Jun Murai Lab., Keio University. 761 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 762 Kawasaki, Kanagawa 212-0054 763 Japan 765 Phone: +81-44-580-1600 766 Fax: +81-44-580-1437 767 Email: ernst@sfc.wide.ad.jp 768 URI: http://www.sfc.wide.ad.jp/~ernst/ 770 Hong-Yon Lach 771 Motorola Labs Paris 772 Espace Technologique - Saint Aubin 773 Gif-sur-Yvette Cedex, 91 193 774 France 776 Phone: +33-169-35-25-36 777 Fax: 778 Email: hong-yon.lach@motorola.com 779 URI: 781 Appendix A. Change Log From Earlier Versions 783 The discussions behind the changes in the lattest versions of this 784 documents are reflected in the "issue" web page: 785 http://www.sfc.wide.ad.jp/~ernst/nemo/ 787 A.1 Changes since draft-nemo-terminology-02.txt 789 - Issue A18: Redesigned Figure 3 791 - Issue A22: The follolwing comment added in the definition of 792 "Mobile Network": "Re-arrangement of the mobile network and changing 793 the attachment point of the egress interface to the foreign link are 794 orthogonal processes and do no affect each other." (as suggested by 795 TJ) 797 - Issue A23: Clarified in definition of "NEMO-link" that the link may 798 comprise the mobile network: "A link (subnet) which comprises, or is 799 located within, the mobile network." (as suggested by TJ) 801 - Issue A24: Removed definition of CR (as suggested by TJ) 803 - Issue A25: Removed the miscellaneous terms "Idle MNN" and "Idle 804 mobile network" (as suggested by TJ) 806 - Issue A26: English brush up. 808 A.2 Changes since draft-nemo-terminology-01.txt 810 - Shorten abstract. 812 - Reshaped some figures. 814 - LFN, VMN, LMN: said that the node is able/unable to move while 815 maintaining/not maintaining ongoing sessions. Text already 816 appareared in the document, but not in the definition itself. 818 - NEMO-enabled: said that MR and HA are the only NEMO-enabled nodes 819 in NEMO Basic Support 821 - Removed "NEMO-enabled MR" as this definition is self-contained into 822 "NEMO-enabled Node" 824 - Rephrased the definition of "multihomed host", "multihomed router", 825 "multihomed mobile network" and removed the terms multi-addressed and 826 multi-sited, multi-rooted-NEMO, etc. Such terms were not so useful, 827 and somewhat too long. 829 - Added the case "multiple MNPs are advertised" to the definition of 830 mobile network 832 - Copy-pasted terms defined from RFC 3753 so that the document is 833 self-contained 835 - Updated References 837 - Added new term "Correspondent Router" 839 - Permanently removed NEMO-Prefix. Only MNP will be used 841 - Added terms "Mobile Home Network" and "Distributed Home Network" in 842 the Home Network Model section. These 2 terms were provided by 843 Pascal Thubert on July 30th 2004 845 A.3 Changes since draft-nemo-terminology-00.txt 847 - NEMO will be used either as the concept for NEtwork MObility and a 848 noun meaning "NEtwork that is MObile" 850 - Deprecated TMLR and MONET. 852 - Added NEMO-prefix, NEMO-link, NEMO-enabled MR. 854 - Precision that IP address of LFN, LMN, or VMN is taken from a MNP 856 - Added abbreviation E-face (Egress interface) and I-face (Ingress 857 interface) 859 - Some re-ordering of terms, and a few typos. 861 - Added some text from the usage draft-thubert-usages (now home 862 network model draft-ietf-nemo-home-network-models) 864 Intellectual Property Statement 866 The IETF takes no position regarding the validity or scope of any 867 Intellectual Property Rights or other rights that might be claimed to 868 pertain to the implementation or use of the technology described in 869 this document or the extent to which any license under such rights 870 might or might not be available; nor does it represent that it has 871 made any independent effort to identify any such rights. Information 872 on the procedures with respect to rights in RFC documents can be 873 found in BCP 78 and BCP 79. 875 Copies of IPR disclosures made to the IETF Secretariat and any 876 assurances of licenses to be made available, or the result of an 877 attempt made to obtain a general license or permission for the use of 878 such proprietary rights by implementers or users of this 879 specification can be obtained from the IETF on-line IPR repository at 880 http://www.ietf.org/ipr. 882 The IETF invites any interested party to bring to its attention any 883 copyrights, patents or patent applications, or other proprietary 884 rights that may cover technology that may be required to implement 885 this standard. Please address the information to the IETF at 886 ietf-ipr@ietf.org. 888 Disclaimer of Validity 890 This document and the information contained herein are provided on an 891 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 892 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 893 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 894 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 895 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 896 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 898 Copyright Statement 900 Copyright (C) The Internet Society (2005). This document is subject 901 to the rights, licenses and restrictions contained in BCP 78, and 902 except as set forth therein, the authors retain all their rights. 904 Acknowledgment 906 Funding for the RFC Editor function is currently provided by the 907 Internet Society.