RE: SUA: CLDT: RC Parameter
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Hi Howard, Please see for comments below. Thanks, Tolga > -----Original Message----- > From: May, Howard [mailto:[email protected]] > Sent: Thursday, June 01, 2006 5:34 AM > To: [email protected]; Ilie Glib > Cc: sigtran; Tolga Asveren > Subject: RE: [Sigtran] SUA: CLDT: RC Parameter > > > Brian, Ilie, > > My understanding is that in SE operation a RC relates to a signalling > relationship between two ASs. Therefore if you have two ASPs each with > 'N' ASes wishing to talk to the other ASPs 'N' ASes then N*N RC values > are required. [TOLGA]Yes, you are right that in IPSP-SE RC identifies a signaling relationship between two AS, which are hosted on two IPSPs. > > An AS may be independantly ACTIVE or INACTIVE for each signalling > relationship it is configured with. > > I don't understand why it is advantageous to comment on what the Routing > Key assoicated with this RC is. To force the Routing Key to be made > from the Source and Destination AS addresses does seem to restrict Relay > operation. [TOLGA]RC needs to identify both ends of traffic flow, because it relates to a signaling relationship between two AS. This is different than the ASP/SGP relationship, which is a client/server model, where traffic range is defined only from AS point of view, which is hosted on ASP. For IPSP, there are two AS, one on each end. IPSP mode of operation doesn't support relaying on SIGTRAN signaling level, not because of some deficiency, but because it never was intended to do so, it is used for direct communication between two peers. It is still possible to use IPSP model for relaying messages, but this needs to happen on application level. > > Regards > > Howard > > >-----Original Message----- > >From: Brian F. G. Bidulock [mailto:[email protected]] > >Sent: 01 June 2006 09:17 > >To: Ilie Glib > >Cc: sigtran; Tolga Asveren > >Subject: Re: [Sigtran] SUA: CLDT: RC Parameter > > > >Ilie, > > > >That's only because M3UA IPSP does not support relay. SUA IPSP does. > >I don't think that we want to rule out relay for SUA IPSP. > > > >--brian > > > >Ilie Glib wrote: (Thu, 01 Jun 2006 10:05:06) > >> Hello Tolga, > >> > >> my assumption was that each AS in the picture below is defined by its > >> destination address only, and there is no source address in the RK > >> definition. For instance, I have AS1=SSN1, AS2=SSN2 on one side, and > >> AS3=SSN3, AS4=SSN4 on the other side. This is possible according to > >> SUA RFC, and it shall work in single exchange mode (M3UA RFCbis does > >> not allow this configuration for SE mode, and mandates that > >RK defines > >> both source and destination addresses when SE is in use), unless we > >> explicitly prohibit this configuration in SUA implementers' guide, > >> that is, make source and destination addresses mandatory parts of SUA > >> RK definition in SE as M3UA does. > >> > >> Thank you > >> > >> Ilie > > > >-- > >Brian F. G. Bidulock > >[email protected] > >http://www.openss7.org/ > > > >_______________________________________________ > >Sigtran mailing list > >[email protected] > >https://www1.ietf.org/mailman/listinfo/sigtran > >