One document matched: draft-dhody-pce-association-attr-02.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-02" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ASSOC-ATTR">Path Computation Element communication
Protocol extension for relationship between LSPs and Attributes</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>sunseawq@huawei.com</email>
</address>
</author>
<date month="July" 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 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, policy or behaviours).
</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.minei-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, which includes, but not limited
to - </t>
<t>
<list style="symbols">
<t>Configured Parameters</t>
<t>Policies</t>
<t>Behaviour</t>
</list>
</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="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>
</section>
<section title="Policy based Constraints" toc="default">
<t>In the context of policy-enabled path computation
<xref target="RFC5394"/>, path computation policies may be applied
at both a PCC and a PCE. Consider an Label Switch Router (LSR) with
a policy enabled PCC, it receives a service request via signaling,
including over a Network-Network Interface (NNI) or User Network
Interface (UNI) reference point, or receives a configuration request
over a management interface to establish a service. The PCC may also
apply user- or service-specific policies to decide how the path
selection process should be constrained, that is, which constraints,
diversities, optimization criterion, and constraint relaxation
strategies should be applied in order for the service LSP(s) to have
a likelihood to be successfully established and provide necessary
QoS and resilience against network failures. The user- or
service-specific policies applied to PCC and are then passed to
the PCE along with the Path computation request, in the form of
constraints <xref target="RFC5394"/>. </t>
<t>PCEP speaker can use the generic mechanism as per
<xref target='I-D.minei-pce-association-group'/> to associate a set
of LSPs with policy and its resulting path computation constraints.
This simplified the path computation message exchanges.</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.minei-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 or
behaviors). A new optional Association Object is defined. This
document uses the same
association for attributes, called Attribute Association
Group (AAG) based on the generic Association object. This document
defines a new association type called "Attribute Association
Type" of value TBD. 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.minei-pce-association-group'/>.</t>
<t>One or more LSP are grouped via a single group identifier as
defined in <xref target='I-D.minei-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 Association 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Type - TBD 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="RFC7150"/>.</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=[TBD] | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is [TBD] 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. </t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines a new type 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.minei-pce-association-group'/> in itself.</t>
<t> Some deployments may find these 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.minei-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
TBD 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
TBD 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.minei-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.minei-pce-association-group"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5394.xml" ?>
<?rfc include="reference.RFC.6805.xml" ?>
<?rfc include="reference.RFC.7150.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<?rfc include="reference.I-D.ietf-pce-pceps"?>
</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[
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 560037
INDIA
EMail: udayasree.palle@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:24:28 |