Subject: [ipfix-eval] Streaming IPDR Advocacy Draft

From: Jeff Meyer <[email-masked]>
Date: Mon, 02 Sep 2002 21:24:50 -0700

Hi,

Please post the attached draft-meyer-ipfix-IPDR-eval-00.txt as an
internet draft.

The document is also available at the following URL:

http://www.ipdr.org/documents/ipfix/draft-meyer-ipfix-IPDR-eval-00.txt

An HTML version is also available, making navigation
to references simpler, at:

http://www.ipdr.org/documents/ipfix/draft-meyer-ipfix-IPDR-eval-00.html

Regards,

   Jeff Meyer

Network Working Group                                           J. Meyer
Internet-Draft                                           Hewlett-Packard
Expires: March 3, 2003                                 September 2, 2002

        Evaluation Of Streaming IPDR Against IPFIX Requirements
                     draft-meyer-ipfix-IPDR-eval-00

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.

   This Internet-Draft will expire on March 3, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document provides an evaluation of the applicability of the
   Streaming IPDR protocol as an IPFIX protocol.  It compares the
   properties and capabilities of Streaming IPDR to the IPFIX
   requirements.

   Streaming IPDR is a mechanism to deliver streams of network usage
   information which follow the Internet Protocol Detail Records (IPDR)
   format over a reliable transport connection.

Meyer                    Expires March 3, 2003                  [Page 1]

Internet-Draft            Streaming IPDR Eval             September 2002

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Documentation  . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   Level of Standarization  . . . . . . . . . . . . . . . . . .  3
   1.3   Patent Protection  . . . . . . . . . . . . . . . . . . . . .  4
   1.4   Availability . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.5   Commercial Use . . . . . . . . . . . . . . . . . . . . . . .  4
   1.6   Future Protocol Development Areas  . . . . . . . . . . . . .  4
   2.    Architectural Considerations . . . . . . . . . . . . . . . .  5
   2.1   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .  5
   2.2   General Applicability  . . . . . . . . . . . . . . . . . . .  6
   2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.2.2 Trivial Streaming IPDR . . . . . . . . . . . . . . . . . . .  8
   2.3   Architectural Differences  . . . . . . . . . . . . . . . . .  8
   3.    Item Level Compliance Evaluation . . . . . . . . . . . . . .  9
   3.1   Items by Section . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.1 Data Export (6)  . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.2 Configuration (7)  . . . . . . . . . . . . . . . . . . . . . 11
   3.1.3 General Requirements (8) . . . . . . . . . . . . . . . . . . 12
   3.2   Compliance Table . . . . . . . . . . . . . . . . . . . . . . 12
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 17
         References . . . . . . . . . . . . . . . . . . . . . . . . . 18
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
   A.    IPFIX IPDR Service Definition  . . . . . . . . . . . . . . . 20
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 29

Meyer                    Expires March 3, 2003                  [Page 2]

Internet-Draft            Streaming IPDR Eval             September 2002

1. Introduction

   This document provides an evaluation of the applicability of the
   Streaming IPDR [2] protocol as an IPFIX protocol.  First, the general
   IPDR architecture is introduced and its application to the
   communication between an IPFIX exporting process and an IPFIX
   collecting process is discussed in Section 2.  Section 3 discusses in
   detail, to which degree requirements stated in the IPFIX Requirements
   [1] are met.

   This document uses the terminology defined in IPFIX Requirements [1].

1.1 Documentation

   The specific protocol mechanism, Streaming IPDR [2], is a work in
   progress submitted as an IETF draft.

   The protocol itself builds upon some of the procedures defined in the
   IPDR Network Data Management-Usage (NDM-U) 3.1 [6] specification.

   Sections 1, 2 and 3 of the NDM-U 3.1 specification provide an
   Introduction, the IPDR Reference model and the business requirements
   addressed.

   The relevant protocol sections in NDM-U 3.1 are:

      The NDM-U Protocol in section 4.  More specifically subsections
      4.1 and 4.3.

      The Schema guidelines in section A.4

   In addition Appendix A in this document defines an IPDR service
   definition which addresses the required set of IPFIX data attributes.

1.2 Level of Standarization

   IPDR.org is an non-profit industry consortium.  Member companies
   collaborate to agree upon IPDR specifications.  These specifications
   are versioned and published on the IPDR.org website.  The current
   specification as of this writing is NDM-U 3.1. [6]

   Particpating companies also participate in interoperability and
   compliance activities to shake out issues in the specification.

   In addition to relying on the NDM-U 3.1 specification, this proposal
   introduces two additional documents, the IPFIX service definition, in
   Appendix A and the Streaming IPDR [2] extension and protocol binding.

Meyer                    Expires March 3, 2003                  [Page 3]

Internet-Draft            Streaming IPDR Eval             September 2002

   The Streaming IPDR protocol may be submitted as an IETF Proposed
   Standard, based on evaluation by the IPFIX working group.

1.3 Patent Protection

   There are no known patents which apply to or affect the right to
   freely use this technology.

