Internet-Draft PCE VN Association May 2022
Lee, et al. Expires 12 November 2022 [Page]
PCE Working Group
Intended Status:
Standards Track
Y. Lee
H. Zheng
Huawei Technologies
D. Ceccarelli

Path Computation Element Communication Protocol (PCEP) extensions for establishing relationships between sets of Label Switched Paths and Virtual Networks


This document describes how to extend the Path Computation Element (PCE) Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of virtual network using the PCE architecture.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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."

This Internet-Draft will expire on 12 November 2022.

Table of Contents

1. Introduction

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs) [RFC5440].

[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. For its computations, 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. The additional state allows the PCE to compute constrained paths while considering individual Label Switched Paths (LSPs) and their interactions.

[RFC8281] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model.

[RFC8697] introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes.

[RFC8453] introduces a framework for Abstraction and Control of TE Networks (ACTN) and describes various Virtual Network (VN) operations initiated by a customer or application. A 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.

[RFC8637] examines the PCE and ACTN architectures and describes how the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] describes a hierarchy of stateful PCEs with Parent PCE coordinating multi-domain path computation function between Child PCEs, 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 Multi-domain Service Coordinator (MDSC) [RFC8453].

In this context, there is a need to associate a set of LSPs with a VN "construct" to facilitate VN operations in the PCE architecture. This association allows a PCE to identify which LSPs belong to a certain VN. The PCE could then use this association to optimize all LSPs belonging to the VN at once. The PCE could further take VN-specific actions on the LSPs, such as relaxation of constraints, policy actions, setting default behavior, etc.

This document specifies a PCEP extension to associate a set of LSPs based on Virtual Network (VN).

1.1. Requirement 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.

2. Terminology

The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] and [RFC8453].

3. Operation Overview

As per [RFC8697], 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 is not limited to -

In this document we define a new association group called the VN Association Group (VNAG). This grouping is used to define the association between a set of LSPs and a virtual network.

The Association Object contains a field to identify the type of association, and this document defines a new Association Type value of TBD1 to indicate that the association is a "VN Association". The Association Identifier in the Association Object is the VNAG Identifier and is handled in the same way as the generic association identifier defined in [RFC8697].

In this document, "VNAG object" refers to an Association Object with the Association type set to "VN Association".

Local polices on the PCE 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 object in a PCEP message, it MUST process the first occurrence and it MUST ignore the others.

[RFC8697] specifies the mechanism by which a PCEP speaker can advertise which association types it supports. This is done using the ASSOC-Type-List TLV carried within an OPEN object. A PCEP speaker MUST include the VN Association Type (TBD1) in the ASSOC-Type-List TLV before using the VNAG object in a PCEP message. As per [RFC8697], if the implementation does not support the VN Association Type, it will return a PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not supported".

The Association IDs (VNAG IDs) for this Association Type are dynamic in nature (and created by the Parent PCE (MDSC) based on the VN operations for the LSPs belonging to the same VN). Operator configuration of VNAG IDs is not supported so there is no need for an Operator-Configured Association Range to be set. Thus, the VN Association Type (TBD1) MUST NOT be present in the Operator-Configured Association Range TLV if that TLV is present in the OPEN object. If an implementation encounters the VN Association Type (TBD1) in an Operator-Configured Association Range TLV, it MUST ignore the associated Start-Assoc-ID and Range values.

This association is useful in a PCEP session between a parent PCE (MDSC) and a child PCE (PNC). When computing the path, the child PCE (PNC) refers to the VN association in the request from the parent PCE (MDSC) and maps the VN to the associated LSPs and network resources. From the perspective of Parent PCE, it receives a virtual network creation request by its customer, with the VN uniquely identified by an Association ID in VNAG as well as the Virtual Network identifier. This VN may comprise multiple LSPs in the network in a single domain or across multiple domains. Parent PCE sends a PCInitiate Message with this association information in the VNAG Object. This in effect binds an LSP that is to be instantiated at the child PCE with the VN. The VN association information could be included as a part of the response as well. Figure 1 shows an example of a typical VN operation using PCEP. It is worth noting that in a multi-domain scenario, the different domains are controlled by different child PCEs. In order to set up the cross-domain tunnel, multiple segments need to be stitched, by the border nodes in each domain who receives the instruction from their child PCE (PNC).

                      .            ****** ..                   MPI    .
                   .                .        .                 PCEP   .
                .                   .          .   PCInitiate LSPx   .
              .                    .             .   with VNAG = 10   .
             .                    .                .                  .
            .                    .                  .                 .
           .                    .                    .                .
           v                    v                    v                .
         ******               ******               ******             .
         *PNC1*               *PNC2*               *PNC4*             .
         ******               ******               ******             .
         +---------------+    +---------------+    +---------------+  .
         |A              |----|               |----|              C|  .
         |               |    |               |    |               |  .
         |DOMAIN 1       |----|DOMAIN 2       |----|DOMAIN 4       |  .
         +------------B13+    +---------------+    +B43------------+  .
                                                  /                  .
                             ******              /                   .
                             ******            /
                              B31           B34
                             |               |
                             |DOMAIN 3      B|

         MDSC -> Parent PCE
         PNC  -> Child  PCE
         MPI  -> PCEP

         Figure 1: Example of VN operations in H-PCE Architecture

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 customer's request), the parent PCE sends an PCUpd Message to inform each affected child PCE of this change.

4. Extensions to PCEP

The format of VNAG is as per the ASSOCIATION object [RFC8697].

This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV". Optionally, the new TLV can be jointly used with the existing "VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below:

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 Identifier                //
   |                                                               |
              Figure 2: The VIRTUAL-NETWORK-TLV formats

Type: TBD2 (to be allocated by IANA)

Length: Variable Length, which covers the value portion of the TLV.

Virtual Network Identifier (variable): a symbolic name for the VN that uniquely identifies the VN. It SHOULD be a string of printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL terminator. The Virtual Network Identifier is a human-readable string that identifies a VN and can be specified with the association information. An implementation could use the Virtual Network Identifier to maintain a mapping to the VN association group and the LSPs associated with the VN. The Virtual Network Identifier MAY be specified by the customer or set via an operator policy 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. 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 [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 [RFC7942], "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".

5.1. Huawei's Proof of Concept based on ONOS

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.

  • Organization: Huawei
  • Implementation: Huawei's PoC based on ONOS
  • Description: PCEP as a southbound plugin was added to ONOS. To support ACTN, this extension in PCEP is used. Refer
  • Maturity Level: Prototype
  • Coverage: Full
  • Contact:

6. 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 [RFC8697] in itself.

Some deployments may find the Virtual Network Identifier and the VN associations as extra sensitive; and thus should employ suitable PCEP security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253].

7. IANA Considerations

7.1. Association Object Type Indicator

IANA is requested to make the assignment of a new value for the sub-registry "ASSOCIATION Type Field" (request to be created in [RFC8697]) within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows:

      Value     Name                        Reference

      TBD1      VN Association Type         [This I.D.]

7.2. PCEP TLV Type Indicator

IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows:

      Value     Name                        Reference

      TBD2      VIRTUAL-NETWORK-TLV         [This I.D.]

7.3. PCEP Error

IANA is requested to allocate new error value within the "PCEP-ERROR Object Error Types and Values" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows:

      Error-Type  Meaning

      6           Mandatory Object missing
                  Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This

8. Manageability Considerations

8.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.

8.2. Information and Data Models

The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the association between LSPs including VN association.

8.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].

8.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].

8.5. Requirements On Other Protocols

Mechanisms defined in this document do not imply any new requirements on other protocols.

8.6. Impact On Network Operations

[RFC8637] describe the network operations when PCE is used for VN operations. Section 3 further specify the operations when VN associations is used.

9. References

9.1. Normative References

Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, , <>.
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, , <>.
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, , <>.

9.2. Informative References

Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, , <>.
Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, , <>.
King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, , <>.
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <>.
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, , <>.
Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, , <>.
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, , <>.
Zhang, F. and A. Farrel, "Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol", RFC 7470, DOI 10.17487/RFC7470, , <>.
Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, , <>.
Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, , <>.
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, , <>.
Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-18, , <>.

Appendix A. Contributors

   Dhruv Dhody
   Huawei Technologies
   Divyashree Technopark, Whitefield
   Bangalore, Karnataka  560066

   Qin Wu
   Huawei Technologies

   Xian Zhang
   Huawei Technologies

   Adrian Farrel
   Old Dog Consulting

Authors' Addresses

Young Lee
South Korea
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Guangdong, 523808
Daniele Ceccarelli