One document matched: draft-dhody-pce-recv-srlg-01.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-dhody-pce-recv-srlg-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="PCE-SRLG">PCEP Extensions for Receiving SRLG Information</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author initials="F" surname="Zhang" fullname="Fatai Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhangfatai@huawei.com</email>
</address>
</author>
<author fullname="Xian Zhang" initials="X." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District
</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</author>
<author fullname="Victor Lopez" initials="V." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz 82-84
</street>
<city>Madrid </city>
<region></region>
<code>28045</code>
<country>Spain</country>
</postal>
<email>vlopez@tid.es</email>
</address>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz 82-84
</street>
<city>Madrid </city>
<region></region>
<code>28045</code>
<country>Spain</country>
</postal>
<email>ogondio@tid.es</email>
</address>
</author>
<date month="February" year="2014" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The 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).</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>As per <xref target="RFC4655"/>, 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. </t>
<t>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 <xref target="RFC4202"/>.
H-LSP (Hierarchical LSP) or S-LSP (Stitched LSP) can be used for carrying
one or more other LSPs as described in <xref target="RFC4206"/> and
<xref target="RFC6107"/>. 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. <xref target='I-D.zhang-ccamp-gmpls-uni-app'/> describes
the use of a PCE for end to end User-Network Interface (UNI) path computation.</t>
<t>Note that <xref target='I-D.ietf-ccamp-rsvp-te-srlg-collect'/> 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).</t>
<t><xref target='I-D.farrel-interconnected-te-info-exchange'/> 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.</t>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="CPS:">Confidential Path Segment. A segment of a path that contains
nodes and links that the policy requires not to be disclosed
outside the domain.</t>
<t hangText="PCE:">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.</t>
<t hangText="SRLG:">Shared Risk Link Group.</t>
<t hangText="UNI:">User-Network Interface.</t>
</list>
</t>
</section>
<section title="Usage of SRLG" toc="default">
<t><xref target="RFC4202"/> 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.</t>
<t>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) <xref target="RFC5521"/> is used to specify SRLG information to be
explicitly excluded.</t>
</section>
<section title="PCEP Requirements" toc="default">
<t>Following key requirements are identified for PCEP to
receive SRLG information during path computation:</t>
<t>
<list style="hanging">
<t hangText="SRLG Indication:">The PCEP speaker must be capable
of indicating whether the SRLG information of the path should be received during
the path computation procedure.</t>
<t hangText="SRLG:">If requested, the SRLG information should be
received during the path computation and encoded in the PCRep message.</t>
</list>
</t>
<t>Cooperating PCEs <xref target="RFC4655"/> 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 <xref target="RFC6805"/> or Ingress PCE(1)
<xref target="RFC5441"/> or Higher-Layer PCE <xref target="RFC5623"/>)
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).</t>
</section>
<section title="Extension to PCEP" toc="default">
<t>This document extends the existing RP (Request Parameters) object
<xref target="RFC5440"/> 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.</t>
<section title="The Extension of the RP Object" toc="default">
<t>This document adds the following flags to the RP Object:</t>
<t>
<list style="hanging">
<t hangText="S (SRLG - 1 bit):">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.</t>
</list>
</t>
</section>
<section title="SRLG Subobject in ERO" toc="default">
<t>As per <xref target="RFC5440"/>, ERO is used to encode the path
and is carried within a PCRep message to provide the computed path
when computation was successful.</t>
<t>The SRLG of a path is
the union of the SRLGs of the links in the path <xref target="RFC4202"/>.
The SRLG subobject is defined in <xref target='I-D.ietf-ccamp-rsvp-te-srlg-collect'/>,
as shown below:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The meaning and description of Type, Length and SRLG ID can be found in
<xref target='I-D.ietf-ccamp-rsvp-te-srlg-collect'/>. Bits in the Flags field
are ignored.</t>
<t>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.</t>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="Backward Compatibility" toc="default">
<t>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.</t>
<t>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.</t>
</section>
<section title="Confidentiality via PathKey" toc="default">
<t><xref target="RFC5520"/> 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.</t>
<t>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.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not add any new
security concerns beyond those discussed in <xref target="RFC5440"/>.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>Mechanisms defined in this document do not imply any new control of
function and policy requirements.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target='I-D.ietf-pce-pcep-mib'/> describes the PCEP MIB, there are no new MIB Objects
for this document.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness detection
and monitoring requirements in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>Mechanisms defined in this document do not imply any new requirements
on other protocols.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
<xref target="RFC5440"/>.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>IANA assigns values to PCEP parameters in registries defined in
<xref target="RFC5440"/>. IANA is requested to make the following
additional assignments.</t>
<section title="New Subobjects for the ERO Object" toc="default">
<t>IANA has previously assigned an Object-Class and Object-Type to the
ERO carried in PCEP messages <xref target="RFC5440"/>. IANA also maintains a list
of subobject types valid for inclusion in the ERO.</t>
<t>IANA is requested to assign one new subobject types for inclusion in the ERO as
follows:</t>
<texttable style="none" suppress-title="true">
<ttcol align="center" width='40%'>Subobject</ttcol>
<ttcol align="left" width='40%'>Meaning </ttcol>
<ttcol align="left" width='40%'>Reference </ttcol>
<c>34 (TBD)</c><c>SRLG sub-object</c><c>This document</c>
</texttable>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4202.xml" ?>
<?rfc include="reference.RFC.4206.xml" ?>
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.5520.xml" ?>
<?rfc include="reference.RFC.5521.xml" ?>
<?rfc include="reference.RFC.5623.xml" ?>
<?rfc include="reference.RFC.6107.xml" ?>
<?rfc include="reference.RFC.6805.xml" ?>
<?rfc include="reference.I-D.ietf-ccamp-rsvp-te-srlg-collect"?>
<?rfc include="reference.I-D.ietf-pce-pcep-mib"?>
<?rfc include="reference.I-D.farrel-interconnected-te-info-exchange"?>
<?rfc include="reference.I-D.zhang-ccamp-gmpls-uni-app"?>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
Avantika
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: avantika.sushilkumar@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:42:35 |