WDIFF

draft-ietf-ipfix-info-00.txt --> draft-ietf-ipfix-info-01.txt

Network Working Group                                          P. Calato
Internet-Draft                                   Riverstone Networks Inc
Expires: December 15, 2003 February 10, 2004                                      J. Meyer
                                                         Hewlett-Packard
                                                              J. Quittek
                                                         NEC Europe Ltd.
                                                           June 16,
                                                         August 12, 2003


            Information Model for IP Flow Information Export
                        draft-ietf-ipfix-info-00
                        draft-ietf-ipfix-info-01

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 December 15, 2003. February 10, 2004.

Copyright Notice

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

Abstract

   This document defines an and information and data model for scalable
   monitoring, measuring and exporting the IP flow Flow
   Information export (IPFIX) protocol. It is used by the IPFIX protocol
   for encoding measured traffic information and information related to
   collectors.
   the traffic measurement process. Although developed for the IPFIX
   protcol, the model is defined in an open way that easily allows using
   it in other protocols, interfaces, and applications.






Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 1]

Internet-Draft          IPFIX Information Model                June              August 2003


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . .   5 .   4
   2.   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   6 .   5
   3.     Definition   Properties of a an IPFIX Flow Attribute  . . . . . . . . . . . . . . . . . . .   7   6
   4.     Properties of an IPFIX Information Element . . . . . . . .   8
   5.   Type Space . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.1 .   8
   4.1  int  . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.2 .   8
   4.2  unsignedInt  . . . . . . . . . . . . . . . . . . . . . . .   9
   5.3 .   8
   4.3  long . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.4 .   8
   4.4  unsignedLong . . . . . . . . . . . . . . . . . . . . . . .   9
   5.5 .   8
   4.5  float  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.6 .   8
   4.6  double . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.7
   4.7  hexBinary  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.8
   4.8  string . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.9 .   9
   4.9  boolean  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.10 .   9
   4.10 byte . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.11 .   9
   4.11 unsignedByte . . . . . . . . . . . . . . . . . . . . . . .  10
   5.12 .   9
   4.12 short  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.13 .   9
   4.13 unsignedShort  . . . . . . . . . . . . . . . . . . . . . .  10
   5.14 .   9
   4.14 dateTime . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.15
   4.15 ipdr:dateTimeMsec  . . . . . . . . . . . . . . . . . . . . .  10
   5.16
   4.16 ipdr:ipV4Addr  . . . . . . . . . . . . . . . . . . . . . .  11
   5.17 .  10
   4.17 ipdr:ipV6Addr  . . . . . . . . . . . . . . . . . . . . . .  11
   5.18 .  10
   4.18 ipdr:UUID  . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.19 .  10
   4.19 ipdr:dateTimeUsec  . . . . . . . . . . . . . . . . . . . . .  11
   6.
   5.   Extending the Information Model  . . . . . . . . . . . . . .  12
   7.     The Benefits of a Formal Machine Readable Information
          Model
   6.   Flow Attributes  . . . . . . . . . . . . . . . . . . . . . .  13
   6.1  sourceAddress  . . . .  13
   8.     Using XML Schema for Information Models . . . . . . . . .  14
   9.     Information Elements . . . . . . . . . .  13
   6.2  sourceAddressV6  . . . . . . . . .  15
   9.1    sourceAddress . . . . . . . . . . . . .  13
   6.3  destinationAddress . . . . . . . . .  15
   9.1.1  Type . . . . . . . . . . . .  13
   6.4  destinationAddressV6 . . . . . . . . . . . . . . .  15
   9.1.2  Field Id . . . . .  13
   6.5  protocolIdentifier . . . . . . . . . . . . . . . . . . . .  15
   9.2    sourceAddressV6 .  13
   6.6  sourcePort . . . . . . . . . . . . . . . . . . . .  15
   9.2.1  Type . . . . .  14
   6.7  destinationPort  . . . . . . . . . . . . . . . . . . . . . .  15
   9.2.2  Field Id  14
   6.8  ingressPort  . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.9  egressPort . .  15
   9.3    destinationAddress . . . . . . . . . . . . . . . . . . . .  15
   9.3.1  Type . . .  15
   6.10 packetCount  . . . . . . . . . . . . . . . . . . . . . . . .  15
   9.3.2  Field Id
   6.11 byteCount  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   9.4    destinationAddressV6 . . .
   6.12 classOfService . . . . . . . . . . . . . . . .  15
   9.4.1  Type . . . . . . .  16
   6.13 flowLabel  . . . . . . . . . . . . . . . . . . . .  15
   9.4.2  Field Id . . . . .  16
   6.14 flowCreationTime . . . . . . . . . . . . . . . . . . . .  15
   9.5    protocolIdentifier . .  16
   6.15 flowEndTime  . . . . . . . . . . . . . . . . . .  16
   9.5.1  Type . . . . . .  17
   6.16 sourceAS . . . . . . . . . . . . . . . . . . . . .  16
   9.5.2  Reference . . . . .  17
   6.17 destinationAS  . . . . . . . . . . . . . . . . . . .  16
   9.5.3  Field Id . . . .  17
   6.18 nextHopAS  . . . . . . . . . . . . . . . . . . . . .  16
   9.6    sourcePort . . . .  17
   6.19 tcpControlBits . . . . . . . . . . . . . . . . . . . .  16



Calato, et al.         Expires December 15, 2003                [Page 2]

Internet-Draft          IPFIX Information Model                June 2003


   9.6.1  Type . . .  18
   6.20 ipV4SourceExporterAddress  . . . . . . . . . . . . . . . . .  18
   6.21 ipV6SourceExporterAddress  . . . . . . .  16
   9.6.2  Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.7    destinationPort  . . . . . . . . . . . . . . . . . . . . .  16
   9.7.1  Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.7.2  Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  17
   9.8    ingressPort  . . . . . . . . . . . . . . . . . . . . . . .  17
   9.8.1  Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   9.8.2  Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  17
   9.9    egressPort . . . . . . . .  18



Calato, et al.         Expires February 10, 2004                [Page 2]

