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

31 Jul 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@LUCENT.COM
To: ITU-SG16@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@tech-know-ware.com
+44 1473 635863
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@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