Internet DRAFT - draft-alto-caching-subscription

draft-alto-caching-subscription






Internet Engineering Task Force                              S. Madhavan
Internet-Draft                                              R. Nandiraju
Intended status: Informational                       Huawei Technologies
Expires: August 25, 2012                               February 22, 2012


                     ALTO Caching and Subscription
                   draft-alto-caching-subscription-00

Abstract

   The specification of the ALTO protocol uses map based approaches
   assuming that the information provided is static for a longer period
   of time.  But in some cases network operators reallocate IP subnets
   from time to time which in turn changes the mapping partitions[I-
   D.ietf-alto-deployments].  Since the ALTO clients are unaware of the
   map information changes, clients need to query the servers for every
   service request and many such requests are redundant because the
   information was not changed.  The purpose of this memo is to provide
   two mechanisms which will help the ALTO clients to be informed of the
   map information changes. a) ALTO clients cache the map information
   and the servers provide the expiration time for invalidation. b) ALTO
   clients can subscribe for event notifications from the server

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 25, 2012.

Copyright Notice

   Copyright (c) 2012 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



Madhavan & Nandiraju     Expires August 25, 2012                [Page 1]

Internet-Draft                ALTO Caching                 February 2012


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Structure . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overall Operation  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  EndpointAddrGroup  . . . . . . . . . . . . . . . . . . . .  6
     6.2.  NetworkMapData . . . . . . . . . . . . . . . . . . . . . .  6
     6.3.  ContactAddr  . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  ALTO caching and invalidation  . . . . . . . . . . . . . . . .  6
     7.1.  Server behavior  . . . . . . . . . . . . . . . . . . . . .  7
     7.2.  Client behavior  . . . . . . . . . . . . . . . . . . . . .  7
     7.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  7
       7.3.1.  Network Map with Expiry Example  . . . . . . . . . . .  8
       7.3.2.  Filtered Network Map with Expiry Example . . . . . . .  9
   8.  Subscription and Notification Service  . . . . . . . . . . . .  9
     8.1.  Requesting a Subscription  . . . . . . . . . . . . . . . . 10
       8.1.1.  Input Parameters . . . . . . . . . . . . . . . . . . . 10
     8.2.  Refreshing of Subscriptions  . . . . . . . . . . . . . . . 11
     8.3.  Notifier Subscription Handling . . . . . . . . . . . . . . 11
       8.3.1.  Response . . . . . . . . . . . . . . . . . . . . . . . 11
     8.4.  Notifier Notification behavior . . . . . . . . . . . . . . 12
       8.4.1.  Input Parameters . . . . . . . . . . . . . . . . . . . 12
     8.5.  Subscriber Notification handling . . . . . . . . . . . . . 13
     8.6.  Unsubscribing  . . . . . . . . . . . . . . . . . . . . . . 13
     8.7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Detecting support for Subscription Service . . . . . . . . . . 16
     9.1.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Transport Considerations . . . . . . . . . . . . . . . . . . . 18
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     12.1. application/alto-* Media Types . . . . . . . . . . . . . . 18
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     14.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



Madhavan & Nandiraju     Expires August 25, 2012                [Page 2]

Internet-Draft                ALTO Caching                 February 2012


1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates, that are able to provide a desired
   resource [RFC5693].  The requirements for ALTO are itemized in
   I-D.ietf-alto-reqs.  ALTO is realized by a client-server
   protocol.ALTO clients send queries to ALTO servers, in order to
   solicit guidance.

   ALTO clients needs to query the ALTO server for cost map and network
   map information to select one or several hosts from a set of
   candidates.  Network Maps may be stable for a longer time but changes
   whenever the service provider reallocates IP subnets.  [I-D.ietf-
   alto-deployments]

   This memo defines a mechanism for ALTO clients to cache the map
   information and for the servers to provide the expiration time for
   invalidation at subset level or map level.  In addition the ALTO
   clients can subscribe to the ALTO server to be informed of a map
   information change.  The server MAY send only the changed map
   information even if clients subscribe for complete information.


2.  Problem Statement

   The ALTO protocol uses HTTP for discovering available Information
   resources at an ALTO server and retreiving information resources.
   The protocol defines Map-based and Non-map based approaches for
   retreiving information resources.Map-based approaches are chosen as
   they lower the signaling load on the server, as the maps have only to
   be retrieved if they are changed.

   HTTP protocol already defines mechanisms for caching the content.
   There are many limitations in using those mechanisms.  HTTP based
   caches store the responses only for HTTP GET requests.  ALTO queries
   can be GET or POST(in case of filtered map) requests.  In the case of
   POST requests, HTTP caching mechanism cannot be used because
   responses for POST are generally not cached.

   The validity of the information in the map need not be same for all
   the elements in the map and there is currently no mechanism(in HTTP
   also) to convey this information.  This mechanism has to be
   incorporated into the protocol itself.

   ISPs reallocate IPv4 subnets within their infrastructure from time to
   time, partly to ensure the efficient usage of IPv4 addresses.  The
   frequency of these "renumbering events" depend on the growth in



Madhavan & Nandiraju     Expires August 25, 2012                [Page 3]

Internet-Draft                ALTO Caching                 February 2012


   number of subscribers and the availability of address space within
   the ISP.


3.  Protocol Structure

   The ALTO Protocol uses a simple extensible framework to convey
   network information.  In the general framework, the ALTO protocol
   will convey properties on both Network Locations and the paths
   between Network Locations.[I-D.ietf-alto-protocol].

   The Map filtering and endpoint cost services can be extended to
   include the map level and subset level expiration time.  This memo
   also extends the ALTO information services to include the
   subscription and notification service.  Any node can transmit a
   notification through HTTP to any other node for the changes in
   subscribed events.  The framework also provides mechanisms for
   subscriptions to be done for full maps or subset of the maps
   available in the Map service.

   .-------------------------------------------------------------------.
   |                                                                   |
   |.--------..-------------------------------------------------------.|
   ||        || ALTO Info Services                                    ||
   ||        || .-----------. .----------. .----------..-------------.||
   ||        || |    Map    | | Endpoint | | Endpoint || Subscription|||
   ||        || | Filtering | | Property | |   Cost   || and         |||
   ||        || |           | |          | |          || Notification|||
   ||        || |           | |          | |          || Service     |||
   ||        || |  Service  | | Service  | | Service  ||             |||
   || Server || `-----------' `----------' `----------'`-------------'||
   ||  Info. || .-------------------------------------.               ||
   || Service|| |  Map Service                        |               ||
   ||        || |  .-------------.  .--------------.  |               ||
   ||        || |  | Network Map |  |  Cost Map    |  |               ||
   ||        || |  `-------------'  `--------------'  |               ||
   ||        || `-------------------------------------'               ||
   |`--------'`-------------------------------------------------------'|
   |                                                                   |
   `-------------------------------------------------------------------'

                     Figure 1: ALTO Protocol Structure


4.  Overall Operation

   The overall operation is based on the ALTO client caching the map
   information.  The ALTO server sends the map information providing



Madhavan & Nandiraju     Expires August 25, 2012                [Page 4]

Internet-Draft                ALTO Caching                 February 2012


   details of full or subset level expiration.  Clients can subcsribe
   for map information changes.  ALTO server sends notifcations for the
   map information based on the subscription

   ALTO server can choose to use HTTP based caching mechanisms or ALTO
   caching mechanism (defined in this document) based on the request.

   A typical message flow would be:

                 ALTO Client       ALTO Server
                     |-----ALTO Query--->|     ALTO Query for complete map information
                     |<---ALTO Response--|     ALTO Response with caching related information
                     |                   |
Subset level         |------ALTO Query-->|     ALTO Query for expired maps
validity expires     |<-------200--------|     ALTO response
                     |                   |



   The requests and responses are encoded with JSON.  Subscriptions can
   be expired and MUST be refreshed using subscription requests.

                          Figure 2: Message flow


5.  Definitions

   ALTO cache: Any logical entity which caches the ALTO responses for
   the purpose of reducing repeated requests by the alto client to the
   alto server.  The ALTO cache MAY be co-located with the ALTO client
   or it can be a separate node

   Event:Any change in a resource that can trigger a notification

   Subscription:An established relationship in which a resource has
   indicated interest in certain event

   Subscriber:A subscriber is an ALTO node that initiates a subscription
   with a subscription server

   Notification:Notification is the mechanism by which notifier nodes
   sends changed events information to the subsctiber

   Notifier:A notifier is an ALTO node which generates Notification
   messages for the purpose of notifying subscribers of the state of a
   resource.





Madhavan & Nandiraju     Expires August 25, 2012                [Page 5]

Internet-Draft                ALTO Caching                 February 2012


6.  ALTO Types

   This section details the format for particular data values used for
   ALTO caching and the Subscription framework.  Base types defined by
   I-D.ietf-alto-protocol are used by this memo with some extensions
   listed below.

6.1.  EndpointAddrGroup

   EndpointAddrGroup JSON object is extended as below

   object {
        JSONString expires;
        EndpointPrefix [AddressType]<0..*>;
        ...
      } EndpointAddrGroup;

6.2.  NetworkMapData

   NetworkMapData JSON object is extended as below

    object {
        JSONString expires;
        EndpointAddrGroup [pidname]<0..*>;
        ...
      } NetworkMapData;

6.3.  ContactAddr

   The ALTO subscription framework requires the client nodes to provide
   the contact information which includes the transport tuple details so
   that server can send notification.  These connections can be
   persistent or not.

   ContactAddr is defined as:
   object {
        EndpointAddr addr;
        JSONInteger port;
      } ContactAddr;


7.  ALTO caching and invalidation

   ALTO servers specify the expiration time of the complete map or the
   subset level maps in the response.  Expiration time format is an
   absolute date and time with GMT as reference.  ISPs MAY use any
   mechanism to determine the expiration time.  This is out of the scope
   of this specification.



Madhavan & Nandiraju     Expires August 25, 2012                [Page 6]

Internet-Draft                ALTO Caching                 February 2012


7.1.  Server behavior

   ALTO server MAY use HTTP based or ALTO caching mechanism to convey
   the expiration time.  When the request is HTTP GET,then the ALTO
   server MAY use HTTP based caching mechanism.  In the case of request
   being POST, ALTO server SHOULD use ALTO caching mechanism.  To ensure
   consistent behaviour and reduce implementation complexity it is
   recommended that the mechanism defined by this memo is used for all
   caching scenarios.

7.2.  Client behavior

   ALTO cache MUST be able to identify expiration of map level or subset
   level information.  On expiry, cache SHOULD trigger a new request to
   the server to refresh the expiration.

7.3.  Examples


































Madhavan & Nandiraju     Expires August 25, 2012                [Page 7]

Internet-Draft                ALTO Caching                 February 2012


7.3.1.  Network Map with Expiry Example

   GET /networkmap HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-networkmap+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-networkmap+json
   Cache-Control: no-cache

   {
     "meta" : {},
     "data" : {
       "map-vtag" : "1266506139",
       "map" : {
         "expires": "Wed, 14 Sep 2011 16:00:00 GMT",
         "PID1" : {
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/25"
           ]
         },
         "PID2" : {
           "ipv4" : [
             "198.51.100.128/25"
           ]
         },
         "PID3" : {
           "ipv4" : [
             "0.0.0.0/0"
           ],
           "ipv6" : [
             "::/0"
           ]
         }
       }
     }
   }












Madhavan & Nandiraju     Expires August 25, 2012                [Page 8]

Internet-Draft                ALTO Caching                 February 2012


7.3.2.  Filtered Network Map with Expiry Example

   POST /networkmap/filtered HTTP/1.1
   Host: custom.alto.example.com
   Content-Length: [TODO]
   Content-Type: application/alto-networkmapfilter+json
   Accept: application/alto-networkmap+json,application/alto-error+json

   {
     "pids": [ "PID1", "PID2" ]
   }


   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-networkmap+json

   {
     "meta" : {},
     "data" : {
       "map-vtag" : "1266506139",
       "map" : {
         "PID1" : {
           "expires": "Wed, 14 Sep 2011 16:00:00 GMT",
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/24"
           ]
         },
         "PID2" : {
           "expires": "Wed, 14 Dec 2011 16:00:00 GMT",
           "ipv4": [
             "198.51.100.128/24"
           ]
         }
       }
     }
   }


8.  Subscription and Notification Service

   The Subcription service allows ALTO clients to subscribe to events so
   that ALTO server can return full maps or subset of the full maps
   available in the Map service.  On event changes, ALTO server sends
   notifications for the changed events.





Madhavan & Nandiraju     Expires August 25, 2012                [Page 9]

Internet-Draft                ALTO Caching                 February 2012


8.1.  Requesting a Subscription

   When a subscriber wishes to subscribe to a particular state for a
   resource, it forms a HTTP POST message.This POST message will be
   confirmed with a final message, 200 OK message indicating that the
   subscription is accepted and notification message will be sent
   immediately.

   The framework allows entities to subscribe full or subset of full
   maps provided by the Map service.For example ALTO clients can
   subscribe for complete maps like NetworkMap, CostMaps or also for
   subsets like NetworkMapFilter, CostMapFilter or Endpoint services.
   Subscription request MUST carry "eventtype", "expires" value,
   "contactaddr" parameters encoded in the JSON object and sent as
   payload.The "eventtype" indicates what type of events subscription is
   required.The "expires" key indicates the actual duration for which
   the subscription will remain active.

   Subscribers need to provide "contactaddr" in the first subscription
   message which will be used by server nodes to send notification
   messages.

   Non-2xx final response indicates that no subscription is created and
   no notification messages will be sent.

8.1.1.  Input Parameters

   Input parameters are supplied in the entity body of the HTTP POST
   request.  This document specifies the input parameters with a data
   format indicated by a a media type "application/
   alto-subscribeinput+json", which is a JSON object of SubscribeInput:

   object {
        JSONString event-types<0....*>;
        JSONInteger expires;
        ContactAddr [AddressType]<0..*>;
        ReqFilteredNetworkMap networkfiltermap;   [OPTIONAL]
        ReqFilteredCostMap costfiltermap;         [OPTIONAL]
        ReqEndpointProp endpointprop;             [OPTIONAL]
        ReqEndpointCostMap endpointcostmap;       [OPTIONAL]
      } SubscribeInput;

   with members:

   event-types: List of event types for which subcsription needs to be
   done.  This can be "NetworkMap", "CostMap", "NetworkMapFilter",
   "CostMapFilter", "endpointprop", "endpointcost" strings.  NetworkMap
   and CostMap events subscrobes for complete information and rest of



Madhavan & Nandiraju     Expires August 25, 2012               [Page 10]

Internet-Draft                ALTO Caching                 February 2012


   the event types handles subsets.

   expires: The expires value indicates the lifetime of the
   subscription.

   contactaddr: Used by the notifier to contact the subscriber for
   sending notification details.

   All the objects are optional and needs to be added based on the
   eventtype parameter.  Refer I-D.ietf-alto-protocol for
   ReqFilteredNetworkMap, ReqFilteredCostMap, ReqEndpointProp and
   ReqEndpointCostMap JSON object definitions.

8.2.  Refreshing of Subscriptions

   Subscriber can send refresh requests before a subscription expires by
   sending HTTP POST message with the same event and subscrid parameter
   returned in 200 OK message.The subscrid parameter is used to
   differentiate multiple subscriptions from the same node.

   If a request to refresh a subscription receives a "404" response,
   this indicates that the subscription has already been terminated.

8.3.  Notifier Subscription Handling

   The Notifier should check that the event specified is understood.  If
   not, notifier should send "503 Service Unavailable" response to
   indicate that the specified event is not understood.

   If the event is understood, notifier creates a subscription and
   stores the "contactaddr", event-type and expires information.Notifier
   returns a "200 OK" message which indicates that the subscription is
   succesful. 200 OK reponse message contains the "event" information,a
   unique "subscrid" parameter and "expires" value.  The subscrid
   parameter is used to differentiate multiple subscriptions.

8.3.1.  Response

   Input parameters are supplied in the entity body of the 200 OK
   message.  This document specifies the input parameters with a data
   format indicated by a a media type "application/
   alto-subscriptiondata+json".

   object {
        JSONString subscrid;
        JSONInteger expires;
        JSONString event-types<0....*>;
      } SubcriptionData;



Madhavan & Nandiraju     Expires August 25, 2012               [Page 11]

Internet-Draft                ALTO Caching                 February 2012


   with members:

   subscrid: This id is sent by notifier and is used to uniquely
   identify subscription.  Refresh subscriptions and notifications MUST
   carry this id

   event-types: This should be the same received in the subscription
   request

8.4.  Notifier Notification behavior

   Notifier indicates a change in the subscribed state by sending a HTTP
   POST message with resource information, event, "substate" and
   "subscrid" parameter.The resource information can be NetworkMap,
   CostMap, NetworkMapFilter,CostMapFilter or EndPoint Service
   information.  The "substate" refers to the subscription state which
   can be "active" or "terminated".  The "substate" indicates the
   subscription state maintained by the notifier.

   If the value of the "substate" is active, the notifier should include
   an expires value indicating the time remaining for the subscription.

   If the value of the "substate" is terminated, the notifier may
   include a "reason" value.

8.4.1.  Input Parameters

   Input parameters are supplied in the entity body of the HTTP POST
   request.  This document specifies the input parameters with a data
   format indicated by a a media type "application/
   alto-notificationdata+json".

   object {
        JSONString event-type<0....*>;
        JSONString subscrid;
        JSONString substate;
        JSONInteger expires;
        InfoResourceNetworkMap networkmap;               [OPTIONAL]
        InfoResourceCostMap    costmap;                  [OPTIONAL]
        InfoResourceEndpointProperty endpointprop;       [OPTIONAL]
        InfoResourceEndpointCostMap endpointcostmap;     [OPTIONAL]
      } NotifitionData;

   with members:

   substate: Indicates the subscription state maintained by the server

   expires: Indicates the time remaining for the subscription identified



Madhavan & Nandiraju     Expires August 25, 2012               [Page 12]

Internet-Draft                ALTO Caching                 February 2012


   by subscrid

   All the objects are optional and needs to be added based on the
   eventtype parameter.  Refer I-D.ietf-alto-protocol for
   InfoResourceNetworkMap, InfoResourceCostMap,
   InfoResourceEndpointProperty and InfoResourceEndpointCostMap JSON
   object definitions.

8.5.  Subscriber Notification handling

   Subscriber should check the subscrid returned in the notification
   message to check whether this is an outstanding subscription.  If
   not, it MUST return "404 Not Found" response message.

   If the substate is active, it means that the subscription is active
   and hence can check the expires value.  Subscriber can send refresh
   requests if required.

8.6.  Unsubscribing

   Unsubscription is done by sending HTTP POST message with uri as
   example.com/unsubscribe and payload containing the "subscrid" which
   needs to be terminated.

8.7.  Example

   An ALTO node [P2P peer/Tracker] queries the ALTO server and contacts
   the peer for service.  Node caches the data locally and wants to
   subscribe for resource state changes [Filtered Network
   Map].Refreshing of the subscription is done and is terminated later
   using unsubscribe option.In this example, the ALTO Server provides
   subscription, notification and unsubscribe service via a separate
   subdomain, "custom.alto.example.com".

   POST /subscription HTTP/1.1
   Host: custom.alto.example.com
   Content-Length: [TODO]
   Content-Type: alto-subscribeinput+json
   Accept: application/alto-subscriptiondata+json,
           application/alto-error+json

   {
     "event-types": ["NetworkMapFilter"],
     "expires": 3600,
     {
         "ipv4": [
             "addr": "192.0.2.0",
             "port": 5828



Madhavan & Nandiraju     Expires August 25, 2012               [Page 13]

Internet-Draft                ALTO Caching                 February 2012


         ]
     },
     {
         "pids": [ "PID1", "PID2" ]
     }
   }

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-subscriptiondata+json

   {
       "subscrid": "1223subsrandstr",
       "expires" : 3600,
       "event-types": ["NetworkMapFilter"]
   }

   Change in the resource state is notified using notification message.

   POST /notification HTTP/1.1
   Host: custom.alto.example.com
   Content-Length: [TODO]
   Content-Type: application/alto-notificationdata+json
   Accept: application/alto-error+json

   {
       "event-types": ["NetworkMapFilter"],
       "subscrid": "1223subsrandstr",
       "substate": "active",
       "expires": "3600",
       {
        "meta" : {},
        "data" : {
          "map-vtag" : "1266506139",
          "map" : {
            "PID1" : {
              "ipv4" : [
                "192.0.2.0/24",
                "198.51.100.0/25"
              ]
            },
            "PID2" : {
              "ipv4" : [
                "198.51.100.128/25"
              ]
            },
            "PID3" : {
              "ipv4" : [



Madhavan & Nandiraju     Expires August 25, 2012               [Page 14]

Internet-Draft                ALTO Caching                 February 2012


                "0.0.0.0/0"
              ],
              "ipv6" : [
                "::/0"
              ]
            }
          }
        }
      }
   }

   HTTP/1.1 200 OK

   Node refreshes the subscription.

   POST /unsubscribe HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-error+json
   Content-Type: application/alto-subscriptiondata+json

   {
       "subscrid": "1223subsrandstr",
       "expires" : 3600,
       "event-types": ["NetworkMapFilter"]
   }

   HTTP/1.1 200 OK

   Node terminates the subscription

   POST /unsubscribe HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-error+json
   Content-Type: application/alto-subscriptiondata+json

   {
       "subscrid": "1223subsrandstr",
       "expires" : 0,
       "event-types": ["NetworkMapFilter"]
   }

   HTTP/1.1 200 OK









Madhavan & Nandiraju     Expires August 25, 2012               [Page 15]

Internet-Draft                ALTO Caching                 February 2012


9.  Detecting support for Subscription Service

   An Information Resource Directory indicates to ALTO Clients which
   Information Resources are made available by an ALTO Server[I-D.ietf-
   alto-protocol].  The Information Resource Directory defined by
   I-D.ietf-alto-protocol will be extended to add new directory entries
   for Subscription and Unsubscription service.

   The media-types mentions the list of all media types of information
   resources which will be sent by the Notifier.

9.1.  Example

   The following is an example Information Resource Directory returned
   by an ALTO Server.  In this example, the ALTO Server provides
   subscription, notification and unsubscribe service via a separate
   subdomain, "custom.alto.example.com".


































Madhavan & Nandiraju     Expires August 25, 2012               [Page 16]

Internet-Draft                ALTO Caching                 February 2012


   GET /directory HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-directory+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-directory+json

   {
   "resources" : [
   {
    "uri" : "http://alto.example.com/serverinfo",
    "media-types" : [ "application/alto-serverinfo+json" ]
   }, {
    "uri" : "http://alto.example.com/networkmap",
    "media-types" : [ "application/alto-networkmap+json" ]
   }, {
    "uri" : "http://alto.example.com/subscription",
    "media-types" : [
      "alto-subscriptiondata+json"
    ],
    "accepts" : [
      "application/alto-networkmapfilter+json",
      "application/alto-costmapfilter+json",
      "application/alto-endpointpropparams+json",
      "application/alto-endpointcostparams+json"
    ]
   },{
    "uri" : "http://alto.example.com/notification",
    "media-types" : [
      "application/alto-networkmap+json",
      "application/alto-costmap+json",
      "application/alto-endpointprop+json",
      "application/alto-endpointcost+json"
    ],
    "accepts" : [
      "application/alto-networkmapfilter+json",
      "application/alto-costmapfilter+json",
      "application/alto-endpointpropparams+json",
      "application/alto-endpointcostparams+json"
    ]
   },{
    "uri" : "http://alto.example.com/unsubscribe"
   }
   ]
   }





Madhavan & Nandiraju     Expires August 25, 2012               [Page 17]

Internet-Draft                ALTO Caching                 February 2012


10.  Transport Considerations

   If subscription mechanism needs to be used the ALTO nodes MUST work
   as peers.

   Input parameters and responses are encoded in the HTTP request's
   entity body, and the request uses the HTTP POST method.


11.  Acknowledgements


12.  IANA Considerations

12.1.  application/alto-* Media Types

     This document requests the registration of multiple media types,
                            listed in Table 1.

       +-------------+----------------------------+---------------+
       | Type        | Subtype                    | Specification |
       +-------------+----------------------------+---------------+
       | application | alto-subscribeinput+json   | Section 6.1.1 |
       | application | alto-subscriptiondata+json | Section 6.4.1 |
       | application | alto-notificationdata+json | Section 6.5.1 |
       +-------------+----------------------------+---------------+

                                  Table 1


13.  Security Considerations

   TBD


14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

14.2.  Informative References

   [I-D.ietf-alto-deployments]
              Stiemerling, M. and S. Kiesel, "ALTO Deployment
              Considerations", draft-ietf-alto-deployments-03 (work in
              progress), November 2011.



Madhavan & Nandiraju     Expires August 25, 2012               [Page 18]

Internet-Draft                ALTO Caching                 February 2012


   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-10 (work in progress),
              October 2011.

   [I-D.ietf-alto-reqs]
              Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", draft-ietf-alto-reqs-13 (work in progress),
              January 2012.

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


Authors' Addresses

   Sreekanth Madhavan
   Huawei Technologies
   Bangalore,
   India

   Phone:
   Email: sreekanth.madhavan@huawei.com


   Nandiraju Ravishankar
   Huawei Technologies
   Bangalore,
   India

   Phone:
   Email: ravi.nandiraju@huawei.com

















Madhavan & Nandiraju     Expires August 25, 2012               [Page 19]