Network Working Group S. Burleigh Internet-DraftJet Propulsion Laboratory, California Institute of Technol Intended status: Experimental April 25, 2013 Expires: October 27, 2013 Bundle Protocol Extended Class Of Service (ECOS) draft-irtf-dtnrg-ecos-04 Abstract This document describes an extension to the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) that marks bundles with class-of-service designators beyond those defined for the BP primary block. The extended class-of-service designators are an "ordinal" number that provides fine-grained prioritization of bundles, a "critical" flag, a "streaming" flag, and an optional flow label. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 27, 2013. Copyright Notice Copyright (c) 2013 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 Burleigh Expires October 27, 2013 [Page 1] Internet-Draft ECOS April 2013 (http://trustee.ietf.org/license-info) in effect on the date of 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ECOS Extension Block Format . . . . . . . . . . . . . . . . . 3 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Bundle Origination . . . . . . . . . . . . . . . . . . . 4 3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 5 3.3. Bundle Delivery . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document describes an extension to the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] that marks bundles with class- of-service designators beyond those defined for the BP primary block. The bundle protocol specification defines a single designator for a bundle's class of service: o Priority, a value in the range 0 through 2, with higher values indicating greater urgency: 0 = "bulk", 1 = "normal", 2 = "expedited". Priority level 3 is reserved for future use. For some applications, such as space flight operations, additional variation in class of service may be required: o Many more levels of priority may be needed, enabling more fine- grained control over the precedence of user-selected application data types in the progress of bundles through the network. o A way of indicating emergency ("critical") traffic may be needed. Emergency traffic is not merely high-priority: it is so important that the user is willing to incur the network overhead of transmitting the bundle along every potential route to its destination, rather than only on the route that would normally be selected as the "best" route according to the applicable routing value function. This expedient ensures that the bundle arrives at Burleigh Expires October 27, 2013 [Page 2] Internet-Draft ECOS April 2013 its destination in the least possible time, regardless of how accurately the routing system reckons end-to-end latency on any given route: the bundle arrives by whatever turns out to be the fastest route, as well as by all others. o There may be a need to request that all nodes forwarding the bundle use convergence-layer protocols that *don't *perform retransmission upon detected loss of data. This designation may be important for bundles carrying application data for which timeliness of delivery is more important than certainty: retransmitted "old data" may be a waste of bandwidth that could instead be used to convey new data of greater value, or the out- of-order arrival of retransmitted data may degrade the usefulness of streaming data such as audio or video. o There may be a need for an opaque "flow label" that can be used by the application to pass a variety of transmission control parameters to the convergence-layer protocol. The Extended Class of Service (ECOS) extension to Bundle Protocol is designed to provide these additional class of service designators. 2. ECOS Extension Block Format The ECOS block conforms to sections 4.5.2 and 4.6 of [RFC5050], constrained as follows: o Block type code is 19. (See "IANA Considerations" below.) o The following block processing control flag MUST be set to 1: * Bit 0 - block must be replicated in every fragment. The setting of other block processing control flags, where not mandated by the Bundle Protocol specification, is an implementation matter. o The block MUST NOT contain any EID references. o Block data length is 2 + N, where N is zero if the ECOS block contains no flow label (as described below) and is otherwise the length of the SDNV in which that flow label is represented. The block data of the ECOS block comprises at least two and possibly three fields. The first field of the block data is an 8-bit "flags" byte. The bits of the flags signify the following conditions: Burleigh Expires October 27, 2013 [Page 3] Internet-Draft ECOS April 2013 o The 0x01 bit, if True, indicates that the bundle is "critical": the bundle protocol agent is requested to forward one copy of the bundle along every path that might get it to its destinaion. o The 0x02 bit, if True, indicates that the bundle is "streaming": the bundle protocol agent is requested to forward the bundle on a "best-efforts" basis, without retransmission. o The 0x04 bit, if True, indicates that the "ordinal" byte of this ECOS block (the byte immediately following the "flags" byte) is followed by a numeric "flow label" in SDNV representation. o All other bits of the "flags" byte are reserved for future use. The "flags" byte is followed by an 8-bit "ordinal" byte, containing an unsigned "ordinal" number in the range 0-255. For a bundle whose standard class of service is 2 ("expedited"), the ordinal number indicates the relative priority of this bundle among all other expedited bundles: ordinal value 100 indicates greater urgency than ordinal value 99, and so on. Ordinal value 255 is reserved for custody signals. For a bundle whose standard class of service is not 2, the ordinal value has no significance. If the 0x04 bit of the ECOS block's "flags" byte is True, the third field of the block data is a numeric "flow label" value in SDNV representation. The significance of the flow label is an implementation matter. Notionally, the flow label is intended to be used to convey quality-of-service information to the convergence- layer protocol adapter. The bundle protocol agent's response to a flow label whose significance is unknown is an implementation matter. 3. Processing 3.1. Bundle Origination At the time a bundle is sourced it MAY contain one ECOS block. When a bundle contains an ECOS block, the ECOS block MUST precede the payload block and it MUST be the only ECOS block in the bundle. The manner in which the application issuing the block communicates the values of the ECOS block data fields to the bundle protocol agent is an implementation matter. If the ECOS block contains a flow label, then the 0x04 bit of the block's "flags" byte MUST be set to 1 (True) and the flow label MUST be a numeric value represented as a valid SDNV. Otherwise the 0x04 bit of the block's flags byte MUST be set to 0 (False). Burleigh Expires October 27, 2013 [Page 4] Internet-Draft ECOS April 2013 The ordinal byte of the ECOS block MUST contain an unsigned integer in the range 0-255. If the bundle of which the ECOS block is a part is a custody signal, then the value of the ordinal byte MUST be 255; otherwise, the value of the ordinal bit MUST be in the range 0-254. 3.2. Bundle Forwarding This section applies only to nodes at which procedures for processing ECOS blocks are implemented. When a node at which such procedures are not implemented receives a bundle that contains one or more ECOS blocks, those blocks must be processed as prescribed in the Bundle Protocol specification. When a received bundle contains multiple ECOS blocks or contains a single ECOS block that is invalid (that is, one that violates one or more of the provisions of section 3.1 above), all ECOS blocks in the bundle MUST be ignored and SHOULD be deleted. At the time a bundle that has no valid single ECOS block is received from a neighboring node, the bundle protocol agent MAY insert an ECOS block into the bundle. The values of the block data fields of such an ECOS block are an implementation matter, provided that they conform to this specification. The forwarding of a bundle that contains a valid ECOS block, whether locally sourced or received from another bundle protocol agent or locally inserted upon reception from another bundle protocol agent, MUST comply with the following rules: 1. If the 0x01 bit of the ECOS block's flags byte is set to 1, then exactly one copy of the bundle SHOULD be forwarded to every neighboring node that has some plausible prospect of being able to forward the bundle toward its final destination without returning it to the local node, a determination that is a matter left to the bundle protocol agent's route computation mechanism; also, the bundle MUST be queued for transmission as if its standard class of service were 2 ("expedited") and its ordinal value were 254, regardless of the actual values of these fields. Each "critical" bundle MUST be forwarded *at most once* by each bundle protocol agent; that is, critical bundles MUST NOT be reforwarded in response to custody refusals, the expiration of custody transfer timers, the presence of a routing loop in the network, or any other condition, because such reforwarding could result in unbounded bundle transmission explosions. The manner in which this constraint is enforced is an implementation matter. One possible approach is to manage a list of the IDs and expiration times of all critical bundles received, removing bundles from the list only as the associated expiration times are Burleigh Expires October 27, 2013 [Page 5] Internet-Draft ECOS April 2013 reached; since "critical" bundles should be issued rarely, managing such a list should not be a severe processing burden. Note that a bundle protocol agent MAY choose to handle a critical bundle as non-critical traffic and forward it on only a single path, but ignoring the "critical" flag may put network assets as risk and should be avoided unless necessary to preserve the continued operation of the bundle protocol agent. 2. If the 0x02 bit of the ECOS block's flags byte is set to 1, then the bundle protocol agent SHOULD forward the bundle by invoking an adapter for a convergence layer protocol that does NOT perform retransmission of data lost in transit. If the bundle protocol agent has no access to such a convergence layer adapter then this flag may be ignored, but in that case application data units may arrive out of transmission order at the destination (possibly degrading application performance) and/or transmission bandwidth may be wasted on unnecessary retransmission, reducing the effective throughput of the network. 3. If the bundle's class of service is 2 (expedited), then the bundle protocol agent MUST forward this bundle only after forwarding all other bundles that are to be forwarded to the same node and have got class of service 2 and have explicit or implicit ordinal byte value that is higher than or equal to the ECOS block's ordinal byte value. Moreover, the bundle protocol agent MUST forward this bundle before forwarding any other bundle that is to be forwarded to the same node and either (a) has got class of service 2 and explicit or implicit ordinal byte value lower than the ECOS block's ordinal byte value or (b) has got class of service less than 2. An implicit ordinal byte value is the ordinal byte value for a bundle that has no valid ECOS block; that value is 0. The valid ECOS block of a received bundle that is to be forwarded to another node MUST NOT be deleted from the bundle. 3.3. Bundle Delivery When a bundle that contains an ECOS block is delivered to its final destination, the values of ECOS block fields MAY be provided to the application but otherwise have no impact on bundle delivery procedures. Burleigh Expires October 27, 2013 [Page 6] Internet-Draft ECOS April 2013 4. IANA Considerations This specification allocates a codepoint from the Bundle Block Type Codes registry defined in [I-D.irtf-dtnrg-iana-bp-registries]. The additional entry in the Bundle Block Type Codes Registry assigns value 19 to the Extended Class of Service block and references this specification. 5. Security Considerations Clearly the injection of bundles with the "critical" flag set to True could increase the impact of a denial of service attack. As with all such attacks, the best available defense is to require valid Bundle Authentication Blocks on all received bundles. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. Author's Address Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Drive, m/s 301-490 Pasadena, CA 91109 USA Phone: +1 818 393 3353 Email: Scott.C.Burleigh@jpl.nasa.gov Burleigh Expires October 27, 2013 [Page 7]