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
|
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 7074 LabN
Updates: 3471, 4202, 4203, 5307 J. Meuric
Category: Standards Track Orange
ISSN: 2070-1721 November 2013
Revised Definition of the GMPLS Switching Capability and Type Fields
Abstract
GMPLS provides control for multiple switching technologies and for
hierarchical switching within a technology. GMPLS routing and
signaling use common values to indicate the type of switching
technology. These values are carried in routing protocols via the
Switching Capability field, and in signaling protocols via the
Switching Type field. While the values used in these fields are the
primary indicators of the technology and hierarchy level being
controlled, the values are not consistently defined and used across
the different technologies supported by GMPLS. This document is
intended to resolve the inconsistent definition and use of the
Switching Capability and Type fields by narrowly scoping the meaning
and use of the fields. This document updates all documents that use
the GMPLS Switching Capability and Types fields, in particular RFCs
3471, 4202, 4203, and 5307.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7074.
Berger & Meuric Standards Track [Page 1]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include 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.
1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) provides control
for multiple switching technologies. It also supports hierarchical
switching within a technology. The original GMPLS Architecture, per
[RFC3945], included support for five types of switching capabilities.
An additional type was also defined in [RFC6002]. The switching
types defined in these documents include:
1. Packet Switch Capable (PSC)
2. Layer-2 Switch Capable (L2SC)
3. Time-Division Multiplex Capable (TDM)
4. Lambda Switch Capable (LSC)
5. Fiber-Switch Capable (FSC)
6. Data Channel Switching Capable (DCSC)
Support for the original types was defined for routing in [RFC4202],
[RFC4203], and [RFC5307], where the types were represented in the
Switching Capability (Switching Cap) field. In general, hierarchy
within a type is addressed in a type-specific fashion, and a single
Switching Capability field value is defined per type. The exception
to this is PSC, which was assigned four values to indicate four
levels of hierarchy: PSC-1, PSC-2, PSC-3, and PSC-4. The same values
used in routing are defined for signaling in [RFC3471], and are
carried in the Switching Type field. Following the IANA registry, we
refer to the values used in the routing Switching Capability field
and signaling Switching Type field as Switching Types.
Berger & Meuric Standards Track [Page 2]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
In general, a Switching Type does not indicate a specific data-plane
technology; this needs to be inferred from context. For example,
L2SC was defined to cover Ethernet and ATM, and TDM was defined to
cover both SONET/SDH [RFC4606] and G.709 [RFC4328]. The basic
assumption was that different technologies of the same type would
never operate within the same control, i.e., signaling and routing
domains.
The past approach in assignment of Switching Types has proven to be
problematic from two perspectives. The first issue is that some
examples of switching technologies have different levels of switching
that can be performed within the same technology. For example, there
are multiple types of Ethernet switching that may occur within a
provider network. The second issue is that the Switching Capability
field value is used in Interior Gateway Protocols (IGPs) to indicate
the format of the Switching Capability-specific information (SCSI)
field, and that an implicit mapping of type to SCSI format is
impractical for implementations that support multiple switching
technologies. These issues led to the introduction of two new types
for Ethernet in [RFC6004] and [RFC6060], namely:
7. Ethernet Virtual Private Line (EVPL)
8. 802_1 PBB-TE (Provider Backbone Bridge Traffic Engineering)
An additional value is also envisioned to be assigned in support of
G.709v3 by [GMPLS-G709] in order to disambiguate the format of the
SCSI field.
While a common representation of hierarchy levels within a switching
technology certainly fits the design objectives of GMPLS, the
definition of multiple PSC Switching Types has also proven to be of
little value. Notably, there are no known uses of PSC-2, PSC-3, and
PSC-4.
This document proposes to resolve such inconsistent definitions and
uses of the Switching Types by reducing the scope of the related
fields and narrowing their use. In particular, this document
deprecates the use of the Switching Types as an identifier of
hierarchy levels within a switching technology and limits its use to
the identification of a per-switching technology SCSI field format.
This document updates all documents that use the GMPLS Switching
Capability and Switching Type fields, in particular RFCs 3471, 4202,
4203, and 5307.
Berger & Meuric Standards Track [Page 3]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
1.1. Current Switching Type Definition
The Switching Type values are carried in both routing and signaling
protocols. Values are identified in IANA's "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Parameters" registry,
which is currently located at <http://www.iana.org/assignments/
gmpls-sig-parameters/>.
For routing, a common information element is defined to carry
Switching Type values for both OSPF and IS-IS routing protocols in
[RFC4202]. Per [RFC4202], Switching Type values are carried in a
Switching Capability (Switching Cap) field in an Interface Switching
Capability Descriptor. This information shares a common formatting
in both OSPF as defined by [RFC4203] and in IS-IS as defined by
[RFC5307]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
The content of the Switching Capability-specific information field
depends on the value of the Switching Capability field.
Similarly, the Switching Type field is defined as part of a common
format for use by GMPLS signaling protocols in [RFC3471] and is used
by [RFC3473]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Type: 8 bits
Indicates the type of switching that should be performed on a
particular link. This field is needed for links that advertise
more than one type of switching capability. This field should
Berger & Meuric Standards Track [Page 4]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
map to one of the values advertised for the corresponding link
in the routing Switching Capability Descriptor ...
1.2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Revised Switching Type Definition
This document modifies the definition of Switching Type. The
definitions are slightly different for routing and signaling and are
described in the following sections.
2.1. Routing -- Switching Cap Field
For routing [RFC4202] [RFC4203] [RFC5307], the following definition
should be used for Switching Cap field:
The Switching Cap field indicates the type of switching being
advertised via GMPLS Switching Type values. A different Switching
Type value SHOULD be used for each data-plane technology, even
when those technologies share the same type of multiplexing or
switching. For example, Time Division Multiplexing (TDM)
technologies that have different multiplexing structures, such as
Synchronous Digital Hierarchy (SDH) [G.707] and Optical Transport
Network (OTN) [G.709], should use two different Switching Types.
As the format of the Switching Capability-specific information
field is dependent on the value of this field, a different
Switching Type value MUST be used to differentiate between
different Switching Capability-specific information field formats.
This definition does not modify the format of the Interface
Switching Capability Descriptor.
Note that from a practical standpoint, this means that any time a new
switching technology might use a different Switching Capability-
specific information field format, a new Switching Type SHOULD be
used.
Berger & Meuric Standards Track [Page 5]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
2.2. Signaling -- Switching Type Field
For signaling [RFC3471], which is used by [RFC3473], the following
definition should be used for the Switching Type field:
Indicates the type of switching that should be performed on a
particular link via GMPLS Switching Type values. This field maps
to one of the values advertised for the corresponding link in the
routing Switching Capability Descriptor, see [RFC4203] and
[RFC5307].
Note that from a practical standpoint, there is no change in the
definition of this field.
2.3. Assigned Switching Types
This document deprecates the following Switching Types:
Value Name
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
These values SHOULD be treated as unsupported types and, in the
case of signaling, processed according to Section 2.1.1 of
[RFC3473].
3. Compatibility
For existing implementations, the primary impact of this document is
deprecating the use of PSC-2, 3, and 4. At the time of publication,
there are no known deployments (or even implementations) that make
use of these values, so there are no compatibility issues for current
routing and signaling implementations.
4. Security Considerations
This document impacts the values carried in a single field in
signaling and routing protocols. As no new protocol formats or
mechanisms are defined, there are no particular security implications
raised by this document.
For a general discussion on MPLS- and GMPLS-related security issues,
see the MPLS/GMPLS security framework [RFC5920].
Berger & Meuric Standards Track [Page 6]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
5. IANA Considerations
IANA has deprecated some values and redefined the related values in
the "IANA-GMPLS-TC-MIB" definitions. In particular, the Switching
Types portion of the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry been revised to read:
Switching Types
Registration Procedures
Standards Action
Reference
[RFC3471][RFC4328][This Document]
Value Name Reference
0 Unassigned
1 Packet-Switch Capable-1 (PSC-1) [RFC3471]
2 Deprecated [This Document]
3 Deprecated [This Document]
4 Deprecated [This Document]
5-29 Unassigned
30 Ethernet Virtual Private Line (EVPL) [RFC6004]
31-39 Unassigned
40 802_1 PBB-TE [RFC6060]
41-50 Unassigned
51 Layer-2 Switch Capable (L2SC) [RFC3471]
52-99 Unassigned
100 Time-Division-Multiplex Capable (TDM) [RFC3471]
101-124 Unassigned
125 Data Channel Switching Capable (DCSC) [RFC6002]
126-149 Unassigned
150 Lambda-Switch Capable (LSC) [RFC3471]
151-199 Unassigned
200 Fiber-Switch Capable (FSC) [RFC3471]
201-255 Unassigned
A parallel change to IANA-GMPLS-TC-MIB was also made. In particular,
under IANAGmplsSwitchingTypeTC a reference to this document has been
added as item 3. The following changes have also been made to the
related values:
psc2(2), -- Deprecated [This Document]
psc3(3), -- Deprecated [This Document]
psc4(4), -- Deprecated [This Document]
Berger & Meuric Standards Track [Page 7]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
6. Acknowledgments
We thank John Drake for highlighting the current inconsistent
definitions associated with the Switching Capability and Type fields.
Daniele Ceccarelli and Adrian Farrel provided valuable feedback on
this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, October 2008.
7.2. Informative References
[G.707] ITU-T Recommendation G.707/Y.1322 (2007), "Network node
interface for the synchronous digital hierarchy (SDH)".
[G.709] ITU-T Recommendation G.709/Y.1331 (2009), "Interfaces
for the Optical Transport Network (OTN)".
[GMPLS-G709] Zhang, F., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks", Work in Progress,
September 2013.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
Berger & Meuric Standards Track [Page 8]
^L
RFC 7074 GMPLS Switching and Type Fields Revision November 2013
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, January
2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized
Multi-Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
Channel Switching Capable (DCSC) and Channel Set Label
Extensions", RFC 6002, October 2010.
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS)
Support for Metro Ethernet Forum and G.8011 Ethernet
Service Switching", RFC 6004, October 2010.
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS)
Control of Ethernet Provider Backbone Traffic
Engineering (PBB-TE)", RFC 6060, March 2011.
8. Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1 301 468 9228
EMail: lberger@labn.net
Julien Meuric
Orange
Research & Development
2, Avenue Pierre Marzin
22307 Lannion Cedex -- France
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange.com
Berger & Meuric Standards Track [Page 9]
^L
|