[Sls-slp] RE: Encapsulation Service
greg.j.kazz at jpl.nasa.gov
Wed Apr 19 18:22:18 UTC 2006
My comments in ** ** below.
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
> >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
> >>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 **
> >>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 188.8.131.52: 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 . 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 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 184.108.40.206, item g -- this is a poorly worded summary of section
> >>220.127.116.11. 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). **
> >>Section 18.104.22.168 -- "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 **
> >>Section 22.214.171.124 -- "The extended protocol IDs..." I didn't
> >see this in
> >>reference . 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. **
> >>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
** 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.
More information about the SLS-SLP