IPFIX working group EDITORS: K.C. Norseth
Internet Draft Enterasys Networks
draft-ietf-ipfix-data-00.txt Paul Calato
Expires: August 2002 Riverstone Networks Inc
IPFIX Data Model
Data Model for IP Flow Information Export
draft-ietf-ipfix-data-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet- Drafts as reference material or
to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines an information and daqta model for
scalable monitoring, measuring and exporting IP flow information
to collectors.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [ ].
1. Introduction 3
2. Scope 3
3. Terminology 3
4. Flow Type and Flow Definition 3
4.1. Observation Point 5
4.2. Unidirectional and Bidirectional Flows 5
5. Metering Process Function 6
5.1. Flow Classification 6
IPFIX Working Group Expires August 2002 [Page 1]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
5.2. Selection Criteria Of Packets 6
5.2.1. Function on properties that determines a flow type (Fi) 7
5.2.2. Sampling packets on a flow type (Si) 7
5.3. Selection Criteria of flows for export 7
5.4. Flow Expiration 7
6. Information Model 8
6.1. Attributes related to IP Packet Header 8
6.2. Attributes Related to Measurement 9
6.3. Attributes Related to Flow Definition 9
6.4. Attributes related to Upper Layers 9
7. Information Elements 9
7.1. IP Address 9
7.1.1. Source Address 9
7.1.2. Destination Address 10
7.1.3. NEXT_HOP_IP 10
7.2. Time Stamps 10
7.2.1. Flow Creation Time 10
7.2.2. Flow End Time 10
7.2.3. Flow Start UTC Time 11
7.2.4. Flow End UTC Time 11
7.2.5. Flow Update Start Time 11
7.2.6. Flow Update End Time 11
7.2.7. Flow Update Delta Time 11
7.3. Service Types 11
7.3.1. Class of Service 11
7.3.2. TCP Control Bits 12
7.3.3. Protocol Identifier 12
7.3.4. Source Exporter Address 12
7.4. Flow End State 13
7.5. Statistical Elements 13
7.5.1. Byte Count 13
7.5.2. Packet Count 13
7.5.3. Dropped Byte Count 14
7.5.4. Dropped Packet Count 14
7.5.5. IPM_DPKTS 14
7.5.6. IPM_DOCTETS 14
7.6. Port Information 14
7.6.1. Source Port 14
7.6.2. Destination Port 14
7.7. Autonomous System (AS) 15
7.7.1. Source AS 15
7.7.2. Destination AS 15
7.7.3. Next Hop AS 15
7.8. IfIndexes and Interfaces 15
7.8.1. Ingress Port 15
7.8.2. Egress Port 15
7.8.3. Egress ATM Subinterface 16
7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE 16
7.9. NetMasks 16
7.9.1. Source Address Netmask 16
7.9.2. Destination Address Netmask 16
7.10. BGP & Vlan 's 16
7.10.1. Destination BGP Community 16
7.10.2. Source BGP Community 17
IPFIX Working Group Expires August 2002 [Page 2]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
7.10.3. BGP_NEXT_HOP 17
7.10.4. Source VLAN ID 17
7.10.5. Destination VLAN ID 17
7.11. Virtual Information 17
7.11.1. Source Virtual Address 17
7.11.2. Source Virtual Port 18
7.11.3. Destination Virtual Address 18
7.11.4. Destination Virtual Port 18
7.12. Vendor Specific 19
7.13. Misc. Information Elements 19
7.13.1. Flow Label 19
7.13.2. Flow Direction 19
7.13.3. Fragment ID 19
7.13.4. Internal queue priority 19
7.13.5. Global VPN Identifier 20
7.13.6. ICMP_TYPE 20
7.13.7. IGMP_TYPE 20
7.14. Sampling 20
7.14.1. SAMPLING_INTERVAL 20
7.14.2. SAMPLING_ALGO 20
8. IANA Consideration 20
9. Security Section 20
10. References 21
11. Acknowledgements 22
12. Author's Addresses 23
13. Full Copyright Statement 24
14. To Add 24
1. Introduction
Many applications e.g., Intrusion detection, traffic
engineering, 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 data,
which may be used by the exporter for IP traffic flow monitoring
an measuring.
2. Scope
This document defines information data model for IPFIX[3].
Specifically, this document describes a general purpose flow
definition along with the data elements which may be exported.
3. Terminology
To be filled out
4. Flow Type and Flow Definition
As defined in the requirement draft [1],
"A flow is a set of packets passing an observation point in
IPFIX Working Group Expires August 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
the network during a certain time interval. All packets
belonging to a particular flow have a set of common
properties derived from the data contained in the packet and
from the packet treatment at the observation point."
In this draft 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. 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 of the flow. Flows can be defined in multiple
ways. Some examples are:
Example 1:
To create flows, we define the different fields to distinguish
flows. The different combination of the field values creates
unique flows. If the keys are defined as {source IP address,
destination IP address, TOS}, then all of these are different
flows.
1. {192.1.40.1, 171.6.23.5, 4}
2. {192.1.40.23, 171.6.23.67, 4}
3. {192.1.40.23, 171.6.23.67, 2}
4. {198.20.9.200, 171.6.23.67, 4}
Example 2:
To create flows, we can apply a match function to all the packets
that pass through an observation point, in order to aggregate some
values. This could be done by defining the keys as {source IP
address, destination IP address, TOS} like in the example 1, and
applying the function which masks the least significant 8 bits of
the source IP address and destination IP address (i.e. the
resultant is a /24 address). The 4 flows from example 1 would now
be aggregated into 3 flows, by merging the flows 1. and 2. into a
single flow.
1. {192.1.40.0/24, 171.6.23.0/24, 4}
2. {192.1.40.0/24, 171.6.23.0/24, 2}
3. {198.20.9.0/24, 171.6.23.0/24, 4}
Example 3:
IPFIX Working Group Expires August 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
To create flows, we can filter some field values on all packets
that pass the observation point, in order to select only certain
flows. The filter is defined by choosing fixed values for specific
fields from the packet.
All the packets that go from a customer network 192.1.40.0/24 to
another customer network 171.6.23.0/24 with TOS value of 4 define
a flow. All other combinations don't define a flow and are not
taken into account. The 3 flows from example 2 would now be
reduced to 1 flow, by filtering away the second and the third
flow. {192.1.40.0/24, 171.6.23.0/24, 4}.
The above example can be thought of as a function F takes as input
{source IP address, destination IP address, TOS}. The function
selects only the packets which satisfy all the 3 conditions which
are:
* mask the least significant 8 bits of source IP address,
compare against 192.1.40.0.
* mask the least significant 8 bits of destination IP address,
compare against 171.6.23.0.
* tos value equal to 4.
Depending on the values of {source IP address, destination IP
address, TOS} of the different observed packets, the metering
process function F would choose/filter/aggregate different sets of
packets, which would create different flows. In other words,
based on various combination of values of {source IP address,
destination IP address, TOS}, F(source IP address, destination IP
address, TOS) would result in the definition of one or more flows.
The function F is referred to as Flow Type.
4.1. Observation Point
For definition refer to section 1.2. A flow is uniquely defined by
the way it gets measured at an observation point.
Example:
The flow defined in the example 1 of section 2., can be used at 2
different observation points 'a' and 'b' in 2 different ways.
Observation point 'a' measures the packets that match the flow
{192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and
'b' measures packets that match the same flow with a sampling rate
of 1 in 100.
4.2. Unidirectional and Bidirectional Flows
A flow defined by the above terms is unidirectional. In case the
exporter has got the knowledge of the bi-directional flows and in
case the bi-directional information make sense, the exporter MAY
choose to export in the same Template/Flow Record, along with
IPFIX Working Group Expires August 2002 [Page 5]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
bidirectional accounting information. This would save some
bandwidth as the exporter won't have to send two unidirectional
flow records.
Let {KF1,KF2.., KFn} define the set of fields consisting of at
least one of :
a. one or more of packet header fields
b. one or more properties of the packet itself
c. one or more of fields derived from packet treatment
The corresponding flow is F(KF1,KF2.., KFn). If the flow has any
characteristics which pertain to a direction w.r.t to the wire,
then it is a uni-directional flow. Say <KFi, KFj> forms a pair
which defines the <source, destination> characteristic in a
direction w.r.t wire. If <KFj, KFi> defines the <source,
destination> in the other direction w.r.t the wire, then Bi-
directional flow can be defined as
F(KF1,.. <KFj,KFi | KFi,KFJ> , ...KFn).
Where "|" means "OR" and <> just delimits the internal set.
5. Metering Process Functions
5.1. Flow Classification
The collector MUST be able to map the flow to the corresponding
property types defined by the flow type. This can be done only if
the collector has a mapping from flow type identifier (carried in
each flow record) to its actual structure. More details of how
this can be achieved are described in section 5.???
In addition the collector, when it receives the flow records, MAY
need the following interpreting the flow records further:
A. Observation Point.
B. Selection Criteria of Packets
As mentioned in section 2.1, a flow record can be better analyzed
if the Observation Point from which it is measured is known. As
such it is recommended that the flow record carry the Observation
Point information along with the flow records when exported. In
cases where there is a single observation point or where the
observation point information is not relevant, the exporter MAY
choose not to add this to the flow records.
5.2. Selection Criteria Of Packets
The measurement device MAY define rules so that only certain
packets within a flow can be chosen for measurement at an
IPFIX Working Group Expires August 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
observation point. This MAY be done by one of the two types of
methods defined below or a combination of them. A combination of
each of these ways can be adopted to select the packets .i.e. one
can define a set of methods {F1, S1, F2, S2, S3} executed in
certain sequence at an observation point to collect flows of a
particular type.
5.2.1. Function on properties that determines a flow type (Fi)
Packets that satisfy a function on the fields defined by the
packet header fields or fields obtained while doing the packet
processing or the properties of the packet itself.
Example:
Mask/Match of the fields that define a filter. The filter may be
defined as {Protocol == TCP, Destination Port between 80 and 120}.
Multiple such filters could be used in any sequence to select
packets.
5.2.2. Sampling packets on a flow type (Si)
Packets that satisfy the sampling criteria for this flow type.
Example:
Sample every 100th packet that was received at an observation
point and collect the flow information for a particular flow type.
choosing all the packets is a special case where sampling rate is
1:1.
5.3. Selection Criteria of flows for export
The measurement device MAY define additional rules so that only
certain flows records are picked up for export. This MAY be done
by either one of the two types of methods defined in 2.3.1 and
2.3.2 or a combination of them.
Example:
The flow records which meet the following selection criteria are
only exported.
1 All flow records whose destination IP address matches
{20.3.1.5}.
2 Every other (.i.e. sampling rate 1 in 2) flow record whose
destination IP address matches {160.0.1.30}.
IPFIX Working Group Expires August 2002 [Page 7]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
5.4. Flow Expiration
A flow is considered to be inactive if no packets of this flow has
been observed at the observation point for a given timeout
interval. The flow can be exported under the following conditions:
1. If the exporter can deduce the end of a flow, the exporter
SHOULD export the flow records when the end of the flow is
detected. For example: flow generated by TCP type of traffic
where the FIN or RST bits indicate the end of the flow
2. If the flow has been inactive for a certain period of time.
This inactivity timeout SHOULD be configurable. For
example: flow generated by UDP type of traffic.
3. For long aging flows, the exporter SHOULD export the flow
records on regular basis, in order to:
a. report the flow records periodic accounting information
to the collector
b. avoid counter wrapping This activity timeout SHOULD be
configurable
4. If the exporter experiences resources constraints, a flow
MAY be prematurely expired (example: memory)
6. Information Model
The IPFIX information model is listed in the IPFIX requirement
document. The information model consists of the set of attributes
that an IPFIX exporting device should be able to export. In
conjunction with IP flow definitions, they provide locally
accurate information about a flow.
This section presents a rigorous definition and sufficient
statistics for these attributes.
6.1. Attributes related to IP Packet Header
The following attributes are obtained directly from IP packet
header belonging to a flow:
* IP Version Number
* Source Address
* Destination Address
* Source Port (e.g. TCP port number)
* Destination Port (e.g. TCP port number)
* Protocol Type
* TOS (for version 4)
* Flow Label (for version 6)
* DSCP (if DiffServ is supported)
IPFIX Working Group Expires August 2002 [Page 8]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
6.2. Attributes Related to Measurement
The following attributes relates to measurements and measuring
methodology:
* Packet Counter
* Dropped Packet Counter
* Byte Counter
* Dropped Byte Counter
* Timestamp of the First Packet Observed
* Timestamp of the Last Packet Observed
* Timeout Indication
* Sampling Method
* Sampling Parameters
6.3. Attributes Related to Flow Definition
The following attributes relates to IP flow definitions.
* Incoming Interface
* Outgoing Interface
* Packet Treatment
* Unique ID of the Observation Point
* Unique ID of the Measuring Device
6.4. Attributes related to Upper Layers
The following attributes provides information of lower layer
protocols.
* MPLS Label (if MPLS is supported)
7. Information Elements
All element descriptions contain the following information:
Field Type:
This is the type of element the field is. All values are defined
in the TEXTUAL CONVENTIONS in the IETF rfcs. For example, a
source address is defined as field defined IpAddress from SNMPv2-
SMI (RFC 1443).
[This needs to be filled in on all the fields]
Size:
The size of the Data FlowSet including FlowSet ID and the Length .
7.1.IP Address
7.1.1. Source Address
IPFIX Working Group Expires August 2002 [Page 9]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Source address taken from the packet header. Addresses can be of
any type as described in RFC 1700 [note - we need a new reference
here, 1700 has been obsoleted]
[ Do we want to be even more specific and say
"taken from the IP packet header"
Is there a reason to report L2 addresses? ]
Field Type: ### Size: ###
7.1.2. Destination Address
Destination address taken from the packet header. Address is
defined the same as for Source Address.
Field Type: ### Size: ###
7.1.3. NEXT_HOP_IP
Address of the next hop. address is defined the same as for Source
Address .
Field Type: ### Size: ###
7.2.Time Stamps
[ Note - there are several concepts in the time
section. We certainly can and will argue
about whether there is unnecessary
duplication or not.
For now I just wanted to get the ideas down
]
7.2.1. Flow Creation Time
The time at which the flow was created. The time is a
SNMPv2 TimeStamp [1443].
Field Type: ### Size: ###
7.2.2. Flow End Time
The time at which the flow was deleted. The time is a SNMPv2
TimeStamp [1443].
[ Do we need a reason code? e.g. inactivity,
detected TCP FIN.
]
IPFIX Working Group Expires August 2002 [Page 10]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Field Type: ### Size: ###
7.2.3. Flow Start UTC Time
The time in seconds since 00:00:00 UTC, January 1, 1970 associated
with the status/statistics observed or other events. If both Time
and UTC_TIME are present, UTC Time takes precedence.
Field Type: ### Size: ###
7.2.4. Flow End UTC Time
The time in seconds since 00:00:00 UTC, January 1, 1970 associated
with the status/statistics observed or other events.
[ Need to define what happens if more If both Time IE is
present ]
Field Type: ### Size: ###
7.2.5. Flow Update Start Time
Defines the time at the start of the flow Update. The time is a
SNMPv2 TimeStamp [1443].
Field Type: ### Size: ###
7.2.6. Flow Update End Time
Defines the time at the end of the flow Update. The time is a
SNMPv2 TimeStamp [1443].
Field Type: ### Size: ###
7.2.7. Flow Update Delta Time
The time covered by the update (e.g. update end -
update_start).The time is in 100ths of seconds.
Field Type: ### Size: ###
7.3.Service Types
7.3.1. Class of Service
The class of service associated with a flow.
Class of Service Received
Class of Service Transmitted
IPFIX Working Group Expires August 2002 [Page 11]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
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]
[Can more than one Class of Service can be present???]
Field Type: ### Size: ###
7.3.2.TCP Control Bits
The TCP control bits seen for this flow. Note a 0 value for each
bit only indicates that the flag was not detected (i.e. it may
have occurred but was not detected by the reporting CCE). TCP
Control Bits are defined by RFC 793.
[ Do we need another field with a more definitive
meaning for 0??
]
Field Type: ### Size: ###
7.3.3.Protocol Identifier
e.g. TCP/UDP [ need an RFC reference here. PAC]
Field Type: ### Size: ###
7.3.4. Source Exporter [ is that the right term?? PAC] Address
Source Exporter address is the address of the Exporter reporting
the flow, Address is same as is as shown for Source Address. This
information is used by applications to later correlate the
ingress/egress port with a specific Exporter. It is also used to
maintain the source Exporter information when there is an
intermediate proxy. For example, given the picture below:
SW1 -------- P1 ------ Collector
^
|
SW2---------- |
Flows coming from SW1 and SW2 through proxy P1 would look to the
Collector [ is this the right term??? PAC] like the same Exporter
connection. With the Source Exporter in the message the original
Exporter address is maintained.
[ Does this belong here or in the Arch doc? I think
in the arch doc.
]
IPFIX Working Group Expires August 2002 [Page 12]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Field Type: ### Size: ###
7.4. Flow End State
The reason the flow has ended.
1. Inactivity timeout
2. End of flow detected (e.g. TCP FIN)
3. Forced end ????
4. Cache full
Field Type: ### Size: ###
7.5.Statistical Elements
To be expanded
7.5.1. Byte Count
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.
Field Type: ### Size: ###
7.5.2. Packet Count
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.
Field Type: ### Size: ###
IPFIX Working Group Expires August 2002 [Page 13]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
7.5.3. Dropped Byte Count
Contains the count of octets dropped at the observation point
associated with the identified flow.
The dropped byte count can be a running counter and is the count
from the beginning of the flow establishment.
The byte count can be a delta counter and is the count since the
last report for this flow.
Field Type: ### Size: ###
7.5.4. Dropped Packet Count
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.
Field Type: ### Size: ###
7.5.5. IPM_DPKTS
Packet count for IP Multicast
Field Type: ### Size: ###
7.5.6. IPM_DOCTETS
Octet (byte) count for IP Multicast
Field Type: ### Size: ###
7.6.Port Information
To be added
7.6.1. Source Port
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.
Field Type: ### Size: ###
IPFIX Working Group Expires August 2002 [Page 14]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
7.6.2. Destination Port
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.
Field Type: ### Size: ###
7.7.Autonomous System (AS)
To be added
Field Type: ### Size: ###
7.7.1. Source AS
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):
Field Type: ### Size: ###
7.7.2. Destination AS
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).
Field Type: ### Size: ###
7.7.3.Next Hop AS
The Autonomous System (AS) numbers for the next hop IP. Autonomous
System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).
Field Type: ### Size: ###
7.8.IfIndexes and Interfaces
To be added
7.8.1. Ingress Port
The ifIndex where the packets for the flow are being received.
ifIndex is defined by RFC 2233.
Field Type: ### Size: ###
IPFIX Working Group Expires August 2002 [Page 15]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
7.8.2. Egress Port
The ifIndex where the packets for the flow are exiting. ifIndex is
defined by RFC 2233.
[ Do multi-cast flow cause us to possible have
more than one of these??
PAC
]
Field Type: ### Size: ###
7.8.3. Egress ATM Subinterface
The egress vpi/vci for the flow is provided in this Information
element. vpi/vci id defined by the ATM Forum UNI 3.1
specification:
Field Type: ### Size: ###
7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE
The egress DLCI for the flow is provided in this Information
element. ITU Q.922 defines the DLCI range. The frDlcmiState is
defined in RFC 2115 and defines the specific values of the DLCI.
Field Type: ### Size: ###
7.9.NetMasks
7.9.1. Source Address Netmask
The number of bits in the CIDR netmask, as defined in RFC 1519,
for the source address.
Field Type: ### Size: ###
7.9.2. Destination Address Netmask
The CIDR netmask, as defined in RFC 1519, for the destination
address.
Field Type: ### Size: ###
7.10.BGP & Vlan 's
7.10.1. Destination BGP Community
The BGP community number for the destination address. BGP
IPFIX Working Group Expires August 2002 [Page 16]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
community number is defined by RFC 1997:
Field Type: ### Size: ###
7.10.2. Source BGP Community
The BGP community number for the source address.
Field Type: ### Size: ###
7.10.3. BGP_NEXT_HOP
Next-hop router in the BGP domain
Field Type: ### Size: ###
7.10.4. Source VLAN ID
The Source VLAN ID associated with the flow. VLAN ID is defined by
IEEE standard 802.1q - 1998[802.1q].
[ Is this ultimate source VLAN or the source vlan of the port
where the packet came in? Or do we need a way to represent
both? ]
Field Type: ### Size: ###
7.10.5. Destination VLAN ID
The destination VLAN ID associated with the flow. VLAN ID is
defined by IEEE standard 802.1q - 1998[802.1q].
[ Is this ultimate destination VLAN or the destination vlan of
the port where the packet went out? Or do we need a way to
represent both?]
Field Type: ### Size: ###
7.11.Virtual Information
7.11.1. Source Virtual Address
An Exporter may be involved in redirecting flows. This information
element captures information needed for proper accounting of
redirected flows. The Source Virtual information element contains
the source address of the flow as transmitted by the Exporter. It
is generally different than the source address information
element, which contains the address of the actual source of the
message.
IPFIX Working Group Expires August 2002 [Page 17]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
A type field would contain the type of translation performed on
the source address. The following types are currently available:
1 - NAT
2 - LSNAT
3 - Web Cache
The address is defined the same as for Source Address.
Field Type: ### Size: ###
7.11.2. Source Virtual Port
A CCE may be involved in redirecting flows. This information
element captures information needed for proper accounting of
redirected flows. The Source Virtual port information element
contains the source port of the flow as transmitted by the CCE. It
may be different than the source port information element, which
contains the port of the actual source of the flow. An IP
Protocol field is present and is defined by the IP protocol spec
[RFC 791] (e.g. TCP/UDP). The fields indicate how to interpret the
port value field.
A type field contains the type of translation performed on the
source port. The following types are currently available:
1 - NAT
2 - LSNAT
3 - Web Cache
Field Type: ### Size: ###
7.11.3. Destination Virtual Address
The Destination Virtual information element contains the
destination address of the flow as received by the Exporter. It is
generally different than the destination port number, which
contains the actual destination address of the flow.
Field Type: ### Size: ###
7.11.4. Destination Virtual Port
The Destination Virtual port information element contains the
destination port of the flow as received by the Exporter. It may
be different than the destination port recorded in the destination
port, which contains the actual destination port of the flow.
Field Type: ### Size: ###
IPFIX Working Group Expires August 2002 [Page 18]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
7.12. Vendor Specific
Vendors may add their own information to the protocol. Information
contained in this information element is vendor specific. OID and
OID Value are defined by ITU X.680.X683 (1997) and are encoded as
defined by ITU X.690.691(1997). This information element MUST not
contain any information which cannot be safely ignored by the
Exporter or Collector. If multiple Vendor Specific information
element's with the same OID occur, then the vendor defines
semantics of ordering.
Field Type: ### Size: ###
7.13.Misc. Information Elements
7.13.1.Flow Label
The Flow Label information element contains the IPV6 Flow Label
information as defined by RFC 2460.
Field Type: ### Size: ###
7.13.2. Flow Direction
The direction of the flow observed at the observation point. If
the observation point is a set of interface(s) the direction is
w.r.t the wire.
Field Type: ### Size: ###
7.13.3. Fragment ID
The fragment ID associated with the flow. RFC 791 and RFC 2460
define fragment ID.
Field Type: ### Size: ###
7.13.4. Internal queue priority
A switch may map several of its internal priority queues into a
Premium, High, Medium or Low category.
[ This section needs more]
Field Type: ### Size: ###
7.13.5.Global VPN Identifier
IPFIX Working Group Expires August 2002 [Page 19]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
The VPN identifier associated with the flow as defined in RFC
2685.
Field Type: ### Size: ###
7.13.6. ICMP_TYPE
ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP
code
[We need a spec reference.]
Field Type: ### Size: ###
7.13.7. IGMP_TYPE
IGMP Packet Type
[We need a spec reference.]
Field Type: ### Size: ###
7.14.Sampling
7.14.1. SAMPLING_INTERVAL
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.
Field Type: ### Size: ###
7.14.2. SAMPLING_ALGO
The type of algorithm used for sampling data. Currently, the only
sampling algorithm defined is:
0x02 packet-sampling
Field Type: ### Size: ###
8. IANA Consideration
To be filled out.
9. Security Section
To be filled out.
IPFIX Working Group Expires August 2002 [Page 20]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
10. References
3. J. Quittek ,et al.," Requirements for IP Flow Information
Export ", (work in progress) ,Internet Draft, Internet
Engineering Task Force, <draft-ietf-ipfix-reqs-00.txt>,
November 2001
4. M. Wood ,et al.," Intrusion Detection Message Exchange
Requirements",(work in progress), Internet Draft, Internet
Engineering Task Force, draft-ietf-idwg-requirements-
06,February 2002.
5. Daniel O. Awduche, et. al.," Overview and Principles of
Internet Traffic Engineering", (work in progress), Internet
Draft, Internet Engineering Task Force, draft-ietf-tewg-
principles-02.txt, May 2002
[Brow00] Nevil Brownlee: Packet Matching for NeTraMet
Distributions,
http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-
adelaide/pp-dist/
[DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation
Metric for IPPM,
<draft-ietf-ippm-ipdv-08.txt>, November 2001
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
Loss Metric for IPPM, September 1999
[ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun:
Application of Sampling Methodologies to Network Traffic
Characterization, Proceedings of ACM SIGCOMM'93,
San Francisco, CA, USA, September 13 - 17, 1993
[GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed
MARTENS, John G. CLEARY:
Nonintrusive and Accurate Measurement of Unidirectional Delay and
Delay Variation on
the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998
[DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory
Sampling for Direct Traffic
Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
August 28 -
September 1, 2000.
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
Metric for IPPM,
Request for Comments: 2679, September 1999
[ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle:
IPFIX Working Group Expires August 2002 [Page 21]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Evaluation of Building Blocks
for Passive One-way-delay Measurements, Proceedings of Passive and
Active Measurement
Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
(PAM 2001)
[MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture
and framework," work in progress. October 2001.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663, August
1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001.
[PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for
Provider Provisioned Virtual Private Networks ", work in progress,
<draft-ietf-ppvpn-framework-03.txt>, January 2002.
[VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
<draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.
[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998.
[1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt>
<http://www.ietf.org/html.charters/ipfix-charter.html>
[2] K.Zhang, et al., "Common Reliable Accounting for Network
Element (CRANE)", <draft-kzhang-crane-protocol-02.txt>, February
2002
[3] G. Sadasivan, et al., "Flow Export Architecture", <draft-
cisco-ipfix-arch-00.txt>, January 2002
[4] Carlson, James, "PPP Design, Implementation and Debugging",
Second Edition .
11. Acknowledgements
We like to thank all the people contributing to the requirements
discussion on the mailing list, and the design teams for a lot of
valuable comments.
George Carle
Tanja Zseby
Paul Calato
Dave Plonka
Kevin Zhang
KC Norseth
Benoit Claise
IPFIX Working Group Expires August 2002 [Page 22]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Ganesh Sadasivan
Vamsi Valluri
Ram Gopal
Jc Martin
Carter Bullard
Juergen Quittek
Reinaldo Penno
Nevil Brownlee
Simon Leinen
12. Author's Addresses
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Paul Calato
Riverstone Networks, Inc.
5200 Great America Parkway
Santa Clara, CA 95054 USA
Phone: +1 (603) 557-6913
Email: calato@riverstonenet.com
Ganesh Sadasivan
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 (408) 527-0251
Email: gsadasiv@cisco.com
Ram Gopal
Nokia
5 Wayside Road,
Burlington, MA 01803
Phone:+1 781 993 3685
Email: ram.gopal@nokia.com
Man Li
Nokia
5 Wayside Road,
Burlington, MA 01803
Phone: +1 781 993 3923
Email: man.m.li@nokia.com
K.C. Norseth
Enterasys Networks
2691 S. Decker Lake Lane
Salt Lake City, Utah 84119
IPFIX Working Group Expires August 2002 [Page 23]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
Phone: +1 801 887 9823
Email: knorseth@enterasys.com
Reinaldo Penno
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9-B1240
Santa Clara, CA 95134
Email: rpenno@nortelnetworks.com
Juergen Quittek
NEC Europe Ltd.
Adenauerplatz 6
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@ccrle.nec.de
Kevin Zhang
XACCT Technologies, Inc.
2900 Lakeside Drive
Santa Clara, CA 95054
Phone +1 301 992 4697
Email: kevin.zhang@xacct.com
Tanja Zseby
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Phone: +49 30 3463 7153
Email: zseby@fokus.gmd.de
13. Full Copyright Statement
"Copyright (C) The Internet Society (date). 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.
14. To Add
We should have as example of how the flow packet works. A good
IPFIX Working Group Expires August 2002 [Page 24]
INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002
example is what a NetFlow v5 packet looks like with this data
model.
IPFIX Working Group Expires August 2002 [Page 25]
