Internet DRAFT - draft-chouasne-babel-tos-specific
draft-chouasne-babel-tos-specific
Network Working Group G. Chouasne
Internet-Draft J. Chroboczek
Updates: 6126 (if approved) PPS, University of Paris-Diderot
Intended status: Experimental July 3, 2017
Expires: January 4, 2018
TOS-Specific Routing in Babel
draft-chouasne-babel-tos-specific-00
Abstract
This document describes an extension to the Babel routing protocol to
support TOS-specific routing. This version is using mandatory sub-
TLVs.
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 January 4, 2018.
Copyright Notice
Copyright (c) 2017 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.
Chouasne & Chroboczek Expires January 4, 2018 [Page 1]
Internet-Draft TOS-Specific Routing in Babel July 2017
Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conceptual Description . . . . . . . . . . . . . . . . . 3
2.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 3
2.3. ToS-specific sub-TLV . . . . . . . . . . . . . . . . . . 4
2.4. ToS-specific Messages . . . . . . . . . . . . . . . . . . 5
3. Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ToS interpretation . . . . . . . . . . . . . . . . . . . 6
3.2. IP version . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Interaction with non-Tos-specific Babel . . . . . . . . . 6
3.4. Interaction with the Source-specific routing extension . 7
3.5. Forwarding Behavior . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction and background
The Type of Service (ToS) or Differentiated Services Code Point
(DSCP) is a field of the IPv4 and IPv6 headers that can be used to
request different per-hop behaviour when forwarding IP packets with
identical source and destination. The most common application of the
ToS field is to request different queueing policies (priority, drop
probability, etc.) from an AQM.
A slightly less common application of the ToS field is to take it
into account in addition to the destination address when performing a
routing decision. For example, a router that has a low-latency
default route with high monetary cost might announce it with a "low-
latency" ToS, and thus avoid carrying ordinary best-effort traffic
over the expensive route. A router that performs ToS-specific
routing maintains a routing table which instead of being merely
indexed by destination prefixes is indexed by pairs of a prefix and a
ToS value. In order to be routed according to a given entry in the
routing table, a packet must match not only the destination prefix
but also the ToS value. ToS-specific forwarding is described in more
detail in Section 3.5.
Just like ordinary routes, ToS-specific routes can be installed
manually but are more commonly installed by a dynamic routing
protocol. This document specifies an extension to the Babel routing
protocol [BABEL] that allows it to carry ToS-specific routes. This
extension considers the ToS field as an opaque value that is only
Chouasne & Chroboczek Expires January 4, 2018 [Page 2]
Internet-Draft TOS-Specific Routing in Babel July 2017
compared for equality, but ignores the two bits that have been
reserved for Explicit Congestion Notification (ECN) [RFC3168], and is
therefore compatible with the defintion of the ToS field used by DSCP
[DSCP].
The extended protocol remains interoperable with the unextended Babel
protocol in a sense made precise in Section 3.3.
2. Protocol Operation
2.1. Conceptual Description
ToS-specific routes are routes that are defined by the same
informations as classic routes, plus a ToS. This extension adds ToS-
specific routes to the non-ToS-specific routes handled by the
original Babel protocol.
This extension doesn't change the processing of non-ToS-specific
routes. A node implementing this extension behaves exactly like a
node implementing the original protocol as far as non-ToS-specific
routes are concerned.
ToS-specific routes are treated analogously to non-ToS-specific
routes, except for an additional ToS field in a number of data
structures (Section 2.2) and in the encoding of Update and Request
TLVs, which are augmented with a sub-TLV carrying the ToS. This sub-
TLV has the mandatory bit set ([BABEL] Section 4.4), and hence,
Updates and Requests for ToS-specific routes will be ignored by nodes
implementing only the original protocol. Therefore, ToS-specific
routes can only consist of a sequence of nodes implementing this
extension.
2.2. Data Structures
An implementation of Babel that implements this extension needs to
add a ToS field to a number of data structures it maintains.
2.2.1. The Source Table
The source table maintained by any Babel node, as described in
[BABEL], Section 3.2.4, is extended with the following field:
o the ToS specifying the ToS of packets to which this entry applies.
Chouasne & Chroboczek Expires January 4, 2018 [Page 3]
Internet-Draft TOS-Specific Routing in Babel July 2017
2.2.2. The Table of Pending Requests
The table of pending requests, maintained by any Babel node, as
described in [BABEL], Section 3.2.4, is extended with the following
field:
o the ToS being requested.
The table is now indexed by (prefix, ToS) pairs.
2.3. ToS-specific sub-TLV
This extension defines a new sub-TLV that adds a ToS field to a Babel
packet. It turns regular Updates, Route Requests and Seqno Requests
into ToS-specific Updates, Route Requests and Seqno Requests. Other
TLVs MUST NOT be sent with this sub-TLV attached. If any are
received, they will be silently ignored, as described in Section 4.4
of [BABEL].
A node MUST send ToS-specific Update, Route Request and Seqno Request
if the route they advertise is ToS-specific. Otherwise, a node MUST
send non-ToS-specific Update, Route Request and Seqno Request.
The ToS sub-TLV is defined as follow:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | ToS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields :
Type Set to TBD to indicate a ToS-specific mandatory sub-TLV.
Length The length of the body, exclusive of the Type and Length
fields. It MUST be set to 1.
ToS The ToS value of the ToS-specific route. This MUST be a
multiple of 4 (i.e. the two least-significant bits MUST be
0).
The value TBD has the mandatory bit set to 1 and this sub-TLV must
therefore be handled in accordance with Section 4.4 of [BABEL].
Chouasne & Chroboczek Expires January 4, 2018 [Page 4]
Internet-Draft TOS-Specific Routing in Babel July 2017
2.4. ToS-specific Messages
This section describes the handling of ToS-specific messages.
2.4.1. Updates
Whenever a ToS-specific Update is sent by a node implementing this
extension, the source table MUST be updated as follows : if an entry
indexed by (prefix, plen, router-id, ToS), exists, it MUST be
modified as described in section 3.7.3 of [BABEL]. Otherwise, a new
entry is created with value (prefix, plen, router-id, ToS, seqno,
metric).
2.4.2. Requests
Whenever a node implementing this extension sends a ToS-specific
Request, it MUST add its content as an entry to the Pending Requests
Table, as described in section 3.2.7 of [BABEL], with the suitable
ToS.
2.4.2.1. Route Requests
When a node implementing this extension receives a ToS-specific Route
Request for a prefix (prefix, plen) and a ToS t, it checks its route
table for a selected route with this prefix, plen, and with ToS t in
the corresponding source. If such a route doesn't exist, it MUST
send a ToS-specific retraction for that prefix.
When a node implementing this extension receives a wildcard Route
Request, it SHOULD send a full routing table dump, as described in
Section 3.8.1.1 of [BABEL]. Therefore, it SHOULD also dump its ToS-
specific routes.
2.4.2.2. Seqno Requests
When a node receives a Seqno Request for a prefix (prefix, plen) with
a ToS-specific sub-TLV with ToS t, it MUST send a ToS-specific update
with ToS t for a selected route specified by the Plen, Prefix and
Source ToS field, with either a router-id different from what is
specified by the Router-Id field, or a Seqno no less than what is
specified by the Seqno field. If there is no such route in the Route
Table, it MUST forward the seqno request according to the rules
defined in Section 3.8.1.2 of [BABEL].
Chouasne & Chroboczek Expires January 4, 2018 [Page 5]
Internet-Draft TOS-Specific Routing in Babel July 2017
3. Interaction
This section describes the interaction of this extension with other
protocols and other versions of Babel.
3.1. ToS interpretation
Several interpretations have been defined for the ToS field.
This extension ignores the last two bits of the field, while the
first six bits of the ToS field are opaque to this extension. Hence,
it is compatible with all extensions that don't use the last two bits
of the field. This is the case of all interpretations known to us.
In particular, it is compatible with the Differentiated Service Field
interpretation (DSCP), defined in RFC 2474, the original
interpretation described in RFC 791, and the ECN protocol, described
in RFC 3168.
In the case of the DSCP interpretation, one must note that a packet
with a DSCP value will follow the route with the ToS being four times
this value.
Details on how packets are forwarded are provided in Section 3.5.
3.2. IP version
This protocol extension is compatible with IPV4 and IPV6. AE fields
MUST be filled accordingly, as described in Section 4.1.3 of [BABEL].
3.3. Interaction with non-Tos-specific Babel
The encoding of ToS-specific Updates and Requests is using a reserved
sub-TLV. This means that, as defined in section 4.4 of [BABEL], they
will be ignored by nodes that don't implement this extension, which
means that non-ToS-specific nodes will not treat ToS-specific routes.
In a topology of routers implementing ToS-specific Babel and non-ToS-
specific Babel, all packets will reach their destination if it is
reachable. Non-ToS-specific packets will follow the same routes as
if ToS-specific routers were non-ToS-specific routers. ToS-specific
packets may switch to a non-ToS-specific route if and only if there
is no route for the required ToS.
This extension uses a mandatory bit on each sub-TLV. It is necessary
that this bit is set to 1 for all ToS-specific sub-TLV to avoid
loops, as shown in the following example.
Chouasne & Chroboczek Expires January 4, 2018 [Page 6]
Internet-Draft TOS-Specific Routing in Babel July 2017
Consider two neighboring routers A and B, A implementing the ToS-
specific Babel extension, and B implementing just the base Babel
protocol. Suppose that A has a ToS-specific route for a prefix P and
ToS t.
B will receive an update from A with this ToS-specific route.
Suppose that B reads the update TLV but drops the ToS-specific sub-
TLV. It will now forwards packets for P through A.
B will then send an update for the route to (P) to A. A will take B
as next-hop for the matching packets.
When a packet with no ToS arrives to A or B, it will travel between A
and B indefinitely, as shown in the figure below.
(P) (P)
--> <--
----------- A ----------------- B -----------
<--
(P, t)
3.4. Interaction with the Source-specific routing extension
The ToS-specific routing extension is compatible with the source-
specific extension. A node implementing ToS-specific routing and
source-specific routing handles ToS-specific routes and source-
specific routes. To achieve this, data structures are extended with
a ToS field and a source field.
In principle, a node could handle routes that are both ToS- and
source-specific. In that case, Updates and Requests advertising
source-and-ToS-specific routes would need to be sent with both the
source prefix sub-TLV and the ToS sub-TLV, and a route preference
ordering for source-and-ToS-specific packets would need to be
defined. Until such an ordering is defined, updates with both the
source prefix and ToS sub-TLVs MUST NOT be sent, and, if received,
MUST be silently dropped.
3.5. Forwarding Behavior
When a packet for an address A arrives to a node, it may match
several routes. The node MUST choose the route with the destination-
first ordering.
This ordering only considers routes that have either no ToS or the
Tos of the packet (ignoring the last two bits). It forwards a packet
through the route with the most specific prefix. If there are two
routes with the same prefix, then one of them has no ToS and the
Chouasne & Chroboczek Expires January 4, 2018 [Page 7]
Internet-Draft TOS-Specific Routing in Babel July 2017
other has the ToS of the packet (ignoring the last two bits). The
packet is following the latter. If there is no route with a matching
prefix, the packet is dropped.
When a ToS-specific route is retracted while the router has another
non-ToS-specific route, packets should fall back to this non-ToS-
specific route as fast as possible, to avoid more delay. Hence, it
is RECOMMENDED to use the algorithm described in Section 3.5.5 of
[BABEL]
A Babel implementation of this extension must ensure that these
semantics are observed. If they aren't, the implementation MUST
disambiguate the routing tables by using a suitable algorithm (for
example the algorithm of Boutier [SS-ROUTING]).
It may be the case that the forwarding plane cannot handle some ToS
values. In that case, routes with these values as ToS MUST NOT be
selected and therefore MUST NOT be announced.
4. IANA Considerations
IANA is instructed to add the following entry to the "Babel sub-TLV
type" registry:
+------+------------------+-----------------+
| Type | Name | Reference |
+------+------------------+-----------------+
| TBD | ToS-specific TLV | (this document) |
+------+------------------+-----------------+
5. Security considerations
The extension defined in this protocol defines three new sub-TLVs for
defined TLVs. This extension doesn't alterate any of the security
properties of the base protocol.
6. References
6.1. Normative References
[BABEL] Chroboczek, J., "The Babel Routing Protocol", draft-
chroboczek-babel-rfc6126bis-03 (work in progress), July
2016.
Chouasne & Chroboczek Expires January 4, 2018 [Page 8]
Internet-Draft TOS-Specific Routing in Babel July 2017
6.2. Informative References
[SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing",
August 2014.
In Proc. IFIP Networking 2015. A slightly earlier
version is available online from http://arxiv.org/
pdf/1403.0445.
Authors' Addresses
Gwendoline Chouasne
PPS, University of Paris-Diderot
Case 7014
75205 Paris Cedex 13
France
Email: gwendoline.chouasne-guillon@ens.fr
Juliusz Chroboczek
PPS, University of Paris-Diderot
Case 7014
75205 Paris Cedex 13
France
Email: jch@irif.fr
Chouasne & Chroboczek Expires January 4, 2018 [Page 9]
