idnits 2.17.1 draft-coene-rserpool-applic-ipfix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 197 has weird spacing: '... zzzz zzzz...' -- 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 (February 13, 2003) is 7743 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) -- Looks like a reference, but probably isn't: 'RFCCOMM' on line 80 -- Looks like a reference, but probably isn't: 'RFC3057' on line 145 == Unused Reference: '1' is defined on line 154, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 158, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 162, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 166, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 169, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 173, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 176, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 181, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '8') Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP flow information exchange L. Coene 3 Working group Siemens 4 Internet-Draft P. Conrad 5 Expires: August 14, 2003 Temple University 6 February 13, 2003 8 Reliable Server pool use in IP flow information exchange 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 14, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes the applicability of the relialeble server 40 pool architecture to the IP flow information exchange using Endpoint 41 Name Resolution Protocol(ENRP) function of Rserpool only. Data 42 exchange in IPFIX between the router and the datacollector can be 43 using a limited retransmission protocol. 45 1. INTRODUCTION 47 Reliable server pooling provides protocols for providing higly 48 available services. The services are located in pool of redundant 49 servers and if a server fails, another server will take over. The 50 only requirement put on these servers belonging to the pool is that 51 if state is maintained by the server, this state must be transfered 52 to the other server taking over. The mechanism for transfering this 53 state information is NOT part of the Reliable server pooling 54 architecture and/or protocols and must be provided by other 55 protocols. 57 The goal is to provide server based redundancy. Transport and network 58 level redundancy are handle by the transport and network layer 59 protcols. 61 The application may choose to distribute its traffic over the servers 62 of the pool conforming to a certain policy. 64 The application wishing to make use of Rserpool protocols may use 65 different transport layers(such as UDP, TCP and SCTP). However some 66 transport layers may have restrictions build in in the way they might 67 be operating in the Rserpool architecture and its protocols. 69 1.1 Scope 71 The scope of this document is to explain the way that a minimal 72 version of Reliable server pool protocols have to be used in order to 73 provide a higly available service towards IP flow Information 74 Exchange(IPFIX) protocols. 76 1.2 Terminology 78 The terms are commonly identified in related work and can be found in 79 the Aggregate Server Access Protocol and Endpoint Name Resolution 80 Protocol Common Parameters document[RFCCOMM]. 82 2. IPFIX using Rserpool 84 2.1 Architecture 86 IP flow information is exchanged between observation points and 87 collector points. The observation points may try to find out via the 88 endpoint resolution protocol(ENRP) which collector point(s) are 89 active. Both the observation and the collector point may have 90 limitations for exchanging the information( observation point may 91 have limited buffer space and collectors points may be overburdened 92 with receiving lots of flow info from different observation points). 94 The observation point will query the ENRP server for resolution of a 95 particular collector pool name and ENRP will return to the 96 observation point of list of 1 or more collector points. 98 The observation point will use its own transport protocols(TCP, UDP, 99 SCTP, PR-SCTP) for exchanging the IPFIX data between the observation 100 point and the collection point. If a collection point would fail, 101 then the observation point will send its data towards a different 102 collector point, belonging to the same collector pool. 104 Collector points will announce themselves to the ENRP server and will 105 be monitored for their avialebility. The observation point will only 106 query the ENRP server for server pool namer resolution. 108 3. Transport protocols suitable for IPFIX 110 The exchange of IP flow information data between a observation point 111 and a collection point consists of massive ammounts of data. 113 One collection point can service many observation points, therefore 114 transport protocols must do congestion control(example: modifying the 115 receive buffer space, thus reducing the incoming flow of data), so 116 that the collection point is not overburdened by its collections 117 points. Some data must arrive at the collectore while othr data migth 118 arrive(if it get lost, no problem). The choice of relialeble or 119 partial relialeble delivery has to be made by the observation point. 120 This calls for a protocol that should have variable relialebility for 121 the transport of its data, prefereably to be chosen by IPFIX 122 protocols on a per-message base. 124 PR-SCTP is the only know protocol which allows the choice of full, 125 partial or no relialeble delivery of the message to its peer node. 126 TCP will only allow full relialeble delivery, while UDP has only 127 unrelialeble delivery and NO congestion control to speak of. 129 4. Security considerations 131 The protocols used in the Reliable server pool architecture only 132 tries to increase the availability of the servers in the network. 133 Rserpool protocols does not contain any protocol mechanisms which are 134 directly related to user message authentication, integrity and 135 confidentiality functions. For such features, it depends on the IPSEC 136 protocols or on Transport Layer Security(TLS) protocols for its own 137 security and on the architecture and/or security features of its user 138 protocols. 140 Rserpool architecture allows the use of different Transport protocols 141 for its application and control data exchange. Those transport 142 protocols may have mechanisms for reducing the risk of blind 143 denial-of-service attacks and/or masquerade attacks. If such measures 144 are required by the applications, then it is advised to check the 145 SCTP applicability statement[RFC3057] for guidance on this issue. 147 5. Acknowledgments 149 The authors wish to thank X, Y and M. Stillman and many others for 150 their invaluable comments. 152 References 154 [1] Tuexen, M., Stewart, R., Shore, M., Xie, Q., Ong, L., Loughney, 155 J. and M. Stillman, "Requirements for Reliable Server Pooling", 156 RFC 3237, January 2002. 158 [2] Tuexen, M., Stewart, R., Shore, M., Xie, Q., Ong, L., Loughney, 159 J. and M. Stillman, "Architecture for Reliable Server Pooling", 160 Draft in progress , October 2002. 162 [3] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 163 Server Access Protocol (ASAP)", Draft in progress , October 164 2002. 166 [4] Xie, Q., Stewart, R. and M. Stillman, "Endpoint Name Resolution 167 Protocol (ENRP)", Draft in progress , October 2002. 169 [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 170 Server Access Protocol and Endpoint Name Resolution Protocol 171 Common Parameters", Draft in progress , October 2002. 173 [6] Conrad, P. and P. Lei, ""Services Provided By Reliable Server 174 Pooling", Draft in progress , January 2003. 176 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 177 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 178 ""Stream Control Transmission Protocol"", RFC 2960, October 179 2000. 181 [8] Coene, L., ""Stream Control Transmission Protocol Applicability 182 statement"", RFC 3257, April 2002. 184 Authors' Addresses 186 Lode Coene 187 Siemens 188 Atealaan 32 189 Herentals 2200 190 Belgium 192 Phone: +32-14-252081 193 EMail: lode.coene@siemens.com 194 Phil Conrad 195 Temple University 196 zzz 197 zzzz zzzz 198 USA 200 Phone: zzzz 201 EMail: zzzz 203 Intellectual Property Statement 205 The IETF takes no position regarding the validity or scope of any 206 intellectual property or other rights that might be claimed to 207 pertain to the implementation or use of the technology described in 208 this document or the extent to which any license under such rights 209 might or might not be available; neither does it represent that it 210 has made any effort to identify any such rights. Information on the 211 IETF's procedures with respect to rights in standards-track and 212 standards-related documentation can be found in BCP-11. Copies of 213 claims of rights made available for publication and any assurances of 214 licenses to be made available, or the result of an attempt made to 215 obtain a general license or permission for the use of such 216 proprietary rights by implementors or users of this specification can 217 be obtained from the IETF Secretariat. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights which may cover technology that may be required to practice 222 this standard. Please address the information to the IETF Executive 223 Director. 225 Full Copyright Statement 227 Copyright (C) The Internet Society (2003). All Rights Reserved. 229 This document and translations of it may be copied and furnished to 230 others, and derivative works that comment on or otherwise explain it 231 or assist in its implementation may be prepared, copied, published 232 and distributed, in whole or in part, without restriction of any 233 kind, provided that the above copyright notice and this paragraph are 234 included on all such copies and derivative works. However, this 235 document itself may not be modified in any way, such as by removing 236 the copyright notice or references to the Internet Society or other 237 Internet organizations, except as needed for the purpose of 238 developing Internet standards in which case the procedures for 239 copyrights defined in the Internet Standards process must be 240 followed, or as required to translate it into languages other than 241 English. 243 The limited permissions granted above are perpetual and will not be 244 revoked by the Internet Society or its successors or assignees. 246 This document and the information contained herein is provided on an 247 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 248 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 249 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 250 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 251 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 253 Acknowledgement 255 Funding for the RFC Editor function is currently provided by the 256 Internet Society.