One document matched: draft-dhody-pce-recv-srlg-04.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-04" 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>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</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>Distrito Telefonica</street>
<street>Edificio Sur 3, 3rd floor</street>
<city>Madrid</city>
<region></region>
<code>28050</code>
<country>Spain</country>
</postal>
<email>victor.lopezalvarez@telefonica.com</email>
</address>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Distrito Telefonica</street>
<street>Edificio Sur 3, 3rd floor</street>
<city>Madrid </city>
<region></region>
<code>28050</code>
<country>Spain</country>
</postal>
<email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</author>
<date month="October" year="2015" />
<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 (TE) 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 can
constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure can 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-teas-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) during the path computation itself to the ingress (PCC) rather
than receiving this information during signaling. </t>
<t><xref target='I-D.ietf-teas-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 can constitute
a 'shared risk link group' (SRLG) if they share a resource whose failure
can 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 SHOULD be capable
of indicating whether the SRLG information of the path is to 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) (TBA-IANA) :">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-teas-rsvp-te-srlg-collect'/>
for ROUTE_RECORD object (RRO). The same subobject format (reproduced below)
can be used by the ERO object in the PCRep message.</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-teas-rsvp-te-srlg-collect'/>. Reserved field
SHOULD be set to zero on transmission and MUST be ignored on receipt.</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. Incase no SRLG information
is present for the path, an empty SRLG subobject with Length as 4 (and no SRLG-IDs) is included.</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 as per <xref target="RFC5440"/>,
it would ignore the flag. In which case, the PCC will receive ERO with
no SRLG subobject and can determine that the PCE does not support the
PCEP extention as defined in this document.</t>
<t>If PCEP speaker receives a PCRep message with SRLG subobject that it does
not support or recognize, it would act according to the existing processing
rules of the ERO.</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>
<t>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.</t>
</section>
<section title="Coherent SRLG IDs" toc="default">
<t>
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.
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t> The procedures defined in
this document permit the transfer of SRLG data between layers or
domains during the path computation of LSPs, subject to policy at
the PCE. It is recommended that PCE
policies take the implications of releasing SRLG information into
consideration and behave accordingly during path computation. Other
security concerns are discussed in <xref target="RFC5440"/>.
An analysis of the
security issues for routing protocols that use TCP (including PCEP)
is provided in <xref target='RFC6952'/>, while <xref target='I-D.ietf-pce-pceps'/> discusses an experimental
approach to provide secure transport for PCEP.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>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 PCEP peer 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.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target='RFC7420'/> 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. Note that, <xref target='I-D.ietf-teas-rsvp-te-srlg-collect'/>
provide similar requirements for signaling protocol.</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 RP Object Flag" toc="default">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry and the "RP Object Flag Field" sub-registry.</t>
<t>IANA has allocated a new bit from this registry as follows:</t>
<texttable style="none" suppress-title="true">
<ttcol align="center" width='40%'>Bit</ttcol>
<ttcol align="left" width='40%'>Meaning </ttcol>
<ttcol align="left" width='40%'>Reference </ttcol>
<c>TBA</c><c>SRLG</c><c>This document</c>
</texttable>
</section>
<section title="New Subobjects for the ERO Object" toc="default">
<t>PCEP uses the ERO registry maintained for RSVP at
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml.
Within this registry IANA maintains sub-registry for ERO subobject at
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-25</t>
<t>Upon approval of this document, IANA is requested to make identical additions to the registry as
follows (which is un-assigned right now):</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Subobject Type Reference
34 SRLG sub-object [This I.D.]
]]></artwork>
</figure>
</t>
<t>Note that, an early allocation for SRLG sub-object for RRO in
RSVP-TE is made for <xref target='I-D.ietf-teas-rsvp-te-srlg-collect'/>
which expires on 2016-09-11.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>Special thanks to the authors of
<xref target='I-D.ietf-teas-rsvp-te-srlg-collect'/>. This document
borrows some of text from it.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.ietf-teas-rsvp-te-srlg-collect"?>
</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.RFC.6952.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<?rfc include="reference.I-D.ietf-pce-pceps"?>
<?rfc include="reference.I-D.ietf-teas-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
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: udayasree.palle@huawei.com
Avantika
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: avantika.sushilkumar@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:42:58 |