Subject: [netext] Follow up on bulk-PBU-bitmap-ID

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Nov 2009 14:46:38 +0800

Hi all,

After the netext meeting the Chairs asked us to put some scenarios in
the ML where the bitmap-bulk-PBU method can be used and to get general
consensus from the group regarding applicability.  I am highlighting the
scenarios we presented in the Netext meeting in this mail.

As presented in the meeting and also described in the
draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used
to optimize bulk PBU in some scenarios.

Please look at the scenarios below and give your feedback regarding
scenario validity and the need for such method to address optimization
in these scenarios.  Ofcourse we are proposing this as an optional
feature.  A deployment may or may not use it.

The scenarios are:
Scenario 1: 
Multiple new attachment requests arriving at MAG simultaneously and MAG
performing multiple initial registration PBUs

Scenario 2:
Multiple MN re-registrations at a new LMA due to shut down of the
previous serving LMA in a LMA failure scenario

Scenario 3: 
Multiple handoff requests arriving at MAG simultaneously and MAG
performing multiple handoff registration PBUs.

Scenario 4: 
Multiple detachment events detected at MAG simultaneously and MAG
performing multiple de-registration PBUs.

Scenario 5: 
Multiple initial registrations, handoff registrations and
re-registration events happening simultaneously at MAG and MAG
performing multiple PBUs tied to different type of events.

Scenario 6: 
MNs moving in  group into MAG service area.  As a result, MAG performing
multiple handoff or multiple new attachment PBUs for MNs tied to group
mobility.

Scenario 7: 
MAG offloading some MNs binding lists to another MAG for load balancing
purpose.  New MAG sends multiple PBU registrations for all the MNs that
were transferred.

Thanks.

BR,
Mohana

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Nov 2009 17:34:35 +0800

Hi, Mohana:
Take a look at the scenarios you summarized, I would like to make some comments,
please see inline.

Regards!
-Qin
----- Original Message ----- 
From: "Mohana Jeyatharan" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 20, 2009 2:46 PM
Subject: [netext] Follow up on bulk-PBU-bitmap-ID

> feature.  A deployment may or may not use it.

[Qin]: I agree bitmap based Bulk PBU is optional  feature and quite useful when 
a set of mobile node tied to one MAG has not formed one or several group.

> performing multiple initial registration PBUs

[Qin]: In this scenario, You should require multiple new PBUs to be sent to the same LMA, right?

> previous serving LMA in a LMA failure scenario

[Qin]: This scenario seems overlapped with bulk re-registration draft. In this scenario,
 the problem is how does MAG know the previous serving LMA is shut down.
whether MN group has already formed on the MAG.

> performing multiple handoff registration PBUs.

[Qin]: I am wondering what's the difference between scenario 2 and scenario 3? 
In my understanding, when MN handover from previous MAG to the new MAG,
MAG should also perform re-registration to the same LMA, what am I missing?
I also found the handoff case is not covered by bulk re-registration draft. What's the reason?

> performing multiple de-registration PBUs.

[Qin]: This scenario is only useful when goups for a set of MN has not formed before de-registration happens.
If MN's group ID has already been created, MAG can perform bulk de-registration PBU using MN's group ID.

> performing multiple PBUs tied to different type of events.

[Qin]: It seems to me scenario5 is one combined case using scenario 1,2,3.
I am wondering how does MAG handle PBUs for initial registration, handoff registration, re-registration in one message.
Also I am difficult to understand that how LMA will process this  message for different purposes at the same time.
Therefore It is a good idea to consider this scenario.

> multiple handoff or multiple new attachment PBUs for MNs tied to group

[Qin]: It seems to me this sccenario seems like NEMO scenario. I think this scenario is quite useful scenario. Suppose a set of MNs moving as one in one vechicle, 
How the MAG in the vechicle perform multiple new attachment PBUs when the vechicle is moving. Bitmap based bulk PBU is quite fit into this scenario.

> purpose.  New MAG sends multiple PBU registrations for all the MNs that

[Qin]: In my understanding, load balancing between LMAs is required. Because LMA is easier to be overloaded than MAGs. But I am not sure
there is some requirement for load balancing between MAGs. Can you tell where this requirement come from?

> Thanks.
> 
> BR,
> Mohana
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Nov 2009 18:24:11 +0800

Hi Qin,

Thank you for your comments on the scenarios we proposed.

Please see some replies below.

BR,
Mohana

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 5:35 PM
> To: Mohana Jeyatharan; [email-masked]
> Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID
> 
> Hi, Mohana:
> [Qin]: I agree bitmap based Bulk PBU is optional  feature and quite
useful
> when

[Mohana] Thanks for this comment.  Bcos, in some heavily populated urban
areas the MAGs may get multiple attach/ handoff attach requests
triggered within a very short time span and the bitmap approach can be
used before grouping.  Anyway there are more scenarios below which can
be used in our discussion.

> [Qin]: In this scenario, You should require multiple new PBUs to be
sent
> to the same LMA, right?
[Mohana]well this scenario is like multiple new attachment requests
arriving within a very minute time frame.  So, instead of sending
multiple PBUs probably a single PBU can be sent without any significant
impact on the new attachemnt establishment time for any given MN.
> [Qin]: This scenario seems overlapped with bulk re-registration draft.
In
> this scenario,

[Mohana] From my reading of the bulk reregistration draft, this scenario
was not mentioned.  I think the older version had this. The MAG fist
needs to make the regsitration at the new LMA.  After such regsitration,
the new LMA will assign the group ID.  But the initial registrations at
the new LMA can be optimized using the bitmap approach.  MAG has binding
list tied to many MNs. So it can use bitmap to tranfer to new LMA. The
failure can be identified by refresh PBU failure.

> MAG should also perform re-registration to the same LMA, what am I
[Mohana] Well in RFC 5213, re-registration is defined more like
refreshing the PBU from the same MAG.  Handoff is a change in MAG.  So,
in that sense, they are different.  I think you are considering handoff
also has re-regsitartion.  Well w.r.t. LMA handoff is also like
re-registration.

> I also found the handoff case is not covered by bulk re-registration
draft.
> What's the reason?

[Mohana]  handoff case is not covered bcos the focus is using group ID
to perform re-reg and revocation.
> registration PBU using MN's group ID.

[Mohana] I understand your comment here.  But, the scenario we mention
here is that what if some nodes belonging to groups decide to detach.
Not all nodes and hence grouping cannot be used.  So this is more like
random events.

> I am wondering how does MAG handle PBUs for initial registration,
handoff
> registration, re-registration in one message.
> Also I am difficult to understand that how LMA will process this
message
> for different purposes at the same time.

[Mohana] Ok, so you are saying that this scenario is a bit more
complicated. Agree it is athe combination of the scenarios you
mentioned. Well re-regi, new reg and handoff reg are all handled by
means of HI mobility option.  So combining is not a problem  However,
the LMA needs to understand that this is bulk PBU handling multiple
event tied to multiple Mns and need to update the binding entries
accordingly.  Perhaps we need to think whether it creates more
complexity in LMA behaviour.  However, just wanted to highlight usage of
the bitmap approach in these scenarios. Agree need to consider whether
combining makes LMA processing very complicated.

> [Qin]: It seems to me this sccenario seems like NEMO scenario. I think
> this scenario is quite useful scenario. Suppose a set of MNs moving as
one
> in one vechicle,
> How the MAG in the vechicle perform multiple new attachment PBUs when
the
> vechicle is moving. Bitmap based bulk PBU is quite fit into this
scenario.

[Mohana] exactly.  Thanks for mentioning about the NEMO case. So, this
is something like a MR or a central contoller performing bulk
registration at the MAG instead of each individual MNs.  So, in such
scenario the bulk method is useful.  Here you don't get individual
regsitartions but a cntral entity gives combined registrations to the
MAG.

> [Qin]: In my understanding, load balancing between LMAs is required.
> Because LMA is easier to be overloaded than MAGs. But I am not sure
> there is some requirement for load balancing between MAGs. Can you
tell
> where this requirement come from?

[Mohana]  I cannot pin point a specifc document. But in any GW
deployments there is usually multiple entities handling registrations
for load balancing.  In 3GPP there is multiple S-GWs, multiple MMEs,
multipe P-GWs and so on.  So, this scenario is practical because suppose
many nodes attach to one MAG and another MAG does not have many Mn
registrations bos Mn regsitartions are removed due to mobility, then the
overloaded MAG can transfer some load to another MAG(not so overloaded
MAG).

---

From: Conny Larsson <[email-masked]>
Date: Fri, 20 Nov 2009 12:04:56 +0100

Hi Mohana,

In the below scenarios (4 out of 7) you are using the word 
"simultaneously". How would you define simultaneously? Depending on the 
time interval you define there will be a delay introduced. Is this a 
correct interpretation of the scenarios or did you have anything else in 
mind?

Regards
Conny

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 23 Nov 2009 08:35:57 +0800

Hi Conny,

Thanks for your response.

Well simultaneously means many new call registrations or handoff
registrations being triggered at a MAG within a very short time frame. I
agree with you that there will be some delay.  Since the assumption is
that many arrive within a short time frame, MAG grouping these in a
single PBU does not really cause so much delay.

Bcos in some handoff cases, one may not have any on-going session.  Also
during initial attach there can be a some delay that can be accepted to
applications bcos a Mn may not send or receive data immediately after
attach.
Thus such minute delay in grouping the initial attach registrations or
handoff registrations does not cause any harm as far the MN performance
is concerned.

So, was thinking of such cases, where a minute delay can be tolerable
and also beneficial to the operator.  However, if the SLA(service level
agreement) is such that this delay cannot be tolerated, then the
operator MUST not do such bulk registration.

Considering the traffic will increase many folds in future, such
optimization may be needed.  It gives the flexibility to the operators.

Also please look at scenario 6 where we highlight group mobility or
group registration.  In such case, it is very probable that simultaneous
registrations of multiple MNs are given to the network by a single
entity(central controller of group or MR).  In such case, there will not
be any delay in the registrations at the MAG.

Thanks.

BR,
Mohana

> From: Conny Larsson [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 7:05 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]