Subject: [fmc] FMC BoF at IETF 84?

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Jun 2012 22:29:38 -0700

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.  While there
are many possible solutions, all of them will require some
agreement on how to identify the wireless end device (e.g.,
handset).  Other requirements might include session continuity,
policy distribution, QoS management, and application mobility.
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.

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Thu, 7 Jun 2012 22:59:52 -0700

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]> 
Sent by: [email-masked]
06/07/2012 10:29 PM

To
"[email-masked]" <[email-masked]>
cc

Subject
[fmc] FMC BoF at IETF 84?

Hello folks,

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

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 08:32:09 +0200

Dear Charlie,

IMHO, it is too early to request a BoF. We are still in the process of assessing whether there is a specification effort required within IETF.
Even in this mailing list, there was not much discussion and several questions are still to be fixed first.

The current available "fmc" documents are not mature; especially the requirements draft is in the very early stage. We have contributed with three issues to kick off the discussion but as mentioned in the Introduction of the draft, this does not mean we are voicing for creating a WG and so.

We need to focus our energy and avoid waste it in preparing a BoF which is likely to fail in achieving its objectives. 

Alternatively, I would invite interested people to contribute to the requirements document and to challenges the requirements and recommendations sketched in it. 

Before requesting a formal meeting in IETF, we need IMHO to have clear ideas about the following: 

* Is there any remaining issues to be solved?
* Why existing IETF tools do not help to solve those issues?
* Are these issues specific to the "FMC" context (as understood in BBF-3GPP)?
* If there are issues specific to FMC, what are the specificities? 
* What is the best approach to make help advancing missing specification pieces?: Existing WGs, New WG, etc.
* Wouldn't be better to seek for liaison from BBF and 3GPP?

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Charles E. Perkins
>Envoyé : vendredi 8 juin 2012 07:30
>À : [email-masked]
>Objet : [fmc] FMC BoF at IETF 84?
>
>
>Hello folks,
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Jun 2012 23:53:58 -0700

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] wrote:
> However, when I examine the charter that you were describing below, 
> many questions come to my mind.
>
> *"Charles E. Perkins" <[email-masked]>*
> "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...
>
> 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.
>
> 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?
>
> 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.
>

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Fri, 8 Jun 2012 00:28:59 -0700

Dear Charles, 

Sincerely thanks for your prompt responses. 

I would like to clarify that, I have not implied anything on one-way or 
the other that no work needs to be done in IETF. 

I thought that I was very clear for asking what needs to be done based on 
your descriptions for the BOF?  Somehow, my questions are bounced back to 
me? 

May be it is my lack of understanding of IETF's culture?  I would think 
that, when a BOF is formed, there is strong indication that some work must 
need and worth to be investigated in IETF.  But, based on your 
descriptions, I can't derive what they are? 

Unfortunately, at this point, my questions are still remained. :)

Thanks again for your timely response. 
Tricci 

06/07/2012 11:53 PM

To
[email-masked]
cc
[email-masked], "[email-masked]" <[email-masked]>
Subject
Re: [fmc] FMC BoF at IETF 84?

Hello Tricci,

seemed quite reasonable to initiate some effort.  I gather you do not see 
the

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.

SDOs (not IETF) have duplicated effort.  I'm personally familiar with one 
or

within the jurisdiction of the IETF, but they seemed to me to be well 
within

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.

Thanks in advance. 
Tricci 

To

Subject

Hello folks,

-- 
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 10:09:12 +0200

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]] De la part de Charles E. Perkins
Envoyé : vendredi 8 juin 2012 08:54
À : [email-masked]
Cc : [email-masked]; [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.

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.

Dear Charles, 

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] 

06/07/2012 10:29 PM 

To

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

cc

Subject

		

Hello folks,

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]
https://www.ietf.org/mailman/listinfo/fmc <https://www.ietf.org/mailman/listinfo/fmc> 

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 08 Jun 2012 01:10:49 -0700

Hello Tricci,

I don't exactly know how better to answer your questions, but I'll try again
with fewer words.  Perhaps the extra verbiage gets in the way.

On 6/8/2012 12:28 AM, [email-masked] wrote:
>
> I thought that I was very clear for asking what needs to be done based 
> on your descriptions for the BOF?

device identity, session continuity, policy distribution,
QoS management, and application mobility

But please keep in mind that other people may have other ideas.  This
is simply a list resulting from my understanding of the problem as
formulated by BBF and ITU.

> Somehow, my questions are bounced back to me?

No... (?) You asked me what needed to be done, I mentioned the above, 
and asked if you could supply pointers to related (or duplicative) work 
in other SDOs.  That's quite different than simply reflecting back your 
questions.

