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]