Network Working Group R. Stewart Internet-Draft Huawei Intended status: Informational P. Lei Expires: September 30, 2011 Cisco Systems, Inc. M. Tuexen Muenster Univ. of Applied Sciences March 29, 2011 Uses of Stream Reconfiguration for SCTP draft-stewart-tsvwg-reconfuse-sctp-00.txt Abstract This document is used to convey different use cases for the Stream Reconfiguration draft xxxxxxx. It does not represent a standard nor does it represent real applications that are available for download. Instead it illustrates various use cases of the stream reconfiguration facilities for SCTP [RFC4960] . It serves as a guideline to application developers to show the stream reconfigurations various potentials. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Stewart, et al. Expires September 30, 2011 [Page 1] Internet-Draft SCTP Reconf Use March 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Stewart, et al. Expires September 30, 2011 [Page 2] Internet-Draft SCTP Reconf Use March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Example Applications . . . . . . . . . . . . . . . . . . . . . 4 3.1. And FTP example . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Combining features to achieve redundancy . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 8.2. Informational References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Stewart, et al. Expires September 30, 2011 [Page 3] Internet-Draft SCTP Reconf Use March 2011 1. Introduction Many times on the tsvwg mailing list some have questioned the valid uses of various features in the stream reconfiguration draft. This document attempts to answer those questions by illustrating use cases for all of the features currently contained within the draft has it went to last call in tsvwg. Some of the use cases mentioned here have been implemented at one time or another by the various co- authors of the reconfiguration draft. Other examples have not been built but instead are used to simply illustrate how one would use the feature. 2. Terminology List any terminology that we will use in the document. 3. Example Applications In this document we present NNN example applications that illustrate the use of stream reconfiguration. First we will examine a typical use by illustrating a mythical file transfer protocol something like FTP but modified to fit SCTP. Next we will go further and examine how the stream re-configuation in combination with the SCTP Address Reconfiguration [RFC5061] and SCTP Authentication [RFC4895] can be combined to provide a redundancy service that allows a "backup" application to acquire or move an association from one machine to another. 3.1. And FTP example FTP is a long time staple of the internet. Most every operating system today has an ftp client and often times an FTP server that can be enabled if desired. It is an easily understood paradigm. A user logs in to an ftp server via an ftp command. And then can send various commands to change directories, request file transfers, list file or even make directories. Some users will also find that they have to go into "passive" mode since normally when FTP starts a file transfer, it creates a new TCP connection between the server and the client for the actual file transfer. The closing of the connection is normally used as the signal to the client or server receiving the file that all of the data bytes have been transferred. In the Socket API this is usually signified by a zero length read. In the case of some NAT's and firewalls passive mode is required to not be blocked by the middlebox. Stewart, et al. Expires September 30, 2011 [Page 4] Internet-Draft SCTP Reconf Use March 2011 In this example we will illustrate the handy use of SCTP and its stream reconfiguration feature to do an equivalent SCTP version of FTP. The user would of course login to the ftp server in the same way today that they do with tcp. Setting up an association via a client command. In the case of the underlying SCTP configuration each side would ask for a number of streams equal to one more than the number of simultaneous transfers they anticipate supporting. Conservative clients and servers would ask for 2. Stream 0 is reserved for the "command" stream and is considered a bi-directional stream. Commands such as 'ls' or 'cd' would be sent via stream 0 and the appropriate responses (e.g. the list of files) would be sent back to the client over stream 0 in response. When the client wishes to transfer a file by the client doing a "get foo" command. The server do the following: 1> Choose an idle stream, an idle stream is one not being used for file transfer at this time and is in the initial state, i.e. the next stream sequence number is 0. 2> On the selected stream the server would send a special message as the first message on the stream i.e. stream sequence 0. This message would contain the name of the file, the ownership (user name and possibly user id), permissions and any other bookkeeping information that is necessary for the transfer. Setting that streams state to non-idle or in the file transfer state. 3> After sending the first setup message, send each data block to the peer from the file in an ordered message on the selected stream to the peer requesting the file. 4> At the completion of the file transfer, reset the stream sequence number and place the stream back to the idle state. When receiving this first message on the respective stream (N), the first message, ssn 0, would: A> Key the receiver into placing the incoming stream into "file transfer" mode. The special ssn 0 on a un-assigned stream (i.e one not in a file transfer state) into using the first message to open the file and set the stream into the "file transfer" state. B> All subsequent messages arriving on the stream in this state are directly written to the appropriate file descriptor assigned to that stream. Stewart, et al. Expires September 30, 2011 [Page 5] Internet-Draft SCTP Reconf Use March 2011 C> If for some reason the file could not be opened or a write error in output of the data occurs, the receiver would request a incoming and outgoing stream reset to signal to the peer that an error occurred. D> In the file transfer state, the stream would continue to receive either messages (which would be written out) or a stream reset. The stream reset would indicate to the receiver that the stream is to be taken out of the file transfer state and the file is to be closed. E> At that point the stream is set back to the initial state and is available for any subsequent transfer. When a 'put' is requested by the client, no message need travel over the control stream 0. Instead the client would simply select an idle stream and send the same transfer message to the peer as the first stream sequence number 0 to the server. The server would react the same way that the client did above and follow similar procedures. It is also possible that one of the sides, when going to transfer a file, does not have any idle streams. In such a case the add stream capability can be used to add an additional stream resource. This allows a SCTP-FTP server and client to start with a minimal number of streams (2 at a minimum) and only expand the number of streams upon the demand of the user for parallel transfers. This example illustrates the use of two basic reconfiguration utilities. The add-stream and the stream-reset for SSN. The next example will illustrate some various uses of the multiple stream reset and the TSN/SSN reset capabilities. 3.2. Combining features to achieve redundancy Consider the following picture: +--------+ +---------+ | Host-A | | Host-A~ | +---+----+ +----+----+ | IP-A | IP-B | | +-------------+--------------+ | | IP-Z +------+----+ | Host-Peer | +-----------+ Stewart, et al. Expires September 30, 2011 [Page 6] Internet-Draft SCTP Reconf Use March 2011 Host-A and Host-Peer have an SCTP association between them. The association is between IP-A:NNNN and IP-Z:MMMMM. Now often times in such a situation it is desired to have Host-A~ backup Host-A in case of a fault in either the hardware or software of Host-A. A variety of methods have been used to do this in the past. One common method is that Host-A~ watches Host-A in some fashion via either specialized hardware of some sort of pinging mechanism. If Host-A~ sees that Host-A is down, it assumes the network identity of host A by adopting IP-A on its interface and sending a promiscuous ARP so that packets destined to IP-A end up at the backup (i.e. Host-A~). Now one problem with this is any TCP connection or SCTP association between Host-A and Host-Peer will need to be torn down and re- established. This, in some protocols, may have un-desireable side- effects (e.g. BGP). Some implementations have attempted to compensate for this by having additional connectivity between Host-A and Host-A~ and keeping track of sequence numbers at the transport layer as well as keeping track of application state (between the primary and backup application). Much of the transport state is stable but large parts of it also are transient. In SCTP's case TSN and Stream Sequence numbers may be changing quite rapidly and this takes away additional resources by generating additional traffic between Host-A and Host-A~. Add to this that the promiscuous ARP and assuming the network identity of the peer is in itself somewhat kludgy at best. Now consider a possible different scenario which can be used if we apply SCTP's address reconfiguration, SCTP Authentication and the Stream reconfiguration mechanisms. If the two servers (Host-A and Host-A~) will do the following every time they acquire a peer: 1) After association setup send the random keys (for AUTH), Vtags, Sequence numbers, stream sequence numbers and various SCTP PCB information to Host-A~. 2) The application can use an inter-SCTP association between IP-A and IP-B to send this information. This association can further be used to send any application state updates that are needed and both servers should be using the same port number NNNN. 3) If the application ever uses the stream reconfiguration mechanism, an updated stream reconfiguration sequence number must be sent to the backup peer over this association. But note these changes are hopefully far less frequent then changes to TSN or SSN's within the association to the Host-Peer. Stewart, et al. Expires September 30, 2011 [Page 7] Internet-Draft SCTP Reconf Use March 2011 4) The backup peer Host-A~ may wish to increase the SCTP heartbeat rate to a faster value so that normal SCTP mechanisms (although at a faster rate) can be used to detect peer association failure faster than normally would be detected (by Host-Peer). After this setup, if Host-A fails, Host-A~ would do the following: A) Immediately upon detecting host failure of Host-A, send an Address Reconfiguration [RFC5061] with the appropriate authentication [RFC4895] to Host-Peer. In this reconfiguration, Add IP-B first, followed by Delete IP-A. These two actions should be bundled in one reconfiguration message but the Add parameter must be first (otherwise the peer would reject the request). B) After the address reconfiguration successfully completes send a stream reconfiguration resetting the TSN and all SSN's. This is done with the TSN/SSN reconfiguration request. C) After completion the application should be able to continue to talk to Host-Peer over the same association. Asking for any reconfiguration (if needed) that the application would like with its peer (e.g. a BGP restart). An alternative to this strategy would be to use just SSN resets but this would place additional burden upon the synchronization between Host-A and Host-A~ in that the TSN sequence would need to be kept in sync in addition to the stream reconfiguration sequence space. This mechanism could then be used to provide a "friendly" takeover for redundancy purposes of a peer association with no down time. Other scenarios are also possible, for example an application may want to use similar mechanisms to hand off part of its load from one server to another while both are active i.e. not in a failure case. More Examples to come 4. Security Considerations TBD 5. IANA Considerations TBD Stewart, et al. Expires September 30, 2011 [Page 8] Internet-Draft SCTP Reconf Use March 2011 6. IPR Considerations An IPR disclosure will be forthcoming. 7. Acknowledgements 8. References 8.1. Normative references [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. 8.2. Informational References [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Randall R. Stewart Huawei Chapin, SC 29036 USA Email: randall@lakerest.net Stewart, et al. Expires September 30, 2011 [Page 9] Internet-Draft SCTP Reconf Use March 2011 Peter Lei Cisco Systems, Inc. 8735 West Higgins Road Suite 300 Chicago, IL 60631 USA Phone: Email: peterlei@cisco.com Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Stewart, et al. Expires September 30, 2011 [Page 10]