| TOC |
|
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 (C) The Internet Society (2002). All Rights Reserved.
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.
| TOC |
| TOC |
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].
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.
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.
The Streaming IPDR protocol may be submitted as an IETF Proposed Standard, based on evaluation by the IPFIX working group.
There are no known patents which apply to or affect the right to freely use this technology.
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.
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.
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.
| TOC |
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.
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.
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].
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.
The basic elements of the Streaming IPDR protocol are the following:
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 |
+----------------+
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.
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.
When limited to the communication between an exporting process and a collection process, the IPDR Reference model matches that of IPFIX.
| TOC |
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.
The subsections describe how Streaming IPDR satisfies each of the mandatory requirements of the specified for the IPFIX protocol.
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 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.
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.
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.
Streaming IPDR uses TCP which is provides reliable ordered delivery of information. Streaming also allows for application level sequence 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.
The underlying security options proposed by Streaming IPDR in section 4 address the attacks and other concerns described in the security section.
The protocol allows an exporting process to address this requirement.
This requirement is specified as a MAY and is not addressed by Streaming IPDR.
The protocol allows an exporting process to address this requirement.
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]
ack time interval hint
schema, namespace and type information of flow records
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.
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..
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..
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.
-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 | | |
|-------+-------------------------+-----+------|
| 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 |
|-------+-------------------------+-----+------|
| 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
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.
| TOC |
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.
| TOC |
| TOC |
| 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 |
| TOC |
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>
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
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
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>
</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.
</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>
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>
</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"/>
</sequence>
</extension>
</complexType>
</schema>
| TOC |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.