idnits 2.17.1 draft-vonhugo-multimob-dmm-context-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 19, 2013) is 4055 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (ref. '4') (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-06 == Outdated reference: A later version (-13) exists of draft-ietf-pim-explicit-tracking-05 == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-pmip-01 == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group D. von Hugo 3 Internet-Draft Telekom Innovation Laboratories 4 Intended status: Experimental H. Asaeda 5 Expires: September 20, 2013 NICT 6 P. Seite 7 France Telecom - Orange 8 March 19, 2013 10 Context Transfer for Multicast support in Distributed Mobility 11 Management (DMM) 12 draft-vonhugo-multimob-dmm-context-02 14 Abstract 16 This document describes a context transfer based concept to support 17 overarching IP multicast services applicable to various existing 18 approaches for Distributed Mobility Management. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 20, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 68 3. Handover Process . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Multicast Context Transfer Data Format . . . . . . . . . . 7 70 3.2. Multicast Context Transfer with MLD Proxy . . . . . . . . 7 71 3.3. Multicast Context Transfer with PIM-SM . . . . . . . . . . 10 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 This document describes an application of various existing approaches 83 for Distributed Mobility Management (DMM) [15] to support overarching 84 IP multicast services with Proxy Mobile IPv6 (PMIPv6) [3] and Client 85 Mobile IPv6 (MIPv6) [2], respectively. Key concept of Distributed 86 Mobility Management (DMM) in a flat network architecture where core 87 entities and functionalities are deployed in a distributed manner 88 assumes a mobile node to use the first access router (AR) it attaches 89 to as principal mobility anchor, i.e. Home Agent (HA) in MIPv6 or 90 Local Mobility Anchor (LMA) in PMIPv6. Requirements for future DMM 91 protocols are listed and discussed in [22]. Current proposals for 92 DMM based Mobility such as MIP-based Distributed Mobility Anchoring 93 (DMA) [16] and [21] as well as PMIP-based solutions for Distributed 94 Mobility Management [17], [20] ... and so forth define new AR 95 capabilities applicable to a flat architecture. Common idea of the 96 various approaches is to distribute functionalities for local 97 attachment of a MN to the network and for dynamically keeping track 98 of a MN and its current sessions, also in case of MN attachment to a 99 different AR, to all Access Routers. These ARs are denoted here by 100 DMM ARs (DARs) which are responsible for hosting (anchoring) newly 101 attached MNs and their started sessions (flows), and for relaying old 102 sessions to the MNs' previous DAR(s), respectively. Some solutions 103 refer to a common data base containing all relevant MN information 104 for retrieval which may be co-located with existing logical entities 105 such as DMM-defined Local Mobility Anchor (LMA) or a new common 106 central Mobility Database (MDB). 108 The MultiMob Base Protocol [12] specifies a mechanism for supporting 109 multicast reception within a PMIPv6 domain using Multicast Listener 110 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") [7]. 111 Several extensions have been proposed to optimize Routing or session 112 continuity during Handover of a MN. While some approaches rely on 113 the LMA anchoring of a MN to speed up the subscription process during 114 handover as proposed in [19] others apply on an extension of Context 115 Transfer Protocol (CXTP) [10] specification directly [11] or via the 116 established fast HO approach using FPMIP/FMIP [14] to support 117 forwarding of multicast group subscription and traffic data between 118 MAGs. Within a DMM-like approach where location (i.e. anchoring) and 119 access functionality can be handled by the same entity a data 120 exchange between the current AR and a prior one to ensure low delay 121 and loss could be achieved without enhancing complexity too much by 122 applying the CTXP modification directly. In case of node mobility 123 during an ongoing multicast reception session the node should be able 124 to continuously receive the multicast data through the new AR just 125 after handover completion without any MLD signaling on the new 126 wireless link. This procedure is multicast context transfer that 127 provides multicast session continuity and avoids extra packet loss 128 and session disruption. Multicast context transfer will be the 129 required function to support seamless handover, while for its 130 effective procedure, interaction with multicast communication 131 protocols should be taken into account. To synchronize multicast 132 with unicast traffic measures to prevent delay extension due to 133 waiting for multicast information should be established as proposed 134 in [19] 136 The Context Transfer Protocol (CXTP) specification [10] describes the 137 mechanism that allows better support for minimizing service 138 disruption during handover. This document proposes to extend CXTP 139 for forwarding of multicast context transfer in a DMM domain. 140 "Multicast-Context Transfer Data (M-CTD)" message as defined in [11] 141 is applied here for transferring multicast membership states between 142 the previously attached DAR (p-DAR) to a newly attached DAR (n-DAR) 143 within a DMM domain. The context transfer is either started from the 144 n-DAR on its own after attachment of the mobile node or initiated by 145 the p-DAR after being informed by the access network of the planned 146 handover. Existing DMM proposals assume that for data exchange 147 between p-DAR and n-DAR a dedicated tunnel already is in place. 148 Details of the set-up procedure for this tunnel are therefore out of 149 scope of this document. 151 Depending on the scenario of multicast application the real-time 152 delivery of content may be more important than lossless and error- 153 free transmission. Thus to allow for temporary storage or buffering 154 at a previous access router during handover and subsequent forwarding 155 may be advantageous to some file transmission use cases whereas for 156 real-time video services such as live IPTV the focus is on low delay. 157 Here only transfer of the MN's subscription context shall be 158 considered for simplicity reasons. 160 To decide on a multicast flow quality requirements dedicated flags 161 may be defined to be stored in and retrieved from the common data 162 base or policy storage. Deteiled considerations on these parameters 163 are out of scope of this document. 165 2. Conventions and Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 168 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 169 this document are to be interpreted as described in RFC 2119 [1]. 171 The following terms used in this document are to be interpreted as 172 defined in existing proxy and client mobility protocols and in future 173 upcoming Distributed Mobility Management (DMM) protocol 174 specifications, see e.g. [15]: Distributed Access Router (DAR), 175 Mobility Data Base (MDB), Mobile Node (MN), Proxy Care-of Address 176 (Proxy-CoA), Mobile Node Identifier (MN-Identifier), Distributed 177 Binding Update (DBU), and Distributed Binding Acknowledgement (DBA). 179 3. Handover Process 181 DAR is responsible for detecting the mobile node's movements to and 182 from the access link and for initiating a per-flow binding 183 registration either as mobility anchor (primary point of attachment). 184 In case a MN attaches to the DAR which was already previously 185 assigned to another (previous or primary) DAR (p-DAR) the new DAR 186 (n-DAR) tracks the mobile node's movements to and from the access 187 link and performs signaling of the status to that p-DAR and to a 188 common MDB. In DMM Multicast, it SHOULD NOT be required for mobile 189 nodes to initiate re-subscription to multicast channels, and DAR 190 SHOULD keep multicast membership state for mobile nodes even if they 191 attach a different DAR during the ongoing session. 193 For multicast context transfer, an IGMP/MLD-based explicit membership 194 tracking function [18] MAY be enabled on DAR (whether the DAR behaves 195 as a router or proxy). The explicit tracking function enables a 196 router to keep track of downstream multicast membership state created 197 by downstream hosts attached on the router's link. When a mobile 198 node attaches to a new network, thanks to the explicit tracking 199 function, the p-DAR extracts the mobile node's multicast membership 200 state from complete multicast membership state the p-DAR has 201 maintained and transmits it to the n-DAR. 203 The assumed architecture for a DMM-based multicast mobility is shown 204 in Figure 1. 206 +--------------------+ 207 | Mobility Data Base | 208 +--------------------+ 209 / | \ 210 / | \ 211 / | \ 212 / | \ 213 +--------+ +--------+ + ------+ 214 | DAR1 |______| DAR2 |____| DAR3 | 215 | = p-DAR|______| = n-DAR| | | 216 +--------+ +--------+ +-------+ 217 | 218 +----+ 219 | MN | 220 +----+ 222 Figure 1: Distributed mobility for flat architecture 224 3.1. Multicast Context Transfer Data Format 226 Multicast Context Transfer Data (M-CTD) is a message used with CXTP 227 to transfer multicast membership state from p-DAR to n-DAR. The 228 following information is included in M-CTD to recognize mobile node's 229 membership state. 231 1. Receiver address - indicates the address of the MN sending the 232 Current-State Report. 234 2. Filter mode - indicates either INCLUDE or EXCLUDE as defined in 235 [5]. 237 3. Source addresses and multicast addresses - indicates the address 238 pairs the MN has joined. 240 The M-CTD message MUST contain the 'A' bit set as defined for the CTD 241 message format in [10] for to initiate the transmission of a reply 242 message by the new DAR. 244 The following information included in a reply to M-CTD (similar to 245 the CTDR message defined in [10]) is used to request the old DAR to 246 store still incoming multicast data, to forward them to the new DAR, 247 and finally to leave the multicast group after successful handover 248 from n-DAR to p-DAR. 250 1. Receiver address - indicates the address of the MN sending the 251 Current-State Report. 253 2. Flag indicating the p-DAR to start (B) buffering the received 254 multicast data (in case the new connection is not yet fully set 255 up), to forward (F) the buffered data after successful handover, 256 or to leave (L) the multicast groups unless there are still 257 other active subscriptions for the corresponding groups on the 258 p-DAR. 260 3. Source addresses and multicast addresses - indicates the address 261 pairs the MN has joined. 263 The M-CTDR message MUST contain the 'S' bit set as defined for the 264 CTD message format in [10] for to indicate the successful reception 265 of context data at the new DAR. 267 3.2. Multicast Context Transfer with MLD Proxy 269 This section describes the case that DAR operates as an MLD proxy, as 270 defined in [7] and specified in the base MultiMob solution [12]. 272 The MLD listener handover with CXTP and MLD proxy shown in Figure 2 273 is defined as follows. 275 1. A MN is assumed to be attached to the p-DAR wishing to receive 276 multicast content and sending the corresponding MLD Report. The 277 serving p-DAR subscribes to the group as MLD proxy and forwards 278 the multicast traffic to the MN via the access link. In case 279 the MN's multicast session is completed while being attached to 280 p-DAR no corresponding entry into the Mobility Data Base needs 281 to be created (regular IPv6 routing). However in case the MN 282 wants to maintain the multicast session (together with ongoing 283 unicast connections) during movement it either registers the 284 address configured at the p-DAR as home address, as described in 285 [21] or the p-DAR has to create a binding entry in the central 286 MDB as proposed e.g. in [20] or [16]. 288 2. When the MN moves to another DAR with the multicast session 289 ongoing the p-DAR detects the detachment and subsequently sends 290 a request to create a Binding Cache Entry for the MN in the MBD, 291 denoted by BCE Create Request (BC-Req). 293 3. After attaching a new DAR, the mobile node sends a Router 294 Solicitation (RS) as specified in [8]. In case the MN shall 295 remain unaware of any change in connectivity the n-DAR has to 296 identify the p-DAR address during retrieving the MN's BCE from 297 the mobile node's MDB e.g. via newly specified Distributed 298 Binding Update (DBU) and corresponding Acknowledgement (DBA). 299 n-DAR then sends a request for context transfer (CT-Req) to the 300 p-DAR as defined in [10]. Since the MN cannot initiate the 301 related Context Transfer Activate Request (CTAR) message that 302 may be sent by the MDB. In case the mobile node has the 303 capability and the chance to signal to the p-DAR the link status 304 and the potential new DAR address (e.g. as is specified in terms 305 of Event Services by [9]) the p-DAR will send a CTAR message to 306 n-DAR on behalf of the mobile node. Alternatively the p-DAR or 307 the n-DAR may have information on potential DARs in their 308 vicinity to which such a CTAR or CT-Req message may be 309 multicasted. 311 4. p-DAR provides together with the other feature data the 312 multicast states corresponding to the moving MN-Identifier to 313 n-DAR. p-DAR utilizes a context transfer protocol to deliver 314 MN's Policy Profile to n-DAR, and sends Multicast Context 315 Transfer Data (M-CTD) (defined in Section 3.1) to n-DAR. 317 5. If there are multicast channels the MN has subscribed but the 318 n-DAR has not yet subscribed, n-DAR subscribes via sending 319 (potentially aggregated) MLD [5][6] Membership Report messages 320 (i.e. Join) to the corresponding MDB. 322 6. After successful completion of MN attachment the n-DAR replies 323 to M-CTD with a Multicast Context Transfer Response message 324 signalling the handover completion upon which p-DAR may leave 325 the multicast group in case no other MN attached to p-DAR has 326 subscribed to that group. 328 MN p-DAR n-DAR MDB 329 | | | | 330 |-MLD Report->|==== MLD Report (aggregated Join) =======> 331 | | | | 332 |<------------|<=========== Multicast data ============== 333 | | | | 334 Detach | | | 335 | | | | 336 | |----- BC-Req ------------------------->| 337 | | | | 338 Attach | | | 339 | | | | 340 |------------- RS --------------->| | 341 | | |------- DBU ------>| 342 | | | | 343 | | |<-------DBA--------| 344 | | | | 345 | |<----- CT-Req -------------------------| 346 | | | | 347 | |------ CXTP ------>| | 348 | | M-CTD | | 349 | | |=== MLD Report ===>| 350 | | | | 351 |<----------- RA -----------------| | 352 | | | | 353 | | |<= Multicast data =| 354 | |<------ CXTP ------| | 355 | | M-CTDR | | 356 | | | | 357 |<-------- Multicast data --------| | 358 | | | | 359 | |=== potential MLD Report (leave) =====>| 360 | | | | 362 Figure 2: MLD listener handover with CXTP and MLD proxy 364 After MN attaches to n-DAR, the forwarded multicast data from p-DAR 365 will be delivered to the MN immediately. Afterwards the current 366 multicast data are delivered as received from MDB and the MN's 367 multicast membership state at the p-DAR is cancelled. 369 3.3. Multicast Context Transfer with PIM-SM 371 This section describes the case that DAR operates as a PIM-SM [4] 372 router, as described in a proposed solution [13]. 374 The MLD listener handover with CXTP and PIM-SM is identical as 375 described in Section 3.2 except that instead of "MLD report 376 (aggregated Join)" the DARs will send "PIM Join" messages and that 377 the "MLD Report (leave)" , to be sent if there are no attached mobile 378 nodes listening the multicast channels at p-DAR, is replaced by "PIM 379 Prune" message. 381 4. IANA Considerations 383 This document proposes to extent messages defined by the 384 experimental Context Transfer Protocol [10] for the sake of 385 supporting Multicast control. To achieve such a support the Context 386 Transfer Data (CTD) Message and the Context Transfer Data Reply 387 (CTDR) Message shall be modified to enable transfer of multicast 388 related data, i.e. M-CTD and M-CTDR. The such transported data 389 consist of subscription states and flags indicating specific actions 390 to the PMIP defined anchor MAG. Such extensions described in sect. 391 3.1. of this draft may require an allocation process by IANA as 392 already described in [11]. 394 5. Security Considerations 396 Security is an important issue in all kinds of mobile and wireless 397 communication to protect aspects as described in [22], i.e. both 398 access security to allow only legitimate nodes to access mobile 399 multicast service and end-to-end security of signaling messages which 400 may contain confidential data. As outlined in e.g. [22] sufficiently 401 strong protection mechanisms mut be applied. 402 Beside that to our knowledge no new security risks are introduced 403 with this concept. 405 6. Acknowledgements 407 Many of the specifications described in this document are discussed 408 and provided by the multimob mailing-list. Detailed comments by Luis 409 Miguel Contreras Murillo are gratefully acknowledged. 411 7. References 413 7.1. Normative References 415 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 416 levels", RFC 2119, March 1997. 418 [2] Perkins, C, Ed., Johnson, D., and J. Arkko, "Mobility Support 419 in IPv6", RFC 6275, July 2011. 421 [3] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., 422 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 424 [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 425 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 426 Protocol Specification (Revised)", RFC 4601, August 2006. 428 [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 429 (MLDv2) for IPv6", RFC 3810, June 2004. 431 [6] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 432 Protocols", RFC 5790, February 2010. 434 [7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 435 Group Management Protocol (IGMP) / Multicast Listener Discovery 436 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 437 RFC 4605, August 2006. 439 [8] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The 440 Relationship between Links and Subnet Prefixes", RFC 5942, 441 July 2010. 443 [9] "IEEE Standard for Local and Metropolitan Area Networks - Part 444 21: Media Independent Handover Services, IEEE LAN/MAN Std 445 802.21-2008", January 2009. 447 7.2. Informative References 449 [10] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli, 450 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 452 [11] von Hugo, D. and H. Asaeda, "Context Transfer Protocol 453 extensions for Multicast", 454 draft-vonhugo-multimob-cxtp-extension-03.txt (work in 455 progress), February 2013. 457 [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment 458 for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) 459 Domains", RFC 6224, April 2011. 461 [13] Asaeda, H. and P. Seite, "Multicast Routing Optimization by 462 PIM-SM with PMIPv6", 463 draft-asaeda-multimob-pmip6-extension-11.txt (work in 464 progress), October 2012. 466 [14] Schmidt, TC., Waehlisch, M., Koodli, R., Fairhurst, G., and D. 467 Liu, "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast 468 Handovers", 469 draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt (work in 470 progress), February 2013. 472 [15] Patil, B. (Ed.), Williams, C., and J. Korhonen, "Approaches to 473 Distributed mobility management using Mobile IPv6 and its 474 extensions", draft-patil-dmm-issues-and-approaches2dmm-00.txt 475 (work in progress), March 2012. 477 [16] Seite, P. and P. Bertin, "Distributed Mobility Anchoring", 478 draft-seite-dmm-dma-06.txt (work in progress), January 2013. 480 [17] Liu, D., Song, J., and W. Luo, "PMIP Based Distributed Mobility 481 Management Appproach", 482 draft-liu-dmm-pmip-based-approach-02.txt (work in progress), 483 March 2012. 485 [18] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking 486 Function for Multicast Routers", 487 draft-ietf-pim-explicit-tracking-05.txt (work in progress), 488 February 2013. 490 [19] Contreras, LM., Bernardos, CJ., and I. Soto, "PMIPv6 multicast 491 handover optimization by the Subscription Information 492 Acquisition through the LMA (SIAL)", 493 draft-ietf-multimob-fast-handover-03.txt (work in progress), 494 October 2012. 496 [20] Bernardos, CJ., de la Oliva, A., Giust, F., and T. Melia, "A 497 PMIPv6-based solution for Distributed Mobility Management", 498 draft-bernardos-dmm-pmip-01.txt (work in progress), March 499 2012. 501 [21] Bernardos, CJ., de la Oliva, A., and F. Giust, "A IPv6 502 Distributed Client Mobility Management approach using existing 503 mechanisms", draft-bernardos-mext-dmm-cmip-00.txt (work in 504 progress), March 2011. 506 [22] Chan, H. (Ed.) et al., "Requirements of distributed mobility 507 management", draft-ietf-dmm-requirements-03.txt, (work in 508 progress), December 2012. 510 Authors' Addresses 512 Dirk von Hugo 513 Telekom Innovation Laboratories 514 Deutsche-Telekom-Allee 7 515 Darmstadt 64295 516 Germany 518 Email: Dirk.von-Hugo@telekom.de 520 Hitoshi Asaeda 521 National Institute of Information and Communications Technology 522 Network Architecture Laboratory 523 4-2-1 Nukui-Kitamachi 524 Koganei, Tokyo 184-8795 525 Japan 527 Email: asaeda@nict.go.jp 529 Pierrick Seite 530 France Telecom - Orange 531 4, rue du Clos Courtel 532 BP 91226 533 Cesson-Sevigne 35512 534 France 536 Email: pierrick.seite@orange.com