[要約] RFC 3746は、Forwarding and Control Element Separation (ForCES) Frameworkに関する標準化ドキュメントです。その目的は、ネットワークデバイスの転送機能と制御機能を分離するためのフレームワークを提供することです。
Network Working Group L. Yang
Request for Comments: 3746 Intel Corp.
Category: Informational R. Dantu
Univ. of North Texas
T. Anderson
Intel Corp.
R. Gopal
Nokia
April 2004
Forwarding and Control Element Separation (ForCES) Framework
転送および制御要素分離（力）フレームワーク
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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions.
このドキュメントでは、力（要素分離）ネットワーク要素の力（転送および制御要素の分離）のアーキテクチャフレームワークを定義し、関連するエンティティとその相互作用を識別します。
Table of Contents
目次
1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 2
1.2. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction to Forwarding and Control Element Separation
(ForCES) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Control Elements and Fr Reference Point . . . . . . . . . 10
3.2. Forwarding Elements and Fi reference point. . . . . . . . 11
3.3. CE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. FE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
4. Operational Phases . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Pre-association Phase . . . . . . . . . . . . . . . . . . 15
4.1.1. Fl Reference Point . . . . . . . . . . . . . . . . 15
4.1.2. Ff Reference Point . . . . . . . . . . . . . . . . 16
4.1.3. Fc Reference Point . . . . . . . . . . . . . . . . 17
4.2. Post-association Phase and Fp reference point . . . . . . 17
4.2.1. Proximity and Interconnect between CEs and FEs . . 18
4.2.2. Association Establishment. . . . . . . . . . . . . 18
4.2.3. Steady-state Communication . . . . . . . . . . . . 19
4.2.4. Data Packets across Fp reference point . . . . . . 21
4.2.5. Proxy FE . . . . . . . . . . . . . . . . . . . . . 22
4.3. Association Re-establishment. . . . . . . . . . . . . . . 22
4.3.1. CE graceful restart. . . . . . . . . . . . . . . . 23
4.3.2. FE restart . . . . . . . . . . . . . . . . . . . . 24
5. Applicability to RFC 1812. . . . . . . . . . . . . . . . . . . 25
5.1. General Router Requirements . . . . . . . . . . . . . . . 25
5.2. Link Layer. . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Internet Layer Protocols. . . . . . . . . . . . . . . . . 27
5.4. Internet Layer Forwarding . . . . . . . . . . . . . . . . 27
5.5. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
5.6. Application Layer -- Routing Protocols. . . . . . . . . . 29
5.7. Application Layer -- Network Management Protocol. . . . . 29
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
8.1. Analysis of Potential Threats Introduced by ForCES. . . . 31
8.1.1. "Join" or "Remove" Message Flooding on CEs . . . . 31
8.1.2. Impersonation Attack . . . . . . . . . . . . . . . 31
8.1.3. Replay Attack. . . . . . . . . . . . . . . . . . . 31
8.1.4. Attack during Fail Over. . . . . . . . . . . . . . 32
8.1.5. Data Integrity . . . . . . . . . . . . . . . . . . 32
8.1.6. Data Confidentiality . . . . . . . . . . . . . . . 32
8.1.7. Sharing security parameters. . . . . . . . . . . . 33
8.1.8. Denial of Service Attack via External Interface. . 33
8.2. Security Recommendations for ForCES . . . . . . . . . . . 33
8.2.1. Using TLS with ForCES. . . . . . . . . . . . . . . 34
8.2.2. Using IPsec with ForCES. . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References. . . . . . . . . . . . . . . . . . . 37
9.2. Informative References. . . . . . . . . . . . . . . . . . 37
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 40
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
A set of terminology associated with the ForCES requirements is defined in [4] and we only include the definitions that are most relevant to this document here.
力の要件に関連付けられた一連の用語は[4]で定義されており、ここでこのドキュメントに最も関連する定義のみを含めます。
Addressable Entity (AE) - An entity that is directly addressable given some interconnect technology. For example, on IP networks, it is a device to which we can communicate using an IP address; on a switch fabric, it is a device to which we can communicate using a switch fabric port number.
アドレス可能なエンティティ（AE） - 相互接続テクノロジーを考慮して直接アドレス指定できるエンティティ。たとえば、IPネットワークでは、IPアドレスを使用して通信できるデバイスです。スイッチファブリックでは、スイッチファブリックポート番号を使用して通信できるデバイスです。
Physical Forwarding Element (PFE) - An AE that includes hardware used to provide per-packet processing and handling. This hardware may consist of (but is not limited to) network processors, ASICs (Application-Specific Integrated Circuits), or general purpose processors, installed on line cards, daughter boards, mezzanine cards, or in stand-alone boxes.
物理転送要素（PFE） - パケットごとの処理と取り扱いを提供するために使用されるハードウェアを含むAE。このハードウェアは、ネットワークプロセッサ、ASIC（アプリケーション固有の統合サーキット）、またはラインカード、娘ボード、メザニンカード、またはスタンドアロンボックスに設置された汎用プロセッサで構成されている場合があります。
PFE Partition - A logical partition of a PFE consisting of some subset of each of the resources (e.g., ports, memory, forwarding table entries) available on the PFE. This concept is analogous to that of the resources assigned to a virtual switching element as described in [9].
PFEパーティション-PFEで利用可能な各リソースの一部のサブセット（ポート、メモリ、転送テーブルエントリなど）で構成されるPFEの論理パーティション。この概念は、[9]で説明されているように、仮想スイッチング要素に割り当てられたリソースの概念に類似しています。
Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general purpose processor.
物理制御要素（PCE） - 制御機能を提供するために使用されるハードウェアを含むAE。このハードウェアには通常、汎用プロセッサが含まれます。
PCE Partition - A logical partition of a PCE consisting of some subset of each of the resources available on the PCE.
PCEパーティション - PCEで利用可能な各リソースの一部のサブセットで構成されるPCEの論理パーティション。
Forwarding Element (FE) - A logical entity that implements the ForCES Protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed by a CE via the ForCES Protocol. FEs may happen to be a single blade (or PFE), a partition of a PFE, or multiple PFEs.
転送要素（FE） - 力プロトコルを実装する論理的エンティティ。FESは、基礎となるハードウェアを使用して、CEがForce Protocolを介して指示したパケットごとの処理と取り扱いを提供します。FESは、たまたま単一のブレード（またはPFE）、PFEのパーティション、または複数のPFEである可能性があります。
Control Element (CE) - A logical entity that implements the ForCES Protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols. CEs may consist of PCE partitions or whole PCEs.
制御要素（CE） - 力プロトコルを実装し、それを使用してパケットの処理方法を1つ以上のFESに指示する論理的エンティティ。CESは、制御プロトコルやシグナル伝達プロトコルの実行などの機能を処理します。CESは、PCEパーティションまたはPCE全体で構成されている場合があります。
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE.
Force Network Element（NE） - 1つ以上のCESと1つ以上のFESで構成されるエンティティ。NEは通常、外部のエンティティから内部組織を隠し、NEの外側のエンティティへの単一の管理ポイントを表します。
Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element. It is possible for some elements of the NE to be in pre-association phase while other elements are in the post-association phase.
前協会の段階 - FEマネージャー（以下を参照）とCEマネージャー（以下を参照）が、FEとCEが同じネットワーク要素の一部であるべきかどうかを決定している期間。NEの一部の要素は、他の要素が同類後の段階にある間に、同類前の段階にある可能性があります。
Post-association Phase - The period of time during which an FE knows which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another.
関連後の段階 - CEがそれを制御するためにCEがどのCEであるかを知っている期間、およびCEとFEが互いにコミュニケーションを確立している時間を含め、その逆も同様です。
ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES Protocol" refers only to the ForCES post-association phase protocol (see below).
Force Protocol-全体的な力アーキテクチャ内で使用される複数のプロトコルが存在する場合がありますが、「Force Protocol」という用語は、Association Phase Protocolの力のみを指します（以下を参照）。
ForCES Post-Association Phase Protocol - The protocol used for post-association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES Protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. This protocol could be a single protocol or could consist of multiple protocols working together, and may be unicast or multicast based. A separate protocol document will specify this information.
Association Post Association Phase Protocol-CESとFES間の関連性相通信に使用されるプロトコル。このプロトコルは、CE-CE-CE-CE-CE-To-Fe通信、またはFEマネージャーとCEマネージャー間の通信には適用されません。フォースプロトコルは、FESが奴隷であり、CESがマスターであるマスタースレーブプロトコルです。このプロトコルには、通信チャネルの管理（接続確立、ハートビートなど）とコントロールメッセージ自体の両方が含まれます。このプロトコルは、単一のプロトコルであるか、複数のプロトコルで構成されている可能性があり、ユニキャストまたはマルチキャストベースである可能性があります。別のプロトコルドキュメントがこの情報を指定します。
FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use; however, this is currently out of scope. Being a logical entity, an FE manager might be physically combined with any of the other logical entities mentioned in this section.
FEマネージャー - 連想前段階で動作し、FEがどのCE（S）が通信するかを決定する責任がある論理的エンティティ。このプロセスはCE Discoveryと呼ばれ、FEマネージャーが利用可能なCEの機能を学習することが含まれる場合があります。FEマネージャーは、静的構成から事前関連フェーズプロトコル（以下を参照）まで何でも使用して、使用するCE（S）を決定できます。ただし、これは現在範囲外です。論理的なエンティティであるため、FEマネージャーは、このセクションで言及されている他の論理エンティティのいずれかと物理的に組み合わせることができます。
CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which FE to use; however, this is currently out of scope. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section.
CEマネージャー - 連想前段階で動作し、どのFe（S）が通信すべきかを決定する責任がある論理的エンティティ。このプロセスはFe Discoveryと呼ばれ、CEマネージャーが利用可能なFESの機能を学習することが含まれる場合があります。CEマネージャーは、静的構成から前協会前の位相プロトコル（以下を参照）まで何でも使用して、使用するFEを決定できます。ただし、これは現在範囲外です。論理的なエンティティであるため、CEマネージャーは、このセクションで言及されている他の論理エンティティのいずれかと物理的に組み合わせることができます。
Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES Protocol. However, the two capability discovery mechanisms may utilize the same FE model.
事前関連フェーズプロトコル - 使用するCESまたはFESを決定するために使用されるFEマネージャーとCEマネージャーの間のプロトコル。前協会のフェーズプロトコルには、CEおよび/またはFE機能発見メカニズムが含まれる場合があります。この機能発見プロセスは、力プロトコル内で使用されている（および置き換えられない）とはまったく分離されていることに注意してください。ただし、2つの機能発見メカニズムは同じFEモデルを利用する場合があります。
FE Model - A model that describes the logical processing functions of an FE.
Feモデル - Feの論理処理関数を記述するモデル。
ForCES Protocol Element - An FE or CE.
力プロトコル要素 - FeまたはCE。
Intra-FE topology - Representation of how a single FE is realized by combining possibly multiple logical functional blocks along multiple data paths. This is defined by the FE model.
Intra -FEトポロジ - 複数のデータパスに沿って複数の論理機能ブロックを組み合わせることにより、単一のFeがどのように実現されるかを表します。これは、FEモデルによって定義されます。
FE Topology - Representation of how the multiple FEs in a single NE are interconnected. Sometimes it is called inter-FE topology, to be distinguished from intra-FE topology used by the FE model.
Feトポロジ - 単一のNEの複数のFESが相互接続されている方法の表現。時々、FEモデルで使用されるIntra-FEトポロジと区別されると呼ばれることもあります。
Inter-FE topology - See FE Topology.
Inter -FEトポロジ - FEトポロジーを参照してください。
An IP network element (NE) appears to external entities as a monolithic piece of network equipment, e.g., a router, NAT, firewall, or load balancer. Internally, however, an IP network element (NE) (such as a router) is composed of numerous logically separated entities that cooperate to provide a given functionality (such as routing). Two types of network element components exist: control element (CE) in control plane and forwarding element (FE) in forwarding plane (or data plane). Forwarding elements are typically ASIC, network-processor, or general-purpose processor-based devices that handle data path operations for each packet. Control elements are typically based on general-purpose processors that provide control functionality, like routing and signaling protocols.
IPネットワーク要素（NE）は、外部エンティティに、ルーター、NAT、ファイアウォール、ロードバランサーなどのモノリシックなネットワーク機器として表示されます。ただし、内部的には、IPネットワーク要素（NE）（ルーターなど）は、特定の機能（ルーティングなど）を提供するために協力する多数の論理的に分離されたエンティティで構成されています。2種類のネットワーク要素コンポーネントが存在します。コントロールプレーンの制御要素（CE）と転送エレメント（FE）の転送面（またはデータプレーン）です。転送要素は通常、各パケットのデータパス操作を処理するASIC、ネットワークプロセッサ、または汎用プロセッサベースのデバイスです。制御要素は通常、ルーティングやシグナリングプロトコルなどの制御機能を提供する汎用プロセッサに基づいています。
ForCES aims to define a framework and associated protocol(s) to standardize information exchange between the control and forwarding plane. Having standard mechanisms allows CEs and FEs to become physically separated standard components. This physical separation accrues several benefits to the ForCES architecture. Separate components would allow component vendors to specialize in one component without having to become experts in all components. Standard protocol also allows the CEs and FEs from different component vendors to interoperate with each other and hence it becomes possible for system vendors to integrate together the CEs and FEs from different component suppliers. This interoperability translates into increased design choices and flexibility for the system vendors. Overall, ForCES will enable rapid innovation in both the control and forwarding planes while maintaining interoperability. Scalability is also easily provided by this architecture in that additional forwarding or control capacity can be added to existing network elements without the need for forklift upgrades.
フォースは、制御面と転送面の間の情報交換を標準化するためのフレームワークと関連するプロトコルを定義することを目指しています。標準メカニズムを持つことにより、CEとFESは物理的に分離された標準コンポーネントになります。この物理的な分離は、フォースアーキテクチャにいくつかの利点が生じます。個別のコンポーネントにより、コンポーネントベンダーは、すべてのコンポーネントの専門家になることなく、1つのコンポーネントに特化できます。また、標準プロトコルにより、さまざまなコンポーネントベンダーのCESとFESが互いに相互運用できるため、システムベンダーがさまざまなコンポーネントサプライヤーのCEとFEを統合することが可能になります。この相互運用性は、システムベンダーの設計選択と柔軟性の向上につながります。全体として、部隊は、対照機と転送の両方で迅速な革新を可能にしながら、相互運用性を維持します。また、このアーキテクチャによってスケーラビリティは、フォークリフトのアップグレードを必要とせずに追加の転送または制御容量を既存のネットワーク要素に追加できるという点で簡単に提供されます。
------------------------- -------------------------
| Control Blade A | | Control Blade B |
| (CE) | | (CE) |
------------------------- -------------------------
^ | ^ |
| | | |
| V | V
---------------------------------------------------------
| Switch Fabric Backplane |
---------------------------------------------------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
------------ ------------ ------------
|Router | |Router | |Router |
|Blade #1 | |Blade #2 | |Blade #N |
| (FE) | | (FE) | | (FE) |
------------ ------------ ------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
Figure 1. A router configuration example with separate blades.
図1.個別のブレードを備えたルーター構成の例。
One example of such physical separation is at the blade level. Figure 1 shows such an example configuration of a router, with two control blades and multiple forwarding blades, all interconnected into a switch fabric backplane. In such a chassis configuration, the control blades are the CEs while the router blades are the FEs, and the switch fabric backplane provides the physical interconnect for all the blades. Control blade A may be the primary CE while control blade B may be the backup CE providing redundancy. It is also possible to have a redundant switch fabric for high availability support. Routers today with this kind of configuration use proprietary interfaces for messaging between CEs and FEs. The goal of ForCES is to replace such proprietary interfaces with a standard protocol. With a standard protocol like ForCES implemented on all blades, it becomes possible for control blades from vendor X and forwarding blades from vendor Y to work seamlessly together in one chassis.
このような物理的分離の一例は、ブレードレベルです。図1は、2つのコントロールブレードと複数の転送ブレードを備えたルーターのこのような例を示しており、すべてがスイッチファブリックバックプレーンに相互接続されています。このようなシャーシ構成では、コントロールブレードはCESであり、ルーターブレードはFESであり、スイッチファブリックバックプレーンはすべてのブレードの物理的な相互接続を提供します。コントロールブレードAが主要なCEである可能性がありますが、コントロールブレードBは冗長性を提供するバックアップCEである可能性があります。また、高可用性サポートのために冗長スイッチファブリックを持つことも可能です。この種の構成で今日のルーターは、CEとFES間のメッセージングに独自のインターフェイスを使用しています。力の目標は、そのような独自のインターフェイスを標準プロトコルに置き換えることです。すべてのブレードに実装された標準のプロトコルのような力を使用すると、ベンダーXのコントロールブレードとベンダーYの転送ブレードが1つのシャーシでシームレスに一緒に作業できるようになります。
------- -------
| CE1 | | CE2 |
------- -------
^ ^
| |
V V
============================================ Ethernet
^ ^ . . . ^
| | |
V V V
------- ------- --------
| FE#1| | FE#2| | FE#n |
------- ------- --------
^ | ^ | ^ |
| | | | | |
| V | V | V
Figure 2. A router configuration example with separate boxes.
図2.個別のボックスを備えたルーター構成の例。
Another level of physical separation between the CEs and FEs can be at the box level. In such a configuration, all the CEs and FEs are physically separated boxes, interconnected with some kind of high speed LAN connection (like Gigabit Ethernet). These separated CEs and FEs are only one hop away from each other within a local area network. The CEs and FEs communicate to each other by running ForCES, and the collection of these CEs and FEs together become one routing unit to the external world. Figure 2 shows such an example.
CESとFESの間の別のレベルの物理的分離は、ボックスレベルにある可能性があります。このような構成では、すべてのCESとFESは物理的に分離されたボックスであり、何らかの高速LAN接続（ギガビットイーサネットのような）と相互接続されています。これらの分離されたCEとFESは、ローカルエリアネットワーク内で互いに1ホップ離れています。CESとFESは、力を実行することで互いに通信し、これらのCEとFESの収集は一緒に外部の1つのルーティングユニットになります。図2はそのような例を示しています。
In both examples shown here, the same physical interconnect is used for both CE-to-FE and FE-to-FE communication. However, that does not have to be the case. One reason to use different interconnects is that the CE-to-FE interconnect does not have to be as fast as the FE-to-FE interconnect, so the more faster and more expensive connections can be saved for FE-to-FE. The separate interconnects may also provide reliability and redundancy benefits for the NE.
ここに示す両方の例では、同じ物理的相互接続がCE-FEとFE対FE通信の両方に使用されます。ただし、そうである必要はありません。異なる相互接続を使用する理由の1つは、CEからFEの相互接続がFE-FEインターコネクトほど速くなければならないため、FE-FEのためにより高速でより高価な接続を保存できることです。個別の相互接続は、NEの信頼性と冗長性の利点を提供する場合があります。
Some examples of control functions that can be implemented in the CE include routing protocols like RIP, OSPF, and BGP, control and signaling protocols like RSVP (Resource Reservation Protocol), LDP (Label Distribution Protocol) for MPLS, etc. Examples of forwarding functions in the FE include LPM (longest prefix match) forwarder, classifiers, traffic shaper, meter, NAT (Network Address Translators), etc. Figure 3 provides example functions in both CE and FE. Any given NE may contain one or many of these CE and FE functions in it. The diagram also shows that the ForCES Protocol is used to transport both the control messages for ForCES itself and the data packets that are originated/destined from/to the control functions in the CE (e.g., routing packets). Section 4.2.4 provides more detail on this.
CEで実装できる制御機能のいくつかの例には、RIP、OSPF、BGPなどのルーティングプロトコル、RSVP（リソース予約プロトコル）、MPLSのLDP（ラベル分布プロトコル）などの制御およびシグナル伝達プロトコルが含まれます。FEには、LPM（最長のプレフィックスマッチ）転送業者、分類器、トラフィックシェーパー、メーター、NAT（ネットワークアドレス翻訳者）などが含まれます。図3は、CEとFEの両方の機能を示しています。与えられたNEには、これらのCEおよびFE機能の1つまたは多くが含まれている場合があります。また、この図は、力プロトコルが、力自体の制御メッセージと、CEの制御関数（例：ルーティングパケット）に由来する/運命づけられているデータパケットの両方の制御メッセージの両方を輸送するために使用されることを示しています。セクション4.2.4では、これの詳細について説明します。
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
^ ^
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
v v
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
| | | | | | |
|LPM Fwd|Meter |Shaper |NAT |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
| FE resources |
-------------------------------------------------
Figure 3. Examples of CE and FE functions.
図3. CEおよびFE関数の例。
A set of requirements for control and forwarding separation is identified in [4]. This document describes a ForCES architecture that satisfies the architectural requirements of [4] and defines a framework for ForCES network elements and the associated entities to facilitate protocol definition. Whenever necessary, this document uses many examples to illustrate the issues and/or possible solutions in ForCES. These examples are intended to be just examples, and should not be taken as the only or definite ways of doing certain things. It is expected that a separate document will be produced by the ForCES working group to specify the ForCES Protocol.
[4]で、制御と転送の分離のための一連の要件が特定されています。このドキュメントは、[4]のアーキテクチャ要件を満たすForce Architectureについて説明し、Protocolの定義を促進するためのForce Network Elementsと関連するエンティティのフレームワークを定義します。必要に応じて、このドキュメントは多くの例を使用して、力の問題や可能な解決策を説明します。これらの例は、単なる例であることを意図しており、特定のことを行う唯一のまたは明確な方法とみなされるべきではありません。Force Working Groupによって個別の文書が作成されると、Force Protocolを指定することが期待されています。
This section defines the ForCES architectural framework and the associated logical components. This ForCES framework defines components of ForCES NEs, including several ancillary components. These components may be connected in different kinds of topologies for flexible packet processing.
このセクションでは、Forces Architectural Frameworkと関連する論理コンポーネントを定義します。このForce Frameworkは、いくつかの補助コンポーネントを含む力NEのコンポーネントを定義します。これらのコンポーネントは、柔軟なパケット処理のためにさまざまな種類のトポロジに接続されている場合があります。
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE Manager and a CE Ff: Interface between the FE Manager and an FE Fl: Interface between the CE Manager and the FE Manager Fi/f: FE external interface
FP：CE-FEインターフェイスFi：Fe-FeインターフェイスFR：CE-CEインターフェイスFC：CEマネージャーとCE FFの間のインターフェイス：FEマネージャーとFE FLの間のインターフェイス：CEマネージャーとFEマネージャーFIの間のインターフェース/F：FE外部インターフェイス
Figure 4. ForCES Architectural Diagram
図4.建築図を強制します
The diagram in Figure 4 shows the logical components of the ForCES architecture and their relationships. There are two kinds of components inside a ForCES network element: control element (CE) and forwarding element (FE). The framework allows multiple instances of CE and FE inside one NE. Each FE contains one or more physical media interfaces for receiving and transmitting packets from/to the external world. The aggregation of these FE interfaces becomes the NE's external interfaces. In addition to the external interfaces, there must also exist some kind of interconnect within the NE so that the CE and FE can communicate with each other, and one FE can forward packets to another FE. The diagram also shows two entities outside of the ForCES NE: CE Manager and FE Manager. These two ancillary entities provide configuration to the corresponding CE or FE in the pre-association phase (see Section 4.1).
図4の図は、フォースアーキテクチャとその関係の論理コンポーネントを示しています。フォースネットワーク要素の中には、制御要素（CE）と転送要素（FE）の2種類のコンポーネントがあります。このフレームワークは、1つのNE内のCEとFEの複数のインスタンスを許可します。各FEには、外部から外部からパケットを受信および送信するための1つ以上の物理メディアインターフェイスが含まれています。これらのFeインターフェイスの集約は、NEの外部インターフェイスになります。外部インターフェイスに加えて、CEとFEが互いに通信できるように、NE内に何らかの相互接続が存在する必要があり、1つのFEが別のFEにパケットを転送できます。図は、部隊NEの外側の2つのエンティティ、CEマネージャーとFEマネージャーも示しています。これらの2つの補助エンティティは、前協会段階で対応するCEまたはFEに構成を提供します（セクション4.1を参照）。
For convenience, the logical interactions between these components are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown in Figure 4. The FE external interfaces are labeled as Fi/f. More detail is provided in Section 3 and 4 for each of these reference points. All these reference points are important in understanding the ForCES architecture, however, the ForCES Protocol is only defined over one reference point -- Fp.
便利なため、これらのコンポーネント間の論理的相互作用は、図4に示すように、基準点FP、FC、FF、FR、FL、およびFIによってラベル付けされます。FE外部インターフェイスは、FI/Fとしてラベル付けされています。これらの参照ポイントのそれぞれについて、セクション3および4に詳細が記載されています。これらの参照ポイントはすべて、力アーキテクチャを理解する上で重要ですが、Force Protocolは1つの参照ポイント（FP）でのみ定義されます。
The interface between two ForCES NEs is identical to the interface between two conventional routers and these two NEs exchange the protocol packets through the external interfaces at Fi/f. ForCES NEs connect to existing routers transparently.
2つの力NES間のインターフェイスは、2つの従来のルーターとこれら2つのNES間のインターフェイスと同一であり、Fi/Fの外部インターフェイスを介してプロトコルパケットを交換します。力NESは既存のルーターに透過的に接続します。
It is not necessary to define any protocols across the Fr reference point to enable control and forwarding separation for simple configurations like single CE and multiple FEs. However, this architecture permits multiple CEs to be present in a network element. In cases where an implementation uses multiple CEs, the invariant that the CEs and FEs together appear as a single NE must be maintained.
FR参照ポイント全体にプロトコルを定義して、単一CEや複数のFESなどの単純な構成の制御と転送を可能にする必要はありません。ただし、このアーキテクチャにより、複数のCEがネットワーク要素に存在することができます。実装が複数のCESを使用する場合、CESとFESが一緒に表示される不変性は、単一のNEを維持する必要があります。
Multiple CEs may be used for redundancy, load sharing, distributed control, or other purposes. Redundancy is the case where one or more CEs are prepared to take over should an active CE fail. Load sharing is the case where two or more CEs are concurrently active and any request that can be serviced by one of the CEs can also be serviced by any of the other CEs. For both redundancy and load sharing, the CEs involved are equivalently capable. The only difference between these two cases is in terms of how many active CEs there are simultaneously. Distributed control is the case where two or more CEs are concurrently active but certain requests can only be serviced by certain CEs.
複数のCEは、冗長性、負荷共有、分散制御、またはその他の目的に使用できます。冗長性とは、アクティブなCEが失敗した場合に1つ以上のCEが引き継ぐ準備ができている場合です。負荷共有は、2つ以上のCEが同時にアクティブである場合であり、CESのいずれかがサービスを提供できるリクエストは、他のCESのいずれかによってもサービスを提供できます。冗長性と負荷共有の両方について、関係するCESは同等に有能です。これら2つのケースの唯一の違いは、同時にアクティブCEの数が同時にあるという点です。分散制御は、2つ以上のCEが同時にアクティブであるが、特定のリクエストは特定のCESによってのみサービスを提供できる場合です。
When multiple CEs are employed in a ForCES NE, their internal organization is considered an implementation issue that is beyond the scope of ForCES. CEs are wholly responsible for coordinating amongst themselves via the Fr reference point to provide consistency and synchronization. However, ForCES does not define the implementation or protocols used between CEs, nor does it define how to distribute functionality among CEs. Nevertheless, ForCES will support mechanisms for CE redundancy or fail over, and it is expected that vendors will provide redundancy or fail over solutions within this framework.
複数のCEが力NEで使用される場合、その内部組織は、力の範囲を超えた実装の問題と見なされます。CEは、FR基準点を介して自分自身を調整して、一貫性と同期を提供することに完全に責任があります。ただし、力はCES間で使用される実装またはプロトコルを定義するものではなく、CES間で機能を分配する方法を定義しません。それにもかかわらず、部隊はCEの冗長性のメカニズムをサポートするか、失敗し、ベンダーはこのフレームワーク内で冗長性を提供するか、ソリューションを失敗させることが期待されます。
An FE is a logical entity that implements the ForCES Protocol and uses the underlying hardware to provide per-packet processing and handling as directed by a CE. It is possible to partition one physical FE into multiple logical FEs. It is also possible for one FE to use multiple physical FEs. The mapping between physical FE(s) and logical FE(s) is beyond the scope of ForCES. For example, a logical partition of a physical FE can be created by assigning some portion of each of the resources (e.g., ports, memory, forwarding table entries) available on the ForCES physical FE to each of the logical FEs. Such a concept of FE virtualization is analogous to a virtual switching element as described in [9]. If FE virtualization occurs only in the pre-association phase, it has no impact on ForCES. However, if FE virtualization results in a resource change taken from an existing FE (already participating in ForCES post-association phase), the ForCES Protocol needs to be able to inform the CE of such a change via asynchronous messages (see [4], Section 5, requirement #6).
FEは、Force Protocolを実装し、基礎となるハードウェアを使用して、CEが指示したパケットごとの処理と取り扱いを提供する論理的エンティティです。1つの物理的なFEを複数の論理FESに分割することが可能です。また、1つのFEが複数の物理FESを使用することも可能です。物理的なFe（s）と論理Fe（s）のマッピングは、力の範囲を超えています。たとえば、物理FEの論理パーティションは、各ロジカルFESに物理FEで利用可能な各リソース（ポート、メモリ、転送テーブルエントリなど）の一部を割り当てることで作成できます。このようなFE仮想化の概念は、[9]で説明されているように仮想スイッチング要素に類似しています。FE仮想化が事前分類段階でのみ発生する場合、力には影響しません。ただし、FE仮想化が既存のFEから取られたリソースの変更をもたらす場合（既にアソシエーション後の力段階に参加している）、部隊プロトコルは非同期メッセージを介してCEにそのような変更を通知できる必要があります（[4]、参照、セクション5、要件＃6）。
FEs perform all packet processing functions as directed by CEs. FEs have no initiative of their own. Instead, FEs are slaves and only do as they are told. FEs may communicate with one or more CEs concurrently across reference point Fp. FEs have no notion of CE redundancy, load sharing, or distributed control. Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve redundancy, load sharing, or distributed control. The idea is to keep FEs as simple and dumb as possible so that FEs can focus their resources on the packet processing functions. Unless otherwise configured or determined by a ForCEs Protocol exchange, each FE will process authorized incoming commands directed at it as it receives them on a first come first serve basis.
FESは、CESが指示したすべてのパケット処理機能を実行します。FESには独自のイニシアチブがありません。代わりに、FESは奴隷であり、言われたとおりにするだけです。FESは、基準点FPを介して1つ以上のCEと同時に通信する場合があります。FESには、CE冗長性、負荷共有、または分散制御の概念はありません。代わりに、FESはそれらを制御することを許可されたCEからのコマンドを受け入れ、冗長性、負荷共有、または分散コントロールを達成するために自分自身を調整するのはCES次第です。アイデアは、FESがパケット処理機能にリソースを集中できるように、FESを可能な限りシンプルで愚かに保つことです。Force Protocol Exchangeによって特に構成または決定されない限り、各FEは、先着順で受信するため、承認された受信コマンドを処理します。
For example, in Figure 5, FE1 and FE2 can be configured to accept commands from both the primary CE (CE1) and the backup CE (CE2). Upon detection of CE1 failure, perhaps across the Fr or Fp reference point, CE2 is configured to take over activities of CE1. This is beyond the scope of ForCES and is not discussed further.
たとえば、図5では、Fe1とFe2を構成して、プライマリCE（CE1）とバックアップCE（CE2）の両方からコマンドを受け入れるように構成できます。CE1障害を検出すると、おそらくFRまたはFPの基準点を越えて、CE2はCE1の活動を引き継ぐように構成されています。これは力の範囲を超えており、これ以上議論されていません。
Distributed control can be achieved in a similar fashion, without much intelligence on the part of FEs. For example, FEs can be configured to detect RSVP and BGP protocol packets, and forward RSVP packets to one CE and BGP packets to another CE. Hence, FEs may need to do packet filtering for forwarding packets to specific CEs.
分散制御は、FES側の多くの知能なしに、同様の方法で実現できます。たとえば、FESはRSVPおよびBGPプロトコルパケットを検出し、RSVPパケットを1つのCEおよびBGPパケットに別のCEに転送するように構成できます。したがって、FESは、特定のCEにパケットを転送するためのパケットフィルタリングを行う必要がある場合があります。
------- Fr -------
| CE1 | ------| CE2 |
------- -------
| \ / |
| \ / |
| \ / |
| \/Fp |
| /\ |
| / \ |
| / \ |
------- Fi -------
| FE1 |<----->| FE2 |
------- -------
Figure 5. CE redundancy example.
図5. CE冗長性の例。
This architecture permits multiple FEs to be present in an NE. [4] dictates that the ForCES Protocol must be able to scale to at least hundreds of FEs (see [4] Section 5, requirement #11). Each of these FEs may potentially have a different set of packet processing functions, with different media interfaces. FEs are responsible for basic maintenance of layer-2 connectivity with other FEs and with external entities. Many layer-2 media include sophisticated control protocols. The FORCES Protocol (over the Fp reference point) will be able to carry messages for such protocols so that, in keeping with the dumb FE model, the CE can provide appropriate intelligence and control over these media.
このアーキテクチャにより、複数のFEがNEに存在することができます。[4]力プロトコルは、少なくとも数百のFESにスケーリングできる必要があることを指示しています（[4]セクション5、要件＃11を参照）。これらの各FEは、異なるメディアインターフェイスを備えた異なるパケット処理機能のセットを潜在的に持っている可能性があります。FESは、他のFESおよび外部エンティティとのレイヤー2接続の基本的なメンテナンスを担当します。多くのレイヤー2メディアには、洗練されたコントロールプロトコルが含まれます。Force Protocol（FP Reference Pointを超える）は、そのようなプロトコルのメッセージを伝達できるため、Dumb Feモデルに沿ってCEがこれらのメディアに対する適切なインテリジェンスと制御を提供できるようにします。
When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 5, Requirement #3). Packets that enter the NE via one FE and leave the NE via a different FE are transferred between FEs across the Fi reference point. The Fi reference point could be used by FEs to discover their (inter-FE) topology, perhaps during the pre-association phase. The Fi reference point is a separate protocol from the Fp reference point and is not currently defined by the ForCES Protocol.
複数のFESが存在する場合、力では、パケットがNEに1つのFeに到達し、別のFeを介してNEを出ることが必要である必要があります（[4]、セクション5、要件＃3を参照）。1つのFeを介してNEを入力し、異なるFeを介してNEを離れるパケットは、FI参照ポイント全体のFES間に転送されます。FI基準点は、おそらく前協会前の段階で、FESがそれらの（Inter-FE）トポロジを発見するために使用できます。Fi基準点は、FP基準点から個別のプロトコルであり、現在はForce Protocolで定義されていません。
FEs could be connected in different kinds of topologies and packet processing may spread across several FEs in the topology. Hence, logical packet flow may be different from physical FE topology. Figure 6 provides some topology examples. When it is necessary to forward packets between FEs, the CE needs to understand the FE topology. The FE topology may be queried from the FEs by the CEs via the ForCES Protocol, but the FEs are not required to provide that information to the CEs. So, the FE topology information may also be gathered by other means outside of the ForCES Protocol (like inter-FE topology discovery protocol).
FESはさまざまな種類のトポロジーで接続でき、トポロジのいくつかのFESに広がる可能性があります。したがって、論理パケットフローは、物理的なFEトポロジーとは異なる場合があります。図6にトポロジの例をいくつか示します。FES間でパケットを転送する必要がある場合、CEはFEトポロジを理解する必要があります。FEトポロジは、FESからFESからForce Protocolを介して質問される場合がありますが、FESはその情報をCESに提供する必要はありません。したがって、FEトポロジー情報は、Force Protocol以外の他の手段によって収集される場合があります（FE Interpology Discovery Protocolなど）。
-----------------
| CE |
-----------------
^ ^ ^
/ | \
/ v \
/ ------- \
/ +->| FE3 |<-+ \
/ | | | | \
v | ------- | v
------- | | -------
| FE1 |<-+ +->| FE2 |
| |<--------------->| |
------- -------
^ | ^ |
| | | |
| v | v
(a) Full mesh among FE1, FE2, and FE3
(a) Fe1、Fe2、およびFe3の完全なメッシュ
-----------
| CE |
-----------
^ ^ ^ ^
/ | | \
/------ | | ------\
v v v v
------- ------- ------- -------
| FE1 |<->| FE2 |<->| FE3 |<->| FE4 |
------- ------- ------- -------
^ | ^ | ^ | ^ |
| | | | | | | |
| v | v | v | v
(b) Multiple FEs in a daisy chain
(b) デイジーチェーン内の複数のFE
^ |
| v
-----------
| FE1 |<-----------------------|
----------- |
^ ^ |
/ \ |
| ^ / \ ^ | V
v | v v | v ----------
--------- --------- | |
| FE2 | | FE3 |<------------>| CE |
--------- --------- | |
^ ^ ^ ----------
| \ / ^ ^
| \ / | |
| v v | |
| ----------- | |
| | FE4 |<----------------------| |
| ----------- |
| | ^ |
| v | |
| |
|----------------------------------------|
(c) Multiple FEs connected by a ring
(c) リングで接続された複数のFE
Figure 6. Some examples of FE topology
図6. FEトポロジのいくつかの例
CE managers are responsible for determining which FEs a CE should control. It is legitimate for CE managers to be hard-coded with the knowledge of with which FEs its CEs should communicate with. A CE manager may also be physically embedded into a CE and be implemented as a simple keypad or other direct configuration mechanism on the CE. Finally, CE managers may be physically and logically separate entities that configure the CE with FE information via such mechanisms as COPS-PR [7] or SNMP [5].
CEマネージャーは、どのFESが制御すべきかを決定する責任があります。CEマネージャーが、CESがどのFESと通信すべきかについての知識でハードコーディングされることは合法です。CEマネージャーは、CEに物理的に埋め込まれ、CEの単純なキーパッドまたはその他の直接構成メカニズムとして実装される場合があります。最後に、CEマネージャーは、COPS-PR [7]やSNMP [5]などのメカニズムを介してFE情報でCEを構成する物理的および論理的に分離するエンティティである場合があります。
FE managers are responsible for determining with which CE any particular FE should initially communicate. Like CE managers, no restrictions are placed on how an FE manager decides with which CE its FEs should communicate, nor are restrictions placed on how FE managers are implemented. Each FE should have one and only one FE manager, while different FEs may have the same or different FE manager(s). Each manager can choose to exist and operate independently of other manager.
FEマネージャーは、特定のFEが最初に通信するCEを決定する責任があります。CEマネージャーと同様に、FEマネージャーがCEのFESがどのように通信するかを決定する方法に制限はありません。また、FEマネージャーの実装方法に制限はありません。各FEには1つのFEマネージャーのみが必要ですが、異なるFESには同じまたは異なるFEマネージャーがある場合があります。各マネージャーは、他のマネージャーとは独立して存在して運営することを選択できます。
Both FEs and CEs require some configuration to be in place before they can start information exchange and function as a coherent network element. Two operational phases are identified in this framework: pre-association and post-association.
FESとCESの両方が、コヒーレントネットワーク要素として情報交換と機能を開始する前に、ある程度の構成を設置する必要があります。このフレームワークでは、2つの運用段階が特定されています。つまり、前協会と協会後。
The Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining whether an FE and a CE should be part of the same network element. The protocols used during this phase may include all or some of the message exchange over Fl, Ff, and Fc reference points. However, all these may be optional and none of this is within the scope of the ForCES Protocol.
提携前段階は、FEマネージャーとCEマネージャーがFEとCEが同じネットワーク要素の一部であるかどうかを決定している期間です。このフェーズで使用されるプロトコルには、FL、FF、およびFCの参照ポイントを介したすべてまたは一部のメッセージ交換が含まれる場合があります。ただし、これらはすべてオプションである可能性があり、これらのいずれもフォースプロトコルの範囲内ではありません。
CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated. Communication across the Fl reference point is optional in this architecture. No requirements are placed on this reference point.
CEマネージャーとFEマネージャーは、個々のCEとFE、またはCESとFESのセットを関連付ける必要があるかどうかを判断するために、事前関連段階のFL参照ポイント全体で通信することができます。このアーキテクチャでは、FL参照ポイント全体の通信がオプションです。この参照ポイントには要件はありません。
CE managers and FE managers may be operated by different entities. The operator of the CE manager may not want to divulge, except to specified FE managers, any characteristics of the CEs it manages. Similarly, the operator of the FE manager may not want to divulge FE characteristics, except to authorized entities. As such, CE managers and FE managers may need to authenticate one another. Subsequent communication between CE managers and FE managers may require other security functions such as privacy, non-repudiation, freshness, and integrity.
CEマネージャーとFEマネージャーは、さまざまなエンティティによって運営される場合があります。CEマネージャーのオペレーターは、指定されたFEマネージャーを除き、管理するCESの特性を除き、漏らしたくない場合があります。同様に、FEマネージャーのオペレーターは、認定されたエンティティを除いて、FE特性を漏らしたくない場合があります。そのため、CEマネージャーとFEマネージャーは互いに認証する必要がある場合があります。CEマネージャーとFEマネージャー間のその後のコミュニケーションには、プライバシー、非和解、新鮮さ、完全性など、他のセキュリティ機能が必要になる場合があります。
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) | |
1|<------------------------------>| |
| | | |
|(a list of CEs and their attributes) |
2|<-------------------------------| |
| | | |
|(a list of FEs and their attributes) |
3|------------------------------->| |
| | | |
| | | |
|<----------------Fl------------>| |
Figure 7. An example of a message exchange over the Fl reference point
図7. FL参照ポイント上のメッセージ交換の例
Once the necessary security functions have been performed, the CE and FE managers communicate to determine which CEs and FEs should communicate with each other. At the very minimum, the CE and FE managers need to learn of the existence of available FEs and CEs respectively. This discovery process may entail one or both managers learning the capabilities of the discovered ForCES protocol elements. Figure 7 shows an example of a possible message exchange between the CE manager and FE manager over the Fl reference point.
必要なセキュリティ機能が実行されると、CEとFEマネージャーは通信して、どのCEとFESが相互に通信するかを決定します。最低限、CEとFEマネージャーは、それぞれ利用可能なFEとCEの存在を知る必要があります。この発見プロセスには、発見された力プロトコル要素の機能を学習する一方または両方のマネージャーが必要になる場合があります。図7は、FL基準点でのCEマネージャーとFEマネージャーの間の可能なメッセージ交換の例を示しています。
The Ff reference point is used to inform forwarding elements of the association decisions made by the FE manager in the pre-association phase. Only authorized entities may instruct an FE with respect to which CE should control it. Therefore, privacy, integrity, freshness, and authentication are necessary between the FE manager and FEs when the FE manager is remote to the FE. Once the appropriate security has been established, the FE manager instructs the FEs across this reference point to join a new NE or to disconnect from an existing NE. The FE Manager could also assign unique FE identifiers to the FEs using this reference point. The FE identifiers are useful in the post association phase to express FE topology. Figure 8 shows example of a message exchange over the Ff reference point.
FF参照ポイントは、前協会前の段階でFEマネージャーが行った協会の決定の転送要素を通知するために使用されます。CEがそれを制御することに関して、承認されたエンティティのみがFEを指示することができます。したがって、FEマネージャーがFEに遠く離れている場合、FEマネージャーとFESの間では、プライバシー、整合性、新鮮さ、および認証が必要です。適切なセキュリティが確立されると、FEマネージャーは、この参照ポイントを介してFESに新しいNEに参加するか、既存のNEから切断するように指示します。FEマネージャーは、この基準点を使用してFESに一意のFE識別子を割り当てることもできます。FE識別子は、協会後の段階でFEトポロジーを表現するのに役立ちます。図8は、FF参照ポイント上のメッセージ交換の例を示しています。
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) |(security exchange)
1|<------------>|authentication 1|<----------->|authentication
| | | |
|(FE ID, attributes) |(CE ID, attributes)
2|<-------------|request 2|<------------|request
| | | |
3|------------->|response 3|------------>|response
|(corresponding CE ID) |(corresponding FE ID)
| | | |
| | | |
|<-----Ff----->| |<-----Fc---->|
Figure 8. Examples of a message exchange over the Ff and Fc reference points
図8. FFおよびFC参照ポイント上のメッセージ交換の例
Note that the FE manager function may be co-located with the FE (such as by manual keypad entry of the CE IP address), in which case this reference point is reduced to a built-in function.
FEマネージャー関数は、FE（CE IPアドレスの手動キーパッドエントリなど）と共同住宅されている場合があります。この場合、この参照ポイントは組み込み関数に縮小されます。
The Fc reference point is used to inform control elements of the association decisions made by CE managers in the pre-association phase. When the CE manager is remote, only authorized entities may instruct a CE to control certain FEs. Privacy, integrity, freshness, and authentication are also required across this reference point in such a configuration. Once appropriate security has been established, the CE manager instructs the CEs as to which FEs they should control and how they should control them. Figure 8 shows example of a message exchange over the Fc reference point.
FC参照ポイントは、前協会の段階でCEマネージャーが行った協会の決定の制御要素を通知するために使用されます。CEマネージャーがリモートである場合、認定されたエンティティのみがCEに特定のFESを制御するよう指示することができます。このような構成のこの参照ポイント全体で、プライバシー、整合性、新鮮さ、および認証も必要です。適切なセキュリティが確立されると、CEマネージャーは、CESにどのFESを制御すべきか、どのようにそれらを制御するかを指示します。図8は、FC参照ポイント上のメッセージ交換の例を示しています。
As with the FE manager and FEs, configurations are possible where the CE manager and CE are co-located and no protocol is used for this function.
FEマネージャーやFESと同様に、CEマネージャーとCEが共同で構成され、この関数にはプロトコルが使用されない場合に構成が可能です。
The Post-association phase is the period of time during which an FE and CE have been configured with information necessary to contact each other and includes both association establishment and steady-state communication. The communication between CE and FE is performed across the Fp ("p" meaning protocol) reference point. ForCES Protocol is exclusively used for all communication across the Fp reference point.
関連後の段階は、互いに連絡するために必要な情報でFEとCEが構成されており、協会の確立と定常状態のコミュニケーションの両方を含む期間です。CEとFEの間の通信は、FP（「P」を意味するプロトコル）参照ポイント全体で実行されます。Forceプロトコルは、FP参照ポイント全体のすべての通信にのみ使用されます。
The ForCES Working Group has made a conscious decision that the first version of ForCES will be focused on "very close" CE/FE localities in IP networks. Very Close localities consist of control and forwarding elements that are either components in the same physical box, or separated at most by one local network hop ([8]). CEs and FEs can be connected by a variety of interconnect technologies, including Ethernet connections, backplanes, ATM (cell) fabrics, etc. ForCES should be able to support each of these interconnects (see [4] Section 5, requirement #1). When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES Protocol will make use of an existing RFC 2914 [3] compliant L4 protocol with adequate reliability, security, and congestion control (e.g., TCP, SCTP) for transport purposes.
Force Working Groupは、Forceの最初のバージョンがIPネットワークの「非常に近い」CE/FEの地域に焦点を当てるという意識的な決定を下しました。非常に近い局所は、同じ物理ボックス内のコンポーネントであるか、最大で1つのローカルネットワークホップ（[8]）によって分離される制御要素と転送要素で構成されています。CESおよびFESは、イーサネット接続、バックプレーン、ATM（セル）ファブリックなどのさまざまな相互接続テクノロジーによって接続できます。力はこれらの各相互接続をサポートできる必要があります（[4]セクション5、要件＃1を参照）。CESとFESが単一のL3ルーティングホップを超えて分離されると、Force Protocolは、輸送目的のための適切な信頼性、セキュリティ、および混雑制御（TCP、SCTPなど）を備えた既存のRFC 2914 [3]に準拠したL4プロトコルを使用します。。
FE CE
| |
|(Security exchange.) |
1|<--------------------->|
| |
|(Let me join the NE please.)
2|---------------------->|
| |
|(What kind of FE are you? -- capability query)
3|<----------------------|
| |
|(Here is my FE functions/state: use model to
describe)
4|---------------------->|
| |
|(Initial config for FE -- optional)
5|<----------------------|
| |
|(I am ready to go. Shall I?)
6|---------------------->|
| |
|(Go ahead!) |
7|<----------------------|
| |
Figure 9. Example of a message exchange between CE and FE over Fp to establish an NE association
図9. NE関連を確立するためのFPを介したCEとFEの間のメッセージ交換の例
As an example, figure 9 shows some of the message exchange that may happen before the association between the CE and FE is fully established. Either the CE or FE can initiate the connection.
例として、図9は、CEとFEの関連が完全に確立される前に発生する可能性のあるメッセージ交換の一部を示しています。CEまたはFEのいずれかが接続を開始できます。
Security handshake is necessary to authenticate the two communication endpoints to each other before any further message exchange can happen. The security handshake should include mutual authentication and authorization between the CE and FE, but the exact details depend on the security solution chosen by the ForCES Protocol. Authorization can be as simple as checking against the list of authorized end points provided by the FE or CE manager during the pre-association phase. Both authentication and authorization must be successful before the association can be established. If either authentication or authorization fails, the end point must not be allowed to join the NE. After the successful security handshake, message authentication and confidentiality are still necessary for the on-going information exchange between the CE and FE, unless some form of physical security exists. Whenever a packet fails authentication, it must be dropped and a notification may be sent to alert the sender of the potential attack. Section 8 provides more details on the security considerations for ForCES.
さらなるメッセージ交換が発生する前に、2つの通信エンドポイントを相互に認証するために、セキュリティハンドシェイクが必要です。セキュリティハンドシェイクには、CEとFEの間の相互認証と承認を含める必要がありますが、正確な詳細は、フォースプロトコルによって選択されたセキュリティソリューションに依存します。許可は、Asociation Pre-Association段階でFEまたはCEマネージャーが提供する承認されたエンドポイントのリストに対してチェックするのと同じくらい簡単です。協会を確立する前に、認証と承認の両方を成功させる必要があります。認証または承認が失敗した場合、エンドポイントをNEに結合することを許可してはなりません。セキュリティの握手が成功した後、何らかの形の物理的セキュリティが存在しない限り、CEとFEの間の進行中の情報交換には、メッセージ認証と機密性が依然として必要です。パケットが認証に失敗するときはいつでも、ドロップし、通知を送信して送信者に潜在的な攻撃を警告することができます。セクション8では、部隊のセキュリティに関する考慮事項の詳細について説明します。
After the successful security handshake, the FE needs to inform the CE of its own capability and optionally its topology in relation to other FEs. The capability of the FE shall be represented by the FE model, as required in [4] (Section 6, requirement #1). The model would allow an FE to describe what kind of packet processing functions it contains, in what order the processing happens, what kinds of configurable parameters it allows, what statistics it collects, and what events it might throw, etc. Once such information is available to the CE, the CE may choose to send some initial or default configuration to the FE so that the FE can start receiving and processing packets correctly. Such initialization may not be necessary if the FE already obtains the information from its own bootstrap process. Once the necessary initial information is exchanged, the process of association is completed. Packet processing and forwarding at the FE cannot begin until association is established. After the association is established, the CE and FE enter steady-state communication.
セキュリティの握手が成功した後、FEはCEに独自の能力、およびオプションで他のFESに関連してトポロジを通知する必要があります。FEの機能は、[4]（セクション6、要件＃1）に必要なFEモデルで表されるものとします。モデルにより、FEは、どのような種類のパケット処理機能が含まれているか、処理が発生する順序で、どのような構成可能なパラメーターを許可するか、どの統計を収集するか、または投げる可能性のあるイベントなどを説明することができます。CEが利用できるCEは、FEがパケットの受信と処理を正しく開始できるように、初期またはデフォルトの構成をFEに送信することを選択できます。FEがすでに独自のブートストラッププロセスから情報を取得している場合、このような初期化は必要ない場合があります。必要な初期情報が交換されると、関連のプロセスが完了します。FEでのパケット処理と転送は、関連性が確立されるまで開始できません。協会が確立された後、CEとFEは定常状態通信に入ります。
Once an association is established between the CE and FE, the ForCES Protocol is used by the CE and FE over the Fp reference point to exchange information to facilitate packet processing.
CEとFEの間に関連性が確立されると、FPの基準点を介してCEとFEによってForceプロトコルが使用され、パケット処理を容易にするために情報を交換します。
FE CE
| |
|(Add these new routes.)|
1|<----------------------|
| |
|(Successful.) |
2|---------------------->|
| |
| |
|(Query some stats.) |
1|<----------------------|
| |
|(Reply with stats collected.)
2|---------------------->|
| |
| |
|(My port is down, with port #.)
1|---------------------->|
| |
|(Here is a new forwarding table)
2|<----------------------|
| |
Figure 10. Examples of a message exchange between CE and FE over Fp during steady-state communication
図10.定常状態通信中のFPを介したCEとFEの間のメッセージ交換の例
Based on the information acquired through CEs' control processing, CEs will frequently need to manipulate the packet-forwarding behaviors of their FE(s) by sending instructions to FEs. For example, Figure 10 shows message exchange examples in which the CE sends new routes to the FE so that the FE can add them to its forwarding table. The CE may query the FE for statistics collected by the FE and the FE may notify the CE of important events such as port failure.
CESの制御処理を通じて取得された情報に基づいて、CESはFESに命令を送信することにより、Feのパケットフォワードの動作を操作する必要があります。たとえば、図10は、CEがFEに新しいルートを送信して、FEが転送テーブルに追加できるようにするメッセージ交換の例を示しています。CEは、FEとFEによって収集された統計のFEを照会する場合があります。CEは、ポート障害などの重要なイベントについてCEに通知する場合があります。
--------------------- ----------------------
| | | |
| +--------+ | | +--------+ |
| |CE(BGP) | | | |CE(BGP) | |
| +--------+ | | +--------+ |
| | | | ^ |
| |Fp | | |Fp |
| v | | | |
| +--------+ | | +--------+ |
| | FE | | | | FE | |
| +--------+ | | +--------+ |
| | | | ^ |
| Router | | | Router | |
| A | | | B | |
---------+----------- -----------+----------
v ^
| |
| |
------------------->---------------
Figure 11. Example to show data packet flow between two NEs.
図11. 2つのNE間のデータパケットフローを表示する例。
Control plane protocol packets (such as RIP, OSPF messages) addressed to any of NE's interfaces are typically redirected by the receiving FE to its CE, and CE may originate packets and have its FE deliver them to other NEs. Therefore, the ForCES Protocol over Fp not only transports the ForCES Protocol messages between CEs and FEs, but also encapsulates the data packets from control plane protocols. Moreover, one FE may be controlled by multiple CEs for distributed control. In this configuration, the control protocols supported by the FORCES NEs may spread across multiple CEs. For example, one CE may support routing protocols like OSPF and BGP, while a signaling and admission control protocol like RSVP is supported in another CE. FEs are configured to recognize and filter these protocol packets and forward them to the corresponding CE.
NEのいずれかのインターフェイスに宛てられたコントロールプレーンのプロトコルパケット（RIP、OSPFメッセージなど）は通常、受信FEによってCEにリダイレクトされ、CEはパケットを発信し、FEに他のNEに配信する場合があります。したがって、FPを介した力プロトコルは、CESとFES間のForce Protocolメッセージを輸送するだけでなく、コントロールプレーンプロトコルからのデータパケットをカプセル化します。さらに、1つのFEは、分散制御のために複数のCESによって制御される場合があります。この構成では、力によってサポートされる制御プロトコルは、複数のCEに広がる可能性があります。たとえば、1つのCEはOSPFやBGPなどのルーティングプロトコルをサポートする場合がありますが、RSVPのようなシグナリングおよび入学制御プロトコルは別のCEでサポートされています。FESは、これらのプロトコルパケットを認識してフィルタリングし、対応するCEに転送するように構成されています。
Figure 11 shows one example of how the BGP packets originated by router A are passed to router B. In this example, the ForCES Protocol is used to transport the packets from the CE to the FE inside router A, and then from the FE to the CE inside router B. In light of the fact that the ForCES Protocol is responsible for transporting both the control messages and the data packets between the CE and FE over the Fp reference point, it is possible to use either a single protocol or multiple protocols.
図11は、ルーターAによって発生したBGPパケットがルーターBに渡される方法の1つの例を示しています。この例では、力プロトコルを使用して、パケットをCEからルーターA内のFEに輸送し、次にFからFからFAに輸送します。Router B. CEは、FPの基準点でCEとFEの間のデータパケットとデータパケットの両方を輸送する責任があるという事実に照らして、単一のプロトコルまたは複数のプロトコルを使用することが可能です。
In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES Protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. This allows the CE to communicate to the physical FE via the proxy by using ForCES, while the proxy manipulates the physical FE using some intermediary form of communication (e.g., a non-ForCES protocol or DMA). In such an implementation, the combination of the proxy and the physical FE becomes one logical FE entity. It is also possible for one proxy to act on behalf of multiple physical FEs.
物理FEが汎用プロトコルを直接実装できない場合（たとえば、汎用CPUがないため）、プロキシFeを使用して、物理Feの代わりにFP基準点を終了できます。これにより、CEは力を使用してプロキシを介して物理的なFEに通信することができますが、プロキシは何らかの中間の通信形式（例えば、非フォースプロトコルまたはDMA）を使用して物理的なFEを操作します。このような実装では、プロキシと物理FEの組み合わせは、1つの論理的なFEエンティティになります。また、1つのプロキシが複数の物理FESに代わって行動することも可能です。
One needs to be aware of the security implication introduced by the proxy FE. Since the physical FE is not capable of implementing ForCES itself, the security mechanism of ForCES can only secure the communication channel between the CE and the proxy FE, but not all the way to the physical FE. It is recommended that other security mechanisms (including physical security property) be employed to ensure the security between the CE and the physical FE.
プロキシFEによって導入されたセキュリティの意味合いに注意する必要があります。物理FEは力自体を実装できないため、力のセキュリティメカニズムは、CEとプロキシFEの間の通信チャネルのみを保護できますが、物理FEまですべてではありません。CEと物理FEの間のセキュリティを確保するために、他のセキュリティメカニズム（物理セキュリティプロパティを含む）を採用することをお勧めします。
FEs and CEs may join and leave NEs dynamically (see [4] Section 5, requirements #12). When an FE or CE leaves the NE, the association with the NE is broken. If the leaving party rejoins an NE later, to re-establish the association, it may need to re-enter the pre-association phase. Loss of association can also happen unexpectedly due to a loss of connection between the CE and the FE. Therefore, the framework allows the bi-directional transition between these two phases, but the ForCES Protocol is only applicable for the post-association phase. However, the protocol should provide mechanisms to support association re-establishment. This includes the ability for CEs and FEs to determine when there is a loss of association between them, and to restore association and efficient state (re)synchronization mechanisms (see [4] Section 5, requirement #7). Note that security association and state must also be re-established to guarantee the same level of security (including both authentication and authorization) exists before and after the association re-establishment.
FESとCESは、NESを動的に結合して放置する場合があります（[4]セクション5、要件＃12を参照）。FeまたはCEがNEを離れると、NEとの関連が壊れます。退職者が後でNEに再び参加している場合、協会を再確立するために、事前関連段階に再入力する必要があるかもしれません。CEとFEの間の接続が失われたため、関連性の喪失も予想外に発生する可能性があります。したがって、フレームワークにより、これら2つのフェーズ間の双方向の遷移が可能になりますが、Force Protocolは関連する後の段階にのみ適用できます。ただし、プロトコルは、関連性の再確立をサポートするメカニズムを提供する必要があります。これには、CESとFESがそれらの間に関連性が失われる時期を決定し、関連性と効率的な状態（再）同期メカニズムを回復する能力が含まれます（[4]セクション5、要件＃7を参照）。セキュリティ協会と州も再確立されて、協会の再確立の前後に同じレベルのセキュリティ（認証と承認の両方を含む）が存在することを保証する必要があることに注意してください。
When an FE leaves or joins an existing NE that is already in operation, the CE needs to be aware of the impact on FE topology and deal with the change accordingly.
FEがすでに動作している既存のNEを出または結合する場合、CEはFEトポロジーへの影響を認識し、それに応じて変更に対処する必要があります。
The failure and restart of the CE in a router can potentially cause much stress and disruption on the control plane throughout a network because in restarting a CE for any reason, the router loses routing adjacencies or sessions with its routing neighbors. Neighbors who detect the lost adjacency normally re-compute new routes and then send routing updates to their own neighbors to communicate the lost adjacency. Their neighbors do the same thing to propagate throughout the network. In the meantime, the restarting router cannot receive traffic from other routers because the neighbors have stopped using the router's previously advertised routes. When the restarting router restores adjacencies, neighbors must once again re-compute new routes and send out additional routing updates. The restarting router is unable to forward packets until it has re-established routing adjacencies with neighbors, received route updates through these adjacencies, and computed new routes. Until convergence takes place throughout the network, packets may be lost in transient black holes or forwarding loops.
ルーターでのCEの障害と再起動は、何らかの理由でCEを再起動する際に、ルーティングネイバーとの隣接またはセッションをルーティングするため、ネットワーク全体のコントロールプレーンに多くのストレスと混乱を引き起こす可能性があります。失われた隣接を検出する隣人は通常、新しいルートを再計算し、ルーティングアップデートを自分の隣人に送信して、失われた隣接を伝えます。彼らの隣人は、ネットワーク全体に伝播するために同じことをします。それまでの間、再起動ルーターは、近隣が以前に宣伝されていたルーターの使用を停止したため、他のルーターからトラフィックを受信できません。ルーターの再起動が隣接を復元する場合、近隣は再び新しいルートを再計算し、追加のルーティングアップデートを送信する必要があります。再起動ルーターは、近隣のルーティング隣接を再確立し、これらの隣接を介してルートの更新を受け取り、新しいルートを計算するまで、パケットを転送することができません。ネットワーク全体で収束が行われるまで、一時的なブラックホールまたは転送ループでパケットが失われる可能性があります。
A high availability mechanism known as the "graceful restart" has been used by the IP routing protocols (OSPF [11], BGP [12], IS-IS [13]) and MPLS label distribution protocol (LDP [10]) to help minimize the negative effects on routing throughout an entire network caused by a restarting router. Route flap on neighboring routers is avoided, and a restarting router can continue to forward packets that would otherwise be dropped.
「優雅な再起動」として知られる高可用性メカニズムは、IPルーティングプロトコル（OSPF [11]、BGP [12]、IS-IS [13]）およびMPLSラベル分布プロトコル（LDP [10]）で使用されています。ルーターの再起動によって引き起こされるネットワーク全体のルーティングに対するマイナスの影響を最小限に抑えます。隣接するルーターのルートフラップは避けられ、再起動ルーターは、それ以外の場合はドロップされるパケットを転送し続けることができます。
While the details differ from protocol to protocol, the general idea behind the graceful restart mechanism remains the same. With the graceful restart, a restarting router can inform its neighbors when it restarts. The neighbors may detect the lost adjacency but do not recompute new routes or send routing updates to their neighbors. The neighbors also hold on to the routes received from the restarting router before restart and assume they are still valid for a limited time. By doing so, the restarting router's FEs can also continue to receive and forward traffic from other neighbors for a limited time by using the routes they already have. The restarting router then re-establishes routing adjacencies, downloads updated routes from all its neighbors, recomputes new routes, and uses them to replace the older routes it was using. It then sends these updated routes to its neighbors and signals the completion of the graceful restart process.
詳細はプロトコルごとに異なりますが、優雅な再起動メカニズムの背後にある一般的なアイデアは同じままです。優雅な再起動により、再起動するルーターは、再起動時に隣人に通知できます。隣人は、隣接する隣接を検出することができますが、新しいルートを再計算したり、隣人にルーティングの更新を送信したりしません。また、隣人は再起動する前に再起動ルーターから受け取ったルートを保持し、それらがまだ限られた時間に有効であると仮定します。そうすることで、ルーターのFESの再起動は、すでに持っているルートを使用して、他の隣人から限られた時間の間にトラフィックを受け取り、転送することもできます。再起動するルーターは、ルーティングの隣接を再確立し、すべての隣人から更新されたルートをダウンロードし、新しいルートを再コンピタリングし、使用していた古いルートを交換するためにそれらを使用します。次に、これらの更新されたルートを隣人に送信し、優雅な再起動プロセスの完了を示します。
Non-stop forwarding is a requirement for graceful restart. It is necessary so a router can continue to forward packets while it is downloading routing information and recomputing new routes. This ensures that packets will not be dropped. As one can see, one of the benefits afforded by the separation of CE and FE is exactly the ability of non-stop forwarding in the face of the CE failure and restart. The support of dynamic changes to CE/FE association in ForCES also makes it compatible with high availability mechanisms, such as graceful restart.
ノンストップ転送は、優雅な再起動の要件です。ルーターがルーティング情報をダウンロードし、新しいルートを再計算している間、ルーターがパケットを転送し続けることが必要です。これにより、パケットがドロップされないようになります。ご覧のとおり、CEとFEの分離によって得られる利点の1つは、CEの障害と再開に直面して、まさにノンストップ転送の能力です。力におけるCE/FEアソシエーションへの動的な変化のサポートにより、優雅な再起動などの高可用性メカニズムと互換性があります。
ForCES should be able to support a CE graceful restart easily. When the association is established the first time, the CE must inform the FEs what to do in the case of a CE failure. If graceful restart is not supported, the FEs may be told to stop packet processing all together if its CE fails. If graceful restart is supported, the FEs should be told to cache and hold on to its FE state, including the forwarding tables across the restarts. A timer must be included so that the timeout causes such a cached state to eventually expire. Those timers should be settable by the CE.
力は、優雅な再起動を簡単にサポートできるはずです。協会が初めて確立されたとき、CEはCEの障害の場合に何をすべきかをFESに通知する必要があります。優雅な再起動がサポートされていない場合、FESは、CEが失敗した場合にパケット処理をすべて停止するように指示される場合があります。優雅な再起動がサポートされている場合、FESは、再起動全体の転送テーブルを含む、キャッシュしてそのFe状態を保持するように指示する必要があります。タイムアウトがそのようなキャッシュ状態を最終的に期限切れにするように、タイマーを含める必要があります。これらのタイマーは、CEによって設定できる必要があります。
In the same example in Figure 5, assuming CE1 is the working CE for the moment, what would happen if one of the FEs, say FE1, leaves the NE temporarily? FE1 may voluntarily decide to leave the association. Alternatively, FE1 may stop functioning simply due to unexpected failure. In the former case, CE1 receives a "leave-association request" from FE1. In the latter, CE1 detects the failure of FE1 by some other means. In both cases, CE1 must inform the routing protocols of such an event, most likely prompting a reachability and SPF (Shortest Path First) recalculation and associated downloading of new FIBs from CE1 to the other remaining FEs (only FE2 in this example). Such recalculation and FIB updates will also be propagated from CE1 to the NE's neighbors that are affected by the connectivity of FE1.
図5の同じ例では、Ce1が現時点で機能していると仮定すると、FE1の1つ（Fe1がNEを一時的に離れるとどうなりますか？Fe1は自発的に協会を去ることを決定するかもしれません。あるいは、Fe1は、予期しない障害のために単純に機能することを停止する場合があります。前者の場合、CE1はFE1から「休暇分類要求」を受け取ります。後者では、Ce1は他の手段でFe1の故障を検出します。どちらの場合も、CE1はそのようなイベントのルーティングプロトコルに通知する必要があり、CE1から他のFESへの新しいFIBの到達可能性とSPFの再計算と関連するダウンロードを促進する可能性が最も高い（この例ではFE2のみ）。このような再計算とFIBの更新は、Fe1の接続の影響を受けるCE1からNEの近隣にも伝播されます。
When FE1 decides to rejoin again, or when it restarts again after the failure, FE1 needs to re-discover its master (CE). This can be achieved by several means. It may re-enter the pre-association phase and get that information from its FE manager. It may retrieve the previous CE information from its cache, if it can validate the information freshness. Once it discovers its CE, it starts message exchange with the CE to re-establish the association, as outlined in Figure 9, with the possible exception that it might be able to bypass the transport of the complete initial configuration. Suppose that FE1 still has its routing table and other state information from the last association. Instead of re-sending all the information, it may be able to use a more efficient mechanism to re-sync the state with its CE, if such a mechanism is supported by the ForCES Protocol. For example, CRC-32 of the state might give a quick indication of whether or not the state is in-sync with its CE. By comparing its state with the CE first, it sends an information update only if it is needed. The ForCES Protocol may choose to implement similar optimization mechanisms, but it may also choose not to, as this is not a requirement.
Fe1が再び再び参加することを決定した場合、または障害後に再び再起動する場合、Fe1はマスター（CE）を再発見する必要があります。これはいくつかの手段で実現できます。前協会の段階に再び入り、FEマネージャーからその情報を取得する場合があります。情報の鮮度を検証できる場合、以前のCE情報をキャッシュから取得する場合があります。CEを発見すると、図9に概説されているように、CEとのメッセージ交換を開始して、完全な初期構成の輸送をバイパスできる可能性があることを例外として、関連性を再確立します。Fe1がまだルーティングテーブルとその他の状態情報を最後の協会から持っていると仮定します。すべての情報を再配置する代わりに、そのようなメカニズムが力プロトコルによってサポートされている場合、より効率的なメカニズムを使用してCEで状態を再同期することができる場合があります。たとえば、州のCRC-32は、州がCEに皮をつけているかどうかを迅速に示している可能性があります。状態を最初にCEと比較することにより、必要な場合にのみ情報更新を送信します。Force Protocolは、同様の最適化メカニズムを実装することを選択できますが、これは要件ではないため、そうでないことも選択できます。
[4] Section 5, requirement #9 dictates "Any proposed ForCES architecture must explain how that architecture supports all of the router functions as defined in RFC 1812." RFC 1812 [2] discusses many important requirements for IPv4 routers from the link layer to the application layer. This section addresses the relevant requirements in RFC 1812 for implementing IPv4 routers based on ForCES architecture and explains how ForCES satisfies these requirements by providing guidelines on how to separate the functionalities required into the forwarding plane and control plane.
[4] セクション5、要件＃9は、「提案された力のアーキテクチャは、RFC 1812で定義されているすべてのルーター機能をどのようにサポートするかを説明する必要があります。」RFC 1812 [2]は、リンクレイヤーからアプリケーションレイヤーまでのIPv4ルーターの多くの重要な要件について説明します。このセクションでは、Force Architectureに基づいてIPV4ルーターを実装するためのRFC 1812の関連要件に対処し、フォワーディングプレーンとコントロールプレーンに必要な機能を分離する方法に関するガイドラインを提供することにより、Forcesがこれらの要件を満たす方法を説明します。
In general, the forwarding plane carries out the bulk of the per-packet processing that is required at line speed, while the control plane carries most of the computationally complex operations that are typical of the control and signaling protocols. However, it is impossible to draw a rigid line to divide the processing into CEs and FEs cleanly and the ForCES architecture should not limit the innovative approaches in control and forwarding plane separation. As more and more processing power is available in the FEs, some of the control functions that traditionally are performed by CEs may now be moved to FEs for better performance and scalability. Such offloaded functions may include part of ICMP or TCP processing, or part of routing protocols. Once off-loaded onto the forwarding plane, such CE functions, even though logically belonging to the control plane, now become part of the FE functions. Just like the other logical functions performed by FEs, such off-loaded functions must be expressed as part of the FE model so that the CEs can decide how to best take advantage of these off-loaded functions when present on the FEs.
一般に、転送面は、ライン速度で必要なパケットごとの処理の大部分を実行しますが、コントロールプレーンは、コントロールおよびシグナル伝達プロトコルに典型的な計算的に複雑な操作のほとんどを運びます。ただし、処理をCESとFESにきれいに分割するために厳格なラインを描くことは不可能であり、フォースアーキテクチャは、平面分離の制御と転送の革新的なアプローチを制限すべきではありません。FESではますます多くの処理能力が利用可能であるため、伝統的にCESによって実行されていた制御機能のいくつかは、より良いパフォーマンスとスケーラビリティのためにFESに移動するようになりました。このようなオフロードされた関数には、ICMPまたはTCP処理の一部、またはルーティングプロトコルの一部が含まれる場合があります。転送面にオフロードされると、このようなCE機能は、論理的にコントロールプレーンに属していますが、現在はFE関数の一部になります。FESによって実行される他の論理関数と同様に、このようなオフロードされた関数は、FEモデルの一部として表現する必要があります。これにより、CESはFESに存在するときにこれらのオフロードされた関数を最大限に活用する方法を決定できます。
Routers have at least two or more logical interfaces. When CEs and FEs are separated by ForCES within a single NE, some additional interfaces are needed for intra-NE communications, as illustrated in figure 12. This NE contains one CE and two FEs. Each FE has four interfaces; two of them are used for receiving and transmitting packets to the external world, while the other two are for intra-NE connections. CE has two logical interfaces #9 and #10, connected to interfaces #3 and #6 from FE1 and FE2, respectively. Interface #4 and #5 are connected for FE1-FE2 communication. Therefore, this router NE provides four external interfaces (#1, 2, 7, and 8).
ルーターには、少なくとも2つ以上の論理インターフェイスがあります。図12に示すように、CESとFESが単一のNE内の力によって分離されている場合、NEINTRA-NE通信には追加のインターフェイスが必要です。このNEには、1つのCEと2つのFESが含まれています。各FEには4つのインターフェイスがあります。そのうちの2つは、パケットの受信および送信に外部の世界に使用され、他の2つはNEINTRA接続用です。CEには、FE1とFE2のそれぞれインターフェイス＃3と＃6に接続されている2つの論理インターフェイス＃9と＃10があります。インターフェイス＃4と＃5は、FE1-FE2通信に接続されています。したがって、このルーターNEは、4つの外部インターフェイス（＃1、2、7、および8）を提供します。
---------------------------------
| router NE |
| ----------- ----------- |
| | FE1 | | FE2 | |
| ----------- ----------- |
| 1| 2| 3| 4| 5| 6| 7| 8| |
| | | | | | | | | |
| | | | +----+ | | | |
| | | | | | | |
| | | 9| 10| | | |
| | | -------------- | | |
| | | | CE | | | |
| | | -------------- | | |
| | | | | |
-----+--+----------------+--+----
| | | |
| | | |
Figure 12. A router NE example with four interfaces.
図12. 4つのインターフェイスを備えたルーターNEの例。
IPv4 routers must implement IP to support its packet forwarding function, which is driven by its FIB (Forwarding Information Base). This Internet layer forwarding (see RFC 1812 [2] Section 5) functionality naturally belongs to FEs in the ForCES architecture.
IPv4ルーターは、FIB（転送情報ベース）によって駆動されるパケット転送機能をサポートするためにIPを実装する必要があります。このインターネットレイヤー転送（RFC 1812 [2]セクション5を参照）機能は、当然、Force ArchitectureのFESに属します。
A router may implement transport layer protocols (like TCP and UDP) that are required to support application layer protocols (see RFC 1812 [2] Section 6). One important class of application protocols is routing protocols (see RFC 1812 [2] Section 7). In the ForCES architecture, routing protocols are naturally implemented by CEs. Routing protocols require that routers communicate with each other. This communication between CEs in different routers is supported in ForCES by FEs' ability to redirect data packets addressed to routers (i.e., NEs), and the CEs' ability to originate packets and have them delivered by their FEs. This communication occurs across the Fp reference point inside each router and between neighboring routers' external interfaces, as illustrated in Figure 11.
ルーターは、アプリケーション層プロトコルをサポートするために必要なトランスポート層プロトコル（TCPやUDPなど）を実装する場合があります（RFC 1812 [2]セクション6を参照）。アプリケーションプロトコルの重要なクラスの1つは、プロトコルをルーティングすることです（RFC 1812 [2]セクション7を参照）。フォースアーキテクチャでは、ルーティングプロトコルはCESによって自然に実装されています。ルーティングプロトコルでは、ルーターが相互に通信する必要があります。さまざまなルーターのCE間のこの通信は、ルーター（つまり、NES）にアドレス指定されたデータパケットをリダイレクトするFESの能力と、パケットを発信し、FESによって配信するCESの能力によって力でサポートされています。この通信は、図11に示すように、各ルーター内のFP基準点と隣接するルーターの外部インターフェイス間で発生します。
Since FEs own all the external interfaces for the router, FEs need to conform to the link layer requirements in RFC 1812 [2]. Arguably, ARP support may be implemented in either CEs or FEs. As we will see later, a number of behaviors that RFC 1812 mandates fall into this category -- they may be performed by the FE and may be performed by the CE. A general guideline is needed to ensure interoperability between separated control and forwarding planes. The guideline we offer here is that CEs MUST be capable of these kinds of operations while FEs MAY choose to implement them. The FE model should indicate its capabilities in this regard so that CEs can decide where these functions are implemented.
FESはルーターのすべての外部インターフェイスを所有しているため、FESはRFC 1812のリンクレイヤー要件に準拠する必要があります[2]。間違いなく、ARPサポートはCESまたはFESのいずれかで実装できます。後で見るように、RFC 1812がこのカテゴリに委ねる多くの行動は、FEによって実行され、CEによって実行される場合があります。分離された制御面と転送面の間の相互運用性を確保するために、一般的なガイドラインが必要です。ここで提供するガイドラインは、CESがこれらの種類の操作が可能である必要があるのに対し、FESはそれらを実装することを選択できることです。FEモデルは、CESがこれらの機能が実装される場所を決定できるように、この点でその機能を示す必要があります。
Interface parameters, including MTU, IP address, etc., must be configurable by CEs via ForCES. CEs must be able to determine whether a physical interface in an FE is available to send packets or not. FEs must also inform CEs of the status change of the interfaces (like link up/down) via ForCES.
MTU、IPアドレスなどを含むインターフェイスパラメーターは、力を介してCESによって構成可能でなければなりません。CESは、FEの物理インターフェイスがパケットを送信できるかどうかを判断できる必要があります。また、FESは、力を介してインターフェイスのステータス変更（リンクアップ/ダウンなど）をCESに通知する必要があります。
Both FEs and CEs must implement the IP protocol and all mandatory extensions as RFC 1812 specified. CEs should implement IP options like source route and record route while FEs may choose to implement those as well. The timestamp option should be implemented by FEs to insert the timestamp most accurately. The FE must interpret the IP options that it understands and preserve the rest unchanged for use by CEs. Both FEs and CEs might choose to silently discard packets without sending ICMP errors, but such events should be logged and counted. FEs may report statistics for such events to CEs via ForCES.
FESとCESの両方が、RFC 1812が指定したように、IPプロトコルとすべての必須拡張機能を実装する必要があります。CESは、ソースルートやレコードルートなどのIPオプションを実装する必要がありますが、FESもそれらを実装することを選択できます。タイムスタンプオプションはFESによって実装されて、タイムスタンプを最も正確に挿入する必要があります。FEは、CESが使用するために変更されていない残りを理解し、保存するIPオプションを解釈する必要があります。FESとCESの両方が、ICMPエラーを送信せずに静かにパケットを破棄することを選択する場合がありますが、そのようなイベントを記録してカウントする必要があります。FESは、そのようなイベントの統計を力を介してCESに報告する場合があります。
When multiple FEs are involved to process packets, the appearance of a single NE must be strictly maintained. For example, Time-To-Live (TTL) must be decremented only once within a single NE. For example, it can be always decremented by the last FE with egress function.
パケットを処理するために複数のFEが関与する場合、単一のNEの外観を厳密に維持する必要があります。たとえば、時間（TTL）までの時間（TTL）は、単一のNE内で1回だけ減少する必要があります。たとえば、出口関数で最後のFEによって常に減少することができます。
FEs must receive and process normally any packets with a broadcast destination address or a multicast destination address that the router has asked to receive. When IP multicast is supported in routers, IGMP is implemented in CEs. CEs are also required of ICMP support, while it is optional for FEs to support ICMP. Such an option can be communicated to CEs as part of the FE model. Therefore, FEs can always rely upon CEs to send out ICMP error messages, but FEs also have the option of generating ICMP error messages themselves.
FESは、通常、ローターが受信するように要求したブロードキャスト宛先アドレスまたはマルチキャストの宛先アドレスを備えたパケットを通常受信および処理する必要があります。IPマルチキャストがルーターでサポートされている場合、IGMPはCESに実装されます。CESはICMPサポートにも必要ですが、FESがICMPをサポートすることはオプションです。このようなオプションは、FEモデルの一部としてCESに伝達できます。したがって、FESは常にCESに依存してICMPエラーメッセージを送信できますが、FESにはICMPエラーメッセージを自体に生成するオプションもあります。
IP forwarding is implemented by FEs. When the routing table is updated at the CEs, ForCES is used to send the new route entries from the CEs to FEs. Each FE has its own forwarding table and uses this table to direct packets to the next hop interface.
IP転送はFESによって実装されます。ルーティングテーブルがCESで更新されると、CESからFESに新しいルートエントリを送信するために力が使用されます。各FEには独自の転送テーブルがあり、このテーブルを使用して次のホップインターフェイスにパケットを向けます。
Upon receiving IP packets, the FE verifies the IP header and processes most of the IP options. Some options cannot be processed until the routing decision has been made. The routing decision is made after examining the destination IP address. If the destination address belongs to the router itself, the packets are filtered and either processed locally or forwarded to the CE, depending upon the instructions set-up by the CE. Otherwise, the FE determines the next hop IP address by looking in its forwarding table. The FE also determines the network interface it uses to send the packets. Sometimes an FE may need to forward the packets to another FE before packets can be forwarded out to the next hop. Right before packets are forwarded out to the next hop, the FE decrements TTL by 1 and processes any IP options that could not be processed before. The FE performs IP fragmentation if necessary, determines the link layer address (e.g., by ARP), and encapsulates the IP datagram (or each of the fragments thereof) in an appropriate link layer frame and queues it for output on the interface selected.
IPパケットを受信すると、FEはIPヘッダーを検証し、ほとんどのIPオプションを処理します。ルーティングの決定がなされるまで、いくつかのオプションを処理することはできません。ルーティングの決定は、宛先IPアドレスを調べた後に行われます。宛先アドレスがルーター自体に属している場合、パケットはフィルター処理され、CEによって設定された命令に応じて、局所的に処理されるか、CEに転送されます。それ以外の場合、FEは転送テーブルを調べて次のホップIPアドレスを決定します。FEは、パケットの送信に使用するネットワークインターフェイスも決定します。パケットを次のホップに転送する前に、FEが別のFEにパケットを転送する必要がある場合があります。パケットが次のホップに転送される直前に、FEはTTLを1で減少させ、以前に処理できなかったIPオプションを処理します。FEは、必要に応じてIP断片化を実行し、リンクレイヤーアドレス（ARPなど）を決定し、適切なリンクレイヤーフレームにIPデータグラム（またはその各フラグメント）をカプセル化し、選択したインターフェイスの出力をキューにします。
Other options mentioned in RFC 1812 [2] for IP forwarding may also be implemented at FEs, for example, packet filtering.
IP転送用のRFC 1812 [2]で言及されている他のオプションは、たとえばパケットフィルタリングなど、FESでも実装できます。
FEs typically forward packets destined locally to CEs. FEs may also forward exceptional packets (packets that FEs do not know how to handle) to CEs. CEs are required to handle packets forwarded by FEs for whatever reason. It might be necessary for ForCES to attach some meta-data with the packets to indicate the reasons of forwarding from FEs to CEs. Upon receiving packets with meta-data from FEs, CEs can decide to either process the packets themselves, or pass the packets to the upper layer protocols including routing and management protocols. If CEs are to process the packets by themselves, CEs may choose to discard the packets, or modify and re-send the packets. CEs may also originate new packets and deliver them to FEs for further forwarding.
FESは通常、CESに局所的に運命づけられたパケットを転送します。FESは、CESに例外的なパケット（FESが処理する方法がわからない）を転送する場合があります。CESは、何らかの理由でFESによって転送されたパケットを処理する必要があります。FESからCESへの転送の理由を示すために、パケットと一部のメタデータを取り付ける必要があるかもしれません。FESからメタデータを使用してパケットを受信すると、CESはパケット自体を処理するか、ルーティングおよび管理プロトコルを含む上層プロトコルにパケットを渡すことを決定できます。CESがパケットを単独で処理する場合、CESはパケットを破棄するか、パケットを変更して再センドすることを選択できます。また、CESは新しいパケットを発信し、さらに転送するためにFESに配信する場合があります。
Any state change during router operation must also be handled correctly according to RFC 1812. For example, when an FE ceases forwarding, the entire NE may continue forwarding packets, but it needs to stop advertising routes that are affected by the failed FE.
ルーター操作中の状態の変更もRFC 1812に従って正しく処理する必要があります。たとえば、FEが転送を停止する場合、NE全体がパケットを転送し続ける場合がありますが、FEの障害によって影響を受ける広告ルートを停止する必要があります。
The Transport layer is typically implemented at CEs to support higher layer application protocols like routing protocols. In practice, this means that most CEs implement both the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
通常、輸送層はCESで実装され、ルーティングプロトコルなどの高層アプリケーションプロトコルをサポートします。実際には、これはほとんどのCESが送信制御プロトコル（TCP）とユーザーデータグラムプロトコル（UDP）の両方を実装することを意味します。
Both CEs and FEs need to implement the ForCES Protocol. If some layer-4 transport is used to support ForCES, then both CEs and FEs need to implement the L4 transport and ForCES Protocols.
CESとFESの両方が、力プロトコルを実装する必要があります。一部のレイヤー-4輸送が力をサポートするために使用される場合、CESとFESの両方がL4輸送と力のプロトコルを実装する必要があります。
Interior and exterior routing protocols are implemented on CEs. The routing packets originated by CEs are forwarded to FEs for delivery. The results of such protocols (like forwarding table updates) are communicated to FEs via ForCES.
内部および外部ルーティングプロトコルがCESに実装されています。CESから発信されるルーティングパケットは、配信のためにFESに転送されます。このようなプロトコルの結果（転送テーブルの更新など）は、力を介してFESに伝えられます。
For performance or scalability reasons, portions of the control plane functions that need faster response may be moved from the CEs and off-loaded onto the FEs. For example, in OSPF, the Hello protocol packets are generated and processed periodically. When done at the CEs, the inbound Hello packets have to traverse from the external interfaces at the FEs to the CEs via the internal CE-FE channel. Similarly, the outbound Hello packets have to go from the CEs to the FEs and to the external interfaces. Frequent Hello updates place heavy processing overhead on the CEs and can overwhelm the CE-FE channel as well. Since typically there are far more FEs than CEs in a router, the off-loaded Hello packets are processed in a much more distributed and scalable fashion. By expressing such off-loaded functions in the FE model, we can ensure interoperability. However, the exact description of the off-loaded functionality corresponding to the off-loaded functions expressed in the FE model are not part of the model itself and will need to be worked out as a separate specification.
パフォーマンスまたはスケーラビリティの理由により、より速い応答が必要な制御プレーン機能の一部をCESから移動し、FESにオフロードすることができます。たとえば、OSPFでは、Helloプロトコルパケットが生成され、定期的に処理されます。CESで行われた場合、インバウンドハローパケットは、FESの外部インターフェイスから内部CE-FEチャネルを介してCESに移動する必要があります。同様に、アウトバウンドのハローパケットは、CESからFESおよび外部インターフェイスに移動する必要があります。頻繁に更新される更新では、CESに重い処理オーバーヘッドを配置し、CE-FEチャネルを圧倒することもできます。通常、ルーターにはCESよりもはるかに多くのFESがあるため、オフロードされたハローパケットは、はるかに分散したスケーラブルな方法で処理されます。FEモデルでこのようなオフロードされた関数を表現することにより、相互運用性を確保できます。ただし、FEモデルで表されるオフロードされた関数に対応するオフロードされた機能の正確な説明は、モデル自体の一部ではなく、別の仕様として解決する必要があります。
RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". In general, for the post-association phase, most external management tasks (including SNMP) should be done through interaction with the CE in order to support the appearance of a single functional device. Therefore, it is recommended that an SNMP agent be implemented by CEs and that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here such that CEs act in the role of master agent to process SNMP protocol messages while FEs act in the role of subagent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the subagent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols.
RFC 1812 [2]は、「ルーターがSNMPによって管理可能でなければならない」ことも規定しています。一般に、関連後の段階では、単一の機能デバイスの外観をサポートするために、CEとの対話を通じてほとんどの外部管理タスク（SNMPを含む）を実行する必要があります。したがって、SNMPエージェントをCESによって実装し、FESによって受信されたSNMPメッセージをCESにリダイレクトすることをお勧めします。RFC 2741（[6]）で定義されているAgentXフレームワークは、CESがSNMPプロトコルメッセージを処理するマスターエージェントの役割に基づいて行動し、FESがFESに居住するMIBオブジェクトにアクセスできるようにするためにSNMPプロトコルメッセージを処理するように適用される場合があります。マスターエージェント（CE）とサブエージェント（FE）の間のAgentXプロトコルメッセージは、他のアプリケーションレイヤープロトコルからのデータパケットと同様に、力を介してカプセル化および輸送されます。
This document defines an architectural framework for ForCES. It identifies the relevant components for a ForCES network element, including (one or more) FEs, (one or more) CEs, one optional FE manager, and one optional CE manager. It also identifies the interaction among these components and discusses all the major reference points. It is important to point out that, among all the reference points, only the Fp interface between CEs and FEs is within the scope of ForCES. ForCES alone may not be enough to support all desirable NE configurations. However, we believe that ForCES over an Fp interface is the most important element in realizing physical separation and interoperability of CEs and FEs, and hence the first interface that ought to be standardized. Simple and useful configurations can still be implemented with only CE-FE interface being standardized, e.g., single CE with full-meshed FEs.
このドキュメントは、力の建築枠組みを定義しています。（1つ以上）FES、（1つ以上）CES、1つのオプションのFEマネージャー、および1つのオプションのCEマネージャーなど、Force Network要素の関連コンポーネントを識別します。また、これらのコンポーネント間の相互作用を識別し、すべての主要な参照ポイントについて説明します。すべての参照ポイントの中で、CESとFESの間のFPインターフェイスのみが力の範囲内であることを指摘することが重要です。力だけでは、すべての望ましいNE構成をサポートするのに十分ではない場合があります。ただし、FPインターフェイス上の力は、CESとFESの物理的分離と相互運用性を実現する上で最も重要な要素であり、したがって標準化されるべき最初のインターフェイスであると考えています。シンプルで便利な構成は、標準化されているCE-FEインターフェイスのみが標準化されている場合でも実装できます。
Joel M. Halpern gave us many insightful comments and suggestions and pointed out several major issues. T. Sridhar suggested that the AgentX protocol could be used with SNMP to manage the ForCES network elements. Susan Hares pointed out the issue of graceful restart with ForCES. Russ Housley, Avri Doria, Jamal Hadi Salim, and many others in the ForCES mailing list also provided valuable feedback.
Joel M. Halpernは、多くの洞察に富んだコメントと提案を私たちに与え、いくつかの大きな問題を指摘しました。T. Sridharは、AgentXプロトコルをSNMPで使用してForce Network Elementsを管理できることを提案しました。スーザン・ヘレスは、力で優雅な再開の問題を指摘しました。Russ Housley、Avri Doria、Jamal Hadi Salim、およびForce Mailing Listの他の多くも、貴重なフィードバックを提供しました。
The NE administrator has the freedom to determine the exact security configuration that is needed for the specific deployment. For example, ForCES may be deployed between CEs and FEs connected to each other inside a box over a backplane. In such a scenario, physical security of the box ensures that most of the attacks, such as man-in-the-middle, snooping, and impersonation, are not possible, and hence the ForCES architecture may rely on the physical security of the box to defend against these attacks and protocol mechanisms may be turned off. However, it is also shown that denial of service attacks via external interfaces as described below in Section 8.1.8 is still a potential threat, even for such an "all-in-one-box" deployment scenario and hence the rate limiting mechanism is still necessary. This is just one example to show that it is important to assess the security needs of the ForCES-enabled network elements under different deployment scenarios. It should be possible for the administrator to configure the level of security needed for the ForCES Protocol.
NE管理者には、特定の展開に必要な正確なセキュリティ構成を決定する自由があります。たとえば、バックプレーンを介してボックス内で互いに接続されたCEとFESの間に力が配備される場合があります。このようなシナリオでは、ボックスの物理的なセキュリティにより、中間者、スヌーピング、なりすましなどの攻撃のほとんどが不可能であることを保証します。これらの攻撃とプロトコルメカニズムを防御することは、オフになる可能性があります。ただし、セクション8.1.8で説明するように、外部インターフェイスを介したサービス拒否攻撃は、そのような「オールインワンボックス」展開シナリオであっても、潜在的な脅威であることが示されています。したがって、レート制限メカニズムはまだ必要です。これは、さまざまな展開シナリオの下で、フォース対応ネットワーク要素のセキュリティニーズを評価することが重要であることを示す一例にすぎません。管理者がForce Protocolに必要なセキュリティのレベルを構成できるはずです。
In general, the physical separation of two entities usually results in a potentially insecure link between the two entities and hence much stricter security measurements are required. For example, we pointed out in Section 4.1 that authentication becomes necessary between the CE manager and FE manager, between the CE and CE manager, and between the FE and FE manager in some configurations. The physical separation of the CE and FE also imposes serious security requirements for the ForCES Protocol over the Fp interface. This section first attempts to describe the security threats that may be introduced by the physical separation of the FEs and CEs, and then it provides recommendations and guidelines for the secure operation and management of the ForCES Protocol over the Fp interface based on existing standard security solutions.
一般に、2つのエンティティの物理的な分離は通常、2つのエンティティ間の潜在的に不安定なリンクをもたらすため、より厳しいセキュリティ測定が必要です。たとえば、セクション4.1で、CEマネージャーとFEマネージャーの間で、CEマネージャーとCEマネージャーの間、および一部の構成のFEとFEマネージャーの間で認証が必要になることを指摘しました。CEとFEの物理的な分離は、FPインターフェイス上の力プロトコルに深刻なセキュリティ要件も課しています。このセクションでは、最初にFESとCESの物理的な分離によって導入される可能性のあるセキュリティの脅威を説明しようとします。次に、既存の標準セキュリティソリューションに基づいてFPインターフェイスを介した力プロトコルの安全な動作と管理のための推奨事項とガイドラインを提供します。。
This section provides the threat analysis for ForCES, with a focus on the Fp interface. Each threat is described in detail with the effects on the ForCES Protocol entities or/and the NE as a whole, and the required functionalities that need to be in place to defend the threat.
このセクションでは、FPインターフェイスに焦点を当てた力の脅威分析を提供します。各脅威は、勢力プロトコルエンティティまたは/およびNE全体への影響、および脅威を守るために必要な必要性のある機能に詳細に説明されています。
Threats: A malicious node could send a stream of false "join NE" or "remove from NE" requests on behalf of a non-existent or unauthorized FE to legitimate CEs at a very rapid rate, and thereby creating unnecessary state in the CEs.
脅威：悪意のあるノードは、存在しないまたは不正なFEに代わって非常に迅速な速度で「ne」または「NEから削除」リクエストのストリームを非常に迅速な速度で送信し、CESに不必要な状態を作成する可能性があります。
Effects: If maintaining state for non-existent or unauthorized FEs, a CE may become unavailable for other processing and hence suffer from a denial of service (DoS) attack similar to the TCP SYN DoS. If multiple CEs are used, the unnecessary state information may also be conveyed to multiple CEs via the Fr interface (e.g., from the active CE to the stand-by CE) and hence subject multiple CEs to a DoS attack.
効果：存在しないまたは許可されていないFESの状態を維持する場合、CEは他の処理で利用できなくなる可能性があり、したがって、TCP Syn DOSと同様のサービス拒否（DOS）攻撃に苦しむことがあります。複数のCEが使用される場合、不必要な状態情報をFRインターフェイス（例えば、アクティブなCEからスタンバイCEまで）を介して複数のCEに伝えることができ、したがって複数のCEをDOS攻撃に被験者にします。
Requirement: A CE that receives a "join" or "remove" request should not create any state information until it has authenticated the FE endpoint.
要件：「結合」または「削除」要求を受信するCEは、FEエンドポイントを認証するまで状態情報を作成しないでください。
Threats: A malicious node can impersonate a CE or FE and send out false messages.
脅威：悪意のあるノードは、CEまたはFEになりすまして誤ったメッセージを送信できます。
Effects: The whole NE could be compromised.
効果：NE全体が損なわれる可能性があります。
Requirement: The CE or FE must authenticate the message as having come from an FE or CE on the list of the authorized ForCES elements (provided by the CE or FE Manager in the pre-association phase) before accepting and processing it.
要件：CEまたはFEは、それを受け入れて処理する前に、認可された部隊要素のリスト（CEまたはFEマネージャーによって提供されるCEまたはFEマネージャーによって提供される）からのFEまたはCEからのメッセージを認証する必要があります。
Threat: A malicious node could replay the entire message previously sent by an FE or CE entity to get around authentication.
脅威：悪意のあるノードは、認証を回避するために、以前にFEまたはCEエンティティによって送信されたメッセージ全体を再生できます。
Effect: The NE could be compromised.
効果：NEが妥協する可能性があります。
Requirement: A replay protection mechanism needs to be part of the security solution to defend against this attack.
要件：リプレイ保護メカニズムは、この攻撃を防御するためのセキュリティソリューションの一部である必要があります。
Threat: A malicious node may exploit the CE fail-over mechanism to take over the control of NE. For example, suppose two CEs, say CE-A and CE-B, are controlling several FEs. CE-A is active and CE-B is stand-by. When CE-A fails, CE-B is taking over the active CE position. The FEs already had a trusted relationship with CE-A, but the FEs may not have the same trusted relationship established with CE-B prior to the fail-over. A malicious node can take over as CE-B if such a trusted relationship has not been established prior to or during the fail-over.
脅威：悪意のあるノードは、NEの制御を引き継ぐためにCEフェールオーバーメカニズムを活用する場合があります。たとえば、Ce-AとCe-Bなどの2つのCEがいくつかのFEを制御していると仮定します。CE-Aはアクティブで、CE-Bはスタンバイです。CE-Aが失敗すると、CE-BはアクティブなCE位置を引き継ぎます。FESはすでにCE-Aと信頼できる関係を持っていましたが、FESはフェールオーバー前にCE-Bと同じ信頼関係を確立していない可能性があります。このような信頼できる関係がフェールオーバーの前後に確立されていない場合、悪意のあるノードはCE-Bとして引き継ぐことができます。
Effect: The NE may be compromised after such insecure fail-over.
効果：このような不安定なフェールオーバー後に名前が侵害される場合があります。
Requirement: The level of trust between the stand-by CE and the FEs must be as strong as the one between the active CE and the FEs. The security association between the FEs and the stand-by CE may be established prior to fail-over. If not already in place, such security association must be re-established before the stand-by CE takes over.
要件：スタンバイCEとFESの間の信頼のレベルは、アクティブなCEとFESの間のものと同じくらい強力でなければなりません。FESとスタンバイCEのセキュリティ協会は、フェールオーバー前に確立される場合があります。まだ整っていない場合は、スタンバイCEが引き継ぐ前に、そのようなセキュリティ協会を再確立する必要があります。
Threats: A malicious node may inject false messages to a legitimate CE or FE.
脅威：悪意のあるノードは、正当なCEまたはFEに誤ったメッセージを挿入する場合があります。
Effect: An FE or CE receives the fabricated packet and performs an incorrect or catastrophic operation.
効果：FEまたはCEが製造されたパケットを受け取り、誤ったまたは壊滅的な操作を実行します。
Requirement: Protocol messages require integrity protection.
要件：プロトコルメッセージには、整合性保護が必要です。
Threat: When FE and CE are physically separated, a malicious node may eavesdrop the messages in transit. Some of the messages are critical to the functioning of the whole network, while others may contain confidential business data. Leaking of such information may result in compromise even beyond the immediate CE or FE.
脅威：FEとCEが物理的に分離されている場合、悪意のあるノードが輸送中のメッセージを盗聴する場合があります。一部のメッセージは、ネットワーク全体の機能に重要であり、他のメッセージには機密のビジネスデータが含まれる場合があります。そのような情報を漏らすことは、即時のCEまたはFEを超えても妥協する可能性があります。
Effect: Sensitive information might be exposed between the CE and FE.
効果：CEとFEの間に機密情報が公開される場合があります。
Requirement: Data confidentiality between the FE and CE must be available for sensitive information.
要件：FEとCEの間のデータの機密性は、機密情報のために利用可能でなければなりません。
Threat: Consider a scenario where several FEs are communicating to the same CE and sharing the same authentication keys for the Fp interface. If any FE or CE is compromised, all other entities are compromised.
脅威：いくつかのFESが同じCEと通信し、FPインターフェイスの同じ認証キーを共有しているシナリオを検討してください。FEまたはCEが侵害された場合、他のすべてのエンティティが侵害されます。
Effect: The whole NE is compromised.
効果：NE全体が損なわれます。
Recommendation: To avoid this side effect, it's better to configure different security parameters for each FE-CE communication over the Fp interface.
推奨事項：この副作用を回避するには、FPインターフェイスを介した各FE-CE通信のさまざまなセキュリティパラメーターを構成することをお勧めします。
Threat: When an FE receives a packet that is destined for its CE, the FE forwards the packet over the Fp interface. A malicious node can generate a huge message storm like routing protocol packets etc. through the external Fi/f interface so that the FE has to process and forward all packets to the CE through the Fp interface.
脅威：FEがCE用に運命づけられているパケットを受信すると、FEはFPインターフェイスよりもパケットを転送します。悪意のあるノードは、外部Fi/Fインターフェイスを介してルーティングプロトコルパケットなどの大きなメッセージストームを生成することができ、FEがFPインターフェイスを介してすべてのパケットをCEに処理および転送する必要があります。
Effect: The CE encounters resource exhaustion and bandwidth starvation on Fp interface due to an overwhelming number of packets from FEs.
効果：CEは、FESからの圧倒的な数のパケットのために、FPインターフェイスでリソースの疲労と帯域幅の飢vに遭遇します。
Requirement: Some sort of rate limiting mechanism MUST be in place at both the FE and CE. The Rate Limiter SHOULD be configured at the FE for each message type being received through the Fi/f interface.
要件：FEとCEの両方で、何らかのレート制限メカニズムを整える必要があります。Fi/Fインターフェイスを介して受信される各メッセージタイプについて、Rate LimiterをFEで構成する必要があります。
The requirements document [4] suggested that the ForCES Protocol should support reliability over the Fp interface, but no particular transport protocol is yet specified for ForCES. This framework document does not intend to specify the particular transport either, and so we only provide recommendations and guidelines based on the existing standard security protocols [18] that can work with the common transport candidates suitable for ForCES.
要件ドキュメント[4]は、フォースプロトコルがFPインターフェイス上の信頼性をサポートする必要があることを示唆しましたが、力に対して特定の輸送プロトコルはまだ指定されていません。このフレームワークドキュメントは、特定の輸送も指定するつもりはないため、力に適した一般的な輸送候補と連携できる既存の標準セキュリティプロトコル[18]に基づいた推奨事項とガイドラインのみを提供します。
We review two existing security protocol solutions, namely IPsec (IP Security) [15] and TLS (Transport Layer Security) [14]. TLS works with reliable transports such as TCP or SCTP for unicast, while IPsec can be used with any transport (UDP, TCP, SCTP) and supports both unicast and multicast. Both TLS and IPsec can be used potentially to satisfy all of the security requirements for the ForCES Protocol. In addition, other approaches that satisfy the requirements can be used as well, but are not documented here, including the use of L2 security mechanisms for a given L2 interconnect technology.
2つの既存のセキュリティプロトコルソリューション、つまりIPSEC（IPセキュリティ）[15]とTLS（輸送層セキュリティ）[14]をレビューします。TLSは、ユニキャスト用のTCPやSCTPなどの信頼できる輸送で動作しますが、IPSECは任意の輸送（UDP、TCP、SCTP）で使用でき、ユニキャストとマルチキャストの両方をサポートできます。TLSとIPSECの両方を使用すると、Force Protocolのすべてのセキュリティ要件を満たすために潜在的に使用できます。さらに、要件を満たす他のアプローチも使用できますが、特定のL2相互接続テクノロジーにL2セキュリティメカニズムを使用するなど、ここでは文書化されていません。
When ForCES is deployed between CEs and FEs inside a box or a physically secured room, authentication, confidentiality, and integrity may be provided by the physical security of the box. Thus, the security mechanisms may be turned off, depending on the networking topology and its administration policy. However, it is important to realize that even if the NE is in a single-box, the DoS attacks as described in Section 8.1.8 can still be launched through the Fi/f interfaces. Therefore, it is important to have the corresponding counter-measurement in place, even for single-box deployment.
ボックス内のCESとFESの間に力が展開される場合、または物理的に保護された部屋の間に、認証、機密性、および整合性が提供される場合があります。したがって、セキュリティメカニズムは、ネットワークトポロジとその管理ポリシーに応じて、オフにすることができます。ただし、NEがシングルボックスにある場合でも、セクション8.1.8で説明されているDOS攻撃は、FI/Fインターフェイスを介して起動できることを認識することが重要です。したがって、シングルボックスの展開であっても、対応するカウンター測定を実施することが重要です。
TLS [14] can be used if a reliable unicast transport such as TCP or SCTP is used for ForCES over the Fp interface. The TLS handshake protocol is used during the association establishment or re-establishment phase to negotiate a TLS session between the CE and FE. Once the session is in place, the TLS record protocol is used to secure ForCES communication messages between the CE and FE.
TLS [14]は、FPインターフェイス上の力にTCPやSCTPなどの信頼できるユニキャスト輸送が使用される場合に使用できます。TLSハンドシェイクプロトコルは、協会の確立または再確立段階で使用され、CEとFEの間のTLSセッションを交渉します。セッションが整ったら、TLSレコードプロトコルを使用して、CEとFEの間の力の通信メッセージを保護します。
A basic outline of how TLS can be used with ForCES is described below. Steps 1) through 7) complete the security handshake as illustrated in Figure 9, while step 8) is for all further communication between the CE and FE, including the rest of the messages after the security handshake shown in Figure 9 and the steady-state communication shown in Figure 10.
TLSを力で使用する方法の基本的な概要を以下に説明します。手順1）から7）図9に示すようにセキュリティハンドシェイクを完了し、ステップ8）は、図9に示すセキュリティハンドシェイクの後の残りのメッセージを含むCEとFEの間のすべてのさらなる通信と定常状態を含めます。図10に示す通信。
1) During the Pre-association phase, all FEs are configured with the CEs (including both the active CE and the standby CE).
1) 前協会の段階では、すべてのFESがCES（アクティブCEとスタンバイCEの両方を含む）で構成されます。
2) The FE establishes a TLS connection with the CE (master) and negotiates a cipher suite.
2) FEは、CE（マスター）とのTLS接続を確立し、暗号スイートを交渉します。
3) The FE (slave) gets the CE certificate, validates the signature, checks the expiration date, and checks whether the certificate has been revoked.
3) FE（スレーブ）はCE証明書を取得し、署名を検証し、有効期限をチェックし、証明書が取り消されたかどうかを確認します。
4) The CE (master) gets the FE certificate and performs the same validation as the FE in step 3).
4) CE（マスター）はFE証明書を取得し、ステップ3でFEと同じ検証を実行します）。
5) If any of the checks fail in step 3) or step 4), the endpoint must generate an error message and abort.
5) ステップ3）またはステップ4）でチェックのいずれかが失敗した場合、エンドポイントはエラーメッセージを生成して中止する必要があります。
6) After successful mutual authentication, a TLS session is established between the CE and FE.
6) 相互認証が成功した後、CEとFEの間にTLSセッションが確立されます。
7) The FE sends a "join NE" message to the CE.
7) FEは、CEに「結合NE」メッセージを送信します。
8) The FE and CE use the TLS session for further communication.
8) FEとCEは、さらなる通信のためにTLSセッションを使用します。
Note that there are different ways for the CE and FE to validate a received certificate. One way is to configure the FE Manager or CE Manager or other central component as CA, so that the CE or FE can query this pre-configured CA to validate that the certificate has not been revoked. Another way is to have the CE and FE directly configure a list of valid certificates in the pre-association phase.
CEとFEには、受け取った証明書を検証する方法が異なることに注意してください。1つの方法は、CEまたはFEがこの事前に構成されたCAを照会して、証明書が取り消されていないことを検証できるように、FEマネージャーまたはCEマネージャーまたはその他の中央コンポーネントをCAとして構成することです。もう1つの方法は、CEとFEに、事前関連段階で有効な証明書のリストを直接構成することです。
In the case of fail-over, it is the responsibility of the active CE and the standby CE to synchronize ForCES states, including the TLS states to minimize the state re-establishment during fail-over. Care must be taken to ensure that the standby CE is also authenticated in the same way as the active CE, either before or during the fail-over.
フェールオーバーの場合、フェールオーバー中の状態の再確立を最小限に抑えるためのTLS状態を含む、力状態を同期させることは、アクティブなCEとスタンバイCEの責任です。フェイルオーバーの前後に、アクティブなCEと同じ方法でスタンバイCEも認証されるように注意する必要があります。
IPsec [15] can be used with any transport protocol, such as UDP, SCTP, and TCP, over the Fp interface for ForCES. When using IPsec, we recommend using ESP in the transport mode for ForCES because message confidentiality is required for ForCES.
IPSEC [15]は、FPのFPインターフェイスを介して、UDP、SCTP、TCPなどの任意の輸送プロトコルで使用できます。IPSECを使用する場合、力にメッセージの機密性が必要であるため、輸送モードでESPを使用することをお勧めします。
IPsec can be used with both manual and automated SA and cryptographic key management. But IPsec's replay protection mechanisms are not available if manual key management is used. Hence, automatic key management is recommended if replay protection is deemed important. Otherwise, manual key management might be sufficient for some deployment scenarios, especially when the number of CEs and FEs is relatively small. It is recommended that the keys be changed periodically, even for manual key management.
IPSECは、手動および自動化されたSAおよび暗号化キー管理の両方で使用できます。ただし、手動のキー管理を使用する場合、IPSECのリプレイ保護メカニズムは利用できません。したがって、リプレイ保護が重要とみなされる場合は、自動キー管理が推奨されます。それ以外の場合、特にCESとFESの数が比較的少ない場合、いくつかの展開シナリオには手動のキー管理で十分かもしれません。手動のキー管理の場合でも、キーを定期的に変更することをお勧めします。
IPsec can support both unicast and multicast transport. At the time this document was published, the MSEC working group was actively working on standardizing protocols to provide multicast security [17]. Multicast-based solutions relying on IPsec should specify how to meet the security requirements in [4].
IPSECは、ユニキャストとマルチキャストトランスポートの両方をサポートできます。この文書が公開されたとき、MSECワーキンググループは、マルチキャストセキュリティを提供するためにプロトコルの標準化に積極的に取り組んでいました[17]。IPSECに依存するマルチキャストベースのソリューションは、[4]のセキュリティ要件を満たす方法を指定する必要があります。
Unlike TLS, IPsec provides security services between the CE and FE at IP level, so the security handshake, as illustrated in Figure 9 amounts to a "no-op" when manual key management is used. The following outlines the steps taken for ForCES in such a case.
TLSとは異なり、IPSECはIPレベルでCEとFEの間のセキュリティサービスを提供するため、図9に示すように、セキュリティの握手は、手動キー管理が使用される場合は「ノーオップ」になります。次のことは、そのような場合の力のために取られた措置の概要を示しています。
1) During the Pre-association phase, all the FEs are configured with CEs (including the active CE and standby CE) and SA parameters manually.
1) 前協会の段階では、すべてのFESがCES（アクティブCEおよびスタンバイCEを含む）とSAパラメーターを手動で構成します。
2) The FE sends a "join NE" message to the CE. This message and all others that follow are afforded security service according to the manually configured IPsec SA parameters, but replay protection is not available.
2) FEは、CEに「結合NE」メッセージを送信します。このメッセージとその後のすべてのメッセージは、手動で構成されたIPSEC SAパラメーターに従ってセキュリティサービスが提供されますが、リプレイ保護は利用できません。
It is up to the administrator to decide whether to share the same key across multiple FE-CE communication, but it is recommended that different keys be used. Similarly, it is recommended that different keys be used for inbound and outbound traffic.
複数のFe-CE通信で同じキーを共有するかどうかを決定するのは管理者次第ですが、異なるキーを使用することをお勧めします。同様に、インバウンドトラフィックとアウトバウンドトラフィックには、異なるキーを使用することをお勧めします。
If automatic key management is needed, IKE [16] can be used for that purpose. Other automatic key distribution techniques, such as Kerberos, may be used as well. The key exchange process constitutes the security handshake as illustrated in Figure 9. The following shows the steps involved in using IKE with IPsec for ForCES. Steps 1) to 6) constitute the security handshake in Figure 9.
自動キー管理が必要な場合は、IKE [16]をその目的に使用できます。Kerberosなどの他の自動キーディストリビューション技術も同様に使用できます。キー交換プロセスは、図9に示すように、セキュリティの握手を構成します。次のことは、IKEを力に使用することに伴う手順を示しています。手順1）から6）図9のセキュリティハンドシェイクを構成します。
1) During the Pre-association phase, all FEs are configured with the CEs (including active CE and standby CE), IPsec policy etc.
1) 前協会の段階では、すべてのFESがCES（アクティブCEおよびスタンバイCEを含む）、IPSECポリシーなどで構成されます。
2) The FE kicks off the IKE process and tries to establish an IPsec SA with the CE (master). The FE (Slave) gets the CE certificate as part of the IKE negotiation. The FE validates the signature, checks the expiration date, and checks whether the certificate has been revoked.
2) FEはIKEプロセスを開始し、CE（マスター）でIPSEC SAを確立しようとします。FE（スレーブ）は、IKE交渉の一部としてCE証明書を取得します。FEは署名を検証し、有効期限をチェックし、証明書が取り消されたかどうかを確認します。
3) The CE (master) gets the FE certificate and performs the same check as the FE in step 2).
3) CE（マスター）はFE証明書を取得し、ステップ2でFEと同じチェックを実行します）。
4) If any of the checks fail in step 2) or step 3), the endpoint must generate an error message and abort.
4) ステップ2）またはステップ3）でチェックのいずれかが失敗した場合、エンドポイントはエラーメッセージを生成して中止する必要があります。
5) After successful mutual authentication, the IPsec session is established between the CE and FE.
5) 相互認証が成功した後、IPSECセッションはCEとFEの間に確立されます。
6) The FE sends a "join NE" message to the CE. No SADB entry is created in FE yet.
6) FEは、CEに「結合NE」メッセージを送信します。SADBエントリはまだFEで作成されていません。
7) The FE and CE use the IPsec session for further communication.
7) FEとCEは、さらなる通信のためにIPSECセッションを使用します。
The FE Manager, CE Manager, or other central component can be used as a CA for validating CE and FE certificates during the IKE process. Alternatively, during the pre-association phase, the CE and FE can be configured directly with the required information, such as certificates or passwords etc., depending upon the type of authentication that administrator wants to configure.
FEマネージャー、CEマネージャー、またはその他の中央コンポーネントは、IKEプロセス中にCEおよびFE証明書を検証するためのCAとして使用できます。あるいは、前協会の段階では、管理者が構成する認証の種類に応じて、CEとFEを証明書やパスワードなどの必要な情報と直接構成できます。
In the case of fail-over, it is the responsibility of the active CE and standby CE to synchronize ForCES states and IPsec states to minimize the state re-establishment during fail-over. Alternatively, the FE needs to establish a different IPsec SA during the startup operation itself with each CE. This will minimize the periodic state transfer across the IPsec layer though the Fr (CE-CE) Interface.
フェールオーバーの場合、フェールオーバー中の状態の再確立を最小限に抑えるために、力状態とIPSEC状態を同期させることは、アクティブなCEとスタンバイCEの責任です。あるいは、FEは、各CEでの起動操作中に異なるIPSEC SAを確立する必要があります。これにより、FR（CE-CE）インターフェイスを使用して、IPSECレイヤーを横切る周期的な状態転送が最小限に抑えられます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[3] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[3] フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[4] Khosravi, H. and Anderson, T., Eds., "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[4] Khosravi、H。およびAnderson、T.、eds。、「IPコントロールと転送の分離の要件」、RFC 3654、2003年11月。
[5] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002.
[5] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[6] Daniele, M., Wijnen, B., Ellison, M. and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[6] Daniele、M.、Wijnen、B.、Ellison、M。、およびD. Francisco、「Agent Extensibility（AgentX）プロトコルバージョン1」、RFC 2741、2000年1月。
[7] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[7] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R.、A。Smith、「ポリシープロビジョニングのためのCopsの使用（COPS-PR） "、RFC 3084、2001年3月。
[8] Crouch, A. et al., "ForCES Applicability Statement", Work in Progress.
[8] Crouch、A。et al。、「Force Applicability Statement」、進行中の作業。
[9] Anderson, T. and J. Buerkle, "Requirements for the Dynamic Partitioning of Switching Elements", RFC 3532, May 2003.
[9] Anderson、T。およびJ. Buerkle、「スイッチング要素の動的分割の要件」、RFC 3532、2003年5月。
[10] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[10] Leelanivas、M.、Rekhter、Y。およびR. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[11] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[11] Moy、J.、Pillay-Esnault、P。and A. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[12] Sangli, S. et al., "Graceful Restart Mechanism for BGP", Work in Progress.
[12] Sangli、S。et al。、「BGPの優雅な再起動メカニズム」、進行中の作業。
[13] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", Work in Progress.
[13] Shand、M。およびL. Ginsberg、「IS-ISのシグナルを再起動」、進行中の作業。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[14] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[15] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[15] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[16] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[17] Hardjono, T. and Weis, B. "The Multicast Group Security Architecture", RFC 3740, March 2004.
[17] Hardjono、T。and Weis、B。「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、2004年3月。
[18] Bellovin, S., Schiller, J. and C. Kaufman, Eds., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[18] Bellovin、S.、Schiller、J。and C. Kaufman、eds。、「インターネットのセキュリティメカニズム」、RFC 3631、2003年12月。
L. Lily Yang Intel Corp., MS JF3-206, 2111 NE 25th Avenue Hillsboro, OR 97124, USA
L. Lily Yang Intel Corp.、MS JF3-206、2111 NE 25th Avenue Hillsboro、または97124、米国
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com
Ram Dantu Department of Computer Science, University of North Texas, Denton, TX 76203, USA
ノーステキサス大学、デントン、テキサス州テキサス州76203、米国のコンピュータサイエンスのラムダントゥ科
Phone: +1 940 565 2822
EMail: rdantu@unt.edu
Todd A. Anderson Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124, USA
トッドA.アンダーソンインテルコーポレーション2111 NE 25th Avenue Hillsboro、または97124、米国
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803, USA
Ram Gopal Nokia Research Center 5、Wayside Road、バーリントン、マサチューセッツ州01803、米国
Phone: +1 781 993 3685
EMail: ram.gopal@nokia.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。