path: root/doc/rfc/rfc3532.txt

Network Working Group                                        T. Anderson
Request for Comments: 3532                                    Intel Labs
Category: Informational                                       J. Buerkle
                                                         Nortel Networks
                                                                May 2003


    Requirements for the Dynamic Partitioning of Switching Elements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document identifies a set of requirements for the mechanisms
   used to dynamically reallocate the resources of a switching element
   (e.g., an ATM switch) to its partitions.  These requirements are
   particularly critical in the case of an operator creating a switch
   partition and then leasing control of that partition to a third
   party.

Table of Contents

   1.  Definitions ................................................  2
   2.  Introduction ...............................................  3
   3.  Dynamic Partitioning .......................................  6
   4.  Requirements ...............................................  7
   5.  Security Considerations ....................................  9
   6.  Intellectual Property Considerations .......................  9
   7.  Acknowledgements ...........................................  9
   8.  Normative References ....................................... 10
   9.  Informative References ..................................... 10
   10. Authors' Addresses ......................................... 10
   11. Full Copyright Statement ................................... 11










Anderson, et al.             Informational                      [Page 1]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


1.  Definitions

   In this document, the following definitions will be used.

   Switching Element - A device that switches packets (e.g., an ATM
      switch or MPLS LSR) and whose resources can be divided into
      partitions, each of which can be independently controlled by a
      different controller.

   Partition - A partition is a set of switching element (SE)
      resources.  Partitions are also referred to as virtual SEs.

   Active Partition - An active partition is a partition in which the
      resources are in use; either under the direct control of a
      separate controller or under internal policy-based control.

   Controller - The entity responsible for controlling the operations
      of an active partition.

   Static Partitioning - In static partitioning, no changes can be made
      to any active partition's resources without requiring a restart of
      that partition.  Instances of repartitioning in which connections
      to controllers are disconnected before resources can be
      reallocated therefore fall into this category.

   Dynamic Partitioning - In dynamic partitioning, an active
      partition's resources can be reapportioned without requiring a
      restart of the partition.

   Frozen Partition - A frozen partition is an active partition that is
      in the process of being shutdown.  A frozen partition's unused
      resources are relinquished, but all current connections are
      allowed to remain until removed by the controller.  As connections
      close, the resources are returned to the SE.

   Deterministic Partitioning - In deterministic partitioning, each
      active partition is given an allotted quantity of each resource.
      The usage of resources in one active partition does not influence
      the resources available to another active partition.  All
      discussions in these requirements presuppose the use of
      deterministic partitioning.

   Statistical Partitioning - In statistical partitioning, some or all
      resources are pooled among the active partitions, and allocations
      may be based on percentages or on some other metric.  Discussion
      of statistical partitions is outside the scope of these
      requirements.




Anderson, et al.             Informational                      [Page 2]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


   Proactive Notification - A proactive notification is a message sent
      from a SE to its controller at the time an event occurs.
      Specifically, if a SE asynchronously sends the controller a
      message when it is dynamically partitioned, we say that the SE has
      proactively notified its controller of the resource
      reapportionment.

   Explicit Reactive Notification - In explicit reactive notification,
      the SE does not asynchronously send a message when dynamic
      partitioning occurs.  Instead, the SE includes an explicit,
      resources-reassigned error code in the response to a subsequent
      request by the controller for an unavailable resource.

   Implicit Reactive Notification - This is similar to an Explicit
      Reactive Notification except that the protocol does not contain
      any explicit resources-reassigned error codes.  In this case, all
      that the SE can do is to indicate that some general, unknown error
      or generic resource error (i.e., some resource error problem has
      occurred but the exact cause is not specified) has occurred when
      the controller attempts to use unavailable resources.  In such
      cases, the controller may attempt to determine whether a resource
      shortfall caused the error by using whatever messages are
      available through the control protocol to query available
      resources.

