Hello Li,
Am 27.07.2012 05:00, schrieb [email protected]:
In our drat, ETRs are still the authoritative source for mapping
information.
In draft-ietf-lisp-23, according to "Map-Register Message Format" on
page 41,
there is a p bit which is called proxy-map-reply bit. When an ETR sends a
Map-Register Message requesting for the Map-Server to proxy Map-Reply,
it will
set the p bit to 1.
In our draft, SHDHT Nodes could be considered as Map-Servers which
implement the "Proxy Map Reply" mode.
If this is so then Map-Register messages with P-bit set are mandatory
for SHDHT to work properly in the current status of the draft, right?
> Am 16.07.2012 11:43, schrieb [email protected]:
> > Michael Hoefling <[email protected]> 写于
2012-07-12
> > 22:32:36:
> > > 4. In Section 4.1 you state that a Node Routing Table lookup using a
> > > Resource ID returns the closest matching Partition ID. How
do you
> > > define "closest Partition ID"? What happens if the Node Routing
> > > Table has no match for the requested Resource ID? This case
is not
> > > covered in the document yet.
> >
> >
> > About "the closest Partition ID", please see the following
> > example(in section 3.1 of the -01 version).
> >
> > For example, for a data object whose Resource ID is 0x8213, the
> > Resource ID locates between Partition ID 0x7000 and Partition ID
> > 0x9000. As Partition ID 0x9000 is closer to Resource ID
0x8213, the
> > data object will be stored and maintained on Node2 who is assigned
> > with the hash space segment indexed by Partition ID 0x9000.
> >
> > Consider about three Partition IDs 0x5000, 0x7000 and 0x9000. Based
on the
> > "closest" rule, hash space segments indexed by the Partition ID
0x7000 may
> > be considered as [0x6000, 0x8000).
>
> Ok. From the text in the draft I still do not get it, but with the
> explanation in your reply, I think I might have understood it. Please
> verify whether my following own explanation is correct.
>
> If I get this right then every SHDHT node holds the same Node Routing
> Table? That is, every SHDHT node knows all Partition IDs assigned to all
> SHDHT nodes?
>
> With this assumptions I would interpret the "closest" rule as follows:
> If we have three consecutive Partition IDs a, b, and c which are the
> only Partition IDs in SHDHT for our example, then the range of each hash
> space segment is defined as follows:
> Partition ID a: [id(a)-d(c,a); id(a)+d(a,b))
> Partition ID b: [id(b)-d(a,b); id(b)+d(b,c))
> Partition ID c: [id(c)-d(b,c); id(c)+d(c,a))
> with functions
> id(x): value of Partition ID x in hash space
> d(x,y): distance between Partition ID x and y in hash space
>
> Did I get this right?
Almost correct.
The space segment is defined as:
Partition ID a: [id(a)-0.5*d(c,a); id(a)+0.5*d(a,b))
Partition ID b: [id(b)-0.5*d(a,b); id(b)+0.5*d(b,c))
Partition ID c: [id(c)-0.5*d(b,c); id(c)+0.5*d(c,a))
with functions
id(x): value of Partition ID x in hash space
d(x,y): distance between Partition ID x and y in hash space
Yes, my description in draft was not clear enough. I will modify it
in the next version.
OK, I forgot the 0.5 while writing the mail. It would be good to include
this in the draft.
What happens in SHDHT if only a partition of the entire EID space is
managed using SHDHT, i.e., there exist larger gaps between Partition
IDs? I guess this was my initial intention to ask how the size of hash
space segments are determined in SHDHT.
Regards,
Michael
--
Dipl.-Inform. Michael Hoefling, M.Sc.
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70507, fax: (+49)-7071/29-5220
mailto: [email protected]
http://kn.inf.uni-tuebingen.de/staff/hoefling
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
