Path Computation Element
Communication Protocol (PCEP) Extension for Path Segment in Segment
Routing (SR)Huawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinachengli13@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095ChinaMach.chen@huawei.comChina MobileChinachengweiqiang@chinamobile.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comCisco Systems, Inc.Canadargandhi@cisco.comZTE CorporationChinaxiong.quan@zte.com.cn
Routing Area
PCE Working GroupThe Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets through
an IPv6 or MPLS network using the source routing paradigm. A Segment
Routed Path can be derived from a variety of mechanisms, including an
IGP Shortest Path Tree (SPT), explicit configuration, or a Path
Computation Element (PCE).Path identification is needed for several use cases such as
performance measurement in Segment Routing (SR) network. This document
specifies extensions to the Path Computation Element Protocol (PCEP) to
support requesting, replying, reporting and updating the Path Segment ID
(Path SID) between PCEP speakers. 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 Multiprotocol Label Switching (MPLS) as well
as Generalzied 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 .
specify the procedures and PCEP protocol extensions for using the PCE as
the central controller for static LSPs, where LSPs can be provisioned as
explicit label instructions at each hop on the end-to-end path.Segment routing (SR) leverages the source
routing and tunneling paradigms and supports steering packets into an
explicit forwarding path at the ingress node.An SR path needs to be identified in some use cases such as
performance measurement. For identifying an SR path, introduces a new segment
that is referred to as Path Segment. specifies extensions to
the Path Computation Element Protocol (PCEP)
for SR networks, that allow a stateful PCE to compute and initiate SR-TE
paths, as well as a PCC to request, report or delegate SR paths. extend PCEP to support SR
paths for IPv6 data plane.
specifies the procedures and PCEP protocol extensions when a PCE-based
controller is also responsible for configuring the forwarding actions on
the routers (SR SID distribution in this case), in addition to computing
the paths for packet flows in a segment routing network and telling the
edge routers what instructions to attach to packets as they enter the
network.This document specifies a mechanism to carry the SR path
identification information in PCEP messages . The SR path
identifier can be a Path Segment in SR-MPLS , or a Path Segment in SRv6
or other IDs that can
identify an SR path. This document also extends the PCECC-SR mechanism
to inform the Path Segment to the egress PCC.This memo makes use of the terms defined in ,
, and .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.This document specifies a mechanism of encoding (and allocating) Path
Segment in PCEP extensions. For supporting Path Segment in PCEP, several
TLVs and flags are defined. The formats of the objects and TLVs are
described in . The procedures of Path Segment
allocation are described in .There are various modes of operations, such as - The Path Segment can be allocated by Egress PCC. The PCE should
request the Path Segment from Egress PCC.The PCE can allocate a Path Segment on its own accord and inform
the ingress/egress PCC, useful for PCE-initiated LSPs.Ingress PCC can also request PCE to allocate the Path Segment, in
this case, the PCE would either allocate and inform the assigned
Path Segment to the ingress/egress PCC using PCEP messages, or first
request egress PCC for Path Segment and then inform it to the
ingress PCC.The path information to the ingress PCC and PCE is exchanged via an
extension to and . The Path Segment
information to the egress PCC can be informed via an extension to the
PCECC-SR procedures .For the PCE to allocate a Path Segment, the PCE SHOULD be aware of
the MPLS label space from the PCCs. This is done via mechanism as
described in . Otherwise,
the PCE should request the egress PCC for Path Segment allocation. defined a new Path
Setup Type (PST) and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers
use this sub-TLV to exchange information about their SR capability.
The TLV defines a Flags field that includes one bit (L-flag) to
indicate Local Significance .This document adds an additional flag for Path Segment
allocation, as follows -P (Path Segment Identification bit): A PCEP speaker sets this
flag to 1 to indicate that it has the capability to encode SR
path identification (Path Segment, as per ).The figure is included for the ease of the reader and can be
removed at the time of publication. defined a new
Path Setup Type (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP
speakers use this sub-TLV to exchange information about their SRv6
capability. The TLV includes a Flags field and one bit (L-flag) was
allocated in .This document adds an additional flag for Path Segment
allocation, as follows -P (Path Segment Identification bit): A PCEP speaker sets this
flag to 1 to indicate that it has the capability to encode SRv6
path identification.(Path Segment, as per ).The figure is included for the ease of the reader and can be
removed at the time of publication.Along with the SR sub-TLVs, the PCECC Capability as per should be
advertised if the PCE allocates the Path Segment and acts as a
Central Controller that manages the Label space.The PCECC Capability should also be advertised on the egress PCEP
session, along with the SR sub-TLVs. This is needed to ensure that
the PCE can use the PCECC objects/mechanism to request/inform the
egress PCC of the Path Segment as described in this document.The LSP Object is defined in Section 7.3 of . This document adds the following flags to the LSP
Object:P (PCE Allocation bit): If the bit is set to 1, it indicates
that the PCC requests PCE to allocate resource for this LSP. With
the resource TLV, a PCE can undertsand what kind of resource
should be allocated, such as Path Segment and Binding Segment. A
PCC would set this bit to 1 and include a PATH-SEGMENT TLV in the
LSP object to request for allocation of Path Segment by the PCE in
the PCReq or PCRpt message. A PCE would also set this bit to 1 and
include a PATH-SEGMENT TLV to indicate that the Path Segment is
allocated by PCE and encoded in the PCRep, PCUpd or PCInitiate
message. Further, a PCE would set this bit to 0 and include a
PATH-SEGMENT TLV in the LSP object to indicate that the Path
Segment should be allocated by the PCC as described in .The figure is included for the ease of the reader and can be
removed at the time of publication.The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object
for Path Segment allocation. The type of this TLV is to be allocated
by IANA (TBA4). The format is shown below.The type (16-bit) of the TLV is TBA4 (to be allocated by IANA).
The length (16-bit) has a fixed value of 8 octets. The value
contains the following fields: ST (The Segment type - 8 bits): The ST field specifies the
type of the Path Segment field, which carries a Path Segment
corresponding to the SR path.0: MPLS Path Segment, which is an MPLS label as defined
in . The
PST type MUST be set to SR (MPLS).1: SRv6 Path Segment, which is a 128 bit IPv6 address as
defined in .
The PST type MUST be set to SRv6.Flags (8 bits): Two flags are currently defined: L-Bit (Local/Global - 1 bit): If set, then the Path
Segment carried by the PATH-SEGMENT TLV has local
significance. If not set, then the Path Segment carried by
this TLV has global significance (i.e. Path Segment is
global within an SR domain).The unassigned bits MUST be set to 0 and MUST be ignored
at receipt.Reserved (16 bits): MUST be set to 0 and MUST be ignored at
receipt.Path Segment: The Path Segment of an SR path. The Path
Segment type is indicated by the ST field. When the ST is 0, it
is a MPLS Path Segment in the MPLS label
format. When the ST field is 1, it is a 128-bit SRv6 Path
Segment as defined in .In general, only one instance of PATH-SEGMENT TLV will be
included in LSP object. If more than one PATH-SEGMENT TLV is
included, the first one is processed and others MUST be ignored.
Multiple Path Segment allocation for use cases like alternate-making
will be considered in future version of this draft.When the Path Segment allocation is enable, a PATH-SEGMENT TLV
MUST be included in the LSP object.If the label space is maintained by PCC itself, and the Path
Segment is allocated by Egress PCC, then the PCE should request the
Path Segment from Egress PCC as described in . In this case, the PCE should send a PCUpdate
or PCInitiate message to
the egress PCC to request the Path Segment. The P-flag in LSP should
be unset in this case.If a PCEP node does not recognize the PATH-SEGMENT TLV, it would
behave in accordance with and ignore the
TLV. If a PCEP node recognizes the TLV but does not support the TLV,
it MUST send PCErr with Error-Type = 2 (Capability not
supported).The FEC Object is used to
specify the FEC information and MAY be carried within PCInitiate or
PCRpt message for the PCECC-SR operations. The PCE MUST inform the
Path Identification information to the Egress PCC. To do this, this
document extends the procedures of by defining a
new FEC object type for Path.FEC Object-Type is TBA6 'Path'.One or more following TLV(s) are allowed in the 'path' FEC object -
SYMBOLIC-PATH-NAME TLV: As defined in ,
it is a human-readable string that identifies an LSP in the
network.LSP-IDENTIFIERS TLVs: As defined in ,
it is optional for SR, but could be used to encode the source,
destination and other identification information for the path.SPEAKER-ENTITY-ID TLV: As defined in ,
a unique identifier for the PCEP speaker, it is used to identify
the Ingress PCC.Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be
included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of each
TLV is processed, if more than one TLV of each type is included, the
first one is processed and others MUST be ignored.The Central Control Instructions (CCI) Object is used by the PCE to
specify the forwarding instructions is defined in . Further
defined
a CCI object type for SR.The Path Segment information is encoded directly in the CCI SR
object. The Path Segment TLV as described in the , MUST also be included in the CCI SR object as
the TLV (as it includes additional information regarding the Path
Segment identifier).This document adds the following flags to the CCI Object: C (PCC Allocation bit): If the bit is set to 1, it indicates
that the allocation needs to be done by the PCC for this central
controller instruction. A PCE set this bit to request the PCC to
make an allocation from its SR label space. A PCC would set this
bit to indicate that it has allocated the CC-ID and report it to
the PCE.(Editor's Note - An update is planned for in the next
revision detailing this procedure, and the above text might move
there.)The Path Segment allocation and encoding is as per the stateful PCE
operations for segment routing. The procedures are as per the
corresponding extensions defined in and (which are further based on
and ). The additional
operations for Path Segment are defined in this section.To notify (or request) the Path Segment to the Egress PCC, the
procedures are as per the PCECC-SR (which is based
on ). The
additional operations are defined in this section.As defined in , a
Path Segment can be allocated by the egress PCC. In this case, the
label space is maintained on the PCC itself.This section describes the mechanism of Path Segment allocation by
using PCInitiate and PCUpd message in Stateful PCE model.The ingress PCC could request the Path Segment to be allocated by
the PCE via PCRpt message. The delegate flag (D-flag) MUST also be
set for this LSP. Also, the P-flag in the LSP object MUST be
set.On receiving a stateful path computation request with Path
Segment allocation request from an ingress PCC, a stateful PCE
requests the egress PCC to allocate a Path Segment.The PATH-SEGMENT TLV MUST be included in an LSP object in the
PCInitiate message sent from the PCE to the egress to request Path
Segment allocation by the egress PCC. The P flag in LSP object MUST
be set to 0. This PCInitiate message to egress PCC would be the
similar to the one sent to ingress PCC as per , but the egress PCC would
only allocate the Path Segment and would not trigger the
initiation/update operation.If the value of Path Segment is 0x0 it indicates that the PCE is
requesting a Path Segment for this LSP. If the Path Segment is set
to a value 'n' and the P flag is unset in the LSP object, it
indicates that the PCE requests a specific value 'n' of Path
Segment. If the Path Segment is allocated successfully, the egress
PCC reports the Path Segment via PCRpt message with PATH-SEGMENT TLV
in LSP object. Else, it MUST send a PCErr message with Error-Type =
TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If
the value of Path Segment is valid, but the PCC is unable to
allocate the Path Segment, it MUST send a PCErr message with
Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2
("Unable to allocate the specified label/SID").Once the PCE receives the PCRpt message, it can obtain the Path
Segment information from the egress PCC and then update the path
with Path Segment by sending PCUpd message.If the Path Segment is updated successfully, the ingress PCC will
acknowledge with a PCRpt message to the PCE. In case of error, as
described in , an PCErr
message with Error-Type = TBA7 ("Path SID failure") and Error Value
= 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST roll
back the Path Segment vlaue to the previous value by sending a PCUpd
message to synchronize with the egress PCC.If the ingress PCC wishes to withdraw or modify a previously
reported Path Segment value, it MUST send a PCRpt message without
any PATH-SEGMENT TLV or with the PATH-SEGMENT TLV containing the new
Path Segment respectively. In this case, the PCE should synchronize
with egresss PCC via PCUpd message.The Path Segment MUST be withdrawn when the corresponding LSP is
removed. When the LSP is deleted, the PCE MUST request the egress
PCC to withdraw the LSP and associated Path Segment via PCInitiate
message with the R flag is set in the SRP object.If an egress PCC receives a valid Path Segment value from a PCE
which is different than the current Path Segment, it MUST try to
allocate the new value. If the new Path Segment is successfully
allocated, the egress PCC MUST report the new value to the PCE.
Otherwise, it MUST send a PCErr message with Error-Type = TBA7
("Path label/SID failure") and Error Value = 2 ("Unable to allocate
the specified label/SID").A stateful PCE also can initiate or update an LSP with Path
Segment actively via requesting the egress PCC to allocate a Path
Segment.If a PCE wishes to modify a previously requested Path Segment
value or allocate a Path Segment for an PCE-Initiated LSP, it MUST
request the egress PCC to allocate a new value by sending a PCUpd
message to the egress PCC with PATH-SEGMENT TLV containing the new
Path Segment value. Also, the P flag in LSP object is unset. Absence
of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes
to withdraw the Path Segment.The mechanism of requesting Path Segment is as per .Once the PCE receives the PCRpt message, it can obtain the Path
Segment information from the egress PCC and then update or initiate
an LSP with Path Segment.If the SR-Path is setup, the ingress PCC will acknowledge with a
PCRpt message to the PCE. In case of error, as described in , an PCErr message will be
sent back to the PCE. The PCE MUST request the egress PCC to
withdraw the LSP and associated Path Segment via PCInitiate message
with the R flag is set in the SRP object.If the Path Segment is updated successfully, the ingress PCC will
acknowledge with a PCRpt message to the PCE. In case of error, an
PCErr message with Error-Type = TBA7 ("Path SID failure") and Error
Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST
roll back the Path Segment vlaue to the previous value by sending a
PCUpd message to synchronize with the egress PCC.For allocating the Path Segments to SR paths by the PCEs, the PCE
controlled label space MUST be known at PCEs via configurations or
any other mechanisms. The PCE controlled label spaces MAY be
advertised as described in .The PCE could allocate the Path Segment on its own for a
PCE-Initiated (or delegated LSP). The allocated Path Segment needs
to be informed to the Ingress and Egress PCC. The PCE would use
the PCInitiate message or PCUpd message
towards the Ingress PCC and MUST include
the PATH-SEGMENT TLV in the LSP object. The PCE would further
inform the egress PCC about the Path Segment allocated by the PCE
using the PCInitiate message as described in .The ingress PCC could request the Path Segment to be allocated
by the PCE via PCRpt message as per . The
delegate flag (D-flag) MUST also be set for this LSP. Also, the
P-flag in the LSP object MUST be set.A PATH-SEGMENT TLV MUST be included in the LSP object. If the
value of Path Segment is 0x0, it indicates that the Ingress PCC is
requesting a Path Segment for this LSP. If the Path Segment is set
to a value 'n', it indicates that the ingress PCC requests a
specific value 'n' of Path Segment.If the Path Segment is allocated successfully, the PCE would
further respond to Ingress PCC with PCUpd message as per and MUST include the PATH-SEGMENT TLV in a LSP
object. Else, it MUST send a PCErr message with Error-Type = TBA7
("Path SID failure") and Error Value = 1 ("Invalid SID"). If the
value of Path Segment is valid, but the PCC is unable to allocate
the Path Segment, it MUST send a PCErr message with Error-Type =
TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to
allocate the specified label/SID").The active PCE would allocate the Path Segment as per the
PATH-SEGMENT flags and in case PATH-SEGMENT is not included, the
PCE MUST act based on the local policy.The PCE would further inform the egress PCC about the Path
Segment allocated by the PCE using the PCInitiate message as
described in .As described in ,
in an SR-MPLS network, when a packet is transmitted along an SR path,
the labels in the MPLS label stack will be swapped or popped. So that no
label or only the last label may be left in the MPLS label stack when
the packet reaches the egress node. Thus, the egress node cannot
determine from which SR path the packet comes. For this reason, it
introduces the Path Segment.Apart from allocation and encoding of the Path Segment (described in
this document) for the LSP, it would also be included in the SID/Label
stack of the LSP (usually for processing by the egress). To support
this, the Path Segment MAY also be a part of SR-ERO as prepared by the
PCE as per . The PCC MAY
also include the Path Segment while preparing the label stack based on
the local policy and use-case.It is important that the PCE learns the Maximum SID Depth (MSD) that
can be imposed at each node/link of a given SR path to ensure that the
SID stack depth does not exceed the number of SIDs the node is capable
of imposing. As a new type of segment, Path Segment will be inserted in
the SID list just like other SIDs. Thus, the PCE needs to consider the
affect of Path Segment when computing a LSP with Path Segment
allocation.SR PCE Capability TLV is defined in , and the registry to manage
the Flag field of the SR PCE Capability TLV is requested in . IANA is requested to make the
following allocation in the aforementioned registry.SRv6 PCE Capability TLV is defined in defined in , and the registry to
manage the Flag field of the SRv6 PCE Capability Flags is requested in
. IANA is requested
to make the following allocation in the aforementioned registry. defines the LSP object; per that RFC, IANA
created a registry to manage the value of the LSP object's Flag field.
IANA has allocated a new bit in the "LSP Object Flag Field"
subregistry, as follows:IANA is requested to add the assignment of a new allocation in the
existing "PCEP TLV Type Indicators" subregistry as follows:This document requests that a new subregistry named "PATH-SEGMENT
TLV Segment Type (ST) Field" to be created to manage the value of
the ST field in the PATH-SEGMENT TLV.Further, this document also requests that a new subregistry named
"PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field
in the PATH-SEGMENT TLV. New values are assigned by Standards Action
. Each bit should be tracked with the
following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCCCI object is defined in defined in , further
defined
a CCI object type for SR. and the subregistry to manage the Flag field
of the CCI object for SR is requested in . IANA is
requested to make the following allocation in the aforementioned
subregistry.A new PCEP object called FEC is defined in . IANA is
requested to allocate a new Object-Type for FEC object in the "PCEP
Objects" subregistry.IANA is requested to allocate code-points in the "PCEP-ERROR Object
Error Types and Values" subregistry for the following new error-types
and error-values:TBAThe following people have substantially contributed to this
document: