Browse Prior Art Database

Mutual Encapsulation Considered Dangerous (RFC1326)

IP.com Disclosure Number: IPCOM000002148D
Original Publication Date: 1992-May-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 4 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Tsuchiya: AUTHOR

Abstract

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).

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

Network Working Group P. Tsuchiya

Request for Comments: 1326 Bellcore

May 1992

Mutual Encapsulation Considered Dangerous

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard. Distribution of this memo is

unlimited.

Abstract

This memo describes a packet explosion problem that can occur with

mutual encapsulation of protocols (A encapsulates B and B

encapsulates A).

The Current Environment

In spite of international standardization efforts to the contrary, we

are these days seeing a plethora of different protocols, both

standard and proprietary, each designed to fill a technical or

marketing niche. The end result is that they eventually butt up

against each other and are expected to interwork in some fashion.

One approach to this interworking is to encapsulate one protocol

within another. This has resulted in cases of mutual encapsulation,

where protocol A runs over protocol B in some cases, and protocol B

runs over protocol A in other cases. For example, there exists cases

of both IP over AppleTalk and AppleTalk over IP. (The term mutual

encapsulation comes from the paper by Shoch, Cohen, and Taft, called

Mutual Encapsulation of Internetwork Protocols", Computer Networks 5,

North-Holland, 1981, 287-300. The problem identified in this RFC is

not mentioned in the Shoch et. al. paper.)

If there are not already other instances of mutual encapsulation,

there will likely be more in the future. This is particularly true

with respect to the various internet protocols, such as IP, CLNP,

AppleTalk, IPX, DECNET, and so on.

The Problem

The problem with mutual encapsulation is the following. Consider the

topology shown in Figure 1. We see two backbones and four stubs.

Backbone B(X) uses a native protocol of X (that is, it expects to

receive packets with a header for protocol X). B(Y) uses a native

protocol of Y. Likewise, the right and left S(Y) stubs use protocol

Y, and the right and left S(X) stubs use protocol X.

::: ::::: ::::: ::: :::

+------+ :Y :X:Y +------+ :X:Y :Y +------+ :Y +------+

| | ::: ::::: | | ::::: ::: | | ::: | |

| S(Y) |-----Ra-----| |-------Rb----| |------| S(Y) |

| | | | | | | |

+------+ | | | | +------+

| B(X) | | B(Y) |

...