Subject: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

From: <[email-masked]>
Date: Thu, 5 Jul 2012 23:32:49 +0200

Hi Charles and all,

s.b.

-----Ursprüngliche Nachricht-----
Von: Charles E. Perkins [mailto:[email-masked]]
Gesendet: Dienstag, 12. Juni 2012 23:50
An: Schott, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; von Hugo, Dirk
Betreff: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

Hello folks,

I have some comments on the new draft.

First, I think it would be better to focus on network attachment and
mobility
aspects of the problem.  We don't need to include network discovery and
selection as part of the FMC problem.  For example, we could limit ourselves
to making a solution that enables the desirable FMC outcomes based on
the presumption that the access networks are already determined.

This fits naturally with the way that a candidate access network is first
discovered before the attachment (or handover) is initiated.

 RS: I agree with Charles, we do not need to include network discovery as a part of the problem.

I am also worried about bundling in content adaptation as part of the
problem space.  This was mentioned at the IETF 83 Bar BoF.  There, it
was suggested that the IETF might specify some means of transporting
content adaptation commands, without specifying the commands
themselves.  That is much more reasonable, but I'd still suggest that
we could profitably delay that part of the solution until we at least
figure out how to authenticate and attach devices to the candidate
access networks.

Similar comments apply to streaming.

 RS: We can remove it in the next version of the draft and discuss it in the solution documents

Finally, I think that we should not be limited to only the solutions
for HOST_ID that are enumerated in ietf-intarea-nat-reveal-analysis.

 RS: We can have a wider scope and replace "HOST_ID" by "host_id"
  Sophie has provided a proposal we can integrate in the next version.

Regards,
Charlie P.

On 6/12/2012 11:28 AM, [email-masked] wrote:
> Hi all,
>
> we have posted a new version of draft-schott-fmc-requirements-01.txt.
> Sophie Durel and Hasnaa Moustafa are now editors, too.
> We have added a section about streaming.
> Please use this version for further discussion on the list.
>
> Regards
>
> Roland
>
> -------
>
>
> A new version of I-D, draft-schott-fmc-requirements-01.txt
> has been successfully submitted by Roland Schott and posted to the
> IETF repository.
>
> Filename:        draft-schott-fmc-requirements
> Revision:        01
> Title:           Requirements on Fixed Mobile Convergence
> Creation date:   2012-06-12
> WG ID:           Individual Submission
> Number of pages: 11
> URL:             http://www.ietf.org/internet-drafts/draft-schott-fmc-requirements-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-schott-fmc-requirements
> Htmlized:        http://tools.ietf.org/html/submission.filename }}-01
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-schott-fmc-requirements-01
>
> Abstract:
>     This document provides a brief overview of the FMC (Fixed Mobile
>     Convergence) architecture and related works.  The purpose of the
>     document is to sketch a big picture for the FMC activity to ease
>     identifying whether specification effort is required within IETF.
>     This document identifies and analyzes some of issues that have arisen
>     so far and elaborates a set of requirements for the FMC system.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> fmc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc
>
>

--
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Sun, 8 Jul 2012 14:36:40 +0200

Hi Hassnaa,

in my opinion we can bring this into the new version of
the draft and discussing the changes on the list.

Otherwise the parts discussed via mail may be difficult to
align.

Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet: Freitag, 6. Juli 2012 10:16
An: Schott, Roland; [email-masked]; [email-masked]; DUREL Sophie OLNC/NAD/TIP
Cc: von Hugo, Dirk; BINET David OLNC/NAD/TIP
Betreff: RE: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

Hi Roland,

This was an old discussion that was followed by more recent ones. And there was more exchange concerning the streaming and the Host-Id issue.

Kindest regards,
Hassnaa

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]
Envoyé : jeudi 5 juillet 2012 23:33
À : [email-masked]; [email-masked]; DUREL Sophie OLNC/NAD/TIP
Cc : MOUSTAFA Hassnaa RD-CORE; [email-masked]; BINET David OLNC/NAD/TIP
Objet : AW: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

Hi Charles and all,

s.b.

