Network Working Group M. Rose Internet-Draft Invisible Worlds, Inc. Expires: January 18, 2002 P. Conrad Temple University July 20, 2001 Mapping the BEEP Framework onto SCTP draft-mrose-beep-sctpmapping-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes how a BEEP session is mapped onto the Stream Control Transmission Protocol. Rose & Conrad Expires January 18, 2002 [Page 1] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Session Management . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 6 5. Special Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 A. Changes from draft-mrose-beep-sctpmapping-01 . . . . . . . . . 10 B. Changes from draft-mrose-beep-sctpmapping-00 . . . . . . . . . 11 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 Rose & Conrad Expires January 18, 2002 [Page 2] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 1. Introduction This memo describes how a BEEP [1] session is mapped onto the Stream Control Transmission Protocol [3]. Refer to Section 2.5 of [1] for an explanation of the mapping requirements. Rose & Conrad Expires January 18, 2002 [Page 3] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [4] Rose & Conrad Expires January 18, 2002 [Page 4] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 3. Session Management The mapping of BEEP session management onto the SCTP service is straight-forward. A BEEP session is established when a SCTP association is established between two BEEP peers: o the BEEP peer that issues an ASSOCIATE call is termed the initiator; and, o the BEEP peer that receives a COMMUNICATIONS UP notification is termed the listener. During association establishment, both BEEP peers request as many outbound SCTP streams as possible. A BEEP session is released when either peer issues the SHUTDOWN call, and the SCTP association is subsequently terminated. A BEEP session is terminated when either peer issues the CLOSE call, and the SCTP association is subsequently aborted. Rose & Conrad Expires January 18, 2002 [Page 5] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 4. Message Exchange The mapping of BEEP exchanges onto the SCTP service is straight- forward. Messages on a given channel are reliably sent and received using the SEND and RECEIVE calls: o the mapping between BEEP channel numbers and SCTP stream identifiers is the identity function; and, o the "unorder" flag is not present to provide orderly delivery of messages on the same BEEP channel. When BEEP is mapped over SCTP, the underlying SCTP implementation MUST support the the extensions for stream flow limits. [5] This requirement arises because the transport layer window space is shared across multiple streams; a per-stream flow control window is needed to avoid starvation and deadlock when multiple channels are used simultaneously on a BEEP session. In the mapping of BEEP over a single TCP connection [2], SEQ frames are used to manage a sliding window for each channel. In the BEEP over SCTP mapping, SEQ frames are not used. Instead, upon channel creation, the BEEP peer should set the stream byte limit [5] to the amount of buffer space set aside for that channel (not less than 4096 bytes.) Rose & Conrad Expires January 18, 2002 [Page 6] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 5. Special Behavior If use of a transport security profile is negotiated, then in addition to be used over BEEP channel (SCTP stream) zero, each time a BEEP channel is created, a new transport security context must be negotiated over the underlying SCTP stream. Rose & Conrad Expires January 18, 2002 [Page 7] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 6. Security Considerations Consult Section [1]'s Section 9 for a discussion of security issues. Rose & Conrad Expires January 18, 2002 [Page 8] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 References [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [2] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [3] 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. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I. and P. Conrad, "SCTP Extensions for Dynamic Reconfiguration of IP Addresses and Enforcement of Flow and Message Limits", Internet Draft draft-ietf-tsvwg-addip-sctp-02.txt, June 2001. Authors' Addresses Marshall T. Rose Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: mrose@invisible.net URI: http://invisible.net/ P.T. Conrad Temple University CIS Dept., Wachman Hall 303 1805. N. Broad St Philadelphia, PA 19122 US Phone: +1 215 204 7910 EMail: conrad@acm.org URI: http://netlab.cis.temple.edu Rose & Conrad Expires January 18, 2002 [Page 9] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 Appendix A. Changes from draft-mrose-beep-sctpmapping-01 o Added reference to extensions for SCTP stream flow limits. Rose & Conrad Expires January 18, 2002 [Page 10] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 Appendix B. Changes from draft-mrose-beep-sctpmapping-00 o s/BXXP/BEEP/g Rose & Conrad Expires January 18, 2002 [Page 11] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 Appendix C. Acknowledgements The authors gratefully acknowledge the contributions of: Vern Paxon. Rose & Conrad Expires January 18, 2002 [Page 12] Internet-Draft Mapping the BEEP Framework onto SCTP July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rose & Conrad Expires January 18, 2002 [Page 13]