One document matched: draft-dhody-pce-association-attr-05.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-association-attr-05" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ASSOC-ATTR-POLICY">Path Computation Element communication
Protocol extension for relationship between LSPs and Attributes or Policies</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>560066</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>sunseawq@huawei.com</email>
</address>
</author>
<date month="October" year="2016" />
<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 defines a mechanism to create associations between a
set of LSPs and a set of attributes (such as configuration
parameters).
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t><xref target="RFC5440"/> describes the Path Computation Element
communication Protocol (PCEP) which enables the communication between
a Path Computation Client (PCC) and a Path Control Element (PCE),
or between two PCEs based on the PCE architecture
<xref target="RFC4655"/>.</t>
<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 and a stateless PCE.</t>
<t>This document specifies a PCEP extension to associate one or
more LSPs with a set of attributes.</t>
<t>PCEP Extensions
for Stateful PCE Model <xref target="I-D.ietf-pce-stateful-pce"/>
describes a set of extensions to PCEP to
enable active control of MPLS-TE and GMPLS tunnels.
<xref target="I-D.ietf-pce-pce-initiated-lsp"/> describes the setup and teardown of
PCE-initiated LSPs under the active stateful PCE model, without the
need for local configuration on the PCC, thus allowing for a dynamic
network. The mechanims described in this document is equally applicable to
these deployment models. </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="AAG:">Attribute Association Group.</t>
<t hangText="LSR:">Label Switch Router.</t>
<t hangText="MPLS:">Multiprotocol Label Switching.</t>
<t hangText="PAG:">Policy Association Group.</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>
</list>
</t>
</section>
<section title="Motivation" toc="default">
<t>This section discusses in more detail the motivation and use cases
for such an association including but not limited to - </t>
<section title="Opaque Identifier" toc="default">
<t>An opaque identifier may represent attributes such as
configured parameters or constraints that a PCEP speaker may
invoke on a peer. Thus a PCEP speaker may only need an opaque identifier
to invoke these attributes (parameters or constraints) rather than
encoding them explicitly in each PCEP message.</t>
<t>This can also be used for tagging bunch of LSP to a particular customer
or for creation of virtual network like in case of Abstraction and
Control of TE Networks (ACTN) <xref target="I-D.ietf-teas-actn-requirements"/>.
(See <xref target="I-D.leedhody-pce-vn-association"/>)</t>
</section>
<section title="Bundled requests" toc="default">
<t>In some scenarios(e.g.,the topology example described in
Section 4.6 of <xref target="RFC6805"/>), there is a need to send
multiple requests with the same constraints and attributes to the
PCE. Currently these requests are either sent in a separate path
computation request (PCReq) messages or bundled together in one
(or more) PCReq messages. In either case, the constraints and
attributes need to be encoded separately for each request even
though they are exactly identical.</t>
<t>If a association is used to identify these constraints and
attributes shared by multiple requests and grouped together via
association mechanism, thus simplifying the path
computation message exchanges.</t>
</section>
</section>
<section title="Overview" 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. This grouping can then be used
to define associations between sets of LSPs or between a set of
LSPs and a set of attributes (such as configuration parameters).
A new optional Association Object-type is defined
based on the generic Association object -
<list style="symbols">
<t>Attribute Association Group (AAG) </t>
</list>
</t>
<t>Thus this document defines a new association type called
"Attribute Association Type" of value TBD1. An AAG can have one or more LSPs and its
associated attributes.
The scope and handling of AAG identifier
is similar to the generic association identifier defined in
<xref target='I-D.ietf-pce-association-group'/>.</t>
<t>One or more LSP are grouped via a single group identifier as
defined in <xref target='I-D.ietf-pce-association-group'/>. The
attributes that may be associated with this set of LSPs may either are -</t>
<t>
<list style="symbols">
<t>known to the PCEP peers via some external means like
configuration, policy enforcement etc (can be considered as
'out-of-band'). PCEP speaker simply use the AAG identifier in the
PCEP message and the peer is supposed to be aware of the associated
attributes. This is suitable for stateless PCE where the PCEP peers
should be aware of the association and its significance
outside of the protocol.</t>
<t>or communicated to the PCEP peer via PCEP itself on first
use (can be considered as 'in-band'). PCEP speaker creates a new
AAG by using a new identifier and the associated attributes are
communicated via TLVs in association object. This is applicable for
stateful PCE only.</t>
</list>
</t>
<t>Error handling would be taken up in future revision.</t>
</section>
<section title="Attribute Association Group" toc="default">
<t>The format of the generic Association object used for AAG is shown in
<xref target='FIG1'/>:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="The AAG Object formats" width="" anchor="FIG1">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
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 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type (TBD1) | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type (TBD1) | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Type = TBD1 for the Attribute Association Type.</t>
<t>AAG may carry optional TLVs including but not limited to -</t>
<t>
<list style="symbols">
<t>ATTRIBUTE-OBJECT-TLV: Used to communicate associated attributes
in form of PCEP objects, described in this document.</t>
<t>VENDOR-INFORMATION-TLV: Used to communicate arbitrary behavioural
information, described in <xref target="RFC7470"/>.</t>
</list>
</t>
<section title="ATTRIBUTE-OBJECT-TLV" toc="default">
<t>The ATTRIBUTE-OBJECT-TLV(s) maybe included in AAG object to
associate attributes encoded in PCEP objects.</t>
<t>The format of the ATTRIBUTE-OBJECT-TLV is shown in the
following figure:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="ATTRIBUTE-OBJECT-TLV format" width="" anchor="FIG2">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
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 (TBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is TBD2 and it has a variable length. The value
part consist of a PCEP object (including common header <xref target="RFC5440"/>
identifying the object) that is
associated with this AAG. This TLV identifies the attributes associated
with this group. For each attribute a separate TLV is used.
Future PCEP message exchanges may only carry the AAG with no ATTRIBUTE-OBJECT-TLV. </t>
<t>[Editor,s Note - How to make changes to attribute list will be added
in future revison.]</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines a new types for association and a
new ATTRIBUTE-OBJECT-TLV 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>
<t> Some deployments may find the associations and their implications
as extra sensitive
and thus should employ suitable PCEP security mechanisms like TCP-AO
or <xref target='I-D.ietf-pce-pceps'/>.</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 Attribute Association Type [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="PCEP TLV Type Indicators" toc="default">
<t>This document defines the following new PCEP TLV; IANA is
requested to make the following allocations from this registry.
http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators</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
TBD2 ATTRIBUTE-OBJECT-TLV [This I.D.]
]]></artwork>
</figure>
</t>
</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 attribute associations 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.RFC.7470.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.6805.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<?rfc include="reference.I-D.ietf-pce-pceps"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.ietf-teas-actn-requirements"?>
<?rfc include="reference.I-D.leedhody-pce-vn-association"?>
</references>
<section title="Policy" toc="default">
<t>An earlier version of this document also had details about
Policy association group. This has been moved to an independent
document. </t>
</section>
<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[
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R.China
EMail: zhang.xian@huawei.com
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasree.palle@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:24:14 |