Subject: Re: Comments on v12

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Nov 1999 16:28:27 -0500

> 1. Section 6.2.1: "An MGC can only release/modify
> terminations and the resources
> that the termination represents
> which it has previously seized via e.g. the Add command."
>
> This statement seems to imply that an MGC can modify
> termination only after they
> have been seized using the Add command. Does that mean that
> an MGC can not
> modify terminations in a NULL context ?
It is not meant to imply that.

>
> 2. Section 6.2.2: "A wildcarding mechanism using two types of
> wildcards can be
> used with TerminationIDs. The
> two wildcards are ALL and CHOOSE. The former is used to
> address multiple
> Terminations at once, while the latter is used to indicate to
> a media gateway
> that it must select a Termination satisfying the partially specified
> TerminationID."
>
> In the text encoding, it is possible to let the MG choose a
> termination Id by
> using $, but it is not possible to choose from a partially specified
> termination, that is it is not possible to tell MG to choose
> any termination
> starting with say R12/C2/. The same is possible in the binary
> encoding.
>
> I think both the encoding should support the same set of
> features and hence $
> should be allowed in the termination id to be able to
> describe partially
> specified terminationid as R12/C2/$.
While I personally would favor this change, I think that the text encoding
best represents the state of agreements on wildcards.

>
> 3. Section 11.1 "ServiceChange may only be applied to the
> Root by the Master
> MGC."
>
> Why such a restriction is there ? Does this mean that if a
> ServiceChange is
> applied to the ROOT of one Virtual MG, then it gets applied
> to all virtual MGs ?
Yes.  It is considered difficult to restart a virtual MG and not the
rest of the physical MGs.

> Consider a scenario where a physical MG is decomposed into 3
> virtual MGs being
> controlled by three different MGCs. If one of the MGC (which
> is not the master
> MGC) wants to handoff the virtual MG that it is controlling
> to another MGC, then
> it should be able to send the SerivceChange on the Root
> termination to the
> specific virtual MG that it is controlling. Why should only
> master MGc be
> allowed to send ServiceChange on Root ?
I don't think we considered that possibility.  To accomplish it requires
that
we narrowly define when the MGC can send ServiceChange to the root of a
virtual MG.  While this seems to me to be a desirable thing, I'd also say it
does not rise to the level of severity that would warrant a change at this
time.

>
> 4. Annex B:  ABNF sepcification for digitMapDescriptor:
>
> digitMapDescriptor = DigitMapToken EQUAL digitMapName ( LBRKT
> digitMapValue
> RBRKT )
>
> should be
>
> digitMapDescriptor = DigitMapToken EQUAL digitMapName [ LBRKT
> digitMapValue
> RBRKT ]
Yes, a typo, the value is intended to be optional.

>
> 5. Annex D.1.2: "MGs can simply detect duplicate transactions
> by looking at the
> transaction identifier only."
> This line needs to be rephrased. Both MG and MGC can detect a
> duplicate
> transaction by looking at a combination of mId and TransactionId as
> TransactionIds are unique wrt to the sender (refer section 8.1.1).
Good suggestion.  I think we CAN to real editorial changes like this,
but we are trying hard not to make any changes at all.

>
> 6. Annex D.1.4: "The root termination has a property
> (ProvisionalResponseTimerValue), which can be
> set to the requested maximum number of milliseconds between
> receipt of a command
> and
> transmission of the TransactionPending response."
>
> How is "ProvisionalResponseTimerValue" different from
> "normalMGExecutionTime"
> (as defined in section 8.2.3) ? Shouldn't the timer value for sending
> TransactionPending message be derived from normalMgExecutionTime ?
ProvisionalResponseTimer is changeable, normalExecutionTime is not

>
> 7. Annex D.1.4: "In order to account for the possibility of
> an undetected or
> in-progress "failover", we modify the classic algorithm so
> that if the Media
> Gateway receives a
> valid ServiceChange message announcing a failover, it will
> start transmitting
> outstanding
> commands to that new MGC."
>
> This is also valid for MGC, that is, if MGC sees a ServiceChange with
> "failover", then it should reset the retransmission count and send the
> outstanding commands to the new MG.
I think you are correct.

> Also in the case of ServiceChange with ServiceChangeMethod as
> "Handoff", the
> retransmission count should be set to zero and the pending
> transactions and
> transaction replies have to be sent to the new MGC.
No, a characteristic of handoff is that transactions are completed with the
original initiator, so replies are sent to the old MGC.  A new transaction
would go to the new MGC.

>
> 8. Annex D.1.4: "It is however important that the maximum delay of
> retransmissions be bounded. Prior to any
> retransmission, it is checked that the time elapsed since the
> sending of the
> initial datagram is no
> greater than T-MAX. If more than T-MAX time has elapsed, the
> MG concludes that
> the MGC has
> failed, and it begins its recovery process. The value T-MAX
> is related to the
> LONG-TIMER value:
> the LONG-TIMER value is obtained by adding to T-MAX the
> maximum propagation
> delay in the
> network."
>
> I believe this works the other way also, that is, MGC also
> checks elapsed time
> against T-MAX.
Yes, I think so.

>
> 9. The positioning of Events descriptor and Signals
> Descriptor is not clear. Are
> they part of the Stream Descriptor ? I believe they are not,
> in which case the
> text in section 7.1.6 needs to be changed.
Arggh, we missed one!  Yes, indeed, we must change 7.1.6

