]> Futurewei Technologies USA

USA tte@cs.fau.de

China Mobile

China liuyisong@chinamobile.com

China Telecom

China zhuyq8@chinatelecom.cn

New H3C Technologies

China linchangwang.04414@h3c.com

PIM This document describes the IPv6 extensions to support an experiment in which new IPv6 Routing headers that support stateless replication are implemented and deployed for IPv6 Segment Routing Networks. Collectively, these headers are called Multicast Routing Header (MRH). One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment.

Overview This document introduces IPv6 Routing headers that enable stateless replication of packets in IPv6 or SRv6 networks. These headers are collectively called Multicast Routing Headers (MRH). IPv6 Packets using these Routing headers can be IPv6 multicast packets or IPv6 (unicast) packets. When they are multicast packets, these mechanism can enable to avoid stateful multicast tree building protocols, such as PIM-SM, . When they are unicast packets that need to be sent to more than one receiver, this mechanism allows to avoid either sender-side replication of these packets or the use of IPv6 multicast to achieve the replication. The mechanisms in this document are specifically targeted for SRv6 networks where stateless forwarding through ingres node steering of packets via SRH ()) already establishes a network preference to minimize the amount of state required in networks and/or the desire or need for advanced traffic steering, both of which is also possible for stateless replicated packets through the mechanisms in this memo. This document intends to support an experiment in which these new IPv6 Routing headers are implemented and deployed for IPv6 Segment Routing Networks or IPv6 network withoutt he desire for other forwarding planes. One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment. This document only specifies the Routing headers and their semantics. The larger context of the experiment is (informationally) described in . This document is intended for 6MAN which is authoritative for IPv6 extension headers, but it is initially directed at review in PIM which is responsible for the overall experiment as the Multicast Routing expert group, including Multicast for Segment Routing/SRv6.

The Multicast Routing Header (MRH) The MRH header contains the following fields: Next Header - Defined in . Hdr Ext Len - Defined in . Routing Type - Defined in . Each MRH sub-type is allocated a new Routing Type by IANA. Segments Left - Defined in . Type-specific Data - Described in . In the MRH, the Type-specific Data field contains the elements as shown in .

The "MSER-Segment" ("Multicast Source Exit Router Segment") carries an IPv6 address. If it is an IPv6 address according to , then the packet is an IPv6 multicast packet. If the MSER-Segment is not an IPv6 address, then it is a SID according to , and the packet is called a stateless, directed replication, SRv6 (unicast) packet. MRH Sub-Type specific data contains a compressed encoding of SIDs that permits replication to a set of one or more destination SR nodes. Its encoding is determined by the MRH Sub-Type indicated by the Routing Type field. The data contained in MSER-Segment does not allow to determine on every Segment endpoint node a calculation of the actual number of segments left, nor would this value be useful. For this reasons, the MRH header field does not include a "Segments Left" field, but that space is instead used to indicate the offset to the optional TLV objects field in 32 bit units. This also makes it necessary for the MRH Sub-Type field to be multiple of 32 bit units in length - or be padded accordingly. If no TLV objects field is present, the value of TLV offset points to the first byte after the end of the MRH header. Note that the definition of TLV offset makes it never zero, which is necessary so that routers not supporting MRH extension headers will stop processing the packet and raise an ICMPv6 error according to , section 4.4. The X Flag is for future extensions, see . It MUST be set to 0 Packets received with X set to 1 MUST, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. The length of the MRH Sub-Type may change during processing. TLV offset then needs to be updated accordingly. MTU discovery is not used for multicast packets and MRH headers are intended for use in controlled networks, so change in header size is something that can be managed. For example by never sending packets with more than the minimum MTU of 1280 as recommended for multicast packets in and accordingly setting the MTU in the controlled network so the largest possible headersizes plus 1280 will fit. The Optional Type Length Value (TLV) objects field is as defined in . As specified there, its length may change. Except for the aforementioned fixed value of the Segments left field, routing and forwarding for packets with an MRH routing extension header follows the rules of as restated and refined by the following definitions.

MRH nodes There are different types of nodes that may be involved in MRH segment routing networks: Source nodes: originate packets with an MRH segment address in the destination address of the IPv6 header Transit nodes: forward packets destined to a remote MRH segment Segment endpoint nodes: process a local segment in the destination address of an IPv6 header. Egress nodes: a subset of the Segment endpoint node that act as IPv6/IPv6-Multicast host to the packet, passing it up to the next header protocol of the packet Note that SRv6 in does not explicitly name egress nodes, although every SRH packet has exactly one such Egress node too. This document simply adds that additional terminology for convenience reasons. All other node types have exactly the same specification as in .

