Network Working Group J. Meyer Internet-Draft PayPal Expires: January 17, 2005 J. Quittek NEC S. Bryant Cisco Systems Ltd July 19, 2004 Information Model for IP Flow Information Export draft-ietf-ipfix-info-04 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 January 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines and information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic observation point, the traffic metering process and the exporting 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. Meyer, et al. Expires January 17, 2005 [Page 1] Internet-Draft IPFIX Information Model July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Properties of IPFIX Protocol Fields . . . . . . . . . . . . 6 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 octet . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7 octetArray . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8 string . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . . . . 9 3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . . 9 3.11 ipv4Address . . . . . . . . . . . . . . . . . . . . . . . . 9 3.12 ipv6Address . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Flow Attributes . . . . . . . . . . . . . . . . . . . . . . 10 4.1 deltaOctetCount . . . . . . . . . . . . . . . . . . . . . . 10 4.2 deltaPacketCount . . . . . . . . . . . . . . . . . . . . . . 10 4.3 totalFlowCount . . . . . . . . . . . . . . . . . . . . . . . 10 4.4 protocolIdentifier . . . . . . . . . . . . . . . . . . . . . 11 4.5 classOfServiceV4 . . . . . . . . . . . . . . . . . . . . . . 11 4.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . . . . 11 4.7 transportSourcePort . . . . . . . . . . . . . . . . . . . . 12 4.8 sourceAddressV4 . . . . . . . . . . . . . . . . . . . . . . 13 4.9 sourceMaskV4 . . . . . . . . . . . . . . . . . . . . . . . . 13 4.10 ingressInterface . . . . . . . . . . . . . . . . . . . . . . 13 4.11 transportDestinationPort . . . . . . . . . . . . . . . . . . 14 4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . . 14 4.13 destinationMaskV4 . . . . . . . . . . . . . . . . . . . . . 15 4.14 egressInterface . . . . . . . . . . . . . . . . . . . . . . 15 4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . . 15 4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . . . 15 4.17 destinationAsNumber . . . . . . . . . . . . . . . . . . . . 16 4.18 bgpNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . 16 4.19 OutMulticastPacketCount . . . . . . . . . . . . . . . . . . 16 4.20 OutMulticastOctetCount . . . . . . . . . . . . . . . . . . . 17 4.21 flowEndTime . . . . . . . . . . . . . . . . . . . . . . . . 17 4.22 flowCreationTime . . . . . . . . . . . . . . . . . . . . . . 17 4.23 deltaOutOctetCount . . . . . . . . . . . . . . . . . . . . . 17 4.24 deltaOutPacketCount . . . . . . . . . . . . . . . . . . . . 18 4.25 minPacketLength . . . . . . . . . . . . . . . . . . . . . . 18 4.26 maxPacketLength . . . . . . . . . . . . . . . . . . . . . . 18 4.27 sourceAddressV6 . . . . . . . . . . . . . . . . . . . . . . 18 4.28 destinationAddressV6 . . . . . . . . . . . . . . . . . . . . 19 4.29 sourceMaskV6 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.30 destinationMaskV6 . . . . . . . . . . . . . . . . . . . . . 19 Meyer, et al. Expires January 17, 2005 [Page 2] Internet-Draft IPFIX Information Model July 2004 4.31 flowLabelV6 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.32 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . . . . 20 4.33 igmpType . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.34 flowActiveTimeOut . . . . . . . . . . . . . . . . . . . . . 20 4.35 flowInactiveTimeout . . . . . . . . . . . . . . . . . . . . 21 4.36 exportedOctetCount . . . . . . . . . . . . . . . . . . . . . 21 4.37 exportedPacketCount . . . . . . . . . . . . . . . . . . . . 21 4.38 exportedFlowCount . . . . . . . . . . . . . . . . . . . . . 21 4.39 sourcePrefixV4 . . . . . . . . . . . . . . . . . . . . . . . 22 4.40 destinationPrefixV4 . . . . . . . . . . . . . . . . . . . . 22 4.41 mplsTopLabelType . . . . . . . . . . . . . . . . . . . . . . 22 4.42 mplsTopLabelIPAddressV4 . . . . . . . . . . . . . . . . . . 23 4.43 minimumTTL . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.44 maximumTTL . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.45 identificationV4 . . . . . . . . . . . . . . . . . . . . . . 23 4.46 sourceMacAddress . . . . . . . . . . . . . . . . . . . . . . 24 4.47 ipVersion . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.48 ipNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . . 24 4.49 bgpNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . 25 4.50 ipv6OptionHeaders . . . . . . . . . . . . . . . . . . . . . 25 4.51 partialMPLSLabelStackEntry1 . . . . . . . . . . . . . . . . 26 4.52 partialMPLSLabelStackEntry2 . . . . . . . . . . . . . . . . 26 4.53 partialMPLSLabelStackEntry3 . . . . . . . . . . . . . . . . 27 4.54 partialMPLSLabelStackEntry4 . . . . . . . . . . . . . . . . 27 4.55 partialMPLSLabelStackEntry5 . . . . . . . . . . . . . . . . 27 4.56 partialMPLSLabelStackEntry6 . . . . . . . . . . . . . . . . 28 4.57 partialMPLSLabelStackEntry7 . . . . . . . . . . . . . . . . 28 4.58 partialMPLSLabelStackEntry8 . . . . . . . . . . . . . . . . 28 4.59 partialMPLSLabelStackEntry9 . . . . . . . . . . . . . . . . 29 4.60 partialMPLSLabelStackEntry10 . . . . . . . . . . . . . . . . 29 4.61 runningOctetCounter . . . . . . . . . . . . . . . . . . . . 29 4.62 runningPacketCounter . . . . . . . . . . . . . . . . . . . . 30 4.63 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 30 4.64 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 30 4.65 exporterAddressV4 . . . . . . . . . . . . . . . . . . . . . 31 4.66 exporterAddressV6 . . . . . . . . . . . . . . . . . . . . . 31 4.67 droppedOctetDeltaCount . . . . . . . . . . . . . . . . . . . 31 4.68 droppedPacketDeltaCount . . . . . . . . . . . . . . . . . . 32 4.69 droppedOctetTotalCount . . . . . . . . . . . . . . . . . . . 32 4.70 droppedPacketTotalCount . . . . . . . . . . . . . . . . . . 32 4.71 flowEndReason . . . . . . . . . . . . . . . . . . . . . . . 32 4.72 classOfServiceV6 . . . . . . . . . . . . . . . . . . . . . . 33 5. Extending the Information Model . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . 36 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 Normative Reference . . . . . . . . . . . . . . . . . . . . 38 Informative Reference . . . . . . . . . . . . . . . . . . . 39 Meyer, et al. Expires January 17, 2005 [Page 3] Internet-Draft IPFIX Information Model July 2004 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 41 B. Formal Specification of Abstract Data Types . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . . 73 Meyer, et al. Expires January 17, 2005 [Page 4] Internet-Draft IPFIX Information Model July 2004 1. Introduction The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in [IPFIX-PROTO] defines how information elements are transmitted. For information elements, it specifies the encoding of a set of basic data types. However, the list of fields that can be transmitted by the protocol, such as flow attributes (source IP address, number of packets, etc.) and information about the metering and exporting process (packet observation point, smapling rate, flow timeout interval, etc.), is not specified in [IPFIX-PROTO]. This document complements the IPFIX protocol specification by providing the IPFIX information model. The main part of this document is Section 5 defines the (extensible) list of fields to be transmitted by the IPFIX protcol. Section 2 defines a template for specifying IPFIX fields that is used in Section 4. Section 3 defines the set of abstract data types that are available for IPFIX fields. Section 5 discusses extensibility of the IPFIX information model. The main bodies of Sections 2, 3 and 4 were generated from XML documents. The XML-based specification of template, abstract data types and IPFIX fields can be used for automatically checking syntactical correctness of the specification of IPFIX fields. Further it can be used for generating IPFIX protocol implementation code that deals with processing IPFIX fields. Also code for applications that further process traffic information transmitted via the IPFIX protocol can be generated with the XML specification of IPFIX fields. For that reason, the XML document that served as source for Section 4 and the XML schema that served as source for Sections 2 and 3 are attached to this document in Appendices A and B. Note that although partially generated from the attached XML documents, the main body of this document is normative while the appendices are informational. Meyer, et al. Expires January 17, 2005 [Page 5] Internet-Draft IPFIX Information Model July 2004 2. Properties of IPFIX Protocol Fields Fields of the IPFIX protocol carrying information about traffic measurement are modeled as elements of the IPFIX information model and specified in Section 4. For defining the fields, a template is used that is specified below. All fields specified for the IPFIX protocol either in this document or by an 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. "sourceIpAddress"). fieldType - A numeric identifier administered by IANA. This is used for compact identification of an information item when encoding templates in the protocol. description - The semantics of this information element. Describes how this field is derived from the flow or other information available to the observer. dataType - One of the types listed in the "Type Space" section. The type space for attributes is constrained to facilitate implementation. The existing 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. dataTypeSemantics - The integral types may be qualified by additional semantic details. Qualifying the fields as 'quantity', 'counter', 'identifier' or 'flags'. applicability - to be done ... status - to be done ... All fields specified for the IPFIX protocol either in this document or by an extension MAY have the following properties defined: vendorId - 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. usage - to be done ... Meyer, et al. Expires January 17, 2005 [Page 6] Internet-Draft IPFIX Information Model July 2004 units - If the field is a measure of some kind, the units identify what the measure is. enumeratedRange - 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 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. reference - Identifies additional specifications which more precisely define this item or provide additional context for its use. Meyer, et al. Expires January 17, 2005 [Page 7] Internet-Draft IPFIX Information Model July 2004 3. Type Space The following subsections describe the abstract data types that can be used for the specification of IPFIX fields in Section 4. 3.1 octet The type "unsignedByte" represents a non-negative integer value in the range of 0 to 255. 3.2 unsigned16 The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535. 3.3 unsigned32 The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295. 3.4 unsigned64 The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615. 3.5 float32 The type "float32" corresponds to an IEEE single-precision 32-bit floating point type. 3.6 boolean The type "boolean" represents a binary value. 3.7 octetArray The type "octetArray" represents a finite length string of octets. 3.8 string The type "string" represents a finite length string of valid characters from the 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 UTF-8 format, which is identical in encoding for USASCII characters, but also accomodates other Unicode multibyte characters. Meyer, et al. Expires January 17, 2005 [Page 8] Internet-Draft IPFIX Information Model July 2004 3.9 dateTimeSeconds The type "dateTimeSeconds" represents a time value 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. 3.10 dataTimeMicroSeconds The type "dateTimeSeconds" represents a time value having a precision of microseconds and normalized to the GMT timezone. 3.11 ipv4Address The type "ipv4Addr" represents a value of an IPv4 address. These addresses are typically stored as 32-bit integers. 3.12 ipv6Address The type "ipv6Addr" represents a value of an IPv6 address. Meyer, et al. Expires January 17, 2005 [Page 9] Internet-Draft IPFIX Information Model July 2004 4. Flow Attributes 4.1 deltaOctetCount Description: The number of octets in (incoming) packets observed for this flow at the observation point since the previous report (if any). The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Field Id: 1 Units: octets 4.2 deltaPacketCount Description: The number of (incoming) packets observed for this flow at the observation point since the previous report (if any). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Field Id: 2 Units: packets 4.3 totalFlowCount Description: The number of flows observed so far in the observation domain. Abstract Data Type: unsigned64 Data Type Semantics: runningCounter Field Id: 3 Units: flows Meyer, et al. Expires January 17, 2005 [Page 10] Internet-Draft IPFIX Information Model July 2004 4.4 protocolIdentifier Description: The protocol number observed for packets of this flow. The protocol number identifies the IP packet payload. Protocol numbers are defined in the IANA Protocol Numbers registry. In Internet Protocol version 4 (IPv4) this is carried in the "Protocol" field. In Internet Protocol version 6 (IPv6) this is carried in the "Next Header" field in the last extension header of the packet. Abstract Data Type: octet Data Type Semantics: identifier Field Id: 4 Reference: See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See list of protocol numbers assigned by IANA at http://www.iana.org/ assignments/protocol-numbers. 4.5 classOfServiceV4 Description: The value of the IPv4 TOS field observed for packets of this flow. Abstract Data Type: octet Data Type Semantics: identifier Field Id: 5 Reference: See RFC 791 for the definition of the IPv4 TOS field. 4.6 tcpControlBits Description: Meyer, et al. Expires January 17, 2005 [Page 11] Internet-Draft IPFIX Information Model July 2004 TCP control bits observed for packets of this flow. The value of this field is the result of a logical OR operation over the flags observed in all packets of the flow. This implies that a 0 value for a bit indicates that the respective bit was not set in any of the observed packets of this flow. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | | Reserved | URG | ACK | PSH | RST | SYN | FIN | | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Reserved: Reserved for future use by TCP. Must be zero. URG: Urgent Pointer field significant ACK: Acknowledgment field significant PSH: Push Function RST: Reset the connection SYN: Synchronize sequence numbers FIN: No more data from sender Abstract Data Type: octet Data Type Semantics: flags Field Id: 6 Reference: See RFC 793 for a definition of the TCP control bits in the TCP header. 4.7 transportSourcePort Description: A source port identifier in the transport header. For transport protocols UDP, TCP and SCTP this is the source port number given in the respective header. This field MAY also be used for future transport protocols that have 16 bit source port identifiers. Abstract Data Type: unsigned16 Data Type Semantics: identifier Field Id: 7 Meyer, et al. Expires January 17, 2005 [Page 12] Internet-Draft IPFIX Information Model July 2004 Reference: See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 2960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. 4.8 sourceAddressV4 Description: IPv4 source address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv4Address Field Id: 8 Reference: See RFC 791 for the definition of the IPv4 source address field. 4.9 sourceMaskV4 Description: The number of contiguous bits that are relevant in the sourceAddressV4 field. Abstract Data Type: octet Field Id: 9 Units: bits 4.10 ingressInterface Description: The index of the IP interface (ifIndex) where packets of this flow are being received. Abstract Data Type: unsigned32 Data Type Semantics: identifier Meyer, et al. Expires January 17, 2005 [Page 13] Internet-Draft IPFIX Information Model July 2004 Field Id: 10 Reference: See RFC 2863 for the definition of the ifIndex object. 4.11 transportDestinationPort Description: A destination port identifier in the transport header. For transport protocols UDP, TCP and SCTP this is the destination port number given in the respective header. This field MAY also be used for future transport protocols that have 16 bit destination port identifiers. Abstract Data Type: unsigned16 Data Type Semantics: identifier Field Id: 11 Reference: See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 2960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. 4.12 destinationAddressV4 Description: IPv4 destination address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv4Address Field Id: 12 Reference: See RFC 791 for the definition of the IPv4 destination address field. Meyer, et al. Expires January 17, 2005 [Page 14] Internet-Draft IPFIX Information Model July 2004 4.13 destinationMaskV4 Description: The number of contiguous bits that are relevant in the destinationAddressV4 field. Abstract Data Type: octet Field Id: 13 Units: bits 4.14 egressInterface Description: The index of the IP interface (ifIndex) where packets of this flow are being sent. Abstract Data Type: unsigned32 Data Type Semantics: identifier Field Id: 14 Reference: See RFC 2863 for the definition of the ifIndex object. 4.15 ipNextHopAddressV4 Description: The IPv4 address of the next IP hop to which packets of this flow are forwarded. Abstract Data Type: ipv4Address Field Id: 15 4.16 sourceAsNumber Description: The autonomous system (AS) number of the source address in the IP packet header in a packet of this flow. Abstract Data Type: unsigned16 Meyer, et al. Expires January 17, 2005 [Page 15] Internet-Draft IPFIX Information Model July 2004 Data Type Semantics: identifier Field Id: 16 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 4.17 destinationAsNumber Description: The autonomous system (AS) number of the destination address in the IP packet header in a packet of this flow. Abstract Data Type: unsigned16 Data Type Semantics: identifier Field Id: 17 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 4.18 bgpNextHopAddressV4 Description: The IPv4 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv4Address Field Id: 18 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 4.19 OutMulticastPacketCount Description: The number of outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the observation point of this flow. Meyer, et al. Expires January 17, 2005 [Page 16] Internet-Draft IPFIX Information Model July 2004 Abstract Data Type: unsigned64 Field Id: 19 Units: packets 4.20 OutMulticastOctetCount Description: The number of octets in outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the observation point of this flow. Abstract Data Type: unsigned64 Field Id: 20 Units: octets 4.21 flowEndTime Description: The timestamp of the last packet of this flow. Abstract Data Type: dateTimeSeconds Field Id: 21 4.22 flowCreationTime Description: The timestamp of the first packet of this flow. Abstract Data Type: dateTimeSeconds Field Id: 22 4.23 deltaOutOctetCount Description: The number of octets in outgoing packets observed for this flow at the observation point since the previous report (if any). The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Meyer, et al. Expires January 17, 2005 [Page 17] Internet-Draft IPFIX Information Model July 2004 Field Id: 23 Units: octets 4.24 deltaOutPacketCount Description: The number of outgoing packets observed for this flow at the observation point since the previous report (if any). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Field Id: 24 Units: packets 4.25 minPacketLength Description: Length of the smallest packet observed for this flow. Abstract Data Type: unsigned16 Field Id: 25 Units: octets 4.26 maxPacketLength Description: Length of the largest packet observed for this flow. Abstract Data Type: unsigned16 Field Id: 26 Units: octets 4.27 sourceAddressV6 Description: Meyer, et al. Expires January 17, 2005 [Page 18] Internet-Draft IPFIX Information Model July 2004 IPv6 source address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv6Address Field Id: 27 4.28 destinationAddressV6 Description: IPv6 destination address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv6Address Field Id: 28 4.29 sourceMaskV6 Description: The number of contiguous bits that are relevant in the sourceAddressV6 field. Abstract Data Type: octet Field Id: 29 Units: bits 4.30 destinationMaskV6 Description: The number of contiguous bits that are relevant in the destinationAddressV6 field. Abstract Data Type: octet Field Id: 30 Units: bits 4.31 flowLabelV6 Meyer, et al. Expires January 17, 2005 [Page 19] Internet-Draft IPFIX Information Model July 2004 Description: The Flow Label of the IPv6 packet header observed in a packet of this flow. Abstract Data Type: unsigned32 Field Id: 31 Reference: See RFC 2460 for a definition of the flow label field in the IPv6 packet header. 4.32 icmpTypeCode Description: Type and Code of the ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. Abstract Data Type: unsigned16 Field Id: 32 Reference: See RFC 792 for a definition of the ICMP type and code fields. 4.33 igmpType Description: The type field of the IGMP message. Abstract Data Type: octet Field Id: 33 Reference: See RFC 2236 for a definition of the IGMP type field. 4.34 flowActiveTimeOut Description: The number of seconds after which an active flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 Meyer, et al. Expires January 17, 2005 [Page 20] Internet-Draft IPFIX Information Model July 2004 Field Id: 36 Units: seconds 4.35 flowInactiveTimeout Description: A flow is considered to be timed out if not packet belonging to the flow has been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 Field Id: 37 Units: seconds 4.36 exportedOctetCount Description: The number of all octets reported by the exporting process to this collecting process. Abstract Data Type: unsigned64 Field Id: 40 Units: octets 4.37 exportedPacketCount Description: The number of all packets reported by the exporting process to this collecting process. Abstract Data Type: unsigned64 Field Id: 41 Units: packets 4.38 exportedFlowCount Meyer, et al. Expires January 17, 2005 [Page 21] Internet-Draft IPFIX Information Model July 2004 Description: The number of all flows records reported by the exporting process to this collecting process. Abstract Data Type: unsigned64 Field Id: 42 Units: flows 4.39 sourcePrefixV4 Description: IPv4 source address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list Abstract Data Type: ipV4Address Field Id: 44 Units: flows 4.40 destinationPrefixV4 Description: IPv4 destination address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list Abstract Data Type: ipV4Address Field Id: 45 Units: flows 4.41 mplsTopLabelType Description: MPLS top label type: This field identifies the control protocol that allocated the top of stack label. Meyer, et al. Expires January 17, 2005 [Page 22] Internet-Draft IPFIX Information Model July 2004 Abstract Data Type: octet Data Type Semantics: identifier Field Id: 46 4.42 mplsTopLabelIPAddressV4 Description: The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. Abstract Data Type: ipV4Address Field Id: 47 4.43 minimumTTL Description: Minimum TTL value observed for any packet in this flow. Abstract Data Type: octet Field Id: 52 4.44 maximumTTL Description: Maximum TTL value observed for any packet in this flow. Abstract Data Type: octet Field Id: 53 4.45 identificationV4 Description: Packet identification field from the first IP packet of this flow. Abstract Data Type: octet Data Type Semantics: identifier Field Id: 54 Meyer, et al. Expires January 17, 2005 [Page 23] Internet-Draft IPFIX Information Model July 2004 Reference: See RFC 791 for the definition of the IPv4 identification field. 4.46 sourceMacAddress Description: Packet identification field from the first IP packet of this flow. Abstract Data Type: octet Field Id: 56 Reference: See RFC 791 for the definition of the IPv4 identification field. 4.47 ipVersion Description: The IP version field given in the IP header. Abstract Data Type: octet Field Id: 60 Units: flows Reference: See RFC 791 for a definition of the version field in the IPv6 packet header. See RFC 2460 for a definition of the version field in the IPv6 packet header. Additional information on defined version numbers can be found at http://www.iana.org/assignments/ version-numbers. 4.48 ipNextHopAddressV6 Description: The IPv6 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv6Address Field Id: 62 Meyer, et al. Expires January 17, 2005 [Page 24] Internet-Draft IPFIX Information Model July 2004 4.49 bgpNextHopAddressV6 Description: The IPv6 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv6Address Data Type Semantics: identifier Field Id: 63 Reference: See RFC 1771 for a description of BGB-4. See RFC 1930 a definition of the AS number. 4.50 ipv6OptionHeaders Description: IPv6 options in the IP packet headers of this flow. This is encoded as a bit field. bit IPv6 Option Definition 0 Reserved 1 44 Fragmentation header - not first fragment 2 43 Routing header 3 44 Fragmentation header - first fragment 4 Unknown Layer 4 header (compressed, encrypted, not supported) 5 Reserved 6 0 Hop-by-hop option header 7 60 Destination option header 8 108 Payload compression header 9 51 Authentication Header 10 50 Encrypted security payload 11 to 31 Reserved Abstract Data Type: unsigned32 Meyer, et al. Expires January 17, 2005 [Page 25] Internet-Draft IPFIX Information Model July 2004 Data Type Semantics: flags Field Id: 64 Reference: To be done. 4.51 partialMPLSLabelStackEntry1 Description: The label, exp and s fields from the outermost MPLS label stack entry e.g. the last label that was pushed last. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit Abstract Data Type: unsigned32 Field Id: 70 Reference: See RFC 3032. 4.52 partialMPLSLabelStackEntry2 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse1. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 71 Reference: See RFC 3032. Meyer, et al. Expires January 17, 2005 [Page 26] Internet-Draft IPFIX Information Model July 2004 4.53 partialMPLSLabelStackEntry3 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse2. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 72 Reference: See RFC 3032. 4.54 partialMPLSLabelStackEntry4 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse3. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 73 Reference: See RFC 3032. 4.55 partialMPLSLabelStackEntry5 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse4. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 74 Reference: See RFC 3032. Meyer, et al. Expires January 17, 2005 [Page 27] Internet-Draft IPFIX Information Model July 2004 4.56 partialMPLSLabelStackEntry6 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse5. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 75 Reference: See RFC 3032. 4.57 partialMPLSLabelStackEntry7 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse6. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 76 Reference: See RFC 3032. 4.58 partialMPLSLabelStackEntry8 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse7. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 77 Reference: See RFC 3032. Meyer, et al. Expires January 17, 2005 [Page 28] Internet-Draft IPFIX Information Model July 2004 4.59 partialMPLSLabelStackEntry9 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse8. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 78 Reference: See RFC 3032. 4.60 partialMPLSLabelStackEntry10 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse9. See the definition of partialMplsLse1 for further details. Abstract Data Type: unsigned32 Field Id: 79 Reference: See RFC 3032. 4.61 runningOctetCounter Description: Number of observed octets for a pre-defined permanent flow. EDITOR'S NOTE: clarification required. Abstract Data Type: unsigned64 Data Type Semantics: runningCounter Field Id: 85 Units: octets Meyer, et al. Expires January 17, 2005 [Page 29] Internet-Draft IPFIX Information Model July 2004 4.62 runningPacketCounter Description: Number of observed packets for a pre-defined permanent flow. EDITOR'S NOTE: clarification required. Abstract Data Type: unsigned64 Data Type Semantics: runningCounter Field Id: 86 Units: packets 4.63 bgpNextHopAsNumber Description: The autonomous system (AS) number of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: unsigned16 Data Type Semantics: identifier Field Id: 128 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 4.64 ipNextHopAsNumber Description: The autonomous system (AS) number of the next IP hop to which packets of this flow are forwarded. Abstract Data Type: unsigned16 Data Type Semantics: identifier Field Id: 129 Meyer, et al. Expires January 17, 2005 [Page 30] Internet-Draft IPFIX Information Model July 2004 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 4.65 exporterAddressV4 Description: The IPv4 address of the used by the exporting process. This is used by the collector to identify the exporter in cases where the identity of the exporter may have been obscured by the use of a proxy. Abstract Data Type: ipv4Address Data Type Semantics: identifier Field Id: 130 4.66 exporterAddressV6 Description: The IPv6 address of the used by the exporting process. This is used by the collector to identify the exporter in cases where the identity of the exporter may have been obscured by the use of a proxy. Abstract Data Type: ipv6Address Data Type Semantics: identifier Field Id: 131 4.67 droppedOctetDeltaCount Description: The number of octets in packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Field Id: 132 Units: octets Meyer, et al. Expires January 17, 2005 [Page 31] Internet-Draft IPFIX Information Model July 2004 4.68 droppedPacketDeltaCount Description: The number of packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter Field Id: 133 Units: packets 4.69 droppedOctetTotalCount Description: The number of octets in packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: runningCounter Field Id: 134 Units: octets 4.70 droppedPacketTotalCount Description: The number of packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: runningCounter Field Id: 135 Units: packets 4.71 flowEndReason Description: Meyer, et al. Expires January 17, 2005 [Page 32] Internet-Draft IPFIX Information Model July 2004 The reason for flow termination. EDITORS' NOTE: This needs to be defined as an enumerated range. Abstract Data Type: octet Field Id: 136 4.72 classOfServiceV6 Description: The value of the IPv6 traffic class field observed for packets of this flow. Abstract Data Type: octet Field Id: 135 Reference: See RFC 2460 for the definition of the IPv6 traffic class field. Meyer, et al. Expires January 17, 2005 [Page 33] Internet-Draft IPFIX Information Model July 2004 5. Extending the Information Model A key requirement for IPFIX is to allow for extending the set of information items which are reported for flows. This section defines the mechanism for extending this set. The IPFIX protocol carries flow records defined by a template. Multiple templates may be defined for a dialog between an exporter and a collector. A given template identifies the information items and their order. The means of identification of information items in a template is via a field ID. Field Id's are unique identifiers administered by IANA. Extension is done by defining new Information elements, including the set of necessary information and possibly additional optional information for each element. Each new information item MUST be assigned a unique fieldId as part of its definition. These unique field ids are the connection between the record structure communicated by the protocol using templates and a consuming application. Vendor specific extensions may be made by vendors with IANA enterprise ID assignments, without registering specific field ID's with IANA. In these cases the field definiton must specify the vendor ID as well as the vendor-specified field ID and other mandatory field properties. Before creating vendor-specific fields, the general applicability of such information elements should be considered. For generally applicable fields using IETF and IANA mechanisms for extendind the information model is recommended. Meyer, et al. Expires January 17, 2005 [Page 34] Internet-Draft IPFIX Information Model July 2004 6. IANA Considerations IANA has to create a new registry for IPFIX fields ID's. Appendix B defines an XML schema which may be used to create consistent machine readable extensions to the IPFIX information model. This schema introduces a new namaspace, which will be assigned by IANA according to RFC 3688. Currently the name space for this schema is identified as http://www.ietf.org/ipfix. Meyer, et al. Expires January 17, 2005 [Page 35] Internet-Draft IPFIX Information Model July 2004 7. Security Considerations The IPFIX information model itself does not directly introduce security issues. Rather it defines a set of attributes which may for privacy or business issues be considered sensitive information. The underlying protocol used to exchange the information described here must therefor apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such protocols are defined in separate documents. Specifically the IPFIX Protocol document. Meyer, et al. Expires January 17, 2005 [Page 36] Internet-Draft IPFIX Information Model July 2004 8. Acknowledgements The editors thank Stewart Bryant for a lot of useful input on the field definitions. Also many thanks to Thomas Dietz for developing the XSLT scripts that generate large portions of the text part of this document from the XML appendices. Meyer, et al. Expires January 17, 2005 [Page 37] Internet-Draft IPFIX Information Model July 2004 Normative Reference [1] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX Protocol Specification", IETF draft work in progress, January 2004, . Meyer, et al. Expires January 17, 2005 [Page 38] Internet-Draft IPFIX Information Model July 2004 Informative Reference [2] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements for IP Flow Information Export", IETF draft work in progress, January 2004, . [3] Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow Information Export", IETF draft work in progress, October 2003, . [4] Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX Applicability", IETF draft work in progress, October 2003, . [5] Claise, B., "Cisco Systems NetFlow Services Export Version 9", IETF draft work in progress, June 2003, . [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML, May 2001, . [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML, May 2001, . [9] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1.1", October 2002, . [10] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, Sept. 2000, . [11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . [12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", RFC 3470, January 2003, . Meyer, et al. Expires January 17, 2005 [Page 39] Internet-Draft IPFIX Information Model July 2004 [13] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003, . [14] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004, . Authors' Addresses Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US Phone: +1 408 976-9149 EMail: jemeyer@paypal.com URI: http://www.paypal.com Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de URI: http://www.netlab.nec.de/ Stewart Bryant Cisco Systems Ltd 250, Longwater, Green Park Reading RG2 6GB United Kingdom EMail: stbryant@cisco.com Meyer, et al. Expires January 17, 2005 [Page 40] Internet-Draft IPFIX Information Model July 2004 Appendix A. Formal Specification of IPFIX Fields This appendix contains a formal description of the IPFIX information model XML document. Note that this appendix is of informational nature, while the text in section 4 generated from this appendix is normative. Using a formal and machine readable syntax for the Information model enables the creation of IPFIX aware tools which can automatically adapt to extensions to the information model, by simply reading updated information model specifications. The 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 authored in XML and transformed according to RFC2629. It should be noted that the use of XML in exporters, collectors or other tools is not mandatory for the deployment of IPFIX. In particular exporting processes do not produce or consume XML as part of their operation. It is expected that IPFIX collectors MAY take advantage of the machine readability of the Information Model vs. hardcoding their behavior or inventing proprietary means for accomodating extensions. The number of octets in (incoming) packets observed for this flow at the observation point since the previous report (if any). The number of octets include IP header(s) and IP payload. octets Meyer, et al. Expires January 17, 2005 [Page 41] Internet-Draft IPFIX Information Model July 2004 The number of (incoming) packets observed for this flow at the observation point since the previous report (if any). packets The number of flows observed so far in the observation domain. flows The protocol number observed for packets of this flow. The protocol number identifies the IP packet payload. Protocol numbers are defined in the IANA Protocol Numbers registry. In Internet Protocol version 4 (IPv4) this is carried in the "Protocol" field. In Internet Protocol version 6 (IPv6) this is carried in the "Next Header" field in the last extension header of the packet. See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers. Meyer, et al. Expires January 17, 2005 [Page 42] Internet-Draft IPFIX Information Model July 2004 The value of the IPv4 TOS field observed for packets of this flow. See RFC 791 for the definition of the IPv4 TOS field. TCP control bits observed for packets of this flow. The value of this field is the result of a logical OR operation over the flags observed in all packets of the flow. This implies that a 0 value for a bit indicates that the respective bit was not set in any of the observed packets of this flow. to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing See RFC 793 for a definition of the TCP control bits in the TCP header. A source port identifier in the transport header. For transport protocols UDP, TCP and SCTP this is the source port number given in the respective header. This field MAY also be used for future transport protocols that have 16 bit source port identifiers. Meyer, et al. Expires January 17, 2005 [Page 43] Internet-Draft IPFIX Information Model July 2004 See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 2960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. IPv4 source address taken from the IP packet header of a packet of this flow. See RFC 791 for the definition of the IPv4 source address field. The number of contiguous bits that are relevant in the sourceAddressV4 field. bits 0-32 The index of the IP interface (ifIndex) where packets of this flow are being received. See RFC 2863 for the definition of the ifIndex object. Meyer, et al. Expires January 17, 2005 [Page 44] Internet-Draft IPFIX Information Model July 2004 A destination port identifier in the transport header. For transport protocols UDP, TCP and SCTP this is the destination port number given in the respective header. This field MAY also be used for future transport protocols that have 16 bit destination port identifiers. See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 2960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. IPv4 destination address taken from the IP packet header of a packet of this flow. See RFC 791 for the definition of the IPv4 destination address field. The number of contiguous bits that are relevant in the destinationAddressV4 field. Meyer, et al. Expires January 17, 2005 [Page 45] Internet-Draft IPFIX Information Model July 2004 bits 0-32 The index of the IP interface (ifIndex) where packets of this flow are being sent. See RFC 2863 for the definition of the ifIndex object. The IPv4 address of the next IP hop to which packets of this flow are forwarded. The autonomous system (AS) number of the source address in the IP packet header in a packet of this flow. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. Meyer, et al. Expires January 17, 2005 [Page 46] Internet-Draft IPFIX Information Model July 2004 The autonomous system (AS) number of the destination address in the IP packet header in a packet of this flow. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The IPv4 address of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The number of outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the observation point of this flow. packets The number of octets in outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the observation point of this flow. Meyer, et al. Expires January 17, 2005 [Page 47] Internet-Draft IPFIX Information Model July 2004 octets The timestamp of the last packet of this flow. The timestamp of the first packet of this flow. The number of octets in outgoing packets observed for this flow at the observation point since the previous report (if any). The number of octets include IP header(s) and IP payload. octets The number of outgoing packets observed for this flow at the observation point since the previous report (if any). packets Length of the smallest packet observed for this flow. Meyer, et al. Expires January 17, 2005 [Page 48] Internet-Draft IPFIX Information Model July 2004 octets Length of the largest packet observed for this flow. octets IPv6 source address taken from the IP packet header of a packet of this flow. IPv6 destination address taken from the IP packet header of a packet of this flow. The number of contiguous bits that are relevant in the sourceAddressV6 field. bits 0-128 The number of contiguous bits that are relevant in the destinationAddressV6 field. bits 0-128 The Flow Label of the IPv6 packet header observed in a packet of this flow. See RFC 2460 for a definition of the flow label field in the IPv6 packet header. Type and Code of the ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. See RFC 792 for a definition of the ICMP type and code fields. The type field of the IGMP message. See RFC 2236 for a definition of the IGMP type field. Meyer, et al. Expires January 17, 2005 [Page 50] Internet-Draft IPFIX Information Model July 2004 The number of seconds after which an active flow is timed out anyway, even if there is still a continuous flow of packets. seconds A flow is considered to be timed out if not packet belonging to the flow has been observed for the number of seconds specified by this field. seconds The number of all octets reported by the exporting process to this collecting process. octets The number of all packets reported by the exporting process to this collecting process. packets Meyer, et al. Expires January 17, 2005 [Page 51] Internet-Draft IPFIX Information Model July 2004 The number of all flows records reported by the exporting process to this collecting process. flows IPv4 source address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list flows IPv4 destination address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list flows MPLS top label type: 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label 0x02 Pseudowire: Any PWE3 or Cisco AToM based label 0x03 VPN: Any label associated with VPN 0x04 BGP: Any label associated with BGP or BGP routing 0x05 LDP: Any label associated with dynamically assigned labels using LDP This field identifies the control protocol that allocated the top of stack label. Meyer, et al. Expires January 17, 2005 [Page 52] Internet-Draft IPFIX Information Model July 2004 The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. Minimum TTL value observed for any packet in this flow. Maximum TTL value observed for any packet in this flow. Packet identification field from the first IP packet of this flow. See RFC 791 for the definition of the IPv4 identification field. Packet identification field from the first IP packet of this flow. Meyer, et al. Expires January 17, 2005 [Page 53] Internet-Draft IPFIX Information Model July 2004 See RFC 791 for the definition of the IPv4 identification field. The IP version field given in the IP header. flows See RFC 791 for a definition of the version field in the IPv6 packet header. See RFC 2460 for a definition of the version field in the IPv6 packet header. Additional information on defined version numbers can be found at http://www.iana.org/assignments/version-numbers. The IPv6 address of the next BGP hop to which packets of this flow are forwarded. The IPv6 address of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4. See RFC 1930 a definition of the AS number. Meyer, et al. Expires January 17, 2005 [Page 54] Internet-Draft IPFIX Information Model July 2004 IPv6 options in the IP packet headers of this flow. This is encoded as a bit field. to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing To be done. The label, exp and s fields from the outermost MPLS label stack entry e.g. the last label that was pushed last. to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing to be replaced by ASCII drawing See RFC 3032. Meyer, et al. Expires January 17, 2005 [Page 55] Internet-Draft IPFIX Information Model July 2004 The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse1. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse2. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse3. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed Meyer, et al. Expires January 17, 2005 [Page 56] Internet-Draft IPFIX Information Model July 2004 immediately before the LSE that would be reported by partialMplsLse4. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse5. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse6. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse7. See the definition of partialMplsLse1 for further details. Meyer, et al. Expires January 17, 2005 [Page 57] Internet-Draft IPFIX Information Model July 2004 See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse8. See the definition of partialMplsLse1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by partialMplsLse9. See the definition of partialMplsLse1 for further details. See RFC 3032. Number of observed octets for a pre-defined permanent flow. EDITOR'S NOTE: clarification required. Meyer, et al. Expires January 17, 2005 [Page 58] Internet-Draft IPFIX Information Model July 2004 octets Number of observed packets for a pre-defined permanent flow. EDITOR'S NOTE: clarification required. packets The autonomous system (AS) number of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The autonomous system (AS) number of the next IP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The IPv4 address of the used by the exporting process. This is used by the collector to identify the exporter in cases where the identity of the exporter may have been obscured by the use of a proxy. The IPv6 address of the used by the exporting process. This is used by the collector to identify the exporter in cases where the identity of the exporter may have been obscured by the use of a proxy. The number of octets in packets of this flow dropped by packet treatment. octets The number of packets of this flow dropped by packet treatment. packets The number of octets in packets of this flow dropped by packet treatment. octets The number of packets of this flow dropped by packet treatment. packets The reason for flow termination. idle timeout end of flow detected (e.g. TCP FIN) forced end cache full EDITORS' NOTE: This needs to be defined as an enumerated range. The value of the IPv6 traffic class field observed for packets of this flow. See RFC 2460 for the definition of the IPv6 traffic class field. Meyer, et al. Expires January 17, 2005 [Page 61] Internet-Draft IPFIX Information Model July 2004 Meyer, et al. Expires January 17, 2005 [Page 62] Internet-Draft IPFIX Information Model July 2004 Appendix B. Formal Specification of Abstract Data Types This appendix containfs a formal description of the abstract data types to be used for IPFIX fields and a formal description of the template used for defining IPFIX fields. Note that this appendix is of informational nature, while the text in sections 2 and 3 generated from this appendix is normative. The type "unsignedByte" represents a non-negative integer value in the range of 0 to 255. The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535. The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295. The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615. Meyer, et al. Expires January 17, 2005 [Page 63] Internet-Draft IPFIX Information Model July 2004 The type "float32" corresponds to an IEEE single-precision 32-bit floating point type. The type "boolean" represents a binary value. The type "octetArray" represents a finite length string of octets. The type "string" represents a finite length string of valid characters from the 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 UTF-8 format, which is identical in encoding for USASCII characters, but also accomodates other Unicode multibyte characters. The type "dateTimeSeconds" represents a time value 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 Meyer, et al. Expires January 17, 2005 [Page 64] Internet-Draft IPFIX Information Model July 2004 can be stored in 32-bit integers. The type "dateTimeSeconds" represents a time value having a precision of microseconds and normalized to the GMT timezone. The type "ipv4Addr" represents a value of an IPv4 address. These addresses are typically stored as 32-bit integers. The type "ipv6Addr" represents a value of an IPv6 address. A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters which represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the integral fields should behave as a quantity. Meyer, et al. Expires January 17, 2005 [Page 65] Internet-Draft IPFIX Information Model July 2004 A measurement which is ongoing from the perspective of the exporter. Basically the same semantics as counters in SNMP. Counters are unsigned and wrap back to zero after reaching the limit of the type. E.g. an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point the next increment will wrap its value to zero and continue counting from zero. An integral value which serves as an identifier. Specifically mathematical operations on two identifiers (aside from the equality operation) are meaningless. E.g. Autonomous System Id 1 * Autonomous System Id 2 is meaningless. An integral value which actually represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags should always be of an unsigned type. Used for fields that are applicable to flow records only. Meyer, et al. Expires January 17, 2005 [Page 66] Internet-Draft IPFIX Information Model July 2004 Used for fields that are applicable to option records only. Used for fields that are applicable to flow records as well as to option records. Indicates that the field definition is that the definition is current and valid. Indicates that the field definition is obsolete, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. Meyer, et al. Expires January 17, 2005 [Page 67] Internet-Draft IPFIX Information Model July 2004 Indicates that the field definition is obsolete and should not be implemented and/or can be removed if previously implemented. to be done ... to be done ... to be done ... Meyer, et al. Expires January 17, 2005 [Page 68] Internet-Draft IPFIX Information Model July 2004 The semantics of this information element. Describes how this field is derived from the flow or other information available to the observer. to be done ... If the field is a measure of some kind, the units identify what the measure is. Identifies additional specifications which more precisely define this item or provide additional context for its use. Some items may have a specific set of numeric Meyer, et al. Expires January 17, 2005 [Page 69] Internet-Draft IPFIX Information Model July 2004 identifiers associated with a set of discrete values this element may take. The meaning of each discrete value and a human readable name should be assigned. 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. 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. "sourceIpAddress"). One of the types listed in the "Type Space" section. The type space for attributes is constrained to facilitate implementation. The existing 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. Meyer, et al. Expires January 17, 2005 [Page 70] Internet-Draft IPFIX Information Model July 2004 The integral types may be qualified by additional semantic details. Qualifying the fields as 'quantity', 'counter', 'identifier' or 'flags'. A numeric identifier administered by IANA. This is used for compact identification of an information item when encoding templates in the protocol. 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. to be done ... to be done ... Meyer, et al. Expires January 17, 2005 [Page 71] Internet-Draft IPFIX Information Model July 2004 Meyer, et al. Expires January 17, 2005 [Page 72] Internet-Draft IPFIX Information Model July 2004 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 (2004). 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 Meyer, et al. Expires January 17, 2005 [Page 73] Internet-Draft IPFIX Information Model July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer, et al. Expires January 17, 2005 [Page 74]