Bit Indexed Explicit Replication (bier)
|WG||Name||Bit Indexed Explicit Replication|
|Area||Routing Area (rtg)|
|Dependencies||Document dependency graph (SVG)|
|Jabber chat||Room address||xmpp:email@example.com?join|
Charter for Working Group
In conventional IP multicast forwarding, the packets of a given
multicast "flow" are forwarded along a tree that has been constructed
for the specific purpose of carrying that flow. This requires transit
nodes to maintain state on a per-flow basis, and requires the transit
nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.
BIER (Bit Index Explicit Replication) is an alternative method of
multicast forwarding. It does not require any multicast-specific
trees, and hence does not require any multicast-specific tree building
protocols. Within a given "BIER domain", an ingress node encapsulates
a multicast data packet in a "BIER header". The BIER header
identifies the packet's egress nodes in that domain. Each possible
egress node is represented by a a single bit within a bitstring; to
send a packet to a particular set of egress nodes, the ingress node
sets the bits for each of those egress nodes, and clears the other
bits in the bistring. Each packet can then be forwarded along the
unicast shortest path tree from the ingress node to the egress nodes.
Thus there are no per-flow forwarding entries.
Due to the particular sensitivity of adding new significant
functionality into the data-plane at high link speeds, the BIER work
will progress as Experimental. The scope of the experiment will be
documented in the output of the Working Group. As described in
item (9) below, the work may become Standards Track once there
is sufficient experience with the benefits and downsides of the technology.
BIER is initially chartered to do experimental work on this new
multicast forwarding mechanism as follows:
1) BIER architecture: The WG will publish an architecture, based
upon draft-wijnands-bier-architecture-04. It will discuss the
security properties of BIER. It will include the normative
algorithm for how BIER packet forwarding is done. It will specify
the information that is required to be in a BIER header so that a
router can support BIER forwarding.
2) BIER encapsulation: The working group should assume that the
technology will need to be embedded in the data plane and operate
at very high packet line speeds. The WG will publish a document
defining an MPLS-based encapsulation based upon
draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
to have a high-quality and stable RFC for a new data-plane
encapsulation, the MPLS-based encapsulation draft shall wait after
WGLC and not progress to IETF Last Call until there are two
independent interoperable implementations.
As a secondary focus, the WG may also work on one non-MPLS
data-plane encapsulation. This draft also shall wait after WGLC
and not progress to IETF Last Call until there are two independent
interoperable implementations. This draft must focus on and
include the following details:
a) What is the applicability of the encapsulation and for which
use-cases is this encapsulation required?
b) Does this proposed encapsulation imply any changes to the
c) What design choices have been made for the encapsulation
type and the included fields.
d) The proposed encapsulation with considerations given to at
least OAM, Class of Service, security, fragmentation, TTL.
3) Transition Mechanisms: The WG will describe how BIER can be
partially deployed and still provide useful functionality. A
minimum of the necessary mechanisms to support incremental
deployment and/or managing different BIER mask-length compatibility
may be defined. Each such mechanism must include an applicability
statement to differentiate its necessity from other proposed
4) Applicability Statements: The WG will describe how BIER can be
applied to multicast L3VPN and to EVPN. This draft will describe
what mechanism is used to communicate the group membership between
the ingress router and the egress routers, what scalability
considerations may arise, and any deployment considerations. The WG
will work on additional applicability statements, as needed,
describing how BIER can be applied; for example, this may be needed
to clarify how a non-MPLS data-plane encapsulation would be used.
5) Use Case: The WG may produce one use-case document that clearly
articulates the potential benefits of BIER for different use-cases.
This would be based upon draft-kumar-bier-use-cases-01.
6) Manageability and OAM: The WG will describe how OAM will work in a
BIER domain and what simplifications BIER offers for managing the
multicast traffic. A strong preference will be given to extensions
to existing protocols.
7) Management models: The WG may work on YANG models and, if needed,
MIB modules to support common manageability.
8) IGP extensions. When a BIER domain falls within a "link state
IGP"" network, the information needed to set up the BIER forwarding
tables (e.g., the mapping between a given bit position and a given
egress router) may be carried in the link state advertisements of the
IGP. The link state advertisments may also carry other information
related to forwarding (e.g., the IGP may support multiple topologies,
in which case it may be necessary to advertise which topologies are
to be used for BIER forwarding). Any necessary extensions to the IGP
will be specified by the WG as Experimental, in cooperation with the
ISIS and OSPF WGs.
9) Deployment Evaluation: Once there is deployment experience, the
WG will produce an Informational RFC describing the benefits,
problems, and trade-offs for using BIER instead of traditional
multicast forwarding mechanisms. Ideally, this should also contain
an analysis of the impact and benefit of the new BIER data-plane to
the overall Internet architecture. This document is intended to be
used to evaluate whether to recharter BIER to produce Standards
The BIER working group will coordinate with several different working
groups and must include the relevant other working groups during
working group last call on the relevant drafts. BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based
OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions
to flood BIER-related information. BIER will coordinate with BESS and
IDR on the applicability of existing BGP-based mechanisms for
providing multicast group membership information. BIER will coordinate
with PIM on the applicability of and extensions to PIM, IGMP, and MLD
to support BIER; BIER will work directly on the applicability
statements, as needed.
|Dec 2024||WG Last Call on draft related to BIER deployment experience|
|Dec 2024||WG Last Call on draft related to BIER YANG Model / MIB|
|Dec 2024||WG Last Call on draft related to BIER Transition Mechanisms|
|Dec 2024||WG Last Call on draft related to BIER OAM|
|Dec 2024||WG Last Call on draft related to BIER use cases|
|Dec 2024||WG Last Call on draft related to BIER MVPNs|
|Dec 2024||WG Last Call on draft related to BIER MPLS encapsulation|
|Dec 2024||WG Last Call on draft related to BIER architecture|
|Dec 2024||WG Call for Adoption of draft related to BIER deployment experience|
|Aug 2015||WG Last Call on draft related to ISIS BIER ranges|
|Aug 2015||WG Last Call on draft related to OSPF BIER extensions|
|Aug 2015||WG Last Call on draft related to BIER problem statement|
|Jul 2015||WG Call for Adoption of draft related to BIER YANG Model / MIB|
|Jul 2015||WG Call for Adoption of draft related to BIER Transition Mechanisms|
|Mar 2015||WG Call for Adoption of draft related to BIER OAM|
|Mar 2015||WG Call for Adoption of draft related to BIER use cases|
|Mar 2015||WG Call for Adoption of draft related to ISIS BIER ranges|
|Mar 2015||WG Call for Adoption of draft related to BIER MVPNs|
|Mar 2015||WG Call for Adoption of draft related to OSPF BIER extensions|
|Mar 2015||WG Call for Adoption of draft related to BIER MPLS encapsulation|
|Mar 2015||WG Call for Adoption of draft related to BIER problem statement|