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

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Tue, 20 Jan 2004 08:39:08 +0100

Brian, 

Pls check the following:

- RFC3332 1.4.2.2: "Routing Keys SHOULD be unique in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result."

- RFC2119: "SHOULD   This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Although the guide is not to do what you are proposing, whenever you have the particular circumstance of talking to John's implementation you would say that you have your valid reasons and then you would say the "SHOULD" allows them. Of course those valid reasons would need to be discussed between the two parties and agreed. 

In order to get the consensus that SHOULD will also be moved to the new text in the following way:

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

Hopefully we are all happy.

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: lunes, 19 de enero de 2004 21:31
> To: Barry Nagelberg
> Cc: SIGTRAN Mailing List
> Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> 
> 
> Barry,
> 
> Javier's new text needs to be changed to allow what
> was already allowed by the RFC.
> 
> --brian
> 
> Barry Nagelberg wrote:                                        
>                        (Mon, 19 Jan 2004 11:03:23)
> > Brian,
> > 
> > ASP3 will not be able to register 5-5-5(*). The SGP will return the
> > following error code, as described in Javier's new text:
> > 
> > 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.
> > 
> > Barry Nagelberg
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, January 16, 2004 4:26 PM
> > > To: Barry Nagelberg
> > > Cc: SIGTRAN Mailing List
> > > Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> > >
> > >
> > > 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
> > > >
> > > > > -----Original Message-----
> > > > > 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
> > > > > Subject: Re: [Sigtran] M3UA: More redundant RKM error codes
> > > > >
> > > > >
> > > > > 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]>
> > > > > >
> > > > > > Subject:    Re: [Sigtran] M3UA: More redundant RKM 
> error codes
> > > > > >
> > > > > >
> > > > > > 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]>
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > > > --
> > > > > > 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
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> 
> -- 
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Jan 2004 01:11:10 -0700

J.Javier,

I have no problem with SHOULD, just with Barry's MUST.

I can agree with your text as worded below.

(However, note that RFC2119 does not require a bilateral agreement
to deviate from a SHOULD, as you seem to imply in your note.)

--brian

J.Javier Pastor (ML/EEM) wrote:                                                   (Tue, 20 Jan 2004 08:39:08)
> Brian, 
> 
> Pls check the following:
> 
> - RFC3332 1.4.2.2: "Routing Keys SHOULD be unique in the sense that each
> received SS7 signalling message SHOULD have a full or partial match to a
> single routing result."
> 
> - RFC2119: "SHOULD   This word, or the adjective "RECOMMENDED", mean that
> there may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and carefully
> weighed before choosing a different course."
> 
> Although the guide is not to do what you are proposing, whenever you have
> the particular circumstance of talking to John's implementation you would
> say that you have your valid reasons and then you would say the "SHOULD"
> allows them. Of course those valid reasons would need to be discussed
> between the two parties and agreed. 
> 

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