Subject: RE: [Sigtran] reg req

From: "Tomar, Nitin" <[email-masked]>
Date: Thu, 14 Feb 2002 13:59:03 -0800

Hi Virendra, Brian,

 I would say (c) 
 and about (f), as per my understanding
 the text specified in the draft 12 [sec 4.1.1] 
-->
 Error - "Cannot Support Unique Routing"  An incoming signaling message
received at an 
SGP should not match against more than one Routing Key.
<--
 does not refer to the scenario you have specified.

 Brian, If ASP is confused then its better to send positive 
 REG RSP with already generated Routing Context for the AS.

- Nitin.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 10:58 AM
> To: Nahar,virendra
> Cc: [email-masked]
> Subject: Re: [Sigtran] reg req
> 
> 
> Nahar,virendra,
> 
> Nahar,virendra wrote:                              (Fri, 15 
> Feb 2002 00:04:03)
> > At SG side if u get a Reg Request from an ASP which is 
> already ACTIVE
> > for this AS .
> > which action  should be the action taken ..options are !!
> > (a) Discard the request & send an  error message with cause 
> unexpected
> > message.
> > (b) Send the Registration response with RC & result as 
> successful & mark
> > the ASP in inactive state.
> > (c) Send a positive Reg Response & do not change the state of ASP.
> > (d) Send a negative Reg Response with code error unknown
> > (e) Define a new error code for this case .
> > 
> >         Pls clarify this condition
> 
> I would say (f) send a negative Reg Response with error code
> "Cannot Support Unique Routing".
> 
> If you are considering the case where the ASP crashes and 
> comes back up,
> the ASP should have sent ASP UP resulting in deregistration 
> of all routing
> keys and deactivation of all AS.  So the only time that an 
> ASP would send
> such a thing is if the ASP is confused, perhaps about the 
> state of an AS
> under its control.  There is not much one can do here: the 
> ASP is broken.
> 
> --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

---

From: "Nahar,virendra" <[email-masked]>
Date: Fri, 15 Feb 2002 03:40:17 +0530

I agree with u Nitin & thats was my view point  also
but Brian has a different opinion his answer inline
(b) and (c) are not really applicable IMO because they
modify the state of the AS at the SG without informing
the ASP.  The ASP needs to control the AS state.

--brian

--
Virendra Nahar
HCL-Technologies Ltd
Networking Systems Lab
51, Jawaharlal Nehru Road
Guindy Industrial Estate,
Ekkatuthangal,
Chennai - 600 097.
Phone Off : +91 44 233 4174 or +91 44 233 4181(extn:261,218)
mailto:[email-masked]
############################################################
"He who has a why for life can put with any how."
                             Frederick Nietzsche
############################################################

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Feb 2002 18:06:55 -0600

Nitin,

(c) leaves the AS in the ACTIVE state when the ASP obviously
believes that it is in the INACTIVE state because it is
registering the routing key.  Also, there is the possibility
that the ASP is attempting to register a separate AS with the
same routing key as an already active AS.  This is precisely
the overlap situation for which the "Cannot Support Unique
Routing" was devised.

Even for the "Cannot Support Unique Routing" case, we had some
discussions on the WG which tended to indicate that returning
this error was at the SG's discretion.  That if RC was
included in the routing key that the overlap situation could
be used to detect the scenario where the routing key was
expanded without reregistering.  We pretty much left those
dicusssions for extension draft.  There are other cases in
which altering an existing registration on the fly is valuable
for ISUP CICs and in SUA and TUA.  I had prepared a rough
draft of such a registration mechanism, but I have not
submitted it yet.

IMO if action (c) is taken, the SG leaves open the situation
where it will be sending DATA to what it believes to be an
ACTIVE AS, when the AS is in the INACTIVE state at the ASP.
This would result in DATA messages sent into a black hole
causing significant data loss.

If action (c) is taken, the SG should send a NTFY("AS-Active")
for the specified AS to notify the ASP that it believes the AS
to be in the active state, and even an ASP Active Ack, to
force the ASP to address the state of the AS.

If action (b) is taken, the SG should send a
NTFY("AS-Inactive") for the specified AS and event an ASP
Inactive Ack, again, to force the ASP to address the state of
the AS and resynchronize state of the AS between the SG and
the ASP.

With NTFY and ASP (In)active Acks, this process would be
rather disruptive on an otherwise normal AS which simply has
an additional AS attempting to register under the wrong
routing key.  Less disruptive to existing AS would be to deny
the registration request per (f).

Does that clarify the situation?  These things are really
implementation dependent and therefore not addressed by the
specification.  It takes an understanding of probable failure
modes to determine the correct course of action for broken
peers.  In the final analysis, the correct action to take with
broken peers is to fix them.

This is not IMO an interoperability issue.  One can always
find interesting ways in which specific implementations can
break and disrupt the protocol.  Other implementations can
find equally interesting way in which to recover from them.  I
don't believe that anything needs to be added to the existing
specification.  Implementations experience will point the way
here.  The results of ETSI testing at the end of this month
might shed some light on situations like this, just as the
Ericsson testing last year highlighted some issues which have
already been addressed.

--brian

Tomar, Nitin wrote:                       (Thu, 14 Feb 2002 13:59:03)

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