idnits 2.17.1 draft-zhangj-pce-multi-fiber-inter-domain-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 9, 2013) is 4118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5316' is mentioned on line 133, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Missing Reference: 'RFC5392' is mentioned on line 292, but not defined == Unused Reference: 'RFC3630' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC5441' is defined on line 376, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Zhang 3 Internet-Draft JJ. Wang 4 Intended status: Informational YL. Zhao 5 Expires: July 13, 2013 SG. Huang 6 Y. Bai 7 BUPT 8 ZH. Wang 9 XP. Cao 10 ZTE Corporation 11 January 9, 2013 13 PCEP extension for multi-fiber existing in inter-domain link 14 draft-zhangj-pce-multi-fiber-inter-domain-01 16 Abstract 18 Currently, most route computing algorithms only compute a shortest or 19 an optimal path.The results of this computation just refer to link 20 level, without consideration of fibers. But, in real networks, the 21 link between two adjacent nodes always has multi-fibers. This 22 condition above happens more frequently especially for the gateway 23 nodes in the multi-domain network. Moreover, the number of links 24 between two adjacent domains is always more than one. From the view 25 of parent PCE, the two conditions above will be regarded as the 26 problem of multi-fibers between adjacent nodes. However, most route 27 computing algorithms always can not solve the problem of multi-fiber 28 between adjacent nodes. As a result, parent PCE can not compute the 29 route sequence with specific fibers. It brings distress and problems 30 when parent PCE computing the loose route sequence. 32 In order to solve the problems existing in real networks, an 33 efficient solution will be proposed for parent PCE facing the multi- 34 fiber between adjacent nodes. Some interface and structure will be 35 expanded in this proposal. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 13, 2013. 54 Copyright 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. PCE discovery . . . . . . . . . . . . . . . . . . . . . . 4 73 1.2. TED of parent PCE . . . . . . . . . . . . . . . . . . . . 5 74 1.3. Communication of domain connection information . . . . . . 5 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 76 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5. PCEP Protocol Extension . . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 In real networks, the link between two adjacent nodes always has 89 multi-fibers. The condition above happens more frequently in the 90 multi-domain network. Moreover, the number of links between two 91 adjacent domains is always more than one. From the view of parent 92 PCE, the two conditions above will be regarded as the problem of 93 multi-fiber between adjacent nodes. However, most route computing 94 algorithms always can not solve the problem of multi-fiber between 95 adjacent nodes. As a result, parent PCE will not compute the route 96 sequence with specific fibers. It brings distress and problems when 97 parent PCE computing the loose route sequence. 99 Most route calculating situations of multi-fiber link can be solved 100 by bundling scheme. The fiber information of one link will always be 101 bundled to inform other modules. However, there are some situations 102 that bundling scheme can not process. For instance, only the total 103 free bandwidth of the link and maximum free bandwidth of fibers in 104 this link can be described by the bundle information. It is assumed 105 that there are 10 fibers in one link and the total free bandwidth is 106 60Gb/s. The maximum free bandwidth of fibers in this link is 10Gb/ 107 s.(Actually free bandwidth of other fibers is less than 10GB/s.) For 108 example, three requests arrive at the same moment to request 10Gb/s 109 for bandwidth. With the bundling information, all the three requests 110 can be met. However, only one of the requests can be allocated with 111 10Gb/s and the other two will fail. If the detail information of 112 fibers in this link can be known completely, the three requests for 113 10Gb/s will not be accepted at the same time and the other two 114 requests will not fail. In the situation like this, the bundling 115 scheme has many shortages and the detail information of fiber need to 116 be described in some other structure. 118 As a result, we need to let the parent PCE know the detail 119 information of every fiber in the link. The parent PCE will compute 120 out the detail route sequence with fiber information. And it will 121 recover the shortage of the bundling scheme and the existing route 122 computation algorithm. 124 1.1. PCE discovery 126 The parent PCE also needs to know the inter-domain connectivity. 127 This information could be configured with suitable policy and 128 commercial rules, or could be learned from the child PCEs. 130 In order to make the parent PCE know more interconnection 131 information, the child PCE will report the identity of its neighbor 132 domains. The IGP in each neighbor domain can advertise its inter- 133 domain TE link capabilities [RFC5316], [RFC5392]. This information 134 can be collected by the child PCEs and forwarded to the parent PCE, 135 or the parent PCE could participate in the IGP in the child domains. 137 1.2. TED of parent PCE 139 The parent PCE maintains a domain topology map of the child domains 140 and their interconnectivity. Where inter-domain connectivity is 141 provided by TE links, the capabilities of those links may also be 142 known to the parent PCE. The parent PCE maintains a traffic 143 engineering database (TED) for the parent domain in the same way that 144 any PCE does. 146 The mechanism for building the parent TED is likely to rely heavily 147 on administrative configuration and commercial issues because the 148 network was probably partitioned into domains specifically to address 149 these issues. 151 In practice, certain information may be passed from the child domains 152 to the parent PCE to help build the parent TED. It is much more 153 likely that a suitable solution will involve specific communication 154 from an entity in the child domain (such as the child PCE) to convey 155 the necessary information. 157 1.3. Communication of domain connection information 159 The parent PCE needs a parent TED and it indicates that the 160 information might be supplied from the child PCEs in each domain. 161 This requires a mechanism whereby information about inter-domain 162 links can be supplied by a child PCE to a parent PCE, for example on 163 a PCEP Notify (PCNtf) message. 165 The information that would be exchanged includes: 167 o Identifier of advertising child PCE 169 o Identifier of PCE's domain 171 o Identifier of the link 173 o TE properties of the link (metrics, bandwidth) 175 o Other properties of the link (technology-specific) 177 o Identifier of link end-points 179 o Identifier of adjacent domain 181 It may be desirable for this information to be periodically updated, 182 for example, when available bandwidth changes. In this case, the 183 parent PCE might be given the ability to configure thresholds in the 184 child PCE to prevent flapping of information. 186 2. Conventions Used in This Document 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 3. Terminologies 194 PCE (Path Computation Element): an entity (component, application or 195 network node) that is capable of computing a network path or route 196 based on a network graph and applying computational constraints. 198 4. Procedure 200 Firstly, parent PCE needs to discover the child PCEs to build the 201 topology from parent PCE's eye. This needs the child PCEs to report 202 the inter-domain link information to parent PCE. Parent PCE builds 203 its TED just like the child PCE does. The child PCEs report the 204 inter-domain link information to parent PCE with the notification 205 message. When all the reported information are collected, parent PCE 206 will get the topology between child PCEs. When there are more than 207 one inter-domain links between two adjacent domains or more than one 208 fibers between two adjacent gateway nodes, parent PCE will get the 209 topology of child PCEs with the feature of multi-fiber between 210 adjacent nodes. 212 Until now most route computation algorithms are not supporting the 213 condition that there are multi-fiber between adjacent nodes. 214 However, a solution with increasing the fake nodes can fulfill the 215 task. The introduction of the solution follows: 217 The solution to solve the route computation with multi-fiber between 218 adjacent nodes: 220 First, we need to record the information of original topology for a 221 backup. Then, if there are n original edges between two nodes, we 222 increase a fake node in each of n-1 edges except the least weight 223 edge. This will divided the original edge into two sub-segments. 224 Per sub-segment will become a new edge and its weight will become the 225 half value of the original edge's. Based on the information of new 226 topology just formed, we compute the route sequence between source 227 node and destination node with the original algorithm. The 228 calculated route sequences must be checked to make sure that the new 229 edge and fake node will be restored to the original edge. 231 Thus, the different fibers of every link can be distinguished. 232 Moreover, the original algorithm can be used to compute route 233 sequences where the multi-fiber between adjacent nodes exists. The 234 problem of computing route sequences with multi-fiber between 235 adjacent nodes can be solved well. 237 The information of inter-domain link must be extended to the 238 granularity of fiber. Based on the computing proposal of multi-fiber 239 between nodes, the parent PCE can compute out the detail inter-domain 240 loose route. The proposal can provide the solution of the 241 computation of multi-fiber between adjacent nodes which can not be 242 completed before. This also can help the process of resource 243 reservation. 245 The proposal can solve the loose route sequences with inter-domain 246 multi-fiber between adjacent gateway nodes for parent PCE well. 247 However, the information of every fiber of inter-domain link must be 248 collected by the parent PCE. As a result, the structure of inter- 249 domain link used to fulfill the communication between parent PCE and 250 child PCE must be extended to adjust the new efficient proposal. 252 5. PCEP Protocol Extension 254 In hierarchy PCE protocol, NOIFICATION message is used to communicate 255 with parent PCE and child PCE. The format of NOTIFICATION is as 256 follows: 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Reserved | Flags | NT | NV | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 // Optional TLVs // 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The related TLV for inter-domain information is inter-domain link 268 TLV. 270 IGP in each neighbor domain can advertise its inter-domain TE link 271 capabilities. This information can be collected by the child PCEs 272 and forwarded to the parent PCE. PCEP Inter-domain Link TLV is used 273 for carrying the inter-domain TE link attributes for this purpose. 274 Each Inter-domain Link TLV can carry the attributes of one inter- 275 domain link at the most. 277 The length of inter-domain Link TLV is variable. The format of this 278 TLV is defined below: 280 0 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Advertise Router ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 // sub-TLVs // 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Advertise Router ID (32 bits): indicates the router ID which 290 advertises the TE LSA or LSP. 292 Sub-TLVs: the OSPF sub-TLVs for a TE link which defined in [RFC5392] 293 and other associated OSPF RFCs. It is noted that if the IGP is IS-IS 294 for the child domain the sub-TLVs must be converted to the OSPF sub- 295 TLVs format when sending this information to the parent PCE through 296 PCEP PCNtf message. 298 A new type of sub-TLV will be extended in this document in order to 299 store the fiber information of every link which includes the number 300 of fiber, wavelength information, source IP, destination IP and so 301 on. 303 The new sub-TLV consists of a header and sub-sub-TLV set. The header 304 includes the type of this sub-TLV, the number of fiber in this link, 305 the source IP of this link, the destination IP of this link. The 306 sub-sub-TLV includes the number of the fiber, the capacity of the 307 fiber, the free bandwidth of the fiber, TE metric information. The 308 sub-sub-TLV set is formed by N sub-sub-TLVs. N is the number of 309 fibers in the link. 311 The new sub TLV is defined below: 313 0 1 2 3 314 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Source IP | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Destination IP | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Sub-sub-TLV set | 323 . . 324 . . 325 . . 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Type: the type value of this sub-TLV. 330 Length: the length of this sub-TLV. 332 Source IP: the source IP of this link. 334 Destination IP: the destination IP of this link. 336 Sub-sub-TLV set: the set of N sub-sub-TLVs, N means the number of 337 fibers in this link. 339 Sub-sub-TLV is defined as follows: 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Fiber number | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Capacity | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Unreserved Bandwidth | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Wavelength Information | 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 6. IANA Considerations 356 TBD. 358 7. Security Considerations 360 TBD. 362 8. References 364 8.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 367 Requirement Levels", RFC 2119, March 1997. 369 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 370 Engineering(TE) Extensions to OSPF Version 2", RFC 3630, 371 September 2003. 373 [RFC5440] Vasseur, JP. and JL. Le Roux, "Traffic Engineering (TE) 374 Extensions to OSPF Version 2", RFC 5440, March 2009. 376 [RFC5441] Vasseur, JP. and R. Zhang, "A Backward-Recursive PCE-Based 377 Computation (BRPC) Procedure to Compute Shortest 378 Constrained Inter-Domain Traffic Engineering Label 379 Switched Paths", RFC 5441, April 2009. 381 8.2. Informative References 383 [draft-ietf-pce-brpc-09] 384 Vasseur, JP. and R. Zhang, "A Backward Recursive PCE-based 385 Computation (BRPC) Procedure To Compute Shortest 386 Constrained Inter-domain Traffic Engineering Label 387 Switched Paths", April 2008. 389 [draft-ietf-pce-hierarchy-fwk-01] 390 King, D., Farrel, A., and Q. Zhao, "The Application of the 391 Path Computation Element Architecture to the Determination 392 of a Sequence of Domains in MPLS and GMPLS", March 2012. 394 [draft-zhang-pce-hierarchy-extensions-00] 395 Zhang, F. and Q. Zhao, "Extensions to Path Computation 396 Element Communication Protocol (PCEP) for Hierarchical 397 Path Computation Elements (PCE)", April 2011. 399 [draft-zhang-pce-hierarchy-extensions-01] 400 Zhang, F. and Q. Zhao, "Extensions to Path Computation 401 Element Communication Protocol (PCEP) for Hierarchical 402 Path Computation Elements (PCE)", October 2011. 404 Authors' Addresses 406 Jie Zhang 407 BUPT 408 No.10,Xitucheng Road,Haidian District 409 Beijing 100876 410 P.R.China 412 Phone: +8613911060930 413 Email: lgr24@bupt.edu.cn 414 URI: http://www.bupt.edu.cn/ 416 Jingjing Wang 417 BUPT 418 No.10,Xitucheng Road,Haidian District 419 Beijing 100876 420 P.R.China 422 Phone: +8615901047466 423 Email: buptwjj@yahoo.cn 424 URI: http://www.bupt.edu.cn/ 426 Yongli Zhao 427 BUPT 428 No.10,Xitucheng Road,Haidian District 429 Beijing 100876 430 P.R.China 432 Phone: +8613811761857 433 Email: yonglizhao@bupt.edu.cn 434 URI: http://www.bupt.edu.cn/ 435 Shanguo Huang 436 BUPT 437 No.10,Xitucheng Road,Haidian District 438 Beijing 100876 439 P.R.China 441 Phone: +8613693578265 442 Email: shghuang@bupt.edu.cn 443 URI: http://www.bupt.edu.cn/ 445 Yun Bai 446 BUPT 447 No.10,Xitucheng Road,Haidian District 448 Beijing 100876 449 P.R.China 451 Phone: +8618810810306 452 Email: byrain@outlook.com 453 URI: http://www.bupt.edu.cn/ 455 Zhihong Wang 456 ZTE Corporation 457 No.16,Huayuan Road,Haidian District 458 Beijing 100191 459 P.R.China 461 Phone: +861061198108 462 Email: wang.zhihong@zte.com.cn 463 URI: http://www.zte.com.cn/ 465 Xuping Cao 466 ZTE Corporation 467 No.16,Huayuan Road,Haidian District 468 Beijing 100191 469 P.R.China 471 Phone: +8613070182356 472 Email: cao.xuping@zte.com.cn 473 URI: http://www.zte.com.cn/