Internet DRAFT - draft-arumuganainar-rtgwg-dps-l4-ppn



INTERNET-DRAFT                                  Arunkumar Arumuga Nainar
Intended Status: Informational draft             Tata Communications Ltd
Expires: April 5, 2015                                   October 2, 2014

              Layer 4 Path preference negotiation for DPS


   This document is a supporting draft to draft-arumuganainar-rtgwg-DPS-
   Requirements-01. The DPS draft talks about high level architecture to
   implement dynamic path selection based on application. The DPS draft
   suggests the implementation to be done in three steps:  

   1) DPS Signaling: Here participating routers communicate with each
   other to exchange application related information

   2) Profile Based Filter: This section describes how packets can be
   classified and filtered 

   3) DPS Routing Frame Work: This ensures that separated traffic
   remains separated through out the network

   While overall architecture is still valid, this draft suggests an
   enhancement to the DPS Signaling component. The currently implemented
   technique uses BGP for the signaling requirements. Whilst this is
   good for certain cases, applications that can be off loaded to the
   secondary link are pre-decided. It restricts behavior from responding
   to dynamic network conditions. For example, a network administrator
   would want to off load some of the non-critical applications over the
   secondary link, however when there is acute congestion within the
   network, they might want the router to behave aggressively by off
   loading more applications to the secondary circuit. Yet while doing
   so there should not be any asymmetric routing on the network. 

   Since BGP is essentially a control plane protocol, it is not aware of
   what is happening on the network in the forwarding plane, hence there
   is a need to do the signaling in the forwarding plane. This drafts
   suggest one such mechanism. Here  the idea is to exchange the Path
   Preference information at layer 4 level. Such signaling could happen
   during TCP connection establishment phase. When done this way, a
   decision can be taken for each of the session and hence making it
   more dynamic than the one that can achieved through BGP.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the

Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 1]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

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
   ( 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. DPS Layer 4 Signaling Overview. . . . . . . . . . . . . . . . .  4
     3.Application Classification :-  . . . . . . . . . . . . . . . .  5
   4. Application List And Grey Scales  . . . . . . . . . . . . . . .  6
   5. Layer 7 Classification Issue:-  . . . . . . . . . . . . . . . .  7
   6. Customization Of Path Selection . . . . . . . . . . . . . . . .  8
   8. Implementation Details. . . . . . . . . . . . . . . . . . . . .  9
   7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8  Security Considerations . . . . . . . . . . . . . . . . . . . . 11

Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 2]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11


Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 3]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

1  Introduction

   BGP is used for signaling in the current implementation of DPS . BGP
   provides a consistent mechanism to exchange the Path Preference
   information between the two routers/sites. However, since BGP is a
   control plane protocol, we will not be able to exchange the
   dynamically changing network conditions. Here there is need to do the
   signaling in the forwarding plane.

   This draft proposes to do the signaling during the TCP connection
   establishment phase. When done this way the signaling is done for
   each session. This enables the router to be aware of network
   conditions dynamically and take the most appropriate path.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2. DPS Layer 4 Signaling Overview.

   The TCP connection establishment follows the three way process. This
   can be summarised in 3 steps:

      1) Client M/C first sends a SYN packet

      2) Sever M/C accepts the SYN and responds back with a SYN/ACK

      3) Client Acknowledges the SYN/ACK with an ACK

   During the whole process, many parameters will be exchanged and
   agreed upon. Some router implementations intercept these session
   initiation packets and influence the exchanged information. For
   example, routers could intercept the SYN packet and force the end
   hosts to negotiate a reduced MSS size.

   Similar legal intercept technique could be used to exchange Path
   Preference information.

   Client -----Router1 ====(Network)======Router2------Server

   Here the interception works in the below fashion:

   1) Client sends a packet to server


Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 4]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   2) Router 1 intercepts the SYN packet and adds TCP options. This
   option could be loaded with Path Preference information.  For
   example, let us assume there is no congestion on the client site's
   tail circuit. Hence, router 1 wants to send traffic that belongs to
   this session over the primary circuit.

   3) When router 2 receives the SYN packet with that known TCP option.
   It comes to know that the SYN is coming from a DPS capable site. It
   then caches the TCP state, strips the option and sends it to the

   4) When the server responds back with a SYN/ACK, router 2 intercepts
   the SYN/ACK and adds its Path Preference information in to the
   SYN/ACK packet using the same TCP option. Let's assume there is a
   congestion on the network at router 2, it replies back saying my side
   is congested so let us off load this session to the secondary link.

   5) Router 1, when it receives back the SYN/ACK it knows it is coming
   from a DPS capable site and the remote site wants the application to
   be off loaded to the secondary link.

   6) When the client sends back ACK, router 1 intercepts it and adds an
   option confirming that it agrees to the remote site choice to offload
   that session 

   Subsequently when the data packets are sent over a path that is
   negotiated and agreed. Here the preference of a particular path can
   be taken based on dynamic local network conditions. Since the path is
   negotiated and agreed across both ends, the network will respond to
   both local and remote network conditions.                            

