Scheme for an internet encapsulation protocol: Version 1
RFC 1241
|
Document |
Type |
|
RFC - Experimental
(July 1991; No errata)
|
|
Authors |
|
Robert Woodburn
,
David Mills
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
ps
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1241 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Woodburn
Request for Comments: 1241 SAIC
D. Mills
University of Delaware
July 1991
A Scheme for an Internet Encapsulation Protocol:
Version 1
1. Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
2. Glossary
Clear Datagram -
The unmodified IP datagram in the User Space before
Encapsulation.
Clear Header -
The header portion of the Clear Datagram before
Encapsulation. This header includes the IP header and
possibly part or all of the next layer protocol header,
i.e., the TCP header.
Decapsulation -
The stripping of the Encapsulation Header and forwarding
of the Clear Datagram by the Decapsulator.
Decapsulator -
The entity responsible for receiving an Encapsulated
Datagram, decapsulating it, and delivering it to the
destination User Space. Delivery may be direct, or via
Encapsulation. A Decapsulator may be a host or a gateway.
Encapsulated Datagram -
The datagram consisting of a Clear Datagram prepended with
an Encapsulation Header.
Encapsulation -
The process of mapping a Clear Datagram to the
Encapsulation Space, prepending an Encapsulation Header to
the Clear Datagram and routing the Encapsulated Datagram
Woodburn & Mills [Page 1]
RFC 1241 Internet Encapsulation July 1991
to a Decapsulator.
Encapsulation Header -
The header for the Encapsulation Protocol prepended to the
Clear Datagram during Encapsulation. This header consists
of an IP header followed by an Encapsulation Protocol
Header.
Encapsulation Protocol Header -
The Encapsulation Protocol specific portion of the
Encapsulation Header.
Encapsulation Space -
The address and routing space within which the
Encapsulators and Decapsulators reside. Routing within
this space is accomplished via Flows. Encapsulation
Spaces do not overlap, that is, the address of any
Encapsulator or Decapsulator is unique for all
Encapsulation Spaces.
Encapsulator -
The entity responsible for mapping a given User Space
datagram to the Encapsulation Space, encapsulating the
datagram, and forwarding the Encapsulated Datagram to a
Decapsulator. An Encapsulator may be a host or a gateway.
Flow -
Also called a "tunnel." A flow is the end-to-end path in
the Encapsulation Space over which Encapsulated Datagrams
travel. There may be several Encapsulator/Decapsulator
pairs along a given flow. Note that a Flow does not
denote what User Space gateways are traversed along the
path.
Flow ID -
A 32-bit identifier which uniquely distinguishes a flow in
a given Encapsulator or Decapsulator. Flow IDs are
specific to a single Encapsulator/Decapsulator Entity and
are not global quantities.
Mapping Function -
This is the function of mapping a Clear Header to a
particular Flow. All encapsulators along a given Flow are
required to map a given Clear Header to the same Flow.
User Address -
The address or identifier uniquely identifying an entity
within a User Space.
Woodburn & Mills [Page 2]
RFC 1241 Internet Encapsulation July 1991
Source Route -
A complete end-to-end route which is computed at the
source and enumerates transit gateways.
User Space -
The address and routing space within which the users
reside. Routing within this space provides reachability
between all address pairs within the space. User Spaces
do not overlap, that is, a given User Address is unique in
all User Spaces.
3. Background
For several years researchers in the Internet community have needed a
means of "tunneling" between networks. A tunnel is essentially a
Source Route that circumvents conventional routing mechanisms.
Tunnels provide the means to bypass routing failures, avoid broken
gateways and routing domains, or establish deterministic paths for
experimentation.
There are several means of accomplishing tunneling. In the past,
tunneling has been accomplished through source routing options in the
IP header which allow gateways along a given path to be enumerated.
Show full document text