Hi Marcelo, I am sorry for my late response. Thanky you very much! See my comments inline... :-) marcelo bagnulo braun schrieb:
Hi Deguang, El 15/10/2006, a las 15:24, Deguang Le escribió:Hi all, a slight comment on the Context Tag... -Page50 o The context tag used to transmit control messages and payload extension headers - allocated by the peer; CT(peer) -Page51 o The context to expect in received control messages and payload extension headers - allocated by the local host; CT(local)In page 50 and 51, two parameters, namely CT(peer) and CT(local), are defined for each ULID-pair context. right?However, in page 13, the terminology of CT is given as follows: Context tag Each end of the context allocates a context tag for the context. This is used to uniquely associate both received control packets and payload extension headers as belonging to the context.Based on my understanding of above CT terminology, for a given context, there is only "A" unique context tag used to identify the context (i.e. the ULID-pair context, right?).no, the above terminology states that _each_ end of the context allocates one context tag. since there are two ends in a shim context, this sums two context tags, right? CT(peer) and CT(local)
You are right. Thank you very much! I think I understand what the two CTs means and their usages now. You mean each established shim6 context is identified by two CTs (i.e. a peer CT and a local CT) in fact, and the values of these two CTs are different. Right? :-) However, I wonder why two endpoints can not negotiate "a" CT to establish and identify a shim6 context. Is it not feasible to establish a shim6 context if only "one" CT is used for identifying a context? Cheers, Deguang
Regards, marceloTherfore, I am confused why each ULID-pair context needs these "TWO" context tags: CT(peer) and CT(local)? Are the CT(peer) and the CT(local) the same thing (or are they the same 47-bit number?)in essence?Have a nice weekend! Cheers, Deguang