Internet-Draft          IPFIX Information Model              August 2003


   6.22 droppedPacketCount . . . . . . . . . . . . . . . .  17
   9.9.1  Type . . . . .  19
   6.23 samplingInterval . . . . . . . . . . . . . . . . . . . . . .  17
   9.9.2  Field Id  19
   6.24 samplingAlgorithm  . . . . . . . . . . . . . . . . . . . . .  20
   6.25 flowEndState . . . .  17
   9.10   packetCount . . . . . . . . . . . . . . . . . . . .  20
   6.26 droppedByteCount . . .  17
   9.10.1 Type . . . . . . . . . . . . . . . . . . .  20
   7.   The Benefits of a Formal Machine Readable Information
        Model  . . . . . . . .  17
   9.10.2 Units . . . . . . . . . . . . . . . . . . .  21
   8.   Security Considerations  . . . . . . .  18
   9.10.3 Field Id . . . . . . . . . . .  22
        References . . . . . . . . . . . . . .  18
   9.11   byteCount . . . . . . . . . . .  23
        Authors' Addresses . . . . . . . . . . . . .  18
   9.11.1 Type . . . . . . . .  24
   A.   IPFIX IPDR Service Definition  . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . .  18
   9.11.2 Units  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.11.3 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.12   classOfService . . . . . . . . . . . . . . . . . . . . . .  18
   9.12.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.12.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.13   flowLabel  . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.13.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.13.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.14   flowCreationTime . . . . . . . . . . . . . . . . . . . . .  19
   9.14.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.14.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.15   flowEndTime  . . . . . . . . . . . . . . . . . . . . . . .  19
   9.15.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.15.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.16   sourceAS . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.16.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.16.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.17   destinationAS  . . . . . . . . . . . . . . . . . . . . . .  20
   9.17.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.17.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.18   nextHopAS  . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.18.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.18.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.19   tcpControlBits . . . . . . . . . . . . . . . . . . . . . .  20
   9.19.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.19.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.20   sourceExporterAddress  . . . . . . . . . . . . . . . . . .  21
   9.20.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.20.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.21   droppedPacketCount . . . . . . . . . . . . . . . . . . . .  21
   9.21.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  22



Calato, et al.         Expires December 15, 2003                [Page 3]

Internet-Draft          IPFIX Information Model                June 2003


   9.21.2 Units  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.21.3 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.22   samplingInterval . . . . . . . . . . . . . . . . . . . . .  22
   9.22.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.22.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.23   samplingAlgorithm  . . . . . . . . . . . . . . . . . . . .  22
   9.23.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.23.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.24   flowEndState . . . . . . . . . . . . . . . . . . . . . . .  22
   9.24.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.24.2 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.25   droppedByteCount . . . . . . . . . . . . . . . . . . . . .  23
   9.25.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.25.2 Units  . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.25.3 Field Id . . . . . . . . . . . . . . . . . . . . . . . . .  23
          References . . . . . . . . . . . . . . . . . . . . . . . .  24
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  25
   A.     IPFIX IPDR Service Definition  . . . . . . . . . . . . . .  26
          Intellectual Property and Copyright Statements . . . . . .  36







































Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 4] 3]

Internet-Draft          IPFIX Information Model                June              August 2003


1. Introduction

   Many applications e.g., Intrusion intrusion detection, traffic engineering, and
   accounting among others require the monitoring, measuring of IP
   traffic flows. It is hence important to have a standard way of
   exporting information related to IP flows. This document defines the
   base set of data items attributes which may be used by the exporter
   for when exporting IP traffic flow monitoring and measuring.
   information. It also defines the mechanism by which new data items
   may be added without changing the underlying exchange protocol.










































Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 5] 4]

Internet-Draft          IPFIX Information Model                June              August 2003


2. Scope

   This document defines an information data model for IPFIX-Requirements
   [1]Specifically, this document describes a general purpose flow
   definition along with the data elements which may be exported.














































Calato, et al.         Expires December 15, 2003                [Page 6]

Internet-Draft          IPFIX Information Model                June 2003


3. Definition of a IP Flow

   As defined in the requirement draft IPFIX-Requirements [1]

   . A flow is a set of packets passing an observation point in the
   network during a certain time interval. All packets belonging to a
   particular flow have a set
   Information eXport (IPFIX) protocol. The model consists of common properties derived from the data
   contained in the packet and from the packet treatment at the
   observation point.

   In this document we define the flow more specifically. A flow is
   defined as a set of packets passing an observation point in the
   network during a certain time interval. All packets belonging to a
   particular flow have a set
   of common properties.

   Each property is defined as the result of applying a function to the
   values of: A. one or more of packet header fields (e.g. destination
   IP address) B. one or more properties of the packet itself (e.g.
   packet length) C. information elements, each one or more of fields derived from packet treatment
   (e.g. AS number) A packet is defined to belong to a flow if it
   matches all the defined properties defining a single attribute of the a
   flow. Flows can be defined
   in multiple ways. For each individual attribute, the semantics is clearly
   specified and a data type is assigned to it.












































Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 7] 5]

Internet-Draft          IPFIX Information Model                June              August 2003


4.


3. Properties of an IPFIX Information Element Flow Attribute

   Flow attributes are modeled as information elements of the IPFIX
   information model. Each information element models a single flow
   attribute.

   For defining flow attributes, a template is used.

   Information elements defined in this specification, or by extension
   MUST have the following properties defined:

      Name - a unique and meaningful name for the field. The preferred
      spelling for the name is to use mixed case if the name is
      compound, with an initial lower case letter. (E.g.
      "sourceAddress").
      "sourceIpAddress").

      Description - the semantics of this information element. Describes
      how this field is derived from the flow or other information
      available to the observer.

      Type - one of the types listed in the typespace following section, "The Type
      Space". The type space for attributes is constrained to facilitate
      implementation. The existing typespace type space does however encompass
      most basic types used in modern programming languages, as well as
      some derived types (such as IPAddress) which are common to this
      domain and useful to distinguish.

      FieldId - a numeric identifier administered by IANA. This is used
      for compact identification of an information item when encoding
      templates in the protocol.

   Information elements defined in this specification, or by extension
   MAY have the following properties defined:

      Vendor ID - when extension is done outside of the scope of the
      IANA IPFIX fieldId range, a vendorId MUST be provided.  This
      identifier is based on IANA assigned enterprise identifiers.

      Reference - identifies additional specifications which more
      precisely define this item or provide additional context for its
      use.

      Units - if the field is a measure of some kind, the units identify
      what the measure is.

      Enumerated range - some items may have a specific set of numeric
      identifiers associated with a set of discrete values this element
      may take.  The meaning of each discrete value and a human readable



