[Sls-slp] RE: Encapsulation Service
Durst, Robert C.
durst at mitre.org
Wed Apr 19 20:08:58 UTC 2006
>> >>In section 2.2, it is unclear what the conformance requirements
>> >>are. There are two protocols (Space Packet and
>> >>under a single service interface. Are both required for
>> >**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
>> >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
>>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
>> >>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
>** I will add it to the Space Link Identifiers book **
>> >** 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
>>than informative, but it would be nice to have this explained
>** OK, I will see if I can weave these explanation in without
>being wordy **
>> >>Section 4.1, item b) the APID "shall be one of the reserved
>> >>defined in reference . 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 , 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
>> >>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
>> >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
>>Could you please clarify these points in the document?
>** OK **
>>I think that it would be useful to summarize the "managed parameters"
>>somewhere, to make it clear specifically what bilateral
>>required to ensure interoperability. This may be part of the "lore"
>>within the CCSDS community, but if we want other folks to use
>>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...
More information about the SLS-SLP