PCEP
Extensions for Segment Routing leveraging the IPv6 data planeRtBrick IndiaN-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3BangaloreKarnataka560102Indiamahend.ietf@gmail.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinachengli13@huawei.comCisco Systemsmsiva@cisco.comRtBrick IncBangaloreKarnatakaIndiaprejeeth@rtbrick.comChina Telecom109 West Zhongshan Ave, Tianhe DistrictBangaloreGuangzhouP.R. Chinazhuyq.gd@chinatelecom.cn
Routing
PCE Working GroupThe 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.
SR enables any head-end node to select
any path without relying on a hop-by-hop signaling technique
(e.g., LDP or RSVP-TE).It depends only on "segments" that are advertised by Link-
State IGPs. 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).Since SR can be applied to both MPLS and IPv6
forwarding plane, a PCE should be able to compute SR-Path for
both MPLS and IPv6 forwarding plane. This document describes the
extensions required for SR support for IPv6
data plane in Path Computation Element communication Protocol (PCEP).
The PCEP extension and mechanism to support SR-MPLS is described
in RFC 8664. This document extends it to support SRv6 (SR over IPv6).
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.
As per ,
with Segment Routing (SR), a node steers a packet through an ordered
list of instructions, called segments. A segment can represent any
instruction, topological or service-based. A segment can have a
semantic local to an SR node or global within an SR domain. SR
allows to enforce a flow through any path and service chain while
maintaining per-flow state only at the ingress node of the SR domain.
Segments can be
derived from different components: IGP, BGP, Services, Contexts,
Locater, etc. The list of segment forming the path is called the
Segment List and is encoded in the packet header.
Segment Routing can be applied to the IPv6 architecture
with the Segment Routing Header (SRH) .
A segment is encoded as an IPv6
address. An ordered list of segments is encoded as an ordered list
of IPv6 addresses in the routing header. The active segment is
indicated by the Destination Address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and
indicates the next segment. Segment Routing use cases are described in and
.
Segment Routing protocol extensions are defined in
, and
.As per ,
an SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are
often used as a shorter reference for "SRv6 Segment". Further details
are in an illustration provided in
.The SR architecture can be applied to the MPLS forwarding
plane without any change, in which case an SR path
corresponds to an MPLS Label Switching Path (LSP). The SR is
applied to IPV6 forwarding plane using SRH.
A SR path can be derived from an IGP Shortest Path Tree (SPT),
but SR-TE paths may not follow IGP SPT. Such paths may be
chosen by a suitable network planning tool, or a PCE and
provisioned on the ingress node. describes Path Computation Element communication Protocol
(PCEP) for communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE) or between a
pair of PCEs. A PCE or a PCC operating as a PCE (in
hierarchical PCE environment) computes paths for MPLS Traffic
Engineering LSPs (MPLS-TE LSPs) based on various constraints
and optimization criteria.
specifies extensions to PCEP that allow a stateful PCE to
compute and recommend network paths in compliance with
and defines objects and TLVs for MPLS-TE LSPs.
Stateful PCEP extensions provide synchronization of LSP state
between a PCC and a PCE or between a pair of PCEs, delegation
of LSP control, reporting of LSP state from a PCC to a PCE,
controlling the setup and path routing of an LSP from a PCE
to a PCC. Stateful PCEP extensions are intended for an
operational model in which LSPs are configured on the PCC,
and control over them is delegated to the PCE.A mechanism to dynamically initiate LSPs on a PCC based on the
requests from a stateful PCE or a controller using stateful PCE is
specified in . As per
, it is possible to use a stateful PCE for computing one or more SR-TE
paths taking into account various constraints and objective
functions. Once a path is chosen, the stateful PCE can initiate an
SR-TE path on a PCC using PCEP extensions specified in
using the SR specific PCEP
extensions specified in .
specifies PCEP
extensions for supporting a SR-TE LSP for MPLS data
plane. This document extends
to support SR for IPv6 data plane. Additionally, using
procedures described in this document, a PCC can request an SRv6 path
from either stateful or a stateless PCE. This specification relies
on the PATH-SETUP-TYPE TLV and procedures specified in
.This specification provides a mechanism for a network controller
(acting as a PCE) to instantiate candidate paths for an SR Policy
onto a head-end node (acting as a PCC) using PCEP. For more
information on the SR Policy Architecture, see
.This document uses the following terms defined in
: PCC, PCE, PCEP Peer.This document uses the following terms defined in
: Stateful PCE, Delegation.The message formats in this document are specified using
Routing Backus-Naur Format (RBNF) encoding as specified in
.Node or Adjacency Identifier.Path Computation Client.Path Computation Element.Path Computation Element
Protocol.Segment Routing.Segment Identifier.Segment Routing for IPv6
forwarding plane.IPv6 Segment Routing Header.IPv6 Segment List (List of IPv6 SIDs
representing a path in IPv6 SR domain)Basic operations for PCEP speakers is as per
. SRv6 Paths computed by a
PCE can be represented as an ordered list of SRv6 segments of 128-bit
value. "SRv6 SID" or simply "SID" are often used as a shorter reference
for "SRv6 Segment" in this document. defined
a new Explicit Route Object (ERO) subobject denoted by "SR-ERO subobject" capable of
carrying a SID as well as the identity of the node/adjacency
represented by the SID. SR-capable PCEP speakers
should be able to generate and/or process such ERO subobject. An ERO
containing SR-ERO subobjects can be included in the PCEP Path
Computation Reply (PCRep) message defined in , the PCEP LSP
Initiate Request message (PCInitiate) defined in
, as well as in the PCEP LSP Update
Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
defined in .This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO and RRO respectively
to carry SRv6 SID (IPv6 Address). SRv6-capable PCEP speakers MUST be able to generate and/or process this.When a PCEP session between a PCC and a PCE is
established, both PCEP speakers exchange their capabilities to
indicate their ability to support SRv6 specific
functionality.In summary, this document:Defines a new PCEP capability for SRv6.Defines a new subobject SRv6-ERO in ERO.Defines a new subobject SRv6-RRO in RRO.Defines a new path setup type carried in the PATH-SETUP-TYPE
and PATH-SETUP-TYPE-CAPABILITY TLVs.In SR networks, an ingress node of an SR path appends
all outgoing packets with an SR header consisting of a list
of SIDs (IPv6
Prefix in case of SRv6). The header has all necessary
information to guide the packets from the ingress node to
the egress node of the path, and hence there is no need for
any signaling protocol.For IPv6 in control plane with MPLS data-plane, mechanism remains same as
This document describes extensions to SR path for IPv6
data plane. SRv6 Path (i.e. ERO) consists of an ordered set
of SRv6 SIDs(see details in ).A PCC or PCE indicates its ability to support SRv6
during the PCEP session Initialization Phase via a
new SRv6-PCE-CAPABILITY sub-TLV (see details in
).
As defined in , a PCEP message consists of a common header
followed by a variable length body made up of mandatory and/or
optional objects. This document does not require any changes in the
format of PCReq and PCRep messages specified in , PCInitiate
message specified in , and PCRpt and
PCUpd messages specified in . However,
PCEP messages pertaining to SRv6 MUST include PATH-SETUP-TYPE
TLV in the RP or SRP object to clearly identify that SRv6 is
intended. This document defines a new Path Setup Type (PST) for SRv6, as follows:PST = TBD2: Path is setup using SRv6.A PCEP speaker MUST indicate its support of the function described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list.This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP
speakers use this sub-TLV to exchange information about their SRv6
capability. If a PCEP speaker includes PST=TBD2 in the PST List of the
PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the following
figure:The code point for the TLV type (TBD1) is to be defined by
IANA. The TLV length is variable.The value comprises of -
Reserved: 2 octet, this field MUST be set to 0 on transmission, and ignored on receipt.Flags: 2 octet, two bits are currently assigned in this document.
N bit: A PCC sets this flag bit to 1 to indicate that it is capable
of resolving a Node or Adjacency Identifier (NAI) to a SRv6-SID.X bit: A PCC sets this bit to 1 to indicate that it does not impose any limit on MSD (irrespective of the MSD-Type).Unassigned bits MUST be set to 0 and ignored on receipt.A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as per the IGP MSD Type registry created by and populated with SRv6 MSD types as per ; MSD-Value (1 octet) is as per .This TLV format is compliant with the PCEP TLV format defined
in . That is, the TLV is composed of 2 octets for the type,
2 octets specifying the TLV length, and a Value field. The Length
field defines the length of the value portion in octets. The TLV is
padded to 4-octet alignment, and padding is not included in the
Length field. The number of (MSD-Type,MSD-Value) pairs can be determined from the Length field of the TLV.In order to indicate the SRv6 path, RP or SRP
object MUST include the PATH-SETUP-TYPE TLV specified in
. This document defines a new
Path Setup Type (PST=TBD2) for SRv6.The LSP-IDENTIFIERS TLV MAY be present for the above PST type.In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO.An SRv6-ERO subobject is formatted as shown in the following figure.The fields in the SRv6-ERO Subobject are as follows:The 'L' Flag: Indicates whether the subobject represents a loose-hop
(see ). If this flag is set to zero, a PCC MUST NOT
overwrite the SID value present in the SRv6-ERO subobject.
Otherwise, a PCC MAY expand or replace one or more SID values in
the received SRv6-ERO based on its local policy.Type: Set to TBD3.Length: Contains the total length of the subobject in octets. The
Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO
subobject MUST contain at least one of a SRv6-SID or an NAI. The S and F bit in the Flags
field indicates whether the SRv6-SID or NAI fields are absent.NAI Type (NT): Indicates the type and format of the NAI contained in
the object body, if any is present. If the F bit is set to zero
(see below) then the NT field has no meaning and MUST be ignored
by the receiver. This document reuses NT types defined in :
If NT value is 0, the NAI MUST NOT be included.When NT value is 2, the NAI is as per the 'IPv6 Node ID' format defined in , which specifies an IPv6 address. This is used to
identify the owner of the SRv6 Identifier. This is optional, as the LOC (the locater portion) of the SRv6 SID serves a similar purpose (when present).When NT value is 3, the NAI is as per the 'IPv6 Adjacency' format defined in , which specify a pair of IPv6 addresses. This is used to identify the IPv6 Adjacency and used with the SRv6 Adj-SID.When NT value is 6, the NAI is as per the 'link-local IPv6 addresses' format defined in , which specify a pair of (global IPv6
address, interface ID) tuples. It is used to identify the IPv6 Adjacency and used with the SRv6 Adj-SID.SR-MPLS specific NT types are not valid in SRv6-ERO.Flags: Used to carry additional information pertaining to the SRv6-SID.
This document defines the following flag bits. The other bits
MUST be set to zero by the sender and MUST be ignored by the
receiver.
S: When this bit is set to 1, the SRv6-SID value in the subobject
body is absent. In this case, the PCC is responsible for
choosing the SRv6-SID value, e.g., by looking up in the SR-DB using
the NAI which, in this case, MUST be present in the subobject.
If the S bit is set to 1 then F bit MUST be set to zero.
F: When this bit is set to 1, the NAI value in the subobject
body is absent. The F bit MUST be set to 1 if NT=0, and
otherwise MUST be set to zero. The S and F bits MUST NOT both
be set to 1.
Function Behavior: A 16 bit field representing supported functions associated with SRv6 SIDs. This information is optional and plays no role in the SRH imposed on the packet.
It could be included for maintainability and diagnostic purpose.
If function code is not defined, 0 is used.
Functions codes are defined in .SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing the SRv6 segment.NAI: The NAI associated with the SRv6-SID. The NAI's format depends on
the value in the NT field, and is described in .At least one of the SRv6-SID or the NAI MUST be included in the SRv6-ERO
subobject, and both MAY be included.In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO.A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per
. The RRO on this message represents the SID list that was
applied by the PCC, that is, the actual path taken. The
procedures of with respect to the RRO apply equally to this
specification without change.An RRO contains one or more subobjects called "SRv6-RRO subobjects"
whose format is shown below:The format of the SRv6-RRO subobject is the same as that of the SRv6-ERO
subobject, but without the L flag.Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as per .A PCC indicates that it is capable of supporting the head-end
functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in
the Open message that it sends to a PCE. A PCE indicates that it is
capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY
sub-TLV in the Open message that it sends to a PCC.If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be
assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then
close the PCEP session. If a PCEP speaker receives a PATH-SETUP-
TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST
list does not contain PST=TBD2, then the PCEP speaker MUST ignore the
SRv6-PCE-CAPABILITY sub-TLV.The number of SRv6 SIDs that can be imposed on a packet depends on the
PCC's IPv6 data plane's capability. If a PCC sets the X flag to 1 then
the MSD is not used and MUST NOT be included. If a PCE receives an
SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then it MUST
ignore any MSD-Type, MSD-Value fields and MUST assume that the sender can impose
any length of SRH. If a PCC sets the X flag to zero, then it sets
the SRv6 MSD-Type, MSD-Value fields that it can impose on a
packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the X
flag and SRv6 MSD-Type, MSD-Value fields both set to zero then it is considered as an error and
the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message.").
In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message.").Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE-CAPABILITY sub-TLV
indicates the SRv6 SID imposition limit for the PCC node. However,
if a PCE learns these via different means, e.g
routing protocols, as specified in:
;
;
, then it ignores the
values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE
learns the other advanced SRv6 MSD via different means, it MUST use that value
regardless of the values exchanged in the SRv6-PCE-CAPABILITY sub-TLV.Once an SRv6-capable PCEP session is established with a non-zero SRv6 MSD
value, the corresponding PCE MUST NOT send SRv6 paths with a number
of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD Type).
If a PCC needs to modify the SRv6 MSD
value, it MUST close the PCEP session and re-establish it with the
new value. If a PCEP session is established with a non-zero SRv6 MSD
value, and the PCC receives an SRv6 path containing more SIDs than
specified in the SRv6 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr message with
Error-Type 10 (Reception of an invalid object) and Error-Value 3
(Unsupported number of Segment ERO subobjects). If a PCEP session is
established with an SRv6 MSD value of zero, then the PCC MAY specify an
SRv6 MSD for each path computation request that it sends to the PCE, by
including a "maximum SID depth" metric object on the request similar
to .The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILITY sub-TLV are
meaningful only in the Open message sent from a PCC to a PCE. As
such, a PCE MUST set the flags to zero and not include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub-TLV in an outbound
message to a PCC. Similarly, a PCC MUST ignore N,X flag and any (MSD-Type,MSD-Value) pair
received from a PCE. If a PCE receives multiple SRv6-PCE-CAPABILITY
sub-TLVs in an Open message, it processes only the first sub-TLV
received.The ERO processing remains as per and .If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond according to the rules for a malformed object per .On receiving an SRv6-ERO, a PCC MUST validate that the Length field,
the S bit, the F bit and the NT field are consistent, as follows.If NT=0, the F bit MUST be 1, the S bit MUST be zero and the Length MUST be 24.If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24, otherwise the Length MUST be 40.If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 40, otherwise the Length MUST be 56.If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 48, otherwise the Length MUST be 64.NT types (1,3, and 5) are not valid for SRv6.If a PCC finds that the NT field, Length field, S bit and F bit are not consistent, it MUST consider the entire ERO invalid and MUST send
a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object").If a PCEP speaker that does not recognize the NT value received in SRv6-ERO subobject, it would behave as per . In case a PCEP speaker receives the SRv6-ERO subobject, when the PST is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV
was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and
Error-Value = TBD5 ("Attempted SRv6 when the capability was not advertised"). If a PCC receives a list of SRv6 segments, and the number of SRv6 segments exceeds the SRv6 MSD that the PCC can impose on
the packet (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD
("Unsupported number of Segment ERO subobjects") as per .When a PCEP speaker detects that all subobjects of ERO are not of type TBD3, and if it does not handle such ERO, it MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD ("Non-identical ERO subobjects")as per .The SRv6-ERO contains a sequence of subobjects. According to
, each SRv6-ERO subobject in the sequence identifies a segment that the traffic will be directed
to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second SRv6-ERO
subobject represents the second segment, and so on.The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus a next hop. The PCC sends packets along the segment routed path
by prepending the SRH onto the packets and sending the resulting, modified packet to the next hop.The syntax checking rules that apply to the SRv6-RRO subobject are identical to those of the SRv6-ERO subobject, except as noted below.If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 SID and NAI are absent, it MUST consider the entire RRO invalid and send a
PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD6 ("Both SID and NAI are absent in SRv6-RRO subobject").If a PCE detects that the subobjects of an RRO are a mixture of SRv6-RRO subobjects and subobjects of other types, then it MUST send a
PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with other subobject types").The security considerations described in , and
, , are
applicable to this specification. No additional security
measure is required.This document defines a new subobject type for the PCEP explicit
route object (ERO), and a new subobject type for the PCEP record
route object (RRO). The code points for subobject types of these
objects is maintained in the RSVP parameters registry, under the
EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to
allocate code-points in the RSVP
Parameters registry for each of the new subobject types defined in
this document. IANA is requested to create a new sub-registry, named "SRv6-ERO Flag
Field", within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the Flag field of the SRv6-ERO subobject. New
values are to be 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 RFCThe following values are defined in this document:IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the
type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY
TLV. IANA is requested to make the following assignment:IANA is requested to create a new sub-registry, named "SRv6 Capability
Flag Field", within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Flag field of the SRv6-PCE-CAPABILITY
sub-TLV. New values are to be 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 RFCThe following values are defined in this document: created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry,
as follows:IANA is requested to allocate code-points in the PCEP-ERROR Object
Error Types and Values registry for the following new error-values:The authors would like to thank Jeff Tentsura, Adrian Farrel and Khasanov Boris for valuable suggestions.The following persons contributed to this document: