Subject: [fmc] WG: New Version Notification for draft-xue-fmc-ps-03.txt

From: <[email-masked]>
Date: Mon, 22 Oct 2012 17:21:45 +0200

Dear all,
For the FMC BoF in Atlanta we have submitted a new version for PS draft where we have focussed on two use cases which should be specific for operators use case to provide fixed mobile converged services via interworking of their heterogeneous access networks.
Group Id handling (for a subscriber owning multiple UE devices) and UE mobility within fixed networks are described as potential FMC use cases. Please don't hesitate to send your comments to the list!

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet: Montag, 22. Oktober 2012 17:12
An: von Hugo, Dirk
Cc: [email-masked]; [email-masked]
Betreff: New Version Notification for draft-xue-fmc-ps-03.txt

A new version of I-D, draft-xue-fmc-ps-03.txt
has been successfully submitted by Dirk von Hugo and posted to the
IETF repository.

Filename:        draft-xue-fmc-ps
Revision:        03
Title:           Problem Statement for Fixed Mobile Convergence
Creation date:   2012-10-22
WG ID:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-03.txt
Status:          http://datatracker.ietf.org/doc/draft-xue-fmc-ps
Htmlized:        http://tools.ietf.org/html/draft-xue-fmc-ps-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-xue-fmc-ps-03

Abstract:
   The purpose of this document is to analyze the issues that have
   arisen so far and to propose several use cases for the Fixed Mobile
   Convergence.  This document gives a brief overview of the assumed
   Fixed Mobile Convergence architecture and related works and then
   introduces several Intarea type of use cases based on the partnership
   in Fixed Mobile Convergence architecture, such as group
   identification, mobility consideration, such as mobility status
   reporting in Wi-Fi network.

The IETF Secretariat

---

From: <[email-masked]>
Date: Tue, 23 Oct 2012 10:03:11 +0200

Hi Dirk,

I read the new version you submitted. I have some questions for clarification:

(1) You introduced two new identifiers: Group ID and Subscriber ID. What is the difference between these two identifiers?

(2) The document says:

"   There are many standardization issues related to FMC and protocol
   extension work needed.  If these issues are fixed, the advantages
   brought out will be:

   1.  Optimize traffic management (per-UE granularity in the fixed
       broadband network)" 

(2.1) Isn't this the purpose of "host identification"? 
(2.2) Is this really possible if you introduce the concept of GroupID and not "host identifier"?

(3) The text says:

"The subscriber ID must be contained in the traffic packet of the
   subscriber in order to achieve policy enforcement in the device node
   in the network."

(3.1) Why a subscriber identifier is needed to be leaked into IP packets?
(3.2) Who is responsible for injecting this information in IP packets?
(3.3) How a device will discover/learn/"be provisioned" with this information?
(3.4) How to trust this information? Is the device injecting this information a trusted device?
(3.5) Solution examples you listed are bound to IP, do you have in mind examples which would not be similar to a "host identifier"?

(4) Several parts of the GorupID text are close to the host identification issue. Could you please explain the difference?

(5) The text does not summarize the technical issues; for instance: 

(5.1) What are the technical issues in Section 4?
(5.2) Why these issues are specific to FMC? 
(5.3) Is inter-operator policy exchange in scope?
(5.4) Why existing IETF tools do not solve encountered issues?

Thanks.
Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de [email-masked]
>Envoyé : lundi 22 octobre 2012 17:22
>À : [email-masked]
>Cc : [email-masked]; [email-masked]
>Objet : [fmc] WG: New Version Notification for draft-xue-fmc-ps-03.txt
>
>
>Dear all,
>For the FMC BoF in Atlanta we have submitted a new version for 
>PS draft where we have focussed on two use cases which should 
>be specific for operators use case to provide fixed mobile 
>converged services via interworking of their heterogeneous 
>access networks.
>Group Id handling (for a subscriber owning multiple UE 
>devices) and UE mobility within fixed networks are described 
>as potential FMC use cases. Please don't hesitate to send your 
>comments to the list!
>
>Best regards
>Dirk
>
>URL:             
>http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-03.txt
>_______________________________________________
>fmc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/fmc
>

---

From: <[email-masked]>
Date: Tue, 23 Oct 2012 18:19:48 +0200

Hi Med,
Thank you for the detailed questions. I hope to have fully understood them and try to answer as far as what is my thinking:

(1) In fact the Group Id shall denote the group of all devices belonging to one subscriber so in the document the expression Group Id is identical to Subscriber Id. Sorry for the confusion.

(2) As is well known in the mobile network sessions are established on a per contract/SIM card/UE basis whereas in a fixed network the identification is based on the access level (e.g. residential site owner) which with several (e.g. own and visiting) devices within a local network may cover different UEs. To resolve this ambiguity in the fixed mobile scenario where UEs may belong to the same or different customers the Group Id can help to address the 'right' UE or UEs. So perhaps in addition to Group Id identification we may need further mechanisms to achieve true per-UE granularity (e.g. including device capabilities, service preference, policies, etc.). It may be true that in other scenarios per-UE granularity is achieved by using a proper 'host identifier' alone, but here we will focus on FMC scenario.

(3) The group id concept shall denote the destination address of IP traffic for all devices of a subscriber to be able to receive the information (and the operator may decide on the most useful access technology). How to achieve the Group Id to show up in the IP packet is out of scope but a possible mechanism may be either deployed in the UE or in a central network entity to map IP addresses of all UEs within a subscribers group to the Group Id and use this, perhaps similar to the logical interface concept described in http://www.ietf.org/id/draft-ietf-netext-logical-interface-support-06.txt. Implementation details are not yet defined but the mapping would be part of the contract bewteen customer and operator. Since not a single host but a group of devices are addressed here I don't see the similarity to a "host identifier".

(4) Difference between group_id and host_id are IMO the fact that with group_id an operator can address, account, authorise, and authenticate different physical devices and access interfaces via a single subscription as is required for FMC scenario. Further potential applications may be service differentiation according to device capabilities but here similar aspects as for host_id issue come into consideration - thus there is indeed some overlap between both use cases.

(5) Some of the technical issues of this draft have been explained above such as for sect. 4 on group_id the unambiguous identification of any device in the ownership of a customer/subscriber which is especially an issue in fixed networks.
Furthermore the synchronization of different devices under the same group_id may be a technical issue to be solved. Additional issue should be brought up and discussed on this list ...

The issues are specific for 'seamless' service access via multiple devices or devices with multiple interfaces to such heterogeneous access domains as mobile and fixed networks administrated by different operators but might perhaps also apply to different WiFi hotspot providers.

I think that as discussed in the BarBOF in Vancouver "if there is no relationship between fixed network and mobile network, UE is not going to be able to make use of operator services" so a relationship which may include kind of policy exchange is assumed.

AFAIK there is no IETF activity solving those issues right now but of course that will be task for the list and the upcoming session to discuss and find out.

Thanks and I hope to have helped for clarification and that my co-authors will correct me if I was wrong on some parts.

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Dienstag, 23. Oktober 2012 10:03
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: [fmc] New Version Notification for draft-xue-fmc-ps-03.txt

Hi Dirk,

(2) The document says:

(3) The text says:

Thanks.
Cheers,
Med