home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rtfm-new-traffic-flow-00.txt < prev    next >
Text File  |  1996-11-26  |  18KB  |  511 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Real Time Flow Measurement Working Group        S.W. Handelman
  8. Internet-draft                                  IBM
  9. Expire in six months                            Hawthorne, NY USA
  10.  
  11.                                                 N. Brownlee
  12.                                                 U of Auckland, NZ
  13.  
  14.                                                 Greg Ruth
  15.                                                 GTE Laboratories, Inc
  16.                                                 Waltham, MA USA
  17.  
  18.  
  19.                                                 November, 1996
  20.  
  21.  
  22.  
  23. Real Time Flow Measurement Working Group - New Attributes for 
  24.                     Traffic Flow Measurement
  25.  
  26.            <draft-ietf-rtfm-new-traffic-flow-00.txt>
  27.  
  28.  
  29. 1. Status of this Memo
  30.  
  31.    This document is an Internet Draft.  Internet Drafts are working
  32.    documents of the Internet Engineering Task Force (IETF), its areas,
  33.    and its working groups.  Note that other groups may also distribute
  34.    working documents as Internet Drafts.
  35.  
  36.    Internet  Drafts  are  draft  documents  valid  for  a maximum of six
  37.    months, and may be updated, replaced, or obsoleted by other documents
  38.    at any time.  It is inappropriate to use Internet Drafts as reference
  39.    material or to cite them other than as "work in progress".
  40.  
  41.    To learn the current status of any Internet Draft, please  check  the
  42.    "1id-abstracts.txt" listing contained in the Internet Drafts shadow
  43.    directories  on  ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
  44.    munnari.oz.au  (Pacific  Rim),  ds.internic.net  (US  East Coast), or
  45.    ftp.isi.edu (US West Coast).
  46.  
  47.    This memo provides information for the Internet community.  This memo
  48.    does  not  specify an Internet standard of any kind.  Distribution of
  49.    this memo is unlimited.
  50.  
  51. 2.1 Introduction
  52.  
  53.    The Real-time Traffic Flow Measurement (RTFM) working group has
  54.    developed a rudimentary system for measuring and reporting
  55.    information about traffic flows in the Internet.  This document
  56.    explores the definition of extensions to the concepts of flow
  57.    measurements as currently defined in RFC 1272 and [1].
  58.  
  59.  
  60.  
  61. Handelman, Brownlee, Ruth                [Page 1]
  62.  
  63. Internet-Draft                        November, 1996
  64.  
  65.  
  66.    The RTFM Working Group has defined the concept of a standardized
  67.    meter which records flows from a traffic stream according to a Rule
  68.    Set that is active in the meter[1]. Implementations of this meter
  69.    have been done by Nevil Brownlee in the University of Auckland, NZ,
  70.    and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA.
  71.    The meter implementations measure flows by marking them with time
  72.    stamps, recording total traffic in bytes and packets. In general one
  73.    may say that the meter finds the existence of flows, and records the
  74.    traffic in each flow. The RTFM WG has also discussed the Collector
  75.    Program whose job is to fetch the completed group of flows active in
  76.    the Meter.
  77.  
  78. 2.1 RTFM's Definition of Flows
  79.  
  80.    The RTFM Meter architecture views a flow as a set of packets between
  81.    two end-points (as defined by their source and destination attribute
  82.    values), and as BI-DIRECTIONAL (i.e. the meter effectively monitors
  83.    two sub-flows, one in each direction).
  84.  
  85.    Reasons why RTFM flows are bi-directional:
  86.  
  87.    - We are interested in understanding the behavior of sessions between
  88.    end-points.
  89.  
  90.    - We want to perform as much data reduction as possible, so as to
  91.    reduce the amount of data to be retrieved from a remote meter.
  92.  
  93.    - The end-point attribute values (the "Address" and "Type" ones) are
  94.    the same for both directions; storing them in bi-directional flows
  95.    reduces the meter's memory demands.
  96.  
  97. 2.2 RTFM's Current Definition of Network Flows and their Attributes
  98.  
  99.    Flows, as described in the "Architecture" I-D have the following
  100.    properties:
  101.  
  102.    a. They occur between two end-points, specified as sets of attribute
  103.    values in the meter's current rule set.  A flow is completely
  104.    identified by its set of end-point attribute values.
  105.  
  106.    b. Each flow may also have values for "computed" attributes (Class
  107.    and Kind).  These are directly derived from the end-point attribute
  108.    values.
  109.  
  110.    c. A new flow comes into being when the a packet is seen which is not
  111.    classified by the Rule Set into an existing flow. The meter records
  112.    the time  when this new flow is created.
  113.  
  114.  
  115.  
  116.  
  117. Handelman, Brownlee, Ruth                [Page 2]
  118.  
  119. Internet-Draft                        November, 1996
  120.  
  121.  
  122.    d. Attribute values in (a), (b) and (c) are set when the meter sees
  123.    the first packet for the flow, and are never changed.
  124.  
  125.    e. Each flow has a "LastTime" attribute, which indicates the time the
  126.    meter last saw a packet for the flow.
  127.  
  128.    f. Each flow has two packet and byte counters, one for each flow
  129.    direction (Forward and Backward).  These are updated as packets are
  130.    observed by the meter.
  131.  
  132.    g. ALL the attributes have (more or less) the same meaning for a
  133.    variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as
  134.    TCP/IP.
  135.  
  136.    Current flow attributes as described above, fit very well into the
  137.    SNMP data model.  They are either static, or are continuously updated
  138.    counters.  They are NEVER reset.  In this document they will be
  139.    referred to as "old-style" attributes.
  140.  
  141.    It is easy to add further "old-style" attributes, since they don't
  142.    require any new features in the architecture.  For example:
  143.  
  144.    - Count of the number of "lost" packets (determined by watching
  145.    sequence number fields for packets in each direction; only available
  146.    for protocols which have sequence numbers).
  147.  
  148.    - In the future, RTFM could coordinate directly with the Flow number
  149.    from the IPv6 header.
  150.  
  151.    At the June, 1996 meeting of the RTFM WG, in Montreal, Canada, a
  152.    proposal was put forth to extend the work of the group to produce an
  153.    Internet Draft "New Attributes for Traffic Flow Measurement". That
  154.    proposal has brought forth this document. The goal of this work is to
  155.    produce a simple set of abstractions, which can be easily implemented
  156.    and at the same time enhance the value of RTFM meters. This document
  157.    also defines a method for organizing the flow abstractions to
  158.    preserve the existing RTFM flow table.
  159.  
  160.    An addition to the main architecture document of RTFM is the use of
  161.    High Watermarks, to set up Alerts when the value of a flow record
  162.    variable  exceeds a watermark, e.g. the total byte count exceeds a
  163.    preset amount, such as no user should send more than 2,000,000
  164.    packets over a certain time period.  This is a generalization of the
  165.    concept defined in RTFM to send Traps when a the Meter finds an
  166.    exception condition in its own processing (The Architecture Document
  167.    refers to running out of buffer space).
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Handelman, Brownlee, Ruth                [Page 3]
  174.  
  175. Internet-Draft                        November, 1996
  176.  
  177.  
  178. 2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows
  179.  
  180.  
  181.    The concept of flows has been studied in various different contexts.
  182.    For the purpose of extending RTFM, a starting point is the work of
  183.    the Integrated Services WG. We will measure quantities that are often
  184.    set by Integrated Services and configuration programs. We will look
  185.    at the work of the Benchmarking - Internet Provider Performance
  186.    Metrics Working Group, and also look at the work of Claffy, Braun and
  187.    Polyzos.
  188.  
  189.    An example of the use of capacity and performance information is
  190.    found in "The Use of RSVP with IETF Integrated Services".  [2].
  191.    RSVP's use of Integrated Services revolves around Token Bucket Rate,
  192.    Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum
  193.    Packet Size, and the Slack term. These are set by TSpec, ADspec and
  194.    FLowspec (Integrated Services Keywords), and are used in
  195.    configuration and operation of Integrated Services. RTFM could
  196.    monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum
  197.    Packet Size, and the Slack term. RTFM could infer details of the
  198.    Token Bucket. We will develop measures to work with these service
  199.    metrics.
  200.  
  201.    RTFM will work with several traffic measurements identified by IPPM
  202.    [3]. There are two broad areas in which RTFM is useful for IPPM.
  203.  
  204.    1) RTFM could act as a passive device that can gather traffic and
  205.    performance statistics at appropriate places in TCP/IP networks
  206.    (servers or client locations).
  207.  
  208.    2) RTFM could give detailed analyses of IPPM test flows that pass
  209.    through the Network segment that RTFM is monitoring.
  210.  
  211.    RTFM will also incorporate work from Claffy, Braun and Polyzos [4].
  212.    We can measure flow time-outs, traffic aggregation and metrics on the
  213.    application layer using methods similar to theirs.
  214.  
  215. 3. Flow Abstractions
  216.  
  217.    Extensions to the current RTFM flow attributes may be divided into
  218.    three general classes:
  219.  
  220.    o packet traces - collections of individual packets in a flow or a
  221.    segment of a flow
  222.  
  223.    o 'aggregates' - statistics derived from the flow taken as a whole
  224.    (e.g. mean rate, max packet size).
  225.  
  226.  
  227.  
  228.  
  229. Handelman, Brownlee, Ruth                [Page 4]
  230.  
  231. Internet-Draft                        November, 1996
  232.  
  233.  
  234.    o 'series'- sequences of attributes that depend on more than one
  235.    packet (e.g. inter- arrival times)
  236.  
  237.    The following sections suggest implementations for each of these
  238.    classes of extensions.
  239.  
  240.    As an introduction to flow abstractions one fact must be emphasized.
  241.    Several of the measurements enumerated below can be implemented by a
  242.    Meter Reader that is tied to the meter with instantaneous response,
  243.    and very high bandwidth.  If the Meter Reader and Meter can be
  244.    arranged in such a way, RTFM could collect Packet Traces with time
  245.    stamps, and provide them to the Meter Reader for processing by the
  246.    Meter Reader.
  247.  
  248.    A more useful alternative is to have the meter calculate some flow
  249.    statistics locally. This allows a looser coupling between the meter
  250.    and Meter Reader. RTFM will create an 'extended attribute' depending
  251.    upon settings in the Rules table of RTFM. By default, RTFM will not
  252.    create any extensions without explicit instructions in the Rules
  253.    table.
  254.  
  255.    RTFM's traditional flows can be analyzed at two levels. The first is
  256.    to analyze the Network traffic in terms of time, e.g. traffic load of
  257.    a particular flow, to be called Network Flows. These flows can be
  258.    looked at as an extension of the "old-style" flow attributes. The
  259.    second, is to derive a value from the flow, e.g. analyzing packet
  260.    sequence numbers and ACKS and estimating delay.  This second type
  261.    will be called Derived Attributes.
  262.  
  263. 3.1. Packet Traces
  264.  
  265.  
  266.    The simplest way of doing this in the meter would be to have a new
  267.    attribute called, say, "PacketTrace."  This would be a table, with a
  268.    column for each property of interest.  For example, one could have
  269.  
  270.    - Arrival time (TimeTicks from SysUptime, or microseconds from
  271.    FirstTime for the flow).
  272.  
  273.    - Direction (Forward or Backward)
  274.  
  275.    - Sequence number (for protocols with sequence numbers)
  276.  
  277.    - Flags (for TCP at least).
  278.  
  279.    To add a row to the table, we only have to have a rule which PushPkts
  280.    the PacketTrace attribute.
  281.  
  282.  
  283.  
  284.  
  285. Handelman, Brownlee, Ruth                [Page 5]
  286.  
  287. Internet-Draft                        November, 1996
  288.  
  289.  
  290.    To use this, one would write a rule set which selected out a small
  291.    number of flows of interest, and PushPkted PacketTrace for each of
  292.    them.  A MaxTraceRows default value of 2000 would be enough to allow
  293.    a Meter Reader to read 1-second ping traces every 10 minutes or so.
  294.    More realistically, a MaxTraceRows of 500 would be enough for one-
  295.    minute pings, read once each hour.
  296.  
  297. 3.2. Aggregate Attributes
  298.  
  299.  
  300.    Performance aspects of flows are useful in the case of a flow between
  301.    a server and client. RTFM could find the same data in TCP/IP and UDP
  302.    flows, and can find additional data in TCP flows. The performance
  303.    data found by this method define the flow capacity used by the
  304.    individual flow, as experienced in the locale of the RTFM meter. The
  305.    data found in this method would help  Operations Support determine
  306.    the performance of delivery in the network being measured.
  307.  
  308.    For both TCP/IP and UDP, RTFM's "old-style" flow attributes count the
  309.    bytes/packets for packets which match the rule set for an individual
  310.    flow.  In addition to these totals, RTFM could calculate Packet size
  311.    and Bit rate statistics.
  312.  
  313.    Packet size - RTFM's packet flows can be examined to determine the
  314.    maximum packet size found in a flow. This will give the Network
  315.    Operator an indication of the MTU being used in a flow. It will also
  316.    give an indication of the sensitivity to loss of a flow, for losing
  317.    large packets causes more data to be repeated.
  318.  
  319.    Bit rate  - The data could also be recorded as the maximum and
  320.    minimum data rate of the flow, found over specific time periods
  321.    during the lifetime of a flow. This measure could be used to compare
  322.    the bandwidth used by the flow with the total capacity of the media
  323.    and guarantees set for flows.
  324.  
  325. 3.3 Series Attributes
  326.  
  327.  
  328.    The notion of series attributes, is to keep simple statistics that
  329.    involve more than one packet. Methods to derive simple percentiles,
  330.    means, and other statistics can be developed for each flow. The
  331.    notation to construct such an attribute would be a command in the
  332.    rule set, instructing the meter to compute the attribute. This is
  333.    similar to the definition above of creating an aggregate attribute.
  334.  
  335.    TCP and UDP
  336.  
  337.    Inter-arrival statistics - TCP and UDP. RTFM knows the time that it
  338.  
  339.  
  340.  
  341. Handelman, Brownlee, Ruth                [Page 6]
  342.  
  343. Internet-Draft                        November, 1996
  344.  
  345.  
  346.    encounters each individual packet. Statistics can be kept to record
  347.    the inter-arrival times of the packets, which would give an
  348.    indication of the jitter found in the Flow.
  349.  
  350.    TCP Only - Data Loss - This is an area for further study. TCP packets
  351.    have byte sequence numbers and SYNS, FINS, and ACK's associated with
  352.    them. RTFM could track the sequence numbers in the flows, and
  353.    calculate the packet loss occurring in a flow, and thus we can
  354.    develop a metric of lost packets and useful traffic.
  355.  
  356.    Delay analysis -  TCP flows also could be examined for the timing
  357.    between Transmissions and ACKS and thus we can get some measure of
  358.    delay. This assumes the forward and reverse packets are both visible
  359.    to the meter.
  360.  
  361.    Subflow analysis - TCP flows, e.g. a Web server's httpd flows
  362.    actually contain many individual sub flows. Given, a well known Web
  363.    Server WW, and a  client CC, RTFM would normally pick up an
  364.    aggregation of all the flows of text, graphics, Java programs, etc.
  365.    that are sent between WW and CC. By analyzing the Sequence numbers,
  366.    RTFM could estimate when each subflow occurs, and thus maintain
  367.    statistics about the subflows on a network.
  368.  
  369.  
  370.    3.4 Action on Exceptions
  371.  
  372.    The user of RTFM will have the ability to define Network and Derived
  373.    flows, as having High Watermarks. The existence of abnormal service
  374.    conditions, such as non-ending flow, a flow that exceeds a given
  375.    limit in traffic (e.g. a flow that is exhausting the capacity of the
  376.    line that carries it) causes an ALERT to be sent to the Collector for
  377.    forwarding to the Manager. Operations Support may define service
  378.    situations in many different environments. This is an area for
  379.    further discussion on Alert and Trap handling.
  380.  
  381. 4. Packet Flow Table
  382.  
  383.    The architecture of RTFM has defined the structure of flows, and this
  384.    draft does not change that structure. The flow table could have
  385.    ancillary tables called "Packet Flow Tables", which would contain
  386.    rows of values and or actions as defined under packet traces,
  387.    aggregate attributes and series attributes. Each Packet Flow table
  388.    would be marked with the number of its corresponding flow in the RTFM
  389.    flow table.  In order to identify the data in a Packet Flow Table,
  390.    the value of the Rules Table Extension will be pushed into a string
  391.    at the head of each row. For example, if a Packet Flow table entry
  392.    has Bit Rates for a particular flow, the "BitRate" string would be
  393.    found at the head of the row.
  394.  
  395.  
  396.  
  397. Handelman, Brownlee, Ruth                [Page 7]
  398.  
  399. Internet-Draft                        November, 1996
  400.  
  401.  
  402.    A method of bundling the Packet Flow table and the packet data will
  403.    be developed such that an SNMP manager can retrieve whole flow table
  404.    entries, and whole Packet Flow Tables, with SNMP v2 Getbulk
  405.    instructions. This will be accomplished by creating a flow attribute
  406.    called FlowDataPackage. This will be an encoded sequence of all the
  407.    objects such that the Getbulk could operate on the whole structure.
  408.  
  409. 4.1 Note on Interchange between Meter and Meter Reader
  410.  
  411.    The above information on Getbulk could be superseded in the near
  412.    future by the work of the RMONMIB Bulk Data Transfer.
  413.  
  414. 5. Extensions to the Rules Table
  415.  
  416.    The Rules Table of "old-style" attributes will be extended for the
  417.    new flow types. A list of actions, and Keywords, such as "BitRate"-
  418.    for Bit Rate, "MaxPack", for Max Packet size will be developed and
  419.    used to inform RTFM to collect a set of extended values for a
  420.    particular flow (or set of flows).
  421.  
  422. 6. Security Considerations
  423.  
  424.    Security considerations are not discussed in this memo.
  425.  
  426. 7. Author's  Address:
  427.  
  428.    Sig Handelman
  429.    IBM Research Division
  430.    Hawthorne, NY
  431.    Phone: 1-914-784-7626
  432.    E-mail: handel@watson.ibm.com
  433.  
  434.    Nevil Brownlee
  435.    The University of Auckland
  436.    New Zealand
  437.    Phone: +64 9 373 7599 x8941
  438.    E-mail: n.brownlee@auckland.ac.nz
  439.  
  440.    Greg Ruth
  441.    GTE Laboratories
  442.    Waltham, MA
  443.    Phone: 1 617 466 2448
  444.    E-mail: grr1@gte,com
  445.  
  446. 8. References:
  447.  
  448.    [1] Brownlee, N, Mills, C., Ruth, G.: "Traffic Flow Measurement:
  449.    Architecture", Internet Draft, April, 1996
  450.  
  451.  
  452.  
  453. Handelman, Brownlee, Ruth                [Page 8]
  454.  
  455. Internet-Draft                        November, 1996
  456.  
  457.  
  458.    [2] Wroclawski, J., : "The Use of RSVP with IETF Integrated Services
  459.    Internet" Draft,  October, 1996
  460.  
  461.    [3] Almes, G. et al: "Framework for IP Provider Metrics" Internet
  462.    Draft. July 1996
  463.  
  464.    [4] Claffy, K., Braun, H-W, Polyzos, G. "A Parameterizable
  465.    Methodology for Internet Traffic Flow Profiling," IEEE Journal on
  466.    Selected Areas in Communications, Vol. 13, No. 8, October 1995.
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509. Handelman, Brownlee, Ruth                [Page 9]
  510. 
  511.