The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband devices such as home and enterprise edge routers, personal computers, mobile devices, etc..., whether wired or wireless. Measuring portions of the Internet on a large scale is vital for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the same measurements for a large number of points on the Internet, and to have the results collected and stored in the same form. Practically, the LMAP working group is chartered to determine the form of data models and select/extend one or more protocols for the secure communications from a Controller to instruct Measurement Agent what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, and then for a Measurement Agent to report the results to the Collector. Data models should be extensible for new and additional measurements. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing MAs may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. In the initial chartering phase, there is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home hub, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. At a high level, LMAP systems are agnostic to the measurements and results, and extensible to incorporate evolution in the measurement area, but the details such as the data models must be standardized to match the measurements. LMAP will, where possible, adopt the performance metrics of the IPPM WG, And bring any required new performance metrics to the IPPM WG for standardization. The use case where an end user can independently perform network diagnostic measurements (beyond their private network) is not directly in scope, recognizing that users have many opportunities to do this today. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter, although a bootstrapping process may be described and conducted in many ways, such as configuration during manufacture or with a local USB interface. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be combined with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process is outside the scope of work. However, the working group may design simple technical protection methods. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. LMAP will consider re-use of existing protocols and data model languages in its efforts to produce the following work items: 1. The LMAP Framework - provides common terminology and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). The WG will decide later whether protocols and data models (for Control, respectively Report) will be defined in one or separated documents.