Internet DRAFT - draft-arumuganainar-rtgwg-dps-use-cases

draft-arumuganainar-rtgwg-dps-use-cases



 



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]