RFC
RFC 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
RFC 3539 Authentication, Authorization and Accounting (AAA) Transport Profile
rfc6733 Diameter Base Protocol
5.5. Transport Failure Detection
Given the nature of the Diameter protocol, it is recommended that
transport failures be detected as soon as possible. Detecting such
failures will minimize the occurrence of messages sent to unavailable
agents, resulting in unnecessary delays, and will provide better
failover performance. The Device-Watchdog-Request and Device-
Watchdog-Answer messages, defined in this section, are used to pro-
actively detect transport failures.
5.5.1. Device-Watchdog-Request
The Device-Watchdog-Request (DWR), indicated by the Command Code set
to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
traffic has been exchanged between two peers (see Section 5.5.3).
Upon detection of a transport failure, this message MUST NOT be sent
to an alternate peer.
Message Format
::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
* [ AVP ]
5.5.2. Device-Watchdog-Answer
The Device-Watchdog-Answer (DWA), indicated by the Command Code set
to 280 and the Command Flags' 'R' bit cleared, is sent as a response
to the Device-Watchdog-Request message.
Message Format
::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ AVP ]
RFC7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
p.14
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two
servers. A server SHOULD also use watchdog packets from the client
to determine that the session is still active.
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
that do not implement an application-layer watchdog MUST also
maintain a "Last Traffic" timestamp per DTLS session. The
granularity of this timestamp is not critical and could be limited to
one-second intervals. The timestamp SHOULD be updated on reception
of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than
once per interval. The timestamp MUST NOT be updated in other
situations.
When a session has not received a packet for a period of time, it is
labeled "idle". The server SHOULD delete idle DTLS sessions after an
"idle timeout". The server MAY cache the TLS session parameters, in
order to provide for fast session resumption.
This session "idle timeout" SHOULD be exposed to the administrator as
a configurable setting. It SHOULD NOT be set to less than 60 seconds
and SHOULD NOT be set to more than 600 seconds (10 minutes). The
minimum useful value for this timer is determined by the application-
layer watchdog mechanism defined in the following section.
p.15
5.2. Client Session Management
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU
between the client and server, prior to sending any RADIUS traffic.
Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two
systems. RADIUS/DTLS clients SHOULD also use the application-layer
watchdog algorithm defined in [RFC3539] to determine server
responsiveness. The Status-Server packet defined in [RFC5997] SHOULD
be used as the "watchdog packet" in any application-layer watchdog
algorithm.
RADIUS/DTLS clients SHOULD proactively close sessions when they have
been idle for a period of time. Clients SHOULD close a session when
the DTLS Heartbeat algorithm indicates that the session is no longer
active. Clients SHOULD close a session when no traffic other than
watchdog packets and (possibly) watchdog responses has been sent for
three watchdog timeouts. This behavior ensures that clients do not
waste resources on the server by causing it to track idle sessions.
A session MUST be deleted when non-RADIUS traffic is received over
it. This specification is for RADIUS, and there is no reason to
allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST
be deleted when RADIUS traffic fails to pass security checks. There
is no reason to permit insecure networks. A session SHOULD NOT be
deleted when a well-formed, but "unexpected", RADIUS packet is
received over it. Future specifications may extend RADIUS/DTLS, and
we do not want to forbid those specifications.
The goal of the above requirements is to ensure security, while
maintaining flexibility. Any security-related issue causes the
connection to be closed. After the security restrictions have been
applied, any unexpected traffic may be safely ignored, as it cannot
cause a security issue. There is no need to close the session for
unexpected but valid traffic, and the session can safely remain open.
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two
servers. A server SHOULD also use watchdog packets from the client
to determine that the session is still active.
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
that do not implement an application-layer watchdog MUST also
maintain a "Last Traffic" timestamp per DTLS session. The
granularity of this timestamp is not critical and could be limited to
one-second intervals. The timestamp SHOULD be updated on reception
of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than
once per interval. The timestamp MUST NOT be updated in other
situations.
When a session has not received a packet for a period of time, it is
labeled "idle". The server SHOULD delete idle DTLS sessions after an
"idle timeout". The server MAY cache the TLS session parameters, in
order to provide for fast session resumption.
This session "idle timeout" SHOULD be exposed to the administrator as
a configurable setting. It SHOULD NOT be set to less than 60 seconds
and SHOULD NOT be set to more than 600 seconds (10 minutes). The
minimum useful value for this timer is determined by the application-
layer watchdog mechanism defined in the following section.
[RFC] watchdog: Adding softwatchdog
[RFC,V2,21/21] Documentation/rv: Add watchdog-monitor documentation
[RFC v2 0/2] Add driver for PAPR watchdog timers
[RFC,19/23] watchdog/hardlockup: Make arch_touch_nmi_watchdog() to hpet-based implementation
RFC: API Change: watchdog: wdt_feed error codes #26708
PATCH RFC] Watchdog: Load module for only active watchdog in kdump kernel
Watchcat
Watchcat is not a standard now.
Watchcat is hardware only.
There are no software watchcat.
I am planning wtchcat standard as RFC(request for comment)
sample documentation
watchcat as monitor with pwer saving.
Abstract
internet inactivation has become a major concern over the past few years.
Users are becoming more aware that their online activity can be ussed or
not to used. The communication can be easily begun, but can not maintain
connection. One of usefull function are watchdog, and watch cat is more
power saving.
There have been several watchdog timers. This is watchcat, not watchdog.
This document provides an overview of this actity , with the intention
to inform the technical community about this, and help coordinate between
present and futures standardization activities.
Status of This Memo
Nothing.