idnits 2.17.1 draft-zhou-mboned-multrans-path-optimization-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 218 has weird spacing: '... vv vv...' == Line 219 has weird spacing: '...pstream vvvvv...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (February 20, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Sun 3 Internet-Draft China Telecom 4 Intended status: Informational C. Zhou 5 Expires: August 24, 2013 Huawei Technologies 6 February 20, 2013 8 Multicast transition path optimization in IPv4 and IPv6 networks 9 draft-zhou-mboned-multrans-path-optimization-03 11 Abstract 13 This document describes a mechanism to optimize the path between the 14 multicast router and multicast source in both IPv4 and IPv6 networks. 15 The basic idea is that when a multicast translation router has an 16 IPv4 path and an IPv6 path to the same multicast data source, and 17 both IPv4 and IPv6 joins are received, only one path is used. One 18 path is pruned, instead of the same traffic flowing over both v4 and 19 v6 paths. By adding a metric to the IPv4 path, the multicast 20 translation router can determine which path to receive multicast 21 data: IPv4 path, IPv6 path or both. Therefore, an optimization path 22 will typically be chosen when an identical v4/v6 traffic flow exists. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in . 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 24, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. A general topology for IPv4 and IPv6 multicast networks . . 5 68 4.2. Parsing MTR to two virtual Routers . . . . . . . . . . . . 6 69 4.3. Selecting interfaces to Source or RP . . . . . . . . . . . 7 70 4.4. Selecting a multicast data flow from upstream interface . . 7 71 4.5. Requirements to the mulitcast Router . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 75 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 It is common to use multi-access LANs such as Ethernet for 81 transmitting multicast data in networks. Section 3.6 of[RFC4601] 82 describes Multi-Access Transit LANs. 84 The PIM Assert message could be used when there are two identical 85 multicast data flows (IPv4 and IPv6). When duplicate data packets 86 appear on the LAN from different routers, the routers notice this and 87 then select a single forwarder. This selection is performed using 88 PIM Assert messages, which solve the problem in favor of the upstream 89 router that has (S,G) state; Or, if neither or both router has (S,G) 90 state, then the problem is solved in favor of the router with the 91 best metric to the RP for RP trees, or the best metric to the source 92 via source-specific trees. 94 During IPv6 transition, it is common that there are many IPv4 95 networks and IPv6 networks that connected to each other, which means 96 that multiple multicast translation routers(MTR) exist at the edge of 97 a network. For robustness, reliability and load balance purpose, MTR 98 function could be implemented in several nodes in the network. MTR 99 can be the mAFTR (Multicast AFTR ) mentioned in 100 [draft-ietf-softwire-dslite-multicast]. mAFTR can encapsulate IPv4 101 multicast data in IPv6 tunnel. MTR can also be the mXlate (Multicast 102 Translator) as mentioned in [draft-lee-behave-v4v6-mcast-fwk]. mXlate 103 can translate IPv4 multicast data to IPv6 multicast data. 105 As a result, MTR (mXlate or mAFTR) will have more than one path to 106 reach the RP or source S in IPv4 networks and IPv6 networks. Or in 107 other words, they will have two upstream routers: one is IPv6 router, 108 and the other is IPv4 router. MTR can reach the RP or source S by 109 both paths. Since MTR can receive both IPv4 and IPv6 (*,G) (or 110 (S,G)) Join request, it needs to select a best path to RP or S in 111 both IPv4 and IPv6 networks. When it receives the two identical 112 multicast data flows via IPv4 and IPv6 interfaces, MTR needs to send 113 Prune Message to the worse path interface. Figure 1 shows the 114 scenario that MTR can reach source S through both IPv4 path and IPv6 115 path. 117 2. Terminology 119 This document makes use of the following terms: 121 mXlate: A multicast translator mentioned in 122 [draft-lee-behave-v4v6-mcast-fwk]. 124 mAFTR: A multicast Address Family Transition Router mentioned in 125 [draft-ietf-softwire-dslite-multicast]. 127 MTR: A multicast translation router, it can be mAFTR or mXlate. 129 PIM-SM: Protocol Independent Multicast-Sparse Mode 131 RP:Rendezvous Point 133 3. Scenarios 135 During the multicast transition from IPv4 to IPv6, there may be a 136 router which receives IPv4 join (PIM or IGMP) on one interface, and 137 an IPv6 join (PIM or MLD) on another interface (or it could even be 138 the same interface). The router should support IPv4 PIM and IPv6 PIM 139 that is translation capable. Assume these joins are for both IPv4 140 (S4,G4) and IPv6 (S6,G6), and that there are active sources for both, 141 sending basically the same content. Either because there is a real 142 source for both, or some upstream router is translating. The router 143 could then simply send upstream joins for both of these, and forward 144 the traffic as needed without translation. 146 However, if the router is aware that the same content comes from 147 these two sources, it could select to join one of the streams, and 148 translate as needed for the one downstream that wants a different 149 protocol. In this case, there will be a tradeoff between bandwidth 150 on the upstream links, and the cost of translation (both on this 151 device, and perhaps the quality of the stream). When PIM Assert 152 message is used to achieve this, the metrics for IPv4 and IPv6 should 153 be comparable and all the PIM devices on the link should support PIM 154 assert. 156 4. Solution Overview 158 This section gives a sloution for the issues mentioned above. 160 4.1. A general topology for IPv4 and IPv6 multicast networks 162 /----\ 163 /--------\ |IPv4 | 164 +--------+ // \\ /|Router+---/----\ 165 |IPv4 +--| IPv4 network \ / \----/ |IPv4 | 166 |Receiver| \\ // \\ +---------+/ |Router| 167 +--------+ \--------/ \ | / \---+/ 168 \| MTR1 | | 169 | \ /-+--\ 170 /--------\ // |\ |IPv4 | 171 +--------+ // \\ // +---------+ \ |Router| 172 |IPv6 +---| IPv6 network / \ \-+--/ 173 |Receiver| \\ // \ /----\ | 174 +--------+ \--------/ \IPv6 \ +----+--+ 175 |Router|\\| | 176 \----/ \MTR2 | 177 | | 178 /--------\ +---|---+ 179 // \\ | 180 IPv4 Source --------| 181 \\ // 182 \--------/ 184 Figure 1: MTR can reach IPv4 Source through IPv4 path and IPv6 path 186 Figure 1 shows that MTR1 can access IPv4 Source through IPv4 path or 187 IPv6 path.MTR1 has two upstream routers, one is IPv4 Router and the 188 other is IPv6 Router. MTR1 receives IPv4 (*,G) or (S,G) Join request 189 from IPv4 network and IPv6 (*,G) or (S,G) Join request from IPv6 190 network. MTR1 can send Join request to RP or source S from interface 191 connected to IPv4 Router or from interface connected to IPv6 Router. 192 MTR1 may also send Join request from both upstream interfaces. In 193 this case, MTR1 need to select a best path to RP or S in both IPv4 194 and IPv6 networks. MTR1 sends Prune Message to the worse path, when 195 it receives two identical multicast data flows in IPv4 and IPv6 196 upstream interface. MTR1 may receive two identical multicast data 197 flows at the same time and stop interworking multicast data flow 198 between IPv4 network and IPv6 network. 200 4.2. Parsing MTR to two virtual Routers 202 * * 203 * * 204 +--*------*---+ 205 | | 206 | | 207 | MTR1 | 208 | | 209 | | 210 +--/-------\--+ 211 / \ 212 / vvvvvv \ 213 v v 214 v v 215 v v 216 v v v v 217 v v v v 218 vv vv 219 IPv4 upstream vvvvvv IPv6 upstream 220 interface: X v v interface: A 221 * vv * 222 * * 223 +------*----------------*------+ 224 | //--*--\\ //--*--\\ | 225 | |Virtual | |Virtual | | 226 | |v4 Router+----+v6 Router| | 227 | \\---/-// IF:V \\--\--// | 228 | / \ | 229 +------/-----------------\-----+ 230 / \ 231 / \ 233 IPv6 downstream IPv6 downstream 234 interface: Y interface: B 236 For simplification, we use two virtual Routers to replace MTR1 237 Router. Figure 2 shows that MTR1 can be taken as two virtual 238 Routers. The one on the left is a Virtual IPv4 Router, the one on 239 the right is a Virtual IPv6 Router. Virtual IPv4 Router has an IPv4 240 upstream interface X and an IPv4 downstream interface Y. Virtual IPv6 241 Router has an IPv6 upstream interface A and an IPv6 downstream 242 interface B. The interface between two virtual Routers is V. 244 When MTR receives two multicast data flows (one from IPv4 interface 245 and the other from IPv6 interface), it compares two flows according 246 to [draft-ietf-mboned-64-multicast-address-format] to confirm whether 247 they are identical data flows. If they are the same, select one or 248 two. When MTR Receives a IPv6 (S, G) or (*, G)Join, virtual IPv6 249 Router selects an interface to send Join message. The interface can 250 be IPv6 upstream interface A or IPv4 upstream interface X (via 251 interface V). 253 4.3. Selecting interfaces to Source or RP 255 The procedure to select an interface to S or RP is as below. 257 1.Set the Metric value m1 for translation or encapsulation from 258 IPv4 muticast to IPv6 multicast data. 260 2.From interface A connecting IPv6 Router, MTR can get the metric 261 m2 to reach S or RP by PIM assert message sent from IPv6 Router. 263 3.From interface X connecting IPv4 Router, MTR can get the metric 264 m3 to reach S or RP by PIM assert message from IPv4 Router. 266 4.When MTR receives a IPv6 PIM Join message, virtual IPv6 Router 267 compares m2 and m3+m1. If m2>m3+m1, sending PIM Join message from 268 IPv4 interface; If m2m3+m1, MTR will send PIM Prune Messages to IPv6 interface 285 A; If m2. 322 [draft-ietf-mboned-64-multicast-address-format] 323 IETF, "IPv6 Multicast Address With Embedded IPv4 Multicast 324 Address", August 2012, . 327 [draft-ietf-softwire-dslite-multicast] 328 IETF, "Delivery of IPv4 Multicast Services to IPv4 Clients 329 over an IPv6 Multicast Network", Oct 2012, . 333 [draft-lee-behave-v4v6-mcast-fwk] 334 IETF, "IPv4/IPv6 Multicast Translation Framework", 335 Feb 2011, . 338 Authors' Addresses 340 Qiong Sun 341 China Telecom 342 Xizhimenneidajie Xicheng District 343 Beijing, 100035 344 China 346 Phone: 347 Fax: 348 Email: sunqiong@ctbri.com.cn 349 URI: 351 Cathy Zhou 352 Huawei Technologies 353 Section F, R&D Building, Huawei Longgang Production Base 354 Shenzhen, 518129 355 China 357 Phone: 358 Fax: 359 Email: cathy.zhou@huawei.com 360 URI: