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 HTTP/1.1 Host: Content-Length: 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 Content-Length: Content-Type: application/alto 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]