Re: [netext] Scope of Prefixes in Flow Mobility

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

Hi Sri,

On Thu, 2010-08-05 at 09:06 -0700, Sri Gundavelli wrote:
> Hi Carlos:
> 
> In the absence of triggers from MN, on flow path preferences, it makes a
> world of difference in solution simplicity terms, between the two. We should
> support both. 

Of course we should support both. My point is that we can have a
solution that naturally support both, without really needing to make a
distinction per-scenario.

Carlos

> 
> (Question: for scenario 4:)
> 
> Its a good question. The mobile node may bridge all interfaces and may end
> up configuring them on the virtual interface, or not. But, from the network
> perspective, preserving multihoming properties can handle both the cases
> properly.
> 
> Sri
>  
> 
> 
> On 8/5/10 8:47 AM, "Carlos Jesús Bernardos Cano" <[e-mail]> wrote:
> 
> > Hi Sri,
> > 
> > I've always seen Scenario 3 as a sub-case of scenario 4 (the granularity
> > is per-prefix, not per 5-tuple flow). Question: for scenario 4: do we
> > really need the MAGs to advertise all the prefixes to the MN? I think it
> > is not really required if the MN uses the logical interface concept. The
> > only requirement is that the MAG knows how to route the prefixes (e.g.,
> > know that P2 is reachable through the same p2p interface where P1 is
> > reachable, without really advertising P2 on that interface).
> > 
> > Kind Regards,
> > 
> > Carlos
> > 
> > On Thu, 2010-08-05 at 08:35 -0700, Sri Gundavelli wrote:
> >>> 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.
> >> 
> >> (Couple of slides attached)
> >> 
> >> The above approach will always will result in a single prefix allocation
> >> across interfaces, which is not desirable. If the feature is active, we
> >> start with one prefix on a interface and start sharing on the other
> >> interface. Couple of points:
> >> 
> >> 1.) For each new interface attachment, always allocate a new prefix, or set
> >> of prefixes, just as in 5213.
> >> 2.) However, if the flow policy requires an existing active flow on a
> >> different interface to be relocated to the new interface, the approach of
> >> prefix sharing across interfaces can be considered.
> >> 
> >> As I said yesterday (please see the attached slides), we have 4 scenarios.
> >> Scenario-1 and Scenario-2 are covered in 5213. Now, we have scenario-3,
> >> moving all the flows associated with a prefix (i.e. Using the source address
> >> from the same prefix) i.e. Mohana's draft, to a new interface. This is
> >> almost like Sceanario-1, we have proper indicators.
> >> 
> >> The other scenario, which I never liked is scenario-4, requiring shared
> >> prefixes across interfaces. But, scenario-4 and scenario-2 should not be
> >> seen as mutually exclusive. In other words, its not always multihoming vs
> >> prefix sharing, but rather its always multihoming, but some flows that had
> >> to moved to different interface (determined by policy), even if they are
> >> using a prefix from the prev interface, we need to share so those flows can
> >> be relocated. Assuming new flows will pick up the right source
> >> address/interface selection and eventually keeping the prefixes to the
> >> respective interfaces.
> >> 
> >> 
> >> Sri
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 8/5/10 2:09 AM, "MELIA, TELEMACO (TELEMACO)"
> >> <[e-mail]> 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).
> >>> 
> >>> 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