One document matched: draft-kumarzheng-bier-ping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category='std' ipr='trust200902' docName='draft-kumarzheng-bier-ping-00'>
<front>
<title abbrev="BIER Ping">BIER Ping and Trace</title>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="N." surname="Akiya" fullname="Nobo Akiya">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city> <region>ON</region> <code>K2K 3E8</code>
<country>Canada</country>
</postal>
<email>nobo@cisco.com</email>
</address>
</author>
<author initials="L." surname="Zheng" fullname="Lianshu Zheng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country>China</country>
</postal>
<email>vero.zheng@huawei.com</email>
</address>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country></country>
</postal>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>Network Work group</workgroup>
<keyword>bier</keyword>
<abstract><t>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.
</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.wijnands-bier-architecture" /> 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.
</t>
<t>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.</t>
</section>
<section title="Conventions used in this document">
<section title="Terminology">
<t>BFER - Bit Forwarding Egress Router</t>
<t>BFIR - Bit Forwarding Ingress Router</t>
<t>BIER - Bit Index Explicit Replication</t>
<t>ECMP - Equal Cost Multi-Path</t>
<t>OAM - Operation, Administration and Maintenance</t>
<t>SI - Set Identifier</t>
</section>
<section title="Requirements notation">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="BIER OAM">
<t>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.
<xref target="I-D.wijnands-mpls-bier-encapsulation" /> defines a 4-bit field as "Proto"
to identify the payload following BIER header. In order to differentiate the
BIER data packet from BIER OAM packet, this document introduces a new value for
the Proto field as:</t>
<t>Proto:
<list><t>PROTO-TBD1: BIER OAM</t>
</list>
</t>
<section title="BIER OAM message format">
<t>The BIER OAM packet header format that follows BIER header is as follows:
</t>
<figure>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Type Dependent Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Type
<list><t>The Message Type is one of the following:</t>
</list>
</t>
<figure>
<artwork><![CDATA[
Type Value Field
-------- ---------------
TBD1 BIER Echo Request
TBD2 BIER Echo Reply
]]></artwork>
</figure>
<t>The Echo Request/Reply header format is as follows:
</t>
<figure>
<artwork><![CDATA[
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 | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Proto
<list><t>Set to 0 for Echo Request/Reply header.</t>
</list>
</t>
<t>QTF
<list><t>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 <xref target="RFC5905"/>. When set to 3, the timestamp
format is in IEEE 1588-2008
(1588v2) Precision Time Protocol format.</t>
</list>
</t>
<t>RTF
<list><t>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 <xref target="RFC5905"/>. When set to 3, the timestamp
format is in IEEE 1588-2008
(1588v2) Precision Time Protocol format.</t>
</list>
</t>
<t>Reply mode
<list><t>The Reply mode is set to one of the below:</t>
</list>
</t>
<figure>
<artwork><![CDATA[
Value Meaning
-------- ---------------
1 Do not Reply
2 Reply via IPv4/IPv6 UDP packet.
3 Reply via BIER packet
]]></artwork>
</figure>
<t>Return Code
<list><t>Set to zero if Type is TBD1. Set as defined in section 3.2
if Type is TBD2.</t>
</list>
</t>
<t>Return subcode
<list><t>To Be updated.</t>
</list>
</t>
<t>Sender's Handle, Sequence number and Timestamp
<list><t>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.</t>
<t>The Sequence number is assigned by the Initiator and can be used
to detect any missed replies.
</t>
<t>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.
</t>
</list>
</t>
<t>TLVs
<list><t>Carries the TLVs as defined in Section 3.3.</t>
</list>
</t>
</section>
<section title="Return Code">
<t>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.
</t>
<t>The Return Code can be one of the following:
</t>
<figure>
<artwork><![CDATA[
Value Value Meaning
-------- ---------------
0 No return code (Set by Initiator in Echo Request)
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying BFR is the only BFER in header Bitstring
4 Set-Identifier Mismatch
5 Packet-Forward-Success
6 Invalid Multipath Info Request
7 No control plane entry for Multicast Overlay Data
8 No matching entry in forwarding table.
9 Replying BFR is one of the BFER in header Bitstring
]]></artwork>
</figure>
</section>
<section title="BIER OAM TLV">
<t>This section defines various TLVs that can be used in BIER OAM packet. The
TLVs (Type-Length-Value tuples) have the following format:
</t>
<figure>
<artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>TLV Types are defined below; Length is the length of the Value field in octets.
The Value field depends on the TLV Type.
</t>
<section title="Original SI-BitString TLV">
<t>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:
</t>
<figure>
<artwork><![CDATA[
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 | BitString Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Length field is set as defined in section 3 of
<xref target="I-D.wijnands-mpls-bier-encapsulation" />.
</t>
<t>Set ID field is set to the Set Identifier to which the
BitString belongs to. This value is derived as defined in
section 3 of <xref target="I-D.wijnands-bier-architecture" />
</t>
<t>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</t>
</section>
<section title="Target SI-BitString TLV">
<t>The Target SI-BitString TLV carries the set of BFER from
which the Initiator expects the reply from.This TLV
has the following format:
</t>
<figure>
<artwork><![CDATA[
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 | BitString Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Length field is set as defined in section 3 of
<xref target="I-D.wijnands-mpls-bier-encapsulation" />.
</t>
<t>Set ID field is set to the Set Identifier to which the
BitString belongs to. This value is derived as defined in
section 3 of <xref target="I-D.wijnands-bier-architecture" />
</t>
<t>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.</t>
</section>
<section title="Incoming SI-BitString TLV">
<t>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:
</t>
<figure>
<artwork><![CDATA[
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 | BitString Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Length field is set as defined in section 3 of
<xref target="I-D.wijnands-mpls-bier-encapsulation" />.
</t>
<t>Set ID field is set to the Set Identifier of the incoming
BIER-MPLS label. This value is derived as defined in
section 2.2 of <xref target="I-D.psenak-ospf-bier-extensions" />
</t>
<t>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.</t>
<t>An Initiator MUST NOT include this TLV in Echo Request.
</t>
</section>
<section title="Downstream Mapping TLV">
<t>This TLV has the following format:
</t>
<figure>
<artwork><![CDATA[
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>MTU
<list><t>Set to MTU value of outgoing interface.</t>
</list>
</t>
<t>Address Type
<list><t>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:</t>
</list>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
<t>Flags
<list><t>The Flags field has the following format:</t>
</list>
</t>
<figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd |I|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>When I flag is set, the Responding BFR SHOULD include the Incoming
SI-BitString TLV in echo reply message.
</t>
<t>Downstream Address and Downstream Interface Address
<list><t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<section title="Downstream Mapping Sub-TLVs">
<t>This section defines the optional Sub-TLVs that can be included in Downstream
Mapping TLV.
</t>
<figure>
<artwork><![CDATA[
Sub-TLV Type Value
--------------- --------------
1 Multipath Entropy Data
2 Egress BitString
]]></artwork>
</figure>
<section title="Multipath Entropy Data">
<t>
</t>
<figure>
<artwork><![CDATA[
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>M Flag
<list><t>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.</t>
</list>
</t>
<t>Multipath Information
<list><t>Entropy Data encoded as defined in section x3.</t>
</list>
</t>
</section>
<section title="Egress BitString">
<t>This Sub-TLV MAY be included by Responder BFR with the rewritten
BitString in outgoing interface as defined in section 6.1 of
<xref target="I-D.wijnands-bier-architecture" />
</t>
<figure>
<artwork><![CDATA[
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | BitString Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Responder BFER TLV">
<t>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:
</t>
<figure>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>BFR-ID
<list><t>The BFR-ID field carries the BFR-ID of replying BFER.
This TLV MAY be included by
Responding BFER in BIER Echo Reply packet.</t>
</list>
</t>
</section>
<section title="Responder BFR TLV">
<t>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:
</t>
<figure>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Routable Address (4 or 16 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Length
<list><t>The Length field varies depending on the Address Type.</t>
</list>
</t>
<t>Address Type
<list><t>Set to 1 for IPv4 or 2 for IPv6.</t>
</list>
</t>
<t>Routable Address
<list><t> Carries any locally routable address of replying BFR.
This TLV MAY be included by
Responding BFR in BIER Echo Reply packet.</t>
</list>
</t>
</section>
<section title="Upstream Interface TLV">
<t>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:
</t>
<figure>
<artwork><![CDATA[
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Length
<list><t>The Length field varies depending on the Address Type.</t>
</list>
</t>
<t>Address Type
<list><t>Set to 1 for IPv4 or 2 for IPv6.</t>
</list>
</t>
<t>Upstream Address
<list><t> As defined in Section 3.3.4</t>
</list>
</t>
</section>
</section>
</section>
<section title="Procedures">
<t>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".</t>
<section title="BIER OAM processing">
<t>A BIER OAM packet MUST be sent to BIER control plane for OAM processing if one
of the following conditions is true:
<list hangIndent="9" style="symbols">
<t>The receiving BFR is a BFER.</t>
<t>TTL of BIER-MPLS Label expired.</t>
<t>Presence of Router Alert label in the label stack.</t>
</list>
</t>
</section>
<section title="Per BFER ECMP Discovery">
<t>As defined in <xref target="I-D.wijnands-bier-architecture" />, 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.
</t>
<t><xref target="I-D.wijnands-mpls-bier-encapsulation" /> 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.
</t>
<t>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.
</t>
<t>Any transit BFR will reply back with Bit-masked Entropy for each downstream
path as defined in <xref target="RFC4379"/>
</t>
</section>
<section title="Sending BIER Echo Request">
<t>Initiator MUST set the Message Type as TBD1 and Return Code as 0. Initiator
infer the Set Identifier value from the respective BitString that will be appended in BIER
header and include in "SI" field.
</t>
<t>The Proto field in OAM packet MUST be set to 0, if there is no data packet
following immediately after OAM packet. In all other cases, the Proto field MUST be set to value
as defined in <xref target="I-D.wijnands-mpls-bier-encapsulation" />, same as
of the data packet that follows after OAM packet.
</t>
<t>Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT include
more than one Original SI-BitString TLV. In Ping mode, Initiator MAY include Target SI-BitString
TLV listing all the BFER from which the Initiator expects a response. In traceroute
mode, Initiator SHOULD include Target SI-Bitstring TLV. Initiator on receiving a
reply with Return code as "Replying router is one of the BFER in BIER header Bitstring"
, SHOULD unset the respective BFR-id from Target SI-Bitstring on any subsequent request.
</t>
<t>
Initiator MAY also include Downstream Mapping TLV (section 3.3.4). In presence
of Multipath Entropy Data Sub-TLV, the Target SI-BitString TLV MUST
carry only one BFER id.
</t>
<t>Initiator then encapsulates with BIER header and set the Proto as TBD1 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
BitString TLV.
</t>
</section>
<section title="Receiving BIER Echo Request">
<t>Sending a BIER OAM Echo Request to control plane for payload processing
is triggered as mentioned in section 4.1.
</t>
<t>Any BFR on receiving Echo Request MUST send Echo Reply with Return Code set to
1, if the packet fails sanity check. If the packet sanity check is fine, it
initiates a variable as "Best-return-code" and further processes it as below:
<list style="numbers">
<t>Set the Best-return-code to "SI Mismatch", if the received BIER-MPLS Label is not
assigned to the Set ID value in Original SI-BitString TLV. Go to
section 4.5.
</t>
<t>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.
</t>
<t>Set the Best-return-code to "Invalid Multipath Info Request",
if the Echo Request is received with
more than 1 BFER id in Target SI-BitString TLV AND Multipath Entropy Data Sub-TLV.
Go to section 4.5.
</t>
<t>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.
</t>
<t>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 is 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.
</t>
<t>Set the Best-return-code to "No matching entry in forwarding table",
if the forwarding lookup defined in
section 6.5 of <xref target="I-D.wijnands-bier-architecture" /> does
not match any entry for the received BitString in BIER header.
</t>
<t>Set the Best-return-code to "Packet-Forward-OK", and include
Downstream Mapping TLV. Go to section 4.5
</t>
</list>
</t>
</section>
<section title="Sending Echo Reply">
<t>Responder MUST include DDMAP in Echo Reply if the incoming Echo Request carries
DDMAP. Responder MUST set the Message Type as TBD2 and Return Code as
Best-return-code. The SI field MUST be set to 0 and Proto field MUST be set
to 0.
</t>
<t>Responder appends BIER header listing the BitString with BFIR ID (from received
Echo Request), set the Proto to PROTO-TBD1 and set the BFIR as zero.
</t>
</section>
<section title="Receiving Echo Reply">
<t>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.
</t>
<t>If receiving echo reply have Downstream Mapping, Initiator SHOULD copy the same
to subsequent Echo Request(s).
</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document request the IANA the creation and management of
below registries:</t>
<section title="Message Types, Reply Modes, Return Codes">
<t>This document request to assign the Message Types and Reply mode mentioned in section 3.1,
, Return code mentioned in Section 3.2.</t>
</section>
<section title="TLVs">
<t>The TLVs and Sub-TLVs requested by this document for IANA consideration are the following:</t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure><t></t>
</section>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>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 </t>
</section>
<section title="Acknowledgement">
<t> TBD</t>
</section>
<section title="Contributing Authors">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.wijnands-mpls-bier-encapsulation"?>
<?rfc include="reference.I-D.wijnands-bier-architecture"?>
<?rfc include="reference.I-D.psenak-ospf-bier-extensions"?>
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.5905"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.6425"?>
<?rfc include="reference.RFC.6424"?>
<?rfc include="reference.RFC.6291"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:51:46 |