File: rfc1987.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 (2467 lines) | stat: -rw-r--r-- 105,821 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
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467






Network Working Group                                P. Newman, Ipsilon
Request for Comments: 1987                           W. Edwards, Sprint
Category: Informational                              R. Hinden, Ipsilon
                                                    E. Hoffman, Ipsilon
                                                 F. Ching Liaw, Ipsilon
                                                       T. Lyon, Ipsilon
                                                   G. Minshall, Ipsilon
                                                            August 1996



       Ipsilon's General Switch Management Protocol Specification
                              Version 1.1





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

   The General Switch Management Protocol (GSMP), is a general purpose
   protocol to control an ATM switch. GSMP allows a controller to
   establish and release connections across the switch; add and delete
   leaves on a point-to-multipoint connection; manage switch ports;
   request configuration information; and request statistics.



















Newman, et. al.              Informational                      [Page 1]

RFC 1987              GSMP Protocol Specification            August 1996


Table of Contents

   1. Introduction....................................................3

   2. GSMP Packet Format..............................................4

   3. Connection Management Messages..................................7
      3.1 Add Branch Message.........................................11
      3.2 Delete Branch Message......................................12
      3.3 Delete Tree Message........................................13
      3.4 Verify Tree Message........................................13
      3.5 Delete All Message.........................................14
      3.6 Move Branch Message........................................14

   4. Port Management Message........................................16

   5. Statistics Messages............................................20
      5.1 VC Activity Message........................................20
      5.2 Port and VC Statistics Messages............................23
          5.2.1 Port Statistics Message..............................26
          5.2.2 VC Statistics Message................................26

   6. Configuration..................................................26
      6.1 Switch Configuration Message...............................27
      6.2 Port Configuration Message.................................28
      6.3 All Ports Configuration Message............................32

   7. Event Messages.................................................33
      7.1 Port Up Message............................................35
      7.2 Port Down Message..........................................35
      7.3 Invalid VPI/VCI Message....................................35
      7.4 New Port Message...........................................35
      7.5 Dead Port Message..........................................36

   8. Adjacency Protocol.............................................36
      8.1 Packet Format..............................................36
      8.2 Procedure..................................................39

   9. Failure Response Messages......................................41

   References........................................................43
   Security Considerations...........................................43
   Authors' Addresses................................................43








Newman, et. al.              Informational                      [Page 2]

RFC 1987              GSMP Protocol Specification            August 1996


1. Introduction

   The General Switch Management Protocol (GSMP), is a general purpose
   protocol to control an ATM switch. GSMP allows a controller to
   establish and release connections across the switch; add and delete
   leaves on a point-to-multipoint connection; manage switch ports;
   request configuration information; and request statistics. It also
   allows the switch to inform the controller of asynchronous events
   such as a link going down. GSMP runs across an ATM link connecting
   the controller to the switch, on a control connection (virtual
   channel) established at initialization. The GSMP protocol is
   asymmetric, the controller being the master and the switch being the
   slave. Multiple switches may be controlled by a single controller
   using multiple instantiations of the protocol over separate control
   connections.

   A switch is assumed to contain multiple "ports". Each port is a
   combination of one "input port" and one "output port". Some GSMP
   requests refer to the port as a whole whereas other requests are
   specific to the input port or the output port.  ATM cells arrive at
   the switch from an external communication link on incoming virtual
   channels at an input port. ATM cells depart from the switch to an
   external communication link on outgoing virtual channels from an
   output port. Virtual channels on a port or link are referenced by
   their virtual path and virtual channel identifiers (VPI/VCI). A
   virtual channel connection across a switch is formed by connecting an
   incoming virtual channel to one or more outgoing virtual channels.
   Virtual channel connections are referenced by the input port on which
   they arrive and the virtual path and virtual channel identifiers
   (VPI/VCI) of their incoming virtual channel.

   In general a virtual channel is established with a certain quality of
   service (QOS). Unfortunately this is an ill defined and changing
   concept as new ideas make their way into hardware. For this version
   of the GSMP protocol it is assumed that each virtual channel
   connection may be assigned a priority when it is established. It may
   be assumed that for virtual channel connections that share the same
   output port, an ATM cell on a connection with a higher priority is
   much more likely to exit the switch before an ATM cell on a
   connection with a lower priority if they are both in the switch at
   the same time. The number of priorities that each port of the switch
   supports may be obtained from the port configuration message.

   Switch ports are described by a 32 bit port number. The switch
   assigns port numbers and it may typically choose to structure the 32
   bits into sub-fields that have meaning to the physical structure of
   the switch (e.g. shelf, slot, port). In general, a port in the same
   physical location on the switch will always have the same port



Newman, et. al.              Informational                      [Page 3]

RFC 1987              GSMP Protocol Specification            August 1996


   number, even across power cycles. The internal structure of the port
   number is opaque to the GSMP protocol. However, by looking up the
   product identity in a database, network management tools may discover
   the partitioning of the port number and the physical meaning of the
   sub-fields.

   Each switch port also maintains a port session number assigned by the
   switch. A connection management message or a port management message
   with an incorrect port session number must be rejected.  This allows
   the controller to detect a link failure and to keep state
   synchronized. The port session number of a port remains unchanged
   while the port is continuously in the available state and the link
   status is continuously up. When a port returns to the available state
   after it has been unavailable or in any of the loopback states, or
   when the line status returns to the up state after it has been down
   or in test, or after a power cycle, its port session number will have
   changed.  Port session numbers should be assigned using some form of
   random number.

   GSMP also contains an adjacency protocol. The adjacency protocol is
   used to synchronize state across the link, to discover the identity
   of the entity at the other end of a link, and to detect when it
   changes.


2. GSMP Packet Format

   GSMP packets are variable length and are encapsulated directly in an
   AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header as illustrated:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LLC (0xAA-AA-03)                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                   SNAP (0x00-00-00-88-0C)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         GSMP Message                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Pad (0 - 47 octets)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +               AAL-5 CPCS-PDU Trailer (8 octets)               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Newman, et. al.              Informational                      [Page 4]

RFC 1987              GSMP Protocol Specification            August 1996


   (The convention in the documentation of Internet Protocols [rfc1700]
   is to express numbers in decimal and to picture data in "big-endian"
   order. That is, fields are described left to right, with the most
   significant octet on the left and the least significant octet on the
   right. Whenever a diagram shows a group of octets, the order of
   transmission of those octets is the normal order in which they are
   read in English. Whenever an octet represents a numeric quantity the
   left most bit in the diagram is the high order or most significant
   bit. That is, the bit labeled 0 is the most significant bit.
   Similarly, whenever a multi-octet field represents a numeric quantity
   the left most bit of the whole field is the most significant bit.
   When a multi-octet quantity is transmitted, the most significant
   octet is transmitted first. This is the same coding convention as is
   used in the ATM layer [I.361] and AAL-5 [I.363].)

   The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00
   0x00 0x88 0x0C.

   The maximum transmission unit (MTU) of the GSMP message is 1500
   octets.

   The default virtual channel for LLC/SNAP encapsulated messages is:

      VPI = 0
      VCI = 15.

   GSMP is a master-slave protocol. The controller issues request
   messages to the switch. Each request message indicates whether a
   response is required from the switch and contains a transaction
   identifier to enable the response to be associated with the request.
   The switch replies with a response message indicating either a
   successful result or a failure. There are four classes of GSMP
   request-response message: Connection Management, Port Management,
   Statistics, and Configuration. The switch may also generate
   asynchronous Event messages to inform the controller of asynchronous
   events.  Event messages are not acknowledged by the controller. There
   is also an adjacency protocol message used to establish
   synchronization across the link and maintain a handshake.

   For the request-response messages each message type has a format for
   the request message and a format for the success response.  Unless
   otherwise specified a failure response message is identical to the
   request message that caused the failure, with the Code field
   indicating the nature of the failure. Event messages have only a
   single format defined as they are not acknowledged by the controller.

   Except for the adjacency protocol message, no GSMP messages may be
   sent across the link until the adjacency protocol has achieved



Newman, et. al.              Informational                      [Page 5]

RFC 1987              GSMP Protocol Specification            August 1996


   synchronization, and all GSMP messages received on a link that does
   not currently have state synchronization must be discarded.

   All GSMP messages, except the adjacency protocol message, have the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Message Body                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
             The GSMP protocol version number, currently Version = 1. It
             should be set by the sender of the message to the GSMP
             protocol version that the sender is currently running.

   Message Type
             The GSMP message type. GSMP messages fall into five
             classes: Connection Management, Port Management,
             Statistics, Configuration, and Events. Each class, except
             for port management, has a number of different message
             types. In addition, one Message Type is allocated to the
             adjacency protocol.

   Result
             Field in a connection management request message or a port
             management request message, is used to indicate whether a
             response is required to the request message if the outcome
             is successful. A value of "NoSuccessAck" indicates that the
             request message does not expect a response if the outcome
             is successful, and a value of "AckAll" indicates that a
             response is expected if the outcome is successful.  In both
             cases a failure response will be generated if the request
             fails. This facility reduces the traffic in the case where
             the controller is simply checking that the state in the
             switch is correct. For all other request messages a value
             of "NoSuccessAck" in the request message is ignored and the
             request message is handled as if the field were set to
             "AckAll".  In a response message the result field can have
             two values: "Success" and "Failure".




Newman, et. al.              Informational                      [Page 6]

RFC 1987              GSMP Protocol Specification            August 1996


             The encoding of the result field is:

                  NoSuccessAck:  Result = 1
                  AckAll:        Result = 2
                  Success:       Result = 3
                  Failure:       Result = 4.


             The Result field is not used in an adjacency protocol
             message and should be set to zero by the sender and ignored
             by the receiver.

   Code
             Field gives further information concerning the result in a
             response message. It is mostly used to pass an error code
             in a failure response but can also be used to give further
             information in a success response message or an event
             message. In a request message the code field is not used
             and is set to zero. In an adjacency protocol message the
             Code field is used to determine the function of the
             message.

   Transaction Identifier
             Used to associate a request message with its response
             message. For request messages the controller may select any
             transaction identifier. For response messages the
             transaction identifier is set to the value of the
             transaction identifier from the message to which it is a
             response.  For event messages the transaction identifier
             should be set to zero. In the adjacency protocol the
             Transaction Identifier is not used. This field is not
             present in the adjacency protocol message.


3. Connection Management Messages

   Connection management messages are used by the controller to
   establish, delete, modify and verify connections across the switch.
   The Add Branch, Delete Branch, Delete Tree, Verify Tree, and Delete
   All connection management messages have the following format for both
   request and response messages:










Newman, et. al.              Informational                      [Page 7]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Input Port                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |      Input VPI        |          Input VCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Output Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |      Output VPI       |          Output VCI           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Number of Branches       |   Reserved    |   Priority    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port Session Number
             Field gives the session number of the input port. Each
             switch port maintains a Port Session Number assigned by the
             switch. The port session number of a port remains unchanged
             while the port is continuously in the Available state and
             the link status is continuously Up. When a port returns to
             the Available state after it has been Unavailable or in any
             of the Loopback states, or when the line status returns to
             the Up state after it has been Down or in Test, or after a
             power cycle, a new Port Session Number must be generated.
             Port session numbers should be assigned using some form of
             random number.  The switch must reject any connection
             management request message that has an invalid Port Session
             Number for the port specified in the Input Port field by
             returning a failure response message with the Code field
             indicating, "Invalid port session number." The current port
             session number may be obtained using a configuration
             message.

   Input Port
             Indicates a switch input port.  Switch ports are referenced
             by a 32 bit value assigned by the switch.

   Input VPI
             Identifies an ATM virtual path arriving at the switch input
             port indicated by the Input Port field.





Newman, et. al.              Informational                      [Page 8]

RFC 1987              GSMP Protocol Specification            August 1996


   Input VCI
             Identifies an ATM virtual channel arriving on the virtual
             path indicated by the Input VPI field at the switch input
             port indicated by the Input Port field.

   Output Port
             Indicates a switch output port.  Switch ports are
             referenced by a 32 bit value assigned by the switch.

   Output VPI
             Identifies an outgoing virtual path departing from the
             switch output port indicated in the Output Port field.

   Output VCI
             Identifies an outgoing virtual channel departing on the
             virtual path indicated by the Output VPI field from the
             switch output port indicated in the Output Port field.

   Number of Branches
             Gives the number of output branches on a virtual channel
             connection. (A unicast connection will have one branch, a
             multicast connection will have two or more branches.) This
             field is only used in the Verify Tree message.  In all
             other connection management messages this field should be
             set to zero by the sender and ignored by the receiver.

   Reserved
             This field is not used. It is set to zero by the sender and
             ignored by the receiver.

   Priority
             Gives the priority of the connection.  The highest priority
             is numbered zero and the lowest priority is numbered "Q-1"
             where "Q" is the number of priorities that the output port
             can support. The ability to offer different qualities of
             service to different connections based upon their priority
             is assumed to be a property of the output port of the
             switch. It is assumed that for virtual channel connections
             that share the same output port, an ATM cell on a
             connection with a higher priority is much more likely to
             exit the switch before an ATM cell on a connection with a
             lower priority if they are both in the switch at the same
             time. The number of priorities that each output port can
             support is given in the Port Configuration message. If a
             connection request is received with a value in the priority
             field that the switch cannot support, the switch will
             assign the closest priority that it is capable of
             supporting.  This field is only used in the Add Branch and



Newman, et. al.              Informational                      [Page 9]

RFC 1987              GSMP Protocol Specification            August 1996


             Move Branch messages.  In all other connection management
             messages this field should be set to zero by the sender and
             ignored by the receiver.

   If the result field of the request message is "AckAll" the switch
   must reply to all connection management request messages with a
   success response message or a failure response message.  If the
   result field of the request message is "NoSuccessAck" the switch must
   only reply in the case of a failure.

   A success response message must not be sent until the operation has
   been successfully completed. For connection management messages the
   success response message is a copy of the request message returned
   with a Result field indicating success. The Code field is not used in
   a connection management success response message and should be set to
   zero. The failure response message is a copy of the request message
   returned with a Result field indicating failure. The Code field is
   used to pass the Failure Code in a connection management failure
   response message. If the switch issues a failure response the
   connection state within the switch must not be modified by the
   request message that resulted in the failure.

   No distinction is made between unicast connections and multicast
   connections. The first Add Branch message for a particular Input
   Port, Input VPI, and Input VCI will establish a unicast connection.
   The second Add Branch message with the same Input Port, Input VPI,
   and Input VCI fields will convert the connection to a multicast
   connection with two branches. Subsequent Add Branch messages with the
   same Input Port, Input VPI, and Input VCI fields will add further
   branches to the multicast connection. Use of the Delete Branch
   message on a multicast connection with two branches will result in a
   unicast connection. Use of the Delete Branch message on a unicast
   connection will delete the unicast connection. There is no concept of
   a connection with zero output branches. All connections are
   unidirectional, one input virtual channel to one or more output
   virtual channels.

   The connection management messages may be issued regardless of the
   Port Status of the switch port. Connections may be established or
   deleted when a switch port is in the Available, Unavailable, or any
   of the Loopback states. However, all connection state on an input
   port will be deleted when the port returns to the Available state
   from any other state, i.e. when a Port Management message is received
   for that port with the Function field indicating either Bring Up, or
   Reset Input Port.






Newman, et. al.              Informational                     [Page 10]

RFC 1987              GSMP Protocol Specification            August 1996


3.1 Add Branch Message

   The Add Branch message is a connection management message used to
   establish a virtual channel connection or to add an additional branch
   to an existing virtual channel connection. It may also be used to
   check the connection state stored in the switch. The connection is
   specified by the Input Port, Input VPI, and Input VCI fields. The
   output branch is specified by the Output Port, Output VPI, and Output
   VCI fields. The priority of the connection is specified by the
   Priority field. The Add Branch message is:

      Message Type = 16

   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields does not already exist, it must be
   established with the single output branch specified in the request
   message. The output branch should have the priority specified by the
   Priority field. If the Result field of the request message is
   "AckAll" a success response message must be sent upon successful
   establishment of the specified branch.  The success response message
   must not be sent until the Add Branch operation has been completed.

   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields already exists, but the specified output
   branch does not, the new output branch must be added. The new output
   branch should have the priority specified by the Priority field. If
   the Result field of the request message is "AckAll" a success
   response message must be sent upon successful establishment of the
   specified branch. The success response message must not be sent until
   the Add Branch operation has been completed.

   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields already exists and the specified output
   branch also already exists, the priority of the connection, if
   different from the request message, should be changed to that in the
   request message. A success response message must be sent if the
   Result field of the request message is "AckAll".  This allows the
   controller to periodically reassert the state of a connection or to
   change its priority. If the result field of the request message is
   "NoSuccessAck" a success response message should not be returned.
   This may be used to reduce the traffic on the control link for
   messages that are reasserting previously established state. For
   messages that are reasserting previously established state, the
   switch must always check that this state is correctly established in
   the switch hardware (i.e. the actual connection tables used to
   forward cells).





Newman, et. al.              Informational                     [Page 11]

RFC 1987              GSMP Protocol Specification            August 1996


   The behavior is undefined if the output virtual channel specified by
   the Output Port, Output VPI, and Output VCI fields is already in use
   by any connection other than that specified by the Input Port, Input
   VPI, and Input VCI fields.

   A failure response must be returned if the switch is unable to
   establish the specified branch or if there is an error in any of the
   fields of the request message. If a failure message is returned the
   state of the switch must not have been modified by the request
   message.

   It should be noted that different switches support multicast in
   different ways. There will be a limit to the total number of
   multicast connections any switch can support, and possibly a limit on
   the maximum number of branches that a multicast connection may
   specify.  Some switches also impose a limit on the number of
   different VPI/VCI values that may be assigned to the output branches
   of a multicast connection. Many switches are incapable of supporting
   more than a single branch of any particular multicast connection on
   the same output port. Specific failure codes are defined for some of
   these conditions. If a switch sends a failure response to an Add
   Branch message it must choose the most specific failure code.

3.2 Delete Branch Message

   The Delete Branch message is a connection management message used to
   delete a single branch of a virtual channel connection, or in the
   case of the last branch, to delete the connection. The virtual
   channel connection is specified by the Input Port, Input VPI, and
   Input VCI fields. The specific branch is indicated by the Output
   Port, Output VPI, and Output VCI fields. The Delete Branch message
   is:

      Message Type = 17

   If the Result field of the request message is "AckAll" a success
   response message must be sent upon successful deletion of the
   specified branch. The success response message must not be sent until
   the delete branch operation has been completed and if possible, not
   until all data on that branch, queued for transmission, has been
   transmitted. A failure message indicating, "The specified connection
   does not exist," must be sent if the connection specified by the
   Input Port, Input VPI, and Input VCI fields does not exist. A failure
   message indicating, "The specified branch does not exist," must be
   sent if the connection specified by the Input Port, Input VPI, and
   Input VCI fields exists but the branch specified by the Output Port,
   Output VPI, and Output VCI fields does not exist.




Newman, et. al.              Informational                     [Page 12]

RFC 1987              GSMP Protocol Specification            August 1996


3.3 Delete Tree Message

   The Delete Tree message is a connection management message used to
   delete an entire virtual channel connection. All remaining branches
   of the connection are deleted. The virtual channel connection is
   specified by the Input Port, Input VPI, and Input VCI fields.  The
   Output Port, Output VPI, and Output VCI fields are not used in this
   message and their contents should be set to zero by the sender and
   ignored by the receiver. The Delete Tree message is:

      Message Type = 18

   If the Result field of the request message is "AckAll" a success
   response message must be sent upon successful deletion of the
   specified connection. The success message must not be sent until the
   delete operation has been completed and if possible, not until all
   data on the connection, queued for transmission, has been
   transmitted. A failure message indicating, "The specified connection
   does not exist," must be sent if the connection specified by the
   Input Port, Input VPI, and Input VCI fields does not exist.

3.4 Verify Tree Message

   The Verify Tree message is a connection management message used to
   verify the number of branches on a virtual channel connection.  The
   virtual channel connection is specified by the Input Port, Input VPI,
   and Input VCI fields. The Output Port, Output VPI, and Output VCI
   fields are not used in this message and their contents should be set
   to zero by the sender and ignored by the receiver.  The number of
   branches that the sender believes that this virtual channel
   connection should contain is given by the Number of Branches field.
   The Verify Tree message is:

      Message Type = 19

   If the Result field of the request message is "AckAll" a success
   response message must be sent if the receiver agrees that the actual
   number of branches of the specified virtual channel connection
   matches the number contained in the Number of Branches field of the
   request message. The failure response message, with the code field
   set to "Failure specific to the particular message type," must be
   sent if the actual number of branches of the specified virtual
   channel connection does not match the number contained in the Number
   of Branches field of the request message. In this failure response
   message the Number of Branches field must be changed to contain the
   actual number of branches of the specified virtual channel
   connection. A failure response message with the code field set to a
   different value must be used to indicate some other failure such as,



Newman, et. al.              Informational                     [Page 13]

RFC 1987              GSMP Protocol Specification            August 1996


   "The specified connection does not exist." In this case the Number of
   Branches field will be the same as that of the request message.

   The Verify Tree message can only be guaranteed to yield a correct
   response when there are no other connection request messages or their
   response messages pending for the specified connection.  If this is
   not the case the result of the Verify Tree message is undefined.

3.5 Delete All Message

   The Delete All message is a connection management message used to
   delete all connections on a switch input port. All connections that
   arrive at the specified input port must be deleted. On completion of
   the operation all dynamically assigned VPI/VCI values for the
   specified port must be unassigned, i.e. there must be no virtual
   connections established in the VPI/VCI space that GSMP controls on
   this port. The Input VPI, Input VCI, Output Port, Output VPI, and
   Output VCI fields are not used in this message and their contents are
   ignored and unspecified. The Delete All message is"

      Message Type = 20

   If the Result field of the request message is "AckAll" a success
   response message must be sent upon completion of the operation. The
   success response message must not be sent until the operation has
   been completed.


3.6 Move Branch Message

   The Move Branch connection management message has the following
   format for both request and response messages:



















Newman, et. al.              Informational                     [Page 14]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Input Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |        Input VPI      |           Input VCI           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Old Output Port                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |    Old Output VPI     |        Old Output VCI         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        New Output Port                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |    New Output VPI     |        New Output VCI         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Reserved                   |   Priority    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Move Branch message is a connection management message used to
   move a single output branch of a virtual channel connection from its
   current output port, output VPI, and output VCI, to a new output
   port, output VPI, and output VCI on the same virtual channel
   connection. None of the other output branches are modified.  When the
   operation is complete the original output VPI/VCI on the original
   output port will be deleted from the connection.  The Move Branch
   message is:

      Message Type = 22

   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields already exists, and the output branch
   specified by the Old Output Port, Old Output VPI, and Old Output VCI
   fields exists as a branch on that connection, the output branch
   specified by the New Output Port, New Output VPI, and New Output VCI
   fields is added to the connection and the branch specified by the Old
   Output Port, Old Output VPI, and Old Output VCI fields is deleted. If
   the Result field of the request message is "AckAll" a success
   response message must be sent upon successful completion of the
   operation. The success response message must not be sent until the
   Move Branch operation has been completed.





