Skip to main content

OSPF Extensions For BIER
draft-ietf-bier-ospf-bier-extensions-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8444.
Authors Peter Psenak , Nagendra Kumar Nainar , IJsbrand Wijnands , Andrew Dolganow , Tony Przygienda , Zhaohui (Jeffrey) Zhang , Sam Aldrin
Last updated 2015-10-19
Replaces draft-psenak-ospf-bier-extensions
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8444 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-bier-ospf-bier-extensions-01
OSPF                                                      P. Psenak, Ed.
Internet-Draft                                                  N. Kumar
Intended status: Standards Track                            IJ. Wijnands
Expires: April 21, 2016                                            Cisco
                                                             A. Dolganow
                                                          Alcatel-Lucent
                                                           T. Przygienda
                                                                Ericsson
                                                                J. Zhang
                                                  Juniper Networks, Inc.
                                                               S. Aldrin
                                                            Google, Inc.
                                                        October 19, 2015

                        OSPF Extensions For BIER
              draft-ietf-bier-ospf-bier-extensions-01.txt

Abstract

   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.

   This document describes the OSPF protocol extension required for BIER
   with MPLS encapsulation.

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

Psenak, et al.           Expires April 21, 2016                 [Page 1]
Internet-Draft          OSPF Extensions For BIER            October 2015

   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 21, 2016.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Flooding of the BIER Information in OSPF  . . . . . . . . . .   3
     2.1.  The BIER Sub-TLV  . . . . . . . . . . . . . . . . . . . .   3
     2.2.  The BIER MPLS Encapsulation Sub-TLV . . . . . . . . . . .   4
     2.3.  Flooding scope of BIER Information  . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

Psenak, et al.           Expires April 21, 2016                 [Page 2]
Internet-Draft          OSPF Extensions For BIER            October 2015

   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
   [I-D.wijnands-mpls-bier-encapsulation].

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

2.  Flooding of the BIER Information in OSPF

   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
   [I-D.wijnands-bier-architecture].

   Given that the BIER information is associated with the prefix, the
   OSPF Extended Prefix Opaque LSA [I-D.ietf-ospf-prefix-link-attr] is
   used to flood BIER related information.

