Subject: [netlmm] Issue: BUList vs Visitor Table

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 13 Aug 2007 00:27:23 -0700

Hopefully, this is the last issue. Very minor. Quick and short
discussions are appreciated.

There were some discussions on the conceptual data structure that
is defined for the MAG. We had some discussions with the options,
to keep the BUList or define a new data structure, Visitor Table
such as in MIP4. We had different views on this and would like to
close this properly.

We currently, recommended the use BU List on the MAG.
As per Section 11.1, 3775:

> 11.1.  Conceptual Data Structures
>
>   Each mobile node MUST maintain a Binding Update List.
>
>   The Binding Update List records information for each Binding Update
>   sent by this mobile node, in which the lifetime of the binding has
>   not yet expired.  The Binding Update List includes all bindings sent
>   by the mobile node either to its home agent or correspondent nodes.

BU List is for a specific MN. On the MAG, we have a list of MN's,
effectively, list of BULists. The MAG is required to maintain the
BUList on a MN basis. But, again we just have one binding that we
need to maintain for each MN for PMIP6.

Options:

1. Define a new Conceptual Data Structure, Visitor Table.

VisitorTable {
  VisitorEntry[]  /* MN Vistitor List */
}
 
VisitorEntry {
  NAI
  MAC
  ....
  BUList;            
}

2. Keep the BU List and maintain BUEntry on a MN basis.
We just need to maintain one binding state for each MN.
Slightly modifies the definition of BUList as defined
in 3775.

BUList {
  BUEntry[]       /* BU Entry, one for each MN */
}

BUEntry {
  NAI 
  ...  
}

Quick Comments:

Thanks
Sri

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "John.zhao" <[email-masked]>
Date: Mon, 13 Aug 2007 16:40:49 +0800

Hi,Sri

	No some prefer on it. But I confuse that why we can't leave such a
thing like this to implement? 

	My two cents.

	Best Rgds,
Thanks

John.zhao

> -----邮件原件-----
> 发件人: Sri Gundavelli [mailto:[email-masked]]
> 发送时间: 2007年8月13日 15:27
> 收件人: [email-masked]
> 主题: [netlmm] Issue: BUList vs Visitor Table
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Aug 2007 14:17:25 -0700

Sri,

One correction. According to RFC 3775 each entry in the binding update 
list corresponds to one active binding cache entry that the mobile node 
maintains at a home agent or a correspondent node. In Proxy Mobile IPv6 
context, each entry in the binding update list on the MAG would 
correspond to one proxy binding cache entry that the MAG maintains at an 
LMA on behalf of a mobile node.

We *do not* have a list of binding update lists on the MAG. Rather it is 
one binding update list with one entry per proxy binding cache entry 
created by the MAG at an LMA.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 15 Aug 2007 22:22:05 -0700

Hi Vijay,

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, August 13, 2007 2:17 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] Issue: BUList vs Visitor Table
> 
> Sri,
> 

As per Section 11.1 [3775]:

   "The Binding Update List includes all bindings sent
   by the mobile node either to its home agent or correspondent nodes."

In a BU List, each entry corresponds to one binding, as you say. But,
all the entries are for a given mobile node. In PMIP6, we just have
one entry, today. We don't have RO support and hence there is just
one entry. 

Now, should we modify the definition of a BU List to handle multiple
mobile node (NAI's/HNP's) binding states, by making each entry unique
to a mobile node. Or, just define a new data structure such as a
Visitor List. In that each visitor entry can hold a BUList. 

The later approach will allow future extensibility, IMO. The former
approach still requires a definition change from 3775.

> created by the MAG at an LMA.

True. If we make each entry unique to a mobile node and if we assume,
we will never have to maintain multiple binding states (binding to a CN
...etc) for a given mobile node, yes, we can hold them in one BUList.
With that assumption, I agree, we can keep the BUList. 

I feel, it might be better to define a visitor list as supposed to
modifying the BU List definition and also for supporting multiple
binding states for each MN, later.

Others ? Suggestions welcome !!

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Aug 2007 22:31:26 -0700

> approach still requires a definition change from 3775.

No, it does not. Each entry in the binding update list on the MAG still 
corresponds to one binding that the MAG maintains. In RFC 3775 each 
entry corresponds to one binding that the MN maintains. In PMIPv6, there 
is just one binding update list on a MAG. in RFC 3775 there is just one 
binding update list on a MN. So I don't see an issue.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 16 Aug 2007 03:38:29 -0700

> binding update list on a MN. So I don't see an issue.

Ok. Lets try to get some feedback from the WG on their interpretation,
and close the issue, one way or the other.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Aug 2007 17:19:44 +0200

Hi Sri, 

FWIW I'm agnostic to this issue -- sorry that it doesn't help resolving 
it.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 22 Aug 2007 08:36:01 -0700 (PDT)

Hi Julien,

Ok. No problems.

Thanks
Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 22 Aug 2007 08:45:34 -0700

Hi Sri and Vijay,

> binding update list on a MN. So I don't see an issue.

I tend to agree with Sri. 

As it is defined in RFC 3775 one BUL has multiple entries for a single
MN. 
Having entries for different MNs in the MAG BUL would basically change
the definition of RFC 3775. 

Moreover, there are also other difference between the BUL and what is
needed at the MAG: for example the list at the MAG should contain also
the identifiers of the MNs.

Finally the operations of the MAG related to the BUL are different than
the operations of a MN. 

I think the Visitors List would be more appropriate for PMIPv6.

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Aug 2007 09:16:20 -0700

> the definition of RFC 3775. 

If you take a look at RFC 3775 again, it says each binding update list 
entry corresponds to one binding cache maintained at a home agent or a CN.

    Binding Update List

       This list is maintained by each mobile node.  The list has an item
       for every binding that the mobile node has or is trying to
       establish with a specific other node.  Both correspondent and home
       registrations are included in this list.  Entries from the list
       are deleted as the lifetime of the binding expires.  See Section
       11.1.

Late in Section 11.1

So the use of binding update list for PMIPv6, where each entry in the 
binding update list on the MAG would correspond to one proxy binding 
cache entry created by the MAG, would be consistent with RFC 3775.

> the identifiers of the MNs.

No. Even in RFC 3775, if a mobile node uses different identities with 
its home agent and CN or has more than one home agent, the binding 
update list entries would have the identity of the mobile node stored. 
In RFC 3775, the home address can also be the identity of the mobile 
node. In this case, if a mobile node has more than one home address, 
they will all appear in the binding update list.

> Finally the operations of the MAG related to the BUL are different than

??? Can you elaborate?

> I think the Visitors List would be more appropriate for PMIPv6.

I would prefer re-using the binding update list data structure from 
Mobile IPv6, instead of defining a new data structure.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 27 Aug 2007 02:55:57 -0700

> update list entries would have the identity of the mobile node stored.

The identity is not stored in the BUL based on RFC 3775. The only
"identity" used is the HoA based on section 11.1 of RFC 3775. 

My point is that PMIPv6 will anyway require additional parameters in the
BUL compared to MIPv6 (and the identity is one example). 

> > Finally the operations of the MAG related to the BUL are different
than

Sorry for not being explicit here. 

I was referring to the handover/dereg case: the trigger for sending a
deregistration PBU for the MAG are different from the trigger for a MN.
Basically, even though the data structure is similar, the operations of
the MAG are different.

> Mobile IPv6, instead of defining a new data structure.

I have not a strong opinion on this, just a preference in terms of
clarity of the spec.

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 03:48:54 -0700

>> cache entry created by the MAG, would be consistent with RFC 3775.

So you agree that the use of the binding update list in PMIPv6 is not in 
conflict with RFC 3775?

> BUL compared to MIPv6 (and the identity is one example). 

Yes, we have listed those in section 6.6 of 
draft-ietf-netlmm-proxymip6-01.txt

> Basically, even though the data structure is similar, the operations of

I don't see an issue here though. Yes, the functionality of the MAG is 
different from the MN. But that does not mean we need new data 
structures, we re-use what can be re-used from MIPv6.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 27 Aug 2007 06:28:14 -0700

> >> entry corresponds to one binding cache maintained at a home agent
or a
> > CN.
> >>     Binding Update List
> >>
> >>        This list is maintained by each mobile node.  The list has
an
> > item
> >>        establish with a specific other node.  Both correspondent
and
> > home

It may not be in conflict. It's just that other fields and information
are needed. Therefore it is not the BUL specified in RFC 3775 you are
proposing to re-use. But there may some value to re-use as much as
possible provided that clarify of spec.

> draft-ietf-netlmm-proxymip6-01.txt

Good. I plan to go through the draft again soon.

> structures, we re-use what can be re-used from MIPv6.

As mentioned above, you may re-use part of the BUL and add the necessary
new information. But the specification must be very clear in what is
different and how the functionality of the MAG is different from the MN
with respect to the BUL.

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 06:43:14 -0700

> possible provided that clarify of spec.

Ok. We do recognize in the PMIPv6 spec what additional information must 
be stored in each binding update list entry.

> different and how the functionality of the MAG is different from the MN

Of course. Goes without saying.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 06:33:37 -0700

> Sent: Monday, August 27, 2007 6:43 AM
> To: Giaretta, Gerardo
> Cc: Sri Gundavelli; [email-masked]
> >> So you agree that the use of the binding update list in 
> PMIPv6 is not
> > in
> >> conflict with RFC 3775?
> >>
> > 

So, if we are not re-using BUList in the basic form, it might be better
to use Visitor Table with Visitor entries. Each visitor entry can adopt
the BUList. Else, if we support RO in the extension docs, not sure how
multiple bindings will be stored for each MN ? This can be made to work,
since there is just one binding. But, multiple binding suport for each
MN is given. So, why not just adopt the right datastructure with RO in
mind. It will be cleaner, IMO, to go with the visitor table.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Aug 2007 06:43:01 -0700

Sri Gundavelli wrote:
> to use Visitor Table with Visitor entries. 

We already recognize the additional information that needs to be store 
on the MAG's binding update list entry for PMIPv6. We have already 
documented that in the PMIPv6 base spec.

 > Each visitor entry can adopt
> the BUList. 

I don't think we should create a list of lists.

> Else, if we support RO in the extension docs, not sure how

Sri, you are not listening. Each entry in the binding update list 
corresponds to the a binding maintained at another node. The number of 
mobile nodes or the number of binding cache entries per mobile does not 
change the definition of the binding update list. Even if we have PMIPv6 
route optimization, we won't contradict the binding update list 
definition in RFC 3775. For each CN, you do PMIPv6 RO, there would one 
additional binding update list entry on the MAG. Thats all.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 06:56:51 -0700

> Sent: Tuesday, August 28, 2007 6:43 AM
> To: Sri Gundavelli
> Cc: 'Giaretta, Gerardo'; [email-masked]

If each entry is not unique to a MN, but unique for a binding,
there could be multiple entries for a given MN (with RO support).
For deleting a MN state, implementations have to search the BUList
with NAI key and delete all those entries. If the list is kept
unique on a MN basis, its one search and that entire entry can
be deleted. Otherwise, there needs to be a tie between all the
bindings that are created for a given MN and spread out in the 
BuList.

Again, I'm not proposing a new conceptual data structrure
just for the sake of it. The BUList as currently defined, may not
fit when the state needs to be stored for multiple MN's and each
MN with multiple bindings.

Sri