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

Versions: 00 01

Network Working Group                                 Y. El Mghazli, Ed.
Internet-Draft                                       S. Randriamasy, Ed.
Intended status: Standards Track                              F. Taburet
Expires: April 26, 2011                  Alcatel-Lucent Bell Labs France
                                                        October 23, 2010


                          ALTO in Mobile Core
                 draft-randriamasy-alto-mobile-core-01

Abstract

   The ALTO working group 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 performance (or Quality of Experience) in
   the application while reducing resource consumption in the underlying
   network infrastructure.

   The present document addresses the case of ALTO transactions
   involving a peers connected via a mobile core network.  It proposes
   specific scopes and use cases for mobile core networks and as a first
   step, properties of paths and endpoints that allow to facilitate ALTO
   transaction within such a scope.

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 [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
   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."




El Mghazli, et al.       Expires April 26, 2011                 [Page 1]


Internet-Draft              alto-mobile-core                October 2010


   This Internet-Draft will expire on April 26, 2011.

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



































El Mghazli, et al.       Expires April 26, 2011                 [Page 2]


Internet-Draft              alto-mobile-core                October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  ALTO usage in Mobile Core Networks . . . . . . . . . . . . . .  4
     2.1.  Architecture and Peer Selection Model  . . . . . . . . . .  4
     2.2.  ALTO Scope for Mobile Core Network . . . . . . . . . . . .  5
       2.2.1.  Spatial scope of Mobile Core ALTO  . . . . . . . . . .  5
       2.2.2.  Time scope of Mobile Core ALTO . . . . . . . . . . . .  6
     2.3.  Scenario and use case: Endpoint Cost lookup  . . . . . . .  6
   3.  Example: MC-ALTO in a 3GPP framework . . . . . . . . . . . . .  7
     3.1.  MC-ALTO Endpoint Cost transactions . . . . . . . . . . . .  7
       3.1.1.  Current ALTO Protocol  . . . . . . . . . . . . . . . .  7
       3.1.2.  Example of MC-ALTO extensions  . . . . . . . . . . . .  8
     3.2.  3GPP Cost Map Specifications . . . . . . . . . . . . . . .  8
       3.2.1.  3GPP Registration, Location and Routing Areas  . . . .  9
       3.2.2.  3GPP User Identification and location  . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




























El Mghazli, et al.       Expires April 26, 2011                 [Page 3]


Internet-Draft              alto-mobile-core                October 2010


1.  Introduction

   An ALTO Server could support many properties about Endpoints beyond
   their network location or grouping.  For example, connection type,
   geographical location, and others may be useful to applications.  The
   current ALTO protocol draft [ID-alto-protocol5] considers the peer
   selection problem from a broadband ISP perspective and focuses on
   metrics that are almost static and relate mainly to topological
   distance and routing cost in IP networks.

   Mobile network resources are scarce and the endpoints may move.
   Therefore, Mobile operators may wish to integrate P2P techniques
   (including P2PTV) in order to take advantage of powerful and cheap
   techniques to deliver resources like TV channels, instead of using
   complex and costly client/server centralized solutions.  Such
   operators may need to optimize P2P traffic by selecting mobile
   endpoints based on the underlying mobile network topology itself.

   The present document proposes to define ALTO protocol features that
   are specific to Mobile Core networks.  As a first example, it
   proposes an extension to the ALTO protocol that allow to identify and
   locate a peer within a 3GPP mobile network.  It actually specifies
   3GPP network location identifiers to be conveyed in the ALTO
   messages.


2.  ALTO usage in Mobile Core Networks

   This section discusses an approach to perform peer selection using
   information from an ALTO server operated by a mobile network
   operator.

2.1.  Architecture and Peer Selection Model

   In the approach described here, we assume a peer selection model
   where the resource directory returns a list of potential resource
   providers.

   Figure 1 shows the Mobile Core-ALTO integrated architecture that is
   discussed in this document.  As an example, we have added a Mobile
   Core (MC) specific element, that is linked to the ALTO server and
   feeds it with information.  In the present case this element is the
   Host Location Register and Visitor Location Register (HLR/VLR).
   Currently such information is considered out of the ALTO scene, but
   the purpose is to initiate Mobile Core specific ALTO.






El Mghazli, et al.       Expires April 26, 2011                 [Page 4]


Internet-Draft              alto-mobile-core                October 2010


   +-------------------------------------------------------------------+
   |                      Mobile Core Operator                         |
   |                                                                   |
   |                                                                   |
   |  +-----------+       +---------+                  +--------+      |
   |  |MC specific|       | ALTO    | ALTO Protocol    | ALTO   |      |
   |  |information|.......| Server  | ---------------- | Client |      |
   |  |  HLR/VLR  |       +---------+                  +--------+      |
   |  +-----------+                                   /       |        |
   |                              ALTO SD Query/Response      |        |
   |                                               /          |        |
   |                                       +-----------+  +----------+ |
   |                                       | ALTO      |  |    P2P   | |
                                           | Service   |  |  tracker | |
   |                                       | Discovery |  +----------+ |
   |                                       +-----------+               |
   |                                                                   |
   | Figure 1: Mobile Core-ALTO integrated architecture:               |
   |           example integrating 3GPP location information           |
   +-------------------------------------------------------------------+


   The way the ALTO Server associates the network coordinates of a
   mobile user to a corresponding peer is out of the scope of the
   present document.

2.2.  ALTO Scope for Mobile Core Network

   Mobile core networks have smaller sizes as ISP Core networks in terms
   of topology.  On the other hand they have a higher degree of topology
   change in terms of their connections to end nodes.  Above all, they
   need to cope with limited resources.  This motivates and justifies
   the use of Mobile Core specific Alto services that report the
   mobility of particular endpoints thay support and that can afford the
   high dynamicity of ALTO information, because of the smaller size of
   the network the Alto servers report on.

2.2.1.  Spatial scope of Mobile Core ALTO

   The spatial scope of Mobile Core ALTO (MC-ALTO) Servers is restricted
   to the MC.  They report on the MC topology and other information
   related to the MC topology.  They also report on the endpoints
   attached to this MC.  One option is that the MC-ALTO Servers
   communicate with ALTO Servers managed by the same ISP but located and
   reporting on the ISP Core network.






El Mghazli, et al.       Expires April 26, 2011                 [Page 5]


Internet-Draft              alto-mobile-core                October 2010


2.2.2.  Time scope of Mobile Core ALTO

   Any information can have a lifetime as long a that of ISP core ALTO.
   However MC ALTO can handle information with a shorter lifetime.  A
   reduced time scope serves mainly the purpose of tracking the mobility
   of attached Endpoints.

2.3.  Scenario and use case: Endpoint Cost lookup

   Mobile Core ALTO integration is illustrated with the ALTO use case
   where: an ALTO client is embedded in the P2P client, the endpoints
   cost evaluation and ranking are outsourced to the ALTO Server before
   the client performs the final selection.  It is then the duty of the
   resource consumer to invoke ALTO, in order to solicit the ISP
   guidance regarding this list.

   Figure 2. below shows an example of this scenario.

 .-----------.                          .---------------.
 |Mobile Core|                          |               |
 |    ALTO   |  (2) Get Endpoint Cost   |  P2P Client   |
 |   Server  | <----------------------> | (ALTO Client) |
 |           |                          |               |    .---------.
 `-----------'                          `---------------' <- |  P2P    |
             .---------.                 /  |      ^    ^    | Tracker |
             | Peer 1  | <--------------    |      |     \   `---------'
             `---------'                    |    (1) Gather Peers
                 .      (3) Connect to      |      |       \
                 .        Selected Peers   /   .--------.  .--------.
             .---------.                  /    |  P2P   |  |  DHT   |
             | Peer 50 | <----------------     | Client |  `--------'
             `---------'                       | (PEX)  |
                                               `--------'
Figure 2: Mobile Core ALTO with an ALTO Client embedded in a P2P Client


   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 its ALTO Server, including discovered
       peers as the set of Destination Network Locations, and indicates
       the 'ordinal' Cost Mode (It means that the returned Cost Map
       indicates the ranking of the candidate peers).  Together with
       this "regular" ALTO information, the ALTO Client provides its
       coordinates in the Mobile network.



El Mghazli, et al.       Expires April 26, 2011                 [Page 6]


Internet-Draft              alto-mobile-core                October 2010


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

   The set of Endpoints that are analysed by the ALTO Server may be
   either inside of outside the mobile core.  The way information
   Endpoints inside and outside the MC is coordinated is currently
   outside of the scope of the present draft and will be addressed in
   further versions.

   Do note that there may be an alternative way to integrate ALTO
   services into Mobile Core networks, where a P2P application that
   makes use of a centralized resource directory (in some specific P2P
   implementations called a "tracker").  In this scenario the ALTO
   servers receive queries only from few entities, i.e., the resource
   directories.  As these resource directories must be powerful machines
   anyway, it may be reasonable to send large amounts of ALTO guidance
   data to them, which will be cached there.  Furthermore, in this
   scenario it may be possible to hide the exact addresses of the peers
   from the ALTO server.  This latter case is out of scope of the
   present document.


3.  Example: MC-ALTO in a 3GPP framework

   This section provides an example of MC specific information involved
   in MC ALTO transaction.  The example information is the 3GPP location
   information on the client querying a MC ALTO Endpoint Cost service.
   Such information is currently out of scope of the ALTO protocol.  The
   purpose is to initiate the introduction of MC specific information
   and define its consequences in the ALTO Protocol.

3.1.  MC-ALTO Endpoint Cost transactions

3.1.1.  Current ALTO Protocol

   Below are the formats of the ALTO Endpoint Cost Lookup request and
   response, as described in the current ALTO protocol
   draft[ID-alto-protocol5] .  The request message allows an ALTO Client
   to query for costs amongst an arbitrary set of source and destination
   endpoints.

   Here, the ALTO Endpoint Cost Lookup request is issued by the ALTO
   client to order for each source peer the list of destination peers
   gathered by the P2P network (e.g. from a P2P tracker).  In this
   example, the ALTO Client request for Endpoint Costs in the "ordinal"
   mode.  The ALTO Endpoint Cost request syntax is:





El Mghazli, et al.       Expires April 26, 2011                 [Page 7]


Internet-Draft              alto-mobile-core                October 2010


      POST /endpoint/cost/lookup<URI-Query-String> HTTP/1.1

      Host: <Host>

      Content-Length: <BodyLength>



      <ReqCostMap>

   The request body includes a list of source and destinaiton endpoints
   that should be assigned a cost rank by the ALTO server.  The allowed
   query string parameters are described in the current protocol (secton
   7.7.3.2).  The identifiers correspond to endpoints, specified
   currently by their IP address.

   As stated in [ID-alto-protocol5], the ALTO Endpoint Cost response
   syntax is:

      HTTP/1.1 200 <StatusMsg>

      Content-Length: <BodyLength>

      Content-Type: application/alto



      <ALTOResponse>

   Like for the request, the identifiers correspond to endpoints.

3.1.2.  Example of MC-ALTO extensions

   In the present MC-ALTO example, the ALTO Endpoint Cost Lookup request
   is issued by an ALTO client embedded in a mobile client, to order a
   list of peers, w.r.t. their routing cost.  Some of the peer endpoints
   can also be in mobile devices.

   The MC extension of the ALTO transaction in this case consist in
   specifying the mobile peers not only by their IP address, but also by
   3GPP identifications such as the International Mobile Subscriber
   Identity (IMSI) and location identifiers such as those described in
   sections 3.1.2.1 and 3.1.2.2 below.

3.2.  3GPP Cost Map Specifications

   The 3GPP ALTO Endpoint Cost lookup request must carry the parameters
   that identify and locate the mobile endpoints.



El Mghazli, et al.       Expires April 26, 2011                 [Page 8]


Internet-Draft              alto-mobile-core                October 2010


3.2.1.  3GPP Registration, Location and Routing Areas

   [3GPP.23.002] describes how the 3GPP Location management works.  It
   involves the following functions:

   o  HLR (Home Location Register): The HLR is a database that holds
      information concerning the subscribers.  It performs the following
      functions:

      *  handling of permanent subscriber data (identification,
         subscription information, service limitation)

      *  handling of temporary subscriber data:

         +  current Visitor Location Register (VLR), SGSN addresses
            where the subscriber roams

         +  security information

      *  dialogue with the AuC (Authentication Center) database

   o  VLR (Visitor Location Register): The VLR contains all the
      subscriber data required for call handling and other purposes for
      mobile subscribers currently located in the area controlled by the
      VLR.  The VLR supports a mobile paging and tracking subsystem in
      the local area where the mobile is presently roaming.

   Several area types have been defined in UMTS to handle user mobility:

   o  Location Area (LA):

      *  a LA contains a group of cells, each cell belonging to one LA,

      *  LAs are used by the Core Network Circuit Switched domain to get
         information on the user location when in the idle mode,

      *  a LA consists of a number of cells belonging to the RNCs that
         are connected to the same CN node, i.e. one 3G_MSC/VLR,

      *  the mapping between one LA and the RNCs is handled within the
         MSC/VLR covering this LA.

   o  Routing Area (RA):

      *  an RA contains a group of cells, each cell belonging to one RA,

      *  RAs are used by the Core Network Packet Switched domain)to get
         information on the user location when in the idle mode,



El Mghazli, et al.       Expires April 26, 2011                 [Page 9]


Internet-Draft              alto-mobile-core                October 2010


      *  one RA consists of a number of cells belonging to RNCs that are
         connected to the same CN node, i.e. one 3G_SGSN,

      *  the mapping between one RA and RNCs is handled within the SGSN
         owning this RA.

   o  UMTS Registration Area (URA): when the User Equipment (UE) is in
      connected mode and is using common and/or shared channels, the
      network can locate it on the cell basis or on the URA basis,
      depending on its level of activity and mobility.

   o  Service Area (SA): one SA may consist of one country, be a part of
      a country or include several countries.

3.2.2.  3GPP User Identification and location

   The 3GPP ALTO query must contain the data and procedures which
   unambiguously and securely identify the mobile user.  These functions
   are typically embedded in a stand alone smart card.  This device is
   associated with a given user, and as such allows to identify this
   user regardless of the ME (Mobile Equipment) he uses.

   The USIM card (UMTS Subscriber Identity Module card) allows the
   identification of any mobile subscriber (MS) by the network.  In
   particular, a subscriber can borrow any mobile without changing
   anything from the network point of view since she keeps the same
   USIM-card.

   The USIM card contains the following information:

   o  the International Mobile Subscriber Identity (IMSI);

   o  the Mobile Station International ISDN Number (MSISDN);

   o  the preferred language and the UE options;

   o  the secret key K, for the security procedures;

   o  the ciphering and integrity algorithms, that are part of the
      security system;

   o  the temporary mobile subscriber identities for PS and CS domains
      (TMSI and P-TMSI);

   o  the location and routing area identities: LAI and RAI;

   o  the forbidden networks list;




El Mghazli, et al.       Expires April 26, 2011                [Page 10]


Internet-Draft              alto-mobile-core                October 2010


   o  the services list (CS and PS domain).

   A unique IMSI is allocated to each subscriber MS in the UMTS system
   and is composed of three parts:

   1.  The Mobile Country Code (MCC) identifies uniquely the country of
       domicile of the MS.

   2.  The Mobile Network Code (MNC), identifies the home GSM PLMN of
       the MS.

   3.  Mobile Subscriber Identification Number (MSIN) identifying the MS
       within a GSM PLMN.

   The National Mobile Subscriber Identity (NMSI) consists of the MNC
   and the MSIN.

   In order to support the subscriber identity confidentiality service,
   the VLRs and SGSNs may allocate Temporary Mobile Subscriber
   Identities (TMSI) to visiting MSs.  The VLR and SGSNs must be capable
   of correlating an allocated TMSI with the IMSI of the mobile UE to
   which it is allocated.

   A UE may be allocated two TMSIs, one for services provided through
   the MSC, and the other for services provided through the SGSN (P-TMSI
   for short).


4.  IANA Considerations


5.  Security Considerations


6.  Acknowledgements


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [3GPP.23.002]
              3GPP, "Network architecture", 3GPP TS 23.002 3.6.0,



El Mghazli, et al.       Expires April 26, 2011                [Page 11]


Internet-Draft              alto-mobile-core                October 2010


              September 2002.

   [ID-alto-protocol5]
              ""ALTO Protocol" draft-ietf-alto-protocol-05.txt",
              July 2010.


Authors' Addresses

   Yacine El Mghazli (editor)
   Alcatel-Lucent Bell Labs France

   Email: yacine.el_mghazli@alcatel-lucent.com


   Sabine Randriamasy (editor)
   Alcatel-Lucent Bell Labs France

   Email: Sabine.Randriamasy@alcatel-lucent.com


   Francois Taburet
   Alcatel-Lucent Bell Labs France

   Email: francois.taburet@alcatel-lucent.com


























El Mghazli, et al.       Expires April 26, 2011                [Page 12]


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