Subject: AW: RC registration was: cic registration

From: Schmidt Andre <[email-masked]>
Date: Mon, 1 Oct 2001 14:10:31 +0200

Hello Greg,

It seems,  that  you  misunderstood  our last  comment  concerning  the  online
change of RKs. Excuse our unclear description. 

- The goal of our proposal is, to use the currently defined M3UA mechanisms as far as possible.
- The additional RC field within the REGREQ as proposed by Brian is necessary.
- Automatic ASP-to-ASP protocol may always be used OPTIONAL, but should never be a MUST.
- RK online changes not limited to CIC ranges.

Let's distinguish between different situations.

   1) SG doesn't support dynamic configuration, ASPs use DYNREG.
In this case online change of a RK is allowed, if only one ASP is registered.
At SG and ASP the new RK exist beside the current registered one.
The complete new RK will be sent within the DYNREG.
If more ASPs are registered, the SG send a negative REGRSP concerning the
received REGREQ. If more ASPs are registered, they have to unregister before
the last registered ASP requests the RK change.
If the new RK within the REGREQ doesn't match to the corresponding new RK stored
within the SG, the SG response with a negative REGRSP and the previously valid RK
will be still used.
If the new RK matches the new RK within the SG, it will be taken as the new
registered RK and the previous RK will be deleted. The SG send a positive REGRSP to the ASP.
On reception of the positive REGRSP, the ASP deletes the previous registered RK and takes the
new RK instead.
Following ASPs register to this RK with a REGREQ without RC, because they want to connect
to an existing RK.

   2) SG support dynamic configuration, ASPs use DYNREG.
In this case online change of a RK is allowed, if only one ASP is registered.
At the ASP the new RK exist beside the current registered one.
The complete new RK will be sent within the DYNREG.
If more ASPs are registered, the SG send a negative REGRSP concerning the
received REGREQ. If more ASPs are registered, they have to unregister before
the last registered ASP requests the RK change.
If the new RK within the REGREQ makes problems (overlapping...) with existing RKs stored
within the SG, the SG response with a negative REGRSP and the previously valid RK
will be still used.
If the new RK is OK, it will be taken as the new
registered RK and the previous RK using the same RC will be deleted.
The SG sends a positive REGRSP to the ASP.
On reception of the positive REGRSP, the ASP deletes the previous registered RK and takes the
new RK instead.
Following ASPs register to this RK with a REGREQ without RC, because they want to connect
to an existing RK.

Reason: Supports a robust solution. Because #7 databases are normaly changed at times
of low traffic load, the reduction to 1 remaining ASP concerning a RK shouldn't make
any problems. Currently no big changes are necessary within the M3UA protocol. It is
an easy way to keep the RKs between different ASPs consistent. A M3UA protocol
enhancement, which allows online change of RKs for several registered ASP,
will be much more complicated in all possible situations, to keep the consistency
of RK data of different ASPs.

There are some more situations to discuss like the following:
A SG has a registered RK, which was built by dynamic configuration. Now a second ASP
without support of dynamic registration, wants to be connected to the same RK at the
same SG.

We think, that our proposal may be a stable basic solution for online change of RKs.
Future M3UA protocol enhancements and/or automatic ASP-to-ASP protocols are never
prohibited by this proposal.

with kindest regards 

                     Andrè

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Freitag, 28. September 2001 08:21
An: sigtran
Betreff: Re: RC registration was: cic registration

Greetings Andre,

It seems at the beginning of your message that you disagreed to adding RC In
the REG REQ to change the RK without also adding your procedure to reduce to
one ASP, as this would mandate the use of an ASP-to-ASP protocol.   I
disagreed with that conclusion but by the time I read right to the end of
your message I interpreted that you agreed to add the RC to the REG REQ (as
long as the included RK should be the complete new one).  This seems fine by
me so no point arguing.

