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]