3.Application Classification :-

   The key thing here is how does a router decide which application
   needs to be off loaded. This draft makes the following

   To begin with, the administrator of the network should prepare 3
   lists: a) white list b) grey list c) black list

   White List:- Application listed in the white list always goes over
   the primary link. The behavior does not change even if there is any
   congestion on the link. 

Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 5]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   Black List:- Application listed in the black list always goes over
   secondary link. Even when there is no congestion on the primary link.

   Grey List:- Application listed in the grey list behaves like a white
   list application when the primary link is not congested and behaves
   like a black list application when there is congestion.   

   It should be noted that the grey list behavior can also be a result
   of remote side congestion. For example, when given Site  prefers the
   primary link for the grey list application but the remote site
   prefers the back up link, then both sites will agree on back path for
   the session.

   Also the definition of application could also include a layer 7
   signature. For example:

      1) HTTP (TCP Port: 80) made to URL Could be put
      on a black list

      2) HTTP (TCP Port: 80) made to URL Could be put on
      a grey list 

   Hence it is mandatory that router implementations should support deep
   packet inspection for the purpose of classification (based on layer 7

4. Application List And Grey Scales

   While the 3 list hierarchy does seems to work. Under practical
   circumstances this is not sufficient. Network administrators will
   want to off load applications less aggressively when the utilization
   levels are very low. However, they may want to progressively off load
   more applications or TCP sessions. To illustrate this, the following
   example is given:

   Let us say following applications are listed as grey applications:

   Grey Shade 1:- Email, Intranet

   Grey Shade 2:- Video streaming application such as You Tube

   Grey shade 3:- All peer to peer applications.

   1) When link utilization is <=60 all grey applications will go over
   the primary link

   2) When link utilisation is >60 but <=70, shade 3 applications(peer-
   to-peer) will go over the secondary link

Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 6]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   3) When link link utilisation is >70 but <=90, shade 3 and shade 2
   applications (peer-to-peer & video streaming) will go over the

   4) When link utilisation is >90, all grey applications will be off

5. Layer 7 Classification Issue:-

   In order to make the off loading very effective, we should be able to
   do two things.

   1) Classification and grouping of protocol to be done based on L7

   2) Path Preferences should be negotiated per session. This actually
   provides the ability to react to local or remote network conditions

   Whilst negotiating the Path Preferences during the connection
   establishment, there will be problem reading the layer 7 Signatures
   during that phase. Layer 7 signature will be only know after the
   connection is established. Hence if the grey list is based on layer 7
   signatures, then direct negotiation of Path Preferences will not be
   possible. Hence an alternate approach needs to be worked out.

   To overcome the above problem, the draft suggests, rather than
   negotiating Path Preferences directly, we could get pre-authorization
   for the use of specific path. This will work based on the following

   1) When the SYN packet hits router, it intercepts that packet and
   adds a TCP option. This option will communicate what is the maximum
   grey shade that router  can send via the primary link. For example,
   if you have 6 shades of grey defined and if the TCP option indicates
   option 4, then it indicates router  is seeking pre-authorization for
   offloading applications that belongs to shade 5 or 6.

   2) However it could happen that in the remote site primary link is
   heavily congested and hence it would want to offload all applications
   that belong to shades 3, 4, 5 & 6. Hence it's router  responds back
   with TCP option set to 2.

   3) Since 2 is less than 4, Originating site-router  accepts Remote
   site router's choice and confirms it agreement by sending back the
   acceptance in the ACK message.


Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 7]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   When the connection is established routers in both site would have
   formally agreed what path to choose when they determine the layer 7
   signatures. Because of this pre-authorization,  there is no chance of
   asymmetric routing. In this scheme of things following rules apply:

   1) Administrator should clearly indicate what is LAN facing interface
   and what is WAN facing interface on the router. 

   2) Any SYN packet with no Path Preference information set would
   indicate the packet is coming from a site that does not have DPS
   enabled. In such a case normal routing will be followed to forward
   the packet.

   3) If the two routers specify different Path Preference information,
   the lowest number always wins. 

   Additionally it is based on the assumption that classification of
   application and grey scale definition will have to be done globally.
   This is because only grey scale levels are negotiated. The premise of
   the negotiation is based on the fact that once the grey scale is
   negotiated, the path of application could determined with certainty.
   This is only possible when the definitions are made globally. Hence
   the draft recommends any implementations should support central
   definition of an application list. And any individual routers/devices
   participating in DPS should be  able to pull the definition from
   central location so as avoid inconsistencies in path selection. 

   UDP and other non-TCP based application may not be able to
   participate in the negotiation. Hence they could be either placed in
   a white list or a black list.          

