idnits 2.17.1 draft-ietf-nemo-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** 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 (February 16, 2004) is 7374 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) -- Looks like a reference, but probably isn't: 'DEPRECIATED' on line 259 == Unused Reference: '4' is defined on line 791, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 799, but no explicit reference was found in the text -- No information found for draft-ietf-seamoby-terminology - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-02 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '8') Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 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 16, 2004 H-Y. Lach 5 Motorola Labs 6 February 16, 2004 8 Network Mobility Support Terminology 9 draft-ietf-nemo-terminology-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 16, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines a terminology for discussing network mobility 40 problems and solution requirements. Network mobility arises when a 41 router connecting an entire network to the Internet dynamically 42 changes its point of attachment to the Internet therefrom causing the 43 reachability of the entire network to be changed in the topology. 44 Such kind of network is referred to as a mobile network. Without 45 appropriate mechanisms, sessions established between nodes in the 46 mobile network and the global Internet cannot be maintained while the 47 mobile router changes its point of attachment. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Architecture Components . . . . . . . . . . . . . . . . . . 4 55 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1 Mobile Network . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.3 MONET [DEPRECIATED] . . . . . . . . . . . . . . . . . . . . 6 59 3.4 Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . . 7 60 3.5 Egress Interface (E-face) . . . . . . . . . . . . . . . . . 7 61 3.6 Ingress Interface (I-face) . . . . . . . . . . . . . . . . . 7 62 3.7 NEMO-prefix (MNP) . . . . . . . . . . . . . . . . . . . . . 7 63 3.8 NEMO-link . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.9 Mobile Network Node (MNN) . . . . . . . . . . . . . . . . . 7 65 3.10 Node behind the MR . . . . . . . . . . . . . . . . . . . . . 7 66 3.11 Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . . 7 67 3.12 Local Mobile Node (LMN) . . . . . . . . . . . . . . . . . . 7 68 3.13 Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . . 7 69 3.14 NEMO-enabled (NEMO-node) . . . . . . . . . . . . . . . . . . 8 70 3.15 NEMO-enabled MR . . . . . . . . . . . . . . . . . . . . . . 8 71 3.16 MIPv6-enabled (MIPv6-node) . . . . . . . . . . . . . . . . . 9 72 3.17 Correspondent Node (CN) . . . . . . . . . . . . . . . . . . 9 74 4. Nested Mobility Terms . . . . . . . . . . . . . . . . . . . 9 75 4.1 Nested Mobile Network . . . . . . . . . . . . . . . . . . . 9 76 4.2 root-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3 parent-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.4 sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.5 root-MR (or TLMR, but depreciated) . . . . . . . . . . . . . 10 80 4.6 parent-MR . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.7 sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . 11 84 5.1 Multihomed Host . . . . . . . . . . . . . . . . . . . . . . 11 85 5.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . . 12 86 5.3 Multihomed Mobile Network . . . . . . . . . . . . . . . . . 13 87 5.4 Multihomed and Nested Mobile Network . . . . . . . . . . . . 13 88 5.5 Illustration . . . . . . . . . . . . . . . . . . . . . . . . 14 90 6. Mobility Support Terms . . . . . . . . . . . . . . . . . . . 15 91 6.1 Host mobility support . . . . . . . . . . . . . . . . . . . 15 92 6.2 Network Mobility support (NEMO Support) . . . . . . . . . . 15 93 6.3 NEMO Basic Support . . . . . . . . . . . . . . . . . . . . . 16 94 6.4 NEMO Extended Support . . . . . . . . . . . . . . . . . . . 16 96 7. New Text From Usage Draft . . . . . . . . . . . . . . . . . 16 97 7.1 Home Link . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 7.2 Home Network . . . . . . . . . . . . . . . . . . . . . . . . 16 99 7.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . . 16 100 7.4 MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16 101 7.5 Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . . 16 102 7.6 Aggregated Home Network . . . . . . . . . . . . . . . . . . 16 103 7.7 Extended Home Network . . . . . . . . . . . . . . . . . . . 17 104 7.8 Virtual Home Network . . . . . . . . . . . . . . . . . . . . 17 106 8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . . 17 107 8.1 Idle MNN . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 8.2 Idle Mobile Network . . . . . . . . . . . . . . . . . . . . 17 110 9. Changes since draft-nemo-terminology-00.txt . . . . . . . . 17 112 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 114 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 118 Intellectual Property and Copyright Statements . . . . . . . 20 120 1. Introduction 122 Network mobility support is concerned with managing the mobility of 123 an entire network which changes its point of attachment to the 124 Internet and thus its reachability in the Internet topology. If 125 network mobility is not explicitly supported by some mechanisms, 126 existing sessions break and connectivity to the global Internet is 127 lost. 129 This document defines the specific terminology needed to describe the 130 problem space we face with network mobility and to edict the 131 solutions and the requirements they must comply with. This 132 terminology complies with the usual IPv6 terminology [7] and the 133 generic mobility-related terms already defined in [2] and in the 134 Mobile IPv6 [1] specifications. Some terms introduced in the present 135 version of the draft may only be useful for the purpose of defining 136 the problem scope and functional requirements of network mobility 137 support and shall be removed or refined once we agree on the 138 requirements. 140 The first section introduces terms to define the architecture 141 components; the second introduces terms to discuss the requirements, 142 the third, terms to discuss nested mobility; the forth defines 143 multihoming, and the last, miscellaneous terms which do not fit in 144 either sections. The overall terminology is summarized in fig.1 to 5. 145 Fig.1 shows a single mobile subnetwork. Fig.2. shows a larger mobile 146 network comprising several subnetworks, attached on a foreign link. 147 Fig.3 illustrates a node changing its point of attachment within the 148 mobile network. Fig.4 and 5 illustrate nested mobility whereas Fig.6 149 to Fig.8 illustrate multihoming. 151 2. Architecture Components 153 Fig.1 and 2 illustrate the architecture components involved in 154 network mobility. The terms "Fixed Node (FN)", "Mobile Node (MN)", 155 "Mobile Network", "Mobile Router (MR)", "Mobile Network Node (MNN)", 156 "home link", "foreign link", "ingress interface", "egress interface", 157 access router (AR), home link, foreign link are defined in [2]. 159 A mobile network is composed by one or more IP-subnet and is viewed 160 as a single unit. It is connected to the Internet by means of mobile 161 routers (MRs). Nodes behind the MR primarily comprise fixed nodes 162 (nodes unable to change their point of attachment while maintaining 163 ongoing sessions), and additionally mobile nodes (nodes able to 164 change their point of attachment while maintaining ongoing sessions). 165 In most cases, the internal structure of the mobile network will in 166 effect be relatively stable (no dynamic change of the topology), but 167 this is not a general assumption. 169 ____ 170 | | 171 | CN | 172 |____| 173 ___|____________________ 174 | | 175 | | 176 | Internet | 177 | | 178 |________________________| 179 __|_ __|_ 180 | | Access | | 181 | AR | Router | AR | 182 |____| |____| 183 ______|__ foreign __|_____________ home 184 link __|_ link 185 | | 186 | MR | Mobile Router 187 |____| 188 _________|_______ NEMO-link 189 __|__ __|__ 190 | | | | 191 | MNN | | MNN | Mobile Network Nodes 192 |_____| |_____| 194 Fig.1: Architecture Components 196 At the network layer, MRs get access to the global Internet from the 197 Access Routers (ARs) on the visited link. The MR maintains the 198 Internet connectivity for the entire mobile network. It has one or 199 more egress interface(s) and one or more ingress interface(s). When 200 forwarding a packet to the Internet the packet is transmitted 201 upstream through one of the MR's egress interfaces to the AR; when 202 forwarding a packet from the AR down to the mobile network, the 203 packet is transmitted downstream through one of the MR's ingress 204 interfaces. 206 3. Functional Terms 208 ________________________ 209 | | 210 | | 211 | Internet | 212 | | 213 |________________________| 214 __|_ 215 Access | | 216 Router | AR | 217 |____| 218 foreign _____|_____________ 219 link | 220 | 'e' 221 __|__ 222 | 'i'| | 223 |____| MR | Mobile Router 224 | |_____| 225 | |'i' 226 | | 227 | ____|________________ NEMO-link 1 228 | __|__ __|__ 229 _____ | | | | | 230 | |__| | MNN | | MNN | 231 | MNN | | |_____| |_____| 232 |_____| | 233 | NEMO-link 2 'i': MR's ingress interface 234 'e': MR's egress interface 236 Fig.2: Larger Mobile Network with 2 subnets 238 Within the term Mobile Network Node (MNN), we can distinguish between 239 LFN, VMN and LMN. The distinction is a property of how different 240 types of nodes can move in the topology and is necessary to discuss 241 issues related to mobility management and access control, but does 242 not preclude that mobility should be handled differently. Nodes are 243 classified according to their function and capabilities with the 244 rationale that nodes with different properties (may) have different 245 requirements. 247 3.1 Mobile Network 249 As defined in [2]) 251 3.2 NEMO 253 An abbreviation either for "NEtwork MObility" or for " a NEtwork that 254 is MObile". It the former, it refers to the concept of "network 255 mobility" like in "NEMO Basic Support" and is also the working 256 group's name. In the latter, it is used as a noun, e.g. "a NEMO" 257 meaning "a mobile network". 259 3.3 MONET [DEPRECIATED] 260 An abbreviation for MObile NETwork. MONET can be used as a noun, e.g. 261 a MONET" meaning "a mobile network". Not to be confused with MANET 262 (Mobile Ad-hoc NETwork) 264 3.4 Mobile Router (MR) 266 As defined in [2]) 268 3.5 Egress Interface (E-face) 270 As defined in [2]) 272 3.6 Ingress Interface (I-face) 274 As defined in [2]) 276 3.7 NEMO-prefix (MNP) 278 An acronym for Mobile Network Prefix (as defined in [2]) 280 3.8 NEMO-link 282 A link (subnet) located within the mobile network. 284 3.9 Mobile Network Node (MNN) 286 As defined in [2]). May be either a LFN, LMN, or a VMN. 288 3.10 Node behind the MR 290 Any MNN located in a mobile network, beside the MRs connecting the 291 mobile network to the Internet. 293 3.11 Local Fixed Node (LFN) 295 A fixed node (FN), either a host or a router, that belongs to the 296 mobile network and which doesn't move topologically with respect to 297 the MR. It's address is taken from a NEMO-prefix. 299 3.12 Local Mobile Node (LMN) 301 A mobile node (MN), either a host or a router which can move 302 topologically with respect to the MR and whose home link belongs to 303 the mobile network. It's address is taken from a NEMO-prefix. 305 3.13 Visiting Mobile Node (VMN) 307 A mobile node (MN), either a host or a router which can move 308 topologically with respect to the MR and whose home link doesn't 309 belong to the mobile network. A VMN that gets temporarily attached to 310 a NEMO-link (used as a foreign link) obtains an address on that link 311 (i.e. taken from a NEMO-prefix). 313 3.14 NEMO-enabled (NEMO-node) 315 A node that has been extended with network mobility support 316 capabilities and that may take special actions based on that (details 317 of the capabilities are not known yet, but it may be implementing 318 some sort of Route Optimization). 320 ________________________ 321 | | 322 | | 323 | Internet | 324 | | 325 |________________________| 326 __|_ __|_ 327 | | Access | | 328 | AR | Router | AR | 329 |____| |____| 330 __|_ _____|_____________ foreign 331 | | _|__ link 332 | MN | | | | 333 |____| _____ |__| MR | Mobile Router 334 | |__| |____| 335 |--> | LMN | | __|_____________ NEMO-link 1 336 | |_____| | __|__ | 337 | _____ | | | 338 | | |__| | LFN | 339 | | LFN | | |_____| | 340 | |_____| | | 341 | | NEMO-link 2 | 342 | | 343 |------------------------------| 345 Fig.3: LFN and LMN: LMN changing from NEMO-link 1 to NEMO-link 2 347 3.15 NEMO-enabled MR 349 A mobile router that has been extended with network mobility support 350 capabilities and that may take special actions based on that (for 351 instance as the ones defined in NEMO Basic Support [3] 353 3.16 MIPv6-enabled (MIPv6-node) 355 A node which has been extended with host mobility support 356 capabilities as defined in [1] and that may take special actions 357 based on that 359 3.17 Correspondent Node (CN) 361 Any node that is communicating with one or more MNNs. A CN could 362 either be located in the fixed network or within the mobile network, 363 and could be either fixed or mobile. 365 4. Nested Mobility Terms 367 Nested mobility occurs when there are more than one level of 368 mobility. A MNN acts as an Access Router (AR) and allows visiting 369 nodes to get attached to it. There are two cases of nested mobility: 371 o when the attaching node is a single node: VMN (see figure 4). For 372 instance, when a passenger carrying a mobile phone gets Internet 373 access from the public access network deployed into a bus. 375 o when the attaching node is a router with nodes behind it, i.e. a 376 mobile network (see figure 5). For instance, when a passenger 377 carrying a PAN gets Internet access from the public access network 378 deployed in the bus. 380 For the second case, we introduce the following terms: 382 4.1 Nested Mobile Network 384 A mobile network is said to be nested when a mobile network is 385 getting attached to a larger mobile network. The aggregated hierarchy 386 of mobile networks becomes a single nested mobile network. 388 4.2 root-NEMO 390 The mobile network at the top of the hierarchy connecting the 391 aggregated nested mobile network to the Internet. 393 4.3 parent-NEMO 395 The upstream mobile network providing Internet access to a mobile 396 network down the hierarchy. 398 4.4 sub-NEMO 400 The downstream mobile network attached to a mobile network up the 401 hierarchy. It becomes a subservient of the parent-NEMO. The sub-NEMO 402 is getting Internet access through the parent-NEMO and does not 403 provide Internet access to the parent-NEMO. 405 4.5 root-MR (or TLMR, but depreciated) 407 The MR(s) of the root-NEMO used to connect the nested mobile network 408 to the fixed Internet. Was referred to as "TMLR" (Top-Level Mobile 409 Router) in former versions of this document. 411 4.6 parent-MR 413 The MR(s) of the parent-NEMO. 415 4.7 sub-MR 417 The MR(s) of the sub-NEMO connected to a parent-NEMO 419 ________________________ 420 | | 421 | | 422 | Internet | 423 | | 424 |________________________| 425 __|_ __|_ 426 | | Access | | 427 | AR | Router | AR | 428 |____| |____| 429 _____|_____________ home 430 | _|__ link 431 | | | | 432 | _____ |__| MR | Mobile Router 433 | | |__| |____| 434 ----------> | VMN | | __|_____________ NEMO-link 1 435 |_____| | __|__ __|__ 436 _____ | | | | | 437 | |__| | LFN | | LMN | 438 | LFN | | |_____| |_____| 439 |_____| | 440 | NEMO-link 2 442 Fig.4: Nested Mobility: single VMN attached to a mobile network 443 ________________________ 444 | | 445 | | 446 | Internet | 447 | | 448 |________________________| 449 __|__ __|__ 450 | | | | 451 | AR1 | | AR2 | 452 |_____| |_____| 453 _____|_____________ foreign 454 __|__ link 455 | | 456 | _____ |__| MR1 | root-MR 457 |__| |__| |_____| 458 | | MR2 | | __|_____________ NEMO-link 1 459 | |_____| | __|__ __|__ 460 _____ | | | | | | 461 | | | sub-MR | | LFN | | LMN | 462 | LFN |__| | |_____| |_____| 463 |_____| | | 464 | | NEMO-link 2 466 |-------------------| |---------------------------| 467 sub-NEMO root-NEMO 469 Fig.5: Nested Mobility: sub-NEMO attached to a larger mobile network 471 5. Multihoming Terms 473 Multihoming, as currently defined by the IETF, covers 474 site-multihoming [8] and host multihoming. 476 5.1 Multihomed Host 478 Within host-multihoming, a host may either be: 480 o multi-addressed: multiple source addresses to choose between on a 481 given interface; all IPv6 nodes are multi-addressed due to the 482 presence of link-local addresses on all interfaces. 484 o multi-interfaced: multiple interfaces to choose between, on the 485 same link or not. 487 o multi-linked: multiple links to choose between (just like 488 multi-interfaced but all interfaces are NOT connected to the same 489 link) 491 o multi-sited: when using IPv6 site-local address and attached to 492 different sites 494 5.2 Multihomed Mobile Router 496 A MR is multihomed when it has simultaneously more than one active 497 connection to the Internet, that is when it is either: 499 o multi-egress-addressed MR: the MR has simultaneously multiple 500 active addresses to choose between on a given egress interface 502 o multi-egress-interfaced MR: the MR has simultaneously multiple 503 active egress interfaces on the same link or not 505 o multi-egress-linked MR: the MR has simultaneously multiple active 506 egress interfaces on distinct links 508 o multi-egress-sited MR: the MR is simultaneously attached to 509 different sites (possible distinct ISPs). 511 ________________________ 512 | | 513 | | 514 | Internet | 515 | | 516 |________________________| 517 __|__ __|__ 518 | | | | 519 | AR1 | | AR2 | 520 |_____| |_____| 521 foreign ______|_____ _____|______ foreign 522 link 1 | ____ | link 2 523 | | | | 524 |___| MR |___| 525 |____| 526 ______|_____ NEMO-link 527 __|__ 528 | | 529 | LFN | 530 |_____| 532 Fig.6: Multihomed Mobile Network: MR has multiple egress interfaces 534 5.3 Multihomed Mobile Network 536 A mobile network is multihomed when there more than one active egress 537 interface connected to the global Internet, that is when either: 539 o a MR is multihomed, or 541 o multi-MR-NEMO: the mobile network has more than one MR to choose 542 between 544 ________________________ 545 | | 546 | | 547 | Internet | 548 | | 549 |________________________| 550 __|__ __|__ 551 | | | | 552 | AR1 | | AR2 | 553 |_____| |_____| 554 foreign ______|_____ _____|______ foreign 555 link 1 __|__ __|__ link 2 556 | | | | 557 | MR1 | | MR2 | 558 |_____| |_____| 559 _____|__________|_____ NEMO-link 560 __|__ 561 | | 562 | LFN | 563 |_____| 565 Fig.7: Multihomed Mobile Network: NEMO with multiple MRs 567 5.4 Multihomed and Nested Mobile Network 569 A nested mobile network is multihomed when there are more than one 570 active interface connected to the global Internet, that is when 571 either: 573 o a root-MR is multihomed, or 575 o multi-rooted-NEMO: there are more than one root-MR to choose 576 between 578 5.5 Illustration 580 Fig.6 and 7 show two examples of multihomed mobile networks. Fig.8. 581 shows two independent mobile networks. NEMO-1 is single-homed to the 582 Internet through MR1. NEMO-2 is multihomed to the Internet through 583 MR2a and MR2b. Both mobile networks offer access to visiting nodes 584 and networks through an AR. 586 Let's consider the two following nested scenarios in Fig.8: 588 Scenario 1: what happens when MR2a's egress interfaced is attached to 589 AR1 ? 591 * NEMO-2 becomes a subservient of NEMO-11 593 * NEMO-1 becomes the parent-NEMO for NEMO-2 and the root-NEMO for 594 the aggregated nested mobile network 596 * NEMO-2 becomes the sub-NEMO 598 * MR1 is the root-MR for the aggregated nested mobile network 600 * MR2a is a sub-MR in the aggregated nested mobile network 602 * NEMO-2 is still multihomed to the Internet through AR1 and ARz 604 * The aggregated nested mobile network is not multihomed since 605 NEMO-2 cannot be used as a transit network for NEMO-1 607 Scenario 2: what happens when MR1's egress interface is attached to 608 AR2 ? 610 * NEMO-1 becomes a subservient of NEMO-2 612 * NEMO-1 becomes the sub-NEMO 614 * NEMO-2 becomes the parent_NEMO for NEMO-1 and also the 615 root-NEMO for the aggregated nested mobile network) 617 * MR2a and MR2b are both root-MRs for the aggregated nested 618 mobile network 620 * MR1 is a sub-MR in the aggregated nested mobile network 621 * NEMO-1 is not multihomed 623 * The aggregated nested mobile network is multihomed 625 _____________________________ 626 | | 627 | | 628 | Internet | 629 | | 630 |_____________________________| 631 __|__ __|__ __|__ 632 | | | | | | 633 | ARx | | ARy | | ARz | 634 |_____| |_____| |_____| 635 ______|__ ____|____ ___|____ 636 __|__ __|___ __|___ 637 | | | | | | 638 | MR1 | | MR2a | | MR2b | 639 |_____| |______| |______| 640 NEMO-1 _____|____ ___|__________|___ NEMO-2 641 __|__ __|__ 642 | | | | 643 | LFN | AR1 | LFN | AR2 644 |_____| |_____| 646 Fig.8: Multihomed Nested Mobile Network 648 6. Mobility Support Terms 650 6.1 Host mobility support 652 Host Mobility Support is a mechanism which maintains session 653 continuity between mobile nodes and their correspondents upon the 654 mobile host's change of point of attachment. It could be achieved by 655 Mobile IPv6. 657 6.2 Network Mobility support (NEMO Support) 659 Network Mobility Support is a mechanism which maintains session 660 continuity between mobile network nodes and their correspondent upon 661 a mobile router's change of point of attachment. Solutions for this 662 problem are classified into NEMO Basic Support, and NEMO Extended 663 Support. 665 6.3 NEMO Basic Support 667 NEMO Basic Support is a solution to preserve session continuity by 668 means of bidirectional tunneling much like what is done using [1] for 669 mobile nodes. The solution for doing this is solely specified in [3]. 671 6.4 NEMO Extended Support 673 NEMO Extended support is to provide the necessary optimization, 674 including routing optimization between arbitrary MNNs and CNs. 676 7. New Text From Usage Draft 678 The text in this section is taken from [5] and is subject to 679 discussion on the mailing list. 681 7.1 Home Link 683 The link attached to the interface at the Home Agent on which the 684 Home Prefix is configured. The interface can be a virtual interface, 685 in which case the Home Link is a virtual Home Link. 687 7.2 Home Network 689 The Network formed by the application of the Home Prefix on the Home 690 Link. With Nemo, the concept of Home Network is extended as explained 691 below. 693 7.3 Home Address 695 With Mobile IPv6, a Home Address is derived from the Home Network 696 prefix. This is generalized in Nemo, with some limitations: A Home 697 Address can be either derived from the Home Network or from one of 698 the Mobile Router's Mobile Network prefixes. 700 7.4 MRHA Tunnel 702 The bi-directional tunnel between a Mobile Router and its Home Agent 704 7.5 Mobile Aggregated Prefix 706 An aggregation of Mobile Network Prefixes. 708 7.6 Aggregated Home Network 709 The Home Network associated with a Mobile Aggregated Prefix. This 710 Aggregation is advertised as a subnet on the Home Link, and thus used 711 as Home Network for Nemo purposes. 713 7.7 Extended Home Network 715 The network associated with the aggregation of one or more Home 716 Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home 717 Network that is a subnet, the extended Home Network is an aggregation 718 and is further subnetted. 720 7.8 Virtual Home Network 722 The Home Network associated with a Virtual Network. The Extended Home 723 Network and the Aggregated Home Network can be configured as Virtual 724 Home Network. 726 8. Miscellaneous Terms 728 8.1 Idle MNN 730 A MNN that does not engage in any communication. 732 8.2 Idle Mobile Network 734 A mobile network that does not engage in any communication outside 735 the network may be considered idle from the global Internet. This 736 doesn't preclude that MNNs are themselves idle. Internal traffic 737 between any two MNNs located in the same mobile network is not 738 concerned by this statement. 740 9. Changes since draft-nemo-terminology-00.txt 742 - NEMO will be used either as the concept for NEtwork MObility and a 743 noun meaning "NEtwork that is MObile" 745 - Added TMLR as depreciated term (everyone should use root-MR 746 instead) 748 - Added NEMO-prefix 750 - Added NEMO-link 752 - Added NEMO-enabled MR 754 - Precision that IP address of LFN, LMN, or VMN is taken from a 755 NEMO-prefix 756 - Added abbreviation E-face (Egress interface) and I-face (Ingress 757 interface) 759 - Some re-ordering of terms, and a few typos. 761 - Added some text from the usage draft [5] 763 10. Acknowledgments 765 The material presented in this document takes most of the text from 766 our former internet-drafts submitted to MobileIP WG and to the former 767 MONET BOF. Authors would therefore like to thank both Motorola Labs 768 Paris and INRIA (PLANETE team, Grenoble, France), for the opportunity 769 to bring this terminology to the IETF, and particularly Claude 770 Castelluccia (INRIA) for his advices, suggestions, and direction, 771 Alexandru Petrescu (Motorola) and Christophe Janneteau (Motorola). 773 We also acknowledge the input from Hesham Soliman (Ericsson), Mattias 774 Petterson (Ericsson), and numerous other people from the NEMO Working 775 Group 777 References 779 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 780 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 781 2003. 783 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 784 draft-ietf-seamoby-terminology-04 (work in progress), April 785 2003. 787 [3] Devarapalli, V., "Network Mobility Basic Support Protocol", 788 draft-ietf-nemo-basic-support-02 (work in progress), December 789 2003. 791 [4] Ernst, T., "Network Mobility Support Requirements", 792 draft-ietf-nemo-requirements-02 (work in progress), February 793 2004. 795 [5] Thubert, P., Wakikawa, R. and V. Devarapalli, "Examples of Basic 796 NEMO Usage", draft-thubert-nemo-basic-usages (work in progress), 797 February 2004. 799 [6] Perkins, C., "IP Mobility support", IETF RFC 2002, October 1996. 801 [7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 802 IETF RFC 2460, December 1998. 804 [8] Abley, J., Black, B. and V. Gill, "Goals for IPv6 805 Site-Multihoming Architectures", IETF RFC 3582, August 2003. 807 Authors' Addresses 809 Ernst Thierry 810 WIDE at Keio University 811 Jun Murai Lab., Keio University. 812 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 813 Kawasaki, Kanagawa 212-0054 814 Japan 816 Phone: +81-44-580-1600 817 Fax: +81-44-580-1437 818 EMail: ernst@sfc.wide.ad.jp 819 URI: http://www.sfc.wide.ad.jp/~ernst/ 821 Hong-Yon Lach 822 Motorola Labs Paris 823 Espace Technologique - Saint Aubin 824 Gif-sur-Yvette Cedex, 91 193 825 France 827 Phone: +33-169-35-25-36 828 Fax: 829 EMail: hong-yon.lach@motorola.com 830 URI: 832 Intellectual Property Statement 834 The IETF takes no position regarding the validity or scope of any 835 intellectual property or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; neither does it represent that it 839 has made any effort to identify any such rights. Information on the 840 IETF's procedures with respect to rights in standards-track and 841 standards-related documentation can be found in BCP-11. Copies of 842 claims of rights made available for publication and any assurances of 843 licenses to be made available, or the result of an attempt made to 844 obtain a general license or permission for the use of such 845 proprietary rights by implementors or users of this specification can 846 be obtained from the IETF Secretariat. 848 The IETF invites any interested party to bring to its attention any 849 copyrights, patents or patent applications, or other proprietary 850 rights which may cover technology that may be required to practice 851 this standard. Please address the information to the IETF Executive 852 Director. 854 Full Copyright Statement 856 Copyright (C) The Internet Society (2004). All Rights Reserved. 858 This document and translations of it may be copied and furnished to 859 others, and derivative works that comment on or otherwise explain it 860 or assist in its implementation may be prepared, copied, published 861 and distributed, in whole or in part, without restriction of any 862 kind, provided that the above copyright notice and this paragraph are 863 included on all such copies and derivative works. However, this 864 document itself may not be modified in any way, such as by removing 865 the copyright notice or references to the Internet Society or other 866 Internet organizations, except as needed for the purpose of 867 developing Internet standards in which case the procedures for 868 copyrights defined in the Internet Standards process must be 869 followed, or as required to translate it into languages other than 870 English. 872 The limited permissions granted above are perpetual and will not be 873 revoked by the Internet Society or its successors or assignees. 875 This document and the information contained herein is provided on an 876 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 877 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 878 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 879 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 880 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 882 Acknowledgment 884 Funding for the RFC Editor function is currently provided by the 885 Internet Society.