idnits 2.17.1 draft-krishnan-multimob-pmip6basicmcast-solution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 are 8 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 6, 2009) is 5406 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-13 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4831 == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mmcastv6-ps-07 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track B. Sarikaya 5 Expires: January 7, 2010 Huawei USA 6 TC. Schmidt 7 HAW Hamburg, Dept. Informatik 8 July 6, 2009 10 Proxy Mobile IPv6 Basic Multicast Support Solution 11 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 7, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes how multicast routing can be supported in 50 Proxy Mobile IPv6 in a way similar to Mobile IPv6. The Mobile Access 51 Gateway tunnels MLD messages from the mobile nodes to local mobility 52 anchor. The Local Mobility Anchor joins the multicast group and 53 starts forwarding the received multicast packets to the mobile access 54 gateway. In case of a handover the tunnel end point changes but the 55 operation remains anchored at the local mobility anchor. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview of PMIPv6 Multicast . . . . . . . . . . . . . . . . . 4 62 3.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Local Mobility Anchor Operation . . . . . . . . . . . . . . . . 5 64 4.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . . 7 66 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 More and more operators are beginning to provide wireless broadband 78 network services such as Mobile IPTV. Mobile IPTV service is an 79 audio/video (A/V) service which is combined with interactive data for 80 the related or supplementary information of A/V program using bi- 81 directional wireless broadband links. Users can enjoy the downlink 82 A/V stream and request more detailed or value-added information via 83 uplink simultaneously. Mobile IPTV service, which can also be 84 described as place-shifting IPTV service, is to ensure continuous and 85 original IPTV experiences for the users who move to the other place 86 from where he or she was originally subscribed for [ITUIPTV]. IPTV 87 strongly relies on a group distribution system available in the 88 network. 90 Apart from Mobile IPTV, packet based point-to-multipoint group voice 91 application like push to talk, content broadcasting and streaming 92 over audio and video conferencing, online multiplayer gaming, mobile 93 chat and instant messaging, file transfer to recipients of a group 94 whose members could be on the move are applications of IP multicast 95 technology for mobile users. Most of these services pose rigid real- 96 time constraints onto the network infrastructure challenging both, 97 mobility and multicast routing protocol performance [MMCASTv6-PS]. 99 Localized mobility management domain is an access network that 100 supports IP level mobility without requiring client software on the 101 mobile nodes [RFC4831]. Proxy Mobile IPv6 (PMIPv6) provides mobility 102 support to the mobile nodes (MN) in a localized mobility management 103 domain [RFC5213]. Mobile access gateway (MAG) proxies MN in mobility 104 signaling (proxy binding update/acknowledgement) with the localized 105 mobility anchor (LMA). PMIPv6 is currently an unicast mobility 106 protocol. 108 In this document we will describe how multicast routing can be 109 supported in Proxy Mobile IPv6 [RFC5213]. PMIPv6 has potential to be 110 widely used and because of this multicast mobility support in PMIPv6 111 is essential. PMIPv6 with multicast routing support can then be used 112 in Mobile IPTV and other IP multicast applications to provide 113 seamless mobility. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14 [RFC2119]. 121 This document uses the terminology defined in [RFC3775] and in NetLMM 122 Goals document [RFC4831]. 124 3. Overview of PMIPv6 Multicast 126 This document describes Local Mobility Anchor-based basic multicast 127 forwarding in Proxy Mobile IPv6. Mobility Access Gateway is not 128 enabled to support multicast routing. The base protocol only 129 supports receiver mobility. 131 When mobile node wishes to join a multicast group it sends a Mobile 132 Listener Discovery Version 2 (MLDv2) protocol Report message to its 133 Mobility Access Gateway. The mobile node MUST use the link-local 134 address as the source address to send the MLD Report and any 135 subsequent MLD messages. Mobility Access Gateway encapsulates the 136 message and forwards it to Local Mobility Anchor on the bi- 137 directional tunnel between Mobility Access Gateway and Local Mobility 138 Anchor. 140 Local Mobility Anchor decapsulates the MLD report message from the 141 Mobility Access Gateway. Local Mobility Anchor joins the group on 142 behalf of the mobile node with the upstream multicast router (MR). 143 Local Mobility Anchor sets up multicast state as multicast router for 144 the listener which is the mobile node. 146 Multicast data packets received by Local Mobility Anchor MUST be 147 encapsulated and sent to Mobility Access Gateway on the bi- 148 directional tunnel. Mobility Access Gateway decapsulates the packet 149 and sends it to the mobile node. 151 Since Mobility Access Gateway does not keep multicast state, if the 152 decapsulated packet is a multicast packet Mobility Access Gateway can 153 not send it to the mobile node. This requires Local Mobility Anchor 154 to duplicate the multicast packet for each member in the multicast 155 group and encapsulate the multicast packet with a unicast header. 156 This encapsulation is done first. Next, based on the destination 157 address (MN-HoA) the packet is encapsulated again to be sent to the 158 Mobility Access Gateway for this mobile node [RFC3344]. 160 In case of handover the new Mobility Access Gateway sends a Proxy 161 Binding Update to Local Mobility Anchor. This message will update 162 the binding cache entry so that it points for this MN-HoA to the new 163 Mobility Access Gateway's Proxy-CoA. 165 3.1. IPv4 Support 167 For mobile nodes that have IPv4 stack enabled Proxy Mobile IPv6 can 168 provide IPv4 home address mobility support 170 [I-D.ietf-netlmm-pmip6-ipv4-support]. Mobile access gateway gets an 171 IPv4 home address for the mobile node as described in 172 [I-D.ietf-netlmm-pmip6-ipv4-support]. When such a mobile node wishes 173 to join a multicast group it sends an Internet Group Management 174 Protocol version 3 (IGMPv3) Membership Report message to its Mobility 175 Access Gateway. IGMPv3 requires a valid IP source address to be used 176 as the source address of the membership report message. Mobile node 177 MUST use its home address as the source address of the membership 178 report message. 180 Mobile access gateway tunnels the report message to the local 181 mobility anchor. Local mobility anchor decapsulates the IGMP report 182 message from the Mobility Access Gateway. Local Mobility Anchor 183 joins the group on behalf of the mobile node with the upstream 184 multicast router (MR). Local Mobility Anchor sets up multicast state 185 as multicast router for the listener which is the mobile node. 187 When packets are received for the multicast group that the mobile 188 node is subscribed, local mobility anchor encapsulates each packet 189 and sends it to each mobile node on the tunnel between local mobility 190 anchor and mobile access gateway. 192 4. Local Mobility Anchor Operation 194 Local Mobility Anchor is the multicast router for all mobile nodes in 195 Proxy Mobile IPv6 domain and performs the multicast router part of 196 MLDv2 [RFC3810]. After receiving MLD Report message from the mobile 197 node, Local Mobility Anchor joins the multicast tree for this 198 multicast group with an upstream router. 200 MLDv2 nodes maintain multicast listening state per multicast address 201 which keeps track of the sources of the multicast group. This allows 202 a simple forwarding downstream of the multicast packet received from 203 one of the sources. As for the group membership, local mobility 204 anchor receives information about the receivers by sending periodic 205 queries to the mobile nodes. Since Proxy Mobile IPv6 supports Per-MN 206 prefix model the query messages and report messages are sent 207 individually to each mobile node. This means that each group can 208 have only one member on the link between local mobility anchor and 209 mobile node. However a given multicast group may have more than one 210 member each located on a different point-to-point link. 212 Local Mobility Anchor MUST maintain multicast membership status state 213 for the the mobile nodes. This state consists of a set of records of 214 the form: 216 (IPv6 multicast address, receiver list) 217 where the receiver list is a potentially long list of link-local 218 source addresses of all the mobile nodes that are currently members 219 of this multicast group. 221 When a multicast packet is received from the upstream multicast 222 router, local mobility anchor searches the multicast membership 223 status state for the source multicast address. When a match is 224 found, local mobility anchor tunnels the packet to each member in the 225 receiver list on the bi-directional tunnel between local mobility 226 anchor and mobile access gateway. For each receiver, local mobility 227 anchor searches the binding cache entry to find a match to the link 228 local source address. When a match is found, the corresponding 229 mobile access gateway address, i.e Proxy-CoA and mobile node home 230 address, i.e. MN-HoA are used in formating the tunneled packet. The 231 format of the tunneled packet is shown below (where CP stands for the 232 content provider for the multicast channel): 234 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 235 IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */ 236 IPv6 header (src=CP, dst= Multicast group) /* Multicast Packet */ 237 Upper layer protocols /* Packet Content*/ 239 Figure 1: Tunneled Multicast Packet from LMA to MAG 241 MLDv2 General Queries sent by the local mobility anchor are sent to 242 the link-local all-nodes multicast address (FF02::1). Local mobility 243 anchor MUST tunnel the general queries to each MN that has MLD 244 multicast membership state. 246 The format of the tunneled packet is shown below: 248 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 249 IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */ 250 IPv6 header (src=LMA Link-local, dst= FF02::1) /* Multicast Packet */ 251 General Query /* Packet Content*/ 253 Figure 2: Tunneled Multicast Packet from LMA to MAG 255 4.1. IPv4 Support 257 If IPv4 transport is used between mobile access gateway and local 258 mobility anchor, the format of the tunneled packet is shown below: 260 IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */ 261 IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */ 262 IPv4 header (src=CP, dst= Multicast group) /* Multicast Packet */ 263 Upper layer protocols /* Packet Content*/ 265 Figure 3: Tunneled Multicast IPv4 Packet from LMA to MAG 267 IGMP general queries are sent to all systems on this subnet multicast 268 address (224.0.0.1). Local mobility anchor MUST tunnel the general 269 queries to each MN that has IGMP multicast membership state. 271 The format of the tunneled packet is shown below if IPv4 transport is 272 used: 274 IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */ 275 IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */ 276 IPv4 header (src=IPv4-LMAA1, dst= 224.0.0.1) /* Multicast Packet */ 277 General Query /* Packet Content*/ 279 Figure 4: Tunneled Multicast IPv4 Packet from LMA to MAG 281 5. Mobile Access Gateway Operation 283 Proxy Mobile IPv6 base specification [RFC5213] requires Mobile Access 284 Gateway to not to forward the packets that are sent with the link- 285 local source address to support Duplicate Address Detection protocol. 286 However in this document we modify this in order to allow MLDv2 287 packets to be exchanged between Local Mobility Anchor and mobile 288 node. Mobile Access Gateway MUST tunnel a packet from a mobile node 289 connected to its access link with an IP destination address of FF02: 290 0:0:0:0:0:0:16 (all MLDv2-capable routers) through the bi- 291 directional tunnel established between itself and the mobile node's 292 local mobility anchor. MLDv2 also requires the source address of 293 such packets to be link-local address of the mobile node. 295 When forwarding packets sent to the mobile node, after removing the 296 outer header, if the mobile access gateway determines that the inner 297 packet is encapsulated and the source address is the local mobility 298 anchor address, it MUST remove this second outer header. The mobile 299 access gateway MUST forward the resulting packet on the connected 300 interface associated with the destination address of the second outer 301 header. 303 6. Mobile Node Operation 305 In order to receive multicast packets from the multicast groups of 306 interest, Mobile node must be MLDv2-capable. MLDv2 is run between 307 the mobile node and Local Mobility Anchor with the mobile node being 308 the multicast address listener and local mobility anchor the 309 multicast router. 311 When an application wants to join a multicast group such as receive 312 IPTV, the application makes a join socket call. This triggers MLDv2 313 layer to send Multicast Listener Report to Mobile Access Gateway 314 which tunnels it to local mobility anchor. The source address of the 315 MLDv2 Report message is mobile node's link-local address and the 316 destination address is FF02:0:0:0:0:0:0:16, i.e. MLDv2 capable 317 routers group address. Local mobility anchor as multicast router 318 joins the multicast group and gets attached to the multicast tree 319 associated with this multicast group. Multicast packets sent to the 320 multicast group address are received by the local mobility anchor 321 which tunnels them to the mobile access gateway. 323 By the time mobile node sends the first MLDv2 report message mobile 324 access gateway must have registered this mobile node to the local 325 mobility anchor. Proxy Mobile IPv6 base protocol assures that 326 mobile-node link local address is unique in the point-to-point link 327 between the mobile node and mobile access gateway and also the mobile 328 node is registered with its local mobility anchor (LMA) (using Proxy 329 Binding Update/ Acknowledgement exchange between mobile access 330 gateway and local mobility anchor) before the mobile node completes 331 the duplicate address detection (DAD) operation (Section 6.8 in 332 [RFC5213]). Mobile node MUST send MLDv2 report message after DAD 333 operation is completed. 335 7. Security Considerations 337 This draft introduces no additional messages. Compared to [RFC3810], 338 [RFC3376], [RFC5213], and [I-D.ietf-netlmm-pmip6-ipv4-support] there 339 are no additional threats to be introduced. 341 8. IANA Considerations 343 None. 345 9. Acknowledgements 347 The authors would like to thank Jouni Korhonen for his comments on 348 the mailing list. 350 10. References 352 10.1. Normative References 354 [I-D.ietf-netlmm-pmip6-ipv4-support] 355 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 356 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13 357 (work in progress), June 2009. 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 363 August 2002. 365 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 366 Thyagarajan, "Internet Group Management Protocol, Version 367 3", RFC 3376, October 2002. 369 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 370 in IPv6", RFC 3775, June 2004. 372 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 373 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 375 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 376 Management (NETLMM)", RFC 4831, April 2007. 378 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 379 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 381 10.2. Informative References 383 [ITUIPTV] Li, M., "IPTV Service Scenarios", ITU-T IPTV Focus Group 384 on IPTV FG-IPTV-DOC-0085, May 2007. 386 [MMCASTv6-PS] 387 Schmidt, TC., Waehlisch, M., and G. Fairhurst, "Multicast 388 Mobility in MIPv6: Problem Statement and Brief Survey", 389 draft-irtf-mobopts-mmcastv6-ps-07 (work in progress), 390 April 2009. 392 Authors' Addresses 394 Suresh Krishnan 395 Ericsson 396 8400 Decarie Blvd. 397 Town of Mount Royal, QC 398 Canada 400 Email: suresh.krishnan@ericsson.com 402 Behcet Sarikaya 403 Huawei USA 404 1700 Alma Dr. Suite 500 405 Plano, TX 75075 407 Email: sarikaya@ieee.org 409 Thomas C. Schmidt 410 HAW Hamburg, Dept. Informatik 411 Berliner Tor 7 412 D-20099 Hamburg, Germany 414 Email: Schmidt@informatik.haw-hamburg.de