Internet DRAFT - draft-fall-dtnrg-schl
draft-fall-dtnrg-schl
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]