1.4 Availability

   The base IPDR NDM-U 3.1 specification is implemented by a number of
   billing and mediation software companies.  The specific procedures
   introduced in Streaming IPDR are not currently available with
   commercial products.

   A complete implementation written in Java has been developed, but is
   under test.  A C implementation can built upon existing work done in
   IPDR's reference library.

1.5 Commercial Use

   Several service providers have deployed IPDR based service accounting
   in their networks.  Based upon the recent availability of a compact
   as well as XML based format, and IPDR's XML-Schema based extension
   model, it is expected that IPDR will be more widely deployed in the
   future.

1.6 Future Protocol Development Areas

   The current NDM-U 3.1 Sevice Definition Guidelines and the Compact
   data model limit the protocol to carrying data which is in "First
   Normal Form" (FNF).

   Current IPFIX flow records are also FNF.  They are all defined as
   non-repeating fields, and the fields are simple primitive types, not
   structures.

   It is desireable to remove the first normal form restriction, but
   still encourage keeping record structures as flat as possible.  This
   will allow mapping the XML Schema model to existing protocols and
   CDRs such as Diameter or 3GPP GGSN records, without removing
   information.

   Proposed additions to the XDR based compact format and the Schema
   writing guidelines will be made shortly to address repeating fields
   and records to be defined in addition to FNF.

Meyer                    Expires March 3, 2003                  [Page 4]

Internet-Draft            Streaming IPDR Eval             September 2002

2. Architectural Considerations

   This section introduces the architecture of the Streaming IPDR
   protocol and suggests a way of applying it to the communication
   between an IPFIX exporting process and an IPFIX collecting process.

   IPDR is a general purpose protocol meant to address the exchange of
   usage information between cooperating systems.

2.1 Protocol Overview

   The compact IPDR specification defines a document format which offers
   a compact and efficient represenation of usage accounting data.  This
   structure is defined in section 4.3 of the IPDR NDM-U 3.1
   [6]specfication.

   The encoding format is based on the ONC-RPC eXtensible Data
   Representation (XDR).  The encoding supports a basic set of primitive
   data types and a number of additional types which are derived from
   the primitive types

   The mechanisms for encoding and transport are completely separate in
   IPDR.

   The CompactIPDR format can be used to serialize usage information to
   a file or it can be used to serialize usage information onto a
   reliable transport, such as TCP.  For real time push oriented
   communication the streaming over a reliable transport is preferred,
   as described in Streaming IPDR [2].

   A file can also be used as the unit of exchange.  File based exchange
   has been the focus of much of  the Interoperability work done by
   various member companies of IPDR.org to date.  The file transfer
   related exchange described in Section 4.4 is not part of this
   proposal.  Although it does provide a pull based model for exchange
   of information between collection processes.

   IPDR's XML-Schema based format has the additional benefit of
   providing a well defined equivalent XML encoding.  Both the compact
   and XML formats are based on a common service definition
   specification.  The service specification is expressed as one or more
   XML Schema documents, which follow the guidelines set forth in
   section A.4 of the IPDR NDM-U 3.1 specification.

   Service specifications are the primary means of extension in IPDR.  A
   service definition addressing the required and optional parameters
   described in IPFIX Requirements is provided as an Appendix to this
   document.

Meyer                    Expires March 3, 2003                  [Page 5]

Internet-Draft            Streaming IPDR Eval             September 2002

   As an example of the general usefulness of XML as a base language for
   specifications, consider this document.  Although you may be reading
   it as an HTML document or a formatted nroff text document, it started
   off as a set of markup following RFC2629 [13].

                       +----------------------+
                       | Service Definition(s)|
                       |    (in XML Schema)   |
                       +----------------------+
                          |              |
                          v              v
            +---------------------+   +-----------------------+
            | Usage information   |   |  Usage information    |
            |   (an XML Document) |   |   (a compact document)|
            +---------------------+   +-----------------------+

   The XML encoding is not used by Streaming IPDR protocol.  However it
   is worth noting that all flow records sent using Streaming IPDR have
   a lossless and unambiguous mapping to content in an XML document.

   The details of the XML encoding are contained in Section 4.2 of NDM-U
   3.1 [6].

2.2 General Applicability

   This specification only addresses the exchange of information between
   an exporting process and a collecting process.  How metering points
   and observation points interact with the exporting process is
   specifically not addressed.

   Specifically the model specified in section 2.4 of NDM-U 3.1 [6]
   assumes that the Service Element contains the metering points.  The
   raw information acquired by the meterint points is turned into IPDR
   based strcutures by some Recording Element.

   The recorded flows are transmitted over a TCP connection to one or
   more collecting processes.  Different record types are identified in
   the stream by different descriptors.  These types should also be
   defined in one of the XML Schemas describing the exported
   information.

2.2.1 Illustration

   The basic elements of the Streaming IPDR protocol are the following:

Meyer                    Expires March 3, 2003                  [Page 6]

Internet-Draft            Streaming IPDR Eval             September 2002

      Header - this describes the XML schemas and namespace declarations
      to be used for this session (or document).  This makes each stream
      (or file) a self describing document.

      Descriptor - sometimes refered to as templates, this element
      describes the fields which may appear in a flow record.  Order is
      implied.  This allows flow records to be well packed (especially
      with numeric types).

      Ack - a message indicating the sequence number and relative time
      information at each system.  Provides "application level" flow
      control capabilities.

      Usage Event - a flow record whose structure was previously defined
      by a descriptor.

      Disconnect - provides graceful shutdown of communication channel
      with known disposition of flow records.

      Time t0:

                      <-- TCP Conn Established -->

       +----------------+
       |     Header     |
       +----------------+  -- transmitted -->
       |   Descriptor   |
       +----------------+
       |      Ack       |
       +----------------+

                                      +----------------+
                                      |     Header     |
                   <-- transmitted    +----------------+
                                      |      Ack       |
                                      +----------------+

      Time t1 (one or more usage event(s) recorded):

       +----------------+
       |   Usage Event  |  -- transmitted -->
       +----------------+
               ...
       +----------------+
       |   Usage Event  |

Meyer                    Expires March 3, 2003                  [Page 7]

Internet-Draft            Streaming IPDR Eval             September 2002

       +----------------+

      Time t2 (either time or volume hint triggers Ack):

                                      +----------------+
                   <-- transmitted    |      Ack       |
                                      +----------------+

      Time t3 (idle period has exceeded hint):

       +----------------+
       |      Ack       |  -- transmitted -->
       +----------------+

      Basic scenario continues until some terminating control message
      arrives and finally at time tn:

       +----------------+
       |    Disconnect  |  -- transmitted -->
       +----------------+
                                      +----------------+
                   <-- transmitted    |   Disconnect   |
                                      +----------------+

                       <-- TCP Connection Release -->

   Note that additional descriptor stream elements MAY be transmitted in
   the stream along with Usage Events at any time.

2.2.2 Trivial Streaming IPDR

   The illustration presented above is the IPDR Streaming protocol in
   its reliable mode.  There is also a "Trivial Streaming Protocol"
   which does not involve any communication from the collecting system.
   The author has seen several middlebox and application protocols
   following this pattern.  So it is worthwile to note this option
   exists as well.

2.3 Architectural Differences

   When limited to the communication between an exporting process and a
   collection process, the IPDR Reference model matches that of IPFIX.

Meyer                    Expires March 3, 2003                  [Page 8]

Internet-Draft            Streaming IPDR Eval             September 2002

3. Item Level Compliance Evaluation

   This section evaluates the compliance of the Streaming IPDR with the
   IPFIX requirements item by item.  Requirements are addressed by their
   section numbers and item numbers in IPFIX Requirements [1].  For each
   requirement, it is explained to what degree Streaming IPDR meets the
   requirement and how this is achieved.

   At the end of the written discussion a table summarizes the
   compliance by asssigning one of five grades to each item.

   Please note that the requirements specified in sections 4, 5 and 7.1
   of IPFIX Requirements [1] do not directly concern the IPFIX protocol,
   but the semantics of the data transferred.  They can be met easily by
   extensible protocols that do not restrict sematics of transferred
   data.  This includes the Streaming IPDR format, as the data model
   allows for arbitrary extension, following a well established
   standard, XML Schema [4].

   Therefor only sections 6, 7.2 and 8 will be directly covered.

3.1 Items by Section

   The subsections describe how Streaming IPDR satisfies each of the
   mandatory requirements of the specified for the IPFIX protocol.

3.1.1 Data Export (6)

3.1.1.1 Information Model (6.1)

   The proposed information model is based on the data model  draft [12]
   which is currently available.

   Items 2,3,4,5,6,7,8,9,10,11,12,16,17,18 are addressed directly by the
   existing IPFIX data model draft.  They are present as element
   defintions in Appendix A.  The combination of these elements to form
   an IPDR complexType is also shown.  Mandatory and optional parameters
   are captured as well.

   The remaining items are addressed as follows:

      Item 1: the distinction between IPv4 and IPv6 is determined by the
      record type.  Records either contain all IPv4 based addresses or
      all IPv6 style addresses.

      Item 13: the current data model defines three attributes related
      to Autonomous System identifiers.  These are captured in the
      schema definition.  The meaning of "if BGP is supported at the

Meyer                    Expires March 3, 2003                  [Page 9]

Internet-Draft            Streaming IPDR Eval             September 2002

      observation point: BGP AS Number" is unclear.

      Item 19: the current data model does specifies an address of an
      observationPoint.  It is assumed this matches the intent of this
      item.

      Item 20: the initial IPDR header exchange provides recorderInfo,
      which should match this requirement.

      Items 14,15,21,22,26: the current data model does not appear to
      define these items.  This protocol advocacy draft assumes that the
      abstract data model be defined to match the requirements.

3.1.1.2 Data Model (6.2)

   IPDR's Data Model is based on a subset of XML Schema.  [4]  This
   subset provides a restricted set of types to define basic elements
   (Flow Record Fields) and complex type definitions (Flow Record
   structures).

   The front matter to the XML Schema webpage states "XML Schemas
   express shared vocabularies and allow machines to carry out rules
   made by people.  They provide a means for defining the structure,
   content and semantics of XML documents."

   IPDR carries this definition further, recognizing that the XML-Schema
   language can be used to define the structure, content and semantics
   of other encoding schemes.  In particular the mapping to XDR provides
   one concrete use case.  Future definitions may map to additional
   protocols.

   Appendix A provides an example of the modelling capability of NDM-U
   3.1.  See the section describing "Futures" in this document for
   additional planned capabilities.

3.1.1.3 Data Transfer (6.3)

3.1.1.3.1 Congestion Awareness (6.3.1)

   Streaming IPDR uses TCP which is congestion aware.  Streaming IPDR
   also enables congestion information at the application level via the
   optional use of sequence numbers.

3.1.1.3.2 Reliability (6.3.2)

   Streaming IPDR uses TCP which is provides reliable ordered delivery
   of information.  Streaming also allows for application level sequence

Meyer                    Expires March 3, 2003                 [Page 10]

Internet-Draft            Streaming IPDR Eval             September 2002

   numbers.  In the event of connection loss, the acknowledgement scheme
   will bound the amount of information which needs to be retransmitted,
   in order to guarantee delivery of all flow records.

3.1.1.3.3 Security (6.3.3)

   The underlying security options proposed by Streaming IPDR in section
   4 address the attacks and other concerns described in the security
   section.

3.1.1.4 Regular Reporting Interval (6.4)

   The protocol allows an exporting process to address this requirement.

3.1.1.5 Notification on Specific Events (6.5)

   This requirement is specified as a MAY and is not addressed by
   Streaming IPDR.

3.1.1.6 Anonymization (6.6)

   The protocol allows an exporting process to address this requirement.

3.1.2 Configuration (7)

