Internet Draft                                                J. Quittek
<draft-quittek-ipfx-req-01.txt>                                      NEC
Expires: January 2002
                                                                T. Zseby
                                                                G. Carle
                                                               S. Zander
                                                               GMD FOKUS

                                                               July 2001


                    Requirements for IP Flow Export
                    <draft-quittek-ipfx-req-01.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This memo defines requirements for the export of IP flow information
   out of routers, traffic measurement probes and middleboxes.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.






Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 1]


Internet Draft              IPFX Requirements                  July 2001


Table of Content

   1. Introduction
   1.1. IP Flows
   2. Applications Requiring IP Flow Export
   2.1 Usage Accounting
   2.2 Traffic Profiling
   2.3 Traffic Engineering
   2.4 Attack/Intrusion Detection
   2.5 Network Surveillance
   2.6 QoS Monitoring
   3. Distinguishing Flows
   3.1. Interfaces
   3.2. Packet Treatment
   3.3. IP Header Fields
   3.4. Transport Header Fields
   3.5. MPLS Label
   3.6. DiffServ Code Point
   4. Metering Process
   4.1. Reliability
   4.2. Sampling
   4.3. Timestamps
   4.4. Timeout
   4.5. Header Compression
   4.6. Ignore Port Copy
   5. Data Export
   5.1. Information Model
   5.2. Data Model
   5.3. Data Transfer
   5.3.1. Reliability
   5.3.2. Confidentiality
   5.3.3 Integrity
   5.3.3 Authenticity
   5.4. Reporting Times
   5.4.1. Regular Interval
   5.4.2. Notification on Account Opening
   5.4.3. Notification on Account Closing
   5.5. Anonymization
   6. Configuration
   7. General Requirements
   8. Open Issues
   9. Security Considerations
   10. References
   11. Authors' Addresses







Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 2]


Internet Draft              IPFX Requirements                  July 2001


1. Introduction

   There are several applications that require flow-based IP traffic
   measurements.  Such measurements could be performed by a router while
   forwarding the traffic, by a middlebox [MIDBOXTAX], or by a traffic
   measurement probe attached to a line or monitor port. This memo
   defines requirements for exporting traffic flow information out of
   these boxes for further processing by applications located on other
   devices. In section 2 a selection of such applications is presented.
   The following sections list requirements derived from these
   applications.

1.1 IP Flows

   There are several definitions of the term 'flow' being used by the
   Internet community. Within this document we use the following one:

      A flow is a set of packets passing an observed point in the
      network during a certain time interval. All packets belonging to a
      particular flow have a set of common properties derived from the
      data contained in the packet or from packet reception or packet
      treatment at the observing device.

   The observed point may be a network interface of a device or an
   entire router or middlebox with several interfaces. Properties
   derived from packet reception include the interface at which the
   packet arrived and potentially some more fine grained sub-IP
   information. Properties derived from packet treatment include
   information about the kind of treatment (observation only, reception,
   forwarding, discarding) and, in case of forwarding, the selected
   forwarding parameters.

   Which flow properties are considered for distinguishing flows is part
   of the requirements definition and will be addressed below. This
   definitions cover the range from a flow containing all packets
   observed at a network interface to a flow consisting of just a single
   packet between two applications with a specific sequence number.
   Please note that the definition does not match a general application-
   level end-to-end stream. However, an applicaton may derive properties
   of application-level streams by processing measured flow data.


2. Applications Requiring IP Flow Export

   The following list contains a selection of applications requiring IP
   flow export. Because requirements for flow export listed in further
   sections below are derived from these applications, their selection
   is crucial. The goal of this requirements document is not to cover



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 3]


Internet Draft              IPFX Requirements                  July 2001


   all possible applications with all their flow export requirements,
   but to cover applications which are considered to be of significant
   importance in today's or future IP networks, and for which
   requirements can be met with reasonable technical effort.

   Please note, that the described applications can have a large number
   of differing implementations. Requirement details or the weighting of
   requirements could differ for specific implementations. Therefore we
   derive the requirements from the general functionality of the
   selected applications.  Furthermore, the list of applications should
   lead to a better understanding of the requirements which is
   particularly important when designing or implementing a traffic flow
   measuring device.

