ALTO WG J. Zhang Internet-Draft Tongji University Intended status: Informational K. Gao Expires: October 23, 2016 Tsinghua University Y. Yang Yale University April 21, 2016 Experiences of Implementing ALTO in OpenDaylight draft-zhang-alto-opendaylight-impl-01 Abstract This text introduces some experiences of implementing ALTO in OpenDaylight (ODL). The main key issues about design and implementation are discussed. Some of these issues have been figured out in the current implementation, the others have not. This text also gives some possible designs to discuss. 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 October 23, 2016. Copyright Notice Copyright (c) 2016 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 Zhang, et al. Expires October 23, 2016 [Page 1] Internet-Draft Implementing ALTO in ODL April 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Changes Since Version -00 . . . . . . . . . . . . . . . . 3 2. Key Design Issues . . . . . . . . . . . . . . . . . . . . . . 3 3. Design and Implement ECS . . . . . . . . . . . . . . . . . . 4 3.1. Current Solution to Compute the Routing Path . . . . . . 5 3.2. Multi-Path in ECS . . . . . . . . . . . . . . . . . . . . 6 3.3. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Precise Cost Computation . . . . . . . . . . . . . . . . 7 3.5. Available Bandwidth with Shared Links . . . . . . . . . . 8 3.6. A Comprehensive Architecture . . . . . . . . . . . . . . 8 4. Design and Implement Dynamic Maps . . . . . . . . . . . . . . 9 4.1. Challenges about handling dynamic network . . . . . . . . 9 4.2. Current Solution about Dynamic Network . . . . . . . . . 10 5. Achieve MD-SAL and Cross Platform Design . . . . . . . . . . 12 5.1. Overview of Current ALTO Server in ODL . . . . . . . . . 12 5.2. Implementation of Models . . . . . . . . . . . . . . . . 14 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. ECS Extension . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Network State Abstraction . . . . . . . . . . . . . . . . 17 6.3. A Loose Coupling Design to Support the Cross Platform . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Normative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction ODL is one of the most popular Software Defined Networking (SDN) controller. We have implemented an ALTO server in ODL. However, some issues are very important to the design and implementation of ALTO server. In this document, we present some experiences of implementing ALTO in ODL, and discuss some key issues about the design and implementation. Zhang, et al. Expires October 23, 2016 [Page 2] Internet-Draft Implementing ALTO in ODL April 2016 1.1. Terminology o ECS: Endpoint Cost Service o ODL: OpenDaylight, an implementation of SDN controller o SSE: Server-Sent Event o MD-SAL: Model-Driven Service Abstraction Layer 1.2. Changes Since Version -00 o Restated fine-grained ECS problem in Section 2 and refined the experience of implementing ECS in ODL in Section 3. The section about "Customized Routing Cost" has been removed because of it is not a specific problem in ODL. o Introduced details about the experience of implementing auto-map in Section 4.2. o Updated overview of current implementation in Section 5.1 and introduced the solution for extensibility problem. o Moved the cross platform problem to Section 6. 2. Key Design Issues To implement ALTO in OpenDaylight, we identify a set of design and implementation issues: o T-ALTO-MDSAL: How to use MD-SAL to implement ALTO? The core of OpenDaylight is MD-SAL, which provides mechanisms to describe, store, and access state in ODL data store. To achieve a relatively native design, we should use MD-SAL. At the same time, ALTO has defined its own data types such as Endpoint, PID, Vtag, Network Map, Cost Map. Hence, a first, basic design issue is how to represent the basic ALTO data in ODL data store. o T-CrossPlatform: How to support cross platform? Balancing the preceding consideration, although we focus on implementing ALTO in ODL, we should also consider porting to other SDN controllers such as ONOS. Hence, we target a loose coupling architecture, to achieve an extensible, cross-platform design as much as possible. o T-ECS: How to implement ECS? Zhang, et al. Expires October 23, 2016 [Page 3] Internet-Draft Implementing ALTO in ODL April 2016 Going from syntax to semantics, we first consider ECS, which is a basic service in ALTO. One may consider the map services as aggregation services on top of ECS. Hence, a key implementation design is how to compute the cost between two endpoints in ODL. Comparing with traditional network, there are several differences in the SDN scenario. The central controller can collect the topology and statistics information of network easily. But some problems like fine-grained path and reactive mode have to be solved. o T-AutoMap: How to allow a network operator (ALTO server administrator) to define automatically generated network maps? One possibility to define a network map is to allow the network operator to upload a static file defining the PIDs of the network map. Although this approach is modular, it is inconvenient. See Section 16 in [RFC7285]. Conceptually, a network map defines a partition of endpoints according to the properties of the endpoints. A mechanism (e.g., a description language) which allows a network operator to define the grouping conditions and then the ALTO server automatically to compute the partition can provide substantial value. After computing a network map, the ALTO server should also be able to compute the corresponding cost map, for each given cost metric. Since network state can be dynamic, we need to update network maps and cost maps when network state changes. o T-Push: How to push updates to ALTO clients? Client would like to receive update information as soon as possible. See Internet draft [DRAFT-SSE]. 3. Design and Implement ECS There are two key issues when we try to implement ECS in ODL: o How to get an exact forwarding path between two Endpoints. o How to provide the reasonable costs computation in one query. We have not yet implemented the functionality of ECS completely because of some challenges. Some of these challenges are caused by the limitation of ODL, but some are general problems in the SDN scenario. Developers may face several challenges when implementing ECS in ODL. The following are the main challenges we faced: Zhang, et al. Expires October 23, 2016 [Page 4] Internet-Draft Implementing ALTO in ODL April 2016 About computing routing path: o Challenge 1: There will be multiple fine-grained paths between two Endpoints in the SDN scenario. o Challenge 2: The routing path may be re-active and have not been applied when the ECS query arrives. o Challenge 3: SDN controllers like ODL support multiple applications to do the path computation. About computing cost: o Challenge 4: How to evaluate the precise cost of a known flow. o Challenge 5: How to evaluate the reasonable costs when there are shared links. In the following several subsections, we will talk about details of these challenges and our solutions. Some challenges have not been solved, and we discuss the reasons and give some proposals in Section 6. 3.1. Current Solution to Compute the Routing Path Currently, our implementation of routing path computation in ODL contains two components: Host Tracker and Forwarding Rules Manager (FRM) Checker. And this implementation can only work with OpenFlow- enabled networks. The Host Tracker will handle the ARP packets in the network and maintain the information of end hosts. It will store the bindings between MAC addresses and IP addresses. Because our ALTO server works on OpenFlow based networks, we need to know an OpenFlow match to decide a path. The OpenFlow match can be L2 or L3 in the real network. But the ECS query message only provides L3 information (IP address) of endpoints. So we implement a component like Host Tracker to maintain the map from L3 to L2. ODL provides an FRM to manage the flow tables of real OpenFlow switches connected to the ODL controller. For pro-active paths, we can look up FRM to compute them. FRM Checker is such a component which provides API to compute pro-active paths by accepting L2 or L3 matches. Zhang, et al. Expires October 23, 2016 [Page 5] Internet-Draft Implementing ALTO in ODL April 2016 +-------------+ L3 request -->| FRM Checker | +-------------+ | | Look up Flow Tables | | get L2/L3 Mapping v v +-----+ +--------------+ | FRM | | Host Tracker | +-----+ +--------------+ : : ,-----------. ,-' Source of `-. ( topological ) `-. information ,-' `-----------' Figure 1: Overview of Routing Path Computation. The overview of path computation module can be presented in Figure 1. And the algorithm of looking up FRM is presented in Figure 2. while (currentSwitchId != dstSwitchId) { r <- loopupFlowTable(switchId, match); if (!r) { forceComputeRoutingPath(switchId, match); r <- loopupFlowTable(switchId, match); } currentSwitchId = getNextSwitchId(r); } Figure 2: Algorithm about lookupFRM(). 3.2. Multi-Path in ECS In the actual environment of network, there may be more than one routing path from the source IP to the destination IP. The cost between two Endpoints is decided by the actual routing path, but we may not get the actual routing path from the pair of the source IP and the destination IP. One reason is related to Challenge (2), and the subsection will talk about the details. The other reason is that the ALTO server cannot get enough information from the input of ECS. For example, assume there are two hosts in the network, labeled as H1 and H2. And there are three switches in the links between H1 and H2. The topology is described as Figure 3. When H1 send data to the TCP port 22 of H2, the packet will be forwarded along the path "H1 - S1 - S3 - S2 - H2". But when H1 send HTTP request to H2, the packet will be forwarded along the path "H1 - S1 - S2 - H2". Zhang, et al. Expires October 23, 2016 [Page 6] Internet-Draft Implementing ALTO in ODL April 2016 H1 ---- S1 ---- S2 ---- H2 \ / \ / S3 Figure 3: Multi-Path in Network. In this case, the ALTO server will get two paths when looking up FRM to compute the routing path. Since the ALTO server does not know which type of packet will be sent by H1, it cannot decide which path is the actual one. This problem is caused by the limitation of ALTO protocol and the features of OpenFlow. One of the most important features in OpenFlow-enabled networks is to support fine-grained path which makes the controlling of paths more flexible. But the original ALTO protocol is not expressive in this scenario. A possible solution is proposed in [DRAFT-ECS-FLOW]. The implementation of this solution is in progress. 3.3. Reactive Mode We find this is a common problem in OpenFlow-enabled network. Once the network is working on the reactive mode, we may not know the real path only by checking devices information. There may be some routing paths which are still not active. Only when the special packets are sent to the special destination, the rule will be called to insert the Flow Table. So we may not get the routing path by looking up FRM. We do not have a good solution to handle it. Although several modules in ODL provide some routing services to compute the path (such as l2switch), we still cannot know which module will be active. We have tried to extend the input and output format of ECS. But it is not enough to solve this challenge. 3.4. Precise Cost Computation Cost computation is often based on network statistics. In traditional network, we can setup some agents to monitor the network statistics in real time. But in SDN scenario, collecting the network statistics is easier. OpenFlow switches will store these statistics information in the Meter Tables (assume the switches support OpenFlow 1.3). And the ODL controller can look up these information directly without executing any measuring tasks. Zhang, et al. Expires October 23, 2016 [Page 7] Internet-Draft Implementing ALTO in ODL April 2016 The ECS module SHOULD evaluate the path cost as precisely as possible. However, OpenFlow switches can only collect their own statistics. If we want to get the statistics between endpoints, we have to make them aggregate. It MAY NOT be precise. If we want to make the evaluation more precise, we may have to do some real measurements in the network. 3.5. Available Bandwidth with Shared Links Some cost metrics requested by clients may be shared by different flows, such as 'bandwidth'. For example, a client sends an ECS request to get the available bandwidths between a list of source IPs and a list of destination IPs. The following example is a very common case: src1 --- s1 s5 --- dst1 \ / s3 --- s4 / \ src2 --- s2 s6 --- dst2 Figure 4: Bandwidth with Links Shared. In the case described in Figure 4, "s3 - s4" is a link shared by all flows between [src1, src2] and [dst1, dst2]. If the client would like to select two pairs from (srci, dsti), their paths must share bandwidth in the link "s3 - s4". So the ALTO server cannot compute the available bandwidth of each flow individually. An possible solution is to divide maximum bandwidth and available bandwidth into different 'cost-mode'. But it is still helpless to compute available bandwidth. Another solution is to introduce Routing State Abstraction ([DRAFT-RSA]). The details will be discussed in Section 6. 3.6. A Comprehensive Architecture The following is a comprehensive architecture to figure out our design: Zhang, et al. Expires October 23, 2016 [Page 8] Internet-Draft Implementing ALTO in ODL April 2016 HTTP +--------------+ Request----->| | | ECS Service | +-----------+ HTTP <-----| |---->| Routing | Response +------|-------+ | Path | +------|-------+ | Computing | | Cost |<----| Module | | Computing | +-----------+ | Module | +--------------+ Figure 5: A Comprehensive Architecture of ECS. 4. Design and Implement Dynamic Maps The ALTO server should be able to handle dynamic network. For example, when some nodes or links in the network topology change, the ALTO server must regenerate Network Maps and recompute Cost Map. According to our experiences of implementing ALTO in ODL, there may be also several challenges about handling dynamic network. We will indicate these challenges and our solutions below. Some challenges have been solved, and we will introduce our solution. But some challenges still remain to be dealt with. We will also discuss them and the possible solutions in Section 6. 4.1. Challenges about handling dynamic network The key challenges about dealing with dynamic network are indicated below: o How to regenerate Network Maps: Network Maps are dependent on the network topology. The ALTO server should update Network Maps when the topology changes. For example, when a new host H1 is added to the network, the ALTO server should assign a PID for H1 in one Network Map. The challenge is that different Network Maps may have different rules to decide PID, but it is difficult to describe these rules. So it is hard to regenerate Network Maps automatically. o When and How to recompute Cost Map: Every Cost Map depends on one Network Map. When the dependent Network Map is regenerated, the related Cost Map also need to be updated. Generally speaking, the ALTO server should recompute the cost for the PID which is updated. But sometimes, the update of Zhang, et al. Expires October 23, 2016 [Page 9] Internet-Draft Implementing ALTO in ODL April 2016 PID does not effect the cost. The ALTO server should decide when and how to recompute Cost Map. o How to handle updates incrementally and quickly: According to [DRAFT-SSE], the ALTO server may provide a service which allows user to require incremental updates using SSE. But the ALTO server must have the capability to listen, compute and maintain the incremental updates. The challenge is how to provide incremental updates service correctly and efficiently. 4.2. Current Solution about Dynamic Network 4.2.1. Basic Service to Handle Dynamic Network To handle the dynamic network, finding the updates of network is the basic capability. The update about hosts is the most basic type of updates. As the description in Section 5.1.1, the ALTO server introduces a module named 'hosttracker' to find new hosts in the network. For example, once a new host H1 is added to the network, ALTO server will get the address of H1, and record it to the default Network Map. 4.2.2. Solution to Regenerate Network Maps Our goal is to provide easy-to-use, yet complete specification and algorithms to allow administrators to define grouping of network nodes. We have designed an anchor-based Auto-Map service, which can generate Network Maps from network topology automatically. This service uses the nearest-neighbor algorithm to generate the Network Maps. Administrators can modify a JSON format configuration file to configure the auto-map service. An example configuration file is presented by Figure 6. Zhang, et al. Expires October 23, 2016 [Page 10] Internet-Draft Implementing ALTO in ODL April 2016 nearest-network-map-config.json { "net-map-id": "nearest-network-map", "net-map-grp-alg": "nearest-alg", "net-map-grp-para": { "metric": "hopcount", "anchors": { "pid1": ["sw1", "sw2"], "pid2": ["sw3"], "pid3": ["sw4", "sw5"] } } } Figure 6: An Example of Network Auto-Map Configuration File. 4.2.3. Solution to Recompute the Cost Map Auto-Map service also provides a generic method to define the cost computation between two PIDs. The basic idea is to compute inter-PID cost from inter-endpoint costs: Given PIDS Pa and Pb, there will be |Pa| x |Pb| inter-endpoint costs. We provide multiple definitions (median, x-percentile, avg) as the cost from Pa to Pb, and allow multiple algorithms to do the computation (total enumeration, random sampling). Administrators can also setup a JSON format configuration file to configure the related arguments. An example configuration file is presented by Figure 7. cost-map-config.json { "cost-map-id": "cmap1", "uses": [ "my-nn-auto-network-map" ], "cost-type": { "cost-mode": "numerical", "cost-metric": "hopcount" }, "cost-map-group-metric": "avg", "cost-map-group-alg": { "alg": "random-sampling", "count" : 10000 } } Figure 7: An Example of Cost Auto-Map Configuration File. Zhang, et al. Expires October 23, 2016 [Page 11] Internet-Draft Implementing ALTO in ODL April 2016 4.2.4. Solution to Handle Incremental Updates We are implementing ALTO incremental updates using SSE in ODL. The following is a very simple design: +----------------+ | Update Service | +----------------+ | | Get diff patch | +--------------+ | DAG for Data | +--------------+ | | Maintain | +-------------+ | Data Change | | Listener | +-------------+ Figure 8: A Simple Architecture of the Update Service. The update service is a top module to handle HTTP request from the client. The "DAG for Data" module computes JSON patches and store them to maintain all data changes from listener. 5. Achieve MD-SAL and Cross Platform Design 5.1. Overview of Current ALTO Server in ODL 5.1.1. Architecture ALTO server provides two types of user interfaces -- one for application developers and the other for network managers. The developer interface provides a HTTP server to handle request/response defined in [RFC7285]. And the manager interface is a command-line interface, which provides commands to operate (add/delete/change) the data in data store. Zhang, et al. Expires October 23, 2016 [Page 12] Internet-Draft Implementing ALTO in ODL April 2016 +-------------------------------------------------------+ | ALTO-NorthBound | +-------------------------------------------------------+ : : : : +-----------+ +-----------+ +----------+ +-----------+ | ECS-Route | | EPS-Route | | MS-Route | | IRD-Route | +-----------+ +-----------+ +----------+ +-----------+ : : : +------------+ : | Routed RPC | : +------------+ : / \ +----------+ ... +------------+ +----------+ | Instance | | Manual Map | | Auto-Map | +----------+ Resource | Instance | | Instance | | `..... Pool ...+------------+ +----------+ | : | | +-------------------------------------------------------+ | OpenDaylight Data Store | +-------------------------------------------------------+ Figure 9: ALTO Architecture Overview. As depicted in Figure 9, the services in this server are model- driven, and the foundation of these services is the data store in ODL. The models in this ALTO server define two major things: data types and the interfaces of RPCs (See [DRAFT-ALTO-YANG]. As it can be seen from the figure, there are five conceptual components whose names and functionalities are introduced in the following sections. 5.1.2. Components The following is an introduction about the main components in this ALTO server. o Northbound: The most important functionality of the northbound is to forward the incoming requests to the corresponding route. It has also defined the base URL for ALTO resources. Other connection-related operations can be taken here, such as authentication. o Route: Route, short for northbound route, is where the ALTO protocol is processed. Upon a request arrival, it must check the media types, parse the request body (if any) to customized input formats and forward to the corresponding instance. When the output is Zhang, et al. Expires October 23, 2016 [Page 13] Internet-Draft Implementing ALTO in ODL April 2016 returned, the route must transform it into RFC-compatible format, set the correct media type and forward it to the northbound. o Instance: Instance implements the ALTO services. Different instances can use different information sources and have different internal storage and logic. o Datastore: Datastore is where the related data, including network statistics and user configurations, are stored. The OpenDaylight has already provided a tree-like datastore based on the YANG model. o Resource Pool: The resource pool is where the instances SHOULD be registered. It is essential to support the standard service models and the standard northbound routes, and to provide information to the IRD. 5.1.3. Extensibility In the practice of implementing ALTO server, we find extensibility is very important. ALTO needs extensibility because of two aspects. The one is the protocol extension. There are more and more ALTO protocol extensions, and some of them have been used in the practice. ALTO server SHOULD provide a easy way to enable additional services for protocol extensions. In the design of Figure 9, we can add new route modules for the additional services easily. The other one is the different implementations of services. A better practice is to allow different implementations for the services with the same interface. The architecture of Figure 9 allow different service instances to share the same route modules. It is enough extensible. 5.2. Implementation of Models Programming in ODL is model-driven since Lithium release. So we should define the data types and RPCs by defining the YANG model. But when we try to use the YANG model defined in [DRAFT-ALTO-YANG] to implement the ALTO server in ODL, several problems occur, making some services not work. In the following, we present the problems about the YANG model and our corresponding solutions. Zhang, et al. Expires October 23, 2016 [Page 14] Internet-Draft Implementing ALTO in ODL April 2016 5.2.1. The definition of 'cost'. Outputs of the Cost Map and ECS both require a data type named 'cost', which stands for the cost between a source and a destination. Section A.1 of [DRAFT-ALTO-YANG] defines 'cost' as following: grouping alto-cost { anyxml cost { mandatory true; description "ALTO cost is a JSONValue, which could be an object, array, string, etc. (Ref: RFC 7159 Sec.3.)"; } } In this definition, 'cost' is declared as the 'anyxml' statement, which is used to represent an unknown chunk of XML (see [RFC6020]). It is because that 'cost' is defined as a JSONValue in [RFC7285], which could be any valid types in JSON. But when we tried to implement the 'cost' type with its definition in the Lithium Release of ODL, we found that 'anyxml' was not implemented by the YANG parser as we expected. Actually, there are two problems needed to be solved: 1. The Cost Map and ECS need different definitions of 'cost' type to generate different JAVA classes in ODL. 2. The 'cost' type could be different built-in types in different Cost Maps or outputs of ECS. For the first problem, the 'augment' statement in YANG model could solve it. For the second problem, however, we cannot use the 'anyxml' statement because JAVA is not dynamically typed. In order to support different built-in types, we use 'string' to define 'cost' type. But ALTO server must parse the value of 'cost' by itself. Following is the current YANG model for the 'cost' type: Zhang, et al. Expires October 23, 2016 [Page 15] Internet-Draft Implementing ALTO in ODL April 2016 module alto-cost-default { namespace "urn:opendaylight:alto:costdefault"; prefix "alto-cost-default"; import alto-service {prefix alto-restconf;} augment "/alto-restconf:endpoint-cost-service/alto-restconf: output/alto-restconf:endpoint-cost-service/alto-restconf: endpoint-cost-map/alto-restconf:dst-costs" { leaf cost-default { type string; } } augment "/alto-restconf:resources/alto-restconf:cost-maps /alto-restconf:cost-map/alto-restconf:map/ alto-restconf: dst-costs" { leaf cost-default { type string; } } } 5.2.2. The definition of 'constraint' 'Constraint' is an optional capability in [RFC7285]. The definition provided by [DRAFT-ALTO-YANG] is presented as follows: typedef constraint { type string { pattern "(gt|ge|lt|le|eq) [0-9]+"; } ... } This definition cannot support float 'cost' type. And we give the following definition to replace with it. typedef constraint { type string { pattern "(gt|ge|lt|le|eq) [0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?"; } ... } Zhang, et al. Expires October 23, 2016 [Page 16] Internet-Draft Implementing ALTO in ODL April 2016 6. Discussions 6.1. ECS Extension To address some issues in Section 3, we need to extend the data format of ECS. For example, ODL must know the TCP port of the destination to compute the actual routing path. So the client must indicate this information in the JSON of request. 6.2. Network State Abstraction In some cases, the client send an ECS request to get the available bandwidths of some flows, which have shared links. The traditional method cannot give reasonable bandwidths for each flow. A possible solution to solve this issue is to introduce Routing State Abstraction. 6.3. A Loose Coupling Design to Support the Cross Platform The current architecture of the ALTO server couples with the implementation of ODL. A loose coupling architecture design is expected. It will be very helpful to support the cross platform. According to the discussion in Section 3.1, however, some services cannot decouple with ODL completely, such as ECS. 7. IANA Considerations This document does not define any new media type or introduce any new IANA consideration. 8. Security Considerations This document does not introduce any privacy or security issue not already present in the ALTO protocol. 9. Acknowledgments The authors thank discussions with Xin (Tony) Wang and reviews by Dan Peng and Qiao Xiang. 10. References 10.1. Informative References Zhang, et al. Expires October 23, 2016 [Page 17] Internet-Draft Implementing ALTO in ODL April 2016 [DRAFT-ALTO-YANG] Shi, X. and Y. Yang, "A YANG Data Model for Base ALTO Data", 2015, . [DRAFT-ECS-FLOW] Wang, J. and Q. Xiang, "ALTO Extension: Endpoint Cost Service for Flows", 2015, . [DRAFT-RSA] Gao, K., Wang, X., Yang, Y., and G. Chen, "ALTO Extension: A Routing State Abstraction Service Using Declarative Equivalence", 2015, . [DRAFT-SSE] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", 2015, . 10.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", Oct 2010, . [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", 2014, . Authors' Addresses J. (Jensen) Zhang Tongji University 4800 Cao'an Road Shanghai 201804 China Email: jingxuan.n.zhang@gmail.com Zhang, et al. Expires October 23, 2016 [Page 18] Internet-Draft Implementing ALTO in ODL April 2016 Kai Gao Tsinghua University 30 Shuangqinglu Street Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Y. Richard Yang Yale University 51 Prospect St New Haven CT USA Email: yry@cs.yale.edu Zhang, et al. Expires October 23, 2016 [Page 19]