PCE Working Group Francesco Lazzeri
Internet Draft Daniele Ceccarelli
Intended status: Standard Track Ericsson
Expires: November 2017 Young Lee
Huawei
May 12, 2017
Extensions to the Path Computation Element Protocol (PCEP) for residual
path bandwidth support
draft-lazzeri-pce-residual-bw-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 12, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
Lazzeri, et al. Expires November 12, 2017 [Page 1]
Internet-Draft PCEP residual bandwidth retrieval May 2017
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
The ability of a hierarchy of PCEs to compute accurate end-to-end
paths across multiple domains is recognized as an important
requirement in many applications.
This document describes extensions to the PCE Communication
Protocol (PCEP) in order to provide new path-related bandwidth
metrics, which a PCC, like a H-PCE (either stateful or stateless),
can use from an erstwhile path computation to deploy multiple LSPs
(having the same end-points and constraints) without additional
requests, until either the remaining bandwidth along that path is
all allocated or a deployment fails.
This information would also be beneficial for implementing
abstractions of the domain topology, building the abstract
connectivity incrementally, based only on really used constraints,
as soon as path computation results are returned.
Table of Contents
1. Requirements for managing the residual bandwidth as a metric..5
2. New metrics definition....................................... 6
2.1. Link and Path Unreserved bandwidth...................... 6
2.2. Link and Path Residual bandwidth........................ 6
3. PCEP protocol extensions..................................... 7
4. Non-Understanding/Non-Support Residual Bandwidth............. 9
4.1. Mode of Operation...................................... 10
5. Procedures.................................................. 11
6. IANA considerations ........................................ 11
6.1. METRIC types .......................................... 11
6.2. New Error-Values....................................... 11
7. Security Considerations..................................... 12
8. References ................................................. 13
8.1. Normative Reference ................................... 13
8.2. Informative References................................. 13
9. Contributors ............................................... 15
Authors' Addresses ............................................ 15
Intellectual Property Statement................................ 15
Disclaimer of Validity ........................................ 16
Lazzeri, et al. Expires November 12,2017 [Page 2]
Internet-Draft PCEP residual bandwidth retrieval May 2017
Introduction
Path computation of end-to-end routes spanning multiple domains is a
key requirement for networks with a centralized path computation
function (e.g. hierarchical PCE or SDN).
In such scenarios, a hierarchy of PCEs is often implemented, where,
as illustrated in [RFC6805], a parent PCE coordinates the operations
of a set of child (domain) PCEs in order to compute end-to-end paths
across the network.
In a hierarchical architecture of PCEs, domain PCEs just know the
topology of their domains, while the parent PCE has in general
detailed information about the managed domains and the relevant
inter-domain links, but not necessarily enough information about the
internals of each domain, so that it's capable to compute accurately
an end-to-end path.
One of the key features of SDN is the support of network
abstraction, that is, as described in [RFC7926], the capability of
applying policy to a set of information about a network, in order to
produce selective information that represents the potential ability
to connect across the domain.
The process of abstraction produces a connectivity graph, which can
be used by the parent PCE to compute an accurate path based on the
abstracted topology. The main issue is that the connectivity graph
can be huge, depending on the size of the domain topology and the
number of end-points defined on the edge of the domain.
One way to provide similar information is to store the result of
path computations requested to the child PCEs (performed by e.g. TE-
tunnels "compute only") and try reusing them if possible to save
further path computation iterations between parent and child PCEs.
In any case a selection of path computation constraints has to be
defined against the abstract topology in order to reduce the number
of the abstract links or TE-tunnels exported by the connectivity
graph, as it's impractical to compute or pre-compute all the
constraints combinations. It's also very important to reduce the
number of updates of such connectivity information to the parent PCE
in order not to flood it with a continuous stream of updates.
The objective of this document is to define an extension to the PCEP
[RFC5440] providing information about the bandwidth still available
for future reservations on a given path, that is the minimum
unreserved bandwidth and the minimum residual bandwidth among all
the link of that path.
This is not a new concept to PCEP. In [RFC5541] two objective
functions are defined, called minimum load path (MLP) and maximum
Lazzeri, et al. Expires November 12,2017 [Page 3]
Internet-Draft PCEP residual bandwidth retrieval May 2017
residual bandwidth path (MBP). Both of them allow to find paths with
optimal value of bandwidth-related metrics, defined on a per-link
basis, considering the links traversed by that path. For example,
the residual bandwidth of a path is defined as the minimum value of
the residual bandwidth on each link in the path. Specifying that OF
inside the SVEC object of a PCReq message, the PCE tries and finds
the path with the maximum value of the path residual bandwidth.
Unfortunately, being an objective function, MBP can only be used to
find a path that optimizes the residual bandwidth, but its value
cannot be returned for a path computed with some other objectives
(and also when MBP itself is used), or used as a bound.
The same applies to the unreserved bandwidth. The difference between
residual and unreserved bandwidth is well described in [RFC7471]:
"The calculation of Residual Bandwidth is different than that of
Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts
tunnel reservations from Maximum Bandwidth (i.e., the link
capacity) [RFC3630] and provides an aggregated remainder across
priorities. Unreserved Bandwidth, on the other hand, is
subtracted from the Maximum Reservable Bandwidth (the bandwidth
that can theoretically be reserved) and provides per priority
remainders. Residual Bandwidth and Unreserved Bandwidth
[RFC3630] can be used concurrently, and each has a separate use
case (e.g., the former can be used for applications like Weighted
ECMP while the latter can be used for call admission control)".
Having this information would allow a PCC (e.g. a parent PCE) to
reuse a path resulting from a path computation to route additional
LSPs without requesting new path computations (with the same end-
points and constraints), until the maximum path unreserved bandwidth
is taken (or a path deployment fails).
This information would be also beneficial for implementing an
abstraction of the domain topology by building a domain abstract
topology incrementally, possibly starting from a simple pre-computed
base, and adding abstract information as new path computations are
requested by the client, using only really used constraints.
Lazzeri, et al. Expires November 12,2017 [Page 4]
Internet-Draft PCEP residual bandwidth retrieval May 2017
1. Requirements for managing the residual bandwidth as a metric
Path computation with optimization of the load or of the residual
bandwidth has been defined as important objective functions in
[RFC5541].
Managing the unreserved bandwidth (related to the load) and the
residual bandwidth of a path as additional metrics, adds the
capability to return their value, or putting a bound on their value.
This is an added value in distributed PCE applications, like e.g. in
ACTN architecture [ACTN-FW] and [PCE-APP]. The following associated
key requirements are identified for PCEP:
1. A PCE supporting this draft MUST have the capability to
compute end-to-end (E2E) paths with either unreserved bandwidth or
with residual bandwidth constraints. It MUST also support the
combination of these new constraints with existing constraints, like
IGP metric, TE metric, hop limit, and network performance
constraints as defined in [RFC5440] and [PCEP-SERV-AWARE].
2. A PCC MUST be able to specify either unreserved bandwidth or
residual bandwidth constraints in a Path Computation Request (PCReq)
message to be applied during the path computation.
3. A PCC MUST be able to request that a PCE optimizes a path
using either unreserved bandwidth or residual bandwidth as objective
metric.
4. A PCE that supports this specification is not required to
provide unreserved bandwidth or residual bandwidth path computation
to any PCC at any time.
Therefore, it MUST be possible for a PCE to reject a PCReq
message with reason codes that indicate unreserved bandwidth or
residual bandwidth is not supported. Furthermore, a PCE that does
not support this specification will either ignore or reject such
requests using pre-existing mechanisms, therefore the requests MUST
be identifiable to legacy PCEs and rejections by legacy PCEs MUST be
acceptable within this specification.
5. A PCE that supports this specification MUST be able to return
unreserved or residual bandwidth information of the computed path in
a Path Computation Reply (PCRep) message.
Lazzeri, et al. Expires November 12,2017 [Page 5]
Internet-Draft PCEP residual bandwidth retrieval May 2017
2. New metrics definition
2.1. Link and Path Unreserved bandwidth
The unreserved bandwidth of a link is the bandwidth available for
future allocation on the link at a given priority, that is the
difference between the Maximum Reservable Bandwidth of the link and
total bandwidth used on that link by LSPs with priority equal or
lower (higher value) than the specified priority. In order to define
the path unreserved bandwidth, the following concepts and notation
need to be introduced:
o A network comprises of a set of N links {Li, (i=1...N)}.
o A path of a point to point (P2P) LSP is a list of K links
{Lpi,(i=1...K)}.
o The maximum reservable bandwidth of the link Li, named Ri.
o The bandwidth allocated to LSPs at priority p on the link Li is
the sum of the bandwidth of all the LSPs passing through the
link Li with priority >= p, named Bi(p).
o The unreserved bandwidth at priority p of the link Li is
Ui(p) = Ri - Bi(p)
The path unreserved bandwidth at a given priority k is defined
as the minimum value of the unreserved bandwidth at priority k among
all the links along the P2P path. Specifically, extending on the
above mentioned terminology:
o Path unreserved bandwidth metric at priority is defined as:
PU(p) = min {Ui(p), (i=1...K)}
2.2. Link and Path Residual bandwidth
The residual bandwidth of a link is the bandwidth physically left
free for future allocation on the link. In order to define the path
residual bandwidth, the following concepts and notation need to be
introduced:
o A network comprises of a set of N links {Li, (i=1...N)}.
Lazzeri, et al. Expires November 12,2017 [Page 6]
Internet-Draft PCEP residual bandwidth retrieval May 2017
o A path of a point to point (P2P) LSP is a list of K links
{Lpi,(i=1...K)}
o The maximum bandwidth of the link Li, named Bi.
o The sum of the bandwidth of all the LSPs passing through the
link Li, that is the bandwidth allocated on the link, named Ai.
o The residual bandwidth of the link Li is r(i) = Bi - Ai.
The path residual bandwidth is defined as the minimum value of the
residual bandwidth among all the links along the P2P path.
Specifically, extending on the above mentioned terminology:
o Path residual bandwidth metric for the P2P path is defined as:
PB = min {r(Lpi), (i=1...K)}
3. PCEP protocol extensions
This section defines PCEP extensions to fulfill the requirements
outlined in Section 2. The proposed solution is used to support
path unreserved bandwidth and path residual bandwidth as additional
metrics of the PCEP protocol.
The METRIC object is defined in section 7.8 of [RFC5440], comprising
metric-value, metric-type (T field) and a flags field comprising a
number of bit-flags.
This document defines two new types for the METRIC object:
T = TBD1: Path Unreserved Bandwidth
When the T field is set to TBD1, the value of the metric-value field
is set to the Path Unreserved Bandwidth for the traffic type and
priority requested in the PCReq message.
The same format used by [RFC5440] for the BANDWIDTH object body is
used here to represent the value of a path unreserved bandwidth
bound or returned value, as shown in the following:
Lazzeri, et al. Expires November 12,2017 [Page 7]
Internet-Draft PCEP residual bandwidth retrieval May 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Unreserved Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH UNRESERVED BANDWIDTH value format
Path Unreserved Bandwidth (32 bits): The path unreserved
bandwidth is encoded in 32 bits in IEEE floating point format (see
[IEEE.754.1985]), expressed in bytes per second.
The PATH UNRESERVED BANDWIDTH value has a fixed length of 4
bytes.
T = TBD2: Path Residual Bandwidth
When the T field is set to TBD2, the value of the metric-value field
is set to the Path Residual Bandwidth for the traffic type requested
in the PCReq message.
When the T field is set to TBD2, the value of the metric-value field
is set to the Path Residual Bandwidth for the traffic type requested
in the PCReq message.
The same format used by [RFC5440] for the BANDWIDTH object body is
used here to represent the value of a path residual bandwidth bound
or returned value, as shown in the following:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH RESIDUAL BANDWIDTH value format
Path Residual Bandwidth (32 bits): The path residual bandwidth
is encoded in 32 bits in IEEE floating point format (see
[IEEE.754.1985]), expressed in bytes per second.
The PATH RESIDUAL BANDWIDTH value has a fixed length of 4 bytes.
Lazzeri, et al. Expires November 12,2017 [Page 8]
Internet-Draft PCEP residual bandwidth retrieval May 2017
Editor NOTE: these definitions provide support only of PSC signal
type. For other signal types (e.g. ODU, WDM) these fields can be
filled with the number of unreserved or residual fixed containers
(e.g. 3 ODU0) related to the type of traffic specified in the PCReq.
This has to be discussed.
A PCC MAY use the path unreserved or residual bandwidth in a PCReq
message to request a path meeting the end to end unreserved or
residual bandwidth requirement. In this case, the B bit MUST be set
to suggest a bound (a minimum) for the path residual bandwidth
metric that must be guaranteed for the PCC to consider the computed
path as acceptable. The path unreserved or residual bandwidth
metrics must be greater than or equal to the value specified in the
metric-value field.
The P bit MAY be set to specify the constraint as mandatory, or MAY
be left cleared to specify the bound as optional.
A PCC can also use this metric to ask PCE to optimize (that is
maximize) the path residual bandwidth during path computation.
In this case, the B bit MUST be cleared.
A PCE MAY use the path residual bandwidth metric in a PCRep
message along with a NO-PATH object in the case where the PCE cannot
compute a path meeting this constraint.
A PCE can also use this metric to send the computed path residual
bandwidth metric to the PCC.
4. Non-Understanding/Non-Support Residual Bandwidth
If a PCE receives a PCReq message containing a METRIC object with
type PATH UNRESERVED BANDWIDTH or PATH RESIDUAL BANDWIDTH and the
PCE does not understand or support those metric types, and the P bit
is clear in the METRIC object header then the PCE SHOULD simply
ignore the METRIC object as per the processing specified in
[RFC5440].
If the PCE does not understand the new METRIC types, and the P
bit is set in the METRIC object header, then the PCE MUST send a
PCErr message containing a PCEP-ERROR Object with Error-Type = 4
Lazzeri, et al. Expires November 12,2017 [Page 9]
Internet-Draft PCEP residual bandwidth retrieval May 2017
(Not supported object) and Error-value = 4 (Unsupported parameter)
[RFC5440][RFC5541].
If the PCE understands but does not support the new METRIC type,
and the P bit is set in the METRIC object header, then the PCE MUST
send a PCErr message containing a PCEP-ERROR Object with Error-Type
= 4 (Not supported object) with Error-value = TBD3 (Unsupported path
unreserved bandwidth constraint) or TBD4 (Unsupported path residual
bandwidth constraint).
The path computation request MUST then be cancelled.
If the PCE understands the new METRIC type, but the local policy
has been configured on the PCE to not allow network performance
constraint, and the P bit is set in the METRIC object header, then
the PCE MUST send a PCErr message containing a PCEP-ERROR Object
with Error-Type = 5 (Policy violation) with Error-value = TBD5 (Not
Allowed path unreserved bandwidth constraint) or TBD6 (Not
Allowed path residual bandwidth constraint). The path computation
request MUST then be cancelled.
4.1. Mode of Operation
As explained in [RFC5440], the METRIC object is optional and can
be used for several purposes. In a PCReq message, a PCC MAY insert
one or more METRIC objects:
o To indicate the metric (path unreserved or path residual
bandwidth) that MUST be optimized by the path computation
algorithm.
o To indicate a bound on the METRIC (path unreserved or path
residual bandwidth) that MUST NOT be exceeded for the path to be
considered as acceptable by the PCC.
In a PCRep message, the PCE MAY insert the METRIC object with an
Explicit Route Object (ERO) so as to provide the METRIC (residual
bandwidth) for the computed path.
The PCE MAY also insert the METRIC object with a NO-PATH object to
indicate that the metric constraint could not be satisfied.
The path computation algorithmic aspects used by the PCE to
optimize a path with respect to a specific metric are outside the
scope of this document.
All the rules of processing the METRIC object as explained in
[RFC5440] are applicable to the new metric types as well.
Lazzeri, et al. Expires November 12,2017 [Page 10]
Internet-Draft PCEP residual bandwidth retrieval May 2017
5. Procedures
The new metrics defined in this document don't add or change the
procedures already defined for PCEP protocol in [RFC5440] and
[RFC5541].
In particular, the existing objective function MBP is still usable
as appropriate, being equivalent to the usage of the Path Residual
Bandwidth metric with the B bit cleared.
The new metric can be used to define new procedures especially in
the scope of SDN and ACTN, which are out of the scope of this
document.
6. IANA considerations
6.1. METRIC types
IANA maintains the "Path Computation Element Protocol (PCEP)
Numbers" at <http://www.iana.org/assignments/pcep>. Within this
registry IANA maintains one sub-registry for "METRIC object T
field".
Two new metric types are defined in this document for the METRIC
object (specified in [RFC5440]).
IANA is requested to make the following allocations:
Value Description Reference
----------------------------------------------------------
TBD1 Path unreserved bandwidth metric [This I.D.]
TBD2 Path residual bandwidth metric [This I.D.]
6.2. New Error-Values
IANA maintains a registry of Error-Types and Error-values for use
in PCEP messages. This is maintained as the "PCEP-ERROR Object
Error Types and Values" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry.
IANA is requested to make the following allocations:
Lazzeri, et al. Expires November 12,2017 [Page 11]
Internet-Draft PCEP residual bandwidth retrieval May 2017
Four new Error-values are defined for the Error-Type "Not
supported object" (type 4) and "Policy violation" (type 5).
Error-Type Meaning and error values Reference
4 Not supported object
Error-value=TBD3 Unsupported [This I.D.]
Path unreserved bandwidth constraint
Error-value=TBD4 Unsupported
Path residual bandwidth constraint
5 Policy violation
Error-value=TBD5 Not allowed [This I.D.]
Path unreserved bandwidth constraint
Error-value=TBD6 Not allowed
Path residual bandwidth constraint
7. Security Considerations
This document defines new METRIC types, which do not add any new
security concerns beyond those discussed in [RFC5440] and [RFC5541]
in itself.
In some scenarios, path unreserved bandwidth and path residual
bandwidth information could be considered sensitive and could be
used to influence path computation and setup with adverse effect.
Snooping of PCEP messages with such data, or using PCEP messages for
network reconnaissance, may give an attacker sensitive information
about the capabilities of the network. Thus, such deployment should
employ suitable PCEP security mechanisms like TCP Authentication
Option (TCP-AO) [RFC5925] or [PCEPS].
The Transport Layer Security (TLS) based procedure in [PCEPS] is
considered as a security enhancement and thus much better suited for
the sensitive residual bandwidth information.
Lazzeri, et al. Expires November 12,2017 [Page 12]
Internet-Draft PCEP residual bandwidth retrieval May 2017
8. References
8.1. Normative References
[RFC5440] Vasseur JP., Ed. and JL. Le Roux, Ed.,
"Path Computation Element (PCE) Communication
Protocol(PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee,
"Encoding of Objective Functions in the Path
Computation Element Communication Protocol (PCEP)",
RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica,
"The TCP Authentication Option", RFC 5925,
DOI 10.17487/RFC5925, June 2010,
<http://www.rfc-editor.org/info/rfc5925>.
[RFC7420] Koushik A.,Stephan E.,Zhao Q.,King D. and J.Hardwick,
"Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>.
[PCEPS] Lopez, D.Lopez, D., Dios, O., Wu, W., and D. Dhody,
"Secure Transport for PCEP", draft-ietf-pce-pceps-11
(work in progress), January 2017.
[IEEE.754.1985] IEEE, "Standard for Binary Floating-Point Arithmetic",
IEEE 754, August 1985
8.2. Informative References
[RFC6805] King, D., Ed., and A. Farrel, Ed.,
"The Application of the Path Computation Element
Architecture to the Determination of a Sequence of
Domains in MPLS and GMPLS", RFC 6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[RFC7471] Giacalone S., Ward D., Drake J., Atlas A. and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471,
Lazzeri, et al. Expires November 12,2017 [Page 13]
Internet-Draft PCEP residual bandwidth retrieval May 2017
DOI 10.17487/RFC7471, March 2015,
<http://www.rfc-editor.org/info/rfc7471>
[RFC7926] Farrel, A. et al., "Problem Statement and Architecture
for Information Exchange Between Interconnected
Traffic Engineered Networks", RFC 7926, July 2016.
[ACTN-FW] Ceccarelli, D. and Y. Lee, "Framework for Abstraction
and Control of Traffic Engineered Networks", draft-
ietf-teas-actn-framework-03 (work in progress),
February 2017.
[PCE-APP] Dhody, D. Lee, Y. Ceccarelli, D. "Applicability of
Path Computation Element (PCE) for Abstraction and
Control of TE Networks (ACTN)" draft-dhody-pce-
applicability-actn-02
Lazzeri, et al. Expires November 12,2017 [Page 14]
Internet-Draft PCEP residual bandwidth retrieval May 2017
9. Contributors
Authors' Addresses
Francesco Lazzeri
Ericsson
Via Melen 77
Genova - Italy
Email: francesco.lazzeri@ericsson.com
Daniele Ceccarelli
Ericsson AB
Gronlandsgatan 21
Kista - Stockholm
Email: daniele.ceccarelli@ericsson.com
Young Lee (Editor)
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Lazzeri, et al. Expires November 12,2017 [Page 15]
Internet-Draft PCEP residual bandwidth retrieval May 2017
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lazzeri, et al. Expires November 12,2017 [Page 16]