PCEP Extensions for Receiving SRLG InformationHuawei TechnologiesLeela PalaceBangaloreKarnataka560008Indiadhruv.ietf@gmail.comHuawei TechnologiesBantian, Longgang DistrictShenzhenGuangdong518129P.R.Chinazhangfatai@huawei.comHuawei TechnologiesBantian, Longgang District
ShenzhenGuangdong518129P.R.Chinazhang.xian@huawei.comTelefonica I+DDistrito TelefonicaEdificio Sur 3, 3rd floorMadrid28050Spainvictor.lopezalvarez@telefonica.comTelefonica I+DDistrito TelefonicaEdificio Sur 3, 3rd floorMadrid 28050Spainoscar.gonzalezdedios@telefonica.com
Routing
PCE Working GroupThe Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering (TE) in networks controlled
by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
(GMPLS).This document provides extensions for the Path Computation Element
Protocol (PCEP) to receive Shared Risk Link Group (SRLG)
information during path computation via encoding this information
in the path computation reply message.As per , PCE based path computation model is
deployed in large, multi-domain, multi-region, or multi-layer networks.
In such case PCEs may cooperate with each other to provide end to end
optimal path. It is important to understand which TE links in the network might be
at risk from the same failures. In this sense, a set of links may
constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure may affect all links in the set .
H-LSP (Hierarchical LSP) or S-LSP (Stitched LSP) can be used for carrying
one or more other LSPs as described in and
. H-LSP and S-LSP may be computed by PCE(s) and
further form as a TE link. The SRLG information of such LSPs can be
obtained during path computation itself and encoded in the PCEP Path Computation
Reply (PCRep) message. describes
the use of a PCE for end to end User-Network Interface (UNI) path computation.Note that specifies
a extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
where SRLG information is collected at the time of signaling. But in case a PCE
or cooperating PCEs are used for path computation it is recommended that SRLG information is
provided by the PCE(s) during the path computation itself. describes a
scaling problem with SRLGs in multi-layer environment and introduce a concept of
Macro SRLG (MSRLG). Lower layer SRLG are abstracted at the time of path computation and can
be the basis to generate such a Macro SRLG at the PCE.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .The following terminology is used in this document.Confidential Path Segment. A segment of a path that contains
nodes and links that the policy requires not to be disclosed
outside the domain.Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or route based on a
network graph and applying computational constraints.Shared Risk Link Group.User-Network Interface. states that a set of links may constitute
a 'shared risk link group' (SRLG) if they share a resource whose failure
may affect all links in the set. For example, two fibers in the same
conduit would be in the same SRLG. If an LSR is required to have
multiple diversely routed LSPs to another LSR, the path computation
should attempt to route the paths so that they do not have any links
in common, and such that the path SRLGs are disjoint.In case a PCE or cooperating PCEs are used for path computation,
the SRLG information is provided by the PCE(s). For example, disjoint paths
for inter-domain or inter-layer LSPs. In order to achieve path computation
for a secondary (backup) path, a PCC may request the PCE for a route that must
be SRLG disjoint from the primary (working) path. The Exclude Route Object
(XRO) is used to specify SRLG information to be
explicitly excluded.Following key requirements are identified for PCEP to
receive SRLG information during path computation:The PCEP speaker must be capable
of indicating whether the SRLG information of the path should be received during
the path computation procedure.If requested, the SRLG information should be
received during the path computation and encoded in the PCRep message.Cooperating PCEs with inter-PCE Communication
work together to provide the end to end optimal path as well as the SRLG
information of this path. During inter-domain or inter-layer path computation,
the aggregating PCE (Parent PCE or Ingress PCE(1)
or Higher-Layer PCE )
should receive the SRLG information of path segments from other PCEs and
provide the end to end SRLG information of the optimal path to the Path
Computation Client (PCC).This document extends the existing RP (Request Parameters) object
so that a PCEP speaker can request SRLG information
during path computation. The SRLG subobject maybe carried inside
the Explicit Route Object (ERO) in the PCRep message.This document adds the following flags to the RP Object:when set, in a PCReq message, this
indicates that the SRLG information of the path
should be provided in the PCRep message. Otherwise, when
cleared, this indicates that the SRLG information should not be
included in the PCRep message. In a PCRep message, when the S bit is
set this indicates that the returned path in ERO also carry the
SRLG information;
otherwise (when the S bit is cleared), the returned path does not
carry SRLG information.As per , ERO is used to encode the path
and is carried within a PCRep message to provide the computed path
when computation was successful.The SRLG of a path is
the union of the SRLGs of the links in the path .
The SRLG subobject is defined in
for ROUTE_RECORD object (RRO). The same subobject format (as shown below)
can be encoded inside the ERO object in the PCRep message.The meaning and description of Type, Length and SRLG ID can be found in
. Reserved field
SHOULD be set to zero on transmission and MUST be ignored on receipt.The SRLG subobject should be encoded inside the ERO object in the PCRep message
when the S-Bit (SRLG) is set in the PCReq message.If a PCE receives a request and the PCE does not understand the
new SRLG flag in the RP object, then the PCE SHOULD reject the request.If PCEP speaker receives a PCRep message with SRLG subobject that it does
not support or recognize, it must act according to the existing processing rules of ERO. defines a mechanism to hide the contents of a segment
of a path, called the Confidential Path Segment (CPS). The CPS may
be replaced by a path-key that can be conveyed in the PCEP
and signaled within in a RSVP-TE ERO.When path-key confidentiality is used, encoding
SRLG information in PCRep along with the path-key could be useful to compute a SRLG
disjoint backup path at the later instance.The path segment that needs to be hidden (that is, CPS) MAY be
replaced in the ERO with a PKS. The PCE MAY use the SRLG Sub-objects
in the ERO along with the PKS sub-object.
In a multi-layer multi-domain scenario, SRLG ids may be configured by
different management entities in each layer/domain. In such
scenarios, maintaining a coherent set of SRLG IDs is a key
requirement in order to be able to use the SRLG information properly.
Thus, SRLG IDs must be unique. Note that current procedure is
targeted towards a scenario where the different layers and domains
belong to the same operator, or to several coordinated administrative
groups. Ensuring the aforementioned coherence of SRLG IDs is beyond
the scope of this document. Further scenarios, where coherence in the SRLG IDs cannot be
guaranteed are out of the scope of the present document and are left
for further study.
This document does not add any new
security concerns beyond those discussed in .A PCE involved in inter-domain or inter-layer path
computation should be capable of being configured with a
SRLG processing policy to specify if the SRLG IDs of the domain
or specific layer network can be exposed to the PCC outside the domain
or layer network, or whether they should be summarized, mapped
to values that are comprehensible to PCC outside the domain or
layer network, or removed entirely. describes the PCEP MIB, there are no new MIB Objects
for this document.Mechanisms defined in this document do not imply any new liveness detection
and monitoring requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new requirements
on other protocols.Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
.IANA assigns values to PCEP parameters in registries defined in
. IANA is requested to make the following
additional assignments.IANA has previously assigned an Object-Class and Object-Type to the
ERO carried in PCEP messages . IANA also maintains a list
of subobject types valid for inclusion in the ERO.IANA is requested to assign one new subobject types for inclusion in the ERO as
follows:SubobjectMeaning Reference xx (TBA)SRLG sub-objectThis documentSpecial thanks to the authors of
. This document
borrows some of text from it.