idnits 2.17.1 draft-eckert-bier-cgm2-rbs-01.txt: -(943): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(944): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(945): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(947): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(949): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(951): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(953): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(955): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(957): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(963): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(965): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(969): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(971): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(979): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(980): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(981): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(982): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(985): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(986): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(987): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(993): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(995): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(998): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1000): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1003): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1005): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1012): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1013): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1014): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1015): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1016): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1017): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1018): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1019): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1020): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1021): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1022): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1023): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1024): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 69 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8296]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 314: '...BS address. Therefore, N MUST support...' RFC 2119 keyword, line 321: '... BFR MUST support a value of N large...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 February 2022) is 801 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 770 == Missing Reference: 'Index' is mentioned on line 749, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-12 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER T. Eckert 3 Internet-Draft Futurewei Technologies USA 4 Intended status: Experimental B. Xu 5 Expires: 13 August 2022 Huawei Technologies (2012Lab) 6 9 February 2022 8 Carrier Grade Minimalist Multicast (CGM2) using Bit Index Explicit 9 Replication (BIER) with Recursive BitString Structure (RBS) Addresses 10 draft-eckert-bier-cgm2-rbs-01 12 Abstract 14 This memo introduces the architecture of a multicast architecture 15 derived from BIER-TE, which this memo calls Carrier Grade Minimalist 16 Multicast (CGM2). It reduces limitations and complexities of BIER-TE 17 by replacing the representation of the in-packet-header delivery tree 18 of packets through a "flat" BitString of adjacencies with a 19 hierarchical structure of BFR-local BitStrings called the Recursive 20 BitString Structure (RBS) Address. 22 Benefits of CGM2 with RBS addresses include smaller/fewer BIFT in 23 BFR, less complexity for the network architect and in the CGM2 24 controller (compared to a BIER-TE controller) and fewer packet copies 25 to reach a larger set of BFER. 27 The additional cost of forwarding with RBS addresses is a slightly 28 more complex processing of the RBS address in BFR compared to a flat 29 BitString and the novel per-hop rewrite of the RBS address as opposed 30 to bit-reset rewrite in BIER/BIER-TE. 32 CGM2 can support the traditional deployment model of BIER/BIER-TE 33 with the BIER/BIER-TE domain terminating at service provider PE 34 routers as BFIR/BFER, but it is also the intention of this document 35 to expand CGM2 domains all the way into hosts, and therefore 36 eliminating the need for an IP Multicast flow overlay, further 37 reducing the complexity of Multicast services using CGM2. Note that 38 this is not fully detailed in this version of the document. 40 This document does not specify an encapsulation for CGM2/RBS 41 addresses. It could use existing encapsulations such as [RFC8296], 42 but also other encapsulations such as IPv6 extension headers. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 13 August 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 79 1.2. Encapsulation Considerations . . . . . . . . . . . . . . 4 80 2. CGM2/RBS Architecture . . . . . . . . . . . . . . . . . . . . 5 81 3. CGM2/RBS forwarding plane . . . . . . . . . . . . . . . . . . 6 82 3.1. RBS BIFT . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.2. Reference encoding of RBS addresses . . . . . . . . . . . 8 84 3.3. RBS Address . . . . . . . . . . . . . . . . . . . . . . . 8 85 3.3.1. RecursiveUnit . . . . . . . . . . . . . . . . . . . . 8 86 3.3.2. AddressingField . . . . . . . . . . . . . . . . . . . 9 87 4. BIER-RBS Example . . . . . . . . . . . . . . . . . . . . . . 9 88 4.1. BFR B . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 4.2. BFR R . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.3. BFR S . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4.4. BFR C . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 4.5. BFR D . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.6. BFR E . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 5. RBS forwarding Pseudocode . . . . . . . . . . . . . . . . . . 16 95 6. Operational and design considerations (informational) . . . . 18 96 6.1. Comparison with BIER-TE / BIER . . . . . . . . . . . . . 18 97 6.1.1. Eliminating the need for large BIFT . . . . . . . . . 18 98 6.1.2. Reducing number of duplicate packet copies across 99 BFR . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 6.1.3. BIER-TE forwarding plane complexities . . . . . . . . 20 101 6.1.4. BIER-TE controller complexities . . . . . . . . . . . 20 102 6.1.5. BIER-TE specification complexities . . . . . . . . . 20 103 6.1.6. Forwarding plane complexity . . . . . . . . . . . . . 21 104 6.2. CGM2 / RBS controller considerations . . . . . . . . . . 21 105 6.3. Analysis of performance gain with CGM2 . . . . . . . . . 21 106 6.3.1. Reference topology . . . . . . . . . . . . . . . . . 21 107 6.3.2. Comparison BIER and CGM2/RBS . . . . . . . . . . . . 23 108 6.4. Example use case scenarios . . . . . . . . . . . . . . . 24 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 110 8. Security considerations . . . . . . . . . . . . . . . . . . . 24 111 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 114 10.2. Informative References . . . . . . . . . . . . . . . . . 25 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 117 1. Overview 119 1.1. Introduction 121 Carrier Grade Minimalist Multicast (CGM2) is an architecture derived 122 from the BIER-TE architecture [I-D.ietf-bier-te-arch] with the 123 following changes/improvements. 125 CGM2 forwarding is based on the principles of BIER-TE forwarding: It 126 is based on an explicit, in-packet, "source routed" tree indicated 127 through bits for each adjacency that the packet has to traverse. 128 Like in BIER-TE, adjacencies can be L2 to a subnet local neighbor in 129 support of "native" deployment of CGM2 and/or L3, so-called "routed" 130 adjacencies to support incremental or partial deployment of CGM2 as 131 needed. 133 The address used to replicate packets in the network is not a flat 134 network wide BitString as in BIER-TE, but a hierarchical structure of 135 BitStrings called a Recursive BitString Structure (RBS) Address. The 136 significance of the BitPositions (BP) in each BitString is only local 137 to the BIFT of the router/BFR that is processing this specific 138 BitString. 140 RBS addressing allows for a more compact representation of a large 141 set of adjacencies especially in the common case of sparse set of 142 receivers in large Service Provider Networks (SP). 144 CGM2 thereby eliminates the challenges in BIER [RFC8279] and BIER-TE 145 having to send multiple copies of the same packet in large SP 146 networks and the complexities especially for BIER-TE (but also BIER) 147 to engineer multiple set identifier (SI) and/or sub-domains (SD) 148 BIER-TE topologies for limited size BitStrings (e.g.: 265) to cover 149 large network topologies. 151 Like BIER-TE, CGM2 is intended to leverage a Controller to minimize 152 the control plane complexity in the network to only a simple unicast 153 routing underlay required only for routed adjacencies. 155 The controller centric architecture provides most easily any type of 156 required traffic optimization for its multicast traffic due to their 157 need to perform often NP-complete calculations across the whole 158 topology: reservation of bandwidth to support CIR/PIR traffic buffer/ 159 latency to support Deterministic Network (DetNet) traffic, cost 160 optimized Steiner trees, failure point disjoint trees for higher 161 resilience including DetNet deterministic services. 163 CGM2 can be deployed as BIER/BIER-TE are specified today, by 164 encapsulating IP Multicast traffic at Provider Edge (PE) routers, but 165 it is also considered to be highly desirable to extend CGM2 all the 166 way into Multicast Sender/Receivers to eliminate the overhead of an 167 Overlay Control plane for that (legacy) IP Multicast layer and the 168 need to deal with yet another IP multicast group addressing space. 169 In this deployment option Controller signaling extends directly (or 170 indirectly via BFIR) into senders. 172 1.2. Encapsulation Considerations 174 This document does not define a specific BIER-RBS encapsulation nor 175 does it preclude that multiple different encapsulations may be 176 beneficial to better support different use-cases or operator/user 177 technology preferences. Instead, it discusses considerations for 178 specific choices. 180 BIER-RBS can easily re-use [RFC8296] encapsulation. The RBS address 181 is inserted into the [RFC8296] BitString field. The BFR forwarding 182 plane needs to be configured (from Controller or control plane) that 183 the BIFT-id(s) used with RBS addresses are mapped to BIFT and 184 forwarding rules with RBS semantic. 186 SI/SD fields of [RFC8296] may be used as in BIER-TE, but given that 187 CGM2 is designed (as described in the Overview section) to simplify 188 multicast services, a likely and desirable configuration would be to 189 only use a single BIFT in each BFR for RBS addresses, and mapping 190 these to a single SD and SI 0. 192 IP Multicast [RFC1112] was defined as an extension of IP [RFC791], 193 reusing the same network header, and IPv6 multicast inherits the same 194 approach. In comparison, [RFC8296] defines BIER encapsulation as a 195 completely separate (from IP) layer 3 protocol, and duplicates both 196 IP and MPLS header elements into the [RFC8296] header. This not only 197 results in always unused, duplicate header parameters (such as TC vs. 198 DSCP), but it also foregoes the option to use any non-considered IPv6 199 extension headers with BIER and would require the introduction of a 200 whole new BIER specific socket API into host operating systems if it 201 was to be supported natively in hosts. 203 Therefore an encapsulation of RBS addresses using an IP and/or IPv6 204 extension header may be more desirable in otherwise IP and/or IPv6 205 only deployments, for example when CGM2 is extended into hosts, 206 because it would allow to support CGM2 via existing IP/IPv6 socket 207 APIs as long as they support extension headers, which the most 208 important host stacks do today. 210 2. CGM2/RBS Architecture 212 This section describes the basic CGM2 architecture via Figure 1 213 through its key differences over the BIER-TE architecture. 215 Optional 216 |<-IGMP/PIM-> multicast flow <-PIM/IGMP->| 217 overlay 219 CGM2 [CGM2 Controller] 220 control plane . ^ ^ ^ 221 . / | \ BIFT configuration 222 .......... | | | per-flow RBS setup 223 . | | | 224 . v v v 225 Src (-> ... ) -> BFIR-----BFR-----BFER -> (... ->) Rcvr 227 |<----------------->| 228 CGM2 with RBS-address forwarding plane 230 |<.............. <- CGM domain ---> ...............| 232 |<--------------------->| 233 Routing underlay (optional) 235 Figure 1: CGM2/RBS Architecture 237 In the "traditional" option, when deployed with a domain spanning 238 from BFIR to BFER, the CGM2 architecture is very much like the BIER- 239 TE architecture, in which the BIER-TE forwarding rules for 240 (BitString,SI,SD) addresses are replaced by the RBS address 241 forwarding rules. 243 The CGM2 Controller replaces the BIER-TE controller, populating 244 during network configuration the BIFT, which are very much like BIER- 245 TE BIFT, except that they do not cover a network-wide BP address 246 space, but instead each BFR BIFT only needs as many BP in its BIFT as 247 it has link-local adjacencies, and in partial deployments also 248 additional L3 adjacencies to tunnel across non-CGM capable routers. 250 Per-flow operations in this "traditional" option is very much as in 251 BIER/BIER-TE, with the CGM2 controller determining the RBS address 252 (instead of the BIER-TE (BitString,SI,SD)) to be imposed as part of 253 the RBS address header (compared to the BIER encapsulation [RFC8296]) 254 on the BFIR. 256 To eliminate the need for an IP Multicast flow overlays, a CGM2 257 domain may extend all the way into Sender/Receiver hosts. This is 258 called "end-to-end" deployment model. In that case, the sender host 259 and CGM2 controller collaborate to determine the desired receivers 260 for a packet as well as desired path policy/requirements, the 261 controller indicates to the sender of the packet the necessary RBS 262 address and address of the BFIR, and the Sender imposes an 263 appropriate RBS address header together with a unicast encapsulation 264 towards the BFIR. 266 CGM2 is also intended so especially simplify controller operations 267 that also instantiate QoS policies for multicast traffic flows, such 268 as bandwidth and latency reservations (e.g.: DetNet). As in BIER-TE, 269 this is orthogonal to the operations of the CGM2/RBS address 270 forwarding operations and will be covered in separate documents. 272 3. CGM2/RBS forwarding plane 274 Instead of a (flat) BitString as in BIER-TE that use a network wide 275 shared BP address space for adjacencies across multiple BFR, CGM2 276 uses a structured address built from so-called RecursiveUnits (RU) 277 that contain BitStrings, each of which is to be parsed by exactly one 278 BFR along the delivery tree of the packet. 280 The equivalent to a BIER/BIER-TE BitString is therefore called the 281 RecursiveUnit BitString Structure (RBS) Address. Forwarding for 282 CGMP2 is therefore also called RBS forwarding. 284 3.1. RBS BIFT 286 RBS BIFT as shown in Figure 2 are, like BIER-TE BIFT, tables that are 287 indexed by BP, containing for each BP an adjacency. The core 288 difference over BIER-TE BIFT is that the BP of the BIFT are all local 289 to the BFR, whereas in BIER-TE, the BP are shared across a BIER-TE 290 domain, each BFR can only use a subset the BP for its own 291 adjacencies, and only in some cases can BP be shared for adjacencies 292 across two (or more) BFR. Because of this difference, most of the 293 complexities of BIER-TE BIFT are not required with BIER-RBS BIFT, see 294 Section 6.1.3. 296 +--+---------+-------------+ 297 |BP|Recursive| Adjacency| 298 +--+---------+-------------+ 299 | 1| 1|adjacenct BFR| 300 +--+---------+-------------+ 301 | 2| 0| punt/host| 302 +--+---------+-------------+ 303 | ..... ... | 304 +--+---------+-------------+ 305 | N| ...| ... | 306 +--+---------+-------------+ 308 Figure 2: RBS BIFT 310 An RBS BIFT has a configured number of N addressable BP entries. 311 When a BFR receives a packet with an RBS address, it expects that the 312 BitString inside the RBS address that needs to be parsed by the BFR 313 (see Section 3.3 has a length that matches N according to the 314 encapsulation used for the RBS address. Therefore, N MUST support 315 configuration in increments of the supported size of the BitString in 316 the encapsulation of the RBS Address. In the reference encoding (see 317 Section 3.3), the increment for N is 1 (bit). If an encapsulation 318 would call for a byte accurate encoding of the BitString, N would 319 have to be configurable in increments of 8. 321 BFR MUST support a value of N larger than the maximum number of 322 adjacencies through which RBS forwarding/replication of a single 323 packet is required, such as the number of physical interfaces on BFR 324 that are intended to be deployed as a Provider Core (P) routers. 326 RBS BIFT introduce a new "Recursive" flag for each BP. These are 327 used for adjacencies to other BFR to indicate that the BFR processing 328 the packet RBS address BitString also has to expect for every BP with 329 the recursive flag set another RU inside the RBS address. 331 3.2. Reference encoding of RBS addresses 333 Structure elements of the RBS Address and its components are 334 parameterized according to a specific encapsulation for RBS 335 addresses, such as the total size of the TotalLen field and the unit 336 in which it is counted (see Section 3.3). These parameters are 337 outside the scope of this document. Instead, this document defines 338 example parameters that together form the so called "Reference 339 encoding of RBS addresses". This encoding may or may not be adopted 340 for any particular encapsulation of RBS addresses. 342 3.3. RBS Address 344 An RBS address is structured as shown in Figure 3. 346 +----------+-----+---------------+---------+ 347 | TotalLen | Rsv | RecursiveUnit | Padding | 348 +----------+-----+---------------+---------+ 349 . . 350 .... TotalLen ....... 352 Figure 3: RBS Address 354 TotalLen counts in some unit, such as bits, nibbles or bytes the 355 length of the RBS Address excluding itself and Padding. For the 356 reference encoding, TotalLen is an 8-bit field that counts the size 357 of the RBS address in bits, permitting for up to 256 bit long RBS 358 addresses. 360 In case additional, non-recursive flags/fields are determined to be 361 required in the RBS Address, they should be encoded in a field 362 between TotalLen and RecursiveUnit, which is called Rsv. In the 363 reference encoding, this field has a length of 0. 365 Padding is used to align the RBS address as required by the 366 encapsulation. In the reference encoding, this alignment is to 8 367 bits (byte boundaries). Therefore, Padding (bits) = (8 - TotalLen % 368 8). 370 3.3.1. RecursiveUnit 372 The RecursiveUnit field is structured as shown in Figure 4. 374 +-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+ -+ 375 | BitString...| AddressingField...| RecursiveUnit 1...M| 376 +-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+- -+ 378 Figure 4: RBS RecursiveUnit 380 The BitString field indicates the bit positions (BPs) to which the 381 packet is to be replicated using the BIFT of the BFR that is 382 processing the Recursive unit. 384 For each of M BP set in the BitString of the RecursiveUnit for which 385 the Recursive flag is set in the BIFT of the BFR, the RecursiveUnit 386 contains a RecursiveUnit i, i=1...M, in order of increasing BP index. 388 If adjacencies between BFR are not configured as recursive in the 389 BIFT, this recursive extraction does not happen for an adjacency, no 390 RecursiveUnit i has to be encoded for the BP, and BFRs across such 391 adjacencies would have to share the BP of a common BIFT as in BIER- 392 TE. This option is not further discussed in this version of the 393 document. 395 3.3.2. AddressingField 397 The AddressingField of an RBS address is structured as shown in 398 Figure 5. 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 401 | L1 | L2 |...| L(M-1) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 404 Figure 5: RBS AddressingField 406 The AddressingField consists of one or more fields Li, i=1...(M-1). 407 Li is the length of RecursiveUnit i for the i'th recursive bit set in 408 the BitString preceding it. 410 In the reference encoding, the lengths are 8-bit fields indicating 411 the length of RecursiveUnits in bits. 413 The length of the M'th RecursiveUnit is not explicitly encoded but 414 has to be calculated from TotalLen. 416 4. BIER-RBS Example 418 Figure 6 shows an example for RBS forwarding. 420 +-+ +-+ +-+ 421 | |-----| |------|C|-=> Client2 422 +-+ +-+ +-+ 423 / \ \ /=>/ \ 424 / \ \ / | 425 +-+ +-+ +-+ +-+ 426 Client1 =>-|B|-=>-|R|-=>-|S|-=>-|D|-=> Client3 427 +-+ +-+ +-+ +-+ 428 \ / 429 \ +-+ 430 \-=>-|E|-=> Client4 431 +-+ 433 Figure 6: Example Network Topology 435 A packet from Client1 connected to BFIR B is intended to be 436 replicated to Client2,3,4. The example initially assumes the 437 traditional option of the architecture, in which the imposition of 438 the header for the RBS address happens on BFIR B, for example based 439 on functions of an IP multicast flow overlay. 441 A controller determines that the packet should be forwarded hop-by- 442 hop across the network as shown in Figure 7. 444 Client 1 ->B(impose BIER-RBS) 445 =>R( 446 => E (dispose BIER-RBS) 447 => Client4 448 => S( 449 =>C (dispose BIER-RBS) 450 => Client2 451 =>D (dispose BIER-RBS) 452 => Client3 453 ) 454 ) 456 Figure 7: Desired example forwarding tree 458 4.1. BFR B 460 The 34 bit long (without padding) RBS address shown in Figure 8 is 461 constructed to represent the desired tree from Figure 7 and is 462 imposed at B onto the packet through an appropriate header supporting 463 the reference encoding of RBS addresses. 465 .............. RecursiveUnit ................. 466 . . 467 +-------+----+-----+-----+-----+----+-----+------+-----+-----+ 468 |Tlen:34|B:01|R:011|L1:10|S:011|L1:3|C:001|D:0001|E:001|Pad:6| 469 +-------+----+-----+-----+-----+----+-----+------+-----+-----+ 470 8bit 2bit 3bit 8bit 3bit 8bit 3bit 4bit 3bit 6bit 472 Figure 8: RBS Address imposed at BFIR-B 474 In Figure 8 and further the illustrations of RBS addresses, 475 BitStrings are preceded by the name of the BFR for whom they are 476 destined and their values are shown as binary with the lowest BP 1 477 starting on the left. TotalLength (Tlen:), AddressingField (L1:) and 478 Padding (Pad:) fields are shown with decimal values. 480 RBS forwarding on B examines this address based on its RBS BIFT with 481 N=2 BP entries, which is shown in Figure 9. 483 +--+---------+---------+ 484 |BP|Recursive|Adjacency| 485 +--+---------+---------+ 486 | 1| 0| client1 | 487 +--+---------+---------+ 488 | 2| 1| R | 489 +--+---------+---------+ 491 Figure 9: BIER-RBS BIFT on B 493 This results in the parsing of the RBS address as shown in Figure 10, 494 which shows that B does not need (nor can) parse all structural 495 elements, but only those relevant to its own RBS forwarding 496 procedure. 498 ......... RecursiveUnit ............... 499 . . 500 . ......,.. RecursiveUnit 1 ......... 501 . . . 502 +-------+----+----------------------------------+-----+ 503 |Tlen:34|B:01|R:01100001010011000000110010001001|Pad:6| 504 +-------+----+----------------------------------+-----+ 505 8bit 2bit 32bit 6bit 507 Figure 10: RBS Address as processed by BFIR-B 509 There is only one BP towards BFR R set in the BitString B:01, so the 510 RecursiveUnit 1 follows directly after the end of the BitString B:01 511 and it covers the whole Tlen - length of BitString (34 - 2 = 32 bit). 513 B rewrites the RBS address by replacing the RecursiveUnit with 514 RecursiveUnit 1 and adjusts the Padding to zero bits. The resulting 515 RBS address is shown in Figure 11. It then sends the packet copy 516 with that rewritten RBS address to BFR R. 518 4.2. BFR R 520 BFR R receives from BFR B the packet with that RBS address shown in 521 Figure 11. 523 .............. RecursiveUnit ............ 524 . . 525 +-------+-----+-----+-----+----+-----+------+-----+ 526 |Tlen:32|R:011|L1:18|S:011|L1:3|C:001|D:0001|E:001| 527 +-------+-----+-----+-----+----+-----+------+-----+ 528 8bit 3bit 8bit 3bit 8bit 3bit 4bit 3bit 529 . . . 530 . RecursiveUnit 1...... ..... 531 . 532 RecursiveUnit 2 ... 534 Figure 11: RBS Address processed by BFR-R 536 BFR R parses the RBS Address as shown in Figure 12 using its RBS BIFT 537 of N=3 BP entries shown in Figure 13. 539 .............. RecursiveUnit ............ 540 . . 541 +-------+-----+-----+--------------------+-----+ 542 |Tlen:32|R:011|L1:18|S:011000000110010001|E:001| 543 +-------+-----+-----+--------------------+-----+ 544 8bit 3bit 8bit 18bit 3bit 545 . . . 546 . RecursiveUnit 1... ..... 547 . 548 RecursiveUnit 2 ... 550 Figure 12: RBS Address processed by BFR-R 552 Because there are two recursive BP set in the BitString for R, one 553 for BFR S and one for BFR E, one Length field L1 is required in the 554 AddressingField, indicating the length of the RecursiveUnit 1 for BFR 555 S, followed by the remainder of the RBS address being the 556 RecursiveUnit 2 for BFR E. 558 +--+---------+---------+ 559 |BP|Recursive|Adjacency| 560 +--+---------+---------+ 561 | 1| 1| B | 562 +--+---------+---------+ 563 | 2| 1| S | 564 +--+---------+---------+ 565 | 3| 1| E | 566 +--+---------+---------+ 568 Figure 13: RBS BIFT on BFR R 570 BFR R accordingly creates one copy for BFR S using RecursiveUnit 1, 571 and only copy for BFR E using RecursiveUnit 2, updating Padding 572 accordingly for each copy. 574 4.3. BFR S 576 BFR S receives from BFR B the packet and parses the RBS address as 577 shown in Figure 14 using its RBS BIFT of N=3 BP shown in Figure 15. 579 .... RecursiveUnit .... 580 . . 581 +-------+-----+----+-----+------+-----+ 582 |Tlen:18|S:011|L1:3|C:001|D:0001|Pad:6| 583 +-------+-----+----+-----+------+-----+ 584 8bit 3bit 8bit 3bit 4bit 3bit 585 . . . . 586 .... ...... 587 RecursiveUnit 1 . . 588 . 589 RecursiveUnit 2 ....... 591 Figure 14: RBS Address processed by BFR-S 593 +--+---------+---------+ 594 |BP|Recursive|Adjacency| 595 +--+---------+---------+ 596 | 1| 1| R | 597 +--+---------+---------+ 598 | 2| 1| C | 599 +--+---------+---------+ 600 | 3| 1| D | 601 +--+---------+---------+ 603 Figure 15: RBS BIFT on BFR-S 605 BFR S accordingly sends one packet copy with RecursiveUnit 1 in the 606 RBS address to BFR C and a second packet copy with RecursiveUnit 2 to 607 BFR D. 609 4.4. BFR C 611 BFR C receives from BFR S the packet and parses the RBS address 612 according to its N=3 BP entries BIFT (shown in Figure 17) as shown in 613 Figure 16. 615 +-------+-----+-----+ 616 |Tlen:3 |C:001|Pad:5| 617 +-------+-----+-----+ 618 8bit 3bit 5bi 620 Figure 16: RBS Address processed by BFR-C 622 +--+---------+-------------+ 623 |BP|Recursive| Adjacency| 624 +--+---------+-------------+ 625 | 1| 1| S | 626 +--+---------+-------------+ 627 | 2| 1| D | 628 +--+---------+-------------+ 629 | 3| 0| local_decap| 630 +--+---------+-------------+ 632 Figure 17: RBS BIFT on BFR-C 634 BFR S accordingly creates one packet copy for BP 3 where the RBS 635 address encapsulation is disposed of, and the packet is ultimately 636 forwarded to Client 2, for example because of an IP multicast payload 637 for which the multicast flow overlay identifies Client 2 as an 638 interested receiver, as in BIER/BIER-TE. 640 To avoid having to use an IP flow overlay, the BIFT could instead 641 have one BP allocated for every non-RBS destination, in this example 642 BP 3 would then explicitly be allocated for Client 2, and instead of 643 disposing of the RBS address encapsulation, BFR C would impose or 644 rewrite a unicast encapsulation to make the packet become a unicast 645 packet directed to Client 2. This option is not further detailed in 646 this version of the document. 648 4.5. BFR D 650 The procedures for processing of the packet on BFR D are very much 651 the same as on BFR C. Figure 18 shows the RBS address at BFR D, 652 Figure 19 shows the N=4 bit RBS BIFT of BFR D. 654 +-------+------+-----+ 655 |Tlen:4 |D:0001|Pad:4| 656 +-------+------+-----+ 657 8bit 4bit 4bit 659 Figure 18: RBS Address processed by BFR-D 661 +--+---------+-------------+ 662 |BP|Recursive| Adjacency| 663 +--+---------+-------------+ 664 | 1| 1| S | 665 +--+---------+-------------+ 666 | 2| 1| C | 667 +--+---------+-------------+ 668 | 3| 1| E | 669 +--+---------+-------------+ 670 | 4| 0| local_decap| 671 +--+---------+-------------+ 673 Figure 19: RBS BIFT on BFR-D 675 4.6. BFR E 677 The procedures for processing of the packet on BFR E are very much 678 the same as on BFR C and D. Figure 20 shows the RBS address at BFR 679 D, Figure 21 shows the N=E bit RBS BIFT of BFR E. 681 +-------+-----+-----+ 682 |Tlen:3 |E:001|Pad:5| 683 +-------+-----+-----+ 684 8bit 3bit 5bit 686 Figure 20: RBS Address processed by BFR-E 688 +--+---------+-------------+ 689 |BP|Recursive| Adjacency| 690 +--+---------+-------------+ 691 | 1| 1| R | 692 +--+---------+-------------+ 693 | 2| 1| D | 694 +--+---------+-------------+ 695 | 3| 0| local_decap| 696 +--+---------+-------------+ 698 Figure 21: RBS BIFT on BFR-E 700 5. RBS forwarding Pseudocode 702 The following example RBS forwarding Pseudocode assumes the reference 703 encoding of bit-accurate length of BitStrings and RecursiveUnits as 704 well as 8-bit long TotalLen and AddressingField Lengths. All packet 705 field addressing and address/offset calculations is therefore bit- 706 accurate instead of byte accurate (which is what most CPU memory 707 access today is). 709 void ForwardRBSPacket (Packet) 710 { 711 RBS = GetPacketMulticastAddr(Packet); 712 Total_len = RBS; 713 Rsv = Total_len + length(Total_Len); 714 BitStringA = Rsv + length(Rsv); 715 AddressingField = BitStringA + BIFT.entries; 717 // [1] calculate number of recursive bits set in BitString 718 CopyBitString(*BitStringA, *RecursiveBits, BIFT.entries); 719 And(*RecursiveBits,*BIFTRecursiveBits, BIFT.entries); 720 N = CountBits(*RecursiveBits, BIFT.entries); 722 // Start of first RecursiveUnit in RBS address 723 // After AddressingField array with 8-bit length fields 724 RecursiveUnit = AddressingField + (N - 1) * 8; 726 RemainLength = *Total_len - length(Rsv) 727 - BIFT.entries; 729 Index = GetFirstBitPosition(*BitStringA); 730 while (Index) { 731 PacketCopy = Copy(Packet); 733 if (BIFT.BP[Index].recursive) { 734 if(N == 1) { 735 RecursiveUnitLength = RemainLength; 736 } else { 737 RecursiveUnitLength = *AddressingField; 738 N--; 739 AddressingField += 8; 740 RemainLength -= RecursiveUnitLength; 741 RemainLength -= 8; // 8 bit of AddressingField 742 } 743 RewriteRBS(PacketCopy, RecursiveUnit, RecursiveUnitLength); 744 SendTo(PacketCopy, BIFT.BP[Index].adjacency); 746 RecursiveUnit += RecursiveUnitLength; 747 } else { 748 DisposeRBSheader(PacketCopy); 749 SendTo(PacketCopy, BIFT.BP[Index].adjacency); 750 } 751 Index = GetNextBitPosition(*BitStringA, Index); 752 } 754 Figure 22: RBS address forwarding Pseudocode 756 Explanations for Figure 22. 758 RBS is the (bit accurate) address of the RBS address in packet header 759 memory. BitStringA is the address of the RBS address BitString in 760 memory. length(Total_Len) and length(Rsv) are the bit length of the 761 two RBS address fields, e.g.: 8 bit and 0 bit for the reference 762 encoding. 764 The BFR local BIFT has a total number of BIFT.entries addressable BP 765 1...BIFTentries. The BitString therefore has BIFT.entries bits. 767 BIFT.RecursiveBits is a BitString pre-filled by the control plane 768 with all the BP with the recursive flag set. This is constructed 769 from the Recursive flag setting of the BP of the BIFT. The code 770 starting at [1] therefore counts the number of recursive BP in the 771 packets BitString. 773 Because the AddressingField does not have an entry for the last (or 774 only) RecursiveUnit, its length has to be calculated by taking 775 TotalLen into account. 777 RewriteRBS needs to replace RBS address with the RecursiveUnit 778 address, keeping only Rsv, recalculating TotalLen and adding 779 appropriate Padding. 781 For non-recursive BP, the Pseudocode assumes disposition of the 782 RBSheader. This is not strictly necessary but non-disposing cases 783 are outside of scope of this version of the document. 785 6. Operational and design considerations (informational) 787 6.1. Comparison with BIER-TE / BIER 789 This section discusses informationally, how and where CGM2 can avoid 790 different complexities of BIER/BIER-TE, and where it introduces new 791 complexities. 793 6.1.1. Eliminating the need for large BIFT 795 In a BIER domain with M BFER, every BFR requires M BIFT entries. If 796 the supported BSL is N and M > 2 ^ N, then S = (M / 2 ^ N) set 797 indices (SI) are required, and S copies of the packet have to be sent 798 by the BFIR to reach all targeted BFER. 800 In CGM2, the number of BIFT entries does not need to scale with the 801 number of BFER or paths through the network, but can be limited to 802 only the number of L2 adjacencies of the BFR. Therefore CGM2 803 requires minimum state maintenance on each BFR, and multiple SI are 804 not required. 806 6.1.2. Reducing number of duplicate packet copies across BFR 808 If the total size of an RBS encoded delivery tree is larger than a 809 supported maximum RBS header size, then the CGM2 controller simply 810 needs to divide the tree into multiple subtrees, each only addressing 811 a part of the BFER (leaves) of the target tree and pruning any 812 unnecessary branches. 814 B1 815 / \ 816 B2 B3 817 / \ / \ 818 / \/ \ 819 B4 B5 B6 820 /..| / \ |..\ 821 B7..B99 B100..B200 B201...B300 823 Figure 23: Simple Topology Example 825 Consider the simple topology in Figure 23 and a multicast packet that 826 needs to reach all BFER B7...B300. Assume that the desired maximum 827 RBM header size is such that a RBS address size of <= 256 bits is 828 desired. The CGM2 controller could create an RBS address 829 B1=>B2=>B4=>(B7..B99), for a first packet, an RBS address 830 B1=>B3=>B5=>(B100..B200) for a second packet and a third RBS address 831 B1=>B3=>B6=>B201...B300. 833 The elimination of larger BIFT state in BFR through multiple SI in 834 BIER/BIER-TE does come at the expense of replicating initial hops of 835 a tree in RBS addresses, such as in the example the encoding of 836 B1=>B3 in the example. 838 Consider that the assignment of BFIR-ids with BIER in the above 839 example is not carefully engineered. It is then easily possible that 840 the BFR-ids for B7..B99 are not sequentially, but split over a larger 841 BFIR-id space. If the same is true for all BFER, then it is possible 842 that each of the three BFR B4,B5 and B6 has attached BFER from three 843 different SI and one may need to send for example three multiple 844 packets to B7 to address all BFER B7..B99 or to B5 to address all 845 B100..B200 or B6 to address all B201...B300. These unnecessary 846 duplicate packets across B4, B5 or B6 are because of the addressing 847 principle in BIER and are not necessary in CGM2, as long as the total 848 length of an RBS address does not require it. 850 For more analysis, see Section 6.3. 852 6.1.3. BIER-TE forwarding plane complexities 854 BIER-TE introduces forwarding plane complexities to allow reducing 855 the BSL required. While all of these could be supported / 856 implemented with CGM2, this document contends that they are not 857 necessary, therefore providing significant overall simplifications. 859 * BIER-TE supports multiple adjacencies in a single BIFT Index to 860 allow compressing multiple adjacencies into a single Index for 861 traffic that is known to always require replications to all those 862 adjacencies (such as when flooding TV traffic). 864 * BIER-TE support ECMP adjacencies which have to calculate which out 865 of 2 or more possible adjacencies a packet should be forwarded to. 867 * BIER-TE supports special Do-Not-Clear (DNC) behavior of 868 adjacencies to permit reuse of such a bit for adjacencies on 869 multiple consecutive BFR. This behavior specifically also raises 870 the risk of looping packets. 872 6.1.4. BIER-TE controller complexities 874 BIER-TE introduces BIER-TE controller plane mechanisms that allow to 875 reuse bits of the flat BIER-TE BitStrings across multiple BFR solely 876 to reduce the number of BP required but without introducing 877 additional complexities for the BIER-TE forwarding plane. 879 * Shared BP for all Leaf BFR. 881 * Shared BP for both Interfaces of p2p links. 883 * Shared bits for multi-access subnets (LANs). 885 These bit-sharing mechanisms are unnecessary and inapplicable to CGM2 886 because there is no need to share BP across the BIFT of multiple BFR. 888 6.1.5. BIER-TE specification complexities 890 The BIER-TE specification distinguishes between forward (link scope) 891 and routed (underlay routed) adjacencies to highlight, explain and 892 emphasize on the ability of BIER-TE to be deployed in an overlay 893 fashion especially also to reduce the necessary BSL, even when all 894 routers in the domain could or do support BIER-TE. 896 In CGM2, routed adjacencies are considered to be only required in 897 partial deployments to forward across non-CGM2 enabled routers. This 898 specification does therefore not highlight link scope vs. routed 899 adjacencies as core distinct features. 901 6.1.6. Forwarding plane complexity 903 CGM2 introduces some more processing calculation steps to extract the 904 BitString that needs to be examined by a BFR from the RBS address. 905 These additional steps are considered to be non-problematic for 906 todays programmable forwarding planes such as P4. 908 Whereas BIER-TE clears bit on each hops processing, CGM2 rewrites the 909 address on every hop by extracting the recursive unit for the next 910 hop and make it become the packet copies address. This rewrite 911 shortens the RBS address. This hopefully has only the same 912 complexity as (tunnel) encapsulations/decapsulations in existing 913 forwarding planes. 915 6.2. CGM2 / RBS controller considerations 917 TBD. Any aspects not covered in Section 6.1. 919 6.3. Analysis of performance gain with CGM2 921 TBD: Comparison of number of packets/header sizes required in large 922 real-world operator topology between BIER/BIER-TE and CGM2. 923 Analysis: Gain in dense topology. 925 6.3.1. Reference topology 927 Reference topology description: 929 1. Typical topology of Beijing Mobile in China. 931 2. All zones dual homing access to backbone. 933 3. Core layer: 4 nodes full mesh connected 935 4. Aggregation layer: 8 nodes are divided into two layers, with full 936 interconnection between the layers and dual homing access to the 937 core layer on the upper layer. 939 5. Aggregation rings: 8 rings, 6 nodes per ring 941 6. Access rings: 3600 nodes, 18 nodes per ring. 943 ┌──────┐ ┌──────┐ 944 │ ├──────────┤ │ 945 /└──────┘\ /└──────┘\ Interconnected 946 / / | \ \ / / | \ \ BackBone 947 ┌──────┐/ / | \ \ / / | \ \┌──────┐ 948 │ │ / | \ \ / / | \ │ │ 949 └───┬──┘ / | \ \/ / | \ └─┬────┘ 950 │ / | \ /\ / | \ │ 951 ┌──┴───┐ | / \ | ┌──┴───┐ 952 │ │------------+ \/ +------------│ │ 953 └──────┘\ | /\ | /└──────┘ 954 \ | / \ | / 955 \ ┌──────┐/ \┌──────┐ / 956 \│ ├──────┤ │/ 957 └───┬──┘ └───┬──┘ 958 │ \ / │ Dual Return Access 959 │ \ / │ 960 │ \ / │ 961 │ / │ 962 │ / \ │ 963 ┌─┴───┐/ \┌───┴─┐ 964 │ ├─────┤ │ 965 └─┬───┘\ /└───┬─┘ 966 │ \ / │ Core Layer 967 │ / │ 968 │ / \ │ 969 ┌─┴───┐/ \┌───┴─┐ 970 /│ ├─────┤ │\ 971 / └──┬──┘\ /└──┬──┘ \ 972 / │\ \ / /│ \ Zone1 973 / │ \ \ / │ \ 974 / │ \ / \ / │ \ 975 / +----│---+ +---│----+ \ 976 / / │ \ / │ \ \ 977 / / │ + │ \ \ 978 / / │ / \ │ \ \ 979 ┌───┐/ ┌┴──┐/ \┌──┴┐ \┌───┐ 980 │ │\ /│ │ │ │\ /│ │ 981 └─┬─┘ \ / └─┬─┘\ /└─┬─┘ \ / └─┬─┘ 982 │ \ / │ \ / │ \ / │ Aggregation 983 │ \/ │ / │ \/ │ Layer 984 │ /\ │ / \ │ /\ │ 985 ┌─┴─┐ / \ ┌─┴─┐/ \┌─┴─┐ / \ ┌─┴─┐ 986 │ │-- --│ │ │ │-- --│ │ 987 └───┘ └───┘\ /└───┘\ └───┘ 988 / | \ \ / / | \ 989 / | \ \ / | \ 990 / | / \/ | \ 991 / +--|--+ \/+---|---+ \ 992 / / | /\ | \ \ 993 ┌───┐ ┌┴──┐/ \┌───┐ ┌───┐ ASBR 994 │ │ │ │ │ │ │ │ 995 └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ 996 │ │ │ │ 997 │ │ │ │ 998 ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ 999 │ │ │ │ │ │ │ │ 1000 └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ 1001 │ │ │ │ 1002 │ │ 8Rings │ │ 1003 ┌─┴─┐ ┌─┴─┐ ...┌─┴─┐ ┌─┴─┐ 1004 │ │---│ │ │ │---│ │ 1005 ----└───┘ └───┘ └───┘\ └───┘ 1006 / / \ \ | \ \ \ | \ 1007 / / \ \ | \ \ +---|-+ \ 1008 / / \ +-|---+\ \ | \ \ 1009 / / \ | \\ \ | \ \ 1010 / / \ | \\ \ | \ \ 1011 / / \ | \\ \ | \ \ 1012 ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ CSBR 1013 │ │ │ │ │ │ │ │ │ │ │ │ 1014 └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ 1015 │ │ Access │ │ │ │ 1016 │ │ Rings │ │ │ │ 1017 ┌─┴─┐ ┌─┴─┐ ... ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ 1018 │ │ │ │ │ │ │ │ │ │ │ │ 1019 └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ 1020 │ │ │ │ │ │ 1021 │ │ │ │ │ │ 1022 ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ 1023 │ │ │ │ │ │ │ │ │ │ │ │ 1024 └───┘...└───┘ └───┘...└───┘ └───┘...└───┘ 1026 Figure 24: Reference Topology 1028 6.3.2. Comparison BIER and CGM2/RBS 1030 The following performance comparison is based on Figure 24. 1032 1. CGM2: We randomly select egress points as group members, with the 1033 total number ranging from 10 to 28800 (for sake of simplicity, we 1034 assume merely one client per egress point). The egress points 1035 are randomly distributed in the topology with 10 runs for each 1036 value, showing the average result in our graphs. The total 1037 number of samples is 60 1039 2. BIER: We divide the overall topology into 160 BIER domains, each 1040 of which includes 180 egress points, providing the total of 28000 1041 egress points. 1043 3. Simulation: In order to compare the BIER against the in-packet 1044 tree encoding mechanism, we limit the size of the header to 256 1045 bits (the typical size of a BIER header). 1047 Conclusion: 1. BIER reaches its 160 packet replication limit at 1048 about 500 users, while the in-packet tree encoding reaching its limit 1049 of 125 replications at about 12000 users. And the following decrease 1050 of replications is caused by the use of node-local broadcast as a 1051 further optimization. 2. For the sake of comparison, the same 1052 256-bit encapsulation limit is imposed on CGM2, but we can completely 1053 break the 256-bit encapsulation limit, thus allowing the source to 1054 send fewer multicast streams. 3. CCGM2 encoding performs 1055 significantly better than BIER in that it requires less packet 1056 replications and there network bandwidth. 1058 6.4. Example use case scenarios 1060 TBD. 1062 7. Acknowledgements 1064 This work is based on the design published by Sheng Jiang, Xu Bing, 1065 Yan Shen, Meng Rui, Wan Junjie and Wang Chuang {jiangsheng|bing.xu|ya 1066 nshen|mengrui|wanjunjie2|wangchuang}@huawei.com, see [CGM2Design]. 1068 8. Security considerations 1070 TBD. 1072 9. Changelog 1074 [RFC-Editor: please remove this section]. 1076 This document is written in https://github.com/cabo/kramdown-rfc2629 1077 markup language. This documents source is maintained at 1078 https://github.com/toerless/bier-cgm2-rbs, please provide feedback to 1079 the appropriate IETF mailing list and submit an Issue to the GitHub. 1081 01 - Added section 6.3 about performance comparison and co-author 1082 (Robin). 1084 00 - Initial version from [CGM2Design]. 1086 10. References 1088 10.1. Normative References 1090 [I-D.ietf-bier-te-arch] 1091 Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering 1092 for Bit Index Explicit Replication (BIER-TE)", Work in 1093 Progress, Internet-Draft, draft-ietf-bier-te-arch-12, 28 1094 January 2022, . 1097 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1098 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1099 . 1101 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1102 DOI 10.17487/RFC0791, September 1981, 1103 . 1105 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1106 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1107 Explicit Replication (BIER)", RFC 8279, 1108 DOI 10.17487/RFC8279, November 2017, 1109 . 1111 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1112 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1113 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1114 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1115 2018, . 1117 10.2. Informative References 1119 [CGM2Design] 1120 Jiang, S., Xu, B.(., Shen, Y., Rui, M., Junjie, W., and W. 1121 Chuang, "Novel Multicast Protocol Proposal Introduction", 1122 10 October 2021, 1123 . 1126 Authors' Addresses 1128 Toerless Eckert 1129 Futurewei Technologies USA 1130 2220 Central Expressway 1131 Santa Clara, CA 95050 1132 United States of America 1134 Email: tte@cs.fau.de 1135 Bing (Robin) Xu 1136 Huawei Technologies (2012Lab) 1137 China 1139 Email: bing.xu@huawei.com