idnits 2.17.1 draft-stewart-tsvwg-reconfuse-sctp-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (March 29, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2960' is defined on line 339, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 2 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 R. Stewart 3 Internet-Draft Huawei 4 Intended status: Informational P. Lei 5 Expires: September 30, 2011 Cisco Systems, Inc. 6 M. Tuexen 7 Muenster Univ. of Applied 8 Sciences 9 March 29, 2011 11 Uses of Stream Reconfiguration for SCTP 12 draft-stewart-tsvwg-reconfuse-sctp-00.txt 14 Abstract 16 This document is used to convey different use cases for the Stream 17 Reconfiguration draft xxxxxxx. It does not represent a standard nor 18 does it represent real applications that are available for download. 19 Instead it illustrates various use cases of the stream 20 reconfiguration facilities for SCTP [RFC4960] . It serves as a 21 guideline to application developers to show the stream 22 reconfigurations various potentials. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 30, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Example Applications . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. And FTP example . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Combining features to achieve redundancy . . . . . . . . . 6 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 77 6. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 81 8.2. Informational References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 Many times on the tsvwg mailing list some have questioned the valid 87 uses of various features in the stream reconfiguration draft. This 88 document attempts to answer those questions by illustrating use cases 89 for all of the features currently contained within the draft has it 90 went to last call in tsvwg. Some of the use cases mentioned here 91 have been implemented at one time or another by the various co- 92 authors of the reconfiguration draft. Other examples have not been 93 built but instead are used to simply illustrate how one would use the 94 feature. 96 2. Terminology 98 List any terminology that we will use in the document. 100 3. Example Applications 102 In this document we present NNN example applications that illustrate 103 the use of stream reconfiguration. First we will examine a typical 104 use by illustrating a mythical file transfer protocol something like 105 FTP but modified to fit SCTP. Next we will go further and examine 106 how the stream re-configuation in combination with the SCTP Address 107 Reconfiguration [RFC5061] and SCTP Authentication [RFC4895] can be 108 combined to provide a redundancy service that allows a "backup" 109 application to acquire or move an association from one machine to 110 another. 112 3.1. And FTP example 114 FTP is a long time staple of the internet. Most every operating 115 system today has an ftp client and often times an FTP server that can 116 be enabled if desired. It is an easily understood paradigm. A user 117 logs in to an ftp server via an ftp command. And then can send 118 various commands to change directories, request file transfers, list 119 file or even make directories. 121 Some users will also find that they have to go into "passive" mode 122 since normally when FTP starts a file transfer, it creates a new TCP 123 connection between the server and the client for the actual file 124 transfer. The closing of the connection is normally used as the 125 signal to the client or server receiving the file that all of the 126 data bytes have been transferred. In the Socket API this is usually 127 signified by a zero length read. In the case of some NAT's and 128 firewalls passive mode is required to not be blocked by the 129 middlebox. 131 In this example we will illustrate the handy use of SCTP and its 132 stream reconfiguration feature to do an equivalent SCTP version of 133 FTP. The user would of course login to the ftp server in the same 134 way today that they do with tcp. Setting up an association via a 135 client command. In the case of the underlying SCTP configuration 136 each side would ask for a number of streams equal to one more than 137 the number of simultaneous transfers they anticipate supporting. 138 Conservative clients and servers would ask for 2. Stream 0 is 139 reserved for the "command" stream and is considered a bi-directional 140 stream. Commands such as 'ls' or 'cd' would be sent via stream 0 and 141 the appropriate responses (e.g. the list of files) would be sent back 142 to the client over stream 0 in response. 144 When the client wishes to transfer a file by the client doing a "get 145 foo" command. The server do the following: 147 1> Choose an idle stream, an idle stream is one not being used for 148 file transfer at this time and is in the initial state, i.e. the 149 next stream sequence number is 0. 151 2> On the selected stream the server would send a special message as 152 the first message on the stream i.e. stream sequence 0. This 153 message would contain the name of the file, the ownership (user 154 name and possibly user id), permissions and any other bookkeeping 155 information that is necessary for the transfer. Setting that 156 streams state to non-idle or in the file transfer state. 158 3> After sending the first setup message, send each data block to the 159 peer from the file in an ordered message on the selected stream to 160 the peer requesting the file. 162 4> At the completion of the file transfer, reset the stream sequence 163 number and place the stream back to the idle state. 165 When receiving this first message on the respective stream (N), the 166 first message, ssn 0, would: 168 A> Key the receiver into placing the incoming stream into "file 169 transfer" mode. The special ssn 0 on a un-assigned stream (i.e 170 one not in a file transfer state) into using the first message to 171 open the file and set the stream into the "file transfer" state. 173 B> All subsequent messages arriving on the stream in this state are 174 directly written to the appropriate file descriptor assigned to 175 that stream. 177 C> If for some reason the file could not be opened or a write error 178 in output of the data occurs, the receiver would request a 179 incoming and outgoing stream reset to signal to the peer that an 180 error occurred. 182 D> In the file transfer state, the stream would continue to receive 183 either messages (which would be written out) or a stream reset. 184 The stream reset would indicate to the receiver that the stream is 185 to be taken out of the file transfer state and the file is to be 186 closed. 188 E> At that point the stream is set back to the initial state and is 189 available for any subsequent transfer. 191 When a 'put' is requested by the client, no message need travel over 192 the control stream 0. Instead the client would simply select an idle 193 stream and send the same transfer message to the peer as the first 194 stream sequence number 0 to the server. The server would react the 195 same way that the client did above and follow similar procedures. 197 It is also possible that one of the sides, when going to transfer a 198 file, does not have any idle streams. In such a case the add stream 199 capability can be used to add an additional stream resource. This 200 allows a SCTP-FTP server and client to start with a minimal number of 201 streams (2 at a minimum) and only expand the number of streams upon 202 the demand of the user for parallel transfers. 204 This example illustrates the use of two basic reconfiguration 205 utilities. The add-stream and the stream-reset for SSN. The next 206 example will illustrate some various uses of the multiple stream 207 reset and the TSN/SSN reset capabilities. 209 3.2. Combining features to achieve redundancy 211 Consider the following picture: 213 +--------+ +---------+ 214 | Host-A | | Host-A~ | 215 +---+----+ +----+----+ 216 | IP-A | IP-B 217 | | 218 +-------------+--------------+ 219 | 220 | IP-Z 221 +------+----+ 222 | Host-Peer | 223 +-----------+ 225 Host-A and Host-Peer have an SCTP association between them. The 226 association is between IP-A:NNNN and IP-Z:MMMMM. Now often times in 227 such a situation it is desired to have Host-A~ backup Host-A in case 228 of a fault in either the hardware or software of Host-A. A variety 229 of methods have been used to do this in the past. One common method 230 is that Host-A~ watches Host-A in some fashion via either specialized 231 hardware of some sort of pinging mechanism. If Host-A~ sees that 232 Host-A is down, it assumes the network identity of host A by adopting 233 IP-A on its interface and sending a promiscuous ARP so that packets 234 destined to IP-A end up at the backup (i.e. Host-A~). 236 Now one problem with this is any TCP connection or SCTP association 237 between Host-A and Host-Peer will need to be torn down and re- 238 established. This, in some protocols, may have un-desireable side- 239 effects (e.g. BGP). Some implementations have attempted to 240 compensate for this by having additional connectivity between Host-A 241 and Host-A~ and keeping track of sequence numbers at the transport 242 layer as well as keeping track of application state (between the 243 primary and backup application). Much of the transport state is 244 stable but large parts of it also are transient. In SCTP's case TSN 245 and Stream Sequence numbers may be changing quite rapidly and this 246 takes away additional resources by generating additional traffic 247 between Host-A and Host-A~. Add to this that the promiscuous ARP and 248 assuming the network identity of the peer is in itself somewhat 249 kludgy at best. 251 Now consider a possible different scenario which can be used if we 252 apply SCTP's address reconfiguration, SCTP Authentication and the 253 Stream reconfiguration mechanisms. If the two servers (Host-A and 254 Host-A~) will do the following every time they acquire a peer: 256 1) After association setup send the random keys (for AUTH), Vtags, 257 Sequence numbers, stream sequence numbers and various SCTP PCB 258 information to Host-A~. 260 2) The application can use an inter-SCTP association between IP-A and 261 IP-B to send this information. This association can further be 262 used to send any application state updates that are needed and 263 both servers should be using the same port number NNNN. 265 3) If the application ever uses the stream reconfiguration mechanism, 266 an updated stream reconfiguration sequence number must be sent to 267 the backup peer over this association. But note these changes are 268 hopefully far less frequent then changes to TSN or SSN's within 269 the association to the Host-Peer. 271 4) The backup peer Host-A~ may wish to increase the SCTP heartbeat 272 rate to a faster value so that normal SCTP mechanisms (although at 273 a faster rate) can be used to detect peer association failure 274 faster than normally would be detected (by Host-Peer). 276 After this setup, if Host-A fails, Host-A~ would do the following: 278 A) Immediately upon detecting host failure of Host-A, send an Address 279 Reconfiguration [RFC5061] with the appropriate authentication 280 [RFC4895] to Host-Peer. In this reconfiguration, Add IP-B first, 281 followed by Delete IP-A. These two actions should be bundled in 282 one reconfiguration message but the Add parameter must be first 283 (otherwise the peer would reject the request). 285 B) After the address reconfiguration successfully completes send a 286 stream reconfiguration resetting the TSN and all SSN's. This is 287 done with the TSN/SSN reconfiguration request. 289 C) After completion the application should be able to continue to 290 talk to Host-Peer over the same association. Asking for any 291 reconfiguration (if needed) that the application would like with 292 its peer (e.g. a BGP restart). 294 An alternative to this strategy would be to use just SSN resets but 295 this would place additional burden upon the synchronization between 296 Host-A and Host-A~ in that the TSN sequence would need to be kept in 297 sync in addition to the stream reconfiguration sequence space. 299 This mechanism could then be used to provide a "friendly" takeover 300 for redundancy purposes of a peer association with no down time. 301 Other scenarios are also possible, for example an application may 302 want to use similar mechanisms to hand off part of its load from one 303 server to another while both are active i.e. not in a failure case. 305 More Examples to come 307 4. Security Considerations 309 TBD 311 5. IANA Considerations 313 TBD 315 6. IPR Considerations 317 An IPR disclosure will be forthcoming. 319 7. Acknowledgements 321 8. References 323 8.1. Normative references 325 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 326 "Authenticated Chunks for the Stream Control Transmission 327 Protocol (SCTP)", RFC 4895, August 2007. 329 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 330 RFC 4960, September 2007. 332 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 333 Kozuka, "Stream Control Transmission Protocol (SCTP) 334 Dynamic Address Reconfiguration", RFC 5061, 335 September 2007. 337 8.2. Informational References 339 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 340 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 341 Zhang, L., and V. Paxson, "Stream Control Transmission 342 Protocol", RFC 2960, October 2000. 344 Authors' Addresses 346 Randall R. Stewart 347 Huawei 348 Chapin, SC 29036 349 USA 351 Email: randall@lakerest.net 352 Peter Lei 353 Cisco Systems, Inc. 354 8735 West Higgins Road 355 Suite 300 356 Chicago, IL 60631 357 USA 359 Phone: 360 Email: peterlei@cisco.com 362 Michael Tuexen 363 Muenster University of Applied Sciences 364 Stegerwaldstr. 39 365 48565 Steinfurt 366 Germany 368 Email: tuexen@fh-muenster.de