But I am confused as to whether you (or others) would see the need for a
Notify from the SG to the other ASPs that did not send the REG REQ.   When
the initiating ASP gets the successful REG RSP, it now knows to flip from
using the "old" to the "new" RK configuration - but the other ASPs are in
the dark as to whether the SG has accepted the new configuration and may now
already be receiving traffic for the "new" configuration.   If there is an
ASP-to-ASP protocol then yes the initiating ASPs can inform the others to
make the change but there could be a delay and some traffic discard at the
other ASPs (for the new range component) until they are synched.  If there
is no ASP-to-ASP protocol (or it is down), then maybe an AS configuration
management system (or craftsperson) can take action.  But in my head, the
Notify to the other ASPs could minimize message loss on the RK configuration
change, because the SG notifies them directly before starting traffic for
the "new" RK.  Note that the Notify is not intended to inform the ASPs of
the new configuration, but to trigger the change from the "old" to the "new"
RK, both of which are known already.

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, September 27, 2001 10:26 AM
Subject: AW: RC registration was: cic registration

Hallo Brian,

Considering complexity and flexibility, I think it is the wrong way to
notify ASP about Routing Key changes.

Up to now the M3UA protocol (as a client/server architecture) was for good
reason, independent from any ASP to ASP communication.
An ASP-to-ASP protocol was declared as "MAY use" respectively "nice to
have".  The implementation of M3UA has permitted up to now to process this
new signaling protocol without an ASP-to-ASP protocol.

Consider the case that ASP's produced by different manufactures intend to
share traffic from one common SG for the same RK. A new additional internal
specification for the "ASP-to-ASP" protocol would be necessary.  It is new
that an ASP, which did not request more traffic before, is informed about
the expanding of the processed traffic with a NOTIFY and has immediately to
handle this new data range.

The ASP would not be in STANDBY or a similar state, in which it is prepared
for the new data range. Therefore the ASP-to-ASP protocol would not be
further optional. It would be an important tool to safeguard data
consistence between different ASP, because then an ASP must know the
configuration states from all other ASP's in this RoutingKey.

It could happen, that in the moment when an ASP is modifying the RK, one
association to a member ASP, belonging to this RK, is disturbed. If it would
not be informed over the intern ASP-to-ASP protocol misunderstanding in the
new activation respectively registration process are unavoidable.

Also for the normal process, where the NOTIFY messages will not be
acknowledge, it would be a must for the future to update ASP data fields
continuously.
It is visible, that a lot of new requirement regarding the intern ASP-to-ASP
protocols are necessary. With other words the implementation of M3UA without
relation to any other, up to now not available, specification is
unavoidable.
If the requirement below would be set to valid in M3UA all necessary steps,
described above, are not necessary.

> Modify Requests for a Routing Key, which is processed by more than one
ASP's (independent which type of Traffic Mode is used), must be rejected by
the SG.

This requirement is the guarantee for consistency data fields within all
ASP's belonging to one RK without developing a new ASP-to-ASP protocol. But
of course, the use of any ASP-to-ASP protocol would not be influenced by our
proposal.

One the other hand, the possibility to change RK-data should not be reduced
on CIC-Ranges. Nobody knows what else will be necessary in the future. We
suggest to use a modify request instead of an add- and delete request. So
forget our proposal from yesterday.

Only the new parameter (that means the existing RK will be completely
replaced by the new received RK) should be included together with the RC in
the REG REQ. If for example an existing OPC-List should be adapted in the
manner that some OPC should be removed and some other added, only one REG
REQ is necessary instead of two REG messages otherwise.

With kind regards ... Andrè

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 26. September 2001 17:03
An: sigtran
Cc: [email-masked]
Betreff: Re: RC registration was: cic registration

Andre,

What is accomplished by having ASP1 and 2 deregister just to
register back again against the expanded RK?  Why should not
ASP3 notify ASP1 and 2 of the change before one of them requests
that the SG expand the key.

It is not the SG's responsibility to ensure that the ASPs have
properly coordinated amoungst themselves.

Consider that ASP1, 2 and 3 have been provisioned with the
state machines and datafill necessary to handle CICs 301-400.
Why should not only one of them register for the expansion?

--brian

