Re: [netext] netext Digest, Vol 14, Issue 14

["gsnaa.v2" <[e-mail]>]

Hi all,
As Pierrick mentioned, I think a very important question we should solve now is that whether MN should involve in the complex mobility management. Although the document “draft-gundavelli-netext-extensions-motivation-00.txt” has declared that the MN can involve in the mobility management in some special scenarios, including vertical handover, multihoming and flow mobility, this question is still being discussed and we can not reach a consensus about it. 
Regards,
Zhiwei Yan


2010-07-22 



gsnaa.v2 



发件人： netext-request 
发送时间： 2010-07-22  03:00:18 
收件人： netext 
抄送： 
主题： netext Digest, Vol 14, Issue 14 
 
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 
https://www.ietf.org/mailman/listinfo/netext
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.
Send netext mailing list submissions to
[e-mail]
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/netext
or, via email, send a message with subject or body 'help' to
[e-mail]
You can reach the person managing the list at
[e-mail]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netext digest..."
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Today's Topics:
   1. Re: Comments & Questions on the
      I-D:draft-bernardos-netext-pmipv6-flowmob-00
      ([e-mail])
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
------------------------------------------------------------
From:  <[e-mail]>
To:  <[e-mail]>
 <[e-mail]>
Subject:  Re: [netext] Comments & Questions on theI-D:draft-bernardos-netext-pmipv6-flowmob-00
Date:  Wed21 Jul 2010 15:51:45 +0200
Hi Tran Minh and Carlos,
Please let me jump into this interesting discussion.
Tran Minh, You're right, theoretically both the LMA and the MN should also be able to make decision about the path to use for a given IP flow. In addition to handover triggers at the MN side that you are suggesting, it may be not desirable that the LMA enforces its decision to the MN despite of the user preferences. 
However, a MN driven decision in a network based mobility management solution is quite tricky without MN signalling (and we definitely want to avoid such a signalling, I don't want to reopen the debate :-)). For example, you wrote:
"The MAG can be aware of this movement by analyzing the packets received from the MN and inform the LMA."
I don't think such a simple solution could be sufficient, since there are some cases where the MN does not use the uplink very often, e.g. RTP streaming. 
So, trying to support the MN driven routing decision would bring additional complexity and delay in the design of a solution. So, for the sake of pragmatism, it makes sense to focus, in a first step, on a routing decision driven by the LMA where the MN just updates its uplink path according to where packets are received.
Then we need to clarify the requirement for handover triggers to be processed at the MN side only. If so, we could think about extension to the base solution as drafted in draft-bernardos.
Regards,
Pierrick
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part
> de Tran Minh Trung
> Envoyé : mercredi 21 juillet 2010 12:17
> à : [e-mail]
> Cc : [e-mail]
> Objet : Re: [netext] Comments & Questions on the I-D:draft-bernardos-
> netext-pmipv6-flowmob-00
> 
> Hi Bernardos,
> 
> Thank you for your reply.
> Pls. see my replies inline.
> 
> 2010/7/21 Carlos Jesús Bernardos Cano <[e-mail]>:
> > Hi Tran Minh,
> >
> > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote:
> >> Hi Bernardos and all,
> >>
> >> I have some comments and questions on the I-D
> >> draft-bernardos-netext-pmipv6-flowmob-00 as follows:
> >
> > Thanks a lot for the feedback. Please see some comments inline below.
> >
> >>
> >> 1) I think the LMA can decide to move down-link flows only. The
> >> up-link flows should be moved by the MN (eg. the MN is aware of the
> >> attachment status via each IF and decide which IF is better for
> >> sending up-link flows). The MAG should be aware of the movement of
> >
> > Our assumption is that the MN does implement the logical interface (as
> > explained in draft-melia-netext-logical-interface-support-01). The LMA
> > has of course the direct control of how downlink flows are routed, but
> > an MN implementing the logical interface will just mirror that behavior
> > with the uplink packets. Therefore, the LMA is the only entity
> > controlling flow mobility both in downlink and uplink directions.
> >
> 
> 
> >> up-link flows and inform the LMA to update information.
> >
> > In the current draft, the MAG is informed about flow mobility operations
> > by the LMA. There is signaling defined for that purpose.
> >
> 
> Let's consider the case that the MN performs a handoff. I think it is
> a special case of flow mobility when all flows are moved from an
> interface to another. The MAG is aware of that event and informs the
> LMA by using handoff indicator. So I think that we may consider the
> same for the case that flows are moved by the MN. The MAG can be aware
> of this movement by analyzing the packets received from the MN and
> inform the LMA.
> 
> In real network both operator (the LMA) and user (the MN) can set and
> perform the rules to select the best interface (access technologies)
> for serving a specific service flow. So we may better support for both
> of them.
> 
> 
> >>
> >> 2) It is necessary to discuss about the flow mobility triggers. The
> >> signaling procedure between MAG/LMA depends on trigger. With different
> >> kind of trigger we have to use different signaling procedure.
> >
> > The trigger is out of the scope of the solution draft. Any kind of
> > trigger could be supported. For example a central policy entity can make
> > the decisions based on the overall state of the network and trigger the
> > LMA. IMHO, which entity triggers the LMA can be left out of the scope,
> > as it does not have an impact on the protocol (with current design).
> >
> 
> I agree that it is not necessary to discuss detail about trigger in
> the solution draft.
> However, we have to mention about where do triggers come from?. Basing
> on the source of trigger we have to use different signaling procedure.
> 
> For examples:
> 
> - The MN performs new attachment -> The MAG is aware of that event and
> informs the LMA about new attachment and asks the LMA whether to move
> some exiting flows to new attachment.
> - The MAG receives new flows from an interface of the MN -> The MAG
> informs and asks LMA to check whether this flow is a new flow or just
> a flow moved from another interface of the MN.
> - The LMA sees some changes in the network conditions or service
> profile of the MN -> The LMA decides to move some flows to get better
> services and inform MAGs.
> 
> 
> >>
> >> 3) The proposed solution requires new signaling messages and new
> >> caching table. It makes more complicated for implementing and
> >> combining with the existing standard than just extending the current
> >> PBU/PBA messages as well as BCE and BULE caching table.
> >
> 
> > Well, this was a design decision (there might be of course others). We
> > preferred not to overload existing signaling. Regarding the data
> > structures, they are just logical ones, they could also even be
> > implemented by extending BCE and BUL.
> >
> >>
> >> 4) What are the necessary requirements of the logical interface to
> >> support flow mobility?
> >
> > This should be covered by
> > draft-melia-netext-logical-interface-support-01.
> >
> 
> I get some confuses about the logical interface described in the I-D
> "draft-melia-netext-logical-interface-support-" and the logical
> interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00"
> 
> IMHO, when we use logical interface, the (set of) prefix(es) is
> assigned to the logical interface only, not to physical interface. The
> LMA, at layer 3, may see only the logical interface.
> 
> From this point, I think the 'Unique prefix per physical interface'
> scenario is not necessary.
> 
> However if we consider this scenario, then we can justify why we need
> it as Julien suggested. And also we can discuss to make clear that why
> we use the logical interface to hide the physical interfaces but we
> still separate prefix(es) assignment basing on physical interfaces.
> 
> ---
> Tran Minh Trung
> 
> >>
> >> I hope that we can have more discussion on these issues before making
> >> it as a WG document.
> >
> > Sure, useful discussion as this is very very welcome. Thanks!
> >
> > Kind Regards,
> >
> > Carlos
> >
> >>
> >> Regards,
> >> Tran Minh Trung
> >>
> >
> > --
> > Carlos Jesús Bernardos Cano     http://www.netcoms.net
> > GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >
> 
> 
> 
> --
> Ph.D., Senior Member
> Electronics and Telecommunications Research Institute
> Standards Research Center
> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
> Tel : [phone],   Fax : [phone]
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
------------------------------------------------------------
_______________________________________________
netext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netext
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com