FMC Working Group C. Xie Internet-Draft Q. Sun Intended status: Informational China Telecom Expires: April 25, 2013 October 22, 2012 Use Cases and Requirements in Fixed Mobile Convergence draft-sun-fmc-use-case-01 Abstract This document provides a brief review of use cases in FMC (Fixed Mobile Convergence) architecture from operational point of view. It also provides technical requirements and problems which need be resolved in IETF. It is complementary to the existing problem statement and requirements documents. 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 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 April 25, 2013. Copyright Notice Copyright (c) 2012 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 Xie & Sun Expires April 25, 2013 [Page 1] Internet-Draft FMC use case October 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use case 1: Unified User Identification . . . . . . . . . . . 3 3. Use case 2: Unified QoS provisioning capability . . . . . . . 5 4. Use case 3: Seamless handover for VPDN tunnel . . . . . . . . 6 5. Use case 4: Mobility . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Xie & Sun Expires April 25, 2013 [Page 2] Internet-Draft FMC use case October 2012 1. Introduction In the FMC (Fixed Mobile Convergence) architecture, the major FMC could be devided into several aspects, which are the converged business and service, converged infrastructure and network, and converged user management. The fundamental principle of FMC all starts from the consumers. With a multitude of devices to fit different personal preference, multi heterogeneous networks including fixed, 3GPP, WiFi, etc., and different business models in practice, people are getting more and more confused on how to make the decision to choose their subscriber-id, access network, etc. The customer needs a life without barriers. The converged business will provide the customer with a uniform policy and user experience. It can be seamlessly and intuitively accessible across all devices and all networks. The converged network and infrastructure will reduce the CAPEX and OPEX for operators, and incur minimal additional costs with the ever-changing business model. The converged user management and terminals will offer a more simple and convenient user experience, which will deliver broadband connectivity and standardized multimedia services to a wide range of devices, including media servers, video cameras, portable media players, PCs and mobile phones. While BBF and 3GPP has done a lot of work on architecture model, interface definition, etc., protocol standardization work should still be undertaken in IETF which is acceptable to all parties and cultivates a common ecosystem based on Internet protocol architecture. The purpose of this document is provides the use cases in FMC ecosystem, together with some technical requirements and problems which need be resolved in IETF process. Some issues have been taken by some existing WGs in IETF, and some can be applied but not specific to FMC scenario. Our purpose can be regarded as a motivation to encouraging those working items to be standardized in IETF. 2. Use case 1: Unified User Identification Consider a device of the subscriber accessing a network has to be authorised and authenticated as well as to assure reliability of the service,the device must be able to identified and recognized as the first step. That means that the identity of the device must be transferred and acknowledged. In addition, a unique identity has to Xie & Sun Expires April 25, 2013 [Page 3] Internet-Draft FMC use case October 2012 be transferred or assigned to the device to maintian the device management. In real network,ISP assign a subscriber-id to the subscriber always. One subscriber may have multiple devices, including PC, mobile phones, ipad, etc., and may seamlessly cross multiple heterogeneous networks. The subscriber can not only use this subscriber-id to access the network, but also share the subscription between multiple devices. ISP could assign an ID to the customer, any of the devices belonging to the customer can achieve the authentication progress. The cumtomer can use this subcriber-id to connect the same service applications (operator's service or third-party service) without additional appliance. The devices of the same subscriber should be managed in a group. This group could be identified by a identification.With this unified identication, the customer can log in different application systems with a single access control. Besides, operators and content providers can apply the unified access policy, accounting policy, etc., to the customer for the specific set of devices, as illustrated in Figure 1 below. Subscriber A have three device, X, Y, Z +---------------+ | | | Subscription | +------------------------+ +---------------+ +-------+ | | | | | | | Phone | | Cellular | +-------+ | *---------------+ | | -+- | | / \ | | / \ +-------+ +------------------------+ | | | | | ISP. | | Phone | +------------------------+ | | +-------+ | | \ / | | \ / | WiFi | -+- +-------+ | *---------------+ | | | | | Pad | | | +-------+ | | +------------------------+ Figure 1 Potencial Technical Issues: Xie & Sun Expires April 25, 2013 [Page 4] Internet-Draft FMC use case October 2012 The Device Identifier, such as ISIM, MAC address, IP address etc, is used to indicate each individual device or host for the customer. Currently, IP address can be regarded as a device Identifier from the network layer. However, these identifiers are difficult to be kept consistently with NAT/CGNs(Carrier Grade Network Address Translation) along the path. Addional techniques (e.g. Host_ID, ID/Locator split, Device ID mapping to the network information,etc.)should be introduced to guarantee that a unique device Identifier will not be modified heterogeneous network environment. Additionally, there is no suitable certain identifier by means of group the customer's devices for unified control and management. . The group identifier for the devices should be introduced. Based on this kind of identifier, the operator can provide unified policy control on the user-level, irrespective of the devices .It provides a business case with unified subscriber management, policy control, single sign-on for applications, etc. 3. Use case 2: Unified QoS provisioning capability A customer was firstly watching TV with a smart phone on his way home, and the video stream is smooth. When he arrives home, he switches the same TV channel to the television screen and keep watching. This user experience should not decrease due to the handover between different devices, the QoS feature should remain consistent with customers' profile all the time, as illustrated in Figure 2 below. Xie & Sun Expires April 25, 2013 [Page 5] Internet-Draft FMC use case October 2012 +-------+ | | | Phone | +------------------------+ +-------+ | | | | | | | Cellular | | | *---------------+ V | | -+- Moving | | / \ | | / e.g. \ +-------+ +------------------------+ | Cloud | | | | Internet +--+ Phone | +------------------------+ | | | +-------+ | | \ / | | | \ / |APP mobility | WiFi | -+- | +-------+ | *---------------+ +--> | | | | CPE | | | +-------+ | | +------------------------+ Figure 2 In this scenario, different devices will have the special requirement on display resolution, codec, etc. Addtionally, different networks will also have alternative ways to achieve these requirements.Moreover, content providers may provide differentiated service for subscribers. When a customer roams from one network to another, or from one device or another, the user QoS priority should still be treated uniformly in Content Provider/ Service Provider (CP/SP), including bandwidth guarantee, Content Distribution Network (CDN) policy, etc. Potential Technical Issues: 1. QoS mapping: Unified user experience can only be achieved when heterogeneous networks interpret QoS parameters uniformly, which is based on the identification of the user. 2. User identification: CP/SP should support to identify the subscribers across different devices and heterogenous network. 4. Use case 3: Seamless handover for VPDN tunnel A virtual private dial-up network (VPDN) is a network that extends remote access to a private network using a shared infrastructure, Xie & Sun Expires April 25, 2013 [Page 6] Internet-Draft FMC use case October 2012 VPDN allows individual users to connect to a remote network such as roaming sales people connecting to their company's intranet. VPDNs use Layer 2 tunnel technologies (L2F, L2TP, and PPTP) to extend the Layer 2 and higher parts of the network connection from a remote user across an ISP network to a private network. Sometimes, in order to ensure the confidentiality of the data sent to an remote user, IPsec is used to setup a secure tunnel from the VPDN Client to a central router. However, when the user roams from one access point to another one,the network needs to provide a seamless remote access during handover. Potential Technical Issues: The issues that should be tackled in this case include device feature identification, seamless handover between different secure tunnels,Qos mapping, etc. Currently, a possible solution is Mobike [RFC4555], which allows the IP addresses of the tunnel endpoints in IPsec tunnel mode to change. However, this solution has a "NAT prohibition" feature which can be used to ensure that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. Besides, other kinds of VPDN should also be solved in seamless handover case. 5. Use case 4: Mobility Mobility is one of the most important items which should be considered in FMC work. We introduce two mobility usecases here, one is mobility between different access technologies (WiFi and 3GPP), and the other is mobility in WiFi scenario, such as between APs, as illustrated in Figure 3 below. Xie & Sun Expires April 25, 2013 [Page 7] Internet-Draft FMC use case October 2012 +-------+ | | | Phone | +------------------------+ +-------+ | | | | | | | Cellular | | | *---------------+ V | | -+- Moving | | / \ | | / e.g. \ +-------+ +------------------------+ | Cloud | | | | Internet | Phone | +------------------------+ | | +-------+ |+----+ | \ / | || AP | | \ / v |+----+ WiFi | -+- +-------+ | *---------------+ | |+----+ | | Phone | || AP | | +-------+ |+----+ | +------------------------+ Figure 3 Customer service should be guaranteed during the switch between one access network to another. For example, customer's call or video service shouldn't be interrupted when moving from 3GPP access to WiFi access techonology. Even more we can see all the services depends on the substantive of customer's profile. Move, in the NAT scenario, we need identification for UE behind NAT. It is important to confirm the device identification binding or updated accordingly for the same UE which is moving. It isn't in the scope of mobility protocol. Additionally, WiFi is one of the most important access technology for operators, it is possible that customer is playing video in the bus via WiFi. The mobility between APs,and in AP overlap area must be considered. Even more, wherever the device access to the service via WiFi, such as at home or in the hotspot, or even roaming to another WiFi operator's network, the QoS and service experience should be uniform. Potential Technical Issues: 1. In order to provide uniform policy control, the device identification should be uniform or transferred during the device mobility. This is the specical requirement for UE identifier. Xie & Sun Expires April 25, 2013 [Page 8] Internet-Draft FMC use case October 2012 2. When the service application from one device to another deivce of a subscriber, the uniform QoS and service experience should be guaranteed, even between different access networks. Based on this requirement, PMIP and MIP can not achieve the QoS uniform during mobility. Additional mechine is needed. 3. In the scenario of WiFi, the service QoS and experience between different APs should be guanrantted during device mobility. In this case, the WiFi connection status and the subscriber information should be tracked during mobility. 6. IANA Considerations 7. Security Considerations TBD 8. Acknowledgements TBD 9. References 9.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 9.2. Informative References [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, Xie & Sun Expires April 25, 2013 [Page 9] Internet-Draft FMC use case October 2012 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Authors' Addresses Chongfeng Xie China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China Email: xiechf@ctbri.com.cn Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China Email: sunqiong@ctbri.com.cn Xie & Sun Expires April 25, 2013 [Page 10]