!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"> <!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml"> <!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml"> ]> ALTO Topology Service: Uses Cases, Requirements, and Framework Grotto Networking

Fremont CA US +01 510 623 8575 [email protected]
Yale University
51 Prospect St New Haven CT USA [email protected]
Huawei Technologies
1700 Alma Drive, Suite 500 Plano TX 75075 USA (927) 509-5599 [email protected]
Transport ALTO WG template 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.
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 as discussed in . 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; Comcast; CenturyLink; BT; China Telecom; Internet 2. A user (application) with such information may conduct a wide variety of analysis, for example, in determining its service provider(s). 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; Maple. 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.
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.
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. Applications that make extensive use of network bandwidth resources are discussed in . 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. GMPLS and GMPLS routing 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 . 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 for redundancy and increased reliability, such reliability would be significantly diminished if the paths to those data centers shared similar fates. 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 some high frequency trading applications need to make use of both a low latency path and a high bandwidth path. 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.
Here we furnish a partial list of examples that illustrate one or more properties desirable in an extended ALTO topology service. Project floodlight provides limited inter switch topology information https://github.com/wallnerryan/floodlight/blob/master/example/graphTopo.py . 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 . The Open Grid Forum has developed a general Network Markup Language http://www.ogf.org/documents/GFD.206.pdf . 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. TBD. TBD.
Formal requirements to come...
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.
References and provide tentative models and encodings for abstract topology representation.
From management systems, to proprietary interfaces to routing systems, to i2rs...
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 and 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 .
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.
Hopefully we'll have lots of interested folks commenting and we'll give them credit here.
This memo includes no request to IANA.
All drafts are required to have a security considerations section and this will as we flesh it out.
&RFC2119; Minimal Reference ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications This draft proposes ALTO information model and protocol extensions to support application and network resource information exchange for high bandwidth applications in partially controlled and controlled environments as part of the infrastructure to application information exposure (i2aex) initiative. Use Cases for High Bandwidth Query and Control of Core Networks This draft describes two generic use-cases that illustrate application layer traffic optimization concepts applied to high bandwidth core networks. For the purposes here high bandwidth will mean bandwidth that is significant with respect to the capacity of a wavelength in a wavelength division multiplexed optical transport system, e.g., 10-40Gbps or more. For each of these generic use cases, we present a generic optimization problem, look at the type of information needed (query interface) to perform the optimization, investigate a reservation interface to request network resources, and also consider enhanced availability and recovery scenarios. ALTO Topology Considerations The Application-Layer Traffic Optimization (ALTO) Service has defined Network and Cost maps to provide basic network information. In this document, we discuss some initial thinking on adding topology in ALTO. Generalized Multi-Protocol Label Switching (GMPLS) Architecture Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.</t><t> This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK] Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] Optical Network Control ALTO Protocol Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at looking glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) Service provides network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO Service would primarily be provided by ISPs, other entities such as content service providers could also operate an ALTO Service. Applications that could use this service are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.