Network Working Group R. Stewart
Request for Comments: 5352 Q. Xie
Category: Experimental The Resource Group
M. Stillman
Nokia
M. Tuexen
Muenster Univ. of Applied Sciences
September 2008
Aggregate Server Access Protocol (ASAP)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
集計サーバアクセスプロトコル（ASAPは、RFC 5352）は、エンドポイントHandlespace冗長プロトコル（ENRP; RFC 5353）と連動して、IPネットワーク上で高可用性データ転送メカニズムを提供します。 ASAPを効果的に通信エンドポイントと通常単一障害点を構成し、その物理IPアドレス（複数可）との間の結合を排除し、そのIPアドレス（複数可）からの論理通信エンドポイントを隔離するハンドルベースのアドレッシングモデルを使用します。
In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.
また、できるだけ早くサーバープールと負荷分散のための完全な透明支持体を提供し、プールとして各論理通信先を定義します。また、動的システムのスケーラビリティを可能にする - サーバー・プールのメンバーは、サービスを中断することなく、いつでも追加または削除することができます。
ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.
ASAPのストリーム伝送制御プロトコル（; RFC 4960 SCTP）によって提供されるネットワークレベルの冗長性を最大限に活用するように設計されています。 SCTP以外の各トランスポートプロトコルは、付属のトランスポート・マッピング・ドキュメントを持たなければなりません。プール要素（PES）とENRPサーバ間で渡さ至急メッセージがSCTPトランスポートプロトコルを使用しなければならないことに留意すべきです。
The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high-availability Pool Handle translation service.
高可用性サーバプールは、ASAP ENRP高可用性プール・ハンドル変換を定義しながら、プールのユーザインターフェースは、翻訳、負荷分散管理、障害管理に対処するためのハンドルを提供する、すなわち、ASAPとENRP 2つのプロトコルを、組み合わせることによって得られますサービス。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Definitions ................................................4
1.2. Conventions ................................................5
1.3. Organization of This Document ..............................6
1.4. Scope of ASAP ..............................................6
1.4.1. Extent of the Handlespace ...........................6
2. Message Definitions .............................................6
2.1. ASAP Parameter Formats .....................................7
2.2. ASAP Messages ..............................................7
2.2.1. ASAP_REGISTRATION Message ...........................7
2.2.2. ASAP_DEREGISTRATION Message .........................8
2.2.3. ASAP_REGISTRATION_RESPONSE Message ..................9
2.2.4. ASAP_DEREGISTRATION_RESPONSE Message ...............10
2.2.5. ASAP_HANDLE_RESOLUTION Message .....................10
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message ............11
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message ...................13
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message ...............14
2.2.9. ASAP_ENDPOINT_UNREACHABLE Message ..................14
2.2.10. ASAP_SERVER_ANNOUNCE Message ......................15
2.2.11. ASAP_COOKIE Message ...............................16
2.2.12. ASAP_COOKIE_ECHO Message ..........................16
2.2.13. ASAP_BUSINESS_CARD Message ........................17
2.2.14. ASAP_ERROR Message ................................17
3. Procedures .....................................................18
3.1. Registration ..............................................18
3.2. De-Registration ...........................................21
3.3. Handle Resolution .........................................23
3.4. Endpoint Keep Alive .......................................25
3.5. Unreachable Endpoints .....................................26
3.6. ENRP Server Hunt Procedures ...............................27
3.7. Handling ASAP Endpoint to ENRP Server
Communication Failures ....................................28
3.7.1. SCTP Send Failure ..................................28
3.7.2. T1-ENRPrequest Timer Expiration ....................29
3.7.3. Registration Failure ...............................29
3.8. Cookie Handling Procedures ................................29
3.9. Business Card Handling Procedures .........................30
4. Roles of Endpoints .............................................31
5. SCTP Considerations ............................................31
6. The ASAP Interfaces ............................................31
6.1. Registration.Request Primitive ............................32
6.2. Deregistration.Request Primitive ..........................32
6.3. CachePopulateRequest Primitive ............................33
6.4. CachePurgeRequest Primitive ...............................33
6.5. DataSendRequest Primitive .................................33
6.5.1. Sending to a Pool Handle ...........................34
6.5.2. Pool Element Selection .............................35
6.5.2.1. Round-Robin Policy ........................35
6.5.3. Sending to a Pool Element Handle ...................35
6.5.4. Send by Transport Address ..........................37
6.5.5. Message Delivery Options ...........................37
6.6. Data.Received Notification ................................38
6.7. Error.Report Notification .................................39
6.8. Examples ..................................................39
6.8.1. Send to a New Pool .................................39
6.8.2. Send to a Cached Pool Handle .......................40
6.9. PE Send Failure ...........................................41
6.9.1. Translation.Request Primitive ......................41
6.9.2. Transport.Failure Primitive ........................42
7. Timers, Variables, and Thresholds ..............................42
7.1. Timers ....................................................42
7.2. Variables .................................................42
7.3. Thresholds ................................................43
8. IANA Considerations ............................................43
8.1. A New Table for ASAP Message Types ........................43
8.2. Port Numbers ..............................................44
8.3. SCTP Payload Protocol Identifier ..........................44
8.4. Multicast Addresses .......................................44
9. Security Considerations ........................................44
9.1. Summary of RSerPool Security Threats ......................45
9.2. Implementing Security Mechanisms ..........................46
9.3. Chain of Trust ............................................49
10. Acknowledgments ...............................................50
11. References ....................................................50
11.1. Normative References .....................................50
11.2. Informative References ...................................51
The Aggregate Server Access Protocol (ASAP), when used in conjunction with Endpoint Name Resolution Protocol [RFC5353], provides a high-availability data-transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
集計サーバアクセスプロトコル（できるだけ早く）、エンドポイントの名前解決プロトコルと共に使用[RFC5353]は、IPネットワーク上で高可用性データ転送機構を提供します。 ASAPを効果的に通信エンドポイントと通常単一障害点を構成し、その物理IPアドレス（複数可）との間の結合を排除し、そのIPアドレス（複数可）からの論理通信エンドポイントを隔離するハンドルベースのアドレッシングモデルを使用します。
When multiple receiver instances exist under the same handle (aka a server pool), an ASAP Endpoint will select one Pool Element (PE), based on the current load sharing policy indicated by the server pool, and deliver its message to the selected PE.
複数の受信インスタンスが同じハンドル（別名サーバープール）の下に存在する場合、ASAPのエンドポイントは、サーバプールによって示される現在の負荷分散ポリシーに基づいて、1つのプール要素（PE）を選択し、選択されたPEにそのメッセージを配信します。
While delivering the message, ASAP can be used to monitor the reachability of the selected PE. If it is found unreachable, before notifying the message sender (an ASAP User) of the failure, ASAP can automatically select another PE (if one exists) under that pool and attempt to deliver the message to that PE. In other words, ASAP is capable of transparent failover amongst PE instances within a server pool.
メッセージを提供しながら、できるだけ早く選択PEの到達可能性を監視するために使用することができます。それは失敗のメッセージ送信者（ASAPのユーザ）を通知する前に、到達不能検出された場合、できるだけ早く自動的にそのプールの下に別のPE（存在する場合）を選択し、そのPEにメッセージを配信しようと試みることができます。換言すれば、できるだけ早くサーバープール内PEインスタンス間で透過的なフェイルオーバーすることが可能です。
ASAP depends on ENRP, which provides a high-availability Pool Handlespace. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as presentation to the upper layer (aka an ASAP User) via a unified primitive interface.
できるだけ早く高可用性プールHandlespaceを提供ENRP、に依存しています。できるだけ早く統一プリミティブインタフェースを介して上位層（別名できるだけ早くユーザ）に基礎をなすトランスポート技術の抽象化、負荷分散管理、障害管理、ならびに提示する責任があります。
When SCTP [RFC4960] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by SCTP.
SCTP [RFC4960]は、トランスポート層プロトコルとして使用される場合、できるだけ早くシームレスSCTPによって提供されるリンク層の冗長性を組み込むことができます。
This document defines the ASAP portion of the high-availability server pool.
この文書では、高可用性サーバー・プールの至急部分を定義します。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
ASAP User: Either a PE or Pool User (PU) that uses ASAP.
できるだけ早くユーザー：PEまたはできるだけ早く使用してプールのユーザー（PU）のどちらか。
Business Card: When presented by a PU or PE, it specifies the pool the sender belongs to and provides a list of alternate PEs in case of failovers.
名刺は：PUまたはPEが提示した場合は、送信者が所属し、フェイルオーバーの場合には、代替PEのリストを提供してプールを指定します。
Operational Scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols.
動作範囲：信頼できるサーバプーリングプロトコルの特定のインスタンスによってプールユーザーに表示ネットワークの一部。
Pool (or Server Pool): A collection of servers providing the same application functionality.
プール（またはサーバプール）：同じアプリケーション機能を提供するサーバの集合。
Pool Handle: A logical pointer to a pool. Each server pool will be identifiable in the operational scope of the system by a unique Pool Handle.
プール・ハンドル：プールへの論理ポインタ。各サーバー・プールには、独自のプール・ハンドルによってシステムの動作範囲内に識別されます。
Pool Element: A server entity having registered to a pool.
プール要素：プールに登録されたサーバエンティティ。
Pool User: A server pool user.
プールユーザー：サーバー・プールのユーザー。
Pool Element Handle (or Endpoint Handle): A logical pointer to a particular Pool Element in a pool, consisting of the Pool Handle and a destination transport address of the Pool Element.
プール要素ハンドル（またはエンドポイントハンドル）：プールハンドルとプール要素の宛先トランスポートアドレスからなるプール内の特定のプール要素への論理ポインタ、。
Handlespace: A cohesive structure of Pool Handles and relations that may be queried by an internal or external agent.
Handlespace：内部または外部エージェントによって照会することができるプールハンドルと関係の凝集構造。
Home ENRP Server: The ENRP server to which a PE or PU currently sends all namespace service requests. A PE must only have one Home ENRP server at any given time, and both the PE and its Home ENRP server MUST know and keep track of this relationship. A PU should select one of the available ENRP servers as its Home ENRP server, but the collective ENRP servers may change this by the sending of an ASAP_ENDPOINT_KEEP_ALIVE message.
PEまたはPUは現在、すべての名前空間のサービス要求を送信するENRPサーバ：ホームENRPサーバ。 PEは、任意の時点で1台のホームENRPサーバを持っている必要がありますし、PEとそのホームENRPサーバの両方が知っていると、この関係を追跡する必要があります。 PUは、そのホームENRPサーバとして利用できるENRPサーバのいずれかを選択する必要がありますが、集団ENRPサーバはASAP_ENDPOINT_KEEP_ALIVEメッセージを送信することで、これを変更することがあります。
ENRP Client Channel: The communication channel through which an ASAP User sends all namespace service requests. The client channel is usually defined by the transport address of the Home ENRP server and a well-known port number. The channel MAY make use of multicast or a named list of ENRP servers.
ENRPクライアントチャンネル：できるだけ早くユーザーはすべての名前空間のサービス要求を送信する通信チャネル。クライアントチャネルは通常、ホームENRPサーバと、よく知られているポート番号のトランスポート・アドレスによって定義されます。チャネルは、マルチキャストまたはENRPサーバの名前付きリストを利用することができます。
Network Byte Order: Most significant byte first, aka Big Endian.
ネットワークバイト順序：最初の最上位バイト、別名ビッグエンディアン。
Transport Address: A transport address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol).
トランスポートアドレス：トランスポート・アドレスは、伝統的にネットワーク層アドレス、トランスポート層プロトコルおよびトランスポート層のポート番号によって定義されます。 SCTPは、IP上で動作する場合には、トランスポートアドレスはIPアドレス及び（SCTPトランスポートプロトコルである）SCTPポート番号の組み合わせで定義されています。
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]に記載されているように解釈されます。
Section 2 details the ASAP message formats. In Section 3, we provide detailed ASAP procedures for the ASAP implementer. Section 4 summarizes which messages need to be supported by which nodes, and Section 5 describes the usage of SCTP. In Section 6, details of the ASAP interface are given, focusing on the communication primitives between ASAP, the applications above ASAP, and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layers). Also included in this discussion are relevant timers and configurable parameters, as appropriate. Section 7 provides threshold and protocol variables.
第2節では、できるだけ早くメッセージフォーマットの詳細について説明します。第3節では、我々はできるだけ早く実装の詳細できるだけ早く手続きを提供しています。第4節では、メッセージがどのノードによってサポートされる必要がまとめたものであり、第5節では、SCTPの使用方法について説明します。第6節では、ASAPのインターフェースの詳細は、ASAPおよびSCTP（または他のトランスポート層）の間にできるだけ早く、できるだけ早く、かつできるだけ早く自体上記アプリケーション、および通信プリミティブとの間の通信プリミティブに着目し、与えられています。また、この議論では、必要に応じて、関連するタイマーと設定可能なパラメータも含まれています。第7節は、しきい値とプロトコル変数を提供します。
It should be noted that variables, timers, and constants are used in the text when necessary. The complete list can be found in Section 7.
必要なときに、変数、タイマ、および定数がテキストで使用されていることに留意すべきです。完全なリストは、第7節で見つけることができます。
The requirements for high availability and scalability do not imply requirements on shared state and data. ASAP does not provide transaction failover. If a host or application fails during the processing of a transaction, this transaction may be lost. Some services MAY provide a way to handle the failure, but this is not guaranteed. ASAP MAY provide hooks to assist an application in building a mechanism to share state but ASAP in itself does NOT share any state.
高可用性とスケーラビリティを実現するための要件は、共有状態とデータに関する要件を意味するものではありません。できるだけ早くトランザクションのフェイルオーバーを提供していません。ホストまたはアプリケーションがトランザクションの処理中に障害が発生した場合、このトランザクションが失われることがあります。一部のサービスでは、障害を処理する方法を提供することができるが、これは保証されません。できるだけ早く状態を共有する仕組みを構築してアプリケーションを支援するためのフックを提供してもよいが、できるだけ早く自体にどのような状態を共有しません。
The scope of ASAP/ENRP is NOT Internet-wide. The handlespace is neither hierarchical nor arbitrarily large like DNS. A flat peer-to-peer model is detailed. Pools of servers will exist in different administrative domains. For example, suppose the use of ASAP and ENRP is wanted. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact a server pool in Japan instead of North America. The PU would use DNS to get the list of IP addresses of the Japanese server pool; that is, the ENRP client channel in Japan. From there, the PU would query the Home ENRP server it established and then directly contact the PE(s) of interest.
至急/ ENRPの範囲は、インターネット全体ではありません。 handlespaceは、階層やDNSなどの任意の大きさでもありません。フラットピア・ツー・ピアモデルが詳細です。サーバのプールは、異なる管理ドメインに存在しています。例えば、至急の使用を想定し、ENRPが望まれます。まず、PUはENRPサーバに接続するためにDNSを使用することができます。北米のPUはなく、北米の日本におけるサーバプールに連絡したいとします。 PUは、日本のサーバー・プールのIPアドレスのリストを取得するためにDNSを使用します。それは、日本ではENRPクライアントチャンネルです。そこから、PUは、それが確立ホームENRPサーバに照会して、直接関心のPE（複数可）をご連絡します。
All messages, as well as their fields described below, shall be in network byte order during transmission. For fields with a length bigger than 4 bytes, a number in a pair of parentheses may follow the field name to indicate the length of the field in number of bytes.
以下で説明するすべてのメッセージ、ならびにこれらのフィールドは、送信中にネットワークバイトオーダーにしなければなりません。 4バイトより大きい長さのフィールドでは、括弧のペアの数は、バイト数のフィールドの長さを示すために、フィールド名に従うことができます。
The basic message format and all parameter formats can be found in [RFC5354]. Note also that *all* ASAP messages exchanged between an ENRP server and a PE MUST use SCTP as transport, while ASAP messages exchanged between an ENRP server and a PU MUST use either SCTP or TCP as transport. PE to PU data traffic MAY use any transport protocol specified by the PE during registration.
基本的なメッセージ形式およびすべてのパラメータのフォーマットは、[RFC5354]に見出すことができます。 ASAPのメッセージがトランスポートとしてSCTPまたはTCPを使用しなければならないENRPサーバとPUとの間で交換しながら、ノートはまた、*全て* ASAPのメッセージは、ENRPサーバとトランスポートとしてSCTPを使用しなければならないPEとの間で交換しました。 PUデータトラフィックのPEは、登録時にPEで指定された任意のトランスポートプロトコルを使用してもよいです。
This section details the individual messages used by ASAP. These messages are composed of a standard message format found in Section 4 of [RFC5354]. The parameter descriptions can be found in [RFC5354].
このセクションでは、至急で使用される個々のメッセージについて詳しく説明します。これらのメッセージは、[RFC5354]のセクション4に見られる標準メッセージフォーマットで構成されています。パラメータの説明は、[RFC5354]で見つけることができます。
The following ASAP message types are defined in this section:
できるだけ早く、次のメッセージの種類は、このセクションで定義されています。
Type Message Name
----- -------------------------
0x00 - (Reserved by IETF)
0x01 - ASAP_REGISTRATION
0x02 - ASAP_DEREGISTRATION
0x03 - ASAP_REGISTRATION_RESPONSE
0x04 - ASAP_DEREGISTRATION_RESPONSE
0x05 - ASAP_HANDLE_RESOLUTION
0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE
0x07 - ASAP_ENDPOINT_KEEP_ALIVE
0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK
0x09 - ASAP_ENDPOINT_UNREACHABLE
0x0a - ASAP_SERVER_ANNOUNCE
0x0b - ASAP_COOKIE
0x0c - ASAP_COOKIE_ECHO
0x0d - ASAP_BUSINESS_CARD
0x0e - ASAP_ERROR
others - (Reserved by IETF)
Figure 1
図1
The ASAP_REGISTRATION message is sent by a PE to its Home ENRP server to either create a new pool or to add itself to an existing pool. The PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle parameter and the Pool Element parameter. The Pool Handle parameter specifies the name to be registered. The Pool Element parameter MUST be filled in by the registrant, as outlined in Section 3.1. Note that the PE sending the registration message MUST
ASAP_REGISTRATIONメッセージが新しいプールを作成するか、または既存のプールに自分自身を追加するためにそのホームENRPサーバにPEによって送信されます。 ASAP_REGISTRATIONメッセージを送信するPEは、プール・ハンドルパラメータとプール要素パラメータに記入しなければなりません。プール・ハンドルパラメータが登録する名前を指定します。 3.1節で概説したようプール要素パラメータは、登録者が記入しなければなりません。 PEは、登録メッセージを送信しなければならないことに注意してください
send the message using an SCTP association. Furthermore, the IP address(es) of the PE that is registered within the Pool Element parameter MUST be a subset of the IP address(es) used in the SCTP association, regardless of the registered transport protocol.
SCTPアソシエーションを使用してメッセージを送信します。また、プール要素パラメータに登録されているPEのIPアドレス（ES）は関係なく、登録されたトランスポートプロトコルの、SCTPアソシエーションで使用されるIPアドレス（複数可）のサブセットでなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
Pool Element Parameter:
プール要素パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP server to remove itself from a pool to which it registered.
ASAP_DEREGISTRATIONメッセージは、それが登録するプールからそれ自体を除去するためにそのホームENRPサーバにPEによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
PE Identifier Parameter:
PE識別子パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The PE sending the ASAP_DEREGISTRATION MUST fill in the Pool Handle and the PE identifier parameter in order to allow the ENRP server to verify the identity of the endpoint. Note that de-registration is NOT allowed by proxy; in other words, a PE may only de-register itself.
ASAP_DEREGISTRATIONを送るPEはENRPサーバは、エンドポイントの身元を確認することを可能にするためにプール・ハンドルおよびPE識別子パラメータに記入しなければなりません。登録解除がプロキシで許可されていないことに注意してください。換言すれば、PEのみできる自身を登録解除。
The ASAP_REGISTRATION_RESPONSE message is sent in response by the Home ENRP server to the PE that sent an ASAP_REGISTRATION message.
ASAP_REGISTRATION_RESPONSEメッセージはASAP_REGISTRATIONメッセージを送信したPEのホームENRPサーバによって応答して送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) Flag:
R（拒否）フラグ：
When set to '1', this flag indicates that the ENRP server sending this message has rejected the registration. Otherwise, when this flag is set to '0', this indicates the registration has been granted.
「1」に設定すると、このフラグは、このメッセージを送るENRPサーバが登録を拒否したことを示しています。このフラグが「0」に設定されている場合はそれ以外の場合、これは登録が付与されたことを示します。
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
PE Identifier Parameter:
PE識別子パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
Operational Error Parameter (optional):
誤操作パラメータ（オプション）：
See [RFC5354].
[RFC5354]を参照してください。
This parameter is included if an error or some atypical events occurred during the registration process. When the R flag is set to '1', this parameter, if present, indicates the cause of the rejection. When the R flag is set to '0', this parameter, if present, serves as a warning to the registering PE, informing it that some of its registration values may have been modified by the ENRP server. If the registration was successful and there is no warning, this parameter is not included.
エラーまたは一部の非定型のイベントは、登録プロセス中に発生した場合、このパラメータは含まれています。 Rフラグが「1」に設定されている場合、このパラメータは、存在する場合に、拒絶の原因を示しています。 Rフラグが「0」に設定されている場合に存在する場合、このパラメータは、その登録値のいくつかはENRPサーバによって変更された可能性があることを通知する、登録PEへの警告として働きます。登録が成功したと警告がない場合は、このパラメータが含まれていません。
The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP server to a PE in response to an ASAP_DEREGISTRATION message or due to the expiration of the registration life of the PE in the pool.
ASAP_DEREGISTRATION_RESPONSEメッセージは、プール内のPEの登録寿命の満了にASAP_DEREGISTRATIONメッセージに応答してかによりPEにホームENRPサーバによって返されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
PE Identifier Parameter:
PE識別子パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
Operational Error:
運用エラー：
See [RFC5354].
[RFC5354]を参照してください。
This parameter is included if an error or some atypical events occurred during the de-registration process. If the de-registration was successful this parameter is not included.
エラーまたは一部の非定型のイベントが登録解除処理中に発生した場合、このパラメータは含まれています。登録解除が成功した場合、このパラメータが含まれていません。
The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to its Home ENRP server to resolve a Pool Handle into a list of Pool Elements that are members of the pool indicated by the Pool Handle.
ASAP_HANDLE_RESOLUTIONメッセージはプールがプール・ハンドルによって示され、プールのメンバーであるプール要素のリストにハンドル解決するために、そのホームENRPサーバへのPEまたはPUのいずれかによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 |0|0|0|0|0|0|0|S| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'S' bit:
「S」ビット：
The 'S' bit, if set to '1', requests the Home ENRP server to send updates to this Pool dynamically when the Pool changes for the lifetime of the SCTP association. Dynamic updates to the pool will consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages, without the user needing to send in an ASAP_HANDLE_RESOLUTION.
「S」ビット、「1」に設定すると、プールはSCTPアソシエーションのライフタイムのために変更されたときに動的このプールに更新を送信するためにホームENRPサーバに要求。プールへの動的更新はASAP_HANDLE_RESOLUTIONで送信する必要がユーザーせずに、追加のASAP_HANDLE_RESOLUTION_RESPONSEメッセージで構成されます。
If the 'S' bit is set to '0', no Dynamic updates are requested.
「S」ビットが「0」に設定されている場合は、動的更新が要求されていません。
Note that if a new Home ENRP server is adopted, any 'dynamic update request' will need to be re-sent to the new Home ENPR server if the endpoint would like to continue to receive updates. In other words, the ENRP servers do NOT share state regarding which of its PU's are requesting automatic update of state. Thus, upon change of Home ENRP server, the PU will need to re-send an ASAP_HANDLE_RESOLUTION message with the 'S' bit set to '1'. Note also, that the 'S' bit will only cause Dynamic update of a Pool when the Pool exists. If a negative response is returned, no further updates to the Pool (when it is created) will occur.
新しいホームENRPサーバが採用されている場合、エンドポイントがアップデートを受信し続けたい場合は、任意の「動的更新要求は」新しいホームENPRサーバに再送信する必要があることに注意してください。言い換えれば、ENRPサーバは、状態の自動更新を要求しているそのPUののかに関する状態を共有することはありません。このように、ホームENRPサーバの変更時に、PUは「S」が「1」に設定ビットがASAP_HANDLE_RESOLUTIONメッセージを再送信する必要があります。プールが存在する場合は「S」ビットのみプールの動的更新を引き起こすことにも注意してください。否定応答が返された場合、（それが作成されます）プールへの更なるアップデートは行われません。
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by the Home ENRP server of the PU or PE that sent an ASAP_HANDLE_RESOLUTION message or is sent periodically upon Pool changes if the PU has requested Dynamic updates.
ASAP_HANDLE_RESOLUTION_RESPONSEメッセージはASAP_HANDLE_RESOLUTIONメッセージを送信したり、PUが動的更新を要求した場合のプールの変更時に定期的に送信されたPUまたはPEのホームENRPサーバによって応答して送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 |0|0|0|0|0|0|0|A| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'A' bit:
「」ビット：
This bit is set to '1' if the ENRP server accepts the request to send automatic updates (i.e., the 'S' bit was set on the request). If this bit is set to '0', either the ENRP server does NOT support automatic updates, it has resource issues and cannot supply this feature, or the user did not request it.
ENRPサーバ（すなわち、「S」ビットはリクエストに応じて設定された）自動更新を送信する要求を受け付けると、このビットが「1」に設定されています。このビットが「0」に設定されている場合は、どちらかのENRPサーバが自動更新をサポートしていない、それはリソースの問題があり、この機能を提供することができない、またはユーザーがそれを要求しませんでした。
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
Overall PE Selection Policy (optional):
全体的にPE選択ポリシー（オプション）：
See [RFC5354].
[RFC5354]を参照してください。
This parameter can be present when the response is positive. If present, it indicates the overall pool member selection policy of the pool. If not present, a Round-Robin overall pool member selection policy is assumed. This parameter is not present when the response is negative.
応答が正の場合、このパラメータは存在することができます。存在する場合、それはプールの全体的なプールメンバー選択方針を示しています。存在しない場合は、ラウンドロビン、全体のプールメンバー選択方針を想定しています。応答が負の場合、このパラメータは存在しません。
Note, any load policy parameter within a Pool Element parameter (if present) MUST be ignored, and MUST NOT be used to determine the overall pool member selection policy.
メモ、プール要素パラメータ（存在する場合）内の任意の負荷ポリシーパラメータは無視しなければなりません、そして全体的なプールメンバー選択方針を決定するために使用してはいけません。
Pool Element Parameters (optional):
プール要素パラメータ（オプション）：
See [RFC5354].
[RFC5354]を参照してください。
When the response is positive, an array of PE parameters are included, indicating the current information about the PEs in the named pool. At least one PE parameter MUST be present. When the response is negative, no PE parameters are included.
応答が肯定である場合、PEパラメータの配列は、指定プール内のPEについての現在の情報を示す、含まれています。少なくとも1つのPEパラメータが存在しなければなりません。応答が否定である場合、何PEパラメータが含まれていません。
Operational Error (optional):
操作ミス（オプション）：
See [RFC5354].
[RFC5354]を参照してください。
The presence of this parameter indicates that the response is negative (the handle resolution request was rejected by the ENRP server). The cause code in this parameter (if present) will indicate the reason the handle resolution request was rejected (e.g., the requested Pool Handle was not found). The absence of this parameter indicates that the response is positive.
このパラメータの存在は、応答が（ハンドル解決要求をENRPサーバによって拒否された）負であることを示しています。このパラメータで原因コードは（存在する場合）は、ハンドル解決要求が拒否された理由（例えば、要求されたプール・ハンドルが見つかりませんでした）が表示されます。このパラメータが存在しない場合は、応答が肯定的であることを示しています。
The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the PE is reachable and requires the PE to adopt the sending server as its new Home ENRP server if the 'H' bit is set to '1'. Regardless of the setting of the 'H' bit, an ASAP Endpoint MUST respond with an ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages that arrive.
ASAP_ENDPOINT_KEEP_ALIVEメッセージはPEにENRPサーバによって送信されます。 ASAP_ENDPOINT_KEEP_ALIVEメッセージは、PEが到達可能であることを確認するために使用され、「H」ビットが「1」に設定されている場合、その新しいホームENRPサーバとして送信サーバを採用するPEを必要とします。かかわらず、「H」ビットの設定に、できるだけ早くエンドポイントは、到着したあらゆるASAP_ENDPOINT_KEEP_ALIVEメッセージにASAP_ENDPOINT_KEEP_ALIVE_ACKで応じなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |0|0|0|0|0|0|0|H| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H (Home ENRP server) Flag:
H（ホームENRPサーバ）旗：
When set to '1', indicates that the ENRP server that sends this message wants to be the Home ENRP server of the receiver of this message.
「1」に設定すると、このメッセージを送信ENRPサーバは、このメッセージの受信者のホームENRPサーバであることを望んでいることを示します。
Server Identifier: 32 bits (unsigned integer)
サーバ識別子：32ビット（符号なし整数）
This is the ID of the ENRP server, as discussed in [RFC5353].
[RFC5353]で説明したように、これは、ENRPサーバのIDです。
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP server.
ASAP_ENDPOINT_KEEP_ALIVE_ACKメッセージはENRPサーバによって送信されたASAP_ENDPOINT_KEEP_ALIVEメッセージに応答してPEによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
PE Identifier Parameter:
PE識別子パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to its Home ENRP server to report an unreachable PE.
ASAP_ENDPOINT_UNREACHABLEメッセージが到達不能PEを報告するためにそのホームENRPサーバにPEまたはPUのいずれかによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
PE Identifier Parameter:
PE識別子パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_SERVER_ANNOUNCE message is sent by an ENRP server such that PUs and PEs know the transport information necessary to connect to the ENRP server.
ASAP_SERVER_ANNOUNCEメッセージはPUとPEはENRPサーバに接続するために必要なトランスポート情報を知っているようにENRPサーバによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ..... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Identifier: 32 bits (unsigned integer)
サーバ識別子：32ビット（符号なし整数）
This is the ID of the ENRP server, as discussed in [RFC5353].
[RFC5353]で説明したように、これは、ENRPサーバのIDです。
Transport Parameters (optional):
交通パラメータ（オプション）：
See [RFC5354] for the SCTP and TCP Transport parameters.
SCTPとTCPトランスポートパラメータについて[RFC5354]を参照してください。
Only SCTP and TCP Transport parameters are allowed for use within the SERVER_ANNOUNCE message.
SCTPとTCPトランスポート・パラメータのみがSERVER_ANNOUNCEメッセージ内で使用するために許可されています。
The ASAP_COOKIE message is sent by a PE to a PU, allowing the PE to convey information it wishes to share using a control channel.
ASAP_COOKIEメッセージは、PEは、それが制御チャネルを使用して共有したい情報を伝達することができ、PUにPEによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter :
クッキーパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it detects a failure with the current PE to aid in failover. The Cookie Parameter sent by the PE is the latest one received from the failed PE.
それは、フェイルオーバーを助けるために、現在のPEとの故障を検出した場合ASAP_COOKIE_ECHOメッセージが新しいPEにPUによって送信されます。 PEによって送信されたクッキーパラメータが失敗したPEから受信した最新のものです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter:
クッキーパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE to a PU using a control channel to convey the pool handle and a preferred failover ordering.
ASAP_BUSINESS_CARDメッセージはプールハンドルと好ましいフェイルオーバ順序を搬送するために制御チャネルを使用して、PEまたはPEからPUへPUによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
プール・ハンドルのパラメータ：
See [RFC5354].
[RFC5354]を参照してください。
Pool Element Parameters:
プール要素パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
The ASAP_ERROR message is sent in response by an ASAP Endpoint receiving an unknown message or an unknown parameter to the sending ASAP Endpoint to report the problem or issue.
ASAP_ERRORメッセージは、問題や課題を報告してできるだけ早く送信エンドポイントに不明なメッセージや、未知のパラメータを受信できるだけ早くエンドポイントによって応答して送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0e |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Parameter:
誤操作パラメータ：
See [RFC5354].
[RFC5354]を参照してください。
When an ASAP Endpoint receives an ASAP message with an unknown message type or a message of known type that contains an unknown parameter, it SHOULD handle the unknown message or the unknown parameter according to the unrecognized message and parameter handling rules, defined in Section 3.
ASAPのエンドポイントが不明なメッセージ・タイプまたは未知のパラメータが含まれている既知のタイプのメッセージで、ASAPメッセージを受信すると、不明なメッセージまたはセクション3で定義された認識されていないメッセージとパラメータ処理ルールに従って未知パラメータを処理します。
According to the rules, if an error report to the message sender is needed, the ASAP endpoint that discovered the error SHOULD send back an ASAP_ERROR message that includes an Operational Error parameter with the proper cause code, cause length, and case-specific information.
メッセージの送信者にエラーレポートが必要な場合は、ルールによると、エラーを発見し、ASAPエンドポイントは、適切な原因コード、原因の長さ、およびケース固有の情報と運用エラーパラメータを含んASAP_ERRORメッセージを送り返すべきです。
This section will focus on the methods and procedures used by an internal ASAP Endpoint. Appropriate timers and recovery actions for failure detection and management are also discussed. Also, please note that ASAP messages sent between a PE and PU are identified by an SCTP Payload Protocol Identifier (PPID).
このセクションでは、内部のASAPエンドポイントによって使用される方法と手順に焦点を当てます。障害検出および管理のための適切なタイマと回復アクションも議論されています。また、ASAPはPEとPUとの間で送信されるメッセージはSCTPペイロードプロトコル識別子（PPID）によって識別されることに注意してください。
When a PE wishes to initiate or join a server pool, it MUST use the procedures outlined in this section for registration. Often, the registration will be triggered by a user request primitive (discussed in Section 6.1). The PE MUST register using an SCTP association established between itself and the Home ENRP server. If the PE has not established its Home ENRP server, it MUST follow the procedures specified in Section 3.6.
PEは、サーバー・プールを開始または参加することを望む場合は、登録のために、このセクションで概説した手順を使用しなければなりません。多くの場合、登録は（セクション6.1で説明する）プリミティブユーザ要求によってトリガされます。 PEは、それ自体とホームENRPサーバとの間で確立されたSCTPアソシエーションを使用して登録しなければなりません。 PEは、そのホームENRPサーバを確立していない場合は、セクション3.6で指定された手順に従わなければなりません。
Once the PE's ASAP Endpoint has established its Home ENRP server, the following procedures MUST be followed to register:
PEのできるだけ早くエンドポイントは、そのホームENRPサーバを確立したら、次の手順では、登録することに従う必要があります。
R1) The PE's SCTP endpoint used to communicate with the Home ENRP server MUST be bound to all IP addresses that will be used by the PE (regardless of which transport protocol will be used to service user requests to the PE).
PEのSCTP終点がホームENRPサーバとの通信に使用されるR1）は関係なく、PEへのサービスのユーザーの要求）に使用されるトランスポートプロトコルのPE（で使用されるすべてのIPアドレスにバインドする必要があります。
R2) The PE's ASAP Endpoint MUST formulate an ASAP_REGISTRATION message, as defined in Section 2.2.1. In formulating the message, the PE MUST:
セクション2.2.1で定義されるようにR2）PEのASAPのエンドポイントは、ASAP_REGISTRATIONメッセージを定式化しなければなりません。メッセージを定式化において、PE必要があります。
R2.1) Fill in the Pool Handle parameter to specify which server pool the ASAP Endpoint wishes to join.
R2.1）のASAPエンドポイントは、参加を希望するサーバープールを指定するプール・ハンドルパラメータを入力します。
R2.2) Fill in the PE identifier using a good-quality randomly generated number ([RFC4086] provides some information on randomness guidelines).
R2.2）良質ランダムに生成された番号を（[RFC4086]はランダムガイドラインに関するいくつかの情報を提供する）を使用してPE識別子を入力します。
R2.3) Fill in the Registration Lifetime parameter with the number of seconds that this registration is valid for. Note that a PE that wishes to continue service MUST re-register before the registration expires.
R2.3）この登録は、のために有効である秒数の登録寿命パラメータを入力します。登録の有効期限が切れる前にサービスを継続したいPEが再登録しなければならないことに注意してください。
R2.4) Fill in a User Transport parameter to specify the type of transport and the data/control channel usage the PE is willing to support. Note, in joining an existing server pool, the PE MUST follow the overall transport type and overall data/control channel usage of the pool. Otherwise, the registration may be rejected by the ENRP server.
R2.4）輸送およびPEがサポートする意思があるデータ/制御チャネルの使用状況のタイプを指定するユーザトランスポートパラメータを入力します。ノートは、既存のサーバー・プールを接合する際に、PEは、プールの全体的なトランスポート・タイプおよび全体的なデータ/制御チャネルの使用に従わなければなりません。そうしないと、登録はENRPサーバによって拒否されることがあります。
R2.5) Fill in the preferred Pool Member Selection Policy parameter.
R2.5）が好ましいプールメンバー選択方針パラメータを入力します。
R3) Send the ASAP_REGISTRATION message to the Home ENRP server using SCTP.
R3）は、SCTPを使用してホームENRPサーバにASAP_REGISTRATIONメッセージを送信します。
R4) Start a T2-registration timer.
R4）T2-登録タイマーを起動します。
Note: the PE does not need to fill in the optional ASAP transport parameter. The ASAP transport parameter will be filled in and used by the Home ENRP server.
注意：PEは、オプションできるだけ早く輸送パラメータに記入する必要はありません。できるだけ早く輸送パラメータが記入し、ホームENRPサーバによって使用されます。
If the T2-registration timer expires before receiving an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the PE shall start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server, the PE SHOULD restart the registration procedure.
T2-登録タイマは、SCTP層から受信されたASAP_REGISTRATION_RESPONSEメッセージ、またはSEND.FAILURE通知を受信する前に満了する場合、PEは、サーバーのハントの手順を開始するものと異なるENRPサーバからサービスを取得しようとする試みで（セクション3.6を参照してください） 。新しいホームENRPサーバを確立した後、PEは、登録手順を再起動する必要があります。
At the reception of the registration response, the PE MUST stop the T2-registration timer. If the response indicates success, the PE is registered and will be considered an available member of the server pool. If the registration response indicates a failure, the PE must either re-attempt registration after correcting the error or return a failure indication to the PE's upper layer. The PE MUST NOT re-attempt registration without correcting the error condition.
登録応答の受信時に、PEは、T2-登録タイマを停止する必要があります。応答が成功を示す場合、PEが登録され、サーバー・プールの使用可能なメンバーとみなされます。登録応答が失敗を示す場合、PEは、誤差を補正した後、またはPEの上位層に失敗の表示を返すのいずれかの再試行登録しなければなりません。 PEは、エラー条件を修正せずに登録を再試行してはなりません。
At any time, a registered PE MAY wish to re-register to either update its member selection Policy Value or registration expiration time. When re-registering, the PE MUST use the same PE identifier.
任意の時点で、登録されたPEは、そのメンバー選択ポリシー値または登録の有効期限時刻を更新するか再登録することを望むかもしれません。再登録するとき、PEは、同じPEの識別子を使用しなければなりません。
After successful registration, the PE MUST start a T4-reregistration timer. At its expiration, a re-registration SHOULD be made starting at step R1, including (at completion) restarting the T4- reregistration timer.
登録が成功した後、PEはT4-再登録タイマーを起動する必要があります。その満了時に、再登録は、T4-の再登録タイマを再起動（終了時）を含む、ステップR1で開始されるべきです。
Note that an implementation SHOULD keep a record of the number of registration (and re-registration) attempts it makes in a local variable that gets set to zero before the initial registration attempt to the Home ENRP server or after a successful re-registration. If repeated registration timeouts or failures occurs and the local count exceeds the Threshold 'MAX-REG-ATTEMPT', the implementation SHOULD report the error to its upper layer and stop attempting registration.
実装が登録（再登録）の数を記録しておくべきであることに注意することは、ホームENRPサーバへの初期登録の試みの前または成功した再登録後にゼロに設定されますローカル変数になりますしようとします。繰り返し登録タイムアウトや障害が発生し、地元のカウントがしきい値「MAX-REG-ATTEMPT」を超えた場合、実装は、その上位層にエラーを報告し、登録をしようと停止する必要があります。
The ENRP server handles the ASAP_REGISTRATION message according to the following rules:
ENRPサーバは、次の規則に従ってASAP_REGISTRATIONメッセージを処理します。
1. If the named pool does not exist in the handlespace, the ENRP server MUST create a new pool with that handle in the handlespace and add the PE to the pool as its first PE.
1.名前のプールがhandlespaceに存在しない場合は、ENRPサーバはhandlespaceにそのハンドルを使用して新しいプールを作成し、その最初のPEとしてプールにPEを加えなければなりません。
When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first
PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the
registering PE.
2. If the named pool already exists in the handlespace, but the requesting PE is not currently a member of the pool, the ENRP server will add the PE as a new member to the pool.
2.名前のプールがすでにhandlespaceに存在しますが、要求元のPEは、現在のプールのメンバーでない場合、ENRPサーバは、プールへの新しいメンバーとしてPEを追加します。
However, before adding the PE to the pool, the server MUST check
if the policy type, transport type, and transport usage indicated
by the registering PE is consistent with those of the pool. If
different, the ENRP server MUST reject the registration.
3. If the named pool already exists in the handlespace *and* the requesting PE is already a member of the pool, the ENRP server SHOULD consider this as a re-registration case. The ENRP server MUST perform the same tests on policy, transport type, and transport use, as described above. If the re-registration is accepted after the test, the ENRP server SHOULD replace the attributes of the existing PE with the information carried in the received ASAP_REGISTRATION message.
3.名前のプールがすでに要求してPEが既にプールのメンバーである* handlespaceに存在し、*場合は、ENRPサーバは、再登録のケースとしてこれを考慮する必要があります。上記のようにENRPサーバは、ポリシー、トランスポート・タイプ、および輸送用途に同じテストを実行しなければなりません。再登録は、試験後に受理された場合、ENRPサーバは、受信したASAP_REGISTRATIONメッセージで運ばれる情報を既存のPEの属性を置き換えてください。
4. After accepting the registration, the ENRP server MUST assign itself the owner of this PE. If this is a re-registration, the ENRP server MUST take over ownership of this PE, regardless of whether the PE was previously owned by this server or by another server. The ENRP server MUST also record the SCTP transport address from which it received the ASAP_REGISTRATION in the ASAP Transport parameter TLV inside the PE parameter of this PE.
4.登録を受け付けた後、ENRPサーバは、このPEの所有者自体を割り当てる必要があります。これは、再登録の場合は、ENRPサーバは関係なく、PEが以前にこのサーバまたは別のサーバが所有していたかどうかの、このPEの所有権を引き継ぐ必要があります。 ENRPサーバはまた、このPEのPEパラメータの内部に、ASAP交通パラメータTLVにASAP_REGISTRATIONを受信し、そこからSCTPトランスポートアドレスを記録しなければなりません。
5. The ENRP server may reject the registration due to other reasons such as invalid values, lack of resource, authentication failure, etc.
5. ENRPサーバは、そのような等無効な値、リソースの不足、認証失敗などの他の理由で登録を拒否することができます
In all above cases, the ENRP server MUST reply to the requesting PE with an ASAP_REGISTRATION_RESPONSE message. If the registration is accepted, the ENRP server MUST set the R flag in the ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, the ENRP server MUST indicate the rejection by setting the R flag in the ASAP_REGISTRATION_RESPONSE to '1'.
上記のすべての場合において、ENRPサーバはASAP_REGISTRATION_RESPONSEメッセージで要求PEに応答しなければなりません。登録が受け入れられた場合、ENRPサーバは、「0」にASAP_REGISTRATION_RESPONSEでRフラグを設定しなければなりません。登録が拒否された場合、ENRPサーバは、「1」にASAP_REGISTRATION_RESPONSEでRフラグを設定することにより、拒絶反応を示さなければなりません。
If the registration is rejected, the ENRP server SHOULD include the proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message.
登録が拒否された場合は、ENRPサーバはASAP_REGISTRATION_RESPONSEメッセージに適切なエラー原因（複数可）を含むべきです。
If the registration is granted (either a new registration or a re-registration case), the ENRP server MUST assign itself to be the Home ENRP server of the PE, i.e., to "own" the PE.
登録は（新規登録または再登録の場合のいずれか）、許可された場合、ENRPサーバはPEを「所有」すること、すなわち、PEのホームENRPサーバであること自体を割り当てる必要があります。
Implementation note: For better performance, the ENRP server may find it both efficient and convenient to internally maintain two separate PE lists or tables -- one is for the PEs that are owned by the ENRP server and the other is for all the PEs owned by their peer(s).
実装上の注意：より良いパフォーマンスを得るために、ENRPサーバは内部的に効率的で便利なの両方それを見つけることが二つの別々のPEのリストまたはテーブルを維持する - 1はENRPサーバによって所有されているのPE用で、もう一方が所有するすべてのPEのためでありますそのピア（複数可）。
Moreover, if the registration is granted, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. If the registration is denied, no message will be sent to its peers.
登録が許可されている場合また、ENRPサーバは、ちょうど行われた変更について同輩に知らせるためにhandlespaceアップデート行動を取る必要があります。登録が拒否された場合、メッセージはそのピアに送信されません。
In the event a PE wishes to de-register from its server pool (normally, via an upper-layer request, see Section 6.2), it SHOULD use the following procedure. It should be noted that an alternate method of de-registration is to NOT re-register and to allow the registration life of the PE to expire. In this case, an ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP Endpoint to indicate the removal of the PE from the pool it registered.
PEは、そのサーバプールから登録解除することを希望する場合（通常は、上位層の要求を介して、セクション6.2を参照）は、以下の手順を使用すべきです。登録解除する別の方法ではなく再登録するとPEの登録寿命の期限が切れるようにすることであることに留意すべきです。この場合、ASAP_DEREGISTRATION_RESPONSEメッセージは、それが登録されたプールからのPEの除去を示すために、PEのASAPのエンドポイントに送信されます。
When de-registering, the PE SHOULD use the SCTP association that was used for registration with its Home ENRP server. To de-register, the PE's ASAP Endpoint MUST take the following actions:
解除登録すると、PEはそのホームENRPサーバへの登録に使用したSCTPアソシエーションを使用すべきです。登録解除するには、PEのできるだけ早くエンドポイントは、次のアクションを実行する必要があります
D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION message (Section 2.2.2) using the same Pool Handle parameter sent during registration.
D1）登録中に送られた同じプール・ハンドルパラメータを使用してASAP_DEREGISTRATIONメッセージ（2.2.2項）のプール・ハンドルパラメータを入力します。
D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION message. The identifier MUST be the same as used during registration. The use of the same Pool Handle and Pool Identifier parameters used in registration allows the identity of the PE ASAP Endpoint to be verified before de-registration can occur.
D2）ASAP_DEREGISTRATIONメッセージのPE識別子パラメータを入力します。登録時に使用される識別子は同じでなければなりません。登録に使用したのと同じプール・ハンドルとプール識別子パラメータの使用は、登録抹消が発生する前に、ASAP PEエンドポイントのアイデンティティを検証することを可能にします。
D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server using the PE's SCTP association.
D3）は、PEのSCTPアソシエーションを使用してホームENRPサーバにASAP_DEREGISTRATIONメッセージを送信します。
D4) Start a T3-Deregistration timer.
D4）T3-登録解除タイマーを起動します。
If the T3-Deregistration timer expires before receiving either an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification from the PE's SCTP endpoint, the PE's ASAP Endpoint shall start the ENRP Server Hunt procedure (see Section 3.6) in an attempt to get service from another ENRP server. After establishing a new Home ENRP server, the ASAP Endpoint SHOULD restart the de-registration procedure.
T3-登録解除タイマーがASAP_REGISTRATION_RESPONSEメッセージ、またはPEのSCTPエンドポイントからSEND.FAILURE通知のいずれかを受信する前に満了した場合、PEの至急エンドポイントは、ENRPサーバハント手順を開始するものと別からサービスを取得しようとする試みで（セクション3.6を参照してください） ENRPサーバ。新しいホームENRPサーバを確立した後、できるだけ早くエンドポイントは、登録解除の手続きを再起動する必要があります。
At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP endpoint MUST stop the T3-Deregistration timer.
ASAP_DEREGISTRATION_RESPONSEのレセプションでは、PEの至急のエンドポイントは、T3-登録解除タイマーを停止する必要があります。
It should be noted that after a successful de-registration, the PE MAY still receive requests for some period of time. The PE MAY wish to remain active and service these requests or to exit and ignore these requests.
成功した登録解除した後、PEはまだ一定の時間のための要求を受信することができることに留意すべきです。 PEはアクティブのままとこれらの要求にサービスを提供するか、終了し、これらの要求を無視するようにすることもできます。
Upon receiving the message, the ENRP server SHALL remove the PE from its handlespace. Moreover, if the PE is the last one of the named pool, the ENRP server will remove the pool from the handlespace as well.
メッセージを受信すると、ENRPサーバはhandlespaceからPEを除去SHALL。 PEは、名前付きプールの最後のものであればまた、ENRPサーバは、同様handlespaceからプールを削除します。
If the ENRP server fails to find any record of the PE in its handlespace, it SHOULD consider the de-registration granted and completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the PE.
ENRPサーバはそのhandlespaceでPEの任意のレコードを検索するために失敗した場合、それが許可され、完了し登録解除を検討し、PEにASAP_DEREGISTRATION_RESPONSEメッセージを送るべきです。
The ENRP server may reject the de-registration request for various reasons, such as invalid parameters, authentication failure, etc.
ENRPサーバは、無効なパラメータ等、認証の失敗、などの様々な理由のために登録解除要求を拒否することができます
In response, the ENRP server MUST send an ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-registration is rejected, the ENRP server MUST indicate the rejection by including the proper Operational Error parameter.
応答では、ENRPサーバはPEにASAP_DEREGISTRATION_RESPONSEメッセージを送らなければなりません。登録解除が拒否された場合、ENRPサーバは、適切な運用エラーパラメータを含むことにより、拒絶反応を示す必要があります。
It should be noted that de-registration does not stop the PE from sending or receiving application messages.
登録解除は、アプリケーション・メッセージを送信または受信からPEを停止しないことに留意すべきです。
Once the de-registration request is granted *and* the PE removed from its local copy of the handlespace, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. Otherwise, the ENRP server MUST NOT inform its peers.
登録解除要求は*と* PEはhandlespaceのローカルコピーから削除付与されると、ENRPサーバは、ちょうど行われた変更について同輩に知らせるためにhandlespaceアップデート行動を取る必要があります。それ以外の場合は、ENRPサーバはそのピアに通知してはなりません。
At any time, a PE or PU may wish to resolve a handle. This usually will occur when an ASAP Endpoint sends a Pool Handle (Section 6.5.1) to its Home ENRP server or requests a cache population (Section 6.3). It may also occur for other reasons (e.g., the internal ASAP PE wishes to know its peers to send a message to all of them). When an ASAP Endpoint (PE or PU) wishes to resolve a pool handle to a list of accessible transport addresses of the member PEs of the pool, it MUST take the following actions:
いつでも、PEまたはPUは、ハンドルを解決することを望むかもしれません。できるだけ早くエンドポイントは、そのホームENRPサーバにプール・ハンドル（6.5.1項）を送信またはキャッシュ人口（6.3節）を要求したときにこれは通常発生します。また、（例えば、内部のASAP PEは、それらのすべてにメッセージを送信するために、そのピアを知りたい）他の理由のために起こり得ます。できるだけ早くエンドポイント（PEまたはPU）は、プールのメンバーPEのアクセストランスポート・アドレスのリストにプールハンドルを解決しようとするとき、次のことを行う必要があります。
NR1) Fill in an ASAP_HANDLE_RESOLUTION message (Section 2.2.5) with the Pool Handle to be resolved.
NR1）プール・ハンドル付きASAP_HANDLE_RESOLUTIONメッセージ（セクション2.2.5）に記入が解決されます。
NR2) If the endpoint does not have a Home ENRP server, start the ENRP Server Hunt procedures specified in Section 3.6 to obtain one. Otherwise, proceed to step NR3.
エンドポイントはホームENRPサーバを持っていない場合NR2）は、1を得るために、セクション3.6で指定されたENRPサーバハントの手続きを開始します。それ以外の場合は、NR3に進みます。
NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server using SCTP; if a PU, send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server using either TCP or SCTP. If sent from a PE, the SCTP association used for registration SHOULD be used.
NR3）PEた場合は、SCTPを使用して、ホームENRPサーバへASAP_HANDLE_RESOLUTIONメッセージを送ります。 PU場合、TCPまたはSCTPのいずれかを使用してホームENRPサーバへASAP_HANDLE_RESOLUTIONメッセージを送信します。 PEから送信された場合は、登録のために使用されるSCTPアソシエーションを使用すべきです。
NR4) Start a T1-ENRPrequest timer.
NR4）T1-ENRPrequestタイマーを起動します。
If the T1-ENRPrequest timer expires before receiving a response message, the ASAP Endpoint SHOULD take the steps described in Section 3.7.2. If a SEND.FAILURE notification is received from the SCTP or TCP layer, the ASAP Endpoint SHOULD start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server, the ASAP Endpoint SHOULD restart the handle resolution procedure.
T1-ENRPrequestタイマーが応答メッセージを受信する前に満了した場合は、できるだけ早くエンドポイントは、セクション3.7.2で説明する手順を取る必要があります。 SEND.FAILURE通知がSCTPまたはTCPレイヤから受信された場合は、できるだけ早くエンドポイントは、別のENRPサーバからサービスを取得しようとする試みで（セクション3.6を参照）サーバーハントの手順を開始する必要があります。新しいホームENRPサーバを確立した後、できるだけ早くエンドポイントは、ハンドル解決手順を再起動する必要があります。
At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message, the ASAP Endpoint MUST stop its T1-ENRPrequest timer. After stopping the T1-ENRPrequest timer, the ASAP Endpoint SHOULD process the message as appropriate (e.g., populate a local cache, give the response to the ASAP User, and/or use the response to send the ASAP User's message).
ASAP_HANDLE_RESOLUTION_RESPONSEメッセージの受信時に、ASAPのエンドポイントは、T1-ENRPrequestタイマーを停止する必要があります。 T1-ENRPrequestタイマを停止した後、できるだけ早くエンドポイント（例えば、ローカルキャッシュを移植できるだけ早くユーザーに応答を与え、及び/又は、ASAPユーザメッセージを送信するために応答を使用して）必要に応じてメッセージを処理しなければなりません。
Note that some ASAP Endpoints MAY use a cache to minimize the number of handle resolutions sent. If a cache is used, it SHOULD:
一部できるだけ早くエンドポイントが送信されたハンドル解像度の数を最小限にするためにキャッシュを使用することができることに注意してください。キャッシュを使用する場合は、必要があります。
C1) Be consulted before sending a handle resolution.
C1）は、ハンドルの解像度を送信する前に相談すること。
C2) Have a stale timeout timer associated with each cache entry. If the cache entry is determined to be stale upon a cache hit, a handle resolution message SHOULD be sent so the cache can be updated.
C2）は、各キャッシュエントリに関連付けられた古いタイムアウトタイマーを持っています。キャッシュエントリがキャッシュヒット時に陳腐であると判断された場合はキャッシュを更新することができますので、ハンドル解決メッセージを送ってください。
C3) In the case of a stale cache entry, the implementation may, in parallel, update the cache and answer the request, or it may block the user and wait for an updated cache before proceeding with the users request.
C3）古いキャッシュエントリの場合、実装は、並行して、キャッシュを更新し、要求に応答することができる、またはそれは、ユーザをブロックし、ユーザの要求に進む前に更新されたキャッシュを待つことができます。
C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a handle resolution request but instead SHOULD use the entry from the cache.
キャッシュエントリが古くなっていない場合はC4）、エンドポイントは、ハンドル解決要求を送信することはできませんが、代わりにキャッシュからエントリを使用すべきです。
It should be noted that the impact of using a cache depends on the policy and the requirements of the application. For some applications, cache-usage can increase the performance of the system; for some, it can decrease it.
キャッシュを使用しての影響は政策やアプリケーションの要件に依存することに注意すべきです。一部のアプリケーションでは、キャッシュの使用は、システムのパフォーマンスを向上させることができます。いくつかのために、それを減らすことができます。
An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION requests from PUs, either over an SCTP association on the well-known SCTP port, or over a TCP connection on the well-known TCP port.
ENRPサーバは、いずれかのよく知られたSCTPポート上のSCTPアソシエーションを超える、またはよく知られたTCPポート上のTCP接続を介して、各PUからASAP_HANDLE_RESOLUTION要求を受信するために準備する必要があります。
Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server MUST first look up the pool handle in its handlespace. If the pool exists, the Home ENRP server MUST compose and send back an ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.
ASAP_HANDLE_RESOLUTIONメッセージを受信すると、ENRPサーバは、最初にそのhandlespaceでプール・ハンドルをルックアップする必要があります。プールが存在する場合は、ホームENRPサーバを構成し、要求元のPUにASAP_HANDLE_RESOLUTION_RESPONSEメッセージを返送しなければなりません。
In the response message, the ENRP server SHOULD list all the PEs currently registered in this pool, in a list of PE parameters. The ENRP server MUST also include a pool member selection policy parameter to indicate the overall member selection policy for the pool, if the current pool member selection policy is not Round-Robin.
応答メッセージに、ENRPサーバはPEパラメータのリストに、現在このプールに登録されているすべてのPEをリストする必要があります。 ENRPサーバは、現在のプールメンバー選択ポリシーがラウンドロビンでない場合は、プールの全体的なメンバー選択方針を示すために、プールメンバー選択方針パラメータを含まなければなりません。
If the named pool does not exist in the handlespace, the ENRP server MUST reject the handle resolution request by responding with an ASAP_HANDLE_RESOLUTION_RESPONSE message carrying an Unknown Pool Handle error.
名前のプールがhandlespaceに存在しない場合は、ENRPサーバは不明プール・ハンドルのエラーを運ぶASAP_HANDLE_RESOLUTION_RESPONSEメッセージで応答することにより、ハンドル解決要求を拒絶しなければなりません。
The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a PE in order to verify it is reachable. If the transport level heartbeat mechanism is insufficient, this message can be used in a heartbeat mechanism for the ASAP level whose goal is determining the health status of the ASAP level in a timely fashion. (The transport level heartbeat mechanism may be insufficient due to either the timeouts or the heartbeat interval being set too long, or, that the transport level heartbeat mechanism's coverage is limited only to the transport level at the two ends.) Additionally, the ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of fault detection if the SCTP stack is in the kernel. In such a case, while the SCTP-level heartbeat monitors the end-to-end connectivity between the two SCTP stacks, the ASAP-level heartbeat monitors the end-to-end liveliness of the ASAP layer above it.
ASAP_ENDPOINT_KEEP_ALIVEメッセージが到達可能であることを確認するためにPEにENRPサーバによって送信されます。トランスポート・レベルのハートビートメカニズムが不十分である場合、このメッセージは、目標タイムリーにできるだけ早くレベルの健康状態を決定することですできるだけ早くレベルのハートビート・メカニズムで使用することができます。 （トランスポートレベルのハートビート機構は、トランスポートレベルのハートビート機構のカバレッジのみ両端のトランスポートレベルに限定されることは、タイムアウトにより又は長すぎる設定されているハートビート間隔のいずれかに不十分であること、又はもよい。）また、ASAP_ENDPOINT_KEEP_ALIVEメッセージSCTPスタックがカーネルにある場合は、故障検出の信頼性の値を持っています。 SCTPレベルのハートビートは、2つのSCTPスタック間のエンドツーエンドの接続性を監視しながら、このような場合には、できるだけ早くレベルのハートビートは、その上のASAP層のエンドツーエンドの活気を監視します。
The use of the ASAP_ENDPOINT_KEEP_ALIVE message (Section 2.2.7) and the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following actions MUST be taken:
ASAP_ENDPOINT_KEEP_ALIVEメッセージ（セクション2.2.7）とASAP_ENDPOINT_KEEP_ALIVE_ACK（セクション2.2.8）の使用について説明します。 ASAP_ENDPOINT_KEEP_ALIVEメッセージを受信すると、以下のアクションを取らなければなりません。
KA1) The PE must verify that the Pool Handle is correct and matches the Pool Handle sent in its earlier ASAP_REGISTRATION message. If the Pool Handle does not match, the PE MUST silently discard the message.
KA1）PEは、プール・ハンドルが正しく、プールが以前ASAP_REGISTRATIONメッセージで送信されるハンドルと一致することを確認しなければなりません。プール・ハンドルが一致しない場合、PEは静かにメッセージを捨てなければなりません。
KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as follows:
KA2）ASAP_ENDPOINT_KEEP_ALIVE_ACKを送信します（セクション2.2.8）は次のよう：
KA2.1) Fill in the Pool Handle parameter with the PE's Pool Handle.
KA2.1）PEのプール・ハンドル付きプール・ハンドルパラメータを入力します。
KA2.2) Fill in the PE Identifier parameter using the PE identifier used by this PE for registration.
KA2.2）登録のために、このPEによって使用されるPEの識別子を使用してPE識別子パラメータを入力します。
KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the appropriate SCTP association for the ENRP server that sent the ASAP_ENDPOINT_KEEP_ALIVE message.
KA2.3）ASAP_ENDPOINT_KEEP_ALIVEメッセージを送信したENRPサーバの適切なSCTPアソシエーションを介しASAP_ENDPOINT_KEEP_ALIVE_ACKメッセージを送ります。
KA2.4) If the H flag in the received ASAP_ENDPOINT_KEEP_ALIVE message is set, and the Server Identifier in the message is NOT the identity of your Home ENRP server (or it is not set, e.g., you have a no Home ENRP server) adopt the sender of the ASAP_ENDPOINT_KEEP_ALIVE message as the new Home ENRP server.
KA2.4）受信ASAP_ENDPOINT_KEEP_ALIVEメッセージ中のHフラグが設定され、メッセージ中のサーバー識別子は、あなたのホームENRPサーバのアイデンティティではありません（またはそれは、例えば設定されていないされている場合は、あなたがいないホームENRPサーバを持っている）を採用新しいホームENRPサーバとしてASAP_ENDPOINT_KEEP_ALIVEメッセージの送信者。
Occasionally, an ASAP Endpoint may realize a PE is unreachable. This may occur by a specific SCTP error realized by the ASAP endpoint or via an ASAP User report via the Transport.Failure Primitive (Section 6.9.2). In either case, the ASAP Endpoint SHOULD report the unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE message to any ENRP server. Before sending the ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in the Pool Handle parameter and PE Identifier parameter of the unreachable endpoint. If the sender is a PE, the message MUST be sent via SCTP. It should be noted that an ASAP Endpoint MUST report no more than once each time it encounters such an event. Additionally, when processing a Transport.Failure Primitive (Section 6.9.2), the ASAP Endpoint MUST NOT send an ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous request to send data to the PE specified by the primitive.
時々、ASAPのエンドポイントは、PEが到達不能であると認識することができます。これは、ASAPエンドポイントによって、またはTransport.Failureプリミティブ（項6.9.2）を介して、ASAPユーザレポートを介して実現特定SCTPエラーによって起こり得ます。いずれの場合においても、できるだけ早くエンドポイントは、任意のENRPサーバにASAP_ENDPOINT_UNREACHABLEメッセージを送信することにより、PEの使用不能を報告すべきです。 ASAP_ENDPOINT_UNREACHABLEメッセージを送信する前に、ASAPのエンドポイントは、プール・ハンドルをパラメータと到達不能エンドポイントのPE識別子パラメータを記入すべきです。送信者がPEである場合、メッセージは、SCTPを介して送信されなければなりません。できるだけ早くエンドポイントは、それがこのようなイベントに遭遇するたびに一回以下で報告しなければならないことに留意すべきです。 Transport.Failureプリミティブ（節6.9.2）を処理するとき、ユーザはプリミティブで指定されたPEにデータを送信する前の要求をしていない限り、また、ASAPのエンドポイントはASAP_ENDPOINT_UNREACHABLEメッセージを送ってはいけません。
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, an ENRP server MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the H flag in the message SHOULD be set to '0', in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP server MUST consider the PE as truly unreachable and MUST remove the PE from its handlespace.
ASAP_ENDPOINT_UNREACHABLEメッセージを受信すると、ENRPサーバは直ちに問題のPEへのポイントツーポイントASAP_ENDPOINT_KEEP_ALIVEメッセージを送らなければなりません（メッセージにおけるHフラグは、この場合には、「0」に設定されるべきです）。このASAP_ENDPOINT_KEEP_ALIVEが失敗した場合は、ENRPサーバが真に到達不能としてPEを考慮する必要があり、そのhandlespaceからPEを除去しなければならない（例えば、それは、SCTP SEND.FAILURE通知をもたらします）。
If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully to the PE, the ENRP server MUST retain the PE in its handlespace. Moreover, the server SHOULD keep a counter to record how many ASAP_ENDPOINT_UNREACHABLE messages it has received reporting reachability problem relating to this PE. If the counter exceeds the protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE from its handlespace.
ASAP_ENDPOINT_KEEP_ALIVEメッセージがPEに正常に送信された場合、ENRPサーバはhandlespaceでPEを保持しなければなりません。また、サーバーは、このPEに関連する到達可能性の問題を報告して受信したどのように多くのASAP_ENDPOINT_UNREACHABLEメッセージを記録するカウンタを維持する必要があります。カウンタは、プロトコル閾値MAX-BAD-PE-REPORTを超える場合、ENRPサーバはhandlespaceからPEを削除する必要があります。
Optionally, an ENRP server may also periodically send point-to-point ASAP_ENDPOINT_KEEP_ALIVE (with the H flag set to '0') messages to each of the PEs owned by the ENRP server in order to check their reachability status. If the sending of ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the PE as unreachable and MUST remove the PE from its handlespace. Note, if an ENRP server owns a large number of PEs, the implementation should pay attention not to flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This can be achieved by varying the time between two ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/ minus 50 percent.
必要に応じて、ENRPサーバはまた、定期的に到達可能状態を確認するために、ENRPサーバが所有するPEのそれぞれにメッセージ（H「0」に設定されたフラグで）ポイントツーポイントASAP_ENDPOINT_KEEP_ALIVEを送信することができます。 PEにASAP_ENDPOINT_KEEP_ALIVEの送信が失敗した場合は、ENRPサーバが到達不能としてPEを考慮する必要があり、そのhandlespaceからPEを削除する必要があります。 ENRPサーバはPEの多数を所有している場合、実装はASAP_ENDPOINT_KEEP_ALIVEメッセージのバーストでネットワークを溢れさせないようにする注意を払う必要があり、注意してください。その代わり、実装は、時間をかけてASAP_ENDPOINT_KEEP_ALIVEメッセージトラフィックを配布する必要があります。これは、プラス/マイナス50％ランダムに同一のPEへの2つのASAP_ENDPOINT_KEEP_ALIVEメッセージ間の時間を変化させることによって達成することができます。
Each PU and PE manages a list of transport addresses of ENRP servers it knows about.
各PUとPEは、それは知っているENRPサーバのトランスポート・アドレスのリストを管理します。
If multicast capabilities are used within the operational scope, an ENRP server MUST send periodically every (N+1)*T6-Serverannounce an ASAP_SERVER_ANNOUNCE message (Section 2.2.10), which includes all the transport addresses available for ASAP communication on the multicast ENRP client channel, where N is the number of ENRP servers the server has found via receiving ASAP_SERVER_ANNOUNCE messages. This should result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per T6-Serverannounce.
マルチキャスト機能が動作範囲内で使用される場合、ENRPサーバは、定期的にマルチキャストENRPに、ASAPの通信のために利用可能なすべてのトランスポート・アドレスを含むすべての（N + 1）* T6-Serverannounce ASAP_SERVER_ANNOUNCEメッセージ（セクション2.2.10）を送らなければなりませんNは、サーバがASAP_SERVER_ANNOUNCEメッセージを受信を通じて発見したENRPサーバの数あるクライアントチャネル、。これは、T6-Serverannounceあたり約1 ASAP_SERVER_ANNOUNCEのメッセージレートをもたらすべきです。
If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it SHOULD insert all new included transport addresses into its list of ENRP server addresses and start a T7-ENRPoutdate timer for each address. For all already-known, included transport addresses, the T7-ENRPoutdate timer MUST be restarted for each address. If no transport parameters are included in the ASAP_SERVER_ANNOUNCE message, the SCTP transport protocol is assumed to be used and the source IP address and the IANA-registered ASAP port number is used for communication with the ENRP server. If a T7-ENRPoutdate timer for a transport address expires, the corresponding address is deleted from the managed list of transport addresses of the PU or PE.
ASAP_SERVER_ANNOUNCEメッセージはPUまたはPEによって受信された場合、それはENRPサーバアドレスのリストにすべての新しい含まトランスポートアドレスを挿入し、各アドレスのT7-ENRPoutdateタイマーを開始する必要があります。すべての既知の場合は、トランスポート・アドレスを含め、T7-ENRPoutdateタイマーは、各アドレスのために再起動する必要があります。いかなる輸送パラメータがASAP_SERVER_ANNOUNCEメッセージに含まれていない場合は、SCTPトランスポートプロトコルが使用されると仮定され、ソースIPアドレスと、ASAP IANA登録ポート番号はENRPサーバとの通信に使用されます。トランスポート・アドレスのためのT7-ENRPoutdateタイマーが満了した場合は、対応するアドレスは、PUまたはPEのトランスポート・アドレスの管理リストから削除されます。
If multicast capabilities are not used within the operational scope, each PU and PE MUST have a configured list of transport addresses of ENRP servers.
マルチキャスト機能が動作範囲内で使用されていない場合は、各PUとPEはENRPサーバのトランスポートアドレスの設定されたリストを持たなければなりません。
At its startup, or when it fails to communicate with its Home ENRP server (i.e., timed out on an ENRP request), a PE or PU MUST establish a new Home ENRP server (i.e., set up a TCP connection or SCTP association with a different ENRP server).
それはそのホームENRPサーバとの通信に失敗したときにその起動時、または、PEまたはPUは（新しいホームENRPサーバを確立しなければならない（すなわち、ENRP要求にタイムアウトになりました）、すなわちでTCP接続またはSCTP協会をセットアップします別のENRPサーバ）。
To establish a Home ENRP server, the following rules MUST be followed:
ホームENRPサーバを確立するには、以下の規則に従う必要があります。
SH1) The PE or PU SHOULD try to establish an association or connection, with no more than three ENRP servers. An ASAP Endpoint MUST NOT establish more than three associations or connections.
PEまたはPU SH1）は、3つ以下のENRPサーバと、結合または接続を確立しようとする必要があります。できるだけ早くエンドポイントは、以上の3つの団体または接続を確立してはなりません。
SH2) The ASAP Endpoint shall start a T5-Serverhunt timer.
SH2）できるだけ早くエンドポイントは、T5-Serverhuntタイマーをスタートします。
SH3) If the ASAP Endpoint establishes an association or connection it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD also reset the T5-Serverhunt timer to its initial value and then proceed to step SH6.
SH3）できるだけ早くエンドポイントは、そのT5-Serverhuntタイマーを停止しなければならない結合または接続を確立した場合。できるだけ早くエンドポイントもその初期値にT5-ServerhuntタイマーをリセットしてからSH6に進みべきです。
SH4) If an association or connection establishment fails, the ASAP Endpoint SHOULD try to establish an association or connection using a different transport address.
結合または接続の確立に失敗した場合SH4）は、できるだけ早くエンドポイントは、異なるトランスポートアドレスを使用して結合または接続を確立しようとする必要があります。
SH5) If the T5-Serverhunt timer expires, the following should be performed:
SH5）T5-Serverhuntタイマーが満了した場合は、以下を実行する必要があります。
SH5.1) The ASAP Endpoint MUST double the value of the T5- Serverhunt timer. Note that this doubling is capped at the value RETRAN.max.
SH5.1）できるだけ早くエンドポイントはT5- Serverhuntタイマーの値を倍にしなければなりません。この倍増は値RETRAN.maxで制限されることに注意してください。
SH5.2) The ASAP Endpoint SHOULD stop the establishment of associations and connections with the transport addresses selected in step SH1.
SH5.2）、ASAPエンドポイントは、ステップSH1で選択されたトランスポートアドレスとの関連との接続の確立を停止すべきです。
SH5.2) The ASAP Endpoint SHOULD repeat trying to establish an association or connection by proceeding to step SH1. It SHOULD attempt to select a different set of transport addresses with which to connect.
SH5.2）できるだけ早くエンドポイントは、SH1に進むことにより、結合または接続を確立しようとして繰り返す必要があります。それはと接続するためのトランスポート・アドレスの異なるセットを選択しようとすべきです。
SH6) The PE or PU shall pick one of the ENRP servers with which it was able to establish an association or connection, and send all subsequent ENRP request messages to this new Home ENRP server.
PEまたはPU SH6）は、結合または接続を確立することであったとENRPサーバのいずれかを選択し、この新しいホームENRPサーバへの後続のすべてのENRP要求メッセージを送信しなければなりません。
Three types of failure may occur when the ASAP Endpoint at either the PE or PU tries to communicate with an ENRP server:
3つの障害のタイプPEまたはPUのいずれかでのASAPエンドポイントはENRPサーバと通信しようとしたときに発生する可能性があります。
A) SCTP send failure
A）SCTPの送信失敗
B) T1-ENRPrequest timer expiration
B）T1-ENRPrequestタイマーの有効期限
C) Registration failure
C）登録の失敗
This communication failure indicates that the SCTP layer was unable to deliver a message sent to an ENRP server. In other words, the ENRP server is unreachable.
この通信障害は、SCTP層はENRPサーバに送信されたメッセージを配信できなかったことを示しています。言い換えれば、ENRPサーバが到達不能です。
In such a case, the ASAP Endpoint MUST NOT re-send the undeliverable message. Instead, it SHOULD discard the message and start the ENRP Server Hunt procedure as described in Section 3.6. After finding a new Home ENRP server, the ASAP Endpoint should re-send the request.
このような場合には、ASAPのエンドポイントは、配信不能メッセージを再送信してはいけません。代わりに、メッセージを破棄して、セクション3.6で説明したようにENRPサーバハントの手順を開始する必要があります。新しいホームENRPサーバを発見した後、できるだけ早くエンドポイントは、要求を再送信する必要があります。
Note that an ASAP Endpoint MAY also choose to NOT discard the message, but to queue it for retransmission after a new Home ENRP server is found. If an ASAP Endpoint does choose to discard the message, after a new Home ENRP server is found, the ASAP Endpoint MUST be capable of reconstructing the original request.
できるだけ早くエンドポイントは、メッセージを廃棄しないことを選択するかもしれないが、新しいホームENRPサーバが発見された後、再送信のためにそれをキューに入れることに注意してください。できるだけ早くエンドポイントは、新しいホームENRPサーバが発見された後、メッセージを破棄することを選択しない場合は、できるだけ早くエンドポイントは、元の要求を再構成することができなければなりません。
When the T1-ENRPrequest timer expires, the ASAP Endpoint should re-send the original request to the ENRP server and restart the T1- ENRPrequest timer. In parallel, the ASAP Endpoint should begin the ENRP server hunt procedures described in Section 3.6.
T1-ENRPrequestタイマーの期限が切れると、できるだけ早くエンドポイントは、ENRPサーバに元の要求を再送信し、T1〜ENRPrequestタイマーを再起動する必要があります。並行して、ASAPのエンドポイントは、セクション3.6で説明ENRPサーバハント手順を開始すべきです。
This should be repeated up to MAX-REQUEST-RETRANSMIT times. After that, an Error.Report notification should be generated to inform the ASAP User, and the ENRP request message associated with the T1- ENRPrequest timer should be discarded. It should be noted that if an alternate ENRP server responds, the ASAP Endpoint SHOULD adopt the responding ENRP server as its new Home ENRP server and re-send the request to the new Home ENRP server.
これは、MAX-REQUEST-RETRANSMIT回まで繰り返すべきです。その後、Error.Report通知は、できるだけ早くユーザーに通知するために生成されるべきであり、T1〜ENRPrequestタイマーに関連付けられているENRP要求メッセージは破棄されなければなりません。代替ENRPサーバが応答する場合、できるだけ早くエンドポイントは、その新しいホームENRPサーバとして応答ENRPサーバを採用すべきと新しいホームENRPサーバに要求を再送信ことに留意すべきです。
Registration failure is discussed in Section 3.1.
登録の失敗は、3.1節で議論されています。
Whenever a PE wants, and a control channel exists, it can send an ASAP_COOKIE message to a PU via the control channel. The PU's ASAP endpoint stores the Cookie parameter and discards an older cookie if it is previously stored.
PEが望んで、制御チャネルが存在するときはいつでも、それは、制御チャネルを介してPUにASAP_COOKIEメッセージを送信することができます。 PUのASAPのエンドポイントは、クッキーのパラメータを格納し、それが以前に格納されている場合、古いクッキーを破棄します。
Note: A control channel is a communication channel between a PU and PE that does not carry data passed to the user. This is accomplished with SCTP by using a PPID to separate the ASAP messages (Cookie and Business Card) from normal data messages.
注：制御チャネルはユーザに渡されるデータを搬送しないPUとPE間の通信チャネルです。これは、通常のデータメッセージから至急のメッセージ（クッキーやビジネスカード）を分離するためにPPIDを使用することによってSCTPを用いて達成されます。
If the PU's ASAP Endpoint detects a failure and initiates a failover to a different PE, it SHOULD send the latest received cookie parameter in an ASAP_COOKIE_ECHO message to the new PE as the first message on the control channel. Upper layers may be involved in the failover procedure.
PUのASAPのエンドポイントが障害を検出し、別のPEへのフェイルオーバーを開始した場合、それは、制御チャネル上の最初のメッセージとして新しいPEにASAP_COOKIE_ECHOメッセージに最新の受信クッキーパラメータを送るべきです。上位層は、フェイルオーバー手順に関与することができます。
The cookie handling procedure can be used for state sharing. Therefore, a cookie should be signed by the sending PE ASAP Endpoint and the cookie should be verified by the receiving PE's ASAP Endpoint. The details of the verification procedure are out of scope for this document. It is only important that the PU always stores the last received Cookie parameter and sends that back unmodified in case of a PE failure.
Cookie処理手順は、状態を共有するために使用することができます。したがって、送信PEのASAPエンドポイントとクッキーによって署名されなければならないクッキーは、受信PEのASAPのエンドポイントによって検証されるべきです。検証手順の詳細は、このドキュメントの範囲外です。 PUは、常に最後のクッキーパラメータを受信し、PEに障害が発生した場合には変更されていないことを送り返す保存することだけが重要です。
When communication begins between a PU and a PE, either of which could be part of a PU/PE combination (i.e., a message is sent between the entities), a PE should always send an ASAP_BUSINESS_CARD message to a PU. A PU should send an ASAP_BUSINESS_CARD message to a PE only if it is part of a PU/PE combination. An ASAP_BUSINESS_CARD message MUST ONLY be sent if a control channel exists between a PU and PE. After communication has been established between a PE and PU, a new ASAP_BUSINESS_CARD message may be sent at any time by either entity to update its failover order.
通信はPU及びPU / PEの組合せの一部とすることができるいずれものPE（すなわち、メッセージが、エンティティ間で送信される）との間で開始されると、PEは常にPUにASAP_BUSINESS_CARDメッセージを送信すべきです。 PUは、PU / PEの組み合わせの一部である場合にのみ、PEにASAP_BUSINESS_CARDメッセージを送信すべきです。制御チャネルはPUとPEとの間に存在する場合ASAP_BUSINESS_CARDメッセージのみが送信されなければなりません。通信は、PEとPUとの間に確立された後、新しいASAP_BUSINESS_CARDメッセージは、フェイルオーバー順序を更新するために、いずれかのエンティティによっていつでも送信することができます。
The ASAP_BUSINESS_CARD message serves two purposes. First, it lists the pool handle. For a PU that is part of a PU/PE combination that is contacting a PE, this is essential so that the PE learns the pool handle of the PU/PE combination requesting service. Secondly, the ASAP_BUSINESS_CARD message tells the receiving entity a failover order that is recommended to follow. This should facilitate rendezvous between entities that have been working together, as well as to control the load redistribution upon the failure of any PE.
ASAP_BUSINESS_CARDメッセージは2つの目的を果たします。まず、プール・ハンドルを示しています。 PEは、サービスを要求PU / PEの組み合わせのプール・ハンドルを学習するようにPEを接触さPU / PEの組み合わせの一部であるPUの場合、これは必須です。第二に、ASAP_BUSINESS_CARDメッセージは、受信エンティティ従うことを推奨されるフェイルオーバー順序を伝えます。これは、一緒に働いているだけでなく、任意のPEの故障時に負荷の再配分を制御するエンティティ間のランデブーを促進すべきです。
Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13), the receiving ASAP Endpoint SHOULD:
ASAP_BUSINESS_CARDメッセージを受信すると、エンドポイントは、ASAP SHOULD受信、（セクション2.2.13を参照のこと）。
BC1) Unpack the message, and if no entry exists in the translation cache of the receiving ASAP Endpoint for the pool handle listed within the ASAP_BUSINESS_CARD message, perform an ASAP_HANDLE_RESOLUTION for that pool handle. If the translation cache does hold an entry for the pool handle, then it may be necessary to update the peer endpoint.
BC1）メッセージをアンパックし、そしてエントリがASAP_BUSINESS_CARDメッセージ内に記載されているプールハンドルのASAPの受信エンドポイントの翻訳キャッシュに存在しない場合、そのプールのハンドルのASAP_HANDLE_RESOLUTIONを行います。翻訳キャッシュがプールハンドルのエントリを保持しない場合、ピアエンドポイントを更新する必要があるかもしれません。
BC2) Unpack the message and populate a preferred list for failover order. If the peer's PE should fail, this preferred list will be used to guide the ASAP Endpoint in the selection of an alternate PE.
BC2）メッセージを開梱し、フェールオーバーのための優先リストを作成します。ピアのPEが故障した場合、この好ましいリストは、代替PEの選択で、ASAPエンドポイントを案内するために使用されます。
A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION and ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ERROR messages. It MAY implement the handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE messages.
PUはASAP_HANDLE_RESOLUTIONとASAP_HANDLE_RESOLUTION_RESPONSEメッセージの処理を実装しなければなりません。さらに、それはASAP_ERRORメッセージの処理をサポートしなければなりません。それはASAP_COOKIE、ASAP_COOKIE_ECHO、およびASAP_BUSINESS_CARDメッセージの処理を実施することができます。また、ASAP_SERVER_ANNOUNCEメッセージの処理を実施することができます。
A PE MUST implement the handling of ASAP_REGISTRATION, ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ENDPOINT_KEEP_ALIVE, ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore, it MAY support the handling of ASAP_SERVER_ANNOUNCE messages.
PEはASAP_REGISTRATION、ASAP_DEREGISTRATION、ASAP_REGISTRATION_RESPONSE、及びASAP_DEREGISTRATION_RESPONSEメッセージの処理を実装しなければなりません。さらに、それはASAP_ENDPOINT_KEEP_ALIVE、ASAP_ENDPOINT_KEEP_ALIVE_ACK、ASAP_ENDPOINT_UNREACHABLE、およびASAP_ERRORメッセージの処理をサポートしなければなりません。それはASAP_COOKIE、ASAP_COOKIE_ECHO、およびASAP_BUSINESS_CARDメッセージの処理をサポートする必要があります。さらに、それはASAP_SERVER_ANNOUNCEメッセージの処理をサポートするかもしれません。
An ENRP server MUST implement the handling of ASAP_REGISTRATION, ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ENDPOINT_KEEP_ALIVE, ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ERROR messages. Furthermore, it MAY support the handling of ASAP_SERVER_ANNOUNCE messages.
ENRPサーバはASAP_REGISTRATION、ASAP_DEREGISTRATION、ASAP_REGISTRATION_RESPONSE、およびASAP_DEREGISTRATION_RESPONSEメッセージの処理を実装しなければなりません。さらに、それはASAP_ENDPOINT_KEEP_ALIVE、ASAP_ENDPOINT_KEEP_ALIVE_ACK、ASAP_ENDPOINT_UNREACHABLE、およびASAP_ERRORメッセージの処理をサポートしなければなりません。さらに、それはASAP_SERVER_ANNOUNCEメッセージの処理をサポートするかもしれません。
If a node acts as a PU and a PE, it MUST fulfill both roles.
ノードは、PUとPEとして機能する場合、それは両方の役割を満たさなければなりません。
Each ASAP message is considered as an SCTP user message. The PPID registered for ASAP SHOULD be used. The SCTP port used at the ENRP server might be preconfigured or announced in the ASAP_SERVER_ANNOUNCE message or the well-known ASAP port.
各至急メッセージはSCTPユーザメッセージとして考えられています。至急のために登録されたPPIDを使用する必要があります。 ENRPサーバで使用SCTPポートは、事前設定やASAP_SERVER_ANNOUNCEメッセージや、よく知られた、ASAPポートに発表される可能性があります。
ASAP messages belonging to the control channel MUST be sent using the PPID registered for ASAP. Messages belonging to the data channel MUST NOT use the PPID registered for ASAP.
できるだけ早く制御チャネルに属するメッセージは至急に登録さPPIDを使用させなければなりません。データチャネルに属しているメッセージは、できるだけ早くに登録さPPIDを使用してはなりません。
This chapter will focus primarily on the primitives and notifications that form the interface between the ASAP User and ASAP and that between ASAP and its lower-layer transport protocol (e.g., SCTP).
この章では、主に、ASAPとその下層のトランスポートプロトコル（例えば、SCTP）との間のASAP ASAPはユーザとの間の界面を形成するプリミティブと通知にその焦点を当てます。
Note, the following primitive and notification descriptions are shown for illustrative purposes. We believe that including these descriptions in this document is important to the understanding of the operation of many aspects of ASAP; but an ASAP implementation is not required to use the exact syntax described in this section.
ノートは、次のプリミティブ通知説明は例示の目的のために示されています。私たちは、この文書にこれらの記述を含むことは至急の多くの側面の動作を理解するのに重要であると信じています。しかし、できるだけ早く実装は、このセクションで説明する正確な構文を使用する必要はありません。
An ASAP User passes primitives to the ASAP sub-layer to request certain actions. Upon the completion of those actions or upon the detection of certain events, the ASAP layer will notify the ASAP User.
ASAPのユーザーが特定のアクションを要求するために、できるだけ早く副層にプリミティブを渡します。これらのアクションが完了すると、または特定のイベントを検出すると、ASAPの層は、できるだけ早くユーザーに通知します。
Format: registration.request(Pool Handle,
User Transport parameter(s))
The Pool Handle parameter contains a NULL terminated ASCII string of fixed length. The optional User Transport parameter(s) indicates specific transport parameters and types with which to register. If this optional parameter is left off, then the SCTP endpoint used to communicate with the ENRP server is used as the default User Transport parameter. Note that any IP address contained within a User Transport parameter MUST be a bound IP address in the SCTP endpoint used to communicate with the ENRP server.
プール・ハンドルのパラメータはNULLが固定長のASCII文字列を終了含まれています。オプションのユーザトランスポートパラメータ（複数も可）は、特定のトランスポートパラメータと登録するとタイプを示します。このオプションパラメータがオフに残っている場合は、SCTP終点は、ENRPサーバは、デフォルトのユーザー・交通パラメータとして使用されているとの通信に使用されます。ユーザートランスポートパラメータ内に含まれる任意のIPアドレスがENRPサーバとの通信に使用されるSCTP終点でバインドされたIPアドレスでなければならないことに注意してください。
The ASAP User invokes this primitive to add itself to the handlespace, thus becoming a Pool Element of a pool. The ASAP User must register itself with the ENRP server by using this primitive before other ASAP Users using the handlespace can send message(s) to this ASAP User by Pool Handle or by PE handle (see Sections 6.5.1 and 6.5.3).
できるだけ早くユーザーは、このようにプールのプール要素になってきて、handlespaceに自分自身を追加するには、このプリミティブを起動します。できるだけ早くユーザーはできるだけ早くhandlespaceを使用して、ユーザーがこのできるだけ早くプールすることにより、ユーザハンドルまたはPEハンドルによって（セクション6.5.1と6.5.3を参照）にメッセージ（複数可）を送信することができ、他の前に、このプリミティブを使用してENRPサーバに自身を登録する必要があります。
In response to the registration primitive, the ASAP Endpoint will send an ASAP_REGISTRATION message to the Home ENRP server (see Sections 2.2.1 and 3.1), and start a T2-registration timer.
登録プリミティブに対応して、できるだけ早くエンドポイントは、ホームENRPサーバへASAP_REGISTRATIONメッセージを送信します（セクション2.2.1と3.1を参照）、およびT2-登録タイマーを起動します。
Format: deregistration.request(Pool Handle)
フォーマット：deregistration.request（プール・ハンドル）
The ASAP PE invokes this primitive to remove itself from the Server Pool. This should be used as a part of the graceful shutdown process by the application.
できるだけ早くPEは、サーバー・プールから自分自身を削除するには、このプリミティブを起動します。これは、アプリケーションによって正常なシャットダウンプロセスの一部として使用する必要があります。
An ASAP_DEREGISTRATION message will be sent by the ASAP Endpoint to the Home ENRP server (see Sections 2.2.2 and 3.2).
ASAP_DEREGISTRATIONメッセージはホームENRPサーバにできるだけ早くエンドポイントによって送信されます（セクション2.2.2と3.2を参照してください）。
Format: cache_populate_request([Pool-Handle |
Pool-Element-Handle])
If the address type is a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should initiate a mapping information query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle and updating its local cache when the response comes back from the ENRP server.
アドレスタイプは、プール・ハンドルで、地元のハンドル変換キャッシュが存在する場合は、できるだけ早くエンドポイントはプールハンドルにASAP_HANDLE_RESOLUTIONメッセージを送信し、応答が戻ってENRPサーバから来るとき、ローカルキャッシュを更新することにより、マッピング情報のクエリを開始する必要があります。
If a Pool-Element-Handle is passed, then the Pool Handle is unpacked from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message is sent to the ENRP server for resolution. When the response message returns from the ENRP server, the local cache is updated.
プール・エレメント・ハンドルが渡された場合、プール・ハンドルはプール要素-ハンドルからアンパックされ、ASAP_HANDLE_RESOLUTIONメッセージが解決のためのENRPサーバに送信されます。応答メッセージがENRPサーバから返された場合、ローカルキャッシュが更新されます。
Note that if the ASAP service does NOT support a local cache, this primitive performs NO action.
このプリミティブを行いNOアクション、できるだけ早くサービスは、ローカルキャッシュをサポートしていない場合があります。
Format: cache_purge_request([Pool-Handle | Pool-Element-Handle])
フォーマット：cache_purge_request（[プール-ハンドル|プール要素-ハンドル]）
If the user passes a Pool Handle and local handle translation cache exists, the ASAP Endpoint should remove the mapping information on the Pool Handle from its local cache. If the user passes a Pool-Element-Handle, then the Pool Handle within is used for the cache_purge_request.
ユーザーがプールハンドルとローカルハンドル変換キャッシュが存在して合格した場合は、できるだけ早くエンドポイントは、ローカルキャッシュからハンドルプールのマッピング情報を削除する必要があります。ユーザーがプール要素ハンドルを渡した場合、プールは内部ハンドルcache_purge_requestのために使用されています。
Note that if the ASAP service does NOT support a local cache, this primitive performs NO action.
このプリミティブを行いNOアクション、できるだけ早くサービスは、ローカルキャッシュをサポートしていない場合があります。
Format: data_send_request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified Pool or Pool Element within the current Operational scope.
できるだけ早く現在の運用範囲内でいくつかの指定されたプールやプール要素にメッセージを送信するには、この原始的な要求。
Depending on the address type used for the send request, the sender's ASAP Endpoint may perform address translation and Pool Element selection before sending the message out. This MAY also dictate the creation of a local transport endpoint in order to meet the required transport type.
送信要求のために使用されるアドレスの種類に応じて、送信者のできるだけ早くエンドポイントは、メッセージを送信する前にアドレス変換やプール要素の選択を行うことができます。また、これは、必要なトランスポート・タイプを満たすために、地元の交通機関のエンドポイントの作成を指示することができます。
The data_send_request primitive can take different forms of address types, as described in the following sections.
次のセクションで説明したようにdata_send_requestプリミティブは、アドレスタイプの異なる形態をとることができます。
In this case, the destinationAddress and typeOfAddress together indicate a pool handle.
この場合、宛先アドレスとtypeOfAddressは、一緒にプールハンドルを示しています。
This is the simplest form of send_data_request primitive. By default, this directs ASAP to send the message to one of the Pool Elements in the specified pool.
これはsend_data_requestプリミティブの最も単純な形式です。デフォルトでは、これは、指定されたプールのプール要素の1つにメッセージを送信するためにできるだけ早く指示します。
Before sending the message out to the pool, the sender's ASAP endpoint MUST first perform a pool handle to address translation. It may also need to perform Pool Element selection if multiple Pool Elements exist in the pool.
プールにメッセージを送信する前に、送信者のできるだけ早くエンドポイントは、最初の翻訳に対処するためのプール・ハンドルを実行しなければなりません。また、複数のプール要素がプール内に存在する場合にはプール要素の選択を実行する必要があります。
If the sender's ASAP implementation does not support a local cache of the mapping information, or if it does not have the mapping information on the pool in its local cache, it will transmit an ASAP_HANDLE_RESOLUTION message (see Sections 2.2.5 and 3.3) to the current Home ENRP server and MUST hold the outbound message in queue while awaiting the response from the ENRP server (any further send request to this pool before the ENRP server responds SHOULD also be queued).
送信者のできるだけ早く実装は、マッピング情報のローカルキャッシュをサポートしていない、またはそれはそのローカルキャッシュにプールのマッピング情報を持っていない場合、それはに（セクション2.2.5と3.3を参照）ASAP_HANDLE_RESOLUTIONメッセージを送信する場合は現在のホームENRPサーバとENRPサーバ（ENRPサーバの応答もキューに入れられるべきである前に、さらにこのプールに要求を送信）からの応答を待っている間、キューに送信メッセージを保持しなければなりません。
Once the necessary mapping information arrives from the ENRP server, the sender's ASAP will:
必要なマッピング情報はENRPサーバから到着すると、送信者は意志至急です。
A) map the pool handle into a list of transport addresses of the destination PE(s);
A）先PE（S）のトランスポートアドレスのリストにプールハンドルをマッピングします。
B) if multiple PEs exist in the pool, choose one of them and transmit the message to it. In that case, the choice of the PE is made by the ASAP Endpoint of the sender based on the server pooling policy, as discussed in Section 6.5.2;
複数のPEがプールに存在する場合B）、それらのいずれかを選択し、それにメッセージを送信します。その場合には、PEの選択は、セクション6.5.2で説明したように、サーバプールポリシーに基づいて、送信者のASAPのエンドポイントによって行われます。
C) optionally create any transport endpoint that may be needed to communicate with the PE selected;
C）任意選択PEと通信するために必要とされ得る任意のトランスポートエンドポイントを作成します。
D) if no transport association or connection exists towards the destination PE, establish any needed transport state;
D）は、トランスポートアソシエーションまたは接続先のPEに向かって存在しない場合、任意の必要な搬送状態を確立します。
E) send out the queued message(s) to the appropriate transport connection using the appropriate send mechanism (e.g., for SCTP, the SEND primitive in [RFC4960] would be used); and,
E）適切な送信機構（例えば、SCTPのために、[RFC4960]にプリミティブSENDが使用される）を使用して適切なトランスポート接続のキューに入れられたメッセージ（単数または複数）を送り出します。そして、
F) if the local cache is implemented, append/update the local cache with the mapping information received in the ENRP server's response. Also, record the local transport information (e.g., the SCTP association id) if any new transport state was created.
Fローカルキャッシュが実装されている場合）、ENRPサーバの応答で受信したマッピング情報をローカルキャッシュを更新/追加します。また、新たな搬送状態が作成された場合、ローカルトランスポート情報（例えば、SCTPアソシエーションID）を記録します。
For more on the ENRP server request procedures see [RFC5353].
ENRPサーバ要求の手順の詳細については、[RFC5353]を参照してください。
Optionally, the ASAP Endpoint of the sender may return a Pool Element handle of the selected PE to the application after sending the message. This PE handle can then be used for future transmissions to that same PE (see Section 6.5.3).
必要に応じて、送信者のASAPのエンドポイントは、メッセージを送信した後、アプリケーションに選択されたPEのプール要素ハンドルを返すことができます。このPEのハンドルは、その同じPEへの将来の送信に使用することができます（第6.5.3項を参照してください）。
Section 3.7 defines the failover procedures for cases where the selected PE is found unreachable.
セクション3.7は、選択されたPEが到達不能検出された場合のフェイルオーバー手順を定義します。
Each time an ASAP User sends a message to a pool that contains more than one PE, the sender's ASAP Endpoint must select one of the PEs in the pool as the receiver of the current message. The selection is made according to the current server pooling policy of the pool to which the message is sent.
できるだけ早くユーザーが複数のPEが含まれているプールにメッセージを送信するたびに、送信者のできるだけ早くエンドポイントは、現在のメッセージの受信者として、プール内のPEのいずれかを選択しなければなりません。選択は、メッセージが送信されたプールの現在のサーバプールポリシーに従って行われます。
Note, no selection is needed if the ASAP_SEND_TOALL option is set (see Section 6.5.5).
ASAP_SEND_TOALLオプションが設定されている場合は、何も選択は必要ありません注意してください（6.5.5項を参照してください）。
Together with the server pooling policy, each PE can also specify a Policy Value for itself at the registration time. The meaning of the Policy Value depends on the current server pooling policy of the group. A PE can also change its Policy Value whenever it desires, by re-registering itself with the handlespace with a new Policy Value. Re-registration shall be done by simply sending another ASAP_REGISTRATION to its Home ENRP server (see Section 2.2.1).
一緒にサーバプーリング方針で、各PEはまた、登録時に自分自身のためのポリシーの値を指定することができます。ポリシー値の意味は、グループの現在のサーバプーリング方針に依存します。それは新しいポリシー値とhandlespaceで自身を再登録することで、希望する時はいつでもPEもそのポリシーの値を変更することができます。登録が再単にそのホームENRPサーバへの別のASAP_REGISTRATIONを送信することにより行われなければならない（2.2.1項を参照してください）。
One basic policy is defined in this document; others can be found in [RFC5356]
一つの基本方針は、このドキュメントで定義されています。他の人は[RFC5356]で見つけることができます
When an ASAP Endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP Endpoint of the sender will select the receiver for each outbound message by Round-Robining through all the registered PEs in that Pool, in an attempt to achieve an even distribution of outbound messages. Note that in a large server pool, the ENRP server might not send back all PEs to the ASAP client. In this case, the client or PU will be performing a Round-Robin policy on a subset of the entire Pool.
できるだけ早くエンドポイントは、プールでメッセージを送信すると、送信者の至急エンドポイントでは、そのプール内のすべての登録済みのPEによるラウンドロビン方式により、各アウトバウンドメッセージの受信者を選択しますハンドルとラウンドロビンは、そのプールの現在の方針でありますアウトバウンドメッセージの均一な分布を達成しようとします。大規模なサーバー・プールに、ENRPサーバはできるだけ早くクライアントに戻ってすべてのPEを送信しない場合があります。この場合、クライアントまたはPUは、プール全体のサブセットのラウンドロビンポリシーを実行します。
In this case, the destinationAddress and typeOfAddress together indicate an ASAP Pool Element handle.
この場合、宛先アドレスとtypeOfAddressは一緒にできるだけ早くプール要素ハンドルを示しています。
This requests that the ASAP Endpoint deliver the message to the PE identified by the Pool Element handle.
これは、できるだけ早くエンドポイントプール要素ハンドルで識別されるPEにメッセージを配信することを要求します。
The Pool Element handle should contain the Pool Handle and a destination transport address of the destination PE or the Pool Handle and the transport type. Other implementation dependent elements may also be cached in a Pool Element handle.
プール要素ハンドルはプールハンドルと宛先PEまたはプールハンドルとトランスポート・タイプの宛先トランスポートアドレスが含まれている必要があります。その他の実装に依存する要素もプール要素ハンドルにキャッシュすることができます。
The ASAP Endpoint shall use the transport address and transport type to identify the endpoint with which to communicate. If no communication state exists with the peer endpoint (and is required by the transport protocol), the ASAP Endpoint MAY set up the needed state and then invoke the SEND primitive for the particular transport protocol to send the message to the PE.
ASAPのエンドポイントは、通信するエンドポイントを識別するためのトランスポートアドレス及びトランスポートタイプを使用しなければなりません。いかなる通信状態は、ピアエンドポイントと存在しない（およびトランスポート・プロトコルにより要求される）場合、ASAPのエンドポイントは、必要な状態を設定した後、PEにメッセージを送信するための特定のトランスポートプロトコルのプリミティブSENDを呼び出すことができます。
In addition, if a local translation cache is supported, the endpoint will:
また、地元の変換キャッシュがサポートされている場合、エンドポイントは以下となります。
A) send out the message to the transport address (or association id) designated by the PE handle.
A）PEハンドルによって指定されたトランスポートアドレス（またはアソシエーションID）にメッセージを送信します。
B) determine if the Pool Handle is in the local cache.
B）プール・ハンドルがローカルキャッシュにあるかどうかを確認します。
If it is *not*, the endpoint will:
それは* *でない場合、エンドポイントは以下となります。
i) ask the Home ENRP server for handle resolution on the pool handle by sending an ASAP_HANDLE_RESOLUTION message (see Section 2.2.5), and
I）（セクション2.2.5を参照）ASAP_HANDLE_RESOLUTIONメッセージを送信することにより、プール・ハンドルのハンドル解決のためのホームENRPサーバを尋ねると、
ii) use the response to update the local cache.
ⅱ）ローカルキャッシュを更新するために応答を使用しています。
If the pool handle is in the cache, the endpoint will only update the pool handle if the cache is stale. A stale cache is indicated by it being older than the protocol parameter 'stale.cache.value' (see Section 7.2).
プール・ハンドルがキャッシュにある場合、キャッシュが古くなっている場合、エンドポイントは唯一のプール・ハンドルを更新します。古いキャッシュは、それはプロトコルパラメータ「stale.cache.value」より年上であることによって示されている（7.2節を参照してください）。
Sections 3.5 and 6.9 define the failover procedures for cases where the PE pointed to by the Pool Element handle is found to be unreachable.
セクション3.5および6.9は、PEがプール要素ハンドルによって指さが到達不能であることが判明した場合のフェイルオーバー手順を定義します。
Optionally, the ASAP Endpoint may return the actual Pool Element handle to which the message was sent (this may be different from the Pool Element handle specified when the primitive is invoked, due to the possibility of automatic failover).
任意に、ASAPのエンドポイント（これはプリミティブが呼び出されたときにより自動フェイルオーバーの可能性に、指定されたハンドルプール要素は異なっていてもよい）は、実際のプール要素は、メッセージが送信された先のハンドル戻してもよいです。
In this case, the destinationAddress and typeOfAddress together indicate a transport address and transport type.
この場合には、宛先アドレスとtypeOfAddressは一緒にトランスポートアドレス及びトランスポート・タイプを示します。
This directs the sender's ASAP Endpoint to send the message out to the specified transport address.
これは、指定されたトランスポートアドレスにメッセージを送信する送信者のできるだけ早くエンドポイントを指示します。
No endpoint failover is supported when this form of send request is used. This form of send request effectively bypasses the ASAP endpoint.
送信要求のこのフォームを使用した場合いかなるエンドポイント・フェイルオーバーはサポートされていません。送信要求のこの形式は、効果的にできるだけ早くエンドポイントをバイパスします。
The Options parameter passed in the various forms of the above data_send_request primitive gives directions to the sender's ASAP endpoint on special handling of the message delivery.
プリミティブdata_send_request上記の様々な形で渡されたオプションのパラメータは、メッセージ配信の特別な処理に送信者の至急エンドポイントに指示を与えます。
The value of the Options parameter is generated by bit-wise "OR"ing of the following pre-defined constants:
オプションパラメータの値がビット単位の「OR」によって生成され、次の事前定義された定数のING：
ASAP_USE_DEFAULT: 0x0000 Use default setting.
ASAP_USE_DEFAULT：0000を使用するデフォルト設定。
ASAP_SEND_FAILOVER: 0x0001 Enables PE failover on this message. In the case where the first selected PE or the PE pointed to by the PE handle is found unreachable, the sender's ASAP Endpoint SHOULD re-select an alternate PE from the same pool if one exists, and silently re-send the message to this newly selected endpoint.
ASAP_SEND_FAILOVER：0x0001には、このメッセージにPEフェイルオーバーを有効にします。最初に選択PE又はPEがPEハンドルによって指さが到達不能検出された場合に存在する場合、送信者のASAPエンドポイントは、同じプールから代替PEを再選択する必要があり、そして静かに再送信メッセージこれに新しく選択したエンドポイント。
Note that this is a best-effort service. Applications should be aware that messages can be lost during the failover process, even if the underlying transport supports retrieval of unacknowledged data (e.g., SCTP). (Example: messages acknowledged by the SCTP layer at a PE, but not yet read by the PE when a PE failure occurs.) In the case where the underlying transport does not support such retrieval (e.g., TCP), any data already submitted by ASAP to the transport layer may be lost upon failover.
これはベストエフォート型のサービスであることに注意してください。アプリケーションは、基礎となるトランスポートが未確認のデータ（例えば、SCTP）の検索をサポートしている場合でも、メッセージは、フェールオーバープロセス中に失われる可能性があることに注意する必要があります。 （例：メッセージがPEでSCTP層によって承認が、PEの障害が発生したときにまだPEによって読み出されない。）、基礎となるトランスポートは、検索（例えば、TCP）をサポートしていない場合には、既にによって提出されたすべてのデータをできるだけ早くトランスポート層へのフェイルオーバー時に失われることがあります。
ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the sender's ASAP Endpoint from re-sending the message to any alternate PE in case that the first selected PE, or the PE pointed to by the PE handle, is found to be unreachable. Instead, the sender's ASAP Endpoint shall notify its upper layer about the unreachability with an Error.Report and return any unsent data.
ASAP_SEND_NO_FAILOVER：0×0002このオプションは、最初に選択PE、またはPEがPEハンドルによって指される場合に、任意の代替PEにメッセージを再送信し、送信者のASAPのエンドポイントを禁止するが、到達不能であることが見出されています。代わりに、送信者のできるだけ早くエンドポイントはError.Reportと到達不能についてその上位層に通知し、任意の未送信データを返還しなければなりません。
ASAP_SEND_TO_LAST: 0x0004 This option requests that the sender's ASAP Endpoint send the message to the same PE in the pool to which the previous message destined to this pool was sent.
ASAP_SEND_TO_LAST：送信者のできるだけ早くエンドポイントこのプールに向かう前のメッセージが送信されたためにプール内の同じPEにメッセージを送信0x0004は、このオプションを要求。
ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option directs the sender's ASAP endpoint to send a copy of the message to all the PEs, except for the sender itself if the sender is a PE in that pool.
ASAP_SEND_TO_ALL：0x0008でプールで送信ハンドルは、このオプションは、送信者がそのプール内のPEがある場合は、送信者自身を除いて、すべてのPEにメッセージのコピーを送信する送信者のできるだけ早く終点を指示します。
ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination with the ASAP_SEND_TO_ALL option. It permits the sender's ASAP Endpoint to also deliver a copy of the message to itself if the sender is a PE of the pool (i.e., loop-back).
ASAP_SEND_TO_SELF：0x0010このオプションは、ASAP_SEND_TO_ALLオプションと組み合わせて適用されます。これは、送信者がプールのPE（すなわち、ループバック）である場合にもそれ自体にメッセージのコピーを配信するために送信者のASAPエンドポイントを可能にします。
ASAP_SCTP_UNORDER: 0x1000 This option requests that the transport layer send the current message using un-ordered delivery (note the underlying transport must support un-ordered delivery for this option to be effective).
ASAP_SCTP_UNORDER：トランスポート層は、未注文の配信を使用して、現在のメッセージを送信0x1000をこのオプションを要求（基礎となるトランスポートが効果的であることには、このオプションのための非注文の配信をサポートしている必要があります注意してください）。
Format: data.received(messageReceived, sizeOfMessage,
senderAddress, typeOfAddress)
When a new user message is received, the ASAP Endpoint of the receiver uses this notification to pass the message to its upper layer.
新しいユーザ・メッセージを受信すると、受信機のASAPのエンドポイントは、その上位レイヤにメッセージを渡すために、この通知を使用します。
Along with the message being passed, the ASAP Endpoint of the receiver should also indicate to its upper layer the message senders address. The sender's address can be in the form of either an SCTP association id, TCP transport address, UDP transport address, or an ASAP Pool Element handle.
メッセージが渡されると共に、受信機のASAPのエンドポイントは、その上位レイヤにメッセージ送信者のアドレスを示すべきです。送信者のアドレスは、SCTP協会イド、TCPトランスポート・アドレス、UDPトランスポート・アドレス、またはできるだけ早くプール要素ハンドルのいずれかの形態にすることができます。
A) If the handle translation local cache is implemented at the receiver's ASAP Endpoint, a reverse mapping from the sender's IP address to the pool handle should be performed, and if the mapping is successful, the sender's ASAP Pool Element handle should be constructed and passed in the senderAddress field.
A）ハンドル翻訳ローカルキャッシュが受信機で実装されている場合はできるだけ早くエンドポイント、プール・ハンドルへの送信者のIPアドレスからの逆マッピングを実行する必要がありますし、マッピングが成功した場合、送信者の至急プール要素ハンドルを構築し、合格する必要がありますsenderAddressフィールドに入力します。
B) If there is no local cache or the reverse mapping is not successful, the SCTP association id or other transport specific identification (if SCTP is not being used) should be passed in the senderAddress field.
SCTPアソシエーションIDまたは他のトランスポート固有の識別（SCTPが使用されていない場合）、そこにはローカルキャッシュがないか、逆マッピングが成功しない場合B）senderAddressフィールドに渡さなければなりません。
Format: error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage)
An error.report should be generated to notify the ASAP User about failed message delivery as well as other abnormalities.
error.reportは、失敗したメッセージ配信、ならびに他の異常についてできるだけ早くユーザに通知するために生成されるべきです。
The destinationAddress and typeOfAddress together indicate to whom the message was originally sent. The address type can be either an ASAP Pool Element handle, association id, or a transport address.
宛先アドレスとtypeOfAddressは一緒に、メッセージが最初に送信された者に示しています。アドレスタイプは、ASAPプール要素ハンドル、アソシエーションID、またはトランスポートアドレスのいずれかとすることができます。
The original message (or the first portion of it if the message is too big) and its size should be passed in the failedMessage and sizeOfMessage fields, respectively.
元のメッセージ（またはメッセージが大きすぎる場合、それの最初の部分）と、そのサイズは、それぞれ、failedMessage及びsizeOfMessageフィールドに渡さなければなりません。
These examples assume an underlying SCTP transport between the PE and PU. Other transports are possible, but SCTP is utilized in the examples for illustrative purposes. Note that all communication between the PU and ENRP server and the PE and ENRP servers would be using SCTP.
これらの実施例は、PEとPUとの間の根本的なSCTP輸送を想定します。他のトランスポートが可能であるが、SCTPは、例示の目的のために実施例において利用されています。 PUとENRPサーバとPEとENRPサーバの間のすべての通信は、SCTPを使用するであろうことに留意されたいです。
This example shows the event sequence when a Pool User sends the message "hello" to a pool that is not in the local translation cache (assuming local caching is supported).
プールユーザー（ローカルキャッシュがサポートされていると仮定して）ローカル変換キャッシュにないプールに「ハロー」メッセージを送信するときに、この例では、イベント・シーケンスを示しています。
ENRP Server PU new-handle:PEx
ENRPサーバPU新しいハンドル：PEX
| | |
| +---+ |
| | 1 | |
|2. ASAP_HANDLE_RESOLUTION +---+ |
|<-------------------------------| |
| +---+ |
| | 3 | |
|4. ASAP_HANDLE_RESOLUTION_RSP +---+ |
|------------------------------->| |
| +---+ |
| | 5 | |
| +---+ 6. "hello1" |
| |---------------->|
| | |
1) The user at PU invokes:
1）PUのユーザが呼び出します。
data_send_request("new-handle", handle-type, "hello1", 6, 0);
data_send_request（ "新しいハンドル"、 "hello1"、6型ハンドル、0）;
The ASAP Endpoint, in response, looks up the pool "new-handle" in its local cache, but fails to find it.
できるだけ早くエンドポイントは、応答して、そのローカルキャッシュにプール「新・ハンドル」まで見えますが、それを見つけることができません。
2) The ASAP Endpoint of the PU queues the message and sends an ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all information about pool "new-handle".
2）PUのASAPのエンドポイントは、メッセージをキューに入れ、プール「新・ハンドル」に関する全ての情報を求めてENRPサーバにASAP_HANDLE_RESOLUTION要求を送信します。
3) A T1-ENRPrequest timer is started while the ASAP Endpoint is waiting for the response from the ENRP server.
できるだけ早くエンドポイントは、ENRPサーバからの応答を待っている間、3）T1-ENRPrequestタイマーがスタートします。
4) The ENRP server responds to the query with an ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the information about pool "new-handle".
4）ENRPサーバは、プール「新・ハンドル」に関するすべての情報が含まれていASAP_HANDLE_RESOLUTION_RESPONSEメッセージでクエリに応答します。
5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local cache with information on pool "new-handle".
5）至急PUでT1-ENRPrequestタイマーをキャンセルし、プールの「新・ハンドル」に関する情報をローカルキャッシュを移植。
6) Based on the server pooling policy of pool "new-handle", ASAP at PU selects the destination PE (PEx), sets up, if necessary, an SCTP association towards PEx (explicitly or implicitly), and sends out the queued "hello1" user message.
6）PUは、宛先PE（PEX）を選択し、ASAPに、プール「新しいハンドル」のポリシーをプールサーバに基づいて、「必要に応じて、PEX（明示的または暗黙的に）向かっSCTPアソシエーションを設定し、キューを送出しますhello1" ユーザメッセージ。
This shows the event sequence when the ASAP User PU sends another message to the pool "new-handle" after what happened in Section 6.8.1.
できるだけ早くユーザーPUは、セクション6.8.1に何が起こった後にプール「新・ハンドル」に別のメッセージを送信するときに、このイベントシーケンスを示しています。
ENRP Server PU new-handle:PEx
ENRPサーバPU新しいハンドル：PEX
| | |
| +---+ |
| | 1 | |
| +---+ 2. "hello2" |
| |---------------->|
| | |
1) The user at PU invokes:
1）PUのユーザが呼び出します。
data_send_request("new-handle", handle-type, "hello2", 6, 0);
data_send_request（ "新しいハンドル"、 "hello2"、6型ハンドル、0）;
The ASAP Endpoint, in response, looks up the pool "new-handle" in its local cache and finds the mapping information.
できるだけ早くエンドポイントは、応答して、そのローカルキャッシュにプール「新しいハンドルを」検索し、マッピング情報を検索します。
2) Based on the server pooling policy of "new-handle", ASAP at PU selects the PE (assuming EPx is selected again), and sends out "hello2" message (assuming the SCTP association is already set up).
2）PUは、PE（のEPxが再び選択されると仮定）を選択し、SCTPアソシエーションがすでに設定されていると仮定すると、「hello2」メッセージを（）を送信し、ASAPで、「新しいハンドル」のポリシーをプールサーバに基づきます。
When the ASAP Endpoint in a PE or PU attempts to send a message to a PE and fails, the failed sender will report the event as described in Section 3.5.
ASAPはPEでエンドポイントまたはPUは、PEにメッセージを送信しようと失敗した場合、セクション3.5で説明したように、失敗した送信者は、イベントを報告します。
Additional primitives are also defined in this section to support those user applications that do not wish to use ASAP as the actual transport.
追加のプリミティブは、実際のトランスポートとしてできるだけ早く使用したくないそれらのユーザー・アプリケーションをサポートするために、このセクションで定義されています。
Format: translation.request(Pool-Handle)
フォーマット：translation.request（プールハンドル）
If the address type is a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should look within its translation cache and return the current known transport types, ports, and addresses to the caller.
アドレスの種類がプールハンドルとローカルハンドル変換キャッシュが存在している場合は、できるだけ早くエンドポイントは、その翻訳キャッシュ内見て、呼び出し元に、現在知られているトランスポートタイプ、ポート、およびアドレスを返す必要があります。
If the Pool Handle does not exist in the local handle cache or no handle cache exists, the ASAP Endpoint will send an ASAP_HANDLE_RESOLUTION request using the Pool Handle. Upon completion of the handle resolution, the ASAP Endpoint should populate the local handle cache (if a local handle cache is supported) and return the transport types, ports, and addresses to the caller.
プール・ハンドルがローカルハンドルキャッシュに存在しないか、まったくハンドルキャッシュが存在しない場合は、できるだけ早くエンドポイントは、プール・ハンドルを使用してASAP_HANDLE_RESOLUTION要求を送信します。 （ローカルハンドルキャッシュがサポートされている場合）は、ハンドル解像度が完了すると、ASAPのエンドポイントは、ローカルハンドルキャッシュを投入する必要があり、呼び出し元に転送タイプ、ポート、およびアドレスを返します。
Format: transport.failure(Pool-Handle, Transport-address)
フォーマット：transport.failure（プール・ハンドル、トランスポートアドレス）
If an external user encounters a failure in sending to a PE and is *not* using ASAP, it can use this primitive to report the failure to the ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the "Home" ENRP server in response to this primitive. Note ASAP SHOULD NOT send an ASAP_ENDPOINT_UNREACHABLE *unless* the user has actually made a previous request to send data to the PE.
外部ユーザーは、できるだけ早く使用して*いない* PEへの送信に失敗に遭遇している場合、それはできるだけ早くエンドポイントに失敗したことを報告するには、このプリミティブを使用することができます。できるだけ早くこのプリミティブに応じて、「ホーム」ENRPサーバにASAP_ENDPOINT_UNREACHABLEを送信します。ユーザが実際にPEにデータを送信する前の要求をした*しない限り、* ASAP_ENDPOINT_UNREACHABLEを送るべきではありませんできるだけ早く注意してください。
The following is a summary of the timers, variables, and pre-set protocol constants used in ASAP.
以下では、ASAPで使用されるタイマー、変数、及び予め設定されたプロトコル定数の要約です。
T1-ENRPrequest - A timer started when a request is sent by ASAP to the ENRP server (providing application information is queued). Normally set to 15 seconds.
T1-ENRPrequest - 要求は（情報がキューイングされたアプリケーションを提供する）ENRPサーバにできるだけ早くによって送信されたときにタイマーをスタート。通常は15秒に設定。
T2-registration - A timer started when sending an ASAP_REGISTRATION request to the Home ENRP server, normally set to 30 seconds.
T2-登録 - 通常は30秒に設定ホームENRPサーバへASAP_REGISTRATION要求を、送信するときにタイマーがスタート。
T3-deregistration - A timer started when sending a de-registration request to the Home ENRP server, normally set to 30 seconds.
T3-登録解除 - 通常は30秒に設定ホームENRPサーバへの登録解除要求を、送信するときにタイマーがスタート。
T4-reregistration - This timer is started after successful registration into the ENRP handlespace and is used to cause a re-registration at a periodic interval. This timer is normally set to 10 minutes or 20 seconds less than the Lifetime parameter used in the registration request (whichever is less).
T4-再登録 - このタイマはENRPのhandlespaceに登録が成功した後に開始され、定期的な間隔で再登録を引き起こすために使用されます。このタイマーは、通常10分（いずれか小さい方）登録要求に使用される寿命パラメータ未満の20秒に設定されています。
T5-Serverhunt - This timer is used during the ENRP Server Hunt procedure and is normally set to 10 seconds.
T5-Serverhunt - このタイマは、ENRPサーバハントの手続きの際に使用され、通常は10秒に設定されています。
T6-Serverannounce - This timer gives the time between the sending of consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1 second.
T6-Serverannounce - このタイマは、連続したASAP_SERVER_ANNOUNCEメッセージの送信間の時間を与えます。これは、通常は1秒に設定されています。
T7-ENRPoutdate - This timer gives the time a server announcement is valid. It is normally set to 5 seconds.
T7-ENRPoutdate - このタイマーは、サーバーのアナウンスが有効な時間を与えます。これは、通常は5秒に設定されています。
stale_cache_value - A threshold variable that indicates how long a cache entry is valid for.
stale_cache_value - キャッシュエントリが有効ですどのくらいの期間を示すしきい値変数。
MAX-REG-ATTEMPT - The maximum number of registration attempts to be made before a server hunt is issued. The default value of this is set to 2.
MAX-REG-ATTEMPT - 登録の最大数は、サーバ狩りが発行される前に行うことを試みます。これのデフォルト値は2に設定されています。
MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made when requesting information from the local ENRP server before a server hunt is issued. The default value for this is 2.
MAX-REQUEST-RETRANSMIT - サーバ・ハントが発行される前にローカルENRPサーバから情報を要求するときに行われるべき試みの最大数。このため、デフォルト値は2です。
RETRAN-MAX - This value represents the maximum time between registration attempts and puts a ceiling on how far the registration timer will back off. The default value for this is normally set to 60 seconds.
RETRAN-MAX - この値は、登録試行間の最大時間を表し、登録タイマーがオフにバックアップする方法をはるかに上の天井を置きます。このデフォルト値は、通常は60秒に設定されています。
This document (RFC 5352) is the reference for all registrations described in this section. All registrations have been listed on the Reliable Server Pooling (RSerPool) Parameters page.
この文書（RFC 5352）は、このセクションで説明するすべての登録のための基準です。すべての登録は（RSerPool）パラメータページをプーリング信頼性の高いサーバーに上場されています。
ASAP Message Types are maintained by IANA. Fourteen initial values have been assigned by IANA as described in Figure 1. IANA created a new table, "ASAP Message Types":
至急メッセージタイプはIANAによって維持されています。 IANAは新しいテーブル、「できるだけ早くメッセージタイプ」を作成し、図1で説明したようにフォーティーンの初期値は、IANAによって割り当てられています：
Type Message Name Reference
----- ------------------------- ---------
0x00 (Reserved by IETF) RFC 5352
0x01 ASAP_REGISTRATION RFC 5352
0x02 ASAP_DEREGISTRATION RFC 5352
0x03 ASAP_REGISTRATION_RESPONSE RFC 5352
0x04 ASAP_DEREGISTRATION_RESPONSE RFC 5352
0x05 ASAP_HANDLE_RESOLUTION RFC 5352
0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFC 5352
0x07 ASAP_ENDPOINT_KEEP_ALIVE RFC 5352
0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFC 5352
0x09 ASAP_ENDPOINT_UNREACHABLE RFC 5352
0x0a ASAP_SERVER_ANNOUNCE RFC 5352
0x0b ASAP_COOKIE RFC 5352
0x0c ASAP_COOKIE_ECHO RFC 5352
0x0d ASAP_BUSINESS_CARD RFC 5352
0x0e ASAP_ERROR RFC 5352
0x0b-0xff (Available for Assignment) RFC 5352
Requests to register an ASAP Message Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied.
この表にできるだけ早くメッセージタイプを登録するための要求はIANAに送られるべきです。番号は一意である必要があります。 [RFC5226]の「仕様が必要である」というポリシーが適用されなければなりません。
The references for the already assigned port numbers
すでに割り当てられたポート番号の参照
asap-tcp 3863/tcp
できるだけ早く-TCP 3863 / TCP
asap-udp 3863/udp
できるだけ早く-UDP 3863 / UDP
asap-sctp 3863/sctp
煙-SCTP 3863 / SCTP
asap-tcp-tls 3864/tcp
できるだけ早く-TCP-TLS 3864 / TCP
asap-sctp-tls 3864/sctp
できるだけ早く-SCTP-TLS 3864 / SCTP
have been updated to RFC 5352.
RFC 5352に更新されました。
The reference for the already assigned ASAP payload protocol identifier 11 has been updated to RFC 5352.
既に割り当てられたできるだけ早くペイロードプロトコル識別子11のための基準は、RFC 5352にアップデートされています。
IANA has assigned an IPv4 multicast address (224.0.1.185) and an IPv6 multicast address (FF0X:0:0:0:0:0:0:133). The IPv4 address is part of the Internetwork Control Block (224.0.1/24).
（133：0：0：0：0：0：0 FF0X）IANAは、IPv4マルチキャストアドレス（224.0.1.185）とIPv6マルチキャストアドレスが割り当てられています。 IPv4アドレスは、インターネットワークコントロールブロック（224.0.1 / 24）の一部です。
We present a summary of the of the threats to the RSerPool architecture and describe security requirements in response in order to mitigate the threats. Next, we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats. Finally, we present a chain-of-trust argument that examines critical data paths in RSerPool and shows how these paths are protected by the TLS implementation.
私たちは、RSerPoolアーキテクチャへの脅威のの概要を提示し、脅威を軽減するために、応答におけるセキュリティ要件を記述します。次に、我々は脅威に対応して実装要件ですTLSに基づくセキュリティメカニズムを、提示します。最後に、我々はRSerPoolに重要なデータ・パスを調べて、これらのパスは、TLSの実装により保護されている方法を示しチェーン・オブ・信頼引数を提示します。
"Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats" [RFC5355] describes the threats to the RSerPool architecture in detail and lists the security requirements in response to each threat. From the threats described in this document, the security services required for the RSerPool protocol are enumerated below.
「脅威に対応するセキュリティのための信頼できるサーバプーリング（RSerPool）と要件によって導入脅威」[RFC5355]は詳細にRSerPoolアーキテクチャへの脅威について説明し、それぞれの脅威に対応してセキュリティ要件を示しています。この文書で説明脅威から、RSerPoolプロトコルに必要なセキュリティサービスは、以下に列挙されています。
Threat 1) PE registration/de-registration flooding or spoofing.
-----------
Security mechanism in response: ENRP server authenticates the PE.
Threat 2) PE registers with a malicious ENRP server.
-----------
Security mechanism in response: PE authenticates the ENRP server.
Threats 1 and 2, taken together, result in mutual authentication of the ENRP server and the PE.
脅威1および2は、一緒になって、ENRPサーバとPEの相互認証をもたらします。
Threat 3) Malicious ENRP server joins the ENRP server pool.
-----------
Security mechanism in response: ENRP servers mutually authenticate.
Threat 4) A PU communicates with a malicious ENRP server for handle
resolution.
-----------
Security mechanism in response: The PU authenticates the ENRP server.
Threat 5) Replay attack.
-----------
Security mechanism in response: Security protocol that has protection
from replay attacks.
Threat 6) Corrupted data that causes a PU to have misinformation
concerning a pool handle resolution.
-----------
Security mechanism in response: Security protocol that supports
integrity protection.
Threat 7) Eavesdropper snooping on handlespace information.
-----------
Security mechanism in response: Security protocol that supports data
confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server.
-----------
Security mechanism in response: ASAP must control the number of ASAP
Endpoint unreachable messages transmitted from the PU to the ENRP
server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server.
-----------
Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE.
To summarize, the threats 1-7 require security mechanisms that support authentication, integrity, data confidentiality, and protection from replay attacks.
要約すると、脅威1-7は、セキュリティ認証をサポートするメカニズムを、整合性、データの機密性、およびリプレイ攻撃からの保護を必要とします。
For RSerPool we need to authenticate the following:
RSerPoolのために我々は次のことを認証する必要があります。
PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP server (mutual authentication)
We do not define any new security mechanisms specifically for responding to threats 1-7. Rather, we use an existing IETF security protocol, specifically [RFC3237], to provide the security services required. TLS supports all these requirements and MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported, at a minimum, by implementers of TLS for RSerPool. For purposes of backwards compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other IETF-approved ciphersuites.
我々は、具体的な脅威1-7に対応するため、新たなセキュリティ・メカニズムを定義していません。むしろ、我々は必要なセキュリティサービスを提供するために、既存のIETFセキュリティプロトコル、特に[RFC3237]を使用します。 TLSは、これらすべての要件をサポートし、実装しなければなりません。 TLS_RSA_WITH_AES_128_CBC_SHAの暗号スイートはRSerPoolのためのTLSの実装によって、最低限、サポートしなければなりません。後方互換性の目的のために、ENRPはTLS_RSA_WITH_3DES_EDE_CBC_SHAをサポートする必要があります。実装者はまた、他のIETF承認の暗号スイートをサポートするかもしれません。
ENRP servers, PEs, and PUs MUST implement TLS. ENRP servers and PEs MUST support mutual authentication using PSK (pre-shared-key). ENRP servers MUST support mutual authentication among themselves using PSK. PUs MUST authenticate ENRP servers using certificates.
ENRPサーバは、PEを、とのPUは、TLSを実装しなければなりません。 ENRPサーバとPEはPSK（事前共有キー）を使用して相互認証をサポートしなければなりません。 ENRPサーバは、PSKを使用してそれらの間で相互認証をサポートしなければなりません。 PUが証明書を使用してENRPサーバを認証する必要があります。
TLS with PSK is mandatory to implement as the authentication mechanism for ENRP to ENRP authentication and PE to ENRP authentication. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. The justification for PSK is that we assume that one administrative domain will control and manage the server pool. This allows for PSK to be implemented and managed by a central security administrator.
PSKとTLS認証をENRPする認証およびPEをENRPするENRPの認証機構として実装することが必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。 PSKのための正当化は、我々は1つの管理ドメインは、サーバー・プールを制御し、管理することを前提としていることです。 PSKが実装され、中央のセキュリティ管理者によって管理されるためこれができます。
TLS with certificates is mandatory to implement as the authentication mechanism for PUs to the ENRP server. PUs MUST authenticate ENRP servers using certificates. ENRP servers MUST possess a site certificate whose subject corresponds to their canonical hostname. PUs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All RSerPool Elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably, well-known distributors of site certificates comparable to those that issue root certificates for web browsers).
証明書とTLSはENRPサーバへのPUのための認証機構として実装するために必須です。 PUが証明書を使用してENRPサーバを認証する必要があります。 ENRPサーバは、その対象と彼らの正規のホスト名に対応して、サイトの証明書を持っている必要があります。 PUは、TLSとの相互認証のために自分自身の証明書を持っているかもしれませんが、何の規定は、その使用については、このドキュメントに記載されていません。 TLSは、TLSネゴシエーション中に受信した証明書を検証するためのメカニズムを持っていなければならサポートするすべての要素RSerPool。これは、認証局によって発行された一つ以上のルート証明書の所持を伴う（好ましくは、Webブラウザ用のルート証明書を発行するものと同等のサイト証明書のよく知られた代理店）。
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). The client's understanding of the server's identity (typically, the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using DNS Security (DNSSEC), or using user- or admin-configured host-to-address/ address-to-host lookup tables).
（サーバのCertificateメッセージに提示される）man-in-the-middle攻撃を防ぐために、クライアントはサーバーの身元を確かめなければなりません。サーバーのIDのクライアントの理解は（一般的に、トランスポート接続を確立するために使用されるアイデンティティ）は「基準アイデンティティ」と呼ばれています。クライアントは、基準同一のタイプ（例えば、DNS名またはIPアドレス）を決定し、基準アイデンティティとマッチが生成されるまで、対応するタイプのそれぞれのsubjectAltName値との比較を行います。試合が生成されると、サーバの身元が確認された、およびサーバのIDチェックが完了しています。異なるのsubjectAltNameタイプが異なる方法で一致しています。クライアントは、前の比較を実行する異なるタイプの参照IDをマッピングすることができます。マッピングは、リファレンスアイデンティティをマッピングすることができるに利用可能なすべてのsubjectAltNameタイプに対して実行されてもよいです。しかし、基準IDは唯一のマッピングがされているタイプのいずれか、本質的に安全な（例えば、型のdNSNameののsubjectAltNameと比較するURIからDNS名を抽出する）、またはそのためのマッピングは、安全な方法で行われる（にマッピングされなければなりません例えば、DNSセキュリティ（DNSSEC）、またはUSER-または管理者が設定したホストからアドレス/アドレスからホストへのルックアップテーブルを使用）を使用。
If the server identity check fails, user-oriented clients SHOULD either notify the user or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect, or both. Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
サーバーIDチェックが失敗した場合、ユーザー指向のクライアントは、いずれかをユーザに通知したり、輸送接続を閉じ、サーバのアイデンティティが疑わしいであることを示す必要があります。自動化されたクライアントは、トランスポート接続をクローズして、サーバのアイデンティティが疑わしい、またはその両方であることを示すエラーを返すか、ログインする必要があります。このセクションで説明するサーバIDチェックを越えて、クライアントはさらに、サーバは、提供するように要求されたサービスを提供することを許可されていることを確認するチェックを行うために準備する必要があります。クライアントは、この決意を行う際に、ローカルポリシー情報を利用するために必要があるかもしれません。
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format, as specified in Section 4 of [RFC3490], before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of [RFC3490] as follows: * in step 1, the domain name SHALL be considered a "stored string"; * in step 3, set the flag called "UseSTD3ASCIIRules"; * in step 4, process each label with the "ToASCII" operation; and * in step 5, change all label separators to U+002E (full stop).
基準IDは国際化ドメイン名である場合型のdNSNameののsubjectAltName値と比較する前に、[RFC3490]のセクション4で指定されるように、適合実装は、ASCII互換エンコーディング（ACE）形式に変換しなければなりません。具体的には、以下のよう適合実装は、[RFC3490]のセクション4で指定された変換操作を実行しなければなりません：*ステップ1で、ドメイン名が「記憶された文字列」と見なさなければなりません。 *ステップ3で、「UseSTD3ASCIIRules」と呼ばれるフラグを設定します。 *工程4、工程「もしToASCII」操作で各ラベルにおいて、そして*ステップ5で、U + 002E（フルストップ）に、すべてのラベルの区切りを変更します。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality, according to the rules specified in Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then, only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
「へ-ASCII」変換を行った後、DNSラベルと名前が「*」（ASCII 42）ワイルドカード文字がタイプののsubjectAltName値で許可されているRFC 3490のセクション3で指定された規則に従って、等しいかどうかを比較しなければなりませんdNSName、その後、その値だけでは、一番左の（最下位）DNSラベルとして。このワイルドカードは、サーバー名に任意の一番左のDNSラベルと一致します。つまり、対象* .example.comとは、サーバー名a.example.comとb.example.comと一致しますが、example.comまたはa.b.example.comと一致していないです。
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation in [RFC0791] and [RFC2460]. For IP version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
基準IDはIPアドレスである場合、同一性は、[RFC0791]の「ネットワークバイト順」オクテットストリング表現と[RFC2460]に変換されなければなりません。 IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列は正確に4オクテットを含んでいます。 IPバージョン6の場合は、RFC 2460で指定されているように、オクテット文字列は、正確に16オクテットを含んでいます。このオクテット文字列は、その後のタイプIPアドレスののsubjectAltName値と比較されます。参照アイデンティティオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
After a TLS layer is established in a session, both parties are to independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see RFC 4511)[RFC4511]. Implementations may re-evaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer.
TLS層はセッション中に確立された後、両当事者は独立して、ローカルポリシーと達成セキュリティレベルに基づいて継続するかどうかを決定することです。いずれかの当事者がそれを継続するために、セキュリティレベルが不十分であると判断した場合は、すぐにTLS（再）交渉の後にTLS層を削除する必要があります（RFC 4511を参照してください）[RFC4511]を完了しました。実装はTLS層を除去する必要があり、それが不十分な発見時に、任意の時点でセキュリティレベルを再評価します。
Implementations MUST support TLS with SCTP, as described in [RFC3436] or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to a TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer, we also have to take into account the differences between TLS and SCTP.
TCP上に[RFC3436]またはTLSに記載されているように[RFC5246]で説明されるような実装は、SCTPとTLSをサポートしなければなりません。 TLS / SCTPを使用した場合、我々はRSerPoolは、TLS / SCTPユーザに利用できないSCTPのすべての機能を使用していないことを確認する必要があります。これは困難な技術的問題ではなく、単に必要条件ではありません。 RSerPool下層のAPIを説明するとき、我々も考慮にTLSおよびSCTPの違いを取らなければなりません。
Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5) to the ENRP server.
脅威8はENRPサーバへASAP_ENDPOINT_UNREACHABLEメッセージ（セクション3.5を参照）の数を制限するために、できるだけ早くプロトコルを必要とします。
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see [RFC5353]).
脅威9はPEにENRPサーバからASAP_ENDPOINT_KEEP_ALIVEメッセージの数を制限するENRPプロトコルを必要とする（[RFC5353]を参照）。
There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot consider the source address of such a message to be a trustworthy address of an ENRP server. A receiver must also be prepared to receive a large number of multicast announcements from attackers.
マルチキャストアナウンスメント用に定義されたセキュリティメカニズムはありません。したがって、そのような発表の受信機は、ENRPサーバの信頼アドレスにそのようなメッセージの送信元アドレスを考慮することができません。受信機はまた、攻撃者からのマルチキャストアナウンスの多数を受け取るように準備されなければなりません。
Security is mandatory to implement in RSerPool and is based on TLS implementation in all three architecture components that comprise RSerPool -- namely PU, PE, and ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server.
セキュリティはRSerPoolに実装するために必須であり、すべての3つのRSerPoolを含むアーキテクチャコンポーネントでTLSの実装に基づいている - すなわち、PU、PE、およびENRPサーバ。我々は、すべての通信のためにTLSを使用してピアとPEの登録は、保護されたENRPサーバであることがENRP認証ENRPサーバを定義します。
Here is a description of all possible data paths and a description of the security.
ここでは、すべての可能なデータパスの記述とセキュリティの記述があります。
PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS)
PE <---> secured ENRP server (mutual authentication;
registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS)
If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it.
システムのすべてのコンポーネントが認証及びTLSを使用して通信する場合は、信頼の連鎖は、音です。信頼チェーンのルートは、ENRPサーバです。それは、TLSを使用して保護されている場合、セキュリティは、接続しようとするすべてのENRPとPEのコンポーネントに適用されます。
Summary of interaction between secured and unsecured components: If the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as an error due to security considerations and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure, as the response can be tampered with in transit even if the ENRP database is secured.
固定され保護されていない構成要素間の相互作用の概要：PEは、TLSを使用して安全なENRPサーバに登録しようとしない場合は、エラーメッセージ応答を受信するによるセキュリティ問題にエラーとして示され、登録は拒否されます。 TLSを使用しないENRPサーバが安全なENRPサーバのデータベースを更新しようとする場合、更新は拒否されます。 PUは、TLSを使用し、安全なENRPサーバと通信していない場合は、応答がENRPデータベースが確保されている場合でも、中に改ざんすることができますよう、応答は、セキュリティで保護されていないことを理解した上で応答を取得します。
The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server.
最後のケースは、PUがENRPに安全な要求を送信します。それはENRPとPEが確保されていないことかもしれないし、これは許容できる構成です。その意図は、PUとENRPサーバ間のインターネットを介した通信を確保することです。
Summary:
概要：
RSerPool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers.
RSerPoolアーキテクチャコンポーネントは、信頼の連鎖を確立するために互いに通信することができます。担保PEとENRPサーバは、無担保ENRPまたはPEサーバーとのすべての通信を拒否します。
If the above is enforced, then a chain of trust is established for the RSerPool user.
上記が適用されている場合には、信頼の連鎖はRSerPoolのユーザーのために確立されています。
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback.
作者は彼らの貴重なコメントやフィードバックのためにジョンLoughney、リンドンオング、ウォルター・ジョンソン、トーマスDreibholz、および多くの他に感謝したいです。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002.
[RFC3237] Tuexen、M.、謝、Q.、スチュワート、R.、ショア、M.、オング、L.、Loughney、J.、およびM.スティルマン、 "信頼できるサーバプーリングのための要件"、RFC 3237年1月2002。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[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月。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
[RFC5356] Dreibholz、T.およびM. Tuexen、 "信頼できるサーバプーリング方針"、RFC 5356、2008年9月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（ASAP）から印刷して、エンドポイントHandlespace冗長プロトコル（ENRP）パラメータ"、RFC 5354、2008年9月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5353]謝、Q.、スチュワート、R.、スティルマン、M.、Tuexen、M.、およびA.シルバー、 "エンドポイントHandlespace冗長プロトコル（ENRP）"、RFC 5353、2008年9月。
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.
[RFC5355]スティルマンが、M.編、ゴパル、R.、ガットマン、E.、ホールドレッジ、M.、およびS. Sengodanは、 "脅威脅威に応答して信頼できるサーバプーリング（RSerPool）とセキュリティ要件によって導入されました" 、RFC 5355、2008年9月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
Randall R. Stewart The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
ランドールR.スチュワートザ・リソース・グループ1700ペンシルバニアアベニューNWスイート560ワシントンD.C.、20006 USA
EMail: randall@lakerest.net
メールアドレス：randall@lakerest.net
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
オリンピックアイスQ私はIEにWスイート560ワシントンD.C.、20006 USA専用リソース・グループ1700年ペンシルベニア州AVをX
Phone: +1 224-465-5954 EMail: Qiaobing.Xie@gmail.com
電話：+1 224-465-5954電子メール：Qiaobing.Xie@gmail.com
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 USA
モーリーンスティルマンノキア1167ピーチツリーのCt。ネーパーヴィル、IL 60540 USA
EMail: maureen.stillman@nokia.com
メールアドレス：maureen.stillman@nokia.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルTuexenミュンスター大学。応用科学Stegerwaldstrの。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。