2.1 Usage Accounting

   Several new business models for selling IP service and IP-based
   services are currently under investigation. Beyond flat rate services
   which do not need accounting, accounting for these models can be
   based on time or volume. Accounting can be performed per user or per
   user group, it can be performed just for basic IP service or
   individually per high-level service and/or per content type
   delivered. For advanced/future services, accounting may also be
   performed per class of service (assuming different quality of service
   for different classes) and per used (label switched) path.

2.2 Traffic Profiling

   Traffic profiling is a process of characterizing IP flows and flow
   aggregates by using a model that represents key parameters of the
   flow such as flow duration, volume and burstiness. It is a
   prerequisite for network planning, network dimensioning, trend
   analysis, developing business models, and other activities. It
   heavily depends on the particular traffic profiling objective(s) what
   statistics and accuracy are required from the measurements. Typical
   information needed for traffic profiling are the distribution of used
   services and protocols in the network, the amount of packets of a
   specific type (e.g. percentage of IPv6 packets) and specific flow
   profiles.

   Since objectives for traffic profiling can vary, this application
   requires a high flexibility of the measurement infrastructure,
   especially regarding the options for measurement configuration and
   packet classification.

2.3 Traffic Engineering

   Traffic Engineering (TE) comprises methods for measurement, modeling,



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 4]


Internet Draft              IPFX Requirements                  July 2001


   characterization and control of a network. The goal of TE is the
   optimization of network resource utilization and traffic performance
   [RFC2702].  Since control and administrative reaction to measurement
   results requires access to the involved network nodes, TE mechanisms
   and the required measurement function usually are performed within
   one administrative domain.  Typical parameters required for TE are
   link utilization, load between specific network nodes, number, size
   and entry/exit points of the active flows and routing information.

2.4 Attack/Intrusion Detection

   Capturing of flow information plays an important role for network
   security, both for detection of security violation, and for
   subsequent defense. In case of a Denial of Service (DOS) attack, flow
   monitoring can allow detection of unusual load situations or
   suspicious flows. In a second step, flow analysis can be performed in
   order to gather information about the attacking flows, and for
   deriving a defense strategy.  Intrusion detection is a potentially
   more demanding application which would not only look at specific
   characteristics of flows, but that may also use a stateful packet
   flow analysis for detecting specific, suspicious activities, or
   unusally frequent activities. Such activities may be characterized by
   specific communication patterns, detectable by characteristic
   sequences of certain packet types.

2.5 Network Surveillance

   This application class requires collection and storage of information
   that characterizes flows, and possibly also the collection and
   storage of selected packets. One obvious use for network surveillance
   is the collection of evidence of illegal activities for the purpose
   of law enforcement. As the data collected for the purpose of network
   surveillance contains sensitive information, adequate security
   mechanisms are required in order to avoid misuse of the sensitive
   information.

2.6 QoS Monitoring

   QoS monitoring is the non-intrusive (passive) measurement of quality
   parameters for single flows or traffic aggregates.  In contrast to
   intrusive (active) measurements, non-intrusive measurements utilize
   the existing traffic in the network for QoS analysis. Since no test
   traffic is sent, non-intrusive measurements can only be applied in
   situations where the traffic of interest is already present in the
   network. One example application is the validation of QoS parameters
   negotiated in a service level specification (SLS).

   Non-intrusive measurements cannot provide the kind of controllable



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 5]


Internet Draft              IPFX Requirements                  July 2001


   experiments that can be achieved with active measurements. On the
   other hand non-intrusive measurements do not suffer from undesired
   side effects caused by sending test traffic (e.g. additional load,
   "Heisenberg" effects, potential differences in treatment of test
   traffic and real customer traffic)

   QoS monitoring often requires the correlation of data from multiple
   measurement instances  (e.g. for measuring one-way metrics). This
   requires proper clock synchronization of the involved measurement
   instances. For some measurements packet events at the different
   measurement points must be correlated. For this, the provisioning of
   post-processing functions (e.g. the generation of packet IDs) at the
   measurement instances would be useful.  Furthermore QoS monitoring
   can lead to a huge amount of measurement result data. Therefore it
   would highly benefit from mechanisms to reduce the measurement data,
   like aggregation of results and sampling.


