LMAP Working Group L. Deng INTERNET-DRAFT China Mobile Intended Status: Informational R. Huang Expires: December 29, 2014 Huawei S. Duan CATR May 29, 2014 Use-cases for Collaborative LMAP draft-deng-lmap-collaboration-00 Abstract This document discusses the motivation and use-cases for collaborative LMAP practices, where multiple autonomous measurement systems collaborate together to help with UoE 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 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Expires December 29, 2014 [Page 1] INTERNET DRAFT May 29, 2014 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 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Motivation for Collaborative LMAP . . . . . . . . . . . . . . . 4 4 Use-cases for Collaborative LMAP . . . . . . . . . . . . . . . . 5 4.1 UoE-oriented network regulation . . . . . . . . . . . . . . 5 4.1.1 the current situation of its own region network . . . . 5 4.1.2 the peering performance between ISPs in its own region . 5 4.2 Collaborative measurement for multi-domain ISP network . . . 6 4.3 UoE-oriented performance enhancement by ICP . . . . . . . . 6 4.4 Trouble-shooting initiated by end consumers . . . . . . . . 7 5 Derived Requirements . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Initiator-controller exchange for task instruction . . . . . 8 5.2 Reporter-collector exchange for data aggregation . . . . . . 8 5.3 initiator-reporter exchange for output instruction . . . . . 8 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Expires December 29, 2014 [Page 2] INTERNET DRAFT May 29, 2014 1 Introduction With the rapid development of Internet technology and the increasing complexity of broadband network architecture, it is quite 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 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 an information model, the associated data models, the control protocol for the secure communication between Controller and MA, and the report protocol for the secure communication between MA and Collector. Current LMAP protocols are based on the following assumptions. o All the involved entities are under the control of a single organization, which also means an MA can only be controlled by one controller at any 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 conduct across multiple ISPs. How to do large scale performance measurements in these scenarios is still unsolved. This document discusses the motivation and use-cases for collaborative LMAP practices, where multiple autonomous measurement systems collaborate together to help with UoE enhancement by ICPs, network performance monitory to guide ISP/Regulator planning for network infrastructure and/or regulatory policies and cross-boundary Expires December 29, 2014 [Page 3] INTERNET DRAFT May 29, 2014 troubleshooting for SLA complaints from end consumers. 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]. Initiator, the instructor for collaborative LMAP tasks, potentially on behalf of a regulator, a third party ICPs or an end consumer. Reporter, the reporting party that aggregates partial measurements reports from collaborative LMAP task participants and produces the ultimate report to the task initiator. 3 Motivation for Collaborative LMAP End-to-end performance measurement and trouble shooting is important to solve end user's UoE issues, to manage and optimize the network of Internet Service Providers, to improve service logic and application design for Internet Content Providers, and to examine the status of and guide future administration of local network infrastructures for regulators. From ISP's perspective, given the importance of supporting LMAP for its own network construction and operation as well as the potential impact of introducing third-party LMAP MAs into key network entities, a sensible ISP would prefer to build its own LMAP system based on 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 LMAP systems, for the following reasons: On one hand, for the regulator, in order to stimulate local network development, it is necessary to have a clear picture of local ISPs' peering performance for interworking points as well as their own network construction. Considering the prohibitive cost of a unified third-party deployment for LMAP MAs at various interworking points for a large geographic area, it is expected to be more practical to make use of ISPs' autonomous LMAP systems for collaboration. 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 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 Expires December 29, 2014 [Page 4] INTERNET DRAFT May 29, 2014 some extent and collaborate with the ICP/user in understanding the bottleneck and exploiting better network servicing for end-to-end UoE. 4 Use-cases for Collaborative LMAP The regulator, ISP/ICP and users would hope 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. 4.1 UoE-oriented network regulation A regulator is responsible for monitoring the current status and planning for the future of network construction and operation of its own region. In order to promoting the region network development, the regulator needs to monitor the status of interconnection between different ISPs as well as the overall network construction status in this region. 4.1.1 the current situation of its own region network Understanding the current situation of its own region network is necessary for a regulator to form guiding policies for adjusting the network architecture and planning for network development in the future. In order to get a clear picture of a large geographic area, it is prohibitive for the regulator to deploy a dedicated LMAP system on its own, where it's necessary to deploy a large number of MAs. For a small region, the deployment cost is acceptable, but for a large region, the cost is very expensive and unacceptable. The regulator usually achieve this goal by means of ISP's LMAP and the third-party LMAPs. Therefore, it is expected that multiple organizations would simultaneously deploy their dedicated MAs for private LMAP system within their network boundary in the same region and by combining them together a measurement system can mainly cover the whole region's network infrastructure. Through collaboration, MAs from multiple organizations can perform comprehensive measurement for the whole gregion network in great depth which can reflect the local network operation state. 4.1.2 the peering performance between ISPs in its own region Expires December 29, 2014 [Page 5] INTERNET DRAFT May 29, 2014 Bad performance of peering links between different ISPs not only has great impact to ICP services but also to a local access ISP relying on other transit ISP for internet access. For example, a mobile operators lacking internet access resource have to pay expensive interconnection expense to other operators. The Regulator can formulate instructive policies to promote information circulation between ISP networks and solve the user QoE problem by understanding the interconnection QoS. For the same reason, ISP/ICP can also benefit from more clear understanding on the Interconnection quality. Taking mobile network for example, the data flow for a service request from a mobile terminal to a ICP firstly goes through the local ISP access network and then into the internet via a third-party 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 ISP#1 MA and ISP#2 MA to understand the interconnection quality. UE<=>access ISP<=>transit ISP #1<=>Internet<=>transit ISP #2<=>ICP Figure 1 mobile network data access across domains 4.2 Collaborative measurement for multi-domain ISP network For large ISP, it is common practice to divide its global network into several autonomous domains (ASs), each operated and managed by a region branch. It is therefore, very likely that separate LMAP 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 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 AS or multiple ASes. Each Provincial branch can deploy its own LMAP system to monitor its local network states. 4.3 UoE-oriented performance enhancement by ICP New applications or revision 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, Expires December 29, 2014 [Page 6] INTERNET DRAFT May 29, 2014 experimental and operational phases of a new feature/technology introduction to an application. However, it is expensive and non- economic for each ICP to build its own dedicated LMAP system into various ISPs' networks. At the same time, with the transition of ISPs' mindset from subscriber-centered charging for network accessing to ICP-centered charging, ISPs are motivated to offer assistance to ICPs' exploration for better UoE through more efficient usage of network resource provision under the guidance of real-time performance measurement 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 measurement. 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.4 Trouble-shooting initiated by end consumers With growing influence of broadband access nowadays, more and more traditional ICPs are extending to the market of home gateway, as a result from the popularity of intelligent TVs and intelligent STBs. The services of end users in their home network are probably controlled by ICPs who may collaborate with the broadband access service providers to guarantee users the promised QoE. When malfunctions influencing user QoE occur in this type of services, it is necessary to have a mechanism with which the diagnostic measurement could be launched from the user side and demarcate the problem. Generally the home gateway(such as home WLAN router) is the border of ISP network and home network. The ISP network includes 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 may not controlled by any ISP. However, the user may want to measure the link quality of between the UE and home gateway, the UE and access ISP, or the UE to the ICP, separately. Thus in this scenario, it is difficult Expires December 29, 2014 [Page 7] INTERNET DRAFT May 29, 2014 to deploy a single LMAP system which completely covers the whole path for accurate end to end QoE measurements and assists fault demarcation. UE <=>home net<=>home GW<=>access ISP<=>transit ISP<=>Internet<=>ICP Figure 2 cross-domain data traffic in home network 5 Derived Requirements This section presents derived requirements for LMAP protocols to enable the above collaborative use-cases. In particular, two entities for the general coordination of cross- organization interactions for collaborative LMAP tasks are introduced: the initiator and the reporter, for cross-domain measurement task assignment and result aggregation, respectively. Three protocols for interactions for the newly-introduced entities and existing LMAP entities are discussed. 5.1 Initiator-controller exchange for task instruction The globally trusted and verifiable initiator instructs each participating LMAP controllers with corresponding measurement sub- tasks to be performed within the LMAP system, indicating the corresponding reporter, to whom the results of the sub-tasks is to be submitted. A globally unified identifier may be required for each collaborative measurement task too. 5.2 Reporter-collector exchange for data aggregation A collector from each participating LMAP system interacts with the corresponding reporter to report local measurement results. 5.3 initiator-reporter exchange for output instruction The initiator also notifies the reporter with instructions on how to output the final measurement report (e.g. data aggregation methods to be used) as well as the identities of the participating controllers. 6 Security Considerations It is assumed that the security issues within a participating LMAP system can be addressed by its local security mechanisms and out of Expires December 29, 2014 [Page 8] INTERNET DRAFT May 29, 2014 scope of this document. Each participating LMAP system may have its own consideration and policy regarding its local network and/or subscriber private information. In performing collaborative task, it is still possible for a collector to enforce local protection schemes, e.g. filtering algorithms, onto local measurement data before submission to the reporter, hence providing protection to sensitive information for both the subscriber and the network operator. It is important for a participating LMAP system to be able to authenticate the initiator/reporter for a given collaborative measurement task, provide differentiated service provision according to its local policies (e.g. flexible authorization based on the initiator's identity, the type of measurement task, measurement methodology, frequency, etc.), and protect itself from service abuse of malicious initiators or information leakage to malicious reporters. It is expected that, an ISP LMAP system is not likely to initiate local active measurement task, in response to a third-party instruction. A task/data verification scheme is needed for the reporter to exclude un-authorized or non-intended collectors from tampering the measurement report or blocking the reporter from proper functioning with corrupted/forged/replayed local reports. 7 IANA Considerations There is no IANA action in this document. Expires December 29, 2014 [Page 9] INTERNET DRAFT May 29, 2014 8 References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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-05 (work in progress), May 2014. [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-00 (work in progress), February 2014. Expires December 29, 2014 [Page 10] INTERNET DRAFT May 29, 2014 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 December 29, 2014 [Page 11]