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]
