<?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-non-mpls-encap-over-udp-04"
     ipr="trust200902">
  <front>
    <title abbrev="Encapsulating Non-MPLS-BIER in UDP">Encapsulating
    Non-MPLS-BIER in UDP</title>

    <author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
      <organization>Alibaba Inc.</organization>

      <address>
        <email>xiaohu.xxh@alibaba-inc.com</email>
      </address>
    </author>

    <author fullname="Greg Shepherd" initials="G.S." surname="Shepherd">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>gjshep@gmail.com</email>

        <uri/>
      </address>
    </author>

    <!--

-->

    <date day="22" month="January" year="2019"/>

    <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. BIER has two types
      of encapsulation formats: one is MPLS-BIER encapsulation, the other is
      non-MPLS-BIER encapsulation. This document proposes a mechanism of
      encapsulating non-MPLS-BIER packets over UDP tunnels.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> 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 Section 6.9 of <xref
      target="RFC8279"/>, a BFR may need to tunnel a BIER packet over a
      certain kind of tunnel, e.g., UDP tunnel.</t>

      <t><xref target="RFC8296"/> defines two types of BIER encapsulation
      formats: one is MPLS-BIER encapsulation, the other is non-MPLS-BIER
      encapsulation. MPLS-BIER packets can be transported over UDP tunnels by
      using the MPLS-in-UDP encapsulation as described in <xref
      target="RFC7510"/> . This document proposes a mechanism of encapsulating
      non-MPLS-BIER packets over UDP tunnels.</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="RFC8279">
      </xref>and <xref target="RFC8296"/>.</t>
    </section>

    <section title="Encapsulation in UDP">
      <t>Non-MPLS-BIER-in-UDP encapsulation format is shown as follows:
      <figure>
          <artwork><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Source Port = Entropy      |        Dest Port = TBD1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    Non-MPLS-BIER Packet                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 1: Non-MPLS-BIER-in-UDP Encapsulation Format]]></artwork>
        </figure><list>
          <t>Source Port of UDP: <list style="empty">
              <t>This field contains a 16-bit entropy value that is generated
              by the encapsulator to uniquely identify a flow. What
              constitutes a flow is locally determined by the encapsulator and
              therefore is outside the scope of this document. What algorithm
              is actually used by the encapsulator to generate an entropy
              value is outside the scope of this document. For example, the
              20-bit entropy value contained in the BIER header could actually
              be transformed to a 16- bit value and then be filled into this
              field.</t>

              <t>In case the tunnel does not need entropy, this field of all
              packets belonging to a given flow SHOULD be set to a randomly
              selected constant value so as to avoid packet reordering.</t>

              <t>To ensure that the source port number is always in the range
              49152 to 65535 (Note that those ports less than 49152 are
              reserved by IANA to identify specific applications/protocols)
              which may be required in some cases, instead of calculating a
              16-bit hash, the encapsulator SHOULD calculate a 14-bit hash and
              use those 14 bits as the least significant bits of the source
              port field while the most significant two bits SHOULD be set to
              binary 11. That still conveys 14 bits of entropy information
              which would be enough as well in practice.</t>
            </list></t>

          <t>Destination Port of UDP:</t>

          <t><list style="empty">
              <t>This field is set to a value (TBD1) allocated by IANA to
              indicate that the UDP tunnel payload is a non-MPLS-BIER
              packet.</t>
            </list>UDP Length:</t>

          <t><list style="empty">
              <t>The usage of this field is in accordance with the current UDP
              specification <xref target="RFC0768"/>.</t>
            </list></t>

          <t>UDP Checksum:</t>

          <t><list style="empty">
              <t>For IPv4 UDP encapsulation, this field is RECOMMENDED to be
              set to zero for performance or implementation reasons because
              the IPv4 header includes a checksum and use of the UDP checksum
              is optional with IPv4. For IPv6 UDP encapsulation, the IPv6
              header does not include a checksum, so this field MUST contain a
              UDP checksum that MUST be used as specified in <xref
              target="RFC0768"/> and <xref target="RFC2460"/> unless one of
              the exceptions that allows use of UDP zero-checksum mode (as
              specified in <xref target="RFC6935"/>) applies.</t>
            </list></t>

          <t>Non-MPLS-BIER Packet:</t>

          <t><list style="empty">
              <t>This field contains one non-MPLS-BIER packet.</t>
            </list></t>
        </list></t>
    </section>

    <section anchor="Advertising" title="Processing Procedures">
      <t>This Non-MPLS-BIER-in-UDP encapsulation causes non-MPLS BIER packets
      to be forwarded across an IP transit core via "UDP tunnels". While
      performing Non-MPLS-BIER-in-UDP encapsulation, an encapsulator would
      generate an entropy value and encode it in the Source Port field of the
      UDP header. The Destination Port field is set to a value (TBD1)
      allocated by IANA to indicate that the UDP tunnel payload is a
      non-MPLS-BIER packet. Transit routers, upon receiving these UDP
      encapsulated non-MPLS-BIER packets, could balance these packets based on
      the hash of the five-tuple of UDP packets. Decapsulators receiving these
      UDP encapsulated non-MPLS-BIER packets MUST decapsulate these packets by
      removing the UDP header and then forward them accordingly.</t>

      <t>Similar to all other IP-based tunneling technologies,
      Non-MPLS-BIER-in-UDP encapsulation introduces overheads and reduces the
      effective Maximum Transmission Unit (MTU) size. Non-MPLS-BIER-in-UDP
      encapsulation may also impact Time-to-Live (TTL) or Hop Count (HC) and
      Differentiated Services (DSCP). Hence, Non-MPLS-BIER-in-UDP MUST follow
      the corresponding procedures defined in <xref target="RFC2003"/>.</t>

      <t>Encapsulators MUST NOT fragment non-MPLS-BIER packet, and when the
      outer IP header is IPv4, encapsulators MUST set the DF bit in the outer
      IPv4 header. It is strongly RECOMMENDED that IP transit core be
      configured to carry an MTU at least large enough to accommodate the
      added encapsulation headers. Meanwhile, it is strongly RECOMMENDED that
      Path MTU Discovery <xref target="RFC1191"/> <xref target="RFC1981"/> or
      Packetization Layer Path MTU Discovery (PLPMTUD) <xref
      target="RFC4821"/> is used to prevent or minimize fragmentation.</t>
    </section>

    <section title="Congestion Considerations">
      <t>As it's explicitly stated in the Application Statements (Section 6),
      this Non-MPLS-BIER-in-UDP encapsulation method MUST only be used within
      networks that are well-managed, therefore, congestion control mechanism
      is not needed.</t>
    </section>

    <section title="Applicability Statements">
      <t>This Non-MPLS-BIER-in-UDP encapsulation technology MUST only be used
      within networks which are well-managed by a service provider and MUST
      NOT be used within the Internet. In the well-managed network, traffic is
      well-managed to avoid congestion and fragmentation on encapsulated
      packets (i.e., Non-MPLS-BIER packets) are not needed.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>One UDP destination port number indicating non-MPLS-BIER needs to be
      allocated by IANA:</t>

      <t><figure>
          <artwork><![CDATA[   Service Name: Non-MPLS-BIER-in-UDP Transport Protocol(s):UDP 
   Assignee: IESG <iesg@ietf.org> 
   Contact: IETF Chair <chair@ietf.org>. 
   Description: Encapsulate Non-MPLS-BIER packets in UDP tunnels. 
   Reference: This document. 
   Port Number: TBD1 -- To be assigned by IANA.]]></artwork>
        </figure></t>

      <t>One UDP destination port number indicating Non-MPLS-BIER with DTLS
      needs to be allocated by IANA:</t>

      <t><figure>
          <artwork><![CDATA[   Service Name: Non-MPLS-BIER-in-UDP-with-DTLS 
   Transport Protocol(s): UDP 
   Assignee: IESG <iesg@ietf.org> 
   Contact: IETF Chair <chair@ietf.org>. 
   Description: Encapsulate Non-MPLS-BIER packets in UDP tunnels with DTLS. 
   Reference: This document. 
   Port Number: TBD2 -- To be assigned by IANA.]]></artwork>
        </figure></t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security problems faced with the Non-MPLS-BIER-in-UDP tunnel are
      exactly the same as those faced with MPLS-in-UDP tunnel <xref
      target="RFC7510"/>. In other words, the Non-MPLS-BIER-in-UDP tunnel as
      defined in this document by itself cannot ensure the integrity and
      privacy of data packets being transported through the
      Non-MPLS-BIER-in-UDP tunnel and cannot enable the tunnel decapsulator to
      authenticate the tunnel encapsulator. In the case where any of the above
      security issues is concerned, the Non-MPLS-BIER-in-UDP tunnel SHOULD be
      secured with IPsec or DTLS. IPsec was designed as a network security
      mechanism and therefore it resides at the network layer. As such, if the
      tunnel is secured with IPsec, the UDP header would not be visible to
      intermediate routers anymore in either IPsec tunnel or transport mode.
      As a result, the meaning of adopting the Non-MPLS-BIER-in-UDP tunnel as
      an alternative to the Non-MPLS-BIER-in-GRE or Non-MPLS-BIER-in-IP tunnel
      is lost. By comparison, DTLS is better suited for application security
      and can better preserve network and transport layer protocol
      information. Specifically, if DTLS is used, the destination port of the
      UDP header will be filled with a value (TBD2) indicating non-MPLS-BIER
      with DTLS and the source port can still be used as an entropy field for
      load-sharing purposes.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.8279"?>

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

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

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

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

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

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

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

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

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

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

      <!---->
    </references>

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

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