-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-eckert-bier-cgm2-rbs-01.txt
1456 lines (959 loc) · 53.9 KB
/
draft-eckert-bier-cgm2-rbs-01.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
BIER T. Eckert
Internet-Draft Futurewei Technologies USA
Intended status: Experimental . Bing (Robin) Xu
Expires: 13 August 2022 Huawei Technologies (2012Lab)
9 February 2022
Carrier Grade Minimalist Multicast (CGM2) using Bit Index Explicit
Replication (BIER) with Recursive BitString Structure (RBS) Addresses
draft-eckert-bier-cgm2-rbs-01
Abstract
This memo introduces the architecture of a multicast architecture
derived from BIER-TE, which this memo calls Carrier Grade Minimalist
Multicast (CGM2). It reduces limitations and complexities of BIER-TE
by replacing the representation of the in-packet-header delivery tree
of packets through a "flat" BitString of adjacencies with a
hierarchical structure of BFR-local BitStrings called the Recursive
BitString Structure (RBS) Address.
Benefits of CGM2 with RBS addresses include smaller/fewer BIFT in
BFR, less complexity for the network architect and in the CGM2
controller (compared to a BIER-TE controller) and fewer packet copies
to reach a larger set of BFER.
The additional cost of forwarding with RBS addresses is a slightly
more complex processing of the RBS address in BFR compared to a flat
BitString and the novel per-hop rewrite of the RBS address as opposed
to bit-reset rewrite in BIER/BIER-TE.
CGM2 can support the traditional deployment model of BIER/BIER-TE
with the BIER/BIER-TE domain terminating at service provider PE
routers as BFIR/BFER, but it is also the intention of this document
to expand CGM2 domains all the way into hosts, and therefore
eliminating the need for an IP Multicast flow overlay, further
reducing the complexity of Multicast services using CGM2. Note that
this is not fully detailed in this version of the document.
This document does not specify an encapsulation for CGM2/RBS
addresses. It could use existing encapsulations such as [RFC8296],
but also other encapsulations such as IPv6 extension headers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 1]
Internet-Draft bier-cgm2-rbs February 2022
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 13 August 2022.
Copyright Notice
Copyright (c) 2022 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 (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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Encapsulation Considerations . . . . . . . . . . . . . . 4
2. CGM2/RBS Architecture . . . . . . . . . . . . . . . . . . . . 5
3. CGM2/RBS forwarding plane . . . . . . . . . . . . . . . . . . 6
3.1. RBS BIFT . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Reference encoding of RBS addresses . . . . . . . . . . . 8
3.3. RBS Address . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. RecursiveUnit . . . . . . . . . . . . . . . . . . . . 8
3.3.2. AddressingField . . . . . . . . . . . . . . . . . . . 9
4. BIER-RBS Example . . . . . . . . . . . . . . . . . . . . . . 9
4.1. BFR B . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. BFR R . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. BFR S . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. BFR C . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. BFR D . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. BFR E . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. RBS forwarding Pseudocode . . . . . . . . . . . . . . . . . . 16
6. Operational and design considerations (informational) . . . . 18
6.1. Comparison with BIER-TE / BIER . . . . . . . . . . . . . 18
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 2]
Internet-Draft bier-cgm2-rbs February 2022
6.1.1. Eliminating the need for large BIFT . . . . . . . . . 18
6.1.2. Reducing number of duplicate packet copies across
BFR . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3. BIER-TE forwarding plane complexities . . . . . . . . 20
6.1.4. BIER-TE controller complexities . . . . . . . . . . . 20
6.1.5. BIER-TE specification complexities . . . . . . . . . 20
6.1.6. Forwarding plane complexity . . . . . . . . . . . . . 21
6.2. CGM2 / RBS controller considerations . . . . . . . . . . 21
6.3. Analysis of performance gain with CGM2 . . . . . . . . . 21
6.3.1. Reference topology . . . . . . . . . . . . . . . . . 21
6.3.2. Comparison BIER and CGM2/RBS . . . . . . . . . . . . 23
6.4. Example use case scenarios . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. Security considerations . . . . . . . . . . . . . . . . . . . 24
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Overview
1.1. Introduction
Carrier Grade Minimalist Multicast (CGM2) is an architecture derived
from the BIER-TE architecture [I-D.ietf-bier-te-arch] with the
following changes/improvements.
CGM2 forwarding is based on the principles of BIER-TE forwarding: It
is based on an explicit, in-packet, "source routed" tree indicated
through bits for each adjacency that the packet has to traverse.
Like in BIER-TE, adjacencies can be L2 to a subnet local neighbor in
support of "native" deployment of CGM2 and/or L3, so-called "routed"
adjacencies to support incremental or partial deployment of CGM2 as
needed.
The address used to replicate packets in the network is not a flat
network wide BitString as in BIER-TE, but a hierarchical structure of
BitStrings called a Recursive BitString Structure (RBS) Address. The
significance of the BitPositions (BP) in each BitString is only local
to the BIFT of the router/BFR that is processing this specific
BitString.
RBS addressing allows for a more compact representation of a large
set of adjacencies especially in the common case of sparse set of
receivers in large Service Provider Networks (SP).
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 3]
Internet-Draft bier-cgm2-rbs February 2022
CGM2 thereby eliminates the challenges in BIER [RFC8279] and BIER-TE
having to send multiple copies of the same packet in large SP
networks and the complexities especially for BIER-TE (but also BIER)
to engineer multiple set identifier (SI) and/or sub-domains (SD)
BIER-TE topologies for limited size BitStrings (e.g.: 265) to cover
large network topologies.
Like BIER-TE, CGM2 is intended to leverage a Controller to minimize
the control plane complexity in the network to only a simple unicast
routing underlay required only for routed adjacencies.
The controller centric architecture provides most easily any type of
required traffic optimization for its multicast traffic due to their
need to perform often NP-complete calculations across the whole
topology: reservation of bandwidth to support CIR/PIR traffic buffer/
latency to support Deterministic Network (DetNet) traffic, cost
optimized Steiner trees, failure point disjoint trees for higher
resilience including DetNet deterministic services.
CGM2 can be deployed as BIER/BIER-TE are specified today, by
encapsulating IP Multicast traffic at Provider Edge (PE) routers, but
it is also considered to be highly desirable to extend CGM2 all the
way into Multicast Sender/Receivers to eliminate the overhead of an
Overlay Control plane for that (legacy) IP Multicast layer and the
need to deal with yet another IP multicast group addressing space.
In this deployment option Controller signaling extends directly (or
indirectly via BFIR) into senders.
1.2. Encapsulation Considerations
This document does not define a specific BIER-RBS encapsulation nor
does it preclude that multiple different encapsulations may be
beneficial to better support different use-cases or operator/user
technology preferences. Instead, it discusses considerations for
specific choices.
BIER-RBS can easily re-use [RFC8296] encapsulation. The RBS address
is inserted into the [RFC8296] BitString field. The BFR forwarding
plane needs to be configured (from Controller or control plane) that
the BIFT-id(s) used with RBS addresses are mapped to BIFT and
forwarding rules with RBS semantic.
SI/SD fields of [RFC8296] may be used as in BIER-TE, but given that
CGM2 is designed (as described in the Overview section) to simplify
multicast services, a likely and desirable configuration would be to
only use a single BIFT in each BFR for RBS addresses, and mapping
these to a single SD and SI 0.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 4]
Internet-Draft bier-cgm2-rbs February 2022
IP Multicast [RFC1112] was defined as an extension of IP [RFC791],
reusing the same network header, and IPv6 multicast inherits the same
approach. In comparison, [RFC8296] defines BIER encapsulation as a
completely separate (from IP) layer 3 protocol, and duplicates both
IP and MPLS header elements into the [RFC8296] header. This not only
results in always unused, duplicate header parameters (such as TC vs.
DSCP), but it also foregoes the option to use any non-considered IPv6
extension headers with BIER and would require the introduction of a
whole new BIER specific socket API into host operating systems if it
was to be supported natively in hosts.
Therefore an encapsulation of RBS addresses using an IP and/or IPv6
extension header may be more desirable in otherwise IP and/or IPv6
only deployments, for example when CGM2 is extended into hosts,
because it would allow to support CGM2 via existing IP/IPv6 socket
APIs as long as they support extension headers, which the most
important host stacks do today.
2. CGM2/RBS Architecture
This section describes the basic CGM2 architecture via Figure 1
through its key differences over the BIER-TE architecture.
Optional
|<-IGMP/PIM-> multicast flow <-PIM/IGMP->|
overlay
CGM2 [CGM2 Controller]
control plane . ^ ^ ^
. / | \ BIFT configuration
.......... | | | per-flow RBS setup
. | | |
. v v v
Src (-> ... ) -> BFIR-----BFR-----BFER -> (... ->) Rcvr
|<----------------->|
CGM2 with RBS-address forwarding plane
|<.............. <- CGM domain ---> ...............|
|<--------------------->|
Routing underlay (optional)
Figure 1: CGM2/RBS Architecture
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 5]
Internet-Draft bier-cgm2-rbs February 2022
In the "traditional" option, when deployed with a domain spanning
from BFIR to BFER, the CGM2 architecture is very much like the BIER-
TE architecture, in which the BIER-TE forwarding rules for
(BitString,SI,SD) addresses are replaced by the RBS address
forwarding rules.
The CGM2 Controller replaces the BIER-TE controller, populating
during network configuration the BIFT, which are very much like BIER-
TE BIFT, except that they do not cover a network-wide BP address
space, but instead each BFR BIFT only needs as many BP in its BIFT as
it has link-local adjacencies, and in partial deployments also
additional L3 adjacencies to tunnel across non-CGM capable routers.
Per-flow operations in this "traditional" option is very much as in
BIER/BIER-TE, with the CGM2 controller determining the RBS address
(instead of the BIER-TE (BitString,SI,SD)) to be imposed as part of
the RBS address header (compared to the BIER encapsulation [RFC8296])
on the BFIR.
To eliminate the need for an IP Multicast flow overlays, a CGM2
domain may extend all the way into Sender/Receiver hosts. This is
called "end-to-end" deployment model. In that case, the sender host
and CGM2 controller collaborate to determine the desired receivers
for a packet as well as desired path policy/requirements, the
controller indicates to the sender of the packet the necessary RBS
address and address of the BFIR, and the Sender imposes an
appropriate RBS address header together with a unicast encapsulation
towards the BFIR.
CGM2 is also intended so especially simplify controller operations
that also instantiate QoS policies for multicast traffic flows, such
as bandwidth and latency reservations (e.g.: DetNet). As in BIER-TE,
this is orthogonal to the operations of the CGM2/RBS address
forwarding operations and will be covered in separate documents.
3. CGM2/RBS forwarding plane
Instead of a (flat) BitString as in BIER-TE that use a network wide
shared BP address space for adjacencies across multiple BFR, CGM2
uses a structured address built from so-called RecursiveUnits (RU)
that contain BitStrings, each of which is to be parsed by exactly one
BFR along the delivery tree of the packet.
The equivalent to a BIER/BIER-TE BitString is therefore called the
RecursiveUnit BitString Structure (RBS) Address. Forwarding for
CGMP2 is therefore also called RBS forwarding.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 6]
Internet-Draft bier-cgm2-rbs February 2022
3.1. RBS BIFT
RBS BIFT as shown in Figure 2 are, like BIER-TE BIFT, tables that are
indexed by BP, containing for each BP an adjacency. The core
difference over BIER-TE BIFT is that the BP of the BIFT are all local
to the BFR, whereas in BIER-TE, the BP are shared across a BIER-TE
domain, each BFR can only use a subset the BP for its own
adjacencies, and only in some cases can BP be shared for adjacencies
across two (or more) BFR. Because of this difference, most of the
complexities of BIER-TE BIFT are not required with BIER-RBS BIFT, see
Section 6.1.3.
+--+---------+-------------+
|BP|Recursive| Adjacency|
+--+---------+-------------+
| 1| 1|adjacenct BFR|
+--+---------+-------------+
| 2| 0| punt/host|
+--+---------+-------------+
| ..... ... |
+--+---------+-------------+
| N| ...| ... |
+--+---------+-------------+
Figure 2: RBS BIFT
An RBS BIFT has a configured number of N addressable BP entries.
When a BFR receives a packet with an RBS address, it expects that the
BitString inside the RBS address that needs to be parsed by the BFR
(see Section 3.3 has a length that matches N according to the
encapsulation used for the RBS address. Therefore, N MUST support
configuration in increments of the supported size of the BitString in
the encapsulation of the RBS Address. In the reference encoding (see
Section 3.3), the increment for N is 1 (bit). If an encapsulation
would call for a byte accurate encoding of the BitString, N would
have to be configurable in increments of 8.
BFR MUST support a value of N larger than the maximum number of
adjacencies through which RBS forwarding/replication of a single
packet is required, such as the number of physical interfaces on BFR
that are intended to be deployed as a Provider Core (P) routers.
RBS BIFT introduce a new "Recursive" flag for each BP. These are
used for adjacencies to other BFR to indicate that the BFR processing
the packet RBS address BitString also has to expect for every BP with
the recursive flag set another RU inside the RBS address.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 7]
Internet-Draft bier-cgm2-rbs February 2022
3.2. Reference encoding of RBS addresses
Structure elements of the RBS Address and its components are
parameterized according to a specific encapsulation for RBS
addresses, such as the total size of the TotalLen field and the unit
in which it is counted (see Section 3.3). These parameters are
outside the scope of this document. Instead, this document defines
example parameters that together form the so called "Reference
encoding of RBS addresses". This encoding may or may not be adopted
for any particular encapsulation of RBS addresses.
3.3. RBS Address
An RBS address is structured as shown in Figure 3.
+----------+-----+---------------+---------+
| TotalLen | Rsv | RecursiveUnit | Padding |
+----------+-----+---------------+---------+
. .
.... TotalLen .......
Figure 3: RBS Address
TotalLen counts in some unit, such as bits, nibbles or bytes the
length of the RBS Address excluding itself and Padding. For the
reference encoding, TotalLen is an 8-bit field that counts the size
of the RBS address in bits, permitting for up to 256 bit long RBS
addresses.
In case additional, non-recursive flags/fields are determined to be
required in the RBS Address, they should be encoded in a field
between TotalLen and RecursiveUnit, which is called Rsv. In the
reference encoding, this field has a length of 0.
Padding is used to align the RBS address as required by the
encapsulation. In the reference encoding, this alignment is to 8
bits (byte boundaries). Therefore, Padding (bits) = (8 - TotalLen %
8).
3.3.1. RecursiveUnit
The RecursiveUnit field is structured as shown in Figure 4.
+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+ -+
| BitString...| AddressingField...| RecursiveUnit 1...M|
+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+- -+
Figure 4: RBS RecursiveUnit
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 8]
Internet-Draft bier-cgm2-rbs February 2022
The BitString field indicates the bit positions (BPs) to which the
packet is to be replicated using the BIFT of the BFR that is
processing the Recursive unit.
For each of M BP set in the BitString of the RecursiveUnit for which
the Recursive flag is set in the BIFT of the BFR, the RecursiveUnit
contains a RecursiveUnit i, i=1...M, in order of increasing BP index.
If adjacencies between BFR are not configured as recursive in the
BIFT, this recursive extraction does not happen for an adjacency, no
RecursiveUnit i has to be encoded for the BP, and BFRs across such
adjacencies would have to share the BP of a common BIFT as in BIER-
TE. This option is not further discussed in this version of the
document.
3.3.2. AddressingField
The AddressingField of an RBS address is structured as shown in
Figure 5.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| L1 | L2 |...| L(M-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: RBS AddressingField
The AddressingField consists of one or more fields Li, i=1...(M-1).
Li is the length of RecursiveUnit i for the i'th recursive bit set in
the BitString preceding it.
In the reference encoding, the lengths are 8-bit fields indicating
the length of RecursiveUnits in bits.
The length of the M'th RecursiveUnit is not explicitly encoded but
has to be calculated from TotalLen.
4. BIER-RBS Example
Figure 6 shows an example for RBS forwarding.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 9]
Internet-Draft bier-cgm2-rbs February 2022
+-+ +-+ +-+
| |-----| |------|C|-=> Client2
+-+ +-+ +-+
/ \ \ /=>/ \
/ \ \ / |
+-+ +-+ +-+ +-+
Client1 =>-|B|-=>-|R|-=>-|S|-=>-|D|-=> Client3
+-+ +-+ +-+ +-+
\ /
\ +-+
\-=>-|E|-=> Client4
+-+
Figure 6: Example Network Topology
A packet from Client1 connected to BFIR B is intended to be
replicated to Client2,3,4. The example initially assumes the
traditional option of the architecture, in which the imposition of
the header for the RBS address happens on BFIR B, for example based
on functions of an IP multicast flow overlay.
A controller determines that the packet should be forwarded hop-by-
hop across the network as shown in Figure 7.
Client 1 ->B(impose BIER-RBS)
=>R(
=> E (dispose BIER-RBS)
=> Client4
=> S(
=>C (dispose BIER-RBS)
=> Client2
=>D (dispose BIER-RBS)
=> Client3
)
)
Figure 7: Desired example forwarding tree
4.1. BFR B
The 34 bit long (without padding) RBS address shown in Figure 8 is
constructed to represent the desired tree from Figure 7 and is
imposed at B onto the packet through an appropriate header supporting
the reference encoding of RBS addresses.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 10]
Internet-Draft bier-cgm2-rbs February 2022
.............. RecursiveUnit .................
. .
+-------+----+-----+-----+-----+----+-----+------+-----+-----+
|Tlen:34|B:01|R:011|L1:10|S:011|L1:3|C:001|D:0001|E:001|Pad:6|
+-------+----+-----+-----+-----+----+-----+------+-----+-----+
8bit 2bit 3bit 8bit 3bit 8bit 3bit 4bit 3bit 6bit
Figure 8: RBS Address imposed at BFIR-B
In Figure 8 and further the illustrations of RBS addresses,
BitStrings are preceded by the name of the BFR for whom they are
destined and their values are shown as binary with the lowest BP 1
starting on the left. TotalLength (Tlen:), AddressingField (L1:) and
Padding (Pad:) fields are shown with decimal values.
RBS forwarding on B examines this address based on its RBS BIFT with
N=2 BP entries, which is shown in Figure 9.
+--+---------+---------+
|BP|Recursive|Adjacency|
+--+---------+---------+
| 1| 0| client1 |
+--+---------+---------+
| 2| 1| R |
+--+---------+---------+
Figure 9: BIER-RBS BIFT on B
This results in the parsing of the RBS address as shown in Figure 10,
which shows that B does not need (nor can) parse all structural
elements, but only those relevant to its own RBS forwarding
procedure.
......... RecursiveUnit ...............
. .
. ......,.. RecursiveUnit 1 .........
. . .
+-------+----+----------------------------------+-----+
|Tlen:34|B:01|R:01100001010011000000110010001001|Pad:6|
+-------+----+----------------------------------+-----+
8bit 2bit 32bit 6bit
Figure 10: RBS Address as processed by BFIR-B
There is only one BP towards BFR R set in the BitString B:01, so the
RecursiveUnit 1 follows directly after the end of the BitString B:01
and it covers the whole Tlen - length of BitString (34 - 2 = 32 bit).
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 11]
Internet-Draft bier-cgm2-rbs February 2022
B rewrites the RBS address by replacing the RecursiveUnit with
RecursiveUnit 1 and adjusts the Padding to zero bits. The resulting
RBS address is shown in Figure 11. It then sends the packet copy
with that rewritten RBS address to BFR R.
4.2. BFR R
BFR R receives from BFR B the packet with that RBS address shown in
Figure 11.
.............. RecursiveUnit ............
. .
+-------+-----+-----+-----+----+-----+------+-----+
|Tlen:32|R:011|L1:18|S:011|L1:3|C:001|D:0001|E:001|
+-------+-----+-----+-----+----+-----+------+-----+
8bit 3bit 8bit 3bit 8bit 3bit 4bit 3bit
. . .
. RecursiveUnit 1...... .....
.
RecursiveUnit 2 ...
Figure 11: RBS Address processed by BFR-R
BFR R parses the RBS Address as shown in Figure 12 using its RBS BIFT
of N=3 BP entries shown in Figure 13.
.............. RecursiveUnit ............
. .
+-------+-----+-----+--------------------+-----+
|Tlen:32|R:011|L1:18|S:011000000110010001|E:001|
+-------+-----+-----+--------------------+-----+
8bit 3bit 8bit 18bit 3bit
. . .
. RecursiveUnit 1... .....
.
RecursiveUnit 2 ...
Figure 12: RBS Address processed by BFR-R
Because there are two recursive BP set in the BitString for R, one
for BFR S and one for BFR E, one Length field L1 is required in the
AddressingField, indicating the length of the RecursiveUnit 1 for BFR
S, followed by the remainder of the RBS address being the
RecursiveUnit 2 for BFR E.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 12]
Internet-Draft bier-cgm2-rbs February 2022
+--+---------+---------+
|BP|Recursive|Adjacency|
+--+---------+---------+
| 1| 1| B |
+--+---------+---------+
| 2| 1| S |
+--+---------+---------+
| 3| 1| E |
+--+---------+---------+
Figure 13: RBS BIFT on BFR R
BFR R accordingly creates one copy for BFR S using RecursiveUnit 1,
and only copy for BFR E using RecursiveUnit 2, updating Padding
accordingly for each copy.
4.3. BFR S
BFR S receives from BFR B the packet and parses the RBS address as
shown in Figure 14 using its RBS BIFT of N=3 BP shown in Figure 15.
.... RecursiveUnit ....
. .
+-------+-----+----+-----+------+-----+
|Tlen:18|S:011|L1:3|C:001|D:0001|Pad:6|
+-------+-----+----+-----+------+-----+
8bit 3bit 8bit 3bit 4bit 3bit
. . . .
.... ......
RecursiveUnit 1 . .
.
RecursiveUnit 2 .......
Figure 14: RBS Address processed by BFR-S
+--+---------+---------+
|BP|Recursive|Adjacency|
+--+---------+---------+
| 1| 1| R |
+--+---------+---------+
| 2| 1| C |
+--+---------+---------+
| 3| 1| D |
+--+---------+---------+
Figure 15: RBS BIFT on BFR-S
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 13]
Internet-Draft bier-cgm2-rbs February 2022
BFR S accordingly sends one packet copy with RecursiveUnit 1 in the
RBS address to BFR C and a second packet copy with RecursiveUnit 2 to
BFR D.
4.4. BFR C
BFR C receives from BFR S the packet and parses the RBS address
according to its N=3 BP entries BIFT (shown in Figure 17) as shown in
Figure 16.
+-------+-----+-----+
|Tlen:3 |C:001|Pad:5|
+-------+-----+-----+
8bit 3bit 5bi
Figure 16: RBS Address processed by BFR-C
+--+---------+-------------+
|BP|Recursive| Adjacency|
+--+---------+-------------+
| 1| 1| S |
+--+---------+-------------+
| 2| 1| D |
+--+---------+-------------+
| 3| 0| local_decap|
+--+---------+-------------+
Figure 17: RBS BIFT on BFR-C
BFR S accordingly creates one packet copy for BP 3 where the RBS
address encapsulation is disposed of, and the packet is ultimately
forwarded to Client 2, for example because of an IP multicast payload
for which the multicast flow overlay identifies Client 2 as an
interested receiver, as in BIER/BIER-TE.
To avoid having to use an IP flow overlay, the BIFT could instead
have one BP allocated for every non-RBS destination, in this example
BP 3 would then explicitly be allocated for Client 2, and instead of
disposing of the RBS address encapsulation, BFR C would impose or
rewrite a unicast encapsulation to make the packet become a unicast
packet directed to Client 2. This option is not further detailed in
this version of the document.
4.5. BFR D
The procedures for processing of the packet on BFR D are very much
the same as on BFR C. Figure 18 shows the RBS address at BFR D,
Figure 19 shows the N=4 bit RBS BIFT of BFR D.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 14]
Internet-Draft bier-cgm2-rbs February 2022
+-------+------+-----+
|Tlen:4 |D:0001|Pad:4|
+-------+------+-----+
8bit 4bit 4bit
Figure 18: RBS Address processed by BFR-D
+--+---------+-------------+
|BP|Recursive| Adjacency|
+--+---------+-------------+
| 1| 1| S |
+--+---------+-------------+
| 2| 1| C |
+--+---------+-------------+
| 3| 1| E |
+--+---------+-------------+
| 4| 0| local_decap|
+--+---------+-------------+
Figure 19: RBS BIFT on BFR-D
4.6. BFR E
The procedures for processing of the packet on BFR E are very much
the same as on BFR C and D. Figure 20 shows the RBS address at BFR
D, Figure 21 shows the N=E bit RBS BIFT of BFR E.
+-------+-----+-----+
|Tlen:3 |E:001|Pad:5|
+-------+-----+-----+
8bit 3bit 5bit
Figure 20: RBS Address processed by BFR-E
+--+---------+-------------+
|BP|Recursive| Adjacency|
+--+---------+-------------+
| 1| 1| R |
+--+---------+-------------+
| 2| 1| D |
+--+---------+-------------+
| 3| 0| local_decap|
+--+---------+-------------+
Figure 21: RBS BIFT on BFR-E
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 15]
Internet-Draft bier-cgm2-rbs February 2022
5. RBS forwarding Pseudocode
The following example RBS forwarding Pseudocode assumes the reference
encoding of bit-accurate length of BitStrings and RecursiveUnits as
well as 8-bit long TotalLen and AddressingField Lengths. All packet
field addressing and address/offset calculations is therefore bit-
accurate instead of byte accurate (which is what most CPU memory
access today is).
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 16]
Internet-Draft bier-cgm2-rbs February 2022
void ForwardRBSPacket (Packet)
{
RBS = GetPacketMulticastAddr(Packet);
Total_len = RBS;
Rsv = Total_len + length(Total_Len);
BitStringA = Rsv + length(Rsv);
AddressingField = BitStringA + BIFT.entries;
// [1] calculate number of recursive bits set in BitString
CopyBitString(*BitStringA, *RecursiveBits, BIFT.entries);
And(*RecursiveBits,*BIFTRecursiveBits, BIFT.entries);
N = CountBits(*RecursiveBits, BIFT.entries);
// Start of first RecursiveUnit in RBS address
// After AddressingField array with 8-bit length fields
RecursiveUnit = AddressingField + (N - 1) * 8;
RemainLength = *Total_len - length(Rsv)
- BIFT.entries;
Index = GetFirstBitPosition(*BitStringA);
while (Index) {
PacketCopy = Copy(Packet);
if (BIFT.BP[Index].recursive) {
if(N == 1) {
RecursiveUnitLength = RemainLength;
} else {
RecursiveUnitLength = *AddressingField;
N--;
AddressingField += 8;
RemainLength -= RecursiveUnitLength;
RemainLength -= 8; // 8 bit of AddressingField
}
RewriteRBS(PacketCopy, RecursiveUnit, RecursiveUnitLength);
SendTo(PacketCopy, BIFT.BP[Index].adjacency);
RecursiveUnit += RecursiveUnitLength;
} else {
DisposeRBSheader(PacketCopy);
SendTo(PacketCopy, BIFT.BP[Index].adjacency);
}
Index = GetNextBitPosition(*BitStringA, Index);
}
Figure 22: RBS address forwarding Pseudocode
Explanations for Figure 22.
Eckert & Bing (Robin) Xu Expires 13 August 2022 [Page 17]
Internet-Draft bier-cgm2-rbs February 2022
RBS is the (bit accurate) address of the RBS address in packet header
memory. BitStringA is the address of the RBS address BitString in
memory. length(Total_Len) and length(Rsv) are the bit length of the
two RBS address fields, e.g.: 8 bit and 0 bit for the reference
encoding.
The BFR local BIFT has a total number of BIFT.entries addressable BP
1...BIFTentries. The BitString therefore has BIFT.entries bits.
BIFT.RecursiveBits is a BitString pre-filled by the control plane
with all the BP with the recursive flag set. This is constructed
from the Recursive flag setting of the BP of the BIFT. The code
starting at [1] therefore counts the number of recursive BP in the
packets BitString.
Because the AddressingField does not have an entry for the last (or
only) RecursiveUnit, its length has to be calculated by taking
TotalLen into account.
RewriteRBS needs to replace RBS address with the RecursiveUnit
address, keeping only Rsv, recalculating TotalLen and adding
appropriate Padding.
For non-recursive BP, the Pseudocode assumes disposition of the
RBSheader. This is not strictly necessary but non-disposing cases
are outside of scope of this version of the document.
6. Operational and design considerations (informational)
6.1. Comparison with BIER-TE / BIER
This section discusses informationally, how and where CGM2 can avoid
different complexities of BIER/BIER-TE, and where it introduces new
complexities.
6.1.1. Eliminating the need for large BIFT
In a BIER domain with M BFER, every BFR requires M BIFT entries. If
the supported BSL is N and M > 2 ^ N, then S = (M / 2 ^ N) set
indices (SI) are required, and S copies of the packet have to be sent
by the BFIR to reach all targeted BFER.
In CGM2, the number of BIFT entries does not need to scale with the
number of BFER or paths through the network, but can be limited to