One document matched: draft-dhody-pce-association-attr-01.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-01" 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>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</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="2014" />
<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 behaviors).
</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 behaviors).</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="AGID:">Association Group ID.</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).</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 way simplifying 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, 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 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 common group identifier in the same
way as <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.</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.</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 Association object used for AAG is shown in
<xref target='FIG1'/>:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="The Association Object format" 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 | Generic flags |R| Type-specific flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association group id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Type - TBD for the Attribute Association Type.</t>
<t>This document does not have any new type-specific flags.</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 behavioral
information, described in <xref target="RFC7150"/>.</t>
</list>
</t>
<section title="ATTRIBUTE-OBJECT-TLV" toc="default">
<t>The ATTRIBUTE-OBJECT-TLV 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-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The type of the TLV is [TBD] and it has a variable length. The value
part consist of the PCEP object header <xref target="RFC5440"/>
identifying the objects that are
associated with this AAG. Thus this TLV identify the attributes
present in the PCEP message that are associated with this group.
Future PCEP messages may only carry the AAG. </t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>TBD</t>
</section>
<section title="IANA Considerations" toc="default">
<t>TBD</t>
</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"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5394.xml" ?>
<?rfc include="reference.RFC.6805.xml" ?>
<?rfc include="reference.RFC.7150.xml" ?>
</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
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:24:06 |