Subject: [Megaco] ServiceChange procedures -- future Annex F

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Jul 2002 14:04:20 -0400

All,

At the June Rapporteur's meeting, baseline text was accepted for what will
eventually become Annex F.  This Annex covers ServiceChange procedures,
putting definitions on common terms (like registration and control
association) and delving into behavior of ServiceChange on Root.  Work on
this is expected to complete mid to late 2003.

I encourage you all to read the document, as work will progress on it at
future ITU meetings.  Any comments, issues, questions, etc., should be
posted here.  There is a lot of work left to do, such as defining non-root
behavior and clarifying a number of questions that the document poses.

Until such time as the document can be posted to the Megaco web site, you
can retrieve it from:

ftp://standards.pictel.com/avc-site/0206Bru/TD-41a.zip

Kevin

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Jul 2002 16:00:28 -0400

My apologies on the typo.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:39 PM
To: Chuong N. Nguyen; [email-masked]
Subject: Re: [Megaco] ServiceChange procedures -- future Annex F

Try (note "_" in dir name)
ftp://standards.pictel.com/avc-site/0206_Bru/TD-41a.zip

At 03:30 PM 7/23/2002, Chuong N. Nguyen wrote:

Hi Kevin 

I have trouble getting this doc. 

Can you verify? 

Thanks 
Chuong 

Kevin Boyle wrote: 

All, 

Kevin

-- 
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Jul 2002 16:00:28 -0400

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:39 PM
To: Chuong N. Nguyen; [email-masked]
Subject: Re: [Megaco] ServiceChange procedures -- future Annex F

Hi Kevin 

Can you verify? 

Thanks 
Chuong 

Kevin Boyle wrote: 

All, 

Kevin

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 28 Jul 2002 18:21:58 +0200

Kevin and list,

Here are some comments about the proposed ServiceChange procedures.

1. INSTANTIATE

I am not sure what you mean by "Only MGs may instantiate control
associations".  I understand that only MGs may initiate control
associations.  What additional information is intended by the word
"instantiate"?

2. CONTROL ASSOCIATION = MG IN-SERVICE?
 
The document seems to equate the existence of a control association with the
MG being in-service.  I can think of three reasons why this might be a
problem.  One is if an application finds value in separating the notion of
MG being in good working order, and able to provide telephony service, from
its current ability to talk to an MGC.  How would an MG say to an MGC, "I am
able and willing to talk to you, but I have hardware, software or other
problems that prevent me from providing any service to subscribers"?  One
answer might be, that in this case the MG is IS but all its terminations are
OOS.  Well, what if the problem is with some common equipment that is shared
by all terminations?  If we assign the OOS condition to all the
terminations, then we mask any specific OOS conditions that apply to some
terminations and not others.

The other way in which an MG service state might differ from its ability to
talk to an MGC would be, "All my equipment is in good working order, but I
don't want to talk to you, this MGC".  Of course, you might argue that an MG
has no right to make such a statement.  If it does, then until such an MG
establishes a control association with another MGC, it has to know that it
is considered OOS, even though its equipment is OK.  I don't see a real
problem here, because an MG can have as many internal states as it likes; it
has nobody to tell it to.

The second possible objection I see relates to consistency between Root
states and other termination states.  I am basing myself on Tom Taylor's
posting on 28/11/2001 on a thread I initiated:

The answer to all your quandaries is indeed to require both sides to track 
two state variables.  However, this only requires one explicit state value 
in the messages exchanged between them, as I'll explain below.  Thinking 
this out, I've changed my mind a bit on how it all should work.  I came to 
this point in considering what would happen in the case of SewrviceChange 
'glare', where both sides simultaneously announce that the termination is 
out of service.  We don't need a visible change in the protocol to take care

of this, but we do need to specify some behaviour.  We could specify backoff

rules, but I think the proposal I give below is simpler. 

I would remark that the two states are not "fault" versus "administrative", 
but rather "MG view" vs. "MGC view".  Administration could act directly on 
the MG rather than through the MGC, or the MGC could detect a fault in the 
provisioned data for the termination.  Each entity has to track its peer's 
view as well as its own. 

The necessary coordination can still be achieved through a single state 
property in the messages exchanged.  The key point is in the interpretation 
of that property.  Instead of a single shared view of state, it represents 
the sender's view of state.  The required description of behaviour is 
therefore as follows (text to go in the ServiceChange section 7.2.8: 
 - either entity in the control association may send a ServiceChange 
indicating a change in the state of a termination at any time 
 - a termination is available for general use only if neither the MG nor the

MGC have most recently indicated that it is out of service 
 - in other cases use of the termination is restricted. 

The above defines language we can now use to replace current restrictions on

applying other commands when a termination is out of service.  We say 
instead, that the commands cannot be applied when use of the termination is 
restricted in accordance with the definition given in section 7.2.8. 
	[End of Tom Taylor quote].

This is actually the subject of point 4.f) in the document, so I take it
that it is not resolved yet.  Personally, I think Tom's position is very
reasonable and clean.  Now, if with respect to terminations, each side is
aware of its own view of the state, and the other entity's (MG's/MGC's) view
of the state, it would be logical to apply the same model to the state of
Root.  My objection here is mainly aesthetic; maybe it has no practical
significance.

