[要約] RFC 3539は、AAAトランスポートプロファイルに関する規格であり、認証、認可、会計のためのトランスポートプロトコルを定義しています。その目的は、ネットワーク上のユーザーの認証とアクセス制御を効果的に管理することです。
Network Working Group B. Aboba
Request for Comments: 3539 Microsoft
Category: Standards Track J. Wood
Sun Microsystems, Inc.
June 2003
Authentication, Authorization and Accounting (AAA) Transport Profile
認証、承認、会計（AAA）輸送プロファイル
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals.
このドキュメントでは、認証、承認、会計（AAA）のためにプロトコル内で発生する輸送の問題について説明します。また、AAAプロトコルによる輸送の使用に関する推奨事項も提供します。これには、標準トラックRFCの使用と実験的提案が含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 2
2. Issues in Transport Usage. . . . . . . . . . . . . . . . . . . 5
2.1. Application-driven Versus Network-driven . . . . . . . . 5
2.2. Slow Failover. . . . . . . . . . . . . . . . . . . . . . 6
2.3. Use of Nagle Algorithm . . . . . . . . . . . . . . . . . 7
2.4. Multiple Connections . . . . . . . . . . . . . . . . . . 7
2.5. Duplicate Detection. . . . . . . . . . . . . . . . . . . 8
2.6. Invalidation of Transport Parameter Estimates. . . . . . 8
2.7. Inability to use Fast Re-Transmit. . . . . . . . . . . . 9
2.8. Congestion Avoidance . . . . . . . . . . . . . . . . . . 9
2.9. Delayed Acknowledgments. . . . . . . . . . . . . . . . . 11
2.10. Premature Failover . . . . . . . . . . . . . . . . . . . 11
2.11. Head of Line Blocking. . . . . . . . . . . . . . . . . . 11
2.12. Connection Load Balancing. . . . . . . . . . . . . . . . 12
3. AAA Transport Profile. . . . . . . . . . . . . . . . . . . . . 12
3.1. Transport Mappings . . . . . . . . . . . . . . . . . . . 12
3.2. Use of Nagle Algorithm . . . . . . . . . . . . . . . . . 12
3.3. Multiple Connections . . . . . . . . . . . . . . . . . . 13
3.4. Application Layer Watchdog . . . . . . . . . . . . . . . 13
3.5. Duplicate Detection. . . . . . . . . . . . . . . . . . . 19
3.6. Invalidation of Transport Parameter Estimates. . . . . . 20
3.7. Inability to use Fast Re-Transmit. . . . . . . . . . . . 21
3.8. Head of Line Blocking. . . . . . . . . . . . . . . . . . 22
3.9. Congestion Avoidance . . . . . . . . . . . . . . . . . . 23
3.10. Premature Failover . . . . . . . . . . . . . . . . . . . 24
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . 25
6.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A - Detailed Watchdog Algorithm Description . . . . . . . 28
Appendix B - AAA Agents. . . . . . . . . . . . . . . . . . . . . . 33
B.1. Relays and Proxies . . . . . . . . . . . . . . . . . . . 33
B.2. Re-directs . . . . . . . . . . . . . . . . . . . . . . . 35
B.3. Store and Forward Proxies. . . . . . . . . . . . . . . . 36
B.4. Transport Layer Proxies. . . . . . . . . . . . . . . . . 38
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 39
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 39
Author Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals.
このドキュメントでは、認証、承認、会計（AAA）のためにプロトコル内で発生する輸送の問題について説明します。また、AAAプロトコルによる輸送の使用に関する推奨事項も提供します。これには、標準トラックRFCの使用と実験的提案が含まれます。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「必要はありません」、および「必要はありません」は、[RFC2119]に記載されているように解釈されるべきではありません。
Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation.
トレンド分析、監査、請求、またはコスト配分を目的として、リソース使用に関する情報を収集する行為を説明します。
Administrative Domain An internet, or a collection of networks, computers, and databases under a common administration.
管理ドメインインターネット、または共通の管理下でのネットワーク、コンピューター、およびデータベースのコレクション。
Agent A AAA agent is an intermediary that communicates with AAA clients and servers. Several types of AAA agents exist, including Relays, Re-directs, and Proxies.
エージェントA AAAエージェントは、AAAクライアントおよびサーバーと通信する仲介者です。リレー、リダイレクト、プロキシなど、いくつかのタイプのAAAエージェントが存在します。
Application-driven transport Transport behavior is said to be "application-driven" when the rate at which messages are sent is limited by the rate at which the application generates data, rather than by the size of the congestion window. In the most extreme case, the time between transactions exceeds the round-trip time between sender and receiver, implying that the application operates with an effective congestion window of one. AAA transport is typically application driven.
アプリケーション駆動型の輸送輸送動作は、メッセージが送信されるレートが、輻輳ウィンドウのサイズではなく、アプリケーションがデータを生成するレートによって制限される場合、「アプリケーション駆動型」と言われています。最も極端な場合、トランザクション間の時間は送信者と受信機の間の往復時間を超えており、アプリケーションが効果的な混雑ウィンドウで動作することを意味します。AAAトランスポートは通常、アプリケーション駆動型です。
Attribute Value Pair (AVP) The variable length concatenation of a unique Attribute (represented by an integer) and a Value containing the actual value identified by the attribute.
属性値ペア（AVP）一意の属性（整数で表される）の変数長の連結と、属性によって識別される実際の値を含む値。
Authentication The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication).
認証は、相互に既知の名前空間からの既存のラベルの形で、メッセージ（メッセージ認証）またはチャネルのエンドポイント（エンティティ認証）として、既知の名前空間から既存のラベルの形で検証する行為。
Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential.
認可されたリソースへのアクセスなど、特定の権利が特定の資格情報の発表者に付与できるかどうかを判断する行為。
Billing The act of preparing an invoice.
請求書を準備する行為を請求する。
Network Access Identifier The Network Access Identifier (NAI) is the userID submitted by the host during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. The NAI may not necessarily be the same as the user's e-mail address or the user-ID submitted in an application layer authentication.
ネットワークアクセス識別子ネットワークアクセス識別子（NAI）は、ネットワークアクセス認証中にホストが提出したユーザーIDです。ローミングでは、NAIの目的は、ユーザーを特定するだけでなく、認証要求のルーティングを支援することです。NAIは、ユーザーの電子メールアドレスや、アプリケーションレイヤー認証で提出されたユーザーIDと必ずしも同じではない場合があります。
Network Access Server (NAS) A Network Access Server (NAS) is a device that hosts connect to in order to get access to the network.
ネットワークアクセスサーバー（NAS）ネットワークアクセスサーバー（NAS）は、ネットワークにアクセスするために接続をホストするデバイスです。
Proxy In addition to forwarding requests and responses, proxies enforce policies relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. While proxies typically do not respond to client Requests prior to receiving a Response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and may not support all extensions.
プロキシリクエストと応答の転送に加えて、プロキシはリソースの使用とプロビジョニングに関連するポリシーを実施します。これは通常、NASデバイスの状態を追跡することで実現されます。通常、プロキシはサーバーから応答を受信する前にクライアントリクエストに応答しませんが、ポリシーが違反されている場合に拒否メッセージを発信する場合があります。その結果、プロキシはそれらを通過するメッセージのセマンティクスを理解する必要があり、すべての拡張機能をサポートしない場合があります。
Local Proxy A Local Proxy is a proxy that exists within the same administrative domain as the network device (e.g. NAS) that issued the AAA request. Typically a local proxy is used to multiplex AAA messages to and from a large number of network devices, and may implement policy.
ローカルプロキシローカルプロキシは、AAAリクエストを発行したネットワークデバイス（NASなど）と同じ管理ドメイン内に存在するプロキシです。通常、ローカルプロキシは、多数のネットワークデバイスとの間でAAAメッセージを多重化するために使用され、ポリシーを実装する場合があります。
Store and forward proxy Store and forward proxies distinguish themselves from other proxy species by sending a reply to the NAS prior to proxying the request to the server. As a result, store and forward proxies need to implement AAA client and server functionality for the messages that they handle. Store and Forward proxies also typically keep state on conversations in progress in order to assure delivery of proxied Requests and Responses. While store and forward proxies are most frequently deployed for accounting, they also can be used to implement authentication/authorization policy.
ストアとフォワードのプロキシストアおよび転送プロキシは、リクエストをサーバーにプロキシする前にNASに返信することにより、他のプロキシ種と区別します。その結果、ストアおよびフォワードプロキシは、処理するメッセージにAAAクライアントとサーバー機能を実装する必要があります。また、プロキシを保存および転送することで、プロキシのリクエストと応答の配信を保証するために、進行中の会話の状態を維持します。ストアおよびフォワードプロキシは、会計用に最も頻繁に展開されますが、認証/認証ポリシーを実装するためにも使用できます。
Network-driven transport Transport behavior is said to be "network driven" when the rate at which messages are sent is limited by the congestion window, not by the rate at which the application can generate data. File transfer is an example of an application where transport is network driven.
ネットワーク駆動型の輸送輸送の動作は、メッセージが送信されるレートが、アプリケーションがデータを生成できる速度ではなく、うっ血ウィンドウによって制限される場合、「ネットワーク駆動型」と言われています。ファイル転送は、輸送がネットワーク駆動型であるアプリケーションの例です。
Re-direct Rather than forwarding Requests and Responses between clients and servers, Re-directs refer clients to servers and allow them to communicate directly. Since Re-directs do not sit in the forwarding path, they do not alter any AVPs transitting between client and server. Re-directs do not originate messages and are capable of handling any message type. A Re-direct may be configured only to re-direct messages of certain types, while acting as a Relay or Proxy for other types. As with Relays, re-directs do not keep state with respect to conversations or NAS resources.
クライアントとサーバー間のリクエストと応答を転送するのではなく、リダイレクトを行うと、リダイレクトはクライアントを参照し、サーバーを直接通信できるようにします。リダイレクトは転送パスに座っていないため、クライアントとサーバー間のAVPSトランジットを変更しません。リダイレクトはメッセージを発信せず、メッセージタイプを処理できます。他のタイプのリレーまたはプロキシとして機能しながら、特定のタイプのメッセージを再ダイレクトするためにのみ再ダイレクトを構成できます。リレーと同様に、リダイレクトは会話やNASのリソースに関して状態を維持しません。
Relay Relays forward requests and responses based on routing-related AVPs and domain forwarding table entries. Since relays do not enforce policies, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any extension or message type. Since relays make decisions based on information in routing AVPs and domain forwarding tables they do not keep state on NAS resource usage or conversations in progress.
リレーは、ルーティング関連のAVPSおよびドメイン転送テーブルエントリに基づいて、フォワードリクエストと応答をリレーします。リレーはポリシーを実施しないため、非ルーティングAVPを調べたり変更したりしません。その結果、リレーはメッセージを発信することはなく、メッセージや非ルーティングAVPのセマンティクスを理解する必要はなく、拡張機能またはメッセージタイプを処理することができます。リレーは、AVPとドメイン転送テーブルをルーティングする際の情報に基づいて決定を下すため、NASリソースの使用または会話については状態を維持していません。
Issues that arise in AAA transport usage include:
AAA輸送の使用で発生する問題は次のとおりです。
Application-driven versus network-driven Slow failover Use of Nagle Algorithm Multiple connections Duplicate detection Invalidation of transport parameter estimates Inability to use fast re-transmit Congestion avoidance Delayed acknowledgments Premature Failover Head of line blocking Connection load balancing
アプリケーション駆動型とネットワーク駆動型のスローフェイルオーバーナグルアルゴリズムの使用複数の接続の重複検出輸送パラメーターの推定の無効化
We discuss each of these issues in turn.
これらの各問題について順番に説明します。
AAA transport behavior is typically application rather than network driven. This means that the rate at which messages are sent is typically limited by how quickly they are generated by the application, rather than by the size of the congestion window.
AAA輸送の動作は、通常、ネットワーク駆動型ではなくアプリケーションです。これは、メッセージが送信されるレートが、通常、輻輳ウィンドウのサイズではなく、アプリケーションによってどれだけ速く生成されるかによって制限されることを意味します。
For example, let us assume a 48-port NAS with an average session time of 20 minutes. This device will, on average, send only 144 authentication/authorization requests/hour, and an equivalent number of accounting requests. This represents an average inter-packet spacing of 25 seconds, which is much larger than the Round Trip Time (RTT) in most networks.
たとえば、平均セッション時間が20分の48ポートNASを想定しましょう。このデバイスは、平均して、144の認証/承認リクエスト/時間のみ、および同等の数の会計リクエストのみを送信します。これは、25秒の平均パケット間間隔を表しており、ほとんどのネットワークでの往復時間（RTT）よりもはるかに大きいです。
Even on much larger NAS devices, the inter-packet spacing is often larger than the RTT. For example, consider a 2048-port NAS with an average session time of 10 minutes. It will on average send 3.4 authentication/authorization requests/second, and an equivalent number of accounting requests. This translates to an average inter-packet spacing of 293 ms.
はるかに大きなNASデバイスであっても、パケット間の間隔はRTTよりも大きいことがよくあります。たとえば、平均セッション時間が10分の2048ポートNASを検討してください。平均して3.4認証/承認要求/秒を送信し、同等の数の会計リクエストを送信します。これは、293ミリ秒の平均パケット間間隔に変換されます。
However, even where transport behavior is largely application-driven, periods of network-driven behavior can occur. For example, after a NAS reboot, previously stored accounting records may be sent to the accounting server in rapid succession. Similarly, after recovery from a power failure, users may respond with a large number of simultaneous logins. In both cases, AAA messages may be generated more quickly than the network will allow them to be sent, and a queue will build up.
ただし、輸送動作が大部分がアプリケーション駆動型である場合でも、ネットワーク駆動型の動作の期間が発生する可能性があります。たとえば、NASの再起動の後、以前に保存されていた会計記録が迅速に会計サーバーに送信される場合があります。同様に、停電からの回復後、ユーザーは多数の同時ログインで応答する場合があります。どちらの場合も、AAAメッセージは、ネットワークを送信できるよりも迅速に生成され、キューが蓄積されます。
Network congestion can occur when transport behavior is network-driven or application-driven. For example, while a single NAS may not send substantial AAA traffic, many NASes may communicate with a single AAA proxy or server. As a result, routers close to a heavily loaded proxy or server may experience congestion, even though traffic from each individual NAS is light. Such "convergent congestion" can result in dropped packets in routers near the AAA server, or even within the AAA server itself.
輸送の動作がネットワーク駆動型またはアプリケーション駆動型である場合、ネットワークの輻輳が発生する可能性があります。たとえば、単一のNASはかなりのAAAトラフィックを送信できない場合がありますが、多くのNaseが単一のAAAプロキシまたはサーバーと通信する場合があります。その結果、個々のNASからのトラフィックが軽いにもかかわらず、重度のロードされたプロキシまたはサーバーに近いルーターは輻輳を発生する場合があります。このような「収束輻輳」は、AAAサーバーの近くのルーター、またはAAAサーバー自体内でさえ削除されたパケットを削除する可能性があります。
Let us consider what happens when 10,000 48-ports NASes, each with an average session time of 20 minutes, are configured with the same AAA agent or server. The unfortunate proxy or server would receive 400 authentication/authorization requests/second and an equivalent number of accounting requests. For 1000 octet requests, this would generate 6.4 Mbps of incoming traffic at the AAA agent or server.
平均セッション時間が20分の10,000 48ポートNaseが同じAAAエージェントまたはサーバーで構成されている場合、何が起こるかを考えてみましょう。不幸なプロキシまたはサーバーは、400の認証/承認リクエスト/秒と同等の数の会計リクエストを受け取ります。1000個のオクテットリクエストの場合、これにより、AAAエージェントまたはサーバーで6.4 Mbpsの入力トラフィックが生成されます。
While this transaction load is within the capabilities of the fastest AAA agents and servers, implementations exist that cannot handle such a high load. Thus high queuing delays and/or dropped packets may be experienced at the agent or server, even if routers on the path are not congested. Thus, a well designed AAA protocol needs to be able to handle congestion occurring at the AAA server, as well as congestion experienced within the network.
このトランザクション負荷は、最速のAAAエージェントとサーバーの機能内にありますが、このような高負荷を処理できない実装が存在します。したがって、パス上のルーターが混雑していなくても、エージェントまたはサーバーで高いキューイングの遅延および/またはドロップされたパケットが経験される場合があります。したがって、適切に設計されたAAAプロトコルは、AAAサーバーで発生する混雑と、ネットワーク内で経験されたうっ血を処理できる必要があります。
Where TCP [RFC793] is used as the transport, AAA implementations will experience very slow fail over times if they wait until a TCP connection times out before resending on another connection. This is not an issue for SCTP [RFC2960], which supports endpoint and path failure detection. As described in section 8 of [RFC2960], when the number of retransmissions exceeds the maximum ("Association.Max.Retrans"), the peer endpoint is considered unreachable, the association enters the CLOSED state, and the failure is reported to the application. This enables more rapid failure detection.
TCP [RFC793]がトランスポートとして使用される場合、AAAの実装は、TCP接続が別の接続に留まる前に時間が出るまで待つと非常に遅い失敗を経験します。これは、EndPointとPATH障害検出をサポートするSCTP [RFC2960]の問題ではありません。[RFC2960]のセクション8で説明されているように、再送信の数が最大（ "Association.max.retrans"）を超えると、ピアエンドポイントは到達不可能と見なされ、関連付けは閉じた状態に入り、障害はアプリケーションに報告されます。これにより、より迅速な障害検出が可能になります。
AAA protocol messages are often smaller than the maximum segment size (MSS). While exceptions occur when certificate-based authentication messages are issued or where a low path MTU is found, typically AAA protocol messages are less than 1000 octets. Therefore, when using TCP [RFC793], the total packet count and associated network overhead can be reduced by combining multiple AAA messages within a single packet.
AAAプロトコルメッセージは、多くの場合、最大セグメントサイズ（MSS）よりも小さくなります。証明書ベースの認証メッセージが発行された場合、または低パスMTUが見つかった場合に例外が発生しますが、通常、AAAプロトコルメッセージは1000オクテット未満です。したがって、TCP [RFC793]を使用する場合、単一のパケット内で複数のAAAメッセージを組み合わせることで、合計パケットカウントと関連するネットワークオーバーヘッドを減らすことができます。
Where AAA runs over TCP and transport behavior is network-driven, such as after a reboot when many users login simultaneously, or many stored accounting records need to be sent, the Nagle algorithm will result in "transport layer batching" of AAA messages. While this does not reduce the work required by the application in parsing packets and responding to the messages, it does reduce the number of packets processed by routers along the path. The Nagle algorithm is not used with SCTP.
AAAがTCPで実行され、多くのユーザーが同時にログインしたときに再起動した後、多くの保存された会計記録を送信する必要があるなど、NagleアルゴリズムはAAAメッセージの「トランスポート層バッチ」になります。これは、パケットの解析やメッセージに応答するアプリケーションに必要な作業を削減するものではありませんが、パスに沿ってルーターによって処理されるパケットの数を減らします。NagleアルゴリズムはSCTPで使用されません。
Where AAA transport is application-driven, the NAS will typically receive a reply from the home server prior to having another request to send. This implies, for example, that accounting requests will typically be sent individually rather than being batched by the transport layer. As a result, within the application-driven regime, the Nagle algorithm [RFC896] is ineffective.
AAAトランスポートがアプリケーション駆動型である場合、NASは通常、別のリクエストを送信する前にホームサーバーから返信を受け取ります。これは、たとえば、会計リクエストが通常、輸送層によってバッチされるのではなく、個別に送信されることを意味します。その結果、アプリケーション駆動型体制内では、ナグルアルゴリズム[RFC896]は効果がありません。
Since the RADIUS [RFC2865] Identifier field is a single octet, a maximum of 256 requests can be in progress between two endpoints described by a 5-tuple: (Client IP address, Client port, UDP, Server IP address, Server port). In order to get around this limitation, RADIUS clients have utilized more than one sending port, sometimes even going to the extreme of using a different UDP source port for each NAS port.
半径[RFC2865]識別子フィールドは単一のオクテットであるため、5タプルで記述された2つのエンドポイント間で最大256のリクエストが進行する可能性があります（クライアントIPアドレス、クライアントポート、UDP、サーバーIPアドレス、サーバーポート）。この制限を回避するために、RADIUSクライアントは複数の送信ポートを利用しており、各NASポートに異なるUDPソースポートを使用することも極端に進むことさえあります。
Were this behavior to be extended to AAA protocols operating over reliable transport, the result would be multiplication of the effective slow-start ramp-up by the number of connections. For example, if a AAA client had ten connections open to a AAA agent, and used a per-connection initial window [RFC3390] of 2, then the effective initial window would be 20. This is inappropriate, since it would permit the AAA client to send a large burst of packets into the network.
この動作は、信頼できる輸送上で動作するAAAプロトコルに拡張される場合、結果は効果的なスロースタートランプアップの接続の数を増殖させます。たとえば、AAAクライアントがAAAエージェントに10の接続を開いており、2の接続ごとの初期ウィンドウ[RFC3390]を使用した場合、有効な初期ウィンドウは20になります。これは、AAAクライアントが許可されるため、不適切です。大きなパケットをネットワークに送信するには。
Where a AAA client maintains connections to multiple AAA agents or servers, and where failover/failback or connection load balancing is supported, it is possible for multiple agents or servers to receive duplicate copies of the same transaction. A transaction may be sent on another connection before expiration of the "time wait" interval necessary to guarantee that all packets sent on the original connection have left the network. Therefore it is conceivable that transactions sent on the alternate connection will arrive before those sent on the failed connection. As a result, AAA agents and servers MUST be prepared to handle duplicates, and MUST assume that duplicates can arrive on any connection.
AAAクライアントが複数のAAAエージェントまたはサーバーへの接続を維持し、フェールオーバー/フェールバックまたは接続ロードバランスがサポートされている場合、複数のエージェントまたはサーバーが同じトランザクションの重複コピーを受信する可能性があります。元の接続で送信されたすべてのパケットがネットワークを去ったことを保証するために必要な「時間待機」間隔の有効期限が切れる前に、別の接続にトランザクションを送信することができます。したがって、代替接続に送信されたトランザクションが、失敗した接続に送信されるものが届く前に到着すると考えられます。その結果、AAAエージェントとサーバーは、重複を処理するために準備する必要があり、重複が任意の接続に到着できると仮定する必要があります。
For example, in billing, it is necessary to be able to weed out duplicate accounting records, based on the accounting session-id, event-timestamp and NAS identification information. Where authentication requests are always idempotent, the resultant duplicate responses from multiple servers will presumably be identical, so that little harm will result.
たとえば、請求では、会計セッション-ID、イベント - タンプン、NASの識別情報に基づいて、重複する会計記録を除草できる必要があります。認証要求が常にiDempotentである場合、結果の結果として複数のサーバーからの重複した応答はおそらく同一であるため、害はほとんどありません。
However, there are situations where the response to an authentication request will depend on a previously established state, such as when simultaneous usage restrictions are being enforced. In such cases, authentication requests will not be idempotent. For example, while an initial request might elicit an Accept response, a duplicate request might elicit a Reject response from another server, if the user were already presumed to be logged in, and only one simultaneous session were permitted. In these situations, the AAA client might receive both Accept and Reject responses to the same duplicate request, and the outcome will depend on which response arrives first.
ただし、認証要求に対する応答が、同時使用の制限が施行されている場合など、以前に確立された状態に依存する状況があります。そのような場合、認証要求は等ではありません。たとえば、初期リクエストは受け入れの応答を引き出す可能性がありますが、ユーザーがすでにログインしていると推定されている場合、1つの同時セッションのみが許可されている場合、複製リクエストは別のサーバーからの拒否応答を引き出す可能性があります。これらの状況では、AAAクライアントは、同じ重複リクエストに対する応答を受け入れ、拒否することの両方を受け取る可能性があり、結果はどの応答が最初に到着するかによって異なります。
Congestion control principles [Congest],[RFC2914] require the ability of a transport protocol to respond effectively to congestion, as sensed via increasing delays, packet loss, or explicit congestion notification.
輻輳制御原則[Commest]、[RFC2914]は、遅延、パケットの損失、または明示的な混雑通知を介して感知されるように、輸送プロトコルが混雑に効果的に対応する能力を必要とします。
With network-driven applications, it is possible to respond to congestion on a timescale comparable to the round-trip time (RTT).
ネットワーク駆動型アプリケーションでは、往復時間（RTT）に匹敵するタイムスケールの混雑に応答することができます。
However, with AAA protocols, the time between sends may be longer than the RTT, so that the network conditions can not be assumed to persist between sends. For example, the congestion window may grow during a period in which congestion is being experienced because few packets are sent, limiting the opportunity for feedback. Similarly, after congestion is detected, the congestion window may remain small, even though the network conditions that existed at the time of congestion no longer apply by the time when the next packets are sent. In addition, due to the low sampling interval, estimates of RTT and RTO made via the procedure described in [RFC2988] may become invalid.
ただし、AAAプロトコルでは、送信中の時間はRTTよりも長くなる可能性があるため、ネットワーク条件を送信中に持続すると想定できません。たとえば、輻輳ウィンドウは、送信されたパケットがほとんどなく、フィードバックの機会を制限するため、輻輳が発生している期間中に成長する可能性があります。同様に、輻輳が検出された後、輻輳ウィンドウは、次のパケットが送信されるまでに輻輳時に存在していたネットワーク条件がもはや適用されなくなります。さらに、サンプリング間隔が低いため、[RFC2988]で説明されている手順を介して作成されたRTTおよびRTOの推定値が無効になる可能性があります。
When congestion window validation [RFC2861] is implemented, the result is that AAA protocols operate much of the time in slow-start with an initial congestion window set to 1 or 2, depending on the implementation [RFC3390]. This implies that AAA protocols gain little benefit from the windowing features of reliable transport.
輻輳ウィンドウの検証[RFC2861]が実装されると、AAAプロトコルは、実装[RFC3390]に応じて、初期輻輳ウィンドウが1または2に設定されたスロースタートで多くの時間を動作させます。これは、AAAプロトコルが信頼できる輸送のウィンドウ機能からほとんど利益を得ることがないことを意味します。
Since the congestion window is so small, it is generally not possible to receive enough duplicate ACKs (3) to trigger fast re-transmit. In addition, since AAA traffic is two-way, ACKs including data will not count as part of the duplicate ACKs necessary to trigger fast re-transmit. As a result, dropped packets will require a retransmission timeout (RTO).
輻輳ウィンドウは非常に小さいため、一般に、高速再送信をトリガーするのに十分な複製ACK（3）を受け取ることはできません。さらに、AAAトラフィックは双方向であるため、データを含むACKは、高速再送信をトリガーするために必要な重複ACKの一部としてカウントされません。その結果、ドロップされたパケットには再送信タイムアウト（RTO）が必要になります。
The law of conservation of packets [Congest] suggests that a client should not send another packet into the network until it can be reasonably sure that a packet has exited the network on the same path. In the case of a AAA client, the law suggests that it should not retransmit to the same server or choose another server until it can be reasonably sure that a packet has exited the network on the same path. If the client advances the window as responses arrive, then the client will "self clock", adjusting its transmission rate to the available bandwidth.
パケットの保存法[Commest]は、パケットが同じパスでネットワークを終了することを合理的に確実にするまで、クライアントがネットワークに別のパケットを送信してはならないことを示唆しています。AAAクライアントの場合、法律は、パケットが同じパスでネットワークを終了することを合理的に確実にするまで、同じサーバーに再送信したり、別のサーバーを選択したりしないでください。クライアントが応答が到着するとウィンドウを前進させると、クライアントは「セルフクロック」になり、送信速度を利用可能な帯域幅に調整します。
While a AAA client using a reliable transport such as TCP [RFC793] or SCTP [RFC2960] will self-clock when communicating directly with a AAA-server, end-to-end self-clocking is not assured when AAA agents are present.
TCP [RFC793]やSCTP [RFC2960]などの信頼できるトランスポートを使用しているAAAクライアントは、AAAサーバーと直接通信するときにセルフクロックしますが、AAAエージェントが存在する場合、エンドツーエンドのセルフクロックは保証されません。
As described in the Appendix, AAA agents include Relays, Proxies, Re-directs, Store and Forward proxies, and Transport proxies. Of these agents, only Transport proxies and Re-directs provide a direct transport connection between the AAA client and server, allowing end-to-end self-clocking to occur.
付録に記載されているように、AAAエージェントにはリレー、プロキシ、リダイレクト、保存および転送プロキシ、輸送プロキシが含まれます。これらのエージェントのうち、輸送プロキシとリダイレクトのみがAAAクライアントとサーバーの間の直接的な輸送接続を提供し、エンドツーエンドの自己閉鎖が発生することを可能にします。
With Relays, Proxies or Store and Forward proxies, two separate and de-coupled transport connections are used. One connection operates between the AAA client and agent, and another between the agent and server. Since the two transport connections are de-coupled, transport layer ACKs do not flow end-to-end, and self-clocking does not occur.
リレー、プロキシ、または保存および転送プロキシを使用すると、2つの別々の分離された輸送接続が使用されます。1つの接続は、AAAクライアントとエージェントの間で動作し、別の接続はエージェントとサーバーの間で動作します。2つの輸送接続が分離されているため、輸送層のアックはエンドツーエンドでは流れず、セルフクロックは発生しません。
For example, consider what happens when the bottleneck exists between a AAA Relay and a AAA server. Self-clocking will occur between the AAA client and AAA Relay, causing the AAA client to adjust its sending rate to the rate at which transport ACKs flow back from the AAA Relay. However, since this rate is higher than the bottleneck bandwidth, the overall system will not self-clock.
たとえば、AAAリレーとAAAサーバーの間にボトルネックが存在する場合に何が起こるかを検討してください。AAAクライアントとAAAリレーの間でセルフクロックが発生し、AAAクライアントが送信速度をAAAリレーから戻すレートに調整します。ただし、このレートはボトルネックの帯域幅よりも高いため、システム全体は自己遮断されません。
Since there is no direct transport connection between the AAA client and AAA server, the AAA client does not have the ability to estimate end-to-end transport parameters and adjust its sending rate to the bottleneck bandwidth between the Relay and server. As a result, the incoming rate at the AAA Relay can be higher than the rate at which packets can be sent to the AAA server.
AAAクライアントとAAAサーバーの間に直接的な輸送接続がないため、AAAクライアントはエンドツーエンドの輸送パラメーターを推定し、送信率をリレーとサーバーの間のボトルネック帯域幅に調整する機能を持っていません。その結果、AAAリレーの着信レートは、パケットをAAAサーバーに送信できるレートよりも高くなります。
In this case, the end-to-end performance will be determined by details of the agent implementation. In general, the end-to-end transport performance in the presence of Relays, Proxies or Store and Forward proxies will always be worse in terms of delay and packet loss than if the AAA client and server were communicating directly.
この場合、エンドツーエンドのパフォーマンスは、エージェントの実装の詳細によって決定されます。一般に、AAAクライアントとサーバーが直接通信している場合よりも、リレー、プロキシ、またはストアおよびフォワードプロキシの存在下でのエンドツーエンドの輸送パフォーマンスは、遅延とパケット損失の点で常に悪化します。
For example, if the agent operates with a large receive buffer, it is possible that a large queue will develop on the receiving side, since the AAA client is able to send packets to the AAA agent more rapidly than the agent can send them to the AAA server. Eventually, the buffer will overflow, causing wholesale packet loss as well as high delay.
たとえば、エージェントが大きな受信バッファーで動作する場合、AAAクライアントはエージェントがエージェントに送信できるよりも迅速にパケットを送信できるため、受信側に大きなキューが発生する可能性があります。AAAサーバー。最終的に、バッファーはオーバーフローし、卸売パケット損失と高い遅延を引き起こします。
Methods to induce fine-grained coupling between the two transport connections are difficult to implement. One possible solution is for the AAA agent to operate with a receive buffer that is no larger than its send buffer. If this is done, "back pressure" (closing of the receive window) will cause the agent to reduce the AAA client sending rate when the agent send buffer fills. However, unless multiple connections exist between the AAA client and AAA agent, closing of the receive window will affect all traffic sent by the AAA client, even traffic destined to AAA servers where no bottleneck exists. Since multiple connections between a AAA client and agent result in multiplication of the effective slow-start ramp rate, this is not recommended. As a result, use of "back pressure" cannot enable individual AAA client-server conversations to self-clock, and this technique appears impractical for use in AAA.
2つの輸送接続の間に細粒カップリングを誘導する方法を実装することは困難です。考えられる解決策の1つは、AAAエージェントが送信バッファーよりも大きくない受信バッファーで動作することです。これが行われた場合、「バックプレッシャー」（受信ウィンドウの閉鎖）により、エージェントがバッファーの塗りつぶしを送信すると、エージェントがAAAクライアントの送信レートを減らします。ただし、AAAクライアントとAAAエージェントの間に複数の接続が存在しない限り、受信ウィンドウを閉じることで、AAAクライアントが送信したすべてのトラフィックが影響します。AAAクライアントとエージェントの間の複数の接続により、効果的なスロースタートランプレートが増殖するため、これは推奨されません。その結果、「背圧」を使用することは、個々のAAAクライアントサーバーの会話をセルフクロックにすることを可能にすることができず、この手法はAAAでの使用が非現実的であると思われます。
As described in Appendix B, ACKs may comprise as much as half of the traffic generated in a AAA exchange. This occurs because AAA conversations are typically application-driven, and therefore there is frequently not enough traffic to enable ACK piggybacking. As a result, AAA protocols running over TCP or SCTP transport may experience a doubling of traffic as compared with implementations utilizing UDP transport.
付録Bで説明されているように、ACKSはAAA取引所で生成されたトラフィックの半分を含む場合があります。これは、AAAの会話が通常アプリケーション駆動型であるために発生します。したがって、ACKピギーバックを有効にするのに十分なトラフィックがないことがよくあります。その結果、TCPまたはSCTPトランスポートを介して実行されるAAAプロトコルは、UDP輸送を利用した実装と比較して、トラフィックの倍増を発生する可能性があります。
It is typically not possible to address this issue via the sockets API. ACK parameters (such as the value of the delayed ACK timer) are typically fixed by TCP and SCTP implementations and are therefore not tunable by the application.
通常、Sockets APIを介してこの問題に対処することはできません。ACKパラメーター（遅延ACKタイマーの値など）は通常、TCPおよびSCTP実装によって固定されているため、アプリケーションでは調整できません。
RADIUS failover implementations are typically based on the concept of primary and secondary servers, in which all traffic flows to the primary server unless it is unavailable. However, the failover algorithm was not specified in [RFC2865] or [RFC2866]. As a result, RADIUS failover implementations vary in quality, with some failing over prematurely, violating the law of "conservation of packets".
RADIUSフェールオーバー実装は通常、プライマリサーバーとセカンダリサーバーの概念に基づいており、すべてのトラフィックが利用できない限り、プライマリサーバーに流れます。ただし、フェイルオーバーアルゴリズムは[RFC2865]または[RFC2866]で指定されていません。その結果、RADIUSフェールオーバーの実装は品質が異なり、一部は時期尚早に失敗し、「パケットの保存」の法則に違反しています。
Where a Relay, Proxy or Store and Forward proxy is present, the AAA client has no direct connection to a AAA server, and is unable to estimate the end-to-end transport parameters. As a result, a AAA client awaiting an application-layer response from the server has no transport-based mechanism for determining an appropriate failover timer.
リレー、プロキシ、またはストア、フォワードプロキシが存在する場合、AAAクライアントはAAAサーバーに直接接続されておらず、エンドツーエンドの輸送パラメーターを推定できません。その結果、サーバーからのアプリケーション層応答を待っているAAAクライアントには、適切なフェイルオーバータイマーを決定するための輸送ベースのメカニズムはありません。
For example, if the path between the AAA agent and server includes a high delay link, or if the AAA server is very heavily loaded, it is possible that the NAS will failover to another agent while packets are still in flight. This violates the principle of "conservation of packets", since the AAA client will inject additional packets into the network before having evidence that a previously sent packet has left the network. Such behavior can result in a worse situation on an already congested link, resulting in congestive collapse [Congest].
たとえば、AAAエージェントとサーバーの間のパスに高い遅延リンクが含まれている場合、またはAAAサーバーが非常に重くロードされている場合、Packetがまだ飛行中にNASが別のエージェントにフェイルオーバーする可能性があります。これは「パケットの保存」の原則に違反します。これは、AAAクライアントが以前に送信されたパケットがネットワークを離れたという証拠を持つ前に、追加のパケットをネットワークに挿入するためです。このような行動は、すでに混雑しているリンクの状況が悪化する可能性があり、うっ血性崩壊[うっ血]をもたらします。
Head of line blocking occurs during periods of packet loss where the time between sends is shorter than the re-transmission timeout value (RTO). In such situations, packets back up in the send queue until the lost packet can be successfully re-transmitted. This can be an issue for SCTP when using ordered delivery over a single stream, and for TCP.
ラインブロッキングのヘッドは、送信間の時間が再送信タイムアウト値（RTO）よりも短いパケット損失の期間中に発生します。このような状況では、失われたパケットが正常に再送信されるまで、送信キューにパケットをバックアップします。これは、単一のストリームで順序付けられた配信を使用した場合、およびTCPにSCTPの問題になる可能性があります。
Head of line blocking is typically an issue only on larger NASes. For example, a 48-port NAS with an average inter-packet spacing of 25 seconds is unlikely to have an RTO greater than this, unless severe packet loss has been experienced. However, a 2048-port NAS with an average inter-packet spacing of 293 ms may experience head-of-line blocking since the inter-packet spacing is less than the minimum RTO value of 1 second [RFC2988].
通常、ラインブロッキングのヘッドは、より大きなnaseのみの問題です。たとえば、25秒の平均パケット間間隔を持つ48ポートNASは、重度のパケット損失が発生しない限り、RTOをこれよりも大きくする可能性は低いです。ただし、293ミリ秒の平均パケット間間隔を持つ2048ポートNASは、パケット間間隔が1秒の最小RTO値[RFC2988]よりも少ないため、頭のブロックを経験する可能性があります。
In order to lessen queuing delays and address head of line blocking, a AAA implementation may wish to load balance between connections to multiple destinations. While it is possible to employ dynamic load balancing techniques, this level of sophistication may not be required. In many situations, adequate reliability and load balancing can be achieved via static load balancing, where traffic is distributed between destinations based on static "weights".
キューイングの遅延を軽減し、ラインブロッキングのヘッドに対処するために、AAAの実装は、複数の宛先への接続間のバランスをロードすることを望む場合があります。動的な負荷分散技術を採用することは可能ですが、このレベルの洗練度は必要ない場合があります。多くの状況では、静的な負荷分散を介して適切な信頼性と負荷分散を介して実現できます。そこでは、静的な「重み」に基づいてトラフィックが宛先間に分布しています。
In order to address AAA transport issues, it is recommended that AAA protocols make use of standards track as well as experimental techniques. More details are provided in the sections that follow.
AAA輸送の問題に対処するために、AAAプロトコルが標準トラックと実験的手法を利用することをお勧めします。詳細については、以下のセクションに記載されています。
AAA Servers MUST support TCP and SCTP. AAA clients SHOULD support SCTP, but MUST support TCP if SCTP is not available. As support for SCTP improves, it is possible that SCTP support will be required on clients at some point in the future. AAA agents inherit all the obligations of Servers with respect to transport support.
AAAサーバーは、TCPとSCTPをサポートする必要があります。AAAクライアントはSCTPをサポートする必要がありますが、SCTPが利用できない場合はTCPをサポートする必要があります。SCTPのサポートが向上するにつれて、将来のある時点でSCTPサポートがクライアントに必要である可能性があります。AAAエージェントは、輸送サポートに関してサーバーのすべての義務を継承します。
While AAA protocols typically operate in the application-driven regime, there are circumstances in which they are network driven. For example, where an NAS reboots, or where connectivity is restored between an NAS and a AAA agent, it is possible that multiple packets will be available for sending.
AAAプロトコルは通常、アプリケーション主導の体制で動作しますが、ネットワーク駆動型の状況があります。たとえば、NASが再起動する場合、またはNASとAAAエージェントの間で接続性が回復する場合、複数のパケットが送信できる可能性があります。
As a result, there are circumstances where the transport-layer batching provided by the Nagle Algorithm (12) is useful, and as a result, AAA implementations running over TCP MUST enable the Nagle algorithm, [RFC896]. The Nagle algorithm is not used with SCTP.
その結果、Nagleアルゴリズム（12）によって提供される輸送層バッチが有用である状況があり、その結果、TCPを介して実行されるAAA実装は、Nagleアルゴリズム[RFC896]を有効にする必要があります。NagleアルゴリズムはSCTPで使用されません。
AAA protocols SHOULD use only a single persistent connection between a AAA client and a AAA agent or server. They SHOULD provide for pipelining of requests, so that more than one request can be in progress at a time. In order to minimize use of inactive connections in roaming situations, a AAA client or agent MAY bring down a connection to a AAA agent or server if the connection has been unutilized (discounting the watchdog) for a certain period of time, which MUST NOT be less than BRINGDOWN_INTERVAL (5 minutes).
AAAプロトコルは、AAAクライアントとAAAエージェントまたはサーバーの間に1つの永続的な接続のみを使用する必要があります。一度に複数のリクエストが進行できるように、リクエストのパイプラインを提供する必要があります。ローミングの状況での非アクティブな接続の使用を最小限に抑えるために、AAAクライアントまたはエージェントは、接続が一定期間使用されていない（ウォッチドッグを割り当てる）場合、AAAエージェントまたはサーバーへの接続を削減する場合があります。brinddown_interval（5分）未満。
While a AAA client/agent SHOULD only use a single persistent connection to a given AAA agent or server, it MAY have connections to multiple AAA agents or servers. A AAA client/agent connected to multiple agents/servers can treat them as primary/secondary or balance load between them.
AAAクライアント/エージェントは、特定のAAAエージェントまたはサーバーへの単一の永続的な接続のみを使用する必要がありますが、複数のAAAエージェントまたはサーバーへの接続がある場合があります。複数のエージェント/サーバーに接続されたAAAクライアント/エージェントは、それらをプライマリ/セカンダリまたはバランス負荷として扱うことができます。
In order to enable AAA implementations to more quickly detect transport and application-layer failures, AAA protocols MUST support an application layer watchdog message.
AAAの実装が輸送およびアプリケーションレイヤーの障害をより迅速に検出できるようにするために、AAAプロトコルはアプリケーションレイヤーウォッチドッグメッセージをサポートする必要があります。
The application layer watchdog message enables failover from a peer that has failed, either because it is unreachable or because its applications functions have failed. This is distinct from the purpose of the SCTP heartbeat, which is to enable failover between interfaces. The SCTP heartbeat may enable a failover to another path to reach the same server, but does not address the situation where the server system or the application service has failed. Therefore both mechanisms MAY be used together.
アプリケーションレイヤーウォッチドッグメッセージは、到達不能であるか、アプリケーション機能が失敗したために、失敗したピアからのフェールオーバーを有効にします。これは、SCTPハートビートの目的とは異なります。これは、インターフェイス間のフェールオーバーを有効にするためです。SCTPハートビートは、別のパスへのフェイルオーバーが同じサーバーに到達するために有効になる可能性がありますが、サーバーシステムまたはアプリケーションサービスが失敗した状況に対処しません。したがって、両方のメカニズムを一緒に使用できます。
The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection. It operates on all open connections and is used to suspend and eventually close connections that are experiencing difficulties. The watchdog is also used to re-open and validate connections that have returned to health. The watchdog may be utilized either within primary/secondary or load balancing configurations. However, it is not intended as a cluster heartbeat mechanism.
ウォッチドッグは、AAAクライアントまたはエージェントが別の接続で再送信するタイミングを決定できるようにするために使用されます。それはすべてのオープン接続で動作し、困難を経験している接続を停止し、最終的に閉じるために使用されます。ウォッチドッグは、健康に戻った接続を再開および検証するためにも使用されます。ウォッチドッグは、プライマリ/セカンダリまたはロードバランシング構成のいずれかで使用できます。ただし、クラスターハートビートメカニズムとして意図されていません。
The application layer watchdog is designed to detect failures of the immediate peer, and not to be affected by failures of downstream proxies or servers. This prevents instability in downstream AAA components from propagating upstream. While the receipt of any AAA Response from a peer is taken as evidence that the peer is up, lack of a Response is insufficient to conclude that the peer is down. Since the lack of Response may be the result of problems with a downstream proxy or server, only after failure to respond to the watchdog message can it be determined that the peer is down.
アプリケーションレイヤーウォッチドッグは、即時のピアの障害を検出するように設計されており、ダウンストリームプロキシまたはサーバーの障害の影響を受けません。これにより、下流のAAAコンポーネントの不安定性が上流の伝播を防ぎます。ピアからのAAA応答の受領は、ピアが上がっているという証拠と見なされますが、応答の欠如は、ピアがダウンしていると結論付けるには不十分です。応答の欠如は、下流のプロキシまたはサーバーの問題の結果である可能性があるため、ウォッチドッグメッセージに応答しなかった後にのみ、ピアがダウンしていると判断できます。
Since the watchdog algorithm takes any AAA Response into account in determining peer liveness, decreases in the watchdog timer interval do not significantly increase the level of watchdog traffic on heavily loaded networks. This is because watchdog messages do not need to be sent where other AAA Response traffic serves as a constant reminder of peer liveness. Watchdog traffic only increases when AAA traffic is light, and therefore a AAA Response "signal" is not present. Nevertheless, decreasing the timer interval TWINIT does increase the probability of false failover significantly, and so this decision should be made with care.
ウォッチドッグアルゴリズムは、ピアリンシーを決定する際にAAA応答を考慮しているため、ウォッチドッグタイマー間隔の減少は、重度のロードされたネットワークのウォッチドッグトラフィックのレベルを大幅に上げることはありません。これは、他のAAA応答トラフィックがピアライデンスの絶え間ないリマインダーとして機能する場合、ウォッチドッグメッセージを送信する必要がないためです。ウォッチドッグのトラフィックは、AAAトラフィックが軽い場合にのみ増加するため、AAA応答「信号」が存在しません。それにもかかわらず、タイマー間隔のTwinitを減らすと、誤ったフェイルオーバーの確率が大幅に増加するため、この決定は注意して行う必要があります。
The watchdog behavior is controlled by an algorithm defined in this section. This algorithm is appropriate for use either within primary/secondary or load balancing configurations. Implementations SHOULD implement this algorithm, which operates as follows:
ウォッチドッグの動作は、このセクションで定義されているアルゴリズムによって制御されます。このアルゴリズムは、プライマリ/セカンダリまたは負荷分散構成内で使用するのに適しています。実装は、次のように動作するこのアルゴリズムを実装する必要があります。
[1] Watchdog behavior is controlled by a single timer (Tw). The initial value of Tw, prior to jittering is Twinit. The default value of Twinit is 30 seconds. This value was selected because it minimizes the probability that failover will be initiated due to a routing flap, as noted in [Paxson].
[1] ウォッチドッグの動作は、単一のタイマー（TW）によって制御されます。ジッタリングの前のTWの初期値はTwinitです。Twinitのデフォルト値は30秒です。[Paxson]に記載されているように、ルーティングフラップのためにフェイルオーバーが開始される可能性を最小限に抑えるため、この値が選択されました。
While Twinit MAY be set as low as 6 seconds (not including jitter), it MUST NOT be set lower than this. Note that setting such a low value for Twinit is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts.
Twinitは6秒の低さ（ジッターを含まない）に設定される場合がありますが、これよりも低く設定してはなりません。Twinitのこのような低い値を設定すると、重複の確率が増加する可能性が高く、スプリアスフェールオーバーとフェールバックの試みが増加する可能性が高いことに注意してください。
In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, each time the watchdog interval is calculated with a jitter by using the Twinit value and randomly adding a value drawn between -2 and 2 seconds. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random, generated by a PRNG seeded as per [RFC1750].
分散システム間で固定タイマーで発生する可能性のある同期の動作を回避するために、Twinit値を使用し、-2〜2秒の間に描画された値をランダムに追加することにより、ウォッチドッグ間隔がジッターで計算されるたびに。ジッターを作成するための代替計算を使用する場合があります。これらは、[RFC1750]に従って播種されたPRNGによって生成される擬似ランダムでなければなりません。
[2] When any AAA message is received, Tw is reset. This need not be a response to a watchdog request. Receiving a watchdog response from a peer constitutes activity, and Tw should be reset. If the watchdog timer expires and no watchdog response is pending, then a watchdog message is sent. On sending a watchdog request, Tw is reset.
[2] AAAメッセージが受信されると、TWがリセットされます。これは、ウォッチドッグリクエストへの応答である必要はありません。ピアからウォッチドッグの応答を受信することはアクティビティを構成し、TWをリセットする必要があります。ウォッチドッグタイマーが期限切れになり、ウォッチドッグの応答が保留されていない場合、ウォッチドッグメッセージが送信されます。ウォッチドッグリクエストを送信すると、TWはリセットされます。
Watchdog packets are not retransmitted by the AAA protocol, since AAA protocols run over reliable transports that will handle all retransmissions internally. As a result, a watchdog request is only sent when there is no watchdog response pending.
AAAプロトコルは、すべての再送信を内部で処理する信頼できるトランスポートを実行するため、ウォッチドッグパケットはAAAプロトコルによって再送信されません。その結果、ウォッチドッグリクエストは、監視員の応答が保留されていない場合にのみ送信されます。
[3] If the watchdog timer expires and a watchdog response is pending, then failover is initiated. In order for a AAA client or agent to perform failover procedures, it is necessary to maintain a pending message queue for a given peer. When an answer message is received, the corresponding request is removed from the queue. The Hop-by-Hop Identifier field MAY be used to match the answer with the queued request.
[3] ウォッチドッグタイマーが期限切れになり、ウォッチドッグの応答が保留されている場合、フェールオーバーが開始されます。AAAクライアントまたはエージェントがフェールオーバー手順を実行するためには、特定のピアの保留中のメッセージキューを維持する必要があります。回答メッセージが受信されると、対応するリクエストがキューから削除されます。ホップバイホップ識別子フィールドを使用して、回答をキューに合わせたリクエストと一致させることができます。
When failover is initiated, all messages in the queue are sent to an alternate agent, if available. Multiple identical requests or answers may be received as a result of a failover. The combination of an end-to-end identifier and the origin host MUST be used to identify duplicate messages.
フェールオーバーが開始されると、キュー内のすべてのメッセージは、利用可能な場合は代替エージェントに送信されます。フェールオーバーの結果、複数の同一のリクエストまたは回答が受信される場合があります。エンドツーエンド識別子とOriginホストの組み合わせを使用して、重複メッセージを識別する必要があります。
Note that where traffic is heavy, the application layer watchdog can take as long as 2Tw to determine that a peer has gone down. For peers receiving a high volume of AAA Requests, AAA Responses will continually reset the timer, so that after a failure it will take Tw for the lack of traffic to be noticed, and for the watchdog message to be sent. Another Tw will elapse before failover is initiated.
トラフィックが重い場合、アプリケーションレイヤーウォッチドッグは、ピアがダウンしたことを判断するために2TWの長い時間を取ることができることに注意してください。大量のAAAリクエストを受け取ったピアの場合、AAA応答はタイマーを継続的にリセットするため、障害後にトラフィックの不足に気付くにはTWがかかり、ウォッチドッグメッセージが送信されます。フェールオーバーが開始される前に、別のTWが経過します。
On a lightly loaded network without much AAA Response traffic, the watchdog timer will typically expire without being reset, so that a watchdog response will be outstanding and failover will be initiated after only a single timer interval has expired.
AAA応答トラフィックのない軽くロードされたネットワークでは、ウォッチドッグタイマーは通常、リセットされずに期限切れになります。そのため、ウォッチドッグの応答は未払いになり、単一のタイマー間隔のみが期限切れになった後にフェールオーバーが開始されます。
[4] The client MUST NOT close the primary connection until the primary's watchdog timer has expired at least twice without a response (note that the watchdog is not sent a second time, however). Once this has occurred, the client SHOULD cause a transport reset or close to be done on the connection.
[4] クライアントは、プライマリのウォッチドッグタイマーが応答せずに少なくとも2回期限切れになるまでプライマリ接続を閉じてはなりません（ただし、ウォッチドッグは2度目に送信されないことに注意してください）。これが発生したら、クライアントは接続でトランスポートリセットまたは近くに行われる必要があります。
Once the primary connection has failed, subsequent requests are sent to the alternate server until the watchdog timer on the primary connection is reset.
プライマリ接続が失敗すると、プライマリ接続のウォッチドッグタイマーがリセットされるまで、後続のリクエストが代替サーバーに送信されます。
Suspension of the primary connection prevents flapping between primary and alternate connections, and ensures that failover behavior remains consistent. The application may not receive a response to the watchdog request message due to a connectivity problem, in which case a transport layer ACK will not have been received, or the lack of response may be due to an application problem. Without transport layer visibility, the application is unable to tell the difference, and must behave conservatively.
プライマリ接続の一時停止は、プライマリ接続と代替接続の間の羽ばたきを防ぎ、フェイルオーバー動作が一貫していることを保証します。アプリケーションは、接続性の問題のためにウォッチドッグ要求メッセージへの応答を受け取らない場合があります。その場合、輸送層ACKは受信されませんでした。または、応答の欠如がアプリケーションの問題によるものである可能性があります。輸送層の可視性がなければ、アプリケーションは違いを伝えることができず、控えめに動作する必要があります。
In situations where no transport layer ACK is received on the primary connection after multiple re-transmissions, the RTO will be exponentially backed off as described in [RFC2988]. Due to Karn's algorithm as implemented in SCTP and TCP, the RTO estimator will not be reset until another ACK is received in response to a non-re-transmitted request. Thus, in cases where the problem occurs at the transport layer, after the client fails over to the alternate server, the RTO of the primary will remain at a high value unless an ACK is received on the primary connection.
[RFC2988]で説明されているように、輸送層ACKが一次接続でプライマリ接続で受信されない状況では、RTOは指数関数的にバックアウトされます。SCTPおよびTCPで実装されているKarnのアルゴリズムにより、RTO推定器は、非REトランスミストリクエストに応じて別のACKを受信するまでリセットされません。したがって、問題が輸送層で発生する場合、クライアントが代替サーバーに失敗した後、プライマリのRTOはプライマリ接続でACKを受信しない限り、高い値のままです。
In the case where the problem occurs at the transport layer, subsequent requests sent on the primary connection will not receive the same service as was originally provided. For example, instead of failover occurring after 3 retransmissions, failover might occur without even a single retransmission if RTO has been sufficiently backed off. Of course, if the lack of a watchdog response was due to an application layer problem, then RTO will not have been backed off. However, without transport layer visibility, there is no way for the application to know this.
輸送層で問題が発生した場合、プライマリ接続に送信された後続の要求は、当初提供されたのと同じサービスを受け取りません。たとえば、3回の再送信後にフェールオーバーが発生する代わりに、RTOが十分に後退した場合、1回の再送信さえなくフェールオーバーが発生する可能性があります。もちろん、ウォッチドッグの応答の欠如がアプリケーション層の問題によるものである場合、RTOは後退していません。ただし、輸送層の可視性がなければ、アプリケーションがこれを知る方法はありません。
Suspending use of the primary connection until a response to a watchdog message is received guarantees that the RTO timer will have been reset before the primary connection is reused. If no response is received after the second watchdog timer expiration, then the primary connection is closed and the suspension becomes permanent.
ウォッチドッグメッセージへの応答が受信されるまで、プライマリ接続の使用を一時停止すると、プライマリ接続が再利用される前にRTOタイマーがリセットされることが保証されます。2番目のウォッチドッグタイマーの有効期限が切れた後に応答がない場合、プライマリ接続が閉じられ、サスペンションが永続的になります。
[5] While the connection is in the closed state, the AAA client MUST NOT attempt to send further watchdog messages on the connection. However, after the connection is closed, the AAA client continues to periodically attempt to reopen the connection.
[5] 接続が閉じた状態にある間、AAAクライアントは接続上にさらにウォッチドッグメッセージを送信しようとしてはなりません。ただし、接続が閉じた後、AAAクライアントは定期的に接続の再開を試み続けます。
The AAA client SHOULD wait for the transport layer to report connection failure before attempting again, but MAY choose to bound this wait time by the watchdog interval, Tw. If the connection is successfully opened, then the watchdog message is sent. Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it. Connection validation via receipt of multiple watchdogs is not required when a connection is initially brought up -- in this case, the connection can immediately be put into service.
AAAクライアントは、輸送層が再び試みる前に接続障害を報告するのを待つ必要がありますが、ウォッチドッグ間隔TWでこの待ち時間をバインドすることを選択できます。接続が正常に開かれた場合、ウォッチドッグメッセージが送信されます。3つのウォッチドッグメッセージが送信され、応答されると、接続がサービスに返され、トランザクションが再び送信されます。接続が最初に発生した場合、複数のウォッチドッグを受領して接続検証は必要ありません。この場合、接続をすぐに使用することができます。
[6] When using SCTP as a transport, it is not necessary to disable SCTP's transport-layer heartbeats. However, if AAA implementations have access to SCTP's heartbeat parameters, they MAY chose to ensure that SCTP's heartbeat interval is longer than the AAA watchdog interval, Tw. This will ensure that alternate paths are still probed by SCTP, while the primary path has a minimum of heartbeat redundancy.
[6] SCTPを輸送として使用する場合、SCTPの輸送層ハートビートを無効にする必要はありません。ただし、AAAの実装がSCTPのハートビートパラメーターにアクセスできる場合、SCTPのハートビート間隔がAAAウォッチドッグ間隔TWよりも長くなることを確認することを選択する場合があります。これにより、代替パスがSCTPによって依然としてプローブされることが保証されますが、プライマリパスには最小限の心拍冗長性があります。
The watchdog timer MAY be integrated with primary/secondary style failover so as to provide improved reliability and basic load balancing. In order to balance load among multiple AAA servers, each AAA server is designated the primary for a portion of the clients, and designated as secondaries of varying priority for the remainder. In this way, load can be balanced among the AAA servers.
ウォッチドッグタイマーは、信頼性と基本的な負荷分散を改善するために、プライマリ/セカンダリスタイルのフェールオーバーと統合される場合があります。複数のAAAサーバー間の負荷のバランスをとるために、各AAAサーバーはクライアントの一部のプライマリに指定され、残りの優先度が異なる二次として指定されます。このようにして、AAAサーバー間で負荷をバランスさせることができます。
Within primary/secondary configurations, the watchdog timer operates as follows:
プライマリ/セカンダリ構成内で、ウォッチドッグタイマーは次のように動作します。
[1] Assume that each client or agent is initially configured with a single primary agent or server, and one or more secondary connections.
[1] 各クライアントまたはエージェントが最初に単一のプライマリエージェントまたはサーバー、および1つ以上のセカンダリ接続で構成されていると仮定します。
[2] The watchdog mechanism is used to suspend and eventually close primary connections that are experiencing difficulties. It is also used to re-open and validate connections that have returned to health.
[2] ウォッチドッグメカニズムは、困難を経験しているプライマリ接続を停止し、最終的に閉じるために使用されます。また、健康に戻った接続を再開および検証するためにも使用されます。
[3] Once a secondary is promoted to primary status, either on a temporary or permanent basis, the next server on the list of secondaries is promoted to fill the open secondary slot.
[3] 一時的または永続的なベースで、セカンダリーが一次ステータスに昇格すると、セカンダリーのリストの次のサーバーが宣伝され、オープンセカンダリスロットが埋められます。
[4] The client or agent periodically attempts to re-open closed connections, so that it is possible that a previously closed connection can be returned to service and become eligible for use again. Implementations will typically retain a limit on the number of connections open at a time, so that once a previously closed connection is brought online again, the lowest priority secondary connection will be closed. In order to prevent periodic closing and re-opening of secondary connections, it is recommended that functioning connections remain open for a minimum of 5 minutes.
[4] クライアントまたはエージェントは定期的に閉じた接続を再開しようとするため、以前に閉じた接続をサービスに戻し、再び使用する資格がある可能性があります。実装は通常、一度に開く接続の数の制限を保持するため、以前に閉じられた接続が再びオンラインになったら、最優先のセカンダリ接続が閉じられます。二次接続の定期的な閉鎖と再オープンを防ぐために、機能する接続を最低5分間開いたままにすることをお勧めします。
[5] In order to enable diagnosis of failover behavior, it is recommended that a table of failover events be kept within the MIB. These failover events SHOULD include appropriate transaction identifiers so that client and server data can be compared, providing insight into the cause of the problem (transport or application layer).
[5] フェイルオーバー動作の診断を可能にするために、フェイルオーバーイベントのテーブルをMIB内に保持することをお勧めします。これらのフェールオーバーイベントには、クライアントとサーバーのデータを比較できるように適切なトランザクション識別子を含める必要があり、問題の原因（輸送またはアプリケーション層）に関する洞察を提供します。
Primary/secondary failover is capable of providing improved resilience and basic load balancing. However, it does not address TCP head of line blocking, since only a single connection is in use at a time.
プライマリ/セカンダリフェールオーバーは、回復力の向上と基本的な負荷分散を提供することができます。ただし、一度に1つの接続のみが使用されているため、TCPヘッドのラインブロッキングには対応していません。
A AAA client or agent maintaining connections to multiple agents or servers MAY load balance between them. Establishing connections to multiple agents or servers reduces, but does not eliminate, head of line blocking issues experienced on TCP connections. This issue does not exist with SCTP connections utilizing multiple streams.
複数のエージェントまたはサーバーへの接続を維持するAAAクライアントまたはエージェントは、それらの間のバランスをロードする場合があります。複数のエージェントまたはサーバーへの接続を確立すると、TCP接続で発生したラインブロッキングの問題の責任者が削減されますが、排除しません。この問題は、複数のストリームを使用したSCTP接続には存在しません。
In connection load balancing configurations, the application watchdog operates as follows:
関連性のあるロードバランシング構成では、アプリケーションウォッチドッグは次のように動作します。
[1] Assume that each client or agent is initially configured with connections to multiple AAA agents or servers, with one connection between a given client/agent and an agent/server.
[1] 各クライアントまたはエージェントが、特定のクライアント/エージェントとエージェント/サーバーの間に1つの接続を持つ複数のAAAエージェントまたはサーバーへの接続で最初に構成されていると仮定します。
[2] In static load balancing, transactions are apportioned among the connections based on the total number of connections and a "weight" assigned to each connection. Pearson's hash [RFC3074] applied to the NAI [RFC2486] can be used to determine which connection will handle a given transaction. Hashing on the NAI provides highly granular load balancing, while ensuring that all traffic for a given conversation will be sent to the same agent or server. In dynamic load balancing, the value of the "weight" can vary based on conditions such as AAA server load. Such techniques, while sophisticated, are beyond the scope of this document.
[2] 静的負荷分散では、接続の総数と各接続に割り当てられた「重量」に基づいて、接続にトランザクションが配分されます。NAI [RFC2486]に適用されたピアソンのハッシュ[RFC3074]を使用して、特定のトランザクションを処理する接続を決定できます。NAIをハッシュすると、特定の会話のすべてのトラフィックが同じエージェントまたはサーバーに送信されるようにしながら、非常に細かい負荷分散を提供します。動的負荷バランスでは、「重量」の値は、AAAサーバーの負荷などの条件によって異なります。このようなテクニックは、洗練されていますが、このドキュメントの範囲を超えています。
[3] Transactions are distributed to connections based on the total number of available connections and their weights. A change in the number of available connections forces recomputation of the hash table. In order not to cause conversations in progress to be switched to new destinations, on recomputation, a transitional period is required in which both old and new hash tables are needed in order to permit aging out of conversations in progress. Note that this requires a way to easily determine whether a Request represents a new conversation or the continuation of an existing conversation. As a result, removing and adding of connections is an expensive operation, and it is recommended that the hash table only be recomputed once a connection is closed or returned to service.
[3] トランザクションは、利用可能な接続の総数とその重みに基づいて接続に分配されます。利用可能な接続の数の変更により、ハッシュテーブルの再計算が強制されます。進行中の会話を新しい目的地に切り替えないようにするために、再計算では、進行中の会話の老化を許可するために、古いハッシュテーブルと新しいハッシュテーブルの両方が必要である移行期間が必要です。これには、リクエストが新しい会話を表すか、既存の会話の継続を表すかを簡単に判断する方法が必要であることに注意してください。その結果、接続を削除して追加することは高価な操作であり、接続が閉じられたり、サービスに戻された場合にのみ、ハッシュテーブルを再計算することをお勧めします。
Suspended connections, although they are not used, do not force hash table reconfiguration until they are closed. Similarly, re-opened connections not accumulating sufficient watchdog responses do not force a reconfiguration until they are returned to service.
中断された接続は使用されていませんが、閉じられるまでハッシュテーブルの再構成を強制しないでください。同様に、十分なウォッチドッグの応答を蓄積しない接続を再開しても、サービスに戻されるまで再構成を強制しません。
While a connection is suspended, transactions that were to have been assigned to it are instead assigned to the next available server. While this results in a momentary imbalance, it is felt that this is a relatively small price to pay in order to reduce hash table thrashing.
接続が中断されている間、それに割り当てられたトランザクションは、代わりに次の利用可能なサーバーに割り当てられます。これは瞬間的な不均衡をもたらしますが、ハッシュテーブルのスラッシングを減らすために、これは比較的小さい価格であると感じられます。
[4] In order to enable diagnosis of load balancing behavior, it is recommended that in addition to a table of failover events, a table of statistics be kept on each client, indexed by a AAA server. That way, the effectiveness of the load balancing algorithm can be evaluated.
[4] 負荷分散の動作の診断を可能にするために、フェイルオーバーイベントの表に加えて、AAAサーバーによってインデックス付けされた各クライアントに統計の表を保持することをお勧めします。そうすれば、負荷分散アルゴリズムの有効性を評価できます。
Multiple facilities are required to enable duplicate detection. These include session identifiers as well as hop-by-hop and end-to-end message identifiers. Hop-by-hop identifiers whose value may change at each hop are not sufficient, since a AAA server may receive the same message from multiple agents. For example, a AAA client can send a request to Agent1, then failover and resend the request to Agent2; both agents forward the request to the home AAA server, with different hop-by-hop identifiers. A Session Identifier is insufficient as it does not distinguish different messages for the the same session.
重複検出を有効にするには、複数の施設が必要です。これらには、セッション識別子とホップバイホップおよびエンドツーエンドのメッセージ識別子が含まれます。AAAサーバーは複数のエージェントから同じメッセージを受信する場合があるため、各ホップで値が変更される可能性のあるホップバイホップ識別子は十分ではありません。たとえば、AAAクライアントはAgent1にリクエストを送信し、その後フェールオーバーしてリクエストをAgent2に再送信できます。両方のエージェントは、異なるホップバイホップ識別子を使用して、ホームAAAサーバーにリクエストを転送します。セッション識別子は、同じセッションの異なるメッセージを区別しないため、不十分です。
Proper treatment of the end-to-end message identifier ensures that AAA operations are idempotent. For example, without an end-to-end identifier, a AAA server keeping track of simultaneous logins might send an Accept in response to an initial Request, and then a Reject in response to a duplicate Request (where the user was allowed only one simultaneous login). Depending on which Response arrived first, the user might be allowed access or not.
エンドツーエンドのメッセージ識別子の適切な処理により、AAA操作が等量であることが保証されます。たとえば、エンドツーエンドの識別子がない場合、同時ログインを追跡するAAAサーバーは、初期リクエストに応じて受け入れを送信し、その後、重複リクエストに応答して拒否される場合があります（ユーザーは1つの同時に許可された場合のみです。ログイン）。どの応答が最初に到着したかに応じて、ユーザーはアクセスを許可されるかどうか。
However, if the server were to store the end-to-end message identifier along with the simultaneous login information, then the duplicate Request (which utilizes the same end-to-end message identifier) could be identified and the correct response could be returned.
ただし、サーバーが同時ログイン情報とともにエンドツーエンドメッセージ識別子を保存する場合、重複要求（同じエンドツーエンドメッセージ識別子を使用）を識別し、正しい応答を返すことができます。
In order to address invalidation of transport parameter estimates, AAA protocol implementations MAY utilize Congestion Window Validation [RFC2861] and RTO validation when using TCP. This specification also recommends a procedure for RTO validation.
輸送パラメーターの推定値の無効化に対処するために、AAAプロトコルの実装は、TCPを使用する際に輻輳ウィンドウの検証[RFC2861]およびRTO検証を利用する場合があります。この仕様は、RTO検証の手順も推奨しています。
[RFC2581] and [RFC2861] both recommend that a connection go into slow-start after a period where no traffic has been sent within the RTO interval. [RFC2861] recommends only increasing the congestion window if it was full when the ACK arrived. The congestion window is reduced by half once every RTO interval if no traffic is received.
[RFC2581]および[RFC2861]はどちらも、RTO間隔内にトラフィックが送信されていない期間後に接続がスロースタートになることを推奨しています。[RFC2861]は、ACKが到着したときにいっぱいであった場合にのみ、混雑ウィンドウを増やすことをお勧めします。トラフィックが受信されないと、RTO間隔ごとに半分に縮小されます。
When Congestion Window Validation is used, the congestion window will not build during application-driven periods, and instead will be decayed. As a result, AAA applications operating within the application-driven regime will typically run with a congestion window equal to the initial window much of the time, operating in "perpetual slowstart".
輻輳ウィンドウの検証を使用すると、アプリケーション駆動型の期間中は輻輳ウィンドウが構築されず、代わりに崩壊します。その結果、アプリケーション駆動型制度内で動作するAAAアプリケーションは、通常、「永続的なスロースタート」で動作している最初のウィンドウに等しい混雑ウィンドウで実行されます。
During periods in which AAA behavior is application-driven this will have no effect. Since the time between packets will be larger than RTT, AAA will operate with an effective congestion window equal to the initial window. However, during network-driven periods, the effect will be to space out sending of AAA packets. Thus instead of being able to send a large burst of packets into the network, a client will need to wait several RTTs as the congestion window builds during slow-start.
AAAの動作がアプリケーション駆動型である期間中、これは効果がありません。パケット間の時間はRTTよりも大きくなるため、AAAは初期ウィンドウに等しい効果的な輻輳ウィンドウで動作します。ただし、ネットワーク駆動型の期間中は、AAAパケットの送信をスペースアウトする効果があります。したがって、パケットの大きなバーストをネットワークに送信できる代わりに、クライアントはスロースタート中に混雑ウィンドウが構築されるため、いくつかのRTTを待つ必要があります。
For example, a client operating over TCP with an initial window of 2, with 35 AAA requests to send would take approximately 6 RTTs to send them, as the congestion window builds during slow start: 2, 3, 3, 6, 9, 12. After the backlog is cleared, the implementation will once again be application-driven and the congestion window size will decay. If the client were using SCTP, the number of RTTs needed to transmit all requests would usually be less, and would depend on the size of the requests, since SCTP tracks the progress for the opening of the congestion window by bytes, not segments.
たとえば、2の初期ウィンドウでTCPを介して操作するクライアントは、35のAAAリクエストを送信することを要求します。。バックログがクリアされた後、実装は再びアプリケーション駆動型になり、輻輳ウィンドウサイズが崩壊します。クライアントがSCTPを使用していた場合、すべてのリクエストを送信するために必要なRTTの数は通常少なくなり、リクエストのサイズに依存します。SCTPは、セグメントではなく、輻輳ウィンドウの開口部の進行状況を追跡するためです。
Note that [RFC2861] and [RFC2988] do not address the issue of RTO validation. This is also a problem, particularly when the Congestion Manager [RFC3124] is implemented. During periods of high packet loss, the RTO may be repeatedly increased via exponential back-off, and may attain a high value. Due to lack of timely feedback on RTT and RTO during application-driven periods, the high RTO estimate may persist long after the conditions that generated it have dissipated.
[RFC2861]および[RFC2988]はRTO検証の問題に対処していないことに注意してください。これは、特に混雑マネージャー[RFC3124]が実装されている場合にも問題です。高いパケット損失の期間中、RTOは指数関数的なバックオフにより繰り返し増加する可能性があり、高い値を達成する可能性があります。アプリケーション駆動型期間中のRTTおよびRTOに関するタイムリーなフィードバックがないため、生成された条件が消散した後も長く続く可能性があります。
RTO validation MAY be used to address this issue for TCP, via the following procedure:
RTO検証は、次の手順を介して、TCPのこの問題に対処するために使用できます。
After the congestion window is decayed according to [RFC2861], reset the estimated RTO to 3 seconds. After the next packet comes in, re-calculate RTTavg, RTTdev, and RTO according to the method described in [RFC2581].
[RFC2861]に従って輻輳ウィンドウが減衰した後、推定RTOを3秒にリセットします。次のパケットが入った後、[RFC2581]で説明されている方法に従って、RTTAVG、RTTDEV、およびRTOを再計算します。
To address this issue for SCTP, AAA implementations SHOULD use SCTP heartbeats. [RFC2960] states that heartbeats should be enabled by default, with an interval of 30 seconds. If this interval proves to be too long to resolve this issue, AAA implementations MAY reduce the heartbeat interval.
SCTPのこの問題に対処するには、AAA実装ではSCTPハートビートを使用する必要があります。[RFC2960]は、ハートビートをデフォルトで30秒の間隔で有効にする必要があると述べています。この間隔がこの問題を解決するには長すぎることが判明した場合、AAAの実装はハートビート間隔を減らす可能性があります。
When Congestion Window Validation [RFC2861] is used, AAA implementations will operate with a congestion window equal to the initial window much of the time. As a result, the window size will often not be large enough to enable use of fast re-transmit for TCP. In addition, since AAA traffic is two-way, ACKs carrying data will not count towards triggering fast re-transmit. SCTP is less likely to encounter this issue, so the measures described below apply to TCP.
輻輳ウィンドウの検証[RFC2861]を使用すると、AAAの実装は、ほとんどの場合、初期ウィンドウに等しい混雑ウィンドウで動作します。その結果、ウィンドウサイズは、TCPの高速再送信の使用を可能にするのに十分な大きさではないことがよくあります。さらに、AAAトラフィックは双方向であるため、ACKSの運搬データは高速再送信のトリガーにカウントされません。SCTPはこの問題に遭遇する可能性が低いため、以下に説明する措置はTCPに適用されます。
To address this issue, AAA implementations SHOULD support selective acknowledgement as described in [RFC2018] and [RFC2883]. AAA implementations SHOULD also implement Limited Transmit for TCP, as described in [RFC3042]. Rather than reducing the number of duplicate ACKs required for triggering fast recovery, which would increase the number of inappropriate re-transmissions, Limited Transmit enables the window size be increased, thus enabling the sending of additional packets which in turn may trigger fast re-transmit without a change to the algorithm.
この問題に対処するために、AAAの実装は[RFC2018]および[RFC2883]に記載されているように、選択的な承認をサポートする必要があります。[RFC3042]で説明されているように、AAAの実装もTCPの限定送信を実装する必要があります。不適切な再送信の数を増やす迅速な回復のトリガーに必要な重複アックの数を減らすのではなく、送信が限られているため、ウィンドウサイズを増やすことができ、したがって、追加のパケットの送信が可能になり、順番に高速な再送信をトリガーする可能性があります。アルゴリズムを変更することなく。
However, if congestion window validation [RFC2861] is implemented, this proposal will only have an effect in situations where the time between packets is less than the estimated retransmission timeout (RTO). If the time between packets is greater than RTO, additional packets will typically not be available for sending so as to take advantage of the increased window size. As a result, AAA protocols will typically operate with the lowest possible congestion window size, resulting in a re-transmission timeout for every lost packet.
ただし、輻輳ウィンドウの検証[RFC2861]が実装されている場合、この提案は、パケット間の時間が推定再送信タイムアウト（RTO）よりも短い状況でのみ効果があります。パケット間の時間がRTOよりも大きい場合、通常、追加のパケットは、ウィンドウサイズの増加を活用するために送信するために使用できません。その結果、AAAプロトコルは通常、可能な限り低い輻輳ウィンドウサイズで動作し、失われたパケットごとに再送信タイムアウトをもたらします。
TCP inherently does not provide a solution to the head-of-line blocking problem, although its effects can be lessened by implementation of Limited Transmit [RFC3042], and connection load balancing.
TCPは本質的に、頭部のブロッキング問題の解決策を提供しませんが、その効果は、限られた送信[RFC3042]の実装と接続荷重バランスの実装によって軽減できます。
Each AAA node SHOULD distribute its messages evenly across the range of SCTP streams that it and its peer have agreed upon. (A lost message in one stream will not cause any other streams to block.) A trivial and effective implementation of this simply increments a counter for the stream ID to send on. When the counter reaches the maximum number of streams for the association, it resets to 0.
各AAAノードは、メッセージとそのピアが同意したSCTPストリームの範囲に均等にメッセージを配布する必要があります。（1つのストリームで失われたメッセージは、他のストリームをブロックすることはありません。）これの些細で効果的な実装は、ストリームIDのカウンターが送信されるだけです。カウンターが協会の最大ストリーム数に達すると、0にリセットされます。
AAA peers MUST be able to accept messages on any stream. Note that streams are used *solely* to prevent head-of-the-line blocking. All identifying information is carried within the Diameter payload. Messages distributed across multiple streams may not be received in the order they are sent.
AAAピアは、あらゆるストリームでメッセージを受け入れることができなければなりません。ストリームは *単独で *単独で使用されていることに注意してください。すべての識別情報は、直径のペイロード内で運ばれます。複数のストリームに分配されたメッセージは、送信される順序で受信されない場合があります。
SCTP peers can allocate up to 65535 streams for an association. The cost for idle streams may or may not be zero, depending on the implementation, and the cost for non-idle streams is always greater than 0. So administrators may wish to limit the number of possible streams on their diameter nodes according to the resources (i.e. memory, CPU power, etc.) of a particular node.
SCTPピアは、関連性に最大65535のストリームを割り当てることができます。アイドルストリームのコストは、実装に応じてゼロである場合とそうでない場合があり、アイドル以外のストリームのコストは常に0より大きいため、管理者はリソースに従って直径ノードの可能なストリームの数を制限したい場合があります特定のノードの（すなわち、メモリ、CPU電源など）。
On a Diameter client, the number of streams may be determined by the maximum number of peak users on the NAS. If a stream is available per user, then this should be sufficient to prevent head-of-line blocking. On a Diameter proxy, the number of streams may be determined by the maximum number of peak sessions in progress from that proxy to each downstream AAA server.
直径クライアントでは、NASのピークユーザーの最大数によってストリームの数が決定できます。ユーザーごとにストリームが利用可能な場合、これは頭のブロックを防ぐのに十分でなければなりません。直径のプロキシでは、ストリームの数は、そのプロキシから各下流のAAAサーバーへの進行中のピークセッションの最大数によって決定できます。
Stream IDs do not need to be preserved by relay agents. This simplifies implementation, as agents can easily handle forwarding between two associations with different numbers of streams. For example, consider the following case, where a relay server DRL forwards messages between a NAS and a home server, HMS. The NAS and DRL have agreed upon 1000 streams for their association, and DRL and HMS have agreed upon 2000 streams for their association. The following figure shows the message flow from NAS to HMS via DRL, and the stream ID assignments for each message:
ストリームIDは、リレーエージェントによって保存する必要はありません。これにより、エージェントは異なる数のストリームとの2つの関連性の間の転送を簡単に処理できるため、実装が簡素化されます。たとえば、リレーサーバーがNASとホームサーバーHMSの間でメッセージを転送する次のケースを考えてみましょう。NASとDRLは、彼らの協会のために1000のストリームに同意し、DRLとHMSは彼らの協会のために2000のストリームに同意しました。次の図は、DRLを介したNASからHMSへのメッセージフローと、各メッセージのストリームID割り当てを示しています。
+------+ +------+ +------+
| | | | | |
| NAS | ---------> | DRL | ---------> | HMS |
| | | | | |
+------+ 1000 streams +------+ 2000 streams +------+
msg 1: str id 0 msg 1: str id 0
msg 2: str id 1 msg 2: str id 1
...
msg 1000: str id 999 msg 1000: str id 999
msg 1001: str id 0 msg 1001: str id 1000
DRL can forward messages 1 through 1000 to HMS using the same stream ID that NAS used to send to DRL. However, since the NAS / DRL association has only 1000 streams, NAS wraps around to stream ID 0 when sending message 1001. The DRL / HMS association, on the other hand, has 2000 streams, so DRL can reassign message 1001 to stream ID 1000 when forwarding it on to HMS.
DRLは、NASがDRLに送信するために使用したのと同じストリームIDを使用して、1〜1000からHMSを転送できます。ただし、NAS / DRL協会には1000のストリームしかないため、NASはメッセージ1001を送信するときにID 0をストリーミングするためにラップします。一方、DRL / HMSアソシエーションには2000のストリームがあるため、DRLはメッセージ1001を再割り当てしてID 1000をストリーミングできます。HMSに転送するとき。
This distribution scheme acts like a hash table. It is possible, yet unlikely, that two messages will end up in the same stream, and even less likely that there will be message loss resulting in blocking when this happens. If it does turn out to be a problem, local administrators can increase the number of streams on their nodes to improve performance.
この分布スキームは、ハッシュテーブルのように機能します。2つのメッセージが同じストリームで終わる可能性はありませんが、これが起こったときにブロックされるメッセージの損失が発生する可能性はさらに低くなります。問題が発生した場合、ローカル管理者はノードのストリーム数を増やしてパフォーマンスを向上させることができます。
In order to improve upon default timer estimates, AAA implementations MAY implement the Congestion Manager (CM) [RFC3124]. CM is an end-system module that:
デフォルトのタイマーの推定値を改善するために、AAA実装では渋滞マネージャー（CM）[RFC3124]を実装する場合があります。CMは次のようなエンドシステムモジュールです。
(i) Enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and
(i) 同じ受信機に任命された送信者からの複数の同時ストリームのアンサンブルを有効にし、同じ渋滞特性を共有して適切な混雑の回避と制御を実行します。
(ii) Allows applications to easily adapt to network congestion.
（ii）アプリケーションがネットワークの混雑に簡単に適応できるようにする。
The CM helps integrate congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-stream bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions.
CMは、すべてのアプリケーションと輸送プロトコルにわたって混雑管理を統合するのに役立ちます。CMは、輻輳パラメーター（利用可能な集計およびストリームごとの帯域幅、レシーバーごとの往復時間など）を維持し、アプリケーションがネットワーク特性について学習し、情報をCMに渡すことを可能にするAPIをエクスポートし、互いの混合情報を共有できるようにします。、およびデータ送信をスケジュールします。
The CM enables the AAA application to access transport parameters (RTTavg, RTTdev) via callbacks. RTO estimates are currently not available via the callback interface, though they probably should be. Where available, transport parameters SHOULD be used to improve upon default timer values.
CMを使用すると、AAAアプリケーションはコールバックを介して輸送パラメーター（RTTAVG、RTTDEV）にアクセスできます。RTOの推定値は現在、コールバックインターフェイスを介して利用できませんが、おそらくそうあるべきです。利用可能な場合は、輸送パラメーターを使用して、デフォルトのタイマー値を改善する必要があります。
Premature failover is prevented by the watchdog functionality described above. If the next hop does not return a reply, the AAA client will send a watchdog message to it to verify liveness. If a watchdog reply is received, then the AAA client will know that the next hop server is functioning at the application layer. As a result, it is only necessary to provide terminal error messages, such as the following:
上記のウォッチドッグ機能により、早期フェールオーバーが防止されます。次のホップが返信を返さない場合、AAAクライアントはWatchDogメッセージを送信して、livensionを確認します。ウォッチドッグの返信が受信された場合、AAAクライアントは、次のホップサーバーがアプリケーションレイヤーで機能していることを知るでしょう。その結果、次のような端末エラーメッセージを提供することのみが必要です。
"Busy": agent/Server too busy to handle additional requests, NAS should failover all requests to another agent/server.
「ビジー」：エージェント/サーバーは忙しすぎて追加のリクエストを処理できません。NASは、すべてのリクエストを別のエージェント/サーバーにフェールオーバーする必要があります。
"Can't Locate": agent can't locate the AAA server for the indicated realm; NAS should failover that request to another proxy.
「見つけられない」：エージェントは、指定された領域のAAAサーバーを見つけることができません。NASは、その要求を別のプロキシにフェールオーバーする必要があります。
"Can't Forward": agent has tried both primary and secondary AAA servers with no response; NAS should failover the request to another agent.
「転送できません」：エージェントは、応答なしでプライマリおよびセカンダリAAAサーバーの両方を試しました。NASは、別のエージェントへのリクエストをフェールオーバーする必要があります。
Note that these messages differ in their scope. The "Busy" message tells the NAS that the agent/server is too busy for ANY request. The "Can't Locate" and "Can't Forward" messages indicate that the ultimate destination cannot be reached or isn't responding, implying per-request failover.
これらのメッセージは範囲が異なることに注意してください。「ビジー」メッセージは、NASに、エージェント/サーバーがどんなリクエストにも忙しすぎることを伝えます。「見つけられない」と「転送できない」メッセージは、最終的な目的地に到達できないか、応答していないことを示しており、リケストあたりの失敗を意味します。
Since AAA clients, agents and servers serve as network access gatekeepers, they are tempting targets for attackers. General security considerations concerning TCP congestion control are discussed in [RFC2581]. However, there are some additional considerations that apply to this specification.
AAAのクライアント、エージェント、サーバーはネットワークアクセスゲートキーパーとして機能するため、攻撃者にとって魅力的なターゲットです。TCP混雑制御に関する一般的なセキュリティ上の考慮事項については、[RFC2581]で説明しています。ただし、この仕様に適用されるいくつかの追加の考慮事項があります。
By enabling failover between AAA agents, this specification improves the resilience of AAA applications. However, it may also open avenues for denial of service attacks.
AAAエージェント間のフェールオーバーを有効にすることにより、この仕様により、AAAアプリケーションの回復力が向上します。ただし、サービス拒否攻撃の手段も開く可能性があります。
The failover algorithm is driven by lack of response to AAA requests and watchdog packets. On a lightly loaded network where AAA responses would not be received prior to expiration of the watchdog timer, an attacker can swamp the network, causing watchdog packets to be dropped. This will cause the AAA client to switch to another AAA agent, where the attack can be repeated. By causing the AAA client to cycle between AAA agents, service can be denied to users desiring network access.
フェールオーバーアルゴリズムは、AAAリクエストとウォッチドッグパケットへの応答がないことによって駆動されます。WatchDogタイマーの有効期限が切れる前にAAA応答が受信されない軽くロードされたネットワークでは、攻撃者がネットワークを圧倒し、ウォッチドッグパケットをドロップすることができます。これにより、AAAクライアントは別のAAAエージェントに切り替えられ、攻撃を繰り返すことができます。AAAクライアントがAAAエージェント間でサイクリングすることにより、ネットワークアクセスを希望するユーザーにサービスを拒否できます。
Where TLS [RFC2246] is being used to provide AAA security, there will be a vulnerability to spoofed reset packets, as well as other transport layer denial of service attacks (e.g. SYN flooding). Since SCTP offers improved denial of service resilience compared with TCP, where AAA applications run over SCTP, this can be mitigated to some extent.
TLS [RFC2246]がAAAセキュリティを提供するために使用されている場合、スプーフィングされたリセットパケット、およびその他の輸送層のサービス攻撃の拒否（Syn Floodingなど）に対する脆弱性があります。SCTPは、AAAアプリケーションがSCTPを介して実行されるTCPと比較して改善されたサービスの回復力を提供するため、これはある程度緩和できます。
Where IPsec [RFC2401] is used to provide security, it is important that IPsec policy require IPsec on incoming packets. In order to enable a AAA client to determine what security mechanisms are in use on an agent or server without prior knowledge, it may be tempting to initiate a connection in the clear, and then to have the AAA agent respond with IKE [RFC2409]. While this approach minimizes required client configuration, it increases the vulnerability to denial of service attack, since a connection request can now not only tie up transport resources, but also resources within the IKE implementation.
IPSEC [RFC2401]がセキュリティを提供するために使用される場合、IPSECポリシーには着信パケットにIPSECが必要であることが重要です。AAAクライアントが事前知識のないエージェントまたはサーバーで使用されているセキュリティメカニズムを決定できるようにするために、クリアで接続を開始し、AAAエージェントにIKE [RFC2409]に応答するように誘惑する可能性があります。このアプローチは必要なクライアントの構成を最小限に抑えますが、接続要求は輸送リソースだけでなく、IKE実装内のリソースを結び付けることができるため、サービス拒否攻撃に対する脆弱性が向上します。
This document does not create any new number spaces for IANA administration.
このドキュメントでは、IANA管理用の新しい数字スペースは作成されません。
References
参考文献
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A. Romanow, "An Extension to the Selective Acknowledgment (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883] Floyd、S.、Mahdavi、J.、Mathis、M.、Podolsky、M。、およびA. Romanow、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、2000年7月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V.Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC3042] Allman, M., Balakrishnan H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042] Allman、M.、Balakrishnan H.およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[RFC3074] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load Balancing Algorithm", RFC 3074, February 2001.
[RFC3074] Volz、B.、Gonczi、S.、Lemon、T。、およびR. Stevens、「DHC Load Balancing Algorithm」、RFC 3074、2001年2月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、H。およびS. Seshan、「ザ・ミッシェンマネージャー」、RFC 3124、2001年6月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策の実施」、RFC 2607、1999年6月。
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP混雑ウィンドウ検証」、RFC 2861、2000年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, June 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「会計管理の紹介」、RFC 2975、2000年6月。
[RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの最初のウィンドウの増加」、RFC 3390、2002年10月。
[Congest] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Commest] Jacobson、V。、「混雑の回避と管理」、コンピューターコミュニケーションレビュー、Vol。18、いいえ。4、pp。314-329、1988年8月。ftp：//ftp.ee.lbl.gov/papers/congavoid.ps.z
[Paxson] Paxson, V., "Measurement and Analysis of End-to-End Internet Dynamics", Ph.D. Thesis, Computer Science Division, University of California, Berkeley, April 1997.
[Paxson] Paxson、V。、「エンドツーエンドのインターネットダイナミクスの測定と分析」、Ph.D。論文、カリフォルニア大学バークレー校、コンピューターサイエンス部門、1997年4月。
Appendix A - Detailed Watchdog Algorithm
付録A-詳細なウォッチドッグアルゴリズム
In this Appendix, the memory control structure that contains all information regarding a specific peer is referred to as a Peer Control Block, or PCB. The PCB contains the following fields:
この付録では、特定のピアに関するすべての情報を含むメモリ制御構造は、ピアコントロールブロックまたはPCBと呼ばれます。PCBには次のフィールドが含まれています。
Status: OKAY: The connection is up SUSPECT: Failover has been initiated on the connection. DOWN: Connection has been closed. REOPEN: Attempting to reopen a closed connection INITIAL: The initial state of the pcb when it is first created. The pcb has never been opened.
ステータス：わかりました：接続は疑わしいです：接続でフェイルオーバーが開始されました。ダウン：接続が閉じられています。再オープン：閉じた接続を再開しようとする初期：PCBが最初に作成されたときの初期状態。PCBが開かれたことはありません。
Variables: Pending: Set to TRUE if there is an outstanding unanswered watchdog request Tw: Watchdog timer value NumDWA: Number of DWAs received during REOPEN
変数：保留：未解決の未回答のウォッチドッグリクエストがある場合はtrueに設定されますTW：ウォッチドッグタイマー値Numdwa：再開中に受け取ったDWAの数
Tw is the watchdog timer, measured in seconds. Every second, Tw is decremented. When it reaches 0, the OnTimerElapsed event (see below) is invoked. Pseudo-code for the algorithm is included on the following pages.
TWは、数秒で測定されたウォッチドッグタイマーです。毎秒TWが減少します。0に達すると、OntimerElapsedイベント（以下を参照）が呼び出されます。アルゴリズムの擬似コードは、次のページに含まれています。
SetWatchdog()
{
/*
SetWatchdog() is called whenever it is necessary
to reset the watchdog timer Tw. The value of the
watchdog timer is calculated based on the default
initial value TWINIT and a jitter ranging from
-2 to 2 seconds. The default for TWINIT is 30 seconds,
and MUST NOT be set lower than 6 seconds.
*/
Tw=TWINIT -2.0 + 4.0 * random() ;
SetTimer(Tw) ;
return ;
}
/*
OnReceive() is called whenever a message
is received from the peer. This message MAY
be a request or an answer, and can include
DWR and DWA messages. Pending is assumed to
be a global variable.
*/
OnReceive(pcb, msgType)
{
if (msgType == DWA) {
Pending = FALSE;
}
switch (pcb->Status){
case OKAY:
SetWatchdog();
break;
case SUSPECT:
pcb->Status = OKAY;
Failback(pcb);
SetWatchdog();
break;
case REOPEN:
if (msgType == DWA) {
NumDWA++;
if (NumDWA == 3) {
pcb->status = OKAY;
Failback();
}
} else {
Throwaway(received packet);
}
break;
case INITIAL:
case DOWN:
Throwaway(received packet);
break;
default:
Error("Shouldn't be here!");
break;
}
}
/*
OnTimerElapsed() is called whenever Tw reaches zero (0).
*/
OnTimerElapsed(pcb)
{
switch (pcb->status){
case OKAY:
if (!Pending) {
SendWatchdog(pcb);
SetWatchdog();
Pending = TRUE;
break;
}
pcb->status = SUSPECT;
FailOver(pcb);
SetWatchdog();
break ;
case SUSPECT:
pcb->status = DOWN;
CloseConnection(pcb);
SetWatchdog();
break;
case INITIAL:
case DOWN:
AttemptOpen(pcb);
SetWatchdog();
break;
case REOPEN:
if (!Pending) {
SendWatchdog(pbc);
SetWatchdog();
Pending = TRUE;
break;
}
if (NumDWA < 0) {
pcb->status = DOWN;
CloseConnection(pcb);
} else {
NumDWA = -1;
}
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
/*
OnConnectionUp() is called whenever a connection comes up
*/
OnConnectionUp(pcb)
{
switch (pcb->status){
case INITIAL:
pcb->status = OKAY;
SetWatchdog();
break;
case DOWN:
pcb->status = REOPEN;
NumDWA = 0;
SendWatchdog(pcb);
SetWatchdog();
Pending = TRUE;
break;
default:
error("Shouldn't be here!);
break;
}
}
/*
OnConnectionDown() is called whenever a connection goes down
*/
OnConnectionDown(pcb)
{
pcb->status = DOWN;
CloseConnection();
switch (pcb->status){
case OKAY:
Failover(pcb);
SetWatchdog();
break;
case SUSPECT:
case REOPEN:
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
/* Here is the state machine equivalent to the above code:
STATE Event Actions New State
===== ------ ------- ----------
OKAY Receive DWA Pending = FALSE
SetWatchdog() OKAY
OKAY Receive non-DWA SetWatchdog() OKAY
SUSPECT Receive DWA Pending = FALSE
Failback()
SetWatchdog() OKAY
SUSPECT Receive non-DWA Failback()
SetWatchdog() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA == 2 NumDWA++
Failback() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA < 2 NumDWA++ REOPEN
STATE Event Actions New State
===== ------ ------- ----------
REOPEN Receive non-DWA Throwaway() REOPEN
INITIAL Receive DWA Pending = FALSE
Throwaway() INITIAL
INITIAL Receive non-DWA Throwaway() INITIAL
DOWN Receive DWA Pending = FALSE
Throwaway() DOWN
DOWN Receive non-DWA Throwaway() DOWN
OKAY Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE OKAY
OKAY Timer expires & Failover()
Pending SetWatchdog() SUSPECT
SUSPECT Timer expires CloseConnection()
SetWatchdog() DOWN
INITIAL Timer expires AttemptOpen()
SetWatchdog() INITIAL
DOWN Timer expires AttemptOpen()
SetWatchdog() DOWN
REOPEN Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE REOPEN
REOPEN Timer expires & CloseConnection()
Pending & SetWatchdog()
NumDWA < 0 DOWN
REOPEN Timer expires & NumDWA = -1
Pending & SetWatchdog()
NumDWA >= 0 REOPEN
INITIAL Connection up SetWatchdog() OKAY
DOWN Connection up NumDWA = 0
SendWatchdog()
SetWatchdog()
Pending = TRUE REOPEN
OKAY Connection down CloseConnection()
Failover()
SetWatchdog() DOWN
SUSPECT Connection down CloseConnection()
SetWatchdog() DOWN
REOPEN Connection down CloseConnection()
SetWatchdog() DOWN
*/
Appendix B - AAA Agents
付録B -AAAエージェント
As described in [RFC2865] and [RFC2607], AAA agents have become popular in order to support services such as roaming and shared use networks. Such agents are used both for authentication/authorization, as well as accounting [RFC2975].
[RFC2865]および[RFC2607]で説明されているように、AAAエージェントは、ローミングや共有使用ネットワークなどのサービスをサポートするために人気を博しています。このようなエージェントは、認証/承認、および会計[RFC2975]の両方に使用されます。
AAA agents include:
AAAエージェントには以下が含まれます。
Relays Proxies Re-directs Store and Forward proxies Transport layer proxies
リレープロキシリダイレクトストアアンドフォワードプロキシトランスポートレイヤープロキシ
The transport layer behavior of each of these agents is described below.
これらの各エージェントの輸送層の動作を以下に説明します。
While the application-layer behavior of relays and proxies are different, at the transport layer the behavior is similar. In both cases, two connections are established: one from the AAA client (NAS) to the relay/proxy, and another from the relay/proxy to the AAA server. The relay/proxy does not respond to a client request until it receives a response from the server. Since the two connections are de-coupled, the end-to-end conversation between the client and server may not self clock.
リレーとプロキシのアプリケーション層の動作は異なりますが、輸送層では動作は似ています。どちらの場合も、2つの接続が確立されます。1つはAAAクライアント（NAS）からリレー/プロキシへ、もう1つはリレー/プロキシからAAAサーバーです。リレー/プロキシは、サーバーから応答を受信するまでクライアント要求に応答しません。2つの接続が分離されているため、クライアントとサーバーの間のエンドツーエンドの会話はセルフクロックではない場合があります。
Since AAA transport is typically application-driven, there is frequently not enough traffic to enable ACK piggybacking. As a result, the Nagle algorithm is rarely triggered, and delayed ACKs may comprise nearly half the traffic. Thus AAA protocols running over reliable transport will see packet traffic nearly double that experienced with UDP transport. Since ACK parameters (such as the value of the delayed ACK timer) are typically fixed by the TCP implementation and are not tunable by the application, there is little that can be done about this.
AAAトランスポートは通常、アプリケーション駆動型であるため、ACKピギーバックを有効にするのに十分なトラフィックがないことがよくあります。その結果、ナグルアルゴリズムがトリガーされることはめったになく、遅延ACKはトラフィックのほぼ半分を構成する可能性があります。したがって、信頼できる輸送を介して実行されるAAAプロトコルは、UDP輸送で経験したパケットトラフィックがほぼ2倍になることがわかります。ACKパラメーター（遅延ACKタイマーの値など）は通常、TCP実装によって固定されており、アプリケーションで調整できないため、これについてできることはほとんどありません。
A typical trace of a conversation between a NAS, proxy and server is shown below:
NAS、プロキシ、サーバー間の会話の典型的な痕跡を以下に示します。
Time NAS Relay/Proxy Server
------ --- ----------- ------
0 Request
------->
OTTnp + Tpr Request
------->
OTTnp + TdA Delayed ACK
<-------
OTTnp + OTTps + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTps +
Tpr + Tsr + Reply
OTTsp + TpR <-------
OTTnp + OTTps +
Tpr + Tsr + Delayed ACK
OTTsp + TdA ------->
OTTnp + OTTps +
OTTsp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Relay/Proxy) OTTpn = One-way trip time (Relay/Proxy to NAS) OTTps = One-way trip time (Relay/Proxy to Server) OTTsp = One-way trip time (Server to Relay/Proxy) TdA = Delayed ACK timer Tpr = Relay/Proxy request processing time TpR = Relay/Proxy reply processing time Tsr = Server request processing time
key --- ott =一元配置旅行時間ottnp =一方向のトリップ時間（nasからリレー/プロキシ）ottpn =一方向のトリップ時間（nasへのリレー/プロキシ）ottps =一方向トリップ時間（リレー/プロキシサーバーへ）OTTSP =一方向のトリップ時間（サーバーからリレー/プロキシ）
At time 0, the NAS sends a request to the relay/proxy. Ignoring the serialization time, the request arrives at the relay/proxy at time OTTnp, and the relay/proxy takes an additional Tpr in order to forward the request toward the home server. At time TdA after receiving the request, the relay/proxy sends a delayed ACK. The delayed ACK is sent, rather than being piggybacked on the reply, as long as TdA < OTTps + OTTsp + Tpr + Tsr + TpR.
時間0に、NASはリレー/プロキシにリクエストを送信します。シリアル化時間を無視すると、リクエストは時刻OTTNPのリレー/プロキシに到着し、リレー/プロキシはリクエストをホームサーバーに転送するために追加のTPRを取得します。時間TDAでリクエストを受け取った後、リレー/プロキシは遅延ACKを送信します。遅延ACKは、TDA <OTTPS OTTSP TPR TSR TPRである限り、返信にピギーバックされるのではなく、送信されます。
Typically Tpr < TdA, so that the delayed ACK is sent after the relay/proxy forwards the request toward the server, but before the relay/proxy receives the reply from the server. However, depending on the TCP implementation on the relay/proxy and when the request is received, it is also possible for the delayed ACK to be sent prior to forwarding the request.
通常、TPR <TDAであるため、リレー/プロキシがリクエストをサーバーに転送した後に遅延ACKが送信されますが、リレー/プロキシがサーバーから返信を受信する前に送信されます。ただし、リレー/プロキシでのTCP実装とリクエストが受信された場合、リクエストを転送する前に遅延ACKを送信することも可能です。
At time OTTnp + OTTps + Tpr, the server receives the request, and Tsr later, it generates the reply. Where Tsr < TdA, the reply will contain a piggybacked ACK. However, depending on the server responsiveness and TCP implementation, the ACK and reply may be sent separately. This can occur, for example, where a slow database or storage system must be accessed prior to sending the reply.
OTTNP OTTPS TPRの時点で、サーバーはリクエストを受信し、TSRは返信を生成します。ここで、TSR <TDA、返信にはピギーバックされたACKが含まれます。ただし、サーバーの応答性とTCP実装に応じて、ACKと応答は個別に送信される場合があります。これは、たとえば、返信を送信する前に遅いデータベースまたはストレージシステムにアクセスする必要がある場合に発生する可能性があります。
At time OTTnp + OTTps + OTTsp + Tpr + Tsr the reply/ACK reaches the relay/proxy, which then takes TpR additional time to forward the reply to the NAS. At TdA after receiving the reply, the relay/proxy generates a delayed ACK. Typically TpR < TdA so that the delayed ACK is sent to the server after the relay/proxy forwards the reply to the NAS. However, depending on the circumstances and the relay/proxy TCP implementation, the delayed ACK may be sent first.
OTTNP OTTPS ottSP TPR TSRの時間に、応答/ACKがリレー/プロキシに到達し、TPRがNASに返信を転送するために追加の時間がかかります。TDAで返信を受け取った後、リレー/プロキシは遅延ACKを生成します。通常、リレー/プロキシがNASへの返信を転送した後、遅延ACKがサーバーに送信されるように、TPR <TDA。ただし、状況とリレー/プロキシTCPの実装に応じて、遅延ACKを最初に送信できます。
As with a delayed ACK sent in response to a request, which may be piggybacked if the reply can be received quickly enough, piggybacking of the ACK sent in response to a reply from the server is only possible if additional request traffic is available. However, due to the high inter-packet spacings in typical AAA scenarios, this is unlikely unless the AAA protocol supports a reply ACK.
リクエストに応じて送信された遅延ACKと同様に、返信を十分に迅速に受信できる場合はピギーバックされる可能性があります。サーバーからの返信に応じて送信されたACKのピギーバックは、追加のリクエストトラフィックが利用可能な場合にのみ可能です。ただし、典型的なAAAシナリオのパケット間間隔が高いため、AAAプロトコルが返信ACKをサポートしていない限り、これはほとんどありません。
At time OTTnp + OTTps + OTTsp + OTTpn + Tpr + Tsr + TpR the NAS receives the reply. TdA later, a delayed ACK is generated.
当時ottnp ottps ottsp ottpn tpr tsr tprが返信を受け取ります。TDAの後、遅延ACKが生成されます。
Re-directs operate by referring a NAS to the AAA server, enabling the NAS to talk to the AAA server directly. Since a direct transport connection is established, the end-to-end connection will self-clock.
Re-Directsは、NASをAAAサーバーに紹介することで動作し、NASがAAAサーバーと直接通信できるようにします。直接輸送接続が確立されるため、エンドツーエンドの接続がセルフクロックになります。
With re-directs, delayed ACKs are less frequent than with application-layer proxies since the Re-direct and Server will typically piggyback replies with ACKs.
リダイレクトを使用すると、遅延ACKは、リダイレクトとサーバーが通常ACKでピギーバックの応答をするため、アプリケーション層プロキシよりも頻繁には少なくなります。
The sequence of events is as follows:
一連のイベントは次のとおりです。
Time NAS Re-direct Server
------ --- --------- ------
0 Request
------->
OTTnp + Tpr Redirect/ACK
<-------
OTTnp + Tpr + Request
OTTpn + Tnr ------->
OTTnp + OTTpn +
Tpr + Tsr + Reply/ACK
OTTns <-------
OTTnp + OTTpn +
OTTns + OTTsn +
Tpr + Tsr + Delayed ACK
TdA ------->
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Re-direct) OTTpn = One-way trip time (Re-direct to NAS) OTTns = One-way trip time (NAS to Server) OTTsn = One-way trip time (Server to NAS) TdA = Delayed ACK timer Tpr = Re-direct processing time Tnr = NAS re-direct processing time Tsr = Server request processing time
key --- ott =一方向の旅行時間ottnp =一方向のトリップ時間（NASから再ダイレクト）ottpn =一方向のトリップ時間（NASに再ダイレクト）ottns =一方向のトリップ時間（NASからサーバーへ）ottsn =一方向のトリップ時間（サーバーからNAS）
With a store and forward proxy, the proxy may send a reply to the NAS prior to forwarding the request to the server. While store and forward proxies are most frequently deployed for accounting [RFC2975], they also can be used to implement authentication/authorization policy, as described in [RFC2607].
ストアとフォワードプロキシを使用すると、リクエストをサーバーに転送する前に、プロキシがNASに返信を送信する場合があります。ストアおよびフォワードプロキシは、会計のために最も頻繁に展開されますが[RFC2975]、[RFC2607]で説明されているように、認証/認証ポリシーを実装するためにも使用できます。
As noted in [RFC2975], store and forward proxies can have a negative effect on accounting reliability. By sending a reply to the NAS without receiving one from the accounting server, store and forward proxies fool the NAS into thinking that the accounting request had been accepted by the accounting server when this is not the case. As a result, the NAS can delete the accounting packet from non-volatile storage before it has been accepted by the accounting server. That leaves the proxy responsible for delivering accounting packets. If the proxy involves moving parts (e.g. a disk drive) while the NAS does not, overall system reliability can be reduced. As a result, store and forward proxies SHOULD NOT be used.
[RFC2975]で述べたように、ストアおよびフォワードプロキシは、会計信頼性に悪影響を与える可能性があります。アカウンティングサーバーから受信せずにNASに返信を送信することにより、NASを欺き、フォワードプロキシを、これがそうでない場合に会計リクエストが会計サーバーによって受け入れられたと考えるようにします。その結果、NASは、会計サーバーが受け入れる前に、不揮発性ストレージから会計パケットを削除できます。これにより、プロキシは会計パケットを配信する責任を負います。プロキシに移動部品（ディスクドライブなど）が含まれている場合、NASはそうではない場合、システム全体の信頼性を低下させることができます。その結果、ストアとフォワードのプロキシを使用しないでください。
The sequence of events is as follows:
一連のイベントは次のとおりです。
Time NAS Proxy Server
------ --- ----- ------
0 Request
------->
OTTnp + TpR Reply/ACK
<-------
OTTnp + Tpr Request
------->
OTTnp + OTTph + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTph +
Tpr + Tsr + Reply
OTThp + TpR <-------
OTTnp + OTTph +
Tpr + Tsr + Delayed ACK
OTThp + TdA ------->
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Proxy) OTTpn = One-way trip time (Proxy to NAS) OTTph = One-way trip time (Proxy to Home server) OTThp = One-way trip time (Home Server to Proxy) TdA = Delayed ACK timer Tpr = Proxy request processing time TpR = Proxy reply processing time Tsr = Server request processing time
key --- ott =一元配置旅行時間ottnp =一方向のトリップ時間（NASからプロキシ）ottpn =一方向のトリップ時間（NASへの代理）ottph =一方向のトリップ時間（ホームサーバーへの代理）ottp =一元配置旅行時間（ホームサーバーからプロキシ）TDA =遅延ACKタイマーTPR =プロキシ要求処理時間TPR =プロキシ応答処理時間TSR =サーバー要求処理時間
In addition to acting as proxies at the application layer, transport layer proxies forward transport ACKs between the AAA client and server. This splices together the client-proxy and proxy-server connections into a single connection that behaves as though it operates end-to-end, exhibiting self-clocking. However, since transport proxies operate at the transport layer, they cannot be implemented purely as applications and they are rarely deployed.
アプリケーションレイヤーでプロキシとして機能することに加えて、輸送層はAAAクライアントとサーバーの間の前方輸送Acksをプロキシします。これにより、クライアントプロキシとプロキシサーバーの接続が、エンドツーエンドで動作し、自己課題を示すように振る舞う単一の接続に接続します。ただし、輸送プロキシは輸送層で動作するため、純粋にアプリケーションとして実装することはできず、めったに展開されません。
With a transport proxy, the sequence of events is as follows:
トランスポートプロキシを使用すると、一連のイベントは次のとおりです。
Time NAS Proxy Home Server
------ --- ----- -----------
0 Request
------->
OTTnp + Tpr Request
------->
OTTnp + OTTph + Reply/ACK
Tpr + Tsr <-------
OTTnp + OTTph +
Tpr + Tsr + Reply/ACK
OTThp + TpR <-------
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TdA ------->
OTTnp + OTTph +
OTThp + OTTpn +
Tpr + Tsr + Delayed ACK
TpR + TpD ------->
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Proxy) OTTpn = One-way trip time (Proxy to NAS) OTTph = One-way trip time (Proxy to Home server) OTThp = One-way trip time (Home Server to Proxy) TdA = Delayed ACK timer Tpr = Proxy request processing time TpR = Proxy reply processing time Tsr = Server request processing time TpD = Proxy delayed ack processing time
key --- ott =一元配置旅行時間ottnp =一方向のトリップ時間（NASからプロキシ）ottpn =一方向のトリップ時間（NASへの代理）ottph =一方向のトリップ時間（ホームサーバーへの代理）ottp =一元配置旅行時間（ホームサーバーからプロキシ）TDA =遅延ACKタイマーTPR =プロキシ要求処理時間TPR =プロキシ応答時間TSR =サーバー要求処理時間TPD =プロキシ遅延ACK処理時間
Intellectual Property Statement
知的財産声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
Acknowledgments
謝辞
Thanks to Allison Mankin of AT&T, Barney Wolff of Databus, Steve Rich of Cisco, Randy Bush of AT&T, Bo Landarv of IP Unplugged, Jari Arkko of Ericsson, and Pat Calhoun of Blackstorm Networks for fruitful discussions relating to AAA transport.
AT＆TのAllison Mankin、DatabusのBarney Wolff、CiscoのSteve Rich、AT＆TのRandy Bush、IP UnpluggedのBo Landarv、EricssonのJari Arkko、およびAAA輸送に関する実りある議論のためのBlackstorm NetworksのPat Calhounに感謝します。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Jonathan Wood Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Jonathan Wood Sun Systems、Inc。901 San Antonio Road Palo Alto、CA 94303
EMail: jonwood@speakeasy.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。