[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: teardown of the ULID-pair context


El 12/12/2006, a las 14:47, Matthijs Mekking escribió:


Hi,

I have a question about the teardown of the ULID-pair context. In
chapter 9, the proto6 draft says "A reasonable approach would be not to
tear down a context until at least 5 minutes have passed since the last
message was sent or received using the context." Does this include
messages that do not contain a shim6 extension header? My opinion is yes: 



yes, of course
please note that the REAP protcool for instance actually processes the payload packets in some form, since it activates timers based on recieved and sent payload packets, so, in any case the payload packets 


If there is a context on host A for host B, this means that both are
multihomed. They should enjoy the goals of multihoming, such as
failover. However, the communication between A and B initially uses the
ULID address pair. Therefore, the IPv6 address fields do not need to be
replaced by a different locator pair, and the message is not tagged with 
a shim6 extension header. In other words, the context is not being used
at the moment. This means that if after 5 minutes there was no context
switch, the context states may be teared down again. If shortly after
this the link corresponding to the ULID pair fails, the hosts are not
able to do failover anymore.
So, shim unaware payloads (traffic not using the context) should also be 
observed. I suggest that the text 'using the context' in chapter 9 will
be removed.
as i mention above, the payload packets (not carrying the payload shim6 header) are using the context and have an impact on the context state (e.g. w.r.t. timers)
in any case, i can rephrase it more clearly, and explicitly mention that this does include data packets without the payload header 



In order to observer shim unaware payloads, the shim6 layer should look
up a context for these kind of messages. Chapter 11 already defines how
this should be done for sending ULP payloads. For receiving packets
(chapter 12), this information is missing. I suggest there should be a
section before 12.1 receiving payload extension headers:

12.x Receiving payload without extension headers

The receiver extracts the IPv6 source and destination fields, and uses
this to find a ULID-pair context, such that the IPv6 address fields
match the ULID(local) and ULID(peer). If such a context is found, the
context appears not to be quiescent and this should be remembered. The
host continues with proceeding the message.
yes, this makes sense.... actually it should be noted more clearly in the spec that data packets without shim6 payload header do actually need processing in the shim6 ctxt state... this is particularly critical for the reap protocol, which sets and stops timers upon the recpetion and sending these packets... i will try to add something in these lines... 

thanks again, regards, marcelo






With regards,

Matthijs Mekking
matthijs@NLnetLabs.nl
NLnetLabs/Radboud University