idnits 2.17.1 draft-oneill-mip-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 66 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 752 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 July 2002) is 7959 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) == Missing Reference: 'RevTun' is mentioned on line 143, but not defined == Unused Reference: 'RFC2026' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'IGMPv3' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'MLDv2' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'PIM-SM' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'SSM' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'PIM-DM' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'DVMRP' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'MOSPF' is defined on line 1093, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3220 (ref. 'MIPv4') (Obsoleted by RFC 3344) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-v3-05 == Outdated reference: A later version (-08) exists of draft-vida-mld-v2-03 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-05 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-00 == Outdated reference: A later version (-05) exists of draft-ietf-pim-dm-new-v2-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-pim-dm-new-v2 (ref. 'PIM-DM') == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-10 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 Internet Draft Flarion Technologies 3 Document: draft-oneill-mip-multicast-00.txt 5 July 2002 4 Expires: Dec 2002 6 Mobility Management and IP Multicast 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 Mobile IP provides a mobile node, that visits a foreign subnet, the ability 35 to continue to use an address from its home subnet (the home address) as a 36 source address. This is achieved through the allocation of a Care of Address 37 on the foreign subnet that is used as the end-point of a redirection tunnel 38 from a home agent on the home subnet. Mobile IP in RFC 3220 states that when 39 the mobile node originates multicast traffic intended for the foreign 40 multicast system, it can only do so by first obtaining an IP address from the 41 foreign subnet (a Collocated Care of Address) and then using this address as 42 the multicast source address. This is to ensure that the source address will 43 pass multicast routing reverse path forwarding checks. 45 This foreign multicast model is however extremely restrictive, and still very 46 problematic to multicast routing and applications when the mobile node 47 regularly changes foreign subnets, as is common in wireless systems. This is 48 because the source address continues to evolve which must be tracked by 49 source specific multicast application and routing signalling. Using the home 50 multicast system, again described above, is also non-optimal because the 51 mobile node receiver is then serviced by packets that must be tunnelled from 52 its home agent which, removes any multicast routing benefits (ie network 53 based tree building). This draft therefore describes modifications to the 54 foreign multicast interface between mobile IP and multicast routing that 55 enable the mobile node to use its persistent home address as a multicast 56 source address. 58 INDEX 60 Abstract 62 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 66 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 68 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Limitations of MIP Multicast. . . . . . . . . . . . . . . . . . . . 4 71 5.1. Commercial Implications. . . . . . . . . . . . . . . . . . . . 4 72 5.2. Foreign Multicast System in RFC3220. . . . . . . . . . . . . . 4 73 5.3. Home Multicast System in RFC3220 . . . . . . . . . . . . . . . 5 74 5.4. Non-Member Senders . . . . . . . . . . . . . . . . . . . . . . 6 75 5.5. Reverse Tunnelling Enhancements from RFC 3024. . . . . . . . . 7 76 5.6. The Problem with CCoAs . . . . . . . . . . . . . . . . . . . . 8 78 6. HoA based MIP Multicast . . . . . . . . . . . . . . . . . . . . . . 9 79 6.1. Hybrid Multicast System. . . . . . . . . . . . . . . . . . . . 10 80 6.2. Shared Tree Solution . . . . . . . . . . . . . . . . . . . . . 12 81 6.3. MIPv4 FA Multicast Encapsulation, MIPv6 RPF Redirect Option. . 13 82 6.4. Multicast Signalling Extensions - RPF Redirection. . . . . . . 14 84 7. AAA Support for MIP Multicast . . . . . . . . . . . . . . . . . . . 19 86 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 19 90 10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 20 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 Mobile IP provides a mobile node, which visits a foreign subnet, with the 97 ability to continue to use an address from its home subnet (the home address) 98 as a source address. This is achieved through the allocation of a Care of 99 Address on the foreign subnet that is used as the end-point of a tunnel from 100 a Home Agent on the home subnet. Mobile IP in RFC 3220 [MIPv4] and in [MIPv6] 101 states that when the mobile node originates multicast traffic intended for 102 the foreign multicast system, it can only do so by first obtaining an IP 103 address from the foreign subnet (a Collocated Care of Address) and then using 104 this address as the multicast source address. This is to ensure that the 105 source address will pass multicast routing reverse path forwarding checks as 106 mentioned, for example, in the MIPv4 RFC text which is repeated overleaf. 108 A mobile node that wishes to send datagrams to a multicast group also 109 has two options: (1) send directly on the visited network; or (2) 110 send via a tunnel to its home agent. Because multicast routing in 111 general depends upon the IP source address, a mobile node which sends 112 multicast datagrams directly on the visited network MUST use a co- 113 located care-of address as the IP source address. Similarly, a 114 mobile node which tunnels a multicast datagram to its home agent MUST 115 use its home address as the IP source address of both the (inner) 116 multicast datagram and the (outer) encapsulating datagram. This 117 second option assumes that the home agent is a multicast router. 119 This foreign multicast model is however extremely restrictive, and still very 120 problematic to multicast routing and applications when the mobile node 121 regularly changes foreign subnets, as is common in wireless systems. This is 122 because the source address continues to evolve which must be tracked by 123 source specific multicast application and routing signalling. Using the home 124 multicast system, again described above, is also non-optimal because the 125 mobile node receiver is then serviced by packets that must be tunnelled from 126 its home agent which, removes any multicast routing benefits (ie network 127 based tree building). This draft therefore describes modifications to the 128 foreign multicast interface between mobile IP and multicast routing that 129 enable the mobile node to use its persistent home address as a multicast 130 source address. It concentrates primarily on MIPv4, but mentions related 131 MIPv6 issues and opportunities, which are brought together in section 8 along 132 with a detailed description of the present MIPv6 foreign multicast scheme. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 137 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 138 be interpreted as described in RFC-2119 [RFC2119]. 140 3. Terminology used in this document 142 Much of the terminology used in this document borrows from Mobile IPv4 143 [MIPv4], MIP Reverse Tunnelling [RevTun] and IP multicast RFCs and drafts. 144 This draft introduces the following additional terminology. 146 Home multicast Multicast via the home IGMP/MLD signalling. 147 Foreign multicast Multicast via the IGMP/MLD signalling on the visited 148 Subnet. 149 Hybrid Multicast Foreign multicast reception, home multicast origination. 150 Designated Router The DR is the multicast router/forwarder for a subnet. 151 OldDR / NewDR Sender DRs as part of hand-off between subnets. 152 RPF Redirection Redirecting the RPF check to point to the FA/DR and not 153 the multicast source address. 154 Cross-over Router The furthest router from the senders oldDR on a source 155 tree that has the sender newDR on a different RPF 156 interface. 157 Hand-Off Router The router that issues an explicit Join towards the newDR 158 and is the closest router from the old DR that has the 159 newDR on the same RPF interface. 160 RPF Header An IPv6 routing header indicating the preferred multicast 161 RPF point for (S,G) packets. 163 4. Motivation 165 The motivation for this work is to enable a mobile node to have the option of 166 using the more efficient foreign multicast delivery system. This requires the 167 typical mobile node in wireless systems to use its home address as a foreign 168 multicast source address, rather than a Collocated Care of Address, and yet 169 still pass multicast routing RPF checks. This is to enable source specific 170 multicast application and routing state to survive mobile node hand-offs 171 between access routers that would typically not survive when using a 172 Collocated Care of Address. Changes in these multicast source Collocated 173 addresses would otherwise require multicast receiver application and routing 174 signalling to be kept informed of each new source address change and to 175 modify application and routing state in sympathy with such changes. These 176 changes would unavoidably lead to lost packets and/or excessive signalling. 177 An associated motivation for this work is to avoid a mobile node, that wishes 178 to source multicast traffic, from having to acquire a Collocated Care of 179 Address from each foreign subnet, which is particularly expensive in MIPv4. 181 5. Limitations of MIP Multicast 183 5.1. Commercial Considerations 185 It is clear that MIP typically has a closely coupled policy layer that 186 enables the home and foreign operators to control MN capabilities and packet 187 routing when on the foreign subnet. In many cases the home operator wishes 188 all packets to be routed to and from the home network for security, cost or 189 customer control reasons. Similarly, the foreign operator also wishes to 190 protect its own services and users from being affected by the presence of the 191 roaming MN. In contrast, the foreign operator could alternatively require 192 that the MN makes use of its own services whilst in the foreign domain and 193 supporting this is probably a desire by the home operator to divert commodity 194 traffic flows away from its home network and instead be delivered more 195 efficiently by the foreign operator. These network and service control 196 tensions are addressed by the policy layer. They need to be resolved by the 197 AAA exchanges that occur during the request to connect to the foreign subnet. 198 This draft does not overly consider which of these commercial models is more 199 important for MIP multicast and simply aims to make all practical options 200 available to the parties involved. A discussion of the type of AAA support 201 required for the specific suggestions in this draft are however outlined in 202 section 7. 204 5.2. Foreign Multicast System in RFC3220 206 The foreign subnet has an IGMP Querier, a multicast designated router (DR) 207 and at least one Foreign Agent (FA). The IGMP Querier issues Queries to the 208 all-multicast-systems IP broadcast address, and the multicast DR and other 209 receive GMRs from the MNs addressed to the multicast group address of 210 interest. These IGMP messages are transmitted unencapsulated over the foreign 211 subnet. The foreign multicast system uses native multicast routing from 212 multicast senders in the Internet, down the multicast distribution tree 213 towards those DRs that have joined to the group on behalf of their attached 214 MNs. The DRs then transmit the multicast packets unencapsulated over the 215 access link to the MN members that are members of the multicast group 216 identified by the group destination address. 218 It can be seen that when multiple DRs in an access network are members of the 219 same multicast group, and each DR has multiple MNs on that group, that the 220 use of native multicast forwarding results in a single copy of each packet 221 from the core of the network out across the access network and over the 222 access link to the MN members. This represents the potential for significant 223 bandwidth savings when compared to the home multicast system. 225 CN HA FA MN 226 MN with FA CoA 227 MN Reception CN------------------------------G>----------------->G 229 MN Origination G<------ NOT PERMITTED 231 MN with CCoA 232 MN Reception CN------------------------------G>----------------->G 234 MN Origination G<----------------CCoA 236 Figure 1. Forward and reverse foreign network multicast in RFC 3220 238 MN origination is not permitted when the MN has a FA CoA and hence such MNs 239 can only receive multicast content. This prevents MIPv4 MNs, which typically 240 cannot afford to be given a unique CCoA at each FA, nor afford the delay of 241 continually updating this CCoA on hand-off, from taking part in bi- 242 directional multicast flows that are typical with RTP sessions, and common in 243 other multicast data applications. 245 MN origination is permitted when the MN has a CCoA, with that CCoA used as 246 the source address. Once again multicast packets are sent unencapsulated over 247 the access link, this time from the MN to the multicast DR on the subnet. 248 This router forwards the packets into the multicast tree for the group 249 contained in the destination address field of the packet. It can be seen here 250 that whilst the multicast forwarding is bandwidth efficient, through the use 251 of native multicast, it is limited to MNs with CCoAs. 253 5.3. Home Multicast System in RFC3220 255 The home multicast system in RFC 3220 uses a bi-directional tunnel between 256 the HA and the MN CoA. The MN can have either a FA CoA or a CCoA from the FA 257 and the resulting forwarding and encapsulations are shown graphically in 258 figure 1. The MN should set the 'B' bit in the MIP RREQ to request the HA to 259 forward to the MN, amongst other broadcast traffic, IGMP Queries and possibly 260 IGMP Group Membership Reports to the MN. The MN can then issue solicited or 261 unsolicited GMRs for the groups and group senders of interest to that MN, and 262 the HA can then keep MN specific IGMP state to enable it to make appropriate 263 forwarding decisions for multicast traffic arriving to the home subnet. Note 264 that the HA must also export the MN GMRs to the home subnet, so that it can 265 be seen by the IGMP Querier, received by the multicast DR on the home subnet 266 for injection into the multicast tree building protocol, and also be seen by 267 other MNs on the subnet to suppress their own GMRs. The IGMP Queries and GMRs 268 must be sent encapsulated over the foreign subnet to avoid them being 269 confused with foreign subnet IGMP signalling, with the encapsulation being 270 the same as that used for multicast content. 272 CN HA FA MN 273 MN with FA CoA 274 MN Reception CN----------G>------------------------------------->G 275 HA===================================>HoA 276 HA==============>CoA 278 MN Origination G<---------G<-------------------------------------HoA 279 HA<===================================HoA 281 MN with CCoA 282 MN Reception CN----------G>------------------------------------->G 283 HA==================================>CCoA 285 MN Origination G<---------G<-------------------------------------HoA 286 HA<==================================CCoA 288 Figure 2. Forward and reverse home network multicast in RFC 3220 290 The major limitation here is that MN reception of multicast content is via a 291 unicast tunnel from its HA. This tunnel is required to hide the multicast 292 content from the foreign multicast system and to identify the target MN (the 293 HoA/CCoA is otherwise missing due to the multicast packet having a group 294 destination address). There is then potential for significant replication 295 load being placed on the HA (and associated loss of bandwidth efficiency) 296 when significant numbers of registered MNs at that HA are members of the same 297 multicast group. In addition, when multiple MNs on the same foreign subnet 298 are members of the same multicast group then multiple copies of the same 299 content must be delivered to that foreign subnet and delivered over the air- 300 interface in wireless systems. Only in the case that neither the HA nor the 301 FA has multiple members of the same group (low membership coherence) is their 302 no gain to be had from using multicast (network tree building and 303 replication) between the HA and the FA. In all other cases, the absence of a 304 multicast delivery tree potentially results in significant inefficiencies. 305 When comparing the delivery costs (encapsulation processing and overhead) of 306 multicast and unicast content from the HA in this model, it is evident that 307 it is potentially better to use a multicast to unicast gateway on the home 308 subnet and delivery any content using unicast, instead of incurring the 309 additional cost and complexity of the unicast encapsulation and associated 310 multicast signalling. 312 MN origination of content is via a unicast tunnel from the MN to the HA, 313 using the HoA as a multicast source address. The unicast tunnel is less of an 314 issue here because source specific branches from senders are common in 315 multicast tree building and therefore the unicast tunnel does not result in 316 significant multicast inefficiencies. The tunnel is required simply to hide 317 the multicast content from the foreign multicast system. 319 5.4. Non-Member Multicast Senders 321 It is permitted in the multicast architecture for a host to send traffic 322 towards a multicast group of which it is not a member. When a host sends an 323 IGMP GMR for group G, it is specifically asking to be a receiver of the group 324 but may also wish to send to that group. A non-member sender is not a 325 receiver on the group and is likely only a transient sender. This is 326 typically used to support early media flows in parallel with IGMP processing, 327 for transient senders that do not wish to disturb the multicast routing 328 fabric, and for supporting sensor devices that are clearly not interested in 329 the traffic from other senders. A non-member sender simply originates packets 330 to the group G and the multicast designated router forwards these into the 331 multicast receiver tree, without initiating any receiver tree building 332 activity in the multicast routing protocol. Non-member sender traffic is 333 still however exposed to RPF checks. Non-member senders can be supported in 334 either home or foreign multicast systems and therefore IGMP (or MLD) 335 signalling may not occur before MN originated traffic flows. 337 5.5. Reverse Tunnelling Enhancements from RFC 3024 339 Reverse Tunnelling was developed to provide topologically correct tunnels 340 back to the HA. When the MN has a FA CoA and wishes to tunnel traffic, 341 including MN originated multicast, back to the HA then in RFC3220 as shown in 342 figure 2, this is achieved by a MN to HA tunnel using the HoA as a source 343 address. Unfortunately, the HoA is not a topologically correct source address 344 and hence risks being dropped in the Internet in routers deploying source 345 address checking. RFC 3024 instead adds the ability for the tunnel to instead 346 be initiated from the FA towards the HA and hence being topologically 347 correct. Reverse tunnelling is requested by setting the 'T' bit in the MIP 348 RREQ from the MN to the FA and onto the HA. There are then two modes for 349 forwarding between and the MN to FA. In the default Direct Delivery Style 350 (DDS), the MN sends the packets unencapsulated to the FA which then tunnels 351 all received packets to the HA in the reverse tunnel. Essentially, all MN 352 originated packets are viewed as being home network packets and foreign 353 multicast is not permitted. Unfortunately, this method does not work however 354 for multicast packets on a broadcast foreign subnet (not point to point) 355 because these home broadcast packets will be confused with foreign broadcast 356 packets by other MNs on the subnet and can be incorrectly received. RFC 3024 357 therefore mandates the second form of reverse tunnel forwarding known as 358 Encapsulating Delivery Style (EDS). In EDS, the MN can selectively reverse 359 tunnel packets to the HA through the use of an encapsulation between the MN 360 and the FA. EDS mode is selected by the MN in the MIP RREQ by including an 361 EDS extension as well as setting the 'T' bit. 363 The EDS extension is not forwarded to the HA and is viewed as purely a local 364 matter between the MN and the FA. Packets which are encapsulated in a tunnel 365 from the MN HoA to the FA are switched into a MIP tunnel from the FA CoA to 366 the HA address. The HA then decapsulates them, and then forwards them onto 367 the home subnet. The encapsulation on the foreign subnet also means that home 368 multicast packets are hidden from the foreign broadcast subnet and are 369 therefore not confusing to other MNs on the foreign subnet. Packets that are 370 not to be reverse tunnelled are sent natively by the MN to the FA, which then 371 forwards them normally, which in the case of foreign multicast is down the 372 multicast tree. Essentially, EDS mode enables a MN to potentially partake in 373 both home and foreign network multicast at the same time with the 374 encapsulations over the foreign subnet being used to separate out IGMP and 375 multicast content from/to the home and foreign multicast systems. Clearly, a 376 MN would not wish to join the same multicast groups via both systems and so 377 the MN, FA and HA need to have some configuration or AAA policy to decide 378 which multicast systems the MN can participate in, and its limitations on 379 that system (receiver, sender, receiver and sender, multicast group scope). 380 Additionally, as has been described in 5.1, it is only a CCoA that enables a 381 MN to originate traffic towards the foreign multicast system. 383 5.6 The Problem with CCoAs 385 Referring back to section 4.4 in RFC3220, the claim is made that MN 386 origination into the foreign multicast system must use a CCoA. This is 387 because the multicast source address must be topologically correct to pass 388 the multicast reverse path forwarding check. This process, which is common to 389 almost all multicast forwarding engines, is used to build source trees and to 390 prevent routing loops. This is achieved by having the multicast forwarding 391 engine in each multicast router, look-up the unicast source address within 392 each multicast packet, as a unicast destination address in the unicast 393 forwarding table. If the multicast packet arrives on an incoming interface, 394 which is also the outgoing interface that would be used to forward unicast 395 packets to that unicast destination address, then the RPF check has succeeded 396 and the multicast packet may for replicated and forwarded. Putting aside 397 transient routing effects, this RPF check will generally succeed for MN 398 originated packets when the topologically correct CCoA is used as a source 399 address. However, the RPF check will not generally succeed if the MN HoA is 400 used as the source address because the HoA is topologically incorrect 401 (belonging to the home subnet) and hence the multicast packets will not be 402 received over the interface used to forward unicast packets towards the HoA. 403 RFC 3220 is therefore correct in its statements and decisions in this regard. 405 However, RFC 3220 fails to mention that there is an additional problem with 406 CCoAs. This is that the CCoA is a transient address and must change on each 407 hand-off if the MN keeps moving. Each such address changes has a damaging 408 affect on multicast applications and routing. For example, IGMPv3 enables a 409 host to undertake source specific membership of a group, specifically 410 enabling a MN to ignore content or receive content only from specific senders 411 to that group. Protocol Independent Multicast-Sparse Mode (PIM-SM) also has 412 source specific JOIN and PRUNE mechanisms that act in sympathy with sender 413 specific group membership signalling to ensure only requested content is 414 delivered down the multicast tree. In addition, PIM-SM supports both shared 415 and source specific trees with the source specific PIM JOINs creating (S, G) 416 state to over-rule the (*,G) shared tree state. 418 Source Specific Multicast (SSM) is also under development in the IETF in 419 which the multicast destination group address as well as the senders unicast 420 address identifies the multicast 'channel', and multicast routers keep (S+G) 421 state. Finally, multicast transport and session layers applications typically 422 use the multicast source address to 'demultiplex' content into sender 423 specific feeds. This is because at a simplistic level, many to many network 424 multicast is simply a superposition of multiple one to many transport flows. 426 In all these cases, a change in the multicast source address will create 427 significant problems, requiring the address change to be communicated down 428 the tree in advance of the CCoA update, so that new source specific routing 429 state can be installed for (S2,G) or (S2+G) instead of (S1,G) or (S1+G). It 430 must also be known to the host so that receiver applications can update 431 transport, session and application state, to avoid application confusion and 432 data corruption or loss. The scale of the update (all router and host sender 433 specific state for that sender) coupled with the likely speed of hand-offs 434 (and hence CCoA changes), makes the choice of the CCoA as a source address 435 extremely problematic. Essentially, it completely prevents the MN from using 436 the foreign multicast system and it must instead use the less efficient home 437 multicast system. In solving the RPF problem, and preserving the packets of a 438 single MN originator, it is clear that RFC 3220 creates an even bigger 439 problem, with wider implications on multicast routing stability. This is 440 because the mobility is being directly exposed to the global multicast 441 routing system through the address change, but is not being exposed to the 442 unicast system (MIP instead deals with the latter). Note that the use of the 443 HoA in the home multicast system coupled with the unicast tunnelling back to 444 home subnet is one obvious way for multicast and MIP to collaborate in 445 getting the job done. This however misses the efficiency of the foreign 446 multicast delivery tree. The only way to correct this problem is to use the 447 MN HoA as a multicast source address for the foreign multicast system 448 (aligning somewhat home and foreign multicast processing on the hosts) and 449 then find scalable means for MIP and the foreign multicast routing to work 450 together to preserve the senders packets through the RPF check process. A 451 range of techniques are next described in section 6, with the different 452 techniques potentially forming an evolution and interoperability capability, 453 as MIP and multicast technologies and standards evolve. They are described in 454 overview to stimulate discussion between mobility and multicast researchers, 455 so that standards activity can be commenced to address this opportunity. 457 6. HoA based MIP Multicast 459 The aim, in summary, is to enable a MN to originate IP multicast traffic 460 using the HoA as a source address and have those packets correctly delivered 461 by the foreign multicast system by specifically bypassing or satisfying the 462 multicast RPF checks. This needs to work when the MN has requested EDS 463 reverse tunnelling ('T' bit set plus EDS extension) or when no reverse 464 tunnelling has been requested ('T' bit unset'). With DDS reverse tunnelling, 465 it is clear that foreign multicast is by definition prevented and is not 466 discussed further. An additional requirement is that the MN should not need 467 to be aware of how the local FA is addressing this problem so that the MN can 468 simply be made aware that foreign multicast origination is possible and then 469 undertake home and foreign multicast as befits its configuration, incoming 470 signalling, and the policy exchanged between the HA and FA. This idealised 471 foreign multicast system is shown in figure 3 where the MN believes the FA 472 (specifically the multicast designated router on the foreign subnet if 473 different from the FA) is able to inject the multicast packets into the 474 foreign multicast system and the multicast system will safely deliver them 475 through the Internet to the multitude of CN multicast receivers on that 476 group. This distribution should at all times be limited by the appropriate 477 scope of the multicast group. Note that in the idealised system, the MN 478 processing is the same for both a FA CoA and a CCoA. 480 CN HA FA MN 481 MN with FA CoA 482 MN Reception CN-------------------------------G>---------------->G 484 MN Origination G<------------------------------G<----------------HoA 486 MN with CCoA 487 MN Reception CN-------------------------------G>---------------->G 489 MN Origination G<------------------------------G<----------------HoA 491 Figure 3. Idealised Foreign Multicast System 493 Before discussing the alternative solutions to this problem, it is important 494 to point out that these solutions are covered at a relatively high-level and 495 significant work in standards and subsequent engineering may be required to 496 turn these suggestions into commercial reality. For now, they should simply 497 be considered as examples to justify the potentially reality of MIP foreign 498 multicast, using the HoA as a source address. 500 6.1 Hybrid Multicast System 502 The first (early) solution to this problem is to combine the best of the home 503 and foreign multicast systems in satisfying the problem, thereby creating a 504 hybrid multicast system. For simplicity, we will assume that the FA is also 505 the multicast designated router for the foreign subnet. We can also assume 506 that unencapsulated IGMP and multicast packets with a HoA source address are 507 intended for the foreign multicast system, whether or not the 'B' bit is set 508 or EDS RevTun has been requested and the 'T' bit is set. Essentially, we care 509 greatly about being able to receive multicast via the foreign multicast 510 system to accrue the bandwidth efficiencies, but care less about the path of 511 the sender specific MN originated traffic. 513 The MN may or may not be a member of the multicast group G, whose scope must 514 encompass both the home and foreign subnets (global scope only). If the MN is 515 a member of group G then it will have sent an IGMP GMR for group G to the 516 FA/DR and the FA/DR will have tracked IGMP state and initiated multicast tree 517 building to add the FA/DR onto the receiver trees for the groups of interest 518 to its MNs. This MN, and other MNs on that foreign subnet, will then receive 519 multicast from the FA/DR in an unencapsulated form, and via a bandwidth 520 efficient foreign multicast tree. We will now discuss how this is 521 complemented with MN originated traffic. 523 6.1.1. MNs with FA CoA 525 The MN originates traffic to the group G by sending unencapsulated packets 526 onto the foreign subnet with its HoA as a source address and a destination 527 address of G. On a broadcast subnet, other members of group G on that subnet 528 will also receive the packet. The FA also receives these packets but instead 529 of injecting them into the foreign multicast system, it instead reverse 530 tunnels them to the HA that matches the senders HoA in the visitors list, 531 with the non-local HoA address acting as the trigger for this redirection. 532 The HA knows the FA CoA from the registration and should therefore be happy 533 to receive encapsulated packets from the registered FA CoA to the HA. 534 Specifically, it needs to be happy to receive multicast packets via the FA 535 CoA when the 'T' bit is not set. It will of course already be happy if the 536 'T' bit is set from RFC3024. 538 The HA has no IGMP state for such packets and treats them as non-member 539 sender packets by injecting them into the home multicast system without 540 initiating any receiver tree building. These MN originated packets are 541 topologically correct at the HA and hence will satisfy any subsequent RPF 542 checks except under transient routing situations. Note that the FA must first 543 undertake its own multicast RPF check on the multicast packet using MIP 544 visitor list state instead of the unicast routing state, before forwarding 545 the packet to the HA. In addition, the FA needs to deliver the MN originated 546 packets to other receivers of that group on that FA if the MNs are using 547 point to point links. 549 This is because the multicast routing in the FA must itself not forward the 550 packets again onto the foreign subnet when received down the multicast 551 distribution tree, if they contain source addresses matching HoAs in the 552 visitor list. This is necessary to avoid duplicate delivery on broadcast 553 foreign subnets and is commonly achieved by the DR installing a source 554 specific routing entry to discard packets arriving via a unidirectional 555 shared tree that were originated from that DR. 557 6.1.2. MNs with CCoAs 559 When a MN has a CCoA it may or not have registered via the DR, which has an 560 FA in MIPv4 or an attendant in MIPv6. If the MN has not registered via the DR 561 then the DR cannot support hybrid multicast by forwarding the MN originated 562 multicast packets to the HA because it has no state to do so. More 563 specifically, the DR in this case cannot support MN originated foreign 564 multicast traffic at all because any packets with a HoA source address, 565 including IGMP GMRs, are topologically incorrect and hence will be discarded 566 during ingress filtering in the absence of MIP visitor list state. 568 If the MN has registered via the DR then the DR will know the MN/CCoA/HA 569 binding but in addition needs to know the MN/HoA binding to enable it to pass 570 MN originated packets during ingress filtering and to then be able to tunnel 571 them to the HA from the DR address. There are clearly ways that the MN could 572 provide this information to the DR and the HA via a MIP extension, so that 573 the tunnelling is both possible and acceptable, but this clearly requires the 574 MN to be aware of the need to add such an extension. Thankfully, this 575 extension is also required to enable the FA to natively forward unicast 576 packets from the HoA and hence does not imply that the MN needs to know about 577 the foreign multicast mechanism. The FA/DR receives the unencapsulated MN 578 originated multicast packets and forwards them to the HA using the FA/DR 579 address as a source address. The HA then receives packets from an address 580 that is not equal to the registered CoA, but is equal to the source address 581 of the received registration via that FA/DR and hence should be accepted 582 because the HA and FA share an SA. The use of the HoA as a source address for 583 foreign multicast can therefore only be permitted if the MN has registered 584 via the FA/attendent and has informed that node of the MN HoA for ingress 585 filtering purposes. 587 CN HA FA/DR MN 589 MN with FA CoA 590 MN Reception CN-------------------------------G>---------------->G 592 MN Origination G<------------------------------G<----------------HoA 593 HA<=============FACoA 595 MN with CCoA via FA 596 MN Reception CN-------------------------------G>---------------->G 598 MN Origination G<------------------------------G<----------------HoA 599 HA<=============FACoA 601 Figure 3. Hybrid Multicast System 603 Note that the use of the HoA as a multicast source address implies very 604 different processing on the MN than the existing use of the CCoA. This is 605 clearly a significant concern because MIPv6 relies solely on a MN CCoA, and 606 its use for foreign multicast is potentially broken as discussed in section 607 8. This effectively means that MNs should be prevented from initiating 608 foreign multicast content from the CCoA except in the specific case that the 609 MN is sure that the CCoA will not be changing during the lifetime of the 610 multicast session. This clearly excludes cellular mobility environments. 612 6.2 Shared Tree Solution 614 Some multicast routing protocols, such as PIM-SM, use a shared tree from a 615 root node out to all receivers. The RPF check in this shared receiver tree is 616 not made towards the senders unicast address in the multicast packet, but is 617 instead made towards the root node whose address is distributed to all the 618 multicast routers. Therefore the RPF problem with a non-local HoA address 619 only needs to be solved between the senders designated router and the root 620 node for such shared trees. This can be achieved by using a unicast tunnel 621 from the DR to the root node, and then have the root node forward the senders 622 packets down the receiver tree. 624 CN RP HA FA/DR MN 626 MN with FA CoA 627 MN Reception CN----------G>-------------------G>---------------->G 629 MN Origination G<---------G<-------------------G<----------------HoA 630 RP<======REG=====FACoA 632 MN with CCoA via FA 633 MN Reception CN----------G>-------------------G>---------------->G 635 MN Origination G<---------G<-------------------G<----------------HoA 636 RP<======REG=====FACoA 638 Figure 4. PIM-SM RP MIP Solution 640 In the specific case of PIM-SM, shown in figure 4, the root node is called 641 the Rendevouz Point (RP) and PIM-SM already has mechanisms to enable the DR 642 to tunnel packets directly to the RP using a Register message encapsulation. 643 In the case of member senders, the RP is able to then try to PIM JOIN back to 644 the sender via the senders DR and transmit periodic Register Stop messages to 645 the senders DR. The PIM JOIN is intended to enable the senders DR to send 646 packets natively to the RP via a source specific branch whilst the Register 647 Stop is intended to prevent the parallel encapsulation of multicast packets 648 from the senders DR to the RP in Register messages. In addition to the source 649 specific branch to the RP from the senders DR, any receiver DR is also 650 allowed to try to build a source specific branch towards the senders DR and 651 in so doing bypass the RP and the shared tree. 653 In the case of foreign multicast, both of these source specific branches will 654 be directed towards the HoA in the source address of the multicast packet 655 (and hence the HA subnet), and not towards the senders DR, which is the FA. 656 These source specific PIM JOINs will therefore install state that will not be 657 exercised by packets unless they cross part of the shared tree. The existence 658 of this state is not a problem however as it will not cause problems and will 659 eventually safely time out due to the soft state refresh model in PIM. The 660 Register message could be extended to inform the RP not to bother attempting 661 a PIM JOIN for this (S,G) and hence avoid wasted PIM JOIN and Register Stop 662 signalling. In addition, the DR or RP could also periodically send a new PIM 663 message down the multicast tree to the receiver DRs to also instruct them not 664 to undertake source specific JOINs for this (S,G). 666 Comparing this model to the hybrid approach of 6.1, we can see a number of 667 advantages that accrue when the multicast protocol uses a shared tree and 668 supports unicast encapsulation to the root node. Firstly, in the hybrid 669 approach it is clear that senders packets first go to the HA and then 670 potentially onto the root node within a shared tree protocol. Therefore, 671 sending the packets directly to the root node removes an additional 672 encapsulated hop which is specifically useful when the HA and RP and far 673 apart. In addition, we can see that by leaving all forwarding to the FA/DR we 674 remove any uncertainties about the scope of group G, that otherwise limits 675 the hybrid approach to global scope only. Finally, the most widely deployed 676 multicast protocol in the Internet is PIM-SM and therefore the availability 677 of a shared tree protocol with encapsulation to the root is generally 678 assured. This solution does not however address the problem associated with 679 CCoAs, nor does it deal with other types of multicast routing protocols with 680 MOSPF a particular concern. MOSPF domains can of course still rely on the 681 Hybrid solution of 6.2. 683 6.3 MIPv4 FA Multicast Encapsulation and MIPv6 RPF Redirect Option 685 The first two solutions rely on a unicast encapsulation to a point at which 686 the HoA source address can pass subsequent RPF checks. An alternative 687 solution is to encapsulate throughout the tree using an MIP multicast 688 encapsulation. The FA encapsulates packets with a non-local HoA source 689 address that have passed MIP aware ingress checking, using its own address as 690 the source address and the inner destination group G as the outer destination 691 address. This packet will then have a topologically correct source address 692 and can be correctly forwarded by any multicast protocol that builds on- 693 demand source trees to the receivers of G via (anyFA,G) state. The receivers 694 will then decapsulate such packets to reveal the original multicast packet 695 with the HoA source address, which will then be checked against the source 696 specific host membership state before being passed up to the transport layer. 697 Essentially the host is prepared to receive from any FA and therefore does 698 not need to be kept informed of FA CoA changes. Any source specific tree 699 building triggered by the receiver DR state should be suppressed when the 700 data is received encapsulated like this. This approach again bypasses the HA 701 with all the associated benefits, and this time is applicable to multicast 702 protocols other than PIM-SM which would continue to use the Register 703 encapsualtion. This however comes at the cost of host (and potentially DR) 704 complexity, and the bandwidth inefficiency of the multicast encapsulation. In 705 addition, this clearly does not work directly for explicit join protocols, 706 the and in general limits any (S,G) pruning to the granularity of the FA 707 address, such that multiple senders at the same FA cannot be selected/pruned. 709 The cost of the encapsulation can be reduced in MIPv6 through the use of a 710 new hop by hop option header. This 'RPF Redirect' option would be added by 711 the MN and checked by all multicast routers, and includes the CCoA. The 712 RPF redirect header therefore provides the opposite binding information to 713 routers to that provided to the host by the Home Address Option (HAO) The RPF 714 Redirect option would then be used in multicast routers to redirect RPF 715 checks towards the senders DR instead of the HoA. The RPF Redirect Option or 716 the source address of the FA encapsulation technique can be used by hosts to 717 redirect source specific joins and prunes towards the newDR address, rather 718 than towards the multicast source address of the original multicast packet. 719 These redirections are clearly however affected by FA changes and this issue 720 will be left for discussion in section 6.4.4. 722 6.4 Multicast Signalling Extensions - RPF Redirection 724 Section 6.3 handles the RPF problem in the data plane, but an alternative is 725 to handle it in the multicast signalling plane. This is a longer-term 726 solution in that changes to multicast signalling need to be widely deployed 727 throughout a domain before they can be used, and because of the time to 728 design, standardise and implement changes to deployed protocols. Essentially, 729 the multicast RPF mechanism and the signalling in each routing protocol needs 730 to be extended to support an arbitrary RPF point for the (S,G) in question. 731 This is known henceforth in this document as RPF redirection and is analogous 732 to the aims of the RPF Redirect option previously mentioned. 734 During hand-off, the CoA address is changing at the senders end and therefore 735 each sender DR needs to advertise the new RPF point for that sender. This is 736 achieved by injecting an RPF Redirect message into the multicast routing 737 system using hop by hop multicast protocol signalling that is sent down the 738 present tree or broadcast to multicast neighbours (protocol specific). In the 739 latter case, each router passes the current RPF point to any subsequent 740 joiners so that the sender DR only needs to undertake a periodic refresh of 741 the RPF point in the absence of mobility. In the former case, the RPF point 742 needs to be flooded rapidly by routers that detect that the old and new RPF 743 points are on different interfaces so that the rapid flood is limited to 744 those routers that are affected by the change. Note that the change in the 745 senders DR might take the MN to a newDR that has no other members of group G, 746 and also leave the oldDR with no other members of group G. Therefore some of 747 the above RPF redirection signalling can be coupled with tree building 748 activity (join/prune/membership flood) at the old and newDRs. 750 When the MN originator undertakes a hand-off, the oldDR and the newDR need to 751 collaborate to update the RPF point. There is a cross-over router in the 752 vicinity of both the old and new DRs that is the last router that would 753 discard packets from the MN sent via the new DR, when using the oldDR as an 754 RPF point. The newDR and all intermediate routers to the cross-over router 755 need to be on the sender multicast tree for the group of interest, and must 756 have the RPF point set to the newDR, in advance of multicast data being sent, 757 to avoid that data being discarded. Once on the tree, then the newDR needs to 758 send periodic RPF Redirects from the newDR to maintain the RPF point and the 759 tree. At the same time, the receiver tree must also be updated. The precise 760 mechanisms are of course multicast protocol specific due to the wide range of 761 protocol mechanisms such as explicit join (PIM), member report broadcast 762 (MOSPF), and data flood and prune (DVMRP) as examples. 764 6.4.1 PIM-SM Example (SSM also) 766 PIM uses explicit join/prune messaging to build either a shared tree from the 767 RP, or source specific tree using the source address contained in multicast 768 packets received on the shared tree. A source tree or Register encapsulation 769 can be used between the DR and the RP in the case of a shared tree. During a 770 hand-off on a shared tree with a source specific branch to the RP, the oldDR 771 first needs to send an RPF Redirect down the multicast tree to first seek out 772 the cross-over router. The RPF Redirect message contains the old DR address, 773 the destination group address, the HoA source address, and the newDR address. 774 The cross-over router is identified by the next hop router towards the RP, 775 termed the Hand-Off (HO) router, which detects that the RPF Redirect message 776 does not affect the local RPF check because the oldDR and newDR interfaces 777 are already the same. This router therefore issues an immediate JOIN towards 778 the newDR to create (S,G,