idnits 2.17.1 draft-ali-pce-remote-initiated-lsp-usage-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 3 characters 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2013) is 3833 days in the past. Is this intentional? 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: 'RFC6107' is mentioned on line 307, but not defined == Unused Reference: 'RFC 6107' is defined on line 325, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Zafar Ali 3 Internet Draft Siva Sivabalan 4 Intended status: Standard Track Clarence Filsfils 5 Expires: April 20, 2014 Cisco Systems 6 Robert Varga 7 Pantheon Technologies 8 Victor Lopez 9 Oscar Gonzalez de Dios 10 Telefonica I+D 11 Xian Zhang 12 Huawei 13 October 21, 2013 15 Path Computation Element Communication Protocol (PCEP) 16 Extensions for remote-initiated LSP Usage 17 draft-ali-pce-remote-initiated-lsp-usage-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on April 20, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) 60 controlling the copyright in such materials, this document may not 61 be modified outside the IETF Standards Process, and derivative 62 works of it may not be created outside the IETF Standards Process, 63 except to format it for publication as an RFC or to translate it 64 into languages other than English. 66 Abstract 68 When active stateful PCE is used for managing PCE-initiated LSP, 69 PCC may not be aware of the intended usage of the LSP (e.g., in a 70 multi-layer network). PCEP Extensions for PCE-initiated MPLS and 71 GMPLS LSP Setup specifications do not address this requirement. 72 This draft addresses the requirement to specify on how PCC should 73 use the remote initiated LSPs. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in RFC 2119 80 [RFC2119]. 82 Table of Contents 84 1. Introduction ..................................................3 85 2. Use Cases .....................................................3 86 2.1. Bandwidth-on-demand .......................................3 87 3. Remote Initiated LSP Usage Requirement ........................5 88 4. PCEP extension for PCEP Initiated LSP Usage Specification .....5 89 4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message ....5 90 4.2. Communicating LSP usage to Egress node ....................7 91 5. Security Considerations .......................................7 92 6. IANA Considerations ...........................................7 93 6.1. END-POINT Object ..........................................7 94 7. Acknowledgments ...............................................7 95 8. References ....................................................7 96 8.1. Normative References ......................................8 97 8.2. Informative References ....................................8 98 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 100 1. Introduction 102 [I-D. draft-crabbe-pce-pce-initiated-lsp] and [I-D. draft-ali- 103 pce-remote-initiated-gmpls-lsp] describe the setup and teardown 104 of PCE-initiated MPLS and GMPLS LSPs under the active stateful 105 PCE model, without the need for local configuration on the PCC, 106 thus allowing for a dynamic network that is centrally controlled 107 and deployed. However, when an active stateful PCE is used for 108 managing remote-initiated MPLS or GMPLS LSP, the PCC may not be 109 aware of the intended usage of the remote-initiated LSP. For 110 example, the PCC may not know the target IGP instance in which 111 the remote-initiated LSP is to be used. These requirements are 112 outlined in Section 3. 114 This draft addresses the requirement to specify on how PCC 115 should use the PCEP initiated LSPs. This is achieved by using 116 LSP_TUNNEL_INTERFACE_ID Object defined in [RFC6107] in PCEP, as 117 detailed in Section 4. PCEP extensions specified in this 118 document are equally applicable to PCEP initiated MPLS as well 119 as GMPLS LSPs. 121 2. Use Cases 123 2.1. Bandwidth-on-demand 125 This use case assumes there is a multi-layer network composed by 126 routers and optical equipment. In this scenario, there is an 127 entity, which decides it needs extra bandwidth between two 128 routers. This certain moment a GMPLS LSP connecting both routers 129 via the optical network can be established on-the-fly. This 130 entity can be a router, an active stateful PCE or even the NMS 131 (with or without human intervention). 133 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 135 [See PDF version of the document for Figures] 137 Figure 1. Bandwidth on demand use case 139 It is important to note that the bandwidth-on-demand interfaces 140 and spare bandwidth in the optical network could be shared to 141 cover many under capacity scenarios in the L3 network. For 142 example, in this use-case, if we assume all interfaces are 10G 143 and there is 10G of spare bandwidth available in the optical 144 network, the spare bandwidth in the optical network can be used 145 to connect any router, depending on bandwidth demand of the 146 router network. For example, if there are three routers, it is 147 not known a priori if the demand will make bandwidth-on-demand 148 interface at R1 to be connected to bandwidth-on-demand interface 149 at R2 or R3. For this reason, bandwidth-on-demand interfaces 150 cannot be pre-provisioned with the IP services that are expected 151 to carry. Furthermore, in this example, as active stateful PCE 152 is used for managing PCE-initiated LSP, PCC may not be aware of 153 the intended usage of the PCE-initiated LSP. Specifically, when 154 the PCE1 initiated GMPLS tunnel1, PCC does not know the IGP 155 instance whose demand leads to establishment of the GMPLS 156 tunnel1 and hence does not know the IGP instance in which the 157 GMPLS tunnel1 needs to be advertised. Similarly, the PCC does 158 not know IP address that should be assigned to the GMPLS 159 tunnel1. In the above example, this IP address is labeled as 160 TUN-IP-R1 (tunnel IP address at R1). The PCC also does not know 161 if the tunnel needs to be advertised as forwarding and/ or 162 routing adjacency and/or to be locally used by the target IGP 163 instance. Similarly, egress node for GMPLS signaling (R2 node in 164 this example) may not know the intended usage of the tunnel 165 (tunnel1 in this example). For example, the R2 node does not 166 know IP address that should be assigned to the GMPLS tunnel1. In 167 the above example, this IP address is labeled as TUN-IP-R2 168 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 170 (tunnel IP address at R2). Section 4 of this draft addresses the 171 requirement to specify on how PCC and egress node for signaling 172 should use the remote initiated LSPs. 174 3. Remote Initiated LSP Usage Requirement 176 The requirement to specify usage of the LSP to the PCC includes 177 but not limited to specification of the following information. 179 - The target IGP instance for the Remote-initiated LSP needs to 180 be specified. 182 - In the target IGP instance, should the PCE-initiated LSP be 183 advertised as a forwarding adjacency and/ or routing adjacency 184 and/ or to be used locally by the PCC? 186 - Should the as Remote-initiated LSP be advertised an IPv4 FA/ 187 RA, IPv6 FA/ RA or as unnumbered FA/ RA. 189 - If Remote-initiated LSP is to be advertised an IPv4 FA/ RA, 190 IPv6 FA/ RA, what is the local and remote IP address is to be 191 used for the advertisement. 193 4. PCEP extension for PCEP Initiated LSP Usage Specification 195 The requirement to specify on how PCC should use the PCEP 196 initiated LSPs in outlined in Section 2. This subsection 197 specifies PCEP extension used to satisfy this requirement. 199 4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message 201 [RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for 202 communicating usage of the forwarding or routing adjacency from 203 the ingress node to the egress node. This document extends the 204 LSP Initiate (PCInitiate) Message to include 205 LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object 206 class and type for the LSP_TUNNEL_INTERFACE_ID object are as 207 follows: 209 Object Name: LSP_TUNNEL_INTERFACE_ID 211 Object-Class Value: TBA by Iana (suggested value: 40) 213 Object-type: 1 215 The contents of this object are identical in encoding to the 216 contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined 217 in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE 218 LSP_TUNNEL_INTERFACE_ID object are acceptable in this object. 219 The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond 220 to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please 221 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 223 note that use of TLV type 1 defined in [RFC3477] is not 224 specified by this document. 226 TLV TLV 227 Type Description Reference 228 -- ------------------------------------------------- ---------- 229 2 IPv4 interface identifier with target IGP instance [RFC6107] 231 3 IPv6 interface identifier with target IGP instance [RFC6107] 233 4 Unnumbered interface with target IGP instance [RFC6107] 235 The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID 236 object are identical to those defined for the RSVP-TE 237 LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the 238 fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV 239 are identical to those defined for the corresponding RSVP-TE 240 LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have 241 slightly different usage. 243 - IPv4 Interface Address field in IPv4 interface identifier 244 with target IGP instance TLV: This field indicates the local 245 IPv4 address to be assigned to the tunnel at the PCC (ingress 246 node for RSVP-TE signaling). In the example use case of 247 Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is 248 carried in this field (if TUN-IP-R1 is a v4 address). 250 - IPv6 Interface Address field in IPv4 interface identifier 251 with target IGP instance TLV: This field indicates the local 252 IPv6 address to be assigned to the tunnel at the PCC (ingress 253 node for RSVP-TE signaling). 255 - LSR's Router ID field in Unnumbered interface with target IGP 256 instance: The PCC SHOULD use the LSR's Router ID in Unnumbered 257 interface with target IGP instance in advertising the LSP 258 being initiated by the PCE. 260 - Interface ID (32 bits) field in unnumbered interface with 261 target IGP instance: All bits of this field MUST be set to 0 262 by the PCE server and MUST be ignored by PCC. PCC SHOULD 263 allocate an Interface ID that fulfills Interface ID 264 requirements specified in [RFC3477]. 266 When the Ingress PCC receives an LPS Request Message with 267 LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained 268 in the TLV to drive the IGP instance, treatment of the LSP being 269 initiated in the target IGP instance (e.g., FA, RA or local 270 usage), the local IPv4 or IPv6 address or router-id for 271 unnumbered case to be used for advertisement of the LSP being 272 instantiated. 274 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 276 4.2. Communicating LSP usage to Egress node 278 PCE does not need to send LSP Initiate message to egress node to 279 communicate LSP usage information. Instead PCC (Ingres signaling 280 node) uses RSVP-TE signaling mechanism specified in [RFC6107] to 281 send the LSP usage to Egress node. Specifically, when the 282 Ingress PCC receives an LPS Request Message with 283 LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD add 284 LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For this 285 purpose, it is RECOMMENDED that the ingress PCC use content of 286 the LSP_TUNNEL_INTERFACE_ID TLV in LSP Initiate Message in PCEP 287 to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This 288 document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object 289 in RSVP-TE signaling as specified in [RFC6107]. 291 The egress node uses information contained in the 292 LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive 293 the IGP instance, treatment of the LSP being initiated in the 294 target IGP instance (e.g., FA, RA or local usage), the local 295 IPv4 or IPv6 address or router-id for unnumbered case to be used 296 for advertisement of the LSP being instantiated. 298 5. Security Considerations 300 To be added in future revision of this document. 302 6. IANA Considerations 304 6.1. END-POINT Object 306 This document extends the LSP Initiate Message to include 307 LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object 308 class and type for the LSP_TUNNEL_INTERFACE_ID object are as 309 follows: 311 Name Class value Type 312 ---- ----------- ---- 313 LSP_TUNNEL_INTERFACE_ID TBA by Iana (Suggested:40) 1 315 7. Acknowledgments 317 The authors would like to thank George Swallow and Jan Medved 318 for their comments. 320 8. References 321 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 323 8.1. Normative References 325 [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 326 for Dynamically Signaled Hierarchical Label Switched 327 Paths", RFC 6107, February 2011. 329 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 330 Links in Resource ReSerVation Protocol - Traffic 331 Engineering (RSVP-TE)", RFC 3477, January 2003. 333 [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I., 334 Sivabalan, S., Varga, R., "PCEP Extensions for PCE- 335 initiated LSP Setup in a Stateful PCE Model", draft- 336 crabbe-pce-pce-initiated-lsp, work in progress. 338 [I-D. draft-ali-pce-remote-initiated-gmpls-lsp] Z. Ali, S. 339 Sivabalan, C. Filsfils, R. Varga, V. Lopez, O. Dios, 340 X. Zhang, " Path Computation Element Communication 341 Protocol (PCEP) Extensions for remote-initiated GMPLS 342 LSP Setup", draft-ali-pce-remote-initiated-gmpls-lsp, 343 work in progress. 345 8.2. Informative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 Authors' Addresses 352 Zafar Ali 353 Cisco Systems 354 Email: zali@cisco.com 356 Siva Sivabalan 357 Cisco Systems 358 Email: msiva@cisco.com 360 Clarence Filsfils 361 Cisco Systems 362 Email: cfilsfil@cisco.com 364 Robert Varga 365 Pantheon Technologies 367 Victor Lopez 368 Telefonica I+D 369 Email: vlopez@tid.es 371 Oscar Gonzalez de Dios 372 Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 374 Telefonica I+D 375 Email: ogondio@tid.es 377 Xian Zhang 378 Huawei Technologies 379 Email: zhang.xian@huawei.com