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）インターネット協会（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
ForCESの要件に関連した用語のセットは、[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） - のForCESプロトコルを実装する論理エンティティ。 FEは、パケットごとの処理、強制的プロトコルを介してCEの指示に従って処理を提供するために、基礎となるハードウェアを使用します。 FEは、単一のブレード（または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） - のForCESプロトコルを実装し、パケットを処理する方法についての一の以上のFEを指示するためにそれを使用して論理的なエンティティ。 CEは、このような制御およびシグナリングプロトコルの実行などの機能を扱います。 CEは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.
ForCESネットワーク要素（NE） - 一の以上のCEと1つの以上のFEで構成するエンティティ。 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.
ポスト関連フェーズ - FEは、CEとFEが互いに通信を確立する時間を含め、その逆も同様に制御することであるCEを知っている期間。
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).
ForCESプロトコルは - 全体のForCESアーキテクチャ内で使用される複数のプロトコルが存在してもよいが、用語「のForCESプロトコル」のみ力にポスト会合相プロトコル（下記参照）を意味します。
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.
ForCESポスト協会フェーズプロトコル - CEとFEとの間にポスト会合相の通信に使用されるプロトコル。このプロトコルは、CE-に-CE通信、FE-に-FE通信、またはFEとCEマネージャ間の通信には適用されません。 ForCESプロトコルのFEはスレーブであり、CEがマスターであるマスター・スレーブプロトコルです。このプロトコルは、通信チャネル（例えば、接続確立、ハートビート）の管理及び制御メッセージ自体の両方を含みます。このプロトコルは、単一のプロトコルであるか、または一緒に働く複数のプロトコルから成ることができ、ユニキャストまたはマルチキャスト基づくことができます。別のプロトコル文書は、この情報を指定します。
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の発見と呼ばれ、利用可能なCEの機能を学習FEマネージャを含むことができます。 FEマネージャが使用するCE（複数可）を決定する（下記参照）プレ会合相プロトコルに静的構成から何かを使用することができます。しかし、これは現在の範囲外です。論理的なエンティティであること、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）CEが通信するべきかを決定する責任がある論理エンティティ。このプロセスは、FEの発見と呼ばれ、利用できるのFEの機能を学習CEマネージャを含むことができます。 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.
事前会合フェーズプロトコル - のCEまたは複数のFEを使用するかを決定するために使用されるFEマネージャとCE管理者との間のプロトコル。事前会合相プロトコルは、CEおよび/またはFE能力発見メカニズムを含むことができます。 ForCESプロトコル内で使用される、この機能の発見プロセスから完全に独立している（と置き換えることはありません）ことに注意してください。しかし、2つの機能ディスカバリメカニズムは同じFEモデルを利用することができます。
FE Model - A model that describes the logical processing functions of an FE.
FEモデル - FEの論理的な処理機能を記述するモデル。
ForCES Protocol Element - An FE or CE.
ForCESプロトコル要素 - 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.
イントラ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の複数のFEが相互接続されているかの表現。時にはFEモデルで使用される内FEトポロジと区別するために、間FEトポロジと呼ばれています。
Inter-FE topology - See FE Topology.
インター-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）は、（ルータなど）（例えば、ルーティングのような）所定の機能を提供するように協働する多数の論理的に分離されたエンティティで構成されています。ネットワーク要素部品の二つのタイプが存在する：コントロールプレーンとプレーン（又はデータプレーン）を転送における転送要素（FE）内の制御要素（CE）を。転送要素は、典型的には、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
力は制御および転送プレーン間の情報交換を標準化するためのフレームワークおよび関連するプロトコル（複数可）を定義することを目的とします。標準的なメカニズムを有するCEとFEが物理的に分離され、標準的な構成要素になることを可能にします。この物理的分離はのForCESアーキテクチャにいくつかの利点を計上します。個別のコンポーネントは、コンポーネントのベンダーは、すべてのコンポーネントの専門家になることなく、一つの構成要素に特化できるようになります。標準プロトコルは、異なるコンポーネントベンダーからCEとFEが相互運用することを可能にし、システムベンダーは複数のCEを一緒に統合するために、したがってことが可能となり、
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.
異なる部品サプライヤーからの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枚の制御ブレードと複数の転送ブレード、すべてとルータのような構成例を示しています。このようなシャーシ構成では、ルータブレードがFEであるが、制御ブレードはCEのであり、スイッチファブリックバックプレーンは、すべてのブレードの物理的相互接続を提供します。制御ブレードBは、冗長性を提供するバックアップCEかもしれないが、制御ブレードAは、一次CEであってもよいです。高可用性をサポートするための冗長スイッチファブリックを有することも可能です。このような構成を持つルータ今日は、CEとFE間のメッセージングのための独自のインタフェースを使用しています。力の目標は、標準プロトコルで、このような独自のインタフェースを交換することです。すべてのブレードに実装さのForCESような標準的なプロトコルでは、ベンダーXからの制御ブレード可能となり、1台のシャーシにシームレスに連携することがベンダーYからブレードを転送します。
------- -------
| 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.
CEとFEとの間の物理的分離の別のレベルは、ボックスレベルであってもよいです。このような構成では、すべてのCEとFEは、物理的（ギガビットイーサネットなど）高速LAN接続のいくつかの種類と相互接続箱を、分離されています。これらの分離されたCEとFEは、ローカルエリアネットワーク内に一つだけホップ離れています。 CEとFEが実行力によってお互いに通信し、これらのCEとFEのコレクションは、一緒に外界へのルーティングユニットとなります。図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は、1またはそれでこれらのCEとFE機能の多くが含まれていてもよいです。図はまた、のForCESプロトコルが自身のForCES及び/発信/から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.
CEとFE機能の3例を図。
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]のアーキテクチャ要件を満たし、プロトコル定義を容易に力のネットワーク要素と関連するエンティティのためのフレームワークを定義するのForCESアーキテクチャを記述する。必要に応じて、この文書は力の問題および/または可能な解決策を説明するために多くの例を使用しています。これらの例は一例であることが意図され、そして特定の物事の唯一のか明確な方法として取られるべきではありません。別の文書にはのForCESプロトコルを指定するには、ワーキンググループの力によって生成されることが期待されます。
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アーキテクチャフレームワークと関連した論理コンポーネントを定義します。これのForCESフレームワークは、いくつかの補助的な成分を含むのForCESの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
Figure 4. ForCES Architectural Diagram
図4のForCESアーキテクチャダイアグラム
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の図は、のForCESアーキテクチャとそれらの関係の論理コンポーネントを示します。制御要素（CE）及び転送要素（FE）：二つの力のネットワーク要素内の成分の種類があります。フレームワークは、1つのNE内のCEとFEの複数のインスタンスを許可します。各FEは、外界へ/からのパケットを受信し、送信するための1つ以上の物理メディアインターフェイスを含んでいます。これらのFEインターフェイスの集約は、NEの外部インターフェイスになります。 CEとFEが互いに通信できるように、外部インタフェースに加えて、NE内の相互接続のいくつかの種類が存在しなければならない、1 FEが別のFEにパケットを転送することができます。 CE ManagerおよびFEマネージャ：図はまたのForCES NEの外側に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.
FE外部インターフェイスを部屋/ Fとラベル付けされている図4に示すように、便宜上、これらの構成要素間の論理的な相互作用は、基準点Fpとは、Fc、Ffと、FR、FL、とFIによって標識されます。より詳しくは、これらの基準点の各々については、セクション3と4に設けられています。 Fpは - これらのすべての基準点は、のForCESアーキテクチャを理解する上で重要であり、しかし、のForCESプロトコルは、ただ1つの基準点の上に定義されています。
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.
二つの力のNEとの間のインターフェースは、2つの従来のルータとの間のインターフェースと同一であり、これら2つのNEが部屋/ Fで外部インターフェースを介してプロトコル・パケットを交換します。 ForCESのNEは、透過的に既存のルータに接続します。
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.
単一のCEおよび複数のFEのような単純な構成のための制御および転送分離を可能にするために、Frの基準点を横切る任意のプロトコルを定義する必要はありません。しかしながら、このアーキテクチャは、ネットワーク要素に存在する複数のCEを可能にします。実装は複数のCEを使用する場合には、CEとFEが一緒になって単一の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が活性CEに障害が発生した場合に引き継ぐために準備されている場合です。負荷分散は、二つ以上のCEが同時にアクティブであるとCEの一つによってサービスされ得る任意の要求は、他のCEのいずれかによってサービスされ得る場合です。冗長性と負荷分散の両方のために、関係CEは等価的に可能です。これら2例の唯一の違いは、同時に存在しているどのように多くのアクティブなCEの用語です。分散制御は、二つ以上のCEが同時に活性であるが、特定の要求にのみ、特定のCEによってサービスすることができるされている場合です。
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がのForCES NEに採用されている場合には、その内部組織は力の範囲を超えている実装の問題と考えられています。 CEは、一貫性と同期を提供するために、Frの基準点を経由して、それ自体で調整するための完全に責任があります。しかし、力がCEの間で使用される実装やプロトコルを定義していません。また、CEの間で機能を分配する方法を定義しません。それにもかかわらず、力が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は、のForCESプロトコルを実装する論理エンティティであり、パケット単位の処理を提供するために、基礎となるハードウェアを使用してCEによって誘導されたものとして扱います。複数の論理のFEに一つの物理FEを分割することが可能です。 1 FEは、複数の物理のFEを使用することも可能です。物理FE（S）と論理FE（S）との間のマッピングは、力の範囲を超えています。例えば、物理的なFEの論理パーティションは、論理のFEのそれぞれにFE物理的な力で利用可能なリソース（例えば、ポート、メモリ、転送テーブルエントリ）のそれぞれの一部を割り当てることによって作成することができます。 [9]に記載のようにFE仮想化のような概念は、仮想スイッチング素子に類似しています。 FEの仮想化は、予め関連付けフェーズでのみ発生する場合、それは力に影響を与えません。リソース変更にFE仮想化結果は、既存のFE（既にポスト会合相力の参加）から採取された場合は、のForCESプロトコル（参照非同期メッセージを介して、そのような変化の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.
CEによって誘導されたものとしてのFEは、すべてのパケット処理機能を実行します。 FEは、自分の一切主導権を持っていません。その代わり、FEが奴隷であり、彼らが言われるようにのみ行います。 FEは、同時に基準点Fpを横切って一の以上のCEと通信することができます。 FEは、CEの冗長化、負荷分散、あるいは分散制御の概念を持っていません。その代わり、FEがどのCEからのコマンドは、それらを制御する権限を受け入れて、そしてそれは、冗長性、負荷分散、あるいは分散制御を実現するために自分たちの中で調整するのCEまでです。アイデアはのFEは、パケット処理機能にリソースを集中できるように、できるだけシンプルでダムとしてのFEを維持することです。そうでなければ構成または強制プロトコル交換によって決定されない限り、各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.
分散制御フェズの一部に大きなインテリジェンスなしに、同様の方法で達成することができます。例えば、複数のFEは、別のCEに1つのCEおよびBGPパケットにRSVPとBGPプロトコルパケット、及び順方向RSVPパケットを検出するように構成することができます。したがって、FEが特定の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.
このアーキテクチャは、NEに存在するように複数のFEを許可します。 [4]（[4]第5章、要求＃11を参照）のForCESプロトコルのFEの少なくとも数百まで拡張することができなければならないことを指示します。これらのFEの各々は、潜在的に異なるメディアインターフェースと、パケット処理機能の異なるセットを有することができます。 FEは、他のFEとし、外部エンティティとのレイヤ2接続の基本的なメンテナンスを担当しています。多くの層-2メディアは、洗練された制御プロトコルが含まれます。 （FP基準点を介して）力プロトコルは、ダム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.
複数のFEが存在する場合、力は、パケットが1 FEによってNEに到着し、異なるFE（[4]、セクション5、要件＃3を参照）を介してNEを残すことができなければならないことを要求します。 1 FEを介してNEを入力し、異なるFEを介してNEを残すパケットがFiの基準点を横切るのFE間で転送されます。 Fiの基準点は、おそらく事前アソシエーションフェーズの間、彼らの（インターFE）のトポロジを発見するためのFEによって使用することができます。 Fiの基準点は、浮動小数点基準点から別のプロトコルであり、現在のForCESプロトコルによって定義されていません。
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).
トポロジ内の複数のFEに分散できるのFEは、トポロジー及びパケット処理の異なる種類で接続することができます。したがって、論理パケットフローは、物理FEトポロジ異なっていてもよいです。図6は、いくつかのトポロジーの例を提供します。それはのFE間でパケットを転送する必要がある場合には、CEは、FEトポロジーを理解する必要があります。 FEトポロジはのForCESプロトコルを介したCEによってのFEから照会することができるが、複数のFEは、CEにその情報を提供するために必要とされません。だから、FEトポロジ情報は、（間FEトポロジ発見プロトコルのような）のForCESプロトコルの外側の他の手段によって収集することができます。
-----------------
| CE |
-----------------
^ ^ ^
/ | \
/ v \
/ ------- \
/ +->| FE3 |<-+ \
/ | | | | \
v | ------- | v
------- | | -------
| FE1 |<-+ +->| FE2 |
| |<--------------->| |
------- -------
^ | ^ |
| | | |
| v | v
(a) Full mesh among FE1, FE2, and FE3
FE1、FE2、およびFE3の間で（a）のフルメッシュ
-----------
| 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のマネージャーはCEが制御する必要がありFESかを決定する責任があります。 CE管理者は、そのCEが連通べきFESとの知識をハードコーディングされることが正当なものです。 CEマネージャは、物理的にCEに埋め込まれてもよく、CE上の単純なキーパッドまたは他の直接設定機構として実装すること。最後に、CEマネージャはCOPS-PRのような機構を介してFE情報をCEを設定し、物理的および論理的に別個のエンティティとすることができる[7]またはSNMP [5]。
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マネージャがどのそれのFEが通信べきCE、もFEマネージャの実装方法に載置された制限であると決定する方法に置かれていません。別のFEは、同一または異なるFEマネージャ（複数可）を有することができる各FEは、唯一の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.
両方のFEおよびCEは、彼らがコヒーレントネットワーク要素として情報交換や機能を開始する前の場所にあるように、いくつかの設定が必要です。事前会合およびポスト関連：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基準点を介したメッセージ交換の全部または一部を含むことができます。しかし、すべてのこれらは任意であってもよく、これはいずれものForCESプロトコルの範囲内ではありません。
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、またはCEとFEのセットが関連するかどうかを決定するために、事前会合相フロリダ州の基準点を横切って通信することができます。フロリダの基準点間の通信は、このアーキテクチャではオプションです。何の要件は、この基準点に置かれていません。
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管理者を除き、漏らしたくないかもしれない、CEのいずれかの特性には、管理しています。同様に、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のF1参照点上のメッセージ交換の一例
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とFEが相互に通信すべきかを決定するために通信します。最低でも、CEおよびFE管理者は、それぞれ利用できるのFEおよびCEの存在を知る必要があります。この発見プロセスは、発見されたのForCESプロトコル要素の機能を学習し、一方または両方のマネージャを伴ってもよいです。図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マネージャーとのFEの間で必要です。適切なセキュリティが確立されると、FEの監督は新しいNEに参加したり、既存のNEとの接続を切断するために、この基準点間のFEに指示します。 FE Managerは、この基準点を使用してのFEに固有の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
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マネージャ機能が、この基準点は、組み込み関数に還元された場合には（例えばCE IPアドレスの手動キーパッド入力により）FEと同じ場所に配置されてもよいことに留意されたいです。
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マネージャがリモートである場合、唯一許可エンティティは、特定のFEを制御するために、CEを指示してもよいです。プライバシー、整合性、新鮮さ、および認証はまた、このような構成では、この基準点間で必要とされています。適切なセキュリティが確立された後、彼らが制御する必要がありますしているのFEとそれらがどのようにそれらを制御する必要があるとして、CEマネージャはCEのを指示します。図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.
CEマネージャとCEが同じ場所に配置され、プロトコルがこの機能のために使用されていない場合FEマネージャとのFEと同様に、構成が可能です。
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」を意味プロトコル）が基準点を横切って行われます。 ForCESプロトコルは、専用の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.
ForCESワーキンググループは、力の最初のバージョンは、IPネットワークにおける「非常に近い」CE / FEの地域を中心に説明することを意識的な決定をしました。非常に近い地域は、同じ物理ボックス内のいずれかの成分である、または1つのローカルネットワークホップによって最大で分離された制御および転送要素から成る（[8]）。 CEとFEイーサネット接続を含む相互接続技術、種々の方法により接続することができ、バックプレーン、ATM（セル）布地などの力がこれらの相互接続の各々をサポートすることができなければならない（[4]第5、要件＃1を参照）。 CEとFEが単一L3ルーティングホップを超えて離れている場合、のForCESプロトコルは、既存のRFC 2914輸送目的のために十分な信頼性、セキュリティ、および輻輳制御（例えば、TCP、SCTP）と[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
NEの関連付けを確立するためにFpの上CEとFEとの間のメッセージ交換の図9の例
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.
セキュリティ握手はそれ以上のメッセージ交換が発生する前に、お互いに二つの通信のエンドポイントを認証する必要があります。セキュリティハンドシェイクがCEとFEとの間の相互認証と承認を含める必要がありますが、正確な詳細は、のForCESプロトコルによって選択されたセキュリティ・ソリューションに依存します。許可は事前関連付け段階中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に通知し、他のFEとの関係でそのトポロジーをオプションする必要があります。 [4]（セクション6、要件＃1）に、必要に応じてFEの能力は、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との間に確立されると、のForCESプロトコルは、パケットの処理を容易にするための情報を交換するためのFP基準点上CEとFEによって使用されます。
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
図定常通信中Fpの上CEとFEとの間のメッセージ交換の10例
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.
CEの制御処理によって取得した情報に基づいて、CEはしばしばのFEに命令を送ることによって、彼らのFE（S）のパケット転送動作を操作する必要があります。例えば、図10は、FEは、その転送テーブルに追加できるように、CEは、FEに新しい経路を送信するメッセージ交換の例を示します。 CEは、ポート障害などの重要なイベントのCEを通知することができるFEとFEによって収集された統計情報のためのFEを問い合わせることができます。
--------------------- ----------------------
| | | |
| +--------+ | | +--------+ |
| |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.
（例えばRIP、OSPFメッセージなど）パケットがNEのインターフェイスのいずれか宛の制御プレーンプロトコルは、典型的には、そのCEを受信FEによってリダイレクトされ、CEは、パケットを発信し、そのFEが他のNEに配信有していてもよいです。従って、Fpの上のForCESプロトコルはCEとFE間の力プロトコルメッセージを搬送するだけでなく、制御プレーンプロトコルからデータパケットをカプセル化するだけでなく。さらに、一FEは、分散制御のための複数のCEによって制御されてもよいです。この構成では、力のNEによってサポートされる制御プロトコルは、複数のCEに分散してもよいです。 RSVPのようなシグナリング及びアドミッション制御プロトコルは、他のCEでサポートされている間、例えば、1つのCEは、OSPFやBGPなどのルーティングプロトコルをサポートすることができます。 FEを認識し、これらのプロトコルのパケットをフィルタリングし、対応する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をルータに渡される方法の一例は、のForCESプロトコルにFEから次にルータA内のFEにCEからのパケットを転送するために使用され、 ForCESプロトコル制御メッセージとFP基準点上CEとFEとの間のデータパケットの両方を輸送するための責任であるという事実に照らしてルータB.内部CE、単一のプロトコルまたは複数のプロトコルのいずれかを使用することが可能です。
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の欠如のため、例えば）のForCESプロトコルを実装することができない場合に、プロキシFEではなく物理的FEのFpの基準点を終端するために使用することができます。プロキシは、通信の何らかの中間形態（例えば、非フォースプロトコルまたはDMA）を使用して物理FEを操作しながら、これは、CEは、力を使用して、プロキシを介して物理的FEと通信することを可能にします。そのような実装では、プロキシと物理FEの組み合わせが一つの論理FEエンティティなります。 1つのプロキシが複数の物理のFEを代表して行動することも可能です。
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は、強制的にそれ自体を実現することができないので、力のセキュリティメカニズムは、物理FEまでずっとCEとプロキシ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.
FEおよびCEは、参加して（[4]第5章、要求＃12を参照）を動的NEを残すことができます。 FEまたはCEがNEを離れたとき、NEとの関連付けが壊れています。去る当事者が後でNEに復帰した場合、関連付けを再確立するために、それは事前会合相を再入力する必要があるかもしれません。関連の損失はまた、CEとFEとの間の接続の喪失に予期せず発生する可能性があります。したがって、フレームワークは、これらの二つの相の間の双方向の移行を可能にする、が、強制プロトコルは、ポスト会合相のためにのみ適用可能です。しかし、プロトコルが再確立アソシエーションをサポートするためのメカニズムを提供しなければなりません。これは、それらの間の関連の損失があるときを決定するために、及び関連で効率的な状態（再）同期メカニズム（[4]第5章、要求＃7を参照）を復元するために、CEとFEのための能力を含みます。そのセキュリティアソシエーションおよび状態も（認証および承認の両方を含む）同じレベルのセキュリティアソシエーションを再確立前後の存在を保証するために再確立する必要があります。
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.
"グレースフルリスタート" として知られている高可用性機構（[13]-ISは、IS、OSPF [11]、BGP [12]）IPルーティングプロトコルによって使用されており、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.
詳細は、プロトコルからのプロトコルに異なるが、グレースフルリスタートメカニズムの背後にある一般的な考え方は同じまま。それが再起動したときにグレースフルリスタートを使用すると、再起動ルータは、その隣人に知らせることができます。隣人は、失われた隣接関係を検出することができるが、新しいルートを再計算するか、隣人へのルーティングアップデートを送信しません。隣人はまた、再起動する前に再起動ルータから受信したルートを保持し、彼らはまだ限られた時間のために有効であると仮定します。そうすることによって、再起動ルータのFEにはまた、彼らは既に持っているルートを使用することにより、限られた時間のために他のネイバーからのトラフィックを受信し、前方を継続することができます。再起動ルータはその後、そのすべてのネイバーからのルート更新されたルーティング隣接関係、ダウンロードを再確立し、新たなルートを再計算し、それを使用していた古いルートを置き換えるためにそれらを使用しています。これは、その隣人にこれらの更新されたルートを送信し、グレースフルリスタート処理の完了を知らせます。
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.
ノンストップフォワーディンググレースフルリスタートのための必要条件です。それは、ルーティング情報をダウンロードして、新しいルートを再計算している間、ルータがパケットを転送し続けることができるようにそれは必要です。これは、パケットが廃棄されないことを保証します。 1が見ることができるように、CEとFEとの分離によってもたらされる利点の一つは、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はCEに障害が発生した場合に何をすべきかのFEを通知しなければなりません。グレースフルリスタートがサポートされていない場合、FEがそのCEが失敗した場合、すべて一緒にパケット処理を停止するように指示することができます。グレースフルリスタートがサポートされている場合、のFEをキャッシュし、再起動して転送テーブルを含め、その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は一瞬のために働いてCEであると仮定すると、のFEの一つは、FE1を言ったらどうなるか、一時的にNEの葉？ FE1は、自主的に関連性を残すように決めることができます。また、FE1は、予期しない障害のために、単純に機能停止することがあります。前者の場合、CE1はFE1から「リーブ・アソシエーション要求」を受信します。後者では、CE1は、いくつかの他の手段によってFE1の故障を検出します。どちらの場合も、CE1は、最も可能性の高い到達可能性とSPF（最短パス優先）再計算し、残りのFE（この例では唯一FE2）のCE1から新しいのFIBの関連するダウンロードを促す、このようなイベントのルーティングプロトコルを通知しなければなりません。このような再計算し、FIBアップデートもCE1からFE1の接続性の影響を受けている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は依然として、ルーティングテーブルと最後の会合から他の状態情報を持っていると仮定する。代わりに、すべての情報を再送信するので、そのような機構は、のForCESプロトコルでサポートされている場合、そのCEで状態を同期し直すために、より効率的なメカニズムを使用することができるかもしれません。例えば、CRC-32の状態は、状態に同期そのCEとであるか否かの迅速な指示を与えるかもしれません。最初のCEとその状態を比較することによって、それが必要とされている場合にのみ、情報の更新を送信します。 ForCESプロトコルは、同様の最適化のメカニズムを実装することもできますが、これは必要条件ではありませんようにも、ないことを選択できます。
[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で定義されている任意の提案のForCESアーキテクチャは、そのアーキテクチャは、ルータ機能のすべてをサポートする方法を説明しなければなりません」 RFC 1812 [2]は、アプリケーション層へのリンク層からIPv4ルーターのための多くの重要な要件について説明します。このセクションでは、のForCESアーキテクチャに基づいたIPv4ルータを実現するためのRFC 1812に関連する要件に対処し、力が転送プレーンと制御プレーンに必要な機能を分離する方法に関するガイドラインを提供することによって、これらの要件を満たす方法について説明します。
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.
制御プレーンは、制御及びシグナリングプロトコルの典型的なものである、計算複雑な操作の大部分を担持しながら、一般的に、転送プレーンは、ライン速度で必要とされるパケット単位の処理の大部分を行います。しかし、きれいにCEとFEに処理を分割するため、強制的アーキテクチャは、制御プレーンとの分離を転送で革新的なアプローチを限定するものではない剛性の線を描画することは不可能です。より多くの処理能力は、フェスに利用可能であるように、伝統のCEによって実行される制御機能のいくつかは、現在、より良いパフォーマンスとスケーラビリティのためのFEに移動させてもよいです。そのようなオフロード機能は、ICMPの一部またはTCP処理、またはルーティングプロトコルの一部を含むことができます。一度、オフロードされたフォワーディングプレーンの上には、そのようなCE機能、論理的に制御プレーンに属していても、今FE機能の一部となります。 CEが存在する場合のFEで最高のこれらのオフロード機能を利用する方法を決定することができるようにするだけのFEによって実行される他の論理関数のように、そのようなオフロード機能は、FEモデルの一部として表現されなければなりません。
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つ以上の論理インタフェースを有しています。 CEとFEが単一のNE内の力によって分離されている場合、いくつかの追加のインタフェースは、イントラNE通信のために必要とされている図12に示すように、このNEは、1つのCE二つのFEを含んでいます。各FEは、4つのインターフェースを有します。他の2つは、イントラNEの接続のためにしている間にそれらの2には、外部の世界にパケットを受信し、送信するために使用されています。 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を参照）の機能は、当然のForCESアーキテクチャでのFEに属します。
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.
ルータは、アプリケーション層プロトコル（RFC 1812 [2]のセクション6を参照）をサポートするために必要とされる（TCPやUDPなど）トランスポート層プロトコルを実装することができます。アプリケーションプロトコルの1つの重要なクラスは、ルーティングプロトコル（RFC 1812 [2]のセクション7を参照します）。 ForCESアーキテクチャでは、ルーティングプロトコルは、天然のCEによって実現されます。ルーティングプロトコルは、ルータが互いに通信することを必要とします。異なるルータ内のCE間のこの通信は、パケットを発信し、それらは、それらのFEによって送達有する能力のFEのデータ・パケット（すなわち、NES）ルータ宛、およびCEリダイレクトする能力によって力が支持されています。図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.
FEは、ルータのすべての外部インターフェイスを所有しているので、のFEは、RFC 1812で、リンク層の要件に準拠する必要がある[2]。間違いなく、ARPのサポートは、CEのかのFEのいずれかで実施することができます。我々は後で見るように、1812の任務をRFC行動の数は、このカテゴリーに入る - 彼らはFEによって行うことができ、CEによって行うことができます。一般的なガイドラインは、分離された制御および転送プレーン間の相互運用性を確保するために必要とされます。私たちはここに提供するガイドラインは、FEには、それらを実装することを選択するかもしれないがCEが操作のこれらの種類のことができなければならないことです。これらの機能が実装されている場合のCEが決めることができるようにFEモデルは、この点でその能力を示す必要があります。
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アドレス、などのインターフェイスパラメータは、力によってのCEにより設定可能でなければなりません。 CEは、FE内の物理インタフェースがパケットを送信するかしないために利用可能であるかどうかを判定することができなければなりません。 FEも力により（アップ/ダウンリンクのような）インターフェースの状態変化のCEのを通知しなければなりません。
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.
両方のFEおよびCEは、IPプロトコルと指定されたRFC 1812としてすべての必須の拡張機能を実装する必要があります。 FEは、同様にそれらを実装することを選択するかもしれないがCEはソースルートとレコードルートなどのIPオプションを実装する必要があります。タイムスタンプオプションは、最も正確にタイムスタンプを挿入するためのFEによって実施されるべきです。 FEは、それが理解IPオプションを解釈したCEで使用するためにそのまま残りを保持する必要があります。両方のFEおよびCEは黙っICMPエラーを送信せずにパケットを破棄することを選択するかもしれないが、このようなイベントがログに記録され、カウントする必要があります。 FEが力によってCEにこのようなイベントの統計情報を報告することがあります。
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）は、単一のNE内に一度だけ減らさなければなりません。例えば、それは常に出力機能で、最後の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.
FEは、ブロードキャスト宛先アドレスまたはルータが受信するように要求しているマルチキャスト宛先アドレスを持つ通常の任意のパケットを受信して処理しなければなりません。 IPマルチキャストは、ルータでサポートされている場合、IGMPは、CEの中に実装されています。 FEは、ICMPをサポートすることは任意でありながらのCEはまた、ICMPのサポートを必要としています。そのようなオプションは、FEモデルの一部として、CEに伝達することができます。そのため、FEが常にICMPエラーメッセージを送信するためのCEに頼ることができますが、のFEは、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フォワーディングはのFEによって実装されます。ルーティングテーブルはCESで更新されると、力がのFEへのCEから新しいルートエントリを送信するために使用されます。各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は1でTTLを減少し、前に処理することができませんでした任意の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]また、例えば、複数のFEにパケットフィルタリングを実施することができます。
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.
通常のFE CEにローカルに宛てたパケットを転送。 FEも前方に例外パケットをCEに（つまりのFEパケットが処理する方法がわからない）ことがあります。 CEのは、何らかの理由でのFEによって転送されるパケットを処理するために必要とされています。力がCEにのFEから転送さの理由を示すために、パケットをいくつかのメタデータを添付することが必要になることがあります。 FEからメタデータを持つパケットを受信すると、CEはプロセスのいずれかにパケット自体を決定することができ、またはルーティングおよび管理プロトコルを含む上位層プロトコルにパケットを渡します。 CEが自身でパケットを処理する場合は、CEは、パケットを破棄することを選択するか、変更し、パケットを再送信してもよいです。 CEはまた、新しいパケットを発信し、さらに転送するためのFEにそれらを配信することができます。
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で実現されます。実際には、これはほとんどのCEが伝送制御プロトコル（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.
CEとFEはどちらものForCESプロトコルを実装する必要があります。いくつかのレイヤ4トランスポートが力をサポートするために使用される場合、CEとFEの両方が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.
内部と外部のルーティングプロトコルは、CEの上で実装されています。 CEによって発信ルーティングパケットは、送達のためのFEに転送されます。 （フォワーディングテーブルの更新等）、そのようなプロトコルの結果は力によってのFEに伝達されます。
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.
パフォーマンスやスケーラビリティの理由のために、より速い応答を必要と制御プレーン機能の部分は、複数のCEから、オフロードのFEに移動させてもよいです。例えば、OSPFで、ハロープロトコルパケットが生成され、定期的に処理されます。 CESで行われた場合に、着信Helloパケットは、内部CE-FEチャネルを介してCEにのFEでの外部インターフェイスから横断しなければなりません。同様に、アウトバウンドHelloパケットは、フェズと外部インタフェースへのCEから行かなければなりません。頻繁こんにちはアップデートは、CEの上に重い処理のオーバーヘッドを配置し、同様にCE-FEチャネルを圧倒することができます。通常、ルータでのCEよりもはるかに多くのFEがあるので、オフロードされたHelloパケットは、はるかに分布し、スケーラブルな方法で処理されています。 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によって管理可能でなければなりません」と指示します。一般に、ポスト会合相のために、（SNMPを含む）最も外部の管理タスクは、単一の機能装置の外観をサポートするためにCEとの相互作用を介して行われるべきです。したがって、SNMPエージェントは、CEのことでとのFEが受信したSNMPメッセージがそのCEにリダイレクトされることを実装することをお勧めします。 （[6]）RFC 2741で定義されたのAgentXフレームワークは、ここでのCEは複数のFEに存在する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.
この文書では、力をアーキテクチャフレームワークを定義します。これは、（一つ以上）のFE、（一つ以上）のCE、任意の一人のFEマネージャと1つのオプションCEマネージャなどのForCESネットワーク要素に関連する要素を識別する。また、これらの構成要素間の相互作用を識別し、すべての主要な基準点を説明します。すべての基準点のうち、CEとFEとの間の唯一のFPインターフェイスは、力の範囲内である、ことを指摘することは重要です。一人の力はすべての望ましいNE構成をサポートするのに十分ではないかもしれません。しかし、我々はFpのインタフェースを介して力がCEとFEの物理的分離と相互運用性を実現する上で最も重要な要素、および標準化されるべきであるので、最初のインターフェイスであると信じています。簡単で便利な構成が依然としてのみCE-FEインタフェースは標準化された状態で実装することができ、例えば、フルメッシュのFEを有する単一のCE。
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.
ジョエルM.ハルパーンは私たちに多くの洞察に満ちたコメントや提案を与え、いくつかの主要な問題点を指摘しました。 T.シュリダールは、AgentXプロトコルは、のForCESネットワーク要素を管理するためにSNMPで使用することができることを示唆しました。スーザンノウサギは軍とグレースフルリスタートの問題を指摘しました。ラスHousley、Avriドリア、ジャマル・ハディサリム、およびメーリングリスト力の多くの人はまた、貴重なフィードバックを提供します。
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とFEとの間に配備されてもよいです。このようなシナリオでは、箱の物理的なセキュリティは、このようなイン・ザ・ミドル男-、スヌーピング、および偽装などの攻撃のほとんどは、可能でないことを保証し、そのためのForCESアーキテクチャは、ボックスの物理的なセキュリティに頼ることができますこれらの攻撃およびプロトコルメカニズムを防御するためにオフにすることができます。セクション8.1.8で後述のようにしかし、それはまた、外部インターフェースを介して、サービス攻撃の拒否を示しても、このような「オール・イン・ワンボックス」展開シナリオのために、依然として潜在的な脅威であり、したがって、機構の制限速度でありますまだ必要。さまざまな展開シナリオの下でのForCES対応のネットワーク要素のセキュリティニーズを評価することが重要であることを示すために、ほんの一例です。管理者がのForCESプロトコルのために必要なセキュリティのレベルを設定することが可能でなければなりません。
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つのエンティティ間の潜在的に安全でないリンクをもたらし、したがってはるかに厳しいセキュリティ測定が必要とされます。例えば、我々は、認証がCEとCEマネージャとの間、およびいくつかの構成でFEとFEマネージャーの間で、CEマネージャとFE・マネージャーとの間必要になることを4.1節で指摘しました。 CEとFEの物理的な分離はまた、Fpのインタフェースを介してのForCESプロトコルのための深刻なセキュリティ要件を課しています。このセクションでは、最初のFEおよびCEの物理的分離によって導入することができるセキュリティ脅威を記述しようとし、そしてそれは、既存の標準のセキュリティソリューションに基づいたFPインタフェース上のForCESプロトコルの安全な動作および管理のための推奨事項とガイドラインを提供します。
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のインタフェースを中心に、力を脅威分析を提供します。それぞれの脅威はのForCESプロトコルエンティティまたは/および全体として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.
脅威：悪意のあるノードは「NEに参加する」または非常に急速に正当なCEに存在しないか、不正FEの代わりに要求「NEから削除」、およびそれによって、CEの中で不要な状態を作り出す偽のストリームを送信することができます。
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.
効果は：存在しない、または不正のFEの状態を維持する場合、CEは、他の処理のために利用できなくなることがあり、したがって、TCP SYN DoS攻撃と同様のサービス拒否（DoS）攻撃の拒否に苦しみます。複数のCEを使用する場合、不必要な状態情報は、DoS攻撃に対して、ひいては被写体複数のCE（CEによるスタンドに活性なCEから、例えば）のFRインタフェースを介して複数のCEに搬送することができます。
Requirement: A CE that receives a "join" or "remove" request should not create any state information until it has authenticated the FE endpoint.
要件：それはFEエンドポイントを認証したまでは「参加」または「削除」要求を受けたCEがどのような状態情報を作成しないでください。
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マネージャによって提供される）承認のForCES要素のリストに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フェイルオーバメカニズムを利用することができます。例えば、2つのCEを仮定し、CE-AおよびCE-Bと言う、いくつかのFEを制御しています。 CE-Aがアクティブであり、CE-Bは、スタンバイです。 CE-Aが故障した場合、CE-Bは、アクティブCEの位置を引き継ぐされます。 FEは、すでにCE-Aとの信頼関係を持っていましたが、FEには、同じの信頼関係は、CE-Bとの間で確立されていない可能性がありフェイルオーバーする前に。このように信頼関係が前またはフェイルオーバー時に確立されていない場合、悪意のあるノードは、CE-Bとして引き継ぐことができます。
Effect: The NE may be compromised after such insecure fail-over.
効果：NEは、後に損なわれる可能性があり、このような不安定なフェイルオーバー。
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スタンドバイとのFE間の信頼のレベルは、アクティブなCEとFEとの間の1ほど強力でなければなりません。 CEによるスタンドのFEとの間のセキュリティアソシエーションがフェイルオーバ前に確立されてもよいです。代わりに存在していない場合はスタンドバイ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.
脅威：いくつかのFEは同じ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のインタフェースを介してパケットを転送します。悪意のあるノードは、FEが処理とFPインタフェースを介してCEへのすべてのパケットを転送しなければならないように、外部の部屋/ Fインタフェースを介して等プロトコル・パケットをルーティングするような巨大なメッセージの嵐を生成することができます。
Effect: The CE encounters resource exhaustion and bandwidth starvation on Fp interface due to an overwhelming number of packets from FEs.
効果：CEが原因のFEからのパケットの圧倒的な数にFpのインターフェイス上の資源の枯渇や帯域幅の飢餓が発生しました。
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の両方での場所でなければなりません。レートリミッタは、部屋/ Fインタフェースを介して受信される各メッセージタイプの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]のForCESプロトコル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（Transport Layer Security）を[14]を確認します。 TLSは、IPsecは、任意のトランスポート（UDP、TCP、SCTP）で使用することができるが、そのようなユニキャスト用のTCP又はSCTPなどの信頼性の高いトランスポートで動作し、ユニキャストとマルチキャストの両方をサポートします。 TLSとIPsecの両方がのForCESプロトコルのセキュリティ要件のすべてを満たすために潜在的に使用することができます。加えて、要件を満たす他の方法も同様に使用することができるが、所与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.
力がボックスまたは物理的に安全な部屋、認証、機密性、完全性及び内部CEとFEとの間で展開されている場合は、ボックスの物理的なセキュリティによって提供されてもよいです。これにより、セキュリティメカニズムは、ネットワークトポロジとその管理ポリシーに応じて、オフにすることができます。しかし、NEがワンボックスであっても、セクション8.1.8で説明したようにDoS攻撃は、まだ部屋/ 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.
このようなTCP又はSCTPなどの信頼性の高いユニキャストトランスポートがFpのインタフェースを介して力を使用する場合、TLS [14]を使用することができます。 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）プレ会合相の間、全てのFEは、アクティブCEとスタンバイ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.
チェックのいずれかが、ステップ3）またはステップ4）で失敗した場合は5）、エンドポイントはエラーメッセージを生成し、中断しなければなりません。
6) After successful mutual authentication, a TLS session is established between the CE and FE.
6）成功した相互認証の後、TLSセッションは、CEとFEとの間に確立されます。
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のためのさまざまな方法があることに注意してください。一つの方法は、CEやFEは、証明書が失効していないことを検証するために、この事前設定されたCAを問い合わせることができるように、CAとFE ManagerまたはCEマネージャまたは他の中心的なコンポーネントを設定することです。もう一つの方法は、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.
フェイルオーバーの場合には、それは力を同期させるためにアクティブCEとスタンバイCEの責任であると、フェイルオーバー時の状態の再確立を最小にするためにTLSの状態を含む、述べています。ケアは、スタンバイ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とのインタフェースを介してこのような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のリプレイの保護メカニズムは使用できません。したがって、自動鍵管理はリプレイ保護が重要であると考えられる場合に推奨されます。そうでない場合は、手動鍵管理は、CEとFEの数が比較的少ない場合は特に、いくつかの展開シナリオには十分かもしれません。キーがさえ手動鍵管理のために、定期的に変更することをお勧めします。
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.
手動鍵管理を使用した場合9量が「NO-OP」を、図に示すようにTLSとは異なり、IPsecは、CEとFE IPレベルで、したがってセキュリティハンドシェイクの間にセキュリティサービスを提供します。以下は、このような場合の力のために取られるステップの概要を示します。
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）プレ会合相の間、全てのFEは、手動でアクティブCEとスタンバイ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に示すように、鍵交換プロセスは、以下の力をIPsecで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）プレ会合相の間、全てのFEは、アクティブCEとスタンバイ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.
チェックのいずれかが、ステップ2）または工程3）で失敗した場合4）、エンドポイントはエラーメッセージを生成し、中断しなければなりません。
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を確立する必要があります。これは、フランス（CE-CE）インタフェースしかしIPSecレイヤを横切る周期的状態の転送を最小化します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2]ベイカー、F.、エド。、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[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.、アンダーソン、T.編、 "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]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、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]ダニエル、M.、Wijnenの、B.、エリソン、M.とD.フランシスコ、 "エージェント拡張（の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]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.およびA.スミス、「使用をCOPSポリシープロビジョニング（COPS-PR）」、RFC 3084、2001年3月のため。
[8] Crouch, A. et al., "ForCES Applicability Statement", Work in Progress.
[8]クラウチ、A.ら、 "のForCESの適用に関する声明"、ProgressのWork。
[9] Anderson, T. and J. Buerkle, "Requirements for the Dynamic Partitioning of Switching Elements", RFC 3532, May 2003.
[9]アンダーソン、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.アガルワル、 "ラベル配布プロトコルのためのグレースフルリスタートメカニズム"、RFC 3478、2003年2月。
[11] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[11]モイ、J.、Pillay-Esnault、P.及びA. Lindem、 "優雅なOSPF再起動"、RFC 3623、2003年11月。
[12] Sangli, S. et al., "Graceful Restart Mechanism for BGP", Work in Progress.
[12]サングリ、S.ら、 "BGPのためのグレースフルリスタート機構"、ProgressのWork。
[13] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", Work in Progress.
[13]シャンド、M.およびL.ギンズバーグ、 "IS-ISのための再起動シグナリング"、ProgressのWork。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[14]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[15] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[15]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[16]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[17] Hardjono, T. and Weis, B. "The Multicast Group Security Architecture", RFC 3740, March 2004.
[17] Hardjono、T.とヴァイス、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.、シラー、J.及びC.カウフマン、編、 "インターネットのセキュリティメカニズム"、RFC 3631、2003年12月。
L. Lily Yang Intel Corp., MS JF3-206, 2111 NE 25th Avenue Hillsboro, OR 97124, USA
L.リリーヤンインテル、MS JF3-206、2111 NE 25日アベニューヒルズボロ、OR 97124、USA
Phone: +1 503 264 8813 EMail: lily.l.yang@intel.com
電話：+1 503 264 8813 Eメール：lily.l.yang@intel.com
Ram Dantu Department of Computer Science, University of North Texas, Denton, TX 76203, USA
コンピュータサイエンス、ノーステキサス大学、デントン、TX 76203、USAのラムDantu部門
Phone: +1 940 565 2822 EMail: rdantu@unt.edu
電話：+1 940 565 2822 Eメール：rdantu@unt.edu
Todd A. Anderson Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124, USA
トッドA.アンダーソンインテル社2111 NE 25日アベニューヒルズボロ、OR 97124、USA
Phone: +1 503 712 1760 EMail: todd.a.anderson@intel.com
電話：+1 503 712 1760 Eメール：todd.a.anderson@intel.com
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803, USA
ラムゴパルノキア・リサーチセンター5、道端の道路、バーリントン、MA 01803、USA
Phone: +1 781 993 3685 EMail: ram.gopal@nokia.com
電話：+1 781 993 3685 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。