idnits 2.17.1 draft-coene-rserpool-applic-ipfix-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2012) is 4310 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-10 == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-delay-09 == Outdated reference: A later version (-31) exists of draft-dreibholz-rserpool-enrp-takeover-07 Summary: 1 error (**), 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 Simula Research Laboratory 4 Intended status: Informational L. Coene 5 Expires: January 3, 2013 Nokia Siemens Networks 6 P. Conrad 7 University of Delaware 8 July 2, 2012 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-14.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 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 3, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. IPFIX using RSerPool . . . . . . . . . . . . . . . . . . . . . 3 71 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Transport protocols suitable for IPFIX . . . . . . . . . . . . 4 73 4. Security considerations . . . . . . . . . . . . . . . . . . . . 4 74 5. Reference Implementation . . . . . . . . . . . . . . . . . . . 5 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 Reliable Server Pooling provides protocols for providing highly 86 available services. The services are located in a pool of redundant 87 servers and if a server fails, another server will take over. The 88 only requirement put on these servers belonging to the pool is that 89 if state is maintained by the server, this state must be transferred 90 to the other server taking over. 92 The goal is to provide server-based redundancy. Transport and 93 network level redundancy are handle by the transport and network 94 layer protcols. 96 The application may choose to distribute its traffic over the servers 97 of the pool conforming to a certain policy. 99 The application wishing to make use of RSerPool protocols may use 100 different transport layers (such as UDP, TCP and SCTP). However, 101 some transport layers may have restrictions build in in the way they 102 might be operating in the RSerPool architecture and its protocols. 104 1.1. Scope 106 The scope of this document is to explain the way that a minimal 107 version of Reliable Server Pooling protocols have to be used in order 108 to provide a highly available service towards IP Flow Information 109 Exchange (IPFIX) protocols. 111 1.2. Terminology 113 The terms are commonly identified in related work and can be found in 114 the Aggregate Server Access Protocol and Endpoint Handlespace 115 Redundancy Protocol Common Parameters document [RFC5354] 117 2. IPFIX using RSerPool 119 2.1. Architecture 121 IP flow information is exchanged between observation points and 122 collector points. The observation points may try to find out via the 123 Aggregate Server Access Protocol (ASAP, see [RFC5352]) which 124 collector point(s) are active. Both the observation and the 125 collector point may have limitations for exchanging the information 126 (observation point may have limited buffer space and collectors 127 points may be overburdened with receiving lots of flow information 128 from different observation points). 130 The observation point will query the ENRP server for resolution of a 131 particular collector pool name and the ENRP server will return a list 132 of one or more collector points to the observation point. 134 The observation point will use its own transport protocols (TCP, UDP, 135 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 136 between the observation point and the collector point. If a 137 collector point would fail, then the observation point will send its 138 data towards a different collector point, belonging to the same 139 collector pool. 141 Collector points will announce themselves to the ENRP server and will 142 be monitored for their availability. The observation point will only 143 query the ENRP server for server pool name resolution. 145 3. Transport protocols suitable for IPFIX 147 The exchange of IP flow information data between an observation point 148 and a collection point consists of massive amounts of data. 150 One collection point can service many observation points, therefore 151 transport protocols must do congestion control (example: modifying 152 the receive buffer space, thus reducing the incoming flow of data), 153 so that the collection point is not overburdened by its observation 154 points. Some data must arrive at the collector while other data 155 might arrive (if it gets lost: no problem). The choice of reliable 156 or partial reliable delivery has to be made by the observation point 157 These requirements demand a protocol which provides variable 158 transport reliability of its data: it should be able to chose the 159 reliability by the IPFIX protocols on a a per-message base. 161 SCTP [RFC4960] with PR-SCTP extension [RFC3758] is the only know 162 protocol which allows the choice of full, partial or unreliable 163 delivery of the message to its peer node. TCP will only allow fully 164 reliable delivery, while UDP only provides unreliable delivery and NO 165 congestion control. 167 4. Security considerations 169 The protocols used in the Reliable Server Pooling architecture only 170 try to increase the availability of the servers in the network. 171 RSerPool protocols do not contain any protocol mechanisms which are 172 directly related to user message authentication, integrity and 173 confidentiality functions. For such features, it depends on the 174 IPSEC protocols or on Transport Layer Security (TLS) protocols for 175 its own security and on the architecture and/or security features of 176 its user protocols. 178 The RSerPool architecture allows the use of different transport 179 protocols for its application and control data exchange. These 180 transport protocols may have mechanisms for reducing the risk of 181 blind denial-of-service attacks and/or masquerade attacks. If such 182 measures are required by the applications, then it is advised to 183 check the SCTP applicability statement RFC2057 [RFC3257] for guidance 184 on this issue. 186 5. Reference Implementation 188 The RSerPool reference implementation RSPLIB can be found at 189 [RSerPoolPage]. It supports the functionalities defined by 190 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 191 the options [I-D.dreibholz-rserpool-asap-hropt], 192 [I-D.dreibholz-rserpool-enrp-takeover] and 193 [I-D.dreibholz-rserpool-delay]. An introduction to this 194 implementation is provided in [Dre2006]. 196 6. Security Considerations 198 Security considerations for RSerPool systems are described by 199 [RFC5355]. 201 7. IANA Considerations 203 This document introduces no additional considerations for IANA. 205 8. Acknowledgments 207 The authors wish to thank Maureen Stillman and many others for their 208 invaluable comments. 210 9. References 212 9.1. Normative References 214 [RFC3257] Coene, L., "Stream Control Transmission Protocol 215 Applicability Statement", RFC 3257, April 2002. 217 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 218 Conrad, "Stream Control Transmission Protocol (SCTP) 219 Partial Reliability Extension", RFC 3758, May 2004. 221 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 222 RFC 4960, September 2007. 224 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 225 Overview of Reliable Server Pooling Protocols", RFC 5351, 226 September 2008. 228 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 229 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 230 September 2008. 232 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 233 Silverton, "Endpoint Handlespace Redundancy Protocol 234 (ENRP)", RFC 5353, September 2008. 236 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 237 "Aggregate Server Access Protocol (ASAP) and Endpoint 238 Handlespace Redundancy Protocol (ENRP) Parameters", 239 RFC 5354, September 2008. 241 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 242 Holdrege, "Threats Introduced by Reliable Server Pooling 243 (RSerPool) and Requirements for Security in Response to 244 Threats", RFC 5355, September 2008. 246 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 247 Policies", RFC 5356, September 2008. 249 [I-D.dreibholz-rserpool-asap-hropt] 250 Dreibholz, T., "Handle Resolution Option for ASAP", 251 draft-dreibholz-rserpool-asap-hropt-10 (work in progress), 252 December 2011. 254 [I-D.dreibholz-rserpool-delay] 255 Dreibholz, T. and X. Zhou, "Definition of a Delay 256 Measurement Infrastructure and Delay-Sensitive Least-Used 257 Policy for Reliable Server Pooling", 258 draft-dreibholz-rserpool-delay-09 (work in progress), 259 December 2011. 261 [I-D.dreibholz-rserpool-enrp-takeover] 262 Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 263 the ENRP Handle Update Message", 264 draft-dreibholz-rserpool-enrp-takeover-07 (work in 265 progress), December 2011. 267 9.2. Informative References 269 [Dre2006] Dreibholz, T., "Reliable Server Pooling - Evaluation, 270 Optimization and Extension of a Novel IETF Architecture", 271 March 2007. 273 [RSerPoolPage] 274 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 2012. 276 Authors' Addresses 278 Thomas Dreibholz 279 Simula Research Laboratory, Network Systems Group 280 Martin Linges vei 17 281 1364 Fornebu, Oestlandet 282 Norway 284 Phone: +47-6782-8200 285 Fax: +47-6782-8201 286 Email: dreibh@simula.no 287 URI: http://www.iem.uni-due.de/~dreibh/ 289 Lode Coene 290 Nokia Siemens Networks 291 Atealaan 32 292 Herentals 2200 293 Belgium 295 Phone: +32-14-252081 296 Email: lode.coene@nsn.com 298 Phillip Conrad 299 University of Delaware 300 103 Smith Hall 301 Newark DE 19716 302 USA 304 Phone: +1-302-831-8622 305 Email: conrad@acm.org