File: rfc2166.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1907 lines) | stat: -rw-r--r-- 75,527 bytes parent folder | download | duplicates (5)
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
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907






Network Working Group                                     D. Bryant
Request for Comments: 2166                                3Com Corp
Category: Informational                                 P. Brittain
                                               Data Connection Ltd.
                                                          June 1997

                      APPN Implementer's Workshop
                         Closed Pages Document

                         DLSw v2.0 Enhancements

Status of this Memo

This memo provides information for the Internet community.  This memo
does not specify an Internet standard of any kind.  Distribution of
this memo is unlimited.

Abstract

   This document specifies

   - a set of extensions to RFC 1795 designed to improve the scalability
     of DLSw
   - clarifications to RFC 1795 in the light of the implementation
     experience to-date.

   It is assumed that the reader is familiar with DLSw and RFC 1795.  No
   effort has been made to explain these existing protocols or
   associated terminology.

   This document was developed in the DLSw Related Interest Group (RIG)
   of the APPN Implementers Workshop (AIW). If you would like to
   participate in future DLSw discussions, please subscribe to the DLSw
   RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com
   specifying 'subscribe aiw-dlsw' as the body of the message.

Table of Contents

   1. INTRODUCTION ................................................    3
   2. HALT REASON CODES............................................    3
   3. SCOPE OF SCALABILITY ENHANCEMENTS............................    4
   4. OVERVIEW OF SCALABILITY ENHANCEMENTS.........................    6
   5. MULTICAST GROUPS AND ADDRESSING..............................    7
   5.1 USING MULTICAST GROUPS......................................    8
   5.2 DLSW MULTICAST ADDRESSES....................................    8
   6. DLSW MESSAGE TRANSPORTS......................................    8
   6.1 TCP/IP CONNECTIONS ON DEMAND................................    9
    6.1.1 TCP CONNECTIONS ON DEMAND RACE CONDITIONS................    9



Bryant & Brittain            Informational                      [Page 1]

RFC 2166              APPN Implementer's Workshop             June 1997


   6.2 SINGLE SESSION TCP/IP CONNECTIONS...........................    9
    6.2.1 EXPEDITED SINGLE SESSION TCP/IP CONNECTIONS..............   10
     6.2.1.1 TCP PORT NUMBERS......................................   10
     6.2.1.2 TCP CONNECTION SETUP..................................   10
     6.2.1.3 SINGLE SESSION SETUP RACE CONDITIONS..................   10
     6.2.1.4 TCP CONNECTIONS WITH NON-MULTICAST CAPABLE DLSW PEERS.   11
   6.3 UDP DATAGRAMS...............................................   12
    6.3.1 VENDOR SPECIFIC FUNCTIONS OVER UDP.......................   12
    6.3.2 UNICAST UDP DATAGRAMS....................................   12
    6.3.3 MULTICAST UDP DATAGRAMS..................................   13
   6.4 UNICAST UDP DATAGRAMS IN LIEU OF IP MULTICAST...............   13
   6.5 TCP TRANSPORT...............................................   14
   7. MIGRATION SUPPORT............................................   14
   7.1 CAPABILITIES EXCHANGE.......................................   14
   7.2 CONNECTING TO NON-MULTICAST CAPABLE NODES...................   15
   7.3 COMMUNICATING WITH MULTICAST CAPABLE NODES..................   15
   8. SNA SUPPORT..................................................   16
   8.1 ADDRESS RESOLUTION..........................................   16
   8.2 EXPLORER FRAMES.............................................   16
   8.3 CIRCUIT SETUP...............................................   17
   8.4 EXAMPLE SNA SSP MESSAGE SEQUENCE............................   17
   8.5 UDP RELIABILITY.............................................   19
    8.5.1 RETRIES..................................................   19
   9. NETBIOS......................................................   20
   9.1 ADDRESS RESOLUTION..........................................   21
   9.2 EXPLORER FRAMES.............................................   21
   9.3 CIRCUIT SETUP...............................................   21
   9.4 EXAMPLE NETBIOS SSP MESSAGE SEQUENCE........................   22
   9.5 MULTICAST RELIABILITY AND RETRIES...........................   24
   10. SEQUENCING..................................................   24
   11. FRAME FORMATS...............................................   25
   11.1 MULTICAST CAPABILITIES CONTROL VECTOR......................   25
    11.1.1 DLSW CAPABILITIES NEGATIVE RESPONSE.....................   26
   11.2 UDP PACKETS................................................   26
   11.3 VENDOR SPECIFIC UDP PACKETS................................   27
   12. COMPLIANCE STATEMENT........................................   28
   13. SECURITY CONSIDERATIONS.....................................   29
   14. ACKNOWLEDGEMENTS............................................   29
   15. AUTHORS' ADDRESSES..........................................   30
   16. APPENDIX - CLARIFICATIONS TO RFC 1795.......................   31











Bryant & Brittain            Informational                      [Page 2]

RFC 2166              APPN Implementer's Workshop             June 1997


   1. Introduction

   This document defines v2.0 of Data Link Switching (DLSw) in the form
   of a set of enhancements to RFC 1795. These enhancements are designed
   to be fully backward compatible with existing RFC 1795
   implementations. As a compatible set of enhancements to RFC 1795,
   this document does not replace or supersede RFC 1795.

   The bulk of these enhancements address scalability issues in DLSw
   v1.0.  Reason codes have also been added to the HALT_DL and
   HALT_DL_NOACK SSP messages in order to improve the diagnostic
   information available.

   Finally, the appendix to this document lists a number of
   clarifications to RFC 1795 where the implementation experience to-
   date has shown that the original RFC was ambiguous or unclear. These
   clarifications should be read alongside RFC 1795 to obtain a full
   specification of the base v1.0 DLSw standard.

2. HALT Reason codes

   RFC 1795 provides no mechanism for a DLSw to communicate to its peer
   the reason for dropping a circuit.  DLSw v2.0 adds reason code fields
   to the HALT_DL and HALT_DL_NOACK SSP messages to carry this
   information.

   The reason code is carried as 6 bytes of data after the existing SSP
   header.  The format of these bytes is as shown below.

   Byte       Description
   0-1        Generic HALT reason code in byte normal format

   2-5        Vendor-specific detailed reason code

   The generic HALT reason code takes one of the following decimal
   values (which are chosen to match the disconnect reason codes
   specified in the DLSw MIB).

   1 - Unknown error
   2 - Received DISC from end-station
   3 - Detected DLC error with end-station
   4 - Circuit-level protocol error (e.g., pacing)
   5 - Operator-initiated (mgt station or local console)

   The vendor-specific detailed reason code may take any value.






Bryant & Brittain            Informational                      [Page 3]

RFC 2166              APPN Implementer's Workshop             June 1997


   All V2.0 DLSws must include this information on all HALT_DL and
   HALT_DL_NOACK messages sent to v2.0 DLSw peers.  For backwards
   compatibility with RFC 1795, DLSw V2.0 implementations must also
   accept a HALT_DL or HALT_DL_NOACK message received from a DLSw peer
   that does not carry this information (i.e. RFC 1795 format for these
   SSP messages).

3. Scope of Scalability Enhancements

   The DLSw Scalability group of the AIW identified a number of
   scalability issues associated with existing DLSw protocols as defined
   in RFC 1795:

   - Administration

     RFC 1795 implies the need to define the transport address of all
     DLSw peers at each DLSw.  In highly meshed situations (such as
     those often found in NetBIOS networks), the resultant
     administrative burden is undesirable.

   - Address Resolution

     RFC 1795 defines point to point TCP (or other reliable transport
     protocol) connections between DLSw peers.  When attempting to
     discover the location of an unknown resource, a DLSw sends an
     address resolution packet to each DLSw peer over these connections.
     In highly meshed configurations, this can result in a very large
     number of packets in the transport network.  Although each packet
     is sent individually to each DLSw peer, they are each identical in
     nature.  Thus the transport network is burdened with excessive
     numbers of identical packets.  Since the transport network is most
     commonly a wide area network, where bandwidth is considered a
     precious resource, this packet duplication is undesirable.

   - Broadcast Packets

     In addition to the address resolution packets described above, RFC
     1795 also propagates NetBIOS broadcast packets into the transport
     network.  The UI frames of NetBIOS are sent as LAN broadcast
     packets.  RFC 1795 propagates these packets over the point to point
     transport connections to each DLSw peer.  In the same manner as
     above, this creates a large number of identical packets in the
     transport network, and hence is undesirable.  Since NetBIOS UI
     frames can be sent by applications, it is difficult to predict or
     control the rate and quantity of such traffic.  This compounds the
     undesirability of the existing RFC 1795 propagation method for
     these packets.




Bryant & Brittain            Informational                      [Page 4]

RFC 2166              APPN Implementer's Workshop             June 1997


   - TCP (transport connection) Overhead

     As defined in RFC 1795, each DLSw maintains a transport connection
     to its DLSw peers.  Each transport connection guarantees in order
     packet delivery.   This is accomplished using acknowledgment and
     sequencing algorithms which require both CPU and memory at the DLSw
     endpoints in direct proportion to the number transport connections.
     The DLSw Scalability group has identified two scenarios where the
     number of transport connections can become significant resulting in
     excessive overhead and corresponding equipment costs (memory and
     CPU).   The first scenario is found in highly meshed DLSw
     configurations where the number of transport connections
     approximates n2 (where n is the number of DLSw peers).  This is
     typically found in DLSw networks supporting NetBIOS.  The second
     scenario is found  in networks  where many remote locations
     communicate to few central sites.  In this case, the central sites
     must support n transport connections  (where n is the number of
     remote sites).    In both scenarios the resultant transport
     connection overhead is considered undesirable depending upon the
     value of n.

   - LLC2 overhead

     RFC 1795 specifies that each DLSw provides local termination for
     the LLC2 (SDLC or other SNA reliable data link  protocol) sessions
     traversing the SSP.   Because these reliable data links provide
     guaranteed in order packet delivery, the memory and CPU overhead of
     maintaining these connections can also become significant.   This
     is particularly undesirable in the second scenario described above,
     because the number of reliable connections maintained at the
     central site is the aggregate of the connections maintained at each
     remote site.

   It is not the intent of this document to address all the undesirable
   scalability issues associated with RFC 1795.  This paper identifies
   protocol enhancements to RFC 1795 using the inherent multicast
   capabilities of the underlying transport network to improve the
   scalability of RFC 1795.  It is believed that the enhancements
   defined, herein, address many of the issues identified above, such as
   administration, address resolution, broadcast packets, and, to a
   lesser extent, transport overhead.  This paper does not address LLC2
   overhead.  Subsequent efforts by the AIW and/or DLSw Scalability
   group may address the unresolved scalability issues.








Bryant & Brittain            Informational                      [Page 5]

RFC 2166              APPN Implementer's Workshop             June 1997


   While it is the intent of this paper to accommodate all transport
   protocols as best as is possible, it is recognized that the multicast
   capabilities of many protocols is not yet well defined, understood,
   or implemented. Since TCP is the most prevalent DLSw transport
   protocol in use today, the DLSw Scalability group has chosen to focus
   its definition around IP based multicast services. This document only
   addresses the implementation detail of IP based multicast services.

   This proposal does not consider the impacts of IPv6 as this was
   considered too far from widespread use at the time of writing.

4. Overview of Scalability Enhancements

   This paper describes the use of multicast services within the
   transport network to improve the scalability of DLSw based
   networking.  There are only a few main components of this proposal:

   - Single session TCP connections

     RFC 1795 defines a negotiation protocol for DLSw peers to choose
     either two unidirectional or one bi-directional TCP connection.
     DLSws implementing the enhancements described in this document must
     support and use(whenever required and possible)a single bi-
     directional TCP connection between DLSw peers. That is to say that
     the single tunnel negotiation support of RFC 1795 is a prerequisite
     function to this set of enhancements. Use of two unidirectional TCP
     connections is only allowed (and required)for migration purposes
     when communicating with DLSw peers that do not implement these
     enhancements.

     This document also specifies a faster method for bringing up a
     single TCP connection between two DLSw peers than the negotiation
     used in RFC 1795.  This faster method, detailed in section 6.2.1,
     must be used where both peers are known to support DLSw v2.0.

   - TCP connections on demand

     Two DLSw peers using these enhancements will only establish a TCP
     connection when necessary.  SSP connections to DLSw peers which do
     not implement these enhancements are assumed to be established by
     the means defined in RFC 1795.  DLSws implementing v2.0 utilize UDP
     based transport services to send address resolution packets
     (CANUREACH_ex, NETBIOS_NQ_ex, etc.).  If a positive response is
     received, then a TCP connection is only established to the
     associated DLSw peer if one does not already exist.
     Correspondingly, TCP connections are brought down when there are no
     circuits to a DLSw peer for an implementation defined period of
     time.



Bryant & Brittain            Informational                      [Page 6]

RFC 2166              APPN Implementer's Workshop             June 1997


   - Address resolution through UDP

     The main thrust of this paper is to utilize non-reliable transport
     and the inherent efficiencies of multicast protocols whenever
     possible and applicable to reduce network overhead.  Accordingly,
     the address resolution protocols of SNA and NetBIOS are sent over
     the non-reliable transport of IP, namely UDP.  In addition, IP
     multicast/unicast services are used whenever address resolution
     packets must be sent to multiple destinations. This avoids the need
     to maintain TCP SSP connections between two DLSw peers when no
     circuits are active.  CANUREACH_ex and ICANREACH_ex packets can be
     sent to all the appropriate DLSw peers without the need for pre-
     configured peers or pre-established TCP/IP connections.  In
     addition, most multicast services (including TCP's MOSPF, DVMRP,
     MIP, etc.) replicate and propagate messages only as necessary to
     deliver to all multicast members.   This avoids duplication and
     excessive bandwidth consumption in the transport network.

     To further optimize the use of WAN resources, address resolution
     responses are sent in a directed fashion (i.e., unicast) via UDP
     transport whenever possible.   This avoids the need to setup or
     maintain TCP connections when they are not required.  It also
     avoids the bandwidth costs associated with broadcasting.

     Note: It is also permitted to send some address resolution traffic
     over existing TCP connections.  The conditions under which this is
     permitted are detailed in section 7.

   - NetBIOS broadcasts over UDP

     In the same manner as above, NetBIOS broadcast packets are sent via
     UDP (unicast and multicast) whenever possible and appropriate. This
     avoids the need to establish TCP connections between DLSw peers
     when there are no circuits required.   In addition, bandwidth in
     the transport network is conserved by utilizing the efficiencies
     inherent to multicast service implementation.  Details covering
     identification of these packets and proper propagation methods are
     described in section 10.

5. Multicast Groups and Addressing

   IP multicast services provides an unreliable datagram oriented
   delivery service to multiple parties. Communication is accomplished
   by sending and/or listening to specific 'multicast' addresses.  When
   a given node sends a packet to a specific address (defined to be
   within the multicast address range), the IP network (unreliably)
   delivers the packet to every node listening on that address.




Bryant & Brittain            Informational                      [Page 7]

RFC 2166              APPN Implementer's Workshop             June 1997


   Thus, DLSws can make use of this service by simply sending and
   receiving (i.e., listening for) packets on the appropriate multicast
   addresses. With careful planning and implementation, networks can be
   effectively partitioned and network overhead controlled by sending
   and listening on different addresses groups.  It is not the intent of
   this paper to define or describe the techniques by which this can be
   accomplished.  It is expected that the networking industry (vendors
   and end users alike) will determine the most appropriate ways to make
   use of the functions provided by use of DLSw multicast transport
   services.

