Internet DRAFT - draft-huang-appsawg-aipi-ps-uc
draft-huang-appsawg-aipi-ps-uc
INTERNET-DRAFT R. Huang
Intended Status: Informational H.Song
Expires: April 16, 2015 Huawei
October 13, 2014
Problem Statement and Use Cases for Application Intelligent
Policy Interface (AIPI)
draft-huang-appsawg-aipi-ps-uc-00
Abstract
This document discusses the problem statement and use cases of an
interface named Application Intelligent Policy Interface (AIPI) that
translates the real application requirements (e.g., network should
ensure how many users of the OTT provider watch high definition video
simultaneously.) into network level requirements, e.g.,
configurations or service deployments requirements and network QoS
requirements, are useful and necessary for modern networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Huang Expires April 16, 2015 [Page 1]
INTERNET DRAFT A Framework of SIB for SIB October 13, 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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Gap Between Application Requirements and Network . . . . . . 4
3.2 Difficulty for Network adaptation . . . . . . . . . . . . . 4
3.3 Difficulty for Network Policies Maintenance . . . . . . . . 5
4. Use Cases for Application Intelligent Policy Interface . . . . 5
4.1 OTT Service Deployment . . . . . . . . . . . . . . . . . . . 5
4.2 Enterprise Service Isolation and Interconnection . . . . . . 6
4.3 Automatic Adaptation . . . . . . . . . . . . . . . . . . . . 6
5 Existing Work . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . 7
9.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Huang Expires April 16, 2015 [Page 2]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
1 Introduction
With the rapid development of network technologies, the network is
more and more open. Many new technologies, e.g., SDN and NFV, etc.,
are emerging to help OTT application providers to get control of the
network more flexibly than before. So far, these technologies are all
network oriented, which based on network elements, ports, links,
protocols or virtualization of the above. For those OTT application
developers with little knowledge of network or small enterprise, they
may not be able to fully utilize the network resources or correctly
set network services to meet their requirements from the services and
applications they provide.
This document further argues that an interface that translates the
real application requirements (e.g., network should ensure how many
users of the OTT provider watch high definition video
simultaneously.) into network level requirements, e.g.,
configurations or service deployments requirements and network QoS
requirements, are useful and necessary for modern networks. How the
interface looks like is an issue outside the scope of the present
document. The remainder of this document develops this idea into
detail: Section 2 provides terminology; Section 3 discusses the
problem statements; Section 4 provides some use cases in which the
interface could be used, and Section 5 analyses the current related
IETF work.
2 Terminology
AIPI: Application Intelligent Policy Interface, which is used for
translating the application requirements to network level
requirements.
Software-Defined Networking (SDN): A framework that supports the
separation of Control and Forwarding Planes via standardized
interfaces.
Network Functions Virtualization (NFV): A network architecture
concept that proposes using IT virtualization related technologies to
virtualize entire classes of network node functions into building
blocks that may be connected, or chained, together to create
communication services.
Network Policy: network level policies that can be directly used to
configure the network elements
Application Intelligent Policy: Application oriented policies that
reflect the QoS of the application service, but cannot be directly
configured to network elements
Huang Expires April 16, 2015 [Page 3]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
3. Problem Statement
3.1 Gap Between Application Requirements and Network
Traditional network and applications effectively treat each other as
black boxes. Network is effectively isolated from the end-systems,
which then have little control over how the network handles packets.
Likewise, the network has limited visibility on the application
logic.
With the increasingly demanding of network opening, technologies like
SDN and NFV becomes the future trends of network development. A key
objective of this open network is to facilitate and exploit the
virtualization of network functions so that they can be provided on a
programmable basis for applications and service innovators. It seems
to be a good way for OTT or enterprise applications to have some
insight into network infrastructure. However, applications may focus
more on service logic, service implementation, performance and
experience, in stead of network information. Deep network
capabilities exposed by the programmable network will be impossible
for non-network-owning players to replicate.
Moreover, many different sets of network interfaces for applications
are emerging. They provide network functions like path computation,
loop avoidance, routing, security and many other tasks through
abstracting and normalizing the quirks and eccentricities of
different data plane devices. However, these interfaces are all
network oriented. OTT applications may not adequately use these
interfaces to fulfill their own requirement as they have no idea how
their service running in the network really works. For example, OTT
applications may not know which one is the most suitable path to
choose. Also, there is no common consensus about how those parameters
of network (e.g., bandwidth, delay, jitter, etc.) affect the QoE of
OTT applications.
3.2 Difficulty for Network adaptation
Most of current interfaces really provides a way for OTT applications
to easily apply for network resources or network functions or certain
QoS (delay, loss, jitter). Due to the gap between OTT applications
requirements and network, OTT applications may abuse these interface
for their goods. For example, OTT applications may request more
bandwidth than that they really need, or they may apply for some
functions that they never use.
There are also some cases that requests from the OTT applications
can't be accepted for network because of extravagant demands, while
there do exist some other ways to fulfill the real requirements of
Huang Expires April 16, 2015 [Page 4]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
OTT applications. Obviously, current interfaces between OTT
applications and network couldn't do network adaptations since
network has no idea what OTT applications really want.
3.3 Difficulty for Network Policies Maintenance
Plenty varieties of requirements for service performance and access
control breed plenty of complicated network configuration or QoS
rules and ACL policies deployments. Usually these configurations and
polices are maintained by network administrators who may not
understand what the corresponding real service requirements are. With
the change of network configuration and policies due to the updates
of service requirements, e.g., new service deployment or old service
expired, the maintenance of the network becomes more and more
difficult especially along with the transfer of network
administrators.
4. Use Cases for Application Intelligent Policy Interface
If network has an interface enabling OTT applications to input their
own application service requirements and has the ability to translate
the application service requirements to network requirement, problems
will be solved. AIPI (application intelligent policy interface) is
dedicated to cope with such problems. In this document, we mainly
discuss several use cases that AIPI which is application friend could
be applied.
4.1 OTT Service Deployment
OTT service providers can benefit from using such an application
oriented interface so that they don't have to care about the underlay
network details of no matter physical or virtual devices and
functions. Instead, they just need to focus on what they are good at,
which are their applications and services for end users.
Suppose an OTT video provider wants to activate the service which
ensure 1000 end user to watch its high definition live video content
simultaneously. Traditional way is to request some specific bandwidth
resources or CDN services or VPN from ISPs. These kind of requests
are usually exaggerated which may result in wasting of resources.
When using AIPI, the OTT provider only needs to provide inputs from
its perspective. For example, the OTT provider indicate that the
video is 720p, and it's a live http streaming, and he wants his end
users could watch fluently and the QoE should be excellent. Then ISP
will analyse the requirements from the OTT provider, and translate
them into network QoS, e.g., bandwidth >5120kpbs, RTT<120ms,
jitter<50ms and loss<1%.
Huang Expires April 16, 2015 [Page 5]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
When OTT providers have same service deployments in different
networks, they can also benefit by using AIPI. Same request can be
transmitted by AIPI to different ISP networks instead of figuring
out what network resources they need in each different network.
4.2 Enterprise Service Isolation and Interconnection
Enterprise networks are growing in complexity and size with
globalization, outsourcing, and wireless expanding the reach of the
network beyond its traditional design parameters. IT departments are
tasked with ensuring the applications and services run well across
both private and public networks. Add to that ongoing application and
data center projects such as virtualization and cloud computing all
the components that make up that network becomes even more of a
challenge. Especially with the frequent personnel transfer of
functions, locations or departments, IT departments are facing a huge
workload.
AIPI is a way to make IT departments work more efficiently and
effectively. Using AIPI, the administrators of IT departments just
need to maintain the requirements from their enterprise and leave the
automatic configurations and deployments to network service
providers, which hence largely reduces the OPEX of IT departments.
4.3 Automatic Adaptation
AIPI is also helpful for network providers to achieve automatic
adaptation for OTT service providers. With AIPI, network providers
who know network the best will learn the real requirements from OTT
service providers, and they certainly have the ability to figure out
how to satisfy these requirements with minimum resources and maximum
efficiency.
The advantage is also reflected when network problems affecting OTT
service SLAs happen. For example, when a node on the specific OTT
service path is experiencing congestions, network provider could just
choose another path which satisfies the requirements for this OTT
service without any communication with this OTT provider.
5 Existing Work
There are some existing efforts in IETF that may be related to this
work. In this section, we give a detailed analysis towards them.
Application Enabled Collaborative Networking (AECON): AECON [AECON]
is trying to work out ways to enable communication of flow
characteristics between applications in end users and the network by
Huang Expires April 16, 2015 [Page 6]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
active information exchange. And the information communicated through
AECON is network oriented.
Shared Unified Policy Automation (SUPA): The main goal of SUPA [SUPA]
is to provide a way for network management applications and for
network services to specify share application based policies to the
network infrastructure using a simplified view of the network. SUPA
is also a network oriented interface and does not really concern OTT
applications.
Interface to the Routing System (I2RS): I2RS [I2RS] facilitates real-
time or event driven interaction with the routing system through a
collection of protocol-based control or management interfaces which
allow information, policy and operational parameters to be injected
into or retrieved from the routing system of network. It is network
oriented as it collects and injects network information.
Application-Layer Traffic Optimization (ALTO): ALTO [ALTO] is
considered as a solution to expose abstract topologies and costs to
applications in P2P domain, datacenter networks and content
distribution networks (CDN). It is also network oriented rather than
application oriented.
AIPI tries to specify an application oriented interface which conveys
the real application requirements to network and facilitates the
translation from real application requirements to network
requirements. AIPI is about the communication between Application
deployment servers and network. AIPI could further use SUPA to
configure or adjust network.
6 IANA Considerations
This draft includes no request to IANA.
7 Security Considerations
TBD.
8 Acknowledgments
The authors would like to thank Hanyu Wei for giving valuable
comments and suggestions.
9 References
9.1 Normative References
[SUPA] IETF SUPA (Shared Unified Policy Automation) BoF Charter,
Huang Expires April 16, 2015 [Page 7]
INTERNET DRAFT A Framework of SIB for SIB October 13, 2014
https://github.com/liushucheng/SUPA/wiki/SUPA-Charter
[AECON] IETF AECON (Application Enabled Collaborative Networking)
barBoF,
http://trac.tools.ietf.org/bof/trac/wiki/BofIETF90#
[I2RS] IETF I2RS (Interface to the Routing System) WG Charter,
http://datatracker.ietf.org/wg/i2rs/charter/
[ALTO] IETF ALOT (Application-Layer Traffic Optimization),
http://datatracker.ietf.org/wg/alto/charter/
9.2 Informative References
[NFV] http://en.wikipedia.org/wiki/Network_Functions_Virtualization
[SDN] http://tools.ietf.org/html/draft-haleplidis-sdnrg-layer-
terminology-06
Authors' Addresses
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
EMail: rachel.huang@huawei.com
Haibin Song
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
EMail: songhaibin@huawei.com
Huang Expires April 16, 2015 [Page 8]
