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] 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] 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] 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] 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] 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 ôtemplate negotiationö 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] 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 ôtemplatesö 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 û 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] 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 |<=|===========|=>|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Æs 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Æs 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] 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 | ==========> | 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] 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] 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Æs 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] 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] 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 ôflatö 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 ôflatö records. 3.4 Data Export [IPFIX-REQ Section 6] Compliances Zhang, et al. Expires - March, 2003 [Page 13] 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] 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Æs 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] 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Æs 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] 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] 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] 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] 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]