One document matched: draft-bernstein-alto-topo-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!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">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-bernstein-alto-topo-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Topology Service Framework">ALTO Topology Service: Uses Cases, Requirements, and
Framework</title>
<author fullname="Greg M. Bernstein" initials="G. M." role="editor"
surname="Bernstein">
<organization>Grotto Networking</organization>
<address>
<postal>
<street></street>
<city>Fremont</city>
<region>CA</region>
<code></code>
<country>US</country>
</postal>
<phone>+01 510 623 8575</phone>
<email>gregb@grotto-networking.com</email>
</address>
</author>
<author fullname="Y. Richard Yang" initials="Y." role="editor"
surname="Yang">
<organization>Yale University</organization>
<address>
<postal>
<street>51 Prospect St</street>
<city>New Haven</city>
<region>CT</region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>yry@cs.yale.edu</email>
</address>
</author>
<author fullname="Young Lee" initials="Y." role="editor"
surname="Lee">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<phone>(927) 509-5599</phone>
<email>ylee@huawei.com</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>ALTO WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t> 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> 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 <xref target="I-D.ietf-alto-protocol"/>
as discussed in <xref target="I-D.yang-alto-topology"></xref>.</t>
<t>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
<eref target="http://www.verizonenterprise.com/about/network/maps/map.xml">Verizon</eref>;
<eref target="http://business.comcast.com/enterprise/about-us/our-network">Comcast</eref>;
<eref target="http://www.centurylink.com/business/resource-center/network-maps/">CenturyLink</eref>;
<eref target="http://www.bt.net/info/europe.shtml">BT</eref>;
<eref target="http://www.chinatelecomusa.com/content.asp?pl=627&sl=637
&contentid=638&id=1&indexid=0">China Telecom</eref>;
<eref target="http://atlas.grnoc.iu.edu/atlas.cgi?map_name=Internet2%20IP%20Layer">Internet 2</eref>.
A user
(application) with such information may conduct a wide variety of
analysis, for example, in determining its service provider(s).</t>
<t>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 <eref target="https://wiki.opendaylight.org/view/OpenDaylight_Controller:
Architectural_Framework">OpenDayLight</eref>;
<eref target="http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p87.pdf">Maple</eref>.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="use_cases" title="Uses Cases">
<t>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.
<list hangIndent="8" style="hanging">
<t hangText="Large Bandwidth"><vspace blankLines="0"/>Applications that make extensive use
of network bandwidth resources are discussed in
<xref target="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
<eref target="http://www.grotto-networking.com/BackupExample.html">
http://www.grotto-networking.com/BackupExample.html</eref>.
</t>
<t hangText="Enhanced Reliability"><vspace blankLines="0"/>GMPLS <xref target="RFC3945"/> and GMPLS
routing <xref target="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 <xref target="OptControl"/>.
<vspace blankLines="1"/>
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.
</t>
<t hangText="Latency Sensitivity"><vspace blankLines="0" /> 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 <eref target="http://cacm.acm.org/magazines/2013/10/168186-barbarians-at-the-gateways/abstract">
http://cacm.acm.org/magazines/2013/10/168186-barbarians-at-the-gateways/abstract</eref> some
high frequency trading applications need to make use of both a low latency path and a high bandwidth
path.
</t>
<t hangText="Policy Enforcement"><vspace blankLines="0"/>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.
</t>
</list>
</t>
<section anchor="tech_use_cases" title="Technology Specific Examples">
<t>Here we furnish a partial list of examples that illustrate one or more properties
desirable in an extended ALTO topology service.
<list hangIndent="8" style="hanging">
<t hangText="SDN: Project Floodlight"><vspace blankLines="0"/>Project floodlight
provides limited inter switch topology information <eref target="https://github.com/wallnerryan/floodlight/blob/master/example/graphTopo.py">
https://github.com/wallnerryan/floodlight/blob/master/example/graphTopo.py
</eref>.
</t>
<t hangText="SDN: Open Daylight"><vspace blankLines="0"/>
The Open Daylight project is aiming to supply a "north bound" topology service
<eref target="https://jenkins.opendaylight.org/controller/job/controller-merge/ws/opendaylight/northbound/topology/target/site/wsdocs/el_ns0_topology.html">
https://jenkins.opendaylight.org/controller/job/controller-merge/ws/opendaylight/northbound/topology/target/site/wsdocs/el_ns0_topology.html
</eref>.
</t>
<t hangText="Grid Computing - OGF NML"><vspace blankLines="0"/>The Open Grid Forum has developed a
general Network Markup Language <eref target="http://www.ogf.org/documents/GFD.206.pdf">
http://www.ogf.org/documents/GFD.206.pdf
</eref>. 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.
</t>
<t hangText="Fiber Maps (multiple carriers)"><vspace blankLines="0" />TBD.</t>
<t hangText="HPC - cluster placement problem"><vspace blankLines="0"/>TBD.
</t>
</list>
</t>
</section>
</section>
<section title="Requirements">
<t>Formal requirements to come...</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section title="ALTO Topology Framework">
<t>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.
</t>
<section title="Abstract Topology Representation">
<t>References <xref target="I-D.lee-alto-app-net-info-exchange"/>
and <xref target="I-D.yang-alto-topology"/> provide tentative models
and encodings for abstract topology representation.</t>
</section>
<section title="Sources of Raw Topology Information">
<t>From management systems, to proprietary interfaces to routing systems, to i2rs...</t>
</section>
<section title="Service/Client Specific Topology Abstraction">
<t>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 <xref target="I-D.lee-alto-app-net-info-exchange"/>
and <xref target="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 <eref target="http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf"/>.
</t>
</section>
<section title="Reservation System Compatibility">
<t>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.</t>
<t>At the IETF we have seem similar requirements for compatibility between
GMPLS routing and signaling systems, particularly via the concept of
loose routes.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Hopefully we'll have lots of interested folks commenting and we'll give them credit here.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section and this will as we flesh it out.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<reference anchor="min_ref">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.lee-alto-app-net-info-exchange'>
<front>
<title>ALTO Extensions to Support Application and Network Resource Information Exchange for High
Bandwidth Applications
</title>
<author initials='Y' surname='Lee' fullname='Young Lee'>
<organization/>
</author>
<author initials='D' surname='Dhody' fullname='Dhruv Dhody'>
<organization/>
</author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
<organization/>
</author>
<author initials='G' surname='Bernstein' fullname='Greg Bernstein'>
<organization/>
</author>
<author initials='T' surname='Choi' fullname='Taesang Choi'>
<organization/>
</author>
<date month='October' day='17' year='2013'/>
<abstract>
<t>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.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-lee-alto-app-net-info-exchange-03'/>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-lee-alto-app-net-info-exchange-03.txt'/>
</reference>
<reference anchor='I-D.bernstein-alto-large-bandwidth-cases'>
<front>
<title>Use Cases for High Bandwidth Query and Control of Core Networks</title>
<author initials='G' surname='Bernstein' fullname='Greg Bernstein'>
<organization/>
</author>
<author initials='Y' surname='Lee' fullname='Young Lee'>
<organization/>
</author>
<date month='June' day='28' year='2011'/>
<abstract>
<t>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.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-bernstein-alto-large-bandwidth-cases-00'/>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bernstein-alto-large-bandwidth-cases-00.txt'/>
</reference>
<reference anchor='I-D.yang-alto-topology'>
<front>
<title>ALTO Topology Considerations</title>
<author initials='Y' surname='Yang' fullname='Yang Yang'>
<organization/>
</author>
<date month='July' day='15' year='2013'/>
<abstract>
<t>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.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-yang-alto-topology-00'/>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-yang-alto-topology-00.txt'/>
</reference>
<reference anchor='RFC3945'>
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS) Architecture</title>
<author initials='E.' surname='Mannie' fullname='E. Mannie'>
<organization /></author>
<date year='2004' month='October' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='3945' />
<format type='TXT' octets='166700' target='http://www.rfc-editor.org/rfc/rfc3945.txt' />
</reference>
<reference anchor='RFC4202'>
<front>
<title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
<author initials='K.' surname='Kompella' fullname='K. Kompella'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<date year='2005' month='October' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='4202' />
<format type='TXT' octets='57333' target='http://www.rfc-editor.org/rfc/rfc4202.txt' />
</reference>
<reference anchor='OptControl'>
<front>
<title>Optical Network Control</title>
<author initials='G. M.' surname='Bernstein' fullname='Greg M. Bernstein'>
<organization></organization>
</author>
<author initials='B.' surname='Rajagopalan' fullname='Bala Rajagopalan'>
<organization></organization>
</author>
<author initials='D.' surname='Saha' fullname='Debanjan Saha'>
<organization></organization>
</author>
<date year='2004'/>
</front>
</reference>
<reference anchor='I-D.ietf-alto-protocol'>
<front>
<title>ALTO Protocol</title>
<author initials='R' surname='Alimi' fullname='Richard Alimi'>
<organization />
</author>
<author initials='R' surname='Penno' fullname='Reinaldo Penno'>
<organization />
</author>
<author initials='Y' surname='Yang' fullname='Yang Yang'>
<organization />
</author>
<date month='October' day='2' year='2013' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-alto-protocol-20' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-20.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:43 |