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]