idnits 2.17.1 draft-boucadair-connectivity-provisioning-profile-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2014) is 3668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3376' is defined on line 835, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-02 == Outdated reference: A later version (-16) exists of draft-farrkingel-pce-abno-architecture-07 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6829 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: October 13, 2014 N. Wang 6 University of Surrey 7 April 11, 2014 9 IP Connectivity Provisioning Profile (CPP) 10 draft-boucadair-connectivity-provisioning-profile-05 12 Abstract 14 This document describes the Connectivity Provisioning Profile (CPP) 15 and proposes a CPP Template to capture IP connectivity requirements 16 to be met within a service delivery context (e.g., Voice over IP or 17 IP TV). The CPP defines the set of IP transfer parameters to be 18 supported by the underlying transport network together with a 19 reachability scope and bandwidth/capacity needs. Appropriate 20 performance metrics such as one-way delay or one-way delay variation 21 are used to characterize an IP transfer service. Both global and 22 restricted reachability scopes can be captured in the CPP. 24 Such a generic CPP template is meant to (1) facilitate the automation 25 of the service negotiation and activation procedures, thus 26 accelerating service provisioning, (2) set (traffic) objectives of 27 Traffic Engineering functions and service management functions and 28 (3) improve service and network management systems with 'decision- 29 making' capabilities based upon negotiated/offered CPPs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 13, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Connectivity Provisioning Interface (CPI) . . . . . . . . 3 67 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Reference Architecture . . . . . . . . . . . . . . . . . 6 69 2. Scope of this Document . . . . . . . . . . . . . . . . . . . 8 70 3. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 9 71 3.1. Customer Nodes . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . 11 74 3.4. Availability Guarantees . . . . . . . . . . . . . . . . . 11 75 3.5. Capacity . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 12 77 3.7. Overall Traffic Guarantees . . . . . . . . . . . . . . . 13 78 3.8. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 13 79 3.9. Flow Identification . . . . . . . . . . . . . . . . . . . 13 80 3.10. Routing & Forwarding . . . . . . . . . . . . . . . . . . 14 81 3.11. Activation Means . . . . . . . . . . . . . . . . . . . . 15 82 3.12. Invocation Means . . . . . . . . . . . . . . . . . . . . 15 83 3.13. Notifications . . . . . . . . . . . . . . . . . . . . . . 15 84 4. CPP Template . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 8. Informative References . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 This document describes the Connectivity Provisioning Profile (CPP) 94 and proposes a CPP Template to capture IP/MPLS connectivity 95 requirements to be met within a service delivery context (e.g., Voice 96 over IP, IP TV, VPN services). 98 In this document, the IP connectivity service is the IP transfer 99 capability characterized by a (Source Nets, Destination Nets, 100 Guarantees, Scope) tuple where "Source Nets" are a group of unicast 101 IP addresses, "Destination Nets" are a group of IP unicast and/or 102 multicast addresses, "Guarantees" reflect the guarantees (expressed 103 in terms of QoS (Quality Of Service), performance and availability, 104 for example) to properly forward traffic to the said "Destination". 105 Finally, the "Scope" denotes the (network) perimeter (e.g., between 106 PE (Provider Equipment) routers or Customer Nodes) where the said 107 guarantees need to be provided. 109 1.1. Connectivity Provisioning Interface (CPI) 111 Figure 1 shows the various connectivity provisioning interfaces 112 covered by CPP: the Customer-Network Connectivity Provisioning 113 Interface, the Service-Network Connectivity Provisioning Interface, 114 and the Network-Network Connectivity Provisioning Interface. 115 Services and applications whose parameters are captured by means of a 116 CPP exchanged through the Service-Network Connectivity Provisioning 117 Interface may be provided by the same administrative entity that 118 operates the underlying network, or by another entity (for example, a 119 Content Provider). 121 +---------+ 122 |Service A| 123 +---+-----+ 124 | +---------+ 125 |CPI |Service B| 126 | +-+-------+ 127 | |CPI 128 +----------+ +-+------+-------+ +------------+ 129 |Subscriber|-----|Network Provider|-----|Peer Network| 130 +----------+ CPI +----------------+ CPI +------------+ 132 Figure 1: Connectivity Provisioning Interfaces 134 The interfaces depicted in Figure 1, can be summarized as shown in 135 Figure 2. 137 The Customer shown in Figure 2 may be another Network Provider (e.g., 138 an IP transit provider), a Service Provider (e.g., an IP telephony 139 Service Provider) which requires the invocation of resources provided 140 by a Network Provider, or an enterprise which wants to interconnect 141 its various sites by subscribing to a VPN service provided by a 142 Network Provider. The proposed CPP can be used to expose, capture, 143 and facilitate the negotiation of the service parameters between 144 these various entities, thereby presenting a common template for 145 describing the available connectivity services. 147 +----------------+ 148 | Customer | 149 +-------+--------+ 150 + CPI 151 +-------+--------+ 152 |Network Provider| 153 +----------------+ 155 Figure 2: CPP: Generic Connectivity Provisioning Interfaces 157 In the rest of the document, "Customer" is used as a generic term to 158 denote the business entity that subscribes to connectivity services 159 offered by a Network Provider (Figure 2). 161 1.2. Rationale 163 Procedures for the design and the operation of IP services have 164 become increasingly diverse and complex. The time it takes to 165 negotiate service parameters and then proceed with the corresponding 166 resource allocation can thus be measured in days, if not weeks. Yet, 167 the bilateral discussions that usually take place between a customer 168 and a Network Provider hardly rely upon some kind of standard 169 checklist, where the customer would be invited to tick all the 170 parameters that apply to its environment, and then negotiate these 171 parameters with the Network Provider, as a function of the available 172 resources, the customer's expectations, the provider's network 173 planning policy, etc. 175 The definition of a clear interface between the service (including 176 third-party applications) and the network layers would therefore 177 facilitate the said discussion, thereby improving the overall service 178 delivery procedure by optimizing the design of the network 179 infrastructures. Indeed, the CPP interface aims at exposing and 180 characterizing, in a technology-agnostic manner, the IP transfer 181 requirements to be met when invoking IP transfer capabilities of a 182 network operated by a Network Provider between a set of Customer 183 Nodes (e.g., Media Gateway (section 11.2.7 [RFC2805]), Session Border 184 Controller [RFC5853], etc.). 186 These requirements include: reachability scope (e.g., limited scope, 187 Internet-wide), direction, bandwidth requirements, QoS parameters 188 (e.g., one-way delay [RFC2679], loss [RFC2680] or one-way delay 189 variation [RFC3393]), protection and high availability guidelines 190 (e.g., sub-50ms/sub-100ms/second restoration). 192 These requirements are then translated into IP/MPLS-related technical 193 clauses (e.g., need for recovery means, definition of the class of 194 service, need for control plane protection, etc.). In a later stage, 195 these various clauses will be addressed by the activation of adequate 196 network features and technology-specific actions (e.g., MPLS-TE 197 (Multiprotocol Label Switching TE, [RFC3346]), RSVP (Resource 198 Reservation Protocol, [RFC2205]), OSPF (Open Shortest Path First) or 199 IS-IS (Intermediate System to Intermediate System), etc.), by means 200 of CPP-derived configuration information. 202 For traffic conformance purposes, a CPP also includes flow 203 identification and classification rules to be followed by 204 participating nodes whenever they have to process traffic according 205 to a specific service as defined by the said CPP. 207 The CPP template aims at capturing connectivity needs and to 208 represent and value these requirements in a standardized manner. 209 Service- and Customer-specific IP provisioning rules may lead to a 210 dramatic increase of the number of IP transfer classes that need to 211 be (pre)-engineered in the network. Instantiating each CPP into a 212 distinct class of service should therefore be avoided for the sakes 213 of performance and scalability. 215 Therefore, application-agnostic IP provisioning practices should be 216 recommended since the requirements captured in the CPP can be used to 217 identify which network class of service is to be used to meet those 218 requirements/guarantees. From that standpoint, the CPP concept is 219 meant to design a limited number of generic classes, so that 220 individual CPP documents, by capturing the connectivity requirements 221 of services, applications and Customers, can be easily mapped to 222 these classes. 224 CPP may also be used as a guideline for network dimensioning and 225 planning teams of a Network Provider to ensure that appropriate 226 resources (e.g., network cards, routers, link capacity, etc.) have 227 been provisioned. Otherwise, (underlying) transport networks would 228 not be able to meet the objectives expressed in all CPP requests. 230 Such a generic CPP template: 232 o Facilitates the automation of the service negotiation and 233 activation procedures, thus improving service delivery times; 234 o Can help setting Traffic Engineering function and service 235 management function objectives, as a function of the number of CPP 236 templates to be processed over a specific period of time, for 237 example. 238 o Improves service and network management systems by adding 239 'decision-making' capabilities based upon negotiated/offered CPPs. 241 In addition, this CPP abstraction makes a clear distinction between 242 the connectivity provisioning requirements and the associated 243 technology-specific rules that need to be applied by participating 244 nodes, and which are meant to accommodate such requirements. 246 The CPP defines the set of IP/MPLS transfer guarantees to be offered 247 by the underlying transport network together with a reachability 248 scope and capacity needs. Appropriate performance metrics such as 249 one-way delay or one-way delay variation are used to characterize the 250 IP transfer service. Guarantees related to availability and 251 resiliency are also included in the CPP. 253 The CPP can be used in an integrated business environment (where the 254 service and network infrastructures are managed by the same 255 administrative entity) or another business environment (where an 256 administrative entity manages the service while another manages the 257 network infrastructure). In the following sections, no assumption is 258 made about the business environment (integrated or not). 260 Service differentiation at the network layer can be enforced by 261 tweaking various parameters which belong to distinct dimensions (e.g, 262 forwarding, routing, processing of incoming traffic, traffic 263 classification, etc.). This document does not make any assumption on 264 how network services are implemented within an networking 265 infrastructure. 267 Activating unicast or multicast capabilities to deliver a 268 connectivity service can be explicitly requested by a Customer in a 269 CPP, or can be an engineering decision of a Network Provider based on 270 the analysis of the Customer connectivity provisioning requirements. 272 An example of CPP usage is through the northbound interface 273 introduced by the Application-based Network Operations (ABNO) 274 framework [I-D.farrkingel-pce-abno-architecture] or as a technique 275 for exposing network services and their characteristics defined in 276 [RFC7149]. 278 1.3. Reference Architecture 280 Customer Nodes belong to a Customer (including corporate Customers) 281 or a service infrastructure (see Figure 1). In some contexts, 282 Customer Nodes can be provided and managed by the Network Provider. 283 The connectivity between these Customer Nodes reflects the IP 284 transfer capability implemented thanks to the allocation of a set of 285 IP resources. IP transfer capabilities are considered by the above 286 services as black boxes. Appropriate notifications and reports would 287 be communicated (through dedicated means) to Customer Nodes to assess 288 the compliance of the experienced IP transfer service against what 289 has been negotiated with the corresponding CPP. These notifications 290 may also be used to assess the efficiency of the various policies 291 enforced in the networking infrastructure to accommodate the 292 requirements detailed in the CPP. 294 The CPP reference architectures are depicted in Figure 3, Figure 4, 295 and Figure 5. 297 The Customer infrastructure can be connected over networking 298 infrastructures managed by one or several Network Providers. 300 .--. .--.. .--..--. 301 ( '.--. 302 .-.' Customer Infrastructure'.-. 303 ( ) 304 +-------------+ +-------------+ 305 |Customer Node|.--. .--.. .--.|Customer Node| 306 +-------------+ +-------------+ 307 | | 308 +--------------+ +--------------+ 309 |Provider Node |.--. .--.. . |Provider Node | 310 +--------------+ +--------------+ 311 ( ) 312 .-.' Network '.-. 313 ( ) 314 ( . . . . . .) 315 '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' 317 Figure 3: Reference Architecture: Connectivity service provided by 318 the same Network Provider using distinct interconnection nodes 319 .--. .--.. .--..--. 320 ( '.--. 321 .-.' Customer Infrastructure'.-. 322 ( ) 323 +-------------+ +-------------+ 324 |Customer Node|.--. .--.. .--.|Customer Node| 325 +-------------+ +-------------+ 326 | | 327 +-----------------------------------+ 328 | Provider Node | 329 +-----------------------------------+ 330 ( ) 331 .-.' Network '.-. 332 ( ) 333 ( . . . . . .) 334 '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' 336 Figure 4: Reference Architecture: Connectivity service provided by 337 the same Network Provider using via one single interconnection node 339 .--. .--.. .--..--. 340 ( '.--. 341 .-.' Customer Infrastructure'.-. 342 ( ) 343 +-------------+ +-------------+ 344 |Customer Node|.--. .--.. .--.|Customer Node| 345 +-------------+ +-------------+ 346 | | 347 +--------------+ +--------------+ 348 |Provider Node | |Provider Node | 349 +--------------+ +--------------+ 350 ( .--.) ( .--.) 351 .-.' Network A '.-. .-.' Network B '.-. 352 ( ) ( ) 353 (. . . .) (. . . .) 354 '.-_-.'.-_-._..' '.-_-.'.-_-._..' 356 Figure 5: Reference Architecture: Connectivity services provided by 357 distinct Network Providers 359 2. Scope of this Document 361 This document details the clauses of the CPP. Candidate protocols 362 (e.g., [I-D.boucadair-connectivity-provisioning-protocol]) that can 363 be used to negotiate and enforce a given CPP are not discussed in 364 this document. 366 In addition to CPP clauses, other clauses may be included in an 367 agreement between a Customer and a Provider (e.g., contact point, 368 escalation procedure, incidents management, billing, etc.). It is 369 out of scope of this document to detail all those additional clauses. 371 Examples of how to translate CPP clauses into specific policies are 372 provided for illustration purposes. It is out of scope of this 373 document to provide an exhaustive list of the technical means to meet 374 the objectives detailed in a CPP. 376 CPP was mainly designed to target IP connectivity services. 377 Nevertheless, it can be used for other non-IP transport schemes. It 378 is out of scope of this document to assess the applicability of CPP 379 to these non-IP schemes. 381 This document covers both unicast and multicast connectivity 382 services. Both Any-Source Multicast (ASM, [RFC1112]) and Source- 383 Specific Multicast (SSM, [RFC4607]) modes can be captured in a CPP. 385 3. Connectivity Provisioning Profile (CPP) 387 A CPP can be seen as the inventory of connectivity provisioning 388 requirements with regard to the IP transfer service. CPP clauses are 389 elaborated in the following sub-sections. The CPP template is 390 provided in Section 4. 392 3.1. Customer Nodes 394 A CPP must include the list of Customer Nodes (e.g., CEs) to be 395 connected to the underlying IP transport network. 397 These nodes should be unambiguously identified (e.g., using a unique 398 Service_identifier, MAC addresses, etc.). For each Customer Node, a 399 border link or a node that belongs to the domain that connects the 400 Customer Nodes should be identified. 402 This clause can specify geolocation information of Customer Nodes. 404 Based on the location of the Customer Node, appropriate operations to 405 retrieve the corresponding border link or "Provider Node" (e.g., PE) 406 should be undertaken. This operation can be manual or automated. 408 A "service site" would be located behind a given Customer Node. A 409 site identifier may be captured in the CPP for the provisioning of 410 managed VPN services [RFC4026] for instance (e.g., Site_identifier). 412 A Customer Node may be connected to several Provider Nodes and 413 multiple Customer Nodes may be connected to the same Provider Node 414 (see Figure 3). 416 3.2. Scope 418 The scope clause specifies the reachability of each of involved 419 Customer Nodes, from both an incoming and outgoing traffic 420 perspectives, thereby yielding specific traffic directionality 421 considerations. It is defined as an unidirectional parameter. Both 422 directions should be described in the CPP. 424 The reachability scope specifies the set of destination prefixes that 425 can be reached from a given customer site (identified by a group of 426 source prefixes). Both global and restricted reachability scopes can 427 be captured in the CPP. A global reachability scope means that a 428 customer site can reach any destination in the Internet and can be 429 reached from any remote host. A restricted reachability scope means 430 no global reachability is allowed; only a set of destinations can be 431 reached from a customer site, and/or only a set of sources can reach 432 the customer site. Both incoming and outgoing reachability scopes 433 are specified in the CPP. 435 Both IPv4 and IPv6 reachability scopes may be specified. 437 The reachability scope clause can include multicast and/or unicast 438 addresses. For SSM, a group of unicast source addresses can be 439 specified in addition to destination multicast addresses. 441 The scope clause can also be used to delimit a topological (or 442 geographical) network portion beyond which the performance and 443 availability guarantees do not apply. A scope may be defined by a 444 set of "Ingress" points and "Egress" points. Several types may be 445 considered, such as: 447 (1) "1:1" Pipe model. Only point-to-point communications are 448 allowed. 449 (2) "1:N" Hose model. Only communications from one site towards a 450 set of destinations are allowed. 451 (3) "1:any" Unspecified hose model. All outbound communications 452 are allowed. 454 The Ingress and Egress points could be Customer Nodes/Provider Nodes 455 or external nodes, provided that these nodes are unambiguously 456 identified (e.g., IPv6 prefix), or a set of IP destinations. 458 3.3. QoS Guarantees 460 QoS guarantees denote a set of IP transfer performance metrics which 461 characterize the quality of the IP transfer treatment to be 462 experienced (when crossing an IP transport infrastructure) by a flow 463 issued from or forwarded to a (set of) "Customer Node(s)". 465 IP performance metrics can be expressed as qualitative or 466 quantitative parameters (both quantitative and qualitative guarantees 467 cannot be specified in the same CPP). Quantitative guarantees may be 468 specified as an average value, as a maximum bound, or as a percentile 469 over an interval of measurements which should be indicated in the 470 measurement method. 472 Several performance metrics have been defined such as: 474 o Traffic Loss [RFC2680] 475 o One way delay [RFC2679] 476 o One way delay variation [RFC3393] 478 These parameters may be specific to a given path or a given scope 479 (e.g., between two Customer Nodes). IP performance metric values 480 indicated in a CPP should reflect the measurement between a set of 481 Customer Nodes or between a Customer Node and a set of Provider 482 Nodes. 484 Quantitative guarantees can only be specified for in-profile traffic 485 (i.e., up to a certain traffic rate). A CPP can include throughput 486 guarantees; when specified, these guarantees are equivalent to 487 quantitative or qualitative loss guarantees. 489 the Meta-QoS class concept can be used when qualitative metrics are 490 used [RFC5160]. 492 3.4. Availability Guarantees 494 This clause specifies the percentage of the time during which the 495 agreed IP performance guarantees apply. The clause can be expressed 496 as maximum/average. The exact meaning of the clause value is defined 497 during the CPP negotiation process. 499 The guarantees cover both QoS deterioration (i.e., IP transfer 500 service is available but it is below the agreed performance bounds), 501 physical failures or service unavailability in general. In order to 502 meet the availability guarantees, several engineering practices may 503 be enforced at the border between the customer and the Network 504 Provider, such as multi-homing designs. 506 The following mechanisms are provided as examples that show that 507 different technical options may be chosen to meet the service 508 availability objectives: 510 o When an IGP (Interior Gateway Protocol) instance is running 511 between the "Customer Node" and the "Provider Node", activate a 512 dedicated protocol, such as BFD (Bi-directional Forwarding 513 Detection [RFC5881][RFC5883]), to control IGP availability and to 514 ensure sub-second IGP adjacency failure detection. 515 o Use of Label Switched Path Ping (LSP Ping) capability to detect 516 LSP availability (check whether the LSP is in place or not) 517 [RFC4379][RFC6424][RFC6425][RFC6426][RFC6829]. 518 o Pre-install backup LSPs for fast-reroute purposes, when a MPLS 519 network connects Customer Nodes [RFC4090]. 520 o Enable VRRP (Virtual Router Redundancy Protocol, [RFC5798]). 521 o Enable IP Fast Reroute features (e.g., [RFC5286] or [RFC6981]). 523 3.5. Capacity 525 This clause characterizes the required capacity to be provided by the 526 underlying IP transport network. This capacity is bound to a defined 527 "Scope" (See Section 3.2) and IP transfer performance guarantees (see 528 Section 3.3 and Section 3.4). 530 The capacity may be expressed for both traffic directions (i.e., 531 incoming and outgoing) and for every border link. The capacity 532 clause defines the limits of the application of quantitative 533 guarantees. 535 It is up to the administrative entity, which manages the IP transport 536 network, to appropriately dimension its network [RFC5136] to meet the 537 capacity requirements expressed in all negotiated CPPs. 539 3.6. Conformance Traffic 541 When capacity information (see Section 3.5) is included in the CPP, 542 requirements for Out-of-Profile traffic treatment need to be also 543 expressed in the CPP. 545 Shaping/policing filters may be applied so as to assess whether 546 traffic is within the capacity profile or out of profile. Out-of- 547 Profile traffic may be discarded or assigned another class (e.g., 548 using the Lower than Best Effort Per Domain Behavior (LE PDB) 549 [RFC3662]). 551 Packet MTU conditions may also be indicated in the CPP. 553 3.7. Overall Traffic Guarantees 555 Overall traffic guarantees are defined when Traffic Volume 556 (Section 3.5) and Conformance (Section 3.6) clauses are not 557 specified. Or if they are actually specified, then Out-of-Profile 558 traffic is assigned another class of service, but is not discarded. 559 Such guarantees can only be qualitative delay and/or qualitative loss 560 or throughput guarantees. 562 If overall traffic guarantees are not specified, best effort 563 forwarding is implied. 565 3.8. Traffic Isolation 567 This clause indicates if the traffic issued by/destined to "Customer 568 Nodes" should be isolated when crossing the IP transport network. 569 This clause can also be used to specify additional security 570 protection requirements (including privacy protection requirements). 572 This clause can then be translated into VPN policy provisioning 573 information, such as the information pertaining to the activation of 574 dedicated tunnels using IPsec, BGP/MPLS VPN facilities [RFC4364], or 575 a combination thereof. The activation of such features should be 576 consistent with the availability and performance guarantees that have 577 been negotiated. 579 3.9. Flow Identification 581 To identify the flows that need to be handled within the context of a 582 given CPP, flow identifiers should be indicated in the CPP. Flow 583 identifiers are used for traffic classification purposes. An example 584 of packet classifier is defined in [RFC2475]. 586 A flow identifier may be composed of the following parameters (but 587 not limited to): 589 o Source IP address, 590 o Source port number, 591 o Destination IP address, 592 o Destination port number, 593 o ToS (Type of Service) or DSCP (Differentiated Services Code Point) 594 field, 595 o Tail-end tunnel endpoint, or 596 o Any combination thereof. 598 Distinct treatments may be implemented for elastic and non elastic 599 traffic (e.g., see the "Constraints on traffic" clause defined in 600 [RFC5160]). 602 Flow classification rules may be specific to a given link, or may be 603 applied for a group or all border links. This should be clearly 604 captured in the CPP. 606 Some practices such as DSCP re-marking may be indicated in the CPP. 607 Re-marking action is under the responsibility of underlying nodes 608 that intervene to deliver the connectivity service. Re-marking can 609 be enforced for both outgoing and incoming traffic received from/ 610 destined to Customer Nodes. These re-marking actions must not alter 611 the service-specific marking integrity (e.g., VPN service). 613 This clause may specify policies (e.g., DSCP re-marking) to be 614 enforced at the egress nodes on packets received from Customer Nodes. 615 If no such policy is specified, the Network Provider enforces its 616 local policies (e.g., clear DSCP marking) on packets leaving its 617 administrative domain. 619 3.10. Routing & Forwarding 621 This clause is used to specify outsourced routing actions such as 622 installing dedicated routes to convey the traffic to its (service) 623 destination. These dedicated routes may be computed, selected and 624 installed for Traffic Engineering or resilience purposes. For 625 Traffic Engineering these paths can be used for intelligently divert 626 traffic away from some nodes/links that may potentially suffer from 627 congestion or avoid crossing competitors networks, while for 628 resilience backup paths are typically pre-installed in order to 629 bypass nodes/links under protection. 631 This clause is also used to specify intermediate functions that must 632 be invoked in the forwarding path (e.g., redirect the traffic to a 633 firewall, invoke topology hiding features, etc.) or specify 634 geographic routing restrictions. 636 A requirement for setting up a logical routing topology may also be 637 considered [RFC4915] or [RFC5120], e.g., to facilitate the management 638 of the nodes that are involved in the forwarding of the traffic as 639 defined in the CPP. 641 This practice should be indicated in the CPP, otherwise path 642 computation is left to the underlying IP routing capabilities. The 643 forwarding behavior (e.g., Per Domain Behavior (PDB) [RFC3086]) may 644 also be specified in a CPP, but remains optional. If indicated, 645 consistency with the IP performance bounds defined in the CPP should 646 be carefully ensured. 648 For illustration purposes, a routing policy would be to avoid 649 satellite links for VoIP (Voice over IP) deployments since this may 650 degrade the offered service. 652 3.11. Activation Means 654 This clause indicates the required action(s) to be undertaken to 655 activate access to the IP connectivity service. 657 Examples of these actions would be the activation of an IGP instance, 658 the establishment of a BGP [RFC4271] or MP-BGP session [RFC4760], PIM 659 (Protocol Independent Multicast, [RFC4601]), etc. 661 3.12. Invocation Means 663 Two types are defined: 665 Implicit: This clause indicates that no explicit means to invoke the 666 connectivity service is required. Access to the connectivity 667 service is primarily conditioned by the requested network 668 capacity. 669 Explicit: This clause indicates the need for explicit means to 670 access the connectivity service. Examples of such means include 671 the use of RSVP [RFC2205], RSVP-TE [RFC3209], IGMP (Internet Group 672 Management Protocol,[RFC3376]), or MLD (Multicast Listener 673 Discovery, [RFC3810]). Appropriate access control procedures 674 [RFC6601] would have to be enforced, e.g., to check whether the 675 capacity actually used is not above the agreed threshold. 677 3.13. Notifications 679 For operation purposes (e.g., supervision) and service fulfillment 680 needs, management platforms need to be notified about critical events 681 which may impact the delivery of the service. 683 The notification procedure should be indicated in the CPP. This 684 procedure may specify the type of information to be sent, the 685 interval, the data model, etc. 687 Notifications can be sent to the management platform by using SNMP 688 (Simple Network Management Protocol, [RFC3416]), Syslog notifications 689 [RFC5424], CPNP signals 690 [I-D.boucadair-connectivity-provisioning-protocol], NETCONF Event 691 Notifications [RFC5277], or a phone call! 693 4. CPP Template 695 Figure 6 provides the RBNF (Routing Backus-Naur Form, [RFC5511]) 696 format of the CPP template. 698 A CPP document includes several connectivity provisioning components; 699 each of these is structured as a CPP. The CPP may include additional 700 optional information elements such as metrics used for Service 701 Assurance purposes, activation schedule, etc. 703 ::= 704 ... 705 ::= 706 ... 707 ::= 708 709 710 711 712 713 714 715 716 717 718 719 720 721 ... 722 ::= ... 723 ::= 724 725 727 Figure 6: CPP Template 729 The description of these clauses is provided in Section 3. 731 The CPP may also include Customer's administrative information, such 732 as a name and other contact details. An example of the RBNF format 733 of the Customer's information is shown in Figure 7. 735 ::= 736 ::= [] 737 [ ...] 739 Figure 7: Customer Description Clause 741 The CPP may include administrative information of the Network 742 Provider too (name, AS number(s), and other contact details). An 743 example of the RBNF format of the provider's information is shown in 744 Figure 8. 746 ::= [] 747 ::= [] 748 [ ...] 750 Figure 8: Provider Description Clause 752 5. IANA Considerations 754 This document does not require any action from IANA. 756 6. Security Considerations 758 This document does not define an architecture nor specify a protocol. 759 Yet, means to guarantee the identity and the ability of a Customer to 760 expose its connectivity requirements to a Network Provider through a 761 CPP and, likewise, means to guarantee the identity and the ability of 762 a Network Provider to expose its capabilities and to capture the 763 requirements of a Customer through a CPP should be properly 764 investigated. 766 CPP documents should be protected against illegitimate modifications 767 (e.g., modification, withdrawal); authorization means should be 768 enabled. These means are deployment-specific. 770 The Network Provider must enforce means to protect privacy-related 771 information captured in a CPP document [RFC6462]. In particular, 772 this information must not be revealed to external parties without the 773 consent of customers. Network Providers should enforce policies to 774 make customer fingerprinting more difficult to achieve. For more 775 discussion about privacy, refer to [RFC6462] and [RFC6973]. 777 7. Acknowledgements 779 Some of the items listed above are the results of several discussions 780 with E. Mykoniati and D. Griffin. Special thanks to them. 782 Many thanks to P. Georgatsos for the discussions and the detailed 783 review of this document. 785 S. Shah, G. Huston, D. King, and S. Bryant who reviewed the document 786 and provided useful comments. 788 8. Informative References 790 [I-D.boucadair-connectivity-provisioning-protocol] 791 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 792 Negotiation Protocol (CPNP)", draft-boucadair- 793 connectivity-provisioning-protocol-02 (work in progress), 794 March 2014. 796 [I-D.farrkingel-pce-abno-architecture] 797 King, D. and A. Farrel, "A PCE-based Architecture for 798 Application-based Network Operations", draft-farrkingel- 799 pce-abno-architecture-07 (work in progress), February 800 2014. 802 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 803 RFC 1112, August 1989. 805 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 806 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 807 Functional Specification", RFC 2205, September 1997. 809 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 810 and W. Weiss, "An Architecture for Differentiated 811 Services", RFC 2475, December 1998. 813 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 814 Delay Metric for IPPM", RFC 2679, September 1999. 816 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 817 Packet Loss Metric for IPPM", RFC 2680, September 1999. 819 [RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway 820 Control Protocol Architecture and Requirements", RFC 2805, 821 April 2000. 823 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 824 Differentiated Services Per Domain Behaviors and Rules for 825 their Specification", RFC 3086, April 2001. 827 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 828 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 829 Tunnels", RFC 3209, December 2001. 831 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 832 Christian, B., and W. Lai, "Applicability Statement for 833 Traffic Engineering with MPLS", RFC 3346, August 2002. 835 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 836 Thyagarajan, "Internet Group Management Protocol, Version 837 3", RFC 3376, October 2002. 839 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 840 Metric for IP Performance Metrics (IPPM)", RFC 3393, 841 November 2002. 843 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 844 Simple Network Management Protocol (SNMP)", STD 62, RFC 845 3416, December 2002. 847 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 848 Per-Domain Behavior (PDB) for Differentiated Services", 849 RFC 3662, December 2003. 851 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 852 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 854 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 855 Private Network (VPN) Terminology", RFC 4026, March 2005. 857 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 858 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 859 2005. 861 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 862 Protocol 4 (BGP-4)", RFC 4271, January 2006. 864 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 865 Networks (VPNs)", RFC 4364, February 2006. 867 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 868 Label Switched (MPLS) Data Plane Failures", RFC 4379, 869 February 2006. 871 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 872 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 873 Protocol Specification (Revised)", RFC 4601, August 2006. 875 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 876 IP", RFC 4607, August 2006. 878 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 879 "Multiprotocol Extensions for BGP-4", RFC 4760, January 880 2007. 882 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 883 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 884 4915, June 2007. 886 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 887 Topology (MT) Routing in Intermediate System to 888 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 890 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 891 RFC 5136, February 2008. 893 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 894 to-Provider Agreements for Internet-Scale Quality of 895 Service (QoS)", RFC 5160, March 2008. 897 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 898 Notifications", RFC 5277, July 2008. 900 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 901 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 903 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 905 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 906 Used to Form Encoding Rules in Various Routing Protocol 907 Specifications", RFC 5511, April 2009. 909 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 910 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 912 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 913 A., and M. Bhatia, "Requirements from Session Initiation 914 Protocol (SIP) Session Border Control (SBC) Deployments", 915 RFC 5853, April 2010. 917 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 918 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 919 2010. 921 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 922 (BFD) for Multihop Paths", RFC 5883, June 2010. 924 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 925 Performing Label Switched Path Ping (LSP Ping) over MPLS 926 Tunnels", RFC 6424, November 2011. 928 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 929 S., and T. Nadeau, "Detecting Data-Plane Failures in 930 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 931 6425, November 2011. 933 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 934 On-Demand Connectivity Verification and Route Tracing", 935 RFC 6426, November 2011. 937 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 938 RFC 6462, January 2012. 940 [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission 941 Control (GCAC) Algorithm Specification for IP/MPLS 942 Networks", RFC 6601, April 2012. 944 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 945 Switched Path (LSP) Ping for Pseudowire Forwarding 946 Equivalence Classes (FECs) Advertised over IPv6", RFC 947 6829, January 2013. 949 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 950 Morris, J., Hansen, M., and R. Smith, "Privacy 951 Considerations for Internet Protocols", RFC 6973, July 952 2013. 954 [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP 955 and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, 956 August 2013. 958 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 959 Networking: A Perspective from within a Service Provider 960 Environment", RFC 7149, March 2014. 962 Authors' Addresses 964 Mohamed Boucadair 965 France Telecom 966 Rennes 35000 967 France 969 Email: mohamed.boucadair@orange.com 970 Christian Jacquenet 971 France Telecom 972 Rennes 35000 973 France 975 Email: christian.jacquenet@orange.com 977 Ning Wang 978 University of Surrey 979 University of Surrey 980 Guildford 981 UK 983 Email: n.wang@surrey.ac.uk