Discussions Issues for the Production of the SLE-SM Red-2 book

 

The following points summarize the discussion of the 25 July 2007 SMWG telecon regarding the draft Add Space Link Session Profile (ASLSP) state diagram that Anthony had distributed earlier that day. If I have missed any points, or have misreperesented any of the issues and/or the discussion related to them, please register the corrections as replies to this message.

As I tried to summarize the discussion, I performed some post-telecon analysis in my head, which I’ve also documented below. I have tried to make clear the separation between what was discussed during the telecon and my thoughts afterwards.

1. Sil suggested separate states exist before and after the ASLSP-AR is sent. The subsequent discussion brought up the point made in the June meeting that prior to the issuance of the AR, the message set is undergoing message set validation. Until the message set is validated, CM doesn’t even “know” about the SLSP being requested to be added, so the SLSP doesn’t yet have a state.

2. What looked like an apparent disparity in the approach outlined in (1) above was noted for the comment attached to the DSLSP-FR loop, which states that the DSLSP fails if the SleSmCreatorName does not match that of the referenced SpaceLinkSessionProfile. Why is checking the SleSmCreatorName a “pre-state” activity for the initial addition of the SLSP, but something that is checked when that SLSP is to be deleted? We left the telcon without resolving this issue.

After the telecon, I (John) had a chance to think about it more and to check the SLE-SM service spec. There is a difference between the two that justifies the apparently-different behavior. In the message set validation that happens prior to the acknowledgement of the ASLSP-I, the SleSmCreatorName is checked to see if it can be authenticated with respect to the source, and if it is valid in the context of the referenced Service Agreement. Faliure at this level results in Exception Response being returned to UM. The same checks are performed as part of message set validation DSLSP-I (and QSLSP-I, for that matter), and this level of validation is similarly absent from the ASLSP state diagram. The SleSmCreatorName-related validation that is called out in the comment box is part of service management validation, which is above the level of message set validation.

3. As the telecon was nearing its end, I raised a question about the QSLSP loops out of the Unreferenced and Referenced states - why do they only succeed, and what happens when a QSLSP fails? Erik rightfully pointed out that the only way for a QSLSP-I to fail (other than a timeout, which should never happen) is for the spaceLinkSessionProfileId to be unknown (in the context of the Service Agreement), in which case the QSLSP-I certainly can’t pertain to the SLSP, so it is invisible from the state of the SLSP.

As I thought more about it after the telecon, I became concerned that here was a failure condition that wasn’t message set validation but rather service management validation, yet it was still “invisible” from the perspective of a given SLSP. I then realized (or, more correctly, remembered) that service management validation itself has two steps. The first step deals with what I will call (for the lack of a better, more terse name) binding of the invocation to an information entity. For the ASLSP, the binding is successful when a new, currently-unused-by-another-SLSP spaceLinkSessionProfileId is provided in the ASLSP-I. For the DSLSP (and QSLSP), the binding is successful when the spaceLinkSessionProfileRef in the DSLSP-I (or QSLSP-I) names a currently-used spaceLinkSessionProfileId.

In the second step - once the invocation is bound to an information entity - the rest of service managment validation can be performed (such as conformance with the ranges on parameter values in the Service Agreement). Failure to bind the invocation to an information entity and failure to meet any of the other service management validation criteria all result in the issuance of an FR, but if the binding fails, no SLSP’s state is affected and therefore these attempted operations are invisible to the state of a SLSP.

We don’t make the distinction between these two steps in service management validation, and in general I don’t think that we need to. But it has made me realize that in the case of the CSP operation, it could lead to unwanted (or at least unexpected) outcomes with respect to how we have currently defied that operation. Here’s the scenario:
UM invokes CSP using a servicePackageId that is already being used; otherwise the CSP-I is fine. The CSP-I is acknowledged (since the validation of the uniqueness of the servicePackageId is service management validation). Before the expected disposition time of the CSP operation, UM invokes the DSP to delete what it thinks is only that enqueued CSP. The DSP-I not only causes the enqueued CSP to fail, it also causes the existing SP with that servicePackageId to be deleted.

Now I think the practical response to this scenario is that if any UM is messed up enough to be redundantly using servicePackageIds, accidentially deleting an existing SP is one of their lesser worries. But I thought I’d point it out. If we wanted to “fix” this problem, we would have to perform the information entity binding validation into the validation that is performed before the AR is issued, which would ential going through all of the UM, CM, and Data Set Composition and Relationship requirements to separate them out. If anyone thinks that we should worry about this more now, please raise the concern. Otherwise, I suggest that we move on.

4. Sil raised the issue of whether we wanted to be able to delete an ASLSP-I any time after it has been acknowledged, in the same way as we have adopted for the CSP and RSP. We recollected discussing this possibility at the June meeting and the decision made then that being able to delete a CSP or RSP is a special case because it involves the allocation and deallocation of scarce resources (e.g., antennas). Sil responded that if an analyst needs to review the new profile before accepting it, that could justify the pre-emptive deletion. However, in the end we agreed that for Red-2 we would not include it, but that Sil will post a possible RID for Red-2 on the CWE discussion page.

5. During the telecon, I noted that two ways of representing decisions are used in the diagram: the first is the separate decision icon (“acceptable”), the second is two guard conditions emanating from the same state (“DSLSP-I [valid]” and “DSLSP-I [not valid]”). I think that one or the other should be used, and there was a general consensus that the two guards approach was preferrable. Regarding the wording of the guard, “acceptable” is not quite right as the guard condition. It is more than acceptable, the operation has in fact been performed. I suggest that the guard conditions be “[profile added]” for the SR branch and “[profile not added]” for the FR branch.