One document matched: draft-wu-pce-pcep-link-bw-utilization-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 category="std" docName="draft-wu-pce-pcep-link-bw-utilization-01"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="TE Link BW Utilization">Extensions to Path Computation
Element Communication Protocol (PCEP) for handling Link Bandwidth
Utilization</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">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>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody">
<organization abbrev="Huawei">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="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc</organization>
<address>
<postal>
<street>Via Del Serafico 200 </street>
<city>Rome</city>
<code>00191 </code>
<country>IT</country>
</postal>
<email>sprevidi@cisco.com </email>
</address>
</author>
<date month="January" year="2014" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs)
requests.</t>
<t>Link bandwidth utilization considering the total bandwidth of a link
in current use for the forwarding is an important factor to consider
during path computation. This document describes extensions to PCEP to
consider them as new constraints during path computation.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>Real time link bandwidth utilization is becoming critical in the path
computation in some networks. It is important that link bandwidth
utilization is factored in during path computation. PCC can request a
PCE to provide a path such that it selects under-utilized links. This
document extends PCEP <xref target="RFC5440"></xref> for this
purpose.</t>
<t>Traffic Engineering Database (TED) as populated by Interior Gateway
Protocol (IGP) contains Maximum bandwidth, Maximum reservable bandwidth
and Unreserved bandwidth (<xref target="RFC3630"></xref> and <xref
target="RFC3784"></xref>). <xref target="OSPF-TE-EXPRESS"></xref> and
<xref target="ISIS-TE-EXPRESS"></xref> further populate Residual
bandwidth, Available bandwidth and Utilized bandwidth.</t>
<t>The links in the path MAY be monitored for changes in the link
bandwidth utilization, re-optimization of such path MAY be further
requested.</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"></xref>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t><list style="hanging">
<t hangText="IGP:">Interior Gateway Protocol. Either of the two
routing protocols, Open Shortest Path First (OSPF) or Intermediate
System to Intermediate System (IS-IS).</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 Protocol.</t>
<t hangText="RSVP:">Resource Reservation Protocol</t>
<t hangText="TE LSP:">Traffic Engineering Label Switched Path.</t>
</list></t>
</section>
<section anchor="SEC_LBU" title="Link Bandwidth Utilization (LBU)"
toc="default">
<t>The bandwidth utilization on a link, forwarding adjacency, or bundled
link is populated in the TED (Utilized Bandwidth in
<xref target="OSPF-TE-EXPRESS"></xref> and <xref
target="ISIS-TE-EXPRESS"></xref>). For a link or forwarding adjacency,
bandwidth utilization represent the actual utilization of the link
(i.e.: as measured in the router). For a bundled link, bandwidth
utilization is defined to be the sum of the component link bandwidth
utilization. This includes traffic for both RSVP and non-RSVP.</t>
<t>LBU Percentage is described as the (LBU / Maximum bandwidth) *
100.</t>
</section>
<section anchor="SEC_LRBU"
title="Link Reserved Bandwidth Utilization (LRBU)" toc="default">
<t>The reserved bandwidth utilization on a link, forwarding adjacency,
or bundled link can be calculated from the TED. This includes traffic
for only RSVP-TE LSPs.</t>
<t>LRBU can be calculated by using the Residual bandwidth, Available
bandwidth and LBU. The actual bandwidth by non-RSVP TE traffic can be
calculated by subtracting Available Bandwidth from Residual Bandwidth.
Once we have the actual bandwidth for non-RSVP TE traffic, subtracting
this from LBU would result in LRBU.</t>
<t>LRBU Percentage is described as the (LRBU / (current reserved
bandwidth)) * 100; where the current reserved bandwidth can be
calculated by subtracting Residual bandwidth from Maximum bandwidth.</t>
</section>
<section anchor="SEC_R" title="PCEP Requirements" toc="default">
<t>Following requirements associated with bandwidth utilization are
identified for PCEP:</t>
<t><list style="numbers">
<t>PCE supporting this draft MUST have the capability to compute
end-to-end path with bandwidth utilization constraints. It MUST also
support the combination of bandwidth utilization constraint with
existing constraints (cost, hop-limit...).</t>
<t>PCC MUST be able to request for bandwidth utilization constraint
in PCReq message as the boundary condition that should not be
crossed for each link in the path.</t>
<t>PCC MUST be able to request for bandwidth utilization constraint
in PCReq message as an Objective function (OF) <xref
target="RFC5541"></xref> to be optimized.</t>
<t>PCEs are not required to support bandwidth utilization
constraint. Therefore, it MUST be possible for a PCE to reject a
PCReq message with a reason code that indicates no support for
bandwidth utilization constraint.</t>
<t>PCEP SHOULD provide mechanism to handle bandwidth utilization
constraint in multi-domain (e.g., Inter-AS, Inter-Area or
Multi-Layer) environment.</t>
</list></t>
</section>
<section title="PCEP Extensions" toc="default">
<t>This section defines extensions to PCEP <xref
target="RFC5440"></xref> for requirements outlined in <xref
target="SEC_R"></xref>. The proposed solution is used to consider
bandwidth utilization during path computation.</t>
<section title="BU Object" toc="default">
<t>The BU (Bandwidth Utilization) is used to indicate the upper limit
of the acceptable link bandwidth utilization percentage.</t>
<t>The BU object may be carried within the PCReq message and PCRep
messages.</t>
<t>BU Object-Class is TBD.</t>
<t>BU Object-Type is 1.</t>
<t>The format of the BU object body is as follows:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="BU Object Body Format" width="">
<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 | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Reserved (24 bits):">This field MUST be set to zero
on transmission and MUST be ignored on receipt.</t>
<t hangText="Type (8 bits):">Represents the bandwidth utilization
type. Link Bandwidth Utilization (LBU) Type is 1 and
Link Reserved Bandwidth Utilization (LRBU) Type is
2.</t>
<t hangText="Bandwidth utilization (32 bits):">Represents the
bandwidth utilization quantified as a percentage (as described in
<xref target="SEC_LBU"></xref> and <xref
target="SEC_LRBU"></xref>). The basic unit is 0.000000023%, with
the maximum value 4,294,967,295 representing 98.784247785%
(4,294,967,295 * 0.000000023%). This value is the maximum
Bandwidth utilization percentage that can be expressed.</t>
</list></t>
<t>The BU object body has a fixed length of 8 bytes.</t>
<section anchor="SEC_N" title="Elements of Procedure" toc="default">
<t>PCC SHOULD request the PCE to factor in the bandwidth utilization
during path computation by including a BU object in the PCReq
message.</t>
<t>Multiple BU objects MAY be inserted in a PCReq or a PCRep message
for a given request but there MUST be at most one instance of the BU
object for each type. If, for a given request, two or more
instances of a BU object with the same type are present, only
the first instance MUST be considered and other instances MUST be
ignored.</t>
<t>BU object MAY be carried in a PCRep message in case of
unsuccessful path computation along with a NO-PATH object to
indicate the constraints that could not be satisfied.</t>
<t>If the P bit is clear in the object header and PCE does not
understand or does not support bandwidth utilization during path
computation it SHOULD simply ignore BU object.</t>
<t>If the P Bit is set in the object header and PCE receives BU
object in path request and it understands the BU object, but the PCE
is not capable of bandwidth utilization check during path
computation, the PCE MUST send a PCErr message with a PCEP-ERROR
Object Error-Type = 4 (Not supported object) <xref
target="RFC5440"></xref>. The path computation request MUST then be
cancelled.</t>
<t>If the PCE does not understand the BU object, then the PCE MUST
send a PCErr message with a PCEP-ERROR Object Error-Type = 3
(Unknown object) <xref target="RFC5440"></xref>.</t>
</section>
</section>
<section title="New Objective Functions" toc="default">
<t>This document defines two additional objective functions -- namely,
MUP (Maximum Under-Utilized Path) and MRUP (Maximum Reserved
Under-Utilized Path. Hence two new objective function codes have to be
defined.</t>
<t>Objective functions are formulated using the following
terminology:</t>
<t><list style="symbols">
<t>A network comprises a set of N links {Li, (i=1...N)}.</t>
<t>A path P is a list of K links {Lpi,(i=1...K)}.</t>
<t>Bandwidth Utilization on link L is denoted u(L).</t>
<t>Reserved Bandwidth Utilization on link L is denoted ru(L).</t>
<t>Maximum bandwidth on link L is denoted M(L).</t>
<t>Current Reserved bandwidth on link L is denoted c(L).</t>
</list></t>
<t>The description of the two new objective functions is as
follows.</t>
<t><list style="hanging">
<t hangText="Objective Function Code:">TBD</t>
<t><list>
<t>Name: Maximum Under-Utilized Path (MUP)</t>
<t>Description: Find a path P such that (Min {(M(Lpi)- u(Lpi))
/ M(Lpi), i=1...K } ) is maximized.</t>
</list></t>
</list></t>
<t><list style="hanging">
<t hangText="Objective Function Code:">TBD</t>
<t><list>
<t>Name: Maximum Reserved Under-Utilized Path (MRUP)</t>
<t>Description: Find a path P such that (Min {(c(Lpi)-
ru(Lpi)) / c(Lpi), i=1...K } ) is maximized.</t>
</list></t>
</list></t>
<t>These new objective function are used to optimize paths based on
bandwidth utilization as the optimization criteria.</t>
<t>If the objective function defined in this document are
unknown/unsupported, the procedure as defined in <xref
target="RFC5541"></xref> is followed.</t>
</section>
<section title="PCEP Message Extension" toc="default">
<section title="The PCReq message" toc="default" anchor="SEC_REQ">
<t>The new optional BU objects MAY be specified in the PCReq message.
As per <xref target="RFC5541"></xref>, an OF object specifying a new
objective function MAY also be specified.</t>
<t>The format of the PCReq message (with <xref
target="RFC5541"></xref> as a base) is updated as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC>[<metric-list>]
</artwork>
</figure>
</section>
<section title="The PCRep message" toc="default" anchor="SEC_REP">
<t>The BU objects MAY be specified in the PCRep message, in case of an
unsuccessful path computation to indicate the bandwidth utilization as
a reason for failure. The OF object MAY be carried within a PCRep
message to indicate the objective function used by the PCE during path
computation.</t>
<t>The format of the PCRep message (with <xref
target="RFC5541"></xref> as a base) is updated as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<IRO>]
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC> [<metric-list>]
</artwork>
</figure>
</section>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="Reoptimization Consideration" toc="default">
<t>PCC can monitor the link bandwidth utilization of the setup LSPs
(change in TED bandwidth parameters of one or more links in the path)
and in case of drastic change, it MAY ask PCE for reoptimization as
per <xref target="RFC5440"></xref>.</t>
</section>
<section title="Inter-domain Consideration" toc="default">
<t><xref target="RFC5441"/> describes the Backward-Recursive
PCE-Based Computation (BRPC) procedure to compute end to end
optimized inter-domain path by cooperating PCEs. The new BU object
defined in this document can be applied to end to end path
computation, in similar manner as existing METRIC object. </t>
<t>All domains should have the same understanding of the BU object
for end-to-end inter-domain path computation
to make sense.</t>
<section title="Inter-AS Link" toc="default">
<t>The IGP in each neighbor domain can advertise its inter-domain
TE link capabilities, this has been described in <xref target="RFC5316"/>
(ISIS) and <xref target="RFC5392"/> (OSPF). The bandwidth related network
performance link properties are described in <xref target="OSPF-TE-EXPRESS"/> and
<xref target="ISIS-TE-EXPRESS"/>, the same properties must be advertised
using the mechanism described in <xref target="RFC5392"/> (OSPF) and
<xref target="RFC5316"/> (ISIS).</t>
</section>
</section>
<section title="P2MP Consideration" toc="default">
<t>TBD</t>
</section>
<section title="Stateful PCE" toc="default">
<t><xref target="STATEFUL-PCE"></xref> specifies a set of
extensions to PCEP to enable
stateful control of MPLS-TE and GMPLS LSPs via PCEP and maintaining
of these LSPs at the stateful PCE. It further distinguishes between
an active and a passive stateful PCE. A passive stateful PCE uses LSP state
information learned from PCCs to optimize path computations but does
not actively update LSP state. In contrast, an active stateful PCE
utilizes the delegation mechanism to let PCCs relinquish control
over some LSPs to the PCE. </t>
<t>The passive stateful PCE implementation MAY use the extension of
PCReq and PCRep messages as defined in <xref target="SEC_REQ"/> and
<xref target="SEC_REP"/> to enable the use of BU object.</t>
<t>The additional objective functions defined in this document can also
be used with stateful PCE.</t>
<section title="PCEP Message Extension" toc="default">
<section title="The PCRpt message" toc="default">
<t>A Path Computation LSP State
Report message (also referred to as PCRpt message) is a PCEP message
sent by a PCC to a PCE to report the current state or delegate control
of an LSP. The PCRpt message is extended to support BU object
(to optionally specify the boundary condition that should not be crossed).</t>
<t>As per <xref target="STATEFUL-PCE"></xref>, the format of the PCRpt
message is as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCRpt Message> ::= <Common Header>
<state-report-list>
where:
<state-report-list> ::= <state-report> [<state-report-list>]
<state-repor> ::= [<SRP>]
<LSP>
<path>
<path> ::= <ERO><attribute-list>[<RRO>]
</artwork>
</figure>
<t>Where <attribute-list> is extended as per <xref target="SEC_REP"/>.</t>
<t>Thus the BU object can be used to specify the boundary condition set at the PCC at the
time of delegation to active stateful PCE.</t>
</section>
</section>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>IANA assigns values to PCEP parameters in registries defined in
<xref target="RFC5440"/>. IANA has made the following additional assignments.</t>
<section title="New PCEP Object" toc="default">
<t>IANA assigned a new object class in the registry of PCEP Objects as
follows.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Object Object Name Reference
Class Type
--------------------------------------------------
TBD 1 BU [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="BU Object" toc="default">
<t>IANA created a registry to manage the codespace of the Type field
of the METRIC Object.</t>
<t>Codespace of the T field (Metric Object)</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Type Name Reference
--------------------------------------------------
1 LBU (Link Bandwidth [This I.D.]
Utilization
2 LRBU (Link Residual [This I.D.]
Bandwidth Utilization
]]></artwork>
</figure>
</t>
</section>
<section title="Objective Functions" toc="default">
<t>Two new Objective Functions have been
defined. IANA has made the following allocations from the PCEP
"Objective Function" sub-registry:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Code Name Reference
Point
--------------------------------------------------
TBA Maximum Under-Utilized [This I.D.]
Path (MUP)
TBA Maximum Reserved [This I.D.]
Under-Utilized Path (MRUP)
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines a new BU object and OF codes which does not add
any new security concerns beyond those discussed in <xref
target="RFC5440"></xref>.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>The only configurable item is the support of the new constraints on
a PCE which MAY be controlled by a policy module. If the new
constraints are not supported/allowed on a PCE, it MUST send a PCErr
message as specified in <xref target="SEC_N"></xref>.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="PCEP-MIB"></xref> 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"></xref>.</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"></xref>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>PCE requires the TED to be populated with the bandwidth
utilization. This mechanism is described in <xref
target="OSPF-TE-EXPRESS"></xref> or <xref
target="ISIS-TE-EXPRESS"></xref>.</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"></xref>.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Alia Atlas, John E Drake and David Ward
for their
useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3630.xml" ?>
<?rfc include="reference.RFC.3784.xml" ?>
<?rfc include="reference.RFC.5316.xml" ?>
<?rfc include="reference.RFC.5392.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<!--OSPF-TE-EXPRESS-->
<reference anchor="OSPF-TE-EXPRESS">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions
[draft-ietf-ospf-te-metric-extensions]</title>
<author fullname="Spencer Giacalone" initials="S"
surname="Giacalone">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D" surname="Ward">
<organization></organization>
</author>
<author fullname="John Drake" initials="J" surname="Drake">
<organization></organization>
</author>
<author fullname="Alia Atlas" initials="A" surname="Atlas">
<organization></organization>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization></organization>
</author>
<date month="December" year="2013" />
</front>
</reference>
<!--ISIS-TE-EXPRESS-->
<reference anchor="ISIS-TE-EXPRESS">
<front>
<title>IS-IS Traffic Engineering (TE) Metric Extensions
[draft-ietf-isis-te-metric-extensions-01]</title>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization></organization>
</author>
<author fullname="Spencer Giacalone" initials="S"
surname="Giacalone">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D" surname="Ward">
<organization></organization>
</author>
<author fullname="John Drake" initials="J" surname="Drake">
<organization></organization>
</author>
<author fullname="Alia Atlas" initials="A" surname="Atlas">
<organization></organization>
</author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<organization></organization>
</author>
<author fullname="Qin Wu" initials="W" surname="Qin">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<!--PCEP-MIB-->
<reference anchor="PCEP-MIB">
<front>
<title>PCE communication protocol(PCEP) Management Information Base
[draft-ietf-pce-pcep-mib]</title>
<author fullname="Kiran Koushik A S" initials="A S"
surname="Kiran Koushik">
<organization></organization>
</author>
<author fullname="Stephan E" initials="E" surname="Stephan">
<organization></organization>
</author>
<author fullname="Quintin Zhao" initials="Q" surname="Zhao">
<organization></organization>
</author>
<author fullname="Daniel King" initials="D" surname="King">
<organization></organization>
</author>
<author fullname="John Hardwick" initials="J" surname="Hardwick">
<organization></organization>
</author>
<date month="July" year="2013" />
</front>
</reference>
<!--STATEFUL-PCE-->
<reference anchor="STATEFUL-PCE">
<front>
<title>PCEP Extensions for Stateful PCE
[draft-ietf-pce-stateful-pce]</title>
<author fullname="Edward Crabbe" initials="E"
surname="Crabbe">
<organization></organization>
</author>
<author fullname="Jan Medved" initials="J" surname="Medved">
<organization></organization>
</author>
<author fullname="Ina Minei" initials="I" surname="Minei">
<organization></organization>
</author>
<author fullname="Robert Varga" initials="R" surname="Varga">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
</references>
<section title="Contributor Addresses" toc="default">
<t><figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
Avantika
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: avantika.sushilkumar@huawei.com
</artwork>
</figure></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:17 |