Internet DRAFT - draft-fan-ipfix-content-info-req
draft-fan-ipfix-content-info-req
Network Working Group P. Fan
Internet-Draft China Mobile
Intended status: Informational July 29, 2013
Expires: January 30, 2014
Requirements for Application Layer Information Export in IP Flow
Information Export (IPFIX)
draft-fan-ipfix-content-info-req-01
Abstract
This document specifies requirements for exporting application layer
information using IPFIX.
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 January 30, 2014.
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.
Fan Expires January 30, 2014 [Page 1]
Internet-Draft Application Layer Information Requirements July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Current Related Information Elements . . . . . . . . . . . . 3
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Internet Content Introducing in Data Centers . . . . . . 3
4.2. Web Site Performance Monitoring . . . . . . . . . . . . . 4
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Internet Content Introducing in Data Centers . . . . . . 5
5.2. Web Site Performance Monitoring . . . . . . . . . . . . . 5
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Our internet today carries a large variety of applications and
services. Apart from layer 3 and layer 4 flow information, network
administrators constantly rely on information in higher layers to
monitor traffic flows. This kind of application related information
is used in many aspects, e.g. network planning, operation,
monitoring, analyzing, etc.
The IPFIX protocol provides us with ways to give network
administrators flow information. A series of standards have been
defined by IPFIX WG, including requirements [RFC3917], architecture
[RFC5470], protocol specification [I-D.ietf-ipfix-protocol-
rfc5101bis], and information model [I-D.ietf-ipfix-information-model-
rfc5102bis]. IPFIX already provides Information Elements for every
common Layer 4 and Layer 3 packet header field in the IETF protocol
suite, basic Layer 2 information, basic counters, timestamps and time
ranges, and so on, according to [I-D.draft-ietf-ipfix-ie-doctors].
However, application layer information export is not yet well
standardized. Granular, well-defined information models that can be
used in a universal, interoperable way to gather application layer
information have not been specified.
This memo describes requirements for exporting application layer
information of traffic flows, and intends to update [RFC3917].
Fan Expires January 30, 2014 [Page 2]
Internet-Draft Application Layer Information Requirements July 2013
2. Scope
The document describes requirements for exporting application layer
information. By "application layer" we are actually referring to
layers above the transport layer, and do not precisely classify a
protocol into layer 5, 6 or 7.
The requirements and scenarios in this documents are based on
practical needs. Flow monitoring and information export is done
globally and statistically without specific targets, and must avoid
violating RFC2804 regarding IETF policy on wiretapping.
3. Current Related Information Elements
There are a number of previously defined coarse-grained information
elements that can be used or referred to when dealing with
application layer information.
Application IEs: [RFC6759] defines a set of information elements
used for export application information, including
applicationDescription, applicationId, applicationName,
classificationEngineId, applicationCategoryName,
applicationSubCategoryName, applicationGroupName, etc.
Applications in [RFC6759] are defined as networking protocols (can
be layer 2 to layer 7) used by networking processes that exchange
packets between them. These information elements give overall
information of what applications are running on our network.
Packet Section IEs We have already several information elements that
carry a series of octets in a packet/frame, e.g.
ipHeaderPacketSection, ipPayloadPacketSection,
mplsLabelStackSection, mplsPayloadPacketSection, etc. These
information elements can even report octets from payload, subject
to RFC2804. Note that the octets these information elements
report start from the beginning of the measured packet/frame, but
application layer information we talk about in this document is
likely to locate in any (even not fixed) place of a packet, and
may not always locate in every packet.
4. Use cases
4.1. Internet Content Introducing in Data Centers
The Internet is operated by a number of ISPs (Internet Service
Providers) and ICPs (Internet Content Providers). ISPs provide
internet access service to subscribers and ICPs provide content. If
internet content resources (web sites, service platforms, etc.)
subscribers want to visit locate inside an ISP's network, then the
Fan Expires January 30, 2014 [Page 3]
Internet-Draft Application Layer Information Requirements July 2013
internet surfing traffic generated by subscribers will be restricted
within the network; if resources are outside the network, then the
traffic will be routed out of the network to the ICPs. For ISPs with
little internet content resources, a large amount of internet traffic
goes to other providers' networks, leading to
1. Pressure on the interconnecting links if bandwidth is limited;
2. User experience degradation when congestion occurs;
3. Interconnection fees if the ISP has to pay for the transit
traffic.
The solution is to bring the content of ICPs into the ISP's own
networks. Normally web sites are introduced and placed inside the
data centers of an ISP, then the relevant internet traffic generated
by subscribers will not go out of the network.
4.2. Web Site Performance Monitoring
Network administrators conduct the monitoring to evaluate the
performance of web sites and user experience of internet access. A
common way is to deploy probes at selected locations in the network
and generate actively measurement traffic to visit web sites to be
monitored. Some of the metrics and information needed include
For each web page element:
1. Durations, including DNS lookup, TCP connection, request
sending, waiting, response receiving, TTFB (Time To First
Byte), etc.;
2. Success rate of downloading the elements;
3. Bytes sent and received by the browser in HTTP messages;
4. Specific information, e.g. method, content type, URL,
referrer, etc.
For web page:
1. Web page loading duration;
2. Number of elements, DNS lookups, TCP connections;
3. Total bytes sent and received;
Fan Expires January 30, 2014 [Page 4]
Internet-Draft Application Layer Information Requirements July 2013
5. Problem Statement
5.1. Internet Content Introducing in Data Centers
The internet traffic is booming very fast these years, but usually
the speed of building a new IDC is much slower. Thus for ISPs with
limited IDC resources and urgent ICP introducing needs, it has to be
considered carefully which web sites and which domain names (or
hosts) of a web site should be introduced first. The basic principle
is to give high priority to those "hot spots" which absorb more
traffic, and the first thing to do is getting a list of hot spots.
With IPFIX today's routers on the interconnecting links can give
network administrators a top-N list of outside IP addresses,
indicating the destinations with the most traffic destined to them.
But knowing the IP address is not enough, because:
1. The entity the IP address belongs to is not known;
2. Even if we can find out the owner of the IP address, the user of
the IP address may be someone else, e.g. an ISP has an IP address
of 1.2.3.4 and allocates it to a server of www.abc.com inside its
IDC;
3. IP address of a web site is subject to change; and
4. Most importantly, it is just not the routine to use IP addresses
to go for negotiation. Marketing people negotiate with ICPs over
the domain names (hosts) to be brought into the network, e.g.
picture.abc.com & news.abc.com are of high priority while
finance.abc.com & www.example.net are not so urgent.
5.2. Web Site Performance Monitoring
The current probe approach is an active way to do the monitoring,
generating test traffic to the target web sites and measuring
information. The performance monitoring procedure is done locally on
probes, and a third-party platform that manages the probes is used to
provide data integration and presentation. Export and storage of the
results are done by vendors in proprietary ways, without standard
definitions. Probes and platforms can not work in an interoperable
way, and network administrators have to rely on third-party platforms
to get test result data, with no means to achieve data records via
the centralized NMS (Network Management System).
Another approach is to do passive monitoring on routers, though in
this case some metrics will not be measured. This approach can be
carried out at any or all locations of a network covering all
Fan Expires January 30, 2014 [Page 5]
Internet-Draft Application Layer Information Requirements July 2013
traffic, which is directly generated by users. Similar as the active
approach, there is no standard way for IPFIX to export information
needed for web site performance monitoring.
6. Requirements
This section describes requirements for exporting application
information.
1. With IPFIX extended, information in protocols above transport
layer is required to be exported based on needs.
2. The Metering Process should be able to parse certain fields in
application protocols to get and export information needed.
3. The Metering Process should be able to do counting and timing for
application protocols to be measured.
7. Security Considerations
TBD.
8. IANA Considerations
This memo includes no request to IANA.
9. Normative References
[I-D.draft-ietf-ipfix-ie-doctors]
Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IPFIX Information Elements", draft-ietf-
ipfix-ie-doctors-07 (Work in Progress), October 2012.
[I-D.ietf-ipfix-information-model-rfc5102bis]
Claise, B. and B. Trammell, "Information Model for IP Flow
Information eXport (IPFIX)", draft-ietf-ipfix-information-
model-rfc5102bis-10 (Work in Progress), February 2013.
[I-D.ietf-ipfix-protocol-rfc5101bis]
Claise, B., Trammell, B., Aitken, P., Bryant, S., Leinen,
S., and T. Dietz, "Specification of the IP Flow
Information eXport (IPFIX) Protocol for the Exchange of
Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-08
(Work in Progress), June 2013.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)", RFC
3917, October 2004.
Fan Expires January 30, 2014 [Page 6]
Internet-Draft Application Layer Information Requirements July 2013
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
March 2009.
[RFC6957] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems
Export of Application Information in IP Flow Information
Export (IPFIX)", RFC 6957, November 2012.
Author's Address
Peng Fan
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing 100053
P.R. China
Email: fanpeng@chinamobile.com
Fan Expires January 30, 2014 [Page 7]