Newman, et. al.              Informational                     [Page 15]

RFC 1987              GSMP Protocol Specification            August 1996


   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields already exists, but the output branch
   specified by the Old Output Port, Old Output VPI, and Old Output VCI
   fields does not exist as a branch on that connection, a failure
   response must be returned with the Code field indicating, "The
   specified branch does not exist." The connection state of the switch
   must not be modified in this case.

   If the virtual channel connection specified by the Input Port, Input
   VPI, and Input VCI fields does not exist, a failure response must be
   returned with the Code field indicating, "The specified connection
   does not exist." The connection state of the switch must not be
   modified in this case.

   The behavior is undefined if the output virtual channel specified by
   the New Output Port, New Output VPI, and New Output VCI fields is
   already in use by any connection.

   A failure response will be returned if the switch is unable to
   establish the specified branch or if there is an error in any of the
   fields of the request message. If a failure message is returned the
   state of the switch must not have been modified by the request
   message.

4. Port Management Message

   The Port Management message allows a port to be brought into service,
   taken out of service, looped back, or reset. Only the Bring Up and
   the Reset Input Port functions change the connection state
   (established connections) on the input port. Only the Bring Up
   function changes the value of the Port Session Number. If the Result
   field of the request message is "AckAll" a success response message
   must be sent upon successful completion of the operation. The success
   response message must not be sent until the operation has been
   completed. The Port Management Message is:

      Message Type = 32

   The Port Management message has the following format for the request
   and success response messages:











Newman, et. al.              Informational                     [Page 16]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Event Flags  |   Duration    |          Function             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
             Gives the port number of the port to which the message
             applies.

   Port Session Number
             Gives the current port session number for the port. If the
             Port Session Number in the request message does not match
             the current port session number of the port indicated by
             the Port field of the request message, a failure response
             must be returned with, "Invalid port session number,"
             indicated in the Code field. If the specified function
             requires a new Port Session Number to be generated the new
             Port Session Number must be given in the success response
             message.  The Port Session Number must be generated using
             some form of random number.

   Event Sequence Number
             In the success response message gives the current value of
             the Event Sequence Number of the switch port indicated by
             the Port field. The Event Sequence Number is set to zero
             when the port is initialized and is incremented by one each
             time an asynchronous event is detected on that port that
             the switch would normally report via an Event message. If
             the Event Sequence Number in the success response differs
             from the Event Sequence Number of the most recent Event
             message received for that port, events have occurred that
             were not reported via an Event message. This is most likely
             to be due to the flow control that restricts the rate at
             which a switch can send Event messages for each port. In
             the request message this field is not used and should be
             set to zero by the sender and ignored by the receiver.




Newman, et. al.              Informational                     [Page 17]

RFC 1987              GSMP Protocol Specification            August 1996


   Event Flags
             Field in the request message is used to reset the Event
             Flags in the switch port indicated by the Port field. Each
             Event Flag in a switch port corresponds to a type of Event
             message. When a switch port sends an Event message it sets
             the corresponding Event Flag on that port. The port is not
             permitted to send another Event message of the same type
             until the Event Flag has been reset. If the Function field
             in the request message is set to "Reset Event Flags," for
             each bit that is set in the Event Flags field, the
             corresponding Event Flag in the switch port is reset.

             The Event Flags field is only used in a request message
             with the Function field set to "Reset Event Flags." For all
             other values of the Function field, the Event Flags field
             should be set to zero in the request message and must be
             ignored by the receiver. In the success response message
             the Event Flags field must be set to the current value of
             the Event Flags for the port, after the completion of the
             operation specified by the request message, for all values
             of the Function field. Setting the Event Flags field to all
             zeros in a "Reset Event Flags" request message allows the
             controller to obtain the current state of the Event Flags
             and the current Event Sequence Number of the port without
             changing the state of the Event Flags.

             The correspondence between the types of Event message and
             the bits of the Event Flags field is as follows:

                Port Up:          Bit 0, (most significant bit)
                Port Down:        Bit 1,
                Invalid VPI/VCI:  Bit 2,
                New Port:         Bit 3,
                Dead Port:        Bit 4.

   Duration
             Is the length of time, in seconds, that any of the loopback
             states remain in operation. When the duration has expired
             the port will automatically be returned to service.  If
             another Port Management message is received for the same
             port before the duration has expired, the loopback will
             continue to remain in operation for the length of time
             specified by the Duration field in the new message. The
             Duration field is only used in request messages with the
             Function field set to Internal Loopback, External Loopback,
             or Bothway Loopback. In all other request messages it
             should be set to zero by the sender and ignored by the
             receiver.



Newman, et. al.              Informational                     [Page 18]

RFC 1987              GSMP Protocol Specification            August 1996


   Function
             Specifies the action to be taken. The specified action will
             be taken regardless of the current status of the port
             (Available, Unavailable, or any Loopback state). The
             defined values of the Function field are:

             Bring Up:
                  Function = 1. Bring the port into service. All
                  connections that arrive at the specified input port
                  must be deleted and a new Port Session Number must be
                  selected using some form of random number. On
                  completion of the operation all dynamically assigned
                  VPI/VCI values for the specified input port must be
                  unassigned, i.e. no virtual connections will be
                  established in the VPI/VCI space that GSMP controls on
                  this input port. The Port Status of the port
                  afterwards will be Available.

             Take Down:
                  Function = 2. Take the port out of service. Any cells
                  received at this port will be discarded. No cells will
                  be transmitted from this port. The Port Status of the
                  port afterwards will be Unavailable. The behavior is
                  undefined if the port over which the GSMP protocol is
                  running is taken down.

             Internal Loopback:
                  Function = 3. Cells arriving at the output port from
                  the switch fabric are looped through to the input port
                  to return to the switch fabric. All of the ATM
                  functions of the input port above the PHY layer, e.g.
                  header translation, are performed upon the looped back
                  cells. The Port Status of the port afterwards will be
                  Internal Loopback.

             External Loopback:
                  Function = 4. Cells arriving at the input port from
                  the external communications link are immediately
                  looped back to the communications link at the physical
                  layer without entering the input port. None of the ATM
                  functions of the input port above the PHY layer are
                  performed upon the looped back cells. The Port Status
                  of the port afterwards will be External Loopback.

             Bothway Loopback:
                  Function = 5. Both internal and external loopback are
                  performed. The Port Status of the port afterwards will
                  be Bothway Loopback.



Newman, et. al.              Informational                     [Page 19]

RFC 1987              GSMP Protocol Specification            August 1996


             Reset Input Port:
                  Function = 6. All connections that arrive at the
                  specified input port must be deleted and the input and
                  output port hardware re-initialized. On completion of
                  the operation all dynamically assigned VPI/VCI values
                  for the specified input port must be unassigned, i.e.
                  no virtual connections will be established in the
                  VPI/VCI space that GSMP controls on this input port.
                  The Port Session Number is not changed by the Reset
                  Input Port function.  The Port Status of the port
                  afterwards will be Unavailable.

             Reset Event Flags:
                  Function = 7. For each bit that is set in the Event
                  Flags field, the corresponding Event Flag in the
                  switch port must be reset. The Port Status of the port
                  is not changed by this function.


5. Statistics Messages

   The statistics messages permit the controller to request the values
   of various hardware counters associated with the switch input and
   output ports, and virtual channels. Two classes of statistics message
   are defined: the VC Activity Message, and the Port and VC Statistics
   Messages. The VC Activity message is used to determine whether one or
   more specific VCs have recently been carrying traffic.  The Port and
   VC Statistics message is used to query the various port and VC
   specific traffic and error counters.

5.1 VC Activity Message

   The VC Activity message is used to determine whether one or more
   specific VCs have recently been carrying traffic. The VC Activity
   message contains one or more VC Activity records. Each VC Activity
   record is used to request and return activity information concerning
   a single virtual connection. Each VC is specified by its input port,
   input VPI, and input VCI. These are specified in the Input Port,
   Input VPI, and Input VCI fields of each VC Activity record.  Two
   forms of activity detection are supported. If the switch supports per
   VC traffic accounting the current value of the traffic counter for
   each specified VC must be returned. The units of traffic counted are
   not specified but will typically be either cells or frames.  The
   controller must compare the traffic counts returned in the message
   with previous values for each of the specified VCs to determine
   whether each VC has been active in the intervening period.  If the
   switch does not support per VC traffic accounting, but is capable of
   detecting per-VC activity by some other unspecified means, the result



Newman, et. al.              Informational                     [Page 20]

RFC 1987              GSMP Protocol Specification            August 1996


   may be indicated for each VC using the Flags field. The VC Activity
   message is:

      Message Type = 48

   The VC Activity request and success response messages have the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Number of Records       |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       VC Activity Records                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Number of Records
             Field specifies the number of VC Activity records to
             follow. The maximum number of VC Activity records permitted
             in a single VC Activity message is 120.

   Reserved
             Field is not used. It is set to zero by the sender and
             ignored by the receiver.

   Each VC Activity Record has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Input Port                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags |      Input VPI        |          Input VCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        VC Traffic Count                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Input Port
             Identifies the port number of the input port on which the
             VC of interest arrives in order to identify the VC
             (regardless of whether the traffic count for the VC is
             maintained on the input port or the output port).



Newman, et. al.              Informational                     [Page 21]

RFC 1987              GSMP Protocol Specification            August 1996


   Input VPI
   Input VCI
             Fields identify the specific virtual channel for which
             statistics are being requested.

   Flags
             In the request message this field is unused, it should be
             set to zero by the sender and ignored by the receiver.  In
             the success response message bit 0 (msb) of the Flags field
             is used to indicate an invalid VC Activity record. This bit
             must be zero if any of the fields in this VC Activity
             record are invalid, if the input port specified by the
             Input Port field does not exist, or if the specified
             connection does not exist. If this bit is zero in a success
             response message bits 1 and 2 of the Flags field and the VC
             Traffic Count field are undefined. If bit 0 of the flags
             field is set, the VC Activity record is valid, and bits 1
             and 2 of the Flags field in the VC Activity record are used
             as follows:

                Bit 1 of the Flags field: if set, indicates that the
                value in bit 2 of the Flags field is valid; if zero,
                indicates that the value in the VC Traffic Count field
                is valid.

                If bit 1 of the Flags field is set, bit 2 of the Flags
                field, if set, indicates that there has been some
                activity on this virtual channel since the last VC
                Activity message for this virtual channel.

                If bit 1 of the Flags field is set, bit 2 of the Flags
                field, if zero, indicates that there has been no
                activity on this virtual channel since the last VC
                Activity message for this virtual channel.

                Bit 3 of the Flags field is not used, it should be set
                to zero by the sender and ignored by the receiver.

   VC Traffic Count
             Field is unused in the request message, it should be set to
             zero by the sender and ignored by the receiver. In the
             success response message, if the switch supports per-VC
             traffic counting, the VC Traffic Count field must be set to
             the value of a free running, VC specific, 64 bit traffic
             counter counting traffic flowing across the specified
             virtual channel.  The value of the traffic counter is not
             modified by reading it.  If per-VC traffic counting is
             supported, the switch must report the VC Activity result



Newman, et. al.              Informational                     [Page 22]

RFC 1987              GSMP Protocol Specification            August 1996


             using the traffic count rather than using bit 2 of the
             Flags field.

   The format of the failure response is the same as the request message
   with the Number of Records field set to zero and no VC Activity
   records returned in the message. If the switch is incapable of
   detecting per-VC activity, a failure response must be returned
   indicating, "The specified request is not implemented on this
   switch."

5.2 Port and VC Statistics Messages

   The Port and VC Statistics messages are used to query the various
   port and VC specific traffic and error counters.

   The Port and VC Statistics request messages have the following
   format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |          VPI          |              VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
             Identifies the port number of the port for which statistics
             are being requested.

   VPI
   VCI
             Fields identify the specific virtual channel for which
             statistics are being requested.  For requests that do not
             require a virtual channel to be specified these fields
             should be set to zero in the request and ignored by the
             receiver.

   The success response messages for the port and VC statistics group
   have the following format:







Newman, et. al.              Informational                     [Page 23]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |          VPI          |              VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Input Cell Count                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Input Frame Count                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Input Cell Discard Count                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                   Input Frame Discard Count                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Input HEC Error Count                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Input Invalid VPI/VCI Count                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Output Cell Count                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Output Frame Count                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                   Output Cell Discard Count                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |



Newman, et. al.              Informational                     [Page 24]

RFC 1987              GSMP Protocol Specification            August 1996


   +                  Output Frame Discard Count                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
   VPI/VCI
             Fields are the same as those of the request message.

   Input Cell Count
   Output Cell Count
             Each gives the value of a free running 64 bit counter
             counting cells arriving at the input or departing from the
             output respectively. In response to a Port Statistics
             message the count will be on a per port basis and in
             response to a VC Statistics message the count will be on a
             per VC basis.

   Input Frame Count
   Output Frame Count
             Each gives the value of a free running 64 bit counter
             counting frames (packets) arriving at the input or
             departing from the output respectively. In response to a
             Port Statistics message the count will be on a per port
             basis and in response to a VC Statistics message the count
             will be on a per VC basis.

   Input Cell Discard Count
   Output Cell Discard Count
             Each gives the value of a free running 64 bit counter
             counting cells discarded due to queue overflow on an input
             port or on an output port respectively. In response to a
             Port Statistics message the count will be on a per port
             basis and in response to a VC Statistics message the count
             will be on a per VC basis.

   Input Frame Discard Count
   Output Frame Discard Count
             Each gives the value of a free running 64 bit counter
             counting frames discarded due to queue overflow on an input
             port or on an output port respectively. In response to a
             Port Statistics message the count will be on a per port
             basis and in response to a VC Statistics message the count
             will be on a per VC basis.

   HEC Error Count
             Gives the value of a free running 64 bit counter counting
             cells discarded due to header checksum errors on arrival at
             an input port.



Newman, et. al.              Informational                     [Page 25]

RFC 1987              GSMP Protocol Specification            August 1996


   Invalid VPI/VCI Count
             Gives the value of a free running 64 bit counter counting
             cells discarded because their VPI/VCI is invalid on arrival
             at an input port. An incoming VPI/VCI is invalid if no
             connection is currently established having that value of
             VPI/VCI.

5.2.1 Port Statistics Message

   The Port Statistics message requests the statistics for the switch
   port specified in the Port field. The contents of the VPI/VCI field
   in the Port Statistics request message are ignored. All of the count
   fields in the success response message refer to per-port counts
   regardless of the virtual channels to which the cells belong.  Any of
   the count fields in the success response message not supported by the
   port will be set to zero. The Port Statistics message is:

      Message Type = 49

5.2.2 VC Statistics Message

   The VC Statistics message requests the statistics for the virtual
   channel specified in the VPI/VCI field that arrives on the switch
   input port specified in the Port field. All of the count fields in
   the success response message refer only to the specified virtual
   channel. The HEC Error Count and Invalid VPI/VCI Count fields are not
   VC specific and are set to zero. Any of the other count fields not
   supported on a per virtual channel basis will be set to zero in the
   success response message. The VC Statistics message is:

      Message Type = 50

