RBS(Recursive BitString Structure) for Multicast Source Routing over IPv6

MSR6(Multicast Source Routing over IPv6) is an IPv6 based multicast source routing (MSR6) solution, defined in , 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. , and have introduced structured segment list by defining arguments in each segment. This document defines IPv6 based 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 , 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 . 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

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.

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 , 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.

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.

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.

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 .

MRH defined in is as follows:

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

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 . 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.

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.

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.

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.

BFR-E receives from BFR-R the packet as shown in Figure 12.

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.

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.

The brief of RBS BitString conversion is shown in Figure 15.

------|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.