idnits 2.17.1 draft-jhlee-netlmm-nemo-scenarios-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1223. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 IETF Trust 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 (September 20, 2008) is 5690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LFN' on line 524 -- Looks like a reference, but probably isn't: 'VMN' on line 524 -- Looks like a reference, but probably isn't: 'LMN' on line 524 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM Working Group J.-H. Lee 3 Internet-Draft B.-J. Han 4 Intended status: Informational T.-M. Chung 5 Expires: March 24, 2009 Sungkyunkwan University 6 H.-J. Lim 7 Korea Financial Security Agency 8 September 20, 2008 10 Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and 11 analysis 12 draft-jhlee-netlmm-nemo-scenarios-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 24, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 As Proxy Mobile IPv6 is deployed, a Mobile Network will be 46 initialized in or move to a Proxy Mobile IPv6 domain. In this 47 document, the scenarios of Network Mobility Basic Support within 48 Proxy Mobile IPv6 that ensure session continuance for all nodes in 49 the Mobile Network are presented. In addition, an analysis of all 50 scenarios that comprise the interactions between Network Mobility 51 Basic Support and Proxy Mobile IPv6 is provided as a guideline to 52 PMIPv6 deployments. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 58 2.1. Conventions used in this document . . . . . . . . . . . . 3 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview of scenarios . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. Scenario A.1 . . . . . . . . . . . . . . . . . . . . . 7 63 3.1.2. Scenario A.2 . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Scenario B.1 . . . . . . . . . . . . . . . . . . . . . 8 66 3.2.2. Scenario B.2 . . . . . . . . . . . . . . . . . . . . . 9 67 3.2.3. Scenario B.3 . . . . . . . . . . . . . . . . . . . . . 9 68 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.3.1. Scenario C.1 . . . . . . . . . . . . . . . . . . . . . 10 70 3.3.2. Scenario C.2 . . . . . . . . . . . . . . . . . . . . . 11 71 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.4.1. Scenario D.1 . . . . . . . . . . . . . . . . . . . . . 12 73 3.4.2. Scenario D.2 . . . . . . . . . . . . . . . . . . . . . 13 74 4. Chaining scenarios . . . . . . . . . . . . . . . . . . . . . . 13 75 5. Analysis of scenarios . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.1.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 21 80 5.1.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 24 81 5.2. Tunneling Management . . . . . . . . . . . . . . . . . . . 25 82 6. Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 25 83 7. Multihoming Considerations . . . . . . . . . . . . . . . . . . 26 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 89 Intellectual Property and Copyright Statements . . . . . . . . . . 28 91 1. Introduction 93 Network Mobility Basic Support (NBS) described in [1] provides that a 94 Mobile Network (NEMO) moves from its home link to a new link based on 95 Mobile IPv6 (MIPv6) [2]. The base protocol for NBS is MIPv6 and 96 derived scenarios therefore focused on the interactions between NBS 97 and MIPv6. As Proxy Mobile IPv6 (PMIPv6) is deployed [3], a NEMO 98 will be initialized in or move to a PMIPv6 domain. Thus, the 99 scenarios where NBS operates within PMIPv6 need to be analyzed as a 100 guideline to PMIPv6 deployments. Note that the interaction scenarios 101 between PMIPv6 and MIPv6 are presented in [4]. 103 This document specifies the scenarios where NBS operates within 104 PMIPv6 and related issues. In addition, an analysis for each 105 scenario is presented. The NEMO Route Optimization is not considered 106 in the scenarios because this document focuses on the interactions 107 between NBS and PMIPv6. 109 2. Conventions & Terminology 111 2.1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [5]. 117 2.2. Terminology 119 Terminologies related to mobility support are defined in [3] and [6]. 120 The following terminologies are frequently used in this document. 122 o Proxy Mobile IPv6 domain (PMIPv6 domain), As defined in [3], it 123 refers to the network where the mobility management is handled by 124 PMIPv6. 126 o Non-Proxy Mobile IPv6 domain (Non-PMIPv6 domain), It refers to the 127 network in where PMIPv6 is not supported. 129 o Mobile Network (NEMO): As defined in [6], it is an entire network 130 that consists of one or more subnets and involves any node (host 131 or router). A NEMO can be initialized at an Non-PMIPv6 domain or 132 at a PMIPv6 domain and move from and to different mobility 133 management domains. In this document, a NEMO is classified into 134 two types: Mobile Network-MIPv6 and Mobile Network-PMIPv6. 136 o Mobile Network-MIPv6 (NEMO-MIPv6): It is a NEMO that has been 137 initialized at an Non-PMIPv6 domain. The Home Address (HoA) of 138 NEMO-MIPv6 is configured from a prefix advertised in the home 139 link. 141 o Mobile Network-PMIPv6 (NEMO-PMIPv6): It is a NEMO that has been 142 initialized at a PMIPv6 domain. The HoA of NEMO-PMIPv6 is taken 143 from the Home Network Prefix (HNP) that is topologically anchored 144 at the Local Mobility Anchor (LMA) defined in [3]. From a 145 perspective of NEMO-PMIPv6, the LMA acts as the Home Agent (HA). 147 o Mobile Router (MR): As defined in [6], it is a router that acts as 148 a gateway in a NEMO. In this document, an MR MUST take cognizance 149 of that the current domain provides a PMIPv6 service or not. 151 o Mobile Router of Mobile Network-MIPv6 (MR-NEMO-MIPv6): It is an MR 152 that acts as a gateway in the current NEMO-MIPv6. 154 o Mobile Router of Mobile Network-PMIPv6 (MR-NEMO-PMIPv6): It is an 155 MR that acts as a gateway in the current NEMO-PMIPv6. 157 o Bi-directional Tunnel between a Mobile Router and its Home Agent 158 (MRHA tunnel): As defined in [6], it is a bi-directional tunnel 159 between an MR and its HA. In NBS, this tunnel is used to preserve 160 session continuance between the MR and the HA. 162 o Mobile Router Identifier (MR-Identifier): It is an identity for an 163 MR used in a PMIPv6 domain. Similar to Mobile Node Identifier 164 (MN-Identifier) defined in [3], mobility entities in a PMIPv6 165 domain MUST acquire and use it for identifying an MR. NAI or MAC 166 address of MR can be used as an identifier. 168 o Care-of Address of Mobile Router in Mobile Network-MIPv6 (CoA- 169 NEMO-MIPv6): It is a Care-of Address (CoA) of MR-NEMO-MIPv6 170 obtained in the new link. When a NEMO-MIPv6 enters to a PMIPv6 171 domain, the CoA is configured based on the HNP and is used as long 172 as the NEMO-MIPv6 is attached to the PMIPv6 domain. 174 o Care-of Address of Mobile Router in Mobile Network-PMIPv6 (CoA- 175 NEMO-PMIPv6): It is a CoA of MR-NEMO-PMIPv6 obtained in another 176 PMIPv6. This address is configured based on the HNP and is used 177 as long as the NEMO-PMIPv6 is attached to the PMIPv6 domain. 179 o Home Address of Mobile Router in Mobile Network-MIPv6 (HoA-NEMO- 180 MIPv6): It is a HoA of MR-NEMO-MIPv6 obtained in the home link. 182 o Home Address of Mobile Router in Mobile Network-PMIPv6 (HoA-NEMO- 183 PMIPv6): It is a HoA of MR-NEMO-PMIPv6 obtained in the home PMIPv6 184 domain. This address is configured based on the HNP defined in 185 [3]. 187 o Mobile Network Prefix (MNP): As defined in [6], it is a network 188 prefix delegated to an MR that is used to advertise in the NEMO. 190 o Mobile Network Node (MNN): As defined in [6], it represents any 191 node that exists and has an address containing the MNP in a NEMO. 192 A MNN is classified into three types: Local Fixed Node, Visiting 193 Mobile Node, and Local Mobile Node. 195 o Local Fixed Node (LFN): As defined in [6], it represents any 196 normal node that has no mobility support stack. An LFN cannot 197 change its point of attachment while communicating with other 198 nodes and its address is taken from the MNP in a NEMO. 200 o Visiting Mobile Node (VMN): As defined in [6], it represents any 201 node that has a mobility support stack. A VMN is a temporarily 202 attached node in a NEMO. From a perspective of VMN, the NEMO is a 203 foreign link in where the VMN obtains its CoA from the MNP. 205 o Local Mobile Node (LMN): As defined in [6], it represents any node 206 that has a mobility support stack. From a perspective of LMN, the 207 NEMO is a home link in where the LMN obtains its HoA from the MNP. 209 o Local Mobility Anchor existing in the home PMIPv6 doamin (LMAh): 210 It is a Local Mobility Anchor for NEMO-PMIPv6 in the home PMIPv6 211 doamin. 213 o Local Mobility Anchor existing in the visit PMIPv6 doamin (LMAv): 214 It is a Local Mobility Anchor for NEMO-PMIPv6 in the visit PMIPv6 215 doamin. 217 o AAA server existing in the home domain (AAAh): It is a AAA server 218 for a NEMO in the home domain. The AAAh is responsible for 219 authenticating and authorizing the NEMO. 221 o AAA server existing in the visit domain (AAAv): It is a AAA server 222 for a NEMO in the visit domain. The AAAv is responsible for 223 authenticating and authorizing the NEMO. The AAAv and the AAAh 224 have a security association to support security credential 225 exchanges. 227 3. Overview of scenarios 229 Several interaction scenarios between NBS and PMIPv6 exist. In the 230 following scenarios, a NEMO ensure that all MNNs keep their session 231 continuance while the NEMO moves around. The main goal of describing 232 scenarios is to show how to establish the MRHA tunnel between a NEMO 233 and its HA when the NEMO moves within PMIPv6 domains. 235 In the all scenarios, the mobility service selection option defined 236 in [7] SHOULD be used to select the PMIPv6 service by a NEMO. AAA 237 servers are used to provide secure access service and service 238 parameters when the NEMO is attached in the access link. Note that 239 the MR-Identifier is used as like as the use of the MN-Identifier. 241 3.1. Scenario A 243 As shown in Figure 1, Scenario A describes that a NEMO moves from an 244 Non-PMIPv6 domain to a PMIPv6 domain. There are two identified sub- 245 scenarios depending on the NEMO type. 247 __ 248 +-----------+ __ __ _/ \__ +----+ 249 ( Home Link ) _/ \_/ \_/ \------| CN | 250 ( ) / / +----+ 251 ( +----+ ) / Internet \__ 252 ( |HA/ |---+---\ _ _ / \ 253 ( |LMAh| | ) \__ __/ \__/ \__/ +--\------------------------+ 254 ( +----+ | ) \__/ ( +----+ +----+ ) 255 ( | ) / ( |LMAv| |AAAv| ) 256 ( +----+ | ) / _______( +----+ +----+ ) 257 ( |AAAh|---+ ) / ( //\\ <-- LMAA ) 258 ( +----+ ) / ( +-----//--\\-----+ ) 259 +-----------+ / ( ( // \\ )<-- IPv4/IPv6) 260 | ( +---//------\\---+ Network ) 261 +-------------|---------+ ( // \\ ) 262 ( Non-PMIPv6 | ) ( //<-- pCoA1 \\<-- PCoA2 ) 263 ( Domain +----+ ) ( +----+ +----+ ) 264 ( | AR | ) ( |MAG1| |MAG2| ) 265 ( +----+ ) ( +----+ +----+ ) 266 ( : ) ( : ) 267 ( : ) ( : <-- CoA-NEMO-MIPv6 ) 268 ( +------+ ==============> +------+ /CoA-NEMO-PMIPv6 ) 269 ( +------| MR |-----+ ) ( +----| MR |-----+ ) 270 ( ( +------+ ) ) ( ( +------+ ) ) 271 ( ( / : : : ) ) ( ( / : : : ) ) 272 ( ( / : : +--+ ) ) ( ( / : : +--+) ) 273 ( ( [LFN][VMN][LMN]|MR| ) ) ( ([LFN][VMN][LMN]|MR|) ) 274 ( ( +--+ ) ) ( ( +--+) ) 275 ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) PMIPv6 ) 276 ( +-------------------+ ) ( +-----------------+ Domain ) 277 +-----------------------+ +------------------------------------+ 279 Figure 1. Scenario A: a NEMO moves from an Non-PMIPv6 domain to a 280 PMIPv6 domain 282 3.1.1. Scenario A.1 284 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- 285 PMIPv6 domain moves from another Non-PMIPv6 domain to a PMIPv6 286 domain. 288 As the NEMO-MIPv6 moves from the Non-PMIPv6 domain to the PMIPv6 289 domain, it attaches to one of MAGs. Similar to the MN attachment 290 defined in [3], the NEMO-MIPv6 MUST be authenticated and authorized 291 by the deployed security service mechanism. For instance, the AAA 292 server can be used for authenticating and authorizing the MR-NEMO- 293 MIPv6 based on the MR-Identifier. The serving MAG, MAG1, sends a 294 Proxy Binding Update (PBU) message to the LMAv. Upon accepting the 295 PBU message, the LMAv sends a Proxy Binding Acknowledgement (PBA) 296 message to the MAG1. As a result of registration, a bi-directional 297 tunnel between the MAG1 and the LMAv for the NEMO-MIPv6 is 298 established. As the MAG1 adverties a Router Advertisement (RA) 299 message cotaining the HNP, the MR-NEMO-MIPv6 obtains its CoA based on 300 the HNP. In other words, the MR in NEMO-MIPv6 configues its CoA- 301 NEMO-MIPv6 from the HNP in the PMIPv6 domain. The configured CoA- 302 NEMO-MIPv6 is registered to the HA by sending Binding Update (BU) 303 message as defined in [1]. The HA on receiving the BU message 304 establishes a binding between the HoA-NEMO-MIPv6 and CoA-NEMO-MIPv6 305 of MR. As a result of establishing the binding, the HA can forward 306 the packets for NEMO-MIPv6 to the current attachement point of MR- 307 NEMO-MIPv6. 309 3.1.2. Scenario A.2 311 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 312 domain moves from an Non-PMIPv6 domain to another PMIPv6 domain. 314 As the NEMO-PMIPv6 moves from the Non-PMIPv6 domain to the PMIPv6 315 domain, it attaches to one of MAGs. Similar to Scenario A.1, after 316 successful authentication and authorization for PMIPv6 service, the 317 registration procedure between the MAG1 and the LMAv is performed. A 318 point of difference between Scenario A.1 and Scenario A.2 is that the 319 MR-NEMO-PMIPv6 registers its CoA, CoA-NEMO-PMIPv6, to the LMAh by 320 sending BU message. The LMAh on receiving the BU message sent from 321 the MR establishes a binding between the HoA-NEMO-PMIPv6 and CoA- 322 NEMO-PMIPv6 of MR. 324 3.2. Scenario B 326 This scenario describes that a NEMO moves between links in a PMIPv6 327 domain as shown in Figure 2. There are three identified sub- 328 scenarios depending on the NEMO type. 330 +-----------+ +----+ 331 ( Home Link ) | CN | 332 ( ) +----+ 333 ( +----+ ) __ / 334 ( |HA/ |---+ ) __ __ _/ \/_ 335 ( |LMAh| | ) _/ \_/ \_/ \ 336 ( +----+ +------/ / 337 ( | ) / Internet \ 338 ( +----+ | ) \ _ _ / 339 ( |AAAh|---+ ) \__ __/ \__/ \__/ 340 ( +----+ ) \__/ | 341 +-----------+ | 342 | 343 +------------------------------|---------------------------------+ 344 ( PMIPv6 +---------+ +-------+ ) 345 ( Domain |LMAv/LMAh| | AAAv/ | ) 346 ( +---------+ | AAAh | ) 347 ( // \\ <-- LMAA +-------+ ) 348 ( +-----//----\\-----+ ) 349 ( ( // \\ )<- IPv4/IPv6 ) 350 ( +---//--------\\---+ Network ) 351 ( // \\ ) 352 ( //<--pCoA1 \\<--pCoA2 ) 353 ( +----+ +----+ ) 354 ( |MAG1| |MAG2| ) 355 ( +----+ +----+ ) 356 ( CoA-NEMO-MIPv6 : : ) 357 ( /CoA-NEMO-PMIPv6 : : ) 358 ( /HoA-NEMO-PMIPv6--> : : ) 359 ( +------+ ==========> +------+ ) 360 ( +----| MR |-----+ +----| MR |-----+ ) 361 ( ( +------+ ) ( +------+ ) ) 362 ( ( / : : : ) ( / : : : ) ) 363 ( ( / : : +--+) ( / : : +--+) ) 364 ( ([LFN][VMN][LMN]|MR|) ([LFN][VMN][LMN]|MR|) ) 365 ( ( +--+) ( +--+) ) 366 ( ( MNP = A::/64 ) ( MNP = A::/64 ) ) 367 ( +-----------------+ +-----------------+ ) 368 +----------------------------------------------------------------+ 370 Figure 2. Scenario B: a NEMO moves between links in a PMIPv6 domain 372 3.2.1. Scenario B.1 374 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- 375 PMIPv6 domain moves between links in a PMIPv6 domain. 377 This scenario is an extension of Scenario A.1. As described in 378 Scenario A.1, the NEMO-MIPv6 has been registered at both the LMAv and 379 the HA. According to [3], there is no additionally registration 380 messages by sending the MR-NEMO-MIPv6 whenever the NEMO-MIPv6 moves 381 between links in the PMIPv6 domain. The serving MAG, MAG2, sends a 382 PBU message to the LMAv to inform that the NEMO-MIPv6 has been moved 383 from the MAG1 to the MAG2. 385 3.2.2. Scenario B.2 387 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 388 domain moves between links in another PMIPv6 domain. 390 This scenario is an extension of Scenario A.2. As described in 391 Scenario A.2, the NEMO-PMIPv6 has been registered at both the LMAv 392 and the LMAh. When the NEMO-PMIPv6 attaches to the MAG2, the MAG2 393 sends a PBU message to the LMAv. 395 3.2.3. Scenario B.3 397 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 398 domain moves between links in the PMIPv6 domain. 400 When the NEMO-PMIPv6 boots up in the PMIPv6 domain, it is registered 401 to the LMAh as a result of PBU message sent from the MAG1. The MR- 402 NEMO-PMIPv6 also creates its HoA based on the RA message including 403 the HNP. The created HoA, pHoA-NEMO-PMIPv6, is used to send a BU 404 message to the LMAh. In this scenario, the LMAh acts as the HA of 405 NEMO-PMIPv6. Similar to Scenario B.2, the MAG2 sends a PBU message 406 to the LMAh when the NEMO-PMIPv6 attaches to the MAG2. 408 3.3. Scenario C 410 This scenario describes that a NEMO moves between different PMIPv6 411 domains as shown in Figure 3. There are two identified sub-scenarios 412 depending on the NEMO type. 414 +-----------+ +----+ 415 ( Home Link ) | CN | 416 ( ) +----+ 417 ( +----+ ) __ / 418 ( |HA/ |---+ ) __ __ _/ \/_ 419 ( |LMAh| | ) _/ \_/ \_/ \ 420 ( +----+ +---------/ / 421 ( | ) / Internet \ 422 ( +----+ | ) \ _ _ / 423 ( |AAAh|---+ ) \__ __/ \__/ \__/\ 424 ( +----+ ) / \__/ \____ 425 +-----------+ / \ 426 / \ 427 +-----------------/------------+ +------------\--------------+ 428 ( PMIPv6-v1 +-----+ +-----+ ) ( PMIPv6-v2 +-----+ +-----+ ) 429 ( Domain |LMAv1| |AAAv1| ) ( Domain |LMAv2| |AAAv2| ) 430 ( +-----+ +-----+ ) ( +-----+ +-----+ ) 431 ( LMAA1 --> || ) ( LMAA2 --> || ) 432 ( +-------||-------+ ) ( +-------||-------+ ) 433 ( ( IPv4 || IPv6 ) ) ( ( IPv4 || IPv6 ) ) 434 ( +-------||-------+ ) ( +-------||-------+ ) 435 ( || ) ( || ) 436 ( || <--pCoA1 ) ( || <--pCoA2 ) 437 ( +----+ ) ( +----+ ) 438 ( |MAG1| ) ( |MAG2| ) 439 ( +----+ ) ( +----+ ) 440 ( : ) ( : ) 441 ( CoA-NEMO-MIPv6 : ) ( : ) 442 ( CoA-NEMO-PMIPv6 : ) ( : ) 443 ( +-------+ ==================> +-------+ ) 444 ( +----| MR |----+ ) ( +----| MR |----+ ) 445 ( ( +-------+ ) ) ( ( +-------+ ) ) 446 ( ( / : : : ) ) ( ( / : : : ) ) 447 ( ( / : : +--+) ) ( ( / : : +--+) ) 448 ( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) ) 449 ( ( +--+) ) ( ( +--+) ) 450 ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) ) 451 ( +-----------------+ ) ( +-----------------+ ) 452 +------------------------------+ +---------------------------+ 454 Figure 3. Scenario C: a NEMO moves between different PMIPv6 domains 456 3.3.1. Scenario C.1 458 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- 459 PMIPv6 domain moves between different PMIPv6 domains. 461 As the NEMO-MIPv6 moves from a PMIPv6 domain (PMIPv6-v1 domain) to 462 another PMIPv6 domain (PMIPv6-v2 domain), the CoA-NEMO-MIPv6 is 463 changed because the serving MAG, MAG2, advertises a RA message 464 including the different HNP that is previously assigned in the 465 PMIPv6-v1 domain. Similar to Scenario A.1, there are two types of 466 registration; registering to the LMAv2 and registering to the HA. 467 For registering to the LMAv2, the MAG2 sends a PBU message to the 468 LMAv2 when the MR-NEMO-MIPv6 is attached to the MAG2. As the MR- 469 NEMO-MIPv6 receives the RA message from the MAG2, the MR sends a BU 470 message to register its new CoA-NEMO-MIPv6 to the HA. 472 3.3.2. Scenario C.2 474 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 475 domain moves between different PMIPv6 domains. 477 Similar to Scenario C.1, the MAG2 registers the NEMO-PMIPv6 to the 478 LMAv2 by sending PBU message. The MR-NEMO-PMIPv6 on receiving the RA 479 message sent from the MAG2 configures its new CoA-NEMO-PMIPv6 because 480 the contained HNP in the RA message is a different HNP compared to 481 the previous HNP. After the address configuration, the MR-NEMO- 482 PMIPv6 informs its new CoA-NEMO-PMIPv6 to the LMAh located in the 483 home domain. 485 3.4. Scenario D 487 This scenario describes that a NEMO moves from a PMIPv6 domain to an 488 Non-PMIPv6 domain as shown in Figure 4. There are two identified 489 sub-scenarios depending on the NEMO type. 491 +-----------+ +----+ 492 ( Home Link ) | CN | 493 ( ) +----+ 494 ( +----+ ) __ / 495 ( |HA/ |---+ ) __ __ _/ \/_ 496 ( |LMAh| | ) _/ \_/ \_/ \ 497 ( +----+ +------/ / 498 ( | ) / Internet \ 499 ( +----+ | ) \ _ _ /\ 500 ( |AAAh|---+ ) \__ __/ \__/ \__/ \ 501 ( +----+ ) /\__/ \ 502 +-----------+ / \_______ 503 / \ 504 +----------------/-----------------+ | 505 ( PMIPv6 +----+ ) | 506 ( Domain |LMAv| ) | 507 ( +----+ ) | 508 ( // \\ <-- LMAA ) | 509 ( +------//----\\------+ ) | 510 ( ( IPv4 // \\ IPv6 ) ) | 511 ( +----//--------\\----+ ) +----------|----------+ 512 ( // \\ ) ( Non-PMIPv6 ) 513 ( //<--pCoA1 \\<--pCoA2 ) ( Domain +----+ ) 514 ( +----+ +----+ ) ( | AR | ) 515 ( |MAG1| |MAG2| ) ( +----+ ) 516 ( +----+ +----+ ) ( : ) 517 ( : ) ( : ) 518 ( CoA-NEMO-MIPv6 : ) ( : ) 519 ( CoA-NEMO-PMIPv6 +------+ ==============> +------+ ) 520 ( +----| MR |-----+ ) ( +----| MR |-----+ ) 521 ( ( +------+ ) ) ( ( +------+ ) ) 522 ( ( / : : : ) ) ( ( / : : : ) ) 523 ( ( / : : +--+) ) ( ( / : : +--+) ) 524 ( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) ) 525 ( ( +--+) ) ( ( +--+) ) 526 ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) ) 527 ( +-----------------+ ) ( +-----------------+ ) 528 +----------------------------------+ +---------------------+ 530 Figure 4. Scenario D: a NEMO moves from a PMIPv6 domain to an Non- 531 PMIPv6 domain 533 3.4.1. Scenario D.1 535 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- 536 PMIPv6 domain moves from a PMIPv6 domain to another MIPv6 domain. 538 As the NEMO-MIPv6 attaches to a new link in the Non-PMIPv6 domain, 539 the MR-NEMO-MIPv6 receives a RA message sent from the access router 540 (AR). The MR-NEMO-MIPv6 takes cognizance of that it has been moved 541 to a new link based on the RA message. As described in [1], the MR- 542 NEMO-MIPv6 sends a BU message to its HA after the adress 543 configuration on the new link. 545 3.4.2. Scenario D.2 547 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 548 domain moves from another PMIPv6 domain to an Non-PMIPv6 domain. 550 As the NEMO-PMIPv6 attaches to a new link in the Non-PMIPv6 domain, 551 the NEMO-PMIPv6 receives a RA message sent from the AR. Similar to 552 Scenario D.1, the MR-NEMO-PMIPv6 sends a BU message to its LMAh after 553 the adress configuration on the new link. 555 4. Chaining scenarios 557 Scenarios described in Section 3 SHOULD be chained according to the 558 movement patterns of NEMO. The chaining scenarios is defined in the 559 next version of this document. 561 5. Analysis of scenarios 563 This section presents the message flows for each scenario described 564 in Section 3. Based on the message flow, the tunneling management 565 issues are presented. 567 5.1. Message Flow 569 5.1.1. Scenario A 571 As mentioned in Section 3.1, Scenario A considers the case in where a 572 NEMO moves from an Non-PMIPv6 domain to a PMIPv6 domain. 574 5.1.1.1. Scenario A.1 576 Figure 5 shows the message flow when the NEMO-MIPv6 that has been 577 initialized at an Non-PMIPv6 domain enters from another Non-PMIPv6 578 domain to a PMIPv6 domain. 580 o The NEMO-MIPv6 enters from the Non-PMIPv6 domain to a PMIPv6 581 domain. 583 o The NEMO-MIPv6 is attached to the MAG1. 585 +-----+ +----+ +------+ +------+ +------+ +----+ +----+ 586 | MNN | | MR | | MAG1 | | LMAv | | AAAv | | HA | | CN | 587 +-----+ +----+ +------+ +------+ +------+ +----+ +----+ 588 | | | | | | | 589 | Movement from | | | | | 590 | Non-PMIPv6 domain | | | | | 591 | | | | | | | 592 | L2 Attachment | | | | | 593 | | L2 Attached Event | | | | 594 | | | | | | | 595 | | Authentication | | | 596 | |<------------------------------>| | | 597 | | | Parameters | | | 598 | | |<--------------------| | | 599 | | | PBU | | | | 600 | | |--------->| | | | 601 | | | PBA | | | | 602 | | RA(HNP) |<---------| | | | 603 | |<---------| | | | | 604 | | | | | | | 605 | Address | | | | | 606 | Configuration | | | | | 607 | | | BU | | | | 608 | |------------------------------------------>| | 609 | |<------------------------------------------| | 610 | | | BA | | | | 611 | | | | | | | 612 | | MR=HA | MAG1=LMAv| MR=HA | | 613 |<-------->0<========>0<########>0<===================>0<-------->| 614 | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | 615 | | v | | | | | | 616 | [HA|MR][CN|MNN] v | | | | 617 | | [LMAv|MAG1][HA|MR][CN|MNN] | | | 618 | | | | | | | 620 Figure 5. Message Flow for Scenario A.1 622 o The authentication procedure for PMIPv6 service is done between 623 the MR-NEMO-MIPv6 and AAAv. 625 o The AAAv provides PMIPv6 service parameters including the MR- 626 Identifier and the corresponding Local Mobility Anchor Address 627 (LMAA) after successfully completing the authentication procedure. 629 o The MAG1 sends a PBU message to the LMAv. 631 o The LMAv sends a PBA message to the MAG1 after successfully 632 completing the binding registration procedure. As a result, the 633 bi-directional tunnel between the MAG1 and the LMAv is established 634 for the MR-NEMO-MIPv6. 636 o The MAG1 sends a RA message to the MR-NEMO-MIPv6. The RA message 637 includes the HNP that is the IPv6 prefix and is topologically 638 anchored at the LMAv. 640 o Based on the HNP, the MR-NEMO-MIPv6 creates its new CoA-NEMO- 641 MIPv6. 643 o The MR-NEMO-MIPv6 sends a BU message to its HA located in the home 644 domain. 646 o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA- 647 NEMO-MIPv6 of MR. 649 o Any packet destinated to the MNNs in the MR-NEMO-MIPv6 is 650 forwarded to the current attachement point of MR-NEMO-MIPv6 651 through the HA and the LMAv. 653 5.1.1.2. Scenario A.2 655 Figure 6 shows the message flow when the NEMO-PMIPv6 that has been 656 initialized at a PMIPv6 domain moves from an Non-MIPv6 domain to 657 another PMIPv6 domain. The message flow is similar to Scenario A.1. 658 Distinguishing differences are as follows. 660 o As the NEMO-PMIPv6 is attached to the MAG1, the AAAv requests the 661 authentication decision to the AAAh. 663 o As the MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 based on 664 the HNP contained in the RA message sent from the MAG1, it sends a 665 BU message to its LMAh located in the home domain. 667 o The LMAh on receiving the BU message sent from MR-NEMO-PMIPv6 668 establishes a binding between the HoA-NEMO-PMIPv6 and CoA-NEMO- 669 PMIPv6. 671 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ 672 | MNN | | MR | | MAG1 | | LMAv | | AAAv | | AAAh | |LMAh| | CN | 673 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ 674 | | | | | | | | 675 | Movement from | | | | | | 676 | Non-PMIPv6 domain| | | | | | 677 | | | | | | | | 678 | L2 Attachment | | | | | | 679 | | L2 Attached Event | | | | | 680 | | | | | | | | 681 | | Authentication Authentication | | 682 | |<--------------------------->|<------->| | | 683 | | | Parameters | Parameters | | 684 | | |<------------------|<--------| | | 685 | | | PBU | | | | | 686 | | |-------->| | | | | 687 | | | PBA | | | | | 688 | | RA(HNP) |<--------| | | | | 689 | |<--------| | | | | | 690 | | | | | | | | 691 | Address | | | | | | 692 | Configuration | | | | | | 693 | | | BU | | | | | 694 | |----------------------------------------------->| | 695 | |<-----------------------------------------------| | 696 | | | BA | | | | | 697 | | | | | | | | 698 | | MR=LMAh |MAG1=LMAv| MR=LMAh | | | 699 |<------>0<=======>0<#######>0<==========================>0<------>| 700 |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| 701 | | v | | | | | | | 702 | [LMAh|MR][CN|MNN] v | | | | | 703 | | [LMAv|MAG1][LMAh|MR][CN|MNN]| | | | 704 | | | | | | | | 706 Figure 6. Message Flow for Scenario A.2 708 5.1.2. Scenario B 710 As mentioned in Section 3.2, Scenario B considers the case in where a 711 NEMO moves between links in a PMIPv6 domain. 713 5.1.2.1. Scenario B.1 715 Figure 7 shows the message flow when the NEMO-MIPv6 that has been 716 initialized at an Non-PMIPv6 domain moves between links in a PMIPv6 717 domain. This scenario is an extension of Scenario A.1 or Scenario 718 C.1. 720 o From a perspective of the PMIPv6 domain, the MR-NEMO-MIPv6 is 721 treated as a node. As the MR-NEMO-MIPv6 is attached to the MAG2, 722 the MAG2 sends a PBU message to the LMAv on behalf of the MR-NEMO- 723 MIPv6. 725 o The MR-NEMO-MIPv6 on receiving the RA message sent from the MAG2 726 can continue to use the same address, CoA-NEMO-MIPv6, configured 727 in the previous MAG. 729 o Since the CoA-NEMO-MIPv6 is not changed, the MR-NEMO-MIPv6 does 730 not need to register its movement to the HA. According to [3], 731 the MR-NEMO-MIPv6 will always detect the same link as long as its 732 attached network is in the scope of PMIPv6 domain. 734 +-----+ +----+ +------+ +------+ +------+ +----+ +----+ 735 | MNN | | MR | | MAG2 | | LMAv | | AAAv | | HA | | CN | 736 +-----+ +----+ +------+ +------+ +------+ +----+ +----+ 737 | | | | | | | 738 | Movement from | | | | | 739 | a pervious MAG | | | | | 740 | | | | | | | 741 | L2 Attachment | | | | | 742 | | L2 Attached Event | | | | 743 | | | | | | | 744 | | Authentication | | | 745 | |<------------------------------>| | | 746 | | | Parameters | | | 747 | | |<--------------------| | | 748 | | | PBU | | | | 749 | | |--------->| | | | 750 | | | PBA | | | | 751 | | RA(HNP) |<---------| | | | 752 | |<---------| | | | | 753 | | | | | | | 754 | | MR=HA | MAG2=LMAv| MR=HA | | 755 |<-------->0<========>0<########>0<===================>0<-------->| 756 | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | 757 | | v | | | | | | 758 | [HA|MR][CN|MNN] v | | | | 759 | | [LMAv|MAG2][HA|MR][CN|MNN] | | | 760 | | | | | | | 762 Figure 7. Message Flow for Scenario B.1 764 5.1.2.2. Scenario B.2 766 Figure 8 shows the message flow when the NEMO-PMIPv6 that has been 767 initialized at a PMIPv6 domain moves between links in another PMIPv6 768 domain. This scenario is an extension of Scenario A.2 or Scenario 769 C.2. 771 o Similar to the message flow of Scenario B.1, the MR-NEMO-MIPv6 is 772 treated as a node. The movement of NEMO-PMIPv6 is detected by the 773 MAG2 and the MAG2 sends a PBU message on behalf of the MR-NEMO- 774 PMIPv6. 776 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ 777 | MNN | | MR | | MAG2 | | LMAv | | AAAv | | AAAh | |LMAh| | CN | 778 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ 779 | | | | | | | | 780 | Movement from | | | | | | 781 | a pervious MAG | | | | | | 782 | | | | | | | | 783 | L2 Attachment | | | | | | 784 | | L2 Attached Event | | | | | 785 | | | | | | | | 786 | | Authentication Authentication | | 787 | |<--------------------------->|<------->| | | 788 | | | Parameters | Parameters | | 789 | | |<------------------|<--------| | | 790 | | | PBU | | | | | 791 | | |-------->| | | | | 792 | | | PBA | | | | | 793 | | RA(HNP) |<--------| | | | | 794 | |<--------| | | | | | 795 | | | | | | | | 796 | | MR=LMAh |MAG2=LMAv| MR=LMAh | | | 797 |<------>0<=======>0<#######>0<==========================>0<------>| 798 |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| 799 | | v | | | | | | | 800 | [LMAh|MR][CN|MNN] v | | | | | 801 | | [LMAv|MAG2][LMAh|MR][CN|MNN]| | | | 802 | | | | | | | | 804 Figure 8. Message Flow for Scenario B.2 806 5.1.2.3. Scenario B.3 808 Figure 9 shows the message flow for Scenario B.3 in where the MR- 809 NEMO-PMIPv6 boots up under an MAG of the PMIPv6 domain and then moves 810 to another MAG in the same PMIPv6 domain, e.g., inter MAG handoff. 812 Since the MR-NEMO-PMIPv6 is registered by sending PBU message sent 813 from MAG1 to the LMAh, the MR-NEMO-PMIPv6 configures its HoA-NEMO- 814 PMIPv6 from the RA message sent from the MAG1. The MR-NEMO-PMIPv6 is 815 treated as a node as long as it moves in the PMIPv6 domain. 817 o As the MR-NEMO-PMIPv6 boots up in the PMIPv6 domain, it is 818 attached to the MAG1. 820 o The authentication procedure between the MR-NEMO-PMIPv6 and the 821 AAAh is done, then the MAG1 obtains PMIPv6 service parameters for 822 the MR-NEMO-PMIPv6 through the AAAh. 824 o The binding registration procedure between the MAG1 and the LMAh 825 is done. 827 o After the address configuration based on the RA message sent from 828 the MAG1, the MR-NEMO-PMIPv6 sends a BU message to the LMAh. 830 o As the MR-NEMO-PMIPv6 moves from the MAG1 to the MAG2, the MAG2 831 detects its movement. Then the further message flow is the same 832 to the case of Scenario B.2 834 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ 835 | MNN | | MR | | MAG1 | | MAG2 | | LMAh | | AAAh | | CN | 836 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ 837 | | | | | | | 838 | Boot up | | | | | 839 | | | | | | | 840 | L2 Attachment | | | | | 841 | | L2 Attached Event | | | | 842 | | | | | | | 843 | | | Authentication | | | 844 | |<----------------------------------------->| | 845 | | | Parameters | | | 846 | | |<-------------------------------| | 847 | | | PBU | | | | 848 | | |-------------------->| | | 849 | | | PBA | | | | 850 | | RA(HNP) |<--------------------| | | 851 | |<---------| | | | | 852 | Address | | | | | 853 | Configuration | | | | | 854 | | | BU | | | | 855 | |------------------------------->| | | 856 | |<-------------------------------| | | 857 | Movement from | BA | | | | 858 | MAG1 to MAG2 | | | | | 859 | | | | | | | 860 | L2 Attachment | | | | | 861 | | | L2 Attached Event | | | 862 | | | | | | | 863 | | | Authentication | | | 864 | |<----------------------------------------->| | 865 | | | | Parameters | | 866 | | | |<--------------------| | 867 | | | | PBU | | | 868 | | | |--------->| | | 869 | | | | PBA | | | 870 | | RA(HNP) | |----------| | | 871 | |<--------------------| | | | 872 | | | | | | | 873 | | | | MAG2=LMAh| | | 874 |<------------------------------>0<========>0<------------------->| 875 | [CN|MNN] | | [LMAh|MAG2][CN|MNN] | [CN|MNN] | 876 | | | | | | | 878 Figure 9. Message Flow for Scenario B.3 880 5.1.3. Scenario C 882 As mentioned in Section 3.3, Scenario C considers the case in where a 883 NEMO moves between different PMIPv6 domains, e.g., inter domain 884 handoff. 886 5.1.3.1. Scenario C.1 888 Figure 10 shows the message flow when the NEMO-MIPv6 that has been 889 initialized at an Non-PMIPv6 moves between different PMIPv6 domains. 890 Becuase this scenario represents the inter domain handoff, two types 891 of registration MUST be performed; registering to the current 892 visiting LMA (LMAv2) and registering to the HA located in the home 893 domain. This scenario is an extension of Scenarios A.1 or B.1. 895 o As the MR-NEMO-MIPv6 moves to the new PMIPv6 domain in where the 896 LMAv2 is the topological anchor point for all nodes' HNP, the MR- 897 NEMO-MIPv6 performs the authentication procedure with the AAAv2. 899 o After successfully completing the authentication procedure, the 900 serving MAG, MAG2, obtains PMIPv6 service parameters for the MR- 901 NEMO-MIPv6 via the AAAv2. 903 o The binding registration procedure between the MAG2 and the LMAv2 904 is done. 906 o The MAG2 sends a RA message to the MR-NEMO-MIPv6. 908 o The MR-NEMO-MIPv6 on receiving the RA message performs the address 909 configuration procedure and then sends a BU message to its HA. 911 o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA- 912 NEMO-MIPv6 of MR. 914 +-----+ +----+ +------+ +-------+ +-------+ +----+ +----+ 915 | MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | HA | | CN | 916 +-----+ +----+ +------+ +-------+ +-------+ +----+ +----+ 917 | | | | | | | 918 | Movement from | | | | | 919 | a PMIPv6 domain | | | | | 920 | | | | | | | 921 | L2 Attachment | | | | | 922 | | L2 Attached Event | | | | 923 | | | | | | | 924 | | Authentication | | | 925 | |<------------------------------>| | | 926 | | | Parameters | | | 927 | | |<--------------------| | | 928 | | | PBU | | | | 929 | | |--------->| | | | 930 | | | PBA | | | | 931 | | RA(HNP) |<---------| | | | 932 | |<---------| | | | | 933 | | | | | | | 934 | Address | | | | | 935 | Configuration | | | | | 936 | | | BU | | | | 937 | |------------------------------------------>| | 938 | |<------------------------------------------| | 939 | | | BA | | | | 940 | | | | | | | 941 | | MR=HA |MAG2=LMAv2| MR=HA | | 942 |<-------->0<========>0<########>0<===================>0<-------->| 943 | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | 944 | | v | | | | | | 945 | [HA|MR][CN|MNN] v | | | | 946 | | [LMAv2|MAG1][HA|MR][CN|MNN] | | | 947 | | | | | | | 949 Figure 10. Message Flow for Scenario C.1 951 5.1.3.2. Scenario C.2 953 Figure 11 shows the message flow when the NEMO-PMIPv6 that has been 954 initialized at an Non-PMIPv6 moves between different PMIPv6 domains. 955 Similar to Scenario C.1, it represents the inter domain handoff so 956 that two types of registration MUST be performed; registering to the 957 current visiting LMA (LMAv2) and registering to the LMAh located in 958 the home domain. This scenario is an extension of Scenarios A.2 or 959 B.2. The message flow is similar to Scenario C.1. Distinguishing 960 differences are as follows. 962 o As the MR-NEMO-PMIPv6 receives the RA message from the MAG2, the 963 MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a 964 BU message to its LMAh. 966 o The HA on receiving the BU message establishes a binding between 967 the HoA-NEMO-PMIPv6 and CoA-NEMO-PMIPv6 of MR. 969 +-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+ 970 | MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | AAAh | |LMAh| | CN | 971 +-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+ 972 | | | | | | | | 973 | Movement from | | | | | | 974 | a PMIPv6 domain | | | | | | 975 | | | | | | | | 976 | L2 Attachment | | | | | | 977 | | L2 Attached Event | | | | | 978 | | | | | | | | 979 | | Authentication Authentication | | 980 | |<--------------------------->|<------->| | | 981 | | | Parameters | Parameters | | 982 | | |<------------------|<--------| | | 983 | | | PBU | | | | | 984 | | |-------->| | | | | 985 | | | PBA | | | | | 986 | | RA(HNP) |<--------| | | | | 987 | |<--------| | | | | | 988 | | | | | | | | 989 | Address | | | | | | 990 | Configuration | | | | | | 991 | | | BU | | | | | 992 | |----------------------------------------------->| | 993 | |<-----------------------------------------------| | 994 | | | BA | | | | | 995 | | | | | | | | 996 | | MR=LMAh |MAG2=LMAv2 MR=LMAh | | | 997 |<------>0<=======>0<#######>0<==========================>0<------>| 998 |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| 999 | | v | | | | | | | 1000 | [LMAh|MR][CN|MNN] v | | | | | 1001 | |[LMAv2|MAG2][LMAh|MR][CN|MNN]| | | | 1002 | | | | | | | | 1004 Figure 11. Message Flow for Scenario C.2 1006 5.1.4. Scenario D 1008 As mentioned in Section 3.4, Scenario D considers the case in where a 1009 NEMO moves from a PMIPv6 to an Non-PMIPv6 domain. 1011 5.1.4.1. Scenario D.1 1013 Figure 12 shows the message flow when the NEMO-MIPv6 that has been 1014 initialized at an Non-PMIPv6 domain moves from a PMIPv6 domain to 1015 another Non-PMIPv6 domain. This scenario is an extension of 1016 Scenarios A.1 or B.1 or C.1. 1018 o As the MR-NEMO-MIPv6 moves out from a PMIPv6, the MR-NEMO-MIPv6 1019 receives the RA message sent from AR in the new link. 1021 o The MR-NEMO-MIPv6 creates its new CoA-NEMO-MIPv6 because the IPv6 1022 prefix is different from its previous prefix. In other words, the 1023 MR-NEMO-MIPv6 takes cognizance of that it has been moved to a new 1024 link based on the prefix information sent from the AR. 1026 o The MR-NEMO-MIPv6 sends a BU message to its LMAh to inform its 1027 movement. 1029 +-----+ +----+ +----+ +----+ +----+ 1030 | MNN | | MR | | AR | | HA | | CN | 1031 +-----+ +----+ +----+ +----+ +----+ 1032 | | | | | 1033 | Movement from | | | 1034 | a PMIPv6 domain | | | 1035 | | RA | | | 1036 | |<--------------| | | 1037 | | | | | 1038 | Address | | | 1039 | Configuration | | | 1040 | | | BU | | 1041 | |------------------------------>| | 1042 | |<------------------------------| | 1043 | | | BA | | 1044 | | | | | 1045 | | MR=HA | | 1046 |<------------->0<=============================>0<------------->| 1047 | [CN|MNN] | [HA|MR][CN|MNN] | [CN|MNN] | 1048 | | | | | 1050 Figure 12. Message Flow for Scenario D.1 1052 5.1.4.2. Scenario D.2 1054 Figure 13 shows the message flow when the NEMO-PMIPv6 that has been 1055 initialized at a PMIPv6 domain moves from another PMIPv6 domain to an 1056 Non-PMIPv6 domain. This scenario is an extension of Scenarios A.2 or 1057 B.2 or C.2. The message flow is similar to Scenario D.1. 1058 Distinguishing differences are as follows. 1060 o As the MR-NEMO-PMIPv6 receives the RA message from the AR, the MR- 1061 NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a BU 1062 message to its LMAh. 1064 +-----+ +----+ +----+ +----+ +----+ 1065 | MNN | | MR | | AR | |LMAh| | CN | 1066 +-----+ +----+ +----+ +----+ +----+ 1067 | | | | | 1068 | Movement from | | | 1069 | a PMIPv6 domain | | | 1070 | | RA | | | 1071 | |<--------------| | | 1072 | | | | | 1073 | Address | | | 1074 | Configuration | | | 1075 | | | BU | | 1076 | |------------------------------>| | 1077 | |<------------------------------| | 1078 | | | BA | | 1079 | | | | | 1080 | | MR=LMAh | | 1081 |<------------->0<=============================>0<------------->| 1082 | [CN|MNN] | [LMAh|MR][CN|MNN] | [CN|MNN] | 1083 | | | | | 1085 Figure 13. Message Flow for Scenario D.2 1087 5.2. Tunneling Management 1089 In the next version of this document, the tunneling management is 1090 presented. 1092 6. Returning Home 1094 In the next version of this document, the returning home case is 1095 presented. 1097 7. Multihoming Considerations 1099 The NEMO can connect to a PMIPv6 domain through multiple interfaces. 1100 In the next version of this document, the multihoming considerations 1101 are presented. 1103 8. Security Considerations 1105 TBA 1107 9. IANA Considerations 1109 TBA 1111 10. Acknowledgment 1113 Comments are solicited and should be addressed to NetLMM working 1114 group's mailing list at netlmm@ietf.org and/or the authors. 1116 This study was supported by a grant of the Korea Health 21 R&D 1117 Project, Ministry of Health & Welfare, Republic of Korea (02-PJ3-PG6- 1118 EV08-0001). 1120 11. References 1122 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1123 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1124 January 2005. 1126 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1127 IPv6", RFC 3775, June 2004. 1129 [3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 1130 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1132 [4] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios 1133 and related issues", draft-giaretta-netlmm-mip-interactions-02 1134 (work in progress), November 2007. 1136 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1137 Levels", BCP 14, RFC 2119, March 1997. 1139 [6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", 1140 RFC 4885, July 2007. 1142 [7] Damic, D., Premec, D., Patil, B., Sahasrabudhe, M., and S. 1143 Krishnan, "Proxy Mobile IPv6 indication and discovery", 1144 draft-damic-netlmm-pmip6-ind-discover-03 (work in progress), 1145 February 2008. 1147 Authors' Addresses 1149 Jong-Hyouk Lee 1150 Sungkyunkwan University 1151 26316, Engineering Building 2, Internet Management Technology Lab. 1152 Suwon-si, Gyeonggi-do, 440-746 1153 Korea 1155 Phone: +82 031 290 7222 1156 Email: jhlee@imtl.skku.ac.kr; jonghyouk@gmail.com 1158 Byung-Jin Han 1159 Sungkyunkwan University 1160 26316, Engineering Building 2, Internet Management Technology Lab. 1161 Suwon-si, Gyeonggi-do, 440-746 1162 Korea 1164 Phone: +82 031 290 7222 1165 Email: bjhan@imtl.skku.ac.kr 1167 Tai-Myoung Chung 1168 Sungkyunkwan University 1169 27328, Engineering Building 2, Internet Management Technology Lab. 1170 Suwon-si, Gyeonggi-do, 440-746 1171 Korea 1173 Phone: +82 031 290 7131 1174 Email: tmchung@ece.skku.ac.kr 1176 Hyung-Jin Lim 1177 Korea Financial Security Agency 1178 15F, 36-1, Yoido-dong, Youngdeungpo-gu 1179 Seoul, 150-886 1180 Korea 1182 Phone: +82 02 6919 9156 1183 Email: hjlim@fsa.or.kr 1185 Full Copyright Statement 1187 Copyright (C) The IETF Trust (2008). 1189 This document is subject to the rights, licenses and restrictions 1190 contained in BCP 78, and except as set forth therein, the authors 1191 retain all their rights. 1193 This document and the information contained herein are provided on an 1194 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1195 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1196 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1197 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1198 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1199 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1201 Intellectual Property 1203 The IETF takes no position regarding the validity or scope of any 1204 Intellectual Property Rights or other rights that might be claimed to 1205 pertain to the implementation or use of the technology described in 1206 this document or the extent to which any license under such rights 1207 might or might not be available; nor does it represent that it has 1208 made any independent effort to identify any such rights. Information 1209 on the procedures with respect to rights in RFC documents can be 1210 found in BCP 78 and BCP 79. 1212 Copies of IPR disclosures made to the IETF Secretariat and any 1213 assurances of licenses to be made available, or the result of an 1214 attempt made to obtain a general license or permission for the use of 1215 such proprietary rights by implementers or users of this 1216 specification can be obtained from the IETF on-line IPR repository at 1217 http://www.ietf.org/ipr. 1219 The IETF invites any interested party to bring to its attention any 1220 copyrights, patents or patent applications, or other proprietary 1221 rights that may cover technology that may be required to implement 1222 this standard. Please address the information to the IETF at 1223 ietf-ipr@ietf.org. 1225 Acknowledgment 1227 Funding for the RFC Editor function is provided by the IETF 1228 Administrative Support Activity (IASA).