RE: Protocol version re-negotiation
Nancy,
The parameter that would be used is be the ServiceChangeAddress. As far as the assumption that the MGC would be provisioned with the primary and secondary MGs, certainly it could be done that way (and the text in 11.4 does imply this), but I do think that passing the address is an acceptable approach and should certainly be allowed.
IMO we don't really need a new method for this. I don't see how adding a new method is more efficient. I still would contend that adding a ServiceChangeReason is sufficient and that it is desirable to do so (at least in V.2).
Michael
-----Original Message----- From: Nancy Devin [mailto:nancy.devin@alcatel.com] Sent: Tuesday, February 27, 2001 1:07 PM To: Brown, Michael [NC1:GW10:EXCH] Cc: ITU-SG16 Mail List; megaco@fore.com Subject: Re: Protocol version re-negotiation
Hi Mike,
I don't understand why your are talking about passing the address of the secondary MG to the MGC during a Failover. My understanding is that the MGC is configured with both the primary MG address and the secondary MG address (even though I did not find any text on that). If that is not the case then which parameter is used to transmit the address the the MGC.
Also, I think the idea of having to Handoff to another MG or Failover to the other MG may not be the most efficient one. If we are to add a new reason then why not also add a new method which would be "VersionNegotiation"
Method: VersionNegotiation TerminationID: Root Reason: MG directed change / MGC directed change Description: Sent from the MG to the MGC, the MG initiates a protocol version negotiation. Sent from the MGC to the MG, the MGC initiates a protocol version negotiation.
Nancy
Michael Brown wrote:
Comments inline.
Michael
"Rosen, Brian" wrote:
I think you missed one point: "How does a NON-redundant MG upgrade to a new version of the protocol?"
It comes down, reboots, and comes up again - it's a service affecting change. AFAIK, that's the only way today.
<MB> Yes, if the MG is really Non-redundant there doesn't seem to be an
option.
Can the MG Failover to itself? Will this cause any problems in the MGC?
Since that's not a defined option, some MGCs might have a problem.
<MB> While there is no existing text specifically saying that this is
allowed.,
there also is none that disallows this behavior. It seems to me that the
MGC
should just accept the "new" address for the "secondary" MG and go on.
This
would be used when an MG and its mate hide behind a single address for the
MGC
<> MG control association. I would think that this could easily be added
to the
implementor's guide and I don't think that it should cause problems.
To allow this requires only a few changes to the text in RFC3015 as follows: Section 7.2.8 ServiceChange Modify text: "6) Failover - sent from MG to MGC to indicate the primary MG is out of service and a secondary is taking over, or to indicate a version negotiation from the MG." Add a Reason: "Version Negotiation" or a more generic "MG Directed Change". Add text: "The MG may initiate a version negotiation with a ServiceChange Command specifying the "Root" for the TerminationID, ServiceChangeMethod equal to Failover and ServiceChangeReason equal to "Version Negotiation"."
I think that's a scope add, which I for one am reluctant to do. If there was a real problem with something we already had, that's one
thing,
but a real feature add, I'm less thrilled about. I'll admit some of the things we have talked about stray at least close, if not over such a line.
Here,
I think an MG that can do a non-service affecting upgrade which is not redundant is pretty unusual these days - I don't mean to discourage
folks
from doing that, but I also don't feel we need changes in semantics (and some additional syntax, albeit some IANA registrations) to make it
happen,
it can wait for V2.
<MB> I'm suppose I'd agree that this propoal is adding a new feature as it
would
require a new, IANA registered reason and the associated behavior. I'd say
it's
somewhat unfortunate because basically, I don't see problems with the
proposed
approach. There is one thing about the approach that bothers me which we
might
consider for V2. That is, the use of Failover in this instance seems inappropriate. The name just seems to imply that a software upgrade is a
failure
scenario. I would suggest that it would be nicer to enhance the
definition of
Handoff rather than Failover since handoff implies a more graceful
transition.
Given the current definitions of Handoff and Failover in version 1, we do
have
to live with Failover for now.
Cheers, Paul
"Rosen, Brian" wrote:
It's unlikely that we will do anything that adds new features by edits to the implementor's guide. It's reasonable to have explanatory text in such a document that is not normative.
I think you failover, upgrade, and failover back with this version of the protocol.
Brian
-----Original Message----- From: Paul Rheaume [mailto:paul.rheaume@alcatel.com] Sent: Thursday, February 22, 2001 1:00 PM To: ITU-SG16 Mail List Cc: megaco@fore.com Subject: Re: Protocol version re-negotiation
Folks,
Where is the appropriate list to discuss this issue?
We feel that version negotiation and the version upgrade process is not well specified and needs to be discussed and properly
defined at the
latest in version 2 of the specification. That means
looking at this
very soon.
I think this issue belongs to the next version of the
Implementor's
Guide.
Regards, Paul
Nancy Devin wrote:
How does a non-redundant MG upgrade to a new Megaco version without affecting service? How does a redundant MG upgrade to a new Megaco version without affecting service?
It is mentionned in RFC3015 that Protocol version negotiation can be done at Restart, Failover, and Handoff serviceChanges. It is not mentionned explicitly how version protocol re-negotiation is done after the MG has registered with the MGC. in both situation
This could be done in at least two different ways as listed bellow.
1- Protocol version negotiation could be initiated using the Failover serviceChange. A Failover serviceChange with a protocol version would indicate that the MG has been configured with a new H.248 protocol version. Sent from the MG to the MGC, it indicates that the MG has been configured with a new H.248 protocol version. This serviceChange shall not indicate Failure of the working MG. This would require that for non-redundant MGs, both the primary IP address and the secondary IP address be the same.
2- Protocol version negotiation could be intiated using a new serviceChange method: VersionNegotiation (Method 7 of the serviceChange command as defined in RFC3015) This serviceChange would be sent from the MG to the MGC to initiate protocol version initiation. It indicates that the MG has been configured with a new H.248 protocol version. Sent from the MGC to the MG, it indicates that the MGC has been configured with a new H.248 protocol version.
Comments please. Nancy
-- Nancy Devin Software Designer
Alcatel 600 March Road, P.O. Box 13600 Kanata, Ontario, Canada K2K 2E6
Telephone: (613) 591-3600 x6897 Fax: (613) 599-3609 Internet: nancy.devin@alcatel.com
Good morning Michael,
In RFC3015, section 7.2.8, it is mentionned that the serviceChangeAddress parameter specifies the address (IP port number) to be used. Can this also contain an IP address? In which cases is it using an IP address and in which cases is it using an IP port? Could it also take other values?
thanks, Nancy
Michael Brown wrote:
Nancy,
The parameter that would be used is be the ServiceChangeAddress. As far as the assumption that the MGC would be provisioned with the primary and secondary MGs, certainly it could be done that way (and the text in 11.4 does imply this), but I do think that passing the address is an acceptable approach and should certainly be allowed.
IMO we don't really need a new method for this. I don't see how adding a new method is more efficient. I still would contend that adding a ServiceChangeReason is sufficient and that it is desirable to do so (at least in V.2).
Michael
-----Original Message----- From: Nancy Devin [mailto:nancy.devin@alcatel.com] Sent: Tuesday, February 27, 2001 1:07 PM To: Brown, Michael [NC1:GW10:EXCH] Cc: ITU-SG16 Mail List; megaco@fore.com Subject: Re: Protocol version re-negotiation
Hi Mike,
I don't understand why your are talking about passing the address of the secondary MG to the MGC during a Failover. My understanding is that the MGC is configured with both the primary MG address and the secondary MG address (even though I did not find any text on that). If that is not the case then which parameter is used to transmit the address the the MGC.
Also, I think the idea of having to Handoff to another MG or Failover to the other MG may not be the most efficient one. If we are to add a new reason then why not also add a new method which would be "VersionNegotiation"
Method: VersionNegotiation TerminationID: Root Reason: MG directed change / MGC directed change Description: Sent from the MG to the MGC, the MG initiates a protocol version negotiation. Sent from the MGC to the MG, the MGC initiates a protocol version negotiation.
Nancy
Michael Brown wrote:
Comments inline.
Michael
"Rosen, Brian" wrote:
I think you missed one point: "How does a
NON-redundant MG
upgrade to a new version of the protocol?"
It comes down, reboots, and comes up again -
it's a service affecting
change. AFAIK, that's the only way today.
<MB> Yes, if the MG is really Non-redundant
there doesn't seem to be an option.
Can the MG Failover to itself? Will this
cause any problems
in the MGC?
Since that's not a defined option, some MGCs
might have a problem.
<MB> While there is no existing text
specifically saying that this is allowed.,
there also is none that disallows this
behavior. It seems to me that the MGC
should just accept the "new" address for the
"secondary" MG and go on. This
would be used when an MG and its mate hide
behind a single address for the MGC
<> MG control association. I would think that
this could easily be added to the
implementor's guide and I don't think that it
should cause problems.
To allow this requires only a few changes
to the text in RFC3015 as
follows: Section 7.2.8 ServiceChange Modify text: "6) Failover - sent from MG
to MGC to indicate
the primary MG is out of service and a secondary is
taking over, or to indicate a
version negotiation from the MG." Add a Reason: "Version Negotiation" or a
more generic "MG Directed
Change". Add text: "The MG may initiate a version
negotiation with a
ServiceChange Command specifying the
"Root" for the TerminationID,
ServiceChangeMethod equal to Failover and
ServiceChangeReason equal to
"Version Negotiation"."
I think that's a scope add, which I for one
am reluctant to do.
If there was a real problem with something
we already had, that's one thing,
but a real feature add, I'm less thrilled
about. I'll admit some of the
things we have talked about stray at least close,
if not over such a line. Here,
I think an MG that can do a non-service
affecting upgrade which is not
redundant is pretty unusual these days - I
don't mean to discourage folks
from doing that, but I also don't feel we
need changes in semantics (and
some additional syntax, albeit some IANA
registrations) to make it happen,
it can wait for V2.
<MB> I'm suppose I'd agree that this propoal
is adding a new feature as it would
require a new, IANA registered reason and the
associated behavior. I'd say it's
somewhat unfortunate because basically, I
don't see problems with the proposed
approach. There is one thing about the
approach that bothers me which we might
consider for V2. That is, the use of Failover
in this instance seems
inappropriate. The name just seems to imply
that a software upgrade is a failure
scenario. I would suggest that it would be
nicer to enhance the definition of
Handoff rather than Failover since handoff
implies a more graceful transition.
Given the current definitions of Handoff and
Failover in version 1, we do have
to live with Failover for now.
Cheers, Paul
"Rosen, Brian" wrote:
It's unlikely that we will do anything
that adds
new features by edits to the
implementor's guide.
It's reasonable to have explanatory text
in such a
document that is not normative.
I think you failover, upgrade, and
failover back
with this version of the protocol.
Brian
-----Original Message----- From: Paul Rheaume
[mailto:paul.rheaume@alcatel.com]
Sent: Thursday, February 22, 2001 1:00
PM
To: ITU-SG16 Mail List Cc: megaco@fore.com Subject: Re: Protocol version
re-negotiation
Folks,
Where is the appropriate list to
discuss this issue?
We feel that version negotiation and
the version upgrade
process is not well specified and needs to be
discussed and properly
defined at the
latest in version 2 of the
specification. That means
looking at this
very soon.
I think this issue belongs to the next
version of the
Implementor's
Guide.
Regards, Paul
Nancy Devin wrote: > > How does a non-redundant MG upgrade
to a new
> Megaco version without affecting
service? How
> does a redundant MG upgrade to a new
Megaco
> version without affecting service? > > It is mentionned in RFC3015 that
Protocol version
> negotiation can be done at Restart,
Failover, and
> Handoff serviceChanges. It is not
mentionned
> explicitly how version protocol
re-negotiation is
> done after the MG has registered
with the MGC. in
> both situation > > This could be done in at least two
different ways
> as listed bellow. > > 1- Protocol version negotiation
could be
> initiated using the Failover
serviceChange. A
> Failover serviceChange with a
protocol version
> would indicate that the MG has been
configured
> with a new H.248 protocol version.
Sent from the
> MG to the MGC, it indicates that the
MG has been
> configured with a new H.248 protocol
version.
> This serviceChange shall not
indicate Failure of
> the working MG. This would require
that for
> non-redundant MGs, both the primary
IP address and
> the secondary IP address be the
same.
> > 2- Protocol version negotiation
could be
> intiated using a new serviceChange
method:
> VersionNegotiation (Method 7 of the
serviceChange
> command as defined in RFC3015) This
serviceChange
> would be sent from the MG to the MGC
to initiate
> protocol version initiation. It
indicates that
> the MG has been configured with a
new H.248
> protocol version. Sent from the MGC
to the MG, it
> indicates that the MGC has been
configured with a
> new H.248 protocol version. > > Comments please. > Nancy
-- Nancy Devin Software Designer
Alcatel 600 March Road, P.O. Box 13600 Kanata, Ontario, Canada K2K 2E6
Telephone: (613) 591-3600 x6897 Fax: (613) 599-3609 Internet: nancy.devin@alcatel.com
-- Nancy Devin Software Designer
Alcatel 600 March Road, P.O. Box 13600 Kanata, Ontario, Canada K2K 2E6
Telephone: (613) 591-3600 x6897 Fax: (613) 599-3609 Internet: nancy.devin@alcatel.com
G'Day,
There's been a few points raised in this thread. It seems to me that people are getting a "protocol version upgrade of Megaco" and an "upgrade of the MG" mixed up. I don't see the need for bringing down the whole MG just to update the Megaco interface. We have protocol version negotiation procedures H.248 sect 11.3. We can issue a ServiceChange with the new version number, method "warm boot" and "restart" and not loose state on the MG. See Annex L -
3.4 Reason # : 902 Name: Warm Boot Definition: This indicates that the entity indicated with the TerminationID is in ServiceState "in-Service", and that it has gone through a start or recovery action. All transactions in process may be lost, but otherwise all state is preserved on the termination. Reference: - Text in the Service Change extension: - Comment: This reason code only applies for TerminationID root.
So I don't see what the issue is.
Any new functionality to add new methods is really something for H248v2.
Cheers, Christian
Michael Brown wrote:
Nancy,
The parameter that would be used is be the ServiceChangeAddress. As far as the assumption that the MGC would be provisioned with the primary and secondary MGs, certainly it could be done that way (and the text in 11.4 does imply this), but I do think that passing the address is an acceptable approach and should certainly be allowed.
IMO we don't really need a new method for this. I don't see how adding a new method is more efficient. I still would contend that adding a ServiceChangeReason is sufficient and that it is desirable to do so (at least in V.2).
Michael
-----Original Message----- From: Nancy Devin [mailto:nancy.devin@alcatel.com] Sent: Tuesday, February 27, 2001 1:07 PM To: Brown, Michael [NC1:GW10:EXCH] Cc: ITU-SG16 Mail List; megaco@fore.com Subject: Re: Protocol version re-negotiation
Hi Mike,
I don't understand why your are talking about passing the address of the secondary MG to the MGC during a Failover. My understanding is that the MGC is configured with both the primary MG address and the secondary MG address (even though I did not find any text on that). If that is not the case then which parameter is used to transmit the address the the MGC.
Also, I think the idea of having to Handoff to another MG or Failover to the other MG may not be the most efficient one. If we are to add a new reason then why not also add a new method which would be "VersionNegotiation"
Method: VersionNegotiation TerminationID: Root Reason: MG directed change / MGC directed change Description: Sent from the MG to the MGC, the MG initiates a protocol version negotiation. Sent from the MGC to the MG, the MGC initiates a protocol version negotiation.
Nancy
Michael Brown wrote:
Comments inline.
Michael
"Rosen, Brian" wrote:
I think you missed one point: "How does a NON-redundant MG upgrade to a new version of the protocol?"
It comes down, reboots, and comes up again - it's a service
affecting
change. AFAIK, that's the only way today.
<MB> Yes, if the MG is really Non-redundant there doesn't seem to be
an option.
Can the MG Failover to itself? Will this cause any problems in the MGC?
Since that's not a defined option, some MGCs might have a problem.
<MB> While there is no existing text specifically saying that this
is allowed.,
there also is none that disallows this behavior. It seems to me that
the MGC
should just accept the "new" address for the "secondary" MG and go
on. This
would be used when an MG and its mate hide behind a single address
for the MGC
<> MG control association. I would think that this could easily be
added to the
implementor's guide and I don't think that it should cause problems.
To allow this requires only a few changes to the text in RFC3015
as
follows: Section 7.2.8 ServiceChange Modify text: "6) Failover - sent from MG to MGC to indicate the primary MG is out of service and a secondary is taking over, or to
indicate a
version negotiation from the MG." Add a Reason: "Version Negotiation" or a more generic "MG
Directed
Change". Add text: "The MG may initiate a version negotiation with a ServiceChange Command specifying the "Root" for the
TerminationID,
ServiceChangeMethod equal to Failover and ServiceChangeReason
equal to
"Version Negotiation"."
I think that's a scope add, which I for one am reluctant to do. If there was a real problem with something we already had, that's
one thing,
but a real feature add, I'm less thrilled about. I'll admit some
of the
things we have talked about stray at least close, if not over such a
line. Here,
I think an MG that can do a non-service affecting upgrade which is
not
redundant is pretty unusual these days - I don't mean to
discourage folks
from doing that, but I also don't feel we need changes in
semantics (and
some additional syntax, albeit some IANA registrations) to make it
happen,
it can wait for V2.
<MB> I'm suppose I'd agree that this propoal is adding a new feature
as it would
require a new, IANA registered reason and the associated behavior.
I'd say it's
somewhat unfortunate because basically, I don't see problems with
the proposed
approach. There is one thing about the approach that bothers me
which we might
consider for V2. That is, the use of Failover in this instance seems
inappropriate. The name just seems to imply that a software upgrade
is a failure
scenario. I would suggest that it would be nicer to enhance the
definition of
Handoff rather than Failover since handoff implies a more graceful
transition.
Given the current definitions of Handoff and Failover in version 1,
we do have
to live with Failover for now.
Cheers, Paul
"Rosen, Brian" wrote:
It's unlikely that we will do anything that adds new features by edits to the implementor's guide. It's reasonable to have explanatory text in such a document that is not normative.
I think you failover, upgrade, and failover back with this version of the protocol.
Brian
-----Original Message----- From: Paul Rheaume [mailto:paul.rheaume@alcatel.com] Sent: Thursday, February 22, 2001 1:00 PM To: ITU-SG16 Mail List Cc: megaco@fore.com Subject: Re: Protocol version re-negotiation
Folks,
Where is the appropriate list to discuss this issue?
We feel that version negotiation and the version upgrade process is not well specified and needs to be discussed and properly
defined at the
latest in version 2 of the specification. That means
looking at this
very soon.
I think this issue belongs to the next version of the
Implementor's
Guide.
Regards, Paul
Nancy Devin wrote: > > How does a non-redundant MG upgrade to a new > Megaco version without affecting service? How > does a redundant MG upgrade to a new Megaco > version without affecting service? > > It is mentionned in RFC3015 that Protocol version > negotiation can be done at Restart, Failover, and > Handoff serviceChanges. It is not mentionned > explicitly how version protocol re-negotiation is > done after the MG has registered with the MGC. in > both situation > > This could be done in at least two different ways > as listed bellow. > > 1- Protocol version negotiation could be > initiated using the Failover serviceChange. A > Failover serviceChange with a protocol version > would indicate that the MG has been configured > with a new H.248 protocol version. Sent from the > MG to the MGC, it indicates that the MG has been > configured with a new H.248 protocol version. > This serviceChange shall not indicate Failure of > the working MG. This would require that for > non-redundant MGs, both the primary IP address and > the secondary IP address be the same. > > 2- Protocol version negotiation could be > intiated using a new serviceChange method: > VersionNegotiation (Method 7 of the serviceChange > command as defined in RFC3015) This serviceChange > would be sent from the MG to the MGC to initiate > protocol version initiation. It indicates that > the MG has been configured with a new H.248 > protocol version. Sent from the MGC to the MG, it > indicates that the MGC has been configured with a > new H.248 protocol version. > > Comments please. > Nancy
-- Nancy Devin Software Designer
Alcatel 600 March Road, P.O. Box 13600 Kanata, Ontario, Canada K2K 2E6
Telephone: (613) 591-3600 x6897 Fax: (613) 599-3609 Internet: nancy.devin@alcatel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Christian Groves -
Michael Brown -
Nancy Devin