Internet Draft GSMP Working Group Avri Doria Internet-Draft Kenneth Sundell, Ericsson Expiration Date: August 1999 17 February 1999 Addition of Partition Id to the GSMP header <draft-doria-gsmp-partition-id-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract A set of modifications to the GSMP protocol are proposed in order to allow the GSMP to support partitioning of physical switch resources into separate virtual switches. Overview The use of the GSMP can be expanded by introducing the use of switch partitions. One way to do is to allow for multiple instances of GSMP to run in both the switch and in the controllers. A physical switch could be divided into separate partitions by means of a separate (non GSMP) management interface according to the policy of the administration that controls the INTERNET-DRAFT Addition of a Partition ID to GSMP Feb 1999 Doria, et. al. Expires Aug 1999 [Page 2] switch. That is, the GSMP would have no involvement in creating the partitions. Each switch controller that established adjacency with a switch partition would be limited to control of its assigned partition(s). This proposal includes the minimal set of changes that need to be made to the GSMP to support switch partitions. Essentially it is necessary to identify which switch partition GSMP messages belong to. Support of partitions can be achieved by making 2 changes to the protocol. O Additon of a partition identifier to the standard GSMP message header. O Changes to the Adjacency message format. 1. Addition of a partition identifier to the standard GSMP message header A partition identifier needs to be added to the GSMP message header that is prepended to all GSMP messages other then the adjacency message. An 8 bit field can be cut out of the transaction id to be used for the partition id. This would leave 24 bits for the transaction id which should be enough for most any switch. It would also allow for backward compatibility. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. Changes to the Adjacency message 2.1 Changes to message format To support multiple switch partitions, a change also needs to be made to the adjacency protocol. Each instance of [switch controller, switch partition] pair will need to satisfy its own adjacency negotiation and heartbeat. It is, therefore, necessary that the partition information should be exchanged in the adjacency protocol. In the simplest form, each controller and partition would only be able to achieve adjacency if they both used the same pre-set partition id. On the other hand, it is often desirable for a switch to assign partitions INTERNET-DRAFT Addition of a Partition ID to GSMP Feb 1999 Doria, et. al. Expires Aug 1999 [Page 3] based on the identity of the controller or some other administrative policy. And finally, especially in case where adjacency is being re-established after a fault, the controller might need to request access to a specific partition. The following fields need to be added to message 10 to support switch partitions: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | PType | PFlag | PCode | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Partition Id is the Partition Identifier which is either requested by the Controller or Assigned by the Switch PType is the type of partition being requested. In this version there is only one type: 1 Fixed Partition PFlag would be used to indicate whether this is a request occurring after a fault or a new request. This flag indicates that switch state should not be reset after synchronization. 1 New Adjacency 2 Recovered Adjacency (other flags TBD if needed) PCode would indicate the type of request: 1 Partition ID request from controller 2 Partition ID assigned by switch 3 Partition Unavailable Response sent by switch when partition requested by controller is unavailable. (other codes TBD if needed) INTERNET-DRAFT Addition of a Partition ID to GSMP Feb 1999 Doria, et. al. Expires Aug 1999 [Page 4] 2.2 Changes to the Loss of Synchronization section The section of Loss of Synchronization should be changed to read as follows: 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 synchronization may be declared. The preferred procedure for a switch to use when it looses synchronisation with its active controller is to attempt to establish synchronization with (one of) its backup controller(s). However, in this preferred approach, it must not reset its state until it achieves synchronization with a backup controller. This means that if, before achieving synchronization with a backup controller, it regains synchronization with its original controller and PFlag is set, it may continue the original session (and cease attempting to establish synchronization with a backup controller). If synchronisation with the original session is regained it is the responsibility of the controller to ensure consistent state between the switch and controller. Additionally if the PFlag is set, and a redundant controller establishes synchronization, then the switch may continue the original session. If synchronization with the original session is regained it is the responsibility of the redundant controller to ensure consistent state between the switch and controller. 2.3 Changes to Adjacency State Table Additionally, the adjacency state tables in the GSMP would need to be changed so that wherever the Peer Identifier was either set or checked, the TransactionId would be checked as well. That is, the tests in the GSMP V2 specification[Newman98] would need to be changed to the following: 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 Sender Partition ID fields in the incoming message match the values stored from a previous message by the "Update Peer Verifier" operation. c) The Receiver Instance, Receiver Port, Receiver Name and Receiver Partition ID fields in the incoming message match the values of the Sender Instance, Sender Port, Sender Name and Sender Partition ID currently sent in outgoing SYN, SYNACK, and ACK messages. INTERNET-DRAFT Addition of a Partition ID to GSMP Feb 1999 Doria, et. al. Expires Aug 1999 [Page 5] References Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 2.0, RFC 2397, March 1998. Authors' Contact Avri Doria +1 401 458 2490 avri@apocalypse.org Kenneth Sundell +46 8719 9880 etxkens@etxb.ericsson.com INTERNET-DRAFT Addition of a Partition ID to GSMP Feb 1999