idnits 2.17.00 (12 Aug 2021) /tmp/idnits25563/draft-fan-ipfix-content-info-req-01.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 29, 2013) is 3218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6759' is mentioned on line 114, but not defined == Unused Reference: 'I-D.ietf-ipfix-information-model-rfc5102bis' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipfix-protocol-rfc5101bis' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'RFC6957' is defined on line 287, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipfix-ie-doctors has been published as RFC 7013 == Outdated reference: draft-ietf-ipfix-information-model-rfc5102bis has been published as RFC 7012 == Outdated reference: draft-ietf-ipfix-protocol-rfc5101bis has been published as RFC 7011 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Fan 3 Internet-Draft China Mobile 4 Intended status: Informational July 29, 2013 5 Expires: January 30, 2014 7 Requirements for Application Layer Information Export in IP Flow 8 Information Export (IPFIX) 9 draft-fan-ipfix-content-info-req-01 11 Abstract 13 This document specifies requirements for exporting application layer 14 information using IPFIX. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 30, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Current Related Information Elements . . . . . . . . . . . . 3 53 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. Internet Content Introducing in Data Centers . . . . . . 3 55 4.2. Web Site Performance Monitoring . . . . . . . . . . . . . 4 56 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Internet Content Introducing in Data Centers . . . . . . 5 58 5.2. Web Site Performance Monitoring . . . . . . . . . . . . . 5 59 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Our internet today carries a large variety of applications and 68 services. Apart from layer 3 and layer 4 flow information, network 69 administrators constantly rely on information in higher layers to 70 monitor traffic flows. This kind of application related information 71 is used in many aspects, e.g. network planning, operation, 72 monitoring, analyzing, etc. 74 The IPFIX protocol provides us with ways to give network 75 administrators flow information. A series of standards have been 76 defined by IPFIX WG, including requirements [RFC3917], architecture 77 [RFC5470], protocol specification [I-D.ietf-ipfix-protocol- 78 rfc5101bis], and information model [I-D.ietf-ipfix-information-model- 79 rfc5102bis]. IPFIX already provides Information Elements for every 80 common Layer 4 and Layer 3 packet header field in the IETF protocol 81 suite, basic Layer 2 information, basic counters, timestamps and time 82 ranges, and so on, according to [I-D.draft-ietf-ipfix-ie-doctors]. 83 However, application layer information export is not yet well 84 standardized. Granular, well-defined information models that can be 85 used in a universal, interoperable way to gather application layer 86 information have not been specified. 88 This memo describes requirements for exporting application layer 89 information of traffic flows, and intends to update [RFC3917]. 91 2. Scope 93 The document describes requirements for exporting application layer 94 information. By "application layer" we are actually referring to 95 layers above the transport layer, and do not precisely classify a 96 protocol into layer 5, 6 or 7. 98 The requirements and scenarios in this documents are based on 99 practical needs. Flow monitoring and information export is done 100 globally and statistically without specific targets, and must avoid 101 violating RFC2804 regarding IETF policy on wiretapping. 103 3. Current Related Information Elements 105 There are a number of previously defined coarse-grained information 106 elements that can be used or referred to when dealing with 107 application layer information. 109 Application IEs: [RFC6759] defines a set of information elements 110 used for export application information, including 111 applicationDescription, applicationId, applicationName, 112 classificationEngineId, applicationCategoryName, 113 applicationSubCategoryName, applicationGroupName, etc. 114 Applications in [RFC6759] are defined as networking protocols (can 115 be layer 2 to layer 7) used by networking processes that exchange 116 packets between them. These information elements give overall 117 information of what applications are running on our network. 119 Packet Section IEs We have already several information elements that 120 carry a series of octets in a packet/frame, e.g. 121 ipHeaderPacketSection, ipPayloadPacketSection, 122 mplsLabelStackSection, mplsPayloadPacketSection, etc. These 123 information elements can even report octets from payload, subject 124 to RFC2804. Note that the octets these information elements 125 report start from the beginning of the measured packet/frame, but 126 application layer information we talk about in this document is 127 likely to locate in any (even not fixed) place of a packet, and 128 may not always locate in every packet. 130 4. Use cases 132 4.1. Internet Content Introducing in Data Centers 134 The Internet is operated by a number of ISPs (Internet Service 135 Providers) and ICPs (Internet Content Providers). ISPs provide 136 internet access service to subscribers and ICPs provide content. If 137 internet content resources (web sites, service platforms, etc.) 138 subscribers want to visit locate inside an ISP's network, then the 139 internet surfing traffic generated by subscribers will be restricted 140 within the network; if resources are outside the network, then the 141 traffic will be routed out of the network to the ICPs. For ISPs with 142 little internet content resources, a large amount of internet traffic 143 goes to other providers' networks, leading to 145 1. Pressure on the interconnecting links if bandwidth is limited; 147 2. User experience degradation when congestion occurs; 149 3. Interconnection fees if the ISP has to pay for the transit 150 traffic. 152 The solution is to bring the content of ICPs into the ISP's own 153 networks. Normally web sites are introduced and placed inside the 154 data centers of an ISP, then the relevant internet traffic generated 155 by subscribers will not go out of the network. 157 4.2. Web Site Performance Monitoring 159 Network administrators conduct the monitoring to evaluate the 160 performance of web sites and user experience of internet access. A 161 common way is to deploy probes at selected locations in the network 162 and generate actively measurement traffic to visit web sites to be 163 monitored. Some of the metrics and information needed include 165 For each web page element: 167 1. Durations, including DNS lookup, TCP connection, request 168 sending, waiting, response receiving, TTFB (Time To First 169 Byte), etc.; 171 2. Success rate of downloading the elements; 173 3. Bytes sent and received by the browser in HTTP messages; 175 4. Specific information, e.g. method, content type, URL, 176 referrer, etc. 178 For web page: 180 1. Web page loading duration; 182 2. Number of elements, DNS lookups, TCP connections; 184 3. Total bytes sent and received; 186 5. Problem Statement 188 5.1. Internet Content Introducing in Data Centers 190 The internet traffic is booming very fast these years, but usually 191 the speed of building a new IDC is much slower. Thus for ISPs with 192 limited IDC resources and urgent ICP introducing needs, it has to be 193 considered carefully which web sites and which domain names (or 194 hosts) of a web site should be introduced first. The basic principle 195 is to give high priority to those "hot spots" which absorb more 196 traffic, and the first thing to do is getting a list of hot spots. 198 With IPFIX today's routers on the interconnecting links can give 199 network administrators a top-N list of outside IP addresses, 200 indicating the destinations with the most traffic destined to them. 201 But knowing the IP address is not enough, because: 203 1. The entity the IP address belongs to is not known; 205 2. Even if we can find out the owner of the IP address, the user of 206 the IP address may be someone else, e.g. an ISP has an IP address 207 of 1.2.3.4 and allocates it to a server of www.abc.com inside its 208 IDC; 210 3. IP address of a web site is subject to change; and 212 4. Most importantly, it is just not the routine to use IP addresses 213 to go for negotiation. Marketing people negotiate with ICPs over 214 the domain names (hosts) to be brought into the network, e.g. 215 picture.abc.com & news.abc.com are of high priority while 216 finance.abc.com & www.example.net are not so urgent. 218 5.2. Web Site Performance Monitoring 220 The current probe approach is an active way to do the monitoring, 221 generating test traffic to the target web sites and measuring 222 information. The performance monitoring procedure is done locally on 223 probes, and a third-party platform that manages the probes is used to 224 provide data integration and presentation. Export and storage of the 225 results are done by vendors in proprietary ways, without standard 226 definitions. Probes and platforms can not work in an interoperable 227 way, and network administrators have to rely on third-party platforms 228 to get test result data, with no means to achieve data records via 229 the centralized NMS (Network Management System). 231 Another approach is to do passive monitoring on routers, though in 232 this case some metrics will not be measured. This approach can be 233 carried out at any or all locations of a network covering all 234 traffic, which is directly generated by users. Similar as the active 235 approach, there is no standard way for IPFIX to export information 236 needed for web site performance monitoring. 238 6. Requirements 240 This section describes requirements for exporting application 241 information. 243 1. With IPFIX extended, information in protocols above transport 244 layer is required to be exported based on needs. 246 2. The Metering Process should be able to parse certain fields in 247 application protocols to get and export information needed. 249 3. The Metering Process should be able to do counting and timing for 250 application protocols to be measured. 252 7. Security Considerations 254 TBD. 256 8. IANA Considerations 258 This memo includes no request to IANA. 260 9. Normative References 262 [I-D.draft-ietf-ipfix-ie-doctors] 263 Trammell, B. and B. Claise, "Guidelines for Authors and 264 Reviewers of IPFIX Information Elements", draft-ietf- 265 ipfix-ie-doctors-07 (Work in Progress), October 2012. 267 [I-D.ietf-ipfix-information-model-rfc5102bis] 268 Claise, B. and B. Trammell, "Information Model for IP Flow 269 Information eXport (IPFIX)", draft-ietf-ipfix-information- 270 model-rfc5102bis-10 (Work in Progress), February 2013. 272 [I-D.ietf-ipfix-protocol-rfc5101bis] 273 Claise, B., Trammell, B., Aitken, P., Bryant, S., Leinen, 274 S., and T. Dietz, "Specification of the IP Flow 275 Information eXport (IPFIX) Protocol for the Exchange of 276 Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-08 277 (Work in Progress), June 2013. 279 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 280 "Requirements for IP Flow Information Export (IPFIX)", RFC 281 3917, October 2004. 283 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 284 "Architecture for IP Flow Information Export", RFC 5470, 285 March 2009. 287 [RFC6957] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 288 Export of Application Information in IP Flow Information 289 Export (IPFIX)", RFC 6957, November 2012. 291 Author's Address 293 Peng Fan 294 China Mobile 295 32 Xuanwumen West Street, Xicheng District 296 Beijing 100053 297 P.R. China 299 Email: fanpeng@chinamobile.com