doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc3532.txt b/doc/rfc/rfc3532.txt
new file mode 100644
index 0000000..81db28a
--- /dev/null
+++ b/doc/rfc/rfc3532.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+