Calato, et al.         Expires February 10, 2004                [Page 6]

Internet-Draft          IPFIX Information Model              August 2003


      name should be assigned.

      Range - some elements may only be able to take on a restricted set
      of values which can be expressed as a range (e.g. 0 through 511
      inclusive). If this is the case, the valid inclusive range should
      be specified.













































Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 8] 7]

Internet-Draft          IPFIX Information Model                June              August 2003


5.


4. Type Space

   The following subsections describe the basic types from which most the
   types of all IPFIX information elements attributes should be constructed.

   By describing Information Elements attributs in terms of a well defined type space, versus
   describing these details in each Element element declaration, greater
   consistency of the existing Information Model information model is expected. This
   should also simplify the process of extending the Information
   Model information model
   over time, and maintain this consistency.

5.1 int

   The type "int" represents a integer numeric value in the range of
   -2147483648

   Still any attribute is free to 2147483647. (i.e. a 32-bit integer)

5.2 unsignedInt

   The type "unsignedInt" represents an integer value in restrict the range of 0
   to 4294967295. (i.e. a 32-bit unsigned integer)

5.3 long

   The type "long" represents an integer value in the range of
   9223372036854775807 assigned to -9223372036854775808. (i.e. a 64-bit integer)

5.4 unsignedLong

   The type "unsignedLong" represents an integer value in it
   further than the range of 0
   to 18446744073709551615. (i.e. a 64-bit unsigned integer)

5.5 float

   The type "float" corresponds to an IEEE single-precision 32-bit
   floating point type.

5.6 double

   The double datatype corresponds to IEEE double-precision 64-bit
   floating point type

5.7 hexBinary

   The general type "hexBinary" represents description in this section does.

   Please note that a finite length string protocol implementation may use other types as
   long as each of octets.
   Note the name reflects types defined below are supported with their
   entire range. For example, the mechanism used in XML documents to
   represent type short can be encoded within the value using ASCII characters.





Calato, et al.         Expires December 15, 2003                [Page 9]

Internet-Draft          IPFIX Information Model                June 2003


5.8 string
   type long.

   The type "string" represents a finite length string of valid
   characters names used are copied from the Unicode character encoding set. Unicode allows
   for ASCII and many other international character sets namespace defined by
   XML-Schema Datatypes.  There are a few types which are useful to be used. It
   is expected that strings will be encoded
   distinguish in UTF-8 format, the context of IPFIX, which is
   identical do not exist in encoding for USASCII characters, but also accomodates
   other Unicode multibyte characters.

5.9 boolean the
   XML-Schema namespace.  The type "boolean" represents extensions used by IPDR.org's NDM-U
   Specification, addresses these gaps and is called out in the values for binary logic. (i.e.
   "true/false" or "1/0").

5.10 byte list
   with the "ipdr:" namespace qualifier.

4.1 int

   The type "byte" "int" represents a integer numeric value in the range of
   -128
   -2147483648 to 127. 2147483647. (i.e. an 8-bit a 32-bit integer)

5.11 unsignedByte

4.2 unsignedInt

   The type "unsignedByte" "unsignedInt" represents a non-negative an integer numeric value in the range of 0
   to 255. 4294967295. (i.e. an 8-bit a 32-bit unsigned integer)

5.12 short

4.3 long

   The type "short" "long" represents a integer numeric value in the range of
   32767 to 32768. (i.e. an 16-bit integer)

5.13 unsignedShort

   The type "unsignedShort" represents a non-negative integer numeric value in the range of 0
   9223372036854775807 to 65535. -9223372036854775808. (i.e. an 16-bit unsigned integer)

5.14 dateTime

   The "dateTime" type represents a specific instant of time. It is
   further restricted from the basic XML dateTime type to having a
   precision of seconds and normalized to the GMT timezone. Such types
   are in common use on many Operating Systems and have the advantage
   that they can be stored in 32-bit integers.

5.15 ipdr:dateTimeMsec

   The "dateTimeMsec" type is defined in the IPDR namespace. It
   represents a specific instant of time. It is further restricted from
   the basic XML dateTime 64-bit integer)

4.4 unsignedLong

   The type to having a precision "unsignedLong" represents an integer value in the range of milliseconds and
   normalized 0
   to the GMT timezone. 18446744073709551615. (i.e. a 64-bit unsigned integer)

4.5 float




Calato, et al.         Expires December 15, 2003 February 10, 2004                [Page 10] 8]

Internet-Draft          IPFIX Information Model                June              August 2003


   Such types are in common use on many Operating Systems and have the
   advantage that they can be stored in 64-bit integers.

5.16 ipdr:ipV4Addr


   The "ipV4Addr" type indicates the value is "float" corresponds to an IP version 4 address.
   These addresses are typically stored as IEEE single-precision 32-bit integers on systems.

5.17 ipdr:ipV6Addr
   floating point type.

4.6 double

   The "ipV6Addr" double datatype corresponds to IEEE double-precision 64-bit
   floating point type indicates the value is an IP version 6 address.
   IPv6 addresses are 16 byte octet strings.

5.18 ipdr:UUID

4.7 hexBinary

   The "UUID" type "hexBinary" represents a universal unique id as defined in finite length string of octets.
   Note the
   OSF specification for Distributed Computing Environment (DCE). It's
   definition can be found in name reflects the OSF CAE Specification, Document C706,
   1997, Appendix A, located at: http://www.opengroup.org/onlinepubs/
   009629399/

   UUIDs are equivalent to Globally Unique Identifiers (GUIDs) mechanism used by
   Microsoft.

   UUIDs are 16 byte quantities which are generated in such a way that
   systems can independently generate their values, but still have XML documents to
   represent the value using ASCII characters.

4.8 string

   The type "string" represents a
   guarantee of global uniqueness finite length string of valid
   characters from the generated value.

   UUID's are typically written Unicode character encoding set. Unicode allows
   for ASCII and many other international character sets to be used. It
   is expected that strings will be encoded in the form
   f81d4fae-7dec-11d0-a765-00a0c91e6bf6. Which merely shows UTF-8 format, which is
   identical in
   hexadecimal encoding for USASCII characters, but also accomodates
   other Unicode multibyte characters.

4.9 boolean

   The type "boolean" represents the 16 values for binary logic. (i.e.
   "true/false" or "1/0").

4.10 byte value. Separators are introduced to segment
   the hex

   The type "byte" represents a integer numeric value into groupings of 4, 2, 2, 2 and 6 bytes.

   An open source C implementation of UUID generation is available in the appendix range of the IETF draft, draftleach-uuids-guids-01.txt. This
   draft has expired, but
   -128 to 127. (i.e. an archived copy is available at: http://
   www.ipdr.org/public/draft-leach-uuids-guids-01.txt

   Note: 8-bit integer)

4.11 unsignedByte

   The type "unsignedByte" represents a non-negative integer numeric
   value in the IETF draft was allowed range of 0 to expire because the group
   considered the OSF work 255. (i.e. an 8-bit unsigned integer)

4.12 short

   The type "short" represents a referenceable standard and did not chose integer numeric value in the range of
   32767 to
   duplicate it.

5.19 ipdr:dateTimeUsec 32768. (i.e. an 16-bit integer)

4.13 unsignedShort

   The dateTimeUsec type is defined "unsignedShort" represents a non-negative integer numeric
   value in the IPDR namespace. It range of 0 to 65535. (i.e. an 16-bit unsigned integer)




Calato, et al.         Expires February 10, 2004                [Page 9]

Internet-Draft          IPFIX Information Model              August 2003


4.14 dateTime

   The "dateTime" type represents a specific instant of time. It is
   further restricted from the basic XML dateTime type to having a
   precision of microseconds seconds and normalized to the GMT timezone.



Calato, et al.         Expires December 15, 2003               [Page 11]

Internet-Draft          IPFIX Information Model                June 2003


6. Extending the Information Model

   A key requirement for IPFIX is to allow for extending the set of
   information items which Such types
   are reported for flows. This section defines in common use on many Operating Systems and have the mechanism for extending this set. advantage
   that they can be stored in 32-bit integers.

4.15 ipdr:dateTimeMsec

   The IPFIX protocol carries flow records "dateTimeMsec" type is defined by in the IPDR namespace. It
   represents a template.
   Multiple templates may be defined for specific instant of time. It is further restricted from
   the basic XML dateTime type to having a dialog between an exporter precision of milliseconds and a collector. A given template identifies
   normalized to the information items GMT timezone.

   Such types are in common use on many Operating Systems and their order. The means of identification of information items have the
   advantage that they can be stored in
   a template 64-bit integers.

4.16 ipdr:ipV4Addr

   The "ipV4Addr" type indicates the value is via a field ID. Field Id's an IP version 4 address.
   These addresses are unique identifiers
   administered by IANA (ed. ? true for vendor specific fields?).

   Extension is done by defining new Information elements, including typically stored as 32-bit integers on systems.

4.17 ipdr:ipV6Addr

   The "ipV6Addr" type indicates the
   set value is an IP version 6 address.
   IPv6 addresses are octet strings of necessary information and possibly additional optional
   information for each element. Each new information item MUST be
   assigned length 16.

4.18 ipdr:UUID

   The "UUID" type represents a universal unique fieldId id as part defined in the
   OSF specification for Distributed Computing Environment (DCE). It's
   definition can be found in the OSF CAE Specification, Document C706,
   1997, Appendix A, located at: http://www.opengroup.org/onlinepubs/
   009629399/

   UUIDs are equivalent to Globally Unique Identifiers (GUIDs) used by
   Microsoft.

   UUIDs are 16 byte quantities which are generated in such a way that
   systems can independently generate their values, but still have a
   guarantee of its definition. These unique
   flow ids global uniqueness of the generated value.

   UUID's are typically written in the connection between form
   f81d4fae-7dec-11d0-a765-00a0c91e6bf6. Which merely shows in
   hexadecimal the record structure communicated
   by 16 byte value. Separators are introduced to segment
   the protocol using templates hex value into groupings of 4, 2, 2, 2 and a consuming application. 6 bytes.




Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 12] 10]

Internet-Draft          IPFIX Information Model                June              August 2003


7. The Benefits


   An open source C implementation of a Formal Machine Readable Information Model

   Appendix A. expresses UUID generation is available in
   the IPFIX Information model as appendix of the IETF draft, draftleach-uuids-guids-01.txt. This
   draft has expired, but an XML-Schema.
   Using archived copy is available at: http://
   www.ipdr.org/public/draft-leach-uuids-guids-01.txt

   Note: the IETF draft was allowed to expire because the group
   considered the OSF work a formal referenceable standard and machine readable syntax for the Information model
   enables did not chose to
   duplicate it.

4.19 ipdr:dateTimeUsec

   The dateTimeUsec type is defined in the creation IPDR namespace. It represents
   a specific instant of IPFIX aware tools which can automatically
   adapt time. It is further restricted from the basic
   XML dateTime type to extensions having a precision of microseconds and
   normalized to the information model, by simply reading
   updated information model specifications. GMT timezone.




































Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 13] 11]

Internet-Draft          IPFIX Information Model                June              August 2003


8. Using XML Schema for Information Models

   The use of XML-Schema as


