Subject: RE: [Sigtran] M3UA: More redundant RKM error codes

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Thu, 15 Jan 2004 16:21:33 +0100

That's right.

As I explained in a previous mail, the duplicate RK case we are talking about makes sense when an ASP registers a RK that it has previously registered. On the other hand, the overlapping RK detection includes a comparison with all the routing keys that have been previously registered by any ASP including the sending one. The reason for the latter is per section 1.4.2.2 as Barry says: "each received SS7 message SHOULD have a full or partial match to a SINGLE routing result". 

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Barry Nagelberg
> Sent: jueves, 15 de enero de 2004 16:12
> To: SIGTRAN Mailing List
> Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> 
> 
> Javier,
> 
> Brian is correct. I am wrong. Please use my original suggestion from
> yesterday, January 14.
> 
> Barry Nagelberg
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, January 15, 2004 10:03 AM
> > To: Barry Nagelberg
> > Cc: SIGTRAN Mailing List
> > Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> >
> >
> > Barry,
> >
> > Oh, so now you're going to send an error every time that an ASP
> > registers for an RK that another ASP has registered for?  Don't
> > be absurd.
> >
> > --brian
> >
> > Barry Nagelberg wrote:
> >                    (Thu, 15 Jan 2004 09:28:03)
> > > Javier,
> > >
> > > Oops, sorry - some minor corrections:
> > >
> > > 1. The registration request is an exact duplicate of a 
> registered RK.
> > > 2. The registration request partially overlaps a registered RK.
> > > 3. The ASP is requesting to modify a registered RK.
> > >
> > > I agree with you and Kamesh (and apparently with everyone 
> else except
> > > Brian), that there SHOULD NOT be more than one RK match per AS.
> > This is also
> > > stated in section 1.4.2.2 of the RFC - Routing Key Limitations.
> > >
> > > Barry Nagelberg
> > >
> > > > -----Original Message-----
> > > > From: J.Javier Pastor (ML/EEM) 
> [mailto:[email-masked]]
> > > > Sent: Thursday, January 15, 2004 4:40 AM
> > > > To: 'Barry Nagelberg'; SIGTRAN Mailing List
> > > > Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> > > >
> > > >
> > > > It seems good to me.
> > > >
> > > > Cheers // Javier.
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > Barry Nagelberg
> > > > > Sent: miércoles, 14 de enero de 2004 15:04
> > > > > To: SIGTRAN Mailing List
> > > > > Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> > > > >
> > > > >
> > > > > Javier,
> > > > >
> > > > > Thanks. For the sake of clarity, I suggest the 
> following changes:
> > > > >
> > > > > <snip>
> > > > >
> > > > > 3.6.1 Description of the problem
> > > > >
> > > > > The RFC does not clearly specify what the SG should do when
> > > > > it receives a
> > > > > Registration Request for a Routing Key that has already been
> > > > > registered.
> > > > > There are 3 scenarios to consider:
> > > > >
> > > > > 1. The registration request is an exact duplicate of a
> > > > registered RK by the sending ASP.
> > > > > 2. The registration request partially overlaps a registered RK
> > > > in the SGP.
> > > > > 3. The ASP is requesting to modify a registered RK.
> > > > >
> > > > > <snip>
> > > > >
> > > > > Barry Nagelberg
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > J.Javier Pastor (ML/EEM)
> > > > > > Sent: Wednesday, January 14, 2004 6:37 AM
> > > > > > To: SIGTRAN Mailing List
> > > > > > Cc: Ken Morneault (E-mail)
> > > > > > Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> > > > > >
> > > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > Here we send the new text proposal to clarify this issue
> > > > > > according your comments.
> > > > > >
> > > > > > Thanks // Javier.
> > > > > >
> > > > > >
> > > > > >
> > > > > > 3.6 Receiving REG for a RK already registered
> > > > > >
> > > > > > 3.6.1 Description of the problem
> > > > > >
> > > > > > The RFC does not clearly specify what the SG should 
> do when it
> > > > > > receives a Registration Request for a Routing Key that has
> > > > > > already been registered. There are two scenarios to 
> consider: the
> > > > > > registration request is a duplicate, it overlaps 
> partially an
> > > > > > already registered RK. Also there is a desire to include the
> > > > > > possibility of modifying a registered  Routing Key.
> > > > > >
> > > > > > 3.6.2 Text changes to the document
> > > > > >
> > > > > > ---------
> > > > > > Old text: (Section 3.6.1)
> > > > > > ---------
> > > > > >
> > > > > > 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 (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                     Destination Point Code
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Network Appearance (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Service Indicators (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |              Originating Point Code List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                   Circuit Range List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   \
> >         \
> > > > > >   /                              ...
> >         /
> > > > > >   \
> >         \
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                     Destination Point Code
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Service Indicators (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |              Originating Point Code List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                   Circuit Range List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > ---------
> > > > > > New text: (Section 3.6.1)
> > > > > > ---------
> > > > > >
> > > > > > 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
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                   Routing Context (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Traffic Mode Type (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                     Destination Point Code
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Network Appearance (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Service Indicators (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |              Originating Point Code List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                   Circuit Range List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   \
> >         \
> > > > > >   /                              ...
> >         /
> > > > > >   \
> >         \
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                     Destination Point Code
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                  Service Indicators (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |              Originating Point Code List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >   |                   Circuit Range List (optional)
> >         |
> > > > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > ---------
> > > > > > Old text: (Section 3.6.2)
> > > > > > ---------
> > > > > >
> > > > > > Registration Status: 32-bit integer
> > > > > >
> > > > > >   The Registration Result Status field indicates the
> > success or the
> > > > > >   reason for failure of a registration request.
> > > > > >   Its values may be:
> > > > > >
> > > > > >      0           Successfully Registered
> > > > > >      1           Error - Unknown
> > > > > >      2           Error - Invalid DPC
> > > > > >      3           Error - Invalid Network Appearance
> > > > > >      4           Error - Invalid Routing Key
> > > > > >      5           Error - Permission Denied
> > > > > >      6           Error - Cannot Support Unique Routing
> > > > > >      7           Error - Routing Key not Currently 
> Provisioned
> > > > > >      8           Error - Insufficient Resources
> > > > > >      9           Error - Unsupported RK parameter Field
> > > > > >      10          Error - Unsupported/Invalid 
> Traffic Handling Mode
> > > > > >
> > > > > > ---------
> > > > > > New text: (Section 3.6.2)
> > > > > > ---------
> > > > > >
> > > > > > Registration Status: 32-bit integer
> > > > > >
> > > > > >   The Registration Result Status field indicates the
> > success or the
> > > > > >   reason for failure of a registration request.
> > > > > >   Its values may be:
> > > > > >      0           Successfully Registered
> > > > > >      1           Error - Unknown
> > > > > >      2           Error - Invalid DPC
> > > > > >      3           Error - Invalid Network Appearance
> > > > > >      4           Error - Invalid Routing Key
> > > > > >      5           Error - Permission Denied
> > > > > >      6           Error - Cannot Support Unique Routing
> > > > > >      7           Error - Routing Key not Currently 
> Provisioned
> > > > > >      8           Error - Insufficient Resources
> > > > > >      9           Error - Unsupported RK parameter Field
> > > > > >      10          Error - Unsupported/Invalid 
> Traffic Handling Mode
> > > > > >      11          Error - Routing Key Change Refused
> > > > > >      12          Error - Routing Key Already Registered
> > > > > >
> > > > > >
> > > > > > ---------
> > > > > > Old text: (Section 4.4.1)
> > > > > > ---------
> > > > > >
> > > > > > If the SGP determines that a unique Routing Key cannot be
> > > > > > created, the SGP returns a Registration Response 
> message to the
> > > > > > ASP, with a Registration Status of "Error - "Cannot Support
> > > > > > Unique Routing"  An incoming signalling message 
> received at an
> > > > > > SGP should not match against more than one Routing Key.
> > > > > >
> > > > > > --------
> > > > > > New text: (Section 4.4.1)
> > > > > > ---------
> > > > > >
> > > > > > If the SGP determines that the requested RK 
> partially, but not
> > > > > > exactly, matches an existing RK, and that an 
> incoming signalling
> > > > > > message received at an SGP could possibly match both the
> > > > > > requested and the existing RK, the SGP returns a 
> Registration
> > > > > > Response message to the ASP, with a Registration 
> Status of "Error
> > > > > > - "Cannot Support Unique Routing. An incoming 
> signalling message
> > > > > > received at an SGP should not match against more than one
> > > > > Routing Key.
> > > > > >
> > > > > > If the SGP determines that the received RK was already
> > > > > > registered, fully and exactly, either statically or 
> dynamically,
> > > > > > by the sending ASP, the SGP returns a Registration Response
> > > > > > message to the ASP, containing a Registration 
> Result "Error -
> > > > > > Routing Key Already Registered ". This error 
> applies whether the
> > > > > > Routing Key is Active or Inactive. For this error 
> code, RC field
> > > > > > in Registration Response message MUST be populated with the
> > > > > > actual value of RC in SGP corresponding to the 
> specified RK in
> > > > > > Registration Request message.
> > > > > >
> > > > > > 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
> > > > > > "ERR - Routing Key Change Refused" is returned if 
> the SGP does
> > > > > > not accept the modification of the Routing Key due 
> to either it
> > > > > > does not support the re-registration procedure or 
> the specific RC
> > > > > > does not exist. Otherwise if the change is accepted, a
> > > > > > Registration Response "Successfully Registered" is returned.
> > > > > >
> > > > > > 3.6.3 Solution description
> > > > > >
> > > > > > The two cases, RK overlap and RK duplication, have been
> > > > > > differentiated and explained in detail. The latter 
> will use a new
> > > > > > specific Error Code as defined above. Also the 
> possibility of
> > > > > > modification to a Routing Key is included with the 
> addition of a
> > > > > > new parameter in the REG REQ message and the corresponding
> > > > > > explanation in the procedures section.
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: [email-masked]
Date: Sat, 17 Jan 2004 12:29:12 +0530

Brian,

Apologies for responding so late.
Can you please explain this with a figure such that we are clear that ASP3
is ultimately serving how many AS's and to which SGP it is associated. I am
not able to understand the configuration you are talking about.

Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 01/17/2004
02:55:48 AM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    Barry Nagelberg <[email-masked]>
cc:    SIGTRAN Mailing List <[email-masked]>

Barry,

There is a 1:1 correspondence; they are:

  5-5-5(ISUP) RC1
  5-5-5(SCCP) RC2
  5-5-5(*)    RC3

--brian

Barry Nagelberg wrote:
(Fri, 16 Jan 2004 09:38:03)
> Brian,
>
> I don't think that this configuration would be clear at all to the SGP.
In
> fact, it is impossible to implement this configuration using an SGP that
> complies with the RFC!
>
> At both the SGP and the ASP, there must be a 1:1 correspondence between a
> Routing Key and a Routing Context (please see Section 1.2 of the RFC). So
if
> ASP3 tries to register 2 different routing keys, 5-5-5(SCCP) and
> 5-5-5(ISUP), the SGP will return 2 different routing context values. You
> will never get RC3 for both routing keys at ASP3!
>
> Barry Nagelberg
>
> > From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > Brian F. G. Bidulock
> > Sent: Friday, January 16, 2004 1:19 AM
> > To: [email-masked]
> > Cc: SIGTRAN Mailing List
> > kakaul,
> > As far as ASP3 is concerned it is one AS.  It activates it
> > by sending ASPAC(RC3).  To the SG it is clear what traffic
> > is activated: 5-5-5(*), and it responds ASPAC Ack(RC3).
> >
> > --brian
> >
> > [email-masked] wrote:
> >                   (Fri, 16 Jan 2004 10:56:35)
> > >
> > >
> > >
> > >
> > > Brian,
> > >
> > >    How can ASP3 have same RC3 for two different AS's (5-5-5(ISUP),
> > > 5-5-5(SCCP)) registered with same SGP.How will ASP3 activate
> > the two AS's.
> > >
> > > Kamesh Kaul
> > > www.hssworld.com
> > > Hughes Software Systems
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Brian F. G. Bidulock" <[email-masked]> on 01/15/2004 08:31:30
PM
> > >
> > > Please respond to [email-masked]
> > >
> > > To:    Kamesh Kaul/HSS@HSS
> > > cc:    SIGTRAN Mailing List <[email-masked]>
> > >
> > > kakaul,
> > > In the example:
> > >             RK          ASP1   ASP2   ASP3
> > >  -----------     ----   ----   ----
> > >  5-5-5(ISUP)      RC1   -     RC3
> > >  5-5-5(SCCP)       -     RC2    RC3
> > >
> > > Is that so difficult?
> > >
> > > --brian
> > >
> > > [email-masked] wrote:
> > > (Thu, 15 Jan 2004 19:17:06)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I totally agree with Javier that there should be unique
> > routing per AS's
> > > ,
> > > > AS's must not overlap.
> > > > I am not able to understand how SG can handle overlapped AS's
> > registered
> > > by
> > > > different ASP's,
> > > > Brian can you explain it a little bit more.
> > > >
> > > > I think SG should not be confused in selecting actual AS if AS's
are
> > > > overlapped because first
> > > > thing what SG does is selecting of AS for given traffic
> > received without
> > > > having any clue of ASP's.
> > > >
> > > > Kamesh Kaul
> > > > www.hssworld.com
> > > > Hughes Software Systems
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------- Forwarded by Kamesh Kaul/HSS on
> > 01/15/2004 07:04
> > > PM
> > > > ---------------------------
> > > >
> > > >
> > > > "Brian F. G. Bidulock" <[email-masked]>@ietf.org on
01/15/2004
> > > > 05:44:34 PM
> > > >
> > > > Please respond to [email-masked]
> > > >
> > > > Sent by:    [email-masked]
> > > >
> > > >
> > > > To:    "J.Javier Pastor (ML/EEM)" <[email-masked]>
> > > > cc:    "'Barry Nagelberg'" <[email-masked]>, SIGTRAN Mailing List
> > > >        <[email-masked]>
> > > >
> > > > J.Javier,
> > > > Where does it say ASes must not overlap?  This is precisely
> > > > one of the example cases we used for IPSP discussions.
> > > > I certainly don't see where retricting this is necessary
> > > > for proper interworking or to protect the network.
> > > >
> > > > The only problem case we had for "Unique Routing" was were
> > > > two RC's exist for the same traffic for the same ASP.  It is
> > > > then abivalent which RC the SG is to assign to the traffic.
> > > >
> > > > In this example case, it is clear which RC value is to be
> > > > assigned to each message for each ASP.  There is no problem
> > > > of "Unique Routing".
> > > >
> > > > The problem of "Unique Routing" exists where one attempt to
> > > > configure or register overlapping RKs for the same ASP.  So
> > > > if ASP4 tries to register for 5-5-5(ISUP) and 5-5-5(*) there
> > > > is a problem of unique routing.  To which RC is ISUP traffic
> > > > to go?
> > > >
> > > > For the case of different ASPs, the SG can choose to support
> > > > it, if capable, or refuse it if not.  The IG need not attempt
> > > > to dictate a restriction to SG capabilities in this regard.
> > > >
> > > > --brian
> > > >
> > > > J.Javier Pastor (ML/EEM) wrote:
> > > > (Thu, 15 Jan 2004 12:11:40)
> > > > > Brian,
> > > > >
> > > > > Why don't you take the following approach...
> > > > >
> > > > > Define two different ASes:
> > > > > - AS1 -> 5-5-5 (ISUP)
> > > > > - AS2 -> 5-5-5 (SCCP)
> > > > >
> > > > > ASP1 registers within AS1
> > > > > ASP2 registers within AS2
> > > > > ASP3 registers within both AS1 and AS2
> > > > >
> > > > > It is important to keep one unique routing per AS. ASes MUST not
> > > overlap.
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > > > Sent: miércoles, 14 de enero de 2004 19:16
> > > > > > To: J.Javier Pastor (ML/EEM)
> > > > > > Cc: 'Barry Nagelberg'; SIGTRAN Mailing List
> > > > > > J.Javier,
> > > > > > Just to clarify, there should be nothing stopping an
> > > > > > implementation from
> > > > > > allowing ASP1 to register for, say, 5-5-5 (ISUP), ASP2 to
register
> > > for
> > > > > > 5-5-5 (SCCP) and ASP3 to register for 5-5-5(*).
> > > > > >
> > > > > > In this case, although ASP3 registers after ASP1 and ASP2,
> > > > > > there is nothing
> > > > > > stopping an SG from assigining a RK and RC to 5-5-5(*) for
ASP3.
> > > > > >
> > > > > > An SG implementation could choose to refuse 5-5-5(*) and
> > require ASP3
> > > > > > to register separately for 5-5-5(ISUP) and 5-5-5(SCCP), or it
> > > > > > might not.
> > > > > > I don't think it is the RFC's place to require one or the
> > other.  So,
> > > > > > for in the case where there is an overlap between
> > "different" APSs,
> > > it
> > > > > > should be left up to the SG implementation as it is now.
> > > > > >
> > > > > > Your additional text below, now clarifies that.  Thank you.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > >
> > > > > > J.Javier Pastor (ML/EEM) wrote:
> > > > > >                     (Wed, 14 Jan 2004 15:30:10)
> > > > > > > Barry,
> > > > > > >
> > > > > > > You are right. And that is valid only for the overlapping
> > > > > > case. You can not create a new AS whose associated RK
> > > > > > overlaps another existing registered RK. In the duplicate
> > > > > > case it is already included that the check is against the RK
> > > > > > previosly registered by the sending ASP. The latter makes
> > > > > > sense but not the former.
> > > > > > >
> > > > > > > Go back to my first proposal.
> > > > > > >
> > > > > > > Thanks // Javier.
> > > > > > >
> > > > > > > > Sent: miércoles, 14 de enero de 2004 14:49
> > > > > > > > To: SIGTRAN Mailing List
> > > > > > > > No, Brian's suggestion is not correct, nor is this updated
> > > > > > > > text. Routing
> > > > > > > > keys are independent of ASPs or associations. I think
> > > > > > perhaps Brian is
> > > > > > > > thinking of the routing context, which may be unique for
> > > > > > each ASP or
> > > > > > > > association.
> > > > > > > >
> > > > > > > > Barry Nagelberg
> > > > > > > >
> > > > > > > > > Sent: Wednesday, January 14, 2004 8:38 AM
> > > > > > > > > To: [email-masked]'
> > > > > > > > > Cc: SIGTRAN Mailing List; Ken Morneault (E-mail)
> > > > > > > > > Brian,
> > > > > > > > > Tell me if the following is OK.
> > > > > > > > >
> > > > > > > > > If the SGP determines that the requested RK partially,
but
> > > > > > > > not exactly,
> > > > > > > > > matches an existing RK already registered for the
> > > > > > sender ASP, and
> > > > > > > > > that an incoming signalling message received at
> > > > > > > > > an SGP could possibly match both the requested and
> > the existing
> > > > > > > > > RK, the SGP
> > > > > > > > > returns a Registration Response message to the ASP, with
a
> > > > > > > > Registration
> > > > > > > > > Status of "Error - "Cannot Support Unique Routing. An
> > > > > > > > incoming signalling
> > > > > > > > > message received at an SGP should not match against more
> > > > > > > > than one Routing
> > > > > > > > > Key.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > THanks // JAvier.
> > > > > > > > >
> > > > > > > > > > Sent: miércoles, 14 de enero de 2004 13:20
> > > > > > > > > > To: J.Javier Pastor (ML/EEM)
> > > > > > > > > > Cc: SIGTRAN Mailing List; Ken Morneault (E-mail)
> > > > > > > > > > J.Javier,
> > > > > > > > > > J.Javier Pastor (ML/EEM) wrote:
> > > > > > > > > >                     (Wed, 14 Jan 2004 12:36:54)
> > > > > > > > > >
> > > > > > > > > > --snip--
> > > > > > > > > > >
> > > > > > > > > > > --------
> > partially, but
> > > > > > > > > > not exactly,
> > > > > > > > > > > matches an existing RK, and that an incoming
signalling
> > > > > > > > > > message received at
> > > > > > > > > > > an SGP could possibly match both the requested and
the
> > > > > > > > > > existing RK, the SGP
> > > > > > > > > > > returns a Registration Response message to the
> > ASP, with a
> > > > > > > > > > Registration
> > > > > > > > > > > Status of "Error - "Cannot Support Unique Routing. An
> > > > > > > > > > incoming signalling
> > > > > > > > > > > message received at an SGP should not match against
more
> > > > > > > > > > than one Routing
> > > > > > > > > > > Key.
> > > > > > > > > > >
> > > > > > > > > > --snip--
> > > > > > > > > >
> > > > > > > > > > I think you mean for a given ASP (Association) in the
> > > > > > > > above.  Correct?
> > > > > > > > > >
> > > > > > > > > > It should be mentioned that the "matching" of RKs is
done
> > > > > > > > > > only against other
> > > > > > > > > > RKs belonging to the same ASP (Association).
> > > > > > > > > >
> > > > > > > > > > --brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > > [email-masked]
> > > > > > > > > > http://www.openss7.org/
> > > > > > > > > >
> > > > > > > > >
> > > > "DISCLAIMER: This message is proprietary to Hughes Software Systems
> > > Limited
> > > > (HSS) and is intended solely for the use of the individual to
> > whom it is
> > > > addressed. It may contain  privileged or confidential information
and
> > > > should not be circulated or used for any purpose other than
> > for what it
> > > is
> > > > intended. If you have received this message in error, please
> > notify the
> > > > originator immediately. If you are not the intended recipient, you
are
> > > > notified that you are strictly prohibited from using,
> > copying, altering,
> > > or
> > > > disclosing the contents of this message. HSS accepts no
responsibility
> > > for
> > > > loss or damage arising from the use of the information transmitted
by
> > > this
> > > > email including damage from virus."
> > > >
> > > >

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

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."