idnits 2.17.1 draft-chan-dmm-distributed-mobility-anchoring-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2016) is 2821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-03 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-07 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-67 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM H. Chan 3 Internet-Draft X. Wei 4 Intended status: Informational Huawei Technologies 5 Expires: January 9, 2017 J. Lee 6 Sangmyung University 7 S. Jeon 8 Instituto de Telecomunicacoes 9 F. Templin 10 Boeing Research and Technology 11 July 8, 2016 13 Distributed Mobility Anchoring 14 draft-chan-dmm-distributed-mobility-anchoring-08 16 Abstract 18 This document defines distributed mobility anchoring. Multiple 19 anchors and nodes are configured with appropriate mobility functions 20 and work together to enable mobility solutions. Example solution is 21 mid-session switching of the IP prefix anchor. Without ongoing 22 session requiring session continuity, a flow can be started or re- 23 started using the new IP prefix which is allocated from the new 24 network and is therefore anchored to the new network. With ongoing 25 session, the anchoring of the prior IP prefix may be relocated to the 26 new network to enable session continuity. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 9, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 64 3. Distributed anchoring . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Distributed anchoring configurations . . . . . . . . . . 5 66 3.2. Distributed anchoring behaviors and message information 67 elements . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. Location management behaviors and message information 69 elements . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2.2. Forwarding management behaviors and message 71 information elements . . . . . . . . . . . . . . . . 10 72 4. Example mobility solutions with distributed anchoring . . . . 12 73 4.1. IP mobility support only when needed . . . . . . . . . . 12 74 4.1.1. Not needed: Changing to the new IP prefix/address . . 13 75 4.1.2. Needed: Providing IP mobility support . . . . . . . . 14 76 4.2. IP prefix/address anchor switching to the new network . . 16 77 4.2.1. Centralized control plane . . . . . . . . . . . . . . 17 78 4.2.2. Hierarchical network . . . . . . . . . . . . . . . . 20 79 4.2.3. Hierarchical network with anchoring change . . . . . 22 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 8.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 A key requirement in distributed mobility management [RFC7333] is to 91 enable traffic to avoid traversing single mobility anchor far from 92 the optimal route. Distributed mobility management solutions do not 93 make use of centrally deployed mobility anchor 94 [Paper-Distributed.Mobility]. As such, the traffic of a flow SHOULD 95 be able to change from traversing one mobility anchor to traversing 96 another mobility anchor as the mobile node moves, or when changing 97 operation and management requirements call for mobility anchor 98 switching, thus avoiding non-optimal routes. This draft proposes 99 distributed mobility anchoring to enable making such route changes. 101 Distributed mobility anchoring employs multiple anchors in the data 102 plane. In general, the control plane function may be separate from 103 the data plane functions and be centralized but may also co-located 104 with the data plane function at these distributed anchors. Different 105 configurations (Section 3.1) of distributed anchoring are then 106 possible. Yet the distributed anchors need to have expected 107 behaviors (Section 3.2). 109 A mobile node (MN) attached to an access router of a network may be 110 allocated an IP prefix which is anchored to that router. It may then 111 use the IP address configured from this prefix as the source IP 112 address to run a flow with its correspondent node (CN). When there 113 are multiple anchors, the flow may need to select the anchor when it 114 is initiated (Section 4). Using an anchor in MN's network of 115 attachment has the advantage that the packets can simply be forwarded 116 according to the forwarding table. Although the anchor is in the 117 MN's network of attachment when the flow was initiated, the MN may 118 later move to another network, so that the IP address no longer 119 belongs to the new network of attachment of the MN. Whether the flow 120 needs session continuity will determine how to ensure that the IP 121 address of the flow will be anchored to the new network of 122 attachment. If the ongoing IP flow can cope with an IP prefix/ 123 address change, the flow can be reiniated with a new IP address 124 anchored in the new network (Section 4.1.1). On the other hand, if 125 the ongoing IP flow cannot cope with such change, the IP address 126 anchoring can be moved from the original network to the new network 127 (Section 4.2). 129 2. Conventions and Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 All general mobility-related terms and their acronyms used in this 136 document are to be interpreted as defined in the Mobile IPv6 base 137 specification [RFC6275], the Proxy Mobile IPv6 specification 138 [RFC5213], and the DMM current practices and gap analysis [RFC7429]. 139 This includes terms such as mobile node (MN), correspondent node 140 (CN), home agent (HA), home address (HoA), care-of-address (CoA), 141 local mobility anchor (LMA), and mobile access gateway (MAG). 143 In addition, this document uses the following term: 145 Home network of an application session (or of an HoA): the network 146 that has allocated the IP address (HoA) used for the session 147 identifier by the application running in an MN. An MN may be 148 running multiple application sessions, and each of these sessions 149 can have a different home network. 151 IP prefix/address anchoring: An IP prefix, i.e., Home Network Prefix 152 (HNP), or address, i.e., Home Address (HoA), allocated to a mobile 153 node is topologically anchored to a node when the anchor node is 154 able to advertise a connected route into the routing 155 infrastructure for the allocated IP prefix. 157 Internetwork Location Management (LM) function: managing and keeping 158 track of the internetwork location of an MN. The location 159 information may be a binding of the IP advertised address/prefix, 160 e.g., HoA or HNP, to the IP routing address of the MN or of a node 161 that can forward packets destined to the MN. It is a control 162 plane function. 164 In a client-server protocol model, location query and update 165 messages may be exchanged between a Location Management client 166 (LMc) and a Location Management server (LMs). 168 With separation of control plane and data plane, the LM function 169 is in the control plane. It may be a logical function at the 170 control plane node, control plane anchor, or mobility controller. 172 It may be distributed or centralized. 174 Forwarding Management (FM) function: packet interception and 175 forwarding to/from the IP address/prefix assigned to the MN, based 176 on the internetwork location information, either to the 177 destination or to some other network element that knows how to 178 forward the packets to their destination. 180 This function may be used to achieve indirection. With separation 181 of control plane and data plane, FM may split into a FM function 182 in the data plane (FM-DP) and a FM function in the control plane 183 (FM-CP). 185 FM-DP may be distributed with distributed mobility management. It 186 may be a function in a data plane anchor or data plane node. 188 FM-CP may be distributed or centralized. It may be a function in 189 a control plane node, control plane anchor or mobility controller. 191 Security Management (SM) function: The security management function 192 controls security mechanisms/protocols providing access control, 193 integrity, authentication, authorization, confidentiality, etc. 194 for the control plane and data plane. 196 This function resides in all nodes such as control plane anchor, 197 data plane anchor, mobile node, and correspondent node. 199 3. Distributed anchoring 201 3.1. Distributed anchoring configurations 203 The mobility functions may be implemented in different configurations 204 of distributed anchoring in architectures separating the control and 205 data planes. The separation as described in 206 [I-D.wt-dmm-deployment-models] has defined home control plane anchor 207 (Home-CPA), home data plane anchor (Home-DPA), access control plane 208 node (Access-CPN), and access data plane node (Access-DPN), which are 209 respectively abbreviated as CPA, DPA, CPN, and DPN here. Some 210 configurations are described in [I-D.sijeon-dmm-deployment-models]. 212 Figure 1 shows 4 configurations of network-based mobility management. 213 In each configuration, an MN is allocated an IP prefix/address IP1 214 and is using IP1 to communicate with a correspondent node (CN) not 215 shown in the figure. The flow of this communication session is shown 216 as flow(IP1, ...) which uses IP1 and other parameters. 218 (a) (b) (c) (d) 219 +-----+ +-----+ 220 |LMs | |LMs | 221 +-----+ +-----+ 223 +------------+ +------------+ +------------+ +------------+ 224 |CPA: | |CPA: | |CPA: | |CPA: | 225 |FM-CP, LM | |FM-CP, LMc | |FM-CP, LMs | |FM-CP, LMp | 226 +------------+ +------------+ +------------+ +------------+ 227 +------------+ +------------+ +------------+ +------------+ 228 |DPA(IPa1): | |DPA(IPa1): | |DPA(IPa1): | |DPA(IPa1): | 229 |anchors IP1 | |anchors IP1 | |anchors IP1 | |anchors IP1 | 230 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 231 +------------+ +------------+ +------------+ +------------+ 233 +------------+ +------------+ 234 |CPN: | |CPN: | 235 |FM-CP, LMc | |FM-CP, LMc | 236 +------------+ +------------+ 237 +------------+ +------------+ 238 |DPN(IPn1): | |DPN(IPn1): | 239 |FM-DP | |FM-DP | 240 +------------+ +------------+ 242 +------------+ +------------+ +------------+ +------------+ 243 |MN(IP1) | |MN(IP1) | |MN(IP1) | |MN(IP1) | 244 |flow(IP1,..)| |flow(IP1,..)| |flow(IP1,..)| |flow(IP1,..)| 245 +------------+ +------------+ +------------+ +------------+ 247 Figure 1. (a) FM-CP and LM at CPA, FM-DP at DPA; (b) Separate LMs, 248 FM-CP and LMc at CPA, FM-DP at DPA; (c) FM-CP and LMs at CPA, FM-DP 249 at DPA, FM-CP and LMc at CPN, FM-DP at DPN; (d) Separate LMs, FM-CP 250 and LMp at CPA, FM-DP at DPA, FM-CP and LMc at CPN, FM-DP at DPN. 252 In Figures 1(a), 1(b), 1(c), and 1(d), the IP address of the MN, IP1, 253 is anchored to the DPA which has the IP prefix/address IPa1. The 254 data plane is distributed so that there may be multiple instances of 255 the DPA (not shown). The control plane may either be distributed or 256 centralized. When the CPA co-locates with the distributed DPA there 257 will be multiple instances of the co-located CPA and DPA (not shown). 259 In Figure 1(a) and Figure 1(b), the network is flat with FM-DP at the 260 distributed DPA. 262 In Figure 1(a), LM and FM-CP co-locate at CPA. Then LM may be 263 distributed or centralized according to whether the CPA is 264 distributed or centralized. 266 Figure 1(b) differs from Figure 1(a) in that the LM function is split 267 into a server LMs and a client LMc. LMc and FM-CP are at the CPA. 268 The LMs may be centralized whereas the LMc may be distributed or 269 centralized according to whether the CPA is distributed or 270 centralized. 272 In Figure 1(c) and Figure 1(d), the network is hierarchical where 273 there may be multiple DPN's for each DPA. There is FM-DP at each of 274 the distributed DPA and at each of the distributed DPN. 276 In Figure 1(c), LMs and FM-CP are at the CPA. In addition, there are 277 FM-CP and LMc at the CPN. Again, LMs may be distributed or 278 centralized according to whether the CPA is distributed or 279 centralized. The CPA may co-locate with DPA or may separate. 281 Figure 1(d) differs from Figure 1(c) in that the LMs is separated 282 out, and a proxy LMp is added between the LMs and LMc. LMp and FM-CP 283 are at the CPA. Again, there are FM-CP and LMc at the CPN. The LMs 284 may be centralized whereas the LMp may be distributed or centralized 285 according to whether the CPA is distributed or centralized. 287 Host-based variants of the mobility function configurations from 288 Figures 1(c) and 1(d) are shown in Figures 2(a) and 2(b) where the 289 role to perform mobility functions by CPN and DPN are now taken by 290 the MN. The MN then need to possess the mobility functions FM and 291 LMc. 293 (a) (b) 294 +-----+ 295 |LMs | 296 +-----+ 298 +------------+ +------------+ 299 |CPA: | |CPA: | 300 |FM-CP, LMs | |FM-CP, LMp | 301 +------------+ +------------+ 302 +------------+ +------------+ 303 |DPA(IPa1): | |DPA(IPa1): | 304 |anchors IP1 | |anchors IP1 | 305 |FM-DP | |FM-DP | 306 +------------+ +------------+ 308 +------------+ +------------+ 309 |MN(IP1) | |MN(IP1) | 310 |flow(IP1,..)| |flow(IP1,..)| 311 |FM, LMc | |FM, LMc | 312 +------------+ +------------+ 314 Figure 2. (a) FM-CP and LMs at CPA, FM-DP at DPA, FM and LMc at MN; 315 (b) Separate LMs, FM-CP and LMp at CPA, FM-DP at DPA, FM and LMc at 316 MN. 318 In Figure 2(a) and Figure 2(b), FM-DP is at the distributed DPA as 319 before. 321 In Figure 2(a), LMs and FM-CP are at the CPA. The LMs may be 322 distributed or centralized according to whether the CPA is 323 distributed or centralized. 325 Figure 2(b) differs from Figure 2(a) in that the LMs is separated out 326 and the proxy LMp is added between the LMs and LMc. LMp and FM-CP 327 are at the CPA. The FMs may be centralized whereas the LMp may be 328 distributed or centralized according to whether the CPA is 329 distributed or centralized. 331 3.2. Distributed anchoring behaviors and message information elements 333 The behaviors of distributed anchoring are defined in this section in 334 order that they may work together in expected manners to produce a 335 distributed mobility solution. The needed information elements are 336 passed as message parameters. 338 3.2.1. Location management behaviors and message information elements 340 It is seen in (Section 3.1) that 342 (1) LMs may be a separate server or may co-locate with LMc at CPA; 343 (2) LMc may be at CPA, CPN, or MN. 345 Example LM design may consists of a distributed database of LMs 346 servers in a pool of distributed servers. The location information 347 about the prefix/address of a MN is primarily at a given LMs. Peer 348 LMs may exchange the location information with each other. LMc may 349 retrieve a given record or send a given record update to LMs. 351 Location information bebaviors: 353 (LM:1) LM may manage the location information in a client-server 354 database system. The example LM database functions are: 356 (LM:1-1) LMc may query LMs about location information for a 357 prefix of MN (pull). 358 Parameters: 359 IP prefix of MN. 361 (LM:1-2) LMs may reply to LMc query about location 362 information for a prefix of MN (pull). 363 Parameters: 364 IP prefix of MN, 365 IP address of FM-DP/DPA/DPN to forward the packets 366 of the flow. 368 (LM:1-3) LMs may inform LMc about location information for a 369 prefix of MN (push). 370 Parameters: 371 IP prefix of MN, 372 IP address of FM-DP/DPA/DPN to forward the packets 373 of the flow. 375 (LM:1-4) LMc may inform LMs about update location 376 information for a prefix of MN. 377 Parameters: 378 IP prefix of MN, 379 IP address of FM-DP/DPA/DPN to forward the packets 380 of the flow. 382 (LM:2) The LM may be a distributed database with multiple LMs 383 servers. For example: 385 (LM:2-1) A LMs may join a pool of LMs servers. 387 Parameters: 388 IP address of the LMs, 389 IP prefixes for which the LMs will host the primary 390 location information. 392 (LM:2-2) LMs may query a peer LMs about location information 393 for a prefix of MN. 394 Parameters: 395 IP prefix. 397 (LM:2-3) LMs may reply to a peer LMs about location 398 information for a prefix of MN. 399 Parameters: 400 IP prefix of MN, 401 IP address of FM-DP/DPA/DPN to forward the packets 402 of the flow. 404 3.2.2. Forwarding management behaviors and message information elements 406 It is seen in (Section 3.1) that 408 (1) FM-CP may be at CPA, CPN, MN; 409 (2) FM-DP may be at DPA, DPN, MN. 411 The FM behaviors and message information elements are: 413 (FM:1) With distributed FM functions, the role of FM for a flow may 414 pass to another FM as the DPA or DPN changes. 416 (FM:2) In addition to above, a flow/session may be stateful for the 417 required information for QoS, charging, etc. are needed. 418 These states need to be transferred from the old anchor to 419 the new anchor. 421 (FM:3) An anchor may act on packets on a per flow basis and perform 422 the changes to the forwarding path upon a change of point of 423 attachment of a MN: 425 (FM:3-1) FM filters the packets up to the granularity of a 426 flow. 427 Example matching parameters are the 5-tuple of a 428 flow. 430 (FM:3-2) FM makes the necessary changes to the forwarding 431 path of a flow. 432 Example mechanism is through forwarding table 433 update activated by DHCPv6-PD. 435 (FM:3-3) FM reverts the previously made changes to the 436 forwarding path of a flow when such changes are no 437 longer needed, e.g., when ongoing flows using an IP 438 prefix/address requiring session continuity have 439 closed. 440 Example mechanism is through expiration of 441 DHCPv6-PD. 443 (FM:4) An anchor may discover and be discovered such as through an 444 anchor registration system: 446 (FM:4-1) FM registers and authenticates itself with a 447 centralized mobility controller. 448 Parameters: 449 IP address of DPA and its CPA; 450 IP prefix anchored to the DPA. 452 (FM:4-2) registration reply: acknowledge of registration and 453 echo the input parameters. 455 (FM:4-3) FM discovers the FM of another IP prefix by 456 querying the mobility controller based on the IP 457 prefix. 458 Parameters: 459 IP prefix of MN. 461 (FM:4-4) when making anchor discovery FM expects the answer 462 parameters as: IP address of DPA to which IP prefix 463 of MN is anchored; IP prefix of the corresponding 464 CPA. 466 (FM:5) With separation of control plane function and data plane 467 function, these function must work together. 469 (FM:5-1) CPA/FM-CP sends forwarding table updates to DPA/FM- 470 DP. 471 Parameters: 472 new forwarding table entries to add; 473 expired forwarding table entries to delete. 475 (FM:5-2) DPA/FM-DP sends to CPA/FM-CP about its status and 476 load. 477 Parameters: 478 state of forwarding function being active or not; 479 loading percentage. 481 (FM:6) An anchor can buffer packets of a flow in a mobility event: 483 (FM:6-1) CPA/FM-CP informs DPA/FM-DP to buffer packets of a 484 flow. 485 Trigger: 486 MN leaves DPA in a mobility event. 487 Parameters: 488 IP prefix of the flow for which packets need to be 489 buffered. 491 (FM:6-2) CPA/FM-CP on behalf of a new DPA/FM-DP informs the 492 CPA/FM-CP of the prior DPA/FM-DP that it is ready 493 to receive any buffered packets of a flow. 494 Parameters: 495 destination IP prefix of the flow's packets; 496 IP address of the new DPA. 498 4. Example mobility solutions with distributed anchoring 500 The IP prefix/address at the MN's side of a flow may be anchored at 501 the access router to which the MN is attached. For example, when an 502 MN attaches to a network (Net1) or moves to a new network (Net2), it 503 is allocated an IP prefix from that network. It configures from this 504 prefix an IP address which is typically a dynamic IP address. It 505 then uses this IP address when a flow is initiated. Packets to the 506 MN in this flow are simply forwarded according to the forwarding 507 table. 509 There may be multiple IP prefixes/addresses to choose from. They may 510 be from the same access network or different access networks. The 511 network may advertise these prefixes with cost options 512 [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the 513 one with the least cost. In addition, these IP prefixes/addresses 514 may be of different types regarding whether mobility support is 515 needed [I-D.ietf-dmm-ondemand-mobility]. A flow will need to choose 516 the appropriate one according to whether it needs IP mobility 517 support. 519 4.1. IP mobility support only when needed 521 IP mobility support may be provided only when needed instead of being 522 provided by default. The simplest configuration in this case is 523 shown in Figures 1(a) and 1(b) in Section 3.1 for which the LM and FM 524 functions are utilized only when needed. 526 A straightforward choice of mobility anchoring is for a flow to use 527 the IP prefix of the network to which the MN is attached when the 528 flow is initiated [I-D.seite-dmm-dma]. 530 4.1.1. Not needed: Changing to the new IP prefix/address 532 When IP mobility support is not needed for a flow, the LM and FM 533 functions are not utilized so that the configuration from Figures 534 1(a) and 1(b) in Section 3.1 simplifies to that shown in Figure 3. 536 Net1 Net2 538 +---------------+ +---------------+ 539 |AR1 | |AR2 | 540 +---------------+ +---------------+ 541 |CPA: | |CPA: | 542 |---------------| |---------------| 543 |DPA(IPa1): | |DPA(IPa2): | 544 |anchors IP1 | |anchors IP2 | 545 +---------------+ +---------------+ 547 +...............+ +---------------+ 548 .MN(IP1) . move |MN(IP2) | 549 .flow(IP1,...) . =======> |flow(IP2,...) | 550 +...............+ +---------------+ 552 Figure 3. Changing to the new IP prefix/address. MN running a flow 553 using IP1 in Net1 changes to running a flow using IP2 in Net2. 555 When there is no need to provide IP mobility to a flow, the flow may 556 use a new IP address acquired from a new network as the MN moves to 557 the new network. 559 Regardless of whether IP mobility is needed, if the flow has 560 terminated before the MN moves to a new network, the flow may 561 subsequently restart using the new IP address allocated from the new 562 network. 564 When session continuity is needed, even if a flow is ongoing as the 565 MN moves, it may still be desirable for the flow to change to using 566 the new IP prefix configured in the new network. The flow may then 567 close and then restart using a new IP address configured in the new 568 network. Such a change in the IP address of the flow may be enabled 569 using a higher layer mobility support which is not in the scope of 570 this document. 572 In Figure 3, a flow initiated while the MN was in Net1 has terminated 573 before the MN moves to a new network Net2. After moving to Net2, the 574 MN uses the new IP prefix anchored in Net2 to start a new flow. The 575 packets may then be forwarded without requiring IP layer mobility 576 support. 578 The call flow is outlined in Figure 4. 580 MN p-AR n-AR CN 581 |MN attaches to p-AR: | | | 582 |acquire MN-ID and profile | | 583 |--RS---------------->| | | 584 | | | | 585 |<----------RA(HNP1)--| | | 586 | | | | 587 Allocated prefix HNP1 588 IP1 address configuration 589 | | | | 590 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 591 | | | | 592 |MN detaches from p-AR| | | 593 |MN attaches to n-AR | | | 594 | | | | 595 |--RS------------------------------>| | 596 | | | | 597 |<--------------RA(HNP2)------------| | 598 | | | | 599 Allocated prefix HNP2 600 IP2 address configuration 601 | | | | 602 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 603 | | | | 605 Figure 4. A flow uses the IP allocated from the network at which the 606 MN is attached when the flow is initiated. 608 The security management function in the anchor node at a new network 609 must allow to assign a valid IP prefix/address to a mobile node. 611 4.1.2. Needed: Providing IP mobility support 613 When IP mobility is needed for a flow, the LM and FM functions in 614 Figures 1(a) and 1(b) in Section 3.1 are utilized. The mobility 615 support may be provided by IP prefix anchor switching to the new 616 network to be described in Section 4.2 or by using other mobility 617 management methods ([Paper-Distributed.Mobility.PMIP] and 618 [Paper-Distributed.Mobility.Review]). Then the flow may continue to 619 use the IP prefix from the prior network. Yet some time later, the 620 user application for the flow may be closed. If the application is 621 started again, the new flow may not need to use the prior network's 622 IP address to avoid having to invoke IP mobility support. This may 623 be the case where a permanent IP prefix/address is not used. The 624 flow may then use the new IP prefix in the network where the flow is 625 being initiated. Routing is again kept simpler without employing IP 626 mobility and will remain so as long as the MN has not moved away from 627 that network. 629 The call flow in this case is outlined in Figure 5. 631 MN p-AR n-AR CN 632 |MN attaches to p-AR: | | | 633 |acquire MN-ID and profile | | 634 |--RS---------------->| | | 635 | | | | 636 |<----------RA(HNP1)--| | | 637 | | | | 638 Allocated prefix HNP1 639 IP1 address configuration 640 | | | | 641 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 642 | | | | 643 |MN detach from p-AR | | | 644 |MN attach to n-AR | | | 645 | | | | 646 |--RS------------------------------>| | 648 IP mobility support such as that described in next sub-section 649 |<--------------RA(HNP2,HNP1)-------| | 650 | | | | 651 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 652 | | | | 653 Allocated prefix HNP2 654 IP2 address configuration 655 | | | | 656 Flow(IP1,IPcn) teminates 657 | | | | 658 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 659 | | | | 661 Figure 5. A flow uses the IP allocated from the network at which the 662 MN is attached when the flow is initiated. 664 To provide IP mobility support with distributed anchoring, the 665 distributed anchors may need to message with each other. When such 666 messaging is needed, the anchors may need to discover each other as 667 described in the FM behaviors and information elements (FM:2) in 668 Section 3.2.2. 670 Then the anchors need to properly forward the packets of the flows as 671 described in the FM behaviors and information elements (FM:1) in 672 Section 3.2.2. 674 If there are in-flight packets toward the old anchor while the MN is 675 moving to the new anchor, it may be necessary to buffer these packets 676 and then forward to the new anchor after the old anchor knows that 677 the new anchor is ready. Such are described in the FM behaviors and 678 information elements (FM:4) in Section 3.2.2. 680 4.2. IP prefix/address anchor switching to the new network 682 The IP prefix/address anchoring may move without changing the IP 683 prefix/address of the flow. Here the LM and FM functions in Figures 684 1(a) and 1(b) in Section 3.1 are implemented as shown in Figure 6. 686 Net1 Net2 688 +---------------+ +---------------+ 689 |AR1 | |AR2 | 690 +---------------+ +---------------+ 691 |CPA: | |CPA: | 692 |LM:IP1<-->IPa2 | |LM:IP1<-->IPa2 | 693 |---------------| |---------------| 694 |DPA(IPa1): | |DPA(IPa2): | 695 |anchors IP1 | move |anchors IP2,IP1| 696 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 697 +---------------+ +---------------+ 699 +...............+ +---------------+ 700 .MN(IP1) . move |MN(IP2,IP1) | 701 .flow(IP1,...) . =======> |flow(IP1,...) | 702 +...............+ +---------------+ 704 Figure 6. IP prefix/address anchor switching to the new network. MN 705 with flow using IP1 in Net1 continues to run the flow using IP1 as it 706 moves to Net2. 708 As an MN with an ongoing session moves to a new network, the flow may 709 preserve session continuity by moving the anchoring of the original 710 IP prefix/address of the flow to the new network. An example is in 711 the use of BGP UPDATE messages to change the forwarding table entries 712 as described in [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved 713 Packet Core (EPC) network in [I-D.matsushima-stateless-uplane-vepc]. 714 However, the response time and scalability of using a distributed 715 routing protocol to update forwarding tables may be controversial. 717 Use of a centralized routing protocol with a centralized control 718 plane as described in Section 4.2.1 will be more scalable. 720 The location management provides information about which IP prefix 721 from an AR in the original network is being used by a flow in which 722 AR in a new network. Such information needs to be deleted or updated 723 when such flows have closed so that the IP prefix is no longer used 724 in a different network. The LM behaviors are described in 725 Section 3.2.1. 727 The FM functions are implemented through the DHCPv6-PD protocol. 728 Here the anchor behavior to properly forward the packets for a flow 729 as described in the FM behaviors and information elements FM:1 in 730 Section 3.2.2 is realized by changing the anchor with DHCPv6-PD and 731 also by reverting such changes later after the application has 732 already closed and when the DHCPv6-PD timer expires. If there are 733 in-flight packets toward the old anchor while the MN is moving to the 734 new anchor, it may be necessary to buffer these packets and then 735 forward to the new anchor after the old anchor knows that the new 736 anchor is ready. Such are described in the FM behaviors and 737 information elements FM:4 in Section 3.2.2. The anchors may also 738 need to discover each other as described in the FM behaviors and 739 information elements FM:2. 741 The security management function in the anchor node at a new network 742 must allow to assign the original IP prefix/address used by the 743 mobile node at the previous (original) network. As the assigned 744 original IP prefix/address is to be used in the new network, the 745 security management function in the anchor node must allow to 746 advertise the prefix of the original IP address and also allow the 747 mobile node to send and receive data packets with the original IP 748 address. 750 The security management function in the mobile node must allow to 751 configure the original IP prefix/address used at the previous 752 (original) network when the original IP prefix/address is assigned by 753 the anchor node in the new network. The security management function 754 in the mobile node also allows to use the original IP address for the 755 previous flow in the new network. 757 4.2.1. Centralized control plane 759 An example of IP prefix anchor switching is in the case where Net1 760 and Net2 both belong to the same operator network with separation of 761 control and data planes ([I-D.liu-dmm-deployment-scenario] and 762 [I-D.matsushima-stateless-uplane-vepc]), where the controller may 763 send to the switches/routers the updated information of the 764 forwarding tables with the IP address anchoring of the original IP 765 prefix/address at AR1 moved to AR2 in the new network. That is, the 766 IP address anchoring in the original network which was advertising 767 the prefix will need to move to the new network. As the anchoring in 768 the new network advertises the prefix of the original IP address in 769 the new network, the forwarding tables will be updated so that 770 packets of the flow will be forwarded according to the updated 771 forwarding tables. The configuration in Figures 1(a) and 1(b) in 772 Section 3.1 for which FM-CP and LM are centralized and FM-DP's are 773 distributed. applies here. Figure 7 shows its implementation where 774 LM is a binding between the original IP prefix/address of the flow 775 and the IP address of the new DPA, whereas FM uses the DHCPv6-PD 776 protocol. 778 Net1 Net2 779 +----------------------------------------------------------------------+ 780 | CPA: | 781 | LM:IP1<-->IPa2 | 782 | FM-CP | 783 +----------------------------------------------------------------------+ 785 +---------------+ +---------------+ 786 |AR1 | |AR2 | 787 +---------------+ +---------------+ 788 |DPA(IPa1): | |DPA(IPa2): | 789 |anchors IP1 | move |anchors IP2,IP1| 790 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 791 +---------------+ +---------------+ 793 +...............+ +---------------+ 794 .MN(IP1) . move |MN(IP2,IP1) | 795 .flow(IP1,...) . =======> |flow(IP1,...) | 796 +...............+ +---------------+ 798 Figure 7. IP prefix/address anchor switching to the new network with 799 with LM and FM-CP in a centralized control plane whereas the FM-DP's 800 are distributed. 802 The call flow in Figure 8 shows that MN is allocated HNP1 when it 803 attaches to the p-AR. A flow running in MN may or may not need IP 804 mobility. If it does, it may continue to use the previous IP prefix. 805 If it does not, it may use a new IP prefix allocated from the new 806 network. 808 MN p-AR n-AR DHCP Servers CN 809 |MN attaches to p-AR: | | | | 810 |acquire MN-ID and profile | | | 811 |--RS---------------->| | | | 812 |<----------RA(HNP1)--| | | | 813 | | | Allocate MN-HNP1 | 814 IP addr config | | | | 815 | | | | | 816 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 817 | | | | | 818 |MN detach from p-AR | | | | 819 |MN attach to n-AR | | | | 820 | | | | | 821 |--RS------------------------------>| | | 822 | | | | | 823 | |------DHCPv6 release-------------->| | 824 | | | | | 825 | | |--DHCPv6 PD request->| | 826 | | |<-DHCPv6 PD reply--->| | 827 | | | | | 828 | forwarding table updates | | 829 | | | | | 830 |<--------------RA(HNP2,HNP1)-------| | | 831 | | | Allocate MN-HNP2 | 832 IP addr config | | | | 833 | | | | | 834 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 835 | | | | | 836 | Flow(IP1,IPcn,...) terminates | | | 837 | | | | | 838 | | DHCPv6-PD timeout | | 839 | | | | | 840 | forwarding table updates | | 841 | | | | | 842 | | | | | 843 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 844 | | | | | 846 Figure 8. DMM solution. MN with flow using IP1 in Net1 continues to 847 run the flow using IP1 as it moves to Net2. 849 As the MN moves from p-AR to n-AR, the p-AR as a DHCP client may send 850 a DHCP release message to release the HNP1. It is now necessary for 851 n-AR to learn the IP prefix of the MN from the previous network so 852 that it will be possible for Net2 to allocate both the previous 853 network prefix and the new network prefix. The network may learn the 854 previous prefix in different methods. For example, the MN may 855 provide its previous network prefix information by including it to 856 the RS message [I-D.jhlee-dmm-dnpp]. 858 Knowing that MN is using HNP1, the n-AR sends to a DHCP server a 859 DHCPv6-PD request to move the HNP1 to n-AR. The server sends to n-AR 860 a DHCPv6-PD reply to move the HNP1. Then BGP route updates will take 861 place here. 863 In addition, the MN also needs a new HNP in the new network. The 864 n-AR may now send RA to n-AR, with prefix information that includes 865 HNP1 and HNP2. The MN may then continue to use IP1. In addition, 866 the MN is allocated the prefix HNP2 with which it may configure its 867 IP addresses. Now for flows using IP1, packets destined to IP1 will 868 be forwarded to the MN via n-AR. 870 As such flows have terminated and DHCP-PD has timed out, HNP1 goes 871 back to Net1. MN will then be left with HNP2 only, which it will use 872 when it now starts a new flow. 874 The anchor behavior to properly forward the packets for a flow as 875 described in the FM behaviors and information elements (FM:1) in 876 Section 3.2.2 is realized by changing the anchor with DHCPv6-PD and 877 undoing such changes later when its timer expires and the application 878 has already closed. With the anchors being separated in control and 879 data planes with LMs and FM-CP centralized in the same control plane, 880 messaging between anchors and the discovery of anchors become 881 internal to the control plane. However, the centralized FM-CP needs 882 to communicate with the distributed FM-DP as described as described 883 in the FM behaviors and information elements (FM:3). Such may be 884 realized by the appropriate messages in [I-D.ietf-dmm-fpc-cpdp]. 885 Again, if there are in-flight packets toward the old anchor while the 886 MN is moving to the new anchor, it may be necessary to buffer these 887 packets and then forward to the new anchor after the old anchor knows 888 that the new anchor is ready. The corresponding FM behaviors and 889 information elements (FM:4) are however realized by the internal 890 behavior in the control plane together with signaling between the 891 control plane and distributed data plane. 893 4.2.2. Hierarchical network 895 The configuration for a hierarchical network is shown in Figures 1(c) 896 and 1(d) in Section 3.1. With centralized control and with a 897 centralized anchor, LM, CPA, CPN are co-located at the centralized 898 control, and there is an AR with the DPA function supporting multiple 899 forwarding switches (FW's) each with a DPN function. A mobility 900 event in this configuration involving change of FW but not of AR is 901 shown in Figure 9. 903 Here the IP prefix allocated to the MN is anchored at the access 904 router (AR) supporting the old FW to which the MN was originally 905 attached as well as the new FW to which the MN has moved. 907 The realization of LM may bet the binding between the IP prefix/ 908 address of the flow used by the MN and the IP address of the DPN to 909 which MN has moved. The implementation of FM to enable change of FW 910 without changing AR may be accomplished using tunneling between the 911 AR and the FW as described in [I-D.korhonen-dmm-local-prefix] and in 912 [I-D.templin-aerolink] or using some other L2 mobility mechanism. 914 Net1 Net2 915 +----------------------------------------------------------------------+ 916 | CPA,CPN: | 917 | LM:IP1<-->IPn2 | 918 | FM-CP | 919 +----------------------------------------------------------------------+ 921 +---------------+ 922 |AR1 | 923 +---------------+ 924 |DPA(IPa1): | 925 |anchors IP1 | 926 |FM:DHCPv6-PD | 927 +---------------+ 929 +---------------+ +---------------+ 930 |FW1 | |FW2 | 931 +---------------+ move +---------------+ 932 |DPN(IPn1): | =======> |DPN(IPn2): | 933 +---------------+ +---------------+ 935 +...............+ +---------------+ 936 .MN(IP1) . move |MN(IP2) | 937 .flow(IP1,...) . =======> |flow(IP1,...) | 938 +...............+ +---------------+ 940 Figure 9. Mobility without involving change of IP anchoring in a 941 network with hierarchy in which the IP prefix allocated to the MN is 942 anchored at an Edge Router supporting multiple access routers to 943 which the MN may connect. 945 Here, the LM behaviors and information elements described in 946 Section 3.2.1 provides information of which IP prefix from its FW 947 needs to be used by a flow using which new FW. The anchor behaviors 948 to properly forward the packets of a flow described in the FM 949 behaviors and information elements (FM:1) may be realized with PMIPv6 950 protocol ([I-D.korhonen-dmm-local-prefix]) or with AERO protocol 951 ([I-D.templin-aerolink]) to tunnel between the AR and the FW. 953 4.2.3. Hierarchical network with anchoring change 955 The configuration for a hierarchical network is still shown in 956 Figures 1(c) and 1(d) in Section 3.1. Again, with centralized 957 control and with a centralized anchor, LM, CPA, CPN are co-located at 958 the centralized control, and there is an AR with the DPA function 959 supporting multiple forwarding switches (FW's) each with a DPN 960 function. However, the mobility event involving change of FW may 961 also involve a change of AR. Such configuration is shown in 962 Figure 10. 964 This deployment case involves both a change of anchor from AR1 to AR2 965 and a network hierarchy AR-FW. It can be realized by a combination 966 of changing the IP prefix/address anchoring from AR1 to AR2 with the 967 mechanism as described in Section 4.2.1 and then forwarding the 968 packets with network hierarchy AR-FW as described in Section 4.2.2. 970 To change AR, AR1 acting as a DHCP-PD client may exchange message 971 with the DHCP server to release the prefix IP1. Meanwhile, AR2 972 acting as a DHCP-PD client may exchange message with the DHCP server 973 to delegate the prefix IP1 to AR2. 975 Net1 Net2 976 +----------------------------------------------------------------------+ 977 | CPA,CPN: | 978 | LM:IP1<-->IPa2,IPn2 | 979 | FM-CP | 980 +----------------------------------------------------------------------+ 982 +---------------+ 983 |Aggregate Point| 984 |---------------| 985 |FM, LM | 986 +---------------+ 988 +---------------+ +---------------+ 989 |AR1 | |AR2 | 990 +---------------+ +---------------+ 991 |DPA(IPa1): | |DPA(IPa2): | 992 |anchors IP1 | move |anchors IP2,IP1| 993 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 994 +---------------+ +---------------+ 996 +---------------+ +---------------+ 997 |FW1 | |FW2 | 998 +---------------+ move +---------------+ 999 |DPN(IPn1): | =======> |DPN(IPn2): | 1000 +---------------+ +---------------+ 1002 +...............+ +---------------+ 1003 .MN(IP1) . move |MN(IP2,IP1) | 1004 .flow(IP1,...) . =======> |flow(IP1,...) | 1005 +...............+ +---------------+ 1007 Figure 10. Mobility involving change of IP anchoring in a network 1008 with hierarchy in which the IP prefix allocated to the MN is anchored 1009 at an Edge Router supporting multiple access routers to which the MN 1010 may connect. 1012 5. Security Considerations 1014 TBD 1016 6. IANA Considerations 1018 This document presents no IANA considerations. 1020 7. Contributors 1022 This document has benefited from other work on mobility solutions 1023 using BGP update, on mobility support in SDN network, on providing 1024 mobility support only when needed, and on mobility support in 1025 enterprise network. These work have been referenced. While some of 1026 these authors have taken the work to jointly write this document, 1027 others have contributed at least indirectly by writing these drafts. 1028 The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, 1029 Peter McCann, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. 1031 Valuable comments have also been received from John Kaippallimil, 1032 ChunShan Xiong, and Dapeng Liu. 1034 8. References 1036 8.1. Normative References 1038 [I-D.ietf-dmm-fpc-cpdp] 1039 Liebsch, M., Matsushima, S., Gundavelli, S., Moses, D., 1040 and L. Bertz, "Protocol for Forwarding Policy 1041 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-03 1042 (work in progress), March 2016. 1044 [I-D.ietf-dmm-ondemand-mobility] 1045 Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On 1046 Demand Mobility Management", draft-ietf-dmm-ondemand- 1047 mobility-07 (work in progress), July 2016. 1049 [I-D.jhlee-dmm-dnpp] 1050 Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", 1051 draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. 1053 [I-D.korhonen-dmm-local-prefix] 1054 Korhonen, J., Savolainen, T., and S. Gundavelli, "Local 1055 Prefix Lifetime Management for Proxy Mobile IPv6", draft- 1056 korhonen-dmm-local-prefix-01 (work in progress), July 1057 2013. 1059 [I-D.liu-dmm-deployment-scenario] 1060 Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, 1061 "Distributed mobility management deployment scenario and 1062 architecture", draft-liu-dmm-deployment-scenario-05 (work 1063 in progress), October 2015. 1065 [I-D.matsushima-stateless-uplane-vepc] 1066 Matsushima, S. and R. Wakikawa, "Stateless user-plane 1067 architecture for virtualized EPC (vEPC)", draft- 1068 matsushima-stateless-uplane-vepc-06 (work in progress), 1069 March 2016. 1071 [I-D.mccann-dmm-flatarch] 1072 McCann, P., "Authentication and Mobility Management in a 1073 Flat Architecture", draft-mccann-dmm-flatarch-00 (work in 1074 progress), March 2012. 1076 [I-D.mccann-dmm-prefixcost] 1077 McCann, P. and J. Kaippallimalil, "Communicating Prefix 1078 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 1079 (work in progress), April 2016. 1081 [I-D.seite-dmm-dma] 1082 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 1083 Anchoring", draft-seite-dmm-dma-07 (work in progress), 1084 February 2014. 1086 [I-D.sijeon-dmm-deployment-models] 1087 Jeon, S. and Y. Kim, "Deployment Models for Distributed 1088 Mobility Management", draft-sijeon-dmm-deployment- 1089 models-03 (work in progress), July 2016. 1091 [I-D.templin-aerolink] 1092 Templin, F., "Asymmetric Extended Route Optimization 1093 (AERO)", draft-templin-aerolink-67 (work in progress), 1094 June 2016. 1096 [I-D.wt-dmm-deployment-models] 1097 Gundavelli, S., "DMM Deployment Models and Architectural 1098 Considerations", draft-wt-dmm-deployment-models-00 (work 1099 in progress), April 2016. 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, 1103 DOI 10.17487/RFC2119, March 1997, 1104 . 1106 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1107 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1108 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1109 . 1111 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1112 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1113 2011, . 1115 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1116 Korhonen, "Requirements for Distributed Mobility 1117 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1118 . 1120 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1121 CJ. Bernardos, "Distributed Mobility Management: Current 1122 Practices and Gap Analysis", RFC 7429, 1123 DOI 10.17487/RFC7429, January 2015, 1124 . 1126 8.2. Informative References 1128 [Paper-Distributed.Mobility] 1129 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 1130 IP Mobility Management from the Perspective of the IETF: 1131 Motivations, Requirements, Approaches, Comparison, and 1132 Challenges", IEEE Wireless Communications, October 2013. 1134 [Paper-Distributed.Mobility.PMIP] 1135 Chan, H., "Proxy Mobile IP with Distributed Mobility 1136 Anchors", Proceedings of GlobeCom Workshop on Seamless 1137 Wireless Mobility, December 2010. 1139 [Paper-Distributed.Mobility.Review] 1140 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 1141 "Distributed and Dynamic Mobility Management in Mobile 1142 Internet: Current Approaches and Issues", February 2011. 1144 Authors' Addresses 1146 H Anthony Chan 1147 Huawei Technologies 1148 5340 Legacy Dr. Building 3 1149 Plano, TX 75024 1150 USA 1152 Email: h.a.chan@ieee.org 1153 Xinpeng Wei 1154 Huawei Technologies 1155 Xin-Xi Rd. No. 3, Haidian District 1156 Beijing, 100095 1157 P. R. China 1159 Email: weixinpeng@huawei.com 1161 Jong-Hyouk Lee 1162 Sangmyung University 1163 708 Hannuri Building 1164 Cheonan 330-720 1165 Korea 1167 Email: jonghyouk@smu.ac.kr 1169 Seil Jeon 1170 Instituto de Telecomunicacoes 1171 Campus Universitario de Santiago 1172 Aveiro 3810-193 1173 Portugal 1175 Email: seiljeon@av.it.pt 1177 Fred L. Templin 1178 Boeing Research and Technology 1179 P.O. Box 3707 1180 Seattle, WA 98124 1181 USA 1183 Email: fltemplin@acm.org