H.450.7 whitepaper uploaded

Dave Walker dave_walker at Mitel.COM
Fri Dec 18 13:47:37 EST 1998


I was just sitting down to write to you, when this arrived. I will address
my response here.

In APC-1480, a PricingIndication was intended to be acknowledged by a
PricingConfirm. I realise that this is awkward, using the one message for
more than one role, and is asymmetric. Annex G has the DescriptorUpdate,
which serves a similar role, and is unacknowledged. I think that this is

Even if the receiver asks for the updated descriptors of interest, it is
not an unequivocal confirmation that the update was received. Several
solutions are possible, some of them more kludgy than others.

Probably the cleanest method would be an additional message,
DescriptorUpdateAck. [As a kludge, nonStandardConfirmation/Rejection witht
the same sequenceNumber would suffice]. An optimisation of embedding the
acknowledgement in the DescriptorRequest (if sent) could cause
implementation problems in matching request with response.

One of the reasons put forward for the descriptorID mechanism is for
caching. I think that to make this effective, a version number has to be
incorporated into the descriptor identification mechanism. The version
number allows the receiver to know if the cached information is still
valid, or updated information must be requested. This could be a "last
sequence number" or "last updated on" timestamp.

In merging Annex G and BEST, we would still be different in identifying
templates. While Annex G would identify them with a descriptorID, I would
identify them with a pattern. I feel that a pattern supports a hierarchical
representation which allows the requestor to know what is in the template
before it is requested, and to "drill-down" into the hierarchy structure of
templates that are of interest.

Perhaps, pending discussion and decision, we could adopt the following, in
DescriptorIDConfirmation and DescriptorUpdate, to allow qualification later?

    descriptorID        DescriptorID,

This would allow version, pattern, or other information to be added later,
something that would be difficult to impossible as these things stand.

I can't see how "drill-down" could be achieved in the current model. This
means that a "flat" template model must be used. I haven't thought it
thrugh yet, but adding a messageType of "sendDescriptorRequest" to
RouteInformation, with "descriptors SEQUENCE OF DescriptorID OPTIONAL"
might do it.

A question that comes to mind is: when would a descriptorID stay the same,
and when would it change? I suspect that it would stay the same, if I alter
the routeInfo, but change if I alter the pattern. If it changes, I must
send out a delete for the old, and an add for the new. (I would think it
imperative that this information not get lost.)



* receiving descriptors from other border elements in response *to* general

replace the words "statically configured" with "public" on line 1.

should the last paragraph allow the use of reliable transport (TCP) as an
alternative to multiple messages for known endpoints?

Fragmentation, and it's consequences are so variable, I doubt that it
should be expressed in quite that way. Where and how are the listed numbers
defined? I thought that the numbers were around 1500 octets for ethernet
and 4000 bytes for FDDI.

here, and in other places (1.7.1 and, does the "+" form part of
the pattern? Are spaces permitted? How are private and public numbers
differentiated (e.g. "For private 31*...")?

I'll now keep looking at the revised draft.


At 16:38 15/12/98 -0700, Glen Freundlich wrote:
>Dear colleagues,
>I have placed review copies of Annex G in the Incoming directory of
>avc-site. The file annexg10c contains change marks from the last draft
>at the Torino meeting. The file annexg10n is the same document with no
>change marks.
>I would appreciate any comments. Remember that the white drafts are due
>19 December, so I plan to deliver Annex G on 18 December. I've compiled
>the ASN.1, but I would appreciate if someone else could also compile it
>as a sanity check.
>Glen Freundlich                           ggf at lucent.com
>Lucent Technologies                       office: +1 303 538 2899
>11900 N. Pecos                            fax: +1 303 538 3907
>Westminster, Colorado 80234  USA

More information about the sg16-avd mailing list