DTN Research Group K. Fall Internet-Draft Intel Labs, Berkeley Intended status: Experimental February 28, 2010 Expires: September 1, 2010 DTN Scope Control using Hop Limits (SCHL) draft-fall-dtnrg-schl-00 Abstract This document defines DTN Scope Control using Hop Limits (SCHL), a DTN Bundle Protocol extension block. The SCHL extension block holds the number of DTN hops a bundle has traversed while being forwarded (count sub-field) and a maximum hop limit value set by the bundle sender (limit sub-field). DTN nodes increment the count sub-field when forwarding a bundle and discard bundles that have traveled at least the number of hops specified in the limit sub-field. This memo also reserves the value 9 for the SCHL extension block type value and bundle status reason code in RFC 5050. 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 September 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Fall Expires September 1, 2010 [Page 1] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 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 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. The SCHL Extension Block . . . . . . . . . . . . . . . . . . . 3 2.1. Hop Count Sub-Field . . . . . . . . . . . . . . . . . . . . 4 2.2. Hop Limit Sub-Field . . . . . . . . . . . . . . . . . . . . 4 3. The SCHL Extension Block Format . . . . . . . . . . . . . . . . 4 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Bundle Origination . . . . . . . . . . . . . . . . . . . . 5 4.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . . 5 4.3. Bundle Delivery . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Fall Expires September 1, 2010 [Page 2] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 1. Introduction This document defines an extension block for use with the Bundle Protocol (BP) [RFC5050] within the context of the Delay-Tolerant Networking (DTN) architecture [RFC4838]. The DTN Bundle Protocol defines the bundle as its protocol data unit and defines "bundle blocks" to carry data of different types. This document defines how to perform DTN Scope Control using Hop Limits (SCHL), and the corresponding extension block, referred to as the "SCHL extension block." SCHL can be used by a bundle sender to control the number of hops a bundle is forwarded. A similar scheme has been used in conjunction with IPv4 and IPv6 multicast (see [RFC3810], Section 5 as an example) to limit the scope of multicast packets. However, SCHL differs from the TTL field in IPv4 and hop limit field in IPv6. The SCHL extension block includes a hop count sub-field that counts from zero upward as a bundle is forwarded, rather than from a limit downward as in IPv4 or IPv6. This capability allows DTN forwarding nodes to ascertain how many hops a bundle has traveled prior to reaching the forwarding node. This capability may be useful in determining how much "effort" the network has put into forwarding the bundle, and consequently may affect resource allocation decisions and/or congestion controls. This document specifies an extension block to the Bundle Protocol (RFC5050) containing two sub-fields, called the hop count sub-field and hop limit sub-field. Bundle Protocol implementations claiming to support SCHL MUST be capable of: o Generating an SCHL extension block and inserting it into a bundle o Allowing applications to specify the maximum hop limit value o Processing received SCHL extension blocks as specified in this document. 1.1. 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]. 2. The SCHL Extension Block The SCHL extension block comprises two sub-fields. The first sub- Fall Expires September 1, 2010 [Page 3] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 field is called the hop count sub-field, and the second is called the hop limit sub-field. The extension block is variable length, as each sub-field is encoded using an SDNV. 2.1. Hop Count Sub-Field A hop-count sub-field contained in the SCHL extension block of a subject bundle indicates the number of DTN hops a bundle has taken (i.e., how many bundle agents have forwarded the bundle). This value is an SDNV containing an initial value of zero. Bundles emitting from the sender will have a value of one. 2.2. Hop Limit Sub-Field A hop-limit sub-field contained in the SCHL extension block of a subject bundle indicates the maximum value the hop count sub-field is permitted to attain. This value is an SDNV with initial value of zero or greater set by the bundle sender. 3. The SCHL Extension Block Format The SCHL extension uses the Canonical Bundle Block Format as defined in the Bundle Protocol RFC 5050 [RFC5050]. |----------+----------+----------+----------+----------| | Type | Flags (*)| Length(*)| Count (*)| Limit(*) | |----------+----------+----------+----------+----------| A [RFC5050] Extension Block Format (no EID references) Figure 1: The SCHL Extension Block Format Notes: o (*) Indicates field contains a Self Delimiting Numerical Value (SDNV) (see Section 4.1. of RFC 5050 [RFC5050]) o "Block Type" (see section 3.1 of RFC 5050 [RFC5050]) is a 1-byte mandatory field set to the value 9, indicating the SCHL extension block. o "Block Processing Control Flags" (see section 3.1 of RFC 5050 [RFC5050]) is an SDNV that contains the BP block processing control flags. For SCHL, this MUST indicate no EID references and MUST set bit 0 (i.e., to indicate the extension is to be replicated in every fragment). Fall Expires September 1, 2010 [Page 4] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 o "Block Length" (see section 3.1 of of RFC 5050 [RFC5050]) is a mandatory SDNV that contains the aggregate length of all remaining fields of the block. A one octet SDNV is shown here for convenience in representation. 4. Processing 4.1. Bundle Origination The bundle user agent MUST provide a method for applications to specify the maximum hop limit for bundles they send. The bundle protocol agent may override this value by way of configuration information by limiting this value to a smaller value, but not a larger one. The protocol agent places the minimum of the two values in the maximum hop limit sub-field and arranges for it to be processed by the bundle security protocol [BPsec],x if enabled. The bundle protocol agent forms the SCHL extension in a subject bundle and MUST initialize the SCHL hop count sub-field to zero. 4.2. Bundle Forwarding A bundle forwarder receiving a bundle with the SCHL extension processes the bundle for local reception if appropriate and then checks the hop count sub-field against the maximum hop sub-field. If the hop count sub-field is equal to or greater than the value in the maximum hop limit sub-field, the bundle is discarded. This is called a "scoping discard event." By default, a scoping discard event MUST not generate any resultant report messages unless the report-request sub-field of the subject bundle is set. If the report-request field of the subject bundle is set when it experiences a scoping discard event, the bundle forwarding agent prepares a bundle status report (see RFC 5050, Section 6.1.1) with status flag set to 00010000 (reporting node deleted the bundle) and Reason Code set to 0x09 (a newly-defined value, indicating hop limit exceeded). This status report is sent according to conventions applicable to the sending of status reports in RFC 5050. 4.3. Bundle Delivery There are no special requirements placed upon bundle delivery. An implementation SHOULD provide a method for an application to ascertain the values of the hop count and hop limit sub-fields carried in the bundles comprising ADUs the application consumes. Fall Expires September 1, 2010 [Page 5] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 5. Acknowledgements The author would like to acknowledge discussions with Scott Burleigh and Alex McMahon as influencing the contents of this document. 6. IANA Considerations This memo includes no request to IANA at this time. However, it does reserve the value 9 for the Block Type value to indicate the SCHL Extension Block, and the value 9 for the Status Report Reason Code field of a bundle status report (RFC 5050). 7. Security Considerations The hop count sub-field is maintained as mutable data, as it is manipulated by a DTN bundle agent. A malicious bundle agent could increase the count field by more than one to induce early bundle discarding or decrease the value in order to induce bundles to be forwarded to a larger scope than the sender intended. A bundle agent might also ignore the maximum hop sub-field, thereby subverting the intentions of the sender. 8. References 8.1. Normative References [BPsec] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-15.txt, work-in-progress, February 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. 8.2. Informative References [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. Fall Expires September 1, 2010 [Page 6] Internet-Draft DTN Scope Control using Hop Limits (SCHL) February 2010 Author's Address Kevin Fall Intel Labs, Berkeley 2150 Shattuck Avenue, #1300 Berkeley, California 94704 USA Phone: +1-510-495-3014 Email: kfall@intel.com Fall Expires September 1, 2010 [Page 7]