2.  Introduction

   This document identifies the logical entities involved in the
   partitioning of switching elements.  Furthermore, this document
   provides a set of requirements for the behavior of these logical
   entities as well as the protocols used by these logical entities to
   communicate with one another.  A primary goal of the requirements
   specified herein is to allow the resources allocated to a partition
   to be increased or decreased while the partition is currently active
   (i.e., it has an active connection with a controller).  This document
   is primarily intended to facilitate the partitioning of GSMP
   switches.  However, while we believe that the logical entities and
   requirements specified here are necessary for the partitioning of
   non-GSMP switches and (longest prefix match) forwarders (e.g.,
   routers), we do not believe that these requirements are necessarily
   sufficient for the partitioning of those devices.

   Three logical entities are involved in the partitioning and control
   of a SE.  First, a switching element (for the purposes of this
   document) is a device that "switches" packets, whose resources can be
   partitioned and whose partitions can each be controlled by a single
   controller.  This partitioning also implies the ability to enforce
   this division of resources between competing partitions.  Second, the



Anderson, et al.             Informational                      [Page 3]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


   partition manager (PM) is a management entity that specifies the
   number of virtual SEs into which the SE should be partitioned and the
   resources to be allocated to each virtual SE.  Lastly, a controller
   directs the use of the resources of one or more partitions to provide
   a set of services.

   In the rest of this document, we will deal exclusively with logical
   entities although it is worth noting here that there are many
   possible mappings of logical entities to physical entities.  For
   example, there may be multiple logical controllers running on a
   single physical processor (and for convenience we may refer to this
   processor as a physical controller).  Conversely, a single logical
   controller could consist of processes running on multiple physical
   processors collaborating to provide proper control.  Likewise, there
   may be multiple partition managers running on a single management
   workstation.  A switching element may consist of one or more whole or
   fractional physical elements.  For example, a SE may be a single
   whole physical switch (e.g., blade in a chassis), multiple whole
   physical switches (e.g., two blades in a chassis made to appear as a
   single logical entity), a single fraction of a physical switch (which
   would enable nested partitions), or multiple fractions of either the
   same or different physical switches (e.g., ports 1-3 on blade 1 and
   ports 2-4 on blade 2).  Finally, any combination of these logical
   entities could theoretically be co-located on the same physical
   resources.

   However, for many reasons, the physical realm often reflects this
   logical division of functionality.  To facilitate this division,
   several protocols, such as MEGACO [RFC3015] and GSMP [RFC3292], exist
   that allow control functionality to be physically separated from
   switching functionality.  Recently, some regulatory environments have
   mandated multi-provider access to a single physical infrastructure.
   To satisfy these regulations, a common use of partitioning will be
   for the owner of the SE to partition the SE into several virtual SEs
   and then to lease these to third parties. In this case, the PM will
   likely be physically separate from all of the controllers.  For
   locality (and therefore ease) of management, SEs will be remotely
   configurable and thus the PM will be physically separated from the
   SE.  The following illustration depicts this arrangement.  The dashed
   lines indicate interactions between the entities and are labeled with
   the cardinality of the relationship between the entities.










Anderson, et al.             Informational                      [Page 4]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


           ------------------             -------------------
           |                | *         * |                 |
           |    Partition   |-------------|   Controller    |
           |     Manager    |      C      |                 |
           ------------------             -------------------
                         1 \                / *
                            \              /
                             \ A        B /
                              \          /
                             * \        / *
                           ------------/------
                           |  --------/---   |
                           |  |Partition |   |
                           |  |          |   |
                           |  ------------   |
                           |Switching element|
                           -------------------

   Interaction A is one in which the PM partitions the SE and allocates
   resources to the partitions it creates.  There is a one-to-many
   relationship between PMs and SEs.  In order to support dynamic
   partitioning, this document will place certain requirements on
   proposed (or new) solutions in this space.

   Interaction B is one in which the controller configures and manages
   an active partition.  Current protocols implementing this interaction
   include GSMP [RFC3292] and MEGACO [RFC3015].  These protocols allow a
   many-to-many relationship between controller and partition.

   Interaction C is one by which a PM and a controller could communicate
   to alter the nature of an active partition.  There is a many-to-many
   relationship between PMs and controllers.  For example, there are
   multiple PMs per controller in the case where a controller is
   managing two partitions from different SEs and there are multiple
   controllers per PM in the case where a SE has two partitions each
   managed by a different controller.  Possible types of interactions
   between PM and controller include:

   -  A controller could request that the resources of one of its active
      partitions be altered; either increased or decreased.

   -  The PM could respond to a controller request for altered resource
      levels.

   -  The PM could request that a controller release resources currently
      allocated to one of its active partitions.  This could involve the
      following types of request:




