Adaptive Unicast to Multicast Forwarding
draft-liu-mboned-adaptive-utom-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yisong Liu , Aijun Wang , Changwang Lin , Zheng Zhang , Yuanxiang Qiu , Yanrong Liang | ||
| Last updated | 2024-07-04 | ||
| RFC stream | (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-00
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, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[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>.
[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 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, <https://www.rfc-
editor.org/info/rfc8200>.
[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>.
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]