Subject: Re: Cisco SG16: Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 09:22:21 -0500

Comments below

> -----Original Message-----
> From: Chip Sharp [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 12:08 AM
> To: [email-masked]
> Subject: Re: Cisco SG16: Service Change
>
>
> At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
> >
> >
> >Comments below.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:55
> >PM  [[TomT]]  snip
> OK. Added the snipped stuff with updated status for
> completeness. Also note
> a couple of new issues here:
>
> Section:         7.2.8 (ServiceChange), numbered list items
> two and three
> Category:     Technical
> Issue no.:     13.12
> Issue:          The draft text has made significant changes to the
> semantics of the "Forced" and "Restart" ServiceChangeMethod
> since the Red
> Bank meeting. The old semantics guaranteed that the MG (or rather the
> affected terminations) would be in a known state following either a
> "Forced" or "Restart" ServiceChange. However the new
> semantics specified
> leaves the MG in an undefined state forcing the MGC to audit
> the MG to
> figure out what to do whenever it receives a "Forced" or "Restart"
> ServiceChange (consider the case where the primary MGC receives the
> "Forced" ServiceChange and the secondary (or another) MGC receives a
> subsequent "Restart" ServiceChange
> Proposal:     It is strongly suggested that the MG (or affected
> terminations) will be in a known state when a "Forced" or "Restart"
> ServiceChange is issued. Consequently, the text should be
> brought back in
> line with the outcome of the Red Bank meeting.
> Status:
>      v14: OPEN. No relevant text changed.
There has not been, to my knowledge, any change to forced and restart
which alters the state of the terminations since Red Bank.

If you cold-start an MG, it will come up in a known state, and
Restart to it's MGC, primary or secondary.  I think we can all
agree it does this.

If the MG itself FORCES terminations out of service, then the MGC
has to do the subtract.  There is no ambiguity of state.  No
secondary MGC is involved.

If the MGC FORCES terminations out of service, it must do the
subtract also, and there is no ambiguity of state.  No secondary
MGC is involved.

Somehow, your problem statement gets into a Handoff, or Failover
case, where, for some reason, you posit a working primary MGC
getting one message, and a working secondary MGC getting another one.
On a failure of an MG, there is no change of MGC, so the restart
looks like an initial registration, and all the terminations
should be in a known state.

On an MG initiated failover, the MG registers with the secondary
with Failover, not Restart.  The MGC could send Forced to
the primary, but the MG is considering it dead, and probably
wouldn't do it.  At any rate, failover DOES require an audit
by the secondary MGC as it should.

On an MGC initiated failover, you use Handoff.  Again, the MGC knows
what the state is, but the secondary doesn't.  It must Audit, but
that is as it should be.

There are no other cases of Forced or Restart that I know about.

> Section:         7.2.8 (ServiceChange), numbered item six
> Category:     Editorial/Technial
> Issue no.:     14.7
> Issue:          The draft text for "Failover" specifies that
> "..., and sent
> from MG to (new) MGC in response to the MG having received a
> ServiceChange
> with ServiceChangeMethod equal to Handoff". It would seem to be more
> consistent if the MG sent a "Handoff" rather than a
> "Failover" to the (new)
> MGC in response to a handoff from the old MGC.
> Proposal:     It is proposed, that above text segment is
> moved from the
> "Failover" method to the "Handoff" method.
> Status:
I'm okay with this, although I think it's a nit

>
> Section:         7.2.8 (ServiceChange), fifth last paragraph
> Category:     Technical, Editorial
> Issue no.:     14.8
> Issue:          The draft text specifies that "The MGC shall use this
> Addres, if specified, in its response to the ServiceChange
> command and any
> subequent commands and responses" and "The MG shall use this
> address for
> any subsequent communication with the MGC". While it makes
> sense to require
> commands to be sent to this address, it is generally not a
> good idea to
> require this for responses, e.g. for clustered systems. Furthermore,
> Section 9 (Transport) also specifies that "Responses to
> commands are sent
> back to the source address of the commands"
> Proposal:     It is strongly recommended, that commands will
> be sent to the
> address specified while responses will always be sent to the
> source address
> they came from.
> Status:
I agree with this.  The text is inconsistant, so something needs
to be changed.  Chip's proposal seems the most reasonable way
to resolve it

>
> Section:         7.2.8 (ServiceChange), third last paragraph
> Category:     Editorial
> Issue no.:     12.25
> Issue:          The draft text specifies that "The
> ServiceChangeMethod
> shall be "forced" for this usage". This is inconsistent with the
> description in Section 11.2  which specified a ServiceChangeMethod of
> "Restart".
> Proposal:     It is recommended that the above text be
> modified to use a
> ServiceChangeMethod of "Restart" instead.
> Status:
>      v13: CLOSED. Text has been modified.
>
>
> Section:     7.2.8 (ServiceChange), last bullet list
> Category:     Technical
> Issue no.:     13.13
> Issue:          The draft text specifies that "Profile required if
> terminationID is not ROOT, optional otherwise". However there
> may not be a
> profile, in which case it makes little sense to require it.
> Secondly, it
> would seem to make more sense to require a profile when the
> terminationID
> in fact is ROOT as that would be the initial registration.
> Proposal:     It is proposed, that the text is changed in
> accordance with
> above.
> Status:
>      v14: OPEN. No relevant text changed.
How about: Profile is Required if the termination ID is ROOT,
and the entity supports a profile, optional otherwise.

I agree the text is wrong, and some change is required.

>
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     When a
> >gateway starts, it generates a restart ServiceChange  to the
> MGC. If the
> >MGC's response to the ServiceChange is lost while a  later
> command is
> >received by the gateway, how this command is handled is  not
> specified in
> >the draft text.  Proposal:       It is recommended that the
> gateway will
> >return an error.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Agreed in principle.  This triggered thoughts of flooding
> >attacks where the attacker masquerades as the MGC which it
> is indirectly
> >trying to flood with error messages.  I suppose we're OK so long as
> >authentication failures are discarded silently.  Anyway, I'll add a
> >"clarification" to section 8.3 stating that the MG should
> respond with an
> >error to authenticated messages from MGCs with which the MG is not
> >currently associated.   It's not quite so simple for MGCs receiving
> >messages from strangers -- I guess the MGC has to look
> inside to determine
> >whether to accept them.
> v14: CLOSED. An error will be returned
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     The draft
> >text specifies that "If the MGC accepts the MG,  it will send a
> >Transaction Accept, with the MGCIdToTry set to itself. If
> the MG receives
> >an MGCIDToTry not equal to the MGC it contacted, it send a
> ServiceChange
> >to the MGC specified in the MGCIdToTry". It is inconsistent
> to on one
> >hand accept the transaction as successful, yet on the other
> hand  require
> >the MG to examine the MGCIdToTry returned to determine if
> >the  registration really was successful or not. Examination of the
> >syntax  reveals that this is part of a larger problem where
> >unsuccessful  transactions, actions and commands are not
> able to return
> >any other  information than an ErrorDescriptor which can
> only contain an
> >error code  and text.  Proposal:       It is recommended
> that the above
> >procedure is replaced by  return of an error code and
> another MGCIdToTry
> >if the registration did not  complete. Furthermore, it is
> recommended that
> >ErrorDescriptors are extended  to allow return of other information
> >(essentially CommandReply) than only  an error code and text.
> >
> >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> it, redirection
> >is different from a transaction error.  The MGC processed
> the command
> >successfully, and the response contains useful information.
> An error
> >should be thought of as a situation where the responder
> reached a dead end
> >when it tried to comply with the request.  In general
> recovery from an
> >error is pretty basic: kill the call.  In special cases the
> error code and
> >context should give enough information for recovery.
> Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> return codes
> that have nothing to do with "errors" per se. In reality,
> these "error
> codes" are really "return codes" and maybe that's where the
> confusion arises.
I'm with Tom on this one, and I'll further point out you can't do
what Chip proposes since if you get an Error descriptor, you
won't get the Service descriptor with the MgcIdToTry!

> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 10:49:27 -0500

Hi Brian

Some comments below.

Regards

        Flemming Andreasen

> which alters the state of the terminations since Red Bank.

Actually, there has. v13 made some changes from v12 in this area. In v12,
"forced" would had an effect similar to subtract on the affected
termination, where as in v13, all of a sudden it's the MGC responsibility
to figure out what the state of the MG is. Similarly, "restart" in v12
implied the affected terminations were not associated with any Context
(except for the NULL context presumably), where as v13 does not. Again, the
MGC will now have to figure out what state the MG is in when it receives a
"restart", 'cause it can't make any assumptions whatsoever.

> Restart to it's MGC, primary or secondary.  I think we can all

Yep, but what about warm-start ?

> should be in a known state.

Yes, they should, and that's the point. When you get a "restart", you know
you are in well-known *clean* state.

> by the secondary MGC as it should.

Ah yes, but what happens when the MG sends "forced" to the MGC (MGC-A), and
a little later it tries to register with MGC-A who meanwhile crashed.
Consequently, MG goes through it's list of secondaries and finds MGC-B. Are
you saying it no longer uses "restart" but "failover" ?

Regardless of what the answer is, it seems like there is a need for a state
transition diagram for the MG and MGC in the text somewhere. It is not
exactly clear what all these rules add up to, and there's clearly some
underlying logic expected.

As for requiring an audit after failover, that seems rather strange to me.
Since failover supposedly is transparent (don't loose any messages, right
?) why would you need that ? You can of course recommend it as good MGC
practice if you think you don't have transparent failover, but I thought
that was the intent of "disconnected".

> what the state is, but the secondary doesn't.  It must Audit, but

Maybe it does, maybe it doesn't. That's MGC internals, right ?

> won't get the Service descriptor with the MgcIdToTry!

Yes, and as pointed out above, that's a fundamental problem that seems to
have no motivation and certainly not be in line with current experience and
practice.