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