One document matched: draft-psenak-ospf-bier-extensions-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std"
docName="draft-psenak-ospf-bier-extensions-01.txt" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>OSPF Extensions For BIER</title>
<author initials="P." surname="Psenak" fullname="Peter Psenak" role="editor">
<organization>Cisco</organization>
<address>
<postal>
<street>Apollo Business Center</street>
<street>Mlynske nivy 43</street>
<city>Bratislava</city> <region></region> <code>821 09</code>
<country>Slovakia</country>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco</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 fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
<organization>Cisco</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<region></region>
<code>1831</code>
<country>Belgium</country>
</postal>
<email>ice@cisco.com</email>
</address>
</author>
<author fullname="Andrew Dolganow" initials="A." surname="Dolganow">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>600 March Rd.</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K2K 2E6</code>
<country>Canada</country>
</postal>
<email>andrew.dolganow@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Tony Przygienda" initials="T." surname="Przygienda">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>antoni.przygienda@ericsson.com</email>
</address>
</author>
<author fullname="Jeffrey Zhang" initials="J." surname="Zhang">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>zzhang@juniper.net</email>
</address>
</author>
<author fullname="Sam Aldrin" initials="S." surname="Aldrin">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<email>zzhang@juniper.net</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>OSPF</workgroup>
<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 OSPF protocol extension required for BIER with MPLS
encapsulation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<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. Neither does BIER explicitly
require a 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>
BIER architecture requires routers participating in BIER within a given BIER domain
to exchange some BIER specific information among themselves. BIER architecture allows
link-state routing protocols to perform the distribution of these information. In this
document we describe extensions to OSPF to distribute BIER specific information for
the case where BIER uses MPLS encapsulation as described in
<xref target="I-D.wijnands-mpls-bier-encapsulation"/>.
</t>
<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 title="Flooding of the BIER Information in OSPF">
<t>All the BIER specific information that a BIER router needs to advertise to other
BIER routers are associated with the BFR-Prefix, a unique (within a given BIER domain),
routable IP address that is assign to each BIER router as described in section 2 of
<xref target="I-D.wijnands-bier-architecture"/>.</t>
<t>Given that the BIER information is associated with the prefix, the OSPF Extended
Prefix Opaque LSA <xref target="I-D.ietf-ospf-prefix-link-attr"/> is used to flood
BIER related information. </t>
<section title="The BIER Sub-TLV">
<t>A new Sub-TLV of the Extended Prefix TLV (defined in
<xref target="I-D.ietf-ospf-prefix-link-attr"/>) is defined for distributing BIER
information. The new Sub-TLV is called BIER Sub-TLV. Multiple BIER Sub-TLVs may be
included in the Extended Prefix TLV.</t>
<t> BIER Sub-TLV has the following format:</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BS Length | MT-ID | BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
</artwork>
</figure>
<t>
<list style='hanging'>
<t>Type: TBD</t>
<t>Length: 4 bytes</t>
<t>BS Length: A 1 octet field encoding the supported BitString length associated
with this BFR-prefix. The values allowed in this field are specified in section 3
of <xref target="I-D.wijnands-mpls-bier-encapsulation"/>.</t>
<t>MT-ID: Multi-Topology ID (as defined in <xref target="RFC4915"/>).</t>
<t>BFR-id: A 2 octet field encoding the BFR-id, as documented in section 2
<xref target="I-D.wijnands-bier-architecture"/>. If the BFR-id is zero, it means,
the advertising router is not advertising any BIER-id.</t>
</list></t>
<t>If multiple BIER Sub-TLVs are present, all having the same BS Length and MT-ID values,
first one MUST be used and subsequent ones MUST be ignored.</t>
</section>
<section title="The BIER MPLS Encapsulation Sub-TLV">
<t>BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. BIER MPLS
Encapsulation Sub-TLVIt is used in order to advertise MPLS specific information used
for BIER. It MUST appear only once in the BIER Sub-TLV.</t>
<t> BIER MPLS Encapsulation Sub-TLV has the following format:</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Lbl Range Size | Label Range Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style='hanging'>
<t>Type: TBD</t>
<t>Length: 4 bytes</t>
<t>Label Range Size: A 1 octet field encoding the label range size of the
label range.</t>
<t>Label Range Base: A 3 octet field, where the 20 rightmost bits represent the first
label in the label range.</t>
<t>The "label range" is the set of labels beginning with the label range base and
ending with (label range base)+(label range size)-1. A unique label range is allocated
for each BitStream length and Multi-Topology ID. These labels are used for BIER
forwarding as described in <xref target="I-D.wijnands-bier-architecture"/> and
<xref target="I-D.wijnands-mpls-bier-encapsulation"/>.</t>
<t>The size of the label range is determined by the number of Set Identifiers (SI)
(section 2 of <xref target="I-D.wijnands-bier-architecture"/>) that are used in the
network. Each SI maps to a single label in the label range. The first label is for
SI=0, the second label is for SI=1, etc.</t>
</list></t>
</section>
<section title="Flooding scope of BIER Information">
<t>Flooding scope of the OSPF Extended Prefix Opaque LSA
<xref target="I-D.ietf-ospf-prefix-link-attr"/> that is used for advertising
BIER Sub TLV is set to area. If (and only if) a single BIER domain contains multiple
OSPF areas, OSPF must propagate BIER information between areas. The following procedure
is used in order to propagate BIER related information between areas:<list style="hanging">
<t>When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area or inter-area
prefix to all its connected areas, it will also originate an Extended Prefix Opaque LSA,
as described in <xref target="I-D.ietf-ospf-prefix-link-attr"/>. The flooding scope of
the Extended Prefix Opaque LSA type will be set to area-scope. The route-type in the
OSPF Extended Prefix TLV is set to inter-area. When determining whether a BIER
Sub-TLV should be included in this LSA ABR will:<list style="hanging">
<t>- look at its best path to the prefix in the source area and find the
advertising router associated with the best path to that prefix.</t>
<t>- determine if such advertising router advertised a BIER Sub-TLV for
the prefix. If yes, ABR will copy the information from such BIER MPLS Sub-TLV
when advertising BIER MPLS Sub-TLV to each connected area.</t>
</list></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>Implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard OSPF failures.</t>
</section>
<section title="IANA Considerations">
<t>
The document requests two new allocations from the OSPF Extended Prefix sub-TLV
registry as defined in <xref target="I-D.ietf-ospf-prefix-link-attr"/>.
<list style='hanging'>
<t>BIER Sub-TLV: TBD</t>
<t>BIER MPLS Encapsulation Sub-TLV: TBD</t>
</list>
</t>
</section>
<section title="Acknowledgments">
<t>
The authors would like to thank Rajiv Asati, Christian Martin, Greg Shepherd and
Eric Rosen for their contribution.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119' ?>
<?rfc include="reference.I-D.draft-wijnands-mpls-bier-encapsulation-00.xml"?>
<?rfc include="reference.I-D.draft-wijnands-bier-architecture-00.xml"?>
<?rfc include="reference.I-D.ietf-ospf-prefix-link-attr.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4915.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:00:10 |