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