idnits 2.17.1 draft-coene-rserpool-applic-ipfix-05.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 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. 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 (January 10, 2008) is 5948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 162, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 166, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 169, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 176, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 186, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 191, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 198, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 204, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 207, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-18 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-18 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-15 ** Obsolete normative reference: RFC 2960 (ref. '7') (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: July 13, 2008 Nokia Siemens Networks 6 P. Conrad 7 University of Delaware 8 January 10, 2008 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-05.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 July 13, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes the applicability of the Reliable 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 transferred 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 highly 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 [6] 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 [4]) 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 availability. 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 amounts 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 might 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 unreliable delivery of the message to 131 its peer node. TCP will only allow fully reliable delivery, while 132 UDP only provides unreliable delivery and NO congestion control. 134 4. Security considerations 136 The protocols used in the Reliable Server Pooling architecture only 137 try to increase the availability of the servers in the network. 138 RSerPool protocols do not contain any protocol mechanisms which are 139 directly related to user message authentication, integrity and 140 confidentiality functions. For such features, it depends on the 141 IPSEC protocols or on Transport Layer Security (TLS) protocols for 142 its own security and on the architecture and/or security features of 143 its user protocols. 145 The RSerPool architecture allows the use of different transport 146 protocols for its application and control data exchange. These 147 transport protocols may have mechanisms for reducing the risk of 148 blind denial-of-service attacks and/or masquerade attacks. If such 149 measures are required by the applications, then it is advised to 150 check the SCTP applicability statement RFC2057 [9] for guidance on 151 this issue. 153 5. Acknowledgments 155 The authors wish to thank Maureen Stillman and many others for their 156 invaluable comments. 158 6. References 160 6.1. Normative References 162 [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 163 J., and M. Stillman, "Requirements for Reliable Server 164 Pooling", RFC 3237, January 2002. 166 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 167 RFC 3668, February 2004. 169 [3] Tuexen, M., "Architecture for Reliable Server Pooling", 170 draft-ietf-rserpool-arch-12 (work in progress), November 2006. 172 [4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 173 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18 174 (work in progress), November 2007. 176 [5] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 177 Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", 178 draft-ietf-rserpool-enrp-18 (work in progress), November 2007. 180 [6] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 181 Server Access Protocol (ASAP) and Endpoint Handlespace 182 Redundancy Protocol (ENRP) Parameters", 183 draft-ietf-rserpool-common-param-15 (work in progress), 184 December 2007. 186 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 187 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 188 Paxson, "Stream Control Transmission Protocol", RFC 2960, 189 October 2000. 191 [8] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 192 "Stream Control Transmission Protocol (SCTP) Partial 193 Reliability Extension", RFC 3758, May 2004. 195 [9] Coene, L., "Stream Control Transmission Protocol Applicability 196 Statement", RFC 3257, April 2002. 198 [10] Conrad, P. and P. Lei, "Services Provided By Reliable Server 199 Pooling", draft-ietf-rserpool-service-02 (work in progress), 200 October 2005. 202 6.2. Informative References 204 [11] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 205 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 207 [12] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 208 Optimization and Extension of a Novel IETF Architecture", Ph.D. 209 Thesis University of Duisburg-Essen, Faculty of Economics, 210 Institute for Computer Science and Business Information 211 Systems, URL: http://duepublico.uni-duisburg-essen.de/servlets/ 212 DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. 214 Authors' Addresses 216 Thomas Dreibholz 217 University of Duisburg-Essen, Institute for Experimental Mathematics 218 Ellernstrasse 29 219 45326 Essen, Nordrhein-Westfalen 220 Germany 222 Phone: +49-201-1837637 223 Fax: +49-201-1837673 224 Email: dreibh@exp-math.uni-essen.de 225 URI: http://www.exp-math.uni-essen.de/~dreibh/ 227 Lode Coene 228 Nokia Siemens Networks 229 Atealaan 32 230 Herentals 2200 231 Belgium 233 Phone: +32-14-252081 234 Email: lode.coene@nsn.com 236 Phillip Conrad 237 University of Delaware 238 103 Smith Hall 239 Newark DE 19716 240 USA 242 Phone: +1 302 831 8622 243 Email: conrad@acm.org 245 Full Copyright Statement 247 Copyright (C) The IETF Trust (2008). 249 This document is subject to the rights, licenses and restrictions 250 contained in BCP 78, and except as set forth therein, the authors 251 retain all their rights. 253 This document and the information contained herein are provided on an 254 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 255 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 256 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 257 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 258 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 259 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 261 Intellectual Property 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use of 275 such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository at 277 http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at 283 ietf-ipr@ietf.org. 285 Acknowledgment 287 Funding for the RFC Editor function is provided by the IETF 288 Administrative Support Activity (IASA).