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.




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
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.

パケットスイッチ装置(例えば、ATMスイッチまたはMPLS LSR)は、そのリソース独立異なるコントローラによって制御することができるそれぞれがパーティションに分割することができ、 - スイッチング素子。

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

パーティション - パーティション要素(SE)リソースを切り替えるのセットです。パーティションは、仮想のSEと呼ばれています。

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.

冷凍パーティション - 凍結されたパーティションがシャットダウン中であるアクティブパーティションです。凍結されたパーティションの未使用のリソースが放棄されていますが、現在のすべての接続は、コントローラによって除去されるまでに放置されています。接続が閉じると、リソースが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.

決定論的パーティションは、 - 決定論的分割では、各アクティブパーティションは、各リソースの割り当て量が与えられます。 1つのアクティブパーティション内のリソースの使用量は、別のアクティブパーティションに利用可能なリソースに影響を与えることはありません。これらの要件のすべての議論は決定論的分割の使用を前提と。

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.

統計パーティション - 統計的なパーティショニングでは、一部またはすべてのリソースがアクティブパーティション間でプールされ、そして割り当ては割合にまたはいくつかの他のメトリックに基づいてもよいです。統計的なパーティションの議論は、これらの要件の範囲外です。

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.

事前通知 - 事前通知は、イベントが発生した時に、そのコントローラにSEから送信されたメッセージです。 SEは非同期コントローラにそれを動的に分割されているメッセージを送信した場合具体的に、私たちは、SEは、積極的に資源再割当てのそのコントローラに通知したと言います。

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.

明示的なリアクティブ通知 - 動的パーティショニングが発生したときに、明示的な反応性の通知では、SEは非同期にメッセージを送信しません。その代わりに、SEが使用不可リソースのコントローラによる後続の要求に応答して、明示的な、リソース・再割り当てエラーコードを含みます。

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.

暗黙の反応通知 - このプロトコルは、明示的な資源・再割り当てのエラーコードが含まれていないことを除き、明示的な反応性の通知に似ています。この場合は、SEが行うことができ、すべてのコントローラが利用できないリソースを使用しようとしたときに、いくつかの一般的な、未知のエラーまたは汎用リソース・エラーが(つまり、いくつかのリソース・エラーの問題が発生しているが、正確な原因が指定されていない)が発生したことを示すためであります。このような場合、コントローラは、リソース不足が利用可能なリソースを照会するために制御プロトコルを介して利用可能であるどのようなメッセージ使用してエラーの原因となったか否かを決定しようと試みることができます。

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 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.

しかし、多くの理由のために、物理的なレルムは、多くの場合、この機能の論理的に分割を反映しています。この分割、例えばMEGACO [RFC3015]とGSMP [RFC3292]などのいくつかのプロトコルを容易にするために、その制御機能が物理的に機能の切り替えから分離することを可能にする存在します。最近、いくつかの規制環境は、単一の物理インフラへのマルチプロバイダのアクセスを義務付けています。これらの規制を満たすために、パーティショニングの一般的な使用は、いくつかの仮想のSEにSEを分割するSEの所有者となり、その後、第三者にこれらをリースします。この場合、PMは、おそらく、すべてのコントローラから物理的に分離されます。地域のために(したがって容易)管理の、SEのリモート構成となり、したがって、PMはSEから物理的に分離されます。次の図は、この構成を示します。破線は、エンティティ間の相互作用を示し、エンティティ間の関係のカーディナリティで標識されます。

           ------------------             -------------------
           |                | *         * |                 |
           |    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.

相互作用Aは、PMがSEを分割し、それが作成したパーティションにリソースを割り当てたものです。 PMとSEの間に1対多の関係があります。動的なパーティショニングをサポートするために、この文書では、この空間に提案(または新しい)ソリューションの一定の要件を配置します。

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.

対話Bは、コントローラがアクティブなパーティションを設定し、管理するものです。この相互作用を実装する現在のプロトコルはGSMP [RFC3292]とMEGACO [RFC3015]を含んでいます。これらのプロトコルは、コントローラとパーティション間の多対多の関係を可能にします。

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:

相互作用Cは、PMとコントローラがアクティブパーティションの性質を変化させるために通信することができるれるものです。 PMとコントローラ間の多対多の関係があります。例えば、コントローラは異なるのSEからの2つのパーティションを管理しているとSEが別のコントローラによって管理される2つのパーティションをそれぞれ有している場合にPMごとに複数のコントローラがある場合は、コントローラごとに複数のPMがあります。 PMとコントローラの間の相互作用の可能なタイプは次のとおりです。

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

- コントローラは、そのアクティブパーティションの1つのリソースが変更されることを要求することができます。増加または減少のいずれか。

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

- PMは、変更されたリソースレベルのためのコントローラ要求に応答することができます。

- 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:

- PMは、コントローラのリリースリソースが現在のアクティブパーティションの1つに割り当てられることを要求することができます。これは、要求の次のタイプを伴うことができます:

- 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.

- PM要求に対するコントローラの応答。

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.

