Re: [ipfix] update of IPFIX-AS -> IPFIX-PROTO compliant to RFC3330. Done.
Benoit Claise <bclaise@cisco.com> Mon, 29 May 2006 14:38 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkit9-0004Gw-55 for ipfix-archive@lists.ietf.org; Mon, 29 May 2006 10:38:35 -0400
Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkit4-0003o5-HR for ipfix-archive@lists.ietf.org; Mon, 29 May 2006 10:38:35 -0400
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FkijK-0004A7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 May 2006 09:28:26 -0500
Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FkijH-0004A1-00 for ipfix@net.doit.wisc.edu; Mon, 29 May 2006 09:28:23 -0500
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k4TESM520741; Mon, 29 May 2006 16:28:22 +0200 (CEST)
Received: from [10.82.240.95] (rtp-vpn2-95.cisco.com [10.82.240.95]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k4TESDC02922; Mon, 29 May 2006 16:28:13 +0200 (CEST)
Message-ID: <447B04FC.1020908@cisco.com>
Date: Mon, 29 May 2006 16:28:12 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Tanja Zseby <Tanja.Zseby@fokus.fraunhofer.de>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] update of IPFIX-AS -> IPFIX-PROTO compliant to RFC3330. Done.
References: <804B13F8F3D94A4AB18B9B01ACB68FA1137A02@EXCHSRV.fokus.fraunhofer.de>
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA1137A02@EXCHSRV.fokus.fraunhofer.de>
Content-Type: multipart/alternative; boundary="------------010708070903070805030801"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 96eb4ba28fbb58504ad11d848dd78c6d
Hi Tanja, > > Benoit, I guess the example address in the protocol draft also need to > be changed for conformance with RFC3330. > Thanks. Done. The IP addresses in the example section now contains 192.0.2.0/24, as explained in RFC 3330 Regards, Benoit. > Regards, > Tanja > > ------------------------------------------------------------------------ > > > > > > > Internet Draft Tanja Zseby > Document: <draft-ietf-ipfix-as-07.txt> Fraunhofer FOKUS > Expires: October 2006 Elisa Boschi > Hitachi > Nevil Brownlee > CAIDA > Benoit Claise > Cisco Systems > > May 2006 > > > IPFIX Applicability > draft-ietf-ipfix-as-07.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that > any applicable patent or other IPR claims of which he or she is > aware have been or will be disclosed, and any of which he or she > becomes aware will be disclosed, in accordance with Section 6 of > BCP 79. > > 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. > > Copyright Notice > > Copyright (C) The Internet Society (2006). > > > > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 1] > IPFIX Applicability May 2006 > > > > > Abstract > > This document describes the applicability of the IP Flow > Information Export (IPFIX) protocol for a variety of > applications. It shows how applications can use IPFIX, describes > the relevant information elements (IEs) and shows opportunities > and limitations of the protocol. The document furthermore > describes relations of the IPFIX framework to other > architectures and frameworks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 2] > IPFIX Applicability May 2006 > > > > Table of Contents > 1. Introduction.............................................4 > 2. Applications of IPFIX....................................4 > 2.1 Accounting...............................................4 > 2.1.1 Example.................................................5 > 2.2 Traffic Profiling........................................7 > 2.3 Traffic Engineering......................................7 > 2.4 Network Security.........................................8 > 2.5 QoS Monitoring..........................................10 > 2.5.1 Correlating Events from Multiple Observation Points....11 > 2.5.2 Examples...............................................11 > 2.6 Inter-Domain Exchange of IPFIX data.....................13 > 2.7 Export of Derived Metrics...............................13 > 2.8 Summary.................................................14 > 3. Relation of IPFIX to Other Frameworks and Protocols.....14 > 3.1 IPFIX and PSAMP.........................................14 > 3.2 IPFIX and RMON..........................................15 > 3.3 IPFIX and IPPM..........................................15 > 3.4 IPFIX and AAA...........................................16 > 3.4.1 Connecting via an AAA Client...........................17 > 3.4.2 Connecting via an Application Specific Module (ASM)....17 > 3.5 IPFIX and RTFM..........................................18 > 3.5.1 Architecture...........................................18 > 3.5.2 Flow Definition........................................19 > 3.5.3 Configuration and Management...........................19 > 3.5.4 Data Collection........................................19 > 3.5.5 Data Model Details.....................................20 > 3.5.6 Transport Protocol.....................................20 > 3.5.7 Summary................................................20 > 4. Limitations.............................................21 > 4.1 Using IPFIX for other Applications than in RFC3917......21 > 4.2 Using a Different Transport Protocol than SCTP..........21 > 4.3 Push vs. Pull Mode......................................21 > 4.4 Template ID number......................................22 > 4.5 Exporting Bidirectional Flow Information................22 > 4.6 IPFIX and IPv6..........................................23 > 5. Security Considerations.................................23 > 6. Normative References....................................24 > 7. Informative References..................................24 > 8. Acknowledgements........................................26 > 9. Authors' Addresses......................................26 > 10. Full Copyright Statement................................27 > 11. Intellectual Property Statement.........................27 > 12. Copyright Statement.....................................28 > 13. Disclaimer..............................................28 > > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 3] > IPFIX Applicability May 2006 > > > > 1. Introduction > > The IPFIX protocol defines how IP Flow information can be > exported from routers, measurement probes or other devices. It > is intended to provide this information as input to various > applications. IPFIX is a general data transport protocol, easily > extensible to suit the needs of different applications. This > document describes how typical applications that can use the > IPFIX protocol. It shows opportunities and limitations of the > protocol. Furthermore, the relationship of IPFIX to other > frameworks and architectures is described. > > 2. Applications of IPFIX > > IPFIX data enables several critical applications. The IPFIX > target applications and the requirements that originate from > those applications are described in [RFC3917]. Those > requirements were used as basis for the design of the IPFIX > protocol. This section describes how these target applications > can use the IPFIX protocol. Considerations for using IPFIX for > other applications than described in [RFC3917] can be found in > section 4.1. > > 2.1 Accounting > > Usage based accounting is one of the major applications for > which the IPFIX protocol has been developed. IPFIX records > provide fine-grained measurement results for highly flexible and > detailed resource usage accounting. > In order to realize usage-based accounting with IPFIX the flow > definition has to be chosen in accordance to the tariff model. > Flows can be distinguished by various IEs (e.g. packet header > fields) from [IPFIX-INFO]. Due to the flexible IPFIX flow > definition, arbitrary flow-based accounting models can be > realized without extensions to the IPFIX protocol. > > A tariff can, for instance, be based on individual end-to-end > flows, in which case accounting can be realized with a flow > definition determined by the quintuple consisting of source > address (sourceIPv4Address), destination address > (destinationIPv4Address), protocol (protocolIdentifier) and port > numbers (e.g., udpSourcePort, udpDestinationPort). Another > example is a class-dependent tariff (e.g. in a DiffServ > network). In this case flows could be distinguished just by the > DiffServ codepoint (DSCP) (ipDiffServCodePoint) and IP addresses > (sourceIPv4Address, destinationIPv4Address). The essential > elements needed for accounting are the number of transferred > > > > > > Zseby, Boschi, Brownlee, Claise [Page 4] > IPFIX Applicability May 2006 > > > > packets and bytes per flow, which can be represented by the per- > flow counter IEs (e.g., packetTotalCount, octetTotalCount). > > For accounting purposes, it would be advantageous to have the > ability to use IPFIX flow records as accounting input in an AAA > infrastructure. AAA servers then could provide the mapping > between user and flow information. > > Note that the reliability requirements defined in [RFC3917] are > not sufficient to guarantee the level of reliability that is > needed for many usage-based accounting systems. Particular > reliability requirements for accounting systems are discussed in > [RFC2975]. > > 2.1.1 Example > > Please note: [RFC3330] demands the use of the address block > 192.0.2.0/24 for example addresses. In the example below we use > two example networks. In order to be conformant to [RFC3330] we > divide the given address block into two networks by subnetting > with a 25 bit netmask (192.0.2.0/25) as follows: > > Network A: 192.0.2.0 ... 192.0.2.127 > Network B: 192.0.2.128 ... 192.0.2.255 > > Let's suppose someone has a Service Level Agreement (SLA) in a > DiffServ network requiring accounting based on traffic volume. > Flows are distinguished by source and destination address. The > information to export in this case is: > - IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], > with a length of 4 octets > - IPv4 destination IP address: destinationIPv4Address in > [IPFIX-INFO], with a length of 4 octets > - DSCP: ipDiffServCodePoint in [IPFIX-INFO], with a length of > 1 octet > - Number of octets of the Flow: OctetDeltaCount in [IPFIX- > INFO], with a length of 4 octets > > The template set will look as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 24 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > Zseby, Boschi, Brownlee, Claise [Page 5] > IPFIX Applicability May 2006 > > > > |0| ipDiffServCodePoint = 195 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| OctetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The information to be exported might be as listed in the > following example table: > > Src. IP addr. | Dst. IP addr. | DSCP | Octets Number > --------------+---------------+--------+-------------- > 192.0.2.12 | 192.0.2.144 | 46 | 120868 > 192.0.2.24 | 192.0.2.156 | 46 | 310364 > 192.0.2.36 | 192.0.2.168 | 46 | 241239 > > In the example we use Diffserv CodePoint 46, recommended for the > Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC2598]. > > The Flow Records will then look as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 43 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.144 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 46 | 120868 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 192.0.2.24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 192.0.2.156 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 46 | 310364 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 192.0.2.36 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 192.0.2.168 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 46 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 241239 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 2.2 Traffic Profiling > > > > > > Zseby, Boschi, Brownlee, Claise [Page 6] > IPFIX Applicability May 2006 > > > > Measurement results reported in IPFIX records can be used for > traffic profiling. IPFIX records captured over a long period of > time can be used to track and anticipate network growth and > usage. Such Information is valuable for trend analysis and > network planning. > > The parameters of interest are determined by the profiling > objectives. Example parameters for traffic profiling are flow > duration, flow volume, burstiness, the distribution of used > services and protocols, the amount of packets of a specific > type, etc. [RFC3917]. > > The distribution of services and protocols in use can be > analyzed by configuring appropriate flows keys for flow > discrimination. Protocols can be distinguished by the > protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) > often provide information about services in use. Those flow keys > are defined in [IPFIX-INFO]. If portnumbers are not sufficient > for service discrimination, further parts of the packet may be > needed. Header fields can be expressed by IEs from [IPFIX-INFO] > Packet payload can be reported by using the IE > ipPayloadPacketSection in [PSAMP-INFO]. > > The flow duration can be calculated from the flow time stamp IEs > defined in [IPFIX-INFO] (e.g., flowEndMicroseconds - > flowStartMicroseconds). The number of packets and number of > bytes of a flow are represented in the per-flow counter IEs > (e.g., packetTotalCount, octetTotalCount). The burstiness of a > flow can be calculated from the flow volume measured at > different time intervals. > > 2.3 Traffic Engineering > > Traffic engineering aims at the optimization of network resource > utilization and traffic performance [RFC2702]. Typical > parameters are link utilization, load between specific network, > nodes, number, size and entry/exit points of active flows and > routing information [RFC3917]. > Size of flows in packets and bytes can be reported by IEs > packetTotalCount, octetTotalCount. Link utilization can be > reported by using a coarse grained flow definition (e.g. based > on identifier IEs such as egressInterface or ingressInterface) > and per-flow counter IEs (e.g. packetTotalCount, > octetTotalCount) defined in [IPFIX-INFO]. > > The load between specific network nodes can be reported in the > same way if one interface of a network node receives only > > > > > > Zseby, Boschi, Brownlee, Claise [Page 7] > IPFIX Applicability May 2006 > > > > traffic from exactly one neighbor node (as usually the case). If > the ingress interface is not sufficient for an unambiguous > identification of the neighbor node, sub-IP header fields IEs > (like sourceMacAddress) can be added as flow keys. > > The IE observedFlowTotalCount provides the number of all flows > exported for the observation domain since the last > initialization of the metering process [IPFIX-INFO]. If this IE > is exported at subsequent points in time, one can derive the > number of active flows in a specific time interval from the > difference of the reported counters. The configured flow > termination criteria have to be taken into account to interpret > that numbers correctly. > > Entry and exit points can be derived from flow records if > metering processes are installed at all edges of the network and > results are mapped in accordance to flow keys. For this and > other analysis methods that require the mapping of records from > different observation points, the same flow keys should be used > at all observation points. The path that packets take through a > network can be investigated by using hash-based sampling > techniques as described in [DuGr00] and [PSAMP-TECH]. For this > IEs from [PSAMP-INFO] are needed. > > Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for > exporting routing information. > > 2.4 Network Security > > Attack and intrusion detection are among the IPFIX target > applications described in [RFC3917]. Due to the enormous amount > of different network attack types, only general requirements > could be addressed in [RFC3917]. > > IPFIX can export flow information for arbitrary flow definitions > as defined in [IPFIX-PROTO]. Packet information can be exported > with IPFIX by using the additional information elements > described in [PSAMP-INFO]. With this theoretically all > information about traffic in the network at IP layer and above > is accessible. This data can be used either directly to detect > anomalies or can provide the basis for further post processing > to generate more complex attack detection metrics. > > Depending on the attack type different metrics are useful. A > sudden increase of traffic load can be a hint that an attack has > been launched. The overall traffic at an observation point can > be monitored using per-flow counter IEs like packetTotalCount, > octetTotalCount as described in 2.3. The number of active flows > > > > > Zseby, Boschi, Brownlee, Claise [Page 8] > IPFIX Applicability May 2006 > > > > can be monitored by regular reporting of the > observedFlowTotalCount. > > A sudden increase of flows from different sources to one > destination may be caused by an attack on a specific host or > network node using spoofed addresses. Many flows to the same > machine but on different ports or many flows to the same port > and different machines may be an indicator for vertical or > horizontal port scanning activities. An unusual ratio of TCP-SYN > to TCP-FIN packets can refer to SYN-flooding. Worms may leave > signatures in traffic patterns. > > The amount of metrics useful for attack detection is as diverse > as attack patterns themselves. Attackers adapt rapidly to > circumvent detection methods and try to hide attack patterns > using slow or stealth attacks. Furthermore, unusual traffic > patterns are not always caused by malicious activities. A sudden > traffic increase may be caused by legitimate users who seek > access to a recently published content. Strange traffic patterns > may also be caused by mis-configuration. > > The difficult task is the separation of good from bad packets to > prepare and launch counteraction. This may require a deeper look > into packet content by using further header field IEs from > [IPFIX-INFO] and/or packet payload from IE > ipPayloadPacketSection in [PSAMP-INFO]. Multi-step analysis > techniques may be useful, e.g., to launch an in-depth analysis > (e.g. based on packet information) in case the flow information > shows suspicious patterns. In order to supervise traffic to a > specific host or network node one has to apply filtering methods > as those described in [PSAMP-TECH]. > > Mapping the two directions of a communication is often useful > for checking correct protocol behavior (see section 4.5). A > correlation of IPFIX data from multiple observation points (see > section 2.5.1) allows assessing the propagation of an attack and > can help to locate its source. > > The integration of previous measurement results helps to review > traffic changes over time for detection of traffic anomalies and > provides the basis for forensic analysis. A standardized storage > format for IPIFX data would support the offline analysis of data > from different operators. > > Nevertheless, capturing full packet traces at all observation > points in the network is not viable due to resource limitations > and privacy concerns. Therefore metrics should be chosen wisely > to allow a solid detection with minimal resource consumption. > > > > > Zseby, Boschi, Brownlee, Claise [Page 9] > IPFIX Applicability May 2006 > > > > Resources can be saved for instance by using coarser grained > flow definitions, reporting pre-processed metrics (e.g. with > additional information elements) or deployment of sampling > methods. > > Detecting security incidents in real-time often requires the > pre-processing of data already at the measurement device. > Immediate data export in case of a potential incident is > desired. IPIFX supports such source-triggered exporting of > information due to the push model approach. Nevertheless, > further exporting criteria have to be implemented to export > IPFIX records upon incident detection events and not only upon > flow end or fixed time intervals. > > Security incidents can become a threat to IPFIX processes > themselves (see also security considerations in [IPFIX-PROTO]). > If an attack generates a large amount of flows (e.g. by sending > packets with spoofed addresses or simulating flow termination) > exporting and collecting process may get overloaded by the > immense amount of records that are exported. A flexible > deployment of packet or flow sampling methods can prevent the > exhaustion of resources. > > Intrusion detection would profit from the combination of IPFIX > functions with AAA functions (see section 3.4). Such an > interoperation enables further means for attacker detection, > advanced defense strategies and secure inter-domain cooperation. > > 2.5 QoS Monitoring > > QoS monitoring is one target application of the IPFIX protocol > [RFC3917]. QoS monitoring is the passive observation of the > transmission quality for single flows or traffic aggregates in > the network. One example of its use is the validation of QoS > guarantees in service level agreements (SLAs). Typical QoS > parameters are loss [RFC2680], one-way [RFC2679] and round-trip > delay [RFC2681] and delay variation [RFC3393]. The calculation > of those QoS metrics requires per-packet processing. Reporting > packet information with IPFIX is possible by simply considering > a single packet as flow. [IPFIX-PROTO] also allows the reporting > of multiple identical information elements in one flow record. > Using this feature for reporting information about multiple > packets in one record would require additional agreement on > semantics regarding the order of information elements (e.g. > which timestamp belongs to which packet payload in a sequence of > information elements). [PSAMP-INFO] defines useful additional > information elements for exporting per packet information with > IPFIX. > > > > > Zseby, Boschi, Brownlee, Claise [Page 10] > IPFIX Applicability May 2006 > > > > > 2.5.1 Correlating Events from Multiple Observation Points > > Some QoS metrics require the correlation of data from multiple > observation points. For this the clocks of the involved metering > processes must be synchronized. Furthermore, it is necessary to > recognize that the same packet was observed at different > observation point. > This can be done by capturing parts of the packet content > (packet header and/or parts of the payload) that do not change > on the way to the destination. Based on the packet content it > can be recognized when the same packet arrived at another > observation point. To reduce the amount of measurement data a > unique packet ID can be calculated from the packet content e.g. > by using a CRC or hash function instead of transferring and > comparing the unprocessed content. Considerations on collision > probability and efficiency of using such packet IDs are > described in [GrDM98, DuGr00, ZsZC01]. > > IPFIX allows the reporting of several IP and transport header > fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only > those fields for packet recognition or ID generation can be > sufficient in scenarios where those header fields vary a lot > among subsequent packets, where a certain amount of packet ID > collisions is tolerable or where packet IDs need to be unique > only for a small time interval. > > For including packet payload information the information element > ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The > information element ipHeaderPacketSection can also be used. But > header fields that can change on the way from source to > destination have to be excluded from the packet ID generation, > because they may differ at different observation points. > > For reporting packet IDs generated by a CRC or hash function the > information element digestHashValue defined in [PSAMP-INFO] can > be used. > > 2.5.2 Examples > > The following examples show which information elements need to > be reported by IPFIX to generate specific QoS metrics. As an > alternative the metrics can be generated directly at the > exporter and IPIFX can be used to export the metrics (see > section 2.7) > > 2.5.2.1 RTT measurements with packet pair matching (single-point) > > > > > > Zseby, Boschi, Brownlee, Claise [Page 11] > IPFIX Applicability May 2006 > > > > The passive measurement of round-trip-times (RTT) can be > performed by using packet pair matching techniques as described > in [Brow00]. For the measurements, request/response packet pairs > from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, > DATA/ACK) are utilized to passively observe the RTT [Brow00]. > This technique requires the correlation of data from both > directions. > > Required information elements per packet (DNS example): > - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] > - DNS header: ipPayloadPacketSection [PSAMP-INFO] > > Required functions: > - Recognition of request/response packet pairs > > Remarks: > - Requires information elements from [PSAMP-INFO] > - observationTimeMicroseconds can be substituted by > flowStartMicroseconds [IPFIX-INFO], because a single packet > can be represented as a flow. > - If time values with a higher granularity are needed > observationTimeNanoseconds can be used. > > 2.5.2.2 One-way Delay Measurements (multi-point) > > Passive one-way-delay measurements require the collection of > data at two observation points. The recognition of packets at > the second observation point can be based on parts of the packet > content directly. A more efficient way is to use a packet ID > (generated from packet content). > > Required information elements per packet (with packet ID): > - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] > - Packet ID: digestHashValue [PSAMP-INFO] > > Required functions: > - packet ID generation > - delay calculation (from arrival times at the two observation > points) > > Remarks: > - Requires information elements from [PSAMP-INFO] > - observationTimeMicroseconds can be substituted by > flowStartMicroseconds [IPFIX-INFO], because a single packet > can be represented as a flow. > - If time values with a higher granularity are needed > observationTimeNanoseconds can be used. > > > > > > Zseby, Boschi, Brownlee, Claise [Page 12] > IPFIX Applicability May 2006 > > > > - The amount of content used for ID generation influences the > number of collisions (different packets that map to the same > ID) that can occur. Investigations on this and other > considerations on packet ID generation can be found in > [GrDM98], [DuGr00], and [ZsZC01]. > > 2.6 Inter-Domain Exchange of IPFIX data > > IPFIX data can be used to share information with neighbor > providers. A few recommendations should to be considered if > IPFIX records travel over the public Internet compared to its > usage within a single domain. First of all, security threats are > higher if data travels over the public Internet. Protection > against disclosure or manipulation of data is even more > important than for intra-domain usage. Therefore IPsec or > Transport Layer Security (TLS) should be used as described in > [IPFIX-PROTO]. > > Furthermore data transfer should be congestion-aware in order to > allow untroubled co-existence with other data flows. That means > transport over SCTP or TCP is required. > > Some ISPs are still reluctant to share information due to > concerns that competing ISPs might exploit network information > from neighbor providers to strengthen their own position in the > market. Nevertheless, technical needs have already triggered the > exchange of data in the past (e.g. exchange of routing > information by BGP). The need to provide inter-domain guarantees > is one big incentive to increase inter-domain cooperation. The > necessity to defend networks against current and future threats > (denial of service attacks, worm distributions, etc.) will > hopefully increase the willingness to exchange measurement data > between providers. > > 2.7 Export of Derived Metrics > > > The IPFIX protocol is used to transport flow and packet > information to provide the input for the calculation of a > variety metrics (e.g. for QoS validation or attack detection). > IPFIX can also be used to transfer these metrics directly, e.g. > if the metric calculation is co-located with measurement and > exporting process. > > It doesn't matter which measurement and post-processing > functions are applied to generate a specific metric. IPFIX can > be used to transport the results from passive and active > measurements and from post-processing operations. For the > > > > > > Zseby, Boschi, Brownlee, Claise [Page 13] > IPFIX Applicability May 2006 > > > > reporting of derived metrics additional information elements > need to be defined. > > 2.8 Summary > > The following table shows an overview of the information > elements required for the target applications described in > [RFC3917] (M-mandatory, R-recommended, O-optional). > > | Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs | > +-------------+------------+--------------+-----------------+ > | Accounting | M | - | - | > +-------------+------------+--------------+-----------------+ > | Traffic | M | O | - | > | Profiling | | | | > +-------------+------------+--------------+-----------------+ > | Traffic | M | - | O | > | Engineering | | | (routing info) | > +-------------+------------+--------------+-----------------+ > | Attack | M | R | R | > | Detection | | |(derived metrics)| > +-------------+------------+--------------+-----------------+ > | QoS | M | M | O | > | Monitoring | |(most metrics)|(derived metrics)| > +-------------+------------+--------------+-----------------+ > > For accounting the IEs in [IPFIX-INFO] are sufficient. For > traffic profiling additionally IEs from [PSAMP-INFO] can be > useful to gain more insight into the traffic. For traffic > engineering flow information from [IPFIX-INFO] is sufficient but > it would profit from routing information, which could be > exported by IPFIX. Attack detection usually profits from further > insight into the traffic. This can be achieved with IEs from > [PSAMP-INFO]. Furthermore the reporting of derived metrics in > additional IEs would be useful. Most QoS metrics require the use > of IEs from [PSAMP-INFO]. IEs from [PSAMP-INFO]are also useful > for the mapping of results from different observation points as > described in section 2.5.1. > > 3. Relation of IPFIX to Other Frameworks and Protocols > > 3.1 IPFIX and PSAMP > > PSAMP defines packet selection methods, their configuration at > routers and probes and the reporting of packet information. > > PSAMP uses IPIFX as basis for exporting packet information > [PSAMP-PROTO]. [PSAMP-INFO] describes further information > > > > > Zseby, Boschi, Brownlee, Claise [Page 14] > IPFIX Applicability May 2006 > > > > elements for exporting packet information and reporting > configuration information. > > The main difference between IPFIX and PSAMP is that IPFIX > addresses the export of flow records whereas PSAMP addresses the > export of packet records. Furthermore, PSAMP explicitly > addresses remote configuration. It defines a MIB for the > configuration of packet selection processes. Remote > configuration is not (yet) addressed in IPFIX, but one could > consider extending the PSAMP MIB to also allow configuration of > IPFIX processes. > > 3.2 IPFIX and RMON > > RMON [RFC3577] is a widely used monitoring system that gathers > traffic data from RMON Agents in network devices in a general > way using SNMP. The RMON MIB is divided into sections, each > section providing different monitoring functions. For example, > the 'Hosts' section gathers statistics for hosts which are > active on the network being monitored. > > RMON has three MIBs that deal with flow information: > > - The Application Performance Measurement MIB (APM-MIB) > [RFC3729] has a complex system for tracking user application > performance, with flow reporting and SLA threshold > notification-trigger configuration, and persistence across > DHCP lease expirations. It requires full RMON2-MIB > protocolDirTable implementation. > > - The Transport Performance Metrics MIB (TPM-MIB) [RFC4150] > breaks out the APM-MIB user flow data into statistics based on > the IPPM metrics. It requires APM-MIB and RMON2-MIB. > > - The Synthetic Sources for Performance Monitoring Algorithms > MIB (SSPM-MIB) [RFC4149] is used to configure and run packet > and flow generators for performance testing purposes. It > requires RMON2-MIB. > > 3.3 IPFIX and IPPM > > The IPFIX protocol can be used to carry IPPM network performance > metrics or information that can be used to calculate those > metrics (see sections 2.5 and 2.7). > > 3.4 IPFIX and AAA > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 15] > IPFIX Applicability May 2006 > > > > AAA defines a protocol and architecture for authentication, > authorization and accounting for service usage [RFC2903]. The > DIAMETER protocol [RFC3588] is used for AAA communication, which > is needed for network access services (Mobile IP, NASREQ, and > ROAMOPS). The AAA architecture [RFC2903] provides a framework > for extending AAA support to other services. DIAMETER defines > the exchange of messages between AAA entities, e.g. between AAA > clients at access devices and AAA servers, and among AAA > servers. DIAMETER is used for the transfer of accounting > records. In order to form accounting records for usage-based > accounting measurement data from the network is required. IPFIX > defines a protocol to export such data from routers, measurement > probes and other devices. Therefore it looks promising to > connect those two architectures. > > As shown in section 2.1 accounting can be realized without an > AAA infrastructure. Accounting applications can directly > incorporate an IPFIX collecting process to receive IPFIX records > with information about the transmitted volume. Nevertheless, if > an AAA infrastructure is in place, the cooperation between IPFIX > and AAA provides many valuable synergistic benefits. IPFIX > records can provide the input for AAA accounting functions and > provide the basis for the generation of DIAMETER accounting > records. Further potential features include the mapping of a > user ID to flow information (by using authentication > information) or facilitating the secure authorized exchange of > DIAMETER accounting records with neighbor domains. The last > feature is especially useful in roaming scenarios where the user > connects to a foreign network and the home provider generates > the invoice. > > Coupling an IPFIX collecting process with AAA functions has also > high potential for intrusion and attack detection. AAA controls > network access and maintains data about users and nodes. AAA > functions can help to identify the source of malicious traffic. > They are able to deny access to suspicious users or nodes. > Therefore coupling those functions with an IPFIX collecting > process can provide an efficient defense against network > attacks. Sharing IPFIX records (either directly or encapsulated > in DIAMETER) with neighbor providers allows an efficient inter- > domain attack detection. The AAA infrastructure can also be used > to configure measurement functions in the network as proposed in > [RFC3334]. > > Two possibilities exist to connect IPFIX and AAA: > > - Connecting via an AAA Client > - Connecting via an Application Specific Module (ASM) > > > > > Zseby, Boschi, Brownlee, Claise [Page 16] > IPFIX Applicability May 2006 > > > > > Both are explained in the following sections. The approaches > only require few additional functions. They do not require any > changes to IPFIX or DIAMETER. > > 3.4.1 Connecting via an AAA Client > > One possibility of connecting IPFIX and AAA is to run an AAA > client on the IPFIX collector. This client can generate DIAMETER > accounting messages and send them to an AAA server. The mapping > of the flow information to a user ID can be done in the AAA > server by using data from the authentication process. DIAMETER > accounting messages can be sent to the accounting application or > to other AAA servers (e.g. in roaming scenarios). > > +---------+ DIAMETER +---------+ > | AAA-S |------------->| AAA-S | > +---------+ +---------+ > ^ > | DIAMETER > | > | > +--+--------+--+ > | | AAA-C | | > + +--------+ | > | | > | Collector | > +--------------+ > ^ > | IPFIX > | > +------------+ > | Exporter | > +------------+ > > Figure 2: IPFIX collector connects to AAA server via AAA client > > 3.4.2 Connecting via an Application Specific Module (ASM) > > Another possibility is to directly connect the IPFIX collector > with the AAA server via an application specific module (ASM). > Application specific modules have been proposed by the IRTF AAA > architecture research group (AAARCH) in [RFC2903]. They act as > an interface between AAA server and service equipment. In this > case the IPFIX collector is part of the ASM. The ASM acts as an > interface between the IPFIX protocol and the input interface of > the AAA server. The ASM translates the received IPFIX data into > an appropriate format for the AAA server. The AAA server then > > > > > Zseby, Boschi, Brownlee, Claise [Page 17] > IPFIX Applicability May 2006 > > > > can add information about the user ID and generate a DIAMETER > accounting record. This accounting record can be sent to an > accounting application or to other AAA servers. > > +---------+ DIAMETER +---------+ > | AAA-S |------------->| AAA-S | > +---------+ +---------+ > ^ > | > +------------------+ > | ASM | > | +------------+ | > | | Collector | | > +------------------+ > ^ > | IPFIX > | > +------------+ > | Exporter | > +------------+ > > Figure 3: IPFIX connects to AAA server via ASM > > 3.5 IPFIX and RTFM > > The Real-time Traffic Flow Measurement (RTFM) working group > defined an architecture for flow measurement [RFC2722]. This > section compares the Real-time Traffic Flow Measurement (RTFM) > framework with the IPFIX framework. > > 3.5.1 Architecture > > The RTFM architecture is very similar to the IPFIX architecture. > It defines meter, meter reader and a manager as building blocks > of the measurement architecture. The manager configures the > meter and the meter reader collects data from the meter. > In RTFM the building blocks communicate via SNMP. > The IPFIX architecture [IPFIX-ARCH] defines metering, exporting > and collecting processes. IPFIX speaks about processes instead > of devices to clarify that multiple of those processes may be > collocated on the same machine. > Both definitions do not contradict each other. One could see the > metering process as part of the meter and the collecting process > as part of the meter reader. > One difference is that IPFIX currently does not define a > managing process, because remote configuration was at least > initially out of scope for the working group. > > > > > > Zseby, Boschi, Brownlee, Claise [Page 18] > IPFIX Applicability May 2006 > > > > 3.5.2 Flow Definition > > RTFM and IPFIX both consider flows as a group of packets which > share a common set of properties. A flow is completely specified > by that set of values, together with a termination criterion > (like inactivity timeout). > > A difference is that RTFM defines flows as bidirectional. An > RTFM meter matches packets from B to A and A to B as separate > parts of a single flow, and maintains two sets of packet and > byte counters, one for each direction. > > IPFIX does not explicitly state whether flows are uni- or > bidirectional. Nevertheless information elements for describing > flow properties were defined only for one direction in [IPFIX- > INFO]. Nevertheless, there are several solutions for reporting > bi-directional flow information (see section 4.5). > > 3.5.3 Configuration and Management > > In RTFM, remote configuration is the only way to configure a > meter. This is done by using SNMP and a specific Meter MIB [RFC > 2720]. The IPFIX group currently does not address IPFIX remote > configuration. > > IPFIX metering processes export the layout of data within their > templates, from time to time. IPFIX collecting processes use > that template information to determine how they should interpret > the IPFIX flow data they receive. > > 3.5.4 Data Collection > > One major difference between IPFIX and RTFM is the data > collection model. RTFM retrieves data in pull mode whereas IPFIX > uses a push mode model to send data to collecting processes. > > An RTFM meter reader pulls data from a meter by using SNMP. SNMP > security on the meter determines whether a reader is allowed to > pull data from it. An IPFIX exporting process is configured to > export records to a specified list of IPFIX collecting > processes. The condition when to send IPFIX records (e.g. flow > termination) has to be configured in the exporting or metering > process. > > 3.5.5 Data Model Details > > > > > > Zseby, Boschi, Brownlee, Claise [Page 19] > IPFIX Applicability May 2006 > > > > RTFM defines all its attributes in the RTFM Meter MIB [RFC > 2720]. IPFIX information elements are defined in [IPFIX-INFO]. > > RTFM uses continuously-incrementing 64-bit counters for the > storage of the number of packets of a flow. The counters are > never reset and just wrap back to zero if the maximum value is > exceeded. Flows can be read at any time. The difference between > counter readings gives the counts for activity in the interval > between readings. > IPFIX allows absolute (totalCounter) and relative counters > (deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and > just wraps to zero if values are too large, exactly as the > counters used in RTFM. The deltaCounter is reset to zero when > the associated flow record is exported. > > 3.5.6 Transport Protocol > > RTFM has a standards-track Meter MIB [RFC 2720], which is used > both to configure a meter and to store metering results. The > MIB provides a way to read lists of attributes with a single > Object Identifier (called a 'package'), which reduces the SNMP > overhead for flow data collection. SNMP, of course, normally > uses UDP as its transport protocol. Since RTFM requires a > reliable flow data transport system, an RTFM meter reader must > time out and resend unanswered SNMP requests. Apart from being > clumsy, this can limit the maximum data transfer rate from meter > to meter reader. > > IPFIX is designed to work over a variety of different transport > protocols. SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory. > UDP and TCP are optional. In addition, the IPFIX protocol > encodes data much more efficiently than SNMP does, hence IPFIX > has lower data transport overheads than RTFM. > > 3.5.7 Summary > > IPFIX exports flow information in push model by using SCTP, TCP > or UDP. It currently does not address remote configuration. RTFM > data collection is using the pull model and runs over SNMP. RTFM > addresses remote configuration which also runs over SNMP. Both > frameworks allow a very flexible flow definition, although RTFM > is based on a bi-directional flow definition. > > 4. Limitations > > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 20] > IPFIX Applicability May 2006 > > > > The goal of this section is to show the limitations of IPFIX and > to give advice where not to use IPFIX or in which cases > additional considerations are required. > > 4.1 Using IPFIX for other Applications than in RFC3917 > > IPFIX provides a generic export mechanism. Due to its template > based structure, it is a quite flexible protocol. Network > operators and users may want to use it also for other > applications than those described in [RFC 3917]. > > Apart from sending raw flow information it can be used to send > aggregated or post-processed data. For this new templates and > information elements can be defined if needed. Due to its push > mode operation IPFIX is also suited to send network initiated > events like alarms and other notifications. It can be used for > exchanging information among network nodes to autonomously > improve network operation. > > Nevertheless, the IPFIX design is based on the requirements that > originate only from the target applications stated in [RFC > 3917]. Using IPFIX for other purposes requires a careful > checking of IPFIX capabilities against application requirements. > Only with this, can one decide whether IPFIX is a suitable > protocol to meet the needs of a specific application. > > 4.2 Using a Different Transport Protocol than SCTP > > SCTP is the preferred protocol for IPFIX, i.e. a conforming > implementation must work over SCTP. Although IPFIX can also work > over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO]. > Users should make sure they have good reasons befor using > protocols other than SCTP in a specific environment. > > 4.3 Push vs. Pull Mode > > IPFIX works in push mode. That means IPFIX records are > automatically exported without waiting for a request. > The responsibility for initiating a data export lies with the > exporting process. > > Criteria for exporting data need to be configured at the > exporting process. Therefore push mode has more benefits if the > trigger for data export is related to events at the exporting > process (e.g. flow termination, memory shortage due to large > amount of flows, etc.). If the protocol used pull mode, the > exporting process would need to wait for a request to send the > > > > > > Zseby, Boschi, Brownlee, Claise [Page 21] > IPFIX Applicability May 2006 > > > > data. With push mode it can send data immediately e.g. before > memory shortage would require a discarding of data. > > With push mode one can prevent the overloading of resources at > the exporting process by simply exporting the information as > soon as certain thresholds are about to exceed. Therefore > exporting criteria are often related to traffic characteristics > (e.g. flow timeout) or resource limitations (e.g. size of flow > cache). But traffic characteristics are usually quite dynamic > and often impossible to predict. If those are used to trigger > flow export, the exporting rate and the resource consumption for > flow export becomes variable and unpredictable. > > Pull mode has advantages if the trigger for data export is > related to events at the collecting process (e.g. a specific > application requests immediate input). > > In a pull mode, a request could simply be forwarded to the > exporting process. In a push mode, the exporting configuration > must be changed to trigger the export of the requested data. > Furthermore, with pull mode one can prevent the overloading of > the collecting process by the arrival of more records than it > can process. > > Whether this is a relevant drawback depends on the flexibility > of the IPFIX configuration and how IPFIX configuration rules are > implemented. > > > 4.4 Template ID number > > The IPFIX specification limits the different template ID numbers > that can be assigned to the newly generated template records in > an observation domain. In particular, template IDs up to 255 are > reserved for Template or option sets (or other sets to be > created) and template IDs from 256 to 65535 are assigned to data > sets. In the case of many exports requiring many different > templates, the set of Template IDs could be exhausted. > > 4.5 Exporting Bidirectional Flow Information > > Although IPFIX does not explicitly state that flows are > unidirectional, information elements that describe flow > characteristics are defined only for one direction in [IPFIX- > INFO]. [IPFIX-PROTO] allows the reporting of multiple identical > information elements in one flow record. With this information > elements for forward and reverse direction can be reported in > one flow record. > > > > > Zseby, Boschi, Brownlee, Claise [Page 22] > IPFIX Applicability May 2006 > > > > > But this is not sufficient. Using this feature for reporting > bidirectional flow information would require an agreement on the > semantic of information elements (e.g. first counter is counter > for the forward direction, second counter for reverse > direction). > > Another option is to use two adjacent flow records to report > both directions of a bidirectional flow separately. This > approach requires additional means for mapping those records and > is quite inefficient due to the redundant reporting of flow > keys. > > 4.6 IPFIX and IPv6 > > There are two issues to consider: > > - Generation and reporting of IPFIX records about IPv6 traffic > - Exporting IPFIX records over IPv6 > > The generation and reporting of IPFIX records about IPv6 traffic > is possible as appropriate information elements exist in [IPFIX- > INFO]. > Exporting IPFIX records over IPv6 is not explicitly addressed in > [IPFIX-PROTO]. Since IPFIX runs over SCTP, SCTP-PR, UDP or TCP, > it is trivial to run IPFIX over IPv6 networks, provided that the > transport protocol being used to carry IPFIX is running on the > IPv6 network. > > 5. Security Considerations > > This document describes the usage of IPFIX in various scenarios. > Security requirements for IPFIX target applications and security > considerations for IPFIX are addressed in [RFC3917] and [IPFIX- > PROTO]. Those requirements have to be met for the usage of > IPFIX. To our current knowledge, the usage scenarios proposed in > section 2 do not induce further security hazards. > > Section 3 of this document describes how IPFIX can be used in > combination with other frameworks. New security hazards can > arise when two individually secure frameworks are combined. For > the combination of AAA with IPFIX an application specific module > (ASM) or an IPFIX collector can function as transit point for > the messages. It has to be ensured that at this point the > applied security mechanisms (e.g. encryption of messages) are > maintained. > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 23] > IPFIX Applicability May 2006 > > > > 6. Normative References > > [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model > for IP Flow Information Export", Internet Draft > <draft-ietf-ipfix-info-07>, work in progress, May > 2005 > > [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification", > Internet Draft <draft-ietf-ipfix-protocol-21.txt>, > work in progress, April 2006 > > [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, > "Information Model for Packet Sampling Exports", > Internet Draft <draft-ietf-psamp-info-04.txt>, work > in progress, March 2006 > > [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, > "Requirements for IP Flow Information Export", RFC > 3917, October 2004 > > 7. Informative References > > [Brow00] Nevil Brownlee, "Packet Matching for NeTraMet > Distributions", > http://www2.auckland.ac.nz/net//Internet/rtfm/meeti > ngs/47-adelaide/pp-dist/ > > [DuGr00] Nick Duffield, Matthias Grossglauser, "Trajectory > Sampling for Direct Traffic Observation", > Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, > August 28 - September 1, 2000 > > [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, > Jed Martens, John G. Cleary, "Nonintrusive and > Accurate Measurement of Unidirectional Delay and > Delay Variation on the Internet", INET'98, Geneva, > Switzerland, 21-24 July, 1998 > > [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, > "Architecture for IP Flow Information Export", > Internet Draft <draft-ietf-ipfix-architecture- > 08.txt>, work in progress, March 2005 > > [PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP) > Protocol Specifications, Internet Draft <draft- > ietf-psamp-protocol-04.txt>, work in progress, > March 2006 > > > > > > Zseby, Boschi, Brownlee, Claise [Page 24] > IPFIX Applicability May 2006 > > > > [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. > Raspall, "Sampling and Filtering Techniques for IP > Packet Selection" Internet Draft <draft-ietf-psamp- > sample-tech-07.txt>, work in progress, July 2005 > > [RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited > Forwarding PHB", RFC 2598, June 1999 > > [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way > Delay Metric for IPPM", RFC 2679, September 1999 > > [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way > Packet Loss Metric for IPPM",RFC 2680, September > 1999 > > [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip > Delay Metric for IPPM", RFC 2681, September 1999 > > [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. > McManus, "Requirements for Traffic Engineering Over > MPLS", RFC 2702, September 1999 > > [RFC2722] Brownlee, N., Mills, C., G. Ruth, "Traffic Flow > Measurement: Architecture", RFC 2722, October 1999 > > [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. > Spence, "Generic AAA Architecture", RFC 2903, > August 2000 > > [RFC2960] R. Stewart (ed.) "Stream Control Transmission > Protocol", RFC 2960, October 2000 > > [RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to > Accounting Management", RFC 2975, October 2000 > > [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330 > September 2002 > > [RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based > Accounting", RFC 3334, October 2002 > > [RFC3393] C. Demichelis, P. Cimento, "IP Packet Delay > Variation Metric for IPPM", RFC 3393, November 2002 > > [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, > D.Romascanu, "Introduction to the Remote Monitoring > (RMON) Family of MIB Module", RFC 3577, August 2003 > > > > > > Zseby, Boschi, Brownlee, Claise [Page 25] > IPFIX Applicability May 2006 > > > > [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. > Arkko, "Diameter Base Protocol", RFC 3588, > September 2003 > > [RFC3729] S. Waldbusser, "Application Performance Measurement > MIB", RFC 3729, March 2004 > > [RFC3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. > Conrad, "Stream Control Transmission Protocol > (SCTP) Partial Reliability Extension", RFC 3758, > May 2004 > > [RFC4149] C. Kalbfleisch, R. Cole, D. Romascanu, "Definition > of Managed Objects for Synthetic Sources for > Performance Monitoring Algorithms", RFC 4149, > August 2005 > > [RFC4150] R. Dietz, R. Cole, "Transport Performance Metrics > MIB", RFC 4150, August 2005 > > [ZsZC01] T. Zseby, S. Zander, G. Carle, "Evaluation of > Building Blocks for Passive One-way-delay > Measurements", Proceedings of Passive and Active > Measurement Workshop (PAM 2001), Amsterdam, The > Netherlands, April 23-24, 2001 > > 8. Acknowledgements > > We would like to thank the following persons for their > contribution, discussion on the mailing list and valuable > comments: > > Sebastian Zander > Robert Loewe > Reinaldo Penno > Lutz Mark > Andy Biermann > > Part of the work has been developed in the research project 6QM > co-funded with support from the European Commission. > > 9. Authors' Addresses > > Tanja Zseby > Fraunhofer Institute for Open Communication Systems (FOKUS) > Kaiserin-Augusta-Allee 31 > 10589 Berlin, Germany > Phone: +49 30 3463 7153 > > > > > Zseby, Boschi, Brownlee, Claise [Page 26] > IPFIX Applicability May 2006 > > > > Email: zseby@fokus.fhg.de > > Elisa Boschi > Hitachi Europe SAS > Immeuble Le Theleme > 1503 Route des Dolines > 06560 Valbonne, France > Phone: +33 4 89874180 > Email: elisa.boschi@hitachi-eu.com > > Nevil Brownlee > CAIDA (UCSD/SDSC) > 9500 Gilman Drive > La Jolla, CA 92093-0505 > Phone : +1 858 534 8338 > Email : nevil@caida.org > > Benoit Claise > Cisco Systems > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > 10.Full Copyright Statement > > "Copyright (C) The Internet Society (2006). 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. > > 11. Intellectual Property Statement > > The IETF has been notified by Cisco of intellectual property > rights claimed in regard to some or all of the specification > contained in this document. For more information, see > > > > > > Zseby, Boschi, Brownlee, Claise [Page 27] > IPFIX Applicability May 2006 > > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix-as- > 02.txt > > The IETF takes no position regarding the validity or scope of > any Intellectual Property Rights or other rights that might be > claimed to pertain to the implementation or use of the > technology described in this document or the extent to which any > license under such rights might or might not be available; nor > does it represent that it has made any independent effort to > identify any such rights. Information on the procedures with > respect to rights in RFC documents can be found in BCP 78 and > BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the > use of such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention > any copyrights, patents or patent applications, or other > proprietary rights that may cover technology that may be > required to implement this standard. Please address the > information to the IETF at ietf-ipr@ietf.org. > > 12. Copyright Statement > > Copyright (C) The Internet Society (2006). This document is > subject to the rights, licenses and restrictions contained in > BCP 78, and except as set forth therein, the authors retain all > their rights. > > 13. Disclaimer > > This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. > > > > > > > > > > Zseby, Boschi, Brownlee, Claise [Page 28] >
- [ipfix] update of IPFIX-AS Tanja Zseby
- Re: [ipfix] update of IPFIX-AS Benoit Claise
- Re: [ipfix] update of IPFIX-AS -> IPFIX-PROTO com… Benoit Claise