| Internet-Draft | BIER Ping | March 2023 |
| Kumar, et al. | Expires 7 September 2023 | [Page] |
Bit Index Explicit Replication (BIER) is an 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 expressed by setting the bits that correspond to those routers in the BIER header.¶
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.¶
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 7 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
[RFC8279] 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 expressed by setting the bits that correspond to those routers in the BIER header.¶
This document describes the mechanism and basic BIER Operations, Administration, and Maintenance (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.¶
BFER - Bit Forwarding Egress Router¶
BFIR - Bit Forwarding Ingress Router¶
BIER - Bit Index Explicit Replication¶
DDMAP - Downstream Detailed Mapping TLV¶
ECMP - Equal Cost Multi-Path¶
OAM - Operation, Administration, and Maintenance¶
SI - Set Identifier¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
BIER OAM is defined to stay within the BIER layer by directly following the BIER header without mandating the need for IP header. [RFC8296] 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 [RFC8296]¶
The BIER OAM packet header format that follows BIER header is as follows:¶
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 | Message Type | Proto | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Type Dependent Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver
Set to 1.
Message Type
This document defines the following Message Types:
Type Value Field
-------- ---------------
1 BIER Echo Request
2 BIER Echo Reply
Proto
¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | Reply mode | Return Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proto Set to 0 for Echo Request/Reply header. QTF¶
Value Meaning
-------- ---------------
1 Do not Reply
2 Reply via IPv4/IPv6 UDP packet.
3 Reply via BIER packet
¶
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 BFR encapsulates the Echo reply payload with IP header. When the Initiator intends to validate the return BIER path, the Reply mode will be set to 3 so that the Responder BFR will encapsulates the Echo Reply with the BIER header.¶
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.¶
The Sequence Number is assigned by the Initiator and can be used to detect any missed replies.¶
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 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.¶
Value Value Meaning
------ ---------------
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 BFER in header Bitstring
5 Packet-Forward-Success
6 Invalid Multipath Info Request
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 Bit-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 Bit-ID in addition to other Bit-IDs, "Replying BFR is one of the BFER 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 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.¶
This section defines various TLVs that can be used in BIER OAM packet. The TLVs (Type-Length-Value tuples) have the following 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
TLV Types are defined below; Length is the length of the Value field in octets. The Value field depends on the TLV Type.¶
The Original SI-BitString TLV carries the set of BFER and carries the same BitString that Initiator includes in the BIER header. This TLV has the following 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 = 1 | 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 value of the Set Identifier to which the BitString belongs to. This value is derived as defined in [RFC8279]¶
Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs to.¶
BS Len is set based on the length of BitString as defined in [RFC8296]¶
The BitString field carries the set of BFR-IDs that Initiator will include in the BIER header. This TLV MUST be included by Initiator in Echo Request packet¶
Any Initiator MUST include this TLV in the Echo Request packet.¶
The Target SI-BitString TLV carries the set of BFER from which the Initiator expects the reply from.This TLV has the following 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 to. This value is derived as defined in [RFC8279]¶
Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs to.¶
BS Len is set based on the length of BitString as defined in [RFC8296]¶
The BitString field carries the set of BFR-IDs of BFER(s) that Initiator expects the response from. The BitString in this TLV may be different from the BitString in the BIER header and allows to control the BFER responding to the Echo Request. This TLV MUST be included by Initiator in BIER OAM packet if the Downstream Mapping TLV (section 3.3.4) is included.¶
The Incoming SI-BitString TLV will be included by Responder BFR in Reply message and copies the BitString from BIER header of incoming Echo Request message. This TLV has the following 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 = 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 to. This value is derived as defined in [RFC8279]¶
Sub-domain ID is set to the Sub-domain value to which BFER in BitString belongs to.¶
BS Len is set based on the length of BitString as defined in [RFC8296]¶
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 I flag set in Downstream Mapping TLV.¶
An Initiator MUST NOT include this TLV in Echo Request.¶
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-tlv Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . List of Sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MTU Set to MTU value of outgoing interface. Address Type¶
Type Addr. Type DA Length DIA Length
------- --------------- ---------- ----------
1 IPv4 Numbered 4 4
2 IPv4 Unnumbered 4 4
3 IPv6 Numbered 16 16
4 IPv6 Unnumbered 16 4
DA Length - Downstream Address field Length
DIA Length - Downstream Interface Address field Length
¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd |I| +-+-+-+-+-+-+-+-+¶
When I flag is set, the Responding BFR MUST include the Incoming SI- BitString TLV in Echo Reply message.¶
If the Address Type is 1, the Downstream Address 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 2, the Downstream Address MUST be set to IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the index assigned by upstream BFR to the interface.¶
If the Address Type is 3, the Downstream Address MUST be set to IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the downstream interface address.¶
If the Address Type is 4, the Downstream Address MUST be set to IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address is set to the index assigned by upstream BFR to the interface.¶
This section defines the optional Sub-TLVs that can be included in Downstream Mapping TLV.¶
Sub-TLV Type Value
------------ -------------
1 Multipath Entropy Data
2 Egress BitString
¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | |
+-+-+-+-+-+-+-+-+-+ |
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag
¶
Responder BFR MAY include this Sub-TLV with the rewritten BitString in the outgoing interface as defined in section 6.1 of [RFC8279]¶
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID | Sub-domain ID |BS Len| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The BFER replying to the request MAY include the Responder BFER TLV. This TLV identifies the originator of BIER Echo Reply. This TLV has the following 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BFR-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BFR-ID¶
Any transit BFR replying to the request MAY include the Responder BFR TLV. This is used to identify the replying BFR without BFR-ID. This TLV has the following 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 = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFR-Prefix (4 or 16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length The Length field varies depending on the Address Type. Address Type Set to 1 for IPv4 or 2 for IPv6. BFR-Prefix¶
The BFR replying to the request MUST include the Upstream Interface TLV. This TLV identifies the incoming interface and the BIER-MPLS label in the incoming Echo Request. This TLV has the following 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 = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Upstream Address (4 or 16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length The Length field varies depending on the Address Type. Address Type¶
The Initiator BFR MAY include Reply-To TLV in the Echo Request. This TLV is used by transit BFR or BFER when the reply mode is 2. The IP address will be used to generate the Echo Reply. This TLV has the following 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 = 8 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Reply-To Address (4 or 16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length The Length field varies depending on the Address Type. Address Type Set to 1 for IPv4 or 2 for IPv6. Reply-To Address¶
The size of the Entropy field in the BIER header is 20 bits as defined in section 2 of [RFC8296]. This encoding is similar to the Multipath Type 9 encoding defined in Section 3.4.1.1.1 of [RFC8029].¶
This section describes aspects of Ping and traceroute operations.¶
A BIER OAM packet MUST be sent to the BIER control plane for OAM processing if one of the following conditions is true:¶
As defined in [RFC8279], BIER follows the unicast forwarding path and allows load balancing over ECMP paths between BFIR and BFER. BIER OAM MUST 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.¶
[RFC8296] proposes the BIER header with the Entropy field that can be leveraged to exercise all ECMP paths. The Initiator/BFIR will use 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 required information in BIER OAM message.¶
The Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream Mapping TLV. It MUST also include the BFER in BitString TLV to which the Multipath query is performed.¶
Any transit BFR will reply with Bit-masked Entropy for each downstream path as defined in [RFC8029]¶
The Initiator MUST set the Message Type as 1 and Return Code as 0. The Proto field in 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 SHOULD increment the Sequence Number by 1 for every subsequent Echo Request. The QTF field is set to Initiator's local timestamp format and 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 trace route 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 Return code as "Replying BFR is the only BFER in header Bitstring" or "Replying router is one of the BFER in header Bitstring", SHOULD unset the respective BFR-id from Target SI- BitString for any subsequent Echo Request.¶
When the Reply mode is set to 2, the Initiator MUST include Reply-To TLV (section 3.3.8) in the Echo Request. The Initiator MUST also listen to the UDP port defined in this TLV and process any segment received with destination port as the value defined in the TLV and sent to control plane for BIER OAM payload processing.¶
The Initiator MAY include Downstream Mapping TLV (section 3.3.4) in the Echo Request to query additional information from transit BFRs and BFERs. In case of ECMP discovery, the Initiator MUST include the Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString TLV carrying a specific BFER ID.¶
The Initiator MUST encapsulate the OAM packet with 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.¶
Sending a BIER OAM Echo Request to control plane for payload processing is triggered as mentioned in section 4.1.¶
Any BFR on receiving Echo Request MUST perform the basic sanity check. If the BFR cannot parse the OAM Dependent data payload 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. If the packet sanity check is fine, it SHOULD initiate the below set of variables:¶
BFR MUST initialize the 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 BIER-Header. If the received Echo Request carries Target SI-BitString TLV, a BFR SHOULD run 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 section 4.5. Else:¶
* /* This step 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. */¶
* /* This step 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. */¶
* /* 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.*/¶
* /* This step 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. */¶
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 SHOULD 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 SHOULD include the Upstream Interface TLV and populate the address from Interface-I.¶
When the Best-return-code is "Replying BFR is one of the BFER in header Bitstring", it MUST include Responder BFER 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 either as BIER-encapsulated or IP/UDP encapsulated depending on the Reply mode in received Echo Request. When the Reply mode in received Echo Request is set to 3, Responder appends BIER header listing the BitString with BFIR ID (from Header- H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in received Echo Request is set to 2, Responder encapsulates with IP/UDP header. The UDP destination port MUST be set to TBD1, and the source port MAY be set to TBD1 or other random local value. The source IP is any local address of the responder and destination IP is derived from Reply-To TLV.¶
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 have Downstream Mapping, the Initiator SHOULD 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 BFER 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. */¶
This document requests a UDP port TBD1 to be allocated by IANA for BIER Echo.¶
This document requests the IANA to create and manage the below registries and sub-registries:¶
IANA is requested to create and maintain "BIER OAM Parameters" registry.¶
IANA is requested to create a "Message Type" sub-registry under "BIER OAM Parameters" registry and assign the Message Types defined in section 3.1¶
IANA is requested to create a "Echo Reply Mode" sub-registry under "BIER OAM Parameters" registry and assign the Echo Reply Modes defined in section 3.1¶
IANA is requested to create a "Echo Return Codes" sub-registry under "BIER OAM Parameters" registry and assign the Return Codes defined in section 3.2¶
The TLVs and Sub-TLVs defined in this document is not limited to Echo Request or Reply message types and is applicable for other message types. The TLVs and Sub-TLVs requested by this document for IANA consideration are the following:¶
Type Sub-Type Value Field
------- -------- -----------
1 Original SI-BitString
2 Target SI-BitString
3 Incoming SI-BitString
4 Downstream Mapping
4 1 Multipath Entropy Data
4 2 Egress BitString
5 Responder BFER
6 Responder BFR
7 Upstream Interface
¶
The security consideration for BIER Ping is similar to ICMP [RFC0792] or LSP Ping [RFC8029], [RFC6425]. 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.¶
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 local secured list before processing the message further¶
The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal Iqbal, Jeffrey (Zhaohui) Zhang,DIA Length - Downstream Interface Address field Length and Shell Nakash for their review and comments.¶
The authors would like to thank Mankamana Mishra for his thorough review and comments.¶