BIER Ping and TraceCisco Systems, Inc.7200 Kit Creek RoadResearch Triangle ParkNC27709USnaikumar@cisco.comCisco Systems, Inc.7200 Kit Creek RoadResearch Triangle ParkNC27709-4987UScpignata@cisco.comBig Switch NetworksJapannobo.akiya.dev@gmail.comHuawei TechnologiesChinavero.zheng@huawei.comHuawei Technologiesmach.chen@huawei.comEricssongregory.mirsky@ericsson.com
Internet
Network Work groupbierBit 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 BIER data plane. 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 OAM packet format
that can be used to perform failure detection
and isolation on BIER data plane without
any dependency on other layers like IP layer.BFER - Bit Forwarding Egress RouterBFIR - Bit Forwarding Ingress RouterBIER - Bit Index Explicit ReplicationECMP - Equal Cost Multi-PathOAM - Operation, Administration and MaintenanceSI - Set Identifier
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in .
BIER OAM is defined in a way that it stays within BIER layer by following
directly the BIER header without mandating the need for IP header.
defines a 4-bit field as "Proto"
to identify the payload following BIER header. When the payload is BIER OAM, the "Proto"
field will be set to 5 as defined in The BIER OAM packet header format that follows BIER header is as follows:
Ver
Set to 1.Message Type
This document defines the following Message Types:Proto
This field is used to define if there is any data packet immediately following the
OAM payload which is used for passive OAM functionality. This field is set
to 0 if there is no data packet following OAM payload.The Echo Request/Reply header format is as follows:
Proto
Set to 0 for Echo Request/Reply header.QTF
Querier Timestamp Format. When set to 2, the Timestamp Sent field is
(in seconds and microseconds, according to the Initiator's clock)
in NTP format . When set to 3, the timestamp
format is in IEEE 1588-2008
(1588v2) Precision Time Protocol format. Any other value SHOULD be considered
as sanity check failureRTF
Responder Timestamp Format. When set to 2, the Timestamp Received field is
(in seconds and microseconds, according to the Initiator's clock)
in NTP format . When set to 3, the timestamp
format is in IEEE 1588-2008
(1588v2) Precision Time Protocol format. Any other value SHOULD be considered
as sanity check failure.Reply mode
The Reply mode is set to one of the below:When Reply mode is set to 1, the receiver will not send any reply. This is used
for unidirectional path validation. The Reply mode by default would be set to 2
and the Responder BFR will encapsulate the Echo reply payload with IP header. When
the Initiator intend to validate the return BIER path, the Reply mode is set to
3 so that the Responder BFR will encapsulate the Echo Reply with BIER header.
Return Code
Set to zero if Type is "BIER Echo Request". Set to one of the value defined in section 3.2,
if Type is "BIER Echo Reply".Return subcode
To Be updated.Sender's Handle, Sequence number and Timestamp
The Sender's Handle is filled by the Initiator, and returned
unchanged by responder BFR. This is 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.
TLVs
Carries the TLVs as defined in Section 3.3.Responder uses Return Code field to reply with 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 following:
"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 any TLV included in the Echo Request is not understood by receiver, the Return code will be
set to "One or more of the TLVs was not understood" carrying the respective TLVs.
When the received header BitString in Echo Request packet contains only its own Bit-ID,
"Replying BFR is the only BFER in header BitString" is set in the reply. This implies that
the receiver is BFER and the packet is not forwarded to any more neighbors.
When the received header BitString in Echo Request packet contains its own Bit-ID in addition
to other Bit-IDs,
"Replying BFR is one of the BFER in header BitString" is set in the reply. This 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 received Echo Request are understood
and forwarding table have forwarding entries for the BitString. This is used by
transit BFR during traceroute mode.
When 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 local forwarding table, the BFR will use
"No matching entry in forwarding table" in the reply.
If the BIER-MPLS label in received Echo Request is not the one assigned for
SI in Original SI-BitString TLV, "Set-Identifier Mismatch" is set inorder 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:
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 BIER header.This TLV
has the following format:
Set ID field is set to the Set Identifier to which the
BitString belongs to. This value is derived as defined in
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
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 packetThe Target SI-BitString TLV carries the set of BFER from
which the Initiator expects the reply from.This TLV
has the following format:
Set ID field is set to the Set Identifier to which the
BitString belongs to. This value is derived as defined in
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
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 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:
Set ID field is set to the Set Identifier to which the
BitString belongs to. This value is derived as defined in
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
The BitString field copies the BitString from 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.
This TLV has the following format:
MTU
Set to MTU value of outgoing interface.Address Type
The Address Type indicates the address type and length of IP address for
downstream interface. The Address type is set to one of the below:Flags
The Flags field has the following format:When I flag is set, the Responding BFR SHOULD include the Incoming
SI-BitString TLV in Echo Reply message.
Downstream Address and Downstream Interface Address
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 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 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 index assigned by upstream BFR to the interface.This section defines the optional Sub-TLVs that can be included in Downstream
Mapping TLV.
M Flag
This flag is set to 0 if all packets will be
forwarded out through interface defined in Downstream Mapping
TLV. When set to 1, Multipath Information will be defined with
Bit masked Entropy data.Multipath Information
Entropy Data encoded as defined in section x3.This Sub-TLV MAY be included by Responder BFR with the rewritten
BitString in outgoing interface as defined in section 6.1 of
The Responder BFER TLV will be included by the BFER replying to the request.
This is used to identify the originator of BIER Echo Reply. This TLV have the
following format:
BFR-ID
The BFR-ID field carries the BFR-ID of replying BFER.
This TLV MAY be included by
Responding BFER in BIER Echo Reply packet.The Responder BFR TLV will be included by the transit BFR replying to the request.
This is used to identify the replying BFR without BFR-ID. This TLV have the
following format:
Length
The Length field varies depending on the Address Type.Address Type
Set to 1 for IPv4 or 2 for IPv6.BFR-Prefix
Carries the local BFR-Prefix of the replying BFR.
This TLV MAY be included by
Responding BFR in BIER Echo Reply packet.The Upstream Interface TLV will be included by the replying BFR in Echo Reply.
This is used to identify the incoming interface and the BIER-MPLS label in
the incoming Echo Request. This TLV have the following format:
Length
The Length field varies depending on the Address Type.Address Type
Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered
3 for IPv6 numbered or 4 for IPv6 Unnumbered.Upstream Address
As defined in Section 3.3.4The Reply-To TLV MAY be included by the Initiator BFR in Echo Request.
This is used by transit BFR or BFER when the reply mode is 2. The IP address
will be used to generate Echo Reply. This TLV have the following format:
Length
The Length field varies depending on the Address Type.Address Type
Set to 1 for IPv4 or 2 for IPv6.Reply-To Address
Set to any locally configured address to which the Echo reply
should be sent to.This section describes aspects of Ping and traceroute operations. While this document
explains the behavior when Reply mode is "Reply via BIER packet",
the future version will be updated with details about the format when the
reply mode is "Reply via IP/UDP packet".A BIER OAM packet MUST be sent to 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 expired.Presence of Router Alert label in the label stack.As defined in , BIER follows
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.
proposes the BIER header
with Entropy field that can be leveraged to exercise all ECMP paths. Initiator/BFIR
will use traceroute message to query each hop about the Entropy information for
each downstream paths. To avoid complexity, it is suggested that the ECMP query is
performed per BFER by carrying required information in BIER OAM message.
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 back with Bit-masked Entropy for each downstream
path as defined in 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 Sender's Handle and Sequence
number is a local matter to 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.
Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT include
more than one Original SI-BitString TLV. Initiator
infers the Set Identifier value and Sub-domain ID value from the respective BitString
that will be included in BIER header of the packet and includes the values in "SI"
and Sub-Domain ID fields respectively.
In Ping mode, 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 trace route mode, Initiator MAY include Target SI-Bitstring TLV
to control the path trace towards any specific BFER or set of BFERs. 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, Initiator MUST include Reply-To TLV (section 3.3.8)
in the Echo Request. Initiator MUST also listen to the UDP port defined in this TLV and
process any segment received with destination port as value defined in the TLV and
sent to control plane for BIER OAM payload processing.
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, Initiator MUST include the Multipath Entropy Data Sub-TLV and SHOULD
set the Target SI-BitString TLV carrying a specific BFER id.
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 send Echo Reply with Return Code set to
"Malformed Echo Request received", if the packet fails sanity check. If the packet sanity check is fine, it
SHOULD initiates 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 DDMAP info and to populate the Upstream Interface TLV.BIER-Label-L
The BIER-MPLS Label received as the top label on 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 from the received Echo Request. This may be used to validate
the DDMAP info and to populate the Incoming SI-BitString TLV. In addition, it can
be used to perform Entropy calculation considering different field in header and
reply via Multipath Entropy Data Sub-TLV.BFR MUST initialize Best-return-code variable to null value.
BFR will populate Interface-I with interface over which the Echo Request is received,
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:
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 section 4.5.
/* This detects any BIER-Label to {sub-domain, BitStringLen, SI} synchronization
problem in the upstream BFR causing any unintended packet leak between sub-domains
*/
Set the Best-return-code to "One or more of the TLVs was not understood",
if any of the TLVs in Echo Request message
is not understood. Go to section 4.5.
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 section 4.5.
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.
/* This detects any deviation between in BIER control plane and BIER forwarding plane
in the previous hop that may result in loop or packet duplication.
*/
Set the Best-return-code to "Invalid Multipath Info Request", when the
DDMAP TLV carries 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 section 4.5. 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 Multipath Entropy Data Sub-TLV from received Echo Request.
Store the Data for each Downstream interface in temporary variable. Set
the Best-return-code to 5 (Packet-Forward-Success) and goto Section 4.5
/* This instructs 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 section 4.5 if the responder is
BFER and there is no more bits in BIER header Bitstring left for forwarding.
Set the Best-return-code to
"Replying router is one of the BFER in BIER header Bitstring", and
include Downstream Mapping TLV, if
the responder is BFER and there are more bits in BitString left for
forwarding. In addition, include the Multipath information as defined in
Section 4.2 if the received Echo Request carries Multipath Entropy Data
Sub-TLV. Go to section 4.5.
Set the Best-return-code to "No matching entry in forwarding table",
if the forwarding lookup defined in
section 6.5 of does
not match any entry for the received BitString in BIER header.
/* This detects any missing BFR-id in the BIER forwarding table.
It could be noted that it is difficult to detect such missing BFR-id
while sending the Request with more than one BFR-id in BitString and
so may need to just 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 section 4.5
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 corresponding
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.
If the received Echo Request had DDMAP with Multipath Entropy Data Sub-TLV, Responder
BFR MUST include DDMAP as defined in Section 3.3.4 for each outgoing interface
over which the packet will be replicated and include the respective Multipath
Entropy Data Sub-TLV. For each outgoing interface, 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 Section 3.3.4 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.
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 source port MAY be set to TBD1 or other random local value.
The source IP is any local address of the responder and destiantion IP is derived
from Reply-To TLV.
Initiator on receiving Echo Reply will use the Sender's Handle to match with
Echo Request sent. If no match is found, Initiator MUST ignore the Echo Reply.
If receiving Echo Reply have Downstream Mapping, 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 helps avoiding any BFR that is both BFER and also transit BFR
to continuously responding with Echo Reply.*/
This document request UDP port TBD1 to be allocated by IANA for BIER Echo.
This document request the IANA for creation and management of
below registries:This document request to assign the Message Types and Reply mode mentioned in section 3.1,
, Return code mentioned 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:The security consideration for BIER Ping is similar to ICMP or LSP Ping. AS like ICMP or LSP ping,
BFR may be exposed to Denial-of-service attacks and it is RECOMMENDED to regulate the BIER Ping packet
flow to control plane. A rate limiter SHOULD be applied to avoid any attack.As like ICMP or LSP Ping, a traceroute can be used to obtain network information. It is RECOMMENDED
that the implementation check 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 and Shell Nakash for thier review and comments.TBD