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
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.
著作権（C）インターネット協会（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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）との間でポリシー情報を交換するために使用することができ、単純なクエリと応答プロトコルについて説明します。ポリシークライアントの一例は、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.
自己識別オブジェクトをオフに活用するように設計されており、COPSプロトコル自体の変更を必要とすることなく、多様なクライアント固有の情報をサポートすることができるという点で3プロトコルは拡張可能です。プロトコルは、一般的な管理、構成、およびポリシーの施行のために作成されました。
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は、認証、再生保護、およびメッセージの整合性のためのメッセージレベルのセキュリティを提供します。 COPSはまた、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.
（1）要求/決定状態は、クライアントとサーバの間で共有され、（2）様々なイベント（要求/決定対）からの状態は相互関連していてもよい：前記プロトコルは、2つの主要な態様では、ステートフルです。 （1）我々は、彼らが明示的にPEPによって削除されるまで、クライアントPEPからのリクエストがインストールまたはリモートPDPによって記憶されていることを意味します。同時に、リモートPDPからの決定は、現在インストールされている要求状態のために、いつでも非同期的に生成することができます。 （2）私たちは、サーバを異なるため、関連する以前にインストールした要求/決定状態（S）の新しいクエリに応答することができることを意味することによって。
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：COPSイラスト。
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は、（[WRK]から取られた）典型的なCOPS例の様々なポリシーコンポーネントのレイアウトを示します。ここで、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はに要求を送信し、リモートPDPからの意思決定を受信するために、このTCP接続を使用しています。リモートPDPは時折以前に承認要求状態の変化を強制的にPEPに迷惑決定を送るかもしれませんがPEPとリモートPDP間の通信は、主にステートフル要求/決定交換の形です。 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コンテキストオブジェクトは、メッセージタイプと要求タイプフィールドを介して、ポリシーイベントをトリガ要求およびメッセージ（該当する場合）のタイプを識別する。着信メッセージの（1）到着ローカルリソースの（2）割り当て、および送信メッセージの（3）転送：COPSは、三のアウトソーシングイベントのタイプを識別する。これらの各イベントが行われ、異なる決定を必要とするかもしれません。 COPS要求/決定メッセージの内容は、文脈に依存します。要求の第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の決定に従わなければなりません。
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の要請メッセージフラグビットメッセージが別のCOPSメッセージにより要請される場合、このフラグがセットされています。このフラグが設定されるべきではない（値= 0）、さもなければ部3で指定されない限り。
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 =同期状態必須（SSQ）6 =クライアントオープン（ OPN）7 =クライアント受け入れ（CAT）8 =クライアント閉じる（CC）9 =キープアライブ（KA）10 =完全な同期（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).
クライアント型は、ポリシーのクライアントを識別します。すべてのカプセル化されたオブジェクトの解釈は、クライアント型に相対的です。クライアントタイプのフィールドで、最上位ビットを設定し、クライアントのタイプは、企業固有の（ - 0xFFFFのこれらは、クライアントのタイプは0x8000です）です。 （特定のクライアント型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.
メッセージの長さ：標準COPSヘッダとすべてのカプセル化されたオブジェクトを含むオクテットでメッセージの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ビットインターフェース4 1 =ハンドル2 =コンテキスト3 = = outインターフェイス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
100-NUM = 1
C-Type = 1, Client Handle.
C型= 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によって削除されます。クライアントハンドルは、クライアントタイプにPDPにおける特定のPEPによって開始され、インストール要求状態を指すために使用されます。 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-タイプ= 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
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
100民= 3
C-Type = 1, IPv4 Address + Interface
C型= 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タイプ= 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が使用されています。アウトインターフェイスは、In-インタフェースオブジェクトと同じフォーマットを持っています。
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
100-NUM = 4
C-Type = 1, IPv4 Address + Interface
C型= 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タイプ= 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-民= 5、C-タイプ= 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.
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)
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)
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-Typeやクライアントタイプに適用できないフラグ値はPEPで無視しなければなりません。
C-Type = 2, Stateless Data
Cタイプ= 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.
それも、アウトソーシングのPEPがそのLPDPでローカルにいくつかの簡単なステートレス政策決定を行うことができるようになりますことを期待されています。このセットは、周知であり、普遍的に実装されているように、PDPは（いずれかの普遍的、構成を介して、またはクライアントオープンメッセージを使用して）同様にそれを認識しています。 PDPは、その決定にこの情報を含むことができ、PEPは、要求を生成し、リソース割当イベントに適用する必要があります。
C-Type = 3, Replacement Data
Cタイプ= 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タイプ= 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-タイプ= 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
100民= 7
C-Type = (same C-Type as for Decision objects)
C型=（判定オブジェクトと同じC型）
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-民= 8、Cタイプ= 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
6欠落5 =必須クライアント固有情報=サポートされていないクライアントタイプ7 =必須COPS 12 =優先サーバ13にリダイレクトシャットダウン= 10 =未指定11 8 =クライアント失敗9 =通信障害が欠落オブジェクト=不明COPSは、オブジェクト：サブコードを（オクテット2）は、未知のオブジェクトのC-numと（オクテット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,
100-CB = 9。
C-Type = 1, Signaled ClientSI.
Cタイプ= 1は、ClientSIを合図をしました。
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.
可変長フィールド。すべてのオブジェクト/クライアントのシグナリングプロトコルや内部の状態に特定の属性は、一つ以上の合図クライアント固有の情報オブジェクト内にカプセル化されています。 ClientSIオブジェクト内にカプセル化されたデータの形式は、クライアントタイプによって決定されます。
C-Type = 2, Named ClientSI.
ClientSI名前Cタイプ= 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.
可変長フィールド。 PDPサーバへのPEP、要求、または構成された状態に関する特定の情報を中継するために有用という名前のコンフィギュレーション情報が含まれています。
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,
100民= 10。
C-Type = 1, Keep-alive timer value
C-タイプ= 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.
Timerオブジェクトは、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識別対象は、リモートPDPにPEPクライアントを識別するために使用されます。これは、クライアントを開き、メッセージのために必要です。
C-Num = 11, C-Type = 1
C-民= 11、C-タイプ= 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.
可変長フィールド。これはNULLもゼロ32ビットワード境界（加工対象物の長さが4つのオクテットの倍数である）に埋め込まれたASCII文字列を終了します。 PEPID一意PEPのリブート永続的な方法でポリシー・ドメイン内のPEPを識別するASCII文字列を含まなければなりません。例えば、それは、PEPの静的に割り当てられたIPアドレスまたはDNS名でもあります。この識別子は、安全にそのポリシールールにPEPを識別するためのハンドルとしてPDPによって使用されてもよいです。
The Type of Report on the request state associated with a handle:
ハンドルに関連付けられた要求状態に関する報告書の種類：
C-Num = 12, C-Type = 1
C-民= 12、C-タイプ= 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,
100民= 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以来、最後の再起動（これは、Client-受け入れを受信意味する）が正常に開かれた最後のPDPを指定する必要があります。何のPDPは、最後のリブート以来使用されなかった場合は、PEPは、単にクライアントのオープンメッセージで、このオブジェクトは含まれません。
C-Num = 14,
100民= 14。
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C型= 1、IPv4アドレス（PDPRedirAddrと同じ形式）
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
Cタイプ= 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,
100民= 15。
C-Type = 1, Accounting timer value
C型= 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.
定期的な会計タイプのレポート間の最小間隔を決定するために使用されるオプションのタイマー値。該当する場合、レポートメッセージを介してPEPに迷惑会計の更新との間に適切な間隔を記述するためにPDPで使用されています。これは、ネットワークから見アカウンティングトラフィックの量を制御する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メッセージの端部に設けられています。ダイジェストは、次いで、特定の全てにメッセージをCOPSが、ダイジェスト値自体を含まないにわたって計算されます。 COPSメッセージの送信者が計算しインテグリティオブジェクトのダイジェスト部分に充填します。 COPSメッセージの受信機は、受信したメッセージ上ダイジェストを計算し、それを受信したインテグリティオブジェクトにダイジェストと一致検証します。
C-Num = 16,
100民= 16。
C-Type = 1, HMAC digest
C型= 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インテグリティオブジェクトは、PEPとPDPの間で共有鍵に基づいてメッセージダイジェストを計算するために、[HMAC] HMAC（メッセージ認証のための鍵付きハッシュ化）を採用しています。
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を指定します。同時に複数のキーが与えられPEPIDためのPDPのキーを対応するPEP上に存在するキーIDを可能にします。キーIDで識別されるキーは、整合性のオブジェクトにメッセージダイジェストを計算するために使用されました。すべての実装は、最低でも、HMACは、MD5メッセージダイジェストアルゴリズム[MD5]を用いているサポートしなければならないHMAC-MD5-96は、メッセージダイジェストを計算するために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ビットの符号なし整数であるシーケンス番号を含みます。シーケンス番号は、最初のクライアントのOpen Client-Acceptメッセージ交換中に開始され、その後1で新しいメッセージが同じ方向にTCP接続を介して送信されるたびにインクリメントされます。シーケンス番号は0xFFFFFFFFの値に達した場合、次の増分は単純にゼロの値にロールオーバーされます。
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メッセージの最後のオブジェクトでなければなりません）のIntegrityオブジェクトまで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は、COPSを経由して特定のクライアントタイプのための代替PDPアドレスとTCPポートにPEPをリダイレクトすることができます。別のTCPポート番号は、同じサーバ上で実行されている別のPDP実装にPEPをリダイレクトするために使用することができます。単一のリモート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は、プライマリPDPを識別する<PDPRedirAddr>オブジェクトを含む<クライアント閉じる>メッセージを介してプライマリPDP（にPEPをリダイレクトする責任があります影響を受ける各クライアントタイプに使用します）。 PEPとPDPの間のセクション2.5の詳細同期動作。
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によって削除されなければなりません。異なる要求の状態を参照するハンドルは、特定の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（従って、同期プロセスを完了）を同期状態Completeメッセージが続く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の状態が正確にPEPの状態を反映することができるようになりますので、PDPたび、そのローカル状態の変更を通知する責任があります。
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、クライアント固有の情報オブジェクトは、政策決定がなされる必要があるため、クライアント型固有のデータを保持しています。構成の場合、名前付きClientSIモジュール、インターフェース、または設定すべき機能についての名前情報を含むことができます。複数ClientSIsの順序は重要ではありません。
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.
新しい/更新された要求に対する第1の決定メッセージは、COPSヘッダーの要請メッセージフラグを設定（値= 1）を有することが必要です。これは、更新要求を追跡する問題を特定の決定が対応し（つまり、同じハンドルの再発行要求である）回避します。与えられたハンドルのため、リクエストごとに最大1つの優秀な要請の決定がある、ということが重要です。これは本質的に、それは募集メッセージフラグを設定して、対応する12月を受け取る前に、PEPは、（与えられたハンドル用）、複数の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等、リクエスト内のオブジェクト）に報告されています。該当する判定対象（S）コンテキストとクライアントのタイプに依存します。意思決定のためのオブジェクトのみ発注要件が必要と判断フラグはタイプがバインディングコンテキストごとに、他の意思決定のオブジェクトタイプに先行しなければなりませんオブジェクトということです。
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メッセージはPDPの決定を行う際にPDPにその成功または失敗を伝達するために、または状態の会計関連の変更を報告するためにPEPによって使用されます。レポート・タイプは、レポートの種類を指定し、オプションのClientSIは、クライアントタイプごとの追加情報を運ぶことができます。
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メッセージは、要請メッセージのフラグを設定する必要がありそしてそれらの対応する決定メッセージが受信されたのと同じ順序で送信されなければなりません。意思決定ごとに設定要請メッセージフラグで生成された複数のレポートの状態メッセージがあってはなりません。
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.
COPSのステートフルな性質を考えると、要求状態が最終的にPEPから削除されたときに対応する状態は、同様に、PDPに除去することができるので、この要求の状態についてDRQメッセージは、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.
不正な形式の決定メッセージが削除または再要求されるべきであるいずれかのPEPに適切な誤った理由コード（バートメッセージフォーマット）と関連する状態を指定DRQをトリガしなければなりません。意思決定は、未知のCOPS決定オブジェクトが含まれていた場合PEPは未知のオブジェクトに含まれている情報を順守することができませんので、PEPは不明COPSは、理由コードをオブジェクトの指定その要求を削除しなければなりません。いずれの場合においても、DRQを発行した後、PEPは、再度対応する要求を再試行してもよいです。
The format of the Synchronize State Query message is as follows:
次のように同期ステートQueryメッセージの形式は次のとおりです。
<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).
クライアントのオープンメッセージは、PDPにPEPがサポートできるクライアントの種類を指定するには、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).
名前ClientSIオブジェクトが（クライアントタイプに適した拡張文書で指定されるように）必要なPDPのPEPについてのグローバルな情報を中継するために含めることができます。
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 Addressオブジェクトを提供することができます。 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.
TCP接続をとることができるクライアントとサーバーの両方は、通信アクティビティタイマ期間を超える期間に検出されない場合（CATメッセージで指定された）最小の時間値を持つクライアントタイプには不十分です。 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.
完全な同期状態はPDPがPEPに同期状態要求を送信した後、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メッセージのセキュリティは、接続ごとに一度ネゴシエートし、特定の接続上のすべての通信を覆っています。 COPSは、セキュリティが必要とされるレベルならば、それは（接続レベルのセキュリティネゴシエーションと接続検証のために予約されている）がゼロのクライアントタイプを指定する最初のクライアントオープン/クライアント-Acceptメッセージ交換中にネゴシエートされなければなりません。
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で指定し、任意のCOPSメッセージで整合性のオブジェクトが含まれませんように、それは単にサポートされているクライアント・タイプのためのPDPクライアントを開き、メッセージを送信します。
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
それは、他のクライアントタイプを開く前に、クライアントタイプ= 0とクライアントのオープンメッセージPDPを送信する場合それ以外の場合は、セキュリティがPEPによって開始することができます。 PDPは、クライアントタイプ= 0とクライアントのオープンを受信した場合、別のクライアントタイプが既に正常に開かれた後、それはそのPEPに（クライアントタイプ= 0の場合）クライアントを閉じるメッセージを返さなければなりません。この最初のクライアントオープンメッセージは、ゼロのクライアントタイプを指定しなければならないとPEPIDとCOPSインテグリティオブジェクトを提供しなければなりません。この整合性オブジェクトは、PEPが必要とする初期シーケンス番号が含まれています
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は、初期クライアントオープン/クライアント受け入れ交換ダイジェストを計算するために使用されるアルゴリズムと鍵を識別する鍵IDの後にその後の通信中にインクリメントします。
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は、Integrityオブジェクトを担持PEPゼロのクライアントタイプとクライアント-Acceptメッセージを送らなければなりません。このインテグリティオブジェクトは、PDPは、PDPとダイジェストを計算するために使用される鍵とアルゴリズムを識別する鍵IDと、後続のすべての通信中に増分するPEPを必要とする最初のシーケンス番号を含むであろう。
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とクライアント閉じるメッセージ。同様に、PDPは、セキュリティを必要とPEPの観点から、有効な整合性オブジェクトを含むクライアントタイプ= 0でクライアント-Acceptメッセージを送り返すないことにより、セキュリティネゴシエーションに失敗した場合は、PEPはPDP Aに送らなければなりませんクライアント閉じる適切なエラーコードを指定のクライアントタイプ= 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. A COPSインテグリティオブジェクトが設けられ、未知/受け入れられないC型（不明COPSは、サポートされていないC-numとC型を特定するエラーコードオブジェクト）としました。 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が期待するもののシーケンス番号を知っているだろう。 ALL COPSメッセージは、次いで、ダイジェスト（クライアントオープン/特定のクライアントタイプのメッセージをクライアント受け入れなど）、適切なメッセージを正しいシーケンス番号を指定ネゴシエートインテグリティオブジェクトを含まなければなりません。 PEPのPDPからのすべての後続のメッセージは、最初のクライアントオープンメッセージのインテグリティオブジェクトにPEPによって提供されるシーケンス番号の増加をもたらさなければなりません。同様に、PDPにPEPからのすべての後続のメッセージは、最初のクライアント-AcceptメッセージのインテグリティオブジェクトにPDPによって提供されるシーケンス番号の増加をもたらさなければなりません。シーケンス番号は、対応する初期シーケンス番号で始まる1ずつ増加しています。初期クライアント受け入れにPDPによってPEPに指定されたシーケンス番号が10である場合、例えば、PEPは、PDPに送信する次のメッセージは... 11のシーケンス番号とその後、次のメッセージを整合オブジェクトを提供しますPEPは、その上の12のシーケンス番号を持っているとしますPDPに送信します。それ以降、受信したメッセージが間違ったシーケンス番号、未知のキーID、無効なメッセージダイジェストを、含まれているか、整合性がネゴシエートされた後のIntegrityオブジェクトが欠落している場合は、クライアントを閉じるメッセージには、有効なを含むクライアントタイプゼロのために生成しなければなりません保全対象と適切なエラーコードを指定します。接続は、ドロップされなければなりません。
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。整合性オブジェクトのメッセージダイジェストを生成するために使用されるキーは、キーIDフィールドによって識別されます。このように、キーIDパラメータは、PEPとPDPで共有潜在的に複数の同時のキーのいずれかを識別するために使用されます。鍵IDはPDPやPEP上の特定のPDPに特定PEPIDに対するものです。各キーはまた、それが有効である範囲内の時間、ならびにキーで使用するアルゴリズムを指定し、関連する暗号化アルゴリズムパラメータの寿命パラメータを設定する必要があります。最低でも、すべての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はリモートPDP、PEPによってサポートされている各クライアントタイプのための1つに1つ以上のクライアント・オープン・メッセージを送信します。クライアントのオープンメッセージは、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は、PDPへの要求の発行を開始するキープアライブメッセージとPEP間のタイマー間隔を指定するクライアントは、受け入れ送信されます。
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.
キープアライブメッセージは、PDPへのPEPから他のメッセージが存在しない場合でも、クライアントとサーバ間の接続がまだ機能して検証するために使用されます。 PEPは、四分の三のClient-AcceptメッセージでPDPによって指定された最小KAタイマ間隔にランダムに四分の一以内COPS KAメッセージを生成しなければなりません。 PEPからのキープアライブメッセージを受信すると、PDPはその後戻っPEPにキープアライブメッセージをエコーすることにより、このキープアライブメッセージに応答しなければなりません。どちらの側が他から最小KAタイマー間隔内にキープアライブや他のCOPSメッセージを受信しない場合、接続が失われたと考えるべきです。
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がシャットダウンされると、それはまた、明示的に、おそらく代わりに使用する別のPDPを指定して、各クライアント型のクライアントをすべて終了し、接続のPEPを送信すべきです。
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
COPSプロトコルは、認証、メッセージ整合性、およびリプレイ防止を達成することができるインテグリティオブジェクトを提供します。全ては、この文書に記載されているように実装はCOPS整合オブジェクトとそのメカニズムをサポートしなければならないCOPS。クライアント（PEP）が正しいポリシーサーバー（PDP）と通信していることを確認するには、共有秘密鍵を使用してPEPとPDPの認証、および接続が有効のままであることを一貫性の証明が必要です。共有秘密最小限のキーによって識別されたキーを手動で設定する（必要で
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.
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整合性オブジェクトは、リプレイ攻撃を回避するために、シーケンス番号を提供します。 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.
クライアントタイプは、メッセージが参照するポリシー・クライアント・アプリケーションを識別する。 [IANA-考察]で定義される範囲0x0001-0x3FFF内のクライアントタイプの値は、仕様が必要ステータスを予約されています。これらの値は、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のでクライアントタイプ値 - [IANA-考察]で定義されるように0x7FFFをプライベート使用のために予約されています。彼らのユニークさを保証することはできないとして、これらのクライアントタイプは、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-考察]で定義されるように役立ちました。これらのクライアントのタイプはIANAによって追跡されますが、その使用を記載し公開した文書を必要としません。 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-考察]において同定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-TYPES、理由-コード、レポート・タイプ、判定対象のコマンドコード/フラグ、およびエラー・コードは、将来のクライアントタイプで使用するために定義されてもよいが、[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol , Version 2", RFC 2608, June 1999.
【SRVLOC]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン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]アトキンソン、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.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVPPR]ブレーデン、R.とL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークスT.とC.アレン、 "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-考察] 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.
アンドリュー・スミスとティモシーオマリー彼らの貴重な貢献のために私たちのWGの議長、ラジYavatkar、ラッセルFenger、フレッド・ベイカー、ローラ・カニンガム、ロッホゲラン、Pingのパン、そしてディミトリオスPendarakisに感謝します。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジム・ボイルレベル3コミュニケーションズ1025エルドラド大通りブルームフィールド、CO 80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
電話：720.888.1192 Eメール：jboyle@Level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
ロン・コーエンシスコシステムズ4 MaskitセントHerzeliya Pituach 46766イスラエル
Phone: +972.9.9700064 EMail: ronc@cisco.com
電話：+972.9.9700064 Eメール：ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
デビッド・ダーラムインテル2111 NE 25日アベニューヒルズボロ、OR 97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
電話：503.264.6232 Eメール：David.Durham@intel.com
Raju Rajan AT&T Shannon Laboratory 180 Park Avenue P.O. Box 971 Florham Park, NJ 07932-0971
ラジュラジャンAT＆Tシャノン研究所180パークアベニュー私書箱ボックス971フローラムパーク、ニュージャージー州07932から0971
EMail: rajan@research.att.com
メールアドレス：rajan@research.att.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
シャイヘルツォークIPHighway社55ニューヨーク・アベニューフラミンガム、MA 01701
Phone: 508.620.1141 EMail: herzog@iphighway.com
電話：508.620.1141 Eメール：herzog@iphighway.com
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
アルンSastryシスコシステムズ4スクエアストックリーパークアクスブリッジ、ミドルUB11 1BN英国
Phone: +44-208-756-8693 EMail: asastry@cisco.com
電話：+ 44-208-756-8693電子メール：asastry@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。