idnits 2.17.1 draft-ietf-nemo-terminology-02.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 31. -- Found old boilerplate from RFC 3978, Section 5.5 on line 914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 904. ** 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 == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 89 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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. 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 25, 2004) is 7094 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-03 ** 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-01 ** 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: 15 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group T. Ernst 2 Internet-Draft WIDE at Keio University 3 Expires: April 25, 2005 H-Y. Lach 4 Motorola Labs 5 October 25, 2004 7 Network Mobility Support Terminology 8 draft-ietf-nemo-terminology-02 10 Abstract 12 This document defines a terminology for discussing network mobility 13 issues and solution requirements. 15 NEMO Working Group T. Ernst 16 Internet-Draft WIDE at Keio University 17 Expires: April 25, 2005 H-Y. Lach 18 Motorola Labs 19 October 25, 2004 21 Network Mobility Support Terminology 22 draft-ietf-nemo-terminology-02 24 Status of this Memo 26 This document is an Internet-Draft and is subject to all provisions 27 of section 3 of RFC 3667. By submitting this Internet-Draft, each 28 author represents that any applicable patent or other IPR claims of 29 which he or she is aware have been or will be disclosed, and any of 30 which he or she become aware will be disclosed, in accordance with 31 RFC 3668. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on April 25, 2005. 51 Copyright Notice 53 Copyright (C) The Internet Society (2004). 55 Abstract 57 This document defines a terminology for discussing network mobility 58 issues and solution requirements. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Architecture Components . . . . . . . . . . . . . . . . . . . 4 65 2.1 Mobile Network (NEMO) . . . . . . . . . . . . . . . . . . 6 66 2.2 Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 6 67 2.3 Egress Interface (E-face) . . . . . . . . . . . . . . . . 7 68 2.4 Ingress Interface (I-face) . . . . . . . . . . . . . . . . 7 69 2.5 Mobile Network Prefix (MNP) . . . . . . . . . . . . . . . 7 70 2.6 NEMO-link . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.7 Mobile Network Node (MNN) . . . . . . . . . . . . . . . . 7 72 2.8 Correspondent Node (CN) . . . . . . . . . . . . . . . . . 7 74 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1 Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . 8 76 3.2 Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . 9 77 3.3 Local Mobile Node (LMN) . . . . . . . . . . . . . . . . . 9 78 3.4 NEMO-enabled node (NEMO-node) . . . . . . . . . . . . . . 9 79 3.5 MIPv6-enabled (MIPv6-node) . . . . . . . . . . . . . . . . 10 80 3.6 Correspondent Router (CR) . . . . . . . . . . . . . . . . 10 82 4. Nested Mobility Terms . . . . . . . . . . . . . . . . . . . . 10 83 4.1 Nested Mobile Network (nested-NEMO) . . . . . . . . . . . 11 84 4.2 root-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 11 85 4.3 parent-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.4 sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.5 root-MR . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.6 parent-MR . . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.7 sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . . 13 92 5.1 Multihomed host or MNN . . . . . . . . . . . . . . . . . . 13 93 5.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 13 94 5.3 Multihomed Mobile Network (multihomed-NEMO) . . . . . . . 14 95 5.4 Nested Multihomed Mobile Network . . . . . . . . . . . . . 14 96 5.5 Illustration . . . . . . . . . . . . . . . . . . . . . . . 15 98 6. Home Network Model Terms . . . . . . . . . . . . . . . . . . . 16 99 6.1 Home Link . . . . . . . . . . . . . . . . . . . . . . . . 16 100 6.2 Home Network . . . . . . . . . . . . . . . . . . . . . . . 17 101 6.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 17 102 6.4 Mobile Home Network . . . . . . . . . . . . . . . . . . . 17 103 6.5 Distributed Home Network . . . . . . . . . . . . . . . . . 17 104 6.6 Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . 17 105 6.7 Aggregated Home Network . . . . . . . . . . . . . . . . . 17 106 6.8 Extended Home Network . . . . . . . . . . . . . . . . . . 17 107 6.9 Virtual Home Network . . . . . . . . . . . . . . . . . . . 17 109 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 18 110 7.1 Host Mobility Support . . . . . . . . . . . . . . . . . . 18 111 7.2 Network Mobility Support (NEMO Support) . . . . . . . . . 18 112 7.3 NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 18 113 7.4 NEMO Extended Support . . . . . . . . . . . . . . . . . . 18 114 7.5 MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 18 116 8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . . . 18 117 8.1 Idle MNN . . . . . . . . . . . . . . . . . . . . . . . . . 18 118 8.2 Idle Mobile Network . . . . . . . . . . . . . . . . . . . 18 120 9. Changes since draft-nemo-terminology-01.txt . . . . . . . . . 19 122 10. Changes since draft-nemo-terminology-00.txt . . . . . . . . 19 124 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 126 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 130 Intellectual Property and Copyright Statements . . . . . . . . 22 132 1. Introduction 134 Network mobility support is concerned with managing the mobility of 135 an entire network. This arises when a router connecting an entire 136 network to the Internet dynamically changes its point of attachment 137 to the Internet therefrom causing the reachability of the entire 138 network to be changed in the topology. Such network is referred to 139 as a mobile network. Without appropriate mechanisms to support 140 network mobility, sessions established between nodes in the mobile 141 network and the global Internet cannot be maintained while the mobile 142 router changes its point of attachment. As a result, existing 143 sessions would break and connectivity to the global Internet would be 144 lost. 146 This document defines the specific terminology needed to describe the 147 problem space, the design goals [4], and the solutions for network 148 mobility support. This terminology complies with the usual IPv6 149 terminology [7] and the generic mobility-related terms already 150 defined in [3] and in the Mobile IPv6 [1] specifications. Some terms 151 introduced in the present version of the draft may only be useful for 152 the purpose of defining the problem scope and functional requirements 153 of network mobility support. 155 Note that the abbreviation NEMO stands either for "a NEtwork that is 156 MObile" and for "NEtwork MObility". The former (see Section 2.1 is 157 used as a noun, e.g. "a NEMO" meaning "a mobile network". The 158 latter (see Section 7 refers to the concept of "network mobility" as 159 in "NEMO Basic Support" and is also the working group's name. 161 Section 2 introduces terms to define the architecture while terms 162 needed to emphasize the distinct functionalities of those 163 architecture components are described in Section 3. Section 4, 164 Section 5 and Section 6 respectively describe terms pertaining to 165 nested mobility, multihoming and those necessary to describe the 166 different configurations of mobile networks at home. The different 167 types of mobility are defined in Section 7. The last section lists 168 miscellaneous terms which do not fit in either sections. 170 2. Architecture Components 172 A mobile network is composed by one or more mobile IP-subnet 173 (NEMO-link) and is viewed as a single unit. The unit is connected to 174 the Internet by means of mobile routers (MRs). Nodes behind the MR 175 (MNNs) primarily comprise fixed nodes (nodes unable to change their 176 point of attachment while maintaining ongoing sessions), and 177 additionally mobile nodes (nodes able to change their point of 178 attachment while maintaining ongoing sessions). In most cases, the 179 internal structure of the mobile network will in effect be relatively 180 stable (no dynamic change of the topology), but this is not a general 181 assumption. 183 Figure 1 illustrates the architecture components involved in network 184 mobility and defined in the below paragraphs: Mobile Router (MR), 185 NEMO-link, Mobile Network Node (MNN), "ingress interface", "egress 186 interface", and Correspondent Nodes (CNs). The other terms "access 187 router" (AR), "Fixed Node (FN)", "Mobile Node (MN)", "home agent" 188 (HA), "home link" and "foreign link" are not terms specific to 189 network mobility and are thus defined in [3]. 191 _ 192 CN ->|_|-| Internet 193 | _____ 194 |-| | |<- home link 195 _ | |-| _ | _ 196 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent) 197 | ^ | _ 198 foreign link ->| . |-|_|<- MR (Mobile Router) 199 .. AR (access ___|___ 200 router) _| |_ 201 |_| |_| 202 ^ ^ 203 MNN1 MNN2 205 Figure 1: Mobile Network on the Home Link 207 Figure 2 shows a single mobile subnetwork. Figure 3 illustrates a 208 larger mobile network comprising several subnetworks, attached on a 209 foreign link. 211 _ 212 CN ->|_|-| 213 | _____ 214 _ | |-| | |<- home link 215 |_|-| _ | _ | |-| _ | _ 216 2 MNNs -> _ |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA 217 |_|-| . | . | 218 | . |<- foreign . 219 single NEMO-link -> . link ^ AR 220 . 221 ^ MR 223 Figure 2: Single Mobile Subnetwork on a Foreign Link 225 At the network layer, MRs get access to the global Internet from the 226 Access Routers (ARs) on the visited link. The MRs maintain the 227 Internet connectivity for the entire mobile network. A given MR has 228 one or more egress interface(s) and one or more ingress interface(s). 229 When forwarding a packet to the Internet the packet is transmitted 230 upstream through one of the MR's egress interfaces to the AR; when 231 forwarding a packet from the AR down to the mobile network, the 232 packet is transmitted downstream through one of the MR's ingress 233 interfaces. 235 2.1 Mobile Network (NEMO) 237 As defined in [3]: 239 An entire network, moving as a unit, which dynamically changes its 240 point of attachment to the Internet and thus its reachability in the 241 topology. The mobile network is composed of one or more IP-subnets 242 and is connected to the global Internet via one or more Mobile 243 Routers (MR). The internal configuration of the mobile network is 244 assumed to be relatively stable with respect to the MR. 246 2.2 Mobile Router (MR) 248 As defined in [3]: 250 A router capable of changing its point of attachment to the network, 251 moving from one link to another link. The MR is capable of 252 forwarding packets between two or more interfaces, and possibly 253 running a dynamic routing protocol modifying the state by which it 254 does packet forwarding. 256 A MR acting as a gateway between an entire mobile network and the 257 rest of the Internet has one or more egress interface(s) and one or 258 more ingress interface(s). Packets forwarded upstream to the rest of 259 the Internet are transmitted through one of the MR's egress 260 interface; packets forwarded downstream to the mobile network are 261 transmitted through one of the MR's ingress interface. 263 2.3 Egress Interface (E-face) 265 As defined in [3]: 267 The interface of a MR attached to the home link if the MR is at home, 268 or attached to a foreign link if the MR is in a foreign network. 270 2.4 Ingress Interface (I-face) 272 As defined in [3]: 274 The interface of a MR attached to a link inside the mobile network. 276 2.5 Mobile Network Prefix (MNP) 278 As defined in [3]: 280 A bit string that consists of some number of initial bits of an IP 281 address which identifies the entire mobile network within the 282 Internet topology. All nodes in a mobile network necessarily have an 283 address containing this prefix. 285 MNP is an acronym for Mobile Network Prefix. 287 2.6 NEMO-link 289 A link (subnet) located within the mobile network. 291 2.7 Mobile Network Node (MNN) 293 As defined in [3]: 295 Any node (host or router) located within a mobile network, either 296 permanently or temporarily. A Mobile Network Node may either be a 297 fixed node (LFN) or a mobile node (VMN or LMN). 299 2.8 Correspondent Node (CN) 301 Any node that is communicating with one or more MNNs. A CN could be 302 either located within a fixed network or within a mobile network, and 303 could be either fixed or mobile. 305 3. Functional Terms 307 ________________________ 308 | | 309 | | 310 | Internet | 311 | | 312 |________________________| 313 __|_ 314 Access | | 315 Router | AR | 316 |____| 317 foreign _____|_____________ 318 link | 319 | 'e' 320 __|__ 321 | 'i'| | 322 |____| MR | Mobile Router 323 | |_____| 324 | |'i' 325 | | 326 | ____|________________ NEMO-link 1 327 | __|__ __|__ 328 _____ | | | | | 329 | |__| | MNN | | MNN | 330 | MNN | | |_____| |_____| 331 |_____| | 332 | NEMO-link 2 'i': MR's ingress interface 333 'e': MR's egress interface 335 Figure 3: Larger Mobile Network with 2 subnets 337 Within the term Mobile Network Node (MNN), we can distinguish between 338 Local Fixed Node (LFN), Visiting Mobile Node (VMN) and Local Mobile 339 Node (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, but does not imply 342 that network mobility or host mobility should be handled differently. 343 Nodes are classified according to their function and capabilities 344 with the rationale that nodes with different properties (may) have 345 different requirements. 347 3.1 Local Fixed Node (LFN) 349 A fixed node (FN), either a host or a router, that belongs to the 350 mobile network and which is unable to change its point of attachment 351 while maintaining ongoing sessions. Its address is taken from a MNP. 353 3.2 Visiting Mobile Node (VMN) 355 A mobile node (MN), either a host or a router whose home link doesn't 356 belong to the mobile network and which is able to change its point of 357 attachment while maintaining ongoing sessions. A VMN that gets 358 temporarily attached to a NEMO-link (used as a foreign link) obtains 359 an address on that link (i.e. the address is taken from a MNP). 361 3.3 Local Mobile Node (LMN) 363 A mobile node (MN), either a host or a router whose home link belongs 364 to the mobile network and which is able to change its point of 365 attachment while maintaining ongoing sessions. Its address is taken 366 from a MNP. Figure 4 illustrates a LMN changing its point of 367 attachment within the mobile network. 369 3.4 NEMO-enabled node (NEMO-node) 371 A node that has been extended with network mobility support 372 capabilities and that may take special actions based on that. 374 In NEMO Basic Support, only the MR and the HA are NEMO-enabled. 376 In NEMO Extended Support, details of the capabilities are not known 377 yet, but NEMO-enabled nodes may be implementing some sort of Route 378 Optimization. 380 ________________________ 381 | | 382 | | 383 | Internet | 384 | | 385 |________________________| 386 __|_ __|_ 387 | | Access | | 388 | AR | Router | AR | 389 |____| |____| 390 __|_ _____|_____________ foreign 391 | | _|__ link 392 | MN | | | | 393 |____| _____ |__| MR | Mobile Router 394 | |__| |____| 395 |--> | LMN | | __|_____________ NEMO-link 1 396 | |_____| | __|__ | 397 | _____ | | | 398 | | |__| | LFN | 399 | | LFN | | |_____| | 400 | |_____| | | 401 | | NEMO-link 2 | 402 | | 403 |------------------------------| 405 Figure 4: LFN versus LMN 407 3.5 MIPv6-enabled (MIPv6-node) 409 A node which has been extended with host mobility support 410 capabilities as defined Mobile IPv6 in [1] and that may take special 411 actions based on that. 413 3.6 Correspondent Router (CR) 415 A router topologically close to the CN that has been extented with 416 some mobility support capabilities and that may take special actions 417 based on that. Details of the capabilities do not matter in the 418 present documents. The CR is said NEMO-enabled if such capabilities 419 are defined for network mobility support. 421 4. Nested Mobility Terms 423 Nested mobility occurs when there are more than one level of 424 mobility, i.e. when a mobile networks acts as an access network and 425 allows visiting nodes to get attached to it. There are two cases of 426 nested mobility: 428 o when the attaching node is a single VMN (see figure 4). For 429 instance, when a passenger carrying a mobile phone gets Internet 430 access from the public access network deployed into a bus. 432 o when the attaching node is a MR with nodes behind it, i.e. a 433 mobile network (see figure 5). For instance, when a passenger 434 carrying a PAN gets Internet access from the public access network 435 deployed in the bus. 437 For the second case, we introduce the following terms: 439 4.1 Nested Mobile Network (nested-NEMO) 441 A mobile network is said to be nested when a mobile network 442 (sub-NEMO) is getting attached to a larger mobile network 443 (parent-NEMO). The aggregated hierarchy of mobile networks becomes a 444 single nested mobile network. 446 4.2 root-NEMO 448 The mobile network at the top of the hierarchy connecting the 449 aggregated nested mobile network to the Internet. 451 4.3 parent-NEMO 453 The upstream mobile network providing Internet access to another 454 mobile network down the hierarchy. 456 4.4 sub-NEMO 458 The downstream mobile network attached to another mobile network up 459 the hierarchy. It becomes a subservient of the parent-NEMO. The 460 sub-NEMO is getting Internet access through the parent-NEMO and does 461 not provide Internet access to the parent-NEMO. 463 4.5 root-MR 465 The MR(s) of the root-NEMO used to connect the nested mobile network 466 to the fixed Internet. Was referred to as "TMLR" (Top-Level Mobile 467 Router) in former versions of this document. 469 4.6 parent-MR 471 The MR(s) of the parent-NEMO. 473 4.7 sub-MR 475 The MR(s) of the sub-NEMO connected to a parent-NEMO 477 ________________________ 478 | | 479 | | 480 | Internet | 481 | | 482 |________________________| 483 __|_ __|_ 484 | | Access | | 485 | AR | Router | AR | 486 |____| |____| 487 _____|_____________ home 488 | _|__ link 489 | | | | 490 | _____ |__| MR | Mobile Router 491 | | |__| |____| 492 ----------> | VMN | | __|_____________ NEMO-link 1 493 |_____| | __|__ __|__ 494 _____ | | | | | 495 | |__| | LFN | | LMN | 496 | LFN | | |_____| |_____| 497 |_____| | 498 | NEMO-link 2 500 Figure 5: Nested Mobility: single VMN attached to a mobile network 501 _____ 502 _ | | 503 _ |--|_|-| |-| _ 504 _ |--|_|--| |_____| | _ |-|_| 505 _ |--|_|--| | |-|_|-| 506 |_|-| | | 507 | 509 MNN sub-MR root-MR AR AR HA 511 <--------><------><-------><------><------------> 512 sub-NEMO root-NEMO fl Internet Home Network 514 Figure 6: Nested Mobility: sub-NEMO attached to a larger mobile 515 network 517 5. Multihoming Terms 519 Multihoming, as currently defined by the IETF, covers 520 site-multihoming [8] and host multihoming. We enlarge this 521 terminology to include "multihomed mobile router" and "multihomed 522 mobile network". The specific configurations and issues pertaining 523 to multihomed mobile networks are coverd in [5]. 525 5.1 Multihomed host or MNN 527 A host (e.g. a MNN) is multihomed when it has several IPv6 addresses 528 to choose between, i.e. in the following cases when it is either: 530 multi-prefixed: multiple prefixes are advertised on the link(s) 531 the host is attached to, or. 533 multi-interfaced: the host has multiple interfaces to choose 534 between, on the same link or not. 536 5.2 Multihomed Mobile Router 538 From the definition of a multihomed host, it follows that a router is 539 multihomed when it has several IPv6 addresses to choose between, i.e. 540 in the following cases when the MR is either: 542 multi-prefixed: multiple prefixes are advertised on the link(s) a 543 MR's egress interface is attached to, or. 545 multi-interfaced: the MR has multiple egress interfaces to choose 546 between, on the same link or not. 548 _____ 549 _ _ | | 550 |_|-| _ |-|_|-| |-| _ 551 _ |-|_|=| |_____| | _ |-|_| 552 |_|-| | |-|_|-| 553 | 554 MNNs MR AR Internet AR HA 556 Figure 7: MR with multiple E-faces 558 5.3 Multihomed Mobile Network (multihomed-NEMO) 560 A mobile network is multihomed when either a MR is multihomed or 561 there are multiple MRs to choose between, or multiple prefixes are 562 advertised in the mobile network. 564 MR1 565 _ | 566 _ |-|_|-| _____ 567 |_|-| |-| | 568 MNNs _ | | |-| _ 569 |_|-| _ |-|_____| | _ |-|_| 570 |-|_|-| |-|_|-| 571 | | 572 MR2 574 Figure 8: Single NEMO-link with Multiple MRs 576 5.4 Nested Multihomed Mobile Network 578 A nested mobile network is multihomed when either a root-MR is 579 multihomed or there are multiple root-MRs to choose between or 580 multiple prefixes are advertised in the nested mobile network. 582 5.5 Illustration 584 Figure 7 and Figure 8 show two examples of multihomed mobile 585 networks. Figure 9 shows two independent mobile networks. NEMO-1 is 586 single-homed to the Internet through MR1. NEMO-2 is multihomed to 587 the Internet through MR2a and MR2b. Both mobile networks offer 588 access to visiting nodes and networks through an AR. 590 Let's consider the two following nested scenarios in Figure 9: 592 Scenario 1: what happens when MR2a's egress interfaced is attached to 593 AR1 ? 595 * NEMO-2 becomes a subservient of NEMO-1 597 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 598 the aggregated nested mobile network 600 * NEMO-2 becomes the sub-NEMO 602 * MR1 is the root-MR for the aggregated nested mobile network 604 * MR2a is a sub-MR in the aggregated nested mobile network 606 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 608 * The aggregated nested mobile network is not multihomed since 609 NEMO-2 cannot be used as a transit network for NEMO-1 611 Scenario 2: what happens when MR1's egress interface is attached to 612 AR2 ? 614 * NEMO-1 becomes a subservient of NEMO-2 616 * NEMO-1 becomes the sub-NEMO 618 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the 619 root-NEMO for the aggregated nested mobile network) 621 * MR2a and MR2b are both root-MRs for the aggregated nested 622 mobile network 624 * MR1 is a sub-MR in the aggregated nested mobile network 625 * NEMO-1 is not multihomed 627 * The aggregated nested mobile network is multihomed 629 _____________________________ 630 | | 631 | | 632 | Internet | 633 | | 634 |_____________________________| 635 __|__ __|__ __|__ 636 | | | | | | 637 | ARx | | ARy | | ARz | 638 |_____| |_____| |_____| 639 ______|__ ____|____ ___|____ 640 __|__ __|___ __|___ 641 | | | | | | 642 | MR1 | | MR2a | | MR2b | 643 |_____| |______| |______| 644 NEMO-1 _____|____ ___|__________|___ NEMO-2 645 __|__ __|__ 646 | | | | 647 | LFN | AR1 | LFN | AR2 648 |_____| |_____| 650 Figure 9: Nested Multihomed Mobile Network 652 6. Home Network Model Terms 654 The terms in this section are useful to describe the possible 655 configurations of mobile networks are home. The configurations are 656 illustrated in [6] 658 6.1 Home Link 660 The link attached to the interface at the Home Agent on which the 661 Home Prefix is configured. The interface can be a virtual interface, 662 in which case the Home Link is a virtual Home Link. 664 6.2 Home Network 666 The Network formed by the application of the Home Prefix on the Home 667 Link. With Nemo, the concept of Home Network is extended as 668 explained below. 670 6.3 Home Address 672 With Mobile IPv6, a Home Address is derived from the Home Network 673 prefix. This is generalized in Nemo, with some limitations: A Home 674 Address can be either derived from the Home Network or from one of 675 the Mobile Router's Mobile Network prefixes. 677 6.4 Mobile Home Network 679 A Mobile Network that also serves as a Home Network. The MR that 680 owns the MNP acts as a Home Agent for it. 682 6.5 Distributed Home Network 684 A Distributed Home Network is advertised by several sites that are 685 geographically distributed and meshed using tunnels in a VPN fashion. 687 6.6 Mobile Aggregated Prefix 689 An aggregation of Mobile Network Prefixes. 691 6..7 Aggregated Home Network 693 The Home Network associated with a Mobile Aggregated Prefix. This 694 Aggregation is advertised as a subnet on the Home Link, and thus used 695 as Home Network for Nemo purposes. 697 6.8 Extended Home Network 699 The network associated with the aggregation of one or more Home 700 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 701 Network that is a subnet, the extended Home Network is an aggregation 702 and is further subnetted. 704 6.9 Virtual Home Network 706 The Home Network associated with a Virtual Network. The Extended 707 Home Network and the Aggregated Home Network can be configured as 708 Virtual Home Network. 710 7. Mobility Support Terms 712 7.1 Host Mobility Support 714 Host Mobility Support is a mechanism which maintains session 715 continuity between mobile nodes and their correspondents upon the 716 mobile host's change of point of attachment. It can be achieved 717 using Mobile IPv6 or other mobility support mechanisms. 719 7.2 Network Mobility Support (NEMO Support) 721 Network Mobility Support is a mechanism which maintains session 722 continuity between mobile network nodes and their correspondent upon 723 a mobile router's change of point of attachment. Solutions for this 724 problem are classified into NEMO Basic Support, and NEMO Extended 725 Support. 727 7.3 NEMO Basic Support 729 NEMO Basic Support is a solution to preserve session continuity by 730 means of bidirectional tunneling between MRs and their HAs much like 731 what is done with [1] for mobile nodes when Routing Optimization is 732 not used. Only the HA and the MR are NEMO-enabled. The solution for 733 doing this is solely specified in [2]. 735 7.4 NEMO Extended Support 737 NEMO Extended support is to provide the necessary optimization, 738 including routing optimization between arbitrary MNNs and CNs. 740 7.5 MRHA Tunnel 742 The bi-directional tunnel between a Mobile Router and its Home Agent 744 8.. Miscellaneous Terms 746 8.1 Idle MNN 748 A MNN that does not engage in any communication. 750 8.2 Idle Mobile Network 752 A mobile network that does not engage in any communication outside 753 the network can be considered idle from the global Internet. This 754 doesn't imply that MNNs are themselves idle. Internal traffic 755 between any two MNNs located in the same mobile network is not 756 concerned by this statement. 758 9. Changes since draft-nemo-terminology-01.txt 760 - Shorten abstract. 762 - Reshaped some figures. 764 - LFN, VMN, LMN: said that the node is able/unable to move while 765 maintaining/not maintaining ongoing sessions. Text already 766 appareared in the document, but not in the definition itself. 768 - NEMO-enabled: said that MR and HA are the only NEMO-enabled nodes 769 in NEMO Basic Support 771 - Removed "NEMO-enabled MR" as this definition is self-contained into 772 "NEMO-enabled Node" 774 - Rephrased the definition of "multihomed host", "multihomed router", 775 "multihomed mobile network" and removed the terms multi-addressed and 776 multi-sited, multi-rooted-NEMO, etc. Such terms were not so useful, 777 and somewhat too long. 779 - Added the case "multiple MNPs are advertised" to the definition of 780 mobile network 782 - Copy-pasted terms defined from RFC 3753 so that the document is 783 self-contained 785 - Updated References 787 - Added new term "Correspondent Router" 789 - Permanently removed NEMO-Prefix. Only MNP will be used 791 - Added terms "Mobile Home Network" and "Distributed Home Network" in 792 the Home Network Model section. These 2 terms were provided by 793 Pascal Thubert on July 30th 2004 795 10. Changes since draft-nemo-terminology-00.txt 797 - NEMO will be used either as the concept for NEtwork MObility and a 798 noun meaning "NEtwork that is MObile" 800 - Deprecated TMLR and MONET. 802 - Added NEMO-prefix, NEMO-link, NEMO-enabled MR. 804 - Precision that IP address of LFN, LMN, or VMN is taken from a MNP 805 - Added abbreviation E-face (Egress interface) and I-face (Ingress 806 interface) 808 - Some re-ordering of terms, and a few typos. 810 - Added some text from the usage draft-thubert-usages (now home 811 network model draft-ietf-nemo-home-network-models) 813 11. Acknowledgments 815 The material presented in this document takes most of the text from 816 former internet-drafts submitted to the former MobileIP WG and the 817 MONET BOF. Authors would therefore like to thank both Motorola Labs 818 Paris and INRIA (PLANETE team, Grenoble, France) where this 819 terminology originated, for the opportunity to bring it to the IETF, 820 and particularly Claude Castelluccia for his advices, suggestions, 821 and direction, Alexandru Petrescu and Christophe Janneteau. We also 822 acknowledge input from Hesham Soliman, Mattias Petterson, Marcelo 823 Bagnulo and numerous other people from the NEMO Working Group. The 824 Home Network Model section is contributed by Pascal Thubert, Ryuji 825 Wakikawa and Vijay Devaparalli. 827 12 References 829 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 830 IPv6", RFC 3775, June 2004. 832 [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support 833 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 834 June 2004. 836 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 837 3753, June 2004. 839 [4] Ernst, T., "Network Mobility Support Goals and Requirements", 840 draft-ietf-nemo-requirements-03 (work in progress), October 841 2004. 843 [5] Ng, C-W., Paik, E-K. and T. Ernst, "Analysis of Multihoming in 844 Network Mobility Support", draft-ietf-nemo-multihoming-issues-01 845 (work in progress), October 2004. 847 [6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network 848 Models", draft-ietf-nemo-home-network-models-01 (work in 849 progress), October 2004. 851 [7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 852 IETF RFC 2460, December 1998. 854 [8] Abley, J., Black, B. and V. Gill, "Goals for IPv6 855 Site-Multihoming Architectures", RFC 3582, August 2003. 857 Authors' Addresses 859 Thierry Ernst 860 WIDE at Keio University 861 Jun Murai Lab., Keio University. 862 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 863 Kawasaki, Kanagawa 212-0054 864 Japan 866 Phone: +81-44-580-1600 867 Fax: +81-44-580-1437 868 EMail: ernst@sfc.wide.ad.jp 869 URI: http://www.sfc.wide.ad.jp/~ernst/ 871 Hong-Yon Lach 872 Motorola Labs Paris 873 Espace Technologique - Saint Aubin 874 Gif-sur-Yvette Cedex, 91 193 875 France 877 Phone: +33-169-35-25-36 878 Fax: 879 EMail: hong-yon.lach@motorola.com 880 URI: 882 Intellectual Property Statement 884 The IETF takes no position regarding the validity or scope of any 885 Intellectual Property Rights or other rights that might be claimed to 886 pertain to the implementation or use of the technology described in 887 this document or the extent to which any license under such rights 888 might or might not be available; nor does it represent that it has 889 made any independent effort to identify any such rights. Information 890 on the procedures with respect to rights in RFC documents can be 891 found in BCP 78 and BCP 79. 893 Copies of IPR disclosures made to the IETF Secretariat and any 894 assurances of licenses to be made available, or the result of an 895 attempt made to obtain a general license or permission for the use of 896 such proprietary rights by implementers or users of this 897 specification can be obtained from the IETF on-line IPR repository at 898 http://www.ietf.org/ipr. 900 The IETF invites any interested party to bring to its attention any 901 copyrights, patents or patent applications, or other proprietary 902 rights that may cover technology that may be required to implement 903 this standard. Please address the information to the IETF at 904 ietf-ipr@ietf.org. 906 Disclaimer of Validity 908 This document and the information contained herein are provided on an 909 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 910 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 911 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 912 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 913 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 916 Copyright Statement 918 Copyright (C) The Internet Society (2004). This document is subject 919 to the rights, licenses and restrictions contained in BCP 78, and 920 except as set forth therein, the authors retain all their rights. 922 Acknowledgment 924 Funding for the RFC Editor function is currently provided by the 925 Internet Society.