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
|
<pre>Network Working Group A. Doria
Request for Comments: 3294 Lulea University of Technology
Category: Informational K. Sundell
Nortel Networks
June 2002
<span class="h1">General Switch Management Protocol (GSMP) Applicability</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo provides an overview of the GSMP (General Switch Management
Protocol) and includes information relating to its deployment in a IP
network in an MPLS environment. It does not discuss deployment in an
ATM (Asynchronous Transfer Mode) network or in a raw ethernet
configuration.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview</span>
The General Switch Management Protocol (GSMP) has been available to
the IETF community for several years now as informational RFCs. Both
GSMPv1.1 (released in March 1996 as <a href="./rfc1987">RFC 1987</a> [<a href="#ref-2" title=""Ipsilon's General Switch Management Protocol Specification Version 1.1"">2</a>]) and GSMPv2.0
(released in August 1998 as <a href="./rfc2297">RFC 2297</a> [<a href="#ref-3" title=""Ipsilon's General Switch Management Protocol Specification Version 2.0"">3</a>]) are available. Several
vendors have implemented GSMPv1.1.
In V1.1 and V2 GSMP was intended only for use with ATM switches.
During the course of the last two years, the GSMP working group has
decided to expand the purview of GSMP to the point where it can be
used to control a number of different kinds of switch and can thus
live up to what its name indicates; a general switch management
protocol. To do this, commands and arguments needed to be
generalised and sections needed to be added, discussing the manner in
which the generalised protocol could be applied to specific kinds of
switches and port types. In short, the protocol has gone through
major changes in the last 24 months.
<span class="grey">Doria & Sundell Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
GSMP provides an interface that can be used to separate the data
forwarder from the routing and other control plane protocols such as
LDP. As such it allows service providers to move away from
monolithic systems that bundle the control plane and the data plane
into a single tightly coupled system - usually in a single chassis.
Separating the control components from the forwarding components and
using GSMP for switch management, enables service providers to create
multi-service systems composed of various vendors equipment. It also
allows for a more dynamic means of adding services to their networks.
The IETF GSMP working group was established in the routing area
because GSMP was being seen as an optional part of the MPLS solution.
In a MPLS system, it is possible to run the routing protocols and
label distribution protocols on one system while passing data across
a generic switch, e.g., an ATM switch. GSMP provides the switch
resource management mechanism needed in such a scenario.
GSMP has also been selected by the Multiservice Switching Forum (MSF)
as its protocol of choice for the Switch Control Interface identified
in their architecture. The MSF is an industry forum which, among its
activities establishes their member's requirements and then works
with the appropriate standards bodies to foster their goals. In the
case of GSMP, the MSF presented the IETF GSMP Working Group with a
set of requirements for GSMP. The working group has made a
determined effort to comply with those requirements in its
specifications.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. GSMP V3 Document Set</span>
The current version of GSMP is documented in 3 documents:
- GSMP: General Switch Management protocol V3 [<a href="#ref-5" title=""General Switch Management Protocol (GSMP) V3"">5</a>]
- GSMP-ENCAPS: General Switch Management Protocol (GSMP) Packet
Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP) [<a href="#ref-4" title=""General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)"">4</a>]
- GSMP-MIB: Definitions of Managed Objects for the General Switch
Management Protocol [<a href="#ref-1" title=""Definitions of Managed Objects for the General Switch Management Protocol (GSMP)"">1</a>]
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. General Description</span>
The General Switch Management Protocol V3 (GSMPv3) [<a href="#ref-5" title=""General Switch Management Protocol (GSMP) V3"">5</a>], is a general
purpose protocol to control a label switch. GSMP allows a
controller to establish and release connections across the switch;
add and delete leaves on a multicast connection; reserve
resources; manage switch ports; request configuration information;
and request statistics. It also allows the switch to inform the
<span class="grey">Doria & Sundell Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
controller of asynchronous events such as a link going down. The
GSMPv3 protocol is asymmetric, the controller being the master and
the switch being the slave.
A physical switch can be partitioned into many virtual switches.
GSMPv3 does not provide support for defining switch partitions.
GSMPv3 treats a virtual switch as if it were a physical switch.
GSMPv3 may be transported in three ways:
- GSMPv3 operation across an IP network is specified.
- GSMPv3 operation across an ATM virtual channel is specified.
- GSMPv3 operation across an Ethernet link is specified.
Other encapsulations are possible, but have not been defined.
Encapsulations are defined in [<a href="#ref-4" title=""General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)"">4</a>].
A label switch is a frame or cell switch that supports connection
oriented switching using the exact match forwarding algorithm
based on labels attached to incoming cells or frames.
A label switch may support multiple label types. However, each
switch port can support only one label type. The label type
supported by a given port is indicated in a port configuration
message. Connections may be established between ports supporting
different label types using the adaptation methods. GSMPv3
supports TLV labels similar to those defined in MPLS. Examples of
labels which are defined include ATM, Frame Relay, DS1, DS3, E1,
E3, MPLS Generic Labels and MPLS FECs.
A connection across a switch is formed by connecting an incoming
labelled channel to one or more outgoing labelled channels.
Connections are generally referenced by the input port on which
they arrive and the label values of their incoming labelled
channel. In some messages, connections are referenced by the
output port.
GSMPv3 supports point-to-point and point-to-multipoint connections.
A multipoint-to-point connection is specified by establishing
multiple point-to-point connections, each of which specifies the
same output label. A multipoint-to-multipoint connection is
specified by establishing multiple point-to-multipoint connections
each of which specifies a different input label with the same
output labels.
<span class="grey">Doria & Sundell Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
In general a connection is established with a certain quality of
service (QoS). GSMPv3 includes a default QoS Configuration and
additionally allows the negotiation of alternative, optional QoS
configurations. The default QoS Configuration includes three QoS
Models: a default service model, a simple priority model and a QoS
profile model. GSMPv3 also supports the reservation of resources
when the labels are not yet known. This ability can be used in
support of MPLS.
GSMP contains an adjacency protocol. The adjacency protocol is used
to synchronise states across the link, to negotiate which version
of the GSMP protocol to use, to discover the identity of the
entity at the other end of a link, and to detect when it changes.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Switch Partitioning</span>
In GSMPv3 switch partitioning is static and occurs prior to running
the protocol. The partitions of a physical switch are isolated from
each other by the implementation and the controller assumes that the
resources allocated to a partition are at all times available to that
partition and only that partition. A partition appears to its
controller as a physical label switch. The resources allocated to a
partition appear to the controller as if they were the actual
physical resources of a physical switch. For example if the
bandwidth of a port is divided among several partitions, each
partition would appear to the controller to have its own independent
port with its fixed set of resources.
GSMPv3 controls a partitioned switch through the use of a partition
identifier that is carried in every GSMPv3 message. Each partition
has a one-to-one control relationship with its own logical controller
entity (which in the remainder of the document is referred to simply
as a controller) and GSMPv3 independently maintains adjacency between
each controller-partition pair.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Switch and controller interactions</span>
Multiple switches may be controlled by a single controller using
multiple instantiations of the protocol over separate control
connections.
Alternatively, multiple controllers can control a single switch.
Each controller would establish a control connection to the switch
using the adjacency protocol. The adjacency mechanism maintains a
state table indicating the control connections that are being
maintained by the same partition. The switch provides information to
the controller group about the number and identity of the attached
controllers. It does nothing, however, to co-ordinate the activities
<span class="grey">Doria & Sundell Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
of the controllers, and will execute all commands as they are
received. It is the controller group's responsibility to co-ordinate
its use of the switch. This mechanism is most commonly used for
controller redundancy and load sharing. Definition of the mechanism
by which controllers use to co-ordinate their control is not within
GSMPv3's scope.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Service support</span>
All GSMPv3 switches support the default QoS Configuration. A GSMPv3
switch may additionally support one or more alternative QoS
Configurations. GSMP includes a negotiation mechanism that allows a
controller to select from the QoS configurations that a switch
supports.
The default QoS Configuration includes three models:
The Service Model is based on service definitions found external
to GSMP such as in CR-LDP, Integrated Services or ATM Service
Categories. Each connection is assigned a specific service
that defines the handling of the connection by the switch.
Additionally, traffic parameters and traffic controls may be
assigned to the connection depending on the assigned service.
In the Simple Abstract Model a connection is assigned a priority
when it is established. It may be assumed that for connections
that share the same output port, a cell or frame on a
connection with a higher priority is much more likely to exit
the switch before a cell or frame on a connection with a lower
priority if they are both in the switch at the same time.
The QoS Profile Model provides a simple mechanism that allows QoS
semantics defined externally to GSMP to be assigned to
connections. Each profile is an opaque indicator that has been
predefined in the controller and in the switch.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Summary of Message Set</span>
The following table gives a summary of the messages defined in this
version of the specification. It also makes a recommendation of the
minimal set of messages that should be supported in an MPLS
environment. These messages will be labelled as "Required", though
the service provided by the other messages are essential for the
operation of carrier quality controller/switch operations. GSMPv1.1
or GSMPv2 commands that are no longer support are marked as
"Obsolete" and should no longer be used.
<span class="grey">Doria & Sundell Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Messages Table</span>
Message Name Message Number Status
Connection Management Messages
Add Branch........................16 Required
ATM Specific - VPC............<a href="#page-26">26</a>
Delete Tree.......................<a href="#page-18">18</a>
Verify Tree.......................19 Obsoleted
Delete All Input..................<a href="#page-20">20</a>
Delete All Output.................<a href="#page-21">21</a>
Delete Branches...................17 Required
Move Output Branch................<a href="#page-22">22</a>
ATM Specific - VPC............<a href="#page-27">27</a>
Move Input Branch.................<a href="#page-23">23</a>
ATM Specific - VPC............<a href="#page-28">28</a>
Port Management Messages
Port Management...................32 Required
Label Range.......................<a href="#page-33">33</a>
State and Statistics Messages
Connection Activity...............<a href="#page-48">48</a>
Port Statistics...................49 Required
Connection Statistics.............<a href="#page-50">50</a>
QoS Class Statistics..............51 Reserved
Report Connection State...........<a href="#page-52">52</a>
Configuration Messages
Switch Configuration..............64 Required
Port Configuration................65 Required
All Ports Configuration...........66 Required
Service Configuration.............<a href="#page-67">67</a>
Reservation Messages
Reservation Request...............70 Required
Delete Reservation................71 Required
Delete All Reservations...........<a href="#page-72">72</a>
Event Messages
Port Up...........................<a href="#page-80">80</a>
Port Down.........................<a href="#page-81">81</a>
Invalid Label.....................<a href="#page-82">82</a>
New Port..........................<a href="#page-83">83</a>
Dead Port.........................<a href="#page-84">84</a>
<span class="grey">Doria & Sundell Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
Abstract and Resource Model Extension Messages
Reserved.Message Range.........200-249
Adjacency Protocol.................10 Required
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The security of GSMP's TCP/IP control channel has been addressed in
[<a href="#ref-4" title=""General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)"">4</a>]. For all uses of GSMP over an IP network, it is REQUIRED that
GSMP be run over TCP/IP using the security considerations discussed
in [<a href="#ref-4" title=""General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)"">4</a>].
References
[<a id="ref-1">1</a>] Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of
Managed Objects for the General Switch Management Protocol
(GSMP)", <a href="./rfc3295">RFC 3295</a>, June 2002.
[<a id="ref-2">2</a>] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F.,
Lyon, T. and Minshall, G., "Ipsilon's General Switch Management
Protocol Specification Version 1.1", <a href="./rfc1987">RFC 1987</a>, August 1996.
[<a id="ref-3">3</a>] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F.,
Lyon, T. and G. Minshall, "Ipsilon's General Switch Management
Protocol Specification Version 2.0", <a href="./rfc2297">RFC 2297</a>, March 1998.
[<a id="ref-4">4</a>] Worster, T., Doria, A. and J. Buerkle, "General Switch Management
Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer
Mode (ATM), Ethernet and Transmission Control Protocol (TCP)",
<a href="./rfc3293">RFC 3293</a>, June 2002.
[<a id="ref-5">5</a>] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General
Switch Management Protocol (GSMP) V3", <a href="./rfc3292">RFC 3292</a>, June 2002.
<span class="grey">Doria & Sundell Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
Authors' Addresses
Avri Doria
Div. of Computer Communications
Lulea University of Technology
S-971 87 Lulea
Sweden
Phone: +1 401 663 5024
EMail: avri@acm.org
Kenneth Sundell
Nortel Networks AB
S:t Eriksgatan 115 A
P.O. Box 6701
SE-113 85 Stockholm Sweden
EMail: sundell@nortelnetworks.com
<span class="grey">Doria & Sundell Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3294">RFC 3294</a> GSMP Applicability June 2002</span>
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Doria & Sundell Informational [Page 9]
</pre>
|
