RFC 7297
IP Connectivity Provisioning Profile (CPP)
RFC 7297 📄✨
IP Connectivity Provisioning Profile (CPP) 💖
Authors: M. Boucadair (France Telecom), C. Jacquenet (France Telecom), and N. Wang (University of Surrey) 🫶 Category: Informational. It's an Independent Submission 🎀 ISSN: 2070-1721 Date: July 2014 📅 Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🙈
Abstract ✨
okay so this doc is all about the Connectivity Provisioning Profile (CPP) 🦋 It's a template for capturing IP/MPLS connectivity requirements for a service, like Voice over IP or IP TV 📞📺 The CPP lists the IP transfer parameters the transport network has to support, plus the reachability scope and the bandwidth/capacity needs 💅 It also uses performance metrics, like one-way delay or one-way delay variation, to describe an IP transfer service. And you can capture both global and restricted reachability scopes 🌸
The whole point of a generic CPP template is threefold, bestie 🧚
- it helps automate service negotiation and activation, so services get provisioned way faster ⚡
- it sets traffic objectives for Traffic Engineering functions and service management functions 🎯
- it gives service and network management systems "decision-making" smarts based on the CPPs that get negotiated or offered 🧠
Status of This Memo 💜
This document isn't an Internet Standards Track specification. It's just published for informational purposes 🌈
It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion, and they don't say anything about whether it's good to implement or deploy 🤷♀️ Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 5741 for that 📚
If you want to know the current status, any errata, or how to send feedback, check out http://www.rfc-editor.org/info/rfc7297 🔗
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), as in effect on the date this document was published. Please read these carefully, bestie 🫶 They explain your rights and restrictions with respect to this document 📜
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Connectivity Provisioning Interface (CPI) . . . . . . . . 3
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Reference Architecture . . . . . . . . . . . . . . . . . 7
2. Scope of This Document . . . . . . . . . . . . . . . . . . . 9
3. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 9
3.1. Customer Nodes Map . . . . . . . . . . . . . . . . . . . 9
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . 11
3.4. Availability . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Capacity . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 13
3.7. Overall Traffic Guarantees . . . . . . . . . . . . . . . 13
3.8. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 13
3.9. Flow Identification . . . . . . . . . . . . . . . . . . . 13
3.10. Routing and Forwarding . . . . . . . . . . . . . . . . . 14
3.11. Activation Means . . . . . . . . . . . . . . . . . . . . 15
3.12. Invocation Means . . . . . . . . . . . . . . . . . . . . 15
3.13. Notifications . . . . . . . . . . . . . . . . . . . . . . 16
4. CPP Template . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay, so this is the intro 🌷 This doc describes the Connectivity Provisioning Profile (CPP) and gives you a CPP template to capture IP/MPLS connectivity requirements for a service delivery context (e.g., Voice over IP, IP TV, and VPN services) 📞📺🔒
Here's the big idea. The IP connectivity service is the IP transfer capability, and it's described by a (Source Nets, Destination Nets, Guarantees, Scope) tuple 🍓
- "Source Nets" is a group of unicast IP addresses 🌐
- "Destination Nets" is a group of IP unicast and/or multicast addresses 📡
- "Guarantees" covers the guarantees (like Quality Of Service (QoS), performance, and availability, for example) that make sure traffic gets forwarded properly to that "Destination" 💜
- "Scope" is the (network) perimeter where those guarantees need to be provided, like between Provider Edge (PE) routers or Customer Nodes 🗺️
It's giving very organised energy, honestly 💅
1.1. Connectivity Provisioning Interface (CPI) 🔌
Figure 1 shows the connectivity provisioning interfaces that CPP covers. There are three of them: the Customer-Network CPI, the Service-Network CPI, and the Network-Network CPI 🦋 Services and applications whose parameters get captured with a CPP exchanged over the Service-Network CPI can be run by the same administrative entity that operates the underlying network, or by a different entity (for example, a Content Provider) 🎬
+---------+
|Service A|
+---+-----+
| +---------+
|CPI |Service B|
| +-+-------+
| |CPI
+----------+ +-+------+-------+ +------------+
| Customer |-----|Network Provider|-----|Peer Network|
+----------+ CPI +----------------+ CPI +------------+
Figure 1: Connectivity Provisioning InterfacesNext, Figure 1 gets summed up in Figure 2 🌈
The Customer in Figure 2 can be another Network Provider (e.g., an IP transit provider) 🛰️ It could also be a Service Provider (e.g., an IP telephony Service Provider) that needs to invoke resources from a Network Provider 📱 Or it could be an enterprise that wants to connect its different sites by subscribing to a VPN service from a Network Provider 🏢 The proposed CPP can be used to expose, capture, and help negotiate service parameters between all of these entities 🫶 So basically it's one common template for describing the available connectivity services ✨
+----------------+
| Customer |
+-------+--------+
+ CPI
+-------+--------+
|Network Provider|
+----------------+
Figure 2: CPP: Generic Connectivity Provisioning InterfacesLast but not least, in the rest of this doc, "Customer" is a generic term for the business entity that subscribes to connectivity services offered by a Network Provider (see Figure 2) 💖 Main character energy, literally 🌈👑
1.2. Rationale ✨
okay so IP services have gotten SO complicated 😭 Designing and running them is a whole vibe now, and figuring out the service parameters and then actually allocating the resources can take days, if not weeks 💀 The wild part is that the back-and-forth between a Customer and a Network Provider never uses some kind of standard checklist where the Customer just ticks every parameter that fits their setup 🙈 Instead, those parameters get negotiated based on the available resources, what the Customer expects, the provider's network planning policy, and so on.
So a clear interface between the service (including third-party applications) and the network layers would make that conversation SO much easier 🫶 It would improve the whole service delivery process by optimizing how the network infrastructures get designed. The CPP interface is all about exposing and characterizing, in a technology-agnostic way, the IP transfer requirements that have to be met when you invoke the IP transfer capabilities of a network run by a Network Provider between a set of Customer Nodes. Examples of those Customer Nodes are a Multimedia Gateway (Section 11.2.7 of [RFC2805]) and a Session Border Controller [RFC5853], among others 🦋
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
- high-availability guidelines (e.g., restoration in less than 50 ms, 100 ms, or 1 second)
Then those requirements get 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.) 🎀 Later on, those clauses get addressed by turning on adequate network features and doing technology-specific actions (e.g., Multiprotocol Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.). All of that happens using CPP-derived configuration information ⚙️✨
For traffic conformance purposes, a CPP also includes flow identification and classification rules. Participating nodes have to follow these whenever they process traffic according to a specific service as defined by that CPP 💅
The CPP template is meant to capture connectivity needs and represent and value those requirements in a standardized manner 🌸 But here's the tea: service- and Customer-specific IP provisioning rules can cause a dramatic increase in the number of IP transfer classes that need to be (pre-)engineered in the network 😭 So instantiating each CPP into a distinct class of service should be avoided, for the sake of performance and scalability.
Therefore, application-agnostic IP provisioning practices should be recommended 🧚 The requirements captured in the CPP can be used to identify which network class of service should be used to meet those requirements/guarantees. From that standpoint, the CPP concept is designed around a limited number of generic classes, so individual CPP documents can capture the connectivity requirements of services, applications, and Customers and then be easily mapped to those classes 💖
A CPP may also be used as a guideline for the network dimensioning and planning teams of a Network Provider. It helps them make sure 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:
- Facilitates the automation of the service negotiation and activation procedures, thus improving service delivery times;
- Can help set Traffic Engineering function and service management function objectives, for example, as a function of the number of CPP templates to be processed over a specific period of time; and
- 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 participating nodes need to apply and that are meant to accommodate those 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 in another business environment (where one administrative entity manages the service while another manages the network infrastructure). The following sections make no assumption about the business environment (integrated or not) ✨
Service differentiation at the network layer can be enforced by tweaking various parameters that belong to distinct dimensions (e.g., forwarding, routing, processing of incoming traffic, traffic classification, etc.). This document does not make any assumption about how network services are implemented within a networking infrastructure 🦋
Activating unicast or multicast capabilities to deliver a connectivity service can be explicitly requested by a Customer in a CPP, or it can be an engineering decision of a Network Provider based on the analysis of the Customer connectivity provisioning requirements 🫶
Examples of CPP usage include the northbound interface introduced by the Application-Based Network Operations (ABNO) framework [NET-OPS] and the technique for exposing network services and their characteristics defined in [RFC7149] 💜
1.3. Reference Architecture 🏗️
Customer Nodes belong to a Customer (including corporate Customers) or to 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. Higher-layer services (such as transport- and application-layer services) treat IP transfer capabilities as black boxes 📦 Appropriate notifications and reports would be communicated (through dedicated means) to Customer Nodes so they can assess the compliance of the experienced IP transfer service against what has been negotiated with the corresponding CPP. These notifications may also be used to assess the efficiency of the various policies enforced in the networking infrastructure to accommodate the requirements detailed in the CPP 🔍
The CPP reference architectures are depicted in Figures 3, 4, and 5 🎨
The Customer infrastructure can be connected over networking infrastructures managed by one or several Network Providers 🌸
.--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node |.--. .--.. . |Provider Node |
+--------------+ +--------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
Figure 3: Reference Architecture: Connectivity Service Provided by
the Same Network Provider Using Distinct Interconnection Nodes .--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+-----------------------------------+
| Provider Node |
+-----------------------------------+
( )
.-.' Network '.-.
( )
( . . . . . .)
'.-_-.'.-_-._.'.-_-.'.-_-.'.--.'
Figure 4: Reference Architecture: Connectivity Service Provided by
the Same Network Provider Using a Single Interconnection Node .--. .--.. .--..--.
( '.--.
.-.' Customer Infrastructure'.-.
( )
+-------------+ +-------------+
|Customer Node|.--. .--.. .--.|Customer Node|
+-------------+ +-------------+
| |
+--------------+ +--------------+
|Provider Node | |Provider Node |
+--------------+ +--------------+
( .--.) ( .--.)
.-.' Network A '.-. .-.' Network B '.-.
( ) ( )
(. . . .) (. . . .)
'.-_-.'.-_-._..' '.-_-.'.-_-._..'
Figure 5: Reference Architecture: Connectivity Services Provided by
Distinct Network Providers2. Scope of This Document 🔭
This document details the clauses of the CPP. Candidate protocols (e.g., [CPNP]) that can be used to negotiate and enforce a given CPP are not discussed in this document 🙅♀️
In addition to CPP clauses, other clauses may be included in an agreement between a Customer and a Provider (e.g., contact point, escalation procedure, incidents management, billing, etc.). It is out of the scope of this document to detail all those additional clauses 📝
Examples of how to translate CPP clauses into specific policies are provided for illustration purposes. It is out of the scope of this document to provide an exhaustive list of the technical means to meet the objectives detailed in a CPP 💭
CPP was mainly designed to target IP connectivity services. Nevertheless, it can be used for other non-IP transport schemes. It is out of the scope of this document to assess the applicability of CPP to these non-IP schemes 🌙
This document covers both unicast and multicast connectivity services. Both Any-Source Multicast (ASM, [RFC1112]) and Source-Specific Multicast (SSM, [RFC4607]) modes can be captured in a CPP 📡✨
3. Connectivity Provisioning Profile (CPP) 🎀
A CPP can be seen as the inventory of connectivity provisioning requirements with regard to the IP transfer service. CPP clauses are elaborated in the following sub-sections. The CPP template is provided in Section 4 💜
3.1. Customer Nodes Map 🗺️💖
okay so a CPP has to include the list of Customer Nodes (e.g., Customer Edges (CEs)) that are gonna get connected to the underlying IP transport network. 🧚
these nodes should be unambiguously identified (e.g., using a unique Service_identifier, Media Access Control (MAC) addresses, etc.). for each Customer Node, a border link or a node that belongs to the domain that connects the Customer Nodes should be identified. bestie, make it clear who's who ✨
this clause can specify geolocation information of Customer Nodes 🌍
based on the location of the Customer Node, appropriate operations to retrieve the corresponding border link or "Provider Node" (e.g., PE) should be undertaken. this operation can be manual or automated 🤖
a "service site" would be located behind a given Customer Node 🏠 a site identifier may be captured in the CPP for the provisioning of managed VPN services [RFC4026], for instance, Site_identifier.
a Customer Node may be connected to several Provider Nodes. multiple Customer Nodes may be connected to the same Provider Node as shown in Figure 4 🦋
3.2. Scope 🎯
the scope clause specifies the reachability of each of the involved Customer Nodes, from both incoming and outgoing traffic perspectives, so it totally yields specific traffic directionality considerations 🧭 it is defined as an unidirectional parameter. both directions should be described in the CPP.
the reachability scope specifies the set of destination prefixes that can be reached from a given Customer site (identified by a group of source prefixes). both global and restricted reachability scopes can be captured in the CPP. a global reachability scope means that a Customer site can reach any destination in the Internet and can be reached from any remote host 🌐 a restricted reachability scope means no global reachability is allowed. only a set of destinations can be reached from a Customer site, and/or only a set of sources can reach the Customer site 🙈 both incoming and outgoing reachability scopes are specified in the CPP.
both IPv4 and IPv6 reachability scopes may be specified 💜
the reachability scope clause can include multicast and/or unicast addresses. for SSM, a group of unicast source addresses can be specified in addition to destination multicast addresses 📡
the scope clause can also be used to delimit a topological (or geographical) network portion beyond which the performance and availability guarantees do not apply. a scope may be defined by a set of "Ingress" points and "Egress" points. several types may be considered, such as:
- (1) "1:1" Pipe model. only point-to-point communications are allowed. 🔗
- (2) "1:N" Hose model. only communications from one site towards a set of destinations are allowed. 🚰
- (3) "1:any" Unspecified hose model. all outbound communications are allowed. 🌊
the Ingress and Egress points could be Customer Nodes / Provider Nodes or external nodes, provided that these nodes are unambiguously identified (e.g., IPv6 prefix), or a set of IP destinations 💅
3.3. QoS Guarantees 🚀
QoS guarantees denote a set of IP transfer performance metrics that characterize the quality of the IP transfer treatment to be experienced (when crossing an IP transport infrastructure) by a flow issued from or forwarded to a (set of) "Customer Node(s)". it's giving performance vibes ⚡
IP performance metrics can be expressed as qualitative or quantitative parameters. both quantitative and qualitative guarantees cannot be specified in the same CPP 🙅♀️ quantitative guarantees may be specified as an average value, as a maximum bound, or as a percentile over an interval of measurements that should be indicated in the measurement method 📊
several performance metrics have been defined, such as:
these parameters may be specific to a given path or a given scope (e.g., between two Customer Nodes). IP performance metric values indicated in a CPP should reflect the measurement between a set of Customer Nodes or between a Customer Node and a set of Provider Nodes 🛣️
quantitative guarantees can only be specified for in-profile traffic (i.e., up to a certain traffic rate). a CPP can include throughput guarantees. when specified, these guarantees are equivalent to quantitative or qualitative loss guarantees 🧁
the Meta-QoS-Class concept can be used when qualitative metrics are used [RFC5160] ✨
3.4. Availability 🛡️
this clause specifies the percentage of the time during which the agreed IP performance guarantees apply. the clause can be expressed as a maximum or an average. the exact meaning of the clause value is defined during the CPP negotiation process 🤝
the guarantees cover both QoS deterioration (i.e., IP transfer service is available, but it is below the agreed performance bounds), physical failures, or service unavailability in general. in order to meet the availability guarantees, several engineering practices may be enforced at the border between the Customer and the Network Provider, such as multi-homing designs 💪
the following mechanisms are provided as examples to show that different technical options may be chosen to meet the service availability objectives 🧩
- When an Interior Gateway Protocol (IGP) instance is running between the "Customer Node" and the "Provider Node", activate a dedicated protocol, such as Bidirectional Forwarding Detection (BFD, [RFC5881][RFC5883]), to control IGP availability and to ensure sub-second IGP adjacency failure detection ⏱️
- Use of the Label Switched Path Ping (LSP Ping) capability to detect LSP availability (check whether the LSP is in place or not) [RFC4379][RFC6424][RFC6425][RFC6426][RFC6829] 🔍
- Pre-install backup LSPs for fast-reroute purposes when an MPLS network connects Customer Nodes [RFC4090] 🔁
- Enable Virtual Router Redundancy Protocol (VRRP, [RFC5798]) 🦸
- Enable IP Fast Reroute features (e.g., [RFC5286] or [RFC6981]) 🏃♀️💨
3.5. Capacity 📦
this clause characterizes the required capacity to be provided by the underlying IP transport network. this capacity is bound to a defined "Scope" (see Section 3.2) and IP transfer performance guarantees (see Sections 3.3 and 3.4) 🎀
the capacity may be expressed for both traffic directions (i.e., incoming and outgoing) and for every border link. the capacity clause defines the limits of the application of quantitative guarantees 📏
it is up to the administrative entity, which manages the IP transport network, to appropriately dimension its network [RFC5136] to meet the capacity requirements expressed in all negotiated CPPs. that's their job, not ours 💅
3.6. Conformance Traffic 🚦
when capacity information (see Section 3.5) is included in the CPP, requirements for out-of-profile traffic treatment need to be also expressed in the CPP 📝
shaping/policing filters may be applied so as to assess whether traffic is within the capacity profile or out of profile. out-of-profile traffic may be discarded or assigned another class (e.g., using Lower Effort Per-Domain Behavior (LE PDB) [RFC3662]) 🗑️
packet MTU conditions may also be indicated in the CPP 📐
3.7. Overall Traffic Guarantees 🌈
overall traffic guarantees are defined when the Capacity (Section 3.5) and Conformance Traffic (Section 3.6) clauses are not specified. or, if they are actually specified, then out-of-profile traffic is assigned another class of service but is not discarded. such guarantees can only be qualitative delay and/or qualitative loss or throughput guarantees 🫶
if overall traffic guarantees are not specified, best effort forwarding is implied 🤷♀️
3.8. Traffic Isolation 🔐
this clause indicates if the traffic issued by or destined to "Customer Nodes" should be isolated when crossing the IP transport network. this clause can also be used to specify additional security protection requirements (including privacy protection requirements). privacy is literally not optional 🙈
this clause can then be translated into VPN policy provisioning information, such as the information pertaining to the activation of dedicated tunnels using IPsec, BGP/MPLS VPN facilities [RFC4364], or a combination thereof. the activation of such features should be consistent with the availability and performance guarantees that have been negotiated 🧷
3.9. Flow Identification 🏷️
to identify the flows that need to be handled within the context of a given CPP, flow identifiers should be indicated in the CPP. flow identifiers are used for traffic classification purposes. an example of packet classifier is defined in [RFC2475] 🔎
a flow identifier may be composed of (but not limited to) the following parameters:
- Source IP address,
- Source port number,
- Destination IP address,
- Destination port number,
- Type of Service (ToS) or Differentiated Services Code Point (DSCP) field,
- Tail-end tunnel endpoint, or
- Any combination thereof.
distinct treatments may be implemented for elastic and non-elastic traffic (e.g., see the "Constraints on traffic" clause defined in [RFC5160]) 🎢
flow classification rules may be specific to a given link or may be applied for a group or all border links. this should be clearly captured in the CPP 💖
some practices such as DSCP re-marking may be indicated in the CPP. re-marking action is under the responsibility of underlying nodes that intervene to deliver the connectivity service. re-marking can be enforced for both outgoing and incoming traffic received from or destined to Customer Nodes. these re-marking actions must not alter the service-specific marking integrity (e.g., VPN service) 🚫
⚠️ bestie, the re-marking actions must not alter the service-specific marking integrity. that one is non-negotiable!
this clause may specify policies (e.g., DSCP re-marking) to be enforced at the egress nodes on packets received from Customer Nodes. if no such policy is specified, the Network Provider enforces its local policies (e.g., clear DSCP marking) on packets leaving its administrative domain 🧹
3.10. Routing and Forwarding 🗺️🧚
this clause is used to specify outsourced routing actions, such as installing dedicated routes to convey the traffic to its (service) destination. these dedicated routes may be computed, selected, and installed for Traffic Engineering or resilience purposes. for Traffic Engineering, these paths can be used to intelligently divert traffic away from some nodes/links that may potentially suffer from congestion or avoid crossing competitors' networks 🚧 for resilience, backup paths are typically pre-installed in order to bypass nodes/links under protection 🛟
this clause is also used to specify intermediate functions that must be invoked in the forwarding path (e.g., redirect the traffic to a firewall, invoke topology hiding features, etc.) or specify geographic routing restrictions 🧱
a requirement for setting up a logical routing topology [RFC4915] [RFC5120] may also be considered, e.g., to facilitate the management of the nodes that are involved in the forwarding of the traffic as defined in the CPP 🗂️
this practice should be indicated in the CPP; otherwise, path computation is left to the underlying IP routing capabilities. the forwarding behavior (e.g., Per-Domain Behavior (PDB) [RFC3086]) may also be specified in a CPP but remains optional. if indicated, consistency with the IP performance bounds defined in the CPP should be carefully ensured 🧐
for illustration purposes, a routing policy would avoid satellite links for Voice over IP (VoIP) deployments since this may degrade the offered service 🛰️📞 no satellites for calls, iykyk 💀
3.11. Activation Means ✨
Okay, so this clause tells you what has to happen to actually switch on access to the IP connectivity service 🔌 Think of it as the "turn it on" step. 💖
Some examples are spinning up an IGP instance, setting up a BGP [RFC4271] or Multiprotocol BGP (MP-BGP) session [RFC4760], or getting Protocol Independent Multicast (PIM, [RFC4601]) running, etc. 🧚
3.12. Invocation Means 🦋
Two types are defined, and they're giving very different vibes 💅
- Implicit: This clause says no explicit means is needed to invoke the connectivity service. Access is mostly decided by the network capacity you request. Simple, clean, no drama 🌸
- Explicit: This clause says you DO need explicit means to access the connectivity service. Examples include RSVP [RFC2205], RSVP-TE [RFC3209], Internet Group Management Protocol (IGMP, [RFC3376]), or Multicast Listener Discovery (MLD, [RFC3810]). Appropriate admission control procedures [RFC6601] would have to be enforced, e.g., to check whether the capacity actually used is not above the agreed threshold. The gatekeeping is real, bestie 👑
3.13. Notifications 🔥
For operation purposes (like supervision) and service fulfillment needs, management platforms need to be notified about critical events that may impact the delivery of the service. Keeping the management platform in the loop is literally non-negotiable 😭
The notification procedure should be indicated in the CPP. This procedure may specify the type of information to be sent, the interval, the data model, etc. 📋
Notifications can be sent to the management platform by using Simple Network Management Protocol (SNMP, [RFC3416]), Syslog notifications [RFC5424], Connectivity Provisioning Negotiation Protocol (CPNP) signals [CPNP], Network Configuration Protocol (NETCONF) Event Notifications [RFC5277], or a phone call! 📞🙈
4. CPP Template 🎀
Figure 6 gives you the Routing Backus-Naur Form (RBNF, [RFC5511]) format of the CPP template. This is the blueprint, so pay attention 💜
A CPP document includes several connectivity provisioning components, and each one is structured as a CPP. The CPP may also include additional optional information elements, like metrics used for Service Assurance purposes, an activation schedule, etc. ✨
<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<Connectivity Provisioning Component> ...
<Connectivity Provisioning Component> ::=
<CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE> ::=
<Customer Nodes Map>
<Scope>
<QoS Guarantees>
<Availability>
<Capacity>
<Traffic Isolation>
<Conformance Traffic>
<Flow Identification>
<Overall Traffic Guarantees>
<Routing and Forwarding>
<Activation Means>
<Invocation Means>
<Notifications>
<Optional Information Element> ...
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALIZATION>
Figure 6: CPP TemplateThe description of these clauses is in Section 3. 🌈
The CPP may also include a Customer's administrative info, like a name and other contact details. Figure 7 shows the RBNF format for that 🧡
<Customer Description> ::= <NAME> <Contact Information>
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 7: Customer Description ClauseThe CPP may include administrative info for the Network Provider too (name, Autonomous System number(s), and other contact details). Figure 8 shows the RBNF format for the provider's info 🍓
<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Figure 8: Provider Description Clause5. Security Considerations 🔐
This document does not define an architecture or specify a protocol. Yet, the means to provide guarantees about the identity of a Customer and its ability to expose connectivity requirements to a Network Provider through a CPP need to be investigated. Likewise, the means to provide guarantees about the identity of a Network Provider and the ability to expose its capabilities, let alone capture the requirements of a Customer through a CPP, should be carefully studied. This is a big open question, babe 😳
CPP documents should be protected against illegitimate modifications (e.g., modification, withdrawal); authorization means should be enabled. These means are deployment-specific. 🚨
The Network Provider must enforce means to protect privacy-related information captured in a CPP document [RFC6462]. In particular, this information must not be revealed to external parties without the consent of Customers. Network Providers should enforce policies to make Customer fingerprinting more difficult to achieve. This part is SERIOUS, no cap 💀 For more discussion about privacy, refer to [RFC6462] and [RFC6973].
6. Acknowledgements 🫶
Some of the items in this document are the result of several discussions with E. Mykoniati and D. Griffin. Special thanks to them 💜
Many thanks to P. Georgatsos for the discussions and the detailed review of this document 🌸
Thanks to S. Shah, G. Huston, D. King, and S. Bryant for reviewing the document and providing useful comments ✨
7. Informative References ✨
okay bestie, this is the reading list 📚 these are the docs the spec points to for background. The heading says "Informative," so they're context, not required reading to implement the thing. Here's the full list, copied exactly so nothing gets lost 🫶
[CPNP] Boucadair, M., Jacquenet, C., and D. Zhang, "Connectivity
Provisioning Negotiation Protocol (CPNP)", Work in
Progress, June 2014.
[NET-OPS] King, D. and A. Farrel, "A PCE-based Architecture for
Application-based Network Operations", Work in Progress,
February 2014.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway
Control Protocol Architecture and Requirements", RFC 2805,
April 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
Christian, B., and W. Lai, "Applicability Statement for
Traffic Engineering with MPLS", RFC 3346, August 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
4915, June 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, February 2008.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, March 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, November 2011.
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
S., and T. Nadeau, "Detecting Data-Plane Failures in
Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
6425, November 2011.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
RFC 6462, January 2012.
[RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission
Control (GCAC) Algorithm Specification for IP/MPLS
Networks", RFC 6601, April 2012.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
Switched Path (LSP) Ping for Pseudowire Forwarding
Equivalence Classes (FECs) Advertised over IPv6", RFC
6829, January 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
August 2013.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014.Authors' Addresses 🎀
and that's the whole crew! 🫶 here are the people who wrote it, with their addresses and emails exactly as listed 💌
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
EMail: christian.jacquenet@orange.com
Ning Wang
University of Surrey
Guildford
UK
EMail: n.wang@surrey.ac.uk📦 where this page comes from
- ietf: rfc7297 2014-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms