POLÍTICAS

In the IDRD architecture, the information on path diversity is stored in the indi- vidual domains’ Mapping Systems (MSs), and thus the propagation of path diversity between two IDRD domains is also performed at the MS level (Point (A) and Point (A’) in Figure 3.2). In the most simple case, in which path diversity is pushed be- tween the domains, the inter-MS protocol is very close to BGP as it is also based on the path vector principle, propagating the AS path in order to prevent loops.

As IDRD domains may be connected to neighbors that have not adopted IDRD, eBGP routing information coming from these neighbors can be redistributed into the MS (Point (B)). In other words, conventional BGP is a source of diversity. More- over, IDRD does not replace BGP as the default inter-domain routing protocol, as IDRD domains keep on advertising BGP routes. This property allows IDRD to fulfill the “Backward Compatibility” and “Incremental Deployability” design criteria. Therefore, even early adopters that do not have any IDRD neighbors, benefit from the adoption of the architecture. Indeed, early adopters can benefit from the route diversity they receive from different eBGP neighbors and choose wisely among the different exit ASBRs depending on the path to be followed. Such early adoption and its benefits are described in Chapter 2 .

In the following parts, we focus on the architecture in the context of its inter- domain adoption.

Route propagation

BGP to MS route redistribution: This case is only relevant if one of the neigh- bors is non-IDRD compatible. In such a case, the adjacent IDRD domain receives eBGP messages at the inter-domain peering points. Pure iBGP can subsequently be used by the IDRD domain for sending these BGP messages from its ASBRs to the IDRD Mapping System (at Point (B) in Figure 3.2). In order to be techni- cally able to send several paths to the Mapping System, ASBRs may use the BGP add-path extension [16]. In such a case, each route is identified in the BGP update thanks to an identifier. The couple (Next_Hop, ADD_path_Identifier) is sufficient for the Mapping System to uniquely identify each one of the routes it receives from all the ASBRs.

Inter-MS routing propagation: The propagation of multiple paths between IDRD- enabled neighbor ASes is performed at the MS-level, i.e., their MSes communicate directly (Points (A) and (A’) in Figure 3.2). This diversity information contains at least the BGP metrics and may also contain additional information, e.g., price, ca- pacity, etc. Overall, the choice of inter-MS protocol which is to be used depends directly on the type of relationship between the adjacent domains. The most simple type is certainly a push-based paradigm similar to the one already in use by BGP. In such a case, the use of BGP add-path [16] can readily be applied between the MSes. The information that needs to be propagated is composed of: (i) the adver- tised prefixes, (ii) a set of routes per prefix, along with the associated BGP metrics, and (iii) an entry ASBR per path, along with an entry path-ID. Other route propaga- tion paradigms could also be considered, e.g., based on negotiation. In that case, a

CHAPTER 3. IDRD: ENABLING INTER-DOMAIN ROUTE DIVERSITY 101

negotiation framework, including proposal/acceptance/path preferences/etc. mes- sages, should be made use of, as proposed in [30].

Mapping System entries

In its data base, the Mapping System must keep a minimum set of information in order to allow for the system’s functioning. It must store the association between the sets of incoming flows and the paths they must be forwarded to. Colours are used to highlight the association between incoming flow information and outgoing flow information.

Domain incoming flows are defined by the following set of infor-

mation, which is stored in the MS and partially configured in the

entry ASBR:

– Anend-destination IP prefix, – An entry ASBR,

– An incoming path-ID,

Each domain incoming flow is further associated to its internal path defined by:

– A set ofoutgoing path-IDs,

– Each one associated with anext hop ASBR(i.e., an exit ASBR

of the domain).

Each domain incoming flow, once forwarded toward an exit ASBR, becomes a domain outgoing flow.

Domain outgoing flows are defined by the following set of infor-

mation, which is also stored in the MS but configured in the exit

ASBR:

– Anend-destination IP prefix(which must be the same as in the

incoming paths),

– The IP address of the exit ASBR (which must be coherent with

thenext hop ASBRof theincoming paths),

– An incoming path-ID (which must be coherent with theoutgoing

path-IDsof theincoming paths).

The domain outgoing flows are further associated to the exter- nal/outgoing path defined by:

– A set of outgoing path-IDs,

– A next hop ASBR (i.e., an entry ASBR of the next AS) per out- going path-ID.

It is important to note that the IP destination of a flow is not mandatory in order to forward it toward the correct path. Once a packet is encapsulated and associated with a Path-ID, the IP destination address may not be required anymore as all the forwarding information may be inserted into the Path-ID. Indeed, in Chapter 4 we analyse the scalability of Path-ID organisations and recommend to forward the packets according to the Path-IDs only.

tial new routing paradigms may emerge. To this end, the following information may be useful; the price of the path or of the exit link, information on stability, bandwidth availability, delays, etc.

ASBR configuration

Once the diversity is propagated between ASes, the Autonomous System Bor- der Routers (ASBRs) must be made aware of the corresponding mapping informa-

tion. The information aboutdomain incoming flows (cf. Section 3.2.2) is config-

ured in an entry ASBR whereas the information aboutdomain outgoing flows is

configured in an exit ASBR.

The MS can either directly push the mapping information or await mapping requests from neighbor ASBRs (Points (C), (C’) and (C”) in Figure 3.2). While the push approach allows for the propagation of the messages to the ASBRs as soon as the MS receives them, at the same time it increases the size of the forwarding table with entries that may not be used at the data plane level. On the other hand, the pull approach introduces latency in forwarding the first packets on a path (i.e., during the mapping request), but it only inserts the required routing entries into the ASBR forwarding table. The choice between push and pull approaches in the configuration of routers is local to each AS and may therefore differ according to the policy of each domain.

Concerning the pull approach, [28] already proposes processes and messages for the LISP protocol that allow a router to request a mapping entry from the map- ping server. This pull configuration protocol is already in use in some commer- cial routers. And as far the push approach is concerned, configurations can be performed via the Netconf protocol [104], which is also available on commercial routers.

We stress that not all the ASBRs of a domain must necessarily be able to deal with the use of routing diversity - instead, a domain may prefer to have only a small number of routers address this issue. In such a case, only a subset of ASBRs need to be compliant with the IDRD architecture.