idnits 2.17.1 draft-gundavelli-multimob-pmip6basicmcast-solution-01.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 4 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 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 (May 13, 2009) is 5459 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) == Unused Reference: 'RFC3376' is defined on line 331, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-12 ** 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 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track T. Schmidt 5 Expires: November 14, 2009 HAW Hamburg, Dept. Informatik 6 S. Krishnan 7 Ericsson 8 May 13, 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 November 14, 2009. 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. Mobile Access 51 Gateway tunnels MLD messages from the mobile nodes to local mobility 52 anchor. Local mobility anchor joins the multicast group and starts 53 forwarding the received multicast packets to the mobile access 54 gateway. In case of 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 . . . . . . . . . . . . . . . . 6 66 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 More and more operators are beginning to provide the wireless 78 broadband network services such as Mobile IPTV. Mobile IPTV service 79 is a kind of audio/video (A/V) service which is combined with 80 interactive data for the related or supplementary information of A/V 81 program using bi-directional wireless broadband links. Users can 82 enjoy the downlink A/V stream and request more detailed or value- 83 added information via uplink simultaneously. Mobile IPTV service, 84 which can also be described as place-shifting IPTV service, is to 85 ensure continuous and original IPTV experiences for the users who 86 move to the other place from where he or she was originally 87 subscribed for [ITUIPTV]. 89 Apart from Mobile IPTV, packet based point-to-multipoint group voice 90 application like push to talk, content broadcasting and streaming 91 over audio and video conferencing, online multiplayer gaming, mobile 92 chat and instant messaging, file transfer to recipients of a group 93 whose members could be on the move are applications of IP multicast 94 technology for mobile users. 96 Localized mobility management domain is an access network that 97 supports IP level mobility without requiring client software on the 98 mobile nodes [RFC4831]. Proxy Mobile IPv6 (PMIPv6) provides mobility 99 support to the mobile nodes (MN) in a localized mobility management 100 domain [RFC5213]. Mobility access gateway (MAG) proxies MN in 101 mobility signaling (proxy binding update/acknowledgement) with the 102 localized mobility anchor (LMA). PMIPv6 is currently an unicast 103 mobility protocol. 105 In this document we will describe how multicast routing can be 106 supported in Proxy Mobile IPv6 [RFC5213]. PMIPv6 has potential to be 107 widely used and because of this multicast mobility support in PMIPv6 108 is essential. PMIPv6 with multicast routing support can then be used 109 in Mobile IPTV and other IP multicast applications to provide 110 seamless mobility. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [RFC2119]. 118 This document uses the terminology defined in [RFC3775] and in NetLMM 119 Goals document [RFC4831]. 121 3. Overview of PMIPv6 Multicast 123 This document describes Local Mobility Anchor-based basic multicast 124 forwarding in Proxy Mobile IPv6. Mobility Access Gateway is not 125 enabled to support multicast routing. The base protocol only 126 supports receiver mobility. 128 When mobile node wishes to join a multicast group it sends a Mobile 129 Listener Discovery Version 2 (MLDv2) protocol Report message to its 130 Mobility Access Gateway. The mobile node MUST use the link-local 131 address as the source address to send the MLD Report and any 132 subsequent MLD messages. Mobility Access Gateway encapsulates the 133 message and forwards it to Local Mobility Anchor on the bi- 134 directional tunnel between Mobility Access Gateway and Local Mobility 135 Anchor. 137 Local Mobility Anchor decapsulates the MLD report message from the 138 Mobility Access Gateway. Local Mobility Anchor joins the group on 139 behalf of the mobile node with the upstream multicast router (MR). 140 Local Mobility Anchor sets up multicast state as multicast router for 141 the listener which is the mobile node. 143 Multicast data packets received by Local Mobility Anchor MUST be 144 encapsulated and sent to Mobility Access Gateway on the bi- 145 directional tunnel. Mobility Access Gateway decapsulates the packet 146 and sends it to the mobile node. 148 Since Mobility Access Gateway does not keep multicast state, if the 149 decapsulated packet is a multicast packet Mobility Access Gateway can 150 not send it to the mobile node. This requires Local Mobility Anchor 151 to duplicate the multicast packet for each member in the multicast 152 group and encapsulate the multicast packet with a unicast header. 153 This encapsulation is done first. Next, based on the destination 154 address (MN-HoA) the packet is encapsulated again to be sent to the 155 Mobility Access Gateway for this mobile node [RFC3344]. 157 In case of handover the new Mobility Access Gateway sends a Proxy 158 Binding Update to Local Mobility Anchor. This message will update 159 the binding cache entry so that it points for this MN-HoA to the new 160 Mobility Access Gateway's Proxy-CoA. 162 3.1. IPv4 Support 164 For mobile nodes that have IPv4 stack enabled Proxy Mobile IPv6 can 165 provide IPv4 home address mobility support 166 [I-D.ietf-netlmm-pmip6-ipv4-support]. Mobility access gateway gets 167 an IPv4 home address for the mobile node as described in 168 [I-D.ietf-netlmm-pmip6-ipv4-support]. When such a mobile node wishes 169 to join a multicast group it sends an Internet Group Management 170 Protocol version 3 (IGMPv3) Membership Report message to its Mobility 171 Access Gateway. IGMPv3 requires a valid IP source address to be used 172 as the source address of the membership report message. Mobile node 173 MUST use its home address as the source address of the membership 174 report message. 176 Mobility access gateway tunnels the report message to the local 177 mobility anchor. Local mobility anchor decapsulates the IGMP report 178 message from the Mobility Access Gateway. Local Mobility Anchor 179 joins the group on behalf of the mobile node with the upstream 180 multicast router (MR). Local Mobility Anchor sets up multicast state 181 as multicast router for the listener which is the mobile node. 183 When packets are received for the multicast group that the mobile 184 node is subscribed, local mobility anchor encapsulates each packet 185 and sends it to each mobile node on the tunnel between local mobility 186 anchor and mobile access gateway. 188 4. Local Mobility Anchor Operation 190 Local Mobility Anchor is the multicast router for all mobile nodes in 191 Proxy Mobile IPv6 domain and performs the multicast router part of 192 MLDv2 [RFC3810]. After receiving MLD Report message from the mobile 193 node, Local Mobility Anchor joins the multicast tree for this 194 multicast group with an upstream router. 196 MLDv2 nodes maintain multicast listening state per multicast address 197 which keeps track of the sources of the multicast group. This allows 198 a simple forwarding downstream of the multicast packet received from 199 one of the sources. As for the group membership, local mobility 200 anchor receives information about the receivers by sending periodic 201 queries to the mobile nodes. Since Proxy Mobile IPv6 supports Per-MN 202 prefix model the query messages and report messages are sent 203 individually to each mobile node. This means that each group can 204 have only one member on the link between local mobility anchor and 205 mobile node. However a given multicast group may have more than one 206 member each located on a different point-to-point link. 208 Local Mobility Anchor MUST maintain multicast membership status state 209 for the the mobile nodes. This state consists of a set of records of 210 the form: 212 (IPv6 multicast address, receiver list) 214 where the receiver list is a potentially long list of link-local 215 source addresses of all the mobile nodes that are currently members 216 of this multicast group. 218 When a multicast packet is received from the upstream multicast 219 router, local mobility anchor searches the multicast membership 220 status state for the source multicast address. When a match is 221 found, local mobility anchor tunnels the packet to each member in the 222 receiver list on the bi-directional tunnel between local mobility 223 anchor and mobile access gateway. For each receiver, local mobility 224 anchor searches the binding cache entry to find a match to the link 225 local source address. When a match is found, the corresponding 226 mobile access gateway address, i.e Proxy-CoA and mobile node home 227 address, i.e. MN-HoA are used in formating the tunneled packet. The 228 format of the tunneled packet is shown below (where CP stands for the 229 content provider for the multicast channel): 231 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 232 IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */ 233 IPv6 header (src=CP, dst= Multicast group) /* Multicast Packet */ 234 Upper layer protocols /* Packet Content*/ 236 Figure 1: Tunneled Multicast Packet from LMA to MAG 238 4.1. IPv4 Support 240 If IPv4 transport is used between mobile access gateway and local 241 mobility anchor, the format of the tunneled packet is shown below: 243 IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */ 244 IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */ 245 IPv4 header (src=CP, dst= Multicast group) /* Multicast Packet */ 246 Upper layer protocols /* Packet Content*/ 248 Figure 2: Tunneled Multicast IPv4 Packet from LMA to MAG 250 5. Mobile Access Gateway Operation 252 Proxy Mobile IPv6 base specification [RFC5213] requires Mobile Access 253 Gateway to not to forward the packets that are sent with the link- 254 local source address to support Duplicate Address Detection protocol. 255 However in this document we modify this in order to allow MLDv2 256 packets to be exchanged between Local Mobility Anchor and mobile 257 node. Mobile Access Gateway MUST tunnel a packet from a mobile node 258 connected to its access link with an IP destination address of FF02: 260 0:0:0:0:0:0:16 (all MLDv2-capable routers) through the bi- 261 directional tunnel established between itself and the mobile node's 262 local mobility anchor. MLDv2 also requires the source address of 263 such packets to be link-local address of the mobile node. 265 6. Mobile Node Operation 267 In order to receive multicast packets from the multicast groups of 268 interest, Mobile node must be MLDv2-capable. MLDv2 is run between 269 the mobile node and Local Mobility Anchor with the mobile node being 270 the multicast address listener and local mobility anchor the 271 multicast router. 273 When an application wants to join a multicast group such as receive 274 IPTV the application makes a join socket call. This triggers MLDv2 275 layer to send Multicast Listener Report to Mobile Access Gateway 276 which tunnels it to local mobility anchor. The source address of the 277 MLDv2 Report message is mobile node's link-local address and the 278 destination address is FF02:0:0:0:0:0:0:16, i.e. MLDv2 capable 279 routers group address. Local mobility anchor as multicast router 280 joins the multicast group and gets attached to the multicast tree 281 associated with this multicast group. Multicast packets sent to the 282 multicast group address are received by the local mobility anchor 283 which tunnels them to mobile access gateway. 285 By the time mobile node sends the first MLDv2 report message mobile 286 access gateway must have registered this mobile node to the local 287 mobility anchor. Proxy Mobile IPv6 base protocol assures that 288 mobile-node link local address is unique in the point-to-point link 289 between the mobile node and mobile access gateway and also the mobile 290 node is registered with its local mobility anchor (LMA) (using Proxy 291 Binding Update/ Acknowledgement exchange between mobile access 292 gateway and local mobility anchor) before the mobile node completes 293 the duplicate address detection (DAD) operation (Section 6.8 in 294 [RFC5213]). Mobile node MUST send MLDv2 report message after DAD 295 operation is completed. 297 Because mobile access gateway is not MLDv2 capable, the mobile node 298 receives all multicast data packets from local mobility anchor as 299 unicast packets with the multicast datagram encapsulated. The mobile 300 node MUST be capable of decapsulating packets sent to its home 301 address in order to receive multicast datagrams. 303 7. Security Considerations 305 This draft introduces no additional messages. Compared to [RFC3810] 306 and [RFC5213] there is no additional threats to be introduced. 308 8. IANA Considerations 310 None. 312 9. Acknowledgements 314 TBD. 316 10. References 318 10.1. Normative References 320 [I-D.ietf-netlmm-pmip6-ipv4-support] 321 Wakikawa, R. and S. Sarikaya, "IPv4 Support for Proxy 322 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 323 (work in progress), April 2009. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 329 August 2002. 331 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 332 Thyagarajan, "Internet Group Management Protocol, Version 333 3", RFC 3376, October 2002. 335 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 336 in IPv6", RFC 3775, June 2004. 338 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 339 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 341 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 342 Management (NETLMM)", RFC 4831, April 2007. 344 [RFC5213] Sarikaya, S., Leung, K., Devarapalli, V., Chowdhury, K., 345 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 347 10.2. Informative References 349 [ITUIPTV] "IPTV Service Scenarios", May 2007. 351 Authors' Addresses 353 Behcet Sarikaya 354 Huawei USA 355 1700 Alma Dr. Suite 500 356 Plano, TX 75075 358 Email: sarikaya@ieee.org 360 Thomas C. Schmidt 361 HAW Hamburg, Dept. Informatik 362 Berliner Tor 7 363 D-20099 Hamburg, Germany 365 Email: Schmidt@informatik.haw-hamburg.de 367 Suresh Krishnan 368 Ericsson 369 8400 Decarie Blvd. 370 Town of Mount Royal, QC 371 Canada 373 Email: suresh.krishnan@ericsson.com