File: rfc7080.html

package info (click to toggle)
doc-rfc 20201128-1
  • links: PTS, VCS
  • area: non-free
  • in suites: bullseye
  • size: 1,307,124 kB
file content (1453 lines) | stat: -rw-r--r-- 74,365 bytes parent folder | download | duplicates (2)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
<pre>Internet Engineering Task Force (IETF)                        A. Sajassi
Request for Comments: 7080                                      S. Salam
Category: Informational                                            Cisco
ISSN: 2070-1721                                                 N. Bitar
                                                                 Verizon
                                                                F. Balus
                                                          Nuage Networks
                                                           December 2013


          <span class="h1">Virtual Private LAN Service (VPLS) Interoperability</span>
                     <span class="h1">with Provider Backbone Bridges</span>

Abstract

   The scalability of Hierarchical Virtual Private LAN Service (H-VPLS)
   with Ethernet access networks (<a href="./rfc4762">RFC 4762</a>) can be improved by
   incorporating Provider Backbone Bridge functionality in the VPLS
   access.  Provider Backbone Bridging has been standardized as IEEE
   802.1ah-2008.  It aims to improve the scalability of Media Access
   Control (MAC) addresses and service instances in Provider Ethernet
   networks.  This document describes different interoperability
   scenarios where Provider Backbone Bridge functionality is used in
   H-VPLS with Ethernet or MPLS access network to attain better
   scalability in terms of number of customer MAC addresses and number
   of service instances.  The document also describes the scenarios and
   the mechanisms for incorporating Provider Backbone Bridge
   functionality within H-VPLS with existing Ethernet access and
   interoperability among them.  Furthermore, the document discusses the
   migration mechanisms and scenarios by which Provider Backbone Bridge
   functionality can be incorporated into H-VPLS with existing MPLS
   access.

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&nbsp;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/rfc7080">http://www.rfc-editor.org/info/rfc7080</a>.



<span class="grey">Sajassi, et al.               Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


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>. Terminology .....................................................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. Applicability ...................................................<a href="#page-5">5</a>
   <a href="#section-4">4</a>. H-VPLS with Homogeneous PBBN Access .............................<a href="#page-6">6</a>
      <a href="#section-4.1">4.1</a>. Service Interfaces and Interworking Options ................<a href="#page-8">8</a>
      <a href="#section-4.2">4.2</a>. H-VPLS with PBBN Access: Type I Service Interface .........<a href="#page-10">10</a>
      <a href="#section-4.3">4.3</a>. H-VPLS with PBBN Access: Type II Service Interface ........<a href="#page-11">11</a>
   <a href="#section-5">5</a>. H-VPLS with Mixed PBBN Access and PBN Access ...................<a href="#page-14">14</a>
      <a href="#section-5.1">5.1</a>. H-VPLS with Mixed PBBN and PBN Access: Modified PBN PE ....<a href="#page-15">15</a>
      <a href="#section-5.2">5.2</a>. H-VPLS with Mixed PBBN and PBN Access: Regular PBN PE .....<a href="#page-16">16</a>
   <a href="#section-6">6</a>. H-VPLS with MPLS Access ........................................<a href="#page-17">17</a>
      <a href="#section-6.1">6.1</a>. H-VPLS with MPLS Access: PBB U-PE .........................<a href="#page-17">17</a>
      <a href="#section-6.2">6.2</a>. H-VPLS with MPLS Access: PBB N-PE .........................<a href="#page-19">19</a>
   <a href="#section-7">7</a>. H-VPLS with MPLS Access: PBB Migration Scenarios ...............<a href="#page-21">21</a>
      <a href="#section-7.1">7.1</a>. 802.1ad Service Frames over VPLS Core .....................<a href="#page-21">21</a>
      <a href="#section-7.2">7.2</a>. PBB Service Frames over VPLS Core .........................<a href="#page-22">22</a>
      <a href="#section-7.3">7.3</a>. Mixed 802.1ad and PBB over VPLS Core ......................<a href="#page-23">23</a>
   <a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-24">24</a>
   <a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-24">24</a>
   <a href="#section-10">10</a>. References ....................................................<a href="#page-24">24</a>
      <a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-24">24</a>
      <a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-25">25</a>












<span class="grey">Sajassi, et al.               Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The scalability of Hierarchical Virtual Private LAN Service (H-VPLS)
   with Ethernet access networks [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>] can be improved by
   incorporating Provider Backbone Bridge (PBB) functionality in the
   VPLS access.  Provider Backbone Bridging has been standardized as
   IEEE 802.1ah-2008 [<a href="#ref-802.1ah" title="&quot;IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges&quot;">802.1ah</a>], which is an amendment to IEEE 802.1Q to
   improve the scalability of Media Access Control (MAC) addresses and
   service instances in Provider Ethernet networks.  This document
   describes interoperability scenarios where IEEE 802.1ah functionality
   is used in H-VPLS with Ethernet or MPLS access network to attain
   better scalability in terms of the number of customer MAC addresses
   and the number of services.

   This document also covers the interoperability scenarios for
   deploying H-VPLS with Provider Backbone Bridging Ethernet access when
   other types of access networks are deployed, including existing
   802.1ad Ethernet and MPLS access in either single or multiple service
   domains.  Furthermore, the document explores the scenarios by which
   an operator can gradually migrate an existing H-VPLS network to
   Provider Backbone Bridging over VPLS.

   <a href="#section-2">Section 2</a> gives a quick terminology reference and <a href="#section-3">Section 3</a>
   highlights the applicability of Provider Backbone Bridging
   interoperation with VPLS.  <a href="#section-4">Section 4</a> describes H-VPLS with
   homogeneous Provider Backbone Bridge Access Network.  <a href="#section-5">Section 5</a>
   discusses H-VPLS with mixed 802.1ah/802.1ad access.  <a href="#section-6">Section 6</a>
   focuses on Provider Backbone Bridging in H-VPLS with MPLS Access
   Network including PBB function on U-PE and on N-PE variants.
   Finally, <a href="#section-7">Section 7</a> describes gradual migration scenarios from
   existing H-VPLS to Provider Backbone Bridging over H-VPLS.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   802.1ad: IEEE specification for "QinQ" encapsulation and bridging of
      Ethernet frames.

   802.1ah: IEEE specification for "MAC tunneling" encapsulation and
      bridging of frames across a Provider Backbone Bridged Network
      (PBBN).

   B-BEB: A backbone edge bridge positioned at the edge of a PBBN.  It
      contains a B-component that supports bridging in the provider
      backbone based on B-MAC and B-TAG information.

   B-MAC: The backbone source or destination MAC address fields defined
      in the 802.1ah provider MAC encapsulation header.




