Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Informational France Telecom
Expires: September 5, 2014 N. Wang
University of Surrey
March 04, 2014
Connectivity Provisioning Profile (CPP)
draft-boucadair-connectivity-provisioning-profile-03
Abstract
This document describes the Connectivity Provisioning Profile (CPP)
and proposes a CPP Template to capture IP connectivity requirements
to be met within a service delivery context (e.g., Voice over IP or
IP TV). The CPP defines the set of IP transfer parameters to be
supported by the underlying transport network together with a
reachability scope and bandwidth/capacity needs. Appropriate
performance metrics such as one-way delay or one-way delay variation
are used to characterize an IP transfer service. Both global and
restricted reachability scopes can be captured in the CPP.
Such a generic CPP template is meant to (1) facilitate the automation
of the service negotiation and activation procedures, thus
accelerating service provisioning, (2) set (traffic) objectives of
Traffic Engineering functions and service management functions and
(3) improve service and network management systems with 'decision-
making' capabilities based upon negotiated/offered CPPs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 5, 2014.
Boucadair, et al. Expires September 5, 2014 [Page 1]
Internet-Draft CPP March 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. 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. Connectivity Provisioning Interface (CPI) . . . . . . . . 3
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Reference Architecture . . . . . . . . . . . . . . . . . 6
2. Scope Of This Document . . . . . . . . . . . . . . . . . . . 8
3. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 9
3.1. Customer Nodes . . . . . . . . . . . . . . . . . . . . . 9
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . 10
3.4. Availability Guarantees . . . . . . . . . . . . . . . . . 11
3.5. Capacity . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 12
3.7. Overall Traffic Guarantees . . . . . . . . . . . . . . . 12
3.8. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 12
3.9. Flow Identification . . . . . . . . . . . . . . . . . . . 13
3.10. Routing & Forwarding . . . . . . . . . . . . . . . . . . 13
3.11. Activation Means . . . . . . . . . . . . . . . . . . . . 14
3.12. Invocation Means . . . . . . . . . . . . . . . . . . . . 14
3.13. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4. CPP Template . . . . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Boucadair, et al. Expires September 5, 2014 [Page 2]
Internet-Draft CPP March 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, 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.
1.1. Connectivity Provisioning Interface (CPI)
Figure 1 shows the various connectivity provisioning interfaces
covered by CPP: the Customer-Network Connectivity Provisioning
Interface, the Service-Network Connectivity Provisioning Interface,
and the Network-Network Connectivity Provisioning Interface.
Services and applications whose parameters are captured by means of a
CPP exchanged through the Service-Network Connectivity Provisioning
Interface may be provided by the same administrative entity that
operates the underlying network, or by another entity (for example, a
Content Provider).
+---------+
|Service A|
+---+-----+
| +---------+
|CPI |Service B|
| +-+-------+
| |CPI
+----------+ +-+------+-------+ +------------+
|Subscriber|-----|Network Provider|-----|Peer Network|
+----------+ CPI +----------------+ CPI +------------+
Figure 1: Connectivity Provisioning Interfaces
The interfaces depicted in Figure 1, can be summarized as shown in
Figure 2.
The Customer shown in Figure 2 may be another Network Provider (e.g.,
an IP transit provider), a Service Provider (e.g., an IP telephony
Service Provider) which requires the invocation of resources provided
Boucadair, et al. Expires September 5, 2014 [Page 3]
Internet-Draft CPP March 2014
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
In the rest of the document, "Customer" is used as a generic term to
denote the business entity that subscribes to connectivity services
offered by a Network Provider (Figure 2).
1.2. Rationale
Procedures for the design and the operation of IP services have
become increasingly diverse and complex. The time it takes to
negotiate service parameters and then proceed with the corresponding
resource allocation can thus be measured in days, if not weeks. Yet,
the bilateral discussions that usually take place between a customer
and a Network Provider hardly rely upon some kind of standard
checklist, where the customer would be invited to tick all the
parameters that apply to its environment, and then negotiate these
parameters with the Network Provider, as a function of the available
resources, the customer's expectations, the provider's network
planning policy, etc.
The definition of a clear interface between the service (including
third-party applications) and the network layers would therefore
facilitate the said discussion, thereby improving the overall service
delivery procedure by optimizing the design of the network
infrastructures. Indeed, the CPP interface aims at exposing and
characterizing, in a technology-agnostic manner, the IP transfer
requirements to be met when invoking IP transfer capabilities of a
network operated by a Network Provider between a set of Customer
Nodes (e.g., Media Gateway (section-11.2.7 [RFC2805]), Session Border
Controller [RFC5853], etc.) .
Boucadair, et al. Expires September 5, 2014 [Page 4]
Internet-Draft CPP March 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., sub-50ms/sub-100ms/second restoration).
These requirements are then translated into IP/MPLS-related technical
clauses (e.g., need for recovery means, definition of the class of
service, need for control plane protection, etc.). In a later stage,
these various clauses will be addressed by the activation of adequate
network features and technology-specific actions (e.g., MPLS-TE
(Multiprotocol Label Switching TE, [RFC3346]), RSVP (Resource
Reservation Protocol, [RFC2205]), OSPF (Open Shortest Path First) or
IS-IS (Intermediate System to Intermediate System), etc.), by means
of CPP-derived configuration information.
For traffic conformance purposes, a CPP also includes flow
identification and classification rules to be followed by
participating nodes whenever they have to process traffic according
to a specific service as defined by the said CPP.
The CPP template aims at capturing connectivity needs and to
represent and value these requirements in a standardized manner.
Service- and Customer-specific IP provisioning rules may lead to a
dramatic increase of the number of IP transfer classes that need to
be (pre)-engineered in the network. Instantiating each CPP into a
distinct class of service should therefore be avoided for the sakes
of performance and scalability.
Therefore, application-agnostic IP provisioning practices should be
recommended since the requirements captured in the CPP can be used to
identify which network class of service is to be used to meet those
requirements/guarantees. From that standpoint, the CPP concept is
meant to design a limited number of generic classes, so that
individual CPP documents, by capturing the connectivity requirements
of services, applications and Customers, can be easily mapped to
these classes.
CPP may also be used as a guideline for network dimensioning and
planning teams of a Network Provider to ensure that appropriate
resources (e.g., network cards, routers, link capacity, etc.) have
been provisioned. Otherwise, (underlying) transport networks would
not be able to meet the objectives expressed in all CPP requests.
Such a generic CPP template:
o Facilitates the automation of the service negotiation and
activation procedures, thus improving service delivery times;
Boucadair, et al. Expires September 5, 2014 [Page 5]
Internet-Draft CPP March 2014
o Can help setting Traffic Engineering function and service
management function objectives, as a function of the number of CPP
templates to be processed over a specific period of time, for
example.
o Improves service and network management systems by adding
'decision-making' capabilities based upon negotiated/offered CPPs.
In addition, this CPP abstraction makes a clear distinction between
the connectivity provisioning requirements and the associated
technology-specific rules that need to be applied by participating
nodes, and which are meant to accommodate such requirements.
The CPP defines the set of IP/MPLS transfer guarantees to be offered
by the underlying transport network together with a reachability
scope and capacity needs. Appropriate performance metrics such as
one-way delay or one-way delay variation are used to characterize the
IP transfer service. Guarantees related to availability and
resiliency are also included in the CPP.
The CPP can be used in an integrated business environment (where the
service and network infrastructures are managed by the same
administrative entity) or another business environment (where an
administrative entity manages the service while another manages the
network infrastructure). In the following sections, no assumption is
made about the business environment (integrated or not).
Service differentiation at the network layer can be enforced by
tweaking various parameters which belong to distinct dimensions (e.g,
forwarding, routing, processing of incoming traffic, traffic
classification, etc.). This document does not make any assumption on
how network services are implemented within an networking
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].
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 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
Boucadair, et al. Expires September 5, 2014 [Page 6]
Internet-Draft CPP March 2014
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
Boucadair, et al. Expires September 5, 2014 [Page 7]
Internet-Draft CPP March 2014
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+-----------------------------------+
| Provider Node |
+-----------------------------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
Figure 4: Reference Architecture: Connectivity service provided by
the same Network Provider using via one single interconnection node
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node | |Provider Node |
+--------------+ +--------------+
( .--.) ( .--.)
.-.' Network A '.-. .-.' Network B '.-.
( ) ( )
(. . . .) (. . . .)
'.-_-.'.-_-._..' '.-_-.'.-_-._..'
Figure 5: Reference Architecture: Connectivity services provided by
distinct Network Providers
2. Scope Of This Document
This document details the clauses of the CPP. Candidate protocols
(e.g., [I-D.boucadair-connectivity-provisioning-protocol]) that can
Boucadair, et al. Expires September 5, 2014 [Page 8]
Internet-Draft CPP March 2014
be used to negotiate and enforce a given CPP are not discussed in
this document.
In addition to CPP clauses, other clauses may be included in an
agreement between a Customer and a Provider (e.g., contact point,
escalation procedure, incidents management, billing, etc.). It is
out of scope of this document to detail all those additional clauses.
Examples of how to translate CPP clauses into specific policies are
provided for illustration purposes. It is out of scope of this
document to provide an exhaustive list of the technical means to meet
the objectives detailed in a CPP.
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 Figure 6.
3.1. Customer Nodes
A CPP must include the list of Customer Nodes (e.g., CEs) to be
connected to the underlying IP transport network.
These nodes should be unambiguously identified (e.g., using a unique
Service_identifier). 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).
3.2. Scope
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
Boucadair, et al. Expires September 5, 2014 [Page 9]
Internet-Draft CPP March 2014
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:
(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.
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 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:
o Traffic Loss [RFC2680]
o One way delay [RFC2679]
o One way delay variation [RFC3393]
Boucadair, et al. Expires September 5, 2014 [Page 10]
Internet-Draft CPP March 2014
The value of these parameters may be specific to a given path or a
given scope (e.g., between two Customer Nodes). Concretely, IP
performance metric values indicated in a CPP should reflect the
measurement between a set of Customer Nodes or between a Customer
Node and a set of Provider Nodes.
Quantitative guarantees can only be specified for in-profile traffic
(i.e., up to a certain traffic rate). A CPP can include throughput
guarantees; when specified, these guarantees are equivalent to
quantitative or qualitative loss guarantees.
the Meta-QoS class concept can be used when qualitative metrics are
used [RFC5160].
3.4. Availability Guarantees
This clause specifies the percentage of the time during which the
agreed IP performance guarantees apply. The clause can be expressed
as maximum/average. The exact meaning of the clause value is defined
during the CPP negotiation process.
The guarantees cover both QoS deterioration (i.e., IP transfer
service is available but it is below the agreed performance bounds),
physical failures or service unavailability in general. In order to
meet the availability guarantees, several engineering practices may
be enforced at the border between the customer and the Network
Provider, such as multi-homing designs.
The following mechanisms are provided as examples that show that
different technical options may be chosen to meet the service
availability objectives:
o When an IGP instance is running between the "Customer Node" and
the "Provider Node", activate a dedicated protocol, such as BFD
(Bi-directional Forwarding Detection [RFC5881][RFC5883]), to
control IGP availability and to ensure sub-second IGP adjacency
failure detection.
o Use of LSP Ping capability to detect LSP availability (check
whether the LSP is in place or not) [RFC4379].
o Pre-install backup LSPs for fast-reroute purposes, when a MPLS
network connects Customer Nodes [RFC4090].
o Enable VRRP [RFC5798].
o Enable IP Fast Reroute features (e.g., [RFC5286]).
Boucadair, et al. Expires September 5, 2014 [Page 11]
Internet-Draft CPP March 2014
3.5. Capacity
This clause characterizes the required capacity to be provided by the
underlying IP transport network. This capacity is bound to a defined
"Scope" (See Section 3.2) and IP transfer performance guarantees (see
(Section 3.3)and (Section 3.4)).
The capacity may be expressed for both traffic directions (i.e.,
incoming and outgoing) and for every border link. The capacity
clause defines the limits of the application of quantitative
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.
3.6. Conformance Traffic
When capacity information (see Section 3.5) is included in the CPP,
requirements for Out-of-Profile traffic treatment need to be also
expressed in the CPP.
Shaping/policing filters may be applied so as to assess whether
traffic is within the capacity profile or out of profile. Out-of-
Profile traffic may be discarded or assigned another class (e.g.,
using the Lower than Best Effort PDB [RFC3662]).
Packet MTU conditions may also be indicated in the CPP.
3.7. Overall Traffic Guarantees
Overall traffic guarantees are defined when Traffic Volume
(Section 3.5)/Conformance (Section 3.6) clauses are not specified.
Or if they are actually specified, then Out-of-Profile traffic is
assigned another class of service, but is not discarded. Such
guarantees can only be qualitative delay and/or qualitative loss or
throughput guarantees.
If overall traffic guarantees are not specified, best effort
forwarding is implied.
3.8. Traffic Isolation
This clause indicates if the traffic issued by/destined to "Customer
Nodes" should be isolated when crossing the IP transport network.
This clause can then be translated into VPN policy provisioning
information, such as the information pertaining to the activation of
Boucadair, et al. Expires September 5, 2014 [Page 12]
Internet-Draft CPP March 2014
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. 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 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 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).
3.10. Routing & Forwarding
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
Boucadair, et al. Expires September 5, 2014 [Page 13]
Internet-Draft CPP March 2014
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.
3.11. Activation Means
This clause indicates the required action(s) to be undertaken to
activate access to the IP connectivity service.
Examples of these actions would be the activation of an IGP instance,
the establishment of a BGP [RFC4271] or MP-BGP session [RFC4760],
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.
Explicit: This clause indicates the need for explicit means to
access the connectivity service. Examples of such means include
the use of RSVP [RFC2205] or RSVP-TE [RFC3209]. Appropriate
access control procedures [RFC6601] would have to be enforced to
check whether the capacity actually used is not above the agreed
threshold.
3.13. Notifications
For operation purposes (e.g., supervision) and service fulfillment
needs, management platforms need to be notified about critical events
which may impact the delivery of the service.
The notification procedure should be indicated in the CPP. This
procedure may specify the type of information to be sent, the
interval, the data model, etc.
Notifications can be sent to the management platform by using SNMP,
Syslog notifications, CPNP signals, or a phone call!
Boucadair, et al. Expires September 5, 2014 [Page 14]
Internet-Draft CPP March 2014
4. CPP Template
Figure 6 provides the RBNF (Routing Backus-Naur Form, [RFC5511])
format of the CPP template. A CPP document includes several
connectivity provisioning components; each of these is structured as
a CPP.
<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
The CPP may include administrative information of the Network
Provider too (name, AS number(s), and other contact details). An
example of the RBNF format of the provider's information is shown in
Figure 8.
Boucadair, et al. Expires September 5, 2014 [Page 15]
Internet-Draft CPP March 2014
<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 8: Provider Description Clause
5. IANA Considerations
This document does not require any action from IANA.
6. Security Considerations
This document does not define an architecture nor specify a protocol.
Yet, means to guarantee the identity and the ability of a Customer to
expose its connectivity requirements to a Network Provider through a
CPP and, likewise, means to guarantee the identity and the ability of
a Network Provider to expose its capabilities and to capture the
requirements of a Customer through a CPP should be properly
investigated.
CPP documents should be protected againts illegitame modifications
(e.g., modification, withdrawal); authorization means should be
enabled. These means are deployment-specific.
7. Acknowledgements
Some of the items listed above are the results of several discussions
with E. Mykoniati and D. Griffin. Special thanks to them.
Many thanks to P. Georgatsos for the discussions and the detailed
review of this document.
S. Shah, Huston, and D. King reviewed the document and provided
useful comments.
8. References
8.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.
Boucadair, et al. Expires September 5, 2014 [Page 16]
Internet-Draft CPP March 2014
[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
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.
Boucadair, et al. Expires September 5, 2014 [Page 17]
Internet-Draft CPP March 2014
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, June 2010.
8.2. Informative References
[I-D.boucadair-connectivity-provisioning-protocol]
Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
Negotiation Protocol (CPNP)", draft-boucadair-
connectivity-provisioning-protocol-01 (work in progress),
October 2013.
[I-D.farrkingel-pce-abno-architecture]
King, D. and A. Farrel, "A PCE-based Architecture for
Application-based Network Operations", draft-farrkingel-
pce-abno-architecture-07 (work in progress), February
2014.
[RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway
Control Protocol Architecture and Requirements", RFC 2805,
April 2000.
[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
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.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[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.
[RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission
Control (GCAC) Algorithm Specification for IP/MPLS
Networks", RFC 6601, April 2012.
Boucadair, et al. Expires September 5, 2014 [Page 18]
Internet-Draft CPP 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
University of Surrey
Guildford
UK
Email: n.wang@surrey.ac.uk
Boucadair, et al. Expires September 5, 2014 [Page 19]