Network Working Group S. Durel Internet-Draft France Telecom Expires: December 14, 2012 H. Moustafa Orange Labs R. Schott Deutsche Telekom June 12, 2012 Requirements on Fixed Mobile Convergence draft-schott-fmc-requirements-01 Abstract This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. 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 December 14, 2012. 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Durel, et al. Expires December 14, 2012 [Page 1] Internet-Draft FMC Requirements June 2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Caution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements on UE Identification . . . . . . . . . . . . . . 3 4.1. Recommendations . . . . . . . . . . . . . . . . . . . . . 5 5. Requirements for Access Selection . . . . . . . . . . . . . . 5 5.1. Recommendations . . . . . . . . . . . . . . . . . . . . . 5 6. Requirements on UE Mobility in Fixed Broadband Network . . . . 5 7. Requirements for Content Adaptation . . . . . . . . . . . . . 6 7.1. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 8. Requirements for Streaming . . . . . . . . . . . . . . . . . . 6 8.1. Personalization of Video Streaming Service . . . . . . . . 6 8.1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 6 8.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 12.2. Informative references . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Durel, et al. Expires December 14, 2012 [Page 2] Internet-Draft FMC Requirements June 2012 1. Introduction 2. Terminology 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]. 3. Caution This document is a working tool to help assessing whether additional specification effort is required within IETF. As such, it is not the intent of this document to become an RFC but be the privileged place to analyze claimed technical issues and their requirements. This document is not by any means voicing for creating a new working group. Technical items identified in the document are judged as potential items which may require conducting specifying effort within IETF. These items are relevant to particular use cases. These use cases and associated requirements should be challenged by FMC List participants. Some of these technical items are already covered by some exiting IETF WGs. This document may also be perceived as a motivation document to encourage advancing those items in the standardization process. 4. Requirements on UE Identification A popular deployment model in fixed networks is to provide a host with a single private IPv4 address at the home LAN or small business LAN. For instance, each host within the local network will be assigned a private IPv4 address, then NA(P)T function is responsible for translating the private IPv4 address to the public IPv4 address assigned to the CPE (Customer Premises Equipment). In addition, a CPE can be configured to offer a shared WiFi to visiting hosts (also called UEs (User Equipments)) which do not belong to the subscriber (owning the CPE). A visiting UE uses that shared WiFi facility to access its services. Granting access to the service is usually conditioned by an access control phase (e.g., redirection to captive portal inviting the user to authenticate). Once access to the service is granted, the visiting UE can be Durel, et al. Expires December 14, 2012 [Page 3] Internet-Draft FMC Requirements June 2012 delivered its services. Among various schemes to offer shared WiFi service, operators may decide to re-use the NAT function embedded in the CPE to route the traffic issued from the visiting UE. It is out of scope of this document to argue in favor or against this deployment model but to describe an issue which must be solved whenever this model is adopted. Indeed, when the traffic of a visiting UE is multiplexed behind the same public IP address, upstream devices won't be able to distinguish the traffic issued from a visiting UE than the one issued by devices belonging to the subscriber owning the CPE. This traffic identification is required to enforce dedicated policies (e.g., Accounting, QoS policies, legal intercept, legal data storage, etc.). As a result, and in order for the operator to still support traffic management for this service, policy control/decision/enforcement MUST be based on a per-UE granularity: i.e., traffic belonging to a visiting UE MUST be explicitly identified. The HOST_ID, introduced in [I-D.ietf-intarea-nat-reveal-analysis], jointly with the external IP address are necessary to uniquely identify the traffic of a given visiting UE. An implementation example would be the use of port sets as HOST_ID. To illustrate this example, let's consider the CPE assigns a private IPv4 address and a set of ports to a visiting UE. Then, the CPE reports the assigned port set to a service node together with other information such as external IPv4@, MAC@, etc. This information will be correlated with the user_id provided during the authentication phase. The CPE will use that port set for NAPTing packets from that visiting UE. The set of ports (assigned by the CPE) and the external IP address (assigned to the CPE) are then sufficient to uniquely identify a UE. The reporting phase can be avoided if the CPE is pre- configured with a static list of port sets to be used for visiting UEs. The use of port sets and other methods to explicitly identify a visiting UE are identified and discussed in [I-D.ietf-intarea-nat- reveal-analysis]. In order to ease the selection of the appropriate HOST_ID solution for the FMC case, below are listed a set of requirements to be met: o All traffic MUST be identified (including TCP, UDP and ICMP) o The UE SHOULD NOT be trusted to inject its own HOST_ID o The CPE SHOULD inject the HOST_ID Durel, et al. Expires December 14, 2012 [Page 4] Internet-Draft FMC Requirements June 2012 o The CPE SHOULD strip any exsiting HOST_ID o The CPE and the service node MUST support at least one common method to convey HOST_ID. 4.1. Recommendations We recommend dedicated efforts to specify a mechanism to reveal HOST_ID in this specific use case. A solution analysis document would help. 5. Requirements for Access Selection Multiple access environment requires clever choice of the access network (cellular, mobile, VPN,...). this selection should depend on different criteria such as user's preference, user profile, network capabilities and conditions, operator policies, application QoS requirements and so on. 5.1. Recommendations Monitoring mechanisms MUST exist allowing the collection of QoS information for each access network type.The network status needs to be known through: knowing the available bandwidth for each type of available network and the cost of using each type of available network, QoS information for each access network type. Policies access selection SHOULD be possible. A mapping between the network status and the service requirements needs to exist to choose the network that best matches the service requirements. Management of user's access in the presence of several candidate access networks (fixed and mobile) needs to exist. 6. Requirements on UE Mobility in Fixed Broadband Network The following are the requirements on UE Mobility in Fixed Broadband Network: o The switch from one network to another MUST exist during the session according to the network status with the change in the UE attachment. Durel, et al. Expires December 14, 2012 [Page 5] Internet-Draft FMC Requirements June 2012 o Mechanisms and interfaces between operators SHOULD be deployed to control the mobility of the traffic flows of their users. o Mobility should be enabled even in AP overlapped area o Differentiated Services for the mobile device or the Station (STA) o Service guarantee when roaming or mobility o Resiliency in the network nodes should be provided 7. Requirements for Content Adaptation In this case, adaptation of content format (HD/SD, codec, .) SHOULD be possible when delivering the same content (e.g. video streaming) regardless of the access network type and of the terminal (User Equipment 'UE") characteristics. 7.1. Recommendations To be able to meet above high level requirement, the content adaptation function needs to: 1. identify the user connection through identifying each UE in a separate manner. The UE identity needs to be updated during the session each time a new terminal is used. The characteristics of each UE being used needs to be known also (e.g. supported resolution, screen size, available network connectivity "WiFi, 3G, .." and the cost of using each type of available networks). 2. distinguishing the UE and the CPE identification (MOTIVATION?). 3. rely on service layer monitoring (for instance through MPEG2 layer monitor for video content) SHOULD exist to choose the network best matching the service requirements. 8. Requirements for Streaming An additional case is the Personalization of Video Streaming Service. 8.1. Personalization of Video Streaming Service 8.1.1. Discussion The explosion of streaming services (across multiple screens, connected devices) triggers the need for video streaming service personalization and makes users looking for rich Quality of Experience (QoE). The personalization of the video streaming service allows the video streaming content delivery in a customized manner considering each user, the used device and the network status through Durel, et al. Expires December 14, 2012 [Page 6] Internet-Draft FMC Requirements June 2012 mainly: i) the choice of the delivery network (fixed or mobile), ii) the choice of the local access network at home (WiFi, Femto, ADSL, .), iii) the choice of the delivery mode (unicast, multicast, delivering content from the one server or from caches, ..) iv) the choice of the content format (HD/SD, codec, .). Consequently, the video streaming content can follow the user from terminal to terminal regardless of the access network type and of the terminal (User Equipment 'UE") characteristics. This requires on one hand technical solutions to allow the selection of the appropriate interface to be used by the UE. As the UE would not have the whole image of the congestion status of the network (and also it would always privilege its own quality regardless of the cost of network use by the operator), these solutions need to be triggered by the network and/or the service domains and not at the UE side. The case of premium clients could be also considered that should have more QoS access (i.e. more bandwidth) and then the decision on the network choice needs to be decided by the operator. To be able to select the appropriate network and adapt the content according to the network status there is a need for knowledge (in a dynamic manner during the session) on the network status and its variation to be able to adapt the content in a dynamic manner also during the session (for example, a session that started with HD content could change to SD if the network conditions degrades). On the other hand, there is a need for updating the content according to the UE capabilities. The current adaptive streaming solutions (as the HAS: HTTP Adaptive Streaming) mainly count on the UE for selecting the suitable content. However, if this happens at the content source opposite to the HTTP adaptive streaming techniques currently existing, it would only send the appropriate content for each client and save network resources (for example, H.264/AVC video is encoded into 2 Mbps for SD and 6Mbps for HD). A mapping between the network status and the service requirements is also needed, where the service requirements are mainly exhibited by the content source (owned by the Content provider or the service provider). It could also be extracted from the content Metadata. To be able to realize such use-case, the following requirements need Durel, et al. Expires December 14, 2012 [Page 7] Internet-Draft FMC Requirements June 2012 to be met: o Each user connection MUST be identified through identifying each UE in a separate manner and distinguishing the UE and the CPE identification. The UE identification could be simply an NFC identifier, MAC identifier, ... associated with more information reflecting the UE characteristics. o Monitoring mechanisms MUST exist allowing the collection of QoS information for each access network type. o Service layer monitoring (for instance through MPEG2 layer monitor for video content) SHOULD exist to choose the network best matching the service requirements. o The switch from one network to another MUST exist during the session according to the network status with the change in the UE attachment. o Mechanisms and interfaces between operators SHOULD be deployed to control the mobility of the traffic flows of their users. 8.2. Recommendations The IETF SHOULD dedicate efforts to consider several issues related to the UE and also to the network status as follows: 1. Each UE needs to be identified in a fine-grained manner and the UE identity needs to be updated during the session each time a new terminal is used. The characteristics of each UE being used needs to be known also (e.g. supported resolution, screen size, available network connectivity "WiFi, 3G, .." and the cost of using each type of available networks). 2. The network status needs to be known through: knowing the available bandwidth for each type of available network and the cost of using each type of available network, QoS information for each access network type. 3. A mapping between the network status and the service requirements needs to exist to choose the network that best matches the service requirements. 9. Security Considerations This document focuses on FMC requirements and the interworking of "WiFi, 3G, etc..." and should not rise to any new security vulnerabilities beyond those described in IPSec [RFC4301], TLS [RFC5246] or SRTP [RFC3711]. Nevertheless an open network architecture is described in this document probably causing new issues not foreseeable yet. Durel, et al. Expires December 14, 2012 [Page 8] Internet-Draft FMC Requirements June 2012 10. IANA considerations None. 11. Acknowledgements Contributions, comments, discussions, and remarks provided by Mohamed Boucadair and Pierrick Seite are gratefully acknowledged. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [TS29.212] "3GPP TS29.212, Policy and Charging Control (PCC) over Gx/Sd reference point", December 2011. [TS23.203] "3GPP TS23.203, Policy and Charging control architecture", December 2011. [TR23.829] "3GPP TR23.829, Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)", October 2010. 12.2. Informative references [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", Durel, et al. Expires December 14, 2012 [Page 9] Internet-Draft FMC Requirements June 2012 RFC 2663, August 1999. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [I-D.so-ipsecme-ikev2-cpext] So, T., "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", draft-so-ipsecme-ikev2-cpext-01 (work in progress), February 2012. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011. [WT146] "Broadband Forum Working Text WT-146, Subscriber Sessions", June 2011. [I-D.ietf-intarea-nat-reveal-analysis] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", draft-ietf-intarea-nat-reveal-analysis-02 (work in progress), April 2012. [WT203] "Broadband Forum Working Text WT-203, Interworking between Next Generation Fixed and 3GPP Wireless Access", December 2011. [samog] "3GPP TR 23.852 V1.0.0, Study on S2a Mobility based On GTP & WLAN access to EPC (SaMOG) (Release 11)", December 2011. [ieee802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2008", 2008. Durel, et al. Expires December 14, 2012 [Page 10] Internet-Draft FMC Requirements June 2012 Authors' Addresses Sophie Durel France Telecom Rennes, 35000 France Phone: Email: sophie.durel@orange.com Hassnaa Moustafa Orange Labs Issy-Les-Moulineaux, France Phone: Email: hassnaa.moustafa@orange.com Roland Schott Deutsche Telekom Darmstadt, 64295 Germany Phone: Email: Roland.Schott@telekom.de Durel, et al. Expires December 14, 2012 [Page 11]