One document matched: draft-templin-intarea-seal-re-00.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track July 2, 2009
Expires: January 3, 2010
SEAL with Reliability Extensions (SEAL-RE)
draft-templin-intarea-seal-re-00.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 3, 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 3, 2010 [Page 1]
Internet-Draft SEAL-RE July 2009
document specifies a third 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. The Segment Bitmap Message . . . . . . . . . . . . . . . . 4
3.2. ITE Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. ETE Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Templin Expires January 3, 2010 [Page 2]
Internet-Draft SEAL-RE 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 a third 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 not
available in the other two modes. 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
discuss SEAL-RE.
Templin Expires January 3, 2010 [Page 3]
Internet-Draft SEAL-RE July 2009
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] with the exception that the ETE returns
a "Segment Bitmap" instead of a "Segment Acknowledged" SEAL control
message when the ITE sets the 'A' bit 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. The Segment Bitmap Message
When the ITE sets A='1' and VER='2' in a SEAL segment, the ETE
returns a "Reassembly Report - Segment Bitmap" message that includes
a 16-byte Bitmap containing a contiguous string of 128 bits. The
bits in the Bitmap correspond to this segment and 127 preceding SEAL
segments that the ETE expected to receive.
The Segment Bitmap message sets Type=0, Code=4 and Header Offset=24.
The message is formatted as follows:
Templin Expires January 3, 2010 [Page 4]
Internet-Draft SEAL-RE July 2009
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=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_MSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP/*/SEAL headers of invoking SEAL data packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: 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
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 correspond 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).
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.
3.2. ITE Behavior
When the ITE uses SEAL-RE mode, it should maintain a cache of the
SEAL segments that it most recently sent to the ETE. The ITE should
also periodically set A='1' in the SEAL header of a segment to
solicit a Segment Bitmap message from the ETE. 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.
Templin Expires January 3, 2010 [Page 5]
Internet-Draft SEAL-RE July 2009
3.3. ETE Behavior
When the ITE receives a SEAL data packet with A='1' and VER='2', it
prepares a Segment Bitmap message as specified in Section 3.1. If
the ETE does not have sufficient segment reception history (e.g., if
the ITE has just shifted to SEAL-RE mode from SEAL_TE), it marks each
unknown segment as received.
The ETE should also maintain reassembly buffering proportional to the
tunnel's (bandwidth*delay) product so that reassembled packets can be
forwarded in the proper order.
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 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.
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
Templin Expires January 3, 2010 [Page 6]
Internet-Draft SEAL-RE July 2009
8.1. Normative References
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-04 (work in
progress), June 2009.
[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.
[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 3, 2010 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 08:31:27 |