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]