draft-ietf-gsmp-dyn-part-reqs-02.txt   draft-ietf-gsmp-dyn-part-reqs-03.txt 
Internet Draft T. Anderson Internet Draft T. Anderson
Expiration: January 2003 Intel Labs GSMP Working Group Intel Labs
File: draft-ietf-gsmp-dyn-part-reqs-02.txt J. Buerkle Expiration Date: May 2003 J. Buerkle
Nortel Networks Nortel Networks
July 2002 November 2002
Requirements for the Dynamic Partitioning of Switching Elements Requirements for the Dynamic Partitioning of Switching Elements
<draft-ietf-gsmp-dyn-part-reqs-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026.
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also Internet-Drafts are working documents of the Internet Engineering
distribute working documents as Internet-Drafts. Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in reference material or to cite them other than as ``work in
progress.'' progress.''
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in an Internet-Drafts http://www.ietf.org/ietf/1id-abstracts.txt
Shadow Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
Abstract Abstract
This document identifies a set of requirements for the mechanisms This document identifies a set of requirements for the mechanisms
used to dynamically reallocate the resources of a switching element used to dynamically reallocate the resources of a switching element
(e.g., an ATM switch) to its partitions. These requirements are (e.g., an ATM switch) to its partitions. These requirements are
particularly critical in the case of an operator creating a switch particularly critical in the case of an operator creating a switch
partition and then leasing control of that partition to a third partition and then leasing control of that partition to a third
party. party.
Definitions Definitions
In this document, the following definitions will be used. In this document, the following definitions will be used.
Anderson, et. al. Expires May 2003 1
November 2002
Switching Element - A device that switches packets (e.g., an ATM Switching Element - A device that switches packets (e.g., an ATM
switch or MPLS LSR) and whose resources can be divided into switch or MPLS LSR) and whose resources can be divided into
partitions, each of which can be independently controlled by a partitions, each of which can be independently controlled by a
different controller. different controller.
Anderson, et. al. Expires January 2003 1
July 2002
Partition - A partition is a set of switching element (SE) Partition - A partition is a set of switching element (SE)
resources. Partitions are also referred to as virtual SEs. resources. Partitions are also referred to as virtual SEs.
Active Partition - An active partition is a partition in which the Active Partition - An active partition is a partition in which the
resources are in use; either under the direct control of a separate resources are in use; either under the direct control of a separate
controller or under internal policy based control. controller or under internal policy-based control.
Controller - The entity responsible for controlling the operations Controller - The entity responsible for controlling the operations
of an active partition. of an active partition.
Static Partitioning - In static partitioning, no changes can be made Static Partitioning - In static partitioning, no changes can be made
to any active partitions resources without requiring a restart of to any active partition's resources without requiring a restart of
that partition. Instances of repartitioning in which connections to that partition. Instances of repartitioning in which connections to
controllers are disconnected before resources are reallocated controllers are disconnected before resources can be reallocated
therefore fall into this category. therefore fall into this category.
Dynamic Partitioning - In dynamic partitioning, an active Dynamic Partitioning - In dynamic partitioning, an active
partitions resources can be reapportioned without requiring a partition's resources can be reapportioned without requiring a
restart of the partition. restart of the partition.
Frozen Partition - A frozen partition is an active partition that is Frozen Partition - A frozen partition is an active partition that is
in the process of being shutdown. A frozen partition's unused in the process of being shutdown. A frozen partition's unused
resources are relinquished, but all current connections are allowed resources are relinquished, but all current connections are allowed
to remain until removed by the controller. As connections close the to remain until removed by the controller. As connections close,
resources are returned to the SE. the resources are returned to the SE.
Deterministic Partitioning - In deterministic partitioning, each Deterministic Partitioning - In deterministic partitioning, each
active partition is given an allotted quantity of each resource. active partition is given an allotted quantity of each resource.
The usage of resources in one active partition does not influence The usage of resources in one active partition does not influence
the resources available to another active partition. All the resources available to another active partition. All
discussions in these requirements presuppose the use of discussions in these requirements presuppose the use of
deterministic partitioning. deterministic partitioning.
Statistical Partitioning - In statistical partitioning, some or all Statistical Partitioning - In statistical partitioning, some or all
resources are pooled among the active partitions, and allocations resources are pooled among the active partitions, and allocations
skipping to change at line 101 skipping to change at line 107
statistical partitions is outside the scope of these requirements. statistical partitions is outside the scope of these requirements.
Proactive Notification - A proactive notification is a message sent Proactive Notification - A proactive notification is a message sent
from a SE to its controller at the time an event occurs. from a SE to its controller at the time an event occurs.
Specifically, if a SE asynchronously sends the controller a message Specifically, if a SE asynchronously sends the controller a message
when it is dynamically partitioned, we say that the SE has when it is dynamically partitioned, we say that the SE has
proactively notified its controller of the resource reapportionment. proactively notified its controller of the resource reapportionment.
Explicit Reactive Notification - In explicit reactive notification, Explicit Reactive Notification - In explicit reactive notification,
the SE does not asynchronously send a message when dynamic the SE does not asynchronously send a message when dynamic
partitioning occurs. Instead, the SE includes a "resource changed" partitioning occurs. Instead, the SE includes an explicit,
error code in the response to a subsequent request by the resources-reassigned error code in the response to a subsequent
controller. 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 an
explicit "resource changed" error. In this case, all that the SE
can do is to indicate that some unspecified error has occurred when
the controller attempts to use non-allocated resources.
Anderson, et. al. Expires January 2003 2 Anderson, et. al. Expires January 2003 2
July 2002 November 2002
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.
Introduction Introduction
Several logical entities are involved in the partitioning and This document identifies the logical entities involved in the
control of a SE. First, a switching element (for the purposes of partitioning of switching elements. Furthermore, this document
this draft) is a device that "switches" packets, whose resources can provides a set of requirements for the behavior of these logical
be partitioned and whose partitions can each be controlled by a entities as well as the protocols used by these logical entities to
single controller. (This partitioning also implies the ability to communicate with one another. A primary goal of the requirements
enforce this division of resources between competing partitions). specified herein is to allow the resources allocated to a partition
Second, the partition manager (PM) is a management entity that to be increased or decreased while the partition is currently active
specifies the number of virtual SEs into which the SE should be (i.e., it has an active connection with a controller). This
partitioned and the resources to be allocated to each virtual SE. document is primarily intended to facilitate the partitioning of
Lastly, a controller directs the use of the resources of one or more 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
draft) 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 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. partitions to provide a set of services.
In the rest of this draft, we will deal exclusively with logical In the rest of this draft, we will deal exclusively with logical
entities although it is worth noting here that there are many entities although it is worth noting here that there are many
possible mappings of logical entities to physical entities. For possible mappings of logical entities to physical entities. For
example, there may be multiple logical controllers running on a example, there may be multiple logical controllers running on a
single physical processor (and for convenience we may refer to this single physical processor (and for convenience we may refer to this
processor as a physical controller). Likewise, there may be processor as a physical controller). Conversely, a single logical
multiple partition managers running on a single management controller could consist of processes running on multiple physical
workstation. A switching element may consist of multiple physical processors collaborating to provide proper control. Likewise, there
elements (e.g., some number of blades in a chassis) or fractional may be multiple partition managers running on a single management
physical elements (i.e., nested partitioning). Finally, any workstation. A switching element may consist of one or more whole
combination of these logical entities could theoretically be or fractional physical elements. For example, a SE may be a single
collocated on the same physical resources. 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
Anderson, et. al. Expires January 2003 3
November 2002
(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 collocated on the same
physical resources.
However, for many reasons, the physical realm often reflects this However, for many reasons, the physical realm often reflects this
logical division of functionality. To facilitate this division, logical division of functionality. To facilitate this division,
several protocols, such as MEGACO [RFC3015] and GSMP [GSMPv3], exist several protocols, such as MEGACO [RFC3015] and GSMP [RFC3292],
that allow control functionality to be physically separated from exist that allow control functionality to be physically separated
switching functionality. Recently, some regulatory environments from switching functionality. Recently, some regulatory
have mandated multi-provider access to a single physical environments have mandated multi-provider access to a single
infrastructure. To satisfy these regulations, a common use of physical infrastructure. To satisfy these regulations, a common use
partitioning will be for the owner of the SE to partition the SE 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. 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 In this case, the PM will likely be physically separate from all of
the controllers. For locality (and therefore ease) of management, the controllers. For locality (and therefore ease) of management,
SEs will be remotely configurable and thus the PM will be physically SEs will be remotely configurable and thus the PM will be physically
separated from the SE. The following illustration depicts this separated from the SE. The following illustration depicts this
arrangement. The dashed lines indicate interactions between the arrangement. The dashed lines indicate interactions between the
entities and are labeled with the cardinality of the relationship entities and are labeled with the cardinality of the relationship
between the entities. between the entities.
Anderson, et. al. Expires January 2003 3
July 2002
------------------ ------------------- ------------------ -------------------
| | * * | | | | * * | |
| Partition |-------------| Controller | | Partition |-------------| Controller |
| Manager | C | | | Manager | C | |
------------------ ------------------- ------------------ -------------------
1 \ / * 1 \ / *
\ / \ /
\ A B / \ A B /
\ / \ /
* \ / * * \ / *
skipping to change at line 186 skipping to change at line 218
------------------- -------------------
Interaction A is one in which the PM partitions the SE and allocates 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 resources to the partitions it creates. There is a one-to-many
relationship between PMs and SEs. In order to support dynamic relationship between PMs and SEs. In order to support dynamic
partitioning, this document will place certain requirements on partitioning, this document will place certain requirements on
proposed (or new) solutions in this space. proposed (or new) solutions in this space.
Interaction B is one in which the controller configures and manages Interaction B is one in which the controller configures and manages
an active partition. Current protocols implementing this an active partition. Current protocols implementing this
interaction include GSMP [GSMPv3] and MEGACO [RFC3015]. These interaction include GSMP [RFC3292] and MEGACO [RFC3015]. These
protocols allow a many-to-many relationship between controller and protocols allow a many-to-many relationship between controller and
partition. partition.
Interaction C is one by which a PM and a controller could Interaction C is one by which a PM and a controller could
communicate to alter the nature of an active partition. There is a communicate to alter the nature of an active partition. There is a
Anderson, et. al. Expires January 2003 4
November 2002
many-to-many relationship between PMs and controllers. For example, many-to-many relationship between PMs and controllers. For example,
there are multiple PMs per controller in the case where a controller there are multiple PMs per controller in the case where a controller
is managing two partitions from different SEs and there are multiple is managing two partitions from different SEs and there are multiple
controllers per PM in the case where a SE has two partitions each controllers per PM in the case where a SE has two partitions each
managed by a different controller. Possible types of interactions managed by a different controller. Possible types of interactions
between PM and controller include: between PM and controller include:
- A controller could request that the resources of one of its - A controller could request that the resources of one of its
active partitions be altered; either increased or decreased. active partitions be altered; either increased or decreased.
- The PM could respond to a controller request for altered - The PM could respond to a controller request for altered
resource levels. resource levels.
- The PM could request that a controller release resources - The PM could request that a controller release resources
currently allocated to one of its active partitions. This could currently allocated to one of its active partitions. This could
involve the following types of request: involve the following types of request:
- A request to relinquish allocated but currently unused - A request to relinquish allocated but currently unused
resources. That is to put a freeze on additional use of the resources. That is to put a freeze on additional use of the
specified resources. specified resources.
- A request to relinquish used resources. - A request to relinquish used resources.
- A request to relinquish an active partition. That is - A request to relinquish an active partition. That is
a request that a controller release control of an active a request that a controller release control of an active
partition. partition.
- The controller∆s response to a PM request. - The controller's response to a PM request.
Anderson, et. al. Expires January 2003 4
July 2002
As far as the authors know, no proposed standard solutions currently As far as the authors know, no proposed standard solutions currently
exist for interactions of type C. exist for interactions of type C.
Dynamic Partitioning Dynamic Partitioning
Static repartitioning of a SE can be a costly and inefficient Static repartitioning of a SE can be a costly and inefficient
process. First, before static repartitioning can take place, all process. First, before static repartitioning can take place, all
existing connections with controllers must be severed. When this 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 happens, the SE will typically release all the state configured by
the controller. Then, the virtual SE must be placed in the "down" the controller. Then, the virtual SE must be placed in the "down"
state while the repartitioning takes place. Once the repartitioning state while the repartitioning takes place. Once the repartitioning
is completed, the partitions are placed in the "up" state and the is completed, the partitions are placed in the "up" state and the
controllers are allowed to reconnect to the partitions. Then, the controllers are allowed to reconnect to the partitions. Then, the
controllers can reestablish state in the active partition. Thus, controllers can reestablish state in those partitions. Thus, static
static repartitioning results in a period of downtime and a period repartitioning results in a period of downtime and a period in which
in which the controllers are reestablishing state. This is the case the controllers are reestablishing state for affected partitions.
even if resources that are not currently in use in one partition, Partitions of a SE that are not affected by a static resource
either an active or an inactive partition, are intended for a fully reallocation need not be transitioned to the down state nor would
loaded active partition. controllers have to reestablish state with unaffected partitions.
Therefore, dynamic partitioning is to be preferred to static Therefore, dynamic partitioning is to be preferred to static
partitioning since it avoids the downtime and loss of state partitioning since it avoids the downtime and loss of state
associated with static partitioning. However, a different set of associated with static partitioning. However, a different set of
potential problems exists for dynamic partitioning. Some questions potential problems exists for dynamic partitioning. Some questions
to be answered include the following: to be answered include the following:
- How is the controller notified of an increase or decrease in - How is the controller notified of an increase or decrease in
resources? resources?
- What should happen when the PM would like to decrease the - What should happen when the PM would like to decrease the
resources allocated to a partition but those resources are in resources allocated to a partition but those resources are in
use? use?
Anderson, et. al. Expires January 2003 5
November 2002
Requirements Requirements
This document does not attempt to answer the preceding questions but This document does not attempt to answer the preceding questions but
instead defines a set of requirements that any solution to these instead defines a set of requirements that any solution to these
problems MUST satisfy. problems MUST satisfy.
1. There MUST be a mechanism by which a PM can create virtual SEs on 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. the SE and allocate SE resources to those virtual SEs.
2. SEs MUST ensure that controllers do not use more resources than 2. SEs MUST ensure that controllers do not use more resources than
those currently allocated to each virtual SE. Therefore, each those currently allocated to each virtual SE. Therefore, each
control protocol MUST provide either an explicit reactive control protocol MUST provide either an explicit reactive
notification or an implicit reactive notification to indicate notification or an implicit reactive notification to indicate
resource exhaustion. resource exhaustion.
3. Furthermore, this mechanism MUST support the partitioning of all 3. Furthermore, there MUST be a mechanism by which a PM can partition
resources discoverable through GSMP (e.g., label tables). Other all resources discoverable through GSMP (e.g., label tables).
resources used by GSMP indirectly (e.g., CPU) or resources (e.g., Partitioning of resources used by GSMP indirectly (e.g., CPU),
forwarding table entries) used by other types of SEs MAY be resources used by non-GSMP switches, or resources (e.g.,
supported. 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 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 partition and if any of those resources are currently in use, the
SE MUST deny the PM∆s request. SE MUST deny the PM's request. (Requirement #8 addresses the
Anderson, et. al. Expires January 2003 5 potential starvation issues raised by this requirement.)
July 2002
5. Subsequent to a resource reallocation failure, the PM SHOULD make 5. Subsequent to a resource reallocation failure, the PM SHOULD make
use of one or both of the capabilities described in requirements 6 use of one or both of the capabilities described in requirements 6
and 7. and 7.
6. A PM SHOULD be able to tell a SE to make an active partition into 6. A PM SHOULD be able to tell a SE to make an active partition into
a frozen partition. a frozen partition.
7. A PM SHOULD be able to contact the controller to ask it to reduce 7. A PM SHOULD be able to contact the controller to ask it to reduce
its resource utilization. its resource utilization.
8. The PM MUST be able to exercise "power on/off" type control of the 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 virtual SEs that it has created. When the virtual power to an
active partition is turned off, the partition becomes inactive and active partition is turned off, the partition becomes inactive and
any controllers associated with that partition are disconnected. any controllers associated with that partition are disconnected.
This capability allows a PM to resort to static partitioning when This capability allows a PM to resort to static partitioning when
a controller is uncooperative about releasing resources. a controller is uncooperative about releasing resources. This
requirement allows permanent starvation as a result of requirement
#4 to be avoided.
9. During dynamic repartitioning, a SE MUST maintain all existing 9. During dynamic repartitioning, a SE MUST maintain all existing
state associated with the partitions being modified. state associated with the partitions being modified.
10. Control protocols SHOULD NOT include any mechanism by which a 10. Control protocols SHOULD NOT include any mechanism by which a
SE can ask its controller to reduce its resource usage. SE can ask its controller to reduce its resource usage.
11. Control protocols MAY contain proactive resource notification 11. Control protocols MAY contain proactive resource notification
messages by which a SE could instantaneously inform the controller messages by which a SE could instantaneously inform the controller
of an increase or decrease in resources. (We do not specifically of an increase or decrease in resources. (We do not specifically
require control protocols to contain proactive notifications require control protocols to contain proactive notifications
because all control protocols must already have explicit or because all control protocols must already have explicit or
implicit reactive notifications as mentioned in requirement #2). implicit reactive notifications as mentioned in requirement #2).
12. A PM MAY directly inform a controller of a change in virtual SE 12. A PM MAY directly inform a controller of a change in virtual SE
resources rather than rely on the implicit resource exhaustion resources rather than rely on the implicit resource exhaustion
mechanism of the control protocol. mechanism of the control protocol.
13. SEs MAY inform the PM of resource exhaustion on a particular 13. SEs MAY inform the PM of resource exhaustion on a particular
partition. partition.
14. A controller MAY ask the PM for further resources or a 14. A controller MAY ask the PM for further resources or a
reduction in existing resources. reduction in existing resources.
Anderson, et. al. Expires January 2003 6
November 2002
15. To support the automation of interaction between the PM and 15. To support the automation of interaction between the PM and
attached controllers, the PM MUST be able to determine from the SE attached controllers, the PM MUST be able to determine from the SE
the addresses of the controllers that are currently attached to a the addresses of the controllers that are currently attached to a
virtual SE. Additionally, the SE MAY allow the PM to determine virtual SE. Additionally, the SE MAY allow the PM to determine
which control protocol (and version thereof) is currently managing which control protocol (and version thereof) is currently managing
each active partition. each active partition.
16. A SE MAY support the ability to have one virtual SE provide a 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 service to another virtual SE within the same physical SE. For
example, a SE may be configured to provide a virtual link between example, a SE may be configured to provide a virtual link between
two virtual SEs. Furthermore: two virtual SEs. Furthermore:
a. There MUST be a mechanism by which the SE can inform the PM a. There MUST be a mechanism by which the SE can inform the PM
which of these partition-to-partition services are provided by which of these partition-to-partition services are provided by
the SE. the SE.
b. There MUST be a mechanism by which the PM can configure the b. There MUST be a mechanism by which the PM can configure the
available partition-to-partition services. available partition-to-partition services.
c. If the configuration of a partition-to-partition service c. If the configuration of a partition-to-partition service
results in a virtual port being added/removed from a virtual results in a virtual port being added/removed from a virtual
SE, the SE MUST notify all controllers attached to that virtual SE, the SE MUST notify all controllers attached to that virtual
SE (assuming that the corresponding control protocol supports SE (assuming that the corresponding control protocol supports
such notifications). such notifications).
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.
Security Considerations Security Considerations
Only authorized PMs MUST be allowed to dynamically repartition a SE. Only authorized PMs MUST be allowed to dynamically repartition a SE.
Similarly, only the PM (or an authorized agent of the PM) that is Therefore, SEs MUST use a secure process by which an authorized
Anderson, et. al. Expires January 2003 6 entity may instruct the SE as to which PM should control it. This
July 2002 instruction MAY specify the PM explicitly or MAY specify the use of
authorized to partition a SE MUST be allowed to contact controllers a (discovery) protocol to dynamically locate the PM. Similarly,
to request that they decrease their resources or inform them that only the PM (or an authorized agent of the PM) that is authorized to
their resources have been increased. Likewise, the PM MUST verify partition a SE MUST be allowed to contact controllers to request
and authenticate that any requests for additional/fewer resources that they decrease their resources or inform them that their
for a virtual SE have come from a controller authorized to control resources have been increased. Likewise, the PM MUST verify and
the specified virtual SE. authenticate that any requests for additional/fewer resources for a
virtual SE have come from a controller authorized to control the
specified virtual SE.
Intellectual Property Considerations Intellectual Property Considerations
The IETF is being notified of intellectual property rights claimed No intellectual property rights are being claimed with respect to
in regard to some or all of the specification contained in this this document.
document. For more information, consult the online list of claimed
rights.
Acknowledgements Acknowledgements
The authors would like to acknowledge the contributions of Avri The authors would like to acknowledge the contributions of Avri
Doria and Jonathan Sadler to this draft. Doria and Jonathan Sadler to this draft.
Normative References Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
Anderson, et. al. Expires January 2003 7
November 2002
[RFC3292] A. Doria, et. al., "General Switch Management Protocol [RFC3292] A. Doria, et. al., "General Switch Management Protocol
(GSMP) V3", RFC3292, June 2002. (GSMP) V3", RFC3292, June 2002.
Informative References Informative References
[RFC3015] F. Cuervo, et. al., "Megaco Protocol 1.0," RFC3015, [RFC3015] F. Cuervo, et. al., "Megaco Protocol 1.0," RFC3015,
November 2000. November 2000.
Author Information Author Information
skipping to change at line 376 skipping to change at line 422
Phone: +1 503 712 1760 Phone: +1 503 712 1760
Email: todd.a.anderson@intel.com Email: todd.a.anderson@intel.com
Joachim Buerkle Joachim Buerkle
Nortel Networks Germany GmbH & Co. KG Nortel Networks Germany GmbH & Co. KG
Hahnstrasse 37-39 Hahnstrasse 37-39
60528 Frankfurt 60528 Frankfurt
Phone: ++49 (0)69 6697 3281 Phone: ++49 (0)69 6697 3281
Email: joachim.buerkle@nortelnetworks.com Email: joachim.buerkle@nortelnetworks.com
Anderson, et. al. Expires January 2003 7 Anderson, et. al. Expires January 2003 8
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/