[Css-dts] Significance of the functional group component of the Service instance Identifier

[John Pietras]

Wolfgang,
Thanks for the response. I think a discussion in Athens would be a good
idea. We'll see you there.

Best regards,
John

> -----Original Message-----
> From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
> Sent: Saturday, March 12, 2005 2:46 AM
> To: John Pietras
> Cc: css-dts at mailman.ccsds.org; css-dts-bounces at mailman.ccsds.org;
CCSDS
> Service Mgmt WG
> Subject: Re: [Css-dts] Significance of the functional group component
of
> the Service instance Identifier
> 
> 
> John,
> 
> While I'm writing this, I'm on travel and do not have the chance at
this
> very
> moment to check what is really contained in the CLTU Book. But I take
your
> word for it and CSTS / DTS at the spring meeting in that case may want
to
> generate one further Pink Sheet, as the example SII clearly refers to
an
> RAF
> SI. But that is just a side remark.
> 
> As regards the functional groups, so far they are not used in any
> systematic
> manner. That is actually true for the complete SII, where from an
> application
> point of view the only thing that matters is that the SII on the user
and
> provider side match. The actual selection of the provider, i.e.. the
> physical
> entity that is supposed to provide the service, happens by putting the
> correct value of responder ID and responder port ID in the SI. I
> personally
> would think that also from an operational point of view it would be
good
> to
> really link the SII field values, among others the functional group,
to
> the
> values in responder ID and responder port ID. In this way, by looking
at
> the
> SII one can figure out for which context the given SI was created. As
far
> as
> I can see, we could apply such scheme without affecting the existing
> implementations, as we only specify conventions in terms of SII field
> values
> and other SI parameters. The exception is probably our SICM tool that
we
> use
> today to generate SIs from network schedules and mission profiles.
> 
> I don't know how urgently we need to come to a conclusion on this
matter,
> but
> I would certainly be happy to discuss this to further level of detail
at
> the
> Athens meeting.
> 
> Best regards,
> 
> Wolfgang
> 
> 
> 
> 
> 
>                       John Pietras
>                       <john.pietras at gst.com>         To:      css-
> dts at mailman.ccsds.org
>                       Sent by:                       cc:      CCSDS
> Service Mgmt WG <smwg at mailman.ccsds.org>
>                       css-dts-bounces at mailma         Subject:
[Css-dts]
> Significance of the functional group component of the
>                       n.ccsds.org                    Service instance
> Identifier
> 
> 
>                       11/03/2005 22:56
> 
> 
> 
> 
> 
> 
> Members of the DTSWG,
> I have recently "rediscovered" that the Service Instance Identifier
for
> SLE transfer services has a Forward/Return Service Functional Group
> component which appears to name a specific instance of a forward space
> link functional group (fsl-fg) or return space link-functional group
> (rsl-fg). The example from the FCLTU Blue (2) Book is
> 'sagr=xyz.spack=abcdef.rsl-fg=gfjdy.raf=onlc2'. The SLE transfer
service
> specifications further states that "the value of [the Forward/Return
> Service Functional Group] is to be agreed between the user and the
> provider."
> 
> Is this FG just a logical identifier that is included in the service
> instance ID, or is the intention that there will be some physical or
> logical entities associated with these FG names that must somehow be
> configured to support the production or provision of the service
> instance? Currently, SLE-SM does not recognize functional groups. I
> would like to understand the intention behind this FG name so that we
> can assess what (if any) changes are required in SLE-SM.
> 
> I apologize for not thinking of the ramifications of this FG component
> when this shortened identifier convention was first proposed (and then
> subsequently adopted).
> 
> Thank you for your consideration of this topic. I look forward to
seeing
> many of you in Athens (a mere month from today!)
> 
> Best regards,
> John
> 
> 
> _______________________________________________
> CSS-dts mailing list
> CSS-dts at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/css-dts
> 
> 
> 
>