Internet DRAFT - draft-alto-notification

draft-alto-notification



ALTO                                                           X. Sun
                                                                K. Li
															  K. Zhou
Internet Draft                 							China Telecom
Expires: August 2010                                 February 26, 2010



             Server Notification mechanism for ALTO optimization
                      draft-alto-notification-00.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 August 26, 2010.



Copyright Notice

   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.  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 BSD License.





Sun, et al.            Expires August 26, 2010                [Page 1]

Internet-Draft       Server Notification mechanism        February 2010




Abstract

   Application-Layer Traffic Optimization (ALTO) guides an application,
   especially a Peer to Peer (P2P) application, to select hosts from
   its candidate set. ALTO is a promising technique for future network,
   as it is able to jointly optimize network resource utilization and
   application performance. The ALTO protocol is Client-Server based.
   Applications work as ALTO clients to fetch PID information from the
   ALTO server, but the ALTO server can't send the notification to ALTO
   clients, even if there is a major change to the networks. This draft
   discusses the requirements for server initialized notification, and
   proposes one mechanism to enable the ALTO server notification.

Table of Contents


   1. Introduction ................................................ 2
   2. Problem statement ........................................... 3
   3. Requirement ................................................. 3
   4. Server initiating notification mechanism .................... 3
      4.1. The processing ......................................... 4
      4.2. Message format ......................................... 5
   5. Security Considerations ..................................... 5
   6. IANA Considerations ......................................... 5
   7. References .................................................. 5
   Author's Addresses ............................................. 6

1. Introduction

   Application Layer Traffic Optimization (ALTO) provides a solution
   benefits both Internet Service Provider (ISP) and P2P
   operators/applications. In this solution, P2P applications utilize
   network information provided by ALTO service to optimize its traffic.
   However, the current ALTO mechanism depends on ALTO clients fetching
   network information from the servers, and neglects the requirements
   to proactively dispatching such information. Unfortunately, there
   are some scenarios that rapid dispatching of network information is
   valuable.

   In this draft, one mechanism is proposed to dispatch the newest
   network information from ALTO server to ALTO clients quickly. It
   will let P2P applications know the new network information. The
   performance of peer selection and ISP traffic management will be
   improved.



Sun, et al.            Expires August 26, 2010                [Page 2]

Internet-Draft       Server Notification mechanism        February 2010



   Because traffic generated by tracker indexed P2P applications
   predominates current P2P networks. This draft considers only the
   server notification implementation based on tracker indexed P2P
   applications.



2. Problem statement

   ALTO enhances the traffic optimization capability of ISPs. However,
   networks and the optimization policy of ISPs are changing frequently.
   Current ALTO protocol uses B/S architecture. ALTO server is the
   passive side, and there is only one direction of ALTO message
   process. ALTO clients send query message periodically to ALTO server
   for the network and optimization information. This kind of passive
   mode cannot response quickly to network or ISP's network provision
   policy change.  When a network change occurs, although the ISP
   updates the ALTO server simultaneously, P2P traffic keeps following
   the guidance of the previous ALTO direction, as ALTO clients have no
   knowledge of the change. This will cause a period of pressure to ISP
   network and raises maintenance problems.



3. Requirement

   Whenever the change of network condition leads to the change of
   network map and cost map in ALTO server, the ALTO server SHOULD
   notify the change to ALTO clients as quickly as possible, and need
   not wait for the ALTO query message of next period as illustrated in
   current ALTO protocol.



4. Server initiating notification mechanism


   In this mechanism, ALTO server will maintain one table to record the
   address information about each ALTO client. ALTO server will
   initiate the notification message connection using the address
   information. The address information will be used to identify the
   ALTO client, which can be the IP address/port or the URL of tracker
   which has the ALTO client. In order to improve the ALTO server's
   efficiency, only P2P tracker and application server will be notified
   by ALTO server.



Sun, et al.            Expires August 26, 2010                [Page 3]

Internet-Draft       Server Notification mechanism        February 2010


   One new ALTO message is added in this mechanism, notification
   message. The source of the message is the ALTO server, and the
   destination is the ALTO client which recorded in the table.

   HTTP protocol is used to build notification message. One lightweight
   HTTP server module is needed in ALTO client to receive notification
   message, as well as HTTP client is needed in the ALTO server.





4.1. The processing

   When network condition changes, the ALTO server will refresh its
   network map and cost map according to the related policy. Once the
   update is finished, ALTO server will build the notification message
   and send to the ALTO clients. When ALTO client receives the
   notification message, it will send the ALTO query message
   immediately to get the renewed network/cost map. This ALTO query
   message is the same with the current ALTO protocol. When ALTO client
   receives the notification message, it need not send any response
   message.


    +---------------+     +---------------+    +----------------+
    |P2P Tracker/   |     |               |    |   Network      |
    |ALTO client    |     |ALTO server    |    |   condition    |
    +---------------+     +-------+-------+    +----------------+
            |                     |                     |
            |                     |  Network changing   |
            |                     <---------------------+
            |                     | \\                  |
            |                     |   | Map refresh     |
            | Notification message| //                  |
            <---------------------|-                    |
            |                     |                     |
            |                     |                     |
            |   Query message     |                     |
            +--------------------->                     |
            |                     |                     |
            |                     |                     |
            |   Response message  |                     |
            <---------------------+                     |
            |                     |                     |




Sun, et al.            Expires August 26, 2010                [Page 4]

Internet-Draft       Server Notification mechanism        February 2010


4.2. Message format

   The notification message format is as below.

          Method        : 'POST'
          URI Path      : '/notification'



5. Security Considerations

   High-level security considerations can be found in the [draft-ietf-
   alto-problem-statement].

6. IANA Considerations

   This document does not mandate any immediate IANA actions.

7. References

   [RFC 5693]
             Seedorf, J. and E. Burger, "Application-Layer Traffic
                 Optimization (ALTO) Problem Statement", RFC 5693,
                 October 2009.

   [I-D.ietf-alto-reqs]
                 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
                 Yang, "Application-Layer Traffic Optimization (ALTO)
                 Requirements", draft-ietf-alto-reqs-01 (work in
                 progress),July 2009.

   [I-D.penno-alto-protocol]
                 Penno, R. and Y. Yang, "ALTO Protocol",
                 draft-ietf-alto-protocol-01 (work in progress),
                 July 2009.













Sun, et al.            Expires August 26, 2010                [Page 5]

Internet-Draft       Server Notification mechanism        February 2010


Author's Addresses

   Xianghui Sun
   China Telecom Beijing Research Institute
   No.118, Xizhimenneidajie, xicheng District
   Beijing 100035
   China

   Email: sunxh@ctbri.com.cn

   Kai Li
   China Telecom Beijing Research Institute
   No.118, Xizhimenneidajie, xicheng District
   Beijing 100035
   China

   Email: leekai@ctbri.com.cn
   
   Kaiyu Zhou
   China Telecom Beijing Research Institute
   No.118, Xizhimenneidajie, xicheng District
   Beijing 100035
   China

   Email: zhouky@ctbri.com.cn






























Sun, et al.            Expires August 26, 2010                [Page 6]