[Sls-slp] Questions about Encapsulation Packet Protocol

Wed Nov 18 17:43:04 UTC 2020

John,
        here may cent waiting whatever additional clarification Greg or 
others may add.

1) Clearly you refer to EOPP and not to SPP. 
Clause  3.2.1.2  can be understood considering Table 4-2.

2) Indeed, a segment header is required to split packets over multiple 
frames. VCP Service has no segment header and therefore can only allow 
blocking (as per Figure 4-14) while MAP Packet Service allows bot blocking 
and segmentation (as per Figure 4-9).

TM and AOS have a first header pointer - in Frame Header and M_PDU 
respectively - and this allows "packets spanning over several frames"

A first header pointer is available also in USLP (see clause 4.1.4.2.2.2.1 
for TFDZ  Construction  Rule  ‘000’  indicating  a  fixed-length  TFDZ). 
[you do not mention this in your item #2.]
Conversely, USLPTFDZ  Construction  Rules  ‘100’, ‘101’, and ‘110’ 
(indicating a variable-length TFDZ) can be used "a la TC' for "packets 
spanning over several frames" 

3) I cannot say whether it was "intention of the SLPWG that the 
multiplexing of Encap packets been done on a FIFO basis". I would simply 
guess that nobody thought to require a multiplexing there :o)
In other words, I think there is nothing preventing an EPP implementation 
to implement a Multiplexing Scheme. I guess that if an agency has this 
need, SLP WG could discuss such input.
Despite limitation to FIFO looks to me very reasonable for Functional 
Resources, I think that absence of a precise statement leaves freedom.

4) we shall pass this to Tom Gannett.

Greg and others are welcome to complement my opinion.

Regards

Gian Paolo

From:   "John Pietras" <john.pietras at gst.com>
To:     "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Cc:     "Wolfgang Hell" <wo_._he at t-online.de>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>
Date:   18-11-20 17:29
Subject:        [Sls-slp] Questions about Encapsulation Packet Protocol
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>

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
 _______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

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