Mapping the BEEP Core onto TCP
RFC 3081

Document Type RFC - Proposed Standard (March 2001; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3081 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            M. Rose
Request for Comments: 3081                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001

                     Mapping the BEEP Core onto TCP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo describes how a BEEP (Blocks Extensible Exchange Protocol)
   session is mapped onto a single TCP (Transmission Control Protocol)
   connection.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
   2.    Session Management . . . . . . . . . . . . . . . . . . . . . 2
   3.    Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
   3.1   Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.3 Processing SEQ Frames  . . . . . . . . . . . . . . . . . . . 4
   3.1.4 Use of Flow Control  . . . . . . . . . . . . . . . . . . . . 4
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 6
         References . . . . . . . . . . . . . . . . . . . . . . . . . 6
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 8

1. Introduction

   This memo describes how a BEEP [1] session is mapped onto a single
   TCP [2] connection.  Refer to Section 2.5 of [1] for an explanation
   of the mapping requirements.

Rose                        Standards Track                     [Page 1]
RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2. Session Management

   The mapping of BEEP session management onto the TCP service is
   straight-forward.

   A BEEP session is established when a TCP connection is established
   between two BEEP peers:

   o  the BEEP peer that issues a passive TCP OPEN call is termed the
      listener; and,

   o  the BEEP peer that issues an active TCP OPEN call is termed the
      initiator.

   A simultaneous TCP OPEN would result in both BEEP peers believing
   they are the initiator and neither peer will be able to start any
   channels.  Because of this, services based on BEEP must be designed
   so that simultaneous TCP OPENs cannot occur.

   If both peers agree to release a BEEP session (c.f., [1]'s Section
   2.4), the peer sending the "ok" reply, immediately issues the TCP
   CLOSE call.  Upon receiving the reply, the other peer immediately
   issues the TCP CLOSE call.

   A BEEP session is terminated when either peer issues the TCP ABORT
   call, and the TCP connection is subsequently aborted.

3. Message Exchange

   The mapping of BEEP exchanges onto the TCP service is less straight-
   forward.

   Messages are reliably sent and received using TCP's SEND and RECEIVE
   calls.  (This also provides ordered delivery of messages on the same
   channel.)

   Although TCP imposes flow control on a per-connection basis, if
   multiple channels are simultaneously in use on a BEEP session, BEEP
   must provide a mechanism to avoid starvation and deadlock.  To
   achieve this, BEEP re-introduces a mechanism used by the TCP:
   window-based flow control -- each channel has a sliding window that
   indicates the number of payload octets that a peer may transmit
   before receiving further permission.

Rose                        Standards Track                     [Page 2]
RFC 3081             Mapping the BEEP Core onto TCP           March 2001

3.1 Flow Control

   Recall from Section 2.2.1.2 of [1] that every payload octet sent in
   each direction on a channel has an associated sequence number.
   Numbering of payload octets within a data frame is such that the
   first payload octet is the lowest numbered, and the following payload
   octets are numbered consecutively.

   The actual sequence number space is finite, though very large,
   ranging from 0..4294967295 (2**32 - 1).  Since the space is finite,
   all arithmetic dealing with sequence numbers is performed modulo
   2**32.  This unsigned arithmetic preserves the relationship of
   sequence numbers as they cycle from 2**32 - 1 to 0 again.  Consult
   Sections 2 through 5 of [3] for a discussion of the arithmetic
   properties of sequence numbers.

3.1.1 Channel Creation

   When a channel is created, the sequence number associated with the
   first payload octet of the first data frame is 0, and the initial
Show full document text