| ALTO WG | W. Roome |
| Internet-Draft | Alcatel-Lucent |
| Intended status: Standards Track | April 10, 2015 |
| Expires: October 12, 2015 |
Resource Attributes for ALTO Protocol
draft-roome-alto-resource-attr-01
This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by defining additional descriptive attributes for the resources offered by an ALTO Server.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 12, 2015.
Copyright (c) 2015 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 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.
In the ALTO Protocol [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.
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.
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.
This document defines a framework for declaring such attributes in IRD entries, and defines an initial set of attributes.
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:
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 [RFC7285] Sec. 9.2.2, IRDResourceEntry is revised as:
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
[Attributes attributes;] // Added
} IRDResourceEntry;
object {
...
} Attributes; // Added
Here is an example of an IRD with attributes:
...
"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 ]
}
},
...
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.
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA. All other identifiers MUST be registered in the "ALTO Resource Attribute Registry" (see Section 8). 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.
Section 3.3 defines an initial set of Resource Attributes.
The type of an attribute value depends on the attribute. When registering an attribute with IANA, the JSON value type MUST be specified.
We propose the following Resource Attributes:
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.
While we do not rigorously define "authoritative", in general if a resource is authoritative for a set of endpoints, then:
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.
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
[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.
Here are brief descriptions of several ways in which clients can take advantage of Resource Attributes:
Here a few points for which I welcome discussion:
The attribute mechanism described in this document does not introduce any security considerations not already present in the ALTO Protocol. The attributes defined in Section 3.3 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.
Other attributes might introduce security issues. If so, those issues should be discussed when the attributes are registered with IANA.
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.
Section 3.3 defines the initial set of Resource Attributes.
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, BCP 26, May 2008. |
| [RFC7285] | Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S. and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014. |