Space Link Extension - Service Management - CCSDS

DRAFT RECOMMENDED STANDARD FOR SPACE LINK EXTENSION SERVICE MANAGEMENT
NOTE 1 – As described in 3.2, the SLE-SM document exchange protocol relies on the
underlying communication service to authenticate the identity of the Source of the
message carried by the SLE-SM document exchange protocol, and to supply the
identity of the Source of the message to the SLE-SM document exchange protocol.
NOTE 2 – Because the format of the identification of the Source used by the underlying
communication service is technology dependent, the mapping between that
identification and the sleSmCreatorName is also technology dependent.
Sequencing of invocation messages within the message set. If a message set contains
invocation messages, the messageSequenceNumber (see table 3-5) parameter of each of
the contained invocations must (a) be unique within the message set, and (b) must have a
value greater than the messageSequenceNumber of the last valid invocation message
received prior to the message set, within the context of the same sleSmCreatorName and
serviceAgreementRef. If the Receiver is unable to validate the sequencing of any
invocation message in the message set, the Receiver shall send an InvalidMessage-
Response exception response to the exception response port of the Sender with appropriate
diagnostic information (as specified in table 3-24), after which the Receiver has no further
responsibility for interpreting and acting upon the invalidly sequenced message.
NOTE 3 – The Receiver does not perform message sequence number checking for any type
of message other than invocations.
Verification of support for the invoked operation. Because different implementations of the
SLE-SM Recommended Standard may support different subsets of the SLE-SM set of
operations (see annex B, Incremental Adoption Approach), the Receiver must validate that
the operation associated with each message is supported by the SLE-SM entity associated
with the Receiver. If the Receiver does not support the operation invocation or notification
type of a received message, the Receiver shall send one InvalidMessageResponse
exception response to the exception response port of the Sender for each unsupportedoperation
invocation or notification message, respectively, and has no further responsibility
for interpreting and acting upon the unsupported-operation message. If the Receiver does not
support the operation return or confirmation type of any received message, the Receiver shall
ignore the unsupported-operation return or confirmation message and has no further
responsibility for interpreting and acting upon the unsupported-type message.
NOTE 4 – An operation return or confirmation can only be legitimately sent in response to
an invocation or notification (respectively), so that if a Receiver receives a return
or confirmation that it could not have possibly sent because it is for an operation
that the Receiver does not support, it is an indication of a serious protocol
breakdown. In such cases the association between the Receiver and the Sender is
completely unreliable and should not be used even to transmit an
InvalidMessageResponse.
Message processing external to the document exchange protocol. The Receiver shall provide
all messages that pass syntactic, authentication, invocation sequencing (as appropriate), and
CCSDS 910.11-R-2 Page 3-7 March 2008