Internet DRAFT - draft-xie-icnrg-hybrid-routing
draft-xie-icnrg-hybrid-routing
Information-Centric Networking Research H. Xie
Group Huawei & USTC
Internet-Draft Y. Sun
Intended status: Informational Institute of Computing
Expires: August 22, 2013 Technology
G. Wang
Huawei (USA)
H. Wu
J. Li
Institute of Computing
Technology
February 18, 2013
Scalable Hybrid Routing for Information-Centric Networks
draft-xie-icnrg-hybrid-routing-00
Abstract
Name-based routing in information-centric networks faces many
challenges, one of which is the scalability challenge; in particular,
content routers may not have sufficiently large FIB to store a large
portion of name prefixes, even if the latter are aggressively
aggregated. In many ICN designs routers have to rely on inefficient
mechanisms (e.g., Interest broadcast in content-centric networks) in
order to route requests. In this draft, we describe a hybrid,
reactive routing approach, where we augment the information-centric
network design with an Infrastructure Information Base (IIB) to reap
the benefits of both name-based and infrastructure-based routing.
Simulation-based evaluations demonstrate that this scheme can
significantly improve the network scalability by cutting down the
number of broadcast packets while maintaining the same level of the
user-perceived latency.
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."
Xie, et al. Expires August 22, 2013 [Page 1]
Internet-Draft ICN routing February 2013
This Internet-Draft will expire on August 22, 2013.
Copyright Notice
Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Xie, et al. Expires August 22, 2013 [Page 2]
Internet-Draft ICN routing February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Observations and Design Considerations . . . . . . . . . . 5
3.1. Proactive Routing vs. Reactive Routing . . . . . . . . . . 5
3.2. Interest Broadcast . . . . . . . . . . . . . . . . . . . . 6
3.3. Interest Starvation Problem . . . . . . . . . . . . . . . 7
4. A Hybird, Reactive Routing Scheme for ICN . . . . . . . . . . 8
4.1. Content Router . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Packet Handling . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. Handling Interest Packet . . . . . . . . . . . . . . . 12
4.3.2. Handling Data Packet . . . . . . . . . . . . . . . . . 13
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Xie, et al. Expires August 22, 2013 [Page 3]
Internet-Draft ICN routing February 2013
1. Introduction
Recently Information-Centric Networking (ICN) has become an
increasingly popular research topic and many exciting efforts have
been made. Among these efforts, two closely related proposals,
Content-Centric Network (CCN) [1] and Named Data Networking (NDN)
[2], are attracting more and more attention. It has been a common
belief that future networks are likely content-centric or
information-centric, enabling the paradigm shift from the traditional
"host-to-host" communication model to the ``host-to-content'' or
``host-to-information'' model. Researchers have made rapid
progresses towards this direction in recent years.
The name-based routing adopted by many ICN designs enables the new
``host-to-content'' or ``host-to-information'' communication model.
In many ICN designs, content and information objects (referred to as
content for short hereafter) have structured names. A content origin
who owns the original content objects announces name prefixes into
the network. Such announcements can be propagated throughout the
network (e.g., via intradomain routing protocols such as OSPF). For
instance, in CCN, the Forward Information Base (FIB) in each router
stores to which interface ("face") the router should forward any
request for a named content matching a given name prefix. Upon
receiving name prefix announcements, each router updates its FIB
accordingly. Clients send Interest packets requesting for interested
content, and the network responds with Data packets of the requested
content. ICN also introduce two new components to content routers:
Content Store (CS) and Pending Interest Table (PIT). CS is leveraged
to store cacheable content objects in order for efficient content
distribution, and PIT is used to aggregate pending Interests for the
same content and propagate Data packets, potentially in a multicast
manner, towards the requesting clients.
2. Challenges
Name-based routing in information-centric networks also poses new
concerns on network scalability. We use CCN as an example to
illustrate the main concerns:
o Firstly, name prefix announcements in ICN have to be propagated
throughout the network via either intradomain protocols such as
OSPF or the like. However, the number of distinct name prefixes
is expected to be enormously large; for instance, Google announced
in July 2008 that the number of unique URLs it processed had
exceeded 1 trillion. Even after extremely aggressive aggregation,
the top-level name prefixes could still be enormously large.
Statistics have shown that as of December 2011, the Internet has
Xie, et al. Expires August 22, 2013 [Page 4]
Internet-Draft ICN routing February 2013
more than half a billion domain names and that the number of
domain names has doubled in the past three years. To propagate
such an enormously large number of name prefixes can be a daunting
task in that it could not only dramatically overload routers but
also consume a significant portion of network bandwidth.
o Secondly, the number of name prefixes is likely to be multiple
orders of magnitude larger than what FIB can store, and the gap
between these two mismatching numbers is likely to sustain.
Hence, only a small portion of name prefixes could possibly be put
in FIB. As a result, FIB misses (i.e., FIB has no knowledge about
where to forward Interests) could be common and name-based routing
has to heavily rely on some fall-back schemes (e.g., broadcast
Interests), most likely on the slow path, to address FIB misses.
This could dramatically degrade network performance and user
experiences.
o Last but not least, the current fall-back scheme adopted in CCN,
namely, flooding Interests via broadcast on FIB misses, could
become another dominating source overloading routers, consuming a
significant portion of network bandwidth, and degrading network
performance.
In this draft, we consider the number of flooded packets as a metric
suggesting the level of scalability, and describe a hybrid, reactive
name-based routing approach in an attempt to address the
aforementioned challenges on scalability in ICN.
3. Key Observations and Design Considerations
We first describe a few key observations and design considerations in
order to help understand the aforementioned challenges. We use CCN
as an example scenario for concreteness.
3.1. Proactive Routing vs. Reactive Routing
In many of the current ICN design, content origins (or their first-
hop routers) are expected to pro-actively and periodically announce
name prefixes that are owned by them, similar to how IP prefixes are
announced in an intradomain network. We refer to this scheme as the
proactive routing scheme. For example, in CCN, re-using intradomain
routing protocols (e.g., OSPF with ICN adaptation) is proposed to
propagate name prefixes to all routers in intradomain networks (see,
e.g., [1]).
However, proactive routing schemes face significant challenges due to
the fact that the number of name prefixes can be tremendously large
Xie, et al. Expires August 22, 2013 [Page 5]
Internet-Draft ICN routing February 2013
in practice. This has significant impacts on both network control
overhead and FIB. More specifically, it is likely that the number of
name prefixes is at least at the scale of domain names in the
Internet, such re-use of OSPF-like proactive schemes could easily
lead to stringent challenges on network scalability. For instance,
assuming domain names with an average length of 16 bytes,
announcements of 0.5 billion domain names can generate as high as 8
billion bytes of traffic; if these names are announced in 1-minute
intervals, then on each network link, the average bandwidth consumed
by periodical active announcements alone is about 1 Gbps. Moreover,
most likely the number of name prefixes, even after aggressive
aggregation, is still much larger than the number of domain names.
If the former is 10 times larger, then link bandwidth consumption due
to name prefix announcement alone can be as high as 10 Gbps. At this
scale, it is likely that FIB can only store a limited, small number
of name prefixes; thus FIB misses are not uncommon.
An alternative approach is the reactive routing scheme; namely, name
prefixes are announced only when Interests for those prefixes are
injected into the network. We believe that this scheme can be more
preferable in information-centric networks. On the one hand,
proactive announcements consume a significant portion of network
bandwidth and may overload routers. When taking content popularity
into account, announcing name prefixes for rarely or never accessed
contents significantly wastes network bandwidth. On the other hand,
because FIB sizes are multiple orders of magnitude smaller than the
number of name prefixes, most name prefixes would not be able to fit
in FIB; therefore, announcing such name prefixes not only wastes
network bandwidth but also overload routers.
The rationale behind the reactive routing scheme is that since FIB
misses are inevitable, we should not require all names prefixes be
squeezed into FIB (aggregation can still help to put as many prefixes
as possible into FIB though). Instead, only those name prefixes that
can maximize the network utility (e.g., reduce extra control overhead
or service latency) should be put in FIB. Thus, FIB has eviction
policies that regulate which entries should be kept in or evicted
from FIB. To some degree, FIB exhibits behaviors similar to the
content cache, except that the former stores name prefixes while the
latter stores named data.
3.2. Interest Broadcast
The preceding description suggests that FIB misses could be common in
ICN when the number of name prefixes is large. FIB misses directly
lead to Interest broadcast, which content routers have to rely on as
the fall-back flooding mechanism to "search" for the content origin
or a router that can fulfill the request. Therefore, Interest
Xie, et al. Expires August 22, 2013 [Page 6]
Internet-Draft ICN routing February 2013
broadcast is likely common and can thus incur significant extra
overhead to the network.
FIB hits, on the other hand, reflect a router's awareness of the
content origin and enables the router to forward Interests to
designated faces without flooding the network. However, FIB hits are
likely heterogeneous; namely, an Interest resulting a FIB hit at one
router may result a FIB miss at another, due to the fact that
different router may decide to put different sets of name prefixes in
their FIB. As a result, a previously FIB-hit Interest may still be
broadcast by routers en route towards the content origin. It is
favorable to leverage FIB hits as much as possible in a collective
manner to reduce the number of flooded Interest as well as Data
packets.
3.3. Interest Starvation Problem
In CCN, Interests can be held "pending" in PIT. An Interest is
pending if another Interest for the same content has been previously
forwarded out but the corresponding Data has not been received yet,
and it has not yet been timed out in PIT. Upon receipt of an
Interest requesting for the content that has been requested by an
existing pending Interest in PIT, a content router does not forward
it; instead, the router uses PIT to track which incoming face(s) it
receives the Interest. Thus, forwarding duplicate Interests for the
same content can be avoided.
(origin) (Client B)
8 2 5 4 1 7
+--------+---------+--------+-------.-------+
| | | | |
| | | | |
+--------+----.----+--------+---------------+
9 6 3 0 10
(Client A)
Figure 1 : Interest Starvation Problem
However, this design could lead to an Interest Starvation Problem,
which we illustrate in the example network shown in Figure 1. This
network is an abbreviated figure of the Abilene network topology
(left: west cost, right: east coast). In this example, Client A
(connected to router 3) sends an Interest for a content owned by the
origin connected to router 8. Router 3 broadcasts the Interest to
its neighbors 5, 6 and 0.
Xie, et al. Expires August 22, 2013 [Page 7]
Internet-Draft ICN routing February 2013
Some of the Interests broadcast towards the east coast, however, will
never reach the origin. One can observe that the Interest forwarded
from 1 to 7 and the Interest from 7 to 1 will both lead to a PIT hit
at router 7 and 1, respectively (and thus no further counterclockwise
Interest forwarding to 4 or even 5). Consequently, when router 5
receives the returned Data, it will not forward it to router 4, as
its PIT does not have a pending Interest coming from 4. In other
words, although router 4's and 1's PIT has a pending Interest, they
are unlikely to receive the Data. This in turn results in the
starvation of future Interests requesting for the same content. For
instance, when Client B requests for the same content at a later time
(but before PIT expires the pending Interest), router 1 does not
forward the Interest due to PIT hit. In this case, B may only be
able to successfully receive the data when the corresponding PIT
entry expires in router 1.
Note that for any new content which has not been requested for, it is
more likely that the interest starvation occurs in flash crowd
scenarios, and such starvation can happen within a limited duration
(mainly determined by the timers expiring pending PIT entries).
However, it is likely in practice that FIB has misses, thus interest
starvation could still occur even for old content.
4. A Hybird, Reactive Routing Scheme for ICN
We describe the details of a hybrid, reactive routing scheme for ICN.
For illustration purposes, we use CCN as a concrete example of ICN to
describe the design details. The rationale behind our design is to
leverage infrastructure-oriented routing whenever possible and reap
the benefits of both name-oriented and host-oriented routing.
4.1. Content Router
We make the following changes to the original CCN content router
architecture, as shown in Figure 2. A complete CCN content router is
depicted in Figure 3.
Xie, et al. Expires August 22, 2013 [Page 8]
Internet-Draft ICN routing February 2013
Index
Ptr Type Reachability Info Base Forwarding Info Base
+---+-----+ Dest. Forwarding Faces Name Destination List
| * | CS | +-------+---------------+ +-------+---------------+
|---+-----| | R1 | 2 | | ... | ... |
| * | PIT | |-------+---------------| |-------+---------------|
|---+-----| | R3 | 0 | | /e/f | R3,R4 |
| * | FIB | |-------+---------------| |-------+---------------|
|---+-----| | R4 | 3 | | ... | ... |
| * | IIB | +-------+---------------+ +-------+---------------+
+---+-----+
Figure 2 : Augmentation to CCN Content Router
Xie, et al. Expires August 22, 2013 [Page 9]
Internet-Draft ICN routing February 2013
+----------------------------------------------------------------+
| Content Store Reachability Info Base |
| Name Data Dest. Forwarding Faces Face 0 |
| +->+-----+----+ +---> +-------+---------------+ +---+ |
| | |... |... | | | R1 | 2 | | |---->
| | |-----+----| | |-------+---------------| | | |
| | |/a/b | | | | R3 | 0 | | |<----
| | |-----+----| | |-------+---------------| +---+ |
| | |... |... | | | R4 | 3 | |
| | +-----+----+ | +-------+---------------+ |
| | | Face 1 |
| | +------------------+ +---+ |
| | Index | | |---->
| | Ptr Type | | | |
| | +---+-----+ | | |<----
| +--------------------------| * | CS | | +---+ |
| |---+-----| | |
| +--------------------------| * | PIT | | |
| | |---+-----| | |
| | +-| * | FIB | | Face 2 |
| | | |---+-----| | +---+ |
| | | | * | IIB | | | |---->
| | | +---+-----+ | | | |
| | | | | | |<----
| | | +------------+ +---+ |
| | | |
| | Pending Interest Table | Forwarding Info Base |
| | Name Requesting Faces | Name Destination List Face 3 |
| | +----+-------------+ +--->+-------+---------------+ +---+ |
| +->|/c/d| 0,3 | | ... | ... | | |---->
| |----+-------------| |-------+---------------| | | |
| |/e/f| 0,1 | | /e/f | R3,R4 | | |<----
| |----+-------------| |-------+---------------| +---+ |
| |... | ... | | ... | ... | |
| +----+-------------+ +-------+---------------+ |
+----------------------------------------------------------------+
Figure 3: Augmented CCN Content Router
Firstly, we require that every router in the network have a unique
name and announce its name to all other routers via available
intradomain routing protocols.
Secondly, we introduce a new component, the Infrastructure
Information Base (IIB), to reap the benefits of infrastructure-
oriented routing. Specifically, IIB stores the forwarding face(s) to
reach any router in the network. Note that IIB stores reachability
information for an intradomain network and in typical intradomain
networks the number of routers ranges from a few dozen to a couple of
Xie, et al. Expires August 22, 2013 [Page 10]
Internet-Draft ICN routing February 2013
thousand. Thus the size of IIB would be less than a couple of
thousand.
Since we require that routers announce their names using intradomain
routing protocols, each router is able to build IIB on their own.
Multi-path routing is feasible if multiple forwarding faces are
allowed in any IIB entry; however, routing loop prevention schemes
should be adopted (we leave it as a future work) Note that if only a
single forwarding face is allowed in any IIB entry, then we end up
with single-path routing and lose the benefits of potentially multi-
path routing in ICN; however, the gain is simplified routing and
improved scalability.
Thirdly, we change the semantics of the original FIB. Specifically,
each FIB entry now stores a name prefix and the names of "landmark"
routers for this prefix. We refer to a router as a landmark router
for a given name prefix if the router for sure has knowledge about
how to reach the origin(s) of the name prefix. For instance, the
router closest to an origin can be treated as the landmark router for
the name prefixes announced by that origin. Since Data packets bears
the origin's name (or an intermediate router's name), upon receipt of
such a Data packet, a router can update its FIB accordingly.
Lastly, we allow FIB to update its entries (i.e., routes) based on
the popularity (or relevant, carrier-chosen measures) of individual
routes. To some degree, now FIB is more like a cache for routes.
Certain caching policies can be applied to evict cold routes in order
to save space for popular routes. Keep in mind that the fall-back
mechanisms (e.g., flooding-based mechanisms) can be used as the last
resort in case of FIB misses (namely, no route is known for a given
name or name prefix). The requests of FIB lookup for popular
contents (triggered by interest packets destined for popular
contents) account for a majority of the FIB lookup workload, thus
storing popular routes is beneficial and improves the overall
performance of the network.
The other two components, Content Store and Pending Interest Table,
remain the same as the original CCN/NDN design.
4.2. Packet Format
In the Interest packet, we introduce a Broadcast flag bit to
distinguish the broadcast Interest (i.e., B Interest) and non-
broadcast Interest (i.e., NB Interest), and introduce a Destination
field, as shown in the Figure 3.
Xie, et al. Expires August 22, 2013 [Page 11]
Internet-Draft ICN routing February 2013
Interest Packet Data Packet
+------------------+ +------------------+
| Content Name | | Content Name |
+------------------+ +------------------+
| Selector | | Signature |
+------------------+ +------------------+
| Destination | | Signed Info |
+------------------+ +------------------+
| Broadcast Flag | | Source |
+------------------+ +------------------+
| Nonce | | Data |
+------------------+ +------------------+
Figure 3: Packet Format
An NB Interest is generally produced after a FIB hit at a router.
Clearly the router has some knowledge about the content and the
origin. In order to better leverage this knowledge, we let the
router fill in the Destination field in the NB Interest with the name
of a landmark router en route towards the origin (we recommend the
router closest to the origin as the landmark). Other routers that
receive such an Interest with this field filled out can therefore
take advantage of this knowledge; however, it is recommended but not
mandatory that routers should use the destination information in its
decision process. In a B Interest, the destination field is always
left empty.
In the Data packet, we introduce a Source field for the content
origin's identification, which provides a reference for updating FIB.
Note that the origin can obfuscated its own name (e.g., a hash of its
name) for privacy preservation purposes. Note also that there can be
multiple origins for a given content and that intermediate routers
may override this field with its own name.
4.3. Packet Handling
We now describe how content routers should handle packets in the
reactive routing scheme.
4.3.1. Handling Interest Packet
The new Interest handling method is presented as below. According to
our preceding description, the unsatisfied PIT hit could cause
starvation of future Interests. We address this problem with a novel
patch utilizing the broadcast flag. Note that the key property of
the starvation is the underlying ring topology (e.g., the ring
including routers 3,0,10,7,1,4,5 in Fig. 1) and some routers on the
Xie, et al. Expires August 22, 2013 [Page 12]
Internet-Draft ICN routing February 2013
ring (e.g., router 1) prohibit forwarding further Interests per their
PIT policy (their PIT is in a mistaken state though). This
starvation can be prevented by allowing routers such as router 1 to
further forward the Interest. In Fig. 1, this corresponds to the
Interest forwarding from 1 to 4 and further to 5 (as well as from 7
to 10 and further). When 5 receives the Data packet, this packet
will also be forwarded to all routers along the ring. In this way,
the broadcast Interest can traverse the ring topology in both
clockwise and counterclockwise directions. Consequently, once any
router in the ring receives the Data packet, all other routers will
eventually clear the corresponding PIT entry. The above strategy
indicates the following rule in the treatment of the broadcast
Interest: when the broadcast Interest is not from a face existing in
PIT (even if the corresponding content is pending), the Interest will
still be further broadcasted. Note that in this rule the broadcast
Interest from an existing face for the pending content can still be
aggregated.
For any broadcast Interest, it is eventually replied with the desired
content if found in CS. Otherwise, if the incoming faces have no
previous requests for the same content, it is broadcasted further if
FIB has no destination information for the requested content.
However, if FIB does have the destination information, then the
Interest will be forward as a non-broadcast Interest (NB) (by
changing the broadcast flag bit and fill the destination field) to
faces towards the destination.
For any non-broadcast Interest, since the destination is already
filled, we can directly forward it according to IIB in a unicast
manner. We can also fall back to the original CCN/NDN design and
adopt a broadcast approach to forward the Interest. Still, we
require that intermediate routers directly reply with the content
data in case of a CS hit.
4.3.2. Handling Data Packet
Handling Data packets is similar to the original CCN/NDN design.
When a Data packet matches a PIT entry, it will be forwarded to all
faces designated by the PIT entry along with a FIB update. Note that
the origin or the router closest to the origin should update the
destination field in the packet.
5. Conclusion
In this draft, we describe a hybrid, reactive information-centric
routing scheme to address the scalability challenge for intradomain
networks. In the design, an Infrastructure Information Base (IIB) is
Xie, et al. Expires August 22, 2013 [Page 13]
Internet-Draft ICN routing February 2013
introduced to augment the original CCN content router design with new
packet handling algorithms. The describe reactive routing scheme can
lead to less broadcast packets than the original proactive scheme
(simulation-based evaluations suggest that the reduction of broadcast
packets could be as high as two orders of magnitude). It can also
address the Interest Starvation Problem, and effectively reduces the
broadcast Interest after the FIB hit.
6. Contributors
The authors would like to thank Yang Wang for his many detailed
reviews and helpful assistance on this draft.
Yang Wang
Georgia State University
Atlanta, Georgia
USA
7. Acknowlegements
This memo is based upon work supported in part by the National
Science Foundation of China (NSFC) under Grant No. 61073192 and the
China 973 Program under Grant No. 2011CB302905. Any opinions,
findings and conclusions or recommendations expressed in this
material are those of the authors and do not necessarily reflect the
views of the funding agencies.
8. Security Considerations
Security issues are not discussed in this memo.
9. IANA Considerations
This document makes no specific request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. Informative References
[1] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N.,
and R. Braynard, "Networking named content, in ACM CoNEXT 2009,
Xie, et al. Expires August 22, 2013 [Page 14]
Internet-Draft ICN routing February 2013
Rome, Italy", Dec 2009.
[2] Zhang, L., Estrin, D., Burke, J., Jacobson, V., Thornton, J.,
Smetters, D., Zhang, B., Tsudik, G., K. Claffy, K., Krioukov,
D., Massey, D., Papadopoulos, C., Abdelzaher, T., Wang, L.,
Crowley, P., and E. Yeh, "Named data networking (NDN) project,
Palo Alto Research Center(PARC), Tech. Rep. NDN-0001", Oct 2010.
[3] Xie, H., Wang, Y., and G. Wang, "Scalable Content Centric
Networks via Reactive Routing, in IEEE ICC 2013, Budapest,
Hungary", June 2013.
Authors' Addresses
Haiyong Xie
Huawei & USTC
Phone:
Email: Haiyong.xie@huawei.com
Yi Sun
Institute of Computing Technology
No.6 Kexueyuan South Road
Beijing, 100190
China
Phone: (86)18611907658
Email: sunyi@ict.ac.cn
Guoqiang Wang
Huawei (USA)
Phone:
Email:
Xie, et al. Expires August 22, 2013 [Page 15]
Internet-Draft ICN routing February 2013
Haibo Wu
Institute of Computing Technology
No.6 Kexueyuan South Road
Beijing, 100190
China
Phone: (86)13811800085
Email: wuhaibo@ict.ac.cn
Jun Li
Institute of Computing Technology
No.6 Kexueyuan South Road
Beijing, 100190
China
Phone: (86)18910572771
Email: lijun@ict.ac.cn
Xie, et al. Expires August 22, 2013 [Page 16]
