idnits 2.17.00 (12 Aug 2021) /tmp/idnits59079/draft-zhang-pce-reqs-for-tdm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (March 02, 2009) is 4821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4657' is defined on line 301, but no explicit reference was found in the text == Outdated reference: draft-ietf-pce-pcep has been published as RFC 5440 == Outdated reference: draft-ietf-pce-gmpls-aps-req has been published as RFC 7025 == Outdated reference: draft-ietf-pce-inter-layer-ext has been published as RFC 8282 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Fatai Zhang 2 Internet Draft Dan Li 3 Intended status: Informational Jianhua Gao 4 Expires: September 2009 Huawei 5 March 02, 2009 7 Requirements for PCE applied 8 in Time-Division Multiplexing (TDM) Networks 10 draft-zhang-pce-reqs-for-tdm-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 02, 2009. 35 Abstract 37 This document describes the special requirements for applying the 38 Path Computation Element (PCE) in Time-Division Multiplexing (TDM) 39 networks, including Synchronous Optical Network (SONET), Synchronous 40 Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). 42 The material presented in this document is collected here 43 for analysis. The intention is to separate this material into 44 separate documents on generic GMPLS requirements, generic 45 GMPLS extensions, and TDM-specific requirements and extensions. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction..................................................2 56 1.1. Disposition of this Document.............................3 57 2. Terminology...................................................4 58 3. PCE Applications..............................................4 59 4. Requirements..................................................5 60 4.1. Requirements when PCC Specifies the Connection Type......5 61 4.2. Requirements when PCE Determines the Connection Type.....6 62 5. Security Considerations.......................................7 63 6. IANA Considerations...........................................7 64 7. Acknowledgments...............................................7 65 8. References....................................................7 66 9. Authors' Addresses............................................8 68 1. Introduction 70 As defined in [RFC4655], a Path Computation Element (PCE) is an 71 entity that is capable of computing a network path or route based on 72 a network graph, and of applying computational constraints during the 73 computation. Any node in the network can act as a Path Computation 74 Client (PCC) and request PCE to compute a path that satisfies the set 75 of constraints. When it finishes computing, the PCE will respond with 76 the path to the PCC. The communication protocol between PCE and PCC 77 has been described in [PCEP]. 79 The main work for PCE so far has been its application in MPLS 80 networks that are already stable and mature. However, the application 81 of PCE to GMPLS in packet and non-packet networks has also been 82 considered. GMPLS has more technology-specific and generic traffic 83 engineering constraints, and some of these, for TDM networks, need 84 further extensions to PCEP. 86 First, the properties of the LSP being computed should be fed to the 87 PCE from the PCC. These properties include the switching capabilities 88 (e.g., TDM, lambda, LSC, etc.), the encoding type (e.g., SDH/Sonet, 89 Digital Wrapper, lambda, etc.), and the signaling type (e.g., VC12, 90 VC3, ODUk, etc.). This information is very important for the PCE to 91 compute a required Path. These properties are parameters are added to 92 PCEP in [PCEP-Layer]. 94 Second, the reliability of the network is very important for 95 transport networks. So the PCE should get information about required 96 level of protection for the LSP from the PCC. In TDM networks, there 97 are abundant protection types to satisfy different demand for the 98 service, for example, 1+1 protection, 1:1 protection, 1: n protection, 99 full rerouting, shared-mesh restoration, and segment recovery, etc. 100 This information is really important for PCE to compute the 101 corresponding work LSP and protection LSP correctly on operating the 102 traffic engineering database (TED). In addition, the link protection 103 also should be taken into account for PCE path computation. The 104 requirements for LSP protection type and link protection type are 105 addressed briefly in [PCE-App-Req]. 107 Third, in TDM networks (e.g., SDH/OTN networks), a client service can 108 be transmitted by various connection(s) of TDM with different 109 connection type. For example, in the SDH networks, if the client 110 service which is 100M Ethernet is required to be transported over the 111 SDH networks, the Ethernet service can be provided by a VC4 112 connection, and it can also be provided by three concatenated VC3 113 connections (Contiguous or Virtual Concatenation). So this 114 information about connection type is vital for PCE to compute the 115 correct LSP(s) to transport the service traffic. 117 The above three requirements are very important for PCE to compute 118 the desirable paths when PCE applied in the TDM networks. However, 119 the first two requirements are addressed partially in [PCEP-Layer] and 120 [PCE-App-Req], so this document focuses on the third requirement. 122 1.1. Disposition of this Document 124 The material presented in this document is collected here for 125 analysis. The intention is to separate this material into separate 126 documents as follows: 128 - Generic GMPLS requirements for PCEP will be merged into a single 129 document working with the authors of [PCE-App-Req]. 131 - A new document will be created to provide generic GMPLS 132 extensions to PCEP to address the generic requirements. 134 - This document will be reduced to contain the TDM-specific 135 requirements (If needed, we can use one document to cover the 136 TDM-specific requirements and extensions). 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. PCE Applications 146 The TDM networks are usually responsible for transmitting data for 147 the client layer. These TDM networks can provide different types of 148 connections for customer services based on different service 149 bandwidth requests. 151 The applications and the corresponding additional requirements for 152 applying PCE in TDM networks are described below. In order to 153 simplify the description, this document just discusses the scenario 154 in SDH networks as an example. The scenarios in SONET or G.709 ODUk 155 layer networks are similar. 157 +------+ +------+ +------+ 158 | | | | | | 159 A1--| N1 +------------------+ N2 | | PCE | 160 | | | | | | 161 +--+---+ +---+--+ +------+ 162 | \ | 163 | \ +------+ | 164 | | | | 165 | | N5 | | 166 | | | | 167 | +------+ \ | 168 +--+---+ \ +---+--+ 169 | | | | 170 | N4 +------------------+ N3 |--A3 171 | | | | 172 +------+ +------+ 174 Figure 1: A simple SDH network 176 Figure 1 shows a simple network topology, where N1, N2, N3, N4, and 177 N5 are all SDH switches. Assume that one Ethernet service with 100M 178 bandwidth is required from A1 to A3 over this network. The client 179 Ethernet service could be provided by a VC4 connection from N1 to N3, 180 and it could also be provided by three concatenated VC3 connections 181 (Contiguous or Virtual concatenation) from N1 to N3. 183 The type of connectivity that is required (one VC4 or three 184 concatenated VC3) needs to be specified by PCC (e.g., N1 or NMS), but 185 could also be determined by PCE automatically based on policy, 186 configuration, or network capabilities. This is related to the 187 policies which can be implemented per [RFC5394]. The next section 188 lists requirements described according to different the policies that 189 are applied. 191 4. Requirements 193 4.1. Requirements when PCC Specifies the Connection Type 195 In this case, when receiving the service request from A1 to A3 from 196 client layer, the PCC (e.g., N1) specifies the transport scheme for 197 the service based on the requested bandwidth and the transport 198 policies pre-configured, and then requests the PCE to compute the 199 corresponding path. For example, the node N1 specifies that it needs 200 three virtual concatenated VC3 connections in the Path Computation 201 Request message to the PCE. Therefore, the following information 202 should be specified by PCC in the PCReq message: 204 (1) Signal Type: Indicates the type of elementary signal that 205 constitutes the requested LSP. A lot of signal types with 206 different granularity have been defined in SONET/SDH and G.709 207 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, 208 ODU2 and ODU3 in G.709 ODUk. See [RFC4606] and [RFC4328] (Note 209 that switching capability and encoding type should also be 210 specified which are described in [PCE-App-Req]). 212 (2) Concatenation Type: In SDH/ SONET and G.709 ODUk networks, two 213 kinds of concatenation modes are defined: contiguous 214 concatenation which requires co-router for each member signal 215 and requires all the interfaces along the path to support this 216 capability, and virtual concatenation which allows diverse 217 routes for the member signals and only requires the ingress and 218 egress interfaces to support this capability. Note that for the 219 virtual concatenation, it also may specify co-routed or 220 separated-routed. See [RFC4606] and [RFC4328] about 221 Concatenation information. 223 (3) Concatenation Number: Indicates the number of signals that are 224 requested to be contiguously or virtually concatenated. Also see 225 [RFC4606] and [RFC4328]. 227 When receiving the PCReq message, PCE computes the path that 228 satisfies the set of constraints in the PCReq message. If successful, 229 the corresponding path will be returned to PCC in the PCRep message. 230 Note that the PCE should return the above information (Signal type, 231 Concatenation type, Concatenation number) in the PCRep message to 232 tell PCC how to create the corresponding connections. 234 In the case of virtual concatenation, when separate-routed paths are 235 required, it is necessary for the PCE to indicate that how many 236 member signals are needed in each route. For example, in Figure 1, if 237 the node N1 requests a virtual concatenation connection with four VC4 238 signals and these four VC4 member signals should be separated-routed, 239 the result of path computation may be two VC4 signals along the route 240 N1-N2-N3 and another two VC4 signal along the route N1-N5-N3. 242 4.2. Requirements when PCE Determines the Connection Type 244 In this case, when receiving the request for a service from A1 to A3 245 from the client layer, the PCC (e.g., N1) sends the PCReq message to 246 the PCE. The message contains the information about requested 247 bandwidth, as described in [PCEP]. 249 When receiving the PCReq message, the PCE determines the transport 250 scheme for the service based on the requested bandwidth and the pre- 251 configured transport policies, and then computes the path. If 252 successful, the information of the corresponding paths will be sent 253 to the PCC in the PCRep message. 255 In order that the PCC can set up the corresponding path, the PCE 256 should tell the PCC the transport scheme, i.e., the connection type. 257 So the PCRep message should contain the information described below: 259 (1) Signal Type: Same as described in Section 4.1. 261 (2) Concatenation Type: Same as described in Section 4.1. 263 (3) Concatenation Number: Same as described in Section 4.1. 265 In the case of virtual concatenation when separated routed paths are 266 returned, it is also necessary for the PCE to indicate that how many 267 member signals are needed in each route, which is the same as 268 described in Section 4.1. 270 5. Security Considerations 272 This document just focuses on the requirements when PCE is applied in 273 the TDM networks, so there is no additional security introduced. 274 Possible security issues should be considered when it need extend 275 PCEP to support these requirements. 277 6. IANA Considerations 279 There is no IANA request in this document. 281 7. Acknowledgments 283 TBD. 285 8. References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 291 communication Protocol (PCEP) - Version 1 -" draft-ietf- 292 pce-pcep (work in progress). 294 [PCE-App-Req] Tomohiro Otani, Kenichi Ogaki and Diego Caviglia, 295 "Requirements for GMPLS applications of PCE" draft-ietf- 296 pce-gmpls-aps-req-00 (work in progress). 298 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 299 Element (PCE)-Based Architecture", RFC 4655, September 2006. 301 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 302 Communication Protocol Generic Requirements", RFC 4657, 303 September 2006. 305 [RFC4606] E. Mannie and D. Papadimitriou, "GMPLS extensions for SONET 306 and SDH control", RFC 4606, August 2006. 308 [RFC4328] D. Papadimitriou, "GMPLS Signaling Extensions for G.709 309 Optical Transport Networks Control", RFC 4328, January 2006. 311 [RFC5394] I. Bryskin, D. Papadimitriou, L. Berger and J. Ash, 312 "Policy-Enabled Path Computation Framework", RFC 5394, 313 December 2008. 315 [PCEP-Layer] E. Oki, T. Takeda, J-L. Le Roux, and A. Farrel, 316 "Extensions to the Path Computation Element communication 317 Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic 318 Engineering", draft-ietf-pce-inter-layer-ext, work in 319 progress. 321 9. Authors' Addresses 323 Fatai Zhang 324 Huawei Technologies Co., Ltd. 325 F3-5-B R&D Center, Huawei Base 326 Bantian, Longgang District 327 Shenzhen 518129 P.R.China 329 Phone: +86-755-28972912 330 Email: Zhangfatai@huawei.com 332 Dan Li 333 Huawei Technologies Co., Ltd. 334 F3-5-B R&D Center, Huawei Base 335 Bantian, Longgang District 336 Shenzhen 518129 P.R.China 338 Phone: +86-755-28973237 339 Email: danli@huawei.com 341 Jianhua Gao 342 Huawei Technologies Co., Ltd. 343 F3-5-B R&D Center, Huawei Base 344 Bantian, Longgang District 345 Shenzhen 518129 P.R.China 347 Phone: +86-755-28972912 348 Email: gjhhit@huawei.com 350 Intellectual Property 352 The IETF Trust takes no position regarding the validity or scope of 353 any Intellectual Property Rights or other rights that might be 354 claimed to pertain to the implementation or use of the technology 355 described in any IETF Document or the extent to which any license 356 under such rights might or might not be available; nor does it 357 represent that it has made any independent effort to identify any 358 such rights. 360 Copies of Intellectual Property disclosures made to the IETF 361 Secretariat and any assurances of licenses to be made available, or 362 the result of an attempt made to obtain a general license or 363 permission for the use of such proprietary rights by implementers or 364 users of this specification can be obtained from the IETF on-line IPR 365 repository at http://www.ietf.org/ipr 367 The IETF invites any interested party to bring to its attention any 368 copyrights, patents or patent applications, or other proprietary 369 rights that may cover technology that may be required to implement 370 any standard or specification contained in an IETF Document. Please 371 address the information to the IETF at ietf-ipr@ietf.org. 373 The definitive version of an IETF Document is that published by, or 374 under the auspices of, the IETF. Versions of IETF Documents that are 375 published by third parties, including those that are translated into 376 other languages, should not be considered to be definitive versions 377 of IETF Documents. The definitive version of these Legal Provisions 378 is that published by, or under the auspices of, the IETF. Versions of 379 these Legal Provisions that are published by third parties, including 380 those that are translated into other languages, should not be 381 considered to be definitive versions of these Legal Provisions. 383 For the avoidance of doubt, each Contributor to the IETF Standards 384 Process licenses each Contribution that he or she makes as part of 385 the IETF Standards Process to the IETF Trust pursuant to the 386 provisions of RFC 5378. No language to the contrary, or terms, 387 conditions or rights that differ from or are inconsistent with the 388 rights and licenses granted under RFC 5378, shall have any effect and 389 shall be null and void, whether published or posted by such 390 Contributor, or included with or in such Contribution. 392 Disclaimer of Validity 394 All IETF Documents and the information contained therein are provided 395 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 396 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 397 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 398 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 399 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 400 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 401 FOR A PARTICULAR PURPOSE. 403 Full Copyright Statement 405 Copyright (c) 2009 IETF Trust and the persons identified as the 406 document authors. All rights reserved. 408 This document is subject to BCP 78 and the IETF Trust's Legal 409 Provisions Relating to IETF Documents in effect on the date of 410 publication of this document (http://trustee.ietf.org/license-info). 411 Please review these documents carefully, as they describe your rights 412 and restrictions with respect to this document.