Internet DRAFT - draft-irino-ipfix-ie-order
draft-irino-ipfix-ie-order
Network Working Group H. Irino
Internet-Draft NTT NS Lab.
Expires: August 28, 2008 Feb 25, 2008
Guidelines for the order of Information Elements
draft-irino-ipfix-ie-order-04
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 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Irino Expires August 28, 2008 [Page 1]
Internet-Draft Order of Information Elements Feb 2008
Abstract
This draft provides guidelines for the order of Information Elements
for Templates of the IPFIX protocol. This draft would like to be
referred as supplementary document for implementations. This draft
provides the referential order for Information Elements in order to
increase efficiency of the Collecting Processes and Exporting
Processes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Purposes of this draft . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Approach to the ordering of Information Elements . . . . . . . 5
3.1. Order of Information Element groups . . . . . . . . . . . 5
3.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Enterprise-specific Information Elements . . . . . . . . . 7
4. Recommended order of Information Elements . . . . . . . . . . 8
5. Applications of order of Information Elements . . . . . . . . 17
5.1. Copy method for multiple adjacent Information Elements . . 17
5.2. Merging with two or more Templates . . . . . . . . . . . . 19
6. Security considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Template composed with Information Elements
equivalent to the NetFlow Version 5 record . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Irino Expires August 28, 2008 [Page 2]
Internet-Draft Order of Information Elements Feb 2008
1. Introduction
This draft provides guidelines for the order of Information Elements
for Templates of the IPFIX protocol. This section states the problem
concerning the order and defines the purposes of this draft.
1.1. Problem statement
The IPFIX protocol provides high flexibility for exporting flow
information by Templates. On the other hand, the flexibility means
that different Templates could contain the same set of Information
Elements in different orders even though the information carried by
the Data Records based on those Templates is essentially the same.
Such a situation could introduce inefficiency into the Exporting
Process and Collecting Process.
For example, when a Mediator [IPFIX-Mediators] aggregates data
records that are based on templates containing the same set of
Information Elements placed in a different order, the Mediator must
change these orders to a unified order in order to export aggregated
data records with a unified template.
If all Exporters in a network could configure templates freely, then
network operators could avoid the above-mentioned problem by using
the same configuration for Templates for all exporters in the
network. However, there is no rule constraining all Exporters of
IPFIX to be freely configurable in terms of Template configuration.
If different Exporters that cannot configure the Template
configuration adopt a different order in the network, then there is a
high probability of the above-mentioned problem occurring with these
Exporters.
1.2. Purposes of this draft
This draft provides a unified referential order for Information
Elements to increase efficiency. Exporters have various
implementations for supported Information Elements and they have
flexibility in terms of template configuration. Therefore, if a
unified order is defined, there is no assurance that exporters will
export the same template. However, a unified order can reduce the
costs of normalizing data records.
Irino Expires August 28, 2008 [Page 3]
Internet-Draft Order of Information Elements Feb 2008
2. Terminology
The terminology used in this document is aligned with the terminology
defined in [RFC5101] and [RFC5102].
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 [RFC2119].
Irino Expires August 28, 2008 [Page 4]
Internet-Draft Order of Information Elements Feb 2008
3. Approach to the ordering of Information Elements
This draft just defines the order among different Information
Elements. It does not define the order among the same Information
Elements. The order among the same Information Elements is
determined by logical order.
The orders of Information Elements in the Scope Fields in Option
Templates cannot be defined in this draft because the orders in Scope
Fields will have a logical meaning. Therefore, orders in Scope
Fields are outside the scope of this draft.
This draft uses the following policies to decide the order. The
first policy has the highest priority and the last one has the
lowest.
1. A unified order of Information Elements is recommended in this
draft.
2. Information Elements are placed separately according to the
Information Element groups defined in [RFC5102].
3. Information Elements derived from packet fields in groups 4-6 are
placed in the order of packet fields.
4. Information Elements are placed in the order described in
[RFC5102] in order to conform to future extensions of the
information model.
3.1. Order of Information Element groups
In this draft, the recommended order for Information Element groups,
except for the padding group defined in [RFC5102], is as follows:
1. Group 1: Identifiers
2. Group 2: Metering and Exporting Process Configuration
3. Group 6: Sub-IP Header Fields
4. Group 4: IP Header Fields
5. Group 5: Transport Header Fields
6. Group 7: Derived Packet Properties
7. Group 8: Min/Max Flow Properties
Irino Expires August 28, 2008 [Page 5]
Internet-Draft Order of Information Elements Feb 2008
8. Group 11: Miscellaneous Flow Properties
9. Group 9: Flow Time Stamps
10. Group 3: Metering and Exporting Process Statistics
11. Group 10: Per-Flow Counters
Some of the Information Elements in group 1 are used to limit the
Scopes, as described in section 5.1 of [RFC5102]. Scope Fields are
placed earlier than non-Scope Fields. Therefore, group 1 is the
earliest in the order.
Some of the Information Elements in group 2 could be used to limit
scopes. For example, exporterIPv4Address or exporterIPv6Address
could be used instead of exporterProcessId as the Scope in the
Exporting Process Reliability Statistics Option Template described in
section 4.3 of [RFC5101]. Therefore, group 2 follows group 1.
Information Elements in groups 4-7 can serve as Flow Keys used for
mapping packets to Flows, as described in section 5 of [RFC5102].
According to [RFC5102], all Flow Keys are among the first 64
Information Elements because the flowKeyIndicator contains only 64
bits. Therefore, Information Elements in groups 4-7 should be placed
earlier than ones in other groups.
Most of the Information Elements in groups 4, 5, and 6 are derived
from the header fields of observed packets. On the other hand,
Information Elements in group 7 are not derived from packet header
fields, but from packet treatment. In general, sub-IP header fields
are placed at the head of the observed packet, IP header fields
follow the sub-IP header, and transport header fields follow the IP
header fields. Therefore, the order of groups is 6, 4, and 5. And
group 7 follows afterward.
Other groups can be classified into three categories. Information
Elements in groups 8 and 11 provide other flow properties.
Information Elements in group 9 provide timestamps. Information
Elements in groups 3 and 10 provide counters for various purposes.
These groups have no priority for group order based on the
definitions in the protocol draft. However, the above-mentioned
group order is expediently provided in this draft to achieve the
purpose of this draft.
3.2. Padding
The Information Element, paddingOctets, can be placed freely to align
Information Elements within Data Records or to align entire Data
Irino Expires August 28, 2008 [Page 6]
Internet-Draft Order of Information Elements Feb 2008
Records to 4-octet or 8-octet boundaries.
3.3. Enterprise-specific Information Elements
This draft recommends that enterprise-specific Information Elements
derived from packet header fields, like IETF-defined Information
Elements in groups 4, 5, and 6, are placed in the order of packet
header fields. For example, if the enterprise-specific Information
Elements derived from the header fields of protocols of layers higher
than the transport protocol (e.g., RTP ssrc), these Information
Elements follow after group 5 (transport header fields).
This draft recommends that enterprise-specific Information Elements
that do not serve as Flow Keys are placed after similar IETF-defined
groups.
Irino Expires August 28, 2008 [Page 7]
Internet-Draft Order of Information Elements Feb 2008
4. Recommended order of Information Elements
This draft recommends that Information Elements in groups 4, 5, and 6
are placed in an order that corresponds to the order of packet header
fields. Information Elements that are not contained in a packet
header follow the set of Information Elements derived from packet
header fields.
However, Information Elements derived from fields of an IPv4 header,
Information Elements derived from fields of an IPv6 header,
Information Elements derived from fields of the headers of both
protocols, and Information Elements that are not contained in a
packet header are mixed in group 4. The recommended order cannot be
the same as the order of packet fields because some IPv4 header
fields and some IPv6 header fields are the same, and these fields are
placed in a different order. Therefore, the recommended order of
Information Elements refers mainly to the order of IPv4 header
fields.
This draft recommends that the order of Information Elements in
groups 1-3 and 7-12 should be the same as the order described in
[RFC5102].
Specifically, the recommended order is as follows:
1. Group 1
1. 141: lineCardId
2. 142: portId
3. 10: ingressInterface
4. 14: egressInterface
5. 143: meteringProcessId
6. 144: exportingProcessId
7. 145: templateId
8. 148: flowId
9. 149: observationDomainId
10. 138: observationPointId
Irino Expires August 28, 2008 [Page 8]
Internet-Draft Order of Information Elements Feb 2008
11. 137: commonPropertiesId
2. Group 2
1. 130: exporterIPv4Address
2. 131: exporterIPv6Address
3. 217: exporterTransportPort
4. 211: collectorIPv4Address
5. 212: collectorIPv6Address
6. 213: collectorInterface
7. 214: collectorProtocolVersion
8. 215: collectorTransportProtocol
9. 216: collectorTransportPort
10. 173: flowKeyIndicator
3. Group 6
1. 56: sourceMacAddress
2. 81: postSourceMacAddress
3. 80: destinationMacAddress
4. 57: postDestinationMacAddress
5. 58: vlanId
6. 59: postVlanId
7. 147: wlanSSID
8. 146: wlanChannelId
9. 70: mplsTopLabelStackSection
10. 203: mplsTopLabelExp
11. 237: postMplsTopLabelExp
Irino Expires August 28, 2008 [Page 9]
Internet-Draft Order of Information Elements Feb 2008
12. 200: mplsTopLabelTTL
13. 71: mplsLabelStackSection2
14. 72: mplsLabelStackSection3
15. 73: mplsLabelStackSection4
16. 74: mplsLabelStackSection5
17. 75: mplsLabelStackSection6
18. 76: mplsLabelStackSection7
19. 77: mplsLabelStackSection8
20. 78: mplsLabelStackSection9
21. 79: mplsLabelStackSection10
22. 202: mplsLabelStackDepth
23. 201: mplsLabelStackLength
24. 194: mplsPayloadLength
4. Group 4
1. 60: ipVersion
2. 207: ipv4IHL
3. 189: ipHeaderLength
4. 5: ipClassOfService
5. 55: postIpClassOfService
6. 195: ipDiffServCodePoint
7. 196: ipPrecedence
8. 31: flowLabelIPv6
9. 190: totalLengthIPv4
10. 224: ipTotalLength
Irino Expires August 28, 2008 [Page 10]
Internet-Draft Order of Information Elements Feb 2008
11. 191: payloadLengthIPv6
12. 54: fragmentIdentification
13. 197: fragmentFlags
14. 88: fragmentOffset
15. 192: ipTTL
16. 4: protocolIdentifier
17. 193: nextHeaderIPv6
18. 8: sourceIPv4Address
19. 12: destinationIPv4Address
20. 27: sourceIPv6Address
21. 28: destinationIPv6Address
22. 9: sourceIPv4PrefixLength
23. 29: sourceIPv6PrefixLength
24. 44: sourceIPv4Prefix
25. 170: sourceIPv6Prefix
26. 13: destinationIPv4PrefixLength
27. 30: destinationIPv6PrefixLength
28. 45: destinationIPv4Prefix
29. 169: destinationIPv6Prefix
30. 206: isMulticast
5. Group 5
1. 7: sourceTransportPort
2. 180: udpSourcePort
3. 182: tcpSourcePort
Irino Expires August 28, 2008 [Page 11]
Internet-Draft Order of Information Elements Feb 2008
4. 11: destinationTransportPort
5. 181: udpDestinationPort
6. 183: tcpDestinationPort
7. 205: udpMessageLength
8. 184: tcpSequenceNumber
9. 185: tcpAcknowledgementNumber
10. 186: tcpWindowSize
11. 238: tcpWindowScale
12. 187: tcpUrgentPointer
13. 188: tcpHeaderLength
14. 32: icmpTypeCodeIPv4
15. 176: icmpTypeIPv4
16. 177: icmpCodeIPv4
17. 139: icmpTypeCodeIPv6
18. 178: icmpTypeIPv6
19. 179: icmpCodeIPv6
20. 33: igmpType
6. Group 7
1. 204: ipPayloadLength
2. 15: ipNextHopIPv4Address
3. 62: ipNextHopIPv6Address
4. 16: bgpSourceAsNumber
5. 17: bgpDestinationAsNumber
6. 128: bgpNextAdjacentAsNumber
Irino Expires August 28, 2008 [Page 12]
Internet-Draft Order of Information Elements Feb 2008
7. 129: bgpPrevAdjacentAsNumber
8. 18: bgpNextHopIPv4Address
9. 63: bgpNextHopIPv6Address
10. 46: mplsTopLabelType
11. 47: mplsTopLabelIPv4Address
12. 140: mplsTopLabelIPv6Address
13. 90: mplsVpnRouteDistinguisher
7. Group 8
1. 25: minimumIpTotalLength
2. 26: maximumIpTotalLength
3. 52: minimumTTL
4. 53: maximumTTL
5. 208: ipv4Options
6. 64: ipv6ExtensionHeaders
7. 6: tcpControlBits
8. 209: tcpOptions
8. Group 11
1. 36: flowActiveTimeout
2. 37: flowIdleTimeout
3. 136: flowEndReason
4. 161: flowDurationMilliseconds
5. 162: flowDurationMicroseconds
6. 61: flowDirection
Irino Expires August 28, 2008 [Page 13]
Internet-Draft Order of Information Elements Feb 2008
9. Group 9
1. 150: flowStartSeconds
2. 151: flowEndSeconds
3. 152: flowStartMilliseconds
4. 153: flowEndMilliseconds
5. 154: flowStartMicroseconds
6. 155: flowEndMicroseconds
7. 156: flowStartNanoseconds
8. 157: flowEndNanoseconds
9. 158: flowStartDeltaMicroseconds
10. 159: flowEndDeltaMicroseconds
11. 160: systemInitTimeMilliseconds
12. 22: flowStartSysUpTime
13. 21: flowEndSysUpTime
10. Group 3
1. 41: exportedMessageTotalCount
2. 40: exportedOctetTotalCount
3. 42: exportedFlowRecordTotalCount
4. 163: observedFlowTotalCount
5. 164: ignoredPacketTotalCount
6. 165: ignoredOctetTotalCount
7. 166: notSentFlowTotalCount
8. 167: notSentPacketTotalCount
9. 168: notSentOctetTotalCount
Irino Expires August 28, 2008 [Page 14]
Internet-Draft Order of Information Elements Feb 2008
11. Group 10
1. 1: octetDeltaCount
2. 23: postOctetDeltaCount
3. 198: octetDeltaSumOfSquares
4. 85: octetTotalCount
5. 171: postOctetTotalCount
6. 199: octetTotalSumOfSquares
7. 2: packetDeltaCount
8. 24: postPacketDeltaCount
9. 86: packetTotalCount
10. 172: postPacketTotalCount
11. 132: droppedOctetDeltaCount
12. 133: droppedPacketDeltaCount
13. 134: droppedOctetTotalCount
14. 135: droppedPacketTotalCount
15. 19: postMCastPacketDeltaCount
16. 20: postMCastOctetDeltaCount
17. 174: postMCastPacketTotalCount
18. 175: postMCastOctetTotalCount
19. 218: tcpSynTotalCount
20. 219: tcpFinTotalCount
21. 220: tcpRstTotalCount
22. 221: tcpPshTotalCount
23. 222: tcpAckTotalCount
Irino Expires August 28, 2008 [Page 15]
Internet-Draft Order of Information Elements Feb 2008
24. 223: tcpUrgTotalCount
Irino Expires August 28, 2008 [Page 16]
Internet-Draft Order of Information Elements Feb 2008
5. Applications of order of Information Elements
When the order of Information Elements is different, these elements
have to be rearranged almost invariably, even if information in the
copy source and copy destination are essentially the same. On the
other hand, rearrangement will not be performed when the order of
Information Elements is the same. Information is copied from
observed packets to an internal Flow Record database (cache) in the
Metering Process, from Flow Records in an internal Flow Record
database to IPFIX Flow Records in the Exporting Process, and from
IPFIX Flow Record to various types of data storage in the Collecting
Process. IPFIX processes have to copy data for different reasons.
Therefore, the efficiency improvement of the copy becomes the
efficiency improvement of the IPFIX processing, and reducing the
number of rearrangements improves efficiency by reducing the number
of copies.
This section describes an example of effective usage of the
processing method using the order of Information Elements mentioned
above.
5.1. Copy method for multiple adjacent Information Elements
Values of Information Elements are copied in the Exporting Process
from the internal Flow Record database to IPFIX Data Records. When
the Collecting Process has to store collected Data Records in various
types of data storage, copies are performed in the Collecting
Process.
Reducing the number of copies increases the performance of these
processes. If the values of multiple Information Elements can be
copied at a time, number of copies is reduced. In the environment in
which each process uses a standard order, the method of copying
multiple adjacent Information Elements is achieved in the specified
order when the following conditions are satisfied.
Data length: The data length of multiple Information Elements in a
copy source and copy destination are the same.
Most Information Elements, whose values are derived from observed
packet header fields, have a fixed length without the reduced size
encoding.
Byte-order: The byte-order of data of multiple Information Elements
in the copy source and copy destination are the same.
When IPFIX devices have a big-endian architecture or data are
coded according to the network byte order, this condition can be
Irino Expires August 28, 2008 [Page 17]
Internet-Draft Order of Information Elements Feb 2008
satisfied easily. On the other hand, when IPFIX devices have a
little-endian architecture, the situations satisfying this
condition are restricted a little.
The Exporting Process can often satisfy this condition because
observed packets are coded according to the network byte order and
exported IPFIX messages are also coded according to the network
byte order. Characteristic properties of Flows are not needed to
convert the byte order even if the processor architecture of
Exporters is not the big-endian architecture.
If the Collecting Process is running on little-endian architecture
and using data coded according to the host byte order, satisfying
this condition on some Information Elements is difficult. On the
other hand, storing values coded according to the network byte
order is better than storing values according to the host byte
order on some Information Elements whose values could be converted
by POSIX functions related to DNS (e.g. inet_ntop).
In addition, although the data structure of Flow Records in an
internal Flow Record database is independents of the order of
Information Elements in Templates, the data structure makes the
comparison between observed packets and Flow Records efficient in the
Metering Process, when the data structure of Flow Records in an
internal Flow Record database is the same as that of packet headers.
The Metering Process has to be repeated to compare incoming packets
to Data Records in an internal Flow Record database to maintain that
database. Exporters that support all Information Elements in
[RFC5102] have to be able to store all fields in packet headers into
their database. It is reasonable that these Exporters adopt the data
structure that is the same as that of packet headers. If multiple
fields that are served as Flow Keys can be compared at a time, a
Metering Process comparing multiple fields at a time will work faster
than a Metering Process comparing a single field at a time.
This draft proposes the orders of packet header fields as criteria
for defining order. If only the data structure of an internal Flow
Record database in Exporter is the same as the data structure of
protocol headers (e.g., IPv4 header, TCP header) in packets, this
proposal enables a method for copying multiple Information Elements
and a method for comparing multiple Information Elements. A
comparison method for multiple Information Elements is achieved by
the following 2 steps:
1. Data masking
2. Comparing memory areas of arbitrary length like the memcmp
function in libc.
Irino Expires August 28, 2008 [Page 18]
Internet-Draft Order of Information Elements Feb 2008
5.2. Merging with two or more Templates
When two or more Templates are merged into a single Template or
single data structure, having the same order is better. That is
because the number of rearrangements of Information Elements can be
minimized. These are example cases:
Mediator exports single IPFIX Messages that are aggregated with
multiple IPFIX messages exported from multiple Exporters.
Collector normalizes Data Records to store them by their
proprietary data structure.
Irino Expires August 28, 2008 [Page 19]
Internet-Draft Order of Information Elements Feb 2008
6. Security considerations
This draft does not directly relate to or introduce any security
issues. The same security considerations as for the IPFIX
Information Model [RFC5102] apply.
Irino Expires August 28, 2008 [Page 20]
Internet-Draft Order of Information Elements Feb 2008
7. IANA considerations
This document has no actions for IANA.
Irino Expires August 28, 2008 [Page 21]
Internet-Draft Order of Information Elements Feb 2008
8. References
[IPFIX-Mediators]
Kobayashi, A., Ishibashi, K., Kondoh, T., and D.
Matsubara, "Reference Model for IPFIX Mediators,
draft-kobayashi-ipfix-mediator-model-01.txt, work in
progress", November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119", March 1997.
[RFC5101] Claise, B., "Specification of the IPFIX Protocol for the
Exchange of IP Traffic Flow Information, RFC5101",
January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export,
RFC5102", January 2008.
Irino Expires August 28, 2008 [Page 22]
Internet-Draft Order of Information Elements Feb 2008
Appendix A. Template composed with Information Elements equivalent to
the NetFlow Version 5 record
This section describes an example of an application of the above-
mentioned order through the building of a Template that has
Information Elements equivalent to fields of the NetFlow Version 5
record.
Irino Expires August 28, 2008 [Page 23]
Internet-Draft Order of Information Elements Feb 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 2 | Length = 48 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Template Number | Field Count = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface(10) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface(14) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipClassOfService(5) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocolIdentifier(4) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address(8) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address(12) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4PrefixLength(9) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|destinationIPv4PrefixLength(13)| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort(7) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationTransportPort(11) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipNextHopIPv4Address(15) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bgpSourceAsNumber(16) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bgpDestinationAsNumber(17) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcpControlBits(6) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| paddingOctets(210) | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flowStartSysUpTime(22) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flowEndSysUpTime(21) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| octetDeltaCount(1) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packetDeltaCount(2) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Template Record equivalent of the NetFlow Version 5 record
Irino Expires August 28, 2008 [Page 24]
Internet-Draft Order of Information Elements Feb 2008
Author's Address
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
Phone: +81 422 59 4403
Email: irino.hitoshi@lab.ntt.co.jp
Irino Expires August 28, 2008 [Page 25]
Internet-Draft Order of Information Elements Feb 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Irino Expires August 28, 2008 [Page 26]