MRH sub-type semantics All MRH sub-types operate on the semantic that a packet is forwarded and replicated across a directed tree rooted in the source node of the MRH packet. All edges of the tree are segments, each vertex of the tree is a segment endpoint node. All leaves and a subset of the non-leaf are egress nodes, operating as IPv6 hosts processing the next header protocol of the packet.

Destination class MRH sub-type In a "destination" class MRH sub-type, the MRH sub-type specific data encodes only a list of egress node SIDs. All leaves of the tree are egress nodes. Non-egress edges/nodes of the tree are determined by forwarding/replication on segment endpoint nodes. Each segment endpoint node determines next segment endpoint nodes to replicate the packet to in order to reach the subset of egress nodes for the subtree rooted in this node. This is the replication mechanism used for example in .

Steering class MRH sub-type In a "steering" class MRH sub-type, the MRH sub-type specific data encodes the complete directed tree with its segment endpoint nodes. Each non-leaf segment endpoint node determines the next segment endpoint nodes to which to replicate the packet to directly from the MRH sub-type specific data without having to examine the encoded tree beyond those next-hops. This is the replication mechanism used for example in . In a "steering" class MRH sub-type, the non-leaf nodes of the tree are pre-determined by the MRH sub-type data and delivery of the packet to that node can thus be granted. Therefore, the actual property of a node being an egress node does not need to be encoded in the MRH sub-type but can instead be derived from membership of that node in the packets IPv6 multicast and/or future MSER segment SID semantic. This allows for more compact encoding of MRH sub-type data in this case because it eliminates the need to distinguish between a non-leaf segment endpoint node of the tree to be an egress node or not.

MRH Packet processing

On Transit Nodes Processing of MRH extension headers is as specified in , Section 4.2. with respect to forwarding of IPv6 packets. However, additional packet processing in the forwarding plane that operate on IPv6 multicast packets for functions beyond those of IPv6 (unicast) packet forwarding MAY perform the same operation on an IPv6 packet with an MRH extension header which is an IPv6 multicast packet because its MSER-Segment contains an IPv6 multicast group address. In this case, the IPv6 multicast related function is performed as if the IPv6 multicast group address in the MSER-Segment was present in the IPv6 DA field of the packet, ignoring the IPv6 (unicast) Segment endpoint address in the IPv6 DA field, which is irrelevant to the IPv6 multicast semantic of the packet. Examples of such functions are statistics gathering of IPv6 multicast packets for IPFIX, attachment of QoS policies to the packet or "ACL" filtering of packet including firewall functions or filtering of scoped IPv6 multicast addresses ().

On the MRH source node A source node steers a packet into an MRH/SR policy that translates into one or more of the following set of data elements, each one required for one copy of the packet. An MSR sub-type header representing in a compressed form a set of Egress node SIDs (destination sub-type) or a tree of segment endoint node SIDs with optional Egress nodes (steering sub-type) An IPv6 source address belonging to the source node, which may be a SID, or which may need to be associated with semantics of the MSR sub-type header or the packet. For example, for an IPv6 multicast SSM packet as in, , the SA needs to be set according to the desired (S,G) channel. An IPv6 destination address, which may be an IPv6 multicast group address (G) or a SID to be processed by all Egress nodes. TLV (including HMAC). Optionally an IPv6 destination address for the first Segment endpoint node. The MRH/SR policy needs more than one data element sets and hence packet copies when the desired list of egress nodes und/or representation of the tree of segment endpoint does not fit into a single MRH header. The source node sets the IPv6 header and MRH extension header as follows The SA of the packet is set to the IPv6 source address The MSER-segment is set to the IPv6 destination address. The Next Header and Hdr Ext Len fields are set as specified in . The Routing Type field is set to the value assigned for the MSR sub-type. The MSR sub-type header is inserted into its field. The Segments left field is set to the length of the MSR sub-type header plus 32 bits in units of 32 bits. If the SR policy includes a first Segment endpoint node IPv6 address, then the packets DA is set to that address, and the packet is sent to it. If the SR policy does not include such an IPv6 address, the packets DA is logically left unset and the packet is passed to the nodes MRH Segment endpoint processing steps.

