[要約] RFC 5811は、ForCESプロトコルのためのSCTPベースのトランスポートマッピングレイヤー（TML）に関する仕様です。このRFCの目的は、ForCESプロトコルのための効果的なトランスポートマッピングレイヤーを提供することです。
Internet Engineering Task Force (IETF) J. Hadi Salim
Request for Comments: 5811 Mojatatu Networks
Category: Standards Track K. Ogawa
ISSN: 2070-1721 NTT Corporation
March 2010
SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol
転送および制御要素分離（力）プロトコル用のSCTPベースの輸送マッピング層（TML）
Abstract
概要
This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol.
このドキュメントは、力（転送および制御要素分離）プロトコルのSCTPベースのTML（輸送マッピング層）を定義します。SCTP（Stream Control Transmission Protocol）を選択する理由を説明し、このTMLが必要なすべての要件とForce Protocolにどのように対処するかについても説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc5811.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5811で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................3
3. Protocol Framework Overview .....................................4
3.1. The PL .....................................................5
3.2. The TML ....................................................5
3.2.1. TML and PL Interfaces ...............................5
3.2.2. TML Parameterization ................................6
4. SCTP TML Overview ...............................................7
4.1. Rationale for Using SCTP for TML ...........................7
4.2. Meeting TML Requirements ...................................8
4.2.1. SCTP TML Channels ...................................9
4.2.2. Satisfying TML Requirements ........................14
5. SCTP TML Channel Work ..........................................16
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. IPsec Usage ...............................................17
7.1.1. SAD and SPD Setup ..................................18
8. Acknowledgements ...............................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Suggested SCTP TML Channel Work Implementation .......21
A.1. SCTP TML Channel Initialization ...........................21
A.2. Channel Work Scheduling ...................................21
A.2.1. FE Channel Work Scheduling ............................21
A.2.2. CE Channel Work Scheduling ............................22
A.3. SCTP TML Channel Termination ..............................23
A.4. SCTP TML NE-Level Channel Scheduling ......................23
Appendix B. Suggested Service Interface ..........................24
B.1. TML Bootstrapping .........................................24
B.2. TML Shutdown ..............................................26
B.3. TML Sending and Receiving .................................27
The ForCES (Forwarding and Control Element Separation) working group in the IETF defines the architecture and protocol for separation of control elements (CEs) and forwarding elements (FEs) in network elements (NEs) such as routers. [RFC3654] and [RFC3746], respectively, define architectural and protocol requirements for the communication between CEs and FEs. The ForCES protocol layer specification [RFC5810] describes the protocol semantics and workings. The ForCES protocol layer operates on top of an inter-connect hiding layer known as the TML. The relationship is illustrated in Figure 1.
IETFの力（転送および制御要素分離）ワーキンググループは、ルーターなどのネットワーク要素（NES）の制御要素（CES）と転送要素（FE）の分離のアーキテクチャとプロトコルを定義します。それぞれ[RFC3654]および[RFC3746]は、CESとFES間の通信のアーキテクチャおよびプロトコル要件を定義します。力プロトコル層仕様[RFC5810]は、プロトコルセマンティクスとワーキングを説明しています。Force Protocol層は、TMLとして知られる相互接続の隠し層の上で動作します。関係を図1に示します。
This document defines the SCTP-based TML for the ForCES protocol layer. It also addresses all the requirements for the TML including security, reliability, and etc., as defined in [RFC5810].
このドキュメントでは、Force Protocol層のSCTPベースのTMLを定義します。また、[RFC5810]で定義されているように、セキュリティ、信頼性などを含むTMLのすべての要件にも対応しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following definitions are taken from [RFC3654] and [RFC3746]:
次の定義は[RFC3654]および[RFC3746]から取得されます。
LFB: Logical Functional Block. A template that represents a fine-grained, logically separate aspect of FE processing.
LFB：論理機能ブロック。FE処理の細粒で論理的に分離された側面を表すテンプレート。
ForCES Protocol: The protocol used at the Fp reference point in the ForCES Framework in [RFC3746].
力プロトコル：[RFC3746]の力フレームワークのFP基準点で使用されるプロトコル。
ForCES PL: ForCES Protocol Layer. A layer in the ForCES architecture that embodies the ForCES protocol and the state transfer mechanisms as defined in [RFC5810].
力PL：力プロトコル層。[RFC5810]で定義されているように、力プロトコルと状態転送メカニズムを具体化する力アーキテクチャの層。
ForCES TML: ForCES Protocol Transport Mapping Layer. 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 SCTP, IP, TCP, UDP, ATM, Ethernet, etc.), and how to achieve and implement reliability, security, etc.
力TML：力プロトコル輸送マッピングレイヤー。プロトコルメッセージの輸送の問題に特に対処するForceプロトコルアーキテクチャのレイヤーは、プロトコルメッセージがさまざまなトランスポートメディア（SCTP、TCP、UDP、ATM、イーサネットなどなど）、および達成方法などのさまざまなトランスポートメディア（信頼性、セキュリティなどを実装します。
The reader is referred to the Framework document [RFC3746], and in particular Sections 3 and 4, for an architectural overview and explanation of where and how the ForCES protocol fits in.
読者は、構造の概要と、力のプロトコルがどこでどのように適合するかについてのアーキテクチャの概要と説明について、フレームワークドキュメント[RFC3746]、特にセクション3および4を参照します。
There is some content overlap between the ForCES protocol specification [RFC5810] and this section (Section 3) in order to provide basic context to the reader of this document.
このドキュメントの読者に基本的なコンテキストを提供するために、フォースプロトコル仕様[RFC5810]とこのセクション（セクション3）の間には、いくつかのコンテンツの重複があります。
The ForCES protocol layering constitutes two pieces, the PL and TML. This is depicted in Figure 1.
力プロトコル層は、PLとTMLの2つのピースを構成します。これを図1に示します。
+----------------------------------------------+
| CE PL |
+----------------------------------------------+
| CE TML |
+----------------------------------------------+
^
|
ForCES PL |messages
|
v
+-----------------------------------------------+
| FE TML |
+-----------------------------------------------+
| FE PL |
+-----------------------------------------------+
Figure 1: Message Exchange between CE and FE to Establish an NE Association
図1：NE関連を確立するためのCEとFEの間のメッセージ交換
The PL is in charge of the ForCES protocol. Its semantics and message layout are defined in [RFC5810]. The TML is necessary to connect two ForCES endpoints as shown in Figure 1.
PLは、力プロトコルを担当しています。そのセマンティクスとメッセージレイアウトは[RFC5810]で定義されています。図1に示すように、TMLは2つの力のエンドポイントを接続するために必要です。
Both the PL and TML are standardized by the IETF. While only one PL is defined, different TMLs are expected to be standardized. The TML at each of the nodes (CE and FE) is expected to be of the same definition in order to inter-operate.
PLとTMLの両方がIETFによって標準化されています。1つのPLのみが定義されていますが、異なるTMLが標準化されると予想されます。各ノード（CEおよびFE）のTMLは、操作するために同じ定義であると予想されます。
When transmitting from a ForCES endpoint, the PL delivers its messages to the TML. The TML then delivers the PL message to the destination TML(s).
力のエンドポイントから送信するとき、PLはそのメッセージをTMLに届けます。TMLは、PLメッセージを宛先TMLに配信します。
On reception of a message, the TML delivers the message to its destination PL (as described in the ForCES header).
メッセージを受信すると、TMLはメッセージを宛先PLに配信します（Force Headerに記載されているように）。
The PL is common to all implementations of ForCES and is standardized by the IETF [RFC5810]. The PL is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations.
PLは力のすべての実装に共通しており、IETF [RFC5810]によって標準化されています。PLは、FeまたはCEをNEに関連付ける責任があります。また、そのような関連性を取り壊す責任があります。
An FE may use the PL to asynchronously send packets to the CE. The FE may redirect various control protocol packets (e.g., OSPF, etc.) to the CE via the PL (from outside the NE). Additionally, the FE delivers various events that the CE has subscribed to via the PL [RFC5812].
FEはPLを使用して、CEにパケットを非同期的に送信する場合があります。FEは、さまざまな制御プロトコルパケット（OSPFなど）をPL（NEの外側から）を介してCEにリダイレクトする場合があります。さらに、FEは、CEがPL [RFC5812]を介してサブスクライブしたさまざまなイベントを提供します。
The CE and FE may interact synchronously via the PL. The CE issues status requests to the FE and receives responses via the PL. The CE also configures the components of the associated FE's LFBs using the PL [RFC5812].
CEとFEは、PLを介して同期的に相互作用する場合があります。CEはステータス要求をFEに発行し、PLを介して応答を受信します。CEは、PL [RFC5812]を使用して、関連するFEのLFBのコンポーネントを構成します。
The TML is responsible for the transport of the PL messages. [RFC5810], Section 5 defines the requirements that need to be met by a TML specification. The SCTP TML specified in this document meets all the requirements specified in [RFC5810], Section 5. Section 4.2.2 of this document describes how the TML requirements are met.
TMLは、PLメッセージの輸送を担当します。[RFC5810]、セクション5では、TML仕様で満たす必要がある要件を定義しています。このドキュメントで指定されたSCTP TMLは、[RFC5810]で指定されたすべての要件を満たしています。このドキュメントのセクション4.2.2については、TML要件の満たされた方法について説明します。
There are two interfaces to the PL and TML. The specification of these interfaces is out of scope for this document, but the interfaces are introduced to show how they fit into the architecture and summarize the function provided at the interfaces. The first interface is between the PL and TML and the other is the CE Manager (CEM)/FE Manager (FEM) [RFC3746] interface to both the PL and TML. Both interfaces are shown in Figure 2.
PLとTMLには2つのインターフェイスがあります。これらのインターフェイスの仕様はこのドキュメントの範囲外ですが、インターフェイスは、それらがアーキテクチャにどのように適合するかを示し、インターフェイスで提供される関数を要約するために導入されています。最初のインターフェイスはPLとTMLの間で、もう1つはPLとTMLの両方へのCEマネージャー（CEM）/FEマネージャー（FEM）[RFC3746]インターフェースです。両方のインターフェイスを図2に示します。
+----------------------------+
| +----------------------+ |
| | | |
+---------+ | | PL | |
| | | +----------------------+ |
|FEM/CEM |<---->| ^ |
| | | | |
+---------+ | |TML API |
| | |
| V |
| +----------------------+ |
| | | |
| | TML | |
| | | |
| +----------------------+ |
+----------------------------+
Figure 2: The TML-PL Interface
図2：TML-PLインターフェイス
The CEM/FEM [RFC3746] interface is responsible for bootstrapping and parameterization of the TML. In its most basic form, the CEM/FEM interface takes the form of a simple static config file that is read on startup in the pre-association phase.
CEM/FEM [RFC3746]インターフェイスは、TMLのブートストラップとパラメーター化を担当します。最も基本的な形式では、CEM/FEMインターフェイスは、事前関連フェーズの起動時に読み取られる単純な静的設定ファイルの形式を取得します。
Appendix B discusses the service interfaces in more detail.
付録Bでは、サービスインターフェイスについてさらに詳しく説明します。
It is expected that it should be possible to use a configuration reference point, such as the FEM or the CEM, to configure the TML.
TMLを構成するために、FEMやCEMなどの構成基準点を使用することができるはずです。
Some of the configured parameters may include:
構成されたパラメーターの一部には、次のものが含まれます。
o PL ID
o pl id
o Connection Type and associated data. For example, if a TML uses IP/SCTP, then parameters such as SCTP ports and IP addresses need to be configured.
o 接続タイプと関連するデータ。たとえば、TMLがIP/SCTPを使用する場合、SCTPポートやIPアドレスなどのパラメーターを構成する必要があります。
o Number of transport connections
o 輸送接続の数
o Connection Capability, such as bandwidth, etc.
o 帯域幅などの接続機能。
o Allowed/Supported Connection Quality of Service (QoS) Policy (or Congestion Control Policy)
o 許可/サポートされている接続サービスの品質（QOS）ポリシー（または混雑制御ポリシー）
SCTP [RFC4960] is an end-to-end transport protocol that is equivalent to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP can do most of what UDP, TCP, or DCCP can achieve. SCTP as can also do most of what a combination of the other transport protocols can achieve (e.g., TCP and DCCP or TCP and UDP).
SCTP [RFC4960]は、多くの面でTCP、UDP、またはDCCPに相当するエンドツーエンドの輸送プロトコルです。いくつかの例外を除いて、SCTPはUDP、TCP、またはDCCPが達成できることのほとんどを実行できます。SCTPは、他の輸送プロトコルの組み合わせのほとんどを達成できるもののほとんどを実行できます（例：TCPおよびDCCPまたはTCPおよびUDP）。
Like TCP, it provides ordered, reliable, connection-oriented, flow-controlled, congestion-controlled data exchange. Unlike TCP, it does not provide byte streaming and instead provides message boundaries.
TCPと同様に、順序付けられた、信頼性が高く、接続指向の、フロー制御された渋滞制御データ交換を提供します。TCPとは異なり、バイトストリーミングを提供せず、代わりにメッセージの境界を提供します。
Like UDP, it can provide unreliable, unordered data exchange. Unlike UDP, it does not provide multicast support
UDPと同様に、信頼できない、順序付けられていないデータ交換を提供できます。UDPとは異なり、マルチキャストサポートは提供されません
Like DCCP, it can provide unreliable, ordered, congestion controlled, connection-oriented data exchange.
DCCPと同様に、信頼性の低い、順序付けられた、混雑制御された接続指向のデータ交換を提供できます。
SCTP also provides other services that none of the three transport protocols mentioned above provide that we found attractive. These include:
SCTPは、上記の3つの輸送プロトコルのいずれも、魅力的だと感じた他のサービスを提供しています。これらには以下が含まれます：
o Multi-homing
o マルチホミング
o Runtime IP address binding
o ランタイムIPアドレスバインディング
o A range of reliability shades with congestion control
o 混雑制御を備えたさまざまな信頼性シェード
o Built-in heartbeats
o 組み込みのハートビート
o Multi-streaming
o マルチストリーミング
o Message boundaries with reliability
o 信頼性を備えたメッセージ境界
o Improved SYN DOS protection
o Syn DOS保護の改善
o Simpler transport events
o よりシンプルな輸送イベント
o Simplified replicasting
o 簡素化された複製
SCTP has all the features required to provide a robust TML. As a transport that is all-encompassing, it negates the need for having multiple transport protocols in order to satisfy the TML requirements ([RFC5810], Section 5). As a result, it allows for simpler coding and therefore reduces a lot of the interoperability concerns.
SCTPには、堅牢なTMLを提供するために必要なすべての機能があります。包括的な輸送として、TML要件を満たすために複数の輸送プロトコルを持つ必要性を否定します（[RFC5810]、セクション5）。その結果、より単純なコーディングが可能になるため、相互運用性の多くの懸念を減らします。
SCTP is also very mature and widely used, making it a good choice for ubiquitous deployment.
SCTPも非常に成熟しており、広く使用されているため、ユビキタスな展開に適しています。
PL
+----------------------+
| |
+-----------+----------+
| TML API
TML |
+-----------+----------+
| | |
| +------+------+ |
| | TML core | |
| +-+----+----+-+ |
| | | | |
| SCTP socket API |
| | | | |
| | | | |
| +-+----+----+-+ |
| | SCTP | |
| +------+------+ |
| | |
| | |
| +------+------+ |
| | IP | |
| +-------------+ |
+----------------------+
Figure 3: The TML-SCTP Interface
図3：TML-SCTPインターフェイス
Figure 3 details the interfacing between the PL and SCTP TML and the internals of the SCTP TML. The core of the TML interacts on its northbound interface to the PL (utilizing the TML API). On the southbound interface, the TML core interfaces to the SCTP layer utilizing the standard socket interface [TSVWG-SCTPSOCKET]. There are three SCTP socket connections opened between any two PL endpoints (whether FE or CE).
図3は、PLとSCTP TMLとSCTP TMLの内部とのインターフェースを示しています。TMLのコアは、北行きのインターフェースでPLに相互作用します（TML APIを使用）。サウスバウンドインターフェイスでは、標準ソケットインターフェイス[TSVWG-SCTPSOCKSOCK]を使用して、SCTPレイヤーへのTMLコアインターフェイス。任意の2つのPLエンドポイント（FEまたはCEであろうと）の間に開かれた3つのSCTPソケット接続があります。
+--------------------+
| |
| TML core |
| |
+-+-------+--------+-+
| | |
| Med prio, |
| Semi-reliable |
| channel |
| | Low prio,
| | Unreliable
| | channel
| | |
^ ^ ^
| | |
Y Y Y
High prio,| | |
reliable | | |
channel | | |
Y Y Y
+-+--------+--------+-+
| |
| SCTP |
| |
+---------------------+
Figure 4: The TML-SCTP Channels
図4：TML-SCTPチャネル
Figure 4 details further the interfacing between the TML core and SCTP layers. There are three channels used to group and prioritize the work for different types of ForCES traffic. Each channel constitutes an SCTP socket interface that has different properties. It should be noted that all SCTP channels are congestion aware (and for that reason that detail is left out of the description of the three channels). SCTP ports 6704, 6705, and 6706 are used for the higher-, medium-, and lower-priority channels, respectively. SCTP Payload Protocol ID (PPID) values of 21, 22, and 23 are used for the higher-, medium-, and lower-priority channels, respectively.
図4は、TMLコアレイヤーとSCTPレイヤー間のインターフェースをさらに詳しく説明しています。さまざまなタイプの力トラフィックの作業をグループ化して優先順位を付けるために使用される3つのチャネルがあります。各チャネルは、異なるプロパティを持つSCTPソケットインターフェイスを構成します。すべてのSCTPチャネルは混雑を認識していることに注意する必要があります（そして、そのため、3つのチャネルの説明から詳細が除外されていることがあります）。SCTPポート6704、6705、および6706は、それぞれ高、中程度、および低優先度チャネルに使用されます。21、22、および23のSCTPペイロードプロトコルID（PPID）値は、それぞれより高い優先度チャネルに使用されます。
SCTP allows up to 64 K streams to be sent over a single socket interface. The authors initially envisioned using a single socket for all three channels (mapping a channel to an SCTP stream). This simplifies programming of the TML as well as conserves use of SCTP ports.
SCTPを使用すると、最大64 Kのストリームを単一のソケットインターフェイスで送信できます。著者は、最初に3つのチャネルすべてに単一のソケットを使用したことを想定していました（SCTPストリームにチャネルをマッピング）。これにより、TMLのプログラミングが簡素化され、SCTPポートの使用が節約されます。
Further analysis revealed head-of-line blocking issues with this initial approach. Lower-priority packets not needing reliable delivery could block higher-priority packets (needing reliable delivery) under congestion situations for an indeterminate period of time (depending on how many outstanding lower-priority packets are pending). For this reason, we elected to go with mapping each of the three channels to a different SCTP socket (instead of a different stream within a single socket).
さらなる分析により、この最初のアプローチに関する頭部のブロッキングの問題が明らかになりました。信頼性の高い配送を必要としない低優先度パケットは、不安定な期間の混雑状況下でより優先順位のパケット（信頼できる配達が必要）をブロックする可能性があります（優れた優位性の低いパケットの数に応じて）。このため、3つのチャネルのそれぞれを別のSCTPソケットにマッピングすることを選択しました（単一のソケット内の別のストリームの代わりに）。
The higher-priority (HP) channel uses a standard SCTP reliable socket on port 6704. SCTP PPID 21 is used for all messages on the HP channel. The HP channel is used for CE-solicited messages and their responses:
より優先順位（HP）チャネルは、ポート6704で標準のSCTP信頼できるソケットを使用します。SCTPPPID21は、HPチャネルのすべてのメッセージに使用されます。HPチャネルは、CE-Sollitedメッセージとその応答に使用されます。
1. ForCES configuration messages flowing from CE to FE and responses from the FE to CE.
1. CEからFEに流れる構成メッセージとFEからCEからの応答を強制します。
2. ForCES query messages flowing from CE to FE and responses from the FE to the CE.
2. Forceは、CEからFEに流れるメッセージとFEからCEへの応答をクエリします。
PL priorities 4-7 MUST be used for all PL messages using this channel. The following PL messages MUST use the HP channel for transport:
PL優先順位4-7は、このチャネルを使用してすべてのPLメッセージに使用する必要があります。次のPLメッセージは、輸送にHPチャネルを使用する必要があります。
o AssociationSetup (default priority: 7)
o AssociationSetup（デフォルトの優先度：7）
o AssociationSetupResponse (default priority: 7)
o AssociationSetupResponse（デフォルト優先度：7）
o AssociationTeardown (default priority: 7)
o AssociationTearDown（デフォルトの優先度：7）
o Config (default priority: 4)
o config（デフォルトの優先度：4）
o ConfigResponse (default priority: 4)
o configResponse（デフォルト優先度：4）
o Query (default priority: 4)
o クエリ（デフォルトの優先度：4）
o QueryResponse (default priority: 4)
o queryResponse（デフォルト優先度：4）
If PL priorities outside of the specified range priority (4-7), PPID, or PL message types other than the above are received on the HP channel, then the PL message MUST be dropped.
指定された範囲の優先順位（4-7）、PPID、またはPLメッセージタイプ以外のPLの優先順位がHPチャネルで受信される場合、PLメッセージをドロップする必要があります。
Although an implementation may choose different values from the defined range (4-7), it is RECOMMENDED that default priorities be used. A response to a ForCES message MUST contain the same priority as the request. For example, a config sent by the CE with priority 5 MUST have a config-response from the FE with priority 5.
実装では、定義された範囲（4-7）から異なる値を選択する場合がありますが、デフォルトの優先順位を使用することをお勧めします。フォースメッセージへの応答には、リクエストと同じ優先度が含まれている必要があります。たとえば、Priority 5を使用してCEから送信された構成には、Priority 5を備えたFEからの構成応答が必要です。
The medium-priority (MP) channel uses SCTP-PR on port 6705. SCTP PPID 22 MUST be used for all messages on the MP channel. Time limits on how long a message is valid are set on each outgoing message. This channel is used for events from the FE to the CE that are obsoleted over time. Events that are accumulative in nature and are recoverable by the CE (by issuing a query to the FE) can tolerate lost events and therefore should use this channel. For example, a generated event that carries the value of a counter that is monotonically incrementing is fit to use this channel.
中程度（MP）チャネルは、ポート6705でSCTP-PRを使用しています。SCTPPPID22は、MPチャネル上のすべてのメッセージに使用する必要があります。メッセージが有効な期間の時間制限は、各送信メッセージに設定されています。このチャネルは、時間の経過とともに廃止されたCEまでのイベントに使用されます。本質的に蓄積され、CEによって回復可能なイベント（FEにクエリを発行することにより）は、失われたイベントに耐えることができ、したがってこのチャネルを使用する必要があります。たとえば、単調に増加しているカウンターの値を運ぶ生成されたイベントは、このチャネルを使用するのに適しています。
PL priority 3 MUST be used for PL messages on this channel. The following PL messages MUST use the MP channel for transport:
PL優先度3は、このチャネルのPLメッセージに使用する必要があります。次のPLメッセージは、輸送にMPチャネルを使用する必要があります。
o Event Notification (default priority: 3)
o イベント通知（デフォルトの優先度：3）
If PL priorities outside of the specified priority, PPID, or PL message type other than the above are received on the MP channel, then the PL message MUST be dropped.
指定された優先順位以外のPL優先順位、上記以外のPPID、またはPLメッセージタイプがMPチャネルで受信される場合、PLメッセージをドロップする必要があります。
The lower-priority (LP) channel uses SCTP port 6706. SCTP PPID 23 is used for all messages on the LP channel. The LP channel also MUST use SCTP-PR with lower timeout values than the MP channel. The reason an unreliable channel is used for redirect messages is to allow the control protocol at both the CE and its peer-endpoint to take charge of how the end-to-end semantics of the said control protocol's operations. For example:
低優先度（LP）チャネルはSCTPポート6706を使用します。SCTPPPID23は、LPチャネルのすべてのメッセージに使用されます。LPチャネルは、MPチャネルよりも低いタイムアウト値でSCTP-PRも使用する必要があります。信頼性の低いチャネルがリダイレクトメッセージに使用される理由は、CEとそのピアエンドポイントの両方で制御プロトコルが、当該制御プロトコルの操作のエンドツーエンドのセマンティクスをどのように担当するかを許可するためです。例えば：
1. Some control protocols are reliable in nature, therefore making this channel reliable introduces an extra layer of reliability that could be harmful. So any end-to-end retransmits will happen remotely.
1. 一部のコントロールプロトコルは本質的に信頼性が高いため、このチャネルを信頼できるものにすると、有害になる可能性のある信頼性の余分な層が導入されます。したがって、エンドツーエンドの再送信はリモートで発生します。
2. Some control protocols may desire having obsolescence of messages over retransmissions; making this channel reliable contradicts that desire.
2. 一部のコントロールプロトコルは、再送信を介したメッセージの陳腐化があることを望む場合があります。このチャネルを信頼できるものにすることは、その欲求と矛盾しています。
Given ForCES PL heartbeats are traffic sensitive, sending them over the LP channel also makes sense. If the other end is not processing other channels, it will eventually get heartbeats; and if it is busy processing other channels, heartbeats will be obsoleted locally over time (and it does not matter if they did not make it).
力を考えると、心拍数はトラフィックに敏感であるため、LPチャネルに送信することも理にかなっています。もう一方の端が他のチャネルを処理していない場合、最終的には心拍が得られます。また、他のチャネルの処理に忙しい場合、ハートビートは時間の経過とともに局所的に廃止されます（そして、彼らがそれを作らなかったかどうかは関係ありません）。
PL priorities 1-2 MUST be used for PL messages on this channel. PL messages that MUST use the MP channel for transport are:
PL優先順位1-2は、このチャネルのPLメッセージに使用する必要があります。輸送にMPチャネルを使用する必要があるPLメッセージは次のとおりです。
o PacketRedirect (default priority: 2)
o packetRedirect（デフォルトの優先度：2）
o Heartbeat (default priority: 1)
o ハートビート（デフォルトの優先度：1）
If PL priorities outside of the specified priority range, PPID, or PL message types other than the above are received on the LP channel, then the PL message MUST be dropped.
指定された優先順位範囲外のPL優先順位、PPID、または上記以外のPLメッセージタイプがLPチャネルで受信される場合、PLメッセージをドロップする必要があります。
In processing the sending and receiving of the PL messages, the TML core uses strict priority work-conserving scheduling, as shown in Figure 5.
PLメッセージの送信と受信の処理において、TML Coreは、図5に示すように、厳密な優先度のワークコンサージスケジューリングを使用します。
This means that the HP messages are always processed first until there are no more left. The LP channel is processed only if channels that are a higher priority than itself have no messages left to process. This means that under a congestion situation, a higher-priority channel with sufficient messages that occupy the available bandwidth would starve lower-priority channel(s).
これは、HPメッセージが最初に最初に処理されることを意味します。LPチャネルは、それ自体よりも優先度が高いチャネルが処理するメッセージが残っていない場合にのみ処理されます。これは、混雑状況の下では、利用可能な帯域幅を占める十分なメッセージを備えた優先順位の高いチャネルが、より低い優先度チャネルを飢えさせることを意味します。
The design intent of the SCTP TML is to tie processing prioritization, as described in Section 4.2.1.1, and transport congestion control to provide implicit node congestion control. This is further detailed in Appendix A.2.
SCTP TMLの設計意図は、セクション4.2.1.1で説明されているように、処理の優先順位付けを結び、暗黙のノード輻輳制御を提供するために混雑制御を輸送することです。これについては、付録A.2でさらに詳しく説明しています。
It should be emphasized that the work scheduling prioritization scheme prescribed in this document is receiver-based processing. Fully arrived packets on any of the channels are a source of work whose output may result in transmitted packets. However, we have no control on the order in which the SCTP/OS/network chooses to send transmitted packets across and make them available to the receiver. This is a limitation that we try to ameliorate by our choice of channel properties, ForCES message grouping, and the tying of CE and FE work scheduling. While that helps us ameliorate some of these issues, it does not fully resolve all.
このドキュメントで規定されている作業スケジューリングの優先順位付けスキームは、受信機ベースの処理であることを強調する必要があります。チャンネルのいずれかに完全に到着したパケットは、出力が送信されたパケットをもたらす可能性のある作業源です。ただし、SCTP/OS/ネットワークが送信されたパケットを送信してレシーバーが利用できるようにする順序を制御できません。これは、チャネルプロパティの選択、強制メッセージグループ化、およびCEおよびFEの作業スケジューリングの結び付けによって改善しようとする制限です。それは私たちがこれらの問題のいくつかを改善するのに役立ちますが、それはすべてを完全に解決するものではありません。
From a ForCES perspective, we can tolerate some reordering. For example, if an FE transmits a config response (HP) followed by 10000 OSPF redirect packets (LP) and the CE gets 5 OSPF redirects (LP) first before the config response (HP), that is tolerable. What matters is the CE gets to processing the HP message soon (instead of sitting in long periods of time processing OSPF packets that would have happened if we use a single socket with three streams). This is particularly important in order to deal with node overload well, as discussed in Section 4.2.2.6.
力の観点からは、いくつかの並べ替えに耐えることができます。たとえば、FEが構成応答（HP）を伝達した後、10000 OSPFリダイレクトパケット（LP）が続き、CEは構成応答（HP）の最初に5つのOSPFリダイレクト（LP）を取得します。重要なのは、CEがHPメッセージをすぐに処理することになることです（3つのストリームを備えた単一のソケットを使用した場合に発生したOSPFパケットの長期にわたって座るのではなく）。セクション4.2.2.6で説明したように、これは特に重要です。
SCTP channel +----------+
Work available | DONE +---<--<--+
| +---+------+ |
Y ^
| +-->--+ +-->---+ |
+-->-->-+ | | | | |
| | | | | | ^
| ^ ^ v ^ v |
^ / \ | | | | |
| / \ | ^ | ^ ^
| / Is \ | / \ | / \ |
| / there \ | /Is \ | /Is \ |
^ / HP work \ ^ /there\ ^ /there\ ^
| \ ? / | /MP work\ | /LP work\ |
| \ / | \ ? / | \ ? / |
| \ / | \ / | \ / ^
| \ / ^ \ / ^ \ / |
| \ / | \ / | \ / |
^ Y-->-->-->+ Y-->-->-->+ Y->->->-+
| | NO | NO | NO
| | | |
| Y Y Y
| | YES | YES | YES
^ | | |
| Y Y Y
| +----+------+ +---|-------+ +----|------+
| |- process | |- process | |- process |
| | HP work | | MP work | | LP work |
| +------+----+ +-----+-----+ +-----+-----+
| | | |
^ Y Y Y
| | | |
| Y Y Y
+--<--<---+--<--<----<----+-----<---<-----+
Figure 5: SCTP TML Strict Priority Scheduling
図5：SCTP TML Strict Priority Scheduling
The following is a list of parameters needed for booting the TML. It is expected these parameters will be extracted via the FEM/CEM interface for each PL ID.
以下は、TMLの起動に必要なパラメーターのリストです。これらのパラメーターは、各PL IDのFEM/CEMインターフェイスを介して抽出されると予想されます。
1. The IP address(es) or a resolvable DNS/hostname(s) of the CE/FE.
1. CE/FEのIPアドレス（ES）または解決可能なDNS/ホスト名。
2. Whether or not to use IPsec. If IPsec is used, how to parameterize the different required ciphers, keys, etc., as described in Section 7.1
2. IPSECを使用するかどうか。IPSECが使用されている場合、セクション7.1で説明されているように、必要なさまざまな暗号、キーなどをパラメーター化する方法
3. The HP SCTP port, as discussed in Section 4.2.1.2. The default HP port value is 6704 (Section 6).
3. セクション4.2.1.2で説明したHP SCTPポート。デフォルトのHPポート値は6704（セクション6）です。
4. The MP SCTP port, as discussed in Section 4.2.1.3. The default MP port value is 6705 (Section 6).
4. セクション4.2.1.3で説明したMP SCTPポート。デフォルトのMPポート値は6705（セクション6）です。
5. The LP SCTP port, as discussed in Section 4.2.1.4. The default LP port value is 6706 (Section 6).
5. セクション4.2.1.4で説明したように、LP SCTPポート。デフォルトのLPポート値は6706（セクション6）です。
[RFC5810], Section 5 lists requirements that a TML needs to meet. This section describes how the SCTP TML satisfies those requirements.
[RFC5810]、セクション5には、TMLが満たす必要がある要件を示しています。このセクションでは、SCTP TMLがこれらの要件をどのように満たすかについて説明します。
As mentioned earlier, a shade of reliability ranges is possible in SCTP. Therefore, this requirement is met.
前述のように、SCTPでは信頼性の範囲の色合いが可能です。したがって、この要件は満たされます。
Congestion control is built into SCTP. Therefore, this requirement is met.
輻輳制御はSCTPに組み込まれています。したがって、この要件は満たされます。
By using three sockets in conjunction with the partial-reliability feature [RFC3758], both timeliness and prioritization requirements are addressed.
部分的な再利用可能性機能[RFC3758]と組み合わせて3つのソケットを使用することにより、適時性と優先順位付け要件の両方に対処します。
There are no extra headers required for SCTP to fulfill this requirement. SCTP can be told to replicast packets to multiple destinations. The TML implementation will need to translate PL addresses to a variety of unicast IP addresses in order to emulate multicast and broadcast PL addresses.
SCTPがこの要件を満たすために必要な追加のヘッダーはありません。SCTPは、複数の宛先にパケットを複製するように指示できます。TMLの実装では、PLアドレスをさまざまなユニキャストIPアドレスに変換して、マルチキャストおよびブロードキャストPLアドレスをエミュレートする必要があります。
Transport link resiliency is one of SCTP's strongest points. Failure detection and recovery is built in, as mentioned earlier.
輸送リンクの回復力は、SCTPの最も強力なポイントの1つです。前述のように、障害検出と回復が組み込まれています。
o The SCTP multi-homing feature is used to provide path diversity. Should one of the peer IP addresses become unreachable, the others are used without needing lower-layer convergence (routing, for example) or even the TML becoming aware.
o SCTPマルチホミング機能は、パスの多様性を提供するために使用されます。ピアIPアドレスの1つが到達不可能になった場合、他のアドレスは低層収束（ルーティングなど）を必要とせずに使用されたり、TMLが認識されたりすることなく使用されます。
o SCTP heartbeats and data transmission thresholds are used on a per-peer IP address to detect reachability faults. The faults could be a result of an unreachable address or peer, which may be caused by a variety of reasons, like interface, network, or endpoint failures. The cause of the fault is noted.
o SCTPハートビートとデータ送信のしきい値は、到達可能性の障害を検出するために、PEERごとのIPアドレスで使用されます。障害は、インターフェイス、ネットワーク、エンドポイントの障害など、さまざまな理由によって引き起こされる可能性のある到達不可能なアドレスまたはピアの結果である可能性があります。障害の原因が記載されています。
o With the ADDIP feature, one can migrate IP addresses to other nodes at runtime. This is not unlike the Virtual Router Redundancy Protocol (VRRP) [RFC5798] use. This feature is used in addition to multi-homing in a planned migration of activity from one FE/CE to another. In such a case, part of the provisioning recipe at the CE for replacing an FE involves migrating activity of one FE to another.
o ADDIP機能を使用すると、実行時にIPアドレスを他のノードに移行できます。これは、仮想ルーター冗長プロトコル（VRRP）[RFC5798]の使用とは異なります。この機能は、1つのFe/CEから別のFE/CEへのアクティビティの計画された移行に加えて、マルチホーミングに加えて使用されます。そのような場合、FEを交換するためのCEでのプロビジョニングレシピの一部には、1つのFEの移行活動が別のものに移行することが含まれます。
The architecture of this TML defines three separate channels, one per socket, to be used within any FE-CE setup. The work scheduling design for processing the TML channels (Section 4.2.1.5) is a strict priority. A fundamental desire of the strict prioritization is to ensure that more important processing work always gets node resources over less important work.
このTMLのアーキテクチャは、任意のFe-CEセットアップ内で使用される3つの別個のチャネル、1つのソケットごとに定義されています。TMLチャネルを処理するための作業スケジューリング設計（セクション4.2.1.5）は厳しい優先事項です。厳格な優先順位付けの基本的な欲求は、より重要な処理作業がより重要な作業よりも常にノードリソースを得ることを保証することです。
When a ForCES node CPU is overwhelmed because the incoming packet rate is higher than it can keep up with, the channel queues grow and transport congestion subsequently follows. By virtue of using SCTP, the congestion is propagated back to the source of the incoming packets and eventually alleviated.
力ノードCPUが圧倒されると、着信パケットレートが追いつくことができるよりも高いために圧倒されると、チャネルキューが増加し、その後混雑が続きます。SCTPを使用することにより、混雑は着信パケットのソースに戻され、最終的に緩和されます。
The HP channel work gets prioritized at the expense of the MP, which gets prioritized over LP channels. The preferential scheduling only kicks in when there is node overload regardless of whether there is transport congestion. As a result of the preferential work treatment, the ForCES node achieves a robust steady processing capacity. Refer to Appendix A.2 for details on scheduling.
HPチャネル作業は、LPチャネルよりも優先順位を付けるMPを犠牲にして優先順位を付けられます。優先スケジューリングは、輸送渋滞があるかどうかに関係なく、ノード過負荷がある場合にのみ開始されます。優先的な作業処理の結果、力ノードは堅牢な安定した処理能力を達成します。スケジューリングの詳細については、付録A.2を参照してください。
For an example of how the overload prevention works, consider a scenario where an overwhelming amount of redirected packets (from outside the NE) coming into the NE may overload the FE while it has outstanding config work from the CE. In such a case, the FE, while it is busy processing config requests from the CE, essentially ignores processing the redirect packets on the LP channel. If enough redirect packets accumulate, they are dropped either because the LP channel threshold is exceeded or because they are obsoleted. If on the other hand, the FE has successfully processed the higher-priority channels and their related work, then it can proceed and process the LP channel. So as demonstrated in this case, the TML ties transport congestion and node overload implicitly together.
過負荷予防がどのように機能するかの例については、CEからの優れた構成作業がある間に、NEに入る圧倒的な量のリダイレクトパケット（NEから）がFEに過負荷になる可能性があるシナリオを検討してください。そのような場合、FEはCEからの構成要求の処理に忙しい間、LPチャネルのリダイレクトパケットの処理を本質的に無視します。十分なリダイレクトパケットが蓄積すると、LPチャネルのしきい値を超えているか、廃止されているためにドロップされます。一方、FEがより優先順位チャネルとその関連作業を正常に処理した場合、LPチャネルを進めて処理できます。したがって、この場合に示されているように、TMLは混雑とノードの過負荷を暗黙的に輸送します。
The SCTP TML sets SCTP PPIDs to identify channels used as described in Section 4.2.1.1.
SCTP TMLは、セクション4.2.1.1で説明されているように使用されるチャネルを識別するためにSCTP PPIDを設定します。
There are two levels of TML channel work within an NE when a ForCES node (CE or FE) is connected to multiple other ForCES nodes:
力ノード（CEまたはFE）が複数の他の力ノードに接続されている場合、NE内には2つのレベルのTMLチャネル作業があります。
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose which of the peer nodes to process.
1. NE-LEVEL I/Oは、強制ノード（CEまたはFE）が処理するピアノードを選択する必要がある場合に動作します。
2. Node-level I/O work where a ForCES node, handles the three SCTP TML channels separately for each single ForCES endpoint.
2. ノードレベルのI/Oは、強制ノードが、単一の力のエンドポイントごとに3つのSCTP TMLチャネルを個別に処理する場合に動作します。
NE-level scheduling definition is left up to the implementation and is considered out of scope for this document. Appendix A.4 briefly discusses some constraints about which an implementer needs to worry.
NEレベルのスケジューリング定義は実装に委ねられ、このドキュメントの範囲外と見なされます。付録A.4は、実装者が心配する必要があるものについてのいくつかの制約について簡単に説明します。
This document provides suggestions on SCTP channel work implementation in Appendix A.
このドキュメントは、付録AのSCTPチャネル作業の実装に関する提案を提供します。
The FE SHOULD do channel connections to the CE in the order of incrementing priorities, i.e., LP socket first, followed by MP, and ending with HP socket connection. The CE, however, MUST NOT assume that there is ordering of socket connections from any FE.
FEは、優先順位を増やす順にCEへのチャネル接続を行う必要があります。つまり、最初にLPソケット、次にMPが続き、HPソケット接続で終了します。ただし、CEは、FEからソケット接続の順序があると仮定してはなりません。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], the following namespaces are defined in ForCES SCTP TML.
「RFCSでIANAの考慮事項セクションを作成するためのガイドライン」[RFC5226]に概説されているポリシーに従って、次の名前空間は力SCTP TMLで定義されています。
o SCTP port 6704 for the HP channel, 6705 for the MP channel, and 6706 for the LP channel.
o HPチャネルのSCTPポート6704、MPチャネルの6705、LPチャネルの6706。
o SCTP Payload Protocol ID (PPID) 21 for the HP channel (ForCES-HP), 22 for the MP channel (ForCES-MP), and 23 for the LP channel (ForCES-LP).
o HPチャネル（Force-HP）のSCTPペイロードプロトコルID（PPID）21、MPチャネル（Force-MP）の場合は22、LPチャネル（Force-LP）で23。
The SCTP TML provides the following security services to the PL:
SCTP TMLは、次のセキュリティサービスをPLに提供します。
o A mechanism to authenticate ForCES CEs and FEs at the transport level in order to prevent the participation of unauthorized CEs and unauthorized FEs in the control and data path processing of a ForCES NE.
o 力NEの制御およびデータパス処理に不正なCEと不正なFESの参加を防ぐために、輸送レベルでCESとFESを認証するメカニズム。
o A mechanism to ensure message authentication of PL data and headers transferred from the CE to FE (and vice versa) in order to prevent the injection of incorrect data into PL messages.
o PLメッセージへの誤ったデータの注入を防ぐために、CEからFe（および逆）に転送されたPLデータとヘッダーのメッセージ認証を確保するメカニズム。
o A mechanism to ensure the confidentiality of PL data and headers transferred from the CE to FE (and vice versa), in order to prevent disclosure of PL information transported via the TML.
o TMLを介して輸送されたPL情報の開示を防ぐために、PLデータとヘッダーの機密性をCEからFe（およびその逆）に保証するメカニズム。
Security choices provided by the TML are made by the operator and take effect during the pre-association phase of the ForCES protocol. An operator may choose to use all, some or none of the security services provided by the TML in a CE-FE connection.
TMLが提供するセキュリティの選択は、オペレーターによって行われ、力プロトコルの前協会段階で有効になります。オペレーターは、CE-FE接続でTMLが提供するセキュリティサービスをすべて、一部、またはまったく使用することを選択できます。
When operating under a secured environment, or for other operational concerns (in some cases performance issues) the operator may turn off all the security functions between CE and FE.
安全な環境の下で、または他の運用上の懸念（場合によってはパフォーマンスの問題）の場合、オペレーターはCEとFEの間のすべてのセキュリティ関数をオフにする場合があります。
IP Security Protocol (IPsec) [RFC4301] is used to provide needed security mechanisms.
IPセキュリティプロトコル（IPSEC）[RFC4301]は、必要なセキュリティメカニズムを提供するために使用されます。
IPsec is an IP-level security scheme transparent to the higher-layer applications and therefore can provide security for any transport layer protocol. This gives IPsec the advantage that it can be used to secure everything between the CE and FE without expecting the TML implementation to be aware of the details.
IPSECは、高レイヤーアプリケーションに透明なIPレベルのセキュリティスキームであるため、輸送層プロトコルのセキュリティを提供できます。これにより、IPSECは、TMLの実装が詳細を認識することを期待せずに、CEとFEの間のすべてを確保するために使用できるという利点を与えます。
The IPsec architecture is designed to provide message integrity and message confidentiality outlined in the TML security requirements [RFC5810]. Mutual authentication and key exchange protocol are provided by Internet Key Exchange (IKE) [RFC2409].
IPSECアーキテクチャは、TMLセキュリティ要件[RFC5810]で概説されているメッセージの整合性とメッセージの機密性を提供するように設計されています。相互認証とキー交換プロトコルは、インターネットキーエクスチェンジ（IKE）[RFC2409]によって提供されます。
A ForCES FE or CE MUST support the following:
力FeまたはCEは以下をサポートする必要があります。
o Internet Key Exchange (IKE)[RFC2409] with certificates for endpoint authentication.
o エンドポイント認証のための証明書を備えたインターネットキーエクスチェンジ（IKE）[RFC2409]。
o Transport Mode Encapsulating Security Payload (ESP) [RFC4303].
o セキュリティペイロードのカプセル化（ESP）[RFC4303]をカプセル化するトランスポートモード。
o HMAC-SHA1-96 [RFC2404] for message integrity protection
o メッセージ整合性保護のためのHMAC-SHA1-96 [RFC2404]
o AES-CBC with 128-bit keys [RFC3602] for message confidentiality.
o メッセージの機密性を得るために、128ビットキーを備えたAES-CBC [RFC3602]。
o Replay protection [RFC4301].
o リプレイ保護[RFC4301]。
A compliant implementation SHOULD provide operational means for configuring the CE and FE to negotiate other cipher suites and even use manual keying.
準拠した実装では、CEとFEを構成するための運用手段を提供して、他の暗号スイートを交渉し、手動キーイングを使用する必要があります。
To minimize the operational configuration, it is RECOMMENDED that only the IANA-issued SCTP protocol number (132) be used as a selector in the Security Policy Database (SPD) for ForCES. In such a case, only a single SPD and SAD entry is needed.
動作構成を最小限に抑えるには、IANA発行のSCTPプロトコル番号（132）のみを、力のセキュリティポリシーデータベース（SPD）のセレクターとして使用することをお勧めします。そのような場合、単一のSPDと悲しいエントリのみが必要です。
Setup MAY alternatively extend the above policy so that it uses the three SCTP TML port numbers as SPD selectors. But as noted above, this choice will require an increased number of SPD entries.
セットアップは、3つのSCTP TMLポート番号をSPDセレクターとして使用するように、上記のポリシーを代わりに拡張する場合があります。ただし、上記のように、この選択にはSPDエントリの数が増える必要があります。
In scenarios where multiple IP addresses are used within a single association, and there is desire to configure different policies on a per-IP address, then following [RFC3554] is RECOMMENDED.
単一のアソシエーション内で複数のIPアドレスが使用されているシナリオでは、PER-IPアドレスで異なるポリシーを構成することを望んでおり、[RFC3554]に従うことをお勧めします。
The authors would like to thank Joel Halpern, Michael Tuxen, Randy Stewart, Evangelos Haleplidis, Chuanhuang Li, Lars Eggert, Avshalom Houri, Adrian Farrel, Juergen Quittek, Magnus Westerlund, and Pasi Eronen for engaging us in discussions that have made this document better.
著者は、Joel Halpern、Michael Tuxen、Randy Stewart、Evangelos Haleplidis、Chuanhuang Li、Lars Eggert、Avshalom Houri、Adrian Farrel、Juergen Quittek、Magnus Westerlund、およびPasi Eronenに感謝します。。
Ross Callon was an excellent manager who persevered in providing us guidance and Joel Halpern was an excellent document shepherd without whom this document would have taken longer to publish.
ロスコロンは私たちにガイダンスを提供することに忍耐した優秀なマネージャーであり、ジョエル・ハルパーンは、この文書が公開するのにもっと時間がかからなかった優れた文書羊飼いでした。
[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月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554] Bellovin、S.、Ioannidis、J.、Keromytis、A。、およびR. Stewart、「IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用」、RFC 3554、2003年7月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケル、S。、グレン、R。、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPSECでのその使用」、RFC 3602、2003年9月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[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、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., HAAS, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810] Doria、A.、Ed。、Hadi Salim、J.、Ed。、Haas、R.、Ed。、Khosravi、H.、Ed。、Wang、W.、Ed。、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素分離（Force）プロトコル仕様」、RFC 5810、2010年3月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IP制御と転送の分離の要件」、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、「転送および制御要素分離（Forces）フレームワーク」、RFC 3746、2004年4月。
[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、「転送および制御要素分離（Force）転送要素モデル」、RFC 5812、2010年3月。
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798] Nadas、S.、ed。、「IPv4およびIPv6用の仮想ルーター冗長プロトコル（VRRP）バージョン3」、RFC 5798、2010年3月。
[TSVWG-SCTPSOCKET] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, March 2010.
[TSVWG-Sctpsocket] Stewart、R.、Poon、K.、Tuexen、M.、Yasevich、V。、およびP. Lei、「Sockets API拡張機能のSockets API拡張（SCTP）」、2010年3月の作業。
As mentioned in Section 5, there are two levels of TML channel work within an NE when a ForCES node (CE or FE) is connected to multiple other ForCES nodes:
セクション5で述べたように、力ノード（CEまたはFE）が複数の他の力ノードに接続されている場合、NE内にはTMLチャネル作業に2つのレベルがあります。
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose which of the peer nodes to process.
1. NE-LEVEL I/Oは、強制ノード（CEまたはFE）が処理するピアノードを選択する必要がある場合に動作します。
2. Node-level I/O work where a ForCES node, handles the three SCTP TML channels separately for each single ForCES endpoint.
2. ノードレベルのI/Oは、強制ノードが、単一の力のエンドポイントごとに3つのSCTP TMLチャネルを個別に処理する場合に動作します。
NE-level scheduling definition is left up to the implementation and is considered out of scope for this document. Appendix A.4 briefly discusses some constraints about which an implementer needs to worry.
NEレベルのスケジューリング定義は実装に委ねられ、このドキュメントの範囲外と見なされます。付録A.4は、実装者が心配する必要があるものについてのいくつかの制約について簡単に説明します。
This document, and in particular Appendix A.1, Appendix A.2, and Appendix A.3 discuss details of node-level I/O work.
このドキュメント、特に付録A.1、付録A.2、および付録A.3は、ノードレベルのI/O作業の詳細について説明します。
As discussed in Section 5, it is recommended that the FE SHOULD do socket connections to the CE in the order of incrementing priorities, i.e., LP socket first, followed by MP, and ending with HP socket connection. The CE, however, MUST NOT assume that there is ordering of socket connections from any FE. Appendix B.1 has more details on the expected initialization of SCTP channel work.
セクション5で説明したように、FEは、優先順位を増やす順に、つまりLPソケットを最初にMPに続き、HPソケット接続で終了する順にCEへのソケット接続を行うことをお勧めします。ただし、CEは、FEからソケット接続の順序があると仮定してはなりません。付録B.1には、SCTPチャネル作業の予想初期化に関する詳細があります。
This section provides high-level details of the scheduling view of the SCTP TML core (Section 4.2.1). A practical scheduler implementation takes care of many little details (such as timers, work quanta, etc.) not described in this document. It is left to the implementer to take care of those details.
このセクションでは、SCTP TMLコア（セクション4.2.1）のスケジューリングビューの高レベルの詳細を示します。実用的なスケジューラの実装では、このドキュメントでは説明されていない多くの小さな詳細（タイマー、ワーク量子など）が処理されます。これらの詳細の世話をすることは実装者に任されています。
The CE(s) and FE(s) are coupled together in the principles of the scheduling scheme described here to tie together node overload with transport congestion. The design intent is to provide the highest possible robust work throughput for the NE under any network or processing congestion.
CE（s）とFe（S）は、ここで説明するスケジューリングスキームの原則で結合され、ノードの過負荷を輸送渋滞と結び付けます。設計の意図は、ネットワークまたは処理渋滞の下で、NEに可能な限り最高の堅牢な作業スループットを提供することです。
The FE scheduling, in priority order, needs to I/O process:
優先順序でのFEスケジューリングは、I/Oプロセスを必要とします。
1. The HP channel I/O in the following priority order:
1. 次の優先順位のHPチャネルI/O：
1. Transmitting back to the CE any outstanding result of executed work via the HP channel transmit path.
1. HPチャネル送信パスを介して実行された作業の未解決の結果は、CEに戻ります。
2. Taking new incoming work from the CE that creates ForCES work to be executed by the FE.
2. FEによって実行されるために、力を作成するCEから新しい着信作業を受ける。
2. ForCES events that result in transmission of unsolicited ForCES packets to the CE via the MP channel.
2. MPチャネルを介してCEに未承諾の力パケットを送信することをもたらす力のイベント。
3. Incoming Redirect work in the form of control packets that come from the CE via LP channel. After redirect processing, these packets get sent out on external (to the NE) interface.
3. 着信は、LPチャネルを介してCEから来る制御パケットの形で作業をリダイレクトします。処理をリダイレクトした後、これらのパケットは外部（NE）インターフェイスに送信されます。
4. Incoming Redirect work in the form of control packets that come from other NEs via external (to the NE) interfaces. After some processing, such packets are sent to the CE.
4. 着信は、外部（NE）インターフェイスを介して他のNEから生じる制御パケットの形で作業をリダイレクトします。一部の処理の後、そのようなパケットはCEに送信されます。
It is worth emphasizing, at this point again, that the SCTP TML processes the channel work in strict priority. For example, as long as there are messages to send to the CE on the HP channel, they will be processed first until there are no more left before processing the next priority work (which is to read new messages on the HP channel incoming from the CE).
この時点で、SCTP TMLがチャネル作業を厳密に優先して処理することを強調する価値があります。たとえば、HPチャネルでCEに送信するメッセージがある限り、次の優先作業を処理する前に残りがなくなるまで最初に処理されます（これは、HPチャネルで新しいメッセージを読み取ることです。CE）。
The CE scheduling, in priority order, needs to deal with:
CEスケジューリングは、優先順序で、次のように対処する必要があります。
1. The HP channel I/O in the following priority order:
1. 次の優先順位のHPチャネルI/O：
1. Process incoming responses to requests of work it made to the FE(s).
1. FE（s）に対して行った作業の要求に対する着信応答を処理します。
2. Transmit any outstanding HP work it needs the FE(s) to complete.
2. 完了するためにFE（s）が必要な未解決のHP作業を送信します。
2. Incoming ForCES events from the FE(s) via the MP channel.
2. MPチャネルを介してFe（S）からの出来事はイベントを強制します。
3. Outgoing Redirect work in the form of control packets that get sent from the CE via LP channel destined to external (to the NE) interface on FE(s).
3. FE（S）の外部（NE）インターフェイスに運命づけられたLPチャネルを介してCEから送信される制御パケットの形での発信リダイレクト作業。
4. Incoming Redirect work in the form of control packets that come from other NEs via external interfaces (to the NE) on the FE(s).
4. 着信は、Fe（s）の外部インターフェイス（NE）を介して他のNEから生じる制御パケットの形で作業をリダイレクトします。
It is worth repeating, for emphasis, that the SCTP TML processes the channel work in strict priority. For example, if there are messages incoming from an FE on the HP channel, they will be processed first until there are no more left before processing the next priority work, which is to transmit any outstanding HP channel messages going to the FE.
強調するために、SCTP TMLがチャネルの動作を厳密に優先して処理することを繰り返す価値があります。たとえば、HPチャネルのFEから送信されるメッセージがある場合、次の優先作業を処理する前に残りがなくなるまで最初に処理されます。
Appendix B.2 describes a controlled disassociation of the FE from the NE.
付録B.2は、NEからのFeの制御された分離を説明しています。
It is also possible for connectivity to be lost between the FE and CE on one or more sockets. In cases where SCTP multi-homing features are used for path availability, the disconnection of a socket will only occur if all paths are unreachable; otherwise, SCTP will ensure reachability. In the situation of a total connectivity loss of even one SCTP socket, it is recommended that the FE and CE SHOULD assume a state equivalent to ForCES Association Teardown being issued and follow the sequence described in Appendix B.2.
また、1つ以上のソケットでFEとCEの間で接続性を失う可能性もあります。SCTPマルチホミング機能がパスの可用性に使用される場合、すべてのパスが到達できない場合にのみ、ソケットの切断が発生します。それ以外の場合、SCTPは到達可能性を確保します。1つのSCTPソケットの合計接続性損失の状況では、FEとCEは、Association Associationが発行されていると同等の状態を想定し、付録B.2に記載されているシーケンスに従うことをお勧めします。
A CE could also disconnect sockets to an FE to indicate an "emergency teardown". The "emergency teardown" may be necessary in cases when a CE needs to disconnect an FE but knows that an FE is busy processing a lot of outstanding commands (some of which the FE hasn't gotten around to processing, yet). By virtue of the CE closing the connections, the FE will immediately be asynchronously notified and will not have to process any outstanding commands from the CE.
CEは、ソケットをFEに切断して、「緊急分裂」を示すこともできます。CEがFEを切断する必要があるが、FEが多くの未解決のコマンドを処理するのに忙しい場合（FEがまだ処理していない）ことを知っている場合、「緊急分裂」が必要になる場合があります。CEが接続を閉じることにより、FEはすぐに非同期に通知され、CEからの未解決のコマンドを処理する必要はありません。
In handling NE-level I/O work, an implementation needs to worry about being both fair and robust across peer ForCES nodes.
NEレベルのI/O作業を処理する際に、実装は、ピアフォースノード全体で公正かつ堅牢であることを心配する必要があります。
Fairness is desired so that each peer node makes progress across the NE. For the sake of illustration, consider two FEs connected to a CE; whereas one FE has a few HP messages that need to be processed by the CE, another may have infinite HP messages. The scheduling scheme may decide to use a quota scheduling system to ensure that the second FE does not hog the CE cycles.
各ピアノードがNE全体で進歩するように、公平性が望まれます。説明のために、CEに接続された2つのFESを検討してください。1つのFEには、CEによって処理する必要があるいくつかのHPメッセージがありますが、別のFEには無限のHPメッセージがある場合があります。スケジューリングスキームは、クォータスケジューリングシステムを使用して、2番目のFEがCEサイクルをホグしないようにすることを決定する場合があります。
Robustness is desired so that the NE does not succumb to a Denial-of-Service (DoS) attack from hostile entities and always achieves a maximum stable workload processing level. For the sake of illustration, consider again two FEs connected to a CE. Consider FE1 as having a large number of HP and MP messages and FE2 having a large number of MP and LP messages. The scheduling scheme needs to ensure that while FE1 always gets its messages processed, at some point we allow FE2 messages to be processed. A promotion and preemption-based scheduling could be used by the CE to resolve this issue.
NEが敵対的なエンティティからのサービス拒否（DOS）攻撃に屈しないように、堅牢性が望まれ、常に最大の安定したワークロード処理レベルを達成します。説明のために、CEに接続された2つのFESをもう一度検討してください。FE1は、多数のHPおよびMPメッセージがあり、FE2が多数のMPおよびLPメッセージを持っていると考えてください。スケジューリングスキームでは、FE1が常にメッセージを処理している間、ある時点でFE2メッセージを処理できるようにする必要があります。この問題を解決するために、CEがプロモーションと先制ベースのスケジューリングを使用できます。
This section outlines a high-level service interface between FEM/CEM and TML, the PL and TML, and between local and remote TMLs. The intent of this interface discussion is to provide general guidelines. The implementer is expected to care of details and even follow a different approach if needed.
このセクションでは、FEM/CEMとTML、PLとTML、およびローカルおよびリモートTMLの間の高レベルのサービスインターフェイスの概要を説明します。このインターフェイスディスカッションの意図は、一般的なガイドラインを提供することです。実装者は、詳細を気にし、必要に応じて別のアプローチに従うことさえ期待されます。
The theory of operation for the PL-TML service is as follows:
PL-TMLサービスの動作理論は次のとおりです。
1. The PL starts up and bootstraps the TML. The end result of a successful TML bootstrap is that the CE TML and the FE TML connect to each other at the transport level.
1. PLは起動し、TMLをブートストラップします。成功したTMLブートストラップの最終結果は、CE TMLとFE TMLが輸送レベルで相互に接続することです。
2. Transmission and reception of the PL messages commences after a successful TML bootstrap. The PL uses send and receive PL-TML interfaces to communicate to its peers. The TML is agnostic to the nature of the messages being sent or received. The first message exchanges that happen are to establish ForCES association. Subsequent messages may be either unsolicited events from the FE PL, control message redirects to/from the CE to/from FE, or configuration from the CE to the FE, and their responses flowing from the FE to the CE.
2. PLメッセージの送信と受信は、TMLブートストラップが成功した後に始まります。PLは、送信および受信PL-TMLインターフェイスを使用して、同僚と通信します。TMLは、送信または受信されるメッセージの性質に不可知論されます。発生する最初のメッセージ交換は、軍隊協会を確立することです。後続のメッセージは、FE PLからの未承諾イベント、CEからFEへの、およびCEからの構成へのリダイレクト、CEからFEへの構成、およびFEからCEへの応答のいずれかです。
3. The PL does a shutdown of the TML after terminating ForCES association.
3. PLは、部隊協会を終了した後、TMLのシャットダウンを行います。
Figure 6 illustrates a flow for the TML bootstrapped by the PL.
図6は、PLによってブートストラップされたTMLのフローを示しています。
When the PL starts up (possibly after some internal initialization), it boots up the TML. The TML first interacts with the FEM/CEM and acquires the necessary TML parameterization (Section 4.2.1.6). Next, the TML uses the information it retrieved from the FEM/CEM interface to initialize itself.
PLが起動すると（おそらく内部初期化の後）、TMLを起動します。TMLは最初にFEM/CEMと相互作用し、必要なTMLパラメーター化を取得します（セクション4.2.1.6）。次に、TMLは、FEM/CEMインターフェイスから取得した情報を使用して、初期化します。
The TML on the FE proceeds to connect the three channels to the CE. The socket interface is used for each of the channels. The TML continues to re-try the connections to the CE until all three channels are connected. It is advisable that the number of connection retry attempts and the time between each retry is also configurable via the FEM. On failure to connect one or more channels, and after the configured number of retry thresholds is exceeded, the TML will return an appropriate failure indicator to the PL. On success (as shown in Figure 6), a success indication is presented to the PL.
FEのTMLは、3つのチャネルをCEに接続するようになります。ソケットインターフェイスは、各チャネルに使用されます。TMLは、3つのチャネルすべてが接続されるまでCEへの接続を再試行し続けます。接続の再試行回数と各再試行の間の時間も、FEMを介して構成できることをお勧めします。1つ以上のチャネルを接続できず、構成された再生しきい値の数を超えた後、TMLは適切な障害インジケーターをPLに返します。成功（図6に示すように）については、PLに成功指示が提示されます。
FE PL FE TML FEM CEM CE TML CE PL
| | | | | |
| | | | | Bootup |
| | | | |<-------------------|
| Bootup | | | | |
|----------->| | |get CEM info| |
| |get FEM info | |<-----------| |
| |------------>| ~ ~ |
| ~ ~ |----------->| |
| |<------------| | |
| | |-initialize TML |
| | |-create the 3 chans.|
| | | to listen to FEs |
| | | |
| |-initialize TML |Bootup success |
| |-create the 3 chans. locally |------------------->|
| |-connect 3 chans. remotely | |
| |------------------------------>| |
| ~ ~ - FE TML connected ~
| ~ ~ - FE TML info init ~
| | channels connected | |
| |<------------------------------| |
| Bootup | | |
| succeeded | | |
|<-----------| | |
| | | |
Figure 6: SCTP TML Bootstrapping
図6：SCTP TMLブートストラップ
On the CE, things are slightly different. After initializing from the CEM, the TML on the CE side proceeds to initialize the three channels to listen to remote connections from the FEs. The success or failure indication is passed on to the CE PL (in the same manner as was done in the FE).
CEでは、物事は少し異なります。CEMから初期化した後、CE側のTMLは3つのチャネルを初期化してFESからのリモート接続をリッスンします。成功または失敗の兆候は、CE PLに渡されます（FEで行われたのと同じ方法で）。
Post bootup, the CE TML waits for connections from the FEs. Upon a successful connection by an FE, the CE TML level keeps track of the transport-level details of the FE. Note, at this stage only transport-level connection has been established; ForCES-level association follows using send/receive PL-TML interfaces (refer to Appendix B.3 and Figure 8).
ブートアップ後、CE TMLはFESからの接続を待ちます。FEによる接続が成功すると、CE TMLレベルはFEの輸送レベルの詳細を追跡します。この段階では、輸送レベルの接続のみが確立されていることに注意してください。フォースレベルの関連付けは、送信/受信PL-TMLインターフェイスを使用して続きます（付録B.3および図8を参照）。
Figure 7 shows an example of an FE shutting down the TML. It is assumed at this point that the ForCES Association Teardown has been issued by the CE. It should also be noted that different implementations may have different procedures for cleaning up state, etc.
図7は、TMLをシャットダウンしたFEの例を示しています。この時点で、部隊協会の分裂がCEによって発行されたと想定されています。また、異なる実装には、状態をクリーンアップするためのさまざまな手順がある場合があることにも注意してください。
When the FE PL issues a shutdown to its TML for a specific PL ID, the TML releases all the channel connections to the CE. This is achieved by closing the sockets used to communicate to the CE. This results in the stack sending a SCTP shutdown, which is received on the CE.
FE PLが特定のPL IDに対してTMLのシャットダウンを発行すると、TMLはCEへのすべてのチャネル接続を解放します。これは、CEと通信するために使用されるソケットを閉じることによって達成されます。これにより、CEで受信されるSCTPシャットダウンをスタックが送信します。
FE PL FE TML CE TML CE PL
| | | |
| Shutdown | | |
|----------->| | |
| |-disconnect 3 chans. | |
| |-SCTP level shutdown | |
| |------------------------>| |
| | | |
| | |TML detects shutdown|
| | |-FE TML info cleanup|
| | |-optionally tell PL |
| | |------------------->|
| | | |
| |- clean up any state of | |
| |-channels disconnected | |
| |<------------------------| |
| |-SCTP shutdown ACK | |
| | | |
| Shutdown | | |
| succeeded | | |
|<-----------| | |
| | | |
Figure 7: FE Shutting Down
図7：FEシャットダウン
On the CE side, a TML disconnection would result in possible cleanup of the FE state. Optionally, depending on the implementation, there may be need to inform the PL about the TML disconnection. The CE-stack-level SCTP sends an acknowledgement to the FE TML in response to the earlier SCTP shutdown.
CE側では、TMLの切断により、Fe状態のクリーンアップが可能になります。オプションでは、実装に応じて、TMLの切断についてPLに通知する必要がある場合があります。CEスタックレベルのSCTPは、以前のSCTPシャットダウンに応じて、FE TMLに確認を送信します。
The TML should be agnostic to the content of the PL messages, or their operations. The PL should provide enough information to the TML for it to assign an appropriate priority and loss behavior to the message. Figure 8 shows an example of a message exchange originated at the FE and sent to the CE (such as a ForCES association message), which illustrates all the necessary service interfaces for sending and receiving.
TMLは、PLメッセージのコンテンツまたはその操作に不可知論される必要があります。PLは、適切な優先度と損失の動作をメッセージに割り当てるために、TMLに十分な情報を提供する必要があります。図8は、FEで発信され、CE（Forces Associationメッセージなど）に送信されたメッセージ交換の例を示しています。これは、送信と受信に必要なすべてのサービスインターフェイスを示しています。
When the FE PL sends a message to the TML, the TML is expected to pick one of HP/MP/LP channels and send out the ForCES message.
Fe PLがTMLにメッセージを送信すると、TMLはHP/MP/LPチャネルのいずれかを選択してForceメッセージを送信することが期待されます。
FE PL FE TML CE TML CE PL
| | | |
|PL send | | |
|----------->| | |
| | | |
| | | |
| |-pick channel | |
| |-TML Send | |
| |------------->| |
| | | |
| | |-TML Receive on chan. |
| | |- mux to PL/PL recv |
| | |--------------------->|
| | | ~
| | | ~ PL Process
| | | ~
| | | PL send |
| | |<---------------------|
| | |-pick chan to send on |
| | |-TML send |
| |<-------------| |
| |-TML Receive | |
| |-mux to PL | |
| PL Recv | | |
|<---------- | | |
| | | |
Figure 8: Send and Recv Flow
図8：送信およびRecvフロー
When the CE TML receives the ForCES message on the channel on which it was sent, it demultiplexes the message to the CE PL.
CE TMLが送信されたチャネル上のフォースメッセージを受信すると、メッセージがCE PLにメッセージを非難します。
The CE PL, after some processing (in this example, dealing with the FE's association), sends the TML the response. As in the case of FE PL, the CE TML picks the channel to send on before sending.
CE PLは、一部の処理の後（この例ではFEの関連付けを扱っています）、TMLに応答を送信します。Fe PLの場合のように、CE TMLは送信する前に送信するチャンネルを選択します。
The processing of the ForCES message upon arrival at the FE TML and delivery to the FE PL is similar to the CE side equivalent as shown above in Appendix B.3.
上記の付録B.に示すように、Fe TMLに到着し、Fe PLへの配信がCE側に類似していることに似ています。
Authors' Addresses
著者のアドレス
Jamal Hadi Salim Mojatatu Networks Ottawa, Ontario Canada
Jamal Hadi Salim Mojatatu Networks Ottawa、オンタリオカナダ
EMail: hadi@mojatatu.com
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
Kentaro Ogawa NTT Corporation 3-9-11 Midori-Cho Musashino-Shi、東京180-8585日本
EMail: ogawa.kentaro@lab.ntt.co.jp