[CESG] RE: Proposed Technical Corrigendum to Encap Service 133.1-B-2

[Hooke, Adrian J (9000)]

The London agreement was that we only have to test IP-over-Encap.

Encap has to be (separately and independently) interoperability tested over TM, TC, AOS and Prox-1 and we know that there are deficiencies there; but we have an agreed way-forward to document the testing issues in the Encap spec. and then progressively work them off as resources become available.

In this case, IP is directly implementable and Encap is directly implementable. With the deprecation of the term "Application Profile",  IP-over-CCSDS should be CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization).

///a

From: Shames, Peter M (313B)
Sent: Thursday, April 14, 2011 12:29 PM
To: Gian.Paolo.Calzolari at esa.int; Hooke, Adrian J (9000)
Cc: Chris Taylor; Kazz, Greg J (313B); Keith Scott; Tom Gannett; Gilles Moury
Subject: Re: Proposed Technical Corrigendum to Encap Service 133.1-B-2

Gippo,

I do not know what "agreement" you are referencing, but the requirements on how we operate are documented in the CCSDS Procedures.  In the current CCSDS Procedures document all Blue Books need to be interoperability tested and one class of Magenta Books, Application Profiles, also need to be interoperability tested.    IP Over CSDS is an instance of an Application profile, thus it needs to be interoperability tested.  ENCAP is a Blue Book, thus it too needs to have all of its options interoperability tested, even if the implementation is just a few lines of code.

If and when we decide to change the CCSDS policy to make Application Profiles Blue Books, which we have discussed but not decided upon, then these will still need to have interoperability testing done, as Blue Books.  In effect nothing will have changed except the "color" of the books.  This class of documents will effectively need to have the same content in either case.

The issues that was raised, as I understand it, was how to handle the fact that the ENCAP did not have complete interoperability testing done prior to publication.  In this regard we all, collectively, screwed up.  The "fix" that was proposed was to waive the requirement for now, and document this in the spec, thus preventing the complete removal of the spec from the current standards track, but to require that interop testing be done as soon as possible.

The other issue was just how far down the stack testing needed to be done.  I believe that in all cases the agreement is that testing needs to only be done down to the top of the underlying "protocol service providing layer" that sits underneath the protocol or stack of protocols that are being specified.  In practice that would mean that ENCAP would need to be tested over any protocol that it is to be used with: TC, TM, AOS, and Prox-1.  There is no requirement to test all layers below this underlying "protocol service providing layer".  The same practice would apply at any layer, particularly where a stack of protocols, I.e. Application Profile, is being specified.

Where things get a little interesting is between layers like the Coding and Sync sub-layer of the link layer, and the Modulation sub-layer of the physical layer.   The interfaces between link layer protocols and coding protocols become complicated since there is the possibility of having block coding synchronous with link layer blocks, or asynchronous with regard  link layer blocks.  How this is to work must be specified.  Similarly the interface between the coding sub-layer and the modulation sub-layer must be carefully defined.  It is not clear that there is a need to test a new coding spec with each and every modulation spec (a large task indeed), but if we choose not to do that we will need to analyze it and carefully document why that is not required.

Regards, Peter




From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Thu, 14 Apr 2011 08:44:30 -0700
To: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov<mailto:Adrian.J.Hooke at jpl.nasa.gov>>
Cc: Chris Taylor <Chris.Taylor at esa.int<mailto:Chris.Taylor at esa.int>>, Greg Kazz <Greg.J.Kazz at jpl.nasa.gov<mailto:Greg.J.Kazz at jpl.nasa.gov>>, Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Tom Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Subject: RE: Proposed Technical Corrigendum to Encap Service 133.1-B-2


Adrian,
        one statement in the slides you sent me (i.e. interoperability testing for Magenta Book) is in conflict with the latest agreement (Blue needs prototype, Magenta needs no prototype).
This is confirming an opinion I have expressed several times; i.e. IP over CCSDS should be a blue book since it is defining a new service.
As such, IP over CCSDS would need prototyping while the Encapsulation service would stay as is considering also that the packet extraction only based on recognizing a packet version and a legth can be with few lines of software.

Ciao

Gian Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110414/eb9fb216/attachment-0001.htm