3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of a possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol performs. This document does not mandate that the implementations adhere to this model as long as their external behavior is consistent with that described in this document.

Note For the sake of clarity, the term "local partner" is used to indicate the role that is being described, and the term "remote partner" is used to indicate the partner with which the local partner is communicating.

An implementation of this protocol uses the following data elements, as specified in [MS-CMPO] section 3.2.1.1:

  • Local Name Object

  • Minimum Level 2 Version Number

  • Maximum Level 2 Version Number

  • Minimum Level 3 Version Number

  • Maximum Level 3 Version Number

  • Security Level

An implementation of this protocol MUST maintain the following data elements:

  • Session Table: A table of Session objects that is maintained by a transports protocol partner as specified in [MS-CMPO] section 3.2.1.2. This protocol does not maintain a Session Table itself, but the Session object MUST be extended to support the following additional data elements:

    • Outgoing Connection Table: A table of Connection objects in use that are initiated by the local partner and indexed by the Connection ID field of the Connection object.

    • Count of Allocated Outgoing Connections: An unsigned 32-bit integer counting the number of outgoing connections that have been allocated for the local partner in the session. Partners in this protocol use their respective underlying transports protocol instances to negotiate a number of pre-allocated Connection objects that each connection requires. More connections are allocated by this instance when it is discovered that the number of entries in the Outgoing Connection Table equals the current value of the Count of Allocated Outgoing Connections. To create a new connection, there MUST be at least one allocated outgoing connection available. Outgoing connections are allocated, and the corresponding count increased, by requesting the local partner to allocate more connection resources through the underlying transports protocol instance.

    • Incoming Connection Table: A table of Connection objects in use that are initiated by the remote partner and indexed by the Connection ID field of the Connection object.

    • Count of Allocated Incoming Connections: An unsigned 32-bit integer counting the number of incoming connections that have been allocated by the remote partner in the session. Partners in this protocol use their respective underlying transports protocol instances to negotiate a number of pre-allocated Connection objects that each connection requires. The number of allocated incoming connections is the value requested by the remote partner. New connections are allowed to be created until the number of entries in the Incoming Connection Table equals the count requested by the remote partner. If the remote partner requires more connections to be created, it MUST request that more be allocated, causing this count to be increased.

    • Boxcar Queue: An ordered queue of Boxcar objects to be transmitted on this session.

The management of these additional data elements is the responsibility of this protocol implementation as outlined in sections 3.1.4.2, 3.1.5.1, 3.1.5.5, and 3.1.7.3.

Note It is possible to implement the conceptual data by using a variety of techniques. An implementation is at liberty to implement such data in any way it pleases.