Re: [netext] Scope of Prefixes in Flow Mobility

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

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