Network Working Group Y. Liu
Internet-Draft T. Jiang
Intended status: Informational China Mobile
Expires: January 29, 2023 Z. Li
Huawei Technologies
Z. Qin
China Unicom
July 28, 2022
Problem Satement of IPv6 Multicast Source Routing (MSR6)
draft-liu-msr6-problem-statement-00
Abstract
This document analyses the problem of the existing IPv6 multicast
solutions according to the usecases of MSR6. To solve these
problems, MSR6 can be used as a complementary 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 January 29, 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires January 29, 2023 [Page 1]
Internet-Draft Problem Statement of MSR6 July 2022
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. Problem Statement for Multicast in Large-scale Network . . . 3
3. Problem Statement for IPv6 Multicast with IPSec . . . . . . . 5
4. Problem Statement for IPv6 Host-initiated Multicast . . . . . 6
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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. The existing
multicast solutions request multicast tree-building on control plane
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, including SRv6, BIER, etc. Source
routing is able to reduce the state of intermediate nodes and
indicate multicast forwarding in the ingress nodes, which could
simplify multicast deployment. Source routing requires sufficient
flexibility on the forwarding plane and IPv6 has the advantage with
good scalability. Therefore, it is important to simplify multicast
deployment and meet high quality service requirements with IPv6
Source Routing based multicast.
The MSR6 will focus on use cases identified in
[I-D.liu-msr6-use-cases] with the following set of characteristics:
- Large network scale with numerous multicast service
- IPv6 multicast flow transmitting through Internet with requirement
of encryption
Liu, et al. Expires January 29, 2023 [Page 2]
Internet-Draft Problem Statement of MSR6 July 2022
- IPv6 Host Initiated or overlay Multicast Transport
According to these usecases this document analyses the problem of the
existing IPv6 multicast solutions under discussion in IETF. To solve
these problems, MSR6 can be used as a complementary multicast
solution.
2. Problem Statement for Multicast in Large-scale Network
In large network scale with numerous multicast service, there are
scalability issues if using existing multicast solutions.
Based on the MSR6 use case document, 2 typical scenarios are
considered as an example:
o Multicast for 5G transport, e.g., with1.5k egress nodes, 10k
multicast services;
o Multicast for DCN, e.g., with 3k switches, 60k links, 1k multicast
services;
If PIM/mLDP/P2MP RSVP-TE are used in these cases, per-flow state
protocols are used to set up multicast tree, which request period
state refresh and corresponding protocol message. Multicast stream
status are maintained in the intermediate nodes. When there are
thousands of concurrent multicast services, per-flow status will
bring scalability issues for network device, especially when the
multicast tree is dynamic.
BIER/BIER-TE([RFC8279]) is introduced in order to avoid explicit
multicast tree building and per flow status in intermediate nodes.
But there is challenge for BIER in a large scale network. Bit
position allocation for BIER is related to the scale of network
topology. The number of bit position affects BIFT size and bitstring
length directly. When there are too many egress nodes/links in the
network, encapsulation expanse and entry numbers of BITF could be
unacceptable. If Several SDs or SIs are divided, too many copies,
excessive traffic redundancy, similar to degradation to head-end
replication.
For example, if BIER defined is used for P2MP tunnel in the network,
bit position should be allocated for all egress nodes, i.e., 9k bit
positions for all possible leaves a. Most of the bit positions are 0
and only few of them are set in some sparse multicast example. In
this case, the BIER Header is inefficient and the encapsulation
expense is unacceptable. Considering that the number of bit position
also determines the BIFT entry size, forwarding speed may also be
affected.
Liu, et al. Expires January 29, 2023 [Page 3]
Internet-Draft Problem Statement of MSR6 July 2022
There are some possible methods to improve the situation in BIER.
For example "set" could be used to save the cost of bit position, but
multiple packets are supposed to be sent when the BFR-ID of the
receivers belong to different set. And when the network size is
large, the usefulness of set is not obvious. In the case showed
above, even 10 Sets are planned, there needs about 9 hundreds bit
positions for each packet and different set requests different BIFTs
in each node.
In BIER-TE, bitstring need to carry bits to indicate not only the
receiving BFER but also the intermediate hops/links across which the
packet must be sent. For the most common case, bit position should
be allocated for all adjacencies. About 100k bit positions are
requested. The bit position representing adjacencies that the
multicast tree goes through are set and the rest of the bit positions
are set to 0. In the example above, 7 bit positions are set in the
bitstring. BIER-TE header is less efficient and the encapsulation
expense is more significant,even compared to BIER. Also controller
is supposed to allocate different BIFTs for 10k nodes;
Some methods defined in BIER-TE is introduced to improve the
situation. "Set" could also be used, but not enough as the analysis
above. There are some other methods for reducing the number of
required bits, such as unicast (forward_routed()), ECMP() or flood
(DNC) over "uninteresting" sub- parts of the topology, which brings
different kinds of limitation for path planning.
Since the exiting BIER/BIER TE cannot satisfy the requirement of
multicast in the large-scale network, it need to introduce the new
source-routing-based solutions for the multicast TE. There can be
possible solutions defined in the drafts. It need to introduce the
new source-routing-based solutions for the multicast . There can be
possible solutions defined in the existing drafts. The basic idea is
combination of RH Segment list and bistring to specify the multicast
path. The existing BIER header cannot satisfy the requirement of
encapsulating such information. Instead IPv6 Route Header combining
with other IPv6 extension header can serve the purpose well. The
possible encapsulation is shown in the following figure.
+--------------------------------+ ---
| IPv6 Header |
+--------------------------------+ IPv6 Multicast TE Tunnel Header
|IPv6 RH (Segment List/Bitstring)|
+--------------------------------+ ---
| Payload |
+--------------------------------+
Liu, et al. Expires January 29, 2023 [Page 4]
Internet-Draft Problem Statement of MSR6 July 2022
3. Problem Statement for IPv6 Multicast with IPSec
In the typical scenario like IPv6-based SDWAN, the multicast traffic
may traverse the Internet through the IPv6-based multicast tunnel.
At the same time the traffic must be encrypted for the purpose of
security. IPSec can be adopted for encryption.
The independent layer design of BIER brings the following challenges:
Option 1: If the IPv6 IPSec extension header is used for the reason
of security (shown in the following figure), the BIER header will be
encrypted and the traffic steering information cannot be acquired by
the BIER nodes. That is, the BIER cannot work in this option.
+--------------------------------+ ---
| IPv6 Header | ^
+--------------------------------+ |
| IPv6 IPSec Header (ESP & AH) | IPv6 Multicast Tunnel Header
+--------------------------------+ |
| BIER Header | |
+--------------------------------+ ---
| Payload |
+--------------------------------+
Option 2: In order for BIER Header to work while implement the
security function, a new security header may have to be introduced
for the BIER layer (shown in the following figure). This means: 1)
that the existing IPv6 IPSec extension header cannot be reused; 2)
There can be conflicted functions in the two layers: IPv6 layer and
BIER layer.
+--------------------------------+ ---
| IPv6 Header | ^
+--------------------------------+ |
| BIER Header | IPv6 Multicast Tunnel Header
+--------------------------------+ |
| New Security Header | |
+--------------------------------+ ---
| Payload |
+--------------------------------+
For MSR6, which is designed based on native IPv6, it is allowed to
reuse IPv6 Authentication header and Encapsulating Security Payload
header. If MSR6 is used in this case, the packet is supposed to
encapsulated as the following to implement end to end multicast
security:
Liu, et al. Expires January 29, 2023 [Page 5]
Internet-Draft Problem Statement of MSR6 July 2022
+--------------------------------+ ---
| IPv6 Header | ^
+--------------------------------+ |
| IPv6 EH (MSR6 EH or Options) | IPv6 Multicast Tunnel Header
+--------------------------------+ |
| IPv6 IPSec Header (ESP & AH) | |
+--------------------------------+ ---
| Payload |
+--------------------------------+
Just as IPsec, there are other existing functionalities that have
been in IETF based on IPv6, for example fragmentation, network
slicing, IOAM etc., which could all be reused in MSR6 which is based
on IPv6 data plane. Comparingly, it has to be defined again if these
functions/header are supposed to be used in BIER, which brings
redundancy.
4. Problem Statement for IPv6 Host-initiated Multicast
In the IPv6 host-initiated multicast scenarios, the host will
originate the IPv6 packet to be replicated for the different leaf
hosts. The packet originated by the host may have the format shown
in the following figure. The packet has the encapsulation of IP
layer and Transport Layer.
+--------------------------------+ ---
| IPv6 Header | IP Layer
+--------------------------------+ ---
| UDP Header | Transport Layer
+--------------------------------+ ---
| Payload |
+--------------------------------+
If BIER is adopted for the multicast traffic steering, the
independent layer design of BIER may make the packet originated by
the host as follows. This violates the layer architecture of the
Internet, that is, it introduces an extra layer (BIER layer). This
does not work in the host.
+--------------------------------+ ---
| IPv6 Header | IP Layer
+--------------------------------+ ---
| BIER Header | BIER Layer
+--------------------------------+ ---
| UDP Header | Transport Layer
+--------------------------------+ ---
| Payload |
+--------------------------------+
Liu, et al. Expires January 29, 2023 [Page 6]
Internet-Draft Problem Statement of MSR6 July 2022
For MSR6, multicast traffic steering information will be encapsulated
in the IPv6 extension header shown in the following figure. It can
still maintain the layer architecture of the Internet.
+--------------------------------+ ---
| IPv6 Header |
+--------------------------------+ IP Layer
| IPv6 EH (MSR6 EH or Options) |
+--------------------------------+ ---
| UDP Header | Transport Layer
+--------------------------------+ ---
| Payload |
+--------------------------------+
Besides, multicast source routing requests no explicit multicast tree
set up protocols. The network device replicates and forwards the
packet just based on the MSR6 header encapsulated by the host.
5. Summary
In summary, in order to satisfy the requirements of the usecases
characterized as follows,
- Large network scale with numerous multicast service
- IPv6 multicast flow transmitting through Internet with requirement
of encryption
- IPv6 Host Initiated or overlay Multicast Transport
according to the analysis of problems of the existing multicast
solutions, MSR6 solution should be introduced to take the advantages
of IPv6 extension header to encapsulate the extensible multicast
traffic steering information and reuse the existing IPv6
encapsulations of the functionalities like IPSec. There can be
unified encapsulation for the IPv6 tunneled packet and the IPv6 host
initiated packet. The abstract MSR6 header is shown in the following
figure:
+--------------------------------+
| IPv6 Header |
+--------------------------------+
|IPv6 RH (Segment List/Bitstring)|
+--------------------------------+
| IPv6 EH (Multicast Options) |
+--------------------------------+
| IPv6 IPSec Header (ESP & AH) |
+--------------------------------+
Liu, et al. Expires January 29, 2023 [Page 7]
Internet-Draft Problem Statement of MSR6 July 2022
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
TBD
8. Acknowledgements
TBD
9. Normative References
[I-D.cheng-spring-ipv6-msr-design-consideration]
Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C.
Fan, "Design Consideration of IPv6 Multicast Source
Routing (MSR6)", draft-cheng-spring-ipv6-msr-design-
consideration-01 (work in progress), October 2021.
[I-D.liu-msr6-use-cases]
Liu, Y., Yang, F., Wang, A., Zhang, X., Geng, X., and Z.
Li, "MSR6(Multicast Source Routing over IPv6) Use Cases",
draft-liu-msr6-use-cases-01 (work in progress), July 2022.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc8279>.
[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, <https://www.rfc-editor.org/info/rfc8296>.
[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,
<https://www.rfc-editor.org/info/rfc8663>.
Liu, et al. Expires January 29, 2023 [Page 8]
Internet-Draft Problem Statement of MSR6 July 2022
Authors' Addresses
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Tianji Jiang
China Mobile
1525 McCathy Blvd.
Milpitas,, CA 95035,
United States of America
Email: tianjijiang@chinamobile.com
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Zhuangzhuang Qin
China Unicom
Email: qinzhuangzhuang@chinaunicom.cn
Liu, et al. Expires January 29, 2023 [Page 9]