Internet DRAFT - draft-kumar-route-discovery
draft-kumar-route-discovery
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]
