IETF Ping Pan
Internet Draft (Infinera)
Lyndon Ong
(Ciena)
Expires: January 9, 2012 October 17, 2011
Software-Defined Network (SDN) Use Case for
Bandwidth on Demand Applications
draft-pan-sdn-bod-problem-statement-and-use-case-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Pan et.al Expires January 3, 2012 [Page 1]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
other groups may also distribute working documents as Internet-
Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 3, 2012.
Copyright Notice
Copyright (c) 2011 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.
Abstract
Service providers and enterprises are increasingly offering services
and applications from data centers. Subsequently, data centers
originate significant amount of network traffic. Without proper
network provisioning, user applications and services are subject to
congestion and delay.
In this document, we argue the necessity in providing network
information to the applications, and thereby enabling the
applications to directly provision network edge devices and relevant
applications.
Table of Contents
1. Introduction...................................................3
Pan et.al Expires January 3, 2012 [Page 2]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
2. Related Work...................................................3
3. Problem Definition.............................................4
4. The Role of SDN Layer..........................................6
5. Use Cases......................................................7
5.1. Scheduled/Dynamic bandwidth service.......................7
5.2. Multi-Layer BoD Support...................................9
5.3. Virtualized Network service..............................11
6. Security Consideration........................................11
7. IANA Considerations...........................................11
8. Normative References..........................................11
9. Acknowledgments...............................................12
1. Introduction
Bandwidth on Demand services are offered by network operators in
industry and research sectors to support the needs of selected
customers needing high point-to-point bandwidth connections.
Such services take advantage of dynamic control of the underlying
network to set up forwarding and resource allocation as requested by
the customer. Some control is given directly to the customer
via a portal so that there is no need to go through an intermediate
stage of service order provisioning on the part of the network operator.
Currently such services are often based on management interfaces to
vendor equipment that are vendor-specific, and as a result the
operator must redesign its supporting control application for each
vendor domain, or limit their offering to a single vendor domain.
In this document, we propose that providing a common interface to
networks of different vendors and technologies would enable the
network provider to offer Bandwidth on Demand services that are more
widely deployable, less complex to develop and capable of offering
more sophisticated features, using additional network information.
Here are some of the conventions used in this document. 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].
3. Related Work
There has been much work in this area in recent years.
Pan et.al Expires January 3, 2012 [Page 3]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
OpenFlow has defined an architecture for offering virtualized
network control through a centralized controller and proxies
called FlowVisors. These allow users to configure forwarding
of packets within slices of the network partitioned off for
their use. The controller is designed to control each network
element directly through a dedicated control interface. It is
not designed to work with existing control plane protocols.
More generally, TMF has developed models and interfaces for
operations and administration of networks through the north-
bound interface provided by the element management system.
These interfaces are not intended for real-time control of
the network element and need to take into account variations
in the design and features of different types of equipment.
PCE is a client-server protocol that operates in MPLS networks that
enables the network operators to compute and potentially provision
optimal point-to-point and point-to-multipoint connections. However,
PCE does not interface with applications to optimize traffic from
user applications.
4. Problem Definition
Figure 1 illustrates the relationship between application and
network today, where customer control of bandwidth on demand
is provided through applications created by the network
operator supporting the user interface, features and backend
accounting for the service. Such applications are used in
single domain deployments and have limited visibility of
underlying networks and resource availability.
+-------------+ +-------------+
| Application | | Application |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
+------------------+ +------------------+
| Network | | Network |
| Domain #1 | | Domain #2 |
+------------------+ +------------------+
Figure 1: Application to network relationship today
Pan et.al Expires January 3, 2012 [Page 5]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
This presents a number of challenges and problems. Without a
standard interface to the network domain and its control plane,
each bandwidth on demand supporting application must
be built for a specific set of vendor equipment and is not
easily generalizable to different vendors or even different
equipment offered by a single vendor. While signaling interfaces
such as the UNI could offer standardized access to network control,
such interfaces have not been adopted because they provide
minimal security and functionality and are designed for more
of a peer relationship between network elements.
Similarly, bandwidth on demand applications must be designed for
a single technology, which restricts the range of use and potential
users. If Domain #1 uses SDH, for example, and Domain #2 uses OTN
it may be necessary to design supporting Application #2 from scratch
even though Application #1 has been successfully offering service.
Ideally the interface should allow some level of technology
independence, as well as potentially integration of control of
multiple layers (esp. packet and circuit).
Third, the application is generally limited to simple services
connecting a source to destination, because interfaces
hide network topology and do not allow visualization of
the topology for different customer views. For some services
users may wish to exercise control over path routing aspects
such as shared risk, or inclusion or exclusion of areas for
policy reasons.
Pan et.al Expires January 3, 2012 [Page 6]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
5. The Role of an SDN Layer
To solve the above problem, the proposal is to introduce a
software-driven network (SDN) layer (as shown in Figure 2), that is
responsible for network virtualization, programmability and
monitoring, between supporting applications and the network.
+-------------+ +-------------+ +-------------+
| Application | | Application | | Application |
| #1 | | #2 | | #3 |
+-------------+ +-------------+ +-------------+
| | |
| | |
+---------------------------------------------------+
| SDN Layer |
| (Network virtualization, programmability |
| and Monitoring) |
+---------------------------------------------------+
| |
| |
+------------------+ +------------------+
| Physical Network | | Physical Network |
| Domain #1 | | Domain #2 |
+------------------+ +------------------+
Figure 2: Application to network relationship for SDN
The purpose of the SDN Layer is to enable the applications
supporting bandwidth on demand services to access information
about and control traffic flows at the network layer through
a standard, secure and customizable interface. Applications can
visualize the traffic flows at the network layer, and manage the
mapping or binding between user traffic flows to the network
connections from the edge of the networks.
The implementation of an SDN Layer involves interfacing among
different types of applications and different types of network domains,
based on technology or vendor, administrative or policy control.
Standardized interfaces must be defined to support this.
Pan et.al Expires January 3, 2012 [Page 7]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
For the architecture to be useful for existing technologies as
well as new, it should be capable of interworking with existing
forms of network control plane as well as potential new control
structures for networks, such as OpenFlow. The focus should be
on providing richer access to network resources as opposed to
redesigning network control itself.
5. Use Cases
5.1. Scheduled/ Dynamic Bandwidth On-Demand Service
Figure 3 illustrates flow in a scheduled or dynamic bandwidth service.
In the simplest case, connectivity may already be provided between
user-specified endpoints, however the bandwidth allocated between
endpoints can be varied within some overall limit based on predefined
schedule or on spontaneous customer request.
In more sophisticated services, the customer may be allowed to
create new connections within a specified set of endpoints and delete
such connections when the connectivity is no longer required.
User
Req's +------------+
-------->| Controller |
+------------+
|
| <----- North-bound protocol to adjust connections
|
\|/
+---------+ +--------+
| PE1 | | PE2 |
| |===== Provisioned Connection ===>| |
+---------+ +--------+
Figure 3: Scheduled/Dynamic BoD Service
Pan et.al Expires January 3, 2012 [Page 8]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
5.2. Multi-Layer BoD Support
User
Req's +------------+
-------->| Controller |
+------------+
|
| <----- North-bound protocol to map packets to circuits
|
\|/
+--------------------+ +--------------------+
Pkt | PE1 | Transport | PE2 | Pkt
====>| Classifer<->Tunnel |<=== Circuit ===>| Classifer<->Tunnel |====>
+--------------------+ +--------------------+
Figure 4: Multi-Layer BoD service
Figure 4 illustrates a BoD service that supports multi-layer
network control. This extends allows the network operator's
supporting applications to control mapping of end user packet
flows onto an underlying circuit-based transport network to
support high speed bandwidth on demand service. Different
transport network technologies may be used to provide the
server layer transport functions so that the application
can evolve easily with new transport technologies.
5.3. Virtualized Network Service
User
Req's +------------+
-------->| Controller |
+------------+
/|\ |
Topology --->| | <----- North-bound protocol to adjust connections
Gathering | |
| \|/
+---------+ +--------+
| PE1 | | PE2 |
| |===== Provisioned Connection ===>| |
+---------+ +--------+
Figure 5: Virtualized network service
Figure 5 illustrates flow in a virtualized network service that offers
some degree of topology visibility and control in addition to the
features of scheduled or dynamic BoD. For some customers it may
be desirable to provide tailored visibility into the topology of
the resources they control, in order for the customer to put into
effect their own routing of traffic within their dedicated domain.
Pan et.al Expires January 3, 2012 [Page 9]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
At this time such visibility is not possible to provide, as protocols
provide either no visibility into topology or full visibility into
topology. For security reasons it is likely that a supporting
network operator will want to limit visibility and control to some
virtualized topology.
Pan et.al Expires January 3, 2012 [Page 10]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
6. Security Considerations
7. IANA Considerations
This document has no actions for IANA.
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
Pan et.al Expires January 3, 2012 [Page 11]
Internet-Draft SDN BoD Problem and Use Cases October 3, 2011
10. Acknowledgments
This work is based on the conversation with many people, including
Thomas Nadeau, Shane Amante and Benson Schliesser.
Authors Addresses
Ping Pan
Email: ppan@infinera.com
Lyndon Ong
Email: lyong@ciena.com
Pan et.al Expires January 3, 2012 [Page 12]