idnits 2.17.1 draft-wang-teas-pce-native-ip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 112 has weird spacing: '...essions strat...' == Line 213 has weird spacing: '...large scale ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 123, but not defined == Unused Reference: 'RFC4655' is defined on line 339, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group A.Wang 2 Internet Draft China Telecom 4 Intended status: Standard Track June 30,2016 5 Expires: December 30, 2016 7 PCE in Native IP Network 8 draft-wang-teas-pce-native-ip-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may not be modified, 17 and derivative works of it may not be created, and it may not be 18 published except as an Internet-Draft. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to publish it 23 as an RFC and to translate it into languages other than English. 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on January 1, 2009. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 Abstract 60 This document defines the PCE use case and solution that can be 61 deployed within the native IP network, using Multi-BGP session 62 strategy and PCE-based central control to assure the end2end traffic 63 performance, and proposes the corresponding extension to PCEP 64 protocol to transfer the key parameters between PCE and the 65 underlying network device (PCC). 67 Table of Contents 69 1. Introduction ................................................ 2 70 2. Conventions used in this document ........................... 3 71 3. Dual-BGP solution for simple topology........................ 3 72 4. Dual-BGP in large Scale Topology ............................ 5 73 5. Multi-BGP for Extended Traffic Differentiation .............. 5 74 6. PCE based solution for Multi-BGP strategy deployment..........6 75 7. PCEP extension for key parameter transformation. ............ 8 76 8. Security Considerations ..................................... 8 77 9. IANA Considerations ......................................... 8 78 10. Conclusions ................................................ 8 79 11. References ................................................. 8 80 11.1. Normative References .................................. 8 81 11.2. Informative References................................. 9 82 12. Acknowledgments ............................................ 9 84 1. Introduction 86 Currently, PCE based traffic assurance requires the underlying network 87 devices support MPLS and the network must deploy multiple LSPs to 88 assure the end-to-end traffic performance. LDP/RSVP-TE or Segment 89 Routing should be enabled within the network to establish various MPLS 90 paths. Such solution will certainly work but the main drawback of it is 91 that all the LSP paths are divided logically, that is to say, all the 92 LSP paths that go through one physical link will share and compete the 93 same resource and MPLS technology has no better solution to meet the 94 requirements for determined QoS effect. 95 On the other hand, there are some legacy networks that does not deploy 96 the MPLS control and forward plane technology, but also need to assure 97 the QoS of application traffic. Deploy some dedicated links statically 98 to meet such requirements is one option but it is not feasible in the 99 service provider network, because the volume and path of application 100 traffic will be vary from time to time. 101 In summary, there are scenarios that the current PCE-based MPLS 102 solution can't be deployed within the network, because the following 103 user requirements: 104 1) End to End traffic assurance. 105 2) Determined Qos Effect. 106 3) No complex MPLS signaling procedure, support Native IP environment. 107 4) Flexible deployment 108 5) Central control. 110 This document defines the PCE use case and solution that can be 111 deployed within the native IP network, using PCE-based central control 112 and Multi BGP sessions strategy to assure the end2end traffic 113 performance, meet the above requirements in dynamical and central 114 control mode, proposes the corresponding extension to PCEP protocol to 115 transfer the key parameters between PCE and the underlying network 116 device(PCC). 118 2. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Dual-BGP solution for simple topology. 126 This section introduces first the dual-BGP solution for simple topology 127 that illustrated in Fig.1, which is comprised by SW1, SW2, R1, R2. 128 There are multiple physical links between R1 and R2. Traffic between 129 IP11 and IP21 are normal traffic, traffic between IP12 and IP22 are 130 priority traffic that should be treated differently. 131 There is only Native IP protocol being deployed between R1 and R2. The 132 traffic between each address pair will be changed timely and the 133 corresponding source/destination addresses of the traffic may also be 134 changed dynamically. 135 The key idea of the Dual-BGP solution for this simple topology is the 136 following: 137 1) Build two BGP sessions between R1 and R2, via the different loopback 138 address lo0,lo1 on these routers. 139 2) Send different prefixes via the two BGP sessions.(For example, 140 IP11/IP21 via the BGP pair 1 and IP12/IP22 via the BGP pair 2). 141 3) Set the static route on R1 and R2 respectively for BGP next hop of 142 lo0,lo1 to different physical link address between R1 and R2. 144 So, the traffic between the IP11 and IP12, and the traffic between IP21 145 and IP22 will go through different physical links between R1 and R2, 146 each type of traffic occupied the different dedicated physical links 147 and will not influence with each other. 149 If there is more traffic between IP12 and IP13 need to be assured, one 150 can reassign more physical links on R1 and R2 to reach the loopback 151 address lo1(also the next hop for BGP Peer pair2), the prefixed that 152 advertised by two BGP peer need not be changed. 154 If, for example, there are traffic from another address pair need to be 155 assured (for example IP13/IP23), but the total volume of assured 156 traffic does not exceed the capacity of the previous appointed physical 157 links, then one need only to advertise the newly added 158 source/destination prefixes via the BGP peer pair2, then the traffic 159 between IP13/IP23 will go through the assigned dedicated physical links 160 as the traffic between IP12/IP22. 162 Such decouple philosophy gives the network operator more flexible 163 control ability on the network traffic, get the determined QoS 164 assurance effect to meet the application's requirement. No complex MPLS 165 signal procedures is introduced, the router need only support native IP 166 protocol. 168 | | 169 | BGP Peer Pair2 | 170 +------------------+ 171 |lo1 lo1 | 172 | | 173 | BGP Peer Pair1 | 174 +------------------+ 175 IP12 |lo0 lo0 | IP22 176 IP11 | | IP21 177 SW1-------R1-----------------R2-------SW2 178 Links Group 180 Fig.1 Design Philosophy for Dual-BGP Solution 182 4. Dual-BGP in large Scale Topology 184 When the assured traffic spans across one large scale network, as that 185 illustrated in Fig.2, the dual BGP sessions cannot be established 186 neighbor by neighbor especially for the iBGP within one AS. For such 187 scenario, we should consider to use the Route Reflector (RR) to achieve 188 the similar Dual-BGP effect, that is to say, select one router which 189 performs the role of RR (for example R3 in Fig.2 - Dual-BGP Solution 190 using Route Reflector for large scale network), every other router will 191 establish two BGP sessions with the RR, using their different loopback 192 addresses respectively. The other two steps for traffic differentiation 193 are same as one described in the Dual-BGP simple topology usage case. 195 For the example shown in Fig.2, if we select the R1-R2-R4-R7 as the 196 dedicated path, then we should set the static routes on theses router 197 respectively, point the BGP next hop (loopback addresses of R1 and R7, 198 which are used to send the prefix of the assured traffic) to the actual 199 address of the physical link 201 +------------R3--------------+ 202 | | 203 SW1-------R1-------R5---------R6-------R7--------SW2 204 | | | | 205 +-------R2---------R4--------+ 206 Fig.2 Dual-BGP solution using route reflector for large scale network 208 5. Multi-BGP for Extended Traffic Differentiation 210 Discussed in the document so far, is the requirement for traffic 211 differentiation to classify traffic into two classes: Assured traffic 212 or best effort (normal) traffic. Dual-BGP solution(simple topology or 213 large scale topology) can meet above requirements. In general 214 situations, several additional traffic differentiation criteria exist, 215 including: 216 ? Traffic requires low latency links and not sensitive to packet loss 217 ? Traffic requires low packet loss but can endure higher latency 218 ? Traffic requires lowest jitter path 219 ? Traffic requires high bandwidth links 220 These varying traffic requirements may be summarized in the following 221 table: 223 +----------+-------------+---------------+-----------------+ 224 | Flow No. | Latency | Packet Loss | Jitter | 225 +----------+-------------+---------------+-----------------+ 226 | 1 | Low | Normal | Don't care | 227 +----------+-------------+---------------+-----------------+ 228 | 2 | Normal | Low | Dont't care | 229 +----------+-------------+---------------+-----------------+ 230 | 3 | Normal | Normal | Low | 231 +----------+-------------+---------------+-----------------+ 232 Table 1. Traffic Requirement Criteria 234 For Flow No.1, we can select the shortest distance path to carry the 235 traffic; for Flow No.2, we can select the idle links to form its end to 236 end path; for Flow No.3, we can let all the traffic pass one single 237 path, no ECMP distribution on the parallel links is required. 239 It is difficult and almost impossible to provide an end-to-end (E2E) 240 path with latency, latency variation, packet loss, and bandwidth 241 utilization constraints to meet the above composition requirements in 242 large scale network via the traditional distributed routing protocol, 243 but these requirements can be solved using the PCE-based architecture 244 since the PCE has the overall network view, can collect real network 245 topology and network performance information about the underlying 246 network, select the appropriate path to meet the various network 247 performance requirements of different traffic type. 249 6. PCE based solution for Multi-BGP strategy deployment. 251 With the advent of SDN concepts within IP network, it is possible to 252 deploy the PCE related technology into the underlying native IP network, 253 to accomplish the central and dynamic control of network traffic 254 according to the application's various requirements. 255 The procedure to implement the dynamic deployment of Multi-BGP strategy 256 is the following: 257 1) PCE gets underlying topology information via the BGP-LS protocol via 258 one router, such as the route reflector R3 in Fig.3 259 2) It collects also the link utilization information via the SNMP 260 protocol. 262 3) Upon the application's requirement, for example, the bi-direction 263 traffic assurance between SW1/SW2, the PCE will calculate the 264 appropriate link path, which can be assigned to such traffic in 265 dedicated mode, other normal traffic will not pass through such 266 physical links. 267 4) PCE will then send the key parameters to R1 and R7 respectively, to 268 let R1 and R7 build another i/eBGP neighbor with R3, advertise the 269 prefixes that owned by SW1/SW2. 270 5) If the calculated dedicated path is via some physical links that 271 belong to R1-R2-R4-R7, then PCE need also build the connection with 272 these on-path routers, send some key parameters to them to build the 273 path to the BGP next-hop via the address of physical links between 274 R1/R2,R2/R4,R4/R7. 275 6) If the assured traffic prefixes are changed and the total volume of 276 assured traffic is not exceed the physical capacity of the previous 277 end-to-end path, then the PCE need only change the related 278 information on R1 and R7. 279 7) If the volume of the assured traffic exceeds the capacity of previous 280 calculated path, then PCE must recalculate the appropriate path to 281 accommodate the exceeding traffic in some new end-to-end physical 282 link. It then need to send some relevant key parameters to the on- 283 path routers to build such path hop by hop. 285 +----+ 286 ***********+PCE +************* 287 * +--*-+ * 288 * / * \ * 289 * * * 290 PCEP* *BGP-LS/SNMP *PCEP 291 * * * 292 * * \ * / 293 \ * / * \ */ 294 \*/-----------R3--------------* 295 | | 296 | | 297 SW1-------R1-------R5---------R6-------R7--------SW2 298 | | | | 299 | | | | 300 +-------R2---------R4--------+ 301 Fig.3 PCE based solution for Multi-BGP deployment 303 7. PCEP extension for key parameter transformation. 305 In order to pass the key parameters to the underlying routers and keep 306 the overall implementation as simple as possible, it is appropriate to 307 extend the PCEP protocol to transfer the key parameters. 308 Based on the design philosophy of afore mentioned Multi-BGP deployment 309 scenario, the key parameters should include the following information: 310 1) BGP peer address and assured prefixes that will be advertised via 311 this BGP session 312 2) Static route information/Destination(BGP next hop) and Next Physical 313 Link Address. 315 Once the router receive such information, it should establish the BGP 316 session with the peer appointed in the PCEP message, advertises the 317 prefixes that contained in the corresponding PCEP message, and build 318 the end to end dedicated path hop by hop. 320 The detail format and the processing procedure of the above two 321 extensions will be provided in another draft. 323 8. Security Considerations 325 TBD 327 9. IANA Considerations 329 TBD 331 10. Conclusions 333 TBD 335 11. References 337 11.1. Normative References 339 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 341 Computation Element (PCE)-Based Architecture", RFC 343 4655, August 2006,. 345 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 346 Computation Element (PCE) Communication Protocol 348 (PCEP)", RFC 5440, March 2009, 350 . 352 11.2. Informative References 354 TBD 356 12. Acknowledgments 358 TBD 360 Authors' Addresses 362 Aijun Wang 363 China Telecom 364 Beiqijia Town, Changping District 365 Beijing,China 367 Email: wangaj@ctbri.com.cn