Skip to main content

IP Connectivity Provisioning Profile (CPP)

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7297.
Authors Mohamed Boucadair , Christian Jacquenet , Ning Wang
Last updated 2014-04-10
RFC stream Independent Submission
IETF conflict review conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile, conflict-review-boucadair-connectivity-provisioning-profile
Stream ISE state In IESG Review
Consensus boilerplate Unknown
Document shepherd Eliot Lear
Shepherd write-up Show Last changed 2014-03-13
IESG IESG state Became RFC 7297 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to
IANA IANA review state IANA OK - No Actions Needed
Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Informational                            France Telecom
Expires: October 12, 2014                                        N. Wang
                                                    University of Surrey
                                                          April 10, 2014

               IP Connectivity Provisioning Profile (CPP)


   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 12, 2014.

Boucadair, et al.       Expires October 12, 2014                [Page 1]
Internet-Draft                     CPP                        April 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
   ( 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Connectivity Provisioning Interface (CPI) . . . . . . . .   3
     1.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Reference Architecture  . . . . . . . . . . . . . . . . .   6
   2.  Scope of this Document  . . . . . . . . . . . . . . . . . . .   8
   3.  Connectivity Provisioning Profile (CPP) . . . . . . . . . . .   9
     3.1.  Customer Nodes  . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  QoS Guarantees  . . . . . . . . . . . . . . . . . . . . .  11
     3.4.  Availability Guarantees . . . . . . . . . . . . . . . . .  11
     3.5.  Capacity  . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.6.  Conformance Traffic . . . . . . . . . . . . . . . . . . .  12
     3.7.  Overall Traffic Guarantees  . . . . . . . . . . . . . . .  13
     3.8.  Traffic Isolation . . . . . . . . . . . . . . . . . . . .  13
     3.9.  Flow Identification . . . . . . . . . . . . . . . . . . .  13
     3.10. Routing & Forwarding  . . . . . . . . . . . . . . . . . .  14
     3.11. Activation Means  . . . . . . . . . . . . . . . . . . . .  15
     3.12. Invocation Means  . . . . . . . . . . . . . . . . . . . .  15
     3.13. Notifications . . . . . . . . . . . . . . . . . . . . . .  15
   4.  CPP Template  . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP/MPLS connectivity

Boucadair, et al.       Expires October 12, 2014                [Page 2]
Internet-Draft                     CPP                        April 2014

   requirements to be met within a service delivery context (e.g., Voice
   over IP, IP TV, 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" are a group of unicast
   IP addresses, "Destination Nets" are a group of IP unicast and/or
   multicast addresses, "Guarantees" reflect the guarantees (expressed
   in terms of QoS (Quality Of Service), performance and availability,
   for example) to properly forward traffic to the said "Destination".
   Finally, the "Scope" denotes the (network) perimeter (e.g., between
   PE (Provider Equipment) 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 Connectivity Provisioning
   Interface, the Service-Network Connectivity Provisioning Interface,
   and the Network-Network Connectivity Provisioning Interface.
   Services and applications whose parameters are captured by means of a
   CPP exchanged through the Service-Network Connectivity Provisioning
   Interface 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
   +----------+     +-+------+-------+     +------------+
   |Subscriber|-----|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) which requires the invocation of resources provided
   by a Network Provider, or an enterprise which wants to interconnect
   its various sites by subscribing to a VPN service provided by a

Boucadair, et al.       Expires October 12, 2014                [Page 3]
Internet-Draft                     CPP                        April 2014

   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 the document, "Customer" is used as a generic term to
   denote the business entity that subscribes to connectivity services
   offered by a Network Provider (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,
   the bilateral discussions that usually take place between a customer
   and a Network Provider hardly rely upon some kind of standard
   checklist, where the customer would be invited to tick all the
   parameters that apply to its environment, and then negotiate these
   parameters 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., Media Gateway (section 11.2.7 [RFC2805]), Session Border
   Controller [RFC5853], etc.).

   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

Boucadair, et al.       Expires October 12, 2014                [Page 4]
Internet-Draft                     CPP                        April 2014

   variation [RFC3393]), protection and high availability guidelines
   (e.g., sub-50ms/sub-100ms/second restoration).

   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., MPLS-TE
   (Multiprotocol Label Switching TE, [RFC3346]), RSVP (Resource
   Reservation Protocol, [RFC2205]), OSPF (Open Shortest Path First) or
   IS-IS (Intermediate System to Intermediate System), 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 at capturing 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 sakes
   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.

   Such a generic CPP template:

   o  Facilitates the automation of the service negotiation and
      activation procedures, thus improving service delivery times;
   o  Can help setting Traffic Engineering function and service
      management function objectives, as a function of the number of CPP

Boucadair, et al.       Expires October 12, 2014                [Page 5]
Internet-Draft                     CPP                        April 2014

      templates to be processed over a specific period of time, for
   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 which 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 which 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 an networking

   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.

   An example of CPP usage is through the northbound interface
   introduced by the Application-based Network Operations (ABNO)
   framework [I-D.farrkingel-pce-abno-architecture] or as a technique
   for exposing network services and their characteristics defined in

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

Boucadair, et al.       Expires October 12, 2014                [Page 6]
Internet-Draft                     CPP                        April 2014

   transfer capability implemented thanks to the allocation of a set of
   IP resources.  IP transfer capabilities are considered by the above
   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 Figure 3, Figure 4,
   and Figure 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.       Expires October 12, 2014                [Page 7]
Internet-Draft                     CPP                        April 2014

          .--. .--.. .--..--.
         (                   '.--.
      .-.' Customer Infrastructure'.-.
      (                                )
     +-------------+               +-------------+
     |Customer Node|.--. .--.. .--.|Customer Node|
     +-------------+               +-------------+
           |                            |
        |        Provider Node              |
          (                             )
        .-.'         Network            '.-.
        (                                   )
         (      .     .    .    .    .    .)

    Figure 4: Reference Architecture: Connectivity service provided by
    the same Network Provider using via one 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

2.  Scope of this Document

   This document details the clauses of the CPP.  Candidate protocols
   (e.g., [I-D.boucadair-connectivity-provisioning-protocol]) that can

Boucadair, et al.       Expires October 12, 2014                [Page 8]
Internet-Draft                     CPP                        April 2014

   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 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 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 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) and Source-Specific
   Multicast (SSM) 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

   A CPP must include the list of Customer Nodes (e.g., CEs) to be
   connected to the underlying IP transport network.

   These nodes should be unambiguously identified (e.g., using a unique
   Service_identifier, 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.

   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 (e.g., Site_identifier).

Boucadair, et al.       Expires October 12, 2014                [Page 9]
Internet-Draft                     CPP                        April 2014

   A Customer Node may be connected to several Provider Nodes and
   multiple Customer Nodes may be connected to the same Provider Node
   (see Figure 3).

3.2.  Scope

   The scope clause specifies the reachability of each of involved
   Customer Nodes, from both an 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
      (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.

   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.

Boucadair, et al.       Expires October 12, 2014               [Page 10]
Internet-Draft                     CPP                        April 2014

3.3.  QoS Guarantees

   QoS guarantees denote a set of IP transfer performance metrics which
   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).  When quantitative metrics are
   used, maximum or average numerical values are provided together with
   a validity interval which should be indicated in the measurement

   Several performance metrics have been defined such as:

   o  Traffic Loss [RFC2680]
   o  One way delay [RFC2679]
   o  One way delay variation [RFC3393]

   The value of these parameters may be specific to a given path or a
   given scope (e.g., between two Customer Nodes).  Concretely, 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 Guarantees

   This clause specifies the percentage of the time during which the
   agreed IP performance guarantees apply.  The clause can be expressed
   as maximum/average.  The exact meaning of the clause value is defined
   during the CPP negotiation process.

   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.

Boucadair, et al.       Expires October 12, 2014               [Page 11]
Internet-Draft                     CPP                        April 2014

   The following mechanisms are provided as examples that show that
   different technical options may be chosen to meet the service
   availability objectives:

   o  When an IGP (Interior Gateway Protocol) instance is running
      between the "Customer Node" and the "Provider Node", activate a
      dedicated protocol, such as BFD (Bi-directional Forwarding
      Detection [RFC5881][RFC5883]), to control IGP availability and to
      ensure sub-second IGP adjacency failure detection.
   o  Use of Label Switched Path Ping (LSP Ping) capability to detect
      LSP availability (check whether the LSP is in place or not)
   o  Pre-install backup LSPs for fast-reroute purposes, when a MPLS
      network connects Customer Nodes [RFC4090].
   o  Enable VRRP (Virtual Router Redundancy Protocol, [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
   (Section 3.3)and (Section 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

   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.

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 the Lower than Best Effort Per Domain Behavior (LE PDB)

   Packet MTU conditions may also be indicated in the CPP.

Boucadair, et al.       Expires October 12, 2014               [Page 12]
Internet-Draft                     CPP                        April 2014

3.7.  Overall Traffic Guarantees

   Overall traffic guarantees are defined when Traffic Volume
   (Section 3.5)/Conformance (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/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].

   A flow identifier may be composed of the following parameters (but
   not limited to):

   o  Source IP address,
   o  Source port number,
   o  Destination IP address,
   o  Destination port number,
   o  ToS (Type of Service) or DSCP (Differentiated Services Code Point)
   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

Boucadair, et al.       Expires October 12, 2014               [Page 13]
Internet-Draft                     CPP                        April 2014

   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.

   For incoming traffic, some practices such as DSCP re-marking may be
   indicated in CPP.  Re-marking action is under the responsibility of
   underlying nodes that intervene to deliver the connectivity service.
   These re-marking actions must not alter the service-specific marking
   integrity (e.g., VPN service).

   This clause may specify packet re-marking policies to be enforced at
   the egress nodes.

3.10.  Routing & 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 for intelligently divert
   traffic away from some nodes/links that may potentially suffer from
   congestion or avoid crossing competitors networks, while 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) or specify geographic routing restrictions.

   A requirement for setting up a logical routing topology may also be
   considered [RFC4915] or [RFC5120], 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 be to avoid
   satellite links for VoIP (Voice over IP) deployments since this may
   degrade the offered service.

Boucadair, et al.       Expires October 12, 2014               [Page 14]
Internet-Draft                     CPP                        April 2014

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 MP-BGP session [RFC4760], PIM
   (Protocol Independent Multicast, [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
   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], IGMP (Internet Group
      Management Protocol,[RFC3376]), or MLD (Multicast Listener
      Discovery, [RFC3810]).  Appropriate access control procedures
      [RFC6601] would have to be enforced such as 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
   which 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 SNMP
   (Simple Network Management Protocol, [RFC3416]), Syslog notifications
   [RFC5424], CPNP signals
   [I-D.boucadair-connectivity-provisioning-protocol], NETCONF Event
   Notifications [RFC5277], or a phone call!

4.  CPP Template

   Figure 6 provides the RBNF (Routing Backus-Naur Form, [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

Boucadair, et al.       Expires October 12, 2014               [Page 15]
Internet-Draft                     CPP                        April 2014

   optional information elements such as metrics used for Service
   Assurance purposes.

                              <Connectivity Provisioning Component> ...
   <Connectivity Provisioning Component> ::=
                              <CONNECTIVITY_PROVISIONING_PROFILE> ...
                              <Customer Nodes Map>
                              <QoS Guarantees>
                              <Traffic Isolation>
                              <Conformance Traffic>
                              <Flow Identification>
                              <Overall Traffic Guarantees>
                              <Routing and Forwarding>
                              <Activation Means>
                              <Invocation Means>
                              <Optional Information Element> ...
   <Customer Nodes Map> ::=  <Customer Node> ...
   <Customer Node> ::=  <IDENTIFIER>

                          Figure 6: CPP Template

   The description of these clauses is provided in Section 3.

   The CPP may also include 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, AS number(s), and other contact details).  An
   example of the RBNF format of the provider's information is shown in
   Figure 8.

Boucadair, et al.       Expires October 12, 2014               [Page 16]
Internet-Draft                     CPP                        April 2014

   <Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
   <Contact Information> ::=  <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
                              [<TELEPHONE_NUMBER> ...]

                   Figure 8: Provider Description Clause

5.  IANA Considerations

   This document does not require any action from IANA.

6.  Security Considerations

   This document does not define an architecture nor specify a protocol.
   Yet, means to guarantee the identity and the ability of a Customer to
   expose its connectivity requirements to a Network Provider through a
   CPP and, likewise, means to guarantee the identity and the ability of
   a Network Provider to expose its capabilities and to capture the
   requirements of a Customer through a CPP should be properly

   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 fingerprinting customers more difficult to achieve.  For more
   discussion about privacy, refer to [RFC6462] and [RFC6973].

7.  Acknowledgements

   Some of the items listed above are the results 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.

   S. Shah, G. Huston, D. King, and S. Bryant who reviewed the document
   and provided useful comments.

8.  Informative References

Boucadair, et al.       Expires October 12, 2014               [Page 17]
Internet-Draft                     CPP                        April 2014

              Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
              Negotiation Protocol (CPNP)", draft-boucadair-
              connectivity-provisioning-protocol-02 (work in progress),
              March 2014.

              King, D. and A. Farrel, "A PCE-based Architecture for
              Application-based Network Operations", draft-farrkingel-
              pce-abno-architecture-07 (work in progress), February

   [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.

Boucadair, et al.       Expires October 12, 2014               [Page 18]
Internet-Draft                     CPP                        April 2014

   [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.

   [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

   [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.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, January

   [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.

Boucadair, et al.       Expires October 12, 2014               [Page 19]
Internet-Draft                     CPP                        April 2014

   [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.

   [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

   [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.

Boucadair, et al.       Expires October 12, 2014               [Page 20]
Internet-Draft                     CPP                        April 2014

   [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.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973, July

   [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


   Christian Jacquenet
   France Telecom
   Rennes  35000


Boucadair, et al.       Expires October 12, 2014               [Page 21]
Internet-Draft                     CPP                        April 2014

   Ning Wang
   University of Surrey
   University of Surrey


Boucadair, et al.       Expires October 12, 2014               [Page 22]