2.1.  The BIER Sub-TLV

   A new Sub-TLV of the Extended Prefix TLV (defined in
   [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.

   BIER Sub-TLV has the following format:

   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-domain-ID |     MT-ID     |              BFR-id           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sub-TLVs (variable)                      |
   +-                                                             -+
   |                                                               |

      Type: TBD

      Length: variable

Psenak, et al.           Expires April 21, 2016                 [Page 3]
Internet-Draft          OSPF Extensions For BIER            October 2015

      Sub-domain-ID: Unique value identifying the BIER sub-domain within
      the BIER domain, as described in section 1 of
      [I-D.wijnands-bier-architecture].

      MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
      the topology that is associated with the BIER sub-domain.

      BFR-id: A 2 octet field encoding the BFR-id, as documented in
      section 2 [I-D.wijnands-bier-architecture].  If the BFR-id is
      zero, it means, the advertising router is not advertising any
      BIER-id.

   Each BFR sub-domain MUST be associate with a single OSPF topology
   that is identified by the MT-ID.  If the association between BEIR
   sub-domain and OSPF topology advertised in the BIER sub-TLV is in
   conflict with the association locally configured on the receiving
   router, BIER sub-TLV SHOULD be ignored.

2.2.  The BIER MPLS Encapsulation Sub-TLV

   BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV.
   BIER MPLS Encapsulation Sub-TLV is used in order to advertise MPLS
   specific information used for BIER.  It MAY appear multiple times in
   the BIER Sub-TLV.

   BIER MPLS Encapsulation Sub-TLV has the following format:

   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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | BS Length |                    Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: TBD

      Length: 4 bytes

      Label Range Size: A 1 octet field encoding the label range size of
      the label range.  It MUST be greater then 0, otherwise the TLV
      MUST be ignored.

      Label Range Base: A 3 octet field, where the 20 rightmost bits
      represent the first label in the label range.

Psenak, et al.           Expires April 21, 2016                 [Page 4]
Internet-Draft          OSPF Extensions For BIER            October 2015

      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
      [I-D.wijnands-mpls-bier-encapsulation].

      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 Sub-domain-ID.  These labels are used for BIER forwarding as
      described in [I-D.wijnands-bier-architecture] and
      [I-D.wijnands-mpls-bier-encapsulation].

      The size of the label range is determined by the number of Set
      Identifiers (SI) (section 2 of [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.

   If same BS length is repeated in multiple BIER MPLS Encapsulation
   Sub-TLV inside the same BIER Sub-TLV, the first BIER MPLS
   Encapsulation Sub-TLV with such BS length MUST be used and any
   subsequent BIER MPLS Encapsulation Sub-TLVs with the same BS length
   MUST be ignored.

   Label ranges within all BIER MPLS Encapsulation Sub-TLV inside the
   same BIER Sub-TLV SHOULD NOT overlap.  If the overlap is detected,
   overlapping BIER MPLS Encapsulation Sub-TLV SHOULD be ignored.

2.3.  Flooding scope of BIER Information

   Flooding scope of the OSPF Extended Prefix Opaque LSA
   [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER
   Sub TLV is set to area.  To allow BIER deployment in a multi-area
   environment, OSPF must propagate BIER information between areas.  The
   following procedure is used in order to propagate BIER related
   information between areas:

      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
      [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:

Psenak, et al.           Expires April 21, 2016                 [Page 5]
Internet-Draft          OSPF Extensions For BIER            October 2015

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

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

3.  Security Considerations

   Implementations must assure that malformed TLV and Sub-TLV
   permutations do not result in errors which cause hard OSPF failures.

4.  IANA Considerations

   The document requests two new allocations from the OSPF Extended
   Prefix sub-TLV registry as defined in
   [I-D.ietf-ospf-prefix-link-attr].

      BIER Sub-TLV: TBD

      BIER MPLS Encapsulation Sub-TLV: TBD

5.  Acknowledgments

   The authors would like to thank Rajiv Asati, Christian Martin, Greg
   Shepherd and Eric Rosen for their contribution.

6.  Normative References

   [I-D.ietf-ospf-prefix-link-attr]
              Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work
              in progress), August 2015.

   [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.wijnands-mpls-bier-encapsulation]
              Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura,
              "Encapsulation for Bit Index Explicit Replication in MPLS
              Networks", draft-wijnands-mpls-bier-encapsulation-00 (work
              in progress), September 2014.

Psenak, et al.           Expires April 21, 2016                 [Page 6]
Internet-Draft          OSPF Extensions For BIER            October 2015

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <http://www.rfc-editor.org/info/rfc4915>.

Authors' Addresses

   Peter Psenak (editor)
   Cisco
   Apollo Business Center
   Mlynske nivy 43
   Bratislava  821 09
   Slovakia

   Email: ppsenak@cisco.com

   Nagendra Kumar
   Cisco
   7200 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: naikumar@cisco.com

   IJsbrand Wijnands
   Cisco
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com

   Andrew Dolganow
   Alcatel-Lucent
   600 March Rd.
   Ottawa, Ontario  K2K 2E6
   Canada

   Email: andrew.dolganow@alcatel-lucent.com

Psenak, et al.           Expires April 21, 2016                 [Page 7]
Internet-Draft          OSPF Extensions For BIER            October 2015

   Tony Przygienda
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   USA

   Email: antoni.przygienda@ericsson.com

   Jeffrey Zhang
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: zzhang@juniper.net

   Sam Aldrin
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA
   USA

   Email: aldrin.ietf@gmail.com

Psenak, et al.           Expires April 21, 2016                 [Page 8]