[要約] RFC 8921は、接続性のプロビジョニング交渉プロトコル（CPNP）に関するもので、異なるネットワークサービスプロバイダ間での動的なサービス交渉を可能にします。その目的は、効率的なネットワークリソースの利用と最適化を促進することにあります。利用場面としては、クラウドサービス、データセンター間の接続、およびエンドユーザーへの高品質な通信サービスの提供が挙げられます。
Independent Submission M. Boucadair, Ed.
Request for Comments: 8921 C. Jacquenet
Category: Informational Orange
ISSN: 2070-1721 D. Zhang
Huawei Technologies
P. Georgatsos
CERTH
October 2020
Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)
動的サービスネゴシエーション：接続性プロビジョニングネゴシエーションプロトコル（CPNP）
Abstract
概要
This document defines the Connectivity Provisioning Negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.
このドキュメントは、サービスパラメータの動的ネゴシエーションを容易にするように設計されている接続性プロビジョニングネゴシエーションプロトコル（CPNP）を定義しています。
CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.
CPNPは、接続性プロビジョニングサービス、ストレージ設備、コンテンツ配信ネットワークなどを含む（ただし、必ずしも限定されない）様々なネゴシエーションの目的に使用できる一般的なプロトコルです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8921.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/frfc8921で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. CPNP Functional Elements
4. Order Processing Models
5. Sample Use Cases
6. CPNP Deployment Models
7. CPNP Negotiation Model
8. Protocol Overview
8.1. Client/Server Communication
8.2. Policy Configuration on the CPNP Server
8.3. CPNP Session Entries
8.4. CPNP Transactions
8.5. CPNP Timers
8.6. CPNP Operations
8.7. Connectivity Provisioning Documents
8.8. Child PQOs
8.9. Multi-Segment Service
8.10. Negotiating with Multiple CPNP Servers
8.11. State Management
8.11.1. On the Client Side
8.11.2. On the Server Side
9. CPNP Objects
9.1. Attributes
9.1.1. CUSTOMER_ORDER_IDENTIFIER
9.1.2. PROVIDER_ORDER_IDENTIFIER
9.1.3. TRANSACTION_ID
9.1.4. SEQUENCE_NUMBER
9.1.5. NONCE
9.1.6. EXPECTED_RESPONSE_TIME
9.1.7. EXPECTED_OFFER_TIME
9.1.8. VALIDITY_OFFER_TIME
9.1.9. SERVICE_DESCRIPTION
9.1.10. CPNP Information Elements
9.2. Operation Messages
9.2.1. QUOTATION
9.2.2. PROCESSING
9.2.3. OFFER
9.2.4. ACCEPT
9.2.5. DECLINE
9.2.6. ACK
9.2.7. CANCEL
9.2.8. WITHDRAW
9.2.9. UPDATE
9.2.10. FAIL
9.2.11. ACTIVATE
10. CPNP Message Validation
10.1. On the Client Side
10.2. On the Server Side
11. Theory of Operation
11.1. Client Behavior
11.1.1. Order Negotiation Cycle
11.1.2. Order Withdrawal Cycle
11.1.3. Order Update Cycle
11.2. Server Behavior
11.2.1. Order Processing
11.2.2. Order Withdrawal
11.2.3. Order Update
11.3. Sequence Numbers
11.4. Message Retransmission
12. Some Operational Guidelines
12.1. CPNP Server Logging
12.2. Business Guidelines and Objectives
13. Security Considerations
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Acknowledgements
Authors' Addresses
This document defines the Connectivity Provisioning Negotiation Protocol (CPNP) that is meant to dynamically exchange and negotiate connectivity provisioning parameters and other service-specific parameters between a Customer and a Provider. CPNP is a tool that introduces automation to the service negotiation and activation procedures, thus fostering the overall service provisioning process. CPNP can be seen as a component of the dynamic negotiation metadomain described in Section 2.4 of [RFC7149].
この文書は、顧客とプロバイダ間の接続性プロビジョニングパラメータとその他のサービス固有のパラメータを動的に交換しネゴシエートすることを目的とした接続プロビジョニングネゴシエーションプロトコル（CPNP）を定義しています。CPNPは、サービス交渉および活性化手順に自動化を導入し、それによって全体的なサービスプロビジョニングプロセスを育成するツールです。CPNPは、[RFC7149]のセクション2.4に記載されている動的ネゴシエーションメタドメインの構成要素として見ることができます。
CPNP is a generic protocol that can be used for negotiation purposes other than connectivity provisioning. For example, CPNP can be used to request extra storage resources, to extend the footprint of a Content Delivery Network (CDN), to enable additional features from a cloud Provider, etc. CPNP can be extended with new Information Elements (IEs). Sample negotiation use cases are described in Section 5. Section 4 introduces several order processing models and defines those that are targeted by CPNP. The CPNP negotiation model is then detailed in Section 7.
CPNPは、接続性プロビジョニング以外のネゴシエーション目的に使用できる一般的なプロトコルです。たとえば、CPNPを使用して、クラウドプロバイダ（CDN）のフットプリントを拡張し、クラウドプロバイダなどの追加機能などを有効にするために、追加のストレージリソースを要求することができます.CPNPを新しい情報要素（IES）で拡張できます。サンプルネゴシエーションの使用例はセクション5に記載されています。セクション4では、いくつかの注文処理モデルを紹介し、CPNPの対象となるものを定義します。その後、CPNPネゴシエーションモデルはセクション7に詳述されています。
[RFC7297] describes a Connectivity Provisioning Profile (CPP) template to capture connectivity requirements to be met by a transport infrastructure for the delivery of various services such as Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) services [RFC4026]. The CPP document defines the set of IP transfer parameters that reflect the guarantees that can be provided by the underlying transport network together with reachability scope and capacity needs. CPNP uses the CPP template to encode connectivity provisioning clauses that are subject to negotiation. The accepted CPP will then be passed to other functional elements that are responsible for the actual service activation and provisioning. For example, Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040] can be used to activate adequate network features that are required to deliver the accepted service. How the outcome of CPNP negotiation is translated into service and network provisioning actions is out of scope of this document.
[RFC7297]は、ボイスオーバーIP（VoIP）、IPTV、およびVirtual Private Network（VPN）サービスなどのさまざまなサービスの配信のためのトランスポートインフラストラクチャによって、接続するための接続性プロビジョニングプロファイル（CPP）テンプレートを説明しています。 ]。 CPP文書は、基礎となるトランスポートネットワークによって到達可能性の範囲と容量のニーズと共に提供できる保証を反映するIP転送パラメータのセットを定義します。 CPNPはCPPテンプレートを使用して、ネゴシエーションの対象となる接続プロビジョニング句をエンコードします。受け入れられたCPPは、実際のサービスの活性化とプロビジョニングを担当する他の機能要素に渡されます。たとえば、ネットワーク構成プロトコル（NETCONF）[RFC6241]またはRESTCONF [RFC8040]を使用して、受け入れられたサービスを配信するために必要な適切なネットワーク機能を有効にすることができます。 CPNPネゴシエーションの結果がサービスに翻訳され、ネットワークプロビジョニングのアクションがどのように翻訳されているかは、この文書の範囲外です。
As a reminder, several proposals have been made in the past by the (research) community (e.g., Common Open Policy Service protocol for supporting Service Level Specification [COPS-SLS], Service Negotiation Protocol [SrNP], Dynamic Service Negotiation Protocol [DSNP], Resource Negotiation and Pricing Protocol [RNAP], Service Negotiation and Acquisition Protocol [SNAP]). CPNP leverages the authors' experience with SrNP by separating the negotiation primitives from the service under negotiation. Moreover, careful examination of the other proposals revealed certain deficiencies that were easier to address through the creation of a new protocol rather than the modification of existing protocols. For example:
リマインダーとして、（研究）コミュニティ（例えば、サービスレベル仕様書のための共通オープンポリシーサービスプロトコル）によって過去にいくつかの提案が行われてきた[SPS - SLS、サービス交渉プロトコル[SRNP]、動的サービスネゴシエーションプロトコル[DSNP]]、リソースネゴシエーションと価格設定プロトコル[RNAP]、サービスネゴシエーションと取得プロトコル[SNAP]）。CPNPは、ネゴシエーションの下でのサービスからの交渉プリミティブを分離することによって、SRNPでの著者の経験を活用しています。さらに、他の提案を慎重に検討すると、既存のプロトコルの変更よりもむしろ新しいプロトコルの作成を通じて対処するのが簡単な特定の欠点が明らかになった。例えば：
* COPS-SLS relies upon the COPS usage for policy provisioning (COPS-PR) [RFC3084], which is a Historic RFC.
* COPS-SLSは、歴史的なRFCであるPolicy Provisioning（COPS-PR）[RFC3084]のCOPSの使用法に依存しています。
* DSNP is tightly designed with one specific service in mind (QoS) and does not make any distinction between a quotation phase and the actual service-ordering phase.
* DSNPは1つの特定のサービスを念頭に置いて厳密に設計されており、引用段階と実際のサービス順序付け段階を区別しません。
One of the primary motivations of this document is to provide a permanent reference to exemplify how service negotiation can be automated.
この文書の主な動機の1つは、サービス交渉が自動化され得る方法を例示するための恒久的な参照を提供することです。
Implementation details are out of scope. An example of required modules and interfaces to implement this specification is sketched in Section 4 of [AGAVE]. This specification builds on that effort.
実装の詳細は範囲外です。この仕様を実装するために必要なモジュールとインタフェースの例は、[Agave]のセクション4でスケッチされています。この仕様はその努力に基づいています。
This document makes use of the following terms:
この文書は以下の用語を利用しています。
Customer: Is a business role that denotes an entity that is involved in the definition and the possible negotiation of an order, including a Connectivity Provisioning Agreement, with a Provider. A connectivity provisioning document is captured in a dedicated CPP template-based document, which may specify (among other information) the sites to be connected, border nodes, outsourced operations (e.g., routing, traffic steering).
顧客：プロバイダーを備えた、定義に関与しているエンティティを、接続性プロビジョニング契約を含む、注文の可能な交渉に関与している事業ロールです。接続性プロビジョニング文書は、接続されるサイト、境界ノード、アウトソーシング操作（例えば、ルーティング、トラフィックステアリング）を（他の情報の中で）指定することができる専用のCPPテンプレートベースの文書にキャプチャされます。
The right to invoke the subscribed service may be delegated by the Customer to third-party end users or brokering services.
加入しているサービスを呼び出す権利は、サードパーティのエンドユーザーまたは仲介サービスに顧客によって委任される可能性があります。
A Customer can be a Service Provider, an application owner, an enterprise, a user, etc.
顧客は、サービスプロバイダ、アプリケーション所有者、企業、ユーザーなどにすることができます。
Network Provider (or Provider): Owns and administers one or many transport domain(s) (typically Autonomous Systems (ASes)) composed of (IP) switching and transmission resources (e.g., routing, switching, forwarding, etc.). Network Providers are responsible for delivering and operating connectivity services (e.g., offering global or restricted reachability at specific rates). Offered connectivity services may not necessarily be restricted to IP.
ネットワークプロバイダ（またはプロバイダ）：（IP）スイッチングおよび送信リソースからなる1つまたは複数のトランスポートドメイン（典型的には自律システム（ASES））（例えば、ルーティング、スイッチング、転送など）を所有および管理する。ネットワークプロバイダは、接続性サービスを提供して動作させることを担当しています（たとえば、特定の割合で世界的または制限された到達可能性を提供する）。提供された接続サービスは必ずしもIPに制限される必要はありません。
The policies to be enforced by the connectivity service delivery components can be derived from the technology-specific clauses that might be included in agreements with the Customers. If no such clauses are included in the agreement, the mapping between the connectivity requirements and the underlying technology-specific policies to be enforced is deployment specific.
接続サービス配信コンポーネントによって実施されるポリシーは、顧客との協定に含まれる可能性がある技術固有の句から導き出すことができます。そのような句が契約に含まれていない場合、接続要件と適用される基礎となる技術固有のポリシーの間のマッピングは展開固有です。
Quotation Order: Denotes a request made by the Customer to the Provider that includes a set of requirements. The Customer may express its service-specific requirements by assigning (strictly or loosely defined) values to the information items included in the commonly understood template (e.g., CPP template) describing the offered service. These requirements constitute the parameters to be mutually agreed upon.
引用順：一連の要件を含むプロバイダに顧客によって行われた要求を表します。顧客は、提供されたサービスを記述する一般的に理解されているテンプレート（例えば、CPPテンプレート）に含まれる情報項目に（厳密にまたは緩やかに定義された）値を割り当てることによって、そのサービス固有の要求を表現することができる。これらの要件は相互に合意されるべきパラメータを構成します。
Offer: Refers to a response made by the Provider to a Customer's quotation order that describes the ability of the Provider to satisfy the order at the time of its receipt. Offers reflect the capability of the Provider in accommodating received Customer orders beyond monolithic 'yes/no' answers.
オファー：プロバイダが受信時に注文を満たす能力を説明する顧客の引用順序にプロバイダによって行われた応答を指します。モノリシックの「はい/いいえ」の答えを超えて受領した顧客注文を受けて、プロバイダの機能を反映しています。
An offer may fully or partially meet the requirements of the corresponding order. In the latter case, it may include alternative suggestions that the Customer may take into account by issuing a new order.
オファーは、対応する順序の要件を完全にまたは部分的に満たすことができます。後者の場合、それは顧客が新しい順序を発行することによって考慮に入れることができる代替提案を含み得る。
Agreement: Refers to an order placed by the Customer and accepted by the Provider. It signals the successful conclusion of a negotiation cycle.
契約：顧客によって配置され、プロバイダによって受け入れられた注文を指します。交渉サイクルの成功した結論を知らせます。
The following functional elements are defined:
以下の機能要素が定義されています。
CPNP client (or client): Denotes a software instance that sends CPNP requests and receives CPNP responses. The current operations that can be performed by a CPNP client are listed below:
CPNPクライアント（またはクライアント）：CPNP要求を送信してCPNP応答を受信するソフトウェアインスタンスを表します。CPNPクライアントによって実行できる現在の操作を以下に示します。
1. Create a quotation order (Section 9.2.1).
1. 引用順序を作成します（9.2.1項）。
2. Cancel an ongoing quotation order under negotiation (Section 9.2.7).
2. 交渉の下で進行中の引用順序をキャンセルします（9.2.7項）。
3. Accept an offer made by a server (Section 9.2.4).
3. サーバーによって行われたオファーを受け入れる（9.2.4項）。
4. Withdraw an agreement (Section 9.2.8).
4. 合意を撤回する（9.2.8項）。
5. Update an agreement (Section 9.2.9).
5. 合意を更新する（9.2.9項）。
CPNP server (or server): Denotes a software instance that receives CPNP requests and sends back CPNP responses accordingly. The CPNP server is responsible for the following operations:
CPNPサーバー（またはサーバー）：CPNP要求を受け取り、それに応じてCPNP応答を送り返すソフトウェアインスタンスを表します。CPNPサーバーは、次の操作を担当します。
1. Process a quotation order (Section 9.2.2).
1. 引用順序を処理する（9.2.2項）。
2. Make an offer (Section 9.2.3).
2. オファーを作る（9.2.3節）。
3. Cancel an ongoing quotation order (Section 11.2.3).
3. 進行中の引用順序をキャンセルします（11.2.3項）。
4. Process an order withdrawal (Section 11.2.3).
4. 注文撤回を処理する（11.2.3項）。
For preparing their service orders, Customers may need to be aware of the offered services. Therefore, Providers should first proceed with the announcement (or the exposure) of the services they can provide. The service announcement process may take place at designated global or Provider-specific service markets or through explicit interactions with the Providers. The details of this process are outside the scope of this document.
彼らのサービス注文を準備するために、顧客は提供されたサービスを認識する必要があるかもしれません。したがって、プロバイダは最初に提供できるサービスの発表（または露出）を進めるべきです。サービス発表プロセスは、指定されたグローバルまたはプロバイダー固有のサービス市場またはプロバイダとの明示的な対話を通じて行われることがあります。このプロセスの詳細はこの文書の範囲外です。
With or without such service announcement/exposure mechanisms in place, the following order processing models can be distinguished:
そのようなサービス発表/露出メカニズムの有無にかかわらず、以下の注文処理モデルを区別することができます。
Frozen model: The Customer cannot actually negotiate the parameters of the service(s) offered by a Provider. After consulting the Provider's service portfolio, the Customer selects the service offer to which he or she wants to subscribe and places an order to the Provider. Order handling is quite simple on the Provider side because the service is not customized per Customer's requirements, but rather designed to address a Customer base that shares the same requirements (i.e., these Customers share the same Connectivity Provisioning Profile). This mode can be implemented using existing tools such as [RFC8309].
冷凍モデル：顧客は実際にプロバイダーによって提供されるサービスのパラメータを交渉することはできません。プロバイダのサービスポートフォリオを参照した後、顧客は、彼または彼女が購読したいサービスオファーを選択し、プロバイダに注文する。顧客の要件ごとにサービスがカスタマイズされていないが、同じ要件を共有する顧客ベースに対処するように設計されているので、注文処理は非常に簡単ですが、同じ要件を共有する顧客ベースに対処するように設計されています（すなわち、これらの顧客は同じ接続プロビジョニングプロファイルを共有しています）。このモードは[RFC8309]などの既存のツールを使用して実装できます。
Negotiation-based model: Unlike the frozen model, the Customer documents his/her requirements in a request for a quotation, which is then sent to one or several Providers. Solicited Providers check whether they can address these requirements or not, and get back to the Customer accordingly, possibly with an offer that may not exactly match the Customer's requirements (e.g., a 100 Mbps connection cannot be provisioned given the amount of available resources, but an 80 Mbps connection can be provided). A negotiation between the Customer and the Provider(s) then follows until both parties reach an agreement (or do not).
交渉ベースのモデル：凍結モデルとは異なり、顧客は引用の要求に必要な要件を文書化します。これは次に1つまたは複数のプロバイダに送信されます。勧誘プロバイダーは、これらの要件に対処できるかどうかを確認し、お客様の要件とまったく一致しない可能性があるオファーで顧客に戻ることができるかどうかを確認します（たとえば、利用可能なリソースの量を考慮して100Mbpsの接続はプロビジョニングできません。80Mbpsの接続を提供できます）。両当事者が合意に達するまで、顧客とプロバイダ間の交渉は続く（またはそうでない）。
Both frozen and negotiation-based models require the existence of appropriate service templates like a CPP template and their instantiation for expressing specific offerings from Providers and service requirements from Customers, respectively. CPNP can be used in either model for automating the required Customer-Provider interactions. The frozen model can be seen as a special case of the negotiation-based model. This document focuses on the negotiation-based model. Not only 'yes/no' answers but also counterproposals may be offered by the Provider in response to Customer orders.
凍結および交渉ベースのモデルの両方が、CPPテンプレートのような適切なサービステンプレートの存在と、それぞれプロバイダやサービス要件からの特定のオファリングを顧客との間で表現するためのそれらのインスタンス化を必要とします。CPNPは、必要な顧客プロバイダの対話を自動化するためのモデルのどちらでも使用できます。凍結モデルは、交渉ベースのモデルの特別な場合と見なすことができます。この文書は交渉ベースのモデルに焦点を当てています。「はい/いいえ」だけでなく、顧客の注文に応じてプロバイダによって提供される可能性があります。
Order processing management on the Network Provider's side usually solicits features supported by the following functional blocks:
ネットワークプロバイダ側の注文処理管理通常、次の機能ブロックでサポートされている機能を登録します。
* Network provisioning (including order activation, Network Planning, etc.)
* ネットワークプロビジョニング（注文起動、ネットワーク計画などを含む）
* Authentication, authorization, and accounting (AAA)
* 認証、承認、および会計（AAA）
* Network and service management (performance measurement and assessment, fault detection, etc.)
* ネットワークとサービス管理（性能測定と評価、障害検出など）
* Sales-related functional blocks (e.g., billing, invoice validation)
* 販売関連機能ブロック（例えば、請求、請求書検証）
* Network impact analysis
* ネットワークインパクト解析
CPNP does not assume any specific knowledge about these functional blocks, drawing an explicit line between protocol operation and the logic for handling connectivity provisioning requests. An order processing logic is typically fed with the information manipulated by the aforementioned functional blocks. For example, the resources that can be allocated to accommodate the Customer's requirements may depend on network availability estimates as calculated by the planning functions and related policies, as well as the number of orders to be processed simultaneously over a given period of time.
CPNPは、これらの機能ブロックに関する特定の知識を想定していないため、プロトコル操作と接続性プロビジョニング要求を処理するためのロジックとの間の明示的な行を描画します。注文処理ロジックは、通常、前述の機能ブロックによって操作された情報を供給される。たとえば、顧客の要件に対応するように割り当てることができるリソースは、計画機能と関連ポリシーによって計算されたネットワークの可用性推定値、および特定の期間にわたって同時に処理されるべき注文数によって異なります。
This document does not elaborate on how Customers are identified and subsequently managed by the Provider's information system.
この文書は、顧客がどのように識別され、その後プロバイダの情報システムによって管理されるかについて詳しく説明していません。
A non-exhaustive list of CPNP use cases is provided below:
CPNPユースケースの非網羅的なリストを以下に示します。
1. [RFC4176] introduces the Layer 3 VPN (L3VPN) Service Order Management functional block, which is responsible for managing the requests initiated by the Customers and tracks the status of the completion of the related operations. CPNP can be used between the Customer and the Provider to negotiate L3VPN service parameters.
1. [RFC4176]は、レイヤ3 VPN（L3VPN）サービスオーダー管理機能ブロックを紹介します。これは、顧客によって開始された要求の管理を担当し、関連する操作の完了の状況を追跡します。L3VPNサービスパラメータをネゴシエートするために、CPNPを顧客とプロバイダの間で使用できます。
A CPNP server could therefore be part of the L3VPN Service Order Management functional block discussed in [RFC4176]. A L3VPN Service YANG data model (L3SM) is defined in [RFC8299]. Once an agreement is reached, the service can be provisioned using, e.g., the L3VPN Network YANG data model specified in [L3VPN-NETWORK-YANG].
したがって、CPNPサーバーは[RFC4176]で説明したL3VPNサービス注文管理機能ブロックの一部となる可能性があります。[RFC8299]にL3VPNサービスYANGデータモデル（L3SM）が定義されています。合意に達すると、[L3VPN-Network-Yang]で指定されたL3VPNネットワークYANGデータモデルを使用して、サービスをプロビジョニングすることができます。
Likewise, a CPNP server could be part of the Layer 2 VPN (L2VPN) Service Order Management functional block. A YANG data model for L2VPN service delivery is defined in [RFC8466]. Once an agreement is reached, the L2VPN service can be provisioned using, e.g., the L2VPN Network YANG data model specified in [L2VPN-NETWORK-YANG].
同様に、CPNPサーバーは、レイヤ2 VPN（L2VPN）サービスオーダー管理機能ブロックの一部です。[RFC8466]では、L2VPNサービス配信のYANDデータモデルが定義されています。合意に達すると、[L2VPN-Network-Yang]で指定されたL2VPNネットワークYANGデータモデルを使用して、L2VPNサービスをプロビジョニングすることができます。
2. CPNP can be used between two adjacent domains to deliver IP interconnection services (e.g., enable, update, disconnect). For example, two Autonomous Systems (ASes) can be connected via several interconnection points. CPNP can be used between these ASes to upgrade existing links, request additional resources, provision a new interconnection point, etc.
2. CPNPは、IP相互接続サービス（例えば、有効化、更新、切断）を提供するために、2つの隣接ドメイン間で使用できます。例えば、2つの自律システム（ASES）はいくつかの相互接続点を介して接続することができる。既存のリンクをアップグレードし、追加のリソースを要求し、新しい相互接続点を提供するために、これらのASSの間でCPNPを使用できます。
See, for example, the framework documented in [ETICS].
たとえば、[ETICS]に記載されているフレームワークを参照してください。
3. An integrated Provider can use CPNP to rationalize connectivity provisioning needs related to its service portfolio. A CPNP server function is used by network operations teams. A CPNP interface to trigger CPNP negotiation cycles is exposed to service management teams.
3. 統合プロバイダは、CPNPを使用して、そのサービスポートフォリオに関連する接続性プロビジョニングのニーズを合理化できます。CPNPサーバー機能はネットワークオペレーションチームで使用されています。CPNPネゴシエーションサイクルをトリガするためのCPNPインタフェースは、サービス管理チームにさらされます。
4. Service Providers can use CPNP to initiate connectivity provisioning requests towards a number of Network Providers so as to optimize the cost of delivering their services. Although multiple CPNP ordering cycles can be initiated by a Service Provider towards multiple Network Providers, a subset of these orders may actually be put into effect.
4. サービスプロバイダは、CPNPを使用して、サービスを提供するコストを最適化するために、多数のネットワークプロバイダに向けて接続性プロビジョニング要求を開始できます。複数のCPNP注文サイクルは、複数のネットワークプロバイダに向かってサービスプロバイダによって開始されることができるが、これらの注文のサブセットが実際に有効になる可能性がある。
For example, a cloud Service Provider can use CPNP to request more resources from Network Providers.
たとえば、クラウドサービスプロバイダはCPNPを使用してネットワークプロバイダからのより多くのリソースを要求できます。
5. CPNP can also be used in the context of network slicing [NETSLICES-ARCH] to request network resources together with a set of requirements that need to be satisfied by the Provider. Such requirements are not restricted to basic IP forwarding capabilities, but may also include a characterization of a set of service functions that may be invoked. For the network slicing case, the instances of a CPP template could be derived from the network slice template documented in [TEAS-SLICE-NBI].
5. CPNPは、ネットワークリソースをプロバイダによって満足する必要がある一連の要件と共にリクエストするネットワークリソースのコンテキストでも使用できます。そのような要件は、基本的なIP転送機能に限定されず、呼び出される可能性がある一連のサービス機能の特性化を含み得る。ネットワークスライスケースの場合、[TEAS-SLICE-NBI]に記載されているネットワークスライステンプレートからCPPテンプレートのインスタンスを派生させることができます。
6. CPNP can be used in Machine-to-Machine (M2M) environments to dynamically subscribe to M2M services (e.g., access data retrieved by a set of sensors, extend sensor coverage, etc.).
6. CPNPは、マシンからマシン（M2M）環境で使用されて、M2Mサービス（例えば、一組のセンサによって検索されたアクセスデータ、センサの範囲などを拡張する）を動的に購読することができます。
Also, Internet of Things (IoT) [RFC6574] domains may rely on CPNP to enable dynamic access to data produced by involved objects, according to their specific policies, to various external stakeholders such as data analytics and business intelligence companies. Direct CPNP-based interactions between IoT domains and interested parties enable open access to diverse sets of data across the Internet, e.g., from multiple types of sensors, user groups, and/or geographical areas.
また、インターネット（IOT）[RFC6574]ドメインは、特定のポリシーによると、関連するオブジェクトによって生成されたデータへの動的アクセスを、データ分析やビジネスインテリジェンス企業などのさまざまな外部の利害関係者へのデータへの動的アクセスを可能にします。IOTドメインと利害関係者との間の直接CPNPベースの相互作用は、例えば複数の種類のセンサ、ユーザグループ、および/または地理的領域から、インターネット全体の多様なデータセットへのオープンアクセスを可能にする。
7. CPNP can be used in the context of Interface to Network Security Functions (I2NSF) [RFC8329] to capture the Customer-driven policies to be enforced by a set of Network Security Functions.
7. CPNPは、ネットワークセキュリティ機能（I2NSF）[RFC8329]へのインタフェースのコンテキストで使用して、一連のネットワークセキュリティ機能によって強制される顧客主導のポリシーをキャプチャすることができます。
8. A Provider offering cloud services can expose a CPNP interface to allow Customers to dynamically negotiate typical data center resources, such as additional storage, processing and networking resources, enhanced security filters, etc.
8. クラウドサービスを提供するプロバイダは、追加のストレージ、処理、ネットワークリソース、強化されたセキュリティフィルタなど、顧客が一般的なデータセンターリソースを動的にネゴシエートできるようにするためにCPNPインターフェースを公開できます。
Cloud computing Providers typically structure their computation service offerings by bundling CPU, RAM, and storage units as quotas, instances, or flavors that can be consumed in an ephemeral or temporal fashion during the lifetime of the required function. A similar approach is followed by CPNP (see for example, Section 9.2.11).
クラウドコンピューティングプロバイダは通常、CPU、RAM、および記憶装置をクォータ、インスタンス、または記憶装置としてバンドルすることによって、必要な機能の存続期間中にエフェメラルまたは時間的方法で消費できるフレーバーをバンドルすることによってそれらの計算サービス製品を構成します。同様のアプローチの後にCPNPが続きます（例えば、9.2.11節を参照）。
9. In the inter-cloud context (also called cloud of clouds or cloud federation), CPNP can be used to reserve computing and networking resources hosted by various cloud infrastructures.
9. クラウド間コンテキスト（クラウドまたはクラウドフェデレーションとも呼ばれる）では、CPNPを使用して、さまざまなクラウドインフラストラクチャによってホストされているコンピューティングおよびネットワークリソースを予約できます。
10. CDN Providers can use CPNP to extend their footprint by interconnecting their respective CDN infrastructures [RFC6770] (see Figure 1).
10. CDNプロバイダは、それぞれのCDNインフラストラクチャ[RFC6770]を相互接続することで、CPNPを使用してフットプリントを拡張できます（図1を参照）。
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
Figure 1: CDN Interconnection
図1：CDN相互接続
11. Mapping Service Providers (MSPs) [RFC7215] can use CPNP to enrich their mapping database by interconnecting their mapping system (see Figure 2). This interconnection allows the relaxation of the constraints on PxTR (Proxy Ingress/Egress Tunnel Router) in favour of native LISP (Locator/ID Separation Protocol) forwarding [RFC6830]. Also, it prevents the fragmentation of the LISP mapping database. A framework is described in [LISP-MS-DISCOVERY].
11. マッピングサービスプロバイダ（MSPS）[RFC7215]は、マッピングシステムを相互接続することで、CPNPを使用してマッピングデータベースを充実させることができます（図2を参照）。この相互接続により、ネイティブLISP（Locator / ID分離プロトコル）転送[RFC6830]を支持してPXTR（Proxy Ingress / Egress Tunnel Router）の制約の緩和を可能にします。また、LISPマッピングデータベースの断片化を防ぎます。フレームワークは[Lisp-MS-Discovery]に記載されています。
,--,--,--. ,--,--,--. ,-' `-. ,-' `-. (Mapping System 'A')===(Mapping System 'B') `-. ,-' `-. ,-' `--'--'--' `--'--'--'
- 、 - 、 - 。 - 、 - 、 - 。 - '` - 。 - '` - 。（マッピングシステム 'a'）===（マッピングシステム 'b'） ` - 。 - '` - 。 - '`--' - ' - '` --' - ' - '
Figure 2: LISP Mapping System Interconnect
図2：LISPマッピングシステムインターコネクト
12. CPNP may also be used between SDN (Software-Defined Networking) controllers in contexts where Cooperating Layered Architecture for Software-Defined Networking (CLAS) is enabled [RFC8597].
12. CPNPは、ソフトウェア定義ネットワーク（CLAS）の協調階層化アーキテクチャが有効になっているコンテキストで、SDN（ソフトウェア定義ネットワーキング）コントローラの間でも使用できます[RFC8597]。
Several CPNP deployment models can be envisaged. Two examples are listed below:
いくつかのCPNP展開モデルを想定することができます。2つの例を以下に示します。
* The Customer deploys a CPNP client while one or several CPNP servers are deployed by the Provider. A CPNP client can discover its CPNP servers using a variety of means (static, dynamic, etc.).
* 1つまたは複数のCPNPサーバーがプロバイダによってデプロイされている間、顧客はCPNPクライアントを展開します。CPNPクライアントは、さまざまな手段（静的、動的など）を使用してCPNPサーバーを検出できます。
* The Customer does not enable any CPNP client. The Provider maintains a Customer Order Management portal. The Customer can initiate connectivity provisioning quotation orders via the portal; appropriate CPNP messages are then generated and sent to the relevant CPNP server. In this model, both the CPNP client and CPNP server are under the responsibility of the same administrative entity (i.e., Network Provider).
* 顧客はCPNPクライアントを有効にしません。プロバイダは顧客注文管理ポータルを管理しています。顧客は、ポータルを介して接続性プロビジョニングの引用順序を開始することができます。その後、適切なCPNPメッセージが生成され、関連するCPNPサーバーに送信されます。このモデルでは、CPNPクライアントとCPNPサーバーの両方が同じ管理エンティティ（すなわち、ネットワークプロバイダ）の責任の下にあります。
Once the negotiation of connectivity provisioning parameters is successfully concluded, that is, an order has been placed by the Customer, the actual network provisioning operations are initiated. The specification of related dynamic resource allocation and policy enforcement schemes, as well as how CPNP servers interact with the network provisioning functional blocks on the Provider side, are out of the scope of this document.
接続性プロビジョニングパラメータのネゴシエーションが成功したら、すなわち顧客によって注文が行われているため、実際のネットワークプロビジョニング操作が開始されます。関連する動的リソース割り当ておよびポリシー執行方式の指定、ならびにCPNPサーバーがプロバイダー側のネットワークプロビジョニング機能ブロックとどのように対話するかは、この文書の範囲外です。
This document does not make any assumptions about the CPNP deployment model either.
この文書は、CPNP展開モデルについての仮定をしません。
CPNP runs between a Customer and a Provider, carrying service orders from the Customer and corresponding responses from the Provider in order to reach a service provisioning agreement. As the services offered by the Provider are well described, by means of the CPP template for connectivity matters, the negotiation process is essentially a value-settlement process, where an agreement is pursued on the values of the commonly understood information items (service parameters) included in the service description template (Section 9.1.9).
CPNPは、サービスプロビジョニング契約に到達するために、顧客とプロバイダとプロバイダとプロバイダからのサービス注文を運びます。プロバイダによって提供されるサービスがよく説明されているので、接続性のためのCPPテンプレートによって、ネゴシエーションプロセスは基本的には一般的に理解されている情報項目の値（サービスパラメータ）の値について契約を追求する価値決済プロセスです。サービス記述テンプレートに含まれています（9.1.9項）。
The content that CPNP carries and the negotiation logic invoked at Customer and Provider sides to manipulate the content (i.e., the information carried in CPNP messages to proceed with the negotiation) is transparent to the protocol.
コンテンツを操作するためにCPNPが顧客側とプロバイダ側で呼び出されたコンテンツ（すなわち、Negotiatiationを進めるためにCPNPメッセージで搬送される情報）は、プロトコルに対して透過的である。
The protocol aims to facilitate the execution of the negotiation logic by providing the required generic communication primitives.
このプロトコルは、必要な一般的な通信プリミティブを提供することによってネゴシエーションロジックの実行を容易にすることを目的としています。
Since negotiations are initiated and primarily driven by the Customer's negotiation logic, it is reasonable to assume that the Customer is the only party that can call for an agreement. An implicit approach is adopted for not overloading the protocol with additional messages. In particular, the acceptance of an offer made by the Provider signals a call for agreement from the Customer. Note that it is almost certain the Provider will accept this call since it refers to an offer that the Provider made. Of course, at any point the Provider or the Customer may quit the negotiations, each on its own grounds.
交渉は開始され、主に顧客の交渉ロジックによって推進されているため、顧客が契約を求めることができる唯一のパーティーであると仮定することは合理的です。プロトコルを追加のメッセージで過負荷にしないために暗黙的なアプローチが採用されています。特に、プロバイダによって行われたオファーの受け入れは、顧客からの合意のための呼び出しを知らせます。プロバイダがプロバイダが作成されたオファーを指すので、プロバイダがこの呼び出しを受け入れることはほぼ確実であることに注意してください。もちろん、プロバイダまたは顧客が交渉を終了することがあります。
Based on the above, CPNP adopts a quotation order/offer/answer model, which proceeds through the following basic steps (Figure 3):
上記に基づいて、CPNPは引用順序/オファー/アンサーモデルを採用しており、これは次の基本的な手順を進めます（図3）。
1. The CPNP client specifies its service requirements in a Provisioning Quotation Order (PQO). The order may include strictly or loosely defined values in the clauses describing service provisioning characteristics.
1. CPNPクライアントは、プロビジョニング引用順序（PQO）でのサービス要件を指定します。注文は、サービスプロビジョニング特性を記述する句内の厳密にまたは疎外された値を含み得る。
2. The CPNP server declines the PQO, or makes an offer to address the requirements of the PQO, or suggests a counterproposal that partially addresses the requirements of the PQO in case specific requirements cannot be accommodated.
2. CPNPサーバーはPQOを辞退するか、またはPQOの要件に対処するためのオファーを作成したり、特定の要件を確保できない場合のPQOの要件を部分的にアドレス指定する相手方を提案します。
3. The CPNP client either accepts or declines the offer. The acceptance of the offer by the CPNP client implies a call for agreement and, thus, the agreement between both parties and the conclusion of the negotiation.
3. CPNPクライアントはオファーを受け入れるか拒否します。CPNPクライアントによるオファーの受け入れは、契約の呼び出し、したがって、両当事者間の合意と交渉の結論を意味します。
+------+ +------+
|Client| |Server|
+------+ +------+
|=====Requested Service=====>|
|<=====Offered Service=======|
|=====Accepted Service======>|
Figure 3: Simplified Service Negotiation
図3：単純化されたサービス交渉
Multiple instances of CPNP may run at a Customer's or a Provider's domains. A CPNP client may be engaged in multiple, simultaneous negotiations with the same or different CPNP servers (parallel negotiations, see Section 8.10), and a CPNP server may need to negotiate with other Provider(s) as part of negotiations that are ongoing with a CPNP client (cascaded negotiations, see Section 8.8).
CPNPの複数のインスタンスは、顧客またはプロバイダのドメインで実行される可能性があります。CPNPクライアントは、同じまたは異なるCPNPサーバー（並列交渉、セクション8.10を参照）との複数の同時交渉に携わることができ、CPNPサーバーは、継続的な交渉の一部として他のプロバイダーと交渉する必要があるかもしれません。CPNPクライアント（カスケード交渉、セクション8.8を参照）。
CPNP relies on various timers to run its operations. Two types of timers are defined: those that are specific to CPNP message transmission and those that are specific to the negotiation logic. The latter are used to guide the negotiation logic at both CPNP client and CPNP server sides, particularly in cases where the CPNP client is involved in parallel negotiations with several CPNP servers or in cases where the CPNP server is, in turn, involved in negotiations with other Providers for processing a given Customer-originated quotation order. CPNP allows a CPNP server to request extra time to proceed with the negotiation. This request may be accepted or rejected by the CPNP client.
CPNPはその操作を実行するためにさまざまなタイマーに依存しています。2種類のタイマーが定義されています.CPNPメッセージ送信に固有のものとネゴシエーションロジックに固有のものです。後者は、特にCPNPクライアントが複数のCPNPサーバーとの並列交渉に関与している場合、またはCPNPサーバーが順番にインレルリファレンスに関与している場合に、CPNPクライアント側とCPNPサーバー側の両方でネゴシエーションロジックを導くために使用されます。所与の顧客発信引用順序を処理するための他のプロバイダ。CPNPを使用すると、CPNPサーバーがネゴシエーションを続行するための余分な時間を要求することができます。この要求は、CPNPクライアントによって受け入れられるか拒否されてもよい。
Providers may need to publish available services to the Customers (see Section 4). CPNP may optionally support this functionality. Dedicated templates can be defined for the purpose of service announcement, which will be used by the CPNP clients to initiate their CPNP negotiation cycles.
プロバイダは、顧客に利用可能なサービスを公開する必要があるかもしれません（セクション4を参照）。CPNPはオプションでこの機能をサポートすることがあります。専用テンプレートは、サービスアナウンスメントの目的で定義できます。これは、CPNPクライアントがCPNPネゴシエーションサイクルを開始するために使用されます。
For the sake of simplicity, a single offer/answer stage is assumed within one CPNP negotiation cycle. Nevertheless, as already stated, multiple CPNP negotiation cycles can be undertaken by a CPNP client (see Figure 4).
簡単にするために、1つのCPNPネゴシエーションサイクル内で単一のオファー/回答段階が想定される。それにもかかわらず、すでに述べたように、複数のCPNPネゴシエーションサイクルはCPNPクライアントによって行われる可能性があります（図4を参照）。
The model is flexible enough to accommodate changing conditions during the lifetime of a service (e.g., the introduction of an additional VPN site).
モデルは、サービスの寿命の間に変化する条件に対応するのに十分柔軟性があります（例えば、追加のVPNサイトの導入）。
+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=====Quotation Order=====>| |=====Quotation Order=====>|
|<==========Offer==========| |<==========Offer==========|
|===========Accept========>| |==========Decline========>|
1-Step Successful Negotiation 1-Step Failed Negotiation Cycle Cycle
1ステップ成功したネゴシエーション1ステップの失敗ネゴシエーションサイクルサイクル
+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|===Quotation Order(a)====>| |===Quotation Order(i)====>|
|<==========Offer==========| |<==========Offer==========|
|==========Decline========>| |==========Decline========>|
|===Quotation Order(b)====>| |===Quotation Order(j)====>|
|<==========Offer==========| |<==========Offer==========|
|===========Accept========>| |==========Decline========>|
|===Quotation Order(k)====>|
|<==========Offer==========|
|==========Decline========>|
|===Quotation Order(l)====>|
|<==Fail to make an offer==|
N-Step Negotiation Cycle: N-Step Negotiation Cycle: Successful Negotiation Failed Negotiation
Nステップネゴシエーションサイクル：Nステップネゴシエーションサイクル：交渉が成功した交渉失敗
Figure 4: Overall Negotiation Process
図4：全体的なネゴシエーションプロセス
The means used by a CPNP client to retrieve a list of active/accepted offers are not defined in this document.
Active / Acpleded Offerのリストを取得するためにCPNPクライアントが使用する手段は、このドキュメントでは定義されていません。
An order can be implicitly or explicitly activated. Section 3.11 of [RFC7297] specifies a dedicated clause called Activation Means. Such a clause indicates the required action(s) to be undertaken to activate access to the (IP connectivity) service. This document defines a dedicated CPNP message that can be used for explicit activation (Section 9.2.11).
注文は暗黙的にまたは明示的に起動することができます。[RFC7297]のセクション3.11は起動手段と呼ばれる専用句を指定します。そのような句は、（IP接続）サービスへのアクセスを起動するために行われる必要な動作を示しています。このドキュメントは、明示的な起動に使用できる専用のCPNPメッセージを定義します（セクション9.2.11）。
CPNP is a client/server protocol that can run over any transport protocol. The default transport mode is UDP secured with Datagram Transport Layer Security (DTLS) [RFC6347]. No permanent CPNP transport session needs to be maintained between the client and the server.
CPNPは、任意のトランスポートプロトコルを介して実行できるクライアント/サーバープロトコルです。デフォルトのトランスポートモードは、データグラムトランスポートレイヤセキュリティ（DTLS）[RFC6347]で保護されています。クライアントとサーバーの間に永続的なCPNPトランスポートセッションを維持する必要はありません。
The CPNP client can be configured with the CPNP server(s). Typically, the CPNP client is configured with an IP address together with a port number using manual or dynamic configuration means (e.g., DHCP). Alternatively, a Provider may advertise the port number (CPNP_PORT) it uses to bind the CPNP service using SRV [RFC2782].
CPNPクライアントは、CPNPサーバーで構成できます。通常、CPNPクライアントは、手動または動的構成手段（例えば、DHCP）を使用してポート番号とともにIPアドレスを使用して構成されています。あるいは、プロバイダは、SRV [RFC2782]を使用してCPNPサービスをバインドするために使用するポート番号（CPNP_PORT）をアドバタイズすることができる。
The CPNP client may be provided with a domain name of the CPNP server for PKIX-based authentication purposes. CPNP servers should prefer the use of DNS-ID and SRV-ID over CN-ID identifier types in certificate requests (Section 2.3 of [RFC6125]). URI-IDs should not be used for CPNP server identity verification.
CPNPクライアントには、PKIXベースの認証目的のためにCPNPサーバのドメイン名を指定することができる。CPNPサーバーは、証明書要求のCN-ID識別子型でDNS-IDおよびSRV-IDの使用を好む（[RFC6125]のセクション2.3）。CPNP Server ID検証にはURI-IDを使用しないでください。
The client sends CPNP requests using CPNP_PORT as the destination port number. The same port number used as the source port number of a CPNP request sent to a CPNP server is used by the server to reply to that request.
クライアントは、宛先ポート番号としてCPNP_PORTを使用してCPNP要求を送信します。CPNPサーバーに送信されたCPNP要求の送信元ポート番号と同じポート番号が、サーバーがその要求に返信するために使用されます。
CPNP is independent of the IP address family.
CPNPはIPアドレスファミリとは無関係です。
CPNP retransmission for unreliable transports is discussed in Section 11.4.
信頼性の低い輸送のためのCPNP再送は、11.4項で議論されています。
Considerations related to mutual authentication are discussed in Section 13.
相互認証に関連する考慮事項については、セクション13で説明されています。
As an input to its decision-making process, the CPNP server may be connected to various external modules such as Customer Profiles, Network Topology, Network Resource Management, Order Repositories, AAA, and Network Provisioning Manager (an example is shown in Figure 5).
その意思決定プロセスへの入力として、CPNPサーバは、顧客プロファイル、ネットワークトポロジ、ネットワークリソース管理、注文リポジトリ、AAA、およびNetwork Provisioning Managerなどのさまざまな外部モジュールに接続することができます（例を図5に示します）。。
These external modules provide inputs to the CPNP server so that it can do the following:
これらの外部モジュールはCPNPサーバーへの入力を提供して次のことができるようになります。
* Check whether a Customer is entitled to initiate a provisioning quotation request.
* 顧客がプロビジョニング引用要求を開始する権利があるかどうかを確認してください。
* Check whether a Customer is entitled to cancel an ongoing order.
* 顧客が進行中の注文をキャンセルする権利があるかどうかを確認してください。
* Check whether administrative data (e.g., billing-related information) have been verified before the processing of the request starts.
* 要求の処理が開始される前に管理データ（例えば、請求関連情報）が検証されているかどうかを確認してください。
* Check whether network capacity is available or additional capacity is required.
* ネットワーク容量が利用可能かどうか、または追加の容量が必要かどうかを確認してください。
* Receive guidelines from network design and sales blocks (e.g., pricing, network usage levels, thresholds associated with the number of CPP templates that can be processed over a given period of time as a function of the nature of the service to be delivered, etc.).
* ネットワーク設計および販売ブロックからのガイドライン（価格、ネットワーク使用量レベル、特定の期間にわたるCPPテンプレートの数に関連したしきい値など、配信されるサービスの性質などの機能として処理することができる。）。
* Transfer completed orders to network provisioning blocks (referred to as "Network Provisioning Manager" in Figure 5). For example, the outcome of CPNP may be passed to modules such as Application-Based Network Operations (ABNO) [RFC7491] or network controllers. These controllers will use protocols such as NETCONF [RFC6241] to interact with the appropriate network nodes and functions for the sake of proper service activation and delivery.
* 完成した注文をネットワークプロビジョニングブロックに転送する（図5の「ネットワークプロビジョニングマネージャ」と呼ばれます）。たとえば、CPNPの結果は、アプリケーションベースのネットワーク操作（ABNO）[RFC7491]またはネットワークコントローラなどのモジュールに渡されてもよい。これらのコントローラは、NetConf [RFC6241]のようなプロトコルを使用して、適切なネットワークノードと対話し、適切なサービスの活性化と配信のために機能します。
The above list of CPNP server operations is not exhaustive.
上記のCPNPサーバー操作のリストは網羅的なものではありません。
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.Business & Administrative Management .
.+------------------------++---------------------------+.
.| Business Guidelines || Billing & Charging |.
.+-----------+------------++-----------+---------------+.
. | | .
. +-------------------+ | .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
.Order Handling Management | | .
. +-------------------+ +-------+-----+--------------+ .
. |Network Topology DB+--+ CPNP Server | .
. +-------------------+ +-+---+---+---+---+-----+----+ .
. | | | | | | .
. +------------------------+-+ | | | | | .
. | Network Dimensioning | | | | | | .
. | & Planning | | | | | | .
. +--------------------------+ | | | | | .
. +----------------------------+-+ | | | +---+----+ .
. | | | | | | AAA | .
. | Network +------------+ | | | +--------+ .
. | Resource | +------------+-+ | +-+----------+ .
. | Management | | Customer | | | Orders | .
. | | | Profiles | | | Repository | .
. +-----------------+ +--------------+ | +------------+ .
. . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
+--------------------------------------+----------------+
| Network Provisioning Manager |
+-------------------------------------------------------+
Figure 5: Order Handling Management Functional Block (Focus on Internal Interfaces)
図5：注文処理管理機能ブロック（内部インターフェイスに焦点を当てて）
The following order-handling modes can also be configured on the server:
次の注文処理モードもサーバー上に設定できます。
Fully automated mode: This mode does not require any action from the administrator when receiving a request for a service. The server can execute its decision-making process related to the orders received and can generate corresponding offers.
完全自動モード：このモードでは、サービスの要求を受信すると、管理者からの処置は不要です。サーバーは、受信した注文に関連するその意思決定プロセスを実行し、対応するオファーを生成できます。
Administrative validation checking: Some or all of the server's operations are subject to administrative validation procedures. This mode requires an action from the administrator for every request received. To that aim, the CPNP methods that can be automatically handled by the server (or are subject to one or several validation administrative checks) can be configured on the server.
管理検証検査：サーバーの操作の一部または全部は管理検証手順の対象となります。このモードでは、受信したすべてのリクエストに対して管理者からのアクションが必要です。その目的のために、サーバーによって自動的に処理される可能性があるCPNPメソッド（または1つまたは複数の検証管理チェック）をサーバー上に設定できます。
A CPNP session entry is represented by a tuple defined as follows:
CPNPセッションエントリは、次のように定義されたタプルによって表されます。
* Transport session (typically, the IP address of the CPNP client, the client's port number, the IP address of the CPNP server, and the CPNP server's port number).
* トランスポートセッション（通常は、CPNPクライアントのIPアドレス、クライアントのポート番号、CPNPサーバーのIPアドレス、およびCPNPサーバーのポート番号）。
* Incremented sequence number (Section 11.3).
* インクリメントされたシーケンス番号（セクション11.3）。
* Customer agreement identifier: This is a unique identifier assigned to the order under negotiation by the CPNP client (Section 9.1.1). This identifier is also used by the client to identify the agreement that will result from a successful negotiation.
* 顧客合意ID：これは、CPNPクライアントによるネゴシエーションの下の順序に割り当てられた一意の識別子です（セクション9.1.1）。この識別子は、クライアントが正常に交渉することから生じる契約を識別するためにも使用されます。
* Provider agreement identifier: This is a unique identifier assigned to the order under negotiation by the CPNP server (Section 9.1.2). This identifier is also used by the server to identify the agreement that will result from a successful negotiation.
* プロバイダ契約ID：これは、CPNPサーバーによるネゴシエーションの下の順序に割り当てられた一意の識別子です（セクション9.1.2）。この識別子は、正常な交渉から生じる契約を識別するためにサーバーによっても使用されます。
* Transaction-ID (Section 8.4).
* トランザクションID（8.4項）
A CPNP transaction occurs between a client and a server for completing, modifying, or withdrawing a service agreement, and comprises all CPNP messages exchanged between the client and the server, from the first request sent by the client to the final response sent by the server. A CPNP transaction is bound to a CPNP session (Section 8.3).
CPNPトランザクションは、サービス契約を完了、修正、または引き出すためのクライアントとサーバー間で発生し、クライアントによって送信された最初の要求からサーバーによって送信された最終的な応答に、クライアントとサーバー間で交換されるすべてのCPNPメッセージを含みます。。CPNPトランザクションはCPNPセッションにバインドされています（セクション8.3）。
Because multiple CPNP transactions can be maintained by the CPNP client, the client must assign an identifier to uniquely identify a given transaction. This identifier is the Transaction-ID.
複数のCPNPトランザクションをCPNPクライアントによって管理できるため、クライアントは特定のトランザクションを一意に識別するために識別子を割り当てる必要があります。この識別子はトランザクションIDです。
The Transaction-ID must be randomly assigned by the CPNP client, according to the best current practice for generating random numbers [RFC4086] that cannot be guessed easily. The Transaction-ID is used for validating CPNP responses received by the client.
取引IDは、乱数を生成するための最良の現在の実践に従って、CPNPクライアントによってランダムに割り当てられている必要があります[RFC4086]を容易に推測できない[RFC4086]。transaction-idは、クライアントによって受信されたCPNP応答を検証するために使用されます。
In the context of a transaction, the client needs to select a sequence number randomly and then needs to assign it to the first CPNP message to send. This number is then incremented for each request message that is subsequently sent within the ongoing CPNP transaction (see Section 11.3).
トランザクションのコンテキストでは、クライアントはランダムにシーケンス番号を選択してから送信する最初のCPNPメッセージに割り当てる必要があります。その後、この数は、続いて進行中のCPNPトランザクション内で送信される要求メッセージごとにインクリメントされます（セクション11.3を参照）。
CPNP adopts a simple retransmission procedure that relies on a retransmission timer represented by RETRANS_TIMER and a maximum retry threshold. The use of RETRANS_TIMER and a maximum retry threshold are described in Section 11.
CPNPは、RETRANS_TIMERによって表される再送信タイマと最大のリトライスレッショルドに依存する簡単な再送信手順を採用しています。RETRANS_TIMERおよび最大リトライ閾値の使用は、セクション11に記載されている。
The response timer (EXPECTED_RESPONSE_TIME) is set by the client to denote the time, in seconds, the client will wait to receive a response from the server to a PQO request (see Section 9.1.6). If the timer expires, the respective PQO is cancelled by the client, and a CANCEL message is generated accordingly.
応答タイマ（expected_response_time）は、クライアントをクライアントで設定して、クライアントはサーバーからPQO要求に応答を受信するのを待ちます（セクション9.1.6を参照）。タイマーが期限切れになると、それぞれのPQOがクライアントによってキャンセルされ、それに応じてキャンセルメッセージが生成されます。
The expected offer timer (EXPECTED_OFFER_TIME) is set by the server to indicate the time by when the CPNP server is expected to make an offer to the CPNP client (see Section 9.1.7). If no offer is received by then, the CPNP client will consider the order as rejected.
予想されるオファータイマー（expected_offer_time）は、CPNPサーバーがCPNPクライアントにオファーを作成することが予想されるときの時間を示すためにサーバーによって設定されます（セクション9.1.7を参照）。その後、オファーが受信されない場合、CPNPクライアントは拒否された順序を考慮します。
An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server to represent the time, in minutes, after which an offer made by the server becomes invalid (see Section 9.1.8).
オファーの有効期限タイマー（Validity_Offer_time）は、サーバーによってサーバーによって設定され、その後、サーバーによって行われたオファーが無効になります（セクション9.1.8を参照）。
CPNP operations are listed below. They may be augmented depending on the nature of some transactions or because of security considerations that may necessitate a distinct CPNP client/server authentication phase before negotiation begins.
CPNP操作を以下に示します。それらは、いくつかのトランザクションの性質、またはネゴシエーションが始まる前に異なるCPNPクライアント/サーバ認証フェーズを必要とする可能性があるセキュリティ上の考慮事項のために拡張されてもよい。
QUOTATION (Section 9.2.1): This operation is used by the client to initiate a PQO. Upon receipt of a QUOTATION request, the server may respond with a PROCESSING, OFFER, or a FAIL message. A QUOTATION-initiated transaction can be terminated by a FAIL message.
引用符（9.2.1項）：この操作は、PQOを開始するためにクライアントによって使用されます。引用要求を受信すると、サーバーは処理、オファー、またはフェイルメッセージで応答することができます。引用開始トランザクションは、FAILメッセージによって終了できます。
PROCESSING (Section 9.2.2): This operation is used to inform the remote party that its message (the order quotation or the offer) was received and it is being processed. This message can also be issued by the server to request more time, in which case, the client may reply with an ACK or FAIL message depending on whether extra time can or cannot be granted.
処理（9.2.2項）：この操作は、そのメッセージ（順序引用またはオファー）を受信したことを遠隔パーティに通知し、処理中です。このメッセージは、サーバによってもっと要求するためにサーバによって発行され、その場合、クライアントは追加の時間が与えられないか、または許可されないかどうかに応じてACKまたはFAILメッセージで返信することができる。
OFFER (Section 9.2.3): This operation is used by the server to inform the client about an offer that can best accommodate the requirements indicated in the previously received QUOTATION message.
オファー（9.2.3節）：この操作は、以前に受信された引用符で示されている要件に最もよく適応できるオファーについてクライアントに通知するためにサーバーによって使用されます。
ACCEPT (Section 9.2.4): This operation is used by the client to confirm the acceptance of an offer made by the server. This message implies a call for agreement. An agreement is reached when an ACK is subsequently received from the server, which is likely to happen if the message is sent before the offer validity time expires; the server is unlikely to reject an offer that it has already made.
承認（9.2.4項）：この操作は、サーバーによって行われたオファーの受け入れを確認するためにクライアントによって使用されます。このメッセージは契約の呼び出しを意味します。ACKがその後サーバーから受信されると、合意に達する。サーバーは、すでに作成したオファーを拒否することはほとんどありません。
DECLINE (Section 9.2.5): This operation is used by the client to reject an offer made by the server. The ongoing transaction may not be terminated immediately, e.g., the client may issue another order or the server may issue another offer.
辞退（9.2.5項）：この操作は、クライアントがサーバーによって行われたオファーを拒否するために使用されます。進行中のトランザクションは直ちに終了されない、例えばクライアントは別の注文を発行することができ、あるいはサーバが他のオファーを発行することができる。
ACK (Section 9.2.6): This operation is used by the server to acknowledge the receipt of an ACCEPT or WITHDRAW message or by the client to confirm the server's request for a time extension (conveyed in a PROCESSING message) in order to process the last received quotation order.
ACK（セクション9.2.6）：この操作は、承認または退会メッセージまたはクライアントの受信を確認するために、またはクライアントが処理するためにサーバーの要求を確認するために使用されます。最後の受信引用順序。
CANCEL (Section 9.2.7): This operation is used by the client to cancel (quit) the ongoing transaction.
キャンセル（セクション9.2.7）：この操作は、継続的なトランザクションをキャンセル（終了）するためにクライアントによって使用されます。
WITHDRAW (Section 9.2.8): This operation is used by the client to withdraw a completed order (i.e., an agreement).
撤回（9.2.8項）：この操作はクライアントが完成した順序を撤回するために使用されます（すなわち、契約）。
UPDATE (Section 9.2.9): This operation is used by the client to update an existing agreement. For example, this method can be invoked to add a new VPN site. This method will trigger a new negotiation cycle.
更新（9.2.9節）：この操作はクライアントが既存の契約を更新するために使用されます。たとえば、このメソッドは新しいVPNサイトを追加するために呼び出すことができます。このメソッドは新しいネゴシエーションサイクルをトリガーします。
FAIL (Section 9.2.10): This operation is used by the server to indicate that it cannot accommodate the requirements documented in the PQO conveyed in the QUOTATION message or to inform the client about an error encountered when processing the received message. In either case, the message implies that the server is unable to make offers, and, as a consequence, it terminates the ongoing transaction.
失敗（9.2.10節）：この操作は、引用符で運ばれているPQOに記載されている要件に対応できない、または受信したメッセージを処理するときに発生したエラーについてクライアントに通知することを示すためにサーバーによって使用されます。どちらの場合でも、メッセージはサーバーがオファーを作成できないことを意味し、結果として継続的なトランザクションを終了します。
This message is also used by the client to reject a time extension request in a PROCESSING message received from the server. The message includes a status code that provides explanatory information.
このメッセージは、サーバから受信した処理メッセージにおいて時間拡張要求を拒否するためにクライアントによっても使用される。メッセージには、説明情報を提供するステータスコードが含まれています。
The above CPNP primitives are service independent. CPNP messages may transparently carry service-specific objects that are handled by the negotiation logic at either side.
上記のCPNPプリミティブはサービスに依存しません。CPNPメッセージは、どちらの側で交渉ロジックによって処理されるサービス固有のオブジェクトを透過的に携帯することがあります。
The document defines the service objects that are required for connectivity provisioning negotiation purposes (see Section 8.7). Additional service-specific objects for CPNP messages to accommodate alternative deployment schemes or other service provisioning needs can be defined in the future.
この文書は、接続性プロビジョニングのネゴシエーションの目的に必要なサービスオブジェクトを定義します（セクション8.7を参照）。代替の展開方式または他のサービスプロビジョニングのニーズに対応するためのCPNPメッセージ用の追加のサービス固有のオブジェクトは、将来的に定義できます。
CPNP makes use of several flavors of Connectivity Provisioning Documents (CPD). These documents follow the same CPP template described in [RFC7297].
CPNPは、接続性プロビジョニング文書（CPD）のいくつかのフレーバーを利用します。これらの文書は[RFC7297]に記載されているのと同じCPPテンプレートに従います。
Requested CPD: Refers to the CPD included by a CPNP client in a QUOTATION request.
要求されたCPD：引用要求でCPNPクライアントによって含まれるCPDを参照します。
Offered CPD: This document is included by a CPNP server in an OFFER message. Its information reflects the proposal of the server to accommodate all or a subset of the clauses depicted in a Requested CPD. A validity time is associated with the offer made.
提供されたCPD：この文書はオファーメッセージ内のCPNPサーバーによって含まれています。その情報は、要求されたCPDに描かれている句の全部またはサブセットに対応するためのサーバーの提案を反映しています。有効期間はオファーと関連付けられています。
Accepted CPD: If the client accepts an offer made by the server, the Offered CPD is included in an ACCEPT message. This CPD is also included in an ACK message. Thus, a three-way handshake procedure is followed for successfully completing the negotiation.
承認されたCPD：クライアントがサーバーによって行われたオファーを受け入れる場合、提供されたCPDはAcceptメッセージに含まれています。このCPDはACKメッセージに含まれています。したがって、交渉を正常に完了するための三方ハンドシェイク手順に従う。
Figure 6 shows a typical CPNP negotiation cycle and the use of the different types of CPDs.
図6は、典型的なCPNPネゴシエーションサイクルとさまざまな種類のCPDの使用を示しています。
+------+ +------+
|Client| |Server|
+------+ +------+
|======QUOTATION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|=======ACCEPT (Accepted CPD)========>|
|<=======ACK (Accepted CPD)===========|
| |
Figure 6: Connectivity Provisioning Documents
図6：接続性プロビジョニング文書
A CPD can include parameters with fixed values, loosely defined values, or any combination thereof. A CPD is said to be concrete if all clauses have fixed values.
CPDは、固定値、疎結合値、またはそれらの任意の組み合わせを有するパラメータを含むことができる。すべての句が固定値を有する場合、CPDは具体的であると言われている。
A typical evolution of a negotiation cycle would start with a quotation order with loosely defined parameters, and then, as offers are made, it would conclude with a concrete CPD for calling for the agreement.
交渉サイクルの典型的な進化は、ゆるく定義されたパラメータを使用して引用順序で始まり、その後、オファーがなされているので、契約を呼び出すための具体的なCPDで結論付けるでしょう。
If the server detects that network resources from another Network Provider need to be allocated in order to accommodate the requirements described in a PQO (e.g., in the context of an inter-domain VPN service, additional Provider Edge (PE) router resources need to be allocated), the server may generate child PQOs to request the appropriate network provisioning operations (see Figure 7). In such a situation, the server also behaves as a CPNP client. The server associates the parent order with its child PQOs. How this is achieved is implementation specific (e.g., this can be typically achieved by locally adding the reference of the child PQO to the parent order).
PQOに記載されている要件に対応するために（例えば、ドメイン間VPNサービスのコンテキストでは、追加のプロバイダエッジ（PE）ルータリソースを参照するためにサーバが他のネットワークプロバイダから割り当てられる必要があることをサーバが検出する必要がある場合割り当てられた）、サーバーは適切なネットワークプロビジョニング操作を要求するために子PQOを生成することがあります（図7を参照）。そのような状況では、サーバーはCPNPクライアントとしても動作します。サーバーは親の注文をその子PQOと関連付けます。これがどのように達成されるかは実装固有のものです（例えば、これは通常、子PQOの参照を親順にローカルに追加することによって達成できます）。
+------+ +--------+ +--------+
|Client| |Server A| |Server B|
+------+ +--------+ +--------+
| | |
|=====QUOTATION=====>| |
|<====PROCESSING=====| |
| |=====QUOTATION=====>|
| |<====PROCESSING=====|
| |<=======OFFER=======|
| |=====PROCESSING====>|
| |=======ACCEPT======>|
| |<=======ACK=========|
|<=======OFFER=======| |
|=====PROCESSING====>| |
|=======ACCEPT======>| |
|<=======ACK=========| |
| | |
Figure 7: Example of Child Orders
図7：子命令の例
Note that the server must not activate recursion for an order if the client includes a negotiation option to restrict the negotiation scope to the resources of the server's domain (Section 9.1.10.3).
クライアントにネゴシエーションスコープをサーバのドメインのリソースに制限するためのネゴシエーションオプションが含まれている場合、サーバは再帰をアクティブにしてはいけません（セクション9.1.10.3）。
If recursion is not explicitly disabled, the server may notify the client when appropriate (Section 9.2.2). Such notification may depend on the nature of the service and also regulatory considerations.
再帰が明示的に無効になっていない場合、サーバーは適切な場合にクライアントに通知することがあります（セクション9.2.2）。そのような通知は、サービスの性質および規制上の考慮事項によって異なります。
A composite service (e.g., connectivity) requested by a Customer could imply multi-segment services (e.g., multi-segment connectivity spanning an end-to-end scope), in the sense that one single CPNP request is decomposed into multiple connectivity requests on the Provider's side (thereby leading to child orders). The Provider is in charge of handling the complexity of splitting the generic provisioning order in a multi-segment context. Such complexity is local to the Provider.
顧客によって要求された複合サービス（例えば、接続性）は、1つの単一のCPNP要求が複数の接続要求に分解されるという意味で、マルチセグメントサービス（例えば、エンドツーエンドスコープにまたがるマルチセグメント接続）を意味することができる。プロバイダの側面（それによって子供の注文につながる）。プロバイダは、マルチセグメントコンテキストで一般的なプロビジョニング順序を分割する複雑さを処理することを担当しています。そのような複雑さはプロバイダのローカルです。
A CPNP client may undertake multiple negotiations in parallel with several servers for various reasons, such as cost optimization and fail-safety. These multiple negotiations may lead to one or many agreements.
CPNPクライアントは、コストの最適化やフェイルセーフティなどのさまざまな理由で、複数のサーバーと並行して複数のネゴシエーションを行うことができます。これらの複数の交渉は、1つまたは複数の契約につながる可能性があります。
The salient point underlining the parallel negotiation scenarios is that, although the negotiation protocol is strictly between two parties, this may not be the case of the negotiation logic. The CPNP client negotiation logic may need to collectively drive parallel negotiations, as the negotiation with one server may affect the negotiation with other servers; for example, it may need to use the responses from all servers as an input for determining the messages (and their content) to subsequently send within the course of each individual negotiation. Therefore, timing is an important aspect on the client's side. The CPNP client needs to have the ability to synchronize the receipt of the responses from the servers. CPNP takes into account this requirement by allowing clients to specify in the QUOTATION message the time by which the server needs to respond (see Section 9.1.6).
並列交渉シナリオの下線を引き下げることは、ネゴシエーションプロトコルは2つの締約国間の間に厳密にあることですが、これはネゴシエーションロジックの場合ではないかもしれません。1つのサーバとの交渉が他のサーバとの交渉に影響を与える可能性があるため、CPNPクライアントネゴシエーションロジックは並列交渉をまとめて駆動する必要があるかもしれません。たとえば、すべてのサーバーからの応答を、メッセージ（およびその内容）を決定するための入力として、その後、各個々のネゴシエーションの過程で送信する必要があるかもしれません。したがって、タイミングはクライアント側の重要な側面です。CPNPクライアントは、サーバーからの応答の受信を同期させる機能を持つ必要があります。CPNPは、クライアントがサーバーが応答する必要がある時刻にクライアントが引用符で指定することを許可することでこの要件を考慮に入れる（セクション9.1.6を参照）。
Both the client and the server maintain repositories to store ongoing orders. How these repositories are maintained is deployment specific. It is out of scope of this document to elaborate on such considerations. Timestamps are also logged to track state change. Tracking may be needed for various reasons, including regulatory or billing ones.
クライアントとサーバーの両方が継続的な注文を保存するためのリポジトリを維持します。これらのリポジトリがどのように維持されるかは展開固有です。このような考慮事項について詳しく説明するのはこの文書の範囲外です。タイムスタンプは、状態の変更を追跡するためにログに記録されます。規制上または請求書を含むさまざまな理由で追跡が必要になる場合があります。
In order to accommodate failures that may lead to the reboot of the client or the server, the use of permanent storage is recommended, thereby facilitating state recovery.
クライアントまたはサーバーの再起動につながる可能性がある障害に対応するために、永久保管の使用を推奨し、それによって状態の回復を促進します。
This is the list of the typical states that can be associated with a given order on the client's side:
これは、クライアントの側面で指定された順序に関連付けることができる一般的な状態のリストです。
Created: The order has been created. It is not handled by the client until the administrator allows it to be processed.
作成：注文が作成されました。管理者が処理を許可するまでクライアントによって処理されません。
AwaitingProcessing: The administrator has approved the processing of a created order, but the order has not been handled yet.
処理を待っています：管理者は作成された順序の処理を承認しましたが、注文はまだ処理されていません。
PQOSent: The order has been sent to the server.
PQOSENT：注文がサーバーに送信されました。
ServerProcessing: The server has confirmed the receipt of the order.
サーバープロセス：サーバーは注文の受信を確認しました。
OfferReceived: An offer has been received from the server.
OfferReceived：サーバーからオファーが受信されました。
OfferProcessing: A received offer is being processed by the client.
オファー処理：受信したオファーがクライアントによって処理されています。
AcceptSent: The client has confirmed the offer to the server.
承認：クライアントはサーバーへのオファーを確認しました。
Completed: The offer has been acknowledged by the server.
完了：オファーはサーバーによって認められました。
Cancelled: The order has failed or was cancelled.
キャンセル：注文が失敗したかキャンセルされました。
Sub-states may be defined (e.g., to track failed vs. cancelled orders), but those are not shown in Figure 8.
サブ状態は定義されていてもよい（例えば、失敗したVS.キャンセル命令を追跡するために）は、図8には示されていない。
+------------------+
| Created |-----------------+
+------------------+ |
| |
v |
+------------------+ |
|AwaitingProcessing|----------------+|
+------------------+ ||
| ||
QUOTATION/UPDATE ||
v ||
+------------------+ ||
| PQOSent |---CANCEL------+||
+------------------+ vvv
| +-----+
PROCESSING | |
v | |
+------------------+ CANCEL | C |
| ServerProcessing |------------>| A |
+------------------+ FAIL | N |
| | C |
| | E |
OFFER | L |
| | L |
v | E |
+------------------+ | D |
| OfferReceived |---CANCEL--->| |
+------------------+ | |
| PROCESSING +-----+
v ^^^
+------------------+ |||
| OfferProcessing |---DECLINE-----+||
+------------------+ ||
| ACCEPT ||
v ||
+------------------+ ||
| AcceptSent |---CANCEL-------+|
+------------------+ |
| ACK |
v |
+------------------+ |
| Completed |---WITHDRAW------+
+------------------+
Figure 8: Example of a CPNP Finite State Machine (Client Side)
図8：CPNP有限ステートマシンの例（クライアント側）
The following lists the states on the server's side that can be associated with a given order and a corresponding offer:
次に、指定された順序とそれに対応するオファーに関連付けることができるサーバー側の状態をリストします。
PQOReceived: The order has been received from the client.
pqoreceived：クライアントから順序が受信されました。
AwaitingProcessing: The order is being processed by the server. An action from the server administrator may be needed.
処理を待っています：注文はサーバーによって処理されています。サーバー管理者からのアクションが必要になる可能性があります。
OfferProposed: The request has been successfully handled, and an offer has been sent to the client.
OfferProposed：要求は正常に処理され、オファーがクライアントに送信されました。
ProcessingReceived: The server has received a PROCESSING message for an offer sent to the client.
処理済み：サーバーはクライアントに送信されたオファーの処理メッセージを受信しました。
AcceptReceived: The server has received a confirmation for the offer from the client.
ACCEPTReceived：サーバーはクライアントからオファーの確認を受け取りました。
Completed: The server has acknowledged the offer (accepted by client) to the client. Transitioning to this state assumes that the ACK was received by the client (this can be detected by the server if it receives a retransmitted ACCEPT message from the client).
完了：サーバーはクライアントにオファー（クライアントによって受け入れられた）を認めました。この状態への移行は、ACKがクライアントによって受信されたことを前提としています（これは、クライアントから再送信された受信メッセージを受信した場合はサーバーによって検出できます）。
Cancelled: The order cannot be accommodated, or it has been cancelled by the client. Associated resources must be released in the latter case, if previously reserved.
キャンセル：注文に対応することも、クライアントによってキャンセルされています。以前に予約されている場合、関連するリソースは後者の場合にリリースされなければなりません。
ChildCreated: A child order has been created in cases where resources from another Network Provider are needed.
保育：別のネットワークプロバイダからのリソースが必要な場合には、子注文が作成されました。
ChildPQOSent: A child order has been sent to the remote server.
ChildPQosent：子順序がリモートサーバーに送信されました。
ChildServerProcessing: A child order is being processed by the remote server.
ChildServerプロセス：子順序がリモートサーバーによって処理されています。
ChildOfferReceived: The remote server has received an offer to a child order.
ChildOfferReceived：リモートサーバーは子順序にオファーを受け取りました。
ChildOfferProcessing: A received offer to a child order is being processed.
ChildOfferプロセス：子供の順序への受信されたオファーが処理されています。
ChildAcceptSent: The child offer (the offer received from the remote server in response to a child order) is confirmed to the remote server.
Childacceptsent：子オファー（子注文に応じてリモートサーバーから受信したオファー）がリモートサーバーに確認されます。
ChildCompleted: The accepted child offer has been acknowledged by the remote server.
ChildCompleted：承認された子オファーはリモートサーバーによって確認されました。
+------------------+ +------------------+
|AwaitingProcessing|<----------| ChildCreated |
+------------------+ +------------------+
| | ^
v | |
+------------------+ | |
| ChildPQOSent |----------------+| Q
+------------------+ || U
| || O
QUOTATION/UPDATE || T
v || A +--------------------+
+---------------------+ CANCEL || T | PQOReceived |
|ChildServerProcessing|------------+|| I +--------------------+
+---------------------+ FAIL vvv O | |
| +-----+ N CANCEL |
PROCESSING | |<---|-------+ PROCESSING
v | | | v
+------------------+ | | +------------------------+
|ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing |
+------------------+ | A | +------------------------+
| | N | ^ | OFFER
OFFER | C | | +------------------+
| | E |<DECLINE-| OfferProposed |
| | L | | +------------------+
v | L | | |
+------------------+ | E | | PROCESSING
|ChildOfferReceived|---CANCEL----| D | | v
+------------------+ | | | +------------------+
| | |<DECLINE-| Proc'ingReceived |
PROCESSING | | |+------------------+
| +-----+ | | ACCEPT
v ^^^^^ | v
+------------------+ ||||| | +------------------+
|ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-| AcceptReceived |
+------------------+ ||| | +------------------+
|ACCEPT ||| | |ACK
v ||| | v
+------------------+ ||| | +------------------+
| ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| Completed |
+------------------+ | | +------------------+
| ACK | |
v | |
+------------------+ | |
| ChildCompleted |---WITHDRAW-----+ |
| +---------------------------+
+------------------+
Figure 9: CPNP Finite State Machine (Server Side)
図9：CPNP有限ステートマシン（サーバー側）
This section defines CPNP objects using the Routing Backus-Naur Form (RBNF) format defined in [RFC5511]. Please also note the following:
このセクションでは、[RFC5511]で定義されているルーティング・バックスナウス・ナウラス（RBNF）形式を使用してCPNPオブジェクトを定義します。また、以下に注意してください。
| Note 1: The formats of CPNP messages are provided using a
| generic format. Implementors can adapt RBNF definitions to
| their "favorite" message format. For example, JSON [RFC8259]
| or Concise Binary Object Representation (CBOR) [RFC7049] can be
| used.
| Note 2: CPNP messages cannot be blindly mapped to RESTCONF
| messages with the target service being modelled as
| configuration data because such data is supposed to be
| manipulated by a RESTCONF client only. In such a model, the
| RESTCONF server cannot use a value other than the one set by
| the client (e.g., Section 9.2.3) or remove offers from its own
| initiative (e.g., Section 9.1.8). An alternate approach might
| be to map CPNP operations into RESTCONF actions (RPC).
| Assessing the feasibility of such approach is out of scope.
The CUSTOMER_ORDER_IDENTIFIER (Customer Order Identifier) is an identifier that is assigned by a client to identify an agreement. This identifier must be unique to the client.
customer_order_identifier（顧客順識別子）は、契約を識別するためにクライアントによって割り当てられている識別子です。この識別子はクライアントに固有のものでなければなりません。
Rules for assigning this identifier (including the structure and semantics) are specific to the client (Customer). The value of CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages.
この識別子を割り当てるための規則（構造とセマンティクスを含む）は、クライアント（顧客）に固有のものです。customer_order_identifierの値は、すべてのCPNPメッセージに含まれています。
The client (Customer) assigns an identifier to an order under negotiation before an agreement is reached. This identifier will be used to unambiguously identify the resulting agreement at the client side (Customer).
クライアント（顧客）は、合意に達する前に交渉の下で識別子を順番に割り当てます。この識別子は、クライアント側（顧客）で結果の合意を明確に識別するために使用されます。
The server handles the CUSTOMER_ORDER_IDENTIFIER as an opaque value.
サーバーはcustomer_order_identifierを不透明値として処理します。
The PROVIDER_ORDER_IDENTIFIER (Provider Order Identifier) is an identifier that is assigned by a server to identify an order. This identifier must be unique to the server.
provider_order_identifier（プロバイダ順識別子）は、注文を識別するためにサーバーによって割り当てられている識別子です。この識別子はサーバーに固有のものでなければなりません。
Rules for assigning this identifier (including the structure and semantics) are specific to the server (Provider). The PROVIDER_ORDER_IDENTIFIER is included in all CPNP messages except QUOTATION messages (because the state is only present at the client side).
この識別子を割り当てるための規則（構造とセマンティクスを含む）は、サーバー（プロバイダ）に固有のものです。Provider_Order_Identifierは、引用符を除くすべてのCPNPメッセージに含まれています（状態がクライアント側に存在するためのみ）。
The server (Provider) assigns an identifier to an order under negotiation before an agreement is reached. This identifier will be used to unambiguously identify the resulting agreement at the server side (Provider).
サーバー（プロバイダー）は、合意に達する前にネゴシエーションの下の注文に識別子を割り当てます。この識別子は、サーバー側（プロバイダ）で結果の契約を明確に識別するために使用されます。
The client handles the PROVIDER_ORDER_IDENTIFIER as an opaque value.
クライアントはProvider_Order_Identifierを不透明値として処理します。
This object conveys the Transaction-ID introduced in Section 8.4.
このオブジェクトは、8.4項で導入されたトランザクションIDを伝えます。
The sequence number is a number that is monotonically incremented in every new CPNP message pertaining to a given CPNP transaction. This number is used to avoid replay attacks.
シーケンス番号は、特定のCPNPトランザクションに関する新しいCPNPメッセージごとに単調に増加する数値です。この数はリプレイ攻撃を避けるために使用されます。
Refer to Section 11.3.
11.3項を参照してください。
The NONCE is a random value assigned by the CPNP server. Assigning a unique NONCE value for each order is recommended.
nonceは、CPNPサーバーによって割り当てられた乱数です。注文ごとに固有のNonce値を割り当てることをお勧めします。
It is mandatory to then include the NONCE in subsequent CPNP client operations on the associated order (including the resulting agreement) such as withdrawing the order or updating the order.
次に、注文を撤回するか、注文を更新するなど、関連する順序で（結果として得られた契約を含む）に、その後のCPNPクライアント操作でNonceを義務付けることが必須です。
If the NONCE validation checks fail, the server rejects the request with a FAIL message that includes the appropriate failure reason code.
Nonce検証チェックが失敗した場合、サーバーは適切な障害理由コードを含むFAILメッセージを使用して要求を拒否します。
This attribute indicates the time by when the CPNP client is expecting to receive a response from the CPNP server to a given PQO. If no offer is received by then, the CPNP client will consider the quotation order to be rejected.
この属性は、CPNPクライアントがCPNPサーバーから特定のPQOへの応答を受信することを期待している時間を示します。その後、オファーが受信されない場合、CPNPクライアントは拒否されるべき引用順序を考慮します。
The EXPECTED_RESPONSE_TIME follows the date format specified in [RFC3339].
expected_response_timeは[RFC3339]で指定された日付形式に従います。
This attribute indicates the time by when the CPNP server is expecting to make an offer to the CPNP client. If no offer is received by then, the CPNP client will consider the order rejected.
この属性は、CPNPサーバーがCPNPクライアントにオファーを実行することを期待しているときの時間を示します。その後、オファーが受信されない場合、CPNPクライアントは拒否された順序を考慮します。
The CPNP server may propose an expected offer time that does not match the expected response time indicated in the quotation order message. The CPNP client can accept or reject the proposed expected time by when the CPNP server will make an offer.
CPNPサーバーは、引用順序メッセージに示されている予想応答時間と一致しない予定されたオファー時間を提案することができます。CPNPクライアントは、CPNPサーバーがオファーを作成すると、提案された予想時間を受け入れるか拒否できます。
The CPNP server can always request extra time for its processing, but this may be accepted or rejected by the CPNP client.
CPNPサーバーは常にその処理に余分な時間を要求できますが、これはCPNPクライアントによって受け入れられるか拒否されます。
The EXPECTED_OFFER_TIME follows the date format specified in [RFC3339].
expected_offer_timeは[RFC3339]で指定された日付形式に従います。
This attribute indicates the time of validity of an offer made by the CPNP server. If the offer is not accepted before this time expires, the CPNP server will consider the CPNP client as having rejected the offer; the CPNP server will silently remove this order from its base.
この属性は、CPNPサーバーによって行われたオファーの有効期限を示します。この時間が経過する前にオファーが受け入れられない場合、CPNPサーバーはCPNPクライアントがオファーを拒否されたものとして考慮されます。CPNPサーバーはこの順序をその基本から静かに削除します。
The VALIDITY_OFFER_TIME follows date format specified in [RFC3339].
validity_offer_timeは、[RFC3339]で指定された日付形式に続きます。
This document defines a machinery to negotiate any aspect subject to negotiation. Service clauses that are under negotiation are conveyed using this attribute.
この文書は、ネゴシエーションの対象となるアスペクトを交渉するための機械を定義しています。交渉中のサービス句は、この属性を使用して伝達されます。
The structure of the connectivity provisioning clauses is provided in the following subsection.
接続性プロビジョニング条項の構造は、以下のサブセクションに記載されています。
The RBNF format of the CPD is shown in Figure 10.
CPDのRBNFフォーマットを図10に示す。
<CPD> ::= <Connectivity Provisioning Component> ...
<Connectivity Provisioning Component> ::=
<CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE> ::=
<Customer Nodes Map>
<SCOPE>
<QoS Guarantees>
<Availability>
<CAPACITY>
<Traffic Isolation>
<Conformance Traffic>
<Flow Identification>
<Overall Traffic Guarantees>
<Routing and Forwarding>
<Activation Means>
<Invocation Means>
<Notifications>
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALIZATION>
Figure 10: The RBNF format of the CPD
図10：CPDのRBNF形式
An Information Element (IE) is an optional object that can be included in a CPNP message.
情報要素（IE）は、CPNPメッセージに含めることができるオプションのオブジェクトです。
The client may include administrative information such as the following:
クライアントは、次のような管理情報を含めることができます。
* Name
* 名前
* Contact Information
* 連絡先
The format of this Information Element is as follows:
この情報要素のフォーマットは次のとおりです。
<Customer Description> ::= [<NAME>] [<Contact Information>]
<Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
The server may include administrative information in an offer such as the following:
サーバーは、次のようなオファーの管理情報を含めることができます。
* Name
* 名前
* AS Number [RFC6793]
* 番号として[RFC6793]
* Contact Information
* 連絡先
The format of this Information Element is as follows:
この情報要素のフォーマットは次のとおりです。
<Provider Description> ::= [<NAME>][<Contact Information>]
[<AS_NUMBER>]
The client may include some negotiation options such as the following:
クライアントは、次のようないくつかのネゴシエーションオプションを含めることができます。
Setup purpose: A client may request the setup of a service (e.g., connectivity) only for testing purposes during a limited period. The order can be extended to become permanent if the client was satisfied during the test period. This operation is achieved using the UPDATE method.
セットアップ目的：クライアントは、期間限定中にテスト目的のためにのみサービスの設定（例えば、接続性）を要求することができる。テスト期間中にクライアントが満たされた場合、順序は永続的になるように拡張できます。この操作は更新方法を用いて実現される。
Activation type: A client may request a permanent or scheduled activation type. If no activation type clause is included during the negotiation, this means that the order will be immediately activated right after the negotiation ends.
アクティベーションタイプ：クライアントは、恒久的またはスケジュールされたアクティベーションタイプを要求することがあります。ネゴシエーション中にアクティベーションタイプ句が含まれていない場合、これは、ネゴシエーションが終了した直後に順番が直ちに起動されることを意味します。
The format of this Information Element is as follows:
この情報要素のフォーマットは次のとおりです。
<Negotiation Options> ::= [<PURPOSE>]
This section defines the RBNF format of CPNP operation messages. The following operation codes are used:
このセクションでは、CPNP操作メッセージのRBNF形式を定義します。以下の操作コードが使用されます。
+======+===================+================+
| Code | Operation Message | Reference |
+======+===================+================+
| 1 | QUOTATION | Section 9.2.1 |
+------+-------------------+----------------+
| 2 | PROCESSING | Section 9.2.2 |
+------+-------------------+----------------+
| 3 | OFFER | Section 9.2.3 |
+------+-------------------+----------------+
| 4 | ACCEPT | Section 9.2.4 |
+------+-------------------+----------------+
| 5 | DECLINE | Section 9.2.5 |
+------+-------------------+----------------+
| 6 | ACK | Section 9.2.6 |
+------+-------------------+----------------+
| 7 | CANCEL | Section 9.2.7 |
+------+-------------------+----------------+
| 8 | WITHDRAW | Section 9.2.8 |
+------+-------------------+----------------+
| 9 | UPDATE | Section 9.2.9 |
+------+-------------------+----------------+
| 10 | FAIL | Section 9.2.10 |
+------+-------------------+----------------+
| 11 | ACTIVATE | Section 9.2.11 |
+------+-------------------+----------------+
Table 1: CPNP Operation Message Codes
表1：CPNP操作メッセージコード
These codes are used to unambiguously identify a CPNP operation; the operation code is conveyed in the METHOD_CODE attribute mentioned in the following subsections.
これらのコードは、CPNP操作を明確に識別するために使用されます。オペレーションコードは、次のサブセクションに記載されているMETHOD_CODE属性で伝達されます。
In the following, VERSION refers to the CPNP version number. This attribute must be set to 1.
次のとおり、バージョンはCPNPのバージョン番号を表します。この属性は1に設定する必要があります。
The format of the QUOTATION message is shown below:
引用メッセージの形式を以下に示します。
<QUOTATION Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
<REQUESTED_CPD>
[<INFORMATION_ELEMENT>...]
A QUOTATION message must include an order identifier that is generated by the client (CUSTOMER_ORDER_IDENTIFIER). Because several orders can be issued to several servers, the QUOTATION message must also include a Transaction-ID.
引用符メッセージには、クライアントによって生成された注文識別子（customer_order_identifier）を含める必要があります。複数のオーダーを複数のサーバーに発行することができますので、引用符メッセージにもトランザクションIDが含まれている必要があります。
The message may include an EXPECTED_RESPONSE_TIME, which indicates by when the client expects to receive an offer from the server. The QUOTATION message must also include a requested service description (that is, a Requested CPD for connectivity services).
メッセージには、expected_response_timeを含めることができます。これは、クライアントがサーバーからオファーを受信することを期待しているときに示すものです。引用符メッセージには、要求されたサービス記述（つまり、接続されたCPDのための要求されたCPD）も含まなければなりません。
The message may include ACTIVATION_TYPE to request a permanent or scheduled activation type (e.g., using the ACTIVATE method defined in Section 9.2.11). If no such clause is included, the default mode is to assume that the order will be active once the accepted activation means are successfully invoked (e.g., Section 3.11 of [RFC7297]).
メッセージには、恒久的またはスケジュールされたアクティベーションタイプ（例えば、セクション9.2.11で定義されている起動方法を使用して）を要求するためのActivation_Typeが含まれてもよい。そのような句が含まれていない場合、デフォルトのモードは、受け入れられた起動手段が正常に呼び出されたら、順序がアクティブになると仮定することです（例えば、[RFC7297]のセクション3.11）。
When the client sends the QUOTATION message to the server, the state of the order changes to "PQOSent" at the client side.
クライアントが引用メッセージをサーバーに送信すると、注文の状態がクライアント側の「PQosent」に変更されます。
The format of the PROCESSING message is shown below:
処理メッセージの形式を以下に示します。
<PROCESSING Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
[<EXPECTED_OFFER_TIME>]
[<PROCESSING_SUBCODE>]
Upon receipt of a QUOTATION message, the server proceeds with the parsing rules (see Section 10). If no error is encountered, the server generates a PROCESSING response to the client to indicate the PQO has been received and it is being processed. The server must generate an order identifier that identifies the order in its local order repository. The server must copy the content of the CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed in the QUOTATION message. The server may include an EXPECTED_OFFER_TIME by when it expects to make an offer to the client.
引用メッセージを受信すると、サーバーは解析ルールを処理します（セクション10を参照）。エラーが発生していない場合、サーバーはPQOが受信されて処理されていることを示すためにクライアントへの処理応答を生成します。サーバーは、そのローカルオーダーリポジトリ内の順序を識別するオーダー識別子を生成する必要があります。サーバーは、引用メッセージに伝達されているとおりのCustomer_Order_IdentifierとTransaction_IDフィールドの内容をコピーする必要があります。サーバーは、それがオファーをクライアントに提供することを期待することによってexpected_offer_timeを含み得る。
Upon receipt of a PROCESSING message, the client verifies whether it has issued a PQO that contains the CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID to that server. If no such PQO is found, the PROCESSING message must be silently ignored. If a PQO is found, the client may check whether it accepts the EXPECTED_OFFER_TIME, and then it changes to state of the order to "ServerProcessing".
処理メッセージを受信すると、クライアントは、customer_order_identifierおよびtransaction_idをそのサーバに含むPQOを発行したかどうかを検証します。そのようなPQOが見つからない場合、処理メッセージは黙って無視されなければならない。PQOが見つかった場合、クライアントはそれがexpected_offer_timeを受け入れるかどうかを確認し、次に「サーバプロセス」の順序の状態に変わります。
If the server requires more time to process the quotation order, it may send a PROCESSING message that includes a new EXPECTED_OFFER_TIME. The client can answer with an ACK message if more time is granted (Figure 11) or with a FAIL message if the time extension request is rejected (Figure 12).
サーバーが引用順序を処理するためのより多くの時間を必要とする場合、それは新しいexpected_offer_timeを含む処理メッセージを送信することがあります。より多くの時間が付与された場合（図11）または時間拡張要求が拒否された場合にフェイルメッセージを使用して、クライアントはACKメッセージで回答できます（図12）。
The server may provide more details in the PROCESSING_SUBCODE attribute about the reason for requesting more time to process the request. The following codes are defined:
サーバーは、要求を処理するためのより多くの時間を要求する理由について、processing_subcode属性の詳細を提供することがあります。以下のコードが定義されています。
+=========+============================+
| Subcode | Description |
+=========+============================+
| 1 | Upgrade of local resources |
+---------+----------------------------+
| 2 | Request external resources |
+---------+----------------------------+
Table 2: PROCESSING_SUBCODE Codes
表2：Processing_SubCodeコード
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|============ACK(TimeGranted)========>|
...
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT(Accepted CPD)=======>|
|<=========ACK(Accepted CPD)==========|
| |
Figure 11: Request More Negotiation Time: Granted
図11：より多くのネゴシエーション時間を要求します
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|=====FAIL(More Time Rejected)=======>|
Figure 12: Request More Negotiation Time: Rejected
図12：より多くのネゴシエーション時間を要求する：拒否されました
The format of the OFFER message is shown below:
オファーメッセージのフォーマットを以下に示します。
<OFFER Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
<VALIDITY_OFFER_TIME>
<OFFERED_CPD>
[<INFORMATION_ELEMENT>...]
The server answers a QUOTATION request received from the client with an OFFER message. The offer will be considered to be rejected by the client if no confirmation (i.e., an ACCEPT message sent by the client) is received by the server before the expiration of the validity time.
サーバーは、オファーメッセージを使用してクライアントから受信した引用要求に応答します。確認がない場合（すなわち、クライアントによって送信されたACCEPTメッセージ）が有効期間の満了前にサーバによって受信される場合、オファーはクライアントによって拒否されると見なされます。
The server may include ACTIVATION_TYPE to indicate whether the offer is about a permanent or scheduled activation type. The message may include ACTIVATION_SCHEDULE to indicate when the order is to be activated. If no such clause is included, the default mode is to assume that the order will be active once the accepted activation means are successfully invoked (e.g., Section 3.11 of [RFC7297] or Section 9.2.11).
サーバは、オファーが恒久的またはスケジュールされたアクティブ化タイプに関するものであるかどうかを示すためのactivation_typeを含み得る。メッセージには、順序がアクティブ化されるべきかを示すためのActivation_Scheduleを含めることができます。そのような句が含まれていない場合、デフォルトモードは、受け入れられた起動手段が正常に呼び出された後（例えば、[RFC7297]またはセクション9.2.11のセクション3.11）になると、順序がアクティブになると仮定することです。
The format of the ACCEPT message is shown below:
Acceptメッセージのフォーマットを以下に示します。
<ACCEPT Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
<ACCEPTED_CPD>
[<INFORMATION_ELEMENT>...]
This message is used by a client to confirm the acceptance of an offer received from a server. The fields of this message must be copied from the received OFFER message. This message should not be sent after the validity time of the offer expires, as indicated by the server (Section 9.2.3).
このメッセージは、サーバーから受信したオファーの受け入れを確認するためにクライアントによって使用されます。このメッセージのフィールドは受信したオファーメッセージからコピーする必要があります。このメッセージは、サーバーによって示されるように、オファーの有効期限が切れた後に送信されないでください（セクション9.2.3）。
The format of the DECLINE message is shown below:
辞退メッセージの形式を以下に示します。
<DECLINE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
[<REASON>...]
The client may issue a DECLINE message to reject an offer. CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, TRANSACTION_ID, and NONCE are used by the server as keys to find the corresponding order. If an order matches, the server changes the state of this order to "Cancelled" and then returns an ACK with a copy of the Requested CPD to the requesting client.
クライアントはオファーを拒否するために辞退メッセージを発行することができます。customer_order_identifier、provider_order_identifier、transaction_id、およびnonceは、対応する順序を見つけるためのキーとしてサーバーによって使用されます。注文が一致した場合、サーバーはこの順序の状態を「キャンセル」させてから、要求されたCPDのコピーを要求しているクライアントにコピーしてACKを返します。
A DECLINE message may include an Information Element to indicate the reason for declining an offer. The following codes are defined:
辞退メッセージは、オファーを低下させる理由を示すための情報要素を含み得る。以下のコードが定義されています。
+======+====================================================+
| Code | Description |
+======+====================================================+
| 1 | Unacceptable gap between the request and the offer |
+------+----------------------------------------------------+
| 2 | Conflict with another offer from another server |
+------+----------------------------------------------------+
| 3 | Activation type mismatch |
+------+----------------------------------------------------+
Table 3: DECLINE Message Codes
表3：メッセージコードを拒否します
If no order is found, the server returns a FAIL message to the requesting client. In order to prevent DDoS (Distributed Denial of Service) attacks, the server should restrict the number of FAIL messages sent to a requesting client. It may also rate-limit FAIL messages.
注文が見つからない場合、サーバーは失敗メッセージを要求しているクライアントに返します。DDOS（Distributed Denibal Service）を防ぐために、サーバーは要求されているクライアントに送信されたFailメッセージの数を制限する必要があります。FAILメッセージを制限することもできます。
A flow example is shown in Figure 13.
フローの例を図13に示す。
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<============PROCESSING==============|
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|===============DECLINE==============>|
|<================ACK=================|
| |
Figure 13: DECLINE Flow Example
図13：辞退フローの例
The format of the ACK message is shown below:
ACKメッセージの形式を以下に示します。
<ACK Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
[<CPD>]
[<INFORMATION_ELEMENT>...]
This message is issued by the server to close a CPNP transaction or by a client to grant more negotiation time to the server.
このメッセージは、CPNPトランザクションを閉じるか、またはクライアントがサーバーにより多くのネゴシエーション時間を付与するためにサーバーによって発行されます。
This message is sent by the server as a response to an ACCEPT, WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message must include the copy of the service description (i.e., CPD for connectivity services) as stored by the server. In particular, the following considerations are taken into account for connectivity provisioning services:
このメッセージは、承諾、撤回、辞退、またはキャンセルメッセージに対する応答としてサーバーによって送信されます。この場合、ACKメッセージには、サーバによって格納されているサービス記述のコピー（すなわち、接続サービス用のCPD）を含める必要があります。特に、接続性プロビジョニングサービスについては、以下の考慮事項が考慮されています。
* A copy of the Requested/Offered CPD is included by the server if it successfully handled a CANCEL message.
* 要求された/提供されたCPDのコピーは、キャンセルメッセージを正常に処理した場合、サーバーによって含まれます。
* A copy of the Updated CPD is included by the server if it successfully handled an UPDATE message.
* 更新プログラムメッセージを正常に処理した場合、更新されたCPDのコピーがサーバーによって含まれます。
* A copy of the Offered CPD is included by the server if it successfully handled an ACCEPT message in the context of a QUOTATION transaction (refer to "Accepted CPD" in Section 8.7).
* 提供されたCPDのコピーは、見積トランザクションのコンテキストでAcceptメッセージを正常に処理した場合にサーバーによって含まれています（8.7節の「承認されたCPD」を参照）。
* An Empty CPD is included by the server if it successfully handled a DECLINE or WITHDRAW message.
* 辞退メッセージまたは撤回メッセージを正常に処理した場合、空のCPDがサーバーによって含まれます。
A client may issue an ACK message as a response to a time extension request (conveyed in PROCESSING) received from the server. In such case, the ACK message must include an EXPECTED_RESPONSE_TIME that is likely to be set to the time extension requested by the server.
クライアントは、サーバから受信された時間拡張要求（処理されている処理中）に対する応答としてACKメッセージを発行することができる。そのような場合、ACKメッセージには、サーバーによって要求された時間拡張に設定される可能性が高いexpected_response_timeが含まれている必要があります。
The format of the CANCEL message is shown below:
キャンセルメッセージのフォーマットを以下に示します。
<CANCEL Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
[<CPD>]
The client can issue a CANCEL message at any stage during the CPNP negotiation process before an agreement is reached. The CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID are used by the server as keys to find the corresponding order. If a quotation order matches, the server changes the state of this quotation order to "Cancelled" and then returns an ACK with a copy of the Requested CPD to the requesting client.
クライアントは、合意に達する前にCPNPネゴシエーションプロセス中にどの段階でもキャンセルメッセージを発行できます。customer_order_identifierとtransaction_idは、対応する順序を見つけるためのキーとしてサーバーによって使用されます。引用順が一致すると、サーバはこの引用順の状態を「キャンセル」に変更し、次に要求されたCPDのコピーを要求側クライアントにコピーしてACKを返します。
If no quotation order is found, the server returns a FAIL message to the requesting client.
引用順序が見つからない場合、サーバーは失敗メッセージを要求側クライアントに返します。
The format of the WITHDRAW message is shown below:
撤回メッセージのフォーマットを以下に示します。
<WITHDRAW Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
[<ACCEPTED_CPD>]
[<INFORMATION_ELEMENT>...]
This message is used to withdraw an offer already accepted by the Customer. Figure 14 shows a typical usage of this message.
このメッセージは、顧客がすでに受け入れられているオファーを撤回するために使用されます。図14はこのメッセージの典型的な使用法を示しています。
+------+ +------+
|Client| |Server|
+------+ +------+
|============WITHDRAW(CPD)===========>|
|<============PROCESSING==============|
|<===========ACK(Empty CPD)===========|
| |
Figure 14: WITHDRAW Flow Example
図14：撤回フローの例
The WITHDRAW message must include the same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the order.
撤回メッセージには、順序を作成するときに使用されるときに使用されるものとして、同じcustomer_order_identifier、provider_order_identifier、およびnonceを含める必要があります。
Upon receipt of a WITHDRAW message, the server checks whether an order matching the request is found. If an order is found, the state of the order is changed to "Cancelled", and an ACK message including an Empty CPD is returned to the requesting client. If no order is found, the server returns a FAIL message to the requesting client.
撤回メッセージを受信すると、サーバーは要求に一致する順序が見つかったかどうかを確認します。注文が見つかった場合は、注文の状態を「キャンセル」に変更し、空のCPDを含むACKメッセージが要求側クライアントに返されます。注文が見つからない場合、サーバーは失敗メッセージを要求しているクライアントに返します。
The format of the UPDATE message is shown below:
アップデートメッセージのフォーマットを以下に示します。
<UPDATE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
<EXPECTED_RESPONSE_TIME>
<REQUESTED_CPD>
[<INFORMATION_ELEMENT>...]
This message is sent by the CPNP client to update an existing service agreement (e.g., Accepted CPD). The UPDATE message must include the same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the order. The CPNP client includes a new service description (e.g., Updated CPD) that integrates the requested modifications. A new Transaction_ID must be assigned by the client.
このメッセージは、CPNPクライアントによって送信されて既存のサービス契約（例えば、承認されたCPD）を更新します。更新メッセージには、順序を作成するときに使用されるときに使用されるものと同じcustomer_order_identifier、provider_order_identifier、およびnonceを含める必要があります。CPNPクライアントは、要求された修正を統合する新しいサービス記述（例えば、更新されたCPD）を含む。新しいtransaction_idをクライアントによって割り当てる必要があります。
Upon receipt of an UPDATE message, the server checks whether an order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE.
更新メッセージを受信すると、サーバは、状態「完了」を有する順序が、customer_order_identifier、provider_order_identifier、およびnonceと一致するかどうかをチェックする。
* If no order is found, the CPNP server generates a FAIL error with the appropriate error code (Section 9.2.10).
* 注文が見つからない場合、CPNPサーバーは適切なエラーコードを持つ失敗エラーを生成します（9.2.10項）。
* If an order is found, the server checks whether it can honor the request:
* 注文が見つかった場合、サーバーはリクエストを尊重できるかどうかを確認します。
- A FAIL message is sent to the client if the server cannot honor the request. The client may initiate a new PQO negotiation cycle (that is, send a new UPDATE message).
- サーバーが要求を尊重できない場合、失敗メッセージがクライアントに送信されます。クライアントは、新しいPQOネゴシエーションサイクルを開始することができます（つまり、新しいアップデートメッセージを送信します）。
- An OFFER message including the updated clauses (e.g., Updated CPD) is sent to the client. For example, the server maintains an order for provisioning a VPN service that connects sites A, B, and C. If the client sends an UPDATE message to remove site C, only sites A and B will be included in the OFFER sent by the server to the requesting client.
- 更新された句（例えば更新されたCPD）を含むオファーメッセージがクライアントに送信される。たとえば、サーバーはサイトA、B、およびCを接続するVPNサービスをプロビジョニングするための注文を維持します。クライアントがサイトCを削除するための更新メッセージを送信する場合、サイトAとBのみがサーバーによって送信されたオファーに含まれます。要求しているクライアントに。
Note that the cycle that is triggered by an UPDATE message is also considered to be a negotiation cycle.
更新メッセージによってトリガされるサイクルもネゴシエーションサイクルと見なされます。
A flow chart that illustrates the use of UPDATE operation is shown in Figure 15.
更新動作の使用を説明するフローチャートを図15に示す。
+------+ +------+
|Client| |Server|
+------+ +------+
|=========UPDATE(Requested CPD)======>|
|<============PROCESSING==============|
|<=========OFFER(Updated CPD)=========|
|=============PROCESSING=============>|
|==========ACCEPT(Updated CPD)=======>|
|<==========ACK(Updated CPD)==========|
| |
Figure 15: UPDATE Flow Example
図15：フローの更新例
The format of the FAIL message is shown below:
FAILメッセージのフォーマットを以下に示します。
<FAIL Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<STATUS_CODE>
This message is sent in the following cases:
このメッセージは次の場合に送信されます。
* The server cannot honor an order received from the client (i.e., received in a QUOTATION or UPDATE request).
* サーバーはクライアントから受信した注文を尊重することはできません（すなわち、見積または更新要求で受信されます）。
* The server encounters an error when processing a CPNP request received from the client.
* クライアントから受信したCPNP要求を処理するときにサーバーはエラーを検出します。
* The client cannot grant more time to the server. This is a response to a time extension request carried in a PROCESSING message.
* クライアントはサーバーにもっと時間を付与できません。これは、処理メッセージで実行されている時間拡張要求に対する応答です。
The status code indicates the error code. The following codes are supported:
ステータスコードはエラーコードを示します。次のコードがサポートされています。
+========+==================+=====================================+
| Status | Error Code | Description |
| Code | | |
+========+==================+=====================================+
| 1 | Message | The message cannot be validated |
| | Validation Error | (see Section 10). |
+--------+------------------+-------------------------------------+
| 2 | Authentication | The request cannot be handled |
| | Required | because authentication is required. |
+--------+------------------+-------------------------------------+
| 3 | Authorization | The request cannot be handled |
| | Failed | because authorization failed. |
+--------+------------------+-------------------------------------+
| 4 | Administratively | The request cannot be handled |
| | prohibited | because of administrative policies. |
+--------+------------------+-------------------------------------+
| 5 | Out of Resources | The request cannot be honored |
| | | because resources (e.g., capacity) |
| | | are insufficient. |
+--------+------------------+-------------------------------------+
| 6 | Network Presence | The request cannot be honored |
| | Error | because there is no network |
| | | presence. |
+--------+------------------+-------------------------------------+
| 7 | More Time | The request to extend the time for |
| | Rejected | negotiation is rejected by the |
| | | client. |
+--------+------------------+-------------------------------------+
| 8 | Unsupported | The request cannot be handled |
| | Activation Type | because the requested activation |
| | | type is not supported. |
+--------+------------------+-------------------------------------+
Table 4: FAIL Message Error Codes
表4：失敗メッセージエラーコード
The format of the ACTIVATE message is shown below:
アクティブ化メッセージのフォーマットを以下に示します。
<ACTIVATE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<NONCE>
<ACTIVATION_SCHEDULE>
[<INFORMATION_ELEMENT>...]
This message is sent by the CPNP client to request the activation of an existing service agreement. The message must include the same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the order. The CPNP client may include a schedule target for activating this order. A new Transaction_ID must be assigned by the client.
このメッセージはCPNPクライアントによって送信され、既存のサービス契約のアクティブ化を要求します。メッセージには、順序を作成するときに使用されるものとして、同じCUSTOMER_ORDER_IDENDIFIER、PROVIDER_ORDER_IDENTIFIER、およびNONCEを含める必要があります。CPNPクライアントは、この順序を起動するためのスケジュールターゲットを含み得る。新しいtransaction_idをクライアントによって割り当てる必要があります。
Upon receipt of an ACTIVATE message, the server checks whether an order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE.
アクティブ化メッセージを受信すると、サーバは、状態「完了」を有する順序が、customer_order_identifier、provider_order_identifier、およびnonceと一致するかどうかをチェックする。
* If no completed order is found, the CPNP server generates a FAIL error with the appropriate error code (Section 9.2.10).
* 完了した注文が見つからない場合、CPNPサーバーは適切なエラーコードを持つ失敗エラーを生成します（セクション9.2.10）。
* If an order is found, the server checks whether it can honor the request:
* 注文が見つかった場合、サーバーはリクエストを尊重できるかどうかを確認します。
- A FAIL message is sent to the client if the server cannot honor the request (e.g., out of resources or explicit activation wasn't negotiated with this client).
- サーバーがリクエストを尊重できない場合（例えば、リソースの不適切または明示的なアクティベーションがこのクライアントとネゴシエートされていませんでした）場合、失敗メッセージがクライアントに送信されます。
- An ACK is sent to the client to confirm that the immediate activation (or deactivation) of the order or its successful scheduling if a non-null ACTIVATION_SCHEDULE was included in the request. Note that setting ACTIVATION_SCHEDULE to 0 in an ACTIVATE request has a special meaning: it is used to request a deactivation of an accepted order.
- ACKはクライアントに送信され、既知のActivation_Scheduleがリクエストに含まれていた場合の順序の即時有効化（または非アクティブ化）が順序またはそのスケジューリングが成功することを確認します。アクティブ化要求でActivation_Scheduleを0に設定すると、特別な意味があります。承認された順序の無効化を要求するために使用されます。
Figure 16 illustrates the use of the ACTIVATE operation.
図16は、起動動作の使用を示す。
+------+ +------+
|Client| |Server|
+------+ +------+
|================ACTIVATE()==========>|
|<==============ACK()=================|
| |
Figure 16: ACTIVATE Flow Example
図16：フローの例を有効にします
Both the client and the server proceed with CPNP message validation. The following tables summarize the validation checks to be followed.
クライアントとサーバーの両方がCPNPメッセージ検証を続行します。次の表は、後に続く検証チェックを要約しています。
+==============+==================================================+
| Operation | Validation Checks |
+==============+==================================================+
| PROCESSING | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier} must |
| | match an existing PQO with a state set to |
| | "PQOSent". The sequence number carried in the |
| | packet must be larger than the sequence number |
| | maintained by the client. |
+--------------+--------------------------------------------------+
| OFFER | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier} must |
| | match an existing order with state set to |
| | "PQOSent", or {Source IP address, source port |
| | number, destination IP address, destination port |
| | number, Transaction-ID, Customer Order |
| | Identifier, Provider Order Identifier} must |
| | match an existing order with a state set to |
| | "ServerProcessing". The sequence number carried |
| | in the packet must be larger than the sequence |
| | number maintained by the client. |
+--------------+--------------------------------------------------+
| ACK | {Source IP address, source port number, |
| (QUOTATION | destination IP address, destination port number, |
| Transaction) | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier, Offered Connectivity |
| | Provisioning Document} must match an order with |
| | a state set to "AcceptSent". The sequence |
| | number carried in the packet must be larger than |
| | the sequence number maintained by the client. |
+--------------+--------------------------------------------------+
| ACK (UPDATE | {Source IP address, source port number, |
| Transaction) | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier, Updated Connectivity |
| | Provisioning Document} must match an order with |
| | a state set to "AcceptSent". The sequence |
| | number carried in the packet must be larger than |
| | the sequence number maintained by the client. |
+--------------+--------------------------------------------------+
| ACK | {Source IP address, source port number, |
| (WITHDRAW | destination IP address, destination port number, |
| Transaction) | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier, Empty Connectivity |
| | Provisioning Document} must match an order with |
| | a state set to "Cancelled". The sequence number |
| | carried in the packet must be larger than the |
| | sequence number maintained by the client. |
+--------------+--------------------------------------------------+
Table 5: Client Side Validation Checks
表5：クライアント側の検証チェック
+============+==================================================+
| Method | Validation Checks |
+============+==================================================+
| QUOTATION | The source IP address passes existing access |
| | filters (if any). The sequence number carried |
| | in the packet must not be lower than the |
| | sequence number maintained by the server. |
+------------+--------------------------------------------------+
| PROCESSING | The sequence number carried in the packet must |
| | be greater than the sequence number maintained |
| | by the server. |
+------------+--------------------------------------------------+
| CANCEL | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier} must |
| | match an order with state set to "PQOReceived" |
| | or "OfferProposed" or "ProcessingReceived" or |
| | "AcceptReceived". The sequence number carried |
| | in the packet must be greater than the sequence |
| | number maintained by the server. |
+------------+--------------------------------------------------+
| ACCEPT | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier, Nonce, Offered |
| | Connectivity Provisioning Document} must match |
| | an order with state set to "OfferProposed" or |
| | "ProcessingReceived". The sequence number |
| | carried in the packet must be greater than the |
| | sequence number maintained by the server. |
+------------+--------------------------------------------------+
| FAIL | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier} must match an order |
| | with state set to "AwaitingProcessing" and for |
| | which a request to grant more time to process an |
| | offer was requested. The sequence number |
| | carried in the packet must be greater than the |
| | sequence number maintained by the server. |
+------------+--------------------------------------------------+
| DECLINE | {Source IP address, source port number, |
| | destination IP address, destination port number, |
| | Transaction-ID, Customer Order Identifier, |
| | Provider Order Identifier, Nonce} must match an |
| | order with state set to "OfferProposed" or |
| | "ProcessingReceived". The sequence number |
| | carried in the packet must be greater than the |
| | sequence number maintained by the server. |
+------------+--------------------------------------------------+
| UPDATE | The source IP address passes existing access |
| | filters (if any), and {Customer Order |
| | Identifier, Provider Order Identifier, Nonce} |
| | must match an existing order with state |
| | "Completed". |
+------------+--------------------------------------------------+
| WITHDRAW | The source IP address passes existing access |
| | filters (if any), and {Customer Order |
| | Identifier, Provider Order Identifier, Nonce} |
| | must match an existing order with state |
| | "Completed". |
+------------+--------------------------------------------------+
| ACTIVATE | The source IP address passes existing access |
| | filters (if any), and {Customer Order |
| | Identifier, Provider Order Identifier, Nonce} |
| | must match an existing order with a state of |
| | "Completed" and its activation procedure set to |
| | explicit. |
+------------+--------------------------------------------------+
Table 6: Server Side Validation Checks
表6：サーバー側検証チェック
Both the CPNP client and server proceed with message validation checks as specified in Section 10.
CPNPクライアントとサーバーの両方が、セクション10で指定されているようにメッセージ検証チェックを続行します。
To place a PQO, the client first initiates a local quotation order object identified by a unique identifier assigned by the client (Client Order Identifier). The state of the quotation order is set to "Created". The client then generates a QUOTATION request that includes the assigned identifier, possibly an expected response time, a Transaction-ID, and a requested service (e.g., Requested CPD). The client may include additional Information Elements such as Customer Description or Negotiation Options.
PQOを配置するために、クライアントは最初にクライアントによって割り当てられた一意の識別子によって識別されるローカル見積順序オブジェクトを開始します（クライアント順識別子）。引用順の状態は「作成」に設定されています。その後、クライアントは、割り当てられた識別子、場合によっては予想される応答時間、トランザクションID、および要求されたサービス（例えば、要求されたCPD）を含む引用要求を生成する。クライアントは、顧客の説明またはネゴシエーションオプションなどの追加情報要素を含み得る。
The client may be configured to not enforce negotiation checks on EXPECTED_OFFER_TIME; if so, the client should either not include the EXPECTED_RESPONSE_TIME attribute in the PQO or it should set the attribute to infinite.
クライアントは、expected_offer_timeでネゴシエーションチェックを強制しないように構成されている可能性があります。もしそうであれば、クライアントはPQOにexpected_response_time属性を含まないか、属性を無限に設定する必要があります。
Once the request is sent to the server, the state of the request is set to "PQOSent", and if a response time is included in the quotation order, a timer is set to the expiration time as included in the QUOTATION request. The client also maintains a copy of the CPNP session entry details used to generate the QUOTATION request. The CPNP client must listen on the same port number that it used to send the QUOTATION request.
要求がサーバに送信されると、要求の状態が「PQosent」に設定され、応答時間が引用順に含まれている場合、引用要求に含まれるように、期限切れ時間にタイマーが設定される。クライアントは、引用要求の生成に使用されるCPNPセッションエントリの詳細のコピーも維持します。CPNPクライアントは、引用要求を送信するために使用されたのと同じポート番号で待機する必要があります。
If no answer is received from the server before the retransmission timer expires (i.e., RETRANS_TIMER, Section 8.5), the client retransmits the message until maximum retry is reached (e.g., three times). The same sequence number is used for retransmitted packets.
再送タイマーが期限切れになる前にサーバから答えが受信されない場合（すなわちRETRANS_TIMER、セクション8.5）、クライアントは最大のリトライに達するまでメッセージを再送信する（例えば、3回）。再送されたパケットには同じシーケンス番号が使用されます。
If a FAIL message is received, the client may decide to issue another (corrected) request towards the same server, cancel the local order, or contact another server. The behavior of the client depends on the error code returned by the server in the FAIL message.
フェイルメッセージが受信された場合、クライアントは同じサーバーに向かって別の（修正された）要求を発行し、ローカル注文をキャンセルするか、別のサーバーに連絡することを決定することができます。クライアントの動作は、フェールメッセージ内のサーバーによって返されたエラーコードによって異なります。
If a PROCESSING message matching the CPNP session entry (Section 8.3) is received, the client updates the CPNP session entry with the PROVIDER_ORDER_IDENTIFIER information. If the client does not accept the expected offer time that may have been indicated in the PROCESSING message, the client may decide to cancel the quotation order. If the client accepts the EXPECTED_OFFER_TIME, it changes the state of the order to "ServerProcessing" and sets a timer to the value of EXPECTED_OFFER_TIME. If no offer is made before the timer expires, the client changes the state of the order to "Cancelled".
CPNPセッションエントリ（セクション8.3）に一致する処理メッセージが受信された場合、クライアントはProvider_Order_Identifier情報を使用してCPNPセッションエントリを更新します。クライアントが処理メッセージに示されている可能性がある予想されるオファー時間を受け入れない場合、クライアントは引用順序をキャンセルすることを決定することができます。クライアントがexpected_offer_timeを受け入れると、注文の状態を "ServerProcessing"に変更し、タイマーをpicture_offer_timeの値に設定します。タイマーが期限切れになる前にオファーがなされていない場合、クライアントは注文の状態を「キャンセル」に変更します。
As a response to a time extension request (conveyed in a PROCESSING message that included a new EXPECTED_OFFER_TIME), the client may either grant this extension by issuing an ACK message or reject the time extension by issuing a FAIL message with a status code set to "More Time Rejected".
時間拡張要求（新しいPESSIGN_OFFER_TIMEを含む処理メッセージで伝送される）に対する応答として、クライアントはACKメッセージを発行することによってこの拡張機能を付与するか、ステータスコードを設定したFAILメッセージを発行することによって時間拡張を拒否することができる。もっと時間が拒否されました」。
If an OFFER message matching the CPNP session entry is received, the client checks if a PROCESSING message having the same PROVIDER_ORDER_IDENTIFIER has been received from the server. If a PROCESSING message was already received for the same order, but the PROVIDER_ORDER_IDENTIFIER does not match the identifier included in the OFFER message, the client silently ignores the message. If a PROCESSING message with the same PROVIDER_ORDER_IDENTIFIER was already received and matches the CPNP transaction identifier, the client changes the state of the order to "OfferReceived" and sets a timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER message.
CPNPセッションエントリと一致するオファーメッセージが受信された場合、クライアントは、同じProvider_Order_Identifierを持つ処理メッセージがサーバーから受信されたかどうかを確認します。処理メッセージが既に同じ順序で受信されたが、Provider_Order_Identifierがオファーメッセージに含まれている識別子と一致しない場合、クライアントはメッセージを無視します。同じprovider_order_identifierを使用した処理メッセージがすでに受信されてCPNPトランザクション識別子と一致している場合、クライアントは注文の状態を「OfferReceived」に変更し、オファーメッセージに示されているvalidity_offer_timeの値にタイマーを設定します。
If an offer is received from the server (i.e., as documented in an OFFER message), the client may accept or reject the offer. The client accepts the offer by generating an ACCEPT message that confirms that the client agrees to subscribe to the offer documented in the OFFER message; the state of the order is passed to "AcceptSent". The transaction is terminated if an ACK message is received from the server. If no ACK is received from the server, the client proceeds with the retransmission of the ACCEPT message until the maximum retry is reached (Section 11.4).
オファーがサーバーから（すなわちオファーメッセージに記載されているように）受信された場合、クライアントはオファーを受け入れるか拒否することができます。クライアントは、クライアントがオファーメッセージに記載されているオファーを購読することを同意することを確認するAcceptメッセージを生成することによってオファーを受け入れます。注文の状態は「承認者」に渡されます。ACKメッセージがサーバーから受信された場合、トランザクションは終了します。サーバーからACKが受信されない場合、クライアントは最大リトライに達するまでACCEPTメッセージの再送信を進めます（セクション11.4）。
The client may also decide to reject the offer by sending a DECLINE message. The state of the order is set by the client to "Cancelled". If an offer is not acceptable to the client, the client may decide to contact a new server or submit another order to the same server. Guidelines to issue an updated order or terminate the negotiation are specific to the client.
クライアントは、拒否メッセージを送信することによってオファーを拒否することを決定することもできます。注文の状態は、クライアントによって「キャンセル」することによって設定されます。オファーがクライアントに受け入れられない場合、クライアントは新しいサーバーに連絡するか、別の注文を同じサーバーに送信することを決定することができます。更新された順序を発行するか、ネゴシエーションを終了するためのガイドラインはクライアントに固有のものです。
An order can be activated (or deactivated) using the ACTIVATE message or other accepted activation means (Section 3.11 of [RFC7297]).
アクティブ化メッセージまたはその他の受け入れられたアクティブ化手段を使用して、注文を起動（または無効化）できます（[RFC7297]のセクション3.11）。
A client may withdraw a completed order. This is achieved by issuing a WITHDRAW message. This message must include the Customer Order Identifier, Provider Order Identifier, and Nonce returned during the order negotiation cycle, as specified in Section 11.1.1.
クライアントは完成した注文を引き出す可能性があります。これは撤回メッセージを発行することによって達成されます。このメッセージには、セクション11.1.1で指定されているように、注文ネゴシエーションサイクル中に顧客注文の識別子、プロバイダーの注文識別子、およびNonceが含まれている必要があります。
If no ACK is received from the server, the client proceeds with the retransmission of the message. If no ACK is received after the maximum retry is exhausted, the client should log the information and must send an alarm to the administrator. If there is no specific instruction from the administrator, the client should schedule another Withdrawal cycle. The client must not retry this Withdrawal cycle more frequently than every 300 seconds and must not retry more frequently than every 60 seconds.
ACKがサーバーから受信されない場合、クライアントはメッセージの再送信を進めます。最大リトライが使い果たされた後にACKが受信されない場合、クライアントは情報を記録し、管理者にアラームを送信する必要があります。管理者から特定の命令がない場合、クライアントは別の撤回サイクルをスケジュールする必要があります。クライアントは300秒ごとより頻繁にこの撤退サイクルを再試行してはならず、60秒ごとより頻繁に再試行してはいけません。
A client may update a completed order. This is achieved by issuing an UPDATE message. This message must include the Customer Order Identifier, Provider Order Identifier, and Nonce returned during the order negotiation cycle specified in Section 11.1.1. The client must include in the UPDATE message an Updated CPD with the requested changes.
クライアントは完成した注文を更新することができます。これは更新メッセージを発行することによって達成されます。このメッセージには、セクション11.1.1で指定された注文ネゴシエーションサイクル中に、顧客注文の識別子、プロバイダーの注文識別子、およびNonceが含まれている必要があります。クライアントは、更新されたCPDを更新メッセージに含める必要があります。
The subsequent message exchange is similar to what is documented in Section 11.1.1.
後続のメッセージ交換は、11.1.1項で文書化されているものと似ています。
Upon receipt of a QUOTATION message from a client, the server sets a CPNP session, stores the Transaction-ID, and generates a Provider Order Identifier. Once preliminary validation checks are completed (Section 10), the server may return a PROCESSING message to inform the client that the quotation order is received and it is under processing; the server may include an expected offer time to notify the client by when an offer will be proposed. An order with state "AwaitingProcessing" is created by the server. The server runs its decision-making process to decide which offer it can make to honor the received order. The offer should be made before the expected offer time expires.
クライアントから引用メッセージを受信すると、サーバはCPNPセッションを設定し、トランザクションIDを格納し、プロバイダ注文識別子を生成する。予備検証チェックが完了すると（セクション10）、サーバは処理メッセージを返し、クライアントに引用順が受信され、処理中の通知されてもよい。サーバは、オファーが提案されたときにクライアントに通知するための予想されるオファー時間を含み得る。ステート「AWAITINGプロセス」を持つ順序は、サーバーによって作成されます。サーバーはその意思決定プロセスを実行して、受信した注文を尊重することができるオファーを決定するために決定します。オファーは予想されるオファー時間が経過する前に行われるべきです。
If the server cannot make an offer, it sends backs a FAIL message with the appropriate error code (Section 9.2.10).
サーバーがオファーを作成できない場合は、適切なエラーコードを使用してFAILメッセージを送ります（セクション9.2.10）。
If the server requires more negotiation time, it must send a PROCESSING message with a new EXPECTED_OFFER_TIME. The client may grant this extension by issuing an ACK message or reject the time extension by issuing a FAIL message with the status code set to "More Time Rejected". If the client doesn't grant more time, the server must answer before the initial expected offer time; otherwise, the client will decline the quotation order.
サーバーがより多くのネゴシエーション時間を必要とする場合は、新しいPESSION_OFFER_TIMEを使用して処理メッセージを送信する必要があります。クライアントは、ACKメッセージを発行することによってこの拡張機能を付与したり、ステータスコードを「より拒否された時間」に設定されている状態」に設定されたFAILメッセージを発行したりすることで、時間拡張を拒否することができます。クライアントがより多くの時間を付与しない場合、サーバーは最初の予想されるオファー時間の前に答えなければなりません。それ以外の場合、クライアントは引用順序を拒否します。
If the server can honor the request, or if it can make an offer that meets only some of the requirements, it creates an OFFER message. The server must indicate the Transaction-ID, the Customer Order Identifier as indicated in the QUOTATION message, and the Provider Order Identifier generated for this order. The server must also include the Nonce and the offered service document (e.g., Offered CPD). The server includes an offer validity time as well. Once sent to the client, the server changes the state of the order to "OfferProposed", and a timer set to the validity time is initiated.
サーバーが要求を尊重できる場合、またはいくつかの要件のみを満たすオファーを作成できる場合は、オファーメッセージを作成します。サーバーは、引用符メッセージに示されている顧客注文識別子、およびこの順序に対して生成されたプロバイダ順序識別子を示す必要があります。サーバーには、NONCEおよび提供されたサービス文書（たとえば、提供されているCPD）も含まなければなりません。サーバーにはオファー妥当性時間も含まれています。クライアントに送信されると、サーバーは注文の状態を「OfferProposed」に変更し、有効期間に設定されたタイマーが開始されます。
If the server determines that additional network resources from another Network Provider are needed to accommodate a quotation order, it will create child PQO(s) and will behave as a CPNP client to negotiate child PQO(s) with possible partnering Providers (see Figure 7).
他のネットワークプロバイダからの追加のネットワークリソースが引用順に対応するために必要なと判断した場合は、子PQOを作成し、相談済みプロバイダの可能性のある子PQOをネゴシエートするためのCPNPクライアントとして動作します（図7を参照）。）。
If no PROCESSING, ACCEPT, or DECLINE message is received before the expiry of the RETRANS_TIMER, the server resends the same offer to the client. This procedure is repeated until maximum retry is reached.
RETRANS_TIMERの有効期限が切れる前に処理、承認、または辞退メッセージが受信されない場合、サーバーはクライアントに同じオファーを再送信します。この手順は、最大のリトライに達するまで繰り返されます。
If an ACCEPT message is received before the offered validity time expires, the server proceeds with validation checks as specified in Section 10. The state of the corresponding order is passed to "AcceptReceived". The server sends back an ACK message to terminate the order processing cycle.
オファーされた有効期限が切れる前にAcceptメッセージを受信した場合、サーバーはセクション10で指定されているように検証チェックを進めます。対応する順序の状態は「AccePtreived」に渡されます。サーバーはACKメッセージを返送して注文処理サイクルを終了します。
If a CANCEL or a DECLINE message is received, the server proceeds with the cancellation of the order. The state of the order is then passed to "Cancelled".
キャンセルまたは辞退メッセージが受信された場合、サーバーは注文のキャンセルを進めます。次に注文の状態が「キャンセル」に渡されます。
A client may withdraw a completed order by issuing a WITHDRAW message. Upon receipt of a WITHDRAW message, the server proceeds with the validation checks, as specified in Section 10:
クライアントは、撤回メッセージを発行することによって完成した注文を引き出すことができます。撤回メッセージを受信すると、サーバーはセクション10で指定されているように、検証チェックを進めます。
* If the checks fail, a FAIL message is sent back to the client with the appropriate error code (e.g., 1 (Message Validation Error), 2 (Authentication Required), or 3 (Authorization Failed)).
* チェックが失敗した場合、失敗メッセージは適切なエラーコード（例えば、1（メッセージ検証エラー）、2（認証必須）、または3（認可に失敗）を含むクライアントに送信されます。
* If the checks succeed, the server clears the clauses of the CPD, changes the state of the order to "Cancelled", and sends back an ACK message with an Empty CPD.
* チェックが成功した場合、サーバーはCPDの句をクリアし、注文の状態を「キャンセル」に変更し、空のCPDでACKメッセージを送り返します。
A client may update an order by issuing an UPDATE message. Upon receipt of an UPDATE message, the server proceeds with the validation checks as specified in Section 10:
クライアントは更新メッセージを発行することによって注文を更新することができる。更新メッセージを受信すると、サーバはセクション10で指定されているように検証チェックを進めます。
* If the checks fail, a FAIL message is sent back to the client with the appropriate error code (e.g., 1 (Message Validation Error), 2 (Authentication Required), 3 (Authorization Failed), or 6 (Network Presence Error)).
* チェックが失敗した場合、失敗メッセージは適切なエラーコード（例えば、1（メッセージ検証エラー）、2（認証必須）、3（認証に失敗）、または6（ネットワークプレゼンスエラー））を使用してクライアントに返送されます。
* The exchange of subsequent messages is similar to what is specified in Section 11.1.1. The server should generate a new Nonce value to be included in the offer made to the client.
* 後続のメッセージの交換は、セクション11.1.1で指定されているものと似ています。サーバーは、クライアントに行われたオファーに含まれる新しいNonce値を生成する必要があります。
In each transaction, sequence numbers are used to protect the transaction against replay attacks. Each communicating partner of the transaction maintains two sequence numbers, one for incoming packets and one for outgoing packets. When a partner receives a message, it will check whether the sequence number in the message is larger than the incoming sequence number maintained locally. If not, the message will be discarded. If the message is proved to be legitimate, the value of the incoming sequence number maintained locally will be replaced by the value of the sequence number in the message. When a partner sends out a message, it will insert the value of the outgoing sequence number into the message and increase the outgoing sequence number maintained locally by 1.
各トランザクションでは、シーケンス番号はトランザクションを再生攻撃から保護するために使用されます。トランザクションの各コミュニケーションパートナーは、入ってくるパケットのための1つ、そして発信パケットのための1つのシーケンス番号を2つ維持します。パートナーがメッセージを受信すると、メッセージ内のシーケンス番号がローカルに維持されている着信シーケンス番号よりも大きいかどうかを確認します。そうでなければ、メッセージは破棄されます。メッセージが正当であることが証明された場合、ローカルに維持されている着信シーケンス番号の値は、メッセージ内のシーケンス番号の値に置き換えられます。パートナーがメッセージを送信すると、発信シーケンス番号の値をメッセージに挿入し、ローカルに維持されている発信シーケンス番号を1つ増やします。
If a transaction partner sends out a message and does not receive any expected reply before the retransmission timer expires (i.e., RETRANS_TIMER), a transaction partner will try to retransmit the message. The procedure is reiterated until a maximum retry is reached (e.g., three times). An exception is the last message (e.g., ACK) sent from the server in a transaction. After sending this message, the retransmission timer will be disabled since no additional feedback is expected.
トランザクションパートナーがメッセージを送信し、再送タイマーが期限切れになる前に予想される返信を受信しない場合（すなわちRETRANS_TIMER）、トランザクションパートナーはメッセージを再送信しようとします。この手順は、最大のリトライに達するまで（例えば3回）繰り返される。例外は、トランザクション内のサーバーから送信された最後のメッセージ（ack）です。このメッセージを送信した後、追加のフィードバックが予想されていないため、再送信タイマは無効になります。
In addition, if the partner receives a retransmission of the last incoming packet it handled, the partner can resend the same answer to the incoming packet with a limited frequency. If an answer cannot be generated right after the request is received, the partner needs to generate a PROCESSING message as the answer.
さらに、パートナーが処理された最後の着信パケットの再送信を受信した場合、パートナーは、限られた周波数で受信パケットに同じ答えを再送信することができます。要求を受信した直後に答えを生成できない場合、パートナーは答えとして処理メッセージを生成する必要があります。
To optimize message retransmission, a partner could also store the last incoming packet and the associated answer. Note that the times of retransmission could be decided by the local policy, and retransmission will not cause any change of sequence numbers.
メッセージの再送信を最適化するために、パートナーは最後の着信パケットと関連付けられた回答を保存することもできます。なお、再送の時刻はローカルポリシーによって決定される可能性があり、再送はシーケンス番号の変更を引き起こさない。
The CPNP server should be configurable to log various events and associated information. Such information may include the following:
CPNPサーバーは、さまざまなイベントと関連情報をログに記録するように設定可能です。そのような情報は以下を含み得る。
* Client's IP address
* クライアントのIPアドレス
* Any event change (e.g., new quotation order, offer sent, order confirmation, order cancellation, order withdrawal, etc.)
* イベント変更（例えば、新しい引用順、送信、順序確認、注文キャンセル、注文撤回など）
* Timestamp
* タイムスタンプ
The exact logging details are deployment specific.
正確なロギングの詳細は展開固有です。
The CPNP server can operate in the following modes:
CPNPサーバーは次のモードで動作できます。
Fully automated mode: The CPNP server is provisioned with a set of business guidelines and objectives that will be used as an input to the decision-making process. The CPNP server will service received orders that fall into these business guidelines; otherwise, requests will be escalated to an administrator that will formally validate or invalidate an order request. The set of policies to be configured to the CPNP server are specific to each administrative entity managing a CPNP server.
完全自動モード：CPNPサーバーは、意思決定プロセスへの入力として使用される一連のビジネスガイドラインと目標を備えています。CPNPサーバーは、これらのビジネスガイドラインに分類された受信命令にサービスを提供します。それ以外の場合は、順序要求を正式に検証または無効にすると、リクエストが管理者にエスカレートされます。CPNPサーバーに設定されるポリシーのセットは、CPNPサーバーを管理する各管理エンティティに固有のものです。
Administrative-based mode: This mode assumes some or all of the CPNP server's operations are subject to a formal administrative validation. CPNP events will trigger appropriate validation requests that will be forwarded to the contact person(s) or department that is responsible for validating the orders. Administrative validation messages are relayed using another protocol (e.g., SMTP) or a dedicated tool.
管理ベースのモード：このモードは、CPNPサーバーの操作の一部または全部が正式な管理検証の対象となります。CPNPイベントは、注文の検証を担当する担当者または部門に転送される適切な検証要求を引き起こします。管理上の検証メッセージは、他のプロトコル（例えば、SMTP）または専用のツールを使用して中継されています。
Business guidelines are local to each administrative entity. How validation requests are presented to an administrator are out of scope of this document; each administrative entity may decide the appropriate mechanism to enable for that purpose.
ビジネスガイドラインは各管理エンティティにローカルです。管理者に検証要求がどのように提示されるかはこの文書の範囲外です。各管理エンティティは、その目的を有効にするための適切なメカニズムを決定することができます。
Means to defend the server against denial-of-service attacks must be enabled. For example, access control lists can be enforced on the client, the server, or the network in between to allow a trusted client to communicate with a trusted server.
サービス拒否攻撃に対してサーバーを守ることを意味する必要があります。たとえば、信頼できるクライアントが信頼できるサーバーと通信できるように、クライアント、サーバー、またはネットワークにアクセス制御リストを適用できます。
The client and the server must be mutually authenticated. Authenticated encryption must be used for data confidentiality and message integrity.
クライアントとサーバーは相互に認証されている必要があります。認証された暗号化は、データの機密性とメッセージの整合性に使用する必要があります。
The protocol does not provide security mechanisms to protect the confidentiality and integrity of the packets transported between the client and the server. An underlying security protocol such as (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport Layer Security (TLS) [RFC8446]) must be used to protect the integrity and confidentiality of protocol messages. In this case, if it is possible to provide automated key management (Section 2.1 of [RFC4107]) and associate each transaction with a different key, inter-transaction replay attacks can naturally be addressed. If the client and the server use a single key, an additional mechanism should be provided to protect against inter-transaction replay attacks between them. Clients must implement DTLS record replay detection (Section 3.3 of [RFC6347]) or an equivalent mechanism to protect against replay attacks.
プロトコルは、クライアントとサーバー間で輸送されたパケットの機密性と整合性を保護するためのセキュリティメカニズムを提供しません。プロトコルメッセージの完全性と機密性を保護するために、（例えば、データグラムトランスポートレイヤセキュリティ（DTLS）[RFC6347]のような基礎となるセキュリティプロトコル（TLS）[RFC8446]）を使用する必要があります。この場合、自動鍵管理（[RFC4107]のセクション2.1）を提供し、各トランザクションを異なるキーに関連付けることが可能であれば、トランザクション間リプレイ攻撃は自然に対処できます。クライアントとサーバーが単一のキーを使用する場合、それらの間のトランザクション間再生攻撃から保護するために追加のメカニズムを提供する必要があります。クライアントはDTLSレコード再生検出（[RFC6347]のセクション3.3）または再生攻撃から保護するための同等のメカニズムを実装する必要があります。
DTLS and TLS with a cipher suite offering confidentiality protection and the guidance given in [RFC7525] must be followed to avoid attacks on (D)TLS.
機密保護を提供するCipher Suiteと[RFC7525]で与えられたガイダンスを持つDTLSとTLSは、（D）TLSの攻撃を回避するために従う必要があります。
The client must silently discard CPNP responses received from unknown CPNP servers. The use of a randomly generated Transaction-ID makes it hard to forge a response from a server with a spoofed IP address belonging to a legitimate CPNP server. Furthermore, CPNP demands that messages from the server must include the correct identifiers of the orders. Two order identifiers are used: one generated by the client and a second one generated by the server. Both the CPNP client and server maintain the local identifier they assigned and the one assigned by the peer for a given order. Means to detect swapping of these identifiers (even when such swapping occurs inadvertently at the client or the server) should be enabled by CPNP clients/servers. For example, the CPNP server should not assign a Provider agreement identifier that is equal to a Customer agreement identifier used by the CPNP client.
クライアントは、未知のCPNPサーバーから受信したCPNP応答を黙って破棄しなければなりません。ランダムに生成されたトランザクションIDを使用すると、正当なCPNPサーバに属する偽装されたIPアドレスを使用してサーバーからの応答を偽造することが困難になります。さらに、CPNPは、サーバーからのメッセージに注文の正しい識別子を含める必要があります。2つの注文識別子が使用されます。クライアントによって生成されたものとサーバーによって生成された2番目のもの。CPNPクライアントとサーバーの両方が、割り当てられているローカル識別子と、ピアによって割り当てられたものを特定の順序で管理します。これらの識別子のスワップを検出することは（そのようなスワッピングがクライアントまたはサーバーで誤って起こる場合でも）CPNPクライアント/サーバーによって有効にする必要があります。たとえば、CPNPサーバーは、CPNPクライアントによって使用される顧客合意識別子に等しいプロバイダー協定識別子を割り当ててはならない。
The Provider must enforce the means to protect privacy-related information included in the documents (see Section 8.7) exchanged in CPNP messages [RFC6462]. In particular, this information must not be revealed to external parties without the consent of Customers. Providers should enforce policies to make Customer fingerprinting difficult to achieve (e.g., in a recursion request). For more discussion about privacy, refer to [RFC6462] [RFC6973].
プロバイダは、CPNPメッセージ（RFC6462]で変更された文書に含まれるプライバシー関連情報を保護するための手段を強制する必要があります[RFC6462]。特に、この情報は顧客の同意なしに外部の関係者に明らかにされてはいけません。プロバイダーは、顧客の指紋を達成するのが困難にするためのポリシーを執行する必要があります（例えば、再帰要求で）。プライバシーに関する詳細については、[RFC6462] [RFC6973]を参照してください。
The Nonce and the Transaction-ID attributes provide sufficient randomness and can effectively tolerate attacks raised by off-path adversaries, who do not have the capability of eavesdropping and intercepting the packets transported between the client and the server. Only authorized clients must be able to modify accepted CPNP orders. The use of a randomly generated Nonce by the server makes it hard to modify an agreement on behalf of a malicious third party.
NonceとTransaction-ID属性は十分なランダム性を提供し、オフパスの敵によって上昇した攻撃を効果的に許容できます。認可されたクライアントだけが、受け入れられたCPNP注文を変更できなければなりません。サーバーによってランダムに生成されたノンスの使用を使用すると、悪意のある第三者に代わって契約を変更することが困難になります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G.およびC. NEWMAN、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「ルーティングバックス - ナウルフォーム（RBNF）：さまざまなルーティングプロトコル仕様の符号化規則を形成するための構文、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。rfc-editor.org/info/rfc5511>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] RESCORLA、E.およびN. MODADUGU、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C.、およびN. Wang、 "IP Connectivity Provisioning Profile（CPP）"、RFC 7297、DOI 10.17487 / RFC7297、2014年7月、<https：//www.rfc-編集者。ORG / INFO / RFC7297>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D., Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE Approach for Network Virtualization: Differentiated Services Delivery", Annals of Telecommunication, Volume 64, 277-288, DOI 10.1007/s12243-009-0103-4, April 2009, <https://rd.springer.com/article/10.1007/ s12243-009-0103-4>.
[Agave] Boucadair、M.、Georgatsos、P.、Wang、N.、Griffin、D.、Pavlou、G.、HowArth、M.、A. Elizondo、「ネットワーク仮想化のためのAgaveアプローチ」、電気通信の年間、巻64,277-288、DOI 10.1007 / S12243-009-0103-4、<https：//rd.springer.com/article / 10.1007/0103-4>。
[COPS-SLS] Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)", Work in Progress, Internet-Draft, draft-nguyen-rap-cops-sls-03, 5 July 2002, <https://tools.ietf.org/html/draft-nguyen-rap-cops-sls-03>.
[COPS-SLS] NGUYEN、T.、「SLSネゴシエーション（COPS-SLS）」、進行中の作業、インターネットドラフト、ドラフト - NGUYEN-RAP-COPS-SLS-03、<https：//tools.ietf.org/html/draft-nguyen-rap-cops-sls-03>。
[DSNP] Chen, J., "Dynamic Service Negotiation Protocol (DSNP)", Work in Progress, Internet-Draft, draft-itsumo-dsnp-03, 2 March 2006, <https://tools.ietf.org/html/draft-itsumo-dsnp-03>.
[DSNP] Chen、J.、「動的サービス交渉プロトコル（DSNP）」、進捗状況、インターネットドラフト、ドラフトottumo-DSNP-03,23,2006、<https：//tools.ietf.org/html/ draft-witsumo-dsnp-03>。
[ETICS] EU FP7 ETICS Project, "Economics and Technologies of Inter-Carrier Services", January 2014, <https://cordis.europa.eu/project/id/248567>.
【ETICS】EU FP7 ETICSプロジェクト、「キャリア間サービスの経済学および技術」、2014年1月、<https：//cordis.europa.eu/project/id/248567>。
[L2VPN-NETWORK-YANG] Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model", Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-00, 2 July 2020, <https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00>.
[L2VPN-Network-Yang] Barguil、S.、Dios、OGD、Boucadair、M.、Munoz、LA、Jalil、L.、およびJ. MA、「レイヤ2 VPNネットワークヤンモデル」、進行中、インターネット--draft、draft-ietf-opsawg-l2nm-00、2020年7月2日、<https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00>。
[L3VPN-NETWORK-YANG] Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05, 16 October 2020, <https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05>.
[L3VPN-Network-Yang] Barguil、S.、Dios、OGD、Boucadair、M.、Munoz、LA、A.アグアド、「レイヤ3 VPNネットワークヤンモデル」、進行中の作業、インターネットドラフト、ドラフト - IETF-Opsawg-L3SM-L3NM-05,2020、<https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05>。
[LISP-MS-DISCOVERY] Boucadair, M. and C. Jacquenet, "LISP Mapping Service Discovery at Large", Work in Progress, Internet-Draft, draft-boucadair-lisp-idr-ms-discovery-01, 9 March 2016, <https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-discovery-01>.
[Lisp-MS-Discovery] Boucadair、M.およびC. Jacquenet、「Lisp Mapping Service Discovery at Service Service Discovery at Service Service Discovery at Service Service Discovery」、インターネットドラフト、Draft-Boucadair-Lisp-IDR-MS-Discovery-01、2016年3月9日、<https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-discovery-01>。
[NETSLICES-ARCH] Geng, L., Dong, J., Bryant, S., Makhijani, K., Galis, A., Foy, X. D., and S. Kuklinski, "Network Slicing Architecture", Work in Progress, Internet-Draft, draft-geng-netslices-architecture-02, 3 July 2017, <https://tools.ietf.org/html/draft-geng-netslices-architecture-02>.
[Netslices-Arch] Geng、L.、Dong、J.、Bryant、S.、Makhijani、K.、Galis、A.、Foy、XD、およびS。Kuklinski、「ネットワークスライスアーキテクチャ」、進行中、インターネット--draft、draft-geng-netslices-architecture-02,2017,3,3,3,3,3,3,3,3,2,0,16,200、<https：//tools.ietf.org/html/draft-geng-netslices-02>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：//www.rfc-editor.org/info/rfc2782>。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, DOI 10.17487/RFC3084, March 2001, <https://www.rfc-editor.org/info/rfc3084>.
[RFC3084]チャン、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R.、A. Smith、 "COPS2001年3月、<https://ww.rfc- editor.org/info/rfc3084>のポリシー・プロビジョニング（COPS-PR） "、RFC 3084、DOI 10.17487 / RFC3084の使用法。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4026] Andersson、L.およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、DOI 10.17487 / RFC4026、2005年3月、<https：//www.rfc-editor.org/info/RFC4026>。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S.およびR. Housley、「暗号鍵管理のためのガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107>。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, <https://www.rfc-editor.org/info/rfc4176>.
[RFC4176] El Mghazli、Y、Ed。、Nadeau、T.、Boucadair、M.、Chan、K.、およびA. Gonguet、「レイヤ3仮想プライベートネットワーク（L3VPN）操作と管理のためのフレームワーク」、RFC 4176、DOI 10.17487 / RFC4176、2005年10月、<https://www.rfc-editor.org/info/rfc4176>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, DOI 10.17487/RFC6462, January 2012, <https://www.rfc-editor.org/info/rfc6462>.
[RFC6462] Cooper、A。、「インターネットプライバシーワークショップからの報告」、RFC 6462、DOI 10.17487 / RFC6462、2012年1月、<https：//www.rfc-editor.org/info/rfc6462>。
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, <https://www.rfc-editor.org/info/rfc6574>.
[RFC6574] Tschofenig、H.およびJ.Arkko、「スマートオブジェクトワークショップからの報告」、RFC 6574、DOI 10.17487 / RFC6574、2012年4月、<https：//www.rfc-editor.org/info/rfc6574>。
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, <https://www.rfc-editor.org/info/rfc6770>.
[RFC6770] Bertrand、G.、ED。、Stephan、E.、Burbridge、T.、Eardley、P.、Ma、K.、およびG.ワトソン、「コンテンツ配信ネットワーク相互接続のためのユースケース」、RFC 6770、DOI10.17487 / RFC6770、2012年11月、<https://www.rfc-editor.org/info/rfc6770>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.
[RFC6793] VOHRA、Q.およびE.チェン、「4オクテット自律システム（AS）ナンバースペースのBGPサポート」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<https：//www.rfc-編集者。ORG / INFO / RFC6793>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D.、およびD.Lewis、「Locator / ID分離プロトコル（Lisp）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<https：//www.rfc-editor.org/info/rfc6830>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C.およびP.Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https：//www.rfc-editor.org/info/rfc7049>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M.およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの視点」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：///www.rfc-編集者。ORG / INFO / RFC7149>。
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7215]ジャカブ、L.、Cabellos-Aparicio、A.、Coras、F.、Domingo-Pascal、J.、およびD.Lewis、「ロケータ/識別子分離プロトコル（LISP）ネットワーク要素展開の考慮事項」、RFC 7215、DOI 10.17487 / RFC7215、2014年4月、<https://www.rfc-editor.org/info/rfc7215>。
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC7491] King、D.およびA. Farrel、「アプリケーションベースのネットワーク事業のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<https：//www.rfc-editor.org/情報/ RFC7491>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M.、K。Watsen、 "Restconf Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.
[RFC8299] WU、Q。、ED。、Litkowski、S.、Tomotaki、L.、およびK.小垣、「L3VPNサービス提供のためのYangデータモデル」、RFC 8299、DOI 10.17487 / RFC8299、2018年1月、<https：//www.rfc-editor.org/info/rfc8299>。
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.
[RFC8309] WU、Q.、Liu、W.およびA. Farrel、「サービスモデルは説明しました」、RFC 8309、DOI 10.17487 / RFC8309、2018年1月、<https：//www.rfc-editor.org/info/RFC8309>。
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, <https://www.rfc-editor.org/info/rfc8329>.
[RFC8329] Lopez、D.、Lopez、E.、Dunbar、L.、Strassner、J.、R.Kumar、「ネットワークセキュリティ機能へのインターフェースのためのフレームワーク」、RFC 8329、DOI 10.17487 / RFC8329、2018年2月、<https://www.rfc-editor.org/info/rfc8329>。
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8466]ウェン、B.、Fioccola、G.、ED。、XIE、C、およびL.Jalil、「レイヤ2仮想プライベートネットワーク（L2VPN）サービス配信のためのYangデータモデル、RFC 8466、DOI 10.17487 /RFC8466、2018年10月、<https：//www.rfc-editor.org/info/rfc8466>。
[RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for Software-Defined Networking (CLAS)", RFC 8597, DOI 10.17487/RFC8597, May 2019, <https://www.rfc-editor.org/info/rfc8597>.
[RFC8597]逆、LM、Bernardos、CJ、Lopez、D.、Boucadair、M.、P. Iovanna、「ソフトウェア定義のネットワーキング（CLAS）の協力層アーキテクチャ、RFC 8597、DOI 10.17487 / RFC85972019年5月、<https：//www.rfc-editor.org/info/rfc8597>。
[RNAP] Wang, X., "A Resource Negotiation and Pricing Protocol (RNAP)", <http://www.cs.columbia.edu/~xinwang/public/projects/ protocol.html>.
[RNAP] Wang、X.、「リソースネゴシエーションと価格設定プロトコル（RNAP）」、<http://www.cs.cs.columbia.edu/~xinwang/public/projects/ protocol.html>。
[SNAP] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and S. Tuecke, "SNAP: A Protocol for Negotiating Service Level Agreements and Coordinating Resource Management in Distributed Systems", DOI 10.1.1.19.5907, 2002, <http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.19.5907>.
[スナップ] Czajkowski、K.、Foster、I.、Kesselman、C、Sander、V.、S.Tuecke、 "Snap：サービスレベル契約の交渉および分散システムにおけるリソース管理の調整プロトコル"、DOI 10.1。1.19.5907,2002、<http://citeeserx.ist.psu.edu/viewdoc/概要？DOI = 10.1.1.19.5907>。
[SrNP] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation Protocol (SrNP)", <https://www.ist-tequila.org/presentations/srnp-pipcm.pdf>.
[SRNP] Georgatsos、P.およびG.Giannakopouros、「サービス交渉プロトコル（SRNP）」、<https://www.ist-tequila.org/presentations/srnp-pipcm.pdf>。
[TEAS-SLICE-NBI] Contreras, L. M., Homma, S., and J. A. Ordonez-Lucena, "Considerations for defining a Transport Slice NBI", Work in Progress, Internet-Draft, draft-contreras-teas-slice-nbi-02, 13 July 2020, <https://tools.ietf.org/html/draft-contreras-teas-slice-nbi-02>.
【TEAS-SLICE-NBI】COLCTRAS、LM、HOMMA、S、およびJA Ordonez-Lucena、「トランスポートスライスの定義に関する考察」、進行中の作業、インターネットドラフト、ドラフト - Contras-Teas-Slice-NBI-2020年7月13日、<https://tools.ietf.org/html/draft-contreras-teas-slice-nbi-02>
Acknowledgements
謝辞
Thanks to Diego R. Lopez, Adrian Farrel, Éric Vyncke, Eric Kline, and Benjamin Kaduk for the comments.
コメントのためのDiego R. Lopez、Adrian Farrel、Eric Vyncke、Eric Kline、およびBenjamin Kadukに感謝します。
Thanks to those that reviewed this document for publication in the Independent Stream.
この文書を独立したストリームに出版するためにこの文書を見直しました。
Special thanks to Luis Miguel Contreras Murillo for the detailed review.
詳細レビューのためのLuis Miguel Contrlas Murilloに感謝します。
Authors' Addresses
著者の住所
Mohamed Boucadair (editor) Orange 35000 Rennes France
Mohamed Boucadair（編集）オレンジ35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Christian Jacquenet Orange 35000 Rennes France
Christian Jacquenet Orange 35000 Rennesフランス
Email: christian.jacquenet@orange.com
Dacheng Zhang Huawei Technologies
Dacheng Zhang Huawei Technologies
Email: dacheng.zhang@huawei.com
Panos Georgatsos Centre for Research and Innovation Hellas 78, Filikis Etairias str. 38334 Volos Greece
Panos Georgatsos研究およびイノベーションHellas 78、Filikis Etairias Str。38334 volosギリシャ
Phone: +302421306070
Email: pgeorgat@gmail.com