IPFIX Working Group B. Claise Internet-Draft A. Johnson Intended Status: Standards Track P. Aitken Expires: October 30th, 2007 Cisco Systems, Inc. April 30th 2007 IPFIX Export per SCTP Stream draft-claise-ipfix-export-per-sctp-stream-00 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 October 30, 2007 [Page 1] Internet-Draft April 2007 Abstract This document specifies an improvement to the use of SCTP as specified in IPFIX: exporting each template record and the associated data records within a unique SCTP stream. This specification offers several advantages: the transmission order is maintained, the data loss for each template record can be deduced, 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. Introduction................................................3 2.1. IPFIX Documents Overview...............................4 2.2. PSAMP Documents Overview...............................5 3. Terminology.................................................5 3.1. Terminology Summary Table..............................8 4. High Level View of the Proposal and Advantages..............8 4.1. Advantage 1: Transmission Order........................8 4.2. Advantage 2: Data Record Loss per Template.............9 4.3. Advantage 3: Easier Job for the Collecting Process.....9 5. Specifications..............................................9 5.1. Template Management....................................9 5.2. The Collecting Process's Side.........................13 5.3. PR-SCTP...............................................14 6. IANA Considerations........................................15 7. Security Considerations....................................15 8. References.................................................15 8.1. Normative References..................................15 8.2. Informative References................................16 9. Acknowledgements...........................................17 10. Author's Addresses........................................17 11. Intellectual Property Statement...........................17 12. Copyright Statement.......................................18 13. Disclaimer................................................18 Expires October 30, 2007 [Page 2] Internet-Draft April 2007 1. Open Issues and Action Items for the next draft version . Insert the functionality to add streams in SCTP, when available in the SCTP reset draft. . Verify if the terminology section is complete, and copied over from [IPFIX-PROTO] when published - In the section "High Level View of the Proposal and Advantages", rather than giving the advantages of our proposal perhaps we should highlight the shortcomings of the IPFIX method and then give a proposal that solves these issues. - What if the option is used in multiple streams? It could be sent multiple times, supposing each stream to operate independently. - 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. 2. 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 Information Element is specified in the IPFIX Information Model [IPFIX-INFO], registered with IANA, or specified as enterprise-specific. 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 a 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] specifies that all Template Records SHOULD be sent on a Stream Control Transmission Protocol (SCTP) association on stream 0 and that the templates MUST be Expires October 30, 2007 [Page 3] Internet-Draft April 2007 sent reliably. The Data Records are sent on a different SCTP stream, for which the reliably level can be chosen. 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 Template is on a different stream from the corresponding Data Records, the Template may not be received before the Data Records. For example, a Template may be blocked pending reliable transmission on stream 0 while the associated Data Records may be transmitted immediately in an unreliable message on another stream. Because the Collecting Process cannot decode the Data Records without the Template, the Data Records may be discarded by the Collector. Also, due to different stream congestion, it is possible that even if the Template and Data Records are both sent reliably, the Data Records sent on another stream still might arrive before the associated Template. Again, the Collecting Process cannot decode the Data Records without the Template and the Data Records may be discarded. Also, because 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 because the collector cannot determine which Template the lost Data Records were associated with. In some cases, it may be important to know how many Data Records were lost (e.g., in the case of billing), but conventionally IPFIX cannot provide this information. 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. As the Packet Sampling (PSAMP) Protocol Specifications [PSAMP- PROTO] are based on the IPFIX protocol specifications, the explanations in this introduction as also valid for the PSAMP protocol. Therefore, the advantages specified by this document also apply to PSAMP. 2.1. IPFIX Documents Overview The IPFIX Protocol [IPFIX-PROTO] provides network administrators with access to IP flow information. Expires October 30, 2007 [Page 4] Internet-Draft April 2007 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 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. Terminology The terms in this section are in line with the IPFIX terminology section [IPFIX-PROTO]. Expires October 30, 2007 [Page 5] Internet-Draft April 2007 Template Template is an ordered sequence of pairs, used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID. Template Record A Template Record defines the structure and interpretation of fields in a Data Record. Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record. Options Template Record An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record. IPFIX Message An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer. Message Header The Message Header is the first part of an IPFIX Message, which provides basic information about the message such as the IPFIX version, length of the message, message sequence number, etc. Set Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header. Expires October 30, 2007 [Page 6] Internet-Draft April 2007 There are three different types of Sets: Template Set, Options Template Set, and Data Set. Template Set A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message. Options Template Set An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message. Data Set A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record. Information Element An Information Element is a protocol and encoding independent description of an attribute which may appear in an IPFIX Record. The IPFIX information model [IPFIX-INFO] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX. Expires October 30, 2007 [Page 7] Internet-Draft April 2007 3.1. Terminology Summary Table +------------------+---------------------------------------------+ | | contents | | +--------------------+------------------------+ | Set | Template | record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Figure A: Terminology Summary Table A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record. A Template Set contains only Template Record(s). An Options Template Set contains only Options Template Record(s). 4. High Level View of the Proposal and Advantages Each (Options) Template and its associated Data Records would be sent on a unique SCTP stream. The (Options) Template would still be sent reliably, while the level of reliability for the Data Records would be chosen depending on the specific application. 4.1. Advantage 1: Transmission Order The first issue with the IPFIX specifications in [IPFIX-PROTO] concerns ordered transmission: a Template could be blocked pending reliable transmission on stream zero, 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 will most probably be discarded. Expires October 30, 2007 [Page 8] Internet-Draft April 2007 Even if the Data Records are sent reliably, the IPFIX protocol imposes that the Data Sets MUST NOT be sent on stream zero. As a consequence, due to different congestion in different streams, the Data Records might arrive before the associated (Options) Template Record. Again, since the Collecting Process can't decode these Data Records without the associated (Options) Template, they will most probably be discarded. 4.2. Advantage 2: Data Record Loss per Template The second issue with the IPFIX specifications in [IPFIX-PROTO] is that, as 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, there's no way of knowing how much data was lost for Data Records defined by a specific Template. It's especially important to know how many Data Records are lost in case of billing. 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 the SCTP stream loss information. 4.3. Advantage 3: Easier Job for the Collecting Process The third advantage 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 guaranteed. 5. Specifications This document is based on the specifications in [IPFIX-PROTO]. However, it only applies to the PR-SCTP transport protocol. All specifications from [IPFIX-PROTO] applies unless specified otherwise in this document. 5.1. Template Management Expires October 30, 2007 [Page 9] Internet-Draft April 2007 This refers to the Template Management section 8 in [IPFIX- PROTO]. While [IPFIX-PROTO] imposes that Template Sets and Options Template Sets SHOULD be sent on the SCTP stream zero, this document specifies that the Template Sets and Options 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 a (Options) Template Set MUST be sent reliably. As such, 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 until the Template is deleted with a Template Withdrawal Message. 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 MAY 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], or the export of the sampling rate. The Exporting Process MUST transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID. The Exporting Process MAY 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 The figure 1 display an example where the stream 10 carries a Template with the Template ID 256 transmitted with full reliability (FR), together with associated Data Records Expires October 30, 2007 [Page 10] Internet-Draft April 2007 transmitted with partial reliabilty (PR). +----------+ +----------+ | | | Options | stream 20 ... -------| Data |-------| Template |------> | 257 | | 257 | | PR| | FR| +----------+ +----------+ Figure 2 The figure 2 display an example where the stream 20 carries an Options Template with the Template ID 257 transmitted with full reliability (FR), together with an associated Data Record transmitted with partial reliabilty (PR). In this example the Option Template contains system meta information which is not directly related to specific Data Records. +--------+ +----------+ +----------+ | | | | | | stream 30 ... ---| Data |...| Data |-----| Template |--- | 259 | | 259 | | 259 | | PR| | PR| | FR| +--------+ +----------+ +----------+ +----------+ +----------+ | | | Options | ---| Data |-------| Template |------> | 258 | | 258 | | FR| | FR| +----------+ +----------+ Figure 3 The figure 3 display an example where tream 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. In this example the Option contains information required to decode the latter Data Records, such as Common Properties information [IPFIX-RED- RED]. The 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 Expires October 30, 2007 [Page 11] Internet-Draft April 2007 through the use of a Template Withdrawal Message. The Template Withdrawal Message MUST be sent in the stream that carries 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] if there are no other Template Record sent on that stream and if the stream is not the stream zero. 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 same stream is reused. If a different stream is reused, the Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdrawal message. 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 on the stream 0. After a Template Withdrawal Message to withdraw all Templates, Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdrawal message. 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. 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 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. Expires October 30, 2007 [Page 12] Internet-Draft April 2007 5.2. 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 MUST support at least 2 inbound streams per association. 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. 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 sent, then the Collecting Process MUST shutdown the association. The only exception is the "All Data Templates Withdrawal Message" sent reliably on the stream zero. 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. If the Template Records have not been received at the time Data Records are received, the Collecting Process MUST shutdown the SCTP assocation. A Collecting Process MUST NOT assume that the Data Expires October 30, 2007 [Page 13] Internet-Draft April 2007 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 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. 5.3. PR-SCTP This refers 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. An Exporting Process MUST request at least two outbound streams per association. The Exporting Process SHOULD request as many SCTP streams as the number of foreseen concurrent Templates. The first stream (referred to as stream zero in the rest of this document), is used to send the Template Withdrawal Message to remove all the Templates. Data Sets MUST NOT be sent on stream zero. The stream 1 MUST be the last stream used. Even if the stream 1 already exports Template Set, Options Template Set, and/or Data Set, the stream 1 MUST be used to export newly created Template ID and its associated Data Records in case there is no new unique stream in SCTP to use. Expires October 30, 2007 [Page 14] Internet-Draft April 2007 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. 6. IANA Considerations 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-07.txt, Internet-Draft work in progress, Juillet 2005 Expires October 30, 2007 [Page 15] Internet-Draft April 2007 [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control Transmission Protocol (SCTP) Stream Reset", draft- stewart-sctpstrrst-04.txt, Internet-Draft work in progress, January 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 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX Applicability", draft-ietf-ipfix-as-11.txt, Internet-Draft work in progress, May 2005 [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-05.txt, Internet-Draft work in progress, [PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", draft-ietf- psamp-protocol-07, Internet-Draft work in progress, October 2006. [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-10.txt, Internet-Draft work in progress, January 2005 [IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing Redundancy in IPFIX and PSAMP Reports", Internet-Draft work in progress, February, 2007 Expires October 30, 2007 [Page 16] Internet-Draft April 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. 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 Expires October 30, 2007 [Page 17] Internet-Draft April 2007 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 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 October 30, 2007 [Page 18]