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

Versions: 00 01

Network Working Group                                S. Randriamasy, Ed.
Internet-Draft                                  Alcatel-Lucent Bell Labs
Intended status: Experimental                             April 15, 2011
Expires: October 17, 2011


                 Provider Confidential ALTO with Relays
                    draft-randriamasy-alto-relay-01

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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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



Randriamasy             Expires October 17, 2011                [Page 1]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


   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 October 17, 2011.

Copyright Notice

   Copyright (c) 2011 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 Simplified BSD License.































Randriamasy             Expires October 17, 2011                [Page 2]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Provider Confidential ALTO . . . . . . . . . . . . . . . . . .  6
     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Provider Confidential ALTO architecture  . . . . . . . . .  7
       4.2.1.  Architecture Framework . . . . . . . . . . . . . . . .  7
       4.2.2.  Current Transaction framework  . . . . . . . . . . . .  8
     4.3.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  ALTO requirements  . . . . . . . . . . . . . . . . . . . . 10
       4.4.1.  ALTO Relays and Connection Relays  . . . . . . . . . . 10
       4.4.2.  PC ALTO discovery processes  . . . . . . . . . . . . . 11
     4.5.  ALTO protocol description updates  . . . . . . . . . . . . 11
       4.5.1.  Need for a PC Service Property . . . . . . . . . . . . 11
       4.5.2.  ALTO messages  . . . . . . . . . . . . . . . . . . . . 11
   5.  Other optional Connection Relay Services . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13


























Randriamasy             Expires October 17, 2011                [Page 3]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


1.  Introduction

   IETF is designing a new service called ALTO that provides guidance to
   P2P applications, which have to select one or several hosts from a
   set of candidates that are able to provide a desired resource.  This
   guidance shall be based on parameters that affect performance and
   efficiency of the data transmission between the hosts, e.g., the
   topological distance.  The ultimate goal is to improve Quality of
   Experience (QoE) in the application while reducing resource
   consumption in the underlying network infrastructure.  The ALTO
   protocol conveys the Internet View from the perspective of a Network
   Provider network region that spans from a region of an Autonomous
   System (AS) to several ASes.  Together with this Network Map, the
   Network Provider determines a Cost Map between locations of the
   Network Map. Last, it provides the NP oriented Ranking of Endpoints
   w.r.t. their routing cost.  Thus an application client can easily get
   the whole Provider Network topology.  Network Providers (NP) in this
   document include both ISPs, who provide means to transport the data
   and Content Delivery Network (CDN) who care for the dissemination,
   storage and possibly identification of the "best" content copy.

   For security reasons however, Network Providers for either transport
   or delivery of content, are reluctant to provide their network
   topology to third parties that may misuse it.  Indeed, the current
   ALTO protocol draft, see [ID-alto-protocol] , includes a section on
   "Security Considerations" where section "Privacy Considerations for
   ISPs" mentions the layer confidentiality issue that needs to be
   solved before ISPs adopt the ALTO protocol.

   This draft proposes to address this issue by introducing a
   transaction mode qualified as "Provider Confidential" (PC).  A PC
   ALTO transaction involves one or several additional entities that are
   called an ALTO Relay.  An ALTO Relay gets the ALTO Responses issued
   by an ALTO Server in place of the Application Client.  The ALTO
   Client itself just gets a status indicating success or failure of the
   transaction.  In case of success, the Application Client connects to
   an entity called a Connection Relay (CR), that is linked to an ALTO
   Relay and mapped to the network region hosting the requesting
   Application Client.  The Application Client, meanwhile specifies how
   to select and connect to the candidate Endpoints given their ranking
   or cost.  It sends this "connection policy" to its associated
   Connection Relay, that must enforce it with the ranking or cost
   received from the ALTO Server.  The CR then communicates with the
   Application Client who thus knows nothing about the ALTO selected
   Endpoints.  The best applicable ALTO Services are in particular the
   Endpoint Cost Service and the Endpoint Property Service.

   This way, users of an ISP that supports Provider Confidential ALTO