5.1 Using Multicast Groups

   The multicast addressing as described above can be effectively used
   to limit the amount of broadcast/multicast traffic in the network.
   It is not the intent of this document to describe how individual
   DLSw/SSP implementations would assign or choose group addresses.  The
   specifics of how this is done and exposed to the end user is an issue
   for the specific implementor.  In order to provide for multivendor
   interoperability and simplicity of configuration, however, this paper
   defines a single IP multicast address, 224.0.10.000, to be used as a
   default DLSw multicast address.  If a given implementation chooses to
   provide a default multicast address, it is recommended this address
   be used.  In addition, this address should be used for both
   transmitting and receiving of multicast SSP messages.  Implementation
   of a default multicast address is not, however, required.

5.2 DLSw Multicast Addresses

   For the purpose of long term interoperability, the AIW has secured a
   block of IP multicast addresses to be used with DLSw.  These
   addresses are listed below:

   Address Range        Purpose
   --------------------------------------------------------------------
   224.0.10.000         Default multicast address
   224.0.10.001-191     User defined DLSw multicast groups
   224.0.10.192-255     Reserved for future use by the DLSw RIG in DLSw
                        enhancements

6. DLSw Message Transports

   With the introduction of DLSw Multicast Protocols, SSP messages are
   now sent over two distinct transport mechanisms: TCP/IP connections
   and UDP services.  Furthermore, the UDP datagrams can be sent to two
   different kinds of IP addresses: unique IP addresses (generally
   associated with a specific DLSw), and multicast IP addresses
   (generally associated with a group of DLSw peers).



Bryant & Brittain            Informational                      [Page 8]

RFC 2166              APPN Implementer's Workshop             June 1997


6.1 TCP/IP Connections on Demand

   As is the case in RFC 1795, TCP/IP connections are established
   between DLSw peers.  Unlike RFC 1795, however, TCP/IP connections are
   only established to carry reliable circuit data (i.e., LLC2 based
   circuits).  Accordingly, a TCP/IP connection is only established to a
   given DLSw peer when the first circuit to that DLSw is required
   (i.e., the origin DLSw must send a CANUREACH_CS to a target DLSw peer
   and there is no existing TCP connection between the two).  In
   addition, the TCP/IP connection is brought down an implementation
   defined amount of time after the last active (not pending) circuit
   has terminated.  In this way, the overhead associated with
   maintaining TCP connections is minimized.

   With the advent of TCP connections on demand, the activation and
   deactivation of TCP connections becomes a normal occurrence as
   opposed to the exception event it constitutes in RFC 1795.  For this
   reason, it is recommended that implementations carefully consider the
   value of SNMP traps for this condition.

6.1.1 TCP Connections on Demand Race Conditions

   Non-circuit based SSP packetsn (e.g.,CANUREACH_ex, etc.) may still be
   sent/received over TCP connections after all circuits have been
   terminated.  Taking this into account implementations should still
   gracefully terminate these TCP connections once the connection is no
   longer supporting circuits.  This may require an implementation to
   retransmit request frames over UDP when no response to a TCP based
   unicast request is received and the TCP connection is brought down.
   This is not required in the case of multicast requests as these are
   received over the multicast transport mechanism.

6.2 Single Session TCP/IP Connections

   RFC 1795 defines the use of two unidirectional TCP/IP sessions
   between any pair of DLSw peers using read port number 2065 and write
   port number 2067.  Additionally, RFC 1795 allows for implementations
   to optionally use only one bi-directional TCP/IP session.  Using one
   TCP/IP session between DLSw peers is believed to significantly
   improve the performance and scalability of DLSw protocols.
   Performance is improved because TCP/IP acknowledgments are much more
   likely to be piggy-backed on real data when TCP/IP sessions are used
   bi-directionally.  Scalability is improved because fewer TCP control
   blocks, state machines, and associated message buffers are required.
   For these reasons, the DLSw enhancements defined in this paper
   REQUIRE the use of single session TCP/IP sessions.





Bryant & Brittain            Informational                      [Page 9]

RFC 2166              APPN Implementer's Workshop             June 1997


   Accordingly, DLSws implementing these enhancements must carry the TCP
   Connections Control Vector in their Capabilities Exchange.  In
   addition, the TCP Connections Control Vector must indicate support
   for 1 connection.

6.2.1 Expedited Single Session TCP/IP Connections

   In RFC 1795, single session TCP/IP connections are accomplished by
   first establishing two uni-directional TCP connections, exchanging
   capabilities, and then bringing down one of the connections.  In
   order to avoid the unnecessary flows and time delays associated with
   this process, a new single session bi-directional TCP/IP connection
   establishment algorithm is defined.

6.2.1.1 TCP Port Numbers

   DLSws implementing these enhancements will use a TCP destination port
   of 2067 (as opposed to RFC 1795 which uses 2065) for single session
   TCP connections.  The source port will be a random port number using
   the established TCP norms which exclude the possibility of either
   2065 or 2067.

6.2.1.2 TCP Connection Setup

   DLSw peers implementing these enhancements will establish a single
   session TCP connection whenever the associated peer is known to
   support this capability.  To do this, the initiating DLSw simply
   sends a TCP setup request to destination port 2067.  The receiving
   DLSw responds accordingly and the TCP three way handshake ensues.
   Once this handshake has completed, each DLSw is notified and the DLSw
   capabilities exchange ensues.  As in RFC 1795, no flows may take
   place until the capabilities exchange completes.

6.2.1.3 Single Session Setup Race Conditions

   The new expedited single session setup procedure described above
   opens up the possibility of a race condition that occurs when two
   DLSw peers attempt to setup single session TCP connections to each
   other at the same time.  To avoid the establishment of two TCP
   connections, the following rules are applied when establishing
   expedited single session TCP connections:

   1.If an inbound TCP connect indication is received on port 2067 while
     an outbound TCP connect request (on port 2067) to the same DLSw (IP
     address) is in process or outstanding, the DLSw with the higher IP
     address will close or reject the connection from the DLSw with the
     lower IP address.




Bryant & Brittain            Informational                     [Page 10]

RFC 2166              APPN Implementer's Workshop             June 1997


   2.To further expedite the process, the DLSw with the lower IP address
     may choose (implementation option) to close its connection request
     to the DLSw with the higher address when this condition is
     detected.
   3.If the DLSw with the lower IP address has already sent its
     capabilities exchange request on its connection to the DLSw with
     the higher IP address, it must resend its capabilities exchange
     request over the remaining TCP connection from its DLSw peer (with
     the higher IP address).
   4.The DLSw with the higher IP address must ignore any capabilities
     exchange request received over the TCP connection to be terminated
     (the one from the DLSw with the lower IP address).

6.2.1.4 TCP Connections with Non-Multicast Capable DLSw peers

   During periods of migration, it is possible that TCP connections
   between multicast capable and non-multicast capable DLSw peers will
   occur.  It is also possible that multicast capable DLSws may attempt
   to establish TCP connections with partners of unknown capabilities
   (e.g., statically defined peers).  To handle these conditions the
   following additional rules apply to expedited single session TCP
   connection setup:

   1.If the capability of a DLSw peer is not known, an implementation
     may choose to send the initial TCP connect request to either port
     2067 (expedited single session setup) or port 2065 (standard RFC
     1795 TCP setup).
   2.If a multicast capable DLSw receives an inbound TCP connect request
     on port 2065 while processing an outbound request on 2067 to the
     same DLSw, the sending DLSw will terminate its 2067 request and
     respond as defined in RFC 1795 with an outbound 2065 request
     (standard RFC 1795 TCP setup).
   3.If a multicast capable DLSw receives an indication that the DLSw
     peer is not multicast capable (the port 2067 setup request times
     out or a port not recognized rejection is received), it will send
     another connection request using port 2065 and the standard RFC
     1795 session setup protocol.














Bryant & Brittain            Informational                     [Page 11]

RFC 2166              APPN Implementer's Workshop             June 1997


6.3 UDP Datagrams

   As mentioned above, UDP datagrams can be sent two different ways:
   unicast (e.g., sent to a single unique IP address) or multicast
   (i.e., sent to an IP multicast address).  Throughout this document,
   the term UDP datagram will be used to refer to SSP messages sent over
   UDP, while unicast and multicast SSP messages will refer to the
   specific type/method of UDP packet transport.  In either case,
   standard UDP services are used to transport these packets.  In order
   to properly parse the inbound UDP packets and deliver them to the SSP
   state machines, all DLSw UDP packets will use the destination port of
   2067.

   In addition, the checksum function of UDP remains optional for DLSw
   SSP messages.  It is believed that the inherent CRC capabilities of
   all data link transports will adequately protect SSP packets during
   transmission.  And the incremental exposure to intermediate nodal
   data corruption is negligible.  For further information on UDP packet
   formats see the �Frame Formats� section.

6.3.1 Vendor Specific Functions over UDP

   In order to accommodate vendor specific capabilities over UDP
   transport, a new SSP packet format has been defined.  This new packet
   format is required because message traffic of this type is not
   necessarily preceded by a capabilities exchange.  Accordingly, DLSw's
   wishing to invoke a vendor specific function may send out this new
   SSP packet format over UDP.

   Because this packet can be sent over TCP connections and non-
   multicast capable nodes may not be able to recognize it,
   implementations may only send this packet over TCP to DLSw peers
   known to understand this packet format (i.e., multicast capable).  To
   avoid this situation in the future, DLSws implementing these
   enhancements must ignore SSP packets with an unrecognized DLSw
   version number in the range of x'31' to x'3F'.  Further information
   and the precise format for this new packet type is described below in
   the �Frame Formats� section.

6.3.2 Unicast UDP Datagrams

   Generically speaking, a unicast UDP datagram is utilized whenever an
   SSP message (not requiring reliable transport) must be sent to a
   unique set (not all) of DLSw peers.  This avoids the overhead of
   having to establish and maintain TCP connections when they are not
   required for reliable data transport.





Bryant & Brittain            Informational                     [Page 12]

RFC 2166              APPN Implementer's Workshop             June 1997


   A typical example of when unicast UDP might be used would be an
   ICANREACH_ex response from a peer DLSw (with which no TCP connection
   currently exists).  In this case, the sending DLSw knows the IP
   address of the intended receiver and can simply send the response via
   unicast UDP.  In addition, there are a number of NetBIOS cases where
   unicast UDP is used to handle UI frames directed to a specific DLSw
   (e.g., NetBIOS STATUS_RESPONSE).  Further detail is provided in the
   NetBIOS section of this document.

6.3.3 Multicast UDP Datagrams

   In a broad sense, multicast UDP datagrams are used whenever a given
   SSP message must be sent to multiple DLSw peers.  In the case of SNA,
   this is primarily the CANUREACH_ex packets.  In the case of NetBIOS,
   multicast datagrams are used to send broadcast UI frames such as
   NetBIOS user datagrams and broadcast datagrams.

   Note, however, it is sometimes possible to avoid broadcasting certain
   NetBIOS frames that would otherwise be broadcast in the LAN
   environment.  This is typically accomplished using name caching
   techniques not described in this paper.  In cases of this type when a
   single destination DLSw can be determined, unicast transport can be
   used to send the 'broadcast' NetBIOS frame to a single destination.
   A more detailed listing of NetBIOS SSP packets and transport methods
   can be found in the NetBIOS section of this document.

6.4 Unicast UDP Datagrams in Lieu of IP Multicast

   Because the use of IP multicast services is actually a function of IP
   itself and not DLSw proper, it is possible for implementations to
   simply make use of the UDP transport mechanisms described in this
   paper without making direct use of the IP multicast function.  While
   this is not considered to be as efficient as using multicast
   transport mechanisms, this practice is not explicitly prohibited.

   Implementations which choose to make use of UDP transport in this
   manner must first know the IP address of all the potential target
   DLSw peers and send individual unicast packets to each.  How this
   information is obtained and/or maintained is outside the scope of
   this paper.

   As a matter of compliance, implementers need not send SSP packets
   outbound over UDP as there are some conditions where this may not be
   necessary or desirable.  It is, however, required that implementers
   provide an option to receive SSP packets over UDP.






Bryant & Brittain            Informational                     [Page 13]

RFC 2166              APPN Implementer's Workshop             June 1997


6.5 TCP Transport

   Despite the addition of UDP based packet transport, TCP remains the
   fundamental form of communications between DLSw peers.  In
   particular, TCP is still used to carry all LLC2 based circuit data.

   Throughout this document wherever UDP unicast (not multicast) is
   discussed, the reader should be aware that TCP may be used instead.
   Moreover, it is strongly recommended that TCP be used in preference
   to UDP whenever a TCP connection to the destination already exists.
   Implementations, however, should be prepared to receive SSP packets
   from either transport (TCP or UDP).

7. Migration Support

   It is anticipated that some networks will experience a transition
   stage where both RFC 1795 (referred to as 'non-multicast' DLSws) and
   It will be important for these two DLSw node types to interoperate
   and thus the following accommodations for non-multicast DLSws are
   required:

7.1 Capabilities Exchange

   In order to guarantee both backward and forward capability, DLSws
   which implement these multicast enhancements will carry a �Multicast
   Capabilities� Control Vector in their capabilities exchange (see RFC
   1795 for an explanation of capabilities exchange protocols).
   Presence of the Multicast Capabilities control vector indicates
   support for the protocols defined in this document on a per DLSw peer
   basis.  Conversely, lack of the Multicast Capabilities control vector
   indicates no support for these extensions on a per DLSw peer basis.

   Additionally, nodes implementing these enhancement will carry a
   modified DLSw Version control vector (x'82') indicating support for
   version 2 release 0.

   Lastly, presence of these control vectors mandates a TCP Connections
   Control Vector indicating support for 1 TCP connection in the same
   Capabilities exchange.

   If a multicast capable DLSw receives a Capabilities Exchange CV that
   includes the Multicast Capabilites CV but does not meet the above
   criteria, it must reject the capabilities exchange by sending a
   negative response as described in section 11.1.1.







Bryant & Brittain            Informational                     [Page 14]

RFC 2166              APPN Implementer's Workshop             June 1997


7.2 Connecting to Non-Multicast Capable Nodes

   It is assumed that TCP connections to DLSw peers which do not support
   multicast services are established by some means outside the scope of
   this paper (i.e., non-multicast partner addresses are configured by
   the customer).  TCP connections must be established and maintained to
   down level nodes in the exact same manner as RFC 1795 requires,
   establishes, and maintains them.  And because non-multicast DLSw
   peers will not indicate support for multicast services in their
   capabilities exchange, a multicast capable DLSw will know all its
   non-multicast peers.

7.3 Communicating with Multicast Capable Nodes

   Because non-multicast nodes will not receive SSP frames via UDP
   (unicast or multicast) transmission, SSP messages to these DLSw peers
   must be sent over TCP connections.  Therefore, nodes which implement
   the multicast protocol enhancements must keep track of which DLSw
   peers do not support multicast extensions (as indicated in the
   capabilities exchange).  When a given packet is sent out via
   multicast services, it must also be sent over multicast UDP(to reach
   other multicast capable DLSw peers) and over the TCP connection to
   each non-multicast node.  And although the multicast service requires
   periodic retransmissions (for reliability reasons), this is not the
   case with TCP connections to non-multicast nodes. Therefore,
   multicast capable DLSws should not resend SSP packets over TCP
   transport connection but rather, rely upon TCP to recover any lost
   packets. Furthermore, communications with non-multicast nodes should
   be in exact compliance with RFC 1795 protocols.

   When sending a unicast UDP message, it is important to know that the
   destination DLSw supports multicast services.  This knowledge can be
   obtained from previous TCP connections/capabilities exchanges or
   inferred from a previously received UDP message, but how this
   information is obtained is outside the scope of this paper.  In the
   latter case, if the DLSw is non-multicast, then there would be a TCP
   connection to it and it would be known to be non-multicast.  If it is
   multicast capable and a TCP connection is in existence, then its
   level is known (via the prior capabilities exchange).  If its
   capabilities are not known and there is not an existing TCP
   connection, then it can be implied to be multicast capable by virtue
   of a cached entry but no active TCP connection (e.g., TCP peer on
   demand support).  This inference, however, could be erroneous in
   cases where the TCP connection (to a non-multicast DLSw) has failed
   for some reason. But normal UDP based unicast verification mechanisms
   will detect no active path to the destination and circuit setup will
   proceed correctly (i.e., succeed or fail in accordance with true
   connectivity).



Bryant & Brittain            Informational                     [Page 15]

RFC 2166              APPN Implementer's Workshop             June 1997


8. SNA Support

   Note: This paper does not attempt to address the unique issues
   presented by SNA/HPR and its non-ERP data links

   In SNA protocols the generalized packet sequence of interest is a
   test frame exchange followed by an XID exchange.  In all cases, DLSw
   uses the CANUREACH_ex and ICANREACH_ex SSP packets to complete
   address resolution and circuit establishment.  The following table
   describes how these packets are transported via UDP between two
   multicast capable DLSw peers.

                                              Transport
     Message Event          Action            Mechanism         Retry
   --------------------------------------------------------------------
   TEST                 SEND CANUREACH_ex    Multicast/Unicast   Yes
   TEST RESPONSE        SEND ICANREACH_ex       Unicast          No


   The following paragraphs provide more detail on how UDP transport and
   multicast protocol enhancements are used to establish SNA data links.

8.1 Address Resolution

   When a DLSw receives an incoming test frame from an attached data
   link, the assumption is that this is an exploratory frame in
   preparation for an XID exchange and link activation.  The DLSw must
   determine a correlation between the destination LSAP (mac and sap
   pairing) and some other DLSw in the transport network.  This paper
   generically refers to this process as �address resolution�.

8.2 Explorer frames

   Address resolution messages may be sent over a TCP connection to a
   multicast capable DLSw peer if such a connection already exists in
   order that they take advantage of the guaranteed delivery of TCP.
   This is particularly recommended for ICANREACH_ex frames.














Bryant & Brittain            Informational                     [Page 16]

RFC 2166              APPN Implementer's Workshop             June 1997


8.3 Circuit Setup

   Circuit setup is accomplished in the same manner as described in RFC
   1795.  More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK,
   XIDFRAME, etc.  are all sent over the TCP connection to the
   appropriate DLSw.  This, of course, assumes the existence of a TCP
   connection between the DLSw peers.  If the sending DLSw (sending a
   CANUREACH_cs ) detects no active TCP connection to the DLSw peer,
   then a TCP connection setup is initiated and the packet sent.  All
   other circuit setup (and takedown) related sequences are now passed
   over the TCP connection.

8.4 Example SNA SSP Message Sequence

   The following diagram provides an example sequence of flows
   associated with an SNA LLC circuit setup.  All flows and states
   described below correspond precisely with those defined in RFC 1795.
   The only exception is the addition of a TCP connection setup and DLSw
   capabilities exchange that occurs when the origin DLSw must send a
   CANUREACH_CS and no TCP connection yet exists to the target DLSw
   peer.






























Bryant & Brittain            Informational                     [Page 17]

RFC 2166              APPN Implementer's Workshop             June 1997


 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

TEST_cmd      DLC_RESOLVE_C    CANUREACH_ex               TEST_cmd
----------->  ----------->     ----------->               ---------->
   TEST_rsp   DLC_RESOLVE_R    ICANREACH_ex                 TEST_rsp
 <---------    <-----------   <-----------                <----------
null XID      DLC_XID
----------->  ----------->
              circuit_start

                           TCP Connection Setup
                             <------------->
                            Capabilities Exch.
                             <------------->

                             CANUREACH_cs    DLC_START_DL
                             ----------->    ----------->
                                              resolve_pending
                             ICANREACH_cs    DLC_DL_STARTED
                             <-----------    <-------------
           circuit_established                circuit_pending
                              REACH_ACK
                              ----------->  circuit_established

                               XIDFRAME         DLC_XID       null XID
                               ----------->     --------->    -------->
        XID        DLC_XID      XIDFRAME         DLC_XID          XID
  <--------   <-----------   <-----------    <-----------    <--------
    XIDs         DLC_XIDs      XIDFRAMEs        DLC_XIDs         XIDs
<---------->  <---------->   <------------>  <------------>  <--------->
SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
----------->  ----------->     ----------->    ----------->    -------->
              connect_pending                 contact_pending

          UA     DLC_CONTACT     CONTACTED    DLC_CONTACTED          UA
  <---------   <-----------  <-----------    <-----------    <--------
                  connected                      connected
IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
<---------->  <----------->  <------------>  <------------>  <-------->




Bryant & Brittain            Informational                     [Page 18]

RFC 2166              APPN Implementer's Workshop             June 1997


8.5 UDP Reliability

   It is important to note, that UDP (unicast and multicast)transport
   services do not provide a reliable means of delivery.  Existing RFC
   1795 protocols guarantee the delivery (or failure notification) of
   CANUREACH_ex and ICANREACH_ex messages.  UDP will not provide the
   same level of reliability.  It is, therefore, possible that these
   messages may be lost in the network and (CANUREACH_ex) retries will
   be necessary.

8.5.1 Retries

   Test Frames are generally initiated by end stations every few
   seconds.  Many existing RFC 1795 DLSw implementations take advantage
   of the reliable SSP TCP connections and filter out end station Test
   frame retries when a CANUREACH_ex is outstanding.  Given the
   unreliable nature of UDP transport for these messages, however, this
   filtering technique may not be advisable.  Neither RFC 1795 nor this
   paper address this issue specifically.  It is simply noted that the
   UDP transport mechanism is unreliable and implementations should take
   this into account when determining a scheme for Test frame filtering
   and explorer retries.  Accordingly, the �Retry� section in the table
   above only serves as an indicator of situations where retries may be
   desirable and/or necessary, but does not imply any requirement to
   implement retries. Also note, that retry logic only applies to non-
   response type packets.  It is not appropriate to retry response type
   SSP packets (i.e., ICANREACH_ex) as there is no way of knowing if the
   original response was ever received (and whether retry is necessary).
   So in the case of SNA, CANUREACH_ex messages may need retry logic and
   ICANREACH_ex messages do not.





















Bryant & Brittain            Informational                     [Page 19]

RFC 2166              APPN Implementer's Workshop             June 1997


9. NetBIOS

   With the introduction of DLSw Multicast transport, all multicast
   NetBIOS UI frames are carried outside the TCP connections between
   DLSw peers (i.e., via UDP datagrams).  The following table defines
   the various NetBIOS UI frames and how they are transported via UDP
   between multicast capable DLSw peers:

                                              Transport
