Internet DRAFT - draft-deng-lmap-ps-collaboration
draft-deng-lmap-ps-collaboration
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
<Deng, et al.> Expires Sep 22, 2016 [Page 1]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 2]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 3]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 4]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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-
<Deng, et al.> Expires Sep 22, 2016 [Page 5]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 6]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 7]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 8]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 9]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 10]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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,
<Deng, et al.> Expires Sep 22, 2016 [Page 11]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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.
<Deng, et al.> Expires Sep 22, 2016 [Page 12]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> Mar 21, 2016
7 Security Considerations
TBA
8 IANA Considerations
There is no IANA action in this document.
9 Acknowledgements
TBA
<Deng, et al.> Expires Sep 22, 2016 [Page 13]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 14]
INTERNET DRAFT <PS and Use-cases for Collaborative LMAP> 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
<Deng, et al.> Expires Sep 22, 2016 [Page 15]
