Network Working Group S. Durel Internet-Draft France Telecom Expires: March 25, 2013 H. Moustafa Orange Labs R. Schott Deutsche Telekom C. Perkins Futurewei September 21, 2012 Requirements for Fixed Mobile Convergence draft-schott-fmc-requirements-03 Abstract Fixed-mobile convergence encompasses a variety of use cases that include situations in which a wireless device travels between a point of attachment in a mobile network (such as a cellular base station) and another point of attachment anchored in a fixed network such as a WiFi hotspot. Convergence then means enabling an end-user to access services or retrieve content whatever the network access conditions (e.g., fixed or mobile access infrastructure), and whether the end- user is in motion or not. This document discusses the issues related to convergence and elaborates a set of requirements. 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 March 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Durel, et al. Expires March 25, 2013 [Page 1] Internet-Draft FMC Requirements September 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Caution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 5. Requirements for MN Identification behind a CPE with NAT . . . 7 5.1. Recommendations for MN Identification behind NAT . . . . . 8 6. Requirements for MN Mobility in Fixed Broadband Network . . . 9 7. Requirements for Link Characteristic Information . . . . . . . 9 7.1. Adaptive Application and Services . . . . . . . . . . . . 10 7.2. Network-Initiated Handover . . . . . . . . . . . . . . . . 10 7.3. End-to-End path characteristics . . . . . . . . . . . . . 10 7.4. Requirements for Link and Sub-Path Information delivery . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative references . . . . . . . . . . . . . . . . . . 11 Appendix A. Requirements for Content Adaptation . . . . . . . . . 14 A.1. Recommendations for Content Adaptation . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Durel, et al. Expires March 25, 2013 [Page 2] Internet-Draft FMC Requirements September 2012 1. Introduction With network heterogeneity and huge demand of multimedia and audio- visual services and applications as a given, users' satisfaction is the aim of each service provider to reduce churn, promote new services and improve the ARPU (Average Revenue per User). The market is crowded. Many players provide Internet and entertainment services, which motivates new business models considering users' experience and considering roaming agreement between different operators. The new expectation for users' consumption style focuses on personalized and interactive usage. This allows users on one hand to share content across many devices and with other users, but on the other hand to access all content seamlessly at the touch of a button. Consequently, Quality of Experience (QoE) has become a crucial determinant of the success or failure of the multimedia and audio- visual applications and services. QoE evaluates the users' perceived quality for the provided services and hence reflects the users' satisfaction. Regarding QoS, 3GPP has made architectural definitions as described in [TS23.203] and [TS29.212]. IETF has also described how QoS can be achieved over IP [RFC5865]. Various meanings can be ascribed to the term Fixed-Mobile Convergence. It is not the intention of this document to give a complete definition regarding business and technical aspects. Fixed- mobile convergence has recently been used to include various use cases in which a wireless device travels between a point of attachment in a mobile network (such as a cellular base station) and another point of attachment anchored in a fixed network such as a WiFi hotspot. [samog]Convergence refers to a perceived unification of the service level available to applications which is, to the extent feasible, independent of the nature of the underlying physical medium. This document discusses issues raised by convergence and elaborates a set of requirements based on the problem statement and use cases as discussed in [I-D.xue-intarea-fmc-ps] and [I-D.sun-fmc-use-case]. These use cases have been under discussion in BBF [WT203] and 3GPP [3GPP.22.278] respectively [3GPP.22.234]. The requirements discussed in this document are meant to help the IETF community to decide whether it should take part of the corresponding effort or not. 2. Caution This document is a working tool to help assessing whether additional specification effort is required within IETF. Technical issues mentioned in this document are those which may require carrying out a Durel, et al. Expires March 25, 2013 [Page 3] Internet-Draft FMC Requirements September 2012 specification effort within IETF. The goal of this document to enable the analysis of technical issues and their requirements. These issues are relevant to particular use cases. The relevant use cases and associated requirements need thorough discussion. Some of these technical issues are already covered by some existing IETF WGs. This document may provide motivation to advance such items in the standardization process. 3. 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 specified in [RFC2119]. The following additional terms are used in this document. aggregation node The access network node which connects CPE and UE devices to the Internet. Codec Compression/Decompression of multimedia data using either a hardware device or software. CPE Customer Premises Equipment, that is equipment found in the customer's physical location and provided by the network operator or service providers. DSL routers, Set-Top-Box (STB), and decoders are examples of CPE. FMC Fixed Mobile Convergence means enabling an end-user to access services or retrieve content whatever the network access conditions (e.g., fixed or mobile access infrastructure), and whether the end- user is in motion or not. This includes also access conditions with this own service profile although having access by a 3rd party. host_id an identifier for the wireless device, as described in [I-D.ietf-intarea-nat-reveal-analysis]. Durel, et al. Expires March 25, 2013 [Page 4] Internet-Draft FMC Requirements September 2012 MN "Mobile Node"; a device that can move from one wireless point of attachment to another. Other standard documents use different terminology for the same idea, for instance "UE" (for User Equipment), or AT (for Access Terminal). NFC Identifier Near Field Communications identifier. Port set a defined set of ports; in this document "port set" is used as an example of a host_id. Each host under the same external IP address is assigned a restricted port set. These port sets may then be advertised to remote servers. Port sets assigned to hosts may be static or dynamic. SD Standard Definition for video using a standard resolution. HD High Definition for video using an enhanced resolution. 4. Architecture Overview In practice multiple scenarios like non-roaming or roaming and access via trusted or untrusted WLAN access are possible. To give a reference architecture we referring to [samog] and [ieee802.11]. The reference architecture describes how access to 3GPP via a GTP-based S2a and PMIP networks is possible. Requirements of the architecture are : REQ1: Access to EPC resources/services with access control by the operator REQ2: Seamless mobility between 3GPP and WLAN for EPS services with IP address preservation REQ3: Non-seamless mobility services between 3GPP and WLAN for EPS services: no IP address preservation REQ4: Support of UEs with single PDN connection; support of UEs with multiple PDN connections REQ5: Access to EPC via WLAN simultaneously with non-seamless WLAN offload General requirements for FMC are common service and subscriber profiles. Additionally common charging, operational and management procedures are also required. Additional requirements for IP traffic Durel, et al. Expires March 25, 2013 [Page 5] Internet-Draft FMC Requirements September 2012 offload are described in [TR23.829]. The benefit of using traffic offload is to save frequency range and to allow access in areas where cellular coverage is not available. For one, operators see a potential in simplifying their operational/ user support complexity, as well as harmonizing network element functionality around the IP protocol. Operators running multiple access networks also view IP service delivery as the key lowest common denominator towards delivering common services in a converged network. The service provider community have shown significant interest in migrating from a pure PPP access environment towards one with IP subscriber sessions for delivery of all IP broadband services in fixed networks [WT146]. With LTE respectively EPC the mobile networks are also introducing a pure all IP mobile broadband access. Probably in the end everything is mobile. One can also presume that everything is all IP having only agnostic access networks. For operating those networks appropriate enough IP address space [RFC6264] and security features like Internet Key Exchange Protocol Version 2 [RFC5996] respectively [I-D.so-ipsecme-ikev2-cpext] are required. The following figure is a brief overview how fixed and mobile networks could interwork: +---------+ +-----------+ +------+ | | | |------| TWAP |---| | +----------+ | WLAN | +------+ | 3GPP | | UE |------| ACCESS | | Home | +----|-----+ | Network | +------+ | Network | | | |------| TWAG |---| | | +-----------+ +---|--+ | | |-----------------------------------| +---------+ Trusted non - 3GPP WLAN Legend: UE User Equipment TWAG Trusted WLAN Access Gateway TWAP Trusted WLAN Access Proxy This FMC Architecture described in [samog]. Figure 1: FMC Requirement Architecture Durel, et al. Expires March 25, 2013 [Page 6] Internet-Draft FMC Requirements September 2012 5. Requirements for MN Identification behind a CPE with NAT A popular deployment model in fixed networks is to provide a host with a single private IPv4 address at the home or small business LAN. Then, each host within the local network will be assigned a private IPv4 address; a NA(P)T function [RFC2663] is responsible for translating the private IPv4 address to the public IPv4 address assigned to the CPE (Customer Premises Equipment). Similar address translation features are also present now in mobile environment; as one example, CPE can be connected to mobile infrastructures. IP address sharing is motivated by a number of different factors. And today, some servers use the source IPv4 address as an identifier to treat some incoming connections differently. Due to the use of NAT44 [RFC3022] and NAT64 [RFC6146]), that address will be shared. In particular, when a server receives packets from the same source address, because this address is shared, the server does not know which host is the sending host [RFC6269]. To be able to sort out the packets for each sending host, the server must have extra information in addition to the source IP address, to distinguish the sending host. This identifying information is called the "host_id". As a general matter, the HOST_ID proposals do not seek to make hosts any more identifiable than they would be if they were using a public, non-shared IP address. However, depending on the solution proposal, the addition of host_id information may allow a device to be fingerprinted more easily than it otherwise would be. Should multiple solutions be combined that include different pieces of information in the host_id, fingerprinting may become even easier. A set of solution candidates to mitigate some of the issues encountered when address sharing is used have been described and compared in [I-D.ietf-intarea-nat-reveal-analysis]. Among or aside this set of solutions, a mechanism will have to be recommended to supply host_id in the use cases described in Section 6 as well as in [I-D.xue-intarea-fmc-ps] and [I-D.sun-fmc-use-case]. A CPE can also be configured to offer a shared WiFi to any visiting host (also called Mobile Node, or simply MN) which does not belong to the subscriber (owning the CPE). A visiting MN 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 MN can receive its services. Business model considerations for such service offerings are out of scope for this document. Among various ways to offer shared WiFi service, operators may elect Durel, et al. Expires March 25, 2013 [Page 7] Internet-Draft FMC Requirements September 2012 to re-use the NAT function embedded in the CPE to route the traffic issued from the visiting MN. When the traffic of a visiting MN is multiplexed behind the same public IP address, upstream devices may be unable to distinguish the the traffic of the visiting MN from other traffic issued by devices belonging to the subscriber owning the CPE. This traffic identification may be 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 the specific MN. In other words, traffic belonging to a visiting MN MUST be explicitly identified. The host_id jointly with the external IP address can be used for this purpose. As one example, port sets can be used as a host-id. To illustrate, suppose the CPE assigns a private IPv4 address and a set of ports to a visiting MN. Then, the CPE can report the assigned port set to a aggregation node together with other information such as external IPv4 address, MAC address, etc. This information will be associated with the user-id provided during the authentication phase. The CPE then uses that port set for translating packets to and from that visiting MN. The set of ports (assigned by the CPE) and the external IP address (assigned to the CPE) are then sufficient to uniquely identify a MN. The reporting phase can be avoided if the CPE is pre- configured with a static list of port sets to be used for visiting MNs. The use of port sets and some other methods to explicitly identify a visiting MN is discussed in [I-D.ietf-intarea-nat-reveal-analysis], but many other methods of identification are also possible. 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 identifiable (including TCP, UDP and ICMP) o The MN SHOULD be authenticated if it injects its own host-id o Otherwise, the CPE SHOULD inject the host-id o The CPE SHOULD strip any existing host-id o The CPE and the aggregation node MUST support at least one common method to convey host-id. 5.1. Recommendations for MN Identification behind NAT We recommend dedicated efforts to specify a mechanism to supply host-id for MNs behind CPE and NAT. A solution analysis document for existing solution approaches would help. Durel, et al. Expires March 25, 2013 [Page 8] Internet-Draft FMC Requirements September 2012 6. Requirements for MN Mobility in Fixed Broadband Network The following are the requirements for MN Mobility in Fixed Broadband Network: o Handover between networks while the session is active according to the network status with the change in the MN attachment. o Mechanisms and interfaces between operators or/and access networks SHOULD be deployed to manage the mobility of the traffic flows of their users. o Mobility should be enabled whether or not coverage areas overlap. o Differentiated Services for the mobile device (MN) o Service guarantee when device is roaming or mobile o Resiliency in the network nodes should be provided 7. Requirements for Link Characteristic Information Today the MN e.g. smart phones are reachable through multiple interfaces and have the possibility to use these interfaces simultaneously. Thus roaming between different access technologies is required. Due to the fact that wireless access link is most likely the bottleneck of end-to-end communication causing a significant portion of end-to-end delay delivery of link respectively sub-path characteristic information from one MN to the other can be used to optimise IP mobility performance by altering the end-to-end path properties. Unfortunately, existing IP mobility, transport and application layer protocols do not provide any facility to indicate which type of link the MN is currently attached to or what kind of changes there were on the local access link. Local access link characteristic may also vary significantly as a result of handover between links on the same type (horizontal handovers) [I-D.korhonen-mobopts-link-characteristics-ps]. Existing mobility protocols do not provide a mechanism to indicate which type of link the MN is currently attached to. Therefore some new signalling mechanism is needed also avoiding the amount of signalling traffic load. The benefit of such signalling mechanism is to avoid complications to the IP transport and the service quality as many applications and congestion control mechanisms fail to respond fast enough if path characteristics change suddenly. Durel, et al. Expires March 25, 2013 [Page 9] Internet-Draft FMC Requirements September 2012 7.1. Adaptive Application and Services Adaptive applications benefit from standardised mechanisms that notifies abrupt changes of link characteristics [I-D.korhonen-mobopts-link-characteristics-ps]. Streaming service e.g. for video or music can adapt to the new connection conditions. Assuming that a mobile device can connect to the network using various access technologies and moves from macro cellular access to 802.11 WLAN an adaptive application could immediately scale the service in an appropriate manner. 7.2. Network-Initiated Handover In a FMC scenario the MN desires to handover to another access network possibility based on the required service quality or other reasons like administrative policies. With link characteristic information delivery mechanisms the network and the remote MN would have the knowledge to make these decisions. 7.3. End-to-End path characteristics To deliver link characteristic information, the MN has to get its access link characteristic dynamically [I-D.korhonen-mobopts-link-characteristics-ps]. Providing of event classification, event reporting or event filtering corresponding to dynamic changes in the link characteristic enables the MN to manage and control link behaviour relevant handovers and mobility. Initial measurement results on the end-to-end path characteristics can be used to inform upper layer congestion control mechanisms determining the effective end-to-end path characteristic. 7.4. Requirements for Link and Sub-Path Information delivery The link characteristic information delivery mechanism SHOULD fulfil the following requirements. REQ1: The link characteristic information delivery is independent of a certain IP mobility solution. REQ2: The link characteristic information delivery SHOULD be applicable to existing mobility solutions. REQ3: It is transport protocol independent. REQ4: Signalling traffic load MUST be avoided. Durel, et al. Expires March 25, 2013 [Page 10] Internet-Draft FMC Requirements September 2012 REQ5: The mechanism MUST work when the MN is multi-homed or not. REQ6: Link characteristic information SHOULD be exchanged prior to handover. REQ7: Link characteristic information MUST be useable for remote peer node and/or remote network control entity. 8. Security Considerations This document focuses on FMC requirements and the interworking of "WiFi, 3G, etc..." and should not give rise to any new security vulnerabilities beyond those described in IPSec [RFC4301], TLS [RFC5246] or SRTP [RFC3711]. Nevertheless an open network architecture aimed at fulfilling the requirements listed in this document may give rise to security issues not yet identified. 9. IANA considerations None. 10. Acknowledgments Contributions, comments, discussions, and remarks provided by David Binet, Mohamed Boucadair, Christian Jacquenet, Daniel Park, and Pierrick Seite are gratefully acknowledged. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative references [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", Durel, et al. Expires March 25, 2013 [Page 11] Internet-Draft FMC Requirements September 2012 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. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, 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-04 (work in progress), August 2012. [I-D.xue-intarea-fmc-ps] Xue, L., Sarikaya, B., and D. Hugo, "Problem Statement for Fixed Mobile Convergence", draft-xue-intarea-fmc-ps-02 (work in progress), March 2012. [I-D.sun-fmc-use-case] Xie, C. and Q. Sun, "Use Cases and Requirements in Fixed Mobile Convergence", draft-sun-fmc-use-case-00 (work in progress), July 2012. [I-D.so-ipsecme-ikev2-cpext] So, T., "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", Durel, et al. Expires March 25, 2013 [Page 12] Internet-Draft FMC Requirements September 2012 draft-so-ipsecme-ikev2-cpext-02 (work in progress), June 2012. [3GPP.22.278] 3GPP, "Service requirements for the Evolved Packet System (EPS)", 3GPP TS 22.278 10.2.0, October 2010. [3GPP.22.234] 3GPP, "Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking", 3GPP TS 22.234 10.0.0, December 2009. [I-D.korhonen-mobopts-link-characteristics-ps] Korhonen, J., "Link Characteristic Information for IP Mobility Problem Statement", draft-korhonen-mobopts-link-characteristics-ps-01 (work in progress), June 2006. [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. [WT146] "Broadband Forum Working Text WT-146, Subscriber Sessions", June 2011. [WT203] "Broadband Forum Working Text WT-203, Interworking between Next Generation Fixed and 3GPP Wireless Access", December 2011. [samog] "3GPP TR 23.852 V1.2.0, Study on S2a Mobility based On GTP & WLAN access to EPC (SaMOG) (Release 12)", July 2012. [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 March 25, 2013 [Page 13] Internet-Draft FMC Requirements September 2012 Appendix A. 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 mobile node (MN) characteristics. A.1. Recommendations for Content Adaptation To be able to meet above high level requirement, the content adaptation function needs to: 1. identify the user connection by identifying each MN in a separate manner. The MN identity MUST be updated during the session each time a new terminal is used. The characteristics of each MN 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 network). 2. distinguishing the MN 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. 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 Durel, et al. Expires March 25, 2013 [Page 14] Internet-Draft FMC Requirements September 2012 Roland Schott Deutsche Telekom Darmstadt, 64295 Germany Phone: Email: Roland.Schott@telekom.de Charles E. Perkins Futurewei Santa Clara, California 94053 USA Phone: Email: charlie.perkins@huawei.com Durel, et al. Expires March 25, 2013 [Page 15]