Network Working Group A. Detti
Internet-Draft S. Salsano
Intended status: Informational N. Blefari-Melazzi
Expires: April 2, 2012 Univ. of Rome "Tor Vergata"
September 30, 2011
An IPv4 Option to support Content Networking
draft-detti-conet-ip-option-01
Abstract
The Content Centric Networking paradigm, also known as Named Data
Networking, shifts the focus of networking from providing connections
between hosts to efficiently providing content to the users. The
work on CCN has traditionally been performed looking at "clean-slate"
solutions which aims to replace IP with a new paradigm. On the other
hand, in this memo we propose an "integration" approach to Content
Centric Networking, i.e. we extend the IP protocol using a new IP
Option. The new IP option is used by routers to support networking
based on content rather than (or better in addition to) end-point
addresses.
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 April 2, 2012.
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
Detti, et al. Expires April 2, 2012 [Page 1]
Internet-Draft IP option for CONET September 2011
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. CONET IP Option . . . . . . . . . . . . . . . . . . . . . . . 4
3. CONET protocol . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Interest CONET Information Unit (Interest CIU) . . . . . . 10
4.1.1. Processing in the end node . . . . . . . . . . . . . . 10
4.1.2. Processing in the serving node . . . . . . . . . . . . 10
4.1.3. Processing in the border node . . . . . . . . . . . . 11
4.1.4. Processing in the intermediate node . . . . . . . . . 11
4.1.5. Processing in the legacy routers . . . . . . . . . . . 12
4.2. Named data CONET Information Unit (Named data CIU) . . . . 12
4.2.1. Processing in the responding node . . . . . . . . . . 12
4.2.2. Processing in a border node . . . . . . . . . . . . . 13
4.2.3. Processing in an intermediate node . . . . . . . . . . 13
4.2.4. Processing in the legacy routers . . . . . . . . . . . 13
5. Routing by name framework . . . . . . . . . . . . . . . . . . 14
6. CONET default namespaces . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Performance Considerations . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Detti, et al. Expires April 2, 2012 [Page 2]
Internet-Draft IP option for CONET September 2011
1. Introduction
In this memo we propose a new approach to Content Centric Networking
[Koponen07][Jacobson09], based on extending the IP protocol by using
a new IP Option [RFC0791] called CONET IP option. The CONET IP
option can be used by routers to support content aware networking, in
addition to classical address based networking. The proposed
solution has been described in [CONET11].
The CONET IP option is used to identify the content which is the
object of the data transfer. Its usage allows efficient in-network
caching and replication of content.
The architecture foresees end hosts, serving nodes and CONET nodes.
End hosts require for content. Serving nodes provide content. CONET
nodes: i) route requests from end hosts to serving nodes; ii) deliver
content from serving nodes to end hosts; iii) may cache content and
therefore provide it to end hosts without contacting the serving
node. CONET nodes can be further classified in Border nodes and
Internal nodes. Border nodes are able to perform both "routing-by-
name" and caching, Internal nodes are not able to perform "routing-
by-name" (but only plain IP routing) and can only perform caching.
requests for content
------------------->
content is provided
<-------------------
+----+ +----+ +----+
| | --| |------| |
+----+\ / +----+ +----+
\ +----+ +----+ /
----| |------| |/
+----+ +----+
end node legacy intermediate border serving
router node node node
| |
+---------CONET next hop----------->+
Figure 1: CONET architecture
In addition to the new CONET IP option, the proposed solution needs a
new Internet Protocol Number to identify the CONET protocol.
Detti, et al. Expires April 2, 2012 [Page 3]
Internet-Draft IP option for CONET September 2011
2. CONET IP Option
The CONET IP option has the following format:
+--------+--------+--------+--------+
|100xxxxx|yyyyyyyy|ppppLLCr| NID |
+--------+--------+--------+--------+
| NID (variable length) |
| ... |
+--------+--------+--------+--------+
| CSN |optional CSN cont. ... |
+--------+--------+--------+--------+
Figure 2: IP Option
Type:
Copied flag: 1 (all fragments must carry the option)
Option class: 0 (control)
Option number: xxxxx (decimal) TO BE ALLOCATED BY IANA
Length:
yyyyyyyy: variable length of IP option in bytes (including the
Type and Length bytes
pppp : CONET Information Unit Type - This four bits field is used to
differentiate between different types of CONET Information Units
(CIUs)
0 Reserved
1 Interest CONET Information Unit (Interest CIU)
2 Named-data CONET Information Unit (Named-data CIU)
2-15 Reserved
LL : NID Length Specification - This two bits field provides the
length of Network Identifier (NID) field or specifies how the NID
length is provided.
0 16 bytes length
1 Reserved
2 NID starts with a one byte length field (NID length in bytes)
3 Reserved
C : cache indication - This one bit field is used to control cache
operations.
Detti, et al. Expires April 2, 2012 [Page 4]
Internet-Draft IP option for CONET September 2011
0 No cache
1 Cache
Within Information Units that request for content (e.g. interest
CIU), if the bit is set to "No cache" it indicates to the crossed
nodes not to look for the content in the cache, but to forward the
request toward the source. Within Information Units that carry
content (e.g. named-data CIU), if the bit is set to "No cache" it
indicates to the crossed nodes not to cache the content.
r : reserved - The last bit of the first byte after the option length
is reserved.
NID : Network Identifier (NID) field - The NID is a unique identifier
for the content. The NID is carried in the NID field. How to
determine the length of this field is defined by the NID Length
Specification field. If the NID Length Specification field
determines the field length, the NID field only carries the NID. If
the NID Length Specification field indicates that the field length is
carried in the field itself, the NID field starts with a one byte
field that determines its length.
If NID Length Specification = 0 (i.e. 16 bytes len),
the NID field is as follows:
+--------+--------+--------+--------+
| NID |
+--------+--------+--------+--------+
| |
+--------+--------+--------+--------+
| |
+--------+--------+--------+--------+
| |
+--------+--------+--------+--------+
If NID Length Specification = 2 (i.e. NID starts with a one byte
length field), the NID field is as follows:
+--------+--------+--------+--------+
| length | NID |
+--------+--------+--------+--------+
| ... |
+--------+--------+--------+--------+
| ... |
The NID starts with a two bytes field called NID namespace ID that
determines the structure of the rest of the NID. NID namespace
Detti, et al. Expires April 2, 2012 [Page 5]
Internet-Draft IP option for CONET September 2011
values needs to be assigned by the IANA. Note that in most
circumstances, the NID can be processed by the routers as an opaque
object, as described in Section 4. This is why the NID namespace ID
has been included at the beginning of the NID itself. In other cases
the nodes are requested to perform a routing-by-name procedure, which
may require a semantic understanding of the NID.
+--------+--------+--------+--------+
| NID namespace ID| ... |
+--------+--------+--------+--------+
| ... |
+--------+--------+--------+--------+
| ... |
+--------+--------+--------+--------+
| ... |
+--------+--------+--------+--------+
CSN : Chunk Sequence Number - This field carries the Chunk Sequence
Number that identifies a portion of the content. The assumption here
is that the content is split in a sequence of smaller unit called
"chunks". The Chunk Sequence Number is represented with a variable
number of bytes. An initial bit pattern determines the length of the
CSN field.
Detti, et al. Expires April 2, 2012 [Page 6]
Internet-Draft IP option for CONET September 2011
1 byte CSN (7 bits CSN range)
+--------+
|0 |
+--------+
2 bytes CSN (15 bit CSN range)
+--------+--------+
|10 |
+--------+--------+
3 bytes CSN (21 bit CSN range)
+--------+--------+--------+
|110 | | |
+--------+--------+--------+
4 bytes CSN (28 bit CSN range)
+--------+--------+--------+--------+
|1110 | | | |
+--------+--------+--------+--------+
5 bytes CSN (32 bit CSN range)
+--------+--------+--------+--------+
|11110000| | | |
+--------+--------+--------+--------+
| |
+--------+
6 bytes CSN (40 bit CSN range)
+--------+--------+--------+--------+
|11110001| | | |
+--------+--------+--------+--------+
| | |
+--------+--------+
Binary patterns from 11110010 to 11111111 are reserved. They can be
used to extend the CSN range if needed. With the above defined
option, we can have up to 2^40 chunks in a content. Assuming a
relatively small chunk size of 1 KBytes, it is possible to have a
content of 1099 TeraBytes, while assuming a more reasonable chunk
size of 256 Kbyte it is possible to have a content of 281474
TeraBytes (218 PetaBytes).
The rationale for having a variable length encoding is the following.
The CSN range for a given content is determined by the content size
divided by the chunk size. As content of very different sizes can be
transmitted, the CSN range can be very different. Therefore it is
not efficient to dimension this field considering the maximum number
Detti, et al. Expires April 2, 2012 [Page 7]
Internet-Draft IP option for CONET September 2011
of chunks in which a content can be split.
3. CONET protocol
In the previous section, we have seen the description of the CONET IP
option that is carried in the header of IP packets. The payload of
IP packets is the CONET protocol and a specific IP protocol number is
assigned to it:
CONET IP protocol number : xxx (to be assigned by IANA).
The figure below shows the CONET protocol stack. CONET protocol is
divided in two sub-layers, whose data unit are respectively denoted
as "Carrier Packets" and "CONET Information Units". A CONET
Information Unit (CIU) can be split into different Carrier Packets.
Each Carrier Packet is transported by an IP packet. There are
different types of CONET Information Units, the CIU type information
is carried in the CONET Information Unit Type field in the CONET IP
option.
+--------+--------+--------+ \
| CONET Information Units | |
+--------+--------+--------+ |- CONET protocol
| Carrier Packets | |
+--------+--------+--------+ /
| IP (with CONET IP option)|
+--------+--------+--------+
The generic structure of a Carrier Packet (CP) is reported hereafter:
+-------------------------+
| CP Payload header |
+-------------------------+
| CP Payload |
+-------------------------+
| CP Path state |
+-------------------------+
The information contained in the CP Payload header is specific for
each CIU type. It will be described in other specification
documents. The CP payload header contains the length of the CP
Payload and allows to identify the start of the CP Path state field.
The CP Path state field is used in end nodes, border nodes and
serving nodes to assist in the forwarding operation of carrier
packet, therefore it is described here.
Detti, et al. Expires April 2, 2012 [Page 8]
Internet-Draft IP option for CONET September 2011
The CP Path State field stores the end node address and the addresses
of the set of crossed border nodes in the path from end node to the
serving node (or to a border or intermediate node that provides a
requested content). The format of the CP path state field is
reported hereafter (assuming that IPv4 addresses are carried).
CP Path State field
+--------+--------+--------+--------+
|0 len | pointer| ad-type| addr 1 |
+--------+--------+--------+--------+
| addr 2 | addr 3 | addr 4 | ad-type|
+--------+--------+--------+--------+
| addr 1 | addr 2 | addr 3 | addr 4 |
+--------+--------+--------+--------+
| ... |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
|1 len | pointer |
+--------+--------+--------+--------+
| ad-type| addr 1 | addr 2 | addr 3 |
+--------+--------+--------+--------+
| addr 4 | ad-type| addr 1 | addr 2 |
+--------+--------+--------+--------+
| addr 3 | addr 4 |
+--------+--------+
The length field specifies the length of the CP Path State field in
bytes. If the first bit of the len field is 0, the remaining 7 bits
of the first byte are used as len field and both the length field and
the pointer field are one byte length. In this case the maximum
value of the length of the CP Path State field is 127. If the first
bit of the len field is 1, both the length field and the pointer
field are two bytes length. In this case the maximum value of the
length of the CP Path State field is 32767.
The pointer field specifies the offset, starting from the start of
the CP Path State field where the last address has been inserted.
Each address is represented as a couple (ad-type, address) it could
be represented by a triple (ad-type, ad-length, address) if the
address type is of variable length. The ad-type field is one byte
size and currently admitted values are:
Detti, et al. Expires April 2, 2012 [Page 9]
Internet-Draft IP option for CONET September 2011
0 Reserved
1 Public IPv4 address (len is 4 bytes, no ad-length needed)
2 Public Ipv6 address (len is 16 bytes, no ad-length needed))
3 Ethernet address (len is 6 bytes, no ad-length needed))
4-255 Reserved
Note that in the context of this document, only the IPv4 case is
covered. The definition of CONET protocols and procedures for IPv6
and for direct mapping into Ethernet are out of the scope.
4. Procedures
4.1. Interest CONET Information Unit (Interest CIU)
4.1.1. Processing in the end node
An end-node that wants to retrieve a content (or better a Chunk of a
content) issues an Interest CIU, the NID and the Chunk Sequence
Number of the required Content are respectively transported in the
Network Identifier (NID) field and in the CSN field of the CONET IP
option. The end-node stores its IP address in CP path state field,
initializing the pointer field. Assuming for simplicity that the
Interest CIU will fit into a single Carrier Packet, the Interest CIU
will be included in the Carrier Packet that in turn is inserted into
an IP packet.
The end-node must now determine the destination IP address for the
Carrier Packet. The end-node performs a routing-by-name, trying to
associate the NID with a next hop (i.e. with the IP address of the
next hop). The next hop can be the Serving Node (if the Serving node
is in the same CONET subnet of the end-node) or a Border Node of the
CONET subnet (if the Serving node is in a different CONET subnet).
Typically the end-node does not participate to the routing-by-name
protocols, therefore it cannot resolve the NID into the address of
the next hop, but it has to ask a name server. The name server is a
part of the so called Name System. Once this information is
retrieved by the name server, the end-note can fill the IP
destination address in the IP header and sends the packet. The end-
node may cache the mapping (NID -> next hop) into its memory as well.
4.1.2. Processing in the serving node
If the Serving Node is in the same CONET than the end-node, the
serving node IP address will be used a destination IP address by the
end-node. The Serving node will receive an IP packet directed to
itself, whose IP protocol number is "CONET". Therefore the packet
will be internally dispatched toward the "CONET entity" in the
Detti, et al. Expires April 2, 2012 [Page 10]
Internet-Draft IP option for CONET September 2011
Serving Node. The CONET entity reads the CONET information unit type
from the CONET IP options and recognizes that the received packet is
an interest packet. Then it reads the NID and Chunk Sequence Number
in the CONET IP option, the NID will correspond to a content provided
by the Serving Node. The CONET entity will then process the CONET
transport protocol information carried in the IP payload, which may
for example specify a requested offset within the chunk. Finally the
CONET entity will respond to the interest packet by sending the
requested named-data CIU.
4.1.3. Processing in the border node
If the Serving Node is in a different CONET than the end-node, the
address of a CONET border node will be used a destination IP address
by the end-node. The border node will receive an IP packet directed
to itself, whose IP protocol number is "CONET". Therefore the packet
will be internally dispatched toward the "CONET entity" in the border
node. The CONET entity reads the CONET information unit type from
the CONET IP options and recognizes that the received packet is an
interest packet. Then it reads the NID and Chunk Sequence Number in
the CONET IP option and is able to understand which content and which
part of the available content it needs to provide. If the Cache
indication field is set to "No Cache" or if the field is set to
"Cache" but the chunk is not available in the cache, the border node
starts the routing-by-name process. It will resolve the next hop of
the interest packet, which can be a serving node in a different CONET
subnet (with respect to the one from which the interest packet was
received) connected to the Border Node, or another Border Node in the
path toward the serving node. Before sending out the packet, the
border node adds its IP address in the CP Path State field and
updates the pointer field. Note that these procedures needs to be
performed in the "fast path" of the border node (in this case the
CONET entity in the border node can be seen as an integral part of
the enhanced IP protocol). If the Cache indication field is set to
"Cache" and the border node has found that the chunk corresponding to
the NID/CSN is available in its cache, the border node will process
the CONET transport protocol information carried in the IP payload,
which may for example specify a requested offset within the chunk and
it will respond to the interest packet by sending the requested
named-data CIU.
4.1.4. Processing in the intermediate node
When a packet is sent to the CONET next hop (as selected by the end
node or by a border node) using the IP destination address of the
next hop resolved by the routing-by-name, it can cross different IP
routers in the path from the sending node and the next hop. A
crossed router that is aware of the CONET IP option, is a CONET
Detti, et al. Expires April 2, 2012 [Page 11]
Internet-Draft IP option for CONET September 2011
intermediate node. This node may have cached the the chunk that is
requested by the interest packet. The intermediate node works as
follows. When processing the IP header for the received packet, it
finds that the packet contains the CONET IP option. If the Cache
indication field is set to "No Cache", the intermediate node forwards
the packet using the destination IP address. If the Cache indication
field is set to "Cache", the intermediate node checks the presence of
the chunk in its cache before forwarding the IP packet. Therefore,
it reads the NID and Chunk Sequence Number in the CONET IP option and
checks if the chunk is present in its cache. If the chunk is not
present, the normal IP processing is continued. Note that these
operations needs to be performed in the "fast path" of the router and
they only require information that is transported in the IP option.
If the chunk is present in the CONET router cache, the router will
process the CONET transport protocol information carried in the IP
payload, which may for example specify a requested offset within the
chunk and it will respond to the interest packet by sending the
requested named-data CIU.
4.1.5. Processing in the legacy routers
When a packet is sent to the CONET next hop (as selected by the end
node or by a border node) using the IP destination address of the
next hop resolved by the routing-by-name, it can cross different IP
routers in the path from the sending node and the next hop. If a
crossed router is a legacy router not aware of the CONET IP option,
it will simply forward the packet looking at the IP destination
address. Note that a requirement for such legacy router is to be
configured not to drop IP packets carrying unidentified IP options.
4.2. Named data CONET Information Unit (Named data CIU)
4.2.1. Processing in the responding node
The responding node is the node that is able to provide a content
(identified by NID and Chunk Sequence Number) to a requesting end-
node. Therefore the responding node can be a serving node which
provides an original copy of the content, or a border node /
intermediate node that provide a cached copy of the content. The
responding node will use the Path State information contained in the
received carrier packet carrying the Interest CIU to route back the
carrier packets containing the named-data CIU towards the requesting
end-node. In particular, it will use the pointer field to read the
last address in the list and will use it as IP destination address
for the Carrier packet carrying the named-data CIU. We can denote
this address as "CONET previous hop". Then it will update the
pointer field so that the next node will use the previous address in
the list. It may choose to strip the used address from the list in
Detti, et al. Expires April 2, 2012 [Page 12]
Internet-Draft IP option for CONET September 2011
the CP Path state, thereby reducing the CP Path State field length.
4.2.2. Processing in a border node
The border node will receive an IP packet directed to itself, whose
IP protocol number is "CONET". Therefore the packet will be
internally dispatched toward the "CONET entity" in the border node.
The CONET entity reads the CONET information unit type from the CONET
IP options and recognizes that the received packet is a named-data
packet. Again, we stress that this processing should be performed in
the fast path. Being a named-data packet, the border node will read
the CP Path State field in the Carrier Packet and by using the
pointer field will identify the CONET previous hop in the path
towards the requesting end-node. Before sending out the packet, it
will update the pointer field in the CP Path State field. The
destination IP address of the packet will be set to the CONET
previous hop retrieved from the CP Path State field. If the Cache
indication bit in the IP option is set to "Cache", the border node
may choose to cache the CIU that is transported by the carried
packet. In this case, it is reccomended that the border node
dispatches the packet as soon as possible and operates on a local
copy to perform cache related operations.
4.2.3. Processing in an intermediate node
An intermediate node, i.e. a router in the path between a serving
node or a border node and the CONET previous hop, which is aware of
the CONET option, may decide to cache the named data CIU transported
by a carrier packet. The intermediate node will receive an IP packet
with an IP destination equal to the CONET previous hop and will
immediately forward this packet using IP routing. Then, if the Cache
indication bit in the IP option is set to "Cache", the intermediate
node may choose to cache the CIU that is transported by the carried
packet.
4.2.4. Processing in the legacy routers
When a packet is sent to the CONET previous hop (as selected by the
serving node or by a border node) using the IP destination address of
the previous hop obtained using the CP Path State information, it can
cross different IP routers in the path from the sending node and the
previous hop. If a crossed router is a legacy router not aware of
the CONET IP option, it will simply forward the packet looking at the
IP destination address. Note that a requirement for such legacy
router is to be configured not to drop IP packets carrying
unidentified IP options.
Detti, et al. Expires April 2, 2012 [Page 13]
Internet-Draft IP option for CONET September 2011
5. Routing by name framework
The routing-by-name process is performed in the end-node and in
border nodes in order to resolve a NID into the next hop towards a
serving node for the given NID. This document provides a framework
under which the routing-by-name procedures can be performed, and
assures that different routing-by-name procedures and approaches may
coexist. These different approaches needs to be separately
specified. The format and the semantic of the NID may need to be
specified when defining a specific routing-by-name approach. This is
made possible by the concept of NID name space ID, which is carried
within the NID.
The basic procedure that a routing-by-name framework needs to offer
is called resolveNID, it takes as input the NID and returns the
next_hop_address. This procedure is performed by end-nodes and by
border nodes that are not able to provide a cached response for a
content requested by an end node.
resolveNid (NID) -> next_hop_address
The tables on which the routing-by-name procedures are based are
populated by serving nodes and by border nodes. The procedure is
initiated by serving nodes that advertize the hosted content with the
advertizeNID procedure. In turn, the procedure is replicated by the
border nodes that spread the received advertising toward other border
nodes. This procedure takes as input a NID, the address of the node
performing the procedure, and the path information towards the
serving node as seen by the node performing the procedure. Depending
on the specific routing-by-name approach, the path information can be
simply an hop count, or it could be the path list (as in the BGP AS-
PATH).
advertizeNid (NID, node_address, path_info)
In the following section we define two CONET default name spaces. It
could be more appropriate that in future version of this document
this specification is provided in a separate document.
6. CONET default namespaces
We define two default NID name spaces for CONET, one is based on
variable length strings as NID, as it was proposed in [Jacobson09],
the second one is based on fixed length hashes. The two namespaces
are assigned the following NID name space IDs.
Detti, et al. Expires April 2, 2012 [Page 14]
Internet-Draft IP option for CONET September 2011
+----------------------------------------------------------------+
| Namespace ID | |
+----------------------------------------------------------------+
| 1 | VLL (Variable Length Label) NID namespace |
+----------------------------------------------------------------+
| 2 | PLHB (Principal/Label Hash Based) NID namespace |
+----------------------------------------------------------------+
In the VLL (Variable Length Label) CONET namespace the NID is simply
the string representation of a resource. As described in
[Jacobson09] NIDs are hierarchically structured so that an individual
name is composed of a number of components (see [Jacobson09] for
further details. An authority is needed to ensure the uniqueness of
the NIDs. The approach should be similar on how the uniqueness of
DNS names is granted in today's Internet.
In the Principal/Label Hash Based CONET namespace the NID is the
composition of two hash values, as follows:
NID = ( hash (Principal) , hash (Label) )
In the Principal/Label Hash Based CONET namespace the Hash(principal)
is a 8 bytes hash of a string representing the Principal. The Label
is a 6 bytes hash of a string representing the label. A central
authority is needed to ensure the uniqueness of the Hash(principal),
i.e. a Principal cannot be assigned if its hash collides with an
already assigned hash. The Principal is responsible to ensuring that
each Hash(Label) belonging to the Principal are unique. Therefore a
Label cannot be used by a Principal if its hash collides with the
Hash of an already used Label.
7. Acknowledgments
We acknowledge the financial support by the EU in the context of the
CONVERGENCE research project.
8. Performance Considerations
IP Options have often been criticized because their support in
current routers would impose a performance penalty, but we can assume
here that routers will be modified to support Content Centric
Networking. Compared with "clean slate" approaches where CCN nodes
could be completely different with respect to routers, we believe
that we are able to provide all the functionality we need for Content
Centric Networking, with reasonable modification in router
Detti, et al. Expires April 2, 2012 [Page 15]
Internet-Draft IP option for CONET September 2011
architectures and preserving all the functionality of current IP
networking.
9. IANA Considerations
This document requires the allocation of one IP option by the IANA.
This document requires the allocation of one IP protocol number by
the IANA.
This document requires that IANA will maintain the registry of CONET
namespaces.
10. Security Considerations
Security considerations to be provided
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
11.2. Informative References
[CONET11] A. Detti, et al., "CONET: A Content Centric Inter-
Networking Architecture", ACM SIGCOMM Workshop on
Information-Centric Networking (ICN-2011), Toronto,
Canada , August 2011.
[Jacobson09]
V. Jacobson, et al., "Networking named content", Proc. of
ACM CoNEXT 2009 , 2009.
[Koponen07]
T. Koponen et al., "A data-oriented (and beyond) network
architecture", Proc. of ACM SIGCOMM 2007 , 2007.
Detti, et al. Expires April 2, 2012 [Page 16]
Internet-Draft IP option for CONET September 2011
Authors' Addresses
Andrea Detti
Univ. of Rome "Tor Vergata"
Via del Politecnico, 1
Rome 00133
Italy
Email: andrea.detti@uniroma2.it
Stefano Salsano
Univ. of Rome "Tor Vergata"
Via del Politecnico, 1
Rome 00133
Italy
Email: stefano.salsano@uniroma2.it
Nicola Blefari-Melazzi
Univ. of Rome "Tor Vergata"
Via del Politecnico, 1
Rome 00133
Italy
Email: blefari@uniroma2.it
Detti, et al. Expires April 2, 2012 [Page 17]