Subject: RE: [Sigtran] M3UA IG V04: Receiving REG for a RK already registered

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 15 Jul 2003 13:32:57 +0200

It seem to resolve the problem and keep the "overlapping" control on an
ASP valid.
Do not forget to include this modification in next IG ;-)

Francois.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent: Tuesday, July 15, 2003 12:37 PM
> To: Zannin, Francois
> Cc: Umesh Vats; VIvek Toky; SIGTRAN e-mail list
> Subject: Re: [Sigtran] M3UA IG V04: Receiving REG for a RK 
> already registered
> 
> 
> Francois,
> 
> Well, not quite.  Even the buggy M3UA should be able to 
> retain the Local-Routing-Key-Identifier from the original REG 
> REQ. All that the ASP need do is reissue If the M3UA cannot 
> maintain the state of the original REG REQ (i.e, retain the 
> Local-Routing-Key-Identifier used) then it cannot correlate 
> the REG RSP anyway.  the REG RSP with the same 
> Local-Routing-Key-Identifier.  The SGP uses this to determine 
> that the REG REQ is a repeat attempt an replies with a REG RSP.
> 
> REG RSP("Cannot support unique routing") is intended as a 
> reply to a REG REQ from a different AS at the ASP.  This 
> could be identified by the presence of a different 
> Local-Routing-Key-Identifier than the original.
> 
> I know that this not mentioned in the IG 04, but we discussed it.
> 
> Example: an ASP sends a REG REQ and waits.  It gives up and 
> sends another REG REQ.  It then receives two REG RSP.  We 
> discussed that if an ASP were to send two REG REQ for the 
> same registration that they should contain the same LRK-Id.
> 
> In the case where a REG REQ contains the same LRK-Id for the 
> same RK, the response to the second could be the same as the 
> response to the first. (Successful).
> 
> Now, the objectionable lines are in IG 04:
> 
>    --------
>    New text: (Section 4.4.1)
>    ---------
> 
>    If the SGP determines that the received RK was already registered,
>    the SGP returns a Registration Response message to the ASP,
>    containing a Registration Result "Error - Cannot Support Unique
>    Routing". This error applies whether the Routing Key is Active or
>    Inactive.
> 
> But, this (strangely) does not change the pertinent passages 
> in the RFC which say:
> 
>    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.
> 
> This error was really intended to preclude "overlapping" 
> routing keys which are verbodden in M3UA.  The error was 
> never intended for attempts at re-registration by the same AS.
> 
> How does the following change sound?
> 
>    --------
>    New text: (Section 4.4.1)
>    ---------
> 
>    If the SGP determines that the received RK was already registered,
>    and the Local-Routing-Key-Identifier in the RK is the same as the
>    Local-Routing-Key-Identifier that was used to register the RK, then
>    the SGP treats the REG REQ as a duplicate and returns a 
> Registration
>    Response message to the ASP, containing a Registration Result
>    "Successful" and the Routing Context associated with the RK.
> 
>    If the SGP determines that the received RK was already registered,
>    and the Local-Routing-Key-Identifier in the RK does not match the
>    Local-Routing-Key-Identifier that was used to register the RK, the
>    the SGP treats the REG REQ as an overlapping RK request and returns
>    a Registration Response message to the ASP, containing a 
> Registration
>    Result "Error - Cannot Support Unique Routing". This error applies
>    whether the Routing Key is Active or Inactive.
> 
> This would only push the SGP into maintain, along with the 
> fact that the ASP is registered against the RK, the 
> Local-Routing-Key-Id that was used by the ASP to register.  4 
> bytes.  Not too much.
> 
> Then an AS can send as many REG REQ as it likes, as long as 
> it uses the same LRK-Id, it will get the same response.
> 
> Sound good?
> 
> --brian
> 
> On Tue, 15 Jul 2003, Zannin, Francois wrote:
> 
> > Brian,
> > 
> > This is true that SCTP is a very reliable transport layer but it may

> > happen that a M3UA on top of SCTP not "bug free" can lost a received

> > message (maybe due to local congestion?). In that case, if the ASP
has 
> > lost the reg_resp, than it cannot deregister the lost RC (because it

> > is not known), the guilty ASP is then unable to recover the missing
RC 
> > unless maybe to send an ASP-DOWN/ASP-UP in order to allows again the

> > AS registration. Then, all already registered AS on the same 
> > associations are lost!
> > 
> > If the Routing KEY is the same as the one already registered, isn't
it 
> > possible for the SG to repeat the same RC?
> > 
> > If the AS (RC) was already ACTIVE on this association, yes it is an 
> > error, then the AS mUST return to the INACTIVE state.
> > 
> > Francois.
> > 
> 
> -- 
> Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> [email-masked]    | world; the unreasonable one persists in  |
> http://www.openss7.org/ | trying  to adapt the  world  to himself. |
>                         | Therefore  all  progress  depends on the |
>                         | unreasonable man. -- George Bernard Shaw |
> 

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