Re: RFC 4666 M3UA - Reg Request Message
"Ilie Glib" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Hello Brian, multiple SG as STP scenario in SUA is a dead end, at least with the current SUA status. I think the difference between CIC and DRN or destination TID is essential. CIC is a "resource" owned by both peers of the signalling relation, while TID/DRN is owned only by one side of the signalling relation. More over DRNs and TIDs are software resources, while CICs are physical resources. For the reasons above, static handling of DRN/TID labels is acceptable, whereas CICs require a rather dynamic handling. That is why I find loadsel or similar way as something mandatory for M3UA to support ISUP, while it is rather nice to have for SUA. Regards /Ilie On 11/7/06, Brian F. G. Bidulock <[email protected]> wrote: > Ilie, > > It is broken in a similar sense to CIC: what is lacking is a > notification procedure for notifying ASPs when a DRN/TID label range is > not being served by any ASP within the AS. The SUA RFC describes the SG > as sending these messages to any active ASP and the problem ensues > again. Coupled with the multiple SG as STP scenario, lack of a > notification procedure is further aggravated. LOADSEL/LOADGRP provide a > superior mechanism for load distribution and activation of DRN/TID label > ranges. Also, they provide a sensible notification procedure and > specified fail over procedures that allows ASPs to determine what > happens to ranges that are not being served. > > All in all, I do not see much difference between managing call state > (CIC) and managing transaction/connection state (TID/DRN). That is why > all three are included in the LOADSEL/LOADGRP drafts. > > --brian > > Ilie Glib wrote: (Tue, 07 Nov 2006 00:59:38) > > Brian, > > > > I do not agree that TID and DRN is a broken loadsharing scheme. > > It works perfectly, although it cannot use TID and DRN ranges dynamically. > > Even that is possible with AS internal communication. > > > > /Ilie > > > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ > -- Ilie