Internet DRAFT - draft-kaiser-if-sel
draft-kaiser-if-sel
Network Working Group A. Kaiser
Internet-Draft A. Petrescu
Intended status: Experimental CEA
Expires: July 10, 2014 January 6, 2014
Interface Selection Mechanism for Multiple Interfaces IPv6 Hosts
draft-kaiser-if-sel-01
Abstract
This document describes an interface selection mechanism that enables
multiple interfaces (multihomed) IPv6 hosts to select their most
appropriate egress interface to send data over the network. The
mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with
two new Router Advertisement options.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 10, 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. 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.
Kaiser & Petrescu Expires July 10, 2014 [Page 1]
Internet-Draft If-Sel January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description of the mechanism . . . . . . . . . . . . . . . . . 5
3.1. Link Cost Option . . . . . . . . . . . . . . . . . . . . . 5
3.2. Path Cost Option . . . . . . . . . . . . . . . . . . . . . 6
4. Status Code . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Example use case . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Network topology . . . . . . . . . . . . . . . . . . . . . 10
5.2. Messages exchange diagram . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Kaiser & Petrescu Expires July 10, 2014 [Page 2]
Internet-Draft If-Sel January 2014
1. Introduction
In the context of multihomed hosts, where hosts are connected to a
network with more than only one interface, the selection of a right
egress interface to send data is critical. Indeed, selecting a wrong
egress interface may lead to a non-optimal routing of data in the
network or, in the worst case, the impossibility to reach the
destination. In order to cope with the aforementioned issue, this
document describes an interface selection mechanism that enables
hosts to select their most appropriate egress interface, leading to
an optimized end-to-end routing of data.
The proposed mechanism is based on the ND protocol. More precisely,
two new options are introduced in RS and RA messages: the Link Cost
Option (LCO) and the Path Cost Option (PCO).
Kaiser & Petrescu Expires July 10, 2014 [Page 3]
Internet-Draft If-Sel January 2014
2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS].
Kaiser & Petrescu Expires July 10, 2014 [Page 4]
Internet-Draft If-Sel January 2014
3. Description of the mechanism
The proposed mechanism is divided into two operations, each one
relying on a new ND option:
o Gathering informations about links costs and selection of a
default egress interface using the Link Cost Option
o Gathering informations about the cost of a path to a destination
and selection of an egress interface for the specific destination
using the Path Cost Option (PCO)
The following subsections detail each operation as well as the
corresponding option.
3.1. Link Cost Option
The LCO is used to advertise the cost of a link. This option SHOULD
be included in all RA messages that are generated by routers.
Therefore, a host that connects to a link is informed about the cost
of this specific link. By extension, if a host is connected to
multiple links in the network, it is informed about the cost of each
of those links. Using these informations, the host selects its
default interface: the interface connected to the link that has the
lowest cost is selected. The host then adds in its routing table an
entry that contains the default route as destination, the router that
is on the corresponding link as next-hop, the selected interface as
outgoing interface and the link cost as metric. Upon reception of
other RA messages, the host compares the link costs included in the
RAs with the one in its routing table. If the received link cost is
better than the one of the default route in the routing table, the
latter MUST be updated accordingly.
The following figure shows the format of the link cost option. This
option is only valid in the RA messages and MUST NOT be included in
the other ND messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kaiser & Petrescu Expires July 10, 2014 [Page 5]
Internet-Draft If-Sel January 2014
Type: Identifier of the LCO (TBD by IANA).
Length: 1. Size of the option as defined in [RFC4861].
Reserved: Unused field. MUST be set to zero by sender and
ignored by recipient.
Link Cost: Unsigned integer. The cost of the link.
3.2. Path Cost Option
The PCO is used by hosts to ask routers about the total cost of a
path to a destination. The routers reply to the request also by
using the PCO. Thus, this option MAY be included in RS and RA
messages.
When a multiple interfaces host wants to send data to a destination
node, it starts by checking in its routing table if a specific route
to this destination exists. If no route exists, the host sends a RS
message with a PCO to the all-routers multicast address on each of
its interfaces. The PCO includes the IPv6 address of the destination
to which the host wants to send data. Upon reception of such RS
message, a router checks in its routing table which route entry it
would select to forward data to this specific destination. The
router then replies by sending a unicast RA message to the requesting
host with a PCO that includes the total cost of the selected path
from the router itself to the destination along with a lifetime that
defines the validity of the route advertised. Upon reception of
these informations, the host computes the total cost of the path from
itself to the destination by adding to the path cost advertised by
the router the corresponding link cost (which is advertised with the
LCO). Once computed, the host selects as egress interface to the
specific destination the interface connected to the path that has the
lowest end-to-end cost. The host then updates its routing table
accordingly with the new computed information.
The following figure shows the format of the path cost option. This
option is only valid in the RS or RA messages and MUST NOT be
included in the other ND messages.
Kaiser & Petrescu Expires July 10, 2014 [Page 6]
Internet-Draft If-Sel January 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Transaction ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination |
| Address or Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Identifier of the PCO (TBD by IANA).
Length: 4. Size of the option as defined in
[RFC4861].
Transaction ID: Identifier of the current RS/RA messages
exchange between the host and the router.
Status Code: Code that provides additionnal informations
about the results provided by the router
(see Section 4 for more details). MUST be
set to zero in RS messages and ignored by
recipient.
Reserved: Unused field. MUST be set to zero by
sender and ignored by recipient.
Prefix Length: Size of the IPv6 prefix that follows. Set
to 128 if the following field contains an
IPv6 address.
Dst. addr. or pref.: IPv6 prefix or address of the destination
node to which the path computation is
asked.
Path Cost: Unsigned integer. The total cost of the
path from the advertising router to the
destination.
Kaiser & Petrescu Expires July 10, 2014 [Page 7]
Internet-Draft If-Sel January 2014
Lifetime: The lifetime of the route advertised in
this PCO. MUST be set to zero in RS
messages and ignored by recipient.
Kaiser & Petrescu Expires July 10, 2014 [Page 8]
Internet-Draft If-Sel January 2014
4. Status Code
A Status Code is included in the PCO option. It provides additionnal
informations to the host about the results of its request. The
following codes are considered:
0 Success: a path to the destination is known by the router and
the corresponding path cost is included in the PCO.
1 No specific route to the destination is known by the router.
However, the router has a default route that can be used to
forward data to the destination, but with no warranty. In this
case, the corresponding path cost MUST be set to the maximum
possible value (i.e. all-ones bits).
2 Failure: the packets to this destination would probably be
dropped by this router because no route to reach the destination
is known or because of any other reason (firewall rules, policy-
related rules, ...). In this case, the path cost value is set
to zero.
Kaiser & Petrescu Expires July 10, 2014 [Page 9]
Internet-Draft If-Sel January 2014
5. Example use case
Typical uses cases that can be considered are home networks,
corporate network, ad-hoc networks, etc. This section illustrates
the mechanism through a simple network topology.
5.1. Network topology
The following figure depicts the network topology used in this
example.
Link1 (4)
2001:db8:1::/64
Link2 (2) --+-----------------------------------------+--
2001:db8:2::/64 | |
--+--------+-- | |
| | | |
| | /----+----\ /----+----\
| | | | | |
+---+---+ +---+ Router1 | | Router2 |
| | | | | |
| Host2 | \----+----/ \----+----/
| | | |
+-------+ | Link3 (5) Link4 (3) |
| 2001:db8:3::/64 2001:db8:4::/64 |
--+----------+-- --+--------+--
| |
| +-------+ |
| I1 | | I2 |
+------+ Host1 +------+
| |
+-------+
The figure shows two routers (Router1, Router2) and two hosts (Host1,
Host2). Theses nodes are connected to each other through 4 links
(Link1, Link2, Link3, Link4). The values in brackets represent the
corresponding link costs. Also, Host1 is a multiple interfaces
device: it is connected to Link3 via its network interface I1 and to
link4 via its network interface I2.
Let us consider Host1. Its first operation consists of gathering
links costs and select a default interface. To this end, Router1 and
Router2 send usual periodic RA messages. These messages include a
LCO that describes the cost of the link: Router1 advertises that the
cost of Link3 is 5 and Router2 advertises that the cost of link4 is
3. As Link4 has a better cost that Link3, Host1 selects I2 as its
default interface. Host1 then updates its routing table accordingly,
as show in the following figure:
Kaiser & Petrescu Expires July 10, 2014 [Page 10]
Internet-Draft If-Sel January 2014
+---------------------+------------------+------------------+------+
| Destination Network | Next-Hop Address | Output Interface | Cost |
+---------------------+------------------+------------------+------+
| fe80::/64 | - | I1 | 5 |
+---------------------+------------------+------------------+------+
| fe80::/64 | - | I2 | 3 |
+---------------------+------------------+------------------+------+
| 2001:db8:3::/64 | - | I1 | 5 |
+---------------------+------------------+------------------+------+
| 2001:db8:4::/64 | - | I2 | 3 |
+---------------------+------------------+------------------+------+
| Default | @Router2 | I2 | 3 |
+---------------------+------------------+------------------+------+
Let us now consider that Host1 wants to communicate with Host2. In a
classical scenario, Host1 would send data for Host2 through I2,
according to its routing table. Data would thus be forwarded by
Router2 and Router1 through Link1 and Link2 respectively, leading to
a total path cost of 9. Sending data through I1 would have been a
better choice. Indeed, despite the fact that Link3 has a worse cost
compared to Link4, the end-to-end path cost would be better (7).
However, as Host1 is not a router, it does not have a sufficient
vision of the network to make such decision. To this end, before
sending data to Host2, Host1 first send a RS message that includes a
PCO on all its outgoing interfaces (I1 and I2). The "Destination
Address" field is filled with the address of Host2. Upon reception
of such message, the routers reply to Host1 with a PCO included in RA
message: Router1 replies that its better known path to reach Host2
has a total cost of 2 (Link2) and Router2 replies that its better
known path has a total cost of 6 (Link1 + Link2). As Host1 already
knows the costs of Link3 and Link4, it computes that sending data
through I1 would have an end-to-end cost of 7 (Link3 + Link2) whereas
using I2 would lead to an end-to-end cost of 9 (Link4 + Link1 +
Link2). Hence, Host1 selects I1 as its egress interface to reach
Host2 and updates accordingly its routing table, as shown in the
following figure:
Kaiser & Petrescu Expires July 10, 2014 [Page 11]
Internet-Draft If-Sel January 2014
+---------------------+------------------+------------------+------+
| Destination Network | Next-Hop Address | Output Interface | Cost |
+---------------------+------------------+------------------+------+
| fe80::/64 | - | I1 | 5 |
+---------------------+------------------+------------------+------+
| fe80::/64 | - | I2 | 3 |
+---------------------+------------------+------------------+------+
| 2001:db8:3::/64 | - | I1 | 5 |
+---------------------+------------------+------------------+------+
| 2001:db8:4::/64 | - | I2 | 3 |
+---------------------+------------------+------------------+------+
| Default | @Router2 | I2 | 3 |
+---------------------+------------------+------------------+------+
| 2001:db8:2::/64 | @Router1 | I1 | 7 |
+---------------------+------------------+------------------+------+
5.2. Messages exchange diagram
The following diagram shows the messages exchanges corresponding to
the example described above: the first two RA messages correspond to
Host1 default interface selection, the following two RS/RA messages
exchanges correspond to the selection of Host1 interface to reach
Host2 and the lasts messages show the final path used by data to
transit from Host1 to Host2 and vice-versa.
Kaiser & Petrescu Expires July 10, 2014 [Page 12]
Internet-Draft If-Sel January 2014
+-------+ +---------+ +---------+ +-------+
| Host1 | | Router1 | | Router2 | | Host2 |
+-------+ +---------+ +---------+ +-------+
| | | |
| +----+--------------+ | | |
| | RA | LCO cost = 5 | | | |
| +----+--------------+ | | |
I1 o<----------------------------o | |
| | | |
| +----+--------------+ | |
| | RA | LCO cost = 3 | | |
| +----+--------------+ | |
I2 o<------------------------------------------o |
| | | |
| +----+------------------+ | | |
| | RS | PCO dst = @Host2 | | | |
| +----+------------------+ | | |
I1 o---------------------------->o | |
| | | |
| +----+------------------+ | |
| | RS | PCO dst = @Host2 | | |
| +----+------------------+ | |
I2 o------------------------------------------>o |
| | | |
| +----+--------------+ | | |
| | RA | PCO cost = 2 | | | |
| +----+--------------+ | | |
I1 o<----------------------------o | |
| | | |
| +----+--------------+ | |
| | RA | PCO cost = 6 | | |
| +----+--------------+ | |
I2 o<------------------------------------------o |
| | | |
| +----+----------+ | +---------------+ |
| | DATA TO HOST2 | | | DATA TO HOST2 | |
| +----+----------+ | +---------------+ |
I1 o---------------------------->o--------------------------->o
| | | |
| +----+----------+ | +---------------+ |
| | DATA TO HOST1 | | | DATA TO HOST1 | |
| +----+----------+ | +---------------+ |
I1 o<----------------------------o<---------------------------o
| | | |
| | | |
Kaiser & Petrescu Expires July 10, 2014 [Page 13]
Internet-Draft If-Sel January 2014
6. Security Considerations
To be done.
Kaiser & Petrescu Expires July 10, 2014 [Page 14]
Internet-Draft If-Sel January 2014
7. IANA Considerations
IANA is kindly requested by the authors to allocate the following
values:
o The Link Cost Option type, which should be added to the Neighbor
Discovery option type space defined in section 13 of [RFC4861]
o The Path Cost Option type, which should be added to the Neighbor
Discovery option type space defined in section 13 of [RFC4861]
Kaiser & Petrescu Expires July 10, 2014 [Page 15]
Internet-Draft If-Sel January 2014
8. References
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Kaiser & Petrescu Expires July 10, 2014 [Page 16]
Internet-Draft If-Sel January 2014
Authors' Addresses
Arnaud Kaiser
Commissariat a l'Energie Atomique
8 Avenue de la Vauve
Palaiseau, Ile-de-France 91120
FR
Email: arnaud.kaiser@cea.fr
Alexandru Petrescu
Commissariat a l'Energie Atomique
8 Avenue de la Vauve
Palaiseau, Ile-de-France 91120
FR
Email: alexandru.petrescu@cea.fr
Kaiser & Petrescu Expires July 10, 2014 [Page 17]
