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]