<?xml version="1.0" encoding="US-ASCII"?>
<!--	$Id: draft-ietf-bier-non-mpls-bift-encoding-02.xml,v 1.6 2018/010/10 iwijnand Exp $	-->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8296.xml">
]>

<rfc ipr="trust200902" category="info"
     docName="draft-ietf-bier-non-mpls-bift-encoding-04">

<?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 abbrev="Non-MPLS BIER BIFT-id Encapsulation">An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation</title>
  <author initials='IJ.' surname='Wijnands' fullname='IJsbrand Wijnands'>
    <organization>Individual</organization>
    <address><postal>
      <street></street>
      <city></city> <region></region>
      <code></code>
      <country>Belgium</country>
    </postal>
    <email>ice@braindump.be</email></address>
  </author>
    <author initials='M.' surname='Mishra' fullname='Mankamana Mishra'>
    <organization>Cisco Systems</organization>
    <address><postal>
      <street>821 alder drive</street>
      <city> Milpitas </city> <region>CA</region>
      <code></code>
      <country>USA</country>
    </postal>
    <email>mankamis@cisco.com</email></address>
  </author>
  <author initials='X.' surname='Xu' fullname='Xiaohu Xu'>
    <organization>Alibaba Group</organization>
    <address><postal>
      <street></street>
      <city></city> <region></region>
      <code></code>
      <country></country>
    </postal>
    <email>xiaohu.xxh@alibaba-inc.com</email></address>
  </author>
  <author initials='H.' surname='Bidgoli' fullname='Hooman Bidgoli'>
    <organization>Nokia</organization>
    <address><postal>
      <street>600 March Rd.</street>
      <city>Ottawa</city> <region>Ontario</region>
      <code>K2K 2E6</code>
      <country>Canada</country>
    </postal>
    <email>hooman.bidgoli@nokia.com</email></address>
  </author>

  <date/>

  <workgroup>BIER Working Group</workgroup>

  <abstract>
    <t>
      Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value.
    </t>
  </abstract>
</front>

