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

["MELIA TELEMACO" <[e-mail]>]

Hi all,

The ID Carlos posted proposes a network based signaling to achieve flow mobility. As Juan Carlos stated earlier the LMA takes flow mobility decisions based on external triggers and while these triggers are out of scope for the solution design document people might feel free to adopt any of them. Although achieving the same goal, the proposed method is semantically different from the one specified for DSMIP. We should not mix things.

telemaco

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Carlos Jesús Bernardos Cano
Envoyé : jeudi 22 juillet 2010 07:15
À : Tran Minh Trung
Cc : [e-mail]
Objet : Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00

Hi Tran Minh,

Some comments inline below...

On Wed, 2010-07-21 at 19:17 +0900, Tran Minh Trung wrote:
> 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.

I think the case of an MN handoff should not be tackled as a particular
case of flow mobility. I'd try to explain why is so IMHO. There are two
different cases: simultaneous attachment to different access
technologies and sequential attachment. The first case is the one I
think you are referring to, and for that I think we cannot assume the MN
can easily control the movement of flows. With current charter, we are
not allowed to define any signaling between the MN and the MAG, and
therefore -- how Pierrick said in another e-mail -- it is quite hard to
define an MN-centric solution for flow mobility.
The second case is really what I understand as inter-tech handoff, and
for that we probably need to tackle that in a different way than flow
mobility. Using the logical interface, that case actually can be
supported quite easily, as we just basically need to follow RFC5213, but
benefiting from the fact that the address(es) that the MN is using
remains the same (it can be seen as an intra-technology handover from
the viewpoint of the MN).
> 
> 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.

See above.

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

Why do we need to know where the triggers come from? If the LMA knows
that it has to move flow X from MN's interface a to MN's interface b...
does it really matter where this flow mobility decision come from (from
the viewpoint of the solution design)?

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

In the drafted solution, the LMA is aware of this event. However that
event is not the trigger itself for moving flows. The deciding entity
(which could be the LMA itself, or even the MAG) should be aware of the
interfaces through which the MN is attached to the PMIPv6 domain, so it
can use that information when deciding to move flows.

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

Why do we need this? I don't understand.

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

It can be the LMA or any other entity. The LMA is the entity signaling
and managing the mobility of flows, but it is not necessarily the entity
making the decisions about flow mobility.

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

I don't agree with that. The logical interface is an artifact at the MN
side, to avoid requiring changes at the host stack. The network can --
and in my opinion must -- know about the different physical interfaces
that the mobile has, so it can handle the movement of flows.

> 
> From this point, I think the 'Unique prefix per physical interface'
> scenario is not necessary.

This is not exactly the same that saying that the LMA sees at layer 3
only the logical interface, IMHO. We still need to discuss and agree
about whether this "unique (set of) prefix(es) per physical interface"
model is required or not.

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

See above.

Thanks,

Carlos

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

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67