rfc1987.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,398 行 · 第 1/5 页
TXT
1,398 行
Network Working Group P. Newman, IpsilonRequest for Comments: 1987 W. Edwards, SprintCategory: Informational R. Hinden, Ipsilon E. Hoffman, Ipsilon F. Ching Liaw, Ipsilon T. Lyon, Ipsilon G. Minshall, Ipsilon August 1996 Ipsilon's General Switch Management Protocol Specification Version 1.1Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Abstract The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.Newman, et. al. Informational [Page 1]RFC 1987 GSMP Protocol Specification August 1996Table of Contents 1. Introduction....................................................3 2. GSMP Packet Format..............................................4 3. Connection Management Messages..................................7 3.1 Add Branch Message.........................................11 3.2 Delete Branch Message......................................12 3.3 Delete Tree Message........................................13 3.4 Verify Tree Message........................................13 3.5 Delete All Message.........................................14 3.6 Move Branch Message........................................14 4. Port Management Message........................................16 5. Statistics Messages............................................20 5.1 VC Activity Message........................................20 5.2 Port and VC Statistics Messages............................23 5.2.1 Port Statistics Message..............................26 5.2.2 VC Statistics Message................................26 6. Configuration..................................................26 6.1 Switch Configuration Message...............................27 6.2 Port Configuration Message.................................28 6.3 All Ports Configuration Message............................32 7. Event Messages.................................................33 7.1 Port Up Message............................................35 7.2 Port Down Message..........................................35 7.3 Invalid VPI/VCI Message....................................35 7.4 New Port Message...........................................35 7.5 Dead Port Message..........................................36 8. Adjacency Protocol.............................................36 8.1 Packet Format..............................................36 8.2 Procedure..................................................39 9. Failure Response Messages......................................41 References........................................................43 Security Considerations...........................................43 Authors' Addresses................................................43Newman, et. al. Informational [Page 2]RFC 1987 GSMP Protocol Specification August 19961. Introduction The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. It also allows the switch to inform the controller of asynchronous events such as a link going down. GSMP runs across an ATM link connecting the controller to the switch, on a control connection (virtual channel) established at initialization. The GSMP protocol is asymmetric, the controller being the master and the switch being the slave. Multiple switches may be controlled by a single controller using multiple instantiations of the protocol over separate control connections. A switch is assumed to contain multiple "ports". Each port is a combination of one "input port" and one "output port". Some GSMP requests refer to the port as a whole whereas other requests are specific to the input port or the output port. ATM cells arrive at the switch from an external communication link on incoming virtual channels at an input port. ATM cells depart from the switch to an external communication link on outgoing virtual channels from an output port. Virtual channels on a port or link are referenced by their virtual path and virtual channel identifiers (VPI/VCI). A virtual channel connection across a switch is formed by connecting an incoming virtual channel to one or more outgoing virtual channels. Virtual channel connections are referenced by the input port on which they arrive and the virtual path and virtual channel identifiers (VPI/VCI) of their incoming virtual channel. In general a virtual channel is established with a certain quality of service (QOS). Unfortunately this is an ill defined and changing concept as new ideas make their way into hardware. For this version of the GSMP protocol it is assumed that each virtual channel connection may be assigned a priority when it is established. It may be assumed that for virtual channel connections that share the same output port, an ATM cell on a connection with a higher priority is much more likely to exit the switch before an ATM cell on a connection with a lower priority if they are both in the switch at the same time. The number of priorities that each port of the switch supports may be obtained from the port configuration message. Switch ports are described by a 32 bit port number. The switch assigns port numbers and it may typically choose to structure the 32 bits into sub-fields that have meaning to the physical structure of the switch (e.g. shelf, slot, port). In general, a port in the same physical location on the switch will always have the same portNewman, et. al. Informational [Page 3]RFC 1987 GSMP Protocol Specification August 1996 number, even across power cycles. The internal structure of the port number is opaque to the GSMP protocol. However, by looking up the product identity in a database, network management tools may discover the partitioning of the port number and the physical meaning of the sub-fields. Each switch port also maintains a port session number assigned by the switch. A connection management message or a port management message with an incorrect port session number must be rejected. This allows the controller to detect a link failure and to keep state synchronized. The port session number of a port remains unchanged while the port is continuously in the available state and the link status is continuously up. When a port returns to the available state after it has been unavailable or in any of the loopback states, or when the line status returns to the up state after it has been down or in test, or after a power cycle, its port session number will have changed. Port session numbers should be assigned using some form of random number. GSMP also contains an adjacency protocol. The adjacency protocol is used to synchronize state across the link, to discover the identity of the entity at the other end of a link, and to detect when it changes.2. GSMP Packet Format GSMP packets are variable length and are encapsulated directly in an AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header as illustrated: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC (0xAA-AA-03) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SNAP (0x00-00-00-88-0C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GSMP Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad (0 - 47 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + AAL-5 CPCS-PDU Trailer (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Newman, et. al. Informational [Page 4]RFC 1987 GSMP Protocol Specification August 1996 (The convention in the documentation of Internet Protocols [rfc1700] is to express numbers in decimal and to picture data in "big-endian" order. That is, fields are described left to right, with the most significant octet on the left and the least significant octet on the right. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted, the most significant octet is transmitted first. This is the same coding convention as is used in the ATM layer [I.361] and AAL-5 [I.363].) The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. The maximum transmission unit (MTU) of the GSMP message is 1500 octets. The default virtual channel for LLC/SNAP encapsulated messages is: VPI = 0 VCI = 15. GSMP is a master-slave protocol. The controller issues request messages to the switch. Each request message indicates whether a response is required from the switch and contains a transaction identifier to enable the response to be associated with the request. The switch replies with a response message indicating either a successful result or a failure. There are four classes of GSMP request-response message: Connection Management, Port Management, Statistics, and Configuration. The switch may also generate asynchronous Event messages to inform the controller of asynchronous events. Event messages are not acknowledged by the controller. There is also an adjacency protocol message used to establish synchronization across the link and maintain a handshake. For the request-response messages each message type has a format for the request message and a format for the success response. Unless otherwise specified a failure response message is identical to the request message that caused the failure, with the Code field indicating the nature of the failure. Event messages have only a single format defined as they are not acknowledged by the controller. Except for the adjacency protocol message, no GSMP messages may be sent across the link until the adjacency protocol has achieved
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?