Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 8279

Experimental
Pages: 43
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: BIER

Multicast Using Bit Index Explicit Replication (BIER)

Part 1 of 3, p. 1 to 13
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                 IJ. Wijnands, Ed.
Request for Comments: 8279                           Cisco Systems, Inc.
Category: Experimental                                     E. Rosen, Ed.
ISSN: 2070-1721                                   Juniper Networks, Inc.
                                                             A. Dolganow
                                                                   Nokia
                                                           T. Przygienda
                                                  Juniper Networks, Inc.
                                                               S. Aldrin
                                                            Google, Inc.
                                                           November 2017


         Multicast Using Bit Index Explicit Replication (BIER)

Abstract

   This document specifies a new architecture for the forwarding of
   multicast data packets.  It provides optimal forwarding of multicast
   packets through a "multicast domain".  However, it does not require a
   protocol for explicitly building multicast distribution trees, nor
   does it require intermediate nodes to maintain any per-flow state.
   This architecture is known as "Bit Index Explicit Replication"
   (BIER).  When a multicast data packet enters the domain, the ingress
   router determines the set of egress routers to which the packet needs
   to be sent.  The ingress router then encapsulates the packet in a
   BIER header.  The BIER header contains a bit string in which each bit
   represents exactly one egress router in the domain; to forward the
   packet to a given set of egress routers, the bits corresponding to
   those routers are set in the BIER header.  The procedures for
   forwarding a packet based on its BIER header are specified in this
   document.  Elimination of the per-flow state and the explicit tree-
   building protocols results in a considerable simplification.

Top      ToC       Page 2 
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8279.

Copyright Notice

   Copyright (c) 2017 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
   (https://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. The BFR Identifier and BFR-Prefix ...............................7
   3. Encoding BFR Identifiers in BitStrings ..........................8
   4. Layering .......................................................11
      4.1. The Routing Underlay ......................................11
      4.2. The BIER Layer ............................................12
      4.3. The Multicast Flow Overlay ................................13
   5. Advertising BFR-ids and BFR-Prefixes ...........................13
   6. BIER Intra-Domain Forwarding Procedures ........................15
      6.1. Overview ..................................................15
      6.2. BFR Neighbors .............................................17
      6.3. The Bit Index Routing Table ...............................18
      6.4. The Bit Index Forwarding Table ............................19
      6.5. The BIER Forwarding Procedure .............................20
      6.6. Examples of BIER Forwarding ...............................23
           6.6.1. Example 1 ..........................................23
           6.6.2. Example 2 ..........................................24
      6.7. Equal-Cost Multipath Forwarding ...........................26
           6.7.1. Non-deterministic ECMP .............................27
           6.7.2. Deterministic ECMP .................................28
      6.8. Prevention of Loops and Duplicates ........................29
      6.9. When Some Nodes Do Not Support BIER .......................30
      6.10. Use of Different BitStringLengths within a Domain ........33
           6.10.1. BitStringLength Compatibility Check ...............34
           6.10.2. Handling BitStringLength Mismatches ...............36
           6.10.3. Transitioning from One BitStringLength to
                   Another ...........................................36
   7. Operational Considerations .....................................37
      7.1. Configuration .............................................37
   8. IANA Considerations ............................................37
   9. Security Considerations ........................................38
   10. References ....................................................39
      10.1. Normative References .....................................39
      10.2. Informative References ...................................39
   Acknowledgements ..................................................40
   Contributors ......................................................41
   Authors' Addresses ................................................43

Top      ToC       Page 4 
1.  Introduction

   This document specifies a new architecture for the forwarding of
   multicast data packets.  The architecture provides optimal forwarding
   of multicast data packets through a "multicast domain".  However, it
   does not require the use of a protocol for explicitly building
   multicast distribution trees, and it does not require intermediate
   nodes to maintain any per-flow state.  This architecture is known as
   "Bit Index Explicit Replication" (BIER).

   A router that supports BIER is known as a "Bit-Forwarding Router"
   (BFR).  The BIER control-plane protocols (see Section 4.2) run within
   a "BIER domain", allowing the BFRs within that domain to exchange the
   information needed for them to forward packets to each other
   using BIER.

   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).  A BFR that receives a
   multicast data packet from another BFR in the same BIER domain, and
   forwards the packet to another BFR in the same BIER domain, will be
   known as a "transit BFR" for that packet.  A single BFR may be a BFIR
   for some multicast traffic while also being a BFER for some multicast
   traffic and a transit BFR for some multicast traffic.  In fact, for a
   given packet, a BFR may be a BFIR and/or a transit BFR and/or (one
   of) the BFER(s) for that packet.

   A BIER domain may contain one or more sub-domains.  Each BIER domain
   MUST contain at least one sub-domain, the "default sub-domain" (also
   denoted "sub-domain 0").  If a BIER domain contains more than one
   sub-domain, each BFR in the domain MUST be provisioned to know the
   set of sub-domains to which it belongs.  Each sub-domain is
   identified by a sub-domain-id in the range [0,255].

   For each sub-domain to which a given BFR belongs, if the BFR is
   capable of acting as a BFIR or a BFER, it MUST be provisioned with a
   "BFR-id" that is unique within the sub-domain.  A BFR-id is a small
   unstructured positive integer.  For instance, if a particular BIER
   sub-domain contains 1,374 BFRs, each one could be given a BFR-id in
   the range [1,1374].

   If a given BFR belongs to more than one sub-domain, it may (though it
   need not) have a different BFR-id for each sub-domain.

   When a multicast packet arrives from outside the domain at a BFIR,
   the BFIR determines the set of BFERs to which the packet will be
   sent.  The BFIR also determines the sub-domain in which the packet
   will be sent.  Determining the sub-domain in which a given packet

Top      ToC       Page 5 
   will be sent is known as "assigning the packet to a sub-domain".
   Procedures for choosing the sub-domain to which a particular packet
   is assigned are outside the scope of this document.  However, once a
   particular packet has been assigned to a particular sub-domain, it
   remains assigned to that sub-domain until it leaves the BIER domain.
   That is, the sub-domain to which a packet is assigned MUST NOT be
   changed while the packet is in flight through the BIER domain.

   Once the BFIR determines the sub-domain and the set of BFERs for a
   given packet, the BFIR encapsulates the packet in a "BIER header".
   The BIER header contains a bit string in which each bit represents a
   single BFR-id.  To indicate that a particular BFER is to receive a
   given packet, the BFIR sets the bit corresponding to that BFER's
   BFR-id in the sub-domain to which the packet has been assigned.  We
   will use the term "BitString" to refer to the bit string field in the
   BIER header.  We will use the term "payload" to refer to the packet
   that has been encapsulated.  Thus, a "BIER-encapsulated" packet
   consists of a "BIER header" followed by a "payload".

   The number of BFERs to which a given packet can be forwarded is
   limited only by the length of the BitString in the BIER header.
   Different deployments can use different BitString lengths.  We will
   use the term "BitStringLength" to refer to the number of bits in the
   BitString.  It is possible that some deployments will have more BFERs
   in a given sub-domain than there are bits in the BitString.  To
   accommodate this case, the BIER encapsulation includes both the
   BitString and a "Set Identifier" (SI).  It is the BitString and the
   SI together that determine the set of BFERs to which a given packet
   will be delivered:

   o  By convention, the least significant (rightmost) bit in the
      BitString is "bit 1", and the most significant (leftmost) bit is
      "bit BitStringLength".

   o  If a BIER-encapsulated packet has an SI of n and a BitString with
      bit k set, then the packet must be delivered to the BFER whose
      BFR-id (in the sub-domain to which the packet has been assigned)
      is n*BitStringLength+k.

   For example, suppose the BIER encapsulation uses a BitStringLength of
   256 bits.  By convention, the least significant (rightmost) bit is
   bit 1, and the most significant (leftmost) bit is bit 256.  Suppose
   that a given packet has been assigned to sub-domain 0 and needs to be
   delivered to three BFERs, where those BFERs have BFR-ids in
   sub-domain 0 of 13, 126, and 235, respectively.  The BFIR would
   create a BIER encapsulation with the SI set to zero and with bits 13,
   126, and 235 of the BitString set.  (All other bits of the BitString
   would be clear.)  If the packet also needs to be sent to a BFER whose