On Segment endpoint nodes This document requires/uses only a single SRv6 SID for the reception of IPv6 packets with MRH type routing extension header. This SID can also be used for other purposes if the node can distinguish the semantic based on the routing header it contains - aka: for packets without an MRH type routing extension header. If local processing requires TLV processing, perform TLV processing as described in in . Determine if this node is an egress node for the packet as follows. If the MRH sub-type data explicitly encodes this node as an egress node. If the node has membership for the IPv6 address in the MSER segment field. This can be the case when it is an IPv6 ASM multicast group that this node has joined to, or if the node has subscribed to the IP6 SSM channel indicated by (SA,MSER-segment), or if the MSER-segment indicates a non multicast SID that the node is subscribed to. The rules for subscription to non multicast SID are outside the scope of this document. If the node is egress node for the packet, create a copy of the packet for which to proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. Reduce the Hop-Count of the packet by 1. If the hop count is <= 1, determine from the MSER segment SID whether ICMPv6 processing is desired. If the MSER segment SID is IPv6 multicast, no ICMPv6 processing is desired. Otherwise, the desire for ICMPv6 processing is defined by the SID. If ICMPv6 processing is desired, Send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address discard the packet, stop processing Determine from the MRH sub-type data a list of 0 or more next-hop segments of the tree and perform the following processing for each of those next-hop segments Create a copy of the packet Change the DA of the packet to the Segment Endpoint SID for that next-hop node. Rewrite the MRH sub-type data according to the processing rule of that MRH sub-type. Typically, in a destination MRH sub-type this consists in eliminating from the encoded Egress nodes set those that are not reachable via this next-hop segment, and for a steering MRH sub-type in adjusting offset pointers in the MRH sub-type data to point to the subtree rooted in the next-hop node. Discard packet, terminate processing

MRH sub-types

MRH-bitstring-destination (MRH-bd) Sub-Type format MRH-bd uses the packet forwarding data structures (BIFT) and forwarding rules of . IPv6 packets with MRH-sd extension header are an compliant encapsulation to support BIER architecture ( packet forwarding, and it uses all forwarding rules unmodified. encapsulation is not used.

shows the field of the MRH Sub-type specific data for the MRH SD is the sub-domain as specified in SI is the Set Identifier as specified in Entropy is as specified in . BitString is as specified in . OAM is for future use with OAM procedures. The length of the BitString MUST be a multiple of 32 bits. It SHOULD be one of thefollowing value for compatibility with potentially pre-existing {RFC8279}} forwarding hardware: 64, 128, 256, 512, 1024, (2048, 4096) Nodes supporting MRH-sd MUST support a BSL of 256 bits. Note that the length of 2048 and 4096 are not possible in an MRH extension header due to the 255 byte size limit of IPv6 extension headers. See . Population of the , section 6.4 forwarding tables (BIFT) is outside the scope of this specification. For the purpose of performing the rewriting of the IPv6 DA on Segment endpoint nodes, the BFR-NBR in the BIFT needs to be the MRH-sd SID of the next-hop MRH-sd node.

MRH-steering (MRH-s) Sub-Type format This sub-type is TBD. There are currently multiple competing proposals considered, including RTS ( and . It should be noted, that will explicitly not be considered, because that work was focussed on re-using the forwarding plane as much as possible, and this lead to a lot of management and scalability issues which would make experimentation not with it not very useful. can work fine in smaller scale deployments (networks and/or size of trees), but the purpose of this experiment is also to find better solutions for future hardware forwarding engines.

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community. The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community. This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network. This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER) packets (RFC 8279); it is called "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER "subdomains" (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP). Futurewei Technologies USA University of Tuebingen University of Tuebingen China Mobile BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. China Mobile Huawei Technologies New H3C Technologies This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability. Futurewei Technologies USA China Mobile This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/ SRv6 networks as well as BIER networks as a related effort.

Longer MRH headers Currently, IPv6 extension headers can only be up to 255 byte in size. It is also perceived common understanding that high-speed IPv6 routers, which are also targeted by this memo can not well support lookup into packets of more than 512 bytes, and that examining a long header may reduce packet throughput performance. For example, an Bitstring has to be completely examined by a router, so longer Bitstrings run into this problem. However, with segment tree encoding in MRH sub-types, a single Segment endpoint nodes does not need to examine the whole header anymore, but only a consecutive smaller part of a potentially much larger header. Likewise, if each node removes its part of the MRH sub-type data for the copy sent to the next-hop node, then each node will also have its part of the header start near the start of MRH header, thus no look deep into the packet is necessary. Likewise, router forwarding engines become like general purpose CPU, the less problematic larger offsets into packet memory will be an issue, but only the total amoun of processing needed to be done on the memory accessed. Finally, is it worth to have a larger header instead of sending multiple packets ? Yes, for multicast packets it is. Consider that a 1024 byte long extension header could address for example 4 times as many destinations as a 256 byte extension header, so the bandwidth use near the source of the packet is significantly reduced by as much as a factor of 4. One possible option would be to use the X field in the MRH header to indicate that the Hdr Ext Len indicates the length of the extension header in 32 or 64 bits.

Changelog 01: Added new co-authors 00: initial version.