idnits 2.17.1 draft-schmidt-multimob-pmipv6-source-00.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 date (November 14, 2011) is 4546 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2710' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 520, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 6224 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt, Ed. 3 Internet-Draft HAW Hamburg 4 Intended status: Standards Track S. Gao 5 Expires: May 17, 2012 H. Zhang 6 Beijing Jiaotong University 7 M. Waehlisch 8 link-lab & FU Berlin 9 November 14, 2011 11 Mobile Multicast Sender Support in PMIPv6 Domains 12 draft-schmidt-multimob-pmipv6-source-00 14 Abstract 16 Multicast communication can be enabled in Proxy Mobile IPv6 domains 17 by deploying MLD Proxy functions at Mobile Access Gateways and 18 multicast routing functions at Local Mobility Anchors, or by 19 additional route optimization schemes. This document describes the 20 support of mobile multicast senders in Proxy Mobile IPv6 domains that 21 is provided by this base deployment scenario, as well as in settings 22 of further optimization. Mobile sources remain agnostic of multicast 23 mobility operations. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 17, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Base Solution for Source Mobility: Overview . . . . . . . . . 3 67 4. Base Solution for Source Mobility: Details . . . . . . . . . . 7 68 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 7 69 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 7 70 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 7 71 4.3.1. Local Mobility Anchors Operating PIM . . . . . . . . . 7 72 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.5. Efficiency of the Distribution System . . . . . . . . . . 9 74 5. Multicast Routing Throughout the Access Network . . . . . . . 9 75 5.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. BIDIR PIM . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Extended Source Mobility Schemes in PMIPv6 . . . . . . . . . . 10 78 6.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 12 86 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 92 [RFC6275] by network-based management functions that enable IP 93 mobility for a host without requiring its participation in any 94 mobility-related signaling. Additional network entities called the 95 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 96 responsible for managing IP mobility on behalf of the mobile node 97 (MN). An MN connected to a PMIPv6 domain, which only operates 98 according to the base specifications of [RFC5213], cannot participate 99 in multicast communication, as MAGs will discard group packets. 101 Multicast support for mobile listeners can be enabled within a PMIPv6 102 domain by deploying MLD Proxy functions at Mobile Access Gateways, 103 and multicast routing functions at Local Mobility Anchors [RFC6224]. 104 This base deployment option is the simplest way to PMIPv6 multicast 105 extensions in the sense that it neither requires new protocol 106 operations nor additional infrastructure entities. Standard software 107 functions need to be activated on PMIPv6 entities, only, on the price 108 of possibly non-optimal multicast routing. 110 Alternate solutions leverage performance optimization by providing 111 multicast routing at the access routers directly, or by other 112 dedicated schemes. 114 This document describes the support of mobile multicast senders in 115 Proxy Mobile IPv6 domains as it is provided by the base deployment 116 scenario [RFC6224], as well as optimizations throughout the access 117 network infrastructure to efficiently solve the source mobility 118 problem as discussed in [RFC5757]. Mobile Nodes in this setting 119 remain agnostic of multicast mobility operations. 121 2. Terminology 123 This document uses the terminology as defined for the mobility 124 protocols [RFC6275], [RFC5213] and [RFC5844], as well as the 125 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 127 3. Base Solution for Source Mobility: Overview 129 The reference scenario for multicast deployment in Proxy Mobile IPv6 130 domains is illustrated in Figure 1. 132 +-------------+ 133 | Multicast | 134 | Listeners | 135 +-------------+ 136 | 137 *** *** *** *** 138 * ** ** ** * 139 * * 140 * Fixed Internet * 141 * * 142 * ** ** ** * 143 *** *** *** *** 144 / \ 145 +----+ +----+ 146 |LMA1| |LMA2| Multicast Anchor 147 +----+ +----+ 148 LMAA1 | | LMAA2 149 | | 150 \\ //\\ 151 \\ // \\ 152 \\ // \\ Unicast Tunnel 153 \\ // \\ 154 \\ // \\ 155 \\ // \\ 156 Proxy-CoA1 || || Proxy-CoA2 157 +----+ +----+ 158 |MAG1| |MAG2| MLD Proxy 159 +----+ +----+ 160 | | | 161 MN-HNP1 | | MN-HNP2 | MN-HNP3 162 MN1 MN2 MN3 163 Multicast Sender + Listener(s) 165 Figure 1: Reference Network for Multicast Deployment in PMIPv6 with 166 Source Mobility 168 An MN in a PMIPv6 domain will decide on multicast data transmission 169 completely independent of its current mobility conditions. It will 170 send packets as initiated by applications, using its source address 171 with Home Network Prefix (HNP) and a multicast destination addresses 172 chosen by application needs. Multicast packets will arrive at the 173 currently active MAG via one of its downstream local (wireless) 174 links. A multicast unaware MAG would simply discard these packets in 175 the absence of a multicast forwarding information base (MFIB). 177 An MN can successfully distribute multicast data in PMIPv6, if MLD 178 proxy functions are deployed at the MAG as described in [RFC6224]. 179 In this set-up, the MLD proxy instance serving a mobile multicast 180 source has configured its upstream interface at the tunnel towards 181 MN's corresponding LMA. For each LMA, there will be a separate 182 instance of an MLD proxy. 184 According to the specifications given in [RFC4605], multicast data 185 arriving from a downstream interface of an MLD proxy will be 186 forwarded to the upstream interface and to all but the incoming 187 downstream interfaces with appropriate forwarding states for this 188 group. Thus multicast streams originating from an MN will arrive at 189 the corresponding LMA and directly at all mobile receivers co-located 190 at the same MAG. Serving as the designated multicast router or an 191 additional MLD proxy, the LMA forwards data to the fixed Internet, if 192 forwarding states are maintained through multicast routing. If the 193 LMA is acting as another MLD proxy, it will forward the multicast 194 data to its upstream interface, and based upon the downstream 195 interfaces' subscriptions accordingly. 197 In case of a handover, the MN (unaware of IP mobility) can continue 198 to send multicast packets as soon as network connectivity is 199 reconfigured. At this time, the MAG has determined the corresponding 200 LMA, and IPv6 unicast address configuration with PMIPv6 bindings have 201 been performed. Multicast packets arriving at the MAG are discarded 202 until the MAG has completed the following steps. 204 1. The MAG SHOULD determine whether the MN is admissible to 205 multicast services, and stop here otherwise. 207 2. The MAG adds the new downstream link to the MLD proxy instance 208 with up-link to the corresponding LMA. 210 As soon as the MN's uplink is associated with the corresponding MLD 211 proxy instance, multicast packets are forwarded again to the LMA and 212 eventually to receivers within the PMIP domain (see the call flow in 213 Figure 2). In this way, multicast source mobility is transparently 214 enabled in PMIPv6 domains that deploy the base scenario for 215 multicast. 217 MN1 MAG1 MN2 MAG2 LMA 218 | | | | | 219 | | Mcast Data | | | 220 | |<---------------+ | | 221 | | Mcast Data | | | 222 | Join(G) +================================================>| 223 +--------------> | | | | 224 | Mcast Data | | | | 225 |<---------------+ | | | 226 | | | | | 227 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 228 | | | | | 229 | | |--- Rtr Sol -->| | 230 | | |<-- Rtr Adv ---| | 231 | | | | | 232 | | | < MLD Proxy Configuration > | 233 | | | | | 234 | | | MLD Query | | 235 | | |<--------------+ | 236 | | | Mcast Data | | 237 | | +-------------->| | 238 | | | | Mcast Data | 239 | | | +===============>| 240 | | | | | 241 | | Mcast Data | | | 242 | |<================================================+ 243 | Mcast Data | | | | 244 |<---------------+ | | | 245 | | | | | 247 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 249 These multicast deployment considerations likewise apply for mobile 250 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 251 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 252 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 253 analogous way. 255 Following these deployment steps, multicast traffic distribution 256 transparently inter-operates with PMIPv6. It is worth noting that a 257 MN - while being attached to the same MAG as the mobile source, but 258 associated with a different LMA, cannot receive multicast traffic on 259 a shortest path. Instead, multicast streams flow up to the LMA of 260 the mobile source, are transferred to the LMA of the mobile listener 261 and tunneled downwards to the MAG again (see Appendix A for further 262 considerations). 264 4. Base Solution for Source Mobility: Details 266 Incorporating multicast source mobility in PMIPv6 requires to deploy 267 general multicast functions at PMIPv6 routers and to define their 268 interaction with the PMIPv6 protocol in the following way. 270 4.1. Operations of the Mobile Node 272 A Mobile Node willing to send multicast data will proceed as if 273 attached to the fixed Internet. No specific mobility or other 274 multicast related functionalities are required at the MN. 276 4.2. Operations of the Mobile Access Gateway 278 A Mobile Access Gateway is required to have MLD proxy instances 279 deployed corresponding to each LMA, taking the corresponding tunnel 280 as its unique upstream link, cf., [RFC6224]. On the arrival of a MN, 281 the MAG decides on the mapping of downstream links to a proxy 282 instance and the upstream link to the LMA based on the regular 283 Binding Update List as maintained by PMIPv6 standard operations. 284 When multicast data is received from the MN, the MAG MUST identify 285 the corresponding proxy instance from the incoming interface and 286 forwards multicast data upstream according to [RFC4605]. 288 The MAG MAY apply special admission control to enable multicast data 289 transition from a MN. It is advisable to take special care that MLD 290 proxy implementations do not redistribute multicast data to 291 downstream interfaces without appropriate subscriptions in place. 293 4.3. Operations of the Local Mobility Anchor 295 For any MN, the Local Mobility Anchor acts as the persistent Home 296 Agent and at the same time as the default multicast upstream for the 297 corresponding MAG. It will manage and maintain a multicast 298 forwarding information base for all group traffic arriving from its 299 mobile sources. It SHOULD participate in multicast routing functions 300 that enable traffic redistribution to all adjacent LMAs within the 301 PMIPv6 domain and thereby ensure a continuous receptivity while the 302 source is in motion. 304 4.3.1. Local Mobility Anchors Operating PIM 306 Local Mobility Anchors that operate the PIM routing protocol 307 [RFC4601] will require sources to be directly connected for sending 308 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 309 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 310 are multicast sources external to the PIM-SM domain. 312 To cure this defect common to all set-ups of subsidiary domains not 313 running PIM, the LMA should act as a PIM Border Router and activate 314 the Border-bit. In this case, the DirectlyConnected(S) is treated as 315 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 316 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 317 interface from MAG to LMA is considered as not part of the PIM-SM 318 component of the LMA (see A.1 of [RFC4601] ). 320 4.4. IPv4 Support 322 An MN in a PMIPv6 domain may use an IPv4 address transparently for 323 communication as specified in [RFC5844]. For this purpose, LMAs can 324 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide 325 IPv4 support in access networks. Correspondingly, multicast 326 membership management will be performed by the MN using IGMP. For 327 multicast support on the network side, an IGMP proxy function needs 328 to be deployed at MAGs in exactly the same way as for IPv6. 329 [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ 330 MLD. Thus IPv4 support can be transparently provided following the 331 obvious deployment analogy. 333 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 334 SHOULD choose multicast signaling according to address configurations 335 on the link, but MAY submit IGMP and MLD queries in parallel, if 336 needed. It should further be noted that the infrastructure cannot 337 identify two data streams as identical when distributed via an IPv4 338 and IPv6 multicast group. Thus duplicate data may be forwarded on a 339 heterogeneous network layer. 341 A particular note is worth giving the scenario of [RFC5845] in which 342 overlapping private address spaces of different operators can be 343 hosted in a PMIP domain by using GRE encapsulation with key 344 identification. This scenario implies that unicast communication in 345 the MAG-LMA tunnel can be individually identified per MN by the GRE 346 keys. This scenario still does not impose any special treatment of 347 multicast communication for the following reasons. 349 Multicast streams from and to MNs arrive at a MAG on point-to-point 350 links (identical to unicast). between the routers and independent of 351 any individual MN. So the MAG-proxy and the LMA SHOULD NOT use GRE 352 key identifiers, but plain GRE encapsulation in multicast 353 communication (including MLD queries and reports). Multicast traffic 354 sent upstream and downstream of MAG-to-LMA tunnels proceeds as 355 router-to-router forwarding according to the multicast forwarding 356 information base (MFIB) of the MAG or LMA and independent of MN's 357 unicast addresses, while the MAG proxy instance re-distributes 358 multicast data down the point-to-point links (interfaces) according 359 to its own MFIB, independent of MN's IP addresses. 361 4.5. Efficiency of the Distribution System 363 In the following efficiency-related issues are enumerated. 365 Multicast reception at LMA In the current deployment scenario, the 366 LMA will receive all multicast traffic originating from its 367 associated MNs. There is no mechanism to suppress upstream 368 forwarding in the absence of receivers. 370 MNs on the same MAG using different LMAs For a mobile receiver and a 371 source that use different LMAs, the traffic has to go up to one 372 LMA, cross over to the other LMA, and then be tunneled back to the 373 same MAG, causing redundant flows in the access network and at the 374 MAG. 376 5. Multicast Routing Throughout the Access Network 378 There are deployment scenarios, where multicast services are 379 available throughout the access network independent of the PMIPv6 380 infrastructure. Direct multicast access can be supported by 382 o native multicast routing provided by one multicast router within a 383 flat access network and MLD proxies deployed at MAGs, 385 o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM 386 [RFC5015] deployed at the MAGs. 388 Multicast traffic distribution can be simplified in these scenarios. 389 A single proxy instance at MAGs with up-link into the multicast cloud 390 will serve as a first hop gateway into the multicast routing domain 391 and avoid traffic duplication or detour routing. Multicast routing 392 functions at MAGs will seemlessly embed PMIP mobility gateways within 393 a multicast cloud. However, mobility of the multicast source in this 394 scenario will require some multicast routing protocols to rebuild 395 distribution trees. This can cause significant service disruptions 396 or delays (see [RFC5757] for further aspects). Deployment details 397 are specific to the multicast routing protocol in use, in the 398 following described for common protocols. 400 5.1. PIM-SM 402 TODO 404 5.2. BIDIR PIM 406 TODO 408 6. Extended Source Mobility Schemes in PMIPv6 410 In this section, specific optimization approaches to multicast source 411 mobility are introduced. 413 6.1. Multiple Upstream Interface Proxy 415 Although multicast communication can be enabled in PMIPv6 domains by 416 deploying MLD Proxy functions at MAG, some disadvantages still exist. 417 Firstly, for a proxy device performing IGMP/MLD-based forwarding has 418 a single upstream interface and one or more downstream interfaces as 419 described in RFC4605, there should be many MLD Proxy functions 420 deployed at one MAG, which is complicated and then is difficult for 421 implementation and management. And then when the multicast packets 422 arrive at the MAG running multiple parallel MLD proxy functions, 423 there may be confusions for the data if there is no extra processing 424 or filtering scheme at the MAG. In addition, the route optimization 425 issue is still up in the air, that is, for a mobile receiver and a 426 source on the same MAG using different LMAs, the traffic has to go up 427 to one LMA, cross over to the other LMA, and then be tunneled back to 428 the same MAG, causing redundant flows in the access network and at 429 the MAG. Therefore, the MLD Proxy function should be extended to 430 accommodate the PMIPv6 protocol. As same as described in [RFC6224] 431 and this document (s. abobe), the MLD proxy functions are deployed at 432 the MAG, while only one MLD Proxy function is required to run at the 433 MAG and multiple upstream interfaces can be set for the MLD Proxy 434 instance, which is called Multi-Upstream Interfaces MLD Proxy 435 (MUIMP). 437 .... TODO details. 439 7. IANA Considerations 441 TODO. 443 Note to RFC Editor: this section may be removed on publication as an 444 RFC. 446 8. Security Considerations 448 This draft does not introduce additional messages or novel protocol 449 operations. Consequently, no new threats are introduced by this 450 document in addition to those identified as security concerns of 451 [RFC3810], [RFC4605], [RFC5213], and [RFC5844]. 453 However, particular attention should be paid to implications of 454 combining multicast and mobility management at network entities. As 455 this specification allows mobile nodes to initiate the creation of 456 multicast forwarding states at MAGs and LMAs while changing 457 attachments, threats of resource exhaustion at PMIP routers and 458 access networks arrive from rapid state changes, as well as from high 459 volume data streams routed into access networks of limited 460 capacities. In addition to proper authorization checks of MNs, rate 461 controls at replicators MAY be required to protect the agents and the 462 downstream networks. In particular, MLD proxy implementations at 463 MAGs SHOULD carefully procure for automatic multicast state 464 extinction on the departure of MNs, as mobile multicast listeners in 465 the PMIPv6 domain will not actively terminate group membership prior 466 to departure. 468 9. Acknowledgements 470 The authors would like to thank (in alphabetical order) Muhamma Omer 471 Farooq, Jouni Korhonen, He-Wu Li, Stig Venaas Li-Li Wang, Qian Wu, 472 Zhi-Wei Yan for advice, help and reviews of the document. 474 10. References 476 10.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 482 Listener Discovery (MLD) for IPv6", RFC 2710, 483 October 1999. 485 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 486 Thyagarajan, "Internet Group Management Protocol, Version 487 3", RFC 3376, October 2002. 489 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 490 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 492 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 493 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 494 Protocol Specification (Revised)", RFC 4601, August 2006. 496 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 497 "Internet Group Management Protocol (IGMP) / Multicast 498 Listener Discovery (MLD)-Based Multicast Forwarding 499 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 501 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 502 "Bidirectional Protocol Independent Multicast (BIDIR- 503 PIM)", RFC 5015, October 2007. 505 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 506 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 508 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 509 Mobile IPv6", RFC 5844, May 2010. 511 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 512 Deployment for Multicast Listener Support in Proxy Mobile 513 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 515 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 516 in IPv6", RFC 6275, July 2011. 518 10.2. Informative References 520 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 521 2", RFC 2236, November 1997. 523 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 524 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 525 and Brief Survey", RFC 5757, February 2010. 527 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 528 "Generic Routing Encapsulation (GRE) Key Option for Proxy 529 Mobile IPv6", RFC 5845, June 2010. 531 Appendix A. Evaluation of Traffic Flows 533 TODO 535 Appendix B. Change Log 537 The following changes have been made from version 538 draft-schmidt-multimob-pmipv6-source-00: 540 Authors' Addresses 542 Thomas C. Schmidt 543 HAW Hamburg 544 Berliner Tor 7 545 Hamburg 20099 546 Germany 548 Email: schmidt@informatik.haw-hamburg.de 549 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 551 Shuai Gao 552 Beijing Jiaotong University 553 Beijing, 554 China 556 Phone: 557 Fax: 558 Email: shgao@bjtu.edu.cn 559 URI: 561 Hong-Ke Zhang 562 Beijing Jiaotong University 563 Beijing, 564 China 566 Phone: 567 Fax: 568 Email: hkzhang@bjtu.edu.cn 569 URI: 571 Matthias Waehlisch 572 link-lab & FU Berlin 573 Hoenower Str. 35 574 Berlin 10318 575 Germany 577 Email: mw@link-lab.net