rfc2297.txt

RFC 的详细文档！

      VCI = 15.




Newman, et. al.              Informational                      [Page 5]

RFC 2297          Ipsilon's General Switch Management         March 1998


2.2 Ethernet Encapsulation

   GSMP packets may be encapsulated on an Ethernet data link 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Destination Address                      |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                         Source Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Ethertype (0x88-0C)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   ~                         GSMP Message                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Instance                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Receiver Instance                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Pad                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Frame Check Sequence                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Destination Address
             For the SYN message of the adjacency protocol the
             Destination Address is the broadcast address
             0xFFFFFFFFFFFF. (Alternatively, it is also valid to
             configure the node with the unicast 48-bit IEEE MAC address
             of the destination. In this case the configured unicast
             Destination Address is used in the SYN message.) For all
             other messages the Destination Address is the unicast 48-
             bit IEEE MAC address of the destination. This address may
             be discovered from the Source Address field of messages
             received during synchronization of the adjacency protocol.

   Source Address
             For all messages the Source Address is the 48-bit IEEE MAC
             address of the sender.

   Ethertype
             The assigned Ethertype for GSMP is 0x880C.




Newman, et. al.              Informational                      [Page 6]

RFC 2297          Ipsilon's General Switch Management         March 1998


   GSMP Message
             The maximum transmission unit (MTU) of the GSMP Message
             field is 1492 octets.

   Sender Instance
             The Sender Instance number for the link obtained from the
             adjacency protocol.  This field is already present in the
             adjacency protocol message. It is appended to all non-
             adjacency GSMP messages in the Ethernet encapsulation to
             offer additional protection against the introduction of
             corrupt state.

   Receiver Instance
             The Receiver Instance number is what the sender believes is
             the current instance number for the link, allocated by the
             entity at the far end of the link.  This field is already
             present in the adjacency protocol message. It is appended
             to all non-adjacency GSMP messages in the Ethernet
             encapsulation to offer additional protection against the
             introduction of corrupt state.

   Pad
             The minimum length of the data field of an Ethernet packet
             is 46 octets.  If necessary, padding should be added such
             that it meets the minimum Ethernet frame size. This padding
             should be octets of zero and it is not considered to be
             part of the GSMP message.

   After the adjacency protocol has achieved synchronization, for every
   GSMP message received with an Ethernet encapsulation, the receiver
   must check the Source Address from the Ethernet MAC header, the
   Sender Instance, and the Receiver Instance.  The incoming GSMP
   message must be discarded if the Sender Instance and the Source
   Address do not match the values of Sender Instance and Sender Name
   stored by the "Update Peer Verifier" operation of the GSMP adjacency
   protocol. The incoming GSMP message must also be discarded if it
   arrives over any port other than the port over which the adjacency
   protocol has achieved synchronization.  In addition, the incoming
   message must also be discarded if the Receiver Instance field does
   not match the current value for the Sender Instance of the GSMP
   adjacency protocol.


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



Newman, et. al.              Informational                      [Page 7]

RFC 2297          Ipsilon's General Switch Management         March 1998


   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 five classes of GSMP
   request-response message: Connection 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.  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.

   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 subfields 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 state synchronized.

   Except for the adjacency protocol message, no GSMP messages may be
   sent across the link until the adjacency protocol has achieved
   synchronization, and all GSMP messages received on a link that does
   not currently have state synchronization must be discarded.

3.1 GSMP Packet Format

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







Newman, et. al.              Informational                      [Page 8]

RFC 2297          Ipsilon's General Switch Management         March 1998


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

   Version
             The 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 six classes:
             Connection Management, Port Management, State and
             Statistics, Configuration, Quality of Service, and Events.
             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 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 Sate 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 were set to "AckAll". (This facility was added to
             reduce the control traffic in the case where the 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.")






Newman, et. al.              Informational                      [Page 9]

RFC 2297          Ipsilon's General Switch Management         March 1998


             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. The "More"
             result indicates that the success 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. 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.

             The encoding of the result field is:

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


             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.

   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