Subject: CIC registration

From: Reema yy <[email-masked]>
Date: Tue, 25 Sep 2001 14:35:56 +0000

Hi
Is it possible to delete a particular CIC range during time ASP is in 
service ?
Let's take this case:
ASP1 registers to SG1 for CIC range 1000-1500, 2000-2500, and later on
suppose we decide to remove 2000-2200 CIC range while processing traffic on 
2201-2500, then how to do that without impacting 2201-2500.

Thanks
Reema

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 12:18:47 -0400

Greetings Reema,

   This has come up before and the answer is that it is not currently
possible via the current registration procedures.  I imagine there are
probably some ways to get around this, depending on the capabilities of the
SG.  For instance, the RKs could be left alone and the loadbalancing
(load-distribution?) algorithm for the AS could be adjusted so that this ASP
no longer gets traffic related to CICs 2000 to 2200.  CIC range is already
noted as a possible input for the loadbalancing mechanism at the SG.  Or
perhaps an intelligent SG implementation could even allow the ASP to
re-register for CIC range 1000-1500 / 2201-2500 (splitting the old RK) and
then later de-register from the previous RK.

Cheers,

   Greg

----- Original Message -----
From: "Reema yy" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 25, 2001 10:35 AM
Subject: CIC registration

> 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: Tue, 25 Sep 2001 15:30:44 -0500

Greg,

What you describe is fine for deleting a range of CICs from
an existing RK, but does not work for adding a range of CICs
to an existing RK.

How about we add RC as an optional parameter to REG REQ so
that a smart SG can also allow the ASP to expand routing
keys on the fly?  This would be particularly useful for SUA
AMF as well...

It doesn't seem like too much to ask that the RC parameter
be provided in REG REQ as optional to support this OPTIONAL
procedure.

Add:

  The format of the Routing Key parameter is as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Local-RK-Identifier                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Traffic Mode Type                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Routing Context (optional)                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Network Appearance (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       SI (optional)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         SSN (optional)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Origination Point Code List (optional)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Circuit Range List (optional)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and add:

   If a Routing Context is provided in the REG REQ and the SG
   determines that the Routing Context applies to an existing Routing
   Key, the SG MAY adjust the existing Routing Key to match the new
   information provided in the Routing Key parameter.
   
Is there a problem with this?

--brian

Greg Sidebottom wrote:                      (Tue, 25 Sep 2001 12:18:47)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 18:05:12 -0400

Hi Brian,

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.

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.

Cheers,

     Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 25, 2001 4:30 PM
Subject: Re: CIC registration

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Sep 2001 20:17:13 -0500

Greg,

Greg Sidebottom wrote:                      (Tue, 25 Sep 2001 18:05:12)
> configuration change request.

Why do the refusal reasons need to be any different than the existing
registration reasons?  (which handle quite a few cases already)
New reasons could always be added in extension if necessary.

> But I'm generally supportive as long as people think this configuration
> change function is going to be used in real networks.

Changing CIC ranges in support of ISUP reconfiguration on a live system
has been requested from several directions.  That is its primary use.
I don't think that one will want to change SI's or DPCs in this manner.

> external AS configuration management protocol to handle this.

What are you worried about?  One ASP changing the RK out from under
another?  ASP to ASP coordination is certainly the domain of the
ASP-to-ASP protocol.

> previous RK still stands.  We probably need some ASP text to make this

Sounds reasonable.

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

---

---

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

Hi Brian,

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 25, 2001 9:17 PM
Subject: Re: CIC registration

> New reasons could always be added in extension if necessary.

[Greg2] I looked at the current reasons in the REG RSP and it didn't seem
clean.  In this case the SG is not refusing the registration, it is refusing
a change to the RK data.  I was thinking that the ASP that sent the REG REQ
is sitting on two RKs, the "old and the "new" one.   Its not a big deal but
I thought an explict reason of "Routing Key change refused" might be useful
to the management system at the ASP.

> I don't think that one will want to change SI's or DPCs in this manner.

[Greg2] OK

> another?  ASP to ASP coordination is certainly the domain of the

[Greg2] I was thinking that it could avoid some message loss.  If the SG
accepts the new RK it may start sending traffic for the new configuration to
all the ASPs in a loadshare group.  There may be some delay before the ASPs
other than the one that sent the REG REQ know that the SG has "accepted" the
new configuration.  The initiating ASP can switch immediately to the new RK
when it gets the successful REG RESP.  But there is some small time until
the other ASPs can be informed (ASP-to-ASP protocol, AS configuration
management system, whatever, ...).  The Notifies wouldn't preclude any
ASP-to-ASP coordination.

Cheers,

    Greg Sidebottom

> > > > probably some ways to get around this, depending on the capabilities
of
> > the
> > > > (load-distribution?) algorithm for the AS could be adjusted so that
this
> > ASP
> > > > re-register for CIC range 1000-1500 / 2201-2500 (splitting the old
RK)
> > and

---