PIM WG Zheng. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track March 27, 2017 Expires: September 28, 2017 Multicast BABEL Extension draft-zhang-pim-babel-ext-02 Abstract This document describes a method that uses Babel protocol extension to deliver multicast information. Babel protocol extension is used to signal receiver multicast interest. 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 28, 2017. 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 (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 Expires September 28, 2017 [Page 1] Internet-Draft Multicast BABEL Extension March 2017 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Babel extensions for multicast information . . . . . . . . . 3 4. Protocol treatment . . . . . . . . . . . . . . . . . . . . . 4 4.1. LHR treatment . . . . . . . . . . . . . . . . . . . . . . 4 4.2. FHR treatment . . . . . . . . . . . . . . . . . . . . . . 4 4.2.1. Confliction treatment . . . . . . . . . . . . . . . . 4 4.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Consideration . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Terminology FHR: First Hop Router, directly connected to the source. LHR: Last Hop Router, directly connected to the receiver. 2. Introduction As described in [I-D.ietf-babel-applicability], Babel is a loop- avoiding distance-vector routing protocol that aims to be robust in a variety of environments. And it has seen a number of successful deployments in hybrid network; large scale overlay networks and small unchanged networks. BIER introduces a novel architecture for multicast packet forwarding. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. When BIER is deployed in a network, a protocol such as MLD is used to deliver the multicast overlay information. The multicast information includes multicast source address and group address, and other information that may be used to indicate the multicast flow. It is the commonly used method in large network that is well-managed. But when BIER is used in middle or small network that is not well- managed, such as some data centers and home network, the overlay protocol will cause the complication of network management. Suppose that there is a middle size network that uses Babel protocol to connect every router, and there are dozens of routers in it. The users in the network have the IPTV and other live broadcast requirement. It is obviously that it will be more efficient that use Zhang Expires September 28, 2017 [Page 2] Internet-Draft Multicast BABEL Extension March 2017 multicast technology in the network. BIER is a good choice to deploy multicast technology in the network. [I-D.zhang-bier-babel-extensions] defines the method to establish the BIER forwarding plane. In case MLD protocol is used to deliver the program multicast information such as group address and source address, the uses device must support Babel protocol and MLD protocol at the same time. It is very suitable that use MLD protocol in large and well-managed network. But in middle or small network, the management of MLD protocol may cause the network to be more complicated. In order to simplify the management in the middle or small network, it may be better that use one protocol to solve the delivery of BIER node information and multicast information. This document describes a method to use Babel protocol extension to convey the multicast information. 3. Babel extensions for multicast information In order to flood the multicast information, the Babel prefix that is associated with multicast information extensions MUST not be aggregated, and the Babel prefix and its multicast information sub- TLV MUST be delivered transitive. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type | Flag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-sub-type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Multicast information extension format o Sub-type: The sub-type of Babel multicast information sub-TLV. The value is TBD. o Flag: Indicates that the sub-TLV is from a FHR. The value is TBD. o Length: The total length of the sub-TLV. Zhang Expires September 28, 2017 [Page 3] Internet-Draft Multicast BABEL Extension March 2017 o Sub-sub-type: The sub-sub-TLV Indicates the IPv4/IPv6 multicast information. The value is TBD. o Length: The length of group and source address. o Group address: The group address. When the type is IPv4, the group address is 4 octets. When the type is IPv6, the group address is 16 octets. o Source address: The source address. When the type is IPv4, the source address is 4 octets. When the type is IPv6, the source address is 16 octets. Because more than one source address may be associated with one group address, more than one source address may appear. And receiver may be interested in receiving all sources for a group, like IGMPv2/ASM. Hence 0 sources are allowed. 4. Protocol treatment 4.1. LHR treatment When a router announces its own prefix such as a loopback interface address, no matter the prefix is IPv4 or IPv6, in case the router is also a LHR, the router should announce the multicast information sub- TLV to the other routers. And the other routers MUST convey the sub- TLV to more routers in the network. And at last all the routers will receive the multicast information and know that where the LHRs are. 4.2. FHR treatment In case a router is a FHR, when the router announces its own prefix such as a loopback interface address, no matter the prefix is IPv4 or IPv6, the router send update message with multicast information sub- TLV. Other routers MUST convey the sub-TLV associate with the prefix to more routers in the network, and then every router knows that where the FHR is. 4.2.1. Confliction treatment In case one or more FHRs announce some same multicast information, the function defined in [I-D.wijnands-bier-mld-lan-election] should be used to judge the unique designed FHR to forward the flow. 4.3. Process When the router who is FHR receives the multicast information that is sent by the LHRs, the designed FHR will encapsulate all the LHRs in the header of multicast flows. Then the routers in the network will Zhang Expires September 28, 2017 [Page 4] Internet-Draft Multicast BABEL Extension March 2017 use the BIER forwarding plane to forward the multicast flows to all the LHRs according to the packet header. And the IPv4 or IPv6 multicast flows will be unified to use the same transport encapsulation. LHR1 LHR2 LHR3 \ / \ / \ / \ / R11 R12 | | | | R21 R22 / \ / \ FHR31 FHR32 Figure 2: Example For example, there are some users who want to receive multicast flows, such as LHR1, LHR2 and LHR3. In case the users support the transport encapsulation function, the LHR may be the users self. In case the users can not support the transport encapsulation function, the LHR may be the closest router that is connects the users. Suppose that LHR1 want to receive a multicast flow (*, G1), LHR2 and LHR3 want to receive a multicast flow (S1, G2), LHR3 also want to receive a multicast (S3, G1). LHRs will send the update messages with multicast information sub-TLV to other routers. Suppose that FHR31 is in charge of (*, G2), and FHR31 and FHR32 all in charge of (*, G1), FHRs will send Babel extensions associate with the multicast information sub-TLV with the Sender flag set. And FHR31 and FHR32 will judge that who is in charge of (*, G1). Suppose that the FHR32 is the designed FHR for the (*, G1). Then FHR31 is in charge of (*, G2), FHR32 is in charge of (*, G1), so FHR31 will encapsulate the multicast flow (*, G2) with the header that includes LHR2 and LHR3, FHR32 will encapsulate the multicast flow (*, G1) with the header that includes LHR1 and LHR3. Then the multicast flows will be forwarded into the network and reach the LHRs. LHR decapsulate the packet and send it to users/receivers. 5. Security Consideration The security function that is defined in [I-D.ietf-babel-rfc6126bis] and [RFC7298] is used directly. Zhang Expires September 28, 2017 [Page 5] Internet-Draft Multicast BABEL Extension March 2017 6. IANA Considerations A new Babel multicast information sub-TLV type need to be defined. Two sub-sub-TLV IPv4/IPv6 types need to be defined for the multicast information sub-TLV. 7. Acknowledgements The authors would like to thank Juliusz Chroboczek, Stig Venaas, Pierre Pfister for their valuable contributions. 8. Normative References [I-D.ietf-babel-applicability] Chroboczek, J., "Applicability of the Babel routing protocol", draft-ietf-babel-applicability-00 (work in progress), July 2016. [I-D.ietf-babel-rfc6126bis] Chroboczek, J., "The Babel Routing Protocol", draft-ietf- babel-rfc6126bis-00 (work in progress), August 2016. [I-D.wijnands-bier-mld-lan-election] Wijnands, I., Pfister, P., and Z. Zhang, "Generic Multicast Router Election on LAN's", draft-wijnands-bier- mld-lan-election-01 (work in progress), July 2016. [I-D.zhang-bier-babel-extensions] Zhang, Z. and T. Przygienda, "BIER in BABEL", draft-zhang- bier-babel-extensions-00 (work in progress), October 2016. [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, . [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, . Author's Address Zhang Expires September 28, 2017 [Page 6] Internet-Draft Multicast BABEL Extension March 2017 Zheng(Sandy) Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: zhang.zheng@zte.com.cn Zhang Expires September 28, 2017 [Page 7]