idnits 2.17.1 draft-coene-rserpool-applic-ipfix-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 5, 2010) is 5225 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-34) exists of draft-dreibholz-rserpool-asap-hropt-04 == Outdated reference: A later version (-31) exists of draft-dreibholz-rserpool-enrp-takeover-01 == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-delay-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 9, 2010 Nokia Siemens Networks 6 P. Conrad 7 University of Delaware 8 January 5, 2010 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-09.txt 13 Abstract 15 This document describes the applicability of the Reliable Server 16 Pooling architecture to the IP Flow Information Exchange using the 17 Aggregate Server Access Protocol (ASAP) functionality of RSerPool 18 only. Data exchange in IPFIX between the router and the data 19 collector can be provided by a limited retransmission protocol. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. IPFIX using RSerPool . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Transport protocols suitable for IPFIX . . . . . . . . . . . . 4 67 4. Security considerations . . . . . . . . . . . . . . . . . . . . 4 68 5. Reference Implementation . . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Reliable Server Pooling provides protocols for providing highly 80 available services. The services are located in a pool of redundant 81 servers and if a server fails, another server will take over. The 82 only requirement put on these servers belonging to the pool is that 83 if state is maintained by the server, this state must be transferred 84 to the other server taking over. 86 The goal is to provide server-based redundancy. Transport and 87 network level redundancy are handle by the transport and network 88 layer protcols. 90 The application may choose to distribute its traffic over the servers 91 of the pool conforming to a certain policy. 93 The application wishing to make use of RSerPool protocols may use 94 different transport layers (such as UDP, TCP and SCTP). However, 95 some transport layers may have restrictions build in in the way they 96 might be operating in the RSerPool architecture and its protocols. 98 1.1. Scope 100 The scope of this document is to explain the way that a minimal 101 version of Reliable Server Pooling protocols have to be used in order 102 to provide a highly available service towards IP Flow Information 103 Exchange (IPFIX) protocols. 105 1.2. Terminology 107 The terms are commonly identified in related work and can be found in 108 the Aggregate Server Access Protocol and Endpoint Handlespace 109 Redundancy Protocol Common Parameters document [RFC5354] 111 2. IPFIX using RSerPool 113 2.1. Architecture 115 IP flow information is exchanged between observation points and 116 collector points. The observation points may try to find out via the 117 Aggregate Server Access Protocol (ASAP, see [RFC5352]) which 118 collector point(s) are active. Both the observation and the 119 collector point may have limitations for exchanging the information 120 (observation point may have limited buffer space and collectors 121 points may be overburdened with receiving lots of flow information 122 from different observation points). 124 The observation point will query the ENRP server for resolution of a 125 particular collector pool name and the ENRP server will return a list 126 of one or more collector points to the observation point. 128 The observation point will use its own transport protocols (TCP, UDP, 129 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 130 between the observation point and the collector point. If a 131 collector point would fail, then the observation point will send its 132 data towards a different collector point, belonging to the same 133 collector pool. 135 Collector points will announce themselves to the ENRP server and will 136 be monitored for their availability. The observation point will only 137 query the ENRP server for server pool name resolution. 139 3. Transport protocols suitable for IPFIX 141 The exchange of IP flow information data between an observation point 142 and a collection point consists of massive amounts of data. 144 One collection point can service many observation points, therefore 145 transport protocols must do congestion control (example: modifying 146 the receive buffer space, thus reducing the incoming flow of data), 147 so that the collection point is not overburdened by its observation 148 points. Some data must arrive at the collector while other data 149 might arrive (if it gets lost: no problem). The choice of reliable 150 or partial reliable delivery has to be made by the observation point 151 These requirements demand a protocol which provides variable 152 transport reliability of its data: it should be able to chose the 153 reliability by the IPFIX protocols on a a per-message base. 155 SCTP [RFC4960] with PR-SCTP extension [RFC3758] is the only know 156 protocol which allows the choice of full, partial or unreliable 157 delivery of the message to its peer node. TCP will only allow fully 158 reliable delivery, while UDP only provides unreliable delivery and NO 159 congestion control. 161 4. Security considerations 163 The protocols used in the Reliable Server Pooling architecture only 164 try to increase the availability of the servers in the network. 165 RSerPool protocols do not contain any protocol mechanisms which are 166 directly related to user message authentication, integrity and 167 confidentiality functions. For such features, it depends on the 168 IPSEC protocols or on Transport Layer Security (TLS) protocols for 169 its own security and on the architecture and/or security features of 170 its user protocols. 172 The RSerPool architecture allows the use of different transport 173 protocols for its application and control data exchange. These 174 transport protocols may have mechanisms for reducing the risk of 175 blind denial-of-service attacks and/or masquerade attacks. If such 176 measures are required by the applications, then it is advised to 177 check the SCTP applicability statement RFC2057 [RFC3257] for guidance 178 on this issue. 180 5. Reference Implementation 182 The RSerPool reference implementation RSPLIB can be found at 183 [RSerPoolPage]. It supports the functionalities defined by 184 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 185 the options [I-D.dreibholz-rserpool-asap-hropt], 186 [I-D.dreibholz-rserpool-enrp-takeover] and 187 [I-D.dreibholz-rserpool-delay]. An introduction to this 188 implementation is provided in [Dre2006]. 190 6. Security Considerations 192 Security considerations for RSerPool systems are described by 193 [RFC5355]. 195 7. IANA Considerations 197 This document introduces no additional considerations for IANA. 199 8. Acknowledgments 201 The authors wish to thank Maureen Stillman and many others for their 202 invaluable comments. 204 9. References 206 9.1. Normative References 208 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 209 Overview of Reliable Server Pooling Protocols", RFC 5351, 210 September 2008. 212 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 213 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 214 September 2008. 216 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 217 Silverton, "Endpoint Handlespace Redundancy Protocol 218 (ENRP)", RFC 5353, September 2008. 220 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 221 "Aggregate Server Access Protocol (ASAP) and Endpoint 222 Handlespace Redundancy Protocol (ENRP) Parameters", 223 RFC 5354, September 2008. 225 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 226 Holdrege, "Threats Introduced by Reliable Server Pooling 227 (RSerPool) and Requirements for Security in Response to 228 Threats", RFC 5355, September 2008. 230 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 231 Policies", RFC 5356, September 2008. 233 [RFC3257] Coene, L., "Stream Control Transmission Protocol 234 Applicability Statement", RFC 3257, April 2002. 236 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 237 Conrad, "Stream Control Transmission Protocol (SCTP) 238 Partial Reliability Extension", RFC 3758, May 2004. 240 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 241 RFC 4960, September 2007. 243 9.2. Informative References 245 [RSerPoolPage] 246 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 247 URL: http://tdrwww.iem.uni-due.de.de/dreibholz/rserpool/. 249 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 250 Optimization and Extension of a Novel IETF Architecture", 251 Ph.D. Thesis University of Duisburg-Essen, Faculty of 252 Economics, Institute for Computer Science and Business 253 Information Systems, URL: http:// 254 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 255 Derivate-16326/Dre2006-final.pdf, March 2007. 257 [I-D.dreibholz-rserpool-asap-hropt] 258 Dreibholz, T., "Handle Resolution Option for ASAP", 259 draft-dreibholz-rserpool-asap-hropt-04 (work in progress), 260 January 2009. 262 [I-D.dreibholz-rserpool-enrp-takeover] 263 Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 264 the ENRP Handle Update Message", 265 draft-dreibholz-rserpool-enrp-takeover-01 (work in 266 progress), January 2009. 268 [I-D.dreibholz-rserpool-delay] 269 Dreibholz, T. and X. Zhou, "Definition of a Delay 270 Measurement Infrastructure and Delay-Sensitive Least-Used 271 Policy for Reliable Server Pooling", 272 draft-dreibholz-rserpool-delay-03 (work in progress), 273 January 2009. 275 Authors' Addresses 277 Thomas Dreibholz 278 University of Duisburg-Essen, Institute for Experimental Mathematics 279 Ellernstrasse 29 280 45326 Essen, Nordrhein-Westfalen 281 Germany 283 Phone: +49-201-1837637 284 Fax: +49-201-1837673 285 Email: dreibh@iem.uni-due.de 286 URI: http://www.iem.uni-due.de/~dreibh/ 288 Lode Coene 289 Nokia Siemens Networks 290 Atealaan 32 291 Herentals 2200 292 Belgium 294 Phone: +32-14-252081 295 Email: lode.coene@nsn.com 297 Phillip Conrad 298 University of Delaware 299 103 Smith Hall 300 Newark DE 19716 301 USA 303 Phone: +1 302 831 8622 304 Email: conrad@acm.org