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]