idnits 2.17.1 draft-zhang-pim-babel-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...ast information extensions MUST not be...' RFC 2119 keyword, line 120: '... TLV MUST be delivered transitive....' RFC 2119 keyword, line 167: '...the other routers MUST convey the sub-...' RFC 2119 keyword, line 176: '.... Other routers MUST convey the sub-T...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (March 27, 2017) is 2581 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6126' is defined on line 269, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-babel-applicability-00 ** Downref: Normative reference to an Informational draft: draft-ietf-babel-applicability (ref. 'I-D.ietf-babel-applicability') == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-00 == Outdated reference: A later version (-02) exists of draft-wijnands-bier-mld-lan-election-01 ** Downref: Normative reference to an Informational draft: draft-wijnands-bier-mld-lan-election (ref. 'I-D.wijnands-bier-mld-lan-election') == Outdated reference: A later version (-10) exists of draft-zhang-bier-babel-extensions-00 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 7298 (Obsoleted by RFC 8967) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Zheng. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track March 27, 2017 5 Expires: September 28, 2017 7 Multicast BABEL Extension 8 draft-zhang-pim-babel-ext-02 10 Abstract 12 This document describes a method that uses Babel protocol extension 13 to deliver multicast information. Babel protocol extension is used 14 to signal receiver multicast interest. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 28, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Babel extensions for multicast information . . . . . . . . . 3 53 4. Protocol treatment . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. LHR treatment . . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. FHR treatment . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2.1. Confliction treatment . . . . . . . . . . . . . . . . 4 57 4.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Consideration . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Terminology 66 FHR: First Hop Router, directly connected to the source. 68 LHR: Last Hop Router, directly connected to the receiver. 70 2. Introduction 72 As described in [I-D.ietf-babel-applicability], Babel is a loop- 73 avoiding distance-vector routing protocol that aims to be robust in a 74 variety of environments. And it has seen a number of successful 75 deployments in hybrid network; large scale overlay networks and small 76 unchanged networks. 78 BIER introduces a novel architecture for multicast packet forwarding. 79 It does not require a signaling protocol to explicitly build 80 multicast distribution trees, nor does it require intermediate nodes 81 to maintain any per-flow state. 83 When BIER is deployed in a network, a protocol such as MLD is used to 84 deliver the multicast overlay information. The multicast information 85 includes multicast source address and group address, and other 86 information that may be used to indicate the multicast flow. It is 87 the commonly used method in large network that is well-managed. But 88 when BIER is used in middle or small network that is not well- 89 managed, such as some data centers and home network, the overlay 90 protocol will cause the complication of network management. 92 Suppose that there is a middle size network that uses Babel protocol 93 to connect every router, and there are dozens of routers in it. The 94 users in the network have the IPTV and other live broadcast 95 requirement. It is obviously that it will be more efficient that use 96 multicast technology in the network. BIER is a good choice to deploy 97 multicast technology in the network. 98 [I-D.zhang-bier-babel-extensions] defines the method to establish the 99 BIER forwarding plane. 101 In case MLD protocol is used to deliver the program multicast 102 information such as group address and source address, the uses device 103 must support Babel protocol and MLD protocol at the same time. 105 It is very suitable that use MLD protocol in large and well-managed 106 network. But in middle or small network, the management of MLD 107 protocol may cause the network to be more complicated. 109 In order to simplify the management in the middle or small network, 110 it may be better that use one protocol to solve the delivery of BIER 111 node information and multicast information. This document describes 112 a method to use Babel protocol extension to convey the multicast 113 information. 115 3. Babel extensions for multicast information 117 In order to flood the multicast information, the Babel prefix that is 118 associated with multicast information extensions MUST not be 119 aggregated, and the Babel prefix and its multicast information sub- 120 TLV MUST be delivered transitive. 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Sub-type | Flag | Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Sub-sub-type | Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Group Address (Encoded-Group format) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Src Address (Encoded-Unicast format) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | ...... | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 1 Multicast information extension format 136 o Sub-type: The sub-type of Babel multicast information sub-TLV. 137 The value is TBD. 139 o Flag: Indicates that the sub-TLV is from a FHR. The value is TBD. 141 o Length: The total length of the sub-TLV. 143 o Sub-sub-type: The sub-sub-TLV Indicates the IPv4/IPv6 multicast 144 information. The value is TBD. 146 o Length: The length of group and source address. 148 o Group address: The group address. When the type is IPv4, the 149 group address is 4 octets. When the type is IPv6, the group 150 address is 16 octets. 152 o Source address: The source address. When the type is IPv4, the 153 source address is 4 octets. When the type is IPv6, the source 154 address is 16 octets. Because more than one source address may be 155 associated with one group address, more than one source address 156 may appear. And receiver may be interested in receiving all 157 sources for a group, like IGMPv2/ASM. Hence 0 sources are 158 allowed. 160 4. Protocol treatment 162 4.1. LHR treatment 164 When a router announces its own prefix such as a loopback interface 165 address, no matter the prefix is IPv4 or IPv6, in case the router is 166 also a LHR, the router should announce the multicast information sub- 167 TLV to the other routers. And the other routers MUST convey the sub- 168 TLV to more routers in the network. And at last all the routers will 169 receive the multicast information and know that where the LHRs are. 171 4.2. FHR treatment 173 In case a router is a FHR, when the router announces its own prefix 174 such as a loopback interface address, no matter the prefix is IPv4 or 175 IPv6, the router send update message with multicast information sub- 176 TLV. Other routers MUST convey the sub-TLV associate with the prefix 177 to more routers in the network, and then every router knows that 178 where the FHR is. 180 4.2.1. Confliction treatment 182 In case one or more FHRs announce some same multicast information, 183 the function defined in [I-D.wijnands-bier-mld-lan-election] should 184 be used to judge the unique designed FHR to forward the flow. 186 4.3. Process 188 When the router who is FHR receives the multicast information that is 189 sent by the LHRs, the designed FHR will encapsulate all the LHRs in 190 the header of multicast flows. Then the routers in the network will 191 use the BIER forwarding plane to forward the multicast flows to all 192 the LHRs according to the packet header. And the IPv4 or IPv6 193 multicast flows will be unified to use the same transport 194 encapsulation. 196 LHR1 LHR2 LHR3 197 \ / \ / 198 \ / \ / 199 R11 R12 200 | | 201 | | 202 R21 R22 203 / \ 204 / \ 205 FHR31 FHR32 206 Figure 2: Example 208 For example, there are some users who want to receive multicast 209 flows, such as LHR1, LHR2 and LHR3. In case the users support the 210 transport encapsulation function, the LHR may be the users self. In 211 case the users can not support the transport encapsulation function, 212 the LHR may be the closest router that is connects the users. 214 Suppose that LHR1 want to receive a multicast flow (*, G1), LHR2 and 215 LHR3 want to receive a multicast flow (S1, G2), LHR3 also want to 216 receive a multicast (S3, G1). LHRs will send the update messages 217 with multicast information sub-TLV to other routers. 219 Suppose that FHR31 is in charge of (*, G2), and FHR31 and FHR32 all 220 in charge of (*, G1), FHRs will send Babel extensions associate with 221 the multicast information sub-TLV with the Sender flag set. And 222 FHR31 and FHR32 will judge that who is in charge of (*, G1). Suppose 223 that the FHR32 is the designed FHR for the (*, G1). 225 Then FHR31 is in charge of (*, G2), FHR32 is in charge of (*, G1), so 226 FHR31 will encapsulate the multicast flow (*, G2) with the header 227 that includes LHR2 and LHR3, FHR32 will encapsulate the multicast 228 flow (*, G1) with the header that includes LHR1 and LHR3. Then the 229 multicast flows will be forwarded into the network and reach the 230 LHRs. LHR decapsulate the packet and send it to users/receivers. 232 5. Security Consideration 234 The security function that is defined in [I-D.ietf-babel-rfc6126bis] 235 and [RFC7298] is used directly. 237 6. IANA Considerations 239 A new Babel multicast information sub-TLV type need to be defined. 241 Two sub-sub-TLV IPv4/IPv6 types need to be defined for the multicast 242 information sub-TLV. 244 7. Acknowledgements 246 The authors would like to thank Juliusz Chroboczek, Stig Venaas, 247 Pierre Pfister for their valuable contributions. 249 8. Normative References 251 [I-D.ietf-babel-applicability] 252 Chroboczek, J., "Applicability of the Babel routing 253 protocol", draft-ietf-babel-applicability-00 (work in 254 progress), July 2016. 256 [I-D.ietf-babel-rfc6126bis] 257 Chroboczek, J., "The Babel Routing Protocol", draft-ietf- 258 babel-rfc6126bis-00 (work in progress), August 2016. 260 [I-D.wijnands-bier-mld-lan-election] 261 Wijnands, I., Pfister, P., and Z. Zhang, "Generic 262 Multicast Router Election on LAN's", draft-wijnands-bier- 263 mld-lan-election-01 (work in progress), July 2016. 265 [I-D.zhang-bier-babel-extensions] 266 Zhang, Z. and T. Przygienda, "BIER in BABEL", draft-zhang- 267 bier-babel-extensions-00 (work in progress), October 2016. 269 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 270 DOI 10.17487/RFC6126, April 2011, 271 . 273 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 274 (HMAC) Cryptographic Authentication", RFC 7298, 275 DOI 10.17487/RFC7298, July 2014, 276 . 278 Author's Address 279 Zheng(Sandy) Zhang 280 ZTE Corporation 281 No. 50 Software Ave, Yuhuatai Distinct 282 Nanjing 283 China 285 Email: zhang.zheng@zte.com.cn