idnits 2.17.1 draft-arumuganainar-rtgwg-dps-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '...rmation and a...' == Line 287 has weird spacing: '...routing will ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2, 2014) is 3494 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 132 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Arunkumar Arumuga Nainar 3 Intended Status: Informational draft Tata Communications Ltd 4 Expires: April 5, 2014 October 2, 2014 6 Dynamic Path Selection Requirements 7 draft-arumuganainar-rtgwg-dps-requirements-01 9 Abstract 11 The high availability puzzle can be resolved by building in 12 resiliency to network designs. Whilst active/backup routing schemes 13 are sufficient to create redundancy with low convergence times the 14 following deficiencies and customer demands are not addressed 15 comprehensively. 17 1. IP routing is essentially best path based. This will lead to 18 underutilized or over utilized links. 20 2. WAN application performance could be adversely impacted due to 21 congestion whilst the backup link remains idle. Techniques such as 22 DiffServ QoS do address the problem effectively, but those approaches 23 address only the symptoms and not the root cause. 25 3. Half of the network resources that the end customer has paid for, 26 always remains unused. This is a matter of huge concern for small and 27 mid-size customers as WAN circuit costs are very high and recurring. 29 Hence there is genuine requirement to offload some of the traffic to 30 an alternate path while the primary path is still active and running. 31 This document defines this requirement in detail. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Basic assumption . . . . . . . . . . . . . . . . . . . . . . . 3 74 3.Problem statement :- . . . . . . . . . . . . . . . . . . . . . . 5 75 4. DPS Routing Requirements . . . . . . . . . . . . . . . . . . . 5 76 5. Dynamic Path selection Framework . . . . . . . . . . . . . . . 7 77 6. Packet flow in DPS Environment . . . . . . . . . . . . . . . . 10 78 8. Implementation Details and Gap Analysis. . . . . . . . . . . . 10 79 8.1 DPS Routing domain:- . . . . . . . . . . . . . . . . . . . . 10 80 8.2 DPS Signaling:- . . . . . . . . . . . . . . . . . . . . . . 12 81 8.3 Profile based Filter . . . . . . . . . . . . . . . . . . . . 13 82 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 84 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 85 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 87 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1 Introduction 92 In a large enterprise environment, network locations are often 93 distributed over large geographical areas (often it spans different 94 countries and continents). In such a case enterprise network managers 95 often buy virtual private networks from service providers. Such a 96 network is built over either MPLS or Internet/IPSEC extension to MPLS 97 networks. 99 Generally the enterprise end user location connects in to the service 100 provider using last mile connections. These last mile circuits comes 101 in various technology options and bandwidth capacities. While the 102 service provider core is very resilient and virtually has infinite 103 capacity in terms of bandwidth, the weak link in the enterprise 104 network is indeed the last mile. 106 Last miles are the costliest component for the enterprise and most of 107 the times it contributes to 50-60% of total network costs. Yet these 108 are the weakest link in the network. They constitute single point of 109 failures and do fail frequently. Hence in order to increase the 110 network availability the network managers buy redundant links. 112 With redundant links in place, the availability puzzle is fully 113 resolved, however, it does pose a significant question. Half of the 114 costliest resource that they have purchased will remain idle through 115 out the life of this network. This happens while network managers 116 work over time to resolve the issues that arise out of congestion on 117 the primary circuit. 119 There is a genuine need to identify few select application and off 120 load them on to a path that is considered to be the best path by the 121 routing protocols. This draft defines and documents this requirement. 122 This draft also describes the high level framework based on which 123 such application off loading could be accomplished. The scope of 124 draft also includes the evaluation of the existing techniques and 125 their gap analysis. 127 1.1 Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Basic assumption 135 This draft addresses a problem faced in an enterprise network. 136 Typical enterprises comprise of collection of sites/Local Area 137 Networks (LANs) that are spread across a large geographical area 138 (across cities, countries and continents). These sites are 139 interconnected via a virtual private network of some form. Such 140 enterprises typically go to single or even multiple service providers 141 to establish this connectivity. 143 In such a case, the service provider will interconnect the site at 144 their POP location via a last mile circuit. The choice of last mile 145 technology could be diverse such as Ethernet, Frame-Relay, ATM, DSL, 146 T1/E1/T3/E3, etc. Bandwidth capacity also varies from location to 147 location (as low as 512 Kbps DSL to as high as 10 Gbps Ethernet). In 148 cases where VPN connectivity is not possible, the VPN network can be 149 extended in to a remote location via Internet/IPSEC technologies as 150 well. Due to the diverse nature of the connectivity option, any frame 151 work should be agonistic to technologies and choice of providers. 153 Router 1--------(POP1)------| 154 | 155 |-----Customer VPN 156 | (SP Managed Core) 157 Router 2--------(POP2)------| 159 This draft assumes availability is very important for the target 160 enterprises, hence there will be at least two last mile circuits that 161 link them to the service provider core. Again, technology and the 162 last mile provider can be chosen independently. Often enterprises 163 selects a good or premium primary circuit and cheaper option for the 164 secondary connectivity. For example 166 1) Primary: 10 Mbps Ethernet to MPLS; Secondary:- 10 Mbps Ethernet to 167 MPLS 169 2) Primary: 10 Mbps Ethernet to MPLS; secondary:- 2 MBPS E1 circuit 170 to MPLS 172 3) Primary: 1.5 Mbps T1; Secondary:- ADSL 2+ Internet/IPSEC 174 The above samples are for illustration taken from typical examples 175 found in the field. 177 Routing schemes usually designate the premium circuit option as 178 primary. Routing protocol metrics will hence be better for the link 179 and all the traffic goes over it as long as they are active. Traffic 180 shift to the secondary if the primary circuit goes down. This kind of 181 routing scheme is called classical routing or Active-passive routing 182 scheme. 184 3.Problem statement :- 186 In the classical routing scheme, all traffic goes over the primary 187 circuit. Sizing of the circuit will depend on the bandwidth 188 requirements of all the applications running on the LAN side which 189 need remote connectivity. Last mile circuits generally constitute a 190 large bulk of the wan network cost. In some networks that are 191 geographically well spread this could constitute 50-60% of total WAN 192 network costs, hence over sizing the network is not an option. 194 As an alternative, the Network Administrator could resort to Quality 195 of Service. This will ensure applications that are critical to the 196 business get enough bandwidth, but as collateral damage, applications 197 that are not so critical could be starved of the bandwidth. This 198 starvation could happen even while secondary circuit is active and 199 contains lots of unused bandwidth. 201 Key challenge here is to find a way to select certain applications 202 that are considered not-so critical for the business and off load 203 them on to secondary circuit. This would ensure applications that 204 would otherwise be starved of bandwidth in the primary circuit will 205 have lots of room in the secondary circuit. This kind of active- 206 active routing scheme will hence forth be called as DPS ( Dynamic 207 Path Selection) routing. This when achieved, will improve the overall 208 user experience for the not-so-critical applications without 209 compromising the critical applications. In majority of the situations 210 this will result in a slightly better experience for the critical 211 applications. 213 It should be noted that during the event of a primary circuit 214 failure, both critical and non-critical applications will go over the 215 secondary circuit. Hence the QoS mechanism will have to be applied 216 even on the secondary circuit so as to punish the not-so-critical 217 applications. Though this is a real problem, the occurrence of such 218 an event is very rare. SLA for a premium circuit such as Carrier or 219 Metro Ethernet could be as high as 99.5% . With this SLA in place 220 network administrators can guarantee acceptable level of performance 221 for all applications 99.5% of the time whilst for critical 222 applications the experience can be guaranteed 99.999% of times. 224 If this DPS routing can be achieved, then it will directly translate 225 in to greater user experience for users with out compromising the 226 cost that the Network managers will have to spend on the WAN 227 networks. 229 4. DPS Routing Requirements 230 The DPS requirements can be summarized in 5 simple steps. 232 1) Any two sites participating in the DPS routing, will have to agree 233 on off loading patterns. This pattern is referred to as DPS Profiles. 234 Example of a profile is illustrated below. 236 Profile 1: Critical Application: SAP, Citrix, VOIP ,Telnet; Non- 237 Critical: remaining applications 239 Profile 2: Critical Application: SAP, Citrix, VOIP, Telnet, SMTP, 240 HTTP; Non-Critical: remaining applications 242 Profile 3: Critical Application: All non-Internet traffic; Non- 243 Critical: Internet-traffic 245 If three sites wanted to participate in DPS routing, they need to 246 exchange the profile information and agree on a common profile to 247 off load. It should be possible that the first site will negotiate to 248 use profile 1 for the second site, and profile 2 with the third. The 249 underling requirement is if two sites communicate they should be able 250 to agree on a common profile. 252 2) Traffic hitting the input interface of router will have to be 253 first classified based on application. Here the application can be 254 defined as follows: 256 a) A specific known TCP port number 258 b) Combination of TCP Port and Server's IP Address 260 c) A known Layer 7 Signature 262 For example: 264 a) Traffic sent to TCP Port (80) could be classified as HTTP 265 application. 267 b) Traffic sent to TCP Port 80 and Server IP (ex: proxy server) 268 can be classified as Internet 270 c) Traffic sent to TCP Port 80 and Server IP (ex. proxy 271 server)sent to the URL www.example.com can be classified as 272 "EXAMPLE.COM APP". Here the classification was based on the Layer 273 7 Signature. 275 3) If the profile is agreed and classification is done, then the 276 participating router should be able to filter the traffic and send it 277 across available paths. 279 4) During step 2, if the traffic is pushed to the secondary circuit 280 (not the best path as per the routing protocol)it should stick with 281 the circuit end to end. For example an application that has been off 282 loaded will have to enter the remote site via the secondary circuit. 283 Return path for that flow will have to take the secondary path at 284 both locations so as to prevent asymmetric routing. 286 As the quality of the link does vary largely at any given site 287 asymmetric routing will invariably create a application performance 288 issues and hence should be avoided at all times.Hence, path symmetry 289 should be honored even during positive and negative events on the 290 network. For example if the secondary circuit fails, either locally 291 or at the remote site, it is treated as a negative event and during 292 this time path symmetry should not be compromised. 294 5. Dynamic Path selection Framework 296 +-------------+ +----------------+ 297 | DPS Routing | Fault in DPS Domain | Normal Routing | 298 | DOMAIN | --------------------> | Domain | 299 +-------------+ +----------------+ 300 ^ ^ 301 | | 302 | | 303 | | 304 ---------------- ----------------------- 305 | | 306 | | 307 +-------------+ +----------------+ 308 |Profile based|<-----|DPS Signaling | 309 | Filter | +----------------+ 310 +-------------+ 312 The objective of DPS is to achieve end-to-end application separation 313 with out introducing asymmetric routing within the network. In order 314 to ensure the above objectives, we should have a comprehensive 315 mechanism to achieve the following tasks. 317 Task 1: Any two sites participating in DPS will have to agree on a 318 common set of applications that will be off loaded to secondary path 319 (also referred to as DPS path on this draft). 321 Task 2: At the time of forwarding the packets, packet should be 322 filtered based on agreed application set. Packets should then be 323 pushed in to appropriate paths. 325 Task 3: If the packet is pushed on to a DPS path, it should always 326 use the secondary link end to end. . 328 Task 4: A comprehensive fault detection mechanism should be put in 329 place to detect the faults in the DPS domain. In such a case, the DPS 330 traffic should be re-routed via the normal routing domain. 332 To achieve the above four tasks, this draft recommends four 333 functional blocks as described in the above diagram. These functional 334 blocks are individually designed and fine tuned to achieve various 335 level of sophistication. Details of the building blocks are described 336 in the below section. 338 Normal Routing Domain: 340 This is the Active-Passive or classical routing as described in 341 section 2. Any site that is not running DPS (DPS unaware), will have 342 only this module. Here, the routing protocol will configured in a 343 traditional fashion. The primary circuit will have a best metric and 344 will be preferred and the secondary will be acting as backup. 346 DPS Routing domain: 348 This will be overlay routing domain that will be built over the 349 existing Normal Routing domain. However some of the paths will not be 350 considered while building the domain. For example Primary Circuits 351 can be ignored while building the overlay domain. Alternatively 352 overlay domain can be built in such a way that it prefers secondary 353 circuit as a path with better metric and hence primarily route over 354 secondary path. 356 It is mandatory that all the LAN routes that are available on the 357 normal routing domain is fully injected in to the overlay DPS Routing 358 domain. However, in order to separate the traffic, the overlay DPS 359 Routing domain will be put into a separate VRF. Once a packet is 360 pushed in to the overlay DSP Routing domain, the Normal Routing 361 domain is never consulted, until the time the fault tolerance 362 mechanism pushes traffic out of the overlay DPS Routing domain. 364 DPS Signaling 366 One of the core objective of DPS is to avoid asymmetry while routing. 367 Hence, if a particular application is off loaded, then the remote 368 network should also off load the same application. The signaling 369 module will provide a mechanism for participating sites to 370 communicate with each other and agree about the applications that 371 need to be off loaded. 373 During the signaling, sites will exchange the Application Profiles as 374 described in section 4. Sites could be able to support more than one 375 profile, however when they communicate a common profile must be 376 chosen. For example, profiles can be defined as follows: 378 Profile 1: Critical Application: SAP, Citrix, VoIP, Telnet; Non- 379 Critical: remaining applications 381 Profile 2: Critical Application: SAP, Citrix, VoIP, Telnet, SMTP, 382 HTTP; Non-Critical: remaining applications 384 Site A & B can support both profile 1 and profile 2 Site C can 385 support profile 1 Site D can support Profile 2 387 When Site A talks to Site C, applications will be off loaded as per 388 definition of Profile 1 390 When Site A talks to Site C, applications will be off loaded as per 391 definition of Profile 2 393 When Site A talks with Site B, off loading can be done either by 394 choosing one profile or by choosing a combination of both profiles. 395 One of the profiles can be dynamically chosen based on the network 396 conditions prevailing at the time. 398 For example Site A could signal to Site B its preference for profile 399 1 when the link utilization level is very high. At all other times it 400 can prefer profile 2 when dealing with Site B. Such a constraint 401 based profile selection should be explicitly acknowledged and agreed 402 by site B. If agreement could not be reached then it will default to 403 normal routing. 405 It should be noted that the profile definition as such is static. All 406 of the application sets will have to be individually defined by the 407 network administrator. But selection of profiles as such can be 408 dynamic and it could depend on a) local or remote network conditions 409 and b) capability of the site of which the target IP address belongs 410 to. 412 Profile Based Filtering Module 414 Once off loaded applications are defined, the framework should 415 support a classification and filtering engine. Classification could 416 be done via variety of application signatures. For example an 417 application signature can be defined as: 419 1) specific TCP port or an Server IP address 421 2) A combination of TCP port and IP Address 423 3) A Layer 7 Signature (eg: specific URL like http://www.example.com) 425 The profile based filter should be able to classify the packets and 426 then push the off loaded application traffic in to the DPS Routing 427 domain. Other traffic should be routed normally. 429 6. Packet flow in DPS Environment 431 If a site is deployed conforming to the above specifications, the 432 following things will happen when the packet hits router. 434 1) When the packet hits the input interface, it gets classified based 435 on the Application Signature. 437 2)If signaling happens in the forwarding plane, then the Signaling 438 Module will communicate with the remote site and agree on the profile 439 that will be used. If the signaling is implemented in the control 440 plane, then the profile negotiation would have already taken place. 441 In both the scenarios, the profile information are fed in to the 442 profile filter. 444 3) Once the profile and application signature is determined, the 445 profile based filter will push the packet in to the appropriate 446 routing domain. 448 4) In the case of the packet being pushed in to the DPS Routing 449 domain, the forwarding happens based on information available in the 450 DPS Routing domain. 452 5) Failures might happen in the network and this might result in loss 453 of routing information in the DPS routing domain. In such a case the 454 DPS routing domain will push the packet out of the domain and in to 455 the Normal Routing domain. Under no circumstances should the packet 456 be dropped due to non-availability of routing information in the DPS 457 routing domain. 459 8. Implementation Details and Gap Analysis. 461 8.1 DPS Routing domain:- 462 The main constraint is that provider devices should be transparent to 463 DPS Domain routing. This adds more complexity to the design. The 464 following techniques were considered for implementation: 466 a) Multi-Topology routing: 468 Multi-Topology Routing was considered but found unsuitable for DPS 469 routing. This is because it requires dependency on providers 470 supporting the DPS Routing scheme. Also, it forces packets to be 471 marked only with two DSCP values (1 for normal routing and another 472 other for DPS routing). Some implementations mandate usage of the 473 same or similar DSCP/IP Precedence values for traffic traveling 474 through both routing domains. 476 And hence it was found that MTR as not suitable for this purpose. 478 b) A separate VPN for DPS: 480 This does work fine for the DPS Routing domain. Here we extend a 481 second sub-interface to the same POP via the secondary last mile 482 circuit. The second sub-interface could be put on a separate VPN. 484 Technically this is feasible. There few implementations in the field 485 of this type. However this is not a preferred option. Any new VPN on 486 a MPLS network will come with extra cost and most of the time, the 487 costs are prohibitively high. 489 c) Overlay VPN Using Dynamic Mesh VPN tunnels: 491 Here the overlay network is built using DMVPN (Dynamic Mesh VPN). 492 Details of DMVPN is described in detail in the draft-detienne-dmvpn. 493 There is a vendor implementation that exists today that supports a 494 multi-point overlay tunnel as described in the draft. This could be 495 used to create an overlay DPS Routing domain. A standard routing 496 protocol can be run over this overlay network. 498 This technique is the widely deployed technique used in field 499 deployments today. In the production environment, several 500 implementations were done with largest one consisting of 300 sites & 501 2000 prefixes. 503 It should be noted that the proposed draft draft-detienne-dmvpn 504 suggests that binding IPSEC encryption on to the DMVPN tunnel is 505 mandatory. DPS Routing does not require IPSEC. Current 506 implementations were all done without encryption. This draft 507 recommends the DMVPN draft to be amended so that IPSEC binding 508 requirement is de-linked from the DMVPN standard. 510 8.2 DPS Signaling:- 512 DPS signaling can be implemented in both forwarding plane and also in 513 the control plane. 515 Control plane implementations are done via BGP. Here, BGP will be 516 used as a routing protocol for the Normal Routing domain. Profile 517 information can be exchanged via standard community. For example: 519 1) Profile 1 can be represented by community 100:1 521 2) Profile 2 can be represented by community 100:2 523 If a given site supports only profile 1, it will advertise site 524 prefixes with a community 100:1. If the same site wanted to support 525 both the profiles then the prefix would be sent with both 526 communities, 100:1 and 100:2. At the remote end, the site will 527 understand the capabilities based on the communities associated with 528 the prefix. 530 For example Site 1 supports both profile 1 and profile 2 and hence it 531 advertise the prefix with community 100:1 and 100:2. But site 2 532 supports only profile 1 (100:1). The common profile between both the 533 sites is 100:1 and hence profile 1 will be used. It should noted that 534 both site 1 and site 2 with full certainty will use profile 1. Under 535 such a scenario asymmetric routing will not happen. 537 Currently this scheme has been implemented using one vendor specific 538 implementation. In the current implementation, the router will colour 539 the packet with IP Precedence values. There will be one to one 540 correspondence between the profile chosen and the IP Precedence 541 values used for colouring. Once the packet is coloured, the profile 542 based filter can applied. Filtering will involve inspecting both the 543 colouring done by the Signaling Module and the application to which 544 the packet belongs to. 546 While this works perfectly well on large scale network, a couple of 547 short comings remains. 549 1) The trust model could not be supported when DPS is enabled. This 550 is because the DPS Signaling Module will remark the TOS bits during 551 the colouring operation. Hence an alternate mechanism needs to 552 developed to color the packet with out modifying the TOS bits. 554 2)Because profiles are exchanged via BGP, the router negotiates the 555 off loaded applications list at the time of exchanging the BGP 556 routing information. This would mean routers will not be able to 557 react to local or remote network condition. For example, the choice 558 of profiles can not be changes if the link utilization is very high. 559 The draft draft-arumuganainar-rtgwg-DPS-L4-path-preference- 560 negotiation-00 suggests an alternate mechanism that will allow 561 profile negotiation to happen when the TCP connection gets 562 established. This will enable link preference to be negotiated for 563 each TCP connection and hence such a mechanism will be more dynamic 564 then the BGP one 566 8.3 Profile based Filter 568 Each profile is associated with a pre-determined list of 569 applications. These applications are determined by the network 570 administrator as an application that can be offloaded. 572 The administrator can define multiple profiles and associate this 573 with one or more sites. When two sites communicate, they signal each 574 other and agree on a single common profile. The Signaling Module will 575 then colour the packet indicating which profile to be used while 576 deciding the application to be off loaded. 578 Once the steps are complete, the profile based filter can be applied. 579 The filter will look for the colour and then matches the protocol 580 with corresponding off loaded application. If a match is found the 581 packet will be pushed in to the DPS Routing domain, otherwise the 582 packet will be normally routed. 584 Current implementations are done using Policy Based Routing (PBR). 585 Here, filtering is done using a special PBR policy. This will check 586 the colour of the packet and the pre-determined list of applications. 587 It could then push the packet in to the appropriate routing domain. 589 While in theory PBR works perfectly fine, PBR is a processor 590 intensive mechanism and hence when it is applied, the throughput of 591 the router is adversely impacted. Hence, router scalability should be 592 kept in mind while sizing the router for any particular site. In the 593 future a light weight mechanism optimised for profile based filtering 594 could be developed as well. 596 7. Summary 598 To summarise, by adopting the DPS frame work, true end to end 599 application based routing scheme could be achieved. The DPS framework 600 has the following advantages: 602 1. Give lots of room for Network Manager to determine which path 603 should be used for which application. 605 2. DPS also provides a scalable frame work for achieving the above 606 objective. 608 3. By modularizing the DPS components, advanced development of 609 individual components becomes possible. Troubleshooting will also 610 get greatly simplified. 612 4. DPS capable sites can co-exist with non-DPS sites and this 613 capability provides enough room for a phased migration. Thus DPS 614 technology adoption is easy and simple. 616 5. It should be noted that DPS frame work and signaling, needs to 617 be understood only by edge devices and any other devices in the 618 path such as provider routers need not be aware of DPS. 620 Definitions and code { 621 line 1 622 line 2 623 } 625 Special characters examples: 627 The characters , , , 628 However, the characters \0, \&, \%, \" are displayed. 630 .ti 0 is displayed in text instead of used as a directive. 631 .\" is displayed in document instead of being treated as a comment 633 C:\dir\subdir\file.ext Shows inclusion of backslash "\". 635 8 Security Considerations 637 TBD 639 9 IANA Considerations 641 TBD 643 10 References 645 10.1 Normative References 647 10.2 Informative References 649 11 Acknowledgements 651 The authors would like to thank Hesham Moussa for his review and 652 comments. 654 Authors' Addresses 656 Arunkumar Arumuga Nainar 657 Tata Communications (UK) Limited 658 1st Floor 659 20 Old Bailey 660 London EC4M 7AN 661 United Kingdom 663 EMail: arun.arumuganainar@tatacommunications.com