RE: Protocol version re-negotiation

1 Mar 2001


      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:nancy.devin@alcatel.com]
Sent: Thursday, March 01, 2001 7:18 AM
To: Brown, Michael [NC1:GW10:EXCH]
Cc: ITU-SG16 Mail List; megaco@fore.com
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: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

Michael Brown

tags (0)

participants (1)