Internet DRAFT - draft-ravi-elastic-icn-packet-format
draft-ravi-elastic-icn-packet-format
ICN Research Group R. Ravindran
Internet-Draft A. Chakraborti
Intended status: Informational Huawei Technologies
Expires: January 7, 2016 July 6, 2015
Elastic ICN Packet Format
draft-ravi-elastic-icn-packet-format-00
Abstract
This draft proposes a new packet format motivated with the goal of
having a single protocol for constrained IoT and unconstrained
infrastructure segments of an ICN network. The packet format focuses
on reducing the transport overhead compared to the one proposed in
[1]. The resulting savings in terms of energy and computing is
significant for low power radios with restricted payload size.
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 7, 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
Ravindran & Chakraborti Expires January 7, 2016 [Page 1]
Internet-Draft Elastic ICN July 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposed Elastic ICN Packet Format . . . . . . . . . . . . . 2
3. Interest Packet Encoding . . . . . . . . . . . . . . . . . . 3
4. Content Object Encoding . . . . . . . . . . . . . . . . . . . 4
5. Packet Encoding Examples . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Motivation
The following points motivates this packet format proposal:
o Universality: One of the requirements in the ICN packet format
draft [5] is the need for universality, where the ICN protocol
should be equally applicable to both infrastructure capable of
transporting large payloads and also adaptable to small MTU
interfaces such as in IoT scenarios. The ICN packet format
proposal in this draft tries to achieve that.
o Transport overhead: One of the common situations in IoT scenario
is the constrained network segment, where sensors or actuators
operate over low power radio links such as 802.15.4, BTLE, or
proprietary ones such as SIGFOX [6] or LORA [7]. These radios
have restricted payload acceptance due to restricted MTU sizes,
such as 81B for 802.15.4, 22B for BTLE, or 12B in the case of
SIGFOX. In these scenarios, it is required to minimize the packet
overhead. The proposed 3B transport header compared to 8B fixed
header in CCNx1.0 [1] results in 6% less packet overhead for 15.4,
23% for BTLE, and 42% for SIGFOX.
o IoT Opportunity: Considering the plethora of non-interoperable
stacks such as Zigbee, AllSeen, Zwave etc, IoT is a greenfield
opportunity for ICN. Having one protocol specification applicable
to both constrained as well as to the infrastructure avoiding
protocol gateways could be a distinguishing factor for ICN.
2. Proposed Elastic ICN Packet Format
The objective of this proposal is to minimize the transport header
overhead by minimizing the bits used for certain fields compared to
the CCNx1.0 [1] proposal. The ICN message encoding follows the
CCNx1.0 specification. Overall, the proposed transport header
Ravindran & Chakraborti Expires January 7, 2016 [Page 2]
Internet-Draft Elastic ICN July 2015
definition offers 3 Byte fixed overhead compared to 8 Byte of
CCNx1.0.
The Elastic Interest and the Content Object encoding is discussed
next. As in CCNx1.0 [1], the ICN message is encapsulated in a
transport header. The proposed transport packet header has a 3 Byte
fixed portion to minimize the transport overhead considering
constraint scenarios, while other optional fields of the transport
header are encapsulated in a Extended Header TLV container, whose
existence is indicated with a flag in the 3 Byte fixed header.
3. Interest Packet Encoding
The Interest packet encoding is shown in Fig. 1 and corresponding
Extended Header TLV definition in Fig. 2:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Ver | Msg | Hop Limit | Length | Extended
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header TLV \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Interest Message \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 1: ICN Interest message format
0 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
+---------------+---------------+---------------+--------------+
| MessageType =T_EXTENDED_HEADER| Extended Header Len |
+---------------+---------------+---------------+--------------+
\ <Optional Length TLV> \
+---------------+---------------+---------------+--------------+
\ <Optional Interest Life Time TLV> \
+---------------+---------------+---------------+--------------+
\ ... \
Figure 2: Extended Header TLV Container for Interest
The general and Interest specific description of the fields in Fig. 1
and Fig. 2 are provided next:
Ravindran & Chakraborti Expires January 7, 2016 [Page 3]
Internet-Draft Elastic ICN July 2015
o E bit: This bit identifies the presence of an Extended Header TLV
in the Interest message.
o Version: These 3 bits identifies the ICN protocol version.
Smaller number space has been allocated considering significant
version changes happen only over longer time periods.
o Message type: These 4 bits identifies the message type, such as
Interest, Content Object etc, allowing 15 message primitives.
Considering the need to maintain the simplicity of the network
layer, we don't expect the number of primitives to exceed this
maximum limit. For the Interest case this message is set to type
Interest.
o Hop Limit: This field is only relevant to Interest messages. This
is set by the first CCN forwarder and decremented at every hop.
When the value is zero, the Interest is dropped.
o Length : This Byte is set to the size of the total ICN protocol
message which includes the fixed and Extended Header if present.
If the total packet size is greater than 255 Byte then this field
is set to 0x00; the total message length is then encoded in the
Extended Header using the Optional Length TLV.
o Extended Header TLV: This TLV container, shown in Fig. 2, is
identified with a new type code (T_EXTENDED_HEADER) and
encapsulates transport and Interest related metadata TLV such as
Optional Length or Interest lifetime. To minimize overhead we do
not exclude the possibility of having a fixed portion in the
Extended Header TLV container, such as for a reserved field, QoS
descriptors along with TLV encoded fields. The Extended TLV
encoding is shown in Fig. 2. The Extended Header Length is the
sum of all hop-by-hop TLVs included in the Extended Header TLV
container.
o ICN Interest Message: This is the ICN Interest message defined in
CCNx1.0 [1] proposal.
4. Content Object Encoding
The Content Object encoding is shown in Fig. 3, and the associated
Extended Header TLV container in Fig. 4.
Ravindran & Chakraborti Expires January 7, 2016 [Page 4]
Internet-Draft Elastic ICN July 2015
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Ver | Msg | Length | Extended
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Header TLV \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ICN Content Object Message \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 3: Extended Header TLV
0 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
+---------------+---------------+---------------+--------------+
| MessageType =T_EXTENDED_HEADER| Extended Header Length |
+---------------+---------------+---------------+--------------+
\ <Optional Length TLV> \
+---------------+---------------+---------------+--------------+
\ <Optional Cache Life Time TLV> \
+---------------+---------------+---------------+--------------+
\ ... \
Figure 4: Extended Header TLV Container for Content Object.
The field definitions are as follows:
o E bit: This bit identifies the presence of an Extended Header TLV
in the Content Object.
o Version: These 3 bits identifies the protocol version.
o Message type: This message is set to type Content Object.
o Length : The Content Object Length is defined in 2B and represents
the total packet length i.e. including the Content Object, fixed
and Extended header. The 2 Byte allows 64KB of total packet
length. If the packet length is larger than 64KB, then this field
is set to 0x0000 indicating that the packet length is encoded in
the Extended Header using the Optional Length TLV. This flexible
length definition allows large Content Object payloads, which is
further discussed later.
Ravindran & Chakraborti Expires January 7, 2016 [Page 5]
Internet-Draft Elastic ICN July 2015
o Extended Header TLV: The Extended Header TLV encoding is similar
to Fig.2. The container encapsulates network and Content Object
related metadata such as Optional Length and Cache lifetime. The
Extended Header Length is the sum of all hop-by-hop TLV included
in the Extended TLV container.
o Content Object Message: This is same as the Content Object in
CCNx1.0 [1] proposal. However, the proposed encoding allows
messages larger than 64KB. This is because of TLV encoding of
length in the Extended Header that allows multiple length type
definitions. For e.g., while the default is 2 Byte length in the
fixed header, a new type such as LEN_TYPE_4GB can be defined in
the Optional Length TLV in the Extended Header to encode Content
Object up to 4GB size. An example of a 4GB Content Object
encoding is shown in Fig. 8.
5. Packet Encoding Examples
Based on above discussion we present examples of packet encoding
here.
Example-1: Interest message with length less than 255 Bytes is shown
in Fig. 5.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Ver | Msg=I | Hop Limit | Length <255 | Interest
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 5: Encoding for Interest payload less than 255 Bytes.
Example-2: Interest payload with length up to 64KB is shown in Fig.
6. In this case, the Optional Length TLV in the Extended Header
encodes the size of the total Interest packet. The Optional Length
type DEFAULT indicates 2 Byte length field.
Ravindran & Chakraborti Expires January 7, 2016 [Page 6]
Internet-Draft Elastic ICN July 2015
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Ver | Msg=I | Hop Limit | 0x0000 |Type= T_EXTENDED
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_HEADER | Extended Header Len = 6 |Optional Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = DEFAULT| Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interest Message \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 6: Encoding for Interest payload up to 64KB.
Example-3: Content Object with length less than 64KB is shown in Fig.
7.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Ver | Msg=C | Length | Content Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Content
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Object Payload \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 7: Encoding for Content Object payload up to 64KB.
Example-4: A Content Object encoding capable of transporting up to
4GB Content Object is shown in Fig. 8. In this case a new type of
Optional Length TLV of type LEN_TYPE_4GB of size 4 Byte is defined in
the Extended Header.
Ravindran & Chakraborti Expires January 7, 2016 [Page 7]
Internet-Draft Elastic ICN July 2015
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Ver | Msg | Length=0x0000 |Type= T_EXTENDED
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_HEADER | Length = 8 | LEN_TYPE_4GB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4 | Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCN Msg Type =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content Object | LEN_TYPE_4GB | Content \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Object Payload \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ... \
Figure 8: Encoding for Content Object payload up to 4GB.
6. Security Considerations
The Elastic ICN packet format proposal doesn't raise any new security
considerations.
7. Informative References
[1] CCN Wire format, CCNX1., "http://www.ietf.org/id/
draft-mosko-icnrg-ccnxmessages-00.txt.", 2013.
[2] Osseiran, A., "Scenarios for 5G Mobile and Wireless
Communications: The Vision of the METIS Project.", IEEE
Communication Magazine , 2014.
[3] Forwarding-Label support in CCN Protocol, Forwarding-
Label., "https://tools.ietf.org/html/draft-ravi-ccn-
forwarding-label-00.", 2005.
[4] Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K.
Ramakrishnan, "COPS: An Efficient Content Oriented
Publish/Subscribe System.", ACM/IEEE Symposium on
Architectures for Networking and Communications Systems
(ANCS 2011) , 2011.
[5] "https://tools.ietf.org/id/draft-icn-packet-format-
requirements-00.txt.", 2015.
[6] SIGFOX, , "http://www.sigfox.com/en/".
Ravindran & Chakraborti Expires January 7, 2016 [Page 8]
Internet-Draft Elastic ICN July 2015
[7] LORA Alliance, , "http://lora-alliance.org/".
Authors' Addresses
Ravishankar Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ravi.ravindran@huawei.com
Asit Chakraborti
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: asit.chakraborti@huawei.com
Ravindran & Chakraborti Expires January 7, 2016 [Page 9]