The third possible objection relates to the debate that has raged in this
list for the last month or so.  Although I realize that you, Kevin, disagree
strongly with the notion that an MG could have simultaneous relationships
with multiple MGCs, and Aleksandr Ryabin has assured you that this is not
really what he is proposing, there are enough ideas in this direction
floating around to suggest that it might not be very future-proof to couple
the MG service state too tightly with its relationship to a specific MGC.

3. RESTART FROM MGC

"When sent by the MGC, the MG shall restart itself using the indicated
ServiceChangeReason to determine whether or not to clear its state".  

I do not understand what "clear its state" means.

4. FORCED FROM MGC

"When sent by the MGC, the MG shall take itself out of service, and
terminate the control association after sending the command reply".

I wonder if there is any real problem (certainly there are implementation
complexities) caused by the fact that usually, an MG receives a command,
acts on it, and then sends a reply.  In this case, it may not be so.
Actually this looks like a fourth objection to control association = MG
in-service.  The MG goes OOS before replying, but terminates the control
association after replying, thus suggesting that they are not the same
thing.  If it really followed the usual pattern of acting on the command
before replying, maybe it shouldn't reply at all?  I don't have a definite
opinion on this, maybe someone else does.

Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 28 Jul 2002 18:21:58 +0200

Kevin and list,

1. INSTANTIATE

 

3. RESTART FROM MGC

4. FORCED FROM MGC

Raphael Tryster

---

From: "Kaul, Bharat" <[email-masked]>
Date: Tue, 30 Jul 2002 16:01:40 -0700

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, July 28, 2002 9:22 AM
To: Kevin Boyle; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

Kevin and list, 

1. INSTANTIATE 

I am not sure what you mean by "Only MGs may instantiate control
associations".  I understand that only MGs may initiate control
associations.  What additional information is intended by the word
"instantiate"?
[Kaul, Bharat] Should be initiate. 

2. CONTROL ASSOCIATION = MG IN-SERVICE? 
 <<<<<<<<snip>>>>>>>>>>>>>>>>.   
This is actually the subject of point 4.f) in the document, so I take it
that it is not resolved yet.  Personally, I think Tom's position is very
reasonable and clean.  Now, if with respect to terminations, each side is
aware of its own view of the state, and the other entity's (MG's/MGC's) view
of the state, it would be logical to apply the same model to the state of
Root.  My objection here is mainly aesthetic; maybe it has no practical
significance.
[Kaul, Bharat] I would agree with you that it seems mainly asethetic. 

The third possible objection relates to the debate that has raged in this
list for the last month or so.  Although I realize that you, Kevin, disagree
strongly with the notion that an MG could have simultaneous relationships
with multiple MGCs, and Aleksandr Ryabin has assured you that this is not
really what he is proposing, there are enough ideas in this direction
floating around to suggest that it might not be very future-proof to couple
the MG service state too tightly with its relationship to a specific MGC.
[Kaul, Bharat] Having implementations wherein a gateway resource is
simulataneously controlled by multiple MGCs, it will break the protocol as
it stands today. If one wants to distribute controlling of mutually
independent gateway resources across multiple MGCs, the virtual MG concept
in the protocol is obvious choice.

3. RESTART FROM MGC 

I do not understand what "clear its state" means. 
[Kaul, Bharat] I always took it to that for established connections will be
torn down gracefully and transient ones not so gracefully. However, I am not
clear about following issues:

*	What happens to "established" connections after expiry of
ServiceChangeDelay ?
*	Assuming all terminations are placed in OOS, what is the state of
the control association ? Is MG still communicating with the same MGC or is
it free to choose MGC's again (e.g. go to primary if one giving restart is
not primary)

4. FORCED FROM MGC 

I wonder if there is any real problem (certainly there are implementation
complexities) caused by the fact that usually, an MG receives a command,
acts on it, and then sends a reply.  In this case, it may not be so.
Actually this looks like a fourth objection to control association = MG
in-service.  The MG goes OOS before replying, but terminates the control
association after replying, thus suggesting that they are not the same
thing.  If it really followed the usual pattern of acting on the command
before replying, maybe it shouldn't reply at all?  I don't have a definite
opinion on this, maybe someone else does.
[Kaul, Bharat]  I interpret it as:  all terminations get placed OOS
rightaway. MG should only attempt to send out response to ServiceChange (i.e
response to other commands don't matter). However, questions about control
association remain.

- Bharat

---

From: "Kaul, Bharat" <[email-masked]>
Date: Tue, 30 Jul 2002 16:01:40 -0700

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, July 28, 2002 9:22 AM
To: Kevin Boyle; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

Kevin and list, 

1. INSTANTIATE 

3. RESTART FROM MGC 

4. FORCED FROM MGC 

- Bharat