ALTO WG G. Bernstein, Ed. Internet-Draft Grotto - IETF Datatracker

278 Pages·2016·0.37 MB·English

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: [phone]
Email: [email protected]
Y. Richard Yang (editor)
Yale University
51 Prospect St
New Haven, CT
USA
Email: [email protected]
Young Lee (editor)
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Phone: [phone]
Email: [email protected]
Bernstein, et al. Expires April 24, 2014 [Page 7]
Internet Engineering Task Force Q. Fu, Ed.
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: April 22, 2014 H. Song
Huawei
October 19, 2013
What’s the Impact of Virtualization to ALTO?
draft-fu-alto-nfv-usecase-00
Abstract
This draft presents a use case of Application Layer Traffic
Optimization (ALTO) with the emergence of Network Function
Virtualization (NFV). 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 emerging Network Functions
Virtualisation (NFV), as currently being in progress in ETSI NFV,
leverages standard IT virtualisation technology to consolidate many
network equipment types onto industry standard high volume servers,
switches and storage.
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 22, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fu, et al. Expires April 22, 2014 [Page 1]
Internet-Draft VNF-ALTO 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Impact of Virtualized Endpoints . . . . . . . . . . . . . . . 4
4. ALTO usecase with NFV . . . . . . . . . . . . . . . . . . . . 6
5. Interaction Architecture of ALTO and NFV . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This draft present a use case of Application Layer Traffic
Optimization (ALTO) with the emergence of Network Function
Virtualization (NFV). 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. Typical deployment scenarios of
ALTO include P2P and CDN, in which P2P tracker or CDN request router
queries ALTO server for network map and cost map, in order to make
decisions on which peer to select for content sharing.
The emerging Network Functions Virtualisation (NFV), as currently
being in progress in ETSI NFV, leverages standard IT virtualisation
technology to consolidate many network equipment types onto industry
standard high volume servers, switches and storage. The NFV
architecture in ETSI ongoing work includes an NFV Management and
Orchestrator (M&O), the VNF(Virtualized Network Function) and the
VNFI(Virtualized Network Function Infrastructure), as is shown in
Figure 1. The NFV M&O is responsible for creating and managing the
VNFs on the VNFI. Interactions between NFV M&O, VNF and VNFI are
beyond scope of this draft.
With the trend of various network functions being virtualized, there
will be impacts on cost and network characteristics of the service
endpoints. Under the ALTO architecture, we analyze the problems and
the necessity of extending the ALTO protocols to faithfully reveal
Fu, et al. Expires April 22, 2014 [Page 2]
Internet-Draft VNF-ALTO October 2013
the network to the clients. The central problem this draft would
like to investigate is: what’s the impact of virtualization to ALTO.
+-----------+
| NFV M&O |
+-----+-----+
|
|
+----------+-----------+
| |
| |
+----+----+ +-----+-----+
| VNF |-----------| VNFI |
+---------+ +-----------+
Figure 1: NFV Architecture in Brief
This draft analyzes the impacts of virtualized endpoints to
application layer traffic optimization and presents a usecase of ALTO
in CDN and P2P network with the peers as a VNF(Virtualized Network
Function). .
2. Terminology
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 [RFC2119].
We use the following terms defined in [RFC5693]. Application, Peer,
ALTO service, ALTO server, ALTO client, ALTO query, ALTO Reply.
And the following terms used in this document have their definitions
from the NFV end to end architecture [NFVE2E].
NFV: network function virtualization. NFV technology uses the
commodity servers to replace the dedicated hardware boxes for the
network functions, for example, home gateway, enterprise access
router, carrier grade NAT and etc. So as to improve the re-
usability, allow more vendors into the market, and reduce time to
market. NFV architecture includes a NFV controller (orchestrator) to
manage the virtual network functions and the infrastructure
resources.
NF: A functional building block within an operator’s network
infrastructure, which has well-defined external interfaces and a
well-defined functional behavior. Note that the totality of all
network functions constitutes the entire network and services
infrastructure of an operator/service provider. In practical terms,
Fu, et al. Expires April 22, 2014 [Page 3]