Subject: [Sigtran] [m3ua] multiple RC's

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Tue, 17 Dec 2002 01:58:47 -0600 (CST)

Brian,Tolga and others,

This thread was already discussed.
[i went through your previous mails but still my doubt is not clear]

Can an AS have multiple RCs?
If your answer is 'no' then please see the example below.

  SG1                       AS1
 +-----+                 +-----+
 |SGP  |-----------------| ASP |
 +-----+                 +-----+
 1-1-1                    2-2-2

ASP registers RK1(3-3-3,4-4-4,5-5-5) with SGP
SGP returns RC1.

Now at ASP we configure the databse to add some more DPCs(6-6-6,7-7-7)

If you want to keep single RC (RC:AS) for AS1 then we will de-register 
previous DPCs and register all DPCs together.

Do you think it is a good method?

If we allow multiple RCs per AS so that we can avoid sending de-register 
message.

At SGP table may look this and 1:1:1 (RK:RC:AS) relationship is false.

RK-RC table
-----------
RK1 RC1
RK2 RC2

AS-RC table
-----------
AS1  RC1,RC2

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Dec 2002 02:09:17 -0700

Samuel,

This was discussed in Sept/Oct of 2001 under the thread "CIC registration".
A procedure for the ASP to update that routing key associated with a given
RC was proposed (and adopted by SUA but not M3UA).  In SUA you will see the
text in section 4.4.1:

   An ASP MAY modify an existing Routing Key by including a Routing 
   Context parameter in the REG REQ.  If the SGP 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.  A Registration Response "Routing Context 
   Registionation Refused" is returned if the SGP does not accept the 
   modification of the Routing Key. 

And the error code in section 3.9.12

            0x17      Routing Key Change Refused 

(But strangely, there is no Routing Context parameter in the Routing Key
necessary to support this procedure.  SUA-14 should be corrected to include
Routing Context as a optional parameter in the Routing Key. see below)

M3UA missed this update which was identified by Nitin in May in the thread:
"Dynamic CICs addition/deletion to an existing AS".

It is clear that CICs in particular cannot be managed without this capability.

It appears that it just slipped through the cracks for M3UA.

I would propose that the IG include the following:

----------------------------------------------------------------------------

  Problem Statement:
  ------------------

  It was intended that the ASP be able to alter an existing routing key.
  This text was missed in the M3UA final draft.  This change provides
  the missed text.

  Section 3.6.1 New Text:
  -----------------------

@@ -2761,6 +2761,8 @@
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Network Appearance (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Routing Context (optional)                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |

  Section 3.6.1 New Text:
  -----------------------

@@ -2876,6 +2878,20 @@
       |                     Network Appearance                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
+   Routing Context:
+
+      The optional Routing Context parameter field identifies an
+      existing Routing Key at an SGP for which the ASP is requesting
+      a modification (see Section 4.4.1).
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Tag = 0x0006          |         Length = 8            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Routing Context                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
    Service Indicators (SI): n X 8-bit integers
 
       The optional SI [7,8] field contains one or more Service

  Section 3.8.1 Changed Text:
  ---------------------------

@@ -3604,7 +3620,7 @@
       0x14      Destination Status Unknown
       0x15      Invalid Network Appearance
       0x16      Missing Parameter
-      0x17      Not Used in M3UA
+      0x17      Routing Key Change Refused
       0x18      Not Used in M3UA
       0x19      Invalid Routing Context
       0x1a      No Configured AS for ASP

  Section 4.4.1 New Text:
  -----------------------

@@ -4913,6 +4929,14 @@
    related SS7 Signalling Network Management messaging, if this did not
    previously start upon the ASP transitioning to state ASP-INACTIVE
 
+   An ASP MAY modify an existing Routing Key by including a Routing
+   Context parameter in the REG REQ.  If 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.  A Registration Response "Routing Context
+   Registration Refused" is returned if the SGP does not accept the
+   modification of the Routing Key.
+
 4.4.2 Deregistration
 
    An ASP MAY dynamically deregister with an SGP as an ASP within an

----------------------------------------------------------------------------

This problem really only exists for CIC because there are potentially
10's of thousands of CIC changes required with churn.  For your example,
the process could simply register another AS and exchange messages with
both AS.

For point code churn this is a simpler approach.  For CIC or GTT churn,
however, a separate RC value and AS for each change is not practical.

--brian

Samuel Dur D. Jeyaseelan wrote:                    (Tue, 17 Dec 2002 01:58:47)

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