idnits 2.17.1 draft-dreibholz-rserpool-asap-hropt-13.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 05, 2013) is 3947 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-delay-11 == Outdated reference: A later version (-31) exists of draft-dreibholz-rserpool-enrp-takeover-09 Summary: 0 errors (**), 0 flaws (~~), 3 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: Experimental July 05, 2013 5 Expires: January 6, 2014 7 Handle Resolution Option for ASAP 8 draft-dreibholz-rserpool-asap-hropt-13.txt 10 Abstract 12 This document describes the Handle Resolution option for the ASAP 13 protocol. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 6, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Handle Resolution Option . . . . . . . . . . . . . . . . . . . 3 66 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Reference Implementation . . . . . . . . . . . . . . . . . . . 4 68 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Reliable Server Pooling defines protocols for providing highly 80 available services. The Aggregate Server Access Protocol (ASAP) 81 provides session management and server selection for applications. 82 Upon request for a server selection -- denoted as handle resolution 83 -- an ENRP server returns a list of selected PE identities. The 84 number of PE identities to be returned is not specified by RSerPool. 85 Furthermore the ASAP protocol does not contain a way for letting the 86 requesting instance specify it. 88 As shown in [Dre2006], [IJAIT2009], [IJHIT2008], selecting too many 89 entries does not make sense for the application, but on the other 90 hand also result in significant processing and network overhead. 91 Furthermore, it has been shown in [LCN2005] that the number of 92 requested elements is usually 1, but there are application cases 93 where more PE identities have to be returned. That is, there should 94 be a possibility to specify the number of requested PE items upon a 95 handle resolution. 97 1.1. Scope 99 The Handle Resolution option defined in this draft simply defines an 100 option to let the PU-side specify the desired number of PE identities 101 from the ENRP server. 103 1.2. Terminology 105 The terms are commonly identified in related work and can be found in 106 the Aggregate Server Access Protocol and Endpoint Handlespace 107 Redundancy Protocol Common Parameters document RFC 5354 [RFC5354]. 109 1.3. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Handle Resolution Option 117 2.1. Definition 119 The Handle Resolution MAY be used once in an ASAP Handle Resolution 120 message sent from a PU to an ENRP server. It is defined as follows. 122 0 1 2 3 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Type = 0x803f | Length=8 | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Items | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Items: 32 bits (unsigned integer) 132 Contains the number of PE identities to be selected by the ENRP 133 server. Setting it to 0xffffffff denotes to obtain as many PE 134 identities as possible. A setting of 0 denotes to use the ENRP 135 server's default value; this default MUST be used if there is no 136 Handle Resolution option given. The ENRP server SHOULD try to fulfil 137 the request for the given number of items. 139 Note, that the high-order bits of the type field are set to 10, which 140 means "skip this parameter and continue processing" if this parameter 141 type is not supported by the ENRP server. This allows for 142 interoperability with old implementations. 144 3. Reference Implementation 146 The RSerPool reference implementation RSPLIB can be found at 147 [RSerPoolPage]. It supports the functionalities defined by 148 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 149 the options [I-D.dreibholz-rserpool-delay], 150 [I-D.dreibholz-rserpool-enrp-takeover] and of course the option 151 defined by this document. An introduction to this implementation is 152 provided in [Dre2006]. 154 4. Testbed Platform 156 A large-scale and realistic Internet testbed platform with support 157 for the multi-homing feature of the underlying SCTP protocol is 158 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 159 some further information can be found on the project website 160 [NorNet-Website]. 162 5. Security Considerations 164 Security considerations for RSerPool systems are described by 165 [RFC5355]. 167 6. IANA Considerations 169 This document does not require additional IANA actions beyond those 170 already identified in the ENRP and ASAP protocol specifications. 172 7. Acknowledgments 174 The author would like to thank Nihad Cosic, Dirk Hoffstadt, Michael 175 Kohnen, Jobin Pulinthanath and Xing Zhou for their support. 177 8. References 179 8.1. Normative References 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 185 Overview of Reliable Server Pooling Protocols", RFC 5351, 186 September 2008. 188 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 189 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 190 September 2008. 192 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 193 Silverton, "Endpoint Handlespace Redundancy Protocol 194 (ENRP)", RFC 5353, September 2008. 196 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 197 "Aggregate Server Access Protocol (ASAP) and Endpoint 198 Handlespace Redundancy Protocol (ENRP) Parameters", 199 RFC 5354, September 2008. 201 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 202 Holdrege, "Threats Introduced by Reliable Server Pooling 203 (RSerPool) and Requirements for Security in Response to 204 Threats", RFC 5355, September 2008. 206 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 207 Policies", RFC 5356, September 2008. 209 [I-D.dreibholz-rserpool-delay] 210 Dreibholz, T. and X. Zhou, "Definition of a Delay 211 Measurement Infrastructure and Delay-Sensitive Least-Used 212 Policy for Reliable Server Pooling", 213 draft-dreibholz-rserpool-delay-11 (work in progress), 214 December 2012. 216 [I-D.dreibholz-rserpool-enrp-takeover] 217 Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 218 the ENRP Handle Update Message", 219 draft-dreibholz-rserpool-enrp-takeover-09 (work in 220 progress), December 2012. 222 8.2. Informative References 224 [Dre2006] Dreibholz, T., "Reliable Server Pooling - Evaluation, 225 Optimization and Extension of a Novel IETF Architecture", 226 March 2007. 228 [IJAIT2009] 229 Dreibholz, T. and E. Rathgeb, "Overview and Evaluation of 230 the Server Redundancy and Session Failover Mechanisms in 231 the Reliable Server Pooling Framework", International 232 Journal on Advances in Internet Technology (IJAIT), Volume 233 2, Number 1, Pages 1-14, ISSN 1942-2652, June 2009. 235 [IJHIT2008] 236 Dreibholz, T. and E. Rathgeb, "An Evaluation of the Pool 237 Maintenance Overhead in Reliable Server Pooling Systems", 238 SERSC International Journal on Hybrid Information 239 Technology (IJHIT), Volume 1, Number 2, Pages 17-32, 240 ISSN 1738-9968, April 2008. 242 [LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of 243 Reliable Server Pooling Systems", Proceedings of the IEEE 244 Conference on Local Computer Networks (LCN) 30th 245 Anniversary, Pages 200-208, ISBN 0-7695-2421-4, 246 DOI 10.1109/LCN.2005.98, November 2005. 248 [RSerPoolPage] 249 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 250 Online: http://www.iem.uni-due.de/~dreibh/rserpool/, 2012. 252 [NorNet-Website] 253 Dreibholz, T., "NorNet -- A Real-World, Large-Scale Multi- 254 Homing Testbed", Online: http://www.nntb.no/, 2013. 256 [PAMS2013-NorNet] 257 Dreibholz, T. and E. Gran, "Design and Implementation of 258 the NorNet Core Research Testbed for Multi-Homed Systems", 259 Proceedings of the 3nd International Workshop on Protocols 260 and Applications with Multi-Homing Support (PAMS) , 261 March 2013. 263 Author's Address 265 Thomas Dreibholz 266 Simula Research Laboratory, Network Systems Group 267 Martin Linges vei 17 268 1364 Fornebu, Akershus 269 Norway 271 Phone: +47-6782-8200 272 Fax: +47-6782-8201 273 Email: dreibh@simula.no 274 URI: http://www.iem.uni-due.de/~dreibh/