>
> May be it is my lack of understanding of IETF's culture?  I would 
> think that, when a BOF is formed, there is strong indication that some 
> work must need and worth to be investigated in IETF.  But, based on 
> your descriptions, I can't derive what they are?

"must" is too strong.  If I could say "must", we would form a working 
group, not a BoF.
For the last sentence, please see above.

> Unfortunately, at this point, my questions are still remained. :)

I hope this helps.

Regards,
Charlie P.

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Fri, 8 Jun 2012 10:12:20 +0200

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

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

Hi,

BR,
Pierrick

Hello Tricci,

Regards,
Charlie P.

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

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

Hello folks,

--
Regards,
Charlie P.

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

fmc mailing list

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

--

Regards,

Charlie P.

---

From: John Kaippallimalil <[email-masked]>
Date: Fri, 8 Jun 2012 14:56:08 +0000

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

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

Hi,

BR,
Pierrick

Hello Tricci,

Regards,
Charlie P.

Thanks in advance.
Tricci

06/07/2012 10:29 PM

To

cc

Subject

Hello folks,

--
Regards,
Charlie P.

fmc mailing list

--

Regards,

Charlie P.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 11 Jun 2012 19:38:46 -0400

Tricci:

Perhaps I'm just too practical. 
 
I really see a clear problem and a set of choices as R.Schott has described
in his HOST_ID portion of his document
(http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt).
 
The context of this problem is a circumstance where the LTE offloads to the
WiFi which is connected to the Wired world, and has a NAT (v4/v6)
translation.
 
Will the LTE to WiFi offload happen in 2013?
 
I believe as 802.11ac with 1G+ deploys in 2012-2013, the offload from LTE
802.11 WiFi/Wired world will increase. The 802.11ai seems to admit there
will be fast handoffs between devices as people walk between sites. Based on
802.11ai discussions, it seems people feel this  validation of IDs (using
802.1x, EAP, DCHP and AAA servers) will be the slow part of the system. Most
of these protocols are under the IETF's control.
 
The LTE to WiFi offload (as you indicated) arises in Big cities where the
LTE has potential 1000s (in the football stadium case). 

R. Schott (http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt)
gives good description of the UE Identifier need that we discussed at the
IETF-83 side-bar meeting. The v4/v6 NAT case seems to be something that you
and everyone else agreed was a problem. This problem seems to be driven by
v4 NATs in the WiFi off load of LTE.
 
Schott further suggests that: 

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

He further states:

   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

   o The CPE SHOULD strip any existing HOST_ID

   o The CPE and the service node MUST support at least one common

   method to convey HOST_ID.

The problem is when I read the solutions suggested in
ietf-intarea-nat-reveal-analysis,
I see different pros/cons to each. For example, The implementation of Port
sets won't scale to 1000s that might rotate by a LTE/WiFi exchange near a
sports stadium. Charlie's suggested some other pros/cons.
 
When I look at the pros/cons ietf-intarea-nat-reveal-analysis, I wonder if
we should change the paradigm of the solution to get a better answer. Noting
that all the solutions for mobility management already require some sort of
identity management, it seems likely that we could borrow some of that work
done as part of existing mobility solutions. 
 
Other SDOs
----------

In May 2012, BBF created a WT-291 that is setting these requirements.
Behcet is the editor of that draft so I will ask him to comment on the
status and content of WT-291.  Behcet started this investigation in IETF
because BBF work prior to WG-291 indicated that the IETF to specify the UE
identifier solution.

Goal

--------

The goal here is to find an interoperable solution we agree works. Schott
correctly points out WG/Non-WG is not concern. The concern is to come to a
single solution or a set of solutions that work. If you think ports scales
will scale to 1000s as a crowd pickups up its cell phones during or after a
football/soccer game - let me know why and how.  

I want happy customers for the WiFi/LTE offload.  What I know will make
customers unhappy is when they are handle by one carrier and get dropped as
they stroll between LTE and WiFi offload points.  They will even want to
keep up their videos and web browsing. 

So.. Charlie's experience leads him to suggest the impact of mobility,
policy and many other things on the IETF choices. My experience leads me to
suggest an interoperable solution in 2012/2013 will help allow multi-vendor
support for WiFi/LTE offload. 

It seems like chatting about interoperable solutions in a side-bar meeting
might create a set of clear choices. 

Tricci - has this been helpful and practical?  

Sue Hares

[email-masked]

