One document matched: draft-dwpz-pce-domain-diverse-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="exp" docName="draft-dwpz-pce-domain-diverse-04" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="DOMAIN-DIVERSE">PCE support for Domain Diversity</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 fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<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>udayasree.palle@huawei.com</email>
</address>
</author>
<author initials="X" surname="Zhang" fullname="Xian Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<region></region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</author>
<date month="October" year="2015" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element (PCE) may be used for computing path for
services that traverse multi-area and multi-AS Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered
(TE) networks.</t>
<t>Path computation should facilitate the selection of paths with
domain diversity. This document examines the existing mechanisms
to do so and further propose some extensions to Path Computation
Element Protocol (PCEP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key requirement. In this
context, a domain is a collection of network elements within a common
sphere of address management or path computational responsibility such
as an Interior Gateway Protocol (IGP) area or an Autonomous Systems (AS).</t>
<t>In a multi-domain environment, Domain Diversity is defined in
<xref target="RFC6805"/>. A pair of paths are domain-diverse if they do
not traverse any of the same transit domains. Domain diversity may be
maximized for a pair of paths by selecting paths that have the smallest
number of shared domains. Path computation should facilitate the
selection of domain diverse paths as a way to reduce the risk of
shared failure and automatically helps to ensure path diversity
for most of the route of a pair of LSPs.</t>
<t>The main motivation behind domain diversity is to
avoid fate sharing, but it can also be because of some geo-political reasons
and commercial relationships that would require domain diversity.
for example, a pair of paths should choose different transit Autonomous System
(AS) because of some policy considerations.</t>
<t>In case when full domain diversity could not be
achieved, it is helpful to minimize the common shared domains. Also it is
interesting to note that other scope of diversity (node, link, SRLG etc) can still be applied inside
the common shared domains.</t>
<t>This document examine a way to achieve domain diversity with existing
inter-domain path computation mechanism like per-domain path computation
technique <xref target="RFC5152"/>, Backward Recursive Path Computation
(BRPC) mechanism <xref target="RFC5441"/> and Hierarchical PCE
<xref target="RFC6805"/>. This document also considers synchronized
as well as non-synchronized dependent path computations.
Since independent and synchronized path computation cannot be used to
apply diversity, it is not discussed in this document.</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 terminology is as per <xref target="RFC5440"/>.</t>
</section>
<section title="Domain Diversity" toc="default">
<t>As described in <xref target="RFC6805"/>, a set of paths are considered to
be domain diverse if they do not share any transit domains, apart from ingress
and egress domains. </t>
<t>Some additional parameters to consider would be - </t>
<t>
<list style="hanging">
<t hangText="Minimize shared domain:">When a fully domain diverse path
is not possible, PCE could be requested to minimize the number of
shared transit domains. This can also be termed as maximizing partial
domain diversity. Other scope of diversity (node, link, SRLG etc)
can still be applied inside the common shared domains.</t>
<t hangText="Boundary Nodes:">Diversity in boundary node selection
can be achieved by node diversity.</t>
</list>
</t>
<section title="Per Domain Path Computation" toc="default">
<t>The per domain path computation technique <xref target="RFC5152"/> defines
a method where the path is computed during the signaling process (on a
per-domain basis). The entry Boundary Node (BN) of each domain is responsible
for performing the path computation for the section of the LSP that crosses
the domain, or for requesting that a PCE for that domain computes that piece
of the path.</t>
<t>
<list style="hanging">
<t hangText="Non-Synchronized Path Computation:">Path computations
are performed in a serialized and independent fashion. After the setup
of primary path, a domain diverse path can be signaled by encoding
the transit domain identifiers in exclude route object (XRO) or
explicit exclusion route subobject (EXRS) using domain sub-objects
defined in <xref target="DOMAIN-SUBOBJ"/> and <xref target="RFC3209"/>
in RSVP-TE. Note that the head end LSR should be aware of transit domain
identifiers of the primary path to be able to do so.
Also a head end label switching router (LSR) can signal a path by using a domain diverse
domain sequence known in priori and encoded in explicit route object (ERO) in path message.</t>
<t hangText="Synchronized Path Computation:">Not Applicable.</t>
</list>
</t>
</section>
<section title="Backward-Recursive PCE-based Computation" toc="default">
<t>The BRPC <xref target="RFC5441"/> technique involves cooperation and
communication between PCEs in order to compute an optimal end-to-end path
across multiple domains. The sequence of domains to be traversed maybe
known before the path computation, but it can also be used when the
domain path is unknown and determined during path computation.</t>
<t>
<list style="hanging">
<t hangText="Non-Synchronized Path Computation:">Path computations
are performed in a serialized and independent fashion. After the
path computation of the primary path, a domain diverse path
computation request is sent by PCC to the PCE, by encoding the
transit domain identifiers in XRO or EXRS using domain sub-objects
defined in <xref target="PCE-DOMAIN"/> and <xref target="RFC3209"/>
in PCEP. Note that the PCC should be aware of transit domain identifiers
of the primary path to be able to do so. Also a PCC can request a path
by using a domain diverse domain sequence known in priori and encoded
in include route object (IRO) in path request message.</t>
<t hangText="Synchronized Path Computation:">Not Applicable. [Since
different transit domain PCEs may be involved , there is difficulty
to achieve synchronization for domain diverse path computation].
Note that <xref target="RFC5440"/> describes other diversity
parameters (node, link, SRLG etc) that may be applied. </t>
</list>
</t>
</section>
<section title="Hierarchical PCE" toc="default" anchor="SEC_HPCE">
<t>In H-PCE <xref target="RFC6805"/> architecture, the parent PCE is used to
compute a multi-domain path based on the domain connectivity information.
The parent PCE may be requested to provide a end to end path or only
the sequence of domains.</t>
<section title="End to End Path" toc="default">
<t>
<list style="hanging">
<t hangText="Non-Synchronized Path Computation:">Path computations
are performed in a serialized and independent fashion. After the path
computation of the primary path, a domain diverse path computation
request is sent to the parent PCE, by encoding the transit domain
identifiers in XRO or EXRS using domain sub-objects defined in
<xref target="PCE-DOMAIN"/> and <xref target="RFC3209"/> in PCEP.
Note that the PCC should be aware of transit domain identifiers
of the primary path to be able to do so. The parent PCE should
provide a domain diverse end to end path.</t>
<t hangText="Synchronized Path Computation:">Child PCE should be
able to request dependent and synchronized domain diverse end to
end paths from its parent PCE. A new flag is added in syncronized vectore (SVEC) object
for this (Refer <xref target="SEC_SVEC"/>).</t>
</list>
</t>
</section>
<section title="Domain-Sequence" toc="default">
<t>
<list style="hanging">
<t hangText="Non-Synchronized Path Computation:">Path computations
are performed in a serialized and independent fashion. After the
primary path computation using H-PCE (involving domain-sequence
selection by parent PCE and end-to-end path computation via BRPC
or Per-Domain mechanisms), a domain diverse path computation
request is sent to the parent PCE, by encoding the transit domain
identifiers in XRO or EXRS using domain sub-objects defined in
<xref target="PCE-DOMAIN"/> and <xref target="RFC3209"/> in PCEP.
Note that the PCC should be aware of transit domain identifiers of
the primary path to be able to do so. The parent PCE should provide
a diverse domain sequence.</t>
<t hangText="Synchronized Path Computation:">Child PCE should be
able to request dependent and synchronized diverse domain-sequence(s)
from it's parent PCE. A new flag is added in SVEC object for this
(Refer <xref target="SEC_SVEC"/>). The parent PCE should reply with
diverse domain sequence(s) encoded in ERO as described in
<xref target="PCE-DOMAIN"/>.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Extension to PCEP" toc="default">
<t>[Editor's Note: It has been requested to move this section to the
HPCE-Extension document - draft-ietf-pce-hierarchy-extensions. This
section would be removed from this document once that is done.]</t>
<section title="SVEC Object" toc="default" anchor="SEC_SVEC">
<t><xref target="RFC5440"/> defines SVEC object which includes flags
for the potential dependency between the set of path computation
requests (Link, Node and SRLG diverse). This document proposes a
new flag O for domain diversity.</t>
<t>The format of the SVEC object body is as follows:</t>
<figure title="SVEC Body Object Format" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_1">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|P|D|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Following new bit is added in the Flags field:</t>
<t>
<list style="hanging">
<t hangText="* O (Domain diverse) bit:">when set, this indicates that
the computed paths corresponding to the requests specified by the
following RP objects MUST NOT have any transit domain(s) in common.</t>
</list>
</t>
<t>The Domain Diverse O-bit can be used in Hierarchical PCE path computation
to compute synchronized domain diverse end to end path or diverse domain
sequences as described in <xref target="SEC_HPCE"/>.</t>
<t>When domain diverse O bit is set, it is applied to the transit domains.
The other bit in SVEC object (N, L, S etc) is set, should still be applied in
the ingress and egress domain.</t>
</section>
<section title="Minimize Shared Domains" toc="default">
<t>In case when full domain diversity could not be
achieved, it maybe helpful to minimize the common shared domains. It's
interesting to note that diversity (node, link etc) can still be applied inside
the common shared transit domains as well as for ingress and egress domain via
the bits in SVEC object (N, L, S etc).</t>
<t>A new Objective function (OF) <xref target="RFC5541"/> code for synchronized
path computation requests is proposed:</t>
<t>MCTD</t>
<t>
<list style="hanging">
<t hangText="* Name:">Minimize the number of Common Transit Domains.</t>
<t hangText="* Objective Function Code:">TBD</t>
<t hangText="* Description:">Find a set of paths such that it passes through
the least number of common transit domains.</t>
</list>
</t>
<t>The MCTD OF can be used in Hierarchical PCE path computation to request
synchronized domain diverse end to end paths or diverse domain sequences
as described in <xref target="SEC_HPCE"/>.</t>
<t>[Editor's Note: A new document is created for the OF for minimizing shared node,
links, SRLGs inside the domain - <xref target="PCE-OF-DIVERSE"/>.]</t>
<t>For non synchronized diverse domain path computation the X bit in XRO or
EXRS <xref target="RFC5521"/> sub-objects can be used, where X bit set as 1
indicates that the domain specified SHOULD be excluded from the path computed
by the PCE, but MAY be included subject to PCE policy and the absence of a
viable path that meets the other constraints and excludes the domain.</t>
</section>
<section title="Relationship between SVEC Diversity Flags and OF" toc="default" >
<t><xref target="RFC5440"/> uses SVEC diversity flag for node,
link or SRLG to describe the potential disjointness between the
set of path computation requests used in PCEP protocol.
This document further extends by adding domain-diverse O-bit in
SVEC object and a new OF Code for minimizing the number of
shared transit domain.</t>
<t>Further <xref target="PCE-OF-DIVERSE"/> defines three new OF codes
to maximize diversity as much as possible, in other words, minimize
the common shared resources (Node,Link or SRLG) between a set of
paths.</t>
<t>It may be interesting to note that the diversity flags in
the SVEC object and OF for diversity can be used together. Some
example of usage are listed below - </t>
<t>
<list style="symbols">
<t>SVEC object with domain-diverse bit=1 - ensure full domain-diversity.</t>
<t>SVEC object with domain-diverse bit=1 and node/link diverse bit=1 -
ensure full domain-diversity, as well as node/link diverse in
ingress and egress domain.</t>
<t>SVEC object with domain-diverse bit=0 and OF=MCTD -
domain-diversity as much as possible. </t>
<t>SVEC object with domain-diverse bit=0;node/link diverse bit=1
and OF=MCTD - domain-diversity as much as possible, as well as
node/link diverse in ingress, egress and shared transit domains.</t>
<t>SVEC object with domain-diverse bit=1 and OF=MCTD - ensure full
domain-diversity.</t>
</list>
</t>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="Transit Domain Identifier" toc="default">
<t>In case of non-synchronized path computation, Ingress node (i.e. a PCC)
should be aware of transit domain identifiers of the primary path. So during
the path computation or signaling of the primary path, the transit domain
should be identified.</t>
<t>A possible solution for path computation could be a flag in RP object
requesting domain identifier to be returned in the PCEP path reply message.</t>
<t>[Editor's Note: There should be a mechanism in signaling and path computation
to obtain the domain information. Further details - TBD]</t>
</section>
<section title="Diversity v/s Optimality" toc="default">
<t>In case of non-synchronized path computation, PCE may
be requested to provide an
optimal primary path first and then PCC requests for a backup path with
exclusion. Note that this approach does not guarantee diversity
compared to disjoint path computations for primary and backup path
in a synchronized manner.</t>
<t>A synchronized path computation with diversity flags and/or
objective function is used to make sure that both the primary path and
the backup path can be computed simultaneously with full diversity
or optimized to be as diverse as
possible. In the latter case we may sacrifice optimal path for diversity,
thus there is a trade-off between the two.</t>
<t>An implementation may further choose to analyze the trade-off
i.e. it may send multiple request to
PCE asking to optimize based on diversity as well as say, cost
and make an intelligent choice between them.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document add a new bit to SVEC object and define a new
object function. The security of the procedures described in
this document depends on PCEP <xref target="RFC5440"/>.
<xref target="RFC6007"/> describe security considerations when
SVEC are supported.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>In addition to <xref target="RFC5440"/>, the PCC should
construct the SVECs to identify and associate domain diverse
SVEC relationships. Considerations for use of objective functions
are mentioned in <xref target="RFC5541"/>.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>The PCEP MIB Module defined in <xref target="RFC7420"/>,
there are no additional parameters identified in this document.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>The domain-diverse path computation in this document allows PCEs to compute optimal
sets of diverse paths. This type of path computation and cooperation may require
more time to obtain its results. Therefore, it is recommended for
PCEP to support the PCE monitoring mechanism specified in <xref target="RFC5886"/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t><xref target="RFC5440"/> provides a sufficient description for this document. There
are no additional considerations.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>There should be a mechanism in signaling and path computation
to obtain the domain information during primary path computation.
Details to be added in future revision.</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"/> and <xref target="RFC6007"/>.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>TBD.</t>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Qilei Wang for starting this discussion in the mailing list.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5152.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.6007.xml" ?>
<?rfc include="reference.RFC.6805.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3209.xml" ?>
<?rfc include="reference.RFC.5521.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<?rfc include="reference.RFC.5886.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<!--DOMAIN-SUBOBJ-->
<reference anchor="DOMAIN-SUBOBJ">
<front>
<title>
Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization/>
</author>
<author initials="V" surname="Kondreddy" fullname="Venugopal Kondreddy">
<organization/>
</author>
<author initials="R" surname="Casellas" fullname="Ramon Casellas">
<organization/>
</author>
<date month="September" day="21" year="2015"/>
<abstract>
<t>
The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude 4-Byte Autonomous System (AS) and Interior Gateway Protocol (IGP) area during path setup.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-rsvp-te-domain-subobjects-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-teas-rsvp-te-domain-subobjects-03.txt"/>
</reference>
<!--PCE-DOMAIN-->
<reference anchor="PCE-DOMAIN">
<front>
<title>Standard Representation of Domain-Sequence</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization/>
</author>
<author initials="R" surname="Casellas" fullname="Ramon Casellas">
<organization/>
</author>
<date month="September" day="21" year="2015"/>
<abstract>
<t>
The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a standard representation and encoding of a Domain-Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-domain-sequence-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-domain-sequence-09.txt"/>
</reference>
<!--PCE-OF-DIVERSE-->
<reference anchor="PCE-OF-DIVERSE">
<front>
<title>PCE support for Maximizing Diversity</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<author initials="Q" surname="Wu" fullname="Qin Wu">
<organization/>
</author>
<date month="June" day="8" year="2015"/>
<abstract>
<t>
The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions. In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a set of services that are required to be diverse (disjointed) from each other. In case when full diversity could not be achieved, it is helpful to maximize diversity as much as possible (or in other words, minimize the common shared resources). This document defines objective function code types for three new objective functions for this purpose to be applied to a set of synchronized path computation requests.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-dhody-pce-of-diverse-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-dhody-pce-of-diverse-03.txt"/>
</reference>
</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[
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
EMail: ramon.casellas@cttc.es
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 14:29:15 |