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]