Randriamasy             Expires October 17, 2011                [Page 4]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


   Services get a better QoE while the ISP saves its resources.

   An Application Client MAY refuse to use Provider Confidential ALTO
   Services.  In that case, one option is that the client gets no ALTO
   service at all, especially if the ISP supports only PC ALTO services,
   and thus a worse QoE.


2.  Scope

   It is assumed that Applications likely to use the ALTO service have a
   choice among several connection endpoints as it is the case for most
   of them.

   This draft generalizes the term P2P Client to Application Client.
   Application Clients include CDN Clients and any Application Client
   having the choice in several connection points for data or resource
   exchange, such as GRID Application Clients, Gaming Application
   Clients and a limited number of P2P Clients.

   The term P2P Clients is used only in the figures, to better
   illustrate the difference of the present proposal with the current
   ALTO protocol draft.  This draft focuses on the use case where: the
   ALTO Client is embedded in the Application Client , only one ALTO
   Relay and one Connection Relay is involved in a PC ALTO Transaction,
   and the ALTO Relay is embedded in the Connection Relay.


3.  Terminology

   Endpoint (EP): stands for Connection Endpoint as in can be a content
   location in [ID-alto-protocol].

   Network Provider: can be an ISP who provides means to transport the
   data or a Content Delivery Network (CDN) provider who cares for the
   dissemination, persistent storage and possibly identification of the
   "best"content copy.

   Application Client (AC): a Client having the choice in several
   connection points for data or resource exchange: typically a client
   of a CDN or a GRID application or a small P2P network.

   ALTO Relay: a functional entity that is mapped to the Application
   Client (AC) w.r.t. the region hosting this Application Client, by an
   ALTO discovery process driven by the Network Provider.  It receives
   the ALTO responses in place of the requesting AC.  The ALTO Relay
   discovery process still needs to be specified.




Randriamasy             Expires October 17, 2011                [Page 5]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


   Connection Relay: this networking entity is linked to or hosts an
   ALTO Relay and is connected with both the Selected Endpoints and the
   Application Client.  It is a transit point between an AC and the
   Selected Endpoints so that the AC ignores the ID and location of the
   Selected EPs.

   Provider Confidential (PC) ALTO Service: this service uses ALTO
   Relays and Connection Relays to keep the Provider Network information
   ignored by the ACs while providing ALTO Services.


4.  Provider Confidential ALTO

