idnits 2.17.1 draft-coene-rserpool-applic-ipfix-06.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, updated by RFC 4748 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 288. 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 IETF Trust 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 (July 11, 2008) is 5767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3237' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 162, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-arch' is defined on line 165, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-enrp' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC3758' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-service' is defined on line 200, but no explicit reference was found in the text == Unused Reference: 'RSerPoolPage' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'Dre2006' is defined on line 211, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-20 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-20 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-17 ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 4 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: January 12, 2009 Nokia Siemens Networks 6 P. Conrad 7 University of Delaware 8 July 11, 2008 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-06.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 January 12, 2009. 38 Abstract 40 This document describes the applicability of the Reliable Server 41 Pooling architecture to the IP Flow Information Exchange using the 42 Aggregate Server Access Protocol (ASAP) functionality of RSerPool 43 only. Data exchange in IPFIX between the router and the data 44 collector can be provided by a limited retransmission protocol. 46 1. Introduction 48 Reliable Server Pooling provides protocols for providing highly 49 available services. The services are located in a pool of redundant 50 servers and if a server fails, another server will take over. The 51 only requirement put on these servers belonging to the pool is that 52 if state is maintained by the server, this state must be transferred 53 to the other server taking over. 55 The goal is to provide server-based redundancy. Transport and 56 network level redundancy are handle by the transport and network 57 layer protcols. 59 The application may choose to distribute its traffic over the servers 60 of the pool conforming to a certain policy. 62 The application wishing to make use of RSerPool protocols may use 63 different transport layers (such as UDP, TCP and SCTP). However, 64 some transport layers may have restrictions build in in the way they 65 might be operating in the RSerPool architecture and its protocols. 67 1.1. Scope 69 The scope of this document is to explain the way that a minimal 70 version of Reliable Server Pooling protocols have to be used in order 71 to provide a highly available service towards IP Flow Information 72 Exchange (IPFIX) protocols. 74 1.2. Terminology 76 The terms are commonly identified in related work and can be found in 77 the Aggregate Server Access Protocol and Endpoint Handlespace 78 Redundancy Protocol Common Parameters document ietf-rserpool-common- 79 param [I-D.ietf-rserpool-common-param] 81 2. IPFIX using RSerPool 83 2.1. Architecture 85 IP flow information is exchanged between observation points and 86 collector points. The observation points may try to find out via the 87 Aggregate Server Access Protocol (ASAP, see ietf-rserpool-asap 88 [I-D.ietf-rserpool-asap]) which collector point(s) are active. Both 89 the observation and the collector point may have limitations for 90 exchanging the information (observation point may have limited buffer 91 space and collectors points may be overburdened with receiving lots 92 of flow information from different observation points). 94 The observation point will query the ENRP server for resolution of a 95 particular collector pool name and the ENRP server will return a list 96 of one or more collector points to the observation point. 98 The observation point will use its own transport protocols (TCP, UDP, 99 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 100 between the observation point and the collector point. If a 101 collector point would fail, then the observation point will send its 102 data towards a different collector point, belonging to the same 103 collector pool. 105 Collector points will announce themselves to the ENRP server and will 106 be monitored for their availability. The observation point will only 107 query the ENRP server for server pool name resolution. 109 3. Transport protocols suitable for IPFIX 111 The exchange of IP flow information data between an observation point 112 and a collection point consists of massive amounts of data. 114 One collection point can service many observation points, therefore 115 transport protocols must do congestion control (example: modifying 116 the receive buffer space, thus reducing the incoming flow of data), 117 so that the collection point is not overburdened by its observation 118 points. Some data must arrive at the collector while other data 119 might arrive (if it gets lost: no problem). The choice of reliable 120 or partial reliable delivery has to be made by the observation point 121 These requirements demand a protocol which provides variable 122 transport reliability of its data: it should be able to chose the 123 reliability by the IPFIX protocols on a a per-message base. 125 SCTP with PR-SCTP extension is the only know protocol which allows 126 the choice of full, partial or unreliable delivery of the message to 127 its peer node. TCP will only allow fully reliable delivery, while 128 UDP only provides unreliable delivery and NO congestion control. 130 4. Security considerations 132 The protocols used in the Reliable Server Pooling architecture only 133 try to increase the availability of the servers in the network. 134 RSerPool protocols do not contain any protocol mechanisms which are 135 directly related to user message authentication, integrity and 136 confidentiality functions. For such features, it depends on the 137 IPSEC protocols or on Transport Layer Security (TLS) protocols for 138 its own security and on the architecture and/or security features of 139 its user protocols. 141 The RSerPool architecture allows the use of different transport 142 protocols for its application and control data exchange. These 143 transport protocols may have mechanisms for reducing the risk of 144 blind denial-of-service attacks and/or masquerade attacks. If such 145 measures are required by the applications, then it is advised to 146 check the SCTP applicability statement RFC2057 [RFC3257] for guidance 147 on this issue. 149 5. Acknowledgments 151 The authors wish to thank Maureen Stillman and many others for their 152 invaluable comments. 154 6. References 156 6.1. Normative References 158 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 159 Loughney, J., and M. Stillman, "Requirements for Reliable 160 Server Pooling", RFC 3237, January 2002. 162 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 163 Technology", RFC 3668, February 2004. 165 [I-D.ietf-rserpool-arch] 166 Tuexen, M., "Architecture for Reliable Server Pooling", 167 draft-ietf-rserpool-arch-12 (work in progress), 168 November 2006. 170 [I-D.ietf-rserpool-asap] 171 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 172 "Aggregate Server Access Protocol (ASAP)", 173 draft-ietf-rserpool-asap-20 (work in progress), May 2008. 175 [I-D.ietf-rserpool-enrp] 176 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 177 Silverton, "Endpoint Handlespace Redundancy Protocol 178 (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), 179 May 2008. 181 [I-D.ietf-rserpool-common-param] 182 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 183 "Aggregate Server Access Protocol (ASAP) and Endpoint 184 Handlespace Redundancy Protocol (ENRP) Parameters", 185 draft-ietf-rserpool-common-param-17 (work in progress), 186 May 2008. 188 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 189 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 190 Zhang, L., and V. Paxson, "Stream Control Transmission 191 Protocol", RFC 2960, October 2000. 193 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 194 Conrad, "Stream Control Transmission Protocol (SCTP) 195 Partial Reliability Extension", RFC 3758, May 2004. 197 [RFC3257] Coene, L., "Stream Control Transmission Protocol 198 Applicability Statement", RFC 3257, April 2002. 200 [I-D.ietf-rserpool-service] 201 Conrad, P. and P. Lei, "Services Provided By Reliable 202 Server Pooling", draft-ietf-rserpool-service-02 (work in 203 progress), October 2005. 205 6.2. Informative References 207 [RSerPoolPage] 208 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", URL: 209 http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 211 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 212 Optimization and Extension of a Novel IETF Architecture", 213 Ph.D. Thesis University of Duisburg-Essen, Faculty of 214 Economics, Institute for Computer Science and Business 215 Information Systems, URL: http:// 216 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 217 Derivate-16326/Dre2006-final.pdf, March 2007. 219 Authors' Addresses 221 Thomas Dreibholz 222 University of Duisburg-Essen, Institute for Experimental Mathematics 223 Ellernstrasse 29 224 45326 Essen, Nordrhein-Westfalen 225 Germany 227 Phone: +49-201-1837637 228 Fax: +49-201-1837673 229 Email: dreibh@iem.uni-due.de 230 URI: http://www.iem.uni-due.de/~dreibh/ 232 Lode Coene 233 Nokia Siemens Networks 234 Atealaan 32 235 Herentals 2200 236 Belgium 238 Phone: +32-14-252081 239 Email: lode.coene@nsn.com 241 Phillip Conrad 242 University of Delaware 243 103 Smith Hall 244 Newark DE 19716 245 USA 247 Phone: +1 302 831 8622 248 Email: conrad@acm.org 250 Full Copyright Statement 252 Copyright (C) The IETF Trust (2008). 254 This document is subject to the rights, licenses and restrictions 255 contained in BCP 78, and except as set forth therein, the authors 256 retain all their rights. 258 This document and the information contained herein are provided on an 259 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 260 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 261 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 262 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 263 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 264 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 266 Intellectual Property 268 The IETF takes no position regarding the validity or scope of any 269 Intellectual Property Rights or other rights that might be claimed to 270 pertain to the implementation or use of the technology described in 271 this document or the extent to which any license under such rights 272 might or might not be available; nor does it represent that it has 273 made any independent effort to identify any such rights. Information 274 on the procedures with respect to rights in RFC documents can be 275 found in BCP 78 and BCP 79. 277 Copies of IPR disclosures made to the IETF Secretariat and any 278 assurances of licenses to be made available, or the result of an 279 attempt made to obtain a general license or permission for the use of 280 such proprietary rights by implementers or users of this 281 specification can be obtained from the IETF on-line IPR repository at 282 http://www.ietf.org/ipr. 284 The IETF invites any interested party to bring to its attention any 285 copyrights, patents or patent applications, or other proprietary 286 rights that may cover technology that may be required to implement 287 this standard. Please address the information to the IETF at 288 ietf-ipr@ietf.org.