DOF Protocol Specification: DOF Protocol Specification

Each PDU represents information sent on the network in some context. This usually means that there is information sent 'surrounding' the PDU itself. This information provides the 'context' for the PDU.

For example, the context for the DOF Protocol Stack itself is a network transport. This could be UDP/IP, TCP/IP, or any other transport. The transport will require certain headers and trailers, but they are not shown in each DOF Protocol Stack PDU. In this example the transport provide the context of the DOF Protocol Stack PDU.

In a similar way, the DOF Protocol Stack defines the context for the other DOF protocols. The Object Access Protocol, for example, can use the DOF Protocol Stack for its context. Just as the transport headers are not shown for the DOF Protocol Stack, the DOF Protocol Stack headers are not shown for the Object Access Protocol.

Understanding the context requires understanding the relative position of the different layers in the protocol stack. Each PDU defines the ordering of all of its parts, and may indicate that it is itself an instance of some other general PDU format. This means that it is always possible to start at a high-level PDU definition and understand it completely, but not always possible to identify everywhere that a particular PDU may be used (as a part of some other higher-level PDU).

Each protocol specification defines its specific contexts. The context definition includes a description of the underlying stack layer (or the containing layer), and defines the information that must be available from that layer (for reception) or passed to that layer (for transmission).

As an example, the context of the DOF Network Protocol is a transport. The transport has a requirement to provide the addresses of nodes, and so part of the context for the transport is the sender address (for reception) or the target address (for transmission). Any transport that will work with the DOF Protocol Stack must meet the context requirements.

Many times a particular PDU will be a specific type of a more general PDU. In these cases, the PDU will indicate that it is an 'instance' of the more general type.

Each PDU will have qualifications placed on its use. The general qualifications include security and transport requirements. The following terms identify these qualifications. Others may be present as well.

Each PDU shows a container, represented as a sequence of fields. The table fully describes each field.

The following is an example of a PDU description.

The container represents the PDU. The diagram shows Fields first to last, left to right and top to bottom. This means that the first fields appear on the wire before the last fields. This is a general principle: things on the top and toward the left in the diagrams appear on the wire before things on the right and bottom. Note that the transport is free to use whatever ordering it must, and memory layout may different from the PDU definition. However, the transfer of a PDU from a program, over an arbitrary transport and into another program must maintain the perceived ordering between the two programs. PDU diagrams are always shown MSB first (most significant byte) and msb first (most significant bit) unless otherwise indicated.

Each field identifies its contents and provides information necessary to understand its use. In the example above, the diagram shows the first six fields of the container. Each field is named, with the exception of reserved fields which are indicated as being grayed out. Field names use monospace text similar to that used in program listing. The third field shown is indicated as reserved. Reserved bits have special requirements described in the DOF Protocol Specification.

Several different field cases are typical, described in the following sections.

There are several free tools that will do comparisons of the text of a PDF. One of these is the xdocdiff plugin for WinMerge. The plugin extracts the text from the PDF (including some information like page numbers), and WinMerge then compares the text.

WinMerge is available from http://winmerge.org. The xdocdiff plugin is available from http://freemind.s57.xrea.com/xdocdiffPlugin/en/index.html.

In order to compare formatting, or to see the changes in the context of the document, a graphical compare is required. There are several free tools, but each has limitations.

Both of these tools suffer from their page-by-page comparison methods. This means that when context shifts because of additions or removals that they start sensing changes at each page boundary. DiffPDF has the ability to select comparison ranges, allowing the program to synchronize at the beginning of each section, but this requires manual configuration and can be difficult for large documents.

