Network Working Group Y. Lee (Huawei)
G. Bernstein (Grotto)
S. Hares (Huawei)
Internet Draft F. Xia (Huawei)
K. Shiomoto (NTT)
Oscar Gonzalez de Dios (Telefonica)
N. So (Verizon)
Intended status: Informational
Expires: July 2011
January 3, 2011
Problem Statement for Cross-Layer Optimization
draft-lee-cross-layer-optimization-problem-02.txt
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/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 February 3, 2011.
Copyright Notice
Lee, et al. Expires July 3, 2011 [Page 1]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
Copyright (c) 2010 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
Due to the lack of layer interaction between networked applications
and the network during service provisioning, many end user
applications and services cannot efficiently utilize the network
capabilities, nor can achieve the desired quality of service
objectives.
This document describes the general problem of cross layer
optimization. Cross-layer optimization (CLO) involves the overall
optimization of application layer and network resources by providing
an interface for interactions and exchanges between the two layers.
The potential gains of cross layer optimization are illustrated via
examples from content delivery systems, video on demand systems, and
grid computing.
Table of Contents
1. Introduction........................................ 3
1.1. Multi-domain, Multi-technology deployments............ 3
1.2. Short Statement of Problem......................... 4
1.3. Document Plan.................................... 4
2. Terms and Profiles.................................... 5
2.1. Terminology..................................... 5
2.2. Application Resource Categories..................... 5
2.3. Application Service Profiles ....................... 6
2.4. Network Capabilities categories..................... 7
2.5. Network Profile Information........................ 7
3. Network Application Examples ........................... 8
3.1. File Distribution Systems and Internet Content......... 9
3.1.1. Cache and Mirror placement problems ............. 9
3.1.2. Efficient Transfer of content to servers ........ 10
3.1.3. Client to server assignment problem ............ 10
3.2. Streaming Content Distribution Systems.............. 11
3.2.1. Live Streaming Issues........................ 11
3.2.2. On-Demand Streaming Issues.................... 11
3.3. Conferencing and Gaming .......................... 12
3.4. Grid Computing.................................. 12
Lee Expires July 3, 2011 [Page 2]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
4. Problem Statement ................................... 13
4.1. Synchronized Reception of Multiple Real-Time Topology and
Traffic Engineering Related databases................... 13
4.2. Cross-Layer Cooperative Load and Traffic Monitoring Process14
4.3. Cross-Layer Synchronization of Configuration Changes... 15
4.4. Cross-layer Provisioning Process................... 15
5. Existing Solutions................................... 15
5.1. SNMPv3 Access models............................. 16
5.2. Netconf/yang ................................... 16
5.3. MPLS OAM....................................... 17
5.4. ITU........................................... 17
6. Security Considerations............................... 17
7. References......................................... 17
Author's Addresses..................................... 21
Intellectual Property Statement .......................... 21
Disclaimer of Validity.................................. 22
1. Introduction
Application layer services by their very nature utilize application
layer resources, and the underlying network resources. Application
layer services can involve a variety of application layer resources
such as data storage, computation, specialized server capabilities,
and large data sets. However, the provisioning of network
applications typically includes minimal or no information about the
state of underlying network capabilities and resources.
For example if an application client can obtain a desired large data
set (file, video, database, etc...) from a choice of many different
servers, the application service will take into account the current
status and load on the servers but only minimal network
considerations, such as topological proximity, connectivity, ping
latency, rather than current link bandwidth utilization or other
quality of service parameters (e.g., delay and jitter).
1.1. Multi-domain, Multi-technology deployments
Application services may make significant demands on network
resources such as bandwidth and may have a variety of quality of
service requirements. Due to the lack of cross layer interaction
between networked applications and the underlying networks during
service provisioning, many application services make poor use of
network resources or not achieve their overall quality of service
objectives and/or being denied of service provisioning pre-maturely.
As more applications begin to be fielded in "cloud computing"
environments, the applications are being deployed on network
resources across multiple domains on multiple types of network
Lee Expires July 3, 2011 [Page 3]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
hardware. This trend to place more applications in "cloud"
environments is project to grow.
This document describes the general problem of cross layer
optimization. Cross-layer optimization (CLO) involves the overall
optimization of application layer and network resources by providing
an interface for interactions and exchanges between the two layers.
The potential gains of cross layer optimization are illustrated via
examples from content delivery systems, video on demand systems, and
grid computing.
1.2. Short Statement of Problem
The lack of communication interface between the application layer and
the network layer does not allow cross-layer optimization to be
specified atomically and/or simultaneously to allow the following:
a. Coordinated query of application and network requirements to
available computing and network resources;
b. Quick re-optimization based on policy of the application-
network upon failures; and
c. Coordinated cross-layer monitoring and provisioning process
enabled based on synchronized application and network layer
resource availability.
Without linked management (OAM and monitoring) at multiple layers,
the network operation of large applications causes churn at
application layer to network layer.
1.3. Document Plan
The document is organized as follows:
o Terms and Profiles (section 2)
o Network Application Examples (section 3)
o Problem Statements (section 4)
o Existing Solution (section 5)
Lee Expires July 3, 2011 [Page 4]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
2. Terms and Profiles
This section describes the basic terminology associated with cross-
layer optimization, and provides descriptions on application profile,
network capabilities and cross-layer profile information.
2.1. Terminology
Application Layer -- The highest layer in the OSI or TCP/IP protocol
models.
Application Profile -- The characteristics of the application from a
network traffic perspective and the QoS requirements that the
application service will require from the network.
Application Resources -- Non-network resources critical to achieving
the application service functionality. Examples include: caches,
mirrors, application specific servers, content, large data sets, and
computing power.
Application Service -- A networked application offered to a variety
of clients.
Network Layer -- All layers below and including layer 3 in the OSI
protocol model that can contribute to meeting the requirements of an
application service. This includes MPLS and GMPLS controlled
networks.
Network Resources -- Resources of any layer 3 or below such as
bandwidth, connections, links, connection processing (creation,
deletion, and management), and network databases.
2.2. Application Resource Categories
Current and emerging application resources can be grouped into a
number of categories as follows:
o Live data sources -- such as video or audio from live sporting or
entertainment events, data feeds from radio telescopes used in
very long baseline interferometry, large particle physics
experiments such as the LHC, or large chemistry databases.
o Processing Resources -- such as raw computational capability for
cloud computing, transactional capabilities for e-commerce,
transcoding capabilities for video and audio.
Lee Expires July 3, 2011 [Page 5]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
o Storage Resources -- such as disk spaces, tape libraries, online
storage in memory, or in network storage,
o Content/Data Sets -- the actual content of video, audio,
commercial records (accounting, customer bases, employee records),
or scientific data sets).
These application resources may reside, and be stored and distributed
around multiple networks to multiple users and clients. The
geographical scope of a network application can be within a building,
an enterprise, an autonomous system and/or be distributed amongst
multiple autonomous systems.
2.3. Application Service Profiles
An application service profile defines characteristics of the
application from a network perspective and the QoS requirements that
the service will require from the network.
Each application is associated with the sources from which the
application resources originate and the consuming locations (e.g.,
client locations) of the application resources. Application service
profiles can be summarized into the following categories:
o Security Profile: (i) dedicated end-to-end VPN-like resource
allocation; (ii) dedicated physical resource allocation
o Location profile: locations of both the clients and the sources
o QoS profile: (i) Delay Tolerance Bound; (ii) Jitter Tolerance
Bound; (iii) Packet Delivery Ratio Tolerance; (iv) Network
Availability, etc.
o Connectivity profile: (i) P-P; (ii) P-MP; (iii) MP-MP; (iv) Any
cast, etc.
o Directionality profile: (i) uni-directional; (ii) bi-directional
o Bandwidth profile: Maximum, average, and minimum bandwidth
requirements for the connectivity, maximum burst rate, maximum
burst duration, etc.
o Duration of service profile: service time of the application
o Network media profile: (i) optical only; (ii) no microwave, etc.
o Restoration profile: (i) Reroute required; (ii) do not re-route,
etc.
Lee Expires July 3, 2011 [Page 6]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
2.4. Network Capabilities categories
Depending on the application, its nature, and related quality of
service, the underlying network is required to have different
capabilities. For our purposes here, network resources and
capabilities can be summarized into the following categories:
o Bandwidth capabilities --- the ability of the network to meet
bandwidth profile requirements of the application service;
o QoS and SLA -- the ability of the network to deliver according to
the QoS profile requirements and the corresponding service level
agreements (SLA).
o Configurability -- the ability to reconfigure/re-optimize various
aspects of the network and the timeliness in which changes can
occur; and
o Adaptability --- the ability to adapt changes due to changes of
service demand or application/network congestion/failure.
2.5. Network Profile Information
The ability to optimize the utilization of both application layer
resources and network resources while meeting service goals will be
highly dependent on the nature of the application and the properties
of the network.
The network profile information differs from the application service
profile (described in section 2.3). The application service profile
describes the characteristics of lower layers (transport and IP
network) that the application requires. The network profile
information describes the characteristics of the underlying IP
network that is associated with application (IP, MPLS).
The following is a non-exhaustive list of some underlying network
types over which application services are transported and the
information that could be shared to promote cross layer optimization:
1. Raw best effort IP network
a. Location mapping of network resources for clients and
application resources, and
b. Available bandwidth by time of day;
2. Raw best effort IP network with tunable weights:
Lee Expires July 3, 2011 [Page 7]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
In addition to basic network resource related location information as
mentioned above, the following information can be shared between the
layers.
a. Data path with prioritization for traffic (IGP weights to
request for application),
b. Estimated offered load for each of the data paths, and
c. Delay matrix allowable for these data paths;
3. Differentiated Services (Diff-Serve) capable network profiles
a. Filtering linked to PHB profiles for data paths
b. Estimated offered load for each of Diff-serve paths, and
c. Policy on pre-emption of existing paths via Diff-Serv
methodology or OAM;
4. MPLS-TE and/or GMPLS enabled networks:
a. Ingress/Egress filters (QoS and Bandwidth),
b. QoS and bandwidth requirements for the label switched path,
c. Types of reroute/backup mandated, and
d. Policies for inter-domain MPLS-TE linkage.
3. Network Application Examples
Normally, a specification starts with the definition of the problem
and applies it to applications. However, since the application drives
the needs in the network, this discussion starts with the
application.
Application are grouped together in ascending order based in
complexity on its QoS profile requirements and resource optimization.
In the following examples, we'll start with the simpler problems in
file distribution systems. From this point, we'll take up the real-
time needs of streaming content distribution systems (live and on-
demand) and grid computing applications.
Lee Expires July 3, 2011 [Page 8]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
3.1. File Distribution Systems and Internet Content
File distribution systems have been used in the Internet and have
been accelerated by the download of web pages, particularly those
with images. These systems have also expanded to include software,
audio and, video file delivery available via the network. These are
also known as content distribution systems, but we will use the name
file distribution system to emphasize that these are concerned with
the transfer of entire files and are not concerned with streaming
services (covered in the next section).
The applications distributing full files have the fewest network QoS
requirements. Optimization goals of these systems include:
o Reduction of latency to clients,
o Offloading originating server, and
o Conservation of network resources.
File Distribution systems have been set up as overlays on existing
network infrastructures. Commonly encountered optimization problems
with network implications include:
o Cache and Mirror placement problem
o Efficient transfer of content to servers
o Client to server assignment problem
3.1.1. Cache and Mirror placement problems
The cache placement problem is concerned with what content to
allocate to which cache servers based on their proximity to clients
and their loading[Cache].
Mirrors differ from caches in that a client is only directed to a
mirror if it has the desired content [Mirror]. The mirror or server
replica placement problem is concerned with where to place a number
of server given a fixed number of possible sites [Mirror],[Replica].
Depending upon the relationship between the file distribution service
provider and the network provider the cache assignment problem comes
in two flavors,
o a general problem formulation with relatively arbitrary server
placement,
Lee Expires July 3, 2011 [Page 9]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
o and a specific formulation for Transparent En-Route Caches
which are placed along the route from the client to the
originating file server and work transparently from the client
perspective [Cache].
All the processing placement optimizations work with knowledge of
application topology some type of network topological information,
e.g., relative link cost network models. Synchronization of the
application and network (transport and IP) topological information is
key to optimization.
One note - exact network models are not always necessary to achieve
significant performance improvements [Topo].
3.1.2. Efficient Transfer of content to servers
The efficient transport of the original content to the "replication"
servers may be important for optimization when the amount of material
becomes large.
When dealing with a large set of replication servers and a large
amount of data, original content delivery to replication servers
benefits from point-to-multipoint concurrent path optimized for
network loading conditions. To optimize these paths taken, the cross-
layer optimizing process must have visibility into the underlying
network resources.
Synchronized optimization at multiple layers (application, transport
and network) is necessary to create efficient transport of the
original content to the replication servers.
We will revisit this issue in the grid computing applications
section.
3.1.3. Client to server assignment problem
In assignment or selection of a content server for a particular
client one would ideally take into account both current server load
(application layer) and network latency between client and server
[Topo]. In the streaming case bandwidth and QoS shall be taken into
account.
The streaming case increases the need for synchronized multi-layer
monitoring and configuration.
Lee Expires July 3, 2011 [Page 10]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
3.2. Streaming Content Distribution Systems
Steaming services come in two basic flavors, live and on-demand. In
addition many variants in between these two extremes are created when
pause or replay functionality is included in a live streaming
service. Streaming services are different from file download in a
number of ways. First, the commencement of content consumption does
not require an entire file to be downloaded. Second minimum bandwidth
and QoS requirements are needed between the client and the server to
render such services viable. Hence such services have a non-trivial
service profile.
3.2.1. Live Streaming Issues
By "live streaming" here we mean that the client is willing to
receive the stream at its current play out point rather than at some
pre-existing start point. A key network issue for live streaming
services is whether multi-casting takes place at the application or
network level. For example in carrier operated IPTV networks IP
multi-casting is beginning to be used [IPTV]. In the case of an
independent live video distribution service, one may make use of an
overlay network of servers that provide the multi-casting.
Examples of optimization problems for a live streaming service
include:
o Server selection problem (application based multi-cast) or leaf
attachment problem (network based multi-cast)[ServMulti]
o Server placement problem (application based multi-cast) or tree
construction (network based multi-cast).
3.2.2. On-Demand Streaming Issues
On-demand services provide additional technical challenges. Service
providers wish to avoid long start up service delays to retain
customers, while at the same time batch together requests to save on
server costs. A number of additional optimization decisions and
problems typically arise in the on-demand applications in addition to
those seen in live streaming:
o Client stream sharing technique
o Batch or Multicast Server selection problem
The on-demand streaming services problems are similar to those seen
in file distribution. These problems are:(a) data allocation problem
(when and where should we pre-stock video files), (b) on-demand
Lee Expires July 3, 2011 [Page 11]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
server placement problem (where to put and how much capacity), and
(c) efficient (cost effective and timely) transfer of content to
servers.
3.3. Conferencing and Gaming
Conferencing and gaming increase the complexity of the overall
application connectivity, and the need for cross-layer
synchronization of monitoring, configuration, and OAM.
First, the issues associated with streaming discussed in Section 3.2
are also present with conferencing and gaming.
Second, both conferencing and gaming are characterized by bi-
directional connection and asymmetric bandwidth between the server
and the user locations.
Thirdly, the games require connectivity which is multipoint-to-
multipoint with hard QoS constraint on latency. This change in
complexity over the point-to-multipoint scenario of streaming content
distribution brings additional problems as follows:
o Data path formation and reformation for multipoint-to-multipoint
can be very inefficient without considering the underlying network
resources
o QoS constraint on latency and bandwidth guarantee for multipoint-
to-multipoint connectivity require coordination across the layers
in terms of both path estimation and path reservation.
Gaming, in particular massively multi-player online games (MMOGs),
has the connectivity and QoS requirements of conferencing but many
more issues related to the scale of application.
Note that as a part of game play many gamers utilize audio
conferencing services such as Ventrilo [VENT] and hence would
generate well modeled audio conferencing traffic.
Due to scalability concerns [GameServ] and the player desires [MPSel]
server selection can be more complicated than that in the streaming
content distribution case.
3.4. Grid Computing
Grid computing supports extremely large transfers of files and data-
streamed (live or on-demand). This large bandwidth requirement in
volume and time differentiate this application profile.
Lee Expires July 3, 2011 [Page 12]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
The volume of the traffic makes it critical to synchronize changes to
the application and network.
In addition grid computing may have a "streaming" requirement similar
to the streaming content distribution systems but again with
significantly reduced fan-out and sometimes extremely large bandwidth
requirements. For example current estimates of the streaming traffic
produce by one antenna in the proposed Square Kilometer Array (SKA)
[SKA] is approximately 160Gbps with the array consisting of
approximately 3000 antennas.
Key issues associated with grid computing include:
o Instantiation of the connectivity with high data rates and/or data
set size
o Controlling very high speed network
Reference [GFD-122] details a number of grid use cases including
visualization, large data streaming coordinated with job execution,
High Energy Physics file replica management -- this is LHC related --
, health care, distributed manufacturing and maintenance, super
computing, and Very Long Baseline Interferometery (radio astronomy).
In some cases these applications run over shared research networks
such as Internet2 [VLBI].
4. Problem Statement
The previous examples show the problems that occur when resources
allocations for both application and network layers are not
synchronized in their action.
This section elaborates the problem statements for a number of
essential processes associated with cross layer optimization.
4.1. Synchronized Reception of Multiple Real-Time Topology and
Traffic Engineering Related databases
As seen in the previous discussion of the applications, the processes
of server selection and content placement can have dramatically
better outcomes if network topology and application topology are
known at the same time. It is critical to know where the application
clients and servers are, and how they are connected at network
layers.
The ability to capture the data at the same instant allows planning
during rapidly changing events or short bursty flows. For example,
location selection for servers and clients requires that the
Lee Expires July 3, 2011 [Page 13]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
performance estimates about the network and application layer align
for applications that require stringent QoS level with bandwidth
guarantee.
It is necessary that querying information about the routing
information (routes and packets) align with application layer
information. As 90% of traffic [CAIDA] is short flows rather than
long flows, the databases queried without time-based synchronization
will provide an inaccurate representation of the network traffic
flow. This will cause the algorithms trying to select viable multi-
layer network topologies to select the wrong paths.
This "topology" information does not need to be exact, but it needs
to be synchronized across the layers. To aid in calculation, the
reporting nodes at network and application may provide an abstracted
set of data. However, they key point is the data needs to be
synchronized across the layers. Even time based statics (such as
network delay over a time period), must be synchronized to the other
layers load conditions.
Probing techniques, resource proximity or SNMP MIB monitoring
techniques do not provide mechanisms to guarantee synchronization of
the data collection. This higher level of synchronization is
necessary to service: a) application with stringent QoS and
Bandwidth, or to b) better schedule massive quantities of small data
flows.
IETF ALTO WG has been focusing on overlay optimization among peers by
utilizing information about topological proximity and appropriate
geographical locations of the underlay networks. With this method, an
application may optimize selecting peer by location. This location
information may help reduce IP traffic or restrict traffic to going
through a single IP service provider.
The current scope of the Alto work does not address the multi-layer
synchronization problems this document has been discussing. ALTO
servers collect and distribute the information regarding servers
based on resource availability and usage of the underlying networks.
The ALTO work does not provide the mechanisms to synchronize writes
or read/writes within the network.
4.2. Cross-Layer Cooperative Load and Traffic Monitoring Process
Load and traffic monitoring processes can be facilitated using an
interface between Cross layer Optimization (CLO) entity and the
Lee Expires July 3, 2011 [Page 14]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
management entities in the application, transport, and network layer
stacks. The CLO entity can monitor at each layer QoS and loading.
As the above examples have shown, it is important to have a
synchronized read of QoS and loading at each layer. As loads shift or
problems occur, it may be important to adjust the granularity of
these measurements.
Some processes that may need adjustment in granularity are: bandwidth
use, bandwidth allocation/reservation, network delay statistics,
existing client-server relationships, and statistics regarding
allocating clients to servers.
4.3. Cross-Layer Synchronization of Configuration Changes
Re-optimization of cross-layers by network management process
requires synchronized configuration across multiple layers. Without
it, one layer's flows may stray outside the planned network traffic
patterns at other layers.
4.4. Cross-layer Provisioning Process
The cross-layer connections need to be able to provision certain
layers with additional connectivity. For example in MPLS-TE and/or
GMPLS networks, the network CLO entity needs to be able to initiate
connection setup on behalf of the various application entities (such
as clients and servers).
The UNI interface defined for GMPLS networks are currently defined
for network equipment rather than interacting with application layer
services. These UNI interfaces would need to be used to create new
provisioned circuits.
5. Existing Solutions
The problems stated in the previous section cannot be solved with
existing mechanisms in IETF network management using: SNMP,
netconf/yang, MPLS OAM, or ITU Y.2011 or Y.2012. Solutions to these
problems need a fundamental addition to the concepts found in the
SNMP context.
Lee Expires July 3, 2011 [Page 15]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
5.1. SNMPv3 Access models
The SNMPv3 [RFC2265] provides the idea of a SNMP context. This SNMP
context is defined as:
"An SNMP context is a collection of management information
accessible by an SNMP entity. An item of management information
may exist in more than one context. An SNMP entity potentially
has access to many contexts."
This indicates that the SNMPv3 access models may allow multiple
viewpoints on the same data. RFC 2261 states: "four pieces of
information are [necessary to provide access to a piece of
information]:
[*] the snmpEngineID of the SNMP entity which provides access to
the management information at device-X,
[*] the contextName (device-X),
[*] the managed object type ([such as] ifDescr),
[*] and the instance ('1')."
The missing piece is a Context with a management information view
that allows synchronization of actions across multiple layers for
read-view, write-view, notify-view and actions.
While the SNMP context provides the fundamental building blocks, it
is does not provide the necessary context to view multiple layers.
This cross-layer optimization work requires standardization of these
multi-layer, multi-device, multi-as contexts.
5.2. Netconf/yang
Netconf provides an XML based access to SNMP MIB data. These data
uses YANG to define the data model.
The netconf/yang data model still uses the concepts found in the SNMP
Access models of context for viewing data. The same lack of
functionality for synchronization of multi-layer still exists in
netconf/yang data models. These protocol lack synchronization of
layers within a device, across multiple devices within a single
Autonomous System (AS), and across multiple devices across multiple
ASes.
Lee Expires July 3, 2011 [Page 16]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
Note: Since some operations are switching to the netconf with yang
data models, the Cross-Layer access model problem will need to be
solved in the netconf/yang models as well as SNMP.
5.3. MPLS OAM
MPLS OAM is limited to MPLS device. MPLS is regarded as one of the
underlying network transport technologies that could enable cross-
layer optimization with application layer; however, current scope of
MPLS OAM does not support any non-MPLS device for its configuration
and provisioning functions.
5.4. ITU
ITU-T Y.2011 NGN and Y.2111 Resource and Admission Control Functions
(RACF) discuss NGN service stratum separation from NGN transport
stratum. ITU-T Y.2012 defines application network interface (ANI)
which provides a channel for interactions and exchanges between
applications and NGN elements. This interface is similar to the CLO
interface.
Y.2012 however does not address any details on the cross-layer
synchronization.
6. Security Considerations
TBD
7. References
[RFC2261] D. Harrington, et al., "An Architecture for Describing SNMP
Management Frameworks," January, 1998.
[RFC2265] B. Wijnen, et al., "View-based Access Control Model (VACM)
for the Simple Network Management Protocol (SNMP),"
January, 1998.
[Y.2011] General principles and general reference model for Next
Generation Networks, October, 2004.
[Y.2012] Functional Requirements and architecture of the NGN, April,
2010.
[Cache] P. Krishnan, D. Raz, and Y. Shavitt, "The cache location
problem," Networking, IEEE/ACM Transactions on, vol. 8,
2000, pp. 568-582.
Lee Expires July 3, 2011 [Page 17]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
[GameMirror] S.D. Webb, S. Soh, and W. Lau, "Enhanced mirrored
servers for network games," Proceedings of the 6th ACM
SIGCOMM workshop on Network and system support for games,
Melbourne, Australia: ACM, 2007, pp. 117-122.
[GameServ]P. Quax, J. Dierckx, B. Cornelissen, G. Vansichem, and W.
Lamotte, "Dynamic server allocation in a real-life
deployable communications architecture for networked
games," Proceedings of the 7th ACM SIGCOMM Workshop on
Network and System Support for Games, Worcester,
Massachusetts: ACM, 2008, pp. 66-71.
[GameTrf] J. Farber, "Network game traffic modeling," Proceedings of
the 1st workshop on Network and system support for games,
Braunschweig, Germany: ACM, 2002, pp. 53-57.
[GroupGame] K. Vik, C. Griwodz, and P. Halvorsen, "Applicability of
group communication for increased scalability in MMOGs,"
Proceedings of 5th ACM SIGCOMM workshop on Network and
system support for games, Singapore: ACM, 2006, p. 2.
[IPTV] A.A. Mahimkar, Z. Ge, A. Shaikh, J. Wang, J. Yates, Y.
Zhang, and Q. Zhao, "Towards automated performance
diagnosis in a large IPTV network," Proceedings of the ACM
SIGCOMM 2009 conference on Data communication, Barcelona,
Spain: ACM, 2009, pp. 231-242.
[Mirror] E. Cronin, S. Jamin, Cheng Jin, A. Kurc, D. Raz, and Y.
Shavitt, "Constrained mirror placement on the Internet,"
Selected Areas in Communications, IEEE Journal on, vol.
20, 2002, pp. 1369-1382.
[MPSel] S. Gargolinski, C.S. Pierre, and M. Claypool, "Game server
selection for multiple players," Proceedings of 4th ACM
SIGCOMM workshop on Network and system support for games,
Hawthorne, NY: ACM, 2005, pp. 1-6.
[PartState] P.B. Beskow, K. Vik, P. Halvorsen, and C. Griwodz,
"Latency reduction by dynamic core selection and partial
migration of game state," Proceedings of the 7th ACM
SIGCOMM Workshop on Network and System Support for Games,
Worcester, Massachusetts: ACM, 2008, pp. 79-84.
[Replica] Lili Qiu, V. Padmanabhan, and G. Voelker, "On the placement
of Web server replicas," INFOCOM 2001. Twentieth Annual
Joint Conference of the IEEE Computer and Communications
Societies. Proceedings. IEEE, 2001, pp. 1587-1596 vol.3.
Lee Expires July 3, 2011 [Page 18]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
[ServVoD] N. Carlsson and D.L. Eager, "Server selection in large-
scale video-on-demand systems," ACM Trans. Multimedia
Comput. Commun. Appl., vol. 6, 2010, pp. 1-26.
[ServStream]M. Guo, M.H. Ammar, and E.F. Zegura, "Selecting among
replicated batching video-on-demand servers," Proceedings
of the 12th international workshop on Network and operating
systems support for digital audio and video, Miami,
Florida, USA: ACM, 2002, pp. 155-163.
[ServMulti] Zongming Fei, M. Ammar, and E. Zegura, "Multicast server
selection: problems, complexity, and solutions," Selected
Areas in Communications, IEEE Journal on, vol. 20, 2002,
pp. 1399-1413.
[SKA] P.E. Dewdney, P.J. Hall, R.T. Schilizzi, and T.J.L.W. Lazio,
"The Square Kilometre Array," Proceedings of the IEEE,
vol. 97, 2009, pp. 1482-1496.
[Stream] D. Eager, M. Vernon, and J. Zahorjan, "Minimizing bandwidth
requirements for on-demand data delivery," Knowledge and
Data Engineering, IEEE Transactions on, vol. 13, 2001, pp.
742-757.
[Topo] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker,
"Topologically-aware overlay construction and server
selection," INFOCOM 2002. Twenty-First Annual Joint
Conference of the IEEE Computer and Communications
Societies. Proceedings. IEEE, 2002, pp. 1190-1199 vol.3.
[VENT] http://www.ventrilo.com/
[VLBI] http://www.internet2.edu/science/vlbi.html
[WoWHrs] P. Tarng, K. Chen, and P. Huang, "An analysis of WoW
players' game hours," Proceedings of the 7th ACM SIGCOMM
Workshop on Network and System Support for Games,
Worcester, Massachusetts: ACM, 2008, pp. 47-52.
[WoWAct] M. Suznjevic, M. Matijasevic, and O. Dobrijevic, "Action
specific Massive Multiplayer Online Role Playing Games
traffic analysis: case study of World of Warcraft,"
Proceedings of the 7th ACM SIGCOMM Workshop on Network and
System Support for Games, Worcester, Massachusetts: ACM,
2008, pp. 106-107.
Lee Expires July 3, 2011 [Page 19]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
[GFD-122] Tiziana Ferrari (editor), "Grid Network services Use Cases
from the e-Science Community", GFD-I-122, Open Grid Forum,
December 12, 2007.
[CDN2001] B. Krishnamurthy, C. Wills, and Y. Zhang, "On the use and
performance of content distribution networks," Proceedings
of the 1st ACM SIGCOMM Workshop on Internet Measurement,
San Francisco, California, USA: ACM, 2001, pp. 169-182.
Lee Expires July 3, 2011 [Page 20]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
Author's Addresses
Young Lee
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Phone: (972) 509-5599
Email: ylee@huawei.com
Greg M. Bernstein
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Susan Hares
Huawei Technologies
Email : shares@huawei.com
Frank Xia
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Phone: (972) 509-5599
Email: xiayangsong@huawei.com
Kohei Shiomoto
NTT
Email : shiomoto.kohei@lab.ntt.co.jp
Oscar Gonzalez de Dios
Telefonica
Email : ogondio@tid.es
Ning So
Verizon Business
Email: ning.so@verizonbusiness.com
Intellectual Property Statement
Lee Expires July 3, 2011 [Page 21]
Internet-Draft Cross-Layer Optimization (CLO) January 2011
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee Expires July 3, 2011 [Page 22]