PIM T. Eckert
Internet-Draft Futurewei Technologies USA
Intended status: Experimental 3 March 2025
Expires: 4 September 2025
Proposal for experimentation with stateless IPv6 multicast source
routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing
Headers (MRH)
draft-eckert-pim-mrh-experiment-00
Abstract
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.
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 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Eckert Expires 4 September 2025 [Page 1]
Internet-Draft msr6-rbs March 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background: The road towards BIER . . . . . . . . . . . . . . 4
3. BIER for IPv6 networks . . . . . . . . . . . . . . . . . . . 8
4. Challenges of BIER with IPv6 . . . . . . . . . . . . . . . . 9
4.1. Oerational, architectural, performance . . . . . . . . . 9
4.2. Architectural and functional . . . . . . . . . . . . . . 10
4.3. IETF process . . . . . . . . . . . . . . . . . . . . . . 10
5. List of target benefits / directions . . . . . . . . . . . . 11
6. Intial proposed MRH definitions . . . . . . . . . . . . . . . 13
6.1. MRH Header . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. BIER MRH Sub-Type format . . . . . . . . . . . . . . . . 14
6.3. Further MRH Sub-Type considerations . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Overview
This document proposes experimentation to evaluate benefits and
feasibility of an IPv6 routing extension header based multicast
forwarding. Experimentation should include implementation and
experimental deployment to evaluate the feasability and benefits of
this approach for IPv6 only networks, especially those using SRv6 for
unicast compared to alternative approaches such as using
[I-D.ietf-bier-bierin6].
This document is mostly meant to be a process document to vet support
for the direction, and if that exists, it would be followed up by an
appropriate IPv6 extension header draft proposal as well as other
deemed necessary documents, such as an architectural document to
describe howto apply the SRv6 SID semantic to the addresses used (or
indicated) vby the IPv6+extension header for stateless multicast.
Eckert Expires 4 September 2025 [Page 2]
Internet-Draft msr6-rbs March 2025
The new IPv6 routing extension header would initially be using using
one or two of the [RFC4727] Experiment Routing Types (253, 254).
Upon successfull completion of experimentation, assignment of a
permanent Routing Type could be requested.
The new routing extension header should inherit all re-useable
aspects of the pre-existing unicast routing headers (RPL source route
header and SRH), so that no unnecessary re-invention of already
applicable SRv6 technology is done.
Likewise, the new routing extension header should in one option
explore how to best re-use the IETF BIER established stateless
multicast forwarding architecture, [RFC8279] while also complying to
[RFC8200], and only exceeding it, when seen beneficial.
Experimentation is also meant to investigate how multiple different
encodings of the stateless multicast forwarding information could
best be encoded in such multicast routing extension header options;
these are henceforth called MRH - Multicast Routing Header.
For example, different encodings could use different Routing Type
code points as used for example across the different compressed
unicast routing header options such as CRH-16, CRH-32. In another
option, different encoding options could be selected from a further
code-point within a single MRH Routing Type header.
The experimentation should include two different encoding options.
One is the aforementioned [RFC8296] architecture based stateless
multicast forwarding information (bitstring plus metadata).
The second encoding should be an initial proposed encoding for
stateless tree encoding within the MRH, such as derived from, but not
necessarily [I-D.eckert-pim-rts-forwarding]. Note that like also in
unicast SRv6 and its various forms of compressed routing header
options, ultimtely different type of networks may prefer different
encodings for multicast, and hence ensuring the design for
extensibility is one core goal of this experimentation.
This document does not (yet) propose an exact list of target
documents required to perform the experiment or which WG it should
best happen, but observes the following:
* 6MAN-WG is the responsible working group for IPv6 extension
headers, but it requires a show of sufficient demand for the
extension header in technology cases like this. One of the goals
of the initial work with 6MAN-WG should be to determine how much
of the encoding variations could be done without repeated work for
6MAN-WG, but instead by only work of the more expert work for such
Eckert Expires 4 September 2025 [Page 3]
Internet-Draft msr6-rbs March 2025
encodings, such as BIER. This would follow the logic, by which
different semantics of QoS information in the DSCP field where
also not performed by 6MAN-WG but other working groups (such as
TSVWG).
* SPRING-WG is the overall responsible WG for the IPv6/SRv6
archtiecture as well as its unicast forwarding designs. SPRING-WG
has delegated responsibility for IPv6 multicast aspects to PIM-WG.
Hence this document is also positioned for PIM-WG for first
considerations.
* BIER-WG is the working group which has introduced stateless
multicast replication to the IETF, and where all the experience
with hardware forwadrding implementation for stateless multicast
replication exists. Given how the goal of this experimentation is
to not re-invent any aspect of BIER-WG except for those aspects
that will support better adoption of the technology to IPv6-only/
SRv6 networks, it is highly desirable to involve BIER in any of
the aspects of the experiment where this expertise can be drawn
upon and where consistency with existing BIER approaches needs to
be vetted.
* New encoding options for stateless multicast forwarding should not
only be defined for encapsulation within an IPv6 MRH, but if BIER-
WG is also interested in that encoding, then the encoding should
be specified agnostic to header encoding, such that it could
support encapsulation both into IPv6/MRH as well as BIER/[RFC8296]
headers.
2. Background: The road towards BIER
This background section is intended as an overview to motivate why
operators have shown interest in an IPv6/SRv6-SRH aligned solution
for stateless multicast for many operational reasons, and why BIER-WG
did arrive at a different conclusion for technology when adopting
[I-D.ietf-bier-bierin6]. This is written in the hope that the
experimentation proposed by this document is understood as a
complementary technology that is ultimately meant to proliferade the
BIER-WG spearheaded technology into more markets with minimum
additional standardization and development effort.
Before BIER, multicast solutions where defined as extensions of the
unicast (inter)network solution run in the network. RFC1112 defined
IP Multicast which re-used IPv4 ([RFC791]) packet headers and added
multicast semantic through a range of dedicated-to-multicast IPv4
destination adress range. IPv6 kept this architecture but already
included it in [RFC2460]. In result, so-called dual-plane IPv4/IPv6
network did also have to run dual-plane IPv4/IPv6 multicast. In
Eckert Expires 4 September 2025 [Page 4]
Internet-Draft msr6-rbs March 2025
networks that only could or wanted to run a single version of IP,
solutions for encapsulation of one version over the other also exist
for both unicast and multicast.
In MPLS networks, initially IP multicast was run by using IPv4
multicast in parallel to MPLS for unicast, but operators expected
that the protocol stack for multicast both in the forwarding plane as
well as the control plane was adjusted to leverage the same protocols
as for MPLS unicast, so that at least in name the variety of
protocols that needed to be run in the network for unicast and
multicast was not increased over an MPLS unicast only network. Even
though implementations of PIM for an MPLS forwarding plane already
existed since 1998, the PIM approach was explicitly not choosen
because this was a protocol unfamiliar to MPLS network operators.
Instead, the industry and thereafter the IETF chose to embed the
necessary multicast functionality into the dominant MPLS unicast
protocols LDP and RSVP-TE. This resultet in mLDP (multicast LDP) and
RSVP-TE/P2MP (Point to Multipoint).
Likewise, PIM overlay signaling for multicast VPN services was also
re-invented due to operator demand by bringing similar multicast
group membership signaling into BGP, thus allowing service providers
to completely run on only BGP and IGP but without PIM for multicast.
Whether the forwarding plane uses IPv4/IPv6 or MPLS. This was done
even though no other than operational reasons of familiary by
operators with BGP where brought forward versus the already well
deployed option of using PIM for overlay signaling in those VPN
solutions.
While this approach of having the multicast solution be embedded in
the networks unicast solution does have a wide range of benefits, it
also came with downsides. When classical MPLS solutions with LDP
where superceeded by SR-MPLS network solution for unicast, this was
also done to eliminate LDP from the network, which had a range of
problems co-existing with unicast IGPs, and/or arguably unnecessary
complexity and duplication of protocol state. But in the wake of
this unicast network architecture evolution towards unicast SR-MPLS,
operators also asked to eliminate multicast MPLS using mLDP and RSVP-
TE/P2MP.
Eckert Expires 4 September 2025 [Page 5]
Internet-Draft msr6-rbs March 2025
More fundamentally, multicast solutions including all the
aforementioned ones are based on explicit multicast tree state, which
is managed hop-by-hop in the network. This is completely contrary to
what operators are used to do with MPLS or IP unicast. In unicast,
the network, especially the transit nodes (called P-nodes in service
provider networks) only carry topology state (routing tables), but
not state belonging to or influenced by individual subscribers of the
network. Subscribers may send arbitrary traffic, but that will not
impact the IP/MPLS unicast routing tables on P-nodes.
In IP/MPLS multicast, this is not the case. When a subscriber starts
multicast sender and receiver applications, then they will cause
mLDP, PIM or BGP signaling to propagate through the network including
transit service provider hops and ultimately create multicast tree
state, which is similar in nature to unicast routing tables: It
requires hardware forwarding resources that can get exhausted, and it
requires control plane activity that may put undesirable load onto
the control plane CPU not only during creation or change of the
applications, but even more so during reconvergence due to
topological changes in the network (failures, recoveries).
While advanced multicast VPN protocol options do allow service
providers to put bounds on this state (I-PMSI state and aggregated
S-PMSI state), this too is causing additional complexity and
diagnostic/troubleshooting overhead.
Even when there is no misbehavior in the network, keeping track and
troubleshooting multicast state hop-by-hop in the network can be a
real operational challenge, and even with aforementioned multicast
VPN mechanisms in place, it still is the equivalent of having unicast
(BGP) VPN subscriber routing table entry related state on P-routers,
whereas in unicast those P-routers only carry a completetely
subscriber agnosted IGP routing table.
In result of all these operational experiences by operators, several
of them opted to move from their prior (stateful) multicast solution
to one where there would be no multicast state at all across the
service provider core network, instead replicating multicast traffic
on the ingress PE as unicast traffic, one copy each to each egress PE
that required the packet. This was much later standardized as
([RFC7988]). This is called "multicast ingress replication"
BIER was invented out of the early recognition of these operational
challenges and in fear that the non-scalability of multicast ingress
replication would ultimately lead to the demise of solutions relying
on network based multicast. The BIER architecture, [RFC8279] defines
a mechanism by which a packet header which includes a bitstring and
associated metadata can source-route and replicate the packet hop-by-
Eckert Expires 4 September 2025 [Page 6]
Internet-Draft msr6-rbs March 2025
hop across P-routers to a set of egress (PE) routers using only the
same type of of routing information as already present in a service
provider network - addressing information for the core networks P/PE
routers specific to BIER, but not to any subscriber information.
With BIER, no multicast tree state ever needs to exist on the transit
(P) routers. The BIER technology also makes it easy to evolve from
multicast ingress replication solutions, by simply adding the BIER to
the P/PE routers and letting the ingress router determine the BIER
header bitstring instead of creating a separate copy per packet to
each required PE. Even partial deployment of BIER across P/PE
routers is well considered in the BIER architecture and feasible
automastically without additional provisioning, albeit this is likely
not fully supported by existing implementations today.
The BIER architecture does not specify the way such a BIER header was
to be packetized. Initially during the work on BIER it was seen as a
real possibility to create per-unicast-network-design encapsulations
as it was done in before for IPv4/IPv6 and MPLS. Nevertheless, when
work towards the first BIER encapsulation(s) progressed, it became
obvious that the definition of multiple different encapsulations was
at the non-mature and non-adopted state of the technology too
ambitious and time consuming (note that the same may be said about
the current evolution towards multiple comprssed unicast routing
headers).
Instead, BIER-WG chose an approach where the metadata required for
different type of networks was coalesced into a single BIER header
approach, which ultimately became [RFC8296] - "Encapsulation for BIER
in MPLS and Non-MPLS Networks". This header includes a DSCP field
for use in IP network, and the first 32 bits mimic exactly a 32-bit
word of an MPLS stack.
When BIER packets are propagated through an MPLS network, there is no
end-to-end MPLS label stack or even MPLS "packet" in that BIER
packet. Logically the per-hop BIER forwarding happens solely at the
BIER layer, and on every hop the packet is encapsulated into a
single-LSE MPLS frame. In a network with full BIER support, where
BIER routers are L2 adjacenty, this is functionally equivalent to
simply encapsulate the BIER packet into an ethernet frame with a BIER
ethernet type. The core reasons for the MPLS encapsulation was the
MPLS network operator preference to only see MPLS frames on the wires
and the possible simplification of MPLS centric router hardware
forwarding plane designs to demultiplex packets easier on an LSE than
on an ethertype. An actual functional benefit of the MPLS
encapsulation exists, in a partial deployment, when the next BIER
router is not L2 adjacent, and the MPLS label could for example be an
SR-MPLS label to the closest BIER capable router.
Eckert Expires 4 September 2025 [Page 7]
Internet-Draft msr6-rbs March 2025
As a result of this originally "optimized-for-MPLS" approach,
architecturally [RFC8296] marked for BIER the desire to embrace an
approach where the BIER multicast solution should be seen as a "one-
size-fits-all" multicast network designs: To avoid the problem that
any change/evolution in unicast forwarding technologies would create
undesirable asks for change in the multicast technology - and hence
cause unnecessary technology churn.
Of course, this approach for the BIER forwarding plane does not
prevent possible churn on the necessary BIER control plane. If for
example use of IGP in networks (as is the standard today in SR
networks) should fall out of fashion, and would be replaced by some
(maybe AI controlled ?) SDN-controller control plane, then the same
would be necessary also for BIER.
3. BIER for IPv6 networks
Operators of IPv6-only networks using SRv6 for unicast traffic
steering and service management expressed interest in adopting
stateless source-routed technologies for multicast across their
networks.
The BIER architecture [RFC8279] was the obvious starting point to
provide this functionality. Additional service requirements such as
traffic engineering could be solved via BIER extensions such as BIER-
TE ([RFC9262]) without IPv6 specific changes required.
Some SRv6 networks are amongst the largest Service Provider networks
in the world, hence there is likely going to be more of an upper-end
scaling evaluation to be done for SRv6 networks.
However, the core challenge for IPv6-only network operators comes
through the "one-size-fits-all" model adopted via [RFC8296] by BIER.
By itself, this RFC is insufficient to operate BIER in a network
without MPLS. For this reason, [I-D.ietf-bier-bierin6] (BIERin6)
defines how to operate BIER in an IPv6 only network based on the
requirements stated in [I-D.draft-ietf-bier-ipv6-requirements]. This
approach repeats the MPLS network approach for BIER in IPv6 networks:
end-to-end forwarding is via an [RFC8296] BIER header and BIER hop-
by-hop an IPv6 specific IPv6 "tunnel" header can be added if that is
so desired, to make the packet appear as IPv6 on the wire. In a full
deployment those L2 IPv6 encapsulations could even use link-local
IPv6 addresses.
In addition, the encoding and control plane signaling of the BIER
metadata that needs change from its [RFC8296] MPLS bindings also
requires new drafts, [I-D.ietf-bier-non-mpls-bift-encoding] and
[I-D.ietf-bier-lsr-non-mpls-extensions].
Eckert Expires 4 September 2025 [Page 8]
Internet-Draft msr6-rbs March 2025
4. Challenges of BIER with IPv6
4.1. Oerational, architectural, performance
The main challenge is that the requirements that lead to BIERin6 did
not take the operational and architectural preferences of operators
running IPv6-only networks into account by replicating the model
developed with primarily MPLS in mind. For operators of IPv6/SRv6
networks, BIERin6 marks a significant departure from their unicast
IPv6 network architecture and operations.
One key difference between IPv6 and MPLS designs is that the cost of
headers and encap/decap. When operators in an IPv6 network expect
for operational reasons to see only IPv6 packets on the wire, the
BIERin6 approach would require per-L2-hop additional IPv6 tunnel
encapsulations, which is a significant overhead, whereas the MPLS
equivalent is no additional encapsulation overhead at all, because
the BIER header itself already start with a 32 bit word that serves
as an MPLS LSE and single-entry label stack to demultiplex to BIER.
If instead (as proposed to be experimented in this document), the
[RFC8200] approach of IPv6 extension header source-routing was used,
then this additional IPv6 per-hop encapsulation header was not
required, but the end-to-end IPv6 header (plus extension header) that
is always required would suffice.
Note too, that this difference also holds true, when there is only a
partial deployment of stateless multicast replication capable
routers, because by virtue of the pre-existing end-to-end IPv6 header
and [RFC8200] defined forwarding rules, the forwarding across non-
stateless-multicast-capable IPv6 routers would solely require
forwarding based on the IPv6 destination address of the IPv6 (base)
header.
In addition to overhead on the wire, different type of forwarding
planes may also incur different degrees of performance loss when per
L2-hop packets actually need to be decapsulated and re-encapsulated
into link-local address IPv6 headers. Keeping an encapsulation IPv6
header and re-writing it hop-by with not only the destination address
(as required by [RFC8200], but also the source-address might equally
be a challenge if hardware is not specifically optimized for that.
The author has the unfortunate experience with this type of hop-by-
hop IPv6 tunneling in a completely different use-case domain, where
it has served as the core obstacle to adoption (see [RFC8994]).
Eckert Expires 4 September 2025 [Page 9]
Internet-Draft msr6-rbs March 2025
4.2. Architectural and functional
While these differences between BIERin6 and extension header based
approaches are mostly router-implementation, performance and operator
preference, there is also a more fundamental issue with BIER which
the proposed extension header resolves, and that is that the packet
on the wire can not be identified as an IPv6 multicast packet, and
hence the wide range of collateral forwarding plane functions that
have already been defined in routers to manage IPv6 multicast traffic
are not applicable or would require a lot more complex, variable
length lookup of the IPv6 multicast destination address across
protocol layer boundaries. These features are listed further below
in the document.
Another way to look at this functional difference is that BIER was
designed to require an IP Multicast flow overlay so that BIER could -
maybe similar to MPLS - be a common "L2.5" technology, whereas IPv6
multicast is designed as an end-to-end L3 technology just like IPv6
unicast, and the IPv6 extension header approach is the only obvious
way to achieve this, and minimize or completely eliminate additional
layering overheads necessary otherwise.
4.3. IETF process
In the discussions about the best BIER for IPv6 network solution, one
of the foremost argument by those in favor of BIERin6 was also
explicitly to prove investment protection for those vendors who had
already invested into [RFC8279] and [RFC8296]. While it certainly
makes sense to support commercial goals in IETF, this specific ask
was never admitted in any prior technology decision between MPLS and
IPv6 solutions nor for other Multicast technologies (e.g.:
introducing BGP instead of PIM overlay signaling was providing all
the necessary functionality, or introducing MPLS multicast forwarding
when many operators had deployed native IPv4 multicast in MPLS
networks). Nor was it done in the case of other technologies, such
as OSPF vs. IS-IS. Instead, if and when different competing designs
existed due to customer demand, the IETF always tried to provide
equally optimized solutions for each customer network type and let
the market decide.
Eckert Expires 4 September 2025 [Page 10]
Internet-Draft msr6-rbs March 2025
While technically similar approaches may pose additional work in the
IETF, they have typically always shown to be beneficial for the
overall set of customers of IETF standards, broadening the scope of
applicability to more candidate customers. The hope of this
experimentation is equally that this would hold true for the
proliveration of original BIER technoligies into IPv6/SRv6 only
networks - more so than what BIERin6 alone could achieve (in the
opinion of the author). Expecting for BIERin6 to make BIER
successfull in IPv6-only/SRv6 networks is a highly risky proposition
and can easily result in less than more adoption of the technology.
Hence this document proposes for the IETF to at least embrace
experimentation with the IPv6 extension header based options which do
provide the best technically and operational solutions for IPv6-only/
SRv6 networks. Especially given the recent varied work on different
unicast steering header options for SRv6 unicast, it seems highly
unlikely that the industry could not endure an additional encoding
alternative to [RFC8296] for stateless multicast replication in IPv6
networks.
5. List of target benefits / directions
The following is a candidate list of benefits/technical targets of
the solutions
The solution uses an IPv6 routing extension header in the same
fashion as SRv6 unicast does this ([RFC8754]) for high-speed networks
or [RFC6554] for IoT networks. Ideally, it should be sufficient to
have a single new IPv6 routing extension header for stateless
multicast (instead of two for unicast for different networks).
For operational safety, it seems prudent to allocate a new routing
extension header code point so that this technology can be introduced
into networks which already run either of the existing unicast
extension headers without having to change any of the unicast
specific fowarding plane code - because demultiplexing between
unicast and multicast would already be able to happen at the
extension header code point.
If instead it is seen by IPv6 experts that it is equally safe and
feasible to encode the information necessary for stateless multicast
into the existing SRH extension header, using similar tricks to how
compressed unicast steering is encoded
([I-D.ietf-spring-srv6-srh-compression]), and that this is
preferrable, then this could of course equally be considered.
Eckert Expires 4 September 2025 [Page 11]
Internet-Draft msr6-rbs March 2025
All forwarding should follow the [RFC8200] and [RFC8986] principles
to the extend that they are applicable to packets that need to be
replicated. This specifically means that on each steering or
replication hop, the IPv6 header destination address gets rewritten
by the next steering/replication hop IPv6 address ("SID") derived
from the extension header.
While application software stacks for other network protocols beside
IP do exist, they are by far not as widely and easily accessible
across wide ranges of platforms/operating systems. use of IPv6
extension headers is the likely most easy proliferable solution to
bring stateless multicast replication into the software realm. This
is not only useful for softwareization of traditional routers with
new implementations, or decomposition thereof into network function
application code, but even more so for actual classical end-to-end
applications using IP multicast. Enabling such applications, to
solely rely on stateless multicast, for example in data centers is an
explicit additional market space that this effort intends to support.
To directly support the established IP multicast service interfaces
of ASM and SSM, the extension header must support to directly
indicate IP multicast. Technically this means that the extension
header also needs to be able to carry an IPv6 mulicast destination
address directly, namely when there is the need to indicate an IPv6
multicast packet. This is a significant difference over SRv6 unicast
and BIER. BIER specifically does support IP multicast only in the
way MPLS does it: as an L2.5 underlay, which can encapsulate an IP
multicast packet. The stateless IPv6 multicast solution intends to
avoid this duplication of IPv6 header when it is used end-to-end.
With this architecture, IPv6 multicast applications could be made to
rely on stateless IPv6 multicast if the socket/network layer in the
multicast hope can simply insert the routing extension header
indicating the stateless distribution tree - without the need for any
additions IPv6 in IPv6 encapsulations or other complexity. This for
example could easily be something to make deployment of IPv6
multicast easier in data center encvironments where the extension
header data could be requested from and provided by a network
controller.
Carrying the IPv6 multicast destination address in a fixed offset
part of an IPv6 extension headers makes it possible (at somewhat
higher parsing cost) to maintain traditional operational benefits of
IP multicast: It allows per-hop operation of IP specific forwarding
plane features:
* IP multicast IPfix for accounting, billing and performance quality
troubleshooting
Eckert Expires 4 September 2025 [Page 12]
Internet-Draft msr6-rbs March 2025
* IP multicast group address (range) derived QoS handling (common in
several network and well matching [RFC8986] "programming" goals).
* IPmulticast group range derived accounting, billing, policiing or
other policies.
6. Intial proposed MRH definitions
6.1. MRH Header
This chapter gives a non-normative idea of how the extension header
structures to be defined by the experiment could look like
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MSER-Segment (128 bit IPv6 address) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRH Sub-Type . MRH Sub-Type specific data |
+.+.+.+.+.+.+.+.+ //
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value (TLV) objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MRH format
The actual "Multicast Routing Header" is identified by one "Routing
Type" value. If multiple encodings ("MRH Sub-Type") are required,
then multiple "Routing Types" would need to be assigned (for
experimentation only two are available), or instad, a new "MRH Sub-
Type" demultiplexer field could be defined. With a worst-case small
number of different MRH Sub-Types of maybe <=5 required, it may be
deemed appropriate by 6MAN-WG to allocate up to e.g.: four Routing
Types before requiring a Sub-Type encoding to avoid Routing Type
exhaustion.
"Segments Left" was defined by [RFC8200]. It may not actually be
useful in all encodings, so one of the experimentation question is
whether it would be acceptable to avoid wasting this space if it is
not needed, or to reuse it for a more appropriate purpose.
Eckert Expires 4 September 2025 [Page 13]
Internet-Draft msr6-rbs March 2025
The "MSER-Segment" ("Multicast Source Exit Router Segment") can carry
the IPv6 multicast packets destination address. This is necessary
when an MRH is to be used to carry an actual IPv6 Multicast packet.
Alternatively, this MSER-Segment can carry a non-IPv6 multicast group
range IPv6 address. In this case it is a group-SID, indicating for
example programmability parameters to the receivers.
When deploying MRH with BIER-like overlays, the MSER Segment may not
be required. If one wanted to avoid wasting those 128 bits for such
use-cases, then appropriate encoding options should be found
(different Routing Type). However, one of the big benefits for IPv6
from using MRH (as opposed to a BIER header) could come from the
ability to always have this destination IPv6 address present in a
fixed location in the IPv6 (extended) header to trigger various
collateral forwarding plane functions, as mentioned elsewhere in this
document. Therefore, the functional (not performance) preference
would be to always include this field. Likewise, in many
applications a "shared IPv6 SID" for all receivers of the packet
seems likely very useful, even if its semantic is not that of an IPv6
multicast group address.
The "MRH Sub-Type specific data" if present may carry the encoding
for a particular method of stateless IPv6 multicast forwarding
6.2. BIER MRH Sub-Type format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | SD | SI |OAM| Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BIER MRH Sub-Type format
Figure 2 is an example initial proposal for encoding of BIER (and
BIER-TE, [RFC9262]) into an MRH Sub-Type.
Most of the signaling elements of the [RFC8296] BIER header are not
required:
Eckert Expires 4 September 2025 [Page 14]
Internet-Draft msr6-rbs March 2025
BFIR-id is not required because in an IPv6 environment, the IPv6
(base) header IPv6 source address (which can be a SID) serves the
same purpose.
If necessary to maintain existing signaling for 16-bit BFR-ID values,
then an appropriate SID format for the 128 bit address with such a 16
bit field can be specified.
Likewise, TTL, DSCP and Ver fields are not required as they already
exist in the IPv6 header.
The Proto field is not required, because the "Next Header" field in
the MRH serves the same purpose.
Nibble, TC and S fields are not required because they are artefacts
of the BIER header for MPLS.
The remaining signaling elements keep their existing semantic but are
slightly different encoded:
[I-D.ietf-bier-non-mpls-bift-encoding] proposes to encode BSL, SD and
SI into the BIFT-id field. This proposal picks up the same encoding,
eliminating therefore also the separate BSL field.
OAM is maintained unchanged. BitString is maintained unchanged.
Entropy is shortened to allow fitting the non-bitstring signaling
elements into 32 bits. 1024 different path options are more than
enough, so no functional deterioration is expected.
6.3. Further MRH Sub-Type considerations
The encoding for other "MRH Sub-Type specific data" fields are not
presented here. For example, if RTS ([I-D.eckert-pim-rts-forwarding]
was used as a Sub-Type, then that field would be encoded according to
that drafts header, specified in [I-D.eckert-pim-rts-forwarding],
section 4.3.
Independent of MRH Sub-Type, the per-hop forwarding rules need to be
specified, should be the same as IPv6 unicast source routing: Every
hop determines for every packet copy a next-hop ipv6 next-hop
address, which will be copied into the IPv6 header destination
address field.
Different from IPv6 unicast, the different MRH Sub-Type encodings
will require different modifications to the MRH header. In the BIER
Sub-Type case for example, bits in the Bitstring need to be cleared.
In headers such as RTS, it may be necessary to update two index
Eckert Expires 4 September 2025 [Page 15]
Internet-Draft msr6-rbs March 2025
fields in the Sub-Type data to indicate to the next-hop the active
part of the Sub-Type header that needs to be parsed. This is
equivalent to the Segments-Left field in IPv6 unicast routing header
cases.
7. Informative References
[I-D.draft-ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Geng, X., Dhanaraj, S., Asati, R.,
Zhu, Y., Mishra, G. S., and Z. J. Zhang, "BIER IPv6
Requirements", Work in Progress, Internet-Draft, draft-
ietf-bier-ipv6-requirements-09, 28 September 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
ipv6-requirements-09>.
[I-D.eckert-msr6-problem-statement]
Eckert, T. T., "Yet another Problem Statement for IPv6
Multicast Source Routing (MSR6)", Work in Progress,
Internet-Draft, draft-eckert-msr6-problem-statement-00, 24
October 2022, <https://datatracker.ietf.org/doc/html/
draft-eckert-msr6-problem-statement-00>.
[I-D.eckert-msr6-rbs]
Eckert, T. T., Geng, X., Zheng, X., Meng, R., and F. Li,
"Recursive Bitstring Structure (RBS) for Multicast Source
Routing over IPv6 (MSR6)", Work in Progress, Internet-
Draft, draft-eckert-msr6-rbs-01, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-eckert-msr6-
rbs-01>.
[I-D.eckert-pim-rts-forwarding]
Eckert, T. T., Menth, M., and S. Lindner, "Stateless
Multicast Replication with Segment Routed Recursive Tree
Structures (RTS)", Work in Progress, Internet-Draft,
draft-eckert-pim-rts-forwarding-02, 6 November 2024,
<https://datatracker.ietf.org/doc/html/draft-eckert-pim-
rts-forwarding-02>.
[I-D.ietf-bier-bierin6]
Zhang, Z., Zhang, Z. J., Wijnands, I., Mishra, M. P.,
Bidgoli, H., and G. S. Mishra, "Supporting BIER in IPv6
Networks (BIERin6)", Work in Progress, Internet-Draft,
draft-ietf-bier-bierin6-11, 2 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
bierin6-11>.
Eckert Expires 4 September 2025 [Page 16]
Internet-Draft msr6-rbs March 2025
[I-D.ietf-bier-lsr-non-mpls-extensions]
Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z.
J., and J. Xie, "LSR Extensions for BIER non-MPLS
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-bier-lsr-non-mpls-extensions-03, 7 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
lsr-non-mpls-extensions-03>.
[I-D.ietf-bier-non-mpls-bift-encoding]
Wijnands, I., Mishra, M. P., Xu, X., and H. Bidgoli, "An
Optional Encoding of the BIFT-id Field in the non-MPLS
BIER Encapsulation", Work in Progress, Internet-Draft,
draft-ietf-bier-non-mpls-bift-encoding-04, 30 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
non-mpls-bift-encoding-04>.
[I-D.ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding (CSID)", Work
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-23, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-23>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/rfc/rfc2460>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727,
DOI 10.17487/RFC4727, November 2006,
<https://www.rfc-editor.org/rfc/rfc4727>.
[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/rfc/rfc6554>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/rfc/rfc7988>.
Eckert Expires 4 September 2025 [Page 17]
Internet-Draft msr6-rbs March 2025
[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/rfc/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/rfc/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/rfc/rfc8296>.
[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/rfc/rfc8754>.
[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/rfc/rfc8986>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/rfc/rfc8994>.
[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/rfc/rfc9262>.
Appendix A. Changelog
00: initial version.
Appendix B. History
This document is an evolution from the process whose last draft was
[I-D.eckert-msr6-problem-statement]. That informational draft covers
in a more concise way two core problem areas
Eckert Expires 4 September 2025 [Page 18]
Internet-Draft msr6-rbs March 2025
1. The Desire and need for an IPv6 routing extension header based
solution architecture for stateless IPv6 multicast source routing
in support of IPv6/SSRv6-only networks. This is covered in
P4...P7 and according explanationsj.
2. The desire and need for an easier to operate and better to scale
stateless replication mechanism instad of [RFC8279], such as
proposals like [I-D.eckert-pim-rts-forwarding] or
[I-D.eckert-msr6-rbs]. These are covered in P1...P3,P8 and
according explanations.
Point 1 in that problem state document can be resolved by an IPv6
routing extension header based solution, which is what this document
explains in more detail and proposes to introduce through
experimental IETF work.
It is thus overlapping with that problem statments P4...P7. Such an
IPv6 routing extension header based solution can and should leverage
both an [RFC8279] based payload, which would allow a minimal change
and new development from existing BIER specifciations, replacing only
[RFC8296] as the encapsulation and replacing the need for
[I-D.ietf-bier-bierin6].
Point 2 is not detailled in this document except to explain what
aspects in the new IPv6 routing extension header are required to
enable such alternative encodings compared to the existing BIER
bitstring.
Author's Address
Toerless Eckert
Futurewei Technologies USA
United States of America
Email: tte@cs.fau.de
Eckert Expires 4 September 2025 [Page 19]