idnits 2.17.1 draft-coene-rserpool-applic-ipfix-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 253. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 RFC 3978 Section 5.4 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 (April 08, 2005) is 6959 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 160, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 164, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 167, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 175, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 184, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 189, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 196, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '1') ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '4') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '5') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '6') ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '9') == Outdated reference: A later version (-02) exists of draft-ietf-rserpool-service-01 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Dreibholz 2 Internet-Draft University of Duisburg-Essen 3 Expires: October 10, 2005 L. Coene 4 Siemens 5 P. Conrad 6 University of Delaware 7 April 08, 2005 9 Reliable Server Pooling Applicability for IP Flow Information Exchange 10 draft-coene-rserpool-applic-ipfix-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 10, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the applicability of the Relialeble Server 44 Pooling architecture to the IP Flow Information Exchange using the 45 Aggregate Server Access Protocol (ASAP) functionality of RSerPool 46 only. Data exchange in IPFIX between the router and the data 47 collector can be provided by a limited retransmission protocol. 49 1. Introduction 51 Reliable Server Pooling provides protocols for providing highly 52 available services. The services are located in a pool of redundant 53 servers and if a server fails, another server will take over. The 54 only requirement put on these servers belonging to the pool is that 55 if state is maintained by the server, this state must be transfered 56 to the other server taking over. 58 The goal is to provide server-based redundancy. Transport and 59 network level redundancy are handle by the transport and network 60 layer protcols. 62 The application may choose to distribute its traffic over the servers 63 of the pool conforming to a certain policy. 65 The application wishing to make use of RSerPool protocols may use 66 different transport layers (such as UDP, TCP and SCTP). However, 67 some transport layers may have restrictions build in in the way they 68 might be operating in the RSerPool architecture and its protocols. 70 1.1 Scope 72 The scope of this document is to explain the way that a minimal 73 version of Reliable Server Pooling protocols have to be used in order 74 to provide a higly available service towards IP Flow Information 75 Exchange (IPFIX) protocols. 77 1.2 Terminology 79 The terms are commonly identified in related work and can be found in 80 the Aggregate Server Access Protocol and Endpoint Handlespace 81 Redundancy Protocol Common Parameters document ietf-rserpool-common- 82 param [6] 84 2. IPFIX using RSerPool 86 2.1 Architecture 88 IP flow information is exchanged between observation points and 89 collector points. The observation points may try to find out via the 90 Aggregate Server Access Protocol (ASAP, see ietf-rserpool-asap [4]) 91 which collector point(s) are active. Both the observation and the 92 collector point may have limitations for exchanging the information 93 (observation point may have limited buffer space and collectors 94 points may be overburdened with receiving lots of flow information 95 from different observation points). 97 The observation point will query the ENRP server for resolution of a 98 particular collector pool name and the ENRP server will return a list 99 of one or more collector points to the observation point. 101 The observation point will use its own transport protocols (TCP, UDP, 102 SCTP, SCTP with PR-SCTP extension) for exchanging the IPFIX data 103 between the observation point and the collector point. If a 104 collector point would fail, then the observation point will send its 105 data towards a different collector point, belonging to the same 106 collector pool. 108 Collector points will announce themselves to the ENRP server and will 109 be monitored for their avialebility. The observation point will only 110 query the ENRP server for server pool name resolution. 112 3. Transport protocols suitable for IPFIX 114 The exchange of IP flow information data between an observation point 115 and a collection point consists of massive ammounts of data. 117 One collection point can service many observation points, therefore 118 transport protocols must do congestion control (example: modifying 119 the receive buffer space, thus reducing the incoming flow of data), 120 so that the collection point is not overburdened by its observation 121 points. Some data must arrive at the collector while other data 122 migth arrive (if it gets lost: no problem). The choice of reliable 123 or partial reliable delivery has to be made by the observation point 124 These requirements demand a protocol which provides variable 125 transport reliability of its data: it should be able to chose the 126 reliability by the IPFIX protocols on a a per-message base. 128 SCTP with PR-SCTP extension is the only know protocol which allows 129 the choice of full, partial or unrelialeble delivery of the message 130 to its peer node. TCP will only allow fully relialable delivery, 131 while UDP only provides unrelialeble delivery and NO congestion 132 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 M. Stillman and many others for their 156 invaluable comments. 158 6. Normative References 160 [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 161 J., and M. Stillman, "Requirements for Reliable Server 162 Pooling", RFC 3237, January 2002. 164 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 165 RFC 3668, February 2004. 167 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 168 A. Silverton, "Architecture for Reliable Server Pooling", 169 draft-ietf-rserpool-arch-09 (work in progress), February 2005. 171 [4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 172 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-11 173 (work in progress), February 2005. 175 [5] Xie, Q., Stewart, R., Stillman, M., and M. Tuexen, "Enpoint 176 Handlespace Redundancy Protocol (ENRP)", 177 draft-ietf-rserpool-enrp-11 (work in progress), February 2005. 179 [6] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 180 Server Access Protocol (ASAP) and Endpoint Name Resolution 181 (ENRP) Parameters", draft-ietf-rserpool-common-param-08 (work 182 in progress), February 2005. 184 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 185 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 186 Paxson, "Stream Control Transmission Protocol", RFC 2960, 187 October 2000. 189 [8] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 190 "Stream Control Transmission Protocol (SCTP) Partial 191 Reliability Extension", RFC 3758, May 2004. 193 [9] Coene, L., "Stream Control Transmission Protocol Applicability 194 Statement", RFC 3257, April 2002. 196 [10] Conrad, P. and P. Lei, "Services Provided By Reliable Server 197 Pooling", draft-ietf-rserpool-service-01 (work in progress), 198 June 2004. 200 Authors' Addresses 202 Thomas Dreibholz 203 University of Duisburg-Essen, Institute for Experimental Mathematics 204 Ellernstrasse 29 205 45326 Essen, Nordrhein-Westfalen 206 Germany 208 Phone: +49-201-1837637 209 Fax: +49-201-1837673 210 Email: dreibh@exp-math.uni-essen.de 211 URI: http://www.exp-math.uni-essen.de/~dreibh/ 213 Lode Coene 214 Siemens 215 Atealaan 32 216 Herentals 2200 217 Belgium 219 Phone: +32-14-252081 220 Email: lode.coene@siemens.com 222 Phillip Conrad 223 University of Delaware 224 103 Smith Hall 225 Newark DE 19716 226 USA 228 Phone: +1 302 831 8622 229 Email: conrad@acm.org 231 Intellectual Property Statement 233 The IETF takes no position regarding the validity or scope of any 234 Intellectual Property Rights or other rights that might be claimed to 235 pertain to the implementation or use of the technology described in 236 this document or the extent to which any license under such rights 237 might or might not be available; nor does it represent that it has 238 made any independent effort to identify any such rights. Information 239 on the procedures with respect to rights in RFC documents can be 240 found in BCP 78 and BCP 79. 242 Copies of IPR disclosures made to the IETF Secretariat and any 243 assurances of licenses to be made available, or the result of an 244 attempt made to obtain a general license or permission for the use of 245 such proprietary rights by implementers or users of this 246 specification can be obtained from the IETF on-line IPR repository at 247 http://www.ietf.org/ipr. 249 The IETF invites any interested party to bring to its attention any 250 copyrights, patents or patent applications, or other proprietary 251 rights that may cover technology that may be required to implement 252 this standard. Please address the information to the IETF at 253 ietf-ipr@ietf.org. 255 Disclaimer of Validity 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 260 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 261 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 262 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Copyright Statement 267 Copyright (C) The Internet Society (2005). This document is subject 268 to the rights, licenses and restrictions contained in BCP 78, and 269 except as set forth therein, the authors retain all their rights. 271 Acknowledgment 273 Funding for the RFC Editor function is currently provided by the 274 Internet Society.