6. Configuration

   The configuration messages permit the controller to discover the
   capabilities of the switch. Three configuration request messages have
   been defined: Switch, Port, and All Ports.














Newman, et. al.              Informational                     [Page 26]

RFC 1987              GSMP Protocol Specification            August 1996


   All configuration request messages have the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
             Identifies the port number for which configuration
             information is being requested. If the Port field is not
             required by the message it is set to zero by the sender and
             ignored by the receiver.

6.1 Switch Configuration Message

   The Switch Configuration message requests the global (non port-
   specific) configuration for the switch. The Switch Configuration
   message is:

      Message Type = 64

   The Port field is not used in the request message and is set to zero.

   The Switch Configuration success response message has the following
   format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Firmware Version Number    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Switch Type          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                          Switch Name                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Firmware Version Number
             The version number of the switch control firmware
             installed.



Newman, et. al.              Informational                     [Page 27]

RFC 1987              GSMP Protocol Specification            August 1996


   Reserved
             Field is not used. It is set to zero by the sender and
             ignored by the receiver.

   Switch Type
             A 16 bit field allocated by the manufacturer of the switch.
             (For these purposes the manufacturer of the switch is
             assumed to be the organization identified by the OUI in the
             Switch Name field.) The Switch Type identifies the product.
             When the Switch Type is combined with the OUI from the
             Switch Name the product is uniquely identified. Network
             Management may use this identification to obtain product
             related information from a database.

   Switch Name
             A 48 bit quantity that is unique within the operational
             context of the device. A 48 bit IEEE 802 MAC address, if
             available, may be used as the Switch Name. The most
             significant 24 bits of the Switch Name must be an
             Organizationally Unique Identifier (OUI) that identifies
             the manufacturer of the switch.

6.2 Port Configuration Message

   The Port Configuration message requests the switch for the
   configuration information of a single switch port. The Port field in
   the request message specifies the port for which the configuration is
   requested.  The Port Configuration message is:

      Message Type = 65.

   The Port Configuration success response message has the following
   format:


















Newman, et. al.              Informational                     [Page 28]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Port Session Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  zero |      Min VPI          |  zero |       Max VPI         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Min VCI            |           Max VCI             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Cell Rate                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Port Status  |   Port Type   |  Line Status  |  Priorities   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
             The switch port to which the configuration information
             refers. Configuration information relating to both the
             input and the output sides of the switch port is given.
             Port numbers are 32 bits wide and allocated by the switch.
             The switch may choose to structure the 32 bits into sub
             fields that have meaning to the physical structure of the
             switch hardware (e.g.  shelf, slot, interface).

   Port Session Number
             The current Port Session Number for the specified port.
             Each switch port maintains a Port Session Number assigned
             by the switch. The Port Session Number of a port remains
             unchanged while the port is continuously in the Available
             state. When a port returns to the Available state after it
             has been Unavailable, or after a power cycle, its Port
             Session Number must be changed, preferably using some form
             of random number.

   Min VPI
             The minimum value of dynamically assigned incoming VPI that
             the connection table on the input port can support and may
             be controlled by GSMP.

   Max VPI
             The maximum value of dynamically assigned incoming VPI that
             the connection table on the input port can support and may
             be controlled by GSMP. It is assumed that the input port



Newman, et. al.              Informational                     [Page 29]

RFC 1987              GSMP Protocol Specification            August 1996


             can handle all values of VPI within the range Min VPI to
             Max VPI inclusive and that GSMP may control all values
             within this range.  If the switch does not support virtual
             paths it is acceptable for both Min VPI and Max VPI to
             specify the same value, most likely zero.

   Min VCI
             The minimum value of dynamically assigned incoming VCI that
             the connection table on the input port can support and may
             be controlled by GSMP.

   Max VCI
             The maximum value of dynamically assigned incoming VCI that
             the connection table on the input port can support and may
             be controlled by GSMP. It is assumed that the input port
             can handle all values of VCI within the range Min VCI to
             Max VCI inclusive for each of the virtual paths in the
             range Min VPI to Max VPI inclusive and that GSMP may
             control all values within this range.

   Cell Rate
             A measure of the bandwidth of the port. It is the rate of
             cells arriving at or departing from the port in cells/s. It
             is assumed that both input port and output port have the
             same cell rate.

   Port Status
             Gives the administrative state of the port. The defined
             values of the Port Status field are:

             Available:
                  Port Status = 1. The port is available to both send
                  and receive cells. When a port changes to the
                  Available state from any other administrative state,
                  all dynamically assigned virtual connections must be
                  cleared and a new Port Session Number must be
                  generated.

             Unavailable:
                  Port Status = 2. The port has intentionally been taken
                  out of service. No cells will be transmitted from this
                  port.  No cells will be received by this port.

             Internal Loopback:
                  Port Status = 3. The port has intentionally been taken
                  out of service and is in internal loopback: cells
                  arriving at the output port from the switch fabric are
                  looped through to the input port to return to the



Newman, et. al.              Informational                     [Page 30]

RFC 1987              GSMP Protocol Specification            August 1996


                  switch fabric. All of the ATM functions of the input
                  port above the PHY layer, e.g. header translation, are
                  performed upon the looped back cells.

             External Loopback:
                  Port Status = 4. The port has intentionally been taken
                  out of service and is in external loopback: cells
                  arriving at the input port from the external
                  communications link are immediately looped back to the
                  communications link at the physical layer without
                  entering the input port. None of the ATM functions of
                  the input port above the PHY layer are performed upon
                  the looped back cells.

             Bothway Loopback:
                  Port Status = 5. The port has intentionally been taken
                  out of service and is in both internal and external
                  loopback.

   Port Type
             The type of physical transmission interface for this port.
             The values for this field are given by the IANAifTYPE
             object from the MIB defined for the IANAifTYPE-MIB
             specified in RFC 1573 [rfc1573]. Example values are: SONET
             or SDH (39), DS-3 (30).

   Line Status
             The status of the physical transmission medium connected to
             the port. The defined values of the Line Status field are:

             Up:
                  Line Status = 1. The line is able to both send and
                  receive cells.  When the Line Status changes to Up
                  from either the Down or Test states, a new Port
                  Session Number must be generated.

             Down:
                  Line Status = 2. The line is unable either to send or
                  receive cells or both.

             Test:
                  Line Status = 3. The port or line is in a test mode,
                  for example, power-on test.

   Priorities
             The number of different priorities that this output port
             can assign to virtual channel connections.  Zero is invalid
             in this field. If an output port is able to support "Q"



Newman, et. al.              Informational                     [Page 31]

RFC 1987              GSMP Protocol Specification            August 1996


             priorities, the highest priority is numbered zero and the
             lowest priority is numbered "Q-1". The ability to offer
             different qualities of service to different connections
             based upon their priority is assumed to be a property of
             the output port of the switch. It may be assumed that for
             virtual channel connections that share the same output
             port, an ATM cell on a connection with a higher priority is
             much more likely to exit the switch before an ATM cell on a
             connection with a lower priority if they are both in the
             switch at the same time.

6.3 All Ports Configuration Message

   The All Ports Configuration message requests the switch for the
   configuration information of all of its ports. The All Ports
   Configuration message is:

      Message Type = 66

   The Port field is not used in the request message and is set to zero.

   The All Ports Configuration success response message has the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Number of Records       |      Port Record Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Port Records                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Number of Records
             Field gives the number of Port Records to follow in the
             message. The maximum number of port records allowed in a
             single All Ports Configuration success response is 64. If a
             switch has more than 64 ports it must send them in multiple
             success response messages.

   Port Record Length
             Field gives the length of each port record in bytes. This
             is currently 24 but the Port Record Length field allows for



Newman, et. al.              Informational                     [Page 32]

RFC 1987              GSMP Protocol Specification            August 1996


             the future definition of further fields at the end of the
             port record while preserving compatibility with earlier
             versions of the protocol.

   Port Records follow in the remainder of the message. Each port record
   has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Port Session Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  zero |      Min VPI          |  zero |       Max VPI         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Min VCI            |           Max VCI             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Cell Rate                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Port Status  |   Port Type   |  Line Status  |  Priorities   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The definition of the fields in the port record is exactly the same
   as that of the Port Configuration message.

7. Event Messages

   Event messages allow the switch to inform the controller of certain
   asynchronous events. Event messages are not acknowledged. The Result
   field and the Code field in the message header are not used and
   should be set to zero. Event messages are not sent during
   initialization. Event messages have the following format:


















Newman, et. al.              Informational                     [Page 33]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero  |          VPI          |              VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port
             Field gives the switch port to which the event message
             refers.

   Port Session Number
             The current Port Session Number for the specified port.

   Event Sequence Number
             The current value of the Event Sequence Number for the
             specified port. The Event Sequence Number is set to zero
             when the port is initialized and is incremented by one each
             time an asynchronous event is detected on that port that
             the switch would normally report via an Event message. The
             Event Sequence Number must be incremented each time an
             event occurs even if the switch is prevented from sending
             an Event message due to the action of the flow control.

   VPI/VCI
             Field gives the VPI/VCI to which the event message refers.
             If this field is not required by the event message it is
             set to zero.

   Each switch port must maintain an Event Sequence Number and a set of
   Event Flags, one Event Flag for each type of Event message.  When a
   switch port sends an Event message it must set the Event Flag on that
   port corresponding to the type of the event. The port is not
   permitted to send another Event message of the same type until the
   Event Flag has been reset. Event Flags are reset by the "Reset Event
   Flags" function of the Port Management message. This is a simple flow
   control preventing the switch from flooding the controller with event
   messages. The Event Sequence Number of the port must be incremented
   every time an event is detected on that port even if the port is



Newman, et. al.              Informational                     [Page 34]

RFC 1987              GSMP Protocol Specification            August 1996


   prevented from reporting the event due to the action of the flow
   control. This allows the controller to detect that it has not been
   informed of some events that have occurred on the port due to the
   action of the flow control.

7.1 Port Up Message

   The Port Up message informs the controller that the Line Status of a
   port has changed from either the Down or Test state to the Up state.
   When the Line Status of a switch port changes to the Up state from
   either the Down or Test state a new Port Session Number must be
   generated, preferably using some form of random number. The new Port
   Session Number is given in the Port Session Number field. The VPI/VCI
   field is not used and is set to zero.  The Port Up message is:

      Message Type = 80

7.2 Port Down Message

   The Port Down message informs the controller that the Line Status of
   a port has changed from the Up state to the Down state. This message
   will be sent to report link failure if the switch is capable of
   detecting link failure. The port session number that was valid before
   the port went down is reported in the Port Session Number field. The
   VPI/VCI field is not used and is set to zero. The Port Down message
   is:

      Message Type = 81

7.3 Invalid VPI/VCI Message

   The Invalid VPI/VCI message is sent to inform the controller that one
   or more cells have arrived at an input port with a VPI/ VCI that is
   currently not allocated to an assigned connection. The input port is
   indicated in the Port field, and the VPI/VCI in the VPI/VCI field.
   The Invalid VPI/VCI message is:

      Message Type = 82

7.4 New Port Message

   The New Port message informs the controller that a new port has been
   added to the switch. The port number of the new port is given in the
   Port field. A new Port Session Number must be assigned, preferably
   using some form of random number.  The new Port Session Number is
   given in the Port Session Number field.  The state of the new port is
   undefined so the VPI/VCI field is not used and is set to zero.  The
   New Port message is:



Newman, et. al.              Informational                     [Page 35]

RFC 1987              GSMP Protocol Specification            August 1996


      Message Type = 83

7.5 Dead Port Message

   The Dead Port message informs the controller that a port has been
   removed from the switch. The port number of the port is given in the
   Port field. The Port Session Number that was valid before the port
   was removed is reported in the Port Session Number field.  The
   VPI/VCI fields are not used and are set to zero. The Dead Port
   message is:

      Message Type = 84

8. Adjacency Protocol

   The adjacency protocol is used to synchronize state across the link,
   to discover the identity of the entity at the other end of a link,
   and to detect when it changes. No GSMP messages other than those of
   the adjacency protocol may be sent across the link until the
   adjacency protocol has achieved synchronization.

8.1 Packet Format

   The adjacency protocol is:

      Message Type = 10

   All GSMP messages belonging to the adjacency protocol have the
   following structure:






















Newman, et. al.              Informational                     [Page 36]

RFC 1987              GSMP Protocol Specification            August 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Name                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                         Receiver Name                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receiver Port                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Instance                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Receiver Instance                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
             The GSMP protocol version number, currently Version = 1. It
             should be set by the sender of the message to the GSMP
             protocol version that the sender is currently running.

   Result
             Field is not used in the adjacency protocol. It should be
             set to zero by the sender and ignored by the receiver.

   Code
             Field specifies the function of the message. Four Codes are
             defined for the adjacency protocol:

                SYN:     Code = 1
                SYNACK:  Code = 2
                ACK:     Code = 3
                RSTACK:  Code = 4.

   Sender Name
             For the SYN, SYNACK, and ACK messages, is the name of the
             entity sending the message. The Sender Name is a 48 bit
             quantity that is unique within the operational context of
             the device. A 48 bit IEEE 802 MAC address, if available,
             may be used for the Sender Name. For the RSTACK message,
             the Sender Name field is set to the value of the Receiver
             Name field from the incoming message that caused the RSTACK
             message to be generated.




Newman, et. al.              Informational                     [Page 37]

RFC 1987              GSMP Protocol Specification            August 1996


   Receiver Name
             For the SYN, SYNACK, and ACK messages, is the name of the
             entity that the sender of the message believes is at the
             far end of the link. If the sender of the message does not
             know the name of the entity at the far end of the link,
             this field should be set to zero. For the RSTACK message,
             the Receiver Name field is set to the value of the Sender
             Name field from the incoming message that caused the RSTACK
             message to be generated.

   Sender Port
             For the SYN, SYNACK, and ACK messages, is the local port
             number of the link across which the message is being sent.
             Port numbers are locally assigned 32 bit values. For the
             RSTACK message, the Sender Port field is set to the value
             of the Receiver Port field from the incoming message that
             caused the RSTACK message to be generated.

   Receiver Port
             For the SYN, SYNACK, and ACK messages, is what the sender
             believes is the local port number for the link, allocated
             by the entity at the far end of the link.  If the sender of
             the message does not know the port number at the far end of
             the link, this field should be set to zero. For the RSTACK
             message, the Receiver Port field is set to the value of the
             Sender Port field from the incoming message that caused the
             RSTACK message to be generated.

   Sender Instance
             For the SYN, SYNACK, and ACK messages, is the sender's
             instance number for the link. It is used to detect when the
             link comes back up after going down or when the identity of
             the entity at the other end of the link changes. The
             instance number is a 32 bit number that is guaranteed to be
             unique within the recent past and to change when the link
             or node comes back up after going down. Zero is not a valid
             instance number. For the RSTACK message, the Sender
             Instance field is set to the value of the Receiver Instance
             field from the incoming message that caused the RSTACK
             message to be generated.

   Receiver Instance
             For the SYN, SYNACK, and ACK messages, is what the sender
             believes is the current instance number for the link,
             allocated by the entity at the far end of the link. If the
             sender of the message does not know the current instance
             number at the far end of the link, this field should be set
             to zero. For the RSTACK message, the Receiver Instance



Newman, et. al.              Informational                     [Page 38]

RFC 1987              GSMP Protocol Specification            August 1996


             field is set to the value of the Sender Instance field from
             the incoming message that caused the RSTACK message to be
             generated.

8.2 Procedure

   The adjacency protocol is described by the rules and state tables
   given in this section.

   The rules and state tables use the following operations:

    o The "Update Peer Verifier" operation is defined as storing the
      values of the Sender Instance, Sender Port, and Sender Name fields
      from a SYN or SYNACK message received from the entity at the far
      end of the link.

    o The procedure "Reset the link" is defined as:

          1. Generate a new instance number for the link
          2. Delete the peer verifier (set to zero the values of Sender
             Instance, Sender Port, and Sender Name previously stored by
             the Update Peer Verifier operation)
          3. Send a SYN message
          4. Enter the SYNSENT state

    o The state tables use the following Boolean terms and operators:

        A    The Sender Instance in the incoming message matches the
             value stored from a previous message by the "Update Peer
             Verifier" operation.

        B    The Sender Instance, Sender Port, and Sender Name fields in
             the incoming message match the values stored from a
             previous message by the "Update Peer Verifier" operation.

        C    The Receiver Instance, Receiver Port, and Receiver Name
             fields in the incoming message match the values of the
             Sender Instance, Sender Port, and Sender Name currently
             sent in outgoing SYN, SYNACK, and ACK messages.

        "&&" Represents the logical AND operation

        "||" Represents the logical OR operation

        "!" Represents the logical negation (NOT) operation.






Newman, et. al.              Informational                     [Page 39]

RFC 1987              GSMP Protocol Specification            August 1996


    o A timer is required for the periodic generation of SYN, SYNACK,
      and ACK messages. The period of the timer is unspecified but a
      value of one second is suggested.

      There are two independent events: the timer expires, and a packet
      arrives. The processing rules for these events are:

         Timer Expires:   Reset Timer
                          If state = SYNSENT Send SYN
                          If state = SYNRCVD Send SYNACK
                          If state = ESTAB   Send ACK

         Packet Arrives:  If incoming message is an RSTACK
                             If A && C && !SYNSENT
                                Reset the link
                             Else Discard the message
                          Else the following State Tables.

    o State synchronization across a link is considered to be achieved
      when the protocol reaches the ESTAB state.

   State Tables

State: SYNSENT

+======================================================================+
|     Condition      |                Action               | New State |
+====================+=====================================+===========+
|    SYNACK && C     |  Update Peer Verifier; Send ACK     |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|    SYNACK && !C    |            Send RSTACK              |  SYNSENT  |
+--------------------+-------------------------------------+-----------+
|        SYN         |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
+--------------------+-------------------------------------+-----------+
|        ACK         |            Send RSTACK              |  SYNSENT  |
+======================================================================+















Newman, et. al.              Informational                     [Page 40]

RFC 1987              GSMP Protocol Specification            August 1996


State: SYNRCVD

+======================================================================+
|     Condition      |                Action               | New State |
+====================+=====================================+===========+
|    SYNACK && C     |  Update Peer Verifier; Send ACK     |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|    SYNACK && !C    |            Send RSTACK              |  SYNRCVD  |
+--------------------+-------------------------------------+-----------+
|        SYN         |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
+--------------------+-------------------------------------+-----------+
|   ACK && B && C    |              Send ACK               |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|  ACK && !(B && C)  |            Send RSTACK              |  SYNRCVD  |
+======================================================================+


State: ESTAB

+======================================================================+
|     Condition      |                Action               | New State |
+====================+=====================================+===========+
|   SYN || SYNACK    |           Send ACK (note 1)         |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|   ACK && B && C    |           Send ACK (note 1)         |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|  ACK && !(B && C)  |              Send RSTACK            |   ESTAB   |
+======================================================================+

   Note 1: No more than one ACK should be sent within any time period of
   length defined by the timer.

9. Failure Response Messages

   A failure response message is formed by returning the request message
   that caused the failure with the Result field in the header
   indicating failure (Result = 4) and the Code field giving the failure
   code. The failure code specifies the reason for the switch being
   unable to satisfy the request message. A failure code of 16 is used
   for a failure that is specific to the particular request message and
   its meaning is defined within the text describing that message. The
   following failure codes are defined:

       1:  Unspecified reason not covered by other failure codes.
       2:  Invalid request message.
       3:  The specified request is not implemented on this switch.
       4:  Invalid port session number.
       5:  One or more of the specified ports does not exist.



Newman, et. al.              Informational                     [Page 41]

RFC 1987              GSMP Protocol Specification            August 1996


       6:  One or more of the specified ports is down.
       7:  One or more of the specified VPIs or VCIs is out of range on
           one or more of the requested ports.
       8:  The specified connection does not exist.
       9:  The specified branch does not exist.
       10: A branch belonging to the specified multicast connection is
           already established on the specified output port and the
           switch cannot support more than a single branch of any
           multicast connection on the same output port.
       11: The limit on the maximum number of multicast connections that
           the switch can support has been reached.
       12: The limit on the maximum number of branches that the
           specified multicast connection can support has been reached.
       13: Unable to assign the requested VPI/VCI value to the requested
           branch on the specified multicast connection.
       14: General problem related to the manner in which multicast is
           supported by the switch.
       15: Out of resources (e.g. memory exhausted, etc.).
       16: Failure specific to the particular message type.
































Newman, et. al.              Informational                     [Page 42]

RFC 1987              GSMP Protocol Specification            August 1996


REFERENCES

   [I.361]   "B-ISDN ATM Layer Specification," International
             Telecommunication Union, ITU-T Recommendation I.361, Mar.
             1993.

   [I.363]   "B-ISDN ATM Adaptation Layer (AAL) Specification,"
             International Telecommunication Union, ITU-T Recommendation
             I.363, Mar. 1993.

   [rfc1700] "Assigned Numbers," STD 2, RFC 1700, October 1994.

   [rfc1573] "Evolution of the Interfaces Group of MIB-II," RFC 1573,
             January 1994.


SECURITY CONSIDERATIONS

   Security issues are not discussed in this document.


AUTHORS' ADDRESSES


   Peter Newman                        Phone: +1 (415) 846-4603
   Ipsilon Networks, Inc.              Email: pn@ipsilon.com

   W. L. Edwards, Chief Scientist      Phone:  +1 (913) 534 5334
   Sprint                              Email:  texas@sprintcorp.com

   Robert M. Hinden                    Phone: +1 (415) 846-4604
   Ipsilon Networks, Inc.              Email: hinden@ipsilon.com

   Eric Hoffman                        Phone: +1 (415) 846-4610
   Ipsilon Networks, Inc.              Email: hoffman@ipsilon.com

   Fong Ching Liaw                     Phone: +1 (415) 846-4607
   Ipsilon Networks, Inc.              Email: fong@ipsilon.com

   Tom Lyon                            Phone: +1 (415) 846-4601
   Ipsilon Networks, Inc.              Email: pugs@ipsilon.com

   Greg Minshall                       Phone: +1 (415) 846-4605
   Ipsilon Networks, Inc.              Email: minshall@ipsilon.com







Newman, et. al.              Informational                     [Page 43]

RFC 1987              GSMP Protocol Specification            August 1996


Ipsilon Networks, Inc. is located at:

   2191 East Bayshore Road
   Suite 100
   Palo Alto, CA 94303
   USA

Sprint is located at:

   Sprint
   Sprint Technology Services - Long Distance Division
   9300 Metcalf Avenue
   Mailstop KSOPKB0802
   Overland Park, KS 66212-6333
   USA




































Newman, et. al.              Informational                     [Page 44]