-----Ursprüngliche Nachricht-----
Von: Charles E. Perkins [mailto:[email-masked]]
Gesendet: Dienstag, 12. Juni 2012 23:50
An: Schott, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; von Hugo, Dirk
Betreff: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 9 Jul 2012 10:05:23 +0000

Hi,

I didn't follow closely this thread, so maybe I'm missing something but, IMHO, access discovery and selection is the key feature of a FMC system. If this problem is not 100% IETF, it is nevertheless related. Actually, this is what the MIF WG refer as "Provisioning domain selection", which may lead to specify mechanism to provision the fmc host with routing, or source address selection, policies or to specify specific API. Actually, "access discovery and selection" is well covered within IETF/MIF or other SDOs and thus, I definitely agree there is no need for more work on "network discovery and selection" , but you can't state it is not part of the problem and I think we should at least refer to MIF WG related work items and potential solutions from other SDOs. Can we agree?

Br,
Pierrick.

> De : [email-masked] [mailto:[email-masked]] De la part de
> [email-masked]
> Cc : MOUSTAFA Hassnaa RD-CORE; BINET David OLNC/NAD/TIP; Dirk.von-
> [email-masked]
> Objet : Re: [fmc] New Version Notification for draft-schott-fmc-
> requirements-01.txt
> 
> Hi Charles and all,
> 
> s.b.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 09 Jul 2012 07:01:48 -0700

Hello Pierrick,

I understand your argument.  I guess we have an ambiguity about what is 
needed for "FMC"
versus what the IETF needs to do about it.  I'm not sure how best to 
resolve this conflict.

I'll try to finish editing the draft tomorrow and resubmit it for larger 
discussion.
Today I have to finish some other drafts before the deadline.

I await other opinions about this.  To be sure, putting something into 
an Appendix
is also an acknowledgement of relevance, but at the same time an attempt to
sharpen focus and enable separation of emphasis in case a working group 
might
be formed.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Mon, 9 Jul 2012 19:48:18 +0200

Hi all,

if we want to have something like WiFi offloading in
our document and want to become provider independent and offer QoS, Security etc.,
I guess we have to include here some requirements in the draft and not having it only
in the Appendix.
On the other hand if all the work is done in MIF WG we can reference this.

Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Charles E. Perkins [mailto:[email-masked]]
Gesendet: Montag, 9. Juli 2012 16:02
An: [email-masked]
Cc: Schott, Roland; [email-masked]; DUREL Sophie OLNC/NAD/TIP; MOUSTAFA Hassnaa RD-CORE; BINET David OLNC/NAD/TIP; von Hugo, Dirk
Betreff: Assisting network selection [was, Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt]

Hello Pierrick,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 01:43:59 +0200

Hi all,

regarding our new version I make the proposal to update
the introduction an terminology part by some references/cites.
Therefore I have put the information I had about section 1, 3 and 11
together and combined it.

I suggest also referencing to draft-sun-fmc-use-case-00.

---

1.  Introduction

   With the network heterogeneity and huge demand of multimedia and
   audio-visual services and applications, users' satisfaction is the
   aim of each service provider to reduce the churn, promote new
   services and improve the ARPU (Average Revenue per User).  A crowded
   market is observed with many players providing Internet and
   entertainment services which triggers new business models considering
   users' experience and considering roaming agreement between different
   operators.  In this crowded market, the new expectations for users'
   consumption style focus on personalized and interactive usage
   allowing users on one hand to share content across many devices and
   with other users and on the other hand to access content all
   seamlessly at the touch of a button.

   Under the term Fixed-Mobile Convergence various meanings can be understood.
   This document has not the ambition 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.

   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 defined architecture as
   described in [TS23.203] and [TS29.212]. Additionally IETF has also described
   how QoS can be achieved over IP [RFC 5865].

   This document proposes a set of requirements based on use cases
   including those discussed in [I-D.draft-sun-fmc-use-case-00].
   These use  cases have been underdiscussion in BBF [WT-203].
   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.

   This document identifies and analyzes issues that have arisen so far
   and elaborates a set of requirements for the FMC protocol design.

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:

   Codec

      Compression/Decompression of multimedia data through a hardware
      device or software.

   CPE

      Customer Premises Equipment.  Equipment found in the customer's
      physical location and provided by the network operator or service
      providers.  DSL routers, Set-Top-Box (STB), 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 3 rd party.

   host_id

      an identifier for the wireless device, as described in
      [I-D.ietf-intarea-nat-reveal-analysis].

   Port set

      a defined set of ports, in this document 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.

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.

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

