The Resilience for BIER
draft-xiong-bier-resilience-01.txt

Abstract

Bit Index Explicit Replication (BIER) is an architecture that specifies a solution for the forwarding of multicast data packets. In some scenarios, the resilience should be provided to guarantee the multicast data is protected by a given backup resource and forwarded successfully to the receivers in BIER-specific network.

This document discusses the resilience use cases, requirements and proposes solutions for BIER, including the protection mechanisms and detection methods.

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 https://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 15, 2019.

Copyright Notice

Copyright (c) 2018 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.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 1.2. Terminology
• 2. Requirements
• 3. BIER Resilience Use Cases
• 3.1. End-to-End 1+1 Protection
• 3.2. End-to-End 1:1 Protection
• 3.3. BIER Link Protection
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informational References
• Authors' Addresses

1. Introduction

[RFC8279] introduces Bit Index Explicit Replication (BIER) architecture and specifies a solution for the forwarding of multicast data packets. The routers which support BIER are known as Bit-Forwarding Router (BFR) and the multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leave at one or more Bit-Forwarding Egress Routers (BFERs).

[I-D.eckert-bier-te-frr] provides some protection mechanisms for traffic engineering of BIER. However, there is no mechanism to protect multicast traffic against BIER-specific network failures. In some scenarios, the resilience should be provided to guarantee the multicast data is protected by a given backup resource and forwarded successfully to the receivers in BIER-specific network.

This document describes the resilience use cases and requirements for BIER-specific network and discusses the protection mechanisms and detection methods.

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

1.2. Terminology

The terminology is defined as [RFC8279].

2. Requirements

The following lists the resilience requirements for BIER-specific multicast domain including the protection mechanisms and detection methods.

(1)

The listed requirements MUST be supported by any transport layer over which the BIER layer can be realized.

(2)

BIER protection type MAY be defined and configured from a centralized controller or management network including BIER end-to-end protection and link/node protection and related information.

(3)

It is required to support the failure detection and notification mechanisms.

(4)

It is required to support the fast protection switching for the BIER packets within the limited time.

3. BIER Resilience Use Cases

The resilience use cases for a BIER-specific network should be considered including end-to-end and link protection scenarios. The protection and related detection mechanisms MAY be provided for BIER resilience against failures such as link or nodes.

3.1. End-to-End 1+1 Protection

The end-to-end protection mechanisms for a BIER-specific network should be considered in some scenarios like shown in Figure 1. It includes end-to-end 1+1 and 1:1 protection use cases. Two disjoint end-to-end paths that are available for 1+1 or 1:1 protection from BFIR to BFERs should be provided, and one of them may be configured to be the protection path for the working path. In this example the working path could be BFIR->BFR1->BFR2->BFR3->BFER1 and BFIR->BFR1->BFR2->BFR3->BFER2; and then the protection path is BFIR->BFR6->BFR5->BFR4->BFER1 and BFIR->BFR6->BFR5->BFR4->BFER2.

 
    
              +----+    +----+     +----+        +-----+
              |BFR1|----|BFR2|-----|BFR3|--------|BFER1|
              +----+    +----+     +----+        +-----+
             /                           \      /
            /                             \    /   
      +----+                               \  /
      |BFIR|                                \/
      +----+                                /\
            \                              /  \
             \                            /    \  
              +----+    +----+      +----+      +-----+
              |BFR6|----|BFR5|------|BFR4|------|BFER2|
              +----+    +----+      +----+      +-----+

         

Figure 1: BIER End-to-End Protection

For 1+1 protection scenario, the multicast traffic MUST be sent across the network through both the working and backup paths. When the link or node failure occurs inf the working path, the BFERs need to switch to receiving the data flow from the protection path.

The failure detection mechanism for end-to-end 1+1 protection scenario MUST be able to monitor and detect multicast failures in working and protection paths. P2MP BFD [I-D.ietf-bfd-multipoint] MAY be used to verify multipoint connectivity between a BFIR and a set of BFERs. [I-D.hu-bier-bfd] describes the use of p2mp BFD in a BIER domain.

End-to-End 1+1 protection provides fast switch but low resource utilization. All BFERs MAY receive two copies from two paths in the no-failure scenario, and the receivers MUST be able to choose one of them and eliminate the duplication.

3.2. End-to-End 1:1 Protection

This section discusses the end-to-end 1:1 protection for BIER. If duplicate transmission is not desirable for some networks, end-to-end 1:1 protection mechanism may be taken into consideration where only one copy is sent to each receiver. The BFIR will send multicast flows onto the working path and switch to the backup path when a failure occurs.

The failure detection mechanism for end-to-end 1:1 protection scenario MUST be able to monitor and detect multicast failures in the receivers (tails) and notify the head node. BIER-specific extensions MAY be proposed based on [I-D.ietf-bfd-multipoint-active-tail]. The P2MP active tail detection method extends the mechanism defined in [I-D.ietf-bfd-multipoint]. It allows tails to notify the head of the failure of the multicast path and can be used in multipoint and multicast networks, e.g., in BIER domain.

If P2MP BFD uses the active tail mode, then when one of the BFERs detects the failure of the working path, it will send a message to the BFIR. The BFIR will notify BFERs of switchover and start forwarding the multicast flows over the protection path.

3.3. BIER Link Protection

Local protection, i.e., link or node protection, MAY be considered for BIER domain as an alternative to end-to-end protection. The nodes which are the BFRs in BIER network and they exchange the information needed for them to forward packets to each other using BIER. The node protection MAY be provided by using mechanisms already existing in the underlay network, for example, described in [I-D.eckert-bier-te-frr].

A BFR MAY send BIER packets to directly connected BIER neighbors through a BIER link without requiring a routing underlay. Link protection SHOULD be considered in BIER domain. The detection of link failure MAY use the Point-to-Point BFD detection defined in [RFC5880]. A set of extension for BIER-specific P2P BFD SHOULD be proposed in further discussion.

As shown in Figure 2, the BIER path from BFIR to BFERs is BFIR->BFR4->BFR3 ->BFR2->BFER1 and BFIR->BFR4->BFR3->BFER2. If the BIER link from BFR4 to BFR3 fails, the failure can be protected by the backup paths over BFR4->BFR1->BFR2 ->BFR3.

 

                     +-----+        +-----+       +--+--+    
                     |BFR1 +--------+BFR2 +-------+BFER1|       
                     +--+--+        +--+--+       +--+--+ 
                        |              |          
                        |              |             
      +--+--+        +--+--+        +--+--+       +--+--+   
      |BFIR +--------+BFR4 +--------+BFR3 +-------+BFER2| 
      +--+--+        +-----+        +-----+       +-----+
          
    

Figure 2: BIER Link Protection

As discussed in [I-D.eckert-bier-te-frr], the BIER link protection MAY use the existing RSVP-TE/P2MP or SR tunnel bypass. When a node detects a failure on a link, it MAY be assumed that the link has failed and the traffic is switched onto the pre-established backup path to get packets to the downstream node.

Also, as discussed in [RFC7490], the Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) Fast Reroute (FRR) approach that achieves guaranteed coverage against link or node failure in the Interior Gateway Protocol (IGP) network MAY be applied in BIER network.

4. Security Considerations

Security aspects of protection in BIER domain may be considered in relation to the data plane, and handling the dedicated OAM packets used to detect, signal a failure, coordinate the state in the BIER protection domain.

5. IANA Considerations

TBD

6. Acknowledgements

TBD

7. References

7.1. Normative References

7.2. Informational References

Authors' Addresses