One document matched: draft-irtf-dtnrg-ecos-01.txt
Differences from draft-irtf-dtnrg-ecos-00.txt
Network Working Group S. Burleigh
Internet-Draft Jet Propulsion Laboratory,
Intended status: Experimental California Institute of
Expires: December 3, 2010 Technology
June 1, 2010
Bundle Protocol Extended Class Of Service (ECOS)
draft-irtf-dtnrg-ecos-01
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
"best-efforts" flag, a "convergence-layer stewardship" 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 December 3, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Burleigh Expires December 3, 2010 [Page 1]
Internet-Draft ECOS June 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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ECOS Extension Block Format . . . . . . . . . . . . . . . . . . 4
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Bundle Origination . . . . . . . . . . . . . . . . . . . . 5
3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . . 6
3.3. Bundle Delivery . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Burleigh Expires December 3, 2010 [Page 2]
Internet-Draft ECOS June 2010
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" 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 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 ensure 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.
o There may be a need to ensure that the bundle should be retained
for possible reforwarding and rerouting even if custody transfer
is not requested. This might be the case for a sequence of
important bundles that are transmitted over a link whose capacity
is insufficient to convey all of the custody signals that would be
produced if custody transfer were requested for them: events that
are functionally equivalent to the arrival of custody acceptance
and refusal signals may instead be generated autonomously by the
Burleigh Expires December 3, 2010 [Page 3]
Internet-Draft ECOS June 2010
convergence-layer protocol adapter.
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.
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 contain no 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:
o The 0x01 bit, if True, indicates that the bundle is "critical":
the bundle protocol agent is required 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 to be
forwarded on a "best-efforts" basis.
o The 0x04 bit, if True, indicates that the bundle is to be retained
for possible reforwarding and rerouting subject to convergence-
layer-initiated pseudo-custodial acceptance or refusal.
Burleigh Expires December 3, 2010 [Page 4]
Internet-Draft ECOS June 2010
o The 0x80 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 0x80 bit of the ECOS block's "flags" byte is False then the
"ordinal" byte is the last field of the block data. Otherwise, the
third and final 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.
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 0x80 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 0x80
bit of the block's flags byte MUST be set to 0 (False).
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.
Burleigh Expires December 3, 2010 [Page 5]
Internet-Draft ECOS June 2010
3.2. Bundle Forwarding
At the time a bundle that has no 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
one copy of the bundle MUST 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.
2. If the 0x02 bit of the ECOS block's flags byte is set to 1, then
the bundle protocol agent MUST invoke the services of an adapter
for a convergence layer protocol that does NOT perform
retransmission of data lost in transit unless the node has no
convergence layer protocol adapter that has a plausible prospect
of being able to forward the bundle toward its final destination
without returning it to the local node.
3. If the 0x04 bit of ECOS block's flags byte is set to 1, then
processing depends on whether or not custody transfer was
requested for this bundle. If it was, then this ECOS block flag
MUST be ignored. Otherwise, the additional retention constraint
"stewardship accepted" MUST be added to the bundle, preventing
the bundle from being discarded (prior to expiration) until this
constraint is removed. Mechanisms by which convergence-layer
adapters may remove this constraint (functionally analogous to
custody acceptance) or may simulate the reception of a "Failed"
custody signal for this bundle (functionally analogous to custody
refusal or timeout) SHOULD be exercised per the results of using
convergence-layer protocols to send the bundle.
4. 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, and 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
Burleigh Expires December 3, 2010 [Page 6]
Internet-Draft ECOS June 2010
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 ECOS block; that value is 0.
The 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 have no impact on bundle
delivery procedures.
4. IANA Considerations
This document has no IANA considerations.
5. Security Considerations
The ECOS block introduces no new security considerations beyond those
discussed in the DTN Bundle Protocol and Bundle Security Protocol
specifications.
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.
Burleigh Expires December 3, 2010 [Page 7]
Internet-Draft ECOS June 2010
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 December 3, 2010 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 10:30:31 |