11.2.  Informative references

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.

   [RFC6264]  Jiang, S., Guo, D., and B. Carpenter, "An Incremental
              Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
              June 2011.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [TS29.212]
              "3GPP TS29.212, Policy and Charging Control (PCC) over
              Gx/Sd reference point", December 2011.

   [TS23.203]
              "3GPP TS23.203, Policy and Charging control architecture",
              December 2011.

   [RFC 5865]
              Baker, F., Polk, J., Dolly, M.,A Differentiated Services Code
              Point (DSCP)for Capacity-Admitted, May 2012 Traffic

   [TR23.829]
              "3GPP TR23.829, Local IP Access and Selected IP Traffic
              Offload (LIPA-SIPTO)", October 2010.

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

   [WT146]    "Broadband Forum Working Text WT-146, Subscriber
              Sessions", June 2011.

   [I-D.ietf-intarea-nat-reveal-analysis]
              Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Solution Candidates to Reveal a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              draft-ietf-intarea-nat-reveal-analysis-02 (work in
              progress), April 2012.

   [WT203]    "Broadband Forum Working Text WT-203, Interworking between
              Next Generation Fixed and 3GPP Wireless Access",
              December 2011.

   [samog]    "3GPP TR 23.852 V1.0.0, Study on S2a Mobility based On GTP
              & WLAN access to EPC (SaMOG) (Release 11)", December 2011.

   [ieee802.11]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications", IEEE Standard 802.11, 2008",
              2008.

   [I-D.draft-sun-fmc-use-case-00]
           Xie, C., Sun, Q., Use Cases and Requirements in Fixed Mobile
             Convergence (work in progress), July 2012

---

Regards

Roland

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 10 Jul 2012 12:25:43 -0700

Hello Roland,

I am O.K. with most of this, but it seems to me that we should also cite
the ITU document, and any relevant 3GPP document as well as the BBF
document  ( BBF [WT-203] as below ).  Also, I think we should cite the
Problem Statement document (draft-xue-intarea-fmc-ps) as well as
the Use Case ( draft-sun-fmc-use-case ) document.

Is this O.K.?

Besides that, we still have quite a few citations that are not
referenced in the body of the document.  It would be nice to
find good places to make the references.

I'm updating the .xml file to have proper cross references and
I'll include what I have for the above documents; if people would
prefer for them to not be cited it is quite easy to remove them
later.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Fri, 6 Jul 2012 08:16:21 +0000

Hi Roland,

Kindest regards,
Hassnaa

-----Message d'origine-----

Hi Charles and all,

s.b.

-----Ursprüngliche Nachricht-----
Von: Charles E. Perkins [mailto:[email-masked]]
Gesendet: Dienstag, 12. Juni 2012 23:50
An: Schott, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; von Hugo, Dirk
Betreff: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Jul 2012 17:12:06 -0700

Hello folks,

I've done the initial proofreading of the revised document, and added
text for the comments that have been received.  Here are the
current intermediate version URLs:

http://www.psg.com/~charliep/ietf84/draft-schott-fmc-requirements-02.txt
http://www.psg.com/~charliep/ietf84/draft-schott-fmc-requirements-02.xml

I will upload this to the IETF submission page tomorrow if all is O.K.

It would be nice to find a place to reference the SAMOG citation
and the remaining dangling citations.  I did add some cross references
for some of that were left dangling in previous revisions.

I do have some questions.  First, please check my definition of
"service host".

Next, I was not clear about this text:

>     This requires on one hand technical solutions to allow the
>     selection of the appropriate interface to be used by the MN.

What is the "other hand"?

--

One area that I think needs emphasis, is the possibility for policy
coordination between the CPE/Residential Gateway and the
Border Gateway (?or service host?) or whatever it is called in the
operator's network.  It is briefly alluded to, but this could end up
to be one of the main work areas in the IETF.

