Subject: Re: [mif] mif Digest, Vol 4, Issue 22

From: yonghao sun <[email-masked]>
Date: Thu, 12 Feb 2009 15:54:34 +0800

Hi, all:
  I have just read this draft,in my opinion,the problem proposed by
this draft is a problem that is need to be sloved currently,Thanks Mr
Deng to propsoe such question for us to discuss!

2009/2/10  <[email-masked]>:
> Send mif mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/mif
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mif digest..."
>
>
> Today's Topics:
>
>   1. How the current application of mobile host works in the MIF
>      (Hui Deng)
>   2. Re: Charter proposal (Qin Wu)
>   3. Re: IP model for multiple mode mobile terminal (Peny Yang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Feb 2009 09:23:43 +0800
> From: Hui Deng <[email-masked]>
> Subject: [mif] How the current application of mobile host works in the
>        MIF
> To: mif <[email-masked]>
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello, all
>
> One strong motivation for MIF to propose is to support the mobile terminal
> which has multiple interfaces and would like to visit Internet.
>
> Let me try to clarify some difference here:
> 1) History
> Applications in the host don't choose the source address, it relies on
> socket to do it.
>
> 2) Now (MIF)
> It has come out a new component which is called as the connection manager,
> when the mobile has multiple interface, subscriber could decide which
> interface to use based
> on the connection manager.
> Then it lead to various ways to do implementations, application may talk
> with the connection manager
> then talk with socket, another case is application may only talk with the
> connection manager,
> the connection manager could talk with the socket et al.
>
> Anyhow, it is the scenario and current practice which MIF is targeting.
>
> One related document which I could find about the connection manager as the
> below link shows
>
>
> http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html
>
> Thanks for your discussion.
> Best regards,
>
> -Hui Deng
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/mif/attachments/20090210/03c9eaff/attachment.htm>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Feb 2009 09:48:24 +0800
> From: Qin Wu <[email-masked]>
> Subject: Re: [mif] Charter proposal
> To: Jacni Qin <[email-masked]>
> Cc: mif <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi, Jacni:
> Thank for your concern. Please see the replies below.
> -Qin
>  ----- Original Message -----
>  From: Jacni Qin
>  To: Qin Wu
>  Cc: Hui Deng ; mif
>  Sent: Monday, February 09, 2009 9:35 PM
>  Subject: Re: [mif] Charter proposal
>
>
>  hi Wu,
>
>
>  On Mon, Feb 9, 2009 at 3:00 PM, Qin Wu <[email-masked]> wrote:
>
>    Hi,hui:
>    few comments on the charter scope.
>    Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF?
>    Shall we consider the case in which one node with multiple interfaces connects to one access network?
>
>  what's the difference between "multiple access network" and "one access network" that you concern? Could you please state it more clearly?
>  [Qin]: One access network can be further divided into multiple subnets. Each subnet in the same access network supports the same access technology.When the node with two interfaces attaches to two access links in one access network, it means the node with two interfaces connects to two subnets in the same access network and each subnet serves one interface.Is it a real scenario MIF needs to consider?
>  Regarding the multiple access networks, What I understand is the node with two interfaces connects two different type of access network, each access network support one type of access technology.
>  In a word, multiple access network can be divided into multiple hetergeneous access networks and multiple homogeneous access networks, also multiple homogeneous access networks can be viewed as one access network, is it true?
>
>
>    If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF?
>
>  I don't believe that.:-)
>  [Qin] Thank for your point. could you elaborate it in details?:) Actually I have difficulty to understand the exact meaning of multi-homed?
>
>  regards,
>
>  Jacni
>
>
>    -Qin
>      ----- Original Message -----
>      From: Hui Deng
>      To: mif
>      Sent: Tuesday, February 03, 2009 5:22 PM
>      Subject: [mif] Charter proposal
>
>
>      Hi, all
>
>      Please feel free to help to comments our charter proposal.
>
>      Background and Motivation
>         A multi-homed host has multiple network interfaces (physical and/or
>         virtual).  For example, a node may be connected to a wired Ethernet
>
>         LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
>         or one or multiple automatic or manual tunnels. Current laptops and
>         smartphones typically have multiple access network interfaces. RFC 5113
>         already specify basic "Network Discovery and Selection Problem".
>
>         But the IETF RFCs only allow one default network connection.
>         If there are multiple connections of the host, all the flows will go
>         to the default gateway based on RFC1122 description. One default
>         gateway guarantees the host always has one entry to the network, but
>         leads to difficulties when multiple connections are simultaneously active.
>
>         A multi-homed host receives node configuration information from each
>         of its access networks.  Some configuration objects are global to the
>         node, some are local to the interface.  Various issues arise when
>         multiple configuration objects that are global to the node are
>         received on the many interfaces the multi-homed host has.  Therefore,
>         there is a need to define the appropriate behavior of an IP stack and
>         possibly define protocols to manage these cases. RFC 3484 proposed
>         default address selection for IPv6 could be a refernce to this work.
>
>      Proposed Work:
>      -------------
>      The proposed mif Working Group will focus on the following topics
>      relevant for multiple interfaces:
>
>       Split DNS:
>         o A multi-homed host may have one of its interfaces facing a DNS
>         service which resolves private names and addresses(Proposed Standard)
>        A mechanism is needed for selecting the right DNS service for the DNS query
>
>       Routing of multiple interfaces:
>         o A multi-homed host may have multiple routes to a destination.
>         However, by default, it may not have enough information to choose best
>         interface.Thus a host would need to be provided with more information
>         for interface selection(Proposed Standard)
>
>       Address Selection Policy:
>         o a multi-homed host with IPv4 and IPv6 connectivity might need to receive
>         an update of its default address selection policy.  However, that policy
>         is only valid within the context of the interface it received it from.
>         Each network on which the node is connected might have a different address
>         policy to push to the connecting nodes". The received policies might be
>         conflicting. A standard mechanism is needed to determine what should be
>         the behavior of the host in such case.(Proposed Standard)
>
>      The BoF proposes to discuss the above items and gauge interest in
>      forming a working Group. There is already work in progress addressing
>      the identified problems, which is expected to be the starting point
>      for the deliverables.
>
>      The proposed activity will be complementary to the existing IETF
>      Working Groups, notably the DHC,6MAN and MEXT WGs.
>
>
>      Many thanks for your comments
>
>      -Hui
>
>
>
> --------------------------------------------------------------------------
>
>
>      _______________________________________________
>      mif mailing list
>      [email-masked]
>      https://www.ietf.org/mailman/listinfo/mif
>
>
>    _______________________________________________
>    mif mailing list
>    [email-masked]
>    https://www.ietf.org/mailman/listinfo/mif
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/mif/attachments/20090210/0574217d/attachment.htm>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 Feb 2009 11:44:47 +0800
> From: Peny Yang <[email-masked]>
> Subject: Re: [mif] IP model for multiple mode mobile terminal
> To: Qin Wu <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hey, Qin:
>
> On Mon, Feb 9, 2009 at 2:14 PM, Qin Wu <[email-masked]> wrote:
>> Hi,Peny:
>> I lost these thread discussion for a while. Thank for your clarification. I
>> fully agree with your most point.As regarding no-mip case for generic IP
>> model,even without user experience for service continuity,i.e., nomadicity,
>> the teminal with multiple interface also can work.The more detailed
>> mechanism is for further study.
> [Peny] I don't get your point here. Could you add more lines to show
> the relationship between Nomadic and MIF?
>
>> as regarding whether generic MIP solution can make the seamless
>> handover, you are right. Some mobility enhanced work have already been done
>> in mipshop working group,e.g.,RFC5270.
> [Peny] Well. MIP case is out of the scope of MIF. I am afraid that
> it's not a good idea to discuss it in this list.
>
>
> Peny
>
>> Best regards!~
>> -Qin
>> ----- Original Message -----
>> From: "Peny Yang" <[email-masked]>
>> To: "Qin Wu" [email-masked]
>> Cc: "mif" <[email-masked]>
>> Hi, Qin:
>>
>> It's a interesting point. Check the lines below:
>>
>> On Sat, Jan 17, 2009 at 7:03 PM, w53375 <sunseawq at huawei.com> wrote:
>>> Thanks for your reply, Please see the follow up comments below.
>>> -Qin
>>>
>>> ----- Original Message -----
>>> From: Hui Deng
>>> To: Qin Wu
>>> Cc: mif at ietf.org
>>> Sent: Wednesday, January 14, 2009 6:35 AM
>>> Subject: IP model for multiple mode mobile terminal
>>> Hi, Qin,
>>>
>>> Thanks for your comments. see below inline reply.
>>> 2009/1/8 Qin Wu <sunseawq at huawei.com>
>>>>
>>>> Interesting topic, As we discussed before, you thought Internet IP
>>>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today
>>>> it
>>>> is a little different, mobile terminal has multiple modes, it would like
>>>> to
>>>> use all of them simulatenously which orginal IP model doesn't work any
>>>> more
>>>> on it.
>>>
>>> [Qin]What I understand in order to achieve seamless handover during the
>>> inter-technology handover, the UE is required to support dual
>>> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access
>>> network
>>> to the CDMA access network, the UE can attach to WIMAX and CDMA link
>>> simuteneusly,in this situation, the traffic can be bicasted to the UE
>>> through two links, the packet loss can be avoided wholly, however, the
>>> difficulty is when the UE frequently moves between hetergeneous network at
>>> high speed, there are great chanllenge for the UE to maintain the WiMAX
>>> link
>>> and CDMA link simuteneously.
>> [Peny] Are you talking about MIP case or non-MIP case?
>> In case of MIP, I agree with you.
>> In case of non-MIP, it seems in IETF there is no way to bi-cast the
>> streams to two different interfaces with two addresses of MN.
>> I just review the discussion in this list. Personally, I think MIF is
>> to solve the issue of GENERIC  IP model. As hui said previously, IP
>> model should no longer have the original assumption of "one link" as
>> many terminals have multiple links so far.
>> MIP has the way to support the multiple links in MN. I once did some
>> work on this as well. Basically, Generic MIP solution is not adequate
>> to make the seamless handover. It needs some low layer modifications
>> (such as one address for multiple link, prevent the high layers to
>> detecting the link transfer event, etc). All the problems originated
>> from the "one default link" design of current OS. Maybe it's the time
>> to do something to improve the generic IP model for multiple link
>> support in MN.
>>
>>> it seems that dynamical provision and routing, coordination and
>>> synchronization will become more complicated, simple way make deployment
>>> easy, it is the way of Internet exist
>>> [Qin} I agree more optimized approach can be used to faciliate utilizing
>>> the
>>> network resource and better user experience.
>>> thanks
>> [Peny] I agree with you two as well.
>>
>> BRG
>> Peny
>> _______________________________________________
>> mif mailing list
>> mif at ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
>> *******************************************************************************************
>> This email and its attachments contain confidential information from HUAWEI,
>> which is intended only for the person or entity whose address is listed
>> above. Any use of the information contained herein in any way (including,
>> but not limited to, total or partial disclosure, reproduction, or
>> dissemination) by persons other than the intended recipient(s) is
>> prohibited. If you receive this e-mail in error, please notify the sender by
>> phone or email immediately and delete it!
>> *******************************************************************************************
>
>
> ------------------------------
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>
> End of mif Digest, Vol 4, Issue 22
> **********************************
>