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]
|