idnits 2.17.1
draft-leedhody-pce-vn-association-02.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 (March 13, 2017) is 2600 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)
== Outdated reference: A later version (-15) exists of
draft-ietf-teas-actn-framework-04
== Outdated reference: A later version (-18) exists of
draft-ietf-pce-pceps-11
== Outdated reference: A later version (-23) exists of
draft-ietf-pce-pcep-yang-02
Summary: 0 errors (**), 0 flaws (~~), 4 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: September 14, 2017 Huawei Technologies
6 D. Ceccarelli
7 Ericsson
8 March 13, 2017
10 PCEP Extensions for Establishing Relationships Between Sets of LSPs
11 and Virtual Networks
12 draft-leedhody-pce-vn-association-02
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 September 14, 2017.
46 Copyright Notice
48 Copyright (c) 2017 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 [RFC8051] describes general considerations for a stateful PCE
87 deployment and examines its applicability and benefits, as well as
88 its challenges and limitations through a number of use cases.
89 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
90 provide stateful control. A stateful PCE has access to not only the
91 information carried by the network's Interior Gateway Protocol (IGP),
92 but also the set of active paths and their reserved resources for its
93 computations. The additional state allows the PCE to compute
94 constrained paths while considering individual LSPs and their
95 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. In this text child PCE would be
121 same as PNC, and the parent PCE as MDSC[ACTN-FWK].
123 This document specifies a PCEP extension to associate a set of LSPs
124 based on Virtual Network (or customer).
126 1.1. Requirements Language
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in [RFC2119].
132 2. Terminology
134 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I-
135 D.ietf-pce-stateful-pce].
137 3. Operation Overview
139 As per [I-D.ietf-pce-association-group], LSPs are associated with
140 other LSPs with which they interact by adding them to a common
141 association group.
143 An association group based on VN is useful for various optimizations
144 that should be applied by considering all the LSPs in the
145 association. This includes, but not limited to -
147 o Path Computation: When computing path for a LSP, the impact of
148 this LSP, on the other LSPs belonging to the same VN is useful to
149 analyze. The aim would be optimize overall VN and all LSPs, rather
150 than a single LSP. Also, the optimization criteria such as
151 minimize the load of the most loaded link (MLL) [RFC5541] and
152 other could be applied for all the LSP belonging to the same VN,
153 identified by the VN association.
155 o Path Re-Optimization: The child PCE or the parent PCE would like
156 to use advanced path computation algorithm and optimization
157 technique that consider all the LSPs belonging to a VN/customer
158 and optimize them all together.
160 This association is useful in PCEP session between parent PCE
161 (MDSC) and child PCE (PNC).
163 ******
164 ..........*MDSC*..............................
165 . ****** .. MPI .
166 . . . PCEP .
167 . . . PCInitiate LSPx .
168 . . . with VNAG = 10 .
169 . . . .
170 . . . .
171 . . . .
172 v v v .
173 ****** ****** ****** .
174 *PNC1* *PNC2* *PNC4* .
175 ****** ****** ****** .
176 +---------------+ +---------------+ +---------------+ .
177 |A |----| |----| C| .
178 | | | | | | .
179 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
180 +------------B13+ +---------------+ +B43------------+ .
181 / .
182 ****** / .
183 *PNC3*<............/.....................
184 ****** /
185 +---------------+/
186 B31 B34
187 | |
188 |DOMAIN 3 B|
189 +---------------+
191 MDSC -> Parent PCE
192 PNC -> Child PCE
193 MPI -> PCEP
195 In this draft, this grouping is used to define associations between a
196 set of LSPs and a virtual network.
198 One new optional Association Object-type is defined based on the
199 generic Association object -
201 o VN Association Group (VNAG)
203 Thus this document define one new association type called "VN
204 Association Type" of value TBD1. The scope and handling of VNAG
205 identifier is similar to the generic association identifier defined
206 in [I-D.ietf-pce-association-group].
208 Local polices on the PCE MAY define the computational and
209 optimization behavior for the LSPs in the VN. An LSP MUST belong to a
210 single VNAG. If an implementation encounters more than one VNAG, it
211 MUST consider the first occurrence and ignore the others.
213 4. Extensions to PCEP
215 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object,
216 the format of VNAG is as follows:
218 0 1 2 3
219 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
220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
221 | Reserved | Flags |R|
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
223 | Association type=TBD1 | Association ID |
224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
225 | IPv4 Association Source |
226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
227 // Optional TLVs //
228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230 0 1 2 3
231 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
232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
233 | Reserved | Flags |R|
234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
235 | Association type=TBD1 | Association ID |
236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
237 | |
238 | IPv6 Association Source |
239 | |
240 | |
241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242 // Optional TLVs //
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245 Figure 1: The VNAG Object formats
247 Please refer to [I-D.ietf-pce-association-group] for the definition
248 of each field in Figure 1. This document defines one mandatory TLV
249 "VIRTUAL-NETWORK-TLV" and one optional TLV "VENDOR-INFORMATION-TLV" -
251 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.
252 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
253 specific behavioral information, described in [RFC7470].
255 The format of VIRTUAL-NETWORK-TLV is as follows.
257 0 1 2 3
258 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
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 | Type=TBD2 | Length (variable) |
261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
262 | |
263 // Virtual Network Name //
264 | |
265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
267 Figure 2: The VIRTUAL-NETWORK-TLV formats
269 Type: TBD2 (to be allocated by IANA)
271 Length: Variable Length
273 Virtual Network Name(variable): symbolic name for the VN.
275 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP
276 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
277 MUST send a PCErr message with Error-Type= 6 (mandatory object
278 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
279 the session.
281 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
283 5. Applicability to H-PCE architecture
285 The ability to compute shortest constrained TE LSPs in Multiprotocol
286 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
287 multiple domains has been identified as a key motivation for PCE
288 development. [RFC6805] describes a Hierarchical PCE (H-PCE)
289 architecture which can be used for computing end-to-end paths for
290 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched
291 Paths (LSPs). Within the hierarchical PCE architecture, the parent
292 PCE is used to compute a multi-domain path based on the domain
293 connectivity information. A child PCE may be responsible for a
294 single domain or multiple domains, it is used to compute the intra-
295 domain path based on its domain topology information.
297 [I-D.dhodylee-pce-stateful-hpce] introduces general considerations
298 for stateful PCE(s) in hierarchical PCE architecture. In particular,
299 the behavior changes and additions to the existing stateful PCE
300 mechanisms in the context of a H-PCE architecture.
302 In Stateful H-PCE architecture, the Parent PCE receives a virtual
303 network creation request by its client over its Northbound API. This
304 VN is uniquely identified by an Association ID in VNAG as well as the
305 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the
306 network in a single domain or across multiple domains.
308 As the Parent PCE computes the optimum E2E paths for each tunnel in
309 VN, it MUST associate each LSP with the VN to which it belongs.
310 Parent PCE sends a PCInitiate Message with this association
311 information in the VNAG Object (See Section 4 for details). This in
312 effect binds an LSP that is to be instantiated at the child PCE with
313 the VN.
315 Whenever changes occur with the instantiated LSP in a domain network,
316 the domain child PCE reports the changes using a PCRpt Message in
317 which the VNAG Object indicates the relationship between the LSP and
318 the VN.
320 Whenever an update occurs with VNs in the Parent PCE (via the
321 client's request), the parent PCE sends an PCUpd Message to inform
322 each affected child PCE of this change.
324 The Child PCE could then use this association to optimize all LSPs
325 belonging to the same VN association together. The Child PCE could
326 further take VN specific actions on the LSPs such as relaxation of
327 constraints, policy actions, setting default behavior etc. The parent
328 PCE could also maintain all E2E LSP or per-domain path segments under
329 a single VN association.
331 6. Security Considerations
333 This document defines one new type for association, which do not add
334 any new security concerns beyond those discussed in [RFC5440], [I-
335 D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in
336 itself.
338 Some deployments may find VN associations and their implications as
339 extra sensitive and thus should employ suitable PCEP security
340 mechanisms like TCP-AO or [I-D.ietf-pce-pceps].
342 7. IANA Considerations
344 7.1. Association Object Type Indicator
346 This document defines the following new association type originally
347 defined in [I-D.ietf-pce-association-group].
349 Value Name Reference
350 TBD1 VN Association Type [This I.D.]
352 7.2. PCEP TLV Type Indicator
354 This document defines the following new PCEP TLV; IANA is requested
355 to make the following allocations from this registry at
356 ; see PCEP TLV Type
357 Indicators.
359 Value Name Reference
361 TBD2 VIRTUAL-NETWORK-TLV [This I.D.]
363 7.3. PCEP Error
365 IANA is requested to make the following allocations from this
366 registry at ; see PCEP-ERROR
367 Object Error Types and Values.
369 This document defines new Error-Type and Error-Value for the
370 following new error conditions:
372 Error-Type Meaning
374 6 Mandatory Object missing
376 Error-value=TBD3: VIRTUAL-NETWORK TLV missing
378 8. Manageability Considerations
380 8.1. Control of Function and Policy
382 An operator MUST BE allowed to mark LSPs that belong to the same VN.
383 This could also be done automatically based on the VN configuration.
385 8.2. Information and Data Models
387 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
388 association between LSPs including VN association.
390 8.3. Liveness Detection and Monitoring
392 Mechanisms defined in this document do not imply any new liveness
393 detection and monitoring requirements in addition to those already
394 listed in [RFC5440].
396 8.4. Verify Correct Operations
398 Mechanisms defined in this document do not imply any new operation
399 verification requirements in addition to those already listed in
400 [RFC5440].
402 8.5. Requirements On Other Protocols
404 Mechanisms defined in this document do not imply any new requirements
405 on other protocols.
407 8.6. Impact On Network Operations
409 Mechanisms defined in this document do not have any impact on network
410 operations in addition to those already listed in [RFC5440].
412 9. References
414 9.1. Normative References
416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
417 Requirement Levels", BCP 14, RFC 2119, DOI
418 10.17487/RFC2119, March 1997.
420 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
421 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
422 March 2009.
424 [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R.
425 Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-
426 stateful-pce, work in progress.
428 [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP Extensions
429 for PCE-initiated LSP Setup in a Stateful PCE Model",
430 draft-ietf-pce-pce-initiated-lsp, work in progress.
432 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for
433 Establishing Relationships Between Sets of LSPs", draft-
434 ietf-pce-association-group, work in progress.
436 9.2. Informative References
438 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
439 Element (PCE)-Based Architecture", RFC 4655, August 2006.
441 [RFC6805] A. Farrel and D. King, "The Application of the Path
442 Computation Element Architecture to the Determination of a
443 Sequence of Domains in MPLS and GMPLS", RFC 6805, November
444 2012.
446 [I-D.dhody-pce-applicability-actn] Dhody D., Lee Y., and D.
447 Ceccarelli, "Applicability of Path Computation Element
448 (PCE) for Abstraction and Control of TE Networks (ACTN)",
449 draft-dhody-pce-applicability-actn, work-in-progress.
451 [I-D.dhodylee-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical
452 Stateful Path Computation Element (PCE)",
453 draft-dhodylee-pce-stateful-hpce, work in progress.
455 [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D.
456 Ceccarelli, "Requirements for Abstraction and Control of TE
457 Networks", draft-ietf-teas-actn-requirements, work in
458 progress.
460 [ACTN-FWK] Ceccarelli D. and Y. Lee, "Framework for Abstraction and
461 Control of Transport Networks", draft-ietf-teas-
462 actn-framework-04 (work in progress), February 2017.
464 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
465 Objective Functions in the Path Computation Element
466 Communication Protocol (PCEP)", RFC 5541,
467 DOI 10.17487/RFC5541, June 2009,
468 .
470 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
471 Constraints in the Path Computation Element Communication
472 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
473 .
475 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
476 Stateful Path Computation Element (PCE)", RFC 8051,
477 DOI 10.17487/RFC8051, January 2017,
478 .
480 [I-D.ietf-pce-pceps]
481 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
482 Transport for PCEP", draft-ietf-pce-pceps-11 (work in
483 progress), January 2017.
485 [I-D.ietf-pce-pcep-yang]
486 Dhody, D., Hardwick, J., Beeram, V., and j.
487 jefftant@gmail.com, "A YANG Data Model for Path
488 Computation Element Communications Protocol (PCEP)",
489 draft-ietf-pce-pcep-yang-02 (work in progress), March
490 2017.
492 Author's Addresses
494 Young Lee (Editor)
495 Huawei Technologies
496 5340 Legacy Drive, Building 3
497 Plano, TX 75023,
498 USA
500 Email: leeyoung@huawei.com
502 Dhruv Dhody (Editor)
503 Huawei Technologies
504 Divyashree Technopark, Whitefield
505 Bangalore, Karnataka 560066
506 India
508 Email: dhruv.ietf@gmail.com
510 Xian Zhang
511 Huawei Technologies
512 China
514 Email: zhang.xian@huawei.com
516 Daniele Ceccarelli
517 Ericsson
518 Torshamnsgatan,48
519 Stockholm,
520 Sweden
522 Email: daniele.ceccarelli@ericsson.com