idnits 2.17.1 draft-doria-gsmp-partition-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 172 has weird spacing: '... is the respo...' == Line 177 has weird spacing: '...so that where...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 February 1999) is 9198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Newman98' on line 179 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GSMP Working Group Avri Doria 2 Internet-Draft Kenneth Sundell, Ericsson 3 Expiration Date: August 1999 17 February 1999 5 Addition of Partition Id to the GSMP header 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at: 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 Abstract 38 A set of modifications to the GSMP protocol are proposed in order 39 to allow the GSMP to support partitioning of physical switch 40 resources into separate virtual switches. 42 Overview 43 The use of the GSMP can be expanded by introducing the use of 44 switch partitions. One way to do is to allow for multiple 45 instances of GSMP to run in both the switch and in the 46 controllers. A physical switch could be divided into separate 47 partitions by means of a separate (non GSMP) management interface 48 according to the policy of the administration that controls the 49 switch. That is, the GSMP would have no involvement in creating 50 the partitions. Each switch controller that established adjacency 51 with a switch partition would be limited to control of its 52 assigned partition(s). 54 This proposal includes the minimal set of changes that need to be 55 made to the GSMP to support switch partitions. Essentially it is 56 necessary to identify which switch partition GSMP messages belong 57 to. Support of partitions can be achieved by making 2 changes to 58 the protocol. 60 O Additon of a partition identifier to the standard GSMP message 61 header. 62 O Changes to the Adjacency message format. 64 1. Addition of a partition identifier to the standard GSMP 65 message header 66 A partition identifier needs to be added to the GSMP message 67 header that is prepended to all GSMP messages other then the 68 adjacency message. 69 An 8 bit field can be cut out of the transaction id to be used for 70 the partition id. This would leave 24 bits for the transaction id 71 which should be enough for most any switch. It would also allow 72 for backward compatibility. 74 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 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | Version | Message Type | Result | Code | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | Partition ID | Transaction Identifier | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | | 81 ~ Message Body ~ 82 | | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 2. Changes to the Adjacency message 87 2.1 Changes to message format 88 To support multiple switch partitions, a change also needs to be 89 made to the adjacency protocol. 90 Each instance of [switch controller, switch partition] pair will 91 need to satisfy its own adjacency negotiation and heartbeat. It 92 is, therefore, necessary that the partition information should be 93 exchanged in the adjacency protocol. In the simplest form, each 94 controller and partition would only be able to achieve adjacency 95 if they both used the same pre-set partition id. On the other 96 hand, it is often desirable for a switch to assign partitions 97 based on the identity of the controller or some other 98 administrative policy. And finally, especially in case where 99 adjacency is being re-established after a fault, the controller 100 might need to request access to a specific partition. 101 The following fields need to be added to message 10 to support 102 switch partitions: 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Version | Message Type | Timer |M| Code | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Sender Name | 109 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 112 | Receiver Name | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Partition ID | PType | PFlag | PCode | Unused | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Sender Port | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Receiver Port | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Sender Instance | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Receiver Instance | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Where: 126 Partition Id is the Partition Identifier which is either requested 127 by the Controller or Assigned by the Switch 129 PType is the type of partition being requested. In this version 130 there is only one type: 131 1 Fixed Partition 133 PFlag would be used to indicate whether this is a request 134 occurring after a fault or a new request. This flag indicates 135 that switch state should not be reset after synchronization. 136 1 New Adjacency 137 2 Recovered Adjacency 138 (other flags TBD if needed) 140 PCode would indicate the type of request: 141 1 Partition ID request from controller 142 2 Partition ID assigned by switch 143 3 Partition Unavailable � Response sent by switch when 144 partition requested by controller is unavailable. 145 (other codes TBD if needed) 147 2.2 Changes to the Loss of Synchronization section 148 The section of Loss of Synchronization should be changed to read 149 as follows: 151 If after synchronisation is achieved, no valid GSMP messages are 152 received in any period of time in excess of three times the value 153 of the Timer field announced in the incoming adjacency protocol 154 messages, loss of synchronization may be declared. 156 The preferred procedure for a switch to use when it looses 157 synchronisation with its active controller is to attempt to 158 establish synchronization with (one of) its backup controller(s). 159 However, in this preferred approach, it must not reset its state 160 until it achieves synchronization with a backup controller. This 161 means that if, before achieving synchronization with a backup 162 controller, it regains synchronization with its original 163 controller and PFlag is set, it may continue the original session 164 (and cease attempting to establish synchronization with a backup 165 controller). If synchronisation with the original session is 166 regained it is the responsibility of the controller to ensure 167 consistent state between the switch and controller. 169 Additionally if the PFlag is set, and a redundant controller 170 establishes synchronization, then the switch may continue the 171 original session. If synchronization with the original session is 172 regained it is the responsibility of the redundant controller to 173 ensure consistent state between the switch and controller. 175 2.3 Changes to Adjacency State Table 176 Additionally, the adjacency state tables in the GSMP would need to 177 be changed so that wherever the Peer Identifier was either set or 178 checked, the TransactionId would be checked as well. That is, the 179 tests in the GSMP V2 specification[Newman98] would need to be 180 changed to the following: 182 O The state tables use the following Boolean terms and operators: 184 a) The Sender Instance in the incoming message matches the 185 value stored from a previous message by the "Update Peer 186 Verifier" operation. 188 b) The Sender Instance, Sender Port, Sender Name and Sender 189 Partition ID fields in the incoming message match the 190 values stored from a previous message by the "Update Peer 191 Verifier" operation. 193 c) The Receiver Instance, Receiver Port, Receiver Name and 194 Receiver Partition ID fields in the incoming message match 195 the values of the Sender Instance, Sender Port, Sender 196 Name and Sender Partition ID currently sent in outgoing 197 SYN, SYNACK, and ACK messages. 199 References 201 Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., 202 Lyon, T. and Minshall, G., "Ipsilon's General Switch Management 203 Protocol Specification," Version 1.1, RFC 1987, August 1996. 205 Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., 206 Lyon, T. and Minshall, G., "Ipsilon's General Switch Management 207 Protocol Specification," Version 2.0, RFC 2397, March 1998. 209 Authors' Contact 211 Avri Doria 212 +1 401 458 2490 213 avri@apocalypse.org 215 Kenneth Sundell 216 +46 8719 9880 217 etxkens@etxb.ericsson.com