INTERNET-DRAFT Arunkumar Arumuga Nainar Intended Status: Informational draft Tata Communications Ltd Expires: April 6, 2015 October 3, 2014 Dynamic Path Selection use-cases draft-arumuganainar-rtgwg-dps-use-cases-01 Abstract Dynamic Path Selection is framework for offloading certain applications traffic that are considered not-so-critical by the network administrator on to a secondary paths ( The paths that are not considered best by routing protocols ). The frame work for implementing such a offloading mechanism is clearly defined in the draft draft-arumuganainar-rtgwg-DPS-requirements-01. This draft describes the use cases for DPS in brief. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 Arunkumar Arumuganainar Expires April 6, 2015 [Page 1] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 (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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic assumption . . . . . . . . . . . . . . . . . . . . . . . 3 3.Use Case 1:- Classical DPS . . . . . . . . . . . . . . . . . . . 5 4. Use Case 2 :- Adaptive DPS . . . . . . . . . . . . . . . . . . 6 5. Use Case 3 : Hierarchical DPS . . . . . . . . . . . . . . . . . 6 5. Use Case 4 : One Way DPS . . . . . . . . . . . . . . . . . . . 7 5. Use Case 5 : IP Based DPS . . . . . . . . . . . . . . . . . . . 8 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Arunkumar Arumuganainar Expires April 6, 2015 [Page 2] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 1 Introduction In a large enterprise environment, networks location is often distributed over large geographical area ( often it spreads across countries and continents). In such a case enterprises network managers often buy virtual private network from service providers. Such network is built over either MPLS or Internet/IPSEC extension to MPLS networks. Generally the enterprise end location connects in to Service provider using last mile connections. These last mile circuits comes in various technology options and bandwidth capacities. While service provider core is very resilient and virtually having infinite capacity in terms of bandwidth, the weak link in the enterprise network is indeed the last miles. Last miles are the costliest component for the enterprise and most of the times it contribute to 50-60% of total network costs. Yet these are the weakest link in the network. They constitutes single point of failure and does fail frequently. Hence in order to increase the network availability the network managers buy redundant links With redundant links in place, availability puzzle is fully resolved. However, it does pose a significant question. Half of the costliest resource that he has purchased will remain idle through out the life of this network. This happen while network managers work over time to resolves the issues that arise out of congestion in the primary circuit. There is a genuine need to identify few select application and offload them on to path that are considered to be best by routing protocols. The draft-arumuganainar-rtgwg-DPS-Requirements-00 defines requirements and the framework. This draft is a companion draft and describes various use cases for DPS. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Basic assumption Draft address the problem faced in a typical enterprise network. Typical enterprises comprise of collection of sites / Local area network that is spread across large geographical area (across Cities ,Countries and continents ). These sites are interconnected via Arunkumar Arumuganainar Expires April 6, 2015 [Page 3] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 virtual private network. Any such enterprises typically can go to single or multiple service providers to establish this connectivity. In such a case service provider will interconnect the site at their POP location via Last mile circuit. The choice last mile technology could be diverse such as ethernet, Frame relay , ATM , DSL, T1/E1/T3/E3 etc. Bandwidth capacity also varies from location to location ( as low as 512KBPS DSL to as high as 10 GIG Ethernet ). In cases when VPN connectivity is not possible ,VPN network can be extended in to a remote location via INTERNET/IPSEC technologies as well. Due to diverse nature of the connectivity option, any frame work should be agonistic to technologies and choice of providers. Router 1 --------POP1------| | -------------Customer VPN | SP- Managed CORE | | Router 2 --------Pop2------- Draft assumes availability is very important for the target enterprises. Hence there will be at least two last miles circuit that link them to service provider core. Again technology and last mile provider can chosen independently. Often enterprises selects a good or premium primary circuit and cheaper option for the secondary connectivity. For example 1) Primary : 10 MBPS Ethernet to MPLS ; Secondary :- 10 MBPS Ethernet to MPLS 2) Primary : 10 MBPS Ethernet to MPLS ; secondary :- 2MBPS E1 circuit to MPLS 3) Primary : 1.5MBPS T1 ; Secondary : ADSL 2+ Internet/IPSEC The above samples are for illustration taken from typical examples found on the field. Routing schemes usually designates Premium circuit option as primary. Routing protocol metrics will hence be better for the link and all the traffic goes over them as long as they are active. Traffic shift Arunkumar Arumuganainar Expires April 6, 2015 [Page 4] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 to secondary if the primary circuit goes down . This kind of routing scheme is called Active-Passive routing. However DPS framework as described in the draft draft-arumuganainar- rtgwg-DPS-use-cases-00 allows offloading of some application on to secondary. Network administrators can determine the offloading pattern to suit his/her needs. This draft documents several ways the offloading can be done/implemented. 3.Use Case 1:- Classical DPS This is more common in the real life deployments today. Here Network Administrator classifies the application in two categories 1) Critical - These are application that are very critical to business and should always travel in the Links that have the best metric 2) Non-Critical - These are application that are not very critical to business. There is no significant penalty that the business would incur if the applications are not available for relatively short period of time . However , better experience of these applications are key to over all use experience level. For example , if access to Internet/ Central proxy is not available for 6 Hrs , there is no significant penalty for the business. But over all better quality Internet access is going to improve the user experiences in the network. Such a type of classification can be done in two way. Method 1 :- Define certain known application as critical and rest of the other application should be non critical. Eg: Critical = { Telnet , RDP , Citrix and SAP } Non Critical = { Every thing else} Method 2 : Non-Critical = { Traffic to Proxy server } ; Critical = { Everything Else } It must be noted that all application should be assigned to either Critical set or non-critical ones. Un assigned applications are invalid under DPS framework. Once this is defined , DPS will kick in and start routing over various last mile links on the network Arunkumar Arumuganainar Expires April 6, 2015 [Page 5] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 4. Use Case 2 :- Adaptive DPS This is a slight modification to Classical DPS. Here in addition to critical and non-critical application sets , network administrator can also define not-so-critical application. The behavior of not so critcial application will depend on local or remote network conditions. To illustrate following example has be quoted. Network administrator , can define SMTP as not so critical application . He can also define network condition that will influence the path. For example if the Link utilization goes abouve 70% SMTP should be offloaded . Until that time SMTP will go over the primary path. Besides Link utilization many other parameters are possible such as Jitter , packet loss etc. Again Network administrator can define multiple levels in not-so- critical application. For example SMTP can be offloaded with Link utilization is above 70% where CIFS offloading will begin when the utilization is goes above 50% So in this scheme Network administrator will define multiple sets of application. 1) Critical Set : Always goes over primary path 2) Non Critical Set :- Alway goes over secondary path 3) Not-So-Critical Sets :- It can either go over primary or over secondary. It should be noted that not-so-critical application will be resolved in to critical or non-critical at the time of entry in to Edge router. Resolution in to critical and non-critical can either depend on local condition or the remote conditions. Hence Signaling should be done in the forwarding plane for adaptive DPS. 5. Use Case 3 : Hierarchical DPS To illustrate this following example is provided. Consider a small network consisting of 20 sites. The sites' profiles are categorized in to 3 types with the below configuration: * Type 1: Primary: 10 Mbps; Secondary: 2 Mbps * Type 2: Primary: 2 Mbps; Secondary: 8 Mbps/800 Kbps DSL Arunkumar Arumuganainar Expires April 6, 2015 [Page 6] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 Common applications used on the network are Citrix, SAP, SMTP, FTP & HTTP. Among which Citrix and SAP are very critical to the business and needs to be protected. The Network Manager wants to restrict Citrix and SAP to the primary link and the rest to the secondary link( Classical DPS ). This works well on Type 2 sites. These are small sites predominantly consisting of thin client. However on Type 1 sites are large sites with thick client. Users utilize applications such as SMTP and Lotus notes more than SAP and Citrix. In such a scenario site will end up in a scenario where there is high congestion on the 2MBPS circuit while utilization level on 10 MBPS primary circuit is very low. Hence Network Administrator wanted to follow a following heirarchy When Type 1 site talks to Type 2 sites , Critical application = { SAP and Citrix } When Type 1 circuit talks with another Type 1 site then critical application = { SAP , Citrix , SMTP and FTP } It should be noted that Type 2 sites whether it communicates with type 1 or type 2 Critical application will always be SAP and Citrix. The above example suggests two levels of hierarchy. In General 7 types of hierarchy is possible. 7 levels actually stems from the fact that in the current implementation IP precedence is used for coloring. IP Precedence restricts number of hierarchy to 7 . This restriction can be done away with if in the future , if alternate coloring mechanism is supported. 5. Use Case 4 : One Way DPS With Cloud services becoming very popular , Servers are being consolidated in to a remote Data Centers. These Data centers today comes with large Bandwidth pipes . Typically DR DCs are placed in alternate location. Hence it is very common to find DCs connected to the network with Single last mile. Withe Single last mile applications can not be offloaded . This will force remote sites to default to normal routing in order to meeting Symmetric routing requirement. This will eventually lead to polarization of links in the Remote sites. In order to overcome this , certain sites could be made DPS capable even through they have only one leg. In such as case Overlay DPS routing domain will be created over the single last mile . This will create a illusion that the Single legged DC will be able to Arunkumar Arumuganainar Expires April 6, 2015 [Page 7] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 participate in DPS . Impact could not be noticed on DC. But we could avoid polarization of links in the Remote sites. One way DPS is fully compatible with Classical DPS , Hierarchical DPS and Adaptive DPS methods . 5. Use Case 5 : IP Based DPS This is an extension of one Way DPS. But very popular in production environment. It is applied in DC-Remote site communications. Here Network administrators wanted to offload all applications to DC but only for sub set of IP address. For example traffic to the DCs from IP address which has got odd number in last octet in it IP address be offloaded . While even addresses will be going via Primary path. This is special case and can be implemented only between Remote sites and DCs. If the communications is between DCs-DCs or Remote sites and Remote sites is an invalid scenario. However IP Based DPS can co- exists with other forms of DPS. For example , 1) Remote site when talks with DC uses the IP Based Schema. 2) Remote Site when talks with another Remote sites it can use Classical or Adaptive schema 7. Summary DPS framework provides extreme flexibility to Network Administrators. Use cases documented above are the one that implemented in production environment. Draft draft-arumuganainar-rtgwg-DPS-requirements-00 suggests flexible frame work for implementing these use cases. There are several enhancements possible and suggested in the draft such as follows. 1) implementation of Signaling in the forwarding plane 2) Alternate mechanisms to color the packet than using IP Prec. 2) Supporting Layer 7 signatures in the profile based filters 3) Support for new and improved overlay routing mechanisms. Arunkumar Arumuganainar Expires April 6, 2015 [Page 8] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 All these when implemented can great increase flexibility Definitions and code { line 1 line 2 } Special characters examples: The characters , , , However, the characters \0, \&, \%, \" are displayed. .ti 0 is displayed in text instead of used as a directive. .\" is displayed in document instead of being treated as a comment C:\dir\subdir\file.ext Shows inclusion of backslash "\". Arunkumar Arumuganainar Expires April 6, 2015 [Page 9] INTERNET DRAFT Dynamic Path Selection use cases October 3, 2014 8 Security Considerations TBD 9 IANA Considerations TBD 10 References 10.1 Normative References 10.2 Informative References 11 Acknowledgements The authors would like to thank Hesham Moussa for his review and comments. Authors' Addresses Arunkumar Arumuga Nainar Tata Communications (UK) 1st Floor 20 Old Bailey London EC4M 7AN United Kingdom EMail: arun.arumuganainar@tatacommunications.com Arunkumar Arumuganainar Expires April 6, 2015 [Page 10]