[email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, June 08, 2012 3:29 AM
To: Charles E. Perkins
Cc: [email-masked]; [email-masked]
Subject: Spam:*******, Re: [fmc] FMC BoF at IETF 84?

Dear Charles, 

I would like to clarify that, I have not implied anything on one-way or the
other that no work needs to be done in IETF. 

May be it is my lack of understanding of IETF's culture?  I would think
that, when a BOF is formed, there is strong indication that some work must
need and worth to be investigated in IETF.  But, based on your descriptions,
I can't derive what they are? 

06/07/2012 11:53 PM 

To

[email-masked] 

cc

Subject

		

Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated
that

Regards,
Charlie P.

Thanks in advance. 
Tricci 

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

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

06/07/2012 10:29 PM 

To

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

cc

Subject

		

Hello folks,

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?  

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?   

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
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/fmc>
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
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/fmc>
https://www.ietf.org/mailman/listinfo/fmc

-- 
Regards,
Charlie P. 

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

---

From: Daniel Park <[email-masked]>
Date: Tue, 12 Jun 2012 16:42:22 +0900

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 <
[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]] *On Behalf Of *THIEBAUT,
> LAURENT (LAURENT)
> *Sent:* Friday, June 08, 2012 3:12 AM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]; [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]] *De la part de*
> [email-masked]
> *Envoyé :* vendredi 8 juin 2012 10:09
> *À :* [email-masked]; [email-masked]
> *Cc :* [email-masked]; [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]] *De la part de*Charles E. Perkins
> *Envoyé :* vendredi 8 juin 2012 08:54
> *À :* [email-masked]
> *Cc :* [email-masked]; [email-masked]
> *Objet :* Re: [fmc] FMC BoF at IETF 84?****
>
> ** **
>
>
> Hello Tricci,
>
> On 6/7/2012 10:59 PM, [email-masked] wrote: ** **
>
> Dear Charles,
>
> ****
> *"Charles E. Perkins" <[email-masked]> <[email-masked]>*
> Sent by: [email-masked] ****
>
> 06/07/2012 10:29 PM ****
>
> To****
>
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]> ****
>
> cc****
>
> ** **
>
> Subject****
>
> [fmc] FMC BoF at IETF 84?****
>
> ** **
>
> ** **
>
> ** **
>
> ****
>
>
>
>
>
> Hello folks,
>
> 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
> 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]****
>
> https://www.ietf.org/mailman/listinfo/fmc****
>
> ** **
>
> -- ****
>
> Regards,****
>
> Charlie P.****
>
>

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 12:21:27 +0200

Hi Daniel,
just a quick remark: The requirements draft is accompanied by a problem statement document

http://www.ietf.org/id/draft-xue-fmc-ps-00.txt

where architecture and so on are described.referring to your question I would say we see fixed and mobile as following

Internet---ethernet---[CPE]---ethernet---[AP]---air---Device is Fixed
Internet---ethernet---[EPC, mobile core]---ethernet---[BS]---air---Device is Mobile

we will discuss the other issues in future in more detail.

Best regards
Dirk
________________________________
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

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

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

or

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 ?

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

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

[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

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,

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,

Regards,
Charlie P.

Thanks in advance.
Tricci

06/07/2012 10:29 PM

To

cc

Subject

Hello folks,

--
Regards,
Charlie P.

fmc mailing list

--

Regards,

Charlie P.

---

From: Daniel Park <[email-masked]>
Date: Tue, 12 Jun 2012 19:33:55 +0900

Hi Dirk,

Thanks for pointing the PS draft. I will go through this and get back to
here with more comments.

Glancing at the draft...

 Figure 1 shows the assumed reference architecture of Fixed Mobile
   Convergence Interworking for a Mobile (3GPP) Network and a fixed non-
   3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as
   an example in document [WT203].

[daniel] ah...so you are very much leaning to the 3GPP perspective. Um.
fixed network is non-3GPP access network and mobile network is 3GPP
network. It seems controversial definition in IETF...In this assumption,
3GPP and Non-3GPP interworking would be clearer than FMC in my thought.
Anyhow, I will take a look at the draft...

Regards, Daniel.
-- 
*Soohong Daniel Park*
Samsung Electronics, SWC

On Tue, Jun 12, 2012 at 7:21 PM, <[email-masked]> wrote:

> **
> *http://www.ietf.org/id/draft-xue-fmc-ps-00.txt*<http://www.ietf.org/id/draft-xue-fmc-ps-00.txt>
>
> where architecture and so on are described.referring to your question I
> would say we see fixed and mobile as following
> *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,
>
> 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*
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
>> *THIEBAUT, LAURENT (LAURENT)
>> On 6/7/2012 10:59 PM, [email-masked] wrote: ****
>>
>> Dear Charles,
>>
>> from documents published by the BBF and the ITU [citations here]. Work
>> is needed in the IETF to meet the requirements.
>>
>> work?  If so, what are the specific problems that BBF has asked IETF, more
>> 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