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

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

Tolga, 

Pls, see my comments below...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: jueves, 15 de enero de 2004 16:39
> To: SIGTRAN Mailing List
> Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> 
> 
> Maybe we should look to this issue again in depth, because a 
> few things have
> changed in the last one year or so about the RKs.
> 
> Before we had CIC/SSN as possible parts of RKs. This could 
> make hierarchical
> routing almost impossible -or at least proprietary- in case 
> of overlapping
> RKs. For example one has AS1:DPC=1-1-1/CIC=0-100 and
> AS:DPC=1-1-1/CIC=50-150. Then for a message with DPC=1-1-1 
> and CIC=75, it is
> not easy (or straighforward) to tell, which AS the message 
> has to match.
> 
> Now the issue is a bit different considering that our RKs are 
> limited to PC
> and User Parts. For example if there is AS1:DPC1-1-1 and 
> AS2:DPC=1-1-1/ISUP,
> it is quite obvious (especially maybe with a small section about
> hierarchical RKs in IG) that traffic for ISUP should go to 
> AS2 and other
> traffic for DPC=1-1-1 to AS1.
> 

But why not using AS1:DPC=1-1-1/SI=SCCP ? This is inline to what you want to achieve and it would make no problems with the RFC..

Take into account that things like this, may move us to use precedence rules in RKs... :-(. I think that is not really needed while you can get the same effect with the already defined building blocks...

> Currently related with RK overlapping we have:
> RFC3332 1.4.2.2 Routing Key Limitations:
> "Routing Keys SHOULD be unique in the sense that each 
> received SS7 sgnalling
> message SHOULD have a full or partial match to a single 
> routing result."
> 
> I also remember some people supporting hierarchical RKs based on that
> "SHOULD" already.
> 
Maybe that was the reason to leave the SHOULD. But doing in other way and being compliance with the standard, implies the need to demonstrate a very good reasons to contradict the SHOULD. I would not see "another way of doing things" as strong enough reasons for that.

> In fact, once there is a well defined hieararchy among 
> overlapping RKs, one
> can even have them on the same ASP -with the drawback of 
> receiving SSNM
> separetly for them, but not big deal
> 
> Personally -at least for now- I don't think overlapping RKs 
> is terribly
> usefull (maybe for a "backup" node:
> 
>            AS2:1-1-1  AS3:1-1-1
>  AS1:1-1-1  SCCP      ISUP
>   +----+   +----+   +----+
>   |ASP1|   |ASP2|   |ASP3|
>   +--+-+   +--+-+   +--+-+
>      |        |        |
>      |        |        |
>      |        |        |
>   +--+--------+--------+-+
>   |                      |
>   |        SG1           |
>   +----------------------+
> 
> Imagine that first AS1 comes up (takes all traffic for AS1), 
> then AS2 and
> AS3. Now, AS1 does not get any traffic. Now AS1 can serve as 
> backup for both
> AS2/AS3 -and will take some part of traffic as soon as any of 
> them fails-.
> 

You can reach the same behaviour including ASP1 in AS2 and AS3... An a side advantage is that you need to define a smaller number of RKs... and ASes.

> 
> Having said all of that, I think because of the "SHOULD" in 
> 1.4.4.2, RFC3332
> already allows such a configuration(and we can assume now 
> hierarchy among
> RKs is almost obvious)
> 
>     Tolga
> 

Summarizing, I think it is not needed to change the RFC regarding this concern (also, for the time being ;D), since the functionality you claim can be already got with the normal procedures.

Cheers // Javier.

> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Thursday, January 15, 2004 8:47 AM
> > To: SIGTRAN Mailing List
> > Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> >
> >
> >
> >
> >
> >
> >
> > 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]>
> >
> > Subject:    Re: [Sigtran] M3UA: More redundant RKM error codes
> >
> >
> > 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.
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: miércoles, 14 de enero de 2004 19:16
> > > > To: J.Javier Pastor (ML/EEM)
> > > > Cc: 'Barry Nagelberg'; SIGTRAN Mailing List
> > > > Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> > > >
> > > >
> > > > 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.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > Barry Nagelberg
> > > > > > Sent: miércoles, 14 de enero de 2004 14:49
> > > > > > To: SIGTRAN Mailing List
> > > > > > Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
> > > > > >
> > > > > >
> > > > > > Javier,
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > J.Javier Pastor (ML/EEM)
> > > > > > > Sent: Wednesday, January 14, 2004 8:38 AM
> > > > > > > To: [email-masked]'
> > > > > > > Cc: SIGTRAN Mailing List; Ken Morneault (E-mail)
> > > > > > > Subject: RE: [Sigtran] M3UA: More redundant RKM 
> error codes
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: miércoles, 14 de enero de 2004 13:20
> > > > > > > > To: J.Javier Pastor (ML/EEM)
> > > > > > > > Cc: SIGTRAN Mailing List; Ken Morneault (E-mail)
> > > > > > > > Subject: Re: [Sigtran] M3UA: More redundant RKM 
> error codes
> > > > > > > >
> > > > > > > >
> > > > > > > > J.Javier,
> > > > > > > >
> > > > > > > > J.Javier Pastor (ML/EEM) wrote:
> > > > > > > >                     (Wed, 14 Jan 2004 12:36:54)
> > > > > > > >
> > > > > > > > --snip--
> > > > > > > > >
> > > > > > > > > --------
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > --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/
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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/
> > > >
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> >  https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> >
> > "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."
> >
> >
> > _______________________________________________
> > 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 15 Jan 2004 11:04:12 -0500

Javier,
> From: J.Javier Pastor (ML/EEM) [mailto:[email-masked]]
> Sent: Thursday, January 15, 2004 11:00 AM
> To: 'Tolga Asveren'; SIGTRAN Mailing List
> But why not using AS1:DPC=1-1-1/SI=SCCP ? This is inline to what
> you want to achieve and it would make no problems with the RFC..
>
> Take into account that things like this, may move us to use
> precedence rules in RKs... :-(. I think that is not really needed
> while you can get the same effect with the already defined
> building blocks...
>
>
> Maybe that was the reason to leave the SHOULD. But doing in other
> way and being compliance with the standard, implies the need to
> demonstrate a very good reasons to contradict the SHOULD. I would
> not see "another way of doing things" as strong enough reasons for that.
>
> You can reach the same behaviour including ASP1 in AS2 and AS3...
> An a side advantage is that you need to define a smaller number
> of RKs... and ASes.
[TOLGA]Yes, you are right. But the above configuration has a slight
advantage: no time is wasted NTFY/ASPAC/ASPAC-ACK (but no big deal, thi sis
supposed to finish quickly and SG can buffer)
> Summarizing, I think it is not needed to change the RFC regarding
> this concern (also, for the time being ;D), since the
> functionality you claim can be already got with the normal procedures.
[TOLGA]Yes, this is also what I think.