As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group R.
Request for Comments: 1241
D.
University of
July 1991
A Scheme for an Internet Encapsulation Protocol
Version 1
1. Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
2.
Clear Datagram -
The unmodified IP datagram in the User Space
Encapsulation
Clear Header -
The header portion of the Clear Datagram
Encapsulation. This header includes the IP header
possibly part or all of the next layer protocol header
i.e., the TCP header
Decapsulation -
The stripping of the Encapsulation Header and
of the Clear Datagram by the Decapsulator
Decapsulator -
The entity responsible for receiving an
Datagram, decapsulating it, and delivering it to
destination User Space. Delivery may be direct, or
Encapsulation. A Decapsulator may be a host or a gateway
Encapsulated Datagram -
The datagram consisting of a Clear Datagram prepended
an Encapsulation Header
Encapsulation -
The process of mapping a Clear Datagram to
Encapsulation Space, prepending an Encapsulation Header
the Clear Datagram and routing the Encapsulated
Woodburn & Mills [Page 1]
RFC 1241 Internet Encapsulation July 1991
to a Decapsulator
Encapsulation Header -
The header for the Encapsulation Protocol prepended to
Clear Datagram during Encapsulation. This header
of an IP header followed by an Encapsulation
Header
Encapsulation Protocol Header -
The Encapsulation Protocol specific portion of
Encapsulation Header
Encapsulation Space -
The address and routing space within which
Encapsulators and Decapsulators reside. Routing
this space is accomplished via Flows.
Spaces do not overlap, that is, the address of
Encapsulator or Decapsulator is unique for
Encapsulation Spaces
Encapsulator -
The entity responsible for mapping a given User
datagram to the Encapsulation Space, encapsulating
datagram, and forwarding the Encapsulated Datagram to
Decapsulator. An Encapsulator may be a host or a gateway
Flow -
Also called a "tunnel." A flow is the end-to-end path
the Encapsulation Space over which Encapsulated
travel. There may be several Encapsulator/
pairs along a given flow. Note that a Flow does
denote what User Space gateways are traversed along
path
Flow ID -
A 32-bit identifier which uniquely distinguishes a flow
a given Encapsulator or Decapsulator. Flow IDs
specific to a single Encapsulator/Decapsulator Entity
are not global quantities
Mapping Function -
This is the function of mapping a Clear Header to
particular Flow. All encapsulators along a given Flow
required to map a given Clear Header to the same Flow
User Address -
The address or identifier uniquely identifying an
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
source and enumerates transit gateways
User Space -
The address and routing space within which the
reside. Routing within this space provides
between all address pairs within the space. User
do not overlap, that is, a given User Address is unique
all User Spaces
3.
For several years researchers in the Internet community have needed
means of "tunneling" between networks. A tunnel is essentially
Source Route that circumvents conventional routing mechanisms
Tunnels provide the means to bypass routing failures, avoid
gateways and routing domains, or establish deterministic paths
experimentation
There are several means of accomplishing tunneling. In the past
tunneling has been accomplished through source routing options in
IP header which allow gateways along a given path to be enumerated
The disadvantage of source routing in the IP header is that
requires the source to know something about the networks traversed
reach the destination. The source must then modify outgoing
to reflect the source route. Current routing
generally don't support source routes in their routing tables as
means of reaching an IP address, nor do current routing protocols
Another means of tunneling would be to develop a new IP option.
option field would be part of a separate IP header that could
prepended to an IP datagram. The IP option would
information about the original datagram. This tunneling option
the disadvantage of significantly modifying existing
implementations to handle a new IP option. It also would be
flexible in permitting the tunneling of other protocols, such as
protocols, through an IP environment. An even less
alternative would be to replace IP with a new networking protocol
a new version of IP with tunneling built in as part of
functionality
A final alternative is to create a new IP encapsulation
which uses the current IP header format. By using encapsulation,
destination can be reached transparently without the source having
know topology specifics. Virtual networks can be created by
otherwise unconnected machines together with flows through
encapsulation space
Woodburn & Mills [Page 3]
RFC 1241 Internet Encapsulation July 1991
++++++ Clear
******
#
Encapsulator/
& User Space
User Space A User Space
-------------- -----------
/ \ / \
/ \ / \
| | | |
| & | | |
| + +++++ | | ***** |
| +++++ + | | * * |
| + | | ***** * |
\ + / ----------- \ * * / ----------
\ ++> # * **> # * ***> # ++++ \
-------------- / * * \ ------------ / + \
| * * | | + |
| * * | | + |
| ***** * | | +++++++ |
| ***** | | V |
| | | & |
\ / \ /
\ / \ /
----------- ----------
Encapsulation
Space B Space
Fig. 1. Encapsulation Architectural
Up until now, there has been no standard for an
protocol. This RFC provides a means of performing encapsulation
the Internet environment
4. Architecture and
The architecture for encapsulation is based on two entities --
Encapsulator and a Decapsulator. These entities and the
spaces are shown in Fig. 1.
Encapsulators and Decapsulators have addresses in the User Spaces
which they belong, as well as addresses in the Encapsulation
to which they belong. An encapsulator will receive a Clear
Woodburn & Mills [Page 4]
RFC 1241 Internet Encapsulation July 1991
from its User Space, and after determining that encapsulation
be used, perform a mapping function which translates the User
information in the Clear Header to an Encapsulation Header.
Encapsulation Header is then prepended to the Clear Datagram to
the Encapsulated Datagram, as in Fig 2. It is desirable that
encapsulation process be transparent to entities in the User Space
Only the Encapsulator need know that encapsulation is occurring
+---------------+-----------------+--------+----------------+
| Encapsulating | Encapsulation | Clear | Remainder of |
| IP Header | Protocol Header | Header | Clear Datagram |
+---------------+-----------------+--------+----------------+
| | |
| Encapsulation Header | Clear Datagram |
| | |
Fig. 2. Example of an Encapsulated
The Encapsulator forwards the datagram to a Decapsulator
identity is determined at the time of encapsulation.
Decapsulator receives the Encapsulated Datagram and removes
Encapsulation Header and treats the Clear Datagram as if it
received locally. The requirement for the address of
Decapsulator is that it be reachable from the Encapsulator'
Encapsulation Space address
5. Generation of the Encapsulation
The contents of the Encapsulation Header are generated by
a mapping function from the Clear Header to the contents of
Encapsulation Header. This mapping function could take many forms
but the end result should be the same. The following
describe one method of performing the mapping. The process
illustrated in Fig. 3.
In the first part of the mapping function, the Clear Header
matched with stored headers and masks to determine a Flow ID.
is essentially a "mask-and-match" table look up, where the
table holds three entries, a Clear Header, a header mask, and
corresponding Flow ID. The mask can be used for allowing a range
source and destination addresses to map to a given flow.
fields, such as the IP TOS bits or even the TCP source or
port addresses could also be used to discriminate between Flows
This flexibility allows many possibilities for using the
function. Not only can a given network be associated with
particular flow, but even a particular TCP protocol or
Woodburn & Mills [Page 5]
RFC 1241 Internet Encapsulation July 1991
could be distinguished from another
How the lookup table is built and maintained is not part of
protocol. It is assumed that it is managed by some higher
entity. It would be sufficient to configure the tables from
text files if necessary
+--------+
| |
+->| Encap. |--+
| | Info. | |
+-------+ | | Table | |
| Mask | +---------+ | | | |
Clear --+-->| & |-->| Flow ID |---+ | | |
Header | | Match | +---------+ +--------+ |
| +-------+ |
| +-->
+----------------------------------------------->
Fig. 3. Generation of the Encapsulation
The Flow IDs are managed at a higher layer as well. An example
how Flow IDs can be managed is found in the Setup protocol of
Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The
layer protocol would be responsible for maintaining information
carried in the encapsulation protocol related to the flow.
could include the information necessary to construct
Encapsulation Header (described below) as well as information such
the type of data being encapsulated (currently only IP is defined),
and the type of authentication used if any. Note that IDPR
requires the use of a longer Flow ID which is unique for the
universe of Encapsulators and is the same at every Encapsulator
The Flow ID that results from the mapping of a Clear Header is a 32
bit quantity and identifies the Flow as it is seen by
Encapsulator. If a Clear Datagram must be encapsulated
decapsulated several times in order reach the destination, the
ID may be different at each Encapsulator, but need not be. The
ID acts as an index into a table of Encapsulation Header
that is used to build the Encapsulation Header. Note that
decision to make the Flow ID local to the Encapsulator is due to
difficulty in choosing and maintaining globally unique identifiers
The intermediate step of using a Flow ID entirely optional.
important requirement is that all Encapsulators along a Flow map
same Clear Header to the same Flow (which could be identified
different identifiers along the way). However, by allowing for
Woodburn & Mills [Page 6]
RFC 1241 Internet Encapsulation July 1991
Flow ID in the protocol, a more efficient implementation of
mapping function becomes possible. This is discussed in more
when we consider the Decapsulator
The following information is required to construct the
Header
Flow ID -
This is the key for this table of information
represents the Flow ID relative to the
Encapsulator
Decapsulator Address -
The IP address of the Decapsulator in the
Space must be known to build the IP portion of
Encapsulation Header
Decapsulator's Flow ID -
The Flow ID, if any, for the Flow as seen by
Decapsulator must be known
Previous Encapsulator's Address -
If this is not the first Encapsulator along the Flow,
previous Encapsulator's address must be known for
reporting
Previous Encapsulator's Flow ID -
In addition to the previous Encapsulator's address,
Flow ID of the Flow relative to the previous
must be known
The Encapsulation Header consists of an IP Header as well as
Encapsulation Protocol Header. The two pieces of
required for the Encapsulation Protocol Header which must
determined at the time of encapsulation are the protocol which
being encapsulated and the Flow ID to send to the Decapsulator.
generation of the IP header is more complicated
There are two possible ways each field in the Clear Header
related to the new IP header
Copy -
Copy the existing field from the Clear Header to the
header in the Encapsulation Header
Ignore -
The field may or may not have existed in the Clear Header
but does not apply to the new IP header
Woodburn & Mills [Page 7]
RFC 1241 Internet Encapsulation July 1991
The IP header has a fixed portion and a variable portion, the
list. A summary of all possible IP fields and the relation to
Clear Header follows in Table 1. [2]
Note that most of the fields in the Clear Header are simply ignored
Fields such as the Header Length in the Clear Header have no
on the Header Length of the new IP header. The fields which are
interesting and require some thought are now discussed
The Quality of Service bits should be copied from the Clear Header
the new IP header. This is in keeping with the
principle that if the User Space was providing a given service,
the Encapsulation Space must provide the same service
The More Fragments bit and Fragment Offset should not be copied
since the datagram being built is a complete datagram, regardless
the status of the encapsulated datagram. If the completed
is too large for the interface, it will be fragmented
transmission to the decapsulator by the normal IP
mechanism
The Don't Fragment bit should not be copied into the
Header. The transparency principle would again be violated.
should be up to the Encapsulator to decide whether
should be allowed across the Encapsulation Space. If it is
that the DF bit should be used, then ICMP message would be
if the Encapsulated Datagram required fragmentation across
Encapsulation Space The mechanism for returning an ICMP message
the source in the User space will have to be modified, however,
this is discussed in the Appendix B
Regarding the Time To Live (TTL) field, the easiest thing to do is
ignore the TTL from the Clear Header. If this field were copied
the Clear Header to the new IP header, the packet life might
prematurely exceeded during transit in the Encapsulation Space.
breaks the transparency rule of encapsulation as seen from the
Space. The TTL of the Clear Header is decremented
encapsulation by the IP forwarding function, so there is no chance
a packet looping forever if the links of a Flow form a loop
Woodburn & Mills [Page 8]
RFC 1241 Internet Encapsulation July 1991
+---------------------+---------+
| Field | Mapping |
+---------------------+---------+
| Version | Ignore |
| Header Length | Ignore |
| Precedence | Copy |
| QoS bits | Copy |
| Total Length | Ignore |
| Identification | Ignore |
| Don't Fragment Bit | Ignore |
| More Fragments Bit | Ignore |
| Fragment Offset | Ignore |
| Time to Live | Ignore |
| Protocol | Ignore |
| Header Checksum | Ignore |
| Source Address | Ignore |
| Destination Address | Ignore |
| End of Option List | Ignore |
| NOP Option | Ignore |
| Security Option | Copy |
| LSR Option | Ignore |
| SSR Option | Ignore |
| RR Option | Ignore |
| Stream ID Option | Ignore |
| Timestamp Option | Ignore |
+---------------------+---------+
Table 1. Summary of IP Header
The protocol field for the new IP header should be filled with
protocol number of the encapsulation protocol
The source address in the new IP header becomes the IP address of
Encapsulator in the Encapsulation Domain. The destination
becomes the IP address of the Decapsulator as found in
encapsulation table
IP Options are generally not copied because most don't make sense
the context of the Encapsulation Space, as the transparency
would indicate. The security option is probably the one option
should get copied for the same reason QOS and precedence fields
copied, the Encapsulation Space must provide the expected service
Timestamp, Loose Source Route, Strict Source Route, and Record
are not copied during encapsulation
6.
In the ideal situation, a Decapsulator receives an
Woodburn & Mills [Page 9]
RFC 1241 Internet Encapsulation July 1991
Datagram, strips off the Encapsulation Header and sends the
Datagram back into IP so that it is forwarded from that point
However, if the Clear Datagram has not reached the destination
Space, it must again be encapsulated to move it close to
destination User Space. In this latter case the Decapsulator
become an Encapsulator and would perform the same calculation
generate the Encapsulation Header as did the previous Encapsulator
In order to make this process more efficient, the use of Flow
have been incorporated into the protocol
When Flow IDs are used, the Flow ID received in the
Header corresponds to a stored Flow ID in the Decapsulator. At
point the Decapsulator has the option of bypassing the mask and
operation on the Clear Header. The received Flow ID can be used
point directly into the local Encapsulator tables for
construction of the next Encapsulation Header. If the Flow ID
unknown, an error message is sent back to the previous
to that effect and a signal is sent to upper layer entity
the encapsulation tables
Because the normal IP forwarding mechanism is being bypassed
Flow IDs are used, certain mechanisms normally handled by IP must
taken care of by the Decapsulator before encapsulation.
Decapsulator must decrement the TTL before the next
occurs. If a Time Exceeded error occurs, then an ICMP message
sent to the source indicated in the Clear Header
7. Error
There are two kinds of error message built into the
protocol. The first is used to report unknown flow identifiers
by a Decapsulator and the second is for the forwarding of
messages
When a Decapsulator is using the received Flow ID in an
Header to forward a datagram to the next Decapsulator in a Flow,
is possible that the Flow ID may not be known. For this case
Decapsulator will notify the previous Encapsulator that the Flow
not known so that the problem may be reported to the
responsible for the programming of the Flow tables. This
accomplished through an encapsulation error message
If an Encapsulator receives an ICMP messages regarding a given flow
this message should be forwarded backwards along the flow to
source Encapsulator. This is accomplished by the second kind
error message. The ICMP message will contain the Flow ID of
message which caused the error. This Flow ID must be translated
the Flow ID relative to the Encapsulator to which the error
Woodburn & Mills [Page 10]
RFC 1241 Internet Encapsulation July 1991
is sent
If an error occurs while sending any error message, no further
message are generated
8.
[1] J. Postel, Internet Control Message Protocol, RFC 792,
September 1981.
[2] J. Postel, Internet Protocol, RFC 791, September 1981.
[3] J. Postel, Transmission Control Protocol, RFC 793,
1981.
[4] ORWG, Inter-Domain Policy Routing Protocol Specification
Usage, Draft, August 1990
A. Packet
This section describes the packet formats for the
protocol
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | HL | MT | RC | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. A.1. Encapsulation Protocol Header
Vers 4 bits The version number of the
protocol. The version of the
described by this document is 1.
HL 4 bits The header length of the
Protocol Header in octets
MT 4 bits The message type of the
Protocol message. A data message has
message type of 1. An error message has
message type of 2.
RC 4 bits The reason code. This field is unused in
Data Message and must have a value of 0.
the Error Message it contains the reason
for the Error Message. Defined reason
Woodburn & Mills [Page 11]
RFC 1241 Internet Encapsulation July 1991
values are
1 Unknown Flow
2 ICMP
Checksum 16 bits A one's complement checksum for
Encapsulation Protocol Header. This field
set to 0 upon calculation of the checksum
is filled with the checksum
result before the data message is sent
Flow ID 32 bits The Flow ID as seen by the Decapsulator
Encapsulator to which this message is
sent. In the case of an Unknown Flow
error, the Flow ID causing the error is used
For Data Messages, the Encapsulation Protocol Header is followed by
Clear Datagram. For Error Messages, the header is followed by the
message being forwarded along a flow
B. Encapsulation and Existing IP
This section discusses in detail the effect of this
protocol upon the existing mechanisms available with IP and some
possible effects of IP mechanisms upon this protocol.
these are Fragmentation and ICMP messages
B.1 Fragmentation and Maximum Transmission
An immediate concern of using an encapsulation mechanism is that
restrictions based upon MTU size. The source of a Clear Datagram
going to generate packets consistent with MTU of the interface
which datagram is transmitted. If these packets reach
Encapsulator and are encapsulated, they may be fragmented if they
larger than the MTU of the Encapsulator, even though the
interfaces of the source and Encapsulator may have the same MTU
Because the Encapsulated Datagram is sent to the Decapsulator
IP, there is no problem in allowing IP to perform fragmentation
reassembly. However, fragmentation is known to be inefficient and
generally avoided. Because a new header is being prepended to
Clear Datagram by the encapsulation process, the likelihood
fragmentation occurring is increased. If the Encapsulator decides
disallow fragmentation through the Encapsulation Space, it must
an ICMP message back to the source. This means that the MTU of
interface in the encapsulation space is effectively smaller than
of the physical MTU of the interface
Fragmentation by intermediate User Space Gateways introduces
Woodburn & Mills [Page 12]
RFC 1241 Internet Encapsulation July 1991
problem. Fragmentation occurs at the IP level. If a TCP protocol
in use and fragmentation occurs, the TCP header is contained in
first fragment, but not the following fragments. [3] If
fragments are forwarded by an Encapsulator, discrimination of
Clear Header for a given flow will only be able to occur on the
header portion of the Clear Header. If discrimination is
on the TCP portion of the header, then only the first fragment
be matched, while remaining fragments will not
B.2 ICMP
The most controversial aspect of encapsulation is the handling
ICMP messages. [1] Because the Encapsulation Header contains
source address of the Encapsulator in the Encapsulation Space,
messages which occur within the Encapsulation Space will be sent
to the Encapsulator. Once the Encapsulator receives the
message, the question is what should the next action be. Since
original source of the Clear Datagram knows nothing about
Encapsulation Space, it does not make sense to forward an
message on to it and ICMP message are not supposed to beget
messages. Yet not sending the original source something may
some important mechanisms
In addition to deciding what to forward to the source of the
Datagram, there is the problem of possibly not having
information to send anything at all back to the source. An
message returns the header of the offending message and the
eight octets of the data after the header. For the case of
encapsulation protocol, this translates to the IP portion of
Encapsulation Header, the first eight octets of the
Protocol Header, and nothing else. The contents of the
Datagram are completely lost. Therefore, for the Encapsulator
send an ICMP message back to the source it has to reconstruct
Clear Header. However, it is essentially impossible to reproduce
exact header
For the purpose of this specification, the Flow ID has been
to be a unique one way mapping from a Clear Header. There is
guarantee that the Flow ID could be used to map back to the
Header, since several headers potentially map to the same flow.
there being no effective way to regenerate the original datagram
some compromises must be examined
For each of the possible ICMP messages, the alternatives and
will be assessed. There are three categories of ICMP
involved. The first is those ICMP messages which are not
in the context of Encapsulation. These are: Echo/Echo Reply
Timestamp/Timestamp Reply
Woodburn & Mills [Page 13]
RFC 1241 Internet Encapsulation July 1991
The second category are those ICMP messages which concern
local to the encapsulation domain. These are messages which
not make sense to the original source if it did receive them.
these cases the encapsulator will have to decide what to do, but
ICMP message need be sent back to the original source. The
will simply be lost, IP is not meant to be a reliable protocol
Subsequent messages received for encapsulation may cause
encapsulator to generate ICMP Destination Unreachable messages
to the original source if the encapsulator can no longer
messages to the destination decapsulator. This requires that
messages inside the encapsulation domain affect the mapping from
Flow ID. ICMP messages in the second category are:
Problem, Redirect, Destination Unreachable, Time Exceeded
Finally there is one ICMP message which has direct bearing on
operation of the original source of datagrams destined
encapsulation, the ICMP Source Quench message. The only
mechanism available to the Encapsulator to handle this message is
the source quench message set a flag for the offending Flow ID
that subsequent messages that map the Flow cause the generation of
source quench back to the original source before the datagram
encapsulated
This last mechanism may be a solution for the more general problem
The rule of thumb could be that when an ICMP message is received
a given flow, then flag the Flow so that then next
encapsulated will cause the next message encapsulated on that flow
force an ICMP message to the source. After the ICMP message is
to the source, the mechanism could be reset. This would
cause every other packet to receive an ICMP message if there were
persistent problem. This mechanism is probably only safe
Unreachable messages and Source Quench
C. Reception of Clear
In order to use the encapsulation protocol a modification is
to IP forwarding. There must be some way for the IP module in
system to pass Clear Datagrams to the encapsulation protocol.
suggested means of doing this is to make an addition to a system'
routing table structures. A flag could be added to a route
tells the forwarding function to use encapsulation. Note that
default route could also be set to use encapsulation
With this mechanism in place, a system's IP forwarding
would examine its routing tables to try and match the IP
to a specific route. If a route was found, it would be then
to see if encapsulation should be used. If not the packet would
handled normally. If encapsulation was turned on for the route,
Woodburn & Mills [Page 14]
RFC 1241 Internet Encapsulation July 1991
the datagram would be sent to encapsulation for forwarding
In addition to snagging packets as they are forwarded,
must be done at the last Decapsulator on a given flow so
packets that are decapsulated are properly dumped into the
module for delivery. Because the packets are encapsulated
before forwarding, it should be a simple matter for
datagrams to be injected into the output portion of IP. However,
source address in the Clear Header must not change. The
must remain the address of the source in the source User Space
not be overwritten with that of the Decapsulator
D. Construction of Virtual Networks with
Because of the modification to the routing table to
encapsulation, it becomes possible to specify a virtual
whose sole purpose is encapsulation. Using this mechanism, it
become possible to link topologically distant entities with Flows
This would allow the construction of a Virtual Network which
overlay the actual routing topology. An example of such a
network is shown in Fig. 4.
Woodburn & Mills [Page 15]
RFC 1241 Internet Encapsulation July 1991
++++++ Virtual Network
****** Virtual Network
# Encapsulator/
------ Common Routing
------------ ------------
/ \ / \
/ +++ # \ / \
| # +++ + | | # ***** # |
| + + | | * * |
| + + | | * * |
| + + | | * * |
| # ++++ # + | | * * |
\ + / ------------- \ # ** / ---------
\ + # ++ \ # ****** *** # ** \
------------ / +++ * ------------ / *** \
| # * | | # *** #|
| + ** | | * *|
| + # | | * ** |
| + ++++ * | | * * |
| #+ * | | * * |
------------ \ ++++ */ ------------ \ * # /
/ \ # + # ** * # ***** /
/ + ------------- / # ****** # *\ --------
| # +++++++ +| | * * |
| + + + | | * * |
| + # | | * * |
| + ++ | | * # |
| # ++++++ | | * ********* |
\ / \ # /
\ / \ /
------------ ------------
Fig. 4. Virtual Networks
Each Encapsulator shown has an virtual interface on one of
virtual networks. The lines represent individual links in the
that connect each member of the virtual network. Note that new
could be added between any points as long as the two entities
visible to each other in a common Encapsulation Space. The
within the virtual network would be handled by the
mechanism. The programming of the routing tables could be a
of any of the currently existing routing protocols, an
OSPF for example
With this in mind, it would be possible to have special
gateways with virtual interfaces on two virtual networks to form
Woodburn & Mills [Page 16]
RFC 1241 Internet Encapsulation July 1991
entire virtual internet. This is the role of the
joining Virtual Network A and Virtual Network B
E. Encapsulation and
It is intended that the encapsulation mechanism described in the
be extensible to other environments outside of the Internet.
should be possible to encapsulate many different protocols within
and IP within many other protocols
The key concepts defined in this memo are the mapping of a header
a Flow ID and the mapping of fields in the original header to
encapsulating header. Special mappings between protocols would
to be defined, i.e. for the QoS bits, and some sort of translation
meanings carefully crafted, but it would be possible, none the less
F. Security
No means of authentication or integrity checking is
defined for this protocol apart from the checksum for the
information. However for authentication or integrity checking to
used with this protocol, it is suggested that the
information be appended to the Encapsulated Datagram.
regarding the type of authentication or integrity check in use
have to be included in the flow management protocol which is used
distribute the flow information
G. Authors'
Robert A.
8619 Westwood Center
Vienna, VA 22182
Phone: (703) 734-9000 or (703) 448-0210
EMail: woody@cseic.saic.
David L.
Electrical Engineering
University of
Newark, DE 19716
Phone: (302) 451-8247
EMail: mills@udel.
Woodburn & Mills [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