Top      ToC       Page 6 
   BFR-id is 257, the BFIR would have to create a second copy of the
   packet, and the BIER encapsulation would specify an SI of 1, and a
   BitString with bit 1 set and all the other bits clear.

   It is generally advantageous to assign the BFR-ids of a given
   sub-domain so that as many BFERs as possible can be represented in a
   single bit string.

   Suppose a BFR (call it "BFR-A") receives a packet whose BIER
   encapsulation specifies an SI of 0 and a BitString with bits 13, 26,
   and 235 set.  Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C,
   such that the best path to BFERs 13 and 26 is via BFR-B, but the best
   path to BFER 235 is via BFR-C.  BFR-A will then replicate the packet,
   sending one copy to BFR-B and one copy to BFR-C.  However, BFR-A will
   clear bit 235 in the BitString of the packet copy it sends to BFR-B
   and will clear bits 13 and 26 in the BitString of the packet copy it
   sends to BFR-C.  As a result, BFR-B will forward the packet only
   towards BFERs 13 and 26, and BFR-C will forward the packet only
   towards BFER 235.  This ensures that each BFER receives only one copy
   of the packet.

   Detailed procedures for forwarding a BIER-encapsulated packet through
   a BIER domain can be found in Section 6.

   With this forwarding procedure, a multicast data packet can follow an
   optimal path from its BFIR to each of its BFERs.  Further, since the
   set of BFERs for a given packet is explicitly encoded into the BIER
   header, the packet is not sent to any BFER that does not need to
   receive it.  This allows for optimal forwarding of multicast traffic.
   This optimal forwarding is achieved without any need for transit BFRs
   to maintain per-flow state or to run a multicast tree-building
   protocol.

   The idea of encoding the set of egress nodes into the header of a
   multicast packet is not new.  For example, [Boivie_Feldman] proposes
   to encode the set of egress nodes as a set of IP addresses, and
   proposes mechanisms and procedures that are in some ways similar to
   those described in the current document.  However, since BIER encodes
   each BFR-id as a single bit in a bit string, it can represent up to
   128 BFERs in the same number of bits that it would take to carry the
   IPv6 address of a single BFER.  Thus, BIER scales to a much larger
   number of egress nodes per packet.

   BIER does not require that each transit BFR look up the best path to
   each BFER that is identified in the BIER header; the number of
   lookups required in the forwarding path for a single packet can be

Top      ToC       Page 7 
   limited to the number of neighboring BFRs; this can be much smaller
   than the number of BFERs.  See Section 6 (especially Section 6.5) for
   details.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  The BFR Identifier and BFR-Prefix

   Each BFR MUST be assigned a single "BFR-prefix" for each sub-domain
   to which it belongs.  A BFR's BFR-prefix MUST be an IP address
   (either IPv4 or IPv6) of the BFR.  It is RECOMMENDED that the
   BFR-prefix be a loopback address of the BFR.

   If a BFR belongs to more than one sub-domain, it may (though it need
   not) have a different BFR-prefix in each sub-domain.

   All BFR-prefixes used within a given sub-domain MUST belong to the
   same address family (either IPv4 or IPv6).

   The BFR-prefix of a given BFR in a given sub-domain MUST be routable
   in that sub-domain.  Whether a particular BFR-prefix is routable in a
   given sub-domain depends on the "routing underlay" associated with
   that sub-domain.  The notion of "routing underlay" is described in
   Section 4.1.

   A "BFR Identifier" (BFR-id) is a number in the range [1,65535].
   Within a given sub-domain, every BFR that may need to function as a
   BFIR or BFER MUST have a single BFR-id, which identifies it uniquely
   within that sub-domain.  A BFR that does not need to function as a
   BFIR or BFER in a given sub-domain does not need to have a BFR-id in
   that sub-domain.

   The value 0 is not a legal BFR-id.

   The procedure for assigning a particular BFR-id to a particular BFR
   is outside the scope of this document.  However, it is RECOMMENDED
   that the BFR-ids for each sub-domain be assigned "densely" from the
   numbering space, as this will result in a more efficient encoding
   (see Section 3).  That is, if there are 256 or fewer BFERs, it is
   RECOMMENDED to assign all the BFR-ids from the range [1,256].  If
   there are more than 256 BFERs but less than 512, it is RECOMMENDED to
   assign all the BFR-ids from the range [1,512], with as few "holes" as

