idnits 2.17.1 draft-xu-softwire-4over6multicast-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2010) is 5164 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) -- Looks like a reference, but probably isn't: 'I-D.draft-metz-softwires-multicast-problem-statement-00' on line 105 -- Looks like a reference, but probably isn't: 'I-D.ietf-l3vpn-2547bis-mcast' on line 127 -- Looks like a reference, but probably isn't: 'RFC4291' on line 325 -- Looks like a reference, but probably isn't: 'RFC2373' on line 365 -- Looks like a reference, but probably isn't: 'RFC4601' on line 547 -- Looks like a reference, but probably isn't: 'RFC4301' on line 609 == Unused Reference: '1' is defined on line 626, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 629, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 632, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 635, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 639, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 642, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 647, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 655, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 4601 (ref. '4') (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 4925 (ref. '5') Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Xu 3 Internet-Draft Y. Cui 4 Expires: September 8, 2010 Tsinghua University 5 Chris. Metz 6 Cisco Systems 7 March 7, 2010 9 Softwire Mesh Multicast 10 draft-xu-softwire-4over6multicast-02 12 Abstract 14 The client networks could be of different address family with the 15 core network during IPv6 transition period. The client networks may 16 need to run IP multicast applications across the transit core while 17 it's not well supported currently. This memo provides a AFBR-based 18 softwire mesh multicast framework for IPv6 transition. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 8, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Softwire Mesh Multicast . . . . . . . . . . . . . . . . . . . 6 75 3.1. Schemes for Unicast core . . . . . . . . . . . . . . . . . 6 76 3.2. Schemes for Multicast core . . . . . . . . . . . . . . . . 6 77 3.2.1. Many to one mapping . . . . . . . . . . . . . . . . . 6 78 3.2.2. One to one mapping . . . . . . . . . . . . . . . . . . 6 79 4. RPF-Vector-Based Address Translation . . . . . . . . . . . . . 8 80 5. Inter-AFBR(Address Family Border Router) signaling . . . . . . 10 81 5.1. Address Mapping . . . . . . . . . . . . . . . . . . . . . 10 82 5.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 11 84 5.4. SPT Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.5. Shared Tree Scheme . . . . . . . . . . . . . . . . . . . . 14 86 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The Internet will need to support IPv4 and IPv6 packets. Both 97 address families and their attendent protocol suites support 98 multicast of the single-source and any-source varieties. As part of 99 the transition to IPv6, there will be scenarios where a backbone 100 network running one IP address family internally (referred to as 101 internal IP or I-IP) will provide transit services to attached client 102 networks running another IP address family (referred to as external 103 IP or E-IP). It is expected that the I-IP core will offer unicast 104 and multicast transit services to the client E-IP client 105 networks.[I-D.draft-metz-softwires-multicast-problem-statement-00] 107 The multicast framework for IPv6 transition can be described like 108 this: As the multicast group members and multicast sources(or RP) of 109 the group may be scattered in different client networks. In order to 110 transfer multicast traffic to the group members, softwire can be 111 used. In the control layer, the distribution trees must cover both 112 the transit core and client networks, so we need to connect the 113 transit core and client distribution trees together for a multicast 114 group in AFBRs. 116 It doesn't need any changes to construct the client distribution 117 trees, but a distribution tree needs to be constructed by the core 118 network, which could support multicast or not. If the core supports 119 multicast, a core tree can be constructed to help transfer multicast 120 traffic efficiently. However, if not, the AFBRs have to replicate 121 the multicast data and transfer them to other AFBRs in mVPN-like 122 mode.. 124 After giving the detailed scenario in the next section, we will give 125 an overview of softwire mesh multicast. Then a detailed introduction 126 of one to one mapping will be given, as many to one or all to one has 127 been realized by mVPN[I-D.ietf-l3vpn-2547bis-mcast]. Here mapping 128 means the relation between multicast groups in client networks and 129 multicast groups in the core network. 131 We mainly talk about PIM-SM(SSM) here as it's a representative 132 multicast protocol. 134 2. Scenario 136 -------- 137 |Receiver| 138 -------- 139 | 140 ._._._._. ._._._._. 141 | | | | -------- 142 | E-IP | | E-IP |--|Source S| 143 | network | | network | -------- 144 ._._._._. ._._._._. 145 | | 146 AFBR upstream AFBR 147 Dual-Stack Dual-Stack 148 | | 149 __+____________________+__ 150 / : : : : \ 151 | : : : : | E-IP Multicast 152 | : I-IP transit core : | message should 153 | : : : : | get across the 154 | : : : : | I-IP transit core 155 \_._._._._._._._._._._._._./ 156 + + 157 downstream AFBR downstream AFBR 158 Dual-Stack Dual-Stack 159 | | 160 ._._._._ ._._._._ 161 -------- | | | | -------- 162 |Receiver|-- | E-IP | | E-IP #|--|Receiver| 163 -------- |network | |network | -------- 164 ._._._._ ._._._._ 166 Figure 1: Softwire Multicast Scenario 168 The softwire multicast framework is illustrated in Figure 1. 169 Multicast source S is in one client network, while its receivers may 170 be in the same or different networks. When they are not in the same 171 client network, they have to communicate with each other through the 172 I-IP transit core. There may be several sources at the same time, 173 and they can also reside in different client networks. What's more, 174 when considering about RP, it may be in a different network with any 175 sources. 177 Some terminology is defined as follows: 179 o Softwire (SW) - A "tunnel" that is created on the basis of a 180 control protocol setup between softwire endpoints with a shared 181 point-to- point, multipoint-to-point, point-to-multipoint or 182 multipoint-to-multipoing state. Softwires are generally dynamic in 183 nature (they may be initiated and terminated on demand), but may be 184 very long-lived. 186 o Address Family Border Router (AFBR) - The dual-stack router that 187 interconnects two networks that use different address families. In 188 the context of softwires multicast, the AFBR runs E-IP and I-IP 189 control planes to maintain E-IP and I-IP multicast state respectively 190 and performs the appropriate encapsulation/decapsultion client E-IP 191 multicast packets for transport across the I-IP core. 193 o I-IP ("Internal IP"). This refers to the form of IP (i.e., either 194 IPv4 or IPv6) that is supported by the transit (or backbone) network. 196 o E-IP ("External IP") This refers to the form of IP (i.e. either 197 IPv4 or IPv6) that is supported by the client networks. 199 o I-IP core Tree. A single-source or multi-source distribution tree 200 rooted at one or more AFBR source nodes and branching out to one or 201 more AFBR leaf nodes. An I-IP core Tree is built using standard IP 202 or MPLS multicast signaling protocols operating exclusively inside 203 the I-IP core network. An I-IP core Tree is used to tunnel E-IP 204 multicast packets belonging to E-IP trees across the I-IP core. 205 Another name for an I-IP core Tree is multicast or multipoint 206 softwire. 208 o E-IP client tree. A single-source or multi-source distribution 209 tree rooted at one or more hosts or routers located inside a client 210 E-IP network and branching out to one or more leaf nodes located in 211 the same or different client E-IP networks. 213 o upstream AFBR: The AFBR router that located at the upstream of 214 multicast data flow, which connects the transit core and the client 215 network the RP/source S belongs to. 217 o downstream AFBR: The AFBR router that located at the downstream of 218 multicast data flow, which connects the transit core and the client 219 network which a group member of RP/source belongs to while the RP/ 220 source doesn't belongs to. 222 3. Softwire Mesh Multicast 224 We face all kinds of scenarios, the I-IP transit core may support 225 multicast, or not. We have multiple choices if it does. However, we 226 have to make use of unicast to transfer the multicast traffic. 228 3.1. Schemes for Unicast core 230 In some scenarios, the I-IP transit core does not run multicast 231 protocols, and thus AFBRs can not construct multicast distribution 232 trees in the I-IP transit core. Under this condition the multicast 233 control messages and data traffic from client networks are 234 encapsulated and decapsulated as common packets to get across the 235 core. 237 There are two alternative schemes in this scenario. One is the 238 ingress AFBR will replicate the packets to all the other AFBRs, which 239 is an easy solution as the AFBR knows the information of the other 240 AFBRs throught MP-BGP using softwire. The other one is the ingress 241 AFBR will replicate the packets to the necessary AFBRs, that is, the 242 AFBRs behind which have group members. The latter one is more 243 complex because the group members' location must be known. 245 3.2. Schemes for Multicast core 247 When the I-IP transit core supports multicast, we can build a 248 multicast tree or several multicast trees in the core so as to 249 transfer the traffic from the client network. According to the 250 number of groups in the core corresponding to the groups in the 251 client networks, there are many to one mapping and one to one mapping 252 to construct the multicast trees in the core. 254 3.2.1. Many to one mapping 256 Using this mapping method, many groups in client networks will be 257 mapped into the same group in the core. Under some conditions, all 258 groups in client networks will be mapped into the same group, as it's 259 the simplest mapping method. 261 Many to one mapping has been well realized by mVPN[I-D.ietf-l3vpn- 262 2547bis-mcast], where traffic from multiple MVPNs will be aggregated 263 into a single multicast distribution tree. Thus many groups are 264 mapped into the same group in the core. 266 3.2.2. One to one mapping 268 Using many to one mapping, the management could be easier, but 269 members of different groups may be scattered in different client 270 networks and when they are mapped into the same group, some AFBRs may 271 receive unnecessary packets of some group when it doesn't belong to 272 the group. 274 For examle, group A and B which belong to client networks are mapped 275 into the same group C in the core. Assume that in a client network, 276 there are members of A while no member of B. But group C must 277 transfer the traffic whenever it belongs to group A or B of the 278 client networks. So the AFBR of this client network may receive 279 unnecessary packets(like packets of group B) if nothing is done in 280 the upstream. 282 There are several ways to realize one to one mapping. Here we will 283 introduce two of them. One is based on RPF-Vector and the other is 284 through inter-AFBR signaling. 286 4. RPF-Vector-Based Address Translation 288 The main idea of address translation is to translate E-IP addresses 289 of the Join/Prune messages to I-IP addresses. Therefore, E-IP 290 multicast messages can be translated to corresponding I-IP multicast 291 messages at ingress AFBRs, and then back to E-IP multicast messages 292 after arriving at egress AFBRs. The translation procedure should 293 follow some predefined rules, so that ingress AFBR and egress AFBR 294 can finish the translation and retranslation procedure correctly 295 without negotiation. For example, if E-IP is IPv4 and I-IP is IPv6, 296 the ingress AFBR uses a predefined IPv6 prefix for any case to 297 translate an IPv4 address to an IPv6 address, and the predefined IPv6 298 prefix combined with the IPv4 address makes up the new IPv6 address 299 in the IPv6 transit core. Then the egress AFBR can easily 300 retranslate it to the original IPv4 address by simply removing the 301 predefined IPv6 prefix. 303 Since the source and group addresses in the I-IP Join/Prune message 304 are translated from E-IP by adding a predefined I-IP prefix, they can 305 not be recognized by P routers to reach the corresponding egress 306 AFBRs. We use an RPF Vector in the Join/Prune message to route them 307 in the I-IP transit core. The RPF Vector is an optional extended PIM 308 attribution, which designates the routers which router the Join/Prune 309 message must pass by. i.e., AFBR A fills the I-IP address of AFBR B 310 in the RPF Vector of Join/Prune message to help it find a route to 311 AFBR B in the transit core. Then the Join/Prune message builds a 312 multicast tree in the transit core and finally arrives at AFBR B. 314 When some multicast data packet arrives at AFBR B, it will be 315 translated to an I-IP packet, and delivered along the I-IP core Tree 316 constructed by the former Join/Prune message in core and arrive at 317 AFBR A. Then AFBR A will translate it back and forward it to the E-IP 318 client network. 320 The address translation scheme is only available when E-IP is IPv4 321 and I-IP is IPv6. As IPv6 addresses are 128bit long, it is possible 322 to translate an IPv4 address to an IPv6 address by making IPv4 323 address part of the IPv6 address algorithmically. AFBRs can 324 translate the IPv4 S and G into corresponding IPv4-mapped IPv6 325 addresses [RFC4291], and then be translated back. The precise 326 circumstances under which these translations are done would be a 327 matter of policy. But if E-IP is IPv6 and I-IP is IPv4, the 328 translation can't be achieved easily, more research is needed to fit 329 this condition. Also, an additional RPF Vector must be applied to 330 help to construct the I-IP core Tree in the transit core. To sum up, 331 the address translation method is virtually the same multicast 332 message taking on different appearances in different IP address 333 family networks and the I-IP core Tree is part of the E-IP client 334 tree while presenting an I-IP feature. 336 5. Inter-AFBR(Address Family Border Router) signaling 338 It's called inter-AFBR signaling because unlike the RPF-Vector-Based 339 address translation, here AFBRs has to send signals to the other 340 AFBRs to construct the whole multicast tree. 342 5.1. Address Mapping 344 There are two kinds of address associated with multicast: source 345 address and group address. Group address will be discussed in this 346 section and source address later when associated with SPT and shared 347 tree scheme. 349 For softwire mesh multicast, there are two different scenarios when 350 talking about address translation, which is also called address 351 mapping here: IPv4-IPv6-IPv4 scenario and IPv6-IPv4-IPv6 scenario. 352 The previous one is easier to implement one to one mapping as the 353 IPv6 address is longer than the IPv4 one. We can simply add a prefix 354 before the IPv4 address when mapping an E-IP address to an I-IP 355 address, just like figure 2 shows. 357 0 8 16 96 127 358 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 359 |FF XX| ISP Assigned Prefix | v4 address| 360 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 362 Figure 2: Mapping from IPv4 to IPv6 address 364 The first two octets must be in accordance with the IPv6 multicast 365 address format defined in section 2.7 of [RFC2373]. The following 10 366 octets are assigned by administrators of ISP and the last 4 octets 367 are the IPv4 address. 369 But for the IPv6-IPv4-IPv6 scenario, due to the shorter length of 370 IPv4 address, it's not that simple to realize one to one mapping. 372 A feasible solution is partial mapping, which maps only part of IPv6 373 addresses into IPv4 addresses, like the IPv6 address with a fixed 374 prefix. We won't talk about it here as it prohibits the use of some 375 IPv6 group addresses. 377 We will talk about another solution: an IPv6 address will be hashed 378 into another IPv4 address using some hash function. In this manner, 379 two or more IPv6 addresses may be mapped into the same IPv4 address. 380 But at the same time, only part of the IPv6 addresses are in use, so 381 with a proper hash function, we can achieve one to one mapping 382 approximately. For example, we could use the last three octets of 383 IPv6 address to fill in the last three octets of IPv4 address, while 384 the first octet is determined by the administrator. 386 5.2. Data Plane 388 Assume that group source S wants to send packets to a group member in 389 different client network with S. S will send the packets along the 390 multicast tree of client network(where S locates) to the upstream 391 AFBR first. Then AFBR will encapsulate the packets with a header 392 whose destination is an I-IP multicast address. Thus the packets 393 will flow along the multicast tree of transit core to the downstream 394 AFBR. 396 Having received the packets, the downstream AFBR will first 397 decapsulate the packets, and then judge whether the packets are 398 necessary, which means whether it has group members behind it. If 399 not, it will just discard them, else it will send them along the 400 multicast tree of client network(where D locates) to the receivers. 401 Finally, D will receiver these packets. 403 5.3. Control Plane 405 There are many control messages in PIM protocol. How to deal with 406 them when they are received by routers, especially AFBR routers is 407 really an important problem. 409 When AFBR receives multicast control messages whose destination is in 410 another client network, it has to maintain the multicast tree in the 411 core, in the mean while, it's responsible to send some of them, like 412 Join or Prune messages, to the client network on the other side of 413 the core. Usually, the messages are tunneled to the other side of 414 the core. The tunneling technology can be GRE, IP-in-IP, MPLS etc. 415 Here we use IP-in-IP, other tunneling method is alike. 417 The upstream AFBR treats the downstream AFBRs as the neighbors on the 418 multicast tree when they send tunneled control messages to it. But 419 unlike native PIM protocol, different neighbors are distinguished by 420 their IP addresses but not by interfaces, because tunneled control 421 messages sent by different downstream AFBRs can arrive at the 422 upstream AFBR through the same interface. Usually, for every group, 423 AFBR will keep a table recording which downstream AFBRs have joined 424 it. 426 The key part is how to maintain the multicast tree in the core. 427 Unlike RPF-Vector-Based scheme, it's not just a process of 428 translation, it's more complicate than that. When AFBR receive E-IP 429 Join messages, the AFBR will judge whether it has already joined the 430 multicast group in the core, if not, then it will send I-IP Join 431 messages upstream. Note that the multicast group is not the group of 432 the Join message AFBR has received, it's the group which is mapped 433 from the group of the Join message. When AFBR receive E-IP Prune 434 messages, it will judge whether there are any group members in the 435 client network, if not, it will send I-IP Prune messages upstream. 437 ._._._._. 438 | | -------- 439 | E-IP |--|Source S| 440 | network | -------- 441 ._._._._. 442 | 443 upstream AFBR 444 Dual-Stack 445 | 446 __ __________+_________ _ 447 / : : : : \ 448 | : : : : | 449 | : I-IP transit core : | 450 | : : : : | 451 | : : : : | 452 \_._._._._._._._._._._._._./ 453 + 454 downstream AFBR 455 Dual-Stack 456 | 457 ._._._._ 458 ---------- | | ---------- 459 |Receiver a|-- | E-IP | --|Receiver b| 460 ---------- |network | ---------- 461 ._._._._ 463 Figure 3: Maintain the multicast tree in the core 465 For example as in figure 3, receiver a belongs to group A while b 466 belongs to group B, A and B will be mapped into group C in the core. 467 Firstly, a sends a Join(S,A) message to source S(here we only 468 consider about PIM-SSM for the sake of simplicity), when the message 469 arrives at the downstream AFBR, the AFBR find that it hasn't yet 470 joined group C, so it will send a Join(S',C)(S' will be defined in 471 the next sections) to the core and send an encapsulated packet 472 E(Join(S,A)) to the upstream AFBR. 474 But when b sends a Join(S,B) message to S, when the AFBR receives it, 475 it finds that it has joined group C. Thus it just sends an 476 encapsulated packet E(Join(S,B)) to the upstream AFBR. Then b wants 477 to quit group B, it will send a Prune(S,G), when downstream AFBR 478 receives it, it finds there are still members of group C, then it 479 just sends an encapsulated packet E(Prune(S,B)) to the upstream AFBR. 480 After that, a also wants to quit, it sends a Prune(S,A) message, when 481 downstream receives it, it finds no member of C exists, so it sends a 482 Prune(S',C) message to the core while sending an encapsulated packet 483 E(Prune(S,A)) to the upstream AFBR. 485 In order to maintain the multicast tree in the core, besides sending 486 messages to the core and upstream AFBRs invoked by messages received 487 from client network, AFBR also has to send some messages 488 periodically, like hello and Join messages, etc. 490 5.4. SPT Scheme 492 SPT means we will construct a source specific tree in the core where 493 the source will be a AFBR. We use PIM-SSM as the technology to 494 construct the source specific tree in the core. The data traffic 495 will flow along the multicast tree of the client network to the 496 upstream AFBR, then the upstream AFBR will act as the source of the 497 SPT in the core. In this way, data will flow to the other AFBR where 498 receivers locate behind, finnaly data traffic comes back to the 499 multicast tree of another client network and arrives at the 500 receivers. 502 So E-IP Join/Prune(S,G) messages will be mapped into I-IP Join/ 503 Prune(S',G') messages, where S' is the address of the upstream AFBR 504 and G' is the mapped group address which we talked about previously. 505 In this way, all the routers in the core recognize this I-IP address 506 and the I-IP control messages will be sent to the right AFBR. And 507 E-IP Join/Prune(*,G) messages will also be mapped into I-IP Join/ 508 Prune(S',G') messages where S' is the address of AFBR where RP 509 locates behind. E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be 510 tunneled to the upstream AFBR while Join/Prune(S',G') will be sent to 511 the core. 513 But for dealing with Join/Prune(S,G,rpt), the downstream AFBR just 514 have to tunnel the E(Join/Prune(S,G,rpt)) to the upstream AFBR, there 515 won't be any Join/Prune(S',G',rpt) sent to the core as we use PIM-SSM 516 in the core. 518 If there are many sources of one group in the same client network. 519 Then they will share the same multicast tree in the core. This will 520 cause some data redundancy, but it's less serious than many to one 521 mapping. 523 5.5. Shared Tree Scheme 525 Compared with SPT scheme, shared tree scheme constructs a shared tree 526 in the core. The data traffic will flow to the upstream AFBR, then 527 the upstream AFBR will send the data traffic the the RP of the shared 528 tree in the core. The RP in the core will distribute the traffic to 529 the necessary AFBRs, throught which the traffic will arrive at the 530 receivers. 532 Both E-IP Join/Prune(S,G) and Join/Prune(*,G) will be mapped into 533 Join/Prune(*,G') where G' is a mapped group address. The Join/ 534 Prune(*,G') messages will be sent to the core and the core routers 535 will pass them to RP of group G' in the core. The core routers need 536 to know the information(the address) of the RP in the core. The RP 537 in the core is discovered according to [RFC4601]. 539 At the same time, E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be 540 tunneled to the upstream AFBR. Thus data traffic will flow to the 541 upstream AFBR. When AFBR receives data of group G, it will take 542 those data, unicast-encapsulates them, and sends them directly to the 543 RP of G' in the core. The RP receives these encapsulated data 544 packets, decapsulates them, and forwards them onto the shared tree. 545 This is just like the register process of [RFC4601]. 547 Also like [RFC4601], RP in the core will switch to native forwarding 548 as register-encapsulation of data packets is inefficient. RP will 549 send an Join(S',G') towards S' and in this way packets from S' starts 550 to arrive natively at the RP. Then RP will send register-stop 551 message to S' when it receives two copies of each of data packets. 553 Like the SPT scheme, when dealing with Join/Prune(S,G,rpt), the 554 downstream AFBR just have to tunnel E(Join/Prune(S,G,rpt)) to the 555 upstream AFBR but not send Join/Prune(S',G',rpt) to the core, as the 556 routers in the core can't distinguish between the packets from RP(of 557 client network) with the packets from source. 559 For each group, there is only one shared tree in the core which is 560 less than SPT scheme. If there are many sources in the group, their 561 packets will follow the same multicast tree when they flow through 562 the core. That means it will cause more serious data redundancy than 563 SPT scheme. But it's still less serious than many to one mapping. 565 For both of SPT Scheme and Shared Tree Scheme, we don't have to worry 566 about assert messages, because it can be done with locally. At the 567 AFBRs, the timers that associated with the other AFBRs must be 568 prolonged, as the control messages or the data may have to travel 569 through the core network for quite a long time. 571 6. Summary 573 There are a lot of schemes talked above. To some schemes, several 574 mapping methods exist. Which one to choose depends on the actual 575 situation. 577 When the core network only supports unicast, we have to decided 578 whether to transfer the replication to all the other AFBRs or the 579 necessary AFBRs. The former one is simple but may cause higher 580 redundancy while more AFBRs will receive data they haven't asked for. 582 When the core network supports multicast, we have many choices. Many 583 to one mapping has been realized by mVPN, but it may cause serious 584 data redundancy. RPF-Vector-Based scheme provides a translation 585 scheme and can achieve one-to-one mapping between client networks and 586 the core network. But it only adapts to IPv4-IPv6-IPv4 scenario and 587 has to make use of RPF Vector which is an optional extended 588 attribution of PIM, which many networks can't satisfy. Inter-AFBR 589 signaling is another choice to realize one to one mapping which 590 adapts to both IPv4-IPv6-IPv4 and IPv6-IPv4-IPv6 scenarios. Both SPT 591 and shared multicast tree can be used in the core to transfer 592 multicast traffic, and usually, shared tree scheme creates less trees 593 in the core than SPT scheme. 595 Whether more trees or less trees exist in the core is better, it also 596 depends. More trees can reduce data redundancy while increasing the 597 overhead for managing the trees, that is, there will be more states 598 in the router and more resources will be wasted on processing 599 multicast control message. 601 Thus choosing different schemes always means choosing data redundancy 602 or overhead. If you consider that data redundancy is more important, 603 you can choose a scheme that creates more trees, and vice versa. 605 7. Security Considerations 607 The AFBR routers could maintain secure communications through the use 608 of Security Architecture for the Internet Protocol as described 609 in[RFC4301]. But when adopting some schemes whose data redundancy is 610 serious, some attacker may use it as a tool for DDoS attack. 612 8. IANA Considerations 614 For Inter-AFBR signaling, address mapping is applied, and it should 615 follow some predefined rule, especially the format of IPv6 prefix for 616 address mapping should be predefined, so that ingress AFBR and egress 617 AFBR can finish the mapping procedure correctly. The format of IPv6 618 prefix for translation can be unified within only the transit core, 619 or within global area. In the later condition, the format should be 620 assigned by IANA. 622 9. References 624 9.1. Normative References 626 [1] Kent, S. and K. Seo, "Security Architecture for the Internet 627 Protocol", RFC 4301, December 2005. 629 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 630 Architecture", RFC 2373, July 1998. 632 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 633 Architecture", RFC 4291, February 2006. 635 [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 636 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 637 Specification (Revised)", RFC 4601, August 2006. 639 [5] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem 640 Statement", RFC 4925, July 2007. 642 [6] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 643 Framework", RFC 5565, June 2009. 645 9.2. Informative References 647 [7] Wijnands, I., Boers, A., and E. Rosen, "The RPF Vector TLV", 648 draft-ietf-pim-rpf-vector-08 (work in progress), January 2009. 650 [8] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, 651 E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP 652 VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in progress), 653 January 2010. 655 [9] Metz, C., Cui, Y., and M. Xu, "Softwires Mesh Multicast Problem 656 Statement", draft-metz-softwires-multicast-problem-statement-00 657 (work in progress), February 2008. 659 Authors' Addresses 661 Mingwei Xu 662 Tsinghua University 663 Department of Computer Science, Tsinghua University 664 Beijing 100084 665 P.R.China 667 Phone: +86-10-6278-5822 668 Email: xmw@csnet1.cs.tsinghua.edu.cn 670 Yong Cui 671 Tsinghua University 672 Department of Computer Science, Tsinghua University 673 Beijing 100084 674 P.R.China 676 Phone: +86-10-6278-5822 677 Email: cuiyong@tsinghua.edu.cn 679 Chris Metz 680 Cisco Systems 681 170 West Tasman Drive 682 San Jose, California 95134-1706 683 USA 685 Phone: +1-408-525-3275 686 Email: chmetz@cisco.com