Scalable Domain-based Routing Scheme
draft-lee-icnrg-domainbasedrouting-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Joo-Chul Lee , Wan-Seon Lim , Woo-Jik Chun | ||
| Last updated | 2014-07-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-icnrg-domainbasedrouting-01
Network Working Group J. Lee
Internet Draft ETRI
Intended status: Informational W. Lim
Expires: January 2015 ETRI
W. Chun
HUFS
July 5, 2014
Scalable Domain-based Routing Scheme
draft-lee-icnrg-domainbasedrouting-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 5, 2014.
Lee Expires January 5, 2015 [Page 1]
Internet-Draft Scalable Domain-based Routing July 2014
Copyright Notice
Copyright (c) 2014 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.
Abstract
This memo describes a scalable routing scheme for ICN regardless of
the underlying network protocols. When Lookup-By-Name routing (LBNR)
is used the first thing to do is name to locator resolution. Once the
locator is acquired, discovery and delivery steps are carried out
based on the network protocol of the locator. However, if the
requestor and contents server are in heterogeneous networks discovery
and delivery step could not be carried out smoothly. To let this
happen seamlessly we propose scalable routing scheme based on
hierarchically-organized domain structure. This scheme is independent
of underlying network protocols and is more scalable thanks to the
abstraction of location spaces. Internet is projected as spaces (i.e.
domains) which have hierarchical relationship among them, and each
node which belongs to a domain can be reached through "locator" which
is a concatenation of "domain IDs".
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 3
3. Terminologies ............................................... 4
4. Domain-based Routing Scheme.................................. 5
4.1. Hierarchically-organized Domain Structure .............. 5
4.1.1. Locator ........................................... 6
4.2. Name Resolution System (NRS)............................ 6
4.3. Locator-based Routing................................... 6
4.4. Server Discovery (path discovery) ...................... 7
4.5. Name-based Forwarding (Name-based delivery)............. 8
4.6. Mobility Support........................................ 9
5. Security Considerations...................................... 9
6. IANA Considerations ......................................... 9
Lee Expires January 5, 2015 [Page 2]
Internet-Draft Scalable Domain-based Routing July 2014
7. References .................................................. 9
7.1. Informative References.................................. 9
1. Introduction
ICN routing locates a data object based on its name which is
initially provided by a requestor. ICN routing may comprise 3 steps:
a name resolution step, a discovery step, and a delivery step.
Depending on how these steps are combined, ICN routing schemes can be
categorized as RBNR, LBNR, and HR [ICN challenges].
If LBNR is used a Name Resolution System (NRS) translates the name of
requesting data object into its locator as the first step. Once the
locator for the name is obtained discovery and delivery may depend on
the network protocol of locator.
The problem is that it is often not possible to get the locator that
is routable in requestor's domain (i.e. the case that requestor and
contents server are in heterogeneous networks). If this happens it
would not be easy way to reach contents server from requestor or vice
versa.
The routing scheme that we propose operates regardless of underlying
network protocol, and it is scalable thanks to the hierarchically
composed domain structure. Each node in a domain can be reached
through locator which is expressed as a form of concatenation of
domain IDs. Each domain gateway, a kind of border router for each
domain, runs routing protocol to build routing table based on the
locators. This is a variation of link-state routing protocol, and
suppresses LSA storm by using LSA-filtering rule between parent and
child domain.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
Lee Expires January 5, 2015 [Page 3]
Internet-Draft Scalable Domain-based Routing July 2014
3. Terminologies
o Domain: a logical/physical group of nodes (requestor, contents
server, or other "domain") which have similar characteristics (E.g.
network protocol, geographical region, same type of contents,
similar category of contents etc.).
o Locator: in this memo, locator is a concatenation of IDs of
hierarchically organized domains.
o Domain Gateway: a kind of border gateway for a domain. The domain
gateway forwards discovery messaged or NDO data, and runs routing
protocol based on locator.
Lee Expires January 5, 2015 [Page 4]
Internet-Draft Scalable Domain-based Routing July 2014
4. Domain-based Routing Scheme
4.1. Hierarchically-organized Domain Structure
+-----------------------------------------------------------------+
| |
| (Domain Id: 0x0A, IPv4) |
| +------[GW #0]----------------------+ |
| | | | |
| | | | |
| | | | |
| | | | |
| | +--------------------------+ |
| | |
| (Domain Id:0x0B, IPv4) | |
| +-------------------[GW #1]--------------------------------+ |
| | ^^^^^^^^ | <------------------------> | |
| | | NRS |----- +------< requestor A (Id: 0xFF) > | |
| | ^^^^^^^^ | <------------------------> | |
| | | | |
| | +--------------------------------+ | |
| | | | | |
| |(Domain Id:0x0C, IPv6)| | | |
| | +----------------[GW #2]-+ (Domain Id:0x0D, Ethernet)| | |
| | | | | +------------------[GW #3]| |
| | | | | | server3 | | | |
| | | server1 | | | +========+ | | | |
| | | +=============+ | | | | | | | | |
| | | | StarWars | | | | | +--------+ | | |
| | | | (0xEE) | | | | | | | | | |
| | | | | | | | +========+ | | | |
| | | | +---+ | | | | | |
| | | +=============+ | | | <-------------> | | |
| | | | | | < requestor B > | | |
| | |(Domain Id:0x0E, IPv4) | | < (Id: 0xAF) > | | |
| | | +-----------[GW #4]-+ | | <-------------> | | |
| | | | server2 | | | | | | |
| | | | +==========+ | | | +-----------------------+ | |
| | | | | | | | | | |
| | | | | +--+ | | | |
| | | | +==========+ | | | |
| | | +-------------------+ | | |
| | +------------------------+ | |
| +----------------------------------------------------------+ |
+-----------------------------------------------------------------+
Figure 1 Sample Domain Architecture
Lee Expires January 5, 2015 [Page 5]
Internet-Draft Scalable Domain-based Routing July 2014
In our scheme network is projected as a set of domains, and each of
which could be decomposed into other domains recursively. Figure 1
shows an example of domain structure. All traffic to and from a
domain should pass through a domain gateway.
4.1.1. Locator
Each domain has its own ID (domain Id). The concatenation of domain
IDs from top level domain to the current domain plays the role of
"locator" for the current domain. (E.g. locator for server3 is
0x0B:0x0D).
4.2. Name Resolution System (NRS)
In Name resolution step a requestor queries current locator of a name
to the NRS. For fast processing hashing technique (like bloom filter)
could be used to implement NRS. More detailed structure is out of
scope of this memo (it will be dealt in other I-D).
4.3. Locator-based Routing
Each domain gateway runs modified link-state routing protocol. Each
LSA transfers "locator" instead of IP prefix. Thus, locators appears
in destination field of routing table.
To suppress LSA storm each domain gateway forwards LSAs to the other
domain gateways according to the following filtering rules:
o LSAs in tier N domain are forwarded to all domain gateways in same
tier domain.
o LSAs in tier N-1 are injected to tier N gateways.
o LSAs in tier N+1 are filtered, LSA which has aggregated locator is
injected to tier N instead. (E.g. [GW #2] delivers LSA which
includes 0x0B:0x0C to [GW #1], locator for domain 0x0E
(0x0B:0x0C:0x0E) is not flooded into [GW #1]).
This results in topology reduction effect. Therefore, each domain
gateway would have topology graph which is as reduced as possible in
its current position.
Lee Expires January 5, 2015 [Page 6]
Internet-Draft Scalable Domain-based Routing July 2014
+---------------------+--------------------+--------+
| Destination | nexthop | out if |
+---------------------+--------------------+--------+
| 0x0B:0x0C | GW #2's address | if1 |
+---------------------+--------------------+--------+
| 0x0B:0x0D | GW #3's address | if1 |
+---------------------+--------------------+--------+
| 0x0B | - | if1 |
+---------------------+--------------------+--------+
| 0x0A | GW #0's address | if0 |
+---------------------+--------------------+--------+
Figure 2 Example of Routing Table (GW #1)
+---------------------+--------------------+--------+
| Destination | nexthop | out if |
+---------------------+--------------------+--------+
| 0x0B:0x0C:0x0E | GW #4's address | if1 |
+---------------------+--------------------+--------+
| 0x0B:0x0D | GW #3's address | if0 |
+---------------------+--------------------+--------+
| 0x0B:0x0C | - | if1 |
+---------------------+--------------------+--------+
| 0x0B | GW #1's address | if0 |
+---------------------+--------------------+--------+
| 0x0A | GW #1's address | if0 |
+---------------------+--------------------+--------+
Figure 3 Example of Routing Table (GW #2)
+---------------------+--------------------+--------+
| Destination | nexthop | out if |
+---------------------+--------------------+--------+
| 0x0B:0x0C | GW #2's address | if0 |
+---------------------+--------------------+--------+
| 0x0B:0x0D | - | if1 |
+---------------------+--------------------+--------+
| 0x0B | GW #1's address | if0 |
+---------------------+--------------------+--------+
| 0x0A | GW #1's address | if0 |
+---------------------+--------------------+--------+
Figure 4 Example of Routing Table (GW #3)
4.4. Server Discovery (path discovery)
When a requestor gets locator for a specific NDO from NRS, it build a
path discovery message and forwards to the default domain gateway (in
this example, "requestor A" send path discovery message to GW #1).
The path discovery message includes followings:
Lee Expires January 5, 2015 [Page 7]
Internet-Draft Scalable Domain-based Routing July 2014
+------------------------------------------------------------------+
| Network header |
+------------------------------------------------------------------+
| Requestor's ID |
+------------------------------------------------------------------+
| NDO's ID |
+------------------------------------------------------------------+
| NDO's current locator |
+------------------------------------------------------------------+
If a domain gateway receives path discovery message, it looks up its
forwarding cache table firstly. If there is no forwarding cache entry
for the NDO's ID, the domain gateway builds new forwarding cache
entry. The domain gateway searches its routing table by using
"locator (included in the path discovery message)" as key, then it
builds forwarding cache entry for the NDO's ID and requestor's ID.
Forwarding cache entry for NDO includes followings:
o NDO's ID
o Next hop information (found in the routing table entry)
Forwarding cache entry for the requestor includes followings:
o Requestor's ID
o Previous hop information (found in the network header)
After building the forwarding cache, the path discovery message is
forwarded to the next hop domain gateway (network header is changed
according to the next-hop information of forwarding cache), and
repeat this procedure until it reaches domain which includes the NDO.
Forwarding caches are managed in the manner of timer-based way.
4.5. Name-based Forwarding (Name-based delivery)
When the contents server which has requested NDO receives path
discovery message, it sends NDO data by using following message
format:
Lee Expires January 5, 2015 [Page 8]
Internet-Draft Scalable Domain-based Routing July 2014
+------------------------------------------------------------------+
| Network header |
+------------------------------------------------------------------+
| Requestor's ID |
+------------------------------------------------------------------+
| NDO data |
+------------------------------------------------------------------+
Network header would be changed according to the next hop information
of forwarding cache.
4.6. Mobility Support
Mobility support can be implemented very easily because path
discovery message and data delivery packet don't include any
location-related information. Usually any domain gateway which
detects movement of node (requestor or server) re-starts path
discovery procedure, then several forwarding caches on the path will
be up-to date. There is almost few things that nodes should do.
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. References
7.1. Informative References
[ICNRG charter] http://irtf.org/icnrg
[ICN Challenges] D.Kutscher, "ICN Research Channelges", internet-
draft, July 2013
[aRoute] Ahmed, Reaz, Md Faizul Bari, Shihabur Rahman Chowdhury, Md
Golam Rabbani, Raouf Boutaba, and Bertrand Mathieu.
"Route: A Name Based Routing Scheme for Information
Centric Networks." In IEEE International Conference on
Computer Communications (INFOCOM) Mini-Conference, 2013.
[Id net] http://www.idnet.re.kr/
Lee Expires January 5, 2015 [Page 9]
Internet-Draft Scalable Domain-based Routing July 2014
Authors' Addresses
Joo-Chul Lee
ETRI
161 Gajeong-dong, Yuseong-gu, Daejon
Phone:
Email: rune@etri.re.kr
Wan-Seon Lim
ETRI
161 Gajeong-dong, Yuseong-gu, Daejon
Phone:
Email: wslim@etri.re.kr
Woo-Jik Chun
HanKuk University of Foreign Studies
81, Oedae-ro, Mohyeon-myeon, Cheoin-gu,Yongin-si, Gyeonggi-do, 449-
791, Korea
Phone:
Email: woojikchun@gmail.com
Lee Expires January 5, 2015 [Page 10]