Top      ToC       Page 8 
   possible in the earlier range.  However, in some deployments, it may
   be advantageous to depart from this recommendation; this is discussed
   further in Section 3.

   In some deployments, it may not be possible to support (in a given
   sub-domain) the full range of 65,535 BFR-ids.  For example, if the
   BFRs in a given sub-domain only support 16 SIs and if they only
   support BitStringLengths of 256 or less, then only 16*256=4,096
   BFR-ids can be supported in that sub-domain.

3.  Encoding BFR Identifiers in BitStrings

   To encode a BFR-id in a BIER data packet, one must convert the BFR-id
   to an SI and a BitString.  This conversion depends upon the parameter
   we are calling "BitStringLength".  The conversion is done as follows.
   If the BFR-id is N, then

   o  SI is the integer part of the quotient (N-1)/BitStringLength.

   o  The BitString has one bit position set.  If the low-order bit is
      bit 1 and the high-order bit is bit BitStringLength, the bit
      position that represents BFR-id N is
      ((N-1) modulo BitStringLength)+1.

   If several different BFR-ids all resolve to the same SI, then all of
   those BFR-ids can be represented in a single BitString.  The
   BitStrings for all of those BFR-ids are combined using a bitwise
   logical OR operation.

   Within a given BIER domain (or even within a given BIER sub-domain),
   different values of BitStringLength may be used.  Each BFR MUST be
   provisioned to know the following:

   o  The BitStringLength ("Imposition BitStringLength") and sub-domain
      ("Imposition sub-domain") to use when it imposes (as a BFIR) a
      BIER encapsulation on a particular set of packets, and

   o  The BitStringLengths ("Disposition BitStringLengths") that it will
      process when (as a BFR or BFER) it receives packets from a
      particular sub-domain.

   It is not required that a BFIR use the same Imposition
   BitStringLength or the same Imposition sub-domain for all packets on
   which it imposes the BIER encapsulation.  However, if a particular
   BFIR is provisioned to use a particular Imposition BitStringLength
   and a particular Imposition sub-domain when imposing the
   encapsulation on a given set of packets, all other BFRs with BFR-ids
   in that sub-domain SHOULD be provisioned to process received BIER

Top      ToC       Page 9 
   packets with that BitStringLength (i.e., all other BFRs with BFR-ids
   in that sub-domain SHOULD be provisioned with that BitStringLength as
   a Disposition BitStringLength for that sub-domain).  Exceptions to
   this rule MAY be made under certain conditions; this is discussed in
   Section 6.10.

   When a BIER encapsulation is specified, the specification MUST define
   a default BitStringLength for the encapsulation.  Every BFIR
   supporting that encapsulation MUST be capable of being provisioned
   with that default BitStringLength as its Imposition BitStringLength.
   Every BFR and BFER supporting that encapsulation MUST be capable of
   being provisioned with that default BitStringLength as a Disposition
   BitStringLength.

   The specification of a BIER encapsulation MAY also allow the use of
   other BitStringLengths.

   If a BFR is capable of being provisioned with a given value of
   BitStringLength as an Imposition BitStringLength, it MUST also be
   capable of being provisioned with that same value as one of its
   Disposition BitStringLengths.  It SHOULD be capable of being
   provisioned with each legal smaller value of BitStringLength as (a)
   its Imposition BitStringLength, and (b) one of its Disposition
   BitStringLengths.

   In order to support transition from one BitStringLength to another,
   every BFR MUST be capable of being provisioned to simultaneously use
   two different Disposition BitStringLengths.

   A BFR MUST support SI values in the range [0,15] and MAY support SI
   values in the range [0,255].  ("Supporting the values in a given
   range" means, in this context, that any value in the given range is
   legal and will be properly interpreted.)  Note that for a given
   BitStringLength, the total number of BFR-ids that can be represented
   is the product of the BitStringLength and the number of supported
   SIs.  For example, if a deployment uses (in a given sub-domain) a
   BitStringLength of 64 and supports 256 SIs, that deployment can only
   support 16384 BFR-ids in that sub-domain.  Even a deployment that
   supports 256 SIs will not be able to support 65,535 BFR-ids unless it
   uses a BitStringLength of at least 256.

   When a BFIR determines that a multicast data packet, assigned to a
   given sub-domain, needs to be forwarded to a particular set of
   destination BFERs, the BFIR partitions that set of BFERs into
   subsets, where each subset contains the target BFERs whose BFR-ids in
   the given sub-domain all resolve to the same SI.  Call these the
   "SI-subsets" for the packet.  Each SI-subset can be represented by a
   single BitString.  The BFIR creates a copy of the packet for each

