Network Working Group J. Meyer Internet-Draft Hewlett-Packard Expires: March 3, 2003 September 2, 2002 Evaluation Of Streaming IPDR Against IPFIX Requirements draft-meyer-ipfix-ipdr-eval-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 3, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the Streaming IPDR protocol as an IPFIX protocol. It compares the properties and capabilities of Streaming IPDR to the IPFIX requirements. Streaming IPDR is a mechanism to deliver streams of network usage information which follow the Internet Protocol Detail Records (IPDR) format over a reliable transport connection. Meyer Expires March 3, 2003 [Page 1] Internet-Draft Streaming IPDR Eval September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Level of Standarization . . . . . . . . . . . . . . . . . . 3 1.3 Patent Protection . . . . . . . . . . . . . . . . . . . . . 4 1.4 Availability . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Commercial Use . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Future Protocol Development Areas . . . . . . . . . . . . . 4 2. Architectural Considerations . . . . . . . . . . . . . . . . 5 2.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 2.2 General Applicability . . . . . . . . . . . . . . . . . . . 6 2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Trivial Streaming IPDR . . . . . . . . . . . . . . . . . . . 8 2.3 Architectural Differences . . . . . . . . . . . . . . . . . 8 3. Item Level Compliance Evaluation . . . . . . . . . . . . . . 9 3.1 Items by Section . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Data Export (6) . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Configuration (7) . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 General Requirements (8) . . . . . . . . . . . . . . . . . . 12 3.2 Compliance Table . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 A. IPFIX IPDR Service Definition . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 Meyer Expires March 3, 2003 [Page 2] Internet-Draft Streaming IPDR Eval September 2002 1. Introduction This document provides an evaluation of the applicability of the Streaming IPDR [2] protocol as an IPFIX protocol. First, the general IPDR architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in the IPFIX Requirements [1] are met. This document uses the terminology defined in IPFIX Requirements [1]. 1.1 Documentation The specific protocol mechanism, Streaming IPDR [2], is a work in progress submitted as an IETF draft. The protocol itself builds upon some of the procedures defined in the IPDR Network Data Management-Usage (NDM-U) 3.1 [6] specification. Sections 1, 2 and 3 of the NDM-U 3.1 specification provide an Introduction, the IPDR Reference model and the business requirements addressed. The relevant protocol sections in NDM-U 3.1 are: The NDM-U Protocol in section 4. More specifically subsections 4.1 and 4.3. The Schema guidelines in section A.4 In addition Appendix A in this document defines an IPDR service definition which addresses the required set of IPFIX data attributes. 1.2 Level of Standarization IPDR.org is an non-profit industry consortium. Member companies collaborate to agree upon IPDR specifications. These specifications are versioned and published on the IPDR.org website. The current specification as of this writing is NDM-U 3.1. [6] Particpating companies also participate in interoperability and compliance activities to shake out issues in the specification. In addition to relying on the NDM-U 3.1 specification, this proposal introduces two additional documents, the IPFIX service definition, in Appendix A and the Streaming IPDR [2] extension and protocol binding. Meyer Expires March 3, 2003 [Page 3] Internet-Draft Streaming IPDR Eval September 2002 The Streaming IPDR protocol may be submitted as an IETF Proposed Standard, based on evaluation by the IPFIX working group. 1.3 Patent Protection There are no known patents which apply to or affect the right to freely use this technology. 1.4 Availability The base IPDR NDM-U 3.1 specification is implemented by a number of billing and mediation software companies. The specific procedures introduced in Streaming IPDR are not currently available with commercial products. A complete implementation written in Java has been developed, but is under test. A C implementation can built upon existing work done in IPDR's reference library. 1.5 Commercial Use Several service providers have deployed IPDR based service accounting in their networks. Based upon the recent availability of a compact as well as XML based format, and IPDR's XML-Schema based extension model, it is expected that IPDR will be more widely deployed in the future. 1.6 Future Protocol Development Areas The current NDM-U 3.1 Sevice Definition Guidelines and the Compact data model limit the protocol to carrying data which is in "First Normal Form" (FNF). Current IPFIX flow records are also FNF. They are all defined as non-repeating fields, and the fields are simple primitive types, not structures. It is desireable to remove the first normal form restriction, but still encourage keeping record structures as flat as possible. This will allow mapping the XML Schema model to existing protocols and CDRs such as Diameter or 3GPP GGSN records, without removing information. Proposed additions to the XDR based compact format and the Schema writing guidelines will be made shortly to address repeating fields and records to be defined in addition to FNF. Meyer Expires March 3, 2003 [Page 4] Internet-Draft Streaming IPDR Eval September 2002 2. Architectural Considerations This section introduces the architecture of the Streaming IPDR protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. IPDR is a general purpose protocol meant to address the exchange of usage information between cooperating systems. 2.1 Protocol Overview The compact IPDR specification defines a document format which offers a compact and efficient represenation of usage accounting data. This structure is defined in section 4.3 of the IPDR NDM-U 3.1 [6]specfication. The encoding format is based on the ONC-RPC eXtensible Data Representation (XDR). The encoding supports a basic set of primitive data types and a number of additional types which are derived from the primitive types The mechanisms for encoding and transport are completely separate in IPDR. The CompactIPDR format can be used to serialize usage information to a file or it can be used to serialize usage information onto a reliable transport, such as TCP. For real time push oriented communication the streaming over a reliable transport is preferred, as described in Streaming IPDR [2]. A file can also be used as the unit of exchange. File based exchange has been the focus of much of the Interoperability work done by various member companies of IPDR.org to date. The file transfer related exchange described in Section 4.4 is not part of this proposal. Although it does provide a pull based model for exchange of information between collection processes. IPDR's XML-Schema based format has the additional benefit of providing a well defined equivalent XML encoding. Both the compact and XML formats are based on a common service definition specification. The service specification is expressed as one or more XML Schema documents, which follow the guidelines set forth in section A.4 of the IPDR NDM-U 3.1 specification. Service specifications are the primary means of extension in IPDR. A service definition addressing the required and optional parameters described in IPFIX Requirements is provided as an Appendix to this document. Meyer Expires March 3, 2003 [Page 5] Internet-Draft Streaming IPDR Eval September 2002 As an example of the general usefulness of XML as a base language for specifications, consider this document. Although you may be reading it as an HTML document or a formatted nroff text document, it started off as a set of markup following RFC2629 [13]. +----------------------+ | Service Definition(s)| | (in XML Schema) | +----------------------+ | | v v +---------------------+ +-----------------------+ | Usage information | | Usage information | | (an XML Document) | | (a compact document)| +---------------------+ +-----------------------+ The XML encoding is not used by Streaming IPDR protocol. However it is worth noting that all flow records sent using Streaming IPDR have a lossless and unambiguous mapping to content in an XML document. The details of the XML encoding are contained in Section 4.2 of NDM-U 3.1 [6]. 2.2 General Applicability This specification only addresses the exchange of information between an exporting process and a collecting process. How metering points and observation points interact with the exporting process is specifically not addressed. Specifically the model specified in section 2.4 of NDM-U 3.1 [6] assumes that the Service Element contains the metering points. The raw information acquired by the meterint points is turned into IPDR based strcutures by some Recording Element. The recorded flows are transmitted over a TCP connection to one or more collecting processes. Different record types are identified in the stream by different descriptors. These types should also be defined in one of the XML Schemas describing the exported information. 2.2.1 Illustration The basic elements of the Streaming IPDR protocol are the following: Meyer Expires March 3, 2003 [Page 6] Internet-Draft Streaming IPDR Eval September 2002 Header - this describes the XML schemas and namespace declarations to be used for this session (or document). This makes each stream (or file) a self describing document. Descriptor - sometimes refered to as templates, this element describes the fields which may appear in a flow record. Order is implied. This allows flow records to be well packed (especially with numeric types). Ack - a message indicating the sequence number and relative time information at each system. Provides "application level" flow control capabilities. Usage Event - a flow record whose structure was previously defined by a descriptor. Disconnect - provides graceful shutdown of communication channel with known disposition of flow records. Time t0: <-- TCP Conn Established --> +----------------+ | Header | +----------------+ -- transmitted --> | Descriptor | +----------------+ | Ack | +----------------+ +----------------+ | Header | <-- transmitted +----------------+ | Ack | +----------------+ Time t1 (one or more usage event(s) recorded): +----------------+ | Usage Event | -- transmitted --> +----------------+ ... +----------------+ | Usage Event | Meyer Expires March 3, 2003 [Page 7] Internet-Draft Streaming IPDR Eval September 2002 +----------------+ Time t2 (either time or volume hint triggers Ack): +----------------+ <-- transmitted | Ack | +----------------+ Time t3 (idle period has exceeded hint): +----------------+ | Ack | -- transmitted --> +----------------+ Basic scenario continues until some terminating control message arrives and finally at time tn: +----------------+ | Disconnect | -- transmitted --> +----------------+ +----------------+ <-- transmitted | Disconnect | +----------------+ <-- TCP Connection Release --> Note that additional descriptor stream elements MAY be transmitted in the stream along with Usage Events at any time. 2.2.2 Trivial Streaming IPDR The illustration presented above is the IPDR Streaming protocol in its reliable mode. There is also a "Trivial Streaming Protocol" which does not involve any communication from the collecting system. The author has seen several middlebox and application protocols following this pattern. So it is worthwile to note this option exists as well. 2.3 Architectural Differences When limited to the communication between an exporting process and a collection process, the IPDR Reference model matches that of IPFIX. Meyer Expires March 3, 2003 [Page 8] Internet-Draft Streaming IPDR Eval September 2002 3. Item Level Compliance Evaluation This section evaluates the compliance of the Streaming IPDR with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in IPFIX Requirements [1]. For each requirement, it is explained to what degree Streaming IPDR meets the requirement and how this is achieved. At the end of the written discussion a table summarizes the compliance by asssigning one of five grades to each item. Please note that the requirements specified in sections 4, 5 and 7.1 of IPFIX Requirements [1] do not directly concern the IPFIX protocol, but the semantics of the data transferred. They can be met easily by extensible protocols that do not restrict sematics of transferred data. This includes the Streaming IPDR format, as the data model allows for arbitrary extension, following a well established standard, XML Schema [4]. Therefor only sections 6, 7.2 and 8 will be directly covered. 3.1 Items by Section The subsections describe how Streaming IPDR satisfies each of the mandatory requirements of the specified for the IPFIX protocol. 3.1.1 Data Export (6) 3.1.1.1 Information Model (6.1) The proposed information model is based on the data model draft [12] which is currently available. Items 2,3,4,5,6,7,8,9,10,11,12,16,17,18 are addressed directly by the existing IPFIX data model draft. They are present as element defintions in Appendix A. The combination of these elements to form an IPDR complexType is also shown. Mandatory and optional parameters are captured as well. The remaining items are addressed as follows: Item 1: the distinction between IPv4 and IPv6 is determined by the record type. Records either contain all IPv4 based addresses or all IPv6 style addresses. Item 13: the current data model defines three attributes related to Autonomous System identifiers. These are captured in the schema definition. The meaning of "if BGP is supported at the Meyer Expires March 3, 2003 [Page 9] Internet-Draft Streaming IPDR Eval September 2002 observation point: BGP AS Number" is unclear. Item 19: the current data model does specifies an address of an observationPoint. It is assumed this matches the intent of this item. Item 20: the initial IPDR header exchange provides recorderInfo, which should match this requirement. Items 14,15,21,22,26: the current data model does not appear to define these items. This protocol advocacy draft assumes that the abstract data model be defined to match the requirements. 3.1.1.2 Data Model (6.2) IPDR's Data Model is based on a subset of XML Schema. [4] This subset provides a restricted set of types to define basic elements (Flow Record Fields) and complex type definitions (Flow Record structures). The front matter to the XML Schema webpage states "XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents." IPDR carries this definition further, recognizing that the XML-Schema language can be used to define the structure, content and semantics of other encoding schemes. In particular the mapping to XDR provides one concrete use case. Future definitions may map to additional protocols. Appendix A provides an example of the modelling capability of NDM-U 3.1. See the section describing "Futures" in this document for additional planned capabilities. 3.1.1.3 Data Transfer (6.3) 3.1.1.3.1 Congestion Awareness (6.3.1) Streaming IPDR uses TCP which is congestion aware. Streaming IPDR also enables congestion information at the application level via the optional use of sequence numbers. 3.1.1.3.2 Reliability (6.3.2) Streaming IPDR uses TCP which is provides reliable ordered delivery of information. Streaming also allows for application level sequence Meyer Expires March 3, 2003 [Page 10] Internet-Draft Streaming IPDR Eval September 2002 numbers. In the event of connection loss, the acknowledgement scheme will bound the amount of information which needs to be retransmitted, in order to guarantee delivery of all flow records. 3.1.1.3.3 Security (6.3.3) The underlying security options proposed by Streaming IPDR in section 4 address the attacks and other concerns described in the security section. 3.1.1.4 Regular Reporting Interval (6.4) The protocol allows an exporting process to address this requirement. 3.1.1.5 Notification on Specific Events (6.5) This requirement is specified as a MAY and is not addressed by Streaming IPDR. 3.1.1.6 Anonymization (6.6) The protocol allows an exporting process to address this requirement. 3.1.2 Configuration (7) 3.1.2.1 Configuration of Exporting Process (7.2) The Streaming IPDR protocol only addresses the acknowledged one way flow of information from the exporting process to the collecting process. The configuration mechanims of the exporting process is not addressed by this proposal. Configuration models based on SNMP MIBs or command line interfaces can be used. Additional configuration items introduced by the Streaming IPDR Protocol, which should be exposed by the exporting process, include: IP Address(es) of the collecting systems. Port(s) of the collecting systems. Flow buffering properties for reliable delivery: maximum buffer size (in # flows) [or no buffering] ack interval hint [or trivial] Meyer Expires March 3, 2003 [Page 11] Internet-Draft Streaming IPDR Eval September 2002 ack time interval hint schema, namespace and type information of flow records 3.1.3 General Requirements (8) 3.1.3.1 Openness (8.1) The NDM-U 3.1 specification [6] is publicly available. It takes the approach of leveraging existing standards where applicable. These include the TMF Telecom Operations Map for the reference model, and XML [3], XML Namespace, XML Schema [4] and XDR [7] as basis for notation, syntax and encoding. 3.1.3.2 Scalability Conerning the number of Exporting Processes (8.2) A collecting application can interface with many exporting processes. The only limitations are the network, disk and processing throughput of the system relative to the flow event rate being presented.. 3.1.3.3 Several Collecting Processes (8.3) Using several, possibly locally deployed, collecting applications to collect from flow exporting systems is a good way to scale collection. Any given collection system is limited by its network, disk and processing throughput relative to the flow event rate being presented.. 3.2 Compliance Table The following table summarizes the degree of compliancy using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is only applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protcols, where the protocol specification itself needs to be extended in order to comply with the requirement. -P Partial compliance: The requirement is met partially by the protocol specification. Meyer Expires March 3, 2003 [Page 12] Internet-Draft Streaming IPDR Eval September 2002 -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. ----------------------------------------------. B: IPFIX Requirement Status | ----------------------------------------. | A: IPDR Streaming Compliance | | ----------------------------------. | | | | | | Sect. | Requirement | | | |-------+-------------------------+-----+------| | 6. | DATA EXPORT | |-------+-------------------------+-----+------| | 6.1. | INFORMATION MODEL | |-------+-------------------------+-----+------| | 6.1. | IP Version | E | M | |-------+-------------------------+-----+------| | 6.1. | src/dst address | E | M | |-------+-------------------------+-----+------| | 6.1. | transport protocol | E | M | |-------+-------------------------+-----+------| | 6.1. | src/dst port | E | M | |-------+-------------------------+-----+------| | 6.1. | Packet counter (h) | E | M | |-------+-------------------------+-----+------| | 6.1. | Byte counter | E | M | |-------+-------------------------+-----+------| | 6.1. | Dropped Packet | E | M | | | Counter (h,i) | | | |-------+-------------------------+-----+------| | 6.1. | ToS Byte | E | M | |-------+-------------------------+-----+------| | 6.1. | Flow Label | E | M | |-------+-------------------------+-----+------| | 6.1. | BGP AS# | E | M | |-------+-------------------------+-----+------| | 6.1. | MPLS label (a) | E | M | | | | | | |-------+-------------------------+-----+------| | 6.1. | DSCP (a) | E | M | |-------+-------------------------+-----+------| | 6.1. | Timestamps for | E | M | | | first/last packet | | | Meyer Expires March 3, 2003 [Page 13] Internet-Draft Streaming IPDR Eval September 2002 |-------+-------------------------+-----+------| | 6.1. | Sampling configuration | E | M | |-------+-------------------------+-----+------| | 6.1. | observation point | E | M | | | identifier | | | |-------+-------------------------+-----+------| | 6.1. | export process | T | M | | | identifier | | | |-------+-------------------------+-----+------| | 6.1. | TTL | E | O | |-------+-------------------------+-----+------| | 6.1. | IP header flags | E | O | |-------+-------------------------+-----+------| | 6.1. | TCP header flags | E | O | |-------+-------------------------+-----+------| | 6.1. | Fragment counter | E | O | |-------+-------------------------+-----+------| | 6.1. | Multicast | E | S | | | replication factor | | | |-------+-------------------------+-----+------| | 6.2. | DATA MODEL | |-------+-------------------------+-----+------| | 6.2. | Flexibility | T | O | |-------+-------------------------+-----+------| | 6.2. | Extensibility | T | M | |-------+-------------------------+-----+------| | 6.3. | DATA TRANSFER | |-------+-------------------------+-----+------| | 6.3.1.| Congestion aware | T | M | |-------+-------------------------+-----+------| | 6.3.2.| Reliability | T | M | |-------+-------------------------+-----+------| | 6.3.3.| Confidentiality | T | S | |-------+-------------------------+-----+------| | 6.3.4.| Integrity | T | M | |-------+-------------------------+-----+------| | 6.3.5.| Authenticity | T | M | |-------+-------------------------+-----+------| | 6.4. | REPORTING TIMES | |-------+-------------------------+-----+------| | 6.4. | Push mode | T | M | |-------+-------------------------+-----+------| | 6.4. | Pull mode | T | O | | | | (a) | | |-------+-------------------------+-----+------| | 6.4.1.| Regular Interval | T | S | |-------+-------------------------+-----+------| | 6.6. | Notifications | P | O | Meyer Expires March 3, 2003 [Page 14] Internet-Draft Streaming IPDR Eval September 2002 |-------+-------------------------+-----+------| | 6.7. | Anonymization | T | O | |-------+-------------------------+-----+------| | 7. | CONFIGURATION | |-------+-------------------------+-----+------| | 7. | Config Measurement | T | M | | | & Data Export |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Observation Point| T | S | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Flow | T | S | | | Specifications |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Flow Timeouts | T | S | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Sampling | T | O | | | |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Report | T | S | | | Data Format |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config | T | O | | | Notifications |(n/a)| | |-------+-------------------------+-----+------| | 7. | Config Anonymization | T | O | | | |(n/a)| | |-------+-------------------------+-----+------| | 8. | GENERAL REQUIREMENTS | |-------+-------------------------+-----+------| | 8.1. | Openness | T | S | |-------+-------------------------+-----+------| | 8.2. | Scalability: | | | | | data collection | T | M | | | from hundreds of | | | | | measurement devices | | | |-------+-------------------------+-----+------| | 8.3. | Several Collectors | T | O | |-------+-------------------------+-----+------| (a) - The IPDR NDM-U 3.1 specification defines a pull based protocol which relies on file transfer. This protocol is not directly advocated in this draft, since the primary consideration is push based delivery. (n/a) - IPDR defines the transfer protocol between the exporting Meyer Expires March 3, 2003 [Page 15] Internet-Draft Streaming IPDR Eval September 2002 and collection process. The behavior of the exporting process is controlled through means such as MIB or command line control, not specified by Streaming IPDR. Meyer Expires March 3, 2003 [Page 16] Internet-Draft Streaming IPDR Eval September 2002 4. Security Considerations Security can be accomplished by using either IPSec [9] or TLS [10] mechanisms when establishing the underlying TCP connection. This is the same security policy used by Diameter [11], sec (13.1 and 13.2) Because the use of IPSec and TLS are transparent to the from the perspective of TCP connection endpoints, the protocol specified here is unchanged. Meyer Expires March 3, 2003 [Page 17] Internet-Draft Streaming IPDR Eval September 2002 References [1] Quittek, J., "Requirements for IP Flow Information Export", IETF draft work in progress, August 2002, . [2] Meyer, J., "Reliable Streaming Internet Protocol Detail Records", IETF draft work in progress, August 2002, . [3] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML, May 2001, . [5] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML, May 2001, . [6] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1", April 2002, . [7] Srinivasan, R., "XDR: External Data Representation Standard", RFC 2026, August 1995, . [8] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, Sept. 2000, . [9] Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, Nov. 1998, . [10] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, Jan. 1999, . [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", draft Work in progress, Jul. 2002, . [12] Norseth, K. and P. Calato, "Data Model for IP Flow Information Export", IETF draft work in progress, August 2002, . Meyer Expires March 3, 2003 [Page 18] Internet-Draft Streaming IPDR Eval September 2002 [13] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . Author's Address Jeff Meyer Hewlett-Packard 19420 Homestead Rd. Cupertino, CA 95014 US Phone: +1 408 447-3477 EMail: jeff_meyer@hp.com URI: http://www.hp.com Meyer Expires March 3, 2003 [Page 19] Internet-Draft Streaming IPDR Eval September 2002 Appendix A. IPFIX IPDR Service Definition This proposal does not take into consideration possible IANA implications. The use of Namespaces as an extension mechanism implies that an IANA registered Namespace URI should be available and that directory names below this base URI be assigned for relevant IETF specifications. The author is not aware of this mechanism today. Alternatively IPDR.org could fulfill this role. The sample uses the IPDR.org namespace. The naming and content is lifted from the IPFIX Data Definition draft [12]. This document defines a subset of the identified IPFIX data model as XML Schema elements and complexTypes. This schema definition is compatable with the IPDR Service Definition format, enabling flow information to be represented as XML or binary documents. And defines the format used when streaming flow information to a recording system. IPv4 source address taken from the packet header. IPv6 source address taken from the packet header. Meyer Expires March 3, 2003 [Page 20] Internet-Draft Streaming IPDR Eval September 2002 IPv4 destination address taken from the packet header. IPv6 destination address taken from the packet header. Protocol number identified in the IP packet. In the Internet Protocol version 4 (IPv4) [RFC791] there is a field, called "Protocol", to identify the next level protocol. This is an 8 bit field. In Internet Protocol version 6 (IPv6) [RFC1883] this field is called the "Next Header" field. These numbers are administered by IANA. http://www.iana.org/assignments/protocol-numbers This information element is used to report UDP source port [see RFC 768] or TCP source port [see RFC 793] as taken from the IP header. This information element is used to report UDP destination port [see RFC 768] or TCP destination port [see RFC 793] as taken from Meyer Expires March 3, 2003 [Page 21] Internet-Draft Streaming IPDR Eval September 2002 the IP header. The ifIndex where the packets for the flow are being received. ifIndex is defined by RFC 2233. The ifIndex where the packets for the flow are exiting. ifIndex is defined by RFC 2233. Contains the count of packets sent and received associated with the identified flow. The packet count can be for packets received (towards source) or packets sent (towards destination) or both (bi-directional flow). The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. packets Contains the count of octets sent and received associated with the Meyer Expires March 3, 2003 [Page 22] Internet-Draft Streaming IPDR Eval September 2002 identified flow. The byte count can be for bytes received (towards source) or bytes sent (towards destination) or both (bi-directional flow). The byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. bytes The class of service associated with a flow. Class of Service Received Class of Service Transmitted 1. IPv4, CoS value is defined by ToS in RFC 791 2. IPv6, CoS value is defined by Traffic Class in RFC 2460 3. MPLS, CoS value is defined by Exp in RFC 3032 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p] The Flow Label information element contains the IPV6 Flow Label information as defined by RFC 2460. The timestamp of the first packet of the flow. Meyer Expires March 3, 2003 [Page 23] Internet-Draft Streaming IPDR Eval September 2002 The timestamp of the last packet of the flow.. The Autonomous System (AS) numbers for the source address associated with a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4): The Autonomous System (AS) numbers for the destination address associated wit a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). The Autonomous System (AS) numbers for the next hop IP. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). The TCP control bits seen for this flow. Note a 0 value for each bit only indicates that the flag was not detected (i.e. it may have occurred but was not detected by the reporting CCE). TCP Control Bits are defined by RFC 793. Meyer Expires March 3, 2003 [Page 24] Internet-Draft Streaming IPDR Eval September 2002 Source Exporter address is the address of the Exporter reporting the flow, Address is same as is as shown for Source Address. This information is used by applications to later correlate the ingress/egress port with a specific Exporter. It is also used to maintain the source Exporter information when there is an intermediate proxy. For example, given the picture below: SW1 -------- P1 ------ Collector ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the Collector [ is this the right term??? PAC] like the same Exporter connection. With the Source Exporter in the message the original Exporter address is maintained. Contains the count of packets dropped at the observation point associated with the identified flow. The dropped packet count can be a running counter and is the count from the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since the last report for this flow. packets Meyer Expires March 3, 2003 [Page 25] Internet-Draft Streaming IPDR Eval September 2002 When using Sampling, the rate at which packets is sampled. For example, a value of 100 indicates that one of every hundred packets is sampled. The type of algorithm used for sampling data. Currently, the only sampling algorithm defined is: 0x02 packet-sampling The reason the flow has ended. 1. Inactivity timeout 2. End of flow detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full [enumerations in IPDR service def schemas are recommended to be of form string, w/ integer values (for Compact format) defined via annotation] Contains the count of octets dropped at the observation point associated with the identified flow. The dropped byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. bytes Meyer Expires March 3, 2003 [Page 26] Internet-Draft Streaming IPDR Eval September 2002 Meyer Expires March 3, 2003 [Page 27] Internet-Draft Streaming IPDR Eval September 2002 Meyer Expires March 3, 2003 [Page 28] Internet-Draft Streaming IPDR Eval September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires March 3, 2003 [Page 29]