Biflow implementation support in IPFIX
Internet-Draft B. Trammell
Document: draft-trammell-ipfix-biflow-00.txt CERT/NetSA
Expires: August 2006 E. Boschi
Hitachi Europe
February 2006
Biflow implementation support in IPFIX
draft-trammell-ipfix-biflow-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Trammell, Boschi Expires August 2006 [Page 1]
Biflow implementation support in IPFIX
Abstract
This document describes how bidirectional flows (biflows) can
be implemented in the IP Flow Information Export (IPFIX)
protocol. It defines biflows in terms of the IPFIX information
model, explores methods for exporing biflow data via IPFIX with
the current version of the protocol, and proposes a set of
information model extensions for more efficient biflow export
and collection.
Table of Contents
1. Introduction............................................2
2. Terminology.............................................3
3. Existing Biflow Implementation Strategies...............3
3.1 Two-Record Flow Association using record adjacency.......3
3.2 Record Adjacency Example.................................4
4. Single Record biflows...................................5
4.1 Biflow Semantics.........................................5
4.2 New Information Elements for Single Record biflows.......6
4.2.1 reverseOctetDeltaCount.................................6
4.2.2 reversePostOctetDeltaCount.............................6
4.2.3 reverseOctetDeltaSumOfSquares..........................6
4.2.4 reverseOctetTotalCount.................................6
4.2.5 reversePostOctetTotalCount.............................6
4.2.6 reverseOctetTotalSumOfSquares..........................7
4.2.7 reversePacketDeltaCount................................7
4.2.8 reversePostPacketDeltaCount............................7
4.2.9 reversePacketTotalCount................................7
4.2.10 reversePostPacketTotalCount...........................7
4.2.11 reverseDroppedOctetDeltaCount.........................8
4.2.12 reverseDroppedPacketDeltaCount........................8
4.2.13 reverseDroppedOctetTotalCount.........................8
4.2.14 reverseDroppedPacketTotalCount........................8
4.3 Single Record Biflow Example.............................9
5. IANA Considerations.....................................9
6. Security Considerations................................10
7. References.............................................10
7.1 Normative References....................................10
7.2 Informative References..................................10
8. Acknowledgements.......................................10
9. Author's Addresses.....................................10
10. Intellectual Property Statement........................11
11. Copyright Statement....................................11
12. Disclaimer.............................................11
Appendix A. Formal Specification of Single Record Biflow
Information Elements...................................11
1. Introduction
Many flow analysis tasks benefit from association of the
upstream and downstream flows of a bidirectional communication,
e.g., separating answered and unanswered TCP requests,
calculating round trip times, etc. Metering processes that are
not part of an asymmetric routing infrastructure are well
positioned to observe bidirectional flows (biflows), and IPFIX
is very nearly complete as a solution for exporting biflow data.
Indeed, IPFIX may presently be used to export biflow data
without any changes to the protocol. This draft explores two
methods for doing so. However, IPFIX flow export and collection
using these methods are not as efficient as possible. To that
Trammell, Boschi Expires August 2006 [Page 2]
Biflow implementation support in IPFIX
end, we propose extensions to the IPFIX Information Model to
include biflow-related Information Elements (IEs).
2. Terminology
Uniflow (unidirectional flow)
A uniflow is a set of IP packets passing an Observation
Point in the network during a certain time interval. All
packets belonging to a particular Uniflow have a set of
common properties. Each property is defined as the result
of applying a function to the values of:
1. One or more packet header fields, transport header
fields, or application header fields.
2. One or more characteristics of the packet itself.
3. One or more fields derived from packet treatment.
A packet is said to belong to a Uniflow if it completely
satisfies all the defined properties of the Uniflow.
This definition is simply the IPFIX definition of an IP
Flow [IPFIX-PROTO].
Directional Key Field
A directional key field is a single field in a Flow Key as
defined in [IPFIX-PROTO] that is specifically associated
with a single endpoint of the flow. sourceIPv4Address and
destinationTransport Port are example directional key
fields.
Non-directional Key Field
A non-directional key field is a single field within a Flow
Key as defined in [IPFIX-PROTO] that is not specifically
associated with either endpoint of the flow.
protocolIdentifier is an example non-directional key field.
Biflow (bidirectional flow)
A biflow is an association of the two uniflows comprising a
bidirectional communication session (e.g., a TCP session,
UDP DNS query and answer) according to the following
conditions:
1. each non-directional key field of each uniflow is
identical to its counterpart in the other
2. each directional key field of each uniflow is identical
to its reverse direction counterpart in the other
3. Existing Biflow Implementation Strategies
3.1 Two-Record Flow Association using record adjacency
The simplest way for an Exporting Process that uses a biflow-
based internal data model to implement flow export using IPFIX
is simply to split the biflow into two uniflow records at export
time. The two uniflow sides of the biflow can then be placed
adjacent to each other in the IPFIX Message, with the initiating
uniflow (the first uniflow seen by the Metering Process)
Trammell, Boschi Expires August 2006 [Page 3]
Biflow implementation support in IPFIX
appearing in the message first. This simple arrangement provides
enough information for a Collecting Process which uses a biflow-
based internal data model to reassemble the biflow without
requiring any computationally-intensive flow matching.
This method has the benefit of extreme simplicity. However, it
also has the disadvantage of extreme simplicity. It is not a
protocol so much as an informal arrangement; Collecting
Processes with biflow- based internal data models cannot rely on
the courtesy of the Exporting Process to arrange biflow halves
adjacently in the flow record stream and so must support
computationally-intensive flow matching anyway. It is also
record space inefficient in that every key field in the first
uniflow, whether directional or non- directional, is duplicated
in the second uniflow record.
3.2 Record Adjacency Example
Assuming that each uniflow record is described by the following
simple template:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a two-record adjacent biflow counting octets in a typical HTTP
transaction might look like the following:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID >= 256 | Length = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.0.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.0.0.200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 2500 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 2006-02-01 17:00:01 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 10.0.0.200 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 10.0.0.100 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 80 | 32770 . . .
Trammell, Boschi Expires August 2006 [Page 4]
Biflow implementation support in IPFIX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 6 | 450000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notice that this trivial example duplicates 13 bytes of key
information per biflow.
4. Single Record Biflows
IPFIX can be used to represent biflows using a single flow
record per biflow through an extension the IPFIX information
model. We propose the addition of a set of "reverse" counters to
count packets sent by the biflow destination. The presence of
the reverse counters in a Flow Record would overload the
definition of the current "forward" counters to count packets
sent by the biflow source.
Note that no reverse post-multicast counters are defined,
because multicast flows are inherently unidirectional.
4.1 Biflow Semantics
The addition of reverse counters to the IPFIX information model
is not without complications. When handling uniflows, the
semantics of "source" and "destination" information elements are
clearly defined by the semantics of the underlying packet header
data. When grouping biflows into single IPFIX data records, the
definitions of "source" and "destination" become less clear.
The most basic method for classifying the two addresses in a
biflow is to define the source address of the flow as the source
address of the first packet seen in that flow by the metering
process. Some metering technologies may attempt to improve upon
this method using some knowledge of the transport or application
protocols (e.g., TCP flags, DNS question/answer counts) in order
to define the source address of the flow as the connection or
transaction initiator while compensating for packet loss. In
either case, the design is the same: one of the underlying
uniflows is assumed to be in the "forward" direction, and one in
the "reverse" direction; the "forward" uniflow is selected based
upon some characteristic of the connection itself.
To support single-record biflow export, Metering Process
implementations MUST assign the forward and reverse direction
such that the forward direction treats the flow initiator as
source, to the best ability of the metering process to determine
the flow initiator. Communicating minor variations among
different approaches to determine the flow initiator are outside
the scope of the IPFIX protocol.
More complex methods of assigning direction exist. One alternate
way to classify biflow addresses is by perimeter; in
this method, a metering process discriminates between "inside"
and "outside" the network, and defines the source address as
the address on one side of this perimeter (generally the
"outside" address; defining source loosely as "attacker"). This
approach is popular in security-focused flow collection tools.
However, it is not as universally applicable to IP flow export
in general. Handling perimeter biflow data, or any biflow data
with direction not arranged by flow initiator, is outside the
scope of this draft.
Trammell, Boschi Expires August 2006 [Page 5]
Biflow implementation support in IPFIX
4.2 New Information Elements for Single Record Biflows
The following information elements are required to support
single record biflows:
4.2.1 reverseOctetDeltaCount
Description:
The number of octets since the previous report (if any) in
packets sent by the biflow destination for this biflow.
The number of octets includes IP header(s)and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 216
Status: proposed
Units: octets
4.2.2 reversePostOctetDeltaCount
Description:
The definition of this Information Element is identical to
the definition of Information Element
'reverseOctetDeltaCount',
except that it reports a potentially modified value caused
by a middlebox function after the packet passed the
observation
point.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 217
Status: proposed
Units: octets
4.2.3 reverseOctetDeltaSumOfSquares
Description:
The sum of the squared numbers of octets since the
previous report (if any) in packets sent by the biflow
destination for this biflow. The number of octets include
IP header(s) and IP payload.
Abstract Data Type: unsigned64
ElementId: 218
Status: proposed
Units: octets
4.2.4 reverseOctetTotalCount
Description:
The total number of octets in packets sent by the biflow
destination since the Metering Process (re-)initialization
for this Observation Point. The number of octets includes
IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 219
Status: proposed
Units: octets
4.2.5 reversePostOctetTotalCount
Description:
The definition of this Information Element is identical to
the definition of Information Element
'reverseOctetTotalCount', except that it reports a
Trammell, Boschi Expires August 2006 [Page 6]
Biflow implementation support in IPFIX
potentially modified value caused by a middlebox function
after the packet passed the observation point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 220
Status: proposed
Units: octets
4.2.6 reverseOctetTotalSumOfSquares
Description:
The total sum of the squared numbers of octets in packets
sent by the biflow destination for this biflow since the
Metering Process (re-)initialization for this Observation
Point. The number of octets include IP header(s) and IP
payload.
Abstract Data Type: unsigned64
ElementId: 221
Status: proposed
Units: octets
4.2.7 reversePacketDeltaCount
Description:
The number of packets since the previous report (if any)
for this biflow sent by the biflow destination.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 222
Status: proposed
Units: packets
4.2.8 reversePostPacketDeltaCount
Description:
The definition of this Information Element is identical to
the definition of Information Element
'reversePacketDeltaCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 223
Status: proposed
Units: packets
4.2.9 reversePacketTotalCount
Description:
The total number of packets sent by the biflow destination
for this biflow at the since the Metering Process (re-)
initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 224
Status: proposed
Units: packets
4.2.10 reversePostPacketTotalCount
Description:
The definition of this Information Element is identical to
the definition of Information Element
'reversePacketTotalCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
Trammell, Boschi Expires August 2006 [Page 7]
Biflow implementation support in IPFIX
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 225
Status: proposed
Units: packets
4.2.11 reverseDroppedOctetDeltaCount
Description:
The number of octets since the previous report (if any) in
packets sent by the biflow destination for this biflow
dropped by packet treatment. The number of octets include
IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 226
Status: proposed
Units: octets
4.2.12 reverseDroppedPacketDeltaCount
Description:
The number of packets since the previous report (if any)
sent by
the biflow destination for this biflow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 227
Status: proposed
Units: packets
4.2.13 reverseDroppedOctetTotalCount
Description:
The total number of octets in packets sent by the biflow
destination for this biflow dropped by packet treatment
since the Metering Process (re-)initialization for this
Observation Point. The number of octets include IP
header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 228
Status: proposed
Units: octets
4.2.14 reverseDroppedPacketTotalCount
Description:
The total number of packets sent by the biflow destination
for this biflow dropped by packet treatment since the
Metering Process (re-)initialization for this Observation
Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 229
Status: proposed
Units: packets
Trammell, Boschi Expires August 2006 [Page 8]
Biflow implementation support in IPFIX
4.3 Single Record Biflow Example
Assuming that each biflow record is described by the following
simple template:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| reverseOctetTotalCount 219 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a single record biflow counting octets in a the same typical
HTTP transaction as in example 3.2 would look like the
following:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID >= 256 | Length = 29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.0.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.0.0.200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 2500 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 450000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |
+-+-+-+-+-+-+-+-+
5. IANA Considerations
This documents defines a set of new IPFIX Information Elements
that extend those already defined in [IPFIX-INFO].
As specified in [IPFIX-INFO] IANA needs to create a new registry
for IPFIX Information Element identifiers. New assignments for
IPFIX Information Elements will be administered by IANA, on a
First Come First Served basis [RFC2434], subject to Expert
Review [RFC2434], i.e. review by one of a group of expert
designated by an IETF Operations and Management Area Director.
The group of experts must double check the Information Elements
definitions with already defined Information Elements for
completeness, accuracy, redundancy, and correct naming following
the naming conventions in [IPFIX-INFO]. Those experts will
Trammell, Boschi Expires August 2006 [Page 9]
Biflow implementation support in IPFIX
initially be drawn from the Working Group Chairs and document
editors of the IPFIX and PSAMP Working Groups [IPFIX-INFO].
6. Security Considerations
The same security considerations as for the IPFIX protocol
[IPFIX-PROTO] apply.
7. References
7.1 Normative References
[IPFIX-PROTO] B. Claise et Al.: IPFIX Protocol Specification,
Internet-draft work in progress
<draft-ietf-ipfix-protocol-18.txt>, September 2005
[IPFIX-INFO] J. Quittek, S.Bryant, B.Claise, J. Meyer:
Information Model for IP Flow Information Export
Internet-draft work in progress <draft-ietf-ipfix-
info-11.txt>, September 2005
7.2 Informative References
[IPFIX-REQ] J. Quittek, et Al.: Requirements for IP Flow
Information Export, RFC 3917, October 2004
[IPFIX-AS] T. Zseby, E. Boschi, N. Brownlee, B. Claise: IPFIX
Applicability, Internet Draft
<draft-ietf-ipfix-as-06.txt>, June 2005
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
8. Acknowledgements
We would like to thank Lutz Mark for his contribution and
comments.
9. Author's Addresses
Elisa Boschi
Hitachi Europe SAS
Immeuble Le Theleme
1503 Route des Dolines
06560 Valbonne, France
Phone: +33 4 89874180
Email: elisa.boschi@hitachi-eu.com
Brian H. Trammell
CERT Network Situational Awareness
Software Engineering Institute
4500 Fifth Avenue
Pittsburgh, PA 15213
US
Phone: +1 412 268 9748
Email: bht@cert.org
Trammell, Boschi Expires August 2006 [Page 10]
Biflow implementation support in IPFIX
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights 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; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
11. Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
12. Disclaimer
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Appendix A. Formal Specification of Single Record Biflow
Information Elements
This appendix contains a formal description of the IPFIX
information elements required for single record biflow export as
in sections 4.1 and 4.2 of this document. Note that the XML
doocument below is informative, and provided for the convenience
of implementations that use the formal XML specification of
information elements as in Appendix A of [IPFIX-INFO]. The text
in section 4.2 is normative.
<fieldDefinitions>
<field name="reverseOctetDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="216"
status="proposed">
<description>
The number of octets since the previous report (if any)
Trammell, Boschi Expires August 2006 [Page 11]
Biflow implementation support in IPFIX
in packets sent by the biflow destination for this biflow.
The number of octets includes IP header(s) and IP payload.
</description>
</field>
<field name="reversePostOctetDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="217"
status="proposed">
<description>
The definition of this Information Element is identical
to the definition of Information Element
'reverseOctetDeltaCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
</description>
</field>
<field name="reverseOctetDeltaSumOfSquares"
dataType="unsigned64"
fieldId="218"
status="proposed">
<description>
The sum of the squared numbers of octets since the previous
report (if any) in packets sent by the biflow destination for
this biflow. The number of octets include IP header(s) and
IP payload.
</description>
</field>
<field name="reverseOctetTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="219"
status="proposed">
<description>
The total number of octets in packets sent by the biflow
destination since the Metering Process (re-)initialization
for this Observation Point. The number of octets includes
IP header(s) and IP payload.
</description>
</field>
<field name="reversePostOctetTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="220"
status="proposed">
<description>
The definition of this Information Element is identical
to the definition of Information Element
'reverseOctetTotalCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
</description>
</field>
<field name="reverseOctetTotalSumOfSquares"
dataType="unsigned64"
fieldId="221"
status="proposed">
<description>
Trammell, Boschi Expires August 2006 [Page 12]
Biflow implementation support in IPFIX
The total sum of the squared numbers of octets in packets
sent by the biflow destination for this biflow since the
Metering Process (re-)initialization for this Observation
Point. The number of octets includes IP header(s) and IP
payload.
</description>
</field>
<field name="reversePacketDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="222"
status="proposed">
<description>
The number of packets since the previous report (if any)
for this biflow sent by the biflow destination.
</description>
</field>
<field name="reversePostPacketDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="223"
status="proposed">
<description>
The definition of this Information Element is identical
to the definition of Information Element
'reversePacketDeltaCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
</description>
</field>
<field name="reversePacketTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="224"
status="proposed">
<description>
The total number of packets sent by the biflow
destination for this biflow at the since the Metering
Process (re-) initialization for this Observation Point.
</description>
</field>
<field name="reversePostPacketTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="225"
status="proposed">
<description>
The definition of this Information Element is identical
to the definition of Information Element
'reversePacketTotalCount', except that it reports a
potentially modified value caused by a middlebox function
after the packet passed the observation point.
</description>
</field>
<field name="reverseDroppedOctetDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="226"
Trammell, Boschi Expires August 2006 [Page 13]
Biflow implementation support in IPFIX
status="proposed">
<description>
The number of octets since the previous report (if any)
in packets sent by the biflow destination for this biflow
dropped by packet treatment. The number of octets include
IP header(s) and IP payload.
</description>
</field>
<field name="reverseDroppedPacketDeltaCount"
dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldId="227"
status="proposed">
<description>
The number of packets since the previous report (if any)
sent by the biflow destination for this biflow dropped by
packet treatment. The number of octets include IP header(s)
and IP payload.
</description>
</field>
<field name="reverseDroppedOctetTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="228"
status="proposed">
<description>
The total number of octets in packets sent by the biflow
destination for this biflow dropped by packet treatment
since the Metering Process (re-)initialization for this
Observation Point. The number of octets include IP
header(s) and IP payload.
</description>
</field>
<field name="reverseDroppedPacketTotalCount"
dataType="unsigned64"
dataTypeSemantics="totalCounter"
fieldId="229"
status="proposed">
<description>
The total number of packets sent by the biflow
destination for this biflow dropped by packet treatment
since the Metering Process (re-)initialization for this
Observation Point. The number of octets include IP
header(s) and IP payload.
</description>
</field>
</fieldDefinitions>
Trammell, Boschi Expires August 2006 [Page 14]