Network Working Group Y. El Mghazli, Ed. Internet-Draft S. Randriamasy, Ed. Intended status: Standards Track Alcatel-Lucent Bell Labs France Expires: April 21, 2011 F. Taburet Alcatel-Lucent Bell Labs October 18, 2010 ALTO in Mobile Core draft-randriamasy-alto-mobile-core-00 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 21, 2011 [Page 1] Internet-Draft alto-mobile-core October 2010 This Internet-Draft will expire on April 21, 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 21, 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 . . . . . . . . . . . . 5 2.3. Scenario and use case . . . . . . . . . . . . . . . . . . 6 3. Example: ALTO usage in 3GPP framework . . . . . . . . . . . . 7 3.1. 3GPP Registration, Location and Routing Areas . . . . . . 7 3.2. ALTO messages . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. 3GPP Path Ranking Query/Response . . . . . . . . . . . 8 3.2.2. 3GPP Cost Map Specifications . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 El Mghazli, et al. Expires April 21, 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: El Mghazli, et al. Expires April 21, 2011 [Page 4] Internet-Draft alto-mobile-core October 2010 +-------------------------------------------------------------------+ | Mobile Core Operator | | | | | | +-----------+ +---------+ +--------+ | | | | | ALTO | ALTO Protocol | ALTO | | | | HLR/VLR |.......| Server | ---------------- | Client | | | | | +---------+ +--------+ | | +-----------+ / | | | ALTO SD Query/Response | | | / | | | +-----------+ +----------+ | | | ALTO | | P2P | | | Service | | tracker | | | | Discovery | +----------+ | | +-----------+ | | | | Figure 1: Mobile Core-ALTO integrated architecture | +-------------------------------------------------------------------+ 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 (MC) ALTO Servers is restricted to the MC. One option is the MC ALTO Servers communicate with ALTO Servers managed by the same ISP but located and reporting on the ISP Core network. 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 El Mghazli, et al. Expires April 21, 2011 [Page 5] Internet-Draft alto-mobile-core October 2010 of attaches Endpoints. 2.3. Scenario and use case Mobile Core ALTO integration is illustrated with the use case where: an ALTO client is embedded in the client, the endpoints 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. .---------. .---------------. | | | | | ALTO | (2) Get Path Ranking | 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) and its coordinates in the Mobile network. 3. The P2P Client connects to the peers in the order specified in the ranking. Do note that there may be an alternative way to integrate ALTO services into Mobile Core networks, where a P2P application that El Mghazli, et al. Expires April 21, 2011 [Page 6] Internet-Draft alto-mobile-core October 2010 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: ALTO usage in 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 Ranknig service. Such informaiton 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. 3GPP Registration, Location and Routing Areas [3GPP.23.002] describes how works the 3GPP Location management. 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 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: El Mghazli, et al. Expires April 21, 2011 [Page 7] Internet-Draft alto-mobile-core October 2010 o Location Area (LA): * an LA contains a group of cells, each cell belonging to one LA, * LAs are used by the Core Network (CS domain) to get information on the user location when in the idle mode, * 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 owning 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 (PS domain) to get information on the user location when in the idle mode, * 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 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. ALTO messages 3.2.1. 3GPP Path Ranking Query/Response Below is the format of the ALTO Endpoint Ranking Query message, as described in [ID-alto-protocol5] . It says the Query message from the ALTO Client MUST follow one of the forms described in the document. The ALTO Query message allows an ALTO Client to query for costs amongst an arbitrary set of sources and destinations. Here, the ALTO Path Rating Lookup query message is used by mobile users to order the list of peers gathered by the P2P network itself (e.g. from a P2P tracker). It follows the form that allows an ALTO Client query for costs from a single Endpoint or PID to all other El Mghazli, et al. Expires April 21, 2011 [Page 8] Internet-Draft alto-mobile-core October 2010 PIDs. Method : 'POST' URI Path : '/cost/m' URI QS Params : 'type=[costtype]' 'mode=[costmode]' 'constraint=[constraint]' Headers : Body : As stated in [ID-alto-protocol5], the ALTO Path Ranking Response message MUST follow: Status Code includes: '200' if all PIDs specified in request are valid, or no PIDs are specified in request. '404' if at least one PID specified in request is not valid. '501' if specified cost type is not supported '501' if constraints not supported but are included Headers : 3.2.2. 3GPP Cost Map Specifications The 3GPP ALTO Path Ranking Query must carry the parameters that identify and locate the mobile user. These parameters are described in Section 3.2.2.1 3.2.2.1. User Identification 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. El Mghazli, et al. Expires April 21, 2011 [Page 9] Internet-Draft alto-mobile-core October 2010 The USIM card (UMTS Subscriber Identity Module card) allows the identification of any mobile subscriber (MS) by the network. In particular, the subscriber can borrow any mobile without changing anything from the network point of view since he 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; 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. El Mghazli, et al. Expires April 21, 2011 [Page 10] Internet-Draft alto-mobile-core October 2010 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, 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 El Mghazli, et al. Expires April 21, 2011 [Page 11] Internet-Draft alto-mobile-core October 2010 Sabine Randriamasy (editor) Alcatel-Lucent Bell Labs France Phone: Fax: Email: Sabine.Randriamasy@alcatel-lucent.com URI: Francois Taburet Alcatel-Lucent Bell Labs Email: francois.taburet@alcatel-lucent.com El Mghazli, et al. Expires April 21, 2011 [Page 12]