>
> 10. Meaning of optional command: This issue has been raised
> earlier also on the
> mailing list but I am not sure of the result.
>
> Does the optional command mean:
>
> "Commands may be marked as "Optional" which can override this
> behavior - if an
> optional command results in an error, subsequent commands in
> the Transaction
> will be executed." (as specified in section 8)
> OR
> "If a command is marked as optional, the MG has the choice of
> executing it or
> not, and if it does
> execute it, it returns the Response, or Error." (as specified
> in section 8.2.2)
> OR
> Both ?
It has been decreed that it is the former, if an optional command fails,
subsequent commands execute anyway.

> If the meaning is both then I suggest both the
> interpretations should be given
> in section 8 itself.
>
>
> 11. Section 12.1.3: "ObservedEventDescriptor Parameters:
> Parameters returned to the MGC in the Notify, and found in the
> ObservedEventDescriptor."
>
> Should be:
>
> ObservedEventDescriptor Parameters:
> Parameters returned to the MGC in the Notify, Audit Value and Audit
> Capabilities, and found in the
> ObservedEventDescriptor.
Sigh, yes, must be changed.

>
> 12. Section 12.1.2: "Characteristics: Read / Write or both."
> What is the significance of having a write only property ?
Should read: "Read only or Read/Write"

>
> 13. Section 12.1.3 and 12.1.4:  Instead of referring to
> section 12.1.1, the
> reference should be 12.2
Typo, yes, must be changed

>
> 14. Section 12.2: "Guidelines to defining Parameters to
> Properties, Events,
> Signals, and Statistics."
> Can we have parameters to Properties and Statistics ? Section
> 12.1.2 and 12.1.5
> do not not mention any parameters to properties and statistics.
No, you can't.  Need to rewrite the section header.  Something like
Guidelines to defining Properties, Statistics and Parameters to Events and
Signals
>
> 15. Section 7.2.8: - Failover should be added to the list of
> possible values for
> ServiceChange Method. It would also be helpful, if for each
> ServiceChangeMethod
> it is explained whether it is possible to use it from MGC or
> MG or both.
Yes to the former.  Good to do for the latter, and a maybe makes it above
the line for change urgency.

Thanks for reviewing the new text critically, very helpfull!

Brian

---

From: Harpreet Singh Anand <[email-masked]>
Date: Fri, 5 Nov 1999 12:51:48 +0530

> ProvisionalResponseTimer is changeable, normalExecutionTime is not

How will MG use normalMgExecutionTime ?

> original initiator, so replies are sent to the old MGC.  A new transaction

Section 11.4, states in the handoff case, the transaction replies are sent to
the new MGC. I am reproducing the paragraph below:

"When the MGC initiates a HandOff, the handover should be transparent to
Operations on the Media Gateway. Transactions can be executed in any order, and
could be in progress when the ServiceChange is executed. Accordingly, commands
in progress continue, transaction replies are sent to the new MGC, and the MG
should expect outstanding transaction replies from the new MGC. Since all
connections should stay up."

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: John Segers <[email-masked]>
Date: Fri, 5 Nov 1999 10:22:25 +0100

Harpreet,

I agree with Brian on most issues, but not on all.  Please see below.

John

Brian Rosen wrote:

> best represents the state of agreements on wildcards.

My understanding was that we converged on the more general mechanism, in
which even something like a/*/c is allowed.  That was the reason for
adding it in the ASN.1.

> but we are trying hard not to make any changes at all.

The way I see it, D.1.2 assumes a MGC-MG pair.  Within that context,
transactionID is all you need.

> > outstanding commands to the new MG.

This doesn't seem useful to me.  What is "the new MG"?  We don't have a
concept of backup MGs.  Furthmermore, pstn bearer channels are hardwired
to MGs, so no other MG can take over because no other MG has access to
those channels.

> Thanks for reviewing the new text critically, very helpfull!

Indeed.  Thank you for the excellent comments.

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Harpreet Singh Anand <[email-masked]>
Date: Fri, 5 Nov 1999 15:25:56 +0530

John,

> to MGs, so no other MG can take over because no other MG has access to

This was with reference to the description given in Section 11.3. I am quoting
the relevant paragraph below:

"Allowing the MGC to send duplicate messages to both MGs accommodates pairs of
MGs that are capable of redundant failover of one of the MGs. Only the Working
MG shall accept or reject transactions. Upon failover, the Primary MG sends a
ServiceChange command with a "Failover" method and a "MG Impending Failure"
reason. The MGC then uses the primary MG as the active MG. When the error
condition is repaired, the Working MG can send a "ServiceChange" with a
"Restart" method."

This paragraph is a bit confusing with the usage of terms like Working Mg,
Primary Mg, Active Mg (a better wording of this paragraph would be very
desirable). But the intent of the paragraph seems to be that two MGs are working
in tandem and failure of one leads to other MG becoming active.

Regards,
Harpreet

---

From: John Segers <[email-masked]>
Date: Fri, 5 Nov 1999 11:19:18 +0100

Ah, the reference to 11.3 does help -- I was only looking at D.1.4.  The
text in 11.3 is not very clear, I agree.  Even if we change the wording
of that section, I'm still not convinced that when the active MG fails,
it is useful to send outstanding commands to the backup.  If the
commands refer to specific circuits, they will have to be changed before
they are transmitted.

John