Provider Confidential ALTO with Relays
draft-randriamasy-alto-relay-01
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Sabine Randriamasy | ||
Last updated | 2011-04-15 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
IETF is designing a new service called ALTO (Application Layer traffic Optimization) that includes a "Network Map Service" and an "Endpoint Ranking Service" and thus incentives for application clients to connect to ISP preferred Endpoints. These services provide a view of the Network Provider (NP) topology to overlay clients. However, NPs remain reluctant to implement the ALTO protocol for security reasons. In particular, they do not want their topology to be easily unveiled to third parties and thus more vulnerable to misuse. This document proposes a scheme to preserve Network Provider confidentiality while allowing the use of ALTO information for applications. It introduces an "ALTO Relay" that gets the provider confidential ALTO response and hands it to a functional entity called a Connection Relay. Meanwhile the ALTO Client gets a status and directions to connect to Connection Relay, that then will hand the desired application data. The benefit for Application Clients accepting ALTO transactions involving ALTO Relays is a better quality of experience.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)