ALTO WG K. Gao Internet-Draft Tsinghua University Expires: January 7, 2016 Y. Yang Yale University July 6, 2015 ALTO Extensions for Multi-Source Information Collection draft-gao-alto-info-extension-01 Abstract The Application-Layer Traffic Optimization (ALTO) protocol enables the distribution of certain network information to applications. Hence, a fundamental functionality of an ALTO server is to collect general network information, especially from multiple "information sources". In this document, we propose a preliminary solution to standardize the process of information collection for ALTO servers by extending the ALTO protocol with some new services, which can also serve as a unified approach of network information distribution. Status of This Memo 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 January 7, 2016. Copyright Notice 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 Gao & Yang Expires January 7, 2016 [Page 1] Internet-Draft ALTO Extensions July 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology and Notation . . . . . . . . . . . . . . . . 4 2. ALTO Servers and Information Sources . . . . . . . . . . . . 4 2.1. Information Sources . . . . . . . . . . . . . . . . . . . 4 2.2. Relationship Analysis . . . . . . . . . . . . . . . . . . 5 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Common ALTO Information Bases . . . . . . . . . . . . . . 7 3.2. Overview of Extended ALTO Services . . . . . . . . . . . 8 3.3. Extended Network Map . . . . . . . . . . . . . . . . . . 8 3.4. Information Map . . . . . . . . . . . . . . . . . . . . . 12 3.5. Endpoint Information Service . . . . . . . . . . . . . . 16 4. Future Improvement . . . . . . . . . . . . . . . . . . . . . 20 4.1. Deriving ALTO Services from the Extensions . . . . . . . 20 4.2. Information Aggregation Services . . . . . . . . . . . . 21 4.3. Scope for Extended ALTO Services . . . . . . . . . . . . 22 4.4. The Regulation of Property Specifications . . . . . . . . 22 4.5. Fetching Filtered Topological Information . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The "Application-Layer Traffic Optimization" protocol proposed in [RFC7285] defines several "maps" to publish network information to applications so that both the network providers and the application users can make better decisions on traffic steering and eventually achieve better performance. However by specifying the protocol between ALTO clients and servers, [RFC7285] only describes part of the service model. In this document we focus on the service model of ALTO servers. A fundamental functionality of the ALTO server is to collect information from what we call "information sources". It is not surprising that there are many different information sources and thus we can describe a more complete service model for the server's side Gao & Yang Expires January 7, 2016 [Page 2] Internet-Draft ALTO Extensions July 2015 in Figure 1, where the arrows indicate the direction of information flow. +--------+ Method #1 +---------------+ ALTO | | <----------+ Information | +----------+ Protocol | | | Source #1 | | ALTO | <--------- | | +---------------+ | Client | | | +----------+ | | Method #2 +---------------+ | | <----------+ Information | ... ... | ALTO | | Source #2 | | Server | +---------------+ +----------+ ALTO | | | ALTO | Protocol | | ... ... | Client | <--------- | | +----------+ | | Method #N +---------------+ | | <----------+ Information | | | | Source #N | +--------+ +---------------+ Figure 1: Service Model for an ALTO server Since the relationships between ALTO servers and information sources can be very complex, as discussed in Section 2.2, the communication between them can hardly be unified. Nevertheless, it is still possible and beneficial to design a generic protocol to collect statistics for servers implemented with certain patterns of ALTO information bases. With a standard protocol, the implementation of ALTO servers can be decoupled from the implementations of information sources, making it much easier to support the feature of fetching information from multiple sources and to be compatible with new information sources. Section 3 introduces the proposed protocol format in details. Despite the initial motivation to help ALTO server implementations gather necessary information, the protocol can also be applied as a unified information distribution method. 1.1. Requirements Language 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 [RFC2119]. Gao & Yang Expires January 7, 2016 [Page 3] Internet-Draft ALTO Extensions July 2015 1.2. Terminology and Notation This document uses the following terms: Application, ALTO Server, ALTO Client and ALTO Response defined in [RFC5693]; Endpoint, ALTO Information and ALTO Information Base defined in [RFC7285]. This document uses the same notations of describing JSON objects in [RFC7285], which are specified in [RFC7159]. This document uses the following additional terms: Information Source. o Information Source An information source is an entity that provides basic information for ALTO servers, see more detailed description in Section 2.1. 2. ALTO Servers and Information Sources This section introduces the concept of "information sources" and discusses the possible relationships between an ALTO server and an information source. 2.1. Information Sources An "information source" can be roughly described as any entity that is capable of providing information on the network but the exact meaning depends on the server implementation. For example, in Software Defined Networking (SDN), for an ALTO server calculating the hop counts by calling the corresponding northbound API of a SDN controller, the controller is an information source. Meanwhile, for an ALTO server using round trip time (RTT) as the routing cost metric, P2P clients submitting the statistics of a connection are regarded as information sources. In this document we identify four major kinds of information sources: o Human Input It is possible that the administrators of an ALTO server want to modify the output to meet the need of certain demands such as policy changes, so they may compose some data accordingly and input them into the server. Also in the early stages of ALTO server development, human interference is inevitable to detect abnormal behavior. o Network Measurement Tools Gao & Yang Expires January 7, 2016 [Page 4] Internet-Draft ALTO Extensions July 2015 Due to financial, technical and security reasons it has been hard to fetch the required data directly from ISPs, thus many efforts have been made to measure different metrics using endpoint-based tools. Since most of these tools require little support from the network infrastructure, lots of them can still work even if the Internet architecture evolves. These measurement techniques can be valuable sources to ALTO services as the measured results often reflect the actual performance of the network. o Network Operating Systems With the progress in opening up the network in recent years, especially with the development of SDN, the networking system itself has become an important source of network information. Using "northbound" APIs provided by SDN controllers, one can get both the configurations and the accurate running states of a network. o Information Aggregators While information sources discussed above are capable to provide the "raw" data, these data can be aggregated, by a third-party aggregator or by a higher-level network OS as in some hierarchical SDN controller designs. It is notable that an ALTO server itself can also be regarded as a source of aggregated information. 2.2. Relationship Analysis The complexity of the relationships between ALTO servers and information sources comes from the following aspects: o How to identify the boundary; o How ALTO servers and information sources are coupled; o The capabilities of information sources. 2.2.1. Identification of Boundaries When we discuss the relationship between an ALTO server and the information source, it is important to identify the boundary first. As it is shown in Figure 2, we can see with different boundaries, different pairs of ALTO servers and information sources can be identified and their relationships are not quite the same. Gao & Yang Expires January 7, 2016 [Page 5] Internet-Draft ALTO Extensions July 2015 +------------------+-----------------------------------------------+ | ALTO Server #A | Information Source #A | +---------------------------------------+ +--------+ | +---------+ | | | | | | Information | | Host +------------+ Agent | Source #0 | | | | | | | +--------+ | +---------+ | +---------------------------------------+ | ALTO SERVER #B | Information Source #B | +--------------------------------------+---------------------------+ Figure 2: Different Ways to Identify the Boundary 2.2.2. Types of Coupling We identify three types of coupling ALTO servers and information sources. o The ALTO server is deeply embedded into the information source, which is either a network OS or an information aggregator. For example, our group has participated in a project to provide ALTO services in [OpenDaylight], an industrial SDN controller. o The ALTO server is loosely coupled with the information source. One example is the ALTO server #A in Figure 2 if the host and agents are still coupled by some private protocol. o The ALTO server is decoupled from the information sources by a standard protocol. For example, an ALTO server which calculates its own costs by merging the routing costs from some other ALTO servers is decoupled from the its information sources as long as they can provide standard ALTO cost map service with the corresponding cost type. 2.2.3. Capabilities of Information Sources The capabilities of an information source, which declare the types of available information, are determined by the type of the information source and the limitation of the targeted network, both of which can vary significantly. However, many capabilities are attached to a certain network element such as a router, a link, an attachment point, etc., which can significantly reduce the complexity. Gao & Yang Expires January 7, 2016 [Page 6] Internet-Draft ALTO Extensions July 2015 3. Protocol Design As described above it is difficult to define a unified protocol to cover the need of ALL ALTO server implementations. However, we can narrow down the demands by establishing clear boundaries and focus on the most general and most commonly used requirements. An observation is made that as mentioned in Section 2.1, the ALTO servers are actually one kind of information source and the ALTO protocol is designed to publish certain network information. Hence, instead of designing a new protocol for data collection, which would result in functionality overlap with ALTO and introduce complexity from an implementation perspective, the solution proposed in this document is based on the ALTO protocol to avoid these drawbacks. In this case, information sources can also take advantages of the ALTO framework such as the service discovery mechanism, and current ALTO implementations don't have to change anything if they want to serve as information sources too. To clarify the boundaries of the targeted information and to exploit the limitation of the current ALTO specification, especially for the network map service, two internal representations of an ALTO information service are introduced. We derive our design based on these two representations and discuss how to extend the ALTO specification so that the extensions can fit in the framework. 3.1. Common ALTO Information Bases Two typical internal representations of ALTO server implementations, as known as ALTO information bases, are identified for ALTO services as discussed below. It can be seen that both structures are highly related to and can reflect the information sources they use. o End-to-End In an end-to-end implementation, the network is represented as a full-mesh graph where the links are implicit and can be ignored. This can happen when the corresponding information source collects the information either by conducting end-to-end measurement methods or by making requests to other end-to-end information resources, whether as an intentional choice or being forced to do so because of the limitations of conditions or priorities to get topological information. o Topological In this case the server is using a graph with explicit nodes and links to represent a network. The graph is usually sparse and may Gao & Yang Expires January 7, 2016 [Page 7] Internet-Draft ALTO Extensions July 2015 have internal nodes that are transparent to the ALTO clients. Such examples are servers retrieving topology information from a SDN controller, from a data aggregator such as CAIDA, or simply from a configuration parser. 3.2. Overview of Extended ALTO Services It can be seen that the current ALTO specifications only publish end- to-end information to the clients. That is probably good enough for end users to choose from different destinations, however, it cannot satisfy the needs of an implementation with a topological ALTO information base because the original ALTO protocol is not capable of publishing topological information. To support this feature, the following extensions are proposed for ALTO protocol: o Section 3.3 introduces an extension of network maps which enables the distribution of topologies; o Section 3.4 introduces the extension to publish information for all elements defined in the extended network map. o Section 3.5 introduces the extension to support querying information between two endpoints. 3.3. Extended Network Map The extended network map can publish topological information such as links between different endpoints. The data component in the response uses the classic vertex-edge representation to describe the topology. Just as with the network map, filtering is also possible for the extended network map but due to timing issues it is not discussed in this document. 3.3.1. Media Type The media types for extended network map is defined in Section 6.1. 3.3.2. HTTP Method The extended network map is requested using the HTTP GET method. Gao & Yang Expires January 7, 2016 [Page 8] Internet-Draft ALTO Extensions July 2015 3.3.3. Accept Input Parameters None 3.3.4. Capabilities The capabilities of an extended network map are described using a JSON object of type ExtNetworkMapCapabilities: object { JSONString type<1..1>; } ExtNetworkMapCapabilities; with fields: o type: the type of information that is published. Currently the only valid options are "end-to-end" and "topological". 3.3.5. Uses None. 3.3.6. Response The "meta" field of the response is the same as of network map responses. The data component of an extended network map service is named "extended-network-map", which is a JSON object of type ExtNetworkMapData, where object { ExtNetworkMapData extended-network-map; } InfoResourceExtNetworkMap : ResponseEntityBase; object { NodeData nodes; [LinkData links;] } ExtNetworkMapData; object-map { NodeName -> NodeDesc; } EndpointData; object { [JSONBool internal;] } NodeDesc : EndpointAddrGroup; Gao & Yang Expires January 7, 2016 [Page 9] Internet-Draft ALTO Extensions July 2015 object-map { LinkName -> LinkDesc; } LinkData; object { JSONString pid<2..2>; JSONString direction; } LinkDesc; If the "type" field in the capabilities is "end-to-end", there MUST be no "links" field in the data component and no "internal" field in any node description. At the same time, ALTO clients MUST ignore these fields if they are mistakenly provided. If the "type" field in the capabilities is "topological", the "links" field and the "internal" field MUST be provided. The "direction" field indicates the allowed direction of traffic. The optional values are "both", "ltr" and "rtl". If the value is not "both", the pid MUST be sorted to represent the correct direction where "ltr" indicates the direction of pid_0 --> pid_1 while "rtl" indicates pid_0 <-- pid_0. 3.3.7. Example Figure 3 demonstrates a simple topology. +-----------+ +-----------+ | Node #1 |----\ | Node #4 | +-----------+ | +-----------+ | | | | | / \ | / \ +-----------+ +-----------+ -------| Node #3 |______| node #6 | +-----------+ +-----------+ | | / \ / \ +-----------+ +-----------+ | Node #2 | | Node #5 | +-----------+ +-----------+ Figure 3: Example Topology The example request and the corresponding response for the extended network map based on this topology is given below. Gao & Yang Expires January 7, 2016 [Page 10] Internet-Draft ALTO Extensions July 2015 GET /extnetworkmap HTTP/1.1 Host: alto.example.org Accept: application/alto-extnetworkmap+json, application/alto-error+json HTTP/1.1 200 OK Content-Length: 1252 Content-type: application/alto-extnetworkmap+json { "meta" : { "vtag": { "resource-id": "extended-network-map-example", "tag": "67e6183c00fe467a960f174b93f23cf7" } }, "extended-network-map": { "nodes": { "node#1": { "internal": "false", "ipv4": [ "192.168.1.0/28" ] }, "node#2": { "internal": "false", "ipv4": [ "192.168.1.128/28" ] }, "node#3": { "internal": "true" }, "node#4": { "internal": "false", "ipv4": [ "192.168.2.0/28" ] }, "node#5": { "internal": "false", "ipv4": [ "192.168.2.128/28" ] }, "node#6": { "internal": "true" } }, "links": { "link#1": { "pid": ["node#1", "node#3"], "direction": "both" }, "link#2": { "pid": ["node#1", "node#3"], Gao & Yang Expires January 7, 2016 [Page 11] Internet-Draft ALTO Extensions July 2015 "direction": "both" }, "link#3": { "pid": ["node#2", "node#3"], "direction": "both" }, "link#4": { "pid": ["node#4", "node#6"], "direction": "both" }, "link#5": { "pid": ["node#5", "node#6"], "direction": "both" }, "link#6": { "pid": ["node#3", "node#6"], "direction": "both" } } } } 3.4. Information Map The information map has many similarities with the cost map. Instead of providing only the "cost" between endpoints, it is extended to publish generic network information for both endpoint/node pairs and links. It is notable that there are no explicit distinctions between attributes and statistics, where the former represent the essence and configurations of the object that should seldom change while the latter represent the dynamic running state of a network. However, an ALTO server can provide such indications in the corresponding specifications. Due to timing issues, the filtering on the information map is not described in this document but it is worthy pointing out that the filtered information map is quite essential to enhance the performance of fetching data for the interested nodes or links. 3.4.1. Media Type The media types for information map is defined in Section 6.1. 3.4.2. HTTP Method The information map is requested using the HTTP GET method. Gao & Yang Expires January 7, 2016 [Page 12] Internet-Draft ALTO Extensions July 2015 3.4.3. Accept Input Parameters None 3.4.4. Capabilities The capabilities of an information map are described using a JSON object of type InfoMapCapabilities: object { JSONString properties<0..*>; } InfoMapCapabilities; with fields: o properties: the list containing the property names of paths and links. The names SHOULD indicate the exact target using prefixes such as "path-" or "link-". The properties here CAN contain both characteristic attributes and statistics for a given path/link. 3.4.5. Uses The resource ID of the network map or the extended network map based on which the information map will be defined. 3.4.6. Response The "meta" field of the response is described using the following JSON object: object { VersionTag dependent-vtags<1..1>; VersionTag vtag; [PropertyName -> PropertySpec;] } InfoMapMetaData; object { JSONString type; [PropertyAttrName -> JSONValue;] } PropertySpec; with fields: o vtag: the same as the "vtag" in the network map; o dependent-vtags: the same as the "dependent-vtags" in the cost map, with the addition that resource ID can point to an extended network map; Gao & Yang Expires January 7, 2016 [Page 13] Internet-Draft ALTO Extensions July 2015 o PropertyName: the name listed in the capabilities. The "type" field in PropertySpec is either "path" or "link". The data component of an information map service is named "information-map", which is a JSON object of type InfoMapData, where: object { InfoMapData information-map; } InfoResourceInfoMap : ResponseEntityBase; object-map { PropertyName -> PropertyMapData; } InfoMapData; object-map { NodeName -> { NodeName -> JSONValue }; } PathPropertyData : PropertyMapData; object-map { LinkName -> JSONValue; } LinkPropertyData : PropertyMapData; If the "type" field in the corresponding PropertySpec is "path", the type of the PropertyMapData MUST be PathPropertyData and the same restriction rule applies to "link" and LinkPropertyData. 3.4.7. Example The example of getting the hop counts between nodes, link cost and the link capacities is given below, using the topology in Figure 3. GET /example-infomap HTTP/1.1 Host: alto.example.org Accept: application/alto-infomap+json, application/alto-error+json HTTP/1.1 200 OK Content-Length: 1434 Content-type: application/alto-infomap+json { "meta": { "vtag": { "resource-id": "infomap-example", "tag": "e7822fdd03814561bdb955667ca06534" }, "dependent-vtags": [ Gao & Yang Expires January 7, 2016 [Page 14] Internet-Draft ALTO Extensions July 2015 { "resource-id": "extended-network-map-example", "tag": "67e6183c00fe467a960f174b93f23cf7" } ], "path-hop-count-cost": { "type": "path", "mode": "numerical", "metric": "hopcount" }, "link-cost": { "type": "link", "mode": "numerical", "metric": "routingcost" }, "link-capacity": { "type": "link", "format": "text" } }, "information-map": { "path-hop-count-cost": { "node#1": { "node#1": 0, "node#2": 2, "node#3": 1, "node#4": 3, "node#5": 3, "node#6": 2 }, "node#2": { "node#1": 2, "node#2": 0, "node#3": 1, "node#4": 3, "node#5": 3, "node#6": 2 }, "node#3": { "node#1": 1, "node#2": 1, "node#3": 0, "node#4": 2, "node#5": 2, "node#6": 1 }, "node#4": { "node#1": 3, "node#2": 3, "node#3": 2, "node#4": 0, "node#5": 2, "node#6": 1 }, "node#5": { "node#1": 3, "node#2": 3, "node#3": 2, "node#4": 2, "node#5": 0, "node#6": 1 }, "node#6": { "node#1": 2, "node#2": 2, "node#3": 1, "node#4": 1, "node#5": 1, "node#6": 0 } }, "link-cost": { Gao & Yang Expires January 7, 2016 [Page 15] Internet-Draft ALTO Extensions July 2015 "link#1": 2, "link#2": 1, "link#3": 1, "link#4": 1, "link#5": 1, "link#6": 1 }, "link-capacity": { "link#1": "10Gbps", "link#2": "5Gbps", "link#3": "10Gbps", "link#4": "10Gbps", "link#5": "10Gbps", "link#6": "20Gbps" } } } 3.5. Endpoint Information Service The endpoint information service to the information map is just as the endpoint cost service to the cost map. It provides only the requested information for paths specified by given pairs of addresses. 3.5.1. Media Type The media types for endpoint information service is defined in Section 6.1. 3.5.2. HTTP Method The endpoint information service is requested using the HTTP POST method. 3.5.3. Accept Input Parameters The input parameters for the endpoint information service is described using the following JSON object: object { EndpointFilter endpoints; [PropertySpecName -> PropertySpec;] [JSONString constraints<0..*>;] } EndpointInfoReq; Gao & Yang Expires January 7, 2016 [Page 16] Internet-Draft ALTO Extensions July 2015 The EndpointFilter is the same as defined in [RFC7285]. The PropertySpec is the same as defined in Section 3.4. The "constraints" have the following three components: o A property name that indicates the property to filter. The corresponding property MUST be declared in the capabilities otherwise it MUST be ignored. o An operator as defined in [RFC7285] o A constant or a symbolic property to be compared to. 3.5.4. Capabilities The capabilities of the endpoint information service are described using a JSON object of type EndpointInfoCapabilities: object { JSONString properties<0..*>; } EndpointInfoCapabilities; with fields: o properties: the list containing the property names between endpoints. 3.5.5. Uses The resource ID of the network map, information map or the extended network map based on which the endpoint information service will be defined. 3.5.6. Response The "meta" field of the response is described using the following JSON object: object { VersionTag dependent-vtags<1..1>; VersionTag vtag; [PropertyName -> PropertySpec;] } EISMetaData; object { JSONString type; [PropertyAttrName -> JSONValue;] } PropertySpec; Gao & Yang Expires January 7, 2016 [Page 17] Internet-Draft ALTO Extensions July 2015 with fields: o dependent-vtags: the same as the "dependent-vtags" in the cost map, with the addition that resource ID can point to an extended network map; o vtag: the same as in the network map; o PropertyName: the name listed in the request. The data component of an endpoint information service is named "endpoint-information", which is a JSON object of type EISData, where: object { EISData endpoint-information; } InfoResourceEISData : ResponseEntityBase; object-map { PropertyName -> EISPropertyMapData; } EISData; object-map { TypedNodeAddr -> { TypedNodeAddr -> JSONValue }; } EISPropertyMapData; 3.5.7. Example The example of getting the routing cost is given below, using the same topology and routing cost information as in Section 3.4.7. Gao & Yang Expires January 7, 2016 [Page 18] Internet-Draft ALTO Extensions July 2015 POST /eis-example HTTP/1.1 Host: alto.example.org Content-Length: 329 Content-type: application/alto-endpointinfoparam+json Accept: application/alto-endpointinfo+json, application/alto-error+json { "endpoints": { "srcs": [ "ipv4:192.168.1.12", "node:node#1" ], "dsts": [ "ipv4:192.168.1.13", "ipv4:192.168.2.34", "node:node#2" ] }, "path-routingcost": { "type": "path", "mode": "numerical", "metric": "routingcost" }, "constraints": ["link-capacity > 8Gbps"] } HTTP/1.1 200 OK Content-length: 601 Content-type: application/alto-endpointinfo+json { "meta": { "vtag": { "resource-id": "eis-example", "tag": "5ffb08265da64136a13978055f3affb6" }, "dependent-vtags": [ { "resource-id": "extended-network-map-example", "tag": "67e6183c00fe467a960f174b93f23cf7" }, { "resource-id": "infomap-example", "tag": "e7822fdd03814561bdb955667ca06534" } ] }, Gao & Yang Expires January 7, 2016 [Page 19] Internet-Draft ALTO Extensions July 2015 "endpoint-information": { "path-cost": { "ipv4:192.168.1.12": { "ipv4:192.168.1.13": 0, "ipv4:192.168.2.34": 4 }, "node:node#1": { "node:node#2": 3 } } } } With the constraint of "link-capacity > 8Gbps" in the request, link#2 should be filtered so the routing cost between node#1 and node#4 is 4 instead of 3. It is notable that the endpoint information is only provided between endpoints with the same address type. 4. Future Improvement In the preceding sections three new ALTO services are introduced, however, they only provide basic functionalities to distribute general network information. In this section we discuss some advanced topics about the extensions for enhancements in functionalities and performance. 4.1. Deriving ALTO Services from the Extensions Even though the extended network map is capable to provide topological information, sometimes applications would still only request for end-to-end information. Also, due to backward- compatibility considerations, a network map derived from the extended network map is desired. One simple implementation is to crop the "links" field from the data component in an extended network map response, ignore all internal nodes and rename the "nodes" field to "network-map". At the same time, new information maps and an endpoint information services can be derived from the corresponding ones for the base extended network map. For example, consider the hop count as the targeted information, the hop counts between two endpoints can be derived by summing up the hop counts (which all have the value of 1) on all the links on the path. That example also demonstrate how the cost map can be derived from certain information maps. Gao & Yang Expires January 7, 2016 [Page 20] Internet-Draft ALTO Extensions July 2015 4.2. Information Aggregation Services With the extensions introduced in Section 3, an generic ALTO server implementation can collect information by querying other ALTO servers providing these information. However, question still remains that how the original data can be collected. One possible way is to use customized ALTO servers, for example, one embedded into a SDN controller. Another approach is to enable passive data collection in an ALTO server where the ALTO server declares a new kind of ALTO "aggregation" service. The aggregation service defines the format of information it can resolve so that information sources, whether they are ALTO servers, ALTO clients or third-party agents, can push the data to the server. The Internet Draft [I-D.ietf-alto-incr-update-sse], which uses Server-Sent Events (SSE) to push incremental updates to the ALTO clients, can also be used as a passive data collection method. Both methods can transport partial data to the aggregator ALTO server, however, the information sources using the "aggregation" service don't have to launch an ALTO server instance, thus this approach allows more lightweight publishers and can apply in more general scenarios. A comparison between the methods mentioned above is listed in Table 1. In "Ext-ALTO with SSE" and "Ext-ALTO", the aggregator ALTO server acts as a client to the publisher ALTO servers which provide the extended ALTO services introduced in this document with and without the SSE mechanism respectively. In "ALTO Aggregation", the aggregator ALTO server is providing the "aggregation" service and there is no demand on the publisher other than following the protocol. +--------------------+--------------+--------------+---------------+ | Description | Aggregator | Publisher | Partial Data | +--------------------+--------------+--------------+---------------+ | Ext-ALTO | ALTO Server | ALTO Server | No | | | Active | Passive | | | Ext-ALTO with SSE | ALTO Server | ALTO Server | Yes | | | Active | Active | | | ALTO Aggregation | ALTO Server | Any | Yes | | | Passive | Active | | +--------------------+--------------+--------------+---------------+ Table 1: Comparison between Different Ways to Collect Data Gao & Yang Expires January 7, 2016 [Page 21] Internet-Draft ALTO Extensions July 2015 4.3. Scope for Extended ALTO Services With the approaches in Section 3 and the ones discussed in sections above, we represent how ALTO protocol can be used to distribute network information to the applications in Figure 4 where the normal paths represent ALTO protocol and the starred path represents some private protocol. +---------------------+ +--------------------+ | | ********+ | | | * | Private | | v v | Information Source | | +--+-------+--+ | | +------+------+ | | +--------------------+ | +<----------+ Generic | | ALTO Client | | ALTO Server | +-------------+ | | +--------+ +<----------+ | +-------------+ | +--+----------+ | Third-Party | | ^ | Aggregator | v | +-------------+ | | +---------+---+ +-----+ | +-------------+ | | | Customized | | ALTO Client | | ALTO Server | | +<------------+ | +-------------+ +-------------+ Figure 4: AN ALTO Deployment Scenario 4.4. The Regulation of Property Specifications In the specifications for the information map and endpoint information service, the information to be published is identified by so-called property specifications. However, there are no standard providing the specifications of other properties at the moment. Even though the specification for "cost-type" proposed in [RFC7285] can be seen as an example, it can still lead to confusions if two ALTO servers happen to use the same mode-metric combination but use different measure units. Just like the cost types in [RFC7285], a registry for the information specification used by the information map and the endpoint information service MUST be created and maintained by IANA in the future. To get started, future proposals SHOULD designate some initial values by providing the specifications for some commonly used information, such as the link capacity, available bandwidth, etc. Another approach is to design a management system where new specifications can be validated and registered with an "exp:" prefix, Gao & Yang Expires January 7, 2016 [Page 22] Internet-Draft ALTO Extensions July 2015 which indicates that they are experimental properties, before they are standardized. 4.5. Fetching Filtered Topological Information One way to fetch filtered topological information, as the name suggests, is to use the filtered information map which returns only the requested data of the requested nodes/links. The filtered information map has not been specified in this document yet but is planned to be included in future updates. Another approach can be achieved in the following way: First use a special type of TypedNodeAddr, the "NodeName", to identify the targeted nodes, and then implement an endpoint information service that returns the links between two requested nodes with all the requested data attached. This particular service can be useful to merge the given sequence of links to a single "virtual" link, which may help reduce the size of network view and encapsulate details of the original topology. 5. Security Considerations This document has not conducted its security analysis. 6. IANA Considerations This document defines registries for application/alto-* media types. 6.1. Media Types The media types for the three ALTO extensions are listed below: +--------------+------------------------------+----------------+ | Type | Subtype | Specification | +--------------+------------------------------+----------------+ | application | alto-extnetworkmap+json | Section 3.3.6 | | application | alto-infomap+json | Section 3.4.6 | | application | alto-endpointinfo+json | Section 3.5.6 | | application | alto-endpointinfoparam+json | Section 3.5.3 | +--------------+------------------------------+----------------+ Table 2: Media Types The media types defined in this document have the same constraints and properties as those defined in [RFC7285], except the authors' information. Gao & Yang Expires January 7, 2016 [Page 23] Internet-Draft ALTO Extensions July 2015 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", draft-ietf-alto-incr-update- sse-00 (work in progress), May 2015. [OpenDaylight] Medved, J., Varga, R., Tkacik, A., and K. Gray, "Opendaylight: towards a model-driven sdn controller architecture", 2014. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7285] Alimi, 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. Authors' Addresses Kai Gao Tsinghua University 30 Shuangqinglu Street, Haidian District Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Gao & Yang Expires January 7, 2016 [Page 24] Internet-Draft ALTO Extensions July 2015 Y. Richard Yang Yale University 51 Prospect St New Haven CT USA Email: yry@cs.yale.edu Gao & Yang Expires January 7, 2016 [Page 25]