Support for Virtual Transport
Network (VTN) in the Path Computation Element Communication Protocol
(PCEP)Huawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinafangsheng@huawei.comChina MobileBeijingChinahanliuyan@chinamobile.comChina MobileBeijingChinawangminxue@chinamobile.com
Routing
PCE Working GroupWith 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.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
when, and only when,
they appear in all capitals, as shown here. 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. specifies a set of extensions to PCEP to
enable stateful control of TE LSPs within and across PCEP sessions in
compliance with . 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 . 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 . 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.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
, or the VTN Resource ID
as defined in . The
logical topology associated with a VTN could be specified using
mechanisms such as Multi-Topology , or 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.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:Where: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.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: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.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.This document defines a new VTN TLV that do not add any new security
concerns beyond those discussed in 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) or Transport Layer Security
(TLS) . The procedure based on TLS is considered
a security enhancement and thus is much better suited for the sensitive
information.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:The authors would like to thank Zhenbin Li for his review and
valuable comments.