Schmidt Andre wrote:                                      (Wed, 26 Sep 2001
16:30:46)
> Up to now our team was participated on this interesting discussion only as
a listener. So we will not appear impolite to start participating before to
say hallo to all members of sigtran.
>
>
> Let us consider the case that the RK in the SG is used in Traffic Mode
"load sharing" for more than one ASP. What should happen if the SG is
receiving a REG REQ for this RK from one of the possible ASP's to expand the
included CIC-Range?
> A Routing Key would not uniquely define a range of signaling traffic if
the ASP's within this Routing Key would process different CIC-Ranges.
>
>
> New Requirements:
>
> Add - or Delete Requests for a Routing Key, which is processed by more
than one ASP's (independent which type of Traffic Mode is used), must be
rejected by the SG.
>
>
> To make our suggestion more illustrated see the configuration below.
>
>   -------------+
>               | --- ASP1(RK1,RC1) --- CIC   1-300
>               |
>        SG    | --- ASP2(RK1,RC1) --- CIC   1-300
>               |
>               | --- ASP3(RK1,RC1) --- CIC   1-300
>               |
>               |
> --------------+
>
> All three ASP's working in TM "load sharing" are handling the CIC Range
1-300.
> The assumption goal is to expand the treated CIC-Range to 1-400.
> At first ASP2 and ASP3 has to deregistrate themselves for RK1. Immediate
after this, ASP1 should send a REG REQ with the additional TAG "Routing
Context =1"  (already described by Brian) and the new additional CIC-Range
(301-400). This should happen in active state so that the traffic over the
last ASP will not be influenced. Immediate after this, ASP2 and ASP3 has to
registrate themselves with the new RK (that means CIC Range 1-400).
Necessary coordination between the involved ASPs is out of scope.
>
> In this way every ASP is able to decide about the traffic to be treated by
itself. Differences concerning RK data between SG and ASP will be avoided.
>
> In our point of view by using this way, all actual requirements for
RK-modification should be realized.
>
> Andrè
>
>
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Mittwoch, 26. September 2001 14:45
> An: sigtran
> Betreff: RC registration was: cic registration
>
>
> Hi Greg,
>
> > I think there are problems for many SGs to implement this as
> > IMHO it gets into all kinds of configuration issues and policies,
> > but I could go for the addition (i.e., optional RC to indicate an
> > AS configuration change request) in the protocol to allow it.
> > Your proposal looks pretty clean - I think we need a little more
> > text on the ASP and SG procedures to support the optional
> > procedure and a more descriptive refusal reason(s) for disallowing a
> > configuration change request.   But I'm generally supportive
> > as long as people think this configuration change function is going
> > to be used in real networks.
>
> Agreed - if this is something useful, we can consider it for both
> SUA & M3UA.  I think common text could be used.
>
> Additionally, an error message "Routing Context Registionation Refused"
> or something like to indicate that the SG did not accept it is
> needed.
>
> > Still thinking...
> >
> >    - Do we need something from the SG to the other ASPs (Notifies?) to
> > confirm the change or can we rely on our infamous ASP-ASP
> > protocol or an external AS configuration management protocol to handle
> > this.
>
> >    - I assume that an SG refusal of the REG REQ would imply that the
> > previous RK still stands.  We probably need some ASP text to make this
> > clear.
>
> Agreed.  The text in 4.4.1 could say that "In the case of the refusal of
> additional
> REG REQ attempts, the existing set of Routing Keys remain valid."
>
> John
>
>

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 1 Oct 2001 13:07:17 -0400

Thanks for your patience Andre,

Responses below ..

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, October 01, 2001 8:10 AM
Subject: AW: RC registration was: cic registration

Hello Greg,

It seems,  that  you  misunderstood  our last  comment  concerning  the
online
change of RKs. Excuse our unclear description.

- The goal of our proposal is, to use the currently defined M3UA mechanisms
as far as possible.
- The additional RC field within the REGREQ as proposed by Brian is
necessary.
- Automatic ASP-to-ASP protocol may always be used OPTIONAL, but should
never be a MUST.
- RK online changes not limited to CIC ranges.

[Greg] I certainly agree with your goals.

In this case online change of a RK is allowed, if only one ASP is
registered.

[Greg] The last two sentances is where we differ - see below.

If the new RK within the REGREQ doesn't match to the corresponding new RK
stored
within the SG, the SG response with a negative REGRSP and the previously
valid RK
will be still used.
If the new RK matches the new RK within the SG, it will be taken as the new
registered RK and the previous RK will be deleted. The SG send a positive
REGRSP to the ASP.
On reception of the positive REGRSP, the ASP deletes the previous registered
RK and takes the
new RK instead.
Following ASPs register to this RK with a REGREQ without RC, because they
want to connect
to an existing RK.

[Greg] I'm still confused - I still don't see why the other ASPs registered
against the RK MUST de-activate de-register before the first ASP can change
to the new RK in a REG REQ.  I believe your argument is that otherwise an
ASP-to-ASP protocol is mandated (and no longer optional).  If my is
understanding is correct then my point is that a NOTIFY from the SG to the
other ASPs could avoid the requirement of an ASP-to-ASP protocol.  (Also I
think an AS configuration management system could handle this).

Note that your method of operation is still allowed - if an Operator prefers
to de-activate and de-register the other ASPs first then there is nothing
against that.  But to mandate this method seems too restrictive if there are
any AS/ASP implementations that can handle it gracefully..

   2) SG support dynamic configuration, ASPs use DYNREG.
In this case online change of a RK is allowed, if only one ASP is
registered.
At the ASP the new RK exist beside the current registered one.
The complete new RK will be sent within the DYNREG.
If more ASPs are registered, the SG send a negative REGRSP concerning the
received REGREQ. If more ASPs are registered, they have to unregister before
the last registered ASP requests the RK change.
If the new RK within the REGREQ makes problems (overlapping...) with
existing RKs stored
within the SG, the SG response with a negative REGRSP and the previously
valid RK
will be still used.
If the new RK is OK, it will be taken as the new
registered RK and the previous RK using the same RC will be deleted.
The SG sends a positive REGRSP to the ASP.
On reception of the positive REGRSP, the ASP deletes the previous registered
RK and takes the
new RK instead.
Following ASPs register to this RK with a REGREQ without RC, because they
want to connect
to an existing RK.

Reason: Supports a robust solution. Because #7 databases are normaly changed
at times
of low traffic load, the reduction to 1 remaining ASP concerning a RK
shouldn't make
any problems. Currently no big changes are necessary within the M3UA
protocol. It is
an easy way to keep the RKs between different ASPs consistent. A M3UA
protocol
enhancement, which allows online change of RKs for several registered ASP,
will be much more complicated in all possible situations, to keep the
consistency
of RK data of different ASPs.

[Greg] IMHO a Notify alleviates the concern you have - I don't see it as
very complicated.  In your preferred operations approach the Notify would
not be used anyway as there is only one ASP registered/active in the AS - so
no worries.  For ASPs employing ASP-to-ASP-protocols (a much more common
approach IMHO) I think the Notify may help in minimizing any potential
message loss (assuming the other ASPs are active).  These implementations
would not want to have the restriction that you propose (i.e., if other ASPs
are registered, they must be de-activated and de-registered before
proceeding)

There are some more situations to discuss like the following:
A SG has a registered RK, which was built by dynamic configuration. Now a
second ASP
without support of dynamic registration, wants to be connected to the same
RK at the
same SG.

[Greg] Yes there are sure to be difficulties in configuration management
when different ASPs in the AS have different configuration capabilities.
But intelligent SG vendors can probably solve this - assuming Operators will
want to do try it.   I don't know how we can expect the M3UA protocol to
solve all configuration problems.

We think, that our proposal may be a stable basic solution for online change
of RKs.
Future M3UA protocol enhancements and/or automatic ASP-to-ASP protocols are
never
prohibited by this proposal.

with kindest regards

                     Andrè

[Greg] It is indeed a stable operational approach but it seems too
restrictive for other implementations.

Cheers,

      Greg

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Freitag, 28. September 2001 08:21
An: sigtran
Betreff: Re: RC registration was: cic registration

