Independent Submission M. Boucadair
Request for Comments: 7297 C. Jacquenet
Category: Informational France Telecom
ISSN: 2070-1721 N. Wang
University of Surrey
July 2014
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），并提出了一个CPP模板，用于捕获服务交付上下文（如IP语音或IP电视）中要满足的IP/MPLS连接要求。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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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
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），并提出了一个CPP模板，用于捕获服务交付上下文（如IP语音、IP电视和VPN服务）中要满足的IP/MPLS连接要求。
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连接服务是以（源网络、目标网络、保证、范围）元组为特征的IP传输能力，其中“源网络”是一组单播IP地址，“目标网络”是一组IP单播和/或多播地址，“保证”反映了保证（例如，以服务质量（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 +------------+
+---------+
|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
图2中所示的客户可能是另一个网络提供商（例如，IP传输提供商）、需要调用网络提供商提供的资源的服务提供商（例如，IP电话服务提供商）或希望互连的企业
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.
通过订阅由网络提供商提供的VPN服务，它可以访问不同的站点。建议的CPP可用于公开、捕获和促进这些不同实体之间的服务参数协商，从而提供用于描述可用连接性服务的公共模板。
+----------------+
| Customer |
+-------+--------+
+ CPI
+-------+--------+
|Network Provider|
+----------------+
+----------------+
| 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接口旨在以技术无关的方式公开和描述在一组客户节点（例如，多媒体网关（RFC2805的第11.2.7节）、会话边界控制器[RFC5853]等）之间调用由网络提供商操作的网络的IP传输能力时要满足的IP传输要求.
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]）、开放最短路径优先（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.
因此，应推荐应用程序无关的IP供应实践，因为CPP中捕获的需求可用于确定将使用哪种网络服务类别来满足这些需求/保证。从这个角度来看，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传输能力被高层服务（如传输层和应用层服务）视为黑盒。适当的通知和报告将（通过专用方式）传达给客户节点，以评估经验丰富的IP传输服务是否符合与相应CPP协商的内容。这些通知还可用于评估网络基础设施中实施的各种策略的效率，以满足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.
客户基础设施可以通过一个或多个网络提供商管理的网络基础设施进行连接。
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node |.--. .--.. . |Provider Node |
+--------------+ +--------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
.--. .--.. .--..--.
( '.--.
.-.' 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 '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
.--. .--.. .--..--.
( '.--.
.-.' 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 '.-.
( ) ( )
(. . . .) (. . . .)
'.-_-.'.-_-._..' '.-_-.'.-_-._..'
.--. .--.. .--..--.
( '.--.
.-.' 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传输方案。评估CPP对这些非IP计划的适用性超出了本文件的范围。
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.
本文档涵盖单播和多播连接服务。任何源多播（ASM，[RFC1112]）和源特定多播（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条款。第4节提供了CPP模板。
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.
这些节点应明确标识（例如，使用唯一的服务标识符、媒体访问控制（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.
“服务站点”将位于给定客户节点的后面。可在CPP中捕获站点标识符以用于提供托管VPN服务[RFC4026]，例如，站点标识符。
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.
scope子句从传入和传出流量的角度指定每个相关客户节点的可达性，从而产生特定的流量方向性考虑。它被定义为一个单向参数。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中捕获。全局可访问范围意味着客户站点可以到达Internet上的任何目的地，并且可以从任何远程主机访问。受限可达范围意味着不允许全局可达；只有一组目的地可以从客户站点到达，和/或只有一组来源可以到达客户站点。传入和传出可达性范围都在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:
scope子句还可用于界定性能和可用性保证不适用的拓扑（或地理）网络部分。范围可以由一组“入口”点和“出口”点定义。可以考虑几种类型，例如：
(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”软管型号。只允许从一个站点到一组目的地的通信。
(3) "1:any" Unspecified hose model. All outbound communications are allowed.
(3) “1：任何”未指定的软管型号。允许所有出站通信。
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.
这些参数可能特定于给定路径或给定范围（例如，两个客户节点之间）。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].
当使用定性指标时，可以使用元QoS类概念[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 当内部网关协议（IGP）实例在“客户节点”和“提供商节点”之间运行时，激活专用协议，如双向转发检测（BFD、[RFC5881][RFC5883]），以控制IGP可用性并确保每秒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 预安装备份LSP，以便在MPLS网络连接客户节点时快速重新路由[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快速重路由功能（例如，[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传输网络的管理实体决定其网络[RFC5136]的适当尺寸，以满足所有协商CPP中表示的容量要求。
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.
然后，可以将该条款转换为VPN策略设置信息，例如与使用IPsec、BGP/MPLS VPN设施[RFC4364]或其组合激活专用隧道有关的信息。此类功能的激活应符合已协商的可用性和性能保证。
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 服务类型（ToS）或差异化服务代码点（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).
CPP中可能会指出一些做法，如DSCP重新标记。重新标记操作由参与提供连接服务的基础节点负责。可以对从客户节点接收或发送到客户节点的传出和传入流量强制执行重新标记。这些重新标记操作不得改变特定于服务的标记完整性（例如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.
出于说明目的，路由策略将避免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:
定义了两种类型：
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]）、系统日志通知[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>
<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> ...]
<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> ...]
<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.
本文档未定义架构或指定协议。然而，需要研究如何保证客户的身份及其通过CPP向网络提供商公开连接需求的能力。同样，应该仔细研究为网络提供商的身份和公开其能力提供保证的方法，更不用说通过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，“连接供应协商协议（CPNP）”，正在进行的工作，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]King，D.和A.Farrel，“基于PCE的应用程序网络运营架构”，进展中的工作，2014年2月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年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，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年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，“差异化服务架构”，RFC 24751998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“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.，Kalidini，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，“媒体网关控制协议架构和要求”，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，“每域区分服务行为的定义及其规范规则”，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：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[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 33462002年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]Demichelis，C.和P.Chimento，“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]Presohn，R.，“简单网络管理协议（SNMP）协议操作的第2版”，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，“区分服务的低域行为（PDB）”，RFC 36622003年12月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，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，“提供商提供的虚拟专用网络（VPN）术语”，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]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年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，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“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，“检测多协议标签交换（MPLS）数据平面故障”，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，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“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：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，2008年2月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5136]Chimento，P.和J.Ishac，“定义网络容量”，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 51602008年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快速重路由的基本规范：无环路交替”，RFC 5286，2008年9月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年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.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，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.，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，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，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[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，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年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 64242011年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.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 64252011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，2011年11月。
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6462]Cooper，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网络的通用连接许可控制（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 68292013年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 69732013年7月。
[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，“使用非经由地址的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，“软件定义的网络：服务提供商环境中的视角”，RFC 7149，2014年3月。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Christian Jacquenet France Telecom Rennes 35000 France
克里斯蒂安·雅克内特法国电信雷恩35000法国
EMail: christian.jacquenet@orange.com
EMail: christian.jacquenet@orange.com
Ning Wang University of Surrey Guildford UK
塞瑞大学王德福分校
EMail: n.wang@surrey.ac.uk
EMail: n.wang@surrey.ac.uk