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.

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
• 1.1. Requirements Language
• 2. Uses Cases
• 2.1. Technology Specific Examples
• 3. Requirements
• 4. ALTO Topology Framework
• 4.1. Abstract Topology Representation
• 4.2. Sources of Raw Topology Information
• 4.3. Service/Client Specific Topology Abstraction
• 4.4. Reservation System Compatibility
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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; 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.

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.

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 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 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 .

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 .

Grid Computing - OGF NML

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.

Fiber Maps (multiple carriers)

TBD.

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 http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf.

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.

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

8.2. Informative References

Authors' Addresses