Requirements for Fixed Mobile Convergence
draft-schott-fmc-requirements-02
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 , Charles E. Perkins | ||
| Last updated | 2012-07-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-02
Network Working Group S. Durel
Internet-Draft France Telecom
Expires: January 13, 2013 H. Moustafa
Orange Labs
R. Schott
Deutsche Telekom
C. Perkins
Futurewei
July 12, 2012
Requirements for Fixed Mobile Convergence
draft-schott-fmc-requirements-02
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 January 13, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Durel, et al. Expires January 13, 2013 [Page 1]
Internet-Draft FMC Requirements July 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. Requirements for MN Identification behind a CPE with NAT . . . 5
4.1. Recommendations for MN Identification behind NAT . . . . . 7
5. Requirements for Access Selection . . . . . . . . . . . . . . 7
6. Requirements for MN Mobility in Fixed Broadband Network . . . 8
7. Requirements for Streaming . . . . . . . . . . . . . . . . . . 8
7.1. Personalization of Video Streaming Service . . . . . . . . 8
7.1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Recommendations for Streaming . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative references . . . . . . . . . . . . . . . . . . 11
Appendix A. Requirements for Content Adaptation . . . . . . . . . 13
A.1. Recommendations for Content Adaptation . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Durel, et al. Expires January 13, 2013 [Page 2]
Internet-Draft FMC Requirements July 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. 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
[cite]. 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 January 13, 2013 [Page 3]
Internet-Draft FMC Requirements July 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 January 13, 2013 [Page 4]
Internet-Draft FMC Requirements July 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. 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,
Durel, et al. Expires January 13, 2013 [Page 5]
Internet-Draft FMC Requirements July 2012
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
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-
Durel, et al. Expires January 13, 2013 [Page 6]
Internet-Draft FMC Requirements July 2012
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.
4.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.
5. Requirements for Access Selection
A multiple access environment requires appropriate choice of the
access network (cellular, mobile, VPN,...) that the device is likely
to be connected to. This selection may depend on various criteria
such as user's preference, user profile, network capabilities and
conditions, operator policies, application QoS requirements and so
on. This access selection can happen when the wireless device is
first connected to an access network, i.e. at bootstrapping phase,
and when a new access network can be accessed to, for example as the
device moves.
Relevant information should be collected for each access network
type, including:
o Available Bandwidth
o Cost
o Latency
o other QoS information
o Operator Network Identification
o Network Protocol Family (IPv4 or IPv6).
Policy access SHOULD also be enabled.
Durel, et al. Expires January 13, 2013 [Page 7]
Internet-Draft FMC Requirements July 2012
A mapping between the network status and the service requirements
should be specified to allow the MN to choose the network that best
matches its service requirements.
It should be possible to manage the user's access in the presence of
several candidate access networks (fixed and mobile).
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 Streaming
Additional IETF specification may be desirable for personalization of
streaming services, especially video.
7.1. Personalization of Video Streaming Service
7.1.1. Discussion
The proliferation of streaming services (e.g., video across multiple
screens and connected devices) motivates video streaming service
personalization -- especially for users desiring richer Quality of
Experience (QoE). Personalization of such services could allow
streaming content delivery in a customized manner depending on each
user, the device used, and the network status mainly through the
following choices:
i) delivery network (fixed or mobile),
ii) local access network (WiFi, Femto, ADSL, .),
iii) delivery mode (unicast, multicast, delivering content from the
one server or from caches, ..)
In this way, the streaming content could follow the user from place
Durel, et al. Expires January 13, 2013 [Page 8]
Internet-Draft FMC Requirements July 2012
to place regardless of the access network type and of the mobile node
(MN) characteristics.
This requires technical solutions to allow the selection of the
appropriate interface to be used by the MN. The MN typically does
not have any global view of the congestion status of the network.
Moreover, in many cases the owner of the device might attempt to gain
the highest level of service (regardless of the cost of network use
by the operator). Service levels need to be controlled by the
network and/or the service domains, not the MN. Likewise, the
ability of premium clients to access more QoS resources (e.g. more
bandwidth) further supports the design guideline enabling network
choices to be decided by the operator.
In many cases, the service level controls required by the network
operator require traffic monitoring at the aggregation node. This
may require further coordination between the aggregation node and the
CPE in order for the aggregation node to have the proper policy
information available.
To be able to select the appropriate network and adapt the content
according to the network status there is a need to obtain information
about the network status and its variation 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. The
current adaptive streaming solutions (as the HAS: HTTP Adaptive
Streaming) mainly count on the MN for selecting the suitable content.
However, if content adaptation happens at the content source (in
contrast to HTTP adaptive streaming techniques currently existing,
the source 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). Content adaptation
directives could also be extracted from the content Metadata.
Personalization of streaming imposes the following requirements:
o Each user connection MUST be identified through identifying each
MN in a separate manner and distinguishing the MN and the CPE
identification. The MN identification could be simply an NFC
identifier, MAC identifier, ... which is then administratively
associated with more information reflecting the MN
characteristics.
o Monitoring mechanisms MUST exist allowing the collection of QoS
information for each access network type.
Durel, et al. Expires January 13, 2013 [Page 9]
Internet-Draft FMC Requirements July 2012
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 maintain the session
according to the network status with the change in the MN
attachment.
o Mechanisms and interfaces between operators SHOULD be deployed to
control the mobility of traffic flows of their users.
7.2. Recommendations for Streaming
The IETF SHOULD dedicate efforts to consider several issues related
to the MN and also to the network status as follows:
1. Each MN needs to be identified and the MN identity needs to 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 networks).
2. Information about is needed for each of the network parameters as
detailed in Section 5,
3. A mapping between the network status and the service requirements
needs to exist to enable selection of the network that best
matches the service requirements.
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.
Durel, et al. Expires January 13, 2013 [Page 10]
Internet-Draft FMC Requirements July 2012
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)",
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]
Durel, et al. Expires January 13, 2013 [Page 11]
Internet-Draft FMC Requirements July 2012
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.
[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",
draft-so-ipsecme-ikev2-cpext-02 (work in progress),
June 2012.
[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.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
Durel, et al. Expires January 13, 2013 [Page 12]
Internet-Draft FMC Requirements July 2012
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2008",
2008.
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 January 13, 2013 [Page 13]
Internet-Draft FMC Requirements July 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 January 13, 2013 [Page 14]