SFC Working Group INTERNET-DRAFT Anil Kumar S N Intended Status: Informational Gaurav Agrawal Vinod Kumar S Huawei Technologies India Expires: June 13, 2016 December 11, 2015 Performance Measurement Architecture for SFC draft-agv-sfc-performance-measurement-architecture-00 Abstract This document describes passive performance measurement(PM) architecture for Service Function Chains (SFCs) in a network. It includes architectural concepts and principles for composite services performance measurement when deployed as SFCs, This document does not propose solutions, protocols, or extensions to existing protocols. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html AGV Expires June 13, 2016 [Page 1] INTERNET DRAFT PM Architecture for SFC December 11, 2015 Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Terms & Definition . . . . . . . . . . . . . . . . . . . . . 5 2 Architecture overview . . . . . . . . . . . . . . . . . . . . . 9 3 Measurement Controller, Measurement Collector & MA. . . . . . . 10 4 Performance Measurement Attributes . . . . . . . . . . . . . . . 11 4.1 NSH Context Header Attributes . . . . . . . . . . . . . . . 11 4.2 PM Reporting Attributes . . . . . . . . . . . . . . . . . . 11 4.3 Attributes Description . . . . . . . . . . . . . . . . . . . 11 4.3.1 PMF Identifier . . . . . . . . . . . . . . . . . . . . . 11 4.3.2 Window Identifier . . . . . . . . . . . . . . . . . . . 12 4.3.3 Measurement Agents with PM Type . . . . . . . . . . . . 12 4.3.4 Performance Statistics . . . . . . . . . . . . . . . . . 13 4.3.5 PM Instance . . . . . . . . . . . . . . . . . . . . . . 13 5 Measurement Controller Operation . . . . . . . . . . . . . . . . 13 6 Classifier Operation . . . . . . . . . . . . . . . . . . . . . . 14 7 MA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8 Collector Operation . . . . . . . . . . . . . . . . . . . . . . 15 9 Measurement steps . . . . . . . . . . . . . . . . . . . . . . . 15 10 Hop by Hop Performance Measurement . . . . . . . . . . . . . . 16 11 End to End Performance Measurement . . . . . . . . . . . . . . 16 12 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.1 Normative References . . . . . . . . . . . . . . . . . . . 17 14.2 Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 AGV Expires June 13, 2016 [Page 2] INTERNET DRAFT PM Architecture for SFC December 11, 2015 1 Introduction The delivery of end-to-end services often requires various service functions. These include traditional network service functions such as firewalls and traditional IP Network Address Translators (NATs), as well as application-specific functions. The definition and instantiation of an ordered set of service functions and subsequent "steering" of traffic through them is termed Service Function Chaining (SFC). The purpose of this memo is to define a general framework for systematic passive performance measurement for the Network Service Header (NSH) encapsulated packets or frames on service chains. Service provider's service level agreements (SLAs) depend on the ability to measure and monitor performance metrics mostly for following parameters: a) Packet Loss b) Packet delay Performance measurement capability enables operators with greater visibility into the performance characteristics of their networks, thereby operators can carry out facilitating & planning, troubleshooting, and network performance evaluation. Performance measurement methods could be broadly into two categories: Active Measurement method : Active method measures performance or reliability parameters by the examining injected special traffic into the network, especially for the purpose of measurement by intended measurement point. Passive measurement method : Passive method measures performance or reliability parameter based of observing existing live traffic (packets) on the network. AGV Expires June 13, 2016 [Page 3] INTERNET DRAFT PM Architecture for SFC December 11, 2015 Both passive and active measurement methods have their strengths and should be regarded as complementary. There are scenarios where active measurements alone is not enough or applicable and passive measurements are desirable along with active measurement method, one such reasons could be the rate, numbers and interval between the injected active measurement packets may affect the accuracy of the results and also the injected test packets may not be guaranteed to always be in-band with the data traffic in the network due to Equal Cost Multi-Path (ECMP). Below are some of the basic requirements for PM architecture for SFC o Measurement of Packet Loss, Delay & Jitter. o Hop by Hop, E2E, & SFC segment(s) Measurement. o Measurement for Granular Flows in SFP as well as SFP as a whole o Continuous/proactive & selective/on-demand measurement. o Packet Out of Ordering shouldn't impact the PM calculation o Compliance with NSH Standards o PM applicability between different component in SPF path to exactly locate the problem area (this includes Measurement between SF-SF, SF-SFF, SFF-SFF etc.) This document describes efficient and accurate passive performance measurement architecture for Service Function Chains (SFCs) in a service function domain with conformance to above listed basic requirements. AGV Expires June 13, 2016 [Page 4] INTERNET DRAFT PM Architecture for SFC December 11, 2015 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Terms & Definition Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a "composite service". The term "service" is used to denote a "network service" in the context of this document. Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a "firewall". Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted. Classification: Locally instantiated matching of traffic flows against policy for subsequent application of the required set of network service functions. The policy may be customer/network/service specific. Classifier: An element that performs Classification. Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for service function chain. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be AGV Expires June 13, 2016 [Page 5] INTERNET DRAFT PM Architecture for SFC December 11, 2015 embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain. One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer. An SF may be SFC encapsulation aware (that is, it receives and acts on information in the SFC encapsulation) or unaware (in which case, data forwarded to the SF does not contain the SFC encapsulation). This is often referred to as "SFC aware" and "SFC unaware", respectively. Service Function Forwarder (SFF): A service function forwarder is responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, an SFF is responsible for delivering traffic to a classifier when needed and supported , transporting traffic to another SFF (in the same or different type of overlay), and terminating the Service Function Path (SFP). Metadata: Provides the ability to exchange context information between classifiers and SFs, and among SFs. Service Function Path (SFP): The service function path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and he fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network. SFC Encapsulation: The SFC encapsulation provides, at a minimum, SFP identification, and is used by the SFC-aware functions, AGV Expires June 13, 2016 [Page 6] INTERNET DRAFT PM Architecture for SFC December 11, 2015 such as the SFF and SFC-aware SFs. The SFC encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries metadata including data-plane context information. Rendered Service Path (RSP): Within an SFP, packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. SFC-Enabled Domain: A network or region of a network that implements SFC. An SFC-enabled domain is limited to a single network administrative domain. SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements. Network Node/Element: Device that forwards packets or frames based on outer header information. In most cases is not aware of the presence of NSH. Network Overlay: Logical network built on top of existing network (the underlay). Packets are encapsulated or tunneled to create the overlay network topology. Network Service Header: Data plane header added to frames/ packets. The header contains information required for service chaining, as well as metadata added and consumed by network nodes and service elements. NSH Proxy: Acts as a gateway: removes and inserts SH on behalf of a service function that is not NSH aware. Service Classifier: Function that performs classification and imposes an NSH. Creates a service path. Non-initial (i.e. subsequent) classification can occur as needed and can alter, or create a new service path. Measurement Collector : An operational function that collects measurement data from a Measurement Agent. Measurement collector is responsible for collecting the Performance measurement Data from Measurement Agent. Measurement collector functionality could be integrated with one of AGV Expires June 13, 2016 [Page 7] INTERNET DRAFT PM Architecture for SFC December 11, 2015 the MA or with the Controller itself. Measurement Agent: An operational function that contains one or more Measurement functions. Measurement Agents is responsible for understand and analyze Performance measurement control information encoded in NSH metadata and perform the performance data collecting and report the same to Measurement collector with key information to identify performance measurement instance along with data collected. Measurement Controller: An operational function that controls running, scheduling, and general coordination of Measurement functions by instructing a Measurement Agent using NSH metadata. Measurement Controller is responsible for Configuring the Performance measurement Instance. Optionally Performance measurement instance can be configured manually at the Ingress in which case Controller is not required AGV Expires June 13, 2016 [Page 8] INTERNET DRAFT PM Architecture for SFC December 11, 2015 2 Architecture overview +--------------------+ +------------------+ | | | | | Measurement | | Measurement | | Controller +----------+ Collector | | | | | | | | | +--------------+-----+ +--------+---------+ | | +----------------+-------------------------+--------------+ | Candidate Measurement Agents | | | | +----- | | +------------+ | SF | | | | | +--+-- | | | SFC | | | | | CLassifier | +---+----+ +--------+ | | | Node <-------> SFF <--------> SFF | | | | | +--------+ +---+----+ | | | | | | | +------------+ +-----+------+ | | +----+ +----+ | | | SF | | SF | | | +----+ +----+ | +---------------------------------------------------------+ SFC performance measurement architecture will have the following major components: Measurement Controller: Responsible for Programming the PM instance at the SFC classifier. Optionally PM instance can be configured manually at the Ingress in which case controller is not required. Measurement Collector: Responsible for collecting the PM Data from MA(s). SFC Classifier: Responsible for programming/encoding measurement control information for MA(s) to collect the appropriate PM statistics information as NSH metadata based on traffic classification & Measurement controller instructions. Measurement Agent: Measurement Agents responsible for collecting the PM Data. From now on will be referred as MA. AGV Expires June 13, 2016 [Page 9] INTERNET DRAFT PM Architecture for SFC December 11, 2015 The following elements in a SFP can act as a MA o SF o SFF o Classifier o NSH Proxy Agent. Note: Controller and Collector function can be hosted on a single device which depending on deployment. 3 Measurement Controller, Measurement Collector & MA. As described the major components of a service function enabled network performance measurement platform are the Measurement Agents, the Measurement Controller(s) and the Measurement Collector(s). The MAs are the elements actually performing the measurements. The MAs are controlled by exactly one Controller at a time and the Measurement Collectors gather the results generated by the MAs. In a nutshell, the normal operation of a SFC performance measurement platform starts with the Controller instructing a set of one or more MAs to perform a set of one or more performance measurement tasks at a certain point in time. The MAs execute the instructions from a Controller, and once they have done so, they report the results of the measurements to one or more Measurement Collectors. The overall detailed framework for a SFC performance measurement platform along with information model will be described in subsequent draft versions. AGV Expires June 13, 2016 [Page 10] INTERNET DRAFT PM Architecture for SFC December 11, 2015 4 Performance Measurement Attributes To perform an effective and accurate measurement; Encoding metadata and accurate communication between measurement controller and measurement agent is very important. To achieve desired goal of efficiency and accuracy many performance control information need to be encoded as NSH Context Header Attributes in NSH metadata. Once measurement is done then these key NSH Context Header Attributes along with measurement data need to be reported to measurement controller. 4.1 NSH Context Header Attributes Following attributes should encoded in NSH metadata in a Context Header - PMF Identifier - Window Identifier - List of MA(s) with PM Type 4.2 PM Reporting Attributes Following Information should be sent from each MA to COLLECTOR - PMF Identifier - Window Identifier - MA with PM Type - Performance Statistics 4.3 Attributes Description Multiple new performance attributes are introduced in this memo to carry performance control information. Each attribute has unique purpose; are understood based on context and corresponding performance is performed by respective MA in the SFP. 4.3.1 PMF Identifier Purpose : For unique identification of a measured Flow in SFC Domain Value : Unique value within current SFC domain Processing : - At Classifier : The PMF Identifier in encoded in NSH Context Header. - At MA : Used as a key while collecting, maintaining & reporting PM Statistics to Collector. AGV Expires June 13, 2016 [Page 11] INTERNET DRAFT PM Architecture for SFC December 11, 2015 - At Collector : Collector co-relates the performance data received from MA using this PMF Identifier. 4.3.2 Window Identifier Purpose : Divides the flows into multiple Windows. Packets with PM information in a Window will have same Window identifier and consecutive Windows will have different identifier. This enables MA to collect & accumulate statistics corresponding to each Window & report it to Collector. Size of the window is programmable Value : Integer (Max/Min Value: Programmable to Context Header at Classifier, once Max value reached then value = Min Value). Value increments with each PM Interval. Processing : - At Classifier : The Window Identifier is encoded in NSH Context Header. - At MA : Used as a key while collecting, maintaining & reporting PM Statistics to Collector. - At Collector : Collector co-relates the performance data received from MA using this Window Identifier. 4.3.3 Measurement Agents with PM Type Purpose : To identify participating measurement agents and type of performance measurement. Value : Service Index to identify SF in SFP. Processing : - At Classifier : Encode the Participating MA(s) with PM Type. - At MA : Presence of self index triggers the PM collection & reporting. - At Collector : Identifies the reporting MA AGV Expires June 13, 2016 [Page 12] INTERNET DRAFT PM Architecture for SFC December 11, 2015 4.3.4 Performance Statistics Purpose : Computation of Performance. Value : Collected Statistics Processing : - At Classifier : None. - At MA : Depends on performance measurement type For Packet Loss: Accumulates received & sent Packets counter for a given Flow + Window and report it to Collector For Delay: Record the time for sent and received packet for a given Flow + window and report it to Collector. - At Collector : Co-relate and maintain received data 4.3.5 PM Instance PM Instance is a set of parameters consisting PMF ID, MA List along wit its PM Type, Window size & PM Schedule (Specifies the time when the PM has to be performed). PM Instance uniquely identifies a PM flow in SFC domain. PM Instance needs to be programmed for a classified flow at the classifier either by Controller or by manually configuration. Values of these parameters will depend on the measurement scenario. 5 Measurement Controller Operation Measurement Controller has the following responsibility: 1) Program the PM Instance at the Classifier 2) Provides the PM Instance details to the Collector (if required) 3) Ensures the uniqueness of PMF Id across the SF Domain 4) Program the reporting interval at the MAs (optional). AGV Expires June 13, 2016 [Page 13] INTERNET DRAFT PM Architecture for SFC December 11, 2015 6 Classifier Operation Classifier classifies packets for the PM Instance based on the instruction provided by the controller. In the classified packets it encodes the following information in Context header of NSH metadata PMF Identifier: As provided by the Controller Window Identifier: Locally generated Number which changes based on the Window size. MA(s): List of MA(s) with PM Type Note: Selecting the packets in a flow to participate in a PM is decided by Controller/Classifier and it is outside the scope of this document. 7 MA Operation MA carries out following operation when packet with NSH header encountered: - Detection of PM Context Header in a packet. - Processing of Context Header Information - Check the Presence of self index in Context header. - Identification of the PM Type. - Performance Measurement based on the identified Type. * For Packet Loss: Accumulates statistics for received & sent Packets for a given PMF + Window * For Delay: Record the time when the packet was received and sent for a given PMF + window - Reporting of accumulated statistics at configured interval to the Collector. This interval should be consistent across all MA. Note: 1) MA does not maintain the context of the window, the statistics information of a single window can be sent in more than one report, its Collector's responsibility to map and accumulates the statistics of a window from different reports. 2) If Classifier itself is a MA it also needs to do performance measurement and reporting. AGV Expires June 13, 2016 [Page 14] INTERNET DRAFT PM Architecture for SFC December 11, 2015 8 Collector Operation Collector collects the data from the MA and performs the following for Data co-relation: - Collector uses PMF Identifier to group statistics related to single PM flow. Collector maintains the statistics related to a single PM flow from multiple MA to compute the performance for the flow. - Collector uses the Window identifier to group the statistics received from multiple MA for a single window for a given PM Flow. - Since MA does not maintain the context of the block interval, statistics information of a single block can be received in more than one report; Collector maps and accumulates the statistics of a block from different reports. - Collector performs the PM computations based on the PM type & statistics collected from the MA; the identification of PM segment is done in the collector, based on the PM types received from the segment end point MAs. 9 Measurement steps Step 1: Programming of PM Instance at Classifier. Step 2: Classifier Classifies & select Packets for a PM Flow. Step 3: Classifier Encapsulates the PM attributes in PM Context Header for selected packets. Step 4: Packet is sent out of Classifier. Step 5: MA receives packet and check presence of PM Context Header (If Context header is not present move to Step 9.) Step 6: MA check presence of its service index in PM Context Header (If its own index is not present than move to Step 9). Step 7: MA obtains PM Type to be carried out and according accumulates PM statistics for a given PMF + Window for received and sent packet. Step 8: MA reports the accumulated PM statistics to Collector at reporting interval. Step 9: Regular Packet processing continues. Step 5 to Step 9 is repeated at every MA. AGV Expires June 13, 2016 [Page 15] INTERNET DRAFT PM Architecture for SFC December 11, 2015 10 Hop by Hop Performance Measurement In case PM needs to be performed on all the SFs in the SFP, as per the described NSH programming in classifier, all the SF's, SI needs to be added in the context header. This will ensure all the SFs participate in the PM. This mechanism will require all the SF to traverse the context header until the self SI is found. Alternatively, we can optimize this process by defining a new context type which means the all the SF's needs to perform the specified PM. By this way at classifier we can skip the SI encoding in the context header, and at MA we can skip the SI traversing. Extension for SFF participation in Hop by Hop PM. As mentioned in the above section, we can define a special context types which means SFF and/or needs participate in the PM. 11 End to End Performance Measurement In case PM needs to be performed on the end point SFs in the SFP, these 2 SI needs to be encoded in the context header, and it will follow the normal procedure to perform E2E SF's PM. If in case PM needs to be performed between the classifier and SFC domain boundary SFF, a special context type will be encode on the NSH, which needs to be processed by the boundary SFF to report the PM data to collector and then strip the NSH. 12 Security Considerations No specific security considerations for this document 13 IANA Considerations No specific IANA considerations for this document AGV Expires June 13, 2016 [Page 16] INTERNET DRAFT PM Architecture for SFC December 11, 2015 14 References 14.1 Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [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. [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. AGV Expires June 13, 2016 [Page 17] INTERNET DRAFT PM Architecture for SFC December 11, 2015 14.2 Informative References [RFC5226] Narten, T. and H. Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC7498] Quinn, P., Ed. and T. Nadeau,Ed.,"Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/ RFC7498, April 2015, . [SFC-arch] Quinn, P., Ed. and J. Halpern, Ed., "Service Function Chaining (SFC) Architecture", 2014, . AGV Expires June 13, 2016 [Page 18] INTERNET DRAFT PM Architecture for SFC December 11, 2015 Authors' Addresses Anil Kumar S N Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560037 EMail: anil.sn@huawei.com Gaurav Agrawal Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560037 EMail: gaurav.agrawal@huawei.com Vinod Kumar S Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560037 EMail: vinods.kumar@huawei.com AGV Expires June 13, 2016 [Page 19]