RE: AS concepts and Relay in SUA and M3UA
Stanislav Ivanovich <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
John, Brian I think that at this point it is rather clear that SUA paper suffers from the serious children's diseases. All the comments I have read today confirm my original impression that SUA RFC added SCCP alike relay (i.e. GT relay) in an ad-hoc manner. The major objection is that it uses AS/RC and Signaling Process concepts as used/defined in the M3UA RFC (by making copy/paste from M3UA RFC) and at the same time we hear statements like these: ----------------------------------------------------------------------------------------- [JOHN] Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process. ----------------------------------------------------------------------------------------- [JOHN] The notion of a process, IMO, is an implementation issue - different OSes may behave different. ----------------------------------------------------------------------------------------- [BRIAN] It might help you to start with the understanding that, although common text was shared to save redundant wordsmithing, the AS concept for SUA is different from that for M3UA. Just as it is different for M2UA and IUA, etc. ----------------------------------------------------------------------------------------- All the statements above do not make sense especially the second one. Of course that no one expects the defintion of a process in an operating system language but instead in the terms of: 1) functionality they perform (e.g. do they contain application functionality or not) 2) communication protocol the entities/processes use to communicate with each other As I said in a mail sent on Friday last week: "A protocol designer must not make any assumptions on the implementation or installation of different protocol entities! In another words protocol design must only consider communication between logical entities and must not show any dependency on the installation! Thus in SUA case you achieve SCCP relay at SCCP endpoint by installing two protocol entities at the same place (i.e. in the same machine), namely IPSP (or ASP) and SRP (or SGP). However nature of the relation between the processes is still clear and kept intact! Namely IPSP is application and SRP (or SGP whatever you call it) is a process which performs SCCP relay." Practically speaking, in my view you have two alternatives for SUA: 1) Abandon or change the original AS/RC/signaling process xxUA concepts (which are strictly followed by M3UA). In this case serious rework on the SUA paper is needed since the paper uses (more or less) copy/paste of the fundamental procedures from M3UA. 2) Follow the fundamental/original AS/RC/signaling process principles (which are copy/pasted from M3UA) but cover the relay functionality by introducing another relationship since as said above the AS/RC concept does not originally cover the relay. In this case you need to extend the role of SGP process to relay between IP-IP and introduce SGP-SGP relationship. I prefer the second option since the AS/RC concept has been originally designed/tailored for direct communication. If one wants to think of any relay in xxUA networks he/she fill very soon realize the complete unsuitability of the AS/RC concept for the building of relay equipped networks. This is especially the case if one wants to do that by following mandatory SE model. In other words there are serious reasons for not allowing the AS/RC concepts be visible/used on the interface between two relay points. However regardless of this fact the RC (as a pointer to an application served by an application process) does not have any meaning between the processes (whatever you call them) which perform the relay on the SCCP level. On the other hand the RC has very important and meaningful role on the SGP-ASP and IPSP-IPSP interfaces. thanks and regards/ Stanislav Ivanovich [email protected] wrote: Tolga, >The question is -at least as far as I understand-, whether an >SUA-IPSP supports relaying. Is the question: 1) MAY an IPSP support relaying. 2) SHOULD an IPSP support relaying. 3) MUST an IPSP support relaying. Which one is the question. I'd say my answer would be: 1) Yes. 2) Maybe. 3) No. John _______________________________________________ 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