One document matched: draft-wu-alto-te-metrics-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-alto-te-metrics-00" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="ALTO TE Metrics">ALTO Traffic Engineering Cost
Metrics</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</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="Young Lee" initials="Y." surname="Lee">
<organization>Huawei</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<email>leeyoung@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</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="Sabine Randriamasy" initials="S." surname="Randriamasy">
<organization>Alcatel-Lucent</organization>
</author>
<date year="2013" />
<area>TSV Area</area>
<workgroup>ALTO Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>JavaScript Object Notation, Application-Layer Traffic
Optimization</keyword>
<abstract>
<t>Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the Cost Map Service and the
Endpoint Cost Service. Future extensions to ALTO may also use Cost
Metric.</t>
<t>Different applications may benefit from different Cost Metrics. For
example, a Resource Consumer may prefer Resource Providers that have low
latency to the Resource Consumer. However the base ALTO protocol [ALTO]
has defined only a single cost metric, i.e., the generic "routingcost"
metric (Sec. 14.2 of ALTO base specification [ALTO]).</t>
<t>In this document, we define XXX Cost Metrics, derived from OSPF-TE
and ISIS-TE, to measure network delay, jitter, packet loss, hop count,
and bandwidth. The metrics defined in this document provide a relatively
comprehensive set of Cost Metrics for ALTO focusing on traffic
engineering. Additional Cost Metrics such as financial cost metrics may
be defined in other documents.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the Cost Map Service and the
Endpoint Cost Service. In particular, applications may benefit from
knowing network performance measured in several Cost Metrics. For
example, a more delay sensitive application may focus on latency, and a
more bandwidth-sensitive application may focus on available
bandwidth.</t>
<t>In this document, we define X Cost Metrics, extending the base ALTO
protocol [ALTO], which has defined only a single Cost Metric, i.e., the
generic "routingcost" metric (Sec. 14.2 of ALTO base specification
[ALTO]).</t>
<t>The Cost Metrics that we define in this document focus on traffic
engineering. Additional metrics may be defined in other documents. In
particular, the Cost Metrics that we define in this document can be
gathered from routing systems; [OSPF-TE], [ISIS-TE], [BGP-LS] and
[BGP-PM] define mechanisms that allow an ALTO Server to retrieve and
derive the necessary information to provide the metrics that we define
in this document.</t>
<t>Note that the metrics that the ALTO Server retrieves may be defined
for only links, and hence, the server will need to compose the link
metrics to obtain path metrics used in services such as the Cost Map
Service. In this definition, we define the metrics to be independent of
link or path, considering that future ALTO extensions may define
link-based services, and hence the defined metrics should still be
usable.</t>
<t>One challenge in defining the metrics is that performance metrics
often depend on configuration parameters. For example, the value of
packet loss rate depends on the measurement interval. We handle this
issue [YRY: IMPORTANT TO SOLVE]</t>
<t>The definitions of a set Cost Metrics can allow us to extend the base
protocol (e.g., allowing output and constraints use different Cost
Metrics), but such extensions are not in the scope of this document.</t>
</section>
<section title="Conventions used in this document">
<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">RFC2119</xref>.</t>
<t>Syntax specifications shown here use the augmented Backus-Naur Form
(ABNF) as described in [RFC5234], and are specified as in the base JSON
specification [RFC4627].</t>
</section>
<section title="Metric: delay">
<figure>
<artwork>
Cost Metric name: delay
Metric Description: To specify spatial and temporal aggregated
delay over the specified source and destination. The
spatial aggregation unit is specified in the query context
(e.g., PID to PID, or endhost to endhost); and the temporal
unit is specified as the measurement interval.
Metric Unit: The unit is microseconds.
Metric Value Type:
A single 'JSONNumber' type value containing a non-negative
integer component that may be followed by a fraction part
and/or an exponent part.
Cost Mode: A Cost Mode is encoded as a US-ASCII string.
The string MUST either have the value 'numerical' or 'ordinal'.
Measurement details: YRY: SPECIFY MORE DETAILS.
Example 1:
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delay"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta" :{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delay"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 10,
"ipv4:198.51.100.34" : 20,
"ipv4:203.0.113.45" : 30,
}
}
}
</artwork>
</figure>
</section>
<section title="Metric: delayjitter">
<figure>
<artwork>
Cost Metric name: delayjitter
Metric Description: To specify the average delay variation over
a configurable interval for each source/destination pair
between two endpoints (network locations) in the network.
It could be either end to end jitter or the jitter
associated with a link (linkjitter). The unit is
microseconds.
Cost Metric Value type:
A single 'JSONumber' type value containing an integer
component that may be prefixed with an optional minus
sign, which may be followed by a fraction part and/or
an exponent part.
Purpose: This is intended to be a constraint attribute value
It could be used as a cost metric constraint attribute used
together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response.
Cost mode: A Cost Mode is encoded as a US-ASCII string.
The string MUST either have the value 'numerical' or 'ordinal'.
Measurement timing: Gather and update at the configurable interval
if it is link attribute. See [OSPF-TE] for configurable
interval. The configurable interval for end to end jitter could
be same as link.
Measurement points with Potential Measurement Domain:
The measurement point could be at any endpoint between
source and destination in the network.
Examples:
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delayjitter"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"delayjitter"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 0
"ipv4:198.51.100.34" : 1
"ipv4:203.0.113.45" : 5
}
}
}
</artwork>
</figure>
</section>
<section title="Metric: pktloss">
<figure>
<artwork>
Cost Metric name: pktloss
Metric Description: To specify a percentage of the total traffic
sent over a configurable interval for each
source/destination pair between two endpoints(network
locations) in the network. It could be either end to
end packet loss or the packet loss associated with a link
(linkloss).
Cost Metric Value type:
A single number value containing an integer component that
may be prefixed with an optional minus sign, which may
be followed by a fraction part and/or an exponent part.
Purpose: This is intended to be a constraint attribute value
It could be used as a cost metric constraint attribute used
together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response.
Cost mode: A Cost Mode is encoded as a US-ASCII string.
The string MUST either have the value 'numerical' or 'ordinal'.
Measurement timing: Gather and update at the configurable interval
if it is link attribute. See [OSPF-TE] for configurable
interval. The configurable interval for end to end packet loss
could be same as link.
Measurement points with Potential Measurement Domain:
The measurement point could be at any endpoint between
source and destination in the network.
Examples:
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "pktloss"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"pktloss"}
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34": 1,
"ipv4:203.0.113.45" : 0,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: hopcount">
<figure>
<artwork>
Cost Metric name: hopcount
Metric Description: To specify the number of hops in the path
between the source endpoint and the destination
endpoint.
Editor Note: Need to specify which layer (IP perhaps), details TBD for
multiple-layer aspect.
Cost Metric Value type:
A single 'JSONNumber' type value containing an
integer component that may be prefixed with an
optional minus sign.
Purpose: This is intended to be a constraint attribute value
It could be used as a cost metric constraint attribute used
together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response.
Cost mode: A Cost Mode is encoded as a US-ASCII string.
string MUST either have the value 'numerical' or 'ordinal'.
</artwork>
</figure>
</section>
<section title="Metrics: bandwidth">
<figure>
<artwork>
Cost Metric name: bandwidth
Metric Description: To specify Bandwidth over a configurable
interval for each source/destination pair between
two endpoints (network locations)in the network.
It could be either aggregated bandwidth for end to end
path or the bandwidth associated with a link. The units
are bytes per second.
Cost Metric Value type:
A single 'JSONNumber' type value containing an integer
component that may be prefixed with an optional minus
sign, which may be followed by a fraction part and/or
an exponent part.
Purpose: This is intended to be a constraint attribute value
It could be used as a cost metric constraint attribute used
together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response.
Cost mode: A Cost Mode is encoded as a US-ASCII string.
The string MUST either have the value 'numerical' or 'ordinal'.
This is just a definition of the costtype 'bandwidth'.
The use of this cost is always in conjunction with what it
represents, which could be Max Bandwidth (maxbw), Residual
Bandwidth (residuebw) etc.
Examples: (based on Residual Bandwidth (residuebw))
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "residubw"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"residubw"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34": 2000,
"ipv4:203.0.113.45" : 5000,
}
}
}
</artwork>
</figure>
</section>
<section title="Metric: maxbw">
<t>A maxbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It could
be either maximum bandwidth for end to end path or the bandwidth
associated with a link. It is extended from Bandwidth Cost metric and
defined as:<figure>
<artwork>
Object {
BWType max;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw;
}maxbw;
</artwork>
</figure></t>
</section>
<section title="Maximum Reserved Bandwdith: maxreservbw">
<t>A maxreservbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It
could be either maximum reserved bandwidth for end to end path or the
bandwidth associated with a link. It is extended from Bandwidth Cost
metric and defined as:<figure>
<artwork>
Object {
BWType maxreserved;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw;
}maxreservbw;
</artwork>
</figure></t>
</section>
<section title="Metric: unreservbw">
<t>A unreservbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It
could be either unreserved bandwidth for end to end path or the
bandwidth associated with a link. It is extended from Bandwidth Cost
metric and defined as:<figure>
<artwork>
Object {
BWType unreserved;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw<1,8>
}unreservbw;
//This bandwidth is per priority [TBD].
</artwork>
</figure></t>
</section>
<section title="Metric: residuebw">
<t>A residuebw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It
could be either residual bandwidth for end to end path or the bandwidth
associated with a link. It is extended from Bandwidth Cost metric and
defined as: <figure>
<artwork>
Object {
BWType Residue;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw;
}rediduebw;
</artwork>
</figure></t>
</section>
<section title="Metric: availbw">
<t>A availbw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It
could be either available bandwidth for end to end path or the bandwidth
associated with a link. It is extended from Bandwidth Cost metric and
defined as:<figure>
<artwork>
Object {
BWType Available;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw;
}availbw;
</artwork>
</figure></t>
</section>
<section title="Metric: utilbw">
<t>A utilbw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It could
be either utilized bandwidth for end to end path or the bandwidth
associated with a link. It is extended from Bandwidth Cost metric and
defined as:<figure>
<artwork>
Object {
BWType Utilized;
[PIDName srcPID;]
[PIDName dstPID;]
[JSONBool state;] //TRUE = not steady for src/dst pair; FALSE = steady;
Bandwidth bw;
}utilbw;
</artwork>
</figure></t>
</section>
<section title="Security Considerations">
<t>The properties defined in this document present no security
considerations beyond those in Section 14 of the base ALTO specification
[ALTO].</t>
</section>
<section title="IANA Considerations">
<t>IANA has added the following entries to the ALTO cost map Properties
registry, defined in Section 3 of [RFCXXX].</t>
<figure>
<artwork>
+-----------+--------------+------------------------+
| Namespace | Property | Reference |
+-----------+--------------+------------------------+
| | delay | [RFCxxxx], Section 3.1 |
| | jitter | [RFCxxxx], Section 3.2 |
| | pktloss | [RFCxxxx], Section 3.3 |
| | bandwidth | [RFCxxxx], Section 3.4 |
| | hopcount | [RFCxxxx], Section 3.5 |
| | maxbw |[RFCxxxx], Section 3.6 |
| | maxresbw |[RFCxxxx], Section 3.7 |
| | unresdbw |[RFCxxxx], Section 3.8 |
| | residbw |[RFCxxxx], Section 3.9 |
| | availbw |[RFCxxxx], Section 3.10 |
| | utilbw |[RFCxxxx], Section 3.11 |
+-----------+--------------+------------------------+
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D.Crocker" initials="D." surname="Crocker">
<organization></organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5234" />
</reference>
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object
Notation (JSON)</title>
<author fullname="D. Crockford" initials="D." surname="Crockford">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4627" />
</reference>
<reference anchor="ALTO">
<front>
<title>ALTO Protocol</title>
<author fullname="R. Alimi" initials="R." surname="Alimi">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-alto-protocol-16" />
</reference>
<reference anchor="OSPF-TE">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions</title>
<author fullname="S. Giacalone" initials="S." surname="Giacalone">
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-ospf-te-metric-extensions-04" />
</reference>
<reference anchor="ISIS-TE">
<front>
<title>ISIS Traffic Engineering (TE) Metric Extensions</title>
<author fullname="S. Giacalone" initials="S." surname="Giacalone">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-isis-te-metric-extensions-01" />
</reference>
<reference anchor="BGP-LS">
<front>
<title>North-Bound Distribution of Link-State and TE Information
using BGP</title>
<author fullname="H.Gredler" initials="H." surname="Gredler">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03" />
</reference>
<reference anchor="BGP-PM">
<front>
<title>BGP attribute for North-Bound Distribution of Traffic
Engineering (TE) performance Metrics</title>
<author fullname="Q.Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="ID" value="draft-wu-idr-te-pm-bgp-02" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="July" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</reference>
</references>
<section title="Filtering constraint Extensions">
<t>Section 10.2.2.3 of "ALTO: Application Layer Traffic Optimization
Protocol" [I.D-ietf-alto-protocol] states: <figure>
<artwork>"
object {
CostType cost-type;
[JSONString constraints<0..*>;]
[PIDFilter pids;]
} ReqFilteredCostMap;
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;
with members:
cost-type The CostType (Section 9.7) for the returned costs. The
cost-metric and cost-mode fields MUST match one of the supported
Cost Types indicated in this resource's capabilities
(Section 10.2.2.4). The ALTO Client SHOULD omit the description
field, and if present, the ALTO Server MUST ignore the description
field.
constraints Defines a list of additional constraints on which
elements of the Cost Map are returned. This parameter MUST NOT be
specified if this resource's capabilities ( Section 10.2.2.4)
indicate that constraint support is not available. A constraint
contains two entities separated by whitespace: (1) an operator,
'gt' for greater than, 'lt' for less than, 'ge' for greater than
or equal to, 'le' for less than or equal to, or 'eq' for equal to;
(2) a target cost value. The cost value is a number that MUST be
defined in the same units as the Cost Metric indicated by the
cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754
double-precision floating point [IEEE.754.2008] to store the cost
value, and SHOULD perform internal computations using double-
precision floating-point arithmetic. If multiple 'constraint'
parameters are specified, they are interpreted as being related to
each other with a logical AND.
”
</artwork>
</figure></t>
<t>In the JSON Object of type ReqFilteredCostMap, the constraint
attribute is expressed as:<figure>
<artwork>
“
[gt | lt | ge | le | eq ] <value>
”
</artwork>
</figure></t>
<t>In this specification, the constraint attribute is changed to<figure>
<artwork>
“
<cost-type2> [gt | lt | ge | le | eq ] <value>
”
</artwork>
</figure></t>
<t>Accordingly, the constraints definition is changed to:<figure>
<artwork>
“
constraints Defines a list of additional constraints on which
elements of the Cost Map are returned. This parameter MUST NOT be
specified if this resource's capabilities ( Section 10.2.2.4)
indicate that constraint support is not available. A constraint
contains three entities separated by whitespace: (1)an cost type
is by default cost-type in the JSON Object of type ReqFilteredCostMap.
In addition, it could be another cost-type used for the returned cost
(2) an operator, 'gt' for greater than, 'lt' for less than, 'ge' for
greater than or equal to, 'le' for less than or equal to, or 'eq' for
equal to; (3) a target cost value. The cost value is a number that
MUST be defined in the same units as the Cost Metric indicated by the
cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754
double-precision floating point [IEEE.754.2008] to store the cost
value, and SHOULD perform internal computations using double-
precision floating-point arithmetic. If multiple 'constraint'
parameters are specified, they are interpreted as being related to
each other with a logical AND.
”
</artwork>
</figure></t>
<t>Editor-Notes: Filtering constraint extension should move to another
document defining multi-metrics filtering in the future.</t>
</section>
<section title="Contributing Authors Addresses">
<figure>
<artwork>
Y. Richard Yang
Yale University
51 Prospect St
New Haven CT
USA
Email: yry@cs.yale.edu
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:29 |