Anderson, et al.             Informational                      [Page 5]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


      -  A request to relinquish allocated, but currently unused
         resources.  That is to put a freeze on additional use of the
         specified resources.

      -  A request to relinquish used resources.

      -  A request to relinquish an active partition.  That is a request
         that a controller release control of an active partition.

      -  The controller's response to a PM request.

   As far as the authors know, no proposed standard solutions currently
   exist for interactions of type C.

3.  Dynamic Partitioning

   Static repartitioning of a SE can be a costly and inefficient
   process.  First, before static repartitioning can take place, all
   existing connections with controllers for the affected partitions
   must be severed.  (This severing must always occur even if the
   resources to be reapportioned are not currently in use.)  When this
   happens, the SE will typically release all the state configured by
   the controller.  Then, the virtual SE must be placed in the "down"
   state while the repartitioning takes place.  Once the repartitioning
   is completed, the partitions are placed in the "up" state and the
   controllers are allowed to reconnect to the partitions.  Then, the
   controllers can reestablish state in those partitions.  Thus, static
   repartitioning results in a period of downtime and a period in which
   the controllers are reestablishing state for affected partitions.
   Partitions of a SE that are not affected by a static resource
   reallocation need not be transitioned to the down state nor would
   controllers have to reestablish state with unaffected partitions.

   Therefore, dynamic partitioning is to be preferred to static
   partitioning since it avoids the downtime and loss of state
   associated with static partitioning.  However, a different set of
   potential problems exists for dynamic partitioning.  Some questions
   to be answered include the following:

   -  How is the controller notified of an increase or decrease in
      resources?

   -  What should happen when the PM would like to decrease the
      resources allocated to a partition but those resources are in use?







Anderson, et al.             Informational                      [Page 6]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


4.  Requirements

   This document does not attempt to answer the preceding questions but
   instead defines a set of requirements that any solution to these
   problems MUST satisfy.

   1.  There MUST be a mechanism by which a PM can create virtual SEs on
       the SE and allocate SE resources to those virtual SEs.

   2.  SEs MUST ensure that controllers do not use more resources than
       those currently allocated to each virtual SE.  Therefore, each
       control protocol MUST provide either an explicit reactive
       notification or an implicit reactive notification to indicate
       resource exhaustion.

   3.  Furthermore, there MUST be a mechanism by which a PM can
       partition all resources discoverable through GSMP (e.g., label
       tables). Partitioning of resources used by GSMP indirectly (e.g.,
       CPU), resources used by non-GSMP switches, or resources (e.g.,
       forwarding table entries) used by forwarding-based network
       elements MAY be supported.

   4.  If a PM instructs a SE to release resources allocated to an
       active partition and if any of those resources are currently in
       use, the SE MUST deny the PM's request.  (Requirement #8
       addresses the potential starvation issues raised by this
       requirement.)

   5.  Subsequent to a resource reallocation failure, the PM SHOULD make
       use of one or both of the capabilities described in requirements
       6 and 7.

   6.  A PM SHOULD be able to tell a SE to make an active partition into
       a frozen partition.

   7.  A PM SHOULD be able to contact the controller to ask it to reduce
       its resource utilization.

   8.  The PM MUST be able to exercise "power on/off" type control of
       the virtual SEs that it has created.  When the virtual power to
       an active partition is turned off, the partition becomes inactive
       and any controllers associated with that partition are
       disconnected. This capability allows a PM to resort to static
       partitioning when a controller is uncooperative about releasing
       resources.  This requirement allows permanent starvation as a
       result of requirement #4 to be avoided.





Anderson, et al.             Informational                      [Page 7]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


   9.  During dynamic repartitioning, a SE MUST maintain all existing
       state associated with the partitions being modified.

   10. Control protocols SHOULD NOT include any mechanism by which a SE
       can ask its controller to reduce its resource usage.

   11. Control protocols MAY contain proactive resource notification
       messages by which a SE could instantaneously inform the
       controller of an increase or decrease in resources.  (We do not
       specifically require control protocols to contain proactive
       notifications because all control protocols must already have
       explicit or implicit reactive notifications as mentioned in
       requirement #2).

   12. A PM MAY directly inform a controller of a change in virtual SE
       resources rather than rely on the implicit resource exhaustion
       mechanism of the control protocol.

   13. SEs MAY inform the PM of resource exhaustion on a particular
       partition.

   14. A controller MAY ask the PM for further resources or a reduction
       in existing resources.

   15. To support the automation of interaction between the PM and
       attached controllers, the PM MUST be able to determine from the
       SE the addresses of the controllers that are currently attached
       to a virtual SE.  Additionally, the SE MAY allow the PM to
       determine which control protocol (and version thereof) is
       currently managing each active partition.

   16. A SE MAY support the ability to have one virtual SE provide a
       service to another virtual SE within the same physical SE.  For
       example, a SE may be configured to provide a virtual link between
       two virtual SEs.  Furthermore:

      a. There MUST be a mechanism by which the SE can inform the PM
         which of these partition-to-partition services are provided by
         the SE.

      b. There MUST be a mechanism by which the PM can configure the
         available partition-to-partition services.

      c. If the configuration of a partition-to-partition service
         results in a virtual port being added/removed from a virtual
         SE, the SE MUST notify all controllers attached to that virtual
         SE (assuming that the corresponding control protocol supports
         such notifications).



Anderson, et al.             Informational                      [Page 8]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


   17. There MUST be a mechanism by which a PM can query a SE to
       determine the resources of that SE, the partitions currently
       configured on that SE and the resources allocated to each
       partition.

5.  Security Considerations

   Only authorized PMs MUST be allowed to dynamically repartition a SE.
   Therefore, SEs MUST use a secure process by which an authorized
   entity may instruct the SE as to which PM should control it.  This
   instruction MAY specify the PM explicitly or MAY specify the use of a
   (discovery) protocol to dynamically locate the PM.  Similarly, only
   the PM (or an authorized agent of the PM) that is authorized to
   partition a SE MUST be allowed to contact controllers to request that
   they decrease their resources or inform them that their resources
   have been increased.  Likewise, the PM MUST verify and authenticate
   that any requests for additional/fewer resources for a virtual SE
   have come from a controller authorized to control the specified
   virtual SE.

6.  Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in RFC 2026.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

7.  Acknowledgements

   The authors would like to acknowledge the contributions of Avri Doria
   and Jonathan Sadler to this document.





Anderson, et al.             Informational                      [Page 9]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


8.  Normative References

   [RFC2119]  Bradner, S. "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3292]  Doria, A., Hellstrand, F., Sundell, K. and T. Worster,
              "General Switch Management Protocol (GSMP) V3", RFC 3292,
              June 2002.

9.  Informative References

   [RFC3015]  Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosem, B.
              and J. Segers, "Megaco Protocol 1.0," RFC 3015, November
              2000.

10. Authors' Addresses

   Todd A. Anderson
   Intel Labs
   JF2-60
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA

   Phone: +1 503 712 1760
   EMail: todd.a.anderson@intel.com


   Joachim Buerkle
   Nortel Networks Germany GmbH & Co. KG
   Hahnstrasse 37-39
   60528 Frankfurt

   Phone:  ++49 (0)69 6697 3281
   EMail: joachim.buerkle@nortelnetworks.com

















Anderson, et al.             Informational                     [Page 10]
^L
RFC 3532       Dynamic Partitioning of Switching Elements       May 2003


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Anderson, et al.             Informational                     [Page 11]
^L