[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/