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: 3293 Lulea University of Technology
Category: Standards Track J. Buerkle
Nortel Networks
T. Worster
June 2002
<span class="h1">General Switch Management Protocol (GSMP)</span>
<span class="h1">Packet Encapsulations for Asynchronous Transfer Mode (ATM),</span>
<span class="h1">Ethernet and Transmission Control Protocol (TCP)</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo specifies the encapsulation of GSMP (General Switch
Management Protocol) packets in ATM (Asynchronous Transfer Mode),
Ethernet and TCP (Transmission Control Protocol).
Specification of Requirements
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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-7" title=""Key words for use in RFCs to Indicate Requirement Levels"">7</a>].
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
GSMP messages are defined in [<a href="#ref-1" title=""General Switch Management Protocol (GSMP) V3"">1</a>] and MAY be encapsulated in several
different protocols for transport. This memo specifies their
encapsulation in ATM AAL-5, in Ethernet or in TCP. Other
encapsulations may be defined in future specifications.
<span class="grey">Doria, et. al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. ATM Encapsulation</span>
GSMP packets are variable length and for an ATM data link layer they
are encapsulated directly in an AAL-5 CPCS-PDU [<a href="#ref-3" title=""B-ISDN ATM Adaptation Layer (AAL) Specification,"">3</a>][4] with an
LLC/SNAP header as illustrated:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(The convention in the documentation of Internet Protocols [<a href="#ref-5" title=""Assigned Numbers"">5</a>] is to
express numbers in decimal. Numbers in hexadecimal format are
specified by prefacing them with the characters "0x". Numbers in
binary format are specified by prefacing them with the characters
"0b". Data is pictured in "big-endian" order. That is, fields are
described left to right, with the most significant byte on the left
and the least significant byte on the right. Whenever a diagram
shows a group of bytes, the order of transmission of those bytes is
the normal order in which they are read in English. Whenever a byte
represents a numeric quantity the left most bit in the diagram is the
high order or most significant bit. That is, the bit labelled 0 is
the most significant bit. Similarly, whenever a multi-byte field
represents a numeric quantity the left most bit of the whole field is
the most significant bit. When a multi-byte quantity is transmitted,
the most significant byte is transmitted first. This is the same
coding convention as is used in the ATM layer [<a href="#ref-2" title=""B-ISDN ATM Layer Specification,"">2</a>] and AAL-5 [<a href="#ref-3" title=""B-ISDN ATM Adaptation Layer (AAL) Specification,"">3</a>][4].)
The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00
0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.)
The maximum transmission unit (MTU) of the GSMP Message field is 1492
bytes.
<span class="grey">Doria, et. al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
The virtual channel over which a GSMP session is established between
a controller and the switch it is controlling is called the GSMP
control channel. The default VPI and VCI of the GSMP control channel
for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is:
VPI = 0
VCI = 15.
The GSMP control channel MAY be changed using the GSMP MIB.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Ethernet Encapsulation</span>
GSMP packets MAY be encapsulated on an Ethernet data link as
illustrated:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Address
For the SYN message of the adjacency protocol the Destination
Address is the broadcast address 0xFFFFFFFFFFFF. (Alternatively,
it is also valid to configure the node with the unicast 48-bit
IEEE MAC address of the destination. In this case the configured
unicast Destination Address is used in the SYN message.) For all
other messages the Destination Address is the unicast 48-bit
<span class="grey">Doria, et. al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
IEEE. MAC address of the destination. This address may be
discovered from the Source Address field of messages received
during synchronisation of the adjacency protocol.
Source Address
For all messages, the Source Address is the 48-bit IEEE MAC
address of the sender.
Ethertype
The assigned Ethertype for GSMP is 0x880C.
GSMP Message
The maximum transmission unit (MTU) of the GSMP Message field is
1492 bytes.
Sender Instance
The Sender Instance number for the link obtained from the
adjacency protocol. This field is already present in the
adjacency protocol message. It is appended to all non-adjacency
GSMP messages in the Ethernet encapsulation to offer additional
protection against the introduction of corrupt state.
Receiver Instance
The Receiver Instance number is what the sender believes is the
current instance number for the link, allocated by the entity at
the far end of the link. This field is already present in the
adjacency protocol message. It is appended to all non-adjacency
GSMP messages in the Ethernet encapsulation to offer additional
protection against the introduction of corrupt state.
Pad
After adjacency has been established the minimum length of the
data field of an Ethernet packet is 46 bytes. If necessary,
padding should be added such that it meets the minimum Ethernet
frame size. This padding should be bytes of zero and is not to be
considered part of the GSMP message.
Frame Check Sequence
The Frame Check Sequence (FCS) is defined in IEEE 802.3 [<a href="#ref-6">6</a>] as
follows:
Note: This section is included for informational and historical
purposes only. The normative reference can be found in IEEE
802.3 Standard [<a href="#ref-6">6</a>].
"A cyclic redundancy check (CRC) is used by the transmit and
receive algorithms to generate a CRC value for the FCS field.
The frame check sequence (FCS) field contains a 4-byte (32-bit)
<span class="grey">Doria, et. al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
cyclic redundancy check (CRC) value. This value is computed as
a function of the contents of the source address, destination
address, length, LLC data and pad (that is, all fields except
the preamble, SFD, FCS and extension). The encoding is defined
by the following generating polynomial.
G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^
7+x^5+x^4+x^2+x^1."
The procedure for the CRC calculation can be found in [<a href="#ref-6">6</a>].
After the adjacency protocol has achieved synchronisation, for every
GSMP message received with an Ethernet encapsulation, the receiver
must check the Source Address from the Ethernet MAC header, the
Sender Instance, and the Receiver Instance. The incoming GSMP
message must be discarded if the Sender Instance and the Source
Address do not match the values of the Sender Instance and the Sender
Name stored by the "Update Peer Verifier" operation of the GSMP
adjacency protocol. The incoming GSMP message must also be discarded
if it arrives over any port other than the port over which the
adjacency protocol has achieved synchronisation. In addition, the
incoming message must also be discarded if the Receiver Instance
field does not match the current value for the Sender Instance of the
GSMP adjacency protocol.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. TCP/IP Encapsulation</span>
When GSMP messages are transported over an IP network, they MUST be
transported using the TCP encapsulation. TCP provides reliable
transport, network flow control, and end-system flow control suitable
for networks that may have high loss and variable or unpredictable
delay.
For TCP encapsulations of GSMP messages, the controller runs the
client code and the switch runs the server code. Upon
initialisation, the server is listening on GSMP's TCP port number:
6068. The controller establishes a TCP connection with each switch
it manages. The switch under control MUST be a multi-connection
server (PORT 6068) to allow creation of multiple control sessions
from N GSMP controller instances. Adjacency protocol messages, which
are used to synchronise the controller and switch and maintain
handshakes, are sent by the controller to the switch after the TCP
connection is established. GSMP messages other than adjacency
protocol messages MUST NOT be sent until after the adjacency protocol
has achieved synchronisation. The actual GSMP message flow will
occur on other ports.
<span class="grey">Doria, et. al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Message Formats</span>
GSMP messages are sent over a TCP connection. A GSMP message is
processed only after it is entirely received. A four-byte TLV header
field is prepended to the GSMP message to provide delineation of GSMP
messages within the TCP stream.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
This 2-byte field indicates the type code of the following
message. The type code for GSMP messages is 0x88-0C (i.e., the
same as GSMP's Ethertype).
Length
This 2-byte unsigned integer indicates the total length of the
GSMP message only. It does not include the 4-byte TLV header.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> TCP/IP Security consideration</span>
When GSMPv3 is implemented for use in IP networks, provisions for
security between the controller and client MUST be available and MUST
be provided by IP Security [IPSEC]. In this case, the IPSEC
Encapsulation Security Payload (ESP) MUST be used to provide both
integrity and confidentiality.
<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="#section-4.2">Section 4.2</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="#section-4.2">Section 4.2</a>. Security using ATM and Ethernet
encapsulations MAY be provided at the link layer. Discussion of
these methods is beyond the scope of this specification. For secure
operation over any media, the IP encapsulation with IPsec SHOULD be
used.
<span class="grey">Doria, et. al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
References
[<a id="ref-1">1</a>] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General
Switch Management Protocol (GSMP) V3", <a href="./rfc3292">RFC 3292</a>, June 2002.
[<a id="ref-2">2</a>] "B-ISDN ATM Layer Specification," International Telecommunication
Union, ITU-T Recommendation I.361, Feb. 1999.
[<a id="ref-3">3</a>] "B-ISDN ATM Adaptation Layer (AAL) Specification," International
Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[<a id="ref-4">4</a>] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",
International Telecommunication Union, ITU-T Recommendation
I.363.5, Aug. 1996.
[<a id="ref-5">5</a>] Reynolds, J., Editor, "Assigned Numbers", <a href="./rfc3232">RFC 3232</a>, January 2002.
[<a id="ref-6">6</a>] IEEE Std 802.3, 1998 Edition
"Information technology-Telecommunications and information
exchange between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier sense multiple access
with collision detection (CSMA/CD) access method and physical
layer specifications"
[<a id="ref-7">7</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Doria, et. al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations June 2002</span>
Authors' Addresses
Tom Worster
Phone: +1 617 247 2624
EMail: fsb@thefsb.org
Avri Doria
Div. of Computer Communications
Lulea University of Technology
S-971 87 Lulea
Sweden
Phone: +1 401 663 5024
EMail: avri@acm.com
Joachim Buerkle
Nortel Networks Germany GmbH & Co. KG
Hahnstr. 37-39
60528 Frankfurt am Main
Germany
EMail: Joachim.Buerkle@nortelnetworks.com
<span class="grey">Doria, et. al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3293">RFC 3293</a> GSMP Packet Encapsulations 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, et. al. Standards Track [Page 9]
</pre>
|
