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 | +---------------+---------------+---------------+--------------+ \ \ +---------------+---------------+---------------+--------------+ \ \ +---------------+---------------+---------------+--------------+ \ ... \ 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 | +---------------+---------------+---------------+--------------+ \ \ +---------------+---------------+---------------+--------------+ \ \ +---------------+---------------+---------------+--------------+ \ ... \ 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]