idnits 2.17.1 draft-coene-rserpool-applic-ipfix-15.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 (January 2, 2013) is 4124 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-11 == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-delay-10 == Outdated reference: A later version (-31) exists of draft-dreibholz-rserpool-enrp-takeover-08 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: July 6, 2013 Nokia Siemens Networks 6 P. Conrad 7 University of Delaware 8 January 2, 2013 10 Reliable Server Pooling Applicability for IP Flow Information Exchange 11 draft-coene-rserpool-applic-ipfix-15.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 July 6, 2013. 38 Copyright Notice 40 Copyright (c) 2013 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. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . . 5 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 Reliable Server Pooling provides protocols for providing highly 87 available services. The services are located in a pool of redundant 88 servers and if a server fails, another server will take over. The 89 only requirement put on these servers belonging to the pool is that 90 if state is maintained by the server, this state must be transferred 91 to the other server taking over. 93 The goal is to provide server-based redundancy. Transport and 94 network level redundancy are handle by the transport and network 95 layer protcols. 97 The application may choose to distribute its traffic over the servers 98 of the pool conforming to a certain policy. 100 The application wishing to make use of RSerPool protocols may use 101 different transport layers (such as UDP, TCP and SCTP). However, 102 some transport layers may have restrictions build in in the way they 103 might be operating in the RSerPool architecture and its protocols. 105 1.1. Scope 107 The scope of this document is to explain the way that a minimal 108 version of Reliable Server Pooling protocols have to be used in order 109 to provide a highly available service towards IP Flow Information 110 Exchange (IPFIX) protocols. 112 1.2. Terminology 114 The terms are commonly identified in related work and can be found in 115 the Aggregate Server Access Protocol and Endpoint Handlespace 116 Redundancy Protocol Common Parameters document [RFC5354] 118 2. IPFIX using RSerPool 120 2.1. Architecture 122 IP flow information is exchanged between observation points and 123 collector points. The observation points may try to find out via the 124 Aggregate Server Access Protocol (ASAP, see [RFC5352]) which 125 collector point(s) are active. Both the observation and the 126 collector point may have limitations for exchanging the information 127 (observation point may have limited buffer space and collectors 128 points may be overburdened with receiving lots of flow information 129 from different observation points). 131 The observation point will query the ENRP server for resolution of a 132 particular collector pool name and the ENRP server will return a list 133 of one or more collector points to the observation point. 135 The observation point will use its own transport protocols (TCP, UDP, 136 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 137 between the observation point and the collector point. If a 138 collector point would fail, then the observation point will send its 139 data towards a different collector point, belonging to the same 140 collector pool. 142 Collector points will announce themselves to the ENRP server and will 143 be monitored for their availability. The observation point will only 144 query the ENRP server for server pool name resolution. 146 3. Transport protocols suitable for IPFIX 148 The exchange of IP flow information data between an observation point 149 and a collection point consists of massive amounts of data. 151 One collection point can service many observation points, therefore 152 transport protocols must do congestion control (example: modifying 153 the receive buffer space, thus reducing the incoming flow of data), 154 so that the collection point is not overburdened by its observation 155 points. Some data must arrive at the collector while other data 156 might arrive (if it gets lost: no problem). The choice of reliable 157 or partial reliable delivery has to be made by the observation point 158 These requirements demand a protocol which provides variable 159 transport reliability of its data: it should be able to chose the 160 reliability by the IPFIX protocols on a a per-message base. 162 SCTP [RFC4960] with PR-SCTP extension [RFC3758] is the only know 163 protocol which allows the choice of full, partial or unreliable 164 delivery of the message to its peer node. TCP will only allow fully 165 reliable delivery, while UDP only provides unreliable delivery and NO 166 congestion control. 168 4. Security considerations 170 The protocols used in the Reliable Server Pooling architecture only 171 try to increase the availability of the servers in the network. 172 RSerPool protocols do not contain any protocol mechanisms which are 173 directly related to user message authentication, integrity and 174 confidentiality functions. For such features, it depends on the 175 IPSEC protocols or on Transport Layer Security (TLS) protocols for 176 its own security and on the architecture and/or security features of 177 its user protocols. 179 The RSerPool architecture allows the use of different transport 180 protocols for its application and control data exchange. These 181 transport protocols may have mechanisms for reducing the risk of 182 blind denial-of-service attacks and/or masquerade attacks. If such 183 measures are required by the applications, then it is advised to 184 check the SCTP applicability statement RFC2057 [RFC3257] for guidance 185 on this issue. 187 5. Reference Implementation 189 The RSerPool reference implementation RSPLIB can be found at 190 [RSerPoolPage]. It supports the functionalities defined by 191 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 192 the options [I-D.dreibholz-rserpool-asap-hropt], 193 [I-D.dreibholz-rserpool-enrp-takeover] and 194 [I-D.dreibholz-rserpool-delay]. An introduction to this 195 implementation is provided in [Dre2006]. 197 6. Testbed Platform 199 A large-scale and realistic Internet testbed platform with support 200 for the multi-homing feature of the underlying SCTP protocol is 201 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 202 some further information can be found on the project website 203 [NorNet-Website]. 205 7. Security Considerations 207 Security considerations for RSerPool systems are described by 208 [RFC5355]. 210 8. IANA Considerations 212 This document introduces no additional considerations for IANA. 214 9. Acknowledgments 216 The authors wish to thank Maureen Stillman and many others for their 217 invaluable comments. 219 10. References 221 10.1. Normative References 223 [RFC3257] Coene, L., "Stream Control Transmission Protocol 224 Applicability Statement", RFC 3257, April 2002. 226 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 227 Conrad, "Stream Control Transmission Protocol (SCTP) 228 Partial Reliability Extension", RFC 3758, May 2004. 230 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 231 RFC 4960, September 2007. 233 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 234 Overview of Reliable Server Pooling Protocols", RFC 5351, 235 September 2008. 237 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 238 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 239 September 2008. 241 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 242 Silverton, "Endpoint Handlespace Redundancy Protocol 243 (ENRP)", RFC 5353, September 2008. 245 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 246 "Aggregate Server Access Protocol (ASAP) and Endpoint 247 Handlespace Redundancy Protocol (ENRP) Parameters", 248 RFC 5354, September 2008. 250 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 251 Holdrege, "Threats Introduced by Reliable Server Pooling 252 (RSerPool) and Requirements for Security in Response to 253 Threats", RFC 5355, September 2008. 255 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 256 Policies", RFC 5356, September 2008. 258 [I-D.dreibholz-rserpool-asap-hropt] 259 Dreibholz, T., "Handle Resolution Option for ASAP", 260 draft-dreibholz-rserpool-asap-hropt-11 (work in progress), 261 July 2012. 263 [I-D.dreibholz-rserpool-delay] 264 Dreibholz, T. and X. Zhou, "Definition of a Delay 265 Measurement Infrastructure and Delay-Sensitive Least-Used 266 Policy for Reliable Server Pooling", 267 draft-dreibholz-rserpool-delay-10 (work in progress), 268 July 2012. 270 [I-D.dreibholz-rserpool-enrp-takeover] 271 Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 272 the ENRP Handle Update Message", 273 draft-dreibholz-rserpool-enrp-takeover-08 (work in 274 progress), July 2012. 276 10.2. Informative References 278 [Dre2006] Dreibholz, T., "Reliable Server Pooling - Evaluation, 279 Optimization and Extension of a Novel IETF Architecture", 280 March 2007. 282 [RSerPoolPage] 283 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 2012. 285 [NorNet-Website] 286 Xiang, J., "NorNet -- A Programmable Testbed for 287 Measurements and Experimental Networking Research", 2013. 289 [PAMS2013-NorNet] 290 Dreibholz, T. and E. Gran, "Design and Implementation of 291 the NorNet Core Research Testbed for Multi-Homed Systems", 292 Proceedings of the 3nd International Workshop on Protocols 293 and Applications with Multi-Homing Support (PAMS) , 294 March 2013. 296 Authors' Addresses 298 Thomas Dreibholz 299 Simula Research Laboratory, Network Systems Group 300 Martin Linges vei 17 301 1364 Fornebu, Akershus 302 Norway 304 Phone: +47-6782-8200 305 Fax: +47-6782-8201 306 Email: dreibh@simula.no 307 URI: http://www.iem.uni-due.de/~dreibh/ 308 Lode Coene 309 Nokia Siemens Networks 310 Atealaan 32 311 Herentals 2200 312 Belgium 314 Phone: +32-14-252081 315 Email: lode.coene@nsn.com 317 Phillip Conrad 318 University of Delaware 319 103 Smith Hall 320 Newark DE 19716 321 USA 323 Phone: +1-302-831-8622 324 Email: conrad@acm.org