idnits 2.17.1 draft-arumuganainar-rtgwg-dps-use-cases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 321 has weird spacing: '...e sites is an...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 3, 2014) is 3490 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 114 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 3 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 6, 2015 October 3, 2014 6 Dynamic Path Selection use-cases 7 draft-arumuganainar-rtgwg-dps-use-cases-01 9 Abstract 11 Dynamic Path Selection is framework for offloading certain 12 applications traffic that are considered not-so-critical by the 13 network administrator on to a secondary paths ( The paths that are 14 not considered best by routing protocols ). The frame work for 15 implementing such a offloading mechanism is clearly defined in the 16 draft draft-arumuganainar-rtgwg-DPS-requirements-01. 18 This draft describes the use cases for DPS in brief. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Basic assumption . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.Use Case 1:- Classical DPS . . . . . . . . . . . . . . . . . . . 5 62 4. Use Case 2 :- Adaptive DPS . . . . . . . . . . . . . . . . . . 6 63 5. Use Case 3 : Hierarchical DPS . . . . . . . . . . . . . . . . . 6 64 5. Use Case 4 : One Way DPS . . . . . . . . . . . . . . . . . . . 7 65 5. Use Case 5 : IP Based DPS . . . . . . . . . . . . . . . . . . . 8 66 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 68 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 69 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 71 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1 Introduction 76 In a large enterprise environment, networks location is often 77 distributed over large geographical area ( often it spreads across 78 countries and continents). In such a case enterprises network 79 managers often buy virtual private network from service providers. 80 Such network is built over either MPLS or Internet/IPSEC extension to 81 MPLS networks. 83 Generally the enterprise end location connects in to Service provider 84 using last mile connections. These last mile circuits comes in 85 various technology options and bandwidth capacities. While service 86 provider core is very resilient and virtually having infinite 87 capacity in terms of bandwidth, the weak link in the enterprise 88 network is indeed the last miles. 90 Last miles are the costliest component for the enterprise and most of 91 the times it contribute to 50-60% of total network costs. Yet these 92 are the weakest link in the network. They constitutes single point of 93 failure and does fail frequently. Hence in order to increase the 94 network availability the network managers buy redundant links 96 With redundant links in place, availability puzzle is fully resolved. 97 However, it does pose a significant question. Half of the costliest 98 resource that he has purchased will remain idle through out the life 99 of this network. This happen while network managers work over time to 100 resolves the issues that arise out of congestion in the primary 101 circuit. 103 There is a genuine need to identify few select application and 104 offload them on to path that are considered to be best by routing 105 protocols. The draft-arumuganainar-rtgwg-DPS-Requirements-00 defines 106 requirements and the framework. This draft is a companion draft and 107 describes various use cases for DPS. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Basic assumption 117 Draft address the problem faced in a typical enterprise network. 118 Typical enterprises comprise of collection of sites / Local area 119 network that is spread across large geographical area (across Cities 120 ,Countries and continents ). These sites are interconnected via 121 virtual private network. Any such enterprises typically can go to 122 single or multiple service providers to establish this connectivity. 124 In such a case service provider will interconnect the site at their 125 POP location via Last mile circuit. The choice last mile technology 126 could be diverse such as ethernet, Frame relay , ATM , DSL, 127 T1/E1/T3/E3 etc. Bandwidth capacity also varies from location to 128 location ( as low as 512KBPS DSL to as high as 10 GIG Ethernet ). In 129 cases when VPN connectivity is not possible ,VPN network can be 130 extended in to a remote location via INTERNET/IPSEC technologies as 131 well. Due to diverse nature of the connectivity option, any frame 132 work should be agonistic to technologies and choice of providers. 134 Router 1 --------POP1------| 135 | 136 -------------Customer VPN 137 | SP- Managed CORE 138 | 139 | 140 Router 2 --------Pop2------- 142 Draft assumes availability is very important for the target 143 enterprises. Hence there will be at least two last miles circuit that 144 link them to service provider core. Again technology and last mile 145 provider can chosen independently. Often enterprises selects a good 146 or premium primary circuit and cheaper option for the secondary 147 connectivity. For example 149 1) Primary : 10 MBPS Ethernet to MPLS ; Secondary :- 10 MBPS Ethernet 150 to MPLS 152 2) Primary : 10 MBPS Ethernet to MPLS ; secondary :- 2MBPS E1 circuit 153 to MPLS 155 3) Primary : 1.5MBPS T1 ; Secondary : ADSL 2+ Internet/IPSEC 157 The above samples are for illustration taken from typical examples 158 found on the field. 160 Routing schemes usually designates Premium circuit option as primary. 161 Routing protocol metrics will hence be better for the link and all 162 the traffic goes over them as long as they are active. Traffic shift 163 to secondary if the primary circuit goes down . This kind of routing 164 scheme is called Active-Passive routing. 166 However DPS framework as described in the draft draft-arumuganainar- 167 rtgwg-DPS-use-cases-00 allows offloading of some application on to 168 secondary. Network administrators can determine the offloading 169 pattern to suit his/her needs. This draft documents several ways the 170 offloading can be done/implemented. 172 3.Use Case 1:- Classical DPS 174 This is more common in the real life deployments today. Here Network 175 Administrator classifies the application in two categories 177 1) Critical - These are application that are very critical to 178 business and should always travel in the Links that have the best 179 metric 181 2) Non-Critical - These are application that are not very critical to 182 business. There is no significant penalty that the business would 183 incur if the applications are not available for relatively short 184 period of time . However , better experience of these applications 185 are key to over all use experience level. For example , if access to 186 Internet/ Central proxy is not available for 6 Hrs , there is no 187 significant penalty for the business. But over all better quality 188 Internet access is going to improve the user experiences in the 189 network. 191 Such a type of classification can be done in two way. 193 Method 1 :- Define certain known application as critical and rest of 194 the other application should be non critical. 196 Eg: Critical = { Telnet , RDP , Citrix and SAP } Non Critical = { 197 Every thing else} 199 Method 2 : Non-Critical = { Traffic to Proxy server } ; Critical = { 200 Everything Else } 202 It must be noted that all application should be assigned to either 203 Critical set or non-critical ones. Un assigned applications are 204 invalid under DPS framework. Once this is defined , DPS will kick in 205 and start routing over various last mile links on the network 207 4. Use Case 2 :- Adaptive DPS 209 This is a slight modification to Classical DPS. Here in addition to 210 critical and non-critical application sets , network administrator 211 can also define not-so-critical application. The behavior of not so 212 critcial application will depend on local or remote network 213 conditions. 215 To illustrate following example has be quoted. Network administrator 216 , can define SMTP as not so critical application . He can also define 217 network condition that will influence the path. For example if the 218 Link utilization goes abouve 70% SMTP should be offloaded . Until 219 that time SMTP will go over the primary path. Besides Link 220 utilization many other parameters are possible such as Jitter , 221 packet loss etc. 223 Again Network administrator can define multiple levels in not-so- 224 critical application. For example SMTP can be offloaded with Link 225 utilization is above 70% where CIFS offloading will begin when the 226 utilization is goes above 50% 228 So in this scheme Network administrator will define multiple sets of 229 application. 231 1) Critical Set : Always goes over primary path 233 2) Non Critical Set :- Alway goes over secondary path 235 3) Not-So-Critical Sets :- It can either go over primary or over 236 secondary. 238 It should be noted that not-so-critical application will be resolved 239 in to critical or non-critical at the time of entry in to Edge 240 router. Resolution in to critical and non-critical can either depend 241 on local condition or the remote conditions. Hence Signaling should 242 be done in the forwarding plane for adaptive DPS. 244 5. Use Case 3 : Hierarchical DPS 246 To illustrate this following example is provided. 248 Consider a small network consisting of 20 sites. The sites' profiles 249 are categorized in to 3 types with the below configuration: 251 * Type 1: Primary: 10 Mbps; Secondary: 2 Mbps 252 * Type 2: Primary: 2 Mbps; Secondary: 8 Mbps/800 Kbps DSL 254 Common applications used on the network are Citrix, SAP, SMTP, FTP & 255 HTTP. Among which Citrix and SAP are very critical to the business 256 and needs to be protected. 258 The Network Manager wants to restrict Citrix and SAP to the primary 259 link and the rest to the secondary link( Classical DPS ). This works 260 well on Type 2 sites. These are small sites predominantly consisting 261 of thin client. However on Type 1 sites are large sites with thick 262 client. Users utilize applications such as SMTP and Lotus notes more 263 than SAP and Citrix. In such a scenario site will end up in a 264 scenario where there is high congestion on the 2MBPS circuit while 265 utilization level on 10 MBPS primary circuit is very low. 267 Hence Network Administrator wanted to follow a following heirarchy 269 When Type 1 site talks to Type 2 sites , Critical application = { SAP 270 and Citrix } 272 When Type 1 circuit talks with another Type 1 site then critical 273 application = { SAP , Citrix , SMTP and FTP } 275 It should be noted that Type 2 sites whether it communicates with 276 type 1 or type 2 Critical application will always be SAP and Citrix. 278 The above example suggests two levels of hierarchy. In General 7 279 types of hierarchy is possible. 7 levels actually stems from the fact 280 that in the current implementation IP precedence is used for 281 coloring. IP Precedence restricts number of hierarchy to 7 . This 282 restriction can be done away with if in the future , if alternate 283 coloring mechanism is supported. 285 5. Use Case 4 : One Way DPS 287 With Cloud services becoming very popular , Servers are being 288 consolidated in to a remote Data Centers. These Data centers today 289 comes with large Bandwidth pipes . Typically DR DCs are placed in 290 alternate location. Hence it is very common to find DCs connected to 291 the network with Single last mile. 293 Withe Single last mile applications can not be offloaded . This will 294 force remote sites to default to normal routing in order to meeting 295 Symmetric routing requirement. This will eventually lead to 296 polarization of links in the Remote sites. 298 In order to overcome this , certain sites could be made DPS capable 299 even through they have only one leg. In such as case Overlay DPS 300 routing domain will be created over the single last mile . This will 301 create a illusion that the Single legged DC will be able to 302 participate in DPS . Impact could not be noticed on DC. But we could 303 avoid polarization of links in the Remote sites. 305 One way DPS is fully compatible with Classical DPS , Hierarchical DPS 306 and Adaptive DPS methods . 308 5. Use Case 5 : IP Based DPS 310 This is an extension of one Way DPS. But very popular in production 311 environment. It is applied in DC-Remote site communications. 313 Here Network administrators wanted to offload all applications to DC 314 but only for sub set of IP address. For example traffic to the DCs 315 from IP address which has got odd number in last octet in it IP 316 address be offloaded . While even addresses will be going via Primary 317 path. 319 This is special case and can be implemented only between Remote sites 320 and DCs. If the communications is between DCs-DCs or Remote sites and 321 Remote sites is an invalid scenario. However IP Based DPS can co- 322 exists with other forms of DPS. 324 For example , 326 1) Remote site when talks with DC uses the IP Based Schema. 328 2) Remote Site when talks with another Remote sites it can use 329 Classical or Adaptive schema 331 7. Summary 333 DPS framework provides extreme flexibility to Network Administrators. 334 Use cases documented above are the one that implemented in production 335 environment. 337 Draft draft-arumuganainar-rtgwg-DPS-requirements-00 suggests flexible 338 frame work for implementing these use cases. There are several 339 enhancements possible and suggested in the draft such as follows. 341 1) implementation of Signaling in the forwarding plane 343 2) Alternate mechanisms to color the packet than using IP Prec. 345 2) Supporting Layer 7 signatures in the profile based filters 347 3) Support for new and improved overlay routing mechanisms. 349 All these when implemented can great increase flexibility 351 Definitions and code { 352 line 1 353 line 2 354 } 356 Special characters examples: 358 The characters , , , 359 However, the characters \0, \&, \%, \" are displayed. 361 .ti 0 is displayed in text instead of used as a directive. 362 .\" is displayed in document instead of being treated as a comment 364 C:\dir\subdir\file.ext Shows inclusion of backslash "\". 366 8 Security Considerations 368 TBD 370 9 IANA Considerations 372 TBD 374 10 References 376 10.1 Normative References 378 10.2 Informative References 380 11 Acknowledgements 382 The authors would like to thank Hesham Moussa for his review and 383 comments. 385 Authors' Addresses 387 Arunkumar Arumuga Nainar 388 Tata Communications (UK) 389 1st Floor 390 20 Old Bailey 391 London EC4M 7AN 392 United Kingdom 394 EMail: arun.arumuganainar@tatacommunications.com