| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Informational | France Telecom |
| Expires: September 05, 2014 | N. Wang |
| University of Surrey | |
| March 04, 2014 |
Connectivity Provisioning Profile (CPP)
draft-boucadair-connectivity-provisioning-profile-03
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.
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 September 05, 2014.
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. 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.
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, VPN services).
In this document, the IP connectivity service is the IP transfer capability characterized by a (Destination, Guarantees, Scope) tuple where "Destination" is a group of IP addresses, "Guarantees" reflect the guarantees (expressed in terms of QoS, performance and availability, for example) to properly forward traffic to the said "Destination". Finally, the "Scope" denotes the (network) perimeter (e.g., between two PE (Provider Equipment) routers where the said guarantees need to be provided.
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
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 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
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 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:
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 infrastructure.
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].
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 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 3Figure 4Figure 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
.--. .--.. .--..--.
( '.--.
.-.' 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
This document details the clauses of the CPP. Candidate protocols (e.g., [I-D.boucadair-connectivity-provisioning-protocol]) 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 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.
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 Figure 6.
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 that belongs to the domain that connects the Customer Nodes should be identified.
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).
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).
The Scope 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 may be defined as the set of destination prefixes that can be reached from a given 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 can be reached from a customer site.
Both IPv4 and IPv6 scopes may be distinguished.
A “Scope” delimits a topological (or geographical) network portion beyond which the performance and availability guarantees do not apply.
A scope may be defined by an “Ingress” point and an “Egress” point. Several types may be considered, such as:
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.
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 method.
Several performance metrics have been defined such as:
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].
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.
The following mechanisms are provided as examples that show that different technical options may be chosen to meet the service availability objectives:
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 [guarantees]and [guarantees1]).
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.
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 PDB [RFC3662]).
Packet MTU conditions may also be indicated in the CPP.
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.
This clause indicates if the traffic issued by/destined to “Customer Nodes” should be isolated when crossing the IP transport network.
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.
To identify the flows that need to be handled within 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:
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 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 DSCP re-marking should be indicated in CPP. Re-marking action is under the responsibility of IP nodes, but this should be conditioned by some constraints such as maintaining the service-specific marking integrity (e.g., VPN service).
When outsourced routing actions are required, dedicated routes may be installed so as to convey the traffic to its (service) destination. These routes may be computed, selected and installed for traffic engineering purposes (e.g., to forward the traffic to some destination while avoiding some nodes (or ASes)).
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) 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.
In the context of VoIP (Voice over IP) deployments for instance, a routing policy would be to avoid satellite links since this may degrade the offered service.
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.
Two types are defined:
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, Syslog notifications, CPNP signals, or a phone call!
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.
<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>
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALISATION>
Figure 6: CPP Template
The description of these clauses is provided in Section 3.
The CPP may 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
<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 8: Provider Description Clause
This document does not require any action from IANA.
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 investigated.
CPP documents should be protected againts illegitame modifications (e.g., modification, withdrawal); authorization means should be enabled. These means are deployment-specific.
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, Huston, and D. King reviewed the document and provided useful comments.