Greetings Andre,

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, September 27, 2001 10:26 AM
Subject: AW: RC registration was: cic registration

Hallo Brian,

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 26. September 2001 17:03
An: sigtran
Cc: [email-masked]
Betreff: Re: RC registration was: cic registration

Andre,

--brian

1-300.

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Angermayr Manfred <[email-masked]>
Date: Tue, 2 Oct 2001 09:26:55 +0200

Hello!
My name is Manfred Angermayr. Up to know I have been following your M3UA discussions with interest. Now I decided to take part also actively ...

I have a bad feeling about these online Routing Key changes. According to the definition of the RK, a RK uniquely defines a range of signalling traffic handled by a particular Application Server. How can the RK be kept unique in the Signalling Gateway if it can be modified online by possibly many affected ASPs? You are right, this could be handled by an AS Configuration Management System, but nevertheless any SG implementation has to cope with all kind of situations, that are not controlled by such a system. The M3UA protocol itself has to describe all kind of error situations if the affected ASPs do not work coordinated by such a system.
Let's look for example at a configuration, where 3 ASPs are registered for the same RK in a loadsharing mode:
What happens, if 2 ASPs request different (contradictory) RK modifications quasi in parallel? How is it ensured, that the ASPs become not confused in this situation?
Your suggestion is to use a NOTIFY message to inform all concerned ASPs. Do you intend to include the complete new RK into the NOTIFY message?
With this online RK modification 1 ASP can change the traffic range that is processed by all other ASPs that are part of this AS. What happens if one of the other ASPs is not able to process this new range of traffic? Has this ASP any chance to refuse this modification? With this mechanism it is no longer under control of the ASP (client) what kind of traffic he wants to process.
NOTIFY messages are not acknowledged, so what should happen if the NOTIFY that indicates a RK modification is lost? How do the ASPs resynchronize?

For sure, all this situations could be handled by an AS Cofiguration Management System or by an ASP to ASP protocol. But  these are not part of M3UA, so we have to find answers within the M3UA protocol itself.
But probably you already have a solution for all these open questions, so I'am looking forward to read the next version of the M3UA draft!

Regards,
Manfred Angermayr

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Montag, 1. Oktober 2001 19:07
An: sigtran
Betreff: Re: RC registration was: cic registration

Responses below ..

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, October 01, 2001 8:10 AM
Subject: AW: RC registration was: cic registration

Hello Greg,

with kindest regards

                     Andrè

Cheers,

      Greg

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Freitag, 28. September 2001 08:21
An: sigtran
Betreff: Re: RC registration was: cic registration

Greetings Andre,

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, September 27, 2001 10:26 AM
Subject: AW: RC registration was: cic registration

Hallo Brian,

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 26. September 2001 17:03
An: sigtran
Cc: [email-masked]
Betreff: Re: RC registration was: cic registration

Andre,

--brian

1-300.

---

---

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 2 Oct 2001 14:10:27 +0200

Hi John, Greg,

I have the same concerns as Mr. Angermayr for SUA. Whatever solution is
found, there's always an overlap phase where both SG and ASP must support
existing calls/connections for the "old" RKs as well as new ones according
the new RKs.

I think there are too many open issues here and missing procedures in AS/ASP
management to support it. It will make interoperability again that much
harder.

I'm wondering whether there wouldn't be a more elegant solution where CIC is
removed from RK (in previous discussions this was already suggested), and
move this to the ASP(I)AC/ASP(I)AC_Ack messages. With this parameter, this
would allow the ASP to inactive for a CIC-subrange (after ASP blocking calls
on these), not for the entire RK (RK parameters are NEVER touched online);
the SG could then notify the other ASPs, which would then have the
opportunity to start handling calls by sending ASPAC for the same subrange.

The (multiple) SGs could then keep a clear dynamic management of it's CIC
allocation tables.

I'm sure there will still be some issues, but we at least should restrict
ourselves in solving the CIC problem, and not deal at this point with any
other change.

A similar procedure is going to be introduced in SUA for the TIDs/DRNs.

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Angermayr Manfred [mailto:[email-masked]]
Sent: dinsdag 2 oktober 2001 9:27
To: sigtran
Subject: AW: RC registration was: cic registration

