From majordomo@mil.doit.wisc.edu Sun Sep 1 04:35:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09965 for ; Sun, 1 Sep 2002 04:35:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17lQ0J-0007KR-00 for ipfix-list@mil.doit.wisc.edu; Sun, 01 Sep 2002 03:22:43 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17lQ0G-0007KK-00 for ipfix-eval@net.doit.wisc.edu; Sun, 01 Sep 2002 03:22:40 -0500 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 1C426400138; Sun, 1 Sep 2002 01:22:39 -0700 (PDT) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id BAA05275; Sun, 1 Sep 2002 01:22:32 -0700 (PDT) Received: from cup.hp.com ([15.244.160.53]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20020901085043.FTEI18196.simail.cup.hp.com@cup.hp.com>; Sun, 1 Sep 2002 01:50:43 -0700 Message-ID: <3D71CFD6.3080303@cup.hp.com> Date: Sun, 01 Sep 2002 01:29:10 -0700 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Juergen Quittek Cc: ram.gopal@nokia.com, n.brownlee@auckland.ac.nz, ipfix-eval@net.doit.wisc.edu, Protocol@ipdr.metratech.com Subject: Re: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) References: <22725026.1030721831@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I'm not sure how to interpret the absence of documents for the other protocols, but here is IPDR's advocacy statement under the Sept. 2 deadline: http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.txt Given the short notice of the reminder sent on Aug. 29, I will continue to update this over the next two days, before submitting to the IETF editor for drafts on Sept. 2. So the above link is likely to be updated after the initial delivery of this e-mail. The initial (incomplete) IPDR IPFIX advocacy draft can be found at http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.txt or http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.html The XML source for this document is available at: http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.xml The base source of this document is XML, written according to RFC2629, described in: http://xml.resource.org/public/rfc/html/rfc2629.html I would recommend this code to other protocol advocates who are interested in utilizing the XML formatting web services available at: http://xml.resource.org/ This allows you to produce .html, .txt, and .nroff files from the same XML source file. Regards, Jeff Meyer www.hp.com/usage Juergen Quittek wrote: > Hi Ram, > > -- ram.gopal@nokia.com wrote on 30 August 2002 08:18 -0400: > >> Hello Juergen, >> >> Sorry, the earlier email slips out of my hands. I interpreted as Sep >> 2 deadline for submission to evaluation team. > > > Yes. Now I see what you mean. I just wanted to remind the declared > (and all other potential) advocates of the deadline for the > advocacy drafts that contain individual protocol evaluations. > > Of course the deadline of the joint evaluation draft is later. > >> Then at the earliest we should produce the evaluation document to the >> mailing list for enough debate/discussion and it need not be on Sep >> 2nd itself. > > > You are right. The joint draft is scheduled for Oct. 16. > >> >> FYI, I have completed reading all the IPFIX candidates and in half >> way mark in documenting as per template. On the other side, I am also >> waiting till Sep 2nd to see any other IPFIX candidate protocol >> submission. >> > > Great! > > Juergen > >> >> Regards >> Ramg >> >>> Hi Ram, >>> >>> You may be right, but how do you interpret the phrase >>> "Advocacy drafts published" in this sniplet from Nevil's >>> message? >>> >>> > > 2 September Cutoff for Protocol Submissions to >>> Evaluation Team >>> > > Advocacy drafts published >>> >>> Juergen >>> >>> >>> -- ram.gopal@nokia.com wrote on 29 August 2002 14:13 -0400: >>> >>> > Hello Juergen, >>> > >>> > The 2 September is cut-off date for "protocol submission" and not >>> > "protocol evaluation" document. >>> > >>> > >>> > Regards >>> > Ramg >>> > >>> >> -----Original Message----- >>> >> From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] >>> >> Sent: Thursday, August 29, 2002 12:50 PM >>> >> To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu >>> >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) >>> >> >>> >> >>> >> Dear protocol advocates: >>> >> >>> >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: >>> >> >>> >> > Hello all: >>> >> > >>> >> > At the IPFIX meeting in Yokohama we reached consensus on >>> >> the evaluation >>> >> > process, with the following timetable: >>> >> > >>> >> > 5 July Publish Protocol Advocacy draft and Call >>> >> for Submissions >>> >> > >>> >> > 15 July Work on consensus in Yokohama, agree on >>> timetable >>> >> > >>> >> > 2 September Cutoff for Protocol Submissions to >>> Evaluation Team >>> >> > Advocacy drafts published >>> >> >>> >> Please do not miss the cutoff date for the protocol >>> >> evaluation drafts on next Monday. >>> >> >>> >> Juergen >>> >> -- >>> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >>> >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >>> >> Adenauerplatz 6, 69115 Heidelberg, Germany >>> http://www.ccrle.nec.de >>> >> >>> >> -- >>> >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>> >> in message body >>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> >> "unsubscribe ipfix" in message body >>> >> Archive http://ipfix.doit.wisc.edu/archive/ >>> >> >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>> in message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Sep 1 19:21:56 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29691 for ; Sun, 1 Sep 2002 19:21:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17ldkt-0006Ji-00 for ipfix-list@mil.doit.wisc.edu; Sun, 01 Sep 2002 18:03:43 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17ldkp-0006JD-00 for ipfix@net.doit.wisc.edu; Sun, 01 Sep 2002 18:03:39 -0500 Received: (qmail 21642 invoked from network); 1 Sep 2002 23:03:22 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 1 Sep 2002 23:03:22 -0000 Received: from Kevinz ([192.168.2.11]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g81N61s02940; Sun, 1 Sep 2002 16:06:02 -0700 Reply-To: From: "kevin.zhang" To: Cc: "Ipfix@Net. Doit. Wisc. Edu" Subject: [ipfix] CRANE Advocacy Draft Date: Sun, 1 Sep 2002 19:07:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C251EA.C824FEA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C251EA.C824FEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SVBGSVggRXZhbHVhdGlvbiBUZWFtLA0KDQpUaGUgQ1JBTkUgYWR2b2NhY3kgZHJhZnQgaGFzIGJl ZW4gc3VibWl0dGVkIHRvIHRoZSBJRVRGIG9uIFNlcHRlbWJlciAxc3QsIDIwMDIuICBJdCBzaG91 bGQgYmUgYXZhaWxhYmxlIGluIHRoZSBJLUQgZGlyZWN0b3J5IHNob3J0bHkuIEkgaGF2ZSBhbHNv IGF0dGFjaGVkIHRoaXMgZHJhZnQgZm9yIHlvdXIgcmV2aWV3Lg0KDQpUaGUgY3VycmVudCBDUkFO RSBzcGVjaWZpY2F0aW9uIGNhbiBiZSBmb3VuZCBhdDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta3poYW5nLWNyYW5lLXByb3RvY29sLTA1LnR4dCANCg0KVGhhbmtz LA0KDQpLZXZpbiBaaGFuZw0KWEFDQ1QgVGVjaG5vbG9naWVzLEluYy4NCisxKDMwMSk5OTItNDY5 Nw== ------=_NextPart_000_0004_01C251EA.C824FEA0 Content-Type: text/plain; name="draft-kzhang-ipfix-eval-CRANE-00.txt" Content-Disposition: attachment; filename="draft-kzhang-ipfix-eval-CRANE-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Kevin Zhang, Eitan = Elkin Document: draft-kzhang-ipfix-eval-CRANE-00.txt Peter Ludemann IPFIX WG XACCT Technologies Expires: March 2003 September 2002 Evaluation of the CRANE Protocol Against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document provides an evaluation of the applicability of the CRANE protocol developed by XACCT Technologies as an IPFIX protocol. It compares the properties and capabilities of the CRANE protocol with the IPFIX requirements [IPFIX-REQ]. Zhang, et al. Expires - March, 2003 [Page 1] =0C Internet-Draft CRANE Evaluation September = 2002 Table of Contents 1. Introduction..................................................3 1.1 CRANE Standardization.....................................3 1.2 CRANE Implementation......................................4 1.3 CRANE Deployment..........................................4 1.4 Intellectual Properties...................................4 1.5 CRANE Future Evolution....................................5 2. Architectural Considerations..................................6 2.1 CRANE Protocol Overview...................................6 2.2 CRANE Features............................................6 2.3 General Applicability.....................................7 2.4 CRANE Protocol Functions..................................8 2.5 Architectural Differences................................12 3. CRANE vs. IPFIX Requirement - Detailed Compliance Evaluation.13 3.1 Introduction.............................................13 3.2 Distinguish Flows [IPFIX-REQ Section 4] Compliances......13 3.3 Metering Process [IPFIX-REQ Section 5] Compliances.......13 3.4 Data Export [IPFIX-REQ Section 6] Compliances............13 3.5 Configuration [IPFIX-REQ Section 7] Compliances..........16 3.6 General Requirements [IPFIX-REQ Section 8] Compliances...17 4. Security Considerations......................................18 References......................................................19 Author's Addresses..............................................20 Zhang, et al. Expires - March, 2003 [Page 2] =0C Internet-Draft CRANE Evaluation September = 2002 1. Introduction This Internet Draft provides an evaluation of applicability of the CRANE (Common Reliable Accounting for Network Elements) protocol developed by XACCT Technologies as an IPFIX protocol. In this section, we review the current CRANE standardization status and its future plans. In Section 2, CRANE architecture and capabilities are introduced, and its application to the communication interface between an IPFIX exporting process and an = IPFIX collecting process is discussed. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met by the CRANE protocol. 1.1 CRANE Standardization The CRANE protocol was developed by XACCT Technologies in response to the urgent need for a reliable, efficient, and flexible technology to collect IP flow information for various business applications such as accounting, SLA management, fraud detection, and traffic engineering, etc. From the very beginning, CRANE was developed as an open protocol so that it can be widely adopted by the communications industry. More than 30 companies have participated in CRANE's development. These companies represent a broad spectrum of the industry, consisting of vendors for routers, probes, access switches, servers, wireless portals, etc. These companies were involved in different stages of the CRANE development; some companies evaluated the CRANE specification and engaged in detailed technical discussions to enhance the protocol, other companies integrated the CRANE Client agent into their devices and conducted testing with the CRANE Servers. CRANE is not a proprietary protocol; its specification was first submitted to the IETF as an Internet Draft in June 2001. It was presented at the IPFIX BOF session at the London IETF meeting to catalyze the IPFIX standardization process and the establishment of the IPFIX WG. The current CRANE protocol specification Version 1.0 can be obtained at http://www.ietf.org/internet-drafts/draft- kzhang-crane-protocol-05.txt[CRANE]. XACCT intends to continue pursuing CRANE standardization in the IETF. Since its submission in June 2001, the CRANE specification was reviewed and commented by IESG and many IETF participants. It is now in the process of being published by the IETF as an Informational RFC. Our thorough review of CRANE indicates that it meets all the IPFIX requirements; we thus would advocate its adoption as the IPFIX protocol. Zhang, et al. Expires - March, 2003 [Page 3] =0C Internet-Draft CRANE Evaluation September = 2002 If CRANE is adopted as the IPFIX protocol, we would like to see the further enhancement of CRANE by the IPFIX WG. We believe expertise from the IPFIX participants can improve the design of the protocol. XACCT Technologies is committed to continue participating and assisting the IPFIX in standardizing CRANE going forward. 1.2 CRANE Implementation XACCT Technologies has implementations of the CRANE Client and Server. Our implementation allows end-to-end flow record export from exporting processes to collecting processes. A reference CRANE Client implementation has been available to our CRANE partners, and has been integrated by several companies into their devices. Currently, XACCT Technologies is the only source for CRANE implementations. As the CRANE protocol is open to public, any companies interested in this technology are free to develop their own implementations. 1.3 CRANE Deployment The CRANE protocol has been adopted by several data export systems at the data collection interface; these systems are designed to collect accounting and network QoS information for billing and SLA management purposes; and these systems generally require high- volume export of flow information. A number of network equipment vendors have integrated the CRANE Client within their devices, and successfully conducted CRANE interoperability tests with CRANE servers. Currently, there is one multi-vendor commercial deployment of the CRANE protocol with a Tier One US operator. One more deployment (message based accounting) has gone through all the pre-production phases, and ready for commercial deployment. A third deployment that involves probes for network monitoring has gone through lab integration. 1.4 Intellectual Properties XACCT Technologies has submitted its CRANE protocol specification to the IPFIX WG of the IETF for standardization. Our participation in IETF has been/will be in conformity with RFC 2026. To date, XACCT Technologies has not filed any patents concerning the CRANE protocol. In the future, XACCT Technologies may seek patent rights to some aspects of the CRANE protocol implementation. In that case, XACCT Technologies is willing to make available a Zhang, et al. Expires - March, 2003 [Page 4] =0C Internet-Draft CRANE Evaluation September = 2002 nonexclusive license under such patents, on fair, reasonable, and non-discriminatory terms and conditions. 1.5 CRANE Future Evolution If CRANE is adopted as the IPFIX protocol, the IPFIX WG is expected to drive the future development of the protocol. The WG will have the freedom to make modifications of the current design, and add new features as it sees fit. XACCT Technologies is committed to continue participating and assisting the IPFIX in standardizing CRANE going forward. If CRANE is not selected as the IPFIX protocol, XACCT Technologies will continue leading its development to preserve values and competitive advantages it brings to the CRANE community. The CRANE protocol specification 1.0 is stable; the future versions will likely be released as a result of new requirements demanded by the industry. Zhang, et al. Expires - March, 2003 [Page 5] =0C Internet-Draft CRANE Evaluation September = 2002 2. Architectural Considerations This section introduces the architecture of a data exporting system where the CRANE protocol is used. It highlights some key CRANE capabilities that support the reliable and efficient way of communications between IPFIX exporting and collecting processes. 2.1 CRANE Protocol Overview CRANE is a flexible, high performance, and reliable protocol that can be used for exporting IP flow information from IPFIX exporting processes to collecting processes. It has an architecture that is similar to the IPFIX's, and meets all the IPFIX requirements. In addition, CRANE addresses the needs of those devices that require high speed IP flow information export. This is achieved through CRANE's template based data export; it not only significantly reduces the on device data record processing, but also reduces the bandwidth consumption for data export. 2.2 CRANE Features We highlight several key CRANE features. These features go beyond the current IPFIX requirements, and can bring great benefits to many data export systems. End-to-end Reliability The CRANCE protocol uses a reliable transport layer protocol such as TCP or SCTP that ensures in-sequence, reliable data packet delivery. It supports flow control and CRANE protocol level reliability through application-level acknowledgement procedures. As a result, valuable flow information is not only ensured to be delivered reliably across the network, but also processed correctly and stored in persistent storage if required before acknowledgements are sent. The CRANE protocol also supports server redundancy configurations and load balancing; through rapid, automatic failover and failback operations, high level of availability and fault tolerance is offered. Flexibility The CRANE protocol imposes minimal constraints on the type and format of delivered data records. By employing a =93template negotiation=94 procedure, any kind of user-defined data model (e.g. IPFIX data model) can be supported. This enables the CRANE protocol to handle diversified information export requirements. The protocol also supports multiple "sessions" and multiple record "formats" between CRANE clients and servers; this enables different Zhang, et al. Expires - March, 2003 [Page 6] =0C Internet-Draft CRANE Evaluation September = 2002 business applications to subscribe to only their required information. Real-time Exporting The CRANE protocol supports the "push" based data delivery model. This potentially can minimize the latency between data collection at Network Elements and data reception and processing at CRANE servers. Efficiency The CRANE protocol messages have low protocol overhead, and records are encoded in a compact binary format. By negotiating = =93templates=94 beforehand, the proper context of the flow information can be "cached" at CRANE end points, and only the desired data records are transmitted with minimum overhead. Where possible, data are transmitted in the internal form most natural to the exporting device and converted, as necessary, by the receiver (collecting process). This avoids the inefficiencies associated with some encoding schemes, which can place processing overhead on the exporter. Lightweight and Memory Efficiency The CRANE API embedding in network equipment has a footprint of approximated 150 =96 200 KB and demands little CPU processing power (platform dependant, but typically only a few percent). The memory requirement on the client side depends on factors such as record size, failover scenarios, export interface data rate, round-trip delay between the client and server, etc.; it can be provisioned to fit in different types of network equipment. 2.3 General Applicability The CRANE protocol is designed for exporting a variety of information from CRANE Clients to CRANE Servers to serve different network and business applications. CRANE Clients are typically embedded in Exporting Devices; exporting devices may include routers, probes, and access switches, etc. CRANE Servers are hosted by Collection Devices that may be part of mediation systems, accounting/billing systems, and network management systems to facilitate business and operation support. The following figure illustrates the reference model of a data export system using the CRANE protocol. The CRANE reference model maps extremely well with the current IPFIX architecture Zhang, et al. Expires - March, 2003 [Page 7] =0C Internet-Draft CRANE Evaluation September = 2002 [IPIX-ARCH]. On the Exporting Device side, the CRANE Monitoring Entity and the CRANE Client map to the IPFIX Metering Process and Exporting Process respectively; on the Collecting Device side, the CRANE Server maps to the IPFIX collecting process. Throughout the document, we will use IPFIX exporting/collecting process and CRANE Client/Server interchangeably. +---------------+ +---------------+ | +----------+ | | +----------+ | | |Monitoring| | | |Processor | | | |Entity | | | |Entity | | | +----------+ |CRANE | +----------+ | | +----------+ |Protocol | +----------+ | | |CRANE |<=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D>|CRANE = | | | |Client | | | |Server | | | +----------+ | | +----------+ | | Exporting | | Collecting | | Device | | Device | +---------------+ +---------------+ The CRANE Client (mapped to the IPFIX Exporting Process) is an implementation on the data producing side of the CRANE protocol. It is typically integrated with the network element=92s software, enabling it to export flow information to CRANE Servers. The CRANE Server (mapped to the IPFIX Collecting Process) is an implementation on the data receiving side of the CRANE protocol. It is typically part of a Business Support System (BSS) (e.g. Billing, Market Analysis, Fraud detection, etc.), or a mediation system. There could be more than one CRANE server connected to one CRANE client to improve robustness of the IPFIX system. The Monitoring Entity (mapped to the IPFIX Metering Process) is not part of the CRANE protocol. Its primary task is to monitor IP flows, and derive IP flow information. How the Monitoring entity measures and derives flow information is outside the scope of the IPFIX protocol, but the attributes used to describe flow information can comply with the IPFIX information model and IP flow definitions. The Processor Entity is not part of the CRANE protocol. Its primary task is to process the received IP flow information based upon end application=92s requirements. 2.4 CRANE Protocol Functions In this section, we describe some of the functions forming the CRANE protocol. These functions support CRANE capabilities that not Zhang, et al. Expires - March, 2003 [Page 8] =0C Internet-Draft CRANE Evaluation September = 2002 only meet IPFIX requirements, but also offer some desirable features that are beneficial to an IPFIX system. The CRANE protocol is an application that uses the data communications services provided by lower layer protocols. It relies on lower layer protocols to deliver reliable, in-sequence data packets. The following diagram illustrates the CRANE protocol architecture: +----------------+ +----------------+ | CRANE | | CRANE |+ | User | | User ||+ +----------------+ +----------------+|| | CRANE | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> | CRANE = |+| | Client | <---------- | Server ||+ +----------------+ +----------------+|| | Transport | | Transport |+| | Layer | <---------> | Layer ||+ +----------------+ +----------------+|| | Lower | | Lower |+| | Layers | <---------> | Layers ||+ +----------------+ +----------------+|| +----------------+| +----------------+ The transport protocols used for CRANE message delivery may be TCP or SCTP. TCP supports all the CRANE functionality, while SCTP offers some desirable capabilities that could improve the overall performance of data export. 2.4.1 Session Control The CRANE protocol uses connection-oriented information transfer. This choice was made because the connection/session on which flow information is exported is expected to last for a long duration, and the network configuration between protocol end-points is mostly static. Furthermore, this choice makes the support of reliability more convenient. A logical association of session is established between protocol end-points before flow information can be exported. An export session consists of three phases - * Session Establishment * Flow Information Export * Session Termination Zhang, et al. Expires - March, 2003 [Page 9] =0C Internet-Draft CRANE Evaluation September = 2002 During session establishment, a CRANE server issues a request that triggers the transport layer connection setup. After the transport layer connection is established successfully, a set of templates is negotiated between a CRANE client and servers. A Template defines the structure of any Data Record that may be exported from the CRANE client, and specifies the data type, meaning, and location of the fields in the record. The specification of templates relates to the flow definitions, and governs what flow information would be exposed to the external systems. The definition of templates is typically installed in the CRANE clients and servers through network management system, and is out of the scope of the CRANE protocol. The provisioning of templates establishes contexts for the IP flow information exchange, so that both CRANE clients and servers can correctly interpret the information. The CRANE protocol also allows template negotiation that would further improve the efficiency of information transfer. After the session is established successfully, the IP flow information is exported from the exporting device to a collector. The data format is governed by the negotiated templates; the collector will use the template to decode the CRANE data message payload. Error control, congestion control, record de-duplication, and redundancy procedures are executed during flow information export, to ensure reliability and robustness of the system. As a data export session is expected to last for a long duration, no explicit session termination messages are provided by the CRANE protocol. A CRANE session is typically terminated as a result of tearing down of the transport layer connection by the CRANE users. 2.4.2 Error Control The CRANE protocol relies on the lower layer to provide in- sequence, reliable data packet delivery. At the protocol level, it supports error control to ensure the flow information is correctly received, processed, and optionally stored at the collector. Messages (containing flow information) received by the collector are acknowledged. By monitoring the acknowledgements from the collector, the exporting device can re-transmit date messages that are perceived to be lost, for example when a fail-over occurs. 2.4.3 Redundancy Support For improved reliability and robustness, redundant CRANE server configuration MAY be employed. The CRANE protocol supports delivering flow information to alternate CRANE servers. Zhang, et al. Expires - March, 2003 [Page 10] =0C Internet-Draft CRANE Evaluation September = 2002 A CRANE session may comprise of one or more CRANE servers. The redundancy configuration is generally provisioned through the network management system (e.g. addresses of CRANE servers and clients participating in a CRANE session). A Server Priority can be assigned to each CRANE server. A CRANE client delivers data record to its perceived operating CRANE server with the highest priority; if this CRANE server is deemed unreachable, the CRANE client delivers the data to the next highest priority CRANE server that is perceived to be operating. If no perceived operating CRANE servers are available, data may be queued in the CRANE client until any CRANE server is available or the client=92s queue space runs out. An alarm SHOULD be generated to inform the CRANE user of the queue overflow condition. Data record exporting SHOULD revert to the higher priority server when it is perceived to be operating again. The conditions under which a fail-over/fail-back may occur include: A) Transport layer notifies the CRANE client that the corresponding port of the CRANE server is unresponsive. B) Total size of unacknowledged data records has exceeded a threshold (configurable) for certain duration (configurable). C) An explicit message is received from the active server instructing the switch over. D) A lower priority server is the active one and a higher priority server has recovered. 2.4.4 Template Management The CRANE protocol enables efficient delivery of accounting data. This is achieved by negotiating a set of Data Templates for a CRANE session before actual accounting data is delivered. A data template defines the structure of a DATA message payload by describing the data type, meaning, and location of the fields in the payload. By agreeing on session templates, CRANE servers understand how to process DATA messages received from a CRANE client. As a result, a CRANE client only needs to deliver actual flow information without attaching any descriptors of the data; this reduces the amount of bytes sent over communication links. The CRANE protocol supports usage of several templates concurrently (for different flow data records). In a CRANE session, all the CRANE servers and the CRANE client must use the same set of Zhang, et al. Expires - March, 2003 [Page 11] =0C Internet-Draft CRANE Evaluation September = 2002 templates. The templates are provisioned through network management system. The complete set of templates residing in a CRANE client MUST bear a configuration ID that identifies the template set. Each data record is delivered with the Template ID and the Configuration ID, so that the correct template can be referenced. A server, when receiving a record with an older Configuration ID, MAY handle the record gracefully by keeping some template history. The transport layer SHOULD ensure that a server would not get messages with future configuration IDs. 2.5 Architectural Differences There are no major architectural differences between the IPFIX system and the data export system that CRANE is currently deployed. The data export systems that CRANE is currently deployed are more generic then IPFIX systems. The Monitoring Entity function in these systems is not limited in monitoring IP flow information. It can meter data communications across all layers, and provide transaction information corresponding to specific applications. Therefore, the IPFIX architecture can be viewed as a subset of these data export systems. The flexible and extensible CRANE data model can therefore cover all the IPFIX attributes. Zhang, et al. Expires - March, 2003 [Page 12] =0C Internet-Draft CRANE Evaluation September = 2002 3. CRANE vs. IPFIX Requirement - Detailed Compliance Evaluation 3.1 Introduction This section evaluates the compliance of the CRANE protocol [CRANE] with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement, it is explained to what degree CRANE meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance -E Extension required for total compliance -P Partial compliance -U Upcoming compliance -F Failed compliance 3.2 Distinguish Flows [IPFIX-REQ Section 4] Compliances Distinguishing flows is one of the tasks performed by the IPFIX Metering Processes; therefore, it is not applicable to the IPFIX Protocol. No detailed analysis is provided for IPFIX-REQ Section 4. From a protocol point of view, the CRANE protocol supports all the necessary data types for IP flow record exporting and allows arbitrary =93flat=94 records. In an IPFIX system, a flow definition would determine how IP flows are distinguished. The CRANE template definition effectively reflects the flow definition, and can be installed in IPFIX exporting devices through configuration. The template definition would then determine how flow information is metered and exported to collecting devices. 3.3 Metering Process [IPFIX-REQ Section 5] Compliances The IPFIX Metering Process primarily deals with the measurement of the IP flow information. It is not applicable to the IPFIX protocol, which is solely used for communications between IPFIX exporting and collecting processes. Therefore, no detailed analysis is provided for IPFIX-REQ Section 5. From a protocol point of view, the CRANE protocol supports all the necessary data types for IP flow information export and allows arbitrary =93flat=94 records. 3.4 Data Export [IPFIX-REQ Section 6] Compliances Zhang, et al. Expires - March, 2003 [Page 13] =0C Internet-Draft CRANE Evaluation September = 2002 IPFIX-REQ Section 6.1 Information Model -T The information model is a list of the attributes that need to be reported to IPFIX collecting processes. The CRANE protocol is independent to an information model that is typically coupled with the Metering Process capabilities. CRANE does not limit what can be exported; it supports the standard IPFIX information model as well as other attributes (standard or proprietary) that the Metering Process wishes to expose. IPFIX-REQ Section 6.2 Data Model -T CRANE implements a Template based data model. A Template defines the structure of any types of IP Flow Record, and specifies the data type, meaning, and location of the fields in the record. A field typically carries an attribute specification that the exporting process wants to export. The template can be viewed as meta-data that describes how IP flow information is encoded in the payload of the relevant CRANE messages. It also indicates the context of which the flow information should be interpreted. Templates are user defined and installed in the exporting and collecting processes through local or remote configuration. CRANE data model is extensible as Templates can be easily created, modified, or deleted. CRANE supports the modification of a Template by adding (enabling) and deleting (disabling) attribute fields. CRANE data model is flexible; besides a few mandatory header fields (such as Template ID, Number of Keys, etc.) that must be present in a template, no further constraints are imposed on the data record format, number of attributes (keys) contained in a template, sequence or position of attributes (keys) in a template, and attribute data types, etc. CRANE templates are configurable locally or remotely. Beyond extensibility and flexibility, template based data model allows flow information to be transmitted in their natural form, without complex encoding/decoding, minimizing the processing overhead at the exporting and collecting processes. Furthermore, as flow records are transmitted without embedded tags, significant bandwidth savings can be achieved. IPFIX-REQ Section 6.3 Data Transfer -T CRANE complies with all the requirement items outlined in IPFIX- REQ Section 6.3. IPFIX-REQ Section 6.3.1 Congestion Awareness -T Zhang, et al. Expires - March, 2003 [Page 14] =0C Internet-Draft CRANE Evaluation September = 2002 CRANE can be viewed as an application that uses TCP or SCTP as the transport layer protocol. Both TCP and SCTP are congestion aware. In addition to meeting the congestion aware requirement, CRANE offers sufficient capabilities to allow an implementation to provide additional application-level flow control and fail- over/fail-back procedures. The detection of congested/overloaded collecting processes as well as congested links would enable the exporting process to take actions in mitigating the situation, e.g. reducing its flow record exporting rate or switching over to a redundant collecting process. In summary, CRANE is not only congestion aware to link conditions, but is also aware of the processing bottlenecks at collection processes. IPFIX-REQ Section 6.3.2 Reliability -T CRANE can be viewed as an application that uses TCP or SCTP as the transport layer protocol. Both TCP and SCTP are reliable that provides lossless, in sequence data delivery. However, in the case of link failure, TCP does not provide sufficient information as to what flow records were processed; and typical implementations do not allow application-level acknowledgment (reliability is provided only at the transport layer). Consequently, CRANE provides its own application-level reliability, to ensure that all records are completely processed before they are acknowledged to the exporting process and can be removed from the transmit queue. In conjunction with CRANE's flow control and fail-over/fail-back procedures, a reliable IPFIX system can be provided. IPFIX-REQ Section 6.3.3 Security -E The CRANE protocol itself does not offer strong security facilities; however, the combination of TCP byte sequence numbering with CRANE=92s data record sequencing would make spoofing very difficult. The reason for not providing CRANE level strong security is due to the fact that many standardized security services such IPSEC and TLS are available, and there is no benefit of duplicating these functionality at the CRANE layer. It is strongly recommended that users of the CRANE protocol evaluate their deployment configurations and implement appropriate security policies. For example, if the CRANE Zhang, et al. Expires - March, 2003 [Page 15] =0C Internet-Draft CRANE Evaluation September = 2002 protocol is deployed over a local area network or a dedicated connection that ensure security, no additional security services or procedures may be required; however, if CRANE clients and servers are connected through the Internet, lower layer security services should be invoked. Using lower layer security services may require configuration of IPFIX exporting and collecting devices, it is not covered by the CRANE protocol. IPFIX-REQ Section 6.4 Regular Reporting Interval -T The CRANE protocol implements push-based flow information export. Triggers for the flow information export are user- configurable. Typical triggers may take into consideration of the amount of flow records available for export, memory consumption on the exporting devices, and a user-defined periodic reporting interval. If configured to report flow information regularly, the exporting process will periodically export available flow information based on the configurable interval. IPFIX-REQ Section 6.5 Notification of Specific Events -T CRANE protocol has a set of query message pairs that allow a collecting process to query the status of an exporting process. It is also configurable at an exporting process to generate notifications based on user-defined list of events and status information contents (defined by a status template). Because CRANE allows multiple template types, some data export can consist of event information. In addition, a CRANE implementation can support MIBs for event notification via SNMP (this is part of XACCT=92s reference implementation). IPFIX-REQ Section 6.6 Anonymization CRANE does not provide anonymization of flow information. In our view, anonymizing exported flow information is end-to-end between a Metering Process and an application; therefore, it is transparent to the IPFIX protocol, and not applicable. 3.5 Configuration [IPFIX-REQ Section 7] Compliances IPFIX-REQ Section 7.1 Configuration of the Metering Process This item is not applicable to the IPFIX protocol, no analysis is provided. IPFIX-REQ Section 7.2 Configuration of the Exporting Process -T Zhang, et al. Expires - March, 2003 [Page 16] =0C Internet-Draft CRANE Evaluation September = 2002 As stated in the IPFIX requirement, the means used for remote configuration is out of the scope of the IPFIX protocol. CRANE itself does not specify how the remote configuration of the exporting process (CRANE Client) is carried out; however, the current CRANE implementation uses the secure SNMP, telnet, or file upload to configure the exporting processes. A set of MIBs maybe defined to achieve this objective. 1. Reporting data format: CRANE uses templates to define reporting data format. 2. Collecting processes: CRANE uses MIBs to capture collecting process information, such as their IP addresses, interface identifiers, etc. 3. Notifications to be sent to the collecting process(es): CRANE supports a set of Status Templates that can be used to report extensive information about the exporting process to collecting process(es). 4. Flow anonymization: not applicable to CRANE 3.6 General Requirements [IPFIX-REQ Section 8] Compliances IPFIX-REQ Section 8.1 Openness -T CRANE can be viewed as an application on top of a reliable transport protocol. It currently runs on top of the widely used TCP, and can also use the relatively new transport protocol - SCTP. In the future, if other reliable transport protocols were developed, CRANE would be easily migrated to use them. CRANE has a flexible and extensible data model that is independent to any information models. It can accommodate all the current and future flow exporting needs, and can support other data exporting systems with their own information models. IPFIX-REQ Section 8.2 Scalability -T CRANE does not have any limitations on how many exporting processes can communicate with one or multiple collecting processes. The collecting process can distinguish exporting processes through their IP addresses, and/or CRANE session ID. IPFIX-REQ Section 8.3 Several Collecting Processes -T CRANE supports redundant collecting process configuration. It has fail-over/fail-back procedures to enable a robust IPFIX system. CRANE protocol supports the de-duplication of flow information that may be caused by retransmission of multiple collecting processes. The combination of the CRANE header Zhang, et al. Expires - March, 2003 [Page 17] =0C Internet-Draft CRANE Evaluation September = 2002 fields (Session ID, Template ID, and Data Sequence Number) uniquely identifies a flow record. The duplicated records can then be removed without inspecting CRANE message payload (or the flow records). 4. Security Considerations For CRANE security considerations, please refer to the protocol specification at http://www.ietf.org/internet-drafts/draft-kzhang- crane-protocol-05.txt[CRANE]. Zhang, et al. Expires - March, 2003 [Page 18] =0C Internet-Draft CRANE Evaluation September = 2002 References [IPFIX-REQ] J. Quittek, "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, Aug. 2002 [IPFIX-ARCH] K.C.Norseth, "Architectural Model for IP Flow Information Export", draft-ietf-ipfix-architecture-02.txt, June 2002 [CRANE] K. Zhang, "XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0", draft-kzhang- crane-protocol-05.txt, August 2002 Zhang, et al. Expires - March, 2003 [Page 19] =0C Author's Addresses Kevin Zhang XACCT Technologies, Inc. 2900 Lakeside Drive Phone: 1-301-992-4697 Santa Clara, CA. 95054 Email: kevin.zhang@xacct.com U.S.A. Eitan Elkin XACCT Technologies, Ltd. 12 Hachilazon St. Phone: 972-3-5764111 Ramat Gan 52522 Email: eitan@xacct.com Israel Peter Ludemann XACCT Technologies, Inc. 2900 Lakeside Drive Phone: 1-408-330-5732 Santa Clara, CA. 95054 Email: peter.ludemann@xacct.com U.S.A. Zhang, et al. Expires - March, 2003 [Page 20] =0C ------=_NextPart_000_0004_01C251EA.C824FEA0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Sep 1 19:24:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29719 for ; Sun, 1 Sep 2002 19:24:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17ldks-0006Jg-00 for ipfix-list@mil.doit.wisc.edu; Sun, 01 Sep 2002 18:03:42 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17ldkp-0006JE-00 for ipfix-eval@net.doit.wisc.edu; Sun, 01 Sep 2002 18:03:39 -0500 Received: (qmail 21642 invoked from network); 1 Sep 2002 23:03:22 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 1 Sep 2002 23:03:22 -0000 Received: from Kevinz ([192.168.2.11]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g81N61s02940; Sun, 1 Sep 2002 16:06:02 -0700 Reply-To: From: "kevin.zhang" To: Cc: "Ipfix@Net. Doit. Wisc. Edu" Subject: [ipfix-eval] CRANE Advocacy Draft Date: Sun, 1 Sep 2002 19:07:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C251EA.C824FEA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C251EA.C824FEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SVBGSVggRXZhbHVhdGlvbiBUZWFtLA0KDQpUaGUgQ1JBTkUgYWR2b2NhY3kgZHJhZnQgaGFzIGJl ZW4gc3VibWl0dGVkIHRvIHRoZSBJRVRGIG9uIFNlcHRlbWJlciAxc3QsIDIwMDIuICBJdCBzaG91 bGQgYmUgYXZhaWxhYmxlIGluIHRoZSBJLUQgZGlyZWN0b3J5IHNob3J0bHkuIEkgaGF2ZSBhbHNv IGF0dGFjaGVkIHRoaXMgZHJhZnQgZm9yIHlvdXIgcmV2aWV3Lg0KDQpUaGUgY3VycmVudCBDUkFO RSBzcGVjaWZpY2F0aW9uIGNhbiBiZSBmb3VuZCBhdDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta3poYW5nLWNyYW5lLXByb3RvY29sLTA1LnR4dCANCg0KVGhhbmtz LA0KDQpLZXZpbiBaaGFuZw0KWEFDQ1QgVGVjaG5vbG9naWVzLEluYy4NCisxKDMwMSk5OTItNDY5 Nw== ------=_NextPart_000_0004_01C251EA.C824FEA0 Content-Type: text/plain; name="draft-kzhang-ipfix-eval-CRANE-00.txt" Content-Disposition: attachment; filename="draft-kzhang-ipfix-eval-CRANE-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Kevin Zhang, Eitan = Elkin Document: draft-kzhang-ipfix-eval-CRANE-00.txt Peter Ludemann IPFIX WG XACCT Technologies Expires: March 2003 September 2002 Evaluation of the CRANE Protocol Against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document provides an evaluation of the applicability of the CRANE protocol developed by XACCT Technologies as an IPFIX protocol. It compares the properties and capabilities of the CRANE protocol with the IPFIX requirements [IPFIX-REQ]. Zhang, et al. Expires - March, 2003 [Page 1] =0C Internet-Draft CRANE Evaluation September = 2002 Table of Contents 1. Introduction..................................................3 1.1 CRANE Standardization.....................................3 1.2 CRANE Implementation......................................4 1.3 CRANE Deployment..........................................4 1.4 Intellectual Properties...................................4 1.5 CRANE Future Evolution....................................5 2. Architectural Considerations..................................6 2.1 CRANE Protocol Overview...................................6 2.2 CRANE Features............................................6 2.3 General Applicability.....................................7 2.4 CRANE Protocol Functions..................................8 2.5 Architectural Differences................................12 3. CRANE vs. IPFIX Requirement - Detailed Compliance Evaluation.13 3.1 Introduction.............................................13 3.2 Distinguish Flows [IPFIX-REQ Section 4] Compliances......13 3.3 Metering Process [IPFIX-REQ Section 5] Compliances.......13 3.4 Data Export [IPFIX-REQ Section 6] Compliances............13 3.5 Configuration [IPFIX-REQ Section 7] Compliances..........16 3.6 General Requirements [IPFIX-REQ Section 8] Compliances...17 4. Security Considerations......................................18 References......................................................19 Author's Addresses..............................................20 Zhang, et al. Expires - March, 2003 [Page 2] =0C Internet-Draft CRANE Evaluation September = 2002 1. Introduction This Internet Draft provides an evaluation of applicability of the CRANE (Common Reliable Accounting for Network Elements) protocol developed by XACCT Technologies as an IPFIX protocol. In this section, we review the current CRANE standardization status and its future plans. In Section 2, CRANE architecture and capabilities are introduced, and its application to the communication interface between an IPFIX exporting process and an = IPFIX collecting process is discussed. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met by the CRANE protocol. 1.1 CRANE Standardization The CRANE protocol was developed by XACCT Technologies in response to the urgent need for a reliable, efficient, and flexible technology to collect IP flow information for various business applications such as accounting, SLA management, fraud detection, and traffic engineering, etc. From the very beginning, CRANE was developed as an open protocol so that it can be widely adopted by the communications industry. More than 30 companies have participated in CRANE's development. These companies represent a broad spectrum of the industry, consisting of vendors for routers, probes, access switches, servers, wireless portals, etc. These companies were involved in different stages of the CRANE development; some companies evaluated the CRANE specification and engaged in detailed technical discussions to enhance the protocol, other companies integrated the CRANE Client agent into their devices and conducted testing with the CRANE Servers. CRANE is not a proprietary protocol; its specification was first submitted to the IETF as an Internet Draft in June 2001. It was presented at the IPFIX BOF session at the London IETF meeting to catalyze the IPFIX standardization process and the establishment of the IPFIX WG. The current CRANE protocol specification Version 1.0 can be obtained at http://www.ietf.org/internet-drafts/draft- kzhang-crane-protocol-05.txt[CRANE]. XACCT intends to continue pursuing CRANE standardization in the IETF. Since its submission in June 2001, the CRANE specification was reviewed and commented by IESG and many IETF participants. It is now in the process of being published by the IETF as an Informational RFC. Our thorough review of CRANE indicates that it meets all the IPFIX requirements; we thus would advocate its adoption as the IPFIX protocol. Zhang, et al. Expires - March, 2003 [Page 3] =0C Internet-Draft CRANE Evaluation September = 2002 If CRANE is adopted as the IPFIX protocol, we would like to see the further enhancement of CRANE by the IPFIX WG. We believe expertise from the IPFIX participants can improve the design of the protocol. XACCT Technologies is committed to continue participating and assisting the IPFIX in standardizing CRANE going forward. 1.2 CRANE Implementation XACCT Technologies has implementations of the CRANE Client and Server. Our implementation allows end-to-end flow record export from exporting processes to collecting processes. A reference CRANE Client implementation has been available to our CRANE partners, and has been integrated by several companies into their devices. Currently, XACCT Technologies is the only source for CRANE implementations. As the CRANE protocol is open to public, any companies interested in this technology are free to develop their own implementations. 1.3 CRANE Deployment The CRANE protocol has been adopted by several data export systems at the data collection interface; these systems are designed to collect accounting and network QoS information for billing and SLA management purposes; and these systems generally require high- volume export of flow information. A number of network equipment vendors have integrated the CRANE Client within their devices, and successfully conducted CRANE interoperability tests with CRANE servers. Currently, there is one multi-vendor commercial deployment of the CRANE protocol with a Tier One US operator. One more deployment (message based accounting) has gone through all the pre-production phases, and ready for commercial deployment. A third deployment that involves probes for network monitoring has gone through lab integration. 1.4 Intellectual Properties XACCT Technologies has submitted its CRANE protocol specification to the IPFIX WG of the IETF for standardization. Our participation in IETF has been/will be in conformity with RFC 2026. To date, XACCT Technologies has not filed any patents concerning the CRANE protocol. In the future, XACCT Technologies may seek patent rights to some aspects of the CRANE protocol implementation. In that case, XACCT Technologies is willing to make available a Zhang, et al. Expires - March, 2003 [Page 4] =0C Internet-Draft CRANE Evaluation September = 2002 nonexclusive license under such patents, on fair, reasonable, and non-discriminatory terms and conditions. 1.5 CRANE Future Evolution If CRANE is adopted as the IPFIX protocol, the IPFIX WG is expected to drive the future development of the protocol. The WG will have the freedom to make modifications of the current design, and add new features as it sees fit. XACCT Technologies is committed to continue participating and assisting the IPFIX in standardizing CRANE going forward. If CRANE is not selected as the IPFIX protocol, XACCT Technologies will continue leading its development to preserve values and competitive advantages it brings to the CRANE community. The CRANE protocol specification 1.0 is stable; the future versions will likely be released as a result of new requirements demanded by the industry. Zhang, et al. Expires - March, 2003 [Page 5] =0C Internet-Draft CRANE Evaluation September = 2002 2. Architectural Considerations This section introduces the architecture of a data exporting system where the CRANE protocol is used. It highlights some key CRANE capabilities that support the reliable and efficient way of communications between IPFIX exporting and collecting processes. 2.1 CRANE Protocol Overview CRANE is a flexible, high performance, and reliable protocol that can be used for exporting IP flow information from IPFIX exporting processes to collecting processes. It has an architecture that is similar to the IPFIX's, and meets all the IPFIX requirements. In addition, CRANE addresses the needs of those devices that require high speed IP flow information export. This is achieved through CRANE's template based data export; it not only significantly reduces the on device data record processing, but also reduces the bandwidth consumption for data export. 2.2 CRANE Features We highlight several key CRANE features. These features go beyond the current IPFIX requirements, and can bring great benefits to many data export systems. End-to-end Reliability The CRANCE protocol uses a reliable transport layer protocol such as TCP or SCTP that ensures in-sequence, reliable data packet delivery. It supports flow control and CRANE protocol level reliability through application-level acknowledgement procedures. As a result, valuable flow information is not only ensured to be delivered reliably across the network, but also processed correctly and stored in persistent storage if required before acknowledgements are sent. The CRANE protocol also supports server redundancy configurations and load balancing; through rapid, automatic failover and failback operations, high level of availability and fault tolerance is offered. Flexibility The CRANE protocol imposes minimal constraints on the type and format of delivered data records. By employing a =93template negotiation=94 procedure, any kind of user-defined data model (e.g. IPFIX data model) can be supported. This enables the CRANE protocol to handle diversified information export requirements. The protocol also supports multiple "sessions" and multiple record "formats" between CRANE clients and servers; this enables different Zhang, et al. Expires - March, 2003 [Page 6] =0C Internet-Draft CRANE Evaluation September = 2002 business applications to subscribe to only their required information. Real-time Exporting The CRANE protocol supports the "push" based data delivery model. This potentially can minimize the latency between data collection at Network Elements and data reception and processing at CRANE servers. Efficiency The CRANE protocol messages have low protocol overhead, and records are encoded in a compact binary format. By negotiating = =93templates=94 beforehand, the proper context of the flow information can be "cached" at CRANE end points, and only the desired data records are transmitted with minimum overhead. Where possible, data are transmitted in the internal form most natural to the exporting device and converted, as necessary, by the receiver (collecting process). This avoids the inefficiencies associated with some encoding schemes, which can place processing overhead on the exporter. Lightweight and Memory Efficiency The CRANE API embedding in network equipment has a footprint of approximated 150 =96 200 KB and demands little CPU processing power (platform dependant, but typically only a few percent). The memory requirement on the client side depends on factors such as record size, failover scenarios, export interface data rate, round-trip delay between the client and server, etc.; it can be provisioned to fit in different types of network equipment. 2.3 General Applicability The CRANE protocol is designed for exporting a variety of information from CRANE Clients to CRANE Servers to serve different network and business applications. CRANE Clients are typically embedded in Exporting Devices; exporting devices may include routers, probes, and access switches, etc. CRANE Servers are hosted by Collection Devices that may be part of mediation systems, accounting/billing systems, and network management systems to facilitate business and operation support. The following figure illustrates the reference model of a data export system using the CRANE protocol. The CRANE reference model maps extremely well with the current IPFIX architecture Zhang, et al. Expires - March, 2003 [Page 7] =0C Internet-Draft CRANE Evaluation September = 2002 [IPIX-ARCH]. On the Exporting Device side, the CRANE Monitoring Entity and the CRANE Client map to the IPFIX Metering Process and Exporting Process respectively; on the Collecting Device side, the CRANE Server maps to the IPFIX collecting process. Throughout the document, we will use IPFIX exporting/collecting process and CRANE Client/Server interchangeably. +---------------+ +---------------+ | +----------+ | | +----------+ | | |Monitoring| | | |Processor | | | |Entity | | | |Entity | | | +----------+ |CRANE | +----------+ | | +----------+ |Protocol | +----------+ | | |CRANE |<=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D>|CRANE = | | | |Client | | | |Server | | | +----------+ | | +----------+ | | Exporting | | Collecting | | Device | | Device | +---------------+ +---------------+ The CRANE Client (mapped to the IPFIX Exporting Process) is an implementation on the data producing side of the CRANE protocol. It is typically integrated with the network element=92s software, enabling it to export flow information to CRANE Servers. The CRANE Server (mapped to the IPFIX Collecting Process) is an implementation on the data receiving side of the CRANE protocol. It is typically part of a Business Support System (BSS) (e.g. Billing, Market Analysis, Fraud detection, etc.), or a mediation system. There could be more than one CRANE server connected to one CRANE client to improve robustness of the IPFIX system. The Monitoring Entity (mapped to the IPFIX Metering Process) is not part of the CRANE protocol. Its primary task is to monitor IP flows, and derive IP flow information. How the Monitoring entity measures and derives flow information is outside the scope of the IPFIX protocol, but the attributes used to describe flow information can comply with the IPFIX information model and IP flow definitions. The Processor Entity is not part of the CRANE protocol. Its primary task is to process the received IP flow information based upon end application=92s requirements. 2.4 CRANE Protocol Functions In this section, we describe some of the functions forming the CRANE protocol. These functions support CRANE capabilities that not Zhang, et al. Expires - March, 2003 [Page 8] =0C Internet-Draft CRANE Evaluation September = 2002 only meet IPFIX requirements, but also offer some desirable features that are beneficial to an IPFIX system. The CRANE protocol is an application that uses the data communications services provided by lower layer protocols. It relies on lower layer protocols to deliver reliable, in-sequence data packets. The following diagram illustrates the CRANE protocol architecture: +----------------+ +----------------+ | CRANE | | CRANE |+ | User | | User ||+ +----------------+ +----------------+|| | CRANE | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> | CRANE = |+| | Client | <---------- | Server ||+ +----------------+ +----------------+|| | Transport | | Transport |+| | Layer | <---------> | Layer ||+ +----------------+ +----------------+|| | Lower | | Lower |+| | Layers | <---------> | Layers ||+ +----------------+ +----------------+|| +----------------+| +----------------+ The transport protocols used for CRANE message delivery may be TCP or SCTP. TCP supports all the CRANE functionality, while SCTP offers some desirable capabilities that could improve the overall performance of data export. 2.4.1 Session Control The CRANE protocol uses connection-oriented information transfer. This choice was made because the connection/session on which flow information is exported is expected to last for a long duration, and the network configuration between protocol end-points is mostly static. Furthermore, this choice makes the support of reliability more convenient. A logical association of session is established between protocol end-points before flow information can be exported. An export session consists of three phases - * Session Establishment * Flow Information Export * Session Termination Zhang, et al. Expires - March, 2003 [Page 9] =0C Internet-Draft CRANE Evaluation September = 2002 During session establishment, a CRANE server issues a request that triggers the transport layer connection setup. After the transport layer connection is established successfully, a set of templates is negotiated between a CRANE client and servers. A Template defines the structure of any Data Record that may be exported from the CRANE client, and specifies the data type, meaning, and location of the fields in the record. The specification of templates relates to the flow definitions, and governs what flow information would be exposed to the external systems. The definition of templates is typically installed in the CRANE clients and servers through network management system, and is out of the scope of the CRANE protocol. The provisioning of templates establishes contexts for the IP flow information exchange, so that both CRANE clients and servers can correctly interpret the information. The CRANE protocol also allows template negotiation that would further improve the efficiency of information transfer. After the session is established successfully, the IP flow information is exported from the exporting device to a collector. The data format is governed by the negotiated templates; the collector will use the template to decode the CRANE data message payload. Error control, congestion control, record de-duplication, and redundancy procedures are executed during flow information export, to ensure reliability and robustness of the system. As a data export session is expected to last for a long duration, no explicit session termination messages are provided by the CRANE protocol. A CRANE session is typically terminated as a result of tearing down of the transport layer connection by the CRANE users. 2.4.2 Error Control The CRANE protocol relies on the lower layer to provide in- sequence, reliable data packet delivery. At the protocol level, it supports error control to ensure the flow information is correctly received, processed, and optionally stored at the collector. Messages (containing flow information) received by the collector are acknowledged. By monitoring the acknowledgements from the collector, the exporting device can re-transmit date messages that are perceived to be lost, for example when a fail-over occurs. 2.4.3 Redundancy Support For improved reliability and robustness, redundant CRANE server configuration MAY be employed. The CRANE protocol supports delivering flow information to alternate CRANE servers. Zhang, et al. Expires - March, 2003 [Page 10] =0C Internet-Draft CRANE Evaluation September = 2002 A CRANE session may comprise of one or more CRANE servers. The redundancy configuration is generally provisioned through the network management system (e.g. addresses of CRANE servers and clients participating in a CRANE session). A Server Priority can be assigned to each CRANE server. A CRANE client delivers data record to its perceived operating CRANE server with the highest priority; if this CRANE server is deemed unreachable, the CRANE client delivers the data to the next highest priority CRANE server that is perceived to be operating. If no perceived operating CRANE servers are available, data may be queued in the CRANE client until any CRANE server is available or the client=92s queue space runs out. An alarm SHOULD be generated to inform the CRANE user of the queue overflow condition. Data record exporting SHOULD revert to the higher priority server when it is perceived to be operating again. The conditions under which a fail-over/fail-back may occur include: A) Transport layer notifies the CRANE client that the corresponding port of the CRANE server is unresponsive. B) Total size of unacknowledged data records has exceeded a threshold (configurable) for certain duration (configurable). C) An explicit message is received from the active server instructing the switch over. D) A lower priority server is the active one and a higher priority server has recovered. 2.4.4 Template Management The CRANE protocol enables efficient delivery of accounting data. This is achieved by negotiating a set of Data Templates for a CRANE session before actual accounting data is delivered. A data template defines the structure of a DATA message payload by describing the data type, meaning, and location of the fields in the payload. By agreeing on session templates, CRANE servers understand how to process DATA messages received from a CRANE client. As a result, a CRANE client only needs to deliver actual flow information without attaching any descriptors of the data; this reduces the amount of bytes sent over communication links. The CRANE protocol supports usage of several templates concurrently (for different flow data records). In a CRANE session, all the CRANE servers and the CRANE client must use the same set of Zhang, et al. Expires - March, 2003 [Page 11] =0C Internet-Draft CRANE Evaluation September = 2002 templates. The templates are provisioned through network management system. The complete set of templates residing in a CRANE client MUST bear a configuration ID that identifies the template set. Each data record is delivered with the Template ID and the Configuration ID, so that the correct template can be referenced. A server, when receiving a record with an older Configuration ID, MAY handle the record gracefully by keeping some template history. The transport layer SHOULD ensure that a server would not get messages with future configuration IDs. 2.5 Architectural Differences There are no major architectural differences between the IPFIX system and the data export system that CRANE is currently deployed. The data export systems that CRANE is currently deployed are more generic then IPFIX systems. The Monitoring Entity function in these systems is not limited in monitoring IP flow information. It can meter data communications across all layers, and provide transaction information corresponding to specific applications. Therefore, the IPFIX architecture can be viewed as a subset of these data export systems. The flexible and extensible CRANE data model can therefore cover all the IPFIX attributes. Zhang, et al. Expires - March, 2003 [Page 12] =0C Internet-Draft CRANE Evaluation September = 2002 3. CRANE vs. IPFIX Requirement - Detailed Compliance Evaluation 3.1 Introduction This section evaluates the compliance of the CRANE protocol [CRANE] with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement, it is explained to what degree CRANE meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance -E Extension required for total compliance -P Partial compliance -U Upcoming compliance -F Failed compliance 3.2 Distinguish Flows [IPFIX-REQ Section 4] Compliances Distinguishing flows is one of the tasks performed by the IPFIX Metering Processes; therefore, it is not applicable to the IPFIX Protocol. No detailed analysis is provided for IPFIX-REQ Section 4. From a protocol point of view, the CRANE protocol supports all the necessary data types for IP flow record exporting and allows arbitrary =93flat=94 records. In an IPFIX system, a flow definition would determine how IP flows are distinguished. The CRANE template definition effectively reflects the flow definition, and can be installed in IPFIX exporting devices through configuration. The template definition would then determine how flow information is metered and exported to collecting devices. 3.3 Metering Process [IPFIX-REQ Section 5] Compliances The IPFIX Metering Process primarily deals with the measurement of the IP flow information. It is not applicable to the IPFIX protocol, which is solely used for communications between IPFIX exporting and collecting processes. Therefore, no detailed analysis is provided for IPFIX-REQ Section 5. From a protocol point of view, the CRANE protocol supports all the necessary data types for IP flow information export and allows arbitrary =93flat=94 records. 3.4 Data Export [IPFIX-REQ Section 6] Compliances Zhang, et al. Expires - March, 2003 [Page 13] =0C Internet-Draft CRANE Evaluation September = 2002 IPFIX-REQ Section 6.1 Information Model -T The information model is a list of the attributes that need to be reported to IPFIX collecting processes. The CRANE protocol is independent to an information model that is typically coupled with the Metering Process capabilities. CRANE does not limit what can be exported; it supports the standard IPFIX information model as well as other attributes (standard or proprietary) that the Metering Process wishes to expose. IPFIX-REQ Section 6.2 Data Model -T CRANE implements a Template based data model. A Template defines the structure of any types of IP Flow Record, and specifies the data type, meaning, and location of the fields in the record. A field typically carries an attribute specification that the exporting process wants to export. The template can be viewed as meta-data that describes how IP flow information is encoded in the payload of the relevant CRANE messages. It also indicates the context of which the flow information should be interpreted. Templates are user defined and installed in the exporting and collecting processes through local or remote configuration. CRANE data model is extensible as Templates can be easily created, modified, or deleted. CRANE supports the modification of a Template by adding (enabling) and deleting (disabling) attribute fields. CRANE data model is flexible; besides a few mandatory header fields (such as Template ID, Number of Keys, etc.) that must be present in a template, no further constraints are imposed on the data record format, number of attributes (keys) contained in a template, sequence or position of attributes (keys) in a template, and attribute data types, etc. CRANE templates are configurable locally or remotely. Beyond extensibility and flexibility, template based data model allows flow information to be transmitted in their natural form, without complex encoding/decoding, minimizing the processing overhead at the exporting and collecting processes. Furthermore, as flow records are transmitted without embedded tags, significant bandwidth savings can be achieved. IPFIX-REQ Section 6.3 Data Transfer -T CRANE complies with all the requirement items outlined in IPFIX- REQ Section 6.3. IPFIX-REQ Section 6.3.1 Congestion Awareness -T Zhang, et al. Expires - March, 2003 [Page 14] =0C Internet-Draft CRANE Evaluation September = 2002 CRANE can be viewed as an application that uses TCP or SCTP as the transport layer protocol. Both TCP and SCTP are congestion aware. In addition to meeting the congestion aware requirement, CRANE offers sufficient capabilities to allow an implementation to provide additional application-level flow control and fail- over/fail-back procedures. The detection of congested/overloaded collecting processes as well as congested links would enable the exporting process to take actions in mitigating the situation, e.g. reducing its flow record exporting rate or switching over to a redundant collecting process. In summary, CRANE is not only congestion aware to link conditions, but is also aware of the processing bottlenecks at collection processes. IPFIX-REQ Section 6.3.2 Reliability -T CRANE can be viewed as an application that uses TCP or SCTP as the transport layer protocol. Both TCP and SCTP are reliable that provides lossless, in sequence data delivery. However, in the case of link failure, TCP does not provide sufficient information as to what flow records were processed; and typical implementations do not allow application-level acknowledgment (reliability is provided only at the transport layer). Consequently, CRANE provides its own application-level reliability, to ensure that all records are completely processed before they are acknowledged to the exporting process and can be removed from the transmit queue. In conjunction with CRANE's flow control and fail-over/fail-back procedures, a reliable IPFIX system can be provided. IPFIX-REQ Section 6.3.3 Security -E The CRANE protocol itself does not offer strong security facilities; however, the combination of TCP byte sequence numbering with CRANE=92s data record sequencing would make spoofing very difficult. The reason for not providing CRANE level strong security is due to the fact that many standardized security services such IPSEC and TLS are available, and there is no benefit of duplicating these functionality at the CRANE layer. It is strongly recommended that users of the CRANE protocol evaluate their deployment configurations and implement appropriate security policies. For example, if the CRANE Zhang, et al. Expires - March, 2003 [Page 15] =0C Internet-Draft CRANE Evaluation September = 2002 protocol is deployed over a local area network or a dedicated connection that ensure security, no additional security services or procedures may be required; however, if CRANE clients and servers are connected through the Internet, lower layer security services should be invoked. Using lower layer security services may require configuration of IPFIX exporting and collecting devices, it is not covered by the CRANE protocol. IPFIX-REQ Section 6.4 Regular Reporting Interval -T The CRANE protocol implements push-based flow information export. Triggers for the flow information export are user- configurable. Typical triggers may take into consideration of the amount of flow records available for export, memory consumption on the exporting devices, and a user-defined periodic reporting interval. If configured to report flow information regularly, the exporting process will periodically export available flow information based on the configurable interval. IPFIX-REQ Section 6.5 Notification of Specific Events -T CRANE protocol has a set of query message pairs that allow a collecting process to query the status of an exporting process. It is also configurable at an exporting process to generate notifications based on user-defined list of events and status information contents (defined by a status template). Because CRANE allows multiple template types, some data export can consist of event information. In addition, a CRANE implementation can support MIBs for event notification via SNMP (this is part of XACCT=92s reference implementation). IPFIX-REQ Section 6.6 Anonymization CRANE does not provide anonymization of flow information. In our view, anonymizing exported flow information is end-to-end between a Metering Process and an application; therefore, it is transparent to the IPFIX protocol, and not applicable. 3.5 Configuration [IPFIX-REQ Section 7] Compliances IPFIX-REQ Section 7.1 Configuration of the Metering Process This item is not applicable to the IPFIX protocol, no analysis is provided. IPFIX-REQ Section 7.2 Configuration of the Exporting Process -T Zhang, et al. Expires - March, 2003 [Page 16] =0C Internet-Draft CRANE Evaluation September = 2002 As stated in the IPFIX requirement, the means used for remote configuration is out of the scope of the IPFIX protocol. CRANE itself does not specify how the remote configuration of the exporting process (CRANE Client) is carried out; however, the current CRANE implementation uses the secure SNMP, telnet, or file upload to configure the exporting processes. A set of MIBs maybe defined to achieve this objective. 1. Reporting data format: CRANE uses templates to define reporting data format. 2. Collecting processes: CRANE uses MIBs to capture collecting process information, such as their IP addresses, interface identifiers, etc. 3. Notifications to be sent to the collecting process(es): CRANE supports a set of Status Templates that can be used to report extensive information about the exporting process to collecting process(es). 4. Flow anonymization: not applicable to CRANE 3.6 General Requirements [IPFIX-REQ Section 8] Compliances IPFIX-REQ Section 8.1 Openness -T CRANE can be viewed as an application on top of a reliable transport protocol. It currently runs on top of the widely used TCP, and can also use the relatively new transport protocol - SCTP. In the future, if other reliable transport protocols were developed, CRANE would be easily migrated to use them. CRANE has a flexible and extensible data model that is independent to any information models. It can accommodate all the current and future flow exporting needs, and can support other data exporting systems with their own information models. IPFIX-REQ Section 8.2 Scalability -T CRANE does not have any limitations on how many exporting processes can communicate with one or multiple collecting processes. The collecting process can distinguish exporting processes through their IP addresses, and/or CRANE session ID. IPFIX-REQ Section 8.3 Several Collecting Processes -T CRANE supports redundant collecting process configuration. It has fail-over/fail-back procedures to enable a robust IPFIX system. CRANE protocol supports the de-duplication of flow information that may be caused by retransmission of multiple collecting processes. The combination of the CRANE header Zhang, et al. Expires - March, 2003 [Page 17] =0C Internet-Draft CRANE Evaluation September = 2002 fields (Session ID, Template ID, and Data Sequence Number) uniquely identifies a flow record. The duplicated records can then be removed without inspecting CRANE message payload (or the flow records). 4. Security Considerations For CRANE security considerations, please refer to the protocol specification at http://www.ietf.org/internet-drafts/draft-kzhang- crane-protocol-05.txt[CRANE]. Zhang, et al. Expires - March, 2003 [Page 18] =0C Internet-Draft CRANE Evaluation September = 2002 References [IPFIX-REQ] J. Quittek, "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, Aug. 2002 [IPFIX-ARCH] K.C.Norseth, "Architectural Model for IP Flow Information Export", draft-ietf-ipfix-architecture-02.txt, June 2002 [CRANE] K. Zhang, "XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0", draft-kzhang- crane-protocol-05.txt, August 2002 Zhang, et al. Expires - March, 2003 [Page 19] =0C Author's Addresses Kevin Zhang XACCT Technologies, Inc. 2900 Lakeside Drive Phone: 1-301-992-4697 Santa Clara, CA. 95054 Email: kevin.zhang@xacct.com U.S.A. Eitan Elkin XACCT Technologies, Ltd. 12 Hachilazon St. Phone: 972-3-5764111 Ramat Gan 52522 Email: eitan@xacct.com Israel Peter Ludemann XACCT Technologies, Inc. 2900 Lakeside Drive Phone: 1-408-330-5732 Santa Clara, CA. 95054 Email: peter.ludemann@xacct.com U.S.A. Zhang, et al. Expires - March, 2003 [Page 20] =0C ------=_NextPart_000_0004_01C251EA.C824FEA0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 2 11:17:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24445 for ; Mon, 2 Sep 2002 11:17:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17lsct-0006cQ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Sep 2002 09:56:27 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17lscr-0006bc-00 for ipfix@net.doit.wisc.edu; Mon, 02 Sep 2002 09:56:25 -0500 Received: from riverstonenet.com ([134.141.180.81]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Sep 2002 07:55:44 -0700 Message-ID: <3D737B8A.AB6CB6D3@riverstonenet.com> Date: Mon, 02 Sep 2002 10:54:02 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipfixx Subject: [ipfix] LFAP Submission Content-Type: multipart/mixed; boundary="------------8C586C0A5E3873FA3D088F71" X-OriginalArrivalTime: 02 Sep 2002 14:55:44.0567 (UTC) FILETIME=[D0719C70:01C25290] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------8C586C0A5E3873FA3D088F71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the LFAP submission (sent to eval team yesterday). Should be on the IETF web page shortly. These are the relevant LFAP specifications... http://www.ietf.org/internet-drafts/draft-riverstone-lfap-01.txt http://www.ietf.org/internet-drafts/draft-riverstone-lfap-data-01.tx --------------8C586C0A5E3873FA3D088F71 Content-Type: text/plain; charset=us-ascii; name="draft-advocate-ipfix-LFAP-eval-05.txt" Content-Disposition: inline; filename="draft-advocate-ipfix-LFAP-eval-05.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT Expires: February 2003 INTERNET-DRAFT Internet Draft Paul Calato Document: draft-ietf-ipfix-reqs-04.txt Riverstone Networks Expires: January 2003 August 2002 Evaluation Of Protocol LFAP Against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the LFAP protocol as an IPFIX protocol. It compares the properties and capabilities of the LFAP protocol to the IPFIX requirements version 05 [IPFIX- REQ]. Calato Informational [Page 1] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Table of Contents 1. INTRODUCTION ......................................................4 2. ARCHITECTURAL CONSIDERATIONS ......................................5 2.1 LFAP ARCHITECTURE HIGHLIGHTS ...................................6 2.1.1. Flow Records ...............................................6 2.1.2. Information Model ..........................................6 2.1.3. Data Model .................................................6 2.1.4. Scalability ................................................6 2.1.5. Security ...................................................7 2.1.6. Statistics .................................................7 2.1.7. Protocol Maturity ..........................................7 2.2 LFAP PROTOCOL OVERVIEW .........................................8 2.2.1. LFAP Flow Ids ..............................................9 2.2.2. Periodic reporting versus singular reporting ...............9 2.2.3. Protocol Example ..........................................10 2.3 GENERAL APPLICABILITY .........................................11 2.3.1. Requirements Section 2.1 IP Traffic Flow ..................11 2.3.2. Requirements Section 2.2 Observation Point ................11 2.3.3. Requirements Section 2.3 Metering .........................11 2.3.4. Requirements Section 2.5 Exporting Process ................11 2.3.5. Requirements Section 2.4 Flow Record ......................13 2.3.6. Requirements Section 2.6 Collecting Process ...............13 2.4 ARCHITECTURAL DIFFERENCES .....................................14 3. ITEM LEVEL COMPLIANCE EVALUATION .................................14 3.1 EXTENDING LFAP ................................................14 3.1.1. Vendor Specific ...........................................15 3.1.2. Information Element Extension .............................15 3.1.3. AR/ARA Message Extension ..................................15 3.1.4. MIB Extensions ............................................15 3.2 REQUIREMENTS SECTION 4 DISTINGUISHING FLOWS ...................15 3.3 REQUIREMENTS SECTION 5 METERING ............................16 3.3.1. Requirements Section 5.1 Reliability ......................16 3.3.2. Requirements Section 5.2 Sampling .........................16 3.3.3. Requirements Section 5.3 Overload .........................16 3.3.4. Requirements Section 5.4 Timestamps .......................17 3.3.5. Requirements Section 5.5 Time Synchronization .............17 3.3.6. Requirements Section 5.6 Flow Expiration ..................17 3.3.7. Requirements Section 5.7 Multicast ........................17 3.3.8. Requirements Section 5.8 Ignore Port Copy .................18 3.3.9. Requirements Section 6.1 Information Model ................18 3.3.10. Templated Data ...........................................21 3.3.11. Requirements Section 6.2 Data Model ......................21 3.3.12. Requirements Section 6.3.1 Congestion Awareness ..........22 3.3.13. Requirements Section 6.3.2 Reliability ...................22 3.3.14. Requirements Section 6.3.3 Security ......................22 Calato Informational [Page 2] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.3.15. Requirements Section 6.4 Regular Reporting ...............22 3.3.16. Requirements Section 6.5 Notification on Specific Events .23 3.3.17. Requirements Section 6.6 Anonymization ...................23 3.3.18. Requirements Section 7.1 Configuration of the Metering ...23 5. Overload behavior .............................................23 3.3.19. Requirements Section 7.2 Configuration of the Exporting ..23 3.3.20. Requirements Section 8.1 Openness ........................24 3.3.21. Requirements Section 8.2 Scalability Concerning the Number of Exporting Processes ...........................................24 3.3.22. Requirements Section 8.3 Several Collecting Processes ....24 4. SECURITY CONSIDERATIONS ..........................................24 4.1 REQUIREMENTS SECTION 6.3.3 SECURITY ...........................24 4.2 REQUIREMENTS SECTION 10.1 DISCLOSURE OF FLOW INFORMATION DATA .25 4.3 REQUIREMENTS SECTION 10.2 FORGERY OF FLOW RECORDS ..........25 4.4 REQUIREMENTS SECTION 10.3 DENIAL OF ERVICE (D S OS) ATTACKS .....26 5. REFERENCES .......................................................27 6. AUTHOR'S ADDRESS .................................................27 7. FULL COPYRIGHT STATEMENT .........................................27 Calato Informational [Page 3] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 1. Introduction This document provides an evaluation of the applicability of the LFAP protocol as an IPFIX protocol. First, the general LFAP architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met. This document uses the terminology defined in [IPFIX-REQ]. LFAP [1][2] was originally submitted to the IETF as RFC 2124 [3] in 1997. Since then it has under gone a number of revisions. Revisions were submitted as Internet Drafts. The latest revision can be found at http://www.ietf.org/internet-drafts/draft-riverstone-lfap-01.txt http://www.ietf.org/internet-drafts/draft-riverstone-lfap-data- 01.txt LFAP is completely unencumbered and is available for use by the internet community. Calato Informational [Page 4] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2. Architectural Considerations This section introduces the architecture of the LFAP protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. LFAP was developed specifically for IP flow accounting. As such it is well suited to support the communication between the Exporting Process and an IPFIX Collecting process. The basic architecture is depicted below: +---------------------------+ | | | | | Application | | | +--//-----------------------+\ // \\ // \\ // \\ +--/--+ +--\--+ | | | | | C1 | | C2 | +--|\-+ +-/+-\+ /| \\ // | \ / | \\ // | \ // | \\ // | \ / | \ / | \ / | \\ // | \ / | \\ // | \ +--/--+ +--+--+ +--\--+ +--/--+ +--+--+ +--\--+ | | | | | | | | | | | | | ID1 | | ID2 | | ID3 | | ID4 | | ID5 | | ID6 | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ One Collecting process services multiple IPFIX Devices. Each IPFIX Device may have one or more backup Collectors. In case of failure, ID1 _ ID3 would also point to C2 and ID4 _ ID6 would point to C1. An application then retrieves the flow data from the Collecting devices. The LFAP protocol is used between the IPFIX Devices and Collecting process to exchange flow accounting data. See section 2.3.4 of this document for a detailed view of an IPFIX device in both LFAP and IPFIX terms. Calato Informational [Page 5] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.1 LFAP Architecture Highlights This section provides an overview of the LFAP Architecture's highlights. 2.1.1. Flow Records LFAP splits flow records along the line of characteristic properties (e.g. source IP) as described in the requirements document section 2.4 Flow Record and measured properties (e.g. bytes) also described in section 2.4. This split allows lower memory requirements for the IPFIX Device. Since the characteristics properties are sent independent of measured characteristics, there is no need to store the characteristic properties until update time. This split also allows lower bandwidth consumption since only measured properties need to be reported with each update. See Section 2.2 of this document for a detailed example. If no split is desired information could be combined. 2.1.2. Information Model LFAP defines a very strong Information Model. Information Elements exchanged have a well defined meaning. LFAP itself defines very little in the way of new data elements. The majority of data is defined in such a way as to use the semantics and value range from the protocol being reported. For example, the Class of Service field is defined in terms of RFC 791 (see section 2.8 of the LFAP data specification [2]). 2.1.3. Data Model LFAP defines data precisely and uses a TLV format to encode transfer of information. Dense encoding is supported via a multi- record structure, which allows type and length to be provided once for all flows reported in the message. Semantic information still resides close by the data to minimize potential interpretation errors. The TLV format also allows extension, as unknown data elements can be easily skipped using the length field. Using a TLV format also makes debugging messages straightforward. 2.1.4. Scalability Since LFAP was designed for IP flow accounting, there is little in the way of non-IP-flow data being passed. Messages with Flow data are dense and compact. LFAP was also designed to minimize memory and CPU consumption on the device. Messages are simplified so that transfer of state information requirements is minimal. For example, on failover from one server to another, IP flows can continue send a flow's periodic updates to the new Collector with absolutely no extra work on the part of the IPFIX device. Also since flow data Calato Informational [Page 6] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 merely needs to be encoded and sent, CPU usage is minimal. 2.1.5. Security The LFAP specification has a complete section on security. It also paves the way for field level security, which may reduce the CPU cycles needed to implement security features. LFAP provides multiple levels of security and it allows security to be handled externally (e.g. by the transport layer), via LFAP protocol itself or a combination. If LFAP itself is used, protection against any combination of these attacks are covered in the specification: 1) Message altering 2) Message replay 3) Message Insertion 4) Message reading (snooping) 5) Impersonation of a CCE or FAS 2.1.6. Statistics LFAP defines a complete management plane for monitoring a running flow information exchange system. These statistics allow detection of problems and even provide a gauge on the extent of damage. For example, if there is loss of connectivity to the Collector for an extended period, a counter will indicate the number of bytes dropped (i.e. not counted) so the damage from loss of connectivity can be assessed. The protocol defines a base set of metric and operational state so that testing for interoperability is simplified. 2.1.7. Protocol Maturity LFAP was originally submitted to the IETF as RFC 2124 in 1997. Since then it has under gone a number of improvements. The basic model and design have been proven with time. LFAP also has working open source implementations /SDKkits freely available on http://www.nmops.org. The code base has been shipping in commercial products for several years. An LFAP API source kit is available from www.nmops.org. The kit can be used for building both client and server applications. The LFAP API was also ported to NT for use as a probe. LFAP servers are also freely available from www.nmops.org. XACCT Technologies distributes a commercial version of that LFAP server. lfapd written by Steven Premeau, used for Flowscan, is another open source server. InMon Corporation developed an LFAP server for use with its products. Clients and Calato Informational [Page 7] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Servers have been built on Solaris, Linux and NT. Lastly, over time LFAP has built up several debugging tools. The first is a client simulator for testing servers. The second is a server simulator for testing clients. Tests are written using ASCII files with test validation built in. A complete set of message dumping facilities are embedded in the LFAP API. Lastly, a load driver for performance testing is also available. The LFAP protocol is mature protocol specifically designed for the demands of IP accounting. 2.2 LFAP Protocol Overview The LFAP message structure is relatively simple. The following diagram represents which messages each side of the LFAP protocol sends. ,----------------------------. ,-----------------------------. | Collector | | IPFIX Device | | | | | `|---+--------|---|-----|----' `---|---|------------|---+----' | ^ ^ | | ^ | ^ | ^ | ^ ^ | ^ ^ | | | | | | | | | | | | | | | | | | | | | | | | VR | | | | | | | | | | | | | | | `---------------' | | | | | | | | | | | | | | VRA | | | | | | | | | | | | | `--------------------' | | | | | | | | | | | | CR | | | | | | | | | | | `------------------------' | | | | | | | | | | | | | | | | | | | | CAN/CRN/DR | | | | | | | | | `---------------------------------' | | | | | | | | | | | | | | | | FER | | | | | | | `-----------------------------------------' | | | | | | | | | | | | FAR/FUN | | | | | `-------------------------------------------------' | | | | | | | | AR/ARA | | | `----------------------------------------------------------' | | | | KA | `------------------------------------------------------------------' LFAP consists of an initial handshake followed by flow export. The Calato Informational [Page 8] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 handshake consists of the VR, VRA, CR, CAN/CRN/DR, AR, ARA and FER messages. Flow export consists of the FAR and FUN messages. The FAR indicates the start of a flow and contains all the requested data elements. The FUN provides periodic updates concerning bytes, packets and time. A state field in the FUN indicates the flow's termination. During the handshake the IPFIX device initiates a TCP connection to a Collector. Session establishment then happens in three phases following TCP connection establishment. In the first phase the LFAP version is exchanged and verified via the VR and VRA messages. In the second phase, the Collector allows or denies the connection via the CRN/CAN/DR messages. The third phase allows setup information to be exchanged via the AR and ARA messages, before flow export begins. For example, the list of Information Elements to be reported may be sent in this phase. Finally, the Collecting device sends the FER and flow export may begin. For more details see the state machine on session establishment in section 6.4 of the LFAP specification [1]. The KA message allows the IPFIX device to quickly detect the loss of a Collector. 2.2.1. LFAP Flow Ids An LFAP Flow ID uniquely identifies a flow. It is used to correlate characteristic properties and all periodic updates. 2.2.2. Periodic reporting versus singular reporting With singular reporting, all characteristic properties and measured properties are reported at the same time. Each report is independent of other flow reports. LFAP Flow IDs in this case are not necessary. With periodic reporting, a flow is reported on more than once. Flow IDs are used to correlate multiple reports to the same flow. Periodic reporting is be more difficult because information can be dispersed plus possible Collector failures. LFAP has done a good job solving this problem with its Flow ID, message structure and failover design. If IPFIX WG determines that singular reporting must be supported the LFAP specification would need to be slightly modified to allow measured characteristics in the FAR message. LFAP is well positioned to handle the more complex case of periodic reporting in addition to the simpler singular reporting. Calato Informational [Page 9] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.2.3. Protocol Example Assume F1 is a flow with a very narrow flow key, which is to be updated once per minute. Assume F2 is a flow with a very coarse flow key and is to be updated once every 15 minutes. For the sake of example, assume F1 uses cumulative bytes value and F2 uses delta byte values. For simplicity time calculations will not be shown, but are similar to processing for cumulative and delta byte calculations. The message structure and processing would be as follows. Time Message Processing ---- -------------- ---------------------------------------- T1 FAR The first packet for F1 is seen at T1. A FAR message is sent with the requested characteristic properties at T1. T2 FAR The first packet for F2 is seen at T2. A FAR message is sent with the requested characteristic properties at T2 T3 F1 FUN T3 is time to update F1. Current statistics S1 are retrieved. Since the statistics are cumulative the Collector uses S1 _ 0 (zero) to calculate the statistics for this interval. T4 F1 FUN T3 is time to update F1 again. Current statistics S2 are retrieved. Since the statistics are cumulative the Collector uses S2 _ S1 to calculate the statistics for this interval. Several more updates for happen before F2 is updated T17 F2 FUN T17 is time to update F2. Current delta statistics DS1 are retrieved. Since the statistics are in delta form the Collector uses DS1 statistics for this interval. Calato Informational [Page 10] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.3 General Applicability 2.3.1. Requirements Section 2.1 IP Traffic Flow LFAP is compatible with the flow definition described. 2.3.2. Requirements Section 2.2 Observation Point 2.3.3. Requirements Section 2.3 Metering 2.3.4. Requirements Section 2.5 Exporting Process These 3 items map to the Connection Control Entity (CCE) in the LFAP specifications. A detailed view of a CCE and how it maps to IPFIX is provided below. Calato Informational [Page 11] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 +--------------------------------------------------------------------+ | ^ | | | Send Message to Collector | | +----------+ Remove +-------+------------+ +-------+ | | | Msg Queue|<--------| LFAP Processing API|<-----+Timers | | | +----------+ | | +-------+ | | ^ +--+------------+----+ | | | |Lookup |Flow Update | | | | | Exporting Process +---------------------------------|------------|---------------------+ | | v | | | | +--------------------------+-| | | | |Flow ID -> Flow table key | | | | | +--------------------------- | | | | ^ | | | | | | | | | Add | | | | +----+------+---+ | | | | LFAP Flow API |Get stats | | | | +-------------+ | | | +---------------+ | | | | ^ | | | | | Flow Start | | | | | Flow End | | | | +-----+---------+ | | | | | Flow Mgt | | | | | +-----> Flow Key | | | | | | | Forward* |------>Packet | | | | | +---------------+ | | | | | | Create - forward/filter| | | | | | Delete | | Metering Process +--|-----------|------------------------|------|---------------------+ | | +-----v--------------+ | | | | | | Flow Table Stats|<--------+ | | | | | |<---------------+ | | | +--------------------+ | | | ^ | | | | | | | | Lookup | | | +-----+------+ | | | | Forward ---+--------> Packet | | | | Filter-----+-----+ | | +-----+ Not Found | | | |Packet +------------+ ----- | | ^ --- | | | - | | Packet---+ Observation Point +--------------------------------------------------------------------+ Figure 1 - CCE ==> IPFIX Arcitecture Calato Informational [Page 12] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 This diagram assumes the device performs some function besides Metering. In a pure passive probe environment some of the device functions would be deleted. A packet arrives at the Observation point and a lookup is done in the flow table. If an entry is found the packet will either be forwarded or dropped. If no entry is found it is sent to the Flow Management system. Flow Management in the diagram includes both device functions (e.g. router functions) and IPFIX Metering functions. In Flow Management the flow key is determined and the flow table is programmed (device functions). IPFIX Metering is notified a flow has been created. Current implementations of LFAP use the device's flow key as the IP flow key. However, for IPFIX purposes this is where the flow would be distinguished based on current IPFIX configuration along with IPFIX Flow Filtering. A message with the characteristic properties is created and sent (usually just added to a queue to be sent in batches). Also the LFAP Flow ID to device flow key is maintained. This is the only piece of state needed for reporting periodic updates. System timers notify LFAP Processing of flow update intervals. Flow timeouts are based on inactivity (not shown in diagram) and Flow management is notified of the event which triggers an LFAP delete notification. The LFAP Processing sends the messages in the queue in addition to sending periodic updates. The Flow ID is used to lookup the matching device flow table key and retrieve statistics. 2.3.5. Requirements Section 2.4 Flow Record In LFAP a flow record maps to 2 messages. The FAR message contains all the characteristic properties such as Source IP, Destination IP, etc_. The FUN message maps to the measured properties such as bytes and packets. This split allows lower memory requirements for the IPFIX Device. Since the characteristics properties are sent independent of measured characteristics, there is no need to store the characteristic properties until update time. This also allows LFAP to report regular updates for a flow without repeating the flow characteristics. Thereby minimizing what is transferred over the network at the expense of keeping minimal state in the CCE for microflow or flow aggregates being reported. 2.3.6. Requirements Section 2.6 Collecting Process The Collecting process maps directly to the Flow Accounting Server (FAS) in the LFAP specification. Calato Informational [Page 13] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.4 Architectural Differences LFAP was designed specifically for IP flow information export and defines the data and transfer protocol whereas IPFIX so far has focused on the architectural constructs of IP flow collection requirements/semantics and processing. Specific differences between LFAP and IPFIX requirements are described under the compliance section. 3. Item Level Compliance Evaluation This section evaluates the compliance of the LFAP protocol with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement it is explained to what degree the LFAP protocol meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is only applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protocols, where the protocol specification itself needs to be extended in order to comply with the requirement. -P Partial compliance: The requirement is met partially by the protocol specification. -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. 3.1 Extending LFAP LFAP can be extended in 4 ways. In general extensions can be made without breaking existing Collectors. Each method is described below. Calato Informational [Page 14] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.1.1. Vendor Specific The Vendor Specific Information Element allows individual vendors to send extra information in any message without modifying the LFAP specification or breaking existing Collectors. The specification states that any information supplied in the Vendor Specific IE MUST be able to be safely ignored. See section 2.45 in the LFAP data specification [2] for a detailed description of the IE. 3.1.2. Information Element Extension The LFAP data specification can be modified with new Information Elements. The LFAP message structure and data semantics will remain the same. The LFAP specification indicates that unknown IE's are to be ignored so compatibility with existing Collectors is maintained. Adding a new element merely involves allocating the next Information Element number and adding the necessary text to the specification. 3.1.3. AR/ARA Message Extension These message are intended to contain control information which needs to be exchanged between the IPFIX Device and the Collecting process. The basic choice here is whether the information is better suited to the MIB or an outside configuration mechanism. Once the decision is made to use the AR/ARA messages, a new command value is allocated along with allocating any supporting Information Elements. Unknown commands are ignored by both the IPFIX device and the Collecting Device. If the command is not optional, the LFAP version number would need to be incremented resulting in an incompatibility for existing Collector and IPFIX Devices. 3.1.4. MIB Extensions New objects may be added for configuration or monitoring. 3.2 Requirements Section 4 Distinguishing Flows Requirements Section 4.1 Interfaces Requirements Section 4.2 IP Header Requirements Section 4.3 Transport Header Fields Requirements Section 4.4 MPLS Requirements Section 4.5 DiffServ Code Requirements Section 4.6 Header Compression and Encryption Calato Informational [Page 15] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Compliance = T Any combination of attributes and/or functions may be used to distinguish flows. The resulting flow may then be exported using LFAP. 3.3 Requirements Section 5 Metering 3.3.1. Requirements Section 5.1 Reliability Compliance = T LFAP has the following statistics defined. Dropped messages A count of the number of FAR or FUN messages the CCE could not be transmitted to the FAS while not in Send State. Dropped messages while connected A count of the number of FAR or FUN messages the CCE could not be transmitted to the FAS while in Send State. Number of bytes not accounted for due to dropped messages A count of the number of bytes accounted for in FUN messages being dropped that CCE could not transmit to the FAS while in Send State. Number of packets not accounted for due to dropped messages A count of the number of packets accounted for on the wire that CCE could not transmit to the FAS while in Send State. 3.3.2. Requirements Section 5.2 Sampling Compliance = F LFAP does not have any support for sampling. However, it is certainly possible to extend it to contain the necessary support. For example, LFAP already has the notion of multiple types of flows. In this case extending LFAP to allow a FAR with a flow type of _sampled_ may be sufficient. 3.3.3. Requirements Section 5.3 Overload Compliance = T Calato Informational [Page 16] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 LFAP indicates that flows may be dropped and keeps statistics on this behavior. However, this should be stated more explicitly in the specification. Since the overload behavior is to stop reporting, there is no need to distinguish the flows from before and after the event. There is also no need to terminate all existing flows when this event occurs. The MUSTs in the requirements, I believe, do not apply to all overload behaviors. 3.3.4. Requirements Section 5.4 Timestamps Compliance = T* * - The LFAP specification indicates the start time is when the flow was created. This generally coincides with the first packet, but the specification does not mandate it. Furthermore, the end time is when the statistics were gathered. This generally coincides with the flow being timed out or the last packet. But again the specification does not mandate it. 3.3.5. Requirements Section 5.5 Time Synchronization Compliance = T LFAP provides a way to obtain time information from the IPFIX device. See sections 3.3 and 3.4 in the LFAP data specification [2] for the AR and ARA messages concerning the RETURN_TIME command. 3.3.6. Requirements Section 5.6 Flow Expiration Compliance = P LFAP provides a way to close a flow via a state field. The state field can be extended to indicate why the flow was close (e.g. timeout, FIN/RST TCP bits). However, LFAP does not clearly define the flow timeout procedure. This can be rectified in a subsequent revision. See section 2.16 of the LFAP data specification [2] concerning Flow State. 3.3.7. Requirements Section 5.7 Multicast Compliance = T LFAP can of course report the individual multicast flows. It can also report multiple output interfaces. See section 2.24 and section 3.1 of the LFAP data specification [2] for a description of multiple egress interfaces. Calato Informational [Page 17] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.3.8. Requirements Section 5.8 Ignore Port Copy Compliance = F LFAP does not support reporting flows resulting from a port copy. Thus there is no way to distinguish them from normal flows. 3.3.9. Requirements Section 6.1 Information Model 1. IP version number Compliance = T* * - The address IE contains an address family field which will indicate IP V4 or IP V6. If address family is not sufficient then IP version number will need a new IE element. 2. source IP address Compliance = T LFAP also supports reporting the address mask. 3. destination IP address Compliance = T LFAP also supports reporting the address mask. 4. IP protocol type (TCP,UDP,ICMP,...) Compliance = T 5. source TCP/UDP port number Compliance = T 6. destination TCP/UDP port number Compliance = T 7. input interface (ifIndex) Compliance = T Calato Informational [Page 18] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 8. output interface (ifIndex) ) Compliance = T 9. packet counter Compliance = T 10. byte counter Compliance = T* * - The LFAP counter definition could be better expressed in the specification. 11. in case of IPv4: Type of Service Compliance = T 12. in case of IPv6: Flow Label Compliance = T 13. if BGP is supported at the observation point: BGP AS number Compliance = T 14. if MPLS is supported at the observation point: MPLS label Compliance = T 15. if DiffServ is supported at the observation point: DSCP Compliance = T 16. timestamp of the first packet of the flow Compliance = T* * - The LFAP specification indicates the start time is when the flow was created. This generally coincides with the first packet, but the specification does not mandate it. 17. timestamp of the last packet of the flow Compliance = T* Calato Informational [Page 19] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 The end time is when the statistics were gathered. This generally coincides with the flow being timed out or the last packet. But the specification does not mandate it. 18. if sampling is used: sampling configuration Compliance = F If the choice was to configure this via the protocol, LFAP could be extended by allowing the sampling configuration to be provided in the AR/ARA message pair or the in LFAP MIB. 19. unique identifier of the observation point Compliance = T* * - The identifier is an IP address. If the observation point is not IP addressable, a different mechanism would be needed. The issue here is how to obtain a unique ID that can also be traced back to a specific IPFIX observation point. 20. unique identifier of the exporting process Compliance = F This would require just the definition of one additional information element. 21. multicast replication factor Compliance = F This would require just the definition of one additional information element. 22. Time To Live Compliance = F This would require just the definition of one additional information element. 23. IP header flags Compliance = F This would require just the definition of one additional Calato Informational [Page 20] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 information element. 24. TCP header flags Compliance = T 25. dropped packet counter at the observation point Compliance = F This would require just the definition of one additional information element. 26. fragmented packet counter Compliance = F This would require just the definition of one additional information element. 3.3.10. Templated Data If templated data passing is needed, LFAP defines a multi- record IE where the record format is given once in the message and then just values are listed for each flow reported. This provides a good amount of data reduction. If further reduction is mandated via a session wide template, additional work would need to be done in LFAP. However, this extra level of reduction, in my view, is only an incremental reduction. The amount of data reduction from a coarser grained flow definition would dwarf any reduction from sending type information per session instead of per message. Thus if bandwidth is an issue, a coarser flow definition is the likely solution. 3.3.11. Requirements Section 6.2 Data Model Compliance = T & F Since LFAP uses a TLV format, unknown IE's are simply skipped over. Thus new attributes can be added without affecting existing Collectors. LFAP also allows, via the protocol, the configuration of the set of data elements to be exported. In some cases LFAP depends on messages coming in order. For example, if cumulative byte counts are used (as opposed to delta byte counts which is also available), out of sequence Calato Informational [Page 21] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 update messages would cause a problem. At the moment TCP is used to solve this problem. If an unreliable transport is needed, LFAP would need to be extended with a message sequence number to ensure ordering at the application layer. There already exists a message ID but it is only a 16 bit value which may not be large enough. The other option is to remove the alternative features that have ordering issues. 3.3.12. Requirements Section 6.3.1 Congestion Awareness Compliance = T LFAP uses TCP. If an unreliable congestion aware protocol is used instead, LFAP would need a larger message ID field (32 bits instead of 16) to solve any ordering issues. 3.3.13. Requirements Section 6.3.2 Reliability Compliance = T LFAP uses TCP which is a reliable transport. LFAP also defines statistics for tracking reliability parameters. Application level reliability is not supported. However, there is enough information in the LFAP messages to provide such support. For example, the FLOW_ID, TIMESTAMP, MESSAGE_ID 3-tuple uniquely identifies all messages. Thus duplicates may be weeded out. However, sending duplicate data records has design and implementation issues associated with it. The design issue is developing a procedure where duplicate records are always eliminated. It seems there exist failure combinations that poke holes in any design. Whether or not those holes are acceptable is an issue for the market place. Furthermore, high volume situations cause practical implementation problems in searching for duplicate records. 3.3.14. Requirements Section 6.3.3 Security See section 4 Security in this document. 3.3.15. Requirements Section 6.4 Regular Reporting Compliance = T LFAP's message structure is ideally suited for regular reporting. Update information may be sent without repeating characteristics. Update intervals can also vary for different flows. Calato Informational [Page 22] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.3.16. Requirements Section 6.5 Notification on Specific Events Compliance = P & F The 2 events mentioned are handled by the FAR/FUN messages. The MIB also defined several events. If other events are needed, the AR/ARA messages could be extended or additional MIB events can be provided. 3.3.17. Requirements Section 6.6 Anonymization Compliance = F If all data is anonymzed an AR/ARA exchange or MIB changes could provide the indication. If it is per message, there is room in the message header to provide the indication. If field level is needed, there is room in the IE type for this indication. However, further review needs to be done as there may be other ways to accomplish this at the field level. 3.3.18. Requirements Section 7.1 Configuration of the Metering 1. Specification of the observation point 2. Specifications of flows to be metered 3. Flow timeouts 4. Sampling method and parameters, if feature is supported 5. Overload behavior Compliance = F LFAP does not define these configuration parameters. LFAP can be extended to provide configuration information via the MIB or AR/ARA exchange. How far we go in the configuration area is another matter. 3.3.19. Requirements Section 7.2 Configuration of the Exporting 1. reporting data format Compliance = T 2. the collecting process(es) to which flows are reported Compliance = T The LFAP MIB allows this to be configured. 3. notifications to be sent to the collecting process(es) Calato Informational [Page 23] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Compliance = P The LFAP MIB defines traps which may be sent. 4. flow anonymization Compliance = F This configuration be can handled via the LFAP MIB or the AR/ARA exchange. 3.3.20. Requirements Section 8.1 Openness Compliance = T* The LFAP Information Model and Data Model were designed for easy extension and flexibility. Configuration extension is possible through MIB and AR/ARA message exchange. 3.3.21. Requirements Section 8.2 Scalability Concerning the Number of Exporting Processes Compliance = T* LFAP places no limits on the number of Exporting Processes. LFAP distinguishes Exporting Processes by address. * - If distinguishing by address is deemed insufficient, an additional Information Element will need to be defined. 3.3.22. Requirements Section 8.3 Several Collecting Processes Compliance = F LFAP would need to define this procedure and add the necessary elements to the MIB module for configuration. 4. Security Considerations Security considerations for the IPFIX protocol are covered by the comparison against the specific Security requirements in the IPFIX requirements document [IPFIX-REQ] where they are specifically addressed by sections 6.3.3 and 10. 4.1 Requirements Section 6.3.3 Security Compliance = T Calato Informational [Page 24] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 LFAP specifies security mechanisms to achieve the elements listed below. The security mechanisms can be external to the protocol (e.g. provided by the transport layer) or via the LFAP protocol itself. A combination may be also be used. LFAP provides mechanisms in the protocol to allow for lightweight simple mechanisms when needed. It also paves the way for field level security, which may reduce the CPU cycles needed to implement security features. Confidentiality If LFAP is used a bit in the message header indicates the message is encrypted. The encryption mechanisms are well defined. Integrity If LFAP is used a bit in the message header indicates the message is authenticated. The authentication procedure covers Integrity. If only Integrity is desired, simply defining one additional bit is all that is necessary. Authenticity If LFAP is used a bit in the message header indicates the message is authenticated. Authentication procedures are well defined. Push Compliance = T Pull Compliance = F LFAP does not support pull mode. Additional work would need to support this mode. 4.2 Requirements Section 10.1 Disclosure of Flow Information Data Compliance = T LFAP defines encryption procedures. 4.3 Requirements Section 10.2 Forgery of Flow Records Compliance = T LFAP defines Authentication and Integrity procedures. Calato Informational [Page 25] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 4.4 Requirements Section 10.3 Denial of Service (DoS) Attacks Compliance = T The LFAP specification describes procedures to mitigate DoS attacks on the IPFIX device and the Collecting device. For example, see the following paragraph in section 5.2 _Version Request Acknowledge (VRA) Message_ of the LFAP specification [1]. _The CCE MUST NOT request a version higher than the one returned in the VRA otherwise the FAS MUST disconnect the TCP session and the counter Session Establishment Errors will be incremented._ This is intended to keep the FAS (Collecting Process) from being bombarded with VR requests as a DoS Attack against the FAS. Calato Informational [Page 26] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 5. References [1] "Light-weight Flow Accounting Protocol Specification Version 5.0" draft-riverstone-lfap-01.txt, June 2002 [2] "LFAP Data Definition Specification", draft-riverstone-lfap-data-01.txt. June 2002 [3] _Cabletron's Light-weight Flow Admission Protocol Specification version 1.0_. Informational RFC 2124 March 1997 [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, work in progress, August 2002. 6. Author's Address Paul Calato Riverstone Networks 5200 Great America Pkwy. Santa Clara, CA 95054 7. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 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. Calato Informational [Page 27] --------------8C586C0A5E3873FA3D088F71-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 2 11:33:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24774 for ; Mon, 2 Sep 2002 11:33:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17lswx-0007AD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Sep 2002 10:17:11 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17lswv-00079N-00 for ipfix-eval@net.doit.wisc.edu; Mon, 02 Sep 2002 10:17:09 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g82FGb708229; Mon, 2 Sep 2002 17:16:37 +0200 (CEST) Message-ID: <3D7380D5.7010809@cisco.com> Date: Mon, 02 Sep 2002 17:16:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bclaise@cisco.com CC: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] draft-claise-ipfix-eval-netflow-00.txt References: <22725026.1030721831@[192.168.102.164]> <3D71CFD6.3080303@cup.hp.com> Content-Type: multipart/mixed; boundary="------------090400070700030005080100" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090400070700030005080100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Please find attached draft-claise-ipfix-eval-netflow-00.txt. Note that I will continue to update this draft over the next days and produce the version 01. A few sections from the verison 00 contains the sentence "to be written". Regards, Benoit. --------------090400070700030005080100 Content-Type: text/plain; name="draft-claise-ipfix-eval-netflow-00.txt" Content-Disposition: inline; filename="draft-claise-ipfix-eval-netflow-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id g82FGb708229 Content-Transfer-Encoding: quoted-printable =20 Internet Draft B. Claise=20 Document: draft-claise-ipfix-eval-netflow-00.txt Cisco Systems=20 Expires: Mars 2003 September 2002=20 =20 =20 Evaluation Of NetFlow Version 9 Against IPFIX Requirements=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are=20 working documents of the Internet Engineering Task Force (IETF), its=20 areas, and its working groups. Note that other groups may also=20 distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 =20 Distribution of this document is unlimited.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved.=20 =20 =20 Abstract=20 =20 This document provides an evaluation of the applicability of the NetFl= ow=20 flow record export protocol version 9 as an IPFIX protocol. It compare= s=20 the properties and capabilities of the NetFlow flow record export prot= ocol=20 version 9 to the IPFIX requirements [IPFIX-REQ].=20 This document is the first version of the draft and should not be=20 considered as finished work. Updated version(s) will soon follow with=20 =20 =20 Claise Expires =96 February 2003 [Page 1]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 changes introduced by the publication of the new requirement draft ver= sion=20 6 [IPFIX-REQ6], and with the English syntax and grammar corrections. =20 =20 =20 =20 Table of Contents=20 =20 1. Introduction...................................................3=20 2. Architectural Considerations...................................5=20 2.1 NetFlow Protocol Overview..................................6=20 2.2 General Applicability......................................6=20 2.2.1 Flow Definition......................................6=20 2.2.2 Observation Point....................................7=20 2.2.3 The Metering Process and the Flow Record.............7=20 2.2.4 The Exporting Process................................7=20 2.2.5 The Collecting Process...............................7=20 2.3 Architectural Differences..................................8=20 3. Item Level Compliance Evaluation...............................9=20 3.1 Terminology (section 2)....................................9=20 3.1.1 IP Traffic Flow (2.1)................................9=20 3.1.2 Observation Point (2.2)..............................9=20 3.1.3 Metering Process (2.3)..............................10=20 3.1.4 Flow Record (2.4)...................................10=20 3.1.5 Exporting Process (2.5).............................10=20 3.1.6 Collecting Process (2.6)............................10=20 3.2 Applications Requiring IP Flow Information Export (3).....10=20 3.3 Distinguishing Flows (4)..................................11=20 3.3.1 Interface (4.1).....................................11=20 3.3.2 IP Header Fields (4.2)..............................11=20 3.3.3 Transport Header Fields (4.3).......................11=20 3.3.4 MPLS (4.4)..........................................11=20 3.3.5 DiffServ Code Point (4.5)...........................11=20 3.3.6 Header Compression and Encryption (4.6).............11=20 3.4 Metering Process (5)......................................11=20 3.4.1 Reliability (5.1)...................................12=20 3.4.2 Sampling (5.2)......................................12=20 3.4.3 Overload Behavior (5.3).............................12=20 3.4.4 Timestamps (5.4)....................................13=20 3.4.5 Time Synchronization (5.5)..........................13=20 3.4.6 Flow Expiration (5.6)...............................13=20 3.4.7 Multicast (5.7).....................................14=20 3.4.8 Ignore Port Copy (5.8)..............................14=20 3.5 Data Export (6)...........................................14=20 3.5.1 Information Model (6.1).............................14=20 3.5.2 Data Model (6.2)....................................15=20 3.5.3 Data Transfer (6.3).................................15=20 3.5.3.1 Congestion Awareness (6.3.1)....................15=20 3.5.3.2 Reliability (6.3.2).............................15=20 =20 =20 Claise Expires =96 Mars 2003 [Page 2]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.5.3.3 Security (6.3.3)................................15=20 3.5.4 Regular Reporting Interval (6.4)....................16=20 3.5.5 Notification on Specific Events (6.5)...............16=20 3.5.6 Anonymization (6.6).................................16=20 3.6 Configuration (7).........................................16=20 3.6.1 Configuration of the Metering Process (7.1).........16=20 3.6.2 Configuration of the Exporting Process (7.2)........16=20 3.7 General Requirements Compliance (8).......................16=20 3.7.1 Openness (8.1)......................................16=20 3.7.2 Scalability Concerning the Number of Exporting Processes=20 (8.2) 16=20 3.7.3 Several Collecting Processes (8.3)..................17=20 4. Security Considerations.......................................17=20 5. References....................................................17=20 6. Author's Address..............................................18=20 7. Full Copyright Statement......................................18=20 =20 =20 1. Introduction=20 =20 This document provides an evaluation of the applicability of the NetFl= ow=20 flow record export protocol version 9 as an IPFIX protocol. First, the= =20 general NetFlow architecture is introduced and its application to the=20 communication between an IPFIX exporting process and an IPFIX collecti= ng=20 process is discussed in Section 2. Section 3 discusses in detail, to w= hich=20 degree requirements stated in [IPFIX-REQ] are met.=20 =20 This document uses the terminology defined in [IPFIX-REQ].=20 =20 Note that the generic term NetFlow refers to multiple different notion= s:=20 the metering process, the exporting process and the export protocol, a= s=20 defined in the IPFIX terminology section of [IPFIX-REQ].=20 Even if the metering process and exporting process form a single NetFl= ow=20 process on the Cisco Systems devices, this document will sometimes ref= er=20 to NetFlow metering process and NetFlow exporting process for the sake= of=20 clarity. But the export protocol will always be referred to as the Net= Flow=20 flow record export protocol version 9. =20 =20 - How and where is it documented?=20 =20 All documentation related to NetFlow can be found at:=20 http://www.cisco.com/go/netflow=20 =20 More specifically, the =93NetFlow Services Solutions Guide=94 covers a= NetFlow=20 overview, the basic and advanced concepts, the explanation of the=20 =20 =20 Claise Expires =96 Mars 2003 [Page 3]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 different versions along with the data types exported, some configurat= ion=20 examples, etc. For reference, see:=20 http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfw= hite .htm=20 =20 The new flexible and extensible NetFlow flow record export version 9 i= s=20 described in the IETF draft "Cisco Systems NetFlow Services Export Ver= sion=20 9" [NETFLOW9], as well as in the following document:=20 http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ntfo_wp.htm=20 =20 - Are there concrete plans for standardizing it?=20 =20 The way to standardize NetFlow is via the IETF IPFIX Working Group.=20 In parallel, Cisco Systems intention is to produce an Information RFC = out=20 of [NETFLOW9]. =20 =20 - Is standardization already in progress?=20 =20 No other standardization than the participation to the IETF IPFIX Work= ing=20 Group is currently taking place.=20 =20 - Is it proprietary to a certain company?=20 =20 NetFlow is a proprietary protocol from Cisco Systems.=20 =20 - Does it include any technology protected by patents?=20 =20 NetFlow is protected by the following patent:=20 United States Patent 6,243,667 Kerr, et al. June 5, 2001=20 =20 Abstract:=20 The invention provides a method and system for switching in networks=20 responsive to message flow patterns. A message "flow" is defined to=20 comprise a set of packets to be transmitted between a particular sourc= e=20 and a particular destination. When routers in a network identify a new= =20 message flow, they determine the proper processing for packets in that= =20 message flow and cache that information for that message flow. Thereaf= ter,=20 when routers in a network identify a packet which is part of that mess= age=20 flow, they process that packet according to the proper processing for=20 packets in that message flow. The proper processing may include a=20 determination of a destination port for routing those packets and a=20 determination of whether access control permits routing those packets = to=20 their indicated destination.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 4]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 Nevertheless, Cisco Systems has no intention to use this patent to pre= vent=20 other vendors to implement a NetFlow-like solution.=20 =20 An Intellectual Property Right message has been sent to the IETF rfc- editor team to post a similar message at http://www.ietf.org/ipr.html=20 =20 - Is it already implemented?=20 =20 The NetFlow flow record export protocol version 9 protocol is currentl= y at=20 the stage of the Early Field Test, while NetFlow flow record export=20 versions 1, 5, 7 and 8 have been implemented for years now.=20 =20 - Is it already in commercial use?=20 =20 Some Cisco Systems partners are currently developing NetFlow Collector= s=20 (the correct term is =93collecting process=94 according to [IPFIX-REQ]= ) able=20 to receive NetFlow version 9 flow records.=20 While many different companies or organizations have already implement= ed=20 NetFlow Collectors for the previous NetFlow flow record export protoco= ls=20 versions. Ex: Concord Communications, Hewlett Packard, Narus, Xacct,=20 Portal, Apogee Networks, Infovista, etc. to name just a few.=20 =20 - Is it available from more than one source?=20 =20 As the inventor of NetFlow, Cisco Systems is the only company implemen= ting=20 this new version 9 on its devices. But, if we speak of the previous=20 NetFlow flow record export protocol versions, then the majority of our= =20 competitors implemented those versions. =20 =20 - Is it already widely used?=20 =20 The new NetFlow flow record export protocol version 9 is in Early Fiel= d=20 Test right now, while the previous NetFlow flow record export versions= =20 have been implemented by our competitors. As a consequence, NetFlow is= =20 widely used through out the industry.=20 =20 =20 2. Architectural Considerations=20 =20 This section introduces the architecture of the NetFlow and suggests a= way=20 of applying it to the communication between an IPFIX exporting process= and=20 an IPFIX collecting process.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 5]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 =20 2.1 NetFlow Protocol Overview=20 =20 This section discusses the most recent evolution of the NetFlow flow=20 record export protocol, which is known as Version 9. The distinguishin= g=20 feature of the NetFlow Version 9 format compared to the previous versi= ons,=20 is that it is template based. Template is a collection of fields along= =20 with the description of their structure and semantics. =20 =20 This approach gives the following advantages:=20 =20 - The template mechanism being flexible, allows the export of the =20 required fields alone from the IP Flows to the collecting process. = =20 This helps to reduce the exported flow data volume, and possible =20 memory savings at the metering process and collecting process.=20 Sending the required information only, reduces the network load too. = =20 =20 - Using the template mechanism, new fields can be added to NetFlow =20 export records without changing the structure of export record =20 format. With the previous NetFlow flow record export versions, =20 adding a new field in the flow record implied a new version of the =20 export protocol format and a new version of the collecting process =20 that supports the parsing of this new export protocol format. =20 =20 - Templates which are sent to the collecting process contains the =20 structural information about the exported Flow Records fields. So, =20 even if the collecting process does not understand the semantics of =20 new fields, it can still interpret the Flow Record. =20 =20 - Even if the NetFlow flow record export protocol version 9 has been=20 created with a IP flow record background in mind, note that=20 Information Model can be extended with any data types and could=20 potentially serve any reporting purposes. E.g. the NetFlow metering=20 process configuration.=20 =20 =20 2.2 General Applicability=20 =20 2.2.1 Flow Definition=20 A NetFlow flow is identified as a unidirectional stream of packets bet= ween=20 a given source and destination=97both defined by a network-layer IP ad= dress=20 =20 =20 Claise Expires =96 Mars 2003 [Page 6]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 and transport-layer source and destination port numbers. Typically in = case=20 of ingress NetFlow, a flow is identified as the combination of the=20 following seven key fields: source IP address, destination IP address,= =20 source port number, destination port number, layer 3 protocol type, To= S=20 byte, input logical interface (ifIndex). In case of egress NetFlow, a = flow=20 is identified as the combination of the following seven key fields: so= urce=20 IP address, destination IP address, source port number, destination po= rt=20 number, layer 3 protocol type, ToS byte, output logical interface=20 (ifIndex).=20 These seven key fields define a unique flow. If a new observed packet=20 contains a different set of these seven key fields, then this packet w= ill=20 create a new flow. Note that a flow contains other accounting fields (= such=20 as the number of packets, number of bytes, the BGP AS, etc).=20 2.2.2 Observation Point=20 NetFlow is enabled in most case per interface (per port), sometimes pe= r=20 subinterface. On specific device, NetFlow is enabled for the entire=20 platform.=20 2.2.3 The Metering Process and the Flow Record=20 NetFlow operates by creating a NetFlow cache that contains the informa= tion=20 for all active flows. A flow record is maintained within the NetFlow c= ache=20 for all active flows. Each flow record in the NetFlow cache contains k= ey=20 fields that can be later used for exporting to a collecting process.=20 2.2.4 The Exporting Process=20 The NetFlow enabled platform checks the NetFlow cache once per second = and=20 expires the flow if no more traffic of that flow is observed. Once=20 expired, the flow records are directly exported to the collecting proc= ess.=20 To achieve efficiency in terms of processing at the Exporter while=20 handling high volume of export, the NetFlow export packet is encapsula= ted=20 into UDP [UDP] datagrams for export to the collecting process.=20 Nevertheless NetFlow flow record export protocol version 9 has been=20 designed to be transport protocol independent. Hence, it can also oper= ate=20 over congestion aware protocols like TCP [TCP] or SCTP [SCTP]. =20 =20 2.2.5 The Collecting Process=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 7]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 NetFlow Collector (the collecting process) provides the data=20 collection from multiple export devices exporting NetFlow flow=20 records. It will process and store the flow records. Some extra=20 actions on these flow records could be executed on the collecting=20 process but per [IPFIX-REQ], these actions are out of the scope of=20 the IPFIX work.=20 =20 =20 =20 2.3 Architectural Differences=20 =20 +----------------+ +----------------+=20 |[*Application 1]| ..|[*Application n]|=20 +--------+-------+ +-------+--------+=20 ^ ^=20 ~ ~=20 +~~~~~~~~~~+~~~~~~~~+=20 !=20 v=20 +----------------------+ +------------------+=20 |Device(i) | | Collector(j) |=20 |[Obsv Point(s)] |--------------->| [*Application(s)]|=20 |[Metering Process(es)]| +---->| |=20 |[Export Process] | | +------------------+=20 +----------------------+ .=20 .... . =20 +----------------------+ |=20 |Device(m) | | =20 |[Obsv Point(s)] |----------+=20 |[Metering Process(es)]| =20 |[Export Process] |=20 +----------------------+=20 =20 Except the terminology difference again described below, there is no=20 difference between the NetFlow and IPFIX architecture.=20 Note that the generic term NetFlow refers to multiple different notion= s:=20 the metering process, the exporting process and the export protocol, a= s=20 defined in the IPFIX terminology section of [IPFIX-REQ].=20 Even if the metering process and exporting process form a single NetFl= ow=20 process on the Cisco Systems devices, this document will sometimes ref= er=20 to NetFlow metering process and NetFlow exporting process for the sake= of=20 clarity. But the export protocol will always be referred to as the Net= Flow=20 flow record export protocol version 9. =20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 8]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3. Item Level Compliance Evaluation=20 =20 This section evaluates the compliance of the NetFlow protocol with the= =20 IPFIX requirements item by item. Requirements are addressed by their=20 section numbers and item numbers in [IPFIX-REQ]. For each requirement=20 it is explained to what degree protocol NetFlow flow export version 9=20 meets the requirement and how this is achieved. The degree of complian= cy=20 is explicitly stated using five grades:=20 =20 -T Total compliance: The requirement is met completely by the=20 protocol specification without any extensions required.=20 =20 -E Extension required for total compliance: The protocol is=20 prepared to be extended and it is possible to extend it in a=20 way that it meets the requirement. This grade is only=20 applicable to protocols that are explicitly open to externally=20 defined extensions, such as SNMP is extended by MIB modules or=20 DIAMETER is extended by application modules. It is not=20 applicable to protocols, where the protocol specification itself= =20 needs to be extended in order to comply with the requirement.=20 =20 -P Partial compliance: The requirement is met partially by the=20 protocol specification.=20 =20 -U Upcoming compliance: The requirement is not met or met=20 partially by the protocol specification, but there is a=20 concrete plan for an upcoming version of the protocol.=20 =20 -F Failed compliance: The requirement is not met by the protocol=20 specification.=20 =20 =20 3.1 Terminology (section 2)=20 =20 3.1.1 IP Traffic Flow (2.1)=20 =20 Total compliance of NetFlow Flow definition with the IPFIX IP=20 Traffic Flow definition.=20 =20 3.1.2 Observation Point (2.2)=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 9]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 Total compliance of NetFlow Observation Point definition with the=20 IPFIX Observation Point definition. NetFlow is enabled by interface=20 or per subinterface. NetFlow can be enable on multiple interfaces=20 at the same time, e.g. all interfaces belonging to one line card, or=20 all the interfaces from the device. On specific device, NetFlow is=20 enabled for the entire platform.=20 =20 3.1.3 Metering Process (2.3)=20 =20 Total compliance of NetFlow with the IPFIX Metering Process=20 definition, for all aspects: packet header capturing, timestamping,=20 sampling, classifying, and maintaining flow records.=20 =20 3.1.4 Flow Record (2.4)=20 =20 Total compliance of NetFlow Flow Record definition with the IPFIX=20 Flow Record definition.=20 =20 3.1.5 Exporting Process (2.5)=20 =20 Total compliance of NetFlow Exporting Process with the IPFIX=20 Exporting Process definition. The NetFlow Exporting Process may send=20 the flow records to 2 different collecting processes.=20 =20 3.1.6 Collecting Process (2.6)=20 =20 Total compliance of NetFlow Collector with the IPFIX collecting=20 process definition. =20 =20 =20 3.2 Applications Requiring IP Flow Information Export (3)=20 =20 Total compliance of NetFlow regarding the different applications=20 described in [IPFIX-REQ] which require IP flow information export,=20 i.e. Usage-based Accounting, Traffic Profiling, Traffic Engineering,=20 Attack/Intrusion Detection and QoS Monitoring. Actually, the=20 Information Model associated with NetFlow flow record export version=20 9 [NETFLOW9] contains all the data types needed to satisfy the=20 requirements of the different applications described in this=20 section.=20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 10]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.3 Distinguishing Flows (4)=20 =20 3.3.1 Interface (4.1)=20 =20 Total Compliance of the interface as a flow distinguisher.=20 In case of ingress NetFlow, a flow is identified, amongst other=20 fields, by the input logical interface (ifIndex). In case of egress=20 NetFlow, a flow is identified, amongst other fields by output=20 logical interface (ifIndex).=20 =20 3.3.2 IP Header Fields (4.2)=20 =20 source IP address (MUST): Total Compliance=20 destination IP address (MUST): Total Compliance=20 protocol type (TCP,UDP,ICMP,...) (MUST): Total Compliance=20 IP version number (SHOULD): Upcoming Compliance=20 =20 3.3.3 Transport Header Fields (4.3)=20 =20 Total Compliance of the port numbers of the transport header as a=20 flow distinguisher.=20 =20 3.3.4 MPLS (4.4)=20 =20 Total Compliance of the MPLS label a flow distinguisher, if the=20 observation point is located at a device supporting Multiprotocol=20 Label Switching.=20 =20 3.3.5 DiffServ Code Point (4.5)=20 =20 Partial Compliance, as NetFlow distinguish flow by the TOS field.=20 =20 3.3.6 Header Compression and Encryption (4.6)=20 =20 Total Compliance.=20 =20 =20 3.4 Metering Process (5) =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 11]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.4.1 Reliability (5.1)=20 =20 To be written.=20 =20 3.4.2 Sampling (5.2)=20 =20 =93The metering process MAY support packet sampling.=94, as defined in= =20 [IPFIX-REQ]=93. Total Compliance. NetFlow supports packet sampling.=20 =20 =93If sampling is supported the sampling configuration MUST be well=20 defined. The sampling configuration includes the sampling method and=20 all its parameters.=94, as defined in [IPFIX-REQ]. Total compliance. =20 See the Options Template from [NETFLOW9]: a template that describes=20 the format of the Flow measurement parameters (like the sampling=20 algorithm, sampling interval) done at the metering process.=20 =20 =93If the sampling configuration is changed during operation, the new=20 sampling configuration with its parameters MUST be indicated to all=20 collecting processes receiving the affected flow records. Changing=20 the sampling configuration includes: start sampling, stop sampling,=20 change sampling method, and change sampling parameter.=93, as defined=20 in [IPFIX-REQ]=93. Partial Compliance. NetFlow supports the =93change=20 sampling method=94 and =93change sampling parameter=94 options.=20 =20 3.4.3 Overload Behavior (5.3)=20 =20 =93In case of an overload, for example lack of memory or processing=20 power, the metering process MAY change its behavior in order to cope=20 with the lack of resources.=94, as defined in [IPFIX-REQ]. =20 Total Compliance. =20 =20 =93But in case the overload behavior has an impact on the metering=20 process or the exporting process, the overload behavior MUST be=20 clearly defined and the collecting process MUST be able to=20 distinguish the flow records exported before and after the metering=20 process behavior change:=94, as defined in [IPFIX-REQ].=20 If the metering process configuration is changed, then Total=20 Compliance. =20 But failed compliance in the following situation: in case the=20 NetFlow cache becomes full, the flow records will be expired with a=20 smaller timeout! In this specific case, this requirement doesn=92t=20 make sense.=20 =20 =93In case of any change of the meter's behavior, all flow records=20 metered by the previous behavior MUST be terminated and exported=20 =20 =20 Claise Expires =96 Mars 2003 [Page 12]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 according to the configuration of the exporting process.=94, as=20 defined in [IPFIX-REQ].=20 Total Compliance.=20 =20 =93The metering process MUST not merge the flow records generated with= =20 the new behavior with the flow records generated with the previous=20 behavior.=94, as defined in [IPFIX-REQ].=20 If the metering process configuration is changed, then Total=20 Compliance because a new Template ID for the new configuration will=20 be generated.=20 But failed compliance in the following situation: in case the=20 NetFlow cache becomes full, the flow records will be expired with a=20 smaller timeout! In this specific case, this requirement doesn=92t=20 make sense.=20 =20 3.4.4 Timestamps (5.4)=20 =20 Total Compliance.=20 =20 3.4.5 Time Synchronization (5.5)=20 =20 The compliance is not relevant as the mechanism used for time=20 synchronization is outside the scope of the IPFIX. =20 =20 3.4.6 Flow Expiration (5.6)=20 =20 Total Compliance of the NetFlow flow expiration mechanism with the=20 IPFIX requirements.=20 The routing device checks the NetFlow cache once per second and expire= s=20 the flow in the following instances:=20 1. Transport is completed (TCP FIN or RST). =20 2. The flow cache has become full. =20 3. The inactive timer has expired after 15 seconds of traffic=20 inactivity. This inactive timer is configurable. =20 4. The active timer has expired after 30 minutes of traffic activi= ty.=20 This active timer is configurable.=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 13]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.4.7 Multicast (5.7)=20 =20 Total Compliance of the multicast support with the IPFIX=20 requirements.=20 =20 3.4.8 Ignore Port Copy (5.8)=20 =20 To be written.=20 =20 =20 3.5 Data Export (6) =20 =20 3.5.1 Information Model (6.1)=20 =20 =93The exporting process MUST be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 1. IP version number: Upcoming Compliance (NetFlow will support=20 IPV6)=20 2. source IP address: Total Compliance=20 3. destination IP address: Total Compliance=20 4. IP protocol type (TCP,UDP,ICMP,...) : Total Compliance=20 5. source TCP/UDP port number: Total Compliance=20 6. destination TCP/UDP port number: Total Compliance=20 7. input interface (ifIndex): Total Compliance=20 8. output interface (ifIndex): Total Compliance=20 9. packet counter: Total Compliance=20 10. byte counter: Total Compliance=20 11. in case of IPv4, Type of Service: Total Compliance=20 12. in case of IPv6, Flow Label: Upcoming Compliance=20 13. if BGP is supported at the observation point, BGP AS number:=20 Total Compliance=20 14. if MPLS is supported at the observation point, MPLS label:=20 Total Compliance=20 15. if DiffServ is supported at the observation point, DSCP:=20 Partial Compliance=20 16. timestamp of the first packet of the flow: Total Compliance=20 17. timestamp of the last packet of the flow: Total Compliance=20 18. if sampling is used, sampling configuration: Total Compliance=20 19. unique identifier of the observation point: Total Compliance=20 (the ifIndex)=20 20. unique identifier of the exporting process: Total Compliance=20 (the IP address)=20 =20 =93The exporting process SHOULD be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 =20 =20 Claise Expires =96 Mars 2003 [Page 14]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 21. multicast replication factor. Total Compliance=20 =20 =93The exporting process MAY be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 22. Time To Live: Extension required for total compliance=20 23. IP header flags: Extension required for total compliance=20 24. TCP header flags: Total Compliance=20 25. dropped packet counter at the observation point: Extension=20 required for total compliance=20 26. fragmented packet counter: Extension required for total=20 compliance=20 =20 3.5.2 Data Model (6.2)=20 =20 =93The data model MUST be extensible=94, as defined in [IPFIX-REQ].=20 Total compliance.=20 =20 =93The data model used for exporting flow information MUST be flexible= =20 concerning the flow attributes contained in flow records=94, as=20 defined in [IPFIX-REQ].=20 Total compliance.=20 =20 =93The Data Model SHOULD be independent of the underlying transport=20 protocol, i.e. the data transfer=94, as defined in [IPFIX-REQ].=20 Total compliance.=20 =20 3.5.3 Data Transfer (6.3)=20 3.5.3.1 Congestion Awareness (6.3.1)=20 =20 =93For the data transfer, a congestion aware protocol MUST be=20 supported=94, as defined in [IPFIX-REQ].=20 To be written.=20 =20 3.5.3.2 Reliability (6.3.2)=20 =20 Total Compliance. A sequence ID exists per export packet so that the=20 collecting process would know if it misses export packets or if=20 packets reordering occurred in the network.=20 =20 3.5.3.3 Security (6.3.3)=20 =20 Failed compliance for confidentiality, integrity and authenticity.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 15]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 3.5.4 Regular Reporting Interval (6.4)=20 =20 Total compliance. For long aging flows, the exporting process=20 exports the flow records on regular basis, in order to:=20 1. report the flow records periodic accounting information=20 to the collecting process=20 2. avoid counter wrapping=20 This activity timeout is configurable=20 =20 3.5.5 Notification on Specific Events (6.5)=20 =20 Failed compliance. =20 =20 3.5.6 Anonymization (6.6)=20 =20 To be written.=20 =20 =20 3.6 Configuration (7)=20 =20 3.6.1 Configuration of the Metering Process (7.1)=20 =20 Total Compliance.=20 =20 3.6.2 Configuration of the Exporting Process (7.2)=20 =20 Total Compliance.=20 =20 =20 3.7 General Requirements Compliance (8)=20 =20 3.7.1 Openness (8.1)=20 =20 Total Compliance.=20 =20 3.7.2 Scalability Concerning the Number of Exporting Processes (8.2)=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 16]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =93Data collection from hundreds of different exporting processes MUST= =20 be supported.=94, as defined in [IPFIX-REQ].=20 Total Compliance.=20 =20 =93The collecting process MUST be able to distinguish several hundred=20 exporting processes by their identifiers.=94, as defined in [IPFIX- REQ].=20 Total Compliance, the identifier being the IP address of the=20 exporting process.=20 =20 3.7.3 Several Collecting Processes (8.3)=20 =20 Total Compliance. The exporting process is able to export flow=20 information to two different collecting process.=20 =20 =20 4. Security Considerations=20 =20 Security considerations for the IPFIX protocol are covered by the=20 comparison against the specific Security requirements in the IPFIX=20 requirements document [IPFIX-REQ] where they are specifically=20 addressed by sections 6.3.3 and 10.=20 =20 The NetFlow flow record export protocol could be run on the top of=20 IPSEC [IPSEC] to assure security.=20 =20 =20 5. References=20 =20 [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information=20 Export", draft-ietf-ipfix-reqs-05.txt, work in progress,=20 July 2002.=20 =20 [IPFIX-REQ6] J. Quittek et al., "Requirements for IP Flow Information=20 Export", draft-ietf-ipfix-reqs-06.txt, work in progress,=20 July 2002.=20 =20 [NETFLOW9] B. Claise et al., "Cisco Systems NetFlow Services Export =20 Version 9", draft-bclaise-netflow-9-00.txt, work in progre= ss,=20 June 2002.=20 =20 [UDP] J. Postel, "User Datagram Protocol", RFC 768, August =20 1980=20 =20 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM =20 =20 =20 Claise Expires =96 Mars 2003 [Page 17]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 PROTOCOL SPECIFICATION", RFC 793, September 1981=20 =20 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", =20 RFC 2960, October 2000=20 =20 [IPSEC] Kent, S., "Security Architecture for the Internet =20 Protocol", RFC 2401, Nov. 1998, =20 =20 =20 6. Author's Address=20 =20 Benoit Claise=20 Cisco Systems=20 De Kleetlaan 6a b1=20 1831 Diegem=20 Belgium=20 =20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 7. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 =20 =20 Claise Expires =96 Mars 2003 [Page 18]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 19]=20 =0C --------------090400070700030005080100-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 2 11:42:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24864 for ; Mon, 2 Sep 2002 11:42:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17lt6U-0007Mf-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Sep 2002 10:27:02 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17lt6Q-0007Lb-00; Mon, 02 Sep 2002 10:26:58 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g82FPt716506; Mon, 2 Sep 2002 17:25:55 +0200 (CEST) Message-ID: <3D738303.7040002@cisco.com> Date: Mon, 02 Sep 2002 17:25:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org, ipfix-eval CC: ipfix-chairs@net.doit.wisc.edu Subject: [ipfix-eval] post draft-claise-ipfix-eval-netflow-00.txt Content-Type: multipart/mixed; boundary="------------080404050605070108000804" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080404050605070108000804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please post the attached draft-claise-ipfix-eval-netflow-00.txt as an internet draft. Thanks. Benoit. --------------080404050605070108000804 Content-Type: text/plain; name="draft-claise-ipfix-eval-netflow-00.txt" Content-Disposition: inline; filename="draft-claise-ipfix-eval-netflow-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id g82FPt716506 Content-Transfer-Encoding: quoted-printable =20 Internet Draft B. Claise=20 Document: draft-claise-ipfix-eval-netflow-00.txt Cisco Systems=20 Expires: Mars 2003 September 2002=20 =20 =20 Evaluation Of NetFlow Version 9 Against IPFIX Requirements=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are=20 working documents of the Internet Engineering Task Force (IETF), its=20 areas, and its working groups. Note that other groups may also=20 distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 =20 Distribution of this document is unlimited.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved.=20 =20 =20 Abstract=20 =20 This document provides an evaluation of the applicability of the NetFl= ow=20 flow record export protocol version 9 as an IPFIX protocol. It compare= s=20 the properties and capabilities of the NetFlow flow record export prot= ocol=20 version 9 to the IPFIX requirements [IPFIX-REQ].=20 This document is the first version of the draft and should not be=20 considered as finished work. Updated version(s) will soon follow with=20 =20 =20 Claise Expires =96 February 2003 [Page 1]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 changes introduced by the publication of the new requirement draft ver= sion=20 6 [IPFIX-REQ6], and with the English syntax and grammar corrections. =20 =20 =20 =20 Table of Contents=20 =20 1. Introduction...................................................3=20 2. Architectural Considerations...................................5=20 2.1 NetFlow Protocol Overview..................................6=20 2.2 General Applicability......................................6=20 2.2.1 Flow Definition......................................6=20 2.2.2 Observation Point....................................7=20 2.2.3 The Metering Process and the Flow Record.............7=20 2.2.4 The Exporting Process................................7=20 2.2.5 The Collecting Process...............................7=20 2.3 Architectural Differences..................................8=20 3. Item Level Compliance Evaluation...............................9=20 3.1 Terminology (section 2)....................................9=20 3.1.1 IP Traffic Flow (2.1)................................9=20 3.1.2 Observation Point (2.2)..............................9=20 3.1.3 Metering Process (2.3)..............................10=20 3.1.4 Flow Record (2.4)...................................10=20 3.1.5 Exporting Process (2.5).............................10=20 3.1.6 Collecting Process (2.6)............................10=20 3.2 Applications Requiring IP Flow Information Export (3).....10=20 3.3 Distinguishing Flows (4)..................................11=20 3.3.1 Interface (4.1).....................................11=20 3.3.2 IP Header Fields (4.2)..............................11=20 3.3.3 Transport Header Fields (4.3).......................11=20 3.3.4 MPLS (4.4)..........................................11=20 3.3.5 DiffServ Code Point (4.5)...........................11=20 3.3.6 Header Compression and Encryption (4.6).............11=20 3.4 Metering Process (5)......................................11=20 3.4.1 Reliability (5.1)...................................12=20 3.4.2 Sampling (5.2)......................................12=20 3.4.3 Overload Behavior (5.3).............................12=20 3.4.4 Timestamps (5.4)....................................13=20 3.4.5 Time Synchronization (5.5)..........................13=20 3.4.6 Flow Expiration (5.6)...............................13=20 3.4.7 Multicast (5.7).....................................14=20 3.4.8 Ignore Port Copy (5.8)..............................14=20 3.5 Data Export (6)...........................................14=20 3.5.1 Information Model (6.1).............................14=20 3.5.2 Data Model (6.2)....................................15=20 3.5.3 Data Transfer (6.3).................................15=20 3.5.3.1 Congestion Awareness (6.3.1)....................15=20 3.5.3.2 Reliability (6.3.2).............................15=20 =20 =20 Claise Expires =96 Mars 2003 [Page 2]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.5.3.3 Security (6.3.3)................................15=20 3.5.4 Regular Reporting Interval (6.4)....................16=20 3.5.5 Notification on Specific Events (6.5)...............16=20 3.5.6 Anonymization (6.6).................................16=20 3.6 Configuration (7).........................................16=20 3.6.1 Configuration of the Metering Process (7.1).........16=20 3.6.2 Configuration of the Exporting Process (7.2)........16=20 3.7 General Requirements Compliance (8).......................16=20 3.7.1 Openness (8.1)......................................16=20 3.7.2 Scalability Concerning the Number of Exporting Processes=20 (8.2) 16=20 3.7.3 Several Collecting Processes (8.3)..................17=20 4. Security Considerations.......................................17=20 5. References....................................................17=20 6. Author's Address..............................................18=20 7. Full Copyright Statement......................................18=20 =20 =20 1. Introduction=20 =20 This document provides an evaluation of the applicability of the NetFl= ow=20 flow record export protocol version 9 as an IPFIX protocol. First, the= =20 general NetFlow architecture is introduced and its application to the=20 communication between an IPFIX exporting process and an IPFIX collecti= ng=20 process is discussed in Section 2. Section 3 discusses in detail, to w= hich=20 degree requirements stated in [IPFIX-REQ] are met.=20 =20 This document uses the terminology defined in [IPFIX-REQ].=20 =20 Note that the generic term NetFlow refers to multiple different notion= s:=20 the metering process, the exporting process and the export protocol, a= s=20 defined in the IPFIX terminology section of [IPFIX-REQ].=20 Even if the metering process and exporting process form a single NetFl= ow=20 process on the Cisco Systems devices, this document will sometimes ref= er=20 to NetFlow metering process and NetFlow exporting process for the sake= of=20 clarity. But the export protocol will always be referred to as the Net= Flow=20 flow record export protocol version 9. =20 =20 - How and where is it documented?=20 =20 All documentation related to NetFlow can be found at:=20 http://www.cisco.com/go/netflow=20 =20 More specifically, the =93NetFlow Services Solutions Guide=94 covers a= NetFlow=20 overview, the basic and advanced concepts, the explanation of the=20 =20 =20 Claise Expires =96 Mars 2003 [Page 3]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 different versions along with the data types exported, some configurat= ion=20 examples, etc. For reference, see:=20 http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfw= hite .htm=20 =20 The new flexible and extensible NetFlow flow record export version 9 i= s=20 described in the IETF draft "Cisco Systems NetFlow Services Export Ver= sion=20 9" [NETFLOW9], as well as in the following document:=20 http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ntfo_wp.htm=20 =20 - Are there concrete plans for standardizing it?=20 =20 The way to standardize NetFlow is via the IETF IPFIX Working Group.=20 In parallel, Cisco Systems intention is to produce an Information RFC = out=20 of [NETFLOW9]. =20 =20 - Is standardization already in progress?=20 =20 No other standardization than the participation to the IETF IPFIX Work= ing=20 Group is currently taking place.=20 =20 - Is it proprietary to a certain company?=20 =20 NetFlow is a proprietary protocol from Cisco Systems.=20 =20 - Does it include any technology protected by patents?=20 =20 NetFlow is protected by the following patent:=20 United States Patent 6,243,667 Kerr, et al. June 5, 2001=20 =20 Abstract:=20 The invention provides a method and system for switching in networks=20 responsive to message flow patterns. A message "flow" is defined to=20 comprise a set of packets to be transmitted between a particular sourc= e=20 and a particular destination. When routers in a network identify a new= =20 message flow, they determine the proper processing for packets in that= =20 message flow and cache that information for that message flow. Thereaf= ter,=20 when routers in a network identify a packet which is part of that mess= age=20 flow, they process that packet according to the proper processing for=20 packets in that message flow. The proper processing may include a=20 determination of a destination port for routing those packets and a=20 determination of whether access control permits routing those packets = to=20 their indicated destination.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 4]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 Nevertheless, Cisco Systems has no intention to use this patent to pre= vent=20 other vendors to implement a NetFlow-like solution.=20 =20 An Intellectual Property Right message has been sent to the IETF rfc- editor team to post a similar message at http://www.ietf.org/ipr.html=20 =20 - Is it already implemented?=20 =20 The NetFlow flow record export protocol version 9 protocol is currentl= y at=20 the stage of the Early Field Test, while NetFlow flow record export=20 versions 1, 5, 7 and 8 have been implemented for years now.=20 =20 - Is it already in commercial use?=20 =20 Some Cisco Systems partners are currently developing NetFlow Collector= s=20 (the correct term is =93collecting process=94 according to [IPFIX-REQ]= ) able=20 to receive NetFlow version 9 flow records.=20 While many different companies or organizations have already implement= ed=20 NetFlow Collectors for the previous NetFlow flow record export protoco= ls=20 versions. Ex: Concord Communications, Hewlett Packard, Narus, Xacct,=20 Portal, Apogee Networks, Infovista, etc. to name just a few.=20 =20 - Is it available from more than one source?=20 =20 As the inventor of NetFlow, Cisco Systems is the only company implemen= ting=20 this new version 9 on its devices. But, if we speak of the previous=20 NetFlow flow record export protocol versions, then the majority of our= =20 competitors implemented those versions. =20 =20 - Is it already widely used?=20 =20 The new NetFlow flow record export protocol version 9 is in Early Fiel= d=20 Test right now, while the previous NetFlow flow record export versions= =20 have been implemented by our competitors. As a consequence, NetFlow is= =20 widely used through out the industry.=20 =20 =20 2. Architectural Considerations=20 =20 This section introduces the architecture of the NetFlow and suggests a= way=20 of applying it to the communication between an IPFIX exporting process= and=20 an IPFIX collecting process.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 5]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 =20 2.1 NetFlow Protocol Overview=20 =20 This section discusses the most recent evolution of the NetFlow flow=20 record export protocol, which is known as Version 9. The distinguishin= g=20 feature of the NetFlow Version 9 format compared to the previous versi= ons,=20 is that it is template based. Template is a collection of fields along= =20 with the description of their structure and semantics. =20 =20 This approach gives the following advantages:=20 =20 - The template mechanism being flexible, allows the export of the =20 required fields alone from the IP Flows to the collecting process. = =20 This helps to reduce the exported flow data volume, and possible =20 memory savings at the metering process and collecting process.=20 Sending the required information only, reduces the network load too. = =20 =20 - Using the template mechanism, new fields can be added to NetFlow =20 export records without changing the structure of export record =20 format. With the previous NetFlow flow record export versions, =20 adding a new field in the flow record implied a new version of the =20 export protocol format and a new version of the collecting process =20 that supports the parsing of this new export protocol format. =20 =20 - Templates which are sent to the collecting process contains the =20 structural information about the exported Flow Records fields. So, =20 even if the collecting process does not understand the semantics of =20 new fields, it can still interpret the Flow Record. =20 =20 - Even if the NetFlow flow record export protocol version 9 has been=20 created with a IP flow record background in mind, note that=20 Information Model can be extended with any data types and could=20 potentially serve any reporting purposes. E.g. the NetFlow metering=20 process configuration.=20 =20 =20 2.2 General Applicability=20 =20 2.2.1 Flow Definition=20 A NetFlow flow is identified as a unidirectional stream of packets bet= ween=20 a given source and destination=97both defined by a network-layer IP ad= dress=20 =20 =20 Claise Expires =96 Mars 2003 [Page 6]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 and transport-layer source and destination port numbers. Typically in = case=20 of ingress NetFlow, a flow is identified as the combination of the=20 following seven key fields: source IP address, destination IP address,= =20 source port number, destination port number, layer 3 protocol type, To= S=20 byte, input logical interface (ifIndex). In case of egress NetFlow, a = flow=20 is identified as the combination of the following seven key fields: so= urce=20 IP address, destination IP address, source port number, destination po= rt=20 number, layer 3 protocol type, ToS byte, output logical interface=20 (ifIndex).=20 These seven key fields define a unique flow. If a new observed packet=20 contains a different set of these seven key fields, then this packet w= ill=20 create a new flow. Note that a flow contains other accounting fields (= such=20 as the number of packets, number of bytes, the BGP AS, etc).=20 2.2.2 Observation Point=20 NetFlow is enabled in most case per interface (per port), sometimes pe= r=20 subinterface. On specific device, NetFlow is enabled for the entire=20 platform.=20 2.2.3 The Metering Process and the Flow Record=20 NetFlow operates by creating a NetFlow cache that contains the informa= tion=20 for all active flows. A flow record is maintained within the NetFlow c= ache=20 for all active flows. Each flow record in the NetFlow cache contains k= ey=20 fields that can be later used for exporting to a collecting process.=20 2.2.4 The Exporting Process=20 The NetFlow enabled platform checks the NetFlow cache once per second = and=20 expires the flow if no more traffic of that flow is observed. Once=20 expired, the flow records are directly exported to the collecting proc= ess.=20 To achieve efficiency in terms of processing at the Exporter while=20 handling high volume of export, the NetFlow export packet is encapsula= ted=20 into UDP [UDP] datagrams for export to the collecting process.=20 Nevertheless NetFlow flow record export protocol version 9 has been=20 designed to be transport protocol independent. Hence, it can also oper= ate=20 over congestion aware protocols like TCP [TCP] or SCTP [SCTP]. =20 =20 2.2.5 The Collecting Process=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 7]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 NetFlow Collector (the collecting process) provides the data=20 collection from multiple export devices exporting NetFlow flow=20 records. It will process and store the flow records. Some extra=20 actions on these flow records could be executed on the collecting=20 process but per [IPFIX-REQ], these actions are out of the scope of=20 the IPFIX work.=20 =20 =20 =20 2.3 Architectural Differences=20 =20 +----------------+ +----------------+=20 |[*Application 1]| ..|[*Application n]|=20 +--------+-------+ +-------+--------+=20 ^ ^=20 ~ ~=20 +~~~~~~~~~~+~~~~~~~~+=20 !=20 v=20 +----------------------+ +------------------+=20 |Device(i) | | Collector(j) |=20 |[Obsv Point(s)] |--------------->| [*Application(s)]|=20 |[Metering Process(es)]| +---->| |=20 |[Export Process] | | +------------------+=20 +----------------------+ .=20 .... . =20 +----------------------+ |=20 |Device(m) | | =20 |[Obsv Point(s)] |----------+=20 |[Metering Process(es)]| =20 |[Export Process] |=20 +----------------------+=20 =20 Except the terminology difference again described below, there is no=20 difference between the NetFlow and IPFIX architecture.=20 Note that the generic term NetFlow refers to multiple different notion= s:=20 the metering process, the exporting process and the export protocol, a= s=20 defined in the IPFIX terminology section of [IPFIX-REQ].=20 Even if the metering process and exporting process form a single NetFl= ow=20 process on the Cisco Systems devices, this document will sometimes ref= er=20 to NetFlow metering process and NetFlow exporting process for the sake= of=20 clarity. But the export protocol will always be referred to as the Net= Flow=20 flow record export protocol version 9. =20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 8]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3. Item Level Compliance Evaluation=20 =20 This section evaluates the compliance of the NetFlow protocol with the= =20 IPFIX requirements item by item. Requirements are addressed by their=20 section numbers and item numbers in [IPFIX-REQ]. For each requirement=20 it is explained to what degree protocol NetFlow flow export version 9=20 meets the requirement and how this is achieved. The degree of complian= cy=20 is explicitly stated using five grades:=20 =20 -T Total compliance: The requirement is met completely by the=20 protocol specification without any extensions required.=20 =20 -E Extension required for total compliance: The protocol is=20 prepared to be extended and it is possible to extend it in a=20 way that it meets the requirement. This grade is only=20 applicable to protocols that are explicitly open to externally=20 defined extensions, such as SNMP is extended by MIB modules or=20 DIAMETER is extended by application modules. It is not=20 applicable to protocols, where the protocol specification itself= =20 needs to be extended in order to comply with the requirement.=20 =20 -P Partial compliance: The requirement is met partially by the=20 protocol specification.=20 =20 -U Upcoming compliance: The requirement is not met or met=20 partially by the protocol specification, but there is a=20 concrete plan for an upcoming version of the protocol.=20 =20 -F Failed compliance: The requirement is not met by the protocol=20 specification.=20 =20 =20 3.1 Terminology (section 2)=20 =20 3.1.1 IP Traffic Flow (2.1)=20 =20 Total compliance of NetFlow Flow definition with the IPFIX IP=20 Traffic Flow definition.=20 =20 3.1.2 Observation Point (2.2)=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 9]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 Total compliance of NetFlow Observation Point definition with the=20 IPFIX Observation Point definition. NetFlow is enabled by interface=20 or per subinterface. NetFlow can be enable on multiple interfaces=20 at the same time, e.g. all interfaces belonging to one line card, or=20 all the interfaces from the device. On specific device, NetFlow is=20 enabled for the entire platform.=20 =20 3.1.3 Metering Process (2.3)=20 =20 Total compliance of NetFlow with the IPFIX Metering Process=20 definition, for all aspects: packet header capturing, timestamping,=20 sampling, classifying, and maintaining flow records.=20 =20 3.1.4 Flow Record (2.4)=20 =20 Total compliance of NetFlow Flow Record definition with the IPFIX=20 Flow Record definition.=20 =20 3.1.5 Exporting Process (2.5)=20 =20 Total compliance of NetFlow Exporting Process with the IPFIX=20 Exporting Process definition. The NetFlow Exporting Process may send=20 the flow records to 2 different collecting processes.=20 =20 3.1.6 Collecting Process (2.6)=20 =20 Total compliance of NetFlow Collector with the IPFIX collecting=20 process definition. =20 =20 =20 3.2 Applications Requiring IP Flow Information Export (3)=20 =20 Total compliance of NetFlow regarding the different applications=20 described in [IPFIX-REQ] which require IP flow information export,=20 i.e. Usage-based Accounting, Traffic Profiling, Traffic Engineering,=20 Attack/Intrusion Detection and QoS Monitoring. Actually, the=20 Information Model associated with NetFlow flow record export version=20 9 [NETFLOW9] contains all the data types needed to satisfy the=20 requirements of the different applications described in this=20 section.=20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 10]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.3 Distinguishing Flows (4)=20 =20 3.3.1 Interface (4.1)=20 =20 Total Compliance of the interface as a flow distinguisher.=20 In case of ingress NetFlow, a flow is identified, amongst other=20 fields, by the input logical interface (ifIndex). In case of egress=20 NetFlow, a flow is identified, amongst other fields by output=20 logical interface (ifIndex).=20 =20 3.3.2 IP Header Fields (4.2)=20 =20 source IP address (MUST): Total Compliance=20 destination IP address (MUST): Total Compliance=20 protocol type (TCP,UDP,ICMP,...) (MUST): Total Compliance=20 IP version number (SHOULD): Upcoming Compliance=20 =20 3.3.3 Transport Header Fields (4.3)=20 =20 Total Compliance of the port numbers of the transport header as a=20 flow distinguisher.=20 =20 3.3.4 MPLS (4.4)=20 =20 Total Compliance of the MPLS label a flow distinguisher, if the=20 observation point is located at a device supporting Multiprotocol=20 Label Switching.=20 =20 3.3.5 DiffServ Code Point (4.5)=20 =20 Partial Compliance, as NetFlow distinguish flow by the TOS field.=20 =20 3.3.6 Header Compression and Encryption (4.6)=20 =20 Total Compliance.=20 =20 =20 3.4 Metering Process (5) =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 11]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.4.1 Reliability (5.1)=20 =20 To be written.=20 =20 3.4.2 Sampling (5.2)=20 =20 =93The metering process MAY support packet sampling.=94, as defined in= =20 [IPFIX-REQ]=93. Total Compliance. NetFlow supports packet sampling.=20 =20 =93If sampling is supported the sampling configuration MUST be well=20 defined. The sampling configuration includes the sampling method and=20 all its parameters.=94, as defined in [IPFIX-REQ]. Total compliance. =20 See the Options Template from [NETFLOW9]: a template that describes=20 the format of the Flow measurement parameters (like the sampling=20 algorithm, sampling interval) done at the metering process.=20 =20 =93If the sampling configuration is changed during operation, the new=20 sampling configuration with its parameters MUST be indicated to all=20 collecting processes receiving the affected flow records. Changing=20 the sampling configuration includes: start sampling, stop sampling,=20 change sampling method, and change sampling parameter.=93, as defined=20 in [IPFIX-REQ]=93. Partial Compliance. NetFlow supports the =93change=20 sampling method=94 and =93change sampling parameter=94 options.=20 =20 3.4.3 Overload Behavior (5.3)=20 =20 =93In case of an overload, for example lack of memory or processing=20 power, the metering process MAY change its behavior in order to cope=20 with the lack of resources.=94, as defined in [IPFIX-REQ]. =20 Total Compliance. =20 =20 =93But in case the overload behavior has an impact on the metering=20 process or the exporting process, the overload behavior MUST be=20 clearly defined and the collecting process MUST be able to=20 distinguish the flow records exported before and after the metering=20 process behavior change:=94, as defined in [IPFIX-REQ].=20 If the metering process configuration is changed, then Total=20 Compliance. =20 But failed compliance in the following situation: in case the=20 NetFlow cache becomes full, the flow records will be expired with a=20 smaller timeout! In this specific case, this requirement doesn=92t=20 make sense.=20 =20 =93In case of any change of the meter's behavior, all flow records=20 metered by the previous behavior MUST be terminated and exported=20 =20 =20 Claise Expires =96 Mars 2003 [Page 12]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 according to the configuration of the exporting process.=94, as=20 defined in [IPFIX-REQ].=20 Total Compliance.=20 =20 =93The metering process MUST not merge the flow records generated with= =20 the new behavior with the flow records generated with the previous=20 behavior.=94, as defined in [IPFIX-REQ].=20 If the metering process configuration is changed, then Total=20 Compliance because a new Template ID for the new configuration will=20 be generated.=20 But failed compliance in the following situation: in case the=20 NetFlow cache becomes full, the flow records will be expired with a=20 smaller timeout! In this specific case, this requirement doesn=92t=20 make sense.=20 =20 3.4.4 Timestamps (5.4)=20 =20 Total Compliance.=20 =20 3.4.5 Time Synchronization (5.5)=20 =20 The compliance is not relevant as the mechanism used for time=20 synchronization is outside the scope of the IPFIX. =20 =20 3.4.6 Flow Expiration (5.6)=20 =20 Total Compliance of the NetFlow flow expiration mechanism with the=20 IPFIX requirements.=20 The routing device checks the NetFlow cache once per second and expire= s=20 the flow in the following instances:=20 1. Transport is completed (TCP FIN or RST). =20 2. The flow cache has become full. =20 3. The inactive timer has expired after 15 seconds of traffic=20 inactivity. This inactive timer is configurable. =20 4. The active timer has expired after 30 minutes of traffic activi= ty.=20 This active timer is configurable.=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 13]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 3.4.7 Multicast (5.7)=20 =20 Total Compliance of the multicast support with the IPFIX=20 requirements.=20 =20 3.4.8 Ignore Port Copy (5.8)=20 =20 To be written.=20 =20 =20 3.5 Data Export (6) =20 =20 3.5.1 Information Model (6.1)=20 =20 =93The exporting process MUST be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 1. IP version number: Upcoming Compliance (NetFlow will support=20 IPV6)=20 2. source IP address: Total Compliance=20 3. destination IP address: Total Compliance=20 4. IP protocol type (TCP,UDP,ICMP,...) : Total Compliance=20 5. source TCP/UDP port number: Total Compliance=20 6. destination TCP/UDP port number: Total Compliance=20 7. input interface (ifIndex): Total Compliance=20 8. output interface (ifIndex): Total Compliance=20 9. packet counter: Total Compliance=20 10. byte counter: Total Compliance=20 11. in case of IPv4, Type of Service: Total Compliance=20 12. in case of IPv6, Flow Label: Upcoming Compliance=20 13. if BGP is supported at the observation point, BGP AS number:=20 Total Compliance=20 14. if MPLS is supported at the observation point, MPLS label:=20 Total Compliance=20 15. if DiffServ is supported at the observation point, DSCP:=20 Partial Compliance=20 16. timestamp of the first packet of the flow: Total Compliance=20 17. timestamp of the last packet of the flow: Total Compliance=20 18. if sampling is used, sampling configuration: Total Compliance=20 19. unique identifier of the observation point: Total Compliance=20 (the ifIndex)=20 20. unique identifier of the exporting process: Total Compliance=20 (the IP address)=20 =20 =93The exporting process SHOULD be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 =20 =20 Claise Expires =96 Mars 2003 [Page 14]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 21. multicast replication factor. Total Compliance=20 =20 =93The exporting process MAY be able to report the following=20 attributes for each metered flow=94, as defined in [IPFIX-REQ]:=20 22. Time To Live: Extension required for total compliance=20 23. IP header flags: Extension required for total compliance=20 24. TCP header flags: Total Compliance=20 25. dropped packet counter at the observation point: Extension=20 required for total compliance=20 26. fragmented packet counter: Extension required for total=20 compliance=20 =20 3.5.2 Data Model (6.2)=20 =20 =93The data model MUST be extensible=94, as defined in [IPFIX-REQ].=20 Total compliance.=20 =20 =93The data model used for exporting flow information MUST be flexible= =20 concerning the flow attributes contained in flow records=94, as=20 defined in [IPFIX-REQ].=20 Total compliance.=20 =20 =93The Data Model SHOULD be independent of the underlying transport=20 protocol, i.e. the data transfer=94, as defined in [IPFIX-REQ].=20 Total compliance.=20 =20 3.5.3 Data Transfer (6.3)=20 3.5.3.1 Congestion Awareness (6.3.1)=20 =20 =93For the data transfer, a congestion aware protocol MUST be=20 supported=94, as defined in [IPFIX-REQ].=20 To be written.=20 =20 3.5.3.2 Reliability (6.3.2)=20 =20 Total Compliance. A sequence ID exists per export packet so that the=20 collecting process would know if it misses export packets or if=20 packets reordering occurred in the network.=20 =20 3.5.3.3 Security (6.3.3)=20 =20 Failed compliance for confidentiality, integrity and authenticity.=20 =20 =20 Claise Expires =96 Mars 2003 [Page 15]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =20 3.5.4 Regular Reporting Interval (6.4)=20 =20 Total compliance. For long aging flows, the exporting process=20 exports the flow records on regular basis, in order to:=20 1. report the flow records periodic accounting information=20 to the collecting process=20 2. avoid counter wrapping=20 This activity timeout is configurable=20 =20 3.5.5 Notification on Specific Events (6.5)=20 =20 Failed compliance. =20 =20 3.5.6 Anonymization (6.6)=20 =20 To be written.=20 =20 =20 3.6 Configuration (7)=20 =20 3.6.1 Configuration of the Metering Process (7.1)=20 =20 Total Compliance.=20 =20 3.6.2 Configuration of the Exporting Process (7.2)=20 =20 Total Compliance.=20 =20 =20 3.7 General Requirements Compliance (8)=20 =20 3.7.1 Openness (8.1)=20 =20 Total Compliance.=20 =20 3.7.2 Scalability Concerning the Number of Exporting Processes (8.2)=20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 16]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 =93Data collection from hundreds of different exporting processes MUST= =20 be supported.=94, as defined in [IPFIX-REQ].=20 Total Compliance.=20 =20 =93The collecting process MUST be able to distinguish several hundred=20 exporting processes by their identifiers.=94, as defined in [IPFIX- REQ].=20 Total Compliance, the identifier being the IP address of the=20 exporting process.=20 =20 3.7.3 Several Collecting Processes (8.3)=20 =20 Total Compliance. The exporting process is able to export flow=20 information to two different collecting process.=20 =20 =20 4. Security Considerations=20 =20 Security considerations for the IPFIX protocol are covered by the=20 comparison against the specific Security requirements in the IPFIX=20 requirements document [IPFIX-REQ] where they are specifically=20 addressed by sections 6.3.3 and 10.=20 =20 The NetFlow flow record export protocol could be run on the top of=20 IPSEC [IPSEC] to assure security.=20 =20 =20 5. References=20 =20 [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information=20 Export", draft-ietf-ipfix-reqs-05.txt, work in progress,=20 July 2002.=20 =20 [IPFIX-REQ6] J. Quittek et al., "Requirements for IP Flow Information=20 Export", draft-ietf-ipfix-reqs-06.txt, work in progress,=20 July 2002.=20 =20 [NETFLOW9] B. Claise et al., "Cisco Systems NetFlow Services Export =20 Version 9", draft-bclaise-netflow-9-00.txt, work in progre= ss,=20 June 2002.=20 =20 [UDP] J. Postel, "User Datagram Protocol", RFC 768, August =20 1980=20 =20 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM =20 =20 =20 Claise Expires =96 Mars 2003 [Page 17]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 PROTOCOL SPECIFICATION", RFC 793, September 1981=20 =20 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", =20 RFC 2960, October 2000=20 =20 [IPSEC] Kent, S., "Security Architecture for the Internet =20 Protocol", RFC 2401, Nov. 1998, =20 =20 =20 6. Author's Address=20 =20 Benoit Claise=20 Cisco Systems=20 De Kleetlaan 6a b1=20 1831 Diegem=20 Belgium=20 =20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 7. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 =20 =20 Claise Expires =96 Mars 2003 [Page 18]=20 =0CEvaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 20= 02=20 =20 =20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Claise Expires =96 Mars 2003 [Page 19]=20 =0C --------------080404050605070108000804-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 2 13:21:45 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27217 for ; Mon, 2 Sep 2002 13:21:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17ludy-0001h5-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Sep 2002 12:05:42 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17ludu-0001gs-00; Mon, 02 Sep 2002 12:05:38 -0500 Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g82H5ZG27565; Mon, 2 Sep 2002 19:05:35 +0200 (MEST) Message-ID: <3D7399DE.3010102@fokus.gmd.de> Date: Mon, 02 Sep 2002 19:03:26 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: ipfix-eval@net.doit.wisc.edu CC: ipfix-chairs@net.doit.wisc.edu Subject: [ipfix-eval] [Fwd: post draft-zander-ipfix-eval-diameter-00.txt] Content-Type: multipart/mixed; boundary="------------070002030009000307000206" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------070002030009000307000206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g82H5ZG27565 Content-Transfer-Encoding: quoted-printable Hi, please find the Diameter evaluation draft attached. The Diameter protocol= spec can be found at http://www.ietf.org/internet-drafts/draft-ietf-aaa-diamet= er-12.txt. I will update the diameter eval draft in the next few days to produce a 0= 1 version. Cheers, Sebastian -------- Urspr=FCngliche Nachricht -------- Betreff: post draft-zander-ipfix-eval-diameter-00.txt Datum: Mon, 02 Sep 2002 18:59:21 +0200 Von: Sebastian Zander Firma: Fraunhofer FOKUS An: Internet-Drafts@ietf.org Hi, please post the draft attached (draft-zander-ipfix-eval-diameter-00.txt) = as internet draft. Thanx, Sebastian --=20 Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.z= ander --=20 Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.z= ander --------------070002030009000307000206 Content-Type: text/plain; name="draft-zander-ipfix-diameter-eval-00.txt" Content-Disposition: inline; filename="draft-zander-ipfix-diameter-eval-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Sebastian Zander Document: draft-zander-ipfix-diameter-eval-00.txt Fraunhofer FOKUS Expires: February 2003 September 2002 Evaluation of Diameter Protocol against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the Diameter protocol [DIAMETER] as an IPFIX protocol. It compares the properties and capabilities of the Diameter protocol to the IPFIX requirements [IPFIX-REQ]. Zander expires February 2003 [Page 1] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Table of Contents 1 Introduction ................................................. 2 1.1 Diameter Standardization ................................... 2 1.2 Diameter Deployment and Evolution .......................... 3 2 Architectural Considerations ................................. 3 2.1 Diameter Protocol Overview ................................. 4 2.2 General Applicability ...................................... 5 2.3 Architectural Differences .................................. 5 3 Item Level Compliance Evaluation ............................. 6 4 Security Considerations ...................................... 11 5 Acknowledgements ............................................. 11 6 References ................................................... 11 7 Author's Addresses ........................................... 12 8 Full Copyright Statement ..................................... 12 1. Introduction This document provides an evaluation of the applicability of the Diameter protocol as an IPFIX protocol. First, the general Diameter architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met. This document uses the terminology defined in [IPFIX-REQ]. The Diameter protocol is the successor of the RADIUS protocol and was developed to overcome several limitations of RADIUS. The Diameter protocol was developed for the purpose of Authentication, Authorization and Accounting (AAA) and is standardized by the IETF Authentication, Authorization and Accounting Working Group (AAA WG). The Diameter base protocol is specified in draft-ietf-aaa- diameter-12.txt [DIAMETER]. The Diameter base protocol provides a AAA framework. Specific applications require extensions to the base protocol and are called Diameter applications. Currently applications are being standardized by the AAA WG for dial-up and mobile IPv4 services. These specific applications are considered out of scope for the purpose of this document. However there are two companion drafts to the Diameter base protocol which need to be considered here: the strong end-to-end security extension [DIAM_CMS] and the transport recommendations for the Diameter base protocol [AAA_TRANS]. Zander expires February 2003 [Page 2] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 1.1. Diameter Standardization The Diameter base protocol has passed Working Group last call after thorough review. The draft will now be reviewed by the IESG and afterwards become a Proposed Standard. The transport recommendations draft is very mature while the CMS draft needs more work. The Diameter protocol will become an open IETF standard and is not protected by any patents. The IETF copyright can be found at the end of [DIAMETER] or at the end of this draft. Currently there exist approximately 5 implementations from different vendors. One of the implementations is even freely available as binary [DIA_SUN]. Furthermore an open source project has been started to create an open source implementation of the protocol [DIA_OS]. 1.2. Diameter Deployment and Evolution The Diameter protocol is already commercially available but not widely used yet because it is not standardized. Also most ISPs will not switch from RADIUS to Diameter for their dial-up services. However if Diameter is used in Release 5 of 3GPP as planned it is expected that the protocol will be widely deployed as part of the 3GPP rollout. A further driver will be ISPs offering mobile IP support. Currently a standardized RADIUS AAA solution for mobile IP does not exist. The further activities of the AAA WG after standardization of Diameter base protocol and base applications are under discussion. The most likely scenario (advocates opinion) is that the AAA WG will continue to develop more Diameter applications (collaborating with other WGs if needed). Also the base protocol will probably be developed further in case the demand is there. 2. Architectural Considerations This section introduces the architecture of the Diameter protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. The Diameter architecture consists of three different entities: Diameter clients, Diameter servers and Diameter agents. Diameter clients send requests for Authentication and/or Authorization to Diameter servers. Diameter clients also send Zander expires February 2003 [Page 3] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 accounting information to Diameter servers. Diameter clients are for example Network Access Servers (NASs) or foreign and home agents (mobile IPv4). Diameter servers perform authentication and authorization decisions based on Diameter clients requests and return answers to Diameter clients. Diameter servers configure accounting of the Diameter clients and get accounting information send by them. When Diameter servers get messages not destinated to themselves they forward both Authentication and Authorization request and accounting data to the appropriate servers. Diameter servers may also automatically direct the Diameter clients to send accounting information in a particular way. Four different types of Diameter agents have been identified and are described in Section 2.8 of [DIAMETER]. Diameter agents are used for a number of purposes: grouping of systems (security associations), request concentration, load balancing and value-added processing of requests/responses. Please note that despite the fact that the terms client and server are used the Diameter protocol is not a client server protocol but a peer-to-peer protocol. Any Diameter peer can start a messages exchange. This will be described in more detail in the next section. 2.1. Diameter Protocol Overview This section only provides a brief overview of the Diameter base protocol. Therefore it is mandatory to read the base protocol draft [DIAMETER] before evaluating the protocol. The Diameter base protocol is intended to provide an AAA framework for applications such as network access or mobile IP [DIAMETER]. is a peer-to-peer protocol allowing any peer to start a message exchange. The Diameter base protocol is never used on its own. It is always extended for a particular application e.g. mobile IPv4. The Diameter protocol is run on top of TCP [TCP] or SCTP [SCTP] which guarantee a reliable and congestion aware transport. Draft [AAA_TRANS] discusses the AAA transport issues in detail. Diameter has a build-in watchdog algorithm which can pro-actively detect transport failures. Also failback and failover procedures have been defined (section 5.5.4 [DIAMETER] and [AAA_TRANS]). Zander expires February 2003 [Page 4] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Diameter supports dynamic peer discovery through different mechanisms e.g. DNS, SLPv2 [SLP] to enable a simpler and more robust deployment. Peers can also be configured manually. Diameter provides application layer sessions which abstracts from transport connections. Diameter messages for multiple sessions are multiplexed through a single transport connection. Diameter server and agents route messages to their final destination based on realms. The data model of Diameter is based on Attribute Value Pairs (AVPs). Each Diameter message consists of a fixed header and a number of AVPs carrying data. The fixed header contains a 16 bit command code which identifies the type of message. A number of data types for AVPs have been defined already. AVPs can be grouped into logical structures. Diameter can be extended by defining new AVP values, new AVPs and new applications (which includes definition of new command codes). The Diameter protocol supports capability negotiation between peers. This enables a more simpler and robust deployment. Diameter supports applications which support Authentication, Authorization and Accounting. It also supports applications which only make use of accounting (see section 8 [DIAMETER]). Diameter uses hop-by-hop security [DIAMETER] and a Diameter extension exists which supports end-to-end security [DIAM_CMS] (see security considerations for more details). 2.2. General Applicability The Diameter architecture consists of three different entities (client, server and agent) while the IPFIX architecture is comprised of: observation point, metering process, exporting process and collecting process. From the viewpoint of the IPFIX protocol only the exporting process and collection process are relevant because these are the entities communicating via the IPFIX protocol. However the IPFIX protocol must carry data generated by the metering process. The process of exporting IP flow information is similar to the accounting part of Diameter: The Diameter client sending accounting information is simlar to the IPFIX exporting process sending IP flow information. The Diameter server receiving accounting information is similar to the collecting process receiving IP flow information. Diameter Relay and Proxy Agents are similar to an IPFIX proxy (a Zander expires February 2003 [Page 5] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 combination of collecting and exporting process) as described in section 9 [IPFIX]. The Diameter Translation Agent is similar to the Protocol Converter as described in section 9 [IPFIX]. The metering process and observation point are similar to entities co-located with the Diameter client which collect the accounting information. The IPFIX protocol could be implemented with Diameter similar as a new Diameter accounting application can be defined. [DIAMETER] explicitly describes how new accounting applications can be defined in section 1.2.4. 2.3. Architectural Differences The Diameter architecture has been developed for providing a AAA framework while IPFIX is to be developed for exporting IP flow information. There are no major differences between both architectures. The Diameter architecture is more generic than IPFIX. It supports a number of different proxy types and message routing. Furthermore the functionality of the first two As is not useful for IPFIX. However IPFIX could be viewed as a subset of Diameter similar to the Diameter accounting functionality. The Diameter standard explicitly supports accounting-only Diameter applications. 3. Item Level Compliance Evaluation This section evaluates the compliance of the Diameter protocol with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement it is explained to what degree protocol Diameter meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is onLY applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protocols, where the protocol specification itself needs to be extended in order to comply with the requirement. Zander expires February 2003 [Page 6] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 -P Partial compliance: The requirement is met partially by the protocol specification. -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. Requirement 4 (Distinguishing Flows): -E The following requirements assumes that Diameter is not only used for exporting IP flow information but also for configuration of the export. In case a different protocol is used for the configuration these requirements do not apply. As Diameter has not been developed for the purpose of IP flow export most of the attributes are not yet defined in the existing data model. To comply to the IPFIX protocol there are several possible options. Either all of the attributes are defined as new AVPs from the defined AVP types (and grouped where appropriate) (see Section 4.3,4.4 [DIAMETER]). Alternatively the existing QoS/IPFilterRule data types can be used and grouped with additional AVPs containing the attributes not yet defined in Diameter (see Section 4.4 [DIAMETER]). A further option is to extend the QoS/IPFilterRule types directly because most of the required attributes are covered already. Requirement 4.1 (Interfaces): -E Incoming interface and outgoing interface can be defined as AVPs. Requirement 4.2 (IP Header): -E Source IP and destination IP address can be defined as new AVPs. Note that Diameter supports both IPv4 and IPv6 addresses. Protocol Type and IP version number can be defined as AVPs. The existing IPFilterRule data type supports source, destination IP, protocol type. It also supports prefix matches of the addresses via masks. Requirement 4.3 (Transport Header): -T/E Source and destination port number can be defined as AVPs. The Zander expires February 2003 [Page 7] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 existing IPFilterRule data type supports ports, list of ports or ranges. Requirement 4.4 (MPLS): -E The MPLs label can be defined as AVP. Requirement 4.5 (DSCP): -T/E The Diffserv Code Point can be defined AVP. The existing QoSFilterRule supports a DSCP attribute. Requirement 4.6 (Header Compression): n/a This imposes no further requirements on the protocol Requirement 5.1 (Reliability): n/a This requirement does not apply to the protocol. Requirement 5.2 (Sampling): -E This requirement is a metering process requirement. However the IPFIX protocol must support to export some information about sampling configuration. New (grouped) AVPs can be defined for carrying the sampling configuration. Requirement 5.3 (Overload Behavior): -E This requirement is a metering process requirement. However some information must be send via the protocol e.g. to indicate overload behavior changes. New AVPs can be defined to signal changes of metering behaviour to the collecting process. Requirement 5.4 (Timestamps): -E This requirement is a metering process requirement. However a candidate protocol must support a proper timestamp format. Diameter does only support the Time data type which is UTC time in seconds. To meet the requirement a new AVP data type must be defined. Alternatively a Time AVP can be used for the seconds and grouped with an additional AVP for the centiseconds. Requirement 5.5 (Time Synchronization): n/a This requirement does not apply to the protocol. Zander expires February 2003 [Page 8] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Requirement 5.6 (Flow Expiration): n/a This requirement does not apply to the protocol. Requirement 5.7 (Multicast Flows): n/a This requirement does not apply to the protocol. Requirement 5.8 (Ignore Port Copy): n/a This requirement does not apply to the protocol. Requirement 6.1 (Information Model): -E For most of the attributes required there currently exist no defined AVPs. But for all attributes listed AVPs can be easily derived from the base data types. Instead of using existing data types new data types could be defined. Requirement 6.2 (Data Model): -T The data model of Diameter is based on the Attribute Value Pair (AVP) concept. An attribute is identified uniquely by a numeric AVP code and AVP length. A number of base types for AVPs have been defined in [DIAMETER]. The data model of Diameter is extensible because new AVPs and new AVP types can be defined. Diameter supports grouping of AVPs and nesting of grouped AVPs to create more complex structure. The data model is flexible because each Diameter message only has a small fixed size header. After the header arbitrary AVPs (as defined for a message) follow. The data model is independent of the transport (TCP or SCTP are used). Requirement 6.3.1 (Congestion Awareness): -T Diameter uses TCP or SCTP as transport. Both protocols are congestion aware. Requirement 6.3.2 (Reliability): -T Diameter is an application layer protocol which uses TCP [TCP] or SCTP [SCTP] as transport protocols which are both reliable. To support application layer reliability the protocol supports application layer ACKs and error messages. Zander expires February 2003 [Page 9] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 A watch dog mechanism has been defined to detect transport problems and failover and failback procedures have been defined. Diameter also supports capability negotiation between peers which assures that both peers have the same capabilities. Requirement 6.3.3 (Security): -T Diameter provides end-to-end as well as hop-by-hop authentication, integrity and encryption. Some mechanisms are provided by underlying security protocols used such as IPSec or TLS. Since [DIAMETER] specifies how to use them this requirement is considered to be met by the protocol. Please read the security considerations section for more details. Requirement 6.3.4 (Push/Pull Mode): -T Diameter is a peer to peer protocol. The current Diameter accounting model uses the push mode (a Diameter client sends accounting information to a Diameter server). However a Diameter application could be defined which supports a pull mode as well. Requirement 6.4 (Regular Report Interval): -T Diameter can send accounting information in regular intervals. Requirement 6.5 (Event Notification): -T A Diameter peer can send messages at times of events. The events and messages must be defined for the specific application. A Diameter configuration message could configure when to send specific event messages. Currently the Diameter base protocol sends accounting messages at the start and end of a session. Requirement 6.6 (Anonymization): n/a Diameter does not support anonymization. However anonymization is not a protocol specific function and therefore the requirement does not apply to the protocol. A function can be integrated into a Diameter peer which anonymizes certain data before it is exported in AVPs. Requirement 7 (Metering Process Configuration): -E These requirements only apply if Diameter is used for configuration of the metering process. Since Diameter is not a protocol for exporting IP flow information the listed attributes are not specified yet. Since the data model is flexible all attributes can Zander expires February 2003 [Page 10] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 be specified as AVPs. Requirement 8.1 (Openness): -T The Diameter base protocol is open and has an extensibility concept specified in the standard. The flexible AVP model allows to support any information model. New Diameter applications can be created which can define application specific messages and message exchange. Requirement 8.2 (Scalability): -T A Diameter peer is not limited in the number of connections to other peers. In Diameter each peer has a unique identifier which must be present in each message (Origin-Host AVP). Furthermore Diameter uses session IDs to uniquely identify specific sessions. Requirement 8.3 (Several Collecting Processes): -T Diameter accounting records are usually only send to the home server. However there is no limitation in the protocol that restricts sending information to only one destination. Diameter supports duplicate data detection over multiple receivers because each accounting message contains client ID, session ID, timestamp and a sequence number in each message. 4. Security Considerations Security considerations for the IPFIX protocol are covered by the comparison against the specific Security requirements in the IPFIX requirements document [IPFIX-REQ] where they are specifically addressed by sections 6.3.3 and 10. The Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security model is acceptable in environments where there is no untrusted third party agents. The use of TLS, IPSEC and considerations of peer-to-peer security issues are discussed in the security considerations of [DIAMETER]. In situations of untrusted third party agents, end-to-end security is needed. [DIAM_CMS] describes how a security association is established by two peers through agents, and how authentication, integrity, confidentiality and data origin authentication are achieved using a mixture of symmetric and asymmetric transforms. Zander expires February 2003 [Page 11] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 5. Acknowledgements The authors would like to thank Jari Arkko for his valuable comments on the first version of the draft. 6. References [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, work in progress, July 2002. [DIAMETER] P. Calhoun et al. "Diameter Base Protocol", draft-ietf-aaa- diameter-12.txt, work in progress, July 2002. [AAA_TRANS] B. Aboba at al., "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa- transport-07.txt, work in progress, April 2002 [DIAM_CMS] P. Calhoun et al., "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-04.txt, work in progress, March 2002 [TCP] Postel, J., "Transmission Control Protocol", RFC 793, January 1981. [SCTP] R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960. October 2000. [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, Version 2", RFC 2165, June 1999. [DIA_SUN] SUN Diameter implementation, http://playground.sun.com/diameter/ [DIA_OS] Diameter Open Source Project, http://sourceforge.net/projects/diameter/ Zander expires February 2003 [Page 12] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 7. Author's Addresses Sebastian Zander Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7287 Email: zander@fokus.fhg.de 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Zander expires February 2003 [Page 13] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 --------------070002030009000307000206-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 3 00:46:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07199 for ; Tue, 3 Sep 2002 00:46:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17m5GC-0001bd-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Sep 2002 23:25:52 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17m5G9-0001bV-00 for ipfix-eval@net.doit.wisc.edu; Mon, 02 Sep 2002 23:25:49 -0500 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id A5090E0068E; Mon, 2 Sep 2002 21:25:46 -0700 (PDT) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id VAA06579; Mon, 2 Sep 2002 21:25:40 -0700 (PDT) Received: from cup.hp.com ([15.244.161.20]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20020903045359.FUCI18196.simail.cup.hp.com@cup.hp.com>; Mon, 2 Sep 2002 21:53:59 -0700 Message-ID: <3D743992.3080209@cup.hp.com> Date: Mon, 02 Sep 2002 21:24:50 -0700 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: internet-drafts@ietf.org Cc: protocol@ipdr.metratech.com, ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] Streaming IPDR Advocacy Draft Content-Type: multipart/mixed; boundary="------------030601070109090407030203" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030601070109090407030203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Please post the attached draft-meyer-ipfix-IPDR-eval-00.txt as an internet draft. The document is also available at the following URL: http://www.ipdr.org/documents/ipfix/draft-meyer-ipfix-IPDR-eval-00.txt An HTML version is also available, making navigation to references simpler, at: http://www.ipdr.org/documents/ipfix/draft-meyer-ipfix-IPDR-eval-00.html Regards, Jeff Meyer --------------030601070109090407030203 Content-Type: text/plain; name="draft-meyer-ipfix-IPDR-eval-00.txt" Content-Disposition: inline; filename="draft-meyer-ipfix-IPDR-eval-00.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Meyer Internet-Draft Hewlett-Packard Expires: March 3, 2003 September 2, 2002 Evaluation Of Streaming IPDR Against IPFIX Requirements draft-meyer-ipfix-IPDR-eval-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 3, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the Streaming IPDR protocol as an IPFIX protocol. It compares the properties and capabilities of Streaming IPDR to the IPFIX requirements. Streaming IPDR is a mechanism to deliver streams of network usage information which follow the Internet Protocol Detail Records (IPDR) format over a reliable transport connection. Meyer Expires March 3, 2003 [Page 1] Internet-Draft Streaming IPDR Eval September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Level of Standarization . . . . . . . . . . . . . . . . . . 3 1.3 Patent Protection . . . . . . . . . . . . . . . . . . . . . 4 1.4 Availability . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Commercial Use . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Future Protocol Development Areas . . . . . . . . . . . . . 4 2. Architectural Considerations . . . . . . . . . . . . . . . . 5 2.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 2.2 General Applicability . . . . . . . . . . . . . . . . . . . 6 2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Trivial Streaming IPDR . . . . . . . . . . . . . . . . . . . 8 2.3 Architectural Differences . . . . . . . . . . . . . . . . . 8 3. Item Level Compliance Evaluation . . . . . . . . . . . . . . 9 3.1 Items by Section . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Data Export (6) . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Configuration (7) . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 General Requirements (8) . . . . . . . . . . . . . . . . . . 12 3.2 Compliance Table . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 A. IPFIX IPDR Service Definition . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 Meyer Expires March 3, 2003 [Page 2] Internet-Draft Streaming IPDR Eval September 2002 1. Introduction This document provides an evaluation of the applicability of the Streaming IPDR [2] protocol as an IPFIX protocol. First, the general IPDR architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in the IPFIX Requirements [1] are met. This document uses the terminology defined in IPFIX Requirements [1]. 1.1 Documentation The specific protocol mechanism, Streaming IPDR [2], is a work in progress submitted as an IETF draft. The protocol itself builds upon some of the procedures defined in the IPDR Network Data Management-Usage (NDM-U) 3.1 [6] specification. Sections 1, 2 and 3 of the NDM-U 3.1 specification provide an Introduction, the IPDR Reference model and the business requirements addressed. The relevant protocol sections in NDM-U 3.1 are: The NDM-U Protocol in section 4. More specifically subsections 4.1 and 4.3. The Schema guidelines in section A.4 In addition Appendix A in this document defines an IPDR service definition which addresses the required set of IPFIX data attributes. 1.2 Level of Standarization IPDR.org is an non-profit industry consortium. Member companies collaborate to agree upon IPDR specifications. These specifications are versioned and published on the IPDR.org website. The current specification as of this writing is NDM-U 3.1. [6] Particpating companies also participate in interoperability and compliance activities to shake out issues in the specification. In addition to relying on the NDM-U 3.1 specification, this proposal introduces two additional documents, the IPFIX service definition, in Appendix A and the Streaming IPDR [2] extension and protocol binding. Meyer Expires March 3, 2003 [Page 3] Internet-Draft Streaming IPDR Eval September 2002 The Streaming IPDR protocol may be submitted as an IETF Proposed Standard, based on evaluation by the IPFIX working group. 1.3 Patent Protection There are no known patents which apply to or affect the right to freely use this technology. 1.4 Availability The base IPDR NDM-U 3.1 specification is implemented by a number of billing and mediation software companies. The specific procedures introduced in Streaming IPDR are not currently available with commercial products. A complete implementation written in Java has been developed, but is under test. A C implementation can built upon existing work done in IPDR's reference library. 1.5 Commercial Use Several service providers have deployed IPDR based service accounting in their networks. Based upon the recent availability of a compact as well as XML based format, and IPDR's XML-Schema based extension model, it is expected that IPDR will be more widely deployed in the future. 1.6 Future Protocol Development Areas The current NDM-U 3.1 Sevice Definition Guidelines and the Compact data model limit the protocol to carrying data which is in "First Normal Form" (FNF). Current IPFIX flow records are also FNF. They are all defined as non-repeating fields, and the fields are simple primitive types, not structures. It is desireable to remove the first normal form restriction, but still encourage keeping record structures as flat as possible. This will allow mapping the XML Schema model to existing protocols and CDRs such as Diameter or 3GPP GGSN records, without removing information. Proposed additions to the XDR based compact format and the Schema writing guidelines will be made shortly to address repeating fields and records to be defined in addition to FNF. Meyer Expires March 3, 2003 [Page 4] Internet-Draft Streaming IPDR Eval September 2002 2. Architectural Considerations This section introduces the architecture of the Streaming IPDR protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. IPDR is a general purpose protocol meant to address the exchange of usage information between cooperating systems. 2.1 Protocol Overview The compact IPDR specification defines a document format which offers a compact and efficient represenation of usage accounting data. This structure is defined in section 4.3 of the IPDR NDM-U 3.1 [6]specfication. The encoding format is based on the ONC-RPC eXtensible Data Representation (XDR). The encoding supports a basic set of primitive data types and a number of additional types which are derived from the primitive types The mechanisms for encoding and transport are completely separate in IPDR. The CompactIPDR format can be used to serialize usage information to a file or it can be used to serialize usage information onto a reliable transport, such as TCP. For real time push oriented communication the streaming over a reliable transport is preferred, as described in Streaming IPDR [2]. A file can also be used as the unit of exchange. File based exchange has been the focus of much of the Interoperability work done by various member companies of IPDR.org to date. The file transfer related exchange described in Section 4.4 is not part of this proposal. Although it does provide a pull based model for exchange of information between collection processes. IPDR's XML-Schema based format has the additional benefit of providing a well defined equivalent XML encoding. Both the compact and XML formats are based on a common service definition specification. The service specification is expressed as one or more XML Schema documents, which follow the guidelines set forth in section A.4 of the IPDR NDM-U 3.1 specification. Service specifications are the primary means of extension in IPDR. A service definition addressing the required and optional parameters described in IPFIX Requirements is provided as an Appendix to this document. Meyer Expires March 3, 2003 [Page 5] Internet-Draft Streaming IPDR Eval September 2002 As an example of the general usefulness of XML as a base language for specifications, consider this document. Although you may be reading it as an HTML document or a formatted nroff text document, it started off as a set of markup following RFC2629 [13]. +----------------------+ | Service Definition(s)| | (in XML Schema) | +----------------------+ | | v v +---------------------+ +-----------------------+ | Usage information | | Usage information | | (an XML Document) | | (a compact document)| +---------------------+ +-----------------------+ The XML encoding is not used by Streaming IPDR protocol. However it is worth noting that all flow records sent using Streaming IPDR have a lossless and unambiguous mapping to content in an XML document. The details of the XML encoding are contained in Section 4.2 of NDM-U 3.1 [6]. 2.2 General Applicability This specification only addresses the exchange of information between an exporting process and a collecting process. How metering points and observation points interact with the exporting process is specifically not addressed. Specifically the model specified in section 2.4 of NDM-U 3.1 [6] assumes that the Service Element contains the metering points. The raw information acquired by the meterint points is turned into IPDR based strcutures by some Recording Element. The recorded flows are transmitted over a TCP connection to one or more collecting processes. Different record types are identified in the stream by different descriptors. These types should also be defined in one of the XML Schemas describing the exported information. 2.2.1 Illustration The basic elements of the Streaming IPDR protocol are the following: Meyer Expires March 3, 2003 [Page 6] Internet-Draft Streaming IPDR Eval September 2002 Header - this describes the XML schemas and namespace declarations to be used for this session (or document). This makes each stream (or file) a self describing document. Descriptor - sometimes refered to as templates, this element describes the fields which may appear in a flow record. Order is implied. This allows flow records to be well packed (especially with numeric types). Ack - a message indicating the sequence number and relative time information at each system. Provides "application level" flow control capabilities. Usage Event - a flow record whose structure was previously defined by a descriptor. Disconnect - provides graceful shutdown of communication channel with known disposition of flow records. Time t0: <-- TCP Conn Established --> +----------------+ | Header | +----------------+ -- transmitted --> | Descriptor | +----------------+ | Ack | +----------------+ +----------------+ | Header | <-- transmitted +----------------+ | Ack | +----------------+ Time t1 (one or more usage event(s) recorded): +----------------+ | Usage Event | -- transmitted --> +----------------+ ... +----------------+ | Usage Event | Meyer Expires March 3, 2003 [Page 7] Internet-Draft Streaming IPDR Eval September 2002 +----------------+ Time t2 (either time or volume hint triggers Ack): +----------------+ <-- transmitted | Ack | +----------------+ Time t3 (idle period has exceeded hint): +----------------+ | Ack | -- transmitted --> +----------------+ Basic scenario continues until some terminating control message arrives and finally at time tn: +----------------+ | Disconnect | -- transmitted --> +----------------+ +----------------+ <-- transmitted | Disconnect | +----------------+ <-- TCP Connection Release --> Note that additional descriptor stream elements MAY be transmitted in the stream along with Usage Events at any time. 2.2.2 Trivial Streaming IPDR The illustration presented above is the IPDR Streaming protocol in its reliable mode. There is also a "Trivial Streaming Protocol" which does not involve any communication from the collecting system. The author has seen several middlebox and application protocols following this pattern. So it is worthwile to note this option exists as well. 2.3 Architectural Differences When limited to the communication between an exporting process and a collection process, the IPDR Reference model matches that of IPFIX. Meyer Expires March 3, 2003 [Page 8] Internet-Draft Streaming IPDR Eval September 2002 3. Item Level Compliance Evaluation This section evaluates the compliance of the Streaming IPDR with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in IPFIX Requirements [1]. For each requirement, it is explained to what degree Streaming IPDR meets the requirement and how this is achieved. At the end of the written discussion a table summarizes the compliance by asssigning one of five grades to each item. Please note that the requirements specified in sections 4, 5 and 7.1 of IPFIX Requirements [1] do not directly concern the IPFIX protocol, but the semantics of the data transferred. They can be met easily by extensible protocols that do not restrict sematics of transferred data. This includes the Streaming IPDR format, as the data model allows for arbitrary extension, following a well established standard, XML Schema [4]. Therefor only sections 6, 7.2 and 8 will be directly covered. 3.1 Items by Section The subsections describe how Streaming IPDR satisfies each of the mandatory requirements of the specified for the IPFIX protocol. 3.1.1 Data Export (6) 3.1.1.1 Information Model (6.1) The proposed information model is based on the data model draft [12] which is currently available. Items 2,3,4,5,6,7,8,9,10,11,12,16,17,18 are addressed directly by the existing IPFIX data model draft. They are present as element defintions in Appendix A. The combination of these elements to form an IPDR complexType is also shown. Mandatory and optional parameters are captured as well. The remaining items are addressed as follows: Item 1: the distinction between IPv4 and IPv6 is determined by the record type. Records either contain all IPv4 based addresses or all IPv6 style addresses. Item 13: the current data model defines three attributes related to Autonomous System identifiers. These are captured in the schema definition. The meaning of "if BGP is supported at the Meyer Expires March 3, 2003 [Page 9] Internet-Draft Streaming IPDR Eval September 2002 observation point: BGP AS Number" is unclear. Item 19: the current data model does specifies an address of an observationPoint. It is assumed this matches the intent of this item. Item 20: the initial IPDR header exchange provides recorderInfo, which should match this requirement. Items 14,15,21,22,26: the current data model does not appear to define these items. This protocol advocacy draft assumes that the abstract data model be defined to match the requirements. 3.1.1.2 Data Model (6.2) IPDR's Data Model is based on a subset of XML Schema. [4] This subset provides a restricted set of types to define basic elements (Flow Record Fields) and complex type definitions (Flow Record structures). The front matter to the XML Schema webpage states "XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents." IPDR carries this definition further, recognizing that the XML-Schema language can be used to define the structure, content and semantics of other encoding schemes. In particular the mapping to XDR provides one concrete use case. Future definitions may map to additional protocols. Appendix A provides an example of the modelling capability of NDM-U 3.1. See the section describing "Futures" in this document for additional planned capabilities. 3.1.1.3 Data Transfer (6.3) 3.1.1.3.1 Congestion Awareness (6.3.1) Streaming IPDR uses TCP which is congestion aware. Streaming IPDR also enables congestion information at the application level via the optional use of sequence numbers. 3.1.1.3.2 Reliability (6.3.2) Streaming IPDR uses TCP which is provides reliable ordered delivery of information. Streaming also allows for application level sequence Meyer Expires March 3, 2003 [Page 10] Internet-Draft Streaming IPDR Eval September 2002 numbers. In the event of connection loss, the acknowledgement scheme will bound the amount of information which needs to be retransmitted, in order to guarantee delivery of all flow records. 3.1.1.3.3 Security (6.3.3) The underlying security options proposed by Streaming IPDR in section 4 address the attacks and other concerns described in the security section. 3.1.1.4 Regular Reporting Interval (6.4) The protocol allows an exporting process to address this requirement. 3.1.1.5 Notification on Specific Events (6.5) This requirement is specified as a MAY and is not addressed by Streaming IPDR. 3.1.1.6 Anonymization (6.6) The protocol allows an exporting process to address this requirement. 3.1.2 Configuration (7) 3.1.2.1 Configuration of Exporting Process (7.2) The Streaming IPDR protocol only addresses the acknowledged one way flow of information from the exporting process to the collecting process. The configuration mechanims of the exporting process is not addressed by this proposal. Configuration models based on SNMP MIBs or command line interfaces can be used. Additional configuration items introduced by the Streaming IPDR Protocol, which should be exposed by the exporting process, include: IP Address(es) of the collecting systems. Port(s) of the collecting systems. Flow buffering properties for reliable delivery: maximum buffer size (in # flows) [or no buffering] ack interval hint [or trivial] Meyer Expires March 3, 2003 [Page 11] Internet-Draft Streaming IPDR Eval September 2002 ack time interval hint schema, namespace and type information of flow records 3.1.3 General Requirements (8) 3.1.3.1 Openness (8.1) The NDM-U 3.1 specification [6] is publicly available. It takes the approach of leveraging existing standards where applicable. These include the TMF Telecom Operations Map for the reference model, and XML [3], XML Namespace, XML Schema [4] and XDR [7] as basis for notation, syntax and encoding. 3.1.3.2 Scalability Conerning the number of Exporting Processes (8.2) A collecting application can interface with many exporting processes. The only limitations are the network, disk and processing throughput of the system relative to the flow event rate being presented.. 3.1.3.3 Several Collecting Processes (8.3) Using several, possibly locally deployed, collecting applications to collect from flow exporting systems is a good way to scale collection. Any given collection system is limited by its network, disk and processing throughput relative to the flow event rate being presented.. 3.2 Compliance Table The following table summarizes the degree of compliancy using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is only applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protcols, where the protocol specification itself needs to be extended in order to comply with the requirement. -P Partial compliance: The requirement is met partially by the protocol specification. Meyer Expires March 3, 2003 [Page 12] Internet-Draft Streaming IPDR Eval September 2002 -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. ----------------------------------------------. B: IPFIX Requirement Status | ----------------------------------------. | A: IPDR Streaming Compliance | | ----------------------------------. | | | | | | Sect. | Requirement | | | |-------+-------------------------+-----+------| | 6. | DATA EXPORT | |-------+-------------------------+-----+------| | 6.1. | INFORMATION MODEL | |-------+-------------------------+-----+------| | 6.1. | IP Version | E | M | |-------+-------------------------+-----+------| | 6.1. | src/dst address | E | M | |-------+-------------------------+-----+------| | 6.1. | transport protocol | E | M | |-------+-------------------------+-----+------| | 6.1. | src/dst port | E | M | |-------+-------------------------+-----+------| | 6.1. | Packet counter (h) | E | M | |-------+-------------------------+-----+------| | 6.1. | Byte counter | E | M | |-------+-------------------------+-----+------| | 6.1. | Dropped Packet | E | M | | | Counter (h,i) | | | |-------+-------------------------+-----+------| | 6.1. | ToS Byte | E | M | |-------+-------------------------+-----+------| | 6.1. | Flow Label | E | M | |-------+-------------------------+-----+------| | 6.1. | BGP AS# | E | M | |-------+-------------------------+-----+------| | 6.1. | MPLS label (a) | E | M | | | | | | |-------+-------------------------+-----+------| | 6.1. | DSCP (a) | E | M | |-------+-------------------------+-----+------| | 6.1. | Timestamps for | E | M | | | first/last packet | | | Meyer Expires March 3, 2003 [Page 13] Internet-Draft Streaming IPDR Eval September 2002 |-------+-------------------------+-----+------| | 6.1. | Sampling configuration | E | M | |-------+-------------------------+-----+------| | 6.1. | observation point | E | M | | | identifier | | | |-------+-------------------------+-----+------| | 6.1. | export process | T | M | | | identifier | | | |-------+-------------------------+-----+------| | 6.1. | TTL | E | O | |-------+-------------------------+-----+------| | 6.1. | IP header flags | E | O | |-------+-------------------------+-----+------| | 6.1. | TCP header flags | E | O | |-------+-------------------------+-----+------| | 6.1. | Fragment counter | E | O | |-------+-------------------------+-----+------| | 6.1. | Multicast | E | S | | | replication factor | | | |-------+-------------------------+-----+------| | 6.2. | DATA MODEL | |-------+-------------------------+-----+------| | 6.2. | Flexibility | T | O | |-------+-------------------------+-----+------| | 6.2. | Extensibility | T | M | |-------+-------------------------+-----+------| | 6.3. | DATA TRANSFER | |-------+-------------------------+-----+------| | 6.3.1.| Congestion aware | T | M | |-------+-------------------------+-----+------| | 6.3.2.| Reliability | T | M | |-------+-------------------------+-----+------| | 6.3.3.| Confidentiality | T | S | |-------+-------------------------+-----+------| | 6.3.4.| Integrity | T | M | |-------+-------------------------+-----+------| | 6.3.5.| Authenticity | T | M | |-------+-------------------------+-----+------| | 6.4. | REPORTING TIMES | |-------+-------------------------+-----+------| | 6.4. | Push mode | T | M | |-------+-------------------------+-----+------| | 6.4. | Pull mode | T | O | | | | (a) | | |-------+-------------------------+-----+------| | 6.4.1.| Regular Interval | T | S | |-------+-------------------------+-----+------| | 6.6. | Notifications | P | O | Meyer Expires March 3, 2003 [Page 14] Internet-Draft Streaming IPDR Eval September 2002 |-------+-------------------------+-----+------| | 6.7. | Anonymization | T | O | |-------+-------------------------+-----+------| | 7. | CONFIGURATION | |-------+-------------------------+-----+------| | 7. | Config Measurement | T | M | | | & Data Export |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Observation Point| T | S | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Flow | T | S | | | Specifications |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Flow Timeouts | T | S | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Sampling | T | O | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Report | T | S | | | Data Format |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config | T | O | | | Notifications |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Anonymization | T | O | | | |(n/a)| | |-------+-------------------------+-----+------| | 8. | GENERAL REQUIREMENTS | |-------+-------------------------+-----+------| | 8.1. | Openness | T | S | |-------+-------------------------+-----+------| | 8.2. | Scalability: | | | | | data collection | T | M | | | from hundreds of | | | | | measurement devices | | | |-------+-------------------------+-----+------| | 8.3. | Several Collectors | T | O | |-------+-------------------------+-----+------| (a) - The IPDR NDM-U 3.1 specification defines a pull based protocol which relies on file transfer. This protocol is not directly advocated in this draft, since the primary consideration is push based delivery. (n/a) - IPDR defines the transfer protocol between the exporting Meyer Expires March 3, 2003 [Page 15] Internet-Draft Streaming IPDR Eval September 2002 and collection process. The behavior of the exporting process is controlled through means such as MIB or command line control, not specified by Streaming IPDR. Meyer Expires March 3, 2003 [Page 16] Internet-Draft Streaming IPDR Eval September 2002 4. Security Considerations Security can be accomplished by using either IPSec [9] or TLS [10] mechanisms when establishing the underlying TCP connection. This is the same security policy used by Diameter [11], sec (13.1 and 13.2) Because the use of IPSec and TLS are transparent to the from the perspective of TCP connection endpoints, the protocol specified here is unchanged. Meyer Expires March 3, 2003 [Page 17] Internet-Draft Streaming IPDR Eval September 2002 References [1] Quittek, J., "Requirements for IP Flow Information Export", IETF draft work in progress, August 2002, . [2] Meyer, J., "Reliable Streaming Internet Protocol Detail Records", IETF draft work in progress, August 2002, . [3] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML, May 2001, . [5] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML, May 2001, . [6] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1", April 2002, . [7] Srinivasan, R., "XDR: External Data Representation Standard", RFC 2026, August 1995, . [8] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, Sept. 2000, . [9] Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, Nov. 1998, . [10] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, Jan. 1999, . [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", draft Work in progress, Jul. 2002, . [12] Norseth, K. and P. Calato, "Data Model for IP Flow Information Export", IETF draft work in progress, August 2002, . Meyer Expires March 3, 2003 [Page 18] Internet-Draft Streaming IPDR Eval September 2002 [13] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . Author's Address Jeff Meyer Hewlett-Packard 19420 Homestead Rd. Cupertino, CA 95014 US Phone: +1 408 447-3477 EMail: jeff_meyer@hp.com URI: http://www.hp.com Meyer Expires March 3, 2003 [Page 19] Internet-Draft Streaming IPDR Eval September 2002 Appendix A. IPFIX IPDR Service Definition This proposal does not take into consideration possible IANA implications. The use of Namespaces as an extension mechanism implies that an IANA registered Namespace URI should be available and that directory names below this base URI be assigned for relevant IETF specifications. The author is not aware of this mechanism today. Alternatively IPDR.org could fulfill this role. The sample uses the IPDR.org namespace. The naming and content is lifted from the IPFIX Data Definition draft [12]. This document defines a subset of the identified IPFIX data model as XML Schema elements and complexTypes. This schema definition is compatable with the IPDR Service Definition format, enabling flow information to be represented as XML or binary documents. And defines the format used when streaming flow information to a recording system. IPv4 source address taken from the packet header. IPv6 source address taken from the packet header. Meyer Expires March 3, 2003 [Page 20] Internet-Draft Streaming IPDR Eval September 2002 IPv4 destination address taken from the packet header. IPv6 destination address taken from the packet header. Protocol number identified in the IP packet. In the Internet Protocol version 4 (IPv4) [RFC791] there is a field, called "Protocol", to identify the next level protocol. This is an 8 bit field. In Internet Protocol version 6 (IPv6) [RFC1883] this field is called the "Next Header" field. These numbers are administered by IANA. http://www.iana.org/assignments/protocol-numbers This information element is used to report UDP source port [see RFC 768] or TCP source port [see RFC 793] as taken from the IP header. This information element is used to report UDP destination port [see RFC 768] or TCP destination port [see RFC 793] as taken from Meyer Expires March 3, 2003 [Page 21] Internet-Draft Streaming IPDR Eval September 2002 the IP header. The ifIndex where the packets for the flow are being received. ifIndex is defined by RFC 2233. The ifIndex where the packets for the flow are exiting. ifIndex is defined by RFC 2233. Contains the count of packets sent and received associated with the identified flow. The packet count can be for packets received (towards source) or packets sent (towards destination) or both (bi-directional flow). The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. packets Contains the count of octets sent and received associated with the Meyer Expires March 3, 2003 [Page 22] Internet-Draft Streaming IPDR Eval September 2002 identified flow. The byte count can be for bytes received (towards source) or bytes sent (towards destination) or both (bi-directional flow). The byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. bytes The class of service associated with a flow. Class of Service Received Class of Service Transmitted 1. IPv4, CoS value is defined by ToS in RFC 791 2. IPv6, CoS value is defined by Traffic Class in RFC 2460 3. MPLS, CoS value is defined by Exp in RFC 3032 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p] The Flow Label information element contains the IPV6 Flow Label information as defined by RFC 2460. The timestamp of the first packet of the flow. Meyer Expires March 3, 2003 [Page 23] Internet-Draft Streaming IPDR Eval September 2002 The timestamp of the last packet of the flow.. The Autonomous System (AS) numbers for the source address associated with a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4): The Autonomous System (AS) numbers for the destination address associated wit a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). The Autonomous System (AS) numbers for the next hop IP. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). The TCP control bits seen for this flow. Note a 0 value for each bit only indicates that the flag was not detected (i.e. it may have occurred but was not detected by the reporting CCE). TCP Control Bits are defined by RFC 793. Meyer Expires March 3, 2003 [Page 24] Internet-Draft Streaming IPDR Eval September 2002 Source Exporter address is the address of the Exporter reporting the flow, Address is same as is as shown for Source Address. This information is used by applications to later correlate the ingress/egress port with a specific Exporter. It is also used to maintain the source Exporter information when there is an intermediate proxy. For example, given the picture below: SW1 -------- P1 ------ Collector ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the Collector [ is this the right term??? PAC] like the same Exporter connection. With the Source Exporter in the message the original Exporter address is maintained. Contains the count of packets dropped at the observation point associated with the identified flow. The dropped packet count can be a running counter and is the count from the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since the last report for this flow. packets Meyer Expires March 3, 2003 [Page 25] Internet-Draft Streaming IPDR Eval September 2002 When using Sampling, the rate at which packets is sampled. For example, a value of 100 indicates that one of every hundred packets is sampled. The type of algorithm used for sampling data. Currently, the only sampling algorithm defined is: 0x02 packet-sampling The reason the flow has ended. 1. Inactivity timeout 2. End of flow detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full [enumerations in IPDR service def schemas are recommended to be of form string, w/ integer values (for Compact format) defined via annotation] Contains the count of octets dropped at the observation point associated with the identified flow. The dropped byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. bytes Meyer Expires March 3, 2003 [Page 26] Internet-Draft Streaming IPDR Eval September 2002 Meyer Expires March 3, 2003 [Page 27] Internet-Draft Streaming IPDR Eval September 2002 Meyer Expires March 3, 2003 [Page 28] Internet-Draft Streaming IPDR Eval September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires March 3, 2003 [Page 29] --------------030601070109090407030203-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 3 13:16:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05576 for ; Tue, 3 Sep 2002 13:16:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17mGqE-00055a-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Sep 2002 11:47:50 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17mGqA-00054s-00; Tue, 03 Sep 2002 11:47:46 -0500 Received: from riverstonenet.com ([134.141.180.104]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 3 Sep 2002 09:47:05 -0700 Message-ID: <3D74E722.74B4F978@riverstonenet.com> Date: Tue, 03 Sep 2002 12:45:22 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: eval-team CC: ipfixx Subject: [ipfix] LFAP MIB Content-Type: multipart/mixed; boundary="------------D85A5C208432D71AE1FD5D55" X-OriginalArrivalTime: 03 Sep 2002 16:47:06.0222 (UTC) FILETIME=[896F00E0:01C25369] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------D85A5C208432D71AE1FD5D55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I forgot to submit the LFAP MIB with the other LFAP specifications. Since it is referenced in the advocate document I've attached it here. It should be on the ietf web page shortly. Paul --------------D85A5C208432D71AE1FD5D55 Content-Type: text/plain; charset=us-ascii; name="lfap_V5_MIB.txt" Content-Disposition: inline; filename="lfap_V5_MIB.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT Expires: March 2003 INTERNET-DRAFT Network Working Group P. Calato Request for Comments: M. MacFaden Category: Informational Riverstone Networks Inc Obsoletes: RFC 2124 September 2002 Category: Informational Light-weight Flow Accounting Protocol MIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document provides a description of MIB module that accompanies the LFAP Specifications [1][2]. Calato Informational [Page 1] INTERNET-DRAFT LFAP MIB August 2002 Table of Contents 1. MIB MODULE ........................................................3 2. REFERENCES .......................................................29 3. AUTHOR'S ADDRESS .................................................29 4. FULL COPYRIGHT STATEMENT .........................................29 Calato Informational [Page 2] INTERNET-DRAFT LFAP MIB August 2002 1. MIB Module #condInclude "rfc1155.inc" #condInclude "smiv2.inc" #condInclude "rfc2851.inc" #condInclude "rfc2571.inc" #include "mibs/rstn/91/rstone-smi-mib.txt" RIVERSTONE-LFAP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, TimeTicks, Counter32, Counter64, Gauge32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB riverstoneMibs froM RIVERSTONE-SMI-MIB rsLfapMIB MODULE-IDENTITY LAST-UPDATED "200208290000Z" ORGANIZATION "Riverstone Networks, Inc" CONTACT-INFO "Riverstone Networks, Inc 5200 Great America Parkway Santa Clara CA USA 95054 PHONE:+1 408.878.6500 EMAIL: nms-eng@riverstonenet.com WEB: http://www.riverstonenet.com" DESCRIPTION "This MIB module defines the management plane for the Lightweight Flow Accounting Protocol as defined in draft-riverstone-lfap-01.txt for devices implementing a Connection Control Entity (CCE). A FAS mib module will provide a management view of the Flow Accounting Server (FAS). This mib module is organized into three sections as follows: 1. CCE Diagnostics 2. CCE Configuration 3. CCE Protocol Monitoring Statistics Calato Informational [Page 3] INTERNET-DRAFT LFAP MIB August 2002 Copyright (C) Riverstone Networks, Inc 2001, 2002." REVISION "200208290000Z" DESCRIPTION "Updated to support LFAPv5 draft #1. Changes include adding reference clauses and improved descriptions to match terms as found in the protocol specification. Added new required counters and made three counters obsolete." REVISION "200106150000Z" DESCRIPTION "Indicate rsLfapServerStaticLastChanged, rsLfapStatsSessionChangedAt and rsLfapStatsLostAt are not supported in LFAPv4 in rsLfapAgentCompliance." REVISION "200106080000Z" DESCRIPTION "Add these objects MsgsUnknownTx, DropsInTxQueueWhenUp, MsgsInRxQueue, InvalidMsgsRx, MsgsUnknownRx into the StatsTable. Rename QueueDrops to DropsInTxQueue, LostPackets to TxLostPackets, LostOctets to TxLostOctets, QueuePeak to InTxQueuePeak. Changed the descriptions of the textual conventions and many of the objects. Rename ServerStatsTable to StatsTable." REVISION "200105070000Z" DESCRIPTION "Change the object identity of the traps to be v1 compliant. Change the previous revision comments. Make rsLfapActiveServer a scalar. Rename rsLfapStaticServerTable to rsLfapServerStaticTable. The objects in that table have also been renamed appropriately." REVISION "200105010000Z" DESCRIPTION "Move the scalars under rsLfapPerMon to a new table. rsLfapStatsTable. Add comformance. Reorganize tree. Rename some object identifiers." REVISION "200103030000Z" DESCRIPTION "Add both send and receive counters, add new counter for any unknown message types, clarify what lost timestamp counters and make MIB module support both implementation at CCE and FAS" REVISION "200102110000Z" DESCRIPTION Calato Informational [Page 4] INTERNET-DRAFT LFAP MIB August 2002 "Initial version of of Riverstone Flow Accounting MIB module for LFAPv4." ::= { riverstoneMibs 19 } rsLfapMIBObjects OBJECT IDENTIFIER ::= { rsLfapMIB 1 } rsLfapAgentState OBJECT IDENTIFIER ::= { rsLfapMIBObjects 1 } rsLfapAgentCfg OBJECT IDENTIFIER ::= { rsLfapMIBObjects 2 } rsLfapServerCfg OBJECT IDENTIFIER ::= { rsLfapMIBObjects 3 } rsLfapStats OBJECT IDENTIFIER ::= { rsLfapMIBObjects 4 } rsLfapDiag OBJECT IDENTIFIER ::= { rsLfapMIBObjects 5 } -- -- Textual conventions -- RSLfapErrorCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This represents the general error states the CCE will report." SYNTAX INTEGER { unknown(1), errorInConfig(2), resourceExhausted(3), errorNoServer(4) } RsLfapServerInst ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This number represents an external LFAP server (FAS) in the list of LFAP servers configured on the CCE. If the value is 0, then no FAS is indicated. While the base specification does not define a hard maximum limit of configured FAS addresses, this object defines one." SYNTAX Integer32 (1..32 | 0) RsTaskPriority ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This represents the relative priority of the CCE task relative to other tasks which share a common CPU resource." SYNTAX INTEGER { high(1), medium(2), low(3) } RSOperState ::= TEXTUAL-CONVENTION STATUS current Calato Informational [Page 5] INTERNET-DRAFT LFAP MIB August 2002 DESCRIPTION "This represents the operational state of the CCE will report. Where no specific state below applies, the CCE may report lfapUnknown(1). lfapNormal(2) represents the CCE is in a valid state as defined in section 6.4 State Diagrams for CCE. Should the CCE enter any of the paths defined in (A) through (E), then it should report lfapError(5). lfapTest(3) should be used when CCE is running self diagnostics. lfapDegraded(4) should not be used." SYNTAX INTEGER { lfapUnknown(1), lfapNormal(2), lfapTest(3), lfapDegraded(4), -- obsolete lfapError(5) } -- -- 1. CCE Diagostics Section -- rsLfapCapabilities OBJECT-TYPE SYNTAX BITS { rsLfapV4(0), rsLfapV5(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol versions supported in this CCE implementation." ::= { rsLfapAgentState 1 } rsLfapAdminState OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The intended administrative status of CCE. When set, the value true will start the CCE and false will stop the CCE. See rsLfapOperState for actual status" ::= { rsLfapAgentState 2 } rsLfapOperState OBJECT-TYPE SYNTAX RSOperState MAX-ACCESS read-only STATUS current Calato Informational [Page 6] INTERNET-DRAFT LFAP MIB August 2002 DESCRIPTION "The operational state of the CCE. See rsLfapAdminState as well." REFERENCE "6.4 State Diagrams, CCE State Machine for Connection Setup" ::= { rsLfapAgentState 3 } rsLfapLastError OBJECT-TYPE SYNTAX RSLfapErrorCode MAX-ACCESS read-only STATUS current DESCRIPTION "Current error status detected by the CCE." REFERENCE "6.4 State Diagrams, CCE State Machine for Connection Setup" ::= { rsLfapAgentState 4 } rsLfapLastErrorReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Current error reason detected by the CCE. This string is suitable for display to an operator." ::= { rsLfapAgentState 5 } rsLfapActiveServer OBJECT-TYPE SYNTAX RsLfapServerInst MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates which FAS is currently connected to the CCE." REFERENCE "4.1 FAS IP Address IE" ::= { rsLfapAgentState 6 } rsRunLfapSelfTest OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When set to true, CCE performs self diagsnostic of accounting subsystem. Requires object rsLfapAdminState to be set to false for set to succeed. Upon completion, rsLfapLastError will indicate test results and rsLfapLastErrorReason may contain any additional information to report." ::= { rsLfapDiag 1 } -- Calato Informational [Page 7] INTERNET-DRAFT LFAP MIB August 2002 -- 2. CCE Configuration Section -- rsLfapPollInterval OBJECT-TYPE SYNTAX Integer32 (1..1440) UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The rate to send flow setup/termination accounting information to the FAS. This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 15 } ::= { rsLfapAgentCfg 1 } rsLfapBatchSize OBJECT-TYPE SYNTAX Integer32 (1..2000) UNITS "records" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of records sent per batch to the FAS. This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 32 } ::= { rsLfapAgentCfg 2 } rsLfapBatchInterval OBJECT-TYPE SYNTAX Integer32 (1..2000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The time in seconds to send flow-create and flow-delete information to the FAS server. This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 1 } ::= { rsLfapAgentCfg 3 } rsLfapLostContactInterval OBJECT-TYPE SYNTAX Integer32 (20..2000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Amount of time to wait before considering the TCP connection lost. Calato Informational [Page 8] INTERNET-DRAFT LFAP MIB August 2002 This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 60 } ::= { rsLfapAgentCfg 4 } rsLfapServerRetryInterval OBJECT-TYPE SYNTAX Integer32 (1..2000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The rate at which to retry a connection to a FAS." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 60 } ::= { rsLfapAgentCfg 5 } rsLfapMaxTxQueueSize OBJECT-TYPE SYNTAX Integer32 (100..2000000) UNITS "message count" MAX-ACCESS read-write STATUS current DESCRIPTION "Number of messages that can be queued for transmit before messages are dropped. This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." DEFVAL { 50000 } ::= { rsLfapAgentCfg 6 } rsLfapTaskPriority OBJECT-TYPE SYNTAX RsTaskPriority UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Used as a hint to the task scheduler on the CCE in scheduling the CCE relative to other tasks on the CCE. This value persists across system restarts." REFERENCE "None, presently not defined in draft #01 spec." ::= { rsLfapAgentCfg 7 } -- CCE list of FAS servers to report to rsLfapServerStaticLastChanged OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last change Calato Informational [Page 9] INTERNET-DRAFT LFAP MIB August 2002 to any object in rsLfapServerStaticTable is made." ::= { rsLfapServerCfg 2 } rsLfapServerStaticTable OBJECT-TYPE SYNTAX SEQUENCE OF RsLfapServerStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to define which FAS server(s) the CCE will connect to when the operational state of CCE is lfapNormal(2)." REFERENCE "4.1 FAS IP Address IE" ::= { rsLfapServerCfg 3 } rsLfapServerStaticEntry OBJECT-TYPE SYNTAX RsLfapServerStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry would represent the configuration of an external FAS on the CCE. Rows added to this table persist across system restarts." INDEX { rsLfapServerStaticIndex } ::= { rsLfapServerStaticTable 1 } RsLfapServerStaticEntry ::= SEQUENCE { rsLfapServerStaticIndex RsLfapServerInst, rsLfapServerStaticAddressType InetAddressType, rsLfapServerStaticAddress InetAddress, rsLfapServerStaticStatus RowStatus } rsLfapServerStaticIndex OBJECT-TYPE SYNTAX RsLfapServerInst MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to index each LFAP server instance defined in this table. " ::= { rsLfapServerStaticEntry 1 } rsLfapServerStaticAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of address found in rsLfapServerStaticAddress. This value may not be modified if the rsLfapServerStaticStatus is active(1)." Calato Informational [Page 10] INTERNET-DRAFT LFAP MIB August 2002 ::= { rsLfapServerStaticEntry 2 } rsLfapServerStaticAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IPv4/6 address of a system acting as a FAS. This should no be a domain or hostnames but a valid IPv4 or IPv6 unicast address. This value may not be modified if the rsLfapServerStaticStatus is active(1)." ::= { rsLfapServerStaticEntry 3 } rsLfapServerStaticStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Install, modify, and delete rows in this table using this object. To modify a row, set this object to notInService(2)." ::= { rsLfapServerStaticEntry 4 } -- -- 3. CCE Protocol Monitoring Statistics -- rsLfapStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF RsLfapStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per FAS server. The protocol spec allows for only one set of counters for all FAS servers. If an implementation does not provide per FAS statistics, then this table only contains one row for the current server being used." REFERENCE "8.1 Common Statistics, 8.2 CCE Statistics" ::= { rsLfapStats 1 } rsLfapStatsEntry OBJECT-TYPE SYNTAX RsLfapStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Calato Informational [Page 11] INTERNET-DRAFT LFAP MIB August 2002 "On the CCE, each entry contains LFAP statistics collected by the CCE relating to a FAS. Each entry is indexed by the FAS server index (rsLfapServerStaticIndex)." INDEX { rsLfapServerStaticIndex } ::= { rsLfapStatsTable 1 } RsLfapStatsEntry ::= SEQUENCE { -- -- Connection statistics -- rsLfapStatsSessionUp TruthValue, rsLfapStatsSessionChangedAt TimeTicks, rsLfapStatsTcpConnects Counter32, rsLfapStatsTcpConnectFails Counter32, -- -- Protocol Statistics -- rsLfapStatsTxVRs Counter32, rsLfapStatsTxVRAs Counter32, rsLfapStatsTxFARs Counter32, rsLfapStatsTxFUNs Counter32, rsLfapStatsTxARAs Counter32, rsLfapStatsTxARs Counter32, rsLfapStatsMsgsInTxQueue Integer32, rsLfapStatsDropsInTxQueue Counter32, rsLfapStatsDropsInTxQueueWhenUp Counter32, rsLfapStatsRxVRs Counter32, rsLfapStatsRxVRAs Counter32, rsLfapStatsRxFARs Counter32, rsLfapStatsRxFUNs Counter32, rsLfapStatsRxARs Counter32, rsLfapStatsRxARAs Counter32, rsLfapStatsMsgsInRxQueue Integer32, rsLfapStatsInvalidMsgsRx Counter32, rsLfapStatsMsgsUnknownRx Counter32, -- -- Lost Accounting Information -- rsLfapStatsTxLostPackets Counter64, rsLfapStatsTxLostOctets Counter64, rsLfapStatsLostAt TimeTicks, -- -- Micro Flow Statistics Calato Informational [Page 12] INTERNET-DRAFT LFAP MIB August 2002 -- rsLfapStatsActiveFlows Counter32, rsLfapStatsFlowRate Gauge32, -- -- Peak -- rsLfapStatsActiveFlowsPeak Gauge32, rsLfapStatsMsgsInTxQueuePeak Gauge32, rsLfapStatsFlowsPeakTime TimeTicks, -- -- additional LFAPv5 protocol stats -- rsLfapVersionMismatchErrors Counter32, rsLfapSessionRxFERs Counter32, -- Session Establishments Accepted rsLfapStatsRxCRNs Counter32, rsLfapLostContacts Counter32, rsLfapTotalPackets Counter32, rsLfapTotalBytes Counter64, rsLfapProtocolViolations Counter32 } -- -- Connection statistics -- rsLfapStatsSessionUp OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the TCP connection between the CCE on the CCE and an external server (FAS) identified by rsLfapServerStaticIndex. If a connection from the CCE is established with the FAS ie it has reached Send State, then its value would be true. Otherwise it would be false." REFERENCE "6.4 State Diagrams, CCE State Machine for Connection Setup" ::= { rsLfapStatsEntry 1 } rsLfapStatsSessionChangedAt OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when rsLfapStatsSessionUp last changed state." Calato Informational [Page 13] INTERNET-DRAFT LFAP MIB August 2002 ::= { rsLfapStatsEntry 2 } rsLfapStatsTcpConnects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is the number of successul TCP connections the LFAP agent made to a FAS." ::= { rsLfapStatsEntry 3 } rsLfapStatsTcpConnectFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is the number of failed TCP connections attempts the CCE made to connect to a FAS." ::= { rsLfapStatsEntry 4 } -- -- Protocol Statistics -- rsLfapStatsTxVRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Version Request(VR) sent by the CCE to a FAS." ::= { rsLfapStatsEntry 5 } rsLfapStatsTxVRAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Version Request Acknowledge (VRA) sent." ::= { rsLfapStatsEntry 6 } rsLfapStatsTxFARs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Flow Activation Records (FAR) sent. TBD: specify ref clause." ::= { rsLfapStatsEntry 7 } Calato Informational [Page 14] INTERNET-DRAFT LFAP MIB August 2002 rsLfapStatsTxFUNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Flow Update Notification (FUN) sent." ::= { rsLfapStatsEntry 8 } rsLfapStatsTxARs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Administrative Request(AR) sent." ::= { rsLfapStatsEntry 9 } rsLfapStatsTxARAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Administrative Request Acknowledge (ARA) sent." ::= { rsLfapStatsEntry 10 } rsLfapStatsMsgsInTxQueue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of messages currently in the send queue." ::= { rsLfapStatsEntry 11 } rsLfapStatsDropsInTxQueue OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of messages dropped by the CCE in the transmitting queue for this FAS." ::= { rsLfapStatsEntry 12 } rsLfapStatsDropsInTxQueueWhenUp OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Calato Informational [Page 15] INTERNET-DRAFT LFAP MIB August 2002 DESCRIPTION "This object represents the number of messages dropped by the CCE in the send queue for this FAS while the connection between the CCE and the FAS is up." ::= { rsLfapStatsEntry 13 } rsLfapStatsRxVRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of VRs received." ::= { rsLfapStatsEntry 14 } rsLfapStatsRxVRAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of VRAs received." ::= { rsLfapStatsEntry 15 } rsLfapStatsRxFARs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of FARs received." ::= { rsLfapStatsEntry 16 } rsLfapStatsRxFUNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of FUNs received." ::= { rsLfapStatsEntry 17 } rsLfapStatsRxARs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of ARs received by the CCE from a FAS." ::= { rsLfapStatsEntry 18 } rsLfapStatsRxARAs OBJECT-TYPE SYNTAX Counter32 Calato Informational [Page 16] INTERNET-DRAFT LFAP MIB August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of ARAs received." ::= { rsLfapStatsEntry 19 } rsLfapStatsMsgsInRxQueue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of messages currently in the receive queue." ::= { rsLfapStatsEntry 20 } rsLfapStatsInvalidMsgsRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the sum of corrupt and erroneous messages received." ::= { rsLfapStatsEntry 21 } rsLfapStatsMsgsUnknownRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of unknown LFAP message types received." ::= { rsLfapStatsEntry 22 } rsLfapStatsTxLostPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The count of packets not accounted for and thus not recorded by the LFAP server." ::= { rsLfapStatsEntry 23 } rsLfapStatsTxLostOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The count of octets not accounted for and thus not recorded by the LFAP server." ::= { rsLfapStatsEntry 24 } Calato Informational [Page 17] INTERNET-DRAFT LFAP MIB August 2002 rsLfapStatsLostAt OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS obsolete DESCRIPTION "On the CCE, the sysUpTime when the LFAP agent last lost trasmitted FAR/FUN messages. On the FAS, it would be the last time when the server lost received FAR/FUN messages." ::= { rsLfapStatsEntry 25 } -- -- Flow Statistics -- rsLfapStatsActiveFlows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of active flows being tracked per FAS." ::= { rsLfapStatsEntry 26 } rsLfapStatsFlowRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of flows being setup per second. This value is calculated as an exponentially decaying average over 30 second intervals" ::= { rsLfapStatsEntry 27 } rsLfapStatsActiveFlowsPeak OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "High water mark for number of active flows being tracked by LFAP." ::= { rsLfapStatsEntry 28 } rsLfapStatsMsgsInTxQueuePeak OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "High water mark for queue depth." ::= { rsLfapStatsEntry 29 } rsLfapStatsFlowsPeakTime OBJECT-TYPE Calato Informational [Page 18] INTERNET-DRAFT LFAP MIB August 2002 SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when max number of flows being reported on was reached." ::= { rsLfapStatsEntry 30 } rsLfapVersionMismatchErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times CCE or FAS did not agree on LFAP version." ::= { rsLfapStatsEntry 31 } rsLfapSessionRxFERs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times either a CCE or FAS reached the Send State as indicated in the state diagrams. In summary, a CCE receives a FER message or a FAS sends an FER message." ::= { rsLfapStatsEntry 32 } rsLfapStatsRxCRNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a CCE has received a CRN message or a FAS has sent a CRN message." ::= { rsLfapStatsEntry 33 } rsLfapLostContacts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a CCE or FAS lost the session while in the Send State. For a CCE, this includes Message timeout, Lost TCP session, or KA timeout. For a FAS, it includes Message timeout and Lost TCP." ::= { rsLfapStatsEntry 34 } Calato Informational [Page 19] INTERNET-DRAFT LFAP MIB August 2002 rsLfapTotalPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets excluding written to TCP session since TCP session was opened." ::= { rsLfapStatsEntry 35 } rsLfapTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes excluding written to TCP session since TCP session was opened. FAS keeps this counter per CCE." ::= { rsLfapStatsEntry 36 } rsLfapProtocolViolations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of valid messages received but considered invalid in the current CCE or FAS state." ::= { rsLfapStatsEntry 38 } -- scalars rsLfapEstablishSessFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times the CCE attempted to connect to each of the FAS it was configured with in succession without success. It includes cases where a DR with an alternate FAS was also tried." REFERENCE "8.2 CCE Statistics - Failed to establish a session to any server" ::= { rsLfapStats 2 } rsLfapDroppedMessages OBJECT-TYPE SYNTAX Counter32 Calato Informational [Page 20] INTERNET-DRAFT LFAP MIB August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of FAR or FUN messages the CCE could not be transmitted to the FAS while not in Send State." REFERENCE "8.2 CCE Statistics - Number of bytes not accounted for due to dropped messages" ::= { rsLfapStats 3 } rsLfapDroppedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes not accounted for due to dropped messages A count of the number of bytes accounted for in FUN messages being dropped that CCE could not transmit to the FAS while in Send State." REFERENCE "8.2 CCE Statistics - Number of packets not accounted for due to dropped messages" ::= { rsLfapStats 4 } rsLfapLastDroppedBytes OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Value of sysUpTime when last message whas dropped while not in Send State." REFERENCE "8.2 CCE Statistics - Time of last dropped message" ::= { rsLfapStats 5 } -- -- CCE Notifications -- rsLfapMIBEvents OBJECT IDENTIFIER ::= { rsLfapMIB 2 } rsLfapMIBEventsPrefix OBJECT IDENTIFIER ::= { rsLfapMIBEvents 0 } rsLfapNoServer NOTIFICATION-TYPE OBJECTS { rsLfapStatsSessionChangedAt, rsLfapStatsTcpConnectFails } STATUS current DESCRIPTION "The CCE has tried to connect to all servers in rsLfapStatsServerStaticTable and has failed." Calato Informational [Page 21] INTERNET-DRAFT LFAP MIB August 2002 ::= { rsLfapMIBEventsPrefix 1 } rsLfapLostMessage NOTIFICATION-TYPE OBJECTS { rsLfapStatsSessionChangedAt, rsLfapStatsLostAt, rsLfapStatsSessionUp } STATUS current DESCRIPTION "When a CCE first drops messages due to no connected server, send this event. No more additional events are sent until the value of rsLfapStatsSessionChangedAt value has changed." ::= { rsLfapMIBEventsPrefix 2 } rsLfapQueueFull NOTIFICATION-TYPE OBJECTS { rsLfapStatsDropsInTxQueue, rsLfapMaxTxQueueSize, rsLfapStatsSessionUp } STATUS current DESCRIPTION "Accounting data may be lost when the CCE's message queue reaches capacity as defined by rsLfapMaxTxQueueSize. rsLfapStatsSessionUp can indicate if this is happening due to no FAS to send to currently. A second case is where the rate of inserts into the queue exceeds the rate at which the FAS is processing them. This can be caused by flow control of the underlying TCP session. Send only one rsLfapStatsQueueFull notification per every 1000 dropped messages or after a change in the value of rsLfapStatsSessionUp for the current FAS." ::= { rsLfapMIBEventsPrefix 3 } -- Conformance Information rsLfapConformance OBJECT IDENTIFIER ::= { rsLfapMIB 3 } rsLfapCompliances OBJECT IDENTIFIER ::= { rsLfapConformance 1 } rsLfapGroups OBJECT IDENTIFIER ::= { rsLfapConformance 2 } -- Compliance Statements rsLfapAgentCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "This compliance statement for implementing this MIB on Calato Informational [Page 22] INTERNET-DRAFT LFAP MIB August 2002 the CCE. Some objects also do not need to be implemeted if the CCE is v4." MODULE -- this module MANDATORY-GROUPS { rsLfapAgentStateGroup, rsLfapAgentCfgGroup, rsLfapServerStaticGroup, rsLfapStatsGroup } GROUP rsLfapDiagGroup DESCRIPTION "The diag object in this group is new. Implementation of this group for version 4 is not necessary." GROUP rsLfapNotificationGroup DESCRIPTION "These notifications are new. Implementation of this group for version 4 is not necessary." OBJECT rsLfapStatsTxVRAs MIN-ACCESS not-accessible DESCRIPTION "This object is not supported by the CCE on the CCE. The CCE would not send a Version Request Acknoledge(VRA) message to a FAS." OBJECT rsLfapStatsRxVRs MIN-ACCESS not-accessible DESCRIPTION "This object is not supported by the CCE on the CCE. A FAS does not send Version Request(VR) messages to the CCE." OBJECT rsLfapStatsRxFARs MIN-ACCESS not-accessible DESCRIPTION "This object is not supported by the CCE on the CCE. A FAS does not send FAR messages to the CCE." OBJECT rsLfapStatsRxFUNs MIN-ACCESS not-accessible DESCRIPTION "This object is not supported by CCE on the CCE. The FAS does not send FUN messages to the CCE." OBJECT rsLfapServerStaticLastChanged MIN-ACCESS not-accessible DESCRIPTION Calato Informational [Page 23] INTERNET-DRAFT LFAP MIB August 2002 "This object is not supported in LFAP v4." OBJECT rsLfapStatsSessionChangedAt MIN-ACCESS not-accessible DESCRIPTION "This object is not supported in LFAP v4." OBJECT rsLfapStatsLostAt MIN-ACCESS not-accessible DESCRIPTION "This object is not supported in LFAP v4." OBJECT rsLfapStatsFlowsPeakTime MIN-ACCESS not-accessible DESCRIPTION "This object is not supported in LFAP v4." OBJECT rsLfapStatsFlowRate MIN-ACCESS not-accessible DESCRIPTION "This object is not supported in LFAP v4." ::= { rsLfapCompliances 1 } rsLfapV5Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This compliance statement for implementing this MIB module on for a v5 CCE." MODULE -- this module MANDATORY-GROUPS { rsLfapAgentStateGroup, rsLfapAgentCfgGroup, rsLfapServerStaticGroup, rsLfapV5StatsGroup } ::= { rsLfapCompliances 2 } -- object grouping clauses for compliant implementions rsLfapAgentStateGroup OBJECT-GROUP OBJECTS { rsLfapCapabilities, rsLfapAdminState, rsLfapOperState, rsLfapLastError, rsLfapLastErrorReason, rsLfapActiveServer Calato Informational [Page 24] INTERNET-DRAFT LFAP MIB August 2002 } STATUS current DESCRIPTION "The collection of objects used to represent the desired and actual operational state of the CCE." ::= { rsLfapGroups 1 } rsLfapAgentCfgGroup OBJECT-GROUP OBJECTS { rsLfapPollInterval, rsLfapBatchSize, rsLfapBatchInterval, rsLfapLostContactInterval, rsLfapServerRetryInterval, rsLfapMaxTxQueueSize, rsLfapTaskPriority } STATUS current DESCRIPTION "The collection of objects used to represent the configuration of LFAP protocol in a given CCE." ::= { rsLfapGroups 2 } rsLfapServerStaticGroup OBJECT-GROUP OBJECTS { rsLfapServerStaticLastChanged, rsLfapServerStaticAddressType, rsLfapServerStaticAddress, rsLfapServerStaticStatus } STATUS current DESCRIPTION "The collection of objects used to represent the configuration of the address of FAS in CCE." ::= { rsLfapGroups 3 } rsLfapStatsGroup OBJECT-GROUP OBJECTS { rsLfapStatsSessionUp, rsLfapStatsSessionChangedAt, rsLfapStatsTcpConnects, rsLfapStatsTcpConnectFails, rsLfapStatsTxVRs, rsLfapStatsTxVRAs, rsLfapStatsTxFARs, rsLfapStatsTxFUNs, rsLfapStatsTxARs, rsLfapStatsTxARAs, Calato Informational [Page 25] INTERNET-DRAFT LFAP MIB August 2002 rsLfapStatsMsgsInTxQueue, rsLfapStatsDropsInTxQueue, rsLfapStatsDropsInTxQueueWhenUp, rsLfapStatsRxVRs, rsLfapStatsRxVRAs, rsLfapStatsRxFARs, rsLfapStatsRxFUNs, rsLfapStatsRxARs, rsLfapStatsRxARAs, rsLfapStatsMsgsInRxQueue, rsLfapStatsInvalidMsgsRx, rsLfapStatsMsgsUnknownRx, rsLfapStatsTxLostPackets, rsLfapStatsTxLostOctets, rsLfapStatsLostAt, rsLfapStatsActiveFlows, rsLfapStatsFlowRate, rsLfapStatsActiveFlowsPeak, rsLfapStatsMsgsInTxQueuePeak, rsLfapStatsFlowsPeakTime } STATUS obsolete DESCRIPTION "The collection of objects for LFAPv4/CCE" ::= { rsLfapGroups 4 } rsLfapDiagGroup OBJECT-GROUP OBJECTS { rsRunLfapSelfTest } STATUS current DESCRIPTION "The collection of objects used to represent CCE/LFAP diagnostics." ::= { rsLfapGroups 5 } rsLfapNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { rsLfapNoServer, rsLfapLostMessage, rsLfapQueueFull } STATUS current DESCRIPTION Calato Informational [Page 26] INTERNET-DRAFT LFAP MIB August 2002 "The collection of notifications for LFAP MIB." ::= { rsLfapGroups 6 } rsLfapV5StatsGroup OBJECT-GROUP OBJECTS { rsLfapStatsSessionUp, rsLfapStatsSessionChangedAt, rsLfapStatsTcpConnects, rsLfapStatsTcpConnectFails, rsLfapStatsTxVRs, rsLfapStatsTxVRAs, rsLfapStatsTxFARs, rsLfapStatsTxFUNs, rsLfapStatsTxARs, rsLfapStatsTxARAs, rsLfapStatsMsgsInTxQueue, rsLfapStatsDropsInTxQueue, rsLfapStatsDropsInTxQueueWhenUp, rsLfapStatsRxVRs, rsLfapStatsRxVRAs, rsLfapStatsRxFARs, rsLfapStatsRxFUNs, rsLfapStatsRxARs, rsLfapStatsRxARAs, rsLfapStatsMsgsInRxQueue, rsLfapStatsInvalidMsgsRx, rsLfapStatsMsgsUnknownRx, rsLfapStatsActiveFlows, rsLfapStatsFlowRate, rsLfapStatsActiveFlowsPeak, rsLfapStatsMsgsInTxQueuePeak, rsLfapStatsFlowsPeakTime, rsLfapVersionMismatchErrors, rsLfapSessionRxFERs, rsLfapStatsRxCRNs, rsLfapLostContacts, rsLfapTotalPackets, rsLfapTotalBytes, rsLfapProtocolViolations, rsLfapEstablishSessFailures, rsLfapDroppedMessages, rsLfapDroppedBytes, Calato Informational [Page 27] INTERNET-DRAFT LFAP MIB August 2002 rsLfapLastDroppedBytes } STATUS current DESCRIPTION "The collection of objects used to represent the statistics of a CCE for Version 5 of LFAP." ::= { rsLfapGroups 7 } END Calato Informational [Page 28] INTERNET-DRAFT LFAP MIB August 2002 2. References [1] "Light-weight Flow Accounting Protocol Specification Version 5.0" draft-riverstone-lfap-01.txt, June 2002 [2] "LFAP Data Definition Specification", draft-riverstone-lfap-data-01.txt. June 2002 3. Author's Address Paul Calato Phone: +1 (603) 738-4206 Email: calato@riverstonenet.com Mike MacFaden Phone: +1 (408) 878-6525 Email: mrm@riverstonenet.com Riverstone Networks, Inc. is located at: 5200 Great America Parkway Santa Clara, CA 95054 USA 4. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 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. Calato Informational [Page 29] --------------D85A5C208432D71AE1FD5D55-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 3 15:22:52 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10490 for ; Tue, 3 Sep 2002 15:22:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17mJ8W-0000km-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Sep 2002 14:14:52 -0500 Received: from h213.p072.iij4u.or.jp ([210.130.72.213] helo=roam.psg.com ident=exim) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17mJ8T-0000kd-00; Tue, 03 Sep 2002 14:14:50 -0500 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mJ8O-0002oT-00; Tue, 03 Sep 2002 12:14:44 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: calato@riverstonenet.com Cc: eval-team , ipfixx Subject: Re: [ipfix] LFAP MIB References: <3D74E722.74B4F978@riverstonenet.com> Message-Id: Date: Tue, 03 Sep 2002 12:14:44 -0700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit has the internet-drafts publication process broken? why are people posting entire drafts to a mailing list? please stop! randy, on a slow ppp dialup overseas -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 3 15:31:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11033 for ; Tue, 3 Sep 2002 15:31:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17mJCT-0000tM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Sep 2002 14:18:57 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17mJCR-0000sc-00; Tue, 03 Sep 2002 14:18:55 -0500 Received: from riverstonenet.com ([134.141.180.104]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 3 Sep 2002 12:18:23 -0700 Message-ID: <3D750A98.52875B7A@riverstonenet.com> Date: Tue, 03 Sep 2002 15:16:40 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: eval-team , ipfixx Subject: Re: [ipfix] LFAP MIB References: <3D74E722.74B4F978@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2002 19:18:24.0708 (UTC) FILETIME=[ACA20840:01C2537E] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit The deadline was 9/2 for drafts to go to the eval team. As usual, most if us waited til the last minute. Sorry about that. Paul Randy Bush wrote: > > has the internet-drafts publication process broken? why are people > posting entire drafts to a mailing list? please stop! > > randy, on a slow ppp dialup overseas -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 3 15:45:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11899 for ; Tue, 3 Sep 2002 15:45:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17mJUA-0001KB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Sep 2002 14:37:14 -0500 Received: from pool-129-44-37-106.ny325.east.verizon.net ([129.44.37.106] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17mJU7-0001K1-00 for ipfix-req@net.doit.wisc.edu; Tue, 03 Sep 2002 14:37:11 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g83JavN14314; Tue, 3 Sep 2002 15:36:57 -0400 From: "Carter Bullard" To: , "'Benoit Claise'" Cc: "'Juergen Quittek'" , "'req'" Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Date: Tue, 3 Sep 2002 15:36:48 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A43B@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660A852B@ptah.newyork.qosient.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle People, An unambiguous way of referring to the fragment most likely to contain flow identifying information is to refer to the "zero offset fragment". It is not correct to assume, however, that all the information needed to track a standard 5-tuple flow is in the zero offset fragment, as the algorithm allows fragmentation to occur within the TCP header. While there are RFC's that suggest that this should not be allowed, some routers still can fragment at the destination port field boundary. I believe that a paragraph that talks about fragmentation should mention that some reassembly may be required. Carter Carter Bullard QoSient, LLC 300 E. 56th Street Suite 18K New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Friday, August 30, 2002 10:14 AM > To: Benoit Claise > Cc: Juergen Quittek; req > Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX > Requirements Questions) > > > Benoit Claise wrote: > > > > Paul, Juergen and all, > > > > >Benoit Claise wrote: > > > > > > > > >>Paul and Juergen, > > >> > > >> > > >> > > >>>Hi Paul, > > >>> > > >>>--On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > > >>> > > >>> > > >>> > > >>>>Juergen Quittek wrote: > > >>>> > > >>>> > > >>>> > > >>>>>Hi Paul, > > >>>>> > > >>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Juergen Quittek wrote: > > >>>>>> > > >>>>>> > > >>>>>>>--On 27 August 2002 14:49 -0400 > calato@riverstonenet.com wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>As I work on the advocates document some questions > have come > > >>>>>>>>to mind on the requirements document. > > >>>>>>>> > > >>>>>>>>4.3 Distinguishing flows using Transport Header Fields > > >>>>>>>> > > >>>>>>>> In the case of fragmented packets there are > > >>>>>>>> no port numbers. Are we saying flow state information > > >>>>>>>> MUST be maintained? In general, it is not clear from > > >>>>>>>> > > >>>>>>>> > > >>>>>>>No, the requirements document does not say so. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> the document what the requirements are for fragmented > > >>>>>>>> packets. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>I think the requirements should not include a > requirement for > > >>>>>>>keeping state of fragmented packets. Would you like > to see an > > >>>>>>>explicit statement on that? This would be a NO NEED FOR > > >>>>>>>statement :-) > > >>>>>>> > > >>>>>>> > > >>>>>> I think we need to be explicit. Most people will think > > >>>>>> of fragements as being counted in the same flow as the > > >>>>>> first packet not as 2 differernt flows. > > >>>>>> > > >>>>>> > > >>>>>I see. Waht about adding a new subsection to Section > "5. Metering > > >>>>>Process": > > >>>>> > > >>>>>5.8. Packet Fragmentation > > >>>>> > > >>>>> In case of IP packet fragmentation, only one > fragment of a single > > >>>>> packet might contain sufficient information for > classifying the > > >>>>> packet correctly. The metering process MAY keep state of > > >>>>> IP packet fragmentation in order to map fragments > that do not > > >>>>> contain sufficient header information correctly to flows. > > >>>>> > > >>>>> > > >>>> How about a slight re-wording... > > >>>> > > >>>> In case of IP datagram fragmentation, only the > first fragment might > > >>>> contain sufficient information for classifying the > packet correctly. > > >>>> The metering process MAY keep state of IP > fragmentation in order to > > >>>> map fragments without sufficient header information > to the same > > >>>> flow as the first fragmented packet. > > >>>> > > >>>> > > >>>Initially I also wanted to phrase like this. But it's IP. And > > >>>fragments might get re-ordered. The first fragment of a > packet that > > >>>is observed, is not necessarily the fragment containing > the TCP/UDP > > >>>header. > > >>> > > >>>Now, if you say "first", it is not clear whether you mean the > > >>>fragment with the first bytes of the IP payload or the first > > >>>fragment observed at the observation point. Your last sentence > > >>>seems to assume that the first observed packet is the > one with the > > >>>first bytes of the payload. > > >>> > > >>> > > >>Why not merge your 2 texts: > > >> > > >> In case of IP packet fragmentation, only one fragment > of the initial > > >> packet might contain sufficient information for > classifying the > > >> packet correctly. Note that this fragment is the first > one generated > > >> by the router imposing the fragmentation, but might > not be the first > > >> one observed by the IPFIX device, due reordering reasons. > > >> The metering process MAY keep state of IP packet fragmentation > > >> in order to map fragments that do not contain sufficient header > > >> information correctly to flows. > > >> > > >> > > >> > > > > > > Juergen suggested a merged text. Are you suggesting > > > an alternative? > > > > > To summarize: > > > > Juergen proposed: > > In case of IP datagram fragmentation, for many typical > > classification schemes, only one fragment contains > > sufficient information to classify the packet. > ^^^^^^ > fragment > > With the above change I think this is clear and easy to read. > > > > > > I proposed above: > > > > In case of IP packet fragmentation, only one fragment of > the initial > > packet might contain sufficient information for classifying the > > packet correctly. Note that this fragment is the first > one generated > > by the router imposing the fragmentation, but might not > be the first > > one observed by the IPFIX device, due reordering reasons. > > The metering process MAY keep state of IP packet fragmentation > > in order to map fragments that do not contain sufficient header > > information correctly to flows. > > This one is OK but goes into explanation I'm not sure > is necessary if you assume familiarity with IP. > > Also, there are 3 terms "initial packet", "packet" > and "fragment". So I get a bit lost. > > But either way will suffice as far as I'm concerned. > > > > > > I think both of them express the same idea. > > The second one maybe contains some more clarifications. > > > > So I'm not really in favor of one or the other. Choose the one that > > you want to. > > > > I'm not sure what were your conclusions for fragmentation > and section > > "6.1 Information Model" > > > > 1. Have something like (implicitely talking about fragmentation): > > 9. packet counter > > Which packets are counted MUST be defined exactly. > > 10. byte counter > > Which bytes of a packet are counted MUST be > defined exactly. > > Which bytes are counted is a legitimate issue. Do we include > ethernet headers, IP headers, CRC, etc...In other words some > bytes are never counted under ANY circumstances. > > I don't see similar issues for the packet counter. > > As soon as you start talking about which flow a packet gets > counted against, it is a "Distinguishing Properties" issue. > If you talk about what flows get counted it is a > configuration issue. > > The question on fragment is are they distinguished by the > full header information or just a subset. > > > > > OR > > > > 2. > > 9. packet counter > > Which packets are counted MUST be defined exactly. > > 10. byte counter > > Which bytes of a packet are counted MUST be > defined exactly. > > And an extra sentence about fragmentation. "The behavior of > the byte > > and packet counters in case of IP packet fragmentation MUST > be clearly > > defined." > > > > Regards, Benoit. > > > > > > > > > > > > > >>> > > >>> > > >>>>> [...] > > >>>>> > > >>>>> > > >>>>> > > >>>>>>>>6.1 information Model > > >>>>>>>> > > >>>>>>>> 9 Packet Counter > > >>>>>>>> 10 Byte counter > > >>>>>>>> > > >>>>>>>> As mentioned earlier, for fragments this > > >>>>>>>> requires state information? If there is no > > >>>>>>>> state info, then what flow are the counted > > >>>>>>>> towards? > > >>>>>>>> > > >>>>>>>> > > >>>>>>>Do you suggest to include a requirement for keeping fragment > > >>>>>>> > > >>>>>>> > > >>>>>state info? > > >>>>> > > >>>>> > > >>>>>> A MAY is as far as I would go. There may > certainly be probes > > >>>>>> that have this capability. We should have a > requirement that > > >>>>>> says fragment counting MUST be clearly defined. > > >>>>>> > > >>>>>> > > >>>>>OK. Currently, we have > > >>>>> > > >>>>> 9. packet counter > > >>>>> If a packet is fragmented, each fragment is > counted as an > > >>>>> individual packet. > > >>>>> 10. byte counter > > >>>>> Which bytes of a packet are counted MUST be defined > > >>>>> exactly. > > >>>>> > > >>>>>What about appending > > >>>>> > > >>>>> The behavior of the byte counter in case of IP packet > > >>>>> fragmentation MUST be clearly defined. > > >>>>> > > >>>>> > > >>>> With the new section on fragmentation I think we can > > >>>> eliminate any mention of it on the counters. > > >>>> > > >>>> > > >>>The new section of the fragmentation is a MAY > requirement. But for > > >>>understamding the behavior of the byte counter you MUST know > > >>>whether or not the option is implemented. > > >>> > > >>> > > >>So, haven't we enough with "The behavior of the byte and packet > > >>counters in case of IP packet fragmentation MUST be clearly > > >>defined."? We need the packet counter in the sentence above: to > > >>know if the flow state information is maintained for fragemented > > >>packets > > >> > > >> > > >> > > >>> > > >>> > > >>>>>? > > >>>>> > > >>>>>Please note that we also have in the MAY attributes section > > >>>>> > > >>>>> 26. fragmented packet counter > > >>>>> counter of all packets for which the > fragmented bit is set in > > >>>>> the IP header > > >>>>> > > >>>>> > > >>>> I'm not sure why this was added. If you want that info, > > >>>> make the IP fragment bit part of the flow definition. > > >>>> > > >>>> > > >>It makes sense. > > >> > > >>Regards, Benoit > > >> > > >> > > >> > > >>>Do you suggest to remove it? Anyone else? > > >>> > > >>> > > >>> Juergen > > >>> > > >>> > > >>> > > >>>-- > > >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > >>>message body > > >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > > >>>ipfix" in message body > > >>>Archive http://ipfix.doit.wisc.edu/archive/ > > >>> > > >>> > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 4 10:39:23 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02325 for ; Wed, 4 Sep 2002 10:39:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17mb4k-0006LV-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Sep 2002 09:24:10 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17mb4j-0006LH-00 for ipfix-req@net.doit.wisc.edu; Wed, 04 Sep 2002 09:24:09 -0500 Received: from riverstonenet.com ([134.141.180.104]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 4 Sep 2002 07:23:36 -0700 Message-ID: <3D761701.E5986839@riverstonenet.com> Date: Wed, 04 Sep 2002 10:21:53 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: req Subject: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2002 14:23:36.0731 (UTC) FILETIME=[A830AEB0:01C2541E] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I wanted to summarize where we are with the issues I raised a while back. A few still need to be resolved. calato@riverstonenet.com wrote: > > As I work on the advocates document some questions > have come to mind on the requirements document. > > 4.3 Distinguishing flows using Transport Header Fields > > In the case of fragmented packets there are > no port numbers. Are we saying flow state information > MUST be maintained? In general, it is not clear from > the document what the requirements are for fragmented > packets. RESOLVED: State information MAY be kept for proper flow designation. > > 4.4 MPLS Label > > In the case of dynamic LSP's the label is not useful. > Why require distinguishing flows based on label. > What can be done with that information? RESOLVED: We agreed to distinguish by label and to report label. > > 5.3 Overload Behavior > > This section needs to be re-worked a little. Some > of the MUST's impose undue burden on the device. > > 1. Must distinguish flow records before and after the > behavior change. > > In the case where the behavior is to drop > overflow flows, why do we need to distinguish > flows. Perhaps I misunderstood something. > > 2. All flows from previous behavior MUST be terminated. > > > Again, if I simply dropped excess flows why terminate > all existing ones. This will likely cause more overflow > as the get reestablished. This also seems to go to > far towards implementation. > > 3. Meeting process MUST NOT merge previous records. > > I think what we are trying to say is flows with a different > definition MUST be distinguishable. How that is done is not > part of the requirements doc. OPEN We agreed that not all behaviors require terminating flows. We still need more dialogue on the following 1. Do we need to define a term for the set of properties that is used to distinguish flows. 2. Do we need to require that flows can be mapped to the term defined in #1 > > 5.4 Timestamps > > Time stamps to not always mapped to the first packet and last > packet. In many cases, the end timestamp is merely when > the flow timed out and has nothing to do with when the > last packet was seen. Allowing both semantics may be useful. > A re-wording like this... > > The metering process MUST be able to generate timestamps for the > start and end of a flow. The metering process MAY also provide > timestamps for the first and the last observed packet > of a flow. The timestamp resolution MUST be at least the one of > the sysUpTime [RFC1213], which is one centisecond. > > Note - this does not mandate 2 timestamp fields for a flow. You > could have one element for each meaning (e.g. Flow-start-time, > first-packet-time, flow-start-and-first-packet-time) and use > the one with the desired meaning. OPEN This issue still needs more dialogue to gain clarity. Ganesh believes it is possible to detect last packet time within msec accuracy. I believe it is not possible without hardware assist and not all platform will have that capability. > > 6.1 information Model > > 9 Packet Counter > 10 Byte counter > > As mentioned earlier, for fragments this > requires state information? If there is no > state info, then what flow are the counted > towards? RESOLVED(I think): no mention needs to me made in the packet or byte counter section since fragment counting is a matter for flow designation. > > 13 BGP AS number > > Is this the AS number for the observation point, the > source/destination address in the packet or some > combination? RESOLVED: These MAY be reported. 1. Source IP AS 2. Destination IP AS 3. Observation Point AS (which may be a a list if it participates on more than one) I would like to propose 2 more Next hop AS previous hop AS > > 14. MPLS Label > > As stated earlier, in the case of dynamic LSP's the > label has no meaning. > > 21 multicast replication number > > The document stated this can change over the life > of the flow. But no mention of what happens when > it changes. Is that a new flow? If not, what meaning > does it have when reported? What can I do with it? RESOLVED: If a new flow is desired, it becomes part of the "Distinguishing Properties". If not, then it can still be reported and ignored when it changes. > > > 6.2 Data Model > > What about allowing Vendors to add information independently? > Some data to be transported may be vendor specific and never > make it into the IPFIX spec. RESOLVED: It is allowed now and we do not need to mention it specifically. > > 8.3 Several Collecting Processes > > No mention is made when reporting to several devices > of ensuring the duplicate data does not cause a double > counting problem. RESOLVED: This requirement needs to be added. > > 9. Special Device Considerations > > I'm not sure of the meaning for the following... > > ... > > Please note that here, the observation > point of a single flow cannot exceed the set of most fine-granular > observation points linked to a single metering process, because only > the metering process can merge packets observed at different fine- > granular observation points to a joint flow. > > ... > > Also the > locations of metering processes are not of any relevance for this > document (in contrast to the locations of observation points and the > exporting processes). > These were just for my understanding. > Paul -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 4 18:18:15 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23404 for ; Wed, 4 Sep 2002 18:18:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17miIm-0003zY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Sep 2002 17:07:09 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17miIl-0003zR-00 for ipfix@net.doit.wisc.edu; Wed, 04 Sep 2002 17:07:07 -0500 Date: Wed, 4 Sep 2002 17:07:07 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX mailing list search engine, and eval drafts Message-ID: <20020904170707.D24016@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-E-NOSUCHOBJECT, specified object does not exist X-Shakespearean-Insult: Thou fobbing bat-fowling malt-worm Precedence: bulk Sender: majordomo listserver IPFIX folks, In response to requests from participants and in an effort to be a better reference during the evaluation process, the IPFIX web site ("http://ipfix.doit.wisc.edu/") has been updated in the following ways: 1) Search Engine for Mailing List Archive There is now a search engine for the mailing list archive. It is available here: http://ipfix.doit.wisc.edu/cgi-bin/search-ipfix-archive.cgi and is linked from this section of the main page: http://ipfix.doit.wisc.edu/#Mailing_List_Archive 2) Protocol Evaluation Drafts The five protocol evaluation drafts are now mirrored daily here: http://ipfix.doit.wisc.edu/eval/ Since we expect these drafts to be updated a number of times as we work through the evaluation process, I have attempted to automate the updates to the list of URLs of the current eval draft revisions in this section of the main page: http://ipfix.doit.wisc.edu/#IPFIX_related_Internet_Drafts_an Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 5 17:43:39 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08136 for ; Thu, 5 Sep 2002 17:43:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17n4Cr-0007jX-00 for ipfix-list@mil.doit.wisc.edu; Thu, 05 Sep 2002 16:30:29 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17n4Cj-0007fv-00 for ipfix-eval@net.doit.wisc.edu; Thu, 05 Sep 2002 16:30:21 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g85LSeM08784 for ; Thu, 5 Sep 2002 16:28:40 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 14:28:26 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C03C57DF3@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] Change of email Date: Thu, 5 Sep 2002 14:28:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25523.2B68F8D2" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25523.2B68F8D2 Content-Type: text/plain; charset="iso-8859-1" Sorry for the previous message to this list listing only 3 candidates. My external alias (which I use on this list) stopped working and I didn't receive any message for a couple of weeks. I hope everything is fixed now. regards, Reinaldo ------_=_NextPart_001_01C25523.2B68F8D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Change of email

Sorry for the previous message to this list listing = only 3 candidates. My external alias (which I use on this list) stopped = working and I didn't receive any message for a couple of weeks. I hope = everything is fixed now.

regards,

Reinaldo

------_=_NextPart_001_01C25523.2B68F8D2-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Sep 13 05:03:12 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29074 for ; Fri, 13 Sep 2002 05:03:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17pm8P-0005w3-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 Sep 2002 03:49:05 -0500 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17pm8O-0005vx-00 for ipfix-req@net.doit.wisc.edu; Fri, 13 Sep 2002 03:49:04 -0500 Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Sep 2002 10:49:00 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ipfix-req] draft-stephan-ippm-spatial-metrics-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 13 Sep 2002 10:49:00 +0200 Message-ID: Thread-Topic: Sending in the reporting MIB Thread-Index: AcIVvqMVwP/tgWTcT2m2AVoQB89mAwAjXUAAEQlwOcA= From: "STEPHAN Emile FTRD/DAC/LAN" To: "IPPM Working Group" , , , X-OriginalArrivalTime: 13 Sep 2002 08:49:00.0867 (UTC) FILETIME=[67C2B130:01C25B02] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA29074 Hello, An new I-D related to measurement is available online http://www.ietf.org/internet-drafts/draft-stephan-ippm-spatial-metrics-00.txt Abstract: The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end to end performance. Measurements system scope is often limited to administrative boundaries. This memo defines spatial metrics both for measuring end-to-end network performance using aggregation of sequence of network measures and for measuring the performance of segment of an IP path trajectory. It distinguishes clearly the decomposition of one end-to-end measure result in a sequence of per hop results from the aggregation of a sequence of per hop measure results in an end-to-end result. best regards. Emile -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 17 11:27:31 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18848 for ; Tue, 17 Sep 2002 11:27:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17rK5h-0002Sc-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Sep 2002 10:16:41 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17rK5e-0002S6-00 for ipfix-req@net.doit.wisc.edu; Tue, 17 Sep 2002 10:16:38 -0500 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g8HFG6728263; Tue, 17 Sep 2002 17:16:06 +0200 (CEST) Message-ID: <3D874736.5020009@cisco.com> Date: Tue, 17 Sep 2002 17:16:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: req Subject: [ipfix-req] IPFIX Requirement draft status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, A lot of topics have been recently discussed on the mailing list. So many that the draft status is currently not too clear (even if we have some consensus on certain issues). Let us consolidate all the feedback, insert all the changes into a new requirement draft and send it to the mailing list. This should be done by the middle of next week. Regards, the editor team -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Sep 17 11:55:50 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19890 for ; Tue, 17 Sep 2002 11:55:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17rKZZ-0002k9-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Sep 2002 10:47:33 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17rKZX-0002Ym-00 for ipfix-req@net.doit.wisc.edu; Tue, 17 Sep 2002 10:47:31 -0500 Received: from riverstonenet.com ([134.141.180.81]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 17 Sep 2002 08:46:56 -0700 Message-ID: <3D874E05.84905C47@riverstonenet.com> Date: Tue, 17 Sep 2002 11:45:09 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: req Subject: Re: [ipfix-req] IPFIX Requirement draft status References: <3D874736.5020009@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2002 15:46:56.0868 (UTC) FILETIME=[73DFCA40:01C25E61] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Dear all, > > A lot of topics have been recently discussed on the mailing list. So > many that the draft status is currently not too clear (even if we have > some consensus on certain issues). > Let us consolidate all the feedback, insert all the changes into a new > requirement draft and send it to the mailing list. This should be done > by the middle of next week. I would like to get some resolution to the remaining open issues I raised first. I sent a summary message to the list, but no responses to date. Paul > > Regards, the editor team > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 25 10:56:09 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28409 for ; Wed, 25 Sep 2002 10:56:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uDM9-0007ge-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 Sep 2002 09:41:37 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uDM6-0007gV-00 for ipfix@net.doit.wisc.edu; Wed, 25 Sep 2002 09:41:34 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA08767 for ; Thu, 26 Sep 2002 02:41:31 +1200 (NZST) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AIB64669; Thu, 26 Sep 2002 02:41:28 +1200 (NZST) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id g8PEfR304265 for ; Thu, 26 Sep 2002 02:41:28 +1200 Received: from 129.69.30.65 ([129.69.30.65]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Thu, 26 Sep 2002 02:41:27 +1200 Message-ID: <1032964887.3d91cb17a8cfa@hotlava.auckland.ac.nz> Date: Thu, 26 Sep 2002 02:41:27 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX status: advocate drafts, requirements draft MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 129.69.30.65 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: As you saw on this mailing list, all five protocol advocates published their Advocay Drafts early in September. Those drafts are listed on the IPFIX home page, http://net.doit.wisc.edu/ipfx/ So far there's been no discussion of any of the Advocacy Drafts on the list. If you have opinions about one or more of them, now's the time to post your comments! At this stage the advocates can edit/ modify/improve their drafts and republish, any time until 18 October. 18 October is the target date for the Evaluation Team to publish their Summary draft; the team are working towards that. Meanwhile, the next revision of the Requirements Draft will be published soon. We need to get this to Last Call very soon now! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 25 12:22:40 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01304 for ; Wed, 25 Sep 2002 12:22:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uEnw-0002nS-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 Sep 2002 11:14:24 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uEnt-0002mh-00 for ipfix@net.doit.wisc.edu; Wed, 25 Sep 2002 11:14:21 -0500 Received: from riverstonenet.com ([134.141.180.91]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 25 Sep 2002 09:14:17 -0700 Message-ID: <3D91E06B.4BC13C39@riverstonenet.com> Date: Wed, 25 Sep 2002 12:12:27 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX status: advocate drafts, requirements draft References: <1032964887.3d91cb17a8cfa@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2002 16:14:17.0990 (UTC) FILETIME=[995D2260:01C264AE] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil Brownlee wrote: > > Hello all: > > As you saw on this mailing list, all five protocol advocates published > their Advocay Drafts early in September. Those drafts are listed on > the IPFIX home page, http://net.doit.wisc.edu/ipfx/ > > So far there's been no discussion of any of the Advocacy Drafts on > the list. If you have opinions about one or more of them, now's the > time to post your comments! At this stage the advocates can edit/ > modify/improve their drafts and republish, any time until 18 October. > > 18 October is the target date for the Evaluation Team to publish > their Summary draft; the team are working towards that. > > Meanwhile, the next revision of the Requirements Draft will be published > soon. We need to get this to Last Call very soon now! I would like to get some closure on the issues I raised. I already sent out a summary/status on the issues. No response so far. Paul > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 25 13:10:07 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03081 for ; Wed, 25 Sep 2002 13:10:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uFDh-0003f2-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 Sep 2002 11:41:01 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uFDe-0003dx-00 for ipfix@net.doit.wisc.edu; Wed, 25 Sep 2002 11:40:58 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8PGeMU20076; Wed, 25 Sep 2002 18:40:22 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E51C265BFD; Wed, 25 Sep 2002 18:40:20 +0200 (CEST) Date: Wed, 25 Sep 2002 18:40:20 +0200 From: Juergen Quittek To: calato@riverstonenet.com, Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX status: advocate drafts, requirements draft Message-ID: <26781129.1032979220@[192.168.102.164]> In-Reply-To: <3D91E06B.4BC13C39@riverstonenet.com> References: <3D91E06B.4BC13C39@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, together with the next version, I'll send a list of changes addressing several of the issues you raised. Then there is still about a month left before Atlanta cut-off date allowing us to discuss the issues with everybody on the and if necessary, commit agreed changes in another version. The reason for not further discussing issue by issue is that we already have a long list of changes and we want to have them visible in a draft instead of having them distributed over more than 50 emails. This does not imply that a final decision on any of you issues is made. We just want to have a common text base for our discussion. Cheers, Juergen -- calato@riverstonenet.com wrote on 25 September 2002 12:12 -0400: > Nevil Brownlee wrote: >> >> Hello all: >> >> As you saw on this mailing list, all five protocol advocates published >> their Advocay Drafts early in September. Those drafts are listed on >> the IPFIX home page, http://net.doit.wisc.edu/ipfx/ >> >> So far there's been no discussion of any of the Advocacy Drafts on >> the list. If you have opinions about one or more of them, now's the >> time to post your comments! At this stage the advocates can edit/ >> modify/improve their drafts and republish, any time until 18 October. >> >> 18 October is the target date for the Evaluation Team to publish >> their Summary draft; the team are working towards that. >> >> Meanwhile, the next revision of the Requirements Draft will be published >> soon. We need to get this to Last Call very soon now! > > I would like to get some closure on the issues I raised. > I already sent out a summary/status on the issues. No > response so far. > > Paul > >> >> Cheers, Nevil >> >> ----------------------------------------------------------------------- >> Nevil Brownlee Director, Technology Development >> Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland >> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >> >> ------------------------------------------------- >> This mail sent through IMP: http://horde.org/imp/ >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 25 15:34:11 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07848 for ; Wed, 25 Sep 2002 15:34:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uHmE-0003md-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 Sep 2002 14:24:50 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17uHmB-0003mW-00 for ipfix@net.doit.wisc.edu; Wed, 25 Sep 2002 14:24:47 -0500 Received: (qmail 15439 invoked from network); 25 Sep 2002 19:24:45 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 25 Sep 2002 19:24:45 -0000 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g8PJRhs25605 for ; Wed, 25 Sep 2002 12:27:43 -0700 From: "Peter Ludemann" To: Subject: RE: [ipfix] IPFIX status: advocate drafts, requirements draft Date: Wed, 25 Sep 2002 12:24:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <1032964887.3d91cb17a8cfa@hotlava.auckland.ac.nz> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil Brownlee wrote Wednesday, September 25, 2002 7:41 AM: > So far there's been no discussion of any of the Advocacy Drafts on > the list. If you have opinions about one or more of them, now's the > time to post your comments! At this stage the advocates can edit/ > modify/improve their drafts and republish, any time until 18 October. Will there be clarification questions from the Evaluation Team to the authors of the various proposals? I'm thinking of the normal industry "RFP" process (I've just gone through a few of these and am still in pain), where the process usually is: 1. Publication of a Request For Proposals (RFP) 2. Clarification questions about the RFP (from the responders) 3. Submission of complete responses + presentations 4. Follow-up questions to the responders 5. Short list (usually 2-3) 6. More follow-up questions 7. Decision 8. Contract negotiations, Statement of Work In the case of IPFIX, we've done up to stage 3. Will there be a step 5 (short list)? For step 6 (questions from the Evaluation Team), will the questions and responses be private or public? Do we want comments about the advocacy drafts from people outside the Evaluation Team or are the Advocacy Drafts the final word? [My feeling is that the advocates have had their turn and that they should keep quiet, except in response to questions from the Evaluation Team or other IPFIXers] - peter -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Sep 25 22:31:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16105 for ; Wed, 25 Sep 2002 22:31:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uOGh-0005qB-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 Sep 2002 21:20:43 -0500 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uOGf-0005pP-00 for ipfix-req@net.doit.wisc.edu; Wed, 25 Sep 2002 21:20:41 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8Q2K33x008892; Wed, 25 Sep 2002 19:20:03 -0700 (PDT) Received: from cisco.com (sjc-vpn2-900.cisco.com [10.21.115.132]) by mira-sjcd-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH43738; Wed, 25 Sep 2002 19:21:03 -0700 (PDT) Message-ID: <3D926ED7.55A3E8E@cisco.com> Date: Wed, 25 Sep 2002 19:20:08 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > I wanted to summarize where we are with the issues > I raised a while back. A few still need to be resolved. > > calato@riverstonenet.com wrote: > > > > As I work on the advocates document some questions > > have come to mind on the requirements document. > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > In the case of fragmented packets there are > > no port numbers. Are we saying flow state information > > MUST be maintained? In general, it is not clear from > > the document what the requirements are for fragmented > > packets. > > RESOLVED: State information MAY be kept for > proper flow designation. > > > > > 4.4 MPLS Label > > > > In the case of dynamic LSP's the label is not useful. > > Why require distinguishing flows based on label. > > What can be done with that information? > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > 5.3 Overload Behavior > > > > This section needs to be re-worked a little. Some > > of the MUST's impose undue burden on the device. > > > > 1. Must distinguish flow records before and after the > > behavior change. > > > > In the case where the behavior is to drop > > overflow flows, why do we need to distinguish > > flows. Perhaps I misunderstood something. > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > Again, if I simply dropped excess flows why terminate > > all existing ones. This will likely cause more overflow > > as the get reestablished. This also seems to go to > > far towards implementation. > > > > 3. Meeting process MUST NOT merge previous records. > > > > I think what we are trying to say is flows with a different > > definition MUST be distinguishable. How that is done is not > > part of the requirements doc. > > OPEN > > We agreed that not all behaviors require terminating flows. > > We still need more dialogue on the following > > 1. Do we need to define a term for the set of properties > that is used to distinguish flows. Is it enough if we give an exporter state along with the export packet. This assumes that a control infromation which explaining the action taken corresponding to the exporter state has been send apriori. This way the flows itself need not be changed. The other way is to send a different flow. Even though the export record may look the same, it is identified by a different id and the id->config mapping is assumed to have been send when the overload condition started. > > > 2. Do we need to require that flows can be mapped to the > term defined in #1 It depends on the apporach taken. > > > > > > 5.4 Timestamps > > > > Time stamps to not always mapped to the first packet and last > > packet. In many cases, the end timestamp is merely when > > the flow timed out and has nothing to do with when the > > last packet was seen. Allowing both semantics may be useful. > > A re-wording like this... > > > > The metering process MUST be able to generate timestamps for the > > start and end of a flow. The metering process MAY also provide > > timestamps for the first and the last observed packet > > of a flow. The timestamp resolution MUST be at least the one of > > the sysUpTime [RFC1213], which is one centisecond. > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > could have one element for each meaning (e.g. Flow-start-time, > > first-packet-time, flow-start-and-first-packet-time) and use > > the one with the desired meaning. > > OPEN > > This issue still needs more dialogue to gain clarity. > > Ganesh believes it is possible to detect last packet time within > msec accuracy. Well, as you mentioned a while ago if some one implements an ager which ages out a million cache entries in s/w, the answer is no. It seems to me it is not something a vendor would venture into doing. It is a good time for some doing something in the similar lines to speak up;) Thanks Ganesh > > > I believe it is not possible without hardware assist and not > all platform will have that capability. > > > > > 6.1 information Model > > > > 9 Packet Counter > > 10 Byte counter > > > > As mentioned earlier, for fragments this > > requires state information? If there is no > > state info, then what flow are the counted > > towards? > > RESOLVED(I think): no mention needs to me made in the packet or byte > counter section since fragment counting is a matter > for flow designation. > > > > > 13 BGP AS number > > > > Is this the AS number for the observation point, the > > source/destination address in the packet or some > > combination? > > RESOLVED: These MAY be reported. > > 1. Source IP AS > 2. Destination IP AS > 3. Observation Point AS (which may be a a list if it > participates on more than one) > > I would like to propose 2 more > > Next hop AS > previous hop AS Why not the AS PATH? > > > > > > 14. MPLS Label > > > > As stated earlier, in the case of dynamic LSP's the > > label has no meaning. > > > > 21 multicast replication number > > > > The document stated this can change over the life > > of the flow. But no mention of what happens when > > it changes. Is that a new flow? If not, what meaning > > does it have when reported? What can I do with it? > > RESOLVED: If a new flow is desired, it becomes part of the > "Distinguishing Properties". If not, then it can still > be reported and ignored when it changes. > > > > > > 6.2 Data Model > > > > What about allowing Vendors to add information independently? > > Some data to be transported may be vendor specific and never > > make it into the IPFIX spec. > > RESOLVED: It is allowed now and we do not need to mention > it specifically. > > > > > 8.3 Several Collecting Processes > > > > No mention is made when reporting to several devices > > of ensuring the duplicate data does not cause a double > > counting problem. > > RESOLVED: This requirement needs to be added. > > > > > 9. Special Device Considerations > > > > I'm not sure of the meaning for the following... > > > > ... > > > > Please note that here, the observation > > point of a single flow cannot exceed the set of most fine-granular > > observation points linked to a single metering process, because only > > the metering process can merge packets observed at different fine- > > granular observation points to a joint flow. > > > > ... > > > > Also the > > locations of metering processes are not of any relevance for this > > document (in contrast to the locations of observation points and the > > exporting processes). > > > > These were just for my understanding. > > > Paul > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 10:29:59 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09152 for ; Thu, 26 Sep 2002 10:29:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uZTM-0005Aj-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 09:18:32 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uZTK-00059o-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 09:18:30 -0500 Received: from riverstonenet.com ([134.141.180.72]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 26 Sep 2002 07:17:56 -0700 Message-ID: <3D9316A7.54B16699@riverstonenet.com> Date: Thu, 26 Sep 2002 10:16:07 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2002 14:17:57.0429 (UTC) FILETIME=[8309CE50:01C26567] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > I wanted to summarize where we are with the issues > > I raised a while back. A few still need to be resolved. > > > > calato@riverstonenet.com wrote: > > > > > > As I work on the advocates document some questions > > > have come to mind on the requirements document. > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > In the case of fragmented packets there are > > > no port numbers. Are we saying flow state information > > > MUST be maintained? In general, it is not clear from > > > the document what the requirements are for fragmented > > > packets. > > > > RESOLVED: State information MAY be kept for > > proper flow designation. > > > > > > > > 4.4 MPLS Label > > > > > > In the case of dynamic LSP's the label is not useful. > > > Why require distinguishing flows based on label. > > > What can be done with that information? > > > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > > > > 5.3 Overload Behavior > > > > > > This section needs to be re-worked a little. Some > > > of the MUST's impose undue burden on the device. > > > > > > 1. Must distinguish flow records before and after the > > > behavior change. > > > > > > In the case where the behavior is to drop > > > overflow flows, why do we need to distinguish > > > flows. Perhaps I misunderstood something. > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > all existing ones. This will likely cause more overflow > > > as the get reestablished. This also seems to go to > > > far towards implementation. > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > I think what we are trying to say is flows with a different > > > definition MUST be distinguishable. How that is done is not > > > part of the requirements doc. > > > > OPEN > > > > We agreed that not all behaviors require terminating flows. > > > > We still need more dialogue on the following > > > > 1. Do we need to define a term for the set of properties > > that is used to distinguish flows. > > Is it enough if we give an exporter state along with the export packet. What do you mean by "exporter state"? > This assumes that a control infromation which explaining the action taken > corresponding to the exporter state has been send apriori. Statement #1 above doesn't say anything about what is sent when or where. I'm asking more of a spec question. We don't define a term for the set of properties that are used to uniquely identify a flow. > This way > the flows itself need not be changed. > The other way is to send a different flow. This is the same as terminating exiting flows, which I'm trying to avoid. > Even though the export record > may look the same, it is identified by a different id and the id->config mapping > is assumed to have been send when the overload condition started. > > > > > > > 2. Do we need to require that flows can be mapped to the > > term defined in #1 > > It depends on the apporach taken. I don't think it does. Statement #2 say we need to ba able to tell which flow mapped to which definition. It doesn't say anything about how that mapping is done, only that it can be done somehow. > > > > > > > > > > > 5.4 Timestamps > > > > > > Time stamps to not always mapped to the first packet and last > > > packet. In many cases, the end timestamp is merely when > > > the flow timed out and has nothing to do with when the > > > last packet was seen. Allowing both semantics may be useful. > > > A re-wording like this... > > > > > > The metering process MUST be able to generate timestamps for the > > > start and end of a flow. The metering process MAY also provide > > > timestamps for the first and the last observed packet > > > of a flow. The timestamp resolution MUST be at least the one of > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > could have one element for each meaning (e.g. Flow-start-time, > > > first-packet-time, flow-start-and-first-packet-time) and use > > > the one with the desired meaning. > > > > OPEN > > > > This issue still needs more dialogue to gain clarity. > > > > Ganesh believes it is possible to detect last packet time within > > msec accuracy. > > Well, as you mentioned a while ago if some one implements an ager > which ages out a million cache entries in s/w, the answer is no. It > seems to me it is not something a vendor would venture into doing. > It is a good time for some doing something in the similar lines to speak up;) > Thanks > Ganesh Some vendors already do this. It is not a theoretical problem but a real one. And you don't need a million flows for it to be a problem. You could have just one flow. If the ager checks say every 30 seconds, then your end time has a maximum of a 30 second delay. Paul > > > > > > > I believe it is not possible without hardware assist and not > > all platform will have that capability. > > > > > > > > 6.1 information Model > > > > > > 9 Packet Counter > > > 10 Byte counter > > > > > > As mentioned earlier, for fragments this > > > requires state information? If there is no > > > state info, then what flow are the counted > > > towards? > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > counter section since fragment counting is a matter > > for flow designation. > > > > > > > > 13 BGP AS number > > > > > > Is this the AS number for the observation point, the > > > source/destination address in the packet or some > > > combination? > > > > RESOLVED: These MAY be reported. > > > > 1. Source IP AS > > 2. Destination IP AS > > 3. Observation Point AS (which may be a a list if it > > participates on more than one) > > > > I would like to propose 2 more > > > > Next hop AS > > previous hop AS > > Why not the AS PATH? > > > > > > > > > > > 14. MPLS Label > > > > > > As stated earlier, in the case of dynamic LSP's the > > > label has no meaning. > > > > > > 21 multicast replication number > > > > > > The document stated this can change over the life > > > of the flow. But no mention of what happens when > > > it changes. Is that a new flow? If not, what meaning > > > does it have when reported? What can I do with it? > > > > RESOLVED: If a new flow is desired, it becomes part of the > > "Distinguishing Properties". If not, then it can still > > be reported and ignored when it changes. > > > > > > > > > 6.2 Data Model > > > > > > What about allowing Vendors to add information independently? > > > Some data to be transported may be vendor specific and never > > > make it into the IPFIX spec. > > > > RESOLVED: It is allowed now and we do not need to mention > > it specifically. > > > > > > > > 8.3 Several Collecting Processes > > > > > > No mention is made when reporting to several devices > > > of ensuring the duplicate data does not cause a double > > > counting problem. > > > > RESOLVED: This requirement needs to be added. > > > > > > > > 9. Special Device Considerations > > > > > > I'm not sure of the meaning for the following... > > > > > > ... > > > > > > Please note that here, the observation > > > point of a single flow cannot exceed the set of most fine-granular > > > observation points linked to a single metering process, because only > > > the metering process can merge packets observed at different fine- > > > granular observation points to a joint flow. > > > > > > ... > > > > > > Also the > > > locations of metering processes are not of any relevance for this > > > document (in contrast to the locations of observation points and the > > > exporting processes). > > > > > > > These were just for my understanding. > > > > > Paul > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 11:52:09 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12776 for ; Thu, 26 Sep 2002 11:52:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uakX-0000Pe-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 10:40:21 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uakU-0000Nm-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 10:40:18 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QFdl1X006179; Thu, 26 Sep 2002 08:39:47 -0700 (PDT) Received: from cisco.com (sjc-vpn2-900.cisco.com [10.21.115.132]) by mira-sjcd-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH57307; Thu, 26 Sep 2002 08:40:41 -0700 (PDT) Message-ID: <3D932A40.D96DD195@cisco.com> Date: Thu, 26 Sep 2002 08:39:44 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> <3D9316A7.54B16699@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > Ganesh Sadasivan wrote: > > > > calato@riverstonenet.com wrote: > > > > > I wanted to summarize where we are with the issues > > > I raised a while back. A few still need to be resolved. > > > > > > calato@riverstonenet.com wrote: > > > > > > > > As I work on the advocates document some questions > > > > have come to mind on the requirements document. > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > In the case of fragmented packets there are > > > > no port numbers. Are we saying flow state information > > > > MUST be maintained? In general, it is not clear from > > > > the document what the requirements are for fragmented > > > > packets. > > > > > > RESOLVED: State information MAY be kept for > > > proper flow designation. > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > Why require distinguishing flows based on label. > > > > What can be done with that information? > > > > > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > This section needs to be re-worked a little. Some > > > > of the MUST's impose undue burden on the device. > > > > > > > > 1. Must distinguish flow records before and after the > > > > behavior change. > > > > > > > > In the case where the behavior is to drop > > > > overflow flows, why do we need to distinguish > > > > flows. Perhaps I misunderstood something. > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > all existing ones. This will likely cause more overflow > > > > as the get reestablished. This also seems to go to > > > > far towards implementation. > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > I think what we are trying to say is flows with a different > > > > definition MUST be distinguishable. How that is done is not > > > > part of the requirements doc. > > > > > > OPEN > > > > > > We agreed that not all behaviors require terminating flows. > > > > > > We still need more dialogue on the following > > > > > > 1. Do we need to define a term for the set of properties > > > that is used to distinguish flows. > > > > Is it enough if we give an exporter state along with the export packet. > > What do you mean by "exporter state"? Whether it is in "overload condition" , "normal" etc. Sorry for being unclear. What I meant was, use the exporter state along with the other information defined in section 4.0 to distinguish flows. The methods that I mentioned below are just examples of implementation. > > > > This assumes that a control infromation which explaining the action taken > > corresponding to the exporter state has been send apriori. > > Statement #1 above doesn't say anything about what is sent > when or where. > > I'm asking more of a spec question. We don't define a term for the > set of properties that are used to uniquely identify a flow. > > > This way > > the flows itself need not be changed. > > The other way is to send a different flow. > > This is the same as terminating exiting flows, which I'm > trying to avoid. Why so? > > > > Even though the export record > > may look the same, it is identified by a different id and the id->config mapping > > is assumed to have been send when the overload condition started. > > > > > > > > > > > 2. Do we need to require that flows can be mapped to the > > > term defined in #1 > > > > It depends on the apporach taken. > > I don't think it does. Statement #2 say we need to ba able to > tell which flow mapped to which definition. It doesn't > say anything about how that mapping is done, only that > it can be done somehow. > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > packet. In many cases, the end timestamp is merely when > > > > the flow timed out and has nothing to do with when the > > > > last packet was seen. Allowing both semantics may be useful. > > > > A re-wording like this... > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > start and end of a flow. The metering process MAY also provide > > > > timestamps for the first and the last observed packet > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > the one with the desired meaning. > > > > > > OPEN > > > > > > This issue still needs more dialogue to gain clarity. > > > > > > Ganesh believes it is possible to detect last packet time within > > > msec accuracy. > > > > Well, as you mentioned a while ago if some one implements an ager > > which ages out a million cache entries in s/w, the answer is no. It > > seems to me it is not something a vendor would venture into doing. > > It is a good time for some doing something in the similar lines to speak up;) > > Thanks > > Ganesh > > Some vendors already do this. It is not a theoretical problem > but a real one. And you don't need a million flows for it > to be a problem. You could have just one flow. If the > ager checks say every 30 seconds, then your end time has > a maximum of a 30 second delay. Is that for some reason or is it a limitation in the implementation? -ganesh > > > Paul > > > > > > > > > > > > I believe it is not possible without hardware assist and not > > > all platform will have that capability. > > > > > > > > > > > 6.1 information Model > > > > > > > > 9 Packet Counter > > > > 10 Byte counter > > > > > > > > As mentioned earlier, for fragments this > > > > requires state information? If there is no > > > > state info, then what flow are the counted > > > > towards? > > > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > > counter section since fragment counting is a matter > > > for flow designation. > > > > > > > > > > > 13 BGP AS number > > > > > > > > Is this the AS number for the observation point, the > > > > source/destination address in the packet or some > > > > combination? > > > > > > RESOLVED: These MAY be reported. > > > > > > 1. Source IP AS > > > 2. Destination IP AS > > > 3. Observation Point AS (which may be a a list if it > > > participates on more than one) > > > > > > I would like to propose 2 more > > > > > > Next hop AS > > > previous hop AS > > > > Why not the AS PATH? > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > label has no meaning. > > > > > > > > 21 multicast replication number > > > > > > > > The document stated this can change over the life > > > > of the flow. But no mention of what happens when > > > > it changes. Is that a new flow? If not, what meaning > > > > does it have when reported? What can I do with it? > > > > > > RESOLVED: If a new flow is desired, it becomes part of the > > > "Distinguishing Properties". If not, then it can still > > > be reported and ignored when it changes. > > > > > > > > > > > > 6.2 Data Model > > > > > > > > What about allowing Vendors to add information independently? > > > > Some data to be transported may be vendor specific and never > > > > make it into the IPFIX spec. > > > > > > RESOLVED: It is allowed now and we do not need to mention > > > it specifically. > > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > No mention is made when reporting to several devices > > > > of ensuring the duplicate data does not cause a double > > > > counting problem. > > > > > > RESOLVED: This requirement needs to be added. > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > ... > > > > > > > > Please note that here, the observation > > > > point of a single flow cannot exceed the set of most fine-granular > > > > observation points linked to a single metering process, because only > > > > the metering process can merge packets observed at different fine- > > > > granular observation points to a joint flow. > > > > > > > > ... > > > > > > > > Also the > > > > locations of metering processes are not of any relevance for this > > > > document (in contrast to the locations of observation points and the > > > > exporting processes). > > > > > > > > > > These were just for my understanding. > > > > > > > Paul > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 12:31:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13962 for ; Thu, 26 Sep 2002 12:31:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17ubJk-0001pK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 11:16:44 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17ubJi-0001oY-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 11:16:42 -0500 Received: from riverstonenet.com ([134.141.180.72]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 26 Sep 2002 09:16:06 -0700 Message-ID: <3D933258.B9BD4EA0@riverstonenet.com> Date: Thu, 26 Sep 2002 12:14:16 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> <3D9316A7.54B16699@riverstonenet.com> <3D932A40.D96DD195@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2002 16:16:06.0706 (UTC) FILETIME=[0493A120:01C26578] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > Ganesh Sadasivan wrote: > > > > > > calato@riverstonenet.com wrote: > > > > > > > I wanted to summarize where we are with the issues > > > > I raised a while back. A few still need to be resolved. > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > As I work on the advocates document some questions > > > > > have come to mind on the requirements document. > > > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > > > In the case of fragmented packets there are > > > > > no port numbers. Are we saying flow state information > > > > > MUST be maintained? In general, it is not clear from > > > > > the document what the requirements are for fragmented > > > > > packets. > > > > > > > > RESOLVED: State information MAY be kept for > > > > proper flow designation. > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > > Why require distinguishing flows based on label. > > > > > What can be done with that information? > > > > > > > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > > > This section needs to be re-worked a little. Some > > > > > of the MUST's impose undue burden on the device. > > > > > > > > > > 1. Must distinguish flow records before and after the > > > > > behavior change. > > > > > > > > > > In the case where the behavior is to drop > > > > > overflow flows, why do we need to distinguish > > > > > flows. Perhaps I misunderstood something. > > > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > > all existing ones. This will likely cause more overflow > > > > > as the get reestablished. This also seems to go to > > > > > far towards implementation. > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > > > I think what we are trying to say is flows with a different > > > > > definition MUST be distinguishable. How that is done is not > > > > > part of the requirements doc. > > > > > > > > OPEN > > > > > > > > We agreed that not all behaviors require terminating flows. > > > > > > > > We still need more dialogue on the following > > > > > > > > 1. Do we need to define a term for the set of properties > > > > that is used to distinguish flows. > > > > > > Is it enough if we give an exporter state along with the export packet. > > > > What do you mean by "exporter state"? > > Whether it is in "overload condition" , "normal" etc. Sorry for being unclear. > What I meant was, use the exporter state along with the other information defined > in section 4.0 to distinguish flows. The methods that I mentioned below are just > examples of implementation. I think this points to an area of weakness for us (IPFIX). We are having a hard time having a discussion. Lets say that DP = "Distinguising Properties". Where DP is the set of fields and functions, etc... that are used to define a flow. Lets assume for now that the set of possible fields and functions, etc... is fully defined somewhere (it's not, but assume it is for now.). If we require that each flow can be mapped to its DP then the discussion moves to how that happens. There are many ways. Here are a few which come to mind... 1) send the DP with each flow. 2) send the DP with an ID. Then each flow contains a DP-ID field. 3) Send the DP for noraml operation and the DP for overload situation. Then only state changes need to be delivered. #3 above seems to be what you are talking about. However, I think we need to define DP as a term and the set of possible fields and functions first. Add the requirement of mapping a flow to a DP. Then the discussion can move to how we can best do the mapping. Then the discussion of what happens under overload conditions will be clearer. > > > > > > > > This assumes that a control infromation which explaining the action taken > > > corresponding to the exporter state has been send apriori. > > > > Statement #1 above doesn't say anything about what is sent > > when or where. > > > > I'm asking more of a spec question. We don't define a term for the > > set of properties that are used to uniquely identify a flow. > > > > > This way > > > the flows itself need not be changed. > > > The other way is to send a different flow. > > > > This is the same as terminating exiting flows, which I'm > > trying to avoid. > > Why so? Because you are going to send a new flow for all existing flows during overload sitiation. It will probably not be 1 for 1 but rather many flows now being collapsed into one during overload. Isn't that what you meant by "send a different flow". > > > > > > > > Even though the export record > > > may look the same, it is identified by a different id and the id->config mapping > > > is assumed to have been send when the overload condition started. > > > > > > > > > > > > > > > 2. Do we need to require that flows can be mapped to the > > > > term defined in #1 > > > > > > It depends on the apporach taken. > > > > I don't think it does. Statement #2 say we need to ba able to > > tell which flow mapped to which definition. It doesn't > > say anything about how that mapping is done, only that > > it can be done somehow. > > > > > > > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > > packet. In many cases, the end timestamp is merely when > > > > > the flow timed out and has nothing to do with when the > > > > > last packet was seen. Allowing both semantics may be useful. > > > > > A re-wording like this... > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > > start and end of a flow. The metering process MAY also provide > > > > > timestamps for the first and the last observed packet > > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > > the one with the desired meaning. > > > > > > > > OPEN > > > > > > > > This issue still needs more dialogue to gain clarity. > > > > > > > > Ganesh believes it is possible to detect last packet time within > > > > msec accuracy. > > > > > > Well, as you mentioned a while ago if some one implements an ager > > > which ages out a million cache entries in s/w, the answer is no. It > > > seems to me it is not something a vendor would venture into doing. > > > It is a good time for some doing something in the similar lines to speak up;) > > > Thanks > > > Ganesh > > > > Some vendors already do this. It is not a theoretical problem > > but a real one. And you don't need a million flows for it > > to be a problem. You could have just one flow. If the > > ager checks say every 30 seconds, then your end time has > > a maximum of a 30 second delay. > > Is that for some reason or is it a limitation in the implementation? > -ganesh It is merely software based aging. Probably just an initial system design choice. Paul > > > > > > > Paul > > > > > > > > > > > > > > > > > I believe it is not possible without hardware assist and not > > > > all platform will have that capability. > > > > > > > > > > > > > > 6.1 information Model > > > > > > > > > > 9 Packet Counter > > > > > 10 Byte counter > > > > > > > > > > As mentioned earlier, for fragments this > > > > > requires state information? If there is no > > > > > state info, then what flow are the counted > > > > > towards? > > > > > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > > > counter section since fragment counting is a matter > > > > for flow designation. > > > > > > > > > > > > > > 13 BGP AS number > > > > > > > > > > Is this the AS number for the observation point, the > > > > > source/destination address in the packet or some > > > > > combination? > > > > > > > > RESOLVED: These MAY be reported. > > > > > > > > 1. Source IP AS > > > > 2. Destination IP AS > > > > 3. Observation Point AS (which may be a a list if it > > > > participates on more than one) > > > > > > > > I would like to propose 2 more > > > > > > > > Next hop AS > > > > previous hop AS > > > > > > Why not the AS PATH? > > > > > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > > label has no meaning. > > > > > > > > > > 21 multicast replication number > > > > > > > > > > The document stated this can change over the life > > > > > of the flow. But no mention of what happens when > > > > > it changes. Is that a new flow? If not, what meaning > > > > > does it have when reported? What can I do with it? > > > > > > > > RESOLVED: If a new flow is desired, it becomes part of the > > > > "Distinguishing Properties". If not, then it can still > > > > be reported and ignored when it changes. > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > > > What about allowing Vendors to add information independently? > > > > > Some data to be transported may be vendor specific and never > > > > > make it into the IPFIX spec. > > > > > > > > RESOLVED: It is allowed now and we do not need to mention > > > > it specifically. > > > > > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > > > No mention is made when reporting to several devices > > > > > of ensuring the duplicate data does not cause a double > > > > > counting problem. > > > > > > > > RESOLVED: This requirement needs to be added. > > > > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > > > ... > > > > > > > > > > Please note that here, the observation > > > > > point of a single flow cannot exceed the set of most fine-granular > > > > > observation points linked to a single metering process, because only > > > > > the metering process can merge packets observed at different fine- > > > > > granular observation points to a joint flow. > > > > > > > > > > ... > > > > > > > > > > Also the > > > > > locations of metering processes are not of any relevance for this > > > > > document (in contrast to the locations of observation points and the > > > > > exporting processes). > > > > > > > > > > > > > These were just for my understanding. > > > > > > > > > Paul > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > "unsubscribe ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 15:04:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18512 for ; Thu, 26 Sep 2002 15:04:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17udmg-0001We-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 13:54:46 -0500 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17udmd-0001VS-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 13:54:43 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8QIs9W4010831; Thu, 26 Sep 2002 11:54:09 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-27.cisco.com [171.71.137.27]) by mira-sjcd-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH65856; Thu, 26 Sep 2002 11:54:59 -0700 (PDT) Message-ID: <3D9357CB.4DC32290@cisco.com> Date: Thu, 26 Sep 2002 11:54:03 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> <3D9316A7.54B16699@riverstonenet.com> <3D932A40.D96DD195@cisco.com> <3D933258.B9BD4EA0@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > Ganesh Sadasivan wrote: > > > > calato@riverstonenet.com wrote: > > > > > Ganesh Sadasivan wrote: > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > I wanted to summarize where we are with the issues > > > > > I raised a while back. A few still need to be resolved. > > > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > > > As I work on the advocates document some questions > > > > > > have come to mind on the requirements document. > > > > > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > > > > > In the case of fragmented packets there are > > > > > > no port numbers. Are we saying flow state information > > > > > > MUST be maintained? In general, it is not clear from > > > > > > the document what the requirements are for fragmented > > > > > > packets. > > > > > > > > > > RESOLVED: State information MAY be kept for > > > > > proper flow designation. > > > > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > > > Why require distinguishing flows based on label. > > > > > > What can be done with that information? > > > > > > > > > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > > > > > This section needs to be re-worked a little. Some > > > > > > of the MUST's impose undue burden on the device. > > > > > > > > > > > > 1. Must distinguish flow records before and after the > > > > > > behavior change. > > > > > > > > > > > > In the case where the behavior is to drop > > > > > > overflow flows, why do we need to distinguish > > > > > > flows. Perhaps I misunderstood something. > > > > > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > > > all existing ones. This will likely cause more overflow > > > > > > as the get reestablished. This also seems to go to > > > > > > far towards implementation. > > > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > > > > > I think what we are trying to say is flows with a different > > > > > > definition MUST be distinguishable. How that is done is not > > > > > > part of the requirements doc. > > > > > > > > > > OPEN > > > > > > > > > > We agreed that not all behaviors require terminating flows. > > > > > > > > > > We still need more dialogue on the following > > > > > > > > > > 1. Do we need to define a term for the set of properties > > > > > that is used to distinguish flows. > > > > > > > > Is it enough if we give an exporter state along with the export packet. > > > > > > What do you mean by "exporter state"? > > > > Whether it is in "overload condition" , "normal" etc. Sorry for being unclear. > > What I meant was, use the exporter state along with the other information defined > > in section 4.0 to distinguish flows. The methods that I mentioned below are just > > examples of implementation. > > I think this points to an area of weakness for us (IPFIX). We are > having a hard time having a discussion. > > Lets say that DP = "Distinguising Properties". Where DP is > the set of fields and functions, etc... that are used > to define a flow. Lets assume for now that the set of possible > fields and functions, etc... is fully defined somewhere > (it's not, but assume it is for now.). > > If we require that each flow can be mapped to its DP > then the discussion moves to how that happens. > > There are many ways. Here are a few which come to mind... > Does it matter how the DP is identified & send (whether with each flow or split across flow & control or otherwise) is sent, from a req. doc perspective? As long as we define DP (which is what you are suggesting to do) and tell that DP must give enough information so that the full flow context can be derived at the collector, will it not solve this issue? > > 1) send the DP with each flow. > 2) send the DP with an ID. Then each flow contains > a DP-ID field. > 3) Send the DP for noraml operation and the DP for > overload situation. Then only state changes need > to be delivered. > > #3 above seems to be what you are talking about. > > However, I think we need to define DP as a term and the set of > possible fields and functions first. Add the requirement of mapping > a flow to a DP. As I see DP is a function of {1.metering process(s) employed, 2. exporter state, 3. fields collected}. There is a furthur inter dependency between * 2&1 (with the exporter state change metering could change), * 2 & 3 (with the exporter state change fields collected could change), * 1 & 3 (fields are input tometering functions). Am I missing anything? > Then the discussion can move to how we > can best do the mapping. Then the discussion of what happens > under overload conditions will be clearer. > > > > > > > > > > > > > This assumes that a control infromation which explaining the action taken > > > > corresponding to the exporter state has been send apriori. > > > > > > Statement #1 above doesn't say anything about what is sent > > > when or where. > > > > > > I'm asking more of a spec question. We don't define a term for the > > > set of properties that are used to uniquely identify a flow. > > > > > > > This way > > > > the flows itself need not be changed. > > > > The other way is to send a different flow. > > > > > > This is the same as terminating exiting flows, which I'm > > > trying to avoid. > > > > Why so? > > Because you are going to send a new flow for all existing flows > during overload sitiation. It will probably not be 1 for 1 but > rather many flows now being collapsed into one during overload. > > Isn't that what you meant by "send a different flow". Yes. But why do we not leave room for such a case? > > > > > > > > > > > > > Even though the export record > > > > may look the same, it is identified by a different id and the id->config mapping > > > > is assumed to have been send when the overload condition started. > > > > > > > > > > > > > > > > > > > 2. Do we need to require that flows can be mapped to the > > > > > term defined in #1 > > > > > > > > It depends on the apporach taken. > > > > > > I don't think it does. Statement #2 say we need to ba able to > > > tell which flow mapped to which definition. It doesn't > > > say anything about how that mapping is done, only that > > > it can be done somehow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > > > packet. In many cases, the end timestamp is merely when > > > > > > the flow timed out and has nothing to do with when the > > > > > > last packet was seen. Allowing both semantics may be useful. > > > > > > A re-wording like this... > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > > > start and end of a flow. The metering process MAY also provide > > > > > > timestamps for the first and the last observed packet > > > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > > > the one with the desired meaning. > > > > > > > > > > OPEN > > > > > > > > > > This issue still needs more dialogue to gain clarity. > > > > > > > > > > Ganesh believes it is possible to detect last packet time within > > > > > msec accuracy. > > > > > > > > Well, as you mentioned a while ago if some one implements an ager > > > > which ages out a million cache entries in s/w, the answer is no. It > > > > seems to me it is not something a vendor would venture into doing. > > > > It is a good time for some doing something in the similar lines to speak up;) > > > > Thanks > > > > Ganesh > > > > > > Some vendors already do this. It is not a theoretical problem > > > but a real one. And you don't need a million flows for it > > > to be a problem. You could have just one flow. If the > > > ager checks say every 30 seconds, then your end time has > > > a maximum of a 30 second delay. > > > > Is that for some reason or is it a limitation in the implementation? > > -ganesh > > It is merely software based aging. Probably just an initial > system design choice. Are you indicating that there could be products in which the design cannot be changed to suit the msec granularity timing requirements of IPFIX? -ganesh > > > Paul > > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > I believe it is not possible without hardware assist and not > > > > > all platform will have that capability. > > > > > > > > > > > > > > > > > 6.1 information Model > > > > > > > > > > > > 9 Packet Counter > > > > > > 10 Byte counter > > > > > > > > > > > > As mentioned earlier, for fragments this > > > > > > requires state information? If there is no > > > > > > state info, then what flow are the counted > > > > > > towards? > > > > > > > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > > > > counter section since fragment counting is a matter > > > > > for flow designation. > > > > > > > > > > > > > > > > > 13 BGP AS number > > > > > > > > > > > > Is this the AS number for the observation point, the > > > > > > source/destination address in the packet or some > > > > > > combination? > > > > > > > > > > RESOLVED: These MAY be reported. > > > > > > > > > > 1. Source IP AS > > > > > 2. Destination IP AS > > > > > 3. Observation Point AS (which may be a a list if it > > > > > participates on more than one) > > > > > > > > > > I would like to propose 2 more > > > > > > > > > > Next hop AS > > > > > previous hop AS > > > > > > > > Why not the AS PATH? > > > > > > > > > > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > > > label has no meaning. > > > > > > > > > > > > 21 multicast replication number > > > > > > > > > > > > The document stated this can change over the life > > > > > > of the flow. But no mention of what happens when > > > > > > it changes. Is that a new flow? If not, what meaning > > > > > > does it have when reported? What can I do with it? > > > > > > > > > > RESOLVED: If a new flow is desired, it becomes part of the > > > > > "Distinguishing Properties". If not, then it can still > > > > > be reported and ignored when it changes. > > > > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > > > > > What about allowing Vendors to add information independently? > > > > > > Some data to be transported may be vendor specific and never > > > > > > make it into the IPFIX spec. > > > > > > > > > > RESOLVED: It is allowed now and we do not need to mention > > > > > it specifically. > > > > > > > > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > > > > > No mention is made when reporting to several devices > > > > > > of ensuring the duplicate data does not cause a double > > > > > > counting problem. > > > > > > > > > > RESOLVED: This requirement needs to be added. > > > > > > > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > > > > > ... > > > > > > > > > > > > Please note that here, the observation > > > > > > point of a single flow cannot exceed the set of most fine-granular > > > > > > observation points linked to a single metering process, because only > > > > > > the metering process can merge packets observed at different fine- > > > > > > granular observation points to a joint flow. > > > > > > > > > > > > ... > > > > > > > > > > > > Also the > > > > > > locations of metering processes are not of any relevance for this > > > > > > document (in contrast to the locations of observation points and the > > > > > > exporting processes). > > > > > > > > > > > > > > > > These were just for my understanding. > > > > > > > > > > > Paul > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > "unsubscribe ipfix" in message body > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 16:09:24 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20230 for ; Thu, 26 Sep 2002 16:09:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uemw-0003vA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 14:59:06 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uemu-0003u4-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 14:59:04 -0500 Received: from riverstonenet.com ([134.141.180.72]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 26 Sep 2002 12:58:30 -0700 Message-ID: <3D936678.639BBEE6@riverstonenet.com> Date: Thu, 26 Sep 2002 15:56:40 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> <3D9316A7.54B16699@riverstonenet.com> <3D932A40.D96DD195@cisco.com> <3D933258.B9BD4EA0@riverstonenet.com> <3D9357CB.4DC32290@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2002 19:58:30.0931 (UTC) FILETIME=[165AC630:01C26597] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > Ganesh Sadasivan wrote: > > > > > > calato@riverstonenet.com wrote: > > > > > > > Ganesh Sadasivan wrote: > > > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > > I wanted to summarize where we are with the issues > > > > > > I raised a while back. A few still need to be resolved. > > > > > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > > > > > As I work on the advocates document some questions > > > > > > > have come to mind on the requirements document. > > > > > > > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > > > > > > > In the case of fragmented packets there are > > > > > > > no port numbers. Are we saying flow state information > > > > > > > MUST be maintained? In general, it is not clear from > > > > > > > the document what the requirements are for fragmented > > > > > > > packets. > > > > > > > > > > > > RESOLVED: State information MAY be kept for > > > > > > proper flow designation. > > > > > > > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > > > > Why require distinguishing flows based on label. > > > > > > > What can be done with that information? > > > > > > > > > > > > RESOLVED: We agreed to distinguish by label and to report label. > > > > > > > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > > > > > > > This section needs to be re-worked a little. Some > > > > > > > of the MUST's impose undue burden on the device. > > > > > > > > > > > > > > 1. Must distinguish flow records before and after the > > > > > > > behavior change. > > > > > > > > > > > > > > In the case where the behavior is to drop > > > > > > > overflow flows, why do we need to distinguish > > > > > > > flows. Perhaps I misunderstood something. > > > > > > > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > > > > all existing ones. This will likely cause more overflow > > > > > > > as the get reestablished. This also seems to go to > > > > > > > far towards implementation. > > > > > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > > > > > > > I think what we are trying to say is flows with a different > > > > > > > definition MUST be distinguishable. How that is done is not > > > > > > > part of the requirements doc. > > > > > > > > > > > > OPEN > > > > > > > > > > > > We agreed that not all behaviors require terminating flows. > > > > > > > > > > > > We still need more dialogue on the following > > > > > > > > > > > > 1. Do we need to define a term for the set of properties > > > > > > that is used to distinguish flows. > > > > > > > > > > Is it enough if we give an exporter state along with the export packet. > > > > > > > > What do you mean by "exporter state"? > > > > > > Whether it is in "overload condition" , "normal" etc. Sorry for being unclear. > > > What I meant was, use the exporter state along with the other information defined > > > in section 4.0 to distinguish flows. The methods that I mentioned below are just > > > examples of implementation. > > > > I think this points to an area of weakness for us (IPFIX). We are > > having a hard time having a discussion. > > > > Lets say that DP = "Distinguising Properties". Where DP is > > the set of fields and functions, etc... that are used > > to define a flow. Lets assume for now that the set of possible > > fields and functions, etc... is fully defined somewhere > > (it's not, but assume it is for now.). > > > > If we require that each flow can be mapped to its DP > > then the discussion moves to how that happens. > > > > There are many ways. Here are a few which come to mind... > > > > Does it matter how the DP is identified & send (whether with each flow or split > across flow & control or otherwise) is sent, from a req. doc perspective? > As long as we define DP (which is what you are suggesting to do) and tell that DP > must give enough information so that the full flow context can be derived at the > collector, will it not solve this issue? > Yes it will. I gave example to make sure we were on the same page. They would not go in the req doc. > > > > 1) send the DP with each flow. > > 2) send the DP with an ID. Then each flow contains > > a DP-ID field. > > 3) Send the DP for noraml operation and the DP for > > overload situation. Then only state changes need > > to be delivered. > > > > #3 above seems to be what you are talking about. > > > > However, I think we need to define DP as a term and the set of > > possible fields and functions first. Add the requirement of mapping > > a flow to a DP. > > As I see DP is a function of {1.metering process(s) employed, 2. exporter state, > 3. fields collected}. I don't see a direct relationship #1 and #2/#3. For example I could have a DP of source and dest IP but collect (i.e. report) Src/Dst AS number. Also, the state may change from normal to overload with no change in DP but rather a dropping of additional flows. I think DP stands pretty much on its own. In other words fields collected and the state are not part of the DP definition. Those things may influence which DP is used but they are not part of the DP definition itself. But I think we are getting a little ahead of the game. We need to define DP and its fields and functions. Once we have consensus that we need to define DP and its fields and functions and we agree we need to map flow to DP, then we can kick off the discussion. > There is a furthur inter dependency between > * 2&1 (with the exporter state change metering could change), > * 2 & 3 (with the exporter state change fields collected could change), > * 1 & 3 (fields are input tometering functions). > > Am I missing anything? > > > Then the discussion can move to how we > > can best do the mapping. Then the discussion of what happens > > under overload conditions will be clearer. > > > > > > > > > > > > > > > > > > This assumes that a control infromation which explaining the action taken > > > > > corresponding to the exporter state has been send apriori. > > > > > > > > Statement #1 above doesn't say anything about what is sent > > > > when or where. > > > > > > > > I'm asking more of a spec question. We don't define a term for the > > > > set of properties that are used to uniquely identify a flow. > > > > > > > > > This way > > > > > the flows itself need not be changed. > > > > > The other way is to send a different flow. > > > > > > > > This is the same as terminating exiting flows, which I'm > > > > trying to avoid. > > > > > > Why so? > > > > Because you are going to send a new flow for all existing flows > > during overload sitiation. It will probably not be 1 for 1 but > > rather many flows now being collapsed into one during overload. > > > > Isn't that what you meant by "send a different flow". > > Yes. But why do we not leave room for such a case? The current document says all flows must be terminated. I was pushing to allow for other alternatives, including terminating all flows. > > > > > > > > > > > > > > > > > > > Even though the export record > > > > > may look the same, it is identified by a different id and the id->config mapping > > > > > is assumed to have been send when the overload condition started. > > > > > > > > > > > > > > > > > > > > > > > 2. Do we need to require that flows can be mapped to the > > > > > > term defined in #1 > > > > > > > > > > It depends on the apporach taken. > > > > > > > > I don't think it does. Statement #2 say we need to ba able to > > > > tell which flow mapped to which definition. It doesn't > > > > say anything about how that mapping is done, only that > > > > it can be done somehow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > > > > packet. In many cases, the end timestamp is merely when > > > > > > > the flow timed out and has nothing to do with when the > > > > > > > last packet was seen. Allowing both semantics may be useful. > > > > > > > A re-wording like this... > > > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > > > > start and end of a flow. The metering process MAY also provide > > > > > > > timestamps for the first and the last observed packet > > > > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > > > > the one with the desired meaning. > > > > > > > > > > > > OPEN > > > > > > > > > > > > This issue still needs more dialogue to gain clarity. > > > > > > > > > > > > Ganesh believes it is possible to detect last packet time within > > > > > > msec accuracy. > > > > > > > > > > Well, as you mentioned a while ago if some one implements an ager > > > > > which ages out a million cache entries in s/w, the answer is no. It > > > > > seems to me it is not something a vendor would venture into doing. > > > > > It is a good time for some doing something in the similar lines to speak up;) > > > > > Thanks > > > > > Ganesh > > > > > > > > Some vendors already do this. It is not a theoretical problem > > > > but a real one. And you don't need a million flows for it > > > > to be a problem. You could have just one flow. If the > > > > ager checks say every 30 seconds, then your end time has > > > > a maximum of a 30 second delay. > > > > > > Is that for some reason or is it a limitation in the implementation? > > > -ganesh > > > > It is merely software based aging. Probably just an initial > > system design choice. > > Are you indicating that there could be products in which the design > cannot be changed to suit the msec granularity timing requirements > of IPFIX? Yes, because if there is no current hardware support and there can be lots of flows then you don't have much choice but to increase the aging time. That type of platform exists today. Paul > -ganesh > > > > > > > Paul > > > > > > > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe it is not possible without hardware assist and not > > > > > > all platform will have that capability. > > > > > > > > > > > > > > > > > > > > 6.1 information Model > > > > > > > > > > > > > > 9 Packet Counter > > > > > > > 10 Byte counter > > > > > > > > > > > > > > As mentioned earlier, for fragments this > > > > > > > requires state information? If there is no > > > > > > > state info, then what flow are the counted > > > > > > > towards? > > > > > > > > > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > > > > > counter section since fragment counting is a matter > > > > > > for flow designation. > > > > > > > > > > > > > > > > > > > > 13 BGP AS number > > > > > > > > > > > > > > Is this the AS number for the observation point, the > > > > > > > source/destination address in the packet or some > > > > > > > combination? > > > > > > > > > > > > RESOLVED: These MAY be reported. > > > > > > > > > > > > 1. Source IP AS > > > > > > 2. Destination IP AS > > > > > > 3. Observation Point AS (which may be a a list if it > > > > > > participates on more than one) > > > > > > > > > > > > I would like to propose 2 more > > > > > > > > > > > > Next hop AS > > > > > > previous hop AS > > > > > > > > > > Why not the AS PATH? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > > > > label has no meaning. > > > > > > > > > > > > > > 21 multicast replication number > > > > > > > > > > > > > > The document stated this can change over the life > > > > > > > of the flow. But no mention of what happens when > > > > > > > it changes. Is that a new flow? If not, what meaning > > > > > > > does it have when reported? What can I do with it? > > > > > > > > > > > > RESOLVED: If a new flow is desired, it becomes part of the > > > > > > "Distinguishing Properties". If not, then it can still > > > > > > be reported and ignored when it changes. > > > > > > > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > > > > > > > What about allowing Vendors to add information independently? > > > > > > > Some data to be transported may be vendor specific and never > > > > > > > make it into the IPFIX spec. > > > > > > > > > > > > RESOLVED: It is allowed now and we do not need to mention > > > > > > it specifically. > > > > > > > > > > > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > > > > > > > No mention is made when reporting to several devices > > > > > > > of ensuring the duplicate data does not cause a double > > > > > > > counting problem. > > > > > > > > > > > > RESOLVED: This requirement needs to be added. > > > > > > > > > > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Please note that here, the observation > > > > > > > point of a single flow cannot exceed the set of most fine-granular > > > > > > > observation points linked to a single metering process, because only > > > > > > > the metering process can merge packets observed at different fine- > > > > > > > granular observation points to a joint flow. > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Also the > > > > > > > locations of metering processes are not of any relevance for this > > > > > > > document (in contrast to the locations of observation points and the > > > > > > > exporting processes). > > > > > > > > > > > > > > > > > > > These were just for my understanding. > > > > > > > > > > > > > Paul > > > > > > > > > > > > -- > > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > > "unsubscribe ipfix" in message body > > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Sep 26 16:16:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20457 for ; Thu, 26 Sep 2002 16:16:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17uetS-0004Fq-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 Sep 2002 15:05:50 -0500 Received: from pool-129-44-38-38.ny325.east.verizon.net ([129.44.38.38] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17uetQ-0004Fj-00 for ipfix-req@net.doit.wisc.edu; Thu, 26 Sep 2002 15:05:48 -0500 Received: from SET (set [192.168.0.161]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g8QK5RO18028; Thu, 26 Sep 2002 16:05:27 -0400 Reply-To: From: "Carter Bullard" To: , "'Ganesh Sadasivan'" Cc: "'req'" Subject: RE: [ipfix-req] Re: IPFIX Requirements Questions Date: Thu, 26 Sep 2002 16:05:10 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E5F8@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660B9667@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I apologize, and no ones fault, but e-mails with 5 levels of indention are impossible to read. Could you guys make your points so we don't have to dig for 5 minutes to find it. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of calato@riverstonenet.com Sent: Thursday, September 26, 2002 3:57 PM To: Ganesh Sadasivan Cc: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > Ganesh Sadasivan wrote: > > > > > > calato@riverstonenet.com wrote: > > > > > > > Ganesh Sadasivan wrote: > > > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > > I wanted to summarize where we are with the issues I raised > > > > > > a while back. A few still need to be resolved. > > > > > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > > > > > > As I work on the advocates document some questions have > > > > > > > come to mind on the requirements document. > > > > > > > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > > > > > > > In the case of fragmented packets there are > > > > > > > no port numbers. Are we saying flow state information > > > > > > > MUST be maintained? In general, it is not clear from > > > > > > > the document what the requirements are for fragmented > > > > > > > packets. > > > > > > > > > > > > RESOLVED: State information MAY be kept for > > > > > > proper flow designation. > > > > > > > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > > > > Why require distinguishing flows based on label. > > > > > > > What can be done with that information? > > > > > > > > > > > > RESOLVED: We agreed to distinguish by label and to > > > > > > report label. > > > > > > > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > > > > > > > This section needs to be re-worked a little. Some > > > > > > > of the MUST's impose undue burden on the device. > > > > > > > > > > > > > > 1. Must distinguish flow records before and after the > > > > > > > behavior change. > > > > > > > > > > > > > > In the case where the behavior is to drop > > > > > > > overflow flows, why do we need to distinguish > > > > > > > flows. Perhaps I misunderstood something. > > > > > > > > > > > > > > 2. All flows from previous behavior MUST be > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > > > > all existing ones. This will likely cause more overflow > > > > > > > as the get reestablished. This also seems to go to > > > > > > > far towards implementation. > > > > > > > > > > > > > > 3. Meeting process MUST NOT merge previous > > > > > > > records. > > > > > > > > > > > > > > I think what we are trying to say is flows with a different > > > > > > > definition MUST be distinguishable. How that is done is not > > > > > > > part of the requirements doc. > > > > > > > > > > > > OPEN > > > > > > > > > > > > We agreed that not all behaviors require terminating > > > > > > flows. > > > > > > > > > > > > We still need more dialogue on the following > > > > > > > > > > > > 1. Do we need to define a term for the set of properties > > > > > > that is used to distinguish flows. > > > > > > > > > > Is it enough if we give an exporter state along with the > > > > > export packet. > > > > > > > > What do you mean by "exporter state"? > > > > > > Whether it is in "overload condition" , "normal" etc. Sorry for > > > being unclear. What I meant was, use the exporter state along with > > > the other information defined in section 4.0 to distinguish > > > flows. The methods that I mentioned below are just examples of > > > implementation. > > > > I think this points to an area of weakness for us (IPFIX). We are > > having a hard time having a discussion. > > > > Lets say that DP = "Distinguising Properties". Where DP is > > the set of fields and functions, etc... that are used > > to define a flow. Lets assume for now that the set of possible > > fields and functions, etc... is fully defined somewhere > > (it's not, but assume it is for now.). > > > > If we require that each flow can be mapped to its DP > > then the discussion moves to how that happens. > > > > There are many ways. Here are a few which come to mind... > > > > Does it matter how the DP is identified & send (whether with each flow > or split across flow & control or otherwise) is sent, from a req. doc > perspective? As long as we define DP (which is what you are suggesting > to do) and tell that DP must give enough information so that the full > flow context can be derived at the collector, will it not solve this > issue? > Yes it will. I gave example to make sure we were on the same page. They would not go in the req doc. > > > > 1) send the DP with each flow. > > 2) send the DP with an ID. Then each flow contains > > a DP-ID field. > > 3) Send the DP for noraml operation and the DP for > > overload situation. Then only state changes need > > to be delivered. > > > > #3 above seems to be what you are talking about. > > > > However, I think we need to define DP as a term and the set of > > possible fields and functions first. Add the requirement of mapping > > a flow to a DP. > > As I see DP is a function of {1.metering process(s) employed, 2. > exporter state, 3. fields collected}. I don't see a direct relationship #1 and #2/#3. For example I could have a DP of source and dest IP but collect (i.e. report) Src/Dst AS number. Also, the state may change from normal to overload with no change in DP but rather a dropping of additional flows. I think DP stands pretty much on its own. In other words fields collected and the state are not part of the DP definition. Those things may influence which DP is used but they are not part of the DP definition itself. But I think we are getting a little ahead of the game. We need to define DP and its fields and functions. Once we have consensus that we need to define DP and its fields and functions and we agree we need to map flow to DP, then we can kick off the discussion. > There is a furthur inter dependency between > * 2&1 (with the exporter state change metering could change), > * 2 & 3 (with the exporter state change fields collected could > change), > * 1 & 3 (fields are input tometering functions). > > Am I missing anything? > > > Then the discussion can move to how we > > can best do the mapping. Then the discussion of what happens > > under overload conditions will be clearer. > > > > > > > > > > > > > > > > > > This assumes that a control infromation which explaining the > > > > > action taken corresponding to the exporter state has been send > > > > > apriori. > > > > > > > > Statement #1 above doesn't say anything about what is sent > > > > when or where. > > > > > > > > I'm asking more of a spec question. We don't define a term for the > > > > set of properties that are used to uniquely identify a > > > > flow. > > > > > > > > > This way > > > > > the flows itself need not be changed. > > > > > The other way is to send a different flow. > > > > > > > > This is the same as terminating exiting flows, which I'm > > > > trying to avoid. > > > > > > Why so? > > > > Because you are going to send a new flow for all existing flows > > during overload sitiation. It will probably not be 1 for 1 but > > rather many flows now being collapsed into one during > > overload. > > > > Isn't that what you meant by "send a different flow". > > Yes. But why do we not leave room for such a case? The current document says all flows must be terminated. I was pushing to allow for other alternatives, including terminating all flows. > > > > > > > > > > > > > > > > > > > Even though the export record > > > > > may look the same, it is identified by a different id and the > > > > > id->config mapping is assumed to have been send when the > > > > > overload condition started. > > > > > > > > > > > > > > > > > > > > > > > 2. Do we need to require that flows can be mapped to the > > > > > > term defined in #1 > > > > > > > > > > It depends on the apporach taken. > > > > > > > > I don't think it does. Statement #2 say we need to ba able to > > > > tell which flow mapped to which definition. It doesn't > > > > say anything about how that mapping is done, only that > > > > it can be done somehow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > > > > packet. In many cases, the end timestamp is merely when > > > > > > > the flow timed out and has nothing to do with when the > > > > > > > last packet was seen. Allowing both semantics may be useful. > > > > > > > A re-wording like this... > > > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > > > > start and end of a flow. The metering process MAY also provide > > > > > > > timestamps for the first and the last observed packet > > > > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > > > > the sysUpTime [RFC1213], which is one > > > > > > > centisecond. > > > > > > > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > > > > the one with the desired meaning. > > > > > > > > > > > > OPEN > > > > > > > > > > > > This issue still needs more dialogue to gain > > > > > > clarity. > > > > > > > > > > > > Ganesh believes it is possible to detect last packet time within > > > > > > msec accuracy. > > > > > > > > > > Well, as you mentioned a while ago if some one implements an > > > > > ager which ages out a million cache entries in s/w, the answer > > > > > is no. It seems to me it is not something a vendor would > > > > > venture into doing. It is a good time for some doing something > > > > > in the similar lines to speak up;) Thanks Ganesh > > > > > > > > Some vendors already do this. It is not a theoretical problem > > > > but a real one. And you don't need a million flows for it > > > > to be a problem. You could have just one flow. If the > > > > ager checks say every 30 seconds, then your end time has > > > > a maximum of a 30 second delay. > > > > > > Is that for some reason or is it a limitation in the > > > implementation? -ganesh > > > > It is merely software based aging. Probably just an initial > > system design choice. > > Are you indicating that there could be products in which the design > cannot be changed to suit the msec granularity timing requirements of > IPFIX? Yes, because if there is no current hardware support and there can be lots of flows then you don't have much choice but to increase the aging time. That type of platform exists today. Paul > -ganesh > > > > > > > Paul > > > > > > > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe it is not possible without hardware assist and not > > > > > > all platform will have that capability. > > > > > > > > > > > > > > > > > > > > 6.1 information Model > > > > > > > > > > > > > > 9 Packet Counter > > > > > > > 10 Byte counter > > > > > > > > > > > > > > As mentioned earlier, for fragments this > > > > > > > requires state information? If there is no > > > > > > > state info, then what flow are the counted > > > > > > > towards? > > > > > > > > > > > > RESOLVED(I think): no mention needs to me made in the packet or byte > > > > > > counter section since fragment counting is a matter > > > > > > for flow designation. > > > > > > > > > > > > > > > > > > > > 13 BGP AS number > > > > > > > > > > > > > > Is this the AS number for the observation point, the > > > > > > > source/destination address in the packet or some > > > > > > > combination? > > > > > > > > > > > > RESOLVED: These MAY be reported. > > > > > > > > > > > > 1. Source IP AS > > > > > > 2. Destination IP AS > > > > > > 3. Observation Point AS (which may be a a list if it > > > > > > participates on > > > > > > more than one) > > > > > > > > > > > > I would like to propose 2 more > > > > > > > > > > > > Next hop AS > > > > > > previous hop AS > > > > > > > > > > Why not the AS PATH? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > > > > label has no meaning. > > > > > > > > > > > > > > 21 multicast replication number > > > > > > > > > > > > > > The document stated this can change over the life > > > > > > > of the flow. But no mention of what happens when > > > > > > > it changes. Is that a new flow? If not, what meaning > > > > > > > does it have when reported? What can I do > > > > > > > with it? > > > > > > > > > > > > RESOLVED: If a new flow is desired, it becomes part of the > > > > > > "Distinguishing Properties". If not, then it can still > > > > > > be reported and ignored when it changes. > > > > > > > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > > > > > > > What about allowing Vendors to add information independently? > > > > > > > Some data to be transported may be vendor specific and never > > > > > > > make it into the IPFIX spec. > > > > > > > > > > > > RESOLVED: It is allowed now and we do not need to mention > > > > > > it specifically. > > > > > > > > > > > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > > > > > > > No mention is made when reporting to several devices > > > > > > > of ensuring the duplicate data does not cause a double > > > > > > > counting problem. > > > > > > > > > > > > RESOLVED: This requirement needs to be added. > > > > > > > > > > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Please note that here, the observation > > > > > > > point of a single flow cannot exceed the set of most fine-granular > > > > > > > observation points linked to a single metering process, because only > > > > > > > the metering process can merge packets observed at different fine- > > > > > > > granular observation points to a joint flow. > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Also the > > > > > > > locations of metering processes are not of any relevance for this > > > > > > > document (in contrast to the locations of observation points and the > > > > > > > exporting processes). > > > > > > > > > > > > > > > > > > > These were just for my understanding. > > > > > > > > > > > > > Paul > > > > > > > > > > > > -- > > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > > "unsubscribe ipfix" in message body > > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 05:26:51 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27243 for ; Mon, 30 Sep 2002 05:26:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17vwbG-00022M-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 04:12:22 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17vwbD-000229-00 for ipfix-eval@net.doit.wisc.edu; Mon, 30 Sep 2002 04:12:19 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id VAA02381 for ; Mon, 30 Sep 2002 21:12:17 +1200 (NZST) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AIE95727; Mon, 30 Sep 2002 21:12:16 +1200 (NZST) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id g8U9CGJ06064 for ; Mon, 30 Sep 2002 21:12:16 +1200 Received: from 129.69.30.65 ([129.69.30.65]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Mon, 30 Sep 2002 21:12:16 +1200 Message-ID: <1033377136.3d981570c042b@hotlava.auckland.ac.nz> Date: Mon, 30 Sep 2002 21:12:16 +1200 From: Nevil Brownlee To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] RE: evaluation process MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 129.69.30.65 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Peter: Quoting Peter Ludemann : > > So far there's been no discussion of any of the Advocacy Drafts on > > the list. If you have opinions about one or more of them, now's the > > time to post your comments! At this stage the advocates can edit/ > > modify/improve their drafts and republish, any time until 18 October. > > Will there be clarification questions from the Evaluation Team to the > authors of the various proposals? I'm thinking of the normal industry "RFP" > process (I've just gone through a few of these and am still in pain), where > the process usually is: > > 1. Publication of a Request For Proposals (RFP) > 2. Clarification questions about the RFP (from the responders) > 3. Submission of complete responses + presentations > 4. Follow-up questions to the responders > 5. Short list (usually 2-3) > 6. More follow-up questions > 7. Decision > 8. Contract negotiations, Statement of Work > > In the case of IPFIX, we've done up to stage 3. > Will there be a step 5 (short list)? > For step 6 (questions from the Evaluation Team), will the questions and > responses be private or public? > Do we want comments about the advocacy drafts from people outside the > Evaluation Team or are the Advocacy Drafts the final word? I'd like to see some discussion of the advocate drafts on this list, after all this is an IETF WG, where all discussion is on the list (and therefore in the list archive). If everyone waits to see what the Evaluation Team comes up with in their 'Evaluation' draft, that will just shorten the time for discussion before the Atlanta IETF meeting! So to answer your question, I believe your steps 4,5 and 6 should happen on the list over the next few weeks. Step 7 should happen on the list bfeore Atlanta, to be confirmed by a WG last call after Atlanta. Step 8, I guess, corresponds to producing the Architecture and Data Model RFCs, which should happen soon after the Evaluation consensus is reached. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 06:12:41 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27649 for ; Mon, 30 Sep 2002 06:12:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17vxM0-00044s-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 05:00:40 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17vxLy-0003uN-00; Mon, 30 Sep 2002 05:00:38 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UA05X17229; Mon, 30 Sep 2002 03:00:05 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 03:00:05 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C04119EF5@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] IPFIX Requirement draft status - section 6.3.2 Date: Mon, 30 Sep 2002 03:00:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26868.25671DBC" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26868.25671DBC Content-Type: text/plain; charset="iso-8859-1" Hello, I'm looking to understand/really clarify this requirement. It seems ambiguous...at least to me. I do not understand what is the meaning/purpose of "-->abscence<-- of reliability....MUST be indicated". Shouldn't we just rephrase that by just saying that the protocol MUST be reliable, provide in-sequence delivery and retransmission? It seems to me we should have 2 options: 1. The IPfix protocol runs over TCP or SCTP 2. The ipfix protocol does not run over TCP or TCP but provide a service equal or in excess to what is provided by TCP/SCTP in terms of reliability, congestion awareness and in-sequence delivery. Reading this text I feel there is a third option which is: 3. "the protocol should run over TCP or SCTP, but you can sidestep this requirement by putting a sequence number on the application layer and/or providing 'abscence' of reliability"... Or maybe one should ask what's the definition of a reliable protocol as far as the ipfix protocol is concerned... "6.3.2. Reliability Absence of reliability of the data transfer, for example caused by loss or reordering of packets containing flow information, MUST be indicated. Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet." regards, Reinaldo ------_=_NextPart_001_01C26868.25671DBC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Requirement draft status - section 6.3.2

Hello,

I'm looking to understand/really clarify this = requirement. It seems ambiguous...at least to me. I do not understand = what is the meaning/purpose of "-->abscence<-- of = reliability....MUST be indicated". Shouldn't we just rephrase that = by just saying that the protocol MUST be reliable, provide in-sequence = delivery and retransmission?

It seems to me we should have 2 options:

1. The IPfix protocol runs over TCP or SCTP
2. The ipfix protocol does not run over TCP or TCP = but provide a service equal or in excess to what is provided by = TCP/SCTP in terms of reliability, congestion awareness and in-sequence = delivery.

Reading this text I feel there is a third option = which is:

3. "the protocol should run over TCP or SCTP, = but you can sidestep this requirement by putting a sequence number on = the application layer and/or providing 'abscence' of = reliability"...

Or maybe one should ask what's the definition of a = reliable protocol as far as the ipfix protocol is concerned...

"6.3.2.  Reliability

   Absence of reliability of the data = transfer, for example caused by
   loss or reordering of packets = containing flow information, MUST be
   indicated.

   Please note that if an unreliable = transport protocol is used,
   reliability can be provided by higher = layers. In such a case only
   lack of overall reliability MUST be = indicated. For example reordering
   could be dealt with by adding a = sequence number to each packet."

regards,

Reinaldo

------_=_NextPart_001_01C26868.25671DBC-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 08:42:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01305 for ; Mon, 30 Sep 2002 08:42:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17vzlI-0001z2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 07:34:56 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17vzlF-0001yQ-00; Mon, 30 Sep 2002 07:34:53 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UCYKX18305; Mon, 30 Sep 2002 05:34:21 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 05:34:20 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C04119F09@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] IPFIX Requirement draft status - section 5.8 Date: Mon, 30 Sep 2002 05:34:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2687D.B153C2D4" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2687D.B153C2D4 Content-Type: text/plain; charset="iso-8859-1" I wonder if requirement 5.8 is relevant at all when choosing the IPfix protocol...More generally should metering requirements matter when choosing the IPfix protocol? Let's suppose we choose lfap as the protocol. Are they going to give me the meter also? I think not...Well, even if they give it to me I'll probably never use it since is platform dependent. Taking this one step further to clarify the analogy. For example, let's suppose we choose Diameter as the Ipfix protocol. Well, clearly diameter does not have a meter built into it, and Diameter is a candidate. 5.8. Ignore Port Copy The metering process MAY be able to ignore packets which are generated by a port copy function acting at the device where the observation point of a flow is located. ------_=_NextPart_001_01C2687D.B153C2D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Requirement draft status - section 5.8

I wonder if requirement 5.8 is relevant at all when = choosing the IPfix protocol...More generally should metering = requirements matter when choosing the IPfix protocol?

Let's suppose we choose lfap as the protocol. Are = they going to give me the meter also? I think not...Well, even if they = give it to me I'll probably never use it since is platform dependent. =

Taking this one step further to clarify the analogy. = For example, let's suppose we choose Diameter as the Ipfix protocol. = Well, clearly diameter does not have a meter built into it, and = Diameter is a candidate.


5.8.  Ignore Port Copy

   The metering process MAY be able to = ignore packets which are
   generated by a port copy function = acting at the device where the
   observation point of a flow is = located.

------_=_NextPart_001_01C2687D.B153C2D4-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 09:07:15 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02124 for ; Mon, 30 Sep 2002 09:07:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w00I-0002KR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 07:50:26 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w00G-0002JF-00; Mon, 30 Sep 2002 07:50:24 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UCnpX18441; Mon, 30 Sep 2002 05:49:52 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 05:49:51 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C04119F16@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] IPFIX Requirement draft status - section 6.6 Date: Mon, 30 Sep 2002 05:49:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2687F.DC168E5A" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2687F.DC168E5A Content-Type: text/plain; charset="iso-8859-1" I would like to understand this requirement in view of the debates regarding privacy and anonymization on the Internet. I wonder if the method to guarantee anonymization is to report a greater prefix is acceptable. Well, but if the whole block is offically assigned or in the extreme cases of portable blocks? You could not trace back to individual, but certainly to a institution you can. Since the requirement is a MAY anyway, maybe we could say that anonymization is not to report the field in question at all if the prefix or a subset of it can be traced back to the parties interested in anonymization. 6.6. Anonymization The exporting process MAY be capable of anonymizing source and destination IP addresses in flow data before exporting them. It MAY support anonymization of port numbers and other fields. Please note that anonymization is not originally an application requirement, but derived from general requirements for treatment of traffic within a network. thanks, Reinaldo ------_=_NextPart_001_01C2687F.DC168E5A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Requirement draft status - section 6.6

I would like to understand this requirement in view = of the debates regarding privacy and anonymization on the Internet. I = wonder if the method to guarantee anonymization is to report a greater = prefix is acceptable. Well, but if the whole block is offically = assigned or in the extreme cases of portable blocks? You could not = trace back to individual, but certainly to a institution you can. =

Since the requirement is a MAY anyway, maybe we could = say that anonymization is not to report the field in question at all = if  the prefix or a subset of it can be traced back to the parties = interested in anonymization.

6.6.  Anonymization

   The exporting process MAY be capable of = anonymizing source and
   destination IP addresses in flow data = before exporting them. It MAY
   support anonymization of port numbers = and other fields. Please note
   that anonymization is not originally an = application requirement, but
   derived from general requirements for = treatment of traffic within a
   network.


thanks,

Reinaldo

------_=_NextPart_001_01C2687F.DC168E5A-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 12:27:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10913 for ; Mon, 30 Sep 2002 12:27:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w3BV-0000ab-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 11:14:13 -0500 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w3BT-0000Zt-00 for ipfix-req@net.doit.wisc.edu; Mon, 30 Sep 2002 11:14:11 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UGDWaW021168; Mon, 30 Sep 2002 09:13:33 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-27.cisco.com [171.71.137.27]) by mira-sjcd-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI50866; Mon, 30 Sep 2002 09:14:35 -0700 (PDT) Message-ID: <3D987831.5B277F0B@cisco.com> Date: Mon, 30 Sep 2002 09:13:37 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D761701.E5986839@riverstonenet.com> <3D926ED7.55A3E8E@cisco.com> <3D9316A7.54B16699@riverstonenet.com> <3D932A40.D96DD195@cisco.com> <3D933258.B9BD4EA0@riverstonenet.com> <3D9357CB.4DC32290@cisco.com> <3D936678.639BBEE6@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Just taking the topic of DP alone. > > > > > > > I think this points to an area of weakness for us (IPFIX). We are > > > having a hard time having a discussion. > > > > > > Lets say that DP = "Distinguising Properties". Where DP is > > > the set of fields and functions, etc... that are used > > > to define a flow. Lets assume for now that the set of possible > > > fields and functions, etc... is fully defined somewhere > > > (it's not, but assume it is for now.). > > > > > > If we require that each flow can be mapped to its DP > > > then the discussion moves to how that happens. > > > > > > There are many ways. Here are a few which come to mind... > > > > > > > Does it matter how the DP is identified & send (whether with each flow or split > > across flow & control or otherwise) is sent, from a req. doc perspective? > > As long as we define DP (which is what you are suggesting to do) and tell that DP > > must give enough information so that the full flow context can be derived at the > > collector, will it not solve this issue? > > > > Yes it will. I gave example to make sure we were on the > same page. They would not go in the req doc. > > > > > > > 1) send the DP with each flow. > > > 2) send the DP with an ID. Then each flow contains > > > a DP-ID field. > > > 3) Send the DP for noraml operation and the DP for > > > overload situation. Then only state changes need > > > to be delivered. > > > > > > #3 above seems to be what you are talking about. > > > > > > However, I think we need to define DP as a term and the set of > > > possible fields and functions first. Add the requirement of mapping > > > a flow to a DP. > > > > As I see DP is a function of {1.metering process(s) employed, 2. exporter state, > > 3. fields collected}. > > I don't see a direct relationship #1 and #2/#3. For example > I could have a DP of source and dest IP but collect (i.e. report) > Src/Dst AS number. Also, the state may change from normal > to overload with no change in DP but rather a dropping of > additional flows. It depends on the overload policy. * If it is such that say more aggregation (by using less fields) is done in the case of an overload (which effecively reduces the # of records exported) then there is a relation between 1 & fields exported (may not be the fields collected as I mentioned above). * If there are fields extracted in the packet path which are not directly derived from the packet (like AS #) in the case of an overload, one may not collect these fields in the packet path itself. * When the exporter state is changed to overload, the metering process may be changed from sampling interval X to Y. Thanks Ganesh > > > I think DP stands pretty much on its own. > In other words > fields collected and the state are not part of the DP > definition. Those things may influence which DP is used > but they are not part of the DP definition itself. > > But I think we are getting a little ahead of the game. > We need to define DP and its fields and functions. > > Once we have consensus that we need to define DP and its > fields and functions and we agree we need to map flow > to DP, then we can kick off the discussion. > > > There is a furthur inter dependency between > > * 2&1 (with the exporter state change metering could change), > > * 2 & 3 (with the exporter state change fields collected could change), > > * 1 & 3 (fields are input tometering functions). > > > > Am I missing anything? > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 12:45:44 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11936 for ; Mon, 30 Sep 2002 12:45:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w3VV-0001FZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 11:34:53 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w3VT-0001F0-00; Mon, 30 Sep 2002 11:34:51 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UGYUU17828; Mon, 30 Sep 2002 11:34:31 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 09:34:16 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C0411A0DF@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req , ipfix-arch@net.doit.wisc.edu Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] Collision between IPFIX Architecture section 5.1 and Requirement draft Date: Mon, 30 Sep 2002 09:34:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2689F.35FE4420" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2689F.35FE4420 Content-Type: text/plain; charset="iso-8859-1" In the beggining of section 5.1 it is stated that "This is based on the requirements specified in the requirement document [2]." But I couldn't find a peer of some of the requirements from architecture draft on the requirements draft. Will these be included on the requirements draft? Excluded from the architecture? For example.... 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) 1. Ability to detect loss of connectivity with the collector and trigger the appropriate action (eg. a switch over to an alternate collector.) <--- 2. Optionally export flow records to multiple collectors. 3. Optionally re-transmit lost flow records. <--- 4. Exchange control information from the collector, monitor export process and detect any overload in the process of exporting. <--- P I would suggest to just take out the requirement section from the architecture draft and incorporate the relevant parts into the requirements draft to avoid confusion and repetition. If people do not agree it would be good if the editors of both documents would put them side by side and compare the wording. thanks, Reinaldo ------_=_NextPart_001_01C2689F.35FE4420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Collision between IPFIX Architecture section 5.1 and = Requirement draft

In the beggining of section 5.1 it is stated = that

"This is based on the requirements specified in = the requirement
   document [2]."

But I couldn't find a peer of some of the = requirements from architecture draft on the requirements draft. Will = these be included on the requirements draft? Excluded from the = architecture? For example....

5.1.2. IPFIX Protocol on IPFIX Device (At Export = Process)

     1. Ability to detect loss of = connectivity with the collector and
        trigger = the appropriate action (eg. a switch over to an
        alternate = collector.) <---
     2. Optionally export flow = records to multiple collectors.
     3. Optionally re-transmit = lost flow records. <---
     4. Exchange control = information from the collector, monitor export
        process = and detect any overload in the process of exporting. <--- P


I would suggest to just take out the requirement = section from the architecture draft and incorporate the relevant parts = into the requirements draft to avoid confusion and repetition. If = people do not agree it would be good if the editors of both documents = would put them side by side and compare the wording.

thanks,

Reinaldo

------_=_NextPart_001_01C2689F.35FE4420-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 13:04:51 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12694 for ; Mon, 30 Sep 2002 13:04:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w3mp-0001h8-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 11:52:47 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w3VT-0001F0-00; Mon, 30 Sep 2002 11:34:51 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UGYUU17828; Mon, 30 Sep 2002 11:34:31 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 09:34:16 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C0411A0DF@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req , ipfix-arch@net.doit.wisc.edu Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-arch] Collision between IPFIX Architecture section 5.1 and Requirement draft Date: Mon, 30 Sep 2002 09:34:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2689F.35FE4420" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2689F.35FE4420 Content-Type: text/plain; charset="iso-8859-1" In the beggining of section 5.1 it is stated that "This is based on the requirements specified in the requirement document [2]." But I couldn't find a peer of some of the requirements from architecture draft on the requirements draft. Will these be included on the requirements draft? Excluded from the architecture? For example.... 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) 1. Ability to detect loss of connectivity with the collector and trigger the appropriate action (eg. a switch over to an alternate collector.) <--- 2. Optionally export flow records to multiple collectors. 3. Optionally re-transmit lost flow records. <--- 4. Exchange control information from the collector, monitor export process and detect any overload in the process of exporting. <--- P I would suggest to just take out the requirement section from the architecture draft and incorporate the relevant parts into the requirements draft to avoid confusion and repetition. If people do not agree it would be good if the editors of both documents would put them side by side and compare the wording. thanks, Reinaldo ------_=_NextPart_001_01C2689F.35FE4420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Collision between IPFIX Architecture section 5.1 and = Requirement draft

In the beggining of section 5.1 it is stated = that

"This is based on the requirements specified in = the requirement
   document [2]."

But I couldn't find a peer of some of the = requirements from architecture draft on the requirements draft. Will = these be included on the requirements draft? Excluded from the = architecture? For example....

5.1.2. IPFIX Protocol on IPFIX Device (At Export = Process)

     1. Ability to detect loss of = connectivity with the collector and
        trigger = the appropriate action (eg. a switch over to an
        alternate = collector.) <---
     2. Optionally export flow = records to multiple collectors.
     3. Optionally re-transmit = lost flow records. <---
     4. Exchange control = information from the collector, monitor export
        process = and detect any overload in the process of exporting. <--- P


I would suggest to just take out the requirement = section from the architecture draft and incorporate the relevant parts = into the requirements draft to avoid confusion and repetition. If = people do not agree it would be good if the editors of both documents = would put them side by side and compare the wording.

thanks,

Reinaldo

------_=_NextPart_001_01C2689F.35FE4420-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 13:35:37 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14037 for ; Mon, 30 Sep 2002 13:35:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w4KB-0002pR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 12:27:15 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w4K8-0002oX-00; Mon, 30 Sep 2002 12:27:12 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UHQsU04661; Mon, 30 Sep 2002 12:26:54 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 10:26:39 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C0411A1DC@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] Requirements drafts, NATed flows and VPNs Date: Mon, 30 Sep 2002 10:26:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C268A6.8718DD6E" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C268A6.8718DD6E Content-Type: text/plain; charset="iso-8859-1" Hello, I think there are some important packet fields/scenarios that should be included in the requirements draft. 1 - We discussed a long time ago to include the VPN-ID as one of the parameters exported. If Ipfix will be used in VPN environments for accouting, QoS, monitoring, etc, this field is a must. 2 - There is mention to intrusion detection/security as one of the applications for IPfix, but there is no requirement to export NATed flows (before and after). In a device that supports NAT (traditional, layer 7 interception, whatever) and it's going to use IPfix for security/intrusion detection, dealing with NAT is must. There is no way a intrusion detection device will find attacker/attacked properly without both sides of a NAT flow. Not to mention accouting, billing, etc. I would propose to include both items on the requirements draft. regards, Reinaldo ------_=_NextPart_001_01C268A6.8718DD6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Requirements drafts, NATed flows and VPNs

Hello,


I think there are some important packet = fields/scenarios that should be included in the requirements draft. =

1 - We discussed a long time ago to include the = VPN-ID as one of the parameters exported. If Ipfix will be used in VPN = environments for accouting, QoS, monitoring, etc, this field is a = must.

2 - There is mention to intrusion detection/security = as one of the applications for IPfix, but there is no requirement to = export NATed flows (before and after).

In a device that supports NAT (traditional, layer 7 = interception, whatever) and it's going to use IPfix for = security/intrusion detection, dealing with NAT is must. There is no way = a intrusion detection device will find attacker/attacked properly = without both sides of a NAT flow. Not to mention accouting, billing, = etc.

I would propose to include both items on the = requirements draft.

regards,

Reinaldo

------_=_NextPart_001_01C268A6.8718DD6E-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 14:05:40 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15662 for ; Mon, 30 Sep 2002 14:05:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w4mV-0003Ww-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 12:56:31 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17w4mS-0003Wm-00 for ipfix-req@net.doit.wisc.edu; Mon, 30 Sep 2002 12:56:28 -0500 Received: (qmail 3911 invoked from network); 30 Sep 2002 17:56:26 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 30 Sep 2002 17:56:26 -0000 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g8UHxSs11698; Mon, 30 Sep 2002 10:59:28 -0700 From: "Peter Ludemann" To: "Reinaldo Penno" , "req" Cc: Subject: RE: [ipfix-req] IPFIX Requirement draft status - section 6.3.2 Date: Mon, 30 Sep 2002 10:56:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C26870.06D56770" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <7B802811BE77D51189910002A55CFD2C04119EF5@zsc3c032.us.nortel.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C26870.06D56770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPFIX Requirement draft status - section 6.3.2Here's another situation: the connection is broken for an extended period (or if there are very slow ACKs) and internal queues fill up on the exporting device. One way to indicate absence of reliability is by detecting a gap in the sequence numbers at the collector when the connection is reestablished. (Is there any other solution?) And if the exporter were to reboot in the interim, what then? CRANE's solution to this is to use a combination of exporter "boot time" and sequence number -- the primary reason is not for detecting data loss due to queue overflow, but for deduplication on fail-over. However, it is not clear how to handle the case of a restart of the exporter, if it changes boot time or forces a new initial sequence number. The exporter may output a separate stream of data (over the same or another connection) which contains status information, such as records lost due to queue overflow; but this is not mandated by the CRANE protocol. The information might also be provided on demand by CRANE's "STATUS REQUEST". - peter -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, September 30, 2002 3:00 AM To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] IPFIX Requirement draft status - section 6.3.2 Hello, I'm looking to understand/really clarify this requirement. It seems ambiguous...at least to me. I do not understand what is the meaning/purpose of "-->abscence<-- of reliability....MUST be indicated". Shouldn't we just rephrase that by just saying that the protocol MUST be reliable, provide in-sequence delivery and retransmission? It seems to me we should have 2 options: 1. The IPfix protocol runs over TCP or SCTP 2. The ipfix protocol does not run over TCP or TCP but provide a service equal or in excess to what is provided by TCP/SCTP in terms of reliability, congestion awareness and in-sequence delivery. Reading this text I feel there is a third option which is: 3. "the protocol should run over TCP or SCTP, but you can sidestep this requirement by putting a sequence number on the application layer and/or providing 'abscence' of reliability"... Or maybe one should ask what's the definition of a reliable protocol as far as the ipfix protocol is concerned... "6.3.2. Reliability Absence of reliability of the data transfer, for example caused by loss or reordering of packets containing flow information, MUST be indicated. Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet." regards, Reinaldo ------=_NextPart_000_001A_01C26870.06D56770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Requirement draft status - section = 6.3.2
Here's another situation: the connection is broken for an = extended=20 period (or if there are very slow ACKs) and internal queues fill up = on the=20 exporting device. One way to indicate absence of reliability is by = detecting a=20 gap in the sequence numbers at the collector when the connection is = reestablished. (Is there any other solution?) And if the exporter were = to reboot=20 in the interim, what then?
CRANE's solution to this is to use a combination of exporter = "boot=20 time" and sequence number -- the primary reason is not for detecting = data loss=20 due to queue overflow, but for deduplication on fail-over.=20 However, it is not clear how to handle the case of a restart = of the=20 exporter, if it changes boot time or forces a new initial = sequence=20 number. The exporter may output a separate stream of = data (over=20 the same or another connection) which contains status information, = such as=20 records lost due to queue overflow; but this is not mandated by the = CRANE=20 protocol. The information might also be provided on=20 demand by CRANE's "STATUS = REQUEST".
-=20 peter
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Monday, September 30, 2002 3:00 AM
To: = req
Cc: ipfix-eval-team@net.doit.wisc.edu
Subject: = [ipfix-req] IPFIX Requirement draft status - section=20 6.3.2

Hello,

I'm looking to understand/really clarify this = requirement. It=20 seems ambiguous...at least to me. I do not understand what is the=20 meaning/purpose of "-->abscence<-- of reliability....MUST be = indicated".=20 Shouldn't we just rephrase that by just saying that the protocol MUST = be=20 reliable, provide in-sequence delivery and retransmission?

It seems to me we should have 2 options:

1. The IPfix protocol runs over TCP or SCTP =
2. The ipfix protocol does not run over TCP or TCP but = provide a=20 service equal or in excess to what is provided by TCP/SCTP in terms of = reliability, congestion awareness and in-sequence delivery.

Reading this text I feel there is a third option = which=20 is:

3. "the protocol should run over TCP or SCTP, but = you can=20 sidestep this requirement by putting a sequence number on the = application=20 layer and/or providing 'abscence' of reliability"...

Or maybe one should ask what's the definition of a = reliable=20 protocol as far as the ipfix protocol is concerned...

"6.3.2.  Reliability

   Absence of reliability of the data = transfer, for=20 example caused by
   loss or = reordering of=20 packets containing flow information, MUST be
   indicated.

   Please note that if an unreliable = transport=20 protocol is used,
   reliability = can be=20 provided by higher layers. In such a case only
   lack of overall reliability MUST be indicated. = For example=20 reordering
   could be dealt with = by adding=20 a sequence number to each packet."

regards,

Reinaldo

------=_NextPart_000_001A_01C26870.06D56770-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 14:07:36 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15741 for ; Mon, 30 Sep 2002 14:07:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w4qP-0003eE-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 13:00:34 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17w4qN-0003dz-00 for ipfix-req@net.doit.wisc.edu; Mon, 30 Sep 2002 13:00:31 -0500 Received: (qmail 4140 invoked from network); 30 Sep 2002 18:00:28 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 30 Sep 2002 18:00:28 -0000 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g8UI3Vs11792; Mon, 30 Sep 2002 11:03:31 -0700 From: "Peter Ludemann" To: "Reinaldo Penno" , "req" Cc: Subject: RE: [ipfix-req] IPFIX Requirement draft status - section 5.8 Date: Mon, 30 Sep 2002 11:00:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C26870.97B56AB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <7B802811BE77D51189910002A55CFD2C04119F09@zsc3c032.us.nortel.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C26870.97B56AB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPFIX Requirement draft status - section 5.8In our "advocacy" document, we stated that all of section 5 is not applicable, except to note that we support all the necessary data types and can export any of the proposed record structures. - peter -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, September 30, 2002 5:34 AM To: req Cc: ipfix-eval-team@net.doit.wisc.edu Subject: [ipfix-req] IPFIX Requirement draft status - section 5.8 I wonder if requirement 5.8 is relevant at all when choosing the IPfix protocol...More generally should metering requirements matter when choosing the IPfix protocol? Let's suppose we choose lfap as the protocol. Are they going to give me the meter also? I think not...Well, even if they give it to me I'll probably never use it since is platform dependent. Taking this one step further to clarify the analogy. For example, let's suppose we choose Diameter as the Ipfix protocol. Well, clearly diameter does not have a meter built into it, and Diameter is a candidate. 5.8. Ignore Port Copy The metering process MAY be able to ignore packets which are generated by a port copy function acting at the device where the observation point of a flow is located. ------=_NextPart_000_0020_01C26870.97B56AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Requirement draft status - section 5.8
In=20 our "advocacy" document, we stated that all of section 5 is not = applicable,=20 except to note that we support all the necessary data types and can = export any=20 of the proposed record structures.
 
-=20 peter
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Monday, September 30, 2002 5:34 AM
To: = req
Cc: ipfix-eval-team@net.doit.wisc.edu
Subject: = [ipfix-req] IPFIX Requirement draft status - section = 5.8

I wonder if requirement 5.8 is relevant at all when = choosing=20 the IPfix protocol...More generally should metering requirements = matter when=20 choosing the IPfix protocol?

Let's suppose we choose lfap as the protocol. Are = they going=20 to give me the meter also? I think not...Well, even if they give it to = me I'll=20 probably never use it since is platform dependent.

Taking this one step further to clarify the analogy. = For=20 example, let's suppose we choose Diameter as the Ipfix protocol. Well, = clearly=20 diameter does not have a meter built into it, and Diameter is a=20 candidate.


5.8.  Ignore Port Copy

   The metering process MAY be able to = ignore=20 packets which are
   generated by = a port=20 copy function acting at the device where the
   observation point of a flow is located.=20

------=_NextPart_000_0020_01C26870.97B56AB0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 19:18:07 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24406 for ; Mon, 30 Sep 2002 19:18:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17w9YT-00047h-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 18:02:21 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17w9YR-00047Z-00 for ipfix-eval@net.doit.wisc.edu; Mon, 30 Sep 2002 18:02:19 -0500 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id BC3426007D4 for ; Mon, 30 Sep 2002 16:02:16 -0700 (PDT) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA05476 for ; Mon, 30 Sep 2002 16:02:11 -0700 (PDT) Received: from cup.hp.com ([15.16.124.96]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20020930233301.GZHK18196.simail.cup.hp.com@cup.hp.com> for ; Mon, 30 Sep 2002 16:33:01 -0700 Message-ID: <3D98D86D.3060104@cup.hp.com> Date: Mon, 30 Sep 2002 16:04:13 -0700 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] Discussion of Candidate Protocols Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, In the interest of spurring discussion around the different candidate protocols, I've written my own brief summary of the candidates, with the expected bias (since I'm the IPDR advocate). - IPDR - much richer and more formal extensibility model, leveraging industry standard XML-Schema. Compactness as good as other candidates (after negotiation of "templates"/"descriptors"), simple set of operations. - NFv9 - compact, but extensibility model (templates) don't provide the set of information which IPDR does. Relatively simple. - Diameter - less compact due to AVP encoding model. Extensibility model formalized, but not provided as a machine readable document. Overhead of acking makes this seem too heavyweight for the requirements as specified. Finally the requirement for a recorder to support the SCTP protocol seems prohibitive, since this may require kernel support lacking on several OS's. - LFAP - has a limited (numeric id based) extensibility model. Protocol is relatively simple. The encoding is tag/len/value meaning it will be less compact than IPDR or NFv9. - CRANE - proprietary vendor format. More complex than is needed for IPFIX use case (20 different operation codes). Template based (like NFv9), has similar lack of formalism in actual definition of extensions. Regards, Jeff Meyer jeffm@cup.hp.com -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Sep 30 19:49:55 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24968 for ; Mon, 30 Sep 2002 19:49:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17wA7F-0005F4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 Sep 2002 18:38:17 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17wA7D-0005CW-00 for ipfix-req@net.doit.wisc.edu; Mon, 30 Sep 2002 18:38:15 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8UNbjU87237 for ; Tue, 1 Oct 2002 01:37:45 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3BDAC67656 for ; Tue, 1 Oct 2002 01:37:42 +0200 (CEST) Date: Tue, 01 Oct 2002 01:37:38 +0200 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] new version of requirements draft Message-ID: <15454011.1033436258@[192.168.102.31]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Today I posted a new version of the IPFIX requirements I-D. You can preview it at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-06.txt The number of discussed issues is still growing, maybe also because the advocates and the evaluators are reading the requirements in more detail now. Benoit, Sebastian, Tanja and I discussed and edited a lot of these issues and tried to identify a consensus or some solution close to consensus. Also Sebastian did a very detailed review. We think that discussion will get simpler, if some of the solutions get integrated into a new version of the I-D. All modifications we applied, are described below. If you disagree with one or more of them, please raise the issues again. Another reason for posting a new version is, that it is not really easy to follow all issues and to cover every issue raised. Thereore, I suggest that each of us raising an issue, gives the issue an identifier, for example composed by his/her name an a number, like Paul-13 or Tanja-02. Then it would be great if everyone who discusses the issue, uses the issue name in the subject field of messages concerning the issue. Maybe we can even spend the effort of numbering issues which are already under discussion. The best way of doing so would be that everybody takes care of the issues raised by herself/himself. It would be great, if we could find consensus on all remaining issues within a month. This would allow us to have a new version before the Atlanta cut-off date. Juergen ========================================================================= Changes from draft-ietf-ipfix-reqs-05.txt to draft-ietf-ipfix-reqs-06.txt ========================================================================= There were 12 fixed typos and 25 minor editorial changes. In addition, the following changes were committed: 2.1 IP Traffic Flow - replace numbered list by "1. one or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields) 2. one or more characteriscs of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...)" 2.3 Metering Process, 1st line: - "Input to the process are IP packet headers" -> "Input to the process are packet headers" - extended second sentence by "and packet treatment at the observation point, for example the selected output interface". 4. Distinguishing Flows, last line before 4.1: "the BGP Autonomous Systems. -> "the BGP Autonomous System number of the IP destination address. 5.3. Overload Behavior replaced last paragraph by "Overload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the metering process behavior, the overload behavior MUST be clearly defined. For some flows, the change of behavior might have an impact on the data that would be stored in the associated flow records after the change, for example if the packet classificaton is changed or the sampling rate. These flows MUST be considered as terminated and the associated flow records MUST be exported separately from new ones generated after the behavior change. The terminated flow records and new ones generated after the behavior change MUST NOT be merged by the metering process. The collecting process MUST be able to distinguish the affected flow records generated before and after the change of behavior. This requirement does not apply to flows and associated flow records not affected by the change of metering process behavior." 5.5. Time Synchronization, entire section: replaced "Metering processes and collecting processes SHOULD be time- synchronized with each other. Using NTP or GPS are possible ways of achieving this. However selecting a method for time synchronization is not in the scope of this document." by "It MUST be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC). Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizing timestamps generated by different metering processes. Note that this does not necessarily imply that timestamps generated by the metering process are UTC timestamps. For example, this requirement can be met by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the system clock of the metering process." 5.8. Packet Fragmentation, this section was added: In case of IP packet fragmentation and depending on the classificaiton scheme, only the zero-offset fragment of a single initial packet might contain sufficient information to classify the packet. Note that this fragment should be the first one generated by the router imposing the fragmentation [RFC791], but might not be the first one observed by the IPFIX device, due reordering reasons. The metering process MAY keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows. 6.1. Information Model: - moved MUST attribute "7. input interface (ifIndex)" to SHOULD section: "18. input interface (ifIndex)". - moved MUST attribute "8. output interface (ifIndex)" to SHOULD section: "19. output interface (ifIndex)". - replaced "9. in case of IPv4: Type of Service" by "9. type of service octet (in case of IPv4), traffic class octet (in case of IPv6)" - replaced "11. if MPLS is supported at the observation point: MPLS label" by "11. if MPLS is supported at the observation point: the top MPLS label or the corrsponding forwarding equivalence class (FEC, [RFC3031]) bound to that label. The FEC is typically defined by an IP prefix." - removed item 12: DSCP. - removed MUST attribute "13. if BGP is supported at the observation point: BGP AS number" and instead appended to the end of section 6.1: "In addition, the exporting process MAY be able to report attributes related to inter-autonomous system routing of a flow, for example by reporting BGP Autonoumous System numbers." - replaced "20. Time To Live" - by "20. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)" - appended to SHOULD attribute "19. multicast replication factor": "The computation of the factor MUST be clearly defined." - added "25. next hop IP address" 7.2. Configuration of the Exporting Process: - inserted new item into bullet list: "3. the reporting interval This requirement only applies if the exporting process supports reporting in regular intervals." - appended to 4. notifications ... "This requirement only applies if the exporting process supports notifications." 8.3. Several Collecting Processes appended "If an exporting process is able to export flow records to multiple collecting processes then it MUST be able to ensure that the flow records can be identified so that duplicates can be detected between different collecting processes and double counting problems can be avoided." 12. References added reference to RFC791. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/