[Robustness] GenericData (was:Minutes of the 7/20 call)

Terry L Anderson tla at LUCENT.COM
Mon Jul 31 13:17:46 EDT 2000


See comments

Pete Cordell wrote:

> 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.

Adding TransportAddress would be my choice.  The problem is that a
TransportAddress is not just an IPv4 address.  Even for "ipAddress" it includes
a port, but there are also a number of other choices (though less commonly
used).

> >
> > 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)

This is what is in the current white draft, but there is a suggestion of
removing anything being added for only Robustness and so we would return to
Status and StatusInquiry having NO UUIE.

> 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.

Unfortunately since False cannot be prohibited in the ASN.1 BOOLEAN gives us a
tri-valued field.  Even if only True/False or True/omit is intended one needs to
state what the recipient should do if the other value is received.

> >         } 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.

I guess that is essentially what gets done in some of the cryptoToken options,
but our stack folks hate this.  It requires calling the ASN.1 encoder twice
(once to encode the "slab", then insert into message and encode again).  With
some stack interfaces this is hard and at a minimum it costs more time.  BUT it
is the most flexible, allowing any structure defined in another message to be
included in GenericData.  (this is one of the disadvantages of ASN.1 encoding in
my view).

> >
> > ?? 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.)

I agree.  It may even be that the specifications on how to use GenericData for a
specific feature can use named structures, e.g., BackupCallSignalAddress defined
as an instance of EnumeratedParameter.

>
> >     - 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 --

Thanks for the comments.

>
>
> 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

--
------------------------------------------------------------
Terry L Anderson              mailto:tla at lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572 at skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 548 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000731/5c51b0a2/attachment-0004.vcf>


More information about the sg16-avd mailing list