Re: [netext] Comments & Questions on theI-D:draft-bernardos-netext-pmipv6-flowmob-00

["Zuniga, Juan Carlos" <[e-mail]>]

Pierrick, Tran Minh,

As Carlos mentioned in his first response to Tran Minh, the necessary requirements of the logical interface to support flow mobility should be captured in the applicability document. The current wording in "draft-melia-netext-logical-interface-support-01" is a little messy due to the last minute merger of two other i-ds, but this is the place where the overall system should be described (i.e. beyond PMIP changes).

Regarding the MN driven decision, we discussed in the past that a trigger could be sent to the LMA via L2.5 signalling. This would not be in scope for the solution document (draft-bernardos-netext-pmipv6-flowmob-00) which, as Pierrick points out, only considers network based solutions. However, it should be documented in the applicability document as this could be one more input at the LMA to trigger the flow mobility (from the network). By making this distinction, we allow both MN and LMA to start the flow mobility, and still limit the mobility management solution to be network based.

Regards,

Juan-Carlos


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: Wednesday, July 21, 2010 9:52 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [netext] Comments & Questions on theI-D:draft-bernardos-
> netext-pmipv6-flowmob-00
> 
> 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