Internet DRAFT - draft-lazzeri-pce-residual-bw
draft-lazzeri-pce-residual-bw
PCE Working Group Francesco Lazzeri
Internet Draft Daniele Ceccarelli
Intended status: Standard Track Ericsson
Expires: August 2018 Young Lee
Dhruv Dhody
Huawei
February 26, 2018
Extensions to the Path Computation Element Protocol (PCEP) for residual
path bandwidth support
draft-lazzeri-pce-residual-bw-01
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 August 26, 2018.
Copyright Notice
Copyright (c) 2018 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
Lazzeri, et al. Expires August 26, 2018 [Page 1]
Internet-Draft PCEP residual bandwidth retrieval February 2018
carefully, as they describe your rights and restrictions with
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 PCEP protocol has objective functions to optimize path
attributes like the residual bandwidth. While this is enough for
some applications, it's not possible to return the computed values
of such attributes to the PCC, or put bounds on them.
This document describes extensions to the PCE Communication
Protocol (PCEP) providing new path-related bandwidth metrics
allowing a PCE to compute paths taking into account and returning to
the PCC information about the remaining bandwidth along the computed
paths.
Table of Contents
1. Requirements for managing the residual bandwidth as a metric...4
2. New metrics definition.........................................5
2.1. Link and Path Unreserved bandwidth........................5
2.2. Link and Path Residual bandwidth..........................5
3. PCEP protocol extensions.......................................6
4. Non-Understanding/Non-Support Residual Bandwidth...............8
4.1. Mode of Operation.........................................9
5. Procedures....................................................10
5.1. Use cases................................................10
6. IANA considerations...........................................11
6.1. METRIC types.............................................11
6.2. New Error-Values.........................................12
7. Security Considerations.......................................12
8. References....................................................13
8.1. Normative References.....................................13
8.2. Informative References...................................14
9. Contributors..................................................15
Authors' Addresses...............................................15
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
Lazzeri, et al. Expires August 26,2018 [Page 2]
Internet-Draft PCEP residual bandwidth retrieval February 2018
Introduction
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 links 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
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 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).
Lazzeri, et al. Expires August 26,2018 [Page 3]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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 August 26,2018 [Page 4]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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 August 26,2018 [Page 5]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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 August 26,2018 [Page 6]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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 August 26,2018 [Page 7]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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 August 26,2018 [Page 8]
Internet-Draft PCEP residual bandwidth retrieval February 2018
(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 August 26,2018 [Page 9]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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.
5.1. Use cases
The first use case is the application of the residual bandwidth
to simplify the computation of an end-to-end path across a multi-
domain network.
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.
In particular, this 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 H-PCE coordinates the
operations of a set of child (domain) PCEs in order to compute end-
to-end paths across the network.
An H-PCE (either stateful or stateless) can make the best of
residual bandwidth metrics, using paths from erstwhile path
computations to deploy multiple LSPs (having the same end-points and
constraints) without additional requests, until either the remaining
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.
The residual bandwidth information would also be beneficial for
implementing abstractions of the domain topology, building the
Lazzeri, et al. Expires August 26,2018 [Page 10]
Internet-Draft PCEP residual bandwidth retrieval February 2018
abstract connectivity incrementally, based only on really used
constraints, as soon as path computation results are returned.
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.
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.]
Lazzeri, et al. Expires August 26,2018 [Page 11]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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:
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.
Lazzeri, et al. Expires August 26,2018 [Page 12]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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.
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
Lazzeri, et al. Expires August 26,2018 [Page 13]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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,
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 August 26,2018 [Page 14]
Internet-Draft PCEP residual bandwidth retrieval February 2018
9. Contributors
Authors' Addresses
Francesco Lazzeri
Ericsson
Via Melen 77
Genova - Italy
Email: francesco.lazzeri@ericsson.com
Daniele Ceccarelli
Ericsson AB
Gronlandsgatan 21
Kista - Sweden
Email: daniele.ceccarelli@ericsson.com
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Dhruv Dhody
Huawei Technologies,
Divyashree Technopark, Whitefield
Bangalore, India
Email: dhruv.ietf@gmail.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
Lazzeri, et al. Expires August 26,2018 [Page 15]
Internet-Draft PCEP residual bandwidth retrieval February 2018
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.
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 August 26,2018 [Page 16]
