Re: Behaviour in DE-IPSP model when ASPAC does not haveany RC.

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Anand,

Your example does not make any sense to me: you did know that for
DE mode to work, each AS must be defined at either end of the
association and that a separate RK, RS and AS must be defined
for each direction of traffic?

Please provide the real-world RK's for the AS in your example.

--brian

Anand N Ilkal wrote:                 (Thu, 25 Mar 2010 20:23:47)
> 
>    Hello Brian,
>    could you please provide your thoughts on the scenario earlier
>    explained?
>    re-produced just for clarification...
>    My doubt is if the following scenario is correct in Double Exchange
>    mode-
> 
>    IPSP A IPSP B
>    LAS1 RC=100 RAS1 RC=300
>    ---------- LASP1 ------------ RASP1
>    LAS2 RC=200
>    ---------- LASP1
>    INIT --------------------------------------------------------------->
>    <----------------------------------------------------------------
>    INIT_ACK
>    COOKIE_ECHO
>    -------------------------------------------------------------->
>    <----------------------------------------------------------------
>    COOKIE_ACK
>    <----------------------------------------------------------------
>    ASPUP
>    ASPUP_ACK
>    --------------------------------------------------------------->
>    <----------------------------------------------------------------
>    ASPAC (without RC)
>    ASPAC_ACK
>    ---------------------------------------------------------------->
> 
>    IPSP A marks LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its stack
>    after receiving ASPAC without any RC, similarly after receiving
>    ASPAC_ACK IPSP B will mark LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE
>    in its stack. And Hence there is no need for sending ASPAC from IPSP
>    A.

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.