RFC3746 日本語訳
3746 Forwarding and Control Element Separation (ForCES) Framework. L.Yang, R. Dantu, T. Anderson, R. Gopal. April 2004. (Format: TXT=98660 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループL.陽の要求をネットワークでつないでください: 3746年のインテル社カテゴリ: ノーステキサスT.アンダーソンインテル社R.ゴパルノキア2004年4月の情報のR.Dantu大学
Forwarding and Control Element Separation (ForCES) Framework
推進と制御要素分離(力)枠組み
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントは、ForCES(推進とControl Element Separation)ネットワーク要素のために建築枠組みを定義して、関連実体とそれらの相互作用を特定します。
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
1. 定義。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. コンベンションは本書では.21.2を使用しました。 用語. . . . . . . . . . . . . . . . . . . . . . 3 2。 推進と制御要素分離(力). . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3への序論。 構造. . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1。 参照が.103.2に指す要素とフランを制御してください。 Forwarding ElementsとFi参照は示されます。 . . . . . . . 11 3.3. Ceマネージャ. . . . . . . . . . . . . . . . . . . . . . . 14 3.4。 FEマネージャ. . . . . . . . . . . . . . . . . . . . . . . 14 4。 操作上のフェーズ. . . . . . . . . . . . . . . . . . . . . . 15 4.1。 プレ協会フェーズ. . . . . . . . . . . . . . . . . . 15 4.1.1。 Fl基準点. . . . . . . . . . . . . . . . 15 4.1.2。 ff基準点. . . . . . . . . . . . . . . . 16 4.1.3。 Fc基準点. . . . . . . . . . . . . . . . 17 4.2。 ポスト協会PhaseとFp基準点. . . . . . 17 4.2.1。 CEsとFEs. . 18の間の近接と内部連絡
Yang, et al. Informational [Page 1] RFC 3746 ForCES Framework April 2004
陽、他 情報[1ページ]のRFC3746は枠組みの2004年4月を強制します。
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
4.2.2. 協会設立。 . . . . . . . . . . . . 18 4.2.3. 定常状態コミュニケーション. . . . . . . . . . . . 19 4.2.4。 Fp基準点. . . . . . 21 4.2.5の向こう側のデータPackets。 プロキシFE. . . . . . . . . . . . . . . . . . . . . 22 4.3。 協会再建。 . . . . . . . . . . . . . . 22 4.3.1. CEの優雅な再開。 . . . . . . . . . . . . . . . 23 4.3.2. FEは.245を再開します。 RFC1812への適用性。 . . . . . . . . . . . . . . . . . . 25 5.1. 一般ルータ要件. . . . . . . . . . . . . . . 25 5.2。 層をリンクしてください。 . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. インターネット層のプロトコル。 . . . . . . . . . . . . . . . . 27 5.4. インターネット層の推進. . . . . . . . . . . . . . . . 27 5.5。 層. . . . . . . . . . . . . . . . . . . . . 28 5.6を輸送してください。 応用層--プロトコルを発送します。 . . . . . . . . . 29 5.7. 応用層--ネットワーク管理プロトコル。 . . . . 29 6. 概要。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 30 8。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 30 8.1. 力によって導入された潜在的な脅威の分析。 . . . 31 8.1.1. CEs. . . . 31 8.1.2における「接合してください」か「取り外してください」というメッセージ氾濫。 ものまね攻撃. . . . . . . . . . . . . . . 31 8.1.3。 反射攻撃。 . . . . . . . . . . . . . . . . . . 31 8.1.4. フェイルオーバーの間の攻撃… 32 8.1 .5。 データの保全. . . . . . . . . . . . . . . . . . 32 8.1.6。 データの機密性. . . . . . . . . . . . . . . 32 8.1.7。 セキュリティパラメタを共有します。 . . . . . . . . . . . 33 8.1.8. External Interfaceを通したサービス妨害Attack。 . 33 8.2. 力. . . . . . . . . . . 33 8.2の.1のためのセキュリティ推薦。 力があるTLSを使用します。 . . . . . . . . . . . . . . 34 8.2.2. 力があるIPsecを使用します。 . . . . . . . . . . . . . 35 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1。 引用規格。 . . . . . . . . . . . . . . . . . . 37 9.2. 有益な参照。 . . . . . . . . . . . . . . . . . 37 10. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 39 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 40
1. Definitions
1. 定義
1.1. Conventions used in this document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
Yang, et al. Informational [Page 2] RFC 3746 ForCES Framework April 2004
陽、他 情報[2ページ]のRFC3746は枠組みの2004年4月を強制します。
1.2. Terminologies
1.2. 用語
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.
アドレス可能なEntity(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.
物理的なForwarding Element(PFE)--ハードウェアを含んでいるAEは以前はよく1パケットあたりの処理と取り扱いを提供していました。 しかし、このハードウェアが成るかもしれない、(制限されない、)、ネットワークプロセッサ、ASICs(アプリケーション特有のIntegrated Circuits)、または線カード、ドーター・ボード、メザニンカードにインストールされたプロセッサかスタンドアロンの箱の中の汎用。
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 Partition--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.
物理的なControl Element(PCE)--ハードウェアを含んでいるAEは以前はよくコントロールの機能性を提供していました。 このハードウェアはメインプロセッサを通常含んでいます。
PCE Partition - A logical partition of a PCE consisting of some subset of each of the resources available on the PCE.
PCE Partition--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.
推進Element(FE)--ForCESプロトコルを実行する論理的な実体。 FEsは、ForCESプロトコルでCEによる指示されるとしての1パケットあたりの処理と取り扱いを提供するのに基盤となるハードウェアを使用します。 ただ一つの刃(または、PFE)、PFEのパーティション、またはFEsはたまたま複数のPFEsであるかもしれません。
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.
Element(CE)を制御してください--どうパケットを処理するかに関して1FEsを命令するのにForCESプロトコルを実行して、それを使用する論理的な実体。 CEsはコントロールとシグナリングプロトコルの実行などの機能性を扱います。 CEsはPCEパーティションか全体のPCEsから成るかもしれません。
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 Network Element(NE)--実体は1CEsと1FEsで構成されました。 NEは通常、内部の組織を外部実体から隠して、NEの外の実体に1ポイントの管理を代表します。
Yang, et al. Informational [Page 3] RFC 3746 ForCES Framework April 2004
陽、他 情報[3ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
プレ協会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.
ポスト協会Phase--FEがどのCEを知っている期間は逆もまた同様にそれを制御することになっています、CEとFEがお互いとのコミュニケーションを確立している時間を含んでいて。
ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES Protocol" refers only to the ForCES post-association phase protocol (see below).
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ポスト-協会Phaseプロトコル--CEsとFEsとのポスト協会フェーズコミュニケーションに使用されるプロトコル。 このプロトコルはCEからCEへのコミュニケーション、FEからFEへのコミュニケーション、または、FEとCEマネージャとのコミュニケーションに適用されません。 ForCESプロトコルはFEsが奴隷であり、CEsがマスターであるマスター奴隷プロトコルです。 このプロトコルは通信チャネル(例えば、コネクション確立、鼓動)の管理とコントロールメッセージの両方自体を含んでいます。 このプロトコルは、ただ一つのプロトコルであるかもしれない、一緒に働いている複数のプロトコルから成ることができて、またはユニキャストかマルチキャストに基づいているかもしれません。 別々のプロトコルドキュメントはこの情報を指定するでしょう。
FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use; however, this is currently out of scope. Being a logical entity, an FE manager might be physically combined with any of the other logical entities mentioned in this section.
FEマネージャ--プレ協会フェーズで運転している、どのCE(s)にFEを決定するかに原因となる論理的な実体は交信するべきです。 この過程は、CE発見と呼ばれて、利用可能なCEsの能力を学ぶFEマネージャを伴うかもしれません。 FEマネージャはどのCE(s)を使用したらよいかを決定するのに静的な構成からプレ協会フェーズプロトコル(以下を見る)までの何でも使用するかもしれません。 しかしながら、範囲の外にこれは現在、あります。 論理的な実体であり、FEマネージャは物理的にこのセクションで言及される他の論理的な実体のいずれにも結合されるかもしれません。
CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which FE to use; however, this is currently out of scope. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section.
CEマネージャ--プレ協会フェーズで運転している、どのFE(s)にCEを決定するかに原因となる論理的な実体は交信するべきです。 この過程は、FE発見と呼ばれて、利用可能なFEsの能力を学ぶCEマネージャを伴うかもしれません。 CEマネージャはどのFEを使用したらよいかを決定するのに静的な構成からプレ協会フェーズプロトコル(以下を見る)までの何でも使用するかもしれません。 しかしながら、範囲の外にこれは現在、あります。 論理的な実体であり、CEマネージャは物理的にこのセクションで言及される他の論理的な実体のいずれにも結合されるかもしれません。
Yang, et al. Informational [Page 4] RFC 3746 ForCES Framework April 2004
陽、他 情報[4ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
プレ協会Phaseプロトコル--FEマネージャとCEマネージャの間のどのCEsかFEsを使用したらよいかを決定するのに使用されるプロトコル。 プレ協会フェーズプロトコルはCE、そして/または、FE能力発見メカニズムを含むかもしれません。 そして、この能力発見の過程が完全に別々である注意、(取り替えない、)、それはForCESの中でプロトコルを使用しました。 しかしながら、2つの能力発見メカニズムが同じFEモデルを利用するかもしれません。
FE Model - A model that describes the logical processing functions of an FE.
FE Model--FEの論理的な処理機能について説明するモデル。
ForCES Protocol Element - An FE or CE.
力は要素について議定書の中で述べます--FEかCe。
Intra-FE topology - Representation of how a single FE is realized by combining possibly multiple logical functional blocks along multiple data paths. This is defined by the FE model.
イントラ-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 Topology--独身のNEの複数のFEsがどうインタコネクトされるかに関する表現。 時々、それは、FEモデルによって使用されたイントラ-FEトポロジーと区別されるために相互FEトポロジーと呼ばれます。
Inter-FE topology - See FE Topology.
相互FEトポロジー--FE Topologyを見てください。
2. Introduction to Forwarding and Control Element Separation (ForCES)
2. 推進への序論と制御要素分離(力)
An IP network element (NE) appears to external entities as a monolithic piece of network equipment, e.g., a router, NAT, firewall, or load balancer. Internally, however, an IP network element (NE) (such as a router) is composed of numerous logically separated entities that cooperate to provide a given functionality (such as routing). Two types of network element components exist: control element (CE) in control plane and forwarding element (FE) in forwarding plane (or data plane). Forwarding elements are typically ASIC, network-processor, or general-purpose processor-based devices that handle data path operations for each packet. Control elements are typically based on general-purpose processors that provide control functionality, like routing and signaling protocols.
IPネットワーク要素(NE)は例えば、一枚岩的なネットワーク装置、ルータ、NAT、ファイアウォール、または負荷分散装置として外部実体に現れます。 しかしながら、本質的に、IPネットワーク要素(NE)(ルータなどの)は協力する、与えられた機能性(ルーティングなどの)を提供する多数の論理的に切り離された実体で構成されます。 2つのタイプのネットワーク要素成分は存在しています: 制御飛行機と推進飛行機(または、データ飛行機)で要素(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
ForCESは、コントロールと推進飛行機の間の情報交換を標準化するために枠組みと関連プロトコルを定義することを目指します。 標準のメカニズムを持っているのに、CEsとFEsは物理的に切り離された規格部品になることができます。 この物理的分離はForCES構造へのいくつかの利益を生じさせます。 別々のコンポーネントで、すべてのコンポーネントの専門家になる必要はなくて、コンポーネント業者は1つのコンポーネントを専門とすることができるでしょう。 そしてまた、異なったコンポーネント業者からのCEsとFEsが互いと共に標準プロトコルで共同利用できて、したがって、システム業者がCEsを一緒に統合するのが可能になる。
Yang, et al. Informational [Page 5] RFC 3746 ForCES Framework April 2004
陽、他 情報[5ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
異なったコンポーネント供給者からのFEs。 この相互運用性はシステム業者のために増加するデザイン選択と柔軟性に翻訳されます。 全体的に見て、ForCESは相互運用性を維持している間、コントロールと推進飛行機の両方で急速な革新を可能にするでしょう。 また、フォークリフトアップグレードの必要性なしで追加推進かコントロール容量を既存のネットワーク要素に追加できるので、この構造で容易にスケーラビリティを提供します。
------------------------- -------------------------
| 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
------------------------- ------------------------- | 制御刃A| | 制御刃B| | (Ce) | | (Ce) | ------------------------- ------------------------- ^ | ^ | | | | | | V| V--------------------------------------------------------- | スイッチ織物バックプレーン| --------------------------------------------------------- ^ | ^ | ^ | | | | | . . . | | | V| V| V------------ ------------ ------------ |ルータ| |ルータ| |ルータ| |刃#1| |刃#2| |刃#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つの例が刃のレベルにあります。 図1はルータのそのような例の構成を示しています、2枚の制御刃と複数の推進刃で、とすべてがスイッチ織物バックプレーンとインタコネクトしました。 そのような車台構成に、ルータ刃はFEsですが、制御刃はCEsであり、スイッチ織物バックプレーンはすべての刃のための物理的な内部連絡を提供します。 制御刃Bは冗長を提供するバックアップCEであるかもしれませんが、制御刃Aは第一のCEであるかもしれません。 また、高可用性サポートのための余分なスイッチ織物を持っているのも可能です。 今日のこの種類の構成があるルータは、CEsとFEsの間で通信するのに独占インタフェースを使用します。 ForCESの目標はそのような独占インタフェースを標準プロトコルに取り替えることです。 すべての刃の上に実行されたForCESのような標準プロトコルで、業者Xと業者Yから刃を進めるのからの制御刃が1個の車台で継ぎ目なく一緒に動作するのは可能になります。
Yang, et al. Informational [Page 6] RFC 3746 ForCES Framework April 2004
陽、他 情報[6ページ]のRFC3746は枠組みの2004年4月を強制します。
------- -------
| CE1 | | CE2 |
------- -------
^ ^
| |
V V
============================================ Ethernet
^ ^ . . . ^
| | |
V V V
------- ------- --------
| FE#1| | FE#2| | FE#n |
------- ------- --------
^ | ^ | ^ |
| | | | | |
| V | V | V
------- ------- | CE1| | CE2| ------- ------- ^ ^ | | V V============================================ イーサネット^ ^… ^| | | V V V------- ------- -------- | FE#1| | FE#2| | FE#n| ------- ------- -------- ^ | ^ | ^ | | | | | | | | V| V| V
Figure 2. A router configuration example with separate boxes.
図2。 別々の箱があるルータ構成の例。
Another level of physical separation between the CEs and FEs can be at the box level. In such a configuration, all the CEs and FEs are physically separated boxes, interconnected with some kind of high speed LAN connection (like Gigabit Ethernet). These separated CEs and FEs are only one hop away from each other within a local area network. The CEs and FEs communicate to each other by running ForCES, and the collection of these CEs and FEs together become one routing unit to the external world. Figure 2 shows such an example.
CEsとFEsの間の別のレベルの物理的分離が箱のレベルにあることができます。 そのような構成では、すべてのCEsとFEsがある種の高速LAN接続(Gigabitイーサネットのような)と共にインタコネクトされた物理的に切り離された箱です。 これらの切り離されたCEsとFEsはローカル・エリア・ネットワークの中で遠くで互いからワンバウンドであるだけです。 CEsとFEsはForCES、およびこれらのCEsの収集を走らせることによって、互いに交信します、そして、一緒にFEsは外界への1ルーティングユニットになります。 図2はそのような例を示しています。
In both examples shown here, the same physical interconnect is used for both CE-to-FE and FE-to-FE communication. However, that does not have to be the case. One reason to use different interconnects is that the CE-to-FE interconnect does not have to be as fast as the FE-to-FE interconnect, so the more faster and more expensive connections can be saved for FE-to-FE. The separate interconnects may also provide reliability and redundancy benefits for the NE.
ここの両方の例では、同じ物理的な内部連絡はCEからFEとFEからFEへのコミュニケーションの両方に使用されます。 しかしながら、それはそうである必要はありません。 異なった内部連絡を使用する1つの理由がCEからFEへの内部連絡がFEからFEへの内部連絡と同じくらい速い必要はないということであるので、FEからFEのために、より多くの、より速くて、より高価な接続を救うことができます。 また、別々の内部連絡はNEのために信頼性と冗長に利益を提供するかもしれません。
Some examples of control functions that can be implemented in the CE include routing protocols like RIP, OSPF, and BGP, control and signaling protocols like RSVP (Resource Reservation Protocol), LDP (Label Distribution Protocol) for MPLS, etc. Examples of forwarding functions in the FE include LPM (longest prefix match) forwarder, classifiers, traffic shaper, meter, NAT (Network Address Translators), etc. Figure 3 provides example functions in both CE and FE. Any given NE may contain one or many of these CE and FE functions in it. The diagram also shows that the ForCES Protocol is used to transport both the control messages for ForCES itself and the
CEで実行できるコントロール機能に関するいくつかの例がRSVP(リソース予約プロトコル)、MPLSのための自由民主党(ラベルDistributionプロトコル)などのようなリップ、OSPF、およびBGPのようなルーティング・プロトコル、コントロール、およびシグナリングプロトコルを含んでいます。 FEでの推進機能に関する例はLPM(最も長い接頭語マッチ)混載業者、クラシファイア、交通整形器、メーター、NAT(ネットワークAddress Translators)などを含んでいます。 図3はCEとFEの両方に例の機能を供給します。 どんな与えられたNEもそれにこれらのCEとFE機能の1か多くを含むかもしれません。 そしてまた、ダイヤグラムが、ForCESプロトコルがForCES自身への両方のコントロールメッセージを輸送するのに使用されるのを示す。
Yang, et al. Informational [Page 7] RFC 3746 ForCES Framework April 2004
陽、他 情報[7ページ]のRFC3746は枠組みの2004年4月を強制します。
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(例えば、ルーティングパケット)で/からコントロール機能まで溯源されるか、または運命づけられているデータ・パケット。 セクション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 |
-------------------------------------------------
------------------------------------------------- | | | | | | | |OSPF|裂け目|BGP|RSVP|自由民主党|. . . | | | | | | | | ------------------------------------------------- | 力は連結します。| ------------------------------------------------- ^ ^力| |データコントロール| |パケットメッセージ| |(例えば、ルーティングパケット) vに対して------------------------------------------------- | 力は連結します。| ------------------------------------------------- | | | | | | | |LPM Fwd|メーター|整形器|NAT|Classi|. . . | | | | | |fier| | ------------------------------------------------- | FEリソース| -------------------------------------------------
Figure 3. Examples of CE and FE functions.
図3。 CEとFE機能に関する例。
A set of requirements for control and forwarding separation is identified in [4]. This document describes a ForCES architecture that satisfies the architectural requirements of [4] and defines a framework for ForCES network elements and the associated entities to facilitate protocol definition. Whenever necessary, this document uses many examples to illustrate the issues and/or possible solutions in ForCES. These examples are intended to be just examples, and should not be taken as the only or definite ways of doing certain things. It is expected that a separate document will be produced by the ForCES working group to specify the ForCES Protocol.
コントロールと推進分離のための1セットの要件は[4]で特定されます。 このドキュメントは、[4]の建築要件を満たすForCES構造について説明して、ForCESネットワーク要素と関連実体がプロトコル定義を容易にするように、枠組みを定義します。 必要であるときはいつも、このドキュメントは、ForCESの問題、そして/または、可能な解決策を例証するのに多くの例を使用します。 これらの例をただ例であることを意図して、あることをする唯一の、または、明確な方法としてみなすべきではありません。 別々のドキュメントがForCESプロトコルを指定するためにForCESワーキンググループによって製作されると予想されます。
3. Architecture
3. 構造
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 NEsの部品を定義します。 これらのコンポーネントはフレキシブルなパケット処理のためにtopologiesの異種で接続されるかもしれません。
Yang, et al. Informational [Page 8] RFC 3746 ForCES Framework April 2004
陽、他 情報[8ページ]のRFC3746は枠組みの2004年4月を強制します。
---------------------------------------
| 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
--------------------------------------- | ネットワーク要素を強制します。| -------------- Fc| -------------- -------------- | | Ceマネージャ|---------+-| Ce1|------| Ce2| | -------------- | | | フラン| | | | | -------------- -------------- | | Fl| | | fp/| | | fp| |----------| / | | | | |/ | | | | | | | | | fp/|----| | | | | /--------/ | | -------------- ff| -------------- -------------- | | FEマネージャ|---------+-| FE1| Fi| FE2| | -------------- | | |------| | | | -------------- -------------- | | | | | | | | | | | ----+--+--+--+----------+--+--+--+----- | | | | | | | | | | | | | | | | Fi/f Fi/f
Fp: CE-FE interface
Fi: FE-FE interface
Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface
fp: CE-FEはFiを連結します: FE-FEはフランを連結します: CE-CEはFcを連結します: CeマネージャとCe ffの間で連結してください: FEマネージャとFE Flの間で連結してください: CeマネージャとFEマネージャFi/fの間で連結してください: FEの外部のインタフェース
Figure 4. ForCES Architectural Diagram
図4。 建築ダイヤグラムを強制します。
The diagram in Figure 4 shows the logical components of the ForCES architecture and their relationships. There are two kinds of components inside a ForCES network element: control element (CE) and forwarding element (FE). The framework allows multiple instances of CE and FE inside one NE. Each FE contains one or more physical media interfaces for receiving and transmitting packets from/to the external world. The aggregation of these FE interfaces becomes the NE's external interfaces. In addition to the external interfaces, there must also exist some kind of interconnect within the NE so that the CE and FE can communicate with each other, and one FE can forward packets to another FE. The diagram also shows two entities outside of the ForCES NE: CE Manager and FE Manager. These two ancillary entities provide configuration to the corresponding CE or FE in the pre-association phase (see Section 4.1).
図4のダイヤグラムはForCES構造と彼らの関係の論理的なコンポーネントを示しています。 ForCESネットワーク要素の中に2種類のコンポーネントがあります: 要素(CE)と推進要素(FE)を制御してください。 枠組みは1NEの中にCEとFEの複数の例を許容します。 各FEは/から外界までパケットを受けて、送るための1つ以上の物理的なメディアインタフェースを含んでいます。 これらのFEインタフェースの集合はNEの外部のインタフェースになります。 また、外部のインタフェースに加えて、ある種の内部連絡が存在しなければなりません。NEの中では、CEとFEが互い、および1FEとコミュニケートできるのが別のFEにパケットを送ることができます。 また、ダイヤグラムはForCES NEの外に2つの実体を示しています: CeマネージャとFEマネージャ。 これらの2つの付属の実体がプレ協会フェーズで対応するCEかFEに構成を供給します(セクション4.1を見てください)。
Yang, et al. Informational [Page 9] RFC 3746 ForCES Framework April 2004
陽、他 情報[9ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
便利において、これらのコンポーネントの間の論理的な相互作用は基準点のFp、Fc、Ff、フラン、Fl、およびFiによってラベルされます、図4に示されるように。 FEの外部のインタフェースはFi/fとしてラベルされます。 それぞれのこれらの基準点のためにセクション3と4にその他の詳細を提供します。 しかしながら、ForCESプロトコルは1つの基準点の上で定義されるだけです--これらのすべての基準点がForCES構造を理解するのにおいて重要である、fp。
The interface between two ForCES NEs is identical to the interface between two conventional routers and these two NEs exchange the protocol packets through the external interfaces at Fi/f. ForCES NEs connect to existing routers transparently.
2ForCES NEsの間のインタフェースは2つの従来のルータの間のインタフェースと同じです、そして、これらの2NEsがFi/fの外部のインタフェースを通してプロトコルパケットを交換します。 ForCES NEsは透明に既存のルータに接続します。
3.1. Control Elements and Fr Reference Point
3.1. 制御要素と参照が指すフラン
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と複数のFEsのような簡単な構成のためのコントロールと推進分離を可能にするために指すフランの向こう側にどんなプロトコルも定義するのは必要ではありません。 しかしながら、この構造は、複数のCEsがネットワーク要素で現在であることを許可します。 実現が複数のCEsを使用する場合では、一緒にCEsとFEsが独身のNEとして見える不変式を維持しなければなりません。
Multiple CEs may be used for redundancy, load sharing, distributed control, or other purposes. Redundancy is the case where one or more CEs are prepared to take over should an active CE fail. Load sharing is the case where two or more CEs are concurrently active and any request that can be serviced by one of the CEs can also be serviced by any of the other CEs. For both redundancy and load sharing, the CEs involved are equivalently capable. The only difference between these two cases is in terms of how many active CEs there are simultaneously. Distributed control is the case where two or more CEs are concurrently active but certain requests can only be serviced by certain CEs.
複数のCEsが冗長、負荷分割法、分散制御、または他の目的に使用されるかもしれません。 冗長はアクティブなCEが失敗するなら1CEsが引き継ぐように準備されるケースです。 負荷分割法は2CEsが同時にアクティブであるケースです、そして、また、他のCEsのいずれもCEsのひとりが修理できるどんな要求も修理できます。 冗長と負荷分割法の両方に関しては、かかわったCEsは同等にできます。 同時に、あるいくつのアクティブなCEsに関してこれらの2つのケースの唯一の違いがあるか。 分散制御は2CEsが、あるCEsが要求を修理できるだけであるのを同時に、アクティブですが、確信しているケースです。
When multiple CEs are employed in a ForCES NE, their internal organization is considered an implementation issue that is beyond the scope of ForCES. CEs are wholly responsible for coordinating amongst themselves via the Fr reference point to provide consistency and synchronization. However, ForCES does not define the implementation or protocols used between CEs, nor does it define how to distribute functionality among CEs. Nevertheless, ForCES will support mechanisms for CE redundancy or fail over, and it is expected that vendors will provide redundancy or fail over solutions within this framework.
複数のCEsがForCES NEで使われるとき、彼らの内部の組織はForCESの範囲にある導入問題であると考えられます。 CEsは完全に一貫性と同期を提供するためにフランを通した自分たちの中で参照ポイントを調整するのに責任があります。 しかしながら、ForCESはCEsの間で使用される実現かプロトコルを定義しません、そして、それはCEsに機能性を分配する方法を定義しません。 それにもかかわらず、ForCESはCE冗長かフェイルオーバーのためにメカニズムをサポートするでしょう、そして、業者がこの枠組みの中で冗長かフェイルオーバー解決法を提供すると予想されます。
Yang, et al. Informational [Page 10] RFC 3746 ForCES Framework April 2004
陽、他 情報[10ページ]のRFC3746は枠組みの2004年4月を強制します。
3.2. Forwarding Elements and Fi reference point
3.2. 参照ポイントをElementsとFiに送ります。
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はCEによる指示されるとしての1パケットあたりの処理と取り扱いを提供するのにForCESプロトコルを実行して、基盤となるハードウェアを使用する論理的な実体です。 1物理的なFEを複数の論理的なFEsに仕切るのは可能です。 また、1FEが複数の物理的なFEsを使用するのも、可能です。 物理的なFE(s)と論理的なFE(s)の間のマッピングはForCESの範囲を超えています。 例えば、ForCESの物理的なFEでそれぞれの論理的なFEsに利用可能な(例えば、ポート、メモリ、推進テーブルエントリー)をそれぞれに関するリソースの何らかの部分に割り当てることによって、物理的なFEの論理的なパーティションを作成できます。 FE仮想化のそのような概念は[9]で説明されるように仮想のスイッチング素子に類似しています。 FE仮想化がプレ協会フェーズだけで起こるなら、それはForCESに変化も与えません。 しかしながら、FE仮想化が既存のFEから取られたリソース変化をもたらすなら(既にForCESポスト協会フェーズに参加して)、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.
FEsはCEsによる指示されるとしてのすべてのパケット処理機能を実行します。 FEsには、それら自身のイニシアチブが全くありません。 代わりに、彼らが言われるように、FEsは奴隷であり、するだけです。 FEsは同時に参照ポイントFpの向こう側に1CEsとコミュニケートするかもしれません。 FEsには、CE冗長、負荷分割法、または分散制御の考えが全くありません。 代わりに、FEsはそれらを制御するのが認可されたどんなCEからもコマンドを受け入れます、そして、冗長、負荷分割法、または分散制御を達成するために自分たちの中で調整するのは、CEs次第です。 考えはFEsがパケット処理機能に彼らのリソースの焦点を合わせることができるようにできるだけ簡単で馬鹿にFEsを保つことです。 プロトコル交換、各FEがそうするForCEsによって別の方法で構成されるか、または決定されない場合、入って来た状態で認可された過程は、第1で彼らを受けるのに応じてそれが向けられる状態で最初に基礎に役立ちに来るように命令します。
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では、第一のCE(CE1)とバックアップCE(CE2)の両方からコマンドを受け入れるためにFE1とFE2を構成できます。 恐らくCE1の故障の検出と、フランかFp基準点の向こう側に、CE2は、CE1の活動を引き継ぐために構成されます。 これについて、ForCESの範囲を超えていて、さらに議論しません。
Distributed control can be achieved in a similar fashion, without much intelligence on the part of FEs. For example, FEs can be configured to detect RSVP and BGP protocol packets, and forward RSVP packets to one CE and BGP packets to another CE. Hence, FEs may need to do packet filtering for forwarding packets to specific CEs.
FEs側の多くの知性なしで分散制御を同様に達成できます。 例えば、RSVP、BGPプロトコルパケット、および前進のRSVPパケットを別のCEに1つのCEとBGPパケットまで検出するためにFEsを構成できます。 したがって、FEsは、推進のために特定のCEsにパケットをフィルターにかけるパケットをする必要があるかもしれません。
Yang, et al. Informational [Page 11] RFC 3746 ForCES Framework April 2004
陽、他 情報[11ページ]のRFC3746は枠組みの2004年4月を強制します。
------- Fr -------
| CE1 | ------| CE2 |
------- -------
| \ / |
| \ / |
| \ / |
| \/Fp |
| /\ |
| / \ |
| / \ |
------- Fi -------
| FE1 |<----->| FE2 |
------- -------
------- フラン------- | 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.
この構造は、複数のFEsがNEで現在であることを許可します。 [4] ForCESプロトコルが少なくとも何百FEs([4] セクション5、要件#11を見る)にスケーリングできなければならない命令。 それぞれのこれらのFEsには、異なったメディアインタフェースがある異なったセットのパケット処理機能が潜在的にあるかもしれません。 FEsは他のFEsと外部実体がある層-2の接続性の基本的な維持に責任があります。 多くの層-2つのメディアが精巧な制御プロトコルを含んでいます。 FORCESプロトコル(Fp基準点の上の)は、CEがこれらのメディアの適切な知性とコントロールを馬鹿なFEモデルと共に保つのに提供できるように、そのようなプロトコルへのメッセージを伝えることができるでしょう。
When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 5, Requirement #3). Packets that enter the NE via one FE and leave the NE via a different FE are transferred between FEs across the Fi reference point. The Fi reference point could be used by FEs to discover their (inter-FE) topology, perhaps during the pre-association phase. The Fi reference point is a separate protocol from the Fp reference point and is not currently defined by the ForCES Protocol.
複数のFEsが存在しているとき、ForCESは、パケットが1FEでNEに到着して、異なったFEを通してNEを残すことができなければならないのを必要とします([4]を見てください、セクション5、Requirement#3)。 Fi基準点の向こう側に1FEを通してNEに入って、異なったFEを通してNEを残すパケットをFEsの間に移します。 Fi基準点は、恐らくプレ協会段階の間、彼らの(相互FE)トポロジーを発見するのにFEsによって使用されるかもしれません。 Fi基準点は、Fp基準点からの別々のプロトコルであり、現在、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).
topologiesの異種でFEsを接続できるでしょう、そして、パケット処理はトポロジーの数個のFEsの向こう側に広まるかもしれません。 したがって、論理的なパケット流動は物理的なFEトポロジーと異なっているかもしれません。 図6はいくつかのトポロジーの例を提供します。 FEsの間にパケットを送るのが必要であるときに、CEは、FEトポロジーを理解する必要があります。 FEトポロジーはCEsによってFEsからForCESプロトコルで質問されるかもしれませんが、FEsはその情報をCEsに供給する必要はありません。 それで、また、FEトポロジー情報は他の手段でForCESプロトコル(相互FEトポロジー発見プロトコルのような)の外に集められるかもしれません。
Yang, et al. Informational [Page 12] RFC 3746 ForCES Framework April 2004
陽、他 情報[12ページ]のRFC3746は枠組みの2004年4月を強制します。
-----------------
| CE |
-----------------
^ ^ ^
/ | \
/ v \
/ ------- \
/ +->| FE3 |<-+ \
/ | | | | \
v | ------- | v
------- | | -------
| FE1 |<-+ +->| FE2 |
| |<--------------->| |
------- -------
^ | ^ |
| | | |
| v | v
----------------- | Ce| ----------------- ^ ^ ^ / | \/v\/------- \ / +->| FE3| <、-+ \ / | | | | \v| ------- | v------- | | ------- | FE1| <、-+ +->| FE2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| ------- ------- ^ | ^ | | | | | | v| v
(a) Full mesh among FE1, FE2, and FE3
(a) FE1、FE2、およびFE3の中の完全なメッシュ
-----------
| CE |
-----------
^ ^ ^ ^
/ | | \
/------ | | ------\
v v v v
------- ------- ------- -------
| FE1 |<->| FE2 |<->| FE3 |<->| FE4 |
------- ------- ------- -------
^ | ^ | ^ | ^ |
| | | | | | | |
| v | v | v | v
----------- | Ce| ----------- ^ ^ ^ ^ / | | \ /------ | | ------\v対v v------- ------- ------- ------- | FE1| <->| FE2| <->| FE3| <->| FE4| ------- ------- ------- ------- ^ | ^ | ^ | ^ | | | | | | | | | | v| v| v| v
(b) Multiple FEs in a daisy chain
(b) デイジーチェインによる複数のFEs
Yang, et al. Informational [Page 13] RFC 3746 ForCES Framework April 2004
陽、他 情報[13ページ]のRFC3746は枠組みの2004年4月を強制します。
^ |
| v
-----------
| FE1 |<-----------------------|
----------- |
^ ^ |
/ \ |
| ^ / \ ^ | V
v | v v | v ----------
--------- --------- | |
| FE2 | | FE3 |<------------>| CE |
--------- --------- | |
^ ^ ^ ----------
| \ / ^ ^
| \ / | |
| v v | |
| ----------- | |
| | FE4 |<----------------------| |
| ----------- |
| | ^ |
| v | |
| |
|----------------------------------------|
^ | | v----------- | FE1| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ----------- | ^ ^ | / \ | | ^ / \ ^ | V v| vに対して| v---------- --------- --------- | | | FE2| | FE3| <、-、-、-、-、-、-、-、-、-、-、--、>| Ce| --------- --------- | | ^ ^ ^ ---------- | \ / ^ ^ | \ / | | | vに対して| | | ----------- | | | | FE4| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ----------- | | | ^ | | v| | | | |----------------------------------------|
(c) Multiple FEs connected by a ring
(c) 複数のFEsがリングで接続しました。
Figure 6. Some examples of FE topology
図6。 FEトポロジーに関するいくつかの例
3.3. CE Managers
3.3. Ceマネージャ
CE managers are responsible for determining which FEs a CE should control. It is legitimate for CE managers to be hard-coded with the knowledge of with which FEs its CEs should communicate with. A CE manager may also be physically embedded into a CE and be implemented as a simple keypad or other direct configuration mechanism on the CE. Finally, CE managers may be physically and logically separate entities that configure the CE with FE information via such mechanisms as COPS-PR [7] or SNMP [5].
CEがどのFEsを制御するはずであるかを決定するのにCEマネージャは責任があります。 CEマネージャがCEsがどのFEsと共にコミュニケートするはずであるかに関する知識で一生懸命コード化されているのは、正統です。 CEマネージャは、また、物理的にCEに埋め込まれていて、簡単なキーパッドか他のダイレクト構成メカニズムとしてCEで実行されるかもしれません。 最終的に、CEマネージャは物理的にそうであり、FE情報でCOPS-PR[7]のようなメカニズムでCEを構成する論理的に別々の実体かSNMPが[5]です。
3.4. FE Managers
3.4. FEマネージャ
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
何か特定のFEが初めはどのCEで交信するはずであるかを決定するのにFEマネージャは責任があります。 CEマネージャのように、FEマネージャがどのCEと共にFEsが交信するはずであり、FEマネージャが実行される置かれた制限が進行中でないかをどう決めるかに関して制限は全く課されません。 各FEには、唯一無二の1FEがあるはずです。
Yang, et al. Informational [Page 14] RFC 3746 ForCES Framework April 2004
陽、他 情報[14ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
異なったFEsが持っているかもしれない間、マネージャは同じであるか異なったFEマネージャがいてください。 各マネージャは、他のマネージャの如何にかかわらず存在して、作動するのを選ぶことができます。
4. Operational Phases
4. 操作上のフェーズ
Both FEs and CEs require some configuration to be in place before they can start information exchange and function as a coherent network element. Two operational phases are identified in this framework: pre-association and post-association.
彼らが論理的なネットワーク要素として情報交換を始めて、機能できる前にFEsとCEsの両方が、何らかの構成が適所にあるのを必要とします。 2つの操作上のフェーズがこの枠組みで特定されます: プレ協会とポスト協会。
4.1. Pre-association Phase
4.1. プレ協会フェーズ
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.
Pre-協会フェーズはFEマネージャとCEマネージャがFEとCEが同じネットワーク要素の一部であるべきであるかどうかと決心している期間です。 この段階の間に使用されるプロトコルはFl、Ff、およびFc基準点の上に交換処理のすべてかいくつかを含むかもしれません。 しかしながら、これらは任意であるかもしれません、そして、ForCESプロトコルの範囲の中にこのなにもありません。
4.1.1. Fl Reference Point
4.1.1. Fl参照ポイント
CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated. Communication across the Fl reference point is optional in this architecture. No requirements are placed on this reference point.
CEマネージャとFEマネージャは、個々のCEとFEか、CEsとFEsの1セットがそうするべきであるか否かに関係なく、関連しているように決定するためにプレ協会フェーズにおけるFl基準点の向こう側に交信するかもしれません。 Fl基準点の向こう側のコミュニケーションはこの構造で任意です。 要件は全くこの基準点に置かれません。
CE managers and FE managers may be operated by different entities. The operator of the CE manager may not want to divulge, except to specified FE managers, any characteristics of the CEs it manages. Similarly, the operator of the FE manager may not want to divulge FE characteristics, except to authorized entities. As such, CE managers and FE managers may need to authenticate one another. Subsequent communication between CE managers and FE managers may require other security functions such as privacy, non-repudiation, freshness, and integrity.
CEマネージャとFEマネージャは異なった実体によって手術されるかもしれません。 指定されたFE以外に、CEマネージャのオペレータはマネージャ(それが管理するCEsのどんな特性も)を明かしたがっていないかもしれません。 同様に、権限のある機関以外に、FEマネージャのオペレータはFEの特性を明かしたがっていないかもしれません。 そういうものとして、CEマネージャとFEマネージャは、お互いを認証する必要があるかもしれません。 CEマネージャとFEマネージャとのその後のコミュニケーションはプライバシーや、非拒否や、新しさや、保全などの他のセキュリティ機能を必要とするかもしれません。
Yang, et al. Informational [Page 15] RFC 3746 ForCES Framework April 2004
陽、他 情報[15ページ]のRFC3746は枠組みの2004年4月を強制します。
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------------>| |
FEマネージャFE CeマネージャCe| | | | | | | | |(セキュリティ交換) | | 1|<------------------------------>| | | | | | |(CEsのリストと彼らの属性) | 2|<-------------------------------| | | | | | |(FEsのリストと彼らの属性) | 3|------------------------------->| | | | | | | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--Fl------------>|、|
Figure 7. An example of a message exchange over the Fl reference
point
図7。 Fl基準点の上の交換処理に関する例
Once the necessary security functions have been performed, the CE and FE managers communicate to determine which CEs and FEs should communicate with each other. At the very minimum, the CE and FE managers need to learn of the existence of available FEs and CEs respectively. This discovery process may entail one or both managers learning the capabilities of the discovered ForCES protocol elements. Figure 7 shows an example of a possible message exchange between the CE manager and FE manager over the Fl reference point.
CEとFEマネージャは、どのCEsとFEsが互いにコミュニケートするはずであるかを決定するために一度、必要なセキュリティ機能が実行されたことがあると伝えます。 非常に最小では、CEとFEマネージャは、それぞれ利用可能なFEsとCEsの存在を知る必要があります。 この発見の過程は発見されたForCESプロトコル要素の能力を学ぶものかマネージャの両方を伴うかもしれません。 図7はFl基準点の上にCEマネージャとFEマネージャの間の可能な交換処理に関する例を示しています。
4.1.2. Ff Reference Point
4.1.2. ff参照ポイント
The Ff reference point is used to inform forwarding elements of the association decisions made by the FE manager in the pre-association phase. Only authorized entities may instruct an FE with respect to which CE should control it. Therefore, privacy, integrity, freshness, and authentication are necessary between the FE manager and FEs when the FE manager is remote to the FE. Once the appropriate security has been established, the FE manager instructs the FEs across this reference point to join a new NE or to disconnect from an existing NE. The FE Manager could also assign unique FE identifiers to the FEs using this reference point. The FE identifiers are useful in the post association phase to express FE topology. Figure 8 shows example of a message exchange over the Ff reference point.
Ff基準点は、プレ協会フェーズでFEマネージャによってされた協会決定の推進要素を知らせるのに使用されます。 権限のある機関だけがCEがそれを制御するはずであるFEを命令するかもしれません。 したがって、FEマネージャがFEにリモートであるときに、プライバシー、保全、新しさ、および認証がFEマネージャとFEsの間で必要です。 適切なセキュリティがいったん確立されると、FEマネージャは、新しいNEを接合するか、または既存のNEから連絡を断つようこの基準点の向こう側のFEsに命令します。 また、FEマネージャは、この基準点を使用することでユニークなFE識別子をFEsに割り当てることができるでしょう。 FE識別子はポスト協会フェーズで急行FEトポロジーの役に立ちます。 エイト環はFf基準点の上に交換処理に関する例を示しています。
Yang, et al. Informational [Page 16] RFC 3746 ForCES Framework April 2004
陽、他 情報[16ページ]のRFC3746は枠組みの2004年4月を強制します。
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---->|
FEマネージャFE CeマネージャCe| | | | | | | | |(セキュリティ交換) |(セキュリティ交換) 1| <、-、-、-、-、-、-、-、-、-、-、--、>|認証1| <、-、-、-、-、-、-、-、-、-、--、>|認証| | | | |(FE ID、属性) |(CE ID、属性) 2| <、-、-、-、-、-、-、-、-、-、-、-、--、|2を要求してください。| <、-、-、-、-、-、-、-、-、-、-、--、|要求| | | | 3|、-、-、-、-、-、-、-、-、-、-、-、--、>|応答3|、-、-、-、-、-、-、-、-、-、-、--、>|応答|(対応するCE ID) |(対応するFE ID) | | | | | | | | | <、-、-、-、--ff----->| | <、-、-、-、--Fc---->|
Figure 8. Examples of a message exchange
over the Ff and Fc reference points
エイト環。 FfとFc基準点の上の交換処理に関する例
Note that the FE manager function may be co-located with the FE (such as by manual keypad entry of the CE IP address), in which case this reference point is reduced to a built-in function.
FEマネージャ機能がFE(CE IPアドレスの手動のキーパッドエントリーなどの)と共に共同見つけられるかもしれなくて、その場合、この基準点が組込み関数に減少することに注意してください。
4.1.3. Fc Reference Point
4.1.3. Fc参照ポイント
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マネージャがリモートであるときに、権限のある機関だけが、あるFEsを制御するようCEに命令するかもしれません。 また、プライバシー、保全、新しさ、および認証がこの基準点の向こう側にそのような構成で必要です。 適切なセキュリティがいったん確立されると、CEマネージャは彼らがどのFEsに関して制御するべきであるか、そして、どのように彼らを制御するべきであるようCEsに命令します。 エイト環はFc基準点の上に交換処理に関する例を示しています。
As with the FE manager and FEs, configurations are possible where the CE manager and CE are co-located and no protocol is used for this function.
FEマネージャとFEsのように、CEマネージャとCEが共同見つけられていて、プロトコルが全くこの機能に使用されないところで構成は可能です。
4.2. Post-association Phase and Fp reference point
4.2. ポスト協会PhaseとFp参照ポイント
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基準点の向こう側に排他的に使用されます。
Yang, et al. Informational [Page 17] RFC 3746 ForCES Framework April 2004
陽、他 情報[17ページ]のRFC3746は枠組みの2004年4月を強制します。
4.2.1. Proximity and Interconnect between CEs and FEs
4.2.1. CEsとFEsの間の近接と内部連絡
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作業部会はForCESの最初のバージョンがIPネットワークで「非常に近い」CE/FE場所に焦点を合わせられるという意識的な決定をしました。 まさしくそのClose場所はコントロールと同じ物理的な箱、ある企業内情報通信網ホップ([8])で大部分で切り離されるところでコンポーネントである要素を進めるのから成ります。 イーサネット接続、バックプレーン、ATM(セル)織物などを含むさまざまな内部連絡技術でCEsとFEsを接続できます。 ForCESはそれぞれのこれらの内部連絡を支持するはずであることができます([4] セクション5、要件#1を見てください)。 CEsとFEsが単一のL3ルーティングホップを超えて切り離されるとき、ForCESプロトコルは輸送目的のための適切な信頼性、セキュリティ、および輻輳制御(例えば、TCP、SCTP)がある既存のRFC2914[3]対応することのL4プロトコルを利用するでしょう。
4.2.2. Association Establishment
4.2.2. 協会設立
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|<----------------------|
| |
FE Ce| | |(セキュリティ交換。) | 1| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(NEを加わらせてください。) 2|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(あなたはどういうFEですか? -- 能力質問) 3| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(ここに、私のFE機能/状態があります: 説明するモデルを使用してください) 4|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(FEのためにコンフィグに頭文字をつけてください--任意)です。 5| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(私は行く準備ができています。 私はそうするでしょう。) 6|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(前に進んでください!) | 7| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 9. Example of a message exchange between CE and FE
over Fp to establish an NE association
図9。 NE協会を設立するFpの上のCEとFEの間の交換処理に関する例
Yang, et al. Informational [Page 18] RFC 3746 ForCES Framework April 2004
陽、他 情報[18ページ]のRFC3746は枠組みの2004年4月を強制します。
As an example, figure 9 shows some of the message exchange that may happen before the association between the CE and FE is fully established. Either the CE or FE can initiate the connection.
例、9が完全に確立されるのをCEとFEとの協会の前で起こるかもしれない交換処理のいくつかに示す図として。 CEかFEのどちらかが接続を開始できます。
Security handshake is necessary to authenticate the two communication endpoints to each other before any further message exchange can happen. The security handshake should include mutual authentication and authorization between the CE and FE, but the exact details depend on the security solution chosen by the ForCES Protocol. Authorization can be as simple as checking against the list of authorized end points provided by the FE or CE manager during the pre-association phase. Both authentication and authorization must be successful before the association can be established. If either authentication or authorization fails, the end point must not be allowed to join the NE. After the successful security handshake, message authentication and confidentiality are still necessary for the on-going information exchange between the CE and FE, unless some form of physical security exists. Whenever a packet fails authentication, it must be dropped and a notification may be sent to alert the sender of the potential attack. Section 8 provides more details on the security considerations for ForCES.
セキュリティ握手が、どんなさらなる交換処理も起こることができる前に2つのコミュニケーション終点を互いに認証するのに必要です。 セキュリティ握手はCEとFEの間の互いの認証と認可を含むべきですが、正確な詳細はForCESプロトコルによって選ばれたセキュリティ解決策によります。 認可はプレ協会段階の間にFEかCEマネージャによって提供された認可されたエンドポイントのリストに対してチェックするのと同じくらい簡単であることができます。 協会を設立できる前に認証と認可の両方がうまくいっているに違いありません。 認証か認可のどちらかが失敗するなら、エンドポイントにNEを接合させてはいけません。 うまくいっているセキュリティ握手の後に、通報認証と秘密性がまだCEとFEの間の継続している情報交換に必要です、何らかのフォームの物理的なセキュリティが存在していない場合。 パケットが認証に失敗するときはいつも、それを落とさなければなりません、そして、起こり得るかもしれない攻撃の送付者を警告するために通知を送るかもしれません。 セクション8はセキュリティ問題に関するその他の詳細をForCESに供給します。
After the successful security handshake, the FE needs to inform the CE of its own capability and optionally its topology in relation to other FEs. The capability of the FE shall be represented by the FE model, as required in [4] (Section 6, requirement #1). The model would allow an FE to describe what kind of packet processing functions it contains, in what order the processing happens, what kinds of configurable parameters it allows, what statistics it collects, and what events it might throw, etc. Once such information is available to the CE, the CE may choose to send some initial or default configuration to the FE so that the FE can start receiving and processing packets correctly. Such initialization may not be necessary if the FE already obtains the information from its own bootstrap process. Once the necessary initial information is exchanged, the process of association is completed. Packet processing and forwarding at the FE cannot begin until association is established. After the association is established, the CE and FE enter steady-state communication.
うまくいっているセキュリティ握手の後に、FEは、それ自身の能力について任意にCEに知らせる必要があります。他のFEsと関連したそのトポロジー。 FEの能力は必要に応じて[4](セクション6、要件#1)にFEモデルによって表されるものとします。 モデルはそれがどういうパケット処理機能を含んでいるか、そして、処理が注文されることで起こって、どんな種類の構成可能なパラメタを許容するか、そして、どんな統計を集めるか、そして、どんな出来事を開くかもしれないかを説明するFEなどを許容するでしょう。 そのような情報がいったんCEに利用可能になると、CEは、FEが正しく受信と処理パケットを始めることができるように何らかの初期かデフォルト構成をFEに送るのを選ぶかもしれません。 FEがそれ自身の摘み皮の過程から情報を既に得るなら、そのような初期化は必要でないかもしれません。 いったん必要な初期の情報を交換すると、協会の過程は完了しています。 協会が設立されるまで、FEでのパケット処理と推進は始まることができません。 協会が設立された後に、CEとFEは定常状態コミュニケーションを入力します。
4.2.3. Steady-state Communication
4.2.3. 定常状態コミュニケーション
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プロトコルはCEによって使用されます、そして、Fp参照の上のFEはパケット処理を容易にするために交換情報を示します。
Yang, et al. Informational [Page 19] RFC 3746 ForCES Framework April 2004
陽、他 情報[19ページ]のRFC3746は枠組みの2004年4月を強制します。
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|<----------------------|
| |
FE Ce| | |(これらの新しいルートを加えてください。)| 1| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(うまくいっている。) | 2|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| |(いくつかの統計について質問してください。) | 1| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(統計が集められている状態で、返答してください。) 2|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| |(私のポートはポート#で下がっています。) 1|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(ここに、新しい推進テーブルがあります) 2| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 10. Examples of a message exchange between CE and FE
over Fp during steady-state communication
図10。 定常状態コミュニケーションの間のFpの上のCEとFEの間の交換処理に関する例
Based on the information acquired through CEs' control processing, CEs will frequently need to manipulate the packet-forwarding behaviors of their FE(s) by sending instructions to FEs. For example, Figure 10 shows message exchange examples in which the CE sends new routes to the FE so that the FE can add them to its forwarding table. The CE may query the FE for statistics collected by the FE and the FE may notify the CE of important events such as port failure.
CEsのコントロール処理で取得された情報に基づいて、CEsは、頻繁に指示をFEsに送ることによってそれらのFE(s)のパケットを進める振舞いを操る必要があるでしょう。 例えば、図10はFEが推進テーブルにそれらを加えることができるようにCEが新しいルートをFEに送る交換処理の例を示しています。 CEはFEによって集められた統計のためにFEについて質問するかもしれません、そして、FEはポートの故障などの重大事件についてCEに通知するかもしれません。
Yang, et al. Informational [Page 20] RFC 3746 ForCES Framework April 2004
陽、他 情報[20ページ]のRFC3746は枠組みの2004年4月を強制します。
4.2.4. Data Packets across Fp reference point
4.2.4. Fp参照ポイントの向こう側のデータPackets
--------------------- ----------------------
| | | |
| +--------+ | | +--------+ |
| |CE(BGP) | | | |CE(BGP) | |
| +--------+ | | +--------+ |
| | | | ^ |
| |Fp | | |Fp |
| v | | | |
| +--------+ | | +--------+ |
| | FE | | | | FE | |
| +--------+ | | +--------+ |
| | | | ^ |
| Router | | | Router | |
| A | | | B | |
---------+----------- -----------+----------
v ^
| |
| |
------------------->---------------
--------------------- ---------------------- | | | | | +--------+ | | +--------+ | | |Ce(BGP)| | | |Ce(BGP)| | | +--------+ | | +--------+ | | | | | ^ | | |fp| | |fp| | v| | | | | +--------+ | | +--------+ | | | FE| | | | FE| | | +--------+ | | +--------+ | | | | | ^ | | ルータ| | | ルータ| | | A| | | B| | ---------+----------- -----------+---------- ^に対して| | | | ------------------->、-、-、-、-、-、-、-、-、-、-、-、-、-、--
Figure 11. Example to show data packet flow between two NEs.
図11。 2NEsの間のデータ・パケット流動を示している例。
Control plane protocol packets (such as RIP, OSPF messages) addressed to any of NE's interfaces are typically redirected by the receiving FE to its CE, and CE may originate packets and have its FE deliver them to other NEs. Therefore, the ForCES Protocol over Fp not only transports the ForCES Protocol messages between CEs and FEs, but also encapsulates the data packets from control plane protocols. Moreover, one FE may be controlled by multiple CEs for distributed control. In this configuration, the control protocols supported by the FORCES NEs may spread across multiple CEs. For example, one CE may support routing protocols like OSPF and BGP, while a signaling and admission control protocol like RSVP is supported in another CE. FEs are configured to recognize and filter these protocol packets and forward them to the corresponding CE.
NEのインタフェースのいずれにも記述されたコントロール飛行機プロトコルパケット(リップ、OSPFメッセージなどの)が受信FEによってCEに通常向け直されて、CEはFEにパケットを溯源して、他のNEsにそれらを渡させるかもしれません。 したがって、Fpの上のForCESプロトコルはCEsとFEsの間でForCESプロトコルメッセージを輸送するだけではなく、規制飛行機プロトコルからデータ・パケットをカプセルに入れりもします。 そのうえ、1FEが分散制御のために複数のCEsによって制御されるかもしれません。 この構成では、FORCES NEsによってサポートされた制御プロトコルは複数のCEsの向こう側に広まるかもしれません。 例えば、1CEがOSPFとBGPのようなルーティング・プロトコルをサポートするかもしれません、RSVPが別のCEで支持されるようにシグナリングと入場コントロールは議定書を作りますが。 FEsは、これらのプロトコルパケットと前進の彼らを対応するCEに認識して、フィルターにかけるために構成されます。
Figure 11 shows one example of how the BGP packets originated by router A are passed to router B. In this example, the ForCES Protocol is used to transport the packets from the CE to the FE inside router A, and then from the FE to the CE inside router B. In light of the fact that the ForCES Protocol is responsible for transporting both the control messages and the data packets between the CE and FE over the Fp reference point, it is possible to use either a single protocol or multiple protocols.
図11は、ルータAによって溯源されたBGPパケットがどうこの例、ルータB.In ForCESプロトコルに通過されるかに関する1つの例がForCESプロトコルがFp基準点の上でCEとFEの間のコントロールメッセージとデータ・パケットの両方を輸送するのに原因となるという事実のルータB.In光の中でCEからFEまでパケットをルータAと、そして、FEからCEまで輸送するのに使用されるのを示して、ただ一つのプロトコルか複数のプロトコルのどちらかを使用するのは可能です。
Yang, et al. Informational [Page 21] RFC 3746 ForCES Framework April 2004
陽、他 情報[21ページ]のRFC3746は枠組みの2004年4月を強制します。
4.2.5. Proxy FE
4.2.5. プロキシFE
In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES Protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. This allows the CE to communicate to the physical FE via the proxy by using ForCES, while the proxy manipulates the physical FE using some intermediary form of communication (e.g., a non-ForCES protocol or DMA). In such an implementation, the combination of the proxy and the physical FE becomes one logical FE entity. It is also possible for one proxy to act on behalf of multiple physical FEs.
物理的なFEが直接ForCESプロトコルを実行できない(例えば、汎用のCPUの不足のため)場合では、物理的なFEの代わりにFp基準点を終えるのにプロキシFEを使用できます。 これで、CEはプロキシを通ってForCESを使用することによって、物理的なFEに交信できます、プロキシが何らかの仲介者フォームに関するコミュニケーション(例えば、非ForCESプロトコルかDMA)を使用することで物理的なFEを操作しますが。 そのような実現では、プロキシと物理的なFEの組み合わせは1つの論理的なFE実体になります。 また、1つのプロキシが複数の物理的なFEsを代表して行動するのも、可能です。
One needs to be aware of the security implication introduced by the proxy FE. Since the physical FE is not capable of implementing ForCES itself, the security mechanism of ForCES can only secure the communication channel between the CE and the proxy FE, but not all the way to the physical FE. It is recommended that other security mechanisms (including physical security property) be employed to ensure the security between the CE and the physical FE.
人は、プロキシFEによって紹介されたセキュリティ含意を意識している必要があります。 物理的なFEがForCES自身を実行できないので、ForCESのセキュリティー対策は、CEとプロキシFEの間に通信チャネルを保証しますが、物理的なFEまでのいっぱいに保証できるだけではありません。 他のセキュリティー対策(物理的なセキュリティ性質を含んでいる)がCEと物理的なFEの間のセキュリティを確実にするのに使われるのは、お勧めです。
4.3. Association Re-establishment
4.3. 協会再建
FEs and CEs may join and leave NEs dynamically (see [4] Section 5, requirements #12). When an FE or CE leaves the NE, the association with the NE is broken. If the leaving party rejoins an NE later, to re-establish the association, it may need to re-enter the pre- association phase. Loss of association can also happen unexpectedly due to a loss of connection between the CE and the FE. Therefore, the framework allows the bi-directional transition between these two phases, but the ForCES Protocol is only applicable for the post- association phase. However, the protocol should provide mechanisms to support association re-establishment. This includes the ability for CEs and FEs to determine when there is a loss of association between them, and to restore association and efficient state (re)synchronization mechanisms (see [4] Section 5, requirement #7). Note that security association and state must also be re-established to guarantee the same level of security (including both authentication and authorization) exists before and after the association re-establishment.
FEsとCEsはダイナミックにNEsを接合して、残すかもしれません([4] セクション5、要件#12を見てください)。 FEかCEがNEを残すとき、NEとの協会は壊れています。 退出パーティーが後で協会を復職させるためにNEに再び加わるなら、それは、プレ協会フェーズに再入する必要があるかもしれません。 また、協会の損失はCEとFEとの接続の損失のため不意に起こることができます。 したがって、枠組みはこれらの二相の間の双方向の変遷を許容しますが、ポスト協会フェーズだけに、ForCESプロトコルは適切です。 しかしながら、プロトコルは、協会再建を支持するためにメカニズムを提供するべきです。 これはCEsとFEsが、いつ、彼らの間の協会の損失があるかを決定して、協会と効率的な州(re)の同期メカニズムを返す能力を含んでいます([4] セクション5、要件#7を見てください)。 また、(認証と認可の両方を含んでいます)が協会再建の前後に存在するのを同じレベルのセキュリティに保証するためにセキュリティ協会と状態を復職させなければならないことに注意してください。
When an FE leaves or joins an existing NE that is already in operation, the CE needs to be aware of the impact on FE topology and deal with the change accordingly.
FEがいなくなるか、または既に稼働中である既存のNEを接合するとき、CEはFEトポロジーへの影響を意識していて、それに従って、変化に対処する必要があります。
Yang, et al. Informational [Page 22] RFC 3746 ForCES Framework April 2004
陽、他 情報[22ページ]のRFC3746は枠組みの2004年4月を強制します。
4.3.1. CE graceful restart
4.3.1. CEの優雅な再開
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])とMPLSラベル分配は議定書を作ります。「優雅な再開」として知られている高可用性メカニズムがIPルーティング・プロトコルによって使用された、(OSPF[11]、BGP[12]、-、(再開ルータによって引き起こされた全体のネットワーク中でルーティングへのマイナスの効果を最小にするのを助ける自由民主党[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.
詳細は議定書の中で述べるプロトコルと異なっていますが、優雅な再開メカニズムの後ろの概念は同じままで残っています。 優雅な再開で、再開ルータは、それがいつ再開するかを隣人に知らせることができます。 隣人は、無くなっている隣接番組を検出しますが、どんなrecomputeにも新しいルートをしないか、またはルーティングアップデートを彼らの隣人に送るかもしれません。 隣人は、また、再開の前に再開ルータから受け取られたルートにしっかりつかまって、それらが限られた時間まだ有効であると仮定します。 また、そうすることによって、再開ルータのFEsは限られた時間他の隣人からそれらが既に持っているルートを使用することによって交通を受けて、進め続けることができます。 再開ルータは、次に、ルーティング隣接番組を復職させて、すべての隣人からのアップデートされたルート、recomputesの新しいルートをダウンロードして、それが使用していたより古いルートを置き換えるのにそれらを使用します。 次に、それは、隣人へのアップデートされたルートをこれらに送って、優雅な再開の過程の完成を信号に送ります。
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
ノンストップ推進は優雅な再開のための要件です。 したがって、ルータが、ルーティング情報をダウンロードして、新しいルートを再計算している間、パケットを進め続けることができるのが必要です。 これは、パケットが落とされないのを確実にします。 人が見ることができるように、CEとFEの分離で都合された利益の1つはまさに見ます。
Yang, et al. Informational [Page 23] RFC 3746 ForCES Framework April 2004
陽、他 情報[23ページ]のRFC3746は枠組みの2004年4月を強制します。
ability of non-stop forwarding in the face of the CE failure and restart. The support of dynamic changes to CE/FE association in ForCES also makes it compatible with high availability mechanisms, such as graceful restart.
CEの故障と再開に直面してノンストップ推進の能力。 また、ForCESの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.
ForCESは容易にCEの優雅な再開を支持するはずであることができます。 協会が1回目に設立されるとき、CEは、CEの故障の場合で何をするかをFEsに知らせなければなりません。 優雅な再開が支持されないなら、FEsが、CEが失敗するならパケットが一斉に処理されるのを止めるように言われるかもしれません。 優雅な再開が支持されるなら、FE状態をキャッシュして、FEsがしっかりつかまるように言われるべきです、再開の向こう側に推進テーブルを含んでいて。 タイマを含まなければならないので、そのようなキャッシュされた状態は結局、タイムアウトで期限が切れます。 それらのタイマはCEで「舗装用敷石-可能」であるはずです。
4.3.2. FE restart
4.3.2. FE再開
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であると仮定して、FE1は、FEsの1つであるなら起こることが一時NEを残すと言いますか? FE1は、協会を出ると自発的に決めるかもしれません。 あるいはまた、FE1は、単に予期していなかった失敗のため機能するのを止めるかもしれません。 前の場合では、CE1はFE1から「協会を出ている要求」を受けます。 後者では、CE1はある他の手段でFE1の失敗を検出します。 どちらの場合も、CE1はそのような出来事のルーティング・プロトコルを知らせなければなりません、たぶんFEs(この例の唯一のFE2)のままで残っている新しいFIBsのCE1からもう片方までの可到達性とSPF(最も短いPath First)再計算と関連ダウンロードをうながして。 また、そのような再計算と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
FE1が、再び再び加わると決めるか、または失敗の後に再び再開すると、FE1は、マスター(CE)を再発見する必要があります。 いくつかの手段でこれを達成できます。 それは、プレ協会フェーズに再入して、FEマネージャからその情報を得るかもしれません。 情報の新しさを有効にすることができるなら、それはキャッシュからの前のCE情報を検索するかもしれません。 いったんCEを発見する後、協会を復職させるためにCEから交換処理を始めます、図9に概説されているようにそれがそうするかもしれない可能な例外で完全な初期の構成の輸送を迂回させることができてください。 FE1には前回の協会からのその経路指定テーブルと他の州の情報がまだあると仮定してください。 すべての情報を再送することの代わりに、CEと共に状態を再同期させるのにより効率的なメカニズムを使用できるかもしれません、そのようなメカニズムがForCESプロトコルによってサポートされるなら。 例えば、状態のCRC-32は状態がCEと共に同時性であるかどうかにおける迅速な指示を与えるかもしれません。 最初にCEと状態を比べることによって、それは情報最新版を送ります。
Yang, et al. Informational [Page 24] RFC 3746 ForCES Framework April 2004
陽、他 情報[24ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
それが必要である場合にだけ。 ForCESプロトコルは、同様の最適化メカニズムを実行するのを選ぶかもしれませんが、また、選ばないのを選ぶかもしれません、これが要件でないので。
5. Applicability to RFC 1812
5. RFC1812への適用性
[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] 「どんな提案されたForCES構造でもRFC1812で定義されて、その構造がどうルータ機能のすべてを支持するかがわからなければならない」セクション5、要件#9命令。 RFC1812[2]はリンクレイヤから応用層までIPv4ルータのための多くの重要な要件について議論します。 このセクションは、ForCES構造に基づくIPv4ルータを実行するためにRFC1812に関連要件を記述して、どう推進飛行機と制御飛行機に必要である機能性を切り離すかに関するガイドラインを提供することによって、ForCESがどうこれらの要件を満たすかを説明します。
In general, the forwarding plane carries out the bulk of the per- packet processing that is required at line speed, while the control plane carries most of the computationally complex operations that are typical of the control and signaling protocols. However, it is impossible to draw a rigid line to divide the processing into CEs and FEs cleanly and the ForCES architecture should not limit the innovative approaches in control and forwarding plane separation. As more and more processing power is available in the FEs, some of the control functions that traditionally are performed by CEs may now be moved to FEs for better performance and scalability. Such offloaded functions may include part of ICMP or TCP processing, or part of routing protocols. Once off-loaded onto the forwarding plane, such CE functions, even though logically belonging to the control plane, now become part of the FE functions. Just like the other logical functions performed by FEs, such off-loaded functions must be expressed as part of the FE model so that the CEs can decide how to best take advantage of these off-loaded functions when present on the FEs.
一般に、推進飛行機が嵩から運ぶ、-、パケット処理がライン・スピードで必要です、制御飛行機はコントロールとシグナリングプロトコルの典型である計算上複雑な操作の大部分を乗せますが。 しかしながら、清潔に処理をCEsとFEsに分割するために堅い線を描くのが不可能であり、ForCES構造はコントロールと修正面分離を進めるのが革新的なアプローチを制限するべきではありません。 ますます多くの処理能力がFEsで利用可能であるときに、CEsによって伝統的に実行されるコントロール機能のいくつかが今、より良い性能とスケーラビリティのためにFEsに動かされるかもしれません。 そのような積み下ろされた機能はICMPかTCP処理の一部、またはルーティング・プロトコルの一部を含むかもしれません。 一度推進飛行機へ積み下ろされます、制御飛行機に論理的に属しますが、現在、そのようなCE機能はFE機能の一部になります。 他の論理関数がまさしくFEsで働いたように、CEsがFEsに存在しているとき、これらの積み下ろされた機能を最もよく利用する方法を決めることができるように、FEモデルの一部としてそのような積み下ろされた機能を言い表さなければなりません。
5.1. General Router Requirements
5.1. 一般ルータ要件
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つ以上の論理的なインタフェースがあります。 CEsとFEsが独身のNEの中でForCESによって切り離されるとき、いくつかの追加インタフェースがイントラ-NEコミュニケーションに必要であり、12は例証されるように中で計算します。 このNEは1CEと2FEsを含んでいます。 各FEには、4つのインタフェースがあります。 それらの2つはパケットを外界に受けて、送るのに使用されます、他の2はイントラ-NE接続のためのものですが。 CEには、FE1とFE2からインタフェース#3、と#6にそれぞれ接続された2つの論理的なインタフェース#9、と#10があります。 インタフェース#4、と#5、はFE1-FE2コミュニケーションのために接続されます。 したがって、このルータNEは4つの外部のインタフェース(#1、2、7、および8)を提供します。
Yang, et al. Informational [Page 25] RFC 3746 ForCES Framework April 2004
陽、他 情報[25ページ]のRFC3746は枠組みの2004年4月を強制します。
---------------------------------
| router NE |
| ----------- ----------- |
| | FE1 | | FE2 | |
| ----------- ----------- |
| 1| 2| 3| 4| 5| 6| 7| 8| |
| | | | | | | | | |
| | | | +----+ | | | |
| | | | | | | |
| | | 9| 10| | | |
| | | -------------- | | |
| | | | CE | | | |
| | | -------------- | | |
| | | | | |
-----+--+----------------+--+----
| | | |
| | | |
--------------------------------- | ルータ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ルータは、パケット推進機能(推進Information基地)をサポートするためにIPを実行しなければなりません。(機能はFIBによって追い立てられます)。 自然に機能性を転送する(RFC1812[2]部5を見ます)このインターネット層がForCES構造でFEsに属します。
A router may implement transport layer protocols (like TCP and UDP) that are required to support application layer protocols (see RFC 1812 [2] Section 6). One important class of application protocols is routing protocols (see RFC 1812 [2] Section 7). In the ForCES architecture, routing protocols are naturally implemented by CEs. Routing protocols require that routers communicate with each other. This communication between CEs in different routers is supported in ForCES by FEs' ability to redirect data packets addressed to routers (i.e., NEs), and the CEs' ability to originate packets and have them delivered by their FEs. This communication occurs across the Fp reference point inside each router and between neighboring routers' external interfaces, as illustrated in Figure 11.
ルータは応用層プロトコルをサポートするのに必要であるトランスポート層プロトコル(TCPとUDPのような)を実行するかもしれません(RFC1812[2]部6を見てください)。 1つの重要なクラスのアプリケーション・プロトコルはルーティング・プロトコル(RFC1812[2]部7を見る)です。 ForCES構造では、ルーティング・プロトコルはCEsによって自然に実行されます。 ルーティング・プロトコルは、ルータが互いにコミュニケートするのを必要とします。 異なったルータにおけるCEsのこのコミュニケーションはForCESでルータ(すなわち、NEs)に記述されたデータ・パケットを向け直すFEsの性能、およびパケットを溯源して、それらのFEsにそれらを渡させるCEsの性能によって支持されます。 このコミュニケーションは各ルータと隣接しているルータの外部のインタフェースの間のFp基準点の向こう側に現れます、図11で例証されるように。
5.2. Link Layer
5.2. リンクレイヤ
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
FEsがルータのためのすべての外部のインタフェースを所有しているので、FEsは、RFC1812[2]のリンクレイヤ要件に従う必要があります。 論証上、ARPサポートはCEsかFEsのどちらかで実行されるかもしれません。 私たちが後で見るように、RFC1812が強制する多くの振舞いがこのカテゴリになります--それらは、FEによって実行されて、CEによって実行されるかもしれません。 一般的ガイドラインが、切り離されたコントロールと推進飛行機の間の相互運用性を確実にするのに必要です。 私たちがここに提供するガイドラインはCEsがこれらの種類の操作ができなければならないということです。
Yang, et al. Informational [Page 26] RFC 3746 ForCES Framework April 2004
陽、他 情報[26ページ]のRFC3746は枠組みの2004年4月を強制します。
while FEs MAY choose to implement them. The FE model should indicate its capabilities in this regard so that CEs can decide where these functions are implemented.
FEsは、彼らを実行するのを選ぶかもしれませんが。 FEモデルは、この点でCEsが、これらの機能がどこで実行されるかを決めることができるように、能力を示すべきです。
Interface parameters, including MTU, IP address, etc., must be configurable by CEs via ForCES. CEs must be able to determine whether a physical interface in an FE is available to send packets or not. FEs must also inform CEs of the status change of the interfaces (like link up/down) via ForCES.
MTU、IPアドレスなどを含むインタフェース・パラメータはCEsがForCESを通して構成可能であるに違いありません。 CEsは、FEの物理インターフェースがパケットを送るために利用可能であるかどうか決定できなければなりません。 また、FEsはForCESを通してインタフェース(/へのリンクのように、ダウンする)の状態変化についてCEsに知らせなければなりません。
5.3. Internet Layer Protocols
5.3. インターネット層のプロトコル
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.
RFC1812が指定したようにFEsとCEsの両方がIPプロトコルとすべての義務的な拡大を実行しなければなりません。 FEsが、また、それらを実行するのを選んでいるかもしれない間、CEsは送信元経路と記録的なルートのようなIPオプションを実行するはずです。 タイムスタンプオプションは、最も正確にタイムスタンプを挿入するためにFEsによって実行されるはずです。 FEはそれが理解しているIPオプションを解釈して、CEsによる使用に、変わりのない残りを保存しなければなりません。 FEsとCEsの両方が、送付ICMP誤りなしでパケットを静かに捨てるのを選ぶかもしれませんが、そのような出来事は、登録されて、数えられるべきです。 FEsはそのような出来事のためにForCESを通して統計をCEsに報告するかもしれません。
When multiple FEs are involved to process packets, the appearance of a single NE must be strictly maintained. For example, Time-To-Live (TTL) must be decremented only once within a single NE. For example, it can be always decremented by the last FE with egress function.
複数のFEsがパケットを処理するためにかかわるとき、厳密に独身のNEの外観を維持しなければなりません。 例えば、生きるTime(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.
通常、FEsはブロードキャストあて先アドレスかルータが受け取るように頼んだマルチキャスト送付先アドレスでどんなパケットも受けて、処理しなければなりません。 IPマルチキャストがルータで支持されるとき、IGMPはCEsで実行されます。 また、ICMPサポートはCEsに要求されますが、FEsがICMPを支持するのは、任意です。 FEモデルの一部としてそのようなオプションをCEsに伝えることができます。 したがって、FEsはICMPエラーメッセージを出すためにいつもCEsを当てにすることができますが、FEsには、また、ICMPエラーメッセージ自体を発生させるオプションがあります。
5.4. Internet Layer Forwarding
5.4. インターネット層の推進
IP forwarding is implemented by FEs. When the routing table is updated at the CEs, ForCES is used to send the new route entries from the CEs to FEs. Each FE has its own forwarding table and uses this table to direct packets to the next hop interface.
IP推進はFEsによって実行されます。 CEsで経路指定テーブルをアップデートするとき、CEsからFEsまでの新しいルートエントリーを送るのにForCESを使用します。 各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
IPパケットを受けると、FEはIPヘッダーについて確かめて、IPオプションの大部分を処理します。 ルーティング決定をするまでいくつかのオプションを処理できません。 送付先IPアドレスを調べた後に、ルーティング決定をします。 目的地です。
Yang, et al. Informational [Page 27] RFC 3746 ForCES Framework April 2004
陽、他 情報[27ページ]のRFC3746は枠組みの2004年4月を強制します。
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.
アドレスがルータ自体に属して、パケットをフィルターにかけて、局所的に処理するか、またはCEに送ります、CEによる指示セットアップによって。 さもなければ、FEは、推進テーブルの中を見ることによって、次のホップIPアドレスを決定します。 また、FEは、それが使用するネットワーク・インターフェースがパケットを送ることを決定します。 時々、FEは、次のホップへの外にパケットを送ることができる前に別のFEにパケットを送る必要があるかもしれません。 次のホップへの外にパケットを送るまさしく前に、FEはTTLを1つ減少させて、以前処理できなかった少しのIPオプションも処理します。 FEは必要なら、IP断片化を実行して、リンクレイヤアドレス(例えば、ARPによる)を決定して、適切なリンクレイヤフレームでIPデータグラム(または、それのそれぞれの断片)を要約して、出力のために選択されたインタフェースにそれを列に並ばせます。
Other options mentioned in RFC 1812 [2] for IP forwarding may also be implemented at FEs, for example, packet filtering.
また、IP推進のためのRFC1812[2]で言及された別の選択肢はFEs、例えば、パケットフィルタリングで実行されるかもしれません。
FEs typically forward packets destined locally to CEs. FEs may also forward exceptional packets (packets that FEs do not know how to handle) to CEs. CEs are required to handle packets forwarded by FEs for whatever reason. It might be necessary for ForCES to attach some meta-data with the packets to indicate the reasons of forwarding from FEs to CEs. Upon receiving packets with meta-data from FEs, CEs can decide to either process the packets themselves, or pass the packets to the upper layer protocols including routing and management protocols. If CEs are to process the packets by themselves, CEs may choose to discard the packets, or modify and re-send the packets. CEs may also originate new packets and deliver them to FEs for further forwarding.
FEsは局所的にCEsに運命づけられたパケットを通常進めます。 また、FEsは例外的なパケット(FEsが、どのようにが扱うかを知らないパケット)をCEsに送るかもしれません。 CEsはいかなる理由でもFEsによって進められたパケットを扱わなければなりません。 ForCESがFEsからCEsまでの推進の理由を示すためにパケットで何らかのメタデータを添付するのが必要であるかもしれません。 メタデータでFEsからパケットを受けると、CEsは、ルーティングと管理プロトコルを含む上側の層のプロトコルにパケット自体を処理するか、またはパケットを通過すると決めることができます。 CEsが自分たちでパケットを処理するつもりであるなら、CEsが、パケットを捨てるのを選ぶかもしれないか、パケットを変更して、再送してください。 CEsはまた、新しいパケットを溯源して、さらなる推進のためにそれらをFEsに渡すかもしれません。
Any state change during router operation must also be handled correctly according to RFC 1812. For example, when an FE ceases forwarding, the entire NE may continue forwarding packets, but it needs to stop advertising routes that are affected by the failed FE.
また、RFC1812によると、正しくルータ操作の間のどんな州の変化も扱わなければなりません。 FEが、進めるのをやめるとき、例えば、全体のNEは、パケットを進め続けるかもしれませんが、それは、失敗したFEで影響を受けるルートの広告を出すのを止める必要があります。
5.5. Transport Layer
5.5. トランスポート層
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).
Transport層は、プロトコルを発送するような、より高い層のアプリケーション・プロトコルをサポートするためにCEsで通常実行されます。 実際には、これは、ほとんどのCEsが通信制御プロトコル(TCP)とユーザー・データグラム・プロトコル(UDP)の両方を実行することを意味します。
Both CEs and FEs need to implement the ForCES Protocol. If some layer-4 transport is used to support ForCES, then both CEs and FEs need to implement the L4 transport and ForCES Protocols.
CEsとFEsの両方が、ForCESプロトコルを実行する必要があります。 何らかの層-4輸送がForCESを支持するのに使用されるなら、CEsとFEsの両方が、L4輸送とForCESプロトコルを実行する必要があります。
Yang, et al. Informational [Page 28] RFC 3746 ForCES Framework April 2004
陽、他 情報[28ページ]のRFC3746は枠組みの2004年4月を強制します。
5.6. Application Layer -- Routing Protocols
5.6. 応用層--ルーティング・プロトコル
Interior and exterior routing protocols are implemented on CEs. The routing packets originated by CEs are forwarded to FEs for delivery. The results of such protocols (like forwarding table updates) are communicated to FEs via ForCES.
内部の、そして、外のルーティング・プロトコルはCEsで実行されます。 配送のためにCEsによって溯源されたルーティングパケットをFEsに送ります。 そのようなプロトコル(テーブルアップデートを進めるような)の結果はForCESを通してFEsに伝えられます。
For performance or scalability reasons, portions of the control plane functions that need faster response may be moved from the CEs and off-loaded onto the FEs. For example, in OSPF, the Hello protocol packets are generated and processed periodically. When done at the CEs, the inbound Hello packets have to traverse from the external interfaces at the FEs to the CEs via the internal CE-FE channel. Similarly, the outbound Hello packets have to go from the CEs to the FEs and to the external interfaces. Frequent Hello updates place heavy processing overhead on the CEs and can overwhelm the CE-FE channel as well. Since typically there are far more FEs than CEs in a router, the off-loaded Hello packets are processed in a much more distributed and scalable fashion. By expressing such off-loaded functions in the FE model, we can ensure interoperability. However, the exact description of the off-loaded functionality corresponding to the off-loaded functions expressed in the FE model are not part of the model itself and will need to be worked out as a separate specification.
性能かスケーラビリティ理由で、より速い応答を必要とするコントロール飛行機機能の部分は、CEsから動かされて、FEsへ積み下ろされるかもしれません。 例えば、OSPFでは、Helloプロトコルパケットは、定期的に発生して、処理されます。 CEsにすると、本国行きのHelloパケットはFEsの外部のインタフェースから内部のCE-FEチャンネルを通したCEsまでの横断にしました。 同様に、外国行きのHelloパケットはCEsからFEsまで外部のインタフェースまで行かなければなりません。 頻繁なHelloアップデートは、重い処理オーバヘッドをCEsに置いて、また、CE-FEチャンネルを圧倒できます。 ルータにはCEsよりはるかに多くのFEsが通常あるので、積み下ろされたHelloパケットははるかに分配されてスケーラブルなファッションで処理されます。 FEモデルでのそのような積み下ろされた機能を言い表すことによって、私たちは相互運用性を確実にすることができます。 しかしながら、FEモデルで言い表された積み下ろされた機能に対応する積み下ろされた機能性の正確な記述は、モデル自体の一部でなく、別々の仕様として解決される必要があるでしょう。
5.7. Application Layer -- Network Management Protocol
5.7. 応用層--ネットワーク管理プロトコル
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.
また、RFC1812[2]は、「ルータはSNMPは処理しやすいに違いありません。」と決めます。 一般に、ポスト協会フェーズにおいて、ほとんどの外部の管理タスク(SNMPを含んでいる)が、単一の機能素子の外観をサポートするためにCEとの相互作用で果たされるべきです。 したがって、SNMPエージェントがCEsによって実装されて、FEsによって受け取られたSNMPメッセージが彼らのCEsに向け直されるのは、お勧めです。 RFC2741([6])で定義されたAgentXフレームワークは、CEsがFEsがFEsに住んでいるMIBオブジェクトへのアクセスを提供するために副代理店の役割で行動している間、SNMPプロトコルメッセージを処理するためにマスターエージェントの役割で行動するように、ここに適用されるかもしれません。 マスターエージェント(CE)と副代理店(FE)の間のAgentXプロトコルメッセージは、ForCESを通してカプセル化されて、輸送されます、いかなる他のアプリケーションからのデータ・パケットもまさしくプロトコルを層にするように。
6. Summary
6. 概要
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
このドキュメントはForCESのために建築フレームワークを定義します。 それはForCESネットワーク要素のために関連コンポーネントを特定します、FEs、(1以上)CEs、1人の任意のFEマネージャ、および1人の任意のCEマネージャを含んでいて(1以上)。 それは、また、これらのコンポーネントの中で相互作用を特定して、すべての少佐について議論します。
Yang, et al. Informational [Page 29] RFC 3746 ForCES Framework April 2004
陽、他 情報[29ページ]のRFC3746はフレームワーク2004年4月を強制します。
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.
参照は示されます。 ForCESの範囲の中にすべての基準点の中にCEsとFEsとのFpインタフェースしかないと指摘するのは重要です。 ForCESだけが、すべての望ましいNE構成をサポートするために十分でないかもしれません。 しかしながら、私たちは、Fpインタフェースの上のForCESがCEsとFEsの物理的分離と相互運用性を換金して、したがって、標準化されるべきである最初のインタフェースを換金するのにおいて最も重要な要素であると信じています。 標準化されるCE-FEインタフェース、例えば、いっぱいにかみ合っているFEsと独身のCEだけと共に簡単で役に立つ構成をまだ実装することができます。
7. Acknowledgements
7. 承認
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。 Sridharは、ForCESネットワーク要素を管理するのにSNMPと共にAgentXプロトコルを使用できるのを示しました。 スーザンHaresはForCESとの優雅な再開の問題を指摘しました。 また、ラスHousley、Avriドーリア、ジャマル・ハディ・サリム、およびForCESメーリングリストの多くの他のものが有益なフィードバックを提供しました。
8. Security Considerations
8. セキュリティ問題
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管理者には、特定の展開に必要である正確なセキュリティ設定を決定する自由があります。 例えば、ForCESはバックプレーンの上の箱の中に互いに接続されたCEsとFEsの間で配布されるかもしれません。 そのようなシナリオでは、箱の物理的なセキュリティは、攻撃の大部分、男性などのように、中央です、詮索、およびものまねが可能でなく、したがって、ForCESアーキテクチャがこれらの攻撃に対して防御するために箱の物理的なセキュリティを当てにするかもしれないのを確実にします、そして、プロトコルメカニズムはオフにされるかもしれません。 しかしながら、また、示されて、外部のそれでも、そのようなものさえのための潜在的な脅威が「オールインワンの箱」であるという.8展開シナリオがセクション8.1で以下で説明されて、したがってメカニズムを制限するレートが説明されるインタフェースを通したサービス攻撃のその否定もまだ必要であるということです。 これは異なった展開シナリオの下でForCESによって可能にされたネットワーク要素の安全要求を評価するのが重要であることを示すちょうど1つの例です。 管理者が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
一般に、通常、2つの実体の物理的分離は2つの実体の間の潜在的に不安定なリンクをもたらします、そして、したがって、はるかに厳しいセキュリティ測定が必要です。 例えば、私たちは、セクション4.1で認証がCEマネージャとFEマネージャと、CEとCEマネージャと、FEとFEマネージャの間でいくつかの構成で必要になると指摘しました。 また、CEとFEの物理的分離はFpインタフェースの上のForCESプロトコルのための重大なセキュリティ要件を課します。 このセクションは、最初に、それが軍事的脅威であるかもしれないのについて説明するのを試みます。
Yang, et al. Informational [Page 30] RFC 3746 ForCES Framework April 2004
陽、他 情報[30ページ]のRFC3746はフレームワーク2004年4月を強制します。
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.
FEsとCEsの物理的分離、および既存の標準のセキュリティソリューションに基づくFpインタフェースの上のForCESプロトコルの安全な操作と管理のための推薦とガイドラインを提供するその時までには、導入します。
8.1. Analysis of Potential Threats Introduced by ForCES
8.1. 力によって導入された潜在的な脅威の分析
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に供給します。 各脅威はForCESプロトコル実体か/と全体でNEへの効果、および脅威を防御するために適所にある必要がある必要な機能性で詳細に説明されます。
8.1.1. "Join" or "Remove" Message Flooding on CEs
8.1.1. CEsにおける「接合してください」か「取り外してください」というメッセージ氾濫
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.
脅威: 非常に急速なレートにおける正統のCEsへの実在しないか権限のないFEと、その結果、CEsに不要な状態を創設することを代表して悪意があるノードは「NEを接合してください」か「NEから、取り外してください」という誤った要求のストリームを送るかもしれません。
Effects: If maintaining state for non-existent or unauthorized FEs, a CE may become unavailable for other processing and hence suffer from a denial of service (DoS) attack similar to the TCP SYN DoS. If multiple CEs are used, the unnecessary state information may also be conveyed to multiple CEs via the Fr interface (e.g., from the active CE to the stand-by CE) and hence subject multiple CEs to a DoS attack.
効果: 実在しないか権限のないFEsのために状態を維持するなら、CEは他の処理を入手できなくなって、したがって、TCP SYN DoSと同様のサービス(DoS)攻撃の否定が欠点であるかもしれません。 また、複数のCEsが使用されているなら、不要な州の情報はDoS攻撃へのフランのインタフェース(例えば、アクティブなCEから予備CEまでの)と複数のしたがって、対象CEsを通して複数のCEsに伝えられるかもしれません。
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は少しの州の情報も作成するはずがありません。
8.1.2. Impersonation Attack
8.1.2. ものまね攻撃
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がそれを受け入れて、処理する前に認可されたForCES要素(プレ協会フェーズにおけるCEかFEマネージャによって提供される)のリストでFEかCEから来たとメッセージを認証しなければなりません。
8.1.3. Replay Attack
8.1.3. 反射攻撃
Threat: A malicious node could replay the entire message previously sent by an FE or CE entity to get around authentication.
脅威: 悪意があるノードは以前にFEかCE実体によって送られた、認証を逃れた全体のメッセージを再演するかもしれません。
Yang, et al. Informational [Page 31] RFC 3746 ForCES Framework April 2004
陽、他 情報[31ページ]のRFC3746はフレームワーク2004年4月を強制します。
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.
要件: 反復操作による保護メカニズムは、この攻撃に対して防御するのにセキュリティソリューションの一部である必要があります。
8.1.4. Attack during Fail Over
8.1.4. フェイルオーバーの間の攻撃
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-AとCE-Bは、CEsが数個のFEsを制御していると言います。 CE-Aはアクティブです、そして、CE-Bは予備です。 CE-Aが失敗すると、CE-BはアクティブなCE職を引き継いでいます。 FEsには、CE-Aとの信じられた関係が既にありましたが、FEsはフェイルオーバーの前のCE-Bと共に同じ信じられた関係を確立させないかもしれません。そのような信じられた関係がフェイルオーバーの前かフェイルオーバー間、確立されていないなら、悪意があるノードはCE-Bとして引き継ぐことができます。
Effect: The NE may be compromised after such insecure fail-over.
効果: 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とFEsの間の信頼のレベルはアクティブなCEとFEsの間のものと同じくらい強いに違いありません。 FEsと予備CEとのセキュリティ協会はフェイルオーバーの前に設立されるかもしれません。そうでなければ、予備CEが引き継ぐ前に既に適所に、そのようなセキュリティ協会を復職させなければなりません。
8.1.5. Data Integrity
8.1.5. データの保全
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.
要件: プロトコルメッセージは保全保護を必要とします。
8.1.6. Data Confidentiality
8.1.6. データの機密性
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の間のデータの機密性は機密情報に利用可能であるに違いありません。
Yang, et al. Informational [Page 32] RFC 3746 ForCES Framework April 2004
陽、他 情報[32ページ]のRFC3746はフレームワーク2004年4月を強制します。
8.1.7. Sharing security parameters
8.1.7. セキュリティパラメタを共有します。
Threat: Consider a scenario where several FEs are communicating to the same CE and sharing the same authentication keys for the Fp interface. If any FE or CE is compromised, all other entities are compromised.
脅威: 数個のFEsが同じCEに交信して、同じ認証キーをFpインタフェースと共有しているシナリオを考えてください。 何かFEやCEが感染されるなら、他のすべての実体が感染されます。
Effect: The whole NE is compromised.
効果: 全体のNEは感染されます。
Recommendation: To avoid this side effect, it's better to configure different security parameters for each FE-CE communication over the Fp interface.
推薦: この副作用を避けるために、Fpインタフェースの上のそれぞれのFE-CEコミュニケーションのための異なったセキュリティパラメタを構成しているほうがよいです。
8.1.8. Denial of Service Attack via External Interface
8.1.8. External Interfaceを通したサービス妨害Attack
Threat: When an FE receives a packet that is destined for its CE, the FE forwards the packet over the Fp interface. A malicious node can generate a huge message storm like routing protocol packets etc. through the external Fi/f interface so that the FE has to process and forward all packets to the CE through the Fp interface.
脅威: FEがCEのために運命づけられているパケットを受けるとき、FEはFpインタフェースの上にパケットを送ります。 悪意があるノードが外部のFi/fインタフェースを通したルーティング・プロトコルパケットなどのような巨大なメッセージ嵐を生成することができるので、FEはFpインタフェースを通してすべてのパケットをCEに処理して、送らなければなりません。
Effect: The CE encounters resource exhaustion and bandwidth starvation on Fp interface due to an overwhelming number of packets from FEs.
効果: CEは圧倒的な数のパケットのためFpインタフェースでFEsからリソース疲労困憊と帯域幅飢餓に遭遇します。
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の両方に適所にあるに違いありません。 Rate Limiter SHOULD、Fi/fインタフェースを通して受け取られるそれぞれのメッセージタイプのためにFEで構成されてください。
8.2. Security Recommendations for ForCES
8.2. 力のためのセキュリティ推薦
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.
ForCESプロトコルが信頼性をサポートするべきであるというドキュメント[4]が示した要件はFpの上で連結しますが、どんな特定のトランスポート・プロトコルもまだForCESに指定されていません。 このフレームワークドキュメントが特定の輸送を指定しないつもりであるので、私たちはForCESに適当な一般的な輸送候補と共に働くことができる標準のセキュリティプロトコル[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 Security)[15]とTLS(輸送Layer Security)[14]を見直します。 TLSはユニキャストのためにTCPかSCTPなどの信頼できる輸送で働いています、IPsecがどんな輸送(UDP、TCP、SCTP)と共にも使用できて、ユニキャストとマルチキャストの両方をサポートしますが。 ForCESプロトコルのためのセキュリティ要件のすべてを満たすのに潜在的にTLSとIPsecの両方を使用できます。 さらに、要件を満たす他のアプローチが、また、使用できますが、ここに記録されません、L2セキュリティー対策の与えられたL2内部連絡技術の使用を含んでいて。
Yang, et al. Informational [Page 33] RFC 3746 ForCES Framework April 2004
陽、他 情報[33ページ]のRFC3746はフレームワーク2004年4月を強制します。
When ForCES is deployed between CEs and FEs inside a box or a physically secured room, authentication, confidentiality, and integrity may be provided by the physical security of the box. Thus, the security mechanisms may be turned off, depending on the networking topology and its administration policy. However, it is important to realize that even if the NE is in a single-box, the DoS attacks as described in Section 8.1.8 can still be launched through the Fi/f interfaces. Therefore, it is important to have the corresponding counter-measurement in place, even for single-box deployment.
箱か物理的に機密保護している部屋の中のCEsとFEsの間でForCESを配布するとき、箱の物理的なセキュリティで認証、秘密性、および保全を提供するかもしれません。 したがって、ネットワークトポロジーとその管理方針によって、セキュリティー対策はオフにされるかもしれません。 しかしながら、単一の箱の中にNEがあっても、Fi/fインタフェースを通してまだセクション8.1.8で説明されるDoS攻撃に着手できるとわかるのは重要です。 したがって、単一の箱の展開のためにさえ適所に対応するカウンタ測定を持っているのは重要です。
8.2.1. Using TLS with ForCES
8.2.1. 力があるTLSを使用します。
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インタフェースの上のForCESに使用されるなら、TLS[14]を使用できます。 TLS握手プロトコルは、CEとFEとのTLSセッションを交渉するのに協会設立か再確立段階の間、使用されます。 セッションが適所にいったんあると、TLSの記録的なプロトコルは、ForCESコミュニケーションが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.
ForCESと共にTLSをどう使用できるかに関する基本要綱は以下で説明されます。 7を通したステップ1)) 図9で例証されるようにセキュリティ握手を終了してください、ステップ8)はCEとFEとのさらなるすべてのコミュニケーションのためのものですが、図9に示されたセキュリティ握手と図10に示された定常状態コミュニケーションの後にメッセージの残りを含んでいて。
1) During the Pre-association phase, all FEs are configured with the
CEs (including both the active CE and the standby CE).
1) Pre-協会段階の間、すべてのFEsがCEsによって構成されます(アクティブなCEと予備CEの両方を含んでいて)。
2) The FE establishes a TLS connection with the CE (master) and
negotiates a cipher suite.
2) FEはCE(マスター)とのTLS接続を確立して、暗号スイートを交渉します。
3) The FE (slave) gets the CE certificate, validates the signature,
checks the expiration date, and checks whether the certificate has
been revoked.
3) FE(奴隷)は、CE証明書を手に入れて、署名を有効にして、有効期限をチェックして、証明書が取り消されたかどうかチェックします。
4) The CE (master) gets the FE certificate and performs the same
validation as the FE in step 3).
4) CE(マスター)は、ステップ3)でFE証明書を手に入れて、FEと同じ合法化を実行します。
5) If any of the checks fail in step 3) or step 4), the endpoint must
generate an error message and abort.
5) チェックのどれかはステップ3)に失敗するか、そして、ステップ4) 終点は、エラーメッセージを生成して、中止にならなければなりません。
6) After successful mutual authentication, a TLS session is
established between the CE and FE.
6) うまくいっている互いの認証の後に、TLSセッションはCEとFEの間で確立されます。
7) The FE sends a "join NE" message to the CE.
7) FEは「NEを接合してください」というメッセージをCEに送ります。
Yang, et al. Informational [Page 34] RFC 3746 ForCES Framework April 2004
陽、他 情報[34ページ]のRFC3746はフレームワーク2004年4月を強制します。
8) The FE and CE use the TLS session for further communication.
8) FEとCEはさらなるコミュニケーションにTLSセッションを使用します。
Note that there are different ways for the CE and FE to validate a received certificate. One way is to configure the FE Manager or CE Manager or other central component as CA, so that the CE or FE can query this pre-configured CA to validate that the certificate has not been revoked. Another way is to have the CE and FE directly configure a list of valid certificates in the pre-association phase.
CEとFEが受け取られていている証明書を有効にする異なった方法があることに注意してください。 1つの方法がカリフォルニアとしてFEマネージャ、CEマネージャまたは他の中心性成分を構成することであり、証明書は、CEかFEがそれを有効にするためにこのあらかじめ設定されたカリフォルニアについて質問できるように、取り消されていません。 別の方法は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がForCES州を連動させる責任です、フェイルオーバーの間、州の再建を最小にするためにTLS州を含んでいて。また、アクティブなCEと同様に、予備CEがフェイルオーバーの前かフェイルオーバー間認証されるのを保証するために注意しなければなりません。
8.2.2. Using IPsec with ForCES
8.2.2. 力があるIPsecを使用します。
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]を使用できます、UDPや、SCTPや、TCPなどのように、ForCESのためのFpインタフェースの上で。 IPsecを使用するとき、私たちは、メッセージ秘密性がForCESに必要であるのでForCESに交通機関で超能力を使用することを勧めます。
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.
手動の、そして、自動化されたSAと暗号のかぎ管理の両方と共にIPsecを使用できます。 しかし、手動のかぎ管理が使用されているなら、IPsecの反復操作による保護メカニズムは利用可能ではありません。 したがって、反復操作による保護が重要であると考えられるなら、自動かぎ管理はお勧めです。 さもなければ、手動のかぎ管理はいくつかの展開シナリオに十分であるかもしれません、特にCEsとFEsの数が比較的少ないときに。 手動のかぎ管理のためにさえ定期的にキーを変えるのはお勧めです。
IPsec can support both unicast and multicast transport. At the time this document was published, the MSEC working group was actively working on standardizing protocols to provide multicast security [17]. Multicast-based solutions relying on IPsec should specify how to meet the security requirements in [4].
IPsecはユニキャストとマルチキャスト輸送の両方をサポートすることができます。 このドキュメントが発表されたとき、MSECワーキンググループは活発にマルチキャストセキュリティ[17]を提供するためにプロトコルを標準化するのに取り組んでいました。 IPsecを当てにするマルチキャストベースのソリューションは[4]でセキュリティ必要条件を満たす方法を指定するべきです。
Unlike TLS, IPsec provides security services between the CE and FE at IP level, so the security handshake, as illustrated in Figure 9 amounts to a "no-op" when manual key management is used. The following outlines the steps taken for ForCES in such a case.
手動のかぎ管理が使用されているとき、TLSと異なって、IPsecはしたがって、平らで、セキュリティ握手であって、「オプアートがありません」への図9量におけるイラスト入りのIPでCEとFEの間にセキュリティー・サービスを供給します。 以下はこのような場合にはForCESに取られた方法を概説します。
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) Pre-協会段階の間、すべてのFEsがCEs(アクティブなCEと予備CEを含んでいる)とSAパラメタによって手動で構成されます。
Yang, et al. Informational [Page 35] RFC 3746 ForCES Framework April 2004
陽、他 情報[35ページ]のRFC3746はフレームワーク2004年4月を強制します。
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は「NEを接合してください」というメッセージをCEに送ります。 手動で構成された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]を使用できます。 また、ケルベロスなどの他の自動主要な分配技法は使用されるかもしれません。 主要な交換プロセスは図9で例証されるようにセキュリティ握手を構成します。 ステップがForCESのためにIPsecと共にIKEを使用するのに伴った以下のショー。 6へのステップ1)) 図9におけるセキュリティ握手を構成してください。
1) During the Pre-association phase, all FEs are configured with the
CEs (including active CE and standby CE), IPsec policy etc.
1) Pre-協会段階の間、すべてのFEsがCEsによって構成されて(アクティブなCEと予備CEを含んでいて)、IPsecは方針などです。
2) The FE kicks off the IKE process and tries to establish an IPsec
SA with the CE (master). The FE (Slave) gets the CE certificate
as part of the IKE negotiation. The FE validates the signature,
checks the expiration date, and checks whether the certificate has
been revoked.
2) FEはIKEプロセスをけっ飛ばして、CE(マスター)と共にIPsec SAを設立しようとします。 FE(奴隷)はIKE交渉の一部としてCE証明書を手に入れます。 FEは、署名を有効にして、有効期限をチェックして、証明書が取り消されたかどうかチェックします。
3) The CE (master) gets the FE certificate and performs the same
check as the FE in step 2).
3) CE(マスター)は、ステップ2)でFE証明書を手に入れて、FEと同じチェックを実行します。
4) If any of the checks fail in step 2) or step 3), the endpoint must
generate an error message and abort.
4) チェックのどれかはステップ2)に失敗するか、そして、ステップ3) 終点は、エラーメッセージを生成して、中止にならなければなりません。
5) After successful mutual authentication, the IPsec session is
established between the CE and FE.
5) うまくいっている互いの認証の後に、IPsecセッションはCEとFEの間で確立されます。
6) The FE sends a "join NE" message to the CE. No SADB entry is
created in FE yet.
6) FEは「NEを接合してください」というメッセージをCEに送ります。 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.
CEを有効にするためのカリフォルニアとIKEの間のFE証明書が処理されるとき、FEマネージャ、CEマネージャ、または他の中心性成分を使用できます。 あるいはまた、プレ協会段階の間、直接必須情報でCEとFEを構成できます、証明書やパスワードなどのように、管理者が構成したがっている認証のタイプに頼っていて。
Yang, et al. Informational [Page 36] RFC 3746 ForCES Framework April 2004
陽、他 情報[36ページ]のRFC3746はフレームワーク2004年4月を強制します。
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.
フェイルオーバーの場合では、それは、アクティブなCEと予備CEがForCES州を連動させる責任とフェイルオーバーの間に州の再建を最小にするIPsec州です。あるいはまた、FEは、各CEとの操業開始運転自体の間、異なったIPsec SAを設立する必要があります。 フラン(CE-CE)は連結しますが、これはIPsec層の向こう側に周期的な州の転送を最小にするでしょう。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[2] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
[3] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[3] フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、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.、Eds「IPの分離のための要件は、制御して、進める」RFC3654、2003年11月。
9.2. Informative References
9.2. 有益な参照
[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.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」RFC3410(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インチ、RFC2741、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.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年3月。
[8] Crouch, A. et al., "ForCES Applicability Statement", Work in
Progress.
[8]屈むこと、A.他、「力の適用性証明」、ProgressのWork。
[9] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", RFC 3532, May 2003.
[9] アンダーソン、T.、およびJ.Buerkle(「スイッチング素子のダイナミックな仕切りのための要件」、RFC3532)は2003がそうするかもしれません。
[10] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful Restart
Mechanism for Label Distribution Protocol", RFC 3478, February
2003.
[10]LeelanivasとM.とRekhterとY.とR.Aggarwal、「ラベル分配プロトコルのための優雅な再開メカニズム」、RFC3478、2003年2月。
Yang, et al. Informational [Page 37] RFC 3746 ForCES Framework April 2004
陽、他 情報[37ページ]のRFC3746はフレームワーク2004年4月を強制します。
[11] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF
Restart", RFC 3623, November 2003.
[11]MoyとJ.とPillay-EsnaultとP.とA.Lindem、「優雅なOSPFは再開する」RFC3623、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.ギンズバーグ、「シグナリングを再開する、-、」 仕事進行中です。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[14] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[15] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[15] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[16] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[17] Hardjono, T. and Weis, B. "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[17]HardjonoとT.とウィス、B. 「マルチキャストグループセキュリティー体系」、RFC3740、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.コーフマン、Eds、「インターネットへのセキュリティー対策」、RFC3631、12月2003日
Yang, et al. Informational [Page 38] RFC 3746 ForCES Framework April 2004
陽、他 情報[38ページ]のRFC3746はフレームワーク2004年4月を強制します。
10. Authors' Addresses
10. 作者のアドレス
L. Lily Yang Intel Corp., MS JF3-206, 2111 NE 25th Avenue Hillsboro, OR 97124, USA
L.ユリ陽のインテル社かMS JF3-206、2111Ne第25Avenueヒースボローか97124、米国
Phone: +1 503 264 8813 EMail: lily.l.yang@intel.com
以下に電話をしてください。 +1 8813年の503 264メール: lily.l.yang@intel.com
Ram Dantu Department of Computer Science, University of North Texas, Denton, TX 76203, USA
牡羊座Dantuコンピュータサイエンス学部、ノーステキサス大学、デントン、テキサス 76203、米国
Phone: +1 940 565 2822 EMail: rdantu@unt.edu
以下に電話をしてください。 +1 2822年の940 565メール: rdantu@unt.edu
Todd A. Anderson Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124, USA
第25トッドA.アンダーソンインテル社2111Ne Avenueヒースボロー、または97124、米国
Phone: +1 503 712 1760 EMail: todd.a.anderson@intel.com
以下に電話をしてください。 +1 1760年の503 712メール: todd.a.anderson@intel.com
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803, USA
ゴパルノキアResearch Center5、道端の道路、バーリントン、MA 01803、米国に激突してください。
Phone: +1 781 993 3685 EMail: ram.gopal@nokia.com
以下に電話をしてください。 +1 3685年の781 993メール: ram.gopal@nokia.com
Yang, et al. Informational [Page 39] RFC 3746 ForCES Framework April 2004
陽、他 情報[39ページ]のRFC3746はフレームワーク2004年4月を強制します。
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Yang, et al. Informational [Page 40]
陽、他 情報[40ページ]
一覧
スポンサーリンク
