idnits 2.17.1 draft-rfced-info-newman-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 65 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10167 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 9 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Newman, Ipsilon 2 Internet-Draft W. L. Edwards, Sprint 3 Category: Informational R. Hinden, Ipsilon 4 E. Hoffman, Ipsilon 5 F. Ching Liaw, Ipsilon 6 T. Lyon, Ipsilon 7 G. Minshall, Ipsilon 8 June 1996 10 General Switch Management Protocol Specification 12 Version 1.1 14 16 Status of this Memo 18 This document is an Internet Draft. Internet Drafts are working 19 documents. 21 Internet Drafts are draft documents valid for a maximum of 6 months. 22 Internet Drafts may be updated, replaced, or obsoleted by other 23 documents at any time. It is not appropriate to use Internet Drafts 24 as reference material or to cite them other than as "work in 25 progress". 27 Abstract 29 The General Switch Management Protocol (GSMP), is a general purpose 30 protocol to control an ATM switch. GSMP allows a controller to 31 establish and release connections across the switch; add and delete 32 leaves on a point-to-multipoint connection; manage switch ports; 33 request configuration information; and request statistics. 35 Table of Contents 37 1. Introduction.......................................................3 39 2. GSMP Packet Format.................................................4 41 3. Connection Management Messages.....................................7 42 3.1 Add Branch Message............................................10 43 3.2 Delete Branch Message.........................................12 44 3.3 Delete Tree Message...........................................12 45 3.4 Verify Tree Message...........................................13 46 3.5 Delete All Message............................................14 47 3.6 Move Branch Message...........................................14 49 4. Port Management Message...........................................16 51 5. Statistics Messages...............................................20 52 5.1 VC Activity Message...........................................20 53 5.2 Port and VC Statistics Messages...............................23 54 5.2.1 Port Statistics Message.................................26 55 5.2.2 VC Statistics Message...................................26 57 6. Configuration.....................................................26 58 6.1 Switch Configuration Message..................................27 59 6.2 Port Configuration Message....................................28 60 6.3 All Ports Configuration Message...............................32 62 7. Event Messages....................................................33 63 7.1 Port Up Message...............................................34 64 7.2 Port Down Message.............................................35 65 7.3 Invalid VPI/VCI Message.......................................35 66 7.4 New Port Message..............................................35 67 7.5 Dead Port Message.............................................35 69 8. Adjacency Protocol................................................36 70 8.1 Packet Format.................................................36 71 8.2 Procedure.....................................................38 73 9. Failure Response Messages.........................................41 75 References...........................................................42 76 Security Considerations..............................................42 77 Authors' Addresses...................................................42 79 1. Introduction 81 The General Switch Management Protocol (GSMP), is a general purpose 82 protocol to control an ATM switch. GSMP allows a controller to 83 establish and release connections across the switch; add and delete 84 leaves on a point-to-multipoint connection; manage switch ports; 85 request configuration information; and request statistics. It also 86 allows the switch to inform the controller of asynchronous events 87 such as a link going down. GSMP runs across an ATM link connecting 88 the controller to the switch, on a control connection (virtual 89 channel) established at initialization. The GSMP protocol is 90 asymmetric, the controller being the master and the switch being the 91 slave. Multiple switches may be controlled by a single controller 92 using multiple instantiations of the protocol over separate control 93 connections. 95 A switch is assumed to contain multiple "ports". Each port is a 96 combination of one "input port" and one "output port". Some GSMP 97 requests refer to the port as a whole whereas other requests are 98 specific to the input port or the output port. ATM cells arrive at 99 the switch from an external communication link on incoming virtual 100 channels at an input port. ATM cells depart from the switch to an 101 external communication link on outgoing virtual channels from an 102 output port. Virtual channels on a port or link are referenced by 103 their virtual path and virtual channel identifiers (VPI/VCI). A 104 virtual channel connection across a switch is formed by connecting an 105 incoming virtual channel to one or more outgoing virtual channels. 106 Virtual channel connections are referenced by the input port on which 107 they arrive and the virtual path and virtual channel identifiers 108 (VPI/VCI) of their incoming virtual channel. 110 In general a virtual channel is established with a certain quality of 111 service (QOS). Unfortunately this is an ill defined and changing 112 concept as new ideas make their way into hardware. For this version 113 of the GSMP protocol it is assumed that each virtual channel 114 connection may be assigned a priority when it is established. It may 115 be assumed that for virtual channel connections that share the same 116 output port, an ATM cell on a connection with a higher priority is 117 much more likely to exit the switch before an ATM cell on a 118 connection with a lower priority if they are both in the switch at 119 the same time. The number of priorities that each port of the switch 120 supports may be obtained from the port configuration message. 122 Switch ports are described by a 32 bit port number. The switch 123 assigns port numbers and it may typically choose to structure the 32 124 bits into sub-fields that have meaning to the physical structure of 125 the switch (e.g. shelf, slot, port). In general, a port in the same 126 physical location on the switch will always have the same port 127 number, even across power cycles. The internal structure of the port 128 number is opaque to the GSMP protocol. However, by looking up the 129 product identity in a database, network management tools may discover 130 the partitioning of the port number and the physical meaning of the 131 sub-fields. 133 Each switch port also maintains a port session number assigned by the 134 switch. A connection management message or a port management message 135 with an incorrect port session number must be rejected. This allows 136 the controller to detect a link failure and to keep state 137 synchronized. The port session number of a port remains unchanged 138 while the port is continuously in the available state and the link 139 status is continuously up. When a port returns to the available state 140 after it has been unavailable or in any of the loopback states, or 141 when the line status returns to the up state after it has been down 142 or in test, or after a power cycle, its port session number will have 143 changed. Port session numbers should be assigned using some form of 144 random number. 146 GSMP also contains an adjacency protocol. The adjacency protocol is 147 used to synchronize state across the link, to discover the identity 148 of the entity at the other end of a link, and to detect when it 149 changes. 151 2. GSMP Packet Format 153 GSMP packets are variable length and are encapsulated directly in an 154 AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header as illustrated: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | LLC (0xAA-AA-03) | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 161 | SNAP (0x00-00-00-88-0C) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ GSMP Message ~ 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Pad (0 - 47 octets) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 + AAL-5 CPCS-PDU Trailer (8 octets) + 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 (The convention in the documentation of Internet Protocols [rfc1700] 174 is to express numbers in decimal and to picture data in "big-endian" 175 order. That is, fields are described left to right, with the most 176 significant octet on the left and the least significant octet on the 177 right. Whenever a diagram shows a group of octets, the order of 178 transmission of those octets is the normal order in which they are 179 read in English. Whenever an octet represents a numeric quantity the 180 left most bit in the diagram is the high order or most significant 181 bit. That is, the bit labeled 0 is the most significant bit. 182 Similarly, whenever a multi-octet field represents a numeric quantity 183 the left most bit of the whole field is the most significant bit. 184 When a multi-octet quantity is transmitted, the most significant 185 octet is transmitted first. This is the same coding convention as is 186 used in the ATM layer [I.361] and AAL-5 [I.363].) 188 The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00 189 0x00 0x88 0x0C. 191 The maximum transmission unit (MTU) of the GSMP message is 1500 192 octets. 194 The default virtual channel for LLC/SNAP encapsulated messages is: 196 VPI = 0 197 VCI = 15. 199 GSMP is a master-slave protocol. The controller issues request 200 messages to the switch. Each request message indicates whether a 201 response is required from the switch and contains a transaction 202 identifier to enable the response to be associated with the request. 203 The switch replies with a response message indicating either a 204 successful result or a failure. There are four classes of GSMP 205 request-response message: Connection Management, Port Management, 206 Statistics, and Configuration. The switch may also generate 207 asynchronous Event messages to inform the controller of asynchronous 208 events. Event messages are not acknowledged by the controller. There 209 is also an adjacency protocol message used to establish 210 synchronization across the link and maintain a handshake. 212 For the request-response messages each message type has a format for 213 the request message and a format for the success response. Unless 214 otherwise specified a failure response message is identical to the 215 request message that caused the failure, with the Code field 216 indicating the nature of the failure. Event messages have only a 217 single format defined as they are not acknowledged by the controller. 219 Except for the adjacency protocol message, no GSMP messages may be 220 sent across the link until the adjacency protocol has achieved 221 synchronization, and all GSMP messages received on a link that does 222 not currently have state synchronization must be discarded. 224 All GSMP messages, except the adjacency protocol message, have the 225 following format: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Version | Message Type | Result | Code | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Transaction Identifier | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 ~ Message Body ~ 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Version 240 The GSMP protocol version number, currently Version = 1. It 241 should be set by the sender of the message to the GSMP 242 protocol version that the sender is currently running. 244 Message Type 245 The GSMP message type. GSMP messages fall into five 246 classes: Connection Management, Port Management, 247 Statistics, Configuration, and Events. Each class, except 248 for port management, has a number of different message 249 types. In addition, one Message Type is allocated to the 250 adjacency protocol. 252 Result 253 Field in a connection management request message or a port 254 management request message, is used to indicate whether a 255 response is required to the request message if the outcome 256 is successful. A value of "NoSuccessAck" indicates that the 257 request message does not expect a response if the outcome 258 is successful, and a value of "AckAll" indicates that a 259 response is expected if the outcome is successful. In both 260 cases a failure response will be generated if the request 261 fails. This facility reduces the traffic in the case where 262 the controller is simply checking that the state in the 263 switch is correct. For all other request messages a value 264 of "NoSuccessAck" in the request message is ignored and the 265 request message is handled as if the field were set to 266 "AckAll". In a response message the result field can have 267 two values: "Success" and "Failure". 269 The encoding of the result field is: 271 NoSuccessAck: Result = 1 272 AckAll: Result = 2 273 Success: Result = 3 274 Failure: Result = 4. 276 The Result field is not used in an adjacency protocol 277 message and should be set to zero by the sender and ignored 278 by the receiver. 280 Code 281 Field gives further information concerning the result in a 282 response message. It is mostly used to pass an error code 283 in a failure response but can also be used to give further 284 information in a success response message or an event 285 message. In a request message the code field is not used 286 and is set to zero. In an adjacency protocol message the 287 Code field is used to determine the function of the 288 message. 290 Transaction Identifier 291 Used to associate a request message with its response 292 message. For request messages the controller may select any 293 transaction identifier. For response messages the 294 transaction identifier is set to the value of the 295 transaction identifier from the message to which it is a 296 response. For event messages the transaction identifier 297 should be set to zero. In the adjacency protocol the 298 Transaction Identifier is not used. This field is not 299 present in the adjacency protocol message. 301 3. Connection Management Messages 303 Connection management messages are used by the controller to 304 establish, delete, modify and verify connections across the switch. 305 The Add Branch, Delete Branch, Delete Tree, Verify Tree, and Delete 306 All connection management messages have the following format for both 307 request and response messages: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Version | Message Type | Result | Code | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Transaction Identifier | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Port Session Number | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Input Port | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | zero | Input VPI | Input VCI | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Output Port | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | zero | Output VPI | Output VCI | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Number of Branches | Reserved | Priority | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Port Session Number 330 Field gives the session number of the input port. Each 331 switch port maintains a Port Session Number assigned by the 332 switch. The port session number of a port remains unchanged 333 while the port is continuously in the Available state and 334 the link status is continuously Up. When a port returns to 335 the Available state after it has been Unavailable or in any 336 of the Loopback states, or when the line status returns to 337 the Up state after it has been Down or in Test, or after a 338 power cycle, a new Port Session Number must be generated. 339 Port session numbers should be assigned using some form of 340 random number. The switch must reject any connection 341 management request message that has an invalid Port Session 342 Number for the port specified in the Input Port field by 343 returning a failure response message with the Code field 344 indicating, "Invalid port session number." The current port 345 session number may be obtained using a configuration 346 message. 348 Input Port 349 Indicates a switch input port. Switch ports are referenced 350 by a 32 bit value assigned by the switch. 352 Input VPI 353 Identifies an ATM virtual path arriving at the switch input 354 port indicated by the Input Port field. 356 Input VCI 357 Identifies an ATM virtual channel arriving on the virtual 358 path indicated by the Input VPI field at the switch input 359 port indicated by the Input Port field. 361 Output Port 362 Indicates a switch output port. Switch ports are 363 referenced by a 32 bit value assigned by the switch. 365 Output VPI 366 Identifies an outgoing virtual path departing from the 367 switch output port indicated in the Output Port field. 369 Output VCI 370 Identifies an outgoing virtual channel departing on the 371 virtual path indicated by the Output VPI field from the 372 switch output port indicated in the Output Port field. 374 Number of Branches 375 Gives the number of output branches on a virtual channel 376 connection. (A unicast connection will have one branch, a 377 multicast connection will have two or more branches.) This 378 field is only used in the Verify Tree message. In all 379 other connection management messages this field should be 380 set to zero by the sender and ignored by the receiver. 382 Reserved 383 This field is not used. It is set to zero by the sender and 384 ignored by the receiver. 386 Priority 387 Gives the priority of the connection. The highest priority 388 is numbered zero and the lowest priority is numbered "Q-1" 389 where "Q" is the number of priorities that the output port 390 can support. The ability to offer different qualities of 391 service to different connections based upon their priority 392 is assumed to be a property of the output port of the 393 switch. It is assumed that for virtual channel connections 394 that share the same output port, an ATM cell on a 395 connection with a higher priority is much more likely to 396 exit the switch before an ATM cell on a connection with a 397 lower priority if they are both in the switch at the same 398 time. The number of priorities that each output port can 399 support is given in the Port Configuration message. If a 400 connection request is received with a value in the priority 401 field that the switch cannot support, the switch will 402 assign the closest priority that it is capable of 403 supporting. This field is only used in the Add Branch and 404 Move Branch messages. In all other connection management 405 messages this field should be set to zero by the sender and 406 ignored by the receiver. 408 If the result field of the request message is "AckAll" the switch 409 must reply to all connection management request messages with a 410 success response message or a failure response message. If the 411 result field of the request message is "NoSuccessAck" the switch must 412 only reply in the case of a failure. 414 A success response message must not be sent until the operation has 415 been successfully completed. For connection management messages the 416 success response message is a copy of the request message returned 417 with a Result field indicating success. The Code field is not used in 418 a connection management success response message and should be set to 419 zero. The failure response message is a copy of the request message 420 returned with a Result field indicating failure. The Code field is 421 used to pass the Failure Code in a connection management failure 422 response message. If the switch issues a failure response the 423 connection state within the switch must not be modified by the 424 request message that resulted in the failure. 426 No distinction is made between unicast connections and multicast 427 connections. The first Add Branch message for a particular Input 428 Port, Input VPI, and Input VCI will establish a unicast connection. 429 The second Add Branch message with the same Input Port, Input VPI, 430 and Input VCI fields will convert the connection to a multicast 431 connection with two branches. Subsequent Add Branch messages with the 432 same Input Port, Input VPI, and Input VCI fields will add further 433 branches to the multicast connection. Use of the Delete Branch 434 message on a multicast connection with two branches will result in a 435 unicast connection. Use of the Delete Branch message on a unicast 436 connection will delete the unicast connection. There is no concept of 437 a connection with zero output branches. All connections are 438 unidirectional, one input virtual channel to one or more output 439 virtual channels. 441 The connection management messages may be issued regardless of the 442 Port Status of the switch port. Connections may be established or 443 deleted when a switch port is in the Available, Unavailable, or any 444 of the Loopback states. However, all connection state on an input 445 port will be deleted when the port returns to the Available state 446 from any other state, i.e. when a Port Management message is received 447 for that port with the Function field indicating either Bring Up, or 448 Reset Input Port. 450 3.1 Add Branch Message 452 The Add Branch message is a connection management message used to 453 establish a virtual channel connection or to add an additional branch 454 to an existing virtual channel connection. It may also be used to 455 check the connection state stored in the switch. The connection is 456 specified by the Input Port, Input VPI, and Input VCI fields. The 457 output branch is specified by the Output Port, Output VPI, and Output 458 VCI fields. The priority of the connection is specified by the 459 Priority field. The Add Branch message is: 461 Message Type = 16 463 If the virtual channel connection specified by the Input Port, Input 464 VPI, and Input VCI fields does not already exist, it must be 465 established with the single output branch specified in the request 466 message. The output branch should have the priority specified by the 467 Priority field. If the Result field of the request message is 468 "AckAll" a success response message must be sent upon successful 469 establishment of the specified branch. The success response message 470 must not be sent until the Add Branch operation has been completed. 472 If the virtual channel connection specified by the Input Port, Input 473 VPI, and Input VCI fields already exists, but the specified output 474 branch does not, the new output branch must be added. The new output 475 branch should have the priority specified by the Priority field. If 476 the Result field of the request message is "AckAll" a success 477 response message must be sent upon successful establishment of the 478 specified branch. The success response message must not be sent until 479 the Add Branch operation has been completed. 481 If the virtual channel connection specified by the Input Port, Input 482 VPI, and Input VCI fields already exists and the specified output 483 branch also already exists, the priority of the connection, if 484 different from the request message, should be changed to that in the 485 request message. A success response message must be sent if the 486 Result field of the request message is "AckAll". This allows the 487 controller to periodically reassert the state of a connection or to 488 change its priority. If the result field of the request message is 489 "NoSuccessAck" a success response message should not be returned. 490 This may be used to reduce the traffic on the control link for 491 messages that are reasserting previously established state. For 492 messages that are reasserting previously established state, the 493 switch must always check that this state is correctly established in 494 the switch hardware (i.e. the actual connection tables used to 495 forward cells). 497 The behavior is undefined if the output virtual channel specified by 498 the Output Port, Output VPI, and Output VCI fields is already in use 499 by any connection other than that specified by the Input Port, Input 500 VPI, and Input VCI fields. 502 A failure response must be returned if the switch is unable to 503 establish the specified branch or if there is an error in any of the 504 fields of the request message. If a failure message is returned the 505 state of the switch must not have been modified by the request 506 message. 508 It should be noted that different switches support multicast in 509 different ways. There will be a limit to the total number of 510 multicast connections any switch can support, and possibly a limit on 511 the maximum number of branches that a multicast connection may 512 specify. Some switches also impose a limit on the number of 513 different VPI/VCI values that may be assigned to the output branches 514 of a multicast connection. Many switches are incapable of supporting 515 more than a single branch of any particular multicast connection on 516 the same output port. Specific failure codes are defined for some of 517 these conditions. If a switch sends a failure response to an Add 518 Branch message it must choose the most specific failure code. 520 3.2 Delete Branch Message 522 The Delete Branch message is a connection management message used to 523 delete a single branch of a virtual channel connection, or in the 524 case of the last branch, to delete the connection. The virtual 525 channel connection is specified by the Input Port, Input VPI, and 526 Input VCI fields. The specific branch is indicated by the Output 527 Port, Output VPI, and Output VCI fields. The Delete Branch message 528 is: 530 Message Type = 17 532 If the Result field of the request message is "AckAll" a success 533 response message must be sent upon successful deletion of the 534 specified branch. The success response message must not be sent until 535 the delete branch operation has been completed and if possible, not 536 until all data on that branch, queued for transmission, has been 537 transmitted. A failure message indicating, "The specified connection 538 does not exist," must be sent if the connection specified by the 539 Input Port, Input VPI, and Input VCI fields does not exist. A failure 540 message indicating, "The specified branch does not exist," must be 541 sent if the connection specified by the Input Port, Input VPI, and 542 Input VCI fields exists but the branch specified by the Output Port, 543 Output VPI, and Output VCI fields does not exist. 545 3.3 Delete Tree Message 547 The Delete Tree message is a connection management message used to 548 delete an entire virtual channel connection. All remaining branches 549 of the connection are deleted. The virtual channel connection is 550 specified by the Input Port, Input VPI, and Input VCI fields. The 551 Output Port, Output VPI, and Output VCI fields are not used in this 552 message and their contents should be set to zero by the sender and 553 ignored by the receiver. The Delete Tree message is: 555 Message Type = 18 557 If the Result field of the request message is "AckAll" a success 558 response message must be sent upon successful deletion of the 559 specified connection. The success message must not be sent until the 560 delete operation has been completed and if possible, not until all 561 data on the connection, queued for transmission, has been 562 transmitted. A failure message indicating, "The specified connection 563 does not exist," must be sent if the connection specified by the 564 Input Port, Input VPI, and Input VCI fields does not exist. 566 3.4 Verify Tree Message 568 The Verify Tree message is a connection management message used to 569 verify the number of branches on a virtual channel connection. The 570 virtual channel connection is specified by the Input Port, Input VPI, 571 and Input VCI fields. The Output Port, Output VPI, and Output VCI 572 fields are not used in this message and their contents should be set 573 to zero by the sender and ignored by the receiver. The number of 574 branches that the sender believes that this virtual channel 575 connection should contain is given by the Number of Branches field. 576 The Verify Tree message is: 578 Message Type = 19 580 If the Result field of the request message is "AckAll" a success 581 response message must be sent if the receiver agrees that the actual 582 number of branches of the specified virtual channel connection 583 matches the number contained in the Number of Branches field of the 584 request message. The failure response message, with the code field 585 set to "Failure specific to the particular message type," must be 586 sent if the actual number of branches of the specified virtual 587 channel connection does not match the number contained in the Number 588 of Branches field of the request message. In this failure response 589 message the Number of Branches field must be changed to contain the 590 actual number of branches of the specified virtual channel 591 connection. A failure response message with the code field set to a 592 different value must be used to indicate some other failure such as, 593 "The specified connection does not exist." In this case the Number of 594 Branches field will be the same as that of the request message. 596 The Verify Tree message can only be guaranteed to yield a correct 597 response when there are no other connection request messages or their 598 response messages pending for the specified connection. If this is 599 not the case the result of the Verify Tree message is undefined. 601 3.5 Delete All Message 603 The Delete All message is a connection management message used to 604 delete all connections on a switch input port. All connections that 605 arrive at the specified input port must be deleted. On completion of 606 the operation all dynamically assigned VPI/VCI values for the 607 specified port must be unassigned, i.e. there must be no virtual 608 connections established in the VPI/VCI space that GSMP controls on 609 this port. The Input VPI, Input VCI, Output Port, Output VPI, and 610 Output VCI fields are not used in this message and their contents are 611 ignored and unspecified. The Delete All message is" 613 Message Type = 20 615 If the Result field of the request message is "AckAll" a success 616 response message must be sent upon completion of the operation. The 617 success response message must not be sent until the operation has 618 been completed. 620 3.6 Move Branch Message 622 The Move Branch connection management message has the following 623 format for both request and response messages: 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Version | Message Type | Result | Code | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Transaction Identifier | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Port Session Number | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Input Port | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | zero | Input VPI | Input VCI | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Old Output Port | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | zero | Old Output VPI | Old Output VCI | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | New Output Port | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | zero | New Output VPI | New Output VCI | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Reserved | Priority | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 The Move Branch message is a connection management message used to 650 move a single output branch of a virtual channel connection from its 651 current output port, output VPI, and output VCI, to a new output 652 port, output VPI, and output VCI on the same virtual channel 653 connection. None of the other output branches are modified. When the 654 operation is complete the original output VPI/VCI on the original 655 output port will be deleted from the connection. The Move Branch 656 message is: 658 Message Type = 22 660 If the virtual channel connection specified by the Input Port, Input 661 VPI, and Input VCI fields already exists, and the output branch 662 specified by the Old Output Port, Old Output VPI, and Old Output VCI 663 fields exists as a branch on that connection, the output branch 664 specified by the New Output Port, New Output VPI, and New Output VCI 665 fields is added to the connection and the branch specified by the Old 666 Output Port, Old Output VPI, and Old Output VCI fields is deleted. If 667 the Result field of the request message is "AckAll" a success 668 response message must be sent upon successful completion of the 669 operation. The success response message must not be sent until the 670 Move Branch operation has been completed. 672 If the virtual channel connection specified by the Input Port, Input 673 VPI, and Input VCI fields already exists, but the output branch 674 specified by the Old Output Port, Old Output VPI, and Old Output VCI 675 fields does not exist as a branch on that connection, a failure 676 response must be returned with the Code field indicating, "The 677 specified branch does not exist." The connection state of the switch 678 must not be modified in this case. 680 If the virtual channel connection specified by the Input Port, Input 681 VPI, and Input VCI fields does not exist, a failure response must be 682 returned with the Code field indicating, "The specified connection 683 does not exist." The connection state of the switch must not be 684 modified in this case. 686 The behavior is undefined if the output virtual channel specified by 687 the New Output Port, New Output VPI, and New Output VCI fields is 688 already in use by any connection. 690 A failure response will be returned if the switch is unable to 691 establish the specified branch or if there is an error in any of the 692 fields of the request message. If a failure message is returned the 693 state of the switch must not have been modified by the request 694 message. 696 4. Port Management Message 698 The Port Management message allows a port to be brought into service, 699 taken out of service, looped back, or reset. Only the Bring Up and 700 the Reset Input Port functions change the connection state 701 (established connections) on the input port. Only the Bring Up 702 function changes the value of the Port Session Number. If the Result 703 field of the request message is "AckAll" a success response message 704 must be sent upon successful completion of the operation. The success 705 response message must not be sent until the operation has been 706 completed. The Port Management Message is: 708 Message Type = 32 710 The Port Management message has the following format for the request 711 and success response messages: 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Version | Message Type | Result | Code | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Transaction Identifier | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Port | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Port Session Number | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Event Sequence Number | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Event Flags | Duration | Function | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Port 730 Gives the port number of the port to which the message 731 applies. 733 Port Session Number 734 Gives the current port session number for the port. If the 735 Port Session Number in the request message does not match 736 the current port session number of the port indicated by 737 the Port field of the request message, a failure response 738 must be returned with, "Invalid port session number," 739 indicated in the Code field. If the specified function 740 requires a new Port Session Number to be generated the new 741 Port Session Number must be given in the success response 742 message. The Port Session Number must be generated using 743 some form of random number. 745 Event Sequence Number 746 In the success response message gives the current value of 747 the Event Sequence Number of the switch port indicated by 748 the Port field. The Event Sequence Number is set to zero 749 when the port is initialized and is incremented by one each 750 time an asynchronous event is detected on that port that 751 the switch would normally report via an Event message. If 752 the Event Sequence Number in the success response differs 753 from the Event Sequence Number of the most recent Event 754 message received for that port, events have occurred that 755 were not reported via an Event message. This is most likely 756 to be due to the flow control that restricts the rate at 757 which a switch can send Event messages for each port. In 758 the request message this field is not used and should be 759 set to zero by the sender and ignored by the receiver. 761 Event Flags 762 Field in the request message is used to reset the Event 763 Flags in the switch port indicated by the Port field. Each 764 Event Flag in a switch port corresponds to a type of Event 765 message. When a switch port sends an Event message it sets 766 the corresponding Event Flag on that port. The port is not 767 permitted to send another Event message of the same type 768 until the Event Flag has been reset. If the Function field 769 in the request message is set to "Reset Event Flags," for 770 each bit that is set in the Event Flags field, the 771 corresponding Event Flag in the switch port is reset. 773 The Event Flags field is only used in a request message 774 with the Function field set to "Reset Event Flags." For all 775 other values of the Function field, the Event Flags field 776 should be set to zero in the request message and must be 777 ignored by the receiver. In the success response message 778 the Event Flags field must be set to the current value of 779 the Event Flags for the port, after the completion of the 780 operation specified by the request message, for all values 781 of the Function field. Setting the Event Flags field to all 782 zeros in a "Reset Event Flags" request message allows the 783 controller to obtain the current state of the Event Flags 784 and the current Event Sequence Number of the port without 785 changing the state of the Event Flags. 787 The correspondence between the types of Event message and 788 the bits of the Event Flags field is as follows: 790 Port Up: Bit 0, (most significant bit) 791 Port Down: Bit 1, 792 Invalid VPI/VCI: Bit 2, 793 New Port: Bit 3, 794 Dead Port: Bit 4. 796 Duration 797 Is the length of time, in seconds, that any of the loopback 798 states remain in operation. When the duration has expired 799 the port will automatically be returned to service. If 800 another Port Management message is received for the same 801 port before the duration has expired, the loopback will 802 continue to remain in operation for the length of time 803 specified by the Duration field in the new message. The 804 Duration field is only used in request messages with the 805 Function field set to Internal Loopback, External Loopback, 806 or Bothway Loopback. In all other request messages it 807 should be set to zero by the sender and ignored by the 808 receiver. 810 Function 811 Specifies the action to be taken. The specified action will 812 be taken regardless of the current status of the port 813 (Available, Unavailable, or any Loopback state). The 814 defined values of the Function field are: 816 Bring Up: 817 Function = 1. Bring the port into service. All 818 connections that arrive at the specified input port 819 must be deleted and a new Port Session Number must be 820 selected using some form of random number. On 821 completion of the operation all dynamically assigned 822 VPI/VCI values for the specified input port must be 823 unassigned, i.e. no virtual connections will be 824 established in the VPI/VCI space that GSMP controls on 825 this input port. The Port Status of the port 826 afterwards will be Available. 828 Take Down: 829 Function = 2. Take the port out of service. Any cells 830 received at this port will be discarded. No cells will 831 be transmitted from this port. The Port Status of the 832 port afterwards will be Unavailable. The behavior is 833 undefined if the port over which the GSMP protocol is 834 running is taken down. 836 Internal Loopback: 837 Function = 3. Cells arriving at the output port from 838 the switch fabric are looped through to the input port 839 to return to the switch fabric. All of the ATM 840 functions of the input port above the PHY layer, e.g. 841 header translation, are performed upon the looped back 842 cells. The Port Status of the port afterwards will be 843 Internal Loopback. 845 External Loopback: 846 Function = 4. Cells arriving at the input port from 847 the external communications link are immediately 848 looped back to the communications link at the physical 849 layer without entering the input port. None of the ATM 850 functions of the input port above the PHY layer are 851 performed upon the looped back cells. The Port Status 852 of the port afterwards will be External Loopback. 854 Bothway Loopback: 855 Function = 5. Both internal and external loopback are 856 performed. The Port Status of the port afterwards will 857 be Bothway Loopback. 859 Reset Input Port: 860 Function = 6. All connections that arrive at the 861 specified input port must be deleted and the input and 862 output port hardware re-initialized. On completion of 863 the operation all dynamically assigned VPI/VCI values 864 for the specified input port must be unassigned, i.e. 865 no virtual connections will be established in the 866 VPI/VCI space that GSMP controls on this input port. 867 The Port Session Number is not changed by the Reset 868 Input Port function. The Port Status of the port 869 afterwards will be Unavailable. 871 Reset Event Flags: 872 Function = 7. For each bit that is set in the Event 873 Flags field, the corresponding Event Flag in the 874 switch port must be reset. The Port Status of the port 875 is not changed by this function. 877 5. Statistics Messages 879 The statistics messages permit the controller to request the values 880 of various hardware counters associated with the switch input and 881 output ports, and virtual channels. Two classes of statistics message 882 are defined: the VC Activity Message, and the Port and VC Statistics 883 Messages. The VC Activity message is used to determine whether one or 884 more specific VCs have recently been carrying traffic. The Port and 885 VC Statistics message is used to query the various port and VC 886 specific traffic and error counters. 888 5.1 VC Activity Message 890 The VC Activity message is used to determine whether one or more 891 specific VCs have recently been carrying traffic. The VC Activity 892 message contains one or more VC Activity records. Each VC Activity 893 record is used to request and return activity information concerning 894 a single virtual connection. Each VC is specified by its input port, 895 input VPI, and input VCI. These are specified in the Input Port, 896 Input VPI, and Input VCI fields of each VC Activity record. Two 897 forms of activity detection are supported. If the switch supports per 898 VC traffic accounting the current value of the traffic counter for 899 each specified VC must be returned. The units of traffic counted are 900 not specified but will typically be either cells or frames. The 901 controller must compare the traffic counts returned in the message 902 with previous values for each of the specified VCs to determine 903 whether each VC has been active in the intervening period. If the 904 switch does not support per VC traffic accounting, but is capable of 905 detecting per-VC activity by some other unspecified means, the result 906 may be indicated for each VC using the Flags field. The VC Activity 907 message is: 909 Message Type = 48 911 The VC Activity request and success response messages have the 912 following format: 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Version | Message Type | Result | Code | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Transaction Identifier | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Number of Records | Reserved | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | | 924 ~ VC Activity Records ~ 925 | | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Number of Records 929 Field specifies the number of VC Activity records to 930 follow. The maximum number of VC Activity records permitted 931 in a single VC Activity message is 120. 933 Reserved 934 Field is not used. It is set to zero by the sender and 935 ignored by the receiver. 937 Each VC Activity Record has the following format: 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Input Port | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Flags | Input VPI | Input VCI | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 + VC Traffic Count + 946 | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Input Port 950 Identifies the port number of the input port on which the 951 VC of interest arrives in order to identify the VC 952 (regardless of whether the traffic count for the VC is 953 maintained on the input port or the output port). 955 Input VPI 956 Input VCI 957 Fields identify the specific virtual channel for which 958 statistics are being requested. 960 Flags 961 In the request message this field is unused, it should be 962 set to zero by the sender and ignored by the receiver. In 963 the success response message bit 0 (msb) of the Flags field 964 is used to indicate an invalid VC Activity record. This bit 965 must be zero if any of the fields in this VC Activity 966 record are invalid, if the input port specified by the 967 Input Port field does not exist, or if the specified 968 connection does not exist. If this bit is zero in a success 969 response message bits 1 and 2 of the Flags field and the VC 970 Traffic Count field are undefined. If bit 0 of the flags 971 field is set, the VC Activity record is valid, and bits 1 972 and 2 of the Flags field in the VC Activity record are used 973 as follows: 975 Bit 1 of the Flags field: if set, indicates that the 976 value in bit 2 of the Flags field is valid; if zero, 977 indicates that the value in the VC Traffic Count field 978 is valid. 980 If bit 1 of the Flags field is set, bit 2 of the Flags 981 field, if set, indicates that there has been some 982 activity on this virtual channel since the last VC 983 Activity message for this virtual channel. 985 If bit 1 of the Flags field is set, bit 2 of the Flags 986 field, if zero, indicates that there has been no 987 activity on this virtual channel since the last VC 988 Activity message for this virtual channel. 990 Bit 3 of the Flags field is not used, it should be set 991 to zero by the sender and ignored by the receiver. 993 VC Traffic Count 994 Field is unused in the request message, it should be set to 995 zero by the sender and ignored by the receiver. In the 996 success response message, if the switch supports per-VC 997 traffic counting, the VC Traffic Count field must be set to 998 the value of a free running, VC specific, 64 bit traffic 999 counter counting traffic flowing across the specified 1000 virtual channel. The value of the traffic counter is not 1001 modified by reading it. If per-VC traffic counting is 1002 supported, the switch must report the VC Activity result 1003 using the traffic count rather than using bit 2 of the 1004 Flags field. 1006 The format of the failure response is the same as the request message 1007 with the Number of Records field set to zero and no VC Activity 1008 records returned in the message. If the switch is incapable of 1009 detecting per-VC activity, a failure response must be returned 1010 indicating, "The specified request is not implemented on this 1011 switch." 1013 5.2 Port and VC Statistics Messages 1015 The Port and VC Statistics messages are used to query the various 1016 port and VC specific traffic and error counters. 1018 The Port and VC Statistics request messages have the following 1019 format: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Version | Message Type | Result | Code | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Transaction Identifier | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Port | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | zero | VPI | VCI | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Port 1034 Identifies the port number of the port for which statistics 1035 are being requested. 1037 VPI 1038 VCI 1039 Fields identify the specific virtual channel for which 1040 statistics are being requested. For requests that do not 1041 require a virtual channel to be specified these fields 1042 should be set to zero in the request and ignored by the 1043 receiver. 1045 The success response messages for the port and VC statistics group 1046 have the following format: 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Version | Message Type | Result | Code | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Transaction Identifier | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Port | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | zero | VPI | VCI | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | | 1060 + Input Cell Count + 1061 | | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | | 1064 + Input Frame Count + 1065 | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | | 1068 + Input Cell Discard Count + 1069 | | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | | 1072 + Input Frame Discard Count + 1073 | | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | | 1076 + Input HEC Error Count + 1077 | | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | | 1080 + Input Invalid VPI/VCI Count + 1081 | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | | 1084 + Output Cell Count + 1085 | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | | 1088 + Output Frame Count + 1089 | | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | | 1092 + Output Cell Discard Count + 1093 | | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | | 1096 + Output Frame Discard Count + 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Port 1101 VPI/VCI 1102 Fields are the same as those of the request message. 1104 Input Cell Count 1105 Output Cell Count 1106 Each gives the value of a free running 64 bit counter 1107 counting cells arriving at the input or departing from the 1108 output respectively. In response to a Port Statistics 1109 message the count will be on a per port basis and in 1110 response to a VC Statistics message the count will be on a 1111 per VC basis. 1113 Input Frame Count 1114 Output Frame Count 1115 Each gives the value of a free running 64 bit counter 1116 counting frames (packets) arriving at the input or 1117 departing from the output respectively. In response to a 1118 Port Statistics message the count will be on a per port 1119 basis and in response to a VC Statistics message the count 1120 will be on a per VC basis. 1122 Input Cell Discard Count 1123 Output Cell Discard Count 1124 Each gives the value of a free running 64 bit counter 1125 counting cells discarded due to queue overflow on an input 1126 port or on an output port respectively. In response to a 1127 Port Statistics message the count will be on a per port 1128 basis and in response to a VC Statistics message the count 1129 will be on a per VC basis. 1131 Input Frame Discard Count 1132 Output Frame Discard Count 1133 Each gives the value of a free running 64 bit counter 1134 counting frames discarded due to queue overflow on an input 1135 port or on an output port respectively. In response to a 1136 Port Statistics message the count will be on a per port 1137 basis and in response to a VC Statistics message the count 1138 will be on a per VC basis. 1140 HEC Error Count 1141 Gives the value of a free running 64 bit counter counting 1142 cells discarded due to header checksum errors on arrival at 1143 an input port. 1145 Invalid VPI/VCI Count 1146 Gives the value of a free running 64 bit counter counting 1147 cells discarded because their VPI/VCI is invalid on arrival 1148 at an input port. An incoming VPI/VCI is invalid if no 1149 connection is currently established having that value of 1150 VPI/VCI. 1152 5.2.1 Port Statistics Message 1154 The Port Statistics message requests the statistics for the switch 1155 port specified in the Port field. The contents of the VPI/VCI field 1156 in the Port Statistics request message are ignored. All of the count 1157 fields in the success response message refer to per-port counts 1158 regardless of the virtual channels to which the cells belong. Any of 1159 the count fields in the success response message not supported by the 1160 port will be set to zero. The Port Statistics message is: 1162 Message Type = 49 1164 5.2.2 VC Statistics Message 1166 The VC Statistics message requests the statistics for the virtual 1167 channel specified in the VPI/VCI field that arrives on the switch 1168 input port specified in the Port field. All of the count fields in 1169 the success response message refer only to the specified virtual 1170 channel. The HEC Error Count and Invalid VPI/VCI Count fields are not 1171 VC specific and are set to zero. Any of the other count fields not 1172 supported on a per virtual channel basis will be set to zero in the 1173 success response message. The VC Statistics message is: 1175 Message Type = 50 1177 6. Configuration 1179 The configuration messages permit the controller to discover the 1180 capabilities of the switch. Three configuration request messages have 1181 been defined: Switch, Port, and All Ports. 1183 All configuration request messages have the following format: 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Version | Message Type | Result | Code | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Transaction Identifier | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Port | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Port 1196 Identifies the port number for which configuration 1197 information is being requested. If the Port field is not 1198 required by the message it is set to zero by the sender and 1199 ignored by the receiver. 1201 6.1 Switch Configuration Message 1203 The Switch Configuration message requests the global (non port- 1204 specific) configuration for the switch. The Switch Configuration 1205 message is: 1207 Message Type = 64 1209 The Port field is not used in the request message and is set to zero. 1211 The Switch Configuration success response message has the following 1212 format: 1214 0 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Version | Message Type | Result | Code | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Transaction Identifier | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Firmware Version Number | Reserved | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Switch Type | | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1225 | Switch Name | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Firmware Version Number 1229 The version number of the switch control firmware 1230 installed. 1232 Reserved 1233 Field is not used. It is set to zero by the sender and 1234 ignored by the receiver. 1236 Switch Type 1237 A 16 bit field allocated by the manufacturer of the switch. 1238 (For these purposes the manufacturer of the switch is 1239 assumed to be the organization identified by the OUI in the 1240 Switch Name field.) The Switch Type identifies the product. 1241 When the Switch Type is combined with the OUI from the 1242 Switch Name the product is uniquely identified. Network 1243 Management may use this identification to obtain product 1244 related information from a database. 1246 Switch Name 1247 A 48 bit quantity that is unique within the operational 1248 context of the device. A 48 bit IEEE 802 MAC address, if 1249 available, may be used as the Switch Name. The most 1250 significant 24 bits of the Switch Name must be an 1251 Organizationally Unique Identifier (OUI) that identifies 1252 the manufacturer of the switch. 1254 6.2 Port Configuration Message 1256 The Port Configuration message requests the switch for the 1257 configuration information of a single switch port. The Port field in 1258 the request message specifies the port for which the configuration is 1259 requested. The Port Configuration message is: 1261 Message Type = 65. 1263 The Port Configuration success response message has the following 1264 format: 1266 0 1 2 3 1267 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 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Version | Message Type | Result | Code | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Transaction Identifier | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Port | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Port Session Number | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | zero | Min VPI | zero | Max VPI | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Min VCI | Max VCI | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Cell Rate | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Port Status | Port Type | Line Status | Priorities | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 Port 1287 The switch port to which the configuration information 1288 refers. Configuration information relating to both the 1289 input and the output sides of the switch port is given. 1290 Port numbers are 32 bits wide and allocated by the switch. 1291 The switch may choose to structure the 32 bits into sub 1292 fields that have meaning to the physical structure of the 1293 switch hardware (e.g. shelf, slot, interface). 1295 Port Session Number 1296 The current Port Session Number for the specified port. 1297 Each switch port maintains a Port Session Number assigned 1298 by the switch. The Port Session Number of a port remains 1299 unchanged while the port is continuously in the Available 1300 state. When a port returns to the Available state after it 1301 has been Unavailable, or after a power cycle, its Port 1302 Session Number must be changed, preferably using some form 1303 of random number. 1305 Min VPI 1306 The minimum value of dynamically assigned incoming VPI that 1307 the connection table on the input port can support and may 1308 be controlled by GSMP. 1310 Max VPI 1311 The maximum value of dynamically assigned incoming VPI that 1312 the connection table on the input port can support and may 1313 be controlled by GSMP. It is assumed that the input port 1314 can handle all values of VPI within the range Min VPI to 1315 Max VPI inclusive and that GSMP may control all values 1316 within this range. If the switch does not support virtual 1317 paths it is acceptable for both Min VPI and Max VPI to 1318 specify the same value, most likely zero. 1320 Min VCI 1321 The minimum value of dynamically assigned incoming VCI that 1322 the connection table on the input port can support and may 1323 be controlled by GSMP. 1325 Max VCI 1326 The maximum value of dynamically assigned incoming VCI that 1327 the connection table on the input port can support and may 1328 be controlled by GSMP. It is assumed that the input port 1329 can handle all values of VCI within the range Min VCI to 1330 Max VCI inclusive for each of the virtual paths in the 1331 range Min VPI to Max VPI inclusive and that GSMP may 1332 control all values within this range. 1334 Cell Rate 1335 A measure of the bandwidth of the port. It is the rate of 1336 cells arriving at or departing from the port in cells/s. It 1337 is assumed that both input port and output port have the 1338 same cell rate. 1340 Port Status 1341 Gives the administrative state of the port. The defined 1342 values of the Port Status field are: 1344 Available: 1345 Port Status = 1. The port is available to both send 1346 and receive cells. When a port changes to the 1347 Available state from any other administrative state, 1348 all dynamically assigned virtual connections must be 1349 cleared and a new Port Session Number must be 1350 generated. 1352 Unavailable: 1353 Port Status = 2. The port has intentionally been taken 1354 out of service. No cells will be transmitted from this 1355 port. No cells will be received by this port. 1357 Internal Loopback: 1358 Port Status = 3. The port has intentionally been taken 1359 out of service and is in internal loopback: cells 1360 arriving at the output port from the switch fabric are 1361 looped through to the input port to return to the 1362 switch fabric. All of the ATM functions of the input 1363 port above the PHY layer, e.g. header translation, are 1364 performed upon the looped back cells. 1366 External Loopback: 1367 Port Status = 4. The port has intentionally been taken 1368 out of service and is in external loopback: cells 1369 arriving at the input port from the external 1370 communications link are immediately looped back to the 1371 communications link at the physical layer without 1372 entering the input port. None of the ATM functions of 1373 the input port above the PHY layer are performed upon 1374 the looped back cells. 1376 Bothway Loopback: 1377 Port Status = 5. The port has intentionally been taken 1378 out of service and is in both internal and external 1379 loopback. 1381 Port Type 1382 The type of physical transmission interface for this port. 1383 The values for this field are given by the IANAifTYPE 1384 object from the MIB defined for the IANAifTYPE-MIB 1385 specified in RFC 1573 [rfc1573]. Example values are: SONET 1386 or SDH (39), DS-3 (30). 1388 Line Status 1389 The status of the physical transmission medium connected to 1390 the port. The defined values of the Line Status field are: 1392 Up: 1393 Line Status = 1. The line is able to both send and 1394 receive cells. When the Line Status changes to Up 1395 from either the Down or Test states, a new Port 1396 Session Number must be generated. 1398 Down: 1399 Line Status = 2. The line is unable either to send or 1400 receive cells or both. 1402 Test: 1403 Line Status = 3. The port or line is in a test mode, 1404 for example, power-on test. 1406 Priorities 1407 The number of different priorities that this output port 1408 can assign to virtual channel connections. Zero is invalid 1409 in this field. If an output port is able to support "Q" 1410 priorities, the highest priority is numbered zero and the 1411 lowest priority is numbered "Q-1". The ability to offer 1412 different qualities of service to different connections 1413 based upon their priority is assumed to be a property of 1414 the output port of the switch. It may be assumed that for 1415 virtual channel connections that share the same output 1416 port, an ATM cell on a connection with a higher priority is 1417 much more likely to exit the switch before an ATM cell on a 1418 connection with a lower priority if they are both in the 1419 switch at the same time. 1421 6.3 All Ports Configuration Message 1423 The All Ports Configuration message requests the switch for the 1424 configuration information of all of its ports. The All Ports 1425 Configuration message is: 1427 Message Type = 66 1429 The Port field is not used in the request message and is set to zero. 1431 The All Ports Configuration success response message has the 1432 following format: 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Version | Message Type | Result | Code | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Transaction Identifier | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Number of Records | Port Record Length | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | | 1444 ~ Port Records ~ 1445 | | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 Number of Records 1449 Field gives the number of Port Records to follow in the 1450 message. The maximum number of port records allowed in a 1451 single All Ports Configuration success response is 64. If a 1452 switch has more than 64 ports it must send them in multiple 1453 success response messages. 1455 Port Record Length 1456 Field gives the length of each port record in bytes. This 1457 is currently 24 but the Port Record Length field allows for 1458 the future definition of further fields at the end of the 1459 port record while preserving compatibility with earlier 1460 versions of the protocol. 1462 Port Records follow in the remainder of the message. Each port record 1463 has the following format: 1465 0 1 2 3 1466 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 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Port | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Port Session Number | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | zero | Min VPI | zero | Max VPI | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Min VCI | Max VCI | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Cell Rate | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Port Status | Port Type | Line Status | Priorities | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 The definition of the fields in the port record is exactly the same 1482 as that of the Port Configuration message. 1484 7. Event Messages 1486 Event messages allow the switch to inform the controller of certain 1487 asynchronous events. Event messages are not acknowledged. The Result 1488 field and the Code field in the message header are not used and 1489 should be set to zero. Event messages are not sent during 1490 initialization. Event messages have the following format: 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Version | Message Type | Result | Code | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Transaction Identifier | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Port | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Port Session Number | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Event Sequence Number | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | zero | VPI | VCI | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Port 1509 Field gives the switch port to which the event message 1510 refers. 1512 Port Session Number 1513 The current Port Session Number for the specified port. 1515 Event Sequence Number 1516 The current value of the Event Sequence Number for the 1517 specified port. The Event Sequence Number is set to zero 1518 when the port is initialized and is incremented by one each 1519 time an asynchronous event is detected on that port that 1520 the switch would normally report via an Event message. The 1521 Event Sequence Number must be incremented each time an 1522 event occurs even if the switch is prevented from sending 1523 an Event message due to the action of the flow control. 1525 VPI/VCI 1526 Field gives the VPI/VCI to which the event message refers. 1527 If this field is not required by the event message it is 1528 set to zero. 1530 Each switch port must maintain an Event Sequence Number and a set of 1531 Event Flags, one Event Flag for each type of Event message. When a 1532 switch port sends an Event message it must set the Event Flag on that 1533 port corresponding to the type of the event. The port is not 1534 permitted to send another Event message of the same type until the 1535 Event Flag has been reset. Event Flags are reset by the "Reset Event 1536 Flags" function of the Port Management message. This is a simple flow 1537 control preventing the switch from flooding the controller with event 1538 messages. The Event Sequence Number of the port must be incremented 1539 every time an event is detected on that port even if the port is 1540 prevented from reporting the event due to the action of the flow 1541 control. This allows the controller to detect that it has not been 1542 informed of some events that have occurred on the port due to the 1543 action of the flow control. 1545 7.1 Port Up Message 1547 The Port Up message informs the controller that the Line Status of a 1548 port has changed from either the Down or Test state to the Up state. 1549 When the Line Status of a switch port changes to the Up state from 1550 either the Down or Test state a new Port Session Number must be 1551 generated, preferably using some form of random number. The new Port 1552 Session Number is given in the Port Session Number field. The VPI/VCI 1553 field is not used and is set to zero. The Port Up message is: 1555 Message Type = 80 1557 7.2 Port Down Message 1559 The Port Down message informs the controller that the Line Status of 1560 a port has changed from the Up state to the Down state. This message 1561 will be sent to report link failure if the switch is capable of 1562 detecting link failure. The port session number that was valid before 1563 the port went down is reported in the Port Session Number field. The 1564 VPI/VCI field is not used and is set to zero. The Port Down message 1565 is: 1567 Message Type = 81 1569 7.3 Invalid VPI/VCI Message 1571 The Invalid VPI/VCI message is sent to inform the controller that one 1572 or more cells have arrived at an input port with a VPI/ VCI that is 1573 currently not allocated to an assigned connection. The input port is 1574 indicated in the Port field, and the VPI/VCI in the VPI/VCI field. 1575 The Invalid VPI/VCI message is: 1577 Message Type = 82 1579 7.4 New Port Message 1581 The New Port message informs the controller that a new port has been 1582 added to the switch. The port number of the new port is given in the 1583 Port field. A new Port Session Number must be assigned, preferably 1584 using some form of random number. The new Port Session Number is 1585 given in the Port Session Number field. The state of the new port is 1586 undefined so the VPI/VCI field is not used and is set to zero. The 1587 New Port message is: 1589 Message Type = 83 1591 7.5 Dead Port Message 1593 The Dead Port message informs the controller that a port has been 1594 removed from the switch. The port number of the port is given in the 1595 Port field. The Port Session Number that was valid before the port 1596 was removed is reported in the Port Session Number field. The 1597 VPI/VCI fields are not used and are set to zero. The Dead Port 1598 message is: 1600 Message Type = 84 1602 8. Adjacency Protocol 1604 The adjacency protocol is used to synchronize state across the link, 1605 to discover the identity of the entity at the other end of a link, 1606 and to detect when it changes. No GSMP messages other than those of 1607 the adjacency protocol may be sent across the link until the 1608 adjacency protocol has achieved synchronization. 1610 8.1 Packet Format 1612 The adjacency protocol is: 1614 Message Type = 10 1616 All GSMP messages belonging to the adjacency protocol have the 1617 following structure: 1619 0 1 2 3 1620 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 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | Version | Message Type | Result | Code | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Sender Name | 1625 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | | | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1628 | Receiver Name | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Sender Port | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Receiver Port | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Sender Instance | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Receiver Instance | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 Version 1640 The GSMP protocol version number, currently Version = 1. It 1641 should be set by the sender of the message to the GSMP 1642 protocol version that the sender is currently running. 1644 Result 1645 Field is not used in the adjacency protocol. It should be 1646 set to zero by the sender and ignored by the receiver. 1648 Code 1649 Field specifies the function of the message. Four Codes are 1650 defined for the adjacency protocol: 1652 SYN: Code = 1 1653 SYNACK: Code = 2 1654 ACK: Code = 3 1655 RSTACK: Code = 4. 1657 Sender Name 1658 For the SYN, SYNACK, and ACK messages, is the name of the 1659 entity sending the message. The Sender Name is a 48 bit 1660 quantity that is unique within the operational context of 1661 the device. A 48 bit IEEE 802 MAC address, if available, 1662 may be used for the Sender Name. For the RSTACK message, 1663 the Sender Name field is set to the value of the Receiver 1664 Name field from the incoming message that caused the RSTACK 1665 message to be generated. 1667 Receiver Name 1668 For the SYN, SYNACK, and ACK messages, is the name of the 1669 entity that the sender of the message believes is at the 1670 far end of the link. If the sender of the message does not 1671 know the name of the entity at the far end of the link, 1672 this field should be set to zero. For the RSTACK message, 1673 the Receiver Name field is set to the value of the Sender 1674 Name field from the incoming message that caused the RSTACK 1675 message to be generated. 1677 Sender Port 1678 For the SYN, SYNACK, and ACK messages, is the local port 1679 number of the link across which the message is being sent. 1680 Port numbers are locally assigned 32 bit values. For the 1681 RSTACK message, the Sender Port field is set to the value 1682 of the Receiver Port field from the incoming message that 1683 caused the RSTACK message to be generated. 1685 Receiver Port 1686 For the SYN, SYNACK, and ACK messages, is what the sender 1687 believes is the local port number for the link, allocated 1688 by the entity at the far end of the link. If the sender of 1689 the message does not know the port number at the far end of 1690 the link, this field should be set to zero. For the RSTACK 1691 message, the Receiver Port field is set to the value of the 1692 Sender Port field from the incoming message that caused the 1693 RSTACK message to be generated. 1695 Sender Instance 1696 For the SYN, SYNACK, and ACK messages, is the sender's 1697 instance number for the link. It is used to detect when the 1698 link comes back up after going down or when the identity of 1699 the entity at the other end of the link changes. The 1700 instance number is a 32 bit number that is guaranteed to be 1701 unique within the recent past and to change when the link 1702 or node comes back up after going down. Zero is not a valid 1703 instance number. For the RSTACK message, the Sender 1704 Instance field is set to the value of the Receiver Instance 1705 field from the incoming message that caused the RSTACK 1706 message to be generated. 1708 Receiver Instance 1709 For the SYN, SYNACK, and ACK messages, is what the sender 1710 believes is the current instance number for the link, 1711 allocated by the entity at the far end of the link. If the 1712 sender of the message does not know the current instance 1713 number at the far end of the link, this field should be set 1714 to zero. For the RSTACK message, the Receiver Instance 1715 field is set to the value of the Sender Instance field from 1716 the incoming message that caused the RSTACK message to be 1717 generated. 1719 8.2 Procedure 1721 The adjacency protocol is described by the rules and state tables 1722 given in this section. 1724 The rules and state tables use the following operations: 1726 o The "Update Peer Verifier" operation is defined as storing the 1727 values of the Sender Instance, Sender Port, and Sender Name fields 1728 from a SYN or SYNACK message received from the entity at the far 1729 end of the link. 1731 o The procedure "Reset the link" is defined as: 1733 1. Generate a new instance number for the link 1734 2. Delete the peer verifier (set to zero the values of Sender 1735 Instance, Sender Port, and Sender Name previously stored by 1736 the Update Peer Verifier operation) 1737 3. Send a SYN message 1738 4. Enter the SYNSENT state 1740 o The state tables use the following Boolean terms and operators: 1742 A The Sender Instance in the incoming message matches the 1743 value stored from a previous message by the "Update Peer 1744 Verifier" operation. 1746 B The Sender Instance, Sender Port, and Sender Name fields in 1747 the incoming message match the values stored from a 1748 previous message by the "Update Peer Verifier" operation. 1750 C The Receiver Instance, Receiver Port, and Receiver Name 1751 fields in the incoming message match the values of the 1752 Sender Instance, Sender Port, and Sender Name currently 1753 sent in outgoing SYN, SYNACK, and ACK messages. 1755 "&&" Represents the logical AND operation 1757 "||" Represents the logical OR operation 1759 "!" Represents the logical negation (NOT) operation. 1761 o A timer is required for the periodic generation of SYN, SYNACK, 1762 and ACK messages. The period of the timer is unspecified but a 1763 value of one second is suggested. 1765 There are two independent events: the timer expires, and a packet 1766 arrives. The processing rules for these events are: 1768 Timer Expires: Reset Timer 1769 If state = SYNSENT Send SYN 1770 If state = SYNRCVD Send SYNACK 1771 If state = ESTAB Send ACK 1773 Packet Arrives: If incoming message is an RSTACK 1774 If A && C && !SYNSENT 1775 Reset the link 1776 Else Discard the message 1777 Else the following State Tables. 1779 o State synchronization across a link is considered to be achieved 1780 when the protocol reaches the ESTAB state. 1782 State Tables 1784 State: SYNSENT 1786 +======================================================================+ 1787 | Condition | Action | New State | 1788 +====================+=====================================+===========+ 1789 | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | 1790 +--------------------+-------------------------------------+-----------+ 1791 | SYNACK && !C | Send RSTACK | SYNSENT | 1792 +--------------------+-------------------------------------+-----------+ 1793 | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | 1794 +--------------------+-------------------------------------+-----------+ 1795 | ACK | Send RSTACK | SYNSENT | 1796 +======================================================================+ 1797 State: SYNRCVD 1799 +======================================================================+ 1800 | Condition | Action | New State | 1801 +====================+=====================================+===========+ 1802 | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | 1803 +--------------------+-------------------------------------+-----------+ 1804 | SYNACK && !C | Send RSTACK | SYNRCVD | 1805 +--------------------+-------------------------------------+-----------+ 1806 | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | 1807 +--------------------+-------------------------------------+-----------+ 1808 | ACK && B && C | Send ACK | ESTAB | 1809 +--------------------+-------------------------------------+-----------+ 1810 | ACK && !(B && C) | Send RSTACK | SYNRCVD | 1811 +======================================================================+ 1813 State: ESTAB 1815 +======================================================================+ 1816 | Condition | Action | New State | 1817 +====================+=====================================+===========+ 1818 | SYN || SYNACK | Send ACK (note 1) | ESTAB | 1819 +--------------------+-------------------------------------+-----------+ 1820 | ACK && B && C | Send ACK (note 1) | ESTAB | 1821 +--------------------+-------------------------------------+-----------+ 1822 | ACK && !(B && C) | Send RSTACK | ESTAB | 1823 +======================================================================+ 1825 Note 1: No more than one ACK should be sent within any time period of 1826 length defined by the timer. 1828 9. Failure Response Messages 1830 A failure response message is formed by returning the request message 1831 that caused the failure with the Result field in the header 1832 indicating failure (Result = 4) and the Code field giving the failure 1833 code. The failure code specifies the reason for the switch being 1834 unable to satisfy the request message. A failure code of 16 is used 1835 for a failure that is specific to the particular request message and 1836 its meaning is defined within the text describing that message. The 1837 following failure codes are defined: 1839 1: Unspecified reason not covered by other failure codes. 1840 2: Invalid request message. 1841 3: The specified request is not implemented on this switch. 1842 4: Invalid port session number. 1844 5: One or more of the specified ports does not exist. 1845 6: One or more of the specified ports is down. 1846 7: One or more of the specified VPIs or VCIs is out of range on 1847 one or more of the requested ports. 1848 8: The specified connection does not exist. 1849 9: The specified branch does not exist. 1850 10: A branch belonging to the specified multicast connection is 1851 already established on the specified output port and the 1852 switch cannot support more than a single branch of any 1853 multicast connection on the same output port. 1854 11: The limit on the maximum number of multicast connections that 1855 the switch can support has been reached. 1856 12: The limit on the maximum number of branches that the 1857 specified multicast connection can support has been reached. 1858 13: Unable to assign the requested VPI/VCI value to the requested 1859 branch on the specified multicast connection. 1860 14: General problem related to the manner in which multicast is 1861 supported by the switch. 1862 15: Out of resources (e.g. memory exhausted, etc.). 1863 16: Failure specific to the particular message type. 1865 REFERENCES 1867 [I.361] "B-ISDN ATM Layer Specification," International 1868 Telecommunication Union, ITU-T Recommendation I.361, Mar. 1869 1993. 1871 [I.363] "B-ISDN ATM Adaptation Layer (AAL) Specification," 1872 International Telecommunication Union, ITU-T Recommendation 1873 I.363, Mar. 1993. 1875 [rfc1700] "Assigned Numbers," RFC 1700, October 1994. 1877 [rfc1573] "Evolution of the Interfaces Group of MIB-II," RFC 1573, 1878 January 1994. 1880 SECURITY CONSIDERATIONS 1882 Security issues are not discussed in this document. 1884 AUTHORS' ADDRESSES 1886 Peter Newman Phone: +1 (415) 846-4603 1887 Ipsilon Networks, Inc. Email: pn@ipsilon.com 1889 W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334 1890 Sprint Email: texas@sprintcorp.com 1892 Robert M. Hinden Phone: +1 (415) 846-4604 1893 Ipsilon Networks, Inc. Email: hinden@ipsilon.com 1895 Eric Hoffman Phone: +1 (415) 846-4610 1896 Ipsilon Networks, Inc. Email: hoffman@ipsilon.com 1898 Fong Ching Liaw Phone: +1 (415) 846-4607 1899 Ipsilon Networks, Inc. Email: fong@ipsilon.com 1901 Tom Lyon Phone: +1 (415) 846-4601 1902 Ipsilon Networks, Inc. Email: pugs@ipsilon.com 1904 Greg Minshall Phone: +1 (415) 846-4605 1905 Ipsilon Networks, Inc. Email: minshall@ipsilon.com 1907 Ipsilon Networks, Inc. is located at: 1909 2191 East Bayshore Road 1910 Suite 100 1911 Palo Alto, CA 94303 1912 USA 1914 Sprint is located at: 1916 Sprint 1917 Sprint Technology Services - Long Distance Division 1918 9300 Metcalf Avenue 1919 Mailstop KSOPKB0802 1920 Overland Park, KS 66212-6333 1921 USA