One document matched: draft-litkowski-pce-association-diversity-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-litkowski-pce-association-diversity-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ASSOC-DISJOINT">Path Computation Element communication
Protocol extension for signalling LSP diversity constraint</title>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 3E8</code>
<country>Canada</country>
</postal>
<email>msiva@cisco.com</email>
</address>
</author>
<author initials="C" surname="Barth" fullname="Colby Barth">
<organization>Juniper Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>cbarth@juniper.net</email>
</address>
</author>
<date month="October" year="2016" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>
This document introduces a simple mechanism to signal path diversity for
a group of Label Switched Paths (LSPs) via an extension to the Path Computation
Element Communication Protocol (PCEP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t><xref target='I-D.ietf-pce-association-group'/> introduces a generic
mechanism to create a grouping of LSPs which can then be used to
define associations between a set of LSPs and a set of attributes (such
as configuration parameters or behaviours) and is equally applicable
to the active and passive modes of a stateful PCE <xref target="I-D.ietf-pce-stateful-pce"/> or a stateless PCE <xref target="RFC5440"/>.</t>
<t>This document specifies a PCEP extension to signal that a particular group of
LSPs should use diverse paths including the requested type of diversity.</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="LSR:">Label Switch Router.</t>
<t hangText="MPLS:">Multiprotocol Label Switching.</t>
<t hangText="PCC:">Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element.</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="PCEP:">Path Computation Element Communication Protocol.</t>
<t hangText="SRLG:">Shared Risk Link Group.</t>
</list>
</t>
</section>
<section title="Motivation" toc="default">
<t>Path diversity is a very common use case today in IP/MPLS networks especially for layer 2 transport over MPLS.
A customer may request that the operator provide two end-to-end disjoint paths across the IP/MPLS core.
The customer may use those paths as primary/backup or active/active.
</t>
<t>Different level of disjointness may be offered:
<list style="symbols">
<t>Link disjointness: the paths of the associated LSPs should transit different
links (but may use common nodes or different links that may have some shared
fate).
</t>
<t>Node disjointness: the paths of the associated LSPs should transit different
nodes (but may use different links that may have some shared fate).
</t>
<t>SRLG disjointness: the paths of the associated LSPs should transit different
links that do not share fate (but may use common transit nodes).
</t>
<t>Node+SRLG disjointness: the paths of the associated LSPs should transit
different links that do not have any common shared fate and should transit
different nodes.
</t>
</list>
</t>
<t>
The associated LSPs may originate from the same or from different head-end(s) and may terminate at the same or different tail-end(s).
</t>
<figure title="Figure 1 - Disjoint paths with different head-ends" suppress-title="false">
<artwork>
_________________________________________
/ \
/ +------+ \
| | PCE | |
| +------+ |
| |
| ***********************> |
| +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | | +------+ |
| | | |
| | | |
| +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ ***********************> +------+ |
| |
\ /
\_________________________________________/
</artwork>
</figure>
<t>
In the figure above, the customer wants to have two disjoint paths between CE1/CE2 and CE3/CE4. From an IP/MPLS network point view, in this example, the CEs are connected to different PEs to maximize their disjointness.
When LSPs originate from different head-ends, distributed computation
of diverse paths can be difficult. Whereas, computation via a centralized PCE ensures
path disjointness correctness and simplicity.
</t>
<t>
Using PCEP, the PCC MUST indicate that disjoint path computation is required, such indication SHOULD include disjointness parameters such as the type of
disjointness, the disjoint group-id, and any customization parameters according to
local policy.
</t>
<t>The PCC can use the generic mechanism as per
<xref target='I-D.ietf-pce-association-group'/> to associate a set
of LSPs with a particular disjoint-group.</t>
<t>The management of the disjoint group-ids will be a key point for the operator as the Association ID field is limited to 65535.
The local configuration of IPv4/IPv6 association source, or Global Association Source/Extended Association ID should allow to overcome this limitation.
For example, when a PCC or PCE initiates all the LSPs in a particular disjoint-group, it can set the IPv4/IPv6 association source can be set to one of its IP address.
When disjoint LSPs are initiated from different head-ends, a unique association identifier SHOULD be used for those LSPs: this can be achieved by setting the IPv4/IPv6 source address to a common value (zero value can be used) as well as the Association ID.
</t>
<t><figure title="Figure 2 - Sample use-cases for carrying disjoint-group over PCEP session" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Policy-ID Y
Initiate & Monitor LSP {Disjoint paths}
| |
| PCReq |
V {Disjoint-group Y} V
+-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE |
| +-----+ | ----------> +-----+
| PCEInitiate | | PCReq
|{Disjoint-group X} | | {Disjoint-group Y}
| | |
| .-----. | | .-----.
| ( ) | +----+ ( )
| .--( )--. | |PE 1|--.--( )--.
V ( ) | +----+ ( )
+---+ ( ) | ( )
|PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network )
+---+ ( ) |PE 3|------( )
Disjoint-group X ) +----+ ( )
{Monitor LSP} '--( )--' '--( )--'
( ) ( )
'-----' '-----'
Case 1: Disjointness initiated by Case 2: Disjointness initiated by
PCE and enforced by PCC PCC and enforced by PCE
]]></artwork>
</figure></t>
<t>Using the disjoint-group within a PCUpdate or PCInit may have two purposes:
<list style="symbols">
<t>Information: in case the PCE is performing the path computation, it may communicate to the PCC the locally used configured parameters in the attribute-list of the LSP.</t>
<t>Configuration: in case the PCC is performing the path computation but the PCE (without computation engine) is managing the LSP parameters,
the PCE should add the disjoint-group within the PCUpdate message to communicate to the PCC the disjointness constraint.</t>
</list>
</t>
</section>
<section title="Protocol extension" toc="default">
<section title="Association group" toc="default">
<t>As per <xref target='I-D.ietf-pce-association-group'/>, LSPs
are associated with other LSPs with which they interact by adding
them to a common association group. The Association ID will be used
to identify the disjoint group a set of LSPs belongs to.
This document defines four new Association types,
based on the generic Association object -
<list style="symbols">
<t>Association type = TBD1 ("Disjointness
Association Type") for link disjoint group. Authors suggest the value 1.</t>
<t>Association type = TBD2 ("Disjointness
Association Type") for node disjoint group. Authors suggest the value 2.</t>
<t>Association type = TBD3 ("Disjointness
Association Type") for srlg disjoint group. Authors suggest the value 3.</t>
<t>Association type = TBD4 ("Disjointness
Association Type") for node+srlg disjoint group. Authors suggest the value 4.</t>
</list>
</t>
<t>A disjoint group can have two or more LSPs. But a PCE may be limited in how many LSPs it can take into account when computing disjointness:
usually PCEs are able to compute a pair of disjoint paths.
If a PCE receives more LSPs in the group than it can handle in its computation algorithm, it SHOULD apply disjointness computation to only a subset of LSPs in the group. The subset of disjoint LSPs will be decided by the implementation.
</t>
<t>Local polices on the PCC or PCE MAY define the computational behavior for the other LSPs
in the group. For example, the PCE may provide no path, a shortest path, or a constrained path
based on relaxing disjointness, etc.</t>
<t>Associating a particular LSP to multiple disjoint groups is authorized from a protocol perspective, however there is no insurance that the PCE will be able to compute properly the multi-disjointness constraint.</t>
</section>
<section title="Optional TLVs" toc="default">
<t>
The disjoint group MAY carry some optional TLVs including but not limited to:
<list style="symbols">
<t>VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor specific behavioral
information, described in <xref target="RFC7150"/>.</t>
<t>DISJOINTNESS-INFORMATION-TLV: Used to communicate some disjointness specific parameters.</t>
</list>
</t>
<t>
The DISJOINTNESS-INFORMATION-TLV is shown in the following figure:
<figure>
<artwork>
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 = [TBD5] | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="none">
<t>Flags:
<list style="symbols">
<t>P: shortest path, this particular LSP in the group SHOULD use the shortest path and others MAY use a non shortest path.</t>
<t>S: strict disjointness, when set if disjoint paths cannot be found, PCE should return no path for LSPs that could not be be disjoint. When unset, PCE is allowed to relax disjointness by using either using a lower disjoint type (link instead of node) or relaxing disjointness constraint at all.</t>
</list>
</t>
</list>
</t>
<t>
If a PCEP speaker receives a disjoint-group without DISJOINTNESS-INFORMATION-TLV, it SHOULD use its locally configured parameters or use the following default parameters:
<list style="symbols">
<t>Strict disjointness is assumed.</t>
<t>LSP can use a non shortest-path.</t>
</list>
</t>
<t>
If a PCEP speaker receives two LSPs with the same disjoint-group but with a different S flag value, it SHOULD apply a strict disjointness path computation for this disjoint-group (it considers S flag set for all LSPs).
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines one new type for association, which do not add any new
security concerns beyond those discussed in <xref target="RFC5440"/>,
<xref target='I-D.ietf-pce-stateful-pce'/> and <xref target='I-D.ietf-pce-association-group'/> in itself.</t>
</section>
<section title="IANA Considerations" toc="default">
<section title="Association object Type Indicators" toc="default">
<t>This document defines the following new association type originally
defined in <xref target='I-D.ietf-pce-association-group'/>.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value Name Reference
TBD1 (suggested value 1) Link Disjoint-group
Association Type [This I.D.]
TBD2 (suggested value 2) Node Disjoint-group
Association Type [This I.D.]
TBD3 (suggested value 3) SRLG Disjoint-group
Association Type [This I.D.]
TBD4 (suggested value 4) Node+SRLG Disjoint-group
Association Type [This I.D.]
]]></artwork>
</figure>
</t>
<t>This document defines the following new PCEP TLV:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value Name Reference
TBD5 DISJOINTNESS-INFORMATION-TLV [This I.D.]
]]></artwork>
</figure>
<t>
IANA is requested to manage the space of flags carried in the DISJOINTNESS-INFORMATION TLV defined in this document, numbering them from 0 as the least significant bit.
</t>
<t>New bit numbers may be allocated in future.</t>
<t>IANA is requested to allocate the following bit numbers in the DISJOINTNESS-INFORMATION-TLV flag space:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Number Name Reference
0 Strict disjointness [This I.D.]
1 Shortest-path [This I.D.]
]]></artwork>
</figure>
</section>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>
An operator MUST be allowed to configure the disjointness associations and parameters at PCEP peers
and associate it with the LSPs. </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.</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="Acknowledgments" toc="default">
<t>A special thanks to author of
<xref target='I-D.ietf-pce-association-group'/>, this document borrow
some of the text from it.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.ietf-pce-association-group"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7150.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:43 |