idnits 2.17.1 draft-arumuganainar-rtgwg-dps-l4-ppn-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 40 has weird spacing: '...m. Here the i...' == Line 197 has weird spacing: '...en Site prefe...' == Line 269 has weird spacing: '... router can s...' == Line 271 has weird spacing: '... router is se...' == Line 276 has weird spacing: '... router respo...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2, 2014) is 3494 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 119 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Arunkumar Arumuga Nainar 3 Intended Status: Informational draft Tata Communications Ltd 4 Expires: April 5, 2015 October 2, 2014 6 Layer 4 Path preference negotiation for DPS 7 draft-arumuganainar-rtgwg-dps-l4-ppn-01 9 Abstract 11 This document is a supporting draft to draft-arumuganainar-rtgwg-DPS- 12 Requirements-01. The DPS draft talks about high level architecture to 13 implement dynamic path selection based on application. The DPS draft 14 suggests the implementation to be done in three steps: 16 1) DPS Signaling: Here participating routers communicate with each 17 other to exchange application related information 19 2) Profile Based Filter: This section describes how packets can be 20 classified and filtered 22 3) DPS Routing Frame Work: This ensures that separated traffic 23 remains separated through out the network 25 While overall architecture is still valid, this draft suggests an 26 enhancement to the DPS Signaling component. The currently implemented 27 technique uses BGP for the signaling requirements. Whilst this is 28 good for certain cases, applications that can be off loaded to the 29 secondary link are pre-decided. It restricts behavior from responding 30 to dynamic network conditions. For example, a network administrator 31 would want to off load some of the non-critical applications over the 32 secondary link, however when there is acute congestion within the 33 network, they might want the router to behave aggressively by off 34 loading more applications to the secondary circuit. Yet while doing 35 so there should not be any asymmetric routing on the network. 37 Since BGP is essentially a control plane protocol, it is not aware of 38 what is happening on the network in the forwarding plane, hence there 39 is a need to do the signaling in the forwarding plane. This drafts 40 suggest one such mechanism. Here the idea is to exchange the Path 41 Preference information at layer 4 level. Such signaling could happen 42 during TCP connection establishment phase. When done this way, a 43 decision can be taken for each of the session and hence making it 44 more dynamic than the one that can achieved through BGP. 46 Status of this Memo 48 This Internet-Draft is submitted to IETF in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as 54 Internet-Drafts. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/1id-abstracts.html 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html 67 Copyright and License Notice 69 Copyright (c) 2013 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. DPS Layer 4 Signaling Overview. . . . . . . . . . . . . . . . . 4 87 3.Application Classification :- . . . . . . . . . . . . . . . . 5 88 4. Application List And Grey Scales . . . . . . . . . . . . . . . 6 89 5. Layer 7 Classification Issue:- . . . . . . . . . . . . . . . . 7 90 6. Customization Of Path Selection . . . . . . . . . . . . . . . . 8 91 8. Implementation Details. . . . . . . . . . . . . . . . . . . . . 9 92 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 94 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 95 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 10.1 Normative References . . . . . . . . . . . . . . . . . . . 11 97 10.2 Informative References . . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 100 1 Introduction 102 BGP is used for signaling in the current implementation of DPS . BGP 103 provides a consistent mechanism to exchange the Path Preference 104 information between the two routers/sites. However, since BGP is a 105 control plane protocol, we will not be able to exchange the 106 dynamically changing network conditions. Here there is need to do the 107 signaling in the forwarding plane. 109 This draft proposes to do the signaling during the TCP connection 110 establishment phase. When done this way the signaling is done for 111 each session. This enables the router to be aware of network 112 conditions dynamically and take the most appropriate path. 114 1.1 Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. DPS Layer 4 Signaling Overview. 122 The TCP connection establishment follows the three way process. This 123 can be summarised in 3 steps: 125 1) Client M/C first sends a SYN packet 127 2) Sever M/C accepts the SYN and responds back with a SYN/ACK 129 3) Client Acknowledges the SYN/ACK with an ACK 131 During the whole process, many parameters will be exchanged and 132 agreed upon. Some router implementations intercept these session 133 initiation packets and influence the exchanged information. For 134 example, routers could intercept the SYN packet and force the end 135 hosts to negotiate a reduced MSS size. 137 Similar legal intercept technique could be used to exchange Path 138 Preference information. 140 Client -----Router1 ====(Network)======Router2------Server 142 Here the interception works in the below fashion: 144 1) Client sends a packet to server 145 2) Router 1 intercepts the SYN packet and adds TCP options. This 146 option could be loaded with Path Preference information. For 147 example, let us assume there is no congestion on the client site's 148 tail circuit. Hence, router 1 wants to send traffic that belongs to 149 this session over the primary circuit. 151 3) When router 2 receives the SYN packet with that known TCP option. 152 It comes to know that the SYN is coming from a DPS capable site. It 153 then caches the TCP state, strips the option and sends it to the 154 server. 156 4) When the server responds back with a SYN/ACK, router 2 intercepts 157 the SYN/ACK and adds its Path Preference information in to the 158 SYN/ACK packet using the same TCP option. Let's assume there is a 159 congestion on the network at router 2, it replies back saying my side 160 is congested so let us off load this session to the secondary link. 162 5) Router 1, when it receives back the SYN/ACK it knows it is coming 163 from a DPS capable site and the remote site wants the application to 164 be off loaded to the secondary link. 166 6) When the client sends back ACK, router 1 intercepts it and adds an 167 option confirming that it agrees to the remote site choice to offload 168 that session 170 Subsequently when the data packets are sent over a path that is 171 negotiated and agreed. Here the preference of a particular path can 172 be taken based on dynamic local network conditions. Since the path is 173 negotiated and agreed across both ends, the network will respond to 174 both local and remote network conditions. 176 3.Application Classification :- 178 The key thing here is how does a router decide which application 179 needs to be off loaded. This draft makes the following 180 recommendations. 182 To begin with, the administrator of the network should prepare 3 183 lists: a) white list b) grey list c) black list 185 White List:- Application listed in the white list always goes over 186 the primary link. The behavior does not change even if there is any 187 congestion on the link. 189 Black List:- Application listed in the black list always goes over 190 secondary link. Even when there is no congestion on the primary link. 192 Grey List:- Application listed in the grey list behaves like a white 193 list application when the primary link is not congested and behaves 194 like a black list application when there is congestion. 196 It should be noted that the grey list behavior can also be a result 197 of remote side congestion. For example, when given Site prefers the 198 primary link for the grey list application but the remote site 199 prefers the back up link, then both sites will agree on back path for 200 the session. 202 Also the definition of application could also include a layer 7 203 signature. For example: 205 1) HTTP (TCP Port: 80) made to URL www.youtube.com. Could be put 206 on a black list 208 2) HTTP (TCP Port: 80) made to URL www.gmail.com. Could be put on 209 a grey list 211 Hence it is mandatory that router implementations should support deep 212 packet inspection for the purpose of classification (based on layer 7 213 signature) 215 4. Application List And Grey Scales 217 While the 3 list hierarchy does seems to work. Under practical 218 circumstances this is not sufficient. Network administrators will 219 want to off load applications less aggressively when the utilization 220 levels are very low. However, they may want to progressively off load 221 more applications or TCP sessions. To illustrate this, the following 222 example is given: 224 Let us say following applications are listed as grey applications: 226 Grey Shade 1:- Email, Intranet 228 Grey Shade 2:- Video streaming application such as You Tube 230 Grey shade 3:- All peer to peer applications. 232 1) When link utilization is <=60 all grey applications will go over 233 the primary link 235 2) When link utilisation is >60 but <=70, shade 3 applications(peer- 236 to-peer) will go over the secondary link 237 3) When link link utilisation is >70 but <=90, shade 3 and shade 2 238 applications (peer-to-peer & video streaming) will go over the 239 secondary 241 4) When link utilisation is >90, all grey applications will be off 242 loaded 244 5. Layer 7 Classification Issue:- 246 In order to make the off loading very effective, we should be able to 247 do two things. 249 1) Classification and grouping of protocol to be done based on L7 250 signatures 252 2) Path Preferences should be negotiated per session. This actually 253 provides the ability to react to local or remote network conditions 255 Whilst negotiating the Path Preferences during the connection 256 establishment, there will be problem reading the layer 7 Signatures 257 during that phase. Layer 7 signature will be only know after the 258 connection is established. Hence if the grey list is based on layer 7 259 signatures, then direct negotiation of Path Preferences will not be 260 possible. Hence an alternate approach needs to be worked out. 262 To overcome the above problem, the draft suggests, rather than 263 negotiating Path Preferences directly, we could get pre-authorization 264 for the use of specific path. This will work based on the following 265 rules. 267 1) When the SYN packet hits router, it intercepts that packet and 268 adds a TCP option. This option will communicate what is the maximum 269 grey shade that router can send via the primary link. For example, 270 if you have 6 shades of grey defined and if the TCP option indicates 271 option 4, then it indicates router is seeking pre-authorization for 272 offloading applications that belongs to shade 5 or 6. 274 2) However it could happen that in the remote site primary link is 275 heavily congested and hence it would want to offload all applications 276 that belong to shades 3, 4, 5 & 6. Hence it's router responds back 277 with TCP option set to 2. 279 3) Since 2 is less than 4, Originating site-router accepts Remote 280 site router's choice and confirms it agreement by sending back the 281 acceptance in the ACK message. 283 When the connection is established routers in both site would have 284 formally agreed what path to choose when they determine the layer 7 285 signatures. Because of this pre-authorization, there is no chance of 286 asymmetric routing. In this scheme of things following rules apply: 288 1) Administrator should clearly indicate what is LAN facing interface 289 and what is WAN facing interface on the router. 291 2) Any SYN packet with no Path Preference information set would 292 indicate the packet is coming from a site that does not have DPS 293 enabled. In such a case normal routing will be followed to forward 294 the packet. 296 3) If the two routers specify different Path Preference information, 297 the lowest number always wins. 299 Additionally it is based on the assumption that classification of 300 application and grey scale definition will have to be done globally. 301 This is because only grey scale levels are negotiated. The premise of 302 the negotiation is based on the fact that once the grey scale is 303 negotiated, the path of application could determined with certainty. 304 This is only possible when the definitions are made globally. Hence 305 the draft recommends any implementations should support central 306 definition of an application list. And any individual routers/devices 307 participating in DPS should be able to pull the definition from 308 central location so as avoid inconsistencies in path selection. 310 UDP and other non-TCP based application may not be able to 311 participate in the negotiation. Hence they could be either placed in 312 a white list or a black list. 314 6. Customization Of Path Selection 316 Though the definition of the white list, grey list and black list is 317 universal across the network, customization is still possible. For 318 example a smaller site with a smaller primary circuit can be 319 configured to support only two shades grey. While Larger site that 320 have large bandwidths can be configured to support 5 shades of grey. 321 Also grey shade selection could also individually configured. For 322 illustration following example is provided. 324 A given network 3 type of site. 326 Site type A: Primary circuit : 100 MBPS , Secondary : 100 MBPS 328 Site Type B: Primary circuit : 10 MBPS , Secondary : 10 MBPS 329 Site Type C: Primary circuit : 2 MBPS , Secondary : 2 MBPS 331 Site type A and B can support all the 5 shades of grey. And site type 332 C can support only 2 shades of grey. Further site, type A starts off 333 loading traffic when the utilization level goes above 80% while site 334 type B does it when it crosses 60%. 336 Even if we tweak this per site, the chance of asymmetric routing does 337 not arise because two sites that are communicating will always 338 negotiate the same grey levels to off load. 340 8. Implementation Details. 342 Currently many non-routing devices also perform deep packet 343 inspection. For example, WAN optimization appliances. The signaling 344 portion can also be off loaded to devices behind routers. In such a 345 case DPS will be implemented on the router based on the traditional 346 model. However the router will be configured to trust the marking 347 done on the sites that hosts these WAN optimization devices. i.e 348 Coloring will be done on an external device that is capable of doing 349 deep packet inspection. 351 7. Summary 353 Currently in the DPS implementation, signaling is done in the 354 signaling plane via BGP. Because the signaling happens in the control 355 plane, we are limited to define applications statically. It does not 356 provide room for off loading applications based on dynamically 357 changing network condition. 359 By moving the signaling to forwarding plane, the draw back of the 360 previous method of signaling can be done away with. 362 This draft suggests doing the signaling when the TCP connection is 363 established. This draft also acknowledges difficulty to integrate 364 layer 7 signatures based classification. To overcome this, the 365 implementation should support global definition application lists. 366 The two sites, whilst negotiating the Path Preferences, only 367 negotiates the highest shade of grey that can sent over the primary 368 circuit. 370 In summary, it is possible to do the signaling of path preference 371 information at layer 4. This would enable DPS implementation to alter 372 the DPS behavior based on network level changes that are local or 373 remote to the given site. 375 Definitions and code { 376 line 1 377 line 2 378 } 380 Special characters examples: 382 The characters , , , 383 However, the characters \0, \&, \%, \" are displayed. 385 .ti 0 is displayed in text instead of used as a directive. 386 .\" is displayed in document instead of being treated as a comment 388 C:\dir\subdir\file.ext Shows inclusion of backslash "\". 390 8 Security Considerations 392 TBD 394 9 IANA Considerations 396 TBD 398 10 References 400 10.1 Normative References 402 10.2 Informative References 404 11 Acknowledgements 406 The authors would like to thank Hesham Moussa for his review and 407 comments. 409 Authors' Addresses 411 Arunkumar Arumuga Nainar 412 Tata Communications (UK) 413 1st Floor 414 20 Old Bailey 415 London EC4M 7AN 416 United Kingdom 418 EMail: arun.arumuganainar@tatacommunications.com