IPFIX Working Group P. Aitken Internet-Draft Cisco Systems Intended status: Standards Track Expires: August 15th, 2013 February 15, 2013 Reporting Equivalent IPFIX Information Elements draft-aitken-ipfix-equivalent-ies-00 Abstract This document proposes a method for IPFIX Exporting Processes to inform Collecting Processes of equivalent Information Elements, so that the Collecting Process can understand the equivalence and be enabled to process data across a change of Information Elements. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 15, 2013. Aitken Expires Aug 2013 [Page 1] Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document 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 RFC 2119 [RFC2119]. Table of Contents 1 Introduction ........................................... 3 2 Terminology............................................. 4 3 Method ................................................. 4 3.1 Equivalence Message Format ............................ 4 4 The Collecting Process's Side .......................... 6 5 Security Considerations ................................ 6 6 IANA Considerations .................................... 6 7 References ............................................. 7 7.1 Normative References .................................. 7 7.2 Informative References ................................ 7 8 Acknowledgements ....................................... 7 9 Author's Addresses ..................................... 7 Aitken Expires Aug 2013 [Page 2] Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013 1 Introduction The IPFIX Protocol [RFC5101] can export a large number of Information Elements, including standard elements specified in the IPFIX information model [RFC5102, IANA-IPFIX], Enterprise- Specific elements [RFC5101], and elements which are backwards compatible with NetFlow Version 9 [RFC3954]. From time to time, an Exporting Process may export the same information using different Information Elements from before. Several scenarios (use cases) can be envisaged: . Enterprise-specific Information Elements have been standardised, so the Exporting Process is changed to export the IANA standard Information Elements [IANA-IPFIX] rather than the Enterprise-specific Information Elements. . The Exporting Process is changed to export IANA standard Information Elements [IANA-IPFIX] rather than NetFlow version 9 fields [RFC3954]. . The Exporting Process is updated to export different Enterprise-specific Information Elements. . An updated Metering Process requests that the Exporting Process exports using different Information Elements from before. In each case it's important to note that the same information is being exported. The only change is in the Information Element used to export the information. Since different Information Elements are now being used to express the same information, the Collecting Process cannot process data received before the change with data received after the change, because the Collecting Process does not know that these Information Elements are related. e.g. it's not possible to compare, aggregate, or sort data across such a change without first understanding that the old and new Information Elements are equivalent. Furthermore, it's impossible for every Collecting Process to know how each IANA standard Information Element [IANA-IPFIX] relates to every company's Enterprise-Specific Information Elements. ie, a Collecting Process from company X cannot be expected to know that company Y's Exporting Process exports Enterprise-specific field Z which is now equivalent to a certain IANA standard element. This document proposes a method for Exporting Processes to inform Collecting Processes of such equivalence, so that the Collecting Process is able to process data across the change. Aitken Expires Aug 2013 [Page 3] Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013 2 Terminology Terms used in this document are defined in the Terminology section of the IPFIX Protocol [RFC5101] and are to be interpreted as defined there. 3 Method An Exporting Process informs a Collecting Process of the equivalence of a pair of IPFIX Information Elements by exporting an IPFIX Equivalence Message. Equivalence Messages SHOULD be sent by the Exporting Process upon opening a new Transport Session, before any other IPFIX Messages are exported. They may be sent in an Options Record Scoped to the Exporter. Multiple Equivalence Messages may be sent using IPFIX Structured Data [RFC6313]. 3.1 Equivalence Message Format The Equivalence Message consists of an original Information Element in the "informationElementId" field (#303), followed by the equivalent Information Element in the "equivalentElementId" field (#TBD), using the Template shown in Figure 1 and Data Record shown in Figure 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| informationElementId #303 | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| equivalentElementId #TBD | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Template for Equivalence Message --+-+---------------+-+---------------+-- ... |E| Original IE |E| Equivalent IE | ... --+-+---------------+-+---------------+-- Figure 2: Equivalence Message Data Record The encoding of these Information Elements follows the rules specified in [RFC5101]. When the original Information Element and the equivalent Information Element are both IANA standard elements [IANA-IPFIX], both of the E bits are zero and the Equivalence Message is as shown in Figure 1. When the Original Information Element is Enterprise-Specific, Aitken Expires Aug 2013 [Page 4] Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013 the Original Information Element's E bit is set and the Information Element number is immediately followed by the corresponding Private Enterprise Number [PEN], as shown in Figure 3: +-+---------------+----------------------------------+-+---------------+ |1| Original IE | Private Enterprise Number |0| Equivalent IE | +-+---------------+----------------------------------+-+---------------+ Figure 3: Equivalence Message with an Enterprise-Specific Original Information Element This allows an Enterprise-Specific Information Element to be specified as equivalent to an IANA-standard Information Element. When the Equivalent Information Element is Enterprise-Specific, the Equivalent Information Element's E bit is set and the Information Element number is immediately followed by the corresponding Private Enterprise Number [PEN] as shown in Figure 4: +-+---------------+-+---------------+----------------------------------+ |0| Original IE |1| Equivalent IE | Private Enterprise Number | +-+---------------+-+---------------+----------------------------------+ Figure 4: Equivalence Message with an Enterprise Specific Equivalent Information Element This allows an IANA-standard Information Element to be specified as equivalent to an Enterprise-Specific Information Element. When both of the Information Elements are Enterprise-Specific, the E bits are set and both Information Element numbers are immediately followed by their corresponding Private Enterprise Number [PEN] as shown in Figure 5: +-+---------------+----------------------------------+ |1| Original IE | Private Enterprise Number | ... +-+---------------+----------------------------------+ +-+---------------+----------------------------------+ ... |1| Equivalent IE | Private Enterprise Number | +-+---------------+----------------------------------+ Figure 5: Equivalence Message with two Enterprise-Specific Information Elements This allows two Enterprise-Specific Information Elements to be specified as equivalent. Note that the Private Enterprise Numbers do not have to be equal. ie, the Information Elements may belong to different Private Enterprises. Aitken Expires Aug 2013 [Page 5] Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013 4 The Collecting Process's Side Equivalence Messages have global scope, unless they're sent in an Options Message with a more restrictive scope, eg an Options Record Scoped to the Exporter. ie, unless otherwise restricted, the specified equivalence applies to all devices. Therefore the Collecting Process does not need to maintain equivalence per device. 5 Security Considerations The same security considerations apply as for the IPFIX Protocol [RFC5101]. 6 IANA Considerations A new Information Element "equivalentElementId" must be allocated in IANA's IPFIX registry, [IANA-IPFIX]: Description: An IPFIX Information Element ("equivalentElementId") that denotes an Information Element identifier which is equivalent to another Information Element identifier, specified in an IPFIX Equivalence Message [this document]. Abstract Data Type: Unsigned16 Data Type Semantics: identifier ElementId: TBD Status: current Reference: [this document] Aitken Expires Aug 2013 [Page 6] 7 References 7.1 Normative References [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011. [IANA-IPFIX] IANA, "IPFIX Information Elements registry", . [PEN] IANA, "Private Enterprise Numbers registry", . [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 7.2 Informative References 8 Acknowledgements Thanks to you, dear reader. 9 Author's Addresses Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, UK Phone: +44 131 561 3616 Email: paitken@cisco.com