[Sls-slp] RE: Encapsulation Service

[Greg Kazz]

Bob,

My comments in ** ** below.

thanks,

Greg

At 07:28 AM 4/19/2006, Durst, Robert C. wrote:

>
>
>Greg et al,
>
>Apologies for the late response.  Here are my thoughts on this:
>
> >>APPROVE WITH CONDITIONS:  1 (33.33%) (Durst)
> >>
> >>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. **


> >>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 **



> >>The document requires a security implications section.
> >
> >** I will work with Howie on how to accomplish this **
>
>OK.  When added, this comment will be resolved.
>
> >>Section 3.3.2.2:  It is unclear to me whether and how a user of the
> >>service is expected to know the correct GVCID and PVN to use.
> > Are these
> >>statically assigned?  Assigned on a per-mission basis?  What are the
> >>implications on interoperability?
> >
> >** 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 **


> >>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 **


>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.
>
> >>Section 4.2.2.1, item g -- this is a poorly worded summary of section
> >>4.2.2.8.  Recommend rewording to "Packet Length (0, 1, 2, or
> >4 octets) --
> >>See Figure 4-2.
> >
> >** Agreed. It will be changed to Packet Length (0, 1, 2, or 4
> >octets). **
>
>Thanks.
>
> >>Section 4.2.2.3 -- "The value '110'..." does this require a
> >RID against
> >>135.0-B-2 (or whatever)?
> >
> >** The PID value '110" needs to be added to Space Link
> >Identifiers blue
> >book via a new pink sheet **
>
>OK, thanks.
>
> >>Section 4.2.2.6 -- "The extended protocol IDs..."  I didn't
> >see this in
> >>reference [8].  Does it require a RID?
> >
> >** A new table called "Extended Protocol IDs" needs to be added to the
> >Space Link Identifiers blue book via the new pink sheet. **
>
>OK.
>
> >>As a note to the secretariat, I'd suggest that we add an
> >Annex for red
> >>books that require modifications to other documents that consolidates
> >>and  summarizes those external dependencies. ** I agree **
>
>Perhaps also another annex that summarizes the "managed parameters" that 
>the protocol specifies that must be agreed among peers in order to ensure 
>interoperability?

** OK, I will list the documents that Encapsulation Service affects and 
which parts (tables etc) are affected  i.e., when a change is made. **


>Thanks, and again, sorry for the delay.
>
>Bob