PCE Working Group Y. Lee
Internet-Draft Futurewei
Intended Status: Standards track X. Zhang
Expires: February 22, 2020 Huawei Technologies
D. Ceccarelli
Ericsson
August 21, 2019
Path Computation Element communication Protocol (PCEP) extensions
for Establishing Relationships between sets of LSPs and Virtual
Networks
draft-ietf-pce-vn-association-00
Abstract
This document describes how to extend Path Computation Element (PCE)
Communication Protocol (PCEP) association mechanism introduced by the
PCEP Association Group specification, to further associate sets of
LSPs with a higher-level structure such as a virtual network (VN)
requested by clients or applications. This extended association
mechanism can be used to facilitate virtual network control using PCE
architecture.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Lee, et al. Expires February, 2019 [Page 1]
Internet-Draft PCEP VN Association August 2019
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
This Internet-Draft will expire on February 22, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 7
5. Applicability to H-PCE architecture . . . . . . . . . . . . . . 8
6. Implementation Status . . . . . . . . . . . . . . . . . . . . . 9
6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Association Object Type Indicator . . . . . . . . . . . . . 10
8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . . 10
8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Manageability Considerations . . . . . . . . . . . . . . . . . 11
9.1. Control of Function and Policy . . . . . . . . . . . . . . 11
9.2. Information and Data Models . . . . . . . . . . . . . . . 11
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 11
9.6. Impact On Network Operations . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Lee, et al. Expires February, 2019 [Page 2]
Internet-Draft PCEP VN Association August 2019
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction
The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients' (PCCs)
requests.
[RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases.
[RFC8231] describes a set of extensions to PCEP to provide stateful
control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP), but also
the set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their
interactions.
[RFC8281] describes the setup, maintenance and teardown of PCE-
initiated LSPs under the stateful PCE model.
[I-D.ietf-pce-association-group] introduces a generic mechanism to
create a grouping of LSPs. This grouping can then be used to define
association between sets of LSPs or between a set of LSPs and a set
of attributes.
[RFC8453] describes various Virtual Network (VN) operations initiated
by a customer/application. In this context, there is a need for
associating a set of LSPs with a VN "construct" to facilitate VN
operations in PCE architecture. This association allows the PCEs to
identify which LSPs belong to a certain VN. The PCE could then use
this association to optimize all LSPs belonging to the VN together.
The PCE could further take VN specific actions on the LSPs such as
relaxation of constraints, policy actions, setting default behavior
etc.
[I-D.ietf-pce-applicability-actn] examines the PCE and ACTN
architecture and describes how the PCE architecture is applicable to
ACTN. [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a
hierarchy of stateful PCEs with Parent PCE coordinating multi-domain
path computation function between Child PCE(s) and thus making it the
base for PCE applicability for ACTN. In this text child PCE would be
same as Provisioning Network Controller (PNC), and the parent PCE as
Lee, et al. Expires February, 2019 [Page 3]
Internet-Draft PCEP VN Association August 2019
Multi-domain Service Coordinator (MDSC) [RFC8453].
This document specifies a PCEP extension to associate a set of LSPs
based on Virtual Network (VN) (or customer). A Virtual Network (VN)
is a customer view of the TE network. Depending on the agreement
between client and provider various VN operations and VN views are
possible as described in [RFC8453].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Lee, et al. Expires February, 2019 [Page 4]
Internet-Draft PCEP VN Association August 2019
2. Terminology
The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231]
and [RFC8453].
3. Operation Overview
As per [I-D.ietf-pce-association-group], LSPs are associated with
other LSPs with which they interact by adding them to a common
association group.
An association group based on VN is useful for various optimizations
that should be applied by considering all the LSPs in the
association. This includes, but not limited to -
o Path Computation: When computing path for a LSP, the impact of
this LSP, on the other LSPs belonging to the same VN is useful to
analyze. The aim would be optimize overall VN and all LSPs, rather
than a single LSP. Also, the optimization criteria such as
minimize the load of the most loaded link (MLL) [RFC5541] and
other could be applied for all the LSP belonging to the same VN,
identified by the VN association.
o Path Re-Optimization: The child PCE or the parent PCE would like
to use advanced path computation algorithm and optimization
technique that consider all the LSPs belonging to a VN/customer
and optimize them all together during the re-optimization.
This association is useful in PCEP session between parent PCE
(MDSC) and child PCE (PNC). The figure describes a typical VN
operations using PCEP for illustration purpose.
Lee, et al. Expires February, 2019 [Page 5]
Internet-Draft PCEP VN Association August 2019
******
..........*MDSC*..............................
. ****** .. MPI .
. . . PCEP .
. . . PCInitiate LSPx .
. . . with VNAG = 10 .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
/ .
****** / .
*PNC3*<............/.....................
****** /
+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
In this draft, this grouping is used to define associations between a
set of LSPs and a virtual network, a new association group is defined
below -
o VN Association Group (VNAG)
One new Association type is defined as described in the Association
object -
o Association type = TBD1 ("VN Association") for VNAG
The scope and handling of VNAG identifier is similar to the generic
association identifier defined in [I-D.ietf-pce-association-group].
In this document VNAG object refers to an Association Object with the
Association type set to "VNAG".
Lee, et al. Expires February, 2019 [Page 6]
Internet-Draft PCEP VN Association August 2019
Local polices on the PCE MAY define the computational and
optimization behavior for the LSPs in the VN. An LSP MUST NOT belong
to more than one VNAG. If an implementation encounters more than one
VNAG, it MUST consider the first occurrence and ignore the others.
[I-D.ietf-pce-association-group] specify the mechanism for the
capability advertisement of the association types supported by a PCEP
speaker by defining a ASSOC-Type-List TLV to be carried within an
OPEN object. This capability exchange for the association type
described in this document (i.e. VN Association Type) MUST be done
before using the policy association. Thus the PCEP speaker MUST
include the VN Association Type (TBD1) in the ASSOC-Type-List TLV
before using the VNAG in the PCEP messages.
This Association-Type is dynamic in nature and created by the Parent
PCE (MDSC) for the LSPs belonging to the same VN or customer. These
associations are conveyed via PCEP messages to the PCEP peer.
Operator-configured Association Range MUST NOT be set for this
association-type and MUST be ignored.
4. Extensions to PCEP
The format of VNAG is as per the ASSOCIATION object [I-D.ietf-pce-
association-group].
This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one
new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV,
VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific
information.
o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.
o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
specific behavioral information, described in [RFC7470].
The format of VIRTUAL-NETWORK-TLV is as follows.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Virtual Network Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lee, et al. Expires February, 2019 [Page 7]
Internet-Draft PCEP VN Association August 2019
Figure 1: The VIRTUAL-NETWORK-TLV formats
Type: TBD2 (to be allocated by IANA)
Length: Variable Length
Virtual Network Name (variable): an unique symbolic name for the VN.
It SHOULD be a string of printable ASCII characters, without a NULL
terminator. The VN name is a human-readable string that identifies
a VN. The VN name MUST remain constant throughout an LSP's lifetime,
which may span across multiple consecutive PCEP sessions and/or
PCC restarts. The VN name MAY be specified by an operator or
auto-generated by the PCEP speaker.
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
MUST send a PCErr message with Error-Type=6 (mandatory object
missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
the session.
The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
5. Applicability to H-PCE architecture
The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key motivation for PCE
development. [RFC6805] describes a Hierarchical PCE (H-PCE)
architecture which can be used for computing end-to-end paths for
inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched
Paths (LSPs). Within the hierarchical PCE architecture, the parent
PCE is used to compute a multi-domain path based on the domain
connectivity information. A child PCE may be responsible for a
single domain or multiple domains, it is used to compute the intra-
domain path based on its domain topology information.
[I-D.ietf-pce-stateful-hpce] introduces general considerations for
stateful PCE(s) in hierarchical PCE architecture. In particular, the
behavior changes and additions to the existing stateful PCE
mechanisms in the context of a H-PCE architecture.
In Stateful H-PCE architecture, the Parent PCE receives a virtual
network creation request by its client over its Northbound API. This
VN is uniquely identified by an Association ID in VNAG as well as the
VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the
network in a single domain or across multiple domains.
As the Parent PCE computes the optimum E2E paths for each tunnel in
Lee, et al. Expires February, 2019 [Page 8]
Internet-Draft PCEP VN Association August 2019
VN, it MUST associate each LSP with the VN to which it belongs.
Parent PCE sends a PCInitiate Message with this association
information in the VNAG Object (See Section 4 for details). This in
effect binds an LSP that is to be instantiated at the child PCE with
the VN.
Whenever changes occur with the instantiated LSP in a domain network,
the domain child PCE reports the changes using a PCRpt Message in
which the VNAG Object indicates the relationship between the LSP and
the VN.
Whenever an update occurs with VNs in the Parent PCE (via the
client's request), the parent PCE sends an PCUpd Message to inform
each affected child PCE of this change.
The Child PCE could then use this association to optimize all LSPs
belonging to the same VN association together. The Child PCE could
further take VN specific actions on the LSPs such as relaxation of
constraints, policy actions, setting default behavior etc. The parent
PCE could also maintain all E2E LSP or per-domain path segments under
a single VN association.
6. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. It
is up to the individual working groups to use this information as
they see fit".
6.1. Huawei's Proof of Concept based on ONOS
Lee, et al. Expires February, 2019 [Page 9]
Internet-Draft PCEP VN Association August 2019
The PCE function was developed in the ONOS open source platform. This
extension was implemented on a private version as a proof of concept
to ACTN.
o Organization: Huawei
o Implementation: Huawei's PoC based on ONOS
o Description: PCEP as a southbound plugin was added to ONOS. To
support ACTN, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol
o Maturity Level: Prototype
o Coverage: Full
o Contact: satishk@huawei.com
7. Security Considerations
This document defines one new type for association, which do not
add any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [I-D.ietf-pce-association-group] in itself.
Some deployments may find the Virtual Network Name and the VN
associations as extra sensitive; and thus should employ suitable
PCEP security mechanisms like TCP-AO [RFC5925] or [RFC8253].
8. IANA Considerations
8.1. Association Object Type Indicator
This document defines a new association type, originally defined
in [I-D.ietf-pce-association-group], for path protection. IANA is
requested to make the assignment of a new value for the sub-
registry "ASSOCIATION Type Field" (request to be created in [I-
D.ietf-pce-association-group]), as follows:
Value Name Reference
TBD1 VN Association Type [This I.D.]
8.2. PCEP TLV Type Indicator
This document defines a new TLV for carrying additional
information of LSPs within a path protection association group.
IANA is requested to make the assignment of a new value for the
existing "PCEP TLV Type Indicators" registry as follows:
Lee, et al. Expires February, 2019 [Page 10]
Internet-Draft PCEP VN Association August 2019
Value Name Reference
TBD2 VIRTUAL-NETWORK-TLV [This I.D.]
8.3. PCEP Error
This document defines new Error-Type and Error-Value related to
path protection association. IANA is requested to allocate new
error values within the "PCEP-ERROR Object Error Types and Values"
sub- registry of the PCEP Numbers registry, as follows:
Error-Type Meaning
6 Mandatory Object missing
Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
I.D.]
9. Manageability Considerations
9.1. Control of Function and Policy
An operator MUST BE allowed to mark LSPs that belong to the same
VN. This could also be done automatically based on the VN
configuration.
9.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
association between LSPs including VN association.
9.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
9.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
9.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new
requirements on other protocols.
Lee, et al. Expires February, 2019 [Page 11]
Internet-Draft PCEP VN Association August 2019
9.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
[RFC5440].
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP
Extensions for Stateful PCE", RFC 8231, September 2017.
[RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP
Setup in a Stateful PCE Model", RFC 8281, December 2017.
[I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group, work in progress.
10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6805] A. Farrel and D. King, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, RFC
7942, DOI 10.17487/RFC7942, July 2016.
Lee, et al. Expires February, 2019 [Page 12]
Internet-Draft PCEP VN Association August 2019
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, <https://www.rfc-
editor.org/info/rfc8453>.
[I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D.
Ceccarelli, "Applicability of Path Computation Element
(PCE) for Abstraction and Control of TE Networks (ACTN)",
draft-ietf-pce-applicability-actn, work-in-progress.
[I-D.ietf-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical
Stateful Path Computation Element (PCE)",
draft-ietf-pce-stateful-hpce, work in progress.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<http://www.rfc-editor.org/info/rfc7470>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<http://www.rfc-editor.org/info/rfc8051>.
[RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
Transport for PCEP", RFC 8253, October 2017 .
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)",
draft-ietf-pce-pcep-yang (work in progress).
Lee, et al. Expires February, 2019 [Page 13]
Internet-Draft PCEP VN Association August 2019
Contributor's Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Technopark, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Qin Wu
Huawei Technologies
China
Email: bill.wu@huawei.com
Author's Addresses
Young Lee
Futurewei
5340 Legacy Drive, Building 3
Plano, TX 75023,
USA
Email: younglee.tx@gmail.com
Xian Zhang
Huawei Technologies
China
Email: zhang.xian@huawei.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm,
Sweden
Email: daniele.ceccarelli@ericsson.com
Lee, et al. Expires February, 2019 [Page 14]
