doc: Add RFC documents

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]
+