<middle>
  <section title="Introduction">
    <t>
      Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated <xref target="RFC8296"/> using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value, based on the Sub-Domain (SD), Set Identifier (SI) and BitStringLength (BSL) values.
    </t>

    <t>
      The BIER architecture requires that a BFR has a BIFT for every combination of &lt;SD, SI, BSL&gt; that is being used. When processing a BIER packet, the correct BIFT is inferred from the BIFT-id field of the encapsulation. When the non-MPLS encapsulation is used in a given BIER domain, it may be desirable for the a BIFT-id to be unique in that domain. This document describes an OPTIONAL method that can be used to form domain-wide unique BIFT-ids based on the &lt;SD, SI, BSL&gt; triples. If in the future the BIER architecture is extended with an additional BIFT argument, this encoding does not generate domain-wide unique identifiers anymore.
    </t>

    <t>
      This encoding, if used, is only for the convenience of the network adminstrators. When forwarding a BIER packet, the BIFT-id is used as an opaque 20-bit value that identifies a BIFT; the forwarding procedures do not parse the 20-bit value, they just use it as a lookup key. 
    </t>
  </section>

  <section title="Terminology and Definitions" >
    <t>
      Readers of this document are assumed to be familiar with the
      terminology and concepts of the documents listed as Normative
      References.  For convenience, some of the more frequently used
      terms appear below.
    </t>

    <t>
      <list style="hanging">
	<t hangText='BIER:'>
          <vspace />
	  Bit Indexed Explicit Replication.
	</t>
	<t hangText='BIFT-id:'>
          <vspace />
	  Bit Indexed Forwarding Table Identifier.
	</t>

      </list>
    </t>
  </section>

  <section title="Specification of Requirements">
    <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="The Bit Index Forwarding Table">
    <t>
      In MPLS networks a BIER label is allocated for each Bit Index Forwarding Table (BIFT) from the platform specific, downstream label database (<xref target="RFC8296"/>). This label is associated with a particular combination of BIER Sub-Domain (SD), Set Identifier (SI) and BitStringLength (BSL). In order for the network to know which MPLS label represents a particular combination of &lt;SD, SI, BS&gt;, this mapping has to be advertised through the network. This is currently done through an IGP or BGP. In MPLS networks this is not a drawback as the MPLS label has to be advertised anyway.
    </t>

    <t>
      When the non-MPLS encoding is chosen, there is no need to advertise the BIFT-id to &lt;SD, SI, BSL&gt; mapping if the BIFT-id is domain-wide unique. For this reason we're defining two encodings that MAY be used by operators to compute the domain-wide unique BIFT-id values from the SD, BSL and/or SI. Although the BIFT-id is not expected to change, it may change when the BSL mismatch procedures <xref target="RFC8279"/> section 6.10.2 are applied.
    </t>
  </section>

  <section title="The Non-MPLS Static BSL-SD-SI BIFT Encoding">
    <t>
      Find below the first 32 bits of the BIER header, encoding the SD, SI and BSL into the 20 bit BIFT-id field.
    </t>
    
    <figure align="center" anchor="Encoding" title="">
      <artwork align="center"><![CDATA[

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  BSL  |       SD      |       SI      | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|-------- 20 bit BIFT-id Field ---------|

]]></artwork>
      </figure>	

      <t>
      <list>
	<t>
	  BSL: This 4-bit field encodes the length in bits of the BitString. These are the same values as documented in <xref target="RFC8296"/>.
	</t>
	<t>
	  SD: This is a 8-bit field that encodes the Sub-Domain as described in <xref target="RFC8279"/>.
	</t>
	<t>
	  SI: This is a 8-bit field that encodes the Set-ID as described in <xref target="RFC8279"/>.
	</t>
	<t>
	  TC: This is a 3-bit field set to 000 (following <xref target="RFC8296"/>).
	</t>
	<t>
	  S: This is a 1-bit field set to 1 (following <xref target="RFC8296"/>).
	</t>
	<t>
	  TTL: See <xref target="RFC8296"/>.
	</t>
      </list>
      </t>
  </section>

  <section title="The Non-MPLS Static IBU-SI BIFT Encoding">
    <t>
      Find below the first 32 bits of the BIER header, encoding the provisioned Index BIFT Unit (IBU) and SI into the 20 bit BIFT-id field. The IBU replaces the BSL and SD values as described in the encoding above. This provides additional flexibility in-case there is a need to support additional arguments other than BSL and SD to create the BIFT-id.
    </t>
    
    <figure align="center" anchor="Encoding2" title="">
      <artwork align="center"><![CDATA[

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          IBU          |       SI      | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|-------- 20 bit BIFT-id Field ---------|

]]></artwork>
      </figure>	

      <t>
      <list>
	<t>
	  IBU: The IBU is a 12-bit field that encodes the provisioned Index BIFT Unit.
	</t>
	<t>
	  SI: This is a 8-bit field that encodes the Set-ID as described in <xref target="RFC8279"/>.
	</t>
	<t>
	  TC: This is a 3-bit field set to 000 (following <xref target="RFC8296"/>).
	</t>
	<t>
	  S: This is a 1-bit field set to 1 (following <xref target="RFC8296"/>).
	</t>
	<t>
	  TTL: See <xref target="RFC8296"/>.
	</t>
      </list>
      </t>
  </section>

   <section title="Security Considerations">
    <t>
      This document does not introduce any new security considerations other than already discussed in <xref target="RFC8279"/>.
    </t>
  </section>

  <section title="IANA Considerations">
    <t>
      There is no IANA consideration.
    </t>
  </section>

  <section title="Acknowledgments">
    <t>
      The authors like to thank the following people for their comments and contributions to this document; Eric Rosen, Neale Ranns, Jeffrey Zhang.  
    </t>
  </section>
</middle>
<back>
  <references title='Normative References'>
    &RFC2119;
    &RFC8279;
    &RFC8296;
  </references>
</back>
</rfc>
