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
|
<pre>Internet Engineering Task Force (IETF) F. Balus, Ed.
Request for Comments: 7041 Alcatel-Lucent
Category: Informational A. Sajassi, Ed.
ISSN: 2070-1721 Cisco
N. Bitar, Ed.
Verizon
November 2013
<span class="h1">Extensions to the Virtual Private LAN Service (VPLS)</span>
<span class="h1">Provider Edge (PE) Model for Provider Backbone Bridging</span>
Abstract
The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines
an architecture and bridge protocols for interconnection of multiple
Provider Bridged Networks (PBNs). Provider backbone bridging was
defined by IEEE as a connectionless technology based on multipoint
VLAN tunnels. PBB can be used to attain better scalability than
Provider Bridges (PBs) in terms of the number of customer Media
Access Control addresses and the number of service instances that can
be supported.
The Virtual Private LAN Service (VPLS) provides a framework for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without running the Rapid Spanning
Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP)
across the backbone. As a result, VPLS has been deployed on a large
scale in service provider networks.
This document discusses extensions to the VPLS Provider Edge (PE)
model required to incorporate desirable PBB components while
maintaining the service provider fit of the initial model.
<span class="grey">Balus, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7041">http://www.rfc-editor.org/info/rfc7041</a>.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. General Terminology .............................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. PE Reference Model ..............................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Packet Walkthrough ..............................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Control Plane ..................................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Efficient Packet Replication in PBB VPLS .......................<a href="#page-12">12</a>
<a href="#section-7">7</a>. PBB VPLS OAM ...................................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-13">13</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-13">13</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. Contributors ..................................................<a href="#page-14">14</a>
<a href="#section-11">11</a>. Acknowledgments ...............................................<a href="#page-15">15</a>
<span class="grey">Balus, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IEEE 802.1 Provider Backbone Bridges specification [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] defines
an architecture and bridge protocols for interconnection of multiple
Provider Bridged Networks (PBNs). PBB can be used to attain better
scalability than Provider Bridges [<a href="#ref-PB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PB</a>] in terms of the number of
customer Media Access Control (MAC) addresses and the number of
service instances that can be supported. PBB provides a data-plane
hierarchy and new addressing designed to achieve such better
scalability in Provider Backbone Networks. A number of Ethernet
control-plane protocols, such as the Rapid Spanning Tree Protocol
(RSTP), the Multiple Spanning Tree Protocol (MSTP), and Shortest Path
Bridging (SPB), could be deployed as the core control plane for loop
avoidance and load balancing for PBB. The applicability of these
control protocols is out of scope for this document.
The Virtual Private LAN Service (VPLS) provides a solution for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without requiring the use of a native
Ethernet control-plane protocol across the backbone. VPLS use of
the structured FEC 129 [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>] also allows for inter-domain,
inter-provider connectivity and enables auto-discovery options across
the network, improving the service delivery options.
A hierarchical solution for VPLS was introduced in [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] and
[<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>] to provide improved scalability and efficient handling of
packet replication. These improvements are achieved by reducing the
number of Provider Edge (PE) devices connected in a full-mesh
topology through the creation of two-tier PEs. A User-facing PE
(U-PE) aggregates all the Customer Edge (CE) devices in a lower-tier
access network and then connects to the Network-facing PE (N-PE)
device(s) deployed around the core domain. In VPLS, Media Access
Control (MAC) address learning and forwarding are done based on
Customer MAC addresses (C-MACs); this poses scalability issues on the
N-PE devices as the number of VPLS instances (and thus C-MACs)
increases. Furthermore, since a set of pseudowires (PWs) is
maintained on a "per customer service instance" basis, the number of
PWs required at N-PE devices is proportional to the number of
customer service instances multiplied by the number of N-PE devices
in the full-mesh set. This can result in scalability issues (in
terms of PW manageability and troubleshooting) as the number of
customer service instances grows.
This document describes how PBB can be integrated with VPLS to allow
for useful PBB capabilities while continuing to avoid the use of MSTP
in the backbone. The combined solution referred to in this document
<span class="grey">Balus, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
as PBB-VPLS results in better scalability in terms of the number of
service instances, PWs, and C-MACs that need to be handled in the
VPLS PEs.
<a href="#section-2">Section 2</a> provides a quick terminology reference. <a href="#section-3">Section 3</a> covers
the reference model for PBB VPLS PEs. <a href="#section-4">Section 4</a> describes the packet
walkthrough. Sections <a href="#section-5">5</a> through <a href="#section-7">7</a> discuss the PBB-VPLS usage of
existing VPLS mechanisms -- the control plane; efficient packet
replication; and Operations, Administration, and Maintenance (OAM).
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. General Terminology</span>
Some general terminology is defined here; most of the terminology
used is from [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>], [<a href="#ref-PB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PB</a>], [<a href="./rfc4664" title=""Framework for Layer 2 Virtual Private Networks (L2VPNs)"">RFC4664</a>], and [<a href="./rfc4026" title=""Provider Provisioned Virtual Private Network (VPN) Terminology"">RFC4026</a>]. Terminology
specific to this memo is introduced as needed in later sections.
B-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains a B-component that supports
bridging in the provider backbone based on Backbone MAC (B-MAC)
and B-tag information.
B-component: A bridging component contained in backbone edge and core
bridges that bridges in the backbone space (B-MAC addresses,
B-VLAN).
B-MAC: The backbone source or destination MAC address fields defined
in the PBB provider MAC encapsulation header.
B-tag: Field defined in the PBB provider MAC encapsulation header
that conveys the backbone VLAN identifier information. The format
of the B-tag field is the same as that of an 802.1ad S-tag field.
B-Tagged Service Interface: The interface between a BEB and a
Backbone Core Bridge (BCB) in a provider backbone bridged network.
Frames passed through this interface contain a B-tag field.
B-VID: The specific VLAN identifier carried inside a B-tag.
B-VLAN: The backbone VLAN associated with a B-component.
B-PW: The pseudowire used to interconnect B-component instances.
BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It can contain an I-component, a
B-component, or both I-components and B-components.
C-VID: The VLAN identifier in a customer VLAN.
<span class="grey">Balus, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
DA: Destination Address.
I-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging
in the customer space (customer MAC addresses, service VLAN IDs).
I-component: A bridging component contained in a backbone edge bridge
that bridges in the customer space (customer MAC addresses,
service VLAN identifier information (S-VLAN)).
I-SID: The 24-bit service instance field carried inside the I-tag.
I-SID defines the service instance that the frame should be
"mapped to".
I-tag: A field defined in the PBB provider MAC encapsulation header
that conveys the service instance information (I-SID) associated
with the frame.
I-Tagged Service Interface: The interface defined between the
I-components and B-components inside an IB-BEB or between two
B-BEBs. Frames passed through this interface contain an I-tag
field.
IB-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging
in the customer space (customer MAC addresses, service VLAN IDs)
and a B-component for bridging the provider's backbone space
(B-MAC, B-tag).
PBs: Provider Bridges (IEEE amendment (802.1ad) to 802.1Q for "QinQ"
encapsulation and bridging of Ethernet frames [<a href="#ref-PB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PB</a>]).
PBBs: Provider Backbone Bridges (IEEE amendment (802.1ah) to 802.1Q
for "MAC tunneling" encapsulation and bridging of frames across a
provider network [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>]).
PBBN: Provider Backbone Bridged Network.
PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ)
technology.
PSN: Packet-Switched Network.
S-tag: A field defined in the 802.1ad QinQ encapsulation header that
conveys the service VLAN identifier information (S-VLAN).
<span class="grey">Balus, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
S-Tagged Service Interface: The interface defined between the
customer (CE) and the I-BEB or IB-BEB components. Frames passed
through this interface contain an S-tag field.
S-VLAN: The specific service VLAN identifier carried inside an S-tag.
SA: Source Address.
S-VID: The VLAN identifier in a service VLAN.
Tag: In Ethernet, a header immediately following the Source MAC
Address field of the frame.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. PE Reference Model</span>
The following gives a short primer on the Provider Backbone Bridge
(PBB) before describing the PE reference model for PBB-VPLS. The
internal components of a PBB bridge module are depicted in Figure 1.
+-------------------------------+
| PBB Bridge Model |
| |
+---+ | +------+ +-----------+ |
|CE |---------|I-Comp|------| | |
+---+ | | | | |--------
| +------+ | | |
| o | B-Comp | |
| o | |--------
| o | | |
+---+ | +------+ | | |
|CE |---------|I-Comp|------| |--------
+---+ ^ | | | ^ | | | ^
| | +------+ | +-----------+ | |
| +------------|------------------+ |
| | |
| | |
S-tagged I-tagged B-tagged
Service Interface Service I/F Service I/F
(I/F)
Figure 1: PBB Bridge Model
<span class="grey">Balus, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
Provider Backbone Bridges (PBBs) [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] offer a scalable solution for
service providers to build large bridged networks. The focus of PBB
is primarily on improving two main areas with provider Ethernet
bridged networks:
- MAC-address table scalability
- Service instance scalability
To obviate the above two limitations, PBB introduces a hierarchical
network architecture with associated new frame formats that extend
the work completed by Provider Bridges (PBs). In the PBBN
architecture, customer networks (using PBs) are aggregated into
PBBNs, which utilize the IEEE PBB frame format. The frame format
employs a MAC tunneling encapsulation scheme for tunneling customer
Ethernet frames within provider Ethernet frames across the PBBN. A
VLAN identifier (B-VID) is used to segregate the backbone into
broadcast domains, and a new 24-bit service identifier (I-SID) is
defined and used to associate a given customer MAC frame with a
provider service instance (also called the service delimiter). It
should be noted that in [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] there is a clear segregation between
provider service instances (represented by I-SIDs) and provider VLANs
(represented by B-VIDs), which was not the case for PBs.
As shown in Figure 1, a PBB bridge may consist of a single
B-component and one or more I-components. In simple terms, the
B-component provides bridging in the provider space (B-MAC, B-VLAN),
and the I-component provides bridging in the customer space (C-MAC,
S-VLAN). The customer frame is first encapsulated with the provider
backbone header (B-MAC, B-tag, I-tag); then, the bridging is
performed in the provider backbone space (B-MAC, B-VLAN) through the
network till the frame arrives at the destination BEB, where it gets
decapsulated and passed to the CE. If a PBB bridge consists of both
I-components and B-components, then it is called an IB-BEB, and if it
only consists of either B-components or I-components, then it is
called a B-BEB or an I-BEB, respectively. The interface between an
I-BEB or IB-BEB and a CE is called an S-tagged service interface, and
the interface between an I-BEB and a B-BEB (or between two B-BEBs) is
called an I-tagged service interface. The interface between a B-BEB
or IB-BEB and a Backbone Core Bridge (BCB) is called a B-tagged
service interface.
<span class="grey">Balus, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
To accommodate the PBB components, the VPLS model defined in
[<a href="./rfc4664" title=""Framework for Layer 2 Virtual Private Networks (L2VPNs)"">RFC4664</a>] is extended as depicted in Figure 2.
+----------------------------------------+
| PBB-VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | |VPLS-1|------------
| | |==========|Fwdr |------------ PWs
+--+ | | Bridge ------------ |------------
|CE|-|-- | | +------+ |
+--+ | | Module | o |
| | | o |
| | (PBB | o |
| | bridge) | o |
| | | o |
+--+ | | | +------+ |
|CE|-|-- | ------------VPLS-n|-------------
+--+ | | |==========| Fwdr |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-------------------------|--------------+
LAN Emulation Interface
Figure 2: PBB-VPLS-Capable PE Model
The PBB module as defined in the [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] specification is expanded to
interact with VPLS Forwarders. The VPLS Forwarders are used in
[<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>] to build a PW mesh or a set of spoke PWs (Hierarchical VPLS
(H-VPLS) topologies). The VPLS instances are represented externally
in the MPLS context by a Layer 2 Forwarding Equivalence Class (L2FEC)
that binds related VPLS instances together. VPLS Signaling
advertises the mapping between the L2FEC and the PW labels and
implicitly associates the VPLS bridging instance to the VPLS
Forwarders [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>].
In the PBB-VPLS case, the backbone service instance in the
B-component space (B-VID) is represented in the backbone MPLS network
using a VPLS instance. In the same way as for the regular VPLS case,
existing signaling procedures are used to generate through PW labels
the linkage between VPLS Forwarders and the backbone service
instance.
Similarly, with the regular H-VPLS, another L2FEC may be used to
identify the customer service instance in the I-component space.
This will be useful, for example, to address the PBB-VPLS N-PE case
where H-VPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE.
<span class="grey">Balus, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
It is important to note that the PBB-VPLS solution inherits the PBB
service aggregation capability where multiple customer service
instances may be mapped to a backbone service instance. In the
PBB-VPLS case, this means multiple customer VPNs can be transported
using a single VPLS instance corresponding to the backbone service
instance, thus substantially reducing resource consumption in the
VPLS core.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Packet Walkthrough</span>
Since the PBB bridge module inherently performs forwarding, the PE
reference model of Figure 2 can be expanded as shown in Figure 3.
Furthermore, the B-component is connected via several virtual
interfaces to the PW Forwarder module. The function of the PW
Forwarder is defined in [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture"">RFC3985</a>]. In this context, the PW Forwarder
simply performs the mapping of the PWs to the virtual interface on
the B-component, without the need for any MAC lookup.
This simplified model takes full advantage of the PBB module -- where
all the [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] procedures, including C-MAC/B-MAC forwarding and PBB
encapsulation/decapsulation, take place -- and thus avoids the need
to specify any of these functions in this document.
Because of text-based graphics, Figure 3 only shows PWs on the
core-facing side; however, in the case of MPLS access with spoke PWs,
the PE reference model is simply extended to include the same PW
Forwarder function on the access-facing side. To avoid cluttering
the figure, but without losing any generality, the access-side PW
Forwarder (Fwdr) is not depicted.
<span class="grey">Balus, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
+------------------------------------------------+
| PBB-VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | | | |
| +------+ | ======== ---------
+--+ | | | | | | --------- PWs
|CE|-|-- | I- ==== ======== PW ---------
+--+ | | Comp | | | | Fwdr |
| +------+ | | | --------- PWs
| | B-Comp ======== ---------
| | | ^ | | |
| +------+ | | | +------+ |
+--+ | | I- | | OOOOOOOOOOOOOOOOOOOOOOOO B-tag
|CE|-|-- | Comp ==== | | | I/Fs
+--+ | | |^ | OOOOOOOOOOOOOOOOOOOOOOOO
| +------+| | | | |
| | +---------------+ | |
| | | |
+-----------|--------------------|---------------+
| |
Internal I-tag I/Fs Virtual Interfaces (I/Fs)
+---------------+ +--------------+
| C-MAC DA,SA | | PSN Header |
|---------------| |--------------|
| S-VID, C-VID | | PW Label |
|---------------| |--------------|
| Payload | | B-MAC DA,SA |
+---------------+ |--------------|
| PBB I-tag |
|--------------|
| C-MAC DA,SA |
|--------------|
| S-VID, C-VID |
|--------------|
| Payload |
+--------------+
Figure 3: Packet Walkthrough for PBB VPLS PE
In order to better understand the data-plane walkthrough, let us
consider the example of a PBB packet arriving over a Backbone
pseudowire (B-PW). The PSN header is used to carry the PBB
encapsulated frame over the backbone while the PW label will point to
the related Backbone Service Instance (B-SI), in the same way as for
regular VPLS. The PW label has in this case an equivalent role with
the backbone VLAN identifier on the PBB B-tagged interface.
<span class="grey">Balus, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
An example of the PBB packet for the regular Ethernet PW is depicted
on the right-hand side of Figure 3. The MPLS packet from the MPLS
core network is received by the PBB-VPLS PE. The PW Forwarder
function of the PE uses the PW label to derive the virtual
interface-id on the B-component, and then, after removing the PSN and
PW encapsulation, it passes the packet to the B-component. From
there on, the processing and forwarding are performed according to
[<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>], where bridging based on the Backbone MAC (B-MAC) Destination
Address (DA) is performed. This scenario results in one of the
following outcomes:
1. The packet is forwarded to a physical interface on the
B-component. In this case, the PBB Ethernet frame is forwarded
as is.
2. The packet is forwarded to a virtual interface on the B-component.
This is not typically the case, because of a single split-horizon
group within a VPLS instance; however, if there is more than one
split-horizon group, then such forwarding takes place. In this
case, the PW Forwarder module adds the PSN and PW labels before
sending the packet out.
3. The packet is forwarded toward the access side via one of the
I-tagged service interfaces connected to the corresponding
I-components. In this case, the I-component removes the B-MAC
header according to [<a href="#ref-PBB" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">PBB</a>] and bridges the packet using the
C-MAC DA.
If the destination B-MAC is an unknown MAC address or a Group MAC
address (multicast or broadcast), then the B-component floods the
packet to one or more of the three destinations described above.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Control Plane</span>
The control-plane procedures described in [<a href="./rfc6074" title=""Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)"">RFC6074</a>], [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>], and
[<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>] can be reused in a PBB-VPLS to set up the PW infrastructure
in the service provider and/or customer bridging space. This allows
porting the existing control-plane procedures (e.g., BGP
Auto-Discovery (BGP-AD), PW setup, VPLS MAC flushing, PW OAM) for
each domain.
<span class="grey">Balus, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Efficient Packet Replication in PBB VPLS</span>
The PBB VPLS architecture takes advantage of the existing VPLS
features addressing packet replication efficiency. The H-VPLS
hierarchy may be used in both customer and backbone service instances
to reduce the redundant distribution of packets over the core. IGMP
and PIM snooping may be applied on a "per customer service instance"
basis to control the distribution of the multicast traffic to
non-member sites.
[<a id="ref-IEEE-802.1Q">IEEE-802.1Q</a>] specifies the use of the Multiple MAC Registration
Protocol (MMRP) for flood containment in the backbone instances. The
same solution can be ported in the PBB-VPLS solution.
Further optimizations of the packet replication in PBB-VPLS are out
of the scope of this document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. PBB VPLS OAM</span>
The existing VPLS, PW, and MPLS OAM procedures may be used in each
customer service instance or backbone service instance to verify the
status of the related connectivity components.
PBB OAM procedures make use of the IEEE Ethernet Connectivity Fault
Management [<a href="#ref-CFM" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">CFM</a>] and ITU-T Y.1731 [<a href="#ref-Y.1731" title=""OAM functions and mechanisms for Ethernet based networks"">Y.1731</a>] tools in both I-components
and B-components.
Both sets of tools (PBB and VPLS) may be used for the combined
PBB-VPLS solution.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
No new security issues are introduced beyond those described in
[<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] and [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>].
<span class="grey">Balus, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC4761">RFC4761</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", <a href="./rfc4761">RFC 4761</a>, January 2007.
[<a id="ref-RFC4762">RFC4762</a>] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", <a href="./rfc4762">RFC 4762</a>, January 2007.
[<a id="ref-RFC6074">RFC6074</a>] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", <a href="./rfc6074">RFC 6074</a>, January 2011.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3985">RFC3985</a>] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.
[<a id="ref-RFC4664">RFC4664</a>] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", <a href="./rfc4664">RFC 4664</a>,
September 2006.
[<a id="ref-PBB">PBB</a>] Clauses 25 and 26 of "IEEE Standard for Local and
metropolitan area networks - Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks", IEEE
Std 802.1Q-REV, 2013.
[<a id="ref-PB">PB</a>] Clauses 15 and 16 of "IEEE Standard for Local and
metropolitan area networks - Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks", IEEE
Std 802.1Q-REV, 2013.
[<a id="ref-CFM">CFM</a>] CFM clauses of "IEEE Standard for Local and metropolitan
area networks - Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", IEEE Std 802.1Q-REV,
2013.
[<a id="ref-IEEE-802.1Q">IEEE-802.1Q</a>]
"IEEE Standard for Local and metropolitan area networks -
Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", IEEE Std 802.1Q-REV, 2013.
<span class="grey">Balus, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
[<a id="ref-Y.1731">Y.1731</a>] ITU-T Recommendation Y.1731, "OAM functions and mechanisms
for Ethernet based networks", July 2011.
[<a id="ref-RFC4026">RFC4026</a>] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", <a href="./rfc4026">RFC 4026</a>, March 2005.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Contributors</span>
The following people made significant contributions to this document:
Matthew Bocci
Alcatel-Lucent
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
EMail: matthew.bocci@alcatel-lucent.com
Raymond Zhang
Alcatel-Lucent
EMail: raymond.zhang@alcatel.com
Geraldine Calvignac
Orange
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: geraldine.calvignac@orange.com
John Hoffmans
KPN
Regulusweg 1
2516 AC Den Haag
The Netherlands
EMail: john.hoffmans@kpn.com
<span class="grey">Balus, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7041">RFC 7041</a> Extensions to VPLS PE Model for PBB November 2013</span>
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
EMail: ostokes@extremenetworks.com
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgments</span>
The authors would like to thank Wim Henderickx, Mustapha Aissaoui,
Dimitri Papadimitriou, Pranjal Dutta, Jorge Rabadan, Maarten Vissers,
and Don Fedyk for their insightful comments and probing questions.
Authors' Addresses
Florin Balus (editor)
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA 94043
USA
EMail: florin.balus@alcatel-lucent.com
Ali Sajassi (editor)
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: sajassi@cisco.com
Nabil Bitar (editor)
Verizon
60 Sylvan Road
Waltham, MA 02145
USA
EMail: nabil.n.bitar@verizon.com
Balus, et al. Informational [Page 15]
</pre>
|
