idnits 2.17.1 draft-leedhody-pce-vn-association-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 date (October 28, 2016) is 2727 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: 'I-D.dhodylee-pce-stateful-hpce' is mentioned on line 117, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Lee 3 Internet-Draft D. Dhody 4 Intended Status: Standards track X. Zhang 5 Expires: May 1, 2017 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 October 28, 2016 10 PCEP Extensions for Establishing Relationships Between Sets of LSPs 11 and Virtual Networks 12 draft-leedhody-pce-vn-association-01 14 Abstract 16 This document describes how to extend Path Computation Element (PCE) 17 Communication Protocol (PCEP) association mechanism introduced by the 18 PCEP Association Group specification, to further associate sets of 19 LSPs with a higher-level structure such as a virtual network (VN) 20 requested by clients or applications. This extended association 21 mechanism can be used to facilitate virtual network control using PCE 22 architecture. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 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 July 25, 2016. 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 respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................2 64 1.1. Requirements Language.....................................3 65 2. Terminology....................................................4 66 3. Operation Overview.............................................4 67 4. Extensions to PCEP.............................................4 68 5. Applicability to H-PCE architecture............................6 69 6. Security Considerations........................................7 70 7. IANA Considerations............................................7 71 7.1. Association Object Type Indicator.........................7 72 7.2. PCEP TLV Type Indicator...................................8 73 7.3. PCEP Error................................................8 74 8. References.....................................................8 75 8.1. Normative References......................................8 76 8.2. Informative References....................................9 77 Author's Addresses................................................9 79 1. Introduction 81 The Path Computation Element communication Protocol (PCEP) provides 82 mechanisms for Path Computation Elements (PCEs) to perform path 83 computations in response to Path Computation Clients' (PCCs) 84 requests. 86 [I-D.ietf-pce-stateful-pce-app] describes general considerations for 87 a stateful PCE deployment and examines its applicability and 88 benefits, as well as its challenges and limitations through a number 89 of use cases. [I-D.ietf-pce-stateful-pce] describes a set of 90 extensions to PCEP to provide stateful control. A stateful PCE has 91 access to not only the information carried by the network's Interior 92 Gateway Protocol (IGP), but also the set of active paths and their 93 reserved resources for its computations. The additional state allows 94 the PCE to compute constrained paths while considering individual 95 LSPs and their interactions. 97 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 98 teardown of PCE-initiated LSPs under the stateful PCE model. 100 [I-D.ietf-pce-association-group] introduces a generic mechanism to 101 create a grouping of LSPs. This grouping can then be used to define 102 association between sets of LSPs or between a set of LSPs and a set 103 of attributes. 105 [ACTN-REQ] describes various Virtual Network (VN) operations 106 initiated by a customer/application. In this context, there is a need 107 for associating a set of LSPs with a VN "construct" to facilitate VN 108 operations in PCE architecture. This association allows the PCEs to 109 identify which LSPs belong to a certain VN. The PCE could then use 110 this association to optimize all LSPs belonging to the VN together. 111 The PCE could further take VN specific actions on the LSPs such as 112 relaxation of constraints, policy actions, setting default behavior 113 etc. 115 [I-D.dhody-pce-applicability-actn] examines the PCE and ACTN 116 architecture and describes how the PCE architecture is applicable to 117 ACTN. [RFC6805] and [I-D.dhodylee-pce-stateful-hpce] describes a 118 hierarchy of stateful PCEs with Parent PCE coordinating multi-domain 119 path computation function between Child PCE(s) and thus making it the 120 base for PCE applicability for ACTN. 122 This document specifies a PCEP extension to associate a set of LSPs 123 based on Virtual Network (or customer). 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. Terminology 133 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I- 134 D.ietf-pce-stateful-pce]. 136 3. Operation Overview 138 As per [I-D.ietf-pce-association-group], LSPs are associated with 139 other LSPs with which they interact by adding them to a common 140 association group. In this draft, this grouping is used to define 141 associations between a set of LSPs and a virtual network. 143 One new optional Association Object-type is defined based on the 144 generic Association object - 146 o VN Association Group (VNAG) 148 Thus this document define one new association type called "VN 149 Association Type" of value TBD1. The scope and handling of VNAG 150 identifier is similar to the generic association identifier defined 151 in [I-D.ietf-pce-association-group]. 153 4. Extensions to PCEP 155 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object, 156 the format of VNAG is as follows: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Reserved | Flags |R| 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Association type=TBD1 | Association ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | IPv4 Association Source | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 // Optional TLVs // 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Reserved | Flags |R| 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Association type=TBD1 | Association ID | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 | IPv6 Association Source | 179 | | 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 // Optional TLVs // 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: The VNAG Object formats 187 Please refer to [I-D.ietf-pce-association-group] for the definition 188 of each field in Figure 1. This document defines one mandatory TLV. 190 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 192 The format of VIRTUAL-NETWORK-TLV is as follows. 194 0 1 2 3 196 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type=TBD2 | Length (variable) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 // Virtual Network Name // 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: The VIRTUAL-NETWORK-TLV formats 208 Type: TBD2 (to be allocated by IANA) 210 Length: Variable Length 212 Virtual Network Name(variable): symbolic name for the VN. 214 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 215 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 216 MUST send a PCErr message with Error-Type= 6 (mandatory object 217 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 218 the session. 220 5. Applicability to H-PCE architecture 222 The ability to compute shortest constrained TE LSPs in Multiprotocol 223 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 224 multiple domains has been identified as a key motivation for PCE 225 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 226 architecture which can be used for computing end-to-end paths for 227 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 228 Paths (LSPs). Within the hierarchical PCE architecture, the parent 229 PCE is used to compute a multi-domain path based on the domain 230 connectivity information. A child PCE may be responsible for a 231 single domain or multiple domains, it is used to compute the intra- 232 domain path based on its domain topology information. 234 [I-D.ietf-dhodylee-stateful-hpce] introduces general considerations 235 for stateful PCE(s) in hierarchical PCE architecture. In particular, 236 the behavior changes and additions to the existing stateful PCE 237 mechanisms in the context of a H-PCE architecture. 239 In Stateful H-PCE architecture, the Parent PCE receives a virtual 240 network creation request by its client over its Northbound API. This 241 VN is uniquely identified by an Association ID in VNAG as well as the 242 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 243 network in a single domain or across multiple domains. 245 As the Parent PCE computes the optimum E2E paths for each tunnel in 246 VN, it MUST associate each LSP with the VN to which it belongs. 247 Parent PCE sends a PCInitiate Message with this association 248 information in the VNAG Object (See Section 4 for details). This in 249 effect binds an LSP that is to be instantiated at the child PCE with 250 the VN. 252 Whenever changes occur with the instantiated LSP in a domain network, 253 the domain child PCE reports the changes using a PCRpt Message in 254 which the VNAG Object indicates the relationship between the LSP and 255 the VN. 257 Whenever an update occurs with VNs in the Parent PCE (via the 258 client's request), the parent PCE sends an PCUpd Message to inform 259 each affected child PCE of this change. 261 The Child PCE could then use this association to optimize all LSPs 262 belonging to the same VN association together. The Child PCE could 263 further take VN specific actions on the LSPs such as relaxation of 264 constraints, policy actions, setting default behavior etc. The parent 265 PCE could also maintain all E2E LSP or per-domain path segments under 266 a single VN association. 268 6. Security Considerations 270 TDB 272 7. IANA Considerations 274 7.1. Association Object Type Indicator 276 This document defines the following new association type originally 277 defined in [I-D.ietf-pce-association-group]. 279 Value Name Reference 281 TBD1 VN Association Type [This I.D.] 283 7.2. PCEP TLV Type Indicator 285 This document defines the following new PCEP TLV; IANA is requested 286 to make the following allocations from this registry at 287 ; see PCEP TLV Type 288 Indicators. 290 Value Name Reference 292 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 294 7.3. PCEP Error 296 IANA is requested to make the following allocations from this 297 registry at ; see PCEP-ERROR 298 Object Error Types and Values. 300 This document defines new Error-Type and Error-Value for the 301 following new error conditions: 303 Error-Type Meaning 305 6 Mandatory Object missing 307 Error-value=TBD3: VIRTUAL-NETWORK TLV missing 309 8. References 311 8.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, DOI 315 10.17487/RFC2119, March 1997. 317 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 318 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 319 March 2009. 321 [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R. 322 Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- 323 stateful-pce, work in progress. 325 [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP Extensions 326 for PCE-initiated LSP Setup in a Stateful PCE Model", 327 draft-ietf-pce-pce-initiated-lsp, work in progress. 329 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 330 Establishing Relationships Between Sets of LSPs", draft- 331 ietf-pce-association-group, work in progress. 333 8.2. Informative References 335 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation 336 Element (PCE)-Based Architecture", RFC 4655, August 2006. 338 [RFC6805] A. Farrel and D. King, "The Application of the Path 339 Computation Element Architecture to the Determination of a 340 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 341 2012. 343 [I-D.ietf-pce-stateful-pce-app] Zhang, X., ED, and Minei, I., ED, 344 "Applicability of a Stateful Path Computation Element 345 (PCE)", draft-ietf-pce-stateful-pce-app, work-in-progress. 347 [I-D.dhody-pce-applicability-actn] Dhody D., Lee Y., and D. 348 Ceccarelli, "Applicability of Path Computation Element 349 (PCE) for Abstraction and Control of TE Networks (ACTN)", 350 draft-dhody-pce-applicability-actn, work-in-progress. 352 [I-D.ietf-dhodylee-stateful-hpce] Dhody, D. and Lee, Y., 353 "Hierarchical Stateful Path Computation Element (PCE)", 354 draft-dhodylee-pce-stateful-hpce, work in progress. 356 [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. 357 Ceccarelli, "Requirements for Abstraction and Control of TE 358 Networks", draft-ietf-teas-actn-requirements, work in 359 progress. 361 Author's Addresses 363 Young Lee (Editor) 364 Huawei Technologies 365 5340 Legacy Drive, Building 3 366 Plano, TX 75023, 367 USA 369 Email: leeyoung@huawei.com 370 Dhruv Dhody (Editor) 371 Huawei Technologies 372 Divyashree Technopark, Whitefield 373 Bangalore, Karnataka 560066 374 India 376 Email: dhruv.ietf@gmail.com 378 Xian Zhang 379 Huawei Technologies 380 China 382 Email: zhang.xian@huawei.com 384 Daniele Ceccarelli 385 Ericsson 386 Torshamnsgatan,48 387 Stockholm, 388 Sweden 390 Email: daniele.ceccarelli@ericsson.com