One document matched: draft-templin-intarea-seal-re-02.txt
Differences from draft-templin-intarea-seal-re-01.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track January 8, 2010
Expires: July 12, 2010
SEAL with Reliability Extensions (SEAL-RE)
draft-templin-intarea-seal-re-02.txt
Abstract
The Subnetwork Encapsulation and Adaptation Layer (SEAL) includes two
basic modes of operation known as "SEAL with Fragmentation Sensing
(SEAL-FS)" and "SEAL with Traffic Engineering (SEAL-TE)". This
document specifies an additional mode known as "SEAL with Reliability
Extensions (SEAL-RE)".
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Templin Expires July 12, 2010 [Page 1]
Internet-Draft SEAL-RE and SEAL-IV January 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements . . . . . . . . . . . . . . . . . 4
3. SEAL with Reliability Extensions (SEAL-RE) Protocol
Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SEAL-RE Message Format . . . . . . . . . . . . . . . . . . 4
3.2. Integrity Check Calculation and Packet Transmission . . . 5
3.3. Integriy Check Verification and Decapsulation . . . . . . 6
3.4. Segment Acknowledgement and Retransmission . . . . . . . . 7
3.4.1. ITE Behavior . . . . . . . . . . . . . . . . . . . . . 7
3.4.2. ETE Behavior . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Templin Expires July 12, 2010 [Page 2]
Internet-Draft SEAL-RE and SEAL-IV January 2010
1. Introduction
The Subnetwork Encapsulation and Adaptation Layer (SEAL)
[I-D.templin-intarea-seal] includes two basic modes of operation
known as "SEAL with Fragmentation Sensing (SEAL-FS)" and "SEAL with
Segmentation and Reassembly (SEAL-SR)". Both modes are used for
determining the maximum packet size (also known as the Maximum
Transmission Unit (MTU)) that can traverse the tunnel without loss
due to size restrictions.
SEAL-FS provides a minimal mechanism through which an egress tunnel
endpoint (ETE) acts as a passive observer that simply informs the
ingress tunnel endpoint (ITE) of any IP fragmentation experienced
within the tunnel. SEAL-FS therefore determines the tunnel Maximum
Transmission Unit (MTU) based on the MTU of the smallest link in the
path. It is useful for determining an appropriate MTU for tunnels
between performance-critical routers over robust links, as well as
for other uses in which packet segmentation and reassembly would
present too great of a burden for the routers or end systems.
SEAL-SR is a functional superset of SEAL-FS, and requires that the
tunnel endpoints support segmentation and reassembly of packets that
are too large to traverse the tunnel without fragmentation. SEAL-SR
determines the tunnel MTU based on the largest packet the ETE is
capable of receiving rather than on the MTU of the smallest link in
the path. Therefore, SEAL-SR can transport packets that are much
larger than the underlying links themselves can carry without
fragmentation.
This document specifies an additional mode of operation known as
"SEAL with Reliability Extensions (SEAL-RE)". SEAL-RE is a
functional superset of SEAL-SR, and adds an Automatic Repeat reQuest
(ARQ) capability for timely retransmission of lost segments as well
as an Integrity Check Vector (ICV) used for detecting packet splicing
errors and bit errors that were not detected by link-layer integrity
checks. SEAL-RE is designed for use in environments with non-
negligible loss rates due to, e.g., interference, link errors,
congestion, etc. Examples include certain Mobile Ad-hoc Networks
(MANETs), low-end wireless networks, aviation data links, sensor
networks, etc.
The use of SEAL-RE is naturally negotiated between tunnel endpoints;
when the ITE attempts to use SEAL-RE, the ETE responds with its
support or non-support for the SEAL-RE mode of operations. As for
the other two modes of operation, SEAL-RE is designed for use with
Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet] and
Routing and Addressing in Next-Generation EnteRprises (RANGER)
[I-D.templin-ranger][I-D.russert-rangers]. The following sections
Templin Expires July 12, 2010 [Page 3]
Internet-Draft SEAL-RE and SEAL-IV January 2010
discuss SEAL-RE.
2. Terminology and Requirements
The terminology of SEAL [I-D.templin-intarea-seal] applies to this
document.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. SEAL with Reliability Extensions (SEAL-RE) Protocol Specification
SEAL-RE obeys the SEAL-SR protocol specification found in Section 4
of [I-D.templin-intarea-seal], however when SEAL-RE is used the ITE
further includes a 16-bit Integrity Check Vector (ICV) as a trailing
checksum that must be verified by the ETE. Additionally, the SEAL-RE
ETE returns a "Reassembly Report - Segment Bitmap" instead of a
"Reassembly Report - Segment Acknowledged" SEAL control message when
the ITE sets A='1' and MOD='2' in a SEAL data packet.
To enable SEAL-RE operation, the ITE simply sets the MOD field in the
header of each data packet to the value '2'. If the ETE does not
implement the SEAL-RE protocol, it will return a SEAL Parameter
Problem message with pointer set to the MOD field. A natural
progression of operations may entail the ITE beginning in SEAL-SR
mode (i.e., with MOD='1') and shifting to SEAL-RE mode (i.e., with
MOD='2') when conditions suggest the need for enhanced reliability.
The following sections discuss operational details of the SEAL-RE
protocol.
3.1. SEAL-RE Message Format
Section 4.1 of [I-D.templin-intarea-seal] shows the SEAL
encapsulation format used for SEAL-FS and SEAL-SR. SEAL-RE uses the
same encapsulation format except that the ITE adds a trailing 2-byte
Integrity Check Vector (ICV) immediately following any mid-layer
trailers. The ICV then becomes an extension of the mid-layer packet,
and therefore appears only once in each mid-layer packet and not once
for each SEAL segment. The SEAL-RE message format is shown in
Figure 1:
Templin Expires July 12, 2010 [Page 4]
Internet-Draft SEAL-RE and SEAL-IV January 2010
+-------------------------+
| |
~ Outer */IPv4 headers ~
| |
I +-------------------------+
n | SEAL Header |
n +-------------------------+ +-------------------------+
e ~ Any mid-layer * headers ~ ~ Any mid-layer * headers ~
r +-------------------------+ +-------------------------+
| | | |
I --> ~ Inner IP ~ --> ~ Inner IP ~
P --> ~ Packet ~ --> ~ Packet ~
| | | |
P +-------------------------+ +-------------------------+
a ~ Any mid-layer trailers ~ ~ Any mid-layer trailers ~
c +-------------+-----------+ +-------------+-----------+
k | 16-bit ICV | | 16-bit ICV | |
e +-------------+ +-------------+ ~
t ~ Any outer trailers ~
+-------------------------+
(After mid-layer encaps.) (After SEAL/*/IPv4 encaps.)
Figure 1: SEAL-RE Encapsulation
Note that the diagram above shows the case of a mid-layer packet
(plus trailing ICV) encapsulated in a single SEAL segment. When
multiple SEAL segments are required, the first segment contains the
leading portion of the mid-layer packet, the second segment contains
the second portion of the mid-layer packet, etc., and the final
segment contains the final portion of the mid-layer packet including
the ICV.
3.2. Integrity Check Calculation and Packet Transmission
After the ITE admits an inner packet into the tunnel as specified in
Sections 4.3.1 and 4.3.2 of [I-D.templin-intarea-seal], it
encapsulates the packet in mid-layer headers and trailers the same as
specified in Section 4.3.3 of [I-D.templin-intarea-seal] but also
includes a two byte ICV field at the end of the packet as shown in
Figure 1. The ITE next calculates a 16-bit checksum of the mid-layer
packet using the Fletcher Checksum algorithm specified in Appendix I
of [RFC1146], then writes the A portion of the checksum in the most-
significant byte of the ICV and writes the B portion in the least
significant byte.
The ITE next performs SEAL segmentation, encapsulation and packet
transmission as specified in the remaining subsections of Section 4.3
Templin Expires July 12, 2010 [Page 5]
Internet-Draft SEAL-RE and SEAL-IV January 2010
of [I-D.templin-intarea-seal]. The ITE uses the SEAL-SR header
format specified in Section 4.2 of [I-D.templin-intarea-seal], except
that it writes the value '2' instead of '1' in the MOD field of each
SEAL segment.
In response to any SEAL-RE packets it sends, the ITE may receive
"Reassembly Report - Checksum Incorrect" messages from the ETE (see
Section 3.3). The ITE MAY consider these messages as indication that
it should adjust its SEAL segmentation parameters and/or packet
transmission strategy.
3.3. Integriy Check Verification and Decapsulation
When the ETE reassembles a SEAL packet with the value '2' in the MOD
field of each SEAL segment, it examines the ICV encoded in the final
two bytes of the mid-layer packet and verifies that the checksum is
correct by applying the Fletcher Checksum algorithm specified in
Appendix I of [RFC1146]. (If the MOD field values of segments of the
same SEAL packet disagree, the ETE instead discards the packet
following reassembly.) If the checksum is correct, the ETE discards
the trailing checksum field then decapsulates the packet and delivers
it to upper layers as specified in Section 4.4.4 of
[I-D.templin-intarea-seal].
If the ETE determines that the checksum value encoded in the ICV does
not match the checksum calculated across the mid-layer packet, it
discards the packet and sends a "Reassembly Report - Checksum
Incorrect" message to the ITE subject to rate limiting. The ETE
prepares the message exactly as for other SEAL Control Messages as
specified in Section 4.4.5 of [I-D.templin-intarea-seal], and sets
Type=0 (i.e., Reassembly Report) and Code=4 (i.e., Checksum
Incorrect). The message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Code=4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
~ as possible without the message ~
| exceeding 576 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Checksum Incorrect Message Format
The ETE writes the maximum-sized packet it is willing to receive from
Templin Expires July 12, 2010 [Page 6]
Internet-Draft SEAL-RE and SEAL-IV January 2010
this ITE in a 32-bit S_MRU field ( a value of zero in this field
means that S_MRU is not specified in this message). The ETE then
writes as much of the invoking packet in the reassembly buffer as
possible at the end of the message body, adds the encapsulating
headers and trailers, and sends the message to the ITE.
3.4. Segment Acknowledgement and Retransmission
In addition to integrity verification, the SEAL-RE ITE and ETE also
engage in segment acknowledgement and retransmission of missing
segments. The following sections describe the ITE and ETE behavior.
3.4.1. ITE Behavior
When the ITE uses SEAL-RE mode, it should maintain a cache of the
most recent SEAL segments that it sent to the ETE. The ITE should
also periodically set A='1' in the SEAL header of a segment to
solicit a "Reassembly Report - Segment Bitmap" message from the ETE
(see Section 3.4.2). When the ITE receives a Segment Bitmap message,
it can use the bitmap to determine which (if any) of the cached
segments should be retransmitted.
3.4.2. ETE Behavior
ETEs that implement SEAL-RE should maintain reassembly buffering
proportional to the tunnel's (bandwidth*delay) product so that
reassembled packets can be forwarded in the proper order in case the
ITE will perform retransmission of missing segments.
When the ETE receives a SEAL data packet with A='1' and MOD='2', it
prepares a "Reassembly Report - Segment Bitmap" message. The ETE
prepares the message exactly as for other SEAL Control Messages as
specified in Section 4.4.5 of [I-D.templin-intarea-seal], and sets
Type=0 (i.e., Reassembly Report) and Code=5 (i.e., Segment Bitmap).
The message is formatted as follows:
Templin Expires July 12, 2010 [Page 7]
Internet-Draft SEAL-RE and SEAL-IV January 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Code=5 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
~ as possible without the message ~
| exceeding 576 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Segment Bitmap Message Format
The ETE writes the maximum-sized packet it is willing to receive from
this ITE in a 32-bit S_MRU field ( a value of zero in this field
means that S_MRU is not specified in this message). For this segment
and each of the 127 preceding segments, the ETE then sets the
corresponding bit in the Bitmap to the value 1 if the segment was
received and the value 0 if the segment was not received.
The most significant bit in the Bitmap corresponds to the current
segment (i.e., segment N), the next-most significant bit corresponds
to segment (N-1), etc., and the final bit in the bitmap corresponds
to segment (N-127). (Note that modulo arithmetic based on the length
of the SEAL_ID field is used). If the ETE does not have sufficient
short-term segment reception history (e.g., the ETE has received less
than 128 packets from this ITE), it marks each unknown segment as
received.
For example, when the ETE receives a SEAL segment with A='1', MOD='2'
and SEAL_ID=1500, it prepares a Segment Bitmap message with a 128 bit
Bitmap set to '10110011 ... (etc)' to denote that segments 1500,
1498, 1497, 1494, 1493, etc. were received, while segments 1499,
1496, 1495, etc. were missing.
After preparing the Bitmap, the ETE then writes as much of the
invoking packet in the reassembly buffer as possible at the end of
the message body, adds the encapsulating headers and trailers, and
sends the message to the ITE.
4. IANA Considerations
The IANA is instructed to designate the value '2' as the SEAL Mode
number for SEAL-RE in the "SEAL Protocol" registry.
Templin Expires July 12, 2010 [Page 8]
Internet-Draft SEAL-RE and SEAL-IV January 2010
The IANA is instructed to designate the values (Type=0; Code=4) for
the "Reassembly Report - Checksum Incorrect" message in the "SEAL
Protocol" registry.
The IANA is instructed to designate the values (Type=0; Code=5) for
the "Reassembly Report - Segment Bitmap" message in the "SEAL
Protocol" registry.
5. Security Considerations
The security considerations in [I-D.templin-intarea-seal] apply also
to SEAL-RE.
6. Related Work
[RFC3366] provides advice to link designers on link Automatic Repeat
reQuest (ARQ).
Similar mechanisms are found in
'draft-thubert-6lowpan-semple-fragment-recovery' and certainly also
in numerous other references.
7. Acknowledgments
This work represents concepts that have evolved through the helpful
insights of numerous colleagues.
8. References
8.1. Normative References
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-07 (work in
progress), October 2009.
[RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum
options", RFC 1146, March 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Templin Expires July 12, 2010 [Page 9]
Internet-Draft SEAL-RE and SEAL-IV January 2010
8.2. Informative References
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-01 (work in progress),
September 2009.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-05 (work in progress),
December 2009.
[I-D.templin-ranger]
Templin, F., "Routing and Addressing in Next-Generation
EnteRprises (RANGER)", draft-templin-ranger-09 (work in
progress), October 2009.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 12, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 08:29:31 |