Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-multicast-00.txt 5 July 2002 Expires: Dec 2002 Mobility Management and IP Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Mobile IP provides a mobile node, that visits a foreign subnet, the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a redirection tunnel from a home agent on the home subnet. Mobile IP in RFC 3220 states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks. This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address. A.W. O'Neill Expires Dec 2002 [Page 1] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Limitations of MIP Multicast. . . . . . . . . . . . . . . . . . . . 4 5.1. Commercial Implications. . . . . . . . . . . . . . . . . . . . 4 5.2. Foreign Multicast System in RFC3220. . . . . . . . . . . . . . 4 5.3. Home Multicast System in RFC3220 . . . . . . . . . . . . . . . 5 5.4. Non-Member Senders . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Reverse Tunnelling Enhancements from RFC 3024. . . . . . . . . 7 5.6. The Problem with CCoAs . . . . . . . . . . . . . . . . . . . . 8 6. HoA based MIP Multicast . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Hybrid Multicast System. . . . . . . . . . . . . . . . . . . . 10 6.2. Shared Tree Solution . . . . . . . . . . . . . . . . . . . . . 12 6.3. MIPv4 FA Multicast Encapsulation, MIPv6 RPF Redirect Option. . 13 6.4. Multicast Signalling Extensions - RPF Redirection. . . . . . . 14 7. AAA Support for MIP Multicast . . . . . . . . . . . . . . . . . . . 19 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 19 10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Mobile IP provides a mobile node, which visits a foreign subnet, with the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a tunnel from a Home Agent on the home subnet. Mobile IP in RFC 3220 [MIPv4] and in [MIPv6] states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks as mentioned, for example, in the MIPv4 RFC text which is repeated overleaf. From RFC 3220 section 4.4. Multicast Datagram Routing, page 66 A mobile node that wishes to send datagrams to a multicast group also has two options: (1) send directly on the visited network; or (2) send via a tunnel to its home agent. Because multicast routing in A.W. O'Neill Expires Dec 2002 [Page 2] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 general depends upon the IP source address, a mobile node which sends multicast datagrams directly on the visited network MUST use a co- located care-of address as the IP source address. Similarly, a mobile node which tunnels a multicast datagram to its home agent MUST use its home address as the IP source address of both the (inner) multicast datagram and the (outer) encapsulating datagram. This second option assumes that the home agent is a multicast router. This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address. It concentrates primarily on MIPv4, but mentions related MIPv6 issues and opportunities, which are brought together in section 8 along with a detailed description of the present MIPv6 foreign multicast scheme. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Terminology used in this document Much of the terminology used in this document borrows from Mobile IPv4 [MIPv4], MIP Reverse Tunnelling [RevTun] and IP multicast RFCs and drafts. This draft introduces the following additional terminology. Home multicast Multicast via the home IGMP/MLD signalling. Foreign multicast Multicast via the IGMP/MLD signalling on the visited Subnet. Hybrid Multicast Foreign multicast reception, home multicast origination. Designated Router The DR is the multicast router/forwarder for a subnet. OldDR / NewDR Sender DRs as part of hand-off between subnets. RPF Redirection Redirecting the RPF check to point to the FA/DR and not the multicast source address. Cross-over Router The furthest router from the senders oldDR on a source tree that has the sender newDR on a different RPF interface. Hand-Off Router The router that issues an explicit Join towards the newDR and is the closest router from the old DR that has the newDR on the same RPF interface. RPF Header An IPv6 routing header indicating the preferred multicast RPF point for (S,G) packets. A.W. O'Neill Expires Dec 2002 [Page 3] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 4. Motivation The motivation for this work is to enable a mobile node to have the option of using the more efficient foreign multicast delivery system. This requires the typical mobile node in wireless systems to use its home address as a foreign multicast source address, rather than a Collocated Care of Address, and yet still pass multicast routing RPF checks. This is to enable source specific multicast application and routing state to survive mobile node hand-offs between access routers that would typically not survive when using a Collocated Care of Address. Changes in these multicast source Collocated addresses would otherwise require multicast receiver application and routing signalling to be kept informed of each new source address change and to modify application and routing state in sympathy with such changes. These changes would unavoidably lead to lost packets and/or excessive signalling. An associated motivation for this work is to avoid a mobile node, that wishes to source multicast traffic, from having to acquire a Collocated Care of Address from each foreign subnet, which is particularly expensive in MIPv4. 5. Limitations of MIP Multicast 5.1. Commercial Considerations It is clear that MIP typically has a closely coupled policy layer that enables the home and foreign operators to control MN capabilities and packet routing when on the foreign subnet. In many cases the home operator wishes all packets to be routed to and from the home network for security, cost or customer control reasons. Similarly, the foreign operator also wishes to protect its own services and users from being affected by the presence of the roaming MN. In contrast, the foreign operator could alternatively require that the MN makes use of its own services whilst in the foreign domain and supporting this is probably a desire by the home operator to divert commodity traffic flows away from its home network and instead be delivered more efficiently by the foreign operator. These network and service control tensions are addressed by the policy layer. They need to be resolved by the AAA exchanges that occur during the request to connect to the foreign subnet. This draft does not overly consider which of these commercial models is more important for MIP multicast and simply aims to make all practical options available to the parties involved. A discussion of the type of AAA support required for the specific suggestions in this draft are however outlined in section 7. 5.2. Foreign Multicast System in RFC3220 The foreign subnet has an IGMP Querier, a multicast designated router (DR) and at least one Foreign Agent (FA). The IGMP Querier issues Queries to the all-multicast-systems IP broadcast address, and the multicast DR and other receive GMRs from the MNs addressed to the multicast group address of interest. These IGMP messages are transmitted unencapsulated over the foreign subnet. The foreign multicast system uses native multicast routing from multicast senders in the Internet, down the multicast distribution tree towards those DRs that have joined to the group on behalf of their attached MNs. The DRs then transmit the multicast packets unencapsulated over the access link to the MN members that are members of the multicast group identified by the group destination address. A.W. O'Neill Expires Dec 2002 [Page 4] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 It can be seen that when multiple DRs in an access network are members of the same multicast group, and each DR has multiple MNs on that group, that the use of native multicast forwarding results in a single copy of each packet from the core of the network out across the access network and over the access link to the MN members. This represents the potential for significant bandwidth savings when compared to the home multicast system. CN HA FA MN MN with FA CoA MN Reception CN------------------------------G>----------------->G MN Origination G<------ NOT PERMITTED MN with CCoA MN Reception CN------------------------------G>----------------->G MN Origination G<----------------CCoA Figure 1. Forward and reverse foreign network multicast in RFC 3220 MN origination is not permitted when the MN has a FA CoA and hence such MNs can only receive multicast content. This prevents MIPv4 MNs, which typically cannot afford to be given a unique CCoA at each FA, nor afford the delay of continually updating this CCoA on hand-off, from taking part in bi- directional multicast flows that are typical with RTP sessions, and common in other multicast data applications. MN origination is permitted when the MN has a CCoA, with that CCoA used as the source address. Once again multicast packets are sent unencapsulated over the access link, this time from the MN to the multicast DR on the subnet. This router forwards the packets into the multicast tree for the group contained in the destination address field of the packet. It can be seen here that whilst the multicast forwarding is bandwidth efficient, through the use of native multicast, it is limited to MNs with CCoAs. 5.3. Home Multicast System in RFC3220 The home multicast system in RFC 3220 uses a bi-directional tunnel between the HA and the MN CoA. The MN can have either a FA CoA or a CCoA from the FA and the resulting forwarding and encapsulations are shown graphically in figure 1. The MN should set the 'B' bit in the MIP RREQ to request the HA to forward to the MN, amongst other broadcast traffic, IGMP Queries and possibly IGMP Group Membership Reports to the MN. The MN can then issue solicited or unsolicited GMRs for the groups and group senders of interest to that MN, and the HA can then keep MN specific IGMP state to enable it to make appropriate forwarding decisions for multicast traffic arriving to the home subnet. Note that the HA must also export the MN GMRs to the home subnet, so that it can be seen by the IGMP Querier, received by the multicast DR on the home subnet for injection into the multicast tree building protocol, and also be seen by other MNs on the subnet to suppress their own GMRs. The IGMP Queries and GMRs must be sent encapsulated over the foreign subnet to avoid them being confused with foreign subnet IGMP signalling, with the encapsulation being the same as that used for multicast content. A.W. O'Neill Expires Dec 2002 [Page 5] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 CN HA FA MN MN with FA CoA MN Reception CN----------G>------------------------------------->G HA===================================>HoA HA==============>CoA MN Origination G<---------G<-------------------------------------HoA HA<===================================HoA MN with CCoA MN Reception CN----------G>------------------------------------->G HA==================================>CCoA MN Origination G<---------G<-------------------------------------HoA HA<==================================CCoA Figure 2. Forward and reverse home network multicast in RFC 3220 The major limitation here is that MN reception of multicast content is via a unicast tunnel from its HA. This tunnel is required to hide the multicast content from the foreign multicast system and to identify the target MN (the HoA/CCoA is otherwise missing due to the multicast packet having a group destination address). There is then potential for significant replication load being placed on the HA (and associated loss of bandwidth efficiency) when significant numbers of registered MNs at that HA are members of the same multicast group. In addition, when multiple MNs on the same foreign subnet are members of the same multicast group then multiple copies of the same content must be delivered to that foreign subnet and delivered over the air- interface in wireless systems. Only in the case that neither the HA nor the FA has multiple members of the same group (low membership coherence) is their no gain to be had from using multicast (network tree building and replication) between the HA and the FA. In all other cases, the absence of a multicast delivery tree potentially results in significant inefficiencies. When comparing the delivery costs (encapsulation processing and overhead) of multicast and unicast content from the HA in this model, it is evident that it is potentially better to use a multicast to unicast gateway on the home subnet and delivery any content using unicast, instead of incurring the additional cost and complexity of the unicast encapsulation and associated multicast signalling. MN origination of content is via a unicast tunnel from the MN to the HA, using the HoA as a multicast source address. The unicast tunnel is less of an issue here because source specific branches from senders are common in multicast tree building and therefore the unicast tunnel does not result in significant multicast inefficiencies. The tunnel is required simply to hide the multicast content from the foreign multicast system. 5.4. Non-Member Multicast Senders It is permitted in the multicast architecture for a host to send traffic towards a multicast group of which it is not a member. When a host sends an IGMP GMR for group G, it is specifically asking to be a receiver of the group but may also wish to send to that group. A non-member sender is not a receiver on the group and is likely only a transient sender. This is A.W. O'Neill Expires Dec 2002 [Page 6] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 typically used to support early media flows in parallel with IGMP processing, for transient senders that do not wish to disturb the multicast routing fabric, and for supporting sensor devices that are clearly not interested in the traffic from other senders. A non-member sender simply originates packets to the group G and the multicast designated router forwards these into the multicast receiver tree, without initiating any receiver tree building activity in the multicast routing protocol. Non-member sender traffic is still however exposed to RPF checks. Non-member senders can be supported in either home or foreign multicast systems and therefore IGMP (or MLD) signalling may not occur before MN originated traffic flows. 5.5. Reverse Tunnelling Enhancements from RFC 3024 Reverse Tunnelling was developed to provide topologically correct tunnels back to the HA. When the MN has a FA CoA and wishes to tunnel traffic, including MN originated multicast, back to the HA then in RFC3220 as shown in figure 2, this is achieved by a MN to HA tunnel using the HoA as a source address. Unfortunately, the HoA is not a topologically correct source address and hence risks being dropped in the Internet in routers deploying source address checking. RFC 3024 instead adds the ability for the tunnel to instead be initiated from the FA towards the HA and hence being topologically correct. Reverse tunnelling is requested by setting the 'T' bit in the MIP RREQ from the MN to the FA and onto the HA. There are then two modes for forwarding between and the MN to FA. In the default Direct Delivery Style (DDS), the MN sends the packets unencapsulated to the FA which then tunnels all received packets to the HA in the reverse tunnel. Essentially, all MN originated packets are viewed as being home network packets and foreign multicast is not permitted. Unfortunately, this method does not work however for multicast packets on a broadcast foreign subnet (not point to point) because these home broadcast packets will be confused with foreign broadcast packets by other MNs on the subnet and can be incorrectly received. RFC 3024 therefore mandates the second form of reverse tunnel forwarding known as Encapsulating Delivery Style (EDS). In EDS, the MN can selectively reverse tunnel packets to the HA through the use of an encapsulation between the MN and the FA. EDS mode is selected by the MN in the MIP RREQ by including an EDS extension as well as setting the 'T' bit. The EDS extension is not forwarded to the HA and is viewed as purely a local matter between the MN and the FA. Packets which are encapsulated in a tunnel from the MN HoA to the FA are switched into a MIP tunnel from the FA CoA to the HA address. The HA then decapsulates them, and then forwards them onto the home subnet. The encapsulation on the foreign subnet also means that home multicast packets are hidden from the foreign broadcast subnet and are therefore not confusing to other MNs on the foreign subnet. Packets that are not to be reverse tunnelled are sent natively by the MN to the FA, which then forwards them normally, which in the case of foreign multicast is down the multicast tree. Essentially, EDS mode enables a MN to potentially partake in both home and foreign network multicast at the same time with the encapsulations over the foreign subnet being used to separate out IGMP and multicast content from/to the home and foreign multicast systems. Clearly, a MN would not wish to join the same multicast groups via both systems and so the MN, FA and HA need to have some configuration or AAA policy to decide which multicast systems the MN can participate in, and its limitations on that system (receiver, sender, receiver and sender, multicast group scope). Additionally, as has been described in 5.1, it is only a CCoA that enables a MN to originate traffic towards the foreign multicast system. A.W. O'Neill Expires Dec 2002 [Page 7] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 5.6 The Problem with CCoAs Referring back to section 4.4 in RFC3220, the claim is made that MN origination into the foreign multicast system must use a CCoA. This is because the multicast source address must be topologically correct to pass the multicast reverse path forwarding check. This process, which is common to almost all multicast forwarding engines, is used to build source trees and to prevent routing loops. This is achieved by having the multicast forwarding engine in each multicast router, look-up the unicast source address within each multicast packet, as a unicast destination address in the unicast forwarding table. If the multicast packet arrives on an incoming interface, which is also the outgoing interface that would be used to forward unicast packets to that unicast destination address, then the RPF check has succeeded and the multicast packet may for replicated and forwarded. Putting aside transient routing effects, this RPF check will generally succeed for MN originated packets when the topologically correct CCoA is used as a source address. However, the RPF check will not generally succeed if the MN HoA is used as the source address because the HoA is topologically incorrect (belonging to the home subnet) and hence the multicast packets will not be received over the interface used to forward unicast packets towards the HoA. RFC 3220 is therefore correct in its statements and decisions in this regard. However, RFC 3220 fails to mention that there is an additional problem with CCoAs. This is that the CCoA is a transient address and must change on each hand-off if the MN keeps moving. Each such address changes has a damaging affect on multicast applications and routing. For example, IGMPv3 enables a host to undertake source specific membership of a group, specifically enabling a MN to ignore content or receive content only from specific senders to that group. Protocol Independent Multicast-Sparse Mode (PIM-SM) also has source specific JOIN and PRUNE mechanisms that act in sympathy with sender specific group membership signalling to ensure only requested content is delivered down the multicast tree. In addition, PIM-SM supports both shared and source specific trees with the source specific PIM JOINs creating (S, G) state to over-rule the (*,G) shared tree state. Source Specific Multicast (SSM) is also under development in the IETF in which the multicast destination group address as well as the senders unicast address identifies the multicast 'channel', and multicast routers keep (S+G) state. Finally, multicast transport and session layers applications typically use the multicast source address to 'demultiplex' content into sender specific feeds. This is because at a simplistic level, many to many network multicast is simply a superposition of multiple one to many transport flows. In all these cases, a change in the multicast source address will create significant problems, requiring the address change to be communicated down the tree in advance of the CCoA update, so that new source specific routing state can be installed for (S2,G) or (S2+G) instead of (S1,G) or (S1+G). It must also be known to the host so that receiver applications can update transport, session and application state, to avoid application confusion and data corruption or loss. The scale of the update (all router and host sender specific state for that sender) coupled with the likely speed of hand-offs (and hence CCoA changes), makes the choice of the CCoA as a source address extremely problematic. Essentially, it completely prevents the MN from using the foreign multicast system and it must instead use the less efficient home multicast system. In solving the RPF problem, and preserving the packets of a single MN originator, it is clear that RFC 3220 creates an even bigger A.W. O'Neill Expires Dec 2002 [Page 8] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 problem, with wider implications on multicast routing stability. This is because the mobility is being directly exposed to the global multicast routing system through the address change, but is not being exposed to the unicast system (MIP instead deals with the latter). Note that the use of the HoA in the home multicast system coupled with the unicast tunnelling back to home subnet is one obvious way for multicast and MIP to collaborate in getting the job done. This however misses the efficiency of the foreign multicast delivery tree. The only way to correct this problem is to use the MN HoA as a multicast source address for the foreign multicast system (aligning somewhat home and foreign multicast processing on the hosts) and then find scalable means for MIP and the foreign multicast routing to work together to preserve the senders packets through the RPF check process. A range of techniques are next described in section 6, with the different techniques potentially forming an evolution and interoperability capability, as MIP and multicast technologies and standards evolve. They are described in overview to stimulate discussion between mobility and multicast researchers, so that standards activity can be commenced to address this opportunity. 6. HoA based MIP Multicast The aim, in summary, is to enable a MN to originate IP multicast traffic using the HoA as a source address and have those packets correctly delivered by the foreign multicast system by specifically bypassing or satisfying the multicast RPF checks. This needs to work when the MN has requested EDS reverse tunnelling ('T' bit set plus EDS extension) or when no reverse tunnelling has been requested ('T' bit unset'). With DDS reverse tunnelling, it is clear that foreign multicast is by definition prevented and is not discussed further. An additional requirement is that the MN should not need to be aware of how the local FA is addressing this problem so that the MN can simply be made aware that foreign multicast origination is possible and then undertake home and foreign multicast as befits its configuration, incoming signalling, and the policy exchanged between the HA and FA. This idealised foreign multicast system is shown in figure 3 where the MN believes the FA (specifically the multicast designated router on the foreign subnet if different from the FA) is able to inject the multicast packets into the foreign multicast system and the multicast system will safely deliver them through the Internet to the multitude of CN multicast receivers on that group. This distribution should at all times be limited by the appropriate scope of the multicast group. Note that in the idealised system, the MN processing is the same for both a FA CoA and a CCoA. CN HA FA MN MN with FA CoA MN Reception CN-------------------------------G>---------------->G MN Origination G<------------------------------G<----------------HoA MN with CCoA MN Reception CN-------------------------------G>---------------->G MN Origination G<------------------------------G<----------------HoA Figure 3. Idealised Foreign Multicast System A.W. O'Neill Expires Dec 2002 [Page 9] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 Before discussing the alternative solutions to this problem, it is important to point out that these solutions are covered at a relatively high-level and significant work in standards and subsequent engineering may be required to turn these suggestions into commercial reality. For now, they should simply be considered as examples to justify the potentially reality of MIP foreign multicast, using the HoA as a source address. 6.1 Hybrid Multicast System The first (early) solution to this problem is to combine the best of the home and foreign multicast systems in satisfying the problem, thereby creating a hybrid multicast system. For simplicity, we will assume that the FA is also the multicast designated router for the foreign subnet. We can also assume that unencapsulated IGMP and multicast packets with a HoA source address are intended for the foreign multicast system, whether or not the 'B' bit is set or EDS RevTun has been requested and the 'T' bit is set. Essentially, we care greatly about being able to receive multicast via the foreign multicast system to accrue the bandwidth efficiencies, but care less about the path of the sender specific MN originated traffic. The MN may or may not be a member of the multicast group G, whose scope must encompass both the home and foreign subnets (global scope only). If the MN is a member of group G then it will have sent an IGMP GMR for group G to the FA/DR and the FA/DR will have tracked IGMP state and initiated multicast tree building to add the FA/DR onto the receiver trees for the groups of interest to its MNs. This MN, and other MNs on that foreign subnet, will then receive multicast from the FA/DR in an unencapsulated form, and via a bandwidth efficient foreign multicast tree. We will now discuss how this is complemented with MN originated traffic. 6.1.1. MNs with FA CoA The MN originates traffic to the group G by sending unencapsulated packets onto the foreign subnet with its HoA as a source address and a destination address of G. On a broadcast subnet, other members of group G on that subnet will also receive the packet. The FA also receives these packets but instead of injecting them into the foreign multicast system, it instead reverse tunnels them to the HA that matches the senders HoA in the visitors list, with the non-local HoA address acting as the trigger for this redirection. The HA knows the FA CoA from the registration and should therefore be happy to receive encapsulated packets from the registered FA CoA to the HA. Specifically, it needs to be happy to receive multicast packets via the FA CoA when the 'T' bit is not set. It will of course already be happy if the 'T' bit is set from RFC3024. The HA has no IGMP state for such packets and treats them as non-member sender packets by injecting them into the home multicast system without initiating any receiver tree building. These MN originated packets are topologically correct at the HA and hence will satisfy any subsequent RPF checks except under transient routing situations. Note that the FA must first undertake its own multicast RPF check on the multicast packet using MIP visitor list state instead of the unicast routing state, before forwarding the packet to the HA. In addition, the FA needs to deliver the MN originated packets to other receivers of that group on that FA if the MNs are using point to point links. A.W. O'Neill Expires Dec 2002 [Page 10] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 This is because the multicast routing in the FA must itself not forward the packets again onto the foreign subnet when received down the multicast distribution tree, if they contain source addresses matching HoAs in the visitor list. This is necessary to avoid duplicate delivery on broadcast foreign subnets and is commonly achieved by the DR installing a source specific routing entry to discard packets arriving via a unidirectional shared tree that were originated from that DR. 6.1.2. MNs with CCoAs When a MN has a CCoA it may or not have registered via the DR, which has an FA in MIPv4 or an attendant in MIPv6. If the MN has not registered via the DR then the DR cannot support hybrid multicast by forwarding the MN originated multicast packets to the HA because it has no state to do so. More specifically, the DR in this case cannot support MN originated foreign multicast traffic at all because any packets with a HoA source address, including IGMP GMRs, are topologically incorrect and hence will be discarded during ingress filtering in the absence of MIP visitor list state. If the MN has registered via the DR then the DR will know the MN/CCoA/HA binding but in addition needs to know the MN/HoA binding to enable it to pass MN originated packets during ingress filtering and to then be able to tunnel them to the HA from the DR address. There are clearly ways that the MN could provide this information to the DR and the HA via a MIP extension, so that the tunnelling is both possible and acceptable, but this clearly requires the MN to be aware of the need to add such an extension. Thankfully, this extension is also required to enable the FA to natively forward unicast packets from the HoA and hence does not imply that the MN needs to know about the foreign multicast mechanism. The FA/DR receives the unencapsulated MN originated multicast packets and forwards them to the HA using the FA/DR address as a source address. The HA then receives packets from an address that is not equal to the registered CoA, but is equal to the source address of the received registration via that FA/DR and hence should be accepted because the HA and FA share an SA. The use of the HoA as a source address for foreign multicast can therefore only be permitted if the MN has registered via the FA/attendent and has informed that node of the MN HoA for ingress filtering purposes. CN HA FA/DR MN MN with FA CoA MN Reception CN-------------------------------G>---------------->G MN Origination G<------------------------------G<----------------HoA HA<=============FACoA MN with CCoA via FA MN Reception CN-------------------------------G>---------------->G MN Origination G<------------------------------G<----------------HoA HA<=============FACoA Figure 3. Hybrid Multicast System A.W. O'Neill Expires Dec 2002 [Page 11] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 Note that the use of the HoA as a multicast source address implies very different processing on the MN than the existing use of the CCoA. This is clearly a significant concern because MIPv6 relies solely on a MN CCoA, and its use for foreign multicast is potentially broken as discussed in section 8. This effectively means that MNs should be prevented from initiating foreign multicast content from the CCoA except in the specific case that the MN is sure that the CCoA will not be changing during the lifetime of the multicast session. This clearly excludes cellular mobility environments. 6.2 Shared Tree Solution Some multicast routing protocols, such as PIM-SM, use a shared tree from a root node out to all receivers. The RPF check in this shared receiver tree is not made towards the senders unicast address in the multicast packet, but is instead made towards the root node whose address is distributed to all the multicast routers. Therefore the RPF problem with a non-local HoA address only needs to be solved between the senders designated router and the root node for such shared trees. This can be achieved by using a unicast tunnel from the DR to the root node, and then have the root node forward the senders packets down the receiver tree. CN RP HA FA/DR MN MN with FA CoA MN Reception CN----------G>-------------------G>---------------->G MN Origination G<---------G<-------------------G<----------------HoA RP<======REG=====FACoA MN with CCoA via FA MN Reception CN----------G>-------------------G>---------------->G MN Origination G<---------G<-------------------G<----------------HoA RP<======REG=====FACoA Figure 4. PIM-SM RP MIP Solution In the specific case of PIM-SM, shown in figure 4, the root node is called the Rendevouz Point (RP) and PIM-SM already has mechanisms to enable the DR to tunnel packets directly to the RP using a Register message encapsulation. In the case of member senders, the RP is able to then try to PIM JOIN back to the sender via the senders DR and transmit periodic Register Stop messages to the senders DR. The PIM JOIN is intended to enable the senders DR to send packets natively to the RP via a source specific branch whilst the Register Stop is intended to prevent the parallel encapsulation of multicast packets from the senders DR to the RP in Register messages. In addition to the source specific branch to the RP from the senders DR, any receiver DR is also allowed to try to build a source specific branch towards the senders DR and in so doing bypass the RP and the shared tree. A.W. O'Neill Expires Dec 2002 [Page 12] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 In the case of foreign multicast, both of these source specific branches will be directed towards the HoA in the source address of the multicast packet (and hence the HA subnet), and not towards the senders DR, which is the FA. These source specific PIM JOINs will therefore install state that will not be exercised by packets unless they cross part of the shared tree. The existence of this state is not a problem however as it will not cause problems and will eventually safely time out due to the soft state refresh model in PIM. The Register message could be extended to inform the RP not to bother attempting a PIM JOIN for this (S,G) and hence avoid wasted PIM JOIN and Register Stop signalling. In addition, the DR or RP could also periodically send a new PIM message down the multicast tree to the receiver DRs to also instruct them not to undertake source specific JOINs for this (S,G). Comparing this model to the hybrid approach of 6.1, we can see a number of advantages that accrue when the multicast protocol uses a shared tree and supports unicast encapsulation to the root node. Firstly, in the hybrid approach it is clear that senders packets first go to the HA and then potentially onto the root node within a shared tree protocol. Therefore, sending the packets directly to the root node removes an additional encapsulated hop which is specifically useful when the HA and RP and far apart. In addition, we can see that by leaving all forwarding to the FA/DR we remove any uncertainties about the scope of group G, that otherwise limits the hybrid approach to global scope only. Finally, the most widely deployed multicast protocol in the Internet is PIM-SM and therefore the availability of a shared tree protocol with encapsulation to the root is generally assured. This solution does not however address the problem associated with CCoAs, nor does it deal with other types of multicast routing protocols with MOSPF a particular concern. MOSPF domains can of course still rely on the Hybrid solution of 6.2. 6.3 MIPv4 FA Multicast Encapsulation and MIPv6 RPF Redirect Option The first two solutions rely on a unicast encapsulation to a point at which the HoA source address can pass subsequent RPF checks. An alternative solution is to encapsulate throughout the tree using an MIP multicast encapsulation. The FA encapsulates packets with a non-local HoA source address that have passed MIP aware ingress checking, using its own address as the source address and the inner destination group G as the outer destination address. This packet will then have a topologically correct source address and can be correctly forwarded by any multicast protocol that builds on- demand source trees to the receivers of G via (anyFA,G) state. The receivers will then decapsulate such packets to reveal the original multicast packet with the HoA source address, which will then be checked against the source specific host membership state before being passed up to the transport layer. Essentially the host is prepared to receive from any FA and therefore does not need to be kept informed of FA CoA changes. Any source specific tree building triggered by the receiver DR state should be suppressed when the data is received encapsulated like this. This approach again bypasses the HA with all the associated benefits, and this time is applicable to multicast protocols other than PIM-SM which would continue to use the Register encapsualtion. This however comes at the cost of host (and potentially DR) complexity, and the bandwidth inefficiency of the multicast encapsulation. In addition, this clearly does not work directly for explicit join protocols, the and in general limits any (S,G) pruning to the granularity of the FA address, such that multiple senders at the same FA cannot be selected/pruned. A.W. O'Neill Expires Dec 2002 [Page 13] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 The cost of the encapsulation can be reduced in MIPv6 through the use of a new hop by hop option header. This 'RPF Redirect' option would be added by the MN and checked by all multicast routers, and includes the CCoA. The RPF redirect header therefore provides the opposite binding information to routers to that provided to the host by the Home Address Option (HAO) The RPF Redirect option would then be used in multicast routers to redirect RPF checks towards the senders DR instead of the HoA. The RPF Redirect Option or the source address of the FA encapsulation technique can be used by hosts to redirect source specific joins and prunes towards the newDR address, rather than towards the multicast source address of the original multicast packet. These redirections are clearly however affected by FA changes and this issue will be left for discussion in section 6.4.4. 6.4 Multicast Signalling Extensions - RPF Redirection Section 6.3 handles the RPF problem in the data plane, but an alternative is to handle it in the multicast signalling plane. This is a longer-term solution in that changes to multicast signalling need to be widely deployed throughout a domain before they can be used, and because of the time to design, standardise and implement changes to deployed protocols. Essentially, the multicast RPF mechanism and the signalling in each routing protocol needs to be extended to support an arbitrary RPF point for the (S,G) in question. This is known henceforth in this document as RPF redirection and is analogous to the aims of the RPF Redirect option previously mentioned. During hand-off, the CoA address is changing at the senders end and therefore each sender DR needs to advertise the new RPF point for that sender. This is achieved by injecting an RPF Redirect message into the multicast routing system using hop by hop multicast protocol signalling that is sent down the present tree or broadcast to multicast neighbours (protocol specific). In the latter case, each router passes the current RPF point to any subsequent joiners so that the sender DR only needs to undertake a periodic refresh of the RPF point in the absence of mobility. In the former case, the RPF point needs to be flooded rapidly by routers that detect that the old and new RPF points are on different interfaces so that the rapid flood is limited to those routers that are affected by the change. Note that the change in the senders DR might take the MN to a newDR that has no other members of group G, and also leave the oldDR with no other members of group G. Therefore some of the above RPF redirection signalling can be coupled with tree building activity (join/prune/membership flood) at the old and newDRs. When the MN originator undertakes a hand-off, the oldDR and the newDR need to collaborate to update the RPF point. There is a cross-over router in the vicinity of both the old and new DRs that is the last router that would discard packets from the MN sent via the new DR, when using the oldDR as an RPF point. The newDR and all intermediate routers to the cross-over router need to be on the sender multicast tree for the group of interest, and must have the RPF point set to the newDR, in advance of multicast data being sent, to avoid that data being discarded. Once on the tree, then the newDR needs to send periodic RPF Redirects from the newDR to maintain the RPF point and the tree. At the same time, the receiver tree must also be updated. The precise mechanisms are of course multicast protocol specific due to the wide range of protocol mechanisms such as explicit join (PIM), member report broadcast (MOSPF), and data flood and prune (DVMRP) as examples. A.W. O'Neill Expires Dec 2002 [Page 14] INTERNET-DRAFT Mobility Management and IP Multicast May 2002 6.4.1 PIM-SM Example (SSM also) PIM uses explicit join/prune messaging to build either a shared tree from the RP, or source specific tree using the source address contained in multicast packets received on the shared tree. A source tree or Register encapsulation can be used between the DR and the RP in the case of a shared tree. During a hand-off on a shared tree with a source specific branch to the RP, the oldDR first needs to send an RPF Redirect down the multicast tree to first seek out the cross-over router. The RPF Redirect message contains the old DR address, the destination group address, the HoA source address, and the newDR address. The cross-over router is identified by the next hop router towards the RP, termed the Hand-Off (HO) router, which detects that the RPF Redirect message does not affect the local RPF check because the oldDR and newDR interfaces are already the same. This router therefore issues an immediate JOIN towards the newDR to create (S,G,