]> Bit Index Explicit Replication (BIER) Ping and Trace Cisco Systems, Inc.
7200 Kit Creek Road Research Triangle Park, NC 27709 US naikumar@cisco.com
North Carolina State University
United States of America cpignata@gmail.com cmpignat@ncsu.edu
Huawei Technologies
mach.chen@huawei.com
Independent
gregimirsky@gmail.com
Network Work group Bit Index Explicit Replication (BIER) is a multicast forwarding architecture designed to simplify and optimize multicast delivery. This document specifies the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane without any dependency on other layers, like the IP layer.
Introduction introduces and explains BIER architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast-related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is specified by setting the bits that correspond to those routers in the BIER header. Similarly, the Initiator of the BIER OAM packet controls the set of BFRs to which the BIER OAM packet is addressed by setting bits in the BitString field of the BIER header that correspond to the BFR-ID values of those BFRs. Operations, Administration, and Maintenance (OAM) mechanisms are expected to support the detection of network failures. After the detection, operators localize and characterize the network defect. A query-based tool, e.g., ICMP and LSP Ping , , is broadly used to detect and localize a network defect. Additionally, this mechanism can be used to check the consistency between the data and control planes. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane without any dependency on other layers, like the IP layer. The specification conforms to R-1 through R-3, R-5, and R-11 requirements listed in . To conform to R-11, BIER Echo Request message is encapsulated in the BIER header that uses the same values of BIFT-id, BSL, Entropy, and DSCP fields as in the BIER header of the monitored BIER flow. Note that the BIER Echo Request/Reply protocol doesn't modify the content of the OAM field in the BIER header (Section 2 of ).
Conventions used in this document
Terminology and Acronyms In this specification, the term "Initiator" is used interchangeably with the "Sender of a BIER Echo Request". BFER - Bit-Forwarding Egress Router BFIR - Bit-Forwarding Ingress Router BFR - Bit-Forwarding Router BIER - Bit Index Explicit Replication DDMAP - Downstream Detailed Mapping TLV ECMP - Equal Cost Multi-Path OAM - Operation, Administration, and Maintenance SI - Set Identifier QTF - Querier Timestamp Format RTF - Responder Timestamp Format NTP - Network Time Protocol MTU - Maximum Transmission Unit DA - Downstream Address DIA - Downstream Interface Address DoS - Denial-of-Service PTP - Precision Time Protocol
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
BIER OAM BIER OAM is defined to stay within the BIER layer by directly following the BIER header without mandating the need for an IP header. To produce information that is useful to an operator, information that statistically reflects conditions experienced by the monitored data flow, the operator must be able to ensure that active OAM packets, e.g., BIER Echo Request, traverse the set of links and nodes and receive the same forwarding treatment as the monitored flow. Hence, all fields in the BIER header that affect packet forwarding (e.g., BFIR-id, BitString) must be set to the values applied to the monitored data flow. defines a 4-bit field as "Proto" to identify the payload following the BIER header. When the payload is BIER OAM, the "Proto" field will be set to 5 as defined in .
BIER OAM Message Format The BIER OAM packet header format that follows the BIER header is displayed in .
BIER OAM Header 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 Ver MessageType Proto Reserved OAM Message Length ~ Message Type Dependent Data ~
  • Ver - a four-bit field that indicates the version of the BIER OAM header. The value defined in this document is 1. The version number is to be incremented whenever a change is made that affects the ability of an implementation to parse or process the BIER OAM header correctly. For example, if syntactic or semantic changes are made to any of the fixed fields.
  • Message Type - a six-bit field that identifies OAM protocol. Values defined in this document are as in .
BIER Echo Type
Value Description
1 BIER Echo Request
2 BIER Echo Reply
  • Proto - a six-bit field. This field is used to define whether there is any data packet immediately following the OAM payload. For example, the In-situ OAM Direct Export Option header can be appended to the BIER OAM message, enabling the collection of the operational state and performance metrics. This field MUST be set to 0 if no data packet follows the OAM payload. Otherwise, the value is one from the IANA registry "BIER Next Protocol Identifiers" .
  • Reserved - a two-octet field. The value MUST be zeroed on transmission and ignored on receipt.
  • OAM Message Length - a four-octet field that reflects the length of the OAM message in octets, including the header and the Messsage Type Dependent Data.
  • Message Type Dependant Data - a variable-length field that includes the OAM message identified by the value of the Message Type field.
