idnits 2.17.1 draft-coene-rserpool-applic-ipfix-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 270. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2006) is 6422 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 161, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 164, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 168, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 171, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 177, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 185, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 190, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 197, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (ref. '3') (Obsoleted by RFC 3979) == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-13 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-13 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-10 ** Obsolete normative reference: RFC 2960 (ref. '8') (Obsoleted by RFC 4960) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft University of Duisburg-Essen 4 Intended status: Informational L. Coene 5 Expires: March 2, 2007 Siemens 6 P. Conrad 7 University of Delaware 8 August 29, 2006 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 2, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the applicability of the Relialeble Server 45 Pooling architecture to the IP Flow Information Exchange using the 46 Aggregate Server Access Protocol (ASAP) functionality of RSerPool 47 only. Data exchange in IPFIX between the router and the data 48 collector can be provided by a limited retransmission protocol. 50 1. Introduction 52 Reliable Server Pooling provides protocols for providing highly 53 available services. The services are located in a pool of redundant 54 servers and if a server fails, another server will take over. The 55 only requirement put on these servers belonging to the pool is that 56 if state is maintained by the server, this state must be transfered 57 to the other server taking over. 59 The goal is to provide server-based redundancy. Transport and 60 network level redundancy are handle by the transport and network 61 layer protcols. 63 The application may choose to distribute its traffic over the servers 64 of the pool conforming to a certain policy. 66 The application wishing to make use of RSerPool protocols may use 67 different transport layers (such as UDP, TCP and SCTP). However, 68 some transport layers may have restrictions build in in the way they 69 might be operating in the RSerPool architecture and its protocols. 71 1.1. Scope 73 The scope of this document is to explain the way that a minimal 74 version of Reliable Server Pooling protocols have to be used in order 75 to provide a higly available service towards IP Flow Information 76 Exchange (IPFIX) protocols. 78 1.2. Terminology 80 The terms are commonly identified in related work and can be found in 81 the Aggregate Server Access Protocol and Endpoint Handlespace 82 Redundancy Protocol Common Parameters document ietf-rserpool-common- 83 param [7] 85 2. IPFIX using RSerPool 87 2.1. Architecture 89 IP flow information is exchanged between observation points and 90 collector points. The observation points may try to find out via the 91 Aggregate Server Access Protocol (ASAP, see ietf-rserpool-asap [5]) 92 which collector point(s) are active. Both the observation and the 93 collector point may have limitations for exchanging the information 94 (observation point may have limited buffer space and collectors 95 points may be overburdened with receiving lots of flow information 96 from different observation points). 98 The observation point will query the ENRP server for resolution of a 99 particular collector pool name and the ENRP server will return a list 100 of one or more collector points to the observation point. 102 The observation point will use its own transport protocols (TCP, UDP, 103 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 104 between the observation point and the collector point. If a 105 collector point would fail, then the observation point will send its 106 data towards a different collector point, belonging to the same 107 collector pool. 109 Collector points will announce themselves to the ENRP server and will 110 be monitored for their avialebility. The observation point will only 111 query the ENRP server for server pool name resolution. 113 3. Transport protocols suitable for IPFIX 115 The exchange of IP flow information data between an observation point 116 and a collection point consists of massive ammounts of data. 118 One collection point can service many observation points, therefore 119 transport protocols must do congestion control (example: modifying 120 the receive buffer space, thus reducing the incoming flow of data), 121 so that the collection point is not overburdened by its observation 122 points. Some data must arrive at the collector while other data 123 migth arrive (if it gets lost: no problem). The choice of reliable 124 or partial reliable delivery has to be made by the observation point 125 These requirements demand a protocol which provides variable 126 transport reliability of its data: it should be able to chose the 127 reliability by the IPFIX protocols on a a per-message base. 129 SCTP with PR-SCTP extension is the only know protocol which allows 130 the choice of full, partial or unrelialeble delivery of the message 131 to its peer node. TCP will only allow fully relialable delivery, 132 while UDP only provides unrelialeble delivery and NO congestion 133 control. 135 4. Security considerations 137 The protocols used in the Reliable Server Pooling architecture only 138 try to increase the availability of the servers in the network. 139 RSerPool protocols do not contain any protocol mechanisms which are 140 directly related to user message authentication, integrity and 141 confidentiality functions. For such features, it depends on the 142 IPSEC protocols or on Transport Layer Security (TLS) protocols for 143 its own security and on the architecture and/or security features of 144 its user protocols. 146 The RSerPool architecture allows the use of different transport 147 protocols for its application and control data exchange. These 148 transport protocols may have mechanisms for reducing the risk of 149 blind denial-of-service attacks and/or masquerade attacks. If such 150 measures are required by the applications, then it is advised to 151 check the SCTP applicability statement RFC2057 [10] for guidance on 152 this issue. 154 5. Acknowledgments 156 The authors wish to thank M. Stillman and many others for their 157 invaluable comments. 159 6. Normative References 161 [1] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 162 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 164 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 165 J., and M. Stillman, "Requirements for Reliable Server 166 Pooling", RFC 3237, January 2002. 168 [3] Bradner, S., "Intellectual Property Rights in IETF Technology", 169 RFC 3668, February 2004. 171 [4] Tuexen, M., "Architecture for Reliable Server Pooling", 172 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 174 [5] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 175 draft-ietf-rserpool-asap-13 (work in progress), February 2006. 177 [6] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 178 draft-ietf-rserpool-enrp-13 (work in progress), February 2006. 180 [7] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 181 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 182 draft-ietf-rserpool-common-param-10 (work in progress), 183 February 2006. 185 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 186 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 187 Paxson, "Stream Control Transmission Protocol", RFC 2960, 188 October 2000. 190 [9] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 191 "Stream Control Transmission Protocol (SCTP) Partial 192 Reliability Extension", RFC 3758, May 2004. 194 [10] Coene, L., "Stream Control Transmission Protocol Applicability 195 Statement", RFC 3257, April 2002. 197 [11] Conrad, P. and P. Lei, "Services Provided By Reliable Server 198 Pooling", draft-ietf-rserpool-service-02 (work in progress), 199 October 2005. 201 Authors' Addresses 203 Thomas Dreibholz 204 University of Duisburg-Essen, Institute for Experimental Mathematics 205 Ellernstrasse 29 206 45326 Essen, Nordrhein-Westfalen 207 Germany 209 Phone: +49-201-1837637 210 Fax: +49-201-1837673 211 Email: dreibh@exp-math.uni-essen.de 212 URI: http://www.exp-math.uni-essen.de/~dreibh/ 214 Lode Coene 215 Siemens 216 Atealaan 32 217 Herentals 2200 218 Belgium 220 Phone: +32-14-252081 221 Email: lode.coene@siemens.com 223 Phillip Conrad 224 University of Delaware 225 103 Smith Hall 226 Newark DE 19716 227 USA 229 Phone: +1 302 831 8622 230 Email: conrad@acm.org 232 Full Copyright Statement 234 Copyright (C) The Internet Society (2006). 236 This document is subject to the rights, licenses and restrictions 237 contained in BCP 78, and except as set forth therein, the authors 238 retain all their rights. 240 This document and the information contained herein are provided on an 241 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 242 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 243 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 244 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 Intellectual Property 250 The IETF takes no position regarding the validity or scope of any 251 Intellectual Property Rights or other rights that might be claimed to 252 pertain to the implementation or use of the technology described in 253 this document or the extent to which any license under such rights 254 might or might not be available; nor does it represent that it has 255 made any independent effort to identify any such rights. Information 256 on the procedures with respect to rights in RFC documents can be 257 found in BCP 78 and BCP 79. 259 Copies of IPR disclosures made to the IETF Secretariat and any 260 assurances of licenses to be made available, or the result of an 261 attempt made to obtain a general license or permission for the use of 262 such proprietary rights by implementers or users of this 263 specification can be obtained from the IETF on-line IPR repository at 264 http://www.ietf.org/ipr. 266 The IETF invites any interested party to bring to its attention any 267 copyrights, patents or patent applications, or other proprietary 268 rights that may cover technology that may be required to implement 269 this standard. Please address the information to the IETF at 270 ietf-ipr@ietf.org. 272 Acknowledgment 274 Funding for the RFC Editor function is provided by the IETF 275 Administrative Support Activity (IASA).