RFC5352 日本語訳
5352 Aggregate Server Access Protocol (ASAP). R. Stewart, Q. Xie, M.Stillman, M. Tuexen. September 2008. (Format: TXT=118712 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループR.スチュワートの要求をネットワークでつないでください: 5352年のQ.シェカテゴリ: 実験的である、応用科学2008年9月の資源グループM.蒸留装置操作係ノキアM.Tuexen Muenster大学
Aggregate Server Access Protocol (ASAP)
集合サーバアクセス・プロトコル(できるだけ早い)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
Server Accessプロトコルに集めてください。(できるだけ早く、Endpoint Handlespace Redundancyプロトコル(ENRP; RFC5353)に関連して、RFC5352)は高可用性データ転送メカニズムをIPネットワークの上に提供します。 できるだけ早く、IPアドレス(es)から論理的なコミュニケーション終点を隔離する、その結果、事実上、通常、1ポイントの失敗を構成するコミュニケーション終点とその物理的な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 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.
できるだけ早く、Stream通信制御プロトコル(SCTP; RFC4960)によって提供されたネットワークレベル冗長を最大限に利用するように設計されます。 SCTP以外の各トランスポート・プロトコルには、付随の輸送マッピングドキュメントがなければなりません。 できるだけ早くPool Elements(PEs)とENRPサーバの間で通過されたメッセージがSCTPトランスポート・プロトコルを使用しなければならないことに注意されるべきです。
The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service.
すなわち、プーリングが獲得される2つのプロトコルを結合する高可用性サーバ、できるだけ早さ、ENRP(ENRPが高い有用性Pool Handle翻訳サービスを定義している間、Pool Handleが翻訳、負荷分割法管理、および障害管理に演説するようにできるだけ早くユーザーインタフェースを提供するコネ)
Stewart, et al. Experimental [Page 1] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[1ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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
1. 序論…4 1.1. 定義…4 1.2. コンベンション…5 1.3. このドキュメントの組織…6 1.4. できるだけ早さの範囲…6 1.4.1. Handlespaceの範囲…6 2. メッセージ定義…6 2.1. できるだけ早さ、パラメタ形式…7 2.2. できるだけ早く、通信します…7 2.2.1. _できるだけ早く、登録は通信します…7 2.2.2. _できるだけ早く、DEREGISTRATIONは通信します…8 2.2.3. できるだけ早さ、_登録_応答メッセージ…9 2.2.4. できるだけ早さ、_DEREGISTRATION_応答メッセージ…10 2.2.5. できるだけ早く、_は_解決メッセージを扱います…10 2.2.6. できるだけ早く、_は_解決_応答メッセージを扱います…11 2.2.7. _できるだけ早く、生きている終点_生活費_は通信します…13 2.2.8. _できるだけ早く、終点_は_を生かします。_ACKは通信します…14 2.2.9. できるだけ早さ、_の終点の_の手の届かないメッセージ…14 2.2.10. _できるだけ早く、サーバ_はメッセージを発表します…15 2.2.11. _できるだけ早く、クッキーは通信します…16 2.2.12. _できるだけ早く、クッキー_はメッセージを反映します…16 2.2.13. _できるだけ早く、ビジネス_カードは通信します…17 2.2.14. できるだけ早さ、_エラーメッセージ…17 3. 手順…18 3.1. 登録…18 3.2. 反-登録…21 3.3. 解決を扱ってください…23 3.4. 終点は生きているままです…25 3.5. 手の届かない終点…26 3.6. ENRPサーバ狩り手順…27 3.7. できるだけ早く、ENRPサーバ通信障害に終点を扱います…28 3.7.1. SCTPは失敗を送ります…28 3.7.2. T1-ENRPrequestタイマ満了…29 3.7.3. 登録失敗…29 3.8. クッキー処理手順…29 3.9. 名刺取り扱い手順…30 4. 終点の役割…31 5. SCTP問題…31 6. できるだけ早く、連結します…31 6.1. 登録要求プリミティブ…32 6.2. Deregistration要求プリミティブ…32 6.3. CachePopulateRequest原始…33 6.4. CachePurgeRequest原始…33 6.5. DataSendRequest原始…33 6.5.1. プールハンドルに発信します…34
Stewart, et al. Experimental [Page 2] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[2ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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
6.5.2. 要素選択をプールしてください…35 6.5.2.1. 連続方針…35 6.5.3. プール要素ハンドルに発信します…35 6.5.4. 輸送アドレスで、発信してください…37 6.5.5. メッセージ配送オプション…37 6.6. Data.Received通知…38 6.7. Error.Report通知…39 6.8. 例…39 6.8.1. 新しいプールに発信してください…39 6.8.2. キャッシュされたプールハンドルに発信してください…40 6.9. PEは失敗を送ります…41 6.9.1. 翻訳要求プリミティブ…41 6.9.2. Transport.Failure原始…42 7. タイマ、変数、および敷居…42 7.1. タイマ…42 7.2. 変数…42 7.3. 敷居…43 8. IANA問題…43 8.1. できるだけ早い新しいテーブルはタイプを通信させます…43 8.2. 数を移植してください…44 8.3. SCTP有効搭載量プロトコル識別子…44 8.4. マルチキャストアドレス…44 9. セキュリティ問題…44 9.1. RSerPool軍事的脅威の概要…45 9.2. セキュリティがメカニズムであると実装します…46 9.3. 信頼のチェーン…49 10. 承認…50 11. 参照…50 11.1. 標準の参照…50 11.2. 有益な参照…51
Stewart, et al. Experimental [Page 3] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[3ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
1. Introduction
1. 序論
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.
Endpoint Name Resolutionプロトコル[RFC5353]に関連して使用されると、Aggregate Server Accessプロトコルは(できるだけ早く、)高い有用性データ転送メカニズムをIPネットワークの上に提供します。 できるだけ早く、IPアドレス(es)から論理的なコミュニケーション終点を隔離する、その結果、事実上、通常、1ポイントの失敗を構成するコミュニケーション終点とその物理的な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.
複数の受信機インスタンスが同じくらい下に存在しているときには(通称サーバプール)を扱ってください、できるだけ早く、Endpointはサーバプールで示された現在の負荷分割法方針に基づいて1Pool Element(PE)を選択して、選択されたPEにメッセージを提供するでしょう。
While delivering the message, ASAP can be used to monitor the reachability of the selected PE. If it is found unreachable, before notifying the message sender (an ASAP User) of the failure, ASAP can automatically select another PE (if one exists) under that pool and attempt to deliver the message to that PE. In other words, ASAP is capable of transparent failover amongst PE instances within a server pool.
メッセージを提供している間、できるだけ早く、選択されたPEの可到達性をモニターするのに使用できます。 メッセージ送付者に通知する前にそれが手が届かないのがわかる、(できるだけ早さ、User、)、できるだけ早く、失敗を、そのプールの下で自動的に別のPEを選択して(1つが存在しているなら)、そのPEにメッセージを提供するのを試みることができます。 言い換えれば、サーバプールの中にPEの中にインスタンスができるだけ早く透明なフェイルオーバーができた状態であります。
ASAP depends on ENRP, which provides a high-availability Pool Handlespace. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as presentation to the upper layer (aka an ASAP User) via a unified primitive interface.
できるだけ早く、高可用性Pool HandlespaceはENRPによります。(ENRPは提供します)。 できるだけ早く上側の層への基本的な輸送技術、負荷流通管理、障害管理、およびプレゼンテーションの抽象化に責任がある、(別名、できるだけ早さ、User、)、統一された原始のインタフェースを通して。
When SCTP [RFC4960] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by SCTP.
SCTP[RFC4960]ができるだけ早くトランスポート層プロトコルとして使用されるとき、シームレスに、SCTPによって提供されたリンクレイヤ冗長は取り入れることができます。
This document defines the ASAP portion of the high-availability server pool.
このドキュメントが定義する、できるだけ早く、高可用性サーバプールを分配してください。
1.1. Definitions
1.1. 定義
This document uses the following terms:
このドキュメントは次の用語を使用します:
ASAP User: Either a PE or Pool User (PU) that uses ASAP.
できるだけ早さ、ユーザ: PEかPool User(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によって提示されると、それは、送付者が属すプールを指定して、フェイルオーバーの場合に代替のPEsのリストを提供します。
Stewart, et al. Experimental [Page 4] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[4ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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 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.
要素ハンドル(または、終点ハンドル)をプールしてください: プールの中の特定のPool Elementへの論理的な指針、Pool Handleと目的地から成るのはPool Elementのアドレスを輸送します。
Handlespace: A cohesive structure of Pool Handles and relations that
may be queried by an internal or external agent.
Handlespace: 内部の、または、外部のエージェントによって質問されるかもしれないPool Handlesと関係の粘着性がある構造。
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.
ホームENRPサーバ: PEかPUが現在すべての名前空間サービスのリクエストを送るENRPサーバ。 その時々で、PEには1つのホームENRPサーバがあるだけでよくて、PEとそのホームENRPサーバの両方が、この関係を知って、動向をおさえなければなりません。 PUがホームENRPサーバとして利用可能なENRPサーバの1つを選定するはずですが、集合的なENRPサーバが発信でこれを変えるかもしれない、_できるだけ早く、ENDPOINT_KEEP_ALIVEは通信します。
ENRP Client Channel: The communication channel through which an ASAP
User sends all namespace service requests. The client channel is
usually defined by the transport address of the Home ENRP server
and a well-known port number. The channel MAY make use of
multicast or a named list of ENRP servers.
ENRPクライアントチャンネル: 通信チャネル、通じて、どれ、できるだけ早く、Userはすべての名前空間サービスのリクエストを送るか。 通常、クライアントチャンネルはホームENRPサーバとウェルノウン・ポート番号の輸送アドレスによって定義されます。 チャンネルはマルチキャストかENRPサーバの命名されたリストを利用するかもしれません。
Network Byte Order: Most significant byte first, aka Big Endian.
バイトオーダーをネットワークでつないでください: 最初に、通称最も重要なバイト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).
アドレスを輸送してください: 輸送アドレスはNetwork Layerアドレスによって伝統的に定義されます、そして、Transport Layerは議定書を作ります、そして、Transport Layerは数を移植します。 IPをひくSCTPの場合では、輸送アドレスはIPアドレスとSCTPポートナンバー(SCTPがTransportプロトコルであるところ)の組み合わせで定義されます。
1.2. Conventions
1.2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Stewart, et al. Experimental [Page 5] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[5ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
1.3. Organization of This Document
1.3. このドキュメントの組織
Section 2 details the ASAP message formats. In Section 3, we provide detailed ASAP procedures for the ASAP implementer. Section 4 summarizes which messages need to be supported by which nodes, and Section 5 describes the usage of SCTP. In Section 6, details of the ASAP interface are given, focusing on the communication primitives between ASAP, the applications above ASAP, and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layers). Also included in this discussion are relevant timers and configurable parameters, as appropriate. Section 7 provides threshold and protocol variables.
セクション2が詳しく述べる、できるだけ早く、書式を通信させてください。 セクション3に、私たちができるだけ早く詳細な状態で提供する、手順、できるだけ早さ、implementer。 セクション4はどのどのノードによってサポートするべきであるかメッセージの必要性をまとめるか、そして、セクション5はSCTPの使用法を説明します。 セクション6、詳細である、できるだけ早く連結してください、当然のこと、できるだけ早さであることの間のコミュニケーション基関数、できるだけ早い上のアプリケーションと、できるだけ早く、それ自体、およびできるだけ早さであることの間のコミュニケーション基関数の焦点を合わせて、および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で全リストを見つけることができます。
1.4. Scope of ASAP
1.4. できるだけ早さの範囲
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.
高値のための有用性とスケーラビリティが要件を含意しない要件は状態とデータを共有しました。 トランザクションフェイルオーバーを提供してください。できるだけ早さ、ホストかアプリケーションがトランザクションの処理の間、失敗するなら、このトランザクションは失われてもよいです。 いくつかのサービスが失敗を扱う方法を提供するかもしれませんが、これは保証されません。 できるだけ早く、状態を共有するためにメカニズムを造るのにアプリケーションを助けるためにフックを提供するかもしれませんが、本来できるだけ早く、少しの状態も共有しません。
1.4.1. Extent of the Handlespace
1.4.1. Handlespaceの範囲
The scope of ASAP/ENRP is NOT Internet-wide. The handlespace is neither hierarchical nor arbitrarily large like DNS. A flat peer-to- peer model is detailed. Pools of servers will exist in different administrative domains. For example, suppose the use of ASAP and ENRP is wanted. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact a server pool in Japan instead of North America. The PU would use DNS to get the list of IP addresses of the Japanese server pool; that is, the ENRP client channel in Japan. From there, the PU would query the Home ENRP server it established and then directly contact the PE(s) of interest.
できるだけ早さでは、/ENRPが広さのNOTインターネットであることを見てください。 handlespaceは階層的でなくて、またDNSのように任意に大きくはありません。 平坦な同輩から同輩へのモデルは詳細です。 サーバのプールは異なった管理ドメインに存在するでしょう。 例えば、できるだけ早さの使用を仮定してください。そうすれば、ENRPは欲しいです。 まず最初に、PUは、ENRPサーバに連絡するのにDNSを使用するかもしれません。北アメリカのPUが北アメリカの代わりに日本のサーバプールに連絡したがっていると仮定してください。 PUは日本のサーバプールのIPアドレスのリストを得るのにDNSを使用するでしょう。 すなわち、日本のENRPクライアントチャンネル。 そこから、PUはそれが確立したホームENRPサーバについて質問して、次に、興味があるPE(s)に直接連絡するでしょう。
2. Message Definitions
2. メッセージ定義
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バイトより大きい分野に、括弧の1組の数は、バイト数における、分野の長さを示すためにフィールド名に従うかもしれません。
Stewart, et al. Experimental [Page 6] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[6ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
2.1. ASAP Parameter Formats
2.1. できるだけ早さ、パラメタ形式
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 MUST使用の間でSCTPを交換しました、メッセージはできるだけ早く、輸送としてENRPサーバとPU MUST使用の間でSCTPかTCPのどちらかを交換しましたが。 PUデータ通信量へのPEは登録の間にPEによって指定されたどんなトランスポート・プロトコルも使用するかもしれません。
2.2. ASAP Messages
2.2. できるだけ早く、通信します。
This section details the individual messages used by ASAP. These messages are composed of a standard message format found in Section 4 of [RFC5354]. The parameter descriptions can be found in [RFC5354].
このセクションはできるだけ早さまでに使用される個々のメッセージを詳しく述べます。 これらのメッセージは[RFC5354]のセクション4で見つけられた標準のメッセージ・フォーマットで構成されます。 [RFC5354]でパラメータ記述を見つけることができます。
The following ASAP message types are defined in this section:
以下はできるだけ早く、このセクションで定義されますメッセージが、タイプする:
Type Message Name ----- ------------------------- 0x00 - (Reserved by IETF) 0x01 - ASAP_REGISTRATION 0x02 - ASAP_DEREGISTRATION 0x03 - ASAP_REGISTRATION_RESPONSE 0x04 - ASAP_DEREGISTRATION_RESPONSE 0x05 - ASAP_HANDLE_RESOLUTION 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 0x09 - ASAP_ENDPOINT_UNREACHABLE 0x0a - ASAP_SERVER_ANNOUNCE 0x0b - ASAP_COOKIE 0x0c - ASAP_COOKIE_ECHO 0x0d - ASAP_BUSINESS_CARD 0x0e - ASAP_ERROR others - (Reserved by IETF)
タイプメッセージ名----- ------------------------- _できるだけ早く、サーバ_はできるだけ早く、0x0bを発表します。0×00((IETFによって予約されます)0×01)、できるだけ早さ、_登録0x02--、できるだけ早さ、_DEREGISTRATION0x03--、できるだけ早さ、_登録_応答0x04--、できるだけ早さ、_DEREGISTRATION_応答0x05、--、できるだけ早く、_は_解決0x06を扱います--できるだけ早く、_は_解決_応答0x07を扱います--_できるだけ早く、終点_が_を生かす0×08、--、_できるだけ早く、終点_が_を生かす_ACK0x09--、できるだけ早さ、__終点の手の届かない0x0a--、_クッキー0x0c--_できるだけ早く、クッキー_は0x0dを反響します--、できるだけ早さ、_ビジネス_カード0x0e--、できるだけ早さ、_誤り他のもの、-(IETFによって予約されます)
Figure 1
図1
2.2.1. ASAP_REGISTRATION Message
2.2.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
_できるだけ早く、REGISTRATIONメッセージは、新しいプールを作成するか、または既存のプールにそれ自体を加えるためにPEによってホームENRPサーバに送られます。 PE発信、_できるだけ早く、REGISTRATIONメッセージはPool HandleパラメタとPool Elementパラメタに記入しなければなりません。 Pool Handleパラメタは、登録されるために名前を指定します。 記入者でセクション3.1に概説されているようにPool Elementパラメタに記入しなければなりません。 登録メッセージを送るPEがそうしなければならないことに注意してください。
Stewart, et al. Experimental [Page 7] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[7ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
send the message using an SCTP association. Furthermore, the IP address(es) of the PE that is registered within the Pool Element parameter MUST be a subset of the IP address(es) used in the SCTP association, regardless of the registered transport protocol.
SCTP協会を使用することでメッセージを送ってください。 その上、Pool Elementパラメタの中に登録されるPEのIPアドレス(es)はSCTP協会で使用されるIPアドレス(es)の部分集合であるに違いありません、登録されたトランスポート・プロトコルにかかわらず。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x01をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
Pool Element Parameter:
要素パラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
2.2.2. ASAP_DEREGISTRATION Message
2.2.2. _できるだけ早く、DEREGISTRATIONは通信します。
The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP server to remove itself from a pool to which it registered.
_できるだけ早く、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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x02をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE識別子パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
PE Identifier Parameter:
PE識別子パラメタ:
See [RFC5354].
[RFC5354]を見てください。
Stewart, et al. Experimental [Page 8] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[8ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
PE発信、_できるだけ早く、DEREGISTRATION MUSTは、ENRPサーバが終点のアイデンティティについて確かめるのを許容するためにPool HandleとPE識別子パラメタに記入します。 反-登録が代理人を通して許されていないことに注意してください。 言い換えれば、PEは反-それ自体を登録するだけであるかもしれません。
2.2.3. ASAP_REGISTRATION_RESPONSE Message
2.2.3. できるだけ早さ、_登録_応答メッセージ
The ASAP_REGISTRATION_RESPONSE message is sent in response by the Home ENRP server to the PE that sent an ASAP_REGISTRATION message.
_できるだけ早く、REGISTRATION_RESPONSEメッセージが発信したPEへのホームENRPサーバによる送られた応答である、_できるだけ早く、REGISTRATIONは通信します。
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x03をタイプしてください。|0|0|0|0|0|0|0|R| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE識別子パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 誤操作(任意の): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
誤りかいくつかの非定型的なイベントが登録手続の間、発生したなら、このパラメタは含まれています。 R旗が'1'に設定されるとき、存在しているなら、このパラメタは拒絶の原因を示します。 R旗が'0'に設定されるとき、存在しているなら、このパラメタは警告として登録しているPEに機能します、それを知らせてそれ
Stewart, et al. Experimental [Page 9] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[9ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
登録値のいくつかがENRPサーバによって変更されたかもしれません。登録がうまくいって、警告してはいけなければ、このパラメタは含まれていません。
2.2.4. ASAP_DEREGISTRATION_RESPONSE Message
2.2.4. できるだけ早さ、_DEREGISTRATION_応答メッセージ
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.
に対応して_できるだけ早く、ホームENRPサーバでDEREGISTRATION_RESPONSEメッセージをPEに返す、_できるだけ早く、DEREGISTRATIONは通信するか、またはプールにおける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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x04をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE識別子パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 誤操作(任意の): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
誤りかいくつかの非定型的なイベントが反-登録手続の間、発生したなら、このパラメタは含まれています。 反-登録がうまくいったなら、このパラメタは含まれていません。
2.2.5. ASAP_HANDLE_RESOLUTION Message
2.2.5. できるだけ早く、_は_解決メッセージを扱います。
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.
_できるだけ早く、HANDLE_RESOLUTIONメッセージは、Pool Elementsのリストの中へのPool Handleによって示されたプールの部材であるPool Handleを決議するためにPEかPUのどちらかによってホームENRPサーバに送られます。
Stewart, et al. Experimental [Page 10] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[10ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x05をタイプしてください。|0|0|0|0|0|0|0|S| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'S' bit:
'、'ビットです:
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.
'、'セットされるなら噛み付かれて'1、'PoolであるときにダイナミックにこのPoolにアップデートを送るホームENRPサーバがSCTP協会の生涯変化するという要求はそうです。 ダイナミックなアップデート、_ユーザが、送る必要があることのないHANDLE_RESOLUTION_RESPONSEメッセージができるだけ早くプールに、追加するのから成っている、できるだけ早さ、_HANDLE_RESOLUTION。
If the 'S' bit is set to '0', no Dynamic updates are requested.
'ビットは設定されること'。'、0、'Dynamicアップデートは全く要求されていません。
Note that if a new Home ENRP server is adopted, any 'dynamic update request' will need to be re-sent to the new Home ENPR server if the endpoint would like to continue to receive updates. In other words, the ENRP servers do NOT share state regarding which of its PU's are requesting automatic update of state. Thus, upon change of Home ENRP server, the PU will need to re-send an ASAP_HANDLE_RESOLUTION message with the 'S' bit set to '1'. Note also, that the 'S' bit will only cause Dynamic update of a Pool when the Pool exists. If a negative response is returned, no further updates to the Pool (when it is created) will occur.
新しいホームENRPサーバが採用されると、終点が、アップデートを受け続けたいならどんな'ダイナミックな更新要求'も、新しいホームENPRサーバに再送される必要に注意してください。 言い換えれば、PUのどれが状態の自動アップデートを要求するかに関してENRPサーバは状態を共有しません。 再送する、'その結果、ホームENRPサーバの変化のPUが、必要があるできるだけ早さ、_HANDLE_RESOLUTIONが通信する、''1に設定されたビット'はそうです。 'それにも注意してください、'Poolが存在するときの意志の原因DynamicだけがアップデートするPoolのビットはそうです。 否定応答を返すと、Pool(それが作成されるとき)へのさらなるアップデートは全く起こらないでしょう。
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message
2.2.6. できるだけ早く、_は_解決_応答メッセージを扱います。
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.
_できるだけ早く、発信したPUかPEのホームENRPサーバで応答でHANDLE_RESOLUTION_RESPONSEメッセージを送る、_できるだけ早く、PUがDynamicアップデートを要求したなら、HANDLE_RESOLUTIONを通信するか、またはPool変化で定期的に送ります。
Stewart, et al. Experimental [Page 11] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[11ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x06をタイプしてください。|0|0|0|0|0|0|0|A| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 総合的なPE選択方針(任意の): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタ1(任意の)をプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタN(任意の)をプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 誤操作(任意の): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'A' bit:
ビット:
This bit is set to '1' if the ENRP server accepts the request to send automatic updates (i.e., the 'S' bit was set on the request). If this bit is set to '0', either the ENRP server does NOT support automatic updates, it has resource issues and cannot supply this feature, or the user did not request it.
すなわち、'ENRPサーバが自動アップデートを送るために要請を受け入れるならこのビットが'1'に設定される、('ビットが要求に設定されたということである、) このビットが'0'に設定されるなら、ENRPサーバが自動アップデートをサポートしないか、リソース問題を持って、この特徴を提供できませんか、またはユーザはそれを要求しませんでした。
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
Overall PE Selection Policy (optional):
総合的なPE選択方針(任意の):
See [RFC5354].
[RFC5354]を見てください。
This parameter can be present when the response is positive. If present, it indicates the overall pool member selection policy of the pool. If not present, a Round-Robin overall pool member selection policy is assumed. This parameter is not present when the response is negative.
応答が積極的であるときに、このパラメタは存在している場合があります。 存在しているなら、それはプールの総合的なプールメンバー選択方針を示します。 プレゼントでないなら、Round-ロビンの総合的なプールメンバー選択方針は想定されます。 応答が否定的であるときに、このパラメタは存在していません。
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パラメタ(存在しているなら)の中のどんな負荷方針パラメタも、無視しなければならなくて、総合的なプールメンバー選択方針を決定するのに使用されてはいけません。
Pool Element Parameters (optional):
要素パラメタ(任意の)をプールしてください:
See [RFC5354].
[RFC5354]を見てください。
Stewart, et al. Experimental [Page 12] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[12ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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パラメタの勢ぞろいは含まれています、命名されたプールの中にPEsに関する現行情報を示して。 少なくとも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サーバによって拒絶されました)。 このパラメタ(存在しているなら)の原因コードはハンドル解決要求が拒絶された(例えば要求されたPool Handleは見つけられませんでした)理由を示すでしょう。 このパラメタの欠如は、応答が積極的であることを示します。
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message
2.2.7. _できるだけ早く、生きている終点_生活費_は通信します。
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.
_できるだけ早く、ENRPサーバはENDPOINT_KEEP_ALIVEメッセージをPEに送ります。 _できるだけ早く、'H'に噛み付いたなら新しいホームENRPサーバが'1'に設定されるとき、ENDPOINT_KEEP_ALIVEメッセージは、PEが届いていることを確かめるのに使用されて、PEが送付サーバを採用するのを必要とします。 _できるだけ早く、いくらか、ENDPOINT_KEEP_ALIVEは通信します。'H'ビットの設定にかかわらずできるだけ早さ、Endpointが応じなければならない、できるだけ早さ、_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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x07をタイプしてください。|0|0|0|0|0|0|0|H| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H (Home ENRP server) Flag:
H(ホームENRPサーバ)旗:
When set to '1', indicates that the ENRP server that sends this message wants to be the Home ENRP server of the receiver of this message.
いつが、'1'にセットして、このメッセージを送るENRPサーバがこのメッセージの受信機についてホームENRPサーバになりたいのを示しますか?
Server Identifier: 32 bits (unsigned integer)
サーバ識別子: 32ビット(符号のない整数)
This is the ID of the ENRP server, as discussed in [RFC5353].
これは[RFC5353]で議論するようにENRPサーバのIDです。
Stewart, et al. Experimental [Page 13] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[13ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message
2.2.8. _できるだけ早く、終点_が_を生かす、_ACKメッセージ
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.
に対応して_できるだけ早く、ENDPOINT_KEEP_ALIVE_ACKメッセージがPEによって送られる、_できるだけ早く、ALIVEが通信させるENDPOINT_KEEP_は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 = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x08をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE識別子パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
PE Identifier Parameter:
PE識別子パラメタ:
See [RFC5354].
[RFC5354]を見てください。
2.2.9. ASAP_ENDPOINT_UNREACHABLE Message
2.2.9. できるだけ早さ、_の終点の_の手の届かないメッセージ
The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to its Home ENRP server to report an unreachable PE.
_できるだけ早く、ENDPOINT_UNREACHABLEメッセージは、手の届かないPEを報告するために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 = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x09をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE識別子パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
Stewart, et al. Experimental [Page 14] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[14ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
PE Identifier Parameter:
PE識別子パラメタ:
See [RFC5354].
[RFC5354]を見てください。
2.2.10. ASAP_SERVER_ANNOUNCE Message
2.2.10. _できるだけ早く、サーバ_はメッセージを発表します。
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.
_できるだけ早く、ENRPサーバは、PUsとPEsがENRPサーバに接続するのに必要な輸送情報を知るように、SERVER_ANNOUNCEメッセージを送ります。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0aをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 輸送Param#1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 輸送Param#2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ..... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 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 Transportパラメタに関して[RFC5354]を見てください。
Only SCTP and TCP Transport parameters are allowed for use within the SERVER_ANNOUNCE message.
SCTPとTCP TransportパラメタだけがSERVER_ANNOUNCEメッセージの中の使用のために許容されています。
Stewart, et al. Experimental [Page 15] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[15ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
2.2.11. ASAP_COOKIE Message
2.2.11. _できるだけ早く、クッキーは通信します。
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.
できるだけ早く、_COOKIEメッセージはPEによってPUに送られます、PEがそれが共有したがっている情報を伝えるのを制御チャンネルを使用することで許容して。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0bをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : クッキーパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter :
クッキーパラメタ:
See [RFC5354].
[RFC5354]を見てください。
2.2.12. ASAP_COOKIE_ECHO Message
2.2.12. _できるだけ早く、クッキー_はメッセージを反映します。
The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it detects a failure with the current PE to aid in failover. The Cookie Parameter sent by the PE is the latest one received from the failed PE.
_できるだけ早く、それがフェイルオーバーで支援するために現在のPEがある失敗を検出すると、COOKIE_ECHOメッセージはPUによって新しいPEに送られます。PEによって送られたCookie Parameterは失敗した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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0cをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : クッキーパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter:
クッキーパラメタ:
See [RFC5354].
[RFC5354]を見てください。
Stewart, et al. Experimental [Page 16] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[16ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
2.2.13. ASAP_BUSINESS_CARD Message
2.2.13. _できるだけ早く、ビジネス_カードは通信します。
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.
_できるだけ早く、BUSINESS_CARDメッセージは、PUによってPEに送られるか、またはPEからプールハンドルと都合のよいフェイルオーバーを伝えるのに制御チャンネルを使用するPUまで注文されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0dをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタ-1をプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : .. : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタ-Nをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter:
ハンドルパラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
Pool Element Parameters:
要素パラメタをプールしてください:
See [RFC5354].
[RFC5354]を見てください。
2.2.14. ASAP_ERROR Message
2.2.14. できるだけ早さ、_エラーメッセージ
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.
_できるだけ早く、応答でERRORメッセージを送る、できるだけ早さ、できるだけ早く未知のメッセージか発信への未知のパラメタを受け取るEndpoint、問題か問題を報告するEndpoint。
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 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0eをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 誤操作パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Parameter:
誤操作パラメタ:
See [RFC5354].
[RFC5354]を見てください。
Stewart, et al. Experimental [Page 17] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[17ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
いつ、できるだけ早さ、Endpoint、受信、できるだけ早く通信してくださいか、未知のメッセージタイプか知られているタイプに関するメッセージで、それが未知のパラメタを含んでいて、それが未知が通信させるSHOULDハンドルであるか認識されていないメッセージとパラメタに従った未知のパラメタはセクション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.
_できるだけ早く、ERRORはそれを通信させます。規則に従って、送付者がメッセージへのエラー・レポートであるなら必要である、できるだけ早く誤りSHOULDを発見した終点が発信して戻る、適切な原因コード、原因の長さ、およびケース特殊情報があるOperational Errorパラメタを含んでいます。
3. Procedures
3. 手順
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).
このセクションはできるだけ早くインターナルによって用いられたメソッドと手順に焦点を合わせるでしょう。Endpoint。 また、失敗検出と管理のための適切なタイマと回復動作について議論します。 また、できるだけ早く、PEとPUの間に送られたメッセージはSCTP有効搭載量プロトコルIdentifier(PPID)によって特定されます。
3.1. Registration
3.1. 登録
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 MUSTは、それ自体とホームENRPサーバの間に設立されたSCTP協会を使用することで登録します。PEがホームENRPサーバを確立していないなら、手順がセクション3.6で指定したということにならなければなりません。
Once the PE's ASAP Endpoint has established its Home ENRP server, the following procedures MUST be followed to register:
かつてのPEのもの、できるだけ早く、Endpointはホーム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) PE(にかかわらずトランスポート・プロトコルがPEへのサービス利用者要求に使用される)によって使用されるすべてのIPアドレスにホームENRPサーバとコミュニケートするのに使用されるPEのSCTP終点を縛らなければなりません。
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のもの、できるだけ早くEndpointが定式化しなければならない、_できるだけ早く、REGISTRATIONはセクション2.2で.1に定義されるように通信します。 メッセージ、PE MUSTを定式化する際に:
R2.1) Fill in the Pool Handle parameter to specify which server
pool the ASAP Endpoint wishes to join.
R2.1) Pool Handleパラメタに記入して、どのサーバプールを指定してくださいか、できるだけ早く、Endpointは接合したがっています。
R2.2) Fill in the PE identifier using a good-quality randomly
generated number ([RFC4086] provides some information on
randomness guidelines).
R2.2) 良質の手当たりしだいに発生している数を使用して、PE識別子に記入してください([RFC4086]は偶発性ガイドラインの何らかの情報を提供します)。
Stewart, et al. Experimental [Page 18] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[18ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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) この登録が有効である秒数でRegistration Lifetimeパラメタに記入してください。 登録が期限が切れる前にサービスを続けたがっている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) User Transportパラメタに記入して、輸送のタイプとPEがサポートしても構わないと思っているデータ/コントロールチャンネル用法を指定してください。 既存のサーバプールを接合する際に、PE MUSTがプールの総合的な輸送タイプと総合的なデータ/コントロールチャンネル使用法に従うことに注意してください。 さもなければ、登録はENRPサーバによって拒絶されるかもしれません。
R2.5) Fill in the preferred Pool Member Selection Policy
parameter.
R2.5) 都合のよいPoolメンバーSelection Policyパラメタに記入してください。
R3) Send the ASAP_REGISTRATION message to the Home ENRP server using
SCTP.
R3) 発信、_できるだけ早く、REGISTRATIONは、SCTPを使用することでホームENRPサーバへ通信します。
R4) Start a T2-registration timer.
R4) T2-登録タイマを始動してください。
Note: the PE does not need to fill in the optional ASAP transport parameter. The ASAP transport parameter will be filled in and used by the Home ENRP server.
以下に注意してください。 PEはできるだけ早く任意に輸送パラメタをいっぱいにする必要はありません。 できるだけ早く、輸送パラメタは、ホームENRPサーバによって記入されて、使用されるでしょう。
If the T2-registration timer expires before receiving an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the PE shall start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server, the PE SHOULD restart the registration procedure.
SCTP層からSEND.FAILURE通知を受け取ります、そして、PEは_できるだけ早く、REGISTRATION_RESPONSEが通信するか、または異なったENRPサーバからサービスを得る試みでServer Hunt手順を始めるものとします(セクション3.6を見ます)。T2-登録タイマが受信する前に期限が切れる、新しいホームENRPサーバを確立した後に、PE SHOULDは登録手順を再開します。
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 MUSTはT2-登録タイマを止めます。 応答が成功を示すと、PEは登録されていて、サーバプールの手があいている部材であると考えられるでしょう。 登録応答が失敗を示すなら、PEはエラーを修正した後に、登録を再試みなければならないか、またはPEの上側の層に失敗指示を返さなければなりません。 エラー条件を修正しないで、PE MUST NOTは登録を再試みます。
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 MAYはメンバー選択Policy Valueをアップデートする再レジスタか登録満了時間まで願っています。 再登録するとき、PE MUSTは同じ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 MUSTはT4-reregistrationタイマを始動します。 満了、再登録SHOULD、T4再登録タイマを再開するのを含む(完成で)ステップR1で始まって、作られてください。
Stewart, et al. Experimental [Page 19] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[19ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
SHOULDがそれが局所変数でそれをする登録(そして、再登録)試みの数に関する記録であることを保つ実装がホームENRPサーバへの新規登録試みの前かうまくいっている再登録の後にゼロに用意することに注意してください。 繰り返された登録タイムアウトか失敗が起こって、地方のカウントがThreshold'マックスレッジATTEMPT'を超えているなら、実装SHOULDは、上側の層に誤りを報告して、登録を試みるのを止めます。
The ENRP server handles the ASAP_REGISTRATION message according to the following rules:
ENRPサーバが扱う、_できるだけ早く、以下に従ったREGISTRATIONメッセージは統治されます:
1. If the named pool does not exist in the handlespace, the ENRP
server MUST create a new pool with that handle in the handlespace
and add the PE to the pool as its first PE.
1. 命名されたプールがhandlespaceに存在していないなら、ENRPサーバは、handlespaceでそのハンドルで新しいプールを作成して、最初のPEとしてプールにPEを加えなければなりません。
When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first
PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the
registering PE.
新しいプールが作成されるとき、最初のPEによって示された方針タイプにプールの総合的なメンバー選択方針を設定しなければなりません、そして、総合的なプール輸送タイプはPEによって示された輸送タイプに用意ができなければなりません、そして、User TransportパラメタのTransport Use分野で登録しているPEによって示されることに総合的なプールデータ/コントロールチャネル構成を設定しなければなりません。
2. If the named pool already exists in the handlespace, but the
requesting PE is not currently a member of the pool, the ENRP
server will add the PE as a new member to the pool.
2. 命名されたプールがhandlespaceに既に存在していますが、現在要求しているPEがプールの部材でないなら、ENRPサーバは新しいメンバーとしてプールにPEを加えるでしょう。
However, before adding the PE to the pool, the server MUST check
if the policy type, transport type, and transport usage indicated
by the registering PE is consistent with those of the pool. If
different, the ENRP server MUST reject the registration.
しかしながら、プールに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. *命名されたプールがhandlespace*に既に存在していて、要求しているPEが既にプールの部材であるなら、ENRPサーバSHOULDは、これが再登録そうであるとみなします。 ENRPサーバは上で説明されるように方針の同じテスト、輸送タイプ、および輸送使用を実行しなければなりません。 再登録を受け入れるなら、テスト、ENRPサーバのときに、SHOULDが置き換える後、情報がある既存のPEの属性はできるだけ早く受け取られているところで_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
4. 登録を受け入れた後に、ENRPサーバはこのPEの所有者をそれ自体に選任しなければなりません。 これが再登録であるなら、ENRPサーバはこのPEの所有権を引き継がなければなりません、PEが以前にこのサーバか別のものによって所有されていたかどうかにかかわらず
Stewart, et al. Experimental [Page 20] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[20ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
また、サーバENRPサーバがそれが受信されたSCTP輸送アドレスを記録しなければならない、できるだけ早さ、_中のREGISTRATION、できるだけ早さ、このPEのPEパラメタにおけるTransportパラメタTLV。
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サーバが要求しているPEに答えなければならない、_できるだけ早く、REGISTRATION_RESPONSEは通信します。 登録を受け入れるなら、ENRPサーバが中にR旗を設定しなければならない、できるだけ早さ、_'0'へのREGISTRATION_RESPONSE。 登録が拒絶されるなら、ENRPサーバが中にR旗を設定することによって拒絶を示さなければならない、できるだけ早さ、_'1'へのREGISTRATION_RESPONSE。
If the registration is rejected, the ENRP server SHOULD include the proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message.
登録が拒絶されるなら、ENRPサーバSHOULDが中に適切な誤り原因を含んでいる、_できるだけ早く、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のホームENRPサーバであり、すなわち、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リストかテーブルを維持するのが効率的であって、かつ便利であることがわかるかもしれません--1つはENRPサーバによって所有されているPEsのためのものです、そして、もう片方が彼らの同輩によって所有されていたすべてのPEsのためのものです。
Moreover, if the registration is granted, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. If the registration is denied, no message will be sent to its peers.
そのうえ、登録が承諾されるなら、ENRPサーバは、ただ行われた変更に関して同輩に知らせるためにhandlespaceアップデート行動を取らなければなりません。 登録を否定すると、メッセージを全く同輩に送らないでしょう。
3.2. De-Registration
3.2. 反-登録
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を見てください)、それ。SHOULDは以下の手順を用います。 反-登録の代替方法が再登録しないで、PEの登録の寿命が期限が切れるのを許容することであることに注意されるべきです。 _できるだけ早く、できるだけ早く、DEREGISTRATION_RESPONSEメッセージをPEのものに送ります。この場合、それが登録したプールからPEの解任を示すEndpoint。
When de-registering, the PE SHOULD use the SCTP association that was used for registration with its Home ENRP server. To de-register, the PE's ASAP Endpoint MUST take the following actions:
反-登録するとき、PE SHOULDがホームENRPサーバによる登録に使用されたSCTP協会を使用する、反-レジスタ、PEのもの、できるだけ早く、Endpointは以下の行動を取らなければなりません:
Stewart, et al. Experimental [Page 21] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[21ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION
message (Section 2.2.2) using the same Pool Handle parameter sent
during registration.
D1) Pool Handleパラメタでいっぱいになる、_できるだけ早く、同じPool Handleパラメタを使用する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) PE Identifierパラメタでいっぱいになる、_できるだけ早く、DEREGISTRATIONは通信します。 識別子は登録の間、使用されるのと同じであるに違いありません。 反-登録が起こることができる前に登録に使用される同じPool HandleとPool Identifierパラメタの使用は、PE ASAP Endpointのアイデンティティが確かめられるのを許容します。
D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server
using the PE's SCTP association.
D3) 発信、_できるだけ早く、DEREGISTRATIONは、PEのSCTP協会を使用することでホームENRPサーバへ通信します。
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タイマが受信する前に期限が切れる、できるだけ早さ、_REGISTRATION_RESPONSEメッセージ、またはPEのSCTP終点、PEのものからのできるだけ早くEndpointがaを設立した後に新しい別のENRPサーバからのサービスにホームENRPサーバを得る試みでENRP Server Hunt手順を始めるものとするという(セクション3.6を見ます)SEND.FAILURE通知、できるだけ早く、Endpoint SHOULDは反-登録手順を再開します。
At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP endpoint MUST stop the T3-Deregistration timer.
レセプション、できるだけ早さ、_DEREGISTRATION_RESPONSE、PEのもの、できるだけ早く、終点は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 MAYがまだいつかの期間を求める要求を受け取っていることに注意されるべきです。 PE MAYはアクティブなままで残って、これらの要求を修理したいか、出て、またはこれらの要求を無視したがっています。
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サーバSHALLはhandlespaceからPEを取り外します。 そのうえ、PEが命名されたプールの最後のひとりであるなら、ENRPサーバはまた、handlespaceからプールを取り外すでしょう。
If the ENRP server fails to find any record of the PE in its handlespace, it SHOULD consider the de-registration granted and completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the PE.
サーバはENRPであるならhandlespaceでPEに関するどんな記録も見つけないで、それは反-登録当然のことを考えて、完成したSHOULDです、そして、発信してください、_できるだけ早く、DEREGISTRATION_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サーバが発信しなければならない、_できるだけ早く、DEREGISTRATION_RESPONSEはPEへ通信します。 反-登録が拒絶されるなら、ENRPサーバは、適切なOperational Errorパラメタを含んでいることによって、拒絶を示さなければなりません。
Stewart, et al. Experimental [Page 22] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[22ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
It should be noted that de-registration does not stop the PE from sending or receiving application messages.
反-登録が、PEがアプリケーションメッセージを送るか、または受け取るのを止めないことに注意されるべきです。
Once the de-registration request is granted *and* the PE removed from its local copy of the handlespace, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. Otherwise, the ENRP server MUST NOT inform its peers.
*いったん反-登録要求に*を与えて、PEがhandlespaceの地方のコピーから取り外すと、ENRPサーバは、ただ行われた変更に関して同輩に知らせるためにhandlespaceアップデート行動を取らなければなりません。 さもなければ、ENRPサーバは同輩に知らせてはいけません。
3.3. Handle Resolution
3.3. 解決を扱ってください。
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がハンドルを決議したがっているかもしれません。 通常、これが起こる、いつ、できるだけ早さ、Endpoint、ホームENRPサーバへの(セクション6.5.1)をPool Handleに送るか、またはキャッシュ人口(セクション6.3)を要求に送るか。 また、それは他の理由で起こるかもしれません(例えば、内部のASAP PEは、同輩が彼らのすべてにメッセージを送るのを知りたがっています)。 いつ、できるだけ早く、Endpoint(PEかPU)はプールのメンバーPEsの理解できる輸送アドレスのリストにプールハンドルを決議したがっていて、以下の行動を取らなければなりません:
NR1) Fill in an ASAP_HANDLE_RESOLUTION message (Section 2.2.5) with
the Pool Handle to be resolved.
NR1) 記入、_できるだけ早く、HANDLE_RESOLUTIONは、決議されるためにPool Handleと共に(セクション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サーバがないなら、1つを得るためにセクション3.6で指定されたENRP Server Hunt手順を始めてください。 さもなければ、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であるなら、発信してください、_できるだけ早く、HANDLE_RESOLUTIONはSCTPを使用することでホームENRPサーバへ通信します。 PUであるなら、発信してください、_できるだけ早く、HANDLE_RESOLUTIONは、TCPかSCTPのどちらかを使用することでホームENRPサーバへ通信します。 送るなら、PE、登録SHOULDに使用される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タイマが期限が切れるなら採る、できるだけ早く、Endpoint SHOULDはセクション3.7で.2に説明された方法を採ります。 SCTPかTCPからSEND.FAILURE通知を受け取るなら層にしてください、できるだけ早くEndpoint SHOULDがa異なったENRPサーバ後設立からのサービスに新しいホームENRPサーバを得る試みでServer Hunt手順を始める、(セクション3.6を見ます)できるだけ早く、Endpoint SHOULDはハンドル解決手順を再開します。
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).
レセプション、_できるだけ早く、HANDLE_RESOLUTION_RESPONSEが通信する、できるだけ早く、EndpointはT1-ENRPrequestタイマを止めなければなりません。 T1-ENRPrequestタイマを止めた後にできるだけ早くEndpoint SHOULDが適宜メッセージを処理する、(例えば、ローカルなキャッシュに居住して、応答を与える、できるだけ早さ、User、発信するのに応答を使用してください、できるだけ早くUserのものが通信する、)
Stewart, et al. Experimental [Page 23] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[23ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Note that some ASAP Endpoints MAY use a cache to minimize the number of handle resolutions sent. If a cache is used, it SHOULD:
できるだけ早く、それにいくつか注意してください。Endpointsは、送られたハンドル解決の数を最小にするのにキャッシュを使用してもよいです。 aであるなら、キャッシュは使用されていて、それはSHOULDです:
C1) Be consulted before sending a handle resolution.
C1) ハンドル解決を送る前に、相談されてください。
C2) Have a stale timeout timer associated with each cache entry. If
the cache entry is determined to be stale upon a cache hit, a
handle resolution message SHOULD be sent so the cache can be
updated.
C2) それぞれのキャッシュエントリーに関連している聞き古したタイムアウトタイマを持ってください。 キャッシュエントリーがキャッシュで聞き古したであることが当たって、ハンドル解決メッセージがSHOULDであると決心しているなら、キャッシュをアップデートできるには、送ってください。
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) キャッシュエントリーが聞き古したでない、終点SHOULD NOTはハンドル解決要求を送りますが、代わりに、SHOULDはキャッシュからエントリーを使用します。
It should be noted that the impact of using a cache depends on the policy and the requirements of the application. For some applications, cache-usage can increase the performance of the system; for some, it can decrease it.
キャッシュを使用する影響がアプリケーションの方針と要件によることに注意されるべきです。 いくつかのアプリケーションのために、キャッシュ用法はシステムの性能を増強できます。 いくつかに関しては、それはそれを減少させることができます。
An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION requests from PUs, either over an SCTP association on the well-known SCTP port, or over a TCP connection on the well-known TCP port.
ENRPサーバSHOULD、できるだけ早くよく知られるSCTPポートの上、または、よく知られるTCPポートにおけるTCP接続の上にPUsから_HANDLE_RESOLUTION要求をSCTP協会の上のどちらかに受け取るように用意してください。
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.
レセプション、_できるだけ早く、HANDLE_RESOLUTIONメッセージ、ENRPサーバは最初に、handlespaceでプールハンドルを見上げなければなりません。 プールが存在しているなら、ホームENRPサーバが構成して、発信して戻らなければならない、_できるだけ早く、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サーバSHOULDは現在このプールの中に登録されているすべてのPEsを記載します、PEパラメタのリストで。 また、ENRPサーバは総合的なメンバー選択方針をプールに示すためにプールメンバー選択方針パラメタを含まなければなりません、現在のプールメンバー選択方針がRound-ロビンでないなら。
If the named pool does not exist in the handlespace, the ENRP server MUST reject the handle resolution request by responding with an ASAP_HANDLE_RESOLUTION_RESPONSE message carrying an Unknown Pool Handle error.
命名されたプールがhandlespaceに存在していないなら、ENRPサーバが応じることによってハンドル解決要求を拒絶しなければならない、_できるだけ早く、HANDLE_RESOLUTION_RESPONSEは、Unknown Pool Handle誤りを運びながら、通信します。
Stewart, et al. Experimental [Page 24] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[24ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
3.4. Endpoint Keep Alive
3.4. 終点は生きているままです。
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.
_できるだけ早く、_ALIVEメッセージがそれについて確かめるためにPEへのENRPサーバによって送られるENDPOINT_KEEPは届いています。 鼓動メカニズムが輸送レベルであるなら不十分である、鼓動メカニズムでこのメッセージを使用できる、できるだけ早く平らにする、だれの目標が健康状態を決定するのがあるか、できるだけ早く、直ちに平らにします。 (輸送レベル鼓動メカニズムがあまりに長い間設定されるタイムアウトか鼓動間隔のどちらかのために不十分であるかもしれませんか、または輸送が鼓動メカニズムの適用範囲を平らにするのは2つの終わりの輸送レベルだけに制限されます。) さらに、_できるだけ早く、ENDPOINT_KEEP_ALIVEメッセージには、カーネルにSCTPスタックがあるなら、欠点検出の信頼性における値があります。 SCTP-レベル鼓動が2つのSCTPスタック、できるだけ早く平らの間の終わりから終わりへの鼓動が終わりから終わりへの活気をモニターする接続性をモニターする間のそのような場合、できるだけ早く層にしてください、それの上で。
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:
そして、使用、_できるだけ早く、ENDPOINT_KEEP_ALIVEが(セクション2.2.7)を通信させる、_できるだけ早く、ENDPOINT_KEEP_ALIVE_ACK(セクション2.2.8)は以下で説明されます。 レセプション、_できるだけ早く、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) Pool Handleが正しく、Pool Handleに合っているのがそれが、より初期であることを送りました。PEが確かめなければならない、_できるだけ早く、REGISTRATIONは通信します。 Pool Handleが合っていないなら、PE MUSTは静かにメッセージを捨てます。
KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as
follows:
KA2) 発信、できるだけ早さ、_以下のENDPOINT_KEEP_ALIVE_ACK(セクション2.2.8):
KA2.1) Fill in the Pool Handle parameter with the PE's Pool
Handle.
KA2.1) PEのPool Handleと共にPool Handleパラメタに記入してください。
KA2.2) Fill in the PE Identifier parameter using the PE
identifier used by this PE for registration.
KA2.2) 登録にこのPEによって使用されたPE識別子を使用して、PE Identifierパラメタに記入してください。
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) 発信、_できるだけ早く、ENDPOINT_KEEP_ALIVE_ACKが発信したENRPサーバのための適切なSCTP協会を通して通信する、_できるだけ早く、ENDPOINT_KEEP_ALIVEは通信します。
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) _ENDPOINT_KEEP_ALIVEメッセージができるだけ早く受け取られているところのH旗であるなら設定していて、メッセージのServer IdentifierがあなたのホームENRPサーバのアイデンティティでない、(それが設定されないで、また例えば、あなたがホームENRPを全く持っていない、サーバ)、送付者を採用する、_できるだけ早く、ENDPOINT_KEEP_ALIVEは新しいホームENRPサーバとして通信します。
Stewart, et al. Experimental [Page 25] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[25ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
3.5. Unreachable Endpoints
3.5. 手の届かない終点
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.
時折、できるだけ早く、Endpointは、PEが手が届かないとわかるかもしれません。 を通してまたは、これが実現された特定のSCTP誤りで起こるかもしれない、できるだけ早さ、終点、できるだけ早く、UserはTransport.Failure Primitive(セクション6.9.2)を通して報告します。 どちらかの場合でできるだけ早くEndpoint SHOULDが発信することによってPEの使用不能を報告する、_できるだけ早く、ENDPOINT_UNREACHABLEがどんなENRPサーバへも通信する、発信する前、_できるだけ早く、ENDPOINT_UNREACHABLEが通信する、できるだけ早さ、Endpoint、中にPool Handleパラメタと手の届かない終点のPE Identifierパラメタをいっぱいにするべきです。 送付者がPEであるなら、SCTPを通してメッセージを送らなければなりません。 それが注意されるべきである、それ、できるだけ早く、Endpointはかつてのそれがそのようなイベントに遭遇する各回だけに報告しなければなりません。 さらに、Transport.Failure Primitive(セクション6.9.2)を処理するときできるだけ早くEndpointが発信してはいけない、_できるだけ早く、ユーザがデータをPEに送るという前の要求をしていない場合、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.
レセプション、_できるだけ早く、ENDPOINT_UNREACHABLEが通信して、ENRPサーバができるだけ早くすぐに_KEEP_ALIVEが問題のPEへ通信させるENDPOINT_をポイントツーポイントに送らなければならない、(H旗、メッセージSHOULDに'0'に設定されてください、この場合) _できるだけ早く、ENDPOINT_KEEP_ALIVEがこれであるなら失敗して(例えば、それはSCTP SEND.FAILURE通知をもたらします)、ENRPサーバは、本当に、PEが手が届かないとみなさなければならなくて、handlespaceからPEを取り外さなければなりません。
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.
_できるだけ早く、ALIVEが通信させるENDPOINT_KEEP_は首尾よくPEに伝えられて、ENRPサーバはhandlespaceでPEを保有しなければなりません。 そのうえ、サーバSHOULDは、できるだけ早くいくつ記録するかためにカウンタを保ちます。_それが持っているENDPOINT_UNREACHABLEメッセージは、このPEに関連することにおける可到達性問題を報告しながら、受信されました。 カウンタがプロトコル敷居マックス-BAD-PE-REPORTを超えているなら、ENRPサーバSHOULDはhandlespaceからPEを取り外します。
Optionally, an ENRP server may also periodically send point-to-point ASAP_ENDPOINT_KEEP_ALIVE (with the H flag set to '0') messages to each of the PEs owned by the ENRP server in order to check their reachability status. If the sending of ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the PE as unreachable and MUST remove the PE from its handlespace. Note, if an ENRP server owns a large number of PEs, the implementation should pay attention not to flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This can be achieved by varying the time between two ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/ minus 50 percent.
また、任意に、ENRPサーバはできるだけ早く、定期的に_彼らの可到達性状態をチェックするためにENRPサーバによって所有されていたそれぞれのPEsへのENDPOINT_KEEP_ALIVE('0'に設定されたH旗がある)メッセージをポイントツーポイントに送るかもしれません。 発信、できるだけ早さでは、_ENDPOINT_KEEP_ALIVEがPEに失敗して、ENRPサーバは、PEが手が届かないとみなさなければならなくて、handlespaceからPEを取り外さなければなりません。 注意、ENRPサーバが多くのPEsを所有しているなら、実装は注意ができるだけ早さの炸裂に伴うネットワークをあふれさせないのを支払うべきです。_ENDPOINT_KEEP_ALIVEメッセージ。 代わりに、実装が分配しなければならない、_できるだけ早く、ENDPOINT_KEEP_ALIVEは期間、トラフィックを通信させます。 できるだけ早く2の間で時間を_ALIVEが同じPEへ手当たりしだいに通信させるENDPOINT_KEEP_と/マイナスしている50パーセント変えることによって、これを達成できます。
Stewart, et al. Experimental [Page 26] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[26ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
3.6. ENRP Server Hunt Procedures
3.6. ENRPサーバ狩り手順
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-Serverannounceを送らなければならない、_できるだけ早く、SERVER_ANNOUNCEは(セクション2.2.10)を通信させます(マルチキャストENRPクライアントに関するコミュニケーション(Nはできるだけ早く_SERVER_ANNOUNCEメッセージを受け取ることを通してサーバが見つけたENRPサーバの数である)ができるだけ早く精神を集中するので、利用可能なすべての輸送アドレスを含んでいます)。 これはできるだけ早く、_1T6-ServerannounceあたりのSERVER_ANNOUNCEにおよそ1のメッセージレートをもたらすべきです。
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.
できるだけ早く_SERVER_ANNOUNCEメッセージがPUかPEによって受け取られて、それがすべての新しい含まれている輸送がENRPサーバアドレスのリストの中に扱うSHOULD差し込みであり、始めは各アドレスのためのT7-ENRPoutdateタイマです。 すべての既知の、そして、含まれている輸送アドレスにおいて、各アドレスのためにT7-ENRPoutdateタイマを再開しなければなりません。 _できるだけ早く、SERVER_ANNOUNCEは通信します、そして、SCTPトランスポート・プロトコルが使用されると思われて、ソースIPアドレスとできるだけ早くIANAによって登録されたポートナンバーはENRPサーバとのコミュニケーションに使用されます。パラメタが含まれている輸送でない、輸送アドレスのためのT7-ENRPoutdateタイマが期限が切れるなら、対応するアドレスはPUかPEの輸送アドレスの管理されたリストから削除されます。
If multicast capabilities are not used within the operational scope, each PU and PE MUST have a configured list of transport addresses of ENRP servers.
マルチキャスト能力が操作上の範囲の中で使用されないなら、各PUとPE MUSTには、ENRPサーバの輸送アドレスの構成されたリストがあります。
At its startup, or when it fails to communicate with its Home ENRP server (i.e., timed out on an ENRP request), a PE or PU MUST establish a new Home ENRP server (i.e., set up a TCP connection or SCTP association with a different ENRP server).
始動、それがいつホームENRPサーバ(すなわち、ENRP要求の外では、調節されている)とコミュニケートしないか、そして、PEまたはPU MUSTでは、新しいホームENRPサーバを確立してください(すなわち、異なったENRPサーバとのTCP関係かSCTP協会を設立してください)。
To establish a Home ENRP server, the following rules MUST be followed:
ホームENRPサーバを証明するために、以下の規則に従わなければなりません:
SH1) The PE or PU SHOULD try to establish an association or
connection, with no more than three ENRP servers. An ASAP
Endpoint MUST NOT establish more than three associations or
connections.
SH1) PEかPU SHOULDが3つ未満のENRPサーバとの協会か関係を確立しようとします。 できるだけ早く、Endpointは3つ以上の協会か接続を確立してはいけません。
SH2) The ASAP Endpoint shall start a T5-Serverhunt timer.
SH2) できるだけ早く、EndpointはT5-Serverhuntタイマを始動するものとします。
Stewart, et al. Experimental [Page 27] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[27ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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) できるだけ早く、Endpointは協会か接続を確立します。それはT5-Serverhuntタイマを止めなければなりません。 できるだけ早く、Endpoint SHOULDはまた、初期の値に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) 協会かコネクション確立が行き詰まるならできるだけ早さ、Endpoint SHOULD、異なった輸送アドレスを使用することで協会か接続を確立するようにしてください。
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) できるだけ早く、EndpointはT5Serverhuntタイマの値を倍にしなければなりません。 この倍増が値の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) できるだけ早く、Endpoint SHOULDはステップ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) できるだけ早く、Endpoint SHOULDは、SH1を踏みかけることによって、協会か接続を確立するトライを繰り返します。 それ、SHOULDは、接続する異なった輸送アドレスを選択するのを試みます。
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サーバにすべてのその後のENRP要求メッセージを送るものとします。
3.7. Handling ASAP Endpoint to ENRP Server Communication Failures
3.7. できるだけ早く、ENRPサーバ通信障害に終点を扱います。
Three types of failure may occur when the ASAP Endpoint at either the PE or PU tries to communicate with an ENRP server:
3つのタイプの失敗が起こるかもしれない、いつ、できるだけ早さ、Endpoint、どちらかでは、PEかPUがENRPサーバとコミュニケートしようとします:
A) SCTP send failure
a) SCTPは失敗を送ります。
B) T1-ENRPrequest timer expiration
B) T1-ENRPrequestタイマ満了
C) Registration failure
C) 登録失敗
3.7.1. SCTP Send Failure
3.7.1. SCTPは失敗を送ります。
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サーバは手が届きません。
Stewart, et al. Experimental [Page 28] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[28ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
そのような場合で再送する、できるだけ早く、Endpointは「非-提出物」メッセージを再送してはいけません。 代わりにそれ、SHOULDはセクション3.6で説明されるようにメッセージを捨てて、ENRP Server Hunt手順を始めます。 新しいホームENRPサーバを見つけた後に再送する、できるだけ早く、Endpointは要求を再送するはずです。
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.
それに注意してください、また、できるだけ早く、Endpointは、メッセージを捨てないのを選ぶかもしれませんが、新しいホームENRPサーバの後に「再-トランスミッション」のためにそれを列に並ばせるのは見つけられます。 できるだけ早さ、Endpoint、新しいホームENRPサーバが見つけられた後にメッセージを捨てるのを選ぶ、できるだけ早く、Endpointはオリジナルの要求を再建できなければなりません。
3.7.2. T1-ENRPrequest Timer Expiration
3.7.2. T1-ENRPrequestタイマ満了
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タイマが期限が切れるとできるだけ早さ、Endpoint、オリジナルの要求をENRPサーバに再送って、T1ENRPrequestタイマを再開するべきです。 平行である、できるだけ早く、Endpointはセクション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.
これはマックス-REQUEST-RETRANSMIT回まで繰り返されるべきです。 その後にError.Report通知が知らせるために生成されるべきである、できるだけ早さ、User、そして、T1ENRPrequestタイマに関連しているメッセージが捨てられるべきであるというENRP要求。 それが代替のENRPサーバであるなら応じることに注意されるべきである、できるだけ早さ、Endpoint SHOULD、新しいホームENRPサーバとして応じているENRPサーバを採用してください、そして、新しいホームENRPサーバに要求を再送してください。
3.7.3. Registration Failure
3.7.3. 登録失敗
Registration failure is discussed in Section 3.1.
セクション3.1で登録失敗について議論します。
3.8. Cookie Handling Procedures
3.8. クッキー処理手順
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が欲しく、制御チャンネルが存在しているときはいつも、発信できる、_できるだけ早く、COOKIEは制御チャンネルでPUへ通信します。 PUのもの、できるだけ早く、それが以前に保存されるなら、終点は、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の間のユーザに渡されたデータを運ばない通信チャネルです。 これがSCTPと共に分離するのにPPIDを使用することによって達成される、できるだけ早く、正常なデータメッセージから(クッキーとBusiness Card)を通信させます。
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.
EndpointがPUのものであるならできるだけ早く異なったPEに失敗を検出して、フェイルオーバーを開始して、それがSHOULDである、最新の受信されたクッキーパラメタを送ってください、_できるだけ早く、COOKIE_ECHOは制御チャンネルに関する最初のメッセージとして新しいPEへ通信します。 上側の層はフェイルオーバー手順にかかわるかもしれません。
Stewart, et al. Experimental [Page 29] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[29ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
州の共有にクッキー処理手順を用いることができます。 したがって、クッキーによって発信しているPE ASAP Endpointであると署名されるべきです、そして、クッキーはできるだけ早く、受信PEのものによって確かめられるはずです。Endpoint。 このドキュメントのための範囲の外に検証手続の詳細があります。 PUがいつも最後の受信されたCookieパラメタを保存して、PEの故障の場合に変更されていなくそれを返送するのが、重要であるだけです。
3.9. Business Card Handling Procedures
3.9. 名刺取り扱い手順
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の間で始まると(すなわち、メッセージを実体の間に送ります)、PEがいつも発信するはずである、_できるだけ早く、BUSINESS_CARDはPUへ通信します。それのどちらかがPU/PE組み合わせのPEのための一部であるかもしれません。 PUが発信するはずである、_できるだけ早く、それである場合にだけ、PEへのBUSINESS_CARDメッセージはPU/PE組み合わせの一部です。 _できるだけ早く、制御チャンネルがPUとPEの間に存在しているなら、BUSINESS_CARDメッセージを送るだけでよいです。 コミュニケーションを確立した後に、できるだけ早く新しいPEとPU、aの間に、いつでも、どちらの実体でも、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.
_できるだけ早く、BUSINESS_CARDメッセージは2つの目的に役立ちます。 まず最初に、それはプールハンドルを記載します。 PEに連絡しているPU/PE組み合わせの一部であるPUに関しては、これが不可欠であるので、PEはサービスを要求するPU/PE組み合わせのプールハンドルを学びます。 第二に、_できるだけ早く、BUSINESS_CARDメッセージは、続くようにお勧めであることの受信実体aフェイルオーバー命令に言います。 これはまた、一緒に、そして、どんなPEの失敗でも荷重再配分を制御するほど働いている実体の間のランデブーを容易にするべきです。
Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13), the receiving ASAP Endpoint SHOULD:
を受け取り次第、できるだけ早さ、BUSINESS_CARDが通信させる(セクション2.2.13を見ます)_、できるだけ早く受信、Endpoint SHOULD:
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) メッセージをアンパックしてください。そうすれば、エントリーが全くできるだけ早く受信の翻訳キャッシュで存在しないならプールハンドルのためのEndpointが中に記載した、_できるだけ早く、BUSINESS_CARDが通信して、働いてください、_できるだけ早く、それのための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が失敗すると、この都合のよいリストが誘導するのにおいて使用する、できるだけ早さ、Endpoint、代替のPEの選択で。
Stewart, et al. Experimental [Page 30] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[30ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
4. Roles of Endpoints
4. 終点の役割
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.
_A PU MUSTは_HANDLE_RESOLUTIONをできるだけ早さの取り扱いに実装します、そして、できるだけ早く、HANDLE_RESOLUTION_RESPONSEは通信します。 その上、それは_ERRORメッセージをできるだけ早さの取り扱いにサポートしなければなりません。 それができるだけ早くできるだけ早さの取り扱いに_COOKIEを実装するかもしれない、_COOKIE_ECHO、_できるだけ早く、BUSINESS_CARDは通信します。 また、それは_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.
A PE MUSTができるだけ早くできるだけ早さの取り扱いに_REGISTRATIONを実装する、_DEREGISTRATION、できるだけ早さ、_REGISTRATION_RESPONSE、_できるだけ早く、DEREGISTRATION_RESPONSEは通信します。 その上、できるだけ早く_ENDPOINT_KEEP_ALIVEをできるだけ早さの取り扱いにサポートしなければならない、_ENDPOINT_KEEP_ALIVE_ACK、できるだけ早さ、_ENDPOINT_UNREACHABLE、_できるだけ早く、ERRORは通信します。 それ、SHOULDができるだけ早くできるだけ早さの取り扱いに_COOKIEをサポートする、_COOKIE_ECHO、_できるだけ早く、BUSINESS_CARDは通信します。 その上、それは_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サーバができるだけ早くできるだけ早さの取り扱いに_REGISTRATIONを実装しなければならない、_DEREGISTRATION、できるだけ早さ、_REGISTRATION_RESPONSE、_できるだけ早く、DEREGISTRATION_RESPONSEは通信します。 その上、できるだけ早く_ENDPOINT_KEEP_ALIVEをできるだけ早さの取り扱いにサポートしなければならない、_ENDPOINT_KEEP_ALIVE_ACK、できるだけ早さ、_ENDPOINT_UNREACHABLE、_できるだけ早く、ERRORは通信します。 その上、それは_SERVER_ANNOUNCEメッセージをできるだけ早さの取り扱いにサポートするかもしれません。
If a node acts as a PU and a PE, it MUST fulfill both roles.
ノードがPUとPEとして機能するなら、それは両方の役割を実現させなければなりません。
5. SCTP Considerations
5. SCTP問題
Each ASAP message is considered as an SCTP user message. The PPID registered for ASAP SHOULD be used. The SCTP port used at the ENRP server might be preconfigured or announced in the ASAP_SERVER_ANNOUNCE message or the well-known ASAP port.
それぞれ、できるだけ早く、メッセージはSCTPユーザメッセージであるとみなされます。 PPIDはASAP SHOULDに登録しました。使用されます。 ENRPサーバで中古のSCTPポートがあらかじめ設定されるか、または発表されるかもしれない、できるだけ早さ、SERVER_ANNOUNCEが通信するか、またはよく知られるのができるだけ早く移植する_。
ASAP messages belonging to the control channel MUST be sent using the PPID registered for ASAP. Messages belonging to the data channel MUST NOT use the PPID registered for ASAP.
できるだけ早く、制御チャンネルのものであるメッセージにできるだけ早く登録されたPPIDを使用させなければなりません。 データ・チャンネルのものであるメッセージはできるだけ早く登録されたPPIDを使用してはいけません。
6. The ASAP Interfaces
6. できるだけ早く、連結します。
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).
そして、本章が主として間にインタフェースを形成する基関数と通知に焦点を合わせる、できるだけ早さ、User、できるだけ早さ、できるだけ早さであることの間のそれとその下層輸送は(例えば、SCTP)について議定書の中で述べます。
Stewart, et al. Experimental [Page 31] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[31ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Note, the following primitive and notification descriptions are shown for illustrative purposes. We believe that including these descriptions in this document is important to the understanding of the operation of many aspects of ASAP; but an ASAP implementation is not required to use the exact syntax described in this section.
注意、以下の原始と通知記述は説明に役立った目的のために示されます。 私たちは、これらの記述を含んでいるのが本書ではできるだけ早さの多くの局面の操作の理解に重要であると信じています。 しかし、できるだけ早く、実装は、このセクションで説明された正確な構文を使用するのに必要ではありません。
An ASAP User passes primitives to the ASAP sub-layer to request certain actions. Upon the completion of those actions or upon the detection of certain events, the ASAP layer will notify the ASAP User.
できるだけ早さ、Userが基関数を通過する、できるだけ早さ、ある動作を要求する副層。 それらの動作の完成かあるイベントの検出に関してできるだけ早く層に通知する、できるだけ早さ、User
6.1. Registration.Request Primitive
6.1. Registration.Request Primitive
Format: registration.request(Pool Handle,
User Transport parameter(s))
形式: registration.request(Handle、User Transportパラメタ(s))をプールしてください。
The Pool Handle parameter contains a NULL terminated ASCII string of fixed length. The optional User Transport parameter(s) indicates specific transport parameters and types with which to register. If this optional parameter is left off, then the SCTP endpoint used to communicate with the ENRP server is used as the default User Transport parameter. Note that any IP address contained within a User Transport parameter MUST be a bound IP address in the SCTP endpoint used to communicate with the ENRP server.
終えられて、Pool HandleパラメタはNULLを含んでいます。固定長のASCIIストリング。 任意のUser Transportパラメタは特定の輸送パラメタと登録するタイプを示します。 この任意のパラメタがやめられるなら、ENRPサーバとコミュニケートするのに使用されるSCTP終点はデフォルトUser Transportパラメタとして使用されます。 User Transportパラメタの中に含まれたどんな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).
できるだけ早さ、User、handlespaceにそれ自体を加えるために原始的にこれを呼び出して、その結果、プールのPool Elementになります。 セクション6.5.1と6.5を見てください。できるだけ早くUserがhandlespaceを使用するUsersができるだけ早くできるだけ早くメッセージをこれに別に送ることができる前に原始的にこれを使用することによってENRPサーバにそれ自体を登録しなければならない、Pool HandleかPEハンドルによるUser、(.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.
登録に対応して原始的である、できるだけ早くEndpointが発信する、_REGISTRATIONはできるだけ早く、ホームENRPサーバ(セクション2.2 .1と3.1を見る)へ通信して、T2-登録タイマを始動します。
6.2. Deregistration.Request Primitive
6.2. Deregistration.Request Primitive
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はServer Poolから立ち退くために原始的にこれを呼び出します。 これは優雅な閉鎖プロセスの一部としてアプリケーションで使用されるべきです。
An ASAP_DEREGISTRATION message will be sent by the ASAP Endpoint to the Home ENRP server (see Sections 2.2.2 and 3.2).
_できるだけ早く、DEREGISTRATIONメッセージによって発信される、できるだけ早さ、Endpoint、ホームENRPサーバ(セクション2.2 .2と3.2を見る)に。
Stewart, et al. Experimental [Page 32] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[32ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
6.3. CachePopulateRequest Primitive
6.3. CachePopulateRequest原始的です。
Format: cache_populate_request([Pool-Handle |
Pool-Element-Handle])
形式: キャッシュ_は_要求に居住します。[要素ハンドルをプールしていた状態で|プールで扱ってください)
If the address type is a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should initiate a mapping information query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle and updating its local cache when the response comes back from the ENRP server.
翻訳キャッシュがアドレスタイプがPool Handleと地方のハンドルであるなら存在している、できるだけ早さ、Endpoint、発信することによってマッピング情報質問を開始するべきである、_できるだけ早く、応答であるときにPoolハンドルとローカルなキャッシュをアップデートすることに関する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.
そして、Pool要素ハンドルが渡されるならPool HandleがPool要素ハンドルからアンパックされる、_できるだけ早く、HANDLE_RESOLUTIONメッセージを解決のためのENRPサーバに送ります。 応答メッセージがENRPサーバから戻るとき、ローカルなキャッシュをアップデートします。
Note that if the ASAP service does NOT support a local cache, this primitive performs NO action.
それに注意してください、できるだけ早く、サービスはローカルなキャッシュをサポートしないで、またこの基関数は動作を全く実行しません。
6.4. CachePurgeRequest Primitive
6.4. CachePurgeRequest原始的です。
Format: cache_purge_request([Pool-Handle | Pool-Element-Handle])
形式: キャッシュ_パージ_要求[要素ハンドルをプールしていた状態で|プールで扱ってください)
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.
ユーザがPool Handleとローカルのハンドル翻訳を渡すならキャッシュが存在している、できるだけ早さ、Endpoint、ローカルなキャッシュからPool Handleに関するマッピング情報を取り除くべきです。 ユーザがPool要素ハンドルを渡すなら、Pool Handleはキャッシュ_パージ_要求に中で使用されます。
Note that if the ASAP service does NOT support a local cache, this primitive performs NO action.
それに注意してください、できるだけ早く、サービスはローカルなキャッシュをサポートしないで、またこの基関数は動作を全く実行しません。
6.5. DataSendRequest Primitive
6.5. DataSendRequest原始的です。
Format: data_send_request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options);
形式: データ_は_要求(destinationAddress、typeOfAddress、メッセージ、sizeOfMessage、Options)を送ります。
This primitive requests ASAP to send a message to some specified Pool or Pool Element within the current Operational scope.
できるだけ早くメッセージをいくつかに送るのが現在のOperational範囲の中でPoolかPool Elementを指定したというこの原始の要求。
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.
要求を送ってください、送付者のもの。アドレスによって、使用されていた状態でタイプしてください、できるだけ早く、メッセージを出す前に、Endpointはアドレス変換とPool Element選択を実行するかもしれません。 また、これは、必要な輸送タイプに会うためにローカル運送終点の作成を書き取るかもしれません。
The data_send_request primitive can take different forms of address types, as described in the following sections.
_が_要求プリミティブを送るデータは以下のセクションで説明されるように異なったフォームのアドレスタイプを取ることができます。
Stewart, et al. Experimental [Page 33] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[33ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
6.5.1. Sending to a Pool Handle
6.5.1. プールハンドルに発信します。
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.
これが最も簡単なフォームである、_データ_要求プリミティブを送ってください。 デフォルトで、これは、できるだけ早く、指定されたプールの中のPool Elementsのひとりにメッセージを送るよう指示します。
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.
メッセージを送る前に、プール、送付者のものへの外では、終点は、最初に、できるだけ早く、翻訳を扱うためにプールハンドルを実行しなければなりません。 また、複数のPool Elementsがプールの中に存在するなら、それは、Pool Element選択を実行する必要があるかもしれません。
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).
送付者のものであり、ローカルなキャッシュでプールに関するマッピング情報を持っていないならできるだけ早く実装がマッピング情報のローカルなキャッシュをサポートしないと伝える、_ENRPサーバから応答を待っている間、できるだけ早く、HANDLE_RESOLUTIONは現在のホームENRPサーバへ通信して(セクション2.2 .5と3.3を見ます)、待ち行列で外国行きのメッセージを保持しなければなりません(ENRPサーバがSHOULDを反応させる前にこのプールに要求をこれ以上送ってください、そして、また、列に並ばせられてください、)。
Once the necessary mapping information arrives from the ENRP server, the sender's ASAP will:
一度、必要なマッピング情報はサーバ、送付者のものができるだけ早くそうするENRPから到着します:
A) map the pool handle into a list of transport addresses of the
destination PE(s);
a) 目的地PE(s)の輸送アドレスのリストの中にプールハンドルを写像してください。
B) if multiple PEs exist in the pool, choose one of them and transmit
the message to it. In that case, the choice of the PE is made by
the ASAP Endpoint of the sender based on the server pooling
policy, as discussed in Section 6.5.2;
B) 複数のPEsがプールの中に存在するなら、彼らのひとりを選んでください、そして、メッセージをそれに送ってください。 その場合、PEの選択をする、できるだけ早さ、Endpoint、セクション6.5.2で議論するようにサーバプーリング方針に基づく送付者について。
C) optionally create any transport endpoint that may be needed to
communicate with the PE selected;
C) 任意に選択されるPEで交信するのに必要であるあらゆる輸送終点を作成してください。
D) if no transport association or connection exists towards the
destination PE, establish any needed transport state;
D) どんな輸送協会も接続も目的地PEに向かって存在しないなら、あらゆる必要な輸送状態を設置してください。
E) send out the queued message(s) to the appropriate transport
connection using the appropriate send mechanism (e.g., for SCTP,
the SEND primitive in [RFC4960] would be used); and,
E) 好個を使用するとメカニズムが送られる適切な輸送接続に列に並ばせられたメッセージを出してください(例えば、SCTPには、[RFC4960]の原始のSENDは使用されるでしょう)。 そして
F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g., the
SCTP association id) if any new transport state was created.
F) ローカルなキャッシュが実装されるなら、ローカルなキャッシュを追加するか、またはENRPサーバの応答でマッピング情報を受け取っていてアップデートしてください。 また、何か新しい輸送状態が創設されたなら、ローカル運送情報(例えば、SCTP協会イド)を記録してください。
Stewart, et al. Experimental [Page 34] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[34ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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).
任意に、できるだけ早さ、Endpoint、メッセージを送った後に、送付者は選択されたPEのPool Elementハンドルをアプリケーションに返すかもしれません。 そして、今後のトランスミッションにその同じPEにこのPEハンドルを使用できます(セクション6.5.3を見てください)。
Section 3.7 defines the failover procedures for cases where the selected PE is found unreachable.
セクション3.7は選択されたPEが手が届かないのがわかるケースのためのフェイルオーバー手順を定義します。
6.5.2. Pool Element Selection
6.5.2. プール要素選択
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.
その都度、できるだけ早さ、User、できるだけ早くEndpointが現在のメッセージの受信機としてプールでPEsの1つを選定しなければならないという1PEを含むプール、送付者のものへのメッセージを送ります。 メッセージが送られるプールの現在のサーバプーリング方針によると、選択をします。
Note, no selection is needed if the ASAP_SEND_TOALL option is set (see Section 6.5.5).
注意、選択は全く必要でない、_できるだけ早く、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は登録時にそれ自体にPolicy Valueを指定できます。 Policy Valueの意味はグループの現在のサーバプーリング方針によります。 また、PEがPolicy Valueを変えることができる、いつ、新しいPolicy Valueと共にhandlespaceにそれ自体を再登録して、それは望んでいるか。 再登録で、できるだけ早く単に_ホームENRPサーバへのREGISTRATIONを別のものに送りながら、するでしょう(セクション2.2.1を見てください)。
One basic policy is defined in this document; others can be found in [RFC5356]
1つの基本方針が本書では定義されます。 中で他のものを見つけることができます。[RFC5356]
6.5.2.1. Round-Robin Policy
6.5.2.1. 連続方針
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.
いつ、できるだけ早さ、Endpoint、Pool HandleとRound-ロビンがそのPoolの通貨政策であるというメッセージを送るか、できるだけ早さ、Endpoint、送付者では、それぞれの外国行きのメッセージのためにそのPoolのすべての登録されたPEsを通してRound-Robiningで受信機を選択するために望んでください、外国行きのメッセージの同等の分配を達成する試みで。 大きいサーバで水たまりになる注意、力がすべてのPEsを後部に送るというわけではないENRPサーバ、できるだけ早さ、クライアント この場合、クライアントかPUが全体のPoolの部分集合に関するRoundロビン方針を実行するでしょう。
6.5.3. Sending to a Pool Element Handle
6.5.3. プール要素ハンドルに発信します。
In this case, the destinationAddress and typeOfAddress together indicate an ASAP Pool Element handle.
この場合一緒にdestinationAddressとtypeOfAddressが示す、できるだけ早さ、Pool Elementハンドル。
Stewart, et al. Experimental [Page 35] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[35ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
This requests that the ASAP Endpoint deliver the message to the PE identified by the Pool Element handle.
これがそれを要求する、できるだけ早く、EndpointはPool Elementハンドルによって特定された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.
Pool Elementハンドルは目的地PEかPool Handleと輸送タイプのPool Handleと送付先輸送アドレスを含むはずです。 また、他の実装依存要素はPool Elementハンドルでキャッシュされるかもしれません。
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.
できるだけ早く、Endpointは、交信する終点を特定するのに輸送アドレスと輸送タイプを使用するものとします。 コミュニケーション状態が全く同輩終点(そして、トランスポート・プロトコルが必要である)で存在していないなら呼び出す、できるだけ早く、Endpointは必要な状態を設立して、次に、特定のトランスポート・プロトコルがメッセージをPEに送るためには原始のSENDを呼び出すかもしれません。
In addition, if a local translation cache is supported, the endpoint will:
さらに、ローカルな翻訳キャッシュがサポートされると、終点はサポートされるでしょう:
A) send out the message to the transport address (or association id)
designated by the PE handle.
a) PEハンドルによって指定された輸送アドレス(または、協会イド)にメッセージを出してください。
B) determine if the Pool Handle is in the local cache.
B) ローカルなキャッシュでPool Handleがあるか決定してください。
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)が発信しながらプールハンドルの上にホームENRPサーバにハンドル解決を求める、_できるだけ早く、HANDLE_RESOLUTIONが通信する、(セクション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はPool Elementハンドルによって示された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).
任意に、できるだけ早さ、Endpoint、メッセージが送られた実際のPool Elementハンドルを返すかもしれません(これはPool Elementハンドルと基関数が呼び出されると指定されていた状態で異なるかもしれません、自動フェイルオーバーの可能性のため)。
Stewart, et al. Experimental [Page 36] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[36ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
6.5.4. Send by Transport Address
6.5.4. 輸送アドレスで、発信してください。
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.
これはできるだけ早く、送付者のものを指示します。指定された輸送アドレスにメッセージを出すEndpoint。
No endpoint failover is supported when this form of send request is used. This form of send request effectively bypasses the ASAP endpoint.
どんな終点フェイルオーバーもサポートされて、これがいつで形成されるかが使用される要求を送るということではありません。 これが形成する、発信、有効に迂回を要求してください、できるだけ早さ、終点。
6.5.5. Message Delivery Options
6.5.5. メッセージ配送オプション
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.
パラメタがメッセージ配送の特別な取り扱いのときに上記の_要求プリミティブができるだけ早く送付者のものへの方向を与えるデータ_が送る様々なフォームを終点を通り過ぎたOptions。
The value of the Options parameter is generated by bit-wise "OR"ing of the following pre-defined constants:
Optionsパラメタの値は以下の事前に定義された定数のビット的な「OR」ingによって生成されます:
ASAP_USE_DEFAULT: 0x0000 Use default setting.
できるだけ早く、_は_デフォルトを使用します: 0×0000は既定の設定を使用します。
ASAP_SEND_FAILOVER: 0x0001 Enables PE failover on this message. In
the case where the first selected PE or the PE pointed to by the
PE handle is found unreachable, the sender's ASAP Endpoint SHOULD
re-select an alternate PE from the same pool if one exists, and
silently re-send the message to this newly selected endpoint.
できるだけ早く、_は_フェイルオーバーを送ります: 0×0001 このメッセージでPEフェイルオーバーを可能にします。 中では、1番目がPEハンドルによって示されたPEかPEを選択したケースが手が届かないのがわかります、送付者のもの。できるだけ早く、1つが存在しているなら、Endpoint SHOULDは同じプールから代替の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の故障が起こると、PEでSCTP層によって承認されましたが、まだ承認されたというわけではないメッセージは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.
できるだけ早く、_は__フェイルオーバーを全く送りません: これがゆだねる0×0002はできるだけ早く、送付者のものを禁止します。1番目がPEを選択したという場合におけるどんな代替のPEへのメッセージも再送するのからのEndpoint、またはPEハンドルによって示されたPEが手が届かないのがわかっています。 代わりに、送付者のものはできるだけ早くError.Reportと共に「非-可到達性」に関して層にします、そして、Endpointが、覚醒剤に通知するものとするあらゆるunsentデータを返してください。
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.
できるだけ早く、_は最後に_を_に送ります: これがゆだねる0×0004がそれを要求する、送付者のもの、できるだけ早く、Endpointはこのプールに運命づけられた前のメッセージが送られたプールの中の同じPEにメッセージを送ります。
Stewart, et al. Experimental [Page 37] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[37ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
できるだけ早く、_は_すべてに_を送ります: 0×0008 Pool Handleによる送付、このオプションができるだけ早く送付者のものを指示するとき、送付者であるなら、送付者自身以外のすべてのPEsにメッセージのコピーを送る終点はそのプールの中のPEです。
ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination
with the ASAP_SEND_TO_ALL option. It permits the sender's ASAP
Endpoint to also deliver a copy of the message to itself if the
sender is a PE of the pool (i.e., loop-back).
できるだけ早く、_は_自己に_を送ります: と組み合わせてこのオプションが当てはまらない0×0010、しかできるだけ早さ、_すべてがゆだねるSEND_TO_。 それはできるだけ早く、送付者のものを可能にします。送付者であるなら、また、コピーに関するメッセージをそれ自体に提供するEndpointはプール(すなわち、ループバック)のPEです。
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).
できるだけ早さ、_SCTP_UNORDER: 0×1000 このオプションは、トランスポート層が順不同の配送を使用することで現在のメッセージを送るよう要求します(基本的な輸送が、順不同の配送はこのオプションが有効であるとサポートしなければならないことに注意してください)。
6.6. Data.Received Notification
6.6. Data.Received通知
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.
新しいユーザメッセージが受信されているときできるだけ早さ、Endpoint、受信機用途では、メッセージを覚醒剤に通過するこの通知は層にされます。
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.
通過されるメッセージと共にできるだけ早さ、Endpoint、また、受信機はメッセージ送付者アドレスを上側の層に示すはずです。 または、送付者のアドレスがSCTP協会イドの形にあることができます、TCP輸送アドレス、UDP輸送アドレス、できるだけ早さ、Pool Elementは扱います。
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) ハンドル翻訳ローカルなキャッシュはEndpoint、できるだけ早く受信機のところで実装されて、逆の送付者のIPアドレスからプールハンドルまでのマッピングが実行されるべきであり、マッピングがうまくいくかどうかにそうされるということです、送付者のもの。できるだけ早く、Pool Elementハンドルは、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が使用されていないなら)がsenderAddress分野で通過されるべきであるSCTP協会イドか他の輸送です。
Stewart, et al. Experimental [Page 38] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[38ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
6.7. Error.Report Notification
6.7. Error.Report通知
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が通知するために生成されるべきである、できるだけ早く、失敗される周りのUserは他の異常と同様に配送を通信させます。
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.
一緒にdestinationAddressとtypeOfAddressは、メッセージが元々だれに送られたかを示します。 アドレスタイプがどちらかであるかもしれない、できるだけ早く、Pool Elementハンドル、協会イド、またはaがアドレスを輸送します。
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分野でそれぞれ通過されるべきです。
6.8. Examples
6.8. 例
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.
これらの例は、基本的なSCTPがPEとPUの間の輸送であると仮定します。 他の輸送は可能ですが、SCTPは説明に役立った目的のための例で利用されます。 PUと、ENRPサーバと、PEとENRPサーバとのすべてのコミュニケーションがSCTPを使用していることに注意してください。
6.8.1. Send to a New Pool
6.8.1. 新しいプールに発信してください。
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).
この例は、Pool Userがいつローカルな翻訳キャッシュにはないプールに「こんにちは」というメッセージを送るかを(地方のキャッシュを仮定するのはサポートされます)イベント系列に示します。
ENRP Server PU new-handle:PEx
ENRPのサーバのPuの新しいハンドル: PEx
| | |
| +---+ |
| | 1 | |
|2. ASAP_HANDLE_RESOLUTION +---+ |
|<-------------------------------| |
| +---+ |
| | 3 | |
|4. ASAP_HANDLE_RESOLUTION_RSP +---+ |
|------------------------------->| |
| +---+ |
| | 5 | |
| +---+ 6. "hello1" |
| |---------------->|
| | |
| | | | +---+ | | | 1 | | |2. _できるだけ早く、_解決+を扱ってください。---+ | |<-------------------------------| | | +---+ | | | 3 | | |4. _できるだけ早く、_解決_RSP+を扱ってください。---+ | |------------------------------->| | | +---+ | | | 5 | | | +---+ 6. "hello1""| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|
Stewart, et al. Experimental [Page 39] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[39ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
1) The user at PU invokes:
1) PUのユーザは以下を呼び出します。
data_send_request("new-handle", handle-type, "hello1", 6, 0);
データ_が_要求を送る、(「新しいハンドル」であり、ハンドルでタイプしてください、「hello1"、6、0、)」、。
The ASAP Endpoint, in response, looks up the pool "new-handle" in
its local cache, but fails to find it.
できるだけ早さ、Endpoint、応答でローカルなキャッシュにおける「新しいハンドル」のプールを見上げますが、それを見つけません。
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) できるだけ早さ、Endpoint、PUがメッセージを列に並ばせて、発信する、_できるだけ早く、HANDLE_RESOLUTIONは、「新しいハンドル」をプールするよう周囲ですべての情報を求めるENRPサーバに要求します。
3) A T1-ENRPrequest timer is started while the ASAP Endpoint is
waiting for the response from the ENRP server.
3) T1-ENRPrequestタイマが始動される、できるだけ早く、EndpointはENRPサーバから応答を待ちます。
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サーバが質問に応じる、_できるだけ早く、それがすべての情報を含むHANDLE_RESOLUTION_RESPONSEメッセージは「新しいハンドル」をプールします。
5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local
cache with information on pool "new-handle".
5) できるだけ早く、PUでは、T1-ENRPrequestタイマは取り消されています、そして、「新しいハンドル」というプールの情報でローカルなキャッシュに居住してください。
6) Based on the server pooling policy of pool "new-handle", ASAP at
PU selects the destination PE (PEx), sets up, if necessary, an
SCTP association towards PEx (explicitly or implicitly), and sends
out the queued "hello1" user message.
6) プールのサーバプーリング方針に「新しいハンドル」であることで基づいて、列に並ばせられた「hello1"ユーザメッセージ」は、できるだけ早く、PUでは、目的地PE(PEx)を選択して、PEx(明らかかそれとなく)に向かって必要なら、SCTP協会を設立して、出されています。
6.8.2. Send to a Cached Pool Handle
6.8.2. キャッシュされたプールハンドルに発信してください。
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.
これがイベント系列にいつかを示している、できるだけ早さ、User PU、何がセクション6.8で.1に起こったかの後のプールへの「新しいハンドル」という別のメッセージを送ります。
ENRP Server PU new-handle:PEx
ENRPのサーバのPuの新しいハンドル: PEx
| | |
| +---+ |
| | 1 | |
| +---+ 2. "hello2" |
| |---------------->|
| | |
| | | | +---+ | | | 1 | | | +---+ 2. "hello2""| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|
Stewart, et al. Experimental [Page 40] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[40ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
1) The user at PU invokes:
1) PUのユーザは以下を呼び出します。
data_send_request("new-handle", handle-type, "hello2", 6, 0);
データ_が_要求を送る、(「新しいハンドル」であり、ハンドルでタイプしてください、「hello2"、6、0、)」、。
The ASAP Endpoint, in response, looks up the pool "new-handle" in
its local cache and finds the mapping information.
できるだけ早さ、Endpoint、応答でローカルなキャッシュにおける「新しいハンドル」のプールを見上げて、マッピング情報を見つけます。
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) 「新しいハンドル」のサーバプーリング方針に基づいて、「hello2"メッセージ(SCTP協会が既に設立されると仮定する)」は、できるだけ早く、PUでは、PE(EPxが再び選択されると仮定する)を選択して、出されています。
6.9. PE Send Failure
6.9. PEは失敗を送ります。
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.
いつ、できるだけ早さ、Endpoint、PEかPEとやり損ないにメッセージを送るPU試みでは、失敗した送付者はセクション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.
また、追加基関数はこのセクションでそうしないそれらのユーザアプリケーションができるだけ早く実際の輸送として使用したいサポートと定義されます。
6.9.1. Translation.Request Primitive
6.9.1. Translation.Request Primitive
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.
翻訳キャッシュがアドレスタイプがPool Handleと地方のハンドルであるなら存在している、できるだけ早さ、Endpoint、翻訳キャッシュの中で見て、現在の知られている輸送タイプ、ポート、およびアドレスを訪問者に返すべきです。
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.
_できるだけ早く、HANDLE_RESOLUTIONは使用を要求します。どんなPool Handleがローカルなハンドルキャッシュで存在しなくてもいいかどうかも、ハンドルキャッシュも存在していない、できるだけ早くEndpointが発信する、Pool Handle。 ハンドル解決の完成に関してできるだけ早さ、Endpoint、ローカルなハンドルキャッシュ(ローカルなハンドルキャッシュがサポートされるなら)に居住して、輸送タイプ、ポート、およびアドレスを訪問者に返すべきです。
Stewart, et al. Experimental [Page 41] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[41ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
6.9.2. Transport.Failure Primitive
6.9.2. Transport.Failure原始的です。
Format: transport.failure(Pool-Handle, Transport-address)
形式: transport.failure(プールハンドル、輸送アドレス)
If an external user encounters a failure in sending to a PE and is *not* using ASAP, it can use this primitive to report the failure to the ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the "Home" ENRP server in response to this primitive. Note ASAP SHOULD NOT send an ASAP_ENDPOINT_UNREACHABLE *unless* the user has actually made a previous request to send data to the PE.
社外利用者がPEに発信する際に失敗に遭遇して、*ができるだけ早くそれが失敗を報告するのにこの基関数を使用できる*使用でない、できるだけ早さ、終点 できるだけ早く発信する、できるだけ早さ、_これに対応した原始の「ホーム」ENRPサーバへのENDPOINT_UNREACHABLE。 注意ASAP SHOULD NOTが発信する、_できるだけ早く、**ユーザが実際にaを前にしていない場合、ENDPOINT_UNREACHABLEは、データをPEに送るよう要求します。
7. Timers, Variables, and Thresholds
7. タイマ、変数、および敷居
The following is a summary of the timers, variables, and pre-set protocol constants used in ASAP.
↓これはタイマ、変数、およびできるだけ早さで使用される事前に設定プロトコル定数の概要です。
7.1. Timers
7.1. タイマ
T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is queued).
Normally set to 15 seconds.
T1-ENRPrequest--できるだけ早さまでにENRPサーバに要求を送るとき、タイマは始動しました(アプリケーション情報を提供するのは列に並ばせられます)。 通常、15秒までセットしてください。
T2-registration - A timer started when sending an ASAP_REGISTRATION
request to the Home ENRP server, normally set to 30 seconds.
T2-登録、--、発信するとき、タイマが始動した_できるだけ早く、REGISTRATIONは、通常、30秒までセットするようホームENRPサーバに要求します。
T3-deregistration - A timer started when sending a de-registration
request to the Home ENRP server, normally set to 30 seconds.
T3-deregistration--通常、30秒に設定されたホームENRPサーバに反-登録要求を送るとき、タイマは始動しました。
T4-reregistration - This timer is started after successful
registration into the ENRP handlespace and is used to cause a re-
registration at a periodic interval. This timer is normally set
to 10 minutes or 20 seconds less than the Lifetime parameter used
in the registration request (whichever is less).
T4-reregistration--このタイマは、うまくいっている登録の後にENRP handlespaceに始動されて、周期的な間隔で、再登録を引き起こすのに使用されます。 このタイマは、通常、10分に設定されるか、またはLifetimeパラメタより登録要求で20秒使用されません(どれがさらに少ないかなら)。
T5-Serverhunt - This timer is used during the ENRP Server Hunt
procedure and is normally set to 10 seconds.
T5-Serverhunt--このタイマは、ENRP Server Hunt手順の間、使用されて、通常、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--このタイマは_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秒に設定されます。
7.2. Variables
7.2. 変数
stale_cache_value - A threshold variable that indicates how long a
cache entry is valid for.
_キャッシュ_値の聞き古したになってください--エントリーが有効であるどれくらい長いキャッシュを示す敷居変数。
Stewart, et al. Experimental [Page 42] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[42ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
7.3. Thresholds
7.3. 敷居
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.
マックスレッジ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.
マックス-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秒に設定されます。
8. IANA Considerations
8. IANA問題
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.
このドキュメント(RFC5352)はこのセクションで説明されたすべての登録証明書の参照です。 すべての登録証明書がReliable Server Pooling(RSerPool)パラメタページに記載されています。
8.1. A New Table for ASAP Message Types
8.1. できるだけ早い新しいテーブルはタイプを通信させます。
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":
できるだけ早く、Message TypesはIANAによって維持されます。 14の初期の値が図1で説明されるようにIANAによって割り当てられました。 IANAが新しいテーブルを作成したのを「タイプはできるだけ早く、通信します」:
Type Message Name Reference ----- ------------------------- --------- 0x00 (Reserved by IETF) RFC 5352 0x01 ASAP_REGISTRATION RFC 5352 0x02 ASAP_DEREGISTRATION RFC 5352 0x03 ASAP_REGISTRATION_RESPONSE RFC 5352 0x04 ASAP_DEREGISTRATION_RESPONSE RFC 5352 0x05 ASAP_HANDLE_RESOLUTION RFC 5352 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFC 5352 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFC 5352 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFC 5352 0x09 ASAP_ENDPOINT_UNREACHABLE RFC 5352 0x0a ASAP_SERVER_ANNOUNCE RFC 5352 0x0b ASAP_COOKIE RFC 5352 0x0c ASAP_COOKIE_ECHO RFC 5352 0x0d ASAP_BUSINESS_CARD RFC 5352 0x0e ASAP_ERROR RFC 5352 0x0b-0xff (Available for Assignment) RFC 5352
メッセージ名前参照をタイプしてください。----- ------------------------- --------- 0×00(IETFによって予約される)RFC、5352、0×01、できるだけ早さ、_登録RFC、5352、0×02、できるだけ早さ、_DEREGISTRATION RFC、5352、0×03、できるだけ早さ、_登録_応答RFC、5352、0×04、できるだけ早さ、_DEREGISTRATION_応答RFC、5352、0×05、できるだけ早く_が_解決RFCを扱う、5352、0×06、できるだけ早く_が_解決_応答RFCを扱う、5352、0×07、_できるだけ早く、終点_は_を生かします; RFC、5352、0×08、_できるだけ早く、終点_が_を生かす、_ACK RFC、5352、0×09、できるだけ早さ、__の手の届かないRFC5352終点0x0a、_できるだけ早く、サーバ_ができるだけ早くRFC5352 0x0bを発表する、_クッキーRFC5352 0x0c、_できるだけ早く、クッキー_ができるだけ早くRFC5352 0x0dを反響する、_ビジネス_カードRFC5352 0x0e、できるだけ早さ、_誤りRFC5352 0x0b-0xff(課題に利用可能な)RFC5352
Stewart, et al. Experimental [Page 43] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[43ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
登録するという要求、できるだけ早く、このテーブルのMessage TypeをIANAに送るべきです。 数はユニークであるに違いありません。 「仕様が必要である」という[RFC5226]の方針を適用しなければなりません。
8.2. Port Numbers
8.2. ポートナンバー
The references for the already assigned port numbers
既に割り当てられたポートナンバーの参照
asap-tcp 3863/tcp
asap-tcp3863/tcp
asap-udp 3863/udp
asap-udp3863/udp
asap-sctp 3863/sctp
asap-sctp3863/sctp
asap-tcp-tls 3864/tcp
asap-tcp-tls3864/tcp
asap-sctp-tls 3864/sctp
asap-sctp-tls3864/sctp
have been updated to RFC 5352.
RFC5352に、アップデートしました。
8.3. SCTP Payload Protocol Identifier
8.3. SCTP有効搭載量プロトコル識別子
The reference for the already assigned ASAP payload protocol identifier 11 has been updated to RFC 5352.
できるだけ早く既に割り当てられるためにペイロードに参照をつけてください。プロトコル識別子11をRFC5352にアップデートしました。
8.4. Multicast Addresses
8.4. マルチキャストアドレス
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、.185と)IPv6マルチキャストが扱う.1、(FF0X:、0:、0:0:0、:、0:0:133、) IPv4アドレスがInternetwork Control Blockの一部である、(224.0 .1 /24)。
9. Security Considerations
9. セキュリティ問題
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実装によってどう保護されるかを提示します。
Stewart, et al. Experimental [Page 44] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[44ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
9.1. Summary of RSerPool Security Threats
9.1. RSerPool軍事的脅威の概要
"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.
「脅威のReliable Server Pooling(RSerPool)によるIntroducedとThreatsへのResponseのSecurityのためのRequirements」[RFC5355]は、詳細にRSerPoolアーキテクチャに脅威を説明して、各脅威に対応してセキュリティ要件をリストアップします。 本書では説明された脅威から、RSerPoolプロトコルに必要であるセキュリティー・サービスは以下に列挙されます。
Threat 1) PE registration/de-registration flooding or spoofing. ----------- Security mechanism in response: ENRP server authenticates the PE.
脅威1) PE反-登録/登録氾濫かスプーフィング。 ----------- 応答におけるセキュリティー対策: ENRPサーバはPEを認証します。
Threat 2) PE registers with a malicious ENRP server. ----------- Security mechanism in response: PE authenticates the ENRP server.
脅威2) PEは悪意があるENRPサーバとともに記名します。----------- 応答におけるセキュリティー対策: PEはENRPサーバを認証します。
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.
脅威3) 悪意があるENRPサーバはENRPサーバプールを接合します。 ----------- 応答におけるセキュリティー対策: ENRPサーバは互いに認証します。
Threat 4) A PU communicates with a malicious ENRP server for handle resolution. ----------- Security mechanism in response: The PU authenticates the ENRP server.
脅威4) PUはハンドル解決のための悪意があるENRPサーバとコミュニケートします。 ----------- 応答におけるセキュリティー対策: PUはENRPサーバを認証します。
Threat 5) Replay attack. ----------- Security mechanism in response: Security protocol that has protection from replay attacks.
脅威5) 反射攻撃。 ----------- 応答におけるセキュリティー対策: 反射攻撃からの保護があるセキュリティプロトコル。
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.
脅威6) プールに関してPUには誤伝がある崩壊したデータは解決を扱います。 ----------- 応答におけるセキュリティー対策: 保全が保護であるとサポートするセキュリティプロトコル。
Threat 7) Eavesdropper snooping on handlespace information. ----------- Security mechanism in response: Security protocol that supports data confidentiality.
脅威7) handlespace情報で詮索する立ち聞きする者。 ----------- 応答におけるセキュリティー対策: データが秘密性であるとサポートするセキュリティプロトコル。
Stewart, et al. Experimental [Page 45] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[45ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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.
脅威8) できるだけ早さを浸水させてください。_PUからENRPサーバまでのENDPOINT_UNREACHABLEメッセージ。----------- 応答におけるセキュリティー対策: できるだけ早く、必須はできるだけ早さの数を制御します。Endpoint手の届かないメッセージはPUからENRPサーバまで送られました。
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.
脅威9) できるだけ早さを浸水させてください。_ENRPサーバからのPEへのENDPOINT_KEEP_ALIVEメッセージ。----------- 応答におけるセキュリティー対策: ENRPサーバはできるだけ早さの数を制御しなければなりません。_PEへのENDPOINT_KEEP_ALIVEメッセージ。
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)
Pu<。---- ENRPサーバ(PUはENRPサーバを認証する)PE<。---->ENRPサーバ(互いの認証)ENRPサーバ<。----->ENRPサーバ(互いの認証)
9.2. Implementing Security Mechanisms
9.2. セキュリティがメカニズムであると実装します。
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のimplementersはRSerPoolのために最小限でTLS_RSA_WITH_AES_128_CBC_SHA ciphersuiteをサポートしなければなりません。 後方にの目的のために、互換性、ENRP SHOULDは、TLS_RSA_WITH_3DES_EDE_がCBC_SHAであるとサポートします。 また、Implementersはいかなる他のIETFによって承認されたciphersuitesもサポートするかもしれません。
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サーバ、PEs、およびPUsはTLSを実装しなければなりません。 PSK(あらかじめ共有されたキー)を使用して、ENRPサーバとPEsは互いの認証をサポートしなければなりません。 PSKを使用して、ENRPサーバは自分たちの中で互いの認証をサポートしなければなりません。 証明書を使用して、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とENRP認証へのPEのための認証機構として実装するために義務的です。 PSKに関しては、あらかじめ共有されたキーを持っていると、承認は構成されます。 プールのネットワーク管理者は、どのノードがプールに参加するのが認可されるかを決める必要があります。 PSKのための正当化は私たちが、1つの管理ドメインがサーバプールを制御して、管理すると思うということです。 これは、PSKが主要なセキュリティ管理者によって実装されて、管理されるのを許容します。
Stewart, et al. Experimental [Page 46] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[46ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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は、PUsのための認証機構としてENRPサーバに実装するために義務的です。証明書を使用して、PUsはENRPサーバを認証しなければなりません。 ENRPサーバには、対象がそれらの正準なホスト名に対応するサイト証明書がなければなりません。 PUsには、それら自身の証明書がTLSとの互いの認証のためにあるかもしれませんが、条項は全く本書では彼らの使用のために詳しく説明されません。 サポートTLS MUSTにはメカニズムがTLS交渉の間に受け取られた証明書を有効にしながらあるRSerPool Elements。 これは認証局(望ましくはウェブブラウザのためにルート証明書を発行するものに匹敵するサイト証明書のよく知られるディストリビュータ)によって発行された1つ以上のルート証明書の所有物を伴います。
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). The client's understanding of the server's identity (typically, the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using DNS Security (DNSSEC), or using user- or admin-configured host-to-address/ address-to-host lookup tables).
介入者攻撃を防ぐために、クライアントはサーバのアイデンティティについて確かめなければなりません(サーバのCertificateメッセージに示されるように)。 サーバのアイデンティティ(通常、アイデンティティは以前は輸送接続をよく確立していた)に関するクライアントの理解は「参照のアイデンティティ」と呼ばれます。 クライアントは、参照のアイデンティティのタイプ(例えば、DNS名かIPアドレス)を決心して、マッチが生産されるまで、対応するタイプの参照のアイデンティティとそれぞれのsubjectAltName値での比較を実行します。 マッチがいったん生産されると、サーバのアイデンティティは確かめられました、そして、サーバ身元確認は完全です。 異なったsubjectAltNameタイプは異なった方法で合わせられています。 比較を実行する前に、クライアントは異なったタイプへの参照のアイデンティティを写像するかもしれません。 マッピングは参照のアイデンティティを写像できるすべての手があいているsubjectAltNameタイプのために実行されるかもしれません。 しかしながら、参照のアイデンティティはマッピングが本来安全であるか(例えば、タイプdNSNameのsubjectAltNameと比較するためにURIからDNS名を抜粋します)、またはマッピングが安全な方法で実行される(例えば、DNS Security(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.
サーバ身元確認が失敗するなら、利用者志向クライアントSHOULDは、ユーザに通知するか、輸送接続を終えて、またはサーバのアイデンティティが疑わしいのを示します。 次に、自動化されたクライアントSHOULDはサーバのアイデンティティが疑わしいのを示す誤り、または両方を輸送接続を終えて、返すか、または登録します。 このセクションで説明されたサーバ身元確認を超えて、クライアントはサーバが提供するのが認可される確実にするさらなる照合に提供するよう要求されているサービスをする用意ができているべきです。 クライアントは、この決断をする際にローカルの方針情報を利用する必要があるかもしれません。
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,
参照のアイデンティティが国際化ドメイン名であるなら、実装を従わせると、それはASCII Compatible Encoding(ACE)形式に変換されなければなりません、[RFC3490]のセクション4で指定されるように、タイプdNSNameのsubjectAltName値との比較の前に。 明確に
Stewart, et al. Experimental [Page 47] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[47ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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).
実装を従わせると、以下の[RFC3490]のセクション4で指定された変換操作は働かなければなりません: * 1、ドメイン名SHALLは中に踏みます。「保存されたストリング」であると考えられてください。 * ステップ3では、「UseSTD3ASCIIRules」と呼ばれる旗を設定してください。 * ステップ4では、"ToASCII"操作で各ラベルを処理してください。 *そして、ステップ5では、すべてのラベル分離符をU+002Eの(終止符)に変えてください。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality, according to the rules specified in Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then, only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
「ASCII」への変換を実行した後に、平等のためにDNSラベルと名前を比較しなければなりません、RFC3490のセクション3で指定された規則に従って。 '*'(ASCII42)ワイルドカードキャラクタはタイプdNSNameのsubjectAltName値と、その値における最も左(最も重要でない)の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.
参照のアイデンティティがIPアドレスであるときに、[RFC0791]と[RFC2460]の「ネットワークバイトオーダー」八重奏ストリング表現にアイデンティティを変換しなければなりません。 IPバージョン4のために、RFC791で指定されるように、八重奏ストリングはまさに4つの八重奏を含むでしょう。 IPバージョン6のために、RFC2460で指定されるように、八重奏ストリングはまさに16の八重奏を含むでしょう。 そして、この八重奏ストリングはタイプiPAddressのsubjectAltName値に対してたとえられます。 参照アイデンティティ八重奏ストリングと値の八重奏ストリングが同じであるなら、マッチは現れます。
After a TLS layer is established in a session, both parties are to independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see RFC 4511)[RFC4511]. Implementations may re-evaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer.
TLS層がセッションのときに確立された後に、双方は、ローカルの方針とレベルが実現したセキュリティに基づいて続くかどうか独自に決めることになっています。 何れの当事者が決めるなら、セキュリティー・レベルが続くように不十分であり、それがSHOULDであることは交渉が完成したTLS(re)直後TLS層を取り除きます(RFC4511を見てください)[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.
実装はSCTPと共に[RFC3436]かTLSで説明されるように[RFC5246]で説明されるようにTCPの上で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が必要である、できるだけ早く議定書を作ってください、_できるだけ早さの数を制限するには、ENDPOINT_UNREACHABLEはENRPサーバへ通信します(セクション3.5を見ます)。
Stewart, et al. Experimental [Page 48] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[48ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
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は、ENRPプロトコルができるだけ早さの数を制限するのを必要とします。_ENRPサーバからPE([RFC5353]を見る)までのENDPOINT_KEEP_ALIVEメッセージ。
There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot consider the source address of such a message to be a trustworthy address of an ENRP server. A receiver must also be prepared to receive a large number of multicast announcements from attackers.
マルチキャスト発表のために定義されたセキュリティー対策が全くありません。 したがって、そのような発表の受信機は、そのようなメッセージのソースアドレスがENRPサーバの信頼できるアドレスであると考えることができません。また、攻撃者から多くのマルチキャスト発表を受けるように受信機を準備しなければなりません。
9.3. Chain of Trust
9.3. 信頼のチェーン
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つのアーキテクチャコンポーネントでTLS実装に基づいています--すなわち、PU、PE、およびENRPサーバ、私たちはすべてのコミュニケーションにTLSを使用して、機密保護しているENRPサーバになるようにENRP同輩とPE記入者を認証する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)
Pu<。---ENRPサーバ(ENRPサーバの認証; TLSの上の質問)PE<であることが固定された>。---ENRPサーバ(互いの認証; TLSの上の反-登録/登録)であることが固定された>は、ENRPサーバが<であると機密保護しました。---ENRPサーバであることが固定された>。(互いの認証; TLSを使用するデータベース更新)
If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it.
システムのすべての部品が使用TLSを認証して、伝えるなら、信頼のチェーンは有効です。 信頼チェーンの根はENRPサーバです。それがTLSを使用することで機密保護されると、セキュリティはそれに接続しようとするすべてのENRPとPEの部品のために励行されるでしょう。
Summary of interaction between secured and unsecured components: If the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as an error due to security considerations and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure, as the response can be tampered with in transit even if the ENRP database is secured.
機密保護していて非機密保護しているコンポーネントの間の相互作用の概要: PEがTLSを使用しないで、安全なENRPサーバとともに記名しようとすると、それはセキュリティ問題と登録による誤りが拒絶されるので示されたエラーメッセージ応答を受けるでしょう。 TLSを使用しないENRPサーバが安全なENRPサーバに関するデータベースをアップデートしようとすると、アップデートは拒絶されるでしょう。 PUがTLSを使用しないで、安全なENRPサーバとコミュニケートすると、応答が安全でないことは理解で返事をもらうでしょう、ENRPデータベースを保証してもトランジットで応答をいじることができるとき。
The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server.
最終的なケースは安全な要求をENRPに送るPUです。 ENRPとPEsが固定されていなくて、これが許容できる構成であるということであるかもしれません。 意図はPUとENRPサーバとのインターネット通信を保証することです。
Stewart, et al. Experimental [Page 49] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[49ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Summary:
概要:
RSerPool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers.
RSerPoolアーキテクチャの部品は、信頼のチェーンを証明するために互いにコミュニケートできます。 機密保護しているPEとENRPサーバはunsecured ENRPとのどんなコミュニケーションかPEサーバも拒絶します。
If the above is enforced, then a chain of trust is established for the RSerPool user.
上記が実施されるなら、信頼のチェーンはRSerPoolユーザのために設立されます。
10. Acknowledgments
10. 承認
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback.
作者は彼らの非常に貴重なコメントとフィードバックについてジョンLoughney、リンドン・オング、ウオルター・ジョンソン、トーマスDreibholz、および多くの他のものに感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Loughney, J., and M. Stillman, "Requirements for Reliable
Server Pooling", RFC 3237, January 2002.
[RFC3237]TuexenとM.とシェとQ.とスチュワートとR.と岸とM.とオングとL.とLoughney、J.とM.スティルマン、「信頼できるサーバプーリングのための要件」RFC3237(2002年1月)。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM.Tuexen、「ストリーム制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、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.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、「ストリーム制御伝動プロトコル」、RFC4960、2007年9月。
Stewart, et al. Experimental [Page 50] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[50ページ]RFC5352は2008年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問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling
Policies", RFC 5356, September 2008.
[RFC5356] DreibholzとT.とM.Tuexen、「信頼できるサーバプーリング方針」、RFC5356、2008年9月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters",
RFC 5354, September 2008.
[RFC5354] スチュワート、R.、シェ、Q.、スティルマン、M.、およびM.Tuexenは「サーバアクセス・プロトコル(できるだけ早い)と終点Handlespace冗長プロトコル(ENRP)パラメタに集めます」、RFC5354、2008年9月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", RFC 5353, September 2008.
[RFC5353] シェ、Q.、スチュワート、R.、スティルマン、M.、Tuexen、M.、およびA.シルヴァートン、「終点Handlespace冗長プロトコル(ENRP)」、RFC5353 2008年9月。
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M.,
and S. Sengodan, "Threats Introduced by Reliable Server
Pooling (RSerPool) and Requirements for Security in
Response to Threats", RFC 5355, September 2008.
[RFC5355]スティルマン、M.(エド)、ゴパル、R.、Guttman、E.、Holdrege、M.、およびS.Sengodan、「セキュリティのために信頼できるサーバプーリング(RSerPool)と要件によって脅威に対応して導入された脅威」RFC5355(2008年9月)。
11.2. Informative References
11.2. 有益な参照
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Stewart, et al. Experimental [Page 51] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[51ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Authors' Addresses
作者のアドレス
Randall R. Stewart The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
ランドル・R.スチュワート資源グループ1700ペンシルバニアAve NW Suite560 20006ワシントンDC(米国)
EMail: randall@lakerest.net
メール: randall@lakerest.net
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
シェ資源グループ1700ペンシルバニアAve NW Suite560 20006ワシントンDC(米国)をQiaobingします。
Phone: +1 224-465-5954 EMail: Qiaobing.Xie@gmail.com
以下に電話をしてください。 +1 224-465-5954 メールしてください: Qiaobing.Xie@gmail.com
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 USA
モーリーン蒸留装置操作係ノキア1167年のピーチトゥリーct。 ナパービル、IL60540米国
EMail: maureen.stillman@nokia.com
メール: maureen.stillman@nokia.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexen Muenster大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Stewart, et al. Experimental [Page 52] RFC 5352 Aggregate Server Access Protocol September 2008
スチュワート、他 実験的な[52ページ]RFC5352は2008年9月にサーバアクセス・プロトコルに集めます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Stewart, et al. Experimental [Page 53]
スチュワート、他 実験的[53ページ]
一覧
スポンサーリンク
