BIER WG Yongqing. Zhu Internet-Draft Huanan. Chen Intended status: Standards Track China Telecom Expires: March 23, 2018 Quan. Xiong Fangwei. Hu ZTE Corporation September 19, 2017 BIER-TE Forwarding draft-zcxh-bier-te-forwarding-00.txt Abstract Traffic Engineering for Bit Index Explicit Replication (BIER-TE) shares part of architecture, definition and packet format with Bit Index Explicit Replication (BIER) according to the introduction in [I-D.eckert-bier-te-arch]. But BIER-TE supports the traffic engineering by explicit hop-by-hop forwarding and loose hop forwarding of packets. This document proposes a set of extensions to realize the BIER-TE forwarding including the assignment of BitPositions to adjacencies and the configuration of Bit Index Forwarding Table (BIFT). 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 March 23, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Zhu, et al. Expires March 23, 2018 [Page 1] Internet-Draft BIER-TE Forwarding September 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Operation Overview . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Assignment of BitPositions to Adjacencies . . . . . . 5 2.2. The configuration of BIFT . . . . . . . . . . . . . . . . 5 3. BIER-TE Forwarding Example . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Traffic Engineering for Bit Index Explicit Replication (BIER-TE) shares part of architecture, definition and packet format with Bit Index Explicit Replication (BIER) according to the introduction in [I-D.eckert-bier-te-arch]. But BIER-TE supports the traffic engineering by explicit hop-by-hop forwarding and loose hop forwarding of packets. [I-D.ietf-bier-mpls-encapsulation] specifies a BIER encapsulation that BIER header contains a bitstring in which each bit represents one egress router in the domain. But in BIER-TE, every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies which BFRs will transit packets passing though. BFRs recognizes BitStrings or packets for every Sub-Domain-ID(SD), BitStringLength(BSL) and Set Identification(SI) combination. [I-D.eckert-bier-te-arch] discussed the process of the BIER-TE forwarding including Bit Index Forwarding Table (BIFT) and forwarding example. The BIER-TE controller host determines and assigns the BitPositions to the adjacencies which explicit paths can be built through them and then pushes the BitPositions/adjacencies to the BIFT Zhu, et al. Expires March 23, 2018 [Page 2] Internet-Draft BIER-TE Forwarding September 2017 which indexed by SI:BitPosition. The BIFT is configured to the routers known as "Bit-Forwarding Router" (BFR) which should be able to send packets to adjacencies connecting to other BFRs. 1.1. Motivation As defined in [I-D.ietf-bier-architecture], a multicast data packet enters a domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves at one or more "Bit-Forwarding Egress Routers" (BFERs). For a multicast forwarding, the controller host needs to assign lots of BitPositions and use multiple SI and BSL within the same sub-domain. The distinct SD, BSL and SI combinations MUST be mapped to more than one BitStrings and carried in different packets. As discussed in [I-D.eckert-bier-te-arch], the BIER-TE controller host tracks the BFR topology of the BIER-TE domain and determines the BitPositions and related BIFTs.Different with BIER, the BIFT related to the BitPositions which associated with a particular SD, BSL and SI combination need to be built throughout the whole network in BIER-TE. The BFRs need to forward the packets based on the BitString and BIFT with a SD, BSL and SI combination.The BitPositions of these adjacencies passing through BFIR to each BFER must be assigned in the same SD, BSL and SI combination to ensure the multicast flow be forwarded to the BFER within the same packet. The assignment of BitPositions and the configuration of BIFT should be taken to considerations in detail. 1.2. Operation Overview Based on the discussion above, this document proposes a set of extensions to realize the BIER-TE forwarding including the assignment of BitPositions to adjacencies and the configuration of BIFT. The main point is that the assignment of BitPositions and the configuration of the BIFT MUST be accomplished based on the explicit paths of multicast flow and be completed after the BFIR and BFERs are configured. The controller host SHOULD take charge of the management about multicast flow information. The controller host dosen't need to track the topology to determine what adjacencies require BitPositions. The controller host MAY compute the explicit paths from BFIR to each BFER first and then assign the BitPositions including SD,BSL and SI combination to the adjacencies which the paths passing though respectively based on the policy. The assignment results need to meet the requirement that the BitPositions of the adjacencies from BFIR to each BFER could belong to a SD, BSL and SI combination. And then the controller pushes those BitPositions/adjacencies to the BIFT of the BFRs. The Zhu, et al. Expires March 23, 2018 [Page 3] Internet-Draft BIER-TE Forwarding September 2017 configuration of BIFT is not completed in BFR topology but incremental configuration based on the requirement of multicast flows. 1.3. 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]. 2. BIER-TE Forwarding This document proposes a general mechanism to extend the process in [I-D.eckert-bier-te-arch]. The operation for BIER-TE forwarding is as follows. The controller host which representing the control plane of BIER-TE discovers the network topology information. When the multicast flows needs to be forwarded in the BIER-TE network, the controller host tracks the multicast flow overlay to determine which multicast flow needs to be sent by a BFIR to which BFERs. And based on the topology, the controller host needs to calculate the explicit paths from BFIR to every BFER across the BIER-TE domain according to the algorithms which is outside the scope of this document. The BIER-TE controller host assigns the BitPositions including SD, BSL and SI combination to the adjacencies according to the assignment method and policy as discussed on the session 3.1. The BIFT for related BFRs which the explicit paths passing through SHOULD be populated by the controller host and configured once the BitPositions assigned with the detail in session 3.2 . Finally, the BIER-TE controller host calculates the BitStrings according to the explicit paths and its related explicit SD, BSL and SI combination and pushes them into the BFIR as discussed in [I-D.eckert-bier-te-arch]. Once the BIFTs and BitStrings was programmed into the data plane of BFRs by the BIER-TE controller host, they can be used to forward packets according to the rules specified in the BIER-TE forwarding Procedures defined in [I-D.eckert-bier-te-arch]. Zhu, et al. Expires March 23, 2018 [Page 4] Internet-Draft BIER-TE Forwarding September 2017 2.1. The Assignment of BitPositions to Adjacencies The BIER-TE controller host assigns the BitPositions including SD, BSL and SI combination to the adjacencies based on the explicit paths passing though. One or more BitPositions MAY be assigned to an adjacency with the different SD, BSL and SI combination. The assignment need to meet the requirement that the BitPositions of the adjacencies from BFIR to each BFER could belong to a SD, BSL and SI combination. This document proposes a merthord for the assignment of BitPosition to adjacencies and defines two types of the assignment policy of BitPositions as following. If the multicast flow needs to be sent from a BFIR to M BFERs along M explicit paths, the controller host MAY assign BitPositions for all adjacencies of M explicit paths with the K sets of SD, BSL and SI combinations which K M according to the assignment policy. EXCLUSIVE-TYPE: Each multicast flow MAY use one or more SD, BSL and SI combination exclusively. SHARING-TYPE: More than one multicast flows MAY share the same SD, BSL and SI combination. If the adjacencies of a path have been assigned to the same SI except some adjacencies which have not been assigned ever, the controller host SHOULD assign BP for these no- assigned adjacencies the same SI with the others. The premise is the index of the SI is enough for the assignment. OPTIONALY, the policy of assignment MAY be configured by customers based on the requirement outside of the document. 2.2. The configuration of BIFT The BIFT is populated by the BIER-TE control plane and exists in all BFRs as defined in [I-D.eckert-bier-te-arch]. This document proposes an extension to BIFT as the table 1 shown. BIFT-id represents a particular BIFT and corresponds to a particular combination of SD, BSL, and SI. The value of BITF-id MUST be assigned by BIER-TE controller host and unique throughout the BIER-TE domain. The BIFT-id can be used in BIER encapsulation as discussed in [I-D.ietf-bier-mpls-encapsulation]. BIFT-type indicates the type of BIFT including BIER and BIER-TE. Zhu, et al. Expires March 23, 2018 [Page 5] Internet-Draft BIER-TE Forwarding September 2017 Table 1 Extension of BIFT ------------------------------------------------------------------------------------ | Index: | Adjacencies: | | BIFT-id () : BitPosition | or one or more per entry | | BIFT-type: BIER-TE | ==================================================================================== | BIFT-id:1 | forward_connected(interface,neighbor,DNR) | ------------------------------------------------------------------------------------ | BIFT-id:2 | forward_connected(interface,neighbor,DNR) | | | forward_connected(interface,neighbor,DNR) | ------------------------------------------------------------------------------------ | BIFT-id:3 | local_decap([VRF]) | ------------------------------------------------------------------------------------ | BIFT-id:4 | forward_routed([VRF,]l3-neighbor) | ------------------------------------------------------------------------------------ | BIFT-id:5 | | ------------------------------------------------------------------------------------ | BIFT-id:6 | ECMP({adjacency1,...adjacencyN}, seed) | ------------------------------------------------------------------------------------ ... | ID:BitStringLength | ... | ------------------------------------------------------------------------------------ The BIFT in one sub-domain of a BFR is a table indexed by BIFT- id:BitPosition which populated by the controller host and configured once the BitPositions assigned. One or more BitPositions in table MAY correspond to the same adjacency. The configuration of BIFT is not completed before the service deployment but incremental configuration based on the requirement of multicast flows. The difference is that the configuration of BIFT is not to replace the table in BFR but update and add the BIFT-id:BitPosition items into BIFT. When links or nodes fail or recover in the topology or service is deleted by customers, the related items need to be removed from BIFT with little effect on other BIFT items of other flows. 3. BIER-TE Forwarding Example Step by step example of basic BIER-TE forwarding and using the network defined in [I-D.eckert-bier-te-arch]. The extension process for BIER-TE forwarding is shown as follows. Zhu, et al. Expires March 23, 2018 [Page 6] Internet-Draft BIER-TE Forwarding September 2017 [Bier-Te Controller Host] / | \ v v v | a13 a1 | +- BFIR2 --+ | | | a2 a6 | LAN2 | +-- BFR3 --+ | | | | a7 a11 | Src -+ +-- BFER1 --+ | | a3 a8 | | | +-- BFR4 --+ +-- Rcv1 | | | | | | | a14 a4 | +- BFIR1 --+ | | +-- BFR5 --+ a10 a12 | LAN1 | a5 a9 +-- BFER2 --+ | +-- Rcv2 | LAN3 IP |..... BIER-TE network ......| IP Figure 1 Forwarding Example aXX indicate the Adjacencies number assigned by the BIER-TE controller host according to the BIER-TE topology. 1, The BIER-TE controller discovers the network topology information and assigns the Adjacencies number for the adjacencies as the figure shown. 2, The BIER-TE controller tracks the multicast flow overlay to determine what multicast flow needs to be sent by which BFIR to which BFERs. Example is from BFIR2 to BFER1 and BFER2. 3, The BIER-TE controller computes the two optimal paths from BFIR2 to BFER1 and from BFIR2 to BFER2 respectively. The result is shown as follows. a.BFIR2->BFER1:SRC->a13->a2->a7->a11->RCV b.BFIR2->BFER2:SRC->a13->a2->a8->a5->a10->a12->RCV 4, The BIER-TE controller host assigns BP for the path from BFIR2 to BFER1 with the assignment method and the policy type is EXCLUSIVE- Zhu, et al. Expires March 23, 2018 [Page 7] Internet-Draft BIER-TE Forwarding September 2017 TYPE. SD =0, SI=0, BSL=4, BIFT-id = 0, the BIFT-id:BitPosition is as follows: a13->0:1 a2->0:2 a7->0:3 a11->0:4 5, The BIER-TE controller host assigns BP for the path from BFIR2 to BFER2. SD =0, SI=1, BSL=8, BIFT-id = 1, the BIFT-id:BitPosition is as follows: a13->1:1 a2->1:2 a8->1:3 a5->1:4 a10->1:5 a12->1:6 6, Based on the assignment, the BIER-TE controller populates the according BIFTs and forwards it to the BFRs as the following shown. BIFT BFIR2: 0:1: local_decap() 1:1: local_decap() 0:2: forward_connected(BFR3) 1:2: forward_connected(BFR3) BIFT BFR3: 0:3: forward_connected(BFER1) 1:3: forward_connected(BFR4) BIFT BFER1: Zhu, et al. Expires March 23, 2018 [Page 8] Internet-Draft BIER-TE Forwarding September 2017 0:4: local_decap() 1:3: forward_connected(BFR4) BIFT BFIR1: 1:4: forward_connected(BFR5) BIFT BFR4: 0:3: forward_connected(BFER1) 1:4: forward_connected(BFR5) BIFT BFR5: 1:5: forward_connected(BFER2) BIFT BFER2: 1:6: local_decap() 7, The BitString is splited into two sub-BitStrings according to the BIFT-id by the BIER-TE controller.Examples for SI:Bitstring is 0:1111 and 1:00111111. 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. Acknowledgements TBD. 7. Normative References [I-D.eckert-bier-te-arch] Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic Engineering for Bit Index Explicit Replication BIER-TE", draft-eckert-bier-te-arch-05 (work in progress), June 2017. Zhu, et al. Expires March 23, 2018 [Page 9] Internet-Draft BIER-TE Forwarding September 2017 [I-D.ietf-bier-architecture] Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-08 (work in progress), September 2017. [I-D.ietf-bier-mpls-encapsulation] Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks", draft-ietf-bier-mpls-encapsulation-08 (work in progress), September 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Yongqing Zhu China Telecom 109 West Zhongshan Ave Guangzhou, Guangdong 510630 China Phone: +86 20 38639581 Email: zhuyq@gsta.com Huanan Chen China Telecom 109 West Zhongshan Ave Guangzhou, Guangdong 510630 China Phone: +86 20 38639346 Email: chenhuanan@gsta.com Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan, Hubei 430223 China Phone: +86 27 83531060 Email: xiong.quan@zte.com.cn Zhu, et al. Expires March 23, 2018 [Page 10] Internet-Draft BIER-TE Forwarding September 2017 Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Zhu, et al. Expires March 23, 2018 [Page 11]