Internet DRAFT - draft-liu-aponf-abstract-network-view-use-case
draft-liu-aponf-abstract-network-view-use-case
Network Working Group W. Liu
Internet-Draft T. Tsou
Intended status: Informational Huawei Technologies
Expires: January 4, 2014 G. Karagiannis
University of Twente
J. Saldana
University of Zaragoza
July 4, 2014
APONF Use Case: Using Abstract View of Network by Application
Developers
draft-liu-aponf-abstract-network-view-use-case-00
Abstract
This document describes a use case of Application Policy on Network
Functions (APONF) that presents how service developers can profit by
using an abstract view of the network during the programming and
development process, instead of manipulating individual devices. In
this way one can write software that programs an arbitrary network.
APONF can be used to interface the programmed arbitrary network into
network management policies, i.e., device configuration models.
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 December 30, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires January 4, 2014 [Page 1]
Internet-Draft Abstract Network View APONF Use Case July 2014
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.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. APONF Use Case: Using Abstract View of Network by Application
Developers . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
As the Internet grows, more and more new services keep on
arising, and network traffic is rapidly increased, which may result
in slow performance of network devices (e.g., BRAS) and poor end-user
experience. This also implies that demands and requirements of such
new services on the supporting communication network will increase.
In addition, today's network operators are challenged to create an
abstract view of their network infrastructure and help service
developers on using and programming this abstraction rather than
manipulating individual devices. An abstract view of a network
infrastructure can be realized using a network configuration model,
that provides a declarative configuration and a network topology
model that describes a multi-layer network. Network management
applications are Operational Support System (OSS)-like applications
that help a communication service provider to monitor, control,
analyze and manage a communication network.
Liu, et al. Expires January 4, 2014 [Page 2]
Internet-Draft Abstract Network View APONF Use Case July 2014
Currently, there are no IETF standard mechanisms or modeling
languages that can directly be applied to model the network
configuration nor the network topology. IETF has however created the
IETF SFC WG [SFC] to document a new approach to service delivery and
operation, where one of its goals is to realize an abstract view of a
network by using a service graph instance, denoted as the Service
Function Path (SFP). This will enable the development of suitable
models for network configuration and network topology.
This use case description is based on [Google], and argues that
service developers can profit by using an abstract view of the
network during the programming and development process, instead of
manipulating individual devices. In this way one can write software
that programs an arbitrary network.
Application Policy on Network Functions (APONF) [APONF] can be used
to interface the programmed arbitrary network into network management
policies, i.e., device configuration models.
This document is organized as follows. Section 2 presents the
terminology. Section 3 provides a brief description of this use
case. Section 4 provides the security considerations.
2. Terminology
Device level configuration model: Supports the description of the
network management policies and describes the configuration
details at the device level.
Network Management Application: Operational Support System (OSS)-like
application that help a communication service provider to monitor,
control, analyze and manage a communication network.
Network configuration model: Provides a declarative configuration of
the network.
Network topology model: Describes the topology of a multi-layer
network.
Service Function Chain (SFC): It defines an ordered set of service
functions that must be applied to packets and/or layer-2 frames selected
as a result of classification. The implied order may not be a linear
progression as nodes may copy to more than one branch. The term
"service chain" is often used as shorthand for service function chain.
Service Function Path (SFP): The instantiation of a Service Function
Chain in the network. Packets follow a Service Function Path from
a classifier through the required instances of service functions
in the network.
Liu, et al. Expires January 4, 2014 [Page 3]
Internet-Draft Abstract Network View APONF Use Case July 2014
3. APONF Use Case: Using an Abstract View of the Network by Application
Developers
This section briefly describes the use case that is based on
[Google], which argues that service developers can profit by using
an abstract view of the network during the programming and
development process instead of manipulating individual devices.
Suppose that a network service is developed and maintained as a
network management application. Such network service can enable the
use of end user applications that require a high security,
reliability and QoS levels to users that are located in the football
stadium in Rio during the FIFA soccer World Cup 2014 in Brazil. The
network service, that for the moment we call "secure applications
during football match", is developed using the requirements of the
end user applications and the available information about the
existing communication infrastructure at the particular football
stadium.
The network management application is used to provide the required
configuration and application programming interfaces to an
application developer that can develop the end user
applications using the SFP based network configuration and network
topology information, associated with the "secure applications
during football match" network service. The application developer can
create an application based model associated with this network
service. This application-based model includes the updates of parts
of the abstract view of the network, i.e., SFP based network
configuration and topology associated with the communication network
infrastructure available at the Rio stadium and the necessary
application based demands to be applied on this network configuration
and network topology.
In this context, APONF can be used to map the application-based model
associated with the "secure applications during football
match" network service into specific network management policies,
i.e., device level configuration models.
4. Security Considerations
Security is a key aspect of any protocol that allows state
installation and extracting of detailed configuration states. More
investigation remains to fully define the security requirements, such
as authorization and authentication levels.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
The authors of this draft would like to thank the APONF participants
for their valuable feedback.
Liu, et al. Expires January 4, 2014 [Page 4]
Internet-Draft Abstract Network View APONF Use Case July 2014
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[Google] Google Use Case,
http://www.sdncentral.com/news/google-open-source-help-policy-based-
sdn/2014/06/
[SFC] IETF SFC (Service Function Chaining) WG charter,
http://datatracker.ietf.org/wg/sfc/charter/
[APONF] http://tools.ietf.org/html/draft-zhou-aponf-architecture-01
Authors' Addresses
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: Tina.Tsou.Zouting@huawei.com
Georgios Karagiannis
University of Twente
Email: g.karagiannis@utwente.nl
Jose Saldana
University of Zaragoza
Dpt. IEC Ada Byron Building
Zaragoza 50018
Spain
Phone: +34 976 762 698
Email: jsaldana@unizar.es
Liu, et al. Expires January 4, 2014 [Page 5]
