Internet DRAFT - draft-mosko-icnrg-ccnxfragmentation
draft-mosko-icnrg-ccnxfragmentation
ICNRG M. Mosko
Internet-Draft PARC, Inc.
Intended status: Experimental July 1, 2015
Expires: January 2, 2016
CCNx End-To-End Fragmentation
draft-mosko-icnrg-ccnxfragmentation-01
Abstract
This document specifies an end to-end fragmentation protocol for
breaking a Content Object into several smaller pieces in order to fit
within a network MTU. The fragmentation protocol does not provide a
secure binding of the fragments to the original object. This is left
to the receiving endpoint. Midpoints may only serve fragments from
their cache if they have assembled and verified the complete Content
Object.
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 January 2, 2016.
Copyright Notice
Copyright (c) 2015 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
Mosko Expires January 2, 2016 [Page 1]
Internet-Draft CCNx TLV July 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
2.1. Interest Fragmentation . . . . . . . . . . . . . . . . . . 5
2.2. Content Object Fragmentation . . . . . . . . . . . . . . . 6
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Interest Header . . . . . . . . . . . . . . . . . . . . . 7
3.2. Content Object Header . . . . . . . . . . . . . . . . . . 8
4. Cache Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Mosko Expires January 2, 2016 [Page 2]
Internet-Draft CCNx TLV July 2015
1. Introduction
This document specifies an end-to-end fragmentation protocol for
breaking a Content Object into several smaller pieces in order to fit
within a network MTU. The fragmentation protocol does not provide a
secure binding of the fragments to the original object. This is left
to the receiving endpoint. Midpoints may only serve fragments from
cache if they have assembled and verified the complete Content
Object.
Packets are represented as 32-bit wide words using ASCII art.
Because of the TLV encoding and optional fields or sizes, there is no
concise way to represent all possibilities. We use the convention
that ASCII art fields enclosed by vertical bars "|" represent exact
bit widths. Fields with a forward slash "/" are variable bitwidths,
which we typically pad out to word alignment for picture readability.
TODO -- we have not adopted the Requirements Language yet.
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].
Mosko Expires January 2, 2016 [Page 3]
Internet-Draft CCNx TLV July 2015
2. Protocol Description
The principle of operation for fragmentation in CCNx 1.0 is that
intermediate systems should not have to fragment packets. An
Interest message is always fragmented to the minimum MTU size and the
forward path's MTU size is recorded in the Interest message so that a
system sending back a Content Object can fragment it to the the
correct size for the path. An intermediate system's Content Store
may store only pre-fragmented objects and respond only if those
fragments satisfy the requirements of an Interest's MTU, otherwise it
will be considered a cache miss.
Because the Interest is the path discovery mechanism for Content
Objects, all Interests MUST carry an InterestFragmentationHeader that
includes information about the forward path's MTU so the reverse path
MTU may be known at the node responding with a Content Object.
The minimum MTU required is 1280 octets. Any system implementing a
physical layer with a smaller MTU must implement link fragmentation,
for example using a PPP layer over the small MTU network.
Systems MUST create fragment streams in the most compressed packing.
That is, all fragments except the last MUST be fragmented to the same
size. This means that all Interests are fragmented to 1280 bytes
except the last fragment. A Content Object may be fragmented to any
size no more than the path MTU discovered, but all fragments except
the last MUST be the same size. This ensures that any two fragment
streams of the same Content Object with the same MTU have the same
representation.
When an end system creates a fragment stream, it generates a 64-bit
number for the FragmentStreamID. This number identifies a contiguous
stream of fragments and allows an end system to use the
FragmentStreamID for reassembly. An intermediate system uses the
FragmentStreamID of a Content Object to ensure that only one stream
of Content Object fragments follow a reverse PIT entry.
A system SHOULD use a random number for an Interest's
FragmentStreamID. This avoids easy denial-of-service attacks by
replying with junk for known fragment stream IDs. A fragmented
Content Object carries both its own FragmentStreamID, which SHOULD be
based on the ContentObjectHash, and the corresponding Interest
FragmentStreamID to facilitate matching on the reverse PIT path.
If the Maximum Path MTU of a Content Object fragment is larger than
the supported MTU on an egress interface, the fragment stream should
be dropped on that interface, even if some of the fragments fit
within the MTU.
Mosko Expires January 2, 2016 [Page 4]
Internet-Draft CCNx TLV July 2015
Fragments are identified by a serial counter FragNum, which ranges
from 0 - 63. Forwarders and end systems should drop duplicate
fragments, identified by the tuple {FragmentID, FragNum}.
If all fragments are not received within a system-dependent timeout,
a system re-assembling fragments should timeout. If the re-assembly
of an Interest times out before the PIT entry, the PIT entry on the
local system should be removed to allow a new fragment stream to
arrive. If the re-assembly of a Content Object times out, the
received fragments bitmask of the PIT should be cleared to allow a
new stream of Content Objects to arrive.
2.1. Interest Fragmentation
If an Interest does not fit with 1280 bytes, then it must be
fragmented to fit within 1280 bytes. There is no path MTU discovery
for Interests.
As an Interest goes through the FIBs, it records the minimum path MTU
based on the egress interface's MTU. A Content Object sent in
response must be fragmented to less than or equal to the minimum path
MTU. A forwarder may choose to put 1280 in the Minimum Path MTU
field even if it supports larger MTUs.
Interests follow the FIB and all fragments of an Interest (i.e. the
same fragment id) should follow the same FIB choices. If at a later
time a similar interest arrives with a smaller minimum path MTU, it
should be forwarded even though it is similar, to ensure that a
returned Content Object is fragmented to a size that satisfies the
Interest's path.
A forwarding node must examine the Interest name to determine its
forwarding. This requires that the forwarding node re-assemble the
front of the Interest to examine the name. In a typical case, this
means that the node must receive fragment 0 to have enough prefix
name components to compute the route. A system MAY discard out-of-
order fragments after fragment 0 during this re-assembly, and once
fragment 0 arrives and the system constructs a PIT entry with the
routing, it should send a control message along the Fragment Stream
ID's reverse path to cause the source to resend the interest stream,
which can now be forwarded out of order. Or, it may buffer out-of-
order fragments.
A system that receives an Interest encapsulated in a packet larger
than 1280 octets must discard it.
Mosko Expires January 2, 2016 [Page 5]
Internet-Draft CCNx TLV July 2015
2.2. Content Object Fragmentation
When forwarding a Content Object along the reverse path of the PIT, a
fragment stream may only be forwarded along reverse PIT entries for
which it satisfies the reverse path minimum MTU.
A PIT entry should only be removed once all fragments of a fragment
stream pass through, or it times out. Because the FragCnt is limited
to 63, a system may match a first stream's Fragment ID and use a
single 64-bit mask.
A Content Object is fragmented based on the Interest minimum path
MTU. It carries an "Maximum Fragment MTU" field set to the maximum
fragment size, which must be no more than an Interest's minimum path
MTU. Because a fragment stream may only satisfy PIT entries with
larger or equal minimum path MTU, all fragments must carry the
Object's fragmentation size. An intermediate node may, for example,
receive the last fragment first, so even if fragments were packed to
maximum size, the forwarder could not infer which PIT entries the
object satisfies without know the fragment stream's fragmentation
size
Mosko Expires January 2, 2016 [Page 6]
Internet-Draft CCNx TLV July 2015
3. Packet Formats
End-to-end fragmentation uses a hop-by-hop TLV header for
fragmentation. There is one header for Interests and one header for
Content Objects.
+--------+-----------+----------------------+-----------------------+
| Type | Abbrev | Name | Description |
+--------+-----------+----------------------+-----------------------+
| %x0006 | T_INTFRAG | Interest | Hop-by-hop |
| | | fragmentation header | fragmentation header |
| | | (Section 3.1) | for Interests. |
| | | | |
| %x0007 | T_OBJFRAG | Content Object | Hop-by-hop |
| | | fragmentation header | fragmentation header |
| | | (Section 3.2) | for Content Objects. |
+--------+-----------+----------------------+-----------------------+
Table 1: Hop-by-hop Header Types
Both fragmented Interests and Content Objects use the fields FragCnt
and FragNum. The count is the number of fragments in the message,
which has a minimum of 1. FragNum is the 0-based fragment number.
Sequential fragment numbers represent sequential byte boundaries of
the original object.
3.1. Interest Header
The field FragmentStreamID identifies a contiguous stream of
fragments. It SHOULD be a random number.
The field PathMinimumMTU is updated per-hop to measure the minimum
path MTU of the interest's reverse path.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTFRAG | LENGTH |
+---------------+---------------+---------------+---------------+
| FragmentStreamID |
| |
+---------------+---------------+---------------+---------------+
| PathMinimumMTU | X X | FragCnt | X X | FragNum |
+---------------+---------------+---------------+---------------+
Mosko Expires January 2, 2016 [Page 7]
Internet-Draft CCNx TLV July 2015
3.2. Content Object Header
The field FragmentStreamID identifies a contiguous stream of
fragments for the Content Object. It SHOULD be derived from the
Content Object's hash, so two objects with the same Fragment Stream
ID represent the same fragmented object.
The field InterestStreamID is the Fragment ID of the corresponding
Interest that the object is answering. This allows PIT matching
without having to reconstruct the Content Object. It makes Content
Objects specific to a given Interest similarity hash.
The field ObjectMaximumMTU is the maximum size of any fragment in the
fragment stream. This allows a forwarder to match a content object
fragment stream against a reverse path MTU size and not send a
fragment stream that will not fit down a path.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_OBJFRAG | LENGTH |
+---------------+---------------+---------------+---------------+
| FragmentStreamID |
| |
+---------------+---------------+---------------+---------------+
| ObjectMaximumMTU | X X | FragCnt | X X | FragNum |
+---------------+---------------+---------------+---------------+
| InterestStreamID |
| |
+---------------+---------------+---------------+---------------+
Mosko Expires January 2, 2016 [Page 8]
Internet-Draft CCNx TLV July 2015
4. Cache Considerations
Objects should be reassembled before sending from cache, to ensure
all fragments exist at the cache.
Single fragment Interests may be satisfied from cache. A system may
choose to reassemble Interests to try and answer from cache. If a
cache miss, the original fragment stream should be forwarded.
Mosko Expires January 2, 2016 [Page 9]
Internet-Draft CCNx TLV July 2015
5. Acknowledgements
Mosko Expires January 2, 2016 [Page 10]
Internet-Draft CCNx TLV July 2015
6. IANA Considerations
TODO: Work with IANA to define the type space for: Hop-by-hop header
types.
All drafts are required to have an IANA considerations section (see
Guidelines for Writing an IANA Considerations Section in RFCs
[RFC5226] for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section
will be removed during conversion into an RFC by the RFC Editor.
Mosko Expires January 2, 2016 [Page 11]
Internet-Draft CCNx TLV July 2015
7. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
Mosko Expires January 2, 2016 [Page 12]
Internet-Draft CCNx TLV July 2015
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[CCN] PARC, Inc., "CCNx Open Source", 2007,
<http://www.CCNx.org>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Mosko Expires January 2, 2016 [Page 13]
Internet-Draft CCNx TLV July 2015
Author's Address
Marc Mosko
PARC, Inc.
Palo Alto, California 94304
USA
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Mosko Expires January 2, 2016 [Page 14]
