[Robustness] GenericData (was:Minutes of the 7/20 call)
Pete Cordell
pete at TECH-KNOW-WARE.COM
Mon Jul 31 12:41:46 EDT 2000
Terry,
I haven't tracked the robustness work, so these comments might be slightly
off beam.
But from a genericData point of view, please see my comments below...
----- Original Message -----
From: Terry L Anderson <tla at LUCENT.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 28 July 2000 18:51
Subject: Re: [Robustness] GenericData (was:Minutes of the 7/20 call)
> Ok, Rich. You've convinced me. Let's see how we would do this
GenericData.
>
> We had the following fields:
> supportsRobustnessProcedures NULL OPTIONAL (RRQ, RCF, Setup,
Connect)
>
> backupCallSignalAddress SEQUENCE OF BackupCallSignalAddress (or
> recoveryCallSignalPoint) (Setup, Connect)
> which is: a SEQENCE OF TransportAddress
We are hoping to add TransportAddress as a data type in content. Een if we
are not successful in that, an IPv4 address is fairly easy to represent in
OCTET STRINGs etc.
>
> hasSharedRepository NULL OPTIONAL (or hasFaultTolerantRepository)
(Setup,
> Connect)
>
> Then we added Status-UUIE and StatusInquiry-UUIE with:
>
> protocolIdentifier ProtocolIdentifier (Status, StatusInquiry)
> callIdentifier OPTIONAL (Status, StatusInquiry)
> fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status)
> includeFastStart BOOLEAN (StatusInquiry)
> h245Address TransportAddress OPTIONAL (Status)
>
> Let's see if I understand the right way to use the GenericData stuff (Rich
or
> others correct me if I have misunderstood).
>
> I believe that we can get the equivalent of "supportsRobustnessProcedures"
by the
> existence of the GenericData field with our Id. It can be empty in RRQ
and RCF
> where nothing but the NULL OPTIONAL was used and can contain the other
necessary
> fields in Setup and Connect.
>
> I don't think we need protocolIdentifier. It was just added because all
UUIE's
> have it. Using GenericData we will avoid adding UUIEs for Status and
> StatusInquiry (note that GenericData is not in the UUIE but in the
H323-UU-PDU
> and so available for messages without a UUIE.
If we add ASN.1 for the status and status-enguiry messages, it seems
reasonable to give them a basic definition that is compatible with the other
messages. i.e. they could easily contain:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry)
callIdentifier OPTIONAL (Status, StatusInquiry)
fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status)
and maybe:
h245Address TransportAddress OPTIONAL (Status)
I'm not sure what the following is intended to do, so can't comment on that.
Still, being a boolean, it is easy to do as generic data if it is specific
to robustness.
includeFastStart BOOLEAN (StatusInquiry)
>
> [Question: GenericData contains a GenericIdentifier that can be a
"standard"
> (integer), OBJECT IDENTIFIER or a nonStandard. When used at the top
H323-UU-PDU
> level, this would identify the GenericData "package". Does the editor
intend to
> issue "standard" values for widely used GenericData's like ours or is
"standard"
> only intended for the lower level use of GenericIdentifier specifying a
> particular parameter in the "package", with the top level always being
OIDs?]
MY intention is that commen packages should use the standard identifier.
This is a LOT more efficient on the wire, and a LOT easier to implement in
code. (OIDs are a bit of a pain with our purchased compiler.)
>
> [note that this is a descriptive structure - not quite compilable ASN.1.
We
> might well define named substructures to make this easier to read.]
>
> So we would have a
> genericData ::= SEQUENCE
> {
> id ::= CHOICE
> {
> standard = <our value> -- or
> oid = <our oid>
> }
> parameters ::= SEQUENCE OF SEQUENCE
> {
> { -- for hasSharedRepository
> id ::= CHOICE
> {
> id = 1 -- for hasSharedRepository
> }
> content ::= CHOICE
> {
> bool = <true or false>
> }
Alternatative emulate the NULL OPTIONAL method where the quantity is TRUE if
present and FALSE otherwise.
> } OPTIONAL - used in Setup and Connect entity has a
SharedRepository
>
> { -- for backupCallSignalAddress
> id ::= CHOICE
> {
> id = 2 -- for backupCallSignalAddress
> }
> content ::= CHOICE
> {
> compound ::= SEQUENCE - this gives us the sequence of
> backupCallSignalAddress
> {
> id ::= CHOICE
> {
> id = 1 - this is just a sequence enumerator and
since
> nested I guess can duplicate values used above??
> }
> content ::= CHOICE
> {
> compound ::= SEQUENCE - this gives the sequence of
> Transport Address + ...
> {
> id ::= CHOICE
> {
> id = 1 - at this level it means the
transport
> address
> }
> content ::= CHOICE
> {
> ??ok here is the hard part we need to
duplicate
> the structure of a TransportAddress
> unless folks agree that TransportAddresses
are
> common enough to be added to the CHOICE list
> This is one disadvantage of the current
> GenericData approach - it is hard to use structures defined
> else where in the ASN.1
Hopefully this will be fixed by adding TransportAddress and AliasAddress to
the Content structure.
> }
> }
> }
> } -- repeat for more backupCallSignalAddress instances
> }
> } OPTIONAL - used in Setup and Connect
>
> { -- for callIdentifier
> id ::= CHOICE
> {
> id = 3 -- for callIdentifier
> }
> content ::= CHOICE
> { -- here we go again duplicating the CallIdentifier though
its not
> as complex
> compound ::= SEQUENCE
> {
> id := CHOICE
> {
> id = 1 -for guid
> }
> content ::= CHOICE
> {
> raw = <guid-octet-string>
> }
> } -- no others needed until ... is expanded
> }
> } OPTIONAL -- used optionally in Status and StatusInquiry - omit
for
> multiplexed channels and set CRV=0
>
> { -- for fastStart
> id ::= CHOICE
> {
> id = 4 -- for fastStart
> }
> content ::= CHOICE
> {
> compound ::= SEQUENCE -- to allow sequence of octet
string
> {
> id ::= CHOICE
> {
> id = 1 - for first octet string
> }
> contents ::= CHOICE
> {
> raw = <an octet string>
> }
> } -- repeat for more octet strings
> }
> } OPTIONAL - used in Status
You don't really need to have the extra level of nesting. Just have
multiple parameter 4s in the package.
>
> { -- for includeFastStart
> id ::= CHOICE
> {
> id = 5 -- for includeFastStart
> }
> content ::= CHOICE
> {
> bool = <true or false>
> }
> } OPTIONAL -- used in StatusInquiry
>
> { -- for h245Address
> id ::= CHOICE
> {
> id = 6 -- for h245Address
> }
> content ::= CHOICE
> {
> --again we have to duplicate the structure of a
TransportAddress
> unless this is added as a content type.
> }
> } OPTIONAL -- used in Status
> }
> } -- wheeoo
>
> We could break this into more than one GenericData but since they share a
lot
> this doesn't gain much. We could separate out the ones used in
RRQ,RCF,Setup and
> Connect from those used in Status and StatusInquiry. These two sets are
> disjoint. But since everything is optional it may not save much.
The other option is to have a slab of ASN.1 coding into a raw encoded
parameter 1 and have done with it. This is really how genericData was
expected to be used for complex structures. That's really a decision for
the editor.
>
> ?? This is a lot more complex than the previous method without
GenericData. Will
> parsing all this extra depth hurt performance? Is anyone going to get
this
> nesting right? I guess if we publish the ASN.1 in the Annex folks can
feed it to
> their ASN.1 compiler to generate the right stuff.
>
> Robustness group - consider this approach. Reply to this email or we will
> discuss it at our next call on 8/3.
>
> As Rich pointed out:
> - we avoid tying down the ASN.1 in November when H.225v2 is approved
(later
> binding)
> - we package everything together so it can all be omitted by
non-robust
> entities
> - we can easily use a different top level id to have a different
"robustness
> protocolId", that is, an additional robustness method or new version of an
old
> one.
>
> but
> - it is nested a bit more deeply in ASN.1
> - it is less self documenting (genericData's and their fields are not
named
> by strings, only numberic ids)
On this point, at least everything will be documented together rather than
being splatted across a number of parts of the Annex, 323 and 225. I think
this makes up slight loss of self documentation (also, I think people have
relied on the so called self documentation too much in the past.)
> - we have to duplicate structures already defined elsewhere in H.225's
ASN.1
> since we cannot directly use it and
> will have to keep changes in synch.
>
> Rich Bowen wrote:
>
-- snip --
Pete.
=============================================
Pete Cordell
Tech-Know-Ware
pete at tech-know-ware.com
+44 1473 635863
=============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd
mailing list