Subject: RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD

From: "Schantz, John" <[email-masked]>
Date: Fri, 13 Sep 2002 11:25:35 -0500

I don't agree, peer-to-peer is also covered under M3UA and I am not
taking about the IPSP case either.

I view M3UA in the same light as MTP3b.  If you do this and base your
implementation on this, all these "problems" that are coming up are
taken care of.  Hence, it really wasn't much work to state the obvious.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, September 13, 2002 10:55 AM
To: Schantz, John
Cc: [email-masked]; Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD

John,

Jeffrey and I were talking about backhaul (SG/ASP) not IPSP.

Nevertheless, In the multiple SG case the ASP still does not need to
maintain routeset state.  It needs only use restricted status responses
to affect SG selection, if it has traffic to send to the concerned
routesets.

I am glad to hear that you appreciate all the work we did in getting the
multiple SG scenario into M3UA.

--brian

Schantz, John wrote:
(Fri, 13 Sep 2002 10:37:07)
> Actually I have not been following this but you are wrong Brian.  The 
> M3UA RFC2b also states that if you have multiple routes, then you must

> maintain their availability status.  Also a good SS7 node is supposed 
> to maintain destination availability status.
> 
> Please stop pulling the brainless back-haul scenario into this.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 10:21 AM
> To: [email-masked]
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> 
> 
> Jeffrey,
> 
> If the ASP keeps track of congestion, it must also keep track of 
> routing. An ASP that keeps track of congestion, availability, 
> restriction, routing is no longer an ASP: it is either an SG or an 
> IPSP. I am somehow not suprised that you seem to think that all nodes 
> should be SGs.  You might consider promoting Tolga's SG-SG draft.  
> This is probably closer to what you are considering and includes the 
> concept of relay between the SS7 network and the IP network.
> 
> --brian
> 
> [email-masked] wrote:
> (Fri, 13 Sep 2002 08:10:52)
> > 
> > Hello Brian,
> > 
> > >Precisely:  Your configuration is not supported by the RFC.  If you
> > >are going to devise a proprietary or non-standard configuration, it

> > >really doesn't matter what you do.  If interoperability is of
concern
> 
> > >to you, I would advise that you follow the proposed standard.  In 
> > >the
> 
> > >standard you have two choices:  (1) the SG terminates MTP3; (2) the
> > >SG is not connected to an SS7 network and is really an IPSP.
> > 
> > It is not a RFC yet, and yes, when M3UA becomes a RFC, we will 
> > comply.
> > 
> > IMO it is unfortunate that this functionality is required for the 
> > M3UA
> 
> > component of the SGP. It is not a function of an SG-STP's MTP3 to
> > maintain congestion status obtained from TFCs that are not destined
to
> 
> > it, but simply through-switched, as is the case when a TFC arrives 
> > for
> 
> > the ASP, and the SGP and ASP do not share a point code. It is clear 
> > to
> 
> > me (now) that, according to the RFC-to-be, ASP point codes are 
> > virtual
> 
> > and are implicitly shared with the SGP.
> > 
> > Since the ASPs are notified of congestion status, and probably
> > implement a procedure to handle it (that is, stop sending and begin
to
> 
> > audit), a simpler alternative is to allow them to provide the 
> > stimulus
> 
> > for the SGP to generate RCTs. This allows for remote congestion 
> > status
> 
> > to be maintained in just one place -- the ASP.
> > 
> > Regards,
> > 
> > Jeff
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 09/12/2002
> > 05:44:54 PM
> > 
> > Please respond to [email-masked]
> > 
> > Sent by:    [email-masked]
> > 
> > 
> > To:    [email-masked]
> > cc:    Tolga Asveren <[email-masked]>, [email-masked]
> > Subject:    Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> > 
> > 
> > Jeffrey,
> > 
> > [email-masked] wrote:
> > (Thu, 12 Sep 2002 16:58:48)
> > >
> > > Hello Brian,
> > >
> > > >But SS7 does not permit RCT to be generated except in response to
> > > >TFC. Are you meaning that you are delaying response to DAUD until

> > > >the next normal RCT cycle?
> > >
> > > I am refering to the scenario in which the M3UA SG-STP does not
> > > share a point code with the M3UA peer. The M3UA ASP sends a
message 
> > > via the SG-STP into the SS7 network, and the message encounters 
> > > congestion. A response method TFC is generated, arrives at the SG 
> > > destined to the peer's point code, and is sent out as a SCON. (The

> > > SG-STP does not capture the TFC and maintain congestion status for

> > > the destination, nor does it initiate route-set-test on behalf of 
> > > the ASP). The ASP replies with a deviated DAUD. The SG generates a

> > > RCT and sends it to the congested destination.
> > >
> > > And yes, I know that your next response is going to be that the SG
> > > is supposed to terminate MTP3, and therefore should implement 
> > > route-set-test on behalf of the ASP. I disagree with this, when
the 
> > > SG and ASP do not share a point code.
> > 
> > Precisely:  Your configuration is not supported by the RFC.  If you
> > are going to devise a proprietary or non-standard configuration, it 
> > really doesn't matter what you do.  If interoperability is of
concern 
> > to you, I would advise that you follow the proposed standard.  In
the 
> > standard you have two choices:  (1) the SG terminates MTP3; (2) the
SG
> 
> > is not connected to an SS7 network and is really an IPSP.
> > 
> > >
> > > >Then I take it you do not have a problem with the text in the
> > > >RFC2b?
> > >
> > > The fact that it does not require the SG to send a SCON in 
> > > response
> > > to a DAUD is good. ;)
> > 
> > I agree.
> > 
> > >
> > > Regards,
> > >
> > > Jeff
> > 
> > --
> > 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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Sep 2002 10:36:58 -0600

John,

I think you are talking about M2PA again.

--brian

Schantz, John wrote:                         (Fri, 13 Sep 2002 11:25:35)