<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-xu-bier-encapsulation-06" ipr="trust200902">
  <front>
    <title abbrev="BIER Encapsulation">A Transport-Independent Bit Index
    Explicit Replication (BIER) Encapsulation Header</title>

    <author fullname="Xiaohu Xu" initials="X.X." role="editor" surname="Xu">
      <organization>Huawei</organization>

      <address>
        <email>xuxiaohu@huawei.com</email>
      </address>
    </author>

    <author fullname="S Somasundaram" initials="S.S." surname="Somasundaram">
      <organization>Alcatel-Lucent</organization>

      <address>
        <!--
       <postal>
         <street></street>
-->

        <!-- Reorder these if your country does things differently -->

        <!--
         <city>Bangalore</city>

         <region></region>

         <code></code>

         <country>India</country>
       </postal>

       <phone>+44 7889 488 335</phone>
-->

        <email>somasundaram.s@alcatel-lucent.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C.J." role="editor"
            surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="Robert Raszuk" initials="R.R." surname="Raszuk">
      <organization>Bloomberg LP</organization>

      <address>
        <!--
       <postal>
         <street></street>
-->

        <!-- Reorder these if your country does things differently -->

        <!--
         <city>Soham</city>

         <region></region>

         <code></code>

         <country>UK</country>
       </postal>

       <phone>+44 7889 488 335</phone>
-->

        <email>robert@raszuk.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Zhaohui Zhang" initials="Z. Z." role="editor"
            surname="Zhang">
      <organization>Juniper</organization>

      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <!--

-->

    <date day="" month="" year="2016"/>

    <abstract>
      <t>Bit Index Explicit Replication (BIER) is a new multicast forwarding
      paradigm which doesn't require an explicit tree-building protocol nor
      intermediate routers to maintain any multicast state. This document
      proposes a transport-independent BIER encapsulation header which is
      applicable regardless of the underlying transport technology.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Bit Index Explicit Replication (BIER) <xref
      target="I-D.ietf-bier-architecture"/> is a new multicast forwarding
      paradigm which doesn't require an explicit tree-building protocol nor
      intermediate routers to maintain any multicast state. As described in
      <xref target="I-D.ietf-bier-architecture"/>, BIER adds a header to a
      multicast data packet (e.g., an IP packet or an MPLS packet). The BIER
      header carries the information needed for supporting the BIER forwarding
      procedures. This document proposes a transport-independent BIER
      encapsulation header which is applicable regardless of the underlying
      transport technology.</t>

      <section title="Requirements Language">
        <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">RFC 2119</xref>.</t>
      </section>
    </section>

    <section anchor="Abbreviations_Terminology" title="Terminology">
      <t>This memo makes use of the terms defined in <xref
      target="I-D.ietf-bier-architecture"/>.</t>
    </section>

    <section title="BIER Header">
      <t>The BIER header is shown in Figure 1.</t>

      <t><figure>
          <artwork align="center"><![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  |  BSL  | Resv  |                Entropy                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           BFIR-ID             |       DS      |    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         SI        |     Sub-domain    |O| Resv|      TTL      |       
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                BitString  (first 32 bits)                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                BitString  (last 32 bits)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 1: BIER Header Format.

       
]]></artwork>
        </figure></t>

      <t><list style="empty">
          <t>Ver(sion): a 4-bit field identifying the version of the BIER
          header. This document specifies version 0 of the BIER header.</t>

          <t>BSL: Bit String Length. If k is the length of the BitString, the
          value of this field is log2(k)-5. However, only the following values
          are supported <xref target="I-D.ietf-bier-mpls-encapsulation"/>
          :</t>

          <t><list style="symbols">
              <t>64 bits</t>

              <t>128 bits</t>

              <t>256 bits</t>

              <t>512 bits</t>

              <t>1024 bits</t>

              <t>2048 bits</t>

              <t>4096 bits</t>
            </list></t>

          <t>The value of the BSL field MUST NOT be set to any value other
          than those listed above. A received packet containing another value
          in this field SHOULD be discarded, and an error logged.</t>

          <t>Entropy: a 20-bit field containing an "entropy" value that can be
          used for load balancing purposes.</t>

          <t>BFIR-ID: a 2-octet field encoding the BFR-ID of the
          Bit-Forwarding Ingress Router (BFIR), in the BIER sub-domain where
          the packet is forwarded to.</t>

          <t>DS: The usage of this field is no different from that of the
          Differentiated Services (DS) field of IPv4 and IPv6 headers. <xref
          target="RFC2474"/>.</t>

          <t>Protocol: a one-octet field indicating the protocol type of the
          BIER payload as per the protocol numbers used in the Protocol field
          <xref target="RFC5237"/> of the IPv4 header and the Next Header
          field of an IPv6 header. Theoretically, with the use of the
          IPv4/IPv6 equivalent Protocol/Next-Header field, the payload of a
          BIER packet could be any type of payload permitted within the
          IPv4/IPv6 packet. However, this document currently only considers
          the use of the BIER encapsulation for "transport" type services
          where the encapsulated packets are either L2.5 (e.g., MPLS) or L3
          (e.g., IP) packets . The valid BIER payload types include (but are
          not limited to) IPv4, IPv6, MPLS, VXLAN <xref
          target="RFC7348"/>,VXLAN-GPE <xref
          target="I-D.ietf-nvo3-vxlan-gpe"/> and LISP <xref
          target="RFC6830"/>. The corresponding IP Protocol numbers for VXLAN,
          VXLAN-GPE and LISP are to be allocated by IANA.</t>

          <t>SI: a 10-bit field encoding the Set-Identifier (SI) for this
          packet in the case where the O-Flag bit is cleared.</t>

          <t>Sub-domain: a 10-bit field encoding the sub-domain where the
          packet is forwarded to in the case where the O-Flag bit is
          cleared.</t>

          <t>O-flag: If it's set, the leftmost 20 bits (i.e., the combination
          of the SI and Sub-domain fields) should be interpreted as an opaque
          number signaled and used much as the MPLS-BIER label in MPLS BIER
          encapsulation <xref target="I-D.ietf-bier-mpls-encapsulation"/>. A
          BFR signals the mapping between the opaque number and (subdomain-id,
          set-id, BSL) and it derives the (subdomain-id,set-id,BSL) from the
          opqaue number in an incoming BIER header just like in the MPLS BIER
          encapsulation case, except that regular MPLS signaling and
          forwarding infrastructure is not required. </t>

          <t>TTL: The usage of this field is no different from that of the
          Time To Live (TTL) field in the IPv4 header.</t>

          <t>BitString: a variable-length BitString field that, together with
          the SI and Sub-domain fields, identifies all the destination BFERs
          for this packet.</t>
        </list></t>
    </section>

    <section anchor="Encaps" title="BIER Header Transport ">
      <t>Since the BIER header format as specified in Section 3 is
      transport-independent by design, it can be carried with any type of
      transport encapsulation headers, such as an Ethernet header, a PPP
      header, an IP header, an MPLS header, a GRE header, an UDP header, etc.
      Any possible transport encapsulation header must be able to indicate the
      payload is an BIER header. For instance, in the BIER-in-MAC
      encapsulation case, the EtherType <xref target="ETYPES"/> field of the
      Ethernet header is used for that purpose. In the BIER-in-IP
      encapsulation case, the Protocol field of the IPv4 header or the
      Next-Header field of the IPv6 header are used. In the MPLS transport
      case, the MPLS-BIER encapsulation <xref
      target="I-D.ietf-bier-mpls-encapsulation"/> SHOULD be used instead. Note
      that more details about BIER-in-UDP encapsualtion (e.g., UDP checksum
      and congestion control) will be specified in future versions of this
      document.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks Antoni Przygienda, IJsbrand Wijnands, Eric Rosen and Toerless
      Eckert for their valuable comments and suggestions on this document.</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document includes a request to IANA to allocate an EtherType
      code,a PPP protocol code, an IPv4 protocol code/an IPv6 Next-Header
      code, a UDP destination port to indicate that BIER-encapsulated data
      follows. Furthermore, this document includes a request to IANA to
      allocate IP Protocol numbers for VXLAN, VXLAN-GPE and LISP
      respectively.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>As mentioned in <xref target="I-D.ietf-bier-architecture"/>, when
      BIER is paired with any transport underlay, it inherits the security
      considerations of the corresponding transport layer. Also, SI and
      BFIR-ID fields of the BIER header may carry values other than those
      intended by the BFIR at the risk of misdelivering the packet. Means to
      protect BFR routers against Man-in-the-Middle and Denial of Service
      attacks must be provided.</t>

      <!---->
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.I-D.ietf-bier-architecture"?>

      <?rfc include="reference.RFC.2119"?>

      <reference anchor="ETYPES">
        <front>
          <title>IEEE 802 Numbers</title>

          <author>
            <organization>The IEEE Registration Authority</organization>
          </author>

          <date year="2012"/>

          <note title="">
            <t>&lt;http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml&gt;.</t>
          </note>
        </front>
      </reference>

      <!---->
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7348"?>

      <?rfc include="reference.RFC.6830"?>

      <?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?>

      <?rfc include="reference.RFC.2474"?>

      <?rfc include="reference.RFC.5237"?>

      <?rfc include="reference.I-D.ietf-bier-mpls-encapsulation"?>

      <!---->
    </references>
  </back>
</rfc>