Message Event            Action               Mechanism           Retry
---------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY     SEND DATAFRAME       Multicast            Yes
ADD_NAME_QUERY           SEND NETBIOS_ANQ     Multicast            Yes
ADD_NAME_RESPONSE        SEND NETBIOS_ANR     Unicast1             No
NAME_IN_CONFLICT         SEND DATAFRAME       Multicast            No
STATUS_QUERY             SEND DATAFRAME       Unicast/Multicast(2) Yes
STATUS_RESPONSE          SEND DATAFRAME       Multicast(5)         No
TERMINATE_TRACE (x'07')  SEND DATAFRAME       Multicast            No
TERMINATE_TRACE (X'13')  SEND DATAFRAME       Multicast            No
DATAGRAM                 SEND DATAFRAME(3)    Unicast/Multicast(2) No
DATAGRAM_BROADCAST       SEND DATAFRAME       Multicast            No
NAME_QUERY               SEND NETBIOS_NQ_ex   Unicast/Multicast(2) Yes
NAME_RECOGNIZED          SEND NETBIOS_NR_ex   Unicast(4)           No

   Note 1:
   Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP message
   is returned via unicast UDP to the originator of the NETBIOS_ANQ
   message.

   Note 2:
   These frames may be sent either Unicast or Multicast UDP.  If the
   implementation has sufficient cached information to resolve the
   NetBIOS datagram destination to a single DLSw peer, then the SSP
   message can and should be sent via unicast.  If the cache does not
   contain such information then the resultant SSP message must be sent
   via multicast UDP.

   Note 3:
   Note that this frame is sent as either a DATAFRAME or DGRMFRAME
   according to the rules as specified in RFC 1795.

   Note 4:
   Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP message
   is returned via unicast UDP to the originator of the NETBIOS_NQ_ex
   frame.  Notice that although the NAME_RECOGNIZED frame is sent as an
   All Routes Explorer (source routing LANs only) frame, the resultant
   NETBIOS_NR_ex is sent as a unicast UDP directed response to the DLSw
   originating the NETBIOS_NQ_ex.  This is because there is no value in



Bryant & Brittain            Informational                     [Page 20]

RFC 2166              APPN Implementer's Workshop             June 1997


   sending NETBIOS_NR_ex as a multicast packet in the transport network.
   The use of ARE transmission in the LAN environment is to accomplish
   some form of load sharing in the source routed LAN environment.
   Since no analogous capability exists in the (TCP) transport network,
   it is not necessary to emulate this function there.  It is important
   to note, however, that when converting a received NETBIOS_NR_ex to a
   NAME_RECOGNIZED frame, the DLSw sends the NAME_RECOGNIZED frame onto
   the LAN as an ARE (source routing LANs only) frame.  This preserves
   the source route load sharing in the LAN environments on either side
   of the DLSw transport network.

   Note 5:
   Although RFC 1795 does not attempt to optimize STATUS_RESPONSE
   processing, it is possible to send a STATUS_RESPONSE as a unicast UDP
   response.  To do this, DLSws receiving an incoming SSP DATAFRAME
   containing a STATUS_QUERY must remember the originating DLSw's
   address and STATUS_QUERY correlator.  Then upon receipt of the
   corresponding STATUS_RESPONSE, the DLSw responds via unicast UDP to
   the originating DLSw(using the remembered originating DLSw address).
   Note, however, that in order to determine whether a frame is a
   STATUS_QUERY, all multicast capable DLSw implementations will need to
   parse the contents of frames that would normally be sent as DATAFRAME
   SSP messages.

   All other multicast frames are sent into the transport network using
   the appropriate multicast group address.

9.1 Address Resolution

   Typical NetBIOS circuit setup using multicast services is essentially
   the same as specified in RFC 1795.  The only significant difference
   is that NETBIOS_NQ_ex messages are sent via UDP to the appropriate
   unicast/multicast IP address and the NETBIOS_NR_ex is sent via
   unicast UDP to the DLSw originating the NETBIOS_NQ_ex.

9.2 Explorer Frames

   Address resolution messages may be sent over a TCP connection to a
   multicast capable partner if such a connection already exists in
   order that they take advantage of the guaranteed delivery of TCP.
   This is particularly recommended for NETBIOS_NR_ex frames.

9.3 Circuit Setup

   Following successful address resolution, a NetBIOS end station
   typically sends a SABME frame to initiate a formal LLC2 connection.
   Receipt of this message results in normal circuit setup as described
   in RFC 1795 (and the SNA case described above).  That is to say that



Bryant & Brittain            Informational                     [Page 21]

RFC 2166              APPN Implementer's Workshop             June 1997


   the CANUREACH_cs messages etc. are sent on a TCP connection to the
   appropriate DLSw peer.  If no such TCP connection exists, one is
   brought up.

9.4 Example NetBIOS SSP Message Sequence

   The following diagram provides an example sequence of flows
   associated with a NetBIOS circuit setup.  All flows and states
   described below correspond precisely with those defined in RFC 1795.
   The only exception is the addition of a TCP connection setup and DLSw
   capabilities exchange that occurs when the origin DLSw must send a
   CANUREACH_cs and no TCP connection yet exists to the target DLSw
   peer.






































Bryant & Brittain            Informational                     [Page 22]

RFC 2166              APPN Implementer's Workshop             June 1997


 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

NAME_QUERY    DLC_DGRM        NETBIOS_NQ_ex   DLC_DGRM       NAME_QUERY
----------->  ----------->    ----------->    ----------->   --------->

  NAME_RECOG    DLC_DGRM      NETBIOS_NR_ex     DLC_DGRM    NAME_RECOG
<-----------  <------------   <-----------    <-----------  <---------

SABME         DLC_CONTACTED
----------->  ----------->
               circuit_start

                            TCP Connection Setup
                              <------------->
                            Capabilities Exch.
                              <------------->

                              CANUREACH_cs    DLC_START_DL
                              ----------->    ----------->
                                             resolve_pending


                              ICANREACH_cs    DLC_DL_STARTED
                              <-----------    <-----------
            circuit_established                circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              CONTACT         DLC_CONTACT     SABME
                              ----------->    ----------->    --------->
             connect_pending                   contact_pending

          UA   DLC_CONTACT       CONTACTED    DLC_CONTACTED           UA
  <---------   <-----------   <-----------    <-----------    <---------
                connected                        connected

   IFRAMEs       DLC_INFOs       IFRAMEs        DLC_INFOs       IFRAMEs
<------------> <------------> <------------>  <------------>  <-------->





Bryant & Brittain            Informational                     [Page 23]

RFC 2166              APPN Implementer's Workshop             June 1997


9.5 Multicast Reliability and Retries

   In the case of NetBIOS, many more packets are being sent via UDP than
   in the SNA case.  Therefore, the exposure to the unreliability of
   these services is greater than that of SNA. For address resolution
   frames, such as NAME_QUERY, etc., successful message delivery is an
   issue.  In addition, the retry interval for these types of frames is
   considerably shorter than SNA with the defaults being: retry interval
   = 0.5 seconds and retry count = 6.  Once again, neither RFC 1795 nor
   this paper attempt to address the issue of LAN frame filtering
   optimizations. This issue is outside the scope of this paper.  But it
   is important for implementers to recognize the inherent unreliable
   nature of UDP transport services for frames of this type and to
   implement retry schemes that are appropriate to successful operation.
   Again, it is only appropriate to consider retry of non-response type
   packets.  Specific NetBIOS messages where successful message delivery
   is considered important (and retries possibly necessary) are
   indicated in the table above with an �Yes� in the �Retry� column.

10. Sequencing

   It is important to note that UDP transport services do not provide
   guaranteed packet sequencing like TCP does for RFC 1795.  In a steady
   state network, in order packet delivery can be generally assumed.
   But in the presence of network outages and topology changes, packets
   may take alternate routes to the destination and arrive out of
   sequence with respect to their original transmission order.  For SNA
   address resolution this should not be a problem given that there is
   no inherent significance to the order of packets being transmitted
   via UDP.

   In the case of NetBIOS, in order delivery is not guaranteed in the
   normal case (e.g., LANs).  This is because LAN broadcasting
   mechanisms suffer the same problems of packet sequencing as do WAN
   multicast mechanisms.  But one might argue the greater likelihood of
   topology related changes in the WAN environment and thus a greater
   level of concern.  The vast majority of NetBIOS UI frames (being
   handled via UDP and Multicast) have correlator values and do not rely
   upon packet sequencing.












Bryant & Brittain            Informational                     [Page 24]

RFC 2166              APPN Implementer's Workshop             June 1997


   The only NetBIOS frames of special note would be: DATAGRAM,
   DATAGRAM_BROADCAST, and STATUS_RESPONSE.  In the case of DATAGRAM and
   DATAGRAM_BROADCAST it is generally assumed that datagrams do not
   provide any guarantee of in order packet delivery.  Thus applications
   utilizing this NetBIOS service are assumed to have no dependency on
   in order packet delivery.  STATUS_RESPONSE can actually be sent as a
   sequence of STATUS_RESPONSE messages.  In cases where this occurs,
   the STATUS_RESPONSE will be exposed to potential out of sequence
   delivery.

11. Frame Formats

11.1 Multicast Capabilities Control Vector

   This control vector is carried in the Capabilities Exchange Request.
   When present, it must be accompanied by a TCP Connections Control
   Vector indicating support for 1 TCP/IP connection and a DLSw version
   CV indicating support for version 2 release 0.  Like all control
   vectors in this SSP message, it is an LT structure.  LT structures
   consist of a 1 byte length field followed by a 1 byte type field.
   The length field includes itself as well as the type and data fields.

   Byte Bit    Description
   0   0-7    Length, in binary, of the Multicast Capabilities control
   vector (inclusive of this byte, always 3)

   1   0-7    Type:  x'8C'

   2   0-7    Multicast Version Number:
               A binary numerical representation of the level of
               multicast services provided.  The protocols as identified
               in this document constitute version one.   Accordingly,
               x'01' is encoded in this field.  Any subsequent version
               must provide the services of all previous versions.

   The intended use of this CV for Multicast support is to detect when
   the multicast CANUREACH_ex flows will suffice between partners.  If
   this CV is present in a CAPEX from a partner, that partner is also
   multicast capable and therefore does not need to receive CANUREACH_ex
   messages over the TCP link that exists between them (and there must
   be one or else the CAPEX would not have flowed) because it will
   receive the multicast copies.

   A DLSw includes this control vector on a peer-wise basis.  That is to
   say, that a DLSw implementation may support multicast services but
   choose not to indicate this in its capabilities exchange to all
   partners. Therefore, a DLSw may include this capabilities CV with
   some DLSw peers and not with others.  Not including this vector can



Bryant & Brittain            Informational                     [Page 25]

RFC 2166              APPN Implementer's Workshop             June 1997


   be used to force TCP connections with other multicast capable nodes
   and degrade to normal RFC 1795 operations.  This capability is
   allowed to provide greater network design flexibility.

   When sending this capabilities exchange control vector, the following
   rules apply:

         Required                       Allowed @
    ID   @ Startup  Length  Repeatable* Runtime  Order  Content
   ====  =========  ======  ==========  =======  =====  ===============
   0x8C     Y        0x03        N         N       5+    Multicast
                                                         Capabilities

*Note: "Repeatable" means a Control Vector is repeatable within a single
   message.

11.1.1 DLSw Capabilities Negative Response

   DLSws that implement these enhancements must provide support for both
   multicast version 1 and single TCP connections.  This means that the
   capabilities exchange request must contain a DLSw Version ID control
   vector (x'82') indicating support for version 2 release 0, a
   Multicast Capabilities control vector, and the TCP Connections
   control vector indicating support for 1 TCP connection within a given
   capabilities exchange. If a multicast capable DLSw receives a
   capabilities exchange with a Multicast Capabilities, but either a
   missing or inappropriate TCP Connections CV (i.e., connections not
   equal to one)or DLSw Version control vector, then the inbound
   capabilities exchange should be rejected with a DLSw capabilities
   exchange negative response (see RFC 1795) using the following new
   reason code:

   x'000D'Inconsistent DLSw Version,  Multicast Capabilities, and TCP
   Connections CV received on the inbound Capabilities exchange

11.2 UDP Packets

   SSP frame formats are defined in RFC 1795.  Multicast protocol
   enhancements do not change these formats in any way.  The multicast
   protocol enhancements, however, do introduce the notion of SSP packet
   transport via UDP.  In this case, standard UDP services and headers
   are used to transport SSP packets.









Bryant & Brittain            Informational                     [Page 26]

RFC 2166              APPN Implementer's Workshop             June 1997


   The following section describes the proper UDP header for DLSw SSP
   packets.

   Byte       Description
   0-1        Source Port address
               In DLSw multicast protocols, this particular field is not
               relevant.  It may be set to any value.

   2-3        Destination Port address
               Always set to 2067

   4-5        Length

   6-7        Checksum
               The standard UDP checksum value.  Use of the UDP checksum
               function is optional.

11.3 Vendor Specific UDP Packets

   In order to accommodate the addition of vendor specific functions
   over UDP transport, a new SSP packet header has been defined. As
   described above, it is possible to receive these packets over both
   UDP and TCP (when a TCP connection already exists).

   It is important to note that the first 4 bytes of this packet match
   the format of existing RFC 1795 SSP packets.  This is done so that
   implementations in the future can expect that the DLSw �Version
   Number� is found in byte one and that the following bytes describe
   the packet header and message length.

   Furthermore, to assist DLSws in detecting 'out-of-sync' conditions
   whereby packet or parsing errors lead to improper length
   interpretations in the TCP datastream, valid DLSw version numbers
   will be restricted to the range of x'31' through x'3F' inclusive.

   DLSw multicast Vendor Specific frame format differs from existing RFC
   1795 packets in the following ways:

   1) The �Version Number� field is set to x'32' (ASCII '2') and now
   represents a packet type more than a DLSw version number.  More
   precisely, it is permitted and expected that DLSw may send packets of
   both types (x'31' and x'32').

   2) The message length field is followed by a new 3 byte field that
   contains the specific vendor's IEEE Organizationally Unique
   Identifier (OUI).





Bryant & Brittain            Informational                     [Page 27]

RFC 2166              APPN Implementer's Workshop             June 1997


   3) All fields following the new OUI field are arbitrary and defined
   by implementers.

   The following section defines this new packet format:

   Byte       Description
   0          DLSw packet type, Always set to x'32'

   1          Header Length
               Always 7 or higher

   2-3        Message Length
               Number of bytes within the data field following the
               header.


   4-6        Vendor specific OUI
               The IEEE Organizationally Unique Identifier (OUI)
               associated with the vendor specific function in
               question.

   7-n        Defined by the OUI owner


12. Compliance Statement

   All DLSw v2.0 implementations must support

   - Halt reason codes
   - the Multicast Capabilities control vector in the DLSw
     capabilities exchanges messages.

   The presence of the Multicast Capabilities control vector in a
   capabilities exchange message implies that the DLSw that issued the
   message supports all the scalability enhancements defined in this
   document.  These are:

   - use of multicast IP (if it is available in the underlying network)
   - use of 2067 as the destination port for UDP and TCP connections
   - single tunnel bring-up of TCP connections to DLSw peers
   - peer-on-demand
   - quiet ignore of all unrecognized vendor-specific UDP/TCP packets.









Bryant & Brittain            Informational                     [Page 28]

RFC 2166              APPN Implementer's Workshop             June 1997


13. Security Considerations

   This document addresses only scalability problems in RFC 1795.  No
   attempt is made to define any additional security mechanisms.  Note
   that, as in RFC 1795, a given implementation may still choose to
   refuse TCP connections from DLSw peers that have not been configured
   by the user.  The mechanism by which the user configures this
   behavior is not specified in this document.