3. Distinguishing Flows

   The following are requirements for distinguishing flows. They specify
   the required availability of properties of observed packets for
   mapping packets to flows. A traffic measuring device MUST support the
   separation of packets by single properties as well as by combinations
   of properties listed below.

3.1. Interfaces

   The measuring device MUST be able to separate flows by the network
   interface at which the packet was observed. If the packet enters the
   device at one interface and leaves it at a different interface, flow
   separation by the incoming interface MUST be supported as well as
   separation by the outgoing interface(s).

3.2. Packet Treatment

   The measuring device SHOULD be able to separate flows by the
   treatment it applies to the packet, such as pure observation,
   reception, forwarding, discarding.

3.3. IP Header Fields

   The measuring device MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated. It MUST
   support separation by a single field as well as separation by
   arbitrary combinations of all REQUIRED fields:
      1. source address (MUST)
      2. destination address (MUST)



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 6]


Internet Draft              IPFX Requirements                  July 2001


      3. transport protocol type (MUST)
      4. version number (SHOULD)
      5. time to live (MAY)
   For source address and destination address separating by full match
   MUST be supported as well as separation by a partial match.

3.4. Transport Header Fields

   The measuring device MUST be able to separate flows by the port
   numbers of the transport header in case of TCP or UDP being used as
   transport protocol. Both, source and destination port number MUST be
   supported for distinguishing flows, individually as well as in
   combination.

3.5. MPLS Label

   If the measuring device supports Multiprotocol Label Switching (MPLS,
   see [RFC3031]) and if this support is activated, then the measuring
   device MUST be able to separate flows by the MPLS label.

3.6. DiffServ Code Point

   If the measuring device supports Differentiated Services (DiffServ)
   and if this support is activated, then the measuring device MUST be
   able to separate flows by the DiffServ Code Point (DSCP, see
   [RFC2474]).


4. Metering Process

   The following are requirements for the metering process. They
   describe the requirements for the process at the measurement
   instance.

4.1. Reliability

   The measurement process MUST either be reliable or missing
   reliability MUST be known and indicated. The measurement process is
   reliable, if each packet passing the point of observation is measured
   according to the configuration of the measuring device. If, e.g. due
   to some overload, not all passing packets can be included into the
   measurement process, then it SHOULD be stored at the measuring
   device, that flows might be measured inaccurately.








Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 7]


Internet Draft              IPFX Requirements                  July 2001


4.2. Sampling

   The measuring device MAY support measuringe traffic by packet
   sampling. If sampling is supported the sampling method and its
   parameters MUST be well defined. The device MAY offer a mechanism for
   automatically switching to sampling (or to a more coarse flow
   definition) in case of certain events, such as device overloaded. If
   automatic switch to sampling or automated switch of the sampling rate
   is supported, the events triggering a switch and the chosen sampling
   method and parameters after a switch MUST be well defined.

4.3. Timestamps

   The measuring device MUST be able to generate timestamps for observed
   packets.  For each accounted flow it MUST be possible to measure at
   least the timestamps of the first and the last packet observed.

4.4. Timeout

   The measuring device MUST be able to detect flow timeout. A flow is
   considered to be timed out if no packet of this flow has been
   observed for a given timeout interval.

4.5. Header Compression

   If the measuring device is able to interpret or forward compressed IP
   headers, then it MUST account all passing packets with compressed
   headers as if they were not compressed.

4.6. Ignore Port Copy

   The measuring device MAY be able to igore packets which are generated
   by a port copy function acting at the same device.


5. Data Export

   The following are requirements for exporting measured flow data out
   of the measuring device. We separate requirements concerning the data
   model and the information model from requirements concerning the data
   transport, and from requirements concerning the reporting interval.

5.1. Information Model

   The information model describes what information is exported. The
   measuring device MUST be able to report the following attributes for
   each measured flow:
      1. flow specification Index



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 8]


