[要約] RFC 7297は、IP接続プロビジョニングプロファイル（CPP）に関する標準化された仕様であり、ネットワークデバイスの自動設定と管理を目的としています。CPPは、ネットワークの接続性を確保するためのプロトコルと手順を提供します。
Independent Submission M. Boucadair
Request for Comments: 7297 C. Jacquenet
Category: Informational France Telecom
ISSN: 2070-1721 N. Wang
University of Surrey
July 2014
IP Connectivity Provisioning Profile (CPP)
IP接続プロビジョニングプロファイル（CPP）
Abstract
概要
This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.
このドキュメントでは、接続プロビジョニングプロファイル（CPP）について説明し、サービス提供コンテキスト（Voice over IPまたはIP TVなど）内で満たされるIP / MPLS接続要件をキャプチャするCPPテンプレートを提案します。 CPPは、到達可能性の範囲と帯域幅/容量のニーズとともに、基盤となるトランスポートネットワークによってサポートされるIP転送パラメーターのセットを定義します。一方向の遅延や一方向の遅延変動などの適切なパフォーマンスメトリックは、IP転送サービスを特徴付けるために使用されます。 CPPでは、グローバルと制限付きの両方の到達可能性スコープをキャプチャできます。
Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision-making' capabilities based upon negotiated/offered CPPs.
このような一般的なCPPテンプレートは、（1）サービスネゴシエーションとアクティブ化手順の自動化を促進し、サービスプロビジョニングを加速し、（2）トラフィックエンジニアリング機能とサービス管理機能の（トラフィック）目標を設定し、（3）サービスを改善することを目的としていますネゴシエートされた/提供されたCPPに基づく「意思決定」機能を備えたネットワーク管理システム。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7297.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7297で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Connectivity Provisioning Interface (CPI) . . . . . . . . 3
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Reference Architecture . . . . . . . . . . . . . . . . . 7
2. Scope of This Document . . . . . . . . . . . . . . . . . . . 9
3. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 9
3.1. Customer Nodes Map . . . . . . . . . . . . . . . . . . . 9
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . 11
3.4. Availability . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Capacity . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 13
3.7. Overall Traffic Guarantees . . . . . . . . . . . . . . . 13
3.8. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 13
3.9. Flow Identification . . . . . . . . . . . . . . . . . . . 13
3.10. Routing and Forwarding . . . . . . . . . . . . . . . . . 14
3.11. Activation Means . . . . . . . . . . . . . . . . . . . . 15
3.12. Invocation Means . . . . . . . . . . . . . . . . . . . . 15
3.13. Notifications . . . . . . . . . . . . . . . . . . . . . . 16
4. CPP Template . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . 18
This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP, IP TV, and VPN services).
このドキュメントでは、接続プロビジョニングプロファイル（CPP）について説明し、サービス提供コンテキスト（Voice over IP、IP TV、VPNサービスなど）内で満たされるIP / MPLS接続要件をキャプチャするCPPテンプレートを提案します。
In this document, the IP connectivity service is the IP transfer capability characterized by a (Source Nets, Destination Nets, Guarantees, Scope) tuple where "Source Nets" is a group of unicast IP addresses, "Destination Nets" is a group of IP unicast and/or multicast addresses, and "Guarantees" reflects the guarantees (expressed in terms of Quality Of Service (QoS), performance, and availability, for example) to properly forward traffic to the said "Destination". Finally, the "Scope" denotes the (network) perimeter (e.g., between Provider Edge (PE) routers or Customer Nodes) where the said guarantees need to be provided.
このドキュメントでは、IP接続サービスは、（Source Nets、Destination Nets、Guarantees、Scope）タプルによって特徴付けられるIP転送機能であり、「Source Nets」はユニキャストIPアドレスのグループ、「Destination Nets」はIPのグループです。ユニキャストアドレスやマルチキャストアドレス、および「保証」は、トラフィックを上記「宛先」に適切に転送するための保証（Quality Of Service（QoS）、パフォーマンス、および可用性などで表現される）を反映します。最後に、「スコープ」は、上記の保証を提供する必要がある（ネットワーク）境界（プロバイダーエッジ（PE）ルーターまたはカスタマーノード間など）を示します。
Figure 1 shows the various connectivity provisioning interfaces covered by CPP: the Customer-Network CPI, the Service-Network CPI, and the Network-Network CPI. Services and applications whose parameters are captured by means of a CPP exchanged through the Service-Network CPI may be provided by the same administrative entity that operates the underlying network or by another entity (for example, a Content Provider).
図1は、CPPがカバーするさまざまな接続プロビジョニングインターフェースを示しています。カスタマーネットワークCPI、サービスネットワークCPI、ネットワークネットワークCPIです。サービスネットワークCPIを介して交換されるCPPによってパラメーターが取得されるサービスおよびアプリケーションは、基盤となるネットワークを操作する同じ管理エンティティまたは別のエンティティ（コンテンツプロバイダーなど）によって提供される場合があります。
+---------+
|Service A|
+---+-----+
| +---------+
|CPI |Service B|
| +-+-------+
| |CPI
+----------+ +-+------+-------+ +------------+
| Customer |-----|Network Provider|-----|Peer Network|
+----------+ CPI +----------------+ CPI +------------+
Figure 1: Connectivity Provisioning Interfaces
図1：接続プロビジョニングインターフェイス
The interfaces depicted in Figure 1 can be summarized as shown in Figure 2.
図1に示すインターフェースは、図2に示すように要約できます。
The Customer shown in Figure 2 may be another Network Provider (e.g., an IP transit provider), a Service Provider (e.g., an IP telephony Service Provider) that requires the invocation of resources provided by a Network Provider, or an enterprise that wants to interconnect its various sites by subscribing to a VPN service provided by a Network Provider. The proposed CPP can be used to expose, capture, and facilitate the negotiation of the service parameters between these various entities, thereby presenting a common template for describing the available connectivity services.
図2に示されているお客様は、別のネットワークプロバイダー（IPトランジットプロバイダーなど）、ネットワークプロバイダーによって提供されるリソースの呼び出しを必要とするサービスプロバイダー（IPテレフォニーサービスプロバイダーなど）、またはネットワークプロバイダーが提供するVPNサービスにサブスクライブして、さまざまなサイトを相互接続します。提案されたCPPは、これらのさまざまなエンティティ間のサービスパラメータのネゴシエーションを公開、キャプチャ、および促進するために使用できます。これにより、使用可能な接続サービスを説明するための共通のテンプレートが提示されます。
+----------------+
| Customer |
+-------+--------+
+ CPI
+-------+--------+
|Network Provider|
+----------------+
Figure 2: CPP: Generic Connectivity Provisioning Interfaces
図2：CPP：汎用接続プロビジョニングインターフェイス
In the rest of this document, "Customer" is used as a generic term to denote the business entity that subscribes to connectivity services offered by a Network Provider (see Figure 2).
このドキュメントの残りの部分では、「顧客」は、ネットワークプロバイダーによって提供される接続サービスにサブスクライブするビジネスエンティティを表す総称として使用されます（図2を参照）。
Procedures for the design and the operation of IP services have become increasingly diverse and complex. The time it takes to negotiate service parameters and then proceed with the corresponding resource allocation can thus be measured in days, if not weeks. Yet, experience has shown that the bilateral discussions that usually take place between a Customer and a Network Provider never rely upon some kind of standard checklist where the Customer would be invited to tick all the parameters that apply to its environment. These parameters would then be negotiated with the Network Provider, as a function of the available resources, the Customer's expectations, the provider's network planning policy, etc.
IPサービスの設計と運用の手順は、ますます多様化および複雑化しています。したがって、サービスパラメータをネゴシエートしてから対応するリソース割り当てを続行するのにかかる時間は、数週間ではなくても、日単位で測定できます。しかし、経験から、通常、顧客とネットワークプロバイダーの間で行われる双方向の議論は、顧客がその環境に適用されるすべてのパラメーターをチェックするように求められる、ある種の標準チェックリストに決して依存しないことがわかっています。これらのパラメーターは、利用可能なリソース、顧客の期待、プロバイダーのネットワーク計画ポリシーなどに応じて、ネットワークプロバイダーと交渉されます。
The definition of a clear interface between the service (including third-party applications) and the network layers would therefore facilitate the said discussion, thereby improving the overall service delivery procedure by optimizing the design of the network infrastructures. Indeed, the CPP interface aims at exposing and characterizing, in a technology-agnostic manner, the IP transfer requirements to be met when invoking IP transfer capabilities of a network operated by a Network Provider between a set of Customer Nodes (e.g., Multimedia Gateway (Section 11.2.7 of [RFC2805]), Session Border Controller [RFC5853], etc.).
したがって、サービス（サードパーティアプリケーションを含む）とネットワークレイヤーの間の明確なインターフェイスの定義は、前述の議論を容易にし、それによってネットワークインフラストラクチャの設計を最適化することにより、全体的なサービス提供手順を改善します。実際、CPPインターフェースは、テクノロジーにとらわれない方法で、ネットワークプロバイダーが運営するネットワークのIP転送機能を一連のカスタマーノード（たとえば、マルチメディアゲートウェイ（ [RFC2805]の11.2.7項）、Session Border Controller [RFC5853]など）。
These requirements include: reachability scope (e.g., limited scope, Internet-wide), direction, bandwidth requirements, QoS parameters (e.g., one-way delay [RFC2679], loss [RFC2680], or one-way delay variation [RFC3393]), protection, and high-availability guidelines (e.g., restoration in less than 50 ms, 100 ms, or 1 second).
これらの要件には、到達可能性の範囲（例：制限範囲、インターネット全体）、方向、帯域幅の要件、QoSパラメーター（例：一方向の遅延[RFC2679]、損失[RFC2680]、または一方向の遅延変動[RFC3393]）が含まれます。 、保護、および高可用性のガイドライン（たとえば、50ミリ秒未満、100ミリ秒、または1秒以内の復元）。
These requirements are then translated into IP/MPLS-related technical clauses (e.g., need for recovery means, definition of the class of service, need for control-plane protection, etc.). In a later stage, these various clauses will be addressed by the activation of adequate network features and technology-specific actions (e.g., Multiprotocol Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), by means of CPP-derived configuration information.
これらの要件は、IP / MPLS関連の技術条項に変換されます（たとえば、回復手段の必要性、サービスクラスの定義、コントロールプレーン保護の必要性など）。後の段階で、これらのさまざまな条項は、適切なネットワーク機能とテクノロジー固有のアクション（たとえば、マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE、[RFC3346]）、リソース予約プロトコル（RSVP、[RFC2205]）のアクティブ化によって対処されます）、Open Shortest Path First（OSPF）、中間システム間（IS-IS）など）、CPP派生の構成情報による。
For traffic conformance purposes, a CPP also includes flow identification and classification rules to be followed by participating nodes whenever they have to process traffic according to a specific service as defined by the said CPP.
トラフィック適合の目的で、CPPには、参加ノードがCPPで定義された特定のサービスに従ってトラフィックを処理する必要がある場合に必ず従うフロー識別および分類ルールも含まれます。
The CPP template aims to capture connectivity needs and to represent and value these requirements in a standardized manner. Service- and Customer-specific IP provisioning rules may lead to a dramatic increase of the number of IP transfer classes that need to be (pre-)engineered in the network. Instantiating each CPP into a distinct class of service should therefore be avoided for the sake of performance and scalability.
CPPテンプレートは、接続のニーズを把握し、これらの要件を標準化された方法で表現および評価することを目的としています。サービスおよびお客様固有のIPプロビジョニングルールにより、ネットワークで（事前に）設計する必要のあるIP転送クラスの数が劇的に増加する可能性があります。したがって、パフォーマンスとスケーラビリティのために、各CPPを異なるサービスクラスにインスタンス化することは避けてください。
Therefore, application-agnostic IP provisioning practices should be recommended, since the requirements captured in the CPP can be used to identify which network class of service is to be used to meet those requirements/guarantees. From that standpoint, the CPP concept is meant to design a limited number of generic classes so that individual CPP documents, by capturing the connectivity requirements of services, applications, and Customers, can be easily mapped to these classes.
したがって、CPPにキャプチャされた要件を使用して、これらの要件/保証を満たすために使用するサービスクラスを特定できるため、アプリケーションに依存しないIPプロビジョニングプラクティスを推奨します。その観点から、CPPの概念は、サービス、アプリケーション、および顧客の接続要件をキャプチャすることにより個々のCPPドキュメントをこれらのクラスに簡単にマッピングできるように、限られた数のジェネリッククラスを設計することを目的としています。
CPP may also be used as a guideline for network dimensioning and planning teams of a Network Provider to ensure that appropriate resources (e.g., network cards, routers, link capacity, etc.) have been provisioned. Otherwise, (underlying) transport networks would not be able to meet the objectives expressed in all CPP requests.
CPPは、適切なリソース（ネットワークカード、ルーター、リンクキャパシティなど）がプロビジョニングされていることを確認するために、ネットワークプロバイダーのネットワーク分析チームと計画チームのガイドラインとしても使用できます。そうしないと、（基礎となる）トランスポートネットワークは、すべてのCPP要求で表現された目標を達成できなくなります。
Such a generic CPP template:
このような一般的なCPPテンプレート：
o Facilitates the automation of the service negotiation and activation procedures, thus improving service delivery times;
o サービスネゴシエーションとアクティブ化手順の自動化を促進し、サービス提供時間を改善します。
o Can help set Traffic Engineering function and service management function objectives, for example, as a function of the number of CPP templates to be processed over a specific period of time; and
o たとえば、特定の期間に処理されるCPPテンプレートの数の関数として、トラフィックエンジニアリング機能とサービス管理機能の目標を設定するのに役立ちます。そして
o Improves service and network management systems by adding 'decision-making' capabilities based upon negotiated/offered CPPs.
o 交渉/提供されたCPPに基づいて「意思決定」機能を追加することにより、サービスおよびネットワーク管理システムを改善します。
In addition, this CPP abstraction makes a clear distinction between the connectivity provisioning requirements and the associated technology-specific rules that need to be applied by participating nodes and that are meant to accommodate such requirements.
さらに、このCPP抽象化は、接続プロビジョニング要件と、参加ノードによって適用される必要があり、そのような要件に対応することを目的とした関連するテクノロジー固有のルールを明確に区別します。
The CPP defines the set of IP/MPLS transfer guarantees to be offered by the underlying transport network together with a reachability scope and capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize the IP transfer service. Guarantees related to availability and resiliency are also included in the CPP.
CPPは、到達可能性の範囲と容量のニーズとともに、基盤となるトランスポートネットワークによって提供される一連のIP / MPLS転送保証を定義します。一方向の遅延や一方向の遅延変動などの適切なパフォーマンスメトリックは、IP転送サービスを特徴付けるために使用されます。可用性と回復力に関連する保証もCPPに含まれています。
The CPP can be used in an integrated business environment (where the service and network infrastructures are managed by the same administrative entity) or another business environment (where an administrative entity manages the service while another manages the network infrastructure). In the following sections, no assumption is made about the business environment (integrated or not).
CPPは、統合ビジネス環境（サービスとネットワークインフラストラクチャが同じ管理エンティティによって管理される）または別のビジネス環境（管理エンティティがサービスを管理し、別のビジネスインフラストラクチャがネットワークインフラストラクチャを管理する）で使用できます。以下のセクションでは、ビジネス環境（統合されているかどうかにかかわらず）については何も想定されていません。
Service differentiation at the network layer can be enforced by tweaking various parameters that belong to distinct dimensions (e.g., forwarding, routing, processing of incoming traffic, traffic classification, etc.). This document does not make any assumption on how network services are implemented within a networking infrastructure.
ネットワーク層でのサービスの差別化は、異なる次元に属するさまざまなパラメーターを微調整することによって実施できます（たとえば、転送、ルーティング、着信トラフィックの処理、トラフィック分類など）。このドキュメントでは、ネットワークインフラストラクチャ内でのネットワークサービスの実装方法については想定していません。
Activating unicast or multicast capabilities to deliver a connectivity service can be explicitly requested by a Customer in a CPP or can be an engineering decision of a Network Provider based on the analysis of the Customer connectivity provisioning requirements.
接続サービスを提供するためにユニキャストまたはマルチキャスト機能をアクティブにすることは、CPPでお客様が明示的に要求することも、お客様の接続プロビジョニング要件の分析に基づいてネットワークプロバイダーが技術的に決定することもできます。
Examples of CPP usage include the northbound interface introduced by the Application-Based Network Operations (ABNO) framework [NET-OPS] and the technique for exposing network services and their characteristics defined in [RFC7149].
CPPの使用例には、アプリケーションベースのネットワーク操作（ABNO）フレームワーク[NET-OPS]によって導入されたノースバウンドインターフェイスや、[RFC7149]で定義されているネットワークサービスとその特性を公開する手法が含まれます。
Customer Nodes belong to a Customer (including corporate Customers) or a service infrastructure (see Figure 1). In some contexts, Customer Nodes can be provided and managed by the Network Provider. The connectivity between these Customer Nodes reflects the IP transfer capability implemented thanks to the allocation of a set of IP resources. IP transfer capabilities are considered by higher-layer services (such as transport- and application-layer services) as black boxes. Appropriate notifications and reports would be communicated (through dedicated means) to Customer Nodes to assess the compliance of the experienced IP transfer service against what has been negotiated with the corresponding CPP. These notifications may also be used to assess the efficiency of the various policies enforced in the networking infrastructure to accommodate the requirements detailed in the CPP.
顧客ノードは、顧客（法人顧客を含む）またはサービスインフラストラクチャに属します（図1を参照）。一部のコンテキストでは、ネットワークプロバイダーがカスタマーノードを提供および管理できます。これらのカスタマーノード間の接続は、一連のIPリソースの割り当てにより実装されたIP転送機能を反映しています。 IP転送機能は、上位層のサービス（トランスポート層やアプリケーション層のサービスなど）ではブラックボックスと見なされます。適切な通知とレポートが（専用の手段を介して）カスタマーノードに送信され、対応するCPPとの交渉内容に対する経験豊富なIP転送サービスのコンプライアンスを評価します。これらの通知は、CPPで詳述されている要件に対応するために、ネットワークインフラストラクチャで適用されるさまざまなポリシーの効率を評価するためにも使用できます。
The CPP reference architectures are depicted in Figures 3, 4, and 5.
CPPリファレンスアーキテクチャを図3、4、および5に示します。
The Customer infrastructure can be connected over networking infrastructures managed by one or several Network Providers.
お客様のインフラストラクチャは、1つまたは複数のネットワークプロバイダーが管理するネットワークインフラストラクチャを介して接続できます。
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node |.--. .--.. . |Provider Node |
+--------------+ +--------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
Figure 3: Reference Architecture: Connectivity Service Provided by the Same Network Provider Using Distinct Interconnection Nodes
図3：リファレンスアーキテクチャ：個別の相互接続ノードを使用して同じネットワークプロバイダーが提供する接続サービス
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+-----------------------------------+
| Provider Node |
+-----------------------------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
Figure 4: Reference Architecture: Connectivity Service Provided by the Same Network Provider Using a Single Interconnection Node
図4：リファレンスアーキテクチャ：単一の相互接続ノードを使用して同じネットワークプロバイダーが提供する接続サービス
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node | |Provider Node |
+--------------+ +--------------+
( .--.) ( .--.)
.-.' Network A '.-. .-.' Network B '.-.
( ) ( )
(. . . .) (. . . .)
'.-_-.'.-_-._..' '.-_-.'.-_-._..'
Figure 5: Reference Architecture: Connectivity Services Provided by Distinct Network Providers
図5：リファレンスアーキテクチャ：異なるネットワークプロバイダーが提供する接続サービス
This document details the clauses of the CPP. Candidate protocols (e.g., [CPNP]) that can be used to negotiate and enforce a given CPP are not discussed in this document.
この文書では、CPPの条項について詳しく説明します。特定のCPPのネゴシエーションと実施に使用できる候補プロトコル（[CPNP]など）は、このドキュメントでは説明されていません。
In addition to CPP clauses, other clauses may be included in an agreement between a Customer and a Provider (e.g., contact point, escalation procedure, incidents management, billing, etc.). It is out of the scope of this document to detail all those additional clauses.
CPP条項に加えて、顧客とプロバイダーの間の契約に他の条項が含まれる場合があります（例：窓口、エスカレーション手順、インシデント管理、請求など）。これらすべての追加の句の詳細は、このドキュメントの範囲外です。
Examples of how to translate CPP clauses into specific policies are provided for illustration purposes. It is out of the scope of this document to provide an exhaustive list of the technical means to meet the objectives detailed in a CPP.
CPP条項を特定のポリシーに変換する方法の例は、説明のために提供されています。 CPPで詳述されている目標を達成するための技術的手段の完全なリストを提供することは、このドキュメントの範囲外です。
CPP was mainly designed to target IP connectivity services. Nevertheless, it can be used for other non-IP transport schemes. It is out of the scope of this document to assess the applicability of CPP to these non-IP schemes.
CPPは、主にIP接続サービスを対象として設計されました。それにもかかわらず、それは他の非IPトランスポートスキームに使用できます。これらの非IPスキームへのCPPの適用性を評価することは、このドキュメントの範囲外です。
This document covers both unicast and multicast connectivity services. Both Any-Source Multicast (ASM, [RFC1112]) and Source-Specific Multicast (SSM, [RFC4607]) modes can be captured in a CPP.
このドキュメントでは、ユニキャストとマルチキャストの両方の接続サービスについて説明します。 Any-Source Multicast（ASM、[RFC1112]）モードとSource-Specific Multicast（SSM、[RFC4607]）モードの両方をCPPでキャプチャできます。
A CPP can be seen as the inventory of connectivity provisioning requirements with regard to the IP transfer service. CPP clauses are elaborated in the following sub-sections. The CPP template is provided in Section 4.
CPPは、IP転送サービスに関する接続プロビジョニング要件の一覧と見なすことができます。 CPP条項については、次のサブセクションで詳しく説明します。 CPPテンプレートはセクション4で提供されています。
A CPP must include the list of Customer Nodes (e.g., Customer Edges (CEs)) to be connected to the underlying IP transport network.
CPPには、基盤となるIPトランスポートネットワークに接続するカスタマーノード（カスタマーエッジ（CE）など）のリストを含める必要があります。
These nodes should be unambiguously identified (e.g., using a unique Service_identifier, Media Access Control (MAC) addresses, etc.). For each Customer Node, a border link or a node that belongs to the domain that connects the Customer Nodes should be identified.
これらのノードは明確に識別される必要があります（たとえば、一意のService_identifier、メディアアクセス制御（MAC）アドレスなどを使用して）。カスタマーノードごとに、ボーダーリンクまたはカスタマーノードを接続するドメインに属するノードを識別する必要があります。
This clause can specify geolocation information of Customer Nodes.
この句は、顧客ノードの地理位置情報を指定できます。
Based on the location of the Customer Node, appropriate operations to retrieve the corresponding border link or "Provider Node" (e.g., PE) should be undertaken. This operation can be manual or automated.
カスタマーノードの場所に基づいて、対応するボーダーリンクまたは「プロバイダーノード」（PEなど）を取得する適切な操作を実行する必要があります。この操作は手動でも自動でも可能です。
A "service site" would be located behind a given Customer Node. A site identifier may be captured in the CPP for the provisioning of managed VPN services [RFC4026], for instance, Site_identifier.
「サービスサイト」は、特定のカスタマーノードの背後に配置されます。管理されたVPNサービス[RFC4026]のプロビジョニングのために、サイト識別子をCPPに取り込むことができます（例：Site_identifier）。
A Customer Node may be connected to several Provider Nodes. Multiple Customer Nodes may be connected to the same Provider Node as shown in Figure 4.
カスタマーノードは複数のプロバイダーノードに接続できます。図4に示すように、複数のカスタマーノードを同じプロバイダーノードに接続できます。
The scope clause specifies the reachability of each of the involved Customer Nodes, from both incoming and outgoing traffic perspectives, thereby yielding specific traffic directionality considerations. It is defined as an unidirectional parameter. Both directions should be described in the CPP.
スコープ句は、着信および発信トラフィックの両方の観点から、関連する各カスタマーノードの到達可能性を指定します。これにより、特定のトラフィックの方向性に関する考慮事項が得られます。これは、単方向パラメーターとして定義されます。 CPPには両方向を記載する必要があります。
The reachability scope specifies the set of destination prefixes that can be reached from a given Customer site (identified by a group of source prefixes). Both global and restricted reachability scopes can be captured in the CPP. A global reachability scope means that a Customer site can reach any destination in the Internet and can be reached from any remote host. A restricted reachability scope means no global reachability is allowed; only a set of destinations can be reached from a Customer site, and/or only a set of sources can reach the Customer site. Both incoming and outgoing reachability scopes are specified in the CPP.
到達可能性スコープは、特定のカスタマーサイトから到達できる一連の宛先プレフィックスを指定します（ソースプレフィックスのグループによって識別されます）。 CPPでは、グローバルと制限付きの両方の到達可能性スコープをキャプチャできます。グローバルな到達可能性スコープとは、顧客サイトがインターネット内の任意の宛先に到達でき、任意のリモートホストから到達できることを意味します。到達可能性の範囲が制限されていると、グローバルな到達可能性は許可されません。カスタマーサイトから到達できる宛先のセット、および/またはカスタマーサイトに到達できるソースのセットのみ。着信と発信の両方の到達可能性スコープがCPPで指定されています。
Both IPv4 and IPv6 reachability scopes may be specified.
IPv4とIPv6の両方の到達可能性スコープを指定できます。
The reachability scope clause can include multicast and/or unicast addresses. For SSM, a group of unicast source addresses can be specified in addition to destination multicast addresses.
到達可能性スコープ句には、マルチキャストアドレスまたはユニキャストアドレス、あるいはその両方を含めることができます。 SSMの場合、宛先マルチキャストアドレスに加えて、ユニキャスト送信元アドレスのグループを指定できます。
The scope clause can also be used to delimit a topological (or geographical) network portion beyond which the performance and availability guarantees do not apply. A scope may be defined by a set of "Ingress" points and "Egress" points. Several types may be considered, such as:
スコープ句は、トポロジー（または地理的）ネットワーク部分を区切るためにも使用できます。この部分を超えると、パフォーマンスと可用性の保証は適用されません。スコープは、一連の「入口」ポイントと「出口」ポイントで定義できます。次のようないくつかのタイプが考えられます。
(1) "1:1" Pipe model. Only point-to-point communications are allowed.
（1） "1：1"パイプモデル。ポイントツーポイント通信のみが許可されています。
(2) "1:N" Hose model. Only communications from one site towards a set of destinations are allowed.
（2）「1：N」ホースモデル。 1つのサイトから一連の宛先への通信のみが許可されます。
(3) "1:any" Unspecified hose model. All outbound communications are allowed.
（3）「1：any」不特定ホースモデル。すべての発信通信が許可されます。
The Ingress and Egress points could be Customer Nodes / Provider Nodes or external nodes, provided that these nodes are unambiguously identified (e.g., IPv6 prefix), or a set of IP destinations.
イングレスポイントとエグレスポイントは、カスタマーノード/プロバイダーノードまたは外部ノードである可能性があります。これらのノードが明確に識別されている場合（IPv6プレフィックスなど）、またはIP宛先のセットです。
QoS guarantees denote a set of IP transfer performance metrics that characterize the quality of the IP transfer treatment to be experienced (when crossing an IP transport infrastructure) by a flow issued from or forwarded to a (set of) "Customer Node(s)".
QoS保証は、「（一連の）「顧客ノード」から発行または転送されたフローによって（IPトランスポートインフラストラクチャを通過するときに）経験されるIP転送処理の品質を特徴付ける一連のIP転送パフォーマンスメトリックを示します。 。
IP performance metrics can be expressed as qualitative or quantitative parameters (both quantitative and qualitative guarantees cannot be specified in the same CPP). Quantitative guarantees may be specified as an average value, as a maximum bound, or as a percentile over an interval of measurements that should be indicated in the measurement method.
IPパフォーマンスメトリックは、質的または量的パラメーターとして表現できます（量的および質的保証の両方を同じCPPで指定することはできません）。定量的保証は、平均値として、最大範囲として、または測定方法で示される必要がある測定の間隔にわたるパーセンタイルとして指定できます。
Several performance metrics have been defined, such as:
次のようないくつかのパフォーマンスメトリックが定義されています。
o Traffic Loss [RFC2680]
o トラフィックの損失[RFC2680]
o One-way delay [RFC2679]
o 一方向の遅延[RFC2679]
o One-way delay variation [RFC3393]
o 一方向の遅延変動[RFC3393]
These parameters may be specific to a given path or a given scope (e.g., between two Customer Nodes). IP performance metric values indicated in a CPP should reflect the measurement between a set of Customer Nodes or between a Customer Node and a set of Provider Nodes.
これらのパラメータは、特定のパスまたは特定のスコープ（たとえば、2つのカスタマーノード間の）に固有である場合があります。 CPPで示されるIPパフォーマンスメトリック値は、一連のカスタマーノード間、またはカスタマーノードと一連のプロバイダーノード間の測定値を反映する必要があります。
Quantitative guarantees can only be specified for in-profile traffic (i.e., up to a certain traffic rate). A CPP can include throughput guarantees; when specified, these guarantees are equivalent to quantitative or qualitative loss guarantees.
定量的保証は、プロファイル内トラフィック（つまり、特定のトラフィックレートまで）に対してのみ指定できます。 CPPにはスループットの保証を含めることができます。指定された場合、これらの保証は量的または質的損失保証と同等です。
The Meta-QoS-Class concept can be used when qualitative metrics are used [RFC5160].
Meta-QoS-Classの概念は、定性的なメトリックが使用される場合に使用できます[RFC5160]。
This clause specifies the percentage of the time during which the agreed IP performance guarantees apply. The clause can be expressed as a maximum or an average. The exact meaning of the clause value is defined during the CPP negotiation process.
この句は、合意されたIPパフォーマンス保証が適用される時間の割合を指定します。節は、最大値または平均値として表すことができます。条項の値の正確な意味は、CPPネゴシエーションプロセス中に定義されます。
The guarantees cover both QoS deterioration (i.e., IP transfer service is available, but it is below the agreed performance bounds), physical failures, or service unavailability in general. In order to meet the availability guarantees, several engineering practices may be enforced at the border between the Customer and the Network Provider, such as multi-homing designs.
保証は、QoSの低下（つまり、IP転送サービスは利用可能ですが、合意されたパフォーマンスの限界を下回っています）、物理的な障害、またはサービスの一般的な利用不可の両方を対象としています。可用性の保証を満たすために、マルチホーミング設計など、顧客とネットワークプロバイダーの間の境界でいくつかのエンジニアリング手法が実施される場合があります。
The following mechanisms are provided as examples to show that different technical options may be chosen to meet the service availability objectives:
次のメカニズムは、サービスの可用性の目標を満たすためにさまざまな技術オプションを選択できることを示す例として提供されています。
o When an Interior Gateway Protocol (IGP) instance is running between the "Customer Node" and the "Provider Node", activate a dedicated protocol, such as Bidirectional Forwarding Detection (BFD, [RFC5881][RFC5883]), to control IGP availability and to ensure sub-second IGP adjacency failure detection.
o Interior Gateway Protocol（IGP）インスタンスが「カスタマーノード」と「プロバイダーノード」の間で実行されている場合、双方向転送検出（BFD、[RFC5881] [RFC5883]）などの専用プロトコルをアクティブにして、IGPの可用性と1秒未満のIGP隣接障害検出を確実にするため。
o Use of the Label Switched Path Ping (LSP Ping) capability to detect LSP availability (check whether the LSP is in place or not) [RFC4379][RFC6424][RFC6425][RFC6426][RFC6829].
o ラベルスイッチドパスping（LSP Ping）機能を使用してLSPの可用性を検出します（LSPが配置されているかどうかを確認します）[RFC4379] [RFC6424] [RFC6425] [RFC6426] [RFC6829]。
o Pre-install backup LSPs for fast-reroute purposes when an MPLS network connects Customer Nodes [RFC4090].
o MPLSネットワークがカスタマーノードに接続するときの高速再ルーティングのために、バックアップLSPをプリインストールします[RFC4090]。
o Enable Virtual Router Redundancy Protocol (VRRP, [RFC5798]).
o 仮想ルーター冗長プロトコル（VRRP、[RFC5798]）を有効にします。
o Enable IP Fast Reroute features (e.g., [RFC5286] or [RFC6981]).
o IP Fast Reroute機能を有効にします（[RFC5286]または[RFC6981]など）。
This clause characterizes the required capacity to be provided by the underlying IP transport network. This capacity is bound to a defined "Scope" (see Section 3.2) and IP transfer performance guarantees (see Sections 3.3 and 3.4).
この節は、基礎となるIPトランスポートネットワークによって提供される必要な容量を特徴付けます。この容量は、定義された「スコープ」（セクション3.2を参照）およびIP転送パフォーマンスの保証（セクション3.3および3.4を参照）にバインドされています。
The capacity may be expressed for both traffic directions (i.e., incoming and outgoing) and for every border link. The capacity clause defines the limits of the application of quantitative guarantees.
キャパシティは、両方のトラフィック方向（つまり、着信と発信）とすべてのボーダーリンクに対して表現できます。容量条項は、量的保証の適用の制限を定義します。
It is up to the administrative entity, which manages the IP transport network, to appropriately dimension its network [RFC5136] to meet the capacity requirements expressed in all negotiated CPPs.
IPトランスポートネットワークを管理する管理エンティティは、ネゴシエートされたすべてのCPPで表される容量要件を満たすようにネットワーク[RFC5136]を適切にディメンション化する必要があります。
When capacity information (see Section 3.5) is included in the CPP, requirements for out-of-profile traffic treatment need to be also expressed in the CPP.
キャパシティ情報（セクション3.5を参照）がCPPに含まれている場合、不適合なトラフィック処理の要件もCPPで表現する必要があります。
Shaping/policing filters may be applied so as to assess whether traffic is within the capacity profile or out of profile. Out-of-profile traffic may be discarded or assigned another class (e.g., using Lower Effort Per-Domain Behavior (LE PDB) [RFC3662]).
シェーピング/ポリシングフィルターを適用して、トラフィックがキャパシティプロファイル内にあるか、プロファイル外にあるかを評価できます。プロファイル外のトラフィックは破棄されるか、別のクラスが割り当てられる可能性があります（例：低エフォート型ドメイン単位動作（LE PDB）[RFC3662]を使用）。
Packet MTU conditions may also be indicated in the CPP.
パケットMTU条件もCPPで示される場合があります。
Overall traffic guarantees are defined when the Capacity (Section 3.5) and Conformance Traffic (Section 3.6) clauses are not specified. Or, if they are actually specified, then out-of-profile traffic is assigned another class of service but is not discarded. Such guarantees can only be qualitative delay and/or qualitative loss or throughput guarantees.
全体的なトラフィックの保証は、容量（セクション3.5）および適合トラフィック（セクション3.6）句が指定されていない場合に定義されます。または、実際に指定されている場合、プロファイル外トラフィックには別のサービスクラスが割り当てられますが、破棄されません。このような保証は、質的遅延および/または質的損失またはスループットの保証のみです。
If overall traffic guarantees are not specified, best effort forwarding is implied.
全体的なトラフィックの保証が指定されていない場合は、ベストエフォート転送が暗示されます。
This clause indicates if the traffic issued by or destined to "Customer Nodes" should be isolated when crossing the IP transport network. This clause can also be used to specify additional security protection requirements (including privacy protection requirements).
この句は、IPトランスポートネットワークを通過するときに、「カスタマーノード」が発行または送信するトラフィックを分離する必要があるかどうかを示します。この句は、追加のセキュリティ保護要件（プライバシー保護要件を含む）を指定するためにも使用できます。
This clause can then be translated into VPN policy provisioning information, such as the information pertaining to the activation of dedicated tunnels using IPsec, BGP/MPLS VPN facilities [RFC4364], or a combination thereof. The activation of such features should be consistent with the availability and performance guarantees that have been negotiated.
この句は、IPsec、BGP / MPLS VPNファシリティ[RFC4364]、またはそれらの組み合わせを使用した専用トンネルのアクティブ化に関する情報など、VPNポリシープロビジョニング情報に変換できます。このような機能のアクティブ化は、交渉された可用性とパフォーマンスの保証と一致している必要があります。
To identify the flows that need to be handled within the context of a given CPP, flow identifiers should be indicated in the CPP. Flow identifiers are used for traffic classification purposes. An example of packet classifier is defined in [RFC2475].
特定のCPPのコンテキスト内で処理する必要があるフローを識別するには、フロー識別子をCPPに示す必要があります。フロー識別子は、トラフィック分類の目的で使用されます。パケット分類子の例は、[RFC2475]で定義されています。
A flow identifier may be composed of (but not limited to) the following parameters:
フロー識別子は、次のパラメーターで構成されます（ただし、これらに限定されません）。
o Source IP address,
o 送信元IPアドレス
o Source port number,
o 送信元ポート番号、
o Destination IP address,
o 宛先IPアドレス、
o Destination port number,
o 宛先ポート番号、
o Type of Service (ToS) or Differentiated Services Code Point (DSCP) field,
o Type of Service（ToS）またはDifferentiated Services Code Point（DSCP）フィールド、
o Tail-end tunnel endpoint, or
o テールエンドトンネルエンドポイント、または
o Any combination thereof.
o それらの任意の組み合わせ。
Distinct treatments may be implemented for elastic and non-elastic traffic (e.g., see the "Constraints on traffic" clause defined in [RFC5160]).
エラスティックトラフィックと非エラスティックトラフィックに対して個別の処理を実装できます（たとえば、[RFC5160]で定義されている「トラフィックの制約」の項を参照してください）。
Flow classification rules may be specific to a given link or may be applied for a group or all border links. This should be clearly captured in the CPP.
フロー分類ルールは、特定のリンクに固有である場合や、グループまたはすべての境界リンクに適用される場合があります。これは、CPPで明確に把握する必要があります。
Some practices such as DSCP re-marking may be indicated in the CPP. Re-marking action is under the responsibility of underlying nodes that intervene to deliver the connectivity service. Re-marking can be enforced for both outgoing and incoming traffic received from or destined to Customer Nodes. These re-marking actions must not alter the service-specific marking integrity (e.g., VPN service).
DSCPの再マーキングなどの一部のプラクティスは、CPPで示される場合があります。再マーキングアクションは、接続サービスを提供するために介入する基本ノードの責任の下にあります。顧客ノードから受信した、または顧客ノード宛ての発信トラフィックと着信トラフィックの両方に再マーキングを実施できます。これらの再マーキングアクションは、サービス固有のマーキングの整合性（VPNサービスなど）を変更してはなりません。
This clause may specify policies (e.g., DSCP re-marking) to be enforced at the egress nodes on packets received from Customer Nodes. If no such policy is specified, the Network Provider enforces its local policies (e.g., clear DSCP marking) on packets leaving its administrative domain.
この節では、カスタマーノードから受信したパケットの出力ノードで適用されるポリシー（DSCP再マーキングなど）を指定できます。そのようなポリシーが指定されていない場合、ネットワークプロバイダーは、管理ドメインから出て行くパケットにローカルポリシー（DSCPマーキングのクリアなど）を適用します。
This clause is used to specify outsourced routing actions, such as installing dedicated routes to convey the traffic to its (service) destination. These dedicated routes may be computed, selected, and installed for Traffic Engineering or resilience purposes. For Traffic Engineering, these paths can be used to intelligently divert traffic away from some nodes/links that may potentially suffer from congestion or avoid crossing competitors' networks. For resilience, backup paths are typically pre-installed in order to bypass nodes/ links under protection.
この節は、トラフィックを（サービス）宛先に伝達するための専用ルートをインストールするなど、外部委託ルーティングアクションを指定するために使用されます。これらの専用ルートは、トラフィックエンジニアリングまたは回復力の目的で計算、選択、およびインストールできます。トラフィックエンジニアリングでは、これらのパスを使用して、トラフィックをインテリジェントに迂回させて、輻輳の影響を受ける可能性のある一部のノード/リンクからトラフィックを迂回させたり、競合他社のネットワークとの交差を回避したりできます。回復力のために、バックアップパスは通常、保護されているノード/リンクをバイパスするために事前にインストールされています。
This clause is also used to specify intermediate functions that must be invoked in the forwarding path (e.g., redirect the traffic to a firewall, invoke topology hiding features, etc.) or specify geographic routing restrictions.
この句は、転送パスで呼び出す必要がある中間機能を指定する（トラフィックをファイアウォールにリダイレクトする、トポロジ非表示機能を呼び出すなど）か、地理的なルーティング制限を指定するためにも使用されます。
A requirement for setting up a logical routing topology [RFC4915] [RFC5120] may also be considered, e.g., to facilitate the management of the nodes that are involved in the forwarding of the traffic as defined in the CPP.
論理ルーティングトポロジー[RFC4915] [RFC5120]をセットアップするための要件も、たとえば、CPPで定義されているトラフィックの転送に関与するノードの管理を容易にするために考慮されます。
This practice should be indicated in the CPP; otherwise, path computation is left to the underlying IP routing capabilities. The forwarding behavior (e.g., Per-Domain Behavior (PDB) [RFC3086]) may also be specified in a CPP but remains optional. If indicated, consistency with the IP performance bounds defined in the CPP should be carefully ensured.
この慣行はCPPに示されるべきである。それ以外の場合、パスの計算は基礎となるIPルーティング機能に任されます。転送動作（ドメインごとの動作（PDB）[RFC3086]など）もCPPで指定できますが、オプションのままです。示されている場合は、CPPで定義されているIPパフォーマンスの範囲との整合性を慎重に確保する必要があります。
For illustration purposes, a routing policy would avoid satellite links for Voice over IP (VoIP) deployments since this may degrade the offered service.
説明のために、ルーティングポリシーでは、Voice over IP（VoIP）展開のサテライトリンクを回避します。これにより、提供されるサービスが低下する可能性があるためです。
This clause indicates the required action(s) to be undertaken to activate access to the IP connectivity service.
この節は、IP接続サービスへのアクセスをアクティブにするために必要なアクションを示します。
Examples of these actions would be the activation of an IGP instance, the establishment of a BGP [RFC4271] or Multiprotocol BGP (MP-BGP) session [RFC4760], Protocol Independent Multicast (PIM, [RFC4601]), etc.
これらのアクションの例は、IGPインスタンスのアクティブ化、BGP [RFC4271]またはマルチプロトコルBGP（MP-BGP）セッションの確立[RFC4760]、プロトコル独立マルチキャスト（PIM、[RFC4601]）などです。
Two types are defined:
2つのタイプが定義されています。
Implicit: This clause indicates that no explicit means to invoke the connectivity service is required. Access to the connectivity service is primarily conditioned by the requested network capacity.
暗黙的：この節は、接続サービスを呼び出す明示的な手段が必要ないことを示します。接続サービスへのアクセスは、主に要求されたネットワーク容量によって調整されます。
Explicit: This clause indicates the need for explicit means to access the connectivity service. Examples of such means include the use of RSVP [RFC2205], RSVP-TE [RFC3209], Internet Group Management Protocol (IGMP, [RFC3376]), or Multicast Listener Discovery (MLD, [RFC3810]). Appropriate admission control procedures [RFC6601] would have to be enforced, e.g., to check whether the capacity actually used is not above the agreed threshold.
明示的：この句は、接続サービスにアクセスするための明示的手段の必要性を示します。そのような手段の例には、RSVP [RFC2205]、RSVP-TE [RFC3209]、インターネットグループ管理プロトコル（IGMP、[RFC3376]）、またはマルチキャストリスナーディスカバリ（MLD、[RFC3810]）の使用が含まれます。たとえば実際に使用された容量が合意されたしきい値を超えていないかどうかを確認するために、適切なアドミッションコントロール手順[RFC6601]を実施する必要があります。
For operation purposes (e.g., supervision) and service fulfillment needs, management platforms need to be notified about critical events that may impact the delivery of the service.
運用目的（監視など）およびサービス実行のニーズのために、サービスの提供に影響を与える可能性のある重要なイベントについて管理プラットフォームに通知する必要があります。
The notification procedure should be indicated in the CPP. This procedure may specify the type of information to be sent, the interval, the data model, etc.
通知手順はCPPに示されている必要があります。この手順では、送信する情報のタイプ、間隔、データモデルなどを指定できます。
Notifications can be sent to the management platform by using Simple Network Management Protocol (SNMP, [RFC3416]), Syslog notifications [RFC5424], Connectivity Provisioning Negotiation Protocol (CPNP) signals [CPNP], Network Configuration Protocol (NETCONF) Event Notifications [RFC5277], or a phone call!
通知は、シンプルネットワーク管理プロトコル（SNMP、[RFC3416]）、Syslog通知[RFC5424]、接続プロビジョニングネゴシエーションプロトコル（CPNP）信号[CPNP]、ネットワーク構成プロトコル（NETCONF）イベント通知[RFC5277]を使用して管理プラットフォームに送信できます。 ]、または電話！
Figure 6 provides the Routing Backus-Naur Form (RBNF, [RFC5511]) format of the CPP template.
図6は、CPPテンプレートのルーティングBackus-Naurフォーム（RBNF、[RFC5511]）形式を示しています。
A CPP document includes several connectivity provisioning components; each of these is structured as a CPP. The CPP may include additional optional information elements such as metrics used for Service Assurance purposes, activation schedule, etc.
CPPドキュメントには、いくつかの接続プロビジョニングコンポーネントが含まれています。これらはそれぞれCPPとして構成されています。 CPPには、サービス保証の目的で使用されるメトリック、アクティブ化スケジュールなどの追加のオプション情報要素が含まれる場合があります。
<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<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>
<Optional Information Element> ...
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALIZATION>
Figure 6: CPP Template
図6：CPPテンプレート
The description of these clauses is provided in Section 3.
これらの句の説明は、セクション3に記載されています。
The CPP may also include a Customer's administrative information, such as a name and other contact details. An example of the RBNF format of the Customer's information is shown in Figure 7.
CPPには、名前やその他の連絡先の詳細など、お客様の管理情報も含まれる場合があります。お客様の情報のRBNF形式の例を図7に示します。
<Customer Description> ::= <NAME> <Contact Information>
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 7: Customer Description Clause
図7：顧客記述句
The CPP may include administrative information of the Network Provider too (name, Autonomous System number(s), and other contact details). An example of the RBNF format of the provider's information is shown in Figure 8.
CPPには、ネットワークプロバイダーの管理情報（名前、自律システム番号、その他の連絡先の詳細）も含まれる場合があります。プロバイダーの情報のRBNF形式の例を図8に示します。
<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 8: Provider Description Clause
図8：プロバイダーの説明句
This document does not define an architecture or specify a protocol. Yet, the means to provide guarantees about the identity of a Customer and its ability to expose connectivity requirements to a Network Provider through a CPP need to be investigated. Likewise, the means to provide guarantees about the identity of a Network Provider and the ability to expose its capabilities, let alone capture the requirements of a Customer through a CPP, should be carefully studied.
このドキュメントでは、アーキテクチャを定義したり、プロトコルを指定したりしていません。ただし、顧客のIDと、CPPを介して接続要件をネットワークプロバイダーに公開するその機能について保証を提供する手段を調査する必要があります。同様に、ネットワークプロバイダーのIDとその機能を公開する機能を保証する手段は、CPPを通じて顧客の要件を取得することはもちろんのこと、慎重に検討する必要があります。
CPP documents should be protected against illegitimate modifications (e.g., modification, withdrawal); authorization means should be enabled. These means are deployment-specific.
CPP文書は、違法な変更（変更、撤回など）から保護する必要があります。承認手段を有効にする必要があります。これらの手段はデプロイメント固有です。
The Network Provider must enforce means to protect privacy-related information captured in a CPP document [RFC6462]. In particular, this information must not be revealed to external parties without the consent of Customers. Network Providers should enforce policies to make Customer fingerprinting more difficult to achieve. For more discussion about privacy, refer to [RFC6462] and [RFC6973].
ネットワークプロバイダーは、CPPドキュメント[RFC6462]でキャプチャされたプライバシー関連情報を保護する手段を実施する必要があります。特に、この情報をお客様の同意なしに外部の第三者に公開してはなりません。ネットワークプロバイダーは、顧客のフィンガープリント作成をより困難にするポリシーを実施する必要があります。プライバシーの詳細については、[RFC6462]および[RFC6973]を参照してください。
Some of the items in this document are the result of several discussions with E. Mykoniati and D. Griffin. Special thanks to them.
このドキュメントの項目のいくつかは、E。MykoniatiおよびD. Griffinとのいくつかの議論の結果です。彼らに感謝します。
Many thanks to P. Georgatsos for the discussions and the detailed review of this document.
この文書の議論と詳細なレビューをしてくれたP. Georgatsosに感謝します。
Thanks to S. Shah, G. Huston, D. King, and S. Bryant for reviewing the document and providing useful comments.
ドキュメントをレビューし、有用なコメントを提供してくれたS. Shah、G。Huston、D。King、およびS. Bryantに感謝します。
[CPNP] Boucadair, M., Jacquenet, C., and D. Zhang, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, June 2014.
[CPNP] Boucadair、M.、Jacquenet、C。、およびD. Zhang、「Connectivity Provisioning Negotiation Protocol（CPNP）」、Work in Progress、2014年6月。
[NET-OPS] King, D. and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, February 2014.
[NET-OPS]キング、D。、およびA.ファレル、「アプリケーションベースのネットワーク運用のためのPCEベースのアーキテクチャ」、進行中の作業、2014年2月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの片方向パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000.
[RFC2805] Greene、N.、Ramalho、M。、およびB. Rosen、「Media Gateway Control Protocol Architecture and Requirements」、RFC 2805、2000年4月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086] Nichols、K.およびB. Carpenter、「Definition of Differentiated Services Per Domain Behavior Behaviors and Rules for their Specification」、RFC 3086、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[RFC3346] Boyle、J.、Gill、V.、Hannan、A.、Cooper、D.、Awduche、D.、Christian、B。、およびW. Lai、「MPLSによるトラフィックエンジニアリングの適用性に関する声明」、RFC 3346 、2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミケリス、CおよびP.キメント、「IPパフォーマンスメトリックのIPパケット遅延変動メトリック（IPPM）」、RFC 3393、2002年11月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R。、「Version 2 of the Protocol Operations for the Simple Network Management Protocol（SNMP）」、STD 62、RFC 3416、2002年12月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662] Bless、R.、Nichols、K。、およびK. Wehrle、「Differentiated Servicesのドメインごとの動作（PDB）の削減」、RFC 3662、2003年12月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L.およびT. Madsen、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、2005年3月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、スワロー、G。、およびA.アトラス、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「ソース固有のIPマルチキャスト」、RFC 4607、2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、2007年6月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、2008年2月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5136] Chimento、P。およびJ. Ishac、「Defining Network Capacity」、RFC 5136、2008年2月。
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, March 2008.
[RFC5160] Levis、P。およびM. Boucadair、「インターネットスケールのサービスの品質（QoS）に関するプロバイダー間の契約の考慮事項」、RFC 5160、2008年3月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、2008年7月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286] Atlas、A。およびA. Zinin、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、2009年4月。
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798] Nadas、S。、「Virtual Router Redundancy Protocol（VRRP）Version 3 for IPv4 and IPv6」、RFC 5798、2010年3月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments from Requirements」、RFC 5853、4月2010。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）for IPv4 and IPv6（Single Hop）」、RFC 5881、2010年6月。
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC5883] Katz、D。およびD. Ward、「マルチホップパスの双方向転送検出（BFD）」、RFC 5883、2010年6月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424] Bahadur、N.、Kompella、K。、およびG. Swallow、「MPLSトンネルを介したラベルスイッチドパスPing（LSP Ping）の実行メカニズム」、RFC 6424、2011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Swallow、G.、Ali、Z.、Farrel、A。、安川S、およびT. Nadeau、「ポイントツーマルチポイントMPLSでのデータプレーン障害の検出-LSPの拡張Ping」、RFC 6425、2011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6462]クーパー、A。、「インターネットプライバシーワークショップからの報告」、RFC 6462、2012年1月。
[RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", RFC 6601, April 2012.
[RFC6601] Ash、G。およびD. McDysan、「IP / MPLSネットワーク用のGeneric Connection Admission Control（GCAC）アルゴリズム仕様」、RFC 6601、2012年4月。
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013.
[RFC6829] Chen、M.、Pan、P.、Pignataro、C。、およびR. Asati、「IPv6経由でアドバタイズされる疑似回線転送等価クラス（FEC）のラベルスイッチドパス（LSP）ping」、RFC 6829、2013年1月。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、7月2013。
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, August 2013.
[RFC6981] Bryant、S.、Previdi、S。、およびM. Shand、「Not-Viaアドレスを使用したIPおよびMPLS高速リルートのフレームワーク」、RFC 6981、2013年8月。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014.
[RFC7149] Boucadair、M。およびC. Jacquenet、「Software-Defined Networking：A Perspective from within a Service Provider Environment」、RFC 7149、2014年3月。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Christian Jacquenet France Telecom Rennes 35000 France
Christian Jacquenet France Telecom Rennes 35000フランス
EMail: christian.jacquenet@orange.com
Ning Wang University of Surrey Guildford UK
寧王サリー大学ギルフォード校
EMail: n.wang@surrey.ac.uk