diff options
Diffstat (limited to 'doc/rfc/rfc3292.txt')
| -rw-r--r-- | doc/rfc/rfc3292.txt | 7675 |
1 files changed, 7675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3292.txt b/doc/rfc/rfc3292.txt new file mode 100644 index 0000000..1d51895 --- /dev/null +++ b/doc/rfc/rfc3292.txt @@ -0,0 +1,7675 @@ + + + + + + +Network Working Group A. Doria +Request for Comments: 3292 Lulea University of Technology +Category: Standards Track F. Hellstrand + K. Sundell + Nortel Networks + T. Worster + June 2002 + + + General Switch Management Protocol (GSMP) V3 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes the General Switch Management Protocol + Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows + one or more external switch controllers to establish and maintain the + state of a label switch such as, an ATM, frame relay or MPLS switch. + The GSMPv3 allows control of both unicast and multicast switch + connection state as well as control of switch system resources and + QoS features. + +Acknowledgement + + GSMP was created by P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. + Ching Liaw, T. Lyon, and G. Minshall (see [6] and [7]). This version + of GSMP is based on their work. + +Contributors + + In addition to the authors/editors listed in the heading, many + members of the GSMP group have made significant contributions to this + specification. Among the contributors who have contributed + materially are: Constantin Adam, Clint Bishard, Joachim Buerkle, + Torbjorn Hedqvist, Georg Kullgren, Aurel A. Lazar, Mahesan + Nandikesan, Matt Peters, Hans Sjostrand, Balaji Srinivasan, Jaroslaw + Sydir, Chao-Chun Wang. + + + +Doria, et. al. Standards Track [Page 1] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +Table of Contents + + 1. Introduction ................................................... 4 + 2. GSMP Packet Encapsulation ...................................... 6 + 3. Common Definitions and Procedures .............................. 6 + 3.1 GSMP Packet Format ........................................... 7 + 3.1.1 Basic GSMP Message format ................................ 7 + 3.1.2 Fields commonly found in GSMP messages .................. 11 + 3.1.3 Labels .................................................. 12 + 3.1.4 Failure Response Messages ............................... 17 + 4. Connection Management Messages ................................ 18 + 4.1 General Message Definitions ................................. 18 + 4.2 Add Branch Message .......................................... 25 + 4.2.1 ATM specific procedures: ................................ 29 + 4.3 Delete Tree Message ......................................... 30 + 4.4 Verify Tree Message ......................................... 30 + 4.5 Delete All Input Port Message ............................... 30 + 4.6 Delete All Output Port Message .............................. 31 + 4.7 Delete Branches Message ..................................... 32 + 4.8 Move Output Branch Message .................................. 35 + 4.8.1 ATM Specific Procedures: ................................ 37 + 4.9 Move Input Branch Message ................................... 38 + 4.9.1 ATM Specific Procedures: ................................ 41 + 5. Reservation Management Messages ............................... 42 + 5.1 Reservation Request Message ................................. 43 + 5.2 Delete Reservation Message .................................. 46 + 5.3 Delete All Reservations Message.............................. 47 + 6. Management Messages ........................................... 47 + 6.1 Port Management Message ..................................... 47 + 6.2 Label Range Message ......................................... 53 + 6.2.1 Labels .................................................. 56 + 7. State and Statistics Messages ................................. 60 + 7.1 Connection Activity Message ................................. 61 + 7.2 Statistics Messages ......................................... 64 + 7.2.1 Port Statistics Message ................................. 67 + 7.2.2 Connection Statistics Message ........................... 67 + 7.2.3 QoS Class Statistics Message ............................ 68 + 7.3 Report Connection State Message ............................. 68 + 8. Configuration Messages ........................................ 73 + 8.1 Switch Configuration Message ................................ 73 + 8.1.1 Configuration Message Processing ........................ 75 + 8.2 Port Configuration Message .................................. 75 + + + +Doria, et. al. Standards Track [Page 2] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 8.2.1 PortType Specific Data .................................. 79 + 8.3 All Ports Configuration Message ............................. 87 + 8.4 Service Configuration Message ............................... 89 + 9. Event Messages ................................................ 93 + 9.1 Port Up Message ............................................ 95 + 9.2 Port Down Message .......................................... 95 + 9.3 Invalid Label Message ...................................... 95 + 9.4 New Port Message ........................................... 96 + 9.5 Dead Port Message .......................................... 96 + 9.6 Adjacency Update Message ................................... 96 + 10. Service Model Definition .................................... 96 + 10.1 Overview .................................................. 96 + 10.2 Service Model Definitions ................................. 97 + 10.2.1 Original Specifications ............................... 97 + 10.2.2 Service Definitions ................................... 98 + 10.2.3 Capability Sets ....................................... 99 + 10.3 Service Model Procedures .................................. 99 + 10.4 Service Definitions ....................................... 100 + 10.4.1 ATM Forum Service Categories .......................... 101 + 10.4.2 Integrated Services ................................... 104 + 10.4.3 MPLS CR-LDP ........................................... 105 + 10.4.4 Frame Relay ........................................... 105 + 10.4.5 DiffServ .............................................. 106 + 10.5 Format and Encoding of the Traffic Parameters ............. 106 + 10.5.1 Traffic Parameters for ATM Forum Services ............. 106 + 10.5.2 Traffic Parameters for Int-Serv Controlled Load Service 107 + 10.5.3 Traffic Parameters for CRLDP Service .................. 108 + 10.5.4 Traffic Parameters for Frame Relay Service ............ 109 + 10.6 Traffic Controls (TC) Flags ............................... 110 + 11. Adjacency Protocol .......................................... 111 + 11.1 Packet Format ............................................. 112 + 11.2 Procedure ................................................. 115 + 11.2.1 State Tables .......................................... 117 + 11.3 Partition Information State ............................... 118 + 11.4 Loss of Synchronisation.................................... 119 + 11.5 Multiple Controllers Per Switch Partition ................. 119 + 11.5.1 Multiple Controller Adjacency Process ................. 120 + 12. Failure Response Codes ...................................... 121 + 12.1 Description of Failure and Warning Response Messages ...... 121 + 12.2 Summary of Failure Response Codes and Warnings ............ 127 + 13. Security Considerations ..................................... 128 + Appendix A Summary of Messages ................................. 129 + Appendix B IANA Considerations ................................. 130 + References ...................................................... 134 + Authors' Addresses .............................................. 136 + Full Copyright Statement ........................................ 137 + + + + + +Doria, et. al. Standards Track [Page 3] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +1. Introduction + + The General Switch Management Protocol (GSMP) is a general purpose + protocol to control a label switch. GSMP allows a controller to + establish and release connections across the switch, add and delete + leaves on a multicast connection, manage switch ports, request + configuration information, request and delete reservation of switch + resources, and request statistics. It also allows the switch to + inform the controller of asynchronous events such as a link going + down. 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. Also a switch may be + controlled by more than one controller by using the technique of + partitioning. + + A "physical" switch can be partitioned into several virtual switches + that are referred to as partitions. In this version of GSMP, switch + partitioning is static and occurs prior to running GSMP. The + partitions of a physical switch are isolated from each other by the + implementation and the controller assumes that the resources + allocated to a partition are at all times available to that + partition. A partition appears to its controller as a label switch. + Throughout the rest of this document, the term switch (or + equivalently, label switch) is used to refer to either a physical, + non-partitioned switch or to a partition. The resources allocated to + a partition appear to the controller as if they were the actual + physical resources of the partition. For example if the bandwidth of + a port were divided among several partitions, each partition would + appear to the controller to have its own independent port. + + GSMP controls a partitioned switch through the use of a partition + identifier that is carried in every GSMP message. Each partition has + a one-to-one control relationship with its own logical controller + entity (which in the remainder of the document is referred to simply + as a controller) and GSMP independently maintains adjacency between + each controller-partition pair. + + Kinds of label switches include frame or cell switches that support + connection oriented switching, using the exact match-forwarding + algorithm based on labels attached to incoming cells or frames. 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. Cells or labelled + frames arrive at the switch from an external communication link on + + + + + +Doria, et. al. Standards Track [Page 4] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + incoming labelled channels at an input port. Cells or labelled + frames depart from the switch to an external communication link on + labelled channels from an output port. + + A switch may support multiple label types, however, each switch port + can support only one label type. The label type supported by a given + port is indicated by the switch to the controller in a port + configuration message. Connections may be established between ports, + supporting different label types. Label types include ATM, Frame + Relay, MPLS Generic and FEC Labels. + + A connection across a switch is formed by connecting an incoming + labelled channel to one or more outgoing labelled channels. + Connections are referenced by the input port on which they originate + and the Label values of their incoming labelled channel. + + GSMP supports point-to-point and point-to-multipoint connections. A + multipoint-to-point connection is specified by establishing multiple + point-to-point connections, each of them specifying the same output + branch. A multipoint-to-multipoint connection is specified by + establishing multiple point-to-multipoint trees each of them + specifying the same output branches. + + In general a connection is established with a certain quality of + service (QoS). This version of GSMP includes a default QoS + Configuration and additionally allows the negotiation of alternative, + optional QoS configurations. The default QoS Configuration includes + three QoS Models: a Service Model, a Simple Abstract Model (strict + priorities) and a QoS Profile Model. + + The Service Model is based on service definitions found external to + GSMP such as in Integrated Services or ATM Service Categories. Each + connection is assigned a specific service that defines the handling + of the connection by the switch. Additionally, traffic parameters + and traffic controls may be assigned to the connection depending on + the assigned service. + + In the Simple Abstract Model, a connection is assigned a priority + when it is established. It may be assumed that for connections that + share the same output port, a cell or frame on a connection with a + higher priority is much more likely to exit the switch before a cell + or frame 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. + + + + + + +Doria, et. al. Standards Track [Page 5] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The QoS Profile Model provides a simple mechanism that allows + connection to be assigned QoS semantics defined externally to GSMP. + The QoS Profile Model can be used to indicate pre-defined + Differentiated Service Per Hop Behaviours (PHBs). Definition of QoS + profiles is outside of the scope of this specification. + + All GSMP switches MUST support the default QoS Configuration. A GSMP + switch may additionally support one or more alternative QoS + Configurations. The QoS models of alternative QoS configurations are + defined outside the GSMP specification. GSMP includes a negotiation + mechanism that allows a controller to select from the QoS + configurations that a switch supports. + + GSMP contains an adjacency protocol. The adjacency protocol is used + to synchronise states across the link, to negotiate which version of + the GSMP protocol to use, to discover the identity of the entity at + the other end of a link, and to detect when it changes. + +2. GSMP Packet Encapsulation + + GSMP packets may be transported via any suitable medium. GSMP packet + encapsulations for ATM, Ethernet and TCP are specified in [15]. + Additional encapsulations for GSMP packets may be defined in separate + documents. + +3. Common Definitions and Procedures + + 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 six classes of GSMP + request-response message: Connection Management, Reservation + Management, Port Management, State and Statistics, Configuration, and + Quality of Service. The switch may also generate asynchronous Event + messages to inform the controller of asynchronous events. The + controller can be required to acknowledge event messages, but by + default does not do so. There is also an adjacency protocol message + used to establish synchronisation 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. + + + + +Doria, et. al. Standards Track [Page 6] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 opaque sub-fields that have meaning to the physical + structure of the switch (e.g., slot, port). In general, a port in + the same physical location on the switch will always have the same + port number, even across power cycles. The internal structure of the + port number is opaque to the GSMP protocol. However, for the + purposes of network management such as logging, port naming, and + graphical representation, a switch may declare the physical location + (physical slot and port) of each port. Alternatively, this + information may be obtained by looking up the product identity in a + database. + + Each switch port also maintains a port session number assigned by the + switch. A message, with an incorrect port session number MUST be + rejected. This allows the controller to detect a link failure and to + keep states synchronised. + + Except for the adjacency protocol message, no GSMP messages may be + sent across the link until the adjacency protocol has achieved + synchronisation, and all GSMP messages received on a link that do not + currently have state synchronisation MUST be discarded. + +3.1 GSMP Packet Format + +3.1.1 Basic GSMP Message format + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Message Body ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Doria, et. al. Standards Track [Page 7] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + (The convention in the documentation of Internet Protocols [5] is to + express numbers in decimal. Numbers in hexadecimal format are + specified by prefacing them with the characters "0x". Numbers in + binary format are specified by prefacing them with the characters + "0b". Data is pictured in "big-endian" order. That is, fields are + described left to right, with the most significant byte on the left + and the least significant byte on the right. Whenever a diagram + shows a group of bytes, the order of transmission of those bytes is + the normal order in which they are read in English. Whenever a byte + represents a numeric quantity, the left most bit in the diagram is + the high order or most significant bit. That is, the bit labelled 0 + is the most significant bit. Similarly, whenever a multi-byte field + represents a numeric quantity, the left most bit of the whole field + is the most significant bit. When a multi-byte quantity is + transmitted, the most significant byte is transmitted first. This is + the same coding convention as is used in the ATM layer [1] and AAL-5 + [2][3].) + + Version + The version number of the GSMP protocol being used in this + session. It SHOULD be set by the sender of the message to the + GSMP protocol version negotiated by the adjacency protocol. + + Message Type + The GSMP message type. GSMP messages fall into the following + classes: Connection Management, Reservation Management, Port + Management, State and Statistics, Configuration, Quality of + Service, Events and messages belonging to an Abstract or + Resource Model (ARM) extension. Each class 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, a Port + Management request message, or a Quality of Service request + message that 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 MUST be + generated if the request fails. For State and Statistics, and + Configuration request messages, a value of "NoSuccessAck" in + the request message is ignored and the request message is + handled as if the field was set to "AckAll". (This facility + was added to reduce the control traffic in the case where the + + + + + +Doria, et. al. Standards Track [Page 8] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + controller periodically checks that the state in the switch is + correct. If the controller does not use this capability, all + request messages SHOULD be sent with a value of "AckAll".) + + In a response message, the result field can have three values: + "Success," "More," and "Failure". The "Success" and "More" + results both indicate a success response. All messages that + belong to the same success response will have the same + Transaction Identifier. The "Success" result indicates a + success response that may be contained in a single message or + the final message of a success response spanning multiple + messages. + + "More" in the result indicates that the message, either request + or response, exceeds the maximum transmission unit of the data + link and that one or more further messages will be sent to + complete the success response. + + ReturnReceipt is a result field used in Events to indicate that + an acknowledgement is required for the message. The default + for Events Messages is that the controller will not acknowledge + Events. In the case where a switch requires acknowledgement, + it will set the Result Field to ReturnReceipt in the header of + the Event Message. + + The encoding of the result field is: + + NoSuccessAck: Result = 1 + AckAll: Result = 2 + Success: Result = 3 + Failure: Result = 4 + More: Result = 5 + ReturnReceipt Result = 6 + + The Result field is not used in an adjacency protocol message. + + 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. + + + + + + + +Doria, et. al. Standards Track [Page 9] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Partition ID + Field used to associate the command with a specific switch + partition. The format of the Partition ID is not defined in + GSMP. If desired, the Partition ID can be divided into + multiple sub-identifiers within a single partition. For + example: the Partition ID could be subdivided into a 6-bit + partition number and a 2-bit sub-identifier which would allow a + switch to support 64 partitions with 4 available IDs per + partition. + + 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. The Transaction + Identifier is not used, and the field is not present, in the + adjacency protocol. + + I flag + If I is set then the SubMessage Number field indicates the + total number of SubMessage segments that compose the entire + message. If it is not set then the SubMessage Number field + indicates the sequence number of this SubMessage segment within + the whole message. + + SubMessage Number + When a message is segmented because it exceeds the MTU of the + link layer, each segment will include a submessage number to + indicate its position. Alternatively, if it is the first + submessage in a sequence of submessages, the I flag will be set + and this field will contain the total count of submessage + segments. + + Length + Length of the GSMP message including its header fields and + defined GSMP message body. The length of additional data + appended to the end of the standard message SHOULD be included + in the Length field. + + + + + + + + + + + +Doria, et. al. Standards Track [Page 10] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +3.1.2 Fields commonly found in GSMP messages + + The following fields are frequently found in GSMP messages. They are + defined here to avoid repetition. + + Port + Gives the port number of the switch port to which the message + applies. + + Port Session Number + 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. + + If the Port Session Number in a request message does not match + the current Port Session Number for the specified port, a + failure response message MUST be returned with the Code field + indicating, "5: Invalid port session number". The current port + session number for a port may be obtained using a Port + Configuration or an All Ports Configuration message. + +3.1.2.1 Additional General Message Information + + 1. Any field in a GSMP message that is unused or defined as + "reserved" MUST be set to zero by the sender and ignored by the + receiver. + + 2. Flags that are undefined will be designated as: x: reserved + + 3. It is not an error for a GSMP message to contain additional data + after the end of the Message Body. This is allowed to support + proprietary and experimental purposes. However, the maximum + transmission unit of the GSMP message, as defined by the data link + layer encapsulation, MUST NOT be exceeded. The length of + additional data appended to the end of the standard message SHOULD + be included in the message length field. + + 4. A success response message MUST NOT be sent until the requested + operation has been successfully completed. + + + + + +Doria, et. al. Standards Track [Page 11] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +3.1.3 Labels + + All labels in GSMP have a common structure composed of tuples, + consisting of a Type, a Length, and a Value. Such tuples are + commonly known as TLV's, and are a good way of encoding information + in a flexible and extensible format. A label TLV is encoded as a 2 + octet field that uses 12 bits to specify a Type and four bits to + specify certain behaviour specified below, followed by a 2 octet + Length field, followed by a variable length Value field. + Additionally, a label field can be composed of many stacked labels + that together constitute the label. + + A summary of TLV labels supported in this version of the protocol is + listed below: + + TLV Label Type Section Title + --------- ---- ------------- + ATM Label 0x100 ATM TLV Labels + FR Label 0x101 Frame Relay TLV Labels + MPLS Gen Label 0x102 MPLS Generic TLV Labels + FEC Label 0x103 FEC TLV Labels + + All Labels will be designated as follow: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| Label Type | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Label Value ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + x: Reserved Flags. + These are generally used by specific messages and will be + defined in those messages. + + S: Stacked Label Indicator + Label Stacking is discussed below in section 3.1.3.5 + + Label Type + A 12-bit field indicating the type of label. + + Label Length + A 16-bit field indicating the length of the Label Value field + in bytes. + + + + +Doria, et. al. Standards Track [Page 12] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Label Value + A variable length field that is an integer number of 32 bit + words long. The Label Value field is interpreted according to + the Label Type as described in the following sections. + +3.1.3.1 ATM Labels + + If the Label Type = ATM Label, the labels MUST be interpreted as an + ATM labels as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| ATM Label (0x100) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x| VPI | VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + For a virtual path connection (switched as a single virtual path + connection) or a virtual path (switched as one or more virtual + channel connections within the virtual path) the VCI field is not + used. + + ATM distinguishes between virtual path connections and virtual + channel connections. The connection management messages apply both + to virtual channel connections and virtual path connections. The Add + Branch and Move Branch connection management messages have two + Message Types. One Message Type indicates that a virtual channel + connection is required, and the other Message Type indicates that a + virtual path connection is required. The Delete Branches, Delete + Tree, and Delete All connection management messages have only a + single Message Type because they do not need to distinguish between + virtual channel connections and virtual path connections. For + virtual path connections, neither Input VCI fields nor Output VCI + fields are required. They SHOULD be set to zero by the sender and + ignored by the receiver. Virtual channel branches may not be added + to an existing virtual path connection. Conversely, virtual path + branches may not be added to an existing virtual channel connection. + In the Port Configuration message each switch input port may declare + whether it is capable of supporting virtual path switching (i.e., + accepting connection management messages requesting virtual path + connections). + + + + + + + + + +Doria, et. al. Standards Track [Page 13] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +3.1.3.2 Frame Relay Labels + + If the TLV Type = FR Label, the labels MUST be interpreted as a Frame + Relay labels as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| FR Label (0x101) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x| Res |Len| DLCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Res + The Res field is reserved in [21], i.e., it is not explicitly + reserved by GSMP. + + Len + The Len field specifies the number of bits of the DLCI. The + following values are supported: + + Len DLCI bits + 0 10 + 2 23 + + DLCI + DLCI is the binary value of the Frame Relay Label. The + significant number of bits (10 or 23) of the label value is to + be encoded into the Data Link Connection Identifier (DLCI) + field when part of the Frame Relay data link header [13]. + +3.1.3.3 MPLS Generic Labels + + If a port's attribute PortType=MPLS, then that port's labels are for + use on links for which label values are independent of the underlying + link technology. Examples of such links are PPP and Ethernet. On + such links the labels are carried in MPLS label stacks [14]. If the + Label Type = MPLS Generic Label, the labels MUST be interpreted as + Generic MPLS labels as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| MPLS Gen Label (0x102)| Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x| MPLS Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Doria, et. al. Standards Track [Page 14] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + MPLS Label + This is a 20-bit label value as specified in [14], represented + as a 20-bit number in a 4-byte field. + +3.1.3.4 FEC Labels + + Labels may be bound to Forwarding Equivalence Classes (FECs) as + defined in [18]. A FEC is a list of one or more FEC elements. The + FEC TLV encodes FEC items. In this version of the protocol only, + Prefix FECs are supported. If the Label Type = FEC Label, the labels + MUST be interpreted as Forwarding Equivalence Class Labels as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| FEC Label (0x103) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ FEC Element 1 ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ FEC Element n ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + FEC Element + The FEC element encoding depends on the type of FEC element. + In this version of GSMP only, Prefix FECs are supported. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Element Type | Address Family | Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Prefix ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Element Type + In this version of GSMP the only supported Element Type is + Prefix FEC Elements. The Prefix FEC Element is a one-octet + value, encoded as 0x02. + + Address Family + Two-byte quantity containing a value from ADDRESS FAMILY + NUMBERS in [5], that encodes the address family for the address + prefix in the Prefix field. + + + + + + + + +Doria, et. al. Standards Track [Page 15] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Prefix Length + One byte containing the length in bits of the address prefix + that follows. A length of zero indicates a prefix that matches + all addresses (the default destination); in this case the + Prefix itself is zero bytes. + + Prefix + An address prefix encoded according to the Address Family + field, whose length, in bits, was specified in the Prefix + Length field. + +3.1.3.5 Label Stacking + + Label stacking is a technique used in MPLS [14] that allows + hierarchical labelling. MPLS label stacking is similar to, but + subtly different from, the VPI/VCI hierarchy of labels in ATM. There + is no set limit to the depth of label stacks that can be used in + GSMP. + + When the Stacked Label Indicator S is set to 1 it indicates that an + additional label field will be appended to the adjacent label field. + For example, a stacked Input Short Label could be designated as + follows: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ** |x|S|x|x| | + +-+-+-+-+ Stacked Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ** Note: There can be zero or more Stacked Labels fields (like + those marked **) following an Input or Output Label field. A + Stacked Label follows the previous label field if and only if + the S Flag in the previous label is set. + + When a label is extended by stacking, it is treated by the protocol + as a single extended label, and all operations on that label are + atomic. For example, in an add branch message, the entire input + label is switched for the entire output label. Likewise, in Move + Input Branch and Move Output Branch messages, the entire label is + swapped. For that reason, in all messages that designate a label + field, it will be depicted as a single 64-bit field, though it might + be instantiated by many 64-bit fields in practice. + + + + +Doria, et. al. Standards Track [Page 16] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +3.1.4 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. + + If the switch issues a failure response in reply to a request + message, no change should be made to the state of the switch as a + result of the message causing the failure. (For request messages + that contain multiple requests, such as the Delete Branches message, + the failure response message will specify which requests were + successful and which failed. The successful requests may result in + changed state.) + + A warning response message is a success response (Result = 3) with + the Code field specifying the warning code. The warning code + specifies a warning that was generated during the successful + operation. + + If the switch issues a failure response it MUST choose the most + specific failure code according to the following precedence: + + - Invalid Message + + - General Message Failure + + - Specific Message Failure + A failure response specified in the text defining the message + type. + + - Connection Failures + + - Virtual Path Connection Failures + + - Multicast Failures + + - QoS Failures + + - General Failures + + - Warnings + + If multiple failures match in any of the categories, the one that is + listed first should be returned. Descriptions of the Failure + response messages can be found in section 12. + + + + +Doria, et. al. Standards Track [Page 17] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +4. Connection Management Messages + +4.1 General Message Definitions + + Connection management messages are used by the controller to + establish, delete, modify and verify connections across the switch. + The Add Branch, Delete Tree, and Delete All connection management + messages have the following format, for both request and response + messages: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reservation ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Adaptation Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + +Doria, et. al. Standards Track [Page 18] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + When required, the Add Branch, Move Input Branch and Move Output + Branch messages have an additional, variable length data block + appended to the above message. This will be required when + indicated by the IQS and OQS flags (if the value of either is set + to 0b10) and the service selector. The additional data block has + the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Reservation ID + Identifies the reservation that MUST be deployed for the branch + being added. Reservations are established using reservation + management messages (see Chapter 5). A value of zero indicates + that no Reservation is being deployed for the branch. If a + reservation with a corresponding Reservation ID exists, then + the reserved resources MUST be applied to the branch. If the + numerical value of Reservation ID is greater than the value of + Max Reservations (from the Switch Configuration message), a + failure response is returned indicating "20: Reservation ID out + of Range". If the value of Input Port differs from the input + port specified in the reservation, or if the value of Output + Port differs from the output port specified in the reservation, + a failure response MUST be returned indicating "21: Mismatched + reservation ports". If no reservation corresponding to + Reservation ID exists, a failure response MUST be returned + indicating "23: Non-existent reservation ID". + + + + + + + + + +Doria, et. al. Standards Track [Page 19] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + If a valid Reservation ID is specified and the Service Model is + used (i.e., IQS or OQS=0b10) then the Traffic Parameters Block + may be omitted from the Add Branch message indicating that the + Traffic Parameters specified in the corresponding Reservation + Request message are to be used. + + Input Port + Identifies a switch input port. + + Input Label + Identifies an incoming labelled channel arriving at the switch + input port indicated by the Input Port field. The value in the + Input Label field MUST be interpreted according to the Label + Type attribute of the switch input port indicated by the Input + Port field. + + Input Service Selector + Identifies details of the service specification being used for + the connection. The interpretation depends upon the Input QoS + Model Selector (IQS). + + IQS = 00: In this case, the Input Service Selector indicates a + simple priority. + + IQS = 01: In this case, the Input Service Selector is an opaque + service profile identifier. The definition of these + service profiles is outside the scope of this + specification. Service Profiles can be used to + indicate pre-defined Differentiated Service Per Hop + Behaviours. + + IQS = 10: In this case, the Input Service Selector corresponds + to a Service Spec as defined in Chapter 8.2. When + the value of either IQS or OQS is set to 0b10, then a + Traffic Parameters Block is appended to the message. + + IQS = 11: In this case the Input Service Selector corresponds + to an ARM service specification. Definition of ARM + service specifications is outside the scope of this + specification and is determined by the MType as + defined in Chapter 8.1. + + Output Port + Identifies a switch output port. + + + + + + + +Doria, et. al. Standards Track [Page 20] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Output Label + Identifies an outgoing labelled channel departing at the switch + output port indicated by the Output Port field. The value in + the Output Label field MUST be interpreted according to the + Label Type attribute of the switch input port indicated by the + Output Port field + + Output Service Selector + Identifies details of the service model being used. The + interpretation depends upon the Output QoS Model selector + (OQS). + + OQS = 00: In this case the Output Service Selector indicates a + simple priority. + + OQS = 01: In this case the Output Service Selector is an opaque + service profile identifier. The definition of these + service profiles is outside the scope of this + specification. Service Profiles can be used to + indicate pre-defined Differentiated Service Per Hop + Behaviours. + + OQS = 10: In this case the Output Service Selector corresponds + to a Service Spec as defined in Chapter 8.2. When + the value of either IQS or OQS is set to 0b10 then a + Traffic Parameters Block is appended to the message. + + OQS = 11: In this case the Output Service Selector corresponds + to an ARM service specification. Definition of ARM + service specifications is outside the scope of this + specification and is determined by the MType as + defined in Chapter 8.1. + + IQS, OQS + Input and Output QoS Model Selector: + The QoS Model Selector is used to specify a QoS Model for the + connection. The values of IQS and OQS determine respectively + the interpretation of the Input Service Selector and the Output + Service Selector, and SHOULD be interpreted as a priority, a + QoS profile, a service specification, or an ARM specification + as shown: + + IQS/OQS QoS Model Service Selector + ------- --------- ---------------- + 00 Simple Abstract Model Priority + 01 QoS Profile Model QoS Profile + 10 Default Service Model Service Specification + 11 Optional ARM ARM Specification + + + +Doria, et. al. Standards Track [Page 21] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + P Flag + If the Parameter flag is set it indicates that a single + instance of the Traffic Parameter block is provided. This + occurs in cases where the Input Traffic Parameters are + identical to Output Traffic Parameters. + + N Flag + The Null flag is used to indicate a null adaptation method. + This occurs when the branch is connecting two ports of the same + type. + + O Flag + The Opaque flag indicates whether the adaptation fields are + opaque, or whether they are defined by the protocol. See the + definition of Adaptation Method below for further information. + + Adaptation Method + The adaptation method is used to define the adaptation framing + that may be in use when moving traffic from one port type to + another port type; e.g., from a frame relay port to an ATM + port. The content of this field is defined by the Opaque flag. + If the Opaque flag is set, then this field is defined by the + switch manufacturer and is not defined in this protocol. If + the opaque flag is not set, the field is divided into two 12- + bit fields as follows: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Input Adaptation | Output Adaptation | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Input Adaptation + Adaptation framing method used on incoming connections. + + Output Adaptation + Adaptation framing method used on outgoing connections. + + Adaptation Types: + + 0x100 PPP + 0x200 FRF.5 + 0x201 FRF.8 + + Input and Output TC Flags + TC (Traffic Control) Flags are used in Add Branch, Move Input + Branch and Move Output Branch messages for connections using + the Service Model (i.e., when IQS or OQS=0b10). The TC Flags + field is defined in Section 10.6. + + + + +Doria, et. al. Standards Track [Page 22] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Input and Output Traffic Parameters Block + This variable length field is used in Add Branch, Move Input + Branch and Move Output Branch messages for connections using + the Service Model (i.e., when IQS or OQS=0b10). Traffic + Parameters Block is defined in Section 10.5. The Traffic + Parameters Block may be omitted if a valid, non-zero + Reservation ID is specified, in which case the Traffic + Parameters of the corresponding Reservation Request message are + used. If the P flag is set, then the appended message block + will only include a single traffic parameter block which will + be used for both input and output traffic. + + For all connection management messages, except the Delete Branches + message, the success response message is a copy of the request + message returned with the Result field indicating success. The Code + field is not used in a connection management success response + message. + + The failure response message is a copy of the request message + returned with a Result field indicating failure. + + Fundamentally, no distinction is made between point-to-point and + point-to-multipoint connections. By default, the first Add Branch + message for a particular Input Port and Input Label will establish a + point-to-point connection. The second Add Branch message with the + same Input Port and Input Label fields will convert the connection to + a point-to-multipoint connection with two branches. However, to + avoid possible inefficiency with some switch designs, the Multicast + Flag is provided. If the controller knows that a new connection is + point-to-multipoint when establishing the first branch, it may + indicate this in the Multicast Flag. Subsequent Add Branch messages + with the same Input Port and Input Label fields will add further + branches to the point-to-multipoint connection. Use of the Delete + Branch message on a point-to-multipoint connection with two branches + will result in a point-to-point connection. However, the switch may + structure this connection as a point-to-multipoint connection with a + single output branch if it chooses. (For some switch designs this + structure may be more convenient.) Use of the Delete Branch message + on a point-to-point connection will delete the point-to-point + connection. There is no concept of a connection with zero output + branches. All connections are unidirectional, one input labelled + channel to one or more output labelled channels. + + In GSMP a multipoint-to-point connection is specified by establishing + multiple point-to-point connections, each of them specifying the same + output branch. (An output branch is specified by an output port and + output label.) + + + + +Doria, et. al. Standards Track [Page 23] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 states 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 24] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +4.2 Add Branch Message + + The Add Branch message is a connection management message used to + establish a connection or to add an additional branch to an existing + connection. It may also be used to check the connection state stored + in the switch. The connection is specified by the Input Port and + Input Label fields. The output branch is specified by the Output + Port and Output Label fields. The quality of service requirements of + the connection are specified by the QoS Model Selector and Service + Selector fields. To request a connection the Add Branch message is: + + Message Type = 16 + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reservation ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Adaptation Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|M|B| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|M|R| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Doria, et. al. Standards Track [Page 25] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + When the value of either IQS or OQS is set to 0b10 then the following + Traffic Parameters Block is appended to the above message: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Input TC Flags |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Input Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Output Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + M: Multicast + Multicast flags are used as a hint for point-to-multipoint or + multipoint-to-point connections in the Add Branch message. + They are not used in any other connection management messages + and in these messages they SHOULD be set to zero. There are + two instances of the M-bit in the Add Branch message; one for + input branch specified by the Input Port and Input Label fields + and one for the output branch specified by the Output Port and + Output Label fields. If set for the input branch (in front of + Input Label field), it indicates that the connection is very + likely to be a point-to-multipoint connection. If zero, it + indicates that this connection is very likely to be a point- + to-point connection or is unknown. If set for the output + branch (in front of the Output Label field), it indicates that + the connection is very likely to be a multipoint-to-point + connection. If zero, it indicates that this connection is very + likely to be a point-to-point connection or is unknown. + + If M flags are set for input as well as output branches, it + indicates that the connection is very likely to be a + multipoint-to-multipoint connection. + + The Multicast flags are only used in the Add Branch message + when establishing the first branch of a new connection. It is + not required to be set when establishing subsequent branches of + a point-to-multipoint or a multipoint-to-point connection and + + + +Doria, et. al. Standards Track [Page 26] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + on such connections it SHOULD be ignored by the receiver. + (Except in cases where the connection replace bit is enabled + and set, the receipt of the second and subsequent Add Branch + messages from the receiver indicates a point-to-multipoint or a + multipoint-to-point connection.) If it is known that this is + the first branch of a point-to-multipoint or a multipoint-to- + point connection, this flag SHOULD be set. If it is unknown, + or if it is known that the connection is point-to-point, this + flag SHOULD be zero. The use of the multicast flag is not + mandatory and may be ignored by the switch. If unused, the + flags SHOULD be set to zero. Some switches use a different + data structure for multicast connections rather than for + point-to-point connections. These flags prevent the switch + from setting up a point-to-point structure for the first branch + of a multicast connection that MUST immediately be deleted and + reconfigured as point-to-multipoint or multipoint-to-point when + the second branch is established. + + B: Bi-directional + The Bi-directional flag applies only to the Add Branch message. + In all other Connection Management messages it is not used. It + may only be used when establishing a point-to-point connection. + The Bi-directional flag in an Add Branch message, if set, + requests that two unidirectional connections be established, + one in the forward direction, and one in the reverse direction. + It is equivalent to two Add Branch messages, one specifying the + forward direction, and one specifying the reverse direction. + The forward direction uses the values of Input Port, Input + Label, Output Port and Output Label as specified in the Add + Branch message. The reverse direction is derived by exchanging + the values specified in the Input Port and Input Label fields, + with those of the Output Port and Output Label fields + respectively. Thus, a connection in the reverse direction + originates at the input port specified by the Output Port + field, on the label specified by the Output Label field. It + departs from the output port specified by the Input Port field, + on the label specified by the Input Label field. + + The Bi-directional flag is simply a convenience to establish + two unidirectional connections in opposite directions between + the same two ports, with identical Labels, using a single Add + Branch message. In all future messages the two unidirectional + connections MUST be handled separately. There is no bi- + directional delete message. However, a single Delete Branches + message with two Delete Branch Elements, one for the forward + connection and one for the reverse, may be used. + + + + + +Doria, et. al. Standards Track [Page 27] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + R: Connection Replace + The Connection Replace flag applies only to the Add Branch + message and is not used in any other Connection Management + messages. The R flag is used in cases when creation of + multipoint-to-point connections is undesirable (e.g., POTS + applications where fan-in is meaningless). If the R flag is + set, the new connection replaces any existing connection if the + label is already in use at the same Output Port. + + The Connection Replace mechanism allows a single Add Connection + command to function as either a Move Branch message or a + combination of Delete Branch/Add Branch messages. This + mechanism is provided to support existing 64k call handling + applications, such as emulating 64k voice switches. + + The use of R flag is optional and MUST be pre-configured in the + Port Management message [see section 6.1] to activate its use. + The R flag MUST NOT be set if it is not pre-configured with the + Port Management message. The switch MUST then return a Failure + Response message: "36: Replace of connection is not activated + on switch". Information about whether the function is active + or not, can be obtained by using the Port Configuration message + [see section 8.2]. + + The R flag MUST NOT be set if either the M flag or the B flag + is set. If a switch receives an Add connection request that + has the R flag set with either the B or the M flag set, it MUST + return a failure response message of: "37: Connection + replacement mode cannot be combined with Bi-directional or + Multicast mode" + + If the connection specified by the Input Port and Input Label fields + does not already exist, it MUST be established with the single output + branch specified in the request message. If the Bi-directional Flag + in the Flags field is set, the reverse connection MUST also be + established. The output branch SHOULD have the QoS attributes + specified by the Class of Service field. + + If the connection specified by the Input Port and Input Label fields + already exists and the R flag is not set, but the specified output + branch does not, the new output branch MUST be added. The new output + branch SHOULD have the QoS attributes specified by the Class of + Service field. + + If the connection specified by the Input Port and Input Label fields + already exists and the specified output branch also already exists, + the QoS attributes of the connection, specified by the Class of + Service field, if different from the request message, SHOULD be + + + +Doria, et. al. Standards Track [Page 28] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 a previously + established state. For messages that are reasserting a 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 or frames). + + If the connection specified by the Input Port and Input Label fields + already exists, and the Bi-directional Flag in the Flags field is + set, a failure response MUST be returned indicating: "15: Point-to- + point bi-directional connection already exists". + + It should be noted that different switches support multicast in + different ways. There may be a limit to the total number of point- + to-multipoint or multipoint-to-point connections certain switches can + support, and possibly a limit on the maximum number of branches that + a point-to-multipoint or multipoint-to-point connection may specify. + Some switches also impose a limit on the number of different Label + values that may be assigned e.g., to the output branches of a point- + to-multipoint connection. Many switches are incapable of supporting + more than a single branch of any particular point-to-multipoint + connection on the same output port. Specific failure codes are + defined for some of these conditions. + +4.2.1 ATM specific procedures: + + To request an ATM virtual path connection the ATM Virtual Path + Connection (VPC) Add Branch message is: + + Message Type = 26 + + An ATM virtual path connection can only be established between ATM + ports, i.e., ports with the "ATM" Label Type attribute. If an ATM + VPC Add Branch message is received and either the switch input port + specified by the Input Port field or the switch output port specified + by the Output Port field is not an ATM port, a failure response + message MUST be returned indicating, "28: ATM Virtual path switching + is not supported on non-ATM ports". + + If an ATM VPC Add Branch message is received and the switch input + port specified by the Input Port field does not support virtual path + switching, a failure response message MUST be returned indicating, + "24: ATM virtual path switching is not supported on this input port". + + + +Doria, et. al. Standards Track [Page 29] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + If an ATM virtual path connection already exists on the virtual path + specified by the Input Port and Input VPI fields, a failure response + message MUST be returned, indicating "27: Attempt to add an ATM + virtual channel connection branch to an existing virtual path + connection". For the VPC Add Branch message, if a virtual channel + connection already exists on any of the virtual channels within the + virtual path specified by the Input Port and Input VPI fields, a + failure response message MUST be returned indicating, "26: Attempt to + add an ATM virtual path connection branch to an existing virtual + channel connection". + +4.3 Delete Tree Message + + The Delete Tree message is a Connection Management message used to + delete an entire connection. All remaining branches of the + connection are deleted. A connection is defined by the Input Port + and the Input Label fields. The Output Port and Output Label fields + are not used in this message. 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. + +4.4 Verify Tree Message + + The Verify Tree message has been removed from this version of GSMP. + + Message Type = 19 + + If a request message is received with Message Type = 19, a failure + response MUST be returned with the Code field indicating: + + "3: The specified request is not implemented on this switch.". + +4.5 Delete All Input Port Message + + The Delete All Input Port message is a connection management message + used to delete all connections on a switch input port. All + connections that originate at the specified input port MUST be + deleted. On completion of the operation all dynamically assigned + Label values for the specified port MUST be unassigned, i.e., there + MUST be no connections established in the Label space that GSMP + controls on this port. The Service Selectors, Output Port, Input + + + +Doria, et. al. Standards Track [Page 30] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Label and Output Label fields are not used in this message. The + Delete All Input Port 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. + + The following failure response messages may be returned to a Delete + All Input Port request. + + 3: The specified request is not implemented on this switch. + + 4: One or more of the specified ports does not exist. + + 5: Invalid Port Session Number. + + If any field in a Delete All Input Port message not covered by the + above failure codes is invalid, a failure response MUST be returned + indicating: "2: Invalid request message". Else, the Delete All Input + Port operation MUST be completed successfully and a success message + returned. No other failure messages are permitted. + +4.6 Delete All Output Port Message + + The Delete All message is a connection management message used to + delete all connections on a switch output port. All connections that + have the specified output port MUST be deleted. On completion of the + operation all dynamically assigned Label values for the specified + port MUST be unassigned, i.e., there MUST be no connections + established in the Label space that GSMP controls on this port. The + Service Selectors, Input Port, Input Label and Output Label fields + are not used in this message. The Delete All Output Port message is: + + Message Type = 21 + + 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. + + The following failure response messages may be returned to a Delete + All Output Port request. + + + + + + +Doria, et. al. Standards Track [Page 31] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 3: The specified request is not implemented on this switch. + + 4: One or more of the specified ports does not exist. + + 5: Invalid Port Session Number. + + If any field in a Delete All Output Port message not covered by the + above failure codes is invalid, a failure response MUST be returned + indicating: "2: Invalid request message". Else, the delete all + operation MUST be completed successfully and a success message + returned. No other failure messages are permitted. + +4.7 Delete Branches Message + + The Delete Branches message is a connection management message used + to request one or more delete branch operations. Each delete branch + operation deletes a branch of a channel, or in the case of the last + branch of a connection, it deletes the connection. The Delete + Branches message is: + + Message Type = 17 + + The request 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Number of Elements | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Delete Branch Elements ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + + + + + + +Doria, et. al. Standards Track [Page 32] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Number of Elements + Specifies the number of Delete Branch Elements to follow in the + message. The number of Delete Branch Elements in a Delete + Branches message MUST NOT cause the packet length to exceed the + maximum transmission unit defined by the encapsulation. + + Each Delete Branch Element specifies a branch to be deleted and has + the following structure: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error |x|x|x|x|x|x|x|x|x|x|x|x| Element Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + Error + Is used to return a failure code indicating the reason for the + failure of a specific Delete Branch Element in a Delete + Branches failure response message. The Error field is not used + in the request message and MUST be set to zero. A value of + zero is used to indicate that the delete operation specified by + this Delete Branch Element was successful. Values for the + other failure codes are specified in Section 12, "Failure + Response Codes". + + All other fields of the Delete Branch Element have the same + definition as specified for the other connection management + messages. + + + + +Doria, et. al. Standards Track [Page 33] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + In each Delete Branch Element, a connection is specified by the Input + Port and Input Label fields. The specific branch to be deleted is + indicated by the Output Port and Output Label fields. + + If the Result field of the Delete Branches request message is + "AckAll" a success response message MUST be sent upon successful + deletion of the branches specified by all of the Delete Branch + Elements. The success response message MUST NOT be sent until all of + the delete branch operations have been completed. The success + response message is only sent if all of the requested delete branch + operations were successful. No Delete Branch Elements are returned + in a Delete Branches success response message and the Number of + Elements field MUST be set to zero. + + If there is a failure in any of the Delete Branch Elements, a Delete + Branches failure response message MUST be returned. The Delete + Branches failure response message is a copy of the request message + with the Code field of the entire message set to "10: General Message + Failure" and the Error field of each Delete Branch Element indicating + the result of each requested delete operation. A failure in any of + the Delete Branch Elements MUST NOT interfere with the processing of + any other Delete Branch Elements. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 34] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +4.8 Move Output Branch Message + + The Move Output Branch message is used to move a branch of an + existing connection from its current output port label to a new + output port label in a single atomic transaction. The Move Output + Branch connection management message has the following format for + both request and response messages: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Adaptation Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Old Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ New Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Doria, et. al. Standards Track [Page 35] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + When the value of either IQS or OQS is set to 0b10 then the following + Traffic Parameters Block is appended to the above message: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Input Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Output Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + The Move Output Branch message is a connection management message + used to move a single output branch of connection from its current + output port and Output Label, to a new output port and Output Label + on the same connection. None of the connection's other output + branches are modified. When the operation is complete the original + Output Label on the original output port will be deleted from the + connection. + + The Move Output Branch message is: + + Message Type = 22 + + For the Move Output Branch message, if the connection specified by + the Input Port and Input Label fields already exists, and the output + branch specified by the Old Output Port and Old Output Label fields + exists as a branch on that connection, the output branch specified by + the New Output Port and New Output Label fields is added to the + connection and the branch specified by the Old Output Port and Old + Output Label 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. + + For the Move Output Branch message, if the connection specified by + the Input Port and Input Label fields already exists, but the output + branch specified by the Old Output Port and Old Output Label fields + + + +Doria, et. al. Standards Track [Page 36] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + does not exist as a branch on that connection, a failure response + MUST be returned with the Code field indicating, "12: The specified + branch does not exist". + +4.8.1 ATM Specific Procedures: + + The ATM VPC Move Output Branch message is a connection management + message used to move a single output branch of a virtual path + connection from its current output port and output VPI, to a new + output port and output VPI on the same virtual channel connection. + None of the other output branches are modified. When the operation + is complete the original output VPI on the original output port will + be deleted from the connection. + + The VPC Move Branch message is: + + Message Type = 27 + + For the VPC Move Output Branch message, if the virtual path + connection specified by the Input Port and Input VPI fields already + exists, and the output branch specified by the Old Output Port and + Old Output VPI fields exists as a branch on that connection, the + output branch specified by the New Output Port and New Output VPI + fields is added to the connection and the branch specified by the Old + Output Port and Old Output VPI 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. + + For the VPC Move Output Branch message, if the virtual path + connection specified by the Input Port and Input VPI fields already + exists, but the output branch specified by the Old Output Port and + Old Output VPI fields does not exist as a branch on that connection, + a failure response MUST be returned with the Code field indicating, + "12: The specified branch does not exist". + + If the virtual channel connection specified by the Input Port and + Input Label fields; or the virtual path connection specified by the + Input Port and Input VPI fields; does not exist, a failure response + MUST be returned with the Code field indicating, "11: The specified + connection does not exist". + + If the output branch specified by the New Output Port, New Output + VPI, and New Output VCI fields for a virtual channel connection; or + the output branch specified by the New Output Port and New Output VPI + fields for a virtual path connection; is already in use by any + connection other than that specified by the Input Port and Input + + + +Doria, et. al. Standards Track [Page 37] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Label fields, then the resulting output branch will have multiple + input branches. If multiple point-to-point connections share the + same output branch, the result will be a multipoint-to-point + connection. If multiple point-to-multipoint trees share the same + output branches, the result will be a multipoint-to-multipoint + connection. + +4.9 Move Input Branch Message + + The Move Input Branch message is used to move a branch of an existing + connection from its current input port label to a new input port + label in a single atomic transaction. The Move Input Branch + connection management message has the following format for both + request and response messages: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 38] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Adaptation Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Old Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ New Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 39] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + When the value of either IQS or OQS is set to 0b10, then the + following Traffic Parameters Block is appended to the above message: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Input Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Output Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + The Move Input Branch message is a connection management message used + to move a single input branch of connection from its current input + port and Input Label, to a new input port and Input Label on the same + connection. None of the connection's other input branches are + modified. When the operation is complete, the original Input Label + on the original input port will be deleted from the connection. + + The Move Input Branch message is: + + Message Type = 23 + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 40] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + For the Move Input Branch message, if the connection specified by the + Output Port and Output Label fields already exists, and the input + branch specified by the Old Input Port and Old Input Label fields + exists as a branch on that connection, the input branch specified by + the New Input Port and New Input Label fields is added to the + connection and the branch specified by the Old Input Port and Old + Input Label 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 Input Branch operation has been + completed. + + For the Move Input Branch message, if the connection specified by the + Output Port and Output Label fields already exists, but the input + branch specified by the Old Input Port and Old Input Label fields + does not exist as a branch on that connection, a failure response + MUST be returned with the Code field indicating, "12: The specified + branch does not exist". + +4.9.1 ATM Specific Procedures: + + The ATM VPC Move Input Branch message is a connection management + message used to move a single input branch of a virtual path + connection from its current input port and input VPI, to a new input + port and input VPI on the same virtual channel connection. None of + the other input branches are modified. When the operation is + complete, the original input VPI on the original input port will be + deleted from the connection. + + The VPC Move Input Branch message is: + + Message Type = 28 + + For the VPC Move Input Branch message, if the virtual path connection + specified by the Output Port and Output VPI fields already exists, + and the input branch specified by the Old Input Port and Old Input + VPI fields exists as a branch on that connection, the input branch + specified by the New Input Port and New Input VPI fields is added to + the connection and the branch specified by the Old Input Port and Old + Input VPI 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 Input Branch operation has been + completed. + + For the VPC Move Input Branch message, if the virtual path connection + specified by the Output Port and Output VPI fields already exists, + but the input branch specified by the Old Input Port and Old Input + + + +Doria, et. al. Standards Track [Page 41] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + VPI fields does not exist as a branch on that connection, a failure + response MUST be returned with the Code field indicating, "12: The + specified branch does not exist". + + If the virtual channel connection specified by the Output Port and + Output Label fields, or if the virtual path connection specified by + the Output Port and Output VPI fields does not exist, a failure + response MUST be returned with the Code field indicating, "11: The + specified connection does not exist". + + If the input branch specified by the New Input Port, New Input VPI, + and New Input VCI fields for a virtual channel connection, or the + input branch specified by the New Input Port and New Input VPI fields + for a virtual path connection, is already in use by any connection + other than that specified by the Output Port and Output Label fields, + then the resulting input branch will have multiple output branches. + If multiple point-to-point connections share the same input branch, + the result will be a point-to-multipoint connection. If multiple + multipoint-to-point trees share the same input branches, the result + will be a multipoint-to-multipoint connection. + +5. Reservation Management Messages + + GSMP allows switch resources (e.g., bandwidth, buffers, queues, + labels, etc.) to be reserved for connections before the connections + themselves are established. This is achieved through the + manipulation of Reservations in the switch. + + Reservations are hard state objects in the switch that can be created + by the controller by sending a Reservation Request message. Each + Reservation is uniquely identified by an identifying number called a + Reservation ID. Reservation objects can be deleted with the Delete + Reservation message or the Delete All Reservations message. A + reservation object is also deleted when the Reservation is deployed + by specifying a Reservation ID in a valid Add Branch message. + + The reserved resources MUST remain reserved until either the + reservation is deployed, in which case the resources are applied to a + branch, or the reservation is explicitly deleted (with a Delete + Reservation message or a Delete All Reservations message), in which + case the resources are freed. Reservations and reserved resources + are deleted if the switch is reset. + + A Reservation object includes its Reservation ID plus all the + connection state associated with a branch with the exception that the + branch's input label and/or output label may be unspecified. The + Request Reservation message is therefore almost identical to the Add + Branch message. + + + +Doria, et. al. Standards Track [Page 42] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The switch establishes the maximum number of reservations it can + store by setting the value of Max Reservations in the Switch + Configuration response message. The switch indicates that it does + not support reservations by setting Max Reservations to 0. The valid + range of Reservation IDs is 1 to Max Reservations). + +5.1 Reservation Request Message + + The Reservation Request message creates a Reservation in the switch + and reserves switch resources for a connection that may later be + established using an Add Branch message. The Reservation Request + Message is: + + Message Type = 70 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 43] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Reservation Request message has the following format for the + request message: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reservation ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Service Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |IQS|OQS|P|x|N|O| Adaptation Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|M|B| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|M|x| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 44] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + When the value of either IQS or OQS is set to 0b10 then the following + Traffic Parameters Block is appended to the above message: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Input Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Output Traffic Parameters Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general connection message will not be + explained in this section. Please refer to section 4.1 for + details. + + All the fields of the Reservation Request message have the same + meanings as they do in the Add Branch message with the following + exceptions: + + Reservation ID + Specifies the Reservation ID of the Reservation. If the + numerical value of the Reservation ID is greater than the value + of the Max Reservations (from the Switch Configuration + message), a failure response is returned indicating "20: the + Reservation ID out of Range". If the value of Reservation ID + matches that of an extant Reservation, a failure response is + returned indicating "22: Reservation ID in use". + + Input Label + If a specific input label is specified, then that label is + reserved along with the required resources. If the Input Label + is 0 then the switch reserves the resources, but will not bind + them to a label until the add branch command is given, which + references the Reservation Id. If the input label is 0, then + all stacked labels MUST also be zeroed. + + + + + + + +Doria, et. al. Standards Track [Page 45] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Output Label + If a specific Output Label is specified then that label is + reserved along with the required resources. If the Output + Label is 0 then the switch reserves the resources, but will not + bind them to a label until the add branch command is given + which references the Reservation Id. If the Output Label is 0, + then all stacked labels MUST also be zeroed + + When the switch receives a valid Reservation Request it reserves all + the appropriate switch resources needed to establish a branch with + corresponding attributes. If sufficient resources are not available, + a failure response is returned indicating "18: Insufficient + resources". Other failure responses are as defined for the Add + Branch message. + +5.2 Delete Reservation Message + + The Delete Reservation message deletes a Reservation object in the + switch and frees the reserved switch resources associated with that + reservation object. The Reservation Request Message is: + + Message Type = 71 + + The Delete Reservation 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reservation ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + If the Reservation ID matches that of an extant Reservation then the + reservation is deleted and corresponding switch resources are freed. + If the numerical value of the Reservation ID is greater than the + value of the Max Reservations (from the Switch Configuration + message), a failure response is returned indicating "20: Reservation + ID out of Range". If the value of Reservation ID does not match that + of any extant Reservation, a failure response is returned indicating + "23: Non-existent reservation ID". + + + + +Doria, et. al. Standards Track [Page 46] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +5.3 Delete All Reservations Message + + The Delete All Reservation message deletes all extant Reservation + objects in the switch and frees the reserved switch resources of + these reservations. The Reservation Request Message is: + + Message Type = 72 + + The Delete All Reservation 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +6. Management Messages + +6.1 Port Management Message + + The Port Management message allows a port to be brought into service, + to be taken out of service, to be set to loop back, reset, or to + change the transmit data rate. 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. The Port Management message MAY also be + used for enabling the replace connection mechanism. The Port + Management message is also used as part of the Event Message flow + control mechanism. + + 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 + + + + + + + + + + + +Doria, et. al. Standards Track [Page 47] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Port Management message has the following format for the request + and success response messages: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|x|x|x|x|x|x|x| Duration | Function | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Flags | Flow Control Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transmit Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Event Sequence Number + 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 initialised. It is incremented by one each time the port + detects an asynchronous event 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. + + R: Connection Replace + The R flag shall only be checked when the Function field = 1 + (Bring Up). If the R flag is set in the Port Management + request message, it indicates that a switch controller requests + the switch port to support the Connection Replace mechanism. + + + +Doria, et. al. Standards Track [Page 48] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Connection Replace behaviour is described in chapter 4.2. If a + switch does not support the Connection Replace mechanism, it + MUST reply with the failure response: "45: Connection Replace + mechanism not supported on switch" and reset the R-flag. Upon + successful response, the R flag SHOULD remain set in the + response message. + + 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. + + 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). If the specified function + requires a new Port Session Number to be generated, the new + Port Session Number MUST be returned in the success response + message. The defined values of the Function field are: + + Bring Up: + Function = 1. Bring the port into service. All connections + that originate at the specified input port MUST be deleted + and a new Port Session Number MUST be selected, preferably + using some form of random number. On completion of the + operation all dynamically assigned Label values for the + specified input port MUST be unassigned, i.e., no + connections will be established in the Label space that GSMP + controls on this input port. Afterwards, the Port Status of + the port will be Available. + + Take Down: + Function = 2. Take the port out of service. Any data + received at this port will be discarded. No data will be + transmitted from this port. Afterwards, the Port Status of + the port will be Unavailable. + + The behaviour is undefined if the port is taken down over + which the GSMP session that controls the switch is running. + (In this case the most probable behaviour would be for the + switch either to ignore the message or to terminate the + current GSMP session and to initiate another session, + + + +Doria, et. al. Standards Track [Page 49] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + possibly with the backup controller, if any.) The correct + method to reset the link over which GSMP is running is to + issue an RSTACK message in the adjacency protocol. + + Internal Loopback: + Function = 3. Data 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 functions of the input + port above the physical layer, e.g., header translation, are + performed upon the looped back data. Afterwards, the Port + Status of the port will be Internal Loopback. + + External Loopback: + Function = 4. Data 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 functions of the input + port, above the physical layer are performed upon the looped + back data. Afterwards, the Port Status of the port will be + External Loopback. + + Bothway Loopback: + Function = 5. Both internal and external loopbacks are + performed. Afterwards, the Port Status of the port will be + Bothway Loopback. + + Reset Input Port: + Function = 6. All connections that originate at the + specified input port MUST be deleted and the input and + output port hardware re-initialised. On completion of the + operation, all dynamically assigned Label values for the + specified input port MUST be unassigned, i.e., no + connections will be established in the Label space that GSMP + controls on this input port. The range of labels that may + be controlled by GSMP on this port will be set to the + default values specified in the Port Configuration message. + The transmit data rate of the output port MUST be set to its + default value. The Port Session Number is not changed by + the Reset Input Port function. Afterwards, the Port Status + of the port will be Unavailable. + + Reset Flags: + Function = 7. This function is used to reset the Event + Flags and Flow Control Flags. For each bit that is set in + the Event Flags field, the corresponding Event Flag in the + switch port MUST be reset to 0. For each bit that is set in + the Flow Control Flags field, the corresponding Flow Control + Flag in the switch port MUST be toggled; i.e., flow control + + + +Doria, et. al. Standards Track [Page 50] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + for the corresponding event is turned off if is currently on + and it is turned on if it is currently off. The Port Status + of the port is not changed by this function. + + Set Transmit Data Rate: + Function = 8. Sets the transmit data rate of the output + port as close as possible to the rate specified in the + Transmit Data Rate field. In the success response message, + the Transmit Data Rate MUST indicate the actual transmit + data rate of the output port. If the transmit data rate of + the requested output port cannot be changed a failure + response MUST be returned with the Code field indicating: + "43: The transmit data rate of this output port cannot be + changed". If the transmit data rate of the requested output + port can be changed, but the value of the Transmit Data Rate + field is beyond the range of acceptable values, a failure + response MUST be returned with the Code field indicating: + "44: Requested transmit data rate out of range for this + output port". In the failure response message, the Transmit + Data Rate MUST contain the same value as contained in the + request message that caused the failure. The transmit data + rate of the output port is not changed by the Bring Up, Take + Down, or any of the Loopback functions. It is returned to + the default value by the Reset Input Port function. + + Transmit Data Rate + This field is only used in request and success response + messages with the Function field set to "Set Transmit Data + Rate". It is used to set the output data rate of the output + port. It is specified in cells/s and bytes/s. If the Transmit + Data Rate field contains the value 0xFFFFFFFF the transmit data + rate of the output port SHOULD be set to the highest valid + value. + + Event Flags + Field in the request message that 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. Depending on the + setting in the Flow Control Flag, a port is either subject to + flow control or not. If it is subject to flow control, then it + is not permitted to send another Event message of the same type + before the Event Flag has been reset. To reset an event flag, + the Function field in the request message is set to "Reset + Flags". For each bit that is set in the Event Flags field, the + corresponding Event Flag in the switch port is reset. + + + + +Doria, et. al. Standards Track [Page 51] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 is not + used. 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 messages and the + bits of the Event Flags field is as follows: + + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|D|I|N|Z|A|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + U: Port Up Bit 0, (most significant bit) + D: Port Down Bit 1, + I: Invalid Label Bit 2, + N: New Port Bit 3, + Z: Dead Port Bit 4, + A: Adjacency Event Bit 5, + x: Unused Bits 6-15. + + Flow Control Flags Field + The flags in this field are used to indicate whether the flow + control mechanism described in the Events Flag field is turned + on or not. If the Flow Control Flag is set, then the flow + control mechanism for that event on that port is activated. To + toggle the flow control mechanism, the Function field in the + request message is set to "Reset Flags". When doing a reset, + for each flag that is set in the Flow Control Flags field, the + corresponding flow control mechanism MUST be toggled. + + The Flow Control Flags correspond to the same event definitions + as defined for the Event Flag. + + + + + + + + + + +Doria, et. al. Standards Track [Page 52] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +6.2 Label Range Message + + The default label range, Min Label to Max Label, is specified for + each port by the Port Configuration or the All Ports Configuration + messages. When the protocol is initialised, before the transmission + of any Label Range messages, the label range of each port will be set + to the default label range. (The default label range is dependent + upon the switch design and configuration and is not specified by the + GSMP protocol.) The Label Range message allows the range of labels + supported by a specified port, to be changed. Each switch port MUST + declare whether it supports the Label Range message in the Port + Configuration or the All Ports Configuration messages. The Label + Range message is: + + Message Type = 33 + + The Label Range message has the following format for the request and + success response messages: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Q|M|D|x| Range Count | Range Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Label Range Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + + + + + + + + +Doria, et. al. Standards Track [Page 53] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Each element of the Label Range Block has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|C| | + +-+-+-+-+ Min Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| | + +-+-+-+-+ Max Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remaining Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Flags + + Q: Query + If the Query flag is set in a request message, the switch + MUST respond with the current range of valid labels. The + current label range is not changed by a request message with + the Query flag set. If the Query flag is zero, the message + is requesting a label change operation. + + M: Multipoint Query + If the Multipoint Query flag is set the switch MUST respond + with the current range of valid specialized multipoint + labels. The current label range is not changed by a request + message with the Multipoint Query flag set. + + D: Non-contiguous Label Range Indicator + This flag will be set in a Query response if the labels + available for assignment belong to a non-contiguous set. + + V: Label + The Label flag use is port type specific. + + C: Multipoint Capable + Indicates label range that can be used for multipoint + connections. + + Range Count + Count of Label Range elements contained in the Label Range + Block. + + Range Length + Byte count in the Label Range Block. + + + + + +Doria, et. al. Standards Track [Page 54] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Min Label + The minimum label value in the range. + + Max Label + The maximum label value in the range. + + Remaining Labels + The maximum number of remaining labels that could be requested + for allocation on the specified port. + + The success response to a Label Range message requesting a change of + label range is a copy of the request message with the Remaining + Labels field updated to the new values after the Label Range + operation. + + If the switch is unable to satisfy a request to change the Label + range, it MUST return a failure response message with the Code field + set to: "40: Cannot support one or more requested label ranges". In + this failure response message, the switch MUST use the Min Label and + Max Label fields to suggest a label range that it is able to satisfy. + + A Label Range request message may be issued regardless of the Port + Status or the Line Status of the target switch port. If the Port + field of the request message contains an invalid port (a port that + does not exist or a port that has been removed from the switch) a + failure response message MUST be returned with the Code field set to, + "4: One or more of the specified ports does not exist". + + If the Query flag is set in the request message, the switch MUST + reply with a success response message containing the current range of + valid labels that are supported by the port. The Min Label and Max + Label fields are not used in the request message. + + If the Multipoint Query flag is set in the request message and the + switch does not support a range of valid multipoint labels, then the + switch MUST reply with a failure response message with the Code field + set to, "42: Specialised multipoint labels not supported". The Min + Label and Max Label fields are not used in the Multipoint request + message. + + If a label range changes and there are extant connection states with + labels used by the previous label range, a success response message + MUST be returned with the Code field set to, "46: One or more labels + are still used in the previous Label Range". This action indicates + that the label range has successfully changed but with a warning that + there are extant connection states for the previous label range. + + + + + +Doria, et. al. Standards Track [Page 55] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +6.2.1 Labels + +6.2.1.1 ATM Labels + + If the Label Type = ATM Label, the labels range message MUST be + interpreted as an ATM Label as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|C| ATM Label (0x100) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| min VPI | min VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| ATM Label (0x100) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| max VPI | max VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remaining VPI's | Remaining VCI's | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + V: Label + If the Label flag is set, the message refers to a range of + VPI's only. The Min VCI and Max VCI fields are unused. If the + Label flag is zero the message refers to a range of VCI's on + either one VPI or on a range of VPI's. + + Min VPI, Max VPI + Specify a range of VPI values, Min VPI to Max VPI inclusive. A + single VPI may be specified with a Min VPI and a Max VPI having + the same value. In a request message, if the value of the Max + VPI field is less than or equal to the value of the Min VPI + field, the requested range is a single VPI with a value equal + to the Min VPI field. Zero is a valid value. In a request + message, if the Query flag is set, and the Label flag is zero, + the Max VPI field specifies a single VPI and the Min VPI field + is not used. The maximum valid value of these fields for both + request and response messages is 0xFFF. + + Min VCI, Max VCI + Specify a range of VCI values, Min VCI to Max VCI inclusive. A + single VCI may be specified with a Min VCI and a Max VCI having + the same value. In a request message, if the value of the Max + VCI field is less than or equal to the value of the Min VCI + field, the requested range is a single VCI with a value equal + to the Min VCI field. Zero is a valid value. (However, VPI=0, + VCI=0 is not available as a virtual channel connection as it is + used as a special value in ATM to indicate an unassigned cell.) + + + +Doria, et. al. Standards Track [Page 56] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Remaining VPI's, Remaining VCI's + These fields are unused in the request message. In the success + response message and in the failure response message these + fields give the maximum number of remaining VPI's and VCI's + that could be requested for allocation on the specified port + (after completion of the requested operation in the case of the + success response). It gives the switch controller an idea of + how many VPI's and VCI's it could request. The number given is + the maximum possible given the constraints of the switch + hardware. There is no implication that this number of VPI's + and VCI's is available to every switch port. + + If the Query flag and the Label flag are set in the request message, + the switch MUST reply with a success response message containing the + current range of valid VPI's that are supported by the port. The Min + VPI and Max VPI fields are not used in the request message. + + If the Query flag is set and the Label flag is zero in the request + message, the switch MUST reply with a success response message + containing the current range of valid VCI's that are supported by the + VPI specified by the Max VPI field. If the requested VPI is invalid, + a failure response MUST be returned indicating: "13: One or more of + the specified Input Labels is invalid". The Min VPI field is not + used in either the request or success response messages. + + If the Query flag is zero and the Label flag is set in the request + message, the Min VPI and Max VPI fields specify the new range of + VPI's to be allocated to the input port specified by the Port field. + The range of VPI's previously allocated to this port SHOULD be + increased or decreased to the specified value. + + If the Query flag and the Label flag are zero in the request message, + the Min VCI and Max VCI fields specify the range of VCI's to be + allocated to each of the VPI's specified by the VPI range. The range + of VCI's previously allocated to each of the VPI's within the + specified VPI range on this port, it SHOULD be increased or decreased + to the specified value. The allocated VCI range MUST be the same on + each of the VPI's within the specified VPI range. + + If the switch is unable to satisfy a request to change the label + range, it MUST return a failure response message with the Code field + set to: "40: Cannot support one or more requested label ranges". If + the switch is unable to satisfy a request to change the VPI, the + switch MUST use the Min VPI and Max VPI fields to suggest a VPI range + that it would be able to satisfy and set the VCI fields to zero, or + if the switch is unable to satisfy a request to change the VCI range + + + + + +Doria, et. al. Standards Track [Page 57] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + on all VPI's within the requested VPI range, the switch MUST use the + Min VPI, Max VPI, Min VCI, and Max VCI fields to suggest a VPI and + VCI range that it would be able to satisfy. + + In all other failure response messages for the label range operation, + the switch MUST return the values of Min VPI, Max VPI, Min VCI, and + Max VCI from the request message. + + While switches can typically support all 256 or 4096 VPI's, the VCI + range that can be supported is often more constrained. Often the Min + VCI MUST be 0 or 32. Typically all VCI's within a particular VPI + MUST be contiguous. The hint in the failure response message allows + the switch to suggest a label range that it could satisfy in view of + its particular architecture. + + While the Label Range message is defined to specify both a range of + VPI's and a range of VCI's within each VPI, the most likely use is to + change either the VPI range or the range of VCI's within a single + VPI. It is possible for a VPI to be valid but to be allocated no + valid VCI's. Such a VPI could be used for a virtual path connection, + but to support virtual channel connections it would need to be + allocated a range of VCI's. + +6.2.1.2 Frame Relay Labels + + If the Label Type = FR Label, the labels range message MUST be + interpreted as Frame Relay Labels as shown: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|C| FR Label (0x101) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| Res |Len| Min DLCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| FR Label (0x101) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| Res |Len| Max DLCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remaining DLCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + V: Label + The Label flag is not used. + + Res + The Res field is reserved in [21], i.e., it is not explicitly + reserved by GSMP. + + + +Doria, et. al. Standards Track [Page 58] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Len + The Len field specifies the number of bits of the DLCI. The + following values are supported: + + Len DLCI bits + 0 10 + 2 23 + + Min DLCI, Max DLCI + Specify a range of DLCI values, Min DLCI to Max DLCI inclusive. + The values SHOULD be right justified in the 23-bit fields and + the preceding bits SHOULD be set to zero. A single DLCI may be + specified with a Min DLCI and a Max DLCI having the same value. + In a request message, if the value of the Max DLCI field is + less than or equal to the value of the Min DLCI field, the + requested range is a single DLCI with a value equal to the Min + DLCI field. Zero is a valid value. + + Remaining DLCI's + This field is unused in the request message. In the success + response message and in the failure response message, this + field gives the maximum number of remaining DLCI's that could + be requested for allocation on the specified port (after + completion of the requested operation in the case of the + success response). It gives the switch controller an idea of + how many DLCI's it could request. The number given is the + maximum possible given the constraints of the switch hardware. + There is no implication that this number of DLCI's is available + to every switch port. + +6.2.1.3 MPLS Generic Labels + + The Label Range Block for PortTypes using MPLS labels. These types + of labels are for use on links for which label values are independent + of the underlying link technology. Examples of such links are PPP + and Ethernet. On such links the labels are carried in MPLS label + stacks [14]. If Label Type = MPLS Gen Label, the labels range + message MUST be interpreted as MPLS Generic Label as shown: + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 59] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|C| MPLS Gen Label (0x102)| Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x|x|x|x|x|x|x|x|x| Min MPLS Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| MPLS Gen Label (0x102)| Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x|x|x|x|x|x|x|x|x| Max MPLS Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remaining Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + V: Label + The Label flag is not used. + + Min MPLS Label, Max MPLS Label + Specify a range of MPLS label values, Min MPLS Label to Max + MPLS Label inclusive. The Max and Min MPLS label fields are 20 + bits each. + + Remaining MPLS Labels + This field is unused in the request message. In the success + response message and in the failure response message this field + gives the maximum number of remaining MPLS Labels that could be + requested for allocation on the specified port (after + completion of the requested operation in the case of the + success response). It gives the switch controller an idea of + how many MPLS Labels it could request. The number given is the + maximum possible given the constraints of the switch hardware. + There is no implication that this number of Labels is available + to every switch port. + +6.2.1.4 FEC Labels + + The Label Range message is not used for FEC Labels and is for further + study. + +7. State and Statistics Messages + + The state and statistics messages permit the controller to request + the values of various hardware counters associated with the switch + input and output ports and connections. They also permit the + controller to request the connection state of a switch input port. + The Connection Activity message is used to determine whether one or + + + + + +Doria, et. al. Standards Track [Page 60] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + more specific connections have recently been carrying traffic. The + Statistics message is used to query the various port and connection + traffic and error counters. + + The Report Connection State message is used to request an input port + to report the connection state for a single connection, a single ATM + virtual path connection, or for the entire input port. + +7.1 Connection Activity Message + + The Connection Activity message is used to determine whether one or + more specific connections have recently been carrying traffic. The + Connection Activity message contains one or more Activity Records. + Each Activity Record is used to request and return activity + information concerning a single connection. Each connection is + specified by its input port and Input Label which are specified in + the Input Port and Input Label fields of each Activity Record. + + Two forms of activity detection are supported. If the switch + supports per connection traffic accounting, the current value of the + traffic counter for each specified connection 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 connections to determine whether each connection has been + active in the intervening period. If the switch does not support per + connection traffic accounting, but is capable of detecting per + connection activity by some other unspecified means, the result may + be indicated for each connection using the Flags field. The + Connection Activity message is: + + Message Type = 48 + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 61] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Connection 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Records |x x x x x x x x x x x x x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Activity Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Number of Records + Field specifies the number of Activity Records to follow. The + number of Activity records in a single Connection Activity + message MUST NOT cause the packet length to exceed the maximum + transmission unit defined by the encapsulation. + + Each Activity Record has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V|C|A|x| TC Count | TC Block Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Traffic Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Doria, et. al. Standards Track [Page 62] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Flags + + V: Valid Record + In the success response message the Valid Record flag is + used to indicate an invalid Activity Record. The flag MUST + be zero if any of the fields in this 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 the Valid Record flag is zero in a success + response message, the Counter flag, the Activity flag, and + the Traffic Count field are undefined. If the Valid Record + flag is set, the Activity Record is valid, and the Counter + and Activity flags are valid. The Valid Record flag is not + used in the request message. + + C: Counter + In a success response message, if the Valid Record flag is + set, the Counter flag, if zero, indicates that the value in + the Traffic Count field is valid. If set, it indicates that + the value in the Activity flag is valid. The Counter flag + is not used in the request message. + + A: Activity + In a success response message, if the Valid Record and + Counter flags are set, the Activity flag, if set, indicates + that there has been some activity on this connection since + the last Connection Activity message for this connection. + If zero, it indicates that there has been no activity on + this connection since the last Connection Activity message + for this connection. The Activity flag is not used in the + request message. + + TC Count + In cases where per connection traffic counting is supported, + this field contains the count of Traffic Count entries. + + TC Block Length + In cases where per connection traffic counting is supported, + this field contains the Traffic Count block size in bytes. + + Input Port + Identifies the port number of the input port on which the + connection of interest originates in order to identify the + connection (regardless of whether the traffic count for the + connection is maintained on the input port or the output port). + + + + + + +Doria, et. al. Standards Track [Page 63] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Input Label + Fields identify the specific connection for which statistics + are being requested. + + Traffic Count + Field is not used in the request message. In the success + response message, if the switch supports per connection traffic + counting, the Traffic Count field MUST be set to the value of a + free running, connection specific, 64-bit traffic counter + counting traffic flowing across the specified connection. The + value of the traffic counter is not modified by reading it. If + per connection traffic counting is supported, the switch MUST + report the Connection Activity result using the traffic count + rather than using the Activity flag. + + The format of the failure response is the same as the request message + with the Number of Records field set to zero and no Connection + Activity records returned in the message. If the switch is incapable + of detecting per connection activity, a failure response MUST be + returned indicating, "3: The specified request is not implemented on + this switch". + +7.2 Statistics Messages + + The Statistics messages are used to query the various port, + connection and error counters. + + The 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + + +Doria, et. al. Standards Track [Page 64] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Label + The Label Fields identifies the specific connection for which + statistics are being requested. + + The success response for the Statistics 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Input Cell Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Input Frame Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Input Cell Discard Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Input Frame Discard Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Header Checksum Error Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Input Invalid Label Count + + | | + + + + + + +Doria, et. al. Standards Track [Page 65] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Output Cell Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Output Frame Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Output Cell Discard Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Output Frame Discard Count + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Field and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Input Cell Count, Output Cell Count + Give the value of a free running 64-bit counter counting cells + arriving at the input or departing from the output + respectively. These fields are relevant for label type = ATM, + for all other label types these fields SHOULD be set to zero by + the sender and ignored by the receiver. + + Input Frame Count, Output Frame Count + Give the value of a free running 64-bit counter counting frames + (packets) arriving at the input or departing from the output + respectively. These fields are relevant for label types = FR + and MPLS, for all other label types these fields SHOULD be set + to zero by the sender and ignored by the receiver. + + Input Cell Discard Count, Output Cell Discard Count + Give 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. These fields are relevant for label + type = ATM, for all other label types these fields SHOULD be + set to zero by the sender and ignored by the receiver. + + Input Frame Discard Count, Output Frame Discard Count + Give the value of a free running 64-bit counter counting frames + discarded due to congestion on an input port or on an output + port respectively. These fields are relevant for label + + + + +Doria, et. al. Standards Track [Page 66] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + types = FR and MPLS, for all other label types these fields + SHOULD be set to zero by the sender and ignored by the + receiver. + + Header Checksum Error Count + Gives the value of a free running 64-bit counter counting cells + or frames discarded due to header checksum errors on arrival at + an input port. For an ATM switch this would be the HEC count. + + Invalid Label Count + Gives the value of a free running 64-bit counter counting cells + or frames discarded because their Label is invalid on arrival + at an input port. + +7.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 Label field in + the Port Statistics request message is ignored. All of the count + fields in the success response message refer to per-port counts + regardless of the connection to which the cells or frames belong. + Any of the count fields in the success response message not supported + by the port MUST be set to zero. The Port Statistics message is: + + Message Type = 49 + +7.2.2 Connection Statistics Message + + The Connection Statistics message requests the statistics for the + connection specified in the Label field that originates 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 connection. + The Header Checksum Error Count and Invalid Label Count fields are + not connection specific and MUST be set to zero. Any of the other + count fields not supported on a per connection basis MUST be set to + zero in the success response message. The Connection Statistics + message is: + + Message Type = 50 + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 67] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +7.2.3 QoS Class Statistics Message + + The QoS Class Statistics message is not supported in this version of + GSMP. + + Message Type = 51 is reserved. + +7.3 Report Connection State Message + + The Report Connection State message is used to request an input port + to report the connection state for a single connection or for the + entire input port. The Report Connection State message is: + + Message Type = 52 + + The Report Connection State request 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|A|V| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Field and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Input Port + Identifies the port number of the input port for which the + connection state is being requested. + + + + + + + + + + + +Doria, et. al. Standards Track [Page 68] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Flags + + A: All Connections + If the All Connections flag is set, the message requests the + connection state for all connections that originate at the + input port specified by the Input Port field. In this case + the Input Label field and the Label flag are unused. + + V: ATM VPI + The ATM VPI flag may only be set for ports with + PortType=ATM. If the switch receives a Report Connection + State message in which the ATM VPI flag set and in which the + input port specified by the Input Port field does not have + PortType=ATM, the switch MUST return a Failure response "28: + ATM Virtual Path switching is not supported on non-ATM + ports". + + If the All Connections flag is zero and the ATM VPI flag is + also zero, the message requests the connection state for the + connection that originates at the input port specified by + the Port and Input Label fields. + + ATM specific procedures: + If the All Connections flag is zero and the ATM VPI flag is + set and the input port specified by the Input Port field has + LabelType=ATM, the message requests the connection state for + the virtual path connection that originates at the input + port specified by the Input Port and Input VPI fields. If + the specified Input VPI identifies an ATM virtual path + connection (i.e., a single switched virtual path) the state + for that connection is requested. If the specified Input + VPI identifies a virtual path containing virtual channel + connections, the message requests the connection state for + all virtual channel connections that belong to the specified + virtual path. + + Input Label + Field identifies the specific connection for which the + connection state is being requested. For requests that do not + require a connection to be specified, the Input Label field is + not used. + + + + + + + + + + +Doria, et. al. Standards Track [Page 69] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Report Connection State 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Connection Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Input Port + Is the same as the Input Port field in the request message. It + identifies the port number of the input port for which the + connection state is being reported. + + Sequence Number + In the case that the requested connection state cannot be + reported in a single success response message, each successive + success response message, in reply to the same request message, + MUST increment the Sequence Number. The Sequence Number of the + first success response message, in response to a new request + message, MUST be zero. + + Connection Records + Each success response message MUST contain one or more + Connection Records. Each Connection Record specifies a single + point-to-point or point-to-multipoint connection. The number + of Connection Records in a single Report Connection State + success response MUST NOT cause the packet length to exceed the + maximum transmission unit defined by the encapsulation. If the + requested connection state cannot be reported in a single + success response message, multiple success response messages + MUST be sent. All success response messages that are sent in + + + +Doria, et. al. Standards Track [Page 70] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + response to the same request message MUST have the same Input + Port and Transaction Identifier fields as the request message. + A single Connection Record MUST NOT be split across multiple + success response messages. "More" in the Result field of a + response message indicates that one or more further success + response messages should be expected in response to the same + request message. "Success" in the Result field indicates that + the response to the request has been completed. The Result + values are defined in chapter 3.1.1. + + Each Connection Record has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|V|P| Record Count | Record Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Input Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Output Branch Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Flags + + A: All Connections + + V: ATM VPI + For the first Connection Record in each success response + message, the All Connections and the ATM VPI flags MUST be + the same as those of the request message. For successive + Connection Records in the same success response message, + these flags are not used. + + P: ATM VPC + The ATM VPC flag may only be set for ports with + PortType=ATM. The ATM VPC flag, if set and only if set, + indicates that the Connection Record refers to an ATM + virtual path connection. + + Input Label + The input label of the connection specified in this Connection + Record. + + Record Count + Count of Output Branch Records included in a response message. + + + + +Doria, et. al. Standards Track [Page 71] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Record Length + Length in bytes of Output Branch Records field + + Output Branch Records + Each Connection Record MUST contain one or more Output Branch + Records. Each Output Branch Record specifies a single output + branch belonging to the connection identified by the Input + Label field of the Connection Record and the Input Port field + of the Report Connection State message. A point-to-point + connection will require only a single Output Branch Record. A + point-to-multipoint connection will require multiple Output + Branch Records. If a point-to-multipoint connection has more + output branches than can fit in a single Connection Record + contained within a single success response message, that + connection may be reported using multiple Connection Records in + multiple success response messages. + + Each Output Branch Record has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Output Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Output Port + The output port of the switch to which this output branch is + routed. + + Output Label + The output label of the output branch specified in this Output + Branch Record. + + ATM specific procedures: + If this Output Branch Record is part of a Connection Record + that specifies a virtual path connection (the ATM VPC flag + is set) the Output VCI field is unused. + + A Report Connection State request message may be issued regardless of + the Port Status or the Line Status of the target switch port. + + If the Input Port of the request message is valid, and the All + Connections flag is set, but there are no connections established on + that port, a failure response message MUST be returned with the Code + field set to, "10: General Message Failure". For the Report + Connection State message, this failure code indicates that no + + + +Doria, et. al. Standards Track [Page 72] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + connections matching the request message were found. This failure + message SHOULD also be returned if the Input Port of the request + message is valid, the All Connections flag is zero, and no + connections are found on that port matching the specified connection. + +8. Configuration Messages + + 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. + +8.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 switch configuration message. + + The Switch Configuration 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MType | MType | MType | MType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Firmware Version Number | Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Switch Type | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Switch Name | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max Reservations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + + + + +Doria, et. al. Standards Track [Page 73] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + MType + Represents an alternative QoS Configuration type. In the + request message the requested MType is in the most significant + (leftmost) MType byte; the other three MType bytes are unused. + The reply message will either accept the MType request by + including the requested MType in the leftmost MType field of + the response message or it will reject the MType request by + responding with MType=0, the default MType, in the first MType + field. Optionally, in the case of a rejection, the switch + reply can include up to 3 additional MType values, each of + which indicates an available alternative QoS Configuration. A + switch that supports only the default QoS Configuration always + returns MType=0 in all four MType fields. MType negotiation is + discussed in section 8.1.1. + + 0 - Indicates use of the default GSMP model + 1-200 - Reserved + 201-255 - Experimental + + Firmware Version Number + The version number of the switch control firmware installed. + + Window Size + The maximum number of unacknowledged request messages that may + be transmitted by the controller without the possibility of + loss. This field is used to prevent request messages being + lost in the switch because of overflow in the receive buffer. + The field is a hint to the controller. If desired, the + controller may experiment with higher and lower window sizes to + determine heuristically the best window size. + + 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 organisation 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 + + + + + + +Doria, et. al. Standards Track [Page 74] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + of the Switch Name MUST be an Organisationally Unique + Identifier (OUI) that identifies the manufacturer of the + switch. + + Max Reservations + The maximum number of Reservations that the switch can support + (see Chapter 5). A value of 0 indicates that the switch does + not support Reservations. + +8.1.1 Configuration Message Processing + + After adjacency between a controller and after a switch is first + established the controller that opts to use a QoS Configuration model + other then the default would send the Switch Configuration request + including the requested QoS Configuration's MType value in the + request message. This request MUST be sent before any connection + messages are exchanged. If the switch can support the requested QoS + configuration, then the switch includes the requested MType value in + the response message as an indication that it accepts the request. + If the switch cannot support the requested QoS Configuration, it + replaces the MType value in the request message with that of the + default QoS Configuration, i.e., MType=0. + + The switch configuration response messages may additionally include + the MType values of up to three alternative QoS Configurations that + the switch supports and that the controller may choose between. + + The exchange continues until the controller sends a requested MType + that the switch accepts or until it sends a connection request + message. If the exchange ends without confirmation of an alternate + switch model, then the default Mtype=0 is be used. + + Once an MType has been established for the switch, it cannot be + changed without full restart, that is the re-establishment of + adjacency with the resetting of all connections. + +8.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. + + + + + + + +Doria, et. al. Standards Track [Page 75] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Port 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Flags | Port Attribute Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PortType |S|x|x|x|x|x|x|x| Data Fields Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ PortType Specific Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x x x x| Number of Service Specs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + ~ Service Specs List ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + 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 subfields that have meaning to + the physical structure of the switch hardware (e.g., physical + slot and port). This structure may be indicated in the + Physical Slot Number and Physical Port Number fields. + + + + + +Doria, et. al. Standards Track [Page 76] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Event Sequence Number + The Event Sequence Number is set to zero when the port is + initialised. It is incremented by one each time the port + detects an asynchronous event that the switch would normally + report via an Event message. The Event Sequence Number is + explained in section 9. + + Event Flags + Event Flags in a switch port corresponds to a type of Event + message. + + Port Attribute Flags + Port Attribute Flags indicate specific behaviour of a switch + port. The format of the Port Attribute Flags field is given + below: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R: Connection Replace flag + If set, indicates that connections being established by an + Add Branch message with a corresponding R-bit set will + replace any previously established connection if a clash + between the established output branch and the requested + output branch occurs [see chapter 4.2]. + + x: Unused. + + PortType + + 1: PortType is ATM + 2: PortType is FR + 3: PortType is MPLS + + S: Service Model + If set, indicates that Service Model data follows the + PortSpecific port configuration data. + + Data Fields Length + The total length in bytes of the combined PortType Specific + Data and Service Model Data fields. The length of each of + these fields may be derived from the other data so the value of + Data Fields Length serves primarily as a check and to assist + parsing of the All Ports Configuration message success + response. + + + +Doria, et. al. Standards Track [Page 77] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + PortType Specific Data + This field contains the configuration data specific to the + particular port type as specified by the PortType field. The + field format and length also depends on the value of the + PortType. PortType Specific Data is defined below. + + Number of Service Specs + Field contains the total number of Service Specs following in + the remainder of the Port Configuration message response or + Port Configuration Record. + + Service Specs List + The Service Specs correspond to the Input and Output Service + selectors used in Connection Management and Reservation + messages. Specifically they define the possible values used + when the Service Selector (IQS or OQS) is set to 0b10 + indicating the use of the default service specification model + defined in Chapter 10. + + Service Spec + The format of each service spec is given below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service ID | Capability Set ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Each Service Spec identifies a Service supported by the switch + together with the Capability Set ID that identifies the + parameters of that instance of the Service. The Service Spec + List may contain more than one Service Spec sharing the same + Service ID. However, each Service Spec in the Service Specs + List MUST be unique. + + Service ID + Field contains the Service ID of a Service supported on the + port. Service ID values are defined as part of the Service + definition in Chapter 9.6. + + Capability Set ID + Field identifies a Capability Set ID of the Service + specified by the Service ID that is supported on the port. + Capability Set ID values are defined by the Switch in the + Service Configuration response message (see Section 8.4). + The switch MUST NOT return a {Service ID, Capability Set ID} + pair that is not reported in a Service Configuration + response message. + + + +Doria, et. al. Standards Track [Page 78] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +8.2.1 PortType Specific Data + + The length, format and semantics of the PortType Specific Data field + in the Port Configuration message success response and in the Port + Records of the All Port Configuration message success response all + depend on the PortType value of the same message or record + respectively. The specification of the PortType Specific Data field + is given below. For each defined PortType value the Min and Max + Label fields are given in the subsequent subsections. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |P|M|L|R|Q| Label Range Count | Label Range Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Default Label Range Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transmit Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Status | Line Type | Line Status | Priorities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Slot Number | Physical Port Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Where each of the ranges in the Default Label Range Blocks will have + the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|C| | + +-+-+-+-+ Min Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| | + +-+-+-+-+ Max Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Doria, et. al. Standards Track [Page 79] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Flags + + P: VP Switching + The ATM VPC flag may only be set for ports with + PortType=ATM. The VP Switching flag, if set, indicates that + this input port is capable of supporting virtual path + switching. Else, if zero, it indicates that this input port + is only capable of virtual channel switching. + + M: Multicast Labels + The Multicast Labels flag, if set, indicates that this + output port is capable of labelling each output branch of a + point-to-multipoint tree with a different label. If zero, + it indicates that this output port is not able to label each + output branch of a point-to-multipoint tree with a different + label. + + L: Logical Multicast + The Logical Multicast flag, if set, indicates that this + output port is capable of supporting more than a single + branch from any point-to-multipoint connection. This + capability is often referred to as logical multicast. If + zero, it indicates that this output port can only support a + single output branch from each point-to-multipoint + connection. + + R: Label Range + The Label Range flag, if set, indicates that this switch + port is capable of reallocating its label range and + therefore accepts the Label Range message. Else, if zero, + it indicates that this port does not accept Label Range + messages. + + Q: QoS + The QoS flag, if set, indicates that this switch port is + capable of handling the Quality of Service messages defined + in section 9 of this specification. Else, if zero, it + indicates that this port does not accept the Quality of + Service messages. + + V: Label + The Label flag is port type specific. + + C: Multipoint Capable + This flag indicates that the label range may be used for + multipoint connections. + + + + + +Doria, et. al. Standards Track [Page 80] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Label Range Count + The total number of Default Label Range elements contained in + the Default Label Range Block. + + Label Range Length + Byte count in the Default Label Range Block. + + Min Label + The specification of the Min Label field for each defined + PortType value is given in the subsequent subsections. The + default minimum value of a dynamically assigned incoming label + that the connection table on the input port supports and that + may be controlled by GSMP. This value is not changed as a + result of the Label Range message. + + Max Label + The specification of the Max Label field for each defined + PortType value is given in the subsequent subsections. The + default maximum value of a dynamically assigned incoming label + that the connection table on the input port supports and that + may be controlled by GSMP. This value is not changed as a + result of the Label Range message. + + Receive Data Rate + + The maximum rate of data that may arrive at the input port in; + + cells/s for PortType = ATM + bytes/s for PortType = FR + bytes/s for PortType = MPLS + + Transmit Data Rate + + The maximum rate of data that may depart from the output port + in; + + cells/s for PortType = ATM + bytes/s for PortType = FR + bytes/s for PortType = MPLS + + (The transmit data rate of the output port may be changed by + the Set Transmit Data Rate function of the Port Management + message.) + + Port Status + Gives the administrative state of the port. The defined values + of the Port Status field are: + + + + +Doria, et. al. Standards Track [Page 81] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Available: + Port Status = 1. The port is available to both send and + receive cells or frames. When a port changes to the + Available state from any other administrative state, all + dynamically assigned 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 or frames will be transmitted from + this port. No cells or frames 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 or frames + 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 functions of the input port above the + physical layer, e.g., header translation, are performed upon + the looped back cells or frames. + + External Loopback: + Port Status = 4. The port has intentionally been taken out + of service and is in external loopback: cells or frames + 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 functions of the input port above the physical layer + are performed upon the looped back cells or frames. + + Bothway Loopback: + Port Status = 5. The port has intentionally been taken out + of service and is in both internal and external loopback. + + The Port Status of the port over which the GSMP session + controlling the switch is running MUST be declared Available. + The controller will ignore any other Port status for this port. + The Port Status of switch ports after power-on initialisation + is not defined by GSMP. + + Line Type + The type of physical transmission interface for this port. The + values for this field are defined by the IANAifType's specified + in [17]. + + + + + + +Doria, et. al. Standards Track [Page 82] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The following values are identified for use in this version + of the protocol. + + PortType = Unknown: other(1) + PortType = MPLS: ethernetCsmacd(6), + ppp(23) + PortType = ATM: atm(37) + PortType = FR: frameRelayService(44) + + 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. 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 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 priority levels that this output port + can assign to connections. Zero is invalid in this field. If + an output port is able to support "Q" 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 connections that share the same output port, a + cell or frame on a connection with a higher priority is much + more likely to exit the switch before a cell or frame on a + connection with a lower priority if they are both in the switch + at the same time. + + Physical Slot Number + The physical location of the slot in which the port is located. + It is an unsigned 16-bit integer that can take any value except + 0xFFFF. The value 0xFFFF is used to indicate "unknown". The + Physical Slot Number is not used by the GSMP protocol. It is + provided to assist network management in functions such as + logging, port naming, and graphical representation. + + + +Doria, et. al. Standards Track [Page 83] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Physical Port Number + The physical location of the port within the slot in which the + port is located. It is an unsigned 16-bit integer that can + take any value except 0xFFFF. The value 0xFFFF is used to + indicate "unknown". The Physical Port Number is not used by + the GSMP protocol. It is provided to assist network management + in functions such as logging, port naming, and graphical + representation. + + There MUST be a one to one mapping between the Port Number and + the Physical Slot Number and Physical Port Number combination. + Two different Port Numbers MUST NOT yield the same Physical + Slot Number and Physical Port Number combination. The same + Port Number MUST yield the same Physical Slot Number and + Physical Port Number within a single GSMP session. If both + Physical Slot Number and Physical Port Number indicate + "unknown" the physical location of switch ports may be + discovered by looking up the product identity in a database to + reveal the physical interpretation of the 32-bit Port Number. + +8.2.1.1 PortType Specific data for PortType=ATM + + If PortType=ATM, the Default Label Range Block 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|V|x| ATM Label (0x100) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x| VPI | VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + V: Label + If the Label flag is set, the message refers to a range of + VPI's only. The Min VCI and Max VCI fields are unused. If the + Label flag is zero the message refers to a range of VCI's on + either one VPI or on a range of VPI's. + + Min VPI + The default minimum value of dynamically assigned incoming VPI + that the connection table on the input port supports and that + may be controlled by GSMP. + + Max VPI + The default maximum value of dynamically assigned incoming VPI + that the connection table on the input port supports and that + may be controlled by GSMP. + + + +Doria, et. al. Standards Track [Page 84] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + At power-on, after a hardware reset, and after the Reset Input + Port function of the Port Management message, the input port + MUST handle all values of VPI within the range Min VPI to Max + VPI inclusive and GSMP MUST be able to control all values + within this range. It should be noted that the range Min VPI + to Max VPI refers only to the incoming VPI range that can be + supported by the associated port. No restriction is placed on + the values of outgoing VPI's that may be written into the cell + header. 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. + + Use of the Label Range message allows the range of VPI's + supported by the port to be changed. However, the Min VPI and + Max VPI fields in the Port Configuration and All Ports + Configuration messages always report the same default values + regardless of the operation of the Label Range message. + + Min VCI + The default minimum value of a dynamically assigned incoming + VCI that the connection table on the input port can support and + may be controlled by GSMP. This value is not changed as a + result of the Label Range message. + + Max VCI + The default maximum value of a dynamically assigned incoming + VCI that the connection table on the input port can support and + may be controlled by GSMP. + + At power-on, after a hardware reset, and after the Reset Input + Port function of the Port Management message, the input port + MUST 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 GSMP MUST be able to control all + values within this range. It should be noted that the range + Min VCI to Max VCI refers only to the incoming VCI range that + can be supported by the associated port on each of the virtual + paths in the range Min VPI to Max VPI. No restriction is + placed on the values of outgoing VCI's that may be written into + the cell header. Use of the Label Range message allows the + range of VCI's to be changed on each VPI supported by the port. + However, the Min VCI and Max VCI fields in the Port + Configuration and All Ports Configuration messages always + report the same default values regardless of the operation of + the Label Range message. + + + + + + +Doria, et. al. Standards Track [Page 85] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + For a port over which the GSMP protocol is operating, the VCI of the + GSMP control channel may or may not be reported as lying within the + range Min VCI to Max VCI. A switch should honour a connection + request message that specifies the VCI value of the GSMP control + channel even if it lies outside the range Min VCI to Max VCI + +8.2.1.2 PortType Specific data for PortType=FR + + If PortType=FR, the Default Label Range Block 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| FR Label (0x101) | Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x|Res|Len| DLCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Res + The Res field is reserved in [21], i.e., it is not explicitly + reserved by GSMP. + + Len + This field specifies the number of bits of the DLCI. The + following values are supported: + + Len DLCI bits + 0 10 + 2 23 + + Min DLCI, Max DLCI + Specify a range of DLCI values, Min DLCI to Max DLCI inclusive. + The values SHOULD be right justified in the 23-bit fields and + the preceding bits SHOULD be set to zero. A single DLCI may be + specified with a Min DLCI and a Max DLCI having the same value. + In a request message, if the value of the Max DLCI field is + less than or equal to the value of the Min DLCI field, the + requested range is a single DLCI with a value equal to the Min + DLCI field. Zero is a valid value. + + + + + + + + + + + +Doria, et. al. Standards Track [Page 86] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +8.2.1.3 PortType Specific data for PortType=MPLS + + The Default Label Range Block for PortTypes using MPLS labels. These + types of labels are for use on links for which label values are + independent of the underlying link technology. Examples of such + links are PPP and Ethernet. On such links the labels are carried in + MPLS label stacks [14]. Ports of the Type MPLS 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x| MPLS Gen Label (0x102)| Label Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|x|x|x|x|x|x|x|x|x|x|x| MPLS Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Min MPLS Label, Max MPLS Label + Specify a range of MPLS label values, Min MPLS Label to Max + MPLS Label inclusive. The Max and Min MPLS label fields are 20 + bits each. + +8.2.1.4 PortType Specific data for PortType=FEC + + The Default Label Range Block for PortTypes using FEC labels is not + used. The Label Range Count and Label Range Length fields defined in + [8.2.1] should be set to 0. + +8.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. + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 87] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x x x x| Number of Records | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Port Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Number of Records + Field gives the total number of Port Records to be returned in + response to the All Ports Configuration request message. The + number of port records in a single All Ports Configuration + success response MUST NOT cause the packet length to exceed the + maximum transmission unit defined by the encapsulation. If a + switch has more ports than can be sent in a single success + response message it MUST send multiple success response + messages. All success response messages that are sent in + response to the same request message MUST have the same + Transaction Identifier as the request message and the same + value in the Number of Records field. All success response + messages that are sent in response to the same request message, + except for the last message, MUST have the result field set to + "More". The last message, or a single success response + message, MUST have the result field set to "Success". All Port + records within a success response message MUST be complete, + i.e., a single Port record MUST NOT be split across multiple + success response messages. + + + + + + + + + +Doria, et. al. Standards Track [Page 88] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Flags | Port Attribute Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PortType |S|x|x|x|x|x|x|x| Data Fields Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ PortType Specific Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x x x x| Number of Service Specs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Service Specs List ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The definition of the fields in the Port Record is exactly the same + as that of the Port Configuration message [section 8.2]. + +8.4 Service Configuration Message + + The Service Configuration message requests the switch for the + configuration information of the Services that are supported. The + Service Configuration message is: + + Message Type = 67 + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 89] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Service 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x x x x| Number of Service Records | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Service Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + Number of Service Records + Field gives the total number of Service Records to be returned + in the Service Records field. + + Service Records + A sequence of zero or more Service Records. The switch returns + one Service Record for each Service that it supports on any of + its ports. A Service record contains the configuration data of + the specified Service. Each Service 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service ID | Number of Cap. Set. Records | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Capability Set Records ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Service ID + The Service ID Field identifies the Service supported by the + port. The Services are defined with their Service ID values as + described in section 10.2. + + + +Doria, et. al. Standards Track [Page 90] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Number of Cap. Set. Records + Field gives the total number of Capability Set Records to be + returned in the Service Record field. + + Capability Set Records + The switch returns one or more Capability Set Records in each + Service Record. A Capability Set contains a set of parameters + that describe the QoS parameter values and traffic controls + that apply to an instance of the Service. Each Capability Set + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cap. Set ID | Traffic Controls | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CLR | CTD | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Frequency | CDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Capability Set ID + The value in this Field defines a Capability Set ID supported + by the switch. The values of a Capability Set ID are assigned + by the switch and used in Port Configuration messages to + identify Capability Sets supported by individual ports. Each + Capability Set Record within a Service Record MUST have a + unique Capability Set ID. + + Traffic Controls + Field identifies the availability of Traffic Controls within + the Capability Set. Traffic Controls are defined as part of + the respective Service definition, see Chapter 10. Some or all + of the Traffic Controls may be undefined for a given Service, + in which case the corresponding Flag is ignored by the + controller. The Traffic Controls field is formatted into + Traffic Control Sub-fields as follows: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | U | D | I | E | S | V |x x x x| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Traffic Control Sub-fields have the following encoding: + + 0b00 Indicates that the Traffic Control is not available in + the Capability Set. + + + +Doria, et. al. Standards Track [Page 91] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 0b01 Indicates that the Traffic Control is applied to all + connections that use the Capability Set. + + 0b10 Indicates that the Traffic Control is available for + application to connections that use the Capability Set + on a per connection basis. + + 0b11 Reserved + + Traffic Control Sub-fields: + + U: Usage Parameter Control + The Usage Parameter Control sub-field indicates the + availability of Usage Parameter Control for the + specified Service and Capability Set. + + D: Packet Discard + The Packet Discard sub-field indicates the availability + of Packet Discard for the specified Service and + Capability Set. + + I: Ingress Shaping + The Ingress Shaping sub-field indicates the + availability of Ingress Traffic Shaping to the Peak + Cell Rate and Cell Delay Variation Tolerance for the + specified Service and Capability Set. + + E: Egress Shaping, Peak Rate + The Egress Shaping, Peak Rate sub-field indicates the + availability of Egress Shaping to the Peak Cell Rate + and Cell Delay Variation Tolerance for the specified + Service and Capability Set. + + S: Egress Traffic Shaping, Sustainable Rate + The Egress Shaping, Sustainable Rate sub-field, if set, + indicates that Egress Traffic Shaping to the + Sustainable Cell Rate and Maximum Burst Size is + available for the specified Service and Capability Set. + + V: VC Merge + The VC Merge sub-field indicates the availability of + ATM Virtual Channel Merge (i.e., multipoint to point + ATM switching with a traffic control to avoid AAL5 PDU + interleaving) capability for the specified Service and + Capability Set. + + + + + + +Doria, et. al. Standards Track [Page 92] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + QoS Parameters + The remaining four fields in the Capability Set Record contain + the values of QoS Parameters. QoS Parameters are defined as + part of the respective Service definition, see Chapter 9.6. + Some or all of the QoS Parameters may be undefined for a given + Service, in which case the corresponding field is ignored by + the controller. + + CLR: Cell Loss Ratio + The Cell Loss Ratio parameter indicates the CLR + guaranteed by the switch for the specified Service. A + cell loss ratio is expressed as an order of magnitude + n, where the CLR takes the value of ten raised to the + power of -n, i.e., log(CLR)=-n. The value n is coded + as a binary integer, having a range of 1 <= n <= 15. + In addition, the value 0b1111 1111 indicates that no + CLR guarantees are given. + + Frequency + The frequency field is coded as an 8 bit unsigned + integer. Frequency applies to the MPLS CR-LDP Service + (see Section 10.4.3). Valid values of Frequency are: + + 0 - Very frequent + 1 - Frequent + 2 - Unspecified + + CTD: Cell Transfer Delay + The CTD value is expressed in units of microseconds. + It is coded as a 24-bit integer. + + CDV: Peak-to-peak Cell Delay Variation + The CDV value is expressed in units of microseconds. + It is coded as a 24-bit integer. + +9. Event Messages + + Event messages allow the switch to inform the controller of certain + asynchronous events. By default the controller does not acknowledge + event messages unless ReturnReceipt is set in the Result field. The + Code field is only used in case of Adjacency Update message, + otherwise it is not used and SHOULD be set to zero. Event messages + are not sent during initialisation. Event messages have the + following format: + + + + + + + +Doria, et. al. Standards Track [Page 93] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Transaction Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I| SubMessage Number | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Port Session Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Event Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x| | + +-+-+-+-+ Label | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Fields and Parameters that have been explained in the + description of the general messages will not be explained in + this section. Please refer to section 3.1 for details. + + 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 initialised. It is incremented by one each time + the port detects an asynchronous event 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. + + Label + Field gives the Label 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 sends an Event message it MUST set the Event Flag for that + port corresponding to the Event type. If Flow Control is activated + for this Event type for this Port then the switch MUST NOT send + another Event message of the same type for that port 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 + + + +Doria, et. al. Standards Track [Page 94] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 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. + +9.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 Label + field is not used and is set to zero. The Port Up message is: + + Message Type = 80 + +9.2 Port Down Message + + The Port Down message informs the controller that the Line Status of + a port has changed from the Up state or Test 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 Label field is not used and is set to zero. The + Port Down message is: + + Message Type = 81 + +9.3 Invalid Label Message + + The Invalid Label message is sent to inform the controller that one + or more cells or frames have arrived at an input port with a Label + that is currently not allocated to an assigned connection. The input + port is indicated in the Port field, and the Label in the Label + field. The Invalid Label message is: + + Message Type = 82 + + + + + + + + + + + +Doria, et. al. Standards Track [Page 95] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +9.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 Label field is not used and is set to zero. The New + Port message is: + + Message Type = 83 + +9.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 Label + fields are not used and are set to zero. The Dead Port message is: + + Message Type = 84 + +9.6 Adjacency Update Message + + The Adjacency Update message informs the controller when adjacencies, + i.e., other controllers controlling a specific partition, are joining + or leaving. When a new adjacency has been established, the switch + sends an Adjacency Update message to every controller with an + established adjacency to that partition. The Adjacency Update + message is also sent when adjacency is lost between the partition and + a controller, provided that there are any remaining adjacencies with + that partition. The Code field is used to indicate the number of + adjacencies known by the switch partition. The Label field is not + used and SHOULD be set to zero. The Adjacency Update message is: + + Message Type = 85 + +10. Service Model Definition + +10.1 Overview + + In the GSMP Service Model a controller may request the switch to + establish a connection with a given Service. The requested Service + is identified by including a Service ID in the Add Branch message or + the Reservation Message. The Service ID refers to a Service + Definition provided in this chapter of the GSMP specification. + + + + + +Doria, et. al. Standards Track [Page 96] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + A switch that implements one or more of the Services, as defined + below, advertises the availability of these Services in the Service + Configuration message response (see Section 8.4). Details of the + switch's implementation of a given Service that are important to the + controller (e.g., the value of delay or loss bounds or the + availability of traffic controls such as policers or shapers) are + reported in the form of a Capability Set in the Service Configuration + message response. + + Thus a switch's implementation of a Service is defined in two parts: + the Service Definition, which is part of the GSMP specification, and + the Capability Set, which describes attributes of the Service + specific to the switch. A switch may support more than one + Capability Set for a given Service. For example if a switch supports + one Service with two different values of a delay bound it could do + this by reporting two Capability Sets for that Service. + + The Service Definition is identified in GSMP messages by the Service + ID, a sixteen-bit identifier. Assigned numbers for the Service ID + are given with the Service Definitions in Section 10.4. The + Capability Set is identified in GSMP messages by the Capability Set + ID, a sixteen-bit identifier. Numbers for the Capability Set ID are + assigned by the switch and are advertised in the Service + Configuration message response. + + The switch reports all its supported Services and Capability Sets in + the Service Configuration message response. The subset of Services + and Capability Sets supported on an individual port is reported in + the Port Configuration message response or in the All Ports + Configuration message response. In these messages the Services and + Capability Sets supported on the specified port are indicated by a + list of {Service ID, Capability Set ID} number pairs. + +10.2 Service Model Definitions + + Terms and objects defined for the GSMP Service Model are given in + this section. + +10.2.1 Original Specifications + + Services in GSMP are defined largely with reference to Original + Specifications, i.e., the standards or implementation agreements + published by organisations such as ITU-T, IETF, and ATM Forum that + originally defined the Service. This version of GSMP refers to 4 + original specifications: [8], [9], [10] and [11]. + + + + + + +Doria, et. al. Standards Track [Page 97] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +10.2.2 Service Definitions + + Each Service Definition in GSMP includes definition of: + + Traffic Parameters + Traffic Parameter definitions are associated with Services + while Traffic Parameter values are associated with connections. + + Traffic Parameters quantitatively describe a connection's + requirements on the Service. For example, Peak Cell Rate is a + Traffic Parameter of the Service defined by the ATM Forum + Constant Bit Rate Service Category. + + Some Traffic Parameters are mandatory and some are optional, + depending on the Service. + + Semantics of Traffic Parameters are defined by reference to + Original Specifications. + + QoS Parameters + QoS Parameters and their values are associated with Services. + + QoS Parameters express quantitative characteristics of a + switch's support of a Service. They include, for example, + quantitative bounds on switch induced loss and delay. + + Some QoS Parameters will be mandatory and some will be + optional. + + Semantics of QoS Parameters are defined by reference to + Original Specifications. + + Traffic Controls + The implementation of some Services may include the use of + Traffic Controls. Traffic Controls include, for example + functions such as policing, input shaping, output shaping, + tagging and marking, frame vs. cell merge, frame vs. cell + discard. + + Switches are not required to support Traffic Controls. Any + function that is always required in the implementation of a + Service is considered part of the Service and is not considered + a Traffic Control. + + If a switch supports a Traffic Control then the control may be + applied either to all connections that use a given Capability + Set (see below) or to individual connections. + + + + +Doria, et. al. Standards Track [Page 98] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The definition of a Traffic Control is associated with a + Service. Traffic Controls are defined, as far as possible, by + reference to Original Specifications. + +10.2.3 Capability Sets + + For each Service that a switch supports the switch MUST also support + at least one Capability Set. A Capability Set establishes + characteristics of a switch's implementation of a Service. It may be + appropriate for a switch to support more than one Capability Set for + a given Service. + + A Capability Set may contain, depending on the Service definition, + QoS Parameter values and an indication of availability of Traffic + Controls. + + If a switch reports QoS Parameter values in a Capability Set then + these apply to all the connections that use that Capability Set. + + For each Traffic Control defined for a given Service the switch + reports availability of that control as one of the following: + + Not available in the Capability Set, + + Applied to all connections that use the Capability Set, or + + Available for application to connections that use the Capability + Set on a per connection basis. In this case, a controller may + request application of the Traffic Control in connection + management messages. + +10.3 Service Model Procedures + + A switch's Services and Capability Sets are reported to a controller + in a Service Configuration message. A Service Configuration message + response includes the list of Services defined for GSMP that the + switch supports and, for each Service, a specification of the + Capability Sets supported for the Service. Services are referred to + by numbers standardised in the GSMP specification. Capability Sets + are referred to by a numbering system reported by the switch. Each + Capability Set within a given Service includes a unique identifying + number together with the switch's specification of QoS Parameters and + Traffic Controls. + + A switch need not support all the defined Services and Capability + Sets on every port. The supported Services and Capability Sets are + reported to the controller on a per port basis in port configuration + messages. Port configuration response messages list the supported + + + +Doria, et. al. Standards Track [Page 99] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Services using the standardised identifying numbers and the + Capability Sets by using the identifying numbers established in the + switch Service configuration messages. + + GSMP does not provide a negotiation mechanism by which a controller + may establish or modify Capability Sets. + + When a controller establishes a connection, the connection management + message includes indication of the Service and the Capability Set. + Depending on these the connection management message may additionally + include Traffic Parameter values and Traffic Control flags. + + A connection with a given Service can only be established if both the + requested Service and the requested Capability Set are available on + all of the connection's input and output ports. + + Refresh of an extant connection is permitted but the add branch + message requesting the message MUST NOT include indication of + Service, Capability Sets or Traffic Parameters. + + An extant connection's Traffic Parameters may be changed without + first deleting the connection. The Service and Capability Sets of an + extant connection cannot be changed. + + Move branch messages may be refused on the grounds of resource + depletion. + +10.4 Service Definitions + + This section sets forth the definition of Services. The following + Service Identifiers are defined: + + ID Service Type + + 1 CBR= 1 + 2 rt-VBR.1 + 3 rt-VBR.2 + 4 rt-VBR.3 + 5 nrt-VBR.1 + 6 nrt-VBR.2 + 7 nrt-VBR.3 + 8 UBR.1 + 9 UBR.2 + 10-11 Reserved + 12 GFR.1 + 13 GFR.2 + 14-19 Reserved + 20 Int-Serv Controlled Load + + + +Doria, et. al. Standards Track [Page 100] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 21-24 Reserved + 25 MPLS CR-LDP QoS + 26-29 Reserved + 30 Frame Relay Service + 31-49 Reserved + 50-69 Reserved GMPLS + 70-65535 Reserved + + Each Service will be defined in its own subsection. Each Service + definition includes the following definitions: + + Service Identifier + The reference number used to identify the Service in GSMP + messages. + + Service Characteristics + A definition of the Service. + + Traffic Parameters + A definition of the Traffic Parameters used in connection + management messages. + + QoS Parameters + A definition of the QoS Parameters that are included in the + Capability Set for instances of the Service. + + Traffic Controls + A definition of the Traffic Controls that may be supported by + an instance of the Service. + + Descriptive text is avoided wherever possible in order to minimise + any possibility of semantic conflict with the Original + Specifications. + +10.4.1 ATM Forum Service Categories + +10.4.1.1 CBR + + Service Identifier: + CBR.1 - Service ID = 1 + + Service Characteristics: + Equivalent to ATM Forum CBR.1 Service, see [8]. + + Traffic Parameters: + - Peak Cell Rate + - Cell Delay Variation Tolerance + + + + +Doria, et. al. Standards Track [Page 101] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + QoS Parameters: + - Cell Loss Ratio + - Maximum Cell Transfer Delay + - Peak-to-peak Cell Delay Variation + + Traffic Controls: + - (U) Usage Parameter Control + - (I) Ingress Traffic Shaping to the Peak Cell Rate + - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay + Variation Tolerance + - (D) Packet Discard + +10.4.1.2 rt-VBR + + Service Identifier: + rt-VBR.1 - Service ID = 2 + rt-VBR.2 - Service ID = 3 + rt-VBR.3 - Service ID = 4 + + Service Characteristics: + Equivalent to ATM Forum rt-VBR Service, see [8]. + + Traffic Parameters: + - Peak Cell Rate + - Cell Delay Variation Tolerance + - Sustainable Cell Rate + - Maximum Burst Size + + QoS Parameters: + - Cell Loss Ratio + - Maximum Cell Transfer Delay + - Peak-to-peak Cell Delay Variation + + Traffic Controls: + - (U) Usage Parameter Control + - (I) Ingress Traffic Shaping to the Peak Cell Rate + - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay + Variation Tolerance + - (S) Egress Traffic Shaping to the Sustainable Cell Rate and + Maximum Burst Size + - (P) Packet Discard + - (V) VC Merge + + + + + + + + + +Doria, et. al. Standards Track [Page 102] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +10.4.1.3 nrt-VBR + + Service Identifier: + nrt-VBR.1 - Service ID = 5 + nrt-VBR.2 - Service ID = 6 + nrt-VBR.3 - Service ID = 7 + + Service Characteristics: + Equivalent to ATM Forum nrt-VBR Service, see [8]. + + Traffic Parameters: + - Peak Cell Rate + - Cell Delay Variation Tolerance + - Sustainable Cell Rate + - Maximum Burst Size + + QoS Parameter: + - Cell Loss Ratio + + Traffic Controls: + - (U) Usage Parameter Control + - (I) Ingress Traffic Shaping to the Peak Cell Rate + - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay + Variation Tolerance + - (S) Egress Traffic Shaping to the Sustainable Cell Rate and + Maximum Burst Size + - (P) Packet Discard + - (V) VC Merge + +10.4.1.4 UBR + + Service Identifier: + UBR.1 - Service ID = 8 + UBR.2 - Service ID = 9 + + Service Characteristics: + Equivalent to ATM Forum UBR Service, see [8]. + + Traffic Parameters: + - Peak Cell Rate + - Cell Delay Variation Tolerance + + QoS Parameter: + None + + Traffic Controls: + - (U) Usage Parameter Control + - (I) Ingress Traffic Shaping to the Peak Cell Rate + + + +Doria, et. al. Standards Track [Page 103] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay + Variation Tolerance + - (P) Packet Discard + - (V) VC Merge + +10.4.1.5 ABR + + ABR is not supported in this version of GSMP. + +10.4.1.6 GFR + + Service Identifier: + GFR.1 - Service ID = 12 + GFR.2 - Service ID = 13 + + Service Characteristics: + Equivalent to ATM Forum GFR Service, see [8]. + + Traffic Parameters: + - Peak Cell Rate + - Cell Delay Variation Tolerance + - Minimum Cell Rate + - Maximum Burst Size + - Maximum Frame Size + + QoS Parameter: + - Cell Loss Ratio + + Traffic Controls: + - (U) Usage Parameter Control + - (I) Ingress Traffic Shaping to the Peak Cell Rate + - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay + Variation Tolerance + - (V) VC Merge + +10.4.2 Integrated Services + +10.4.2.1 Controlled Load + + Service Identifier: + Int-Serv Controlled Load - Service ID = 20 + + Service Characteristics: + See [9]. + + + + + + + +Doria, et. al. Standards Track [Page 104] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Traffic Parameters: + - Token bucket rate (r) + - Token bucket depth (b) + - Peak rate (p) + - Minimum policed unit (m) + - Maximum packet size (M) + + QoS Parameter: + None. + + Traffic Controls: + None. + +10.4.3 MPLS CR-LDP + + Service Identifier: + MPLS CR-LDP QoS - Service ID = 25 + + Service Characteristics: + See [10]. + + Traffic Parameters: + - Peak Data Rate + - Peak Burst Size + - Committed Data Rate + - Committed Burst Size + - Excess Burst Size + - Weight + + QoS Parameter: + - Frequency + + Traffic Controls: + None currently defined. + +10.4.4 Frame Relay + + Service Identifier: + Frame Relay Service - Service ID = 30 + + Service Characteristics: + Equivalent to Frame Relay Bearer Service, see [11]. + + Traffic Parameters: + - Committed Information Rate + - Committed Burst Rate + - Excess Burst Rate + + + + +Doria, et. al. Standards Track [Page 105] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + QoS Parameters: + None. + + Traffic Controls: + - Usage Parameter Control + - Egress Traffic Shaping to the Committed Information Rate and + Committed Burst Size + +10.4.5 DiffServ + + DiffServ is not supported in this version of GSMP. + +10.5 Format and encoding of the Traffic Parameters + + Connection management messages that use the GSMP Service Model (i.e., + those that have IQS or OQS set to 0b10) include the Traffic + Parameters Block that specifies the Traffic Parameter values of a + connection. The required Traffic Parameters of a given Service are + given in Section 10.4. The format and encoding of these parameters + are given below. + +10.5.1 Traffic Parameters for ATM Forum Services + + The Traffic Parameters: + + - Peak Cell Rate + + - Cell Delay Variation Tolerance + + - Sustainable Cell Rate + + - Maximum Burst Size + + - Minimum Cell Rate + + - Maximum Frame Size + + are defined in [8]. These Parameters are encoded as 24-bit unsigned + integers. Peak Cell Rate, Sustainable Cell Rate, and Minimum Cell + Rate are in units of cells per second. Cell Delay Variation + Tolerance is in units of microseconds. Maximum Burst Size and + Maximum Frame Size are in units of cells. In GSMP messages, the + individual Traffic Parameters are encoded as follows: + + + + + + + + +Doria, et. al. Standards Track [Page 106] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x| 24 bit unsigned integer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format of the Traffic Parameters Block in connection management + messages depends on the Service. It is a sequence of the 32 bit + words (as shown above) corresponding to the Traffic Parameters as + specified in the Service Definitions given in Section 10.4.1 in the + order given there. + +10.5.2 Traffic Parameters for Int-Serv Controlled Load Service + + The Traffic Parameters: + + - Token bucket rate (r) + + - Token bucket size (b) + + - Peak rate (p) + + are defined in [9]. They are encoded as 32-bit IEEE single-precision + floating point numbers. The Traffic Parameters Token bucket rate (r) + and Peak rate (p) are in units of bytes per seconds. The Traffic + Parameter Token bucket size (b) is in units of bytes. + + The Traffic Parameters: + + - Minimum policed unit (m) + + - Maximum packet size (M) + + are defined in [9]. They are encoded as 32 integer in units of + bytes. + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 107] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Traffic Parameters Block for the Int-Serv Controlled Load Service + is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Token bucket rate (r) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Token bucket size (b) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peak rate (p) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Minimum policed unit (m) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum packet size (M) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +10.5.3 Traffic Parameters for CRLDP Service + + The Traffic Parameters: + + - Peak Data Rate + + - Peak Burst Size + + - Committed Data Rate + + - Committed Burst Size + + - Excess Burst Size + + are defined in [10] to be encoded as a 32-bit IEEE single-precision + floating point number. A value of positive infinity is represented + as an IEEE single-precision floating-point number with an exponent of + all ones (255) and a sign and mantissa of all zeros. The values Peak + Data Rate and Committed Data Rate are in units of bytes per second. + The values Peak Burst Size, Committed Burst Size and Excess Burst + Size are in units of bytes. + + The Traffic Parameter + + - Weight + + is defined in [10] to be an 8-bit unsigned integer indicating the + weight of the CRLSP. Valid weight values are from 1 to 255. The + value 0 means that weight is not applicable for the CRLSP. + + + + + +Doria, et. al. Standards Track [Page 108] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + The Traffic Parameters Block for the CRLDP Service is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peak Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peak Burst Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Committed Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Committed Burst Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Excess Burst Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x x x x x x x x x x x x| Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +10.5.4 Traffic Parameters for Frame Relay Service + + The Traffic Parameters: + + - Committed Information Rate + + - Committed Burst Size + + - Excess Burst Size + + are defined in [11]. Format and encoding of these parameters for + frame relay signalling messages are defined in [12]. (Note than in + [12] the Committed Information Rate is called "Throughput".) GSMP + uses the encoding defined in [12] but uses a different format. + + The format of the Traffic Parameters Block for Frame Relay Service is + as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x| Mag |x x x x x| CIR Multiplier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x| Mag |x x| CBS Multiplier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x x x x x x x x x x x x x| Mag |x x| EBS Multiplier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Doria, et. al. Standards Track [Page 109] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Mag + This field is an unsigned integer in the range from 0 to 6. + The value 7 is not allowed. Mag is the decimal exponent for + the adjacent multiplier field (which itself functions as a + mantissa). + + CIR Multiplier + This field is an unsigned integer. It functions as the + mantissa of the Committed Information Rate Traffic Parameter. + + CBS Multiplier + EBS Multiplier + These fields are unsigned integers. They function as the + mantissas of the Committed Burst Size and Excess Burst Size + Traffic Parameters respectively. + + The Traffic Parameter Values are related to their encoding in GSMP + messages as follows: + + Committed Information Rate = 10^(Mag) * (CIR Multiplier) + + Committed Burst Size = 10^(Mag) * (CBS Multiplier) + + Excess Burst Size = 10^(Mag) * (EBS Multiplier) + +10.6 Traffic Controls (TC) Flags + + The TC Flags field in Add Branch messages for connections using the + Service Model are set by the controller to indicate that specific + traffic controls are requested for the requested connection. The TC + Flags field is shown below: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |U|D|I|E|S|V|P|x| + +-+-+-+-+-+-+-+-+ + + U: Usage Parameter Control + When set, this flag indicates that Usage Parameter Control + is requested. + + D: Packet Discard + When set, this flag indicates that Packet Discard is + requested. + + + + + + + +Doria, et. al. Standards Track [Page 110] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + I: Ingress Shaping + When set, this flag indicates the availability of Ingress + Traffic Shaping to the Peak Rate and Delay Variation + Tolerance is requested. + + E: Egress Shaping, Peak Rate + When set, this flag indicates that Egress Shaping to the + Peak Rate and Delay Variation Tolerance is requested. + + S: Egress Traffic Shaping, Sustainable Rate + When set, this flag indicates that Egress Traffic Shaping to + the Sustainable Rate and Maximum Burst Size is requested. + + V: VC Merge + When set, this flag indicates that ATM Virtual Channel Merge + (i.e., multipoint to point ATM switching with a traffic + control to avoid AAL5 PDU interleaving) is requested. + + P: Port + When set indicates that traffic block pertains to Ingress + Port. + + x: Reserved + + The controller may set (to one) the flag corresponding to the + requested Traffic Control if the corresponding Traffic Control has + been indicated in the Service Configuration response message (Section + 8.4) as available for application to connections that use the + requested Capability Set on a per connection basis. (The requested + Capability Set is indicated by the Capability Set ID the least + significant byte of the Service Selector field of the Add Branch + message.) If the Traffic Control has been indicated in the Service + Configuration response message as either not available in the + Capability Set or applied to all connections that use the Capability + Set then the controller sets the flag to zero and the switch ignores + the flag. + +11. Adjacency Protocol + + The adjacency protocol is used to synchronise state across the link, + to agree on which version of the protocol to use, to discover the + identity of the entity at the other end of a link, and to detect when + it changes. GSMP is a hard state protocol. It is therefore + important to detect loss of contact between switch and controller, + and to detect any change of identity of switch or controller. No + GSMP messages other than those of the adjacency protocol may be sent + across the link until the adjacency protocol has achieved + synchronisation. + + + +Doria, et. al. Standards Track [Page 111] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +11.1 Packet Format + + All GSMP messages belonging to the adjacency protocol have the + following structure: + + 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 | Timer |M| Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Name | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Receiver Name | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receiver Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PType | PFlag | Sender Instance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Partition ID | Receiver Instance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version + In the adjacency protocol the Version field is used for version + negotiation. The version negotiation is performed before + synchronisation is achieved. In a SYN message the Version + field always contains the highest version understood by the + sender. A receiver receiving a SYN message with a version + higher than understood will ignore that message. A receiver + receiving a SYN message with a version lower than its own + highest version, but a version that it understands, will reply + with a SYNACK with the version from the received SYN in its + GSMP Version field. This defines the version of the GSMP + protocol to be used while the adjacency protocol remains + synchronised. All other messages will use the agreed version + in the Version field. + + The version number for the version of the GSMP protocol defined + by this specification is Version = 3. + + Message Type + The adjacency protocol is: + + Message Type = 10 + + + + +Doria, et. al. Standards Track [Page 112] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Timer + The Timer field is used to inform the receiver of the timer + value used in the adjacency protocol of the sender. The timer + specifies the nominal time between periodic adjacency protocol + messages. It is a constant for the duration of a GSMP session. + The timer field is specified in units of 100ms. + + M-Flag + The M-Flag is used in the SYN message to indicate whether the + sender is a master or a slave. If the M-Flag is set in the SYN + message, the sender is a master. If zero, the sender is a + slave. The GSMP protocol is asymmetric, the controller being + the master and the switch being the slave. The M-Flag prevents + a master from synchronising with another master, or a slave + with another slave. If a slave receives a SYN message with a + zero M-Flag, it MUST ignore that SYN message. If a master + receives a SYN message with the M-Flag set, it MUST ignore that + SYN message. In all other messages the M-Flag is not used. + + 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. If the Ethernet encapsulation is + used the Sender Name MUST be the Source Address from the MAC + header. 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. + + 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. + + + +Doria, et. al. Standards Track [Page 113] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Sender Port + For the SYN, SYNACK, and ACK messages, is the local port number + of the link across which the message is being sent. 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. + + PType + PType is used to specify if partitions are used and how the + Partition ID is negotiated. + + Type of partition being requested. + 0 No Partition + 1 Fixed Partition Request + 2 Fixed Partition Assigned + + PFlag + Used to indicate the type of partition request. + + 1 - New Adjacency. + In the case of a new adjacency, the state of the + switch will be reset. + + 2 - Recovered Adjacency. + In the case of a recovered adjacency, the state of + the switch will remain, and the Switch Controller + will be responsible for confirming that the state + of the switch matches the desired state. + + 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 + 24-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 + + + +Doria, et. al. Standards Track [Page 114] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + of the Receiver Instance field from the incoming message that + caused the RSTACK message to be generated. + + Partition ID + Field used to associate the message with a specific switch + partition. + + 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 field is set to the value + of the Sender Instance field from the incoming message that + caused the RSTACK message to be generated. + +11.2 Procedure + + The adjacency protocol is described by the following rules and state + tables. + + 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, Sender Name and + Partition ID 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, Sender Name and Partition + ID fields in the incoming message match the values stored + from a previous message by the "Update Peer Verifier" + operation. + + + +Doria, et. al. Standards Track [Page 115] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + C The Receiver Instance, Receiver Port, Receiver Name and + Partition ID fields in the incoming message match the values + of the Sender Instance, Sender Port, Sender Name and + Partition ID 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. + + o A timer is required for the periodic generation of SYN, SYNACK, + and ACK messages. The value of the timer is announced in the + Timer field. 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. + If incoming message is a SYN, SYNACK, or ACK: + Response defined by the following State Tables. + If incoming message is any other GSMP message and + state != ESTAB: + Discard incoming message. + If state = SYNSENT Send SYN (Note 1) + If state = SYNRCVD Send SYNACK (Note 1) + + Note 1: No more than two SYN or SYNACK messages should be sent + within any time period of length defined by the timer. + + o State synchronisation across a link is considered to be achieved + when the protocol reaches the ESTAB state. All GSMP messages, + other than adjacency protocol messages, that are received before + synchronisation is achieved, will be discarded. + + + + + + + +Doria, et. al. Standards Track [Page 116] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +11.2.1 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 | + +====================================================================+ + + 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 2) | ESTAB | + +------------------+-------------------------------------+-----------+ + | ACK && B && C | Send ACK (note 3) | ESTAB | + +------------------+-------------------------------------+-----------+ + | ACK && !(B && C) | Send RSTACK | ESTAB | + +====================================================================+ + + + + + + + + +Doria, et. al. Standards Track [Page 117] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Note 2: No more than two ACKs should be sent within any time + period of length defined by the timer. Thus, one ACK MUST be + sent every time the timer expires. In addition, one further + ACK may be sent between timer expirations if the incoming + message is a SYN or SYNACK. This additional ACK allows the + adjacency protocol to reach synchronisation more quickly. + + Note 3: No more than one ACK should be sent within any time + period of length defined by the timer. + +11.3 Partition Information State + + Each instance of a [switch controller-switch partition] pair will + need to establish adjacency synchronisation independently. + + Part of the process of establishing synchronisation when using + partition will be to establish the assignment of partition + identifiers. The following scenarios are provided for: + + - A controller can request a specific partition ID by setting the + PType to Fixed Partition Request. + + - A controller can let the switch decide whether it wants to + assign a fixed partition ID or not, by setting the PType to No + Partition. + + - A switch can assign the specific Partition ID to the session by + setting the PType to Fixed Partition Assigned. A switch can + specify that no partitions are handled in the session by + setting the PType to No Partition. + + The assignment is determined by the following behaviour: + + - An adjacency message from a controller with PType = 1 and + Code = SYN SHOULD be treated as a partition request. + + - An adjacency message from a switch with PType = 2 and + Code = SYN SHOULD be treated as a partition assignment. + + - An adjacency message from a controller or a switch with + PType = 2 and Code = (SYNACK || ACK) SHOULD be treated as a + success response, the partition is assigned. + + - An adjacency message from a controller with PType = 0 and + Code = SYN indicates that the controller has not specified if + it requests partitions or not. + + + + + +Doria, et. al. Standards Track [Page 118] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + - An adjacency message from a switch with PType = 0 and + Code = SYN indicates that the switch does not support + partitions. + + - An adjacency message from a controller or a switch with + PType = 0 and Code = (SYNACK || ACK) indicates that the session + does not support partitions. + + - An adjacency message from a controller or a switch with + PType = (1 || 2) and Code = RSTACK indicates that requested + Partition ID is unavailable. + + - An adjacency message from a controller or a switch with + PType = 0 and Code = RSTACK indicates that an unidentified + error has occurred. The session SHOULD be reset. + + All other combinations of PType and Code are undefined in this + version of GSMP. + +11.4 Loss of Synchronisation + + If after synchronisation is achieved, no valid GSMP messages are + received in any period of time in excess of three times the value of + the Timer field announced in the incoming adjacency protocol + messages, loss of synchronisation may be declared. + + While re-establishing synchronisation with a controller, a switch + SHOULD maintain its connection state, deferring the decision about + resetting the state until after synchronisation is re-established. + + Once synchronisation is re-established the decision about resetting + the connection state SHOULD be made on the following basis: + + - If PFLAG = 1, then a new adjacency has been established and the + state SHOULD be reset + + - If PFLAG = 2, then adjacency has been re-established and the + connection state SHOULD be retained. Verification that + controller and connection state are the same is the + responsibility of the controller. + +11.5 Multiple Controllers per switch partition + + Multiple switch controllers may jointly control a single switch + partition. The controllers may control a switch partition either in + a primary/standby fashion or as part of multiple controllers + providing load-sharing for the same partition. It is the + responsibility of the controllers to co-ordinate their interactions + + + +Doria, et. al. Standards Track [Page 119] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + with the switch partition. In order to assist the controllers in + tracking multiple controller adjacencies to a single switch + partition, the Adjacency Update message is used to inform a + controller that there are other controllers interacting with the same + partition. It should be noted that the GSMP does not include + features that allow the switch to co-ordinate cache synchronization + information among controllers. The switch partition will service + each command it receives in turn as if it were interacting with a + single controller. Controller implementations without controller + entity synchronisation SHOULD NOT use multiple controllers with a + single switch partition. + +11.5.1 Multiple Controller Adjacency Process + + The first adjacency for a specific partition is determined by the + procedures described in section 11.2 and an Adjacency Update message + will be sent. The next adjacencies to the partition are identified + by a new partition request with the same Partition ID as the first + one but with the different Sender Name. Upon establishing adjacency + the Adjacency count will be increased and an Adjacency Update message + will be sent. + + When adjacency between one partition and a controller is lost, the + adjacency count will be decremented and an Adjacency Update message + will be sent. + + Example: + + A switch partition has never been used. When the first controller + (A) achieves adjacency, an adjacency count will be initiated and (A) + will get an Adjacency Update message about itself with Code field = + 1. Since (A) receives an adjacency count of 1 this indicates that it + is the only controller for that partition. + + When a second adjacency (B), using the same Partition ID, achieves + adjacency, the adjacency counter will be increased by 1. Both (A) + and (B) will receive an Adjacency Update message indicating an + adjacency count of 2 in the Code field. Since the count is greater + than 1, this will indicate to both (A) and (B) that there is another + controller interacting with the switch; identification of the other + controller will not be provided by GSMP, but will be the + responsibility of the controllers. + + If (A) looses adjacency, the adjacency count will be decreased and an + Adjacency Update message will be sent to (B) indicating an adjacency + count of 1 in the Code field. If (B) leaves as well, the partition + is regarded as idle and the adjacency count may be reset. + + + + +Doria, et. al. Standards Track [Page 120] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +12. Failure Response Codes + +12.1 Description of Failure and Warning 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 warning response message is a success response (Result = 3) with + the Code field specifying the warning code. The warning code + specifies a warning that was generated during the successful + operation. + + If the switch issues a failure response in reply to a request + message, no change should be made to the state of the switch as a + result of the message causing the failure. (For request messages + that contain multiple requests, such as the Delete Branches message, + the failure response message will specify which requests were + successful and which failed. The successful requests may result in a + changed state.) + + If the switch issues a failure response it MUST choose the most + specific failure code according to the following precedence: + + - Invalid Message + + - General Message Failure + + - Specific Message Failure A failure response specified in the + text defining the message type. + + - Connection Failures + + - Virtual Path Connection Failures + + - Multicast Failures + + - QoS Failures + + - General Failures + + - Warnings + + If multiple failures match in any of the following categories, the + one that is listed first should be returned. The following failure + response messages and failure and warning codes are defined: + + + +Doria, et. al. Standards Track [Page 121] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Invalid Message + + 3: The specified request is not implemented on this switch. + The Message Type field specifies a message that is not + implemented on the switch or contains a value that is not + defined in the version of the protocol running in this + session of GSMP. + + 4: One or more of the specified ports does not exist. + At least one of the ports specified in the message is + invalid. A port is invalid if it does not exist or if it + has been removed from the switch. + + 5: Invalid Port Session Number. + The value given in the Port Session Number field does not + match the current Port Session Number for the specified + port. + + 7: Invalid Partition ID + The value given in the Partition ID field is not legal for + this partition. + + General Message Failure + + 10: The meaning of this failure is dependent upon the + particular message type and is specified in the text + defining the message. + + Specific Message Failure - A failure response that is only used by a + specific message type + + - Failure response messages used by the Label Range message + + 40: Cannot support one or more requested label ranges. + + 41: Cannot support disjoint label ranges. + + 42: Specialised multipoint labels not supported. + + - Failure response messages used by the Set Transmit Data Rate + function of the Port Management message + + 43: The transmit data rate of this output port cannot be changed. + + + + + + + + +Doria, et. al. Standards Track [Page 122] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 44: Requested transmit data rate out of range for this output + port. + The transmit data rate of the requested output port can be + changed, but the value of the Transmit Data Rate field is + beyond the range of acceptable values. + + - Failure response message of the Port Management message + + 45: Connection Replace mechanism not supported on switch. + The R-flag SHOULD be reset in the Response Port Management + message. + + - Failure response message range reserved for the ARM extension + + 128-159: These failure response codes will be interpreted + according to definitions provided by the model + description. + + Connection Failures + + 11: The specified connection does not exist. + An operation that expects a connection to be specified + cannot locate the specified connection. A connection is + specified by the input port and input label on which it + originates. An ATM virtual path connection is specified + by the input port and input VPI on which it originates. + + 12: The specified branch does not exist. + An operation that expects a branch of an existing + connection to be specified cannot locate the specified + branch. A branch of a connection is specified by the + connection it belongs to and the output port and output + label on which it departs. A branch of an ATM virtual + path connection is specified by the virtual path + connection it belongs to and the output port and output + VPI on which it departs. + + 13: One or more of the specified Input Labels is invalid. + + 14: One or more of the specified Output Labels is invalid. + + 15: Point-to-point bi-directional connection already exists. + The connection specified by the Input Port and Input Label + fields already exists, and the bi-directional Flag in the + Flags field is set. + + + + + + +Doria, et. al. Standards Track [Page 123] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 16: Invalid Service Selector field in a Connection Management + message. The value of the Service Selector field is + invalid. + + 17: Insufficient resources for QoS Profile. + The resources requested by the QoS Profile in the Service + Selector field are not available. + + 18: Insufficient Resources. + Switch resources needed to establish a branch are not + available. + + 20: Reservation ID out of Range + The numerical value of Reservation ID is greater than the + value of Max Reservations (from the Switch Configuration + message). + + 21: Mismatched reservation ports + The value of Input Port differs from the input port + specified in the reservation or the value of Output Port + differs from the output port specified in the reservation. + + 22: Reservation ID in use + The value of Reservation ID matches that of an extant + Reservation. + + 23: Non-existent reservation ID + No reservation corresponding to Reservation ID exists. + + 36: Replace of connection is not activated on switch. + Only applicable for Add Branch messages. The Replace + Connection mechanism has not been activated on port by the + Port Management message. + + 37: Connection replacement mode cannot be combined with Bi- + directional or Multicast mode. The R flag MUST NOT be + used in conjunction with either the M flag or the B flag. + + ATM Virtual Path Connections + + 24: ATM virtual path switching is not supported on this input + port. + + + + + + + + + +Doria, et. al. Standards Track [Page 124] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 25: Point-to-multipoint ATM virtual path connections are not + supported on either the requested input port or the + requested output port. + One or both of the requested input and output ports is + unable to support point-to-multipoint ATM virtual path + connections. + + 26: Attempt to add an ATM virtual path connection branch to an + existing virtual channel connection. + It is invalid to mix branches switched as virtual channel + connections with branches switched as ATM virtual path + connections on the same point-to-multipoint connection. + + 27: Attempt to add an ATM virtual channel connection branch to an + existing ATM virtual path connection. + It is invalid to mix branches switched as virtual channel + connections with branches switched as ATM virtual path + connections on the same point-to-multipoint connection. + + 28: ATM Virtual path switching is not supported on non-ATM ports. + One or both of the requested input and output ports is not + an ATM port. ATM virtual path switching is only supported + on ATM ports. + + Multicast Failures + + 29: A branch belonging to the specified point-to-multipoint + connection is already established on the specified output + port and the switch cannot support more than a single + branch of any point-to-multipoint connection on the same + output port. + + 30: The limit on the maximum number of multicast connections that + the switch can support has been reached. + + 31: The limit on the maximum number of branches that the specified + multicast connection can support has been reached. + + 32: Cannot label each output branch of a point-to-multipoint tree + with a different label. + Some switch designs, require all output branches of a + point-to-multipoint connection to use the same value of + Label. + + 33: Cannot add multi-point branch to bi-directional connection. + It is an error to attempt to add an additional branch to + an existing connection with the bi-directional flag set. + + + + +Doria, et. al. Standards Track [Page 125] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 34: Unable to assign the requested Label value to the requested + branch on the specified multicast connection. + Although the requested Labels are valid, the switch is + unable to support the request using the specified Label + values for some reason not covered by the above failure + responses. This message implies that a valid value of + Labels exists that the switch could support. For example, + some switch designs restrict the number of distinct Label + values available to a multicast connection. (Most switch + designs will not require this message.) + + 35: General problem related to the manner in which multicast is + supported by the switch. + Use this message if none of the more specific multicast + failure messages apply. (Most switch designs will not + require this message.) + + QoS Failures + + 60-79: These failure response codes will be interpreted according + to definitions provided by the model description. + + 80: Switch does not support different QoS parameters for different + branches within a multipoint connection. + + General Failures + + 2: Invalid request message. + There is an error in one of the fields of the message not + covered by a more specific failure message. + + 6: One or more of the specified ports is down. + A port is down if its Port Status is Unavailable. + Connection Management, Connection State, Port Management, + and Configuration operations are permitted on a port that + is Unavailable. Connection Activity and Statistics + operations are not permitted on a port that is Unavailable + and will generate this failure response. A Port + Management message specifying a Take Down function on a + port already in the Unavailable state will also generate + this failure response. + + 19: Out of resources. + The switch has exhausted a resource not covered by a more + specific failure message, for example, running out of + memory. + + + + + +Doria, et. al. Standards Track [Page 126] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 1: Unspecified reason not covered by other failure codes. + The failure message of last resort. + + Warnings + + 46: One or more labels are still used in the previous Label Range. + +12.2 Summary of Failure Response Codes and Warnings + + The following list gives a summary of the failure codes defined for + failure response messages: + + 1: Unspecified reason not covered by other failure codes. + 2: Invalid request message. + 3: The specified request is not implemented on this switch. + 4: One or more of the specified ports does not exist. + 5: Invalid Port Session Number. + 6: One or more of the specified ports is down. + 7: Invalid Partition ID. + 10: General message failure. (The meaning of this failure code + depends upon the Message Type. It is defined within the + description of any message that uses it.) + 11: The specified connection does not exist. + 12: The specified branch does not exist. + 13: One or more of the specified Input Labels is invalid. + 14: One or more of the specified Output Labels is invalid. + 15: Point-to-point bi-directional connection already exists. + 16: Invalid service selector field in a connection management + message. + 17: Insufficient resources for QoS profile. + 18: Insufficient resources. + 19: Out of resources (e.g., memory exhausted, etc.). + 20: Reservation ID out of Range + 21: Mismatched reservation ports + 22: Reservation ID in use + 23: Non-existent reservation ID + 24: ATM virtual path switching is not supported on this input + port. + 25: Point-to-multipoint ATM virtual path connections are not + supported on either the requested input port or the + requested output port. + 26: Attempt to add an ATM virtual path connection branch to an + existing virtual channel connection. + 27: Attempt to add an ATM virtual channel connection branch to + an existing virtual path connection. + 28: ATM Virtual Path switching is not supported on non-ATM + ports. + + + + +Doria, et. al. Standards Track [Page 127] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + 29: A branch belonging to the specified point-to-multipoint + connection is already established on the specified + output port and the switch cannot support more than a + single branch of any point-to-multipoint connection on + the same output port. + 30: The limit on the maximum number of point-to-multipoint + connections that the switch can support has been + reached. + 31: The limit on the maximum number of branches that the + specified point-to-multipoint connection can support has + been reached. + 32: Cannot label each output branch of a point-to-multipoint + tree with a different label. + 33: Cannot add multi-point branch to bi-directional + connection. + 34: Unable to assign the requested Label value to the + requested branch on the specified point-to-multipoint + connection. + 35: General problem related to the manner in which point-to- + multipoint is supported by the switch. + 36: Replace of connection is not activated on switch. + 37: Connection replacement mode cannot be combined with Bi- + directional or Multicast mode. + 40: Cannot support one or more requested label ranges. + 41: Cannot support disjoint label ranges. + 42: Specialised multipoint labels not supported. + 43: The transmit data rate of this output port cannot be + changed. + 44: Requested transmit data rate out of range for this output + port. + 45: Connection Replace mechanism not supported on switch. + 46: Labels are still used in the existing Label Range. + 60-79: Reserved for QoS failures. + 80: Switch does not support different QoS parameters for + different branches within a multipoint connection. + 128-159: Reserved for the ARM extensions. + +13. Security Considerations + + The security of GSMP's TCP/IP control channel has been addressed in + [15]. For all uses of GSMP over an IP network it is REQUIRED that + GSMP be run over TCP/IP using the security considerations discussed + in [15]. + + + + + + + + +Doria, et. al. Standards Track [Page 128] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +Appendix A Summary of Messages + + Message Name Message Number Status + + Connection Management Messages + Add Branch .......................16 + ATM Specific - VPC.............26 + Delete Tree.......................18 + Verify Tree.......................19 Obsoleted + Delete All Input..................20 + Delete All Output.................21 + Delete Branches...................17 + Move Output Branch................22 + ATM Specific - VPC............27 + Move Input Branch.................23 + ATM Specifc - VPC............28 + + Port Management Messages + Port Management...................32 + Label Range.......................33 + + State and Statistics Messages + Connection Activity...............48 + Port Statistics...................49 + Connection Statistics.............50 + QoS Class Statistics..............51 Reserved + Report Connection State...........52 + + Configuration Messages + Switch Configuration..............64 + Port Configuration................65 + All Ports Configuration...........66 + Service Configuration.............67 + + Reservation Messages + Reservation Request...............70 + Delete Reservation................71 + Delete All Reservations...........72 + + Event Messages + Port Up...........................80 + Port Down.........................81 + Invalid Label.....................82 + New Port..........................83 + Dead Port.........................84 + + + + + + +Doria, et. al. Standards Track [Page 129] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + Abstract and Resource Model Extension Messages + Reserved..........................200-249 + + Adjacency Protocol....................10 Required + +Appendix B IANA Considerations + + Following the policies outlined in "Guidelines for Writing an IANA + Considerations Section in RFCs" (RFC 2434 [19]), the following name + spaces are defined in GSMPv3. + + - Message Type Name Space [Appendix A] + + - Label Type Name Space [3.1.3] + + - Result Name Space [3.1.1] + + - Failure Response Message Name Space [3.1.4],[11] + + - Adaptation Type Name Space [4.1] + + - Model Type Name Space [8.1] + + - Port Type Name Space [8.2] + + - Service ID Name Space [10.4] + + - Traffic Control Name Space [8.4] + + - Event Flag Name Space [6.1] + +B.1. Message Type Name Space + + GSMPv3 divides the name space for Message Types into four ranges. + The following are the guidelines for managing these ranges. + + - Message Types 0-99. + Message Types in this range are part of the GSMPv3 base + protocol. Message types in this range are allocated + through an IETF consensus action [19]. + + - Message Types 100-199. + Message Types in this range are Specification Required + [19]. Message Types using this range must be documented + in an RFC or other permanent and readily available + references. + + + + + +Doria, et. al. Standards Track [Page 130] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + - Message Types 200-249. + Message Types in this range are Specification Required + [19] and are intended for Abstract and Resource Model + Extension Messages. Message Types using this range must + be documented in an RFC or other permanent and readily + available references. + + - Message Types 250-255. + Message Types in this range are reserved for vendor + private extensions and are the responsibility of + individual vendors. IANA management of this range of the + Message Type Name Space is unnecessary. + +B.2. Label Type Name Space + + GSMPv3 divides the name space for Label Types into three ranges. The + following are the guidelines for managing these ranges. + + - Label Types 0x000-0xAFF. + Label Types in this range are part of the GSMPv3 base + protocol. Label Types in this range are allocated through + an IETF consensus action [19]. + + - Label Types 0xB00-0xEFF. + Label Types in this range are Specification Required [19]. + Label Types using this range must be documented in an RFC + or other permanent and readily available reference. + + - Label Types 0xF00-0xFFF. + Label Types in this range are reserved for vendor private + extensions and are the responsibility of individual + vendors. IANA management of this range of the Label Type + Name Space is unnecessary. + +B.3. Result Name Space + + The following is the guideline for managing the Result Name Space: + + - Result values 0-255. + Result values in this range need an expert review, i.e., + approval by a Designated Expert is required [19]. + +B.4. Failure Response Name Space + + GSMPv3 divides the name space for Failure Responses into three + ranges. The following are the guidelines for managing these ranges: + + + + + +Doria, et. al. Standards Track [Page 131] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + - Failure Responses 0-59, 80-127, 160-255. + Failure responses in these ranges are part of the GSMPv3 + base protocol. Failure Responses in these ranges are + allocated through an IETF consensus action [19]. + + - Failure Responses 60-79, 128-159. + Failure responses in these ranges are reserved for vendor + private extensions and are the responsibility of + individual vendors. IANA management of these ranges of + the Failure Response Name Space are unnecessary. + +B.5. Adaptation Type Name Space + + GSMPv3 divides the name space for Adaptation Types into two ranges. + The following are the guidelines for managing these ranges: + + - Adaptation Type 0x000-0x2FF. + Adaptation Types in this range are part of the GSMPv3 base + protocol. Adaptation Types in this range are allocated + through an IETF consensus action [19]. + + - Adaptation Type 0x300-0xFFF. + Adaptation Types in this range are allocated by the first + come first served principle [19]. + +B.6. Model Type Name Space + + GSMPv3 divides the name space for Model Types into three ranges. The + following are the guidelines for managing these ranges: + + - Model Type 0. + Model Types in this range are part of the GSMPv3 base + protocol. Model Types in this range are allocated through + an IETF consensus action [19]. + + - Model Type 1-200. + Model Types in this range are Specification Required [19]. + Message Types using this range must be documented in an + RFC or other permanent and readily available references. + + - Model Type 201-255. + Model Types in this range are reserved for vendor private + extensions and are the responsibility of individual + vendors. IANA management of these ranges of the Model + Type Name Space are unnecessary. + + + + + + +Doria, et. al. Standards Track [Page 132] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +B.7. Port Type Name Space + + GSMPv3 divides the name space for Port Types into two ranges. The + following are the guidelines for managing these ranges: + + - Port Type 0-127. + Port Types in this range are part of the GSMPv3 base + protocol. Port Types in this range are allocated through + an IETF consensus action [19]. + + - Port Type 128-255. + Port Types in this range are Specification Required [19]. + Port Types using this range must be documented in an RFC + or other permanent and readily available references. + +B.8. Service ID Name Space + + GSMPv3 divides the name space for Service IDs into two ranges. The + following are the guidelines for managing these ranges: + + - Service ID 0-1023. + Service ID's in this range are part of the GSMPv3 base + protocol. Service ID's in this range are allocated + through an IETF consensus action [19]. + + - Service ID 1024-65535. + Service ID's in this range are Specification Required + [19]. Service ID's using this range must be documented in + an RFC or other permanent and readily available + references. + +B.9. Traffic Control Name Space + + The following are the guidelines for managing Traffic Control Flags + in GSMPv3: + + - All Traffic Control Flags are allocated through an expert + review, i.e., approval by a Designated Expert [19]. + +B.10. Event Flag Name Space + + The following are the guidelines for managing Event Flags in GSMPv3: + + - All Event Flags are allocated through an expert review, i.e., + approval by a Designated Expert [19]. + + The TCP port for establishing GSMP connections has been defined as + 6068. + + + +Doria, et. al. Standards Track [Page 133] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +References + + [1] "B-ISDN ATM Layer Specification", International + Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999. + + [2] "B-ISDN ATM Adaptation Layer (AAL) Specification", International + Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993. + + [3] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", + International Telecommunication Union, ITU-T, Recommendation + I.363.5, Aug. 1996. + + [4] Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of + Managed Objects for the General Switch Management Protocol + (GSMP)", RFC 3295, June 2002. + + [5] IANA Assigned Port Numbers, http://www.iana.org + + [6] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., + Lyon, T. and G. Minshall, "Ipsilon's General Switch Management + Protocol Specification Version 1.1", RFC 1987, August 1996. + + [7] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, + F., Lyon, T. and G. Minshall, "Ipsilon's General Switch + Management Protocol Specification Version 2.0", RFC 2297, March + 1998. + + [8] ATM Forum Technical Committee, "Traffic Management Specification + Version 4.1", af-tm-0121.000, 1999. + + [9] Wroclawski, J., "Specification of the Controlled-Load Network + Element Service", RFC 2211, September 1997. + + [10] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., + Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., + Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint- + Based LSP Setup using LDP", RFC 3212, January 2002. + + [11] ITU-T Recommendation I.233 Frame Mode Bearer Services, ISDN + frame relaying bearer services and ISDN switching bearer + service, Nov. 1991. + + [12] ITU-T Recommendation Q.933, Integrated Services Digital Network + (ISDN) Digital Subscriber Signaling System No. 1 (DSS 1) + Signaling Specifications For Frame Mode Switched And Permanent + Virtual Connection Control And Status Monitoring, 1995. + + + + + +Doria, et. al. Standards Track [Page 134] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + + [13] ITU-T Recommendation Q.922, Integrated Services Digital Network + (ISDN) Data Link Layer Specification For Frame Mode Bearer + Services, 1992 + + [14] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., + Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, + January 2001. + + [15] Worster, T., Doria, A. and J. Buerkle, "General Switch + Management Protocol (GSMP) Packet Encapsulations for + Asynchronous Transfer Mode (ATM), Ethernet and Transmission + Control Protocol (TCP)", RFC 3293, June 2002. + + [16] Doria, A. and K. Sundell, "General Switch Management Protocol + Applicability", RFC 3294, June 2002. + + [17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001. + + [18] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B. + Thomas, "LDP Specification", RFC 3036, January 2001. + + [19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [21] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on + Frame Relay Networks Specification", RFC 3034, January 2001. + + + + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 135] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +Authors' Addresses + + Avri Doria + Div. of Computer Communications + Lulea University of Technology + S-971 87 Lulea + Sweden + + Phone: +1 401 663 5024 + EMail: avri@acm.org + + + Fiffi Hellstrand + Nortel Networks AB + S:t Eriksgatan 115 A + SE-113 85 Stockholm Sweden + + EMail: fiffi@nortelnetworks.com + + + Kenneth Sundell + Nortel Networks AB + S:t Eriksgatan 115 A + SE-113 85 Stockholm Sweden + + EMail: ksundell@nortelnetworks.com + + + Tom Worster + + Phone: +1 617 247 2624 + EMail: fsb@thefsb.org + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 136] + +RFC 3292 General Switch Management Protocol V3 June 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Doria, et. al. Standards Track [Page 137] + |