Re: AS concepts and Relay in SUA and M3UA
Stanislav Ivanovich <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Hello again, In addition I would say that GT'es are not managed (neither on the SCCP nor on this SUA interface). Therefore if one would somehow managed to incorporate SUA relay in the AS/RC concept then what would happen if we have a pool of IPSP processes equipped with GT relay which are however used as the 2nd (or 3rd or 4th...) stage of the GT-relay? In this case the AS concept cannot help the originating SCCP application after all our efforts to incorporate SUA relay into the AS/RC concept! The point is that AS redundancy model in this case does not help! Redundancy of GT based relays in my view should be covered by the SG-SG concept as well, however in this case without having conceptual problems (like RC'es on the SUA-relay<->SUA-relay interface). / Stanislav Ivanovich Stanislav Ivanovich <[email protected]> wrote: Brian, I think you missed the essential point of all this. It is not about what are the messages what can be sent or not but what is the relationship between the relay processes. For the moment I will denote this kind of processes SRP (SUA Relay Process). My essential point here is that your specification seems to use the same kind of relation for SRP-SRP as the one between IPSP-IPSP. However this is very wrong! My essential point is that SRP-SRP relation should not deal with application pointers (i.e. RC values) since there it does not make any sense! Otherwise if you claim that there RC does make sense what it would mean in a network scenario of many SRP processes fully or partially meshed??? What do you actually want to achieve with this? Please look my last mail on this issue I had with Tolga. Like Tolga, I also claim that the SCCP-level relay is not IPSP relay since IPSP and ASP'es are application processes! Applications do not perform SCCP-level relay (GT translation). This job is done by SCCP. However in this case you need an SRP (or we can call it SGP what Tolga prefers) and we finish on ASP-SGP------SGP-ASP scenario. Essential point here is that we need another kind of relation namely the one between SRP'es (or SGP'es) currently not supported in your paper. This is not IPSP-IPSP relation! This is something completely different! I read your mail sent to Tolga which says: ------------------------------------------------------ [brian] ------------------------------------------------------ Tolga, Well, no. Unlike MTP, where the transfer function is only optionally equipped! at specific interior nodes in the network (STPs), SCCP relay is possible at all nodes in the network (including endpoints). Therefore M3UA can treat the network as point to point (i.e. like all F-links with no STPs) but SUA cannot treat the network as having no relay points. Therefore, SUA IPSPs must support relay to support SCCP-Users. --brian ------------------------------------------------------ This is completely pointless! Indeed, it is true that you can have SCCP relay at SCCP endpoints. However as a protocol designer you must not make any assumptions on the implementation or instalation of different protocol entities! In another words your protocol desing must only consider communication between logical entities and must not show any dependency on the installation! Thus in this ! case you achieve SCCP relay at SCCP endpoint by installing two protocol entities at the same place (i.e. in the same machine), namley IPSP (or ASP) and SRP (or SGP). However nature of the relation between the processe is stil clear and kept intact! Namely IPSP is application and SRP (or SGP whatever you call it) is a process which performs SCCP relay. You just have to define SRP-SRP relation (because AS/RC concpet does not belong there!) and that's it! kind regards/ Stanislav Ivanovich "Brian F. G. Bidulock" <[email protected]> wrote: Tolga, No supplementary text is necessary. Read section 1.4.6 Relay function. Read section 1.5 Internal Function Provided in the SUA Layer. Read section 1.5.3 Address Mapping Funciton at a Relay Node. Read section 3.4.1 Destination Unavailable (DUNA). Read section 3.4.2 Destination Available (DAVA). Read section 3.4.3 Destination State Audit (DAUD). Read section 3.4.4 Signalling Congestion (SCON). Read section 3.10.9 ASP Capabilities. I think that it is quite clear that DAUD can be sent to a relay point (not only an SG), and that a relay point can send DUNA, DAVA and SCON (not only an SG), and that an IPSP can indicate its ability to relay with ASP Capabilities. All contrary to your M3UA perspective. --brian Tolga Asveren wrote: (Fri, 16 Dec 2005 15:55:49) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:[email protected]] > > Sent: Friday, December 16, 2005 4:09 PM > > To: Tolga Asveren > > Cc: [email protected] > > Subject: Re: [Sigtran]! AS concepts and Relay in SUA and M3UA > > > > > > Tolga, > > > > I am an author of the SUA RFC. > [TOLGA] Yes, you are one of the authors but I think it is clear that neither > the concept of SUA-IPSP nor SUA-relay is clearly defined in the SUA > documents and I believe it would be useful to hear from other people > regarding this issue, before deciding for supplementary text. -- Brian F. G. Bidulock [email protected] http://www.openss7.org/ _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran