idnits 2.17.1 draft-chouasne-babel-tos-specific-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '... TLVs MUST NOT be sent with this sub...' RFC 2119 keyword, line 160: '... A node MUST send ToS-specific Updat...' RFC 2119 keyword, line 161: '... ToS-specific. Otherwise, a node MUST...' RFC 2119 keyword, line 177: '... fields. It MUST be set to 1....' RFC 2119 keyword, line 179: '...he ToS-specific route. This MUST be a...' (17 more instances...) -- The draft header indicates that this document updates RFC6126, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3168' is mentioned on line 98, but not defined == Missing Reference: 'DSCP' is mentioned on line 100, but not defined -- Unexpected draft version: The latest known version of draft-chroboczek-babel-rfc6126bis is -00, but you're referring to -03. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chouasne 3 Internet-Draft J. Chroboczek 4 Updates: 6126 (if approved) PPS, University of Paris-Diderot 5 Intended status: Experimental July 3, 2017 6 Expires: January 4, 2018 8 TOS-Specific Routing in Babel 9 draft-chouasne-babel-tos-specific-00 11 Abstract 13 This document describes an extension to the Babel routing protocol to 14 support TOS-specific routing. This version is using mandatory sub- 15 TLVs. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction and background . . . . . . . . . . . . . . . . . 2 52 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Conceptual Description . . . . . . . . . . . . . . . . . 3 54 2.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. ToS-specific sub-TLV . . . . . . . . . . . . . . . . . . 4 56 2.4. ToS-specific Messages . . . . . . . . . . . . . . . . . . 5 57 3. Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. ToS interpretation . . . . . . . . . . . . . . . . . . . 6 59 3.2. IP version . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.3. Interaction with non-Tos-specific Babel . . . . . . . . . 6 61 3.4. Interaction with the Source-specific routing extension . 7 62 3.5. Forwarding Behavior . . . . . . . . . . . . . . . . . . . 7 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 6.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction and background 72 The Type of Service (ToS) or Differentiated Services Code Point 73 (DSCP) is a field of the IPv4 and IPv6 headers that can be used to 74 request different per-hop behaviour when forwarding IP packets with 75 identical source and destination. The most common application of the 76 ToS field is to request different queueing policies (priority, drop 77 probability, etc.) from an AQM. 79 A slightly less common application of the ToS field is to take it 80 into account in addition to the destination address when performing a 81 routing decision. For example, a router that has a low-latency 82 default route with high monetary cost might announce it with a "low- 83 latency" ToS, and thus avoid carrying ordinary best-effort traffic 84 over the expensive route. A router that performs ToS-specific 85 routing maintains a routing table which instead of being merely 86 indexed by destination prefixes is indexed by pairs of a prefix and a 87 ToS value. In order to be routed according to a given entry in the 88 routing table, a packet must match not only the destination prefix 89 but also the ToS value. ToS-specific forwarding is described in more 90 detail in Section 3.5. 92 Just like ordinary routes, ToS-specific routes can be installed 93 manually but are more commonly installed by a dynamic routing 94 protocol. This document specifies an extension to the Babel routing 95 protocol [BABEL] that allows it to carry ToS-specific routes. This 96 extension considers the ToS field as an opaque value that is only 97 compared for equality, but ignores the two bits that have been 98 reserved for Explicit Congestion Notification (ECN) [RFC3168], and is 99 therefore compatible with the defintion of the ToS field used by DSCP 100 [DSCP]. 102 The extended protocol remains interoperable with the unextended Babel 103 protocol in a sense made precise in Section 3.3. 105 2. Protocol Operation 107 2.1. Conceptual Description 109 ToS-specific routes are routes that are defined by the same 110 informations as classic routes, plus a ToS. This extension adds ToS- 111 specific routes to the non-ToS-specific routes handled by the 112 original Babel protocol. 114 This extension doesn't change the processing of non-ToS-specific 115 routes. A node implementing this extension behaves exactly like a 116 node implementing the original protocol as far as non-ToS-specific 117 routes are concerned. 119 ToS-specific routes are treated analogously to non-ToS-specific 120 routes, except for an additional ToS field in a number of data 121 structures (Section 2.2) and in the encoding of Update and Request 122 TLVs, which are augmented with a sub-TLV carrying the ToS. This sub- 123 TLV has the mandatory bit set ([BABEL] Section 4.4), and hence, 124 Updates and Requests for ToS-specific routes will be ignored by nodes 125 implementing only the original protocol. Therefore, ToS-specific 126 routes can only consist of a sequence of nodes implementing this 127 extension. 129 2.2. Data Structures 131 An implementation of Babel that implements this extension needs to 132 add a ToS field to a number of data structures it maintains. 134 2.2.1. The Source Table 136 The source table maintained by any Babel node, as described in 137 [BABEL], Section 3.2.4, is extended with the following field: 139 o the ToS specifying the ToS of packets to which this entry applies. 141 2.2.2. The Table of Pending Requests 143 The table of pending requests, maintained by any Babel node, as 144 described in [BABEL], Section 3.2.4, is extended with the following 145 field: 147 o the ToS being requested. 149 The table is now indexed by (prefix, ToS) pairs. 151 2.3. ToS-specific sub-TLV 153 This extension defines a new sub-TLV that adds a ToS field to a Babel 154 packet. It turns regular Updates, Route Requests and Seqno Requests 155 into ToS-specific Updates, Route Requests and Seqno Requests. Other 156 TLVs MUST NOT be sent with this sub-TLV attached. If any are 157 received, they will be silently ignored, as described in Section 4.4 158 of [BABEL]. 160 A node MUST send ToS-specific Update, Route Request and Seqno Request 161 if the route they advertise is ToS-specific. Otherwise, a node MUST 162 send non-ToS-specific Update, Route Request and Seqno Request. 164 The ToS sub-TLV is defined as follow: 166 0 1 2 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type = TBD | Length | ToS | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Fields : 174 Type Set to TBD to indicate a ToS-specific mandatory sub-TLV. 176 Length The length of the body, exclusive of the Type and Length 177 fields. It MUST be set to 1. 179 ToS The ToS value of the ToS-specific route. This MUST be a 180 multiple of 4 (i.e. the two least-significant bits MUST be 181 0). 183 The value TBD has the mandatory bit set to 1 and this sub-TLV must 184 therefore be handled in accordance with Section 4.4 of [BABEL]. 186 2.4. ToS-specific Messages 188 This section describes the handling of ToS-specific messages. 190 2.4.1. Updates 192 Whenever a ToS-specific Update is sent by a node implementing this 193 extension, the source table MUST be updated as follows : if an entry 194 indexed by (prefix, plen, router-id, ToS), exists, it MUST be 195 modified as described in section 3.7.3 of [BABEL]. Otherwise, a new 196 entry is created with value (prefix, plen, router-id, ToS, seqno, 197 metric). 199 2.4.2. Requests 201 Whenever a node implementing this extension sends a ToS-specific 202 Request, it MUST add its content as an entry to the Pending Requests 203 Table, as described in section 3.2.7 of [BABEL], with the suitable 204 ToS. 206 2.4.2.1. Route Requests 208 When a node implementing this extension receives a ToS-specific Route 209 Request for a prefix (prefix, plen) and a ToS t, it checks its route 210 table for a selected route with this prefix, plen, and with ToS t in 211 the corresponding source. If such a route doesn't exist, it MUST 212 send a ToS-specific retraction for that prefix. 214 When a node implementing this extension receives a wildcard Route 215 Request, it SHOULD send a full routing table dump, as described in 216 Section 3.8.1.1 of [BABEL]. Therefore, it SHOULD also dump its ToS- 217 specific routes. 219 2.4.2.2. Seqno Requests 221 When a node receives a Seqno Request for a prefix (prefix, plen) with 222 a ToS-specific sub-TLV with ToS t, it MUST send a ToS-specific update 223 with ToS t for a selected route specified by the Plen, Prefix and 224 Source ToS field, with either a router-id different from what is 225 specified by the Router-Id field, or a Seqno no less than what is 226 specified by the Seqno field. If there is no such route in the Route 227 Table, it MUST forward the seqno request according to the rules 228 defined in Section 3.8.1.2 of [BABEL]. 230 3. Interaction 232 This section describes the interaction of this extension with other 233 protocols and other versions of Babel. 235 3.1. ToS interpretation 237 Several interpretations have been defined for the ToS field. 239 This extension ignores the last two bits of the field, while the 240 first six bits of the ToS field are opaque to this extension. Hence, 241 it is compatible with all extensions that don't use the last two bits 242 of the field. This is the case of all interpretations known to us. 243 In particular, it is compatible with the Differentiated Service Field 244 interpretation (DSCP), defined in RFC 2474, the original 245 interpretation described in RFC 791, and the ECN protocol, described 246 in RFC 3168. 248 In the case of the DSCP interpretation, one must note that a packet 249 with a DSCP value will follow the route with the ToS being four times 250 this value. 252 Details on how packets are forwarded are provided in Section 3.5. 254 3.2. IP version 256 This protocol extension is compatible with IPV4 and IPV6. AE fields 257 MUST be filled accordingly, as described in Section 4.1.3 of [BABEL]. 259 3.3. Interaction with non-Tos-specific Babel 261 The encoding of ToS-specific Updates and Requests is using a reserved 262 sub-TLV. This means that, as defined in section 4.4 of [BABEL], they 263 will be ignored by nodes that don't implement this extension, which 264 means that non-ToS-specific nodes will not treat ToS-specific routes. 266 In a topology of routers implementing ToS-specific Babel and non-ToS- 267 specific Babel, all packets will reach their destination if it is 268 reachable. Non-ToS-specific packets will follow the same routes as 269 if ToS-specific routers were non-ToS-specific routers. ToS-specific 270 packets may switch to a non-ToS-specific route if and only if there 271 is no route for the required ToS. 273 This extension uses a mandatory bit on each sub-TLV. It is necessary 274 that this bit is set to 1 for all ToS-specific sub-TLV to avoid 275 loops, as shown in the following example. 277 Consider two neighboring routers A and B, A implementing the ToS- 278 specific Babel extension, and B implementing just the base Babel 279 protocol. Suppose that A has a ToS-specific route for a prefix P and 280 ToS t. 282 B will receive an update from A with this ToS-specific route. 283 Suppose that B reads the update TLV but drops the ToS-specific sub- 284 TLV. It will now forwards packets for P through A. 286 B will then send an update for the route to (P) to A. A will take B 287 as next-hop for the matching packets. 289 When a packet with no ToS arrives to A or B, it will travel between A 290 and B indefinitely, as shown in the figure below. 292 (P) (P) 293 --> <-- 294 ----------- A ----------------- B ----------- 295 <-- 296 (P, t) 298 3.4. Interaction with the Source-specific routing extension 300 The ToS-specific routing extension is compatible with the source- 301 specific extension. A node implementing ToS-specific routing and 302 source-specific routing handles ToS-specific routes and source- 303 specific routes. To achieve this, data structures are extended with 304 a ToS field and a source field. 306 In principle, a node could handle routes that are both ToS- and 307 source-specific. In that case, Updates and Requests advertising 308 source-and-ToS-specific routes would need to be sent with both the 309 source prefix sub-TLV and the ToS sub-TLV, and a route preference 310 ordering for source-and-ToS-specific packets would need to be 311 defined. Until such an ordering is defined, updates with both the 312 source prefix and ToS sub-TLVs MUST NOT be sent, and, if received, 313 MUST be silently dropped. 315 3.5. Forwarding Behavior 317 When a packet for an address A arrives to a node, it may match 318 several routes. The node MUST choose the route with the destination- 319 first ordering. 321 This ordering only considers routes that have either no ToS or the 322 Tos of the packet (ignoring the last two bits). It forwards a packet 323 through the route with the most specific prefix. If there are two 324 routes with the same prefix, then one of them has no ToS and the 325 other has the ToS of the packet (ignoring the last two bits). The 326 packet is following the latter. If there is no route with a matching 327 prefix, the packet is dropped. 329 When a ToS-specific route is retracted while the router has another 330 non-ToS-specific route, packets should fall back to this non-ToS- 331 specific route as fast as possible, to avoid more delay. Hence, it 332 is RECOMMENDED to use the algorithm described in Section 3.5.5 of 333 [BABEL] 335 A Babel implementation of this extension must ensure that these 336 semantics are observed. If they aren't, the implementation MUST 337 disambiguate the routing tables by using a suitable algorithm (for 338 example the algorithm of Boutier [SS-ROUTING]). 340 It may be the case that the forwarding plane cannot handle some ToS 341 values. In that case, routes with these values as ToS MUST NOT be 342 selected and therefore MUST NOT be announced. 344 4. IANA Considerations 346 IANA is instructed to add the following entry to the "Babel sub-TLV 347 type" registry: 349 +------+------------------+-----------------+ 350 | Type | Name | Reference | 351 +------+------------------+-----------------+ 352 | TBD | ToS-specific TLV | (this document) | 353 +------+------------------+-----------------+ 355 5. Security considerations 357 The extension defined in this protocol defines three new sub-TLVs for 358 defined TLVs. This extension doesn't alterate any of the security 359 properties of the base protocol. 361 6. References 363 6.1. Normative References 365 [BABEL] Chroboczek, J., "The Babel Routing Protocol", draft- 366 chroboczek-babel-rfc6126bis-03 (work in progress), July 367 2016. 369 6.2. Informative References 371 [SS-ROUTING] 372 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 373 August 2014. 375 In Proc. IFIP Networking 2015. A slightly earlier 376 version is available online from http://arxiv.org/ 377 pdf/1403.0445. 379 Authors' Addresses 381 Gwendoline Chouasne 382 PPS, University of Paris-Diderot 383 Case 7014 384 75205 Paris Cedex 13 385 France 387 Email: gwendoline.chouasne-guillon@ens.fr 389 Juliusz Chroboczek 390 PPS, University of Paris-Diderot 391 Case 7014 392 75205 Paris Cedex 13 393 France 395 Email: jch@irif.fr