Internet DRAFT - draft-wang-icnrg-container-resolution-system
draft-wang-icnrg-container-resolution-system
INTERNET-DRAFT Rong Wang
Intended Status: Informational Chunfeng Yao
Expires: August 21, 2013 Zhefeng Yan
Huawei
February 17, 2013
Container Resolution System in ICN
draft-wang-icnrg-container-resolution-system-00
Abstract
We illustrate the architecture and mechanism of container resolution
system, and to the protocol of resolving containers in ICN. The
fundamental characters are:1)Use Interest and Data packet as the
communication primitives, 2)Every routing node has FIB, CS, PIT
tables to do packet routing and caching. Current NDN/CCN architecture
does not require a resolution system. The routing is totally based on
prefixes of content names, which causes scalability and mobility
issues described in [Cisco-Name]. This draft addresses the
aforementioned issues.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires August 21, 2013 [Page 1]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
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.
Table of Contents
1 Container Name System . . . . . . . . . . . . . . . . . . . . . 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. System Architecture . . . . . . . . . . . . . . . . . . . . 3
1.3. System Components of CNS . . . . . . . . . . . . . . . . . 4
2 Container Name Scheme . . . . . . . . . . . . . . . . . . . . . 5
2.1 Content Name Composition . . . . . . . . . . . . . . . . . 5
2.2. Container name Registration . . . . . . . . . . . . . . . . 5
2.3 Unregister Container name . . . . . . . . . . . . . . . . . 7
2.4. Resolve Container name . . . . . . . . . . . . . . . . . . 7
2.5. Packet flow in network . . . . . . . . . . . . . . . . . . 9
3 Implementation of CNS . . . . . . . . . . . . . . . . . . . . . 11
4 Execution Engine Process Logic . . . . . . . . . . . . . . . . . 13
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Normative References . . . . . . . . . . . . . . . . . . . 14
7.2 Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Wang, et al. Expires August 21, 2013 [Page 2]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
1 Container Name System
1.1 Introduction This draft is the companion to [Huawei-name] and
illustrats the container resolution system (hereinafter referred to
as NRS) . The NRS assists the routing requirement of the container
name, which is the extension of conventional Information Centric
Networking (hereinafter referred to as ICN) naming.
1.2. System Architecture
An NRS is composed by a number of distributed container name systems
(hereinafter referred to as CNS) deployed in an ICN network. CNS
maintains the mapping from containers to its access containers. The
concept of container, container name, container set , container
assisted routing, resolvable container name, and access container are
described in [Huawei-name]. The following figure illustrates the high
level CNS architecture.
Network/Container A
_.----------.
/ +------+ \
( | CNS | )
\ +------+ /
`----------''
_.--------. Network/Container C
Network/Container B ,-'' `--.
_ _.--------. / +-----+ \
/ +------+ \ ( | CNS | )
/ | CNS | \ \ +-----+ /
\ +------+ / `--.`--------''_.-'
`--------''
Figure 1
For each container name, there is an authoritative CNS (hereinafter
referred to as A-CNS) acting as its final name resolution provider
and usually residing within the container (network). One container
can have an A-CNS for multiple containers. Other CNS can identify
the A-CNS of its container via the container name, e.g., with one of
the following methods:
-Use category tree hierarchy similar to current DNS, and configure an
A-CNS for each container.
-Leverage container assisted ICN routing mechanism to identify the A-
CNS of the container.
Since containers are part of the hierarchical tree or DAG of a
content name, they have to know their predecessor and successor(s) in
Wang, et al. Expires August 21, 2013 [Page 3]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
the tree or DAG [Huawei-name]. Thus CNS within a container has the
similar knowledge of its predecessor and successor(s). If a CNS of a
container cannot locate the A-CNS of its container, it asks the help
from its upper level CNS.
Registration and unregistration operation of a container has to be
done on its A-CNS. Other CNS, for example the CNS for the local
access container, proxies the registration and unregisration requests
to the A-CNS. In other words, the final resolution result of a
container name must come from its A-CNS. For any resolution request,
if an intermediate CNS has the result cached, then it can reply
directly, otherwise this CNS has to forward the request to its A-CNS,
and caches the resolution result according to the predefined policy.
1.3. System Components of CNS
CNS has 3 components, DataBase (hereinafter referred to as DB),
Execution Engine, and Network interfaces.
+----------------------------------+
| +------------------+ |
| Container | Database | |
| Name +------------------+ |
| System | Execution Engine | |
| +------------------+ |
| | Network Interface| |
| +/--|-------------+ |
+-----------/----|----------------+
________/ |
/ |
+------------/---+ +-----------|----+ +---------------+
| Customer | | Network | | Other |
| Client | | Device/ | | Container |
| End User | | Network | | Name |
| Device | | Services | | Systems |
+----------------+ +----------------+ +----------------+
Figure 2
Database stores resolution related data. Implementation details can
leverage current DB technologies or file systems.
Execution engine is responsible for processing resolution related
logic. It analyzes packet from network interface, operates on DB, and
sends operation result out of Network interfaces.
Network interfaces sends/receives ICN packets according to ICN
protocols. It receives Interest packet from client, end device,
network node, service or other CNS, and sends packet to the execution
Wang, et al. Expires August 21, 2013 [Page 4]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
engine for further processing. It forwards Data packet by following
the instruction from execution engine.
2 Container Name Scheme
2.1 Content Name Composition
We propose to reserve a few keywords in ICN for the container name
resolution operations. They are RESOLVE\REGISTER\UNREGISTER,
representing 3 primitive operations: as inquiry, registration and
unregistration, respectively. Keywords are configured automatically
or manually during ICN joining into the network.
Once a CNS with resolution capability joins into ICN, it publishes
aforementioned keywords(RESOLVE\ REGISTER \ UNREGISTER) according to
the ICN rules. Any ICN node who receives the published packet will
add table entries associated with those keywords to its FIB. All
those entries point to the CNS.
We then prefix resolution keyword to the content ID required
resolution to be the new content ID of ICN packet (Interest/Data).
Since each node in ICN use LPM to lookup FIB for forwarding, any
match of the keyword will route the resolution request to the
aforementioned CNS.
We can also use container assisted resolution to route packet to a
CNS. In this case, CNS publishes the name of the container that it
resides in [super container] to ICN according to ICN rules. Any node
in ICN will add routes accordingly. We can use the routing protocol
described in draft [Huawei-name] to route interest to CNS by adding
super container name as the suffix to aforementioned Content ID.
For example, CNS has published that it resides in the super container
named RESOLVER to the ICN. The interest to inquiry
"chinamobile/johndoe" can be composed as
"RESOLVE/chinamobile/johndoe|RESOLVER".
2.2. Container name Registration
The registration operation utilizes ICN protocol's Interest packet to
carry the request, and uses Data packet to carry the reply
(resolution result).
In details, information of container A registration includes:
"replace (Yes/No){access provider Container B/Container set C with
its properties (attributes)}", for example: "( replace=yes;){cn/gd/sz
; TTL =100 | hostsrv.com; resolvable=yes; TTL =5000; }". Where:
-Value of Replace field can be Yes or No (True/False?) If container A
Wang, et al. Expires August 21, 2013 [Page 5]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
exists in CNS,
--If Replace value is No: Insert the new resolution result to the
front of result list. If container B or container set C has already
existed in CNS, then delete the old result.
--If replace value is Yes: Directly replace the existing resolution
result with the new one.
--By default, "replace=no", even with the absence of REPLACE field.
--Example: "Register /chinamobile/johndoe" ->"(
replace=yes;){cn/gd/sz ; TTL =100 | hostsrv.com; resolvable=yes; TTL
=5000; }" For now, original resolution result of
"chinamobile/johndoe" will be invalid and will be replaced by
"cn/gd/sz" and "hostsrv.com"
-Resolvable value (Yes/No): Whether the resolution result (container
B/container set C) can be resolved again. The operation of recursive
resolution can be seen as the expansion of resolution results. The
expansion resolution can be done when writing to Database, or when
resolution system idling, or when receiving a resolution request.
-(Optional) TTL (Unit Second): Time of the resolution result can be
cached. The result will not be cached if this value is 0.
Registration information can be put into Selector field. A new
property, RESOLVE is added to represent name solution (see Figure 3)
to hold register and unregister information.
In the Data packet, it also carries the success or failure
information of the registration operation. In this reply Data packet,
the "signed info" field has to set as "no caching" (This is
implementation dependent), this setting ensures upcoming Interest
requests will not be replied by the intermediaries but the CNS.
Aforementioned content name register and unregister information , it
can be put directly into content name field rather than in Selector
field. The whole content name will be composed of content ID and
content name register/unregister information. As illustrated in
Figure 4.
Interest Packet
+--------------+ +----------+ +-----------------------+
| REGISTER | | Content | | resolve=(replace=yes) |
| /chinamobile |===>| Name | | {|cn/gd/sz ; TTL =100 |
| /johndoe | +----------+ | | hostsrv.com; |
| | RESOLVER | | Selector |<====| resolvable=yes; |
+--------------+ +----------+ | TTL =5000} |
| Nonce | +-----------------------+
+----------+
Figure 3
Wang, et al. Expires August 21, 2013 [Page 6]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
+-------------------------+ Interest Packet
| REGISTER/chinamobile/ | \ +-------------------------+
| johndoe=(replace=yes) | \ | Content Name |
| {| cn/gd/sz ; TTL =100 | /===>+-------------------------+
| | hostsrv.com; | / | Selector |
| resolvable=yes; | / | (Order Preference,...) |
| TTL =5000} | RESOLVER |/ +-------------------------+
+-------------------------+ | Nonce |
+-------------------------+
Figure 4
2.3 Unregister Container name
The purpose of this operation is to unregister the access container
B/container set C for container A. In other words, container
B/container set C is removed or voided from container A's resolution
result list. This operation piggybacks on ICN protocol's Interest
packet to carry the request, and leverages Data packet to carry the
reply.
In details, the unregistration information of a container name looks
like: "{access provider container B/container set C}". For example,
"{cn/gd/sz ; | hostsrv.com;}". This information is in the new added
properties in Selector field similar to that of registration
operation.
-If container A does not exist in CNS, or there is no aforementioned
container B/container set C as the resolution result of container A,
then CNS replies failure status.
-If there are resolution results, remove them from CNS.
-If all resolution results are removed successfully, then reply
"total success", otherwise, reply "partial success" with failed
portions and reasons. The common reason is "non-exist".
-If resolution result of container A does not exist, then remove
container A from CNS. The operation result will be carried back by
Data Packet similar to that of registration. The Data Packet will be
set as uncacheable.
2.4. Resolve Container name
The purpose of this operation is to obtain container B/container set
C which provides access service for container A. This operation
utilizes ICN protocol Interest Packet to carry the request, and Data
packet to carry the resolution result.
In details, the carried packet has to include content name A. For
example "chinamobile/johndoe"
Wang, et al. Expires August 21, 2013 [Page 7]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
The resolution result is carried back by Data packet in the Data
field, for example, "airchina/ca1314; resolvable=yes;ttl=5000; |||
cn/beijing; ttl=1000;||hostsrv.com ||| cn/gd ||| cn/beijjing |||
us/ca", CNS will do the following:
-If content name A does not exist in the CNS, then replies "failed"
or NULL.
-Return the resolution result of container A in order. If the result
container name has the "resolvable=yes" property, then it can be
further resolved. The resolution results can be inserted in the
original result by following the method described in [Huawei-name]
-If the result has TTL property, the caching timer at Signed Info
field of Data packet (implementation details may be different, for
example, in CCN, it is FreshnessSecond, in NDN it is staletime) will
be set as the minimum of TTL (in previous example, it is 1000)
-The intermediaries ICN nodes can cache the resolution results in its
Content Store (hereinafter referred to as CS). Cache Time can be
processed according to ICN rules. Request packet is shown in Figure
5.
+------------------------------------------+
| {johndoe.com/blog/2012/June01/main.html |
| | chinamobile/johndoe; resolvable=yes} |
+------------------------------------------+
| First iteration of resolution
V
+-----------------------------------------------+
| {johndoe.com/blog/2012/June01/main.html |
| | chinamobile/johndoe; resolvable=yes |
| || airchina/ca1314 ; resolvable=yes; ttl=5000 |
| || hostsrv.com; resolvable=yes; ttl=1000} |
+-----------------------------------------------+
| Second iteration of resolution
V
+-----------------------------------------------+
| {johndoe.com/blog/2012/June01/main.html |
| | chinamobile/johndoe; resolvable=yes |
| || airchina/ca1314; resolvable=yes; ttl=5000 |
| ||| cn/beijing; ttl=1000 |
| ||hostsrv.com |
| ||| cn/gd ||| cn/beijjing ||| us/ca} |
+-----------------------------------------------+
+--------------+ Interest Packet
| REGISTER | +-------------------------------+
| /chinamobile }===>| Content Name Container(s) |
| /johndoe | +-------------------------------+
| | RESOLVER | | Selector |
+--------------+ +-------------------------------+
| Nonce |
+-------------------------------+
Wang, et al. Expires August 21, 2013 [Page 8]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
Data Packet +-----------------------------+
+---------------+ | RESOLVE/chinamobile/johndoe |
| Content |<===+-----------------------------+
| Name | +-----------------------------------+
+---------------+ | |airchina/ca1314; resolvable=yes; |
| Signature | | ttl=5000 |
+---------------+ | || cn/beijing; ttl=1000 |
| Signed Info |<===| |hostsrv.com; resolvable=yes; |
+---------------+ | ttl=1000 |
| Data | | || cn/gd || cn/beijing || us/ca |
+---------------+ +-----------------------------------+
Figure 5
2.5. Packet flow in network
Packet flow of a client/request node requesting container
registration/unregistration is shown in Figure 6.
,-----.
,---' `-.
; +----------+
: | A-CNS | `.
+--------=-+ ) Interest
`+- `YO. / +--------------+
Data `---'^`--`OL-' |REGISER |
+------------+ `Ob |/chinamobile |
|REGISER | `Ob |/johndoe|CMCC |
|/chinamobile| `OL +--------------+
|/johndoe | ,-. ,OP
+------------+ _.--' `-dO'-.
_.-------'' +--'--++-.
,-'' dOP| CNS | |Interest
( +------+ ,ooOP' +-----+ |+------------+
\ | ICN |(O' ;|REGISER |
\ | Node | ,-' |/chinamobile|
`. +----do+ ,----' |/johndoe |
+--. `YO. / +------------+
_:Oo.----'
++'' 'YOo.
Data 7O[
+------------+ +-`"---+ +--------+
|REGISER | | ICN ,oooo End |
|/chinamobile| | Node |'''' Device |
|/johndoe | +------+ +--------+
+------------+
Figure 6 container registration/unregistration
-Utilize Interest Packet to request name resolution to ICN.
-Local CNS processes the Interest Packet first.
Wang, et al. Expires August 21, 2013 [Page 9]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
-If the local CNS is the aforementioned A-CNS of this container, then
registration will be done. A Data packet with result will be sent
back.
-If not, the Interest packet will be routed out to the next level CNS
or A-CNS (for example, CMCC) of container A, per the preset rules,
until the registration/unregistration operation can be done on A-CNS.
-The intermediaries CNS will forward the Data packet to the original
requester once it receives the Data packet from next level CNS or A-
CNS.
-Data packet of Register/Unregister does not allow to cache by
intermediaries. This can be done by set "no-caching" in Data packet
in ICN protocol.
Packet flow of a client/a node requesting a resolution of container
is shown in Figure 7.
Data
+-------------+
|RESOLVE | +-----+
|/chinamobile | |A-CNS|
|/johndoe | +-----+ Interest
+-------------+ +------+ / +-------------+
Data |Local |/ |RESOLVE |
+-------------+ |CNS | |/chinamobile |
|RESOLVE | +-+----+ |/johndoe |
|/chinamobile | | | | CMCC |
|/johndoe | | +-------------+
+-------------+ |
Content Store +-+--+
+----------+----------+ |ICN | +----+ Interest
| Name | Data | |Node|------|ICN | +-------------+
+----------+----------+ +-+--+ .'Node| |RESOLVE |
| RESOLVE | airchina | / .-' +----+ |/chinamobile |
| /china | /ca1314; | / .' |/johndoe |
| mobile | resolved | +---++ .-'Interest | | RESOLVER |
| /johndoe | =yes; | |ICN |.' +-------------+ +-------------+
| | ... | |Node| |RESOLVE |
+----------+----------+ +-+--+ |/chinamobile |
| |/johndoe |
| | | RESOLVER |
+---+-----+ +-------------+ +--+------+
|requester| |requester|
+---------+ Data +---------+
+-------------+
|RESOLVE |
|/chinamobile |
|/johndoe |
+-------------+
Figure 7 resolution of container
Wang, et al. Expires August 21, 2013 [Page 10]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
-Utilize Interest Packet to request name resolution to ICN.
-Local CNS processes the Interest Packet first.
-If local CNS can resolve the request, it returns a Data packet with
resolution result.
-If it cannot be resolved, then appends the name of next level CNS or
the name of A-CNS (for example, CMCC) of container A by following the
preset rules. Route the Interest packet accordingly.
-After gets Data packet back from next level CNS or A-CNS, then it
inserts the resolution result into its Database. It generates a new
Data Packet.
-The intermediaries passed by Data packet will forward the Data
packet as well as cache it in its CS table, according to the content
forwarding rule.
-If the same request comes into this intermediary, then Data packet
will be fetched from cache and return back to requester, according to
the content forwarding rule.
3 Implementation of CNS
Aforementioned CNS is based on ICN node (support ICN protocol at
lower level). It is responsible for name registration and resolution.
It can be part of a resolution system together with other CNS'.
Any end device/network device/service can register its access
container/container set in the CNS to enable other devices and
services to inquiry them. Meanwhile, it has the capability to work
seamlessly with other CNS.
As illustrated by Figure 8, John Doe applied a personal domain name
"chinamobile/johndoe", China Mobile provides access service for him.
Current access location is Shenzhen, Guangdong. Thus he registered
the container as "cn/gd/sz"; the same user applied a third party
(Hostsrv) to provide him with service. The name of the specific
access container of the service can be obtained via resolution lookup
(For example, Hostsrv provides 3 DCs for John Doe at "cn/gd",
"cn/Beijing", and "us/ca"). Thus the container is registered as
"hostsrv.com resolvable=yes". Once ICN receives Interest packet with
name "chinamobile/johndoe", it sends resolution request to CNS. After
two iterations of resolutions, NRS returns the resolution results.
Interest
+-----------------------+
|Content Name = |
+------------------+ |{johndoe.com/blog |
|Register | |/2012/June01 |
|/chinamobile | |/main.html |
|/johndoe --> | | |chinamobile/johndoe; |
Wang, et al. Expires August 21, 2013 [Page 11]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
|(replace = yes) |----------+ | resolvable=yes} |
|{| cn/gd/sz ; | | +-----------------------+
| TTL =100 | |
| |hostsrv.com; | |
| resolvable=yes; | v +---------------------+
| TTL =5000} | +----+ |RESOLVE |
+------------------+ |CNS | |/chinamobile/johndoe |
+----+ +---------------------+
+--------------------+ ^
|Register | | +-----------------------+
|/hostsrv.com --> | | |{|cn/gd/sz ; TTL =100 |
|{|cn/gd ; | | | |hostsrv.com; |
| TTL =10000 |--------+ | resolvable=yes; |
| |cn/beijing ; | | TTL =5000} |
| TTL =10000 | +-----------------------+
| |us/ca; TTL =5000} | |
+--------------------+ V
+-----------------------+
|{|cn/gd/sz ; |
| TTL =100 |
| |hostsrv.com; |
| resolvable=yes; |
| TTL =5000 |
| ||cn/gd ; TTL =10000 |
| ||cn/beijing ; |
| TTL =10000 |
| ||us/ca; TTL =5000} |
+-----------------------+
Figure 8
Another implementation method is to return the direct resolution
result. If client wants to resolve the resolvable container, then it
can send another resolution request. Figure 9 illustrates the
procedure.
Interest
+-----------------------+
|Content Name = |
+------------------+ |{johndoe.com/blog |
|Register | |/2012/June01 |
|/chinamobile | |/main.html |
|/johndoe --> | | |chinamobile/johndoe; |
|(replace = yes) |----------+ | resolvable=yes} |
|{| cn/gd/sz ; | | +-----------------------+
| TTL =100 | |
| |hostsrv.com; | |
| resolvable=yes; | v +---------------------+
| TTL =5000} | +----+ |RESOLVE |
Wang, et al. Expires August 21, 2013 [Page 12]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
+------------------+ |CNS | |/chinamobile/johndoe |
+----+ +---------------------+
+--------------------+ ^
|Register | | +-----------------------+
|/hostsrv.com --> | | |{|cn/gd/sz ; TTL =100 |
|{|cn/gd ; | | | |hostsrv.com; |
| TTL =10000 |--------+ | resolvable=yes; |
| |cn/beijing ; | | TTL =5000} |
| TTL =10000 | +-----------------------+
| |us/ca; TTL =5000} |
+--------------------+ +---------------------+
|RESOLVE |
|/hostsrv.com |
+---------------------+
+-----------------------+
|{||cn/gd ; TTL =10000 |
| ||cn/beijing ; |
| TTL =10000 |
| ||us/ca; TTL =5000} |
+-----------------------+
Figure 9
4 Execution Engine Process Logic
Detailed steps:
1.Is the receiving packet Interest packet or Data packet? If it is
interest packet, go to step 2, otherwise, go to step 10.
2.Check operation type. If it is "register/unregister" type, then go
to step 3. If it is "resolve" type, then go to step 8
3.Use this node as A-CNS? Yes, go to step 4, otherwise go to step 9.
4.If it is "register" type, go to step 5, otherwise remove container
names identified by Interest packet from the result list, go to step
12.
5.If container name about to register exists, go to step 6,
otherwise, add new container name and associated resolution results
to Table. Generate Data packet with successful status, go to step 7.
6.
i.If "replace=true", then replace the existing resolution results
with the ones carried from interest packet, generate Data packet with
successful status, go to step 7.
ii.If "replace=false" or no replace property, then insert resolution
results from interest packet to the front of the container list. If
container name in interest packet is the same as of old resolution
results, remove original associated table entry. Generate Data packet
with successful status, go to step 7.
7.(This optional step can be skipped and directly go to step 12).
Traverse resolution results; index all resolvable containers. If a
Wang, et al. Expires August 21, 2013 [Page 13]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
resolvable container can't be resolved locally, then route Interest
packet to the next level CNS or A-CNS of the container name. Wait for
result carried back by Data packet. If the result is NULL, this
container name cannot be resolved. Return failure status in Data
packet, otherwise, create index to the next level resolution.
Generate a complete Data packet with resolution results from all
iterations, go to step 12.
8.
i.Does container name exist in the table? If not, then go to step
9. If yes, then traverse all resolution results, insert generated
Data packet. Go to step 12 after all results have been checked.
ii.(Optional Step) If some of the results are resolvable
("resolvable=yes"), then resolve the container recursively by using
this step. If the same result has been resolved (the same container
name has been packaged into Data Packet), then ignore the result, and
keep the traverse the next item (container name).
9.Append container name of next level CNS or A-CNS to the content ID
in Interest Packet per preset policy. If there is a container name
associated to the node, remove it. Generate a new Interest packet and
route it out, and waiting for the returning Data packet.
10.If the reply Data packet is for register/unregister request,
forward Data packet to the original requester, go to step 12. If the
reply Data packet is for resolution request, go to 11.
11.Create table entry per the content ID (container name in this
context) and resolution result within the Data packet, If the same
container name exists, replace or remove it from the table per the
preset rules. Generate Data packet based on local table results. If
resolution result is NULL then no table entry is created. If this
resolution is triggered by previous REGISTER resolution, go to step
7, otherwise, it is caused by RESOLVE resolution, go to step 6.
12.Call network interface module to forward Interest or Data packet.
5 IANA Considerations
No IANA consideration for this draft.
6 Conclusions
7 References
7.1 Normative References
7.2 Informative References
[Cisco-Name]
NDN and IP Routing, Can it Scale?
http://trac.tools.ietf.org/group/irtf/trac/raw-
attachment/wiki/icnrg/IRTF%20-
Wang, et al. Expires August 21, 2013 [Page 14]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
%20CCN%20And%20IP%20Routing%20-%202.pdf
[CCN] V. Jacobson et al. Networking named content. Proceedings
of the 5th ACM International Conference on Emerging
Networking Experiments and Technologies (CoNEXT 2009). NY:
ACM; 2009; 1-12.
[ICN-name] Ali Ghodsi et al. Naming in Content-Oriented
Architectures. In ACM ICN workshop, 2011.
[SCN] D. Smetters and V. Jacobson. Securing Network Content.
Technical report, PARC, October 2009.
[Huawei-Name]
Draft-ietf-icnrg-icn-naming-and-routing-00.txt.
Wang, et al. Expires August 21, 2013 [Page 15]
INTERNET DRAFT ICN-Naming-Routing February 17, 2013
Authors' Addresses
Rong Wang
Huawei Technologies
Huawei Building,
BanTian, LongGang District
Shenzhen, GuangDong 518129
P.R.CHINA
EMail: WANG.RONG@huawei.com
Chunfeng Yao
Huawei Technologies
Huawei Building,
No.156, BeiQing Rd., Haidian District
Beijing, 100095
P.R. CHINA
EMail: chunfengyao@huawei.com
Zhefeng Yan
Huawei Technologies
Huawei Building,
BanTian, LongGang District
Shenzhen, GuangDong 518129
P.R.CHINA
EMail: yanzhefeng@huawei.com
Wang, et al. Expires August 21, 2013 [Page 16]
