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
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がすべてで必要とされる要件、強制的にプロトコルを扱う方法を説明します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]、それぞれ、CEとFEとの間の通信のためのアーキテクチャ及びプロトコルの要件を定義します。 ForCESプロトコル層の仕様[RFC5810]は、プロトコルのセマンティクスと働きを説明しています。 ForCESプロトコル層は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].
この文書は、のForCESプロトコル層のための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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
ForCESプロトコル：[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].
ForCES PL：のForCESプロトコル層。 [RFC5810]で定義されるのForCESプロトコルおよび状態転送メカニズムを具現のForCESアーキテクチャの層。
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.
ForCES TML：のForCESプロトコル交通マッピング・レイヤー。具体的には、プロトコルメッセージをどのように達成するために、及び（SCTP、IP、TCP、UDP、ATM、イーサネット（登録商標）、等のような）異なる輸送培地にマッピングする方法としてプロトコルメッセージ輸送の問題を、解決のForCESプロトコルアーキテクチャのレイヤそして、など、信頼性、セキュリティを実装
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.
読者は、どのようのForCESプロトコルに収まるのアーキテクチャの概要と説明のために、フレームワーク文書[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.
ForCESプロトコルレイヤリングは、二枚、PLおよびTMLを構成しています。これは、図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：CEとFE間のメッセージ交換NEアソシエーションを確立します
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はのForCESプロトコルを担当しています。その意味とメッセージのレイアウトは[RFC5810]で定義されています。 TMLは、図1に示すように、二つの力のエンドポイントを接続する必要があります。
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によって標準化されています。一つだけPLが定義されている間、別のTMLsは標準化されることが期待されます。ノード（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).
ForCESエンドポイントから送信する場合、PLはTMLにそのメッセージを配信します。 TMLは宛先TML（複数可）にPLメッセージを配信します。
On reception of a message, the TML delivers the message to its destination PL (as described in the ForCES header).
メッセージの受信時に、TMLは、その宛先PL（のForCESヘッダに記載されるような）にメッセージを配信します。
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は、NEにFEまたはCEを関連付けるための責任があります。また、このような団体を解体する責任があります。
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は、非同期CEにパケットを送信するためにPLを使用することができます。 FEは（NE外部から）PLを介してCEへの様々な制御プロトコル・パケット（例えば、OSPFなど）をリダイレクトすることができます。また、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のLFBsの構成要素を構成します。
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]で指定されたすべての要件を満たし、本書の第5節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の間であり、他方は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
PL ID O
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が達成できることのほとんどを行うことができます。また、他のトランスポートプロトコルの組み合わせは、（例えば、TCPおよびDCCPまたはTCPおよびUDP）を達成できるものの大半を行うことができますようにSCTP。
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簡体replicasting
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-SCTPSOCKET]を利用SCTP層にTMLコアインターフェイス。任意の二つの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は、それぞれ、higher-、中、及び低優先順位のチャネルのために使用されます。 21、22、及び23のSCTPペイロードプロトコルID（PPID）値は、それぞれ、higher-、中、及び低優先順位チャネルのために使用されます。
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).
さらなる分析は、この最初のアプローチでヘッドオブラインブロッキングの問題を明らかにしました。信頼できる配信を必要としない低優先度パケットは、（未処理の低い優先度のパケットが保留されている何に依存して）時間の不確定期間の混雑状況下（信頼できる配信を必要とする）より高い優先度のパケットをブロックし得ます。このような理由から、我々は異なるSCTPソケット（の代わりに、単一のソケット内の異なるストリーム）に3つのチャネルのそれぞれをマッピングして行くことを選択しました。
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）チャネルは、HPのチャネル上のすべてのメッセージに使用されているポート6704 SCTP PPID 21上の標準SCTP信頼性の高いソケットを使用しています。 HPチャネルは、CE-勧誘メッセージとその応答のために使用されます。
1. ForCES configuration messages flowing from CE to FE and responses from the FE to CE.
CEからFEとCEのFEからの応答に流れる1のForCES構成メッセージ。
2. ForCES query messages flowing from CE to FE and responses from the FE to the CE.
CEからFEとCEのFEからの応答に流れる2のForCESクエリーメッセージ。
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コンフィグ（デフォルトの優先順位：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）の外部PL優先順位は、上記以外のPPID、または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）とは異なる値を選択することができるが、デフォルトの優先順位を使用することを推奨されています。 ForCESメッセージに対する応答が要求と同じ優先順位を含まなければなりません。例えば、優先5とCEによって送信された設定は、優先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 PPID 22にSCTP-PRを使用するMPのチャネル上のすべてのメッセージのために使用しなければなりません。メッセージは、各送信メッセージに有効に設定されているどのくらいの時間制限。このチャンネルは、時間をかけて廃止されているCEのFEからのイベントのために使用されています。自然の中で蓄積され、（FEにクエリを発行することによって）CEによって回復されるイベントは、失われたイベントに耐えることができますので、このチャネルを使用する必要があります。例えば、単調にインクリメントされるカウンタの値を搬送する生成されたイベントは、このチャネルを使用するように適合しています。
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.
上記以外の指定された優先度、PPID、またはPLメッセージタイプの外部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. SCTP PPID 23は、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).
ForCES PLハートビートを考える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.
図5に示すように、送信及びPLメッセージの送受信を処理する際に、TMLコアは、厳密な優先作業保存スケジューリングを使用します。
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 /ネットワークを介して送信パケットを送信し、受信機にそれらを利用可能にすることを選択した順序に制御することはできません。これは、我々は、チャネルのプロパティ、のForCESメッセージのグループ化、および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.
ForCESの観点から、我々はいくつかの並べ替えを許容することができます。最初の設定応答（HP）の前FEパケット（LP）をリダイレクト10000 OSPF続い設定応答（HP）を送信し、CEは5 OSPFリダイレクト（LP）を取得する場合、例えば、それが許容されます。どのような事項CEは、（代わりに、我々は3つのストリームを持つ単一のソケットを使用する場合に起こっていたOSPFパケットの処理時間の長い期間に座っての）すぐにHPのメッセージを処理することになっています。これは、セクション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完全優先スケジューリング
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インターフェースを介して抽出されると予想されます。
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. HP SCTPポートに、4.2.1.2項で説明したように。デフォルトの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.2.1.3項で説明したように4 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. LPのSCTPポート、セクション4.2.1.4で論じたように。デフォルト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]、TMLを満たすために必要第5章リストの要件。このセクションでは、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は、複数の宛先にパケットをreplicastするように指示することができます。 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の最強のポイントの一つです。先に述べたように、障害の検出と回復は、内蔵されています。
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ハートビートデータ送信しきい値は、到達可能性の障害を検出するごとにピア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.
ADDIP機能ではO、1は、実行時に他のノードにIPアドレスを移行することができます。これは、仮想ルータ冗長プロトコル（VRRP）[RFC5798]の使用とは違っていません。この機能は、別のFE / CEの活性の予定移動マルチホーミングに加えて使用されています。このような場合に、FEを交換するためのCEでプロビジョニング・レシピの一部は、別の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つの別個のチャネル、ソケットあたりのいずれかを、定義します。 （セクション4.2.1.5）TMLチャネルを処理するための作業計画の設計は、厳密な優先事項です。厳格な優先順位付けの基本的な欲求がより重要な処理作業が常にそれほど重要な仕事上のノードのリソースを取得することを確認することです。
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.
着信パケットのレートは、それはついていくことができるよりも高いためのForCESノード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、を犠牲にして優先順位を付けます。ノードの過負荷に関係なく、トランスポート輻輳があるかどうかがある場合、優先スケジューリングだけでキック。優先ワーク治療の結果としてのForCESノードは、ロバスト安定処理能力を実現します。スケジュールの詳細については、付録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に過負荷をかけることのシナリオを検討してください。それはCEからのビジー処理の設定要求であるような場合では、FEは、本質的に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のPPIDsを設定します。
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:
ForCESノードが（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.
ForCESノード（CEまたはFE）を処理するために、ピア・ノードのどれを選択する必要が1 NEレベルのI / Oワーク。
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ワークのForCESノード、各単一のForCESエンドポイントのために別々に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.
「RFCでIANA問題部に書くためのガイドライン」[RFC5226]に概説された方針に続いて、次の名前空間は、SCTPのForCES TMLで定義されています。
o SCTP port 6704 for the HP channel, 6705 for the MP channel, and 6706 for the LP channel.
LPチャンネル用のHP MPチャネルのチャネル、6705、および6706のためのOのSCTPポート6704。
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 SCTPペイロードプロトコルID（PPID）HPチャネル（のForCES-HP）21、MPチャネル（のForCES-MP）22、およびLPチャネル（のForCES-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機構は、不正のCE、強制的にNEの制御及びデータパス処理における不正のFEの参加を防止するために、トランスポートレベルにおける力のCEとFEを認証します。
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.
PLメッセージに不正なデータの注入を防止するために、FEにCEから転送されたPLデータ及びヘッダのメッセージ認証（およびその逆）を確保するためのメカニズムO。
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.
TMLを介して輸送PL情報の開示を防止するために、FEにCEから転送されたPLデータ及びヘッダの機密性（およびその逆）を確保するためのメカニズムO。
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が提供するセキュリティサービスの全て、一部またはnoneを使用することもできます。
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:
ForCES 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.
メッセージの機密性のために、128ビットの鍵[RFC3602]とAES-CBC O。
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とSADエントリが必要とされています。
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.
それはSPDセレクタとして3つのSCTP TMLポート番号を使用するようにセットアップは、代わりに上記のポリシーを延長することができます。上記のようにしかし、この選択は、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アドレスを単一の関連内で使用されて、[RFC3554]以下毎IPアドレス上の異なるポリシーを設定したいという要望がある場合に推奨されます。
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.
著者は、より良い、この文書を作ってきた議論に私たちを係合するためのジョエル・ハルパーン、マイケルTuxen、ランディ・スチュワート、Evangelos Haleplidis、Chuanhuangリー、ラースEggertの、Avshalomフーリー、エードリアンファレル、ユルゲンQuittek、マグヌスウェスター、およびパシ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.
ロスCallonは私たちにガイダンスを提供して辛抱優れたマネージャーだったとジョエルハルパーンは、この文書が公開に時間がかかっていた誰なく、優れた文書の羊飼いでした。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.グレン、 "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]ハーキンとD.とD.カレル、 "インターネットキー交換（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.
"IPsecでストリーム制御伝送プロトコル（SCTP）の使用に" [RFC3554] Bellovin氏、S.、Ioannidis、J.、Keromytis、A.、およびR.スチュワート、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]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、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]ドリア、A.編、ハディサリム、J.、編、HAAS、R.、編、Khosravi、H.編、王、W.、編、ドン、L.、ゴパル、R.、およびJ.ハルパーン、 "転送と制御素子分離（のForCES）プロトコル仕様"、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.アンダーソン、 "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]ヤン、L.、Dantu、R.、アンダーソン、T.、およびR.ゴパル、 "転送および制御素子分離（の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]アルペルン、J.およびJ.ハディサリム、 "転送および制御素子分離（のForCES）転送要素モデル"、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.、エド。、 "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]スチュワート、R.、プーン、K.、Tuexen、M.、Yasevich、V.、およびP.レイ、進歩、2010年3月の作業 "ストリーム制御伝送プロトコル（SCTP）のためのソケットAPIの拡張機能" 。
Appendix A. Suggested SCTP TML Channel Work Implementation
付録A.推奨SCTP TMLチャンネルワークの実装
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.
ForCESノード（CEまたはFE）を処理するために、ピア・ノードのどれを選択する必要が1 NEレベルのI / Oワーク。
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ワークのForCESノード、各単一のForCESエンドポイントのために別々に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の作業の詳細を議論します。
A.1. SCTP TML Channel Initialization
A.1。 SCTP TMLチャンネルの初期化
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は、MPが続く最初の優先順位、すなわち、LPソケットを、インクリメント、およびHPソケット接続で終了のためにCEにソケット接続を行うことが推奨されます。 CEは、しかし、任意のFEからのソケット接続の順序があると仮定してはいけません。付録B.1は、SCTPチャネルの仕事の期待初期化の詳細を持っています。
A.2. Channel Work Scheduling
A.2。チャネル作業計画
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のための可能な限り最高の堅牢な作業のスループットを提供することです。
A.2.1. FE Channel Work Scheduling
A.2.1。 FEチャンネル作業計画
The FE scheduling, in priority order, needs to I/O process:
FEスケジューリングは、優先度順に、I / Oプロセスに必要があります。
1. Transmitting back to the CE any outstanding result of
executed work via the HP channel transmit path.
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.のForCES MPチャネルを介してCEへ未承諾のForCESパケットの送信をもたらす事象。
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.
前記受信リダイレクト（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チャネル上で新しいメッセージを読むことです次の優先順位の作業を（処理する前にそこに残されているまで、例えば、限り、HPのチャネル上のCEに送信するメッセージがあるとして、彼らが最初に処理されませんCE）。
A.2.2. CE Channel Work Scheduling
A.2.2。 CEチャンネル作業計画
The CE scheduling, in priority order, needs to deal with:
CEのスケジューリングは、優先度順に、対処する必要があります。
1. Process incoming responses to requests of work it made to the
FE(s).
2. Transmit any outstanding HP work it needs the FE(s) to complete.
2.未処理のHPはそれが完了するために、FE（複数可）を必要とする作業送信します。
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).
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).
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からの着信メッセージがある場合は、それ以上左FEに行く未処理のHPチャネルメッセージを送信することである次の優先順位の作業を、処理する前にあるまで、例えば、それらが最初に処理されません。
A.3. SCTP TML Channel Termination
A.3。 SCTP TMLチャンネル終了
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は、到達可能性を保証します。一つでもSCTPソケットの総接続損失の状況では、FEおよびCEがのForCES協会ティアダウンが発行されたと同等の状態を前提とし、付録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から未処理のコマンドを処理する必要はありません。
A.4. SCTP TML NE-Level Channel Scheduling
A.4。 SCTP TML NE-レベルチャネルのスケジューリング
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つのFEを考えます。 1 FEは、CEによって処理される必要があるいくつかのHPのメッセージを持っているのに対し、他は無限のHPのメッセージを有することができます。スケジューリング方式は、第二の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つのFEを考えます。 HPとMPのメッセージの数が多いとFE2はMPとLPのメッセージの数が多いようFE1を考えてみましょう。スケジューリング方式は、FE1は常に取得しながら、そのメッセージは、いくつかの点で、我々はFE2メッセージを処理できるように、処理していることを確認する必要があります。プロモーションとプリエンプションベースのスケジューリングは、この問題を解決するためにCEで使用することができます。
Appendix B. Suggested Service Interface
付録B.サービスインターフェイスを推奨しました
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の間に、ローカルおよびリモートのTMLs間の高レベルのサービス・インターフェースを概説します。このインタフェースの議論の目的は、一般的なガイドラインを提供することです。実装者は、詳細を気にしても、必要に応じて、異なるアプローチに従うことが期待されています。
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.
PLメッセージの2送受信が成功したTMLブートストラップの後に始まります。 PLは、そのピアに通信するPL-TMLインタフェースの送受信使用します。 TMLは、送信または受信されたメッセージの性質に依存しません。起こる最初のメッセージ交換は、のForCESの関連付けを確立することです。後続のメッセージは、制御メッセージがCEにFE FEから流れる、またはFEにCEから構成し、その応答に/からCEへの/からのリダイレクト、FE PLから迷惑なイベントのいずれであってもよいです。
3. The PL does a shutdown of the TML after terminating ForCES association.
3. PLはのForCESの関連付けを終了した後にTMLのシャットダウンを行います。
B.1. TML Bootstrapping
B.1。 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は、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つのチャンネルを初期化するために進みます。成功または失敗の表示を（FEで行ったと同様に）CE PLに渡されます。
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フェズからの接続を待ちます。 FEによって接続に成功すると、CE TMLレベルは、FEのトランスポート・レベルの詳細を追跡します。この段階でのみトランスポートレベルの接続が確立されている、注意してください。 ForCESレベルの関連付けは、PL-TMLのインターフェイスは（付録B.3および図8を参照）を受信/送信を用いて以下。
B.2. TML Shutdown
B.2。 TMLシャットダウン
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の例を示しています。のForCES協会のティアダウンは、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に確認応答を送信します。
B.3. TML Sending and Receiving
B.3。 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に送信示します。
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チャネルの一つを選んで、強制的にメッセージを送信することが期待されます。
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.3に上記のようにFE TMLの到着とFE PLへの配信時のForCESメッセージの処理は、CE側相当に類似しています。
Authors' Addresses
著者のアドレス
Jamal Hadi Salim Mojatatu Networks Ottawa, Ontario Canada
ジャマル・ハディサリムMojatatuネットワークオタワ、オンタリオ州カナダ
EMail: hadi@mojatatu.com
メールアドレス：hadi@mojatatu.com
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
けんたろ おがわ んっｔ こｒぽらちおん ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: ogawa.kentaro@lab.ntt.co.jp
メールアドレス：ogawa.kentaro@lab.ntt.co.jp