Subject: Re: [fmc] FMC BoF at IETF 84?

From: <[email-masked]>
Date: Mon, 9 Jul 2012 20:14:07 +0200

Hi Daniel,

see below

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Daniel Park
Gesendet: Dienstag, 12. Juni 2012 09:42
An: John Kaippallimalil
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; THIEBAUT, LAURENT (LAURENT); [email-masked]
Betreff: Re: [fmc] FMC BoF at IETF 84?

Hi Roland,

I've briefly seen the draft. To me, it seems quite straightforward...It can be a just starting point though.
Here is my rough comments for more discussion. (I am also a bit straightforward..so please don't be serious..^^)

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.

[daniel] where is the sections for architecture and related works ? This document directly expresses some of requirements without any of problem statements and architectural explanation. It needs to be updated.

[Roland] We have a problem statement draft, there we have described the architecture and problems to be solved.
Nevertheless IMHO we should also have a figure what we really understand about FMC (I will make a first definition proposal resp. reminder under
terminology).
The discussion open garden, wallet garden or combined model has also not been discussed on the list,
so I have no clear feeling about this.

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

[daniel] Here, still the FMC definition is not clear to me. Are you defining them like below? or anything else ?

Internet---ethernet---[CPE] is Fixed
[CPE]---ethernet---[AP/BS] is Mobile

or
Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed
[AP/BS]---air---Mobile Device is Mobile

More specific, FMC means Fixed-Mobile Convergence. Another words, Convergence seems to me service and session continuity for the user who has both Fixed and Mobile subscription and access, where IETF FMC solutions have to support any of protocols to provide seamless services across Fixed and Mobile networks. It is traditionally a vertical handover in IETF in my experience. In that sense, *visiting hosts which do not belong to the subscriber* is merely taken place. Are you indicating the user who has Fixed network by A service provider and Mobile network by B service provider ?

[Roland] My brief definition is:

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)  are  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 3 rd party.

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.

[daniel] not sure, but it seems a bit implementation issue on the mobile device. Are there any problems or issues to be worked by IETF ?
[Roland] is under discussion, see mails of Charles and Pierrick

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

[daniel] What you mean by mobility in Fixed Network ? In particular, *the switch from one network to another* means plug-in and pull-out from the ethernet port ? Still, FMC seems to be Wire-Wireless handover as one of vertical handover cases. In that sense, FMC has to support seamless connectivity when the user pull out his ethernet cable on the mobile node, any of available wireless networks should be provided for the handover, then the ongoing session will be kept...Isn't it a FMC use case ?
[Roland] nomadic use of fixed devices, nomadic use of a fixed customer with his credentials and access e.g. via 3rd pargty WiFi allowing to get his service profile
and access to WiFi/3G/4G (vica verca) from a mobile device

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.

[daniel] For the adaptive streaming over heterogeneous networks, the appropriate sending rate based on the network characteristics and conditions is a fundamental function, and should be dynamically determined and exchanged between the client and the server. For that issue, there are several related internet-drafts. Just for your information.
http://tools.ietf.org/html/draft-korhonen-mobopts-delivery-analysis-00
http://tools.ietf.org/html/draft-korhonen-mobopts-link-characteristics-ps-01
http://tools.ietf.org/html/draft-daniel-mip-link-characteristic-01

Here, the mobile node has to obtain the network characteristics information via device API, and currently W3C is working on that matter as to define various APIs (Javascript) to get device and network information such as network type, available bandwidth, battery status, and so on...Although it is beyond scope of IETF, but needs to be discussed from the FMC architecture point of view.

[Roland]
In my opinion an interesting information to be discussed on the list

Regards, Daniel
--
Soohong Daniel Park
Samsung Electronics, Co., Ltd.

On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil <[email-masked]<mailto:[email-masked]>> wrote:
Agree with Pierrick that is useful to look from an IETF viewpoint.
The fmc requirements draft http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt is a good place to start.

-John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of THIEBAUT, LAURENT (LAURENT)
Sent: Friday, June 08, 2012 3:12 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [fmc] FMC BoF at IETF 84?

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 8 juin 2012 10:09
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [fmc] FMC BoF at IETF 84?

Hi,

Actually, this is a good discussion. I agree that gathering requirements for FMC is a good exercise, as long as it is done from an IETF standpoint. Otherwise, we duplicate BBF work.
It is also worth to identify existing IETF solutions , or ongoing work, that might meet these requirements. Then gap analysis should be done: what are the specific FMC issues that cannot be solved with current protocols, or using other SDOs mechanisms? That's a fair question which should be answered before going into a BoF, but the problem is that  early stage drafts do not answer above question. In other words,  more work is needed before going into a BoF. It does not mean we should stop discussing; clearly, ongoing work in IETF/FMC is worth the effort but we still have not shown the interest for a dedicated FMC IETF WG... In my opinion...

BR,
Pierrick

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Charles E. Perkins
Envoyé : vendredi 8 juin 2012 08:54
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [fmc] FMC BoF at IETF 84?

Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated that
there is work to do.  I can certainly imagine that the IETF should have something
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.  From the BBF and ITU documents, it
seemed quite reasonable to initiate some effort.  I gather you do not see the
need, or else see that it is already being met.  If you'd like to supply some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF
people don't have to wait to be told what needs to be done.  Of course if
some other SDO does tell the IETF what needs to be done, it can be easier
to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.  I'm personally familiar with one or
two cases.  And, to some extent, duplication can be in the eyes of the
beholder.  For instance, why mess around with having NAIs or IMSIs when
we already have FQDNs??  [just kidding, no worries, I do understand]

Please also note that "identify" is not at all the same as "define".

Regarding the other points -- if you'd like to supply pointers to the relevant
work in other SDOs for "session continuity, policy distribution, QoS
management, and application mobility"  I'd be interested to take a look.
Somehow, in discussions with other interested people, I had the impression
that these things were lacking.  I don't even claim that they are necessarily
within the jurisdiction of the IETF, but they seemed to me to be well within
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to
find out what if anything needs to be done.  It's always O.K. to find out that
nothing needs to be done -- perhaps even preferable.  That was not at all
the sense I got from previous discussion, though.

Regards,
Charlie P.

On 6/7/2012 10:59 PM, [email-masked]<mailto:[email-masked]> wrote:
Dear Charles,

Thank you very much for your kind initiative for this work.

However, when I examine the charter that you were describing below, many questions come to my mind.

Could you please help me to understand better on those considerations?  Please see inline below..

Thanks in advance.
Tricci

"Charles E. Perkins" <[email-masked]><mailto:[email-masked]>
Sent by: [email-masked]<mailto:[email-masked]>

06/07/2012 10:29 PM

To

"[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

cc

Subject

[fmc] FMC BoF at IETF 84?

Hello folks,

It's time to request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request...

Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any specific request on this work?  If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address?   The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues.  I would not like to see the duplicate work done in different SDOs and come up with different solutions?

 While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset).

Tricci > May I ask, why would be the IETF's role to define the wireless end device?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA?  Especially, I am sure that they already have their own definitions.  So, what are the wireless end device that you have in mind that needs to be defined by IETF?  Could you please clarify?

Other requirements might include session continuity, policy distribution, QoS management, and application mobility.

Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF?

The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities.

Tricci > Sorry for asking so many questions?  I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated.  Thanks again in advance to help me to understand your proposal for this BOF.

--
Regards,
Charlie P.

_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc

--------------------------------------------------------

ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

_______________________________________________

fmc mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/fmc

--

Regards,

Charlie P.

_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc