One document matched: draft-roome-alto-resource-attr-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://http://tools.ietf.org/tools/templates/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc iprnotified="no" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
docName="draft-roome-alto-resource-attr-01"
ipr="trust200902">
<front>
<title>Resource Attributes for ALTO Protocol</title>
<author initials="W." surname="Roome" fullname="Wendy Roome">
<organization abbrev="Alcatel-Lucent">Alcatel-Lucent/Bell Labs</organization>
<address>
<postal>
<street>600 Mountain Ave, Rm 3B-324</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>USA</country>
</postal>
<phone>+1-908-582-7974</phone>
<email>w.roome@alcatel-lucent.com</email>
</address>
</author>
<date month="April" year="2015"/>
<area>Networks</area>
<workgroup>ALTO WG</workgroup>
<keyword>ALTO</keyword>
<abstract>
<t>
This document extends the Application-Layer Traffic
Optimization (ALTO) Protocol <xref target="RFC7285"/>
by defining additional descriptive attributes
for the resources offered by an ALTO Server.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
In the ALTO Protocol <xref target="RFC7285"/>,
the Information Resource Directory (IRD)
defines the resources, or services, offered by an ALTO server.
An IRD contains one entry for each resource.
Each entry provides the information a client needs to use that resource:
the URI for the resource,
the type of data the server returns,
the type of data the client sends (if any),
the identifiers of any resources on which this resource depends,
and optional capabilities for the resource.
</t>
<t>
However, resources have many additional attributes.
For example, a Network Map resource maps
PID (Provider-defined Identifier) names to network address prefixes.
A small Network Map resource might define 20 PIDs and a total of 100 prefixes,
while a large Network Map might have 5,000 PIDs and 500,000 prefixes.
A client would like to know the size of the Network Map
before retrieving it,
but the IRD gives no hint.
</t>
<t>
Also, an ALTO Server might have detailed cost data for a set of network addresses,
but only approximate costs (or no cost data at all)
for other network addresses.
If an ALTO Client wants cost data for a particular network address,
and the client knows about several different ALTO Servers,
the client would prefer to use the ALTO Server with the best
data for that address. But the IRD entries give no hint as
to the best server; the client would have to try each server
and guess as to which has the most accurate data.
</t>
<t>
This document defines a framework for declaring such attributes
in IRD entries, and defines an initial set of attributes.
</t>
<section title="Attributes Versus Capabilities">
<t>
The ALTO Protocol already defines a "capabilities" section
for IRD entries, so one alternative is simply to define
additional capabilities. We prefer not to do that for several reasons:
<list style="symbols">
<t>
Capabilities are always defined;
the ALTO protocol either requires the IRD entry to specify a value,
or else defines a default.
Attributes are optional, and do not have defaults.
</t>
<t>
Capability names are defined by the ALTO protocol;
adding a new capability requires a new RFC.
Attribute names are managed by IANA,
so new attributes can be added without
extending the protocol.
</t>
<t>
Attribute values are approximate, and/or may change frequently.
Capabilities are accurate, and should not change unless the resource is redefined.
For example, if a capability says a Cost Maps returns a "routingcost" cost metric,
it is an error if the resource returns a "hopcount" instead.
But the size of a Cost Map may vary from time to time.
So if a Cost Map attribute says the map has 500 cost points,
a client should interpret that as a guideline,
and not be surprised of the actual map has 550 costs.
</t>
</list>
</t>
</section>
</section>
<section title="Changes To ALTO Protocol">
<section title="IRD Entries">
<t>
Resources attributes are defined by a new field, named "attributes",
at the same level as the existing "uri" and "media-type" fields
in IRD entries.
That is, in <xref target="RFC7285"/> Sec. 9.2.2, IRDResourceEntry is revised as:
</t>
<figure>
<artwork><![CDATA[
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
[Attributes attributes;] // Added
} IRDResourceEntry;
object {
...
} Attributes; // Added
]]></artwork>
</figure>
<t>
Here is an example of an IRD with attributes:
</t>
<figure>
<artwork>
<![CDATA[
...
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json",
"attributes" : {
"pid-count-current" : 50,
"prefix-count-current" : 150,
"authoritative-prefixes" : {
"ipv4": [ "1.2.0.0/16", "3.4.0.0/16" ]
},
"authoritative-exclusions" : {
"ipv4": [ "1.2.1.0/25" ]
}
}
},
"numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-routing" ]
},
"uses" : [ "my-default-network-map" ],
"attributes" : {
"cost-count-current" : 500,
"cost-count-range" : [ 250, 750 ]
}
},
...
]]>
</artwork>
</figure>
</section>
</section>
<section title="Resource Attributes">
<section title="Attribute Names">
<t>
An attribute name is encoded as a string. The string MUST be no more
than 32 characters, and it MUST NOT contain characters other than US-ASCII
alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and
U+0061-U+007A), the hyphen (’-’, U+002D), the colon (’:’, U+003A),
the low line (’_’, U+005F), or the ’.’ separator (U+002E). The ’.’
separator is reserved for future use and MUST NOT be used unless
specifically indicated by a companion or extension document.
</t>
<t>
Identifiers prefixed with "priv:" are reserved for Private Use
<xref target="RFC5226"/> without a need to register with IANA. All other
identifiers MUST be registered in the "ALTO Resource Attribute Registry"
(see <xref target="IANA"/>).
For an identifier with the "priv:" prefix, an additional string
(e.g., company identifier or random string) MUST follow
(i.e., "priv:" only is not a valid identifier) to reduce potential collisions.
</t>
<t>
<xref target="ProposedAttributes"/> defines an initial set of Resource Attributes.
</t>
</section>
<section title="Attribute Values">
<t>
The type of an attribute value depends on the attribute.
When registering an attribute with IANA,
the JSON value type MUST be specified.
</t>
</section>
<section anchor="ProposedAttributes" title="Proposed Resource Attributes">
<t>
We propose the following Resource Attributes:
<list style="hanging" hangIndent="5">
<t hangText="pid-count-current:">
<vspace/>Resource type: Network Map
<vspace/>Value type: JSON Number
<vspace/>Semantics: The number of PIDs in the current Network Map.
</t>
<t hangText="prefix-count-current:">
<vspace/>Resource type: Network Map
<vspace/>Value type: JSON Number
<vspace/>Semantics: The total number of prefixes in the current Network Map.
</t>
<t hangText="pid-count-range:">
<vspace/>Resource type: Network Map
<vspace/>Value type: JSON Array with two JSON Numbers
<vspace/>Semantics: Low and high values
for the number of PIDs in the Network Map.
This range SHOULD cover the expected size of the map
for the foreseeable future.
</t>
<t hangText="prefix-count-range:">
<vspace/>Resource type: Network Map
<vspace/>Value type: JSON Array with two JSON Numbers
<vspace/>Semantics: Low and high values
for the total number of prefixes in the Network Map.
This range SHOULD cover the expected size of the map
for the foreseeable future.
</t>
<t hangText="authoritative-prefixes:">
<vspace/>Resource types: Network Map and Endpoint Cost Map
<vspace/>Value type: A JSON Object of type NetworkMapData
(Section 11.2.1.6 of <xref target="RFC7285"/>)
<vspace/>This resource is authoritative (see <xref target="AuthoritativeSets"/>)
for all endpoints which are covered by a prefix in this set,
and which are not covered by a prefix
in the "authoritative-exclusions" set.
</t>
<t hangText="authoritative-exclusions:">
<vspace/>Resource types: Network Map and Endpoint Cost Map
<vspace/>Value type: A JSON Object of type NetworkMapData
(Section 11.2.1.6 of <xref target="RFC7285"/>)
<vspace/>See the "authoritative-prefixes" resource, above.
</t>
<t hangText="cost-count-current:">
<vspace/>Resource type: Cost Map
<vspace/>Value type: JSON Number
<vspace/>Semantics: The number of cost points in the current Cost Map.
Note that although a Cost Map is an NxN matrix,
where N is the number of PIDs,
a Cost Map is not required to define a cost for every {source,destination} pair.
</t>
<t hangText="cost-count-range">
<vspace/>Resource type: Cost Map
<vspace/>Value type: JSON Array with two JSON Numbers
<vspace/>Semantics: Low and high values
for the total number of cost points in the Cost Map.
This range SHOULD cover the expected size of the map
for the foreseeable future.
</t>
</list>
</t>
</section>
<section anchor="AuthoritativeSets" title="Authoritative Endpoint Sets">
<t>
The set of endpoints defined by the "authoritative-prefixes"
and "authoritative-exclusions" attributes are the endpoints
for which a resource provides authoritative data.
For an ALTO Server provided by an ISP,
this will usually be the endpoints of the ISP's customers.
</t>
<t>
While we do not rigorously define "authoritative",
in general if a resource is authoritative for a set of endpoints, then:
<list style="symbols">
<t>
No other ALTO Server has more accurate data for those endpoints.
However, other servers may have equally accurate data.
</t>
<t>
The ALTO Server SHOULD fully specify the costs for those endpoints.
That is, for every endpoint EA in the authoritative set
and every other endpoint EX,
the associated cost map service(s)
SHOULD define the costs from EA to EX
and from EX to EA.
</t>
<t>
PIDs covering endpoints in the authoritative set
SHOULD be more detailed (smaller, finer-grained, etc.)
than PIDs for other endpoints.
</t>
</list>
</t>
<t>
We define the authoritative set with two lists of prefixes,
one ("authoritative-prefixes") to include a set of endpoint addresses,
and the other ("authoritative-exclusions") to exclude some of those addresses.
We chose that approach because it is a simple and efficient way
to represent the addresses of an ISP's customers.
An ISP starts by being granted various address blocks
by the appropriate authority.
These prefixes form the "authoritative-prefixes" list.
Over time, some customers might migrate to other ISPs,
and take their addresses with them.
Those prefixes form the "authoritative-exceptions" list.
This two-level model provides an efficient way to represent
a large block of addresses with a few exceptions,
and seems to be a good balance between efficiency and simplicity.
</t>
<t>
The prefixes in "authoritative-prefixes" do not necessarily appear
directly in the Network Map.
As an example, suppose an ISP were allocated 1.0.0.0/8.
For the Network Map,
the ISP would almost certainly break that large set of addresses
into a number of different PIDs, to reflect the ISP's network structure
(or at least as much as the ISP wishes to reveal).
over
</t>
</section>
</section>
<section title="Impact On Existing Clients">
<t>
<xref target="RFC7285"/> says that clients MUST ignore any fields they do not recognize.
Hence this extension should have no impact on existing ALTO Clients;
they should simply ignore the resource attributes.
</t>
</section>
<section title="Use Cases" anchor="UseCases">
<t>
Here are brief descriptions of several ways
in which clients can take advantage of Resource Attributes:
<list style="symbols">
<t>
Advance knowledge of the size of a network or cost map
allows an ALTO client to allocate sufficient space
to hold the map, or to select the appropriate way to store it.
For example, a Cost Map is an NxN matrix, where N is the number of PIDs.
But it may be sparse. If the number of costs in the Cost Map
is considerably less than the square of the number of PIDs
in the associated Network Map, then the client knows in advance
that the Cost Map is likely to be sparse,
and can use sparse matrix techniques.
On the other hand, if the number of costs is close to the square
of the number of PIDs, the client knows that there is
no advantage in using a sparse matrix.
</t>
<t>
If an ALTO Server offers several different Network Maps,
a client can use the network map size and/or authoritative sets
to select the appropriate Network Map.
</t>
<t>
A client such as a P2P tracker can use the authoritative sets
to select the appropriate ALTO Server.
For example, suppose the tracker has obtained the IRDs
for a number of ALTO Servers,
each providing accurate data for a subset of the overall network.
When a peer requests a set of peers,
the tracker would locate the Network Map
(or Endpoint Cost Service) whose authoritative set
includes the requesting peer's address.
The tracker uses that ALTO resource to evaluate costs
between the requestor and the other peers,
and returns the peers with the lowest costs.
</t>
</list>
</t>
</section>
<section title="Alternatives And Discussion (Delete if draft is published)">
<t>
Here a few points for which I welcome discussion:
<list style="symbols">
<t>
Can anyone suggest a better name than "attributes"?
I considered "properties", but that conflicts with
Endpoint Properties.
Another possibility is "meta", but we have overloaded that name.
</t>
<t>
I don't like the term "authoritative" to describe
the endpoints on which a Network Map is centered.
However, I can't think of anything better,
and it does seem to accurately reflect the intent.
Can anyone suggest an alternative?
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>
The attribute mechanism described in this document
does not introduce any security considerations
not already present in the ALTO Protocol.
The attributes defined in <xref target="ProposedAttributes"/>
provide information which a client can (with effort, perhaps)
deduce from the underlying ALTO resources,
and hence they do not introduce any new security considerations either.
</t>
<t>
Other attributes might introduce security issues.
If so, those issues should be discussed
when the attributes are registered with IANA.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document defines a registry for ALTO Resource Attributes.
When a new ALTO Resource Attribute is defined and accepted by the ALTO working
group, requests for IANA registration MUST include the identifier,
applicable resource type(s), JSON type and intended semantics.
</t>
<t>
<xref target="ProposedAttributes"/> defines the initial set of Resource Attributes.
</t>
</section>
</middle>
<back>
<references>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T." surname="Narten" fullname="T. Narten"/>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand"/>
<date month="May" year="2008"/>
</front>
<seriesInfo name="RFC" value="5226" />
<seriesInfo name="BCP" value="26" />
</reference>
<reference anchor="RFC7285">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
<author initials="R." surname="Almi" fullname="R. Alimi"/>
<author initials="R." surname="Penno" fullname="R. Penno"/>
<author initials="Y." surname="Yang" fullname="Y. Yang"/>
<author initials="S." surname="Kiesel" fullname="S. Kiesel"/>
<author initials="S." surname="Previdi" fullname="S. Previdi"/>
<author initials="W." surname="Roome" fullname="W. Roome"/>
<author initials="S." surname="Shalunov" fullname="S. Shalunov"/>
<author initials="R." surname="Woundy" fullname="R. Woundy"/>
<date month="September" year="2014"/>
</front>
<seriesInfo name="RFC" value="7285" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:03 |