Re: [netext] Scope of Prefixes in Flow Mobility

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

Hi Telemaco,

Please see below -

TELEMACO (TELEMACO) wrote:
> 
> Hi Julien,
> 
> Please see below.
> Telemaco
> 
> 
> 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"... 
> 
> TELE: In EV-DO, the MAG (PDSN/HSGW) already receives the 5-tuples and
> does filtering and throttling based on policy. We should therefore let
> the MAG communicate to the LMA if specific flows cannot be accommodated.

EV-DO is an air interface. How does that relate to the protocol a MAG speaks with an LMA?
 
> (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.)
> 
> TELE: this is right, but I would not be in favor of a solution that
> initializes all the prefixes at attachment time. This is why the cases
> that Rajeev explored in his previous post make sense to me. Considering
> that FMI/FMA signaling is required with the above statement I do not
> see any problem is allowing the MAG to know run time additional
> prefixes to be routed.

As I've said earlier, whether or not there is a possibility to add additional prefixes later is orthogonal to 1) whether or not prefixes are bound to (set of) interfaces as opposed to MN-wide, and 2) whether there's a need to send a traffic selector to achieve flow mobility. 

Adding additional prefixes later is something that I am willing to consider, though I'd like to understand better the motivation.

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