Adaptive Unicast to Multicast Forwarding
draft-liu-mboned-adaptive-utom-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yisong Liu , Aijun Wang , Changwang Lin , Zheng Zhang , Yuanxiang Qiu , Yanrong Liang | ||
| Last updated | 2024-10-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-mboned-adaptive-utom-01
MBONED Working Group Y. Liu
Internet-Draft China Mobile
Intended status: Standards Track A. Wang
Expires: April 20, 2025 China Telecom
C. Lin
New H3C Technologies
Zh. Zhang
ZTE Corporation
Y. Qiu
New H3C Technologies
Y. Liang
Ruijie Networks
October 20, 2024
Adaptive Unicast to Multicast Forwarding
draft-liu-mboned-adaptive-utom-01
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 April 20, 2025.
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 April, 2025 [Page 1]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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. Use Cases of Unicast to Multicast Forwarding ................. 4
2.1. Optimize Traffic Forwarding for Video Live Streaming .... 4
2.2. Optimize Traffic Forwarding for Online Games ............ 4
3. Adaptive Unicast to Multicast Forwarding Architecture ........ 4
4. Device Role Definition ....................................... 5
5. Optimization processing of unicast traffic forwarding ........ 7
5.1. Multicast Group Member Management ....................... 7
5.2. Packet Forwarding Optimization Process .................. 8
6. Mapping Relationship Table Management ....................... 10
6.1. Add Mapping Relationship Table Entries ................. 11
6.2. Delete Mapping Relationship Table Entries .............. 11
7. IANA Considerations ......................................... 12
8. Security Considerations ..................................... 12
9. References .................................................. 12
9.1. Normative References ................................... 12
9.2. Informative References ................................. 13
10. Acknowledgments ............................................ 13
Authors' Addresses ............................................. 14
Liu, et al. Expires April, 2025 [Page 2]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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.
[RFC7450] describes Automatic Multicast Tunneling (AMT), a protocol
for delivering multicast traffic from sources in a multicast-enabled
network to receivers that lack multicast connectivity to the source
network. The protocol uses UDP encapsulation and unicast replication
to provide this functionality.
Unlike the problem of multicast service packets crossing unicast
domain that lack multicast connectivity solved by AMT, what we are
currently facing is the bandwidth pressure issue when forwarding
unicast packets in point to multipoint scenarios.
To solve current 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].
Liu, et al. Expires April, 2025 [Page 3]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 2024
2. Use Cases of Unicast to Multicast Forwarding
2.1. Optimize Traffic Forwarding for Video Live Streaming
Video live streaming is a technology and service that enables real-
time transmission of video and audio content over the internet.
Users can control real-time activities, events or performances
through the Internet platform, such as news, sports events and live
games. The data transmission of video live streaming often adopts a
client-server model. The video content is captured by camera
equipment and transmitted to the server, which then distributes the
video stream to various viewers. Unicast forwarding is used between
the server and the viewer.
Due to the large number of viewers watching the same live channel at
the same time, if the forwarding of live streaming traffic is not
optimized, it will occupy a large amount of bandwidth resources in
the IP carrier network, resulting in the forwarding of other service
packets being affected. If the same unicast traffic can be forwarded
on the multicast path, video live streaming traffic can traverse the
IP carrier network along a multicast forwarding path, effectively
improving the forwarding performance of the carrier network.
2.2. Optimize Traffic Forwarding for Online Games
Online multiplayer games are electronic games that allow multiple
players to interact and compete in the same game environment through
the Internet or LAN. Through network connectivity, players can
interact in real-time around the world. In this game, players can
collaborate to complete tasks, engage in battles, or compete for
rankings.
Due to the low latency of UDP, which is highly suitable for real-
time interaction, many online games use the UDP protocol to transmit
data, such as the well-known World of Warcraft and League of
Legends.
During game interaction, the game server needs to simultaneously
push a large amount of identical game data to multiple players' game
clients. Using the adaptive forwarding method of unicast to
multicast described in this document to forward game data can
greatly reduce the pressure on IP carrier network.
3. 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
Liu, et al. Expires April, 2025 [Page 4]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 2024
site) needs to identify the characteristics of the service and
convert unicast and multicast according to the characteristics.
IP Carrier Network
+--------------------------------------+
| |
| Native Multicast On-Net |
+----------+ | (PIM, P2MP MPLS, BIER, etc) |
| Internet | +-------------+ |
| Service |--| Multicast | |
| Server | | Sender Site | |
+----------+ +-------------+ |
| +--------------+ +--------------+ |
| | Multicast | | Multicast | |
+--| Receiver Site|--| Receiver Site|--+
+--+-------+---+ +-------+------+
| | |
+-+ +-+ +-+
+-+ +-+ +-+
Terminal Terminal
Users Users
Figure 1
4. 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 April, 2025 [Page 5]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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 April, 2025 [Page 6]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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.
5. Optimization processing of unicast traffic forwarding
Taking Figure 2 as an example, introduce the processing flow of
adaptive forwarding optimization for unicast traffic.
5.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 can be obtained through the
five-tuple information of the packet, the application layer
identifier carried in the packet, AI intelligent recognition of
computing card, or deep packet inspection (DPI) technology. These
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)
Liu, et al. Expires April, 2025 [Page 7]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 2024
For example, identifying unicast service traffic that require
forwarding optimization based on the five-tuple information (SIP,
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.
5.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 April, 2025 [Page 8]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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 April, 2025 [Page 9]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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.
6. 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 April, 2025 [Page 10]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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.
6.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.
6.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 April, 2025 [Page 11]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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.
7. IANA Considerations
This document has no IANA actions.
8. Security Considerations
This document does not introduce new security considerations.
9. References
9.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, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[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,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling ", RFC
7450, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Liu, et al. Expires April, 2025 [Page 12]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 2024
[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, <https://www.rfc-editor.org/info/rfc8556>.
[RFC9026] Morin, T., Kebler, R., Mirsky, G., "Multicast VPN Fast
Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, April
2021, <https://www.rfc-editor.org/info/rfc9026>.
9.2. Informative References
TBD
10. Acknowledgments
The authors would like to thank the following for their valuable
contributions of this document:
TBD
Liu, et al. Expires April, 2025 [Page 13]
Internet-Draft Adaptive Unicast to Multicast Forwarding October 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 April, 2025 [Page 14]