Network Working Group M. Boucadair Internet-Draft C. Jacquenet Intended status: Informational France Telecom Expires: March 21, 2013 N. Wang Centre for Communication System Research September 17, 2012 IP/MPLS Connectivity Provisioning Profile draft-boucadair-connectivity-provisioning-profile-00 Abstract This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP connectivity requirements to be met in the context of delivery of services (e.g. Voice over IP or IP TV) which are to be plugged upon an IP/MPLS infrastructure. The CPP defines the set of IP transfer parameters to be supported by the underlying IP/MPLS transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics such as one-way delay, one-way delay variation are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Boucadair, et al. Expires March 21, 2013 [Page 1] Internet-Draft CPP September 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 6 2.1. Customer Nodes or Service Nodes . . . . . . . . . . . . . 8 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. QoS Guarantees . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Availability Guarantees . . . . . . . . . . . . . . . . . 9 2.5. Traffic Volume . . . . . . . . . . . . . . . . . . . . . . 10 2.6. Conformance Traffic . . . . . . . . . . . . . . . . . . . 10 2.7. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 10 2.8. Flow Identification . . . . . . . . . . . . . . . . . . . 11 2.9. Routing & Forwarding . . . . . . . . . . . . . . . . . . . 11 2.10. Activation Means . . . . . . . . . . . . . . . . . . . . . 12 2.11. Invocation Means . . . . . . . . . . . . . . . . . . . . . 12 2.12. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Boucadair, et al. Expires March 21, 2013 [Page 2] Internet-Draft CPP September 2012 1. Introduction This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP/MPLS connectivity requirements to be met in the context of delivery of services (e.g., Voice over IP, IP TV, VPN services) which are to be plugged upon an IP/MPLS infrastructure. The CPP defines the set of IP/MPLS transfer guarantees to be offered by the underlying IP/MPLS 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 assumes service differentiation at the network layer can be enforced by tweaking various parameters which belong to distinct dimensions (e.g, forwarding, routing, traffic access management, traffic classification, etc.). The CPP can be used in both the vertical model (i.e., the service and network infrastructures are managed by the same administrative entity) or the functional separation model (i.e., where distinct administrative entities mange the service and the network infrastructures). In the following sections, no assumption is made about the deployment model (vertical or separation). The CPP also aims at rationalizing the connectivity needs of above- deployed services and then to handle in a generic fashion all these requirements. Service-specific IP provisioning rules may lead to increase the required IP transfer classes to be (pre)-engineered in the operational network. As such, the use of the CPP allows to engineer generic and limited number of classes and then map individual CPP to these classes. Instantiating each CPP into a distinct class of service should be avoided. Therefore, application- agnostic IP provisioning practices should be recommended since the requirements captured in the CPP can be used to identify which network class of service is to be used to meet those requiremenst/ guarantees. CPP may also be used as a "hint" or a guideline for the network dimensioning and planning departments to ensure that appropriate resources (e.g., network cards, routers, upgrade link capacity, etc.) have been provisioned. Otherwise, (underlying) IP/MPLS networks would not be able to meet the targets expressed in all CPP requests (see Figure 1). Boucadair, et al. Expires March 21, 2013 [Page 3] Internet-Draft CPP September 2012 +----------------+ | Customer | +-------+--------+ + CPP +-------+--------+ |Network Provider| +----------------+ Figure 1: CPP: Interactions The customer shown in Figure 1 may be a service provider (e.g., IP telephony service provider) which requires invoking resources provided by an underlying network provider or an enterprise which wants to interconnect its sites using VPN services offered by a network provider. The definition of a clear interface between the service and the network layers has various advantages, such as rationalizing the engineering of network infrastructures. The CPP interface aims at exposing and characterizing the IP transfer requirements to be met between the Customer Nodes (e.g., Media Gateway, Session Border Controller, etc.) when invoking IP transfer capabilities. These requirements include: reachability scope (e.g., limited scope, Internet-wide), bandwidth requirements, QoS parameters (e.g., one-way delay [RFC2679], loss [RFC2680] or one-way delay variation [RFC3393]), protection and high availability guidelines (e.g., sub- 50ms/sub-100ms/second restoration). These requirements will then be translated into IP/MPLS-related technical clauses (e.g., need for recovery means, definition of the class of services, need for control plane protection, etc.) and in a further stage be addressed by the activation of adequate network features and technology-specific actions (e.g., MPLS-TE [RFC3346], RSVP [RFC2205], OSPF or IS-IS configuration, etc.). Customer Nodes belong to a service infrastructure or an enterprise site (see Figure 2, Figure 3 and Figure 4). The connectivity between these Customer Nodes is implemented owing to the IP transfer capability implemented through a collaboration of a set of IP resources. IP transfer capabilities are considered by the above services as black boxes. Appropriate notifications and reports would be communicated (through dedicated means) to Customer Nodes to assess the level of the experienced IP transfer service. 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. Having this CPP abstraction makes a clear distinction between the Boucadair, et al. Expires March 21, 2013 [Page 4] Internet-Draft CPP September 2012 connectivity provisioning requirements and the associated technology- specific rules that have been (or are to be) enforced in operational nodes, and which are meant to accommodate such requirements. .--. .--.. .--..--. ( '.--. .-.' Customer Infrastructure'.-. ( ) +-------------+ +-------------+ |Customer Node|.--. .--.. .--.|Customer Node| +-------------+ +-------------+ | | +--------------+ +--------------+ |Provider Node |.--. .--.. . |Provider Node | +--------------+ +--------------+ ( ) .-.' IP/MPLS Network '.-. ( ) ( . . . . . .) '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' Figure 2: Reference Architecture .--. .--.. .--..--. ( '.--. .-.' Customer Infrastructure'.-. ( ) +-------------+ +-------------+ |Customer Node|.--. .--.. .--.|Customer Node| +-------------+ +-------------+ | | +------------------------------------------+ | Provider Node | +------------------------------------------+ ( ) .-.' IP/MPLS Network '.-. ( ) ( . . . . . .) '.-_-.'.-_-._.'.-_-.'.-_-.'.--.' Figure 3: Reference Architecture (2) As shown in Figure 4, the customer infrastructure can be connected over IP/MPLS networks managed by distinct network providers. Boucadair, et al. Expires March 21, 2013 [Page 5] Internet-Draft CPP September 2012 .--. .--.. .--..--. ( '.--. .-.' Customer Infrastructure'.-. ( ) +-------------+ +-------------+ |Customer Node|.--. .--.. .--.|Customer Node| +-------------+ +-------------+ | | +--------------+ +--------------+ |Provider Node | |Provider Node | +--------------+ +--------------+ ( .--.) ( .--.) .-.' IP/MPLS Network ' .-.' IP/MPLS Network ' ( ) ( ) (. . . .) (. . . .) '.-_-.'.-_-._..' '.-_-.'.-_-._..' Figure 4: Reference Architecture (3) 1.1. Scope This document details the clauses of the CPP. Protocols used to negotiate and to enforce a CPP are out of scope. In addition to CPP clauses, other clauses may be included in an agreement between a customer and a provider (e.g., contact point, escalation procedure, incidents management, billing, etc.). It is out of scope of this document to detail all those additional clauses. Examples of how to translate CPP clauses into technology-specific policies are provided for illustration purposes. It is out of scope of this document to provide an exhaustive list of the technical means to meet the objective included in a CPP. 2. Connectivity Provisioning Profile (CPP) A CPP can be seen as an inventory of connectivity provisioning requirements with regard to IP transfer service. This section lists the clauses of the CPP. Figure 5 provides an overview of the CPP template. CPP clauses are elaborated in the following sub-sections. Boucadair, et al. Expires March 21, 2013 [Page 6] Internet-Draft CPP September 2012 +-------------------------------------------------------------------+ | Customer Nodes Map | +---------+------------+-------------+--------------+-------+-------+ |Customer | Link | Border IP | Localization | Scope | | Node | Identifier | Node | +-------+-------+ | | | Identifier | | IN | OUT | +---------+------------+-------------+--------------+-------+-------+ | | | | | | | +---------+------------+-------------+--------------+-------+-------+ | | | | | | | +---------+------------+-------------+--------------+-------+-------+ | | | | | | | +---------+------------+-------------+--------------+-------+-------+ .... +-------------------------------------------------------------------+ | Guarantees: QoS and Availability | +---------------------------------+---------------------------------+ | One Way Delay | One Way Delay Variation | +---------+-----------+-----------+---------+-----------+-----------+ | MIN | MAX | AVERAGE | MIN | MAX | AVERAGE | +---------+-----------+-----------+---------+-----------+-----------+ | | | | | | | +---------------------------------+---------------------------------+ | Loss | Availability Guarantees | +---------+-----------+-----------+---------+-----------+-----------+ | MIN | MAX | AVERAGE | MTBF | MTBR | MTTR | +---------+-----------+-----------+---------+-----------+-----------+ | | | | | | | +---------------------------------+---------------------------------+ | Traffic Volume | | +---------------------------------+---------------------------------+ | Traffic Isolation | | +---------------------------------+---------------------------------+ | Conformance Traffic | | +---------------------------------+---------------------------------+ | Flow Identification | | +---------------------------------+---------------------------------+ | Routing And Forwarding | | +---------------------------------+---------------------------------+ | Activation Means | | +---------------------------------+---------------------------------+ | Invocation Means | | +---------------------------------+---------------------------------+ | Notifications | | +---------------------------------+---------------------------------+ Figure 5: CPP Template Boucadair, et al. Expires March 21, 2013 [Page 7] Internet-Draft CPP September 2012 2.1. Customer Nodes or Service Nodes A CPP must include the list of Customer Nodes (e.g., CEs) to be connected to the underlying IP transport network. These nodes should be unambiguously identified (e.g., using a unique Service_identifier). For each Customer Node, a border link or a node part of the connectivity domain which is connected to the Customer Node should be identified. Based on the location of the Customer Node (e.g., CE), 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. An identifier of the site may also be pertinent to be captured in the CPP for the provisioning of managed VPN [RFC4026] for instance (e.g., Site_identifier). A Customer Node may be connected to several Provider Nodes and multiple Customer Nodes may be connected to the same Provider Node (see Figure 3). 2.2. Scope The Scope specifies the connection between involved Customer Nodes. It is defined as an unidirectional parameter. Both directions should be described in the CPP. The reachability scope may be defined as allowed destination IP prefixes that can be reached from the customer site. Both IPv4 and IPv6 scopes may be distinguished. A "Scope" delimits a topological (or geographical) network portion over which the performance and availability guarantees are not valid. A scope may be defined by an "Ingress" and "Egress" points. Several types may be envisaged. Examples are listed below: (1) "1:1" Pipe model. Only point to point communications are allowed. (2) "1:N" Hose model. Only communications destined to a set of destinations are allowed. (3) "1:any" Unspecified hose model. All outbound communications destined to whatever reachable destinations are to be offered. A Scope indicating external "Ingress" or "Egress" nodes (i.e., not Boucadair, et al. Expires March 21, 2013 [Page 8] Internet-Draft CPP September 2012 connected to the Provider Network or Customer Network) may also be accepted provided that these nodes are unambiguously identified (e.g., IPv6 prefix). 2.3. QoS Guarantees QoS guarantees denote a set of IP transfer performance metrics which characterize the quality of the IP transfer treatment to be experienced (when crossing an IP transport infrastructure) by a flow issued or destined to a (set of) "Customer Node(s)". IP performance metrics can be expressed as qualitative or quantitative parameters. When quantitative metrics are used, maximum or average numerical values are provided together with a validity interval which should be indicated in the measurement method. Several performance metrics have been defined such as: o Traffic Loss [RFC2680] o One way delay [RFC2679] o One way delay variation [RFC3393] The value of these parameters may be specific to a given path or a given scope (e.g., between two "Customer Nodes"). Concretely, IP performance metric value indicated in a CPP should reflect the measurement between a set of "Customer Node" or between a "Customer Node" and Provider Nodes attached to the IP network. Meta-QoS class concept can be used when qualitative metrics are used [RFC5160]. 2.4. Availability Guarantees This clause specifies the percentage of the time when the agreed IP performance guarantees must be met. 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 in the border link such as allowing for multi-homed "Customer Nodes". The following mechanisms are provided as illustration examples to show that several technical choices may be enforced to meet the service availability needs: o When an IGP instance is running between the "Customer Node" and the "Provider Node", activate a dedicated protocol, such as BFD (Bi-directional Forwarding Detection [RFC5881][RFC5883]), to control IGP availability and then to ensure sub-second IGP adjacency failure detection. Boucadair, et al. Expires March 21, 2013 [Page 9] Internet-Draft CPP September 2012 o Use of LSP ping capability to detect LSP availability (check if the LSP is in place or not) [RFC4379]. o Pre-install backup LSPs for fast-rerouting when MPLS is used between "Customer Nodes" [RFC4090]. o Enable VRRP [RFC5798]. o Enable IP Fast Reroute features (e.g., [RFC5286]). 2.5. Traffic Volume 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 2.2) and IP transfer performance guarantees (see (Section 2.3)and (Section 2.4)). Traffic volume may be expressed per border link and for both directions (i.e., incoming and outgoing). 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. 2.6. Conformance Traffic When capacity information (see Section 2.5) is included in the CPP, out-of-profile traffic would be handled separately. Shaping/policing filters may be applied so as to assess wither the traffic is within the capacity profile or out of profile. Out-of-profile traffic may be discared or under-classed (e.g., using the Lower than Best Effort PDB [RFC3662]). Conditions on the injected packets MTU may also be indicated in the CPP. 2.7. Traffic Isolation This clause indicates if the traffic issued by/destined to "Customer Nodes" should be isolated when crossing the IP transport network. This clause is then translated into IP engineering policies such as activating dedicated tunnels using IPsec or establish BGP/MPLS VPN facilities [RFC4364], or a combination thereof. Activated means should be consistent with those used to meet the availability and performance guarantees. When a "M:N" Scope is defined, optimization should be encouraged and not systematically assume a fully meshed tunnel topology. Boucadair, et al. Expires March 21, 2013 [Page 10] Internet-Draft CPP September 2012 2.8. Flow Identification To identify the flows that need to be handled in the context of a given CPP, flow identifiers should be indicated in the CPP. This identifier is used for traffic classification purposes. A flow identifier may be composed of the following parameters: o source IP address, o source port number, o destination IP address, o destination port number, o ToS or DSCP field, o tail-end tunnel endpoint, or o a combination thereof. Distinct treatments may be implemented for elastic and non elastic traffic (e.g., see the "Constraints on traffic" clause defined in [RFC5160]). Flow classification rules may be specific to a given link or a given rule may be applied for all border links. This should be clearly captured in the CPP. For incoming traffic, some practices such as re-marking the DSCP field should be indicated in CPP. Re- marking action is under the responsibility of IP nodes, but this should be inferred by some constraints such as maintaining the service transparency (e.g., VPN services). 2.9. Routing & Forwarding When outsourced routing actions are required, dedicated routes may be installed so as to convey the traffic to its (service) destination and avoiding some nodes (or ASes). A requirement to dedicate a logical topology may also be envisaged owing to the activation of [RFC4915] or [RFC5120] . This practice should be indicated in the CPP, otherwise routing actions belong to the underlying IP routing capabilities. Forwarding behavior (e.g., Per Domain Behaviour) may also be specified in a CPP. Nevertheless, it is optional. If indicated, consistency with the IP performance bounds defined in the CPP should be carefully ensured. In the context of VoIP deployments for instance, a routing policy would be to avoid satellite links since this may degrade the offered service. Boucadair, et al. Expires March 21, 2013 [Page 11] Internet-Draft CPP September 2012 2.10. Activation Means This clause indicates the required action(s) to be undertaken to activate access to the IP connectivity service. Examples of these actions would be the activation of an IGP instance, the establishment of a BGP [RFC4271] or MB-BGP session [RFC4760], etc. 2.11. Invocation Means Two types are defined: Implicit: This clause when indicated means that no explicit means to invoke the connectivity service is required. Access to connectivity service is conditioned by the requested network capacity. Explicit: This clause indicates the need for an explicit means to access the connectivity service. Examples of explicit invocation means include the use of RSVP [RFC2205] or RSVP-TE [RFC3209]. Appropriate access control procedures [RFC6601] would have to be enforced to check if the capacity actually used is not above the agreed threshold. 2.12. Notifications For operation purposes (e.g., supervision) and service fulfillment needs, added value service platforms need to be notified about critical events which may impact the delivery of the service. The notification procedure should be indicated in the CPP. This procedure may specify the type of information to be sent, the interval, data model, etc. This may be enforced using SNMP, Syslog notifications, or a phone call! 3. IANA Considerations This document does not require any action from IANA. 4. Security Considerations This document does not define an architecture nor specify a protocol. Boucadair, et al. Expires March 21, 2013 [Page 12] Internet-Draft CPP September 2012 5. Acknowledgements Some of the items listed above are results of discussions with P. Georgatsos, E. Mykoniati and D. Griffin. Special thanks to them. 6. References 6.1. Normative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Boucadair, et al. Expires March 21, 2013 [Page 13] Internet-Draft CPP September 2012 RFC 4915, June 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008. [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. 6.2. Informative References [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, March 2008. [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", RFC 6601, April 2012. Boucadair, et al. Expires March 21, 2013 [Page 14] Internet-Draft CPP September 2012 Authors' Addresses Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Christian Jacquenet France Telecom Rennes, 35000 France Email: christian.jacquenet@orange.com Ning Wang Centre for Communication System Research University of Surrey Guildford, UK Email: n.wang@surrey.ac.uk Boucadair, et al. Expires March 21, 2013 [Page 15]