Internet DRAFT - draft-starkcarey-lmap-protocol-criteria
draft-starkcarey-lmap-protocol-criteria
Large-Scale Measurement of Broadband Performance B. Stark
Internet-Draft AT&T
Intended status: Informational T. Carey
Expires: September 2, 2015 Alcatel-Lucent
March 1, 2015
LMAP Protocol Selection Criteria
draft-starkcarey-lmap-protocol-criteria-01
Abstract
This draft identifies criteria to be used by the LMAP WG in
evaluating and selecting Control and Reporting Protocols described by
[I-D.ietf-lmap-framework] and identified as WG deliverables in the
LMAP charter. It is not intended for use for any other purpose or by
any other party. This draft will not be maintained after LMAP
completes its selection of these protocols. The authors of this
draft do not intend to ask for working group adoption or formal
publication by IETF.
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 September 2, 2015.
Copyright Notice
Copyright (c) 2015 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
Stark & Carey Expires September 2, 2015 [Page 1]
Internet-Draft LMAP Protocol Selection Criteria March 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Control Protocol Criteria . . . . . . . . . . . . . . . . . . 2
2.1. Mandatory Criteria . . . . . . . . . . . . . . . . . . . 2
2.2. Comparative Criteria . . . . . . . . . . . . . . . . . . 3
3. Report Protocol Criteria . . . . . . . . . . . . . . . . . . 4
3.1. Mandatory Criteria . . . . . . . . . . . . . . . . . . . 4
3.2. Comparative Criteria . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This draft identifies criteria to be used in evaluating and selecting
Control and Reporting Protocols described by
[I-D.ietf-lmap-framework]. Both mandatory and comparative criteria
are identified for these protocols.
2. Control Protocol Criteria
2.1. Mandatory Criteria
Following is a list of criteria that a Control Protocol is required
to support. Protocols that do not support these criteria will not be
considered appropriate for selection by LMAP WG as a Control
Protocol. Although it is mandatory that the described mechanisms
have been defined for a protocol (in order for the protocol to be
considered by LMAP as a candidate Control Protocol), the mechanisms
do not need to be mandatory to implement per the protocol
specification.
CP-MUST-1 There must be a mechanism that allows a Controller to
cause a session to be established with a MA. Identify
this mechanism and where it is defined.
CP-MUST-2 There must be a mechanism that allows a MA to cause a
session to be established with a Controller. Identify
this mechanism and where it is defined.
Stark & Carey Expires September 2, 2015 [Page 2]
Internet-Draft LMAP Protocol Selection Criteria March 2015
CP-MUST-3 The protocol session must be capable of being secured
using secure credentials, as described in
[I-D.ietf-lmap-framework]. The security mechanism must be
useful for privacy protection, man-in-the-middle defense,
and protection against replay. Identify this mechanism
and where it is defined.
CP-MUST-4 The protocol must be versionable. Identify the process
for extending the protocol.
2.2. Comparative Criteria
Following is a list of criteria that can be used to differentiate
among Control Protocol candidates. For each criterion, it is also
indicated what is considered "better" for a candidate protocol to
support.
CP-DIFF-1 How many exchanges are required to send a complete
instruction set? (less is better)
CP-DIFF-2 How many exchanges are required to send a status update?
(less is better)
CP-DIFF-3 Is it possible to provide partial updates? (yes is
better)
CP-DIFF-4 Are there any special mechanisms (other than STUN/TURN/
ICE or using port forwarding pinholes, PCP, UPnP IGD,
etc.) for NAT/firewall traversal? (if subsequent
evaluation of such a mechanism suggests it is useful and
usable, yes is better)
CP-DIFF-5 How many bytes of overhead (rough estimate or brief
description of the source of overhead is acceptable) are
required to send a complete instruction set? (less is
better)
CP-DIFF-6 How many bytes of overhead (rough estimate or brief
description of the source of overhead is acceptable) are
required to send a status update? (less is better)
CP-DIFF-7 How widely used is the protocol and/or its protocol
elements in mass market devices? (widely is better)
CP-DIFF-8 What mechanisms exist to ensure interoperability of MA
and Controller implementations (e.g., test tools,
plugfests, certification programs, test plan or scripts,
Stark & Carey Expires September 2, 2015 [Page 3]
Internet-Draft LMAP Protocol Selection Criteria March 2015
reference implementations to test against)? (existence of
something is better)
CP-DIFF-9 Are the components of the protocol available as open
source? (yes is better)
CP-DIFF-10 What ecosystem of tools exists for developers
implementing the protocol (e.g., compilers, tutorials,
sample and open source implementations; include tools for
data model creation)? (existence of useful tools is
better)
CP-DIFF-11 Is the protocol versionable? (yes is better, or is this
mandatory?)
CP-DIFF-12 If yes, what is the process for extending the protocol?
(for information)
CP-DIFF-13 What are the encodings supported by the protocol (SOAP,
JSON, XML, etc.)? (simple is better; lower overhead is
better; other aspects still to be determined and
discussed may be better)
3. Report Protocol Criteria
3.1. Mandatory Criteria
Following is a list of criteria that a Report Protocol is required to
support. Protocols that do not support these criteria will not be
considered appropriate for selection by LMAP WG as a Report Protocol.
Although it is mandatory that the described mechanisms have been
defined for a protocol (in order for the protocol to be considered by
LMAP as a candidate Report Protocol), the mechanisms do not need to
be mandatory to implement per the protocol specification.
RP-MUST-1 There must be a mechanism that allows a MA to cause a
session to be established with a Collector. Identify this
mechanism and where it is defined.
RP-MUST-2 The protocol session must be capable of being secured
using secure credentials, as described in
[I-D.ietf-lmap-framework]. The security mechanism must be
useful for privacy protection, man-in-the-middle defense,
and protection against replay. Identify this mechanism
and where it is defined.
RP-MUST-3 The protocol must be versionable. Identify the process
for extending the protocol.
Stark & Carey Expires September 2, 2015 [Page 4]
Internet-Draft LMAP Protocol Selection Criteria March 2015
3.2. Comparative Criteria
Following is a list of criteria that can be used to differentiate
among Report Protocol candidates. For each criterion, it is also
indicated what is considered "better" for a candidate protocol to
support.
RP-DIFF-1 What transport protocols (TCP, UDP, other) can be used
with the protocol? (WG to decide what is better)
RP-DIFF-2 Is a congestion control mechanism supported? (yes is
better)
RP-DIFF-3 How many exchanges are required to send a report? (less
is better)
RP-DIFF-4 Does it allow for sending multiple reports in a session?
(yes is better)
RP-DIFF-5 Is there a capability for long-lived sessions. (yes is
better)
RP-DIFF-6 Is compression supported? (yes is better, or is this
mandatory?)
RP-DIFF-7 How many bytes of overhead (rough estimate or brief
description of the source of overhead is acceptable) are
required to send a report? (less is better)
RP-DIFF-8 How widely used is the protocol and/or its protocol
elements in mass market devices? (widely is better)
RP-DIFF-9 What mechanisms exist to ensure interoperability of MA
and Collector implementations (e.g., test tools,
plugfests, certification programs, test plan or scripts,
reference implementations to test against)? (existence of
something is better)
RP-DIFF-10 Are the components of the protocol available as open
source? (yes is better)
RP-DIFF-11 What ecosystem of tools exists for developers
implementing the protocol (e.g., compilers, tutorials,
sample and open source implementations; include tools for
data model creation)? (existence of useful tools is
better)
Stark & Carey Expires September 2, 2015 [Page 5]
Internet-Draft LMAP Protocol Selection Criteria March 2015
RP-DIFF-12 What are the encodings supported by the protocol (SOAP,
JSON, XML, etc.)? (simple is better; lower overhead is
better; other aspects still to be determined and
discussed may be better)
4. Acknowledgements
Members of LMAP WG, including Dan Romascanu, Joan Luciani, Phil
Eardley, and Juergen Schoenwaelder.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
Candidate Control and Report protocols are required to meet security
requirements identified in [I-D.ietf-lmap-framework].
7. 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 of Broadband Performance (LMAP)", draft-ietf-
lmap-framework-11 (work in progress), February 2015.
Authors' Addresses
Barbara Stark
AT&T
1057 Lenox Park Blvd NE
Atlanta, GA 30319
US
Phone: +1-404-499-6424
Email: bs7652@att.com
Timothy Carey
Alcatel-Lucent
TX
US
Phone: +1-972-415-2065
Email: timothy.carey@alcatel-lucent.com
Stark & Carey Expires September 2, 2015 [Page 6]
