BIER WG Zheng. Zhang Internet-Draft Bo. Wu Intended status: Standards Track Cui. Wang Expires: September 7, 2016 ZTE Corporation March 6, 2016 Path Autogeneration in BIER draft-zhang-bier-path-autogeneration-01 Abstract [I-D.ietf-bier-architecture] BIER introduces a method for multicast flow forwarding, without storing states in every node along the multicast path. This document introduces a method of establishing multicast path automatically. 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 September 7, 2016. Copyright Notice Copyright (c) 2016 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. Zhang, et al. Expires September 7, 2016 [Page 1] Internet-Draft Path Autogeneration in BIER March 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Node function . . . . . . . . . . . . . . . . . . . . . . 3 2.2. TE function . . . . . . . . . . . . . . . . . . . . . . . 4 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Node procedure . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Sending the path packets . . . . . . . . . . . . . . 5 3.1.2. Withdraw Nodes . . . . . . . . . . . . . . . . . . . 5 3.1.3. BFR and BFER . . . . . . . . . . . . . . . . . . . . 6 3.2. BIER-TE procedure . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Sending the path packets . . . . . . . . . . . . . . 6 3.2.2. Withdraw BIER-TE adjacencies . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [I-D.ietf-bier-architecture] BIER is a technology of multicast flow forwarding. [I-D.ietf-bier-mpls-encapsulation] introduces a way to use mpls in BIER forwarding. This document introduces a method of establishing multicast path automatically. Upstream-assigned label is used in this document. Associate with the label indicated the BFIR, the two labels compose the keywords for multicast flow forwarding. Every node along the multicast path used the two labels to forward multicast flow without label changing. Obviously, the nodes along the path establish the mpls forwarding table, when they receive the packet which include the label combination and the path specification. BFIR sends the first packet with label combination and path specification, every node along the path build the mpls forwarding table, and forward the packet to next node according to the path specification. If there is already one mpls forwarding item which has the same label combination, the node combines the next-hop in the packet to the existed forwarding item. 2. Packet Formats This document introduces a new TLV that is carried by the BIER packet, and this TLV is composed by the nodes in the multicast path. There is a flag in the BIER header indicates that a path TLV is be carried. One of the reserved flag may be used to signal this. Zhang, et al. Expires September 7, 2016 [Page 2] Internet-Draft Path Autogeneration in BIER March 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1| Ver | Len | Entropy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM| Reserved 1| Proto | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 BIER Header 2.1. Node function The path list is composed by nodes along the multicast path. The multicast path is decided by BFIR in advance through PCE or other calculations or configurations. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFIR label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream-assigned label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Id | Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Id | BFER-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Path Specification o Type TBD, indicate that there is a path TLV. o Length The length of the TLV. o BFIR label The label of BFIR. o Upstream-assigned label The label that is assigned by BFIR for the specific multicast flow. Zhang, et al. Expires September 7, 2016 [Page 3] Internet-Draft Path Autogeneration in BIER March 2016 o Id The node BFR-id or the link id along the multicast path. They are carried by the packets in order. o BFER-id The BFR-id of BFER. Like the ingress replication, BFIR repeats BIER packets several times according to every BFER of the multicast flow. And then BFIR sends the BIER packets with the two labels. The withdraw packet is the same format with the path packet. But the type should be another type, and the last node that is carried by the withdraw packet is the canceled node. 2.2. TE function Also, the method of path auto-generation can be used in BIER-TE forwarding. The format of TLV that is carried by BIER header is same as the previous section. And the difference is that the BitString is BIER- TE forwarding BitString. The packet is forwarding by the BIER-TE Forwarding Table. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFIR label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream-assigned label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 TE path specification o Type TBD, indicate that there is a TE path TLV. o Length The length of the TLV. o BFIR label The label of BFIR. o Upstream-assigned label The label that is assigned by BFIR for the specific multicast flow. Zhang, et al. Expires September 7, 2016 [Page 4] Internet-Draft Path Autogeneration in BIER March 2016 o BitString The adjacency of TE path, and it is the same as the BitString in the BIER header. When the multicast flow travels the BIER-TE path by BIER-TE forwarding, the two level labels also can be established in every BFR. If some adjacency should be withdrawn from the path, the type will be another type of TE path withdraw TLV. 3. Procedures 3.1. Node procedure 3.1.1. Sending the path packets When BFIR gains the BFER information of a specific multicast flow, BFIR encapsulates the receiving flow with the path list, and sends to every BFER individually.Particularly, the encapsulated packet that is sent by BFIR includes the label combination. B-------- C ------ D -------- | | | | A ------- F ------ G ------ H | | | | --------- K ------ L -------M Figure4 An Example For example, in figure 3, A is BFIR for a specific multicast flow. And D, H, M is BFER. According the PCE calculation, the multicast flow should be sent along these paths: A-F-G-D/H, A-K-L-M. So A encapsulates the flow with the two label combination and makes three copies, and then sends to D/H/M separately. In node A, there is one mpls label forwarding item which the ingress label is the two labels combination, and the next-hops are F and K with the same two labels out. A encapsulates the formal multicast flow with the two labels and forwards to next hops. For the stability consideration, BFIR sends the path packets every once in a while. The interval may be 30 minutes. And when new BFER joined, BFIR sends the path packets to the new BFER immediately. 3.1.2. Withdraw Nodes According to the PCE calculation, some existed nodes in the path may be canceled. BFIR sends the withdraw path packet which the last node is the canceled node. For example in figure 1, if the bandwidth in the network is changed, the multicast flow should be forwarded along these ways: A-B-C-D-H, Zhang, et al. Expires September 7, 2016 [Page 5] Internet-Draft Path Autogeneration in BIER March 2016 A-K-L-M. The specific multicast flow will not pass by the node F and G anymore. Except A sending a new path packet along the path A-B-C-D-H, A also sends two withdraw path packets to node F and G. 3.1.3. BFR and BFER When BFR and BFER receive the path packets, they build an item in the mpls forwarding table according to the label combination that is carried by the packets. If there is an item already in the forwarding table, the nodes should add the next-hop which is the next node in the path packet. When BFR and BFER receive the withdraw path packets which indicate that they should be canceled, the BFR and BFER delete the mpls forwarding item which line with the label combination. If the middle node finds that the next node that along the path is the canceled node, the middle node deletes the next-hop in the mpls forwarding item. If there is no next-hop in the mpls forwarding item, the node deletes the mpls item in the mpls forwarding table. 3.2. BIER-TE procedure 3.2.1. Sending the path packets When BFIR gains the BFER information of a specific multicast flow, and BFIR knows all the adjacencies that the flow should travel, BFIR encapsulates the receiving flow with the BIER-TE adjacencies, and sends to BIER domain. If there are several SI should be encapsulated, the flow will be encapsulated by different BitString several times. B-p1----p2-- C -p3----p4-- D -p5----------- | | | | p6 p7 p8 p9 | | | | A-p10---p11- F -p12---p13- G -p14----p15- H | | | | p16 p17 p18 p19 | | | | --------p20- K -p21---p22- L -p23----p24--M Figure 5 BIER-TE example For example, in figure 4, A is BFIR for a specific multicast flow. And D, H, M is BFER. According the PCE calculation, the multicast flow should be sent along these paths: A-F-G-D/H, A-K-L-M. The BitPositions in BitString are p8, p10, p12, p14, p16, p21, p23. A encapsulates the flow with the two label combination and the BIER-TE BitString. Zhang, et al. Expires September 7, 2016 [Page 6] Internet-Draft Path Autogeneration in BIER March 2016 Like the node function, when the packet goes through the path of BIER-TE, every BFR establishes the label forwarding item. 3.2.2. Withdraw BIER-TE adjacencies If some adjacencies in the existed path should be withdraw, the ingress node send the packet with withdraw type of TLV. The BitString in BIER header is previous TE path adjacency, and the BitString in the TLV is composed of withdraw adjacencies. When BFR receives the packet, BFR will withdraw the associated adjacencies itself. 4. Security Considerations There should be some common security methods to guarantee the validation of path packets. 5. IANA considerations IANA is requested to allocate four types in TLVs of BIER path packets. Two for node function and two for TE function. 6. Normative References [I-D.eckert-bier-te-arch] Eckert, T. and G. Cauchie, "Traffic Enginering for Bit Index Explicit Replication BIER-TE", draft-eckert-bier-te- arch-02 (work in progress), October 2015. [I-D.ietf-bier-architecture] Wijnands, I., Rosen, E., Dolganow, A., P, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-03 (work in progress), January 2016. [I-D.ietf-bier-mpls-encapsulation] Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and S. Aldrin, "Encapsulation for Bit Index Explicit Replication in MPLS Networks", draft-ietf-bier-mpls- encapsulation-03 (work in progress), February 2016. Authors' Addresses Zhang, et al. Expires September 7, 2016 [Page 7] Internet-Draft Path Autogeneration in BIER March 2016 Zheng(Sandy) Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: zhang.zheng@zte.com.cn Bo Wu ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: wu.bo@zte.com.cn Cui(Linda) Wang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: wang.cui1@zte.com.cn Zhang, et al. Expires September 7, 2016 [Page 8]