ALTO WG G. Bernstein, Ed. Internet-Draft Grotto Networking Intended status: Informational Y. Yang, Ed. Expires: April 24, 2014 Yale University Y. Lee, Ed. Huawei Technologies October 21, 2013 ALTO Topology Service: Uses Cases, Requirements, and Framework draft-bernstein-alto-topo-00 Abstract Exposing additional topology information of networks to applications and users beyond that of the current ALTO protocol can enable many important existing and emerging use cases, and many network providers already provide additional information about their networks. At the same time, there is no standard for exposing network topology in a manner that provides simplification via abstraction to the application layer and information hiding via abstraction to the network provider. In this document, we provide a survey of use-cases for extended network topology information, present some initial requirements for such services, and then give a framework of how to integrate such an extended ALTO topology service with network control infrastructure. 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 April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Bernstein, et al. Expires April 24, 2014 [Page 1] Internet-Draft Topology Service Framework October 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Uses Cases . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Technology Specific Examples . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 4. ALTO Topology Framework . . . . . . . . . . . . . . . . . . . 5 4.1. Abstract Topology Representation . . . . . . . . . . . . 5 4.2. Sources of Raw Topology Information . . . . . . . . . . . 5 4.3. Service/Client Specific Topology Abstraction . . . . . . 5 4.4. Reservation System Compatibility . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Topology is a basic property of a network. Hence there is a spectrum of use cases where an application (or user) can benefit from obtaining some knowledge of the topology of the network that it uses or considers using, beyond the "single-switch"abstraction topology abstraction presented in the ALTO Base Protocol [I-D.ietf-alto-protocol] as discussed in [I-D.yang-alto-topology]. As a simple case, many networks already provide public views to their topologies so that current or potential users of their networks can learn more about their networks; for example, see Verizon [1]; Comcast [2]; CenturyLink [3]; BT [4]; China Telecom [5]; Internet 2 [6]. A user (application) with such information may conduct a wide variety of analysis, for example, in determining its service provider(s). Bernstein, et al. Expires April 24, 2014 [Page 2] Internet-Draft Topology Service Framework October 2013 For more advanced use cases such as in a programmatic setting, a topology manager of a network may expose a topology of the network to an application so that the application can provide its input regarding the operations of the network. A concrete example setting is the recent development of Software Defined Networking (SDN); for example see OpenDayLight [7]; Maple [8]. The objective of this document is three folds: (1) it surveys general uses cases and existing designs of how network topologies are exposed to applications; (2) it presents the requirements in exposing network topologies; and (3) it gives a framework of how network topologies to applications can be integrated into network control. 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 RFC 2119 [RFC2119]. 2. Uses Cases Uses cases generally relate to some type of cost metric optimization, application policy, resource requirements (bandwidth), and/or performance criteria such as delay. In the following we give a non- exhaustive list of uses cases for a extended ALTO topology service. Large Bandwidth Applications that make extensive use of network bandwidth resources are discussed in [I-D.bernstein-alto-large-bandwidth-cases]. In addition to a general discussion of large bandwidth requirements specific examples of video on demand and inter-data center networking are given. An optimization example for a scheduled backup service can be found at http://www.grotto-networking.com/ BackupExample.html [9]. Enhanced Reliability GMPLS [RFC3945] and GMPLS routing [RFC4202] in particular have included enhanced reliability support in the form of shared risk link group (SRLG) information that lets a path computation entity understand which links are at risk of simultaneous failures (fate sharing). In addition in optical networks link and node diverse paths are a common method to enhance reliability [OptControl]. However in many cases only the application may have a full view of its reliability needs. For example consider a high reliability application making use of multiple data centers Bernstein, et al. Expires April 24, 2014 [Page 3] Internet-Draft Topology Service Framework October 2013 for redundancy and increased reliability, such reliability would be significantly diminished if the paths to those data centers shared similar fates. Latency Sensitivity From high performance gaming to high frequency trading latency can critically impact application performance. However, reductions in latency may need to be factored against other costs or resource requirements. As mentioned in http://cacm.acm.org/magazines/2013/10/168186-barbarians- at-the-gateways/abstract [10] some high frequency trading applications need to make use of both a low latency path and a high bandwidth path. Policy Enforcement Many application specific requirements such as the HIPPA privacy rule, can place restrictions on where a certain customers data may be kept, or what geographic regions a customers data can traverse, etc... Enhancing topology information made available to an application can help it ensure such requirements are satisfied. 2.1. Technology Specific Examples Here we furnish a partial list of examples that illustrate one or more properties desirable in an extended ALTO topology service. SDN: Project Floodlight Project floodlight provides limited inter switch topology information https://github.com/wallnerryan/floodlight/blob/ master/example/graphTopo.py [11]. SDN: Open Daylight The Open Daylight project is aiming to supply a "north bound" topology service https://jenkins.opendaylight.org/controller/ job/controller-merge/ws/opendaylight/northbound/topology/ target/site/wsdocs/el_ns0_topology.html [12]. Grid Computing - OGF NML The Open Grid Forum has developed a general Network Markup Language http://www.ogf.org/documents/GFD.206.pdf [13]. This borrows concepts from GMPLS and ITU-T G.805 models. However, it is not aimed at application layer users, but rather grid computing operators. Fiber Maps (multiple carriers) TBD. Bernstein, et al. Expires April 24, 2014 [Page 4] Internet-Draft Topology Service Framework October 2013 HPC - cluster placement problem TBD. 3. Requirements Formal requirements to come... 4. ALTO Topology Framework The framework portion of this document, like most IETF frameworks, is an informational section that shows how various systems could come together to form an extended ALTO topology service. 4.1. Abstract Topology Representation References [I-D.lee-alto-app-net-info-exchange] and [I-D.yang-alto-topology] provide tentative models and encodings for abstract topology representation. 4.2. Sources of Raw Topology Information From management systems, to proprietary interfaces to routing systems, to i2rs... 4.3. Service/Client Specific Topology Abstraction Although only the topology/resource abstraction format would be subject to standardization, this section will illustrate some techniques that can be efficiently used to derived service and client specific topology abstractions. References [I-D.lee-alto-app-net-info-exchange] and [I-D.yang-alto-topology] give examples of how raw network topology information can be processed into abstracted application specific form. A lengthier paper with more examples and technology considerations can be found at [14]. 4.4. Reservation System Compatibility As mentioned in the requirements ALTO topology extensions must be able to work with technologies that require resource reservations as well as those that don't. In implementing an overall system the information supplied by an extended ALTO topology service will need to be compatible with a "reservation system" if there is one. At the IETF we have seem similar requirements for compatibility between GMPLS routing and signaling systems, particularly via the concept of loose routes. Bernstein, et al. Expires April 24, 2014 [Page 5] Internet-Draft Topology Service Framework October 2013 5. Acknowledgements Hopefully we'll have lots of interested folks commenting and we'll give them credit here. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations All drafts are required to have a security considerations section and this will as we flesh it out. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 8.2. Informative References [I-D.bernstein-alto-large-bandwidth-cases] Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth Query and Control of Core Networks", draft-bernstein-alto- large-bandwidth-cases-00 (work in progress), June 2011. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- ietf-alto-protocol-20 (work in progress), October 2013. [I-D.lee-alto-app-net-info-exchange] Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi, "ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications ", draft-lee-alto-app-net-info-exchange-03 (work in progress), October 2013. [I-D.yang-alto-topology] Yang, Y., "ALTO Topology Considerations", draft-yang-alto- topology-00 (work in progress), July 2013. [OptControl] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network Control", 2004. Bernstein, et al. Expires April 24, 2014 [Page 6] Internet-Draft Topology Service Framework October 2013 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. Authors' Addresses Greg M. Bernstein (editor) Grotto Networking Fremont, CA US Phone: +01 510 623 8575 Email: gregb@grotto-networking.com Y. Richard Yang (editor) Yale University 51 Prospect St New Haven, CT USA Email: yry@cs.yale.edu Young Lee (editor) Huawei Technologies 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Phone: (927) 509-5599 Email: ylee@huawei.com Bernstein, et al. Expires April 24, 2014 [Page 7]