Internet DRAFT - draft-dong-pce-pcep-vtn
draft-dong-pce-pcep-vtn
PCE Working Group J. Dong
Internet-Draft S. Fang
Intended status: Standards Track Huawei Technologies
Expires: 12 January 2023 L. Han
M. Wang
China Mobile
11 July 2022
Support for Virtual Transport Network (VTN) in the Path Computation
Element Communication Protocol (PCEP)
draft-dong-pce-pcep-vtn-01
Abstract
With the introduction and evolvement of 5G and other network
scenarios, some existing or new customers may require connectivity
services with advanced characteristics comparing to traditional
Virtual Private Networks (VPNs). Such kind of network service is
called enhanced VPNs (VPN+). The typical application of VPN+ is to
provide network slice services.
A Virtual Transport Network (VTN) is a virtual underlay network which
consists of a set of dedicated or shared network resources allocated
from the physical underlay network, and is associated with a
customized logical network topology. VPN+ services can be delivered
by mapping one or a group of overlay VPNs to the appropriate VTNs as
the virtual underlay. Then traffic flows of the VPN+ service can be
steered onto the TE paths within the VTN.
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multi-protocol Label
Switching (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR)
networks.
This document specifies the extensions to PCE communication Protocol
(PCEP) to carry VTN information in the PCEP messages. The extensions
in this document can be used in the basic PCE computation, the
stateful PCE and the PCE-initiated LSP mechanisms to indicate path
computation, path status report and path initialization within a
specific VTN.
Requirements Language
Dong, et al. Expires 12 January 2023 [Page 1]
Internet-Draft PCEP Extensions for VTN July 2022
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.
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 https://datatracker.ietf.org/drafts/current/.
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 January 2023.
Copyright Notice
Copyright (c) 2022 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. New TLV in LSPA Object . . . . . . . . . . . . . . . . . 4
2.2. Capability Advertisement . . . . . . . . . . . . . . . . 5
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
Dong, et al. Expires 12 January 2023 [Page 2]
Internet-Draft PCEP Extensions for VTN July 2022
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC5440] describes the Path Computation Element (PCE) Communication
Protocol (PCEP). PCEP enables the communication between a Path
Computation Client (PCC) and a PCE, or between PCE and PCE, for the
purpose of computation of Multi-protocol Label Switching (MPLS) as
well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched
Path (TE LSP) characteristics.
[RFC8231] specifies a set of extensions to PCEP to enable stateful
control of TE LSPs within and across PCEP sessions in compliance with
[RFC4657]. It includes mechanisms to effect LSP State
Synchronization between PCCs and PCEs, delegation of control over
LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. The model of operation
where LSPs are initiated from the PCE is described in [RFC8281].
[RFC8664] specifies PCEP extensions to allow a stateful PCE to
compute and initiate TE paths, as well as a PCC to request a path
subject to certain constraints and optimization criteria in SR
networks.
With the introduction and evolvement of 5G and other network
scenarios, some existing or new customers may require connectivity
services with advanced characteristics comparing to traditional
Virtual Private Networks (VPNs). Such kind of network service is
called enhanced VPNs (VPN+). The typical application of VPN+ is to
provide network slice services. The concept and general framework of
IETF network slice are described in
[I-D.ietf-teas-ietf-network-slices].
[I-D.ietf-teas-enhanced-vpn] describes a framework and the candidate
component technologies for providing VPN+ services. It also
introduces the concept of Virtual Transport Network (VTN). A Virtual
Transport Network (VTN) is a virtual underlay network which consists
of a set of dedicated or shared network resources allocated from the
physical underlay network, and is associated with a customized
logical network topology. VPN+ services can be delivered by mapping
one or a group of overlay VPNs to the appropriate VTNs as the
underlay, so as to provide the network characteristics required by
the customers. Then the traffic flows of the VPN+ service can be
steered onto the TE paths within the VTN.
Dong, et al. Expires 12 January 2023 [Page 3]
Internet-Draft PCEP Extensions for VTN July 2022
In MPLS or SR based network, the set of network resources allocated
to a VTN can be identified using resource-aware SR SIDs as defined in
[I-D.ietf-spring-resource-aware-segments]
[I-D.ietf-spring-sr-for-enhanced-vpn], or the VTN Resource ID as
defined in [I-D.ietf-6man-enhanced-vpn-vtn-id]. The logical topology
associated with a VTN could be specified using mechanisms such as
Multi-Topology [RFC4915], [RFC5120] or Flex-Algo
[I-D.ietf-lsr-flex-algo], etc.
To meet specific service requirement, traffic flows of a VPN+ service
need be steered onto TE paths of the corresponding VTN. A PCC may
request the PCE for computing a TE path within a VTN, so that the
path computation would take the resource attribute and the associated
topology of the VTN into consideration. Correspondingly, a PCE may
reply or initiate a TE path with VTN-specific control and data plane
information to a PCC.
This document extends PCEP to allow VTN information to be encoded in
the PCEP messages. The extensions in this document can be used in
the basic PCE computation, the stateful PCE and the PCE-initiated LSP
mechanisms to indicate path computation, path status report and path
initialization within the context of a specific VTN.
2. PCEP Extensions
2.1. New TLV in LSPA Object
A new VTN TLV for use in the LSPA Object is defined to indicate the
VTN ID and the related information as constraints. The format of the
VTN 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=TBD1 | Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: VTN TLV Format
Where:
Dong, et al. Expires 12 January 2023 [Page 4]
Internet-Draft PCEP Extensions for VTN July 2022
* VTN ID: A global significant 32-bit identifier which is used to
identify a VTN.
* Flags: 16-bit flags. Currently all the flags are reserved for
future use. They SHOULD be set to zero on transmission and MUST
be ignored on receipt.
* Reserved: 16-bit reserved field for future use. All the bits
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
* Optional sub-TLVs: Additional information which can be used in as
VTN-specific constraints. Currently no sub-TLV is defined in this
document.
2.2. Capability Advertisement
A PCEP speaker indicates whether it supports VTN specific path
computation using a new PCEP capability called "VTN-CAPABILITY".
When the PCEP session is created, it sends an Open message with an
OPEN Object containing the VTN-CAPABILITY TLV. The format of this
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=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: VTN CAPABILITY TLV
The type (16 bits) of the TLV is TBA. The length field is 16 bits
long and has a fixed value of 4.
The value comprises a single field -- Flags (32 bits):
* D (Data Plane VTN-ID CAPABILITY - 1 bit): if set to 1 by a PCC,
the D flag indicates that the PCC supports the encapsulation of
data plane VTN-ID in data packet; if set to 1 by a PCE, the D flag
indicates that the PCE supports to provide path computation result
with the data plane VTN-ID.
* Unassigned bits in the Flags field MUST be set to zero and ignored
on receipt.
Dong, et al. Expires 12 January 2023 [Page 5]
Internet-Draft PCEP Extensions for VTN July 2022
3. Operations
The new VTN TLV defined in this document can be used in the basic PCE
computation, the stateful PCE and the PCE-initiated LSP mechanisms to
indicate path computation, path status report and path initialization
within the context of a specific VTN.
Information about the VTN-specific network resource and topology
attributes can be obtained by the PCE either from the network
planning system, or using a distributed control plane such as IGP or
BGP-LS with necessary extensions. The detailed mechanism is out of
the scope of this document. The obtained VTN specific attributes can
be used in path computation when the VTN-ID is specified in the path
computation request.
With the basic path computation mechanism, the new VTN TLV can be
used to indicate the VTN in which the path computation is requested.
In a PCReq message, the VTN TLV MAY be carried in the LSPA Object to
indicate that the path computation needs to be executed using the
resource and topological attributes of the VTN. The PCE SHOULD use
the network resource and topology attributes associated with the
specified VTN as the parameters of path computation. In a PCRep
message, the VTN TLV MAY be carried in the LSPA Object in case of
failure to indicate the path computation in the VTN was not
successful.
The new VTN TLV can also be used in the stateful PCE mechanisms. A
PCC MAY include the VTN TLV in PCRpt message to indicate the VTN in
which the TE path is reported. And A PCE MAY include the VTN TLV in
PCUpd Message to indicate the VTN in which the TE path needs to be
updated.
With the PCE-Initiated LSP mechanism, the PCE MAY include the VTN TLV
in PCInitiate or PCUpd message to indicate the VTN in which the path
is computed, so that the PCC will use the VTN-specific resources and
data plane VTN-ID in constructing or updating the TE path.
4. Security Considerations
This document defines a new VTN TLV that do not add any new security
concerns beyond those discussed in [RFC5440] in itself. Some
deployments may find the VTN information to be extra sensitive and
could be used to influence path computation and setup with adverse
effect. Additionally, snooping of PCEP messages with such data or
using PCEP messages for network reconnaissance may give an attacker
sensitive information about the operations of the network. Thus,
such deployment should employ suitable PCEP security mechanisms like
TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer
Dong, et al. Expires 12 January 2023 [Page 6]
Internet-Draft PCEP Extensions for VTN July 2022
Security (TLS) [RFC8253]. The procedure based on TLS is considered a
security enhancement and thus is much better suited for the sensitive
information.
5. IANA Considerations
This document makes following requests to IANA for action.
IANA is requested to make the following allocations in the "PCEP TLV
Type Indicators" subregistry of the "Path Computation Element
Protocol (PCEP) Numbers" registry:
Value Description Reference
----- ---------------- -------------
TBD1 VTN This document
TBD2 VTN CAPABILITY This document
6. Contributors
Dhruv Dhody
Email: dhruv.ietf@gmail.com
Zhibo Hu
Email: huzhibo@huawei.com
7. Acknowledgments
The authors would like to thank Zhenbin Li for his review and
valuable comments.
8. References
8.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Dong, et al. Expires 12 January 2023 [Page 7]
Internet-Draft PCEP Extensions for VTN July 2022
[RFC8231] 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, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] 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, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-20, 18 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-
20.txt>.
8.2. Informative References
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[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>.
Dong, et al. Expires 12 January 2023 [Page 8]
Internet-Draft PCEP Extensions for VTN July 2022
[RFC8253] 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, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
K., Contreras, L. M., and J. Tantsura, "Framework for IETF
Network Slices", Work in Progress, Internet-Draft, draft-
ietf-teas-ietf-network-slices-12, 30 June 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
network-slices-12.txt>.
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+)
Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-10, 6 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-
vpn-10.txt>.
[I-D.ietf-spring-resource-aware-segments]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Introducing Resource Awareness to SR
Segments", Work in Progress, Internet-Draft, draft-ietf-
spring-resource-aware-segments-04, 5 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring-
resource-aware-segments-04.txt>.
[I-D.ietf-spring-sr-for-enhanced-vpn]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Segment Routing based Virtual Transport
Network (VTN) for Enhanced VPN", Work in Progress,
Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-02,
5 March 2022, <https://www.ietf.org/archive/id/draft-ietf-
spring-sr-for-enhanced-vpn-02.txt>.
Dong, et al. Expires 12 January 2023 [Page 9]
Internet-Draft PCEP Extensions for VTN July 2022
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra,
"Carrying Virtual Transport Network (VTN) Identifier in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-00, 5 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-enhanced-
vpn-vtn-id-00.txt>.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: jie.dong@huawei.com
Sheng Fang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: fangsheng@huawei.com
Liuyan Han
China Mobile
Beijing
China
Email: hanliuyan@chinamobile.com
Minxue Wang
China Mobile
Beijing
China
Email: wangminxue@chinamobile.com
Dong, et al. Expires 12 January 2023 [Page 10]
