idnits 2.17.1 draft-ietf-softwire-mesh-multicast-17.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 319 has weird spacing: '... |group addre...' -- The document date (August 3, 2017) is 2459 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) == Unused Reference: 'RFC4301' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC7371' is defined on line 739, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG M. Xu 3 Internet-Draft Y. Cui 4 Intended status: Standards Track J. Wu 5 Expires: February 4, 2018 S. Yang 6 Tsinghua University 7 C. Metz 8 G. Shepherd 9 Cisco Systems 10 August 3, 2017 12 Softwire Mesh Multicast 13 draft-ietf-softwire-mesh-multicast-17 15 Abstract 17 The Internet needs to support IPv4 and IPv6 packets. Both address 18 families and their related protocol suites support multicast of the 19 single-source and any-source varieties. During IPv6 transition, 20 there will be scenarios where a backbone network running one IP 21 address family internally (referred to as internal IP or I-IP), while 22 the attached client networks running another IP address family 23 (referred to as external IP or E-IP). The I-IP backbone should offer 24 both unicast and multicast transit services to the client E-IP 25 networks. 27 Softwire Mesh is a solution providing E-IP unicast and multicast 28 support across an I-IP backbone. This document describes the 29 mechanism for supporting Internet-style multicast across a set of 30 E-IP and I-IP networks supporting softwire mesh. We focus on IPv4- 31 over-IPv6 scenario in this document, due to lack of real-world use 32 cases for IPv6-over-IPv4 scenario. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 4, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 6 71 4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . 7 72 4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . 8 73 4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 8 74 4.3. Source Address Mapping . . . . . . . . . . . . . . . . . 9 75 4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 10 76 5. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 11 77 5.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . 11 78 5.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . 11 79 5.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . 11 80 5.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . 11 81 5.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . 12 82 5.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . 14 83 5.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 14 84 5.8. Other PIM States Maintenance . . . . . . . . . . . . . . 14 85 6. Data Plane Functions of the AFBR . . . . . . . . . . . . . . 14 86 6.1. Process and Forward Multicast Data . . . . . . . . . . . 14 87 6.2. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 89 7. Packet Format and Translation . . . . . . . . . . . . . . . . 15 90 8. Softwire Mesh Multicast Encapsulation . . . . . . . . . . . . 16 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 11.2. Informative References . . . . . . . . . . . . . . . . . 18 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 The Internet needs to support IPv4 and IPv6 packets. Both address 103 families and their related protocol suites support multicast of the 104 single-source and any-source varieties. During IPv6 transition, 105 there will be scenarios where a backbone network running one IP 106 address family internally (referred to as internal IP or I-IP) will 107 provide transit services to attached client networks running another 108 IP address family (referred to as external IP or E-IP). 110 One solution is to leverage the multicast functions inherent in the 111 I-IP backbone, to efficiently forward client E-IP multicast packets 112 inside an I-IP core tree, which is rooted at one or more ingress 113 Address Family Border Routers (AFBR) and branches out to one or more 114 egress Address Family Border Routers (AFBR). 116 [RFC4925] outlines the requirements for the softwires mesh scenario 117 and includes support for multicast traffic. It is likely that client 118 E-IP multicast sources and receivers will reside in different client 119 E-IP networks connected to an I-IP backbone network. This requires 120 the client E-IP source-rooted or shared tree to traverse the I-IP 121 backbone network. 123 One method of accomplishing this is to re-use the multicast VPN 124 approach outlined in [RFC6513]. MVPN-like schemes can support the 125 softwire mesh scenario and achieve a "many-to-one" mapping between 126 the E-IP client multicast trees and the transit core multicast trees. 127 The advantage of this approach is that the number of trees in the 128 I-IP backbone network scales less than linearly with the number of 129 E-IP client trees. Corporate enterprise networks and by extension 130 multicast VPNs have been known to run applications that create too 131 many (S,G) states. Aggregation at the edge contains the (S,G) states 132 for customer's VPNs and these need to be maintained by the network 133 operator. The disadvantage of this approach is the possibility of 134 inefficient bandwidth and resource utilization when multicast packets 135 are delivered to a receiving AFBR with no attached E-IP receivers. 137 Internet-style multicast is somewhat different in that the trees are 138 source-rooted and relatively sparse. The need for multicast 139 aggregation at the edge (where many customer multicast trees are 140 mapped into one or more backbone multicast trees) does not exist and 141 to date has not been identified. Thus the need for a basic or closer 142 alignment with E-IP and I-IP multicast procedures emerges. 144 [RFC5565] describes the "Softwire Mesh Framework". This document 145 provides a more detailed description of how one-to-one mapping 146 schemes ([RFC5565], Section 11.1) for IPv4 over IPv6 can be achieved. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 2. Terminology 156 Figure 1 shows an example of how a softwire mesh network can support 157 multicast traffic. A multicast source S is located in one E-IP 158 client network, while candidate E-IP group receivers are located in 159 the same or different E-IP client networks that all share a common 160 I-IP transit network. When E-IP sources and receivers are not local 161 to each other, they can only communicate with each other through the 162 I-IP core. There may be several E-IP sources for a single multicast 163 group residing in different client E-IP networks. In the case of 164 shared trees, the E-IP sources, receivers and RPs might be located in 165 different client E-IP networks. In the simplest case, a single 166 operator manages the resources of the I-IP core, although the inter- 167 operator case is also possible and so not precluded. 169 ._._._._. ._._._._. 170 | | | | -------- 171 | E-IP | | E-IP |--|Source S| 172 | network | | network | -------- 173 ._._._._. ._._._._. 174 | | 175 AFBR upstream AFBR 176 | | 177 __+____________________+__ 178 / : : : : \ 179 | : : : : | E-IP Multicast 180 | : I-IP transit core : | packets are forwarded 181 | : : : : | across the I-IP 182 | : : : : | transit core 183 \_._._._._._._._._._._._._./ 184 + + 185 downstream AFBR downstream AFBR 186 | | 187 ._._._._ ._._._._ 188 -------- | | | | -------- 189 |Receiver|-- | E-IP | | E-IP |--|Receiver| 190 -------- |network | |network | -------- 191 ._._._._ ._._._._ 193 Figure 1: Softwire Mesh Multicast Framework 195 Terminology used in this document: 197 o Address Family Border Router (AFBR) - A router interconnecting two 198 or more networks using different IP address families. In the context 199 of softwire mesh multicast, the AFBR runs E-IP and I-IP control 200 planes to maintain E-IP and I-IP multicast states respectively and 201 performs the appropriate encapsulation/decapsulation of client E-IP 202 multicast packets for transport across the I-IP core. An AFBR will 203 act as a source and/or receiver in an I-IP multicast tree. 205 o Upstream AFBR: An AFBR router that is located on the upper reaches 206 of a multicast data flow. 208 o Downstream AFBR: An AFBR router that is located on the lower 209 reaches of a multicast data flow. 211 o I-IP (Internal IP): This refers to IP address family (i.e., either 212 IPv4 or IPv6) that is supported by the core (or backbone) network. 214 o E-IP (External IP): This refers to the IP address family (i.e. 215 either IPv4 or IPv6) that is supported by the client network(s) 216 attached to the I-IP transit core. 218 o I-IP core tree: A distribution tree rooted at one or more AFBR 219 source nodes and branched out to one or more AFBR leaf nodes. An 220 I-IP core tree is built using standard IP or MPLS multicast signaling 221 protocols operating exclusively inside the I-IP core network. An 222 I-IP core tree is used to forward E-IP multicast packets belonging to 223 E-IP trees across the I-IP core. Another name for an I-IP core tree 224 is multicast or multipoint softwire. 226 o E-IP client tree: A distribution tree rooted at one or more hosts 227 or routers located inside a client E-IP network and branched out to 228 one or more leaf nodes located in the same or different client E-IP 229 networks. 231 o uPrefix46: The /96 unicast IPv6 prefix for constructing an 232 IPv4-embedded IPv6 source address in IPv4-over-IPv6 scenario. 234 o mPrefix46: The /96 multicast IPv6 prefix for constructing an 235 IPv4-embedded IPv6 multicast address in IPv4-over-IPv6 scenario. 237 o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send 238 PIM messages to the upstream AFBR. 240 3. Scenarios of Interest 242 This document focus on IPv4-over-IPv6 scenario, the following diagram 243 shows the scenario. 245 ._._._._. ._._._._. 246 | IPv4 | | IPv4 | -------- 247 | Client | | Client |--|Source S| 248 | network | | network | -------- 249 ._._._._. ._._._._. 250 | | 251 AFBR upstream AFBR 252 | | 253 __+____________________+__ 254 / : : : : \ 255 | : : : : | 256 | : IPv6 transit core : | 257 | : : : : | 258 | : : : : | 259 \_._._._._._._._._._._._._./ 260 + + 261 downstream AFBR downstream AFBR 262 | | 263 ._._._._ ._._._._ 264 -------- | IPv4 | | IPv4 | -------- 265 |Receiver|-- | Client | | Client |--|Receiver| 266 -------- | network| | network| -------- 267 ._._._._ ._._._._ 269 Figure 2: IPv4-over-IPv6 Scenario 271 In Figure 2, the E-IP client networks run IPv4 and the I-IP core runs 272 IPv6. 274 Because of the much larger IPv6 group address space, the client 275 E-IPv4 tree can be mapped to a specific I-IPv6 core tree. This 276 simplifies operations on the AFBR because it becomes possible to 277 algorithmically map an IPv4 group/source address to an IPv6 group/ 278 source address and vice-versa. 280 The IPv4-over-IPv6 scenario is an emerging requirement as network 281 operators build out native IPv6 backbone networks. These networks 282 support native IPv6 services and applications but in many cases, 283 support for legacy IPv4 unicast and multicast services will also need 284 to be accomodated. 286 4. IPv4-over-IPv6 Mechanism 287 4.1. Mechanism Overview 289 Routers in the client E-IPv4 networks have routes to all other client 290 E-IPv4 networks. Through PIM messages, E-IPv4 hosts and routers have 291 discovered or learnt of (S,G) or (*,G) IPv4 addresses. Any I-IPv6 292 multicast state instantiated in the core is referred to as (S',G') or 293 (*,G') and is certainly separated from E-IPv4 multicast state. 295 Suppose a downstream AFBR receives an E-IPv4 PIM Join/Prune message 296 from the E-IPv4 network for either an (S,G) tree or a (*,G) tree. 297 The AFBR can translate the E-IPv4 PIM message into an I-IPv6 PIM 298 message with the latter being directed towards the I-IP IPv6 address 299 of the upstream AFBR. When the I-IPv6 PIM message arrives at the 300 upstream AFBR, it is translated back into an E-IPv4 PIM message. The 301 result of these actions is the construction of E-IPv4 trees and a 302 corresponding I-IP tree in the I-IP network. An example of the 303 packet format and traslation is provided in Section 8. 305 In this case, it is incumbent upon the AFBR routers to perform PIM 306 message conversions in the control plane and IP group address 307 conversions or mappings in the data plane. The AFBRs perform an 308 algorithmic, one-to-one mapping of IPv4-to-IPv6. 310 4.2. Group Address Mapping 312 For the IPv4-over-IPv6 scenario, a simple algorithmic mapping between 313 IPv4 multicast group addresses and IPv6 group addresses is performed. 314 Figure 4 shows the reminder of the format: 316 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 317 | 0-------------32--40--48--56--64--72--80--88--96-----------127| 318 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 319 | mPrefix46 |group address | 320 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 322 Figure 4: IPv4-Embedded IPv6 Multicast Address Format 324 An IPv6 multicast prefix (mPrefix46) is assigned to each AFBR. AFBRs 325 will prepend the prefix to an IPv4 multicast group address when 326 translating it to an IPv6 multicast group address. 328 The mPrefix46 for SSM mode is also defined in Section 2 of [RFC8114]. 330 With this scheme, each IPv4 multicast address can be mapped into an 331 IPv6 multicast address (with the assigned prefix), and each IPv6 332 multicast address with the assigned prefix can be mapped into an IPv4 333 multicast address. The group address translation algorithm can be 334 reffered in Section 5.2 of [RFC8114]. 336 4.3. Source Address Mapping 338 There are two kinds of multicast: ASM and SSM. Considering that the 339 I-IP network and E-IP network may support different kinds of 340 multicast, the source address translation rules needed to support all 341 possible scenarios may become very complex. But since SSM can be 342 implemented with a strict subset of the PIM-SM protocol mechanisms 343 [RFC7761], we can treat the I-IP core as SSM-only to make it as 344 simple as possible. There then remain only two scenarios to be 345 discussed in detail: 347 o E-IP network supports SSM 349 One possible way to make sure that the translated I-IPv6 PIM 350 message reaches upstream AFBR is to set S' to a virtual IPv6 351 address that leads to the upstream AFBR. Figure 5 is the 352 recommended address format based on [RFC6052]: 354 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 355 | 0-------------32--40--48--56--64--72--80--88--96-----------127| 356 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 357 | prefix |v4(32) | u | suffix |source address | 358 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 359 |<------------------uPrefix46------------------>| 361 Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format 363 In this address format, 365 * The "prefix" field contains a "Well-Known" prefix or an ISP- 366 defined prefix. An existing "Well-Known" prefix is 64:ff9b, 367 which is defined in [RFC6052]; 369 * The "v4" field is the IP address of one of upstream AFBR's 370 E-IPv4 interfaces; 372 * The "u" field is defined in [RFC4291], and MUST be set to zero; 374 * The "suffix" field is reserved for future extensions and SHOULD 375 be set to zero; 377 * The "source address" field stores the original source address. 379 We call the overall /96 prefix ("prefix" field and "v4" field and 380 "u" field and "suffix" field altogether) "uPrefix46". 382 o E-IP network supports ASM 384 The (S,G) source list entry and the (*,G) source list entry only 385 differ in that the latter has both the WC and RPT bits of the 386 Encoded-Source-Address set, while the former is all cleared (See 387 Section 4.9.5.1 of [RFC7761]). So we can translate source list 388 entries in (*,G) messages into source list entries in (S'G') 389 messages by applying the format specified in Figure 5 and clearing 390 both the WC and RPT bits at downstream AFBRs, and vice-versa for 391 the reverse translation at upstream AFBRs. 393 4.4. Routing Mechanism 395 In the mesh multicast scenario, routing information is REQUIRED to be 396 distributed among AFBRs to make sure that the PIM messages that a 397 downstream AFBR propagates reach the right upstream AFBR. 399 Every AFBR MUST know the /32 prefix in "IPv4-Embedded IPv6 Virtual 400 Source Address Format". To achieve this, every AFBR should announce 401 one of its E-IPv4 interfaces in the "v4" field, and the corresponding 402 uPrefix46. The announcement SHOULD be sent to the other AFBRs 403 through MBGP. Since every IP address of upstream AFBR's E-IPv4 404 interface is different from each other, every uPrefix46 that AFBR 405 announces MUST be different, and uniquely identifies each AFBR. 406 "uPrefix46" is an IPv6 prefix, and the distribution mechanism is the 407 same as the traditional mesh unicast scenario. But "v4" field is an 408 E-IPv4 address, and BGP messages are NOT tunneled through softwires 409 or any other mechanism specified in [RFC5565], AFBRs MUST be able to 410 transport and encode/decode BGP messages that are carried over 411 I-IPv6, whose NLRI and NH are of E-IPv4 address family. 413 In this way, when a downstream AFBR receives an E-IPv4 PIM (S,G) 414 message, it can translate this message into (S',G') by looking up the 415 IP address of the corresponding AFBR's E-IPv4 interface. Since the 416 uPrefix46 of S' is unique, and is known to every router in the I-IPv6 417 network, the translated message will be forwarded to the 418 corresponding upstream AFBR, and the upstream AFBR can translate the 419 message back to (S,G). When a downstream AFBR receives an E-IPv4 PIM 420 (*,G) message, S' can be generated according to the format specified 421 in Figure 4, with "source address" field set to *(the IPv4 address of 422 RP). The translated message will be forwarded to the corresponding 423 upstream AFBR. Since every PIM router within a PIM domain MUST be 424 able to map a particular multicast group address to the same RP (see 425 Section 4.7 of [RFC7761]), when the upstream AFBR checks the "source 426 address" field of the message, it finds the IPv4 address of the RP, 427 and assertains that this is originally a (*,G) message. This is then 428 translated back to the (*,G) message and processed. 430 5. Control Plane Functions of AFBR 432 AFBRs are responsible for the following functions: 434 5.1. E-IP (*,G) State Maintenance 436 When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP 437 upstream router, the AFBR MUST translate Join/Prune(*,G) messages 438 into Join/Prune(S',G') messages following the rules specified above, 439 then send the latter. 441 5.2. E-IP (S,G) State Maintenance 443 When an AFBR wishes to propagate a Join/Prune(S,G) message to an I-IP 444 upstream router, the AFBR MUST translate Join/Prune(S,G) messages 445 into Join/Prune(S',G') messages following the rules specified above, 446 then send the latter. 448 5.3. I-IP (S',G') State Maintenance 450 It is possible that the I-IP transit core runs another non-transit 451 I-IP PIM-SSM instance. Since the translated source address starts 452 with the unique "Well-Known" prefix or the ISP-defined prefix that 453 SHOULD NOT be used by other service provider, mesh multicast will not 454 influence non-transit PIM-SSM multicast at all. When an AFBR 455 receives an I-IP (S',G') message, it MUST check S'. If S' starts 456 with the unique prefix, then the message is actually a translated 457 E-IP (S,G) or (*,G) message, and the AFBR MUST translate this message 458 back to E-IP PIM message and process it. 460 5.4. E-IP (S,G,rpt) State Maintenance 462 When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an 463 I-IP upstream router, the AFBR MUST operate as specified in 464 Section 6.5 and Section 6.6. 466 5.5. Inter-AFBR Signaling 468 Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT 469 of (S,G), and decide to perform an SPT switchover. According to 470 [RFC7761], it SHOULD propagate a Prune(S,G,rpt) message along with 471 the periodical Join(*,G) message upstream towards RP. However, 472 routers in the I-IP transit core do not process (S,G,rpt) messages 473 since the I-IP transit core is treated as SSM-only. As a result, the 474 downstream AFBR is unable to prune S from this RPT, so it will 475 receive two copies of the same data of (S,G). In order to solve this 476 problem, we introduce a new mechanism for downstream AFBRs to inform 477 upstream AFBRs of pruning any given S from an RPT. 479 When a downstream AFBR wishes to propagate a (S,G,rpt) message 480 upstream, it SHOULD encapsulate the (S,G,rpt) message, then send the 481 encapsulated unicast message to the corresponding upstream AFBR, 482 which we call "RP'". 484 When RP' receives this encapsulated message, it SHOULD decapsulate 485 the message as in the unicast scenario, and retrieve the original 486 (S,G,rpt) message. The incoming interface of this message may be 487 different to the outgoing interface which propagates multicast data 488 to the corresponding downstream AFBR, and there may be other 489 downstream AFBRs that need to receive multicast data of (S,G) from 490 this incoming interface, so RP' SHOULD NOT simply process this 491 message as specified in [RFC7761] on the incoming interface. 493 To solve this problem as simply as possible, we introduce an 494 "interface agent" to process all the encapsulated (S,G,rpt) messages 495 the upstream AFBR receives, and RP' SHOULD prune S from the RPT of 496 group G when no downstream AFBR is subscribed to receive multicast 497 data of (S,G) along the RPT. In this way, we ensure that downstream 498 AFBRs will not miss any multicast data that they need, at the cost of 499 duplicated multicast data of (S,G) along the RPT received by SPT- 500 switched-over downstream AFBRs, if at least one downstream AFBR 501 exists that has not yet sent Prune(S,G,rpt) messages to the upstream 502 AFBR. The mechanism used to achieve this is left to the 503 implementation, the following diagram provides a possible solution 504 that "interface agent" MAY be implemented: 506 +----------------------------------------+ 507 | | 508 | +-----------+----------+ | 509 | | PIM-SM | UDP | | 510 | +-----------+----------+ | 511 | ^ | | 512 | | | | 513 | | v | 514 | +----------------------+ | 515 | | I/F Agent | | 516 | +----------------------+ | 517 | PIM ^ | multicast | 518 | messages | | data | 519 | | +-------------+---+ | 520 | +--+--|-----------+ | | 521 | | v | v | 522 | +--------- + +----------+ | 523 | | I-IP I/F | | I-IP I/F | | 524 | +----------+ +----------+ | 525 | ^ | ^ | | 526 | | | | | | 527 +--------|-----|----------|-----|--------+ 528 | v | v 530 Figure 7: Interface Agent Implementation Example 532 Figure 7 shows an example of interface agent implementation using UDP 533 encapsulation. The interface agent has two responsibilities: In the 534 control plane, it SHOULD work as a real interface that has joined 535 (*,G), representing of all the I-IP interfaces which are outgoing 536 interfaces of the (*,G) state machine, and process the (S,G,rpt) 537 messages received from all the I-IP interfaces. 539 The interface agent maintains downstream (S,G,rpt) state machines of 540 every downstream AFBR, and submits Prune (S,G,rpt) messages to the 541 PIM-SM module only when every (S,G,rpt) state machine is at Prune(P) 542 or PruneTmp(P') state, which means that no downstream AFBR is 543 subscribed to receive multicast data of (S,G) along the RPT of G. 544 Once a (S,G,rpt) state machine changes to NoInfo(NI) state, which 545 means that the corresponding downstream AFBR has switched to receive 546 multicast data of (S,G) along the RPT again, the interface agent 547 SHOULD send a Join (S,G,rpt) to the PIM-SM module immediately. 549 In the data plane, upon receiving a multicast data packet, the 550 interface agent SHOULD encapsulate it at first, then propagate the 551 encapsulated packet from every I-IP interface. 553 NOTICE: It is possible that an E-IP neighbor of RP' that has joined 554 the RPT of G, so the per-interface state machine for receiving E-IP 555 Join/Prune (S,G,rpt) messages SHOULD keep alive. 557 5.6. SPT Switchover 559 After a new AFBR requests the receipt of traffic destined for a 560 multicast group, it will receive all the data from the RPT at first. 561 At this time, every downstream AFBR will receive multicast data from 562 any source from this RPT, in spite of whether they have switched over 563 to an SPT of some source(s) or not. 565 To minimize this redundancy, it is recommended that every AFBR's 566 SwitchToSptDesired(S,G) function employs the "switch on first packet" 567 policy. In this way, the delay in switchover to SPT is kept as small 568 as possible, and after the moment that every AFBR has performed the 569 SPT switchover for every S of group G, no data will be forwarded in 570 the RPT of G, thus no more unnecessary duplication will be produced. 572 5.7. Other PIM Message Types 574 In addition to Join or Prune, other message types exist, including 575 Register, Register-Stop, Hello and Assert. Register and Register- 576 Stop messages are sent by unicast, while Hello and Assert messages 577 are only used between directly linked routers to negotiate with each 578 other. It is not necessary to translate these for forwarding, thus 579 the processing of these messages is out of scope for this document. 581 5.8. Other PIM States Maintenance 583 In addition to states mentioned above, other states exist, including 584 (*,*,RP) and I-IP (*,G') state. Since we treat the I-IP core as SSM- 585 only, the maintenance of these states is out of scope for this 586 document. 588 6. Data Plane Functions of the AFBR 590 6.1. Process and Forward Multicast Data 592 On receiving multicast data from upstream routers, the AFBR checks 593 its forwarding table to find the IP address of each outgoing 594 interface. If there is at least one outgoing interface whose IP 595 address family is different from the incoming interface, the AFBR 596 MUST encapsulate/decapsulate this packet and forward it via the 597 outgoing interface(s), then forward the data via other outgoing 598 interfaces without encapsulation/decapsulation. 600 When a downstream AFBR that has already switched over to the SPT of S 601 receives an encapsulated multicast data packet of (S,G) along the 602 RPT, it SHOULD silently drop this packet. 604 6.2. TTL 606 Processing of TTL information in protocol headers depends on the 607 tunneling technology, and it is out of scope of this document. 609 6.3. Fragmentation 611 The encapsulation performed by an upstream AFBR will increase the 612 size of packets. As a result, the outgoing I-IP link MTU may not 613 accommodate the larger packet size. As it is not always possible for 614 core operators to increase the MTU of every link. Fragmentation 615 after encapsulation and reassembling of encapsulated packets MUST be 616 supported by AFBRs [RFC5565]. 618 7. Packet Format and Translation 620 Because the PIM-SM Specification is independent of the underlying 621 unicast routing protocol, the packet format in Section 4.9 of 622 [RFC7761] remains the same, except that the group address and source 623 address MUST be translated when traversing AFBR. 625 For example, Figure 8 shows the register-stop message format in IPv4 626 and IPv6 address family. 628 0 1 2 3 629 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |PIM Ver| Type | Reserved | Checksum | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | IPv4 Group Address (Encoded-Group format) | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | IPv4 Source Address (Encoded-Unicast format) | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 (1). IPv4 Register-Stop Message Format 639 0 1 2 3 640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 |PIM Ver| Type | Reserved | Checksum | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | IPv6 Group Address (Encoded-Group format) | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | IPv6 Source Address (Encoded-Unicast format) | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 (2). IPv6 Register-Stop Message Format 650 Figure 8: Register-Stop Message Format 652 In Figure 8, the semantics of fields "PIM Ver", "Type", "Reserved", 653 and "Checksum" remain the same. 655 IPv4 Group Address (Encoded-Group format): The encoded-group format 656 of the IPv4 group address described in Section 4.2. 658 IPv4 Source Address (Encoded-Group format): The encoded-unicast 659 format of the IPv4 source address described in Section 4.3. 661 IPv6 Group Address (Encoded-Group format): The encoded-group format 662 of the IPv6 group address described in Section 4.2. 664 IPv6 Source Address (Encoded-Group format): The encoded-unicast 665 format of the IPv6 source address described in Section 4.3. 667 8. Softwire Mesh Multicast Encapsulation 669 Softwire mesh multicast encapsulation does not require the use of any 670 one particular encapsulation mechanism. Rather, it MUST accommodate 671 a variety of different encapsulation mechanisms, and allow the use of 672 encapsulation mechanisms mentioned in [RFC4925]. Additionally, all 673 of the AFBRs attached to the I-IP network MUST implement the same 674 encapsulation mechanism. 676 9. Security Considerations 678 The security concerns raised in [RFC4925] and [RFC7761] are 679 applicable here. In addition, the additional workload associated 680 with some schemes could be exploited by an attacker to perform a out 681 DDoS attack. Compared with [RFC4925], the security concerns SHOULD 682 be considered more carefully: an attacker could potentially set up 683 many multicast trees in the edge networks, causing too many multicast 684 states in the core network. 686 10. IANA Considerations 688 This document includes no request to IANA. 690 11. References 692 11.1. Normative References 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, 696 DOI 10.17487/RFC2119, March 1997, 697 . 699 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 700 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 701 2006, . 703 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 704 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 705 December 2005, . 707 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 708 Durand, Ed., "Softwire Problem Statement", RFC 4925, 709 DOI 10.17487/RFC4925, July 2007, 710 . 712 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 713 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 714 . 716 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 717 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 718 DOI 10.17487/RFC6052, October 2010, 719 . 721 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 722 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 723 2012, . 725 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 726 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 727 Multicast - Sparse Mode (PIM-SM): Protocol Specification 728 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 729 2016, . 731 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 732 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 733 over an IPv6 Multicast Network", RFC 8114, 734 DOI 10.17487/RFC8114, March 2017, 735 . 737 11.2. Informative References 739 [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 740 Multicast Addressing Architecture", RFC 7371, 741 DOI 10.17487/RFC7371, September 2014, 742 . 744 Appendix A. Acknowledgements 746 Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig 747 Venaas provided useful input into this document. 749 Authors' Addresses 751 Mingwei Xu 752 Tsinghua University 753 Department of Computer Science, Tsinghua University 754 Beijing 100084 755 P.R. China 757 Phone: +86-10-6278-5822 758 Email: xumwcs@gmail.com 760 Yong Cui 761 Tsinghua University 762 Department of Computer Science, Tsinghua University 763 Beijing 100084 764 P.R. China 766 Phone: +86-10-6278-5822 767 Email: cuiyong@tsinghua.edu.cn 768 Jianping Wu 769 Tsinghua University 770 Department of Computer Science, Tsinghua University 771 Beijing 100084 772 P.R. China 774 Phone: +86-10-6278-5983 775 Email: jianping@cernet.edu.cn 777 Shu Yang 778 Tsinghua University 779 Graduate School at Shenzhen 780 Shenzhen 518055 781 P.R. China 783 Phone: +86-10-6278-5822 784 Email: yangshu@csnet1.cs.tsinghua.edu.cn 786 Chris Metz 787 Cisco Systems 788 170 West Tasman Drive 789 San Jose, CA 95134 790 USA 792 Phone: +1-408-525-3275 793 Email: chmetz@cisco.com 795 Greg Shepherd 796 Cisco Systems 797 170 West Tasman Drive 798 San Jose, CA 95134 799 USA 801 Phone: +1-541-912-9758 802 Email: shep@cisco.com