[要約] RFC 7121は、ForCESネットワーク要素内の高可用性に関するものであり、要約すると、ネットワーク要素の分離における高可用性の実現方法について説明しています。このRFCの目的は、ForCESネットワーク要素の信頼性と可用性を向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Ogawa
Request for Comments: 7121 NTT Corporation
Updates: 5810 W. Wang
Category: Standards Track Zhejiang Gongshang University
ISSN: 2070-1721 E. Haleplidis
University of Patras
J. Hadi Salim
Mojatatu Networks
February 2014
High Availability within a Forwarding and Control Element Separation (ForCES) Network Element
転送および制御要素分離（ForCES）ネットワーク要素内の高可用性
Abstract
概要
This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.
このドキュメントでは、転送および制御要素分離（ForCES）ネットワーク要素（NE）内の制御要素（CE）高可用性（HA）について説明します。さらに、このドキュメントは、コールドスタンバイ高可用性メカニズムに新しい規範的なテキストを提供することにより、RFC 5810を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7121.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7121で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Quantifying Problem Scope . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. RFC 5810 CE HA Framework . . . . . . . . . . . . . . . . . . 7
2.1. RFC 5810 CE HA Support . . . . . . . . . . . . . . . . . 7
2.1.1. Cold Standby Interaction with the ForCES Protocol . . 8
2.1.2. Responsibilities for HA . . . . . . . . . . . . . . . 10
3. CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Changes to the FEPO Model . . . . . . . . . . . . . . . . 11
3.2. FEPO Processing . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. New FEPO Version . . . . . . . . . . . . . . . . . . 20
Figure 1 illustrates a ForCES Network Element (NE) controlled by a set of redundant Control Elements (CEs) with CE1 being active and CE2 and CEn being backups.
図1は、CE1がアクティブでCE2とCEnがバックアップである一連の冗長制御要素（CE）によって制御されるForCESネットワーク要素（NE）を示しています。
-----------------------------------------
| ForCES Network Element |
| +-----------+ |
| | CEn | |
| | (Backup) | |
-------------- Fc | +------------+ +------------+ | |
| CE Manager |--------+-| CE1 |------| CE2 |-+ |
-------------- | | (Active) | Fr | (Backup) | |
| | +-------+--+-+ +---+---+----+ |
| Fl | | | Fp / | |
| | | +---------+ / | |
| | Fp| |/ |Fp |
| | | | | |
| | | Fp /+--+ | |
| | | +-------+ | | |
| | | | | | |
-------------- Ff | --------+--+-- ----+---+----+ |
| FE Manager |--------+-| 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インターフェースFr：CE-CEインターフェースFc：CEマネージャーとCE間のインターフェースFf：FEマネージャーとFE間のインターフェースFl：CEマネージャーとFEマネージャー間のインターフェースFi / f：FE外部インターフェイス
Figure 1: ForCES Architecture
図1：ForCESアーキテクチャ
The ForCES architecture allows Forwarding Elements (FEs) to be aware of multiple CEs but enforces that only one CE be the master controller. This is known in the industry as 1+N redundancy. The master CE controls the FEs via the ForCES protocol operating on the Fp interface. If the master CE becomes faulty, i.e., crashes or loses connectivity, a backup CE takes over and NE operation continues. By definition, the current documented setup is known as cold standby. The set of CEs controlling an FE is static and is passed to the FE by the FE Manager (FEM) via the Ff interface and to each CE by the CE Manager (CEM) in the Fc interface during the pre-association phase.
ForCESアーキテクチャにより、Forwarding Element（FE）は複数のCEを認識できますが、1つのCEのみがマスターコントローラになるように強制します。これは業界では1 + N冗長性として知られています。マスターCEは、Fpインターフェイスで動作するForCESプロトコルを介してFEを制御します。マスターCEに障害が発生した場合、つまりクラッシュまたは接続が失われた場合、バックアップCEが引き継ぎ、NEの動作が続行されます。定義により、現在文書化されているセットアップはコールドスタンバイと呼ばれます。 FEを制御するCEのセットは静的であり、事前関連付けフェーズ中にFfインターフェイスを介してFE Manager（FEM）によってFEに渡され、FcインターフェイスのCE Manager（CEM）によって各CEに渡されます。
From an FE perspective, the operational parameters for a CE set are defined as components in the FEPO LFB in [RFC5810], Appendix B. In Section 2.1 of this document, we discuss further details of these parameters.
FEの観点から見ると、CEセットの運用パラメーターは、[RFC5810]の付録BのFEPO LFBのコンポーネントとして定義されています。このドキュメントのセクション2.1では、これらのパラメーターの詳細について説明します。
It is assumed that the reader is aware of the ForCES architecture to make sense of the changes being described in this document. This document provides background information to set the context of the discussion in Section 3.
読者は、このドキュメントで説明されている変更を理解するためにForCESアーキテクチャを認識していることを前提としています。このドキュメントは、セクション3のディスカッションのコンテキストを設定するための背景情報を提供します。
At the time of writing, the Fr interface is out of scope for the ForCES architecture. However, it is expected that organizations implementing a set of CEs will need to have the CEs communicate to each other via the Fr interface in order to achieve the synchronization necessary for controlling the FEs.
執筆時点では、FrインターフェイスはForCESアーキテクチャの範囲外です。ただし、一連のCEを実装する組織は、FEの制御に必要な同期を実現するために、Frインターフェイスを介してCEを相互に通信させる必要があることが予想されます。
The problem scope addressed by this document falls into two areas:
このドキュメントで扱う問題の範囲は、次の2つの領域に分類されます。
1. To update the description of [RFC5810] with more clarity on how the current cold standby approach operates within the NE cluster.
1. [RFC5810]の説明を更新して、現在のコールドスタンバイアプローチがNEクラスタ内でどのように動作するかをより明確にする。
2. To describe how to evolve the [RFC5810] cold standby setup to a hot standby redundancy setup to improve the failover time and NE availability.
2. [RFC5810]コールドスタンバイセットアップをホットスタンバイ冗長構成に進化させて、フェイルオーバー時間とNEの可用性を向上させる方法を説明します。
NE recovery and availability is dependent on several time-sensitive metrics:
NEの回復と可用性は、時間に敏感ないくつかのメトリックに依存します。
1. How fast the CE plane failure is detected by the FE.
1. CEプレーンの障害がFEによって検出される速度。
2. How fast a backup CE becomes operational.
2. バックアップCEが稼働するまでの時間。
3. How fast the FEs associate with the new master CE.
3. 新しいマスターCEに関連付けられたFEの速度。
4. How fast the FEs recover their state and become operational. Each FE state is the collective state of all its instantiated LFBs.
4. FEが状態を回復して操作可能になるまでの速さ。各FE状態は、インスタンス化されたすべてのLFBの集合的な状態です。
The design intent of [RFC5810] as well as this document to meet the above goals is driven by desire for simplicity.
上記の目標を達成するための[RFC5810]およびこのドキュメントの設計意図は、単純化への欲求によって推進されています。
To quantify the above criteria with the current prescribed ForCES CE setup in [RFC5810]:
[RFC5810]で現在規定されているForCES CEセットアップで上記の基準を定量化するには、次のようにします。
1. How fast the FE side detects a CE failure is left undefined. To illustrate an extreme scenario, we could have a human operator acting as the monitoring entity to detect faulty CEs. How fast such detection happens could be in the range of seconds to days. A more active monitor on the Fp interface could improve this detection. Usually, the FE will detect a CE failure either by the TML if the Fp interface terminates or by the ForCES protocol by utilizing the ForCES Heartbeat mechanism.
1. FE側がCE障害を検出する速度は未定義のままです。極端なシナリオを説明するために、障害のあるCEを検出する監視エンティティとして機能する人間のオペレーターがいる可能性があります。このような検出が発生する速さは、数秒から数日の範囲です。 Fpインターフェイスでよりアクティブなモニターを使用すると、この検出が向上する可能性があります。通常、FEは、Fpインターフェイスが終了した場合のTML、またはForCESハートビートメカニズムを利用したForCESプロトコルのいずれかによってCE障害を検出します。
2. How fast the backup CE becomes operational is also currently out of scope. In the current setup, a backup CE need not be operational at all (for example, to save power), and therefore it is feasible for a monitoring entity to boot up a backup CE after it detects the failure of the master CE. In Section 3 of this document, we suggest that at least one backup CE be online so as to improve this metric.
2. バックアップCEが動作可能になる速度も、現在のところ範囲外です。現在の設定では、バックアップCEはまったく動作していない（たとえば、電力を節約する）必要があるため、監視エンティティがマスターCEの障害を検出した後でバックアップCEを起動することは可能です。このドキュメントのセクション3では、このメトリックを改善するために、少なくとも1つのバックアップCEをオンラインにすることをお勧めします。
3. How fast an FE associates with a new master CE is also currently undefined. The cost of an FE connecting and associating adds to the recovery overhead. As mentioned above, we suggest having at least one backup CE online. In Section 3, we propose to remove the connection and association cost on failover by having each FE associate with all online backup CEs after associating to an active/master CE. Note that if an FE pre-associates with at least one backup CE, then the system will be technically operating in hot standby mode.
3. FEが新しいマスターCEと関連付ける速度も、現時点では未定義です。接続および関連付けを行うFEのコストにより、回復オーバーヘッドが増加します。上記のように、少なくとも1つのバックアップCEをオンラインにすることをお勧めします。セクション3では、アクティブ/マスターCEに関連付けた後、各FEをすべてのオンラインバックアップCEに関連付けることで、フェイルオーバー時の接続と関連付けのコストを削除することを提案します。 FEが少なくとも1つのバックアップCEに事前に関連付けられている場合、システムは技術的にホットスタンバイモードで動作していることに注意してください。
4. Finally, how fast an FE recovers its state depends on how much NE state exists. By the ForCES current definition, the new master CE assumes zero state on the FE and starts from scratch to update the FE. So, the larger the state, the longer the recovery.
4. 最後に、FEがその状態を回復する速度は、NEの状態がどれだけ存在するかに依存します。 ForCESの現在の定義では、新しいマスターCEはFEでゼロ状態を想定し、最初からFEを更新します。したがって、状態が大きいほど、回復に時間がかかります。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following definitions are taken from [RFC3654], [RFC3746], and [RFC5810]. They are repeated here for convenience as needed, but the normative definitions are found in the referenced RFCs:
以下の定義は、[RFC3654]、[RFC3746]、および[RFC5810]から取得されます。これらは必要に応じてここで繰り返しますが、規範的な定義は参照されるRFCにあります。
Logical Functional Block (LFB): A template that represents fine-grained, logically separate aspects of FE processing.
論理機能ブロック（LFB）：FE処理の細かく論理的に分離された側面を表すテンプレート。
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.
転送要素（FE）：ForCESプロトコルを実装する論理エンティティ。 FEは、基盤となるハードウェアを使用して、ForCESプロトコル経由でCEの指示に従ってパケットごとの処理と処理を提供します。
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.
コントロールエレメント（CE）：ForCESプロトコルを実装し、それを使用して1つ以上のFEにパケットの処理方法を指示する論理エンティティ。 CEは、制御やシグナリングプロトコルの実行などの機能を処理します。
ForCES Network Element (NE): An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE.
ForCESネットワーク要素（NE）：1つ以上のCEと1つ以上のFEで構成されるエンティティ。 NEは通常、内部組織を外部エンティティから隠し、NEの外部のエンティティに対する単一の管理ポイントを表します。
FE Manager (FEM): 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.
FE Manager（FEM）：事前関連付けフェーズで動作し、FEが通信するCEを決定する責任がある論理エンティティ。このプロセスはCEディスカバリーと呼ばれ、FEマネージャーが利用可能なCEの機能を学習する必要がある場合があります。
CE Manager (CEM): 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.
CEマネージャー（CEM）：関連付け前のフェーズで動作し、CEが通信する必要のあるFEを決定する責任がある論理エンティティ。このプロセスはFE検出と呼ばれ、CEマネージャーが利用可能なFEの機能を学習する必要がある場合があります。
ForCES Protocol: The protocol used for 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 and heartbeats) and the control messages themselves.
ForCESプロトコル：CEとFE間の通信に使用されるプロトコル。このプロトコルは、CEからCEへの通信、FEからFEへの通信、またはFEとCEマネージャー間の通信には適用されません。 ForCESプロトコルは、FEがスレーブでCEがマスターであるマスタースレーブプロトコルです。このプロトコルには、通信チャネルの管理（接続の確立やハートビートなど）と制御メッセージ自体の両方が含まれます。
ForCES Protocol Layer (ForCES PL): A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself (including requirements of ForCES Transport Mapping Layer (TML) as shown below). Specifications of ForCES PL are defined in [RFC5810].
ForCESプロトコルレイヤー（ForCES PL）：ForCESプロトコルアーキテクチャのレイヤーで、ForCESプロトコルメッセージ、プロトコルステート転送スキーム、およびForCESプロトコルアーキテクチャ自体（以下に示すForCESトランスポートマッピングレイヤー（TML）の要件を含む）を定義します。 ForCES PLの仕様は[RFC5810]で定義されています。
ForCES Protocol Transport Mapping Layer (ForCES TML): A layer in the ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like Stream Control Transmission Protocol (SCTP), IP, TCP, UDP, ATM, Ethernet, etc.), and how to achieve and implement reliability, security, etc.
ForCESプロトコルトランスポートマッピングレイヤー（ForCES TML）：プロトコルメッセージが異なるトランスポートメディア（Stream Control Transmission Protocol（SCTP）など）にマップされる方法、IP、 TCP、UDP、ATM、イーサネットなど）、および信頼性、セキュリティなどを実現および実装する方法。
To achieve CE High Availability (HA), FEs and CEs MUST interoperate per the definition in [RFC5810], which is repeated for contextual reasons in Section 2.1. It should be noted that in this default setup, which MUST be implemented by CEs and FEs requiring HA, the Fr plane is out of scope (and if available, is proprietary to an implementation).
CE高可用性（HA）を達成するには、FEとCEは、[RFC5810]の定義に従って相互運用する必要があります。これは、2.1の文脈上の理由から繰り返されます。 HAを必要とするCEおよびFEによって実装される必要があるこのデフォルトのセットアップでは、Frプレーンはスコープ外です（使用可能な場合、実装に固有です）。
As mentioned earlier, although there can be multiple redundant CEs, only one CE actively controls FEs in a ForCES NE. In practice, there may be only one backup CE. At any moment in time, only one master CE can control an FE. In addition, the FE connects and associates to only the master CE. The FE and the CE are aware of the primary and one or more secondary CEs. This information (primary and secondary CEs) is configured on the FE and the CE during pre-association by the FEM and the CEM, respectively.
前述のように、複数の冗長CEが存在する可能性がありますが、1つのCEのみがForCES NEのFEをアクティブに制御します。実際には、バックアップCEが1つしかない場合があります。いつでも、1つのマスターCEだけがFEを制御できます。さらに、FEはマスターCEのみに接続して関連付けます。 FEとCEは、プライマリCEと1つ以上のセカンダリCEを認識しています。この情報（プライマリおよびセカンダリCE）は、それぞれFEMおよびCEMによる事前関連付け中に、FEおよびCEで構成されます。
This section includes a new normative description that updates [RFC5810] for the Cold Standby High Availability mechanism.
このセクションには、コールドスタンバイ高可用性メカニズムの[RFC5810]を更新する新しい規範的な説明が含まれています。
Figure 2 below illustrates the ForCES message sequences that the FE uses to recover the connection in the currently defined cold standby scheme.
下の図2は、現在定義されているコールドスタンバイスキームで接続を回復するためにFEが使用するForCESメッセージシーケンスを示しています。
FE CE Primary CE Secondary
| | |
| Association Establishment | |
| Capabilities Exchange | |
1 |<------------------------->| |
| | |
| State Update | |
2 |<------------------------->| |
| | |
| | |
| FAILURE |
| |
| Association Establishment, Capabilities Exchange|
3 |<----------------------------------------------->|
| |
| Event Report (primary CE down) |
4 |------------------------------------------------>|
| |
| State Update |
5 |<----------------------------------------------->|
Figure 2: CE Failover for Cold Standby
図2：コールドスタンバイのCEフェールオーバー
HA parameterization in an FE is driven by configuring the FE Protocol Object (FEPO) LFB.
FEでのHAパラメーター化は、FEプロトコルオブジェクト（FEPO）LFBを構成することによって駆動されます。
The FEPO Control Element ID (CEID) component identifies the current master CE, and the component table BackupCEs identifies the configured backup CEs. The FEPO FE Heartbeat Interval (FEHI), CE Heartbeat Dead Interval (CEHDI), and CE Heartbeat policy help in detecting connectivity problems between an FE and CE. The CE failover policy defines how the FE should react on a detected failure. The FEObject FEState component [RFC5812] defines the operational forwarding status and control. The CE can turn off the FE's forwarding operations by setting the FEState to AdminDisable and can turn it on by setting it to OperEnable. Note: Section 5.1 of [RFC5812] has been updated by an erratum ([Err3487]) that describes the FEState as read-only when it should be read-write.
FEPOコントロールエレメントID（CEID）コンポーネントは現在のマスターCEを識別し、コンポーネントテーブルBackupCEsは構成済みのバックアップCEを識別します。 FEPO FEハートビートインターバル（FEHI）、CEハートビートデッドインターバル（CEHDI）、およびCEハートビートポリシーは、FEとCE間の接続の問題の検出に役立ちます。 CEフェイルオーバーポリシーは、検出された障害に対するFEの対応方法を定義します。 FEObject FEStateコンポーネント[RFC5812]は、運用転送ステータスと制御を定義します。 CEは、FEStateをAdminDisableに設定することでFEの転送操作をオフにでき、OperEnableに設定することでオンにできます。注：[RFC5812]のセクション5.1は、FEStateが読み取り/書き込みである必要がある場合に読み取り専用として説明するエラッタ（[Err3487]）によって更新されています。
Figure 3 illustrates the defined state machine that facilitates the recovery of the connection state.
図3は、接続状態の回復を容易にする定義済みの状態マシンを示しています。
The FE connects to the CE specified on the FEPO CEID component. If it fails to connect to the defined CE, it moves it to the bottom of table BackupCEs and sets its CEID component to be the first CE retrieved from table BackupCEs. The FE then attempts to associate with the CE designated as the new primary CE. The FE continues through this procedure until it successfully connects to one of the CEs or until the CE Failover Timeout Interval (CEFTI) expires.
FEは、FEPO CEIDコンポーネントで指定されたCEに接続します。定義されたCEへの接続に失敗した場合は、それをテーブルBackupCEの一番下に移動し、そのCEIDコンポーネントをテーブルBackupCEから取得した最初のCEに設定します。次に、FEは、新しいプライマリCEとして指定されたCEとの関連付けを試みます。 FEは、CEの1つに正常に接続するか、CEフェイルオーバータイムアウト間隔（CEFTI）が期限切れになるまで、この手順を続行します。
FE tries to associate
+-->-----+
| |
(CE changes master || | |
CE issues Teardown || +---+--------v----+
Lost association) && | Pre-association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| | | |
| +--------+--------+ |
| CE Association | | CEFTI
| Response V | timer
| +------------------+ | expires
| |FE issues CEPrimaryDown ^
| V |
+-+-----------+ +------+-----+
| | (CE changes master || | Not |
| | CE issues Teardown || | Associated |
| | Lost association) && | +->---+
| Associated | CE failover policy = 1 |(May | FE |
| | | Continue | try v
| |-------->------->------>| Forwarding)| assn|
| | Start CEFTI timer | |-<---+
| | | |
+-------------+ +-------+----+
^ |
| Successful V
| Association |
| Setup |
| (Cancel CEFTI timer) |
+_________________________________________+
FE issues CEPrimaryDown event
Figure 3: FE State Machine Considering HA
図3：HAを考慮したFEステートマシン
There are several events that trigger mastership changes. The master CE may issue a mastership change (by changing the CEID component), it may tear down an existing association, or connectivity may be lost between the CE and FE.
マスターシップの変更をトリガーするいくつかのイベントがあります。マスターCEは、（CEIDコンポーネントを変更することにより）マスターシップの変更を発行したり、既存の関連付けを破棄したり、CEとFEの間の接続が失われたりする場合があります。
When communication fails between the FE and CE (which can be caused by either the CE or link failure but is not FE related), either the TML on the FE will trigger the FE PL regarding this failure or it will be detected using the Heartbeat messages between FEs and CEs. The communication failure, regardless of how it is detected, MUST be considered to be a loss of association between the CE and corresponding FE.
FEとCE間の通信が失敗した場合（CEまたはリンク障害のいずれかが原因である可能性がありますが、FE関連ではありません）、FE上のTMLがこの障害に関してFE PLをトリガーするか、ハートビートメッセージを使用して検出されますFEとCEの間。通信障害は、それがどのように検出されるかに関係なく、CEと対応するFEの間の関連付けが失われたものと見なされなければなりません（MUST）。
If the FE's FEPO CE failover policy is configured to mode 0 (the default), it will immediately transition to the pre-association phase. This means that if association is later re-established with a CE, all FE states will need to be re-created.
FEのFEPO CEフェイルオーバーポリシーがモード0（デフォルト）に設定されている場合、ポリシーはすぐに事前関連付けフェーズに移行します。これは、関連付けが後でCEと再確立される場合、すべてのFE状態を再作成する必要があることを意味します。
If the FE's FEPO CE failover policy is configured to mode 1, it indicates that the FE will run in HA restart recovery. In such a case, the FE transitions to the not associated state and the CEFTI timer [RFC5810] is started. The FE may continue to forward packets during this state, depending upon the value of the CEFailoverPolicy component of the FEPO LFB. The FE recycles through any configured backup CEs in a round-robin fashion. It first adds its primary CE to the bottom of table BackupCEs and sets its CEID component to be the first secondary retrieved from table BackupCEs. The FE then attempts to associate with the CE designated as the new primary CE. If it fails to re-associate with any CE and the CEFTI expires, the FE then transitions to the pre-association state and the FE will operationally bring down its forwarding path (and set the [RFC5812] FEObject FEState component to OperDisable).
FEのFEPO CEフェイルオーバーポリシーがモード1に設定されている場合、FEがHA再起動リカバリで実行されることを示しています。このような場合、FEは関連付けられていない状態に移行し、CEFTIタイマー[RFC5810]が開始されます。 FEPO LFBのCEFailoverPolicyコンポーネントの値に応じて、FEはこの状態の間もパケットを転送し続ける場合があります。 FEは、構成済みのバックアップCEをラウンドロビン方式でリサイクルします。まず、プライマリCEをテーブルBackupCEの下部に追加し、CEIDコンポーネントをテーブルBackupCEから取得される最初のセカンダリに設定します。次に、FEは、新しいプライマリCEとして指定されたCEとの関連付けを試みます。 CEとの再関連付けに失敗し、CEFTIの有効期限が切れた場合、FEは関連付け前の状態に移行し、FEは動作上、転送パスを停止します（[RFC5812] FEObject FEStateコンポーネントをOperDisableに設定します）。
If the FE, while in the not associated state, manages to reconnect to a new primary CE before the CEFTI expires, it transitions to the associated state. Once re-associated, the CE may try to synchronize any state that the FE may have lost during disconnection. How the CE re-synchronizes such a state is out of scope for the current ForCES architecture but would typically constitute the issuing of new Config messages and queries.
FEは、関連付けられていない状態で、CEFTIが期限切れになる前に新しいプライマリCEに再接続できた場合、関連付けられた状態に移行します。再関連付けされると、CEは切断中にFEが失ったすべての状態を同期しようとする場合があります。 CEがこのような状態を再同期する方法は、現在のForCESアーキテクチャの範囲外ですが、通常、新しい構成メッセージとクエリの発行を構成します。
An explicit message (a Config message setting the primary CE component in the ForCES Protocol Object) from the primary CE can also be used to change the primary CE for an FE during normal protocol operation. In this case, the FE transitions to the not associated state and attempts to associate with the new CE.
プライマリCEからの明示的なメッセージ（ForCESプロトコルオブジェクトのプライマリCEコンポーネントを設定する構成メッセージ）を使用して、通常のプロトコル操作中にFEのプライマリCEを変更することもできます。この場合、FEは関連付けられていない状態に移行し、新しいCEとの関連付けを試みます。
TML Level:
TMLレベル：
1. The TML controls logical connection availability and failover.
1. TMLは、論理接続の可用性とフェイルオーバーを制御します。
2. The TML also controls peer HA management.
2. TMLはピアHA管理も制御します。
At this level, control of all lower layers, for example, the transport level (such as IP addresses, Media Access Control (MAC) addresses, etc.), and associated links going down are the role of the TML.
このレベルでは、トランスポートレベル（IPアドレス、メディアアクセス制御（MAC）アドレスなど）などのすべての下位層の制御と、ダウンする関連リンクがTMLの役割です。
PL Level: All other functionality, including configuring the HA behavior during setup, Control Element IDs (CE IDs) used to identify primary and secondary CEs, protocol messages used to report CE failure (event report), Heartbeat messages used to detect association failure, messages to change the primary CE (Config), and other HA-related operations described in Section 2.1, are the PL's responsibility.
PLレベル：セットアップ中のHA動作の構成、プライマリおよびセカンダリCEの識別に使用されるコントロールエレメントID（CE ID）、CE障害の報告に使用されるプロトコルメッセージ（イベントレポート）、アソシエーション障害の検出に使用されるハートビートメッセージ、その他すべての機能プライマリCE（構成）を変更するメッセージ、およびセクション2.1で説明されているその他のHA関連の操作は、PLの責任です。
To put the two together, if a path to a primary CE is down, the TML would help recover from a failure by switching over to a backup path, if one is available. If the CE is totally unreachable, then the PL would be informed and it would take the appropriate actions described before.
2つを組み合わせると、プライマリCEへのパスがダウンしている場合、TMLは、バックアップパスが使用可能な場合、バックアップパスに切り替えることで障害からの回復に役立ちます。 CEがまったく到達できない場合、PLは通知を受け、前述の適切なアクションを実行します。
In this section, we describe small extensions to the existing scheme to enable hot standby HA. To achieve hot standby HA, we aim to improve the specific goals defined in Section 1.1, namely:
このセクションでは、ホットスタンバイHAを有効にするための既存のスキームの小さな拡張について説明します。ホットスタンバイHAを実現するために、セクション1.1で定義された特定の目標、すなわち次の改善を目指します。
o How fast a backup CE becomes operational.
o バックアップCEが稼働するまでの時間。
o How fast the FEs associate with the new master CE.
o 新しいマスターCEに関連付けられたFEの速度。
As described in Section 2.1, in the pre-association phase, the FEM configures the FE to make it aware of all the CEs in the NE. The FEM MUST configure the FE to make it aware of which CE is the master and MAY specify any backup CE(s).
セクション2.1で説明したように、事前関連付けフェーズでは、FEMはFEを構成して、NE内のすべてのCEを認識させるようにします。 FEMはFEを構成して、どのCEがマスターであるかを認識させ、バックアップCEを指定する必要があります。
In order for the above to be achievable, there is a need to make a few changes in the FEPO model. Appendix A contains the xml definition of the new version 1.1 of the FEPO LFB.
上記を実現するには、FEPOモデルにいくつかの変更を加える必要があります。付録Aには、FEPO LFBの新しいバージョン1.1のXML定義が含まれています。
Changes from version 1 of the FEPO are:
FEPOのバージョン1からの変更点は次のとおりです。
1. Added four new datatypes:
1. 4つの新しいデータ型が追加されました。
1. CEStatusType -- an unsigned char to specify the status of a connection with a CE. Special values are:
1. CEStatusType-CEとの接続のステータスを指定する符号なし文字。特別な値は次のとおりです。
+ 0 (Disconnected) represents that no connection attempt has been made with the CE yet
+ 0（切断）は、CEとの接続がまだ試行されていないことを示します
+ 1 (Connected) represents that the FE connection with the CE at the TML has completed successfully
+ 1（接続済み）は、TMLでのCEとのFE接続が正常に完了したことを表します
+ 2 (Associated) represents that the FE has successfully associated with the CE
+ 2（関連付け）は、FEがCEと正常に関連付けられたことを表します
+ 3 (IsMaster) represents that the FE has associated with the CE and is the master of the FE
+ 3（IsMaster）は、FEがCEに関連付けられ、FEのマスターであることを表します
+ 4 (LostConnection) represents that the FE was associated with the CE at one point but lost the connection
+ 4（LostConnection）は、ある時点でFEがCEに関連付けられていたが、接続が失われたことを表します
+ 5 (Unreachable) represents that the FE deems this CE unreachable, i.e., the FE has tried over a period to connect to it but has failed
+ 5（到達不能）は、FEがこのCEに到達できないと判断したことを示します。つまり、FEは一定期間接続を試みたが、接続に失敗しました。
2. HAModeValues -- an unsigned char to specify a selected HA mode. Special values are:
2. HAModeValues-選択されたHAモードを指定するためのunsigned char。特別な値は次のとおりです。
+ 0 (No HA Mode) represents that the FE is not running in HA mode
+ 0（HAモードなし）は、FEがHAモードで実行されていないことを表します
+ 1 (HA Mode - Cold Standby) represents that the FE is in HA mode cold standby
+ 1（HAモード-コールドスタンバイ）は、FEがHAモードのコールドスタンバイであることを表します
+ 2 (HA Mode - Hot Standby) represents that the FE is in HA mode hot standby
+ 2（HAモード-ホットスタンバイ）は、FEがHAモードのホットスタンバイであることを表します
3. Statistics -- a complex structure representing the communication statistics between the FE and CE. The components are:
3. 統計-FEとCE間の通信統計を表す複雑な構造。コンポーネントは次のとおりです。
+ RecvPackets, representing the packet count received from the CE
+ CEから受信したパケット数を表すRecvPackets
+ RecvBytes, representing the byte count received from the CE
+ CEから受信したバイト数を表すRecvBytes
+ RecvErrPackets, representing the erroneous packets received from the CE. This component logs badly formatted packets as well as good packets sent to the FE by the CE to set components whilst that CE is not the master. Erroneous packets are dropped (i.e., not responded to).
+ CEから受信したエラーのあるパケットを表すRecvErrPackets。このコンポーネントは、不正にフォーマットされたパケットと、CEがマスターではないコンポーネントを設定するためにCEによってFEに送信された正常なパケットをログに記録します。誤ったパケットは破棄されます（つまり、応答されません）。
+ RecvErrBytes, representing the RecvErrPackets byte count received from the CE
+ CEから受信したRecvErrPacketsバイト数を表すRecvErrBytes
+ TxmitPackets, representing the packet count transmitted to the CE
+ CEに送信されたパケット数を表すTxmitPackets
+ TxmitErrPackets, representing the error packet count transmitted to the CE. Typically, these would be failures due to communication.
+ TxmitErrPackets。CEに送信されたエラーパケット数を表します。通常、これらは通信による障害です。
+ TxmitBytes, representing the byte count transmitted to the CE
+ TxmitBytes、CEに送信されたバイト数を表します
+ TxmitErrBytes, representing the byte count of errors from transmit to the CE
+ TxmitErrBytes。送信からCEへのエラーのバイト数を表します
4. AllCEType -- a complex structure constituting the CE IDs, statistics, and CEStatusType to reflect connection information for one CE. Used in the AllCE's component array.
4. AllCEType-1つのCEの接続情報を反映するためのCE ID、統計、およびCEStatusTypeを構成する複雑な構造。 AllCEのコンポーネント配列で使用されます。
2. Appended two new components:
2. 追加された2つの新しいコンポーネント：
1. Read-only AllCEs to hold the status for all CEs. AllCEs is an array of the AllCEType.
1. すべてのCEのステータスを保持する読み取り専用AllCE。 AllCEsはAllCETypeの配列です。
2. Read-write HAMode of type HAModeValues to carry the HA mode used by the FE.
2. HAModeValuesタイプのHAModeを読み書きして、FEが使用するHAモードを伝達します。
3. Added one additional event, PrimaryCEChanged, reporting the new master CE ID when there is a mastership change.
3. マスターシップが変更されたときに新しいマスターCE IDを報告する1つの追加イベントPrimaryCEChangedを追加しました。
Since no component from FEPO v1 has been changed, FEPO v1.1 retains backwards compatibility with CEs that know only version 1.0. These CEs, however, cannot make use of the HA options that the new FEPO provides.
FEPO v1のコンポーネントは変更されていないため、FEPO v1.1は、バージョン1.0のみを認識しているCEとの下位互換性を保持しています。ただし、これらのCEは、新しいFEPOが提供するHAオプションを利用できません。
The FE's FEPO LFB version 1.1 AllCEs table contains all the CE IDs with which the FE may connect and associate. The ordering of the CE IDs in this table defines the priority order in which an FE will connect to the CEs. This table is provisioned initially from the configuration plane (FEM). In the pre-association phase, the first CE (lowest table index) in the AllCEs table MUST be the first CE with which the FE will attempt to connect and associate. If the FE fails to connect and associate with the first listed CE, it will attempt to connect to the second CE and so forth, and it cycles back to the beginning of the list until there is a successful association. The FE MUST associate with at least one CE. Upon a successful association, a component of the FEPO LFB, specifically the CEID component, identifies the current associated master CE.
FEのFEPO LFBバージョン1.1 AllCEsテーブルには、FEが接続して関連付けることができるすべてのCE IDが含まれています。この表のCE IDの順序は、FEがCEに接続する優先順位を定義します。このテーブルは、最初に構成プレーン（FEM）からプロビジョニングされます。事前関連付けフェーズでは、AllCEsテーブル内の最初のCE（最小のテーブルインデックス）は、FEが接続および関連付けを試みる最初のCEである必要があります。最初にリストされたCEへの接続および関連付けに失敗した場合、FEは2番目のCEへの接続を試み、以下同様に、関連付けが成功するまでリストの先頭に戻ります。 FEは少なくとも1つのCEと関連付ける必要があります。関連付けが成功すると、FEPO LFBのコンポーネント、具体的にはCEIDコンポーネントが、現在関連付けられているマスターCEを識別します。
While it would be much simpler to have the FE not respond to any messages from a CE other than the master, in practice it has been found to be useful to respond to queries and heartbeats from backup CEs. For this reason, we allow backup CEs to issue queries to the FE. Configuration messages (SET/DEL) from backup CEs MUST be dropped by the FE and logged as received errors.
FEがマスター以外のCEからのメッセージに応答しないようにする方がはるかに簡単ですが、実際には、バックアップCEからのクエリとハートビートに応答するのが便利であることがわかっています。このため、バックアップCEがFEにクエリを発行することを許可しています。バックアップCEからの構成メッセージ（SET / DEL）は、FEによってドロップされ、受信エラーとしてログに記録される必要があります。
Asynchronous events that the master CE has subscribed to, as well as heartbeats, are sent to all associated CEs. Packet redirects continue to be sent only to the master CE. The Heartbeat Interval, the CE Heartbeat (CEHB) policy, and the FE Heartbeat (FEHB) policy are global for all CEs (and changed only by the master CE).
マスターCEがサブスクライブした非同期イベントとハートビートは、関連するすべてのCEに送信されます。パケットリダイレクトは、引き続きマスターCEにのみ送信されます。ハートビート間隔、CEハートビート（CEHB）ポリシー、およびFEハートビート（FEHB）ポリシーは、すべてのCEに対してグローバルです（マスターCEによってのみ変更されます）。
Figure 4 illustrates the state machine that facilitates connection recovery with HA enabled.
図4は、HAを有効にした状態で接続の回復を容易にするステートマシンを示しています。
FE tries to associate
+-->-----+
| |
(CE changes master || | |
CE issues Teardown || +---+--------v----+
Lost association) && | Pre-association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| | | |
| +--------+--------+ |
| CE Association | | CEFTI
| Response V | timer
| +------------------+ | expires
| |FE issues CEPrimaryDown ^
| |FE issues PrimaryCEChanged ^
| V |
+-+-----------+ +------+-----+
| | (CE changes master || | Not |
| | CE issues Teardown || | Associated |
| | Lost association) && | +->----------+
| Associated | CE failover policy = 1 |(May | find first |
| | | Continue | associated v
| |-------->------->------>| Forwarding)| CE or retry|
| | Start CEFTI timer | | associating|
| | | |-<----------+
| | | |
+----+--------+ +-------+----+
| |
^ Found | associated CE
| or newly | associated CE
| V
| (Cancel CEFTI timer) |
+_________________________________________+
FE issues CEPrimaryDown event
FE issues PrimaryCEChanged event
Figure 4: FE State Machine Considering HA
図4：HAを考慮したFEステートマシン
Once the FE has associated with a master CE, it moves to the post-association phase (associated state). It is assumed that the master CE will communicate with other CEs within the NE for the purpose of synchronization via the CE-CE interface. The CE-CE interface is out of scope for this document. An election result amongst CEs may result in the desire to change the mastership to a different associated CE; at which point, the current assumed master CE will instruct the FE to use a different master CE.
FEがマスターCEに関連付けられると、関連付け後のフェーズ（関連付けられた状態）に移行します。マスターCEは、CE-CEインターフェイスを介して同期するために、NE内の他のCEと通信することが想定されています。 CE-CEインターフェイスは、このドキュメントの範囲外です。 CE間での選挙結果により、マスターシップを別の関連するCEに変更したい場合があります。その時点で、現在想定されているマスターCEは、別のマスターCEを使用するようにFEに指示します。
FE CE#1 CE#2 ... CE#N
| | | |
| Association Establishment | | |
| Capabilities Exchange | | |
1 |<------------------------->| | |
| | | |
| State Update | | |
2 |<------------------------->| | |
| | | |
| Association Establishment | |
| Capabilities Exchange | |
3I|<-------------------------------------->| |
... ... ... ...
|Association Establishment, Capabilities Exchange |
3N|<----------------------------------------------->|
| | | |
4 |<------------------------->| | |
. . . .
4x|<------------------------->| | |
| FAILURE | |
| | | |
| Event Report (LastCEID changed) | |
5 |--------------------------------------->|------->|
| Event Report (CE#2 is new master) | |
6 |--------------------------------------->|------->|
| | |
7 |<-------------------------------------->| |
. . . .
7x|<-------------------------------------->| |
. . . .
Figure 5: CE Failover for Hot Standby
図5：ホットスタンバイのCEフェールオーバー
While in the post-association phase, if the CE failover policy is set to 1 and the HAMode is set to 2 (hot standby), then the FE, after successfully associating with the master CE, MUST attempt to connect and associate with all the CEs of which it is aware. Figure 5, steps #1 and #2 illustrates the FE associating with CE#1 as the master, and then proceeding to steps #3I to #3N, it shows the association with backup CEs CE#2 to CE#N. If the FE fails to connect or associate with some CEs, the FE MAY flag them as unreachable to avoid continuous attempts to connect. The FE MAY try to re-associate with unreachable CEs when possible.
関連付け後のフェーズで、CEフェイルオーバーポリシーが1に設定され、HAModeが2（ホットスタンバイ）に設定されている場合、FEは、マスターCEとの関連付けに成功した後、すべてのとの接続と関連付けを試行する必要があります。認識しているCE。図5のステップ＃1と＃2は、マスターとしてCE＃1に関連付けられているFEを示し、ステップ＃3Iから＃3Nに進むと、バックアップCE CE＃2からCE＃Nへの関連付けを示しています。 FEが一部のCEとの接続または関連付けに失敗した場合、FEはそれらに到達不能のフラグを付けて、接続の継続的な試行を回避することができます。 FEは、可能な場合、到達不能なCEとの関連付けを再試行する場合があります。
When the master CE, for any reason, is considered to be down, then the FE MUST try to find the first associated CE from the list of all CEs in a round-robin fashion.
何らかの理由でマスターCEがダウンしていると見なされた場合、FEは、すべてのCEのリストから最初に関連付けられたCEをラウンドロビン方式で見つけようとする必要があります。
If the FE is unable to find an associated FE in its list of CEs, then it MUST attempt to connect and associate with the first from the list of all CEs and continue in a round-robin fashion until it connects and associates with a CE or the CEFTI timer expires.
FEがCEのリストで関連するFEを見つけることができない場合、接続およびすべてのCEのリストから最初のFEへの関連付けを試行し、接続またはCEに関連付けるまでラウンドロビン方式で続行する必要があります。 CEFTIタイマーが期限切れになります。
Once the FE selects an associated CE to use as the new master, the FE issues a PrimaryCEDown Event Notification to all associated CEs to notify them that the last primary CE went down (and what its identity was); a second event, PrimaryCEChanged, identifying the new master CE is sent as well to identify which CE the reporting FE considers to be the new master.
FEが新しいマスターとして使用する関連付けられたCEを選択すると、FEはすべての関連付けられたCEにPrimaryCEDownイベント通知を発行して、最後のプライマリCEがダウンしたこと（およびそのID）を通知します。新しいマスターCEを識別する2番目のイベントPrimaryCEChangedも送信され、レポートFEが新しいマスターと見なすCEを識別します。
In most HA architectures, there exists the possibility of split brain. However, in our setup, since the FE will never accept any configuration messages from any other than the master CE, we consider the FE to be fenced against data corruption from the other CEs that consider themselves as the master. The split-brain issue becomes mostly a CE-CE communication problem, which is considered to be out of scope.
ほとんどのHAアーキテクチャでは、スプリットブレインが発生する可能性があります。ただし、このセットアップでは、FEはマスターCE以外からの構成メッセージを一切受け入れないため、自分自身をマスターと見なす他のCEからのデータ破損からFEを隔離することを検討します。スプリットブレインの問題は、主にCE-CE通信の問題になり、範囲外と見なされます。
By virtue of having multiple CE connections, the FE switchover to a new master CE will be relatively much faster. The overall effect is improving the NE recovery time in case of communication failure or faults of the master CE. This satisfies the requirement we set to fulfill.
複数のCE接続があるため、新しいマスターCEへのFEスイッチオーバーは比較的高速になります。全体的な効果は、通信障害またはマスターCEの障害が発生した場合のNE復旧時間の改善です。これは、満たすために設定した要件を満たしています。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], the "Logical Functional Block (LFB) Class Names and Class Identifiers" namespace has been updated.
「RFCのIANAに関する考慮事項セクションを作成するためのガイドライン」[RFC5226]で概説されているポリシーに従って、「論理機能ブロック（LFB）クラス名とクラス識別子」名前空間が更新されました。
A new column, LFB version, has been added to the table after the LFB Class Name. The table now reads as follows:
新しい列、LFBバージョンが、LFBクラス名の後にテーブルに追加されました。テーブルは次のようになります。
+----------------+------------+-----------+-------------+-----------+
| LFB Class | LFB Class | LFB | Description | Reference |
| Identifier | Name | Version | | |
+----------------+------------+-----------+-------------+-----------+
Logical Functional Block (LFB) Class Names and Class Identifiers
論理機能ブロック（LFB）のクラス名とクラス識別子
The rules defined in [RFC5812] apply, with the addition that entries must provide the LFB version as a string.
[RFC5812]で定義されたルールが適用されます。さらに、エントリはLFBバージョンを文字列として提供する必要があります。
Upon publication of this document, all current entries are assigned a value of 1.0.
このドキュメントが公開されると、現在のすべてのエントリに値1.0が割り当てられます。
New versions of already defined LFBs MUST NOT remove the previous version entries.
定義済みのLFBの新しいバージョンは、以前のバージョンのエントリを削除してはなりません（MUST NOT）。
It would make sense to have LFB versions appear in sequence in the registry. The table SHOULD be sorted, and the sorting should be done by Class ID first and then by version.
レジストリにLFBバージョンを順番に表示することは理にかなっています。テーブルはソートする必要があります（SHOULD）。ソートは最初にクラスIDで、次にバージョンで行う必要があります。
This document introduces the FE Protocol Object version 1.1 as follows:
このドキュメントでは、FEプロトコルオブジェクトバージョン1.1を次のように紹介しています。
+------------+----------+---------+---------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+----------+---------+---------------------+-----------+
| 2 | FE | 1.1 | Defines parameters | [RFC7121] |
| | Protocol | | for the ForCES | |
| | Object | | protocol operation | |
+------------+----------+---------+---------------------+-----------+
Logical Functional Block (LFB) Class Names and Class Identifiers
論理機能ブロック（LFB）のクラス名とクラス識別子
Security considerations, as defined in Section 9 of [RFC5810], apply to securing each CE-FE communication. Multiple CEs associated with the same FE still require the same procedure to be followed on a per-association basis.
[RFC5810]のセクション9で定義されているセキュリティの考慮事項は、各CE-FE通信のセキュリティ保護に適用されます。同じFEに関連付けられた複数のCEでも、関連付けごとに同じ手順に従う必要があります。
It should be noted that since the FE is initiating the association with a CE, a CE cannot initiate association with the FE and such messages will be dropped. Thus, the FE is secured from rogue CEs that are attempting to associate with it.
FEはCEとのアソシエーションを開始しているため、CEはFEとのアソシエーションを開始できず、そのようなメッセージはドロップされることに注意してください。したがって、FEは、それに関連付けようとしている不正なCEから保護されます。
CE implementers should have in mind that once associated, the FE cannot distinguish whether the CE has been compromised or has been malfunctioning while not losing connectivity. Securing the CE is out of scope of this document.
CEの実装者は、いったん関連付けられると、接続を失うことなくCEが危険にさらされているのか、誤動作しているかをFEが区別できないことに留意する必要があります。 CEの保護は、このドキュメントの範囲外です。
While the CE-CE plane is outside the current scope of ForCES, we recognize that it may be subjected to attacks that may affect the CE-FE communication.
CE-CEプレーンはForCESの現在の範囲外ですが、CE-FE通信に影響を与える可能性がある攻撃を受ける可能性があることを認識しています。
The following considerations should be made:
次の考慮事項を行う必要があります。
1. Secure communication channels should be used between CEs for coordination and keeping of state to at least avoid connection of malicious CEs.
1. 少なくとも悪意のあるCEの接続を回避するために、調整と状態の維持のためにCE間で安全な通信チャネルを使用する必要があります。
2. The master CE should take into account DoS and Distributed Denial-of-Service (DDoS) attacks from malicious or malfunctioning CEs.
2. マスターCEは、悪意のあるまたは誤動作しているCEからのDoSおよび分散型サービス拒否（DDoS）攻撃を考慮する必要があります。
3. CEs should take into account the split-brain issue. There are currently two fail-safes in the FE: Firstly, the FE has the CEID component that denotes which CE is the master. Secondly, the FE does not allow BackupCEs to configure the FE. However, backup CEs that consider that the master CE has dropped should, as masters themselves, first do a sanity check and query the FE CEID component.
3. CEはスプリットブレインの問題を考慮する必要があります。現在、FEには2つのフェイルセーフがあります。最初に、FEには、CEがマスターであることを示すCEIDコンポーネントがあります。次に、FEはBackupCEがFEを構成することを許可しません。ただし、マスターCEがドロップしたと見なすバックアップCEは、マスター自体として、最初に健全性チェックを実行し、FE CEIDコンポーネントにクエリを実行する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810] Doria、A.、Hadi Salim、J.、Haas、R.、Khosravi、H.、Wang、W.、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素の分離（ForCES）プロトコル仕様」、RFC 5810、2010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、2010年3月。
[Err3487] RFC Errata, Errata ID 3487, RFC 5812, <http://www.rfc-editor.org>.
[Err3487] RFC Errata、Errata ID 3487、RFC 5812、<http://www.rfc-editor.org>。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IP Control and Forwardingの分離の要件」、RFC 3654、2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、2004年4月。
The xml has been validated against the schema defined in [RFC5812].
XMLは、[RFC5812]で定義されているスキーマに対して検証されています。
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO">
<!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<synopsis>
The possible values of the CE Heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE will send heartbeats to the FE
every CEHDI timeout if no other messages
have been sent since.
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE will not send heartbeats to the FE
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<synopsis>
The possible values of the FE Heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE will not generate any heartbeats to the CE
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE generates heartbeats to the CE every FEHI
if no other messages have been sent to the CE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of the FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restarts its state from scratch
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>HAModeValues</name>
<synopsis>
The possible values of HA modes
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>NoHA</name>
<synopsis>
The FE is not running in HA mode
</synopsis>
</specialValue>
<specialValue value="1">
<name>ColdStandby</name>
<synopsis>
The FE is running in HA mode cold standby
</synopsis>
</specialValue>
<specialValue value="2">
<name>HotStandby</name>
<synopsis>
The FE is running in HA mode hot standby
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of the CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The FE should stop functioning immediately and
transition to the FE OperDisable state
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The FE should continue forwarding even without an
associated CE for CEFTI. The FE goes to FE
OperDisable when the CEFTI expires and there is no
association. Requires graceful restart support.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHACapab</name>
<synopsis>
The supported HA features
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>GracefullRestart</name>
<synopsis>
The FE supports graceful restart
</synopsis>
</specialValue>
<specialValue value="1">
<name>HA</name>
<synopsis>
The FE supports HA
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEStatusType</name>
<synopsis>Status values. Status for each CE</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disconnected</name>
<synopsis>No connection attempt with the CE yet
</synopsis>
</specialValue>
<specialValue value="1">
<name>Connected</name>
<synopsis>The FE connection with the CE at the TML
has been completed
</synopsis>
</specialValue>
<specialValue value="2">
<name>Associated</name>
<synopsis>The FE has associated with the CE
</synopsis>
</specialValue>
<specialValue value="3">
<name>IsMaster</name>
<synopsis>The CE is the master (and associated)
</synopsis>
</specialValue>
<specialValue value="4">
<name>LostConnection</name>
<synopsis>The FE was associated with the CE but
lost the connection
</synopsis>
</specialValue>
<specialValue value="5">
<name>Unreachable</name>
<synopsis>The CE is deemed as unreachable by the FE
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>StatisticsType</name>
<synopsis>Statistics Definition</synopsis>
<struct>
<component componentID="1">
<name>RecvPackets</name>
<synopsis>Packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>RecvErrPackets</name>
<synopsis>Packets received from the CE with errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>RecvBytes</name>
<synopsis>Bytes received from the CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>RecvErrBytes</name>
<synopsis>Bytes received from the CE in Error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>TxmitPackets</name>
<synopsis>Packets transmitted to the CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>TxmitErrPackets</name>
<synopsis>
Packets transmitted to the CE that
incurred errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>TxmitBytes</name>
<synopsis>Bytes transmitted to the CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>TxmitErrBytes</name>
<synopsis>
Bytes transmitted to the CE that
incurred errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>AllCEType</name>
<synopsis>Table type for the AllCE component</synopsis>
<struct>
<component componentID="1">
<name>CEID</name>
<synopsis>ID of the CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>Statistics</name>
<synopsis>Statistics per the CE</synopsis>
<typeRef>StatisticsType</typeRef>
</component>
<component componentID="3">
<name>CEStatus</name>
<synopsis>Status of the CE</synopsis>
<typeRef>CEStatusType</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object, with new CEHA
</synopsis>
<version>1.1</version>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running the ForCES version</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
The table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the
primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE failover policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE restart policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The primary CE this FE was last associated
with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="14" access="read-write">
<name>HAMode</name>
<synopsis>
The HA mode used
</synopsis>
<typeRef>HAModeValues</typeRef>
</component>
<component componentID="15" access="read-only">
<name>AllCEs</name>
<synopsis>The table of all CEs</synopsis>
<array type="variable-size">
<typeRef>AllCEType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
The table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>uchar</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
The table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The primary CE has changed
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>PrimaryCEChanged</name>
<synopsis>A new primary CE has been selected
</synopsis>
<eventTarget>
<eventField>CEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>CEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Authors' Addresses
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
けんたろ おがわ んっｔ こｒぽらちおん ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: k.ogawa@ntt.com
Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
Weiの名前Wang Z Hejiang go Agriculture and Industry University 18 X UE正通り、ξASha大学の町、杭州310018 P.R.中国
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
エヴァンジェロスハレプリディスパトラス大学電気電子工学科パトラス26500ギリシャ
EMail: ehalep@ece.upatras.gr
Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada
Jamal Hadi Salim Mojatatu Networks Suite 400、303 Moodie Dr. Ottawa、オンタリオK2H 9R4カナダ
EMail: hadi@mojatatu.com