Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 21 Aug 2008 09:23:48 -0700 (GMT-07:00)

okay with me.

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Aug 19, 2008 2:41 PM
>To: [email-masked], [email-masked], [email-masked]
>Cc: [email-masked]
>Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions
>
>Scott/Charles, are we good with this? Can I close this issue with the
>recommended text below?
>
>PatC 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, August 19, 2008 1:10 PM
>To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions
>
>Pat Calhoun wrote:
>
>> So just to be clear, your request is to replace the first paragraph 
>> only. The resulting section would read as follows:
>
>No, the 2nd paragraph, the three bullets, and the paragraph following
>the bullets also need work... but much of the text is really redundant
>with the new 1st paragraph, so this could be shortened (while fixing the
>incorrect parts at the same time) -- see below.
>
>> <updated section>
>> 2.4.3.  DTLS Error Handling
>> 
>>    If the AC or WTP does not respond to any DTLS handshake messages
>>    sent by its peer, the DTLS specification calls for the message to
>>    be retransmited.  Note that during the handshake, when both the
>>    AC and the WTP are expecting additional handshake messages, they
>>    both retransmit if an expected message has not been received
>>    (note that retransmissions for CAPWAP Control messages work
>>    differently: all CAPWAP Control messages are either requests or
>>    responses, and the peer who sent the request is responsible for
>>    retransmissions).
>> 
>>    If the WTP does not respond to any DTLS handshake messages sent
>>    by the AC, the CAPWAP protocol allows for three possibilities,
>>    listed below.  Note that DTLS MAY send a single TLS Alert message
>>    to the AC to indicate session termination.
>> 
>>    o  The message was lost in transit; in this case, the DTLS
>>       implementation on the WTP will retransmit its last outstanding
>>       handshake message, since it did not receive a reply.
>> 
>>    o  The WTP sent a DTLS Alert, which was lost in transit; in this
>>       case, the AC's WaitDTLS timer will expire, and the 
>>       session will be
>>       terminated.
>> 
>>    o  Communication with the WTP has completely failed; in this case,
>>       the AC's WaitDTLS timer will expire, and the session will be
>>       terminated.
>> 
>>    The DTLS specification provides for retransmission of 
>>    unacknowledged
>>    requests.  If retransmissions remain unacknowledged, the WaitDTLS
>>    timer will eventually expire, at which time the CAPWAP 
>>    component will
>>    terminate the session.
>
>Probably everything from the 2nd paragraph to here could be summarized
>something like this:
>
>   If the WTP or the AC does not receive an expected DTLS handshake
>   message despite of retransmissions, the WaitDTLS timer will
>   eventually expire, and the session will be terminated.  This can
>   happen if communication between the peers has completely failed, or
>   if one of the peers sent a DTLS Alert message which was lost in
>   transit (DTLS does not retransmit Alert messages).
>
>Best regards,
>Pasi
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap