[Sls-slp] RE: Encapsulation Service

[Durst, Robert C.]

 >> >>In section 2.2, it is unclear what the conformance requirements
>> >>are.  There are two protocols (Space Packet and
>Encapsulation Packet)
>> >>under a single service interface.  Are both required for
>conformance?
>> >
>> >**Both protocols can be used to encapsulate other protocols.
>> >For example,
>> >CFDP can be encapsulated into space packets by using APID=2045
>> >or into an
>> >Encapsulation packet by using PID = '110'. I need to know more
>> >about what
>> >you are expecting in terms of "conformance requirements". The
>> >encapsulation
>> >service specifies the inputs, what protocols are used to do the
>> >encapsulating, and references the Space Link Identifiers
>> >document, which
>> >supplies all of the IDs one needs in order to carry out the
>service.**
>>
>>The conformance requirements I am asking about are whether an
>>implementation is "conformant" if it only implements one of these
>>two protocols (SPP or Encapsulation Packet).  If so, please say so.
>>If not, please explain how you ensure interoperability between two
>>conformant applications that invoke this service (when, for example,
>>one is hosted on a node that implements SPP and the other is hosted
>>on a node that implements only Encapsulation).
>
>
>** An implementation is conformant if it only implements one
>of these two
>protocols. I will modify the document to say this explicitly. **

While this is probably the pragmatic approach, the implication of this
is that two implementors can provide the same CCSDS service in a way
that is not, and cannot be configured to be, interoperable.  I find
this disturbing.  This possibility at least  needs to be noted, and
added to the list of parameters that are managed among implementors.
This seems like a rather serious flaw to me.  I would much rather see a
requirement to implement both and an option to use either on a
per-mission basis.  Failing that, I'd like to see a Protocol
Implementation Conformance Statement developed and made mandatory, so
that there is no ambiguity about what an implementor has implemented.

>> >>The document requires a SANA Implications section to address
>> >registered
>> >>APIDs and PIDs, and to define procedures to register new
>> >APIDs and PIDs.
>> >
>> >** All of the IDs used by the Encapsulation Service are
>defined in the
>> >Space Link Identifiers spec. This is true for all of the link layer
>> >protocols. Therefore, it is the Space Link Identifiers book
>> >that requires a
>> >SANA implication section, not Encap. service.  APIDs and PIDs
>> >are defined
>> >in the Space Link Identifiers book which is referenced in
>> >section 2.3 **
>>
>>OK.  Does the Space Link Identifiers book have such a section?  My
>>comment will be successfully resolved if either of these
>documents has a
>>SANA section.
>
>** I will add it to the Space Link Identifiers book **

OK, thanks.

>> >
>> >** GVCID = SCID + VCID. SCID is statically assigned. VCID is
>> >an enterprise
>> >or project managed parameter. CCSDS recognizes certain PVNs.
>> >All of these
>> >IDs are defined and their values are listed (if not a managed
>> >parameter) in
>> >the Space Link Identifiers spec. For things like PVN it's very
>> >static. For
>> >APIDs, an enterprise has to really manage these across the
>> >enterprise in
>> >order for interoperability to happen. Global enterprise
>APIDs begin to
>> >happen in these cases. **
>>
>>This explanation is helpful.  I know that the book is
>normative, rather
>>than informative, but it would be nice to have this explained
>in there.
>
>
>** OK, I will see if I can weave these explanation in without
>being wordy **

Thanks.


>> >>Section 4.1, item b)  the APID "shall be one of the reserved
APIDs"
>> >>defined in reference [8].  Are there guidelines or further
>> >restrictions on
>> >>how a particular APID is chosen?  Does interoperability
>> >depend on this
>> >>choice?  In Table 5-2 of reference [8], there appear to be
>> >two degrees of
>> >>"reserved" -- reserved and assigned to a particular protocol,
>> >and reserved
>> >>but unassigned.  Are any of these fair game?  Or was it
>intended that
>> >>these be drawn from the 2040-2044 range?
>> >
>> >** Again APIDs are a managed parameter by an enterprise except
>> >for the ones
>> >defined in the CCSDS Space Link Identifiers book. There are
>no further
>> >restrictions except the ones managed by the enterprise. Yes,
>> >interoperability is an issue for the management of those
>apids. It is
>> >intended that 2040-2044 be used for encapsulation by space
>packets. **
>>
>>Could you please clarify these points in the document?
>
>** OK **

Thanks.

>>I think that it would be useful to summarize the "managed parameters"
>>somewhere, to make it clear specifically what bilateral
>agreements are
>>required to ensure interoperability.  This may be part of the "lore"
>>within the CCSDS community, but if we want other folks to use
>this, making
>>it clear what needs to be agreed upon out-of-band seems important.

Didn't see any comment on this (but then, my comment didn't require
any).  Any thoughts on an annex to summarize these?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20060419/d548b815/attachment.html>