Browse Prior Art Database

Mapping the BEEP Core onto TCP (RFC3081)

IP.com Disclosure Number: IPCOM000005275D
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2001-Aug-20
Document File: 9 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Rose: AUTHOR

Abstract

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

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 23% of the total text.

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 subsequent...