PCEP
Extensions for Segment Routing leveraging the IPv6 data planeHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiamahendrasingh@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiaprejeeth.k@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comCisco Systemsmsiva@cisco.com
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.
Segment Routing (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 Interior Gateway Protocols (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, Segment Routing 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 draft describes the
extensions required for Segment Routing support for IPv6
data plane in PCEP.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,
Locators, 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 is 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 an and
provisioned on the ingress node. describes Path Computation Element Protocol
(PCEP) for communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE) or between one 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 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
.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 of IPv6 SID
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". defined
a new 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 extends the "SR-ERO subobject" defined in
to carry IPv6 SID(s)
(IPv6 Addresses). SRv6-capable PCEP speakers should 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 new path setup type
carried in the PATH-SETUP-TYPE TLV for SRv6 path.In summary, this document:Defines a new PCEP capability for SRv6Update the SR-ERO and SR-RRO sub-object for SRv6Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
for SR-TE LSP.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 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 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. In other words, a PCEP speaker MUST NOT infer whether or
not a PCEP message pertains to SRv6 from any other object or
TLV.This document defines a new optional TLV for use in the OPEN Object.The SRv6-PCE-CAPABILITY TLV is an optional TLV
associated with the OPEN Object to exchange SRv6 capability
of PCEP speakers. The format of the
SR-PCE-CAPABILITY TLV is shown in the following figure:The code point for the TLV type is to be defined by
IANA. The TLV length is 4 octets.The 4-octet value comprise of -
max-SL: 1 octet, this field specifies the maximum value of the "Segments Left (SL)" in the SRH .Reserved: 1 octet, this field MUST be set to 0 on transmission, and ignored on receipt.Flags: 2 octet, one flag is currently defined in this document.
L bit: A PCC sets this bit to 1 to indicate that it does not impose any limit on SL.By including the SRv6-PCE-CAPABILITY TLV in the OPEN message destined
to a PCE, a PCC indicates that it is capable of supporting the head-
end functions for SRv6. By including the TLV in the OPEN
message destined to a PCC, a PCE indicates that it is capable of
computing SRv6 paths.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) for SRv6 as follows:o PST = TBD2: Path is setup using SRv6
technique.In order to support SRv6, the SR-ERO subobject is
used . All other
processing rules remains the same.For supporting SRv6, a new SID Type (ST) is defined, the format of
SR-ERO sub object remains the same as defined in .When the SID Type (ST) indicates SRv6, then the
SR-ERO subobject represent a SRv6 segment and include a field
SRv6I (SRv6 Identifier) in place of NAI (Node or Adjacency Identifier) defined in .
The 32 bit SID MUST be set to zero on transit and ignored
on receipt. The format of SR-ERO subobject is reproduced with the SRv6I field as shown below:The description of all the flags and fields is as per .For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD.For SRv6 segments (when ST is TBD), M and C flag MUST NOT be set. The S flag MUST be set and SID field MUST be set to 0.
The F bit MUST NOT be set. The Length is 28.The SRv6I format is as shown below:SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 segment.SRv6ST is the SRv6 SID Type which indicates the interpretation for NAI (Node or Adjacency Identifier) as per .Flags is the 12 bit field, no flag bits are currently defined in this document.Function Code is is the 16 bit field representing supported functions.
associated with SRv6 SIDs. See . Following function codes are currently defined -
0: Reserved1: End Function2: End.DX6 Function3: End.DT6 Function4: End.X FunctionNAI field contains the NAI associated with the SRv6 Identifier. Depending on the value of SRv6ST,
the NAI can have different formats.
When SRv6ST value is 1, the NAI is as per the 'IPv6 Node ID' format defined in , which specify an IPv6 address. This is used to
identify the owner of the SRv6 Identifier.When SRv6ST value is 2, 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.Note that when SRv6ST value is 0, NAI is not included and MUST be NULL. The ERO and SR-ERO subobject processing remains
as per and . The ST MUST only be TDB, if the SRv6-PCE-CAPABILITY TLV is exchanged with the PCEP peer.
In case a PCEP speaker receives the SR-ERO subobject with ST indicating SRv6 segment, when the SRv6-PCE-CAPABILITY TLV
was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and
Error-Value = TBD3 ("Attempted SRv6 when the capability was not advertised").
A PCEP speaker that does not recognize the ST value, it would behave as per . [Editor's Note - this is missing from .] If a PCC receives a list of SRv6 segments, and the number of
SRv6 segments exceeds the max-SL that the PCC can impose on
the packet (SRH), it MAY 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
identical to SRv6, 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
.When a PCEP speaker receives an SR-ERO subobject for SRv6 segment,
M, C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it MUST
consider the entire ERO object invalid and send a PCErr message with
Error-Type = 10 ("Reception of an invalid object") and Error-Value =
TBD ("Malformed object") as per . The PCEP speaker MAY include the malformed
SR-ERO object in the PCErr message as well. In order to support SRv6, the SR-ERO Subobject is
used . All other
processing rules remains the same.For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD, the format of
SR-ERO sub object remains the same as defined in .When the SID Type (ST) indicates SRv6, then the
SR-RRO subobject represent a SRv6 segment and include a field
SRv6I (SRv6 Identifier) in place of NAI (Node or Adjacency Identifier) defined in .
The 32 bit SID MUST be set to zero on transit and ignored
on receipt. The format of SR-RRO subobject is reproduced with the SRv6I field as shown below:The description of all fields and flags is as per SR-ERO subobject.Processing rules of SR-RRO subobject are identical to those of SR-ERO
subobject.The security considerations described in , and
are
applicable to this specification. No additional security
measure is required.This document requests IANA to include (I) bit in flags
registry for SR-ERO and SR-RRO sub-objects. Other changes are
defined as:IANA is requested to allocate code-points in the PCEP-ERROR Object
Error Types and Values registry for the following new error-values:IANA is requested to make the assignment of the new code points for
the existing "PCEP TLV Type Indicators" registry as follows:defines
the PATH-SETUP-TYPE TLV and requests that IANA creates
a registry to manage the value of the PATH-SETUP-TYPE
TLV's PST field. IANA is requested to allocate a new
code point in the PCEP PATH_SETUP_TYPE TLV PST field
registry, as follows:The following persons contributed to this document: