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
|
<pre>Network Working Group W. Behl
Request for Comments: 1538 McDATA Corporation
Category: Informational B. Sterling
McDATA Corporation
W. Teskey
I/O Concepts
October 1993
<span class="h1">Advanced SNA/IP : A Simple SNA Transport Protocol</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This RFC provides information for the Internet community about a
method for establishing and maintaining SNA sessions over an IP
internet. While the issues discussed may not be directly relevant to
the research problems of the Internet, they may be interesting to a
number of researchers and implementors. Any questions or comments
relative to the contents of this RFC may be sent to the following
Internet address: snaip@mcdata.com.
Table of Contents
<a href="#section-1">1</a>. Introduction.................................................. <a href="#page-2">2</a>
<a href="#section-2">2</a>. Motivation and Rationale...................................... <a href="#page-2">2</a>
<a href="#section-3">3</a>. SNA/IP Protocol Specification................................. <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a> Glossary..................................................... <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a> Conventions and Assumptions.................................. <a href="#page-3">3</a>
<a href="#section-3.3">3.3</a> The Protocol................................................. <a href="#page-3">3</a>
<a href="#section-3.3.1">3.3.1</a> Connection Establishment................................... <a href="#page-3">3</a>
<a href="#section-3.3.2">3.3.2</a> Data Transfer.............................................. <a href="#page-5">5</a>
<a href="#section-3.3.3">3.3.3</a> Connection Termination and Loss............................ <a href="#page-6">6</a>
<a href="#section-3.3.4">3.3.4</a> Session Data Flow.......................................... <a href="#page-7">7</a>
<a href="#section-3.3.5">3.3.5</a> State Transition Table for the Initiating Node............. <a href="#page-8">8</a>
<a href="#section-4">4</a>. LLC to SNA/IP Conversion...................................... <a href="#page-8">8</a>
<a href="#section-5">5</a>. Performance................................................... <a href="#page-8">8</a>
<a href="#section-6">6</a>. VTAM Definition............................................... <a href="#page-9">9</a>
<a href="#section-7">7</a>. Acknowledgments............................................... <a href="#page-9">9</a>
<a href="#section-8">8</a>. References.................................................... <a href="#page-9">9</a>
<a href="#section-9">9</a>. Security Considerations....................................... <a href="#page-10">10</a>
<a href="#section-10">10</a>. Authors' Addresses........................................... <a href="#page-10">10</a>
<a href="#section-11">11</a>. Disclaimer................................................... <a href="#page-10">10</a>
<span class="grey">Behl, Sterling & Teskey [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Advanced SNA/IP suggests a method for the transmission of SNA session
data over an IP network. This memo documents the SNA/IP protocol as
implemented in the McDATA LinkMaster(R) 6200 Network Gateway, McDATA
LinkMaster(R) 7100 Network Controller, and I/O Concepts X-Direct
TN3270 Server.
Advanced SNA/IP differs from other protocols designed to enable
routing of SNA session traffic over an IP network. SNA/IP was
originally designed for implementation in peripheral network nodes
like SNA gateways and downstream nodes (DSNs). It is the authors'
view, however, that SNA/IP could also be implemented in intermediate
network nodes like routers as the base for an LLC to IP subnet
gateway or data link switch function.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Motivation and Rationale</span>
The token-ring media access control (MAC) protocol 802.5 and logical
link control (LLC) protocol 802.2 were the first set of LAN protocols
used to provide a reliable and connection-oriented data link service
for SNA sessions in a LAN environment.
McDATA's experience with transporting SNA over 802.5 networks led to
an 802.3/802.2 (Ethernet) based variation. As prospective customers
were introduced to these Ethernet products, the question of
routability arose. Network administrators, accustomed to working
with Ethernet networks and the IP-based protocols, required an IP
routable solution. McDATA's "SNA over Ethernet" products were
bridgeable, but were not routable.
SNA sessions require a reliable and connection-oriented data link.
TCP running over IP provides a reliable and connection-oriented
transport service and has the added benefit of being routable. It
seemed the UDP and TCP protocols could be used in place of 802.2 Type
I and Type II levels of service used in traditional SNA token-ring
implementations. Advanced SNA/IP was created as a result of these
observations.
<span class="grey">Behl, Sterling & Teskey [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. SNA/IP Protocol Specification</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Glossary</span>
Data Link Switching (DLSw) - This is best described as a routing
protocol used for the conversion of LLC-based SNA sessions to an IP
form. The initial version of the DLSw protocol is documented in the
informational <a href="./rfc1434">RFC 1434</a> [<a href="#ref-1" title=""Data Link Switching: Switch-to-Switch Protocol"">1</a>].
Downstream Node (DSN) - An SNA Physical Unit (PU) type 2.0 or 2.1
device connected to the SNA network via a LAN (802.5, 802.3, etc.) as
opposed to an SDLC, X.25, or channel connection.
SNA Gateway - A device that provides a data link control (DLC)
conversion function for SNA PU type 5 (host) devices and LAN-
attached DSNs.
Subnet SNA Gateway - A device connected to both a traditional SNA
token-ring segment and an IP network that performs local termination
of the LLC connections, a mapping function of source address to
destination IP address, and a conversion (switching) function of LLC
to IP.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Conventions and Assumptions</span>
Frame formats are shown starting with the IP header. Other headers
will, of course, appear in the actual frames sent, but these headers,
and the numbers of them, will vary across MAC types.
It is assumed the reader is familiar with both the standard SNA
protocol (to the extent it applies to SNA Gateway and DSN functions)
and the base set of TCP/IP protocols. Where practical, the reader is
asked to refer to appropriate SNA and TCP/IP documentation.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. The Protocol</span>
Conceptually, there are three phases to the Advanced SNA/IP protocol:
the Connection Establishment phase, the Data Transfer phase, and the
Connection Termination phase.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Connection Establishment</span>
Connection Establishment involves the exchange of logical XID packets
between the connecting end nodes and culminates in the establishment
of a TCP connection. This process is similar to the IBM-specified
Test, XID, SABME and UA exchange used to establish a Type II 802.2
connection for SNA traffic [<a href="#ref-2" title=""Token-Ring Network Architecture Reference"">2</a>]. In place of the 802.2 Type I
messages, SNA/IP defines the following set of UDP datagrams:
<span class="grey">Behl, Sterling & Teskey [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
Logical Null XID
Use: Sent by an initiating node (such as a DSN) when the
connection to another SNA node is desired.
The Logical Null XID communicates the sending node's
desire to negotiate connection parameters. Once those
parameters are established, the Logical Null XID
communicates the sender's TCP port to which a connection
is to be made.
Format:
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
Source IP address: The IP address of the initiating
node.
Destination IP address: The IP address of the partner SNA
node.
Source UDP Port: Must match the TCP port number to be
used in the eventual TCP connection.
Destination UDP Port: A known port on the partner node
that expects SNA/IP datagrams.
XID Request
Use: Sent in response to a Logical Null XID and requests the
receiving node to send a Logical SNA XID datagram.
Format:
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
The source and destination IP and UDP port numbers follow,
logically, from those provided in the Logical Null XID
datagram.
The format of the XID Request and Logical Null XID are the
same. The two types are distinguished by the roles assumed by
the two nodes. In current implementations, the DSN initiates
the XID exchange by sending the Logical Null XID. The SNA
Gateway responds with the XID request.
<span class="grey">Behl, Sterling & Teskey [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
Logical SNA XID
Use: Sent in response to an XID Request and in the context of
SNA XID negotiation.
Format:
----------------------------------------------------
| IP Header | UDP Header | 0xBF | SNA XID data |
----------------------------------------------------
For PU 2.0 nodes, the SNA XID data consists of a Format 0 XID
[<a href="#ref-3" title=""Systems Network Architecture Formats"">3</a>].
For PU 2.1 nodes, the SNA XID data consists of a Format 3 XID
[<a href="#ref-3" title=""Systems Network Architecture Formats"">3</a>].
A typical Connection Establishment data flow appears below.
Node 1 Node 2
Logical Null XID ------------------------->
<------------------------ XID Request
Logical SNA XID -------------------------->
<------------------------ TCP SYN
TCP SYN ACK ----------------------------->
<------------------------ TCP ACK
Note: The source UDP port of the Logical Null XID equals the
destination TCP port of the TCP SYN segment.
Retries of the Logical Null XID by the initiating node should occur
periodically until an XID Request is received in reply. The frequency
of the retries is left up to the implementor. The lower bound on the
retry timer should be more than the expected round trip time for a
packet on the network.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Data Transfer</span>
There are no special packets defined for the Data Transfer phase.
Once the TCP connection is established, SNA Request Units (RUs) may
be exchanged between the two end nodes. The SNA session data appears
as TCP segment data. The only added SNA/IP requirement is that each
SNA message consisting of a Transmission Header (TH),
Request/Response Header (RH) and an optional Request/Response Request
Unit (RU) be preceded by a two octet length field. Examples of Data
<span class="grey">Behl, Sterling & Teskey [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
Transfer frames are shown below.
-------------------------------------------------------
| IP Header | TCP Header | SNA Msg 1 len | SNA Msg 1 |
-------------------------------------------------------
----------------------------------------------
| IP Header | TCP Header | SNA Msg 1 cont'd ->
----------------------------------------------
--------------------------------
| SNA Msg 2 len | SNA Msg 2 |
--------------------------------
The length field is passed in big endian format. 0 is a valid length
value.
The format of the SNA Message pieces are as defined by SNA [<a href="#ref-3" title=""Systems Network Architecture Formats"">3</a>].
Reliable and sequential delivery of data is provided by the TCP
protocol [<a href="#ref-5" title=""Internetworking with TCP/IP Volume I"">5</a>,<a href="#ref-6" title=""Transmission Control Protocol - DARPA Internet Program Protocol Specification"">6</a>].
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Connection Termination and Loss</span>
Either SNA node may, at any time, terminate the logical SNA
connection by issuing a TCP-level FIN segment. Dictates of the TCP
protocol apply to this termination process [<a href="#ref-5" title=""Internetworking with TCP/IP Volume I"">5</a>,<a href="#ref-6" title=""Transmission Control Protocol - DARPA Internet Program Protocol Specification"">6</a>].
A connection is also terminated, though not as cleanly, if a TCP
Reset segment is sent by either SNA node.
Once a connection is terminated, a new connection may be established
by the process outlined in the Connection Establishment section. For
reconnections made to the LinkMaster 6200 gateway, the same UDP
source port must be used by the initiating node. This implies that
the same TCP port is used. This requirement stems from the fact the
gateway may not always be aware that a TCP connection has been
terminated. This would happen if the DSN became disabled prior to
sending a FIN or Reset segment. Under these circumstances, SNA host
resources remain allocated and a reconnection from a DSN, which the
host believes to already be in session, is not allowed. By requiring
the DSN to use the same port when reestablishing a connection, the
LinkMaster 6200 is able to recognize when a reset of the host
connection is required.
<span class="grey">Behl, Sterling & Teskey [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Complete Session Data Flow</span>
Node 1 Node 2
Logical Null XID ------------------------->
(UDP Datagram)
Logical Null XID ------------------------->
(UDP Datagram)
<------------------------ XID Request
(UDP Datagram)
Logical SNA XID -------------------------->
(UDP Datagram)
<------------------------ TCP SYN
(TCP Message)
TCP SYN ACK ----------------------------->
(TCP Message)
<------------------------ TCP SYN
(TCP Message)
****************** Connection Established *******************
<------------------------ SNA ACTPU
(TCP Message)
SNA ACTPU Response --------------------->
(TCP Message)
<------------------------ SNA ACTLU
(TCP Message)
SNA ACTLU Response --------------------->
(TCP Message)
.
.
.
<------------------------ TCP FIN
(TCP Message)
TCP FIN ACK ------------------------>
(TCP Message)
<------------------------ TCP ACK
(TCP Message)
******************** Connection Closed *********************
Logical Null XID ----------------------->
(UDP Datagram)
.
.
.
.
<span class="grey">Behl, Sterling & Teskey [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>. State Transition Table for the Initiating Node</span>
Transition State
Given State | No Conn | Null XID Sent | SNA XID Sent | Conn Estb
------------+---------+---------------+--------------+-----------
No | | Internal Act. | |
Connection | | Stimulus | |
| | ---> Sends | |
| | 1st Null XID | |
------------+---------+---------------+--------------+-----------
Null XID | | Internal | XID Request |
Sent | | Timer Event | Received |
| | ----> Resend | ----> Sends |
| | Null XID | SNA XID |
------------+---------+---------------+--------------+-----------
SNA XID | | Internal | SNA XID | Indication
Sent | | Timer Event | Received | that TCP
| | ----> Resend | ----> Send | connection
| | Null XID | SNA XID | is estb.
| | | |
------------+---------+---------------+--------------+-----------
Connection | Indica- | | | SNA
Established | tion | | | Session
| that | | | Data
| TCP conn| | |
| term. | | |
A gateway state transition table is not provided here because the
state transitions are dependent on the nature of the SNA host
interface (3172 Channel Protocol, 3174 Channel Protocol, SDLC, etc.).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. LLC to SNA/IP Conversion</span>
The use of Advanced SNA/IP to convert conventional token ring- based
SNA traffic to a routable form is both conceivable and practical.
While interesting, a discussion of this application falls outside the
context of this RFC. Very briefly, it can be said that an SNA/IP-
based "subnet SNA gateway" application could do many of the things
being discussed in the context of the DLSw specification [<a href="#ref-1" title=""Data Link Switching: Switch-to-Switch Protocol"">1</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Performance</span>
The performance of SNA sessions running over an SNA/IP connection
will be affected by the bandwidth available on the network and by how
much traffic is on the network. SNA/IP is poised to take full
advantage of the prioritization and class of service enhancements
promised in the next generation of IP. Today, SNA/IP can take
<span class="grey">Behl, Sterling & Teskey [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
advantage of router packet prioritization schemes based on port
number. SNA/IP also leaves intact the standard SNA class of service
prioritization protocol.
Performance measures taken at McDATA comparing the throughput of
SNA/IP and LLC across a single token-ring segment showed
approximately a 15 percent decrease in the maximum transactions per
hour (1500 bytes to the DSN, 50 bytes out to the host) for SNA/IP.
This decrease is well within the expected levels given the added
processing requirements of TCP/IP over LLC in the LinkMaster 6200 and
LinkMaster 7100 operating environments.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. VTAM Definition</span>
The host VTAM definition of SNA/IP downstream nodes is dependent on
the gateway implementation. Downstream nodes may appear as switched
major nodes connected to an XCA or as downstream nodes connected to a
PU 2.0 controller [<a href="#ref-4" title=""VTAM Resource Definition Reference"">4</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
The authors wish to acknowledge that the definition of SNA/IP was a
collaborative effort involving many individuals ranging from
customers to sales and marketing personnel to engineers. Particular
thanks go to David Beal, Steve Cartwright, Tracey Floming, Audrey
McEwen, Mark Platte, Paul Schroeder, Chuck Weil, and Marty Wright,
who all played key roles in the development and testing of this
protocol and also in the editing of this RFC.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
[<a id="ref-1">1</a>] Dixon, R., and D. Kushi, "Data Link Switching: Switch-to-Switch
Protocol", <a href="./rfc1434">RFC 1434</a>, IBM, March 1993.
[<a id="ref-2">2</a>] "Token-Ring Network Architecture Reference", IBM document #SC30-
3374-02.
[<a id="ref-3">3</a>] "Systems Network Architecture Formats", IBM document #GA27-3136-
12.
[<a id="ref-4">4</a>] "VTAM Resource Definition Reference", IBM document #SC31-6438-1.
[<a id="ref-5">5</a>] Comer, D., "Internetworking with TCP/IP Volume I", Prentice Hall
1991.
[<a id="ref-6">6</a>] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, <a href="./rfc793">RFC 793</a>, USC/Information
Sciences Institute, September 1981.
<span class="grey">Behl, Sterling & Teskey [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1538">RFC 1538</a> Advanced SNA/IP October 1993</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This RFC does not address issues of security. SNA level security
procedures and protocols apply when SNA/IP is used as the transport.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Authors' Addresses</span>
Wilfred Behl
310 Interlocken Parkway
Broomfield, Colorado 80021
Phone: 303-460-4142
Email: wil@mcdata.com
Barbara Sterling
310 Interlocken Parkway
Broomfield, Colorado 80021
Phone: 303-460-4211
Email: bjs@mcdata.com
William Teskey
2125 112th Ave. North East
Suite 303
Bellevue, WA 98004
Phone: 206-450-0650
Email: wct@ioc-sea.com
Note: Any questions or comments relative to the contents of this RFC
should be sent to snaip@mcdata.com. This address will be used to
coordinate the handling of responses.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Disclaimer</span>
McDATA, the McDATA logo, and LinkMaster are registered trademarks of
McDATA Corporation. All other product names and identifications are
trademarks of their respective manufacturers, who are not affiliated
with McDATA Corporation.
Behl, Sterling & Teskey [Page 10]
</pre>
|
