MBONED Working Group Y. Liu Internet-Draft China Mobile Intended status: Standards Track A. Wang Expires: December 31, 2024 China Telecom C. Lin New H3C Technologies Zh. Zhang ZTE Corporation Y. Qiu New H3C Technologies Y. Liang Ruijie Networks July 4, 2024 Adaptive Unicast to Multicast Forwarding draft-liu-mboned-adaptive-utom-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 31, 2024. Copyright Notice Copyright (c) 2024 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 Liu, et al. Expires December, 2024 [Page 1] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes an adaptive optimization method of unicast forwarding for network devices to solve the problem that unicast service traffic takes up too much bandwidth of the IP carrier network under the point to multipoint scenarios. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 1.2. Terminology...............................................3 2. Adaptive Unicast to Multicast Forwarding Architecture..........3 3. Device Role Definition.........................................4 4. Optimization processing of unicast traffic forwarding..........6 4.1. Multicast Group Member Management.........................6 4.2. Packet Forwarding Optimization Process....................7 5. Mapping Relationship Table Management..........................9 5.1. Add Mapping Relationship Table Entries...................10 5.2. Delete Mapping Relationship Table Entries................10 6. IANA Considerations...........................................11 7. Security Considerations.......................................11 8. References....................................................11 8.1. Normative References.....................................11 8.2. Informative References...................................12 9. Acknowledgments...............................................12 Authors' Addresses...............................................13 Liu, et al. Expires December, 2025 [Page 2] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 1. Introduction For the point to multipoint service of existing Internet manufacturers, the Internet service system needs to be upgraded on a large scale to support point-to-point duplication encoding and distribution of multicast streams. For Internet manufacturers, the service pressure of unicast connection can be solved by other ways, such as expanding servers, which lacks the power of multicast transformation. However, for the network operators, the network bandwidth pressure brought by the Internet point to multipoint service is very large, and they do not gain additional benefits from it. Instead, they may occupy the bandwidth required by other services, and have to carry out network expansion to increase network investment costs. To solve this problem, this document proposes a method of adaptive unicast to multicast transmission for network devices. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The definitions of the basic terms are identical to those found in BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514]. 2. Adaptive Unicast to Multicast Forwarding Architecture AS showed in Figure 1, both the head end system and the terminal system of Internet services do not need to be upgraded by multicast. Instead, the PE of the IP carrier network (act as multicast sender site) needs to identify the characteristics of the service and convert unicast and multicast according to the characteristics. Liu, et al. Expires December, 2025 [Page 3] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 IP Carrier Network +--------------------------------------+ | Native Multicast On-Net | | (PIM, P2MP MPLS, BIER, etc) | +----------+ +-------------+ | | Internet |--| Multicast | | | Service | | Sender Site | | | Server | +-------------+ | | | | +--------------+ +--------------+ | +----------+ | | Multicast | | Multicast | | +--| Receiver Site|--| Receiver Site|--+ +--+-------+---+ +-------+------+ | | | +-+ +-+ +-+ +-+ +-+ +-+ Terminal Terminal Users Users Figure 1 3. Device Role Definition Taking Figure 2 as an example, introduce several key device roles in the adaptive forwarding optimization method for unicast traffic. Liu, et al. Expires December, 2025 [Page 4] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 +------------+ | Internet | | Service | | Server | +---+----+---+ | | +------+ +-------+ | | +------------+-----+-----+-------+-----+-----+--------+ | | R4 | | R5 | | | | Ingress PE| | Ingress PE| | | +-----------+ +-----+-----+ | | | | IP Carrier Network | | | | +---------+ +----------+ +----------+ | | | R1 | | R2 | | R3 | | | |Egress PE| | Egress PE| | Egress PE| | +--+----+----+-------+-----+----+-------+-----+----+--+ | | | +----+----+ +-----+----+ +-----+----+ | Terminal| | Terminal | | Terminal | | Users | | Users | | Users | +---------+ +----------+ +----------+ Figure 2 R1~R5 are all PE devices. Among them, R4 and R5 are on the network side, connected to the service server. R1, R2, and R3 are located on the terminal user side. Multiple terminal users need to use the same resources on the service server. * Ingress PE of multicast domain The ingress PE is an edge device located on the Internet service server side of the carrier network. When the service traffic sent by the server to the end user enters the IP carrier network, R4 and R5 act as the ingress nodes of the IP carrier network, identifying the packet characteristics and determining whether the traffic is a predefined unicast service traffic that can be converted into multicast forwarding. If so, R4 and R5 can be recognized as the ingress PE of multicast domain for the service traffic. * Egress PE of multicast domain The egress PE is an edge device located on the terminal user side of the carrier network. Liu, et al. Expires December, 2025 [Page 5] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 When the traffic is sent to the terminal user through the IP carrier network's egress nodes R1, R2, and R3, which can also perform similar processing as the ingress PE. Based on the input and output directions of the service traffic, the roles of ingress PE and egress PE of multicast domain can be determined. The roles are not fixed and unchanging. For different service traffic in different directions, the same device can have different roles simultaneously. In actual deployment, configuration can also be added on the interface to specify the device role for a certain flow characteristics. The detailed configuration method is out of the scope of this document. 4. Optimization processing of unicast traffic forwarding Taking Figure 2 as an example, introduce the processing flow of adaptive forwarding optimization for unicast traffic. 4.1. Multicast Group Member Management Firstly according to the adaptive optimization policy, generate the mapping relationship between unicast flow characteristics, multicast IP addresses, and user IP addresses that need to be adaptively forwarded on the ingress PE R4 and egress PE R1 of the multicast domain in advance. The characteristics of unicast traffic include but are not limited to one or a combination of more message information as follows: * Source IP address * Destination IP address * TCP/UDP source port * TCP/UDP destination port * Protocol number * DSCP * Application ID (APN ID) For example, identifying unicast service traffic that require forwarding optimization based on the five-tuple information (SIP, Liu, et al. Expires December, 2025 [Page 6] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 DIP, SPort, DPort, Protocol) of the packet or based on the APN ID in IPv6 Extension Header. After receiving the service traffic with specified characteristics, the multicast ingress PE will not immediately switch to multicast forwarding path. The process is as followed: 1) When the egress PE R1 of the multicast domain receives a unicast traffic flow with specified characteristics, it simulates static configuration locally to generate the corresponding multicast group or multicast source group, and queries the upstream of the multicast according to the process defined in [RFC6513] and [RFC6514], and sends a C-Multicast join request to the ingress PE R4 of the multicast domain. 2) After receiving the C-Multicast join request from R1, R4 adds R1 to the corresponding multicast group. If there are two or more multicast upstream nodes, choose the optimal one according to [RFC6514], or choose the primary and backup upstream nodes according to [RFC9026]. When the multicast flow reaches the egress PE, only the traffic from the primary node can be forwarded according to the RPF check rule. 4.2. Packet Forwarding Optimization Process The packet forwarding optimization process is shown in Figure 3. +---------------+ +-----------------+ +---------------+ | SIP: Server-IP| | SIP: Server-IP | | SIP: Server-IP| +---------------+ +-----------------+ +---------------+ | DIP:User-IP | |DIP: Multicast IP| | DIP:User-IP | +---------------+ +-----------------+ +---------------+ | Data | | Data | | Data | +---------------+ +-----------------+ +---------------+ +--------+ +--------+ +--------+ +------+ | Server +------->+ R4 +--------->+ R1 +----------+ User | +--------+ +--------+ +--------+ +------+ Figure 3 1) After receiving a packet from the server, ingress PE R4 identifies the unicast packet that needs adaptive forwarding optimization based on the flow characteristics. Liu, et al. Expires December, 2025 [Page 7] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 2) R4 searches the mapping relationship entries, replaces the destination IP address with a multicast address based on the found entry, and converts the identified unicast traffic into the corresponding multicast flow. 3) R4 processes ordinary IP multicast packets and forwards them on the IP carrier network through a multicast tunnel. The multicast tunnels here include but are not limited to PIM, P2MP MPLS, BIER, etc. The process of forwarding multicast packets within the IP carrier network is not within the scope of this document. For details, can refer to the BGP MVPN architecture standards defined in [RFC6513] and [RFC6514], as well as the BIER MVPN standards defined in [RFC8556]. 4) After receiving the multicast traffic forwarded by the carrier network to the terminal user, egress PE R1 restores the multicast traffic to a unicast traffic based on the mapping relationship between the multicast IP address and the terminal user IP address. The destination address is replaced with the terminal user's IP address before unicast forwarding. If multiple terminal users need the same service traffic, R1 will convert multicast packet into multiple unicast packets based on the mapping relationship and send them to each terminal user separately. The table shows the mapping relationship between the unicast flow characteristics (Using five-tuple as an example), multicast IP addresses, and terminal user IP addresses maintained on the ingress PE and egress PE of the multicast domain, as shown in the following example: Liu, et al. Expires December, 2025 [Page 8] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 +---------------+-----------+----------------------------------+ | | | service flow characteristics | | Multicast IP | User IP | Using five-tuple as an example | | | |(DIP, SIP, DPort, Sport, Protocol)| +---------------+-----------+----------------------------------+ | FF0E::1 | 2001::1 | 2001::1, 3001::1, 4545, 8000, IP | +---------------+-----------+----------------------------------+ | FF0E::1 | 2001::2 | 2001::2, 3001::1, 3400, 8000, IP | +---------------+-----------+----------------------------------+ | FF0E::2 | 2001::3 | 2001::3, 3001::2, 6000, 5000, IP | +---------------+-----------+----------------------------------+ | FF0E::3 | 2001::4 | 2001::4, 3001::2, 7000, 5000, IP | +---------------+-----------+----------------------------------+ | FF0E::3 | 2001::1 | 2001::1, 3001::2, 8000, 5000, IP | +---------------+-----------+----------------------------------+ For users who have already been added to the mapping relationship table, the egress PE only forwards packets from the multicast forwarding path to users according to the mapping relationship. For users who have not yet been added to the mapping table, still forward packets from the unicast forwarding path to those users. Before generating the mapping relationship entry for the user, service packets sent to that user continue to be forwarded in unicast mode. But once the user's service traffic switches to the multicast forwarding path, the egress PE MUST stop sending the packet from unicast forwarding path to the user to prevent the end user from receiving duplicate service packets. Therefore, before generating the mapping relationship entry for the user on the ingress PE, the egress PE may receive both unicast service packets sent to the user and multicast service packets sent to other users who have already joined the multicast group. 5. Mapping Relationship Table Management When it is necessary to adaptively switch between unicast and multicast modes for the user's service traffic, the ingress PE SHOULD notify the egress PE to send a request to join or leave the multicast group to the ingress PE. The mapping relationship table can be generated in the following three ways: * Static configuration on ingress and egress PEs. * The controller centrally issues to ingress and egress PEs. Liu, et al. Expires December, 2025 [Page 9] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 * Ingress and egress PEs create and delete entries dynamically based on the user's service traffic. The following focuses on describing the dynamic approach. In practical applications, the optimization strategy on the ingress PE of the multicast domain is specified by the configuration. The mapping relationship table entries on the egress PE are dynamically created and deleted upon receiving notification of switching multicast mode from the ingress PE. 5.1. Add Mapping Relationship Table Entries According to the optimization strategy of the ingress PE, for example, when the number of terminal users who need the same unicast service flow reaches a specified threshold (such as more than 5000), or when the service traffic that multiple terminal users need is continuously forwarded in unicast mode for a certain period of time (such as 10 minutes), the ingress PE sends a notification to switch multicast mode to all egress PEs belonging to these terminal users simultaneously. To a new terminal user who needs to receive a certain service traffic, the ingress PE does not immediately switch the service traffic sent to the terminal user to the multicast path. Instead, it waits for a period of time. If the service traffic to the user can be stably forwarded, the ingress PE sends a notification to the egress PE of the user to trigger the egress PE to send a C-Multicast join request. When receiving the notification, the egress PE adds the corresponding mapping relationship table entry and sends C-Multicast join request to the ingress PE. After receiving the C-Multicast join request from the egress PE, the ingress PE creates a mapping relationship table entry and adds the egress PE to the corresponding multicast group. 5.2. Delete Mapping Relationship Table Entries If the terminal user no longer needs to receive service traffic sent through multicast path, the egress PE to which the terminal user belongs sends a C-Multicast leave message of the multicast group to the ingress PE, and deletes the forwarding optimization mapping relationship table entry. After receiving the C-Multicast leave message, the ingress PE deletes the egress PE from the multicast group and deletes the Liu, et al. Expires December, 2025 [Page 10] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 mapping relationship table entry. Afterwards, the service traffic will no longer be forwarded to this terminal user through the multicast path. Because terminal users only interact with the server, when they no longer need to receive the service traffic, neither the ingress PE nor the egress PE of the multicast domain can receive any signaling. To address this issue, the multicast ingress PE recommends using periodic traffic statistics to perceive whether the terminal user still needs to receive the service traffic. When the traffic send to the user through the ingress PE is below the threshold, it is determined that the service traffic of the terminal user has been interrupted. 6. IANA Considerations This document has no IANA actions. 7. Security Considerations This document does not introduce new security considerations. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Liu, et al. Expires December, 2025 [Page 11] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 2019, . [RFC9026] Morin, T., Kebler, R., Mirsky, G., "Multicast VPN Fast Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, April 2021, . 8.2. Informative References TBD 9. Acknowledgments The authors would like to thank the following for their valuable contributions of this document: TBD Liu, et al. Expires December, 2025 [Page 12] Internet-Draft Adaptive Unicast to Multicast Forwarding July 2024 Authors' Addresses Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Aijun Wang China Telecom China Email: wangaijun@tsinghua.org.cn Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Zheng Zhang ZTE Corporation China Email: zhang.zheng@zte.com.cn Yuanxiang Qiu New H3C Technologies China Email: qiuyuanxiang@h3c.com Yanrong Liang Ruijie Networks China Email: liangyanrong@ruijie.com.cn Liu, et al. Expires December, 2025 [Page 13]