6. Customization Of Path Selection

   Though the definition of the white list, grey list and black list is
   universal across the network, customization is still possible. For
   example a smaller site with a smaller primary circuit can be
   configured to support only two shades grey. While Larger site that
   have large bandwidths can be configured to support 5 shades of grey.
   Also grey shade selection could also individually configured. For
   illustration following example is provided. 

   A given network 3 type of site.

   Site type A: Primary circuit : 100 MBPS , Secondary : 100 MBPS

   Site Type B: Primary circuit : 10 MBPS , Secondary : 10 MBPS

Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 8]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

   Site Type C: Primary circuit : 2 MBPS , Secondary : 2 MBPS

   Site type A and B can support all the 5 shades of grey. And site type
   C can support only 2 shades of grey.  Further site, type A starts off
   loading traffic when the utilization level goes above 80% while site
   type B does it when it crosses 60%.

   Even if we tweak this per site, the chance of asymmetric routing does
   not arise because two sites that are communicating will always
   negotiate the same grey levels to off load. 

8. Implementation Details.

   Currently many non-routing devices also perform deep packet
   inspection. For example, WAN optimization appliances. The signaling
   portion can also be off loaded to devices behind routers. In such a
   case DPS will be implemented on the router based on the traditional
   model. However the router will be configured to trust the marking
   done on the sites that hosts these WAN optimization devices. i.e
   Coloring will be done on an external device that is capable of doing
   deep packet inspection.

7. Summary

   Currently in the DPS implementation, signaling is done in the
   signaling plane via BGP. Because the signaling happens in the control
   plane, we are limited to define applications statically. It does not
   provide room for off loading applications based on dynamically
   changing network condition.

   By moving the signaling to forwarding plane, the draw back of the
   previous method of signaling can be done away with. 

   This draft suggests doing the signaling when the TCP connection is
   established. This draft also acknowledges difficulty to integrate
   layer 7 signatures based classification. To overcome this, the
   implementation should support global definition application lists.
   The two sites, whilst negotiating the Path Preferences, only
   negotiates the highest shade of grey that can sent over the primary

   In summary, it is possible to do the signaling of path preference
   information at layer 4. This would enable DPS implementation to alter
   the DPS behavior based on network level changes that are local or
   remote to the given site.


Arunkumar Arumuganainar  Expires April 5, 2015                  [Page 9]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

      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 5, 2015                 [Page 10]
INTERNET DRAFT   l4 path preference negotiation for DPS  October 2, 2014

8  Security Considerations


9  IANA Considerations


10  References

10.1  Normative References

10.2  Informative References

   11 Acknowledgements

    The authors would like to thank Hesham Moussa for his review and

Authors' Addresses

   Arunkumar Arumuga Nainar
   Tata Communications (UK)
   1st Floor
   20 Old Bailey
   London EC4M 7AN
   United Kingdom


Arunkumar Arumuganainar  Expires April 5, 2015                 [Page 11]