summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7297.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7297.txt')
-rw-r--r--doc/rfc/rfc7297.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7297.txt b/doc/rfc/rfc7297.txt
new file mode 100644
index 0000000..a8bc4e8
--- /dev/null
+++ b/doc/rfc/rfc7297.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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)
+
+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.
+
+ 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.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 1]
+
+RFC 7297 CPP July 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 2]
+
+RFC 7297 CPP July 2014
+
+
+1. Introduction
+
+ 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).
+
+ 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.
+
+1.1. Connectivity Provisioning Interface (CPI)
+
+ 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).
+
+ +---------+
+ |Service A|
+ +---+-----+
+ | +---------+
+ |CPI |Service B|
+ | +-+-------+
+ | |CPI
+ +----------+ +-+------+-------+ +------------+
+ | Customer |-----|Network Provider|-----|Peer Network|
+ +----------+ CPI +----------------+ CPI +------------+
+
+ Figure 1: Connectivity Provisioning Interfaces
+
+ The interfaces depicted in Figure 1 can be summarized as shown in
+ Figure 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
+
+
+
+Boucadair, et al. Informational [Page 3]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+ +----------------+
+ | Customer |
+ +-------+--------+
+ + CPI
+ +-------+--------+
+ |Network Provider|
+ +----------------+
+
+ Figure 2: CPP: Generic Connectivity Provisioning Interfaces
+
+ 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).
+
+1.2. Rationale
+
+ 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.
+
+ 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.).
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 4]
+
+RFC 7297 CPP July 2014
+
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 5]
+
+RFC 7297 CPP July 2014
+
+
+ Such a generic CPP template:
+
+ o Facilitates the automation of the service negotiation and
+ activation procedures, thus improving service delivery times;
+
+ 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 Improves service and network management systems by adding
+ 'decision-making' capabilities based upon negotiated/offered CPPs.
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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].
+
+
+
+
+Boucadair, et al. Informational [Page 6]
+
+RFC 7297 CPP July 2014
+
+
+1.3. Reference Architecture
+
+ 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.
+
+ The CPP reference architectures are depicted in Figures 3, 4, and 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 '.-.
+ ( )
+ ( . . . . . .)
+ '.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
+
+ Figure 3: Reference Architecture: Connectivity Service Provided by
+ the Same Network Provider Using Distinct Interconnection Nodes
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 7]
+
+RFC 7297 CPP July 2014
+
+
+ .--. .--.. .--..--.
+ ( '.--.
+ .-.' 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
+
+ .--. .--.. .--..--.
+ ( '.--.
+ .-.' 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
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 8]
+
+RFC 7297 CPP July 2014
+
+
+2. Scope of This Document
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+3. Connectivity Provisioning Profile (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.
+
+3.1. Customer Nodes Map
+
+ A CPP must include the list of Customer Nodes (e.g., Customer Edges
+ (CEs)) to be connected to the underlying IP transport network.
+
+ 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.
+
+ 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.
+
+
+
+Boucadair, et al. Informational [Page 9]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+ 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.
+
+3.2. Scope
+
+ 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.
+
+ 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.
+
+ Both IPv4 and IPv6 reachability scopes may be specified.
+
+ 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.
+
+ 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.
+
+ (2) "1:N" Hose model. Only communications from one site towards a
+ set of destinations are allowed.
+
+ (3) "1:any" Unspecified hose model. All outbound communications are
+ allowed.
+
+
+
+
+Boucadair, et al. Informational [Page 10]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+3.3. QoS Guarantees
+
+ 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)".
+
+ 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.
+
+ Several performance metrics have been defined, such as:
+
+ o Traffic Loss [RFC2680]
+
+ o One-way delay [RFC2679]
+
+ o One-way delay variation [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.
+
+ 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.
+
+ The Meta-QoS-Class concept can be used when qualitative metrics are
+ used [RFC5160].
+
+3.4. Availability
+
+ 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.
+
+
+
+
+
+Boucadair, et al. Informational [Page 11]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+ 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 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 Pre-install backup LSPs for fast-reroute purposes when an MPLS
+ network connects Customer Nodes [RFC4090].
+
+ o Enable Virtual Router Redundancy Protocol (VRRP, [RFC5798]).
+
+ o Enable IP Fast Reroute features (e.g., [RFC5286] or [RFC6981]).
+
+3.5. Capacity
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 12]
+
+RFC 7297 CPP July 2014
+
+
+3.6. Conformance Traffic
+
+ 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.
+
+ 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]).
+
+ Packet MTU conditions may also be indicated in the CPP.
+
+3.7. Overall Traffic Guarantees
+
+ 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.
+
+ If overall traffic guarantees are not specified, best effort
+ forwarding is implied.
+
+3.8. Traffic Isolation
+
+ 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).
+
+ 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.
+
+3.9. Flow Identification
+
+ 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].
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 13]
+
+RFC 7297 CPP July 2014
+
+
+ A flow identifier may be composed of (but not limited to) the
+ following parameters:
+
+ o Source IP address,
+
+ o Source port number,
+
+ o Destination IP address,
+
+ o Destination port number,
+
+ o Type of Service (ToS) or Differentiated Services Code Point (DSCP)
+ field,
+
+ o Tail-end tunnel endpoint, or
+
+ o Any combination thereof.
+
+ Distinct treatments may be implemented for elastic and non-elastic
+ traffic (e.g., see the "Constraints on traffic" clause defined in
+ [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.
+
+ 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).
+
+ 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.
+
+3.10. Routing and Forwarding
+
+ 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
+
+
+
+
+Boucadair, et al. Informational [Page 14]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+ 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.
+
+ For illustration purposes, a routing policy would avoid satellite
+ links for Voice over IP (VoIP) deployments since this may degrade the
+ offered service.
+
+3.11. Activation Means
+
+ This clause indicates the required action(s) to be undertaken to
+ activate access to the IP connectivity service.
+
+ 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.
+
+3.12. Invocation Means
+
+ 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.
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 15]
+
+RFC 7297 CPP July 2014
+
+
+ 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.
+
+3.13. Notifications
+
+ 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.
+
+ 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!
+
+4. CPP Template
+
+ Figure 6 provides the Routing Backus-Naur Form (RBNF, [RFC5511])
+ format of the CPP template.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 16]
+
+RFC 7297 CPP July 2014
+
+
+ <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
+
+ The description of these clauses is provided in Section 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.
+
+ <Customer Description> ::= <NAME> <Contact Information>
+ <Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
+ [<TELEPHONE_NUMBER> ...]
+
+ Figure 7: Customer Description Clause
+
+ 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.
+
+ <Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
+ <Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
+ [<TELEPHONE_NUMBER> ...]
+
+ Figure 8: Provider Description Clause
+
+
+
+Boucadair, et al. Informational [Page 17]
+
+RFC 7297 CPP July 2014
+
+
+5. Security Considerations
+
+ 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 documents should be protected against illegitimate modifications
+ (e.g., modification, withdrawal); authorization means should be
+ enabled. These means are deployment-specific.
+
+ 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].
+
+6. Acknowledgements
+
+ Some of the items in this document are the result of several
+ discussions with E. Mykoniati and D. Griffin. Special thanks to
+ them.
+
+ Many thanks to P. Georgatsos for the discussions and the detailed
+ review of this document.
+
+ Thanks to S. Shah, G. Huston, D. King, and S. Bryant for reviewing
+ the document and providing useful comments.
+
+7. Informative References
+
+ [CPNP] Boucadair, M., Jacquenet, C., and D. Zhang, "Connectivity
+ Provisioning Negotiation Protocol (CPNP)", Work in
+ Progress, June 2014.
+
+ [NET-OPS] King, D. and A. Farrel, "A PCE-based Architecture for
+ Application-based Network Operations", Work in Progress,
+ February 2014.
+
+ [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
+ RFC 1112, August 1989.
+
+
+
+
+
+Boucadair, et al. Informational [Page 18]
+
+RFC 7297 CPP July 2014
+
+
+ [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+ Functional Specification", RFC 2205, September 1997.
+
+ [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+ and W. Weiss, "An Architecture for Differentiated
+ Services", RFC 2475, December 1998.
+
+ [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+ Delay Metric for IPPM", RFC 2679, September 1999.
+
+ [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+ Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+ [RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway
+ Control Protocol Architecture and Requirements", RFC 2805,
+ April 2000.
+
+ [RFC3086] Nichols, K. and B. Carpenter, "Definition of
+ Differentiated Services Per Domain Behaviors and Rules for
+ their Specification", RFC 3086, April 2001.
+
+ [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.
+
+ [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.
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version
+ 3", RFC 3376, October 2002.
+
+ [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
+ Metric for IP Performance Metrics (IPPM)", RFC 3393,
+ November 2002.
+
+ [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
+ Simple Network Management Protocol (SNMP)", STD 62, RFC
+ 3416, December 2002.
+
+ [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
+ Per-Domain Behavior (PDB) for Differentiated Services",
+ RFC 3662, December 2003.
+
+ [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
+ Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+
+
+Boucadair, et al. Informational [Page 19]
+
+RFC 7297 CPP July 2014
+
+
+ [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
+ Private Network (VPN) Terminology", RFC 4026, March 2005.
+
+ [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+ Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
+ 2005.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+ Networks (VPNs)", RFC 4364, February 2006.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+ Label Switched (MPLS) Data Plane Failures", RFC 4379,
+ February 2006.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601, August 2006.
+
+ [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
+ IP", RFC 4607, August 2006.
+
+ [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+ "Multiprotocol Extensions for BGP-4", RFC 4760, January
+ 2007.
+
+ [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
+ Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
+ 4915, June 2007.
+
+ [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.
+
+ [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
+ RFC 5136, February 2008.
+
+ [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
+ to-Provider Agreements for Internet-Scale Quality of
+ Service (QoS)", RFC 5160, March 2008.
+
+ [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
+ Notifications", RFC 5277, July 2008.
+
+ [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
+ Reroute: Loop-Free Alternates", RFC 5286, September 2008.
+
+
+
+Boucadair, et al. Informational [Page 20]
+
+RFC 7297 CPP July 2014
+
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
+
+ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+ Used to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, April 2009.
+
+ [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
+ Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
+
+ [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.
+
+ [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+ (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
+ 2010.
+
+ [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+ (BFD) for Multihop Paths", RFC 5883, June 2010.
+
+ [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
+ Performing Label Switched Path Ping (LSP Ping) over MPLS
+ Tunnels", RFC 6424, November 2011.
+
+ [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.
+
+ [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
+ On-Demand Connectivity Verification and Route Tracing",
+ RFC 6426, November 2011.
+
+ [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
+ RFC 6462, January 2012.
+
+ [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission
+ Control (GCAC) Algorithm Specification for IP/MPLS
+ Networks", RFC 6601, April 2012.
+
+ [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.
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 21]
+
+RFC 7297 CPP July 2014
+
+
+ [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.
+
+ [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
+ and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
+ August 2013.
+
+ [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
+ Networking: A Perspective from within a Service Provider
+ Environment", RFC 7149, March 2014.
+
+Authors' Addresses
+
+ Mohamed Boucadair
+ France Telecom
+ Rennes 35000
+ France
+
+ EMail: mohamed.boucadair@orange.com
+
+
+ Christian Jacquenet
+ France Telecom
+ Rennes 35000
+ France
+
+ EMail: christian.jacquenet@orange.com
+
+
+ Ning Wang
+ University of Surrey
+ Guildford
+ UK
+
+ EMail: n.wang@surrey.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 22]
+