ASF Specification v2.0 DSP0136 - DMTF

Alert Standard Format (ASF) Specification v2.0
DMTF Document DSP0136
Contents Type Offset Value
Message Tag 1 byte 05h This 1-byte field is used to match request-response pairs. This
value is copied into the response message when one is generated
in a request-response interaction, e.g. the Presence
Ping/Presence Pong pair. When a duplicate message is received,
i.e. one with the same Message Tag, the consumer of the
message determines whether the message is accepted or
rejected. For example, an alert-sending device might be designed
to respond to all Presence Ping messages received, or to keep
track of recent Presence Ping messages and only respond to
those with unique Message Tag values. See below for more
information.
Note: A value of 255 (FFh) indicates that the associated message
is not a request-response type message.
Reserved 1 byte 06h Reserved for future definition by this specification, set to 0.
Data Length 1 byte 07h This 1-byte field contains the byte length of the message’s
variable-length Data field.
Data
N
bytes
08h
Data associated with a particular Message Type, number of bytes
is specified by Data Length.
Using the Message Tag Field
Many of the RMCP messages are of the request/response type:
• A Presence Ping sent from a management console requests that the client respond with a
Presence Pong
• A Capabilities Request from a management console requests that the client respond with a
Capabilities Response
• A System State Request from a management console requests that the client respond with a
System State Response.
For each of these message pairs, the RMCP Data block’s Message Tag field provides a method
to bind a response to its associated request.
For example, a management console sends a Presence Ping with the Message Tag field set to
12h to a managed client. The client’s alert-sending device copies the Message Tag field value
from the message received into the associated Presence Pong response prior to transmitting that
message. When the management console receives the Presence Pong, the console can quickly
map the message to its associated Presence Ping by matching the Message Tag fields.
3.2.3 RMCP Security-Extensions Protocol (RSP)
RMCP Security-Extensions Protocol (RSP) provides integrity and anti-replay services for RMCP
messages. When RSP is used, an entire RMCP message is encapsulated in an RSP header and
trailer (shown as the shaded areas in the table below).
• An RSP header is inserted between the UDP header and the RMCP header and its presence
is identified by the use of the RMCP security extensions UDP port number (0298h).
• An RSP trailer is located following the end of the RMCP message’s Data block (i.e., security
extensions are applied above the UDP layer).
The table illustrates which fields of the RSP header, RMCP message, and RSP trailer are
protected by the integrity service.
Contents Type Offset Value
Source Port 2 Bytes 22h
Destination Port 2 Bytes 24h 0298h
UDP Length 2 Bytes 26h
UDP Checksum 2 Bytes 28h
UDP Header
DSP0136 23 April 2003 Page 23 of 94