idnits 2.17.1 draft-inacio-lmap-enterprise-use-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 30, 2013) is 3917 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 99, but not defined == Unused Reference: 'KEYWORDS' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 191, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 205, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Christopher Inacio 3 Intended Status: Informational Carnegie Mellon University 4 Expires: January 31, 2014 July 30, 2013 6 Large-Scale Broadband Measurement Enterprise Use-Case 7 draft-inacio-lmap-enterprise-use-case-00 9 Abstract 11 The Large-Scale Measurement of Broadband Performance (LMAP) working 12 group is defining mechanisms to monitor network performance of large- 13 scale networks. The use case will describe how very large enterprise 14 networks are not very different from the networks considered by other 15 LMAP use cases and that most measurements are useful to both use 16 cases. In addition this use case will state the need for the ability 17 to have finer grained observation related to User Experience 18 potentially on a per application basis. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Large Scale Enterprise Use Case . . . . . . . . . . . . . . . . 3 61 2.1 Similarities and Differences to ISPs and broadband users . . 3 62 2.2 Additions for Enterprise Measurement . . . . . . . . . . . . 4 63 2.3 The Goal for Enhanced Measurement . . . . . . . . . . . . . 4 64 3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 69 6.2 Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1 Introduction 74 The Large-Scale Measurement of Broadband Performance (LMAP) working 75 group is charged with creating a uniform Information Model in order 76 to measure large-scale network performance. In addition to the 77 Information Model, the working group is charged with creating a 78 Control Protocol and a Report Protocol with their associated data 79 models. 81 The Information Model and associated Data Models necessary for 82 monitoring and regulating Internet Service Provider (ISP) networks 83 are closely shared with the monitoring of large scale enterprise 84 networks. In large scale enterprises, with multiple campuses 85 distributed throughout countries or throughout the world, monitoring 86 campus scale network activity and cross-campus network activity is 87 closely related to monitoring ISP activity. 89 The additional considerations for this large scale enterprise 90 monitoring are the needs to be able to be able to make measurements 91 aligned to enterprise applications and services beyond simple 92 bandwidth and latency measurements. 94 1.1 Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Large Scale Enterprise Use Case 102 2.1 Similarities and Differences to ISPs and broadband users 104 Many large scale enterprises centralized critical and/or expensive 105 resources at a few select locations. For example, login directory 106 services due to their critical role in the infrastructure and 107 security needs, email and calendaring systems, and certain accounting 108 and human resource functions. In large scale multinational 109 organizations, these daily use resources may exist on a different 110 continent then portions of the user base, with complex networks 111 existing at both the remote location and where the critical resource 112 is located. 114 Users of these large scale networks have similar needs from their 115 network providers (usually an internal sub-organization) that general 116 broadband users expect from their ISP. Depending on the 117 organization, the service level agreement (SLA) may be more or less 118 strict. The users within these organizations have the same need to 119 diagnose and verify the performance provided to them as broadband 120 users. Similarly, the sub-organization (referred to as IT 121 (information technology) for the rest of this document) has the same 122 need to test, measure, diagnose, and repair the network as a 123 broadband ISP. 125 The difference between the enterprise users and typical broadband 126 users is their requirement for special SLAs for certain critical 127 resources within their global corporate network. Certain operations 128 within the corporate network, when performing poorly at the global 129 level, may have a disproportionate impact on the users experience 130 when those SLAs are violated. The second issue is that often the IT 131 component within an enterprise is responsible for both application 132 performance and network performance. 134 2.2 Additions for Enterprise Measurement 136 Many large enterprises with geographically distributed resources 137 partition their network monitoring related to geographic sub-units of 138 the enterprise. The lack of uniform measurement and models means 139 that problems that occur across sites are often not solved without 140 significant user pressure. 142 The additional metrics necessary include the ability to distinguish 143 application specific traffic flows in a passive manner and report on 144 the performance end-to-end. Combining this data with typical network 145 performance data, nominally: bandwidth, latency, routing, etc. allows 146 a fine grained view of network activity and resource utilization. 148 2.3 The Goal for Enhanced Measurement 150 The goal of being able to measure the network in holistic ways that 151 can be related to application experience is to answer the age old 152 question: Is it the network or the application? By adding the 153 ability to optionally measure in ways associated to application 154 specific traffic, determining network impact to user experience will 155 be possible. 157 3 Requirements 159 * Passive monitoring of application related network measurements. 161 * Non-averaged recording of application network data. 163 * Ability to correlate application related network measurements to 164 non-application related network measurements. 166 * Ability to track, at possibly per-packet activity level, 167 performance measurements of specific flows, possibly sampled 169 * Ideally, a way for applications to announce themselves to the 170 network for passive measurement. 172 * Simple uniform methods (common ports, DPI) to inspect traffic to 173 associate the traffic with application usage 175 4 Security Considerations 177 Security considerations are appropriate and necessary within the 178 Control Protocol and the Report Protocol. 180 5 IANA Considerations 182 None. 184 6 References 186 6.1 Normative References 188 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 192 1 1995. 194 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 195 April 1 1996. 197 6.2 Informative References 199 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 200 RFC 3514, April 1 2003. 202 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 203 Acronyms", RFC 5513, April 1 2009. 205 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 206 2009. 208 Authors' Addresses 210 Christopher Inacio 211 Carnegie Mellon University 212 5000 Forbes Ave., 213 Pittsburgh, PA 15213 215 EMail: inacio@andrew.cmu.edu