GVCID parameter for Encapsulation - V2 - Oct2009 Encapsulation Service: Specifying the channel in the underlying Space Data Link Protocol Version 2/3 (Last 2 slides added by Greg Kazz) October 2009 Marjorie de Lande Long (Version 1 slides were discussed at CCSDS Fall Meeting Berlin 2008) (Cover slide has been added, and changes to the Prox-1 items on the last two slides)

GVCID parameter for Encapsulation - V2 - Oct2009 Encapsulation Service: Specifying the channel in the underlying Space Data Link Protocol The IP-over-CCSDS Red Book uses the Encapsulation Service as the preferred means for transferring IP datagrams. The Red Book has discussion of the channels (Virtual Channels, MAPs, Port IDs) in the services of the underlying Space Data Link Protocol. Propose that it would be helpful to make a small change to the specification of the service primitives of the Encapsulation Service.

GVCID parameter for Encapsulation - V2 - Oct2009 Encapsulation Service: GVCID parameter The primitives of the Encapsulation Service have a parameter GVCID It is intended to identify the Virtual Channel of the underlying Space Data Link Protocol that transfers the data for the Encapsulation Service: –For the VCP services of TM, TC or AOS, the GVCID is sufficient –For the MAPP service of TC, it does not include the MAP Identifier –For Prox-1, PCIDs and Port IDs (?) are used instead of Virtual Channel IDs

GVCID parameter for Encapsulation – V3 - Oct2009 (red comment by Greg Kazz) Proposed SDLP_Channel parameter Propose that Encapsulation Service primitives have SDLP_Channel parameter instead of GVCID parameter It could be called the “Space Data Link Protocol Channel Identification” The contents of the SDLP_Channel parameter would depend on the underlying service: –for VCP services of TM, TC or AOS: GVCID –for MAPP service of TC: GVCID and MAP ID –for Prox-1: TFVN, SCID, Port ID, PCID, DFC_ID

Prox-1 Parameter Setup Operability Issue How does one set up the parameters for Prox-1 to transfer data across the link? Currently for the Prox-1 over flight of the orbiter, these parameters are set up by management: TFVN, SCID, Physical Channel ID, DFC_ID (type of data sent i.e., packet, segment, user defined) and the Port ID. The question is, are any of these parameters dynamic on the sending side? (The receive side is not an issue because the parameters are available to it.) Currently, these parameters have been static and this set up has been dealt with by management. GVCID parameter for Encapsulation – V3 - Oct2009

Prox-1 Setup Continued For example, today Prox-1 does not have a mechanism to deal with dynamic port id assignments on the sending side. On the receive side, this is no problem. Is this an issue? So a file of packets that contain multiple APIDs that need to be output over different ports is currently not allowed in the specification. One key ops concept is the ability to specify data for the orbiter for internal Mars environment consumption vs data intended for Earth. –Port ID could be one means of achieving this needed addressing capability. GVCID parameter for Encapsulation – V3 - Oct2009