14. Acknowledgements

   This specification was developed in the DLSw Related Interest Group
   (RIG) of the APPN Implementers Workshop.  This RIG is chaired by
   Louise Herndon- Wells (lhwells@cup.portal.com) and edited by Paul
   Brittain (pjb@datcon.co.uk).

   Much of the work on the scalability enhancements for v2.0 was
   developed by Dave Bryant (3COM).

   Other significant contributors to this document include:

   Frank Bordonaro (Cisco)
   Jon Houghton (IBM)
   Steve Klein (IBM)
   Ravi Periasamy (Cisco)
   Mike Redden (Proteon)
   Doug Wolff (3COM)

   Many thanks also to all those who participated in the DLSw RIG
   sessions and mail exploder discussions.

   If you would like to participate in future DLSw discussions, please
   subscribe to the DLSw RIG mailing lists by sending a mail to
   majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body
   of the message.

   If you would like further information on the activities of the AIW,
   please refer to the AIW web site at
   http://www.raleigh.ibm.com/app/aiwhome.htm.












Bryant & Brittain            Informational                     [Page 29]

RFC 2166              APPN Implementer's Workshop             June 1997


15. Authors' Addresses

   The editor of this document is:

         Paul Brittain
         Data Connection Ltd
         Windsor House
         Pepper Street
         Chester
         CH1 1DF
         UK

         tel:   +44 1244 313440
         email: pjb@datcon.co.uk

   Much of the work on this document was created by:

         David Bryant
         3Com Corporation
         5400 Bayfront Plaza MS 2418
         Santa Clara, CA 95052

         tel:   (408) 764-5272
         email: David_Bryant@3mail.3com.com



























Bryant & Brittain            Informational                     [Page 30]

RFC 2166              APPN Implementer's Workshop             June 1997


16. Appendix - Clarifications to RFC 1795

   This appendix attempts to clarify the areas of RFC 1795 that have
   proven to be ambiguous or hard to understand in the implementation
   experience to- date.  These clarifications should be read in
   conjunction with RFC 1795 as this document does not reproduce the
   complete text of that RFC.

   The clarifications are ordered by the section number in RFC 1795 to
   which they apply.  Where one point applies to more than one place in
   RFC 1795, it is listed below by the first relevant section.

   If any implementers encounter further difficulties in understanding
   RFC 1795 or these clarifications, they are encouraged to query the
   DLSw mail exploder (see section 1.1) for assistance.

   3. Send Port

   It is not permitted for a DLSw implementation to check that the send
   port used by a partner is 2067.  All implementations must accept
   connections from partners that do not use this port.

   3   TCP Tunnel bringup

   The paragraph below the figure should read as follows:

      Each Data Link Switch will maintain a list of DLSw capable routers
      and their status (active/inactive). Before Data Link Switching can
      occur between two routers, they must establish two TCP connections
      between them. These connections are treated as half duplex data
      pipes. A Data Link Switch will listen for incoming connections on
      its Read Port (2065), and initiate outgoing connections on its
      Write Port (2067).  Each Switch is responsible for initiating one
      of the two TCP connections.  After the TCP connections are
      established, SSP messages are exchanged to establish the
      capabilities of the two Data Link Switches.  Once the exchange is
      complete, the DLSw will employ SSP control messages to establish
      end-to-end circuits over the transport connection.  Within the
      transport connection, DLSw SSP messages are exchanged.  The
      message formats and types for these SSP messages are documented in
      the following sections.










Bryant & Brittain            Informational                     [Page 31]

RFC 2166              APPN Implementer's Workshop             June 1997


   3.2 RII bit in SSP header MAC addresses

   The RII bit in MAC addresses received from the LAN must be set to
   zero before forwarding in the source or destination address field in
   a SSP message header.  This requirement aims to avoid ambiguity of
   circuit IDs.  It is also recommended that all implementations ignore
   this bit in received SSP message headers.

   3.3 Transport IDs

   All implementations must allow for the DLSw peer varying the
   Transport ID up to and including when the ICR_cs message flows, and
   at all times reflect the most recent TID received from the partner in
   any SSP messages sent.  The TID cannot vary once the ICR_cs message
   has flowed.

   3.4 LF bits

   LF-bits should be propagated from LAN to SSP to LAN (and back) as per
   a bridge (i.e. they can only be revised downwards at each step if
   required).

   3.5 KEEPALIVE messages

   The SSP KEEPALIVE message (x1D) uses the short ("infoframe") version
   of the SSP header.  All DLSw implementation must support receipt and
   quiet ignore of this message, but there is not requirement to send
   it.  There is no response to a KEEPALIVE message.

   3.5 MAC header for Netbios SSP frames

   The MAC header is included in forwarded SSP Netbios frames in the
   format described below:
        -    addresses are always in non-canonical format
        -    src/dest addresses are as per the LLC frame
        -    AC/FC bits may be reset and must be ignored
        -    SSAP, DSAP and command fields are included
        -    RII bit in src address is copied from the LLC frame
        -    the RIF length is not extended to include padding
        -    all RIFs are padded to 18 bytes so that the data is
             in a consistent place.

   3.5.7 Unrecognized control vectors

   All implementations should quietly ignore unrecognized control
   vectors in any SSP messages.  In particular, unrecognized SSP frames
   or unrecognized fields in a CAPEX message should be quietly ignored
   without dropping the TCP connection.



Bryant & Brittain            Informational                     [Page 32]

RFC 2166              APPN Implementer's Workshop             June 1997


   5.4 Use of CUR-cs/CUR-ex

   The SSAP and DSAP numbers in CUR_ex messages should reflect those
   actually used in the TEST (or equivalent) frame that caused the
   CUR_ex message to flow.  This would mean that the SAP numbers in a
   'typical' CUR_ex frame for SNA traffic switched from a LAN will be a
   source SAP of x04 and a destination SAP of x00.

   The CUR_cs frame should only be sent when the DSAP is known.
   Specifically, CUR_ex should be used when a NULL XID is received that
   is targeted at DSAP zero, and CUR_cs when a XID specifying the (non-
   zero) DSAP is received.

   Note that this does not mean that an implementation can assume that
   the DSAP on a CUR_ex will always be zero.  The ICR_ex must always
   reflect the SSAP and DSAP values sent on the CUR_ex.  This is still
   true even if an implementation always sends a TEST with DSAP = x00 on
   its local LAN(s) in response to a CUR_ex to any SAP.

   An example of a situation where the CUR_ex may flow with a non-zero
   DSAP is when there is an APPN stack local to the DLSw node.  The APPN
   stack may then issue a connection request specifying the DSAP as a
   non-zero value.  This would then be passed on the CUR_ex message.

   7.6.1 Vendor IDs

   The Vendor ID field in a CAPEX may be zero.  However, a zero Vendor
   Context ID is not permitted, which implies that an implementation
   that uses a zero ID cannot send any vendor-specific CVs (other than
   those specified by other vendors that do have a non-zero ID)

   7.6.3 Initial Pacing Window

   The initial pacing window may be 1.  There is no requirement on an
   implementation to use any minimum value for the initial pacing
   window.

   7.6.7 TCP Tunnel bringup

   The third paragraph should read:

      If TCP Connections CV values agree and the number of connections
      is one, then the DLSw with the higher IP address must tear down
      the TCP connections on its local port 2065. This connection is
      torn down after a CAPEX response has been both sent and received.
      After this point, the remaining TCP connection is used to exchange
      data in both directions.




Bryant & Brittain            Informational                     [Page 33]

RFC 2166              APPN Implementer's Workshop             June 1997


   7.7 CAPEX negative responses

   If a DLSw does not support any of the options specified on a CAPEX
   received from a partner, or if it thinks the CAPEX is malformed, it
   must send a CAPEX negative response to the partner.  The receiver of
   a CAPEX negative response is then responsible for dropping the
   connection.  It is not permitted to drop the link instead of sending
   a CAPEX negative response.

   8.2 Flow Control ACKs

   The first flow-control ack (FCACK) does not have to be returned on
   the REACH_ACK even if the ICR_cs carried the FCIND bit.  However it
   should be returned on the first SSP frame flowing for that circuit
   after the REACH_ACK.




































Bryant & Brittain            Informational                     [Page 34]