Re: [fmc] FMC BoF at IETF 84?

[Daniel Park <[e-mail]>]

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.

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 ?

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 ?

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 ?

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.


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



On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil <
[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf Of *THIEBAUT,
> LAURENT (LAURENT)
> *Sent:* Friday, June 08, 2012 3:12 AM
> *To:* [e-mail]; [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [fmc] FMC BoF at IETF 84?****
>
> ** **
>
> ** **
>
> ** **
>
> Hello all****
>
> I support Pierrick****
>
> Best regards ****
>
> Laurent
> ALCATEL-LUCENT ****
>   ------------------------------
>
> *De :* [e-mail] [mailto:[e-mail]] *De la part de*
> [e-mail]
> *Envoyé :* vendredi 8 juin 2012 10:09
> *À :* [e-mail]; [e-mail]
> *Cc :* [e-mail]; [e-mail]
> *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 :* [e-mail] [mailto:[e-mail]] *De la part de*Charles E. Perkins
> *Envoyé :* vendredi 8 juin 2012 08:54
> *À :* [e-mail]
> *Cc :* [e-mail]; [e-mail]
> *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, [e-mail] 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" <[e-mail]> <[e-mail]>*
> Sent by: [e-mail] ****
>
> 06/07/2012 10:29 PM ****
>
> To****
>
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]> ****
>
> 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
> [e-mail]
> 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****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/fmc****
>
> ** **
>
> -- ****
>
> Regards,****
>
> Charlie P.****
>
>
> _______________________________________________
> fmc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fmc
>
>