3.1.2.1 Configuration of Exporting Process (7.2)

   The Streaming IPDR protocol only addresses the acknowledged one way
   flow of information from the exporting process to the collecting
   process.

   The configuration mechanims of the exporting process is not addressed
   by this proposal.  Configuration models based on SNMP MIBs or command
   line interfaces can be used.

   Additional configuration items introduced by the Streaming IPDR
   Protocol, which should be exposed by the exporting process, include:

      IP Address(es) of the collecting systems.

      Port(s) of the collecting systems.

      Flow buffering properties for reliable delivery:

         maximum buffer size (in # flows) [or no buffering]

         ack interval hint [or trivial]

Meyer                    Expires March 3, 2003                 [Page 11]

Internet-Draft            Streaming IPDR Eval             September 2002

      ack time interval hint

      schema, namespace and type information of flow records

3.1.3 General Requirements (8)

3.1.3.1 Openness (8.1)

   The NDM-U 3.1 specification [6] is publicly available.  It takes the
   approach of leveraging existing standards where applicable.  These
   include the TMF Telecom Operations Map for the reference model, and
   XML [3], XML Namespace, XML Schema [4] and XDR [7] as basis for
   notation, syntax and encoding.

3.1.3.2 Scalability Conerning the number of Exporting Processes (8.2)

   A collecting application can interface with many exporting processes.
   The only limitations are the network, disk and processing throughput
   of the system relative to the flow event rate being presented..

3.1.3.3 Several Collecting Processes (8.3)

   Using several, possibly locally deployed, collecting applications to
   collect from flow exporting systems is a good way to scale
   collection.  Any given collection system is limited by its network,
   disk and processing throughput relative to the flow event rate being
   presented..

3.2 Compliance Table

   The following table summarizes the degree of compliancy using five
   grades:

      -T  Total compliance: The requirement is met completely by the
      protocol specification without any extensions required.

      -E  Extension required for total compliance: The protocol is
      prepared to be extended and it is possible to extend it in a way
      that it meets the requirement.  This grade is only applicable to
      protocols that are explicitly open to externally defined
      extensions, such as SNMP is extended by MIB modules or DIAMETER is
      extended by application modules.  It is not applicable to
      protcols, where the protocol specification itself needs to be
      extended in order to comply with the requirement.

      -P  Partial compliance: The requirement is met partially by the
      protocol specification.

Meyer                    Expires March 3, 2003                 [Page 12]

Internet-Draft            Streaming IPDR Eval             September 2002

      -U  Upcoming compliance: The requirement is not met or met
      partially by the protocol specification, but there is a concrete
      plan for an upcoming version of the protocol.

      -F  Failed compliance: The requirement is not met by the protocol
      specification.

      ----------------------------------------------.
      B: IPFIX Requirement Status                   |
      ----------------------------------------.     |
      A: IPDR Streaming Compliance            |     |
      ----------------------------------.     |     |
                                        |     |     |
      | Sect. |    Requirement          |     |     |
      |-------+-------------------------+-----+------|
      | 6.    | DATA EXPORT                          |
      |-------+-------------------------+-----+------|
      | 6.1.  | INFORMATION MODEL                    |
      |-------+-------------------------+-----+------|
      | 6.1.  | IP Version              |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | src/dst address         |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | transport protocol      |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | src/dst port            |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Packet counter (h)      |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Byte counter            |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Dropped Packet          |  E  |  M   |
      |       | Counter (h,i)           |     |      |
      |-------+-------------------------+-----+------|
      | 6.1.  | ToS Byte                |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Flow Label              |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | BGP AS#                 |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | MPLS label (a)          |  E  |  M   |
      |       |                         |     |      |
      |-------+-------------------------+-----+------|
      | 6.1.  | DSCP (a)                |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Timestamps for          |  E  |  M   |
      |       | first/last packet       |     |      |

Meyer                    Expires March 3, 2003                 [Page 13]

Internet-Draft            Streaming IPDR Eval             September 2002

      |-------+-------------------------+-----+------|
      | 6.1.  | Sampling configuration  |  E  |  M   |
      |-------+-------------------------+-----+------|
      | 6.1.  | observation point       |  E  |  M   |
      |       | identifier              |     |      |
      |-------+-------------------------+-----+------|
      | 6.1.  | export process          |  T  |  M   |
      |       | identifier              |     |      |
      |-------+-------------------------+-----+------|
      | 6.1.  | TTL                     |  E  |  O   |
      |-------+-------------------------+-----+------|
      | 6.1.  | IP header flags         |  E  |  O   |
      |-------+-------------------------+-----+------|
      | 6.1.  | TCP header flags        |  E  |  O   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Fragment counter        |  E  |  O   |
      |-------+-------------------------+-----+------|
      | 6.1.  | Multicast               |  E  |  S   |
      |       | replication factor      |     |      |
      |-------+-------------------------+-----+------|
      | 6.2.  | DATA MODEL                           |
      |-------+-------------------------+-----+------|
      | 6.2.  | Flexibility             |  T  |  O   |
      |-------+-------------------------+-----+------|
      | 6.2.  | Extensibility           |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.3.  | DATA TRANSFER                        |
      |-------+-------------------------+-----+------|
      | 6.3.1.| Congestion aware        |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.3.2.| Reliability             |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.3.3.| Confidentiality         |  T  |  S   |
      |-------+-------------------------+-----+------|
      | 6.3.4.| Integrity               |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.3.5.| Authenticity            |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.4.  | REPORTING TIMES                      |
      |-------+-------------------------+-----+------|
      | 6.4.  | Push mode               |  T  |  M   |
      |-------+-------------------------+-----+------|
      | 6.4.  | Pull mode               |  T  |  O   |
      |       |                         | (a) |      |
      |-------+-------------------------+-----+------|
      | 6.4.1.| Regular Interval        |  T  |  S   |
      |-------+-------------------------+-----+------|
      | 6.6.  | Notifications           |  P  |  O   |

Meyer                    Expires March 3, 2003                 [Page 14]

Internet-Draft            Streaming IPDR Eval             September 2002

      |-------+-------------------------+-----+------|
      | 6.7.  | Anonymization           |  T  |  O   |
      |-------+-------------------------+-----+------|
      | 7.    | CONFIGURATION                        |
      |-------+-------------------------+-----+------|
      | 7.    | Config Measurement      |  T  |  M   |
      |       | & Data Export           |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Observation Point|  T  |  S   |
      |       |                         |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Flow             |  T  |  S   |
      |       | Specifications          |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Flow Timeouts    |  T  |  S   |
      |       |                         |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Sampling         |  T  |  O   |
      |       |                         |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Report           |  T  |  S   |
      |       | Data Format             |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config                  |  T  |  O   |
      |       | Notifications           |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 7.    | Config Anonymization    |  T  |  O   |
      |       |                         |(n/a)|      |
      |-------+-------------------------+-----+------|
      | 8.    | GENERAL REQUIREMENTS                 |
      |-------+-------------------------+-----+------|
      | 8.1.  | Openness                |  T  |  S   |
      |-------+-------------------------+-----+------|
      | 8.2.  | Scalability:            |     |      |
      |       | data collection         |  T  |  M   |
      |       | from hundreds of        |     |      |
      |       | measurement devices     |     |      |
      |-------+-------------------------+-----+------|
      | 8.3.  | Several Collectors      |  T  |  O   |
      |-------+-------------------------+-----+------|

     (a) - The IPDR NDM-U 3.1 specification defines a pull based
       protocol which relies on file transfer.  This protocol
       is not directly advocated in this draft, since the primary
       consideration is push based delivery.

     (n/a) - IPDR defines the transfer protocol between the exporting

Meyer                    Expires March 3, 2003                 [Page 15]

Internet-Draft            Streaming IPDR Eval             September 2002

       and collection process.  The behavior of the exporting process
       is controlled through means such as MIB or command line control,
       not specified by Streaming IPDR.

Meyer                    Expires March 3, 2003                 [Page 16]

Internet-Draft            Streaming IPDR Eval             September 2002

4. Security Considerations

   Security can be accomplished by using either IPSec [9] or TLS [10]
   mechanisms when establishing the underlying TCP connection.  This is
   the same security policy used by Diameter [11], sec (13.1 and 13.2)

   Because the use of IPSec and TLS are transparent to the from the
   perspective of TCP connection endpoints, the protocol specified here
   is unchanged.

Meyer                    Expires March 3, 2003                 [Page 17]

Internet-Draft            Streaming IPDR Eval             September 2002

References

   [1]   Quittek, J., "Requirements for IP Flow Information Export",
         IETF draft work in progress, August 2002, <http://www.ietf.org/
         internet-drafts/draft-ietf-ipfix-reqs-05.txt>.

   [2]   Meyer, J., "Reliable Streaming Internet Protocol Detail
         Records", IETF draft work in progress, August 2002, <http://
         www.ietf.org/internet-drafts/draft-meyer-ipdr-streaming-
         00.txt>.

   [3]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
         xml-19980210>.

   [4]   World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
         XML, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-
         20010502/>.

   [5]   World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
         XML, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-2-
         20010502/datatypes.html>.

   [6]   Internet Protocol Detail Record Organization, "Network Data
         Management - Usage (NDM-U) For IP-Based Services Version 3.1",
         April 2002, <http://www.ipdr.org/documents/NDM-U_3.1.pdf>.

   [7]   Srinivasan, R., "XDR: External Data Representation Standard",
         RFC 2026, August 1995, <http://www.ietf.org/rfc/rfc1832.txt>.

   [8]   Brownlee, N. and A. Blount, "Accounting Attributes and Record
         Formats", RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
         rfc2924.txt>.

   [9]   Kent, S., "Security Architecture for the Internet  Protocol",
         RFC 2401, Nov. 1998, <http://www.ietf.org/rfc/rfc2401.txt>.

   [10]  Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, Jan.
         1999, <http://www.ietf.org/rfc/rfc2246.txt>.

   [11]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
         "Diameter Base Protocol", draft Work in progress, Jul. 2002,
         <http://search.ietf.org/internet-drafts/draft-ietf-aaa-
         diameter-12.txt>.

   [12]  Norseth, K. and P. Calato, "Data Model for IP Flow Information
         Export", IETF draft work in progress, August 2002, <http://
         www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt>.

Meyer                    Expires March 3, 2003                 [Page 18]

Internet-Draft            Streaming IPDR Eval             September 2002

   [13]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
         1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.

Author's Address

   Jeff Meyer
   Hewlett-Packard
   19420 Homestead Rd.
   Cupertino, CA  95014
   US

   Phone: +1 408 447-3477
   EMail: [email-masked]
   URI:   http://www.hp.com

Meyer                    Expires March 3, 2003                 [Page 19]

Internet-Draft            Streaming IPDR Eval             September 2002

Appendix A. IPFIX IPDR Service Definition

   This proposal does not take into consideration possible IANA
   implications.  The use of Namespaces as an extension mechanism
   implies that an IANA registered Namespace URI should be available and
   that directory names below this base URI be assigned for relevant
   IETF specifications.  The author is not aware of this mechanism
   today.  Alternatively IPDR.org could fulfill this role.  The sample
   uses the IPDR.org namespace.

   The naming and content is lifted from the IPFIX Data Definition draft
   [12].

   <schema xmlns:ipdr="http://www.ipdr.org/namespaces/ipdr">

   <annotation>
     <documentation>
     This document defines a subset of the identified IPFIX data
     model as XML Schema elements and complexTypes.  This schema
     definition is compatable with the IPDR Service Definition
     format, enabling flow information to be represented as XML
     or binary documents.  And defines the format used when streaming
     flow information to a recording system.
     </documentation>
   </annotation>

   <element name="sourceAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
      IPv4 source address taken from the packet header.
     </documentation>
   </annotation>
   </element>

   <element name="sourceAddressV6" type="ipdr:ipV6Addr">
   <annotation>
     <documentation>
      IPv6 source address taken from the packet header.
     </documentation>
   </annotation>
   </element>

   <element name="destinationAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>

Meyer                    Expires March 3, 2003                 [Page 20]

Internet-Draft            Streaming IPDR Eval             September 2002

      IPv4 destination address taken from the packet header.
     </documentation>
   </annotation>
   </element>

   <element name="destinationAddressV6" type="ipdr:ipV6Addr">
   <annotation>
     <documentation>
      IPv6 destination address taken from the packet header.
     </documentation>
   </annotation>
   </element>

   <element name="protocolIdentifier" type="int">
   <annotation>
     <documentation>
      Protocol number identified in the IP packet.

      In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,
      called "Protocol", to identify the next level protocol.  This is an 8
      bit field.  In Internet Protocol version 6 (IPv6) [RFC1883] this field
      is called the "Next Header" field.

      These numbers are administered by IANA.
     </documentation>
     <appinfo>
       <ipdr:reference>http://www.iana.org/assignments/protocol-numbers</ipdr:reference>
     </appinfo>
   </annotation>
   </element>

   <element name="sourcePort" type="int">
   <annotation>
     <documentation>
      This information element is used to report  UDP source port [see
      RFC 768] or TCP source port [see RFC 793] as taken from the IP
      header.
     </documentation>
   </annotation>
   </element>

   <element name="destinationPort" type="int">
   <annotation>
     <documentation>
      This information element is used to report  UDP destination port
      [see RFC 768] or TCP destination port [see RFC 793] as taken from

Meyer                    Expires March 3, 2003                 [Page 21]

Internet-Draft            Streaming IPDR Eval             September 2002

      the IP header.
     </documentation>
   </annotation>
   </element>

   <element name="ingressPort" type="int">
   <annotation>
     <documentation>
      The ifIndex where the packets for the flow are being received.
      ifIndex is defined by RFC 2233.
     </documentation>
   </annotation>
   </element>

   <element name="egressPort" type="int">
   <annotation>
     <documentation>
      The ifIndex where the packets for the flow are exiting. ifIndex is
      defined by RFC 2233.
     </documentation>
   </annotation>
   </element>

   <element name="packetCount" type="int">
   <annotation>
     <documentation>
      Contains the count of packets sent and received associated with
      the identified flow.

      The packet count can be for packets received (towards source) or
      packets sent (towards destination) or both (bi-directional flow).

      The packet count can be a running counter and is the count from
      the beginning of the flow establishment.

      The packet count can be a delta counter and is the count since the
      last report for this flow.
     </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
   </annotation>
   </element>

   <element name="byteCount" type="int">
   <annotation>
     <documentation>
      Contains the count of octets sent and received associated with the

Meyer                    Expires March 3, 2003                 [Page 22]

Internet-Draft            Streaming IPDR Eval             September 2002

      identified flow.

      The byte count can be for bytes received (towards source) or bytes
      sent (towards destination) or both (bi-directional flow).

      The byte count can be a running counter and is the count from the
      beginning of the flow establishment.

      The byte count can be a delta counter and is the count since the
      last report for this flow.
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>
   </annotation>
   </element>

   <element name="classOfService" type="int">
   <annotation>
     <documentation>
      The class of service associated with a flow.

      Class of Service Received
      Class of Service Transmitted

         1. IPv4, CoS value is defined by ToS in RFC 791
         2. IPv6, CoS value is defined by Traffic Class in RFC 2460
         3. MPLS, CoS value is defined by Exp in RFC 3032
         4. VLAN, CoS value is defined by user_priority in
            IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]
     </documentation>
   </annotation>
   </element>

   <element name="flowLabel" type="int">
   <annotation>
     <documentation>
      The Flow Label information element contains the IPV6 Flow Label
      information as defined by RFC 2460.
     </documentation>
   </annotation>
   </element>

   <element name="flowCreationTime" type="dateTime">
   <annotation>
     <documentation>
      The timestamp of the first packet of the flow.
     </documentation>

Meyer                    Expires March 3, 2003                 [Page 23]

Internet-Draft            Streaming IPDR Eval             September 2002

   </annotation>
   </element>

   <element name="flowEndTime" type="dateTime">
   <annotation>
     <documentation>
      The timestamp of the last packet of the flow..
     </documentation>
   </annotation>
   </element>

   <element name="sourceAS" type="int">
   <annotation>
     <documentation>
      The Autonomous System (AS) numbers for the source address
      associated with a flow. Autonomous System (AS) number is defined
      by RFC 1930 and RFC 1771 (BGP-4):
     </documentation>
   </annotation>
   </element>

   <element name="destinationAS" type="int">
   <annotation>
     <documentation>
      The Autonomous System (AS) numbers for the destination address
      associated wit a flow. Autonomous System (AS) number is defined by
      RFC 1930 and RFC 1771 (BGP-4).
     </documentation>
   </annotation>
   </element>

   <element name="nextHopAS" type="int">
   <annotation>
     <documentation>
      The Autonomous System (AS) numbers for the next hop IP. Autonomous
      System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).
     </documentation>
   </annotation>
   </element>

   <element name="tcpControlBits" type="int">
   <annotation>
     <documentation>
      The TCP control bits seen for this flow. Note a 0 value for each
      bit only indicates that the flag was not detected (i.e. it may
      have occurred but was not detected by the reporting CCE). TCP
      Control Bits are defined by RFC 793.

