I-D Action: draft-arumuganainar-rtgwg-dps-l4-ppn-00.txt

internet-drafts@ietf.org Tue, 08 April 2014 11:13 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-arumuganainar-rtgwg-dps-l4-ppn-00.txt
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140408111259.7710.29015.idtracker@ietfa.amsl.com>
Date: Tue, 08 Apr 2014 04:12:59 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/i-d-announce/q538x-Pr-U_E55RsZEg3Fcrk4SU
Reply-To: internet-drafts@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Layer 4 Path preference negotiation for DPS
        Author          : Arunkumar Arumuga Nainar
	Filename        : draft-arumuganainar-rtgwg-dps-l4-ppn-00.txt
	Pages           : 11
	Date            : 2014-04-08

Abstract:
   This document is a supporting draft to draft-arumuganainar-rtgwg-DPS-
   Requirements-00. 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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-arumuganainar-rtgwg-dps-l4-ppn/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-arumuganainar-rtgwg-dps-l4-ppn-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

I-D Action: draft-arumuganainar-rtgwg-dps-l4-ppn-… internet-drafts