--

Lastly, I did not add any text related to the question whether the
Network Access Selection requirements belongs in an Appendix or
in the main body of the text.  I can still change this before
submission if people have ideas.

-- 
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 08:06:51 +0000

Hi, Charles,

Please see inline.

BR,
Pierrick

> De : Charles E. Perkins [mailto:[email-masked]]
> Envoyé : jeudi 12 juillet 2012 02:12
> À : [email-masked]
> Cc : MOUSTAFA Hassnaa RD-CORE; DUREL Sophie OLNC/NAD/TIP; [email-masked];
> BINET David OLNC/NAD/TIP; SEITE Pierrick RD-RESA; Dirk.von-
> [email-masked]
> requirements-01.txt - Input
> 
> 
> 
> Hello folks,
> 

The draft doesn't , you probably wanted to refer to "Service node", right?

actually it is not clear what is a "service node".... as you mentioned below, it seems to be a border gateway. If it is correct, I'd prefer to use "border gateway" which is well-known terminology.

> What is the "other hand"?

I didn't write this piece of text but if "One hand" is the access selection, IMU, the "other hand" would be the adaptation of the content. Anyway, we can remove "one hand" from the sentence.

I agree, we need to elaborate on this.

I'm fine with current proposal.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Jul 2012 10:52:24 -0700

Hello again Pierrick and all,

I've finished the new revision.  One more point:

> I agree, we need to elaborate on this.

I made the following paragraph in section 7.1.1 related to the 
Discussion about
network involvement in maintaining service levels, which seemed to be the
closest match.

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

I hope it is O.K.  If not, I can easily change it even before Monday,
but I would like to go ahead and submit the draft.

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Jul 2012 11:16:42 -0700

Hello folks,

I've uploaded the revised document to the IETF site.

The new system is superfast.  It's already available:
http://www.ietf.org/id/draft-schott-fmc-requirements-02.txt

Comments will be appreciated.

-- 
Regards,
Charlie P.

---

From: Keshav.A.K. <[email-masked]>
Date: Tue, 17 Jul 2012 10:53:38 +0530

Hi,

I have some of the basic question about this FMC-draft w.r.t   ietf scope.

1.  What is the basis of selection of access network type in IETF ? 

(user preference, profile, capability will be based on some type of policy
?)

What is the requirement for IETF here  ? 

2.  What do you mean by  'mechanism  between operator and access network' to
manage

"mobility traffic-flow" of the user ?

3.  Why MN try to have Global View of network congestion ? 

Trying to say MN to have some kind of end to end service mapping with for
particular user/type ?

Dynamic setup and tear down for such mapping on 'pre-established flows'
based on MN request ?

4.w.r.t Streaming requirement , any thoughts of deriving, some kind of
standardized pre-determined number -> which maps to service ? 

  Otherwise what is the scope for ietf about (resolution/screen size,
connectivity type ? 

Regards,

Keshava.A.K.

Huawei Technology India,  Bangalore.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Thursday, July 12, 2012 11:47 PM
To: [email-masked]
Subject: [fmc] draft-schott-fmc-requirements-02.txt

Hello folks,

-- 

Regards,

Charlie P.

fmc mailing list

[email-masked]

---

From: <[email-masked]>
Date: Wed, 18 Jul 2012 15:13:16 +0200

Hi Charles,

thank you for your comments,
see below

-----Ursprüngliche Nachricht-----
Von: Charles E. Perkins [mailto:[email-masked]]
Gesendet: Dienstag, 10. Juli 2012 21:26
An: Schott, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; von Hugo, Dirk
Betreff: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-01.txt - Input

Hello Roland,

Is this O.K.?

RS: yes

RS: I'll try to find proper cross references and if not we
should remove them.

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: <[email-masked]>
Date: Wed, 18 Jul 2012 16:09:07 +0200

Hi Charles,

thank you for uploading and editing
the draft during my vacation.

Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Charles E. Perkins
Gesendet: Donnerstag, 12. Juli 2012 20:17
An: [email-masked]
Betreff: [fmc] draft-schott-fmc-requirements-02.txt

Hello folks,

--
Regards,
Charlie P.