Subject: RC registration was: cic registration

From: [email-masked]
Date: Wed, 26 Sep 2001 15:45:29 +0300

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]

---

From: Schmidt Andre <[email-masked]>
Date: Wed, 26 Sep 2001 16:30:46 +0200

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,

John

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 10:02:36 -0500

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)
> 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]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Schmidt Andre <[email-masked]>
Date: Thu, 27 Sep 2001 16:26:44 +0200

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,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: Greg Sidebottom <[email-masked]>
Date: Fri, 28 Sep 2001 02:20:41 -0400

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.

-----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

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.
> 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.

---