5. Extending the formal specification language Information Model

   A key requirement for IPFIX is modeled
   after the techniques employed by to allow for extending the IPDR NDM-U specification.

   The wide availability set of XML aware tools is a primary consideration
   for this choice.  In particular libraries for parsing XML documents
   information items which are readily available. Also mechanisms such as the Extensible
   Stylesheet Language (XSL) allow reported for flows. This section defines
   the mechanism for transforming extending this set.

   The IPFIX protocol carries flow records defined by a source XML
   document into other documents.  This draft was initially authored in
   XML and transformed according to RFC2629.

   It should template.
   Multiple templates may be noted that defined for a dialog between an exporter
   and a collector. A given template identifies the use information items
   and their order. The means of XML processors identification of information items in
   a template is not mandatory via a field ID. Field Id's are unique identifiers
   administered by IANA (ed. ? true for vendor specific fields?).

   Extension is done by defining new Information elements, including the deployment
   set of IPFIX.  In particular exporting processes which
   may run on constrained platforms do not produce or consume XML necessary information and possibly additional optional
   information for each element. Each new information item MUST be
   assigned a unique fieldId as part of their operation.  It is expected that IPFIX collectors MAY
   take advantage of its definition. These unique
   field ids are the machine readability of connection between the Information Model
   vs. hardcoding their behavior or inventing proprietary means for
   accomodating extensions. record structure
   communicated by the protocol using templates and a consuming
   application.































Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 14] 12]

Internet-Draft          IPFIX Information Model                June              August 2003


9. Information Elements

9.1


6. Flow Attributes

6.1 sourceAddress

   Description:

   IPv4 source address taken from the packet header.

9.1.1 Type

   Type:  The sourceAddress element is of type ipdr:ipV4Addr.

9.1.2

   Field Id

   The field id is 8.

9.2 Id:  8

6.2 sourceAddressV6

   Description:

   IPv6 source address taken from the packet header.

9.2.1 Type

   Type:  The sourceAddressV6 element is of type ipdr:ipV6Addr.

9.2.2

   Field Id

   The field id is 27.

9.3 Id:  27

6.3 destinationAddress

   Description:

   IPv4 destination address taken from the packet header.

9.3.1 Type

   Type:  The destinationAddress element is of type ipdr:ipV4Addr.

9.3.2

   Field Id

   The field id is 12.

9.4 Id:  12

6.4 destinationAddressV6

   Description:

   IPv6 destination address taken from the packet header.

9.4.1 Type

   Type:  The destinationAddressV6 element is of type ipdr:ipV6Addr.

9.4.2

   Field Id Id:  28

6.5 protocolIdentifier

   Description:

   Protocol number identified in the IP packet.




Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 15] 13]

Internet-Draft          IPFIX Information Model                June              August 2003


   The field id is 28.

9.5 protocolIdentifier

   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.

9.5.1 Type

   Type:  The protocolIdentifier element is of type int.

9.5.2 Reference

   Reference:  Additional information on this element can be found at http://
   www.iana.org/assignments/protocol-numbers.

9.5.3
   http://www.iana.org/assignments/protocol-numbers.

   Field Id

   The field id is 4.

9.6 Id:  4

6.6 sourcePort

   Description:

   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.

9.6.1 Type

   Type:  The sourcePort element is of type unsignedShort.

9.6.2

   Field Id

   The field id is 7.

9.7 Id:  7

6.7 destinationPort

   Description:

   This information element is used to report  UDP destination port [see
   RFC 768] or TCP destination port [see RFC 793] as taken from the IP
   header.

9.7.1 Type

   Type:  The destinationPort element is of type unsignedShort.



Calato, et al.         Expires December 15, 2003               [Page 16]

Internet-Draft          IPFIX Information Model                June 2003


9.7.2

   Field Id

   The field id is 11.

9.8 Id:  11

6.8 ingressPort

   Description:

   The ifIndex where the packets for the flow are being received.
   ifIndex is defined by RFC 2233.

9.8.1 Type

   Type:  The ingressPort element is of type unsignedShort.

9.8.2

   Field Id

   The field id is 10.

9.9 Id:  10




Calato, et al.         Expires February 10, 2004               [Page 14]

Internet-Draft          IPFIX Information Model              August 2003


6.9 egressPort

   Description:

   The ifIndex where the packets for the flow are exiting. ifIndex is
   defined by RFC 2233.

9.9.1 Type

   Type:  The egressPort element is of type unsignedShort.

9.9.2

   Field Id

   The field id is 14.

9.10 Id:  14

6.10 packetCount

   Description:

   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.

9.10.1 Type

   Type:  The packetCount element is of type int.




Calato, et al.         Expires December 15, 2003               [Page 17]

Internet-Draft          IPFIX Information Model                June 2003


9.10.2 Units

   Units:  The unit of measure is  packets.

9.10.3

   Field Id

   The field id is 11.

9.11 Id:  2

6.11 byteCount

   Description:

   Contains the count of octets sent and received associated with the
   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.

9.11.1 Type



Calato, et al.         Expires February 10, 2004               [Page 15]

Internet-Draft          IPFIX Information Model              August 2003


   Type:  The byteCount element is of type int.

9.11.2 Units

   Units:  The unit of measure is  bytes.

9.11.3

   Field Id

   The field id is 1.

9.12 Id:  1

6.12 classOfService

   Description:

   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]





Calato, et al.         Expires December 15, 2003               [Page 18]

Internet-Draft          IPFIX Information Model                June 2003


9.12.1 Type

   Type:  The classOfService element is of type byte.

9.12.2

   Field Id

   The field id is 5.

9.13 Id:  5

6.13 flowLabel

   Description:

   The Flow Label information element contains the IPV6 Flow Label
   information as defined by RFC 2460.

9.13.1 Type

   Type:  The flowLabel element is of type int.

9.13.2

   Field Id

   The field id is 31.

9.14 Id:  31

6.14 flowCreationTime

   Description:

   The timestamp of the first packet of the flow.  (Ed. note:  current
   NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
   an info model perspective, an artifact (and an annoying one from a
   consumer perspective) of the protocol implementation details. How to
   address?)

9.14.1 Type

   Type:  The flowCreationTime element is of type dateTime.

9.14.2




Calato, et al.         Expires February 10, 2004               [Page 16]

Internet-Draft          IPFIX Information Model              August 2003


   Field Id

   The field id is 21.

9.15 Id:  21

6.15 flowEndTime

   Description:

   The timestamp of the last packet of the flow.  (Ed. note:  current
   NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
   an info model perspective, an artifact (and an annoying one from a
   consumer perspective) of the protocol implementation details. How to
   address?)

9.15.1 Type

   Type:  The flowEndTime element is of type dateTime.



Calato, et al.         Expires December 15, 2003               [Page 19]

Internet-Draft          IPFIX Information Model                June 2003


9.15.2

   Field Id

   The field id is 22.

9.16 Id:  22

6.16 sourceAS

   Description:

   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):

9.16.1 Type

   Type:  The sourceAS element is of type int.

9.16.2

   Field Id

   The field id is 16.

9.17 Id:  16

6.17 destinationAS

   Description:

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

9.17.1 Type

   Type:  The destinationAS element is of type int.

9.17.2

   Field Id

   The field id is 17.

9.18 Id:  17

6.18 nextHopAS

   Description:

   The Autonomous System (AS) numbers for the next hop IP. Autonomous
   System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).

9.18.1 Type

   Type:  The nextHopAS element is of type int.

9.18.2



Calato, et al.         Expires February 10, 2004               [Page 17]

Internet-Draft          IPFIX Information Model              August 2003


   Field Id

   The field id is -1.

9.19 Id:  -1

6.19 tcpControlBits

   Description:

   The TCP control bits seen for this flow. Note a 0 value for each bit



Calato, et al.         Expires December 15, 2003               [Page 20]

Internet-Draft          IPFIX Information Model                June 2003
   only indicates that the flag was not detected (i.e. it may have
   occurred but was not detected by 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.

   Type:  The tcpControlBits element is of type int.

   Field Id:  6

6.20 ipV4SourceExporterAddress

   Description:

   The IPV4 address of the Exporter reporting the flow. 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 reporting CCE). TCP Control Bits
   are defined by RFC 793.

9.19.1 Type picture below:



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

   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector like the same Exporter connection. With the Source Exporter
   in the message the original Exporter  address is maintained.

   Type:  The tcpControlBits ipV4SourceExporterAddress element is of type int.

9.19.2
   ipdr:ipV4Addr.

   Field Id Id:  -1

6.21 ipV6SourceExporterAddress

   Description:

   The field id is 6.

9.20 sourceExporterAddress

   Source Exporter address is the IPv4 address of the Exporter reporting  the
   flow, Address is same as is as shown for Source Address. flow. This
   information is used by applications to later correlate the ingress/
   egress port with a specific Exporter. It is also used to maintain the



Calato, et al.         Expires February 10, 2004               [Page 18]

Internet-Draft          IPFIX Information Model              August 2003


   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.

9.20.1 Type

   Type:  The ipV6SourceExporterAddress element is of type
   ipdr:ipV6Addr.

   Field Id:  -1

6.22 droppedPacketCount

   Description:

   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.

   Type:  The droppedPacketCount element is of type int.

   Units:  The unit of measure is  packets.

   Field Id:  -1

6.23 samplingInterval

   Description:

   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.

   Type:  The samplingInterval element is of type int.




Calato, et al.         Expires February 10, 2004               [Page 19]

Internet-Draft          IPFIX Information Model              August 2003


   Field Id:  34

6.24 samplingAlgorithm

   Description:

   The type of algorithm used for sampling data. Currently, the only
   sampling algorithm defined  is: 0x02 packet-sampling

   Type:  The sourceExporterAddress samplingAlgorithm element is of type ipdr:ipV4Addr.

9.20.2 int.

   Field Id Id:  35

6.25 flowEndState

   Description:

   The field id 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]

   Type:  The flowEndState element is -1.

9.21 droppedPacketCount of type int.

   Field Id:  -1

6.26 droppedByteCount

   Description:

   Contains the count of packets octets dropped at the observation point
   associated with the identified flow.

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



Calato, et al.         Expires December 15, 2003               [Page 21]

Internet-Draft          IPFIX Information Model                June 2003

   The dropped packet byte count can be a delta counter and is the count since the last
   report for this flow.

9.21.1 Type

   Type:  The droppedPacketCount droppedByteCount element is of type int.

9.21.2 Units

   Units:  The unit of measure is  packets.

9.21.3  bytes.

   Field Id Id:  -1






Calato, et al.         Expires February 10, 2004               [Page 20]

Internet-Draft          IPFIX Information Model              August 2003


7. The field id is -1.

9.22 samplingInterval

   When using Sampling, Benefits of a Formal Machine Readable Information Model

   Appendix A. expresses the rate at which packets is sampled. For
   example, IPFIX Information model as an XML-Schema.
   Using a value formal and machine readable syntax for the Information model
   enables the creation of 100 indicates that one IPFIX aware tools which can automatically
   adapt to extensions to the information model, by simply reading
   updated information model specifications.

   The use of every hundred packets XML-Schema as the formal specification language is sampled.

9.22.1 Type modeled
   after the techniques employed by the IPDR NDM-U specification.

   The samplingInterval element wide availability of XML aware tools and libraries for client
   devices is a primary consideration for this choice.  In particular
   libraries for parsing XML documents are readily available.  Also
   mechanisms such as the Extensible Stylesheet Language (XSL) allow for
   transforming a source XML document into other documents.  This draft
   was initially authored in XML and transformed according to RFC2629.

   It should be noted that the use of type int.

9.22.2 Field Id

   The field id XML in exporters, collectors or
   other tools is 34.

9.23 samplingAlgorithm

   The type of algorithm used not mandatory for sampling data. Currently, the only
   sampling algorithm defined  is: 0x02 packet-sampling

9.23.1 Type

   The samplingAlgorithm element is deployment of type int.

9.23.2 Field Id

   The field id IPFIX.  In
   particular exporting processes do not produce or consume XML as part
   of their operation.  It is 35.

9.24 flowEndState

   The reason the flow has ended. 1. Inactivity timeout 2. End expected that IPFIX collectors MAY take
   advantage of flow
   detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full
   [enumerations in IPDR service def schemas are recommended to be the machine readability of
   form string, w/ integer values (for Compact format) defined via the Information Model vs.
   hardcoding their behavior or inventing proprietary means for
   accomodating extensions.


























Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 22] 21]

Internet-Draft          IPFIX Information Model                June              August 2003


   annotation]

9.24.1 Type


8. Security Considerations

   The flowEndState element is IPFIX information model itself does not directly introduce
   security issues. Rather it defines a set of type int.

9.24.2 Field Id attributes which may for
   privacy or business issues be considered sensitive information.

   The field id is -1.

9.25 droppedByteCount

   Contains the count of octets dropped at underlying protocol used to exchange the observation point
   associated with information described
   here must therefor apply appropriate procedures to guarantee the identified flow.

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

   The byte count can be a delta counter and is the count since exported information.  Such
   protocols are defined in separate documents. Specifically the last
   report for this flow.

9.25.1 Type

   The droppedByteCount element is of type int.

9.25.2 Units

   The unit of measure is  bytes.

9.25.3 Field Id

   The field id is -1. IPFIX
   Protocol document.








































Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 23] 22]

Internet-Draft          IPFIX Information Model                June              August 2003


References

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

   [2]   Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow
         Information Export", IETF draft work in progress, June 2002, 2003,
         <http://www.ietf.org/internet-drafts/
         draft-ietf-ipfix-arch-00.txt>.
         draft-ietf-ipfix-arch-01.txt>.

   [3]   Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX
         Applicability", IETF draft work in progress, June 2003, <http:/
         /www.ietf.org/internet-drafts/draft-ietf-ipfix-as-00.txt>.

   [4]   Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX
         Protocol Specification", IETF draft work in progress, June
         2003, <http://www.ietf.org/internet-drafts/
         draft-ietf-ipfix-protocol-00.txt>.

   [5]   Claise, B., "Cisco Systems NetFlow Services Export Version 9",
         IETF draft work in progress, June 2003, <http://www.ietf.org/
         internet-drafts/draft-claise-netflow-9-02.txt>.

   [4]

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

   [5]

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

   [6]

   [8]   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>.

   [7]

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

   [8]

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

   [9]

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

   [10]




Calato, et al.         Expires February 10, 2004               [Page 23]

Internet-Draft          IPFIX Information Model              August 2003


   [12]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
         Use of Extensible Markup Language (XML) within IETF Protocols",
         RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.

   [11]

   [13]  Pras, A. and J. Schoenwaelder, "Guidelines for "On the Use of
         Extensible Markup Language (XML) within IETF Protocols", Difference between
         Information Models and Data Models", RFC 3444, January 2003,
         <http://www.ietf.org/rfc/rfc3444.txt>.





Calato, et al.         Expires December 15, 2003               [Page 24]

Internet-Draft          IPFIX Information Model                June 2003


Authors' Addresses

   Paul Calato
   Riverstone Networks Inc
   5200 Great America Parkway
   Santa Clara, CA  95054
   US

   Phone: +1 603 557-6913
   EMail: calato@riverstonenet.com
   URI:   http://www.riverstonenet.com


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

   Phone: +1 408 447-3477
   EMail: jeff.meyer2@hp.com
   URI:   http://www.hp.com


   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de
   URI:   http://www.neceurope.com/









Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 25] 24]

Internet-Draft          IPFIX Information Model                June              August 2003


Appendix A. IPFIX IPDR Service Definition

   This proposal does not currently address possible IANA implications
   associated with XML Namespace URIs. 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 normative status of this appendix versus the section "Flow
   Attributes" is a point of discussion.  The "Flow Attributes" section
   is simply machine generated from the formal XML document below.  As
   such using the formal XML document would seem preferable.  However
   historical conventions and IETF's overall level of XML adoption may
   lead to selection of the human readable text in the "Flow Attributes"
   section as being preferable as normative.



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

   <annotation>
     <documentation>
     <t>
     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.
     </t>
     </documentation>
   </annotation>


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



Calato, et al.         Expires February 10, 2004               [Page 25]

Internet-Draft          IPFIX Information Model              August 2003


   </element>


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



Calato, et al.         Expires December 15, 2003               [Page 26]

Internet-Draft          IPFIX Information Model                June 2003
     </documentation>
     <appinfo>
       <ipfix:fieldId>27</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>


   <element name="destinationAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
     <t>
      IPv4 destination address taken from the packet header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>12</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>


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


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



Calato, et al.         Expires February 10, 2004               [Page 26]

Internet-Draft          IPFIX Information Model              August 2003


      <t>
      Protocol number identified in the IP packet.
      </t><t>
      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.
      </t><t>
      These numbers are administered by IANA.



Calato, et al.         Expires December 15, 2003               [Page 27]

Internet-Draft          IPFIX Information Model                June 2003
      </t>
     </documentation>
     <appinfo>
       <ipdr:reference>http://www.iana.org/assignments/protocol-numbers</ipdr:reference>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>4</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="sourcePort" type="unsignedShort">
   <annotation>
     <documentation>
     <t>
      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.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>7</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="destinationPort" type="unsignedShort">
   <annotation>
     <documentation>
     <t>
      This information element is used to report  UDP destination port
      [see RFC 768] or TCP destination port [see RFC 793] as taken from
      the IP header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>11</ipfix:fieldId>
     </appinfo>
   </annotation>



Calato, et al.         Expires February 10, 2004               [Page 27]

Internet-Draft          IPFIX Information Model              August 2003


   </element>

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



Calato, et al.         Expires December 15, 2003               [Page 28]

Internet-Draft          IPFIX Information Model                June 2003
     </documentation>
     <appinfo>
       <ipfix:fieldId>10</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="egressPort" type="unsignedShort">
   <annotation>
     <documentation>
     <t>
      The ifIndex where the packets for the flow are exiting. ifIndex is
      defined by RFC 2233.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>14</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="packetCount" type="int">
   <annotation>
     <documentation>
     <t>
      Contains the count of packets sent and received associated with
      the identified flow.
     </t><t>
      The packet count can be for packets received (towards source) or
      packets sent (towards destination) or both (bi-directional flow).
     </t><t>
      The packet count can be a running counter and is the count from
      the beginning of the flow establishment.
     </t><t>
      The packet count can be a delta counter and is the count since the
      last report for this flow.
     </t>
     </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>11</ipfix:fieldId>
     </appinfo>2</annotation>
   </element>

   <element name="byteCount" type="int">
   <annotation>
     <documentation>
      <t>



Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 29] 28]

Internet-Draft          IPFIX Information Model                June              August 2003


     <appinfo>
       <ipfix:fieldId>2</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="byteCount" type="int">
   <annotation>
     <documentation>
      <t>
      Contains the count of octets sent and received associated with the
      identified flow.
      </t><t>
      The byte count can be for bytes received (towards source) or bytes
      sent (towards destination) or both (bi-directional flow).
      </t><t>
      The byte count can be a running counter and is the count from the
      beginning of the flow establishment.
      </t><t>
      The byte count can be a delta counter and is the count since the
      last report for this flow.
      </t>
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>1</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="classOfService" type="byte">
   <annotation>
     <documentation>
      <t>
      The class of service associated with a flow.
      </t><t>
      Class of Service Received
      </t><t>
      Class of Service Transmitted
      </t><t>
         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]
      </t>
     </documentation>
     <appinfo>



Calato, et al.         Expires February 10, 2004               [Page 29]

Internet-Draft          IPFIX Information Model              August 2003


       <ipfix:fieldId>5</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="flowLabel" type="int">
   <annotation>
     <documentation>
      <t>
      The Flow Label information element contains the IPV6 Flow Label



Calato, et al.         Expires December 15, 2003               [Page 30]

Internet-Draft          IPFIX Information Model                June 2003
      information as defined by RFC 2460.
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>31</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="flowCreationTime" type="dateTime">
   <annotation>
     <documentation>
     <t>
      The timestamp of the first packet of the flow.  (Ed. note:  current NFv9
      protocol uses sysuptime vs. direct time.  Not interesting from an info
      model perspective, an artifact (and an annoying one from a consumer
      perspective) of the protocol implementation details. How to address?)
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>21</ipfix:fieldId>
     </appinfo></annotation>
   </element>


   <element name="flowEndTime" type="dateTime">
   <annotation>
     <documentation>
     <t>
      The timestamp of the last packet of the flow.  (Ed. note:  current NFv9
      protocol uses sysuptime vs. direct time.  Not interesting from an info
      model perspective, an artifact (and an annoying one from a consumer
      perspective) of the protocol implementation details. How to address?)
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>22</ipfix:fieldId>
     </appinfo></annotation>
   </element>




Calato, et al.         Expires February 10, 2004               [Page 30]

Internet-Draft          IPFIX Information Model              August 2003


   <element name="sourceAS" type="int">
   <annotation>
     <documentation>
     <t>
      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):
      </t>
     </documentation>



Calato, et al.         Expires December 15, 2003               [Page 31]

Internet-Draft          IPFIX Information Model                June 2003
     <appinfo>
       <ipfix:fieldId>16</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="destinationAS" type="int">
   <annotation>
     <documentation>
     <t>
      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).
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>17</ipfix:fieldId>
     </appinfo></annotation>
   </element>

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

   <element name="tcpControlBits" type="int">
   <annotation>
     <documentation>
     <t>
      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



Calato, et al.         Expires February 10, 2004               [Page 31]

Internet-Draft          IPFIX Information Model              August 2003


      have occurred but was not detected by the reporting CCE). TCP
      Control Bits are defined by RFC 793.
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>6</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>



Calato, et al.         Expires December 15, 2003               [Page 32]

Internet-Draft          IPFIX Information Model                June 2003

   <element name="sourceExporterAddress" name="ipV4SourceExporterAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
     <t>
      The IPV4 address of the Exporter reporting the flow. 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:
     </t><t><figure><artwork xml:space="preserve">

                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |
      </artwork></figure></t><t>
      Flows coming from SW1 and SW2 through proxy P1 would look to the
      Collector like the same Exporter
      connection. With the Source Exporter in the message the original
      Exporter  address is the maintained.
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="ipV6SourceExporterAddress" type="ipdr:ipV6Addr">
   <annotation>
     <documentation>
     <t>
      The IPv4 address of the Exporter reporting  the flow, Address is same as is as shown for Source Address. flow. 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:
     </t><t><figure><artwork xml:space="preserve">



Calato, et al.         Expires February 10, 2004               [Page 32]

Internet-Draft          IPFIX Information Model              August 2003


                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |
      </artwork></figure></t><t>
      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.
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="droppedPacketCount" type="int">
   <annotation>
     <documentation>
     <t>
      Contains the count of packets dropped at the observation point
      associated with the identified flow.
     </t><t>
      The dropped packet count can be a running counter and is the count
      from the beginning of the flow establishment.
     </t><t>
      The dropped packet count can be a delta counter and is the count
      since the last report for this flow.
     </t>
     </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>



Calato, et al.         Expires December 15, 2003               [Page 33]

Internet-Draft          IPFIX Information Model                June 2003
     </appinfo>
   </annotation>
   </element>

   <element name="samplingInterval" type="int">
   <annotation>
     <documentation>
     <t>
      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.
      </t>



Calato, et al.         Expires February 10, 2004               [Page 33]

Internet-Draft          IPFIX Information Model              August 2003


     </documentation>
     <appinfo>
       <ipfix:fieldId>34</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

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

   <element name="flowEndState" type="int">
   <annotation>
     <documentation>
     <t>
      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]
      </t>



Calato, et al.         Expires December 15, 2003               [Page 34]

Internet-Draft          IPFIX Information Model                June 2003
     </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="droppedByteCount" type="int">
   <annotation>
     <documentation>
      <t>
      Contains the count of octets dropped at the observation point



Calato, et al.         Expires February 10, 2004               [Page 34]

Internet-Draft          IPFIX Information Model              August 2003


      associated with the identified flow.
      </t><t>
      The dropped byte count can be a running counter and is the count
      from the beginning of the flow establishment.
      </t><t>
      The byte count can be a delta counter and is the count since the
      last report for this flow.
      </t>
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   </schema>
































Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 35]

Internet-Draft          IPFIX Information Model                June              August 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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 assignees.

   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



Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 36]

Internet-Draft          IPFIX Information Model                June              August 2003


   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.











































Calato, et al.         Expires December 15, 2003 February 10, 2004               [Page 37]

----