Hello!
My name is Manfred Angermayr. Up to know I have been following your M3UA
discussions with interest. Now I decided to take part also actively ...

I have a bad feeling about these online Routing Key changes. According to
the definition of the RK, a RK uniquely defines a range of signalling
traffic handled by a particular Application Server. How can the RK be kept
unique in the Signalling Gateway if it can be modified online by possibly
many affected ASPs? You are right, this could be handled by an AS
Configuration Management System, but nevertheless any SG implementation has
to cope with all kind of situations, that are not controlled by such a
system. The M3UA protocol itself has to describe all kind of error
situations if the affected ASPs do not work coordinated by such a system.
Let's look for example at a configuration, where 3 ASPs are registered for
the same RK in a loadsharing mode:
What happens, if 2 ASPs request different (contradictory) RK modifications
quasi in parallel? How is it ensured, that the ASPs become not confused in
this situation?
Your suggestion is to use a NOTIFY message to inform all concerned ASPs. Do
you intend to include the complete new RK into the NOTIFY message?
With this online RK modification 1 ASP can change the traffic range that is
processed by all other ASPs that are part of this AS. What happens if one of
the other ASPs is not able to process this new range of traffic? Has this
ASP any chance to refuse this modification? With this mechanism it is no
longer under control of the ASP (client) what kind of traffic he wants to
process.
NOTIFY messages are not acknowledged, so what should happen if the NOTIFY
that indicates a RK modification is lost? How do the ASPs resynchronize?

For sure, all this situations could be handled by an AS Cofiguration
Management System or by an ASP to ASP protocol. But  these are not part of
M3UA, so we have to find answers within the M3UA protocol itself.
But probably you already have a solution for all these open questions, so
I'am looking forward to read the next version of the M3UA draft!

Regards,
Manfred Angermayr

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Montag, 1. Oktober 2001 19:07
An: sigtran
Betreff: Re: RC registration was: cic registration

Responses below ..

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, October 01, 2001 8:10 AM
Subject: AW: RC registration was: cic registration

Hello Greg,

with kindest regards

                     Andrè

Cheers,

      Greg

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Freitag, 28. September 2001 08:21
An: sigtran
Betreff: Re: RC registration was: cic registration

Greetings Andre,

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, September 27, 2001 10:26 AM
Subject: AW: RC registration was: cic registration

Hallo Brian,

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 26. September 2001 17:03
An: sigtran
Cc: [email-masked]
Betreff: Re: RC registration was: cic registration

Andre,

--brian

1-300.

---

---

---

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: [email-masked]
Date: Tue, 2 Oct 2001 15:23:50 +0300

Gery,

I am not a big fan of the Registration issue, as it does have a lot of 
potential issues.  My general suggestion is that the SG can reject
any REQ REQ it wants.

John

> From: ext Verwimp Gery [mailto:[email-masked]]
> Sent: 02 October, 2001 15:10
> To: sigtran
> Subject: RE: RC registration was: cic registration
> 
> 
> Hi John, Greg,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 2 Oct 2001 09:09:48 -0700 (PDT)

Folks,

Perhaps this is a good subject to hold for an
extension draft, we seem to be trying to pack
in a few more functions at the last minute.

Cheers,

L. Ong

--- Angermayr Manfred
<[email-masked]> wrote:
> Hello!
> My name is Manfred Angermayr. Up to know I have been
> following your M3UA discussions with interest. Now I
> decided to take part also actively ...
> 
> I have a bad feeling about these online Routing Key
> changes. According to the definition of the RK, a RK
> uniquely defines a range of signalling traffic
> handled by a particular Application Server. How can
> the RK be kept unique in the Signalling Gateway if
> it can be modified online by possibly many affected
> ASPs? You are right, this could be handled by an AS
> Configuration Management System, but nevertheless
> any SG implementation has to cope with all kind of
> situations, that are not controlled by such a
> system. The M3UA protocol itself has to describe all
> kind of error situations if the affected ASPs do not
> work coordinated by such a system.
> Let's look for example at a configuration, where 3
> ASPs are registered for the same RK in a loadsharing
> mode:
> What happens, if 2 ASPs request different
> (contradictory) RK modifications quasi in parallel?
> How is it ensured, that the ASPs become not confused
> in this situation?
> Your suggestion is to use a NOTIFY message to inform
> all concerned ASPs. Do you intend to include the
> complete new RK into the NOTIFY message?
> With this online RK modification 1 ASP can change
> the traffic range that is processed by all other
> ASPs that are part of this AS. What happens if one
> of the other ASPs is not able to process this new
> range of traffic? Has this ASP any chance to refuse
> this modification? With this mechanism it is no
> longer under control of the ASP (client) what kind
> of traffic he wants to process.
> NOTIFY messages are not acknowledged, so what should
> happen if the NOTIFY that indicates a RK
> modification is lost? How do the ASPs resynchronize?
> 
> For sure, all this situations could be handled by an
> AS Cofiguration Management System or by an ASP to
> ASP protocol. But  these are not part of M3UA, so we
> have to find answers within the M3UA protocol
> itself.
> But probably you already have a solution for all
> these open questions, so I'am looking forward to
> read the next version of the M3UA draft!
> 
> Regards,
> Manfred Angermayr
> 
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 2 Oct 2001 13:21:50 -0400

Thanks for your comments Manfred,

Responses below ...

----- Original Message -----
From: "Angermayr Manfred" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 02, 2001 3:26 AM
Subject: AW: RC registration was: cic registration

Hello!

[Greg] Welcome!

[Greg] I understand your bad feeling.  In past discussions, I have always
been nervous of putting configuration capabilities into the M3UA.  All kinds
of configuration possibilities, errors and mis-use can arise that
potentially complicate things.    The idea of a Registration procedure has
always been attractive but the fact that it allows the
creation/deletion/change of the configuration data in remote nodes is a
two-edged sword.  It introduces some convenience but also some danger.  That
said, I'm comfortable with the current Registration procedures in that they
could be controlled by a properly designed configuration management system.
ASPs cannot really be allowed to randomly create/delete RKs now and they in
the future also cannot be allowed to randomly change RKs.   Configuration
management must be able to control the M3UA Registration component with
coordination, authorization and sanity checks or we are doomed.  The ASPs
cannot even truly be independent - they have to be on the same page in their
configuration, at least with in an AS.  There are a lot of configuration
issues in creating/coordinating the configuration for a group of ASPs in an
AS, of which the Sigtran registration is in reality only a small part.  I
really don't want to see the M3UA protocol trying to control all the
possible configuration errors and mis-use.

[Greg] IMO here is no sane reason for the individual ASPs to request
different RK changes in parallel when they are loadsharing in the same AS.
I don't think we need to put M3UA controls in place to ensure that the ASPs
do not become confused - they are already insane.  The ASP/AS configuration
management must cover this.  The SG could do some things itself if faced by
this - the SG at least needs a way to refuse a change that it determines is
problematic.  Getting different RK change requests from each ASP in an AS in
quasi in parallel may fit the bill as problematic  2;^)

[Greg] I'm not married to the Notify idea - the idea is not completely
formed.  I intended that it merely informs the ASPs of the acceptance of a
change from old RK1 to vew RK2, a change for which the ASPs would already be
configured and ready to handle.  Again, the RK configuration change is only
a small part of the configuration changes at an AS to handle a new traffic
range.  So the RK could be optionally included in a Notify but I really
don't believe that the new RK can be a surprise to the ASP or it will fail.
As you illustrate, it is NOT going to work if the RK change is a
configuration surprise to the other ASPs.  Ultimate control has to reside in
AS configuration management.  If an AS receives a Notify of an RK
configuration change that it is unaware of then immediate management action
is necessary, not a little M3UA message to the SG.  SG authorization
procedures are also needed to ensure that all the ASPs are ready for a
change before any REG REQ is accepted.

Regards,
Manfred Angermayr

[Greg] Unfortunately, I don't have all the answers  2:^(

