Internet DRAFT - draft-boucadair-lmap-considerations
draft-boucadair-lmap-considerations
Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Informational France Telecom
Expires: August 22, 2013 February 18, 2013
Large scale Measurement of Access network Performance (LMAP):
Requirements and Issues from a Network Provider Perspective
draft-boucadair-lmap-considerations-00
Abstract
This document raises several points related to the ongoing LMAP
(Large scale Measurement of Access network Performance) effort. The
goal is to contribute to define a scope for LMAP and its expected
contribution.
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 August 22, 2013.
Copyright Notice
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.
Boucadair & Jacquenet Expires August 22, 2013 [Page 1]
Internet-Draft LMAP: Considerations February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Service-Specific Measurement . . . . . . . . . . . . . . . 4
2.2. Distorting Measurement Results . . . . . . . . . . . . . . 5
2.3. On the Impact of Policies . . . . . . . . . . . . . . . . . 5
2.4. Classes of Service . . . . . . . . . . . . . . . . . . . . 5
2.5. Pending Questions . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Boucadair & Jacquenet Expires August 22, 2013 [Page 2]
Internet-Draft LMAP: Considerations February 2013
1. Introduction
Service Assurance & Fulfilment is a critical component in the service
management environment. Within ISP organizations, dedicated
organizational and functional structures are implemented to
efficiently monitor and assess the overall quality of deployed
services and also the service quality as perceived by end-users.
As such, appropriate actions can be taken to solve encountered
problems and put any disrupted service back to normal operation.
Various tools (e.g., probes, reporting tools, etc.) are deployed to
continuously provide feedback on the status of running services and
notify managers about operational issues.
For the sake of efficient day-to-day operations, an ISP should
implement the Service Fulfilment functions that are responsible for
checking if the services delivered to the users are consistent with
what has been subscribed and possibly negotiated. These functions
may also be used as inputs to Service Assurance related functions.
The ISP should be able to continuously (preferably in real-time)
measure and control the level of quality associated to the services
delivered to its customers. Indeed, network anomalies such as node
outage, link failures, routing disruption and the subsequent overall
service performance degradation should be dynamically reported to
appropriate management structures (like a Network Operations Center).
Ideally, any issue should be solved (or at least detected and handled
as quick as possible) before receiving the complaints from customers.
Improvement of current practices should be investigated to enhance
the quality of experience as perceived by end-users and also to speed
up repair processes whenever a network or service anomaly is
detected.
Within this context, the introduction of a high level of automation
in the global service delivery and operation chains is promising.
This does not mean zero-fault networking: automation is rather meant
to optimize communication between the different actors of the service
delivery chain and also to guarantee the overall consistency between
the different management tools.
Customers should have the ability to check the fulfilment of the
Connectivity Provisioning Profile (CPP,
[I-D.boucadair-connectivity-provisioning-profile]) they have
subscribed to (and possibly negotiated with the service provider).
They could thus evaluate how the Service Provider has delivered the
service as a function of what has been defined in the service
agreement. Customer- or service-specific indicators and related
Boucadair & Jacquenet Expires August 22, 2013 [Page 3]
Internet-Draft LMAP: Considerations February 2013
performance metrics should be accessed by customers so that they can
appreciate the level of quality associated to the services they have
subscribed to. These data should be updated on a regular basis to
adequately reflect the actual status of any service. These
indicators (including a combination thereof) should be described and
listed in the agreement (see Section 2.13 of
[I-D.boucadair-connectivity-provisioning-profile]).
The Large scale Measurement of Access network Performance (LMAP)
effort can be defined as a tool supported by the Service Assurance
functional block provided to customers to assess whether the services
they have subscribed comply with what has been defined in the service
level agreement (including the technical parameters exposed in a CPP
template, for example).
As discussed in [I-D.boucadair-connectivity-provisioning-profile],
performance metrics are not the only relevant indicators to
characterize the connectivity service delivered to the customer;
other important technical clauses (e.g., reachability scope, traffic
conformance, availability, etc.) need also to be taken into account.
Providing customers with tools that can help them better characterize
the level of quality associated to the delivery of any service (or a
combination thereof) they have subscribed to is likely to enhance
their overall quality of experience. As a consequence, such tools
would also optimize the overall efficiency of service operation
(e.g., by reducing the number of calls placed to online support
whenever a problem is pro-actively reported to the customer).
This document discusses several questions to be considered when
designing such tools.
This document makes use of the terms defined in
[I-D.morton-ippm-lmap-path].
2. Discussion
2.1. Service-Specific Measurement
Various service offerings (e.g., IPTV, VoD, Internet, VoIP, etc.) can
be delivered to the same customer. All these services rely upon
devices that are involved the forwarding of the corresponding
service-specific traffic.
These services are not restricted to the basic IP connectivity
service but also include advanced features. The technical clauses
that document the IP connectivity service component of these services
Boucadair & Jacquenet Expires August 22, 2013 [Page 4]
Internet-Draft LMAP: Considerations February 2013
may vary one from the other (e.g., a global reachability can be
provided for the Internet service while IP connectivity service is
restricted to the first SBE/DBE (Session Border Element/Data Border
Element) for VoIP services.
Furthermore, some of these services may be delivered over dedicated
"virtual" channels (e.g., distinct VCs or addresses can be used for
each service).
Assessing whether the delivered service complies with what has been
subscribed by the customer or not suggests that measurement actions
should be specific to the communication facilities (forwarding paths,
virtual channels, tunnels, etc.) used to deliver the service to the
customer.
2.2. Distorting Measurement Results
Some services may rely on several components provided by distinct
administrative entities. For instance, the DNS service may not be
provided by the same operator that provides the IP connectivity. The
level of quality associated to the delivery of a service may
therefore be affected (e.g., because DNS resolution takes longer than
expected) even if traffic performance clauses are honored by the
network provider.
The LMAP system should be designed to accommodate such deployment
scenario.
2.3. On the Impact of Policies
Issues can be experienced when a customer tries to reach a subset of
destinations. These issues may not be necessarily due to performance
degradation in the local network but to some policies enforced in the
destination networks, at the risk of being unable to deliver the
service to some networks (e.g., some government contents cannot be
accessed from some networks, because of a security policy enforced by
the government).
The measurement system should be designed to accommodate such
contexts.
2.4. Classes of Service
Prioritization is used to deliver some services; as such,
measurements should be bound to the QoS class used for a given
service.
In some networks, DSCP marking inheritance mechanisms are used to
Boucadair & Jacquenet Expires August 22, 2013 [Page 5]
Internet-Draft LMAP: Considerations February 2013
make sure customers cannot injects traffic that belongs to an
unauthorized or unsupported class of service. The proposed
measurement framework should be designed to handle such designs.
2.5. Pending Questions
Additional considerations should be taken into account as per the
following questions:
Q1: How to determine the measurement scope? How to characterize a
measurement scope?
Q2: Should inter-domain measurement be in the scope?
Q3: If so, which inter-domain paths should be used to conduct
measurement campaigns? Paths used for measurement may not be
those used to forward service data.
Q4: Which metrics to use? How contributing agents negotiate the
metric to be used? What measurement methodology (e.g.,
frequency of measurement requests)? What methodology to
aggregate results? What approach to follow if a metric is not
returned from a given network segment? How to accommodate the
use of metrics that may not be supported by all devices along
the whole forwarding path?
Q5: How measurement and testing methodology are shared between
involved parties (e.g., between two service providers)? Should
respective responsibilities be negotiated?
Q6: How to ensure time synchronization?
Q7: How can a measurement system dynamically discover the measuring
entities of a single domain? Across several domains?
Q8: How to detect a network is LMAP-compliant? How to configure a
LMAP client with LMAP server information?
Q9: How to guarantee the accuracy of collected data?
Q10: How to control access to measurement results? How to prevent
revealing measurement results to external parties?
Q11: How to map collected data with technical clauses included in a
contract/agreement (e.g., CPP)?
Q12: Flash crowd issues: to what extent measurement traffic can
impact the delivered service during a crisis (e.g., an overload
situation in some regions of the LMAP domain, where a LMAP
domain is an administrative entity that is composed of LMAP-
capable nodes operated by a single structure)?
Q13: How to make sure that the entities involved in measurement do
not dramatically affect the accuracy of the measurement (as per
Heisenberg principle)? Which procedure to apply to control the
reliability of LMAP agents?
Q14: How to make sure measurement data is not impacted by the home
network itself or the machine embedding the measurement agent?
Boucadair & Jacquenet Expires August 22, 2013 [Page 6]
Internet-Draft LMAP: Considerations February 2013
Q15: How can a network provider instruct a LMAP agent to hold its
requests to prevent network congestion situations (e.g., to
avoid link overload)?
Q16: How to make sure measurement data accurately reflect the
network performance and not the policies enforced in that
network?
Q17: The LMAP system can be used to assess the level of delivered
connectivity service to customers? The system can be embedded
in robots enabled in the access segment to emulate the behavior
of connected device. How LMAP can accommodate such deployment
use case?
Q18: To what extent conducting a set of measurement actions at T0
will reelect the actual traffic performance to be experienced
when invoking the subscribed service?
Q19: How path diversity impacts measurements?
Q20: How the system is designed to ensure topology hiding?
3. Security Considerations
TBC.
4. IANA Considerations
This document does not require any action from IANA.
5. Acknowledgments
TBC.
6. Informative References
[I-D.boucadair-connectivity-provisioning-profile]
Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS
Connectivity Provisioning Profile",
draft-boucadair-connectivity-provisioning-profile-02 (work
in progress), September 2012.
[I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-00 (work in progress),
January 2013.
Boucadair & Jacquenet Expires August 22, 2013 [Page 7]
Internet-Draft LMAP: Considerations February 2013
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes, 35000
France
Email: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires August 22, 2013 [Page 8]
