Subject: RE: [Sigtran] SUA -- Source Address in the CORE message

From: [email-masked]
Date: Thu, 2 Oct 2003 12:56:43 +0300

Hi all,

For this issue, I do not see any changes needed for SUA.

John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 08 August, 2003 10:03
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sigtran] SUA -- Source Address in the CORE message
> 
> 
> ygahlaut,
> 
> See Table 2/Q.711 note a1) (calling address in N-CONNECT request):
> 
>  "This parameter is associated with the SCCP service access point at
>   which this primitive is issued if the calling address is absent."
> 
> Therefore, even though there is no calling address in the CORE, the
> SGP can determine the SCCP-SAP of the sender of the CORE using the
> RC associated with the CORE.
> 
> Also, note a3) (responding address in N-CONNECT response):
> 
>  "This parameter is associated with the SCCP service access point at
>   which this primitive is issued if the calling address is absent."
> 
> Therefore, even though there is no calling address in the COAK, the
> SCTP can determine the SCCP-SAP of the sender of the COAK using hte
> RC associated with the COAK.
> 
> As an ASP, you do not send RELRE when DUNA occurs.  The SGP sends
> RELRE to the ASP with the reasons already mentioned, but also sends
> DUNA because it needs to be passed to the SCCP-User.
> 
> See Q.711/6.1.1.2.2 (duly cited in sua-15 section 1.6.1) for more
> information.
> 
> --brian
> 
> [email-masked] wrote:                                   
>                     (Thu, 07 Aug 2003 16:35:36)
> > 
> > 
> > 
> > 
> > Hi Brian,
> >  Please see some comments inline
> > Regards
> > Yogesh
> > www.hssworld.com
> > Hughes Software Systems
> > 
> > 
> > 
> > 
> > "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 08/07/2003
> > 01:42:03 PM
> > 
> > Please respond to [email-masked]
> > 
> > Sent by:    [email-masked]
> > 
> > 
> > To:    Yogesh Gahlaut/HSS@HSS
> > cc:    [email-masked]
> > 
> > Subject:    Re: [Sigtran] SUA -- Source Address in the CORE message
> > 
> > 
> > ygahlaut,
> > 
> > [email-masked] wrote:
> > (Wed, 06 Aug 2003 17:54:39)
> > >
> > >
> > >
> > >
> > > Hi,
> > >         According to the SUA draft Source Address field 
> in CORE message
> > is
> > > optional.
> > > Consider the following sequence
> > >
> > > SGP sends a CORE message to ASP without Source Address.
> > > ASP sends back the COAK to same SGP without Destination Address.
> > > Connection established
> > > :
> > > :
> > >  Data transfer takes place
> > > :
> > > :
> > > SGP sends a DUNA message
> > > :
> > 
> > It is not the role of the ASP to perform SCCP CO state 
> machine functions.
> > These are performed at the SGP.  It is the SGP's 
> resposibility to, as well
> > as
> > sending the DUNA, send RELRE (N-DISCONNNECT-Indication) to 
> the ASP with the
> > appropriate cause (in this case, Subsystem Failure, SCCP 
> Failure, or MTP
> > Failure).
> > 
> > : SGP sends RELRE
> > ###### Yogesh #######
> > I agree about performing the SCCP CO state machine 
> functions at the SGP
> > side. But my query was that how to identify the connection 
> for which i need
> > to send RELRE. I am saying that connection was initiated 
> from SGP side and
> > N-CONNECT request has no calling address(because its 
> optional). When DUNA
> > is to be sent to ASP with some point code (say X). Now look out for
> > connections which has calling address(or Originating Node) 
> as the Point
> > Code X which is now getting Unavailable.
> > Please Correct me if i am missing something.
> > 
> > One more thing as you said RELRE should be sent to ASP. In 
> case if i have
> > say 'n' connections, first i should send 'n' RELRE and then 
> wait for 'n'
> > RELCO and then send DUNA.
> > ###################
> > 
> > > :  <----- Point 1
> > > :
> > > ASP Send Connection Oriented Data
> > 
> > It would be typical to discard CO data after sending RELRE 
> (at least for
> > a short while), to give the AS time to respond to the
> > N-DISCONNECT-Indication
> > and stop sending data.
> > 
> > --brian
> > 
> > Please remove your DISCLAIMER below from future mailings.
> > 
> > > :
> > > :  <---- Point 2
> > > :
> > >
> > >
> > > Now  queries
> > > 1> on Point 1 should the connection be terminated with 
> the destination
> > from
> > > which DUNA message is received and no CODT is allowed
> > > If Yes.... How ?  considering the case where ASP did not 
> receive the
> > Source
> > > Address in CORE message. how can the connection be 
> identified?  because
> > ASP
> > > does not know the peer's address for this Connection.
> > >
> > > Should the Connection be identified using RC  but then 
> there may be a
> > case
> > > in which there is no RC in DUNA message (RC is optional 
> in DUNA message)
> > ?
> > >
> > > 2> on point 2 should this CODT message be allowed to reach SGP ?
> > >    should this message be  routed to another SGP(if there) ?
> > >
> > >
> > > Please correct me if I am missing something
> > >
> > > Regards
> > > Yogesh
> > > www.hssworld.com
> > > Hughes Software Systems
> > >
> > >
> > > _______________________________________________
> > > 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
> 
> -- 
> 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