Editing Diameter (protocol) (section)

== Protocol description ==
{{Expand section|date=June 2008}}

The Diameter base protocol is defined by RFC 6733 (Obsoletes: RFC 3588 and RFC 5719) and defines the minimum requirements for an [[AAA protocol]]. [[#Applications|''Diameter Applications'']] can extend the base protocol by adding new commands, attributes, or both. Diameter security is provided by [[IPsec]] or [[Transport Layer Security|TLS]]. The IANA has assigned [[Transmission Control Protocol|TCP]] and [[Stream Control Transmission Protocol|SCTP]] port number 3868 to Diameter, as stated in section 11.4 of RFC 6733.

=== Packet format ===
The packet consists of a Diameter header and a variable number of Attribute–Value Pairs, or AVPs, for encapsulating information relevant to the Diameter message.

{| class="wikitable" style="text-align:center"
|+Diameter Header
|-
! Bit offset !!<code style="font-size:8pt; line-height:1px;;">&nbsp;0</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;1</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;2</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;3</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;4</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;5</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;6</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;7</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;8</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;9</code>!!<code style="font-size:8pt; line-height:1px;;">10</code>!!<code style="font-size:8pt; line-height:1px;;">11</code>!!<code style="font-size:8pt; line-height:1px;;">12</code>!!<code style="font-size:8pt; line-height:1px;;">13</code>!!<code style="font-size:8pt; line-height:1px;;">14</code>!!<code style="font-size:8pt; line-height:1px;;">15</code>!!<code style="font-size:8pt; line-height:1px;;">16</code>!!<code style="font-size:8pt; line-height:1px;;">17</code>!!<code style="font-size:8pt; line-height:1px;;">18</code>!!<code style="font-size:8pt; line-height:1px;;">19</code>!!<code style="font-size:8pt; line-height:1px;;">20</code>!!<code style="font-size:8pt; line-height:1px;;">21</code>!!<code style="font-size:8pt; line-height:1px;;">22</code>!!<code style="font-size:8pt; line-height:1px;;">23</code>!!<code style="font-size:8pt; line-height:1px;;">24</code>!!<code style="font-size:8pt; line-height:1px;;">25</code>!!<code style="font-size:8pt; line-height:1px;;">26</code>!!<code style="font-size:8pt; line-height:1px;;">27</code>!!<code style="font-size:8pt; line-height:1px;;">28</code>!!<code style="font-size:8pt; line-height:1px;;">29</code>!!<code style="font-size:8pt; line-height:1px;;">30</code>!!<code style="font-size:8pt; line-height:1px;;">31</code>
|-
| '''0''' || colspan="8"| version || colspan="24"| message length
|-
| '''32''' || cellpadding="1"| <code style="font-size:8pt; line-height:1px;;">R</code> ||| <code style="font-size:8pt; line-height:1px;;">P</code> ||| <code style="font-size:8pt; line-height:1px;;">E</code> ||| <code style="font-size:8pt; line-height:1px;;">T</code> || style="background:#fdd;"| &nbsp; || style="background:#fdd;"| &nbsp; || style="background:#fdd;"| &nbsp; || style="background:#fdd;"| &nbsp; || colspan="24"| command code
|-
| '''64''' || colspan="32"| application ID
|-
| '''96''' || colspan="32"| hop-by-hop ID
|-
| '''128''' || colspan="32"| end-to-end ID
|-
| '''160'''<br />... || colspan="32" | AVPs<br />...
|}

=== Version ===
This field indicates the version of the Diameter Base Protocol. As of 2014, the only value supported is 1.<ref name=rfc6733>{{cite journal|title=RFC 6733 - Diameter Base Protocol|journal=Proposed Standard|year=2012 |volume=Standards Track|doi=10.17487/RFC6733 |url=http://tools.ietf.org/html/rfc6733|access-date=12 October 2014|issn=2070-1721|editor-last1=Fajardo |editor-first1=V |last1=Arkko |first1=J. |last2=Loughney |first2=J. |editor-first2=G |editor-last2=Zorn |doi-access=free |url-access=subscription }}</ref>

=== Message length ===
The Message Length field indicates the length of the Diameter message in bytes, including the header fields and the padded AVPs.

=== Command flags ===
The "'''R'''" (Request) bit – If set, the message is a request. If cleared, the message is an answer.

The "'''P'''" (Proxiable) bit – If set, the message MAY be proxied, relayed or redirected.  If cleared, the message MUST be locally processed.

The "'''E'''" (Error) bit – If set, the message contains a protocol error, and the message will not conform to the CCF described for this command.  Messages with the "E"  bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages.

The "'''T'''" (Potentially re-transmitted message) bit – This flag is set after a link failover procedure, to aid the removal of duplicate requests.  It is  set when resending requests not yet acknowledged as an indication of a possible duplicate due to a link failure.

=== Commands ===
Each command Request/Answer pair is assigned a command code. Whether it is the request or answer is identified via the 'R' bit in the Command Flags field of the header.

The values 0-255 are reserved for RADIUS backward compatibility.
The values 256-16777213 are for permanent, standard commands allocated by [[Internet Assigned Numbers Authority|IANA]].
The values 16777214 and 16777215 (hex 0xFFFFFE and 0xFFFFFF) are reserved for experimental and testing purposes.

A Command Code is used to determine the action that is to be taken for a particular message. Some common Diameter commands defined in the protocol (base and applications) are:

{| class="wikitable sortable"
|-
!align=left|Command-Name!!Abbr.!!Code!!Application
|-
| AA-Request||AAR||265||Diameter NAS Application - RFC 7155
|-
| AA-Answer||AAA||265||Diameter NAS Application - RFC 7155
|-
| Diameter-EAP-Request||DER||268||Diameter EAP Application - RFC 4072
|-
| Diameter-EAP-Answer||DEA||268||Diameter EAP Application - RFC 4072
|-
| Abort-Session-Request||ASR||274||Diameter base
|-
| Abort-Session-Answer||ASA||274||Diameter base
|-
| Accounting-Request||ACR||271||Diameter base
|-
| Accounting-Answer||ACA||271||Diameter base
|-
| [[Diameter Credit-Control Application#Message structures|Credit-Control-Request]]||CCR||272||Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
|-
| [[Diameter Credit-Control Application#Message structures|Credit-Control-Answer]]||CCA||272||Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
|-
| Capabilities-Exchange-Request||CER||257||Diameter base
|-
| Capabilities-Exchange-Answer||CEA||257||Diameter base
|-
| Device-Watchdog-Request||DWR||280||Diameter base
|-
| Device-Watchdog-Answer||DWA||280||Diameter base
|-
| Disconnect-Peer-Request||DPR||282||Diameter base
|-
| Disconnect-Peer-Answer||DPA||282||Diameter base
|-
| Re-Auth-Request||RAR||258||Diameter base
|-
| Re-Auth-Answer||RAA||258||Diameter base
|-
| Session-Termination-Request||STR||275||Diameter base
|-
| Session-Termination-Answer||STA||275||Diameter base
|-
| User-Authorization-Request||UAR||283||Diameter SIP Application - RFC 4740
|-
| User-Authorization-Answer||UAA||283||Diameter SIP Application - RFC 4740
|-
| Server-Assignment-Request||SAR||284||Diameter SIP Application - RFC 4740
|-
| Server-Assignment-Answer||SAA||284||Diameter SIP Application - RFC 4740
|-
| Location-Info-Request||LIR||285||Diameter SIP Application - RFC 4740
|-
| Location-Info-Answer||LIA||285||Diameter SIP Application - RFC 4740
|-
| Multimedia-Auth-Request||MAR||286||Diameter SIP Application - RFC 4740
|-
| Multimedia-Auth-Answer||MAA||286||Diameter SIP Application - RFC 4740
|-
| Registration-Termination-Request||RTR||287||Diameter SIP Application - RFC 4740
|-
| Registration-Termination-Answer||RTA||287||Diameter SIP Application - RFC 4740
|-
| Push-Profile-Request||PPR||288||Diameter SIP Application - RFC 4740
|-
| Push-Profile-Answer||PPA||288||Diameter SIP Application - RFC 4740
|-
| User-Authorization-Request||UAR||300||Diameter base (3GPP) RFC 3589
|-
| User-Authorization-Answer||UAA||300||Diameter base (3GPP) RFC 3589
|-
| Server-Assignment-Request||SAR||301||Diameter base (3GPP) RFC 3589
|-
| Server-Assignment-Answer||SAA||301||Diameter base (3GPP) RFC 3589
|-
| Location-Info-Request||LIR||302||Diameter base (3GPP) RFC 3589
|-
| Location-Info-Answer||LIA||302||Diameter base (3GPP) RFC 3589
|-
| Multimedia-Auth-Request||MAR||303||Diameter base (3GPP) RFC 3589
|-
| Multimedia-Auth-Answer||MAA||303||Diameter base (3GPP) RFC 3589
|-
| Registration-Termination-Request||RTR||304||Diameter base (3GPP) RFC 3589
|-
| Registration-Termination-Answer||RTA||304||Diameter base (3GPP) RFC 3589
|-
| Push-Profile-Request||PPR||305||Diameter base (3GPP) RFC 3589
|-
| Push-Profile-Answer||PPA||305||Diameter base (3GPP) RFC 3589
|-
| User-Data-Request||UDR||306||Diameter base (3GPP) RFC 3589
|-
| User-Data-Answer||UDA||306||Diameter base (3GPP) RFC 3589
|-
| Profile-Update-Request||PUR||307||Diameter base (3GPP) RFC 3589
|-
| Profile-Update-Answer||PUA||307||Diameter base (3GPP) RFC 3589
|-
| Subscribe-Notifications-Request||SNR||308||Diameter base (3GPP) RFC 3589
|-
| Subscribe-Notifications-Answer||SNA||308||Diameter base (3GPP) RFC 3589
|-
| Push-Notification-Request||PNR||309||Diameter base (3GPP) RFC 3589
|-
| Push-Notification-Answer||PNA||309||Diameter base (3GPP) RFC 3589
|-
| Bootstrapping-Info-Request||BIR||310||Diameter base (3GPP) RFC 3589
|-
| Bootstrapping-Info-Answer||BIA||310||Diameter base (3GPP) RFC 3589
|-
| Message-Process-Request||MPR||311||Diameter base (3GPP) RFC 3589
|-
| Message-Process-Answer||MPA||311||Diameter base (3GPP) RFC 3589
|-
| Update-Location-Request||ULR||316|| 3GPP TS 29.272 [RFC 5516]
|-
| Update-Location-Answer||ULA||316|| 3GPP TS 29.272 [RFC 5516]
|-
| Cancel-Location-Request||CLR||317|| 3GPP TS 29.272 [RFC 5516]
|-
| Cancel-Location-Answer||CLA||317|| 3GPP TS 29.272 [RFC 5516]
|-
| Authentication-Information-Request||AIR||318|| 3GPP TS 29.272 [RFC 5516]
|-
| Authentication-Information-Answer||AIA||318|| 3GPP TS 29.272 [RFC 5516]
|-
| Insert-Subscriber-Data-Request||IDR||319|| 3GPP TS 29.272 [RFC 5516]
|-
| Insert-Subscriber-Data-Answer||IDA||319|| 3GPP TS 29.272 [RFC 5516]
|-
| Delete-Subscriber-Data-Request||DSR||320|| 3GPP TS 29.272 [RFC 5516]
|-
| Delete-Subscriber-Data-Answer||DSA||320|| 3GPP TS 29.272 [RFC 5516]
|-
| Purge-UE-Request||PER||321|| 3GPP TS 29.272 [RFC 5516]
|-
| Purge-UE-Answer||PEA||321|| 3GPP TS 29.272 [RFC 5516]
|-
| Notify-Request||NR||323|| 3GPP TS 29.272 [RFC 5516]
|-
| Notify-Answer||NA||323|| 3GPP TS 29.272 [RFC 5516]
|-
| Provide-Location-Request||PLR||8388620||3GPP-LCS-SLg (Application-ID 16777255)
|-
| Provide-Location-Answer||PLA||8388620||3GPP-LCS-SLg (Application-ID 16777255)
|-
| Routing-Info-Request||RIR||8388622||3GPP-LCS-SLh (Application-ID 16777291)
|-
| Routing-Info-Answer||RIA||8388622||3GPP-LCS-SLh (Application-ID 16777291)
|-
| AA-Mobile-Node-Request||AMR||260|| Diameter Mobile IPv4 - RFC 4004
|-
| AA-Mobile-Node-Answer||AMA||260|| Diameter Mobile IPv4 - RFC 4004
|-
| Home-Agent-MIP-Request||HAR||262|| Diameter Mobile IPv4 - RFC 4004
|-
| Home-Agent-MIP-Answer||HAA||262|| Diameter Mobile IPv4 - RFC 4004
|-
| Configuration-Information-Request||CIR||8388718|| S6t per 3GPP TS 29.336
|-
| Configuration-Information-Answer||CIA||8388718|| S6t per 3GPP TS 29.336
|-
| Reporting-Information-Request||RIR||8388719|| S6t per 3GPP TS 29.336
|-
| Reporting-Information-Answer||RIA||8388719|| S6t per 3GPP TS 29.336
|-
| NIDD-Information-Request||NIR||8388726|| S6t per 3GPP TS 29.336
|-
| NIDD-Information-Answer||NIA||8388726|| S6t per 3GPP TS 29.336
|}

=== Application-ID ===
Application-ID is used to identify for which Diameter application the message is applicable. The application can be an authentication application, an accounting application, or a vendor-specific application.

Diameter agents conforming to a certain Diameter extension publicize its support by including a specific value of in the Auth-Application-ID Attribute of the Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) command.

The value of the Application-ID field in the header is the same as any relevant Application-ID AVPs contained in the message. For instance, the value of the Application-ID and of the Auth-Application-ID Attribute in the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) Command for the Diameter Credit-Control Application is 4.<ref name=rfc4006>{{cite journal|title=RFC 4006 - Diameter Credit-Control Application
|journal=Proposed Standard|year=2005 |volume=Standards Track|doi=10.17487/RFC4006 |url=https://tools.ietf.org/html/rfc4006|last1=Hakala |first1=H. |last2=Mattila |first2=L. |last3=Stura |first3=M. |last4=Loughney |first4=J. |doi-access=free }}</ref>

{| class="wikitable sortable"
|-
!align=left|Application-ID!!Abbr.!!Full name!!Usage
|-
| 0||Base||Diameter Common Messages||Diameter protocol association establishment/teardown/maintenance
|-
| 16777216||Cx/Dx||3GPP Cx/Dx||IMS I/S-CSCF to HSS interface
|-
| 16777217||Sh||3GPP Sh||VoIP/IMS SIP Application Server to HSS interface
|-
| 16777236||Rx||3GPP Rx||Policy and charging control
|-
| 16777238||Gx||3GPP Gx||Policy and charging control
|-
| 16777251||S6a/S6d||3GPP S6a/S6d||LTE Roaming signaling
|-
| 16777252||S13||3GPP 13||Interface between EIR and MME
|-
| 16777255||SLg||3GPP LCS SLg||Location services
|-
| 16777345||S6t||3GPP S6t||Interface between SCEF and HSS
|}

=== Hop-by-Hop Identifier ===
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) that is used to match the requests with their answers as the same value in the request is used in the response.

The Diameter protocol requires that relaying and proxying agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. Received answers that do not match a known Hop-by-Hop Identifier are ignored by the Diameter agent.

In case of redirecting agents, the Hop-by-Hop Identifier is maintained in the header as the Diameter agent responds with an answer message.

=== End-to-End Identifier ===
The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) that is used to detect duplicate messages along with the combination of the Origin-Host AVP.

When creating a request, the End-to-End Identifier is set to a locally unique value. The End-to-End Identifier is not modified by Diameter agents of any kind, and the same value in the corresponding request is used in the answer.

{{Expand section|date=December 2009}}

=== Attribute–Value Pairs (AVP) ===
{| class="wikitable" style="text-align:center"
|+AVP Header
|-
! Bit offset !!<code style="font-size:8pt; line-height:1px;;">&nbsp;0</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;1</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;2</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;3</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;4</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;5</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;6</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;7</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;8</code>!!<code style="font-size:8pt; line-height:1px;;">&nbsp;9</code>!!<code style="font-size:8pt; line-height:1px;;">10</code>!!<code style="font-size:8pt; line-height:1px;;">11</code>!!<code style="font-size:8pt; line-height:1px;;">12</code>!!<code style="font-size:8pt; line-height:1px;;">13</code>!!<code style="font-size:8pt; line-height:1px;;">14</code>!!<code style="font-size:8pt; line-height:1px;;">15</code>!!<code style="font-size:8pt; line-height:1px;;">16</code>!!<code style="font-size:8pt; line-height:1px;;">17</code>!!<code style="font-size:8pt; line-height:1px;;">18</code>!!<code style="font-size:8pt; line-height:1px;;">19</code>!!<code style="font-size:8pt; line-height:1px;;">20</code>!!<code style="font-size:8pt; line-height:1px;;">21</code>!!<code style="font-size:8pt; line-height:1px;;">22</code>!!<code style="font-size:8pt; line-height:1px;;">23</code>!!<code style="font-size:8pt; line-height:1px;;">24</code>!!<code style="font-size:8pt; line-height:1px;;">25</code>!!<code style="font-size:8pt; line-height:1px;;">26</code>!!<code style="font-size:8pt; line-height:1px;;">27</code>!!<code style="font-size:8pt; line-height:1px;;">28</code>!!<code style="font-size:8pt; line-height:1px;;">29</code>!!<code style="font-size:8pt; line-height:1px;;">30</code>!!<code style="font-size:8pt; line-height:1px;;">31</code>
|-
| '''0''' || colspan="32"| AVP code
|-
| '''32''' |||<code style="font-size:8pt; line-height:1px;;">V</code>|||<code style="font-size:8pt; line-height:1px;;">M</code>|||<code style="font-size:8pt; line-height:1px;;">P</code>|| style="background:#fdd;"|&nbsp;|| style="background:#fdd;"|&nbsp;|| style="background:#fdd;"|&nbsp;|| style="background:#fdd;"|&nbsp;|| style="background:#fdd;"|&nbsp;|| colspan="24"| AVP length
|-
| '''64''' || colspan="32" style="background:#c0dddd;"| vendor ID (optional)
|-
| '''96'''<br>... || colspan="32" | data<br>...
|}

For simplicity, AVP Flag "'''V'''" bit Means '''Vendor Specific'''; "'''M'''" bit means '''Mandatory'''; "'''P'''" bit means '''Protected'''.

The "'''V'''" bit, known as the Vendor-Specific bit, indicates whether the optional '''Vendor-ID''' field is present in the AVP header.  When set the AVP Code belongs to the specific vendor code address space.

The "'''M'''" bit, known as the Mandatory bit, indicates whether support of the AVP is required.  If an AVP with the "'''M'''" bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message ''must'' be rejected.  Diameter Relay and redirect agents ''must not'' reject messages with unrecognized AVPs.

The "'''P'''" bit indicates the need for encryption for end-to-end security.

{| class="wikitable"
|-
!align=left|Attribute-Name!!Code!!Data Type
|-
| Acct-Interim-Interval||85||Unsigned32
|-
| Accounting-Realtime-Required||483||Enumerated
|-
| Acct-Multi-Session-Id||50||UTF8String
|-
| Accounting-Record-Number||485||Unsigned32
|-
| Accounting-Record-Type||480||Enumerated
|-
| Accounting-Session-Id||44||OctetString
|-
| Accounting-Sub-Session-Id||287||Unsigned64
|-
| Acct-Application-Id||259||Unsigned32
|-
| Auth-Application-Id||258||Unsigned32
|-
| Auth-Request-Type||274||Enumerated
|-
| Authorization-Lifetime||291||Unsigned32
|-
| Auth-Grace-Period||276||Unsigned32
|-
| Auth-Session-State||277||Enumerated
|-
| Re-Auth-Request-Type||285||Enumerated
|-
| Class||25||OctetString
|-
| Destination-Host||293||DiamIdent
|-
| Destination-Realm||283||DiamIdent
|-
| Disconnect-Cause||273||Enumerated
|-
| E2E-Sequence||300||Grouped
|-
| Error-Message||281||UTF8String
|-
| Error-Reporting-Host||294||DiamIdent
|-
| Event-Timestamp||55||Time
|-
| Experimental-Result||297||Grouped
|-
| Experimental-Result-Code||298||Unsigned32
|-
| Failed-AVP||279||Grouped
|-
| Firmware-Revision||267||Unsigned32
|-
| Host-IP-Address||257||Address
|-
| Inband-Security-Id||299||Unsigned32
|-
| Multi-Round-Time-Out||272||Unsigned32
|-
| Origin-Host||264||DiamIdent
|-
| Origin-Realm||296||DiamIdent
|-
| Origin-State-Id||278||Unsigned32
|-
| Product-Name||269||UTF8String
|-
| Proxy-Host||280||DiamIdent
|-
| Proxy-Info||284||Grouped
|-
| Proxy-State||33||OctetString
|-
| Redirect-Host||292||DiamURI
|-
| Redirect-Host-Usage||261||Enumerated
|-
| Redirect-Max-Cache-Time||262||Unsigned32
|-
| Result-Code||268||Unsigned32
|-
| Route-Record||282||DiamIdent
|-
| Session-Id||263||UTF8String
|-
| Session-Timeout||27||Unsigned32
|-
| Session-Binding||270||Unsigned32
|-
| Session-Server-Failover||271||Enumerated
|-
| Supported-Vendor-Id||265||Unsigned32
|-
| Termination-Cause||295||Enumerated
|-
| User-Name||1||UTF8String
|-
| Vendor-Id||266||Unsigned32
|-
| Vendor-Specific-Application-Id||260||Grouped
|}

=== State machines ===
{{Expand section|date=December 2009}}

The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages. This is part of the basic protocol functionality and all stacks should support it and as such abstract from the connectivity related operations.
<gallery>
File:RFC3588_peer_state_machine_1.png|Peer State Machine Part 1
File:RFC3588_peer_state_machine_2.png|Peer State Machine Part 2
</gallery>

Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The RFC 3588 defines an authorization and an accounting state machine.
<gallery>
File:RFC3588_auth_state_machine_client.png|Diameter Authorization State Machines (Client)
File:RFC3588_auth_state_machine_server.png|Diameter Authorization State Machines (Server)
File:RFC3588_acct_state_machine_client.png|Diameter Accounting State Machines (Client)
File:RFC3588_acct_state_machine_server.png|Diameter Accounting State Machines (Server)
</gallery>

=== Message flows ===
[[Image:Diameter message flow.png|right]]
The communication between two diameter peers starts with the establishment of a transport connection ([[Transmission Control Protocol|TCP]] or [[SCTP]]). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). For RFC3588 compliant peers TLS (Transport Layer Security) may optionally be negotiated. For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA.

The connection is then ready for exchanging application messages.

If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.