BIER Encapsulation
draft-xu-bier-encapsulation-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Xiaohu Xu  , somasundaram.s@alcatel-lucent.com 
Last updated 2014-09-30
Stream (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: Standards Track                         S. Somasundaram
Expires: April 3, 2015                                    Alcatel-Lucent
                                                      September 30, 2014

                           BIER Encapsulation
                     draft-xu-bier-encapsulation-00

Abstract

   Bit Index Explicit Replication (BIER) is a new multicast forwarding
   paradigm which doesn't require an explicit tree-building protocol and
   doesn't require intermediate routers to maintain any multicast state.
   This document proposes a transport-indepedent BIER encapsulation
   header which is applicable in any kind of transport networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 3, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Xu & Somasundaram         Expires April 3, 2015                 [Page 1]
Internet-Draft             BIER Encapsulation             September 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  BIER Header . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Transport Encapsulation for BIER Header . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Bit Index Explicit Replication (BIER)
   [I-D.wijnands-bier-architecture] is a new multicast forwarding
   paradigm which doesn't require an explicit tree-building protocol and
   doesn't require intermediate routers to maintain any multicast state.
   As described in [I-D.wijnands-bier-architecture], BIER requires that
   a multicast data packet (e.g., an IP packet or an MPLS packet) to be
   encapsulated with a BIER header that carries the information needed
   for supporting the BIER forwarding procedures.  This information at
   least includes Set-Identifier (SI), Multi-Topology Identifier (MT-ID)
   and BitString.  The SI and the BitString are used together to
   identify the set of egress BFRs (BFERs) to which the packet must be
   delivered.  In addition, to indicate what type of payload is
   following the BIER header, a protocol type field is neccessary.  This
   document proposes a transport-indepedent BIER encapsulation header
   which is applicable in any kind of transport networks.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Terminology

   This memo makes use of the terms defined in
   [I-D.wijnands-bier-architecture].

Xu & Somasundaram         Expires April 3, 2015                 [Page 2]
Internet-Draft             BIER Encapsulation             September 2014

3.  BIER Header

   The BIER header is shown as follows:

        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  |   BS Length   |       SI      |         MT-ID         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           BFIR-ID             |         Protocol Type         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Entropy             |     ToS       |      TTL      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                BitString  (first 32 bits)                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                BitString  (last 32 bits)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Ver(sion): This 4-bit field identifies the version of the BIER
      header.  This document specifies version 0 of the BIER header.

      BS Length: This 8-bit field indicates the length of the BitString
      in 4-byte unit.  In other words, if the BitString length is 4*n
      byte, this field should be filled with n (e.g., if the length of
      the BitString is 32 bits, the length field is set to 1, if the
      length of the BitString is 64 bits, the length field is set to
      2...)

      SI: This 8-bit field is filled with the Set-Identifier (SI) for
      this packet.

      MT-ID: This 12-bit field indicates which routing topology
      [RFC4915] [RFC5120] should be applied for BIER forwarding.

      BFIR-ID: This 16-bit field is filled with the BFR-ID of the BFIR.

      Protocol Type: This 16-bit field indicates the protocol type of
      the BIER payload as per [ETYPES].  The BIER payload types include
      but not limited to IPv4 packet, IPv6 packet, MPLS packet, VXLAN
      packet [RFC7348] VXLAN-GPE packet [I-D.quinn-vxlan-gpe], etc.  The
      corresponding Ethertype codes for VXLAN and VXLAN-GPE are TBD1 and
      TBD2 respectively.

      Entropy: This 16-bit field specifies an "entropy" value that can
      be used for load balancing purposes.

Xu & Somasundaram         Expires April 3, 2015                 [Page 3]
Internet-Draft             BIER Encapsulation             September 2014

      BitString: The variable-length BitString field that, together with
      the SI field, identifies all the destination BFERs for this
      packet.

      ToS: The usage of this field is no different from that of the Type
      of Service (ToS) field in the IPv4 header.

      TTL: The usage of this field is no different from that of the Time
      to Live (TTL) field in the IPv4 header.

4.  Transport Encapsulation for BIER Header

   Since the BIER encapsulation format as specifed in Section 3 is
   transport-indepedent, it can be encapsulated with any type of
   transport encapsulation headers, such as Ethernet header, PPP header,
   IP header, MPLS header, GRE header, UDP header etc.  It requires for
   each possible transport encapsulation header to be able to indicate
   the payload is an BIER header.  For instance, In the BIER-in-MAC
   encapsulation case, the EtherType field in the Ethernet header is
   used.  In the BIER-in-IP encapsulation case, the Protocol or Next-
   Header field in the IPv4 or IPv6 header is used.  In the BIER-in-MPLS
   encapsulation case, either the Protocol Type field
   [I-D.xu-mpls-payload-protocol-identifier] within the MPLS packet or a
   to-be-assigned Extended Spcial Purpose label [RFC7274] is used.

5.  Acknowledgements

   TBD.

6.  IANA Considerations

   This document includes a request to IANA to allocate an EtherType
   code, IPv4 protocol type code, IPv6 Next-Header code, UDP destination
   port for carring the BIER-encapsulated packet over the corresponding
   transport networks.  Furthermore, This document includes a request to
   IANA to allocate an EtherType code for VXLAN and VXLAN-GPE.

7.  Security Considerations

   TBD.

8.  References

8.1.  Normative References

   [ETYPES]   The IEEE Registration Authority, "IEEE 802 Numbers", 2012.

Xu & Somasundaram         Expires April 3, 2015                 [Page 4]
Internet-Draft             BIER Encapsulation             September 2014

   [I-D.wijnands-bier-architecture]
              Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda,
              "Multicast using Bit Index Explicit Replication", draft-
              wijnands-bier-architecture-00 (work in progress),
              September 2014.

   [I-D.xu-mpls-payload-protocol-identifier]
              Xu, X. and M. Chen, "MPLS Payload Protocol Identifier",
              draft-xu-mpls-payload-protocol-identifier-00 (work in
              progress), September 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC 7274, June
              2014.

8.2.  Informative References

   [I-D.quinn-vxlan-gpe]
              Quinn, P., Agarwal, P., Fernando, R., Lewis, D., Kreeger,
              L., Smith, M., Yadav, N., Yong, L., Xu, X., Elzur, U., and
              P. Garg, "Generic Protocol Extension for VXLAN", draft-
              quinn-vxlan-gpe-03 (work in progress), July 2014.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
              4915, June 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, August 2014.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com

Xu & Somasundaram         Expires April 3, 2015                 [Page 5]
Internet-Draft             BIER Encapsulation             September 2014

   S Somasundaram
   Alcatel-Lucent

   Email: somasundaram.s@alcatel-lucent.com

Xu & Somasundaram         Expires April 3, 2015                 [Page 6]