Internet Engineering Task Force T. Axel Internet-Draft Deutsche Telekom Intended status: Informational Q. Sun Expires: September 6, 2012 China Telecom C. Zhou Huawei Technologies March 05, 2012 Multicast transition path optimization in IPv4 and IPv6 networks draft-zhou-mboned-multrans-path-optimization-00 Abstract This document describes a mechanism to optimize the path between the multicast router and multicast source in both IPv4 and IPv6 networks. The basic idea is that when a multicast translation router has an IPv4 path and an IPv6 path to the same multicast data source, and both IPv4 and IPv6 joins are received, only one path is used. One path is pruned, instead of the same traffic flowing over both v4 and v6 paths. By adding a metric to the IPv4 path, the multicast translation router can determine which path to receive multicast data: IPv4 path, IPv6 path or both paths. Therefore, an optimization path will typically be chosen when an identical v4/v6 traffic flow exists. Requirements Language 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 . Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 6, 2012. Axel, et al. Expires September 6, 2012 [Page 1] Internet-Draft Multrans path optimization March 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Context and Scope . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. A general topology for IPv4 and IPv6 multicast networks . . 5 4.2. Parsing MTR to two virtual Routers . . . . . . . . . . . . 6 4.3. Solution for selecting interfaces to S or RP . . . . . . . 7 4.4. Solution for selecting a multicast data flow from upstream interface . . . . . . . . . . . . . . . . . . . . 7 4.5. Modifications to mulitcast PIM-SM Router . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Axel, et al. Expires September 6, 2012 [Page 2] Internet-Draft Multrans path optimization March 2012 1. Introduction It is common to use multi-access LANs such as Ethernet for transiting multicast data in networks. Section 3.6 of[RFC4601] describes Multi- Access Transit LANs. The Corresponding solution is provided by using PIM Assert message. When duplicate data packets appear on the LAN from different routers, these routers notice this and then elect a single forwarder. This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source-specific trees. When IPv4 networks migrate to IPv6 netwroks, it is common that there are many IPv4 networks and many IPv6 networks that connected to each other. Then, there will be many multicast translation routers(MTR) at the edge of a network. For robustness, reliability and load distribution purposes, MTR function could be implemented in several nodes in the network. MTR can be the mAFTR (Multicast AFTR ) mentioned in [draft-ietf-softwire-dslite-multicast]. mAFTR can encapsulate IPv4 multicast data in IPv6 tunnel. MTR can also be the mXlate (Multicast Translator) as mentioned in [draft-lee-behave-v4v6-mcast-fwk]. mXlate can translate IPv4 multicast data to IPv6 multicast data. As the result, MTR (mXlate or mAFTR) will have more than one path to reach the RP or source S in IPv4 networks and IPv6 networks. Or in other words, they will have two upstream routers: one is IPv6 router, and the other is IPv4 router. MTR can reach the RP or source S by both paths. Since MTR can receive both IPv4 and IPv6 (*,G) (or (S,G)) Join request, it needs to select a best path to RP or S in both IPv4 and IPv6 networks. When it receives the two same multicast data flows via IPv4 and IPv6 interfaces, MTR needs to send Prune Message to the worse path interface. Figure 1 shows the scenario that MTR can reach source S through both IPv4 path and IPv6 path. 2. Terminology This document makes use of the following terms: mXlate: A multicast translator mentioned in [draft-lee-behave-v4v6-mcast-fwk]. mAFTR: A multicast Address Family Transition Router mentioned in [draft-ietf-softwire-dslite-multicast]. Axel, et al. Expires September 6, 2012 [Page 3] Internet-Draft Multrans path optimization March 2012 MTR: A multicast translation router, it can be mAFTR or mXlate. PIM-SM: Protocol Independent Multicast-Sparse Mode RP:Rendezvous Point 3. Context and Scope 3.1. Context and Scope When IPv4 multicast network migrates to IPv6 multicast network, IPv4 networks and IPv6 networks will coexist for a long time. This draft describes PIM-SM routers at network edge of IPv4 and IPv6 networks during the migration. Multicast services such as Live TV Broadcast may use this technology. This document focuses only on the issues of inter-access between IPv4 multicast networks and IPv6 multicast networks. The scenarios include that an IPv6 receiver gets the multicast data from a IPv4 source , an IPv4 receiver gets the multicast data from a IPv6 source, or both IPv4 and IPv6 receivers get the multicast data from IPv4 or IPv6 source. 4. Solution Overview This section gives a sloution for the issues mentioned above. Axel, et al. Expires September 6, 2012 [Page 4] Internet-Draft Multrans path optimization March 2012 4.1. A general topology for IPv4 and IPv6 multicast networks /----\ /--------\ |IPv4 | +--------+ // \\ /|Router+---/----\ |IPv4 +--| IPv4 network \ / \----/ |IPv4 | |Receiver| \\ // \\ +---------+/ |Router| +--------+ \--------/ \ | / \---+/ \| MTR1 | | | \ /-+--\ /--------\ // |\ |IPv4 | +--------+ // \\ // +---------+ \ |Router| |IPv6 +---| IPv6 network / \ \-+--/ |Receiver| \\ // \ /----\ | +--------+ \--------/ \IPv6 \ +----+--+ |Router|\\| | \----/ \MTR2 | | | /--------\ +---|---+ // \\ | IPv4 Source --------| \\ // \--------/ Figure 1: MTR can reach IPv4 Source through IPv4 path and IPv6 path Figure 1 shows that MTR1 can access IPv4 Source through IPv4 path or IPv6 path.MTR1 has two upstream routers, one is IPv4 Router and the other is IPv6 Router. MRT1 receives IPv4 (*,G) or (S,G) Join request from IPv4 network and IPv6 (*,G) or (S,G) Join request from IPv6 network. MTR1 can send Join request to RP or source S from interface connected to IPv4 Router or from interface connected to IPv6 Router. MTR1 may also send Join request from both upstream interfaces. In this case, MTR1 need to select a best path to RP or S in both IPv4 and IPv6 networks. MTR1 sends Prune Message to the worse path, when it receives two identical multicast data flows in IPv4 and IPv6 upstream interface. MTR1 may receive two identical multicast data flows at the same time and stop interworking multicast data flow between IPv4 network and IPv6 network. Axel, et al. Expires September 6, 2012 [Page 5] Internet-Draft Multrans path optimization March 2012 4.2. Parsing MTR to two virtual Routers * * * * +--*------*---+ | | | | | MTR1 | | | | | +--/-------\--+ / \ / vvvvvv \ v v v v v v v v v v v v v v vv vv IPv4 upstream vvvvvv IPv6 upstream interface: X v v interface: A * vv * * * +------*----------------*------+ | //--*--\\ //--*--\\ | | |Virtual | |Virtual | | | |v4 Router+----+v6 Router| | | \\---/-// IF:V \\--\--// | | / \ | +------/-----------------\-----+ / \ / \ IPv6 downstream IPv6 downstream interface: Y interface: B For simplification, we use two virtual Routers to replace MTR1 Router. Figure 2 shows that MTR1 can be taken as two virtual Routers. The one on the left is a Virtual IPv4 Router, the one on the right is a Virtual IPv6 Router. Virtual IPv4 Router has an IPv4 upstream interface X and an IPv4 downstream interface Y. Virtual IPv6 Router has an IPv6 upstream interface A and an IPv6 downstream interface B. The interface between two virtual Routers is V. When MTR receives two multicast data flows (one from IPv4 interface and the other from IPv6 interface), it compares two flows according to [draft-ietf-mboned-64-multicast-address-format] to confirm whether they are the same multicast data flows. If they are the same data Axel, et al. Expires September 6, 2012 [Page 6] Internet-Draft Multrans path optimization March 2012 flows, select one or two. When MTR Receives a IPv6 (S, G) or (*, G) Join, virtual IPv6 Router needs to select an interface to send Join message. The interface can be IPv6 upstream interface A or IPv4 upstream interface X (via interface V). 4.3. Solution for selecting interfaces to S or RP The steps to select an interface to S or RP. 1.Set the Metric value m1 for translation or encapsulation from IPv4 muticast to IPv6 multicast data. 2.From interface A connecting IPv6 Router, MTR can get the metric m2 to reach S or RP by PIM assert message sent from IPv6 Router. 3.From interface X connecting IPv4 Router, MTR can get the metric m3 to reach S or RP by PIM assert message from IPv4 Router. 4.When MTR receives a IPv6 PIM Join message, virtual IPv6 Router compares m2 and m3+m1. If m2>m3+m1, sending PIM Join message from IPv4 interface; If m2m3+m1, MTR will send PIM Prune Messages to IPv6 interface A; If m2. [draft-ietf-mboned-64-multicast-address-format] IETF, "IPv4-Embedded IPv6 Multicast Address Format", Feb 2012, . [draft-ietf-softwire-dslite-multicast] IETF, "Multicast Extensions to DS-Lite Technique in Broadband Deployments", Oct 2011, . [draft-lee-behave-v4v6-mcast-fwk] IETF, "IPv4/IPv6 Multicast Translation Framework", Feb 2011, . Axel, et al. Expires September 6, 2012 [Page 8] Internet-Draft Multrans path optimization March 2012 Authors' Addresses Axel.Clauberg Deutsche Telekom Phone: Fax: Email: Axel.Clauberg@telekom.de URI: Qiong Sun China Telecom Xizhimenneidajie Xicheng District Beijing, 100035 China Phone: Fax: Email: sunqiong@ctbri.com.cn URI: Cathy Zhou Huawei Technologies Section F, R&D Building, Huawei Longgang Production Base Shenzhen, 518129 China Phone: +85-755-28971869 Fax: Email: cathyzhou@huawei.com URI: Axel, et al. Expires September 6, 2012 [Page 9]