[Sls-slp] Questions about Encapsulation Packet Protocol

[John Pietras]

SLPWG colleagues ---
As you may be aware, the Cross Support Services Area is developing a Functional Resource Model (FRM) that defines the functional resources that abstractly represent the various functions performed by Earth Space Link Terminals (i.e., ground stations). The purpose of these functional resources is facilitate the definition of configuration profiles (used in scheduling) and to support the monitoring and control of the physical resources that are represented by those functional resources in cross support situations. (For those of you familiar with the concept of a Management Information Base (MIB) in the context of network management protocols such as TCP/IP's Simple Network Management Protocol (SNMP) or the ISO/OSI Common Management Information Protocol (CMIP), the FRM is essentially the "MIB" for space data systems.)

We are in the process of completing the definitions of the functional resources that correspond to the CCSDS space data link protocol functions: TC SDLP, TM SDLP, AOS SDLP, USLP, Space Packet Protocol (SPP), and Encapsulation Packet Protocol (EPP). In exploring the interactions among the Encapsulation Function defined in the EPP and the various underlying SDLPs, we have developed a question and several interpretations that I am now posing to you for comment:

1.      Section 3.2.1.2 of the SPP (CCSDS 133.1-B-1) specifies that "the maximum length of a data unit that can be accommodated in an encapsulating packet is 4,294,967,287 octets for the Encapsulation Packet." Is this just the consequence of that being the size supported by the 4-octet PACKET LENGTH field (LENGTH OF LENGTHS = '11'), or are there identified operational use cases for this large a packet?


2.      Section 3.2.2.2 confirms that Encap Packets can be transferred via the Virtual Channel Packet (VCP) service of the TM, TC, and AOD SDLPs, and via the MAP Packet (MAPP) service of TC SDLP and USLP. We make the observation that the only time that the underlying SDLP constrains the size of the Encap packet is when the underlying service is the TC VCP service, where the maximum size of data unit carried by the Encap Packet is constrained to be 1015 octets. For the other SDLP services:

a.      When Encapsulation Packets are transferred via the TC MAPP and USLP MAPP services, segmentation is used to break large Encap Packets in order to fit into TC/USLP transfer frames.

b.      When Encapsulation Packets are transferred via the TM VCP and AOS VCP services, the respective Packet Processing functions break up the encap packets as necessary to fit them into M_PDUs.
If we have misinterpreted anything here please let us know.


3.      The Encapsulation Function performs a multiplexing function by forming Encap packets from data units from different "protocol users", and multiplexing those packets into a single stream of Encap packets for the underlying Packet service. We observe that, unlike other CCSDS SDLP functions that perform multiplexing (Space Packets, Packets, VC Frames, and MC Frames), there is no mention in the EPP Blue Book of multiplexing priority. We interpret that as the intention of the SLPWG that the multiplexing of Encap packets been done on a FIFO basis. We concur with this approach, as we can see no practical reason for other multiplexing schemes, and we plan to define this aspect of the corresponding functional resource to be FIFO only.


4.      Finally, here's an editorial error that should be fixed in the next editorial-level update of the EPP Blue Book: although the title of the book was changed from Encapsulation Service to Encapsulation Packet Protocol, the heading on each page in B-3still reads "CCSDS RECOMMENDED STANDARD FOR ENCAPSULATION SERVICE".

Thanks in advance for any comments that you may have.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201118/970dea0b/attachment.htm>