[要約] RFC 3532は、スイッチング要素の動的パーティショニングの要件についてのガイドラインです。目的は、ネットワークの効率と柔軟性を向上させるために、スイッチング要素のリソースを効果的に分割することです。

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.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

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.

このドキュメントは、スイッチング要素(ATMスイッチなど)のリソースをパーティションに動的に再配置するために使用されるメカニズムの一連の要件を識別します。これらの要件は、オペレーターがスイッチパーティションを作成し、そのパーティションの第三者への制御をリースする場合に特に重要です。

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
1. 定義

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)リソースのセットです。パーティションは仮想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.

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

統計分割 - 統計分割では、一部またはすべてのリソースがアクティブパーティション間でプールされ、割り当てはパーセンテージまたは他のメトリックに基づいています。統計的パーティションの議論は、これらの要件の範囲外です。

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がコントローラーにメッセージを非同期に送信する場合、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
2. はじめに

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.

このドキュメントは、スイッチング要素のパーティションに関与する論理エンティティを識別します。さらに、このドキュメントは、これらの論理エンティティの動作と、これらの論理エンティティが互いに通信するために使用するプロトコルに関する一連の要件を提供します。ここで指定されている要件の主な目標は、パーティションに割り当てられたリソースを増加または減少させることを可能にすることです(つまり、コントローラーとのアクティブな接続がある)。このドキュメントは、主にGSMPスイッチのパーティションを促進することを目的としています。ただし、ここで指定されている論理エンティティと要件は、非GSMPスイッチと(最長のプレフィックスマッチ)フォワーダー(例えば、ルーター)のパーティションに必要であると考えていますが、これらの要件は必ずしも十分であるとは考えていません。これらのデバイス。

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.

SEのパーティションと制御に3つの論理エンティティが関与しています。第一に、スイッチング要素(このドキュメントの目的のため)は、リソースをパーティション化できるパケットを「切り替える」パケットで、それぞれが単一のコントローラーによって制御できるデバイスです。このパーティション化は、競合するパーティション間でこのリソースの分割を実施する能力も意味します。第二に、パーティションマネージャー(PM)は、SEをパーティション化する必要がある仮想SEの数と、各仮想SEに割り当てるリソースを指定する管理エンティティです。最後に、コントローラーは、1つ以上のパーティションのリソースの使用を指示して、一連のサービスを提供します。

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.

このドキュメントの残りの部分では、論理エンティティのみを扱いますが、ここでは物理エンティティに論理エンティティの多くの可能なマッピングがあることはここで注目に値します。たとえば、単一の物理プロセッサで実行されている複数の論理コントローラーが存在する場合があります(そして、便宜上、このプロセッサを物理コントローラーと呼ぶことができます)。逆に、単一の論理コントローラーは、適切な制御を提供するために協力する複数の物理プロセッサで実行されるプロセスで構成されます。同様に、単一の管理ワークステーションで実行されている複数のパーティションマネージャーがいる場合があります。切り替え要素は、1つ以上の全体または分数の物理要素で構成されている場合があります。たとえば、SEは単一の物理スイッチ(シャーシのブレードなど)、複数の物理スイッチ(たとえば、単一の論理エンティティとして表示されるように作られたシャーシの2つのブレード)、物理スイッチの単一の割合である場合があります。(ネストされたパーティションを有効にします)、または同じまたは異なる物理スイッチのいずれかの複数の画分(たとえば、ブレード1のポート1〜3、ブレード2のポート2〜4)。最後に、これらの論理エンティティの任意の組み合わせは、理論的には同じ物理的リソースに共同住宅を立てることができます。

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はすべてのコントローラーと物理的に分離される可能性があります。管理の地域(したがって容易さ)の場合、SESはリモートで構成可能であるため、PMはSEから物理的に分離されます。次の図は、この配置を示しています。破線はエンティティ間の相互作用を示し、エンティティ間の関係の枢機inalとラベル付けされています。

           ------------------             -------------------
           |                | *         * |                 |
           |    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をパーティションし、作成するパーティションにリソースを割り当てるものです。PMSとSESの間には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とコントローラーがアクティブパーティションの性質を変更するために通信できるものです。PMSとコントローラーの間には、多くの関係があります。たとえば、コントローラーが異なるSESから2つのパーティションを管理している場合、コントローラーごとに複数のPMがあり、SEがそれぞれ異なるコントローラーによって管理されている2つのパーティションがある場合、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.

著者が知る限り、タイプCの相互作用に現在提案されている標準ソリューションは存在しません

3. Dynamic Partitioning
3. 動的パーティション

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を「下」状態に配置する必要があります。再パーティションが完了すると、パーティションは「UP」状態に配置され、コントローラーはパーティションに再接続できます。次に、コントローラーはこれらのパーティションで状態を再確立できます。したがって、静的な再構成は、ダウンタイムの期間と、コントローラーが影響を受けるパーティションの状態を再確立している期間をもたらします。静的リソースの再割り当ての影響を受けない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
4. 要件

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に仮想SESを作成し、それらの仮想SESに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. SESは、現在、各仮想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.

3. さらに、PMがGSMP(ラベルテーブルなど)を通じて発見可能なすべてのリソースをPMが分割できるメカニズムがなければなりません。GSMPが間接的に使用するリソースの分割(CPUなど)、非GSMPスイッチで使用されるリソース、または転送ベースのネットワーク要素で使用されるリソース(例:転送テーブルエントリ)がサポートされる場合があります。

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は、この要件によって提起された潜在的な飢starの問題に対処します。)

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.

5. リソースリアルロケーションの障害に続いて、PMは要件6および7で説明されている機能の一方または両方を使用する必要があります。

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

6. PMは、SEにアクティブなパーティションを凍結パーティションにするように指示できるはずです。

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

7. 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は、作成した仮想SESの「パワーオン/オフ」タイプの制御を行使できる必要があります。アクティブなパーティションへの仮想電力がオフになると、パーティションは非アクティブになり、そのパーティションに関連付けられたコントローラーは切断されます。この機能により、PMは、コントローラーがリソースのリリースについて非協力的である場合、静的なパーティションに頼ることができます。この要件により、要件#4が回避された結果、恒久的な飢starが可能になります。

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

9. 動的な再(SEは、パーティションが変更されていることに関連するすべての既存の状態を維持する必要があります。

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

10. 制御プロトコルには、SEがコントローラーにリソースの使用量を削減するように依頼できるメカニズムを含めるべきではありません。

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. PMは、制御プロトコルの暗黙のリソース排出メカニズムに依存するのではなく、仮想SEリソースの変更をコントローラーに直接通知する場合があります。

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

13. SESは、PMに特定のパーティションでのリソースの疲労を通知する場合があります。

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

14. コントローラーは、PMにさらなるリソースまたは既存のリソースの削減を求める場合があります。

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. SEは、1つの仮想SEに同じ物理SE内の別の仮想SEへのサービスを提供する機能をサポートする場合があります。たとえば、2つの仮想SES間の仮想リンクを提供するように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がPMに、これらのパーティションからパーティション間サービスのどれがSEによって提供されるかを通知できるメカニズムがなければなりません。

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

c. パーティション間サービスの構成により、仮想ポートが仮想SEから追加/削除される場合、SEはその仮想SEに接続されたすべてのコントローラーに通知する必要があります(対応するコントロールプロトコルがそのような通知をサポートしていると仮定します)。

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
5. セキュリティに関する考慮事項

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.

許可されたPMのみが、SEを動的に再構成することを許可する必要があります。したがって、SESは、承認されたエンティティがPMがどのPMを制御するかをSEに指示できる安全なプロセスを使用する必要があります。この命令は、PMを明示的に指定するか、(発見)プロトコルの使用を指定してPMを動的に見つける場合があります。同様に、SEをパーティション化する権限を与えられているPM(またはPMの承認されたエージェント)のみが、リソースを減らすか、リソースが増加したことを通知するように要求するために、コントローラーに連絡することを許可する必要があります。同様に、PMは、仮想SEの追加/少ないリソースのリクエストが、指定された仮想SEを制御するために許可されたコントローラーから来ていることを確認し、認証する必要があります。

6. Intellectual Property Considerations
6. 知的財産の考慮事項

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

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

著者は、この文書へのAvri DoriaとJonathan Sadlerの貢献を認めたいと考えています。

8. Normative References
8. 引用文献

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

[RFC2119] Bradner、S。

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

[RFC3292] Doria、A.、Hellstrand、F.、Sundell、K。およびT. Worster、「General Switch Management Protocol(GSMP)V3」、RFC 3292、2002年6月。

9. Informative References
9. 参考引用

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

[RFC3015] Cuervo、F.、Greene、N.、Rayhan、A.、Huitema、C.、Rosem、B。およびJ. Segers、 "Megaco Protocol 1.0、" RFC 3015、2000年11月。

10. Authors' Addresses
10. 著者のアドレス

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

トッドA.アンダーソンインテルラボJF2-60 2111 NE 25th Avenue Hillsboro、または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

Joachim Buerkle Nortel NetworksドイツGmbh&Co。KG Hahnstrasse 37-39 60528 Frankfurt

   Phone:  ++49 (0)69 6697 3281
   EMail: joachim.buerkle@nortelnetworks.com
        
11. 完全な著作権声明

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

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

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.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。