Network Working Group W. Cheng Internet-Draft China Mobile Intended status: Informational G. Mishra Expires: April 28, 2022 Verizon Inc. Z. Li Huawei Technologies A. Wang China Telecom Z. Qin China Unicom C. Fan New H3C Technologies October 25, 2021 Design Consideration of IPv6 Multicast Source Routing (MSR6) draft-cheng-spring-ipv6-msr-design-consideration-01 Abstract This document discusses the design consideration of IPv6 source routing multicast solution. 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 RFC 2119 [RFC2119]. 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 https://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 April 28, 2022. Cheng, et al. Expires April 28, 2022 [Page 1] Internet-Draft Design Consideration of MSR6 October 2021 Copyright Notice Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference Mode . . . . . . . . . . . . . . . . . . . . . . . 3 4. Deployment Modes . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Conventional Multicast Deployment . . . . . . . . . . . . 4 4.2. Host-Initiated Multicast Deployment . . . . . . . . . . . 5 4.3. Multicast Overlay Network . . . . . . . . . . . . . . . . 6 5. Design Consideration . . . . . . . . . . . . . . . . . . . . 7 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Path Programming . . . . . . . . . . . . . . . . . . . . 9 6.2. Resource Assurance . . . . . . . . . . . . . . . . . . . 9 6.3. Deterministic Delay . . . . . . . . . . . . . . . . . . . 9 6.4. Performance Measurement . . . . . . . . . . . . . . . . . 10 6.5. Reliability . . . . . . . . . . . . . . . . . . . . . . . 10 6.6. Forwarding Efficiency . . . . . . . . . . . . . . . . . . 10 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. MVPN or GTM service . . . . . . . . . . . . . . . . . . . 11 7.2. File Delivery . . . . . . . . . . . . . . . . . . . . . . 11 7.3. WebRTC Relaying . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Multicast could provide efficient P2MP service without bandwidth waste. The increasing amount of live video traffic in the network bring new requirements for multicast solutions. Traditional multicast solutions request multicast tree-building on control plane Cheng, et al. Expires April 28, 2022 [Page 2] Internet-Draft Design Consideration of MSR6 October 2021 and maintaining end-to-end tree state per flow, which impacts router state capacity and network convergence time. There has been a lot of work in IETF to simplify service deployment, in which Source Routing is a very important technology. Source routing is able to reduce the state of intermediate nodes and indicate unicast forwarding in the ingress nodes, which could simplify unicast deployment. Source routing requires sufficient flexibility on the forwarding plane and IPv6 has the advantage with good scalability. Particularly, based on the IPv6 data plane, SRv6 could be deployed not only in a controlled domain where routers and hosts are running SRv6 cooperatively. With the same stateless design, there is another work called Bit Index Explicit Replication (BIER) [RFC8279] introduced in IETF. The BIER solution is different than the traditional multicast and the benefits have been understood by the community. However, the BIER architecture is designed to be Layer-2.6 independent layer, and aims to be used in a domain comprised of routers only, where the Ingress router encapsulate a received multicast packet with BIER header and traverse through the domain, wherein the Egress router decapsluate the multicast packet from the BIER encapsulation and forward the multicast packet further as traditional multicast does. With the deployment of SRv6, there is arising requirements to build solutions where hosts and routers are cooperatively deployed in a controlled domain, and stateless multicast solution start from hosts. Therefore, it is important to also have a layer-3 stateless multicast solution based on IPv6 data plane, which we called multicast source routing (MSR6). This document discusses the design consideration of IPv6 multicast source routing (MSR6) solution. It combines the SRv6 Network programming concept and BIER concept to build a new Layer-3 stateless multicast solution. 2. Terminology 3. Reference Mode Cheng, et al. Expires April 28, 2022 [Page 3] Internet-Draft Design Consideration of MSR6 October 2021 +---+ | A | ----------------- +---+ | / \ | +---+ +---+ | | B | | C | MSR6 domain +---+ +---+ | / | | \ | +---+ +---+ +---+ +---+ | | D | | E | | F | | G |-------- +---+ +---+ +---+ +---+ In the reference topology illustrated in Figure 1, it is assumed: o The MSR6 domain is comprised by node A, B, C, D, E, F and G. o Node A is root node. Node B and C are transit nodes. Node D, E, F and G are leaf nodes. o The root and leaf nodes can be hosts or routers. o The transit nodes are routers functioning the MSR6 routing and forwarding procedures. 4. Deployment Modes 4.1. Conventional Multicast Deployment The first deployment mode is dipicted in below figure. Cheng, et al. Expires April 28, 2022 [Page 4] Internet-Draft Design Consideration of MSR6 October 2021 +--------------+ |Client Network| +--------------+ | +---+ | A |------------------ +---+ | / \ | +---+ +---+ | | B | | C | MSR6 domain +---+ +---+ | / | | \ | +---+ +---+ +---+ +---+ | | D | | E | | F | | G |-------- +---+ +---+ +---+ +---+ | | | | +------------------------+ | Client Network | +------------------------+ In this case, MSR6 domain is comprised of routers only. The Ingress router A encapsulates a multicast packet received from client Network with a tunnel header and the encapsulated packet will traverse through the domain, wherein the Egress router decapsluate the multicast packet from the BIER encapsulation and forward the multicast packet further to the client network. This is similar to the BIER architecture with a difference that the the MSR6 uses IPv6 based dataplane. 4.2. Host-Initiated Multicast Deployment The second deployment mode is dipicted in below figure. +---------+ |Server A | -------------- +---------+ | / \ | +---+ +---+ | | B | | C | | +---+ +---+ MSR6 domain / | | \ | +---+ +---+ +---+ +---+ | |Ser| |Ser| |Ser| |Ser| | | D | | E | | F | | G |-------- +---+ +---+ +---+ +---+ In this case, MSR6 domain is comprised of hosts and routers, where node A/D/E/F/G are hosts which is usually a server instead of the Cheng, et al. Expires April 28, 2022 [Page 5] Internet-Draft Design Consideration of MSR6 October 2021 user-equipment(UE). MSR6 packet is originated at Server A, and destined to Server D, E, F and G. 4.3. Multicast Overlay Network In the Multicast Overlay Network, there is a multicast proxy node in each site, and the contents allocation from one site to serveral sites could be implemented by the multicast proxy nodes. ------- / +---+ \ +-----|---+ A +---|-----+ | \ +---+ / | | -Site a- | | | ------- ---|--- / +-+-+ \ / +-+-+ \ | | B | | +-|---+ C +---|-+ \ +---+ / | \ +---+ / | -Site b- | -Site c- | ---|--- ---|--- / +-+-+ \ / +-+-+ \ | | D | | | + E + | \ +---+ / \ +---+ / -Site d- -Site e- An example of the Multicast Overlay Network could be as follows: o Each client of the sites collect the information of the multicast proxy nodes and their connection relationship; o Several clients, from site b,d,e, request the same contents in one client X of site a at the same time; o Client X generates a P2MP path from Site a to site b,d,e and the path is encoded into an MRH A; o Client X sends out the requested contents by an IPv6 packet with MRH A, indicating the P2MP path explicitely; o The packet is transported to the clients in site b,d,e through proxy A in site a and Proxy C in site c; Cheng, et al. Expires April 28, 2022 [Page 6] Internet-Draft Design Consideration of MSR6 October 2021 5. Design Consideration Firstly, MSR6 needs to support the basic multicast functionalities, including: o P2MP Forwarding: replicate and forward multicast packet to the next replication nodes; o Multicast Flow Overlay: multicast service, such as MVPN o P2MP OAM functions: Ping/Traceroute/BFD In addition to this, it is necessary for MSR6 to meet the need of high quality service with high reliability, including: o Traffic Engineering: explicit path specification to satisfy different kinds of requirements o FRR o E2E Protection o Advanced network measurement functions, including: performance measurement and In-situ Flow Information Telemetry, which is the basis for traffic engineering and high quality transport service. The IPv6 multicast source routing should take use of the advantages of source routing to reduce the state of the network as much as possible. That is, it should satisfy the above requirements with high scalability. However, MSR6 is not about starting from scratch. The existing IETF work should be reused as much as possible: o BIER [RFC8279] and [RFC8296] Bit Index Explicit Replication (BIER) defined in [RFC8279] is an architecture providing optimal multicast forwarding without requiring intermediate routers to maintain any per-flow state by using a multicast-specific BIER header. BIER use bitstring in the BIER header to indicate leaf nodes which gives an efficient solution for stateless multicast solution. flow without the requirement of Traffic Engineering. o SRv6([RFC8986]) SRv6 has advantages in indicating explicit paths, which brings convenience for unicast TE and FRR. MSR6 TE should refer to the Cheng, et al. Expires April 28, 2022 [Page 7] Internet-Draft Design Consideration of MSR6 October 2021 experience of SRv6. In addition, SRv6 provides flexible path programming capability with the definition of different type of segments. MSR6 could make use the of existing segments in the design of TE/FRR . For example, path segment ([I-D.ietf-spring-srv6-path-segment]) could help to enhance the performance measurement capability. In the meantime, SRv6 compression ([I-D.srcompdt-spring-compression-requirement]) is under discussion to reduce encapsulation overhead, which could also be reused by MSR6. o The existing and ongoing IPv6 extensions 1) Existing functionalities including fragmentation and security Multicast packets need to be fragmented and secured as they pass through the IPv6 network. This can be done using IPv6 Fragmentation and ESP(Encapsulating Security Payload) defined in [RFC8200]. Work about Path MTU [I-D.ietf-idr-sr-policy-path-mtu] which supports fragmentation, is also under discussion. All these existing work should be reused in the MSR6. 2) New network functionalities based on the ongoing IPv6 Extensions, including Network Slicing, Deterministic Networking(DetNet), IOAM.etc. Network slicing ([I-D.ietf-teas-ietf-network-slices]) and DetNet ([RFC8655]) are being introduced to satisfy the quality service requirements of critical services. IOAM ([I-D.ietf-ippm-ioam-data]) is also introduced to implement in-situ network measurement. IPv6 data plane is being used to support network slicing ([I-D.li-6man-e2e-ietf-network-slicing] and [I-D.dong-6man-enhanced-vpn-vtn-id]), Detnet ([I-D.geng-spring-srv6-for-detnet] and [I-D.geng-spring-sr-redundancy-protection]), IOAM ([I-D.ietf-ippm-ioam-data]), etc. Multicast service can also benefit from these new network functionalities to improve quality of service. MSR6 could reuse the ongoing work based on IPv6 extensions to implement the functionalities for multicast services. 3) Future possible work based on IPv6 extensions, including Application Aware Network (APN) APN ([I-D.li-apn-framework]) is used to provide more granular services, which can use IPv6 extension header to carry APN information for the purpose of steering traffic, etc. MSR6 can combine with APN to map the traffic to different Network-based multicast services/functionalities according to the APN information in the IPv6 data plane. Cheng, et al. Expires April 28, 2022 [Page 8] Internet-Draft Design Consideration of MSR6 October 2021 4) MSR6 is also supposed to be started at the Host based on IPv6 In [RFC8754], it is supposed that a host can originate the IPv6 source routing packet. MSR6 should take use of the native IPv6 design and support originating the IPv6 packet by the host. 6. Requirements This section describes the overall requirements which need to be fulfilled by MSR6. 6.1. Path Programming When the multicast root and leafs are determined, the multicast service may be forwarded along different multicast paths/trees. Each multicast tree has different performance attribute, such as bandwidth, delay, etc. For instance, tree A is the shortest path from root 1 to leaf 1-100, which has the lowest delay, while the other tree B from the same root to same leafs can provide more bandwidth than tree A. Therefore, the delay-sensitive traffic like cloud AR/VR traffic SHOULD be forwarded along with tree A, and the traffic that is delay-insensitive but requiring large bandwidth like 8k HD Video be forwarded along with tree B. In order to meet the different SLA requirements, IPv6-based MSR6 MUST support path programming. 6.2. Resource Assurance Network slicing is another method to provide SLA differentiated services, because it is able to provide separate and independent logical network over the physical network infrastructure. Each Network Slicing has its own allocated resource, which can also meet the specific SLA requirements for different multicast service. Or an independent network slice could be allocated to all the multicast service, which could provide multicast service with better transport performance than normal unicast service. So in order to provide SLA guaranteed services, MSR6 SHOULD support network slicing. 6.3. Deterministic Delay Some delay-sensitive multicast traffic may have the strict requirements for network delay, especailly in some scenario of IoT or enterprise. Deterministic Networking (DetNet) defined in [RFC8655] could provide service with E2E latency upper bound for both unicast and multicast. Therefore, MSR6 shoud support DetNet. Cheng, et al. Expires April 28, 2022 [Page 9] Internet-Draft Design Consideration of MSR6 October 2021 6.4. Performance Measurement Many OAM mechanisms are used to support network operation. Performance Measurement (PM) is one of the most important part of OAM. With PM, the real-time QoS of the forwarding path, like delay, packet loss ratio and throughput, can be measured. PM can be implemented in one of three ways: active, passive, or hybrid defined in [RFC7799], differing in whether OAM packets need to be proactively sent. On-path telemetry, defined in [I-D.song-opsawg-ifit-framework] , is an hybrid mode OAM/PM mechanism, which provides better accuracy than active PM. Some multicast scenarios have strong requirement for PM, therefore on-path Performance Measurement SHOULD be supported in MSR6. 6.5. Reliability In scenarios where multicast is used to carry video streams, packet loss can lead to impaired video quality. So high reliability is required in these scenarios. E2E protection and local protection of node and links MUST be supported in MSR6. Furthermore, root and leaf node protection SHOULD be supported. 6.6. Forwarding Efficiency Multicast is used for saving bandwidth cost with the capability of replication and forwarding. Path Maximum Transmission Unit indicates the maximum size of a packet that it can be forwarded along a path. Setting an appropriate PMTU for packets can avoid fragmentation or dropping, so that the forwarding efficiency can be raised. Also, the overhead of packets MUST be added very carefully since it affects the forwarding efficiency directly. For example, when many SIDs are inserted in an SRv6 packet, the overhead of the SID list is too large. Therefore, the MSR6 MUST support PMTU probing and configuration. In addition, it SHOULD support compression when it is necessary. Cheng, et al. Expires April 28, 2022 [Page 10] Internet-Draft Design Consideration of MSR6 October 2021 7. Use Cases 7.1. MVPN or GTM service MVPN(multicast virtual private network, RFC6513) and GTM(Global Table Multicast, RFC7716) are usual cases for conventional deployment mode, where MSR6 acts as P-tunnel of c-multicast packets. 7.2. File Delivery File Delivery over Unidirectional Transport (FLUTE, RFC6726) is a common use case for multicast. The traditional multicast or MSR6 conventional deployment mode are both valid candidates for FLUTE, where the application in host could Join a multicast Group address, and receive multicast packet carrying file content. In some other cases, File delivery to multiple hosts efficiently (for example, video editing) may need within a data center network, but the data center may not support underlay multicast routing of any form in the Fabric infrastructure. In such cases, Host-initialized MSR6 could be used as figure dipcted below. Server A originates a MSR6 packet carrying file content bytes and sends to B or C. Router B or C receives the MSR6 packet and replicate to Server D/E/F/G. Server D/E/F/G receives the MSR6 packet and gets the file content bytes within it. Router B or C acts as overlay Multicast Service Node [RFC8293] in this case. +---------+ |Server A | ------------------ +---------+ | / \ | / \ | +-----------+ +---+ | | +-----| B | | | | +---+ | | IP Fabric | MSR6 domain | | +---+ | | +-----| C | | +-----------+ +---+ | / | | \ | / | | \ | +---+ +---+ +---+ +---+ | |Ser| |Ser| |Ser| |Ser| | | D | | E | | F | | G |------------ +---+ +---+ +---+ +---+ Cheng, et al. Expires April 28, 2022 [Page 11] Internet-Draft Design Consideration of MSR6 October 2021 7.3. WebRTC Relaying Web Real-Time Communications (WebRTC) is now an official World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) standard. In supporting of multiparty conference, WebRTC Gateway is usually deployed to switch audio and video packets between multiple clients. The figure dipects the case, where C1 to C7 are WebRTC client (e.g., browser), and Server A, D, E, F and G are WebRTC gateways. Within the MSR6 doamin, MSR6 is used in both hosts and routers. C1 C2 C3 \ | / +---------+ |Server A | -------------- +---------+ | / \ | +---+ +---+ | | B | | C | | +---+ +---+ MSR6 domain / | | \ | +---+ +---+ +---+ +---+ | |Ser| |Ser| |Ser| |Ser| | | D | | E | | F | | G |-------- +---+ +---+ +---+ +---+ | | | | C4 C5 C6 C7 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations 10. Acknowledgements 11. Normative References [I-D.dong-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension Header", draft-dong-6man-enhanced-vpn-vtn- id-06 (work in progress), October 2021. Cheng, et al. Expires April 28, 2022 [Page 12] Internet-Draft Design Consideration of MSR6 October 2021 [I-D.geng-spring-sr-redundancy-protection] Geng, X., Chen, M., Yang, F., Garvia, P. C., and G. Mishra, "SRv6 for Redundancy Protection", draft-geng- spring-sr-redundancy-protection-05 (work in progress), August 2021. [I-D.geng-spring-srv6-for-detnet] Geng, X., Li, Z., and M. Chen, "SRv6 for Deterministic Networking (DetNet)", draft-geng-spring-srv6-for-detnet-01 (work in progress), July 2020. [I-D.ietf-idr-sr-policy-path-mtu] Li, C., Zhu, Y., Sawaf, A. E., and Z. Li, "Segment Routing Path MTU in BGP", draft-ietf-idr-sr-policy-path-mtu-04 (work in progress), October 2021. [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data-15 (work in progress), October 2021. [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M., Dhody, D., Gandhi, R., and Y. Zhu, "Path Segment for SRv6 (Segment Routing in IPv6)", draft-ietf-spring-srv6-path-segment-02 (work in progress), May 2021. [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", draft-ietf-teas-ietf- network-slices-04 (work in progress), August 2021. [I-D.li-6man-e2e-ietf-network-slicing] Li, Z. and J. Dong, "Encapsulation of End-to-End IETF Network Slice Information in IPv6", draft-li-6man-e2e- ietf-network-slicing-00 (work in progress), April 2021. [I-D.li-apn-framework] Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, "Application-aware Networking (APN) Framework", draft-li- apn-framework-03 (work in progress), May 2021. [I-D.song-opsawg-ifit-framework] Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- situ Flow Information Telemetry", draft-song-opsawg-ifit- framework-16 (work in progress), October 2021. Cheng, et al. Expires April 28, 2022 [Page 13] Internet-Draft Design Consideration of MSR6 October 2021 [I-D.srcompdt-spring-compression-requirement] Cheng, W., Xie, C., Bonica, R., Dukes, D., Li, C., Shaofu, P., and W. Henderickx, "Compressed SRv6 SID List Requirements", draft-srcompdt-spring-compression- requirement-07 (work in progress), July 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, DOI 10.17487/RFC8663, December 2019, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Cheng, et al. Expires April 28, 2022 [Page 14] Internet-Draft Design Consideration of MSR6 October 2021 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Authors' Addresses Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com Aijun Wang China Telecom Email: wangaj3@chinatelecom.cn Zhuangzhuang Qin China Unicom Email: qinzhuangzhuang@chinaunicom.cn Chi Fan New H3C Technologies Email: fanchi@h3c.com Cheng, et al. Expires April 28, 2022 [Page 15]