Internet DRAFT - draft-madhavan-alto-subscription
draft-madhavan-alto-subscription
Internet Engineering Task Force S. Madhavan
Internet-Draft R. Nandiraju
Intended status: Informational Huawei Technologies
Expires: August 1, 2013 February 1, 2013
ALTO Subscription
draft-madhavan-alto-subscription-01
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 propose
a mechanism where 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 February 2, 2013.
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Madhavan & Nandiraju Expires February 2, 2013 [Page 1]
Internet-Draft ALTO Subscription August 2012
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 . . . . . . . . . . . . . . . . . . . . . . 3
4. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 4
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. ContactAddr . . . . . . . . . . . . . . . . . . . . . . . 5
7. Subscription and Notification Service . . . . . . . . . . . . 5
7.1. Requesting a Subscription . . . . . . . . . . . . . . . . 5
7.1.1. Input Parameters . . . . . . . . . . . . . . . . . . . 6
7.2. Refreshing of Subscriptions . . . . . . . . . . . . . . . 7
7.3. Notifier Subscription Handling . . . . . . . . . . . . . . 7
7.3.1. Response . . . . . . . . . . . . . . . . . . . . . . . 7
7.4. Notifier Notification behavior . . . . . . . . . . . . . . 8
7.4.1. Input Parameters . . . . . . . . . . . . . . . . . . . 8
7.5. Subscriber Notification handling . . . . . . . . . . . . . 9
7.6. Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 9
7.7. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Detecting support for Subscription Service . . . . . . . . . . 11
8.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Transport Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11.1. application/alto-* Media Types . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Madhavan & Nandiraju Expires February 2, 2013 [Page 2]
Internet-Draft ALTO Subscription August 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 subscribe to the
ALTO server and get 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
Case 1: 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
number of subscribers and the availability of address space within
the ISP. In P2P networks, if this information is shared to trackers,
then it can help the trackers to efficiently localize P2P traffic.
Case 2: In i2aex, there are use cases for CDN and inter DC data
transfer which need notifications of changed information between the
ALTO clients and servers [I-D.seedorf-i2aex-alto-cdni-perpective]
[I-D.lee-alto-ext-dc-resource]
Case 3: Notification based mechanims provide strong cache consistency
for ALTO caches
[http://www.ietf.org/proceedings/83/slides/slides-83-alto-1.pdf]
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].
Madhavan & Nandiraju Expires February 2, 2013 [Page 3]
Internet-Draft ALTO Subscription August 2012
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 querying the map
information. The ALTO server sends the map information providing
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
5. Definitions
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
Madhavan & Nandiraju Expires February 2, 2013 [Page 4]
Internet-Draft ALTO Subscription August 2012
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.
6. ALTO Types
This section details the format for particular data values used for
ALTO Subscription framework. Base types defined by I-D.ietf-alto-
protocol are used by this memo with some extensions listed below.
6.1. 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 may be
persistent.
ContactAddr is defined as:
object {
EndpointAddr addr;
JSONInteger port;
} ContactAddr;
7. 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.
7.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
Madhavan & Nandiraju Expires February 2, 2013 [Page 5]
Internet-Draft ALTO Subscription August 2012
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.
7.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
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
Madhavan & Nandiraju Expires February 2, 2013 [Page 6]
Internet-Draft ALTO Subscription August 2012
ReqFilteredNetworkMap, ReqFilteredCostMap, ReqEndpointProp and
ReqEndpointCostMap JSON object definitions.
7.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.
7.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.
7.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;
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
Madhavan & Nandiraju Expires February 2, 2013 [Page 7]
Internet-Draft ALTO Subscription August 2012
7.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.
7.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
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.
Madhavan & Nandiraju Expires February 2, 2013 [Page 8]
Internet-Draft ALTO Subscription August 2012
7.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.
7.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.
7.7. Example
An ALTO node [P2P Tracker] queries the ALTO server and contacts the
peer for service. Node 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
]
},
{
"pids": [ "PID1", "PID2" ]
}
}
HTTP/1.1 200 OK
Content-Length: [TODO]
Madhavan & Nandiraju Expires February 2, 2013 [Page 9]
Internet-Draft ALTO Subscription August 2012
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" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
}
Madhavan & Nandiraju Expires February 2, 2013 [Page 10]
Internet-Draft ALTO Subscription August 2012
}
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
8. 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.
Madhavan & Nandiraju Expires February 2, 2013 [Page 11]
Internet-Draft ALTO Subscription August 2012
8.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 February 2, 2013 [Page 12]
Internet-Draft ALTO Subscription August 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 February 2, 2013 [Page 13]
Internet-Draft ALTO Subscription August 2012
9. 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.
10. Acknowledgements
11. IANA Considerations
11.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
12. Security Considerations
TBD
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[I-D.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO
Deployment Considerations", draft-ietf-alto-deployments-04
(work in progress), March 2012.
Madhavan & Nandiraju Expires February 2, 2013 [Page 14]
Internet-Draft ALTO Subscription August 2012
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-12 (work in progress), July 2012.
[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-16 (work in progress),
June 2012.
[I-D.lee-alto-ext-dc-resource]
Lee, Y., Bernstein, G., Madhavan, S., and D. Dhody, "ALTO
Extensions for Collecting Data Center Resource
Information", draft-lee-alto-ext-dc-resource-00 (work in
progress), July 2012.
[I-D.seedorf-i2aex-alto-cdni-perpective]
Seedorf, J., "Infrastructure-to-application information
exposure from an ALTO-CDNI Perspective",
draft-seedorf-i2aex-alto-cdni-perpective-00 (work in
progress), March 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 February 2, 2013 [Page 15]
