| Internet-Draft | draft-xu-msr6-rbs-00 | March 2022 |
| Xu, et al. | Expires 1 October 2022 | [Page] |
This document defines a new type of segment: End.RBS, and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions.¶
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].¶
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 1 October 2022.¶
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.¶
MSR6(Multicast Source Routing over IPv6) is an IPv6 based multicast source routing (MSR6) solution, defined in [I-D.cheng-spring-ipv6-msr-design-consideration], which leverages the benefits of source routing over IPv6 data plane to provide simplified multicast TE and BE service in an IPv6 network without unnecessary multicast tree status and complex control plane protocols. MSR6 needs to reuse the advantages of SRv6 and BIER to implement source routing.¶
MSR6 has two basic modes of forwarding: one is based on Shortest Path First(SPF), which is called MSR6 BE mode; the other is based on traffic engineered, 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 list by defining arguments in each segment.¶
This document defines IPv6 based RBS [I-D.eckert-bier-cgm2-rbs] which provides an optional solution for MSR6 TE. A new type of segment End.RBS and the corresponding RBS type sub-TLV in MRH defined in [I-D.geng-msr6-traffic-engineering], which could indicate multicast tree in the a recuisive bitstring and save the header overhead.¶
MSR6: Multicast Source Routing over IPv6, defined in .¶
MRH: Multicast Routing Header, a new type of Routing Header which is used for MSR6 [I-D.cheng-spring-ipv6-msr-design-consideration].¶
Replication Endpoint: the intermediate node of a multicast tree, which replicates packet and forwards the packet to the downstream nodes. For MSR6, the Replication Node is called Replication Endpoint which can be indicated by the MSR6 Segment and replicate packets according to the multicast source routing information encapsulation in the MSR6 header of the packet.¶
BFR: Bit-Forwarding Router, a router support RBS.¶
BIFT: Bit Index Forwarding Table, locally to BFR.¶
RU: RecursiveUnit, a Bit String is to be parsed by BFR along the multicast tree of the packet, defined in [I-D.eckert-bier-cgm2-rbs]¶
This section describes the encoding of explictit multicast path with RecursiveUnit BitString Structure (RBS) .¶
An explicit muliticast path is encapsulated with RBS as shown in Figure 1.¶
+----------+---------------------+---------+
| TotalLen | RecursiveUnit | Padding |
+----------+---------------------+---------+
. .
...... TotalLen .......
Figure 1: Architecture of RBS Address
¶
For the reference encoding, TotalLen is an 16-bit field that counts the size of the RecursiveUnit in bits, permitting for up to 65535 Bit long RBS addresses.¶
The Rsv filed,which is defined in [I-D.eckert-bier-cgm2-rbs] , is omitted in this scenario.¶
Padding is used to align the RBS address as required by the IPv6 encapsulation.¶
This section uses a hierarchical multicast tree as an example to describe the RecursiveUnit coding format.¶
+---+
| R |
+-+-+
|
+----------+----+-----+-----------+
| | | |
+-v-+ +-v-+ +-v-+ +-v-+
| A1| | A2| | A3| ... | AM|
+-+-+ +---+ +---+ +---+
|
+----------+----+-----+----------+
| | | |
+-v-+ +-v-+ +-v-+ +-v-+
| B1| | B2| | B3| ... | BN|
+---+ +---+ +---+ +---+
Figure 2: Hierarchical multicast tree
¶
As Shown in Figure 2, the whole explicit multicast path should be encapsulated (See Section 3.1) in-packet, which will be parsed by each Router along the delivery tree.¶
The RecursiveUnit filed is structured as shown in Figure 3. To abbreviate the size of the figure, we use AF for AddressingFiled, and RU for RecursiveUnit In the following figures.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalLen| BitString | AF 1 | AF 2 | ...| AF M-1 | RU 1 | RU 2 | ...| RU M | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
/ \
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
|BitString|AF 1...N-1|RU 1 ...N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
Figure 3: RecursiveUnit Filed Structure¶
The BitString field guides the first-hop node 'R' to locally duplicate packets and forwarding. The length of BitString matches the Maxnumber of adjacencies in node 'R' (See Section 3.3).¶
The AddressingField consists M-1 fields. Each filed is an 8-bits filed and the value of it is the length of relative RecursiveUnit, and may be the offset in some scenario . The length of last RecursiveUnit M could be caculated by TotalLen.¶
And each RecursiveUnit is structured in same mechnism as shown in Figurse 3.¶
RBS BIFT as shown in Figure 4 are containing for each BP an adjacency.¶
+--+---------+-------------+
|BP|RecuFlag | Adjacency|
+--+---------+-------------+
| 1| 1|adjacenct BFR|
+--+---------+-------------+
| 2| 0| punt/host|
+--+---------+-------------+
| ..... ... |
+--+---------+-------------+
| N| ...| ... |
+--+---------+-------------+
Figure 4: RBS BIFT¶
The BP of the BIFT are all local to the BFR. When a BFR receives a packet encapuslated with RBS, it expects that the BitString filed length must be matched with N, which is configured by BFR.¶
When the packet is received by an Replication Endpoint and the DA of this packet is a local SID with the function of End.RBS, the packet will be replicated based on the RBS sub-TLV defined in section 5. The DA of the replicated packets is replaced by the End.RBS for the next Replication Endpoinds.¶
The behavior of End.RBS is defined in section 5 of [I-D.eckert-bier-cgm2-rbs].¶
MRH defined in [I-D.geng-msr6-traffic-engineering] is as follows:¶
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRH Sub-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.MRH of RBS Type Encapsulation
¶
MRH Sub-type: 8-bit identifier of the sub-type. The sub-type of RBS is to be assigned by IANA.¶
Segments Left: MUST be set to 0 when the MRH sub-type is RBS sub-type.¶
Type Length Value objects: Must habe RBS sub-TLV when the MRH sub-type is RBS sub-type.¶
A "RBS" type sub-TLV is defined for RBS in the feild of Optional Type Length Value Objects. The format is shown as below¶
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RBS Address(variable) //
| //
| //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6.RBS Sub-TLV
¶
Type: 8-bit identifier of the type of sub-TLV. The type of RBS option is to be assigned by IANA.¶
Length: 16-bit unsigned integer indicates the length of the option Data field of this option, in octets. The value of Opt Data Len of RBS option depends on the encoding of multicast tree, according to the mechanism defined in section 3.¶
RBS Address: defined in [I-D.eckert-bier-cgm2-rbs]. The packet is forwarded based on the multicast tree indicated by the RBS Address.¶
Figure 7 shows an example for RBS forwarding.¶
+-+
/-=>-|C|-=> Client2
/ +-+
/
+-+ +-+ +-+ +-+
Client1 =>-|B|-=>-|R|-=>-|S|-=>-|D|-=> Client3
+-+ +-+ +-+ +-+
\
\ +-+
\-=>-|E|-=> Client4
+-+
Figure 7: Example Network Topology¶
A packet from Client1 connected to BFR B is intended to be replicated to Client2,3,4.¶
The encapsulation of RBS at BFR-B is shown in Figure 8.¶
........................ RecursiveUnit ...................................
. .
+-----------+------------+-----------------------------------------------------------+-------+
|TotalLen:34|BitString:01|RU1:(R:011|AF:00010010|S:011|AF:00000011|C:001|D:0001|E:001)|Padding|
+-----------+------------+-----------------------------------------------------------+-------+
Figure 8: Encapsulation of RBS at BFR-B¶
Since there is only one RecursiveUnit, the AddressingField is omitted at BFR-B.¶
BFR-B rewrites the RBS by replacing the RecursiveUnit with RecursiveUnit 1 and adjusts the TotalLen and Padding fileds.¶
And BFR-R receives the packet with RBS, which has been processed by BFR-B, shown in Figure 9.¶
.......................... RecursiveUnit ..............................
. .
+-----------+-------------+------------+----------------------------------------------+-------+
|TotalLen:32|BitString:011|AF1:00010010|RU1(S:011|AF1:00000011|C:001|D:0001)RU2(E:001)|Padding|
+-----------+-------------+------------+----------------------------------------------+-------+
Figure 9: Encapsulation of RBS at BFR-R¶
And BFR-R parse the Bitstring filed using BIFT shown in Figure 10.¶
Because there are two recursive BP set in the BitString for R, one AddressingFiled is required to indicate the length of RecursiveUnit 1.¶
+--+---------+---------+ |BP|RecuFlag |Adjacency| +--+---------+---------+ | 1| 1| B | +--+---------+---------+ | 2| 1| S | +--+---------+---------+ | 3| 1| E | +--+---------+---------+ Figure 10: RBS BIFT on BFR-R¶
BFR-R accordingly creates one copy for BFR-S using RecursiveUnit 1, and only copy for BFR-E using RecursiveUnit 2, updating Padding accordingly for each copy.¶
BFR-S receives from BFR-R the packet as shown in Figure 11.¶
............. RecursiveUnit ......................
. .
+-----------+-------------+------------+---------------------+-------+
|TotalLen:18|BitString:011|AF1:00000011|RU1(C:001)RU2(D:0001)|Padding|
+-----------+-------------+------------+---------------------+-------+
Figure 11: Encapsulation of RBS at BFR-S¶
BFR-E receives from BFR-R the packet as shown in Figure 12.¶
+-----------+-------------+-------+ |TotalLen:32|BitString:001|Padding| +-----------+-------------+-------+ Figure 12: Encapsulation of RBS at BFR-E¶
BFR-E would impose or rewrite a unicast encapsulation to make the packet become a unicast packet directed to Client 4.¶
The procedures for processing of the packet on BFR-S are very much the same as on BFR-R.¶
BFR-C receives from BFR-R the packet as shown in Figure 13. And it will make the packet become a unicast packet directed to Client 2.¶
+-----------+-------------+-------+ |TotalLen:3 |BitString:001|Padding| +-----------+-------------+-------+ Figure 13: Encapsulation of RBS at BFR-C¶
BFR-D receives from BFR-R the packet as shown in Figure 14. And it will make the packet become a unicast packet directed to Client 3.¶
+-----------+--------------+-------+ |TotalLen:4 |BitString:0001|Padding| +-----------+--------------+-------+ Figure 14: Encapsulation of RBS at BFR-D¶
The brief of RBS BitString conversion is shown in Figure 15.¶
+------------+
|{S=S , D=C} |
+------------+
|[BitStr=001]|
+============+
| (C-MC Pkt) |
+============+ +-+
/--------=>------|C|----=>---Client2
+------------+ +------------+ /+------------+ +-+ +==========+
|{S=B , D=R} | |{S=R , D=S} | / |{S=S , D=D} | |(C-MC Pkt)|
+------------+ +------------+ / +------------+ +==========+
|[BitStr=011]| |[BitStr=011]| / |[BitStr=0001]|
+==========+ +============+ +=============+ / +============+
|(C-MC Pkt)| | (C-MC Pkt) | | (C-MC Pkt) | / | (C-MC Pkt) |
+==========+ +-+ +============+ +-+ +============+ +-+ +============+ +-+
Client1---=>---|B|-------=>-------|R|-------=>-------|S|---------=>-=--------|D|----=>----Client3
+-+ +-+ +-+ +-+ +==========+
+------------+ \ |(C-MC Pkt)|
|{S=R , D=E}| \ +-+ +==========+
+------------+ \-=>-|E|-----=>------ Client4
|[BitStr=001]| +-+ +==========+
+============+ |(C-MC Pkt)|
| (C-MC Pkt) | +==========+
+============+
Figure 15: Brief of RBS BitString coversion
¶
This document makes no request of IANA.¶
Note to RFC Editor: this section may be removed on publication as an RFC.¶