I agree that we need to discuss these issues and provide some M3UA guidance.
But, ultimately, I believe these are configuration issues.  In my view of
the world, the M3UA has some tools to affect the configuration that are
really under control of a configuration management system.  The
responsibility for preventing and reacting to insane requests must reside
with the configuration management system.  We can put some text in the M3UA
to cover some aspects of these cases but in the end all an SG can do in the
protocol is refuse the insane requests, based on the determination of the
management system.  If the SG doesn't detect an insane request and accepts
it, some or all of the traffic will probably fail at the ASPs independently
of any Notify from the SG, so I don't think the Notify is useful in that
sense

I'm not sure that I can put anything in Issue 9 text as I'm trying to get it
out tonight.  Pending discussion we could do something in Issue 9 as long as
it doesn't destabilize things.  We could possibly cover this with a later
extension draft as well.

Cheers,

   Greg Sidebottom

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Montag, 1. Oktober 2001 19:07
An: sigtran
Betreff: Re: RC registration was: cic registration

Responses below ..

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, October 01, 2001 8:10 AM
Subject: AW: RC registration was: cic registration

Hello Greg,

with kindest regards

                     Andrè

Cheers,

      Greg

-----Ursprüngliche Nachricht-----
Von: Greg Sidebottom [mailto:[email-masked]]
Gesendet: Freitag, 28. September 2001 08:21
An: sigtran
Betreff: Re: RC registration was: cic registration

Greetings Andre,

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Schmidt Andre" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, September 27, 2001 10:26 AM
Subject: AW: RC registration was: cic registration

Hallo Brian,

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 26. September 2001 17:03
An: sigtran
Cc: [email-masked]
Betreff: Re: RC registration was: cic registration

Andre,

--brian

1-300.

---

---

---

---

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 2 Oct 2001 17:17:51 -0400

Hi Gery,

Comments below ..

----- Original Message -----
From: "Verwimp Gery" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 02, 2001 8:10 AM
Subject: RE: RC registration was: cic registration

> existing calls/connections for the "old" RKs as well as new ones according

[Greg] This is a general problem with any configuration change, no matter
how it is initiated.   There can be live calls/transactions outstanding in
any configuration change.  Your proposal below has the same problem - you
just have a solution embedded ("the ASP blocks calls on the affected CIC
sub-range).  The key is that traffic is gracefully withdrawn from the
affected CIC range before initiating a configuration change.  When the
configuration change is completed successfully, traffic can then be ramped
up again (in your case by unblocking the trunks).

> opportunity to start handling calls by sending ASPAC for the same
subrange.

[Greg] This solution is for a completely different problem - it is to me
clearly a protocol proposal to change the load distribution within an
Application Server handling ISUP traffic.  It allows ASPs to tell the SGs
which CICs in the AS it want the traffic for (i.e., which trunks it
controls).   The blocking component allows handing off of trunk control
between the ASPs without having to worry about an outstanding
calls/transactions.

The proposal to change the RK with REG REQ would allow changes in the
overall range of circuits within the AS.  Changing the RK to exclude a CIC
range means that none of the ASPs in the AS will handle traffic for those
circuits. It also allows an extension to the range of circuits controlled.

I think these two solutions solve two complemetary problems. I actually see
a lot of value in solving the first problem and think we should persue it in
an extension draft - but not by overloading the ASP Inactive semantics.  A
new set of messgae would be better.

Cheers,

   Greg

---

---

From: Angermayr Manfred <[email-masked]>
Date: Thu, 4 Oct 2001 14:28:58 +0200

I think this is a good idea!
It is the right way first to finish the basic M3UA protocol and fix it in an RFC, to get some experience and then afterwards to think about additional features in an extension draft.

Regards,
Manfred Angermayr

-----Ursprüngliche Nachricht-----
Von: Lyndon Ong [mailto:[email-masked]]
Gesendet: Dienstag, 2. Oktober 2001 18:10
An: sigtran
Betreff: Re: AW: RC registration was: cic registration

Folks,

Cheers,

L. Ong

--- Angermayr Manfred

---

---