Requirements on Fixed Mobile Convergence
draft-schott-fmc-requirements-00

Network Working Group                                          R. Schott
Internet-Draft                                          Deutsche Telekom
Expires: December 7, 2012                                   June 5, 2012

               Requirements on  Fixed Mobile Convergence
                    draft-schott-fmc-requirements-00

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 7, 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
   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.

Schott                  Expires December 7, 2012                [Page 1]
Internet-Draft              FMC Requirements                   June 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Reminders to the Reader on the IETF Process . . . . . . . . . . 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.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     11.2. Informative references  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Schott                  Expires December 7, 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.  Reminders to the Reader on the IETF Process

   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

Schott                  Expires December 7, 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

Schott                  Expires December 7, 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.

Schott                  Expires December 7, 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 avove 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.  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.

9.  IANA considerations

   None.

Schott                  Expires December 7, 2012                [Page 6]
Internet-Draft              FMC Requirements                   June 2012

10.  Acknowledgements

   Contributions, comments, discussions, and remarks provided by Mohamed
   Boucadair, Sophie Durel, Hasnaa Moustafa, 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.

   [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.

11.2.  Informative references

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,

Schott                  Expires December 7, 2012                [Page 7]
Internet-Draft              FMC Requirements                   June 2012

              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.

Schott                  Expires December 7, 2012                [Page 8]
Internet-Draft              FMC Requirements                   June 2012

Author's Address

   Roland Schott
   Deutsche Telekom
   Heinrich-Hertz-Str. 3-7
   Darmstadt,   64295

   Phone: +49 6151 5812823
   Email: Roland.Schott@telekom.de

Schott                  Expires December 7, 2012                [Page 9]