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
|
<pre>Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 5828 Alcatel-Lucent
Category: Informational L. Berger
ISSN: 2070-1721 LabN
L. Andersson
Ericsson
March 2010
<span class="h1">Generalized Multiprotocol Label Switching (GMPLS) Ethernet</span>
<span class="h1">Label Switching Architecture and Framework</span>
Abstract
There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as Synchronous Optical Network (SONET) /
Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing
(TDM), and Asynchronous Transfer Mode (ATM). This document defines
an architecture and framework for a Generalized-MPLS-based control
plane for Ethernet in this "transport network" capacity. GMPLS has
already been specified for similar technologies. Some additional
extensions to the GMPLS control plane are needed, and this document
provides a framework for these extensions.
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/rfc5828">http://www.rfc-editor.org/info/rfc5828</a>.
<span class="grey">Fedyk, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
Copyright Notice
Copyright (c) 2010 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-1.1">1.1</a>. Terminology ................................................<a href="#page-5">5</a>
<a href="#section-1.1.1">1.1.1</a>. Concepts ............................................<a href="#page-5">5</a>
<a href="#section-1.1.2">1.1.2</a>. Abbreviations and Acronyms ..........................<a href="#page-6">6</a>
<a href="#section-2">2</a>. Background ......................................................<a href="#page-7">7</a>
<a href="#section-2.1">2.1</a>. Ethernet Switching .........................................<a href="#page-7">7</a>
<a href="#section-2.2">2.2</a>. Operations, Administration, and Maintenance (OAM) .........<a href="#page-10">10</a>
<a href="#section-2.3">2.3</a>. Ethernet Switching Characteristics ........................<a href="#page-10">10</a>
<a href="#section-3">3</a>. Framework ......................................................<a href="#page-11">11</a>
<a href="#section-4">4</a>. GMPLS Routing and Addressing Model .............................<a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. GMPLS Routing .............................................<a href="#page-13">13</a>
<a href="#section-4.2">4.2</a>. Control Plane Network .....................................<a href="#page-14">14</a>
<a href="#section-5">5</a>. GMPLS Signaling ................................................<a href="#page-14">14</a>
<a href="#section-6">6</a>. Link Management ................................................<a href="#page-15">15</a>
<a href="#section-7">7</a>. Path Computation and Selection .................................<a href="#page-16">16</a>
<a href="#section-8">8</a>. Multiple VLANs .................................................<a href="#page-17">17</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-17">17</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-18">18</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-18">18</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-18">18</a>
<a href="#section-11">11</a>. Acknowledgments ...............................................<a href="#page-20">20</a>
<span class="grey">Fedyk, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
There has been significant recent work in increasing the capabilities
of Ethernet switches. As a consequence, the role of Ethernet is
rapidly expanding into "transport networks" that previously were the
domain of other technologies such as SONET/SDH, TDM, and ATM. The
evolution and development of Ethernet capabilities in these areas is
a very active and ongoing process.
Multiple organizations have been active in extending Ethernet
technology to support transport networks. This activity has taken
place in the Institute of Electrical and Electronics Engineers (IEEE)
802.1 Working Group, the International Telecommunication Union -
Telecommunication Standardization Sector (ITU-T) and the Metro
Ethernet Forum (MEF). These groups have been focusing on Ethernet
forwarding, Ethernet management plane extensions, and the Ethernet
Spanning Tree Control Plane, but not on an explicitly routed,
constraint-based control plane.
In the forwarding-plane context, extensions have been, or are being,
defined to support different transport Ethernet forwarding models,
protection modes, and service interfaces. Examples of such
extensions include [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>], [<a href="#ref-802.1Qay" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 10: Provider Backbone Bridge Traffic Engineering"">802.1Qay</a>], [<a href="#ref-G.8011" title=""Ethernet over Transport - Ethernet services framework"">G.8011</a>], and [<a href="#ref-MEF.6" title=""Ethernet Services Definitions - Phase I"">MEF.6</a>].
These extensions allow for greater flexibility in the Ethernet
forwarding plane and, in some cases, the extensions allow for a
departure from forwarding based on a spanning tree. For example, in
the [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>] case, greater flexibility in forwarding is achieved
through the addition of a "provider" address space. [<a href="#ref-802.1Qay" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 10: Provider Backbone Bridge Traffic Engineering"">802.1Qay</a>]
supports the use of provisioning systems and network control
protocols that explicitly select traffic-engineered paths.
This document provides a framework for GMPLS Ethernet Label Switching
(GELS). GELS will likely require more than one switching type to
support the different models, and as the GMPLS procedures that will
need to be extended are dependent on switching type, these will be
covered in the technology-specific documents.
In the provider bridge model developed in the IEEE 802.1ad project
and amended to the IEEE 802.1Q standard [<a href="#ref-802.1Q" title=""IEEE standard for Virtual Bridged Local Area Networks"">802.1Q</a>], an extra Virtual
Local Area Network (VLAN) identifier (VID) is added. This VID is
referred to as the Service VID (S-VID) and is carried in a Service
TAG (S-TAG). In Provider Backbone Bridges (PBBs) [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>], a
Backbone VID (B-VID) and B-MAC header with a service instance (I-TAG)
encapsulate a customer Ethernet frame or a service Ethernet frame.
In the IEEE 802.1Q standard, the terms Provider Backbone Bridges
(PBBs) and Provider Backbone Bridged Network (PBBN) are used in the
context of these extensions.
<span class="grey">Fedyk, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
An example of Ethernet protection extensions can be found in
[<a href="#ref-G.8031" title=""Ethernet linear protection switching"">G.8031</a>]. Ethernet operations, administration, and maintenance (OAM)
is another important area that is being extended to enable provider
Ethernet services. Related extensions can be found in [<a href="#ref-802.1ag" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management"">802.1ag</a>] and
[<a href="#ref-Y.1731" title=""OAM Functions and Mechanisms for Ethernet based Networks"">Y.1731</a>].
An Ethernet-based service model is being defined within the context
of the MEF and ITU-T. [<a href="#ref-MEF.6" title=""Ethernet Services Definitions - Phase I"">MEF.6</a>] and [<a href="#ref-G.8011" title=""Ethernet over Transport - Ethernet services framework"">G.8011</a>] provide parallel
frameworks for defining network-oriented characteristics of Ethernet
services in transport networks. These framework documents discuss
general Ethernet connection characteristics, Ethernet User-Network
Interfaces (UNIs), and Ethernet Network-Network Interfaces (NNIs).
[<a href="#ref-G.8011.1" title=""Ethernet private line service"">G.8011.1</a>] defines the Ethernet Private Line (EPL) service, and
[<a href="#ref-G.8011.2" title=""Ethernet virtual private line service"">G.8011.2</a>] defines the Ethernet Virtual Private Line (EVPL) service.
[<a href="#ref-MEF.6" title=""Ethernet Services Definitions - Phase I"">MEF.6</a>] covers both service types. These activities are consistent
with the types of Ethernet switching defined in [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>].
The Ethernet forwarding-plane and management-plane extensions allow
for the disabling of standard Spanning Tree Protocols but do not
define an explicitly routed, constraint-based control plane. For
example, [<a href="#ref-802.1Qay" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 10: Provider Backbone Bridge Traffic Engineering"">802.1Qay</a>] is an amendment to IEEE 802.1Q that explicitly
allows for traffic engineering of Ethernet forwarding paths.
The IETF's GMPLS work provides a common control plane for different
data-plane technologies for Internet and telecommunication service
providers. The GMPLS architecture is specified in <a href="./rfc3945">RFC 3945</a>
[<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]. The protocols specified for GMPLS can be used to control
"Transport Network" technologies, e.g., optical and TDM networks.
GMPLS can also be used for packet and Layer 2 Switching (frame/cell-
based networks).
This document provides a framework for the use of GMPLS to control
"transport" Ethernet Label Switched Paths (Eth-LSPs). Transport
Ethernet adds new constraints that require it to be distinguished
from the previously specified technologies for GMPLS. Some
additional extensions to the GMPLS control plane are needed, and this
document provides a framework for these extensions. All extensions
to support Eth-LSPs will build on the GMPLS architecture and related
specifications.
This document introduces and explains GMPLS control plane use for
transport Ethernet and the concept of the Eth-LSP. The data-plane
aspects of Eth-LSPs are outside the scope of this document and IETF
activities.
The intent of this document is to reuse and be aligned with as much
of the GMPLS protocols as possible. For example, reusing the IP
control-plane addressing allows existing signaling, routing, Link
<span class="grey">Fedyk, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
Management Protocol (LMP), and path computation to be used as
specified. The GMPLS protocols support hierarchical LSPs as well as
contiguous LSPs. Also, GMPLS protocol mechanisms support a variety
of network reference points from UNIs to NNIs. Additions to existing
GMPLS capabilities will only be made to accommodate features unique
to transport Ethernet.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
<span class="h4"><a class="selflink" id="section-1.1.1" href="#section-1.1.1">1.1.1</a>. Concepts</span>
The following are basic Ethernet and GMPLS terms:
o Asymmetric Bandwidth
This term refers to a property of a bidirectional service instance
that has differing bandwidth allocation in each direction.
o Bidirectional congruent LSP
This term refers to the property of a bidirectional LSP that uses
only the same nodes, ports, and links in both directions. Ethernet
data planes are normally bidirectional congruent (sometimes known
as reverse path congruent).
o Contiguous Eth-LSP
A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from
multiple Eth-LSPs, each of which is operating within a VLAN and is
mapped one-to-one at the VLAN boundaries. Stitched LSPs form
contiguous LSPs.
o Eth-LSP
This term refers to Ethernet Label Switched Paths that may be
controlled via GMPLS.
o Hierarchical Eth-LSP
Hierarchical Eth-LSPs create a hierarchy of Eth-LSPs.
o In-band GMPLS signaling
In-band GMPLS signaling is composed of IP-based control messages
that are sent on the native Ethernet links encapsulated by a
single-hop Ethernet header. Logical links that use a dedicated VID
on the same physical links would be considered in-band signaling.
<span class="grey">Fedyk, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
o Out-of-band GMPLS signaling
Out-of-band GMPLS signaling is composed of IP-based control
messages that are sent between Ethernet switches over links other
than the links used by the Ethernet data plane. Out-of-band
signaling typically shares a different fate from the data links.
o Point-to-point (P2P) Traffic Engineering (TE) service instance
A TE service instance made up of a single bidirectional P2P or two
P2P unidirectional Eth-LSPs.
o Point-to-multipoint (P2MP) Traffic Engineering (TE) service
instance
A TE service instance supported by a set of LSPs that comprises one
P2MP LSP from a root to n leaves, plus a bidirectional congruent
point-to-point (P2P) LSP from each of the leaves to the root.
o Shared forwarding
Shared forwarding is a property of a data path where a single
forwarding entry (VID + Destination MAC address) may be used for
frames from multiple sources (Source MAC addresses). Shared
forwarding does not change any data-plane behavior. Shared
forwarding saves forwarding database (FDB) entries only. Shared
forwarding offers similar benefits to merging in the data plane.
However, in shared forwarding, the Ethernet data packets are
unchanged. With shared forwarding, dedicated control-plane states
for all Eth-LSPs are maintained regardless of shared forwarding
entries.
<span class="h4"><a class="selflink" id="section-1.1.2" href="#section-1.1.2">1.1.2</a>. Abbreviations and Acronyms</span>
The following abbreviations and acronyms are used in this document:
CCM Continuity Check Message
CFM Connectivity Fault Management
DMAC Destination MAC Address
Eth-LSP Ethernet Label Switched Path
I-SID Backbone Service Identifier carried in the I-TAG
I-TAG A Backbone Service Instance TAG defined in the
IEEE 802.1ah Standard [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>]
LMP Link Management Protocol
MAC Media Access Control
MP2MP Multipoint to multipoint
NMS Network Management System
OAM Operations, Administration, and Maintenance
<span class="grey">Fedyk, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
PBB Provider Backbone Bridges [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>]
PBB-TE Provider Backbone Bridges Traffic Engineering
[<a href="#ref-802.1Qay" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 10: Provider Backbone Bridge Traffic Engineering"">802.1Qay</a>]
P2P Point to Point
P2MP Point to Multipoint
QoS Quality of Service
SMAC Source MAC Address
S-TAG A Service TAG defined in the IEEE 802.1 Standard
[<a href="#ref-802.1Q" title=""IEEE standard for Virtual Bridged Local Area Networks"">802.1Q</a>]
TE Traffic Engineering
TAG An Ethernet short form for a TAG Header
TAG Header An extension to an Ethernet frame carrying
priority and other information
TSpec Traffic specification
VID VLAN Identifier
VLAN Virtual LAN
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
This section provides background to the types of switching and
services that are supported within the defined framework. The former
is particularly important as it identifies the switching functions
that GMPLS will need to represent and control. The intent is for
this document to allow for all standard forms of Ethernet switching
and services.
The material presented in this section is based on both finished and
ongoing work taking place in the IEEE 802.1 Working Group, the ITU-T,
and the MEF. This section references and, to some degree, summarizes
that work. This section is not a replacement for or an authoritative
description of that work.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Ethernet Switching</span>
In Ethernet switching terminology, the bridge relay is responsible
for forwarding and replicating the frames. Bridge relays forward
frames based on the Ethernet header fields: Virtual Local Area
Network (VLAN) Identifiers (VIDs) and Destination Media Access
Control (DMAC) address. PBB [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>] has also introduced a Service
Instance tag (I-TAG). Across all the Ethernet extensions (already
referenced in the Introduction), multiple forwarding functions, or
service interfaces, have been defined using the combination of VIDs,
DMACs, and I-TAGs. PBB [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>] provides a breakdown of the
different types of Ethernet switching services. Figure 1 reproduces
this breakdown.
<span class="grey">Fedyk, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
PBB Network
Service Types
_,,-' | '--.._
_,.-'' | `'--.._
_,.--' | `'--..
Port based S-tagged I-tagged
_,- -.
_.' `.
_,' `.
one-to-one bundled
_.- =.
_.-' ``-.._
_.-' `-..
many-to-one all-to-one
|
|
|
Transparent
Figure 1: Ethernet Switching Service Types
The switching types are defined in Clause 25 of [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>]. While not
specifically described in [<a href="#ref-802.1ah" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges"">802.1ah</a>], the Ethernet services being
defined in the context of [<a href="#ref-MEF.6" title=""Ethernet Services Definitions - Phase I"">MEF.6</a>] and [<a href="#ref-G.8011" title=""Ethernet over Transport - Ethernet services framework"">G.8011</a>] also fall into the
types defined in Figure 1 (with the exception of the newly defined
I-tagged service type).
[<a id="ref-802.1ah">802.1ah</a>] defines a new I-tagged service type but does not
specifically define the Ethernet services being defined in the
context of [<a href="#ref-MEF.6" title=""Ethernet Services Definitions - Phase I"">MEF.6</a>] and [<a href="#ref-G.8011" title=""Ethernet over Transport - Ethernet services framework"">G.8011</a>], which are also illustrated in Figure
1.
To summarize the definitions:
o Port based
This is a frame-based service that supports specific frame types;
no Service VLAN tagging or MAC-address-based switching.
o S-tagged
There are multiple S-TAG-aware services, including:
+ one-to-one
In this service, each VLAN identifier (VID) is mapped into a
different service.
<span class="grey">Fedyk, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
+ bundled
Bundled S-tagged service supports the mapping of multiple VIDs
into a single service and includes:
* many-to-one
In this frame-based service, multiple VIDs are mapped into the
same service.
* all-to-one
In this frame-based service, all VIDs are mapped into the same
service.
- transparent
This is a special case, all frames are mapped from a single
incoming port to a single destination Ethernet port.
o I-tagged
The edge of a PBBN consists of a combined backbone relay
(B-component relay) and service instance relay (I-component relay).
An I-TAG contains a service identifier (24-bit I-SID) and priority
markings as well as some other fields. An I-tagged service is
typically between the edges of the PBBN and terminated at each edge
on an I-component that faces a customer port so the service is
often not visible except at the edges. However, since the
I-component relay involves a distinct relay, it is possible to have
a visible I-tagged Service by separating the I-component relay from
the B-component relay. Two examples where it makes sense to do
this are an I-tagged service between two PBBNs and as an attachment
to a customer's Provider Instance Port.
In general, the different switching types determine which of the
Ethernet header fields are used in the forwarding/switching function,
e.g., VID only or VID and DMACs. The switching type may also require
the use of additional Ethernet headers or fields. Services defined
for UNIs tend to use the headers for requesting service (service
delimiter) and are relevant between the customer site and network
edge.
In most bridging cases, the header fields cannot be changed, but some
translations of VID field values are permitted, typically at the
network edges.
<span class="grey">Fedyk, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
Across all service types, the Ethernet data plane is bidirectional
congruent. This means that the forward and reverse paths share the
exact same set of nodes, ports, and bidirectional links. This
property is fundamental. The 802.1 group has maintained this
bidirectional congruent property in the definition of Connectivity
Fault Management (CFM), which is part of the overall OAM capability.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Operations, Administration, and Maintenance (OAM)</span>
Robustness is enhanced with the addition of data-plane OAM to provide
both fault and performance management.
Ethernet OAM messages ([<a href="#ref-802.1ag" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management"">802.1ag</a>] and [<a href="#ref-Y.1731" title=""OAM Functions and Mechanisms for Ethernet based Networks"">Y.1731</a>]) rely on data-plane
forwarding for both directions. Determining a broken path or
misdirected packet in this case relies on OAM following the Eth-LSP.
These OAM message identifiers are dependent on the data plane, so
they work equally well for provisioned or GMPLS-controlled paths.
Ethernet OAM currently consists of:
Defined in both [<a href="#ref-802.1ag" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management"">802.1ag</a>] and [<a href="#ref-Y.1731" title=""OAM Functions and Mechanisms for Ethernet based Networks"">Y.1731</a>]:
- CCM/RDI: Continuity Check Message / Remote Defect Indication
- LBM/LBR: Loopback Message/Reply
- LTM/LTR: Link Trace Message/Reply
- VSM/VSR: Vendor-Specific Message/Reply
Additionally defined in [<a href="#ref-Y.1731" title=""OAM Functions and Mechanisms for Ethernet based Networks"">Y.1731</a>]:
- AIS: Alarm Indication Signal
- LCK: Locked Signal
- TST: Test
- LMM/LMR: Loss Measurement Message/Reply
- DM: Delay Measurement
- DMM/DMR: Delay Measurement Message/Reply
- EXM/EXR: Experimental Message/Reply
- APS, MCC: Automatic Protection Switching, Maintenance
Communication Channel
These functions are supported across all the standardized Eth-LSP
formats.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Ethernet Switching Characteristics</span>
Ethernet is similar to MPLS as it encapsulates different packet and
frame types for data transmission. In Ethernet, the encapsulated
data is referred to as MAC client data. The encapsulation is an
Ethernet MAC frame with a header, a source address, a destination
<span class="grey">Fedyk, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
address, and an optional VLAN identifier, type, and length on the
front of the MAC client data with optional padding and a Frame Check
Sequence at the end of the frame.
The type of MAC client data is typically identified by an "Ethertype"
value. This is an explicit type indication, but Ethernet also
supports an implicit type indication.
Ethernet bridging switches based on a frame's destination MAC address
and VLAN. The VLAN identifies a virtual active set of bridges and
LANs. The address is assumed to be unique and invariant within the
VLAN. MAC addresses are often globally unique, but this is not
necessary for bridging.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Framework</span>
As defined in the GMPLS architecture [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>], the GMPLS control
plane can be applied to a technology by controlling the data-plane
and switching characteristics of that technology. The GMPLS
architecture, per [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>], allowed for control of Ethernet bridges
and other Layer 2 technologies using the Layer-2 Switch Capable
(L2SC) switching type. But, the control of Ethernet switching was
not explicitly defined in [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>], [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>], or any other
subsequent GMPLS reference document.
The GMPLS architecture includes a clear separation between a control
plane and a data plane. Control plane and data plane separation
allows the GMPLS control plane to remain architecturally and
functionally unchanged while controlling different technologies. The
architecture also requires IP connectivity for the control plane to
exchange information, but does not otherwise require an IP data
plane.
All aspects of GMPLS, i.e., addressing, signaling, routing and link
management, may be applied to Ethernet switching. GMPLS can provide
control for traffic-engineered and protected Ethernet service paths.
This document defines the term "Eth-LSP" to refer to Ethernet service
paths that are controlled via GMPLS. As is the case with all GMPLS
controlled services, Eth-LSPs can leverage common traffic engineering
attributes such as:
- bandwidth profile;
- forwarding priority level;
- connection preemption characteristics;
- protection/resiliency capability;
- routing policy, such as an explicit route;
- bidirectional service;
<span class="grey">Fedyk, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
- end-to-end and segment protection;
- hierarchy
The bandwidth profile may be used to set the committed information
rate, peak information rate, and policies based on either under-
subscription or over-subscription. Services covered by this
framework will use a TSpec that follows the Ethernet Traffic
parameters defined in [<a href="#ref-ETH-TSPEC" title=""Ethernet Traffic Parameters"">ETH-TSPEC</a>].
In applying GMPLS to "transport" Ethernet, GMPLS will need to be
extended to work with the Ethernet data plane and switching
functions. The definition of GMPLS support for Ethernet is
multifaceted due to the different forwarding/switching functions
inherent in the different service types discussed in <a href="#section-2.1">Section 2.1</a>. In
general, the header fields used in the forwarding/switching function,
e.g., VID and DMAC, can be characterized as a data-plane label. In
some circumstances, these fields will be constant along the path of
the Eth-LSP, and in others they may vary hop-by-hop or at certain
interfaces only along the path. In the case where the "labels" must
be forwarded unchanged, there are a few constraints on the label
allocation that are similar to some other technologies such as lambda
labels.
The characteristics of the "transport" Ethernet data plane are not
modified in order to apply GMPLS control. For example, consider the
IEEE 802.1Q [<a href="#ref-802.1Q" title=""IEEE standard for Virtual Bridged Local Area Networks"">802.1Q</a>] data plane: The VID is used as a "filter"
pointing to a particular forwarding table, and if the DMAC is found
in that forwarding table, the forwarding decision is made based on
the DMAC. When forwarding using a spanning tree, if the DMAC is not
found, the frame is broadcast over all outgoing interfaces for which
that VID is defined. This valid MAC checking and broadcast supports
Ethernet learning. A special case is when a VID is defined for only
two ports on one bridge, effectively resulting in a P2P forwarding
constraint. In this case, all frames that are tagged with that VID
and received over one of these ports are forwarded over the other
port without address learning.
[<a id="ref-802.1Qay">802.1Qay</a>] allows for turning off learning and hence the broadcast
mechanism that provides means to create explicitly routed Ethernet
connections.
This document does not define any specific format for an Eth-LSP
label. Rather, it is expected that service-specific documents will
define any signaling and routing extensions needed to support a
specific Ethernet service. Depending on the requirements of a
service, it may be necessary to define multiple GMPLS protocol
extensions and procedures. It is expected that all such extensions
will be consistent with this document.
<span class="grey">Fedyk, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
It is expected that a key requirement for service-specific documents
will be to describe label formats and encodings. It may also be
necessary to provide a mechanism to identify the required Ethernet
service type in signaling and a way to advertise the capabilities of
Ethernet switches in the routing protocols. These mechanisms must
make it possible to distinguish between requests for different
paradigms including new, future, and existing paradigms.
The Switching Type and Interface Switching Capability Descriptor
share a common set of values and are defined in [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>], [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>],
and [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>] as indicators of the type of switching that should
([<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>]) and can ([<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>]) be performed on a particular link for
an LSP. The L2SC switching type may already be used by
implementations performing Layer 2 Switching including Ethernet. As
such, and to allow the continued use of that switching type and those
implementations, and to distinguish the different Ethernet switching
paradigms, a new switching type needs to be defined for each new
Ethernet switching paradigm that is supported.
For discussion purposes, we decompose the problem of applying GMPLS
into the functions of routing, signaling, link management, and path
selection. It is possible to use some functions of GMPLS alone or in
partial combinations. In most cases, using all functions of GMPLS
leads to less operational overhead than partial combinations.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. GMPLS Routing and Addressing Model</span>
The GMPLS routing and addressing model is not modified by this
document. GMPLS control for Eth-LSPs uses the routing and addressing
model described in [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]. Most notably, this includes the use of
IP addresses to identify interfaces and LSP end-points. It also
includes support for both numbered and unnumbered interfaces.
In the case where another address family or type of identifier is
required to support an Ethernet service, extensions may be defined to
provide mapping to an IP address. Support of Eth-LSPs is expected to
strictly comply to the GMPLS protocol suite addressing as specified
in [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>], [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], and related documents.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. GMPLS Routing</span>
GMPLS routing as defined in [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>] uses IP routing protocols with
opaque TLV extensions for the purpose of distributing GMPLS-related
TE (router and link) information. As is always the case with GMPLS,
TE information is populated based on resource information obtained
from LMP or from configured information. The bandwidth resources of
the links are tracked as Eth-LSPs are set up. Interfaces supporting
the switching of Eth-LSPs are identified using the appropriate
<span class="grey">Fedyk, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
Interface Switching Capabilities (ISC) Descriptor. As mentioned in
<a href="#section-3">Section 3</a>, the definition of one or more new ISCs to support Eth-LSPs
is expected. Again, the L2SC ISCs will not be used to represent
interfaces capable of supporting Eth-LSPs defined by this document
and subsequent documents in support of the transport Ethernet
switching paradigms. In addition, ISC-specific TE information may be
defined as needed to support the requirements of a specific Ethernet
Switching Service Type.
GMPLS routing is an optional functionality but it is highly valuable
in maintaining topology and distributing the TE database for path
management and dynamic path computation.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Control Plane Network</span>
In order for a GMPLS control plane to operate, an IP connectivity
network of sufficient capacity to handle the information exchange of
the GMPLS routing and signaling protocols is necessary.
One way to implement this is with an IP-routed network supported by
an IGP that views each switch as a terminated IP adjacency. In other
words, IP traffic and a simple routing table are available for the
control plane, but there is no requirement for a high-performance IP
data plane, or for forwarding user traffic over this IP network.
This IP connectivity can be provided as a separate independent
network (out-of-band) or integrated with the Ethernet switches (in-
band).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. GMPLS Signaling</span>
GMPLS signaling ([<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] and [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]) is well suited to the
control of Eth-LSPs and Ethernet switches. Signaling provides the
ability to dynamically establish a path from an ingress node to an
egress node. The signaled path may be completely static and not
change for the duration of its lifetime. However, signaling also has
the capability to dynamically adjust the path in a coordinated
fashion after the path has been established. The range of signaling
options from static to dynamic are under operator control.
Standardized signaling also improves multi-vendor interoperability.
GMPLS signaling supports the establishment and control of
bidirectional and unidirectional data paths. Ethernet is
bidirectional by nature and CFM has been built to leverage this.
Prior to CFM, the emulation of a physical wire and the learning
requirements also mandated bidirectional connections. Given this,
<span class="grey">Fedyk, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either
P2P or P2MP (see [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]). GMPLS signaling also allows for full
and partial LSP protection; see [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
Note that standard GMPLS does not support different bandwidth in each
direction of a bidirectional LSP. [<a href="./rfc5467" title=""GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)"">RFC5467</a>], an Experimental
document, provides procedures if asymmetric bandwidth bidirectional
LSPs are required.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Link Management</span>
Link discovery has been specified for links interconnecting IEEE
802.1 bridges in [<a href="#ref-802.1AB" title=""IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery"">802.1AB</a>]. The benefits of running link discovery
in large systems are significant. Link discovery may reduce
configuration and reduce the possibility of undetected errors in
configuration as well as exposing misconnections. However, the
802.1AB capability is an optional feature, so it is not necessarily
operating before a link is operational, and it primarily supports the
management plane.
In the GMPLS context, LMP [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>] has been defined to support GMPLS
control-plane link management and discovery features. LMP also
supports the automated creation of unnumbered interfaces for the
control plane. If LMP is not used, there is an additional
configuration requirement for GMPLS link identifiers. For large-
scale implementations, LMP is beneficial. LMP also has optional
fault management capabilities, primarily for opaque and transparent
network technology. With IEEE's newer CFM [<a href="#ref-802.1ag" title=""IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management"">802.1ag</a>] and ITU-T's
capabilities [<a href="#ref-Y.1731" title=""OAM Functions and Mechanisms for Ethernet based Networks"">Y.1731</a>], this optional capability may not be needed.
It is the goal of the GMPLS Ethernet architecture to allow the
selection of the best tool set for the user needs. The full
functionality of Ethernet CFM should be supported when using a GMPLS
control plane.
LMP and 802.1AB are relatively independent. The LMP capability
should be sufficient to remove the need for 802.1AB, but 802.1 AB can
be run in parallel or independently if desired. Figure 2 provides
possible ways of using LMP, 802.1AB, and 802.1ag in combination.
Figure 2 illustrates the functional relationship of link management
and OAM schemes. It is expected that LMP would be used for control-
plane functions of link property correlation, but that Ethernet
mechanisms for OAM such as CFM, link trace, etc., would be used for
data-plane fault management and fault trace.
<span class="grey">Fedyk, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
+-------------+ +-------------+
| +---------+ | | +---------+ |
| | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation
| | (opt) | |GMPLS | | (opt) | |
| | | | | | | | Bundling
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |
| | 802.1AB |-|<------>|-| 802.1AB | |P2P
| | (opt) | |Ethernet| | (opt) | |link identifiers
| | | | | | | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |End-to-End
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
| | Y.1731 | |Ethernet| | Y.1731 | |Fault Management
| | (opt) | | | | (opt) | |Performance
| | | | | | | |Management
| +---------+ | | +---------+ |
+-------------+ +-------------+
Switch 1 link Switch 2
Figure 2: Logical Link Management Options
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Path Computation and Selection</span>
GMPLS does not identify a specific method for selecting paths or
supporting path computation. GMPLS allows for a wide range of
possibilities to be supported, from very simple path computation to
very elaborate path coordination where a large number of coordinated
paths are required. Path computation can take the form of paths
being computed in a fully distributed fashion, on a management
station with local computation for rerouting, or on more
sophisticated path computation servers.
Eth-LSPs may be supported using any path selection or computation
mechanism. As is the case with any GMPLS path selection function,
and common to all path selection mechanisms, the path selection
process should take into consideration Switching Capabilities and
Encoding advertised for a particular interface. Eth-LSPs may also
make use of the emerging path computation element and selection work;
see [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>].
<span class="grey">Fedyk, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Multiple VLANs</span>
This document allows for the support of the signaling of Ethernet
parameters across multiple VLANs supporting both contiguous Eth-LSP
and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS
hierarchy for the support of peer-to-peer models, UNIs, and NNIs.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
A GMPLS-controlled "transport" Ethernet system should assume that
users and devices attached to UNIs may behave maliciously,
negligently, or incorrectly. Intra-provider control traffic is
trusted to not be malicious. In general, these requirements are no
different from the security requirements for operating any GMPLS
network. Access to the trusted network will only occur through the
protocols defined for the UNI or NNI or through protected management
interfaces.
When in-band GMPLS signaling is used for the control plane, the
security of the control plane and the data plane may affect each
other. When out-of-band GMPLS signaling is used for the control
plane, the data-plane security is decoupled from the control plane,
and therefore the security of the data plane has less impact on
overall security.
Where GMPLS is applied to the control of VLAN only, the commonly
known techniques for mitigation of Ethernet denial-of-service attacks
may be required on UNI ports.
For a more comprehensive discussion on GMPLS security please see the
MPLS and GMPLS Security Framework [<a href="#ref-SECURITY" title=""Security Framework for MPLS and GMPLS Networks"">SECURITY</a>]. Cryptography can be
used to protect against many attacks described in [<a href="#ref-SECURITY" title=""Security Framework for MPLS and GMPLS Networks"">SECURITY</a>]. One
option for protecting "transport" Ethernet is the use of 802.1AE
Media Access Control Security [<a href="#ref-802.1AE" title=""IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security"">802.1AE</a>], which provides encryption
and authentication. It is expected that solution documents will
include a full analysis of the security issues that any protocol
extensions introduce.
<span class="grey">Fedyk, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
<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-RFC3471">RFC3471</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", <a href="./rfc3471">RFC</a>
<a href="./rfc3471">3471</a>, January 2003.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", <a href="./rfc3473">RFC</a>
<a href="./rfc3473">3473</a>, January 2003.
[<a id="ref-RFC3945">RFC3945</a>] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", <a href="./rfc3945">RFC 3945</a>, October 2004.
[<a id="ref-RFC4202">RFC4202</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", <a href="./rfc4202">RFC 4202</a>, October 2005.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-802.1AB">802.1AB</a>] "IEEE Standard for Local and Metropolitan Area Networks,
Station and Media Access Control Connectivity Discovery",
IEEE 802.1AB, 2009.
[<a id="ref-802.1AE">802.1AE</a>] "IEEE Standard for Local and metropolitan area networks
Media Access Control (MAC) Security", IEEE 802.1AE-2006,
August 2006.
[<a id="ref-802.1ag">802.1ag</a>] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 5:
Connectivity Fault Management", IEEE 802.1ag, 2007.
[<a id="ref-802.1ah">802.1ah</a>] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 6:
Provider Backbone Bridges", IEEE Std 802.1ah-2008, August
2008.
[<a id="ref-802.1Q">802.1Q</a>] "IEEE standard for Virtual Bridged Local Area Networks",
IEEE 802.1Q-2005, May 2006.
[<a id="ref-802.1Qay">802.1Qay</a>] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 10:
Provider Backbone Bridge Traffic Engineering", IEEE Std
802.1Qay-2009, August 2009.
<span class="grey">Fedyk, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
[<a id="ref-ETH-TSPEC">ETH-TSPEC</a>] Papadimitriou, D., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Ethernet+Traffic+Parameters%22'>"Ethernet Traffic Parameters"</a>, Work in
Progress, January 2010.
[<a id="ref-G.8011">G.8011</a>] ITU-T Recommendation G.8011, "Ethernet over Transport -
Ethernet services framework", January 2009.
[<a id="ref-G.8011.1">G.8011.1</a>] ITU-T Recommendation G.8011.1/Y.1307.1, "Ethernet private
line service", January 2009.
[<a id="ref-G.8011.2">G.8011.2</a>] ITU-T Recommendation G.8011.2/Y.1307.2, "Ethernet virtual
private line service", January 2009.
[<a id="ref-G.8031">G.8031</a>] ITU-T Recommendation G.8031, "Ethernet linear protection
switching", November 2009.
[<a id="ref-MEF.6">MEF.6</a>] The Metro Ethernet Forum MEF 6, "Ethernet Services
Definitions - Phase I", 2004.
[<a id="ref-RFC4204">RFC4204</a>] Lang, J., Ed., "Link Management Protocol (LMP)", <a href="./rfc4204">RFC</a>
<a href="./rfc4204">4204</a>, October 2005.
[<a id="ref-RFC4875">RFC4875</a>] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>, May
2007.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
August 2006.
[<a id="ref-RFC4872">RFC4872</a>] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", <a href="./rfc4872">RFC 4872</a>, May 2007.
[<a id="ref-RFC4873">RFC4873</a>] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", <a href="./rfc4873">RFC 4873</a>, May 2007.
[<a id="ref-RFC5467">RFC5467</a>] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", <a href="./rfc5467">RFC 5467</a>, March 2009.
[<a id="ref-SECURITY">SECURITY</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009.
[<a id="ref-Y.1731">Y.1731</a>] ITU-T Recommendation Y.1731, "OAM Functions and
Mechanisms for Ethernet based Networks", February 2008.
<span class="grey">Fedyk, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5828">RFC 5828</a> GMPLS Ethernet LS Architecture March 2010</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgments</span>
There were many people involved in the initiation of this work prior
to this document. The GELS framework document and the PBB-TE
extensions document were two documents that helped shape and justify
this work. We acknowledge the work of the authors of these initial
documents: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave
Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego
Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil
Bitar.
George Swallow contributed significantly to this document.
Authors' Addresses
Don Fedyk
Alcatel-Lucent
Groton, MA, 01450
Phone: +1-978-467-5645
EMail: donald.fedyk@alcatel-lucent.com
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
Loa Andersson
Ericsson
Phone: +46 10 717 52 13
EMail: loa.andersson@ericsson.com
Fedyk, et al. Informational [Page 20]
</pre>
|
