IP/MPLS Connectivity Provisioning Profile
draft-boucadair-connectivity-provisioning-profile-02

Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Informational                            France Telecom
Expires: March 29, 2013                                          N. Wang
                                         Centre for Communication System
                                                                Research
                                                      September 25, 2012

               IP/MPLS Connectivity Provisioning Profile
          draft-boucadair-connectivity-provisioning-profile-02

Abstract

   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP connectivity requirements
   to be met in the context of delivery of services (e.g.  Voice over IP
   or IP TV) which are to be plugged upon an IP/MPLS infrastructure.
   The CPP defines the set of IP transfer parameters to be supported by
   the underlying IP/MPLS transport network together with a reachability
   scope and bandwidth/capacity needs.  Appropriate performance metrics
   such as one-way delay, one-way delay variation are used to
   characterize an IP transfer service.  Both global and restricted
   reachability scopes can be captured in the CPP.

   Having the generic CPP template allows for (1) automating the process
   of service negotiation and activation, thus accelerating service
   provisioning, (2) setting the (traffic) objectives of Traffic
   Engineering functions and service management functions and (3)
   enriching service and network management systems with 'decision-
   making' capabilities based on 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 http://datatracker.ietf.org/drafts/current/.

   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 March 29, 2013.

Boucadair, et al.        Expires March 29, 2013                 [Page 1]
Internet-Draft                     CPP                    September 2012

Copyright Notice

   Copyright (c) 2012 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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Connectivity Provisioning Profile (CPP)  . . . . . . . . . . .  7
     2.1.  Customer Nodes or Service Nodes  . . . . . . . . . . . . .  7
     2.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  QoS Guarantees . . . . . . . . . . . . . . . . . . . . . .  8
     2.4.  Availability Guarantees  . . . . . . . . . . . . . . . . .  9
     2.5.  Capacity . . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.6.  Conformance Traffic  . . . . . . . . . . . . . . . . . . .  9
     2.7.  Overall Traffic Guarantees . . . . . . . . . . . . . . . . 10
     2.8.  Traffic Isolation  . . . . . . . . . . . . . . . . . . . . 10
     2.9.  Flow Identification  . . . . . . . . . . . . . . . . . . . 10
     2.10. Routing & Forwarding . . . . . . . . . . . . . . . . . . . 11
     2.11. Activation Means . . . . . . . . . . . . . . . . . . . . . 11
     2.12. Invocation Means . . . . . . . . . . . . . . . . . . . . . 11
     2.13. Notifications  . . . . . . . . . . . . . . . . . . . . . . 12
   3.  CPP Template . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Boucadair, et al.        Expires March 29, 2013                 [Page 2]
Internet-Draft                     CPP                    September 2012

1.  Introduction

   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP/MPLS connectivity
   requirements to be met in the context of delivery of services (e.g.,
   Voice over IP, IP TV, VPN services) which are to be plugged upon an
   IP/MPLS infrastructure.

   Within this document, IP connectivity service is the IP transfer
   capability characterized by a (Destination, Guarantees, Scope) tuple
   where "Destination" is a group of IP addresses, "Guarantees" is the
   guarantees (including QoS performance and availability) to get to the
   "Destination" and "Scope" is the (network) perimeters (e.g., between
   two PEs) where the guarantees should be met.

                             +----------------+
                             |   Customer     |
                             +-------+--------+
                                     + CPP
                             +-------+--------+
                             |Network Provider|
                             +----------------+

                        Figure 1: CPP: Interactions

   The CPP defines the set of IP/MPLS transfer guarantees to be offered
   by the underlying IP/MPLS 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 assumes service differentiation at the network layer can be
   enforced by tweaking various parameters which belong to distinct
   dimensions (e.g, forwarding, routing, traffic access management,
   traffic classification, etc.).

   The CPP can be used in both the integrated model (i.e., the service
   and network infrastructures are managed by the same administrative
   entity) or the functional separation model (i.e., where distinct
   administrative entities mange the service and the network
   infrastructures).  In the following sections, no assumption is made
   about the deployment model (vertical or separation).

   The CPP also aims at rationalizing the connectivity needs of above-
   deployed services and then to handle in a generic fashion all these
   requirements.  Service-specific IP provisioning rules may lead to

Boucadair, et al.        Expires March 29, 2013                 [Page 3]
Internet-Draft                     CPP                    September 2012

   increase the required IP transfer classes to be (pre)-engineered in
   the operational network.  As such, the use of the CPP allows to
   engineer generic and limited number of classes and then map
   individual CPP to these classes.  Instantiating each CPP into a
   distinct class of service should be avoided.  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 requiremenst/
   guarantees.

   CPP may also be used as a "hint" or a guideline for the network
   dimensioning and planning departments to ensure that appropriate
   resources (e.g., network cards, routers, upgrade link capacity, etc.)
   have been provisioned.  Otherwise, (underlying) IP/MPLS networks
   would not be able to meet the targets expressed in all CPP requests
   (see Figure 1).  Having the generic CPP template allows for:
   o  Automating the process of service negotiation and activation, thus
      accelerating service provisioning;
   o  Setting the (traffic) objectives of Traffic Engineering functions
      and service management functions.
   o  Enriching service and network management systems with 'decision-
      making' capabilities based on negotiated/offered CPPs.

   The customer shown in Figure 1 may be another network provider (e.g.,
   provide IP transit service), a service provider (e.g., IP telephony
   service provider) which requires invoking resources provided by an
   underlying network provider, an enterprise which wants to
   interconnect its sites using VPN services offered by a network
   provider.  The proposed CPP can apply to all these interactions,
   presenting a common template for describing the connectivity services
   offered by network providers.

   The definition of a clear interface between the service and the
   network layers has various advantages, such as rationalizing the
   engineering of network infrastructures.  The CPP interface aims at
   exposing and characterizing the IP transfer requirements to be met
   between the Customer Nodes (e.g., Media Gateway, Session Border
   Controller, etc.) when invoking IP transfer capabilities.  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., sub-50ms/sub-100ms/second restoration).  These requirements
   will then be translated into IP/MPLS-related technical clauses (e.g.,
   need for recovery means, definition of the class of services, need
   for control plane protection, etc.) and in a further stage be
   addressed by the activation of adequate network features and
   technology-specific actions (e.g., MPLS-TE [RFC3346], RSVP [RFC2205],

Boucadair, et al.        Expires March 29, 2013                 [Page 4]
Internet-Draft                     CPP                    September 2012

   OSPF or IS-IS configuration, etc.).  For traffic conformance
   purposes, the CPP includes also flow identification and
   classification rules to be followed when invoking a given CPP.

   A network provider expose its connectivity services via a Provider
   Node.  An example of Provider Node is a PE or ASBR.

   Customer Nodes belong to a service infrastructure or an enterprise
   site (see Figure 2).  In some contexts, Customer Node can be provided
   and managed by the Provider.  The connectivity between these Customer
   Nodes is implemented owing to the IP transfer capability implemented
   through a collaboration 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 level of the
   experienced IP transfer service.  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.

   Having this CPP abstraction makes a clear distinction between the
   connectivity provisioning requirements and the associated technology-
   specific rules that have been (or are to be) enforced in operational
   nodes, and which are meant to accommodate such requirements.

   As shown in Figure 2, the customer infrastructure can be connected
   over IP/MPLS networks managed by distinct network providers.

                   .--. .--.. .--..--.
                  (                   '.--.
               .-.' Customer Infrastructure'.-.
               (                                )
              +-------------+               +-------------+
              |Customer Node|.--. .--.. .--.|Customer Node|
              +-------------+               +-------------+
                    |                            |
             +--------------+             +--------------+
             |Provider Node |.--. .--.. . |Provider Node |
             +--------------+             +--------------+
                   (                             )
                 .-.'     IP/MPLS Network         '.-.
                 (                                   )
                  (      .     .    .    .    .    .)
                    '.-_-.'.-_-._.'.-_-.'.-_-.'.--.'

                   .--. .--.. .--..--.
                  (                   '.--.
               .-.' Customer Infrastructure'.-.

Boucadair, et al.        Expires March 29, 2013                 [Page 5]
Internet-Draft                     CPP                    September 2012

               (                                )
              +-------------+               +-------------+
              |Customer Node|.--. .--.. .--.|Customer Node|
              +-------------+               +-------------+
                    |                            |
             +------------------------------------------+
             |             Provider Node                |
             +------------------------------------------+
                   (                             )
                 .-.'     IP/MPLS Network         '.-.
                 (                                   )
                  (      .     .    .    .    .    .)
                    '.-_-.'.-_-._.'.-_-.'.-_-.'.--.'

                   .--. .--.. .--..--.
                  (                   '.--.
               .-.' Customer Infrastructure'.-.
               (                                )
              +-------------+               +-------------+
              |Customer Node|.--. .--.. .--.|Customer Node|
              +-------------+               +-------------+
                    |                            |
             +--------------+             +--------------+
             |Provider Node |             |Provider Node |
             +--------------+             +--------------+
              (            .--.)           (           .--.)
            .-.' IP/MPLS Network '       .-.' IP/MPLS Network '
              (                  )         (                  )
              (.     .    .    .)          (.     .    .    .)
               '.-_-.'.-_-._..'             '.-_-.'.-_-._..'

                     Figure 2: Reference Architecture

1.1.  Scope

   This document details the clauses of the CPP.  Protocols used to
   negotiate and to enforce a CPP are out of scope.

   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 technology-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 objective included in a CPP.

Boucadair, et al.        Expires March 29, 2013                 [Page 6]
Internet-Draft                     CPP                    September 2012

2.  Connectivity Provisioning Profile (CPP)

   A CPP can be seen as an inventory of connectivity provisioning
   requirements with regard to IP transfer service.  CPP clauses are
   elaborated in the following sub-sections.  The CPP template is
   provided in Section 3.

2.1.  Customer Nodes or Service 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).  For each Customer Node, a border link or a node
   part of the connectivity domain which is connected to the Customer
   Node should be identified.

   Based on the location of the Customer Node (e.g., CE), 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.  An
   identifier of the site may also be pertinent to be captured in the
   CPP for the provisioning of managed VPN [RFC4026] for instance (e.g.,
   Site_identifier).

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

2.2.  Scope

   The Scope specifies the reachability out/to each of involved Customer
   Nodes.  It is defined as an unidirectional parameter.  Both
   directions should be described in the CPP.

   The reachability scope may be defined as allowed destination IP
   prefixes that can be reached from the customer site.  Both global and
   restricted reachability scopes can be captured in the CPP.  A
   restricted reachability scope means no global reachability is allowed
   and only a set of destinations are reachable.

   Both IPv4 and IPv6 scopes may be distinguished.

   A "Scope" delimits a topological (or geographical) network portion
   over which the performance and availability guarantees are not valid.

Boucadair, et al.        Expires March 29, 2013                 [Page 7]
Internet-Draft                     CPP                    September 2012

   A scope may be defined by an "Ingress" and "Egress" points.  Several
   types may be envisaged.  Examples are listed below:
      (1) "1:1" Pipe model.  Only point to point communications are
      allowed.
      (2) "1:N" Hose model.  Only communications destined to a set of
      destinations are allowed.
      (3) "1:any" Unspecified hose model.  All outbound communications
      destined to whatever reachable destinations are to be offered.

   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 sets of IP destinations.

2.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 or destined to a (set of) "Customer Node(s)".

   IP performance metrics can be expressed as qualitative or
   quantitative parameters.  When quantitative metrics are used, maximum
   or average numerical values are provided together with a validity
   interval which 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]
   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 value indicated in a CPP should reflect the
   measurement between a set of "Customer Node" or between a "Customer
   Node" and Provider Nodes attached to the IP network.

   Quantitative guarantees can only be specified for in-profile traffic
   (i.e., up to a certain traffic rate).

   Meta-QoS class concept can be used when qualitative metrics are used
   [RFC5160].

   Including both quantitative and qualitative guarantees cannot be
   specified in the same CPP.

   A CPP can include throughput guarantees; when specified these
   guarantees are equivalent to quantitative or qualitative loss
   guarantees.

Boucadair, et al.        Expires March 29, 2013                 [Page 8]
Internet-Draft                     CPP                    September 2012

2.4.  Availability Guarantees

   This clause specifies the percentage of the time when the agreed IP
   performance guarantees must be met.  The clause can be expressed as
   maximum/average.  The exact meaning is agreed during 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 in the border link such as allowing for multi-homed
   "Customer Nodes".

   The following mechanisms are provided as illustration examples to
   show that several technical choices may be enforced to meet the
   service availability needs:
   o  When an IGP 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 then to ensure sub-second IGP
      adjacency failure detection.
   o  Use of LSP ping capability to detect LSP availability (check if
      the LSP is in place or not) [RFC4379].
   o  Pre-install backup LSPs for fast-rerouting when MPLS is used
      between "Customer Nodes" [RFC4090].
   o  Enable VRRP [RFC5798].
   o  Enable IP Fast Reroute features (e.g., [RFC5286]).

2.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 2.2) and IP transfer performance guarantees (see
   (Section 2.3)and (Section 2.4)).

   The capacity may be expressed per border link and for both directions
   (i.e., incoming and outgoing).  This clause is a limit of the traffic
   up to which quantitative guarantees are to be provided.

   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.

2.6.  Conformance Traffic

   When capacity information (see Section 2.5) is included in the CPP,
   out-of-profile traffic would be handled separately.

Boucadair, et al.        Expires March 29, 2013                 [Page 9]
Internet-Draft                     CPP                    September 2012

   Shaping/policing filters may be applied so as to assess wither the
   traffic is within the capacity profile or out of profile.

   Out-of-profile traffic may be discarded or under-classed (e.g., using
   the Lower than Best Effort PDB [RFC3662]).

   Conditions on the injected packets MTU may also be indicated in the
   CPP.

2.7.  Overall Traffic Guarantees

   Overall traffic guarantees are for the case where Traffic Volume/
   Conformance clauses are not specified, or if specified, excess
   traffic is remarked.  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.

2.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 is then translated into IP engineering policies such as
   activating dedicated tunnels using IPsec or establish BGP/MPLS VPN
   facilities [RFC4364], or a combination thereof.  Activated means
   should be consistent with those used to meet the availability and
   performance guarantees.

2.9.  Flow Identification

   To identify the flows that need to be handled in the context of a
   given CPP, flow identifiers should be indicated in the CPP.  This
   identifier is used for traffic classification purposes.

   A flow identifier may be composed of the following parameters:
   o  source IP address,
   o  source port number,
   o  destination IP address,
   o  destination port number,
   o  ToS or DSCP field,
   o  tail-end tunnel endpoint, or
   o  a combination thereof.

   Distinct treatments may be implemented for elastic and non elastic
   traffic (e.g., see the "Constraints on traffic" clause defined in
   [RFC5160]).

Boucadair, et al.        Expires March 29, 2013                [Page 10]
Internet-Draft                     CPP                    September 2012

   Flow classification rules may be specific to a given link or a given
   rule may be applied for all border links.  This should be clearly
   captured in the CPP.  For incoming traffic, some practices such as
   re-marking the DSCP field should be indicated in CPP.  Re- marking
   action is under the responsibility of IP nodes, but this should be
   inferred by some constraints such as maintaining the service
   transparency (e.g., VPN services).

2.10.  Routing & Forwarding

   When outsourced routing actions are required, dedicated routes may be
   installed so as to convey the traffic to its (service) destination
   and avoiding some nodes (or ASes).

   A requirement to dedicate a logical topology may also be envisaged
   owing to the activation of [RFC4915] or [RFC5120].

   This practice should be indicated in the CPP, otherwise routing
   actions belong to the underlying IP routing capabilities.  Forwarding
   behavior (e.g., Per Domain Behavior) may also be specified in a CPP.
   Nevertheless, it is optional.  If indicated, consistency with the IP
   performance bounds defined in the CPP should be carefully ensured.

   In the context of VoIP deployments for instance, a routing policy
   would be to avoid satellite links since this may degrade the offered
   service.

2.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],
   etc.

2.12.  Invocation Means

   Two types are defined:
   Implicit:  This clause when indicated means that no explicit means to
      invoke the connectivity service is required.  Access to
      connectivity service is conditioned by the requested network
      capacity.
   Explicit:  This clause indicates the need for an explicit means to
      access the connectivity service.  Examples of explicit invocation
      means include the use of RSVP [RFC2205] or RSVP-TE [RFC3209].
      Appropriate access control procedures [RFC6601] would have to be
      enforced to check if the capacity actually used is not above the

Boucadair, et al.        Expires March 29, 2013                [Page 11]
Internet-Draft                     CPP                    September 2012

      agreed threshold.

2.13.  Notifications

   For operation purposes (e.g., supervision) and service fulfillment
   needs, added value service 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, data model, etc.

   This may be enforced using SNMP, Syslog notifications, or a phone
   call!

3.  CPP Template

   Figure 3 provides an overview of the CPP template which includes the
   clauses detailed in Section 2.

Boucadair, et al.        Expires March 29, 2013                [Page 12]
Internet-Draft                     CPP                    September 2012

   +-------------------------------------------------------------------+
   |                       Customer Nodes Map                          |
   +---------+------------+-------------+--------------+-------+-------+
   |Customer |    Link    |  Border IP  | Localization |     Scope     |
   |   Node  | Identifier |     Node    |              +-------+-------+
   |         |            |  Identifier |              |   IN  |  OUT  |
   +---------+------------+-------------+--------------+-------+-------+
   |         |            |             |              |       |       |
   +---------+------------+-------------+--------------+-------+-------+
   |         |            |             |              |       |       |
   +---------+------------+-------------+--------------+-------+-------+
   |         |            |             |              |       |       |
   +---------+------------+-------------+--------------+-------+-------+
                                   ....
   +-------------------------------------------------------------------+
   |                 Guarantees: QoS and Availability                  |
   +---------------------------------+---------------------------------+
   |         One Way Delay           |   One Way Delay Variation       |
   +---------------------------------+---------------------------------+
   |            Loss                 |    Availability Guarantees      |
   +---------------------------------+---------------------------------+
   |                     Qualitative Guarantees                        |
   +---------------------------------+---------------------------------+
   |                                 |                                 |
   +---------------------------------+---------------------------------+
                                   ....
   +-------------------------------------------------------------------+
   |                       Capacity  |                                 |
   +---------------------------------+---------------------------------+
   |              Traffic Isolation  |                                 |
   +---------------------------------+---------------------------------+
   |            Conformance Traffic  |                                 |
   +---------------------------------+---------------------------------+
   |            Flow Identification  |                                 |
   +---------------------------------+---------------------------------+
   |     Overall Traffic Guarantees  |                                 |
   +---------------------------------+---------------------------------+
   |          Routing And Forwarding |                                 |
   +---------------------------------+---------------------------------+
   |                Activation Means |                                 |
   +---------------------------------+---------------------------------+
   |               Invocation Means  |                                 |
   +---------------------------------+---------------------------------+
   |                  Notifications  |                                 |
   +---------------------------------+---------------------------------+

                          Figure 3: CPP Template

Boucadair, et al.        Expires March 29, 2013                [Page 13]
Internet-Draft                     CPP                    September 2012

4.  IANA Considerations

   This document does not require any action from IANA.

5.  Security Considerations

   This document does not define an architecture nor specify a protocol.

6.  Acknowledgements

   Some of the items listed above are results of 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 reviewed the document and provided useful comments.

7.  References

7.1.  Normative References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

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

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

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [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

Boucadair, et al.        Expires March 29, 2013                [Page 14]
Internet-Draft                     CPP                    September 2012

              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.

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

   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
              Reroute: Loop-Free Alternates", RFC 5286, September 2008.

   [RFC5798]  Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798, March 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.

7.2.  Informative References

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

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",
              RFC 3662, December 2003.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual

Boucadair, et al.        Expires March 29, 2013                [Page 15]
Internet-Draft                     CPP                    September 2012

              Private Network (VPN) Terminology", RFC 4026, March 2005.

   [RFC5160]  Levis, P. and M. Boucadair, "Considerations of Provider-
              to-Provider Agreements for Internet-Scale Quality of
              Service (QoS)", RFC 5160, March 2008.

   [RFC6601]  Ash, G. and D. McDysan, "Generic Connection Admission
              Control (GCAC) Algorithm Specification for IP/MPLS
              Networks", RFC 6601, April 2012.

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
   Centre for Communication System Research
   University of Surrey
   Guildford,
   UK

   Email: n.wang@surrey.ac.uk

Boucadair, et al.        Expires March 29, 2013                [Page 16]