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+DDon Ramon de la Cruz 82-84
Madrid 28045Spainvlopez@tid.esTelefonica I+DDon Ramon de la Cruz 82-84
Madrid 28045Spainogondio@tid.es
Routing
PCE Working GroupThe Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering 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). 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 ,
as shown below:The meaning and description of Type, Length and SRLG ID can be found in
. Bits in the Flags field
are ignored.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. 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.This document does not add any new
security concerns beyond those discussed in .Mechanisms defined in this document do not imply any new control of
function and policy requirements. 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 34 (TBD)SRLG sub-objectThis documentTBD.