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 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=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">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=""IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges"">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=""IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges"">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=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">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=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">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=""Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges"">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=""IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges"">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=""IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and
[<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges"">802.1D-REV</a>], [<a href="#ref-802.1Q" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">802.1Q</a>], or
[<a href="#ref-802.1ad" title=""IEEE Standard for and metropolitan area networks -- Virtual Bridged Local Area Networks -- Provider Bridges"">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=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges"">802.1D-REV</a>], [<a href="#ref-802.1Q" title=""IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">802.1Q</a>], or [<a href="#ref-802.1ad" title=""IEEE Standard for and metropolitan area networks -- Virtual Bridged Local Area Networks -- Provider Bridges"">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=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">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=""Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)"">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=""Security Framework for Provider- Provisioned Virtual Private Networks (PPVPNs)"">RFC4111</a>] and [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">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>
|