idnits 2.17.1 draft-boucadair-connectivity-provisioning-profile-02.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 (September 25, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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: March 29, 2013 N. Wang 6 Centre for Communication System 7 Research 8 September 25, 2012 10 IP/MPLS Connectivity Provisioning Profile 11 draft-boucadair-connectivity-provisioning-profile-02 13 Abstract 15 This document describes the Connectivity Provisioning Profile (CPP) 16 and proposes a CPP Template to capture IP connectivity requirements 17 to be met in the context of delivery of services (e.g. Voice over IP 18 or IP TV) which are to be plugged upon an IP/MPLS infrastructure. 19 The CPP defines the set of IP transfer parameters to be supported by 20 the underlying IP/MPLS transport network together with a reachability 21 scope and bandwidth/capacity needs. Appropriate performance metrics 22 such as one-way delay, one-way delay variation are used to 23 characterize an IP transfer service. Both global and restricted 24 reachability scopes can be captured in the CPP. 26 Having the generic CPP template allows for (1) automating the process 27 of service negotiation and activation, thus accelerating service 28 provisioning, (2) setting the (traffic) objectives of Traffic 29 Engineering functions and service management functions and (3) 30 enriching service and network management systems with 'decision- 31 making' capabilities based on negotiated/offered CPPs. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 29, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 7 70 2.1. Customer Nodes or Service Nodes . . . . . . . . . . . . . 7 71 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . . 8 73 2.4. Availability Guarantees . . . . . . . . . . . . . . . . . 9 74 2.5. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 2.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 9 76 2.7. Overall Traffic Guarantees . . . . . . . . . . . . . . . . 10 77 2.8. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 10 78 2.9. Flow Identification . . . . . . . . . . . . . . . . . . . 10 79 2.10. Routing & Forwarding . . . . . . . . . . . . . . . . . . . 11 80 2.11. Activation Means . . . . . . . . . . . . . . . . . . . . . 11 81 2.12. Invocation Means . . . . . . . . . . . . . . . . . . . . . 11 82 2.13. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 83 3. CPP Template . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 This document describes the Connectivity Provisioning Profile (CPP) 95 and proposes a CPP Template to capture IP/MPLS connectivity 96 requirements to be met in the context of delivery of services (e.g., 97 Voice over IP, IP TV, VPN services) which are to be plugged upon an 98 IP/MPLS infrastructure. 100 Within this document, IP connectivity service is the IP transfer 101 capability characterized by a (Destination, Guarantees, Scope) tuple 102 where "Destination" is a group of IP addresses, "Guarantees" is the 103 guarantees (including QoS performance and availability) to get to the 104 "Destination" and "Scope" is the (network) perimeters (e.g., between 105 two PEs) where the guarantees should be met. 107 +----------------+ 108 | Customer | 109 +-------+--------+ 110 + CPP 111 +-------+--------+ 112 |Network Provider| 113 +----------------+ 115 Figure 1: CPP: Interactions 117 The CPP defines the set of IP/MPLS transfer guarantees to be offered 118 by the underlying IP/MPLS transport network together with a 119 reachability scope and capacity needs. Appropriate performance 120 metrics such as one-way delay or one-way delay variation are used to 121 characterize the IP transfer service. Guarantees related to 122 availability and resiliency are also included in the CPP. 124 The CPP assumes service differentiation at the network layer can be 125 enforced by tweaking various parameters which belong to distinct 126 dimensions (e.g, forwarding, routing, traffic access management, 127 traffic classification, etc.). 129 The CPP can be used in both the integrated model (i.e., the service 130 and network infrastructures are managed by the same administrative 131 entity) or the functional separation model (i.e., where distinct 132 administrative entities mange the service and the network 133 infrastructures). In the following sections, no assumption is made 134 about the deployment model (vertical or separation). 136 The CPP also aims at rationalizing the connectivity needs of above- 137 deployed services and then to handle in a generic fashion all these 138 requirements. Service-specific IP provisioning rules may lead to 139 increase the required IP transfer classes to be (pre)-engineered in 140 the operational network. As such, the use of the CPP allows to 141 engineer generic and limited number of classes and then map 142 individual CPP to these classes. Instantiating each CPP into a 143 distinct class of service should be avoided. Therefore, application- 144 agnostic IP provisioning practices should be recommended since the 145 requirements captured in the CPP can be used to identify which 146 network class of service is to be used to meet those requiremenst/ 147 guarantees. 149 CPP may also be used as a "hint" or a guideline for the network 150 dimensioning and planning departments to ensure that appropriate 151 resources (e.g., network cards, routers, upgrade link capacity, etc.) 152 have been provisioned. Otherwise, (underlying) IP/MPLS networks 153 would not be able to meet the targets expressed in all CPP requests 154 (see Figure 1). Having the generic CPP template allows for: 155 o Automating the process of service negotiation and activation, thus 156 accelerating service provisioning; 157 o Setting the (traffic) objectives of Traffic Engineering functions 158 and service management functions. 159 o Enriching service and network management systems with 'decision- 160 making' capabilities based on negotiated/offered CPPs. 162 The customer shown in Figure 1 may be another network provider (e.g., 163 provide IP transit service), a service provider (e.g., IP telephony 164 service provider) which requires invoking resources provided by an 165 underlying network provider, an enterprise which wants to 166 interconnect its sites using VPN services offered by a network 167 provider. The proposed CPP can apply to all these interactions, 168 presenting a common template for describing the connectivity services 169 offered by network providers. 171 The definition of a clear interface between the service and the 172 network layers has various advantages, such as rationalizing the 173 engineering of network infrastructures. The CPP interface aims at 174 exposing and characterizing the IP transfer requirements to be met 175 between the Customer Nodes (e.g., Media Gateway, Session Border 176 Controller, etc.) when invoking IP transfer capabilities. These 177 requirements include: reachability scope (e.g., limited scope, 178 Internet-wide), direction, bandwidth requirements, QoS parameters 179 (e.g., one-way delay [RFC2679], loss [RFC2680] or one-way delay 180 variation [RFC3393]), protection and high availability guidelines 181 (e.g., sub-50ms/sub-100ms/second restoration). These requirements 182 will then be translated into IP/MPLS-related technical clauses (e.g., 183 need for recovery means, definition of the class of services, need 184 for control plane protection, etc.) and in a further stage be 185 addressed by the activation of adequate network features and 186 technology-specific actions (e.g., MPLS-TE [RFC3346], RSVP [RFC2205], 187 OSPF or IS-IS configuration, etc.). For traffic conformance 188 purposes, the CPP includes also flow identification and 189 classification rules to be followed when invoking a given CPP. 191 A network provider expose its connectivity services via a Provider 192 Node. An example of Provider Node is a PE or ASBR. 194 Customer Nodes belong to a service infrastructure or an enterprise 195 site (see Figure 2). In some contexts, Customer Node can be provided 196 and managed by the Provider. The connectivity between these Customer 197 Nodes is implemented owing to the IP transfer capability implemented 198 through a collaboration of a set of IP resources. IP transfer 199 capabilities are considered by the above services as black boxes. 200 Appropriate notifications and reports would be communicated (through 201 dedicated means) to Customer Nodes to assess the level of the 202 experienced IP transfer service. These notifications may also be 203 used to assess the efficiency of the various policies enforced in the 204 networking infrastructure to accommodate the requirements detailed in 205 the CPP. 207 Having this CPP abstraction makes a clear distinction between the 208 connectivity provisioning requirements and the associated technology- 209 specific rules that have been (or are to be) enforced in operational 210 nodes, and which are meant to accommodate such requirements. 212 As shown in Figure 2, the customer infrastructure can be connected 213 over IP/MPLS networks managed by distinct network providers. 215 .--. .--.. .--..--. 216 ( '.--. 217 .-.' Customer Infrastructure'.-. 218 ( ) 219 +-------------+ +-------------+ 220 |Customer Node|.--. .--.. .--.|Customer Node| 221 +-------------+ +-------------+ 222 | | 223 +--------------+ +--------------+ 224 |Provider Node |.--. .--.. . |Provider Node | 225 +--------------+ +--------------+ 226 ( ) 227 .-.' IP/MPLS Network '.-. 228 ( ) 229 ( . . . . . .) 230 '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' 232 .--. .--.. .--..--. 233 ( '.--. 234 .-.' Customer Infrastructure'.-. 236 ( ) 237 +-------------+ +-------------+ 238 |Customer Node|.--. .--.. .--.|Customer Node| 239 +-------------+ +-------------+ 240 | | 241 +------------------------------------------+ 242 | Provider Node | 243 +------------------------------------------+ 244 ( ) 245 .-.' IP/MPLS Network '.-. 246 ( ) 247 ( . . . . . .) 248 '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' 250 .--. .--.. .--..--. 251 ( '.--. 252 .-.' Customer Infrastructure'.-. 253 ( ) 254 +-------------+ +-------------+ 255 |Customer Node|.--. .--.. .--.|Customer Node| 256 +-------------+ +-------------+ 257 | | 258 +--------------+ +--------------+ 259 |Provider Node | |Provider Node | 260 +--------------+ +--------------+ 261 ( .--.) ( .--.) 262 .-.' IP/MPLS Network ' .-.' IP/MPLS Network ' 263 ( ) ( ) 264 (. . . .) (. . . .) 265 '.-_-.'.-_-._..' '.-_-.'.-_-._..' 267 Figure 2: Reference Architecture 269 1.1. Scope 271 This document details the clauses of the CPP. Protocols used to 272 negotiate and to enforce a CPP are out of scope. 274 In addition to CPP clauses, other clauses may be included in an 275 agreement between a customer and a provider (e.g., contact point, 276 escalation procedure, incidents management, billing, etc.). It is 277 out of scope of this document to detail all those additional clauses. 279 Examples of how to translate CPP clauses into technology-specific 280 policies are provided for illustration purposes. It is out of scope 281 of this document to provide an exhaustive list of the technical means 282 to meet the objective included in a CPP. 284 2. Connectivity Provisioning Profile (CPP) 286 A CPP can be seen as an inventory of connectivity provisioning 287 requirements with regard to IP transfer service. CPP clauses are 288 elaborated in the following sub-sections. The CPP template is 289 provided in Section 3. 291 2.1. Customer Nodes or Service Nodes 293 A CPP must include the list of Customer Nodes (e.g., CEs) to be 294 connected to the underlying IP transport network. 296 These nodes should be unambiguously identified (e.g., using a unique 297 Service_identifier). For each Customer Node, a border link or a node 298 part of the connectivity domain which is connected to the Customer 299 Node should be identified. 301 Based on the location of the Customer Node (e.g., CE), appropriate 302 operations to retrieve the corresponding border link or "Provider 303 Node" (e.g., PE) should be undertaken. This operation can be manual 304 or automated. 306 A "service site" would be located behind a given Customer Node. An 307 identifier of the site may also be pertinent to be captured in the 308 CPP for the provisioning of managed VPN [RFC4026] for instance (e.g., 309 Site_identifier). 311 A Customer Node may be connected to several Provider Nodes and 312 multiple Customer Nodes may be connected to the same Provider Node 313 (see Figure 2). 315 2.2. Scope 317 The Scope specifies the reachability out/to each of involved Customer 318 Nodes. It is defined as an unidirectional parameter. Both 319 directions should be described in the CPP. 321 The reachability scope may be defined as allowed destination IP 322 prefixes that can be reached from the customer site. Both global and 323 restricted reachability scopes can be captured in the CPP. A 324 restricted reachability scope means no global reachability is allowed 325 and only a set of destinations are reachable. 327 Both IPv4 and IPv6 scopes may be distinguished. 329 A "Scope" delimits a topological (or geographical) network portion 330 over which the performance and availability guarantees are not valid. 332 A scope may be defined by an "Ingress" and "Egress" points. Several 333 types may be envisaged. Examples are listed below: 334 (1) "1:1" Pipe model. Only point to point communications are 335 allowed. 336 (2) "1:N" Hose model. Only communications destined to a set of 337 destinations are allowed. 338 (3) "1:any" Unspecified hose model. All outbound communications 339 destined to whatever reachable destinations are to be offered. 341 The Ingress and Egress points could be Customer Nodes/Provider Nodes 342 or external nodes, provided that these nodes are unambiguously 343 identified (e.g., IPv6 prefix), or a sets of IP destinations. 345 2.3. QoS Guarantees 347 QoS guarantees denote a set of IP transfer performance metrics which 348 characterize the quality of the IP transfer treatment to be 349 experienced (when crossing an IP transport infrastructure) by a flow 350 issued or destined to a (set of) "Customer Node(s)". 352 IP performance metrics can be expressed as qualitative or 353 quantitative parameters. When quantitative metrics are used, maximum 354 or average numerical values are provided together with a validity 355 interval which should be indicated in the measurement method. 357 Several performance metrics have been defined such as: 358 o Traffic Loss [RFC2680] 359 o One way delay [RFC2679] 360 o One way delay variation [RFC3393] 361 The value of these parameters may be specific to a given path or a 362 given scope (e.g., between two "Customer Nodes"). Concretely, IP 363 performance metric value indicated in a CPP should reflect the 364 measurement between a set of "Customer Node" or between a "Customer 365 Node" and Provider Nodes attached to the IP network. 367 Quantitative guarantees can only be specified for in-profile traffic 368 (i.e., up to a certain traffic rate). 370 Meta-QoS class concept can be used when qualitative metrics are used 371 [RFC5160]. 373 Including both quantitative and qualitative guarantees cannot be 374 specified in the same CPP. 376 A CPP can include throughput guarantees; when specified these 377 guarantees are equivalent to quantitative or qualitative loss 378 guarantees. 380 2.4. Availability Guarantees 382 This clause specifies the percentage of the time when the agreed IP 383 performance guarantees must be met. The clause can be expressed as 384 maximum/average. The exact meaning is agreed during CPP negotiation 385 process. 387 The guarantees cover both QoS deterioration (i.e., IP transfer 388 service is available but it is below the agreed performance bounds), 389 physical failures or service unavailability in general. In order to 390 meet the availability guarantees, several engineering practices may 391 be enforced in the border link such as allowing for multi-homed 392 "Customer Nodes". 394 The following mechanisms are provided as illustration examples to 395 show that several technical choices may be enforced to meet the 396 service availability needs: 397 o When an IGP instance is running between the "Customer Node" and 398 the "Provider Node", activate a dedicated protocol, such as BFD 399 (Bi-directional Forwarding Detection [RFC5881][RFC5883]), to 400 control IGP availability and then to ensure sub-second IGP 401 adjacency failure detection. 402 o Use of LSP ping capability to detect LSP availability (check if 403 the LSP is in place or not) [RFC4379]. 404 o Pre-install backup LSPs for fast-rerouting when MPLS is used 405 between "Customer Nodes" [RFC4090]. 406 o Enable VRRP [RFC5798]. 407 o Enable IP Fast Reroute features (e.g., [RFC5286]). 409 2.5. Capacity 411 This clause characterizes the required capacity to be provided by the 412 underlying IP transport network. This capacity is bound to a defined 413 "Scope" (See Section 2.2) and IP transfer performance guarantees (see 414 (Section 2.3)and (Section 2.4)). 416 The capacity may be expressed per border link and for both directions 417 (i.e., incoming and outgoing). This clause is a limit of the traffic 418 up to which quantitative guarantees are to be provided. 420 It is up to the administrative entity, which manages the IP transport 421 network, to appropriately dimension its network [RFC5136] to meet the 422 capacity requirements expressed in all negotiated CPPs. 424 2.6. Conformance Traffic 426 When capacity information (see Section 2.5) is included in the CPP, 427 out-of-profile traffic would be handled separately. 429 Shaping/policing filters may be applied so as to assess wither the 430 traffic is within the capacity profile or out of profile. 432 Out-of-profile traffic may be discarded or under-classed (e.g., using 433 the Lower than Best Effort PDB [RFC3662]). 435 Conditions on the injected packets MTU may also be indicated in the 436 CPP. 438 2.7. Overall Traffic Guarantees 440 Overall traffic guarantees are for the case where Traffic Volume/ 441 Conformance clauses are not specified, or if specified, excess 442 traffic is remarked. Such guarantees can only be qualitative delay 443 and/or qualitative loss or throughput guarantees. 445 If overall traffic guarantees are not specified, best effort 446 forwarding is implied. 448 2.8. Traffic Isolation 450 This clause indicates if the traffic issued by/destined to "Customer 451 Nodes" should be isolated when crossing the IP transport network. 453 This clause is then translated into IP engineering policies such as 454 activating dedicated tunnels using IPsec or establish BGP/MPLS VPN 455 facilities [RFC4364], or a combination thereof. Activated means 456 should be consistent with those used to meet the availability and 457 performance guarantees. 459 2.9. Flow Identification 461 To identify the flows that need to be handled in the context of a 462 given CPP, flow identifiers should be indicated in the CPP. This 463 identifier is used for traffic classification purposes. 465 A flow identifier may be composed of the following parameters: 466 o source IP address, 467 o source port number, 468 o destination IP address, 469 o destination port number, 470 o ToS or DSCP field, 471 o tail-end tunnel endpoint, or 472 o a combination thereof. 474 Distinct treatments may be implemented for elastic and non elastic 475 traffic (e.g., see the "Constraints on traffic" clause defined in 476 [RFC5160]). 478 Flow classification rules may be specific to a given link or a given 479 rule may be applied for all border links. This should be clearly 480 captured in the CPP. For incoming traffic, some practices such as 481 re-marking the DSCP field should be indicated in CPP. Re- marking 482 action is under the responsibility of IP nodes, but this should be 483 inferred by some constraints such as maintaining the service 484 transparency (e.g., VPN services). 486 2.10. Routing & Forwarding 488 When outsourced routing actions are required, dedicated routes may be 489 installed so as to convey the traffic to its (service) destination 490 and avoiding some nodes (or ASes). 492 A requirement to dedicate a logical topology may also be envisaged 493 owing to the activation of [RFC4915] or [RFC5120]. 495 This practice should be indicated in the CPP, otherwise routing 496 actions belong to the underlying IP routing capabilities. Forwarding 497 behavior (e.g., Per Domain Behavior) may also be specified in a CPP. 498 Nevertheless, it is optional. If indicated, consistency with the IP 499 performance bounds defined in the CPP should be carefully ensured. 501 In the context of VoIP deployments for instance, a routing policy 502 would be to avoid satellite links since this may degrade the offered 503 service. 505 2.11. Activation Means 507 This clause indicates the required action(s) to be undertaken to 508 activate access to the IP connectivity service. 510 Examples of these actions would be the activation of an IGP instance, 511 the establishment of a BGP [RFC4271] or MP-BGP session [RFC4760], 512 etc. 514 2.12. Invocation Means 516 Two types are defined: 517 Implicit: This clause when indicated means that no explicit means to 518 invoke the connectivity service is required. Access to 519 connectivity service is conditioned by the requested network 520 capacity. 521 Explicit: This clause indicates the need for an explicit means to 522 access the connectivity service. Examples of explicit invocation 523 means include the use of RSVP [RFC2205] or RSVP-TE [RFC3209]. 524 Appropriate access control procedures [RFC6601] would have to be 525 enforced to check if the capacity actually used is not above the 526 agreed threshold. 528 2.13. Notifications 530 For operation purposes (e.g., supervision) and service fulfillment 531 needs, added value service platforms need to be notified about 532 critical events which may impact the delivery of the service. 534 The notification procedure should be indicated in the CPP. This 535 procedure may specify the type of information to be sent, the 536 interval, data model, etc. 538 This may be enforced using SNMP, Syslog notifications, or a phone 539 call! 541 3. CPP Template 543 Figure 3 provides an overview of the CPP template which includes the 544 clauses detailed in Section 2. 546 +-------------------------------------------------------------------+ 547 | Customer Nodes Map | 548 +---------+------------+-------------+--------------+-------+-------+ 549 |Customer | Link | Border IP | Localization | Scope | 550 | Node | Identifier | Node | +-------+-------+ 551 | | | Identifier | | IN | OUT | 552 +---------+------------+-------------+--------------+-------+-------+ 553 | | | | | | | 554 +---------+------------+-------------+--------------+-------+-------+ 555 | | | | | | | 556 +---------+------------+-------------+--------------+-------+-------+ 557 | | | | | | | 558 +---------+------------+-------------+--------------+-------+-------+ 559 .... 560 +-------------------------------------------------------------------+ 561 | Guarantees: QoS and Availability | 562 +---------------------------------+---------------------------------+ 563 | One Way Delay | One Way Delay Variation | 564 +---------------------------------+---------------------------------+ 565 | Loss | Availability Guarantees | 566 +---------------------------------+---------------------------------+ 567 | Qualitative Guarantees | 568 +---------------------------------+---------------------------------+ 569 | | | 570 +---------------------------------+---------------------------------+ 571 .... 572 +-------------------------------------------------------------------+ 573 | Capacity | | 574 +---------------------------------+---------------------------------+ 575 | Traffic Isolation | | 576 +---------------------------------+---------------------------------+ 577 | Conformance Traffic | | 578 +---------------------------------+---------------------------------+ 579 | Flow Identification | | 580 +---------------------------------+---------------------------------+ 581 | Overall Traffic Guarantees | | 582 +---------------------------------+---------------------------------+ 583 | Routing And Forwarding | | 584 +---------------------------------+---------------------------------+ 585 | Activation Means | | 586 +---------------------------------+---------------------------------+ 587 | Invocation Means | | 588 +---------------------------------+---------------------------------+ 589 | Notifications | | 590 +---------------------------------+---------------------------------+ 592 Figure 3: CPP Template 594 4. IANA Considerations 596 This document does not require any action from IANA. 598 5. Security Considerations 600 This document does not define an architecture nor specify a protocol. 602 6. Acknowledgements 604 Some of the items listed above are results of discussions with E. 605 Mykoniati and D. Griffin. Special thanks to them. 607 Many thanks to P. Georgatsos for the discussions and the detailed 608 review of this document. 610 S. Shah reviewed the document and provided useful comments. 612 7. References 614 7.1. Normative References 616 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 617 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 618 Functional Specification", RFC 2205, September 1997. 620 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 621 Delay Metric for IPPM", RFC 2679, September 1999. 623 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 624 Packet Loss Metric for IPPM", RFC 2680, September 1999. 626 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 627 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 628 Tunnels", RFC 3209, December 2001. 630 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 631 Metric for IP Performance Metrics (IPPM)", RFC 3393, 632 November 2002. 634 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 635 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 636 May 2005. 638 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 639 Protocol 4 (BGP-4)", RFC 4271, January 2006. 641 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 642 Networks (VPNs)", RFC 4364, February 2006. 644 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 645 Label Switched (MPLS) Data Plane Failures", RFC 4379, 646 February 2006. 648 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 649 "Multiprotocol Extensions for BGP-4", RFC 4760, 650 January 2007. 652 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 653 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 654 RFC 4915, June 2007. 656 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 657 Topology (MT) Routing in Intermediate System to 658 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 660 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 661 RFC 5136, February 2008. 663 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 664 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 666 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 667 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 669 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 670 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 671 June 2010. 673 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 674 (BFD) for Multihop Paths", RFC 5883, June 2010. 676 7.2. Informative References 678 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 679 Christian, B., and W. Lai, "Applicability Statement for 680 Traffic Engineering with MPLS", RFC 3346, August 2002. 682 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 683 Per-Domain Behavior (PDB) for Differentiated Services", 684 RFC 3662, December 2003. 686 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 687 Private Network (VPN) Terminology", RFC 4026, March 2005. 689 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 690 to-Provider Agreements for Internet-Scale Quality of 691 Service (QoS)", RFC 5160, March 2008. 693 [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission 694 Control (GCAC) Algorithm Specification for IP/MPLS 695 Networks", RFC 6601, April 2012. 697 Authors' Addresses 699 Mohamed Boucadair 700 France Telecom 701 Rennes, 35000 702 France 704 Email: mohamed.boucadair@orange.com 706 Christian Jacquenet 707 France Telecom 708 Rennes, 35000 709 France 711 Email: christian.jacquenet@orange.com 713 Ning Wang 714 Centre for Communication System Research 715 University of Surrey 716 Guildford, 717 UK 719 Email: n.wang@surrey.ac.uk