Re: [netext] Scope of Prefixes in Flow Mobility

[Carlos Jesús Bernardos Cano <[e-mail]>]

On Thu, 2010-08-05 at 11:09 +0200, MELIA, TELEMACO (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.

Fully agree on this.

Carlos

> 
> 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).
> 
> telemaco 
> ________________________________________
> 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

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