📄 rfc1241.txt
字号:
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 the
Encapsulator. If a Clear Datagram must be encapsulated and
decapsulated several times in order reach the destination, the Flow
ID may be different at each Encapsulator, but need not be. The Flow
ID acts as an index into a table of Encapsulation Header information
that is used to build the Encapsulation Header. Note that the
decision to make the Flow ID local to the Encapsulator is due to the
difficulty in choosing and maintaining globally unique identifiers.
The intermediate step of using a Flow ID entirely optional. The
important requirement is that all Encapsulators along a Flow map the
same Clear Header to the same Flow (which could be identified by
different identifiers along the way). However, by allowing for a
Woodburn & Mills [Page 6]
RFC 1241 Internet Encapsulation July 1991
Flow ID in the protocol, a more efficient implementation of the
mapping function becomes possible. This is discussed in more detail
when we consider the Decapsulator.
The following information is required to construct the Encapsulation
Header:
Flow ID -
This is the key for this table of information and
represents the Flow ID relative to the current
Encapsulator.
Decapsulator Address -
The IP address of the Decapsulator in the Encapsulation
Space must be known to build the IP portion of the
Encapsulation Header.
Decapsulator's Flow ID -
The Flow ID, if any, for the Flow as seen by the
Decapsulator must be known.
Previous Encapsulator's Address -
If this is not the first Encapsulator along the Flow, the
previous Encapsulator's address must be known for error
reporting.
Previous Encapsulator's Flow ID -
In addition to the previous Encapsulator's address, the
Flow ID of the Flow relative to the previous Encapsulator
must be known.
The Encapsulation Header consists of an IP Header as well as an
Encapsulation Protocol Header. The two pieces of information
required for the Encapsulation Protocol Header which must be
determined at the time of encapsulation are the protocol which is
being encapsulated and the Flow ID to send to the Decapsulator. The
generation of the IP header is more complicated.
There are two possible ways each field in the Clear Header could
related to the new IP header.
Copy -
Copy the existing field from the Clear Header to the IP
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 options
list. A summary of all possible IP fields and the relation to the
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 effect
on the Header Length of the new IP header. The fields which are more
interesting and require some thought are now discussed.
The Quality of Service bits should be copied from the Clear Header to
the new IP header. This is in keeping with the transparency
principle that if the User Space was providing a given service, then
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 of
the status of the encapsulated datagram. If the completed datagram
is too large for the interface, it will be fragmented for
transmission to the decapsulator by the normal IP fragmentation
mechanism.
The Don't Fragment bit should not be copied into the Encapsulation
Header. The transparency principle would again be violated. It
should be up to the Encapsulator to decide whether fragmentation
should be allowed across the Encapsulation Space. If it is decided
that the DF bit should be used, then ICMP message would be returned
if the Encapsulated Datagram required fragmentation across the
Encapsulation Space The mechanism for returning an ICMP message to
the source in the User space will have to be modified, however, and
this is discussed in the Appendix B.
Regarding the Time To Live (TTL) field, the easiest thing to do is to
ignore the TTL from the Clear Header. If this field were copied from
the Clear Header to the new IP header, the packet life might be
prematurely exceeded during transit in the Encapsulation Space. This
breaks the transparency rule of encapsulation as seen from the User
Space. The TTL of the Clear Header is decremented before
encapsulation by the IP forwarding function, so there is no chance of
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 Mappings
The protocol field for the new IP header should be filled with the
protocol number of the encapsulation protocol.
The source address in the new IP header becomes the IP address of the
Encapsulator in the Encapsulation Domain. The destination address
becomes the IP address of the Decapsulator as found in the
encapsulation table.
IP Options are generally not copied because most don't make sense in
the context of the Encapsulation Space, as the transparency principle
would indicate. The security option is probably the one option that
should get copied for the same reason QOS and precedence fields are
copied, the Encapsulation Space must provide the expected service.
Timestamp, Loose Source Route, Strict Source Route, and Record Route
are not copied during encapsulation.
6. Decapsulation
In the ideal situation, a Decapsulator receives an Encapsulated
Woodburn & Mills [Page 9]
RFC 1241 Internet Encapsulation July 1991
Datagram, strips off the Encapsulation Header and sends the Clear
Datagram back into IP so that it is forwarded from that point.
However, if the Clear Datagram has not reached the destination User
Space, it must again be encapsulated to move it close to the
destination User Space. In this latter case the Decapsulator would
become an Encapsulator and would perform the same calculation to
generate the Encapsulation Header as did the previous Encapsulator.
In order to make this process more efficient, the use of Flow IDs
have been incorporated into the protocol.
When Flow IDs are used, the Flow ID received in the Encapsulation
Header corresponds to a stored Flow ID in the Decapsulator. At this
point the Decapsulator has the option of bypassing the mask and match
operation on the Clear Header. The received Flow ID can be used to
point directly into the local Encapsulator tables for the
construction of the next Encapsulation Header. If the Flow ID is
unknown, an error message is sent back to the previous Encapsulator
to that effect and a signal is sent to upper layer entity managing
the encapsulation tables.
Because the normal IP forwarding mechanism is being bypassed when
Flow IDs are used, certain mechanisms normally handled by IP must be
taken care of by the Decapsulator before encapsulation. The
Decapsulator must decrement the TTL before the next encapsulation
occurs. If a Time Exceeded error occurs, then an ICMP message is
sent to the source indicated in the Clear Header.
7. Error Messages
There are two kinds of error message built into the encapsulation
protocol. The first is used to report unknown flow identifiers seen
by a Decapsulator and the second is for the forwarding of ICMP
messages.
When a Decapsulator is using the received Flow ID in an Encapsulation
Header to forward a datagram to the next Decapsulator in a Flow, it
is possible that the Flow ID may not be known. For this case the
Decapsulator will notify the previous Encapsulator that the Flow was
not known so that the problem may be reported to the layer
responsible for the programming of the Flow tables. This is
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 the
source Encapsulator. This is accomplished by the second kind of
error message. The ICMP message will contain the Flow ID of the
message which caused the error. This Flow ID must be translated to
the Flow ID relative to the Encapsulator to which the error message
Woodburn & Mills [Page 10]
RFC 1241 Internet Encapsulation July 1991
is sent.
If an error occurs while sending any error message, no further error
message are generated.
8. References
[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, September
1981.
[4] ORWG, Inter-Domain Policy Routing Protocol Specification and
Usage, Draft, August 1990
A. Packet Formats
This section describes the packet formats for the encapsulation
protocol.
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | HL | MT | RC | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. A.1. Encapsulation Protocol Header Example
Vers 4 bits The version number of the encapsulation
protocol. The version of the protocol
described by this document is 1.
HL 4 bits The header length of the Encapsulation
Protocol Header in octets.
MT 4 bits The message type of the Encapsulation
Protocol message. A data message has a
message type of 1. An error message has a
message type of 2.
RC 4 bits The reason code. This field is unused in the
Data Message and must have a value of 0. In
the Error Message it contains the reason code
for the Error Message. Defined reason code
Woodburn & Mills [Page 11]
RFC 1241 Internet Encapsulation July 1991
values are:
1 Unknown Flow ID
2 ICMP returned
Checksum 16 bits A one's complement checksum for the
Encapsulation Protocol Header. This field is
set to 0 upon calculation of the checksum and
is filled with the checksum calculation
result before the data message is sent.
Flow ID 32 bits The Flow ID as seen by the Decapsulator or
Encapsulator to which this message is being
sent. In the case of an Unknown Flow ID
error, the Flow ID causing the error is used.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -