IPFIX Protocol Specifications IPFIX IETF-58 November 10, 2003

IPFIX Protocol Specifications IPFIX IETF-58 November 10, 2003 draft-ietf-ipfix-protocol-01.txt Benoit Claise [email protected] Mark Fullmer [email protected] Reinaldo Penno [email protected] Paul Calato [email protected] 1

Changes in version 01 Terminology Section No more MUST, SHOULD, MAY in the terminology As example, the Template Record contained in version 00: “Data records that correspond to a template MAY appear in the same and/or subsequent Export Packets. The template information is not necessarily carried in every Export Packet. As such, the Collecting Process MUST store the Template Record to interpret the corresponding data records that are received in subsequent data packets. “ Keep the terminology section for the main terms, the rest being described in the different sections Example: FlowSet ID, Template ID PWE3 Architecture IETF-55 2

Changes in version 01 Terminology Section Some sentences in the terminology moved to the appropriate sections Example: A FlowSet ID is used to distinguish the different types of FlowSets. FlowSet IDs lower than 256 are reserved for special FlowSets, such as the Template FlowSet (ID 0) and the Options Template FlowSet (ID 1). The Data FlowSets have a FlowSet ID greater than 255. Definitions order Upper case for all definitions throughout the draft PWE3 Architecture IETF-55 3

Changes in version 01 Requirement Clarifications Sometimes we don't know to which instances a requirement applies: metering process, exporting process or colleting process. Example: The Exporting Process SHOULD insert some padding bytes Finally, note that the Collector MUST accept padding in the Data FlowSet and Options Template FlowSet, which means for the Flow Data Records, the Options Data Records and the Template Records. Example: If the Flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable at the Metering Process, with a minimum value of 0 for an immediate expiration. Some more examples PWE3 Architecture IETF-55 4

Changes in version 01 Clarification Some sections clarified but meaning unchanged! “Packet Layout” section so that the examples explain better the IPFIX behaviour “Flow Expiration” “Template Management” “Terminology Summary Table” PWE3 Architecture IETF-55 5

Changes in version 01 Template FlowSet Added to the Template FlowSet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Template ID K Field Count - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Otherwise: the format of the Template FlowSet implied that it must consist of exactly two records. So a more complex description to show the nested levels of structure. PWE3 Architecture IETF-55 6

New in version 01 Encoding “The Exporter MUST code all fields of the different FlowSets in network byte order (big-endian) “ PWE3 Architecture IETF-55 7

Consensus (?), Text Required Use of Options Template / Options Data Record – Periodic IPFIX synchronization message periodically Number of flow records sent Packets and bytes sent Per observation domain, yes. And per template? – Metering process stats packets / flows dropped at the metering process due to resource exhaustion, etc – Export ID (IP address of exporter) PWE3 Architecture IETF-55 8

Consensus (?), Text Required Having a length field in the Export Packet Header – Replacing the count per the length? Variable Length Data Type encoding – Not well formatted text – No packet format PWE3 Architecture IETF-55 9

Open Issues Transport protocol Failover section will be influenced The template management section will be influenced ex: template don't need lifetimes with connection oriented protocol ex: No periodic retransmission of templates is needed, with a reliable transport protocol. Reliability state diagram is needed. Vendor Specific Information Elements PWE3 Architecture IETF-55 10

Open Issues Sub-second timestamps is needed: consensus Which precision do we need? The requirement draft speaks of centisecond (like sysUpTime) Currently, we have UTC sec sysUptime 1/100 sec in header Currently, we have flow start sysUpTime and flow start sysUpTime in flow records What’s missing: residual UTC 1/100 sec in header PWE3 Architecture IETF-55 11

Open Issues Extensibility, for example make some decisions now about the reserved template ID's 2-254 for future work Some minor terminology discrepancy with the architecture draft Any others? Then thank you PWE3 Architecture IETF-55 12