Meyer                    Expires March 3, 2003                 [Page 24]

Internet-Draft            Streaming IPDR Eval             September 2002

     </documentation>
   </annotation>
   </element>

   <element name="sourceExporterAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
      Source Exporter address is the address of the Exporter reporting
      the flow, Address is same as is as shown for Source Address. This
      information is used by applications to later correlate the
      ingress/egress port with a specific Exporter. It is also used to
      maintain the source Exporter information when there is an
      intermediate proxy. For example, given the picture below:

                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |

      Flows coming from SW1 and SW2 through proxy P1 would look to the
      Collector [ is this the right term??? PAC]  like the same Exporter
      connection. With the Source Exporter in the message the original
      Exporter  address is maintained.
     </documentation>
   </annotation>
   </element>

   <element name="droppedPacketCount" type="int">
   <annotation>
     <documentation>
      Contains the count of packets dropped at the observation point
      associated with the identified flow.

      The dropped packet count can be a running counter and is the count
      from the beginning of the flow establishment.

      The dropped packet count can be a delta counter and is the count
      since the last report for this flow.
     </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
   </annotation>
   </element>

   <element name="samplingInterval" type="int">
   <annotation>
     <documentation>

Meyer                    Expires March 3, 2003                 [Page 25]

Internet-Draft            Streaming IPDR Eval             September 2002

      When using Sampling, the rate at which packets is sampled. For
      example, a value of 100 indicates that one of every hundred
      packets is sampled.
     </documentation>
   </annotation>
   </element>

   <element name="samplingAlgorithm" type="int">
   <annotation>
     <documentation>
      The type of algorithm used for sampling data. Currently, the only
      sampling algorithm defined  is:
      0x02 packet-sampling
     </documentation>
   </annotation>
   </element>

   <element name="flowEndState" type="int">
   <annotation>
     <documentation>
      The reason the flow has ended.
           1. Inactivity timeout
           2. End of flow detected (e.g. TCP FIN)
           3. Forced end ????
           4. Cache full

      [enumerations in IPDR service def schemas are recommended to be
       of form string, w/ integer values (for Compact format)
       defined via annotation]
     </documentation>
   </annotation>
   </element>

   <element name="droppedByteCount" type="int">
   <annotation>
     <documentation>
      Contains the count of octets dropped at the observation point
      associated with the identified flow.

      The dropped byte count can be a running counter and is the count
      from the beginning of the flow establishment.

      The byte count can be a delta counter and is the count since the
      last report for this flow.
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>

Meyer                    Expires March 3, 2003                 [Page 26]

Internet-Draft            Streaming IPDR Eval             September 2002

   </annotation>
   </element>

   <complexType name="SimpleV4Flow">
     <extension base="ipdr:IPDR">
       <sequence>
         <element ref="sourceAddress" minOccurs="1"/>
         <element ref="destinationAddress" minOccurs="1"/>
         <element ref="protocolIdentifier" minOccurs="1"/>
         <element ref="sourcePort" minOccurs="1"/>
         <element ref="destinationPort" minOccurs="1"/>
         <element ref="ingressPort" minOccurs="1"/>
         <element ref="egressPort" minOccurs="1"/>
         <element ref="packetCount" minOccurs="1"/>
         <element ref="byteCount" minOccurs="1"/>
         <element ref="classOfService" minOccurs="0"/>
         <element ref="flowLabel" minOccurs="0"/>
         <element ref="flowCreationTime" minOccurs="1"/>
         <element ref="flowEndTime" minOccurs="1"/>
         <element ref="tcpControlBits" minOccurs="0"/>
         <element ref="samplingInterval" minOccurs="0"/>
         <element ref="samplingAlgorithm" minOccurs="0"/>
         <element ref="sourceExporterAddress" minOccurs="1"/>
       </sequence>
     </extension>
   </complexType>

   <complexType name="SimpleV6Flow">
     <extension base="ipdr:IPDR">
       <sequence>
         <element ref="sourceAddressV6" minOccurs="1"/>
         <element ref="destinationAddressV6" minOccurs="1"/>
         <element ref="protocolIdentifier" minOccurs="1"/>
         <element ref="sourcePort" minOccurs="1"/>
         <element ref="destinationPort" minOccurs="1"/>
         <element ref="ingressPort" minOccurs="1"/>
         <element ref="egressPort" minOccurs="1"/>
         <element ref="packetCount" minOccurs="1"/>
         <element ref="byteCount" minOccurs="1"/>
         <element ref="classOfService" minOccurs="0"/>
         <element ref="flowLabel" minOccurs="0"/>
         <element ref="flowCreationTime" minOccurs="1"/>
         <element ref="flowEndTime" minOccurs="1"/>
         <element ref="tcpControlBits" minOccurs="0"/>
         <element ref="samplingInterval" minOccurs="0"/>
         <element ref="samplingAlgorithm" minOccurs="0"/>
         <element ref="sourceExporterAddress" minOccurs="1"/>

Meyer                    Expires March 3, 2003                 [Page 27]

Internet-Draft            Streaming IPDR Eval             September 2002

       </sequence>
     </extension>
   </complexType>

   </schema>

Meyer                    Expires March 3, 2003                 [Page 28]

Internet-Draft            Streaming IPDR Eval             September 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Meyer                    Expires March 3, 2003                 [Page 29]