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, <http://www.ietf.org/
internet-drafts/draft-ietf-ipfix-reqs-05.txt>.
[2] Meyer, J., "Reliable Streaming Internet Protocol Detail
Records", IETF draft work in progress, August 2002, <http://
www.ietf.org/internet-drafts/draft-meyer-ipdr-streaming-
00.txt>.
[3] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.
[4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/>.
[5] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-2-
20010502/datatypes.html>.
[6] Internet Protocol Detail Record Organization, "Network Data
Management - Usage (NDM-U) For IP-Based Services Version 3.1",
April 2002, <http://www.ipdr.org/documents/NDM-U_3.1.pdf>.
[7] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 2026, August 1995, <http://www.ietf.org/rfc/rfc1832.txt>.
[8] Brownlee, N. and A. Blount, "Accounting Attributes and Record
Formats", RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
rfc2924.txt>.
[9] Kent, S., "Security Architecture for the Internet Protocol",
RFC 2401, Nov. 1998, <http://www.ietf.org/rfc/rfc2401.txt>.
[10] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, Jan.
1999, <http://www.ietf.org/rfc/rfc2246.txt>.
[11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", draft Work in progress, Jul. 2002,
<http://search.ietf.org/internet-drafts/draft-ietf-aaa-
diameter-12.txt>.
[12] Norseth, K. and P. Calato, "Data Model for IP Flow Information
Export", IETF draft work in progress, August 2002, <http://
www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt>.
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, <http://xml.resource.org/public/rfc/html/rfc2629.html>.
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].
<schema xmlns:ipdr="http://www.ipdr.org/namespaces/ipdr">
<annotation>
<documentation>
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.
</documentation>
</annotation>
<element name="sourceAddress" type="ipdr:ipV4Addr">
<annotation>
<documentation>
IPv4 source address taken from the packet header.
</documentation>
</annotation>
</element>
<element name="sourceAddressV6" type="ipdr:ipV6Addr">
<annotation>
<documentation>
IPv6 source address taken from the packet header.
</documentation>
</annotation>
</element>
<element name="destinationAddress" type="ipdr:ipV4Addr">
<annotation>
<documentation>
Meyer Expires March 3, 2003 [Page 20]
Internet-Draft Streaming IPDR Eval September 2002
IPv4 destination address taken from the packet header.
</documentation>
</annotation>
</element>
<element name="destinationAddressV6" type="ipdr:ipV6Addr">
<annotation>
<documentation>
IPv6 destination address taken from the packet header.
</documentation>
</annotation>
</element>
<element name="protocolIdentifier" type="int">
<annotation>
<documentation>
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.
</documentation>
<appinfo>
<ipdr:reference>http://www.iana.org/assignments/protocol-numbers</ipdr:reference>
</appinfo>
</annotation>
</element>
<element name="sourcePort" type="int">
<annotation>
<documentation>
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.
</documentation>
</annotation>
</element>
<element name="destinationPort" type="int">
<annotation>
<documentation>
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.
</documentation>
</annotation>
</element>
<element name="ingressPort" type="int">
<annotation>
<documentation>
The ifIndex where the packets for the flow are being received.
ifIndex is defined by RFC 2233.
</documentation>
</annotation>
</element>
<element name="egressPort" type="int">
<annotation>
<documentation>
The ifIndex where the packets for the flow are exiting. ifIndex is
defined by RFC 2233.
</documentation>
</annotation>
</element>
<element name="packetCount" type="int">
<annotation>
<documentation>
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.
</documentation>
<appinfo>
<ipdr:units>packets</ipdr:units>
</appinfo>
</annotation>
</element>
<element name="byteCount" type="int">
<annotation>
<documentation>
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.
</documentation>
<appinfo>
<ipdr:units>bytes</ipdr:units>
</appinfo>
</annotation>
</element>
<element name="classOfService" type="int">
<annotation>
<documentation>
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]
</documentation>
</annotation>
</element>
<element name="flowLabel" type="int">
<annotation>
<documentation>
The Flow Label information element contains the IPV6 Flow Label
information as defined by RFC 2460.
</documentation>
</annotation>
</element>
<element name="flowCreationTime" type="dateTime">
<annotation>
<documentation>
The timestamp of the first packet of the flow.
</documentation>
Meyer Expires March 3, 2003 [Page 23]
Internet-Draft Streaming IPDR Eval September 2002
</annotation>
</element>
<element name="flowEndTime" type="dateTime">
<annotation>
<documentation>
The timestamp of the last packet of the flow..
</documentation>
</annotation>
</element>
<element name="sourceAS" type="int">
<annotation>
<documentation>
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):
</documentation>
</annotation>
</element>
<element name="destinationAS" type="int">
<annotation>
<documentation>
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).
</documentation>
</annotation>
</element>
<element name="nextHopAS" type="int">
<annotation>
<documentation>
The Autonomous System (AS) numbers for the next hop IP. Autonomous
System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).
</documentation>
</annotation>
</element>
<element name="tcpControlBits" type="int">
<annotation>
<documentation>
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
</documentation>
</annotation>
</element>
<element name="sourceExporterAddress" type="ipdr:ipV4Addr">
<annotation>
<documentation>
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.
</documentation>
</annotation>
</element>
<element name="droppedPacketCount" type="int">
<annotation>
<documentation>
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.
</documentation>
<appinfo>
<ipdr:units>packets</ipdr:units>
</appinfo>
</annotation>
</element>
<element name="samplingInterval" type="int">
<annotation>
<documentation>
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.
</documentation>
</annotation>
</element>
<element name="samplingAlgorithm" type="int">
<annotation>
<documentation>
The type of algorithm used for sampling data. Currently, the only
sampling algorithm defined is:
0x02 packet-sampling
</documentation>
</annotation>
</element>
<element name="flowEndState" type="int">
<annotation>
<documentation>
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]
</documentation>
</annotation>
</element>
<element name="droppedByteCount" type="int">
<annotation>
<documentation>
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.
</documentation>
<appinfo>
<ipdr:units>bytes</ipdr:units>
</appinfo>
Meyer Expires March 3, 2003 [Page 26]
Internet-Draft Streaming IPDR Eval September 2002
</annotation>
</element>
<complexType name="SimpleV4Flow">
<extension base="ipdr:IPDR">
<sequence>
<element ref="sourceAddress" minOccurs="1"/>
<element ref="destinationAddress" minOccurs="1"/>
<element ref="protocolIdentifier" minOccurs="1"/>
<element ref="sourcePort" minOccurs="1"/>
<element ref="destinationPort" minOccurs="1"/>
<element ref="ingressPort" minOccurs="1"/>
<element ref="egressPort" minOccurs="1"/>
<element ref="packetCount" minOccurs="1"/>
<element ref="byteCount" minOccurs="1"/>
<element ref="classOfService" minOccurs="0"/>
<element ref="flowLabel" minOccurs="0"/>
<element ref="flowCreationTime" minOccurs="1"/>
<element ref="flowEndTime" minOccurs="1"/>
<element ref="tcpControlBits" minOccurs="0"/>
<element ref="samplingInterval" minOccurs="0"/>
<element ref="samplingAlgorithm" minOccurs="0"/>
<element ref="sourceExporterAddress" minOccurs="1"/>
</sequence>
</extension>
</complexType>
<complexType name="SimpleV6Flow">
<extension base="ipdr:IPDR">
<sequence>
<element ref="sourceAddressV6" minOccurs="1"/>
<element ref="destinationAddressV6" minOccurs="1"/>
<element ref="protocolIdentifier" minOccurs="1"/>
<element ref="sourcePort" minOccurs="1"/>
<element ref="destinationPort" minOccurs="1"/>
<element ref="ingressPort" minOccurs="1"/>
<element ref="egressPort" minOccurs="1"/>
<element ref="packetCount" minOccurs="1"/>
<element ref="byteCount" minOccurs="1"/>
<element ref="classOfService" minOccurs="0"/>
<element ref="flowLabel" minOccurs="0"/>
<element ref="flowCreationTime" minOccurs="1"/>
<element ref="flowEndTime" minOccurs="1"/>
<element ref="tcpControlBits" minOccurs="0"/>
<element ref="samplingInterval" minOccurs="0"/>
<element ref="samplingAlgorithm" minOccurs="0"/>
<element ref="sourceExporterAddress" minOccurs="1"/>
Meyer Expires March 3, 2003 [Page 27]
Internet-Draft Streaming IPDR Eval September 2002
</sequence>
</extension>
</complexType>
</schema>
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]