One document matched: draft-dhody-pce-srlg-collection-00.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-srlg-collection-00" 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>
<date month="October" year="2013" />
<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 support collection of Shared Risk Link Group (SRLG)
information during path computation and encoding this information
in the 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
collected 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 PCE for end to end User-Network Interface (UNI) path computation.</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. Lower layer SRLG collection at the time of path computation can be
used to generate such a Macro SRLG at the PCE.</t>
<t>Note that <xref target='I-D.ietf-ccamp-rsvp-te-srlg-collect'/> specifies
a similar extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
where SRLG information is collected at the time of signaling.</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="PCEP Requirements" toc="default">
<t>Following key requirements are identified for PCEP to
enable SRLG information collection during path computation:</t>
<t>
<list style="hanging">
<t hangText="SRLG Collection Indication:">The PCEP speaker must be capable
of indicating whether the SRLG information of the LSP should be collected during
the path computation procedure.</t>
<t hangText="SRLG Collection:">If requested, the SRLG information should be
collected during the path computation and encoded in the PCRep message.</t>
</list>
</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
collection 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 Label switched path (LSP) should be collected
during the path computation procedure. Otherwise, when
cleared, this indicates that the SRLG information should not be
collected. 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 of a
TE LSP 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 LSP <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
is 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, collection of SRLG information and encoding
this 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>TBD.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>TBD.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>TBD.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>TBD.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>TBD.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>TBD.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>TBD.</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" ?>
</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.4874.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5520.xml" ?>
<?rfc include="reference.RFC.6107.xml" ?>
<?rfc include="reference.I-D.ietf-ccamp-rsvp-te-srlg-collect"?>
<?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:44:22 |