<span class="grey">Sajassi, et al.               Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   BCB: A backbone core bridge running in the core of a provider
      backbone bridged network.  It bridges frames based on B-TAG
      information just as an 802.1ad provider bridge will bridge frames
      based on a Service VLAN (S-VLAN) identifier.

   B-Component: The backbone component of a Provider Backbone edge
      bridge as defined in [<a href="#ref-802.1ah" title="&quot;IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges&quot;">802.1ah</a>].

   BEB: A backbone edge bridge positioned at the edge of a provider
      backbone bridged network.  It can contain an I-component,
      B-component, or both.

   B-MACs: Backbone MAC addresses -- outer MAC addresses of a PBB-
      encapsulated frame.

   B-TAG: A field defined in the 802.1ah 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: This is the interface between a BEB and
      BCB in a PBB network.  Frames passed through this interface
      contain a B-TAG field.

   B-VID: This is the specific VLAN identifier carried inside a B-TAG

   C-MACs: Customer MAC addresses are the inner MAC addresses of a PBB-
      encapsulated frame.

   H-VPLS: Hierarchical Virtual Private LAN Service.

   I-component: A bridging component contained in a backbone edge bridge
      that bridges in the customer space (customer MAC addresses,
      S-VLAN).

   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, S-VLAN IDs) and a
      B-component for bridging the provider's backbone space (B-MAC,
      B-TAG).

   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, S-VLAN IDs).

   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".



<span class="grey">Sajassi, et al.               Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   I-TAG: A field defined in the 802.1ah provider MAC encapsulation
      header that conveys the service instance information (I-SID)
      associated with the frame.

   I-Tagged Service Interface: This is the interface defined between the
      I-component and B-component inside an IB-BEB or between two
      B-BEBs.  Frames passed through this interface contain an I-TAG
      field.

   N-PE: Network-facing Provider Edge

   PBB: Provider Backbone Bridge

   PBBN: Provider Backbone Bridged Network

   PBN: Provider Bridged Network.  A network that employs 802.1ad (QinQ)
      technology.

   S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
      conveys the Service VLAN (S-VLAN) identifier information.

   S-Tagged Service Interface: This 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

   U-PE: User-facing Provider Edge

   VPLS: Virtual Private LAN Service

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Applicability</span>

   [<a id="ref-RFC4762">RFC4762</a>] describes a two-tier hierarchical solution for VPLS for the
   purpose of improved pseudowire (PW) scalability.  This improvement is
   achieved by reducing the number of PE devices connected in a full-
   mesh topology through connecting CE devices via the lower-tier access
   network, which in turn is connected to the top-tier core network.
   [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>] describes two types of H-VPLS network topologies -- one
   with an MPLS access network and another with an IEEE 802.1ad (QinQ)
   Ethernet access network.  In both types of H-VPLS, the learning and
   forwarding of MAC addresses is based on customer MAC addresses
   (C-MACs), which poses scalability issues as the number of VPLS
   instances (and thus C-MACs) increases.  Furthermore, since a set of
   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



<span class="grey">Sajassi, et al.               Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   (in terms of PW manageability and troubleshooting) as the number of
   customer service instances grows.

   In addition to the above, H-VPLS with an 802.1ad Ethernet access
   network has another scalability issue in terms of the maximum number
   of service instances that can be supported in the access network as
   described in [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>].  Since the number of provider VLANs (S-VLANs)
   is limited to 4094 and each S-VLAN represents a service instance in
   an 802.1ad network, then the maximum number of service instances that
   can be supported is 4094.  These issues are highlighted in [<a href="./rfc6246" title="&quot;Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges&quot;">RFC6246</a>].

   This document describes how IEEE 802.1ah (aka Provider Backbone
   Bridges) can be integrated with H-VPLS to address these scalability
   issues.  In the case of H-VPLS with 802.1ah Ethernet access, the
   solution results in better scalability in terms of both number of
   service instances and number of C-MACs in the Ethernet access network
   and the VPLS core network, as well as number of PWs in VPLS core
   network.  And in the case of H-VPLS with MPLS access, Provider
   Backbone Bridging functionality can be used at the U-PE or N-PE,
   which results in reduction of customer MAC addresses and the number
   of PWs in the VPLS core network.

   The interoperability scenarios depicted in this document fall into
   the following two categories:

   -  Scenarios in which Provider Backbone Bridging seamlessly works
      with current VPLS implementations (e.g., <a href="#section-4.2">Section 4.2</a>).

   -  Scenarios in which VPLS-PE implementations need to be upgraded in
      order to work with Provider Backbone Bridging (e.g., Sections <a href="#section-4.3">4.3</a>
      and 5.1).

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  H-VPLS with Homogeneous PBBN Access</span>

   PBBN access offers MAC-address-table scalability for H-VPLS PE nodes.
   This is due to the MAC tunneling encapsulation scheme of PBB, which
   only exposes the provider's own MAC addresses to PE nodes (B-MACs of
   Provider's PBB-capable devices in the access network), as opposed to
   customers' MAC addresses in conventional H-VPLS with MPLS or 802.1ad
   access.

   PBBN access also offers service-instance scalability when compared to
   H-VPLS with 802.1Q/802.1ad access networks.  This is due to the new
   24-bit service identifier (I-SID) used in PBB encapsulation, which
   allows up to 16M services per PBB access network, compared to 4094
   services per 802.1Q/802.1ad access network.





<span class="grey">Sajassi, et al.               Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   Another important advantage of PBBN access is that it offers clear
   separation between the service layer (represented by I-SID) and the
   network layer (represented by B-VLAN).  B-VLANs segregate a PBB
   access network into different broadcast domains and possibly unique
   spanning-tree topologies, with each domain being able to carry
   multiple services (i.e., I-SIDs).  In 802.1ad access networks, the
   network and service layers are the same (represented by S-VLAN).

   This separation allows the provider to manage and optimize the PBB
   access network topology independent of the number of service
   instances that are supported.

   In this section and those following, we look into different flavors
   of H-VPLS with PBBN access.  This section discusses the case in which
   H-VPLS is deployed with homogeneous PBBN access.  <a href="#section-5">Section 5</a> describes
   the case in which at least one of the access networks has PBN access
   (QinQ/802.1ad) while the others are PBBNs.

   On a macro scale, a network that employs H-VPLS with PBBN access can
   be represented as shown in Figure 1 below.

                           +--------------+
                           |              |
           +---------+     |    IP/MPLS   |    +---------+
   +----+  |         |   +----+        +----+  |         |  +----+
   | CE |--|         |   |VPLS|        |VPLS|  |         |--| CE |
   +----+  |  PBBN   |---| PE |        | PE |--|  PBBN   |  +----+
   +----+  | 802.1ah |   +----+        +----+  | 802.1ah |  +----+
   | CE |--|         |     |   Backbone   |    |         |--| CE |
   +----+  +---------+     +--------------+    +---------+  +----+

                    Figure 1: H-VPLS with PBBN Access

   In the context of PBBN and H-VPLS interoperability, "I-SID Domain"
   and "B-VLAN Domain" can be defined as follows:

   -  "I-SID Domain" refers to a network administrative boundary under
      which all the PBB BEBs and VPLS-PE devices use the same I-SID
      space.  That is, the I-SID assignment is carried out by the same
      administration.  This effectively means that a given service
      instance has the same I-SID designation on all devices within an
      I-SID Domain.

   -  "B-VLAN Domain" refers to a network administrative boundary under
      which all the PBB BEBs and VPLS-PE devices employ consistent I-SID
      to B-VLAN bundling.  For example, the grouping of I-SIDs to
      B-VLANs is the same in that domain.  Although the two B-VLANs in
      two PBBNs that represent the same group of I-SIDs do not need to



