One document matched: draft-templin-intarea-seal-re-01.txt
Differences from draft-templin-intarea-seal-re-00.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track July 6, 2009
Expires: January 7, 2010
SEAL with Reliability Extensions (SEAL-RE)
draft-templin-intarea-seal-re-01.txt
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 January 7, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
Templin Expires January 7, 2010 [Page 1]
Internet-Draft SEAL-RE and SEAL-IV July 2009
document specifies an additional mode known as "SEAL with Reliability
Extensions (SEAL-RE)".
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 . . . . . . . . . . . . . . . . . . . 8
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Templin Expires January 7, 2010 [Page 2]
Internet-Draft SEAL-RE and SEAL-IV July 2009
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
Traffic Engineering (SEAL-TE)". 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-TE 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-TE
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-TE 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-TE, 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 integrtiy
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 January 7, 2010 [Page 3]
Internet-Draft SEAL-RE and SEAL-IV July 2009
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-TE 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 VER='2' in a SEAL data packet.
To enable SEAL-RE operation, the ITE simply sets the VER 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 VER field. A natural
progression of operations may entail the ITE beginning in SEAL-TE
mode (i.e., with VER='1') and shifting to SEAL-RE mode (i.e., with
VER='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-TE. 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 January 7, 2010 [Page 4]
Internet-Draft SEAL-RE and SEAL-IV July 2009
+-------------------------+
| |
~ 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 January 7, 2010 [Page 5]
Internet-Draft SEAL-RE and SEAL-IV July 2009
of [I-D.templin-intarea-seal]. The ITE uses the SEAL-TE 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 VER 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 VER
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 VER 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), Code=4 (i.e., Checksum Incorrect)
and Header Offset=0. The ETE finally writes the IP/*/SEAL headers
that appeared in the original packet before the segment was added to
the reassembly buffer.
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 | Header Offset=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP/*/SEAL headers of invoking SEAL data packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Checksum Incorrect Message Format
Templin Expires January 7, 2010 [Page 6]
Internet-Draft SEAL-RE and SEAL-IV July 2009
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 VER='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), Code=5 (i.e., Segment Bimap) and
Header Offset=24. 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=5 | Header Offset=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP/*/SEAL headers of invoking SEAL data packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Segment Bitmap Message Format
The ETE unconditionally writes the size of its reassembly buffer in
the S_MRU field. If a new value for S_MSS has been discovered, it
Templin Expires January 7, 2010 [Page 7]
Internet-Draft SEAL-RE and SEAL-IV July 2009
also writes the value in the S_MSS field; otherwise, it writes the
value 0 in that field.
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', VER='2'
and SEAL_ID=1500, it prepares a Segment Bitmap message with a 128 bit
Bitmap set to '10110011 ...' to denote that segments 1500, 1498,
1497, 1494, 1493, etc. were received, while segments 1499, 1496,
1495, etc. were missing.
The ETE finally writes the IP/*/SEAL headers of the invoking SEAL
data packet at the end of the message.
4. IANA Considerations
The IANA is instructed to designate the value '2' as the SEAL
protocol version number for SEAL-RE in the "SEAL Control Protocol"
registry.
The IANA is instructed to designate the values (Type=0; Code=4) for
the "Reassembly Report - Checksum Incorrect" message in the "SEAL
Control Protocol" registry.
The IANA is instructed to designate the values (Type=0; Code=5) for
the "Reassembly Report - Segment Bitmap" message in the "SEAL Control
Protocol" registry.
5. Security Considerations
The security considerations in [I-D.templin-intarea-seal] apply also
to SEAL-RE.
Templin Expires January 7, 2010 [Page 8]
Internet-Draft SEAL-RE and SEAL-IV July 2009
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-05 (work in
progress), July 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.
8.2. Informative References
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-00 (work in progress),
May 2009.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-01 (work in progress),
June 2009.
[I-D.templin-ranger]
Templin, F., "Routing and Addressing in Next-Generation
EnteRprises (RANGER)", draft-templin-ranger-07 (work in
progress), February 2009.
Templin Expires January 7, 2010 [Page 9]
Internet-Draft SEAL-RE and SEAL-IV July 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 January 7, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 08:29:33 |