Top      ToC       Page 10 
   SI-subset.  The BIER encapsulation is then applied to each packet.
   The encapsulation specifies a single SI for each packet and contains
   the BitString that represents all the BFR-ids in the corresponding
   SI-subset.  Of course, in order to properly interpret the BitString,
   it must be possible to infer the sub-domain-id from the encapsulation
   as well.

   Suppose, for example, that a BFIR determines that a given packet
   needs to be forwarded to three BFERs, whose BFR-ids (in the
   appropriate sub-domain) are 27, 235, and 497.  The BFIR will have to
   forward two copies of the packet.  One copy, associated with SI=0,
   will have a BitString with bits 27 and 235 set.  The other copy,
   associated with SI=1, will have a BitString with bit 241 set.

   In order to minimize the number of copies that must be made of a
   given multicast packet, it is RECOMMENDED that the BFR-ids used in a
   given sub-domain be assigned "densely" (see Section 2) from the
   numbering space.  This will minimize the number of SIs that have to
   be used in that sub-domain.  However, depending upon the details of a
   particular deployment, other assignment methods may be more
   advantageous.  Suppose, for example, that in a certain deployment,
   every multicast flow is intended either for the "east coast" or for
   the "west coast", but not for both coasts.  In such a deployment, it
   would be advantageous to assign BFR-ids so that all the "west coast"
   BFR-ids fall into the same SI-subset and so that all the "east coast"
   BFR-ids fall into the same SI-subset.

   When a BFR receives a BIER data packet, it will infer the SI from the
   encapsulation.  The set of BFERs to which the packet needs to be
   forwarded can then be inferred from the SI and the BitString.

   In some of the examples given later in this document, we will use a
   BitStringLength of 4 and will represent a BFR-id in the form
   "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a
   BitStringLength of 4) and xyzw is a string of 4 bits.  A
   BitStringLength of 4 is used only in the examples; we would not
   expect actual deployments to have such a small BitStringLength.

   It is possible that several different forms of BIER encapsulation
   will be developed.  If so, the particular encapsulation that is used
   in a given deployment will depend on the type of network
   infrastructure that is used to realize the BIER domain.  Details of
   the BIER encapsulation(s) will be given in companion documents.  An
   encapsulation for use in MPLS networks is described in
   [MPLS_BIER_ENCAPS]; that document also describes a very similar
   encapsulation that can be used in non-MPLS networks.

Top      ToC       Page 11 
4.  Layering

   It is helpful to think of the BIER architecture as consisting of
   three layers: the "routing underlay", the "BIER layer", and the
   "multicast flow overlay".

4.1.  The Routing Underlay

   The "routing underlay" establishes "adjacencies" between pairs of
   BFRs and determines one or more "best paths" from a given BFR to a
   given set of BFRs.  Each such path is a sequence of BFRs
   <BFR(k), BFR(k+1), ..., BFR(k+n)> such that BFR(k+j) is "adjacent" to
   BFR(k+j+1) (for 0<=j<n).

   At a given BFR, say BFR-A, for every IP address that is the address
   of a BFR in the BIER domain, the routing underlay will map that IP
   address into a set of one or more "equal-cost" adjacencies.  If a
   BIER data packet has to be forwarded by BFR-A to a given BFER, say
   BFER-B, the packet will follow the path from BFR-A to BFER-B that is
   determined by the routing underlay.

   It is expected that in a typical deployment, the routing underlay
   will be the default topology that the Interior Gateway Protocol
   (IGP), e.g., OSPF, uses for unicast routing.  In that case, the
   underlay adjacencies are just the OSPF adjacencies.  A BIER data
   packet traveling from BFR-A to BFER-B will follow the path that OSPF
   has selected for unicast traffic from BFR-A to BFER-B.

   If one wants to have multicast traffic from BFR-A to BFER-B travel a
   path that is different from the path used by the unicast traffic from
   BFR-A to BFER-B, one can use a different underlay.  For example, if
   multi-topology OSPF is being used, one OSPF topology could be used
   for unicast traffic and the other for multicast traffic.  (Each
   topology would be considered to be a different underlay.)
   Alternatively, one could deploy a routing underlay that creates a
   multicast-specific tree of some sort.  BIER could then be used to
   forward multicast data packets along the multicast-specific tree,
   while unicast packets follow the "ordinary" OSPF best path.  (In a
   case like this, many multicast flows could be traveling along a
   single tree, and the BitString carried by a particular packet would
   identify those nodes of the tree that need to receive that packet.)
   It is even possible to have multiple routing underlays used by BIER,
   as long as one can infer from a data packet's BIER encapsulation
   which underlay is being used for that packet.

Top      ToC       Page 12 
   If multiple routing underlays are used in a single BIER domain, each
   BIER sub-domain MUST be associated with a single routing underlay
   (though multiple sub-domains may be associated with the same routing
   underlay).  A BFR that belongs to multiple sub-domains MUST be
   provisioned to know which routing underlay is used by each
   sub-domain.  By default (i.e., in the absence of any provisioning to
   the contrary), each sub-domain uses the default topology of the
   unicast IGP as the routing underlay.

   In scenarios where External BGP (EBGP) is used as the IGP, the
   underlay adjacencies, by default, are the BGP adjacencies.

   Specification of the protocols and procedures of the routing underlay
   is outside the scope of this document.

4.2.  The BIER Layer

   The BIER layer consists of the protocols and procedures that are used
   in order to transmit a multicast data packet across a BIER domain,
   from its BFIR to its BFERs.  This includes the following components:

   o  Protocols and procedures that a given BFR uses to advertise, to
      all other BFRs in the same BIER domain:

      *  its BFR-prefix;

      *  its BFR-id in each sub-domain for which it has been provisioned
         with a BFR-id;

      *  the set of Disposition BitStringLengths it has been provisioned
         to use for each sub-domain;

      *  optionally, information about the routing underlay associated
         with each sub-domain.

   o  The procedures used by a BFIR to impose a BIER header on a
      multicast data packet.

   o  The procedures for forwarding BIER-encapsulated packets and for
      modifying the BIER header during transit.

   o  The procedures used by a BFER to decapsulate a BIER packet and
      properly dispatch it.

Top      ToC       Page 13 
4.3.  The Multicast Flow Overlay

   The "multicast flow overlay" consists of the set of protocols and
   procedures that enable the following set of functions.

   o  When a BFIR receives a multicast data packet from outside the BIER
      domain, the BFIR must determine the set of BFERs for that packet.
      This information is provided by the multicast flow overlay.

   o  When a BFER receives a BIER-encapsulated packet from inside the
      BIER domain, the BFER must determine how to further forward the
      packet.  This information is provided by the multicast flow
      overlay.

   For example, suppose the BFIR and BFERs are Provider Edge (PE)
   routers providing Multicast Virtual Private Network (MVPN) service.
   The multicast flow overlay consists of the protocols and procedures
   described in [RFC6513] and [RFC6514].  The MVPN signaling described
   in those RFCs enables an ingress PE to determine the set of egress
   PEs for a given multicast flow (or set of flows); it also enables an
   egress PE to determine the "Virtual Routing and Forwarding Tables"
   (VRFs) to which multicast packets from the backbone network should be
   sent.  MVPN signaling also has several components that depend on the
   type of "tunneling technology" used to carry multicast data through
   the network.  Since BIER is, in effect, a new type of "tunneling
   technology", some extensions to the MVPN signaling are needed in
   order to properly interface the multicast flow overlay with the BIER
   layer.  These are specified in [BIER_MVPN].

   MVPN is just one example of a multicast flow overlay.  Protocols and
   procedures for other overlays will be provided in companion
   documents.  It is also possible to implement the multicast flow
   overlay by means of a "Software-Defined Network" (SDN) controller.
   Specification of the protocols and procedures of the multicast flow
   overlay is outside the scope of this document.



(page 13 continued on part 2)

Next Section