There are also commercial tools that do an excellent job at comparing PDF documents. The first is Adobe Acrobat (http://www.adobe.com/products/acrobat.html), which in later releases has a 'Compare Document' feature. The result of the comparison is an annotated PDF, and hovering the mouse over the change will show the details.

Another commercial tool is PDF Content Comparer (http://www.inetsoftware.de/products/pdf-content-comparer) from i-net Software. This tool does side-by-side comparison, but has an intuitive auto-synchronize that keeps similar content lined up even when additions or deletions have occurred.

The IANA has assigned the decimal number 4561 for DOF protocols by IANA. See the IANA site for more information.

IEEE has assigned the hex number 0x8876 is reserved for DOF protocols. See the IEEE site for more information.

The IANA has assigned the hex number 0x4027 for DOF protocols. See the IANA site for more information.

This typical combination assumes that a server was used to create the session, and that from that point the session exchanges datagrams that are lossless and in-order (assuming that the two are related). Note that it is common for this combination to also provide a streaming session, but that DOF protocols do not differentiate streaming/datagram for this combination: it may be either. It is typical that this type of session will include only 2 nodes, but it is possible to have n-node sessions that are lossless.

DOF protocols make the following assumptions about these types of sessions and the servers that establish them:

Lossless sessions are almost always associated with streaming, and so this category is often called 'streaming' servers. However, it is actually the session and lossless aspects of the sessions, along with the number of nodes in the session, that is the most critical for DOF operation.

This typical combination assumes that no session is created. This means that one node maintains state about the other (the client), and that the other node utilizes a server that receives datagrams. The lack of shared state almost always indicates a lossy relationship.

Note that the lack of shared state (even though one node is likely maintaining state) means that no session exists. This lack of session means that the server treats each individual datagram as unrelated (although datagram relationships may be reintroduced due to different protocol layers).

DOF implementations make the following assumptions about these relationships:

Because of their association with a datagram, this category is often called 'datagram' servers. However, it is actually the lack of session and lossy nature of the server that is the most critical for DOF operation (along with the capability of multicast and broadcast).

This typical combination assumes that a session is created, but that datagrams may be lost. All nodes maintain state about the session. It is very typical for an implementation to create this combination from the none/lossy combination just described through the use of different protocol layer functions. Note that the client likely already maintains state, and so only the server needs to be told to keep track of the particular client. Note that some sort of session identification is likely required as well, provided by different protocol layers on top of the transport. This identification relates different datagrams to each other, as well as to the session information.

DOF implementations make the following assumptions about these relationships:

As mentioned earlier, it is often difficult for an application or transport implementation to accurately determine the target transport addressing that was used on any particular datagram. Even in the case of sessions that should be point to point, the possibility of packet injection means that the 'real' source of a datagram is suspect. In the case of lossy servers it may not be possible to determine if the client really used transport unicast, multicast, or broadcast.

This can cause problems for DOF implementations, since application behavior relies on the specific property values associated with the datagram.

In general, this means that in the absence of security that the client and server must do their best to determine the actual datagram properties, but that they must realize that the information cannot be fully trusted.

However, once a security layer has been added then the properties must be trusted. This means that the source and destination application addressing (not transport addressing) is verified, that the datagram data and size is verified, and that the transport address type (unicast, multicast, or broadcast) is verified. When the security protocol cannot validate any of these properties then it must modify the datagram properties to represent what is possible, rather than trust the transport-determined property value.

For example, if a session (including the DOF protocol layers) can guarantee that a particular datagram arrived from a particular sender and can only be received by a single node, then it can modify the property to indicate unicast addressing. If, however, the security protocol cannot guarantee a single receiver, then it must modify the property to indicate multicast or broadcast as appropriate. Applications that base behavior on these datagram properties for a secure datagram must use the property values as modified by the security protocol.

The DPS frequently runs over lossless transports like TCP/IP. These transports are typically optimized for lossless bi-directional data, and can have performance issues when used to transmit uni-directional, bursty datagrams. Unfortunately, many small-footprint stacks maximize this performance problem by limiting their implementations. To minimize problems it is best that each datagram be acknowledged before the next can be sent, or at least that the datagrams flowing in each direction are roughly equal.

There are two common optimizations specific to TCP/IP that can cause performance problems in these situations. The first is the Nagle Algorithm, which can slow the sending of data assuming that it is desirable to combine many small datagrams into fewer larger datagrams. The second is the introduction of a delay on the ACK assuming that it is better to piggyback the ACK on a data datagram than to send it with no data. The combination of these two optimizations can lead to poor performance of the DPS on TCP/IP.

There are typically options to disable the Nagle Algorithm (TCPNODELAY). Because this affects outgoing traffic there is little more that can be done to optimize performance other than disabling it.

The second optimization, that of delaying an ACK until data exists to "piggyback" it on, is typically not configurable. The answer to this performance issue is to ensure that the protocol in question is symmetric - meaning that each datagram sent in one direction elicits a response datagram going the other direction.

Unfortunately, a typical use case is to establish a session, establish state, and then wait for responses. In this case, little or no traffic moves in one direction and many periodic datagrams move in the other direction. This is the worst situation for both the Nagle Algorithm and the ACK-delay problem. The Nagle Algorithm delays the commands, combining them into larger datagrams. The ACK messages delay because no datagrams are going in the other direction. This is standard problem with asymmetric traffic in TCP/IP.

The DPS provides the commands (through the Ping and Heartbeat commands) to allow for symmetry in the application protocols. This means that if an application protocol knows that it is in a non-symmetric situation and wants to even out the datagrams that it can use the DPP common commands. This behavior should depend on the transport, as it knows whether symmetry is beneficial.

Throughout the DPS and DOF application protocols, there are references to 'Reserved' bits. The following discussion applies to all of these fields.

This protocol specification defines the meaning of every bit that passes over the wire. In many cases, it does so by defining a field and then defining the range of values that can appear in that field. In other cases, it defines a 'bit field,' and in doing so leaves some bits as available. These bits may require a constant value, or the specification may indicate that they are Reserved.

In the absence of other requirements, the handling of these remaining bits would be ambiguous, which is not a good idea in protocol design. However, the possible future use of these bits is restricted because existing implementations will not understand any newly defined behavior.

Any future use must then:

Note that any changes that do not meet these requirements necessitate changing the protocol revision.

Handling these bits requires correct management. The following rule defines correct behavior.

A general requirement of the DPS is that non-communicating or ill-behaved sessions should be detected and terminated/closed as quickly as possible. Ill-behaved sessions are particularly dangerous (from a security perspective) during stack establishment. A goal is to force negotiation as quickly as possible, without being so restrictive that slow network links cause problems.

This general rule applies throughout negotiation and through the authentication phase. The single timer use does not continue into the application protocols, but may still be used (based on the transport requirements) to determine communication failures. These types of timeouts are dependent on the implementation.

Different nodes in the same network may support different versions of DPS layers and different application protocol versions. A primary goal of DOF protocols is interoperability, and so it is important to be able to discover these different nodes and communicate with them if possible.

At the lowest layer (transport), there should be the ability to communicate with all nodes. This usually requires either multicast or broadcast. Specific system implementations may utilize non-standard addressing in order to localize communication. Independent of specific system requirements, DOF nodes should still listen on the standard addresses and ports defined for the transport in order to facilitate discovery by general nodes.

The ability to speak multiple versions of a protocol is generally associated with a gateway. However, it is possible that some nodes (clients or servers) may not function as a gateway, but may speak different protocol versions.

If these nodes simultaneously attempted to use all of the versions that they can, worst-case traffic would result. This is because they may be sending protocol versions that no other node understands, and so the traffic is wasted.

The same is true of a gateway. If gateway nodes simultaneously used all of their versions then the same worst-case traffic would result. It only makes sense for a gateway (or a multi-protocol server or client) to speak versions that others on the network are able to understand.

DOF protocols provide a method for discovering protocol versions in an optimized way. As a requirement, the nodes must be capable of using a multicast or broadcast transport. In general, the difference between 'node discovery' and protocol discovery is that in protocol discovery the goal is not to identify each node, but rather each protocol and protocol version. Whether there are 10 nodes speaking a version or 1,000 nodes is not important (that number can be determined later by using node discovery). This allows for some specific optimizations for protocol discovery.

As an example of the problem of multiple versions, consider the following. A company sells an DOF-based sensor product. The product implements specific versions of the DNP, DPP, and applications. The sensor only responds when queried. Years pass, and the customer has removed the original product that used the sensor, but has not removed the sensor. The customer installs a new product, which speaks different DNP and DPP versions.

How can the new product speak to the old sensor? Without aid (some sort of gateway) it cannot, unless the new product also speaks the older protocol versions. Assuming that it does not speak the older protocol version, then a gateway (a special node that speaks multiple protocol versions) is required. How can such a gateway discover which DNP and DPP versions are available on a network?

One solution, discussed above, would be to cycle through all possible versions, discovering nodes that use each combination. This is expensive in terms of network traffic. Another solution would be to have each node advertise itself on the network periodically, but this is also expensive in terms of network traffic that would be mostly redundant.

In order to solve this problem, DOF specifications define version zero of each protocol (and protocol layer) as a query protocol. Each node is required to support version zero, although it does not encapsulate normal PDUs. The version zero protocol for each layer follows a pattern that allows version discovery.

This means that all nodes will support at least two versions of each stack layer: version zero (for version discovery) and some other version (for PDU encapsulation). Implementations drop unrecognized versions.

Note that by supporting the query version (version 0) a node is only required to respond to queries. If a given node has no reason to discover other version information then it never needs to initiate a query.

Different nodes in the same network may simultaneously be using different versions of DOF protocols, including the DNP, DPP and applications. This means that when two nodes communicate, they need to determine which versions they will use.

If the nodes are using a lossy session or server then the sender can either assert a version or use version discovery (unicast) to determine the versions spoken by the target. If the sender asserts a version that the receiver does not understand then the receiver silently drops the datagram.

When two nodes establish a lossless session, they have the benefit of both bi-directional non-broadcast communication and shared state. This makes the negotiation of protocol versions possible. It is also possible that a lossless session spans local networks where protocol discovery (which uses a multicast or unicast datagram) is not possible. This means that protocol negotiation is required for the two nodes to communicate.

There are two phases to protocol negotiation of the DPS on a lossless session. First, the nodes negotiate DNP and DPP (simultaneously). Following that negotiation (and assuming successful negotiation) a specific application protocol, the DOF Session Protocol (DSP), is used to negotiate the application layer protocols and their options that will be used on the session. This negotiation includes the specific authentication and key distribution protocols that are required.

Negotiation of the protocol version begins with the client. The client identifies the DNP and DPP that it prefers (possibly the only ones it understands) by sending a two byte datagram (one byte DNP, one byte DPP) using only the protocol version bytes and omitting flag bytes, meaning that the flag bits must be clear.

If the server can accept those protocol versions (even if it does not prefer them because they are older and less capable), it echoes a two-byte datagram using the same protocol versions, or alternatively it just begins using those protocol versions by sending a datagram that uses them. Both the client and server know that they are speaking the same versions, and the negotiation of application protocols begins (described further in the section on Application Protocols). The server knows the protocol versions because it echoed the datagram (acceptance), the client knows because it received a datagram with the same protocol versions that it sent.

If the server cannot understand the protocol versions requested, it responds with a two byte datagram using the protocol versions that it prefers (potentially the only ones that it understands), and the roles of client and server are reversed (for the purposes of further negotiation). This means that the old 'client' node is in the role of responding with either an acceptance, beginning to use those versions (by sending a datagram), or another 'rejection' in which case the roles are reversed yet again.

Upon receiving a two byte datagram during negotiation with protocol versions that are not understood, the response is always a two byte datagram with the next preferred protocol versions that are understood or a full datagram that uses a set of versions. This proceeds until either side has no untried protocol versions or a bad datagram (non-negotiation and using versions that are not understood), at which point the session is terminated.

It is common for devices to implement a single set of network and presentation protocol versions. It is also common for devices to initiate sessions with more powerful nodes. This means that in the typical case a client (the node sending the first negotiation bytes in the common case) speaks a single set of protocol versions. The same situation can apply to a server.

In this case where the sender speaks only a single set of protocol versions, then the first datagram sent may include the flag byte, control fields and encapsulated application data. This is 'asserting' protocol versions. This kind of assertion is always a valid response during negotiation, and the client may immediately use it.

If the server speaks only a single set of protocols, it may preemptively send a full datagram with a flag byte, control fields, and application data when the transport session is established. The client would treat this as the end of negotiation. In the case that the client cannot speak those versions, the client terminates the session. If the client had also asserted and the versions did not match then the client and server would both terminate the session. This is correct behavior because an assertion is only possible if the node understands only a single set of versions. Any mismatch of asserted versions means communication is not possible.

Throughout the DPS documents, several references to transport addresses exist. The use of this term 'transport address' means a unique identification of the source of some communication on a specific transport. It also identifies an individual target on a transport.

Different transports may use similar logical addresses. There can also be multiple interfaces speaking the same protocol with identical addresses. The stack should consider all these cases as different transport addresses.

There are transports that lack a well-defined sense of addresses, or where implementations make it necessary to add additional data in order to distinguish addresses. To resolve this problem the DPS adds its own sense of a logical address, called an DNP (DOF Networking Protocol) address. It is important to understand its relationship between DNP addresses and transport addresses.

In the case of sessions, the notion of 'transport address' really relates to the session and not just the transport. For example, it is possible to have both a UDP datagram session and a TCP streaming session that involves the same 'transport address.' In this case, the 'transport' is also part of the 'transport address,' even though in both cases the underlying transport is IP.

This distinction is critical because many stack issues relate to the session, and not directly to the 'transport address' when used in the more limited sense.

A common issue with broadcast and multicast transports is receiving datagrams that the node sent, either because of operating system problems or because of network echoes. In order to prevent each layer of the DOF Protocol Stack from needing to address this issue the transport layer of the DPS must ignore these datagrams.

The transport (referring to the layer directly below the DNP) is uniquely able to remove these echoes because only it is aware of the specific meaning of transport addresses. It also knows (or can know) the different types of sessions and servers that are in use, and whether it is possible for loopback to occur.

In addition, if a transport is not able to determine on its own whether loopback will occur, there is a specific DNP version (127, described later) which a transport implementation can use to determine if loopback is occurring.

Stated another way, all DPS transport implementations must reject inbound multicast or broadcast datagrams that sent by the receiving application. Pay particular attention to the wording – datagrams from the same application must be rejected, not the same node.

In general, this means that implementations must compare the source information (for example, host, and port for UDP) for inbound datagrams with the source information for each session for the receiving application. If the source information matches, then the receiver drops datagram. If such a comparison is not possible or may not result in precisely correct results then the implementation may use DNP version 127 to send a datagram and watch for loopback.

As a further example, two applications running on the same node may be receiving multicast datagrams. Both applications hear datagrams sent from the first application, but only the first application drops them. The same is true for the second application and its datagrams.

Receiving any invalid PDU signals either a corrupt communication channel, loss of state, or a possible attack on the protocol. Invalid PDUs include things like invalid op-codes, malformed flags or other fields, PDU under runs and over runs during parsing, or other structural problems. Invalid PDUs do not include cases where the structure and references are correct, but the operation fails to execute for other reasons.

Throughout the entire DOF Protocol Stack and all related application protocols, the requirements for handling invalid PDUs are identical. The primary consideration is maintaining correct session state (both transport and DPS). If session state cannot be ensured, then the session (whether transport or DPS) must be closed.

For session 'none' state management is not a concern, because there is no DPS session state by definition. However, there is still transport state to manage. For example, streaming protocols like TCP may not be able to identify PDU boundaries without state. If this state is confused by an invalid PDU then the transport session state is lost.

In most cases, datagram PDUs can be dropped without loss of state, while streaming PDUs cannot be dropped without loss of state. Streaming sessions usually have an in-order, guaranteed delivery feature that is leveraged to minimize state transferred in each PDU (for example, packet sequence numbers for security). In these cases, dropping PDUs will affect the state and must therefore result in the session being closed.

The SID is the primary unique part of an operation identifier. This means that they are typically large (to achieve the goal of global uniqueness). The SID used on a secure connection requires the requesting of permission to use the SID as discussed below.

A typical case for a limited-resource node is:

This is an ideal case for determining a SID because the SID can be a function of any unique information associated with the node.

However, there are situations where one or more of the following are true:

In these cases, the application must choose the SID very carefully. In general, each instance of a running application (over time) should use a unique SID. The SID may reflect both some node property and also a sequence number or other unique factor to make each program instance unique. The goal is to prevent reuse of operation identifiers, even accidental reuse.

This discussion results in the following points for a client or server that cannot determine that it is unique on a node:

SID comparison (and operation identifier comparison) is independent of the specific SID format used in a particular PDU.

Using a SID on secure sessions requires appropriate permissions. These permissions are associated with a particular DPP version, and so the particular permission formats are dependent on the DPP version used.

Clients and servers must negotiate any required SID permissions as part of the initial permission requests for the session, since without the permissions neither can send additional secure operations (including a request for additional permissions).

The statements above about DIRECTED and FLOODED operations reference state required for a DIRECTED operation, and state maintained for FLOODED operations. This section discusses these state requirements.

In order to manage a FLOODED operation, each node must maintain information about the operation in order to recognize duplicates and make decisions about how to handle the duplicates. Recognizing the duplicates requires a common identifier, which is the operation identifier. Using the operation identifier means that it must not change as it propagates through the network – a signature requirement for FLOODED operations. Another key requirement is that state for the operation must persist throughout the network in order to prevent loops and ringing.

The ultimate requirement for FLOODED operations is to create a DAG (directed acyclic graph) for each FLOODED operation. The root of the DAG is the original operation source, and it includes all other appropriate nodes as children. This ordered structure means that any node in the DAG has a sense of its parent, called the 'source.' Operations can outlive connections, and so the DAG for an operation may change over time.

The DAG resulting from a FLOODED operation is the basis for establishing new operation state. To understand this, examine two common cases: responses and reactions.

The DOF DPP layer defines response operations. The definition allows for specific behavior for the response, as follows:

Responses are immune from many issues regarding state management, always relying on the established state of a single 'command' operation.

Contrast the behavior of a response with the class of operations called 'reactions.' A reaction is an operation that results from a causing operation, but that is not a response. There are two primary cases for a reaction: a pseudo-response and a general reaction. Pseudo-responses follow the rules for a response (traversing a single DAG to a source) and do not require any special discussion. General reactions are more complicated, because they are not restricted to a single DAG.

Note that there is an assumption in discussing a reaction that it has available to it the DAG of some (possibly multiple) causing operations. Each of these operations has an associated DAG. However, reacting to multiple DAGs by way of combining them in general does not create a DAG. This means that while each operation itself has a DAG, reacting simultaneously using multiple DAGs must follow the rules of a FLOODED operation. To understand this, imagine a network in which each node establishes a causing operation at the same time. A node, anywhere in the same network, that sends a reacting operation will need that operation to go to every node in the network – and must in the process handle the presence of loops and prevent ringing. This is exactly the definition of a FLOODED operation.

Finally, note that reactionary operations may themselves establish a DAG. However, they must do this based on their own state and rules. Other operations may use this DAG, and in doing so, they are not FLOODED. This is in fact the definition of a DIRECTED operation. This implies that all DIRECTED operations must identify the method used to establish the DAG that they will use.

The DPP manages operations based on datagrams sent on the network. These datagrams transfer state from one node to another, and based on the operation both the sender and the receiver must manage the state.

The management of operation state is a critical security issue. Receivers must validate a datagram, from a security perspective, before the receiver modifies any operation state based on the datagram. The DOF Security Specification discusses this at greater length.

Programs create and manage operations, and so operation identification and 'program' identification are related. There are two identifying marks for a program in an DOF network:

This means that an operation source equates to a transport address. The operation itself relates to a SID, although maybe not the SID of the sender (in the case of an operation forwarded through another node).

The state associated with an operation is similar to the state of a session: it has a beginning, it is maintained, it can be cancelled (closed), and it allows state to be shared between endpoints. A key difference between sessions and operations is that operations distribute throughout a network (typically a mesh network). This section discusses common aspects of operations and the lifecycle controls that are included in the DOF specifications.

To emphasize this last point, the state associated with an operation distributes equally among all participating nodes. There is no way to use a single operation to maintain different state between each receiver and the sender. Shared state that is limited to a single sender and receiver requires its own operations.

For any operation, each node is in one of the following states:

The receipt of a datagram causes most changes to operation state. The exception is the Timeout state, and sometimes the Lost state. There is a special case possible where an operation arrives (Initial state), but has already timed out (Timeout state). There are several rules for handling this situation:

The following sections discuss the DPP requirements for operation management. Application protocols will have their own requirements.

Not all state associated with an operation is invariant, but some is. For example, the operation identifier uniquely identifies the operation and is invariant. However, a source can rename the operation (view this contradiction as a cancellation followed by the establishment of a new operation). The duration, on the other hand, changes with each retry of the operation.

The situation of operation state gets more complicated when the application protocols are involved. It is important that protocol implementations be aware of what state can change and what state cannot change.

The purpose of this section is to define the common situations of mutable operation state, specify the common rules, and point out that the application must identify which state can change and which state cannot.

There are two cases when the state of an operation can change. First, when the source of the operation changes. Some operation state relates directly to the source, and so when the source changes then the state associated with the source must change. Second, state changes when the source retries the operation. A retry of the operation may change any state other than invariant state.

This leads to the following classifications for operation state:

For DPP, only the operation identifier is invariant. Specific DPP versions may identify additional state, and should classify the type of state they introduce.

In many application protocols, it is desirable to consolidate multiple operations into a single operation that has the same effect. This can result in both bandwidth and CPU benefits. However, the nature of the DOF Protocol Stack makes such consolidation difficult unless certain rules are followed precisely.

Each application protocol must define the specific rules for consolidating its own operations. This section highlights the difficulties that all application protocols must avoid. If an application protocol makes no mention of consolidation, then assume that consolidation is not possible.

Key to understanding consolidation is the description of DIRECTED and FLOODED operations presented above. A not so obvious effect of FLOODED operations is that the source node does not know, in general, if a receiving node 'accepts' the sender as the authoritative source of the operation.

For example, the following situations can arise:

This lack of knowledge makes it difficult for a node to consolidate operations, because it does not know (again, in general) whether it will be the source of the consolidated operation. If it turns out that the sender is not the source, then the operation that has been 'merged' into the consolidated operation may remain unknown to the receiver (assuming that consolidation results in not forwarding the operation). In turn, this may result in the receiver’s behavior being different from if it had used the sender as the source, making it impossible for the consolidating node to maintain the behavior of the merged operation.

In order to assure that consolidation is valid, a node must only consolidate operations that meet specific requirements. These requirements ensure that the receivers of the consolidated operation accept to the sender as the source of the operation (if they would accept the operation from any node).

In general, this means that consolidated operations must be compatible from a security perspective and either:

The first two rules actually consolidate to a single rule: nodes may consolidate operations that use the consolidator’s SID. This also guarantees that a single application (which uses a single SID by definition) is always able to consolidate its own operations.

The third rule indicates that nodes may consolidate operations from the same source as defined by each DPP version.

It is important that all implementations handle operation state changes in the same way. Typically, this is not an issue; however, the edge cases need clarification. These situations are difficult based on security considerations.

Nodes apply the following sequence for all operation state changes. Note that these steps are logical, and may be implemented in many equivalent ways. For each received operation:

The following discussion applies to reading DPS datagrams on streaming sessions. Datagram transports provide entire datagrams to the reader, and so there is usually not a question of how much data to read. However, on streaming sessions it is typical to obtain data as it arrives without regard to the datagram boundaries that were sent.

The issue is that issuing a read for more data than the datagram contains may cause an indefinite block (at least until another datagram arrives), and reading too few bytes, while safe, is not optimal for many implementations.

The ideal situation is to read the datagram in 2 read operations. The first read obtains enough of the datagram to completely determine the remaining length, and the second read obtains the rest of the datagram. In the worst case this may not be possible, and 3 read operations are required. This occurs when the datagram length changes (getting larger), and not enough data is obtained in the first read to determine the length.

In order to optimize behavior, it is useful to know the smallest datagram size possible, as it will always be possible to read that length. Referring to the DPS.1: DOF Protocol Stack definition; there are always at least three layers present. The DNP and DPP have a mandatory header byte, and the Application has a header that is at least one byte. This means that there are at least three bytes in any datagram. However, in the case of streaming sessions there must be length information present in the DNP. This means that the minimum datagram size is at least four bytes, with at least two bytes required after the DNP layer.

Also note that on streaming sessions that the DNP version (which determines the length) is negotiated (or asserted) immediately, and so the particular DNP version in use will be known and will not change.

On streaming transports, the DNPv1header has a minimum size of three bytes (version, flag, one byte length) and a typical maximum size of five bytes (version, flag, three byte length). Additional bytes after the length can be included with the rest of the PDU for this discussion. The question is whether it is always safe to read the additional two bytes. This is guaranteed to be true because the DOF Protocol Stack must always include an application protocol, and the required headers are at least two bytes long.

Each transport that supports the DPS defines an MTU or Maximum Transmission Unit. The MTU defines the maximum PDU length, based on the transport, and is independent of the capabilities of the protocol itself.

Independent of the transport, the maximum MTU for any transport is 2²⁴-1. This is a massive number, and typical environments will never need to handle datagrams that large.

Note that no current DPS version defines fragmentation, so there is currently no way to send an DPS datagram that is longer than the MTU on that transport. The solution to this problem is to use a streaming session and stream the datagram over that connection. If streaming sessions are not supported then the information can be fragmented at the application layer, with an interface allowing access to the different fragments of data or a streaming transport (below DPS) can be provided.

Transports may also define a 'minimum transport unit', or the minimum datagram size that can be sent. It is the responsibility of the DNP to provide methods for padding the datagrams so that any minimums are met.

The DNP layer sits on top of the Transport layer. As discussed in the Transport section, each transport provides sessions and servers, provides meaning for transport addresses, and deals with the different datagram types (unicast, multicast, broadcast).

The DNP itself is related to a SESSION. The SESSION includes information necessary to send and receive datagrams on a particular transport. Further, based on the transport, different SESSIONS may be related.

For each received PDU the DNP requires the following context information from the Transport:

For each PDU that the DNP is asked to transmit, the context given must contain the following in addition to the information required of the transport context:

There are potentially many different versions of this protocol. The specific version is always determined by the first header byte as shown above.

The following describes behavior and requirements that apply to all versions of the DOF Network Protocol.

Each DNP version defines a 'default' value for its flags. The specific default values can be found in the documentation for the version. This default flag value must be independent of transport. After any negotiation datagrams, if the flags are not present then the default flag value must be assumed.

DNP must provide for determining the size of DPP datagrams. It must also provide for any additional logical addressing in addition to that required by the transport.

DNP logical addresses are an extension of transport logical addressing. Each datagram received can contain a specific source and destination DNP logical address. This information is encapsulated along with the transport address information to form the 'logical address' for DOF communications. The permitted values for DNP addresses include the special value NULL and integer values from zero (0) to 2²²-1 (4194303).

The specification of each DNP version will present the methods used to handle these requirements.

The server side of each lossless session must initially be associated with DNP address NULL. This allows negotiation to occur based on that target address. Each DNP version must use DNP address NULL for all traffic that does not explicitly include a different DNP address.

DNP addresses are associated with the transport address. This means that if the transport address changes for any reason that the associated DNP logical address is no longer valid. For example, a command that is received that includes a source DNP address but requires a multicast response would need to drop the command’s DNP address in the response packet (because it is being sent to a different transport address).

As described above, there are problems attempting to discover all of the different versions of the different DPS layers that are in use in a network. In order to solve this problem, all nodes are required to understand DNP version 0 in addition to at least one other version.

There are two PDUs defined for version 0. The first is a query, and it corresponds to a single byte header. There can be no flag bytes. The second is a response, which is sent some time after the query, and which corresponds to a list of DNP versions supported by the sending node. The format of this PDU is the header byte followed by a number of bytes each representing a version. There must be at least one additional version other than version 0 supported by a node, and so the PDU length (either the query consisting of all zero (0) bytes or the response that must contain at least one non-zero number) differentiates between a query and its response.

Each query is associated with a SESSION that includes a lossy server. This means, for example, that a node supporting multiple multicast addresses must track queries (as described below) for each SESSION.

There are transports that require minimum datagram lengths. In order to support query on these transports, certain trailers are defined on both the query and response.

First, the query PDU may contain as many trailing zero (0) bytes as necessary to meet datagram length requirements. Query datagrams are then defined as datagrams consisting of all zero bytes.

Second, the response PDU may contain as many trailing zero (0) bytes as necessary to meet datagram length requirements. Response datagrams are then defined as a zero (0) byte, followed by some number of non-zero bytes, followed optionally by some number of zero (0) bytes. Note that there is a problem in determining the correct response to a request where there are multiple servers on a single transport address (differentiated by DNP port). As there is no way to identify which server should respond, the (single) response should aggregate all servers.

Responses to unicast queries are sent unicast.

In the example above, node Query wants to determine the DNP versions supported by node A. It sends a unicast DNPv0 Query PDU to A. Since the PDU is unicast, node A immediately responds without any use of timers or delay.

Responses to multicast queries must be sent within three (3) minutes of a query, but the exact timing should be determined randomly and controlled by other network traffic as described below. Responses to unicast queries should be sent quickly.

For multicast queries, between the time of the query and the time of the response three events can prevent sending a version in the query response (that consists of a set of versions):

The goal of this logic is to only send information that cannot be determined by watching network traffic. The specific goal of version detection is not to discover nodes on the network, but rather to just discover versions of protocols that are in use.

In the example above, a node Query initiates version discovery by multicasting an DNPv0 Query PDU. This PDU is heard by nodes A and B. Both of these nodes pick random times within the next three minutes and start timers for when they will respond. The timer on B expires, and so B sends a multicast DNPv0 Query Response. This PDU contains the same version as A, and so in node A cancels its timer without sending a response.

If each version in the pending query response is covered by one of these cases then the query response is not sent. Otherwise at least the versions that have not been seen are sent.

For example, assume that a node N speaks version A and B of DNP. It receives a multicast PDU that is an DNP version 0 query. It determines (randomly) that it will send its response in 2 minutes. The response will be a PDU consisting of a zero byte (header), followed by A and B.

After some time and before the two minutes pass a PDU is multicast from node N using DNP version A. Sometime later, but still before the two minutes pass, a multicast PDU is received by node N using DNP version B. In this case, the pending response PDU is cancelled.

Assume however that the second PDU is not received. The 2 minutes pass. In this case a response containing at least B is sent.

This protocol exists only to accomplish version discovery on a network. In particular, it cannot be used to encapsulate any other stack layers.

This section describes version one-hundred twenty seven (127) of the DOF Network Protocol. The protocol begins with a general one-byte header as described above. This byte contains the version (127).

This version is somewhat special in that it is never really 'supported' by the DPS. It is defined, but its use is reserved for the DPS transports, and not the DPS itself. Because of this, version 127 is not advertised using DNPv0.

The DPP layer sits on top of the DNP layer.

For each received PDU the DPP requires the following context information from the DNP, in addition to the context provided by the Transport:

In addition, for each COMMAND the following must be specified:

Finally, for each RESPONSE the following must be specified:

There are potentially many different versions of this protocol. The specific version is always determined by the first header byte as shown above.

Each DPP version defines a 'default' value for its flags. The specific default values can be found in the documentation for the version. During the negotiation phase no flags are sent, and the meaning of the default flag value is also ignored. After negotiation, if the flag byte is not present then the default value must be assumed.

One of the major purposes of DPP is to protect data through encryption and message authentication. Note that DPP does not provide authentication or key distribution, which are provided by specific application protocols. It is the job, however, of DPP to actually encrypt and decrypt the datagram.

Each DPP version defines how it provides security, although specific security modes of operation are leveraged. DPP is limited in this role to the information provided to it in the context of the datagram, either from layers above (like encryption keys), information that it transmits (fields) and information from the network protocol.

DPP is told that a particular datagram must be secure, and whether encryption or message authentication is required. It also allows the application protocols to determine whether a particular received datagram was secure, and how (authenticated, encrypted). The specifics of how this information is passed on the wire are dependent on the DPP version, and the method by which an application protocol obtains the information is dependent on the DPP implementation. DPP will likely leverage other protocols (security modes of operation) to actually encrypt and authenticate the information, and pass the security-related information on the wire.

However, all secure datagrams (whether authenticated or encrypted) must ensure that no DPP or Application data is modified on the wire.

Each security mode of operation must define the security fields that are required for each PDU. In order to abstract the security headers that are dependent on different security modes of operation, the following placeholders are defined.

Encryption always begins either in or immediately after the DPP.9: Security Mode of Operation Header Fields. This ensures that all application data is encrypted if required. Encryption always ends at the beginning of DPP.11: Security Mode of Operation Trailer Fields. Finally, the DPP.11: Security Mode of Operation Trailer Fields are always at the end of DPP.10: General DPP Trailer.

This definition means that the process of encrypting and decrypting datagrams can be entirely defined by the following information:

Each version of DPP (exception version 0) must provide the common functionality described in this section. Application protocols may rely on the availability of this information independent of the actual DPP version being used. Version 0 has no common behaviors and no context.

Most of the required functionality deals with managing operations and operation lifecycle, discussed above.

Rather than encapsulate different PDUs in the DPP header space, the application identifier 0x7FFF is reserved for DPP. This does not mean that the implementation needs to be identical for each DPP version, only that the application layer can be leveraged by DPP. This includes the ability to use security.

The following behaviors are required. Specific DPP versions may define additional capabilities, and they would be described in the specific version specification document.

It is important to note that the specifications and behaviors of these behaviors are defined here in a common way. The individual versions of DPP only have control over the specific formatting of the commands and responses that they provide.

As described earlier, there are problems attempting to discover all of the different versions of the different DPS layers that are in use in a network. In order to solve this problem, all nodes are required to understand version 0 in addition to at least one other version.

The use of DPPv0 is described here. It may only be used with a non-zero version for DNP. In other words, once a particular DNP version is known then DPP versions can be queried.

There are two PDUs defined for version 0. The first is a query, and it corresponds to a single byte header. There can be no flags. The second is a response, which is sent some time after the query, and which corresponds to a list of DPP versions supported by the sending node. The format of this PDU is the header byte followed by a number of bytes each representing a version. There must be at least one additional version other than version 0 supported by a node, and so the PDU length (either the one-byte query or the multi-byte response) differentiates between a query and its response.

Responses to multicast queries must be sent within three (3) minutes of a query, but the exact timing should be determined randomly and controlled by other network traffic as described below. Responses to unicast queries should be sent quickly.

Responses to unicast queries are sent unicast.

In the example above, node 2 wants to determine the DPP versions supported by node R2. It sends a unicast DPPv0 Query PDU to R2. Since the PDU is unicast, node R2 immediately responds without any use of timers or delay.

For multicast queries, between the time of the query and the time of the response there are three events that can prevent sending a version in the query response (that consists of a set of versions):

The goal of this logic is to only send information that cannot be determined by watching network traffic. The specific goal of version detection is not to discover nodes on the network, but rather to just discover versions of protocols that are in use.

In the example above, a node Q initiates version discovery by multicasting an DPPv0 Query PDU. This PDU is heard by nodes R2 and R3. Both of these nodes pick random times within the next three minutes and start timers for when they will respond. The timer on R3 expires, and so R3 sends a multicast DPPv0 Query Response. This PDU contains the same version as R2, and so node R2 cancels its timer without sending a response.

If each version in the pending query response is covered by one of these cases then the query response is not sent. Otherwise at least the versions that have not been seen are sent.

For example, assume that a node N speaks version A and B of DPP. It receives a PDU that is an DPP version 0 query. It determines (randomly) that it will send its response in 2 minutes. The response will be a PDU consisting of a zero byte (header), followed by A and B (along with whatever DNP bytes are required).

After some time and before the two minutes pass a PDU is multicast from node N using DPP version A. Sometime later, but still before the two minutes pass, a multicast PDU is received by node N using DPP version B. In this case, the pending response PDU is cancelled.

Assume however that the second PDU is not received. The 2 minutes pass. In this case a response containing at least B is sent.

This protocol exists only to accomplish version discovery on a network. In particular, it cannot be used to encapsulate any other stack layers.

The DPS can be used for both peer-to-peer and client/server protocols. Each application protocol must specify whether it is client/server or peer-to-peer.

The following characteristics apply to peer-to-peer protocols:

The following characteristics apply to client/server protocols:

The APP layer sits on top of the DPP layer.

For each received PDU the APP requires the following context information from the DPP, in addition to the context provided by the DPP, DNP, and Transport:

This section discusses the following negotiation phases, which are included here for reference in the descriptions of the session lifecycles.

The use of these negotiated protocols, including periodic use of the authentication protocol as required, continues until the session is closed.

As discussed in the Transport section, a server may receive datagrams for which no session exists. In fact, all DPS sessions start in this state, even though the transport session exists. In a similar way, each new DPS session acts like it is in this state. However, there are timing restrictions on certain transport sessions that mean that the DPS sessions cannot remain in the 'None' state forever – they must actually establish a session.

Commands that do not require a session always execute in the 'None' session. They are never secure (as security requires a session to maintain state). Another way to refer to this state is 'stateless lossy' or 'stateless datagram'.

The 'None' session is characterized by the following characteristics:

There are two methods that can be used to create a lossy session: DSP Open, and Security Negotiation. Both of these methods follow the same general process:

DSP Open is discussed earlier in this section, and creates unsecured DPS sessions between a lossy client and server. An DNP address is used on the server to identify the session. Note that an unsecure lossy session can be transitioned to a secure lossy session by using an authentication protocol. In this case it is the DPS addresses that define the session rather than a security state identifier.

Sessions can also be created through security negotiation. Authentication protocols that allow this behavior describe how it is accomplished. In this case the same server address is used, and the session is identified by using a security state identifier (SSID).

In the case of sessions opened through security negotiation there is a question of which application protocols may be used. These sessions do not negotiate, but rather use discovery to determine which protocols may be used. In general, the same rules as for negotiated sessions apply, meaning that incompatible protocols may not be used.

In all cases, these sessions are controlled by the client. Peer-to-peer protocols may not be used on the session until either the client sends an application datagram using that protocol or acknowledges to the server that the protocol is acceptable using an DSP Query Response. At that point the particular version of the protocol is determined and the server may respond or generate its own datagrams. The client my initiate a client/server datagram at any time, and its use should remain consistent. If the server desires to use a protocol then it should use the DSP Query to determine what is appropriate. This request may be made directly to the client node of the session. Note that the server already knows the application versions that it advertised in the DSP Open response, and by getting an DSP Query response knows the versions allowed by the client. There exists a potential race condition in the case where the client desires to use an old version of an application protocol. In this case it could respond to the server’s Query including multiple versions, allowing the server to begin speaking with a version of its choice, and the client simultaneously begins using a different version. This is resolved through the intent of the client. If the client desires to use a particular application (including the version) then it should only include that version in its Query response. If it does not care, and in fact is not going to initiate the use of an application protocol, then it can allow the server to choose by returning multiple versions.

Note that it is possible to have lossy 2-node sessions that require security, or allow both, or only allow unsecure. The particular state is determined by the response to the DSP Open that begins the session. See the DSP Open command for more information.

Lifecycle management of lossy 2-node sessions is handled through the DSP or security negotiation protocol, depending on how the session was created.

When lossless sessions are involved, independent of the transport used, full negotiation is required for the initial transport session. The following diagram shows the states that a lossless session passes through before application data can be exchanged. Note that there are two places that sessions can originate, with only the first session after transport session establishment requiring DNP/DPP negotiation:

The different protocols used in the phases shown are discussed in this document or in the different security documents.

Lifecycle management of lossless 2-node sessions is handled through the DSP.

Multiple-node sessions are always created between servers and always assume lossy transports. The sense of an 'established' n-node session is also somewhat different than a 2-node session, as it is possible to have an established 1-node session (no other members).

N-node sessions are always established using a group-management security protocol. They may utilize version discovery, but they do not use any negotiation except for security negotiation (managed by the group-management security protocol).

Since n-node sessions always involve servers communicating with other servers, they require the use of a security state identifier (SSID). Further, since n-node sessions rely on transport capabilities for broadcast or multicast, the use of DNP ports is not possible.

Lifecycle management for N-node sessions is handled differently for multicast vs. unicast. Multicast N-node sessions have no lifecycle management for individual nodes, although the session itself has a lifecycle based on their being any members or not.

Unicast N-node sessions are a hybrid of lossy 2-node session characteristics and group characteristics. It is beneficial in these sessions to better manage node state (closer to lossy 2-node session capabilities). However, the protocols that manage these sessions do not have membership tracking commands. It is typical for lossy 2-node sessions to use traffic received in order to verify the activity of the nodes involved. The DPP Ping and Heartbeat are examples of commands that can be used. Upon joining a unicast N-node session, a node should unicast a Heartbeat command to the hub. This command may be lost (since these are lossy sessions), and so the hub must not rely on its reception. If the hub desires to know the state of a node then a Ping should be sent.

When nodes leave a unicast N-node session they should send an DSP Close/Terminate. The response to this command may be used as an indication that the packet was received. Note that while the session state associated with a node may be cleared using this technique, the security state must not be cleared. To clear the security state could allow replay attacks. Note that normal N-node security modes automatically clear unneeded state over time.

The DSP state machine initializes when the DPS completes DNP and DPP negotiation. DSP must not allow non-responsive sessions to indefinitely keep themselves open. This same requirement applies even when negotiation is not required (as in the case of lossy 2-node sessions).

This command and the responses must be supported. A critical aspect for backward (and forward) compatibility is the ability to determine whether or not a requested configuration is acceptable. Incorrectly acknowledging a configuration without understanding it is a serious (and potentially fatal) error. Shortcuts should not be taken when validating a request or responding to a request.

It is possible that a small implementation has a single, hard-coded outbound Configuration Request command, and if it is rejected then the session will fail.

It is critical that an application correctly respond with acceptable configuration options so that the other node can make adjustments.

Configuration Request() → Configuration Acknowledge(): Success

Configuration Request() → Configuration Negative Acknowledge(): Retry requested

Configuration Request() → Configuration Reject(): Retry requested

Once a transport-level lossless session is established between two nodes, each side must issue a Configuration Request (with the client going first, and the server continuing once the client negotiation is complete). This is done after the DOF Protocol Stack negotiation is completed. The configuration options field is filled with the current desired configuration of the sender.

Upon reception of a Configuration Request, an appropriate reply must be transmitted. The specific reply will be based on whether the request is not understood (Configuration Reject), not acceptable (Configuration Negative Acknowledge) or accepted (Configuration Acknowledge). A single Configuration Acknowledge is allowed from the server and client. Multiple Configuration Reject and Configuration Negative Acknowledge responses are allowed.

For each request and negative acknowledge, the Options field is variable in length, and contains the list of attribute/value pairs that the sender desires to negotiate or respond with. The list of attributes and values are responded to as a group with a single response, although the negotiation continues until a timeout or an acceptable request is made.

A client (meaning the node that requests the session) must send a Configuration Request as soon as possible. A server must wait until it has acknowledged the client configuration before negotiating its own options. In this case the server is not required to negotiate any options, in which case an empty request is sent. This may be done, for example, if the clients request includes everything that the server desires. The server may request additional options. However, the server must not change any options requested by the client, and the client must accept any options requested by the server that the client negotiated.

If every attribute received in a request is recognizable and all values are acceptable, then the implementation must transmit a Configuration Acknowledge. This indicates that the sending node is prepared to begin using the protocols and protocol options specified.

If every instance of the received attributes is recognizable, but some values are not acceptable, then the implementation must transmit either a Configuration Negative Acknowledge or (optionally) a Configuration Reject. In the case of a negative acknowledge, the Options field is filled with information that is based on the unacceptable attributes from the request. All attributes with values that are acceptable are filtered out of the Configuration Negative Acknowledge, but otherwise the attributes from the request must not be reordered.

For each requested attribute/value pair in the request, the negative acknowledge either removes it (if acceptable), or replaces it with a list of attributes that enumerate acceptable values for the attribute. It is possible that the attribute data format can encapsulate these options in a single block, which is acceptable as long as the negotiated meaning is unambiguous (in other words, both the sender and receiver understand the single set of options that are negotiated). The response list associated with a given attribute may contain a single entry, or several.

Finally, after the requested attributes have been responded to as described, the sender may include additional attribute/value pairs at the end of the negative response. These attributes act as 'hints' to the other node to include these options in its next request. Again, these lists may include multiple choices for a given attribute, although the requestor must pick a single acceptable attribute of each to include in its next request. If a suitable choice for each 'hinted' attribute is not appropriate for the sender then it may attempt to continue negotiation without including the attribute. However, if no other changes are made to the request then it is impossible for the response to be accepted. It is also possible that the different attributes listed are not allowed in the same request. In this case the requestor may choose the appropriate options that do not conflict.

For example, a server that requires authentication may understand different options using different attributes. A single negative acknowledge may list several options. However, the request is not allowed to request multiple authentication protocols in the same request and so the requestor must choose one of the suggested options.

If some of the received attributes in a request are not recognizable or are not acceptable for negotiation (as configured by the application), then the implementation must transmit a Configuration Reject. The response includes a list of each Attribute Code field that is not acceptable, along with a list of the associated Attribute Data fields that are acceptable to the sender of the reject.

Optionally, and similarly to the Configuration Negative Acknowledge PDU, the Configuration Reject PDU may contain attributes that were not present in the corresponding request. In this case the reject sender is suggesting to the other node that additional options (using those codes) should be included in the next request.

For example, a server may desire a session to be secure. There are two possible responses to a request that does not include the appropriate options:

Reception of a valid Configuration Reject indicates that a new Configuration Request should be sent that should only include the Attribute Code and Attribute Data that have not been rejected.

Reception of a valid Configuration Negative Acknowledge indicates that a new Configuration Request should be sent with the Options modified to include data that was included in the negative acknowledge.

This command is used only on lossless sessions, and retries are not allowed.

DSP must not be routed.

This first sequence shows the easiest negotiation possible.

In this sequence the client requests a configuration. The server acknowledges, and then begins its request, which is acknowledged.

In this more complicated example only a single negotiation is shown. In step 1 the client issues a configuration request for authentication protocol 1, application protocol 2 with options a and b, and application protocol 4.

In step 2 the server rejects authentication protocol 1 and application protocol 4. The client drops its request for authentication because it doesn’t know any alternate authentication protocols. It also must decide a fallback for protocol 4, and it chooses APPID 3.

The changes to its request can be seen in the request in step 3. The request for application protocol 2 has not changed, but application protocol 3 has replaced the request for 4 and the authentication protocol request is gone.

The server now issues a negative acknowledge in step 4. The response contains a list of all options that would be acceptable. In this case the requested options a and b are not allowed. Again, the client must determine an appropriate fallback. In this case the choices allowed are presented.

In step 5 the client makes its third request. It has chosen application protocol 2 with options a and c (which was a choice in the negative acknowledge).

In step 6 the server acknowledges the choices. The two protocols with the selected options will be used.

This command is completely optional.

Close/Terminate() → response(): Success

DSP includes a Close/Terminate command in order to provide a mechanism for the orderly closing of an established session or the termination of an open session. The security used on the command and response must match that of the established secure session that it is used on.

An implementation wishing to close a session should transmit a Close/Terminate command, and the receiver should respond with a Close/Terminate response.

Upon reception or sending of a Close/Terminate response the session should be closed. This logic allows for previously sent packets to be 'flushed' before the session is terminated. It is typical that the side wishing to close the session has recently sent packets indicating, for example, some error condition. If those packets were sent, followed by a Close/Terminate command, and then immediately the session were closed, there would be a chance that none of the packets will actually be sent before the session is closed. In this case the other side of the session is left without the error information that would inform it of the reason that the session was closed.

Waiting for a Close/Terminate response allows for more certainty that all previously sent packets have actually been received by the other side of the session.

The implementation should not wait indefinitely for the Close/Terminate response, but there is not a specified timeout.