<?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>
