INTERNET-DRAFT A. Kumar Intended Status: Informational J-C. Delvenne Expires: August, 2014 UCL, Belgium February 2014 A new route discovery scheme draft-kumar-route-discovery-00 Abstract This document describes a route discovery scheme in the Internet. It could be well suited for any centralized distributed network like software-defined networks. This scheme could be an alternative of path computation element in inter-Autonomous domains routing protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Kumar & Delvenne Expires August 2014 [Page 1] Route discovery February 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Conventions used in this document . . . . . . . . . . . . . . . 3 3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 Functional components and detail of scheme . . . . . . . . . . 3 4.1 Connectivity value of an AS . . . . . . . . . . . . . . . . 3 4.2 Country code . . . . . . . . . . . . . . . . . . . . . . . 3 4.3 Route representation and databases . . . . . . . . . . . . 4 4.4 Route discovery . . . . . . . . . . . . . . . . . . . . . . 4 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1 Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Kumar & Delvenne Expires August 2014 [Page 2] Route discovery February 2014 1 Introduction In this document, we specify the functional components, route representation and procedure of a new route discovery scheme. The software-define networking (SDN) defined a centralized distributed network that may solve the problem of scaling of BGP with alteration. In SDN, the routing control plane is responsible for path computation and selection of routes. We consider this routing control plane as a routing entity and it identified by AS number. The proposed scheme utilize this routing entity's position and connectivity to search route between source and destination administrative domains's REs. 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. 3 Assumptions - Each RE should be responsible for route related tasks (not forwarding) for respective AS. - Each RE knows the neighbor's neighbor list along with the Country code (describe in section 4.1) and connectivity value (describe in section 4.2) of each entry. 4 Functional components and detail of scheme 4.1 Connectivity value of an AS The connectivity value (c-value)of a RE is the number of directly connected ASs via outgoing links and reverse c-value of a RE is define as the number of directly connected ASs via incoming links. 4.2 Country code All Regional Internet Registry (RIR) maintains the country code for Kumar & Delvenne Expires August 2014 [Page 3] Route discovery February 2014 each AS. The RIR uses International Standard ISO 3166 to define country codes for every ASs in the Internet [ISO-3166]. In this scheme we utilizes these codes for search route between source and destination's RE. Any RE can modify the country code symbolically which assign it under following circumstance (only for route discovery ): - If c-value of any RE is one, than it modify the own code with neighbor's code. - If c-value of any RE is two, than it modify the own code with neighbor's code which has higher c-value. 4.3 Route representation and databases Like IP addresses, AS numbers are important Internet number resources. It defined with a unique number for each AS and express as 32 bit numbers. The route discovered by scheme represent as series of AS numbers between source and destination's RE. This scheme uses neighbor list and neighbor's neighbor list with country code and c-value for each entry. 4.4 Route discovery This scheme uses a discovery message for discover the route between pre-defined source and destination. When the destination receive discovery message, it issue an acknowledgement message for source with discovered route. The main procedure of the scheme is follows: 1. When destination's AS number exist in the neighbor list, it direct discovery packet to destination. 2. When destination's AS number exist in the neighbor's neighbor list, it direct discovery packet to destination via a connecting RE. 3. When destination's country code exist in the neighbor list, it direct discovery packet toward a neighbor which share destination's country code. 4. When destination's AS number exist in the neighbor's neighbor list 5. Otherwise, it direct discovery packet toward a neighbor with higher c-value. Kumar & Delvenne Expires August 2014 [Page 4] Route discovery February 2014 5 Security Considerations TBD. 6 IANA Considerations TBD. 7 References 7.1 Informative References [RFC 5773] Davies, E. and Doria, A., "Analysis of Inter-Domain Routing Requirements and History", RFC 5773, February 2010. [ISO-3166] "Country codes", ISO 3166. Authors' Addresses Alok Kumar Universite catholique de Louvain Avenue Georges Lemaitre, 4 1348 Louvain-la-neuve, Belgium Phone: +32 10 478005 Email: alok.kumar@uclouvain.be Jean-Charles Delvenne Universite catholique de Louvain Avenue Georges Lemaitre, 4 1348 Louvain-la-neuve, Belgium Phone: +32 10 478053 Email: jeancharles.delvenne@uclouvain.be Kumar & Delvenne Expires August 2014 [Page 5]