Internet Draft              IPFX Requirements                  July 2001


         It is assumed that configuring flow measurement includes
         stating a set of flow specifications, each of them specifying a
         single flow or a set of flows. Reports on measured flows MUST
         for each reported contain an index or other identifier
         indicating the flow specification (or in case of overlapping
         specifications: one of the flow specifications) which caused
         the measuring device to measure the particular flow.
      2. IP version number
      3. source address
      4. destination address
      5. transport type
      6. source port number
      7. incoming interface
      8. outgoing interfaces
      9. packet treatment (observed only, received, forwarded, dropped)
     10. packet counter
     11. dropped packet counter
     12. payload byte counter
     13. in case of IPv4: Type of Service
     14. in case of IPv6: Flow Label
     15. if MPLS is supported and activated: MPLS label
     16. if DiffServ is supported and activated: DSCP
     17. timestamp of the first packet observed
     18. timestamp of the last packet observed
     19. timeout indication
     20. sampling method
     21. sampling parameters
     22. unique identifier of the observation point
     23. unique identifier of the measuring device

   The measuring device SHOULD be able to report the following
   attributes for each measured flow:
     24. Time To Live
     25. IP header flags
     26. TCP header flags

5.2 Data Model

   The data model describes how information is represented in flow
   records. The data model used for exporting flow data MAY be flexible
   concerning the flow attributes contained in reports. A flexible
   record format would offer the possibility of defining records in a
   flexibility way regarding the number and type of report attributes.

   The data model MUST be extensible for future attributes to be added.
   Even if a set of attributes is fixed in the flow record, the data
   model MUST provide a way of extending the record by configuration or
   for certain implementations.



Quittek et al.        draft-quittek-ipfx-req-01.txt             [Page 9]


Internet Draft              IPFX Requirements                  July 2001


5.3. Data Transfer

   Requirements for the data transfer include reliability and security
   requirements. These requirements do not apply to the measuring device
   alone, but also to the transport network. Consequently, the
   measurement device does not necessarily have to guarantee that all
   requirements are met. Particularly the security requirements might be
   guaranteed already by the network used for data transfer. Then these
   requirements do not have to be considered anymore by the measuring
   device. Therefore, these requirements are OPTIONAL for the measuring
   device, although they may be REQUIRED for the data transfer as
   specified in the appendix.

5.3.1. Reliability

   The data transfer mechanism MUST either be reliabe, or it MUST
   indicate loss of packets and packet reordering during transport.

5.3.2. Confidentiality

   The measuring device MAY provide means for ensuring confidentiality
   of the reported data, e.g. by encryption.

5.3.3 Integrity

   The measuring device MAY provide means for ensuring integrity of the
   reported data.

5.3.3 Authenticity

   The measuring device MAY provide means for ensuring authenticity of
   the reported data.

5.4. Reporting Times

   In general, there are two ways of deciding on reporting times: push
   mode and pull mode. In push mode, the measuring device decides
   without an external trigger on when to send a report on measured
   flows.  In pull mode, sending a report is triggered by an explicit
   request from a data collector or some other receiver of flow records.
   The measuring device MUST support push mode reporting, it MAY support
   pull mode reporting.

5.4.1. Regular Interval

   The measuring device MUST be capable of reporting measured traffic
   data regularly according to a given interval length.




Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 10]


Internet Draft              IPFX Requirements                  July 2001


5.4.2. Notification on Flow Account Opening

   The measuring device MUST be capable of sending notifications to a
   consumer of measure data, that indicate the arrival of the first
   packet of a new flow account.

5.4.3. Notification on Flow Account Closing

   The measuring device MUST be capable of sending notifications to a
   consumer of measure data, that indicate the closing of an account. An
   account for a specific flow might for example be closed after a
   certain timeout expires.

5.5. Anonymization

   The measuring device SHOULD be capable of anonymizing source and
   destination IP addresses in flow data before exporting them. It
   SHOULD support anonymization of port numbers and MAY support the
   anonymizing of other fields. Please note that anonymization is not
   originally an application requirement, but derived from general
   requirements for treatment of traffic within a network.


6. Configuration

   The measuring device MUST provide a way of configuring traffic
   measurement and traffic data export remotely. The following
   parameters MUST be configurable:
      1. specification of the observation point, e.g. a list of
         interfaces
      2. specifications of flows to be measured
      3. reporting data format
         Specifying the reporting data format SHOULD include a selection
         of attributes to be reported for each flow.
      4. reporting interval
      5. notifications
      6. flow timeouts
      7. sampling method and parameters, if feature is supported
      8. flow anonymization, if feature is supported

   The measuring device SHOULD support security of remote configuration
   including confidentiality, integrity and authenticity.









Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 11]


Internet Draft              IPFX Requirements                  July 2001


7. General Requirements

7.1. Openness

   IPFX specifications SHOULD be open to future technologies. This
   includes extensibility of configuration of measurement and reporting
   as well as extensibility of the reporting data model used for
   reporting.

7.2. Scalability concerning measuring devices

   Data collection from at least hundreds of different measuring devices
   MUST be supported. This includes a unique identification of the
   measuring device.


8. Open Issues

   The following issues need to be discussed and included into the
   document:
      1. requirements for measuring multicast traffic
         Shall the number of outgoing packets originating from a single
         incoming packet be reported? Shall all outgoing ports used by a
         multicast session be reported?
      2. Scalability concerning number of flows
      3. Adding AS# to section 5.1.
      4. IP Fragmentation
         How shall fragmented packets be counted? Is fragmentation to be
         reported?
      5. Security
         A lot of security issues need to be discussed including
         - secure configuration
         - exporting payload?
         - TCP header fields and IPSec
         - option for encryption of reported flow records?


9. Security Considerations

   The configuration of a meter and the export of IP Flow information
   has a number of possible security threats such as unauthorized
   access, modification or disclosure of the exported flow information.
   Depending on whether information about the originator of the flow is
   allowed to be revealed privacy protection may be an issue.

   The transport of IP flow and configuration information can be secured
   through the use of end-to-end encryption, as e.g. provided by IPSec.
   The meter must be protected against unauthorized access at the



Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 12]


Internet Draft              IPFX Requirements                  July 2001


   configuration interface.  For inter-domain scenarios the access
   control provided by SNMPv3 [RFC 2274] appears adequate. For other
   scenarios such as third party measurement or inter-domain
   authorization control, a AAA protocol and AAA servers may be
   necessary. This access control can be controlled by policies which
   can be very fine grained such that a certain user is allowed to get
   only specific flow information. If privacy of the flow originator is
   of concern all flow information which contains sensitive data must be
   at least partially anonymized.


10. References

   [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues",
             draft-carpenter-midtax-01.txt, work in progress.

   [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
             Switching Architecture", RFC 3031, January 2001.

   [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition
             of the Differentiated Services Field (DS Field) in the IPv4
             and IPv6 Headers", RFC 2474, December 1998.

   [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
              "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM)
             for version 3 of the Simple Network Management Protocol
             (SNMPv3), RFC 2274, January 1998.


11. Authors' Addresses

   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   69115 Heidelberg
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de









Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 13]


Internet Draft              IPFX Requirements                  July 2001


   Tanja Zseby
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7153
   Email: zseby@fokus.gmd.de


   Georg Carle
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7149
   Email: carle@fokus.gmd.de


   Sebastian Zander
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7287
   Email: zander@fokus.gmd.de



Appendix: Derivation of Requirements form Target Applications

   The following table documents, how the requirements stated in
   sections 3-7 are derived from requirements of the applications listed
   in section 2.

   Used abbreviations:
      M = MUST
      S = SHOULD
      O = MAY (OPTIONAL)
      - = DONT CARE









Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 14]


Internet Draft              IPFX Requirements                  July 2001


   -----------------------------------------------------------------------.
      IPFX                                                                |
   ----------------------------------------------------------------.      |
   F: QoS Monitoring                                               |      |
   ----------------------------------------------------------.     |      |
   E: Network Surveillance                                   |     |      |
   ----------------------------------------------------.     |     |      |
   D: Attack/Intrusion Detection                       |     |     |      |
   ----------------------------------------------.     |     |     |      |
   C: Traffic Engineering                        |     |     |     |      |
   ----------------------------------------.     |     |     |     |      |
   B: Traffic Profiling                    |     |     |     |     |      |
   ----------------------------------.     |     |     |     |     |      |
   A: Usage Accounting               |     |     |     |     |     |      |
   ----------------------------.     |     |     |     |     |     |      |
                               |     |     |     |     |     |     |      |
   | Sect. |    Requirement    |  A  |  B  |  C  |  D  |  E  |  F  | IPFX |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       | GENERAL REQ                                                  |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |                   |     |     |     |     |     |     |      |
   | 7.2.  |Scalability:       |     |     |     |     |     |     |      |
   |       |data collection    |  M  |  S  |  M  |  O  |  M  |  S  |  M   |
   |       |from hundreds of   |     |     |     |     |     |     |      |
   |       |measurement devices|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       | FLOW DISTINGUISH                                             |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.    |Combination of     |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |required attributes|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.1.  |in/out IF          |  S  |  M  |  M  |  S  |  S  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.2.  |Packet treatment   |  O  |  O  |  S  |  O  |  O  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |src/dst address    |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |Masking of IP      |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |adresses           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |transport protocol |  M  |  M  |  -  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |version field      |  -  |  S  |  S  |  O  |  O  |  O  |  S   |
   |       |                   |     |     | (b) |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |TTL                |  -  |  O  |  -  |  O  |  -  |  -  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.4.  |src/dst port       |  M  |  M  |  -  |  M  |  M  |  M  |  M   |



Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 15]


Internet Draft              IPFX Requirements                  July 2001


   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.5.  |MPLS label (a)     |  S  |  S  |  M  |  O  |  -  |  S  |  M   |
   |       |                   |     |     | (c) |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.6.  |DSCP (a)           |  M  |  S  |  M  |  O  |  -  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |METERING PROCESS                                              |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.1.  |Reliability        |  M  |  S  |  S  |  S  |  M  |  S  |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+  M   |
   | 4.1.  |Indication of      |  -  |  M  |  M  |  M  |  -  |  M  |      |
   |       |missing reliability|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.2.  |Sampling           |  O  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.2.  |Dynamic sampling   |  O  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.3.  |Timestamping at    |  M  |  O  |  O  |  S  |  S  |  M  |  M   |
   |       |measurement device |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.4.  |Flow timeout       |  M  |  s  |  -  |  O  |  O  |  O  |  M   |
   |       |                   | (d) |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.5.  |Process compressed |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |headers (a)        |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.6.  |Ignore port copy   |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |REPORT ATTRIBUTES                                             |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       | => TODO           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |DATA MODEL                                                    |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.2.  |Flexibility        |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.2.  |Extensibility      |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |DATA TRANSFER                                                 |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.1 |Reliability        |  M  |  S  |  S  |  S  |  M  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.2 |Confidentiality    |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.3 |Integrity          |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.4 |Authenticity       |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|



Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 16]


Internet Draft              IPFX Requirements                  July 2001


   |       |REPORTING TIMES                                               |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.  |Push mode          |  M  |  O  |  O  |  M  |  O  |  S  |  M   |
   |       |                   |     | (e) | (e) |     | (e) |(e,f)|      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.  |Pull mode          |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |                   |     | (e) | (e) |     | (e) | (e) |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.1 |Regular Interval   |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.2 |Flow Acct. Opening |  S  |  O  |  O  |  M  |  O  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.3 |Flow Acct. Closing |  M  |  O  |  O  |  M  |  O  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |CONFIGURATION                                                 |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |=> TODO            |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   |       |                   |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|

   Remarks:
     (a) if feature is supported
     (b) The differentiation of IPv4 and IPv6 is for TE of importance.
         So we tended to make this a MUST. Nevertheless, a SHOULD seems
         to be sufficient to perform most TE tasks and allows us to have
         a SHOULD for IPFX instead of a MUST.
     (c) For TE in an MPLS network the label is essential. Therefore a
         MUST is given here leading to a MUST in IPFX
     (d) Precise time-based accounting requires reaction to a flow
         timeout.
     (e) Either push or pull has to be supported.
     (f) Required, in order to immediately report drop indications for
         SLA validation

















Quittek et al.        draft-quittek-ipfx-req-01.txt            [Page 17]