<span class="grey">Sajassi, et al.               Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


      use the same B-VID value, in practice, they often use the same
      value because once the I-SID grouping is made identical in two
      PBBNs.  It is very easy to make the values of the corresponding
      B-VIDs identical also.

   Consequently, three different kinds of "Service Domains" are defined
   in the following manner:

   -  Tightly Coupled Service Domain - Different PBBNs' access belonging
      to the same I-SID Domain and B-VLAN Domain.  However, the network
      control protocols (e.g., xSTP) run independently in each PBBN
      access.

   -  Loosely Coupled Service Domain - Different PBBNs' access belonging
      to the same I-SID Domain.  However, each PBBN access maintains its
      own independent B-VLAN Domain.  Again, the network control
      protocols (e.g., xSTP) run independently in each PBBN access.

   -  Different Service Domain - In this case, each PBBN access
      maintains its own independent I-SID Domain and B-VLAN Domain, with
      independent network control protocols (e.g., xSTP) in each PBBN
      access.

   In general, correct service connectivity spanning networks in a
   Tightly Coupled Service Domain can be achieved via B-VID mapping
   between the networks (often even without B-VID translation).
   However, correct service connectivity spanning networks in a Loosely
   Coupled Service Domain requires I-SID to B-VID remapping (i.e.,
   unbundling and rebundling of I-SIDs into B-VIDs).  Furthermore,
   service connectivity spanning networks in Different Service Domains
   requires both I-SID translation and I-SID to B-VID remapping.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Service Interfaces and Interworking Options</span>

   Customer devices will interface with PBBN edge bridges using existing
   Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad.  At the
   PBBN edge, C-MAC frames are encapsulated in a PBB header that
   includes service provider source and destination MAC addresses
   (B-MACs) and are bridged up to the VPLS-PE.  The PBB-encapsulated
   C-MAC frame is then injected into the VPLS backbone network,
   delivered to the remote VPLS-PE node(s), and switched onto the remote
   PBBN access.  From there, the PBBN bridges the encapsulated frame to
   a PBBN edge bridge where the PBB header is removed and the customer
   frame is sent to the customer domain.







<span class="grey">Sajassi, et al.               Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   Interoperating between PBBN devices and VPLS-PE nodes can leverage
   the BEB functions already defined in [<a href="#ref-802.1ah" title="&quot;IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges&quot;">802.1ah</a>].  When I-SID
   visibility is required at the VPLS-PE nodes, a new service interface
   based on I-SID tag will need to be defined.

   Moreover, by mapping a bridge domain (e.g., B-VLAN) to a VPLS
   instance, and bundling multiple end-customer service instances
   (represented by I-SID) over the same bridge domain, service providers
   will be able to significantly reduce the number of full-mesh PWs
   required in the core.  In this case, I-SID visibility is not required
   on the VPLS-PE and the I-SID will serve as the means of
   multiplexing/de-multiplexing individual service instances in the PBBN
   over a bundle (e.g., B-VLAN).

   When I-SID visibility is expected across the service interface at the
   VPLS-PE, the VPLS-PE can be considered to offer service-level
   interworking between PBBN access and the IP/MPLS core.  Similarly,
   when the PE is not expected to have visibility of the I-SID at the
   service interface, the VPLS-PE can be considered to offer network-
   level interworking between PBBN access and the MPLS core.

   A VPLS-PE is always part of the IP/MPLS core, and it may optionally
   participate in the control protocols (e.g., xSTP) of the access
   network.  When connecting to a PBBN access, the VPLS-PE needs to
   support one of the following two types of service interfaces:

      -  Type I: B-Tagged Service Interface with B-VID as Service
         Delimiter

   The PE connects to a Backbone Core Bridge (BCB) in the PBBN access.
   The handoff between the BCB and the PE is B-Tagged PBB-encapsulated
   frames.  The PE is transparent to PBB encapsulations and treats these
   frames as 802.1ad frames since the B-VID EtherType is the same as the
   S-VID EtherType.  The PE does not need to support PBB functionality.
   This corresponds to conventional VPLS-PEs' tagged service interface.
   When using Type I service interface, the PE needs to support either
   raw mode or tagged mode Ethernet PW.  Type I service interface is
   described in detail in <a href="#section-4.2">Section 4.2</a>.

      -  Type II: I-Tagged Service Interface with I-SID as Service
         Delimiter

   The PE connects to a B-BEB (backbone edge bridge with B-component) in
   the PBBN access.  The PE itself also supports the B-BEB functionality
   of [<a href="#ref-802.1ah" title="&quot;IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges&quot;">802.1ah</a>].  The handoff between the B-BEB in the PBBN access and
   the PE is an I-Tagged PBB-encapsulated frame.  With Type II service





<span class="grey">Sajassi, et al.               Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   interface, the PE supports the existing raw mode and tagged mode PW
   types.  Type II service interface is described in detail in <a href="#section-4.3">Section</a>
   <a href="#section-4.3">4.3</a>.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  H-VPLS with PBBN Access: Type I Service Interface</span>

   This is a B-Tagged service interface with B-VID as service delimiter
   on the VPLS-PE.  It does not require any new functionality on the
   VPLS-PE.  As shown in Figure 2, the PE is always part of the IP/MPLS
   core.  The PE may also be part of the PBBN access (e.g., VPLS-PE on
   right side of Figure 2) by participating in network control protocols
   (e.g., xSTP) of the PBBN access.

        PBBN Access       IP/MPLS Core      PBBN Access
                        +--------------+
        +---------+     |              | +---------------+
        |         |    +----+          | |               |
        |      +---+   |VPLS|   +-+    | |    +---+      |
        |      |BCB|---| PE |---|P|    | |    |BCB|      |
        |      +---+  /+----+  /+-+   | |   /+---+      |
        |+---+    |  / +----+ /     +----+ /       +---+|
   +--+ ||IB-| +---+/  |VPLS|/  +-+  |VPLS|/  +---+ |IB-|| +--+
   |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE|
   +--+ |+---+ +---+ ^ +----+   +-+  +----+ ^ +---+ +---+| +--+
        |         |  |  |              | |  |            |
        +---------+  |  |              | +--|------------+
                     |  +--------------+    |
                     |                      |
                   Type I                  Type I

     Figure 2: H-VPLS with PBBN Access and Type I Service Interface

   Type I service interface is applicable to networks with Tightly
   Coupled Service Domains, where both I-SID Domains and B-VLAN Domains
   are the same across all PBBN access networks.

   The BCB and the VPLS-PE will exchange PBB-encapsulated frames that
   include source and destination B-MACs, a B-VID, and an I-SID.  The
   service delimiter, from the perspective of the VPLS-PE, is the B-VID;
   in fact, this interface operates exactly as a current 802.1Q/ad
   interface into a VPLS-PE does today.  With Type I service interface,
   the VPLS-PE can be considered to provide network-level interworking
   between PBBN and MPLS domains, since VPLS-PE does not have visibility
   of I-SIDs.

   The main advantage of this service interface, when compared to other
   types, is that it allows the service provider to save on the number
   of full-mesh PWs required in the core.  This is primarily because



<span class="grey">Sajassi, et al.               Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   multiple service instances (I-SIDs) are bundled over a single full-
   mesh PW corresponding to a bridge domain (e.g., B-VID), instead of
   requiring a dedicated full-mesh PW per service instance.  Another
   advantage is the MAC address scalability in the core since the core
   is not exposed to C-MACs.

   The disadvantage of this interface is the comparably excessive
   replication required in the core: since a group of service instances
   share the same full-mesh of PWs, an unknown unicast, multicast, or
   broadcast on a single service instance will result in a flood over
   the core.  This, however, can be mitigated via the use of flood
   containment per I-SID (B-MAC multicast pruning).

   Three different modes of operation are supported by Type I service
   interface:

   -  Port Mode: All traffic over an interface in this mode is mapped to
      a single VPLS instance.  Existing PW signaling and Ethernet raw
      mode (0x0005) PW type, defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], are
      supported.

   -  VLAN Mode: all traffic associated with a particular VLAN
      identified by the B-VID is mapped to a single VPLS instance.
      Existing PW signaling and Ethernet raw mode (0x0005) PW type,
      defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], are supported.

   -  VLAN Bundling Mode: all traffic associated with a group or range
      of VLANs or B-VIDs is mapped to a single VPLS instance.  Existing
      PW signaling and Ethernet raw mode (0x0005) PW type, defined in
      [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], are supported.

   For the VLAN mode, it is also possible to use Ethernet tagged mode
   (0x0004) PW, as defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], for
   interoperability with equipment that does not support raw mode.  The
   use of raw mode is recommended to be the default though.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  H-VPLS with PBBN Access: Type II Service Interface</span>

   This is an I-Tagged service interface with I-SID as service delimiter
   on the VPLS-PE.  It requires the VPLS-PE to include the B-component
   of PBB BEB for I-SID processing in addition to the capability to map
   an I-SID Bundle to a VPLS instance.  As shown in Figure 3, the PE is
   always part of the IP/MPLS core and connects to one or more B-BEBs in
   the PBBN access.







<span class="grey">Sajassi, et al.               Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


        PBBN Access      IP/MPLS Core      PBBN Access
                       +--------------+
        +---------+    |              |    +---------+
        |         |    |              |    |         |
        |      +---+  +-----+         |    |  +---+  |
        |      |B- |  |PE w/| +-+     |    |  |BCB|  |
        |      |BEB|--|B-BEB|-|P|     |    |  +---+  |
        |      +---+ /+-----+ +-+     |    | /   |   |
        |+---+ +---+/ +-----+/    +-----+ +---+ +---+|
   +--+ ||IB-| |B- |  |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
   |CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
   +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
        |         |  |  |             |  | |         |
        +---------+  |  |             |  | +---------+
                     |  +-------------+  |
                     |                   |
                 Type II             Type II

   Figure 3: H-VPLS with PBBN Access and Type II Service Interface

   Type II service interface is applicable to Loosely Coupled Service
   Domains and Different Service Domains.  B-VLAN Domains can be
   independent and the B-VID is always locally significant in each PBBN
   access: it does not need to be transported over the IP/MPLS core.
   Given the above, it should be apparent that Type II service interface
   is applicable to Tightly Coupled Service Domains as well.

   By definition, the B-BEB connecting to the VPLS-PE will remove any
   B-VLAN tags for frames exiting the PBBN access.  The B-BEB and
   VPLS-PE will exchange PBB-encapsulated frames that include source and
   destination B-MACs and an I-SID.  The service delimiter, from the
   perspective of the VPLS-PE, is the I-SID.  Since the PE has
   visibility of I-SIDs, the PE provides service-level interworking
   between PBBN access and IP/MPLS core.

   Type II service interface may operate in I-SID Bundling Mode: all
   traffic associated with a group or range of I-SIDs is mapped to a
   single VPLS instance.  The PE maintains a mapping of I-SIDs to a PE
   local bridge domain (e.g., B-VID).  The VPLS instance is then
   associated with this bridge domain.  With Loosely Coupled service
   Domains, no I-SID translation needs to be performed.  Type II Service
   interface also supports Different Service Domains in this mode, since
   the B-BEB link in the PE connecting to the local PBBN can perform the
   translation of PBBN-specific I-SID to a local I-SID within the
   IP/MPLS core, which may then be translated to the other PBBN-specific
   I-SID on the egress PE.  Such translation can also occur in the B-BEB
   of PBBN access.  Existing PW signaling and Ethernet raw mode
   (0x0005), defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], is supported.  It is



<span class="grey">Sajassi, et al.               Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   also possible to use a tagged mode (0x0004) PW for purpose of
   interoperability with equipment that does not support raw mode.

   Type II service interface provides operators with the flexibility to
   trade off PW state for multicast flooding containment, since a full-
   mesh of PWs can be set up:

   a. per I-SID,
   b. per group of I-SIDs, or
   c. for all I-SIDs.

   For (a) and (b), the advantage that Type II service interface has
   compared to Type I is that it can reduce replication in the core
   without the need for a mechanism that provides flood containment per-
   I-SID (B-MAC multicast pruning).  This is mainly due to the increased
   segregation of service instances over disjoint full meshes of PWs.
   For (c), both Type II and Type I service interfaces are at par with
   regard to flood containment.

   For (a) and (b), the disadvantage of this service interface, compared
   to Type I, is that it may require a larger number of full-mesh PWs in
   the core.  For (c), both Type II and Type I service interfaces are at
   par with regard to PW state.  However, for all three scenarios, the
   number of full-mesh PWs can still be fewer than the number required
   by H-VPLS without PBBN access, since an I-SID can multiplex many
   S-VLANs.

   It is expected that this interface type will be used for customers
   with significant multicast traffic (but without multicast pruning
   capability in the VPLS-PE) so that a separate VPLS instance is set up
   per group of customers with similar geographic locality (per I-SID
   group).

   Note: Port mode is not called out in Type II service interface since
   it requires the mapping of I-SIDs to be identical on different
   I-Tagged interfaces across VPLS network.  If this is indeed the case,
   Port mode defined in Type I service interface (<a href="#section-4.2">Section 4.2</a>) can be
   used.













<span class="grey">Sajassi, et al.               Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  H-VPLS with Mixed PBBN Access and PBN Access</span>

   It is foreseeable that service providers will want to interoperate
   their existing Provider Bridged Networks (PBNs) with Provider
   Backbone Bridged Networks (PBBNs) over H-VPLS.  Figure 4 below shows
   the high-level network topology.

                           +--------------+
                           |              |
           +---------+     |    IP/MPLS   |    +---------+
   +----+  |         |   +----+        +----+  |         |  +----+
   | CE |--|   PBN   |   |VPLS|        |VPLS|  |         |--| CE |
   +----+  |  (QinQ) |---| PE1|        | PE2|--|  PBBN   |  +----+
   +----+  | 802.1ad |   +----+        +----+  | 802.1ah |  +----+
   | CE |--|         |     |   Backbone   |    |         |--| CE |
   +----+  +---------+     +--------------+    +---------+  +----+

       Figure 4: H-VPLS with Mixed PBN and PBBN Access Networks

   Referring to Figure 4 above, two possibilities come into play
   depending on whether the interworking is carried out at PE1 or PE2.
   These are described in the following subsections.





























<span class="grey">Sajassi, et al.               Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  H-VPLS with Mixed PBBN and PBN Access: Modified PBN PE</span>

   As shown in Figure 5, the operation of VPLS-PE2 (connecting to the
   PBBN access on the right) is no different from what was discussed in
   <a href="#section-4">Section 4</a>.  Type II service interface, as discussed in the above
   section, is applicable.  It is the behavior of VPLS-PE1 (connecting
   to the PBN access on the left) that is the focus of this section.

         PBN Access       IP/MPLS Core      PBBN Access
          (802.1ad)     +--------------+     (802.1ah)
                        |              |    +---------+
         +---------+    |              |    |         |
         |         |   +-----+         |    |  +---+  |
         |      +---+  |PE w/| +-+     |    |  |BCB|  |
         |      |PCB|--|IBBEB|-|P|     |    |  +---+  |
         |      +---+ /+-----+ +-+     |    | /   |   |
         |         | / +-----+/    +-----+ +---+ +---+|
    +--+ |+---+ +---+  |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
    |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
    +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
         |         |  |  |PE1       PE2|  | |         |
         +---------+  |  |             |  | +---------+
                      |  +-------------+  |
                      |                   |
                  S-Tagged           Type II (I-Tagged)

   Figure 5: H-VPLS with Mixed PBN and PBBN Access: Modified PBN PE

   Some assumptions made for this topology include:

   -  CE is directly connected to PBBN via S-Tagged or port-based
      interface.

   -  I-SID in PBBN access represents the same customer as S-VID in PBN
      access.

   -  At S-Tagged service interface of PE with IB-BEB functionality
      (e.g., PE1 in Figure 5), the only viable service is 1:1 mapping of
      S-VID to I-SID.  However, towards the core network side, the same
      PE can support I-SID bundling into a VPLS instance.

   -  PE1 participates in the local I-SID Domain of the IP/MPLS core so
      the model accommodates for the rest of the PBB network any of the
      three domain types described in <a href="#section-4">Section 4</a> -- Tightly Coupled,
      Loosely Coupled, and Different Service Domains.






<span class="grey">Sajassi, et al.               Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   -  For ease of provisioning in these disparate access networks, it is
      recommended to use the same I-SID Domain among the PBBN access
      networks and the PEs with IB-BEB functionality (those connecting
      to PBN).

   This topology operates in I-SID Bundling Mode: at a PE connecting to
   PBN access, each S-VID is mapped to an I-SID and subsequently a group
   of I-SIDs is mapped to a VPLS instance.  Similarly, at a PE
   connecting to PBBN access, each group of I-SIDs is mapped to a VPLS
   instance.  Similar to Type II service interface, no I-SID translation
   is performed for the I-SID bundling case.  Existing PW signaling and
   Ethernet raw mode (0x0005) PW type, defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and
   [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], are supported.  It is possible to use tagged mode (0x0004)
   PW for backward compatibility as well.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  H-VPLS with Mixed PBBN and PBN Access: Regular PBN PE</span>

   As shown in Figure 6, the operation of VPLS-PE1 (connecting to the
   PBN access on the left) is no different from existing VPLS-PEs.  It
   is the behavior of VPLS-PE2 (connecting to the PBBN access on the
   right) that is the focus of this section.

         PBN Access       IP/MPLS Core      PBBN Access
          (802.1ad)     +--------------+     (802.1ah)
                        |              |    +---------+
         +---------+    |              |    |         |
         |         |   +-----+         |    |  +---+  |
         |      +---+  |  PE | +-+     |    |  |BCB|  |
         |      |PCB|--|     |-|P|     |    |  +---+  |
         |      +---+ /+-----+ +-+     |    | /   |   |
         |         | / +-----+/    +-----+ +---+ +---+|
    +--+ |+---+ +---+  |  PE | +-+ |PE w/| |B- | |IB-|| +--+
    |CE|-||PEB|-|PCB|--|     |-|P|-|IBBEB|-|BEB| |BEB|--|CE|
    +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
         |         |  |  |PE1       PE2|  | |         |
         +---------+  |  |             |  | +---------+
                      |  +-------------+  |
                      |                   |
                  S-Tagged           Type II (I-Tagged)

   Figure 6: H-VPLS with Mixed PBN and PBBN Access: Regular PBN PE

   Some assumptions made for this topology include:

   -  The CE is directly connected to the PBBN access via an S-Tagged or
      port-based Interface.





<span class="grey">Sajassi, et al.               Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   -  The I-SID in the PBBN access represents the same customer as the
      S-VID in the PBN access.

   -  There is 1:1 mapping between the I-SID and the VPLS instance.

   -  At the S-Tagged service interface of the PE connecting to PBN
      (e.g., PE1 in Figure 6), the PE only provides 1:1 mapping of S-VID
      to the VPLS instance.  S-VID bundling is not a viable option since
      it does not correspond to anything in the PBBN access.

   -  The PE connecting to the PBBN access (e.g., PE2 in Figure 6),
      supports IB-BEB functionality and the I-component is connected to
      the VPLS Forwarder (i.e., the I-component faces the IP/MPLS core
      whereas the B-component faces the PBBN access network).  One or
      more I-SIDs can be grouped into a B-VID in the PBBN access.

   -  Since C-VID grouping in different PBBN access networks must be
      consistent, it is assumed that same I-SID Domain is used across
      these PBBN access networks.

   Unlike the previous case, I-SID bundling mode is not supported in
   this case.  This is primarily because the VPLS core operates in the
   same manner as today.  The PE with IB-BEB functionality connecting to
   PBBN access performs the mapping of each VPLS instance to an I-SID
   and one or more of these I-SIDs may be mapped onto a B-VID within the
   PBBN access network.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  H-VPLS with MPLS Access</span>

   In this section, the case of H-VPLS with MPLS access network is
   discussed.  The integration of PBB functionality into VPLS-PE for
   such access networks is described to improve the scalability of the
   network in terms of the number of MAC addresses and service instances
   that are supported.

   For this topology, it is possible to embed PBB functionality in
   either the U-PE or the N-PE.  Both of these cases are described in
   the following subsections.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  H-VPLS with MPLS Access: PBB U-PE</span>

   As stated earlier, the objective for incorporating PBB function at
   the U-PE is to improve the scalability of H-VPLS networks in terms of
   the number of MAC addresses and service instances that are supported.

   In current H-VPLS, the N-PE must learn customer MAC addresses
   (C-MACs) of all VPLS instances in which it participates.  This can
   easily add up to hundreds of thousands or even millions of C-MACs at



<span class="grey">Sajassi, et al.               Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   the N-PE.  When the U-PE performs PBB encapsulation, the N-PE only
   needs to learn the MAC addresses of the U-PEs, which is a significant
   reduction.  Furthermore, when PBB encapsulation is used, many I-SIDs
   are multiplexed within a single bridge domain (e.g., B-VLAN).  If the
   VPLS instance is set up per B-VLAN, then one can also achieve a
   significant reduction in the number of full-mesh PWs.  It should be
   noted that this reduction in full-mesh PWs comes at the cost of
   potentially increased replication over the full-mesh of PWs: customer
   multicast and/or broadcast frames are effectively broadcasted within
   the B-VLAN.  This may result in additional frame replication because
   the full-mesh PWs corresponding to a B-VLAN are most likely bigger
   than the full-mesh PWs corresponding to a single I-SID.  However,
   flood containment per I-SID (B-MAC multicast pruning) can be used to
   remedy this drawback and have multicast traffic replicated
   efficiently for each customer (i.e., for each I-SID).

   Figure 7 below illustrates the scenario for H-VPLS with MPLS access.
   As illustrated, customer networks or hosts (CE) connect into the U-PE
   nodes using standard Ethernet interfaces [<a href="#ref-802.1D-REV" title="&quot;IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges&quot;">802.1D-REV</a>], [<a href="#ref-802.1Q" title="&quot;IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks&quot;">802.1Q</a>], or
   [<a href="#ref-802.1ad" title="&quot;IEEE Standard for and metropolitan area networks -- Virtual Bridged Local Area Networks -- Provider Bridges&quot;">802.1ad</a>].  The U-PE is connected upstream to one or more VPLS N-PE
   nodes by MPLS PWs (per VPLS instance).  These, in turn, are connected
   via a full mesh of PWs (per VPLS instance) traversing the IP/MPLS
   core.  The U-PE is outfitted with PBB Backbone Edge Bridge (BEB)
   functions where it can encapsulate/decapsulate customer MAC frames in
   provider B-MACs and perform I-SID translation if needed.

        PBB                                                PBB
        BEB                  +----------+                  BEB
         |                   |          |                   |
         |   +-----------+   |    IP    |   +-----------+   |
         |   | MPLS      |   |   MPLS   |   |    MPLS   |   |
         V   | Access +----+ |   Core   | +----+ Access |   V
   +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
   |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
   +--+  +----+       +----+ |          | +----+       +----+  +--+
             |           |   |          |   |           |
             +-----------+   +----------+   +-----------+

          Figure 7: H-VPLS with MPLS Access Network and PBB U-PE

   The U-PE still provides the same type of services toward its
   customers as before and they are:

      -  Port mode (either 802.1D, 802.1Q, or 802.1ad)
      -  VLAN mode (either 802.1Q or 802.1ad)
      -  VLAN-bundling mode (either 802.1Q or 802.1ad)





<span class="grey">Sajassi, et al.               Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   By incorporating a PBB function, the U-PE maps each of these services
   (for a given customer) onto a single I-SID based on the configuration
   at the U-PE.  Many I-SIDs are multiplexed within a single bridge
   domain (e.g., B-VLAN).  The U-PE can then map a bridge domain onto a
   VPLS instance and the encapsulated frames are sent over the PW
   associated with that VPLS instance.  Furthermore, the entire Ethernet
   bridging operation over the VPLS network is performed as defined in
   [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>].  In other words, MAC forwarding is based on the B-MAC
   address space and service delimiter is based on VLAN ID, which is
   B-VID in this case.  There is no need to inspect or deal with I-SID
   values in the VPLS N-PEs.

   In the case of PBB U-PEs in a single I-SID Domain, I-SID assignment
   is performed globally across all MPLS access networks and therefore
   there is no need for I-SID translation.  This scenario supports I-SID
   bundling mode, and it is assumed that the mapping of the I-SIDs to
   the bridge domain (e.g., B-VLAN) is consistent across all the
   participating PE devices.  In the case of the I-SID bundling mode, a
   bridge domain (e.g., B-VLAN) is mapped to a VPLS instance and an
   existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type
   is used as defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>].

   I-SID mode can be considered to be a degenerate case of I-SID
   bundling where a single bridge domain is used per I-SID.  However,
   that results in an increased number of bridge domains and PWs in the
   PEs.  PBB flood containment (B-MAC multicast pruning) per I-SID can
   be used in conjunction with I-SID bundling mode to limit the scope of
   flooding per I-SID thus removing the need for I-SID mode.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  H-VPLS with MPLS Access: PBB N-PE</span>

   In this case, the PBB function is incorporated at the N-PE to improve
   the scalability of H-VPLS networks in terms of the numbers of MAC
   addresses and service instances that are supported.

   Customer networks or hosts (CE) connect into the U-PE nodes using
   standard Ethernet interfaces [<a href="#ref-802.1D-REV" title="&quot;IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges&quot;">802.1D-REV</a>], [<a href="#ref-802.1Q" title="&quot;IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks&quot;">802.1Q</a>], or [<a href="#ref-802.1ad" title="&quot;IEEE Standard for and metropolitan area networks -- Virtual Bridged Local Area Networks -- Provider Bridges&quot;">802.1ad</a>].
   The U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS
   PWs (per customer).  These, in turn, are connected via a full mesh of
   PWs (per customer or group of customers) traversing the IP/MPLS core.

   The U-PE still provides the same type of services toward its
   customers as before and they are:

      -  Port mode (either 802.1D, 802.1Q, or 802.1ad)
      -  VLAN mode (either 802.1Q or 802.1ad)
      -  VLAN-bundling mode (either 802.1Q or 802.1ad)




<span class="grey">Sajassi, et al.               Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   The spoke PW from the U-PE to the N-PE is not service multiplexed
   because there is no PBB functionality on the U-PE, i.e., one service
   per PW.

                         PBB              PBB
                         BEB +----------+ BEB
                           | |          | |
             +-----------+ | |    IP    | | +-----------+
             | MPLS      | V |   MPLS   | V |    MPLS   |
             | Access +----+ |   Core   | +----+ Access |
   +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
   |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
   +--+  +----+       +----+ |          | +----+       +----+  +--+
             |           |   |          |   |           |
             +-----------+   +----------+   +-----------+

       Figure 8: H-VPLS with MPLS Access Network and PBB N-PE

   By incorporating a PBB function, the N-PE maps each of these services
   (for a given customer) onto a single I-SID based on the configuration
   at the N-PE.  Many I-SIDs can be multiplexed within a single bridge
   domain (e.g., B-VLAN).  The N-PE can, then, either map a single I-SID
   into a VPLS instance or map a bridge domain (e.g., B-VLAN) onto a
   VPLS instance, according to its configuration.  Next, the
   encapsulated frames are sent over the set of PWs associated with that
   VPLS instance.

   In the case of PBB N-PEs in a single I-SID Domain, I-SID assignment
   is performed globally across all MPLS access networks and therefore
   there is no need for I-SID translation.  This scenario supports I-SID
   bundling mode, and it is assumed that the mapping of the I-SIDs to
   the bridge domain (e.g., B-VLAN) is consistent across all the
   participating PE devices.  In the case of the I-SID bundling mode, a
   bridge domain (e.g., B-VLAN) is mapped to a VPLS instance and an
   existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type
   as defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] and [<a href="./rfc4448" title="&quot;Encapsulation Methods for Transport of Ethernet over MPLS Networks&quot;">RFC4448</a>], can be used.

   I-SID mode can be considered to be a degenerate case of I-SID
   bundling where a single bridge domain is used per I-SID.  However,
   that results in an increased number of bridge domains and PWs in the
   PE.  PBB flood containment (B-MAC multicast pruning) per I-SID can be
   used in conjunction with I-SID bundling mode to limit the scope of
   flooding per I-SID thus removing the need for I-SID mode.








<span class="grey">Sajassi, et al.               Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  H-VPLS with MPLS Access: PBB Migration Scenarios</span>

   Operators and service providers that have deployed H-VPLS with either
   MPLS or Ethernet are unlikely to migrate to PBB technology over night
   because of obvious cost implications.  Thus, it is imperative to
   outline migration strategies that will allow operators to protect
   investments in their installed base while still taking advantage of
   the scalability benefits of PBB technology.

   In the following subsections, we explore three different migration
   scenarios that allow a mix of existing H-VPLS access networks to
   coexist with newer PBB-based access networks.  The scenarios differ
   in whether or not the Ethernet service frames passing over the VPLS
   core are PBB-encapsulated.  The first scenario, in <a href="#section-7.1">Section 7.1</a>,
   involves passing only frames that are not PBB-encapsulated over the
   core.  The second scenario, in <a href="#section-7.2">Section 7.2</a>, stipulates passing only
   PBB-encapsulated frames over the core.  Whereas, the final scenario,
   in <a href="#section-7.3">Section 7.3</a>, depicts a core that supports a mix of PBB-
   encapsulated and non-PBB-encapsulated frames.  The advantages and
   disadvantages of each scenario will be discussed in the respective
   sections.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  802.1ad Service Frames over VPLS Core</span>

   In this scenario, existing access networks are left unchanged.  All
   N-PEs would forward frames based on C-MACs.  In other words, Ethernet
   frames that are traversing the VPLS core (within PWs) would use the
   802.1ad frame format, as in current VPLS.  Hence, the N-PEs in
   existing access networks do not require any modification.  For new
   MPLS access networks that have PBB functions on the U-PE, the
   corresponding N-PE must incorporate built-in IB-BEB functions in
   order to terminate the PBB encapsulation before the frames enter the
   core.  A key point here is that while both the U-PE and N-PE nodes
   implement PBB IB-BEB functionality, the former has the I-component
   facing the customer (CE) and the B-component facing the core; whereas
   the latter has the I-component facing the core and the B-component
   facing the customer (i.e., access network).














<span class="grey">Sajassi, et al.               Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


                                          PBB            PBB
                             +----------+ IB-BEB         IB-BEB
                             |          | |               |
             +-----------+   |    IP    | | +-----------+ |
             | MPLS      |   |   MPLS   | V |    MPLS   | |
             | Access +----+ |   Core   | +----+ Access | V
   +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
   |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
   +--+  +----+       +----+ |          | +----+       +----+  +--+
             | (Existing)|   |          |   |  (New)    |
             +-----------+   +----------+   +-----------+

   Figure 9: Migration with 802.1ad Service Frames over VPLS Core

   The main advantage of this approach is that it requires no change to
   existing access networks or existing VPLS N-PEs.  The main
   disadvantage is that these N-PEs will not leverage the advantages of
   PBB in terms of MAC address and PW scalability.  It is worth noting
   that this migration scenario is an optimal option for an H-VPLS
   deployment with a single PBB-capable access network.  When multiple
   PBB-capable access networks are required, then the scenario in
   <a href="#section-7.3">Section 7.3</a> is preferred, as it provides a more scalable and optimal
   interconnect amongst the PBB-capable networks.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  PBB Service Frames over VPLS Core</span>

   This scenario requires that the VPLS N-PE connecting to existing MPLS
   access networks be upgraded to incorporate IB-BEB functions.  All
   Ethernet service frames passing over the VPLS core would be PBB-
   encapsulated.  The PBB over MPLS access networks would require no
   special requirements beyond what is captured in <a href="#section-6">Section 6</a> of this
   document.  In this case, both the U-PE and N-PE, which implement
   IB-BEB functionality, have the I-component facing the customer and
   the B-component facing the core.

                         PBB                             PBB
                      IB-BEB +----------+              IB-BEB
                           | |          |                 |
             +-----------+ | |    IP    |   +-----------+ |
             | MPLS      | V |   MPLS   |   |    MPLS   | |
             | Access +----+ |   Core   | +----+ Access | V
   +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
   |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
   +--+  +----+       +----+ |          | +----+       +----+  +--+
             | (Existing)|   |          |   |  (New)    |
             +-----------+   +----------+   +-----------+

    Figure 10: Migration with PBB Service Frames over VPLS Core



<span class="grey">Sajassi, et al.               Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   The main advantage of this approach is that it allows better
   scalability of the VPLS N-PEs in terms of MAC address and pseudowire
   counts.  The disadvantage is that it requires upgrading the VPLS
   N-PEs of all existing MPLS access networks.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Mixed 802.1ad and PBB over VPLS Core</span>

   In this scenario, existing access networks are left unchanged, and
   they exchange Ethernet frames with 802.1ad format over the PWs in the
   core.  The newly added access networks, which incorporate PBB
   functionality exchange Ethernet frames that are PBB-encapsulated
   amongst each other over core PWs.  For service connectivity between
   existing access network (non-PBB-capable) and new access network (PBB
   based), the VPLS N-PE of the latter network employs IB-BEB
   functionality to decapsulate the PBB header from frames outbound to
   the core and encapsulate the PBB header for frames inbound from the
   core.  As a result, a mix of PBB-encapsulated and 802.1ad Ethernet
   service frames are exchanged over the VPLS core.

   This mode of operation requires new functionality on the VPLS N-PE of
   the PBB-capable access network, so that the PE can send frames in
   802.1ad format or PBB format, on a per PW basis, depending on the
   capability of the destination access network.  Effectively, the PE
   would have to incorporate B-BEB as well as IB-BEB functions.

   A given PE needs to be aware of the capability of its remote peer in
   order to determine whether it connects to the right PW Forwarder.
   This can be achieved either via static configuration or by extending
   the VPLS control plane (BGP-based auto-discovery and LDP Signaling)
   discussed in [<a href="./rfc6074" title="&quot;Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC6074</a>].  The latter approach and the details of the
   extensions required are out of scope for this document.

                                          PBB
                                          B-BEB          PBB
                             +----------+ IB-BEB         IB-BEB
                             |          | |               |
             +-----------+   |    IP    | | +-----------+ |
             | MPLS      |   |   MPLS   | V |    MPLS   | |
             | Access +----+ |   Core   | +----+ Access | V
   +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
   |CE|--|U-PE|       |N-PE| |          | |N-PE|       |U-PE|--|CE|
   +--+  +----+       +----+ |          | +----+       +----+  +--+
             | (Existing)|   |          |   |  (New)    |
             +-----------+   +----------+   +-----------+

                Figure 11: Migration with Mixed 802.1ad and
                     PBB Service Frames over VPLS Core




<span class="grey">Sajassi, et al.               Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   The U-PE and N-PE of the PBB-capable access network both employ BEB
   functionality.  The U-PE implements IB-BEB functionality where the
   I-component faces the customer (CE) and the B-component faces the
   core.  The N-PE, on the other hand, implements IB-BEB functionality
   with the I-component facing the core and the B-component facing the
   customer (access network).  In addition, the N-PE implements
   standalone B-BEB functionality.

   This scenario combines the advantages of both previous scenarios
   without any of their shortcomings, namely: it does not require any
   changes to existing access networks and it allows the N-PE to
   leverage the scalability benefits of 802.1ah for PBBN to PBBN
   connectivity.  The disadvantage of this option is that it requires
   new functionality on the N-PE of the PBBN access.  A second
   disadvantage is that this option requires two P2MP LSPs to be set up
   at the ingress N-PE: one for the N-PEs that support PBB encapsulation
   and another one for the N-PEs that don't support PBB encapsulation.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   The authors would like to thank Chris Metz and Dinesh Mohan for their
   valuable feedback and contributions.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   This document does not introduce any additional security aspects
   beyond those applicable to VPLS/H-VPLS.  VPLS/H-VPLS security
   considerations are already covered in [<a href="./rfc4111" title="&quot;Security Framework for Provider- Provisioned Virtual Private Networks (PPVPNs)&quot;">RFC4111</a>] and [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>].

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-802.1ad">802.1ad</a>]    "IEEE Standard for and metropolitan area networks --
                Virtual Bridged Local Area Networks -- Provider
                Bridges", 802.1ad-2005, August 2005.

   [<a id="ref-802.1ah">802.1ah</a>]    "IEEE Standard for Local and metropolitan area networks
                -- Virtual Bridged Local Area Networks Amendment 7:
                Provider Backbone Bridges", IEEE Std. 802.1ah-2008,
                August 2009.

   [<a id="ref-RFC4447">RFC4447</a>]    Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,
                and G. Heron, "Pseudowire Setup and Maintenance Using
                the Label Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April
                2006.





<span class="grey">Sajassi, et al.               Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


   [<a id="ref-RFC4448">RFC4448</a>]    Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
                "Encapsulation Methods for Transport of Ethernet over
                MPLS Networks", <a href="./rfc4448">RFC 4448</a>, April 2006.

   [<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-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-802.1Q">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(tm), 2012 Edition,
                October 2012.

   [<a id="ref-802.1D-REV">802.1D-REV</a>] "IEEE Standard for Local and metropolitan area networks
                Media Access Control (MAC) Bridges", IEEE Std. 802.1D,
                June 2004.

   [<a id="ref-RFC6246">RFC6246</a>]    Sajassi, A., Ed., Brockners, F., Mohan, D., Ed., and Y.
                Serbest, "Virtual Private LAN Service (VPLS)
                Interoperability with Customer Edge (CE) Bridges", <a href="./rfc6246">RFC</a>
                <a href="./rfc6246">6246</a>, June 2011.

   [<a id="ref-RFC4111">RFC4111</a>]    Fang, L., Ed., "Security Framework for Provider-
                Provisioned Virtual Private Networks (PPVPNs)", <a href="./rfc4111">RFC</a>
                <a href="./rfc4111">4111</a>, July 2005.



















<span class="grey">Sajassi, et al.               Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7080">RFC 7080</a>             VPLS Interoperability with PBB        December 2013</span>


Authors' Addresses

   Ali Sajassi
   Cisco
   EMail: sajassi@cisco.com


   Samer Salam
   Cisco
   EMail: ssalam@cisco.com


   Nabil Bitar
   Verizon Communications
   EMail : nabil.n.bitar@verizon.com


   Florin Balus
   Nuage Networks
   EMail: florin.balus@nuagenetworks.net































Sajassi, et al.               Informational                    [Page 26]
</pre>