Requirements on Fixed Mobile Convergence
draft-schott-fmc-requirements-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Sophie Durel , Hassnaa Moustafa , Roland Schott | ||
| Last updated | 2012-06-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schott-fmc-requirements-01
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]