[要約] RFC 2748は、COPS（Common Open Policy Service）プロトコルに関する仕様であり、ネットワークポリシーの管理と制御を目的としています。COPSは、ネットワークデバイスとポリシーサーバー間の通信を提供し、ポリシーの適用と変更を効率的に行うためのフレームワークです。
Network Working Group D. Durham, Ed.
Request for Comments: 2748 Intel
Category: Standards Track J. Boyle
Level 3
R. Cohen
Cisco
S. Herzog
IPHighway
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
The COPS (Common Open Policy Service) Protocol
COPS（一般的なオープンポリシーサービス）プロトコル
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Conventions used in this document
このドキュメントで使用されている規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC-2119]に記載されているように解釈される。
Abstract
概要
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
このドキュメントでは、QoSシグナル伝達プロトコルに対するポリシー制御をサポートするためのシンプルなクライアント/サーバーモデルについて説明します。このモデルは、ポリシーサーバーのメソッドについて仮定するのではなく、サーバーがポリシーリクエストに決定を返すことに基づいています。このモデルは、他の種類のポリシークライアントが将来サポートされるように拡張可能になるように設計されています。ただし、このドキュメントは、将来のタイプのポリシーを実施するための唯一のまたは好ましいアプローチであると主張していません。
Table Of Contents
目次
1. Introduction....................................................3
1.1 Basic Model....................................................4
2. The Protocol....................................................6
2.1 Common Header..................................................6
2.2 COPS Specific Object Formats...................................8
2.2.1 Handle Object (Handle).......................................9
2.2.2 Context Object (Context).....................................9
2.2.3 In-Interface Object (IN-Int)................................10
2.2.4 Out-Interface Object (OUT-Int)..............................11
2.2.5 Reason Object (Reason)......................................12
2.2.6 Decision Object (Decision)..................................12
2.2.7 LPDP Decision Object (LPDPDecision).........................14
2.2.8 Error Object (Error)........................................14
2.2.9 Client Specific Information Object (ClientSI)...............15
2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................16
2.2.12 Report-Type Object (Report-Type)...........................16
2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
2.2.14 Last PDP Address (LastPDPAddr).............................17
2.2.15 Accounting Timer Object (AcctTimer)........................17
2.2.16 Message Integrity Object (Integrity).......................18
2.3 Communication.................................................19
2.4 Client Handle Usage...........................................21
2.5 Synchronization Behavior......................................21
3. Message Content................................................22
3.1 Request (REQ) PEP -> PDP.....................................22
3.2 Decision (DEC) PDP -> PEP....................................24
3.3 Report State (RPT) PEP -> PDP................................25
3.4 Delete Request State (DRQ) PEP -> PDP........................25
3.5 Synchronize State Request (SSQ) PDP -> PEP...................26
3.6 Client-Open (OPN) PEP -> PDP.................................26
3.7 Client-Accept (CAT) PDP -> PEP...............................27
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28
3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
4. Common Operation...............................................29
4.1 Security and Sequence Number Negotiation......................29
4.2 Key Maintenance...............................................31
4.3 PEP Initialization............................................31
4.4 Outsourcing Operations........................................32
4.5 Configuration Operations......................................32
4.6 Keep-Alive Operations.........................................33
4.7 PEP/PDP Close.................................................33
5. Security Considerations........................................33
6. IANA Considerations............................................34
7. References.....................................................35
8. Author Information and Acknowledgments.........................36
9. Full Copyright Statement.......................................38
This document describes a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). One example of a policy client is an RSVP router that must exercise policy-based admission control over RSVP usage [RSVP]. We assume that at least one policy server exists in each controlled administrative domain. The basic model of interaction between a policy server and its clients is compatible with the framework document for policy based admission control [WRK].
このドキュメントでは、ポリシーサーバー（ポリシー決定ポイントまたはPDP）とそのクライアント（ポリシー執行ポイントまたはPEP）との間のポリシー情報を交換するために使用できる簡単なクエリと応答プロトコルについて説明します。ポリシークライアントの1つの例は、RSVP使用法[RSVP]に対するポリシーに基づく入場制御を行使する必要があるRSVPルーターです。制御された各管理ドメインに少なくとも1つのポリシーサーバーが存在すると仮定します。ポリシーサーバーとそのクライアント間の相互作用の基本モデルは、ポリシーベースの入場管理[WRK]のフレームワークドキュメントと互換性があります。
A chief objective of this policy control protocol is to begin with a simple but extensible design. The main characteristics of the COPS protocol include:
このポリシー制御プロトコルの主な目的は、シンプルだが拡張可能な設計から始めることです。COPSプロトコルの主な特徴は次のとおりです。
1. The protocol employs a client/server model where the PEP sends requests, updates, and deletes to the remote PDP and the PDP returns decisions back to the PEP.
1. プロトコルは、PEPがリクエスト、更新、削除をリモートPDPに送信し、PDPが決定をPEPに戻すクライアント/サーバーモデルを採用しています。
2. The protocol uses TCP as its transport protocol for reliable exchange of messages between policy clients and a server. Therefore, no additional mechanisms are necessary for reliable communication between a server and its clients.
2. プロトコルは、ポリシークライアントとサーバー間のメッセージの信頼できる交換のために、TCPをトランスポートプロトコルとして使用します。したがって、サーバーとそのクライアント間の信頼できる通信には、追加のメカニズムは必要ありません。
3. The protocol is extensible in that it is designed to leverage off self-identifying objects and can support diverse client specific information without requiring modifications to the COPS protocol itself. The protocol was created for the general administration, configuration, and enforcement of policies.
3. プロトコルは、自己識別オブジェクトを活用するように設計されており、COPSプロトコル自体の変更を必要とせずに多様なクライアント固有の情報をサポートできるという点で拡張可能です。このプロトコルは、一般的な管理、構成、およびポリシーの実施のために作成されました。
4. COPS provides message level security for authentication, replay protection, and message integrity. COPS can also reuse existing protocols for security such as IPSEC [IPSEC] or TLS to authenticate and secure the channel between the PEP and the PDP.
4. COPSは、認証、リプレイ保護、メッセージの整合性のためのメッセージレベルのセキュリティを提供します。COPは、PEPとPDPの間のチャネルを認証および保護するために、IPSEC [IPSEC]やTLSなどのセキュリティのために既存のプロトコルを再利用することもできます。
5. The protocol is stateful in two main aspects: (1) Request/Decision state is shared between client and server and (2) State from various events (Request/Decision pairs) may be inter-associated. By (1) we mean that requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions from the remote PDP can be generated asynchronously at any time for a currently installed request state. By (2) we mean that the server may respond to new queries differently because of previously installed Request/Decision state(s) that are related.
5. プロトコルは2つの主な側面でステートフルです：（1）クライアントとサーバーの間でリクエスト/決定状態が共有され、（2）さまざまなイベントの状態（リクエスト/決定ペア）が相互に関連する場合があります。（1）とは、クライアントPEPからのリクエストが、PEPによって明示的に削除されるまで、リモートPDPによってインストールまたは記憶されることを意味します。同時に、リモートPDPからの決定は、現在インストールされている要求状態について、いつでも非同期に生成できます。（2）とは、以前にインストールされたリクエスト/決定状態が関連しているため、サーバーが新しいクエリに異なる方法で応答できることを意味します。
6. Additionally, the protocol is stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable.
6. さらに、このプロトコルは、サーバーが構成情報をクライアントにプッシュし、サーバーが適用できなくなったときにクライアントからそのような状態を削除できるようにするという点でステートフルです。
+----------------+
| |
| Network Node | Policy Server
| |
| +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+
| ^ |
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 1: A COPS illustration.
図1：警官のイラスト。
Figure 1 Illustrates the layout of various policy components in a typical COPS example (taken from [WRK]). Here, COPS is used to communicate policy information between a Policy Enforcement Point (PEP) and a remote Policy Decision Point (PDP) within the context of a particular type of client. The optional Local Policy Decision Point (LPDP) can be used by the device to make local policy decisions in the absence of a PDP.
図1は、典型的なCOPSの例（[WRK]から取られた）のさまざまなポリシーコンポーネントのレイアウトを示しています。ここでは、COPSは、特定のタイプのクライアントのコンテキスト内で、ポリシー執行ポイント（PEP）とリモートポリシー決定ポイント（PDP）の間でポリシー情報を伝えるために使用されます。オプションのローカルポリシー決定ポイント（LPDP）は、PDPがない場合にローカルポリシー決定を行うためにデバイスによって使用できます。
It is assumed that each participating policy client is functionally consistent with a PEP [WRK]. The PEP may communicate with a policy server (herein referred to as a remote PDP [WRK]) to obtain policy decisions or directives.
各参加ポリシークライアントは、PEP [WRK]と機能的に一致していると想定されています。PEPは、ポリシーサーバー（ここではリモートPDP [WRK]と呼ばれる）と通信して、ポリシーの決定または指令を取得する場合があります。
The PEP is responsible for initiating a persistent TCP connection to a PDP. The PEP uses this TCP connection to send requests to and receive decisions from the remote PDP. Communication between the PEP and remote PDP is mainly in the form of a stateful request/decision exchange, though the remote PDP may occasionally send unsolicited decisions to the PEP to force changes in previously approved request states. The PEP also has the capacity to report to the remote PDP that it has successfully completed performing the PDP's decision locally, useful for accounting and monitoring purposes. The PEP is responsible for notifying the PDP when a request state has changed on the PEP. Finally, the PEP is responsible for the deletion of any state that is no longer applicable due to events at the client or decisions issued by the server.
PEPは、PDPへの永続的なTCP接続を開始する責任があります。PEPは、このTCP接続を使用してリクエストを送信し、リモートPDPから決定を受け取ります。PEPとリモートPDP間の通信は主にステートフルリクエスト/決定交換の形式ですが、リモートPDPは、以前に承認された要求状態の変更を強制するためにPEPに未承諾の決定を送信することがあります。また、PEPには、会計および監視の目的に役立つPDPの決定の実行をローカルで完了したことをリモートPDPに報告する能力があります。PEPは、PEPで要求状態が変更されたときにPDPに通知する責任があります。最後に、PEPは、クライアントでのイベントまたはサーバーが発行した決定により、もはや適用できない状態の削除に責任があります。
When the PEP sends a configuration request, it expects the PDP to continuously send named units of configuration data to the PEP via decision messages as applicable for the configuration request. When a unit of named configuration data is successfully installed on the PEP, the PEP should send a report message to the PDP confirming the installation. The server may then update or remove the named configuration information via a new decision message. When the PDP sends a decision to remove named configuration data from the PEP, the PEP will delete the specified configuration and send a report message to the PDP as confirmation.
PEPが構成要求を送信すると、PDPは、構成要求に適用されるように、決定メッセージを介して構成データの名前付き単位をPEPに継続的に送信することが予想されます。名前付き構成データのユニットがPEPに正常にインストールされた場合、PEPはインストールを確認するPDPにレポートメッセージを送信する必要があります。サーバーは、新しい決定メッセージを介して指定された構成情報を更新または削除することができます。PDPがPEPから名前付き構成データを削除する決定を送信すると、PEPは指定された構成を削除し、確認としてPDPにレポートメッセージを送信します。
The policy protocol is designed to communicate self-identifying objects which contain the data necessary for identifying request states, establishing the context for a request, identifying the type of request, referencing previously installed requests, relaying policy decisions, reporting errors, providing message integrity, and transferring client specific/namespace information.
ポリシープロトコルは、要求状態を識別し、要求のコンテキストを確立し、リクエストの種類を特定し、以前にインストールしたリクエストの参照、ポリシー決定の中継、エラーの報告、メッセージの整合性の提供、メッセージの整合性の提供、リクエストの識別、メッセージ、メッセージの提供、メッセージの整合、クライアント固有/名前空間情報の転送。
To distinguish between different kinds of clients, the type of client is identified in each message. Different types of clients may have different client specific data and may require different kinds of policy decisions. It is expected that each new client-type will have a corresponding usage draft specifying the specifics of its interaction with this policy protocol.
異なる種類のクライアントを区別するために、各メッセージでクライアントのタイプが識別されます。異なるタイプのクライアントには、クライアント固有のデータが異なる場合があり、異なる種類のポリシー決定が必要になる場合があります。各新しいクライアントタイプは、このポリシープロトコルとの相互作用の詳細を指定する対応する使用法ドラフトを持つことが期待されます。
The context of each request corresponds to the type of event that triggered it. The COPS Context object identifies the type of request and message (if applicable) that triggered a policy event via its message type and request type fields. COPS identifies three types of outsourcing events: (1) the arrival of an incoming message (2) allocation of local resources, and (3) the forwarding of an outgoing message. Each of these events may require different decisions to be made. The content of a COPS request/decision message depends on the context. A fourth type of request is useful for types of clients that wish to receive configuration information from the PDP. This allows a PEP to issue a configuration request for a specific named device or module that requires configuration information to be installed.
各要求のコンテキストは、それをトリガーしたイベントのタイプに対応します。COPSコンテキストオブジェクトは、メッセージタイプとリクエストタイプフィールドを介してポリシーイベントをトリガーしたリクエストとメッセージのタイプ（該当する場合）を識別します。警官は、3種類のアウトソーシングイベントを特定します。（1）着信メッセージの到着（2）ローカルリソースの割り当て、および（3）発信メッセージの転送。これらの各イベントは、さまざまな決定を下す必要がある場合があります。警官のリクエスト/決定メッセージの内容は、コンテキストに依存します。4番目のタイプのリクエストは、PDPから構成情報を受信したいタイプのクライアントに役立ちます。これにより、PEPは、構成情報をインストールする必要がある特定の名前のデバイスまたはモジュールの構成要求を発行できます。
The PEP may also have the capability to make a local policy decision via its Local Policy Decision Point (LPDP) [WRK], however, the PDP remains the authoritative decision point at all times. This means that the relevant local decision information must be relayed to the PDP. That is, the PDP must be granted access to all relevant information to make a final policy decision. To facilitate this functionality, the PEP must send its local decision information to the remote PDP via an LPDP decision object. The PEP must then abide by the PDP's decision as it is absolute.
PEPには、ローカルポリシーの決定点（LPDP）[WRK]を介してローカルポリシーの決定を下す能力もある場合がありますが、PDPは常に権威ある決定点であり続けています。これは、関連するローカル決定情報をPDPに中継する必要があることを意味します。つまり、PDPは、最終的なポリシー決定を下すために、すべての関連情報へのアクセスを許可されなければなりません。この機能を容易にするために、PEPはLPDP決定オブジェクトを介してリモートPDPにローカルの決定情報を送信する必要があります。PEPは、PDPが絶対的であるため、PDPの決定を順守しなければなりません。
Finally, fault tolerance is a required capability for this protocol, particularly due to the fact it is associated with the security and service management of distributed network devices. Fault tolerance can be achieved by having both the PEP and remote PDP constantly verify their connection to each other via keep-alive messages. When a failure is detected, the PEP must try to reconnect to the remote PDP or attempt to connect to a backup/alternative PDP. While disconnected, the PEP should revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any deleted state or new events that passed local admission control after the connection was lost. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued). After failure and before the new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some limited amount of time. Sections 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
最後に、特に分散ネットワークデバイスのセキュリティとサービス管理に関連付けられているという事実により、このプロトコルにはフォールトトレランスが必要です。PEPとリモートの両方のPDPが、キープアライブメッセージを介して互いに接続を常に検証することにより、フォールトトレランスを実現できます。障害が検出された場合、PEPはリモートPDPに再接続しようとするか、バックアップ/代替PDPに接続しようとする必要があります。切断されている間、PEPはローカルの決定を行うことに戻るはずです。接続が再確立されると、PEPは、接続が失われた後に削除された状態またはローカル入場管理に合格した新しいイベントのPDPに通知することが期待されます。さらに、リモートPDPは、すべてのPEPの内部状態を再同期させることを要求する場合があります（以前にインストールされたすべてのリクエストは再発行されます）。障害後および新しい接続が完全に機能する前に、PEPキャッシュが以前に決定した場合、それらを限られた時間の期間使用し続けると、サービスの中断を最小限に抑えることができます。セクション2.3および2.5は、信頼性を達成するためのCOPSメカニズムを詳細に説明します。
This section describes the message formats and objects exchanged between the PEP and remote PDP.
このセクションでは、PEPとリモートPDPの間で交換されるメッセージフォーマットとオブジェクトについて説明します。
Each COPS message consists of the COPS header followed by a number of typed objects.
各COPSメッセージは、COPSヘッダーに続いて多数のタイプされたオブジェクトで構成されています。
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0.
グローバル注：////フィールドは予約されており、0に設定されています。
The fields in the header are: Version: 4 bits COPS version number. Current version is 1.
ヘッダーのフィールドは次のとおりです。バージョン：4ビットCOPSバージョン番号。現在のバージョンは1です。
Flags: 4 bits Defined flag values (all other flags MUST be set to 0): 0x1 Solicited Message Flag Bit This flag is set when the message is solicited by another COPS message. This flag is NOT to be set (value=0) unless otherwise specified in section 3.
フラグ：4ビット定義されたフラグ値（他のすべてのフラグは0に設定する必要があります）：0x1勧誘されたメッセージフラグビットこのフラグは、メッセージが別の警官メッセージによって求められたときに設定されます。このフラグは、セクション3で特に指定されていない限り、設定されない（値= 0）。
Op Code: 8 bits The COPS operations: 1 = Request (REQ) 2 = Decision (DEC) 3 = Report State (RPT) 4 = Delete Request State (DRQ) 5 = Synchronize State Req (SSQ) 6 = Client-Open (OPN) 7 = Client-Accept (CAT) 8 = Client-Close (CC) 9 = Keep-Alive (KA) 10= Synchronize Complete (SSC)
OPコード：8 COPS操作のビット：1 =リクエスト（REQ）2 =決定（dec）3 =レポート状態（RPT）4 =削除要求状態（DRQ）5 = Synchronize state req（ssq）6 = client-open（opn）7 = client-accept（cat）8 = client-close（cc）9 = keep-alive（ka）10 = synchronize complete（ssc）
Client-type: 16 bits
クライアントタイプ：16ビット
The Client-type identifies the policy client. Interpretation of all encapsulated objects is relative to the client-type. Client-types that set the most significant bit in the client-type field are enterprise specific (these are client-types 0x8000 - 0xFFFF). (See the specific client usage documents for particular client-type IDs). For KA Messages, the client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification).
クライアントタイプはポリシークライアントを識別します。すべてのカプセル化されたオブジェクトの解釈は、クライアントタイプに関連しています。クライアントタイプのフィールドで最も重要なビットを設定するクライアントタイプは、エンタープライズ固有です（これらはクライアントタイプ0x8000-0xffffです）。（特定のクライアントタイプのIDの特定のクライアントの使用文書を参照してください）。KAメッセージの場合、KAが接続検証に使用されるため（クライアントセッション検証ではなく）、ヘッダー内のクライアントタイプを常に0に設定する必要があります。
Message Length: 32 bits Size of message in octets, which includes the standard COPS header and all encapsulated objects. Messages MUST be aligned on 4 octet intervals.
メッセージの長さ：標準の警官ヘッダーとすべてのカプセル化されたオブジェクトを含むオクテットのメッセージの32ビットサイズ。メッセージは4オクテット間隔で整列する必要があります。
All the objects follow the same object format; each object consists of one or more 32-bit words with a four-octet header, using the following format:
すべてのオブジェクトは同じオブジェクト形式に従います。各オブジェクトは、次の形式を使用して、4オクテットヘッダーを備えた1つ以上の32ビット単語で構成されています。
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding MUST be added to the end of the object so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary.
長さは、オブジェクトを構成するオクテットの数（ヘッダーを含む）の数を記述する2オクセット値です。オクテットの長さが32ビットワードの境界に当てはまらない場合、オブジェクトの上に送信する前に次の32ビット境界に合わせて、オブジェクトの端にパディングを追加する必要があります。受信側では、以前に記載されていたオブジェクトの長さを次の32ビット境界に切り上げるだけで、後続のオブジェクト境界を見つけることができます。
Typically, C-Num identifies the class of information contained in the object, and the C-Type identifies the subtype or version of the information contained in the object.
通常、C-Numはオブジェクトに含まれる情報のクラスを識別し、Cタイプはオブジェクトに含まれる情報のサブタイプまたはバージョンを識別します。
C-num: 8 bits 1 = Handle 2 = Context 3 = In Interface 4 = Out Interface 5 = Reason code 6 = Decision 7 = LPDP Decision 8 = Error 9 = Client Specific Info 10 = Keep-Alive Timer 11 = PEP Identification 12 = Report Type 13 = PDP Redirect Address 14 = Last PDP Address 15 = Accounting Timer 16 = Message Integrity
C-NUM：8ビット1 =ハンドル2 =コンテキスト3 =インターフェース4 =インターフェース5 =理由コード6 =決定7 = LPDP決定8 =エラー9 =クライアント固有の情報10 =キープアライブタイマー11 = PEP識別12=レポートタイプ13 = PDPリダイレクトアドレス14 =最後のPDPアドレス15 =アカウンティングタイマー16 =メッセージの整合性
C-type: 8 bits Values defined per C-num.
Cタイプ：C-Numごとに定義された8ビット値。
The Handle Object encapsulates a unique value that identifies an installed state. This identification is used by most COPS operations. A state corresponding to a handle MUST be explicitly deleted when it is no longer applicable. See Section 2.4 for details.
ハンドルオブジェクトは、インストールされた状態を識別する一意の値をカプセル化します。この識別は、ほとんどのCOPSオペレーションで使用されます。ハンドルに対応する状態は、適用できなくなったときに明示的に削除する必要があります。詳細については、セクション2.4を参照してください。
C-Num = 1
C-Type = 1, Client Handle.
c-type = 1、クライアントハンドル。
Variable-length field, no implied format other than it is unique from other client handles from the same PEP (a.k.a. COPS TCP connection) for a particular client-type. It is always initially chosen by the PEP and then deleted by the PEP when no longer applicable. The client handle is used to refer to a request state initiated by a particular PEP and installed at the PDP for a client-type. A PEP will specify a client handle in its Request messages, Report messages and Delete messages sent to the PDP. In all cases, the client handle is used to uniquely identify a particular PEP's request for a client-type.
可変長さのフィールド、特定のクライアントタイプの同じPEP（別名Cops TCP接続）からの他のクライアントハンドルと一意のもの以外の暗黙の形式はありません。最初は常にPEPによって選択され、その後、適用されなくなったときにPEPによって削除されます。クライアントハンドルは、特定のPEPによって開始され、クライアントタイプのためにPDPにインストールされた要求状態を参照するために使用されます。PEPは、リクエストメッセージにクライアントハンドルを指定し、メッセージをレポートし、PDPに送信されたメッセージを削除します。すべての場合において、クライアントハンドルは、クライアントタイプに対する特定のPEPのリクエストを一意に識別するために使用されます。
The client handle value is set by the PEP and is opaque to the PDP. The PDP simply performs a byte-wise comparison on the value in this object with respect to the handle object values of other currently installed requests.
クライアントのハンドル値はPEPによって設定され、PDPに不透明です。PDPは、現在インストールされている他のリクエストのハンドルオブジェクト値に関して、このオブジェクトの値に関するバイトごとの比較を実行するだけです。
Specifies the type of event(s) that triggered the query. Required for request messages. Admission control, resource allocation, and forwarding requests are all amenable to client-types that outsource their decision making facility to the PDP. For applicable client-types a PEP can also make a request to receive named configuration information from the PDP. This named configuration data may be in a form useful for setting system attributes on a PEP, or it may be in the form of policy rules that are to be directly verified by the PEP.
クエリをトリガーしたイベントのタイプを指定します。リクエストメッセージに必要です。入場管理、リソースの割り当て、および転送要求はすべて、意思決定施設をPDPに外部委託するクライアントタイプに適しています。該当するクライアントタイプの場合、PEPはPDPから名前付き構成情報を受信することもリクエストすることができます。この名前付き構成データは、PEPでシステム属性を設定するのに役立つ形式である場合があります。または、PEPによって直接検証されるポリシールールの形式である場合があります。
Multiple flags can be set for the same request. This is only allowed, however, if the set of client specific information in the combined request is identical to the client specific information that would be specified if individual requests were made for each specified flag.
同じリクエストに対して複数のフラグを設定できます。ただし、これは許可されていますが、複合リクエストのクライアント固有の情報のセットが、指定されたフラグごとに個々のリクエストが行われた場合に指定されるクライアント固有の情報と同一である場合にのみ許可されます。
C-num = 2, C-Type = 1
c-num = 2、c-type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
R-Type (Request Type Flag)
Rタイプ（リクエストタイプフラグ）
0x01 = Incoming-Message/Admission Control request 0x02 = Resource-Allocation request 0x04 = Outgoing-Message request 0x08 = Configuration request
0x01 = coming-message/Andiming Control Request 0x02 =リソースアロケーションリクエスト0x04 = Outinover-Messageリクエスト0x08 =構成要求
M-Type (Message Type)
Mタイプ（メッセージタイプ）
Client Specific 16 bit values of protocol message types
プロトコルメッセージタイプのクライアント固有の16ビット値
The In-Interface Object is used to identify the incoming interface on which a particular request applies and the address where the received message originated. For flows or messages generated from the PEP's local host, the loop back address and ifindex are used.
インターフェイスオブジェクトは、特定のリクエストが適用される着信インターフェイスと、受信したメッセージが発信されたアドレスを識別するために使用されます。PEPのローカルホストから生成されたフローまたはメッセージの場合、ループバックアドレスとifindexが使用されます。
This Interface object is also used to identify the incoming (receiving) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
このインターフェイスオブジェクトは、IFIndexを介して着信（受信）インターフェイスを識別するためにも使用されます。IFINDEXは、サブインターフェイスと非仮定インターフェイスを区別するために使用できます（例については、RSVPのLIHを参照）。SNMPがPEPによってサポートされている場合、このIfindex整数は、SNMP MIB-IIインターフェイスインデックステーブルのインターフェイスの同じ整数値に対応する必要があります。
Note: The ifindex specified in the In-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the interface on which the protocol message was received.
注：インターフェイスで指定されたIFINDEXは、通常、基礎となるプロトコルメッセージの流れに関連しています。ifindexは、プロトコルメッセージが受信されたインターフェイスです。
C-Num = 3
C-Type = 1, IPv4 Address + Interface
C-Type = 1、IPv4アドレスインターフェイス
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies the IP address that the incoming message came from.
このタイプのインターフェイスオブジェクトの場合、IPv4アドレスは、着信メッセージが生じたIPアドレスを指定します。
C-Type = 2, IPv6 Address + Interface
C-Type = 2、IPv6アドレスインターフェイス
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies the IP address that the incoming message came from. The ifindex is used to refer to the MIB-II defined local incoming interface on the PEP as described above.
このタイプのインターフェイスオブジェクトの場合、IPv6アドレスは、着信メッセージが生じたIPアドレスを指定します。IFINDEXは、上記のようにPEP上のMIB-II定義されたローカル着信インターフェイスを参照するために使用されます。
The Out-Interface is used to identify the outgoing interface to which a specific request applies and the address for where the forwarded message is to be sent. For flows or messages destined to the PEP's local host, the loop back address and ifindex are used. The Out-Interface has the same formats as the In-Interface Object.
アウトインターフェイスは、特定のリクエストが適用される発信インターフェイスと、転送されたメッセージが送信される場所のアドレスを識別するために使用されます。PEPのローカルホストに運命づけられたフローまたはメッセージの場合、ループバックアドレスとifindexが使用されます。アウトインターフェイスには、インターフェイスオブジェクトと同じ形式があります。
This Interface object is also used to identify the outgoing (forwarding) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
このインターフェイスオブジェクトは、IFIndexを介して発信（転送）インターフェイスを識別するためにも使用されます。IFINDEXは、サブインターフェイスと非仮定インターフェイスを区別するために使用できます（例については、RSVPのLIHを参照）。SNMPがPEPによってサポートされている場合、このIfindex整数は、SNMP MIB-IIインターフェイスインデックステーブルのインターフェイスの同じ整数値に対応する必要があります。
Note: The ifindex specified in the Out-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the one on which a protocol message is about to be forwarded.
注：外部インターフェイスで指定されているifindexは、通常、基礎となるプロトコルメッセージの流れに関連しています。ifindexは、プロトコルメッセージが転送されようとしているものです。
C-Num = 4
C-Type = 1, IPv4 Address + Interface
C-Type = 1、IPv4アドレスインターフェイス
Same C-Type format as the In-Interface object. The IPv4 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
インターフェイスオブジェクトと同じCタイプ形式。IPv4アドレスは、発信メッセージが進行するIPアドレスを指定します。IFINDEXは、PEP上のMIB-II定義されたローカル発信インターフェイスを参照するために使用されます。
C-Type = 2, IPv6 Address + Interface
C-Type = 2、IPv6アドレスインターフェイス
Same C-Type format as the In-Interface object. For this type of the interface object, the IPv6 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
インターフェイスオブジェクトと同じCタイプ形式。このタイプのインターフェイスオブジェクトの場合、IPv6アドレスは、発信メッセージが進行しているIPアドレスを指定します。IFINDEXは、PEP上のMIB-II定義されたローカル発信インターフェイスを参照するために使用されます。
This object specifies the reason why the request state was deleted. It appears in the delete request (DRQ) message. The Reason Sub-code field is reserved for more detailed client-specific reason codes defined in the corresponding documents.
このオブジェクトは、要求状態が削除された理由を指定します。削除要求（DRQ）メッセージに表示されます。サブコードフィールドの理由は、対応するドキュメントで定義されているより詳細なクライアント固有の理由コードのために予約されています。
C-Num = 5, C-Type = 1
c-num = 5、c-type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+
Reason Code: 1 = Unspecified 2 = Management 3 = Preempted (Another request state takes precedence) 4 = Tear (Used to communicate a signaled state removal) 5 = Timeout (Local state has timed-out) 6 = Route Change (Change invalidates request state) 7 = Insufficient Resources (No local resource available) 8 = PDP's Directive (PDP decision caused the delete) 9 = Unsupported decision (PDP decision not supported) 10= Synchronize Handle Unknown 11= Transient Handle (stateless event) 12= Malformed Decision (could not recover) 13= Unknown COPS Object from PDP: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type.
理由コード：1 =不特定の2 =管理3 =先制（別の要求状態が優先される）4 =ティア（シグナル付きの状態除去の通信に使用）州）7 =リソース不足（ローカルリソースは利用できません）8 = PDPの指令（PDP決定が削除を引き起こした）9 =サポートされていない決定（PDP決定がサポートされていない）（回復できません）13 = PDPからの不明なCOPSオブジェクト：サブコード（Octet 2）は不明なオブジェクトのC-Numを含み、（Octet 3）は不明なオブジェクトのC型を含みます。
Decision made by the PDP. Appears in replies. The specific non-mandatory decision objects required in a decision to a particular request depend on the type of client.
PDPによる決定。返信に表示されます。特定のリクエストへの決定に必要な特定の非監視決定オブジェクトは、クライアントのタイプによって異なります。
C-Num = 6 C-Type = 1, Decision Flags (Mandatory)
c-num = 6 c-type = 1、決定フラグ（必須）
0 1 2 3
+--------------+--------------+--------------+--------------+
| Command-Code | Flags |
+--------------+--------------+--------------+--------------+
Commands: 0 = NULL Decision (No configuration data available) 1 = Install (Admit request/Install configuration) 2 = Remove (Remove request/Remove configuration)
コマンド：0 = null決定（構成データは使用できません）
Flags: 0x01 = Trigger Error (Trigger error message if set) Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages.
フラグ：0x01 =トリガーエラー（設定の場合はトリガーエラーメッセージ）注：[シグナル]メッセージのエラー通知を送信できるクライアントタイプにトリガーエラーが適用されます。
Flag values not applicable to a given context's R-Type or client-type MUST be ignored by the PEP.
特定のコンテキストのRタイプまたはクライアントタイプに適用されないフラグ値は、PEPによって無視する必要があります。
C-Type = 2, Stateless Data
C-Type = 2、ステートレスデータ
This type of decision object carries additional stateless information that can be applied by the PEP locally. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. This object is optional in Decision messages and is interpreted relative to a given context.
このタイプの決定オブジェクトには、PEPがローカルに適用できる追加のステートレス情報が搭載されています。これは可変長さのオブジェクトであり、その内部形式は、指定されたクライアントタイプの関連するCOPS拡張ドキュメントで指定する必要があります。このオブジェクトは決定メッセージでオプションであり、特定のコンテキストに対して解釈されます。
It is expected that even outsourcing PEPs will be able to make some simple stateless policy decisions locally in their LPDP. As this set is well known and implemented ubiquitously, PDPs are aware of it as well (either universally, through configuration, or using the Client-Open message). The PDP may also include this information in its decision, and the PEP MUST apply it to the resource allocation event that generated the request.
ペップをアウトソーシングすることでさえ、LPDPでいくつかの簡単なステートレスポリシーの決定をローカルに行うことができると予想されます。このセットはよく知られており、遍在的に実装されているため、PDPはそれを認識しています（普遍的に、構成を通じて、またはクライアントオープンメッセージを使用して）。PDPには、この情報を決定に含めることもでき、PEPはリクエストを生成したリソース割り当てイベントに適用する必要があります。
C-Type = 3, Replacement Data
C-Type = 3、交換データ
This type of decision object carries replacement data that is to replace existing data in a signaled message. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
このタイプの決定オブジェクトには、既存のデータを信号済みメッセージに置き換えるための交換データが含まれています。これは可変長さのオブジェクトであり、その内部形式は、指定されたクライアントタイプの関連するCOPS拡張ドキュメントで指定する必要があります。決定メッセージではオプションであり、特定のコンテキストに関連して解釈されます。
C-Type = 4, Client Specific Decision Data
C-Type = 4、クライアント固有の決定データ
Additional decision types can be introduced using the Client Specific Decision Data Object. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
追加の決定タイプは、クライアント固有の決定データオブジェクトを使用して導入できます。これは可変長さのオブジェクトであり、その内部形式は、指定されたクライアントタイプの関連するCOPS拡張ドキュメントで指定する必要があります。決定メッセージではオプションであり、特定のコンテキストに関連して解釈されます。
C-Type = 5, Named Decision Data
C-Type = 5、名前付き決定データ
Named configuration information is encapsulated in this version of the decision object in response to configuration requests. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to both a given context and decision flags.
名前の構成情報は、構成要求に応じてこのバージョンの決定オブジェクトにカプセル化されています。これは可変長さのオブジェクトであり、その内部形式は、指定されたクライアントタイプの関連するCOPS拡張ドキュメントで指定する必要があります。決定メッセージではオプションであり、特定のコンテキストと決定フラグの両方に関連して解釈されます。
Decision made by the PEP's local policy decision point (LPDP). May appear in requests. These objects correspond to and are formatted the same as the client specific decision objects defined above.
PEPのローカルポリシー決定ポイント（LPDP）による決定。リクエストに表示される場合があります。これらのオブジェクトは、上記で定義されたクライアント固有の決定オブジェクトに対応し、フォーマットされています。
C-Num = 7
C-Type = (same C-Type as for Decision objects)
This object is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client specific error codes. The appropriate Error Sub-codes for a particular client-type SHOULD be specified in the relevant COPS extensions document.
このオブジェクトは、特定のCOPSプロトコルエラーを識別するために使用されます。エラーサブコードフィールドには、追加の詳細なクライアント固有のエラーコードが含まれています。特定のクライアントタイプの適切なエラーサブコードは、関連するCOPS拡張ドキュメントで指定する必要があります。
C-Num = 8, C-Type = 1
c-num = 8、c-type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
Error-Code:
エラーコード：
1 = Bad handle 2 = Invalid handle reference 3 = Bad message format (Malformed Message) 4 = Unable to process (server gives up on query) 5 = Mandatory client-specific info missing 6 = Unsupported client-type 7 = Mandatory COPS object missing 8 = Client Failure 9 = Communication Failure 10= Unspecified 11= Shutting down 12= Redirect to Preferred Server 13= Unknown COPS Object: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type. 14= Authentication Failure 15= Authentication Required
1 =ハンドル2 =無効なハンドルリファレンス3 =悪いメッセージフォーマット（不正なメッセージ）4 =処理できません（サーバーはクエリであきらめます）5 =必須クライアント固有の情報欠落6 =サポートされていないクライアントタイプ78 =クライアントの失敗9 =通信失敗10 =不特定11 =シャットダウン12 =優先サーバーへのリダイレクト=不明なCOPSオブジェクト：サブコード（Octet 2）は不明なオブジェクトのC-Numと（Octet 3）が含まれ、不明なオブジェクトのC-が含まれます。タイプ。14 =認証障害15 =認証が必要です
The various types of this object are required for requests, and used in reports and opens when required. It contains client-type specific information.
このオブジェクトのさまざまなタイプは、リクエストに必要であり、レポートで使用され、必要に応じて開きます。クライアントタイプの特定の情報が含まれています。
C-Num = 9,
c-num = 9、
C-Type = 1, Signaled ClientSI.
c-type = 1、シグナル付きクライアントi。
Variable-length field. All objects/attributes specific to a client's signaling protocol or internal state are encapsulated within one or more signaled Client Specific Information Objects. The format of the data encapsulated in the ClientSI object is determined by the client-type.
可変長いフィールド。クライアントの信号プロトコルまたは内部状態に固有のすべてのオブジェクト/属性は、1つまたは複数のシグナル付きクライアント固有の情報オブジェクト内でカプセル化されます。Clientsiオブジェクトにカプセル化されたデータの形式は、クライアントタイプによって決定されます。
C-Type = 2, Named ClientSI.
c-type = 2、名前付きクライアント。
Variable-length field. Contains named configuration information useful for relaying specific information about the PEP, a request, or configured state to the PDP server.
可変長いフィールド。PEP、リクエスト、またはPDPサーバーに構成された状態に関する特定の情報を中継するのに役立つ名前の構成情報が含まれています。
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
時間は2オクテットの整数値としてエンコードされ、秒単位です。タイマー値はデルタとして扱われます。
C-Num = 10,
c-num = 10、
C-Type = 1, Keep-alive timer value
c-type = 1、キープアライブタイマー値
Timer object used to specify the maximum time interval over which a COPS message MUST be sent or received. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity.
COPSメッセージを送信または受信する必要がある最大時間間隔を指定するために使用されるタイマーオブジェクト。有限のタイムアウトの範囲は、署名されていない2オクテットの整数として表される1〜65535秒です。ゼロの値は無限を意味します。
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+
The PEP Identification Object is used to identify the PEP client to the remote PDP. It is required for Client-Open messages.
PEP識別オブジェクトは、PEPクライアントをリモートPDPに識別するために使用されます。クライアントが開くメッセージに必要です。
C-Num = 11, C-Type = 1
c-num = 11、c-type = 1
Variable-length field. It is a NULL terminated ASCII string that is also zero padded to a 32-bit word boundary (so the object length is a multiple of 4 octets). The PEPID MUST contain an ASCII string that uniquely identifies the PEP within the policy domain in a manner that is persistent across PEP reboots. For example, it may be the PEP's statically assigned IP address or DNS name. This identifier may safely be used by a PDP as a handle for identifying the PEP in its policy rules.
可変長いフィールド。これは、32ビットワードの境界にパッドで塗装されたゼロの終端ASCII文字列です（したがって、オブジェクトの長さは4オクテットの倍数です）。Pepidには、PEPの再起動全体で永続的な方法でポリシードメイン内のPEPを一意に識別するASCII文字列を含める必要があります。たとえば、PEPの静的に割り当てられたIPアドレスまたはDNS名である場合があります。この識別子は、PDPがポリシールールでPEPを識別するためのハンドルとして安全に使用できます。
The Type of Report on the request state associated with a handle:
ハンドルに関連付けられている要求状態に関するレポートのタイプ：
C-Num = 12, C-Type = 1
c-num = 12、c-type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
Report-Type:
1 = Success : Decision was successful at the PEP
2 = Failure : Decision could not be completed by PEP
3 = Accounting: Accounting update for an installed state
A PDP when closing a PEP session for a particular client-type may optionally use this object to redirect the PEP to the specified PDP server address and TCP port number:
特定のクライアントタイプのPEPセッションを閉じるときのPDPは、オプションでこのオブジェクトを使用して、指定されたPDPサーバーアドレスとTCPポート番号にPEPをリダイレクトする場合があります。
C-Num = 13,
c-num = 13、
C-Type = 1, IPv4 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
When a PEP sends a Client-Open message for a particular client-type the PEP SHOULD specify the last PDP it has successfully opened (meaning it received a Client-Accept) since the PEP last rebooted. If no PDP was used since the last reboot, the PEP will simply not include this object in the Client-Open message.
PEPが特定のクライアントタイプのクライアントオープンメッセージを送信すると、PEPが最後に再起動したため、PEPが正常に開いた最後のPDPを指定する必要があります。最後の再起動以来PDPが使用されていない場合、PEPはクライアントオープンメッセージにこのオブジェクトを単に含めません。
C-Num = 14,
c-num = 14、
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
c-type = 1、ipv4アドレス（pdprediraddrと同じ形式）
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
c-type = 2、ipv6アドレス（pdprediraddrと同じ形式）
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
時間は2オクテットの整数値としてエンコードされ、秒単位です。タイマー値はデルタとして扱われます。
C-Num = 15,
c-num = 15、
C-Type = 1, Accounting timer value
C-Type = 1、アカウンティングタイマー値
Optional timer value used to determine the minimum interval between periodic accounting type reports. It is used by the PDP to describe to the PEP an acceptable interval between unsolicited accounting updates via Report messages where applicable. It provides a method for the PDP to control the amount of accounting traffic seen by the network. The range of finite time values is 1 to 65535 seconds represented as an unsigned two-octet integer. A value of zero means there SHOULD be no unsolicited accounting updates.
定期的な会計タイプレポート間の最小間隔を決定するために使用されるオプションのタイマー値。PDPは、該当する場合はレポートメッセージを介して未承諾の会計更新間の許容可能な間隔をPEPに記述するために使用されます。PDPがネットワークで見られる会計トラフィックの量を制御する方法を提供します。有限時間値の範囲は、署名されていない2オクテットの整数として表される1〜65535秒です。ゼロの値は、未承諾の会計更新が必要であることを意味します。
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
The integrity object includes a sequence number and a message digest useful for authenticating and validating the integrity of a COPS message. When used, integrity is provided at the end of a COPS message as the last COPS object. The digest is then computed over all of a particular COPS message up to but not including the digest value itself. The sender of a COPS message will compute and fill in the digest portion of the Integrity object. The receiver of a COPS message will then compute a digest over the received message and verify it matches the digest in the received Integrity object.
整合性オブジェクトには、COPSメッセージの整合性を認証および検証するのに役立つシーケンス番号とメッセージダイジェストが含まれます。使用すると、COPSメッセージの最後に最後のCOPSオブジェクトとして整合性が提供されます。Digestは、特定のCOPSメッセージのすべてで計算されますが、Digest値自体を含めません。COPSメッセージの送信者は、整合性オブジェクトのダイジェスト部分を計算して記入します。COPSメッセージの受信者は、受信したメッセージの上にダイジェストを計算し、受信した整合性オブジェクトのダイジェストと一致することを確認します。
C-Num = 16,
c-num = 16、
C-Type = 1, HMAC digest
C-Type = 1、HMACダイジェスト
The HMAC integrity object employs HMAC (Keyed-Hashing for Message Authentication) [HMAC] to calculate the message digest based on a key shared between the PEP and its PDP.
HMAC Integrityオブジェクトは、HMAC（メッセージ認証用のキー付きハッシュ）[HMAC]を使用して、PEPとそのPDPの間で共有されたキーに基づいてメッセージダイジェストを計算します。
This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular PEP and its PDP and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the PEP with corresponding keys on the PDP for the given PEPID. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 96-bits to calculate the message digest.
この整合性オブジェクトは、特定のPEPとそのPDPの間で共有された特定のキーと、使用する暗号化アルゴリズムを識別するために使用される32ビットキーIDを指定します。キーIDを使用すると、指定された疫病のPDPに対応するキーを備えた複数の同時キーがPEPに存在します。キーIDによって識別されたキーは、整合性オブジェクトでメッセージダイジェストを計算するために使用されました。すべての実装は、少なくとも、MD5メッセージダイジェストアルゴリズム[MD5]を採用して96ビットに切り捨ててメッセージダイジェストを計算するHMACであるHMAC-MD5-96をサポートする必要があります。
This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero.
このオブジェクトには、リプレイ攻撃を避けるために使用される32ビットの符号なし整数であるシーケンス番号も含まれています。シーケンス番号は、最初のクライアントオープンクライアントアセプトメッセージ交換中に開始され、新しいメッセージがTCP接続を介して同じ方向に送信されるたびにインクリメントされます。シーケンス番号が0xffffffffffの値に達した場合、次の増分はゼロの値にロールオーバーするだけです。
The variable length digest is calculated over a COPS message starting with the COPS Header up to the Integrity Object (which MUST be the last object in a COPS message) INCLUDING the Integrity object's header, Key ID, and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
可変長さダイジェストは、整合性オブジェクトのヘッダー、キーID、およびシーケンス番号を含む、COPSヘッダー（これはCOPSメッセージの最後のオブジェクトである必要があります）から始まるCOPSメッセージで計算されます。キー付きメッセージダイジェストフィールドは、ダイジェスト計算の一部として含まれていません。HMAC-MD5-96の場合、HMAC-MD5は128ビットダイジェストを生成し、[HMAC]で指定されているように、キー付きメッセージダイジェストフィールドに保存または検証する前に96ビットに切り捨てられます。HMAC-MD5-96を使用する場合、キー付きメッセージダイジェストは96ビットでなければなりません。
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP implementation per server MUST listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP is responsible for initiating the TCP connection to a PDP. The location of the remote PDP can either be configured, or obtained via a service location mechanism [SRVLOC]. Service discovery is outside the scope of this protocol, however.
COPSプロトコルは、PEPとリモートPDPの間に単一の永続的なTCP接続を使用します。サーバーごとの1つのPDP実装は、よく知られているTCPポート番号（COPS = 3288 [IANA]）で聞く必要があります。PEPは、PDPへのTCP接続を開始する責任があります。リモートPDPの位置は、サービスの位置メカニズム[srvloc]を介して構成するか、取得できます。ただし、サービスの発見はこのプロトコルの範囲外です。
If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client-type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform.
単一のPEPが複数のクライアントタイプをサポートできる場合、複数のクライアントオープンメッセージを送信する場合があります。各クライアントタイプを1つ以上のTCP接続でPDPに指定します。同様に、特定のアドレスとポート番号に居住するPDPは、1つ以上のクライアントタイプをサポートする場合があります。サポートするクライアントタイプを考えると、PDPには、各クライアントタイプを個別に受け入れるか拒否する能力があります。クライアントタイプが拒否された場合、PDPはCOPを介して特定のクライアントタイプの代替PDPアドレスとTCPポートにPEPをリダイレクトできます。異なるTCPポート番号を使用して、PEPを同じサーバーで実行している別のPDP実装にリダイレクトできます。単一のリモートPDPサーバーで複数のクライアントタイプ（おそらく独立したPDPベンダーから）をサポートするための追加の規定は、COPSプロトコルによって提供されませんが、むしろ、特定のサーバープラットフォームのソフトウェアアーキテクチャに任されています。
It is possible a single PEP may have open connections to multiple PDPs. This is the case when there are physically different PDPs supporting different client-types as shown in figure 2.
単一のPEPが複数のPDPにオープンな接続を持つ可能性があります。これは、図2に示すように、異なるクライアントタイプをサポートする物理的に異なるPDPがある場合です。
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 2: Multiple PDPs illustration.
図2：複数のPDPイラスト。
When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type containing an <Error> object indicating the "Communication Failure" Error-Code. Additionally, the PEP SHOULD continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a <Client-Close> message containing a <PDPRedirAddr> object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
TCP接続が取り壊されたり、失われたりすると、PDPは最終的に、PEPとのリクエスト/決定交換に関連する未解決のリクエスト状態をクリーンアップすることが予想されます。タイムアウト条件のためにPEPが失われた接続を検出すると、「通信障害」エラーコードを示す<エラー>オブジェクトを含む各オープンクライアントタイプのクライアントクライアントメッセージを明示的に送信する必要があります。さらに、PEPは、プライマリPDPまたは失敗した場合、既知のバックアップPDPに継続的に接触しようとする必要があります。具体的には、PEPは、接続を確立できるまで構成されているすべての関連するPDPを試してみる必要があります。PEPがバックアップPDPと通信し、プライマリPDPが利用可能になった場合、バックアップPDPはPEPをプライマリPDPにリダイレクトする責任があります（プライマリPDPを識別するA <PDPrediraddr>オブジェクトを含む<クライアントクロース>メッセージを介して影響を受ける各クライアントタイプに使用する）。セクション2.5では、PEPとPDP間の同期動作を詳しく説明しています。
The client handle is used to identify a unique request state for a single PEP per client-type. Client handles are chosen by the PEP and are opaque to the PDP. The PDP simply uses the request handle to uniquely identify the request state for a particular Client-Type over a particular TCP connection and generically tie its decisions to a corresponding request. Client handles are initiated in request messages and are then used by subsequent request, decision, and report messages to reference the same request state. When the PEP is ready to remove a local request state, it will issue a delete message to the PDP for the corresponding client handle. A handle MUST be explicitly deleted by the PEP before it can be used by the PEP to identify a new request state. Handles referring to different request states MUST be unique within the context of a particular TCP connection and client-type.
クライアントハンドルは、クライアントタイプごとに単一のPEPの一意の要求状態を識別するために使用されます。クライアントハンドルはPEPによって選択され、PDPに不透明です。PDPは、リクエストハンドルを使用して、特定のTCP接続を介した特定のクライアントタイプのリクエスト状態を一意に識別し、その決定を対応する要求に一般的に結びます。クライアントハンドルはリクエストメッセージで開始され、その後のリクエスト、決定、およびレポートメッセージによって使用され、同じ要求状態を参照します。PEPがローカルリクエスト状態を削除する準備ができたら、対応するクライアントハンドルのPDPに削除メッセージを発行します。ハンドルは、PEPがPEPによって使用して新しいリクエスト状態を識別する前に、PEPによって明示的に削除する必要があります。異なる要求状態を参照するハンドルは、特定のTCP接続とクライアントタイプのコンテキスト内で一意でなければなりません。
When disconnected from a PDP, the PEP SHOULD revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any events that have passed local admission control. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message.
PDPから切断されると、PEPは現地の決定を行うことに戻る必要があります。接続が再確立されると、PEPはPDPにローカルの入場管理に合格したイベントの通知に通知することが期待されます。さらに、リモートPDPは、同期状態メッセージを送信することにより、すべてのPEPの内部状態を再同期させる（以前にインストールされたすべてのリクエストを再発行する）ように要求する場合があります。
After a failure and before a new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some appropriate length of time. Specific rules for such behavior are to be defined in the appropriate COPS client-type extension specifications.
障害の後、新しい接続が完全に機能する前に、PEPキャッシュが以前に決定を伝え、適切な期間にわたってそれらを使用し続けると、サービスの中断を最小限に抑えることができます。このような動作に関する特定のルールは、適切なCOPSクライアントタイプの拡張仕様で定義されます。
A PEP that caches state from a previous exchange with a disconnected PDP MUST communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. The <LastPDPAddr> object will only be included for the last PDP with which the PEP was completely in sync. If the service interruption was temporary and the PDP still contains the complete state for the PEP, the PDP may choose not to synchronize all states. It is still the responsibility of the PEP to update the PDP of all state changes that occurred during the disruption of service including any states communicated to the previous PDP that had been deleted after the connection was lost. These MUST be explicitly deleted after a connection is reestablished. If the PDP issues a synchronize request the PEP MUST pass all current states to the PDP followed by a Synchronize State Complete message (thus completing the synchronization process). If the PEP crashes and loses all cached state for a client-type, it will simply not include a <LastPDPAddr> in its Client-Open message.
切断されたPDPとの以前の交換からのキャッシュをキャッシュするPEPは、この事実を後で再接続できるPDPに伝えなければなりません。これは、クライアントオープンメッセージにPEPがまだキャッシュ状態である最後のPDPのアドレスとTCPポートを含めることによって達成されます。<lastpdpaddr>オブジェクトは、PEPが完全に同期していた最後のPDPにのみ含まれます。サービスの中断が一時的であり、PDPにPEPの完全な状態がまだ含まれている場合、PDPはすべての状態を同期しないことを選択できます。接続が失われた後に削除された以前のPDPに通知された状態を含む、サービスの混乱の間に発生したすべての州の変更のPDPを更新することは、依然としてPEPの責任です。これらは、接続が再確立された後に明示的に削除する必要があります。PDPが同期要求を発行する場合、PEPはすべての現在の状態をPDPに渡す必要があり、その後に状態の完全なメッセージが同期しなければなりません（したがって、同期プロセスを完了します）。PEPがクライアントタイプのためにすべてのキャッシュ状態をクラッシュさせて失った場合、クライアントがオープンするメッセージに<lastPdPaddr>を単に含めません。
This section describes the basic messages exchanged between a PEP and a remote PDP as well as their contents. As a convention, object ordering is expected as shown in the BNF for each COPS message unless otherwise noted. The Integrity object, if included, MUST always be the last object in a message. If security is required and a message was received without a valid Integrity object, the receiver MUST send a Client-Close message for Client-Type=0 specifying the appropriate error code.
このセクションでは、PEPとリモートPDPの間で交換される基本的なメッセージとその内容について説明します。慣習として、特に明記しない限り、各COPSメッセージのBNFに示されているように、オブジェクトの注文が予想されます。整合性オブジェクトは、含まれている場合は、常にメッセージの最後のオブジェクトでなければなりません。セキュリティが必要であり、有効な整合性オブジェクトなしでメッセージが受信された場合、受信者は、適切なエラーコードを指定するクライアントタイプ= 0のクライアントクローズメッセージを送信する必要があります。
The PEP establishes a request state client handle for which the remote PDP may maintain state. The remote PDP then uses this handle to refer to the exchanged information and decisions communicated over the TCP connection to a particular PEP for a given client-type.
PEPは、リモートPDPが状態を維持できる要求状態クライアントハンドルを確立します。リモートPDPは、このハンドルを使用して、特定のクライアントタイプの特定のPEPへのTCP接続を介して伝えられた交換された情報と決定を参照します。
Once a stateful handle is established for a new request, any subsequent modifications of the request can be made using the REQ message specifying the previously installed handle. The PEP is responsible for notifying the PDP whenever its local state changes so the PDP's state will be able to accurately mirror the PEP's state.
新しいリクエストのためにステートフルハンドルが確立されると、以前にインストールされたハンドルを指定するREQメッセージを使用して、リクエストの後続の変更を行うことができます。PEPは、PDPの状態が変更されるたびにPDPに通知する責任があり、PDPの状態がPEPの状態を正確に反映できるようになります。
The format of the Request message is as follows:
リクエストメッセージの形式は次のとおりです。
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LPDPDecision(s)> ::= <LPDPDecision> |
<LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
The context object is used to determine the context within which all the other objects are to be interpreted. It also is used to determine the kind of decision to be returned from the policy server. This decision might be related to admission control, resource allocation, object forwarding and substitution, or configuration.
コンテキストオブジェクトは、他のすべてのオブジェクトを解釈するコンテキストを決定するために使用されます。また、ポリシーサーバーから返される決定の種類を決定するためにも使用されます。この決定は、入場制御、リソース割り当て、オブジェクトの転送と代替、または構成に関連する可能性があります。
The interface objects are used to determine the corresponding interface on which a signaling protocol message was received or is about to be sent. They are typically used if the client is participating along the path of a signaling protocol or if the client is requesting configuration data for a particular interface.
インターフェイスオブジェクトは、信号プロトコルメッセージが受信された、または送信される対応するインターフェイスを決定するために使用されます。通常、クライアントが信号プロトコルのパスに沿って参加している場合、またはクライアントが特定のインターフェイスの構成データを要求している場合に使用されます。
ClientSI, the client specific information object, holds the client-type specific data for which a policy decision needs to be made. In the case of configuration, the Named ClientSI may include named information about the module, interface, or functionality to be configured. The ordering of multiple ClientSIs is not important.
クライアント固有の情報オブジェクトであるClientsiは、ポリシー決定を行う必要があるクライアントタイプの特定のデータを保持します。構成の場合、指定されたクライアントには、構成するモジュール、インターフェイス、または機能に関する指定された情報が含まれる場合があります。複数のクライアントの順序付けは重要ではありません。
Finally, LPDPDecision object holds information regarding the local decision made by the LPDP.
最後に、LPDPDECISIONオブジェクトは、LPDPが下したローカル決定に関する情報を保持します。
Malformed Request messages MUST result in the PDP specifying a Decision message with the appropriate error code.
奇形の要求メッセージは、適切なエラーコードを使用して決定メッセージを指定するPDPになる必要があります。
The PDP responds to the REQ with a DEC message that includes the associated client handle and one or more decision objects grouped relative to a Context object and Decision Flags object type pair. If there was a protocol error an error object is returned instead.
PDPは、関連するクライアントハンドルと、コンテキストオブジェクトと決定フラグのオブジェクトタイプペアに対してグループ化された1つ以上の決定オブジェクトを含むDECメッセージでREQに応答します。プロトコルエラーがあった場合、代わりにエラーオブジェクトが返されます。
It is required that the first decision message for a new/updated request will have the solicited message flag set (value = 1) in the COPS header. This avoids the issue of keeping track of which updated request (that is, a request reissued for the same handle) a particular decision corresponds. It is important that, for a given handle, there be at most one outstanding solicited decision per request. This essentially means that the PEP SHOULD NOT issue more than one REQ (for a given handle) before it receives a corresponding DEC with the solicited message flag set. The PDP MUST always issue decisions for requests on a particular handle in the order they arrive and all requests MUST have a corresponding decision.
新しい/更新されたリクエストの最初の決定メッセージには、Copsヘッダーに勧誘されたメッセージフラグセット（値= 1）が表示される必要があります。これにより、どの更新された要求（つまり、同じハンドルに対して再発行されたリクエスト）を追跡するという問題が回避されます。特定のハンドルについて、リクエストごとに最大1つの未解決の勧誘決定があることが重要です。これは、本質的に、PEPが、勧誘されたメッセージフラグセットで対応するDECを受信する前に、1つ以上のREQ（特定のハンドルに対して）を発行してはならないことを意味します。PDPは、特定のハンドルで到着する順序で常にリクエストの決定を発行する必要があり、すべてのリクエストには対応する決定が必要です。
To avoid deadlock, the PEP can always timeout after issuing a request that does not receive a decision. It MUST then delete the timed-out handle, and may try again using a new handle.
デッドロックを避けるために、決定を受け取らないリクエストを発行した後、PEPは常にタイムアウトできます。次に、タイムアウトしたハンドルを削除する必要があり、新しいハンドルを使用して再試行する場合があります。
The format of the Decision message is as follows:
決定メッセージの形式は次のとおりです。
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
[<Decision: Named Data>]
The Decision message may include either an Error object or one or more context plus associated decision objects. COPS protocol problems are reported in the Error object (e.g. an error with the format of the original request including malformed request messages, unknown COPS objects in the Request, etc.). The applicable Decision object(s) depend on the context and the type of client. The only ordering requirement for decision objects is that the required Decision Flags object type MUST precede the other Decision object types per context binding.
決定メッセージには、エラーオブジェクトまたは1つ以上のコンテキストと関連する決定オブジェクトのいずれかが含まれます。COPSプロトコルの問題は、エラーオブジェクトに報告されます（例えば、不正な要求メッセージ、要求の不明なCOPSオブジェクトなどを含む元のリクエストの形式のエラー）。該当する決定オブジェクトは、コンテキストとクライアントのタイプに依存します。決定オブジェクトの唯一の順序付け要件は、必要な決定フラグオブジェクトタイプが、コンテキストバインディングごとに他の決定オブジェクトタイプに先行する必要があることです。
The RPT message is used by the PEP to communicate to the PDP its success or failure in carrying out the PDP's decision, or to report an accounting related change in state. The Report-Type specifies the kind of report and the optional ClientSI can carry additional information per Client-Type.
RPTメッセージは、PEPがPDPに伝え、PDPの決定を実行することに成功または失敗を伝えるため、または州の会計関連の変化を報告するために使用されます。レポートタイプは、レポートの種類を指定し、オプションのクライアントはクライアントタイプごとに追加情報を掲載できます。
For every DEC message containing a configuration context that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. In addition, outsourcing decisions from the PDP MAY result in a corresponding solicited Report State from the PEP depending on the context and the type of client. RPT messages solicited by decisions for a given Client Handle MUST set the Solicited Message flag and MUST be sent in the same order as their corresponding Decision messages were received. There MUST never be more than one Report State message generated with the Solicited Message flag set per Decision.
PEPによって受信される構成コンテキストを含むDECごとのメッセージごとに、PEPは、構成決定の適用における成功または失敗を説明する要請されたメッセージフラグセットで対応するレポート状態メッセージを生成する必要があります。さらに、PDPからのアウトソーシングの決定により、コンテキストとクライアントのタイプに応じて、PEPから対応する勧誘されたレポート状態が生じる場合があります。特定のクライアントハンドルの決定によって勧誘されるRPTメッセージは、勧誘されたメッセージフラグを設定する必要があり、対応する決定メッセージが受信されたのと同じ順序で送信する必要があります。決定ごとに勧誘されたメッセージフラグセットで生成されたレポート状態メッセージは1つ以上ありません。
The Report State may also be used to provide periodic updates of client specific information for accounting and state monitoring purposes depending on the type of the client. In such cases the accounting report type should be specified utilizing the appropriate client specific information object.
レポート状態は、クライアントのタイプに応じて、会計および州の監視目的でクライアント固有の情報の定期的な更新を提供するためにも使用できます。このような場合、適切なクライアント固有の情報オブジェクトを使用して、会計レポートタイプを指定する必要があります。
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
When sent from the PEP this message indicates to the remote PDP that the state identified by the client handle is no longer available/relevant. This information will then be used by the remote PDP to initiate the appropriate housekeeping actions. The reason code object is interpreted with respect to the client-type and signifies the reason for the removal.
PEPから送信されると、このメッセージは、クライアントハンドルによって識別された状態が利用可能/関連性がなくなったことをリモートPDPに示します。この情報は、リモートPDPによって適切なハウスキーピングアクションを開始するために使用されます。コードオブジェクトがクライアントタイプに関して解釈され、削除の理由を意味します。
The format of the Delete Request State message is as follows:
削除要求状態メッセージの形式は次のとおりです。
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
Given the stateful nature of COPS, it is important that when a request state is finally removed from the PEP, a DRQ message for this request state is sent to the PDP so the corresponding state may likewise be removed on the PDP. Request states not explicitly deleted by the PEP will be maintained by the PDP until either the client session is closed or the connection is terminated.
警官のステートフルな性質を考えると、要求状態が最終的にPEPから削除されると、この要求状態のDRQメッセージがPDPに送信されるため、対応する状態が同様にPDPで削除されることが重要です。PEPによって明示的に削除されない要求状態は、クライアントセッションが閉じられるか、接続が終了するまでPDPによって維持されます。
Malformed Decision messages MUST trigger a DRQ specifying the appropriate erroneous reason code (Bad Message Format) and any associated state on the PEP SHOULD either be removed or re-requested. If a Decision contained an unknown COPS Decision Object, the PEP MUST delete its request specifying the Unknown COPS Object reason code because the PEP will be unable to comply with the information contained in the unknown object. In any case, after issuing a DRQ, the PEP may retry the corresponding Request again.
奇形の決定メッセージは、適切な誤った理由コード（悪いメッセージ形式）を指定するDRQをトリガーする必要があり、PEPの関連状態は削除または再リケートする必要があります。決定に不明なCOPS決定オブジェクトが含まれていた場合、PEPは不明なオブジェクトに含まれる情報に準拠することができないため、不明なCOPSオブジェクト理由コードを指定する要求を削除する必要があります。いずれにせよ、DRQを発行した後、PEPは対応するリクエストを再度再試行する場合があります。
The format of the Synchronize State Query message is as follows:
Synchronize Stateクエリメッセージの形式は次のとおりです。
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
This message indicates that the remote PDP wishes the client (which appears in the common header) to re-send its state. If the optional Client Handle is present, only the state associated with this handle is synchronized. If the PEP does not recognize the requested handle, it MUST immediately send a DRQ message to the PDP for the handle that was specified in the SSQ message. If no handle is specified in the SSQ message, all the active client state MUST be synchronized with the PDP.
このメッセージは、リモートPDPがクライアント（共通ヘッダーに表示される）がその状態を再除去することを望んでいることを示しています。オプションのクライアントハンドルが存在する場合、このハンドルに関連付けられた状態のみが同期されます。PEPが要求されたハンドルを認識していない場合、SSQメッセージで指定されたハンドルのPDPにDRQメッセージをすぐに送信する必要があります。SSQメッセージにハンドルが指定されていない場合、すべてのアクティブなクライアント状態をPDPと同期する必要があります。
The client performs state synchronization by re-issuing request queries of the specified client-type for the existing state in the PEP. When synchronization is complete, the PEP MUST issue a synchronize state complete message to the PDP.
クライアントは、PEPの既存の状態の指定されたクライアントタイプの要求クエリを再発行することにより、状態同期を実行します。同期が完了した場合、PEPはPDPに状態完全メッセージを同期する必要があります。
The Client-Open message can be used by the PEP to specify to the PDP the client-types the PEP can support, the last PDP to which the PEP connected for the given client-type, and/or client specific feature negotiation. A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes).
クライアントにオープンするメッセージは、PEPによってPDPに指定され、PEPがサポートできるクライアントタイプを指定することができます。クライアントオープンメッセージはいつでもPDPに送信でき、同じクライアントタイプの複数のクライアントオープンメッセージが許可されます（グローバルな状態の変更の場合）。
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
The PEPID is a symbolic, variable length name that uniquely identifies the specific client to the PDP (see Section 2.2.11).
Pepidは、特定のクライアントをPDPに一意に識別する象徴的で可変長さの名前です（セクション2.2.11を参照）。
A named ClientSI object can be included for relaying additional global information about the PEP to the PDP when required (as specified in the appropriate extensions document for the client-type).
必要に応じて（クライアントタイプの適切な拡張機能ドキュメントで指定されているように）、PEPに関する追加のグローバル情報を中継するために、指名されたclientsiオブジェクトを含めることができます。
The PEP may also provide a Last PDP Address object in its Client-Open message specifying the last PDP (for the given client-type) for which it is still caching decisions since its last reboot. A PDP can use this information to determine the appropriate synchronization behavior (See section 2.5).
また、PEPは、クライアントオープンメッセージに最後のPDP（指定されたクライアントタイプ用）を指定する最後のPDPアドレスオブジェクトを提供する場合があります。PDPはこの情報を使用して、適切な同期動作を決定できます（セクション2.5を参照）。
If the PDP receives a malformed Client-Open message it MUST generate a Client-Close message specifying the appropriate error code.
PDPが不正なクライアントオープンメッセージを受信した場合、適切なエラーコードを指定するクライアントクローズメッセージを生成する必要があります。
The Client-Accept message is used to positively respond to the Client-Open message. This message will return to the PEP a timer object indicating the maximum time interval between keep-alive messages. Optionally, a timer specifying the minimum allowed interval between accounting report messages may be included when applicable.
クライアントacceptメッセージは、クライアントオープンメッセージに積極的に応答するために使用されます。このメッセージは、キープアライブメッセージ間の最大時間間隔を示すタイマーオブジェクトのPEPに戻ります。オプションで、会計レポートメッセージ間の最小許容間隔を指定するタイマーは、該当する場合に含めることができます。
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
If the PDP refuses the client, it will instead issue a Client-Close message.
PDPがクライアントを拒否した場合、代わりにクライアントクローズメッセージを発行します。
The KA Timer corresponds to maximum acceptable intermediate time between the generation of messages by the PDP and PEP. The timer value is determined by the PDP and is specified in seconds. A timer value of 0 implies no secondary connection verification is necessary.
KAタイマーは、PDPとPEPによるメッセージの生成の間の最大許容可能な中間時間に対応します。タイマー値はPDPによって決定され、秒で指定されます。0のタイマー値は、二次接続の検証が必要ないことを意味します。
The optional ACCT Timer allows the PDP to indicate to the PEP that periodic accounting reports SHOULD NOT exceed the specified timer interval per client handle. This allows the PDP to control the rate at which accounting reports are sent by the PEP (when applicable).
オプションのACCTタイマーにより、PDPは、定期的な会計レポートがクライアントハンドルごとに指定されたタイマー間隔を超えてはならないことをPEPに示すことができます。これにより、PDPは会計レポートがPEPによって送信されるレートを制御できます（該当する場合）。
In general, accounting type Report messages are sent to the PDP when determined appropriate by the PEP. The accounting timer merely is used by the PDP to keep the rate of such updates in check (i.e. Preventing the PEP from blasting the PDP with accounting reports). Not including this object implies there are no PDP restrictions on the rate at which accounting updates are generated.
一般に、会計タイプのレポートメッセージは、PEPによって適切であると判断された場合、PDPに送信されます。会計タイマーは、PDPがそのような更新のレートを抑えるために単に使用されるだけです（つまり、PEPが会計レポートでPDPを爆破するのを防ぎます）。このオブジェクトを含めないと、会計更新が生成されるレートにPDP制限がないことを意味します。
If the PEP receives a malformed Client-Accept message it MUST generate a Client-Close message specifying the appropriate error code.
PEPが奇形のクライアントacceptメッセージを受信した場合、適切なエラーコードを指定するクライアントクローズメッセージを生成する必要があります。
The Client-Close message can be issued by either the PDP or PEP to notify the other that a particular type of client is no longer being supported.
クライアントクロースメッセージは、PDPまたはPEPによって発行され、特定のタイプのクライアントがサポートされなくなったことを他のものに通知できます。
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
The Error object is included to describe the reason for the close (e.g. the requested client-type is not supported by the remote PDP or client failure).
エラーオブジェクトは、終了の理由を説明するために含まれています（たとえば、要求されたクライアントタイプは、リモートPDPまたはクライアントの障害によってサポートされていません）。
A PDP MAY optionally include a PDP Redirect Address object in order to inform the PEP of the alternate PDP it SHOULD use for the client-type specified in the common header.
PDPには、一般的なヘッダーで指定されたクライアントタイプに使用する代替PDPをPEPに通知するために、PDPリダイレクトアドレスオブジェクトをオプションに含めることができます。
The keep-alive message MUST be transmitted by the PEP within the period defined by the minimum of all KA Timer values specified in all received CAT messages for the connection. A KA message MUST be generated randomly between 1/4 and 3/4 of this minimum KA timer interval. When the PDP receives a keep-alive message from a PEP, it MUST echo a keep-alive back to the PEP. This message provides validation for each side that the connection is still functioning even when there is no other messaging.
キープアライブメッセージは、接続のすべての受信したCATメッセージで指定されたすべてのKAタイマー値の最小値で定義された期間内にPEPによって送信されなければなりません。KAメッセージは、この最小KAタイマー間隔の1/4から3/4の間でランダムに生成する必要があります。PDPがPEPからキープアライブメッセージを受信した場合、PEPに維持することをエコーする必要があります。このメッセージは、他のメッセージがない場合でも、接続がまだ機能していることを各側の検証を提供します。
Note: The client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification).
注：ヘッダーのクライアントタイプは、KAが接続検証に使用されるため、常に0に設定する必要があります（クライアントセッション検証ごとではありません）。
<Keep-Alive> ::= <Common Header>
[<Integrity>]
Both client and server MAY assume the TCP connection is insufficient for the client-type with the minimum time value (specified in the CAT message) if no communication activity is detected for a period exceeding the timer period. For the PEP, such detection implies the remote PDP or connection is down and the PEP SHOULD now attempt to use an alternative/backup PDP.
クライアントとサーバーの両方が、タイマー期間を超える期間に通信アクティビティが検出されない場合、最小時間値（CATメッセージで指定）でTCP接続がクライアントタイプでは不十分であると仮定する場合があります。PEPの場合、そのような検出はリモートPDPまたは接続がダウンしていることを意味し、PEPは代替/バックアップPDPの使用を試みる必要があります。
The Synchronize State Complete is sent by the PEP to the PDP after the PDP sends a synchronize state request to the PEP and the PEP has finished synchronization. It is useful so that the PDP will know when all the old client state has been successfully re-requested and, thus, the PEP and PDP are completely synchronized. The Client Handle object only needs to be included if the corresponding Synchronize State Message originally referenced a specific handle.
Synchronize State CompleteはPEPによってPDPに送信され、PDPがPEPに同期状態要求を送信し、PEPが同期を終了した後に送信されます。PDPがすべての古いクライアント状態が正常に再起動されたことを知るため、PEPとPDPが完全に同期されることを知ることが有用です。クライアントハンドルオブジェクトは、対応する同期状態メッセージが元々特定のハンドルを参照した場合にのみ含める必要があります。
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
This section describes the typical exchanges between remote PDP servers and PEP clients.
このセクションでは、リモートPDPサーバーとPEPクライアント間の典型的な交換について説明します。
COPS message security is negotiated once per connection and covers all communication over a particular connection. If COPS level security is required, it MUST be negotiated during the initial Client-Open/Client-Accept message exchange specifying a Client-Type of zero (which is reserved for connection level security negotiation and connection verification).
COPSメッセージセキュリティは接続ごとに1回交渉され、特定の接続を介したすべての通信をカバーします。COPSレベルのセキュリティが必要な場合は、クライアントタイプのゼロ（接続レベルのセキュリティ交渉と接続検証のために予約されている）を指定する最初のクライアントオープン/クライアント - アクセプトメッセージ交換中にネゴシエートする必要があります。
If a PEP is not configured to use COPS security with a PDP it will simply send the PDP Client-Open messages for the supported Client-Types as specified in section 4.3 and will not include the Integrity object in any COPS messages.
PEPがPDPでCOPSセキュリティを使用するように構成されていない場合、セクション4.3で指定されているように、サポートされているクライアントタイプのPDPクライアントオープンメッセージを単に送信し、COPSメッセージに整合性オブジェクトを含めません。
Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the PDP to increment during subsequent communication after the initial Client-Open/Client-Accept exchange and the Key ID identifying the algorithm and key used to compute the digest.
それ以外の場合、PDPが他のクライアントタイプを開く前にクライアントタイプ= 0を使用してクライアントオープンメッセージを送信する場合、セキュリティはPEPによって開始できます。PDPがクライアントタイプ= 0でクライアントを受信した場合、他のクライアントタイプが既に正常に開かれた後、クライアントクローズメッセージ（クライアントタイプ= 0の場合）をそのPEPに返す必要があります。この最初のクライアントオープンメッセージは、クライアントタイプのゼロを指定する必要があり、PEPIDとCOPSの整合性オブジェクトを提供する必要があります。この整合性オブジェクトには、最初のクライアントオープン/クライアント - アセプト交換後の後続の通信と、ダイジェストの計算に使用されるキーを識別するキーIDの後、PEPが後続の通信中にPDPを要求する初期シーケンス番号が含まれます。
Similarly, if the PDP accepts the PEP's security key and algorithm by validating the message digest using the identified key, the PDP MUST send a Client-Accept message with a Client-Type of zero to the PEP carrying an Integrity object. This Integrity object will contain the initial sequence number the PDP requires the PEP to increment during all subsequent communication with the PDP and the Key ID identifying the key and algorithm used to compute the digest.
同様に、PDPが識別されたキーを使用してメッセージダイジェストを検証することによりPEPのセキュリティキーとアルゴリズムを受け入れる場合、PDPは、整合性オブジェクトを運ぶPEPにクライアントタイプのゼロでクライアントacceptメッセージを送信する必要があります。この整合性オブジェクトには、PDPがPDPとのすべての後続の通信中にPEPが増加する必要がある初期シーケンス番号と、ダイジェストの計算に使用されるキーとアルゴリズムを識別するキーIDが含まれます。
If the PEP, from the perspective of a PDP that requires security, fails or never performs the security negotiation by not sending an initial Client-Open message with a Client-Type=0 including a valid Integrity object, the PDP MUST send to the PEP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Similarly, if the PDP, from the perspective of a PEP that requires security, fails the security negotiation by not sending back a Client-Accept message with a Client-Type=0 including a valid Integrity object, the PEP MUST send to the PDP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Such a Client-Close message need not carry an integrity object (as the security negotiation did not yet complete).
PEPは、セキュリティを必要とするPDPの観点から、有効な整合性オブジェクトを含むクライアントタイプ= 0を使用して最初のクライアントオープンメッセージを送信しないことでセキュリティネゴシエーションを失敗または実行しない場合、PDPはPEPに送信する必要があります適切なエラーコードを指定するクライアントタイプ= 0のクライアントクロースメッセージ。同様に、セキュリティを必要とするPEPの観点からPDPが、有効な整合性オブジェクトを含むクライアントタイプ= 0を含むクライアントacceptメッセージを返送しないことにより、セキュリティ交渉に失敗する場合、PEPはPDPに送信する必要があります。適切なエラーコードを指定するクライアントタイプ= 0のクライアントクロースメッセージ。このようなクライアントクロースメッセージは、セキュリティ交渉がまだ完了していないため）整合性オブジェクトを搭載する必要はありません。
The security initialization can fail for one of several reasons: 1. The side receiving the message requires COPS level security but an Integrity object was not provided (Authentication Required error code). 2. A COPS Integrity object was provided, but with an unknown/unacceptable C-Type (Unknown COPS Object error code specifying the unsupported C-Num and C-Type). 3. The message digest or Key ID in the provided Integrity object was incorrect and therefore the message could not be authenticated using the identified key (Authentication Failure error code).
セキュリティの初期化は、いくつかの理由のいずれかで失敗する可能性があります。1。メッセージを受信する側には、COPSレベルのセキュリティが必要ですが、整合性オブジェクトは提供されませんでした（認証が必要なエラーコード）。2. COPSの整合性オブジェクトが提供されましたが、未知/容認できないCタイプ（サポートされていないC-NumおよびCタイプを指定するCOPSオブジェクトエラーコードが不明）があります。3.提供された整合性オブジェクトのメッセージダイジェストまたはキーIDが正しくなかったため、識別されたキー（認証障害エラーコード）を使用してメッセージを認証できませんでした。
Once the initial security negotiation is complete, the PEP will know what sequence numbers the PDP expects and the PDP will know what sequence numbers the PEP expects. ALL COPS messages must then include the negotiated Integrity object specifying the correct sequence number with the appropriate message digest (including the Client-Open/Client-Accept messages for specific Client-Types). ALL subsequent messages from the PDP to the PEP MUST result in an increment of the sequence number provided by the PEP in the Integrity object of the initial Client-Open message. Likewise, ALL subsequent messages from the PEP to the PDP MUST result in an increment of the sequence number provided by the PDP in the Integrity object of the initial Client-Accept message. Sequence numbers are incremented by one starting with the corresponding initial sequence number. For example, if the sequence number specified to the PEP by the PDP in the initial Client-Accept was 10, the next message the PEP sends to the PDP will provide an Integrity object with a sequence number of 11... Then the next message the PEP sends to the PDP will have a sequence number of 12 and so on. If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped.
最初のセキュリティ交渉が完了すると、PEPはPDPが予想するシーケンス番号を把握し、PDPはPEPが期待するシーケンス番号を知ります。すべてのCOPSメッセージには、適切なメッセージダイジェスト（特定のクライアントタイプのクライアントオープン/クライアント - アクセプトメッセージを含む）を使用して正しいシーケンス番号を指定するネゴシエートされた整合性オブジェクトを含める必要があります。PDPからPEPへの後続のすべてのメッセージは、最初のクライアントオープンメッセージの整合性オブジェクトでPEPによって提供されるシーケンス番号の増加をもたらす必要があります。同様に、PEPからPDPへの後続のすべてのメッセージは、最初のクライアントacceptメッセージの整合性オブジェクトでPDPによって提供されるシーケンス番号の増加をもたらす必要があります。シーケンス番号は、対応する初期シーケンス番号から始まるものによって増加します。たとえば、最初のクライアントacceptでPDPによってPEPに指定されたシーケンス番号が10である場合、PEPがPDPに送信する次のメッセージは、11のシーケンス番号を持つ整合性オブジェクトを提供します...PEPはPDPに送信され、シーケンス数は12などになります。後続の受信メッセージには、間違ったシーケンス番号、未知のキーID、無効なメッセージダイジェスト、または整合性が交渉された後に整合性オブジェクトが欠落している場合、有効なクライアントタイプのゼロに対してクライアントクロースメッセージを生成する必要があります。整合性オブジェクトと適切なエラーコードの指定。その後、接続を削除する必要があります。
Key maintenance is outside the scope of this document, but COPS implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used to produce the Integrity object's message digest is identified by the Key ID field. Thus, a Key ID parameter is used to identify one of potentially multiple simultaneous keys shared by the PEP and PDP. A Key ID is relative to a particular PEPID on the PDP or to a particular PDP on the PEP. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all COPS implementations MUST support the HMAC-MD5-96 [HMAC][MD5] cryptographic algorithm for computing a message digest for inclusion in the Keyed Message Digest of the Integrity object which is appended to the message.
キーメンテナンスはこのドキュメントの範囲外ですが、COPSの実装は、少なくともキーとそのパラメーターをローカルで手動で構成する機能を提供する必要があります。Integrityオブジェクトのメッセージダイジェストを作成するために使用されるキーは、キーIDフィールドによって識別されます。したがって、キーIDパラメーターを使用して、PEPとPDPで共有される潜在的に複数の同時キーの1つを識別します。キーIDは、PDPの特定の疫病またはPEPの特定のPDPに関連しています。また、各キーは、有効な期間のライフタイムパラメーターと、キーで使用するアルゴリズムを指定する関連する暗号化アルゴリズムパラメーターで構成する必要があります。少なくとも、すべてのCOPS実装は、メッセージに追加された整合性オブジェクトのキー付きメッセージダイジェストに含めるためのメッセージダイジェストを計算するためのHMAC-MD5-96 [HMAC] [MD5]暗号化アルゴリズムをサポートする必要があります。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not.
定期的にキーを変更することをお勧めします。キーは、寿命が重複してキー間のスムーズな遷移を可能にするように構成可能でなければなりません。生涯の2つのキー間の重複の中間点では、送信者は現在のキーを使用してから次/長寿命キーに移行する必要があります。一方、受信者は、構成された寿命内で受信された識別されたキーを受け入れ、そうでないものを拒否するだけです。
Sometime after a connection is established between the PEP and a remote PDP and after security is negotiated (if required), the PEP will send one or more Client-Open messages to the remote PDP, one for each client-type supported by the PEP. The Client-Open message MUST contain the address of the last PDP with which the PEP is still caching a complete set of decisions. If no decisions are being cached from the previous PDP the LastPDPAddr object MUST NOT be included in the Client-Open message (see Section 2.5). Each Client-Open message MUST at least contain the common header noting one client-type supported by the PEP. The remote PDP will then respond with separate Client-Accept messages for each of the client-types requested by the PEP that the PDP can also support.
PEPとリモートPDPの間に接続が確立された後、セキュリティがネゴシエートされた後（必要に応じて）、PEPはPEPでサポートされている各クライアントタイプの1つ以上のクライアントオープンメッセージをリモートPDPに送信します。クライアントオープンメッセージには、PEPがまだ完全な決定セットをキャッシュしている最後のPDPのアドレスを含める必要があります。以前のPDPから決定がキャッシュされていない場合、LastPDPADDRオブジェクトをクライアントオープンメッセージに含めてはなりません（セクション2.5を参照）。各クライアントがオープンするメッセージは、少なくともPEPでサポートされている1つのクライアントタイプに注目する共通ヘッダーを含める必要があります。リモートPDPは、PDPがサポートできるPEPによって要求された各クライアントタイプに対して、個別のクライアントアセプトメッセージで応答します。
If a specific client-type is not supported by the PDP, the PDP will instead respond with a Client-Close specifying the client-type is not supported and will possibly suggest an alternate PDP address and port. Otherwise, the PDP will send a Client-Accept specifying the timer interval between keep-alive messages and the PEP may begin issuing requests to the PDP.
特定のクライアントタイプがPDPによってサポートされていない場合、PDPは代わりにクライアント型を指定するクライアントクローズで応答し、代替PDPアドレスとポートを示唆する可能性があります。それ以外の場合、PDPは、Keep-AliveメッセージとPEPの間のタイマー間隔を指定するクライアントacceptを送信し、PDPへのリクエストの発行を開始する場合があります。
In the outsourcing scenario, when the PEP receives an event that requires a new policy decision it sends a request message to the remote PDP. What specifically qualifies as an event for a particular client-type SHOULD be specified in the specific document for that client-type. The remote PDP then makes a decision and sends a decision message back to the PEP. Since the request is stateful, the request will be remembered, or installed, on the remote PDP. The unique handle (unique per TCP connection and client-type), specified in both the request and its corresponding decision identifies this request state. The PEP is responsible for deleting this request state once the request is no longer applicable.
アウトソーシングシナリオでは、PEPが新しいポリシー決定を必要とするイベントを受け取ると、リクエストメッセージをリモートPDPに送信します。特定のクライアントタイプのイベントとして特に適格であるものは、そのクライアントタイプの特定のドキュメントで指定する必要があります。その後、リモートPDPは決定を下し、決定メッセージをPEPに送り返します。リクエストはステートフルであるため、リクエストはリモートPDPに記憶されるか、インストールされます。リクエストとその対応する決定の両方で指定された一意のハンドル（TCP接続ごとの一意の接続とクライアントタイプ）は、このリクエスト状態を特定します。PEPは、リクエストが適用されなくなったら、このリクエスト状態を削除する責任があります。
The PEP can update a previously installed request state by reissuing a request for the previously installed handle. The remote PDP is then expected to make new decisions and send a decision message back to the PEP. Likewise, the server MAY change a previously issued decision on any currently installed request state at any time by issuing an unsolicited decision message. At all times the PEP module is expected to abide by the PDP's decisions and notify the PDP of any state changes.
PEPは、以前にインストールされたハンドルのリクエストを再発行することにより、以前にインストールされた要求状態を更新できます。リモートPDPは、新しい決定を下し、決定メッセージをPEPに送信することが期待されます。同様に、サーバーは、未承諾の決定メッセージを発行することにより、いつでも現在インストールされている要求状態で以前に発行された決定を変更する場合があります。常にPEPモジュールは、PDPの決定を順守し、PDPに州の変更を通知することが期待されています。
In the configuration scenario, as in the outsourcing scenario, the PEP will make a configuration request to the PDP for a particular interface, module, or functionality that may be specified in the named client specific information object. The PDP will then send potentially several decisions containing named units of configuration data to the PEP. The PEP is expected to install and use the configuration locally. A particular named configuration can be updated by simply sending additional decision messages for the same named configuration. When the PDP no longer wishes the PEP to use a piece of configuration information, it will send a decision message specifying the named configuration and a decision flags object with the remove configuration command. The PEP SHOULD then proceed to remove the corresponding configuration and send a report message to the PDP that specifies it has been deleted.
構成シナリオでは、アウトソーシングシナリオのように、PEPは、指定されたクライアント固有の情報オブジェクトで指定される可能性のある特定のインターフェイス、モジュール、または機能に対してPDPに構成要求を行います。PDPは、設定データの名前付き単位を含む潜在的にいくつかの決定をPEPに送信します。PEPは、構成をローカルにインストールして使用することが期待されています。特定の名前の構成は、同じ名前の構成に対して追加の決定メッセージを送信するだけで更新できます。PDPがPEPに構成情報を使用することを希望しなくなった場合、削除構成コマンドを使用して、指定された構成と決定フラグを指定する決定メッセージが送信されます。PEPは、対応する構成を削除し、削除されたことを指定するPDPにレポートメッセージを送信するように進みます。
In all cases, the PEP MAY notify the remote PDP of the local status of an installed state using the report message where appropriate. The report message is to be used to signify when billing can begin, what actions were taken, or to produce periodic updates for monitoring and accounting purposes depending on the client. This message can carry client specific information when needed.
すべての場合において、PEPは、必要に応じてレポートメッセージを使用して、インストールされた状態のローカルステータスのリモートPDPに通知する場合があります。レポートメッセージは、請求がいつ開始できるか、どのようなアクションが実行されたかを示すために、またはクライアントに応じて監視および会計目的で定期的な更新を作成するために使用されます。このメッセージは、必要に応じてクライアント固有の情報を運ぶことができます。
The Keep-Alive message is used to validate the connection between the client and server is still functioning even when there is no other messaging from the PEP to PDP. The PEP MUST generate a COPS KA message randomly within one-fourth to three-fourths the minimum KA Timer interval specified by the PDP in the Client-Accept message. On receiving a Keep-Alive message from the PEP, the PDP MUST then respond to this Keep-Alive message by echoing a Keep-Alive message back to the PEP. If either side does not receive a Keep-Alive or any other COPS message within the minimum KA Timer interval from the other, the connection SHOULD be considered lost.
キープアライブメッセージは、PEPからPDPへの他のメッセージがない場合でも、クライアントとサーバー間の接続を検証するために使用されます。PEPは、クライアントacceptメッセージでPDPによって指定された最小KAタイマー間隔を4分の1から4分の3以内にCOPS KAメッセージをランダムに生成する必要があります。PEPからキープアライブメッセージを受信すると、PDPはPEPにキープアライブメッセージをエコーすることにより、このキープアライブメッセージに応答する必要があります。どちらかの側が、最小Kaタイマー間隔内で他のkaタイマー間隔内でキープアライブまたはその他のCOPメッセージを受け取らない場合、接続は失われたと見なされる必要があります。
Finally, Client-Close messages are used to negate the effects of the corresponding Client-Open messages, notifying the other side that the specified client-type is no longer supported/active. When the PEP detects a lost connection due to a keep-alive timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type specifying a communications failure error code. Then the PEP MAY proceed to terminate the connection to the PDP and attempt to reconnect again or try a backup/alternative PDP. When the PDP is shutting down, it SHOULD also explicitly send a Client-Close to all connected PEPs for each client-type, perhaps specifying an alternative PDP to use instead.
最後に、クライアントクローズメッセージは、対応するクライアントオープンメッセージの効果を無効にするために使用され、指定されたクライアントタイプがもはやサポート/アクティブではないことを反対側に通知します。PEPがキープアライブタイムアウト条件のために失われた接続を検出すると、通信障害エラーコードを指定する各オープンクライアントタイプのクライアントクローズメッセージを明示的に送信する必要があります。その後、PEPはPDPへの接続を終了し、もう一度再接続するか、バックアップ/代替PDPを試してみることができます。PDPがシャットダウンされている場合、各クライアントタイプの接続されたすべてのPEPにクライアントクロースを明示的に送信し、代わりに使用する代替PDPを指定する必要があります。
The COPS protocol provides an Integrity object that can achieve authentication, message integrity, and replay prevention. All COPS implementations MUST support the COPS Integrity object and its mechanisms as described in this document. To ensure the client (PEP) is communicating with the correct policy server (PDP) requires authentication of the PEP and PDP using a shared secret, and consistent proof that the connection remains valid. The shared secret minimally requires manual configuration of keys (identified by a Key ID) shared between the PEP and its PDP. The key is used in conjunction with the contents of a COPS message to calculate a message digest that is part of the Integrity object. The Integrity object is then used to validate all COPS messages sent over the TCP connection between a PEP and PDP.
COPSプロトコルは、認証、メッセージの整合性、およびリプレイ防止を実現できる整合性オブジェクトを提供します。すべてのCOPS実装は、このドキュメントで説明されているように、COPSの整合性オブジェクトとそのメカニズムをサポートする必要があります。クライアント（PEP）が正しいポリシーサーバー（PDP）と通信していることを確認するには、共有秘密を使用してPEPとPDPの認証が必要であり、接続が有効なままであるという一貫した証拠が必要です。共有された秘密を最小限に抑えるには、PEPとそのPDPの間で共有されるキー（キーIDで識別）の手動構成が必要です。キーは、COPSメッセージの内容と組み合わせて使用され、整合性オブジェクトの一部であるメッセージダイジェストを計算します。整合性オブジェクトを使用して、PEPとPDPの間のTCP接続を介して送信されるすべてのCOPSメッセージを検証します。
Key maintenance is outside the scope of this document beyond the specific requirements discussed in section 4.2. In general, it is good practice to regularly change keys to maintain security. Furthermore, it is good practice to use localized keys specific to a particular PEP such that a stolen PEP will not compromise the security of an entire administrative domain.
主要なメンテナンスは、セクション4.2で説明されている特定の要件を超えて、このドキュメントの範囲外です。一般に、セキュリティを維持するために定期的にキーを変更することをお勧めします。さらに、盗まれたPEPが管理ドメイン全体のセキュリティを侵害しないように、特定のPEPに固有のローカライズされたキーを使用することをお勧めします。
The COPS Integrity object also provides sequence numbers to avoid replay attacks. The PDP chooses the initial sequence number for the PEP and the PEP chooses the initial sequence number for the PDP. These initial numbers are then incremented with each successive message sent over the connection in the corresponding direction. The initial sequence numbers SHOULD be chosen such that they are monotonically increasing and never repeat for a particular key.
COPS Integrityオブジェクトは、リプレイ攻撃を避けるためのシーケンス番号も提供します。PDPはPEPの初期シーケンス番号を選択し、PEPはPDPの初期シーケンス番号を選択します。これらの初期数値は、対応する方向に接続を介して送信されるたびに、連続するメッセージごとにインクリメントされます。初期シーケンス番号は、単調に増加し、特定のキーを繰り返さないように選択する必要があります。
Security between the client (PEP) and server (PDP) MAY be provided by IP Security [IPSEC]. In this case, the IPSEC Authentication Header (AH) SHOULD be used for the validation of the connection; additionally IPSEC Encapsulation Security Payload (ESP) MAY be used to provide both validation and secrecy.
クライアント（PEP）とサーバー（PDP）の間のセキュリティは、IPセキュリティ[IPSEC]によって提供される場合があります。この場合、接続の検証にはIPSEC認証ヘッダー（AH）を使用する必要があります。さらに、IPSECカプセル化セキュリティペイロード（ESP）を使用して、検証と秘密の両方を提供することができます。
Transport Layer Security [TLS] MAY be used for both connection-level validation and privacy.
トランスポートレイヤーセキュリティ[TLS]は、接続レベルの検証とプライバシーの両方に使用できます。
The Client-type identifies the policy client application to which a message refers. Client-type values within the range 0x0001-0x3FFF are reserved Specification Required status as defined in [IANA-CONSIDERATIONS]. These values MUST be registered with IANA and their behavior and applicability MUST be described in a COPS extension document.
クライアントタイプは、メッセージが参照するポリシークライアントアプリケーションを識別します。範囲0x0001-0x3FFF内のクライアントタイプの値は、[IANA-Considerations]で定義されているように、予約された仕様が必要なステータスです。これらの値はIANAに登録する必要があり、その行動と適用性はCOPS拡張文書に記載されている必要があります。
Client-type values in the range 0x4000 - 0x7FFF are reserved for Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types are not tracked by IANA and are not to be used in standards or general-release products, as their uniqueness cannot be assured.
範囲0x4000-0x7fffのクライアントタイプの値は、[IANA-Considerations]で定義されているプライベート使用のために予約されています。これらのクライアントタイプはIANAによって追跡されず、標準や一般的なリリース製品では使用されません。その独自性は保証できないためです。
Client-type values in the range 0x8000 - 0xFFFF are First Come First Served as defined in [IANA-CONSIDERATIONS]. These Client-types are tracked by IANA but do not require published documents describing their use. IANA merely assures their uniqueness.
範囲0x8000-0xffffのクライアントタイプの値は、[iana-considerations]で定義されているように最初に提供されます。これらのクライアントタイプはIANAによって追跡されますが、使用を説明する公開されたドキュメントを必要としません。イアナは単に彼らの独自性を保証します。
Objects in the COPS Protocol are identified by their C-Num and C-Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is required to introduce new values for these numbers and, therefore, new objects into the base COPS protocol.
COPSプロトコルのオブジェクトは、C-Num値とC型値によって識別されます。[IANA-Consididerations]で特定されたIETFコンセンサスは、これらの数字の新しい値を導入するために必要であり、したがって、基本COPSプロトコルに新しいオブジェクトを導入する必要があります。
Additional Context Object R-Types, Reason-Codes, Report-Types, Decision Object Command-Codes/Flags, and Error-Codes MAY be defined for use with future Client-types, but such additions require IETF Consensus as defined in [IANA-CONSIDERATIONS].
追加のコンテキストオブジェクトRタイプ、Reason-Codes、Report-Types、Decision Object Command-Codes/Flags、およびエラーコードは、将来のクライアントタイプで使用するために定義される場合がありますが、そのような追加には、[IANA--で定義されるIETFコンセンサスが必要です。考慮事項]。
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be defined relative to a particular Client-type following the same IANA considerations as their respective Client-type.
コンテキストオブジェクトMタイプ、理由サブコード、およびエラーサブコードは、それぞれのクライアントタイプと同じIANAの考慮事項に従って、特定のクライアントタイプに関連して定義できます。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP）バージョン1-機能仕様」、RFC 2205、1997年9月。
[WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC 2753, January 2000.
[WRK] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol , Version 2", RFC 2608, June 1999.
[Srvloc] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[INSCH] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[Insch] Shenker、S。およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[IPSEC] Atkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1995年8月。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVPPR] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks T.およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers
[iana] http://www.isi.edu/in-notes/iana/assignments/port-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[Iana-Considerations] Alvestrand、H。およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable contributions.
Andrew SmithとTimothy O'MalleyのWGチェア、Raj Yavatkar、Russell Fenger、Fred Baker、Laura Cunningham、Roch Guerin、Ping Pan、Dimitrios Pendarakisに貴重な貢献に感謝します。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジムボイルレベル3コミュニケーション1025エルドラドブルバードブルームフィールド、コロラド州80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
電話：720.888.1192メール：jboyle@level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
Ron Cohen Cisco Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
Phone: +972.9.9700064
EMail: ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
David Durham Intel 2111 NE 25th Avenue Hillsboro、または97124
Phone: 503.264.6232 EMail: David.Durham@intel.com Raju Rajan AT&T Shannon Laboratory 180 Park Avenue P.O. Box 971 Florham Park, NJ 07932-0971
電話：503.264.6232メール：David.durham@intel.com Raju Rajan AT＆T Shannon Laboratory 180 Park Avenue P.O.Box 971 Florham Park、NJ 07932-0971
EMail: rajan@research.att.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
Shai Herzog Iphighway、Inc。55 New York Avenue Framingham、MA 01701
Phone: 508.620.1141 EMail: herzog@iphighway.com
電話：508.620.1141メール：herzog@iphighway.com
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge、Middlesex UB11 1bn UK
Phone: +44-208-756-8693
EMail: asastry@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。