BIER Echo Request/Reply Message Format The Echo Request/Reply header format is displayed in
BIER Echo Request/Reply 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 Ver Echo Req/Rep Proto Reserved BIER Echo Request/Reply Length QTF RTF Reply Mode Return Code Reserved2 Sender's Handle Sequence Number Timestamp Sent Timestamp Received ~ TLVs ~
  • Proto field MUST be set to 0 for Echo Request/Reply header.
  • BIER Echo Request/Reply Length a four-octet field that reflects the length of the BIER Echo Request/Reply message in octets, including the BIER OAM header .
  • QTF (Querier Timestamp Format) - a four-bit field. When the field is set to 2, the Timestamp Sent field is (in seconds and picoseconds, according to the Initiator's clock) in the 64-bit long NTP format . When the value of the QTF field is 3, the Timestamp Sent field is in the IEEE 1588-2008 (1588v2) Precision Time Protocol (PTP) format.
  • RTF (Responder Timestamp Format) - a four-bit field. When the field is set to 2, the Timestamp Received field is (in seconds and picoseconds, according to the Initiator's clock) in 64-bit long NTP format . When field's value is 3, the format of the Timestamp Received is as defined in IEEE 1588-2008 (1588v2) Precision Time Protocol . The Initiator MUST zero RTF in the Echo Request, and the Responder MUST ignore the value on receipt.
The sender of the BIER Echo Request might receive the BIER Echo Reply with RTF different from the Sender's QTF. Thus, to calculate one-way delay, the Sender MUST be able to interpret both timestamp formats, i.e., NTP and PTP . Although the use of different timestamp formats is permitted, it may cause ambiguity or even precision loss resulting from format conversion. Thus, the use of homogeneous formats is RECOMMENDED.
  • The Reply Mode - a one-octet field. The value MUST be set to one of the values from .
BIER Reply Mode
Value Description
1 Do not Reply
2 Reply via IPv4/IPv6 UDP packet
3 Reply via BIER packett
  • When Reply Mode is set to 1, the receiver will not send any reply. This mode can be used for unidirectional path validation. When the Reply Mode is set to 2, the Responder Bit-Forwarding Router (BFR) encapsulates the Echo reply payload with the IP/UDP header. The Responder BFR uses the BFIR-id field in the BIER header to determine which IP address family to use in the IP/UDP encaspulation. When the Initiator intends to validate the return BIER path, the Reply Mode will be set to 3 so that the Responder BFR will encapsulate the Echo Reply with the BIER header. Also, the Reply Mode "Reply via BIER packet" can be used if the IP network is deemed less reliable compared to the BIER layer.
  • Return Code - a one-octet field. The value MUST be set to zero if the Type is "BIER Echo Request". The value of the Return Code field MUST be set to one of the values defined in , if the Type is "BIER Echo Reply".
  • Reserved2 - a one-octet field. The Reserved field MUST be zeroed on transmit and MUST be ignored on receipt.
  • Sender's Handle - a four-octet field. The Sender's Handle is filled by the Initiator, and returned unchanged by responder BFR. This value can be used for matching the replies to the request (see ).
  • Sequence Number - a four-octet field. The value of the field is assigned by the Initiator and can be used to detect any missed replies.
  • Timestamp - each field (Sent and Received) is an eight-octet field. The Timestamp Sent is the time when the Echo Request is sent. The Timestamp Received in Echo Reply is the time (accordingly to responding BFR clock) that the corresponding Echo Request was received. The format depends on the QTF/RTF value. The Initiator MUST zero Timestamp Received in the Echo Request, and the Responder MUST ignore the value on receipt.
  • TLVs - Carries the TLVs as defined in .
Return Code The responder uses the Return Code field to reply with a validity check or other error message to Initiator. It does not carry any meaning in Echo Request and MUST be set to zero. The Return Code can be one of the values in . BIER Return Code
Value Description
0 No return code
1 Malformed Echo Request received
2 One or more of the TLVs is not supported
3 Replying BFR is the only BFER in header BitString
4 Replying BFR is one of the BFERs in header BitString
5 Packet-Forward-Success
6 Invalid Multipath Info Request
7 One or more of the TLVs is not supported
8 No matching entry in the forwarding table
9 Set-Identifier Mismatch
10 DDMAP Mismatch
"No return code" will be used by Initiator in the Echo Request. This value MUST NOT be used in Echo Reply. "Malformed Echo Request received" will be used by any BFR if the received Echo Request packet is not properly formatted. When a receiver does not support any TLV included in the Echo Request, the Return code will be set to "One or more of the TLVs is not supported" carrying the respective TLVs. When the received header BitString in the Echo Request packet contains only its BFR-ID, "Replying BFR is the only BFER in header BitString" is set in the reply. This value implies that the receiver is BFER, and the packet is not forwarded to any more neighbors. When the received header BitString in the Echo Request packet contains its BFR-ID in addition to other BFR-IDs, "Replying BFR is one of the BFERs in header BitString" is set in the reply. This value implies that the responder is a BFER and the packet is further forwarded to one or more neighbors. Any transit BFR will send the Echo Reply with "Packet-Forward-Success", if the TLV in the received Echo Request is understood and the forwarding table has forwarding entries for the BitString. This behavior is demonstrated by a transit BFR during traceroute mode. When the Echo Request is received with multipath info () for more than one BFER, the Return Code is set to "Invalid Multipath Info Request". If the BitString cannot be matched in the local forwarding table, the BFR will use "No matching entry in the forwarding table" in the reply. If the BIER-MPLS label in the received Echo Request is not the one assigned for SI in Original SI-BitString TLV, "Set-Identifier Mismatch" is set in order to report the mismatch. If the BitString in Header-H does not match the BitString in Egress BitString Sub-TLV of DDMAP TLV, a responding BFR will use "DDMAP Mismatch" to report the problem.
BIER OAM TLVs This section defines various TLVs that can be used in BIER OAM packet. The TLVs (Type-Length-Value tuples) have the following format:
Type-Length-Value Format Used in BIER Echo Request/Reply 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 ~ Value ~
TLV Types are defined below. A system that receives an Echo Request with unknown TLV Type with the value in the range 0 - 32767 MUST transmit an Echo Reply with the Return Code "One or more of the TLVs is not supported" (2). Also, the Erroneous Echo Request TLV () MUST be included in the BIER Echo Reply. A system that receives an Echo Request with the value in the range 32768 - 65535 MAY silently drop the packet. Length is the length of the Value field in octets. The Value field depends on the TLV Type.
Original SI-BitString TLV The Original SI-BitString TLV carries the set of BFERs and carries the same BitString that the Initiator includes in the BIER header. This TLV has the following format:
The Format of the Original SI-BitString TLV 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 = 1 Length = variable Set ID Sub-domain ID BS Len Reserved BitString (first 32 bits) ~ ~ ~ BitString (last 32 bits)
Set ID - a one-octet field that is set to the value of the Set Identifier to which the BitString belongs. This value is derived as defined in . Sub-domain ID - a one-octet field that is set to the Sub-domain value to which BFER in BitString belongs. BS Len - a four-bit field that is set based on the length of BitString as defined in reflected in four-octet words. Reserved - a twelve-bit field. Its value MUST be zeroed on transmission and ignored on receipt. BitString - a variable length field. The BitString field carries the set of BFR-IDs that Initiator will include in the BIER header. Any Initiator MUST include this TLV in the Echo Request packet. A Responder MUST NOT include this TLV in the Echo Reply packet.
Target SI-BitString TLV The Target SI-BitString TLV carries the set of BFERs from which the Initiator expects the reply. This TLV has the following format:
The Format of the Target SI-BitString TLV 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 = 2 Length = variable Set ID Sub-domain ID BS Len Reserved BitString (first 32 bits) ~ ~ ~ BitString (last 32 bits)
Set ID field is set to the Set Identifier to which the BitString belongs.This value is derived as defined in . Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs. BS Len is set based on the length of BitString as defined in Reserved - the value MUST be zeroed on transmission and ignored on receipt. The BitString field carries the set of BFR-IDs of BFER(s) that Initiator expects a response. The BitString in this TLV may be different from the BitString in the BIER header and allows control of the BFER responding to the Echo Request. This TLV MUST be included by Initiator in the BIER OAM packet if the Downstream Mapping TLV () is included.
Incoming SI-BitString TLV The Incoming SI-BitString TLV will be included by Responder BFR in Reply message and copies the BitString from the BIER header of incoming Echo Request message. This TLV has the following format:
The Format of the Incoming SI-BitString TLV 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 = 3 Length = variable Set ID Sub-domain ID BS Len Reserved BitString (first 32 bits) ~ ~ ~ BitString (last 32 bits)
Set ID field is set to the Set Identifier to which the BitString belongs. This value is derived as defined in Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs. BS Len is set based on the length of BitString as defined in . Reserved - the value MUST be zeroed on transmission and ignored on receipt. The BitString field copies the BitString from the BIER header of the incoming Echo Request. A Responder BFR SHOULD include this TLV in Echo Reply if the Echo Request is received with the I flag set in Downstream Mapping TLV. An Initiator MUST NOT include this TLV in Echo Request.
Downstream Mapping TLV
This TLV has the following format:
The Format of the Downstream Mapping TLV 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 = 4 Length = variable MTU Address Type Flags Downstream Address (4 or 16 octets) Downstream Interface Address (4 or 16 octets) Sub-TLVs Length . . . List of Sub-TLVs .
MTU
A two-octet field. The value is the Maximum Transmission Unit (MTU) value of the egress interface.
Address Type
A one-octet field. The Address Type indicates the address type and length of the IP address for the downstream interface. The value of the Address Type field is set to one of the values listed in . Any other value MUST be processed as invalid TLV.
The Address Types
Value Address Type
1 IPv4 Numbered
2 IPv4 Unnumbered
3 IPv6 Global Unicast Address (including Unique Local Address)
4 IPv6 Link-Local Address Only
Flags
The Flags field has the following format:
The Flags Field Format 0 1 2 3 4 5 6 7 Reserved I
Reserved - a seven-bit field. Its value MUST be zeroed on transmission and ignored on receipt. I - a one-bit field. When I flag is set, the Responding BFR MUST include the Incoming SI- BitString TLV in Echo Reply message.
Downstream Address and Downstream Interface Address
each field is either four-octet or sixteen-octet, depending on the value of Address Type field. Note that values of the Address Type field are mapped to combinations of lengths of Downstream Address (DA) and Donstream Address Interface (DIA) fields as shown im . The Address Type Lengths
Value DA Length DIA Length
1 4 4
2 4 4
3 16 16
4 16 4
where:
DA Length
Downstream Address field Length
DIA Length
Downstream Interface Address field Length
If the Address Type is "IPv4 Numbered" (1), the Downstream Address field MUST be set to IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the downstream interface address. If the Address Type is "IPv4 Unnumbered" (2), the Downstream Address field MUST be set to IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the index assigned by the responding BFR to the interface. If the Address Type is "IPv6 Global Unicast Address (including Unique Local Address)" (3), the Downstream Address MUST be set to IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the downstream interface IPv6 Global Unicast Address (including Unique Local Address). If the Address Type is "IPv6 Link-Local Address Only" (4), the Downstream Address MUST be set to the IPv6 BFR-Prefix of the downstream BFR, and the Downstream Interface Address is set to the index assigned by the responding BFR to the interface.
Downstream Detailed Mapping Sub-TLVs This section defines the optional Sub-TLVs that can be included in Downstream Mapping TLV in . Sub-TLV for the Downstream Mapping TLV
Value Description
1 Multipath Entropy Data
2 Egress BitString
Any value other than listed in MUST be considered as invalid, the Return Code set to Malformed Echo Request received (1). Also, the Erroneous Echo Request TLV () MUST be included in the BIER Echo Reply.
MPLS Multipath Entropy Data Sub-TLV MPLS Multipath Entropy Data sub-TLV is applicable for BIER Echo Request packets encapsulated in MPLS. Encoding of multipath information for other data planes, e.g., IPv6, is for further study. If the MPLS Multipath Entropy Data sub-TLV is present in the BIER Echo Request packet encapsulated in a non-MPLS data plane, it MUST be ignored by the responding BFR.
The Format of the Multipath Data Blob 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 = 1 Length = variable M Reserved Multipath Type (Multipath Information)
M Flag
This flag is set to 0 if all packets will be forwarded out through the interface defined in the Downstream Mapping TLV. When set to 1, Multipath Information will be defined by the Bit masked Entropy data.
Reserved
The value MUST be zeroed on transmission and ignored on receipt.
The interpretaion of the Multipath Type field and Multipath Entropy Data encoding options are the same defined in Section 3.4.1.1 of .
Egress BitString Sub-TLV Responder BFR MAY include this Sub-TLV with the rewritten BitString in the outgoing interface as defined in Section 6.1 of .
The Egress BitString Sub-TLV 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 Type = 2 Length = variable Set ID Sub-domain ID BS Len Reserved BitString (first 32 bits) ~ ~ ~ BitString (last 32 bits)
Set ID field is set to the Set Identifier to which the BitString belongs. This value is derived as defined in . Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs. BS Len is set based on the length of BitString as defined in . Reserved - the value MUST be zeroed on transmission and ignored on receipt. The BitString field copies the rewritten BitString in the outgoing interface as defined in Section 6.1 of .
Responder BFER TLV The BFER replying to the request MAY include the Responder BFER TLV in its BIER Echo Reply. An Initiator MUST NOT include this TLV in Echo Request. This TLV identifies the originator of BIER Echo Reply. This TLV has the following format:
The Responder BFER TLV 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 Type = 5 Length = 4 Reserved BFR-ID
Length
A two-octet field. The value MUST be set to four.
Reserved
A two-octet field. The value MUST be zeroed on transmission and ignored on receipt.
BFR-ID
A two-octet field. The BFR-ID field carries the BFR-ID of the replying BFER. This TLV MAY be included by the Responding BFER in the BIER Echo Reply packet.
Responder BFR TLV Any transit BFR replying to the request MAY include the Responder BFR TLV in its BIER Echo Reply. An Initiator MUST NOT include this TLV in Echo Request. This is used to identify the replying BFR without BFR-ID. This TLV has the following format:
The Responder BFR TLV 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 TLV Type = 6 Length = 8 or 20 Reserved Address Type ~ BFR-Prefix (4 or 16 bytes) ~
Length
The Length field, depending on the Address Type value - 8 or 20.
Reserved
A two-octet field. The value MUST be zeroed on transmission and ignored on receipt.
Address Type
A two-octet field. Set to 1 for IPv4 or 2 for IPv6.
BFR-Prefix
This field carries the local BFR-Prefix of the replying BFR. This TLV MAY be included by Responding BFR in BIER Echo Reply packet.
Ingress Interface TLV The BFR replying to the request MUST include the Ingress Interface TLV. This TLV identifies the incoming interface on which the Echo Request was received. This TLV has the following format:
The Ingress Interface TLV 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 TLV Type = 7 Length = 8 or 20 Reserved Address Type ~ Ingress Interface Address (4 or 16 bytes) ~
Length
The Length field, depending on the Address Type value - 8 or 20.
Reserved
A two-octet field. The value MUST be zeroed on transmission and ignored on receipt.
Address Type
A two-octet field. Set to 1 for IPv4 Numbered, 2 for IPv4 Unnumbered, 3 for IPv6 Global Unicast Address (including Unique Local Address), or 4 for IPv6 Link-Local Address Only.
Ingress Interface Address
A four or sixteen-octet-long field. It lists an address associated with the interface on which the BIER Echo Request received.
Erroneous Echo Request TLV The BFER replying to the request MAY include the Erroneous Echo Request TLV. This TLV provides information about the type and location of the problem in the BIER Echo Request. This TLV has the following format:
The Erroneous Echo Request TLV 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 Type = 8 Length = variable Pointer As much of invoking BIER Echo Request ~ as possible without exceeding path MTU ~
Pointer
A four-octet field that identifies the octet offset within the received BIER Echo Request message where the error was detected. The Pointer will point beyond the end of the BIER Echo Reply message if the field in error is beyond what can fit in the resulting packet.
BIER Ping and Traceroute Operations This section describes aspects of BIER ping and traceroute operations.
BIER OAM Processing A BIER OAM packet MUST be punted to the BIER control plane for OAM processing if one of the following conditions is true:
  • The receiving BFR is a BFER.
  • TTL of BIER-MPLS Label (Section 2.1.1.1 of ) expired.
  • Hop Limit in the IPv6 header (Section 2 of ) expired.
The use of the Router Alert label has been deprecated by . Processing of the received BIER OAM packet with unknown value of the Message Type field () is stopped and the event MUST be logged although through the rate-controlling system. A transit BFR, i.e., one that does not punt the BIER OAM packet to the BIER control plane, forwards the BIER OAM packet according to the rules specified in Section 6.5 of .
BFER ECMP Discovery Within a BIER Domain with MPLS Underlay As defined in , BIER follows the unicast forwarding path and allows load balancing over ECMP paths between BFIR and BFER. BIER OAM is expected to support ECMP path discovery between a BFIR and a given BFER and MUST support path validation and failure detection of any particular ECMP path between BFIR and BFER. proposes the BIER header with the Entropy field that can be leveraged to exercise all ECMP paths. The Initiator/BFIR will use a traceroute message to query each hop about the Entropy information for each of the downstream paths. To avoid complexity, it is suggested that the ECMP query is performed per BFER by carrying the required information in the BIER OAM message. When an operator performs BFER ECMP discovery within a BIER domain over MPLS underlay, the Initiator MUST include MPLS Multipath Entropy Data Sub-TLV in Downstream Mapping TLV. It MUST also include the BFER in the BitString TLV to which the Multipath query is performed. Any transit BFR will transmit the BIER Echo Reply to the Initiator with Bit-masked Entropy for each downstream path as defined in .
Sending BIER Echo Request The Initiator MUST set the Message Type as 1 and Return Code as 0. The Proto field in the OAM packet MUST be set to 0. The choice of the Sender's Handle and Sequence Number is a local matter to the Initiator and the Initiator MUST monotonically increase the Sequence Number, e.g., increment it by one for every, subsequent Echo Request. The QTF field is set to Initiator's local timestamp format, and the TimeStamp Sent field is set to the time that the Echo Request is sent. The Initiator MUST include Original SI-BitString TLV. The Initiator MUST NOT include more than one Original SI-BitString TLV. The Initiator infers the Set Identifier value and Sub-domain ID value from the respective BitString that will be included in the BIER header of the packet and includes the values in "SI" and Sub-Domain ID fields, respectively. In Ping mode, the Initiator MAY include Target SI-BitString TLV to control the responding BFER(s) by listing all the BFERs from which the Initiator expects a response. In the traceroute mode, the Initiator MAY include Target SI-BitString TLV to control the path trace towards any specific BFER or set of BFERs. The Initiator on receiving a reply with the Return code "Replying BFR is the only BFER in the header BitString" or "Replying router is one of the BFERs in header BitString" MUST unset the respective BFR-ID from Target SI-BitString for any subsequent Echo Request. The Initiator MAY include Downstream Mapping TLV () in the Echo Request to query additional information from transit BFRs and BFERs. In case of ECMP discovery within a BIER domain with the MPLS underlay, the Initiator MUST include the MPLS Multipath Entropy Data Sub-TLV and MUST set the Target SI-BitString TLV carrying a specific BFER ID. The Initiator MUST encapsulate the OAM packet with the BIER header and MUST set the Proto as 5 and further encapsulates with BIER-MPLS label. In ping mode, the BIER-MPLS Label TTL MUST be set to 255. In traceroute mode, the BIER-MPLS Label TTL is set successively, starting from 1 and MUST stop sending the Echo Request if it receives a reply with Return code as "Replying router is the only BFER in BIER header BitString" from all BFER listed in Target SI-BitString TLV.
Receiving BIER Echo Request Sending a BIER OAM Echo Request to control plane for payload processing is triggered as mentioned in . Any BFR on receiving an Echo Request MUST perform the basic sanity check, including, but not limited to, checking values of the fields with a priori known values, e.g., Ver, Type and Length if any TLV is present. If, at any stage of processing the received BIER Echo Request, the BFR encounters an error, it MUST stop processing and transmit BIER Echo Reply with the Return Code set accordingly. If the BFR cannot parse the OAM packet completely because the value in the OAM Message Length field is incorrect, BFR MUST send Echo Reply with Return Code set to "Malformed Echo Request received" if the OAM Message Length is incorrect. The Erroneous Echo Request TLV () MUST be included in the BIER Echo Reply. If the packet sanity check is fine, it MUST initiate the below set of variables:
Reply-Flag
This flag is initially set to 1.
Interface-I
The incoming interface on which the Echo Request was received. This MAY be used to validate the Downstream Detailed Mapping TLV (DDMAP) info and populate the Ingress Interface TLV.
BIER-Label-L
The BIER-MPLS Label received as the top label of the received Echo Request. This MAY be used to validate if the packet is traversing the desired Set Identifier and sub-domain path.
Header-H
The BIER header of the received Echo Request. It can be used to validate the DDMAP info and to populate the Incoming SI-BitString TLV. Also, it can be used to perform entropy calculation considering a different field in the header and replying with MPLS Multipath Entropy Data Sub-TLV.
Best-return-code
contains the Return Code for the echo reply packet as currently best known. As the algorithm progresses, this code may change depending on the results of further checks that it performs.
BFR MUST initialize the internal, to the implementation, Best-return-code variable to the null value. BFR will populate the Interface-I with the identifier of the interface over which the Echo Request is received, the top label in the MPLS stack of the received Echo Request to BIER-Label-L, and the BIER header to Header-H. If the received Echo Request carries Target SI-BitString TLV, a BFR MUST run the boolean AND operation between BitString in Header-H and BitString in Target SI-BitString TLV. If the resulting BitString is all-zero, reset Reply-Flag=0 and go to . Else:
  • If the BIER-Label-L does not correspond to the local label assigned for {sub-domain, BitStringLen, SI} in Original SI- BitString TLV, Set the Best-return-code to "Set-Identifier Mismatch" and Go to .
The step above allows the detection of a synchronization problem in the upstream BFR between BIER-Label and {sub-domain, BitStringLen, SI} that might cause an unintended packet leak between sub-domains.
  • If the value in the Return Mode field is unknown, the Receiver MUST set Reply-Flag=0 and go to .
  • The Receiver sets the Best-return-code to"Malformed Echo Request received" if the value of the QTF field is neither 2, nor 3. Also, the Erroneous Echo Request TLV () MUST be included in the BIER Echo Reply. Go to .
  • Set the Best-return-code to "One or more of the TLVs is not supported" if any of the TLVs in the Echo Request message is not supported. Go to .
  • If the BitString in Header-H does not match the BitString in Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to "DDMAP Mismatch" and go to . When there are more than one DDMAP TLV in the received Request packet, the Downstream Address and Downstream Interface Address should be matched with Interface-I to identify the right DDMAP TLV and then perform the BitString match.
The step above allows the detection of a deviation between the BIER control plane and the BIER forwarding plane in the upstream node that may result in a forwarding loop or packet duplication.
  • Set the Best-return-code to "Invalid Multipath Info Request", when the DDMAP TLV carries MPLS Multipath Entropy Data Sub-TLV, and if the Target SI-BitString TLV in the received Echo Request carries more than 1 BFER id. Go to . Else, list the ECMP downstream neighbors to reach BFR-ID in Target SI-BitString TLV, calculate the Entropy considering the BitString in Header-H and MPLS Multipath Entropy Data Sub-TLV from received Echo Request. Store the Data for each Downstream interface in a temporary variable. Set the Best-return-code to 5 (Packet-Forward-Success) and goto
This step instructs the node to calculate the Entropy Data for each downstream interface to reach the BFER in Target SI-BitString TLV by considering the incoming BitString and Entropy Data.
  • Set the Best-return-code to "Replying router is the only BFER in BIER header BitString", and go to if the responder is BFER and there are no more bits in the BIER header BitString left for forwarding.
  • Set the Best-return-code to "Replying router is one of the BFERs in BIER header BitString", and include Downstream Mapping TLV if the responder is BFER and there are more bits in BitString left for forwarding. Also, include the Multipath information as defined in if the received Echo Request carries Multipath Entropy Data Sub-TLV. Go to .
  • Set the Best-return-code to "No matching entry in the forwarding table", if the forwarding lookup, defined in Section 6.5 of does not match any entry for the received BitString in BIER header.
The step above allows the detection of the missing BFR-ID in the node's BIER forwarding table. It is difficult to detect the absence of the BFR-ID if the Request includes more than one BFR-IDs in the BitString and so may need to include the BFER-id that is not responding to detect such failure.
  • Set the Best-return-code to "Packet-Forward-Success", and include Downstream Mapping TLV. Go to .
Sending Echo Reply If Reply-Flag=0, BFR MUST release the variables and MUST NOT send any response to the Initiator. If Reply-Flag=1, proceed as below: The Responder BFR MUST include the BitString from Header-H to Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and BS Len that corresponds to BIER-Label-L. Responder BFR MUST include the Ingress Interface TLV and populate the address from Interface-I. When the Best-return-code is "Replying BFR is one of the BFERs in header BitString", it MUST include Responder BFER TLV.
If the received Echo Request had DDMAP with Multipath Entropy Data Sub-TLV, Responder BFR MUST include DDMAP as defined in for each outgoing interface over which the packet will be replicated and include the respective Multipath Entropy Data Sub-TLV. For each outgoing interface, the respective Egress BitString MUST be included in DDMAP TLV.
If the received Echo Request had DDMAP without Multipath Entropy Data Sub-TLV, Responder BFR MUST include DDMAP as defined in for each outgoing interface over which the packet will be replicated. For each outgoing interface, respective Egress BitString MUST be included in DDMAP TLV.
When the Best-return-code is "Replying BFR is the only BFER in header BitString", it MUST include Responder BFER TLV. The Responder MUST set the Message Type as 2 and Return Code as Best- return-code. The Proto field MUST be set to 0. The Echo Reply can be sent as BIER-encapsulated, or IP/UDP encapsulated, depending on the Reply Mode in the received Echo Request. When the Reply Mode in the received Echo Request is set to 3, Responder appends the BIER header listing the BitString with BFIR ID (from Header-H), sets the Proto to 5, and sets the BFIR as 0. When the Reply Mode in the received Echo Request is set to 2, Responder encapsulates with the IP/UDP header. The UDP destination port MUST be set to TBD1 (), and the source port MAY be set to TBD1 or other value selected from the Dynamic range of port numbers. The source IP address is any non-link-local address associated with the responder, and the destination IP address is derived from the BFIR-id of the BIER header in the received Echo Request.
Receiving Echo Reply The Initiator, upon receiving the Echo Reply, will use the Sender's Handle to match with Echo Request sent. If no match is found, the Initiator MUST ignore the Echo Reply. If receiving Echo Reply has Downstream Mapping, the Initiator MUST copy the same to subsequent Echo Request(s). If one of the Echo Reply is received with Return Code as "Replying BFR is one of the BFERs in header BitString", it SHOULD reset the BFR-ID of the responder from Target SI-BisString TLV in subsequent Echo Request. This step helps avoid any BFR that is both BFER and transit BFR to respond with Echo Reply continuously.
IANA Considerations The terms used in the IANA Considerations below are intended to be consistent with .
UDP Port Number This document requests a UDP port TBD1 to be allocated by IANA for BIER Echo. Service Name bier-echo Transport Protocol UDP, TCP Assignee IESG iesg@ietf.org Contact IETF Chair chair@ietf.org Description The UDP destination port number for the IP/UDP encapsulated BIER Echo Reply message. Reference This document Port Number TBD1
BIER OAM as BIER NEXT Protocol IANA is requested to update the BIER Next Protocol Identifiers registry as follows: BIER OAM as BIER Next Protocol
Value Description Reference
5 OAM Packet This document
BIER OAM Registry Group IANA is requested to create and maintain the "BIER OAM" registry group containing the registries listed below.
BIER OAM Message Type IANA is requested to create in the BIER OAM Message Type registry in the BIER OAM registry group as follows:
  • Registry Name: BIER OAM Message Type.
  • Assignment Policy:
  • 0-58 - IETF Review
  • 59 - 61 - Experimental Use (Reserved, not to be assigned)
  • 62 - 63 - Private Use (Reserved, not to be assigned)
BIER OAM Message Type
Value Description Reference
0 Reserved This document
1 BIER Echo Request/Echo Reply This document
2 - 58 Unassigned This document
59 - 61 Reserved for Experimental Use This document
62 - 63 Reserved for Private Use This document
BIER Echo Request/Echo Reply Registries IANA is requested to create three BIER Echo Request/Echo Reply registries in the BIER OAM registry group, as described below.
BIER Echo Request/Echo Reply Message Types IANA is requested to create in the in the BIER OAM registry group the BIER Echo Request/Echo Reply Message Types registry as follows:
  • Registry Name: BIER Echo Request/Echo Reply Message Types
  • Assignment Policy:
  • 0 - 247 - IETF Review
  • 248 - 251 - Experimental Use (Reserved, not to be assigned)
  • 252 - 255 - Private Use (Reserved, not to be assigned)
BIER Echo Request/Echo Reply Message Types
Value Description Reference
0 Reserved This document
1 BIER Echo Request This document
2 BIER Echo Reply This document
3 - 175 Unassigned This document
176 - 247 Unassigned This document
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use This document
BIER Echo Reply Modes IANA is requested to create in the BIER OAM registry group the new BIER Echo Reply Mode registry as follows:
  • Registry Name: BIER Echo Reply Mode
  • Assignment Policy:
  • 0 - 247 - IETF Review
  • 248 - 251 - Experimental Use (Reserved, not to be assigned)
  • 252 - 255 - Private Use (Reserved, not to be assigned)
BIER Echo Reply Modes
Value Description Reference
0 Reserved This document
1 Do Not Reply This document
2 Reply via an IPv4/IPv6 UDP Packet This document
3 Reply via BIER packet This document
4 - 191 Unassigned This document
192 - 247 Unassigned This document
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use This document
BIER Echo Return Codes IANA is requested to create in the BIER OAM registry group the new BIER Echo Return Codes registry as follows:
  • Registry Name: BIER Echo Return Codes
  • Assignment Policy:
  • 0 - 247 - IETF Review
  • 248 - 251 - Experimental Use (Reserved, not to be assigned)
  • 252 - 255 - Private Use (Reserved, not to be assigned)
BIER Echo Return Codes
Value Description Reference
0 No Return Code This document
1 Malformed Echo Request received This document
2 One or more of the TLVs is not supported This document
3 Replying BFR is the only BFER in header BitString This document
4 Replying BFR is one of the BFERs in header BitString This document
5 Packet-Forward-Success This document
6  Invalid Multipath Info Request This document
7 Unassigned This document
8  No matching entry in the forwarding table This document
9  Set-Identifier Mismatch This document
10  DDMAP Mismatch This document
11 - 247 Unassigned This document
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use This document
Common Registration Procedures for TLVs and Sub-TLVs This section describes registration procedures for Type registries in BIER Echo Request/Reply TLVs and sub-TLVs. TLVs
Range Registration Procedures Note
0-16383 Standards Action This range is for TLVs and sub-TLVs that require an error message if not recognized.
16384-31739 RFC Required This range is for TLVs and sub-TLVs that require an error message if not recognized.
31740-31743 Experimental Use Not to be assigned.
31744-32767 First Come, First Served This range is for TLVs and sub-TLVs that require an error message if not recognized.
32768-49161 Standards Action This range is for TLVs and sub-TLVs that can be silently dropped if not recognized.
49162-64507 RFC Required This range is for TLVs and sub-TLVs that can be silently dropped if not recognized.
64508-64511 Experimental Use Not to be assigned.
64512-65535 First Come, First Served This range is for TLVs and sub-TLVs that can be silently dropped if not recognized.
TLVs IANA is requested to create in the BIER OAM registry group a registry for the Type field of top-level TLVs. as well as sub-registries for the associated sub-TLVs. Note that the meaning of a sub-TLV is scoped by the TLV. The number of spaces for the sub-TLVs of various TLVs is independent.
  • Registry Name: TLVs
  • Assignment Policy:
The TLVs requested by this document for the IANA consideration are listed in . TLVs
Type TLV Name Reference Sub-TLV Registry
0 Reserved This document
1 Original SI-BitString This document No Sub-TLVs
2 Target SI-BitString This document No Sub-TLVs
3 Incoming SI-BitString This document No Sub-TLVs
4 Downstream Mapping This document Link the Sub-TLVs for TLV Type 4 sub-registry
5 Responder BFER This document No Sub-TLVs
6 Responder BFR This document No Sub-TLVs
7 Ingress Interface This document No Sub-TLVs
Sub-TLVs for TLV Type 4 IANA is requested to create in the registry for the Type 4 (Downstream Mapping) a sub-registry Sub-TLVs for Type 4.
  • Registry Name: Sub-TLVs for Type 4
  • Assignment Policy:
TLVs
Type Sub-TLV Name Reference
0 Reserved This document
1 MPLS Multipath Entropy Data This document
2 Egress BitString This document
Security Considerations The security considerations of , and through it of , apply to this specification. The security considerations for BIER Ping are similar to ICMP , ICMPv6 , and LSP Ping , . As with ICMP or LSP Ping, BFR can be exposed to Denial-of-Service (DoS) attacks, and it is RECOMMENDED to regulate the BIER Ping packet flow to the control plane. A rate limiter SHOULD be applied to avoid any attack. Specifically, a rate limiter SHOULD be applied to the well-known UDP port defined in . Although using BIER Echo Request in a DoS amplification attack is theoretically possible, spoofing BFIR ID in the BIER Header presents itself as a serious challenge. As a result, this threat is not a big concern. As with ICMP or LSP Ping, a traceroute can be used to obtain network information. It is RECOMMENDED that the implementation checks the integrity of BFIR of the Echo messages against any locally secured list before processing the message further. In some BIER environments, transmitting a single BIER Echo Request message can result in the sender receiving an overwhelming number of BIER Echo Reply messages. In that case, an operator MAY choose to address the BIER Echo Request to a subset of BFERs rather than to all BFERs in the domain.
Acknowledgement The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal Iqbal, Jeffrey (Zhaohui) Zhang, and Shell Nakash for their review and comments. The authors would like to thank Mankamana Mishra for his thorough review and comments.
References Normative References Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems IANA BIER Next Protocol Identifiers Registry IANA Informative References
Contributors' Addresses Big Switch Networks
Japan nobo.akiya.dev@gmail.com
Individual Contributor
China veronique_cheng@hotmail.com