PCEP Extension for
Segment Routing (SR) Bi-directional Associated PathsHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinachengli13@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095ChinaMach.chen@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.com
Routing Area
PCE Working GroupThe 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.
The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. Furthermore, PCEP can be used for computing paths in
SR networks.This document defines PCEP extensions for grouping two reverse
unidirectional SR Paths into an Associated Bidirectional SR path when
using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as
well as when using a Stateless PCE.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.Segment routing (SR)
leverages the source routing and tunneling paradigms. SR supports to
steer packets into an explicit forwarding path according to the Segment
Routing Policy ( SR Policy) at the ingress
node.However, the SR Policies defined in only supports
uni-directional SR paths. For supporting bi-directional paths , new SR policies carrying
Path ID and bi-directional path information are defined in . 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 . 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
for IPv6 data plane. introduces a generic
mechanism to create a grouping of LSPs which can then be used to define
associations between a set of LSPs and/or a set of attributes, for
example primary and secondary LSP associations, and is equally
applicable to the active and passive modes of a Stateful PCE or a stateless PCE . defines PCEP
extensions for grouping two reverse unidirectional MPLS TE LSPs into an
Associated Bidirectional LSP when using a Stateful PCE for both
PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless
PCE.This document extends the bidirectional association to segment
routing by specifying PCEP extensions for grouping two reverse
unidirectional SR paths into a bi-directional SR path. defines a procedure for
path ID in PCEP for SR by defining the PATH-ID TLV. The path ID can be a
path segment in SR-MPLS , or a path ID in SRv6
, or other IDs that
can identify an SR path. The PATH-ID MUST be included for associated
bidirectional SR paths.This memo makes use of the terms defined in . The reader is assumed to be
familiar with the terminology defined in , , , and .As per , LSPs are
associated by adding them to a common association group. specifies PCEP extensions for
grouping two reverse unidirectional MPLS-TE LSPs into an Associated
Bidirectional LSP for both single-sided and double-sided initiation
cases by defining two new Bidirectional LSP Association Groups.This document extends the procedure for SR bidirectional associated
paths by defining a new bidirectional association type (i.e.
Double-sided Bi-directional SR Path Association Group). The document
further describe the mechanism of associating two unidirectional SR path
into a bidirectional SR path. defines a procedure for path ID in
PCEP for SR by defining the PATH-ID TLV. The bidirectional SR path MUST
also use the PATH-ID TLV.As defined in , two
LSPs are associated as a bi-directional MPLS-TE LSP by a common
bi-directional LSP association group. For associating two SR paths,
this document defines a new association group called 'Double-sided
Bidirectional SR Path Association Group' as follows: Association Type (TBD) = Double-sided Bidirectional SR Path
Association GroupSimilar to other bidirectional associations, this Association Type
is operator-configured in nature and statically created by the
operator on the PCEP peers. The paths belonging to this association is
conveyed via PCEP messages to the PCEP peer. Operator-configured
Association Range TLV
MUST NOT be sent for these Association Types, and MUST be ignored, so
that the entire range of association ID can be used for them. The
handling of the Association ID, Association Source, optional Global
Association Source and optional Extended Association ID in this
association are set in the same way as .A member of the Double-sided Bi-directional SR Path Association
Group can take the role of a forward or reverse SR path and follows
the rules similar to the rules defined in for LSPs.An SR path (forward or reverse) can not be part of more than
one Double-sided Bi-directional SR Path Association Group.The endpoints of the SR paths in this associations cannot be
different.For describing the SR paths in this association group, such as
direction and co-routed information, this association group reuses the
Bi-directional LSP Association Group TLV defined in . All fields and processing
rules are as per .As defined in , the B-flag in RP object MUST
be set when the PCC specifies that the path computation request relates
to a bi-directional TE LSP. In this document, the B-flag also MUST be
set when the PCC specifies that the path computation request relates to
a bi-directional SR path. Likely, when a stateful PCE initiates or
updates a bi-directional SR paths including LSPs and SR paths, the
B-flag in SRP object MUST be set as well.Two uni-directional SR paths can be associated by the association
group object as specified in . A bidirectional LSP
association group object is defined in (for MPLS-TE). This documents
extends the mechanism for bidirectional SR paths. Two SR paths can be
associated together by including the Bi-directional SR Path Association
Group in the PCEP messages. The PATH-ID TLV MUST also be included in the LSP
object for these SR paths.There is also a need to include the reverse direction path in the
PCEP messages, to do this the PCE SHOULD inform the reverse SR path to
the ingress PCC and vice versa. To achieve this a PCInitiate message for
the reverse SR path is sent to the ingress PCC and a PCInitiate message
for the forward SR path is sent to the egress PCC (with the same
association group). These PCInitiate message MUST not trigger initiation
of SR paths. The information of reverse direction path can be used for
several scenarios, such as directed BFD .As specified in
Bidirectional SR Association Group can be created by a Stateful
PCE.Stateful PCE can create and update the forward and reverse SR
path independently for Double-sided Bi-directional SR Path
Association Groups.Stateful PCE can establish and remove the association
relationship on a per SR path basis.Stateful PCE can create and update the SR path and the
association on a PCC via PCInitiate and PCUpd messages,
respectively, using the procedures described in .The Path-ID TLV MUST be included for each SR path in the LSP
object.The opposite direction SR path (LSP2(R) at S, LSP1(F) at D )
SHOULD be informed via PCInitiate message with the matching
association group.As specified in
Bidirectional SR Association Group can also be created by a PCC.PCC can create and update the forward and reverse SR paths
independently for Double-sided Bi-directional SR Path Association
Groups.PCC can establish and remove the association relationship on a
per SR path basis.PCC MUST report the change in the association group of an SR
path to PCE(s) via PCRpt message.PCC can report the forward and reverse SR paths independently
to PCE(s) via PCRpt message.PCC can delegate the forward and reverse SR paths independently
to a Stateful PCE, where PCE would control the SR paths.Stateful PCE can update the SR paths in the Double-sided
Bi-directional SR Path Association Group via PCUpd message, using
the procedures described in .The Path-ID TLV MUST be handled as defined in .The opposite direction SR path (LSP2(R) at S, LSP1(F) at D )
SHOULD be informed via PCInitiate message with the matching
association group.As defined in , for
a stateless PCE, it might be useful to associate a path computation
request to an association group, thus enabling it to associate a
common set of configuration parameters or behaviors with the request.
A PCC can request co-routed or non co-routed forward and reverse
direction paths from a stateless PCE for a bidirectional LSP
association group.The error handling as described in continue to apply.TBATBA