PCEP Extensions for Signaling Multipath InformationCisco Systems, Inc.mkoldych@cisco.comCiena Corporationssivabal@ciena.comJuniper Networks, Inc.tsaad@juniper.netJuniper Networks, Inc.vbeeram@juniper.netNokiahooman.bidgoli@nokia.comCienabyadav@ciena.comHuawei Technologiespengshuping@huawei.comVerizon Inc.gyan.s.mishra@verizon.com
Routing
PCE Working GroupPath computation algorithms are not limited to return a single optimal path.
Multiple paths may exist that satisfy the given objectives and constraints.
This document defines a mechanism to encode multiple paths for a single set of
objectives and constraints.
This is a generic PCEP mechanism, not specific to
any path setup type or dataplane.
The mechanism is applicable to both stateless and stateful PCEP.Path Computation Element (PCE) Communication Protocol (PCEP)
enables the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between two PCEs based on
the PCE architecture .PCEP Extensions for the Stateful PCE Model describes a set
of extensions to PCEP that enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
tunnels. describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for dynamic centralized
control of a network.PCEP Extensions for Segment Routing
specifies extensions to the Path Computation Element Protocol (PCEP)
that allow a stateful PCE to compute and initiate Traffic Engineering
(TE) paths, as well as for a PCC to request a path subject to certain
constraint(s) and optimization criteria in SR networks.Segment Routing Policy for Traffic Engineering
details the concepts of SR
Policy and approaches to steering traffic into an SR Policy. In
particular, it describes the SR candidate-path as a collection of one
or more Segment-Lists. The current PCEP standards only allow for
signaling of one Segment-List per Candidate-Path. PCEP extension to
support Segment Routing Policy Candidate Paths
specifically avoids
defining how to signal multipath information, and states that this
will be defined in another document.This document defines the required extensions that allow the signaling
of multipath information via 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.The following terms are used in this document:PCEP Tunnel:The object identified by the PLSP-ID, see for more details.This extension is motivated by the use-cases described below.The Candidate-Path of an SR Policy is the unit of report/update in PCEP, see
. Each Candidate-Path can
contain multiple Segment-Lists and each Segment-List is encoded by
one ERO. However, each PCEP LSP can contain only a
single ERO, which prevents us from encoding multiple Segment-
Lists within the same SR Candidate-Path.With the help of the protocol extensions defined in this document,
this limitation is overcome.A PCC may request a path with 80 Gbps of bandwidth, but all links in the
network have only 50 Gbps capacity. The PCE can return two paths, that can
together carry 80 Gbps. The PCC can then equally or unequally split the incoming
80 Gbps of traffic among the two paths. introduces a
new TLV that carries the path weight that allows for distribution of incoming
traffic on to the multiple paths.It is desirable for the PCE to compute and signal to the PCC a backup path
that is used to protect a primary path within the multipaths in a given LSP.Note that specify the Path Protection association among LSPs. The use of with multipath is out of scope of this document and is for future study.When multipath is used, a backup path may protect one or more primary
paths. For this reason, primary and backup path identifiers are needed to
indicate which backup path(s) protect which primary path(s).
introduces a new TLV that carries the required information.Certain applications, such as Circuit Style SR Policy ,
require the head-end to know both forward and reverse paths for each of the
segment lists of an SR Policy in order to run OAM/PM/BFD protocols on each
Segment List as a separate circuit.We define the MULTIPATH-CAP TLV that MAY be present in the OPEN
object and/or the LSP object. The purpose of this TLV is two-fold:From PCC: it tells how many multipaths per PCEP Tunnel, the PCC can install in
forwarding.From PCE: it tells that the PCE supports this standard and how
many multipaths per PCEP Tunnel, the PCE can compute.Only the first instance of this TLV can be processed, subsequent
instances SHOULD be ignored. specify the usage of this TLV with Open message (within the OPEN object) and other PCEP messages (within the LSP object).Type: TBD1 for “MULTIPATH-CAP” TLV.Length: 4.Number of Multipaths: the maximum number of multipaths per PCEP
Tunnel. The value 0 indicates unlimited number.W-flag: whether MULTIPATH-WEIGHT-TLV is supported.B-flag: whether MULTIPATH-BACKUP-TLV is supported.O-flag: whether MULTIPATH-OPPDIR-PATH-TLV is supported.We define the PATH-ATTRIB object that is used to carry per-path
information and to act as a separator between several ERO/RRO objects
in the <intended-path>/<actual-path> RBNF element.
The PATH-ATTRIB object always precedes the ERO/RRO that it applies to. If
multiple ERO/RRO objects are present, then each ERO/RRO object MUST be
preceded by an PATH-ATTRIB object that describes it.The PATH-ATTRIB Object-Class value is TBD2.The PATH-ATTRIB Object-Type value is 1.O (Operational - 3 bits): operational state of the path, same
values as the identically named field in the LSP object .R (Reverse): Indicates this path is reverse,
i.e., it
originates on the Tunnel destination and terminates on the
Tunnel source (usually the PCC headend itself).
Paths with this flag set MUST NOT
be installed into forwarding, they serve only informational
purposes.Path ID: 4-octet identifier that identifies a path (encoded in the
ERO/RRO) within the set of multiple paths under the PCEP LSP.
See for details.TLVs that may be included in the PATH-ATTRIB object are described in the
following sections. Other optional TLVs could be defined by future
documents to be included within the PATH-ATTRIB object body.We define the MULTIPATH-WEIGHT TLV that MAY be present in the
PATH-ATTRIB object.Type: TBD3 for “MULTIPATH-WEIGHT” TLV.Length: 4.Weight: weight of this path within the multipath, if W-ECMP is
desired. The fraction of flows a specific ERO/RRO carries is derived
from the ratio of its weight to the sum of all other multipath ERO/RRO weights.When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object,
or the PATH-ATTRIB object is absent from the
<intended-path>/<actual-path>, then the Weight of the corresponding
path is taken to be “1”.This document introduces a new MULTIPATH-BACKUP TLV that MAY
be present in the PATH-ATTRIB object.This TLV is used to indicate the presence of a backup path that is
used for protection in case of failure of the primary path. The format of
the MULTIPATH-BACKUP TLV is:Type: TBD4 for “MULTIPATH-BACKUP” TLVLength: 4 + (N * 4) (where N is the Backup Path Count)Backup Path Count: Number of backup path(s).B: If set, indicates a pure backup path. This is a path that only
carries rerouted traffic after the protected path fails. If this flag
is not set, or if the MULTIPATH-BACKUP TLV is absent,
then the path is assumed to be primary that
carries normal traffic.Backup Path ID(s): a series of 4-octet identifier(s) that identify the
backup path(s) in the set that protect this primary path.This document introduces a new MULTIPATH-OPPDIR-PATH TLV that MAY
be present in the PATH-ATTRIB object.
This TLV encodes a many-to-many mapping between forward and reverse
paths within a PCEP Tunnel.Many-to-many mapping means that a single forward path MAY map
to multiple reverse paths and conversely that a single reverse
path MAY map to multiple forward paths.
Many-to-many mapping can happen for an SR Policy,
when a Segment List contains Node Segment(s)
which traverse parallel links at the midpoint.
The reverse of this Segment List may not be able to be expressed as a single
Reverse Segment List, but need to return multiple Reverse Segment Lists
to cover all the parallel links at the midpoint.Type: TBD9 for “MULTIPATH-OPPDIR-PATH” TLVLength: 16.N (Node co-routed): If set, indicates this path is
node co-routed with
its opposite direction path, specified in this TLV.
Two opposite direction paths are node co-routed if they
traverse the same nodes,
but MAY traverse different links.L (Link co-routed): If set, indicates this path is
link co-routed with
its opposite directions path, specified in this TLV.
Two opposite direction paths are link co-routed if they
traverse the same links (but in the opposite directions).Opposite Direction Path ID: Identifies a path that
goes in the opposite direction to this path.
If no such path exists, then this field MUST be set to 0x0,
which is reserved to indicate the absense of a Path ID.Multiple instances of this TLV
present in the same PATH-ATTRIB object indicate that there are multiple
opposite-direction paths corresponding to the given path. This allows for
many-to-many relationship among the paths of two opposite direction Tunnels.Whenever path A references another path B as being the
opposite-direction path, then path B typically also reference path A as its
own opposite-direction path.See for an example of usage.SR Policy Architecture defines the concept of a
Composite Candidate Path. Unlike a Non-Composite Candidate Path, which contains
Segment Lists, the Composite Candidate Path contains
Colors of other policies. The traffic that is steered into a Composite Candidate Path is
split among the policies that are identified by the Colors contained in
the Composite Candidate Path. The split can be either ECMP or UCMP by adjusting the
weight of each color in the Composite Candidate Path,
in the same manner as the weight of each
Segment List in the Non-Composite Candidate Path is adjusted.To signal the Composite Candidate Path, we make use of the COLOR TLV, defined in
. For a Composite Candidate Path, the COLOR TLV
is included in the PATH-ATTRIB Object, thus allowing each Composite Candidate Path
to do ECMP/UCMP among SR Policies or Tunnels identified by its constituent Colors.
Only one COLOR TLV SHOULD be included into the PATH-ATTRIB object. If multiple
COLOR TLVs are contained in the PATH-ATTRIB object, only the first one MUST be
processed and the others SHOULD be ignored.An empty ERO object MUST be included as per the existing RBNF, i.e.,
ERO MUST contain no sub-objects.
If the head-end receives a non-empty ERO,
then it MUST send PCError message with Error-Type 19 (“Invalid Operation”) and
Error-Value = TBD8 (“Non-empty path”).See for an example of the encoding.When the PCC wants to indicate to the PCE that it wants to get
multipaths for a PCEP Tunnel, instead of a single path, it can do
either (1) or both (1) and (2) of the following:(1) Send the MULTIPATH-CAP TLV in the OPEN object during session
establishment. This applies to all PCEP Tunnels on the PCC,
unless overridden by PCEP Tunnel specific information.(2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a particular
PCEP Tunnel in the PCRpt or PCReq message. This applies to the specified
PCEP Tunnel and overrides the information from the OPEN object.When PCE computes the path for a PCEP Tunnel, it MUST NOT return more
multipaths than the corresponding value of “Number of Multipaths”
from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN
and LSP objects), then the “Number of Multipaths” is assumed to be 1.If the PCE supports this standard, then it MUST include the
MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can
report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the PCE does not include
the MULTIPATH-CAP TLV in the OPEN object, then the PCC MUST assume
that the PCE does not support this standard and fall back to
reporting only a single ERO/RRO.The Path ID uniquely identifies a Path within the context of a
PCEP Tunnel.
Note that when the PCEP Tunnel is an SR Policy Candidate Path, the
Paths within that tunnel are the Segment Lists of that Candidate Path.Value 0x0 is reserved to indicate the absense of a Path ID.
The value of 0x0 MAY be used when this Path is not being referenced
and the allocation of a Path ID is not necessary.Path IDs are allocated by the PCEP peer that currently owns the Tunnel.
If the Tunnel is delegated to the PCE, then the PCE allocates the Path IDs
and sends them in the PCReply/PCUpd/PCInit messages.
If the Tunnel is locally computed on the PCC, then the PCC allocates the
Path IDs and sends them in the PCReq/PCRpt messages.If a PCEP speaker detects that there are two Paths with the same Path ID,
then the PCEP speaker SHOULD send PCError message with
Error-Type = 1 (“Reception of an invalid object”) and
Error-Value = TBD5 (“Conflicting Path ID”).The PATH-ATTRIB object can be used to signal multiple path(s) and indicate
(un)equal loadbalancing amongst the set of multipaths. In this case, the
PATH-ATTRIB is populated for each ERO as follows:The PCE assigns a unique Path ID to each ERO path and populates
it inside the PATH-ATTRIB object. The Path ID is unique within the
context of a PLSP or PCEP Tunnel.The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB object. A
weight is populated to reflect the relative loadshare that is to be
carried by the path. If the MULTIPATH-WEIGHT is not carried inside a
PATH-ATTRIB object, the default weight 1 MUST be assumed when computing
the loadshare.The fraction of flows carried by a specific primary path is derived
from the ratio of its weight to the sum of all other multipath weights.The PATH-ATTRIB object can be used to describe a set of backup path(s) protecting
a primary path within a PCEP Tunnel. In this case, the PATH-ATTRIB is populated for each ERO as
follows:The PCE assigns a unique Path ID to each ERO path and populates
it inside the PATH-ATTRIB object. The Path ID is unique within the
context of a PLSP or PCEP Tunnel.The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB object for each
ERO that is protected. The backup path ID(s) are populated in the
MULTIPATH-BACKUP TLV to reflect the set of backup path(s) protecting the
primary path. The Length field and Backup Path Number in the MULTIPATH-BACKUP
are updated according to the number of backup path ID(s) included.The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB object for each
ERO that is unprotected. In this case, MULTIPATH-BACKUP does not carry
any backup path IDs in the TLV. If the path acts as a pure backup – i.e.
the path only carries rerouted traffic after the protected path(s) fail– then
the B flag MUST be set.Note that primary paths which do not include the MULTIPATH-BACKUP TLV are assumed
to be protected by all the backup paths. I.e., omitting the TLV is equivalent to
including the TLV with all the backup path IDs filled in.Note that a given PCC may not support certain backup combinations,
such as a backup path that is itself protected by another backup path, etc.
If a PCC is not able to implement a requested backup scenario,
the PCC SHOULD send a PCError message with
Error-Type = 19 (“Invalid Operation”) and
Error-Value = TBD7 (“Not supported path backup”).The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently use a combination
of <intended-path> and/or <actual-path>.
As specified in Section 6.1 of , <intended-path> is represented by the
ERO object and <actual-path> is represented by the RRO object:In this standard, we extend these two elements to allow multiple ERO/RRO objects to be
present in the <intended-path>/<actual-path>:Consider the following sample SR Policy, taken from.As specified in , CP1 and CP2
are signaled as separate state-report elements and each has
a unique PLSP-ID, assigned by the PCC.
Let us assign PLSP-ID 100 to CP1 and PLSP-ID 200 to CP2.The state-report for CP1 can be encoded as:The state-report for CP2 can be encoded as:The above sample state-report elements only
specify the minimum mandatory objects,
of course other objects like SRP, LSPA, METRIC, etc., are allowed to be
inserted.Note that the syntax, simply means that this is PATH-ATTRIB object
with Path ID field set to “1” and
with a MULTIPATH-WEIGHT TLV carrying weight of “W1”.Suppose there are 3 paths: A, B, C.
Where A,B are primary and C is to be used only when A or B fail.
Suppose the Path IDs for A, B, C are respectively 1, 2, 3.
This would be encoded in a state-report as:Note that the syntax, simply means that this is PATH-ATTRIB object
with Path ID field set to “1” and
with a MULTIPATH-BACKUP TLV that has B-flag cleared and contains
a single backup path with Backup Path ID of 3.Consider the following Composite Candidate Path, taken from.This is signaled in PCEP as:Consider the two opposite-direction SR Policies between
end-points H1 and E1.The state-report for POL1, CP1 can be encoded as:The state-report for POL1, CP2 can be encoded as:The state-report for POL2, CP1 can be encoded as:The state-report for POL2, CP2 can be encoded as:Note to the RFC Editor - remove this section before publication, as
well as remove the reference to .This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in .
The description of implementations in this section
is intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF. Furthermore,
no effort has been spent to verify the information presented here that
was supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.According to , “this will allow reviewers and
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit”.IANA is requested to make the assignment of a new value for the
existing “PCEP Objects” registry as follows:IANA is requested to make the assignment of a new value for the
existing “PCEP TLV Type Indicators” registry as follows:IANA is requested to make the assignment of a new value for the
existing “PCEP-ERROR Object Error Types and Values” sub-registry of the
PCEP Numbers registry for the following errors:IANA is requested to create a new sub-registry to manage the Flag
field of the MULTIPATH-CAP TLV, called “Flags in MULTIPATH-CAP
TLV”.
New values are to be assigned by Standards Action IANA is requested to create a new sub-registry to manage the Flag
field of the PATH-ATTRIBUTE object,
called “Flags in PATH-ATTRIBUTE Object”.
New values are to be assigned by Standards Action IANA is requested to create a new sub-registry to manage the Flag
field of the MULTIPATH-BACKUP TLV,
called “Flags in MULTIPATH-BACKUP TLV”.
New values are to be assigned by Standards Action IANA is requested to create a new sub-registry to manage the flag
fields of the MULTIPATH-OPPDIR-PATH TLV,
called “Flags in the MULTIPATH-OPPDIR-PATH TLV”.
New values are to be assigned by Standards Action None at this time.Thanks to Dhruv Dhody for ideas and discussion.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE ModelThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.Path Computation Element Communication Protocol (PCEP) Extensions for Segment RoutingSegment 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). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.This document updates RFC 8408.Segment Routing Policy ArchitectureCisco SystemsCisco SystemsBell CanadaBritish TelecomMicrosoft Segment Routing (SR) allows a node to steer a packet flow along any
path. Intermediate per-path states are eliminated thanks to source
routing. SR Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. Packet flows
are steered into a SR Policy on a node where it is instantiated
called a headend node. The packets steered into an SR Policy carry
an ordered list of segments associated with that SR Policy.
This document updates RFC8402 as it details the concepts of SR Policy
and steering into an SR Policy.
PCEP extension to support Segment Routing Policy Candidate PathsCisco Systems, Inc.Ciena CorporationJuniper Networks, Inc.Huawei TechnologiesNokia This document introduces a mechanism to specify a Segment Routing
(SR) policy, as a collection of SR candidate paths. An SR policy is
identified by <headend, color, endpoint> tuple. An SR policy can
contain one or more candidate paths where each candidate path is
identified in PCEP by its uniquely assigned PLSP-ID. This document
proposes extension to PCEP to support association among candidate
paths of a given SR policy. The mechanism proposed in this document
is applicable to both MPLS and IPv6 data planes of SR.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.PCEP Operational ClarificationCisco Systems, Inc.Ciena CorporationHuawei TechnologiesNokiaJuniper Networks, Inc This document proposes some important simplifications to the original
PCEP protocol and also serves to clarify certain aspects of PCEP
operation. The content of this document has been compiled based on
the feedback from several multi-vendor interop exercises. Several
constructs are introduced, such as the LSP-DB and the ASSO-DB.
Circuit Style Segment Routing PoliciesCisco Systems, Inc.Cisco Systems, Inc.Cisco Systems, Inc.Cisco Systems, Inc.Airtel IndiaCienaNokiaVerizonHuawei TechnologiesJuniper NetworksBell Canada This document describes how Segment Routing (SR) policies can be used
to satisfy the requirements for strict bandwidth guarantees, end-to-
end recovery and persistent paths within a segment routing network.
SR policies satisfying these requirements are called "circuit-style"
SR policies (CS-SR policies).
Path Computation Element Protocol(PCEP) Extension for ColorJuniper NetworksJuniper NetworksZTE CorporationZTE CorporationCisco Systems Inc.Verizon Communications Inc. Color is a 32-bit numerical attribute that is used to associate a
Traffic Engineering (TE) tunnel or policy with an intent or objective
(e.g. low latency). This document specifies an extension to Path
Computation Element Protocol (PCEP) to carry the color attribute.
Improving Awareness of Running Code: The Implementation Status SectionThis document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCEAn active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.A Path Computation Element (PCE)-Based ArchitectureConstraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.