Network Working Group H. Irino Internet-Draft NTT NS Lab. Expires: August 5, 2007 February 2007 Order of Information Elements draft-irino-ipfix-ie-order-01 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 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Irino Expires August 5, 2007 [Page 1] Internet-Draft Order of Information Elements February 2007 Abstract This draft describes guidelines for the order of Information Elements of the IPFIX protocol for the creation of Templates. It aims to improve the efficiency of the Collecting Process on the assumption that multiple Exporting Processes send Flow Records containing the same Information Elements to a Collecting Process. Exporters can make (almost) the same Template from the same combination of Information Elements by applying the order rule defined in this draft. Furthermore, some Templates will have a suitable data structure for hardware processing if the rule is applied because the rule defines that fixed-length Information Elements and other Information Elements are separated in position. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purposes of this draft . . . . . . . . . . . . . . . . . . 4 1.2. Targets of this draft . . . . . . . . . . . . . . . . . . 4 1.3. Contents of this draft . . . . . . . . . . . . . . . . . . 5 1.4. Updates from last draft . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Approach to the ordering of Information Elements . . . . . . . 8 3.1. Classification by data length of Information Elements and their order . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Relationship between Abstract Data Types and classes . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Sub classes and their order in fixed-length Information Elements class . . . . . . . . . . . . . . 10 3.2. Order of Information Element groups . . . . . . . . . . . 10 3.2.1. IETF-defined Information Element groups for Flow Key . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. IETF-defined Information Element groups not for Flow Keys . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Padding . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Enterprise-specific Information Elements . . . . . . . 12 3.3. Exceptions to the order defined in this draft . . . . . . 12 4. Recommended order of the combination of length classes and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Basic rule . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. The exception rule . . . . . . . . . . . . . . . . . . . . 14 4.3. Classification of IETF-defined Information Elements . . . 15 5. Handling Information Model Extensions . . . . . . . . . . . . 25 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security considerations . . . . . . . . . . . . . . . . . . . 27 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Irino Expires August 5, 2007 [Page 2] Internet-Draft Order of Information Elements February 2007 Appendix A. A Template composed with Information Elements equivalent to NetFlow Version 5 record . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Irino Expires August 5, 2007 [Page 3] Internet-Draft Order of Information Elements February 2007 1. Introduction 1.1. Purposes of this draft The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. According to [IPFIX-ARCH], in the IPFIX protocol, Flow Records are defined by Templates, where a Template is an ordered set of the Information Elements appearing in a Flow Record, together with their field lengths within those records. However, their flexibility could lead to inefficiency. The flexibility allows Templates to contain the same Information Elements in a different order. Therefore, several different Templates could contain the same Information Elements in different orders although the information carried by the Flow Records based on those Templates is essentially the same. This draft provides guidelines for a rule about the order of Information Elements in an array to avoid the inefficiency introduced above. This draft has two purposes: o To conserve resources used for Template management in the collecting process using common resources to store and process Templates and corresponding Data Records by unifying the data structure of Templates. This unification can be done by applying an order rule when Templates contain the same Information Elements on the assumption that multiple Exporting Processes send Flow Records containing the same Information Elements to a Collecting Process. o To increase the possibility of using hardware decoding to decode part of each Data Record made by a Template. This is achieved by separating the positions of fixed-length Information Elements and other Information Elements. 1.2. Targets of this draft Exporter implementations can be classified into several kinds. Some examples are given below. Configurable: It is possible to select Information Elements, configure their data lengths, and decide their order freely. (e.g., software-based implementations) Hard-coded: It is possible to select preset Templates but not to configure Information Elements in the Templates. (e.g., some router vendors' NetFlow v9 implementations.) Configurable Exporters can export suitable Templates and Data Records Irino Expires August 5, 2007 [Page 4] Internet-Draft Order of Information Elements February 2007 for each collector in various cases. If the Exporters all have the same configuration, the Templates will all have a uniform data structure. On the other hand, hard-coded Exporters might each be able to export a different Template even if the same set of Information Elements is contained in these Templates. Therefore, the mainly target of this draft is hard-coded implementations. This draft SHOULD be referred to for these implementations, or be referred to for the configuration of a fully configurable implementation, but not when there are special requirements. Implementations or configurations written above achieve the above-mentioned purposes. Furthermore, this draft targets creating Templates for shaping Data Records corresponding mainly to Template Records. Data Records corresponding to Option Template Records are regarded as unimportant in this draft because the total volume of Data Records corresponding to Template Records is generally larger than the total volume of Data Records corresponding to Option Template Records. 1.3. Contents of this draft Terminology is described in Section 2. An approach to the ordering of Information Elements is described in Section 3. The order for Information Elements recommended by this draft in described in Section 4. If you want to know this draft's recommended order, you should read Section 4 first. Section 3 explains why the order described in Section 4 is recommended in this draft. The way to handle future extensions of the Information Model is explained in Section 5. The applicability of this draft's recommended rule is described in Section 6. Security considerations are described in Section 7. 1.4. Updates from last draft The differences between this draft and the last draft are as follows: o A change in the recommended order. o The addition of the "Handling Information Model Extensions" section. (Section 5) o The addition of the "Applicability" section. (Section 6) Irino Expires August 5, 2007 [Page 5] Internet-Draft Order of Information Elements February 2007 o A change in the structure of the document. Irino Expires August 5, 2007 [Page 6] Internet-Draft Order of Information Elements February 2007 2. Terminology The terminology used in this document is aligned with the terminology defined in [IPFIX-PROTO] and [IPFIX-INFO]. 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 5, 2007 [Page 7] Internet-Draft Order of Information Elements February 2007 3. Approach to the ordering of Information Elements This draft takes the following three steps to decide the order of Information Elements. 1. Decide the order of Information Element length classes, which are classified by the length of Information Elements. 2. Decide the order of Information Element groups in [IPFIX-INFO]. 3. Decide the order of Information Elements in each combined class, which combines the length classes and groups. This draft defines that the order in this combined classification is equal to the description order in [IPFIX-INFO] in order to support future extension of the information model. 3.1. Classification by data length of Information Elements and their order This draft classifies Information Elements into three classes by their length. The recommended order of classes is as follows: 1. Fixed-length Information Elements class 2. Reduced-Size-Encoding-applicable Information Elements class 3. Variable-length Information Elements class Information Elements belonging to the fixed-length Information Elements class always have a fixed length in any Template. Therefore, the same set of fixed-length Information Elements ordered by a rule always makes the same data structure, and this set can fix data offsets of subsequent Information Elements. Therefore, they SHOULD be positioned before other classes in a Template. Information Elements to which Reduced Size Encoding is applicable might be able to have their lengths reduced by the Exporter and they might be able to change the data offsets of subsequent Information Elements in each Template. Information Elements belonging to the variable-length Information Elements class might be able to behave like variable-length Information Elements. Variable-length Information Elements might have a different length for each data record and might affect the data offsets of subsequent Information Elements in each data record. Therefore, they SHOULD be positioned after other classes in a Template. Irino Expires August 5, 2007 [Page 8] Internet-Draft Order of Information Elements February 2007 The order mentioned above takes into consideration the stability of the data structure and data offsets of subsequent Information Elements. The positional separation of fixed-length Information Elements and other Information Elements can ensure that the same data structure in part of each Template is formed using the same fixed-length Information Elements. As a result, the Collecting Process can conserve resources needed for managing Templates by using common resources to store and process a unified data structure which is part of each Template. 3.1.1. Relationship between Abstract Data Types and classes Information Elements whose Abstract Data Type is unsigned8, signed8, boolean, macAddress, dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, dateTimeNanoseconds, ipv4Address, or ipv6Address invariably belong to the fixed-length Information Elements class. Information Elements whose lengths are specified clearly in their descriptions belong to the fixed-length Information Elements class even if their Abstract Data Types are unsigned16, unsigned32, unsigned64, signed16, signed32, signed64, float32, octetArray, or string. Partial Information Elements whose Abstract Data Type is unsigned16, unsigned32, unsigned64, signed16, signed32, signed64, float32, or float64 belong to the Reduced-Size-Encoding-applicable Information Elements class. A class is selected from the fixed-length Information Elements class or the Reduced-Size-Encoding-applicable class according to the definition of each Information Element having one of the above Abstract Data Types. Information Elements whose Abstract Data Type is octetArray or string belong, in principle, to the variable-length Information Elements class. However, Information Elements whose data lengths are specified clearly in the descriptions are exceptions. Moreover, paddingOctets (Element Id: 210) is excluded from this class. One exception among octetArray Abstract Data Types is as follows. o Information Elements between mplsTopLabelStackSection (ElementId: 70) and mplsLabelStackSection10 (ElementId: 79) are classified into the class of fixed-length Information Elements in this draft because the sentence "The size of this Information Element is 3 octets." is given in their descriptions in [IPFIX-INFO], moreover corresponding fields in [RFC3954] are defined as belong 3 octets. This draft does not constrain an Exporter's encoding in such a way that it forces Information Elements belonging to the variable-length Irino Expires August 5, 2007 [Page 9] Internet-Draft Order of Information Elements February 2007 Information Elements class to have a variable length. In other words, it allows Information Elements belonging to the variable- length Information Elements class to be encoded as having a fixed length, e.g., mplsVpnRouteDistinguisher (ElementID: 90) has a high probability of being encoded as a fixed-length (8 octet) Information Element in Templates. The decision depends on the implementations or configurations of Exporters. 3.1.2. Sub classes and their order in fixed-length Information Elements class This draft further classifies fixed-length Information Elements classes into three sub-classes by their length and recommends the following order for them: 1. Information Elements whose length is a multiple of four octets 2. Information Elements whose length is an even number of octets (excluding multiple of four octets) 3. Information Elements whose length is an odd number of octets In the case of Information Elements whose length is a multiple of four octets, 32-bit data blocks can be created by a single Information Element. In the case of Information Elements whose data length is an even number of octets, 32-bit data blocks can be created by combining two Information Elements. In the case of Information Elements whose data length is an odd number of octets, 32-bit data blocks can be created by combining either four or two Information Elements. Since many processors are based on a 32-bit architecture, it is better to position Information Elements by collecting sub-classes of the same length. 3.2. Order of Information Element groups In this draft, Information Element groups defined in [IPFIX-INFO] are classified into three classes and ordered as follows: 1. Flow key groups (groups 4-7) 2. Non-Flow-key groups (groups 1-3 and groups 8-11) 3. Padding (group 12) Irino Expires August 5, 2007 [Page 10] Internet-Draft Order of Information Elements February 2007 3.2.1. IETF-defined Information Element groups for Flow Key The Information Elements that are derived from fields of packets or from packet treatment, such as the Information Elements in groups 4-7, can serve as Flow Keys used for mapping packets to Flows. According to [IPFIX-INFO], all Flow Keys are among the first 64 Information Elements because the flowKeyIndicator only contains 64 bits. Therefore, Information Elements belonging to groups 4-7 SHOULD have an earlier position than other groups. In this draft, the recommended order of these groups, using group numbers defined in [IPFIX-INFO], is: groups 4, 5, 6, and 7. 3.2.2. IETF-defined Information Element groups not for Flow Keys The recommended order for IETF-defined Information Element groups that are not for Flow keys is: groups 1, 2, 8, 9, 11, 3, and 10. All Information Elements belonging to groups 3 and 10 have counter data type semantics, and Reduced Size Encoding is applicable to these Information Elements. Therefore, these groups are positioned at the end of the position for Reduced-Size-Encoding-applicable Information Elements. In other words, these groups are positioned just before variable-length Information Elements. For non-Flow key groups other than groups 3 and 10, this draft recommends that the group order is in numerical sequence of the group numbers defined in [IPFIX-INFO] because there is no priority for ordering groups. 3.2.3. Padding The paddingOctets Information Elements belonging to the padding group can be positioned freely to set the start of subsequent Information Elements at an aligned boundary. This draft recommends that paddingOctets are positioned in one of the following three positions if it is necessary to align Data Records to a four-octet or eight- octet boundary: 1. Between fixed-length Information Elements and Reduce-Size- Encoding-applicable Information Elements. 2. Between Reduced-Size-Encoding-applicable Information Elements and variable-length Information Elements. 3. Or at the end of a Template record. Irino Expires August 5, 2007 [Page 11] Internet-Draft Order of Information Elements February 2007 3.2.4. Enterprise-specific Information Elements This draft recommends that enterprise-specific Information Elements for Flow keys are positioned after IETF-defined Information Elements for Flow keys. This draft recommends that enterprise-specific Information Elements not for Flow keys are positioned after IETF-defined Information Elements not for Flow keys. 3.3. Exceptions to the order defined in this draft Information Elements that use Scopes in Option Templates are exceptions to the order suggested in this draft. Information Elements that use Scopes MUST be placed at early in the Option Template, where early in this context means after the Option Template Record Header Format. According to [IPFIX-PROTO], the Scope Field Count MUST NOT be zero. Information Elements used as Scopes belong to group 1 or 2. The order of scopes is important, because each combination of the scopes has a different meaning. According to section 3.4.2.1 in [IPFIX-PROTO], for example, if the first scope defines the filtering function, while the second scope defines the sampling function, that means the sampling function first is applied, followed by the filtering function. This is a different meaning from the combination in which sampling occurs first and filtering occurs second. Therefore, Information Elements used as scopes are not ordered with respect to the rules of order in this draft. Templates that have a logical order (e.g., an Information Element is required more than once in a Template) are also exceptions to the rule of order in this draft. Logical order has a higher priority than the rule described in this draft. Irino Expires August 5, 2007 [Page 12] Internet-Draft Order of Information Elements February 2007 4. Recommended order of the combination of length classes and groups It is necessary to consider two rules because of the restriction of flowKeyIndicator. There is a basic rule and an there is an exception rule. The basic rule is used when all Flow key Information Elements are positioned in the first 64 Information Elements. The exception rule is used when all Flow key Information Elements cannot be positioned in the first 64 Information Elements by applying the basic rule. 4.1. Basic rule The length class is given priority over groups. Information Elements are initially ordered by length class and then by group within each length class. 1. Multiple of four octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 2. IETF defined Information Element groups not for Flow Keys 3. Enterprise-specific Information Element groups for Flow Keys 4. Enterprise-specific Information Element groups not for Flow Keys 2. Even number of octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 2. IETF defined Information Element groups not for Flow Keys 3. Enterprise-specific Information Elements for Flow Keys 4. Enterprise-specific Information Elements not for Flow Keys 3. Odd number of octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 2. IETF defined Information Element groups not for Flow Keys 3. Enterprise-specific Information Elements for Flow Keys 4. Enterprise-specific Information Elements not for Flow Keys Irino Expires August 5, 2007 [Page 13] Internet-Draft Order of Information Elements February 2007 4. Reduced-Size-Encoding-applicable Information Elements 1. IETF defined Information Element groups for Flow Keys 2. IETF defined Information Element groups not for Flow Keys 3. Enterprise-specific Information Elements for Flow Keys 4. Enterprise-specific Information Elements not for Flow Keys 5. Variable-length Information Elements 1. IETF defined Information Element groups for Flow Keys 2. IETF defined Information Element groups not for Flow Keys 3. Enterprise-specific Information Elements for Flow Keys 4. Enterprise-specific Information Elements not for Flow Keys 4.2. The exception rule Information Elements for Flow keys come before Information Elements not for Flow keys. 1. Information Element groups for Flow Keys 1. Multiple of four octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 2. Even number of octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 3. Odd number of octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 4. Reduced-Size-Encoding-applicable Information Elements Irino Expires August 5, 2007 [Page 14] Internet-Draft Order of Information Elements February 2007 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 5. Variable-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 2. Information Element groups not for Flow Keys 1. Multiple of four octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 2. Even number of octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 3. Odd number of octets in fixed-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 4. Reduced-Size-Encoding-applicable Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 5. Variable-length Information Elements 1. IETF defined Information Element groups 2. Enterprise-specific Information Elements 4.3. Classification of IETF-defined Information Elements In this section, all Information Elements except paddingOctets are classified by length class and then by group within each length class. Irino Expires August 5, 2007 [Page 15] Internet-Draft Order of Information Elements February 2007 1. Multiple of four octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 1. Group 4: IP Header Fields 1. 8: sourceIPv4Address 2. 27: sourceIPv6Address 3. 44: sourceIPv4Prefix 4. 170: sourceIPv6Prefix 5. 12: destinationIPv4Address 6. 28: destinationIPv6Address 7. 45: destinationIPv4Prefix 8. 169: destinationIPv6Prefix 2. Group 5: Transport Header Fields 1. 184: tcpSequenceNumber 2. 185: tcpAcknowledgementNumber 3. Group 7: Derived Packet Properties 1. 15: ipNextHopIPv4Address 2. 62: ipNextHopIPv6Address 3. 18: bgpNextHopIPv4Address 4. 63: bgpNextHopIPv6Address 5. 47: mplsTopLabelIPv4Address 6. 140: mplsTopLabelIPv6Address 2. IETF defined Information Element groups not for Flow Keys 1. Group 2: Metering and Exporting Process Configuration 1. 130: exporterIPv4Address Irino Expires August 5, 2007 [Page 16] Internet-Draft Order of Information Elements February 2007 2. 131: exporterIPv6Address 3. 211: collectorIPv4Address 4. 212: collectorIPv6Address 2. Group 8: Min/Max Flow Properties 1. 208: ipv4Options 3. Group 9: Flow Time Stamps 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. 160: systemInitTimeMilliseconds 2. Even number of octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 1. Group 4 1. 88: fragmentOffset 2. 190: totalLengthIPv4 2. Group 5 1. 7: sourceTransportPort 2. 11: destinationTransportPort 3. 180: udpSourcePort Irino Expires August 5, 2007 [Page 17] Internet-Draft Order of Information Elements February 2007 4. 181: udpDestinationPort 5. 205: udpMessageLength 6. 182: tcpSourcePort 7. 183: tcpDestinationPort 8. 186: tcpWindowSize 9. 187: tcpUrgentPointer 10. 32: icmpTypeCodeIPv4 11. 139: icmpTypeCodeIPv6 3. Group 6 1. 56: sourceMacAddress 2. 81: postSourceMacAddress 3. 58: vlanId 4. 59: postVlanId 5. 80: destinationMacAddress 6. 57: postDestinationMacAddress 2. IETF defined Information Element groups not for Flow Keys 1. Group 1 1. 145: templateId 2. Group 2 1. 217: exporterTransportPort 2. 216: collectorTransportPort 3. Odd number of octets in fixed-length Information Elements 1. IETF defined Information Element groups for Flow Keys 1. Group 4 Irino Expires August 5, 2007 [Page 18] Internet-Draft Order of Information Elements February 2007 1. 60: ipVersion 2. 9: sourceIPv4PrefixLength 3. 29: sourceIPv6PrefixLength 4. 13: destinationIPv4PrefixLength 5. 30: destinationIPv6PrefixLength 6. 192: ipTTL 7. 4: protocolIdentifier 8. 193: nextHeaderIPv6 9. 195: ipDiffServCodePoint 10. 196: ipPrecedence 11. 5: ipClassOfService 12. 55: postIpClassOfService 13. 206: isMulticast 14. 197: fragmentFlags 15. 189: ipHeaderLength 16. 207: ipv4IHL 2. Group 5 1. 188: tcpHeaderLength 2. 176: icmpTypeIPv4 3. 177: icmpCodeIPv4 4. 178: icmpTypeIPv6 5. 179: icmpCodeIPv6 6. 33: igmpType Irino Expires August 5, 2007 [Page 19] Internet-Draft Order of Information Elements February 2007 3. Group 6 1. 146: wlanChannelId 2. 200: mplsTopLabelTTL 3. 203: mplsTopLabelExp 4. 237: postMplsTopLabelExp 5. 70: mplsTopLabelStackSection 6. 71: mplsLabelStackSection2 7. 72: mplsLabelStackSection3 8. 73: mplsLabelStackSection4 9. 74: mplsLabelStackSection5 10. 75: mplsLabelStackSection6 11. 76: mplsLabelStackSection7 12. 77: mplsLabelStackSection8 13. 78: mplsLabelStackSection9 14. 79: mplsLabelStackSection10 4. Group 7 1. 46: mplsTopLabelType 2. IETF defined Information Element groups not for Flow Keys 1. Group 2 1. 214: collectorProtocolVersion 2. 215: collectorTransportProtocol 2. Group 8 1. 52: minimumTTL 2. 53: maximumTTL Irino Expires August 5, 2007 [Page 20] Internet-Draft Order of Information Elements February 2007 3. 6: tcpControlBits 3. Group 11 1. 136: flowEndReason 2. 61: flowDirection 4. "Reduced Size Encoding" applicable Information Elements 1. IETF defined Information Element groups for Flow Keys 1. Group 4 1. 31: flowLabelIPv6 2. 54: fragmentIdentification 3. 224: ipTotalLength 4. 191: payloadLengthIPv6 2. Group 5 1. 238: tcpWindowScale 3. Group 6 1. 202: mplsLabelStackDepth 2. 201: mplsLabelStackLength 3. 194: mplsPayloadLength 4. Group 7 1. 204: ipPayloadLength 2. 16: bgpSourceAsNumber 3. 17: bgpDestinationAsNumber 4. 128: bgpNextAdjacentAsNumber 5. 129: bgpPrevAdjacentAsNumber Irino Expires August 5, 2007 [Page 21] Internet-Draft Order of Information Elements February 2007 2. IETF defined Information Element groups not for Flow Keys 1. Group 1 1. 141: lineCardId 2. 142: portId 3. 10: ingressInterface 4. 14: egressInterface 5. 143: meteringProcessId 6. 144: exportingProcessId 7. 148: flowId 8. 149: observationDomainId 9. 138: observationPointId 10. 137: commonPorpertiesId 2. Group 2 1. 213: collectorInterface 2. 173: flowKeyIndicator 3. Group 8 1. 25: minimumPacketLength 2. 26: maximumPacketLength 3. 64: ipv6ExtensionHeader 4. 209: tcpOptions 4. Group 9 1. 22: flowStartSysUpTime 2. 21: flowEndSysUpTime 3. 158: flowStartDeltaMicroseconds Irino Expires August 5, 2007 [Page 22] Internet-Draft Order of Information Elements February 2007 4. 159: flowEndDeltaMicroseconds 5. Group 11 1. 36: flowActiveTimeout 2. 37: flowIdleTimeout 3. 161: flowDurationMilliseconds 4. 162: flowDurationMicroseconds 6. 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 7. Group 10 1. 1: octetDeltaCount 2. 23: postOctetDeltaCount 3. 198: octetDeltaSumOfSquares 4. 85: octetTotalCount 5. 171: postOctetTotalCount 6. 199: octetTotalSumOfSquares 7. 2: packetDeltaCount Irino Expires August 5, 2007 [Page 23] Internet-Draft Order of Information Elements February 2007 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 24. 223: tcpUrgTotalCount 5. Variable-length Information Elements 1. IETF defined Information Element groups for Flow Keys 1. Group 6 1. 147: wlanSSID (string) 2. Group 7 1. 90: mplsVpnRouteDistinguisher (octetArray) Irino Expires August 5, 2007 [Page 24] Internet-Draft Order of Information Elements February 2007 5. Handling Information Model Extensions This rule was made by considering data length and groups of Information Elements. The data length and groups of Information Elements are defined in [IPFIX-INFO] without any mention of enterprise-specific Information Elements. The order rule in this draft supports Information Model extensions (for example: the addition of a new Information Element). Irino Expires August 5, 2007 [Page 25] Internet-Draft Order of Information Elements February 2007 6. Applicability This order is applicable for a large network having many routers when these routers play the same role and each router uses the same required Information Elements in a Template. For example, a network carrier has many access routers and applies a common method of operation to them. The rule in this draft will enable a collector to collect Templates from more Exporters because the Information Elements contained in the templates are ordered in the same way. The advantage of this order rule is that multiple exporting processes will be able to use different Templates containing the same required Information Elements and a collecting process will collect Templates in order to create output that has a unified data structure - for example to write a file in binary format, to filter part of a data record, or to work as a IPFIX Mediators defined in [IPFIX-Mediators] - because it will no longer be necessary to have a processing step for converting Templates to an uniform data structure. Defining a unified order creates another possibility. Collectors can be implemented not only by a von Neumann computing model processor, but also by a dataflow model processor. Irino Expires August 5, 2007 [Page 26] Internet-Draft Order of Information Elements February 2007 7. Security considerations This draft does not directly relate to or introduce any security issues. The same security considerations as for the IPFIX Information Model [IPFIX-INFO] apply. Irino Expires August 5, 2007 [Page 27] Internet-Draft Order of Information Elements February 2007 8. IANA considerations This document has no actions for IANA. Irino Expires August 5, 2007 [Page 28] Internet-Draft Order of Information Elements February 2007 9. References [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export, draft-ietf-ipfix-architecture-12.txt, work in progress", Sep 2006. [IPFIX-INFO] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export, draft-ietf-ipfix-info-15.txt, work in progress", Feb 2007. [IPFIX-Mediators] Kobayashi, A., Ishibashi, K., Kondoh, T., and D. Matsubara, "IPFIX Mediators , draft-kobayashi-ipfix-mediator-01.txt , work in progress", October 2006. [IPFIX-PROTO] Claise, B., "IPFIX Protocol Specification Internet Draft, draft-ietf-ipfix-protocol-24.txt, work in progress", June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119 progress", March 1997. [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", October 2004. Irino Expires August 5, 2007 [Page 29] Internet-Draft Order of Information Elements February 2007 Appendix A. A Template composed with Information Elements equivalent to NetFlow Version 5 record This section describes an example of an application of the above order rule through the building of a Template that has Information Elements equivalent to the NetFlow Version 5 record. Irino Expires August 5, 2007 [Page 30] Internet-Draft Order of Information Elements February 2007 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 = 56 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Any Template No xxx | Field Count = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sourceIPv4Address(8) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destinationIPv4Address(12) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipNextHopIPv4Address(15) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sourceTransportPort(7) | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destinationTransportPort(11) | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sourceIPv4PrefixLength(9) | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |destinationIPv4PrefixLength(13)| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | protocolIdentifier(4) | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipClassOfService(5) | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tcpControlBits(6) | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | paddingOctets(210) | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ingressInterface(10) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | egressInterface(14) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bgpSourceAsNumber(16) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bgpDestinationAsNumber(17) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flowStartSysUpTime(22) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flowEndSysUpTime(21) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | octetDeltaCount(1) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packetDeltaCount(2) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: A Template equivalent of NetFlow Version 5 Irino Expires August 5, 2007 [Page 31] Internet-Draft Order of Information Elements February 2007 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 5, 2007 [Page 32] Internet-Draft Order of Information Elements February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 5, 2007 [Page 33]