Internet Draft Anil Kumar S N SFC Working Group Gaurav Agrawal Category: Informational Vinod Kumar S Expires: December 30, 2016 Huawei Technologies C. Jacquenet Orange June 28, 2016 Performance Measurement Architecture for SFC draft-agv-sfc-performance-measurement-architecture-02 Abstract This document describes performance measurement(PM) architecture for Service Function Chains (SFCs) to assess the operational status and behavior of a service function, a subset of service function's, a whole service function chain as a function of the actual deterministic service function / service function chain. This document does not propose solutions, protocols, nor any extension to existing protocols. 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 December 30, 2016 AGV Expires December 30, 2016 [Page 1] INTERNET DRAFT PM Architecture for SFC June 28, 2016 Copyright and License Notice Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . . 7 3 PM Measurements Methods: . . . . . . . . . . . . . . . . . . . . 8 4 Performance Measurement Attributes . . . . . . . . . . . . . . . 9 4.1 Metadata Attributes . . . . . . . . . . . . . . . . . . . . 9 4.2 PM Reporting Attributes . . . . . . . . . . . . . . . . . . 9 4.3 Performance Measurement Attributes Description . . . . . . . 9 4.3.1 PMF Identifier . . . . . . . . . . . . . . . . . . . . . 10 4.3.2 Window Identifier . . . . . . . . . . . . . . . . . . . 10 4.3.3 Measurement Agents Identifier with PM type . . . . . . . 11 4.3.4 Performance Statistics . . . . . . . . . . . . . . . . . 12 5 Measurement Controller Operation . . . . . . . . . . . . . . . . 12 6 Measurement Classifier Operation . . . . . . . . . . . . . . . . 13 7 MA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8 Collector Operation . . . . . . . . . . . . . . . . . . . . . . 14 9 Measurement Steps . . . . . . . . . . . . . . . . . . . . . . . 14 10 Hop by Hop Performance Measurement . . . . . . . . . . . . . . 15 11 SFC as a whole Performance Measurement . . . . . . . . . . . . 15 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 13 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 15.1 Normative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 AGV Expires December 30, 2016 [Page 2] INTERNET DRAFT PM Architecture for SFC June 28, 2016 AGV Expires December 30, 2016 [Page 3] INTERNET DRAFT PM Architecture for SFC June 28, 2016 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). This document describes an architecture used for assessing and monitoring SFC operation. It includes architectural concepts, principles, and components, with a focus on assessing the operational status and behavior of a SF, a subset of SFs, a whole SFC as a function of the actual deterministic SF/SFC. Proper operation of a SFC depends on the ability to monitor and quickly identify faults and focus attention on the root cause of the problem. To achieve this we need to monitor the performance parameters of SFC like packet loss, delay, jitter etc. For instance a SFC is composed of diffServ (e.g., traffic conditioning capabilities) and NAT functions, with OOP as a traffic type. To ensure the proper operation of a OOP it's required to ensure that traffic is properly re-marked before invoking the NAT function which selects a specific pool for such OOP traffic. Incorrect re- marking of this traffic will lead to performance deterioration in terms of increase in one way delay. For another instance a SFC is composed of firewall which is supposed to controls the incoming and outgoing network traffic based on predetermined security rules. To ensure the proper functioning of this SF it's required to ensure that a specific set of traffic must be dropped and another specific set of traffic must be allowed to pass. Continuous measurement and monitoring of packet delay/loss for a SF, a subset of SFs, a whole SFC will help to find the problem. Also performance measurement results can be used to locate the root cause. which inturn can also be used to possibly take required action as far as SFC structuring is concerned. Service provider's service level agreements (SLAs) usually include performance indicators like packet loss or inter-packet delay variation that need to be measured over a given period of time. SFC Performance measurement enables operators with greater visibility into the performance characteristics of their SFCs, thereby ensuring service SLAs. AGV Expires December 30, 2016 [Page 4] INTERNET DRAFT PM Architecture for SFC June 28, 2016 SFC is at service layer which is independent of transport layer technology. For a SFC underlying layer can be a mix of multiple transport layer tunneling technology like MPLS, VXLAN etc. SLA measurements of independent transport layer will not be capable to assess the operational status and behavior of a SF, a subset of SFs, a whole SFC as a function of the actual deterministic SF/SFC which leads to a requirement for performance measurement architecture specific to service function chain. Transport layer PM and SFC PM can go hand in hand, SFC PM can be used to obtain the exact segment of problem if that segment is one of the Transport layer Tunnel, transport layer PM can be used to locate exact fault location. Requirements of SFC performance measurement architecture includes: 1) Localization of performance degradation occurred due to a unit in a service function chain. 2) Localization of performance degradation for a specific service traffic type 3) Enable service providers with a tool to offer high value services whose performance degradation can be proactively located and corrected. 4) ECMP scenarios can result in out of order packets, performance measurement should consider this while measurement. 5) Validation of service function chain performance at the time of deployment/fault correction verification (using probe packets) 6) Runtime Validation of service function chain performance using traffic packets itself to get accurate performance data without additional probe packets. 7) Performance measurement under induced traffic level. The motivation for this can be related to the rate and the amount of traffic that can influence the accuracy of the measurement results 8) Optimized measurement by keeping minimal performance measurement load. AGV Expires December 30, 2016 [Page 5] INTERNET DRAFT PM Architecture for SFC June 28, 2016 Following capabilities are required to be supported by performance measurement architecture to address above requirements. 1) Capability to assess and monitor at a) SF b) SFF c) Set of SF/SFF d) Segment(s) between any two SF/SFF in a SFC. e) SFC as a whole. 2) Capability to measure performance for fine-grained and coarse-grained flow. 3) Capability for Continuous/proactive & selective/on-demand measurement. 4) Support for all three measurement methods: Active Measurement method: Active method measures performance and other parameters by injecting test traffic into the network from specific locations (e.g., a Point of Presence). Passive measurement method: Passive method measures performance and other parameters based on the observation of live traffic forwarded in the network. Hybrid measurement method: Hybrid measurement method uses both active and passive measurement methods. 5) Capability to measure performance even in case of out of order packets. AGV Expires December 30, 2016 [Page 6] INTERNET DRAFT PM Architecture for SFC June 28, 2016 2. Architecture Overview +--------------------+ +------------------+ | | | | | Measurement | | Measurement | | Controller +----------+ Collector | | | | | | | | | +--------------+-----+ +--------+---------+ | | +----------------+-------------------------+--------------+ | Candidate Measurement Agents | | | | +----- | | +------------+ | SF | | | | | +--+-- | | | Measurement| | | | | CLassifier | +---+----+ +--------+ | | | <-------> SFF <--------> SFF | | | | | +--------+ +---+----+ | | | | | | | +------------+ +-----+------+ | | +----+ +----+ | | | SF | | SF | | | +----+ +----+ | +---------------------------------------------------------+ The SFC performance measurement architecture relies upon the following components: Measurement Controller: An entity that controls and coordinates a set of measurement functions. The measurement controller is responsible for programming the performance measurement instance at measurement classifier and updating the same to measurement collector, additionally it can inject probe packets in SFP for measurement. Measurement Collector: An entity that collects measurement data from a measurement agents (MAs). A measurement collector functionality could be integrated with one of the MAs deployed in the network or with the measurement controller itself. Measurement Classifier: An entity responsible for encoding measurement control information based on PMI programmed by measurement controller. SFC Classifier MUST incorporate the measurement classifier functionality to support SFC performance measurement. AGV Expires December 30, 2016 [Page 7] INTERNET DRAFT PM Architecture for SFC June 28, 2016 Measurement Agent: An entity that supports one or more Measurement functions. It is responsible for performance data collection and reporting the same to Measurement collector. The following elements MUST incorporate the MA functionality to support SFC performance measurement. o SF o SFF o Classifier o NSH Proxy Agent. 3 PM Measurements Methods: a) Active measurement : Measurement controller induce probe packets with encoded performance measurement data or programs PMI at measurement classifier which will in turn induce probe packets with encoded performance measurement data. measurement controller updates the PMI to measurement collector. Participating measurement agents based on received encoded information carry out measurements and reports the collected data to measurement collector. measurement collector co-relates received data and provides measurement results. Note: Current draft only covers the Measurement attributes programming for probe packets. Construction of base probe packet is outside the scope of this RFC. b) Passive measurement : Measurement controller programming PMI at measurement classifier and updating the same to measurement collector. measurement classifier encodes the performance measurement data in classified packets. Participating measurement agents based on received encoded information carry out measurement and reports the collected data to measurement collector. measurement collector co- relates received data and provides measurement results. c) Hybrid measurement : Measurement controller induce probe packets to pre-setup load condition for a SFC using active measurement. measurement controller than uses passive measurement to carry out performance measurement under load condition. AGV Expires December 30, 2016 [Page 8] INTERNET DRAFT PM Architecture for SFC June 28, 2016 4 Performance Measurement Attributes There are two types of PM attributes a) Metadata Attributes: These attributes are to instruct the MA to carry out the required performance measurement. Measurement classifier encodes these attributes in the traffic packets based on instructions provided by controller or these attributes are encoded directly in test packet by measurement controller/measurement classifier. b) PM reporting attributes: These attributes are used by MA(s) to report the collected performance data to Collector 4.1 Metadata Attributes The following attributes must be encoded as metadata for selected traffic or probe packets - PMF Identifier - Window Identifier - List of MA(s) identifier with PM Type 4.2 PM Reporting Attributes The following Information should be sent by each MA to the collector: - PMF identifier - Window identifier - MA identifier with PM type - Performance statistics 4.3 Performance Measurement Attributes Description Several performance attributes are introduced in this memo to carry performance control information. Each attribute has a unique purpose; they are interpreted based upon a specific context and the corresponding performance measurement is performed by the respective MA. AGV Expires December 30, 2016 [Page 9] INTERNET DRAFT PM Architecture for SFC June 28, 2016 4.3.1 PMF Identifier Purpose : To unambiguously identify a measurement flow in the SFC Domain. When a MA reports its performance data to collector, collector has to associate the data to a particular instance of measurement, as controller would have created multiple instance of measurements. By using service path index + service index only coarse-grained flows can be identified. To identify a fine-grained flows (Ex: SFC classification is based on destination IP, so flow classified based on this destination IP is coarse-grained flow. Sub flow corresponding to a particular destination IP within this flow is an example of fine-grained flows) within a SFC domain SPI + SI is not enough. PMF identifier is used to uniquely identify the performance measurement instance corresponding to fine grained flows. Value : Unique value within current SFC domain Processing : - At Classifier : The PMF Identifier is encoded in metadata Note: For probe packets this information is encoded by entity (controller/classifier) constructing probe packet. - At MA : Used as a key while collecting, maintaining & reporting PM statistics to collector. - At Collector : Collector correlates the performance data received from a MA using this PMF Identifier. 4.3.2 Window Identifier Purpose : Window identifier is to handle out of order packet scenario. Example: SFC classifier-----------SF1--------------SF2--------------SF3 Packet 1-->-------------------------------------------->Packet 2 Packet 2-->-------------------------------------------->Packet 1 Packet 1 belongs to earlier cycle of measurement but SF3 receives Packet 2 before packet 1 due to out of order problem. Now, when this data is co-related at Collector, if there is no window identifier, packet 2 will be treated as packet 1 and result will be incorrect. Window identifier is of local scope to a MA. Sender (Classifier/Controller) divides the flows into multiple windows. Packets with PM information in a window will have the AGV Expires December 30, 2016 [Page 10] INTERNET DRAFT PM Architecture for SFC June 28, 2016 same window identifier and consecutive windows will have a 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 correlates the performance data received from MA by using this window identifier. 4.3.3 Measurement Agents Identifier with PM type Purpose : To identify participating measurement agents with context and type of performance measurement. Value : Measurement agent for a given SFP is identified using MA identifier + service index MA identifier has two parts 1) Node identifier - 24 bit a) For SFF: MUST be unique number assigned by controller b) For SF: All zero. Context identifier itself identifies SF node. 2) Order identifier - 8 bit a) For SFF: Service index of next SF. b) For SF: Service index MA identifier SHOULD be in decreasing order of the SI for optimized traversal of the SI participation. PM Type (IANA assigned values) Processing : - At Classifier : Encode the participating MA(s) with PM type. AGV Expires December 30, 2016 [Page 11] INTERNET DRAFT PM Architecture for SFC June 28, 2016 - At MA : Presence of self service index triggers the PM collection & reporting - At Collector : Identifies the reporting MA 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 reports it to collector For packet delay: Record the time for sending and receiving a packet of a given flow + window and reports it to collector. - At Collector : Correlates and maintains received data 5 Measurement Controller Operation The Measurement Controller has the following responsibilities: 1) Programs the unique MA identifier for SF/SFF/SFC proxy in SFC domain. 2) Programs the PM instance at the classifier PM Instance MUST contain the following information: a) PM flow classification rule with PMF identifier (unique across the SFC domain). For coarse grained flow PM flow classification rule is optional. b) List of participating MA with PM type. c) Window size and PM schedule. 3) Provides the PM Instance to the collector (if required) 4) Ensures the uniqueness of MA identifier & PMF identifier across the SFC domain 5) Programs the reporting interval at the MAs (optional). 6) For active measurement creates and send test probe packet. AGV Expires December 30, 2016 [Page 12] INTERNET DRAFT PM Architecture for SFC June 28, 2016 6 Measurement Classifier Operation The classifier classifies packets for the PM instance based on the instructions provided by the controller. In the classified packets it encodes the following information in context header of NSH metadata: PMF identifier : As programmed by controller Window identifier : Locally generated number which changes based on the window size. MA(s) : List of MA(s) with PM type For active measurement measurement classifier MAY need to generate probe packet as instructed by measurement controller. Note: Selection of packets in a flow to participate in a PM is decided by controller and it is outside the scope of this document. 7 MA Operation MA carries out the following operations upon receipt of a packet with NSH header: - 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 packet 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 MAs. Note: 1) A MA does not maintain the context of the window, the statistical information of a single window can be sent in more than one report, it is the collector's responsibility to map and accumulate statistics of a window from different reports. 2) If the classifier itself embeds a MA, it also needs to do performance measurement and reporting. AGV Expires December 30, 2016 [Page 13] INTERNET DRAFT PM Architecture for SFC June 28, 2016 8 Collector Operation Collector collects data from the MA and performs the following operations for data correlation purposes: - Collector uses PMF identifier to group statistics related to a given PM flow. Collector maintains the statistics related to a given PM flow from multiple MAs to assess the forwarding performance. - Collector uses the window identifier to group statistics received from multiple MAs for a single window for a given PM flow. - Since the MA does not maintain the context of the block interval, statistical 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 computation 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 MA identifier at SF/SFF/SFC proxy by controller. Programming of PM instance at classifier by controller 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 checks presence of its service index in PM context header (If its own index is not present, then 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 packets. Step 8: MA reports the accumulated PM statistics to collector at reporting intervals. AGV Expires December 30, 2016 [Page 14] INTERNET DRAFT PM Architecture for SFC June 28, 2016 Step 9: Regular packet processing continues. Step 5 to step 9 is repeated at every MA. 10 Hop by Hop Performance Measurement In case PM needs to be performed on all the SFs invoked along the SFP, as per the described NSH programming in the classifier, all the SFs MA identifier needs to be added in the context header. This will ensure all the SFs/SFFs participate in the PM. This mechanism will require all the SFs/SFFs to traverse the context header until the self SI is found. Alternatively, we can optimize this process by defining a new context type where all the SFs need to perform the specified PM. Thus, the classifier can skip the MA identifier encoding in the context header, and the MA can skip the MA identifier processing. Extension for SFF participation in hop-by-hop PM. As mentioned in the previous section, we can define a special context types which means SFF and/or needs participate in the PM. 11 SFC as a whole Performance Measurement In case PM needs to be performed on the endpoint SFs along the SFP, these 2 MA identifier needs to be encoded in the context header, and will follow the procedure to perform E2E SF's PM. In case the PM needs to be performed between the classifier and SFC domain boundary SFF, a special context type will be encoded in the NSH, which needs to be processed by the boundary SFF to report the PM data to the collector and then strip the NSH. 12 Acknowledgements Special Thanks to Nobin Mathew for his review and comments. AGV Expires December 30, 2016 [Page 15] INTERNET DRAFT PM Architecture for SFC June 28, 2016 13 Security Considerations There are no security considerations relevant to this document. 14 IANA Considerations No actions are required from IANA as result of the publication of this document. AGV Expires December 30, 2016 [Page 16] INTERNET DRAFT PM Architecture for SFC June 28, 2016 15 References 15.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. [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/ AGV Expires December 30, 2016 [Page 17] INTERNET DRAFT PM Architecture for SFC June 28, 2016 RFC7498, April 2015, . [SFC-arch] Quinn, P., Ed. and J. Halpern, Ed., "Service Function Chaining (SFC) Architecture", 2014, . AGV Expires December 30, 2016 [Page 18] INTERNET DRAFT PM Architecture for SFC June 28, 2016 Authors' Addresses Anil Kumar S N Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560066 EMail: anil.sn@huawei.com Gaurav Agrawal Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560066 EMail: gaurav.agrawal@huawei.com Vinod Kumar S Huawei Technologies India Pvt. Ltd, Near EPIP Industrial Area, Kundalahalli Village, Whitefield, Bangalore - 560066 EMail: vinods.kumar@huawei.com Christian Jacquenet Orange Rennes 35000 France Email: christian.jacquenet@orange.com AGV Expires December 30, 2016 [Page 19]