OPS Area L. Deng INTERNET-DRAFT China Mobile Intended Status: Informational R. Huang Expires: September 22, 2016 Huawei S. Duan CATR March 21, 2016 Problem Statement and Use-cases for Collaborative Measurements draft-deng-lmap-ps-collaboration-00 Abstract This document presents the problem statement and use-cases for cross domain collaborative measurement practices, where multiple autonomous measurement systems collaborate together in performing various connectivity or performance measurements to help with QoE enhancement by ICPs, network performance monitory to guide ISP/Regulator coordination between autonomous network domains and/or regulatory policies and cross-boundary troubleshooting for complaints from end consumers. 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 Copyright and License Notice Expires Sep 22, 2016 [Page 1] INTERNET DRAFT Mar 21, 2016 Copyright (c) 2013 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 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 IPPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 LMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Motivations for Collaborative Cross-Domain Measurements . . . . 7 4 Use-cases for Collaborative Measurements . . . . . . . . . . . . 8 4.1 Use-cases for Regulators . . . . . . . . . . . . . . . . . . 8 4.1.1 within a regulator's own region . . . . . . . . . . . . 8 4.1.2 peering performance between ISPs . . . . . . . . . . . . 9 4.2 Use-cases for the ISP . . . . . . . . . . . . . . . . . . . 10 4.2.1 measurements within a single domain . . . . . . . . . . 10 4.2.2 measurements for multi-domain ISP networks . . . . . . . 10 4.3 Use-cases for the ICP . . . . . . . . . . . . . . . . . . . 11 4.3.1 QoE-oriented performance enhancement . . . . . . . . . . 11 4.3.2 Trouble-shooting initiated by end consumers . . . . . . 11 5 Derived Requirements . . . . . . . . . . . . . . . . . . . . . . 12 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1 Normative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Expires Sep 22, 2016 [Page 2] INTERNET DRAFT Mar 21, 2016 1 Problem Statement 1.1 IPPM The IP Performance Metrics (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. It also develops and maintains protocols for the measurement of these metrics. These metrics are designed such that they can be used by network operators, end users, or independent testing groups. The WG will seek to develop new metrics and models to more accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths. However, Specifying network or lower layer OAM mechanisms, including measurement task management and result aggregation, is out of scope of the IPPM charter. 1.2 LMAP With the rapid development of Internet technology and the increasing complexity of broadband network architecture, it is becoming difficult to do large scale network measurements due to the lack of the unified measurement system and cooperative protocols. Therefore, the Large-Scale Measurement of Broadband Performance (LMAP) working group is formed to standardize a large scale measurement system for the performance measurements of all kinds of broadband access methods. There are 3 types of entities proposed in the LMAP architecture: [I- D.ietf-lmap-framework] o Measurement Agents (MAs), implemented in network to perform measurement tasks; o Controller, responsible for creating and assigning the measurement tasks; and o Collector, in charge of collecting and storing measurement results. LMAP's current focus is to specify the information model, the associated data models, the control protocol for the secure Expires Sep 22, 2016 [Page 3] INTERNET DRAFT Mar 21, 2016 communication between Controller and MA, and the report protocol for the secure communication between MA and Collector. 1.3 Gap Analysis For a large network, collaboration between multiple Controllers may also be needed for performing local measurement tasks, either because there is a practical limit on the number of MAs a single Controller can manage simultaneously for scalability considerations, because that a local task may involve multiple MAs that are speaking different languages (i.e. different control/report protocols), or because different organizations want to interconnect their measurement systems. Current LMAP protocols are designed under the following assumptions. o All the involved entities are under the control of a single organization. o An MA can only be controlled by a single controller at any given time. o There is no communication between Controllers, between Collectors, or between a Controller and a Collector. However, cross-organization collaborations are increasingly common. For example, accurate troubleshooting for mobile services usually involves two or more organizations, and end-to-end performance measurement may be conducted across multiple ISPs. +---------+ 1| | +--------------------------------------+-----+ | | Cross-Domain Measurement Management System <---+ +--------------------+-----------------------+ 1..n 1| | 1..n +--------------------v-----------------------+ | Local Measurement Management System (LMMS) | +--------------------+-----------------------+ 1| | 1..n +------------v--------------+ | Management Entity (ME) | +---------------------------+ Figure 1 Collaborative Measurement Architecture Expires Sep 22, 2016 [Page 4] INTERNET DRAFT Mar 21, 2016 As shown in the above figure, it is straight-forward to use a multi- level management architecture here, in which the bottom level uses single-domain measurement systems, e.g. LMAP, for coordinating and managing local measurement tasks, and the upper level uses a cross- domain management system for initiating and orchestrating global measurement tasks. In the following, this document first discusses the use-cases,for collaborative measurement practices, where multiple autonomous measurement systems collaborate together to help with QoE enhancement by ICPs, network performance monitoring to guide planning for network infrastructure and cross-boundary troubleshooting for SLA complaints from end consumers, as well as performing regulatory supervision by national regulators; and further summarizes requirements and security considerations for global measurement system. 2 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]. The following acronyms are used extensively in this document. o ICP, Internet Content Provider. o QoE, Quality of Experience. o QoS, Quality of Service. o ISP, Internet Service Provider, or shortly Operator. o SLA, Service Level Agreement. o UE, User Equipment. o MAN, Metro Area Network. o WAN, Wide Area Network. o ME, Measurement Entity (as defined later in this section). o LMMS, Local Measurement Management System (as defined later in this section). o MD, Measurement Domain (as defined later in this section). The following definitions are borrowed from LMAP framework [I-D.ietf- Expires Sep 22, 2016 [Page 5] INTERNET DRAFT Mar 21, 2016 lmap-framework], and used to describe the corresponding entities within a participating LMAP system. o Controller: A function that provides a Measurement Agent with its Instruction. o Collector: A function that receives a Report from a Measurement Agent. o Measurement Agent (MA): The function that receives Instruction Messages from a Controller and operates the Instruction by executing Measurement Tasks (using protocols outside the initial LMAP work scope and perhaps in concert with one or more other Measurement Agents or Measurement Peers) and (if part of the Instruction) by reporting Measurement Results to a Collector or Collectors. o Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic. o Measurement Task: The action performed by a particular Measurement Agent that consists of the single assessment of a Metric through operation of a Measurement Method role at a particular time, with all of the role's Input Parameters set to specific values. o Measurement Result: The output of a single Measurement Task (the value obtained for the parameter of interest or Metric). o Metric: The quantity related to the performance and reliability of the network that we'd like to know the value of. The following definitions are used in this document to describe corresponding entities for a collaborative performance measurement among multiple measurement systems. o Region, a geographical area or administrative domain under the regulation of a single regulator. o Domain, a collection of network devices and their interconnections under the operation of a single administrative entity. o LMMS, Local Measurement Management System, the collection of entities, residing in a participating domain, in charge of local measurement tasks management and result aggregation. For example, the Controller, the Collector and the group of lcoal MAs form the LMMS Expires Sep 22, 2016 [Page 6] INTERNET DRAFT Mar 21, 2016 for a domain using LMAP for local measurement management. o Measurement domain: One Measurement domain is equal to one local measurement system, e.g. a LMAP system as specified in [i.d-ietf- lmap-framework], where all the measurement entities (e.g. MAs) are controlled by a single controlling entity (e.g. LMAP controller). o ME, Measurement Entity, the entity, residing in a participating domain, executes Measurement Tasks and reports Measurement Results as instructed by the local Measurement Managing System. For example, an MA is an instantiation of an ME, in a participating domain using LMAP for local measurement management. 3 Motivations for Collaborative Cross-Domain Measurements End-to-end performance measurement and trouble-shooting are important for multiple parties, including: (1) Internet Service Providers, in solving end user's QoE issues by better managing and optimizing their networks, (2) Internet Content Providers, for enhance its service logic and application design, (3) regulators in examining the status of and guiding future regulation. From ISP's perspective, the importance of supporting measurement system (e.g LMAP) for its own network construction and operation is without doubt. But taken into account the potential impact of introducing third-party measurement entities (e.g. LMAP MAs) into key network entities, a sensible ISP would prefer to build its own local measurement (e.g. LMAP) system based on measurement entities (e.g. MAs) embedded into its local network devices. It is hence expected that the majority of end-to-end performance measurements will be conducted in a collaborative manner involving multiple autonomous measurement systems, for the following reasons: On one hand, for the regulator, in order to stimulate network development, it is necessary to have a clear picture of ISPs' peering performance for interconnection points in addition to their own local network construction. Considering the prohibitive cost of a unified third-party deployment for measurement entities (e.g. LMAP MAs) at various peering links among ISPs for a large geographic area, it may be more practical to make use of ISPs' autonomous LMAP systems for collaboration. Let us take the example in China for instance. China's networks are Expires Sep 22, 2016 [Page 7] INTERNET DRAFT Mar 21, 2016 complex, with more than 31 provinces and 300 regions come to hierarchical networks deployments. There are 3 ISP giants (CMCC, CTCC, CUCC) in mainland China, managing nationwide hierarchical networks, each is consisted of 3-4 national center points for interconnecting on the top, more than 30 provincial backbone networks in the middle, and more than 300 regions' local networks on the bottom. In other words, the national regulator must know the network status of the 3 networks in each region of a province, of a province, and finally the whole country. It would be prohibitive for the national regulator authority, MIIT to deploy its own dedicated probes nationwide(900+). Furthermore, regulators in different countries may want to interconnect their measurement systems to perform cross-border measurements. On the other hand, for the ICP or user, it does not help much for service optimization or trouble shooting if the end-to-end performance measurement is conducted via a simple client-server model while treating the network as a black box. In the meantime, for the purpose of providing more value-added service to the ICPs as well as subscribers, there is motive for an ISP to open its LMAP system to some extent and collaborate with the ICP/user in understanding the bottleneck and exploiting better network servicing for end-to-end QoE. In the following sections, more specific use-cases and derived requirements of collaborative measurement practices for end-to-end performance measurement are presented. 4 Use-cases for Collaborative Measurements As stated above, there are motivations from the regulator, ISP/ICP and users to conduct collaborative measurements at the different levels in order to know if the current network conditions meet the expectations from the regulator policy, the ISP's resource provision agreement or the ICP's service provision agreement. In particular, the following usecases are identified. 4.1 Use-cases for Regulators A regulator may want to monitor the current status and the future deployment of network construction and operation of its region. In order to promote network development, the regulator needs to monitor the status of interconnection between different ISPs as well as the overall network status. 4.1.1 within a regulator's own region Expires Sep 22, 2016 [Page 8] INTERNET DRAFT Mar 21, 2016 Understanding the current situation of its own region is necessary for a regulator to form guiding policies for stimulating further growth in high-speed networks. In order to get a clear picture of a large geographic area, the regulator may choose to not deploy a dedicated local measurement (LMAP) system on its own, while it's necessary to deploy a large number of measurement entities (e.g. MAs). The regulator may achieve this goal by means of the ISP's local measurement systems and the third-party measurement systems. In that case, multiple organizations would simultaneously deploy their dedicated measurement entities for private local measurement systems within their network boundary in the same region, and by combining them together a cross-domain measurement system can mainly cover the whole region's network infrastructure. Through collaboration, measurement entities from multiple organizations can perform comprehensive measurement for the whole regional network in great depth, which can reflect the network's operational state. 4.1.2 peering performance between ISPs Low performance of peering links between different ISPs not only has great impact on ICP services, but also on an access ISPs relying on transit ISPs for Internet connectivity. For example, a mobile operator lacking access to an Internet resource will have to pay interconnections to other operators. The regulator can formulate policies to promote information sharing between ISP networks and investigate the user QoE problem by understanding the interconnection performance. For the same reason, an ISP/ICP can also benefit from a more clear understanding of the performance of the interconnection. For example, the data flow for a service request from a mobile terminal to an ICP first goes through the access ISP network and then into the Internet via a transit ISP network. Similarly, before entering the ICP's own private data-center, it may traverse another transit ISP network. As shown in Figure 1, the measurement can be implemented between a measurement entity in ISP#1 and another measurement entity in ISP#2 to understand the interconnection quality. UE<=>access ISP<=>transit ISP #1<=>Internet<=>transit ISP #2<=>ICP Figure 2 Cross-Domain data flow path In a single administrative domain, there are also scenarios for Expires Sep 22, 2016 [Page 9] INTERNET DRAFT Mar 21, 2016 collaborative measurement. 4.2 Use-cases for the ISP 4.2.1 measurements within a single domain For one side, if the network scale is large enough, with many measurement entities, scalability of the Controller may become an issue [I-D.ooki-lmap-internet-measurement-system]. It would be a simple and scalable manner to construct an effective measurement system by dividing the huge number of measurement entities into groups, and assign a Controller separately to manager each subset of measurement entities. The size of the measurement entity groups are dependent on the number of measurement entities that a single Controller can manage at a time during the real deployment. On the other hand, even the network scale is small, if there are many heterogeneous network devices as functioning measurement entities, the corresponding measurement protocols/interface may be diverse. For example, browser built-in measurement entities can be conveniently implemented as HTTP clients, the CPE devices usually support TR.069 as their management protocol and network devices residing in the core network generally support and runs SNMP protocol by default. In other words, different Controllers speaking different local measurement protocols may be needed to respectively manage different groups of measurement entities in the real deployment. If a measurement task involves measurement entities that belong to different groups, collaboration among corresponding controlling entities is needed for instructing the measurement entities with the task configuration and data collection. 4.2.2 measurements for multi-domain ISP networks For a large ISP, it is common practice to divide its global network into several autonomous domains, each operated and managed by a regional branch. It is therefore, very likely that separate local measurement systems would be deployed into these autonomous domains, resulting in a call for collaborative measurement scenarios even within the same ISP's network. Take the case in China for instance, there are multiple nationwide Expires Sep 22, 2016 [Page 10] INTERNET DRAFT Mar 21, 2016 ISP networks. Within these ISPs, relatively independent local branches, separated by physical territorial scope such as the province, operate their local network which has an autonomous domain or multiple autonomous domains. Each Provincial branch can deploy its own LMAP system to monitor its local network states. 4.3 Use-cases for the ICP 4.3.1 QoE-oriented performance enhancement New applications or updated applications with newly-added functions/features are being pushed to the end user every day, with an increasing requirement for constant performance optimization based on realistic network utilization resultant from application dynamics. It is important to understand the practical performance and impact of various network segments (e.g. access network, transit network and Internet) on the end-to-end traffic path. For the design, experimental and operational phases of a new feature/technology introduction to an application is also of great importance. However, it is expensive and non-economic for each ICP to build its own dedicated local measurement system into various ISPs' networks. At the same time, with the transition of ISPs' mindset from subscriber-centered charging for network access to ICP-centered charging, ISPs are motivated to offer assistance to ICPs' exploration for better QoE through more efficient usage of network resources provisioned under the guidance of real-time performance measurements and optimization to accommodate application dynamics. With ISPs' cooperation, various network segments are no longer hidden behind the black box to end-to-end performance measurements. By combining inputs from both its own end-based LMAP system with ISPs' measurement data, it is possible for an ICP to identify the bottleneck of service provision and develop corresponding enhancement via better guided technology introduction to the application as well as more targeted SLA negotiation with ISPs. 4.3.2 Trouble-shooting initiated by end consumers With the growing influence of broadband access nowadays, more and more traditional ICPs are extending to the market of home gateways, as a result of the popularity of intelligent TVs and intelligent STBs. The services of end users in their home network are probably controlled by ICPs which may collaborate with the broadband access service providers to guarantee users the promised QoE. When malfunctions influencing user QoE occur in these types of services, Expires Sep 22, 2016 [Page 11] INTERNET DRAFT Mar 21, 2016 it is necessary to have a mechanism with which the diagnostic measurement can be launched from the user side and identify the faulty party. Generally the home gateway(such as a home WLAN router) is the border between the ISP network and the home network. The ISP network includes the access network, MAN and WAN. The home network includes home gateway, TV, STB, etc. For a broadband access user who buys a third-party home gateway device, the typical service access path is shown in Figure 2. The home network between home gateway and UE is private and is not controlled by any ISP. However, the user may want to measure the link quality between the UE and the home gateway, the UE and the access ISP, or the UE to the ICP, separately. Thus in this scenario, it is difficult to deploy a single LMAP system which completely covers the whole path for accurate end-to-end QoE measurements and assists fault identification. UE <=>home net<=>home GW<=>access ISP<=>transit ISP<=>Internet<=>ICP Figure 3 Cross-Domain data traffic from home network to ICP 5 Derived Requirements This section presents derived requirements for measurement management protocols to enable the above collaborative use-cases across multiple measurement domains. In particular: o Independence of the local measurement system of individual participating domainsor the specific measurement protocols or metrics. o Global measurement task management. o Cross-domain measurement task management. Expires Sep 22, 2016 [Page 12] INTERNET DRAFT Mar 21, 2016 7 Security Considerations TBA 8 IANA Considerations There is no IANA action in this document. 9 Acknowledgements TBA Expires Sep 22, 2016 [Page 13] INTERNET DRAFT Mar 21, 2016 10 References 10.1 Normative References [I-D.ietf-lmap-framework] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for large-scale measurement platforms (LMAP)", draft-ietf- lmap-framework-11 (work in progress), February 2015. [I-D.ietf-lmap-information-model] Burbridge, T., Eardley, P., Bagnulo, M., and J. Schoenwaelder, "Information Model for Large-Scale Measurement Platforms (LMAP)", draft-ietf- lmap-information-model-03 (work in progress), January 2015. [I-D.ooki-lmap-internet-measurement-system] Ooki M., Kamei, S., "Internet Measurement System", draft-ooki-lmap-internet- measurement-system-01(work in progress), December 2014. [I-D.ietf-lmap-use-cases] Linsner M., Eardley, P., Burbridge, T., Sorensen, F., "Large-Scale Broadband Measurement Use Cases", draft-ietf-lmap-use-cases-06(work in progress), Feburary, 2015 Expires Sep 22, 2016 [Page 14] INTERNET DRAFT Mar 21, 2016 Authors' Addresses Lingli Deng China Mobile Email: denglingli@chinamobile.com Rachel Huang Huawei Email: rachel.huang@huawei.com Shihui Duan China Academy of Telecommunication Research of MIIT Email: duanshihui@catr.cn Expires Sep 22, 2016 [Page 15]