INTERNET-DRAFT Arunkumar Arumuga Nainar Intended Status: Informational draft Tata Communications Ltd Expires: April 4, 2014 October 1, 2013 Dynamic Path Selection (DPS) Based on Application draft-aumuganainar-rtgwg-dps-00 Abstract The document describes a network design architecture for routing packets via different paths available in the network based on application port number. Primarily, this is targeted for Enterprise customers who have built up redundancy at their WAN edge but are suffering from a congested primary link whilst the secondary is idle. The objective of this architecture is as follows 1) Offload bulky application on to the secondary link 2) Achieve the above with out introducing asymmetric routing in the network 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 Arunkumar Arumuganainar Expires April 4, 2014 [Page 1] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. DPS Architecture Overview. . . . . . . . . . . . . . . . . . . 4 3.DPS Signaling:- . . . . . . . . . . . . . . . . . . . . . . . 4 4. DPS Profile Based Packet Filter . . . . . . . . . . . . . . . . 10 5. DPS Routing Frame Work:- . . . . . . . . . . . . . . . . . . . 12 6. DPS Fault-detection mechanism . . . . . . . . . . . . . . . . . 14 8. Implementation Details. . . . . . . . . . . . . . . . . . . . . 14 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Arunkumar Arumuganainar Expires April 4, 2014 [Page 2] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 1 Introduction The high availability puzzle can be resolved by building in resiliency to network designs. Whilst active/backup routing schemes are sufficient to create redundancy with low convergence times the following deficiencies and customer demands are not addressed comprehensively. 1. IP routing is essentially best path based. This will lead to underutilized or over utilized links. 2. WAN application performance could be adversely impacted due to congestion whilst the backup link remains idle. Techniques such as DiffServ QoS do address the problem effectively, but those approaches address only the symptoms and not the root cause. 3. Half of the network resources that the end customer has paid for, always remains unused .This is a matter of huge concern for small and mid-size customers as WAN circuit costs are very high and recurring. Existing Solutions One way to address the above problems is to load balance the traffic across the available links. To enable load balancing, there are several methods that are available today such as the following. 1. Equal Cost Load balancing 2. GLBP (Global Load Balancing Protocol) based load balancing 3. Optimized Edge Routing (OER) - Cisco proprietary feature 4. Policy based routing However all these techniques can only be implemented at per-hop level. This would mean load balancing techniques need to be applied on each and every device that the traffic passes through. Failure to do so, might result in asymmetric routing and out of order packets. This invariably results in serious application performance issues. Proposed solution:- To address this problem, a new architecture called Dynamic Path Selection or DPS is being proposed. DPS provides the frame work for separating applications that have different QoS requirements and sends them along two different paths in the network. By sending different applications on different links, DPS will able to Arunkumar Arumuganainar Expires April 4, 2014 [Page 3] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 successfully address all the issues reported above with out compromising network availability. 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. DPS Architecture Overview. The objective of DPS is to achieve end-to-end application separation with out introducing asymmetric routing within the network. In order to ensure the above objectives, we should have a comprehensive mechanism to achieve the following tasks. Task 1: Any two sites participating in DPS will have to agree on a common set of applications that it will send using either the primary routing path or the secondary routing path (also called a DPS path). This happens in the control plane and will be implemented at the time routing information is exchanged. Please refer to DPS Signaling section for more details. Task 2: At the time of forwarding the packets, packet should be filtered based on application and the capabilities of remote sites. Packets should than be pushed in to appropriate paths. Please refer to DPS Profile Based Packet filter section for more details. Task 3: If the packet is pushed in to a DPS path, it should always use the secondary link end to end. This is achieved by building an overlay VPN network (called DPS Routing Domain) over the normal IP/MPLS network using commonly available technologies such as DMVPN (Dynamic Multipoint VPN) tunnels and VRF (Virtual Routing and Forwarding) instances. Please refer to DPS Routing Frame Work section for more details. Task 4: A comprehensive fault detection mechanism should be put in place to detect the faults in the DPS domain. In such a case, the DPS traffic should be re-routed via the normal routing domain. Please refer to the DPS Fault-Detection & Recovery mechanism section for more details. 3.DPS Signaling:- DPS Signaling will enable sites to actively exchange their DPS Arunkumar Arumuganainar Expires April 4, 2014 [Page 4] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 capabilities dynamically and agree on which set of applications that it will treat as critical and non-critical. DPS architecture assumes existence of dual links on sites that are participating in DPS. For the sake of discussion, the applications to be transported across the first link (also called a primary link) are termed a critical applications and the set of applications that need to be transported across the second link (also called a secondary link) are termed non- critical applications. In order to achieve the above objective, the Network Manager will be required to define the application profile. Information defined in the application profile will be communicated to all participating sites and a decision will be taken locally based on the profile information received for forwarding the packet. Definition of DPS Profile:- A DPS profile is defined as a non-overlapping applications that is treated as critical. The Network Manager will be free to define multiple DPS profiles as long as the application defined in them does not overlap with any of the previously defined DPS profiles. For example:- Profile 1: { Citrix, SAP, RTP, H.325 } Profile 2: { FTP , HTTP } Profile 3: { SMTP, POP3 } . . So on and so forth... Examples quoted above are purely arbitrary and in practice, the definition will be left to the discretion of Network Managers. Any application that is not a member of the critical application set will be treated as non-critical. Note: Alternatively customers/Network managers can also define non- critical application. In such a application that is not a member of non-critical application set will be treated as Critical. The definition is valid as long as no application is a member of more than 1 profile. A site on the network can be defined to conform to one or more profiles. In such a case, the list of applications that the given site can potentially treat as critical is the union of all the profiles that it conforms to. Arunkumar Arumuganainar Expires April 4, 2014 [Page 5] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 Critical application set for site X = Union of all the conforming profiles. DPS path selection is unidirectional. In order to avoid asymmetric routing, we must ensure any two participating sites should define a common set of applications as critical. In such a case, if X and Y are two participating sites, then: Critical Application Set for (X, Y) Pair = Critical Application Set for Site (X) n Critical Application Set for Site (Y) Note: Any application that is not a member of the Critical Application set will be treated as non-critical and will go over the DPS path. Special Case:- It is very much possible that there could be a site within the network that does not have DPS capability. For example: 1. Site might be a small site and might not have dual links and hence DPS will not be applicable to them. 2. When a network is being migrated, the sites that have not been migrated to the new network may not understand DPS and hence should not be treated as a DPS capable site. In such cases routing to and from the sites will have to follow normal IP routing path. To handle this special case, a default profile will be defined called Profile 0: Profile 0: { } is a null set. When a DPS capable site X communicates with a non-DPS Capable site Z then: Critical Application Set for (X,Z) pair = Critical Application Set for Site (X) n Critical Application Set for Site (Z) = { } or a Null set. The behavior for Null set is that all traffic will be treated as critical and will be routed via normal routing domain. Hierarchical model for associating profiles to the site. In order to aid the following objectives, a hierarchical model based Arunkumar Arumuganainar Expires April 4, 2014 [Page 6] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 on M-Tree is proposed for DPS. The M-Tree based approach is a design guideline that provides the network manager with the following benefits: 1. Provides guidelines for association rules between sites and application profiles. 2. Helps translate the above concept/rules in deployment practice using available tools and technologies. M-Tree based Association Model As per this model, application profiles will be arranged in the form of the M-Tree as per the following rule: Default profile or Profile 0 will form the root the tree. Other profile will be assigned as a child. Each parent can have any number of child. Design Note: Technically the depth of tree could be infinite.However implementation schemes could impose its own restrictions. At present we rely on IP precedence to mark the depth of the tree. This restricts the depth of tree to 8 (8 levels including Level 0). Level 0 +-------------------------------------------------------------------+ Profile(0,0) IP Prec=0 community: Null + | + | + +___________________|________________+ Level 1 + +------|-------------------|----------------|-----------------------+ | | | IP Prec=1 v v v + Profile(1,1) Profile(1,2) Profile(1,3) + community: 1:1 community: 1:2 community:1:3 + | + +_________|__________+ + | | Level 2 +---------------------|--------------------|------------------------+ | | IP Prec=2 V V + Profile(2,1) Profile(2,2) + Community: 2:1 community: 2:2 + | + | + +_________|__________+ + Arunkumar Arumuganainar Expires April 4, 2014 [Page 7] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 | | Level 3 +--------------------------------|--------------------|-------------+ | | IP Prec=3 v v + Profile(3,1) Profile(3,3) + community: 3:1 community: 3:2 + +-------------------------------------------------------------------+ Usage of non-IP Precedence based marking could possibly extend the depth of the tree. Couple of mechanism are suggested as possible alternatives and listed below. 1. IP DSCP based marking scheme (up to 64 levels possible). 2. QOS Group based marking scheme (up to 100 levels possible). However marking tree depth or DPS level using IP DSCP or QOS group is not possible using tools currently available in operating systems of networking devices such as Cisco's IOS. It will require minimum amount of code-development effort to take advantage of the above schemes. Till that time, IP Precedence will be used for implementing the framework on a production network and all implementations until that time will be subjected to the known restriction associated with IP Precedence. In the above tree structure, a site can be associated with any of the profiles located in any of the levels. Under such a scenario, the critical application set is defined by following equation: Critical Application Set for give Node i,j = Profile(i,j) U Profile( Parent of Profile(i,j) ) for all values of i,j In order to translate the tree structure in to actual deployment practice, each node or profile will be associated with a standard BGP community and each level will be associated with an IP precedence value. The choice of BGP community is arbitrary and is determined by the administrator. The IP precedence value chosen will be equal to the level at which the profile is located. Because DPS signaling relies on BGP community, when the network is deployed, it is mandatory that the primary link of the DPS capable site should run BGP and all the underlying providers support transport of BGP communities. When a site advertises its routing information, it advertises the community associated with its own profile and all its parents' as well. It should be noted that at any given level, a profile will send only one community (along with the community list of its parent). Arunkumar Arumuganainar Expires April 4, 2014 [Page 8] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 Once the communities are sent, the receiving site will interpret the communities. The interpretation of communities is limited to the communities that the given site advertises. Other communities are silently ignored. A site will receive a BGP prefix and associate an IP precedence to the prefix based on the highest level of the matching communities. For example if a site is in Level N, then it will use following algorithm to associate an IP Precedence for the receiving profile. If Level N community is present , then Set IP Precedence to N If Level N-1 community is present then Set IP Precedence to N-1 . . . If Level 2 community is a present then Set IP Precedence to 2 If Level 1 community is a present then Set IP Precedence to 1 If there is no matching community at all Set IP Precedence to 0 The deployment of above DPS Signaling Mechanism leverages an existing feature called QoS Policy Propagation via BGP (QPPB). This is commonly used feature on networking devices and it is used for propagating QOS marking information in the BGP advertisements. Even though it is not designed to carry DPS signaling, the QPPB functionality is leveraged to achieve DPS signaling. This would mean no additional code changes are required to be done on network devices to achieve this. Note:- All of the above happen in the control plane (before the packet gets forwarded). However the actual marking happens when the packet hits the site's primary LAN interface. A packet will be remarked as the rules set above using QPPB. Once the packet is marked, then the packet will taken through profile based filtering where the decision will be taken about which routing domain will be referred to while forwarding the packet. Practical Illustration of DPS Profiles 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 * Type 3: Primary: 8 Mbps/800 Kbps DSL; Secondary: None 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. Arunkumar Arumuganainar Expires April 4, 2014 [Page 9] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 The Network Manager wants to restrict Citrix and SAP to the primary link and the rest to the secondary link. 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 utilise applications such as SMTP and Lotus notes more than SAP and Citrix. Here a problem is noticed. There is high congestion on the 2 Mbps secondary link. SMTP and FTP are business traffic but by nature they are bulky. Because Type 1 sites have a large number of thick clients,the portion of this traffic is also high. Hence there is the desire to offload SMTP and FTP on to the large 10Mbps link. Based on the above scenario Profile tree can be built as follows. Profile 0: { } - This is null set ; BGP Community: None and Precedence = 0. Profile 1: {Citrix, SAP } with BGP Community : 100:1 and Precedence = 1. Profile 2: {SMTP, FTP} with BGP Community : 100:2 and Precedence = 2. This configuration will result in following: Case 1: When Type 1 talks to Type 1 Site: Critical Application = {Citrix, SAP, SMTP, FTP} Case 2: When Type 1 talks to Type 2 Site: Critical Application = {Citrix, SAP} Case 3: When Type 2 talks to Type 2 Site: Critical Application = {Citrix, SAP} Case 4: When Type1 talks to Type 3 Site: Critical Application = { } Case 5: When Type 2 talks to Type 3 Site: Critical Application = { } Case 6: When Type 3 talks to Type 3 Site: Critical Application = { } 4. DPS Profile Based Packet Filter DPS Profile Based Packet Filter attempts to filter packets based on DPS profiles and pushes them in to the relevant DPS routing domain or the normal routing domain. It happens in two steps: Arunkumar Arumuganainar Expires April 4, 2014 [Page 10] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 > STEP 1:- Colour or mark the packet based on DPS capabilities of the destination site as per the rules set by DPS Signaling. > STEP 2:- Filter the packets based on application and the DPS capabilities of the source-destination pair. STEP 1: Colouring or Marking of Packets. The actual marking happens when the packet hits the routers LAN interface. The packet will be remarked as per the rules set during the DPS signaling by QPPB. Once the packet is marked, the packet will be taken through profile based filtering where the decision to forward it to the relevant routing domain will be taken. Design Note: Because QPPB remarks the traffic, Trust based QoS model will not be supported when DPS is turned on in a given site. However, QoS can still be applied on DPS capable sites; this is achieved by performing explicit classification and marking at the router before applying QoS policies on the out bound interface. Note: Current DPS implementation supports only IP Precedence based markings. However with a little bit of development effort other mechanisms such as QoS group can also be adopted. When this is done, restrictions on trust based QoS model will cease to exist. Here the packet is appropriately coloured so that we can pass this through a profile based filter. 1. Application of the incoming packet is an element of Critical Application Set for (X,Z) then it will be push to normal routing domain. 2. Otherwise it will be pushed to DPS routing domain. 3.Special condition rule also applies here, i.e. if Critical Application Set for (X,Z) is a null set then packet will be pushed to normal routing domain. This Profile based filter will be applied on the LAN interface of the router. Once the traffic hits the primary router, the traffic gets separated as DPS traffic or as normal traffic and gets pushed to appropriate routing domain. Implementation models for Profile based filter is done through two common features/technologies: 1. Packet filters (Access Control List) based on TCP and UDP application port numbers and IP Precedence. 2. Policy based Routing (PBR). Arunkumar Arumuganainar Expires April 4, 2014 [Page 11] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 PBR will use simple next hop feature to push the traffic in to the DPS domain (please refer to DPS Routing Framework section for more details). However in case of single router, dual circuit scenario, a modified version of PBR will be used. Here, PBR will be used to select the VRF domain based on which packet will have to be routed. This feature is called VRF selection based on PBR and it is common feature used on most of networking devices including Cisco. It should be noted that there are several restrictions on PBR match criteria in most implementations such as matching IP Precedence using extend ACLs is not supported. However this mechanism has be tested and implemented in Cisco's software based routing platforms such as ISRs. Also during our implementation, we have found that PBR had huge impact on routers performance. Hence future implementations based on sleek model using Layer 4 port numbers and IP Precedence could be done to make these processes more efficient. 5. DPS Routing Frame Work:- DPS Routing frame work provides overlay routing domain for routing packets that belong to non-critical applications. DPS frame work assumes the following: 1. Customer sites consist of redundant routers and redundant links. The first link (also called a primary link) will connect to Router 1 (also called a primary router) and will be used to carry traffic belonging to critical applications. Primary link will also carry all the traffic destined for sites that do not support DPS. The second link (also called a secondary link) will connect to Router 2 (also called a secondary router) and will be used to carry traffic belonging to non-critical applications. 2. DPS routing framework also assumes that BGP is enabled across the primary link and the network provider supports transport of BGP communities end to end. In order create a DPS routing framework two new interfaces/sub interfaces will be configured and their details are listed below. 1. Dynamic multipoint tunnel interface (DMVPN tunnel interface). This will be created on the secondary router. The DMVPN tunnel is a point to multipoint tunnel interface commonly used in IP Networks for creating any-to-any overlay VPNs. Source Address of the DMVPN tunnel will only be advertised via secondary link. At the primary router these source address will be Arunkumar Arumuganainar Expires April 4, 2014 [Page 12] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 filtered out. This ensures that any traffic coming out of tunnel interface will leave the local site via the secondary link and enter the destination site via its secondary link 2. In addition to the tunnel interface, one more sub-interface will be created across the back to back link between the primary and secondary router. In order to secure the normal and DPS routing domain, new virtual routing and forwarding instances (VRF) will be created on the secondary router. Both the DMVPN tunnel interface and the DPS back to back sub-interface on the secondary router will be assigned to the VRF. Routing protocols will be enabled on the newly created interface and separate routing protocol instances will be run across the DPS domain. Following peers will be established across these interfaces: 1. 1st peering will be established across DPS back to back interface between primary and secondary router. 2. 2nd peering across DMVPN hub. It should be noted that though routing information is exchanged only with DMVPN hub device, traffic flow will be always happen directly between the spokes. This capability is defined by Next Hop Resolution Protocol (NHRP # RFC 2332) and it is built in to DMVPN tunnel technology. This capability is leveraged to provide any to any communication on the DPS Frame work. Design Note:- In order to increase the availability of the DPS routing domains it is suggested to host additional DMVPN hubs. In such a case each DPS site will have two peering points via DMVPN tunnel interfaces. All the LAN routes are pushed in to the DPS domain via peering established across back to back sub interface. This is then propagated across the entire network via a DMVPN tunnel interface. VRF configured on the secondary router ensures that DPS and normal routing information do not get mixed up with each other. If the DPS routing domain is built around the above guidelines, we can ensure that the packet will leave the local site via its secondary link and enter the remote site again via the secondary link. The above design assumes two routers being used. However the design could be a single router, two circuits scenario as well. In such a case, there is no need for the DPS back to back sub-interface. The rest of details remain the same for the single router scenario. Arunkumar Arumuganainar Expires April 4, 2014 [Page 13] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 6. DPS Fault-detection mechanism As with any networks, faults can happen in a DPS routing domain. DPS by design has got several single points of failure. However DPS has been equipped with sound fault detection and recovery mechanisms. Fault detection and recovery mechanisms will dynamically allow a given router to detect faults that might have happened anywhere (local and remote faults ) on the DPS domain. Once the fault is detected the packet is ejected out of the DPS domain and pushed on to the normal routing domain. Fault detection in enabled through dynamic routing information exchanged via a routing protocol. A fault can happen any where within the site such as: 1. Secondary link could have failed. 2. Back to back link connecting primary and secondary router could have failed. 3. LAN interface on the primary router could have failed. All of the above failures will result in routing information being withdrawn from the routing table. If a route for a given DPS capable site is not present in the DPS routing table then it is considered a fault. To enable fault recovery, DPS uses a default static route to push the traffic out of the DPS domain and in to the normal routing domain. During the event default route is used inside the routing domain, we will have to use one or more summary route that encompasses all the LAN routes used with in the network instead of default static routes. This will enable DPS to push the traffic in to the DMVPN tunnel if a more specific route is available. In case a more specific route is not available (this might happen due to local or remote fault) it will use default static route to pop out of DPS domain and back out to the primary router and route via the normal routing domain. 8. Implementation Details. This architecture has been developed using exiting features available in Cisco IOS. Details are given below. 1) DPS Signaling :- QPPB 2) Profile based Filter :- PBR and Extended ACL 3) Routing Framework :- OSPF, DMPVN and VRF Arunkumar Arumuganainar Expires April 4, 2014 [Page 14] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 4) Fault Recovery :- Static Routing All the components are put to gather as described in previous sections and has been thoroughly tested in labs and also implemented in the field. Current implementations are done using Cisco routers and IOS version 15.0M. OSPF has been used as routing protocol inside the DPS domain and it has been tweaked so that it scales well in large deployments. During lab testing, we were able to scale well using this architecture where it was tested up to 500 sites with 5000 prefixes. In the production environment, several implementations were done with largest one consisting of 300 sites & 2000 prefixes. Following are the challenges that we faced during this implementation. Some of them will require additional development effort: 1. Lack of trust based QoS model. This restriction is particularly important in converged environment where voice and data shares the same infrastructure space. Here customers wanted their providers to support trust based markings. Due to reliance of IP precedence based coloring for identifying DPS capabilities trust model could not be supported. 2. Matching using Extended ACLs based on IP Precedence inside the PBR was also a challenge. All hardware switching based platforms such as Cisco's Catalyst platforms failed during lab testing. However software switching based platforms such as Cisco's ISRs performed really well both in lab and also in the production environment. 3. PBR based filters had severe restriction on throughput of software based routing platform. Additional development work is required to accomplish light weight profile based filters. To a greater extent, large scale implementation is possible in the present form with out any modifications on any networking hardware that supports the above mentioned features (eg: Cisco IOS). However, with little bit of development effort, we will be able to overcome some of the shortcomings as well. These are listed below 1) Lack of support for trust model has been a major drawback in the current architecture. Though QPPB can mark, QOS-GROUP field, it can not be matched inside a PBR. IOS in its current form only allows classification based on QoS-Group only on output policy. If support can be added for matching QOS-Group inside a PBR then we can do the coloring based on QoS-Group instead of IP Precedence. Hence trust model can be easily supported. 2) PBR is currently used for Profile based filtering. however through put of the device is very much limited when this feature is turned Arunkumar Arumuganainar Expires April 4, 2014 [Page 15] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 on. Since filtering is only done on IP Precedence and Application port-number, special filters could be developed to speed up this operations. This could improve the performance of the application even better. 7. Summary By summarizing all the four components, true end to end application based routing scheme could be achieved. Such DPS frame work has the following advantages: 1. Give lots of room for Network Manager to determine which path should be used for which application. 2. This is very scalable framework. 3. Trouble shooting the setup is easy and simple since it is based on simple routing. 4. DPS capable sites can co-exists with non DPS sites and this capability provides enough room for phased migration. Hence DPS technology adoption is easy and simple. 5. It should be noted that DPS frame work and signaling, needs to be understood only by edge devices and all the devices in middle such as provider routers need not be aware of DPS. 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 4, 2014 [Page 16] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 8 Security Considerations TBD 9 IANA Considerations TBD 10 References 10.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1 1996. 10.2 Informative References [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. 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 Arunkumar Arumuganainar Expires April 4, 2014 [Page 17] INTERNET DRAFTDynamic Path Selection Based on ApplicationOctober 01, 2013 London EC4M 7AN United Kingdom EMail: arun.arumuganainar@tatacommunications.com Arunkumar Arumuganainar Expires April 4, 2014 [Page 18]