Re: [netext] Scope of Prefixes in Flow Mobility

["Laganier, Julien" <[e-mail]>]

Hi Telemaco,

One quick comment below:

MELIA, TELEMACO wrote:
> 
> Hi all,
> 
> Let me share few thoughts with you.
> 
> I think that the flow mobility feature can be regarded as a service to
> which mobile customers subscribe.
> This can be a flag in  the mobile node's profile (section 6.2 of RFC
> 5213). I suggest to extend the mandatory fields by adding the flow
> mobility service.
> The LMA will be receiving a PBU with the necessary information and can
> take the decision on whether to assign multiple prefixes or the same
> across different access networks. The presence of the flow mobility bit
> implicitely triggers the extended prefix assignment algorithm.
> The LMA will not be aware of the logical interface but knows that the
> MN can handle flow mobility.
> 
> Now, about filters vs. prefix only configured in the MAG for flow
> mobility. I think we should be flexible and allow both to be
> transferred to the MAG. This allows the MAG to understand flows if
> required (else routing is only possible via IP addreses).

The key point in your sentence above is "if required." 

So far I haven't seen a convincing argument as to why we'd need to signal traffic flow filters in a network-based design. In this situation, I do not know why "we should be flexible"...

(Regarding routing, it seems that the MAG is able to route packets appropriately from and to the mobile node as long as it is aware of the mobile node's prefixes.)

--julien

> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of
> Sri Gundavelli [[e-mail]]
> Sent: Thursday, August 05, 2010 5:18 AM
> To: Tran Minh Trung
> Cc: [e-mail]
> Subject: Re: [netext] Scope of Prefixes in Flow Mobility
> 
> Tran:
> 
> >> However, the LMA may choose to assign the same prefix(es) as well as
> new
> >> prefix(es) if it so chooses based on the ATT field. This would be
> scenario 3
> >> below.
> >>
> 
> Right. We assume the network provides the handover hints. We do not
> have the
> MN-AR interface at this point. When we were writing the base spec, the
> MN-AR
> interface was factored into the design. Julien was working on this and
> some
> where we lost track of this critical interface.
> 
> http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03
> 
> We need to revive this at some point. I was hoping Telemaco/Carlos/Juan
> Carlos will revive this in for different SDO architectures, at least
> that
> was our understanding.
> 
> http://ietfreport.isoc.org/idref/draft-melia-netext-3gpp-mn-ar-if/
> 
> Ideally, the handover hints will come from that interface. If we build
> this
> interface, eventually, the mobile node can express the handover
> preferences
> and flow-path preference. This will allow us to cleanly support the
> shared
> prefix scenario.
> 
> 
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> On 8/4/10 7:09 PM, "Tran Minh Trung" <[e-mail]> wrote:
> 
> > Hi Rajeev,
> >
> > Please see my comments inline:
> >
> > On Thu, Aug 5, 2010 at 2:39 AM, Rajeev Koodli <[e-mail]>
> wrote:
> >>
> >> Hi,
> >>
> >> I am still trying to understand what will not work if we don't make
> this
> >> assumption..
> >>
> >> There are two parts here, which I outlined as 2) & 3) below.
> >>
> >> Signaling extension in Binding Update to inform the LMA to support
> same
> >> prefix assignment. This can be another value assignment for the HI
> field.
> >> When this value is set, the LMA knows that it can assign the same
> >> prefix(es). This is scenario 2 below.
> >>
> >
> > How can we set the value of HI exactly?.  Without signaling from the
> > MN, I think it is not easy.
> > Let's assume that we can set the value of HI exactly. Then if the MN
> > uses 2 logical interfaces to hide two different sub-interface paths,
> > how can LMA differentiate them by just depending on HI?
> >
> >> However, the LMA may choose to assign the same prefix(es) as well as
> new
> >> prefix(es) if it so chooses based on the ATT field. This would be
> scenario 3
> >> below.
> >>
> >
> > I think just ATT is not enough. The MN can be equipped with 2
> > interfaces using the same ATT and they can be hidden by different
> > logical interface.
> >
> >> So, why do we need to know anything more than this?
> >>
> >> Thanks,
> >>
> >> -Rajeev
> >>
> >
> > PS: I can not find the scenario 2,3 that you mentioned. Are they the
> > scenarios in your previous email?
> >
> > Regards,
> > TrungTM
> >
> >
> >>
> >> On 8/3/10 11:38 PM, "Tran Minh Trung" <[e-mail]> wrote:
> >>
> >>> Dear Rajeev,
> >>>
> >>> Should we assume that the LMA is aware of the logical interface at
> the MN?.
> >>> If not, how LMA can differentiate which physical interfaces are
> hidden
> >>> by the same logical interface?
> >>> If LMA can not recognize which physical interfaces are hidden by
> the
> >>> same logical interface then it is impossible to assign prefix(es)
> >>> exactly to different attachments.
> >>>
> >>> In case we assume that the LMA is aware of the logical interface at
> >>> the MN, then it is easy to enable LMA to assign the same prefix(es)
> to
> >>> all attachments of the logical interface.
> >>>
> >>> Thank you very much for making it more clear.
> >>> Regards,
> >>> TrungTM
> >>>
> >>>
> >>> On Wed, Aug 4, 2010 at 2:37 AM, Rajeev Koodli <[e-mail]>
> wrote:
> >>>>
> >>>> Hello Carlos, All,
> >>>>
> >>>> We had some good discussion on the prefix model for the flow
> mobility work.
> >>>> I have tried to capture the scenarios in the following text. Let¹s
> work
> >>>> towards incorporating this into the draft.
> >>>>
> >>>>
> >>>> X. Prefix Model
> >>>>
> >>>> Flow mobility assumes simultaneous access to more than one network,
> in
> >>>> a contrast to a typical handover where connectivity to a physical
> >>>> medium is relinquished, and is re-established with another.
> >>>> There are multiple prefix models under which a flow mobility
> protocol needs
> >>>> to work:
> >>>>
> >>>> 1. At the time of a new attachment, the MN obtains a new prefix or
> a
> >>>> new set of prefixes. This is the default behavior with RFC 5213.
> >>>>
> >>>> 2. At the time of a new attachment, the MN obtains the same prefix
> or
> >>>> the same set of prefixes as already assigned to an existing
> >>>> session.  This is not the default behavior in RFC 5213, and the
> LMA
> >>>> needs to be able to provide the same assignment even for the
> >>>> simultaneous attachment (as opposed to the handover scenario only).
> >>>>
> >>>> 3. At the time of a new attachment, the MN obtains a combination
> of
> >>>> prefix(es) in use and new prefix(es). This is a hybrid of the
> above
> >>>> two scenarios. The local policy determines whether the new prefix
> is
> >>>> exclusive to the new attachment or it can be assigned to an
> existing
> >>>> attachment as well.
> >>>>
> >>>> Among the above, scenario 2 needs extensions to RFC 5213 signaling
> at
> >>>> the time of a new attachment. Subsequently, no further signaling
> may
> >>>> be necessary between the LMA and the MAG. The scenario 1 requires
> >>>> flow mobility signaling whenever the LMA determines the need for
> >>>> relocating flows between the different attachments. The scenario 3
> >>>> requires flow mobility signaling whenever the LMA
> >>>> determines the need for relocating flows for the new prefix(es)
> which are
> >>>> not shared across attachments.
> >>>> In all the scenarios, a prefix has to  be valid on the
> >>>> concerned MAGs in order for flow mobility to work. Furthermore,
> each
> >>>> MAG MUST advertise to the MN the all the prefixes received from
> the LMA.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> netext mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> netext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netext
> >>
> >
> >
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext