Internet DRAFT - 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
                                                       February 18, 2013

        Scalable Hybrid Routing for Information-Centric Networks


   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

   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
   ( 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

   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

   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

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

      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

   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

   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

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

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


   Yi Sun
   Institute of Computing Technology
   No.6 Kexueyuan South Road
   Beijing,   100190

   Phone: (86)18611907658

   Guoqiang Wang
   Huawei (USA)


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

   Phone: (86)13811800085

   Jun Li
   Institute of Computing Technology
   No.6 Kexueyuan South Road
   Beijing,   100190

   Phone: (86)18910572771

Xie, et al.              Expires August 22, 2013               [Page 16]