RE: M3UA : query on RC presence in messages
"Prabind Chaubey" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <22F058C3ED9D784E90CE473F2A9847F0ADB234@in-exchange> |
Tolga,
According to RFC4666 the state of AS may be considered when
receiving
messages as well:
4.3.4.3 ASP Active Procedures
If the SGP or IPSP receives any Data messages before an ASP Active
message
is received, the SGP or IPSP MAY discard them. By sending an ASP Active
Ack
message, the SGP or IPSP is no ready to receive and send traffic for the
related Routing Context(s).
[PRABIND] The use of MAY leaves it to implementation. Anyways 4666 is
out only recently, so implementations based on 3332 were on their on
own.
You are right that an ASP, which is not active for a particular AS
should
not send messages for it, but I guess for almost every protocol, part of
the
procedures is to check that the other nodes behave properly.
[PRABIND]IMO m3ua was introduced to extend the services of mtp3 to
remote node for a IP user. So it is really just transparent for an user
in IP world.
Regards,
Prabind
-----Original Message-----
From: Tolga Asveren [mailto:[email protected]]
Sent: Thursday, December 14, 2006 12:08 AM
To: [email protected]
Subject: RE: [SIGTRAN] M3UA : query on RC presence in messages
Prabind,
> -----Original Message-----
> From: Prabind Chaubey [mailto:[email protected]]
> Sent: Wednesday, December 13, 2006 1:29 PM
> To: Tolga Asveren; [email protected]
> Subject: RE: [SIGTRAN] M3UA : query on RC presence in messages
>
>
> Lev and Tolga,
> Yes it's has been rightly pointed out by Tolga that the purpose of RC
is
> to provide a faster mechanism to find out the routing key associated
> with the message. But again, do SG should really care about the RC in
> first place if the ASP which is sending the message is active?
Shouldn't
> the AS which is not active must not send any data message to SG? IMO
the
> SG should really care about the RC when sending the messages to AS, as
> we really don't want the SG to send data to an AS which is not
prepared
> to handle it i.e it is not active!
[TOLGA]According to RFC4666 the state of AS may be considered when
receiving
messages as well:
4.3.4.3 ASP Active Procedures
If the SGP or IPSP receives any Data messages before an ASP Active
message
is received, the SGP or IPSP MAY discard them. By sending an ASP Active
Ack
message, the SGP or IPSP is no ready to receive and send traffic for the
related Routing Context(s).
You are right that an ASP, which is not active for a particular AS
should
not send messages for it, but I guess for almost every protocol, part of
the
procedures is to check that the other nodes behave properly.
>
> Regards,
> Prabind
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Wednesday, December 13, 2006 8:35 PM
> To: [email protected]
> Subject: RE: [SIGTRAN] M3UA : query on RC presence in messages
>
> To prevent routing key analysis happening multiple times is one of the
> reasons. There is no need to analyze the message twice both on SG and
> ASP.
>
> When messages are allowed to be sent/received is determined by AS
state
> machine, which has a 1:1 relationship to a RK. To have RC in messages
is
> an
> easy way to perform the necessary state machine updates/checks.
>
> Thanks,
> Tolga
> -----Original Message-----
> From: Lev Finkel [mailto:[email protected]]
> Sent: Wednesday, December 13, 2006 9:39 AM
> To: Aditya; Prabind Chaubey; [email protected]
> Cc: [email protected]
> Subject: RE: [SIGTRAN] M3UA : query on RC presence in messages
>
>
> Aditya, Prabind,
>
> following this logic intelligent ASP also may accept DATA messages
> without
> RC parameter and handle it based on OPC, DPC, CIC, etc. However I
guess
> the
> RFC authors saying MUST intended to avoid variety of ASP and SGP
> implementation dependent behaviors.
>
> Brian,
> what was a real the rationale behind this MUST for RC being in the
> messages?
>
> Regards,
> Lev
>
>
>
>
> From: Aditya [mailto:[email protected]]
> Sent: Wednesday, December 13, 2006 4:25 PM
> To: Prabind Chaubey; [email protected]; Lev Finkel
> Cc: [email protected]
> Subject: RE: [SIGTRAN] M3UA : query on RC presence in messages
>
>
> I agree with Prabind. However, the RFC says "MUST".
>
> Regards,
> Aditya Sehgal
> Alcatel-Lucent
>
> Prabind Chaubey <[email protected]> wrote:
> Brian,
> If it is known by configuration that which AS the asp is going
> to serve into, is it mandatory to send RC from asp, even if the
multiple
> AS are being served by the asp? I mean SG can very well route the
> message to MTP3 based on the DPC in the message.
>
> Regards,
> Prabind
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, December 13, 2006 4:26 PM
> To: Lev Finkel
> Cc: [email protected]
> Subject: Re: [SIGTRAN] M3UA : query on RC presence in messages
>
> Lev,
>
> Section 3.8.1 Error/RFC 4666
>
> ...
>
> The "No Configured AS for ASP" error is sent if a message is received
> from a peer without a Routing Context parameter and it is not known
> by configuration data which Application Servers are referenced.
>
> --brian
>
> Lev Finkel wrote: (Wed, 13 Dec 2006
> 12:00:45)
> >
> > Hi,
> >
> >
> >
> > is the statement in RFC 3332/4466 sections 3.3.1 (and same for
> other
> > messages)
> >
> > "Where multiple Routing Keys and Routing Contexts are used
> across a
> > common association, the Routing Context MUST be sent to identify
> the
> > traffic flow, assisting in the internal distribution of Data
> messages"
> >
> > relates to both ASP and SGP?
> >
> > Is it correct for SGP to reply with ERROR upon DATA message without
> RC
> > after several RC coordinated? Is it mandatory to send ERROR? Or
> M3UA
> > implementation may allow to forward message based on DPC only?
> >
> >
> >
> > Regards,
> >
> > Lev Finkel
> >
> > Veraz Networks ltd.
>
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
>
>
------------------------------------------------------------------------
> ---X
> ----------------------------------------------------
>
> Don't take life too seriously...
> Nobody comes out alive anyway
>
>
> Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran