IPFIX Working Group B. Claise Internet-Draft P. Aitken Intended Status: Informational A. Johnson Expires: May 19th, 2008 Cisco Systems, Inc. November 19th 2007 IPFIX Export per SCTP Stream draft-claise-ipfix-export-per-sctp-stream-02 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. This Internet-Draft will expire on June, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Expires May 19, 2008 [Page 1] Internet-Draft November 2007 Abstract This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications: exporting each template record and the associated data records within a unique SCTP stream. This specification offers several advantages: the data loss for each template record can be deduced, the transmission order is maintained, and the collecting process's job is easier. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Open Issues and Action Items for the next draft version.....3 2. Terminology.................................................4 2.1. IPFIX Documents Overview...............................4 2.2. PSAMP Documents Overview...............................4 3. Introduction................................................5 3.1. Applicability..........................................5 4. High Level View of the Proposal and Advantages..............6 4.1. First Advantage: Data Record Loss per Template.........6 4.2. Second Advantage: Transmission Order...................7 4.3. Third Advantage: Easier Job for the Collecting Process.8 5. Specifications..............................................9 5.1. PR-SCTP................................................9 5.2. Template Management....................................9 5.2.1. Template Withdrawal Message......................13 5.3. The Collecting Process's Side.........................14 6. IANA Considerations........................................15 7. Security Considerations....................................16 8. References.................................................16 8.1. Normative References..................................16 8.2. Informative References................................16 9. Acknowledgements...........................................17 10. Author's Addresses........................................18 11. Intellectual Property Statement...........................18 12. Copyright Statement.......................................19 13. Disclaimer................................................19 Expires May 19, 2008 [Page 2] Internet-Draft November 2007 1. Open Issues and Action Items for the next draft version - "Redefinition of the Template ID is not encouraged. Instead, new Template ID SHOULD be used, until the exhaustion of the Template ID space." A MUST? This would help solving this issue: "Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template which has already been received but which has not previously been withdrawn (i.e. a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association" - "The IPFIX protocol has a Sequence Number field in the Export header which increases with the number of IPFIX Data Records in the IPFIX Message. A Collector may detect out of sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number". Potentially an example - "If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template is used, then the Collecting Process MUST shutdown the association. " Is this sentence necessary? SHOULD? - Shall we use the counter reset mechanism in SCTP to indicate that there was something wrong with this specific Template/stream, that the template ID should be discarded on the Collecting Process? Proposal: presumably some indication of the stream reset is given to the higher level process. If so, that indication can be used for this purpose, yes. - Explain in more details the limitation of the IPFIX spec and of this draft? I.e., in figure 4, the potential head of line blocking could imply that the Data Records in a different stream might arrive before the Template Records. In other words, no guarantee that the Data Records will always arrive after the Template Record, if the Template Record and Data Records are not sent in the same stream o Proposal: have a full section on this issue, to discuss what has been improved in this draft compared to [IPFIX- PROTO] -> advantage: order in the stream, reuse timer, The Template Withdrawal Message MUST be sent in the last used stream that carried the Template ID to be removed - "The Template Withdrawal Message SHOULD be sent in the last used stream that carried the Template ID to be removed. " o MUST? o If no data records have been sent for 3 seconds, we do not care on which stream we send it. Expires May 19, 2008 [Page 3] Internet-Draft November 2007 2. Terminology IPFIX-specific terminology used in this document is defined in section 2 of [IPFIX-PROTO]. As in [IPFIX-PROTO], these IPFIX- specific terms have the first letter of a word capitalized when used in this document. 2.1. IPFIX Documents Overview The IPFIX Protocol [IPFIX-PROTO] provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX exporting process to a collecting process is defined in the IPFIX Architecture [IPFIX-ARCH], per the requirements defined in RFC 3917 [RFC3917]. The IPFIX Architecture [IPFIX-ARCH] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in the IPFIX Information Model [IPFIX-INFO]. Finally the IPFIX Applicability Statement [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. 2.2. PSAMP Documents Overview The document "A Framework for Packet Selection and Reporting" [PSAMP-FMWK], describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a collector. The set of packet selection techniques (sampling, filtering, and hashing) supported by PSAMP are described in "Sampling and Filtering Techniques for IP Packet Selection" [PSAMP-TECH]. The PSAMP protocol [PSAMP-PROTO] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Expires May 19, 2008 [Page 4] Internet-Draft November 2007 Process. Like IPFIX, PSAMP has a formal description of its information elements, their name, type and additional semantic information. The PSAMP information model is defined in [PSAMP- INFO]. Finally [PSAMP-MIB] describes the PSAMP Management Information Base. 3. Introduction The IPFIX working group has specified a protocol to export IP Flow information [IPFIX-PROTO]. This protocol is designed to export information about IP traffic flows and related measurement data, where a flow is defined by a set of key attributes (e.g. source and destination IP address, source and destination port, etc.). However, thanks to its template mechanism, the IPFIX protocol can export any type of information, as long as the relevant Information Element is specified in the IPFIX Information Model [IPFIX-INFO], registered with IANA, or specified as an enterprise-specific Information Element. The IPFIX protocol [IPFIX-PROTO] specifies that IP traffic measurements for flows are exported using a TLV (type, length, value) format. The information is exported using a Template Record that is sent once to export the {type, length} pairs that define the data format for one or more Data Records that are sent for a flow. The Data Records specify values for each flow. The IPFIX protocol [IPFIX-PROTO] is flexible: it foresees the usage of the multiple SCTP streams per association, and allows the transmission of Data Sets, Template Sets, and/or Options Template Sets on any stream. By exporting each Template Record and the associated Data Records within a unique SCTP stream, this specification offers several advantages such as: the data loss for each template record can be deduced, the transmission order is maintained, and the collecting process's job is easier. Each of those advantages will be described in this document. 3.1. Applicability The specifications in this document applies to the IPFIX protocol specifications [IPFIX-PROTO]. However, it only applies Expires May 19, 2008 [Page 5] Internet-Draft November 2007 to the PR-SCTP transport [RFC3758] protocol. All specifications from [IPFIX-PROTO] apply unless specified otherwise in this document. As the Packet Sampling (PSAMP) Protocol Specifications [PSAMP- PROTO] are based on the IPFIX protocol specifications, the specifications in this document are also valid for the PSAMP protocol. Therefore, the advantages specified by this document also apply to PSAMP. 4. High Level View of the Proposal and Advantages Each Template is exported within a unique SCTP stream. The (Options) Template are still sent reliably, while the level of reliability for the Data Records would be chosen depending on the specific application. 4.1. First Advantage: Data Record Loss per Template The section 6.3.2 of the Requirements for IP Flow Information Export [RFC3917] discusses the data transfer reliability issues. "Loss of flow records during the data transfer from the exporting process to the collecting process must be indicated at the collecting process." is clearly mentioned. However, in some cases, it may be important to know how many Data Records of a certain type were lost (e.g., in the case of billing), but conventionally IPFIX cannot provide this information. Because the Data Records pertaining to different Templates may be sent on the same SCTP stream, there is no way of knowing how much data was lost for Data Records associated with a specific Template. Indeed, the Collector cannot determine which Template the lost Data Records were associated with: we can only know how much data was lost per stream. If multiple Data Records associated with different Templates are sent in one SCTP stream, it is not possible to know how much data was lost for Data Records defined by a specific Template. By using an unique SCTP stream to export all the Data Records associated with a single Template ID, the loss pertaining to a specific Template ID can be deduced from Sequence Number field in the Export header. Indeed, it increases with the number of IPFIX Data Records in the IPFIX Message. Expires May 19, 2008 [Page 6] Internet-Draft November 2007 4.2. Second Advantage: Transmission Order The first issue with the IPFIX specifications in [IPFIX-PROTO] concerns ordered transmission: a Template could be blocked pending reliable transmission, while the associated Data Records could already have been transmitted in an unreliable message on another stream. Since the Collecting Process can't decode the Data Records without the associated Template, they might be discarded. The IPFIX protocol [IPFIX-PROTO] specifies that: - "An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets." - "Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup." - "Template Sets and Options Template Sets may be sent on any SCTP stream. Template Sets and Options Template Sets MUST be sent reliably, using SCTP ordered delivery. As such, the Collecting Process MUST store the Template Record information for the duration of the SCTP association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets." A Collecting Process must have received the Template Record associated with the Data Records to be able to decode the information in the Data Records. However, because the protocol specifications are flexible in terms of stream(s) on which the Template Set, Options Template Set, and corresponding Data Sets are exported, the (Options) Template Set might be exported on a different stream than the corresponding Data Sets. In such a case, the Template may not be received before the Data Records. Even if the IPFIX protocol specifications foresees this case ("The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record."), this particular case could still occur if the Exporting Process does not make sure that this specifications holds true across all the streams of the SCTP association. For example, a Template may be blocked pending reliable transmission on a stream while the Expires May 19, 2008 [Page 7] Internet-Draft November 2007 associated Data Records may be transmitted immediately in an unreliable message on another stream. Also, due to different stream congestion, it is possible that even if the Template and Data Records are both sent reliably, Data Records sent on a different stream than the associated Template might still arrive before the associated Template. Because the Collecting Process cannot decode the Data Records without the Template, the Data Records may be discarded by the Collector, as specified in [IPFIX-PROTO]: "The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received.". In practice, Data Records without associated (Options) Template Records will most probably be discarded by the Collecting Process. 4.3. Third Advantage: Easier Job for the Collecting Process The third advantage, which is actually deduced from second one, is that the Collecting Process's job is now easier. [IPFIX- PROTO] specifies : "If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received". With the new specifications in this document, the Collecting Process doesn't have the store the Data Records while waiting for the Template Records, as the transmission order is always guaranteed. This way, extra reliability of the Data Records is achieved without extra burden on the Collecting Process. Expires May 19, 2008 [Page 8] Internet-Draft November 2007 5. Specifications 5.1. PR-SCTP This section introduces modifications compared to the "SCTP" section 10.2 (and subsections) in [IPFIX-PROTO]. More specifically the "Stream" section 10.2.4.3 PR-SCTP [RFC3758] MUST be implemented by all compliant implementations. If the Exporting Process requires a new Template to be exported but there are no more free SCTP streams available, it MAY increase the number of outbound streams it is able to send to, per [SCTP-RESET]. Alternatively (or if the Collector doesn't support the procedure for the addition of new SCTP streams), stream 0 MUST be used to export newly created Template IDs and its associated Data Records. In other words, stream 0 is the only stream that should export multiple Template Sets, and associated Data Sets. Depending on the application requirement, the Exporting Process selects the mode (unreliable, partially reliable, or fully reliable) of the SCTP messages, used to send the Data Sets. Unreliable mode MAY be used where the application does not require reliable transmission and the use of a retransmission queue is impractical. An Exporter uses multiple streams to export Data Sets. In such a case, the Observation Domain MUST use the same Observation Domain ID value on all of the streams it uses. All IPFIX Message MUST be sent in order within a stream. 5.2. Template Management This section introduces modifications compared to the Template Management section 8 in [IPFIX-PROTO]. The Template Sets SHOULD be sent on the same unique stream as their associated Data Sets. Template Sets and Options Template Sets MUST be sent reliably. In other words, any IPFIX Message containing an (Options) Template Set MUST be sent reliably. The Collecting Process MUST store the Template Record information for the duration of the SCTP association so that it can interpret the corresponding Data Records that are received Expires May 19, 2008 [Page 9] Internet-Draft November 2007 in subsequent Data Sets until the Template is deleted with a Template Withdrawal Message, or the SCTP association is shut down. The Exporting Process MUST transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s). +--------+ +---------+ +----------+ | | | | | | stream 10 ----| Data | . . . | Data |---| Template |---> | 256 | | 256 | | 256 | | PR| | PR| | FR| +--------+ +---------+ +----------+ Figure 1 Figure 1 shows an example where the stream 10 carries a Template with the Template ID 256 transmitted with full reliability (FR), together with associated Data Records transmitted with partial reliabilty (PR). Note that, because all IPFIX Message must be sent in order within a stream, the Template 256 in the figure 1 will always arrive before the Data Records. If an Options Template is necessary to understand the content of a Data Record (i.e. the scope in the Options Template Record is an Information Element contained in the Data Record), then the Options Template Record and associated Data Records SHOULD be sent in the same stream. The Data Records associated with the Options Template SHOULD be sent reliably. A typical example is the export of the redundancy draft information [IPFIX-RED-RED]. +--------+ +----------+ | | | Options | stream 20 ... -------| Data |-------| Template |------> | 257 | | 257 | | FR| | FR| +--------+ +----------+ Figure 2 Figure 2 shows an example where the stream 20 carries an Options Template with the Template ID 257 transmitted with full Expires May 19, 2008 [Page 10] Internet-Draft November 2007 reliability (FR), together with an associated Data Record transmitted with full reliabilty (FR). In this example the Option Template contains system meta information which is directly related to specific Data Records in the same stream. +--------+ +--------+ +----------+ | | | | | | stream 30 ... ---| Data |...| Data |-----| Template |--- | 259 | | 259 | | 259 | | PR| | PR| | FR| +----=---+ +--------+ +----------+ +--------+ +----------+ | | | Options | ...---| Data |-------| Template |------> | 258 | | 258 | | FR| | FR| +--------+ +----------+ Figure 3 Figure 3 shows an example where stream 30 carries an Options Template with Template ID 258 transmitted with full reliability (FR), an associated Data Record transmitted with full reliability (FR), a Template with Template ID 259 transmitted with full reliability (FR), and associated Data Records transmitted with partial reliability (PR). In this example the Option contains information required to decode the latter Data Records, such as Common Properties information [IPFIX-RED-RED]. If a Template ID is used in multiple streams, the Template Set MUST be sent a single time in one of the streams that carry the Template ID. A typical example is the export a PSAMP Report Interpretation [PSAMP-PROTO], which might be re-used across different Data Sets and hence SCTP streams. +--------+ +--------+ +----------+ | | | | | Options | stream 40 ... --| Data |...| Data |---| Template |---> | 260 | | 260 | | 260 | | FR| | FR| | FR| +--------+ +--------+ +----------+ +--------+ +--------+ | | | | Expires May 19, 2008 [Page 11] Internet-Draft November 2007 stream 42 ... --| Data |...| Data |---> | 260 | | 260 | | FR| | FR| +--------+ +--------+ +--------+ +--------+ | | | | stream 44 ... --| Data |...| Data |---> | 260 | | 260 | | FR| | FR| +--------+ +--------+ Figure 4 Figure 4 shows an Options Template Record used on multiple streams. Data records on streams 42 and 44 are sent after the Options Template has been sent on stream 40. In figure 4, the potential head of line blocking on stream 40 could imply that the Data Records in a different stream might arrive before the Options Template Record. In other words, there is no guarantee that the Data Records will always arrive after the (Options) Template Record, if the (Options) Template Record and Data Records are not sent in the same stream. This is a limitation of [IPFIX-PROTO] that is not solved in these specifications. Note: the idea of sending the (Options) Template Records on every single streams to which the Data Records corresponds to has been investigated. However, [IPFIX-PROTO] specifies that the (Options) Templates Records are scoped by Transport Session, not per stream: "Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template which has already been received but which has not previously been withdrawn (i.e. a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association". Therefore, this solution, which would have implied no backwards compatibility with the current Collecting Process implementation, has been discarded. Expires May 19, 2008 [Page 12] Internet-Draft November 2007 5.2.1. Template Withdrawal Message Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message. The Template Withdrawal Message SHOULD be sent in the last used stream that carried the Template ID to be removed. After the Template Withdrawal Message is sent, the Exporting Process SHOULD reset the SCTP stream sequence number to 0 according to [SCTP-RESET] for all the streams that carried the Template ID that was removed, if there are no other Template Record sent on that stream and if the stream is not stream 0. The Template Withdrawal Message MUST be sent reliably. The SCTP stream MUST be ordered so that the reliable IPFIX Message containing the Template Withdrawal Message would not be sent before associated Data Records. The Template ID from a withdrawn Template MAY be reused directly after the Template Withdrawal Message at the condition that the Template ID was only applicable to a single stream and that the new definition is reused in the same stream. The reuse timer allows for the Collecting Process to receive and process the Template withdrawal message, and to wait until no more Data Records of that type have been received on any SCTP stream. The default value of the reuse timer is 3 seconds. If the Template ID was applicable to multiple streams, the Exporting Process SHOULD wait for the expiration of the reuse timer (after sending the Template Withdrawal Message) before reassigning a new definition to the same Template Id. A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message header MAY be used. Refer to "All Data Templates Withdrawal Message" in [IPFIX-PROTO]. The Template Withdrawal Message to withdraw all Templates for the Observation Domain ID MUST be sent reliably. After a Template Withdrawal Message to withdraw all Templates, the Exporting Process SHOULD wait for the expiration of the reuse timer before reassigning a new definition to the same Template Id. If the Metering Process restarts, the Exporting Process MUST reuse the previously assigned Template ID for each Template and it MUST reuse the corresponding previously assigned stream for Expires May 19, 2008 [Page 13] Internet-Draft November 2007 each Template ID. Alternatively, it MUST withdraw the previously issued Template IDs by sending Template Withdrawal Message(s) before reusing them. It can then use any available stream for the Template ID. If the measurement parameters change, the Template MUST be withdrawn (using a Template Withdrawal Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new flow expiration process, a new filtering definition, etc. If a Template is changed, a Template Withdrawal Message MUST be sent to delete the Template. Redefinition of the Template ID is not encouraged. Instead, new Template ID SHOULD be used, until the exhaustion of the Template ID space. 5.3. The Collecting Process's Side This refers to the Collecting Process's Side section 9 in [IPFIX-PROTO]. The Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process will request a number of streams to use for export: the number of streams SHOULD be equivalent to the number of simultaneous Template ID used in the association. A Collecting process SHOULD support the procedure for the addition of a SCTP stream [SCTP- RESET]. If the Collecting Process receives a malformed IPFIX Message, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error. Template Sets and Options Template Sets are only sent once, even if they're used in multiple streams. The Collecting Process MUST store the Template Record information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets. If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template is used, then the Collecting Process MUST shutdown the association. Note that the "All Data Templates Withdrawal Message" may be sent on any stream. Expires May 19, 2008 [Page 14] Internet-Draft November 2007 Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template which has already been received but which has not previously been withdrawn (i.e. a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association. When an SCTP association is closed, the Collecting Process MUST discard all Templates received over that association and stop decoding IPFIX Messages that use those Templates. The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. A Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message. The IPFIX protocol has a Sequence Number field in the Export header which increases with the number of IPFIX Data Records in the IPFIX Message. A Collector may detect out of sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. As this Sequence Number is per SCTP stream, the loss per Template ID can be calculated in case of unreliable or partially-reliable export. A collector SHOULD provide a logging mechanism for tracking out of sequence IPFIX Messages. Such out of sequence IPFIX Messages may be due to Exporter resource exhaustion where it can not transmit messages at their creation rate, an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion where it can not process the IPFIX Messages at their arrival rate, out of order packet reception, duplicate packet reception, or an attacker injecting false messages. If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. 6. IANA Considerations Expires May 19, 2008 [Page 15] Internet-Draft November 2007 This document has no actions for IANA. 7. Security Considerations The same security considerations as for the IPFIX Protocol [IPFIX-PROTO] apply. 8. References 8.1. Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., Conrad, P., "Stream Control Transmission Protocol (SCTP), Partial Reliability Extension", May 2004 [IPFIX-PROTO] B. Claise et Al, IPFIX Protocol Specification, , Internet-Draft work in progress, June 2006 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection" draft-ietf-psamp-sample-tech-10.txt, Internet-Draft work in progress, June 2007 [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control Transmission Protocol (SCTP) Stream Reset", draft- stewart-sctpstrrst-05.txt, Internet-Draft work in progress, June 2007 8.2. Informative References [RFC3917] Quittek, J., Zseby, T., Claise, B. Zander, S, Requirements for IP Flow Information Export, RFC 3917, October 2004 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., "Architecture Model for IP Flow Information Export" draft-ietf-ipfix-architecture-12, Internet-Draft work in progress, September 2006 Expires May 19, 2008 [Page 16] Internet-Draft November 2007 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX Applicability", draft-ietf-ipfix-as-12.txt, Internet-Draft work in progress, February 2007 [IPFIX-INFO] J. Quittek, S. Bryant, B. Claise, J. Meyer, Information Model for IP Flow Information Export, , Internet-draft work in progress, June 2006 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, "Information Model for Packet Sampling Exports", draft- ietf-psamp-info-07.txt, Internet-Draft work in progress, October 2007 [PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", draft-ietf- psamp-protocol-08, Internet-Draft work in progress, June 2007. [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M. Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan, "A Framework for Passive Packet Measurement" draft- ietf-psamp-framework-12.txt, Internet-Draft work in progress, June 2007 [IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing Redundancy in IPFIX and PSAMP Reports", Internet-Draft work in progress, draft-ietf-ipfix-reducing-redundancy- 04.txt, May 2007 [PSAMP-MIB] Dietz, T., Claise, B. "Definitions of Managed Objects for Packet Sampling", Internet-Draft work in progress, June 2006 9. Acknowledgements The authors would like to thank Gerhard Muenz, Randall Stewart, and Peter Lei. Expires May 19, 2008 [Page 17] Internet-Draft November 2007 10. Author's Addresses Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Andrew Johnson Cisco Systems (Scotland) Ltd. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, United Kingdom Phone: +44 131 561 3641 Email: andrjohn@cisco.com Paul Aitken Cisco Systems (Scotland) Ltd. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, United Kingdom Phone: +44 131 561 3616 Email: paitken@cisco.com 11. Intellectual Property Statement 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 Expires May 19, 2008 [Page 18] Internet-Draft November 2007 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 IETF Trust (2007). 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, THE IETF TRUST 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. Expires May 19, 2008 [Page 19]