SEの静的再分割はコストがかかり、非効率的なプロセスになることがあります。まず、静的再パーティショニングを行う前、影響を受けたパーティション用のコントローラとすべての既存の接続が切断されなければなりません。 (この切断は常に再配分するためのリソースが現在使用されていない場合でも発生する必要があります。)これが発生した場合、SEは、通常、コントローラによって設定されたすべての状態を解除します。再パーティション化が行われている間そして、仮想SEは「ダウン」状態にしておく必要があります。再分割が完了すると、パーティションは「アップ」状態に置かれており、コントローラは、パーティションへの再接続を許可されています。その後、コントローラは、それらのパーティションの状態を再確立することができます。したがって、静的再区分のダウンタイムの期間をもたらし、コントローラは、影響を受けるパーティションの状態を再確立している期間。静的リソースの再配分に影響されないSEのパーティションはダウン状態に移行する必要はありませんやコントローラが影響を受けていないパーティションで状態を再確立する必要があります。

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?

- PMがパーティションに割り当てられたリソースを減らしたいが、それらのリソースが使用されているとき何が起こるのでしょうか?

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.

1. PMは、SE上に仮想のSEを作成し、それらの仮想のSEにSEリソースを割り当てることが可能な機構が存在しなければなりません。

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.

2. SEがコントローラは、現在、各仮想SEに割り当てられたものより多くのリソースを使用していないことを保証しなければなりません。したがって、各制御プロトコルは、明示的な反応通知またはリソースの枯渇を示すために暗黙的に反応性の通知のいずれかを提供しなければなりません。

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.)

4. PMは、SEがアクティブパーティションに割り当てられたリソースを解放し、それらのリソースのいずれかが現在使用されている場合、SEはPMの要求を拒否しなければならない指示した場合。 (要件#8は、この要件によって発生した可能性の飢餓問題に対処します。)

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.

6. A PMは、凍結されたパーティションにアクティブパーティションを作るためにSEを伝えることができるべきです。

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

7. A PMは、そのリソース使用率を低減することを依頼するコントローラに接続することができるべきです。

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.

8. PMは、それが作成した仮想のSEの型制御「電源オン/オフ」を行使することができなければなりません。アクティブパーティションの仮想電源をオフにすると、パーティションが非アクティブになり、そのパーティションに関連する任意のコントローラが切断されます。この機能は、コントローラがリソースを解放に関する非協力的であるとき、PMは、静的なパーティショニングに頼ることができます。この要件を回避するための要件#4の結果として永久的な飢餓を可能にします。

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).

11.制御プロトコルは、SEが瞬時にリソースの増減のコントローラに通知することができたことにより、積極的なリソースの通知メッセージを含むかもしれません。 (要件#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.

12. A PMは直接仮想SE資源の変化のコントローラに通知するのではなく制御プロトコルの暗黙の資源枯渇のメカニズムに依拠することができます。

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

13. SEが特定のパーティション上の資源の枯渇のPMを通知することができます。

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.

15. PMと接続されているコントローラの間の相互作用の自動化をサポートするために、PMはSEから、現在の仮想SEに接続されているコントローラのアドレスを決定できなければなりません。また、SEは、PMプロトコル(およびそのバージョン)を制御するかを決定することを可能にする、現在アクティブな各パーティションを管理しています。

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:

16. A SEは、一つの仮想SEは、同じ物理SE内の別の仮想SEにサービスを提供していする機能をサポートするかもしれません。例えば、SEは、二つの仮想のSE間の仮想リンクを提供するように構成されてもよいです。さらに:

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.

A。 SEは、これらのパーティション間のサービスはSEによって提供されているPMを知らせることが可能な機構が存在しなければなりません。

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

B。 PMが利用可能パーティション間のサービスを設定できるメカニズムがあるに違いありません。

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).


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.

17. PMは、そのSEのリソース、現在そのSEに構成パーティションと各パーティションに割り当てられたリソースを決定するために、SEを照会することが可能な機構が存在しなければなりません。

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.

IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手順に関する情報は、RFC 2026パブリケーションと利用できるようにするライセンスの保証のために利用可能となる権利の主張のコピー、または試みの結果で見つけることができますIETF事務局から入手することができます実装者またはこの仕様のユーザーによる、このような所有権の使用のための一般的なライセンスまたは許可を取得するために作られました。

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.

IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情​​報を扱ってください。

7. Acknowledgements

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


8. Normative References

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

[RFC2119]ブラドナーの、S. "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

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

[RFC3292]ドリア、A.、Hellstrand、F.、Sundell、K.およびT. Worster、 "一般的なスイッチ管理プロトコル(GSMP)V3"、RFC 3292、2002年6月。

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.

[RFC3015]クエルボ、F.、グリーン、N.、Rayhan、A.、のHuitema、C.、Rosem、B.及びJ. Segers、 "Megacoのプロトコル1.0、" RFC 3015、2000年11月。

10. Authors' Addresses

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

トッドA.アンダーソンインテル・ラボJF2-60 2111 NE 25日アベニューヒルズボロ、OR 97124 USA

Phone: +1 503 712 1760 EMail:

電話:+1 503 712 1760 Eメール

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

ヨアヒムBuerkle Nortel Networksのドイツ社&株式会社KG Hahnstrasse 37-39 60528フランクフルト

Phone: ++49 (0)69 6697 3281 EMail:

電話:++ 49(0)69 6697 3281 Eメール

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.






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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。