idnits 2.17.1 draft-ietf-gsmp-dyn-part-reqs-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 4 instances 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 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 abstract seems to contain references ([RFC3015], [GSMPv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2002) is 7946 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: 'GSMPv3' is mentioned on line 179, but not defined == Unused Reference: 'RFC3292' is defined on line 339, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3015 (Obsoleted by RFC 3525) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Anderson 3 Expiration: January 2003 Intel Labs 4 File: draft-ietf-gsmp-dyn-part-reqs-02.txt J. Buerkle 5 Nortel Networks 7 July 2002 9 Requirements for the Dynamic Partitioning of Switching Elements 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as ``work in 23 progress.'' 25 To view the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in an Internet-Drafts 27 Shadow Directory, see http://www.ietf.org/shadow.html. 29 Conventions used in this document 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 33 this document are to be interpreted as described in [RFC2119]. 35 Abstract 37 This document identifies a set of requirements for the mechanisms 38 used to dynamically reallocate the resources of a switching element 39 (e.g., an ATM switch) to its partitions. These requirements are 40 particularly critical in the case of an operator creating a switch 41 partition and then leasing control of that partition to a third 42 party. 44 Definitions 46 In this document, the following definitions will be used. 48 Switching Element - A device that switches packets (e.g., an ATM 49 switch or MPLS LSR) and whose resources can be divided into 50 partitions, each of which can be independently controlled by a 51 different controller. 53 Partition - A partition is a set of switching element (SE) 54 resources. Partitions are also referred to as virtual SEs. 56 Active Partition - An active partition is a partition in which the 57 resources are in use; either under the direct control of a separate 58 controller or under internal policy based control. 60 Controller - The entity responsible for controlling the operations 61 of an active partition. 63 Static Partitioning - In static partitioning, no changes can be made 64 to any active partition�s resources without requiring a restart of 65 that partition. Instances of repartitioning in which connections to 66 controllers are disconnected before resources are reallocated 67 therefore fall into this category. 69 Dynamic Partitioning - In dynamic partitioning, an active 70 partition�s resources can be reapportioned without requiring a 71 restart of the partition. 73 Frozen Partition - A frozen partition is an active partition that is 74 in the process of being shutdown. A frozen partition's unused 75 resources are relinquished, but all current connections are allowed 76 to remain until removed by the controller. As connections close the 77 resources are returned to the SE. 79 Deterministic Partitioning - In deterministic partitioning, each 80 active partition is given an allotted quantity of each resource. 81 The usage of resources in one active partition does not influence 82 the resources available to another active partition. All 83 discussions in these requirements presuppose the use of 84 deterministic partitioning. 86 Statistical Partitioning - In statistical partitioning, some or all 87 resources are pooled among the active partitions, and allocations 88 may be based on percentages or on some other metric. Discussion of 89 statistical partitions is outside the scope of these requirements. 91 Proactive Notification - A proactive notification is a message sent 92 from a SE to its controller at the time an event occurs. 93 Specifically, if a SE asynchronously sends the controller a message 94 when it is dynamically partitioned, we say that the SE has 95 proactively notified its controller of the resource reapportionment. 97 Explicit Reactive Notification - In explicit reactive notification, 98 the SE does not asynchronously send a message when dynamic 99 partitioning occurs. Instead, the SE includes a "resource changed" 100 error code in the response to a subsequent request by the 101 controller. 103 Implicit Reactive Notification - This is similar to an Explicit 104 Reactive Notification except that the protocol does not contain an 105 explicit "resource changed" error. In this case, all that the SE 106 can do is to indicate that some unspecified error has occurred when 107 the controller attempts to use non-allocated resources. 109 Introduction 111 Several logical entities are involved in the partitioning and 112 control of a SE. First, a switching element (for the purposes of 113 this draft) is a device that "switches" packets, whose resources can 114 be partitioned and whose partitions can each be controlled by a 115 single controller. (This partitioning also implies the ability to 116 enforce this division of resources between competing partitions). 117 Second, the partition manager (PM) is a management entity that 118 specifies the number of virtual SEs into which the SE should be 119 partitioned and the resources to be allocated to each virtual SE. 120 Lastly, a controller directs the use of the resources of one or more 121 partitions to provide a set of services. 123 In the rest of this draft, we will deal exclusively with logical 124 entities although it is worth noting here that there are many 125 possible mappings of logical entities to physical entities. For 126 example, there may be multiple logical controllers running on a 127 single physical processor (and for convenience we may refer to this 128 processor as a physical controller). Likewise, there may be 129 multiple partition managers running on a single management 130 workstation. A switching element may consist of multiple physical 131 elements (e.g., some number of blades in a chassis) or fractional 132 physical elements (i.e., nested partitioning). Finally, any 133 combination of these logical entities could theoretically be 134 collocated on the same physical resources. 136 However, for many reasons, the physical realm often reflects this 137 logical division of functionality. To facilitate this division, 138 several protocols, such as MEGACO [RFC3015] and GSMP [GSMPv3], exist 139 that allow control functionality to be physically separated from 140 switching functionality. Recently, some regulatory environments 141 have mandated multi-provider access to a single physical 142 infrastructure. To satisfy these regulations, a common use of 143 partitioning will be for the owner of the SE to partition the SE 144 into several virtual SEs and then to lease these to third parties. 145 In this case, the PM will likely be physically separate from all of 146 the controllers. For locality (and therefore ease) of management, 147 SEs will be remotely configurable and thus the PM will be physically 148 separated from the SE. The following illustration depicts this 149 arrangement. The dashed lines indicate interactions between the 150 entities and are labeled with the cardinality of the relationship 151 between the entities. 153 ------------------ ------------------- 154 | | * * | | 155 | Partition |-------------| Controller | 156 | Manager | C | | 157 ------------------ ------------------- 158 1 \ / * 159 \ / 160 \ A B / 161 \ / 162 * \ / * 163 ------------/------ 164 | --------/--- | 165 | |Partition | | 166 | | | | 167 | ------------ | 168 |Switching element| 169 ------------------- 171 Interaction A is one in which the PM partitions the SE and allocates 172 resources to the partitions it creates. There is a one-to-many 173 relationship between PMs and SEs. In order to support dynamic 174 partitioning, this document will place certain requirements on 175 proposed (or new) solutions in this space. 177 Interaction B is one in which the controller configures and manages 178 an active partition. Current protocols implementing this 179 interaction include GSMP [GSMPv3] and MEGACO [RFC3015]. These 180 protocols allow a many-to-many relationship between controller and 181 partition. 183 Interaction C is one by which a PM and a controller could 184 communicate to alter the nature of an active partition. There is a 185 many-to-many relationship between PMs and controllers. For example, 186 there are multiple PMs per controller in the case where a controller 187 is managing two partitions from different SEs and there are multiple 188 controllers per PM in the case where a SE has two partitions each 189 managed by a different controller. Possible types of interactions 190 between PM and controller include: 191 - A controller could request that the resources of one of its 192 active partitions be altered; either increased or decreased. 193 - The PM could respond to a controller request for altered 194 resource levels. 195 - The PM could request that a controller release resources 196 currently allocated to one of its active partitions. This could 197 involve the following types of request: 198 - A request to relinquish allocated but currently unused 199 resources. That is to put a freeze on additional use of the 200 specified resources. 201 - A request to relinquish used resources. 202 - A request to relinquish an active partition. That is 203 a request that a controller release control of an active 204 partition. 205 - The controller�s response to a PM request. 207 As far as the authors know, no proposed standard solutions currently 208 exist for interactions of type C. 210 Dynamic Partitioning 212 Static repartitioning of a SE can be a costly and inefficient 213 process. First, before static repartitioning can take place, all 214 existing connections with controllers must be severed. When this 215 happens, the SE will typically release all the state configured by 216 the controller. Then, the virtual SE must be placed in the "down" 217 state while the repartitioning takes place. Once the repartitioning 218 is completed, the partitions are placed in the "up" state and the 219 controllers are allowed to reconnect to the partitions. Then, the 220 controllers can reestablish state in the active partition. Thus, 221 static repartitioning results in a period of downtime and a period 222 in which the controllers are reestablishing state. This is the case 223 even if resources that are not currently in use in one partition, 224 either an active or an inactive partition, are intended for a fully 225 loaded active partition. 227 Therefore, dynamic partitioning is to be preferred to static 228 partitioning since it avoids the downtime and loss of state 229 associated with static partitioning. However, a different set of 230 potential problems exists for dynamic partitioning. Some questions 231 to be answered include the following: 232 - How is the controller notified of an increase or decrease in 233 resources? 234 - What should happen when the PM would like to decrease the 235 resources allocated to a partition but those resources are in 236 use? 238 Requirements 240 This document does not attempt to answer the preceding questions but 241 instead defines a set of requirements that any solution to these 242 problems MUST satisfy. 244 1. There MUST be a mechanism by which a PM can create virtual SEs on 245 the SE and allocate SE resources to those virtual SEs. 246 2. SEs MUST ensure that controllers do not use more resources than 247 those currently allocated to each virtual SE. Therefore, each 248 control protocol MUST provide either an explicit reactive 249 notification or an implicit reactive notification to indicate 250 resource exhaustion. 251 3. Furthermore, this mechanism MUST support the partitioning of all 252 resources discoverable through GSMP (e.g., label tables). Other 253 resources used by GSMP indirectly (e.g., CPU) or resources (e.g., 254 forwarding table entries) used by other types of SEs MAY be 255 supported. 256 4. If a PM instructs a SE to release resources allocated to an active 257 partition and if any of those resources are currently in use, the 258 SE MUST deny the PM�s request. 260 5. Subsequent to a resource reallocation failure, the PM SHOULD make 261 use of one or both of the capabilities described in requirements 6 262 and 7. 263 6. A PM SHOULD be able to tell a SE to make an active partition into 264 a frozen partition. 265 7. A PM SHOULD be able to contact the controller to ask it to reduce 266 its resource utilization. 267 8. The PM MUST be able to exercise "power on/off" type control of the 268 virtual SEs that it has created. When the virtual power to an 269 active partition is turned off, the partition becomes inactive and 270 any controllers associated with that partition are disconnected. 271 This capability allows a PM to resort to static partitioning when 272 a controller is uncooperative about releasing resources. 273 9. During dynamic repartitioning, a SE MUST maintain all existing 274 state associated with the partitions being modified. 275 10. Control protocols SHOULD NOT include any mechanism by which a 276 SE can ask its controller to reduce its resource usage. 277 11. Control protocols MAY contain proactive resource notification 278 messages by which a SE could instantaneously inform the controller 279 of an increase or decrease in resources. (We do not specifically 280 require control protocols to contain proactive notifications 281 because all control protocols must already have explicit or 282 implicit reactive notifications as mentioned in requirement #2). 283 12. A PM MAY directly inform a controller of a change in virtual SE 284 resources rather than rely on the implicit resource exhaustion 285 mechanism of the control protocol. 286 13. SEs MAY inform the PM of resource exhaustion on a particular 287 partition. 288 14. A controller MAY ask the PM for further resources or a 289 reduction in existing resources. 290 15. To support the automation of interaction between the PM and 291 attached controllers, the PM MUST be able to determine from the SE 292 the addresses of the controllers that are currently attached to a 293 virtual SE. Additionally, the SE MAY allow the PM to determine 294 which control protocol (and version thereof) is currently managing 295 each active partition. 296 16. A SE MAY support the ability to have one virtual SE provide a 297 service to another virtual SE within the same physical SE. For 298 example, a SE may be configured to provide a virtual link between 299 two virtual SEs. Furthermore: 300 a. There MUST be a mechanism by which the SE can inform the PM 301 which of these partition-to-partition services are provided by 302 the SE. 303 b. There MUST be a mechanism by which the PM can configure the 304 available partition-to-partition services. 305 c. If the configuration of a partition-to-partition service 306 results in a virtual port being added/removed from a virtual 307 SE, the SE MUST notify all controllers attached to that virtual 308 SE (assuming that the corresponding control protocol supports 309 such notifications). 311 Security Considerations 313 Only authorized PMs MUST be allowed to dynamically repartition a SE. 314 Similarly, only the PM (or an authorized agent of the PM) that is 315 authorized to partition a SE MUST be allowed to contact controllers 316 to request that they decrease their resources or inform them that 317 their resources have been increased. Likewise, the PM MUST verify 318 and authenticate that any requests for additional/fewer resources 319 for a virtual SE have come from a controller authorized to control 320 the specified virtual SE. 322 Intellectual Property Considerations 324 The IETF is being notified of intellectual property rights claimed 325 in regard to some or all of the specification contained in this 326 document. For more information, consult the online list of claimed 327 rights. 329 Acknowledgements 331 The authors would like to acknowledge the contributions of Avri 332 Doria and Jonathan Sadler to this draft. 334 Normative References 336 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 337 Requirement Levels", RFC 2119, BCP 14, March 1997. 339 [RFC3292] A. Doria, et. al., "General Switch Management Protocol 340 (GSMP) V3", RFC3292, June 2002. 342 Informative References 344 [RFC3015] F. Cuervo, et. al., "Megaco Protocol 1.0," RFC3015, 345 November 2000. 347 Author Information 349 Todd A. Anderson 350 Intel Labs 351 JF2-60 352 2111 NE 25th Avenue 353 Hillsboro, OR 97124 USA 354 Phone: +1 503 712 1760 355 Email: todd.a.anderson@intel.com 357 Joachim Buerkle 358 Nortel Networks Germany GmbH & Co. KG 359 Hahnstrasse 37-39 360 60528 Frankfurt 361 Phone: ++49 (0)69 6697 3281 362 Email: joachim.buerkle@nortelnetworks.com