idnits 2.17.1 draft-anderson-req-dyn-part-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 6 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 (February 2001) is 8464 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 148, but not defined == Unused Reference: 'SPMIB' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC2297' is defined on line 286, 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. -------------------------------------------------------------------------------- 1 Internet Draft T. Anderson 2 Expiration: August 2001 Intel 3 File: draft-anderson-req-dyn-part-00.txt A. Doria 4 Nortel Networks 6 February 2001 8 Requirements for the Dynamic Partitioning of Network Elements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as ``work in 22 progress.'' 24 To view the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in an Internet-Drafts 26 Shadow Directory, see http://www.ietf.org/shadow.html. 28 Conventions used in this document 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 32 this document are to be interpreted as described in [RFC2119]. 34 Abstract 36 This document identifies a set of requirements for the mechanisms 37 used to dynamically reallocate the resources of a partitionable 38 network element (NE). These requirements are particularly critical 39 in the case of an operator creating a virtual NE (by partitioning a 40 physical NE) and then leasing control of that virtual NE to a third 41 party. 43 1. Definitions 45 In this document, the following definitions will be used. 47 Partition - A partition is a defined set of a physical network 48 element (NE) resources that can be used to create a virtual NE. 50 Active Partition - An active partition is a partition in which the 51 resources are in use; either under the direct control of a separate 52 controller or under internal policy based control. 54 Controller - The entity responsible for controlling the operations 55 of an active partition. 57 Static Partitioning - In static partitioning, no changes can be made 58 to any active partition�s resources without requiring a restart of 59 that partition. Instances of repartitioning in which connections to 60 controllers are disconnected before resources are reallocated 61 therefore fall into this category. 63 Dynamic Partitioning - In dynamic partitioning, an active 64 partition�s resources can be reapportioned without requiring a 65 restart of the partition. 67 Frozen Partition - A frozen partition is an active partition which 68 is in the process of shutdown. A frozen partition's unused 69 resources are relinquished, but all current connections are allowed 70 to remain until removed by the controller. As connections close the 71 resources are returned to the NE. 73 Deterministic Partitioning - In deterministic partitioning, each 74 active partition is given an allotted quantity of each resource. 75 The usage of resources in one active partition do not influence the 76 resources available to another active partition. All discussions in 77 these requirements presuppose the use of deterministic partitioning. 79 Statistical Partitioning - In statistical partitioning, some or all 80 resources are pooled among the active partitions, and allocations 81 may be based on percentages or on some other metric. Discussion of 82 statistical partitions is outside the scope of these requirements. 84 Proactive Notification - A proactive notification is a message sent 85 from a NE to its controller at the time an event occurs. 86 Specifically, if a NE asynchronously sends the controller a message 87 when it is dynamically partitioned, we say that the NE has 88 proactively notified its controller of the resource reapportionment. 90 Explicit Reactive Notification - In explicit reactive notification, 91 the NE does not asynchronously send a message when dynamic 92 partitioning occurs. Instead, the NE includes a "resource changed" 93 error code in the response to a subsequent request by the 94 controller. 96 Implicit Reactive Notification - This is similar to an Explicit 97 Reactive Notification except that the protocol does not contain an 98 explicit "resource changed" error. In this case, all that the NE 99 can do is to indicate that some unspecified error has occurred when 100 the controller attempts to use non-allocated resources. 102 2. Introduction 104 Several logical entities are involved in the partitioning and 105 control of a NE. First, there is the physical NE itself that is 106 capable of having its resources partitioned. (This also implies the 107 ability to enforce this division of resources between competing 108 partitions). The partition manager (PM) is the management entity 109 that specifies the number of virtual NEs, partitions, in which the 110 physical NE should be partitioned. The PM then allocates the 111 resources of the physical NE to those virtual NEs. Subsequently, 112 one or more controllers would direct the use of the resources of 113 that now active partition. 115 In many cases, the physical realm reflects this logical division of 116 functionality. For example, MEGACO [RFC3015] and GSMP [GSMPv3] are 117 examples of protocols that allow control functionality to be 118 physically separated from switching/forwarding functionality. 119 Recently, some regulatory environments have mandated multi-provider 120 access to a single physical infrastructure. To satisfy these 121 regulations, a common use of partitioning will be for the owner of 122 the physical NE to partition the NE into several virtual NEs, 123 partitions, and then to lease these to third parties. In this case, 124 the PM must be physically separate from all of the controllers. 125 Since the physical NE must also be remotely configurable, the PM 126 will also be physically separate from the physical NE. The 127 following illustration depicts this arrangement. The dashed lines 128 indicate potential interactions. 130 ------------------ ------------------- 131 | | 3 | | 132 | Partition |-------------| Controller | 133 | Manager | | | 134 ------------------ ------------------- 135 \ / 136 \ / 137 \ 1 2 / 138 \ / 139 ----------------- 140 | | 141 | Network | 142 | Element | 143 ----------------- 145 The interaction labeled "1" is one in which the PM partitions the NE 146 and allocates resources to the partitions. In order to support 147 dynamic partitioning, this document will place certain requirements 148 on proposed (or new) solutions in this space such as [MSF-SPMIB]. 150 The interaction labeled "2" is one by which the controller 151 configures and manages an active partition of the physical NE. 153 Proposed solutions in this space include GSMP [GSMPv3] and MEGACO 154 [RFC3015]. 156 The interaction labeled "3" is one by which a PM and a controller 157 could communicate to alter the nature of an active partition. 158 Possible interactions include: 159 - A controller could request that the resources of one 160 of its active partitions be altered; either increased 161 or decreased. 162 - The PM could respond to a controller request for 163 altered resource levels. 164 - The PM could request that a controller release 165 resources currently allocated to one of its active 166 partitions. This could involve the following types of 167 request: 168 - A request to relinquish allocated but currently unused 169 resources. That is to put a freeze on additional use 170 of the specified resources. 171 - A request to relinquish used resources. 172 - A request to relinquish an active partition. That is 173 a request that a controller shut down an active 174 partition. 175 - The controller�s response to a PM request. 177 As far as the authors know, no proposed standard solutions currently 178 exist for type 3 interactions. 180 3. Dynamic Partitioning 182 Static repartitioning of a NE can be a costly and inefficient 183 process. First, before static repartitioning can take place, all 184 existing connections with controllers must be severed. When this 185 happens, the NE will typically release all the state configured by 186 the controller. Then, the virtual NE must be placed in the "down" 187 state while the repartitioning takes place. Once the repartitioning 188 is completed, the partitions are placed in the "up" state and the 189 controllers are allowed to reconnect to the partitions. Then, the 190 controllers can reestablish state in the active partition. Thus, 191 static repartitioning results in a period of downtime and a period 192 in which the controllers are reestablishing state. This is the case 193 even if resources that are not currently in use in one partition, 194 either and active or an inactive partition, are intended for a fully 195 loaded active partition. 197 Therefore, dynamic partitioning is to be preferred to static 198 partitioning since it avoids the downtime and loss of state 199 associated with static partitioning. However, a different set of 200 potential problems exist for dynamic partitioning. Some questions 201 to be answered include the following: 202 - Who initiates the repartitioning on the NE? 203 - How is the controller notified of an increase or 204 decrease in resources? 205 - What should happen when the PM would like to decrease 206 the resources allocated to a partition but those 207 resources are in use? 209 4. Requirements 211 This document does not attempt to answer the preceding questions but 212 instead defines a set of requirements that any solution to these 213 problems MUST satisfy. 215 1. If a PM instructs a NE to release resources allocated to an 216 active partition and if any of those resources are currently in 217 use, the NE MUST deny the PM�s request. 218 2. During dynamic repartitioning, a NE MUST maintain all existing 219 connection state. 220 3. If a NE denies a repartitioning request due to resources being in 221 use, the PM MAY contact the controller to ask it to reduce its 222 resource utilization. 223 4. If a PM has requested that a controller reduce resource 224 utilization so that a partition can be downsized and that 225 controller is not cooperating, the PM MUST be able to "down" the 226 virtual NE, thereby disconnecting the controller, and then reduce 227 the partition�s resources. In other words, the PM must be able 228 to resort to static partitioning when a controller is 229 uncooperative. 230 5. Control protocols SHOULD NOT include any mechanism by which a NE 231 can ask its controller to reduce its resource usage. 232 6. Because controllers cannot be trusted to use only those resources 233 allocated to their active partitions, the NE MUST reject all such 234 attempts. Preferably, the control protocol would allow the NE to 235 do so with an explicit reactive notification although implicit 236 reactive notifications are also permitted. 237 7. Control protocols MAY contain proactive resource notification 238 messages by which a NE could instantaneously inform the 239 controller of an increase or decrease in resources. When 240 present, dynamic partitioning solutions MAY make use of proactive 241 notifications. However, we do not specifically require control 242 protocols to contain proactive notifications because all control 243 protocols must already have explicit or implicit reactive 244 notifications as mentioned in requirement #6. 245 8. A PM MAY directly inform a controller of a change in virtual NE 246 resources rather than rely on the implicit resource exhaustion 247 mechanism of the control protocol. 248 9. NEs MAY inform the PM of resource exhaustion on a particular 249 partition. 250 10. A controller MAY ask the PM for further resources or a reduction 251 in existing resources. 252 11. To support the automation of interaction between the PM and 253 attached controllers, the PM MUST be able to determine from the 254 NE the addresses of the controllers that are currently attached 255 to a virtual NE. 257 5. Security Considerations 259 Only authorized PMs MUST be allowed to dynamically repartition a NE. 260 Similarly, only the PM (or an authorized agent of the PM) that is 261 authorized to partition a NE MUST be allowed to contact controllers 262 to request that they decrease their resources or inform them that 263 their resources have been increased. Likewise, the PM MUST verify 264 and authenticate that any requests for additional/fewer resources 265 for a virtual NE have come from a controller authorized to control 266 the specified virtual NE. 268 6. Intellectual Property Considerations 270 The IETF is being notified of intellectual property rights claimed 271 in regard to some or all of the specification contained in this 272 document. For more information, consult the online list of claimed 273 rights. 275 7. References 277 [GSMPv3] A. Doria, et. al, "Draft-ietf-gsmp-08.txt", work in 278 progress. 280 [SPMIB] T. Anderson, et. al, "draft-anderson-partitioning-mib- 281 00.txt", work in progress, February 2001. 283 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 284 Requirement Levels", RFC 2119, BCP 14, March 1997. 286 [RFC2297] P. Newman, et. al., "Ipsilon�s General Switch Management 287 Protocol Version 2.0," RFC2297, March 1998. 289 [RFC3015] F. Cuervo, et. al., "Megaco Protocol 1.0," RFC3015, 290 November 2000. 292 8. Author Information 294 Todd A. Anderson 295 Intel 296 2111 NE 25th Avenue 297 Hillsboro, OR 97124 USA 298 +1 503 712 1760 299 todd.a.anderson@intel.com 301 Avri Doria 302 Nortel Networks 303 600 Technology Park Drive 304 Billerica, MA 01821 305 Phone: +1 401 663 5024 306 Email: avri@nortelnetworks.com