RE: SUA: CLDT: RC Parameter
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Hi Ilie,
Oh O.K., I see your point. Yes, the clarification added in M3UA-IG should be
there in SUA-IG as well. SE-IPSP model is a peer-to-peer signaling
relationship where the peers are the IPSP on each side, hence it should be
identified by declaring the traffic range used for this relationship for
both AS.
Thanks,
Tolga
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Thursday, June 01, 2006 4:05 AM
> To: Tolga Asveren
> Cc: sigtran
> Subject: Re: [Sigtran] SUA: CLDT: RC Parameter
>
>
> 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
>
> On 6/1/06, Tolga Asveren <[email protected]> wrote:
> > Ilie,
> >
> > I may be missing something, but if you use different RC for AS1/AS# and
> > AS1/AS4 relationships, would there be any problem?
> >
> > Thanks,
> > Tolga
> >
> > > -----Original Message-----
> > > From: Ilie Glib [mailto:[email protected]]
> > > Sent: Wednesday, May 31, 2006 2:45 PM
> > > To: [email protected]; May, Howard; sigtran
> > > Subject: Re: [Sigtran] SUA: CLDT: RC Parameter
> > >
> > >
> > > Hello Brian, May,
> > >
> > > I think, in case of IPSP to IPSP model, there are two ASes (AS1 and
> > > AS2), one at each side. For SE-IPSP implies activation of both ASes
> > > via one ACTIVE message, the RC exchanged in the ACTIVE message shall
> > > identify both ASes. Consequently RC1 = RC2. Since RC values are
> > > allocated by SGPF, SGPF shall assign RC values consistently. Probably
> > > the only feasible way to assign RCs is by provisioning for SE model.
> > >
> > > I have some doubts about the case when an IPSP serves multiple ASes
> > > and SE-IPSP model is in use. Is this situation possible, can AS1 talk
> > > to AS3 and AS4
> > >
> > > IPSP1 ----------------------------- IPSP2
> > >
> > > AS1 <---------------------------------> AS3
> > > |
> > > AS2 --------------> AS4
> > >
> > >
> > > How can AS4 go inactive, while AS3 be active in SE model?
> > >
> > > Thank you in advance
> > >
> > > Ilie
> > >
> > > On 5/31/06, Brian F. G. Bidulock <[email protected]> wrote:
> > > > Hi Howard,
> > > >
> > > > Please see comments below...
> > > >
> > > > May, Howard wrote: (Wed, 31 May 2006
> > > 10:53:12)
> > > > > Hi,
> > > > >
> > > > > The RC parameter is mandatory in CLDT messages. Please can
> > > you check my
> > > > > understanding of how this parameter should be used in the three
> > > > > following situations.
> > > > >
> > > > > When a CLDT is sent from an SGP to an ASP the value this parameter
> > > > > should be set to is the RC of the AS the message is for.
> The ASP may
> > > > > use this parameter for local distribution of the message.
> > > >
> > > > Yes.
> > > >
> > > > >
> > > > > When a CLDT is sent from an ASP to an SGP the value this parameter
> > > > > should be set to is the RC of the AS the message is from.
> The SGP may
> > > > > use this parameter to determine the Network Context
> applicable to the
> > > > > CLDT.
> > > >
> > > > Yes, and any other restrictions or permissions that might
> be associated
> > > > with the AS at the SGP (such as calling party address).
> > > >
> > > > >
> > > > > When a CLDT is sent from an IPSP to an IPSP the value
> this parameter
> > > > > should be set to is the RC of the AS the message is for.
> The IPSP may
> > > > > use this parameter for local distribution of the message.
> > > >
> > > > For SE-IPSP, the AS the message is for and the AS the message
> > > is from are
> > > > the same. For DE-IPSP, because messages are essentially sent
> > > from the SGPF
> > > > to the ASPF in the criss-cross model, the AS is the As that the
> > > message is
> > > > for just as in the SGP->ASP case above.
> > > >
> > > > --brian
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email protected]
> > > > http://www.openss7.org/
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > > --
> > > Ilie
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran