<?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 RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.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">
]>
<?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 -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- end of list of popular I-D processing instructions -->

<rfc ipr="trust200902" docName="draft-huang-bier-te-encapsulation-00" category="exp">
        <front>
                <title abbrev="BIER-TE ARCH">Encapsulation for BIER-TE</title>
                <author fullname="Rachel Huang" initials="R." surname="Huang">
                  <organization>Huawei</organization>
                  <address>
                    <postal>
                      <street>101 Software Avenue, Yuhua District</street>
                      <city>Nanjing</city>
                      <code>210012</code>
                      <country>China</country>
                    </postal>
                    <email>rachel.huang@huawei.com</email>
                  </address>
                </author>
                <author fullname="Toerless Eckert" initials="T.T.E" surname="Eckert">
                        <organization abbrev="Huawei">Huawei USA - Futurewei Technologies Inc.</organization>
                        <address>
                    <postal>
                      <street>2330 Central Expy</street>
                      <city>Santa Clara</city>
                      <code>95050</code>
                      <country>USA</country>
                    </postal>
                    <email>tte+ietf@cs.fau.de</email>
                  </address>
                </author>
                <author fullname="Naiwen Wei" initials="N.W." surname="Wei">
                        <organization>Huawei</organization>
                        <address>
                                <email>weinaiwen@huawei.com</email>
                        </address>
                </author>

    <author initials="P." surname="Thubert" fullname="Pascal Thubert"> 
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street>Village d'Entreprises Green Side</street> <street>400, Avenue de Roumanille</street> <street>Batiment T3</street>
          <city>Biot - Sophia Antipolis</city>
          <code>06410</code>
          <country>FRANCE</country>
        </postal>
        <phone>+33 4 97 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>

                <date day="5" month="March" year="2018"/>
                <abstract>
<t>
This document proposes an enhanced encapsulation for BIER to support BIER, BIER-TE and a control word.</t>


                </abstract>
        </front>

<middle>

  <section anchor="intro" title="Introduction">

<t> <xref target="BIER-TE-ARCH"></xref> specifies BIER-TE: Traffic Engineering for Bit Index Explicit Replication (BIER). It builds on the BIER architecture as described in <xref target="RFC8279">RFC8279</xref>, but uses every BitPosition of the BitString of a BIER-TE packet to indicate one or more adjacencies instead of a BFER as in BIER.</t>

<t> This document proposes an enhanced version of the MPLS and non-MPLS encapsulation for BIER packets to support both BIER and BIER-TE. It is based on <xref target="RFC8296">RFC8296</xref>.</t>
<t> This enhanced encapsulation also adds support for a control word in the header and discusses it. Finally, the document discusses BitStringLength (BSL) size requirements in implementations for informational reasons to help aide implementors to determine an appropriate BSL.</t>

    <section anchor="Terminology" title="Terminology">
<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">RFC2119</xref>.</t>

    </section>
    <!-- Terminology -->

  </section>
  <!-- intro -->


<section anchor="Encapsulation" title="BIER-TE Encapsulation (normative)">

<section anchor="simultaneous" title="BT bit - Simultaneous support for BIER and BIER-TE">

<t>This document supports mixed BIER and BIER-TE forwarding in a domain. Either or both of them may be used in a domain. The overall solution to support this depends on additional signaling such as existing BIER ISIS/BGP signaling. Architecturally, every SD SHOULD only use a single Type of BIER: BIER or BIER-TE. Note that this document will use the abbreviation BT to refer to the Bier Type.</t>

<t>In the presence of BIER and BIER-TE together in the network, there is always a risk of receiving a packet which is meant to be of one BT and processing it through a BIFT of the other BT. This can come from misconfiguration even in the face of signalling via IGP/BGP. The risk increases also when packets are generated modular from applications on PE or other sources and could use both BTs. To resolve this, the header includes a bit to indicate the BT. If the BT of a packet is inconsistent with the BT of the BIFT on the BFR, the BFR MUST NOT forward it. OAM actions MAY be triggered (subject to future work).</t>

<t>Note that the TTL field of the existing BIER packet header (or of IP packets) spends 7 bits on loop prevention. One bit for the BT is a comparably low cost to protect against a similar degree of problems.</t>

<t>Indicating the BT explicitly through a bit in the encapsulation is called the "explicit" option. Relying solely on the BT of the BIFTs is  called "implicit" option. In this version of the document, we choose the explicit option for reasons outlined above.</t>

</section>

<section anchor="bift-id" title="BIFT-ID">

<t>Like in the original BIER header, the semantic of the BIFT-id of the header is that it is representing a &lt;SI,SD,BSL> on the BFR receiving the packet. In the case of MPLS forwarding, the expectation is that the protocols to signal label ranges would be extended to also signal label ranges for the SD using BIER-TE. This is subject to the work of other documents. In the case of non-MPLS forwarding, no additional signaling may be neccessary, and BIER and BIER-TE packets using the encapsulation of this document would equally use the BIFT-ID encoding as described in <xref target="BIER-non-MPLS"/>.</t> 

</section>

<section anchor="controlword" title="Control Word and flows">

<t>This document adds a "control word" to the BIER packet header to allow that BIER or BIER-TE packets with this header could be used as a DetNet Data Plane, independent of MPLS encapsulation, see <xref target="I-D.ietf-detnet-dp-sol"/>, section 5.3 (in revision 01).</t>

<t>The control word provides a sequence number, therefore allowing to correct reordering and discover packet loss. The primary use though is resilient dual-path transmission of two copies of the same packet via disjoint paths. This is specifically a desirable use-case with BIER-TE because it allows the engineering of such disjoint paths. The flow to which the sequence number in the control word applies is &lt;BFR-id,entropy>.</t>

<t>Note: The justification to carry a control word in the BIER encapsulation is similar to carrying the BFIR-ID in it. Initially, both could be seen as primarily required on BIER domain edge-nodes as part of the overlay using BIER, but not by BIER/BIER-TE itself directly. See <xref target="resilience"/> for more explanation how the resilience mechanism requiring the control word would work. Compared to the BFIR-ID, there is also the option to leverage it within BIER-TE itself. The details of that operations is subject to other specifications.</t>

<t>The authors think that the overhead of the control word is always acceptable for BIER-TE. For BIER, the use of this extended header version is optional, therefore BIER packets that need a control word would use this version of the header, those that do not need it would use version 1. If this overhead is considered to not be acceptable for all BIER-TE packets, the encoding could make those 32 bits optional through the use of one of the reserved bits or version numbers or by using a bit in the header to indicate whether the control word is present or not.</t>

</section>

<section anchor="header" title="Header format &amp; fields">

	
		<figure> <artwork align="left"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             BIFT-id                     | TC  |S|     TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble |  Ver  |  BSL  |              Entropy  (flow-id)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|T|R|    DSCP   |   Proto   |          BFIR-id              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|         Control Word (sequence number)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 BitString  (first 32 bits)                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                BitString  (last 32 bits)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0                    1                    2                   3


]]></artwork></figure>

<t>All header fields not described below are left unchanged from <xref target="BIER-TE-ARCH"/></t>

	<t>
	T: This 1-bit field identifies that the packet is to be forwarded as a BIER packet (0) or a BIER-TE paket(1).</t>

	<t>
	Ver: The version of this header format is 2.</t>

	<t>
	R: Reserved - unchanged (just reduced by one bit from version). Must be set to 0.</t>

	<t>
        Entropy: Unchanged, but double-used as part of the flow-identifier together with the control word</t>

	<t>
        Control Word: The control word in the terminology of MPLS pseudowires (where it originates from) is the full 32 bits. For detnet, the current target is 28 bits of sequence number and 4 bits 0 preceeding it.</t>
	
	</section>

</section>

<section anchor="resilience" title="BIER-TE based resilience operations (informational)">

<t>This section discusses how resilience operations with the help of the sequence number in the control word of the header in this document can be operated as an overlay (BFIR-BFER) function but also points out that it could become an integral (optional) part of BIER-TE itself. This section is solely informational. The planned document to describe the BIER-TE forwarding aspects of resilience operations is <xref target="I-D.thubert-bier-replication-elimination"/>.</t>

<t>The BFIR determines - potentially with the help of a  BIER-TE Controller Host (controller) - a bitstring that forms two disjoint DAGs (Directed Acyclic Graphs) through the BIER-TE domain towards the same set of BFER. In addition, an entropy value is decided (by BFIR and/or controller) and signalled to the BFER. The BFER can therefore set up "duplicate elimination state": The BFIR increments the sequence number with every packet of the flow it sends. The BFER assign packets to a flow by &lt;bfir-id,entropy> and perform duplicate elimination on them.</t>

<t>Note that the bitstring as seen on the receiving BFER can provide additional diagnostics, for example the bits not reset by forwarding in BIER-TE give an indication about which path the BIER-TE packet was forwarded.</t>

<t>Instead of simply considering this protected mode of operations solely an end-to-end (BFIR/BFER) function, it could also be more flexibly embedded into BIER-TE itself, allow to provide in-BIER-TE segmented Packet Replication and (duplicate) Eliminiation Functions (PREF) definable by the bitstring of a BIER-TE packet. This could be achieved by adding to BIER-TE forwarding functions new adjacency types for duplication with sequence-number generation and duplicate-elimination. The ability to perform such processing as part of BIER-TE itself is the primary reason to ensure that all the necessary elements for such operations are part of the BIER-TE header itself.</t>

</section>

<section anchor="BSLconsiderations" title="BitStringLength (BSL) considerations (informational)">

<t>BIER-TE uses each BitPostion to indicate the adjacencies instead of a BFER as in BIER, it therefore consumes more BitPostions than BIER. In BIER-TE, the number of adjacencies passed by one BIER-TE packet MUST be less than the value of BitString length (BSL). The BIER-TE architecture discusses a range of options to reduce the number of bits for intermediate hops through various BIER-TE adjacencies and how to use them.</t>

<t>The maximum supported BSL has a different impact in BIER-TE than it has in BIER: A smaller maximum supported BSL in BIER primarily leads to less replication efficiency: With a BSL of 256, BIER can be up to 256 more efficient than unicast (1 packet for 256 receivers). In BIER-TE, the BSL also limits the size of the topology towards BFER and the alternative paths that can explicitly be engineered to reach the BFER. One simple guess is that 50% of bits in a bitstring may be required for intermediate hops, therefore requiring about double the amount of bits as BIER - as the cost of being able to engineer pats.</t>

<t>So far, there is no comprehensive analysis of the number of required bits for specific scenarios in BIER-TE. The following subsections give two examples of such scenarios and how to use and save BIER-TE bits for intermedia hops.</t>


    <section anchor="IPTV" title="IPTV">
	
	<t>Multicast is widely used for IPTV services by simultaneously delivering a single stream of video to thousands of recipients. Currently, PIM is widely used to provide multicast capability usually from core router(CR) to provider edges (PEs). And the multicast tree is usually constructed in the hierarchical way. The end users using PIM/IGMP to request the multicast data. BIER can be well used in from CR to those PEs. The number of hops from multicast source (CR) which could be BFIRs, to the multicast receivers (PE) which can be regarded as BRERs is usually no more than 10. BIER-TE will be useful in the cases where different video channels can have different transport paths to achieve load balancing.</t>
	
	<t>
	To save the bit consumption, 2 ways could be used:
	</t>
	
	<t>
	1. Multiple BFRs and routes are required to receive the same data. These BFRs or links can share one bit.
	</t>
	
	<t>
	2. Different bits can be used for pruning. But these bits can be reused in similar but different groups.
	</t>
	
	<t>
	Considering an example illustrated as following:
	</t>
	
	<figure> <artwork align="left"><![CDATA[


                       +----+
                       |BFIR|
                       +-+--+
                         |
                         |
           +-------------------------+---|
           |                             |
           |                             |
           |                             |
       +---+---+                    +----+----+
       | BFR1  |       ....         |   BFRn  |
       +---+---+                    +----+----+
           |                             |
           |                            ...
    +------|-------+              +------+---------+
    |      |       |              |      |         |
    |      |       |              |      |         |
 +--+----------------+         +---------+-----------+
 |        BFER1      |         |       BFERn         |
 +--+----------------+         +---------------------+
]]></artwork></figure>

    <t>
	BRF1 and BFRn, and other BFRs in between, can share one bit because they are receiving all the content and don't need pruning. From BFR1 to BFER1, there are 3 ways to reach BFER1. So these 3 ways can be assigned with different bits. But these 3 bits can be reused in the group from BFRn to BFERn, and other groups in between, which share the same topology as the group from BFR1 to BFER1.
	</t>
	
	<t>
	BIER-TE can be well implemented using these 2 ways to save the bit consumption in IPTV networks with the similar topologies like the above example.
	</t>
    </section>

    <section anchor="MVPN" title="Multicast in L3VPN">

	<t>
	MVPN is a technology to deploy multicast service in an existing VPN or as part of a transport infrastructure. Multicast data is transmitted between private networks over a VPN infrastructure by encapsulating the original multicast packets. PE routers are connected to these private networks either containing receivers or senders.
	</t>
	
	<t>
	There are several multicast applications widely using the MVPN deployment. For example, L3VPN multicast service offered by service providers to enterprise customers, and video transport applications for separation between different customers: One content provider may provider video wholesale service to another, or multiple content provider may share one network to transport video from headend. Especially the latter case, network SLAs should be guaranteed as the original video content is precious. Thus, traffic engineering is required.
	</t>
	
	<t>
	According to the current implementations, the scale of a MVPN network usually contains less than several hundreds of PEs, and hundreds of core routers which are connected in full mesh, like following figure illustrated.
	</t>
	
	<figure> <artwork align="left"><![CDATA[

+--+          +----+         +----+        +--+
|PE+----------+ CE +---------+ CE +--------+PE|
++-+          +-+--+         +--+-+        +--+
 |              |               |             |
 |              |               |             |
++-+          +-+--+         +--+-+         +-++
|PE+----------+ CE +---------+ CE +---------+PE|
+--+          +----+         +----+         +--+

]]></artwork></figure>

    <t>
	In such a case, the ways in Section 7.5.2 of <xref target="BIER-TE-ARCH"></xref> can be used by regarding the CE area as the Core. Based on this, current BIER design is sufficient to be reused in BIER-TE.
	</t>
    </section>
    <!-- mvpn -->
</section>

<section anchor="acknowledgements" title="Acknowledgements">

<t>TBD.</t>

</section>

<section anchor="Security" title="Security Considerations">

<t>The security considerations are in compliance with BIER-TE architecture <xref target="BIER-TE-ARCH"></xref> and BIER encapsulation <xref target="RFC8296">RFC8296</xref>. And the content in this document does not create any other attacks or security concerns.</t>

</section>

<section anchor="IANA" title="IANA Considerations">

<t>
TBD.
</t>

</section>

</middle>

<back>

    <references title="Normative References">	  
	
      &RFC2119;
      &RFC8279;
      &RFC8296;
	  <reference anchor="BIER-TE-ARCH">
	    <front>
		  <title>Traffic Engineering for Bit Index Explicit Replication BIER-TE</title>
		  <author fullname="T. Eckert" initials="T." surname="Eckert"></author>
		  <author fullname="G. Cauchie" initials="G." surname="Cauchie"></author>
		  <author fullname="W. Braun" initials="W." surname="Braun"></author>
		  <author fullname="M. Menth" initials="M." surname="Menth"></author>
		  <date month="January" year="2018" />
		</front>
		
		<seriesInfo name="ID" value="draft-ietf-bier-te-arch-00 (work in progress)" />
	  </reference>
	  
	  <reference anchor="BIER-non-MPLS">
	    <front>
		  <title>An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation</title>
		  <author fullname="I. Wijnands" initials="I." surname="Wijnands"></author>
		  <author fullname="X. Xu" initials="X." surname="Xu"></author>
		  <author fullname="H. Bidgoli" initials="H." surname="Bidgoli"></author>
		  <date month="August" year="2017" />
		</front>		
		<seriesInfo name="ID" value="draft-wijnandsxu-bier-non-mpls-bift-encoding-01 (work in progress)" />
	  </reference>
          <?rfc include="reference.I-D.thubert-bier-replication-elimination"?>

    </references>

    <references title="Informative References">	  

          <?rfc include="reference.I-D.ietf-detnet-dp-sol"?>
	  
    </references>

      <!-- TODO change reference below as soon as its available from tool chain-->


</back>
</rfc>
