Internet DRAFT - draft-eckert-msr6-rbs
draft-eckert-msr6-rbs
PIM T. Eckert
Internet-Draft Futurewei Technologies USA
Intended status: Standards Track X. Geng
Expires: 27 April 2023 X. Zheng
R. Meng
F. Li
Huawei 2012 NT Lab
24 October 2022
Recursive Bitstring Structure (RBS) for Multicast Source Routing over
IPv6 (MSR6)
draft-eckert-msr6-rbs-01
Abstract
This document defines an encoding and corresponding packet processing
procedures for native IPv6 multicast source routing (MSR6) using a
so-called "Recursive Bitstring" (RBS) address structure.
The RBS address structure encodes the source-routed multicast tree as
a tree of bitstrings. Each router on the tree only needs to examine
and perform replication for the one bitstring destined for it.
The MSR6/RBS IPv6 extension header encoding and processing is modeled
after that of unicast source routing headers, RFC6554 and RFC8754,
and shares all elements that can be shared. To support the RBS
structure, it is replacing the "Segments Left" pointer to the next
segment with two fields to point to the next sub-tree to parse.
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 27 April 2023.
Eckert, et al. Expires 27 April 2023 [Page 1]
Internet-Draft msr6-rbs October 2022
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Forwarding overview . . . . . . . . . . . . . . . . . . . 4
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. RBS-Address . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. RBS-BIFT . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Multicast Source Routing (MSR6) Header with RBS
Sub-type . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. MRH extension header (refresher) . . . . . . . . . . 9
2.4. MRH Sub-Type specific data for RBS . . . . . . . . . . . 9
2.5. MRS6/RBS processing . . . . . . . . . . . . . . . . . . . 11
2.5.1. MSIR header creation . . . . . . . . . . . . . . . . 11
2.5.2. Common processing . . . . . . . . . . . . . . . . . . 11
2.5.3. MSER header processing . . . . . . . . . . . . . . . 11
2.6. MSR processing of RBS-Address . . . . . . . . . . . . . . 12
2.6.1. MSR processing of receive adjacency . . . . . . . . . 12
2.6.2. MSR per-hop processing . . . . . . . . . . . . . . . 12
3. MSR/RBS forwarding Pseudocode . . . . . . . . . . . . . . . . 14
4. IANA requests . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Background / Explanations . . . . . . . . . . . . . 20
A.1. Evolution from draft-xu-msr6-rbs . . . . . . . . . . . . 20
A.1.1. RBS-Offset/RBS-Length . . . . . . . . . . . . . . . . 20
A.1.2. Type-specific data encoding . . . . . . . . . . . . . 20
A.1.3. IP Multicast compatibility . . . . . . . . . . . . . 21
A.1.4. Terminology . . . . . . . . . . . . . . . . . . . . . 21
A.1.5. Text changes . . . . . . . . . . . . . . . . . . . . 21
Eckert, et al. Expires 27 April 2023 [Page 2]
Internet-Draft msr6-rbs October 2022
A.2. Comparison with RBS for BIER . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Overview
1.1. Introduction
Eliminating hop-by-hop per-multicast-tree state in the forwarding
plane as well as the per-hop, per-tree control plane complexity that
goes along with it has long since been a concern against the
deployment of multicast services. Short of MSR6, there are no IETF
standardized mechanisms to enable this with native hop-by-hop IPv6
forwarding according to [RFC8200] and per-hop stateless replication.
"Multicast Source Routing over IPv6" (MSR6), is such a stateless,
native IPv6 forwarding based multicast source routing (MSR6)
solution, defined in
[I-D.cheng-spring-ipv6-msr-design-consideration].
MSR6 intends to be compatible with and reuse all the IPv6 mechanisms
introduced by prior stateless hop-by-hop native IPv6 unicast
forwarding, including [RFC6554] (IPv6 Source Routing Header for
networks using RPL routing), and [RFC8754] (IPv6 Segment Routing
Header for SRv6). The MSR6 extension header and semantic shares as
much as possible with these unicast approaches. It especially
attempts to allow introducing MSR6 as the multicast extension to for
the IPv6 Segment Routing architecture called SRv6 ([RFC8402] and
[RFC8986]).
MSR6 considers two basic modes of forwarding: one is based on
Shortest Path First(SPF). In this mode, the tree only encodes tree
leaves in the extension header, but no traffic steering. This is
called MSR6 BE mode. The other mode is based on path steering with
replication, which is called MSR6 TE mode.
[I-D.geng-msr6-traffic-engineering], [I-D.chen-pim-srv6-p2mp-path]
and [I-D.geng-msr6-rlb-segment] have introduced structured segment
lists in support of MSR6 TE mode.
This document proposes a variant of an MSR6 extension header that
uses the "Recursive Bitstrings" (RBS) address structure to encode the
source-routed multicast tree as a tree of bitstrings, in support of
MSR6 TE mode. Each router on the tree only needs to examine and
perform replication for the one bitstring encoded in the RBS-Address
for that MSR.
Eckert, et al. Expires 27 April 2023 [Page 3]
Internet-Draft msr6-rbs October 2022
The logic of MSR6/RBS replication and tree representation is derived
(and simplified) from the BIER-TE [RFC9262] architecture. The RBS
address structure replaces a single, end-to-end "flat" bitstring used
in BIER-TE. This eliminates the scalability and controller-plane
complexity of BIER-TE.
Likewise, MSR6/RBS forwarding is based on the architecture specified
in [I-D.eckert-bier-cgm2-rbs]. Because this document intends to only
specify the forwarding specification, it does not cover the system
architecture details. Please refer to [RFC9262] and
[I-D.eckert-bier-cgm2-rbs] for system level details, such as
scalability and complexity comparisons.
A comparison between this document and [I-D.xu-msr6-rbs] and
[I-D.eckert-bier-cgm2-rbs] is given below in Appendix A.
1.2. Forwarding overview
In MSR6/RBS, routers are IPv6 MSR6 Segment Routers (MSR). An ingress
MSR (MSIR) forms an IPv6 packet and includes a Multicast Source
Routing Header (MRH) that uses the RBS format. The MRH controls the
steering and replication of the packet across one or more MSR6
Segment Routers (MSR), terminating the packet in one or more egress
MSR (MSER).
Note that the terms MSR, MSIR and MSER are chosen to be replicating
the terms BFR, BFIR and BFER used for equivalent router roles in BIER
[RFC8279] and BIER-TE [RFC9262]. BIER and BIER-TE are based on a
separate L2.5 forwarding mechanism and encapsulation, optimized for
MPLS networks (see [RFC8296]).
Figure 1 shows an example network topology and an example multicast
tree. R1 has connections to connections to R2, R3, R4, R5 (not
shown) and R6. For the purpose of explaining RBS, it is irrelevant
whether those connections are separate L2 point-to-point links, links
or adjacencies on a shared LAN. Likewise, R3 has connections to R1,
R7, R8, R9 and R10, R4 has connections to R1, R7, R8, R8 and R10, and
and R9 has connections to R3, R4, and some additional unnamed MSR.
Eckert, et al. Expires 27 April 2023 [Page 4]
Internet-Draft msr6-rbs October 2022
+---+
|R1 | (MSIR)
+-+-+
.
....................................
... . . ....
| | | |
+-v-+ +-v-+ +-v-+ +-v-+
| R2| (MSER) |R3 | (MSR) |R4 | (MSR/ |R6 | (MSER)
+-+-+ +---+ +---+ MSER) +---+
. ...... .
............. ............
... . . ....
| | | |
+-v-+ +-v-+ +-v-+ +-v-+
|R7 | (MSER) |R8 | |R9 | (MSR) |R10| (MSER)
+-+-+ +---+ +---+ +---+
.
.....
.... more MSR...
Figure 1: Example Topology/RBS tree
R1 wants to send a packet that is to be received by R2, R4, R6, R7,
R10 and some MSER behind R9. Given how R7, R8, R8, R10 and the MSR
behind R9 can be reached via both either R3 and R4, there is a packet
steering and replication (traffic engineering) choice to be made: R3
should forward and replicate to R8 and R8, and R4 should replicate to
to R9 (to reach the msr behind it, and R10.
Every MSR has an RBS "Bit Index Forwarding Table" (RBS-BIFT) that
defines which BitPosition (BP) (1..N) indicates which adjacency.
Figure 2, shows the example RBS-BIFT for R1.
Eckert, et al. Expires 27 April 2023 [Page 5]
Internet-Draft msr6-rbs October 2022
+--+-------+----------+
|BP|R Flag | Adjacency|
+--+-------+----------+
| 1| 0| receive|
+--+-------+----------+
| 2| 0| R2 |
+--+-------+----------+
| 3| 1| R3 |
+--+-------+----------+
| 4| 1| R4 |
+--+-------+----------+
| 5| 0| R5 |
+--+-------+----------+
| 6| 0| R6 |
+--+-------+----------+
Figure 2: BIFT on R1
The receive adjacency is the bit position indicating that the packet
is destined for the router itself. The R)ecursive flag indicates
whether the adjacency is an intermediate MSR that acts as a
replication point to further MSR. If an MSR is never a transit but
can always only be a leaf in a multicast distribution tree, then R=0.
This allows for more compact encoding of the RBS address structure.
In the example, R2, R5 and R6 are connected to R1 and also leaf
router in the topology, hence they have R=0 in the R1 RBS-BIFT.
When a router receives and processes an IPv6 packet with an MRH that
uses the RBS address structure, the router needs to only act upon the
"RecursiveUnit" (RU) within that address structure destined to it.
+---------------------+
| RecursiveUnit (RU) |
+---------------------+
. .
..... ................
. .
+-----------+-----+ +--------+---+ +----+
| Bitstring | AF1 | ... | AF(n-1)|RU1| ... |RU N|
+-----------+-----+ +--------+---+ +----+
Figure 3: Structure of Recursive Unit
As shown in Figure 3, a Recursive Unit (RU) starts with the Bitstring
for the MSR to which this RU is intended. In the example, the first
MSR is R1, so the Bitstring in the RU is as shown in Figure 4
Eckert, et al. Expires 27 April 2023 [Page 6]
Internet-Draft msr6-rbs October 2022
1 2 3 4 5 6
+-+-+-+-+-+-+
|0|1|1|1|0|1|
+-+-+-+-+-+-+
Figure 4: Bitstring for R1 in the example
When an MSR processes its RU, the length of the BS is derived from
the length of the BIFT. In the case of R1 it is therefore known to
be 6 bits long.
To support replication via intermediate MSR, the RBS address
structure needs to contain for each of those MSR a separate RU. In
the example, the packet is to be further replicated by R3 and R4 and
then further on by R9.
The RU for R1 therefore needs to contain two further RU, one for R3
and one for R4. The one for R4 will also need to contain RUs for the
MSR below it.
When creating packet copies to R3 and R4, R1 needs to rewrite the MRH
such that R3 and R4 will find their respective RU. Therefore, R1
needs to be able to parse its own RU such that it can locate those
further RU for R3 and R4. This is supported by the AddressFields
(AF) following the BS. Each AF indicates the length of one RU that
follows.
When N (in the example N=2) RU follow, only N-1 (in the example 1) AF
are needed, because the length of the N'th RU can be calculated from
the length of the RU minus the sum of the length of the other RU as
indicated in the N-1 AF.
1 2 3 4 5 6
+-+-+-+-+-+-+-..-+...+...+
|0|1|1|1|0|1|AF1 |RU1|RU2|
+-+-+-+-+-+-+-..-+...+...+
Figure 5: RU for R1
In result, the RU for R1 looks as shown in Figure 5. It has the
aforementioned 6-bit long Bitstring because the BIFT of R1 is 6 BP
long, it has one AF1 indicating the length of RU1, which is the RU
for the first set BP in the Bitstring with R=1, so it is for R3, and
the RU finishes with RU2 for the second BP in the BS with R=1, so it
is for R4.
2. Specification
Eckert, et al. Expires 27 April 2023 [Page 7]
Internet-Draft msr6-rbs October 2022
2.1. RBS-Address
As shown in Figure 3 and explained in Section 1.2, an RBS address
consists of the RU for the first MSR of a tree and is composed of a
Bitstring for this MSR, the AddressFields for all but the last bits
(N-1) set in that Bitstring with R=1 flag in the BIFT, followed by N
RU for each of those bits, which are recursivly composed in the same
way.
The RU for any MSR only needs to be decoded (in high-speed hardware)
by the MSR itself, but not any other MSR (along the path/tree).
Creation of an MSR is assumed to be part of application/network stack
on hosts or router control plane software and is therefore assumed to
be able to support arbitrary formats of the AF fields, as long as
there is a standard data model (e.g.: YANG) and/or control plane
protocol specification (e.g.: OSPF or ISIS extensions) for it.
specifically, different router (MSR) implementations may choose to
support different AF formats.
Any MSR MUST support to decode RU where the AF entries are 8 bit in
size. Any MSR SHOULD support to decode a variable length AF
encoding, where 0XXXXXXX (8-bit length AF field) is used to encode a
7-bit XXXXXXX (0..127) values, and where 1XXXXXXXXXXXX is used to
encode an 12-bit value XXXXXXXXXXX.
Note that in the MSR/RBS IPv6 extension header, the RBS-Address can
be as long as 256 bytes. Therefore, non-support of any AF field not
supporting to indicate RU lengths as long as 2048 bit may not allow
to build maximum size MSR/RBS extension headers.
2.2. RBS-BIFT
RBS-BIFT are composed as explained in Section 1.2. Their size can be
any number of entries from 2 to 1024 bits (2^10), resulting in equal
length Bitstrings for the MSR in an RBS-Address.
The leftmost bit in an RBS RU Bitstrings is BIFT entry 1.
The adjacency is an IPv6 link-local, ULA or global IPv6 unicast
address of the next-hop assigned to the BitPosition. Further
requirements are explained in Section 2.6.
2.3. Multicast Source Routing (MSR6) Header with RBS Sub-type
Eckert, et al. Expires 27 April 2023 [Page 8]
Internet-Draft msr6-rbs October 2022
2.3.1. MRH extension header (refresher)
The "Multicast Routing Header" (MRH) is a new [RFC8200] IPv6 routing
header defined according to [I-D.geng-msr6-traffic-engineering] as
follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRH Sub-Type | MRH Sub-Type specific data |
+-+-+-+-+-+-+-+-+ //
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value (TLV) objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MRH format
Next Header: Defined in [RFC8200], section 4.4 (Type of the next
header following so that it can be correctly parsed).
Hdr Ext Len: Defined in [RFC8200], section 4.4 (Length of the
extension header in octets, not counting the first 8 octets).
Routing Type: Code point to be allocated (TBD1) for the RBS Sub-type
for MRH (as part of a registry to be established for the MRH).
Segments Left: Filled with segments left according to [RFC8200],
section 4.4, see Section 2.5.2.
The "Optional TLV objects" are intended to encode applicable TLV from
SRH [RFC8754] or multicast/MRH specific TLVs. Examination of these
TLV is based on their semantic. Current TLV defined in conjunction
with [RFC8754] are examined upon reception of a packet, but not when
forwarding the packet from one segment to another. In case of RBS,
reception is triggered either by Segments Left being 0, or when
parsing the Bitstring and acting upon the BP that is indicating the
receive adjacency.
The RBS Sub-Type specific data contains the RBS address structure as
follows.
2.4. MRH Sub-Type specific data for RBS
Eckert, et al. Expires 27 April 2023 [Page 9]
Internet-Draft msr6-rbs October 2022
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(MHR Sub-type) | RU-Length | RU-Offset .. |S|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MSER-Segment (128 bit IPv6 address) |
| (optional based on S=1) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RU0L |^ Recursive Unit 0 (RU0) ... //
+-+-+-+-+-+ (RBS-Address) //
// ... //
// ....+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MRH Sub-type specific data for RBS (RBS-Address)
RBS-Address is the Recursive Unit as it is to be processed by the
MSIR. It contains (as explained above recursively all the RU for MSR
along the tree for this packet. Processing the complete RBS tree
encoded across multiple MSR is defined here to be as processing a
single End.RBS segment.
padding extends the RBS-Address field to 32-bit alignment. RU0L is
the number of 32-bit units occupied by (RU0L, RBS-Address, padding).
MSER-Segment is a segment to be processed by MSER after the End.RBS
segment. S is a flag that MUST be set to 1 when the MSER-Segment is
present, else it MUST be set to 0. R is a reserved bit (MUST be
ignored upon reception).
RU-Length (RecursiveUnit Length) is the length of the Recursive Unit
to be examined by the processing MSR. It is counted in bits. Given
how [RFC8200] Hdr Ext Len only allows for up to 255 bytes, RU-Length
can at most be only 11 bits long.
RU-offset (Recursive Unit Offset) is the offset in bits of the
Recursive Unit to be examined by the processing MSR, where 0 is the
first bit of RBS-Address.
RU-Length and RU-offset are mutable, all other fields are immutable.
Eckert, et al. Expires 27 April 2023 [Page 10]
Internet-Draft msr6-rbs October 2022
2.5. MRS6/RBS processing
[TBD: This section may need to be re-written with more formalistic
language if the pseudocode (see below) is not a preferred formal
description.]
2.5.1. MSIR header creation
Upon creation of the RBS header with an RBS-Address, RU-Length is set
to the length of the RBS-Address, and RU-offset is set to 0.
MSER-Segment is included when the packet is an IPv6 multicast packet.
In this case, the MSER-Segment carries the IPv6 Destination
(multicast group) Address. The MSER-Segment MAY also contain any non
IPv6 multicast group address when it has been defined/signaled
accordingly as a SID for processing by all MSER that could
potentially receive it. S is set according to the presence of MSER-
Segment.
Segments Left is set to 2 if MSER-Segment is included, otherwise it
is set to 1.
2.5.2. Common processing
When the MSR6/RBS header is received, including by the creating MSIR,
the need to process the RBS-Address (End.RBS segment) is examined.
This is the case when (Segments Left - 1) = 1. See below for further
details. When the End.RBS is not to be processed, then the MSR it
needs to act upon the header as an MSER.
2.5.3. MSER header processing
An MSER examines the presence of MSER-Segment (according to S). If
present, and if MSER-Segment carries an IPv6 multicast address then
the MSER copies the IPv6 multicast address into IPv6 Destination
Address field, discards the MSR6/RBS extension header and proceeds
with processing of the packet as an IPv6 multicast packet.
Note that non withstanding the previous paragraphs behavior, host
stacks SHOULD maintain a copy of the MSR6/RBS extension header data
so that socket / application code can retrieve for advanced
functionality, such as identifying the path taken, as desirable for
resilient transmission.
If the MSER-Segment is not an IPv6 multicast address, the packet is
NOT an IPv6 Multicast packet and MUST NOT be further processed as an
IPv6 Multicast Packet. Instead, the address MUST be accordingly
registered as a SID by the control plane and further processing of
Eckert, et al. Expires 27 April 2023 [Page 11]
Internet-Draft msr6-rbs October 2022
the MSR6/RBS header is subject to the definition of the SID. If the
address does not match a registered SID, the packet MUST be discarded
and an error be raised.
If the MSER-Segment is not present, the router MUST remove the MSR6/
RBS extension header and proceed processing with "receiving" the
packet with the next header.
2.6. MSR processing of RBS-Address
When an MSR received a packet with MSR6/RBS extension header in which
it needs to process the RBS-Address (End.RBS segment), it MUST first
validate that the IPv6 Destination Address is a SID with End.RBS
function.
It MUST be a link-local, ULA or global address on the router not used
for any other functions (IPv6 unicast, Segment Routing). The ability
to send packets to such addresses with End.RBS functions MUST be
tightly controlled in the network to prohibit the ability of
unauthorized senders to cause packet replication attacks by sending
of packets with MSR6/RBS headers.
These requirements logically apply equally to the generating router
(MSIR), but can of course appropriately be optimized in
implementation.
After this ingress check, the MSR parses the RBS-Address field
starting at RU-Offset, taking the RU-Length as a known parameter into
account. This subset of the RU-Address is the RU for this MSR.
Parsing is shown in more detail in Section 3.
Upon parsing, the MSR creates a packet copy for every BP set in
Bitstring and rewrites it according to the following rules. It
finally discards the received packet.
2.6.1. MSR processing of receive adjacency
Packet copies for a receive adjacency have their Segments Left
reduced by 1 and then passed to MSER processing Section 2.5.3.
2.6.2. MSR per-hop processing
Per-hop processing of packets with MSR6/RBS extension header that
include an MSER-Segment with an IPv6 multicast address are IPv6
multicast packets. In result, they inherit all per-hop IPv6
forwarding rules of [RFC8200], processing of any additional industry
common per-hop rules for IPv6 multicast packets (as desirable by
implementations), and additional per-hop applicable IPv6 extension
Eckert, et al. Expires 27 April 2023 [Page 12]
Internet-Draft msr6-rbs October 2022
headers.
For example, the IPv6 header Hopcount field is reduced on every hop,
and the packet discarded if Hopcount reaches 0.
For example, routers/operators along the path may choose to support
filtering of MSR6/RBS packets based on their IPv6 multicast
destination address in the MSER-Segment field. Or perform IPFIX
accounting against those addresses.
For example (TBD): For ECMP situations, the IPv6 Flow Label is used
to choose a next-hop adjacency. This can include BIFT adjacencies
that include multiple next-hop addresses/interfaces.
If the MSER-Segment is not present, or not carrying an IPv6 Multicast
address, more liberty can be taken wrt. processing rules, especially
through definition of additional SID Functions for MSER-Segment.
2.6.2.1. MSR processing for R=0 adjacency
Packet copies for for an adjacency to an MSR neighbor with R=0 have
their Segments Left reduced by 1. RU-Length and RU-Offset SHOULD be
set to 0.
The MSR neighbor IPv6 address/SID from the BIFT entry is copied into
the IPv6 Destination Address field and the packet is forwarded (via
IPv6 unicast forwarding procedures).
The MSR MUST only permit IP6 addresses in the RBS-BIFT for R=0/R=1
entries that have the End.RBS function.
2.6.2.2. MSR processing for R=1 adjacency
The MSR calculates new values for RU-Offset and RU-Length for a copy
to an MSR neighbor with R=1. It updates the RU-Offset, RU-Length
field in the MSR type-specific field for RBS.
The MSR neighbor IPv6 address/SID from the BIFT entry is copied into
the IPv6 Destination Address field and the packet is forwarded (via
IPv6 unicast forwarding procedures).
The MSR MUST only permit IP6 addresses in the RBS-BIFT for R=1
entries that have the End.RBS function.
Eckert, et al. Expires 27 April 2023 [Page 13]
Internet-Draft msr6-rbs October 2022
3. MSR/RBS forwarding Pseudocode
The following example RBS forwarding Pseudocode assumes the reference
encoding of bit-accurate length of Bitstrings and RecursiveUnits as
well as 8-bit long TotalLen and AddressingField Lengths. All packet
field addressing and address/offset calculations is therefore bit-
accurate instead of byte accurate (which is what most CPU memory
access today is).
void ProcessMSR6header(Packet)
{
MSR6 = GetPacketMSR6Header(Packet);
case (MSR6.MRHSubType)
RBS) ProcessRBSSubtype(Packet); break
// ... other MSR6 subtypes
esac
}
void ProcessRBSSubtype(Packet)
{
MSR6 = GetPacketMSR6Header(Packet);
RBS = MSR6.MRHSubType
if(MSR6.RULength == 0) return ReceiveRBSsubtype(Packet)
RU0 = RBS + 29 + (MSR6.S ? 128 : 0)
RU = RU0 + MSR6.RUOffset
RUL = MSR6.RULength
BitstringA = MSR6.RUOffset
AddressingField = BitstringA + BIFT.entries;
// [1] calculate number of recursive bits set in Bitstring
CopyBitstring(*BitstringA, *RecursiveBits, BIFT.entries);
And(*RecursiveBits,*BIFTRecursiveBits, BIFT.entries);
N = CountBits(*RecursiveBits, BIFT.entries);
// Start of first RecursiveUnit in RBS address
// After AddressingField array with 8-bit length fields
RecursiveUnit = AddressingField + (N - 1) * 8;
RemainLength = *(RBS.RULength);
Index = GetFirstBitPosition(*BitstringA);
while (Index) {
PacketCopy = Copy(Packet);
if (BIFT.BP[Index].adjacency == receive)
ReceiveRBSsubtype(PacketCopy)
next;
Eckert, et al. Expires 27 April 2023 [Page 14]
Internet-Draft msr6-rbs October 2022
}
RBSc = RBS - Packet + PacketCopy
MSR6c = MSR6 - Packet + PacketCopy
If (BIFT.BP[Index].recursive) {
if(N == 1) {
RecursiveUnitLength = RemainLength;
} else {
RecursiveUnitLength = *AddressingField;
N--;
AddressingField += 8;
RemainLength -= RecursiveUnitLength;
RemainLength -= 8; // 8 bit of AddressingField
}
*(RBSc.RUOffset) = RecursiveUnit - RU0
*(RBSc.RULength) = RecursiveUnitLength
RecursiveUnit += RecursiveUnitLength;
} else {
*(RBSc.RUOffset) = 0
*(RBSc.RULength) = 0
*(MSR6c.SegmentsLeft) -= 1
}
*(PacketCopy.IPv6hdr.DA) = *(BIFT.BP[Index].adjacency)
// ProcessMSR6TLV(Packet) - needed ?
IPv6Forward(PacketCopy)
Index = GetNextBitPosition(*BitstringA, Index);
}
}
void ReceiveRBSsubtype(Packet)
{
MSR6 = GetPacketMSR6Header(Packet);
RBS = MSR6.MRHSubType
if(MSR6.S) {
*(Packet.IPv6hdr.DA) = *(RBS.MSETSegment)
*(MSR6c.SegmentsLeft) = 0
}
ProcessMSR6TLV(Packet)
// header not needed any further except for diagnostics
// DisposeMSR6Header(Packet)
if(IsIPv6MulticastAddr(Packet.IPv6hdr.DA))
ReceiveIpv6Multicast(Packet)
else
ProcessSRv6DASID(Packet)
}
Figure 8: RBS forwarding Pseudocode
Eckert, et al. Expires 27 April 2023 [Page 15]
Internet-Draft msr6-rbs October 2022
Explanations for Figure 8.
ProcessMSR6header(Packet) is called upon receipt of an IPv6 packet
with an MSR6header. It is preceded by (not shown) standard IPv6
processing of a packet destined to an address of the node (such as
HopCount processing), and other common processing of a Routing
Header. This function only demultiplexes into the MSR6 option
specific code.
ProcessRBSSubtype(Packet) processes the RBS option header. All
address pointers shown use bit accurate addressing, because the
elements of the RU are at bit-accurate offsets.
MSR6 is the address of the MSR6 extension header in the packet, RBS
is the address of the RBS address in the packet.
BitstringA is the address of the RBS address Bitstring in memory.
Other variables use names matching those from the packet header
figures (without " -_").
The BFR local BIFT has a total number of BIFT.entries addressable BP
1...BIFTentries. The Bitstring therefore has BIFT.entries bits.
BIFT.RecursiveBits is a Bitstring pre-filled by the control plane
with all the BP with the recursive flag set. This is constructed
from the Recursive flag setting of the BP of the BIFT. The code
starting at [1] therefore counts the number of recursive BP in the
packets Bitstring.
Because the AddressingField does not have an entry for the last (or
only) RecursiveUnit, its length has to be calculated By subtracting
the length of the prior N-1 RecursiveUnits from RULength. This is
done via variable RemainLength.
For every PacketCopy that is to be forwarded, the RU-Length, RU-
Offset and IPv6 header DestinationAddress (DA) field are updated.
For non-recursive adjacencies, the SegmentsLeft field is also
updated.
For packet copies that are to be received by this node, The DA is
updated from the RBS MSER-Segment field when present, and depending
on what type of address it is, the packet continues to be processed
as a received IPv6 Multicast packet or SRv6 SID.
4. IANA requests
This specification requests a TBD1 code point within a TBD registry
of MRH extension header options.
Eckert, et al. Expires 27 April 2023 [Page 16]
Internet-Draft msr6-rbs October 2022
5. Security considerations
The specification painstakingly attempts to ensure that IPv6
addresses used to deliver MSR6/RBS extension header packets are ONLY
used for such packets such that common IPv6 "clamshell" filtering of
address ranges can ensure that no unauthenticated sender (such as
from outside the domain) can send packets to these addresses.
5.1. Changelog
[RFC-Editor: please remove this section].
This document is written in https://github.com/cabo/kramdown-rfc2629
markup language. This documents source is maintained at
https://github.com/toerless/multicast-rbs, please provide feedback to
the msr6@ietf.org mailing list and submit an Issue to the GitHub.
00 - initial version
01 - This version only adds this note to explain the updated intent
of this document: [I-D.eckert-bier-rbs] is a new draft that described
the RBS structure and its processing as introduced in this document,
but independent of the MSR6 specific components. Instead, the goal
of [I-D.eckert-bier-rbs] is to represent RBS in a way that allows it
to be embedded in different stateless forwarding solutions,
specifically MSR and/or BIER. For this purpose, it has only small
chapters outlining how such embedding can be done. Note that the
name of this draft does not indicate a firm choice of preferred
working group for that work.
This document instead is pending a rewrite where the explicit RBS
text is replaced by text explaining how different MSR6 BE or TE
solution options (including but not limited to RBS) can be embedded
into the presented common MSR6 header. The core element of this
draft then is to be the inclusion of an IPv Multicast address
"destination" segment (as compared to prior common MSR6 header
drafts. These changes are pending and could just not be finished
before IETF115 publication deadline.
6. Acknowledgments
Many thanks for Bing Xu (bing.xu@huawei.com) for editorial work on
the prior variation of this work [I-D.xu-msr6-rbs].
7. References
7.1. Normative References
Eckert, et al. Expires 27 April 2023 [Page 17]
Internet-Draft msr6-rbs October 2022
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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,
<https://www.rfc-editor.org/info/rfc8986>.
7.2. Informative References
[I-D.chen-pim-srv6-p2mp-path]
Chen, H., McBride, M., Fan, Y., Li, Z., Geng, X., Toy, M.,
Mishra, G. S., Wang, A., Liu, L., and X. Liu, "Stateless
SRv6 Point-to-Multipoint Path", Work in Progress,
Internet-Draft, draft-chen-pim-srv6-p2mp-path-07, 23
October 2022, <https://www.ietf.org/archive/id/draft-chen-
pim-srv6-p2mp-path-07.txt>.
[I-D.cheng-spring-ipv6-msr-design-consideration]
Cheng, W., Mishra, G. S., Li, Z., Wang, A., Qin, Z., and
C. Fan, "Design Consideration of IPv6 Multicast Source
Routing (MSR6)", Work in Progress, Internet-Draft, draft-
cheng-spring-ipv6-msr-design-consideration-01, 25 October
2021, <https://www.ietf.org/archive/id/draft-cheng-spring-
ipv6-msr-design-consideration-01.txt>.
Eckert, et al. Expires 27 April 2023 [Page 18]
Internet-Draft msr6-rbs October 2022
[I-D.eckert-bier-cgm2-rbs]
Eckert, T. T. and B. Xu, "Carrier Grade Minimalist
Multicast (CGM2) using Bit Index Explicit Replication
(BIER) with Recursive BitString Structure (RBS)
Addresses", Work in Progress, Internet-Draft, draft-
eckert-bier-cgm2-rbs-01, 9 February 2022,
<https://www.ietf.org/archive/id/draft-eckert-bier-cgm2-
rbs-01.txt>.
[I-D.eckert-bier-rbs]
Eckert, T. T., Menth, M., Geng, X., Zheng, X., Meng, R.,
and F. Li, "Recursive BitString Structure (RBS) Addresses
for BIER and MSR6", Work in Progress, Internet-Draft,
draft-eckert-bier-rbs-00, 24 October 2022,
<https://www.ietf.org/archive/id/draft-eckert-bier-rbs-
00.txt>.
[I-D.geng-msr6-rlb-segment]
Geng, X., Li, Z., and J. Xie, "RLB (Replication through
Local Bitstring) Segment for Multicast Source Routing over
IPv6", Work in Progress, Internet-Draft, draft-geng-msr6-
rlb-segment-01, 24 October 2022,
<https://www.ietf.org/archive/id/draft-geng-msr6-rlb-
segment-01.txt>.
[I-D.geng-msr6-traffic-engineering]
Geng, X., Li, Z., and J. Xie, "IPv6 Multicast Source
Routing Traffic Engineering", Work in Progress, Internet-
Draft, draft-geng-msr6-traffic-engineering-02, 24 October
2022, <https://www.ietf.org/archive/id/draft-geng-msr6-
traffic-engineering-02.txt>.
[I-D.xu-msr6-rbs]
Xu, B., Geng, X., and T. T. Eckert, "RBS(Recursive
BitString Structure) for Multicast Source Routing over
IPv6", Work in Progress, Internet-Draft, draft-xu-msr6-
rbs-01, 30 March 2022, <https://www.ietf.org/archive/id/
draft-xu-msr6-rbs-01.txt>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
Eckert, et al. Expires 27 April 2023 [Page 19]
Internet-Draft msr6-rbs October 2022
[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,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
Appendix A. Background / Explanations
[TBD: This section to be removed, but maybe some explanations will
make sense to move into different sections.]
A.1. Evolution from draft-xu-msr6-rbs
This document is an option for MSR6/RBS that is derived from
[I-D.xu-msr6-rbs]. The key changes over that draft are as follows.
A.1.1. RBS-Offset/RBS-Length
In [I-D.xu-msr6-rbs], the RBS-Address was rewritten on every copy to
a different adjacency by replacing the RU in the RBS-address with the
RU for the adjacency. This required a potentially significant amount
of write cycles to packet memory for each copy and changes the size
of the packet header on each hop.
This draft proposes to add RBS-Offset and RBS-Length fields and
changes the processing of the RBS-address, so that only these two
indices need to be re-calculated and re-written on every packet copy,
keeping the extension header size the same and minimizing the amount
of writes required.
A.1.2. Type-specific data encoding
This draft further reduces the size of the MSR/RBS extension header
by encoding the RBS-address not as a TLV, but as the MRH Type-
specific data field, thereby saving the TL parts of the TLV option
(32 bits). It also replaces the TotalLen field (which did change on
every hop) for the RBS address with an (immutable) 32-bit unit
counter called RU0L which saves 2 bits.
Eckert, et al. Expires 27 April 2023 [Page 20]
Internet-Draft msr6-rbs October 2022
A.1.3. IP Multicast compatibility
This draft adds the (optional) MSER-Segment field (IPv6 address),
with the primary option being that IPv6 packets with MSR/RBS
extension header can support IPv6 multicast without additional IPv6
in IPv6 extension headers or IPv6 in IPv6 encapsulation. Without
this MSER-Segment, there is no field to carry the IPv6 Multicast
Destination Address required to support IPv6 Multicast.
Support for IPv6 Multicast with MSR/RBS not only enables efficient
end-to-end IPv6 multicast with stateless source-routing, but it also
allows to use MSR/RBS even when it only encapsulates another IP or
IPv6 multicast packet. This is the common case when using MVPN,
where the CE multicast packets (IP or IPv6) are IP Multicast
encapsulated on the PE (IPv4 or IPv6). Because of the MSER Segment
field, all MVPN signaling protocols defined for this so-called SP IP
Multicast instance can be reused with MSR6/RBS.
IP Multicast compatibility also should make it easier to support
MSR6/RBS in Host stacks via socket APIs. These already support
extension headers, but it is a lot more complex to introduce new
socket types, which would ve required when MSR6/RBS can not be made
to look like either IP Multicast (or IP Unicast) to the Socket API.
A.1.4. Terminology
This document proposes the terms MSR, MSIR and MSER for routers using
MSR6 stateless multicast.
A.1.5. Text changes
Large part of the text where rewritten, and pseudocode from
[I-D.eckert-bier-cgm2-rbs] was inherited.
A.2. Comparison with RBS for BIER
[I-D.eckert-bier-cgm2-rbs] introduced RBS-Address encoding for BIER
without being specific to what encapsulation to use for it. It also
describes the overall architectural use of RBS addresses and their
scalability benefits.
[I-D.eckert-bier-cgm2-rbs] as an architecture document (wrt. to use
of a controller for example) is also applicable to MSR6/RBS, as are
the scalability benefits of RBS. For current brevity of this draft,
none of that text has been copied here (yet).
Eckert, et al. Expires 27 April 2023 [Page 21]
Internet-Draft msr6-rbs October 2022
[I-D.eckert-bier-cgm2-rbs] stays valid as a valuable protocol option
for BIER, especially as an improvement over BIER-TE due to the
simplification in architectural complexity (variety of adjacencies to
further save bits in the static Bitstring in BIER-TE), and the better
scaling of RBS addresses compared to BIER-TE and even BIER Bitstrings
in large networks. Scale specifically means the need for fewer
packet copies to the same set of BFER (MSER) in large SP networks.
[I-D.eckert-bier-cgm2-rbs] does not currently include the
optimization of RBS-Length/RBS-Offset to avoid rewriting/shortening
the whole RBS-Address on every copy, but that would be equally an
option there.
Authors' Addresses
Toerless Eckert
Futurewei Technologies USA
2220 Central Expressway
Santa Clara, CA 95050
United States of America
Email: tte@cs.fau.de
Xuesong Geng
Huawei 2012 NT Lab
China
Email: gengxuesong@huawei.com
Xiuli Zheng
Huawei 2012 NT Lab
China
Email: zhengxiuli@huawei.com
Rui Meng
Huawei 2012 NT Lab
China
Email: mengrui@huawei.com
Fengkai Li
Huawei 2012 NT Lab
Email: lifengkai@huawei.com
Eckert, et al. Expires 27 April 2023 [Page 22]
