Subject: RE: Protocol version re-negotiation

From: "Michael Brown" <[email-masked]>
Date: Thu, 1 Mar 2001 16:08:39 -0500

Hi Nancy,

In 7.2.8, the reference to the value of the ServiceChange address says:

"...(e.g., IP port number for IP networks)..."

so that it is an example of what the value could be. Following is the ABNF
for what the value could be which I don't believe precludes any type of
addressing naming schema.

serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
VALUE                = quotedString / 1*(SafeChar) 
SafeChar             = DIGIT / ALPHA / "+" / "-" / "&" /  
                       "!" / "_" / "/" / "'" / "?" / "@" /  
                       "^" / "`" / "~" / "*" / "$" / "\" /  
                       "(" / ")" / "%" / "|" / "." 

Admittedly, the specific "appropriate" usage is not definitively specified.
I think it would be up to the MGC to evaluate the nature of the address.

Michael

-----Original Message-----
From: Nancy Devin [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 7:18 AM
To: Brown, Michael [NC1:GW10:EXCH]
Cc: ITU-SG16 Mail List; [email-masked]
Subject: Re: Protocol version re-negotiation

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:[email-masked]]
> Sent: Tuesday, February 27, 2001 1:07 PM
> To: Brown, Michael [NC1:GW10:EXCH]
> Cc: ITU-SG16 Mail List; [email-masked]
> 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:[email-masked]]
> > > > > > Sent: Thursday, February 22, 2001 1:00
> PM
> > > > > > To: ITU-SG16 Mail List
> > > > > > Cc: [email-masked]
> > > > > > 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:  [email-masked]
>

--
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:  [email-masked]

---

From: Nancy Devin <[email-masked]>
Date: Mon, 12 Mar 2001 11:47:23 -0500

Good morning Christian,

The reason why we had put this solution aside is that the RFC specifies
that version negotiation occurs at registration and possibly at failover
and handoff.

Since re-negotiation is done once the MG is registered with the MGC,  will
the serviceChange with the method "warm boot" and "restart" be considered a
registration request even though the MG is already registered?

Nancy

Christian Groves wrote:

> 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
> >
> > 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
> > 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"
> >
> > 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
> > > > It comes down, reboots, and comes up again - it's a service
> > affecting
> > > <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:
> > > > > 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
> > > > > 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
> > > > > > 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
> > > > > > I think you failover, upgrade, and failover back
> > > > > > > From: Paul Rheaume [mailto:[email-masked]]
> > > > > > > Sent: Thursday, February 22, 2001 1:00 PM
> > > > > > > To: ITU-SG16 Mail List
> > > > > > > Cc: [email-masked]
> > > > > > > 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
> > > > > > > > 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

--
Nancy Devin
Software Designer

Alcatel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 12 Mar 2001 10:41:10 -0500

> Sent: Wednesday, March 07, 2001 9:10 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> I agree with you that the reason "warm boot"
> describes perfectly the state of the MG when it
> upgrades to a new version of the H.248 protocol.
> 
> I have question on the use of "restart" and
> "root".  According the RFC3015, this combination
> indicates a registration command.  Since the
> registration command should be the first command
> received from an MG after it comes in service,
> what happens when this command is received while
> the MG is already in service?

[PTT] The MGC must interpret it as meaning that the MG is reregistering
after a warm boot.

[snip]