4.1.  Overview

   To prevent Provider Confidential (PC) information from being unveiled
   to Application Clients, this draft proposes an indirection of the
   information provided by an ALTO Server to an intermediate ALTO
   Functional Entity that is linked to a Networking Entity taking care
   of the transport of the data between the Application Client and the
   selected Endpoint(s).  In this draft, the intermediate Functional
   Entity is called ALTO Relay and the connecting Networking entity a
   Connection Relay.  These two entities are managed by the Network
   Provider.  PC ALTO is particularly well suited to the ALTO protocol
   services reporting on Endpoint Cost and Endpoint Properties.

   Figure 1 shows an example scenario provided in the ALTO protocol
   draft, see [ID-alto-protocol], where the ALTO client is embedded in
   the P2P Client and requires an ALTO server servicing its own ISP to
   provide the Endpoint Cost for a list of gathered peers.

   The use case proceeds as follows:

   1.  The P2P Client discovers peers from sources such as Peer Exchange
       (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and
       P2P Trackers.

   2.  The P2P Client queries the ALTO Server's Ranking Service,
       including discovered peers as the set of Destination Endpoints,
       and indicates the 'ordinal' Cost Mode.  The response indicates
       the ranking of the candidate peers.

   3.  The P2P Client connects to the peers in the order specified in
       the ranking.







Randriamasy             Expires October 17, 2011                [Page 6]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


      .---------.                          .---------------.
      |         | (2) Get Endpoint Ranking |               |
      |  ALTO   | <----------------------> | [ALTO Client] |
      | Server  |                          |               |
      |         |                          |  P2P Client   |    .---------.
      `---------'                          `---------------' <- |  P2P    |
                .---------.                 /  |      ^    ^    | Tracker |
                | Peer 1  | <--------------    |      |     \   `---------'
                `---------'                    |    (1) Gather Peers
                    .      (3) Connect to      |      |       \
                    .        Selected Peers   /   .--------.  .--------.
                .---------.                  /    |  P2P   |  |  DHT   |
                | Peer 50 | <----------------     | Client |  `--------'
                `---------'                       | (PEX)  |
                                                  `--------'


   Figure 1:  Current ALTO protocol scenario for an ALTO Client
   collocated with the P2P Client and querying the ALTO server Ranking Service.


4.2.  Provider Confidential ALTO architecture

4.2.1.  Architecture Framework

   The Provider Confidential Services mentionned in this draft apply
   whether the ALTO Client is co-located with the Application Client or
   with the Application Endpoint tracker.  However they are more
   suitable to the first of these two cases.

   Several kinds of mapping and discovery processes are needed to
   support PC ALTO.  They still need to be specified w.r.t. the ALTO
   Server Discovery under definition.  An AC can be serviced by one or
   several ALTO Servers.  Likewise, an ALTO Relay can be embedded in a
   Connection Relay, or connected to several Connection Relays.  An AC
   itself can be connected to several Connection Relays associated to
   one ALTO Relay.  Future work on PC ALTO needs to define:

   o  The association between an ALTO Server and the ALTO Relay
      receiving its responses.

   o  The association between an Application Client and one or more ALTO
      Connection Relays.

   o  The mapping between ALTO Relays and ALTO Connection Relays.

   The mappings between the ALTO Server and ALTO Relay should be managed
   by the NP.



Randriamasy             Expires October 17, 2011                [Page 7]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


4.2.2.  Current Transaction framework

   For the moment the described PC ALTO transaction relies on the
   following hypotheses:

   1.  An ALTO Client named AOC1 is embedded in or connected to an
       Application Client.

   2.  AOC1 has discovered a reference ALTO server AOS(1), that is
       possibly communicating with other ALTO servers.

   3.  AOC1 has discovered the capabilities of AOS(1) and discovers and
       accepts that all or several types of requested Provider Network
       information are classified as PC.

   4.  AOS(1) is mapped to an ALTO Relay AOR(AOS(1)), by a relevant ALTO
       discovery process, managed by the Network Provider.

   5.  The information requested by AOC1 will be sent to the ALTO Relay
       AOR(AOS(1)).

   6.  AOC(1) will receive from AOS(1) specific ALTO responses (i)
       containing an ALTO status code of success or failure for its
       request, (ii) indicating Provider Confidentiality.

       A.  If the association between an ALTO Client and an ALTO
           Connection Relay is managed by the Network Provider, then
           AOS(1) MUST send to AOC(1) the ID or the Address of the
           Connection Relay(s) it can associate with.

   7.  AOR(AOS(1)) is embedded in or connected to a Connection Relay
       that MUST connect to both the Application Client and to the
       Selected Endpoints.

4.3.  Use cases

   Figure 2 depicts the features and mechanisms added to the current
   ALTO scenario for Provider Confidential ALTO services, for the use
   case depicted in Figure 1.  The EPs have already been discovered.  In
   this figure, the term Peer is replaced by the term Endpoint, the term
   P2P Client by Application Client and a specific Tracker for resource
   sharing Application Endpoints should be added to the tools involved
   in step (1) of Figure 1.  Last the ALTO Service requested by the ALTO
   Client in this example is the "Endpoint Cost" in 'ordinal' mode, that
   provides a ranking of the candidate Endpoints.

   We focus on the ALTO use case where the ALTO Client is co-located
   with an Application Client in a terminal node.  As in section



Randriamasy             Expires October 17, 2011                [Page 8]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


   Figure1, the Application Client queries the ALTO Server servicing its
   own ISP.  An ALTO Relay is mapped to the queried ALTO server.  This
   ALTO Relay is associated to one single ALTO Connection Relay and
   embedded in it.  The ALTO Client requests the ALTO Endpoint Ranking
   Service.


      .---------.                          .---------------.
      |         |(2) Get Endpoint Cost     |               |
      |         |      (ordinal)           | [ALTO Client] |
      |  ALTO   | <----------------------  |               |
      | Server  | ---------------------->  |  Application  |
      |         | (4) Send ALTO Status     |    Client     |      .---------.
      `---------'  (PC) and address of     `---------------' <--- |  EP     |
             |       Connection Relay         |           ^ ^     | Tracker |
             |                                |           |  \    `---------'
             '-----------------------.        |           |   \
                                     |        |           |    \
             (3) Send Endpoint Costs |        |          (1) Gather Endpoints
                   to ALTO Relay     |  (5) Connect to    |      \
                                     |   Connection Relay |       \
                                     |   Send EP specs    |        \
                                     |        |           |         \
     .-----------.                   v        v           |          \
     | Endpoint1 |                 .------------.     .--------.  .--------.
     `-----------' <-------------  |[ALTO Relay]|     |  DNS   |  |  DHT   |
            .      (6) Connect to  |            |     |        |  `--------'
            .      Selected EPs    | Connection |     |   ...  |
     .-----------. <-------------  |   Relay    |     `--------'
     | Endpoint9 |                 `------------'
     `-----------'

   Figure 2: Provider Confidential ALTO transaction for an ALTO Client
   collocated with the Application Client and querying the ALTO Server
   Endpoint Cost Service in ordinal mode.
   The ALTO Relay is embedded in the Connection Relay.
   The EPs have already been discovered.


   The use case proceeds as follows:

   1.  The Application Client discovers EPs from Endpoints tracking
       processes applicable to CDN, Trackerless P2P, or other
       applications connecting several EPs such as gaming and GRID.

   2.  The Application Client via its ALTO Client queries the ALTO
       Server's Endpoint Cost Service, including discovered Endpoints as
       the set of Destination Endpoints, and indicates the 'ordinal'



Randriamasy             Expires October 17, 2011                [Page 9]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


       Cost Mode.

   3.  The ALTO Server sends the requested Path Ranking information to
       its associated ALTO Relay,

   4.  The ALTO Server responds to the Application Client with:

       A.  an ALTO status indicating: (i) failure or success and (ii)
           that the Provider Confidential ServiceType is activated,

       B.  the IP address of the Connection Relay to connect to,

       *  An option is that: if the Network Provider gives the
          Application Client the possibility to refuse the Provider
          Confidential ServiceType and if the AC does so, then it may
          get a lower priority service.

       *  The ALTO Server response to the ALTO Client:

          +  Does not contain any EP address (or other Network
             Information) but MAY content other synthetic information
             such as the number of processed EP locations.

          +  MUST indicate that the sending of the requested information
             to the ALTO Relay has been is completed.

   5.  The Application Client connects to the Connection Relay and sends
       its requirements on how to select and connect to the Endpoints.
       E.g. to how many.

   6.  The Connection Relay connects to the selected Endpoints.

       *  The Connection Relay is now a transit point between the ALTO
          Client and the selected application Endpoints.

4.4.  ALTO requirements

   This section lists the features and updates to the ALTO protocol
   draft that are needed to support PC ALTO transactions.

4.4.1.  ALTO Relays and Connection Relays

   These are the basic additional ALTO architecture elements.  In this
   framework, the ALTO Relay is associated to the Control plane and the
   Connection Relay to the Data plane.  The current protocol draft
   [ID-alto-protocol], , in Section on "Service ID", stresses that "for
   scalability and fault tolerance, multiple ALTO Servers may deployed
   to serve equivalent ALTO information".  Likewise, the deployment and



Randriamasy             Expires October 17, 2011               [Page 10]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


   association of ALTO Relays and Connection Relays should allow
   scalability and fault tolerance, especially for large numbers of
   connected Endpoints.

4.4.2.  PC ALTO discovery processes

   An ALTO Relay discovery process is necessary to associate ALTO
   Servers and ALTO Relays.  Preferably, it just looks up the mapping
   between Servers and Relays, which is previously set by the Provider
   Network management and updated when necessary, typically when the
   Network Map changes, which is not frequent.  Likewise, whether the
   ALTO Connection Relay discovery is driven by the ALTO Server needs to
   be decided.

4.5.  ALTO protocol description updates

   This section proposes a list of updates to the current ALTO protocol
   draft that would support PC ALTO.

4.5.1.  Need for a PC Service Property

   ALTO services and related requests are currently classified w.r.t.
   their type, that is, the information they provide.  They should also
   be classified w.r.t. the way the Network Provider management
   processes the ALTO requests and the responses sent to the Application
   Client.  Typically, if a requested information is considered as
   Provider Confidential by a NP, the corresponding request should be
   classified so and this information sent to the ALTO Client.

   In Section "Protocol Structure", Service Properties could be
   introduced to characterize Provider Confidential ALTO Services.

   Another section may detail how a PC attribute is defined.  For
   example, the section on "Server Capability" may introduce something
   like:

   enum { ServiceDistribution, ..., } ServiceProperty;

   enum { Provider Confidential, Public, Unauthorized, ... }
   ServiceDistribution;

4.5.2.  ALTO messages

   This section on PC specific ALTO messages is very schematic and will
   be further detailed as the work on PC ALTO Services progresses.






Randriamasy             Expires October 17, 2011               [Page 11]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


4.5.2.1.  ALTO Status Codes for PC Services

   When the "Provider Confidential" Service Distribution property is
   available and activated, the ALTO Status codes for the responses sent
   to an ALTO Client MUST include the case where a request has been
   successfully processed but the requested information redirected to
   the ALTO Relay because the invoked ALTO Service is PC.

   In [ID-alto-protocol] , the section on "ALTO Status Codes" provides
   definitions in Table 1 "ALTO Status Codes".  A PC specific status
   code should be added.  It could be for instance: "ALTO Status code =
   7 (or whatever), HTTP Status code=204, Description = (Success) No
   Content".

4.5.2.2.  ALTO Requests

   The ALTO Client does not know in advance whether an ALTO Service is
   PC or not.  So the Request syntax remains the same as the one
   described in [ID-alto-protocol], Section 7.7.5.1.1 "Request Syntax".

   request = POST, HTTP method and URI path

4.5.2.3.  Response Syntax for PC Services

   If the PC service distribution mode is activated, then the
   ServiceProperty attribute ServiceDistribution MUST be set to
   "Provider Confidential".

4.5.2.3.1.  ALTO Server response to ALTO Relay

   The ALTO Server response to an ALTO Relay contains the ALTO
   information requested by the ALTO Client.

4.5.2.3.2.  ALTO response to ALTO Client

   The response to the ALTO Client sent by ALTO Server contains: the
   ALTO Status, plus possible PC specific Response Meta Information plus
   the address or ID of the Connection Relay to connect to.


5.  Other optional Connection Relay Services

   A Connection Relay may host other services.  At the first place, it
   can act as a cache for the data traded by all the interconnected
   Application Clients.  This can significantly help saving time and
   resources both in transport and retrieval of information and
   resources.




Randriamasy             Expires October 17, 2011               [Page 12]


Internet-Draft   Provider Confidential ALTO with Relays       April 2011


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   The Application Client MUST have the guarantee to be connected to a
   Connection Relay that is safe, as the latter is managed by the NP and
   therefore must be protected from any spoofing.  However the client
   may want additional guarantees about the way the NP will process its
   requests for ALTO information.


8.  Acknowledgements


9.  References

9.1.  Normative References

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

9.2.  Informative References

   [ID-alto-protocol]
              ""ALTO Protocol" draft-ietf-alto-protocol-07.txt",
              March 2011.


Author's Address

   Sabine Randriamasy (editor)
   Alcatel-Lucent Bell Labs
   Route de Villejust
   NOZAY  91620
   FRANCE

   Email: Sabine.Randriamasy@alcatel-lucent.com








Randriamasy             Expires October 17, 2011               [Page 13]


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