One document matched: draft-boucadair-connectivity-provisioning-profile-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info"
docName="draft-boucadair-connectivity-provisioning-profile-04"
ipr="trust200902" updates="">
<front>
<title abbrev="CPP">IP Connectivity Provisioning Profile (CPP)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Ning Wang" initials="N." surname="Wang">
<organization>University of Surrey</organization>
<address>
<postal>
<street>University of Surrey</street>
<city>Guildford</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<email>n.wang@surrey.ac.uk</email>
</address>
</author>
<date day="10" month="April" year="2014" />
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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).</t>
<t>In this document, the IP connectivity service is the IP transfer
capability characterized by a (Source Nets, Destination Nets,
Guarantees, Scope) tuple where "Source Nets" are a group of unicast IP
addresses, "Destination Nets" are a group of IP unicast and/or multicast
addresses, "Guarantees" reflect the guarantees (expressed in terms of
QoS (Quality Of Service), performance and availability, for example) to
properly forward traffic to the said "Destination". Finally, the "Scope"
denotes the (network) perimeter (e.g., between PE (Provider Equipment)
routers or Customer Nodes) where the said guarantees need to be
provided.</t>
<section title="Connectivity Provisioning Interface (CPI)">
<t><xref target="interactions2"></xref> 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).</t>
<t><figure align="center" anchor="interactions2"
title="Connectivity Provisioning Interfaces">
<artwork><![CDATA[ +---------+
|Service A|
+---+-----+
| +---------+
|CPI |Service B|
| +-+-------+
| |CPI
+----------+ +-+------+-------+ +------------+
|Subscriber|-----|Network Provider|-----|Peer Network|
+----------+ CPI +----------------+ CPI +------------+
]]></artwork>
</figure>The interfaces depicted in <xref
target="interactions2"></xref>, can be summarized as shown in <xref
target="interactions"></xref>.</t>
<t>The Customer shown in <xref target="interactions"></xref> 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.</t>
<t><figure anchor="interactions"
title="CPP: Generic Connectivity Provisioning Interfaces">
<artwork align="center"><![CDATA[+----------------+
| Customer |
+-------+--------+
+ CPI
+-------+--------+
|Network Provider|
+----------------+
]]></artwork>
</figure>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).</t>
</section>
<section title="Rationale">
<t>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.</t>
<t>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 <xref target="RFC2805"></xref>),
Session Border Controller <xref target="RFC5853"></xref>, etc.).</t>
<t>These requirements include: reachability scope (e.g., limited
scope, Internet-wide), direction, bandwidth requirements, QoS
parameters (e.g., one-way delay <xref target="RFC2679"></xref>, loss
<xref target="RFC2680"></xref> or one-way delay variation <xref
target="RFC3393"></xref>), protection and high availability guidelines
(e.g., sub-50ms/sub-100ms/second restoration).</t>
<t>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, <xref
target="RFC3346"></xref>), RSVP (Resource Reservation Protocol, <xref
target="RFC2205"></xref>), OSPF (Open Shortest Path First) or IS-IS
(Intermediate System to Intermediate System), etc.), by means of
CPP-derived configuration information.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Such a generic CPP template:<list style="symbols">
<t>Facilitates the automation of the service negotiation and
activation procedures, thus improving service delivery times;</t>
<t>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.</t>
<t>Improves service and network management systems by adding
'decision-making' capabilities based upon negotiated/offered
CPPs.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>An example of CPP usage is through the northbound interface
introduced by the Application-based Network Operations (ABNO)
framework <xref target="I-D.farrkingel-pce-abno-architecture"></xref>
or as a technique for exposing network services and their
characteristics defined in <xref target="RFC7149"></xref>.</t>
</section>
<section title="Reference Architecture">
<t>Customer Nodes belong to a Customer (including corporate Customers)
or a service infrastructure (see <xref
target="interactions2"></xref>). 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.</t>
<t>The CPP reference architectures are depicted in <xref
target="ref"></xref>, <xref target="ref1"></xref>, and <xref
target="ref2"></xref>.</t>
<t>The Customer infrastructure can be connected over networking
infrastructures managed by one or several Network Providers.</t>
<t><figure align="center" anchor="ref"
title="Reference Architecture: Connectivity service provided by the same Network Provider using distinct interconnection nodes">
<artwork><![CDATA[ .--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node |.--. .--.. . |Provider Node |
+--------------+ +--------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
]]></artwork>
</figure><figure align="center" anchor="ref1"
title="Reference Architecture: Connectivity service provided by the same Network Provider using via one single interconnection node">
<artwork><![CDATA[ .--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+-----------------------------------+
| Provider Node |
+-----------------------------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
]]></artwork>
</figure><figure align="center" anchor="ref2"
title="Reference Architecture: Connectivity services provided by distinct Network Providers">
<artwork><![CDATA[ .--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node | |Provider Node |
+--------------+ +--------------+
( .--.) ( .--.)
.-.' Network A '.-. .-.' Network B '.-.
( ) ( )
(. . . .) (. . . .)
'.-_-.'.-_-._..' '.-_-.'.-_-._..'
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section title="Scope of this Document">
<t>This document details the clauses of the CPP. Candidate protocols
(e.g., <xref
target="I-D.boucadair-connectivity-provisioning-protocol"></xref>) that
can be used to negotiate and enforce a given CPP are not discussed in
this document.</t>
<t>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.</t>
<t>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.</t>
<t>CPP was mainly designed to target IP connectivity services.
Nevertheless, it can be used for other non-IP transport schemes. It is
out of scope of this document to assess the applicability of CPP to
these non-IP schemes.</t>
<t>This document covers both unicast and multicast connectivity
services. Both Any-Source Multicast (ASM) and Source-Specific Multicast
(SSM) modes can be captured in a CPP.</t>
</section>
<section anchor="cpps" title="Connectivity Provisioning Profile (CPP)">
<t>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 <xref target="tppt"></xref>.</t>
<section title="Customer Nodes">
<t>A CPP must include the list of Customer Nodes (e.g., CEs) to be
connected to the underlying IP transport network.</t>
<t>These nodes should be unambiguously identified (e.g., using a
unique Service_identifier, MAC addresses, etc.). For each Customer
Node, a border link or a node that belongs to the domain that connects
the Customer Nodes should be identified.</t>
<t>This clause can specify geolocation information of Customer Nodes.
</t>
<t>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.</t>
<t>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 <xref target="RFC4026"></xref>
for instance (e.g., Site_identifier).</t>
<t>A Customer Node may be connected to several Provider Nodes and
multiple Customer Nodes may be connected to the same Provider Node
(see <xref target="ref"></xref>).</t>
</section>
<section anchor="scope" title="Scope">
<t>The scope clause specifies the reachability of each of involved
Customer Nodes, from both an incoming and outgoing traffic
perspectives, thereby yielding specific traffic directionality
considerations. It is defined as an unidirectional parameter. Both
directions should be described in the CPP.</t>
<t>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. </t>
<t>Both IPv4 and IPv6 reachability scopes may be specified. </t>
<t>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.</t>
<t>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: <list style="empty">
<t>(1) "1:1" Pipe model. Only point-to-point communications are
allowed.</t>
<t>(2) "1:N" Hose model. Only communications from one site towards
a set of destinations are allowed.</t>
<t>(3) "1:any" Unspecified hose model. All outbound communications
are allowed.</t>
</list></t>
<t>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. </t>
</section>
<section anchor="guarantees" title="QoS Guarantees">
<t>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)".</t>
<t>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.</t>
<t>Several performance metrics have been defined such as: <list
style="symbols">
<t>Traffic Loss <xref target="RFC2680"></xref></t>
<t>One way delay <xref target="RFC2679"></xref></t>
<t>One way delay variation <xref target="RFC3393"></xref></t>
</list>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.</t>
<t>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.</t>
<t>the Meta-QoS class concept can be used when qualitative metrics are
used <xref target="RFC5160"></xref>.</t>
</section>
<section anchor="guarantees1" title="Availability Guarantees">
<t>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.</t>
<t>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.</t>
<t>The following mechanisms are provided as examples that show that
different technical options may be chosen to meet the service
availability objectives:<list style="symbols">
<t>When an IGP (Interior Gateway Protocol) instance is running
between the “Customer Node” and the “Provider
Node”, activate a dedicated protocol, such as BFD
(Bi-directional Forwarding Detection <xref
target="RFC5881"></xref><xref target="RFC5883"></xref>), to
control IGP availability and to ensure sub-second IGP adjacency
failure detection.</t>
<t>Use of Label Switched Path Ping (LSP Ping) capability to detect
LSP availability (check whether the LSP is in place or not) <xref
target="RFC4379"></xref><xref target="RFC6424"></xref><xref
target="RFC6425"></xref><xref target="RFC6426"></xref><xref
target="RFC6829"></xref>.</t>
<t>Pre-install backup LSPs for fast-reroute purposes, when a MPLS
network connects Customer Nodes <xref
target="RFC4090"></xref>.</t>
<t>Enable VRRP (Virtual Router Redundancy Protocol, <xref
target="RFC5798"></xref>).</t>
<t>Enable IP Fast Reroute features (e.g., <xref
target="RFC5286"></xref> or <xref target="RFC6981"></xref>).</t>
</list></t>
</section>
<section anchor="cap" title="Capacity">
<t>This clause characterizes the required capacity to be provided by
the underlying IP transport network. This capacity is bound to a
defined "Scope" (See <xref target="scope"></xref>) and IP transfer
performance guarantees <xref target="guarantees">(see </xref><xref
target="guarantees1"> and </xref>).</t>
<t>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.</t>
<t>It is up to the administrative entity, which manages the IP
transport network, to appropriately dimension its network <xref
target="RFC5136"></xref> to meet the capacity requirements expressed
in all negotiated CPPs.</t>
</section>
<section anchor="ct" title="Conformance Traffic">
<t>When capacity information (see <xref target="cap"></xref>) is
included in the CPP, requirements for Out-of-Profile traffic treatment
need to be also expressed in the CPP.</t>
<t>Shaping/policing filters may be applied so as to assess whether
traffic is within the capacity profile or out of profile.
Out-of-Profile traffic may be discarded or assigned another class
(e.g., using the Lower than Best Effort Per Domain Behavior (LE PDB)
<xref target="RFC3662"></xref>).</t>
<t>Packet MTU conditions may also be indicated in the CPP.</t>
</section>
<section title="Overall Traffic Guarantees">
<t>Overall traffic guarantees are defined when Traffic Volume (<xref
target="cap"></xref>)/Conformance (<xref target="ct"></xref>) 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.</t>
<t>If overall traffic guarantees are not specified, best effort
forwarding is implied.</t>
</section>
<section anchor="isolation" title="Traffic Isolation">
<t>This clause indicates if the traffic issued by/destined to
“Customer Nodes” should be isolated when crossing the IP
transport network. This clause can also be used to specify additional
security protection requirements (including privacy protection
requirements).</t>
<t>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 <xref
target="RFC4364"></xref>, or a combination thereof. The activation of
such features should be consistent with the availability and
performance guarantees that have been negotiated.</t>
</section>
<section title="Flow Identification">
<t>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 <xref target="RFC2475"></xref>.</t>
<t>A flow identifier may be composed of the following parameters (but
not limited to): <list style="symbols">
<t>Source IP address,</t>
<t>Source port number,</t>
<t>Destination IP address,</t>
<t>Destination port number,</t>
<t>ToS (Type of Service) or DSCP (Differentiated Services Code
Point) field,</t>
<t>Tail-end tunnel endpoint, or</t>
<t>Any combination thereof.</t>
</list></t>
<t>Distinct treatments may be implemented for elastic and non elastic
traffic (e.g., see the "Constraints on traffic" clause defined in
<xref target="RFC5160"></xref>).</t>
<t>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. </t>
<t>For incoming traffic, some practices such as DSCP re-marking may be
indicated in CPP. Re-marking action is under the responsibility of
underlying nodes that intervene to deliver the connectivity service.
These re-marking actions must not alter the service-specific marking
integrity (e.g., VPN service).</t>
<t>This clause may specify packet re-marking policies to be enforced
at the egress nodes.</t>
</section>
<section title="Routing & Forwarding">
<t>This clause is used to specify outsourced routing actions such as
installing dedicated routes to convey the traffic to its (service)
destination. These dedicated routes may be computed, selected and
installed for Traffic Engineering or resilience purposes. For Traffic
Engineering these paths can be used for intelligently divert traffic
away from some nodes/links that may potentially suffer from congestion
or avoid crossing competitors networks, while for resilience backup
paths are typically pre-installed in order to bypass nodes/links under
protection. </t>
<t>This clause is also used to specify intermediate functions that
must be invoked in the forwarding path (e.g., redirect the traffic to
a firewall) or specify geographic routing restrictions.</t>
<t>A requirement for setting up a logical routing topology may also be
considered <xref target="RFC4915"></xref> or <xref
target="RFC5120"></xref>, e.g., to facilitate the management of the
nodes that are involved in the forwarding of the traffic as defined in
the CPP.</t>
<t>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) <xref
target="RFC3086"></xref>) 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.</t>
<t>For illustration purposes, a routing policy would be to avoid
satellite links for VoIP (Voice over IP) deployments since this may
degrade the offered service.</t>
</section>
<section title="Activation Means">
<t>This clause indicates the required action(s) to be undertaken to
activate access to the IP connectivity service.</t>
<t>Examples of these actions would be the activation of an IGP
instance, the establishment of a BGP <xref target="RFC4271"></xref> or
MP-BGP session <xref target="RFC4760"></xref>, PIM (Protocol
Independent Multicast, <xref target="RFC4601"></xref>), etc.</t>
</section>
<section title="Invocation Means">
<t>Two types are defined:<list style="hanging">
<t hangText="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.</t>
<t hangText="Explicit:">This clause indicates the need for
explicit means to access the connectivity service. Examples of
such means include the use of RSVP <xref target="RFC2205"></xref>,
RSVP-TE <xref target="RFC3209"></xref>, IGMP (Internet Group
Management Protocol,<xref target="RFC3376"> </xref>), or MLD
(Multicast Listener Discovery, <xref target="RFC3810"></xref>).
Appropriate access control procedures <xref
target="RFC6601"></xref> would have to be enforced such as to
check whether the capacity actually used is not above the agreed
threshold.</t>
</list></t>
</section>
<section title="Notifications">
<t>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.</t>
<t>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.</t>
<t>Notifications can be sent to the management platform by using SNMP
(Simple Network Management Protocol, <xref target="RFC3416"></xref>),
Syslog notifications <xref target="RFC5424"></xref>, CPNP signals
<xref
target="I-D.boucadair-connectivity-provisioning-protocol"></xref>,
NETCONF Event Notifications <xref target="RFC5277"></xref>, or a phone
call!</t>
</section>
</section>
<section anchor="tppt" title="CPP Template">
<t><xref target="rbnf"></xref> provides the RBNF (Routing Backus-Naur
Form, <xref target="RFC5511"></xref>) format of the CPP template.</t>
<t>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. </t>
<t><figure align="center" anchor="rbnf" title="CPP Template">
<artwork><![CDATA[<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>
<LOCALISATION>
]]></artwork>
</figure></t>
<t>The description of these clauses is provided in <xref
target="cpps"></xref>.</t>
<t>The CPP may also include Customer's administrative information, such
as a name and other contact details. An example of the RBNF format of
the Customer's information is shown in <xref
target="customer"></xref>.</t>
<t><figure align="center" anchor="customer"
title="Customer Description Clause">
<artwork><![CDATA[<Customer Description> ::= <NAME> <Contact Information>
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
]]></artwork>
</figure>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 <xref
target="NP"></xref>.</t>
<t><figure align="center" anchor="NP"
title="Provider Description Clause">
<artwork><![CDATA[<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>CPP documents should be protected against illegitimate modifications
(e.g., modification, withdrawal); authorization means should be enabled.
These means are deployment-specific.</t>
<t>The Network Provider must enforce means to protect privacy-related
information captured in a CPP document <xref target="RFC6462"></xref>.
In particular, this information must not be revealed to external parties
without the consent of customers. Network Providers should enforce
policies to make fingerprinting customers more difficult to achieve. For
more discussion about privacy, refer to <xref target="RFC6462"></xref>
and <xref target="RFC6973"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Some of the items listed above are the results of several discussions
with E. Mykoniati and D. Griffin. Special thanks to them.</t>
<t>Many thanks to P. Georgatsos for the discussions and the detailed
review of this document.</t>
<t>S. Shah, G. Huston, D. King, and S. Bryant who reviewed the document
and provided useful comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.3662'?>
<?rfc include='reference.RFC.2679'?>
<?rfc include='reference.RFC.2680'?>
<?rfc include='reference.RFC.5136'?>
<?rfc include='reference.RFC.3393'?>
<?rfc include='reference.RFC.4379'
?>
<?rfc include='reference.RFC.5120'?>
<?rfc include='reference.RFC.4915'?>
<?rfc include='reference.RFC.5881'?>
<?rfc include='reference.RFC.5883'?>
<?rfc include='reference.RFC.5798'?>
<?rfc include='reference.RFC.4760'?>
<?rfc include='reference.RFC.5286'?>
<?rfc include='reference.RFC.6973'?>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.4271'?>
<?rfc include='reference.RFC.4364'?>
<?rfc include='reference.RFC.3416'?>
<?rfc include='reference.RFC.4090'?>
<?rfc include='reference.RFC.3209'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.4601'?>
<?rfc include='reference.I-D.farrkingel-pce-abno-architecture'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
<?rfc include='reference.RFC.5160'?>
<?rfc include='reference.RFC.3346'?>
<?rfc include='reference.RFC.7149'?>
<?rfc include='reference.RFC.6981'?>
<?rfc include='reference.RFC.6462'?>
<?rfc include='reference.RFC.6426'?>
<?rfc include='reference.RFC.6829'?>
<?rfc include='reference.RFC.4026'?>
<?rfc include='reference.RFC.3086'?>
<?rfc include='reference.RFC.5853'?>
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.RFC.6425'?>
<?rfc include='reference.RFC.5424'?>
<?rfc include='reference.RFC.6424'?>
<?rfc include='reference.RFC.6601'?>
<?rfc include='reference.RFC.2805'?>
<?rfc include='reference.RFC.5277'?>
<?rfc include='reference.RFC.5511'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:04 |