[要約] RFC 5352は、Aggregate Server Access Protocol（ASAP）に関する仕様であり、複数のサーバーへのアクセスを効率化するためのプロトコルです。ASAPの目的は、クライアントが複数のサーバーに対して一度にリクエストを送信し、効率的なデータの取得と処理を実現することです。
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)
Aggregate Server Accessプロトコル（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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.
Aggregate Server Access Protocol（ASAP; RFC 5352）は、エンドポイントハンドルスペース冗長プロトコル（ENRP; RFC 5353）と組み合わせて、IPネットワーク上の高可用性データ転送メカニズムを提供します。ASAPは、IPアドレスから論理通信エンドポイントを分離するハンドルベースのアドレス指定モデルを使用するため、通常、単一の障害ポイントを構成する通信エンドポイントと物理IPアドレス（ES）の間のバインディングを効果的に排除します。
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は各論理通信の目的地をプールとして定義し、サーバーのプーリングと負荷共有の完全な透明なサポートを提供します。また、動的システムのスケーラビリティが可能になります。サーバープールのメンバーは、サービスを中断することなく、いつでも追加または削除できます。
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は、ストリームトランスミッションコントロールプロトコル（SCTP; RFC 4960）によって提供されるネットワークレベルの冗長性を最大限に活用するように設計されています。SCTP以外の各輸送プロトコルには、伴う輸送マッピングドキュメントが必要です。プール要素（PES）とENRPサーバーの間に渡されたASAPメッセージが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の2つのプロトコルを組み合わせることで得られます。ASAPでは、翻訳、負荷共有管理、障害管理に対処するためのプールハンドルのユーザーインターフェイスを提供し、ENRPは高可用性プールハンドルの翻訳を定義します。サービス。
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.
Aggregate Server Access Protocol（ASAP）は、エンドポイント名解像度プロトコル[RFC5353]と組み合わせて使用すると、IPネットワークよりも高可用性データ移動メカニズムを提供します。ASAPは、IPアドレスから論理通信エンドポイントを分離するハンドルベースのアドレス指定モデルを使用するため、通常、単一の障害ポイントを構成する通信エンドポイントと物理IPアドレス（ES）の間のバインディングを効果的に排除します。
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.
メッセージを配信している間、ASAPを使用して、選択したPEの到達可能性を監視できます。メッセージ送信者（ASAPユーザー）に障害を通知する前に、到達不可能であることが判明した場合、ASAPはそのプールの下に別のPE（存在する場合）を自動的に選択し、そのPEにメッセージを配信しようとします。言い換えれば、ASAPは、サーバープール内の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.
ASAPはENRPに依存しており、高可用性プールハンドルスペースを提供します。ASAPは、基礎となる輸送技術、負荷分布管理、障害管理、および統一されたプリミティブインターフェイスを介した上層（ASAPユーザー）へのプレゼンテーションの抽象化を担当しています。
When SCTP [RFC4960] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by SCTP.
SCTP [RFC4960]が輸送層プロトコルとして使用される場合、ASAPはSCTPが提供するリンク層冗長性をシームレスに組み込むことができます。
This document defines the ASAP portion of the high-availability server pool.
このドキュメントでは、高可用性サーバープールのASAP部分を定義します。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
ASAP User: Either a PE or Pool User (PU) that uses ASAP.
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.
ハンドルスペース：内部または外部エージェントが照会する可能性のあるプールハンドルと関係のまとまりのある構造。
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.
Home Endp Server：PEまたはPUが現在すべての名前空間サービスリクエストを送信しているENRPサーバー。PEはいつでも1つのホームENRPサーバーしか持っておらず、PEとそのホームENTRPサーバーの両方がこの関係を知り、追跡する必要があります。PUは、利用可能なENRPサーバーのいずれかをHome EntRPサーバーとして選択する必要がありますが、ASAP_ENDPOINT_KEEP_ALIVEメッセージを送信することにより、集合的なENRPサーバーがこれを変更する場合があります。
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クライアントチャネル：ASAPユーザーがすべての名前空間サービスリクエストを送信する通信チャネル。クライアントチャネルは通常、Home Endpサーバーの輸送アドレスと有名なポート番号によって定義されます。チャンネルは、マルチキャストまたは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).
輸送アドレス：輸送アドレスは、従来、ネットワーク層アドレス、輸送層プロトコル、輸送層ポート番号によって定義されています。IPを介して実行されているSCTPの場合、トランスポートアドレスは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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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では、ASAPメッセージ形式を詳しく説明しています。セクション3では、ASAP実装者の詳細なASAP手順を提供します。セクション4では、どのメッセージをサポートする必要があるかを要約し、セクション5にはSCTPの使用について説明します。セクション6では、ASAPインターフェイスの詳細を示し、ASAPの間の通信プリミティブ、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.
高可用性とスケーラビリティの要件は、共有された状態とデータの要件を意味するものではありません。ASAPはトランザクションフェールオーバーを提供しません。トランザクションの処理中にホストまたはアプリケーションが失敗した場合、このトランザクションが失われる可能性があります。一部のサービスは、障害を処理する方法を提供する場合がありますが、これは保証されていません。ASAPは、状態を共有するメカニズムを構築するアプリケーションを支援するためのフックを提供する場合がありますが、できるだけ早く状態を共有しません。
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.
ASAP/ENRPの範囲はインターネット全体ではありません。ハンドルスペースは、階層的でも、DNSのような任意の大きさでもありません。フラットピアツーピアモデルが詳細です。サーバーのプールは、さまざまな管理ドメインに存在します。たとえば、ASAPとENRPの使用が必要であるとします。まず、PUはDNSを使用してENRPサーバーに連絡する場合があります。北米のPUが北米ではなく日本のサーバープールに連絡したいとしています。PUはDNSを使用して、日本のサーバープールのIPアドレスのリストを取得します。つまり、日本のENRPクライアントチャネルです。そこから、PUはそれが確立したホームエンプスサーバーを照会し、その後、関心のある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]に記載されています。また、ENRPサーバーとPEの間で交換されたすべての * ASAPメッセージはSCTPを輸送として使用する必要がありますが、ENRPサーバーとPUの間で交換されるASAPメッセージはSCTPまたはTCPのいずれかを輸送として使用する必要があります。PE To PUデータトラフィックは、登録中に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].
このセクションでは、ASAPで使用される個々のメッセージの詳細を示します。これらのメッセージは、[RFC5354]のセクション4にある標準メッセージ形式で構成されています。パラメーターの説明は[RFC5354]に記載されています。
The following ASAP message types are defined in this section:
このセクションでは、次のASPメッセージタイプを定義しています。
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 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.
ASAP_REGISTRATIONメッセージは、PEによってHome EntRPサーバーに送信され、新しいプールを作成するか、既存のプールに追加します。ASAP_REGISTRATIONメッセージを送信するPEは、プールハンドルパラメーターとプール要素パラメーターを入力する必要があります。プールハンドルパラメーターは、登録する名前を指定します。セクション3.1で概説されているように、プール要素パラメーターは登録者が記入する必要があります。登録メッセージを送信するPEは、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メッセージは、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 = 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_DEREGISTを送信するPEは、ENRPサーバーがエンドポイントのIDを確認できるようにするために、プールハンドルと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に、Home Endp Serverから応答して送信されます。
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」に設定されている場合、このパラメーターは存在する場合、登録PEへの警告として機能し、登録値の一部がENRPサーバーによって変更された可能性があることを通知します。登録が成功し、警告がない場合、このパラメーターは含まれていません。
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メッセージは、ASAP_DEREGISTメッセージに応じて、またはプール内のPEの登録寿命の有効期限のために、Home Endp Serverによって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 = 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メッセージは、PEまたはPUのいずれかによって自宅の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 = 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 Associationの寿命のためにプールが変更されたときに、Home Endp Serverにこのプールの更新を動的に送信するよう要求します。プールへの動的な更新は、ユーザーが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.
新しいHome Enrpサーバーが採用されている場合、エンドポイントが引き続き更新を受け取りたい場合は、「動的更新リクエスト」は新しいHome ENPRサーバーに再配置する必要があることに注意してください。言い換えれば、ENRPサーバーは、PUが状態の自動更新を要求しているPUのどれに関する状態を共有していません。したがって、Home 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または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:
'A'ビット：
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.
このビットは、entrpサーバーが自動更新を送信するリクエストを受け入れる場合、「1」に設定されます（つまり、「s」ビットはリクエストで設定されました）。このビットが「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メッセージは、ENRPサーバーによってPEに送信されます。ASAP_ENDPOINT_KEEP_ALIVEメッセージは、PEが到達可能であることを確認するために使用され、「H」ビットが「1」に設定されている場合、送信サーバーを新しいホームENRPサーバーとして採用する必要があります。「H」ビットの設定に関係なく、ASAPエンドポイントは、到着する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（Home Endp Server）フラグ：
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またはPUのいずれかによって自宅の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 = 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メッセージは、ENRPサーバーによって送信され、PUSとPESが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.
server_announceメッセージ内で使用できるSCTPおよびTCPトランスポートパラメーターのみが許可されます。
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によって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 = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter :
Cookieパラメーター：
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.
ASAP_COOKIE_ECHOメッセージは、フェイルオーバーを支援するために現在のPEで障害を検出すると、PUから新しいPEに送信されます。PEによって送信されたCookieパラメーターは、障害のある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:
Cookieパラメーター：
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メッセージは、PUからPEに送信され、PEから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 = 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メッセージは、問題または問題を報告するためにASAPエンドポイントを送信する未知のメッセージまたは未知のパラメーターを受信するASAPエンドポイントによって応答して送信されます。
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エンドポイントで使用される方法と手順に焦点を当てます。障害検出と管理のための適切なタイマーと回復アクションについても説明します。また、PEとPUの間に送信されたASAPメッセージは、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は、それ自体とHome Endp Serverの間に確立されたSCTP協会を使用して登録する必要があります。PEがHome EntRPサーバーを確立していない場合、セクション3.6で指定された手順に従う必要があります。
Once the PE's ASAP Endpoint has established its Home ENRP server, the following procedures MUST be followed to register:
PEのASAPエンドポイントがHome 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).
R1）Home ENRPサーバーと通信するために使用されるPEのSCTPエンドポイントは、PEが使用するすべてのIPアドレスにバインドする必要があります（どのトランスポートプロトコルがPEにユーザー要求をサービスするために使用されるかに関係なく）。
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:
R2）PEのASAPエンドポイントは、セクション2.2.1で定義されているように、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はプールの全体的な輸送タイプと全体的なデータ/制御チャネルの使用に従う必要があります。それ以外の場合、登録はEntRPサーバーによって拒否される場合があります。
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を使用してASAP_REGISTRATIONメッセージをHome Endpサーバーに送信します。
R4) Start a T2-registration timer.
R4）T2-Registrationタイマーを開始します。
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は、オプションのASAP輸送パラメーターを入力する必要はありません。ASAP輸送パラメーターは、Home Endpサーバーによって記入され、使用されます。
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.
ASAP_REGISTRATION_RESPONSEメッセージを受信する前にT2-Registrationタイマーが期限切れになった場合、またはsend.failureの通知がSCTPレイヤーから受信された場合、PEは別のENRPサーバーからサービスを取得するためにサーバーハント手順を開始します（セクション3.6を参照）。新しいHome Endpサーバーを確立した後、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. 名前付きプールがハンドルスペースに存在しない場合、ENRPサーバーは、ハンドルスペースにそのハンドルを備えた新しいプールを作成し、最初の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.
新しいプールが作成される場合、プールの全体的なメンバー選択ポリシーを最初のPEで示されるポリシータイプに設定する必要があります。全体のプール輸送タイプは、PEで示された輸送タイプに設定する必要があり、プール全体のデータ全体に設定する必要があります。/制御チャネル構成は、登録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. 名前付きプールがすでにハンドルスペースに存在しているが、リクエスト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.
ただし、PEをプールに追加する前に、サーバーは、登録PEで示されるポリシーの種類、輸送タイプ、および輸送の使用がプールのものと一致しているかどうかを確認する必要があります。異なる場合、ENRPサーバーは登録を拒否する必要があります。
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がすでにプールのメンバーである場合、ENRPサーバーはこれを再登録ケースと見なす必要があります。ENRPサーバーは、上記のようにポリシー、輸送タイプ、および輸送の使用に関する同じテストを実行する必要があります。テスト後に再登録が受け入れられた場合、ENRPサーバーは、既存のPEの属性を、受信したASAP_REGISTRATIONメッセージに掲載された情報に置き換える必要があります。
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_REGISSTRATION_RESPONSEメッセージを使用して要求PEに返信する必要があります。登録が受け入れられた場合、ENRPサーバーはASAP_registration_responseにRフラグを「0」に設定する必要があります。登録が拒否された場合、ASAP_REGIST_RESPONSEにRフラグを「1」に設定することにより、ENRPサーバーは拒否を示す必要があります。
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のホームENTRPサーバー、つまりPEを「所有」するように割り当てる必要があります。
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サーバーは、2つの個別の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サーバーは、ハンドルスペースの更新アクションを実行して、行われた変更について同僚に通知する必要があります。登録が拒否された場合、同僚にメッセージは送信されません。
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のASAPエンドポイントに送信され、登録されたプールからのPEの削除が示されます。
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: 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.
登録する場合、PEは、Home Endp Serverへの登録に使用されたSCTP協会を使用する必要があります。登録するには、PEのASAPエンドポイントは次のアクションを実行する必要があります。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識別子パラメーターに入力します。識別子は、登録中に使用されるものと同じでなければなりません。登録で使用される同じプールハンドルとプール識別子パラメーターを使用すると、登録が発生する前にPE ASAPエンドポイントのIDを検証することができます。
D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server using the PE's SCTP association.
d3）PEのSCTP協会を使用して、ASAP_DEREGISTメッセージをHome EntRPサーバーに送信します。
D4) Start a T3-Deregistration timer.
d4）T3-Deregistrationタイマーを開始します。
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-DeregistrationタイマーがASAP_REGISTRATION_RESPONSEメッセージを受信する前に有効期限が切れる場合、またはPEのSCTPエンドポイントからFailure通知を受け取る場合、PEのASAPエンドポイントは、別のサービスを受けるためにENRPサーバーハント手順（セクション3.6を参照）を開始するものとします。ENRPサーバー。新しいHome Enrpサーバーを確立した後、ASAPエンドポイントは登録解除手順を再起動する必要があります。
At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP endpoint MUST stop the T3-Deregistration timer.
ASAP_DEREGISTRATION_RESPONSEを受信すると、PEのASAPエンドポイントはT3-Deregistrationタイマーを停止する必要があります。
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サーバーはそのハンドルスペースからPEを削除するものとします。さらに、PEが指定されたプールの最後の1つである場合、ENRPサーバーはハンドルスペースからプールも削除します。
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サーバーがそのハンドルスペースにPEの記録を見つけられない場合、付与および完了した登録解除を検討し、ASAP_DEREGIST_RESPONSEメッセージをPEに送信する必要があります。
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サーバーはASAP_DEREGISTRATION_RESPONSEメッセージをPEに送信する必要があります。登録解除が拒否された場合、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がハンドルスペースのローカルコピーから削除されたら、ENRPサーバーはハンドルスペースの更新アクションを実行して、行われた変更について同僚に通知する必要があります。それ以外の場合、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はハンドルを解決したい場合があります。これは通常、ASAPエンドポイントがプールハンドル（セクション6.5.1）を自宅のendpサーバーに送信するか、キャッシュ母集団を要求する場合に発生します（セクション6.3）。また、他の理由で発生する場合があります（たとえば、内部のASAP PEは、その仲間を知り、すべての人にメッセージを送信したいと考えています）。ASAPエンドポイント（PEまたはPU）が、プールのメンバーPESのアクセス可能な輸送アドレスのリストにプールハンドルを解決したい場合、次のアクションをとる必要があります。
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.
NR2）エンドポイントにホームENRPサーバーがない場合は、セクション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を使用してASAP_HANDLE_RESOLUTIONメッセージをHome Endpサーバーに送信します。PUの場合、TCPまたはSCTPのいずれかを使用して、ASAP_HANDLE_RESOLUTIONメッセージをHome Endpサーバーに送信します。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タイマーが応答メッセージを受信する前に期限切れになった場合、ASAPエンドポイントはセクション3.7.2で説明されている手順を実行する必要があります。send.failure通知がSCTPまたはTCPレイヤーから受信された場合、ASAPエンドポイントは、別のENRPサーバーからサービスを取得するために、サーバーハント手順（セクション3.6を参照）を開始する必要があります。新しいHome Enrpサーバーを確立した後、ASAPエンドポイントはハンドル解像度の手順を再起動する必要があります。
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エンドポイントはメッセージを必要に応じて処理する必要があります（たとえば、ローカルキャッシュを入力し、ASAPユーザーへの応答を与え、および/または応答を使用して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:
一部のASPエンドポイントは、キャッシュを使用して、送信されるハンドル解像度の数を最小限に抑えることができることに注意してください。キャッシュが使用されている場合は、次のようにする必要があります。
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.
キャッシュを使用することの影響は、アプリケーションのポリシーと要件に依存することに注意する必要があります。一部のアプリケーションでは、Cache-Usageはシステムのパフォーマンスを向上させる可能性があります。一部の人にとっては、それを減らすことができます。
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接続のいずれかで、PUSから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サーバーは最初にハンドルスペースのプールハンドルを検索する必要があります。プールが存在する場合、ホームENRPサーバーは、ASAP_HANDLE_RESOLUTION_RESPONSEメッセージを要求PUに構成して送信する必要があります。
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.
名前付きプールがハンドルスペースに存在しない場合、ENRPサーバーは、未知のプールハンドルエラーを運ぶASAP_HANDLE_RESOLOUTION_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メッセージは、ENRPサーバーによってPEに送信され、到達可能であることを確認します。輸送レベルの心拍メカニズムが不十分な場合、このメッセージは、ASAPレベルの健康状態をタイムリーに決定するASAPレベルの心拍メカニズムで使用できます。（タイムアウトまたはハートビート間隔が長すぎるか、輸送レベルのハートビートメカニズムのカバレッジが両端の輸送レベルに限定されているため、輸送レベルの心拍メカニズムは不十分な場合があります。）SCTPスタックがカーネルにある場合、障害検出の信頼性に価値があります。このような場合、SCTPレベルのハートビートは2つのSCTPスタック間のエンドツーエンドの接続を監視しますが、ASAPレベルのハートビートは、その上の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フラグが設定されており、メッセージのサーバー識別子があなたの家のenterの識別ではない場合（または、それは設定されていません、たとえば、あなたは家のendpサーバーを持っていません）採用ASAP_ENDPOINT_KEEP_ALIVEメッセージの送信者は、新しいHome Endpサーバーとして。
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エンドポイントによって実現される特定のSCTPエラーによって、またはTransport.Failure Primitive（セクション6.9.2）を介してASAPユーザーレポートを介して発生する場合があります。どちらの場合でも、ASAPエンドポイントは、ASAP_ENDPOINT_UNREACHABLEメッセージをENRPサーバーに送信して、PEの利用不能を報告する必要があります。ASAP_ENDpoint_UnReachableメッセージを送信する前に、ASAPエンドポイントは、到達不可能なエンドポイントのプールハンドルパラメーターとPE識別子パラメーターを入力する必要があります。送信者がPEの場合、メッセージはSCTPを介して送信する必要があります。ASAPエンドポイントは、そのようなイベントに遭遇するたびに1回しか報告しないことに注意する必要があります。さらに、Transport.Failure Primitive（セクション6.9.2）を処理する場合、ASAPエンドポイントは、ユーザーがプリミティブで指定されたPEにデータを送信するという以前の要求を行っていない限り、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サーバーはすぐにポイントツーポイントをASAP_ENDPOINT_KEEP_ALIVEメッセージを問題のPEに送信する必要があります（この場合、メッセージのHフラグは「0」に設定する必要があります）。このASAP_ENDPOINT_KEEP_ALIVEが失敗した場合（たとえば、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サーバーはそのハンドルスペースにPEを保持する必要があります。さらに、サーバーはカウンターを保持して、このPEに関連するレポート到達可能性の問題を受け取ったASAP_ENDPOINT_UNREACHABLEメッセージの数を記録する必要があります。カウンターがプロトコルのしきい値max-bad-pe-reportを超えている場合、endpサーバーはそのハンドルスペースから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に、Point-to-Point_Keep_alive（hフラグを「0」に設定）メッセージを定期的に送信することもできます。ASAP_ENDPOINT_KEEP_ALIVEをPEに送信すると失敗した場合、ENRPサーバーはPEを到達不能と見なす必要があり、ハンドルスペースからPEを削除する必要があります。Enrpサーバーが多数のPESを所有している場合、実装は、ASAP_ENDPOINT_KEEP_ALIVEメッセージのバーストでネットワークをあふれさせないように注意する必要があります。代わりに、実装は、ASAP_ENDPOINT_KEEP_ALIVEメッセージトラフィックを期間にわたって配布する必要があります。これは、2つのASAP_ENDPOINT_KEEP_ALIVEメッセージの間の時間を同じPEにプラス/マイナス50％に変えることで達成できます。
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サーバーは定期的に（n 1）*t6-server_announceメッセージ（セクション2.2.10）をすべて（n 1）*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アドレスとIANA登録されたASAPポート番号が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).
スタートアップで、またはHome Enrp Serverと通信できない場合（つまり、ENRPリクエストでタイミングを出します）、PEまたはPUは新しいHome entRPサーバーを確立する必要があります（つまり、TCP接続またはSCTP関連を設定する必要があります。異なるentrpサーバー）。
To establish a Home ENRP server, the following rules MUST be followed:
Home 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.
SH1）PEまたはPUは、3つのENRPサーバーを持つ関連または接続を確立しようとする必要があります。ASAPエンドポイントは、3つ以上の関連性または接続を確立してはなりません。
SH2) The ASAP Endpoint shall start a T5-Serverhunt timer.
SH2）ASAPエンドポイントは、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）ASAPエンドポイントが関連または接続を確立する場合、T5-Serverhuntタイマーを停止する必要があります。ASAPエンドポイントは、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）関連性または接続施設が失敗した場合、ASAPエンドポイントは、異なる輸送アドレスを使用して関連または接続を確立しようとする必要があります。
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）ASAPエンドポイントは、T5-ServerHuntタイマーの値を2倍にする必要があります。この倍増は、値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）ASAPエンドポイントは、ステップ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.
SH6）PEまたはPUは、関連性または接続を確立できるENRPサーバーの1つを選択し、その後のすべてのENRPリクエストメッセージをこの新しいHome Endpサーバーに送信するものとします。
Three types of failure may occur when the ASAP Endpoint at either the PE or PU tries to communicate with an ENRP server:
PEまたはPUのASAPエンドポイントがENRPサーバーと通信しようとする場合、3種類の障害が発生する可能性があります。
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サーバーハント手順を開始する必要があります。新しいHome Enrpサーバーを見つけた後、ASAPエンドポイントはリクエストを再供給する必要があります。
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.
ASAPエンドポイントは、メッセージを廃棄せず、新しいHome Endpサーバーが見つかった後に再送信のためにキューに並ぶことを選択する場合があることに注意してください。ASAPエンドポイントがメッセージを破棄することを選択した場合、新しいHome Enrpサーバーが見つかった後、ASAPエンドポイントは元のリクエストを再構築できる必要があります。
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タイマーの有効期限が切れると、ASAPエンドポイントは元の要求をENRPサーバーに再送信し、T1-Entrequestタイマーを再起動する必要があります。並行して、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 Timeまで繰り返される必要があります。その後、ASAPユーザーに通知するためにエラー.report通知を生成する必要があり、T1-entrequestタイマーに関連付けられたENRPリクエストメッセージを破棄する必要があります。代替ENRPサーバーが応答した場合、ASAPエンドポイントは、応答するENRPサーバーを新しいHome ENRPサーバーとして採用し、リクエストを新しいHome EntRPサーバーに再送信する必要があることに注意してください。
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が必要になり、制御チャネルが存在するたびに、コントロールチャネルを介してASAP_CookieメッセージをPUに送信できます。PUのASAPエンドポイントは、Cookieパラメーターを保存し、以前に保存されている場合は古いCookieを破棄します。
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を使用してASAPメッセージ（Cookieおよび名刺）を通常のデータメッセージから分離することにより、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へのフェイルオーバーを開始する場合、コントロールチャネルの最初のメッセージとしてASAP_COOKIE_ECHOメッセージに最新のCookieパラメーターを新しいPEに送信する必要があります。上層層がフェールオーバー手順に関与する可能性があります。
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処理手順は、状態共有に使用できます。したがって、Cookieを送信PE ASAPエンドポイントで署名する必要があり、Cookieは受信PEのASAPエンドポイントによって検証する必要があります。検証手順の詳細は、このドキュメントの範囲外です。PUが常に最後に受信したCookieパラメーターを保存し、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とPEの間で通信が開始される場合、どちらかがPU/PEの組み合わせの一部である可能性があります（つまり、エンティティ間でメッセージが送信されます）、PEは常にASAP_BUSINESS_CARDメッセージをPUに送信する必要があります。PUは、PU/PEの組み合わせの一部である場合にのみ、ASAP_Business_CardメッセージをPEに送信する必要があります。ASAP_BUSINESS_CARDメッセージは、PUとPEの間にコントロールチャネルが存在する場合にのみ送信する必要があります。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の組み合わせの一部であるPUの場合、これは不可欠であり、PEがPU/PEの組み合わせ要求サービスのプールハンドルを学習します。第二に、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メッセージを受信すると（セクション2.2.13を参照）、受信ASAPエンドポイントは次のようにする必要があります。
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_DEREGIST_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_DEREGIST_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.
それぞれのASAPメッセージは、SCTPユーザーメッセージと見なされます。ASAPに登録されている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.
制御チャネルに属するASAPメッセージは、ASAPに登録されたPPIDを使用して送信する必要があります。データチャネルに属するメッセージは、ASAPに登録されている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ユーザーとASAPの間にインターフェイスを形成するプリミティブと通知に焦点を当て、ASAPとその低層輸送プロトコル（SCTPなど）との間のインターフェースとの間に焦点を当てます。
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.
注意するには、説明的な目的のために、次の原始的および通知の説明が示されています。このドキュメントにこれらの説明を含めることは、ASAPの多くの側面の操作を理解するために重要であると考えています。ただし、このセクションで説明した正確な構文を使用するには、ASAP実装は必要ありません。
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サブレイヤーにプリミティブを渡します。これらのアクションが完了すると、または特定のイベントが検出されると、ASAPレイヤーはASAPユーザーに通知されます。
Format: registration.request(Pool Handle, User Transport parameter(s))
フォーマット：登録.request（プールハンドル、ユーザートランスポートパラメーター）
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文字列が含まれています。オプションのユーザートランスポートパラメーターは、登録する特定の輸送パラメーターとタイプを示します。このオプションのパラメーターが除外されている場合、ENRPサーバーとの通信に使用されるSCTPエンドポイントは、デフォルトのユーザートランスポートパラメーターとして使用されます。ユーザートランスポートパラメーター内に含まれる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).
ASAPユーザーは、この原始を呼び出してハンドルスペースに追加し、プールのプール要素になります。ASAPユーザーは、ハンドルスペースを使用する他のASAPユーザーがプールハンドルまたはPEハンドルでこのASAPユーザーにメッセージを送信できるようにする前に、このプリミティブを使用してENRPサーバーに登録する必要があります（セクション6.5.1および6.5.3を参照）。
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.
登録原始に応じて、ASAPエンドポイントはASAP_REGISTRATIONメッセージをHome ENRPサーバーに送信し（セクション2.2.1および3.1を参照）、T2-Registrationタイマーを開始します。
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.
ASAP 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メッセージは、ASAPエンドポイントによってHome Endpサーバーに送信されます（セクション2.2.2および3.2を参照）。
Format: cache_populate_request([Pool-Handle | Pool-Element-Handle])
形式：cache_populate_request（[プールハンドル|プールエレメントハンドル]）
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エンドポイントは、プールハンドルに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.
ASAPサービスがローカルキャッシュをサポートしていない場合、このプリミティブはアクションを実行しないことに注意してください。
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.
ユーザーがプールハンドルを渡し、ローカルハンドルの翻訳キャッシュが存在する場合、ASAPエンドポイントは、ローカルキャッシュからプールハンドルのマッピング情報を削除する必要があります。ユーザーがプールエレメントハンドルを渡すと、内部のプールハンドルがcache_purge_requestに使用されます。
Note that if the ASAP service does NOT support a local cache, this primitive performs NO action.
ASAPサービスがローカルキャッシュをサポートしていない場合、このプリミティブはアクションを実行しないことに注意してください。
Format: data_send_request(destinationAddress, typeOfAddress, message, sizeOfMessage, Options);
フォーマット：data_send_request（destivingAddress、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.
送信要求に使用されるアドレスタイプに応じて、送信者のASAPエンドポイントは、メッセージを送信する前にアドレス変換とプール要素の選択を実行できます。これにより、必要な輸送タイプを満たすために、ローカルトランスポートエンドポイントの作成が決定される場合があります。
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.
この場合、destinationAddressと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.
メッセージをプールに送信する前に、送信者のASAPエンドポイントは、最初にプールハンドルを実行して翻訳に対処する必要があります。また、プールに複数のプール要素が存在する場合は、プール要素の選択を実行する必要がある場合があります。
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).
送信者のASAP実装がマッピング情報のローカルキャッシュをサポートしていない場合、またはローカルキャッシュにプールにマッピング情報がない場合、ASAP_HANDLE_RESOLUTIONメッセージ（セクション2.2.5および3.3を参照）を送信します。現在のホームENRPサーバーであり、ENRPサーバーからの応答を待っている間、キューにアウトバウンドメッセージを保持する必要があります（EnRPサーバーが応答する前にこのプールにさらに送信するリクエストもキューに掲載する必要があります）。
Once the necessary mapping information arrives from the ENRP server, the sender's ASAP will:
必要なマッピング情報がENRPサーバーから到着すると、送信者のASAPは次のようになります。
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;
b）プールに複数のPEが存在する場合は、そのうちの1つを選択し、メッセージを送信します。その場合、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]の送信プリミティブが使用されます）。と、
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 Association 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.
ASAPユーザーが複数のPEを含むプールにメッセージを送信するたびに、送信者のASAPエンドポイントは、プール内のPEの1つを現在のメッセージの受信機として選択する必要があります。選択は、メッセージが送信されるプールの現在のサーバープーリングポリシーに従って行われます。
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は登録時に自分自身のポリシー値を指定することもできます。ポリシー値の意味は、グループの現在のサーバープーリングポリシーに依存します。また、PEは、新しいポリシー値を持つハンドルスペースで自分自身を再登録することにより、望むときはいつでもポリシー値を変更することができます。再登録は、別のASOP_REGISTRATIONを自宅のENRPサーバーに送信するだけで行われます（セクション2.2.1を参照）。
One basic policy is defined in this document; others can be found in [RFC5356]
このドキュメントでは、1つの基本的なポリシーが定義されています。その他は[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.
ASAPエンドポイントがプールハンドルでメッセージを送信すると、ラウンドロビンがそのプールの現在のポリシーである場合、送信者のASAPエンドポイントは、そのプールのすべての登録されたPEをラウンドロビングして、各アウトバウンドメッセージの受信機を選択します。アウトバウンドメッセージの均等な配布を実現しようとします。大規模なサーバープールでは、ENRPサーバーがASAPクライアントにすべてのPEを送信しない場合があることに注意してください。この場合、クライアントまたはPUは、プール全体のサブセットでラウンドロビンポリシーを実行します。
In this case, the destinationAddress and typeOfAddress together indicate an ASAP Pool Element handle.
この場合、destinationAddressとTypeOfAddressは一緒にASAPプール要素ハンドルを示します。
This requests that the ASAP Endpoint deliver the message to the PE identified by the Pool Element handle.
これは、ASAPエンドポイントがプール要素ハンドルによって識別された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にメッセージを送信する場合があります。
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) ASAP_HANDLE_RESOLUTIONメッセージを送信して、プールハンドルのハンドル解像度をホームENRPサーバーに尋ねます（セクション2.2.5を参照）、
ii) use the response to update the local cache.
ii）応答を使用して、ローカルキャッシュを更新します。
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.
この場合、destinationAddressとTypeOfAddressは一緒に輸送住所と輸送タイプを示します。
This directs the sender's ASAP Endpoint to send the message out to the specified transport address.
これにより、送信者のASAPエンドポイントに指定された輸送アドレスにメッセージを送信するよう指示します。
No endpoint failover is supported when this form of send request is used. This form of send request effectively bypasses the ASAP endpoint.
この形式の送信要求が使用されている場合、エンドポイントフェールオーバーはサポートされていません。この形式の送信要求は、ASAPエンドポイントを効果的にバイパスします。
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プリミティブのさまざまな形式で渡されたオプションパラメーターは、メッセージ配信の特別な処理に関する送信者のASAPエンドポイントへの指示を与えます。
The value of the Options parameter is generated by bit-wise "OR"ing of the following pre-defined constants:
オプションパラメーターの値は、以下の定義された定数のビットごとに生成されます。
ASAP_USE_DEFAULT: 0x0000 Use default setting.
ASAP_USE_DEFAULT：0x0000デフォルト設定を使用します。
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ハンドルによって指された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：0x0002このオプションにより、送信者のASAPエンドポイントが、最初に選択されたPEまたはPEがPEハンドルによって指されたPEが到達できないことが判明した場合に、任意の代替PEにメッセージを再配置することを禁止します。代わりに、送信者のASAPエンドポイントは、エラーを使用して、到達不能について上部層に通知し、無関係のデータを返します。
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：0x0004このオプションは、送信者のASAPエンドポイントが、このプールに任命された前のメッセージが送信されたプールの同じPEにメッセージを送信することを要求します。
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プールハンドルで送信すると、このオプションは送信者のASAPエンドポイントに、送信者自体がそのプールのPEである場合を除き、すべてのPESにメッセージのコピーを送信するよう指示します。
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)
フォーマット：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関連ID、TCP輸送アドレス、UDP輸送アドレス、またはASAPプール要素ハンドルの形式である可能性があります。
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）ハンドル変換のローカルキャッシュが受信機のASAPエンドポイントで実装されている場合、送信者のIPアドレスからプールハンドルへの逆マッピングを実行する必要があり、マッピングが成功した場合、送信者のASAPプール要素ハンドルを構築して渡す必要があります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.
b）ローカルキャッシュがない場合、または逆マッピングが成功していない場合、SCTP Association IDまたはその他のトランスポート特定の識別（SCTPが使用されていない場合）は、SenderAddressフィールドで渡す必要があります。
Format: error.report(destinationAddress, typeOfAddress, failedMessage, sizeOfMessage)
フォーマット：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を生成して、ASAPユーザーにメッセージの配信とその他の異常について通知する必要があります。
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.
DestivingAddressと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).
この例は、プールユーザーがローカル翻訳キャッシュにないプールにメッセージ「Hello」を送信するときのイベントシーケンスを示しています（ローカルキャッシュがサポートされていると仮定）。
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（ "new-handle"、handle-type、 "hello1"、6、0）;
The ASAP Endpoint, in response, looks up the pool "new-handle" in its local cache, but fails to find it.
ASAPエンドポイントは、それに応じて、ローカルキャッシュのプール「ニューハンドル」を調べますが、それを見つけることができません。
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エンドポイントはメッセージをキューに掲載し、ASAP_Handle_ResolutionリクエストをENRPサーバーに送信します。プール「ニューハンドル」に関するすべての情報を要求します。
3) A T1-ENRPrequest timer is started while the ASAP Endpoint is waiting for the response from the ENRP server.
3) ASAPエンドポイントがENRPサーバーからの応答を待っている間に、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) ASAPでは、T1-ENRPREQUESTタイマーをキャンセルし、プール「New Handle」に関する情報をローカルキャッシュに入力します。
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でのASAPは宛先PE（PEX）を選択し、必要に応じてSCTPアソシエーションをPEX（明示的または暗黙的に）に向けてセットアップし、キューになった「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.
これは、ASAPユーザー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（ "new-handle"、handle-type、 "hello2"、6、0）;
The ASAP Endpoint, in response, looks up the pool "new-handle" in its local cache and finds the mapping information.
ASAPエンドポイントは、それに応じて、ローカルキャッシュのプール「ニューハンドル」を調べて、マッピング情報を見つけます。
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でASAPがPEを選択し（EPXが再度選択されたと仮定）、「hello2」メッセージを送信します（SCTPアソシエーションがすでに設定されていると仮定）。
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.
PEまたはPUのASAPエンドポイントが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.
このセクションでは、追加のプリミティブも定義されており、ASAPを実際のトランスポートとして使用したくないユーザーアプリケーションをサポートしています。
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.
アドレスタイプがプールハンドルであり、ローカルハンドルの翻訳キャッシュが存在する場合、ASAPエンドポイントはその翻訳キャッシュ内を見て、現在の既知のトランスポートタイプ、ポート、およびアドレスを発信者に返す必要があります。
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エンドポイントはプールハンドルを使用して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への送信の失敗に遭遇し、ASAPを使用して * *ではない場合、この原始を使用してASAPエンドポイントに障害を報告できます。ASAPは、この原始に応じてASAP_ENDpoint_unReachableを「ホーム」ENRPサーバーに送信します。ASAPは、ユーザーが実際に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 -ASAPでRequestがENRPサーバーに送信されたときにタイマーが開始されます（アプリケーション情報の提供がキューになります）。通常、15秒に設定されています。
T2-registration - A timer started when sending an ASAP_REGISTRATION request to the Home ENRP server, normally set to 30 seconds.
T2 -registration-通常は30秒に設定されたHome EndpサーバーにASAP_REGISTRATIONリクエストを送信するときにタイマーが開始されました。
T3-deregistration - A timer started when sending a de-registration request to the Home ENRP server, normally set to 30 seconds.
T3-Deregistration-通常は30秒に設定されたHome Endpサーバーに登録解除リクエストを送信するときにタイマーが開始されました。
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-Reregistration-このタイマーは、ENRPハンドルスペースへの登録が成功した後に開始され、定期的な間隔で再登録を引き起こすために使用されます。このタイマーは、通常、登録要求で使用されている生涯パラメーターよりも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":
ASAPメッセージタイプはIANAによって維持されます。図1に記載されているように、IANAによって14の初期値が割り当てられています。IANAは新しいテーブル「ASAPメッセージタイプ」を作成しました。
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.
The references for the already assigned port numbers
すでに割り当てられているポート番号の参照
asap-tcp 3863/tcp
ASAP-TCP 3863/TCP
asap-udp 3863/udp
ASAP-UDP 3863/UDP
asap-sctp 3863/sctp
ASAP-SCTP 3863/SCTP
asap-tcp-tls 3864/tcp
ASAP-TCP-TLS 3864/TCP
asap-sctp-tls 3864/sctp
ASAP-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.
すでに割り当てられているASAPペイロードプロトコル識別子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).
IANAは、IPv4マルチキャストアドレス（224.0.1.185）とIPv6マルチキャストアドレス（FF0X：0：0：0：0：0：0：133）を割り当てました。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 CIPHERSUITEは、少なくとも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、およびPUSはTLSを実装する必要があります。ENRPサーバーとPESは、PSK（Pre-Shared-Key）を使用した相互認証をサポートする必要があります。ENRPサーバーは、PSKを使用して相互認証をサポートする必要があります。PUSは、証明書を使用して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し、ENRP認証にPEの認証メカニズムとして実装することを義務付けています。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サーバーへのPUSの認証メカニズムとして実装することが必須です。PUSは、証明書を使用してENRPサーバーを認証する必要があります。ENRPサーバーは、被写体が標準的なホスト名に対応するサイト証明書を所有する必要があります。PUSには、TLSを使用した相互認証のために独自の証明書がある場合がありますが、このドキュメントに使用するための規定は記載されていません。TLSをサポートするすべてのRSERPOOL要素には、TLS交渉中に受信された証明書を検証するメカニズムが必要です。これには、証明書当局によって発行された1つ以上のルート証明書（できれば、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).
中間の攻撃を防ぐために、クライアントはサーバーのIDを確認する必要があります（サーバーの証明書メッセージに示されているように）。サーバーのID（通常、輸送接続の確立に使用されるID）に対するクライアントの理解は、「参照ID」と呼ばれます。クライアントは、参照IDのタイプ（DNS名またはIPアドレスなど）を決定し、一致が生成されるまで、参照IDと対応するタイプの各subjectaltName値との比較を実行します。一致が作成されると、サーバーのIDが検証され、サーバーIDのチェックが完了します。異なるsubmestaltnameタイプは、さまざまな方法で一致しています。クライアントは、比較を実行する前に、参照IDを別のタイプにマッピングできます。マッピングは、参照IDをマッピングできるすべての利用可能なsubmentaltnameタイプに対して実行できます。ただし、参照IDは、マッピングが本質的に安全であるタイプにのみマッピングする必要があります（たとえば、dnsnameのsumberaltnameと比較するためにdns名を抽出して、マッピングが安全な方法で実行される（たとえば、DNSセキュリティ（DNSSEC）を使用するか、ユーザーまたは管理者が構成されているホストからアドレスへ/アドレスからホストへのルックアップテーブルを使用します）。
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が疑わしいことを示す必要があります。自動化されたクライアントは、トランスポート接続を閉じてから、サーバーの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が国際化されたドメイン名である場合、適合実装は、[RFC3490]のセクション4で指定されているように、型DNSNAMEの対象値と比較する前に、ASCII互換エンコード（ACE）形式に変換する必要があります。具体的には、[RFC3490]のセクション4で指定された変換操作を次のように実行する必要があります。 *ステップ1では、ドメイン名は「保存された文字列」と見なされます。*ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。*ステップ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.
「to-ascii」変換を実行した後、RFC 3490のセクション3で指定されたルールに従って、DNSラベルと名前を平等と比較する必要があります。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アドレスである場合、IDは[RFC0791]および[RFC2460]の「ネットワークバイト順」オクテット文字列表現に変換する必要があります。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16のオクテットが含まれます。次に、このOctet文字列は、iPaddressのタイプのsubjectaltname値と比較されます。参照IDオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
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（RE）交渉が完了した直後に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.
[RFC3436]で説明されているように、[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では、ASAPプロトコルがASAP_ENDpoint_UnReachableメッセージの数（セクション3.5を参照）をENRPサーバーに制限する必要があります。
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では、entRPプロトコルがASAP_ENDPOINT_KEEP_ALIVEメッセージの数をENRPサーバーからPEに制限する必要があります（[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.
マルチキャストのアナウンスについて定義されたセキュリティメカニズムはありません。したがって、このような発表の受信者は、そのようなメッセージのソースアドレスをEntRPサーバーの信頼できるアドレスであると考えることはできません。また、受信者は、攻撃者から多数のマルチキャストアナウンスを受け取る準備をする必要があります。
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で実装するために必須であり、RSERPOOLを含む3つのアーキテクチャコンポーネントすべて、つまりPU、PE、およびENRPサーバーのTLS実装に基づいています。すべての通信にTLSを使用し、Enrpピアを認証し、PE登録者を保護された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を使用して認証および通信する場合、信頼のチェーンは健全です。Trustチェーンのルートは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サーバーに登録しようとする場合、セキュリティに関する考慮事項によりエラーとして示されたエラーメッセージ応答がedricedされ、登録は拒否されます。TLSを使用していないENRPサーバーが、Secure 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がEntRPに安全なリクエストを送信することです。ENRPとPESが固定されていない可能性があり、これは許容される構成です。目的は、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アーキテクチャコンポーネントは、互いに通信して、信頼の連鎖を確立することができます。SECUED 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.
著者は、ジョン・ラフニー、リンドン・オング、ウォルター・ジョンソン、トーマス・ドレイブホルツなどに感謝したいと考えています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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.、Xie、Q.、Stewart、R.、Shore、M.、Ong、L.、Loughney、J。、およびM. Stillman、「信頼できるサーバープーリングの要件」、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.、Rescorla、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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）およびEndpoint Handlespace Redundancy Protocol（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] Xie、Q.、Stewart、R.、Stillman、M.、Tuexen、M.、およびA. Silverton、「エンドポイントハンドルスペース冗長プロトコル（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] Stillman、M.、Ed。、Gopal、R.、Guttman、E.、Holdrege、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] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
Qiaobing Xieリソースグループ1700ペンシルバニアアベニアNWスイート560ワシントンD.C.、20006 USA
Phone: +1 224-465-5954
EMail: Qiaobing.Xie@gmail.com
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 USA
Maureen Stillman Nokia 1167 Peachtree Ct。Naperville、IL 60540 USA
EMail: maureen.stillman@nokia.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケル・テクセン・ミューンスター大学。Applied SciencesStegerwaldstraßeの。39 48565 Steinfurtドイツ
EMail: tuexen@fh-muenster.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。