Delay Tolerant Networking Research S. Parikh
Group S. Symington
Internet-Draft K. Scott
Intended status: Experimental R. Durst
Expires: October 17, 2011 R. Edell
The MITRE Corporation
April 15, 2011
Delay-Tolerant Networking Superseding Bundle Extension Block
draft-parikh-bundle-superseding-extension-block-01
Abstract
This document defines an optional Bundle Protocol block called the
Superseding Bundle Extension Block (SBEB) for use with the Bundle
Protocol in the context of the Delay-Tolerant Networking
Architecture. Applications use this block to call for the removal of
previously sent bundles that are rendered obsolete by more recent
bundles. Upon receiving a bundle with an SBEB, a node will search
its bundle store (and outbound queues) for bundles that are obsoleted
by other related bundles according to their source and destination
EID, and the SBEB cookie (if present), and may delete some or all of
them. Discarding obsolete bundles helps conserve storage space and
prevents expending resources in further forwarding bundles that are
no longer relevant. The bundle protocol already uses expiration
times to remove bundles that are no longer useful to applications.
The SBEB is a way for applications to mark bundles that a node may
delete prior to their expiration times.
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
Parikh, et al. Expires October 17, 2011 [Page 1]
Internet-Draft DTN SBEB April 2011
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 17, 2011.
Copyright Notice
Copyright (c) 2011 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
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.
Parikh, et al. Expires October 17, 2011 [Page 2]
Internet-Draft DTN SBEB April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Superseding Bundle Extension Block Format . . . . . . . . . . 6
4. Superseding Bundle Block Processing . . . . . . . . . . . . . 10
4.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 10
4.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 10
4.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. SBEB Type 0 . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. SBEB Type 1 . . . . . . . . . . . . . . . . . . . . . 12
4.3.3. SBEB Type 2 . . . . . . . . . . . . . . . . . . . . . 12
5. Interactions with Bundle Protocol Features . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References (Note: the IDs listed here are in
the RFC editor's queue; this document depends on them;
replace with appropriate RFC references.) . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Parikh, et al. Expires October 17, 2011 [Page 3]
Internet-Draft DTN SBEB April 2011
1. Introduction
This document defines an optional Bundle Protocol block called the
Superseding Bundle Extension Block (SBEB) for use with the Bundle
Protocol [RFC5050] in the context of the DTN Architecture [RFC4838].
Applications use this block to call for the removal of previously
sent bundles that are rendered obsolete by more recent bundles. Upon
receiving a bundle with an SBEB, a node will search its bundle store
(and outbound queues) for bundles that are obsoleted by other related
bundles according to their source and destination EID and the SBEB
cookie (if present), and may delete some or all of them. Thus, a
bundle with an SBEB can trigger the flushing of bundles from nodes as
it traverses the network. A newly arriving bundle might render
obsolete an older bundle that is currently in the store, and the node
may delete it. If an older bundle arrives after a newer bundle
(possible because of out-of- sequence arrivals), then the node may
delete the older (but most recently arrived) bundle. The SBEB
includes a retention count that instructs the node to retain a number
(not just one) of the newest bundles according to their timestamp.
Discarding obsolete bundles helps conserve storage space and prevents
expending resources in further forwarding bundles that are no longer
relevant. The bundle protocol already uses expiration times to
remove bundles that are no longer useful to applications. The SBEB
is a way for applications to mark bundles that a node may delete
prior to their expiration times. However, this extension is not
intended as a reliable mechanism for applications to eliminate
bundles in the network; it is intended to assist in reducing the load
on DTN nodes and the network. The capabilities described in this
document are optional for deployment with the Bundle Protocol. The
use of this extension block is voluntary by applications, and even
bundle nodes that support it can choose to ignore it. To support
this extension, a bundle protocol agent must be capable of receiving
bundles with this extension block and processing them as described in
this document.
2. Motivation
This extension is motivated by applications that send "cyclic
telemetry", that is, bundles containing information that supplants
information in previously sent bundles.
The primary example comes from applications that distribute status
updates. Consider a server that tracks the location of vehicles and
distributes that information to clients over a network of DTN nodes.
The server sends a bundle containing the location of a particular
vehicle when that vehicle reports its position to the server. The
clients only want the most recent location of each vehicle; the
Parikh, et al. Expires October 17, 2011 [Page 4]
Internet-Draft DTN SBEB April 2011
history of the vehicle's location is not useful information (in this
particular example). Therefore, if multiple location updates are
present in a node's bundle store, the node need only forward the most
recent one. By using SBEB, the server can send bundles that will
replace older bundles along the path to the destination. In this
example, the application may use an EID that only identifies the
source application, not the vehicle to which the bundle pertains
(that is, it uses the same source EID regardless of the particular
vehicle). The payload will contain an identifier of the vehicle and
its location; thus, a node will need additional information to
identify bundles that pertain to a particular vehicle, because nodes
do not examine bundle payloads. The cookie field in the extension
block can contain an identifier for the vehicle, and the node can
search the bundle store for bundles with that cookie (in addition to
the source and destination).
A motivating case for retaining more than one matching bundle comes
from a camera system that monitors highway traffic, intended for
commuters to check roadways that are prone to gridlock or accidents,
so they can plan their trip accordingly. The camera sends a snapshot
bundle once every minute to a collecting server over a network of DTN
nodes. The server then posts that image on a website which commuters
check over the Internet (the cameras are not on the Internet). The
expiration time of bundles containing the snapshots are
conservatively set to 10 minutes to give the image sufficient
lifetime to traverse the challenged network of DTN nodes. Suppose
that an intermittent link in the challenged network results in
snapshot bundles accumulating at a node. Only the five (for the sake
of example) most recent photos are useful; previous photos in the
bundle store are not. This gives an observer enough pictures to
gauge the flow of traffic (something that might be difficult for the
camera to compute), but a complete historical record of all images is
not needed. The SBEB instructs the node to retain only the freshest
images and delete the others, thereby releasing storage resources and
preventing the further transmittal of out-of-date bundles. In this
scenario (in contrast to the previous example), since each camera
would have a unique source EID, the tuple of source EID, destination
EID, and timestamp would be sufficient to identify obsolete bundles
in a node's bundle store; no additional cookie is needed.
Note that DTN nodes do not guarantee that bundles arrive at a node in
order of timestamp. Therefore, a node might discard the newly
arrived bundle if a more recent one is already present in the bundle
store. The search only applies to bundles that are currently in the
bundle store when the node acts in response to the SBEB. The node
does not track or consider the timestamps of bundles that have
already departed the node.
Parikh, et al. Expires October 17, 2011 [Page 5]
Internet-Draft DTN SBEB April 2011
In some ways, the SBEB serves as a congestion control guidance
mechanism for DTN nodes. It provides applications a way to advise
which bundles a node can remove to help conserve storage, and in this
respect it supplements the bundle expiration time. However, the goal
of the SBEB is not to provide applications a way to reliably rid the
network of stale bundles. If storage and link resources are
plentiful, nodes may choose to ignore the SBEB; applications should
not depend on nodes to respond to the SBEB.
3. Superseding Bundle Extension Block Format
The SBEB Block uses the Canonical Bundle Block Format as defined in
the Bundle Protocol [2], using the block layout without an EID
Reference List. That is, it is comprised of the following elements:
1. Block-type code (1 byte): Defined as in all bundle protocol
blocks except the primary bundle block (as described in the
Bundle Protocol). The extension block type for SBEBs is
[XXX_TO_BE_ASSIGNED_BY_IANA_XXX -- see Section 6]:
2. Block processing control flags (SDNV): Defined as in all bundle
protocol blocks except the primary bundle block. SDNV encoding
is described in the Bundle Protocol.
* Bit 0 ("Block must be replicated in every fragment") SHOULD be
set.
* Bit 2 ("Delete bundle if block can't be processed") MUST NOT
be set.
* Bit 4 ("Discard block if it can't be processed") MUST NOT be
set.
* Bit 6 ("Block contains an EID-reference field") MUST NOT be
set.
3. Block EID references count and EID references: This field MUST
NOT be present.
4. Block data length (SDNV): defined as in all bundle protocol
blocks except the primary bundle block. SDNV encoding is
described in the bundle protocol.
5. Block-type-specific data fields as follows:
Parikh, et al. Expires October 17, 2011 [Page 6]
Internet-Draft DTN SBEB April 2011
SBEB Flags (SFLAGS, byte) A byte of flags indicating whether or
not an SBEB Cookie is preent, and the type of SBEB:
Bit 0: Cookie Present: Indicates the presence and type of
SBEB cookie field contained in the current block:
0: No cookie field present
1: Cookie field present
Bit 1: IsSigned Indicates whether or not this SBEB contains a
signature of the canonicalized version of the primary
bundle block plus the SBEB.
0: No hash present
1: Hash present
Bits 3-2: SBEB Type Indicates the type operation to be done
to determine which bundles to keep / discard:
0 Supersede by freshness -- keep the most recent N
bundles.
1 Keep fixed time window -- keep all bundles with creation
timestamps >= the creation timestamp of the current
bundle minus N seconds.
2 Supersede by sequence vector
3 Reserved for future use
Bits 7-3: Reserved Reserved for future use.; these bits
SHOULD b set to 0 on send and ignored on receipt.
SBEB Cookie (SDNV) If the Cookie Present bit of the SBEB flags
indicates that an SBEB Cookie is present, then the SBEB Cookie
MUST be included and MUST follow the SBEB Flags. The SBEB
Cookie is an opaque token used by forwarders to match the SBEB
against those of other bundles the routers hold. If the
Cookie Present value is 0 (No cookie field present) then the
SBEB Cookie MUST NOT be present.
SBEB SigLen (SDNV) If the 'IsSigned' bit of the SBEB Flags
indicates that a signed hash is present, the length of that
signed hash (the following field) appears here, encoded as an
SDNV.
Parikh, et al. Expires October 17, 2011 [Page 7]
Internet-Draft DTN SBEB April 2011
SBEBSignature: If the 'IsSigned' bit of the SBEB Flags indicates
that a signed hash is present, that signed hash appears here.
The signing mechanism used is RSA with SHA256 as specified for
the id-sha256 PKCSv2.1 signature scheme in [RFC4055]. The
hash is computed over the following fields of the Primary
Bundle Block, in the order below with no padding in between:
+ Version
+ Source scheme
+ Source scheme-specific part
+ Creation timestamp time
+ Creation timestamp sequence number
+ Destination scheme
+ Destination scheme specific part
followed by the SBEB block (this block) itself, with the
signature-related fields (SBEB SigLength and SBEBSignatures)
fields of the SBEB omitted, followed by any required padding
bytes as zeros; the hash is then signed and the result of the
signing process becomes this field. Nodes that process SBEBs
are expected to be able to determine the correct signing key
from the other fields of the bundle (such as the source EID).
An alternate way to compute the hash could be to compute it over the
concatenation of the mutable canonicalization of the bundle's Primary
Bundle Block as defined in [I-D.irtf-dtnrg-bundle-security] section
3.4.2, followed by the SBEB block (this block) itself, with the
signature-related fields (SBEB SigLength and SBEBSignatures) fields
of the SBEB omitted; the result of the signing process becomes this
field. Nodes that process SBEBs are expected to be able to determine
the correct signing key from the other fields of the bundle (such as
the source EID). Using only the fields listed above doesn't allow
for reuse of other code to manage mutable cononicalization of PBBs,
but should be simpler.
The rest of the fields of an SBEB differ depending on the value of
the SBEB Type field.
If the SBEB Type is 0 or 1, the last field of the SBEB is:
Parikh, et al. Expires October 17, 2011 [Page 8]
Internet-Draft DTN SBEB April 2011
Retention Field (SDNV) For SBEB Type 0 (keep the most recent N
bundles) this indicates the number of newest (by creation
timestamp) matching bundles that a node MUST retain (if as many
bundles are indeed available). The value must be at least one
for a node to search for and discard bundles in response to the
SBEB; thus, a value greater than zero serves to activate an
SBEB. An application uses a value of zero on bundles that
might later be subject to removal by a future bundle, but that
do not themselves trigger the removal of bundles; this allows
the application control over when to activate the discarding of
older bundles.
For SBEB Type 1 (keep bundles from the most recent N seconds)
the retention field in conjunction with the bundle creation
time indicates the threshold beyond which bundles should be
retained. Thus a router processing a bundle with an SBEB-2
extension, a creation timestamp of M, and a Retention Field of
N MUST retain all bundles with creation timestamps >= M-N. The
value must be at least one for a node to search for and discard
bundles in response to the SBEB; thus, a value greater than
zero serves to activate an SBEB. An application uses a value
of zero on bundles that might later be subject to removal by a
future bundle, but that do not themselves trigger the removal
of bundles; this allows the application control over when to
activate the discarding of older bundles.
If the SBEB Type is 2, the remainder of the SBEB contains a
sequence number for this bundle together with a list of sequence
numbers that this bundle obsoletes:
SBEB Sequence Number (SDNV) The SBEB sequence number of this
bundle as assigned by the application. Bundles with a
particular (source, destination) pair SHOULD use monotonic non-
decreasing values for their SBEB sequence numbers.
Obsoletes Up To A cumulative watermark sequence number of
obsoleted bundles. This bundle obsoletes all matching bundles
with SBEB sequence numbers up to and including this value.
This value MUST be less than the SBEB sequence number of this
bundle.
Obsoletes Vector Count (OVC, an SDNV) Count of the number of
sequence numbers in the obsoletes vector.
Parikh, et al. Expires October 17, 2011 [Page 9]
Internet-Draft DTN SBEB April 2011
Obsoletes List (sequence of SDNVs) Vector of obsoleted sequence
numbers. Each element of the vector is a single sequence
number that is obsoleted by this bundle. Each value in the
obsoletes vector MUST be less than the SBEB sequence number of
this bundle.
The Structure of a Superseding Bundle Extension Block is shown in
Figure 1:
+--------+--------------+--------------+--------+--------------------+
| Type | Flags (SDNV) |Length (SDNV) | SFLAGS | Cookie (SDNV, opt) |
+--------+--------------+-------+------+--------+--------------------+
| SBEB Signature (if present) |
+-------------------------------+------------------------------------+
| Retention field (SDNV) |
+-------------------------------+
Figure 1: SBEB Format for SBEBS of type 0, 1
The structure of a Superseding Bundle Extension Block of type 2 is
shown in Figure 2:
+--------+--------------+--------------+--------+--------------------+
| Type | Flags (SDNV) |Length (SDNV) | SFLAGS | Cookie (SDNV, opt) |
+--------+--------------+-------+------+--------+--------------------+
| SBEB Signature (if present) |
+-------------------------------+------------------------------------+
| SBEB Sequence Number (SDNV) | Obsoletes Up To (SDNV) |
+------------+---------------+--+------------+-----------------------+
| OVC (SDNV) | entry1 (SDNV) | entry2 (SDNV) | ...
+------------+---------------+---------------+
Figure 2: SBEB Format for SBEBS of type 2
4. Superseding Bundle Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of SBEB blocks.
4.1. Bundle Transmission
When an outbound bundle is created per the parameters of the bundle
transmission request, this bundle MAY (as influenced by local policy)
include one SBEB (as defined in this specification).
4.2. Bundle Forwarding
The node MUST NOT insert an SBEB into the bundle before forwarding
it. The node MUST NOT modify any part of the SBEB. The node MUST
NOT remove the SBEB before forwarding it.
Parikh, et al. Expires October 17, 2011 [Page 10]
Internet-Draft DTN SBEB April 2011
4.3. Bundle Reception
SBEB processing is optional and may be controlled by policy at a
node.
If a received bundle is complete (i.e. is not a fragment) and
includes an SBEB or upon reassembly of fragments into a complete
bundle that includes an SBEB, and if the receiving node chooses to
process the SBEB, the node MUST process it as follows. Upon receipt
of a bundle with an SBEB, the node searches for other bundles
awaiting forwarding that match the current bundle SBEB criteria.
Matching bundles are those that:
o do not have the current node as their current custodian,
o themselves contain SBEBs with identical SBEB Flags fields as the
one being processed, and
o are members of the same source endpoint as the current bundle, and
o are members of the same destination endpoint as the current
bundle, and
o either contain no cookie if the current SBEB does not contain a
cookie or else contain the same SBEB cookie as the present bundle,
and
o either contain no signature if the current SBEB does not have a
signature or else contains a valid SBEB Signature.
Determining which of the matching bundles are retained and which are
discarded depends on the SBEB type:
4.3.1. SBEB Type 0
The value of the SBEB Retention field identifies the number of
matching bundles, including the current one, that the router should
retain. The value N used is that of the most recent (by creation
timestamp and timestamp sequence number) matching bundle's SBEB
retention field value. The most recent N (by creation timestamp and
creation timestamp sequence number) complete bundles MUST be
retained. Other matching bundles that are complete SHOULD be
discarded. Matching fragments SHOULD be discarded if their creation
timestamps and creation timestamp sequence numbers are such that they
would have been discarded had they been complete at the time of SBEB
processing. Matching bundle fragments with (creation timestamp,
creation timestamp sequence number) values more recent that the
oldest retained complete bundle MUST be retained.
Parikh, et al. Expires October 17, 2011 [Page 11]
Internet-Draft DTN SBEB April 2011
4.3.2. SBEB Type 1
The value of the SBEB Retention field identifies a time threshold
equal to the value of the current bundle's creation timestamp minus
the SBEB Retention field value. The value N used is that of the most
recent (by creating timestamp and timestamp sequence number) matching
bundle's SBEB retention field value. Matching bundles (complete or
fragments) with creation timestamps equal to or after this threshould
MUST be retained; bundles with creation timestamps before the
threshold SHOULD be discarded.
4.3.3. SBEB Type 2
Bundles are retained based on their SBEB sequence numbers as follows.
Bundles (complete or fragments) with sequence numbers less than or
equal to the value of the 'Obsoletes Up To' field SHOULD be
discarded. Bundles with SBEB sequence numbers that are in the
'Obsoletes List' SHOULD be discarded. All other bundles MUST be
retained.
5. Interactions with Bundle Protocol Features
When the SBEB results in a node deleting a bundle, the node MAY
generate a bundle deletion status report, as described in the Bundle
Protocol specification.
If the node implements sequenced outbound queing and if SBEB
processing obsoletes a bundle that is queued for transmission, the
obsoleting bundle MUST take the obsoleted bundle's place in the
queue. This prevents the situation where replacing bundles are
always sent to the tail of the queue, causing a condition where
bundles never depart from a node.
6. IANA Considerations
This document requests that IANA assign a Bundle Block Type Code for
SBEB blocks from the unassigned pool of the Bundle Bock Type Codes
DTN Registry [I-D.irtf-dtnrg-bundle-security] section 3.1.
Note to RFC Editor: once the BP registry is established and a block
type code has been assigned and its value inserted into Section 3 of
this document, this section may be removed on publication as an RFC.
Parikh, et al. Expires October 17, 2011 [Page 12]
Internet-Draft DTN SBEB April 2011
7. Security Considerations
Because the SBEB is not included in the Mutable Canonicalization of
the bundle, its end-to-end integrity is not ensured by the use of the
mandatory Payload Integrity Block ciphersuite defined in the BSP.
Because the SBEB would be included in the Strict Canonicalization of
the bundle, its integrity would be ensured between one bundle
protocol agent and its adjacent bundle protocol agent, providing the
Bundle Authentication Block is used to protect the bundle during that
single DTN hop.
SBEBs could be encrypted using the Extension Security Block mechanism
of the BSP, but 1) the mandatory ciphersuite for ESBs is the
symmetric RSA-AES-128-EXT ciphersuite which uses symmetric keys that
would need to be known to large portions of the network if SBEBs were
to be processed and 2) even without the ESB key, a bad actor with
access to a single bundle containing an encrypted SBEB could (if it
guessed the SBEB-containing ESB) copy the encrypted SBEB onto 'bogus'
bundles and flood the network, crowding out real bundles. This last
attack could be prevented by having the source sign SBEBs.
8. Acknowledgements
9. References
9.1. Normative References (Note: the IDs listed here are in the RFC
editor's queue; this document depends on them; replace with
appropriate RFC references.)
[I-D.irtf-dtnrg-bundle-security]
Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-19 (work in progress),
March 2011.
[I-D.irtf-dtnrg-iana-bp-registries]
Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle
Protocol IANA Registries",
draft-irtf-dtnrg-iana-bp-registries-02 (work in progress),
February 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
Parikh, et al. Expires October 17, 2011 [Page 13]
Internet-Draft DTN SBEB April 2011
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
9.2. Informative References
[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.
Authors' Addresses
Salil Parikh
The MITRE Corporation
7515 Colshire Drive
McLean, Virginia 22102
USA
Phone: +1 (703) 983-3560
Email: sparikh@mitre.org
Susan Symington
The MITRE Corporation
7515 Colshire Drive
McLean, Virginia 22102
USA
Phone: +1 (703) 983-7209
Email: susan@mitre.org
Keith Scott
The MITRE Corporation
7515 Colshire Drive
McLean, Virginia 22102
USA
Phone: +1 (703) 983-6547
Email: kscott@mitre.org
Parikh, et al. Expires October 17, 2011 [Page 14]
Internet-Draft DTN SBEB April 2011
Robert Durst
The MITRE Corporation
7515 Colshire Drive
McLean, Virginia 22102
USA
Phone: +1 (703) 983-7535
Email: durst@mitre.org
Richard Edell
The MITRE Corporation
7515 Colshire Drive
McLean, Virginia 22102
USA
Phone: +1 (703) 983-7535
Email: redell@mitre.org
Parikh, et al. Expires October 17, 2011 [Page 15]