[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/