Signaling Transport (sigtran)

headers Kalyanaraman.Madhavan | 2 Nov 2005 09:37

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Madhavan,

Hope  SGW might have received the ERROR msg with "Invalid Routing
Context" but links should not go down.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid> <at> ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Wed, 2 Nov 2005 Kalyanaraman.Madhavan <at> alcatel.com wrote:

> Hi Samuel,
> 
> Thanks for reply.Currently an error is generated for this parameter &
> links are set to unavailable.
> 
> But the definition for parameter in RFC states,
> 
> Parameter Length: 16 bits (unsigned integer)
> 
>       The Parameter Length field contains the size of the parameter in
>       bytes, including the Parameter Tag, Parameter Length, and
>       Parameter Value fields.  Thus, a parameter with a zero-length
>       Parameter Value field would have a Length field of 4.  The
>       Parameter Length does not include any padding bytes."
> 
> In this case, RC parameter is received complying to above. For this an
> ERROR is reported from AS as you have stated below. The links are
> unavailable due to this communication in loop.
> 
> Kind Regards,Madhavan
> 
> Samuel Dur D. Jeyaseelan wrote:
> 
> Madhavan,
> 
> pls see my comments inline.
> 
> --Samuel
> 
>   Alcatel USA, Inc.                  Internet: <userid> <at> ssd.usa.alcatel.com
>   1000 Coit Road, Plano, Texas 75075
>   ******* The opinions expressed are not those of Alcatel USA, Inc. *******
> 
> On Mon, 31 Oct 2005 Kalyanaraman.Madhavan <at> alcatel.com wrote:
> 
>   
> 
> Hi !!
> 
> I am currently involved in configuration of SGW to AS(doing this type of 
> configuration for first time) & need following clarification as I cannot 
> pick this out in clear way from RFC.
> 
> Scenario:
> 
> - AS sends DAUD to SGW without Routing Context
> - AS receives DAVA with routing context parameter.The contents are tag 
> id & length of the parameter without any value.In this case the length 
> is 4 bytes (2 bytes for tag id & 2 bytes for length field itself)
> 
> Question:
> 
> Since AS has not sent a RC in DAUD, i assume the field should not be 
> received in DAVA.Is my assumption inline with RFC ?
>     
> 
> RC is a 'conditional' parameter that means it is very much needed when an
> ASP serves more than one AS. In your case if the received RC does not find
> any match in the static or dynamic databases then it is appropriate to
> send an ERROR msg to SGW.
> 
>   
> 
> Thank you in advance,
> 
> Kind Regards,Madhavan
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
>     
> 
>   
> 
> 
> 
> 

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Mark,

A couple comments:

Q1) I think it is clear that LSPO does not clear LSB, only LSBE does.
   Under M2PA both PO and Busy conditions can exist at the same time.

Q2) I think buffered messages are buffered messages, regardless of
   what condition prevailed when they were buffered.  When M2PA exits
   PO state and Busy still prevails, I think the text is clear with
   regard to how data messages are treated before LSBE is sent or
   received, in the passages you quoted.

--brian

Davidson, Mark wrote:                         (Wed, 02 Nov 2005 08:21:20)
> 
>    Flow control RFC text included at bottom for convenience...
> 
> 
> 
>    Trying to sort out Busy/Busy End and LPO/ LPO End interactions.
> 
> 
> 
>    The Level 2 flow control text doesn't say anything about buffering
> 
>    during local busy (just says don't ack), but I'm assuming that's
> 
>    the intent, i.e. to avoid retransmissions since M2PA doesn't
> 
>    retransmit. (I'm a little confused as to why LPOR needs those
> 
>    LSRs afterwards but LSBE doesn't, but that's not my real question.)
> 
> 
> 
>    Anyway, it gets really interesting when you have a (local)
> 
>    busy condition, then LPO condition.  MTP2 spec is clear - Stop
> 
>    T5, move to PO state. When PO ends, MSUs may again trigger
> 
>    Busy condition, but if there's no traffic, then no Busy condition.
> 
> 
> 
>    The reverse, LPO followed by Busy does not occur in MTP2 because
> 
>    MSUs are discarded in LPO, so busy is not triggered.
> 
> 
> 
>    Question 1. In M2PA , should an LSBE be expected in the case where
> 
>    there is a local busy followed by LPO? It seems unnecessary to
> 
>    me - the LSPO message should imply an end to the Busy condition.
> 
>    Buffered Busy messages can become buffered LPO messages that are
> 
>    acked during LPO recovery.
> 
> 
> 
>    Question 2. Assuming traffic is buffered in M2PA during local busy,
> 
>    it is possible that the busy condition may not subside during a
> 
>    transient LPO condition.  I.e. LPO ends but queues are still backed
> 
>    up.  Should the Busy resume? What should be acked? Should we wait
> 
>    for the LSRs to be exchanged before sending LSB?
> 
> 
> 
>    -Mark Davidson
> 
> 
> 
>    From the RFC:
> 
> 
> 
>    4.1.5.  Level 2 Flow Control
> 
> 
> 
>       The Link Status Busy message replaces the SIB message of MTP2.  The
>       message SHOULD NOT be transmitted continuously.  M2PA SHALL send a
>       Link Status Busy message to its peer at the beginning of a receive
>       congestion condition where MTP2 would send SIB.  M2PA MAY send
>       additional Link Status Busy messages as long as that condition
>       persists.  When the condition ends, M2PA SHALL send a Link Status
>       Busy Ended message to its peer.
> 
> 
> 
>       M2PA SHALL continue transmitting messages while it is in receive
>       congestion, but MUST NOT acknowledge the message that triggered the
>       sending of the Link Status Busy message, nor any messages received
>       before the sending of Link Status Busy Ended.
> 
> 
> 
>       When the peer M2PA receives the first Link Status Busy message, it
>       SHALL start the Remote Congestion timer T6 if there are messages in
>       the retransmission buffer awaiting acknowledgement (i.e., T7 is
>        running).   M2PA  SHALL  stop  the  T7  timer  if  it  is running.
>    Additional
>       Link Status Busy messages received while T6 is running do not cause
>       T6 to be reset and do not cause T7 to be started.  While T6 is
>       running, T7 SHALL NOT be started.
> 
> 
> 
>        When the peer M2PA receives the Link Status Busy Ended message and
>    T6
>        has  not expired, it SHALL stop T6 (if T6 is running) and start T7
>    (if
>       there are messages awaiting acknowledgement in the retransmission
>       buffer).
> 
> 
> 
>       The peer M2PA SHOULD continue receiving and acknowledging messages
>       while the other end is busy, but MUST NOT send User Data messages
>       after receiving Link Status Busy and before receiving Link Status
>       Busy Ended.

> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Brian,

>Q1) I think it is clear that LSPO does not clear LSB, only LSBE does.

It is clear how a busy clear condition is signaled, but not when it
ends.
There is a difference. 

>   Under M2PA both PO and Busy conditions can exist at the same time.

Works for me, but where does it say that?

>Q2) I think buffered messages are buffered messages, regardless of
>   what condition prevailed when they were buffered.  When M2PA exits
v   PO state and Busy still prevails, I think the text is clear with
>   regard to how data messages are treated before LSBE is sent or
>   received, in the passages you quoted.

The text I quoted says NOTHING about buffering received msgs, so I 
don't see how it can be clear on the subject.

Anyway, I think this is your interpretation:

During local busy OR LPO (or both) buffer and do not acknowledge
received MSUs.

When BOTH conditions are cleared, process and acknowledged buffered
messages.  This is handled explicitly by PO procedures, for local busy 
an ack must be sent if there was at least one data message buffered 
(per other text requiring immediate ack).

Local busy can continue during LPO and still be in effect after LPO
ends.

-Mark

>
>--brian
>
>Davidson, Mark wrote:                         (Wed, 02 Nov 2005
08:21:20)
>> 
>>    Flow control RFC text included at bottom for convenience...
>> 
>> 
>> 
>>    Trying to sort out Busy/Busy End and LPO/ LPO End interactions.
>> 
>> 
>> 
>>    The Level 2 flow control text doesn't say anything about buffering
>> 
>>    during local busy (just says don't ack), but I'm assuming that's
>> 
>>    the intent, i.e. to avoid retransmissions since M2PA doesn't
>> 
>>    retransmit. (I'm a little confused as to why LPOR needs those
>> 
>>    LSRs afterwards but LSBE doesn't, but that's not my real
question.)
>> 
>> 
>> 
>>    Anyway, it gets really interesting when you have a (local)
>> 
>>    busy condition, then LPO condition.  MTP2 spec is clear - Stop
>> 
>>    T5, move to PO state. When PO ends, MSUs may again trigger
>> 
>>    Busy condition, but if there's no traffic, then no Busy condition.
>> 
>> 
>> 
>>    The reverse, LPO followed by Busy does not occur in MTP2 because
>> 
>>    MSUs are discarded in LPO, so busy is not triggered.
>> 
>> 
>> 
>>    Question 1. In M2PA , should an LSBE be expected in the case where
>> 
>>    there is a local busy followed by LPO? It seems unnecessary to
>> 
>>    me - the LSPO message should imply an end to the Busy condition.
>> 
>>    Buffered Busy messages can become buffered LPO messages that are
>> 
>>    acked during LPO recovery.
>> 
>> 
>> 
>>    Question 2. Assuming traffic is buffered in M2PA during local
busy,
>> 
>>    it is possible that the busy condition may not subside during a
>> 
>>    transient LPO condition.  I.e. LPO ends but queues are still
backed
>> 
>>    up.  Should the Busy resume? What should be acked? Should we wait
>> 
>>    for the LSRs to be exchanged before sending LSB?
>> 
>> 
>> 
>>    -Mark Davidson
>> 
>> 
>> 
>    From the RFC:
> 
> 
> 
>    4.1.5.  Level 2 Flow Control
> 
> 
> 
>       The Link Status Busy message replaces the SIB message of MTP2.
The
>       message SHOULD NOT be transmitted continuously.  M2PA SHALL send
a
>       Link Status Busy message to its peer at the beginning of a
receive
>       congestion condition where MTP2 would send SIB.  M2PA MAY send
>       additional Link Status Busy messages as long as that condition
>       persists.  When the condition ends, M2PA SHALL send a Link
Status
>       Busy Ended message to its peer.
> 
> 
> 
>       M2PA SHALL continue transmitting messages while it is in receive
>       congestion, but MUST NOT acknowledge the message that triggered
the
>       sending of the Link Status Busy message, nor any messages
received
>       before the sending of Link Status Busy Ended.
> 
> 
> 
>       When the peer M2PA receives the first Link Status Busy message,
it
>       SHALL start the Remote Congestion timer T6 if there are messages
in
>       the retransmission buffer awaiting acknowledgement (i.e., T7 is
>        running).   M2PA  SHALL  stop  the  T7  timer  if  it  is
running.
>    Additional
>       Link Status Busy messages received while T6 is running do not
cause
>       T6 to be reset and do not cause T7 to be started.  While T6 is
>       running, T7 SHALL NOT be started.
> 
> 
> 
>        When the peer M2PA receives the Link Status Busy Ended message
and
>    T6
>        has  not expired, it SHALL stop T6 (if T6 is running) and start
T7
>    (if
>       there are messages awaiting acknowledgement in the
retransmission
>       buffer).
> 
> 
> 
>       The peer M2PA SHOULD continue receiving and acknowledging
messages
>       while the other end is busy, but MUST NOT send User Data
messages
>       after receiving Link Status Busy and before receiving Link
Status
>       Busy Ended.

> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Hi,
I had a specific question related to a specific scenario explained below
(Single Exchange scenario)

NodeA supports 1 PS with 1 IPSP
NodeB supports 1 PS with 2 IPSPs in Loadshared mode.

There are two associations between NodeA and NodeB. 
The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). 
The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).

The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, 
send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means that IPSP2 and
IPSP3, 
serving a loadshared PS2, are essentially telling NodeA to loadshare all the
traffic 
for PS2, between IPSP2 and IPSP3.

The above concepts are also illustrated below....(I have purposefully
avoided AS-ACTIVE notification)

         NodeA                   <------------NodeB------------>

         PS1-IPSP1               PS2-IPSP2                 PS2-IPSP3
          |                        |                          |
          |<-----ASP Up------------|                          |
          |-------ASP Up Ack------>| (Assoc #1)               |
          |                        |                          |
          |                        |                          |
          |<--------------------ASP Up------------------------| (Assoc #2)
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |                        |                          |
          |                        |                          |
          |<--ASP Active(Ldshr)----|                          |
          |------ASP Active Ack--->|                          |
          |                        |                          |
          |                        |                          |
          |                        |                          |
          |<--------------------ASP Active(Ldshr)-------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |                        |                          |
          |---NOTIFY(AS-ACTIVE)--->|                          |
          |--------------------------NOTIFY(AS-ACTIVE)------->|
          |                        |                          |

Questions:
Assuming a single exchange scenario, would the traffic towards PS1 on NodeA,

be also loadshared across 2 associations ?

I thought it would and hence another follow-up question:
It looks like a loadshared peer (NodeB in our case) with  multiple IPSPs,
is putting a constraint on the NodeA, to ALSO be ready to receive data on 
multiple associations and possibly loadshared. Is this a fair understanding
?

shashank

Shashank,

As far as I understand your question:

You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC for this RK
to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing mode. You are
wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3.

Yes, it can, but I wouldn't call it traffic being loadshared to IPSP1. IPSP2
and IPSP3 are not the same entities. OTOH it makes sense to speak of
loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a
single source is distrubuted to multiple peers.

   Tolga

> -----Original Message-----
> From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Friday, November 04, 2005 9:48 AM
> To: 'sigtran <at> ietf.org'
> Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Hi,
> I had a specific question related to a specific scenario explained below
> (Single Exchange scenario)
>
> NodeA supports 1 PS with 1 IPSP
> NodeB supports 1 PS with 2 IPSPs in Loadshared mode.
>
>
> There are two associations between NodeA and NodeB.
> The first association is between IPSP1 (NodeA) and IPSP2 (NodeB).
> The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).
>
> The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB,
> send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means
> that IPSP2 and
> IPSP3,
> serving a loadshared PS2, are essentially telling NodeA to
> loadshare all the
> traffic
> for PS2, between IPSP2 and IPSP3.
>
> The above concepts are also illustrated below....(I have purposefully
> avoided AS-ACTIVE notification)
>
>
>
>          NodeA                   <------------NodeB------------>
>
>          PS1-IPSP1               PS2-IPSP2                 PS2-IPSP3
>           |                        |                          |
>           |<-----ASP Up------------|                          |
>           |-------ASP Up Ack------>| (Assoc #1)               |
>           |                        |                          |
>           |                        |                          |
>           |<--------------------ASP Up------------------------| (Assoc #2)
>           |----------------------------ASP Up Ack------------>|
>           |                        |                          |
>           |                        |                          |
>           |                        |                          |
>           |<--ASP Active(Ldshr)----|                          |
>           |------ASP Active Ack--->|                          |
>           |                        |                          |
>           |                        |                          |
>           |                        |                          |
>           |<--------------------ASP Active(Ldshr)-------------|
>           |----------------------------ASP Up Ack------------>|
>           |                        |                          |
>           |                        |                          |
>           |---NOTIFY(AS-ACTIVE)--->|                          |
>           |--------------------------NOTIFY(AS-ACTIVE)------->|
>           |                        |                          |
>
>
>
> Questions:
> Assuming a single exchange scenario, would the traffic towards
> PS1 on NodeA,
>
> be also loadshared across 2 associations ?
>
> I thought it would and hence another follow-up question:
> It looks like a loadshared peer (NodeB in our case) with  multiple IPSPs,
> is putting a constraint on the NodeA, to ALSO be ready to receive data on
> multiple associations and possibly loadshared. Is this a fair
> understanding
> ?
>
>
> shashank
>
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>

Thanx Tolga. U are right in understanding my question.

Followup Question:
Since IPSP2 and IPSP3 are serving the same AS, what would determine at
NodeB, if the traffic to IPSP1 is 
to be sent via IPSP2 or IPSP3 ?

shashank

-----Original Message-----
From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org]On
Behalf Of Tolga Asveren
Sent: Friday, November 04, 2005 8:13 PM
To: sigtran <at> ietf.org
Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

As far as I understand your question:

You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC for this RK
to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing mode. You are
wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3.

Yes, it can, but I wouldn't call it traffic being loadshared to IPSP1. IPSP2
and IPSP3 are not the same entities. OTOH it makes sense to speak of
loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a
single source is distrubuted to multiple peers.

   Tolga

> -----Original Message-----
> From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Friday, November 04, 2005 9:48 AM
> To: 'sigtran <at> ietf.org'
> Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Hi,
> I had a specific question related to a specific scenario explained below
> (Single Exchange scenario)
>
> NodeA supports 1 PS with 1 IPSP
> NodeB supports 1 PS with 2 IPSPs in Loadshared mode.
>
>
> There are two associations between NodeA and NodeB.
> The first association is between IPSP1 (NodeA) and IPSP2 (NodeB).
> The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).
>
> The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB,
> send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means
> that IPSP2 and
> IPSP3,
> serving a loadshared PS2, are essentially telling NodeA to
> loadshare all the
> traffic
> for PS2, between IPSP2 and IPSP3.
>
> The above concepts are also illustrated below....(I have purposefully
> avoided AS-ACTIVE notification)
>
>
>
>          NodeA                   <------------NodeB------------>
>
>          PS1-IPSP1               PS2-IPSP2                 PS2-IPSP3
>           |                        |                          |
>           |<-----ASP Up------------|                          |
>           |-------ASP Up Ack------>| (Assoc #1)               |
>           |                        |                          |
>           |                        |                          |
>           |<--------------------ASP Up------------------------| (Assoc #2)
>           |----------------------------ASP Up Ack------------>|
>           |                        |                          |
>           |                        |                          |
>           |                        |                          |
>           |<--ASP Active(Ldshr)----|                          |
>           |------ASP Active Ack--->|                          |
>           |                        |                          |
>           |                        |                          |
>           |                        |                          |
>           |<--------------------ASP Active(Ldshr)-------------|
>           |----------------------------ASP Up Ack------------>|
>           |                        |                          |
>           |                        |                          |
>           |---NOTIFY(AS-ACTIVE)--->|                          |
>           |--------------------------NOTIFY(AS-ACTIVE)------->|
>           |                        |                          |
>
>
>
> Questions:
> Assuming a single exchange scenario, would the traffic towards
> PS1 on NodeA,
>
> be also loadshared across 2 associations ?
>
> I thought it would and hence another follow-up question:
> It looks like a loadshared peer (NodeB in our case) with  multiple IPSPs,
> is putting a constraint on the NodeA, to ALSO be ready to receive data on
> multiple associations and possibly loadshared. Is this a fair
> understanding
> ?
>
>
> shashank
>
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

This is implementation/traffic type dependent and is not something
standardized by M3UA.

> -----Original Message-----
> From: Prasad, Shashank S (Shashank) [mailto:ssprasad <at> lucent.com]
> Sent: Friday, November 04, 2005 10:28 AM
> To: 'Tolga Asveren'; sigtran <at> ietf.org
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Thanx Tolga. U are right in understanding my question.
>
> Followup Question:
> Since IPSP2 and IPSP3 are serving the same AS, what would determine at
> NodeB, if the traffic to IPSP1 is
> to be sent via IPSP2 or IPSP3 ?
>
>
> shashank
>
> -----Original Message-----
> From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org]On
> Behalf Of Tolga Asveren
> Sent: Friday, November 04, 2005 8:13 PM
> To: sigtran <at> ietf.org
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Shashank,
>
> As far as I understand your question:
>
> You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC
> for this RK
> to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing
> mode. You are
> wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3.
>
> Yes, it can, but I wouldn't call it traffic being loadshared to
> IPSP1. IPSP2
> and IPSP3 are not the same entities. OTOH it makes sense to speak of
> loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a
> single source is distrubuted to multiple peers.
>
>    Tolga
>
> > -----Original Message-----
> > From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org]On
> > Behalf Of Prasad, Shashank S (Shashank)
> > Sent: Friday, November 04, 2005 9:48 AM
> > To: 'sigtran <at> ietf.org'
> > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Hi,
> > I had a specific question related to a specific scenario explained below
> > (Single Exchange scenario)
> >
> > NodeA supports 1 PS with 1 IPSP
> > NodeB supports 1 PS with 2 IPSPs in Loadshared mode.
> >
> >
> > There are two associations between NodeA and NodeB.
> > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB).
> > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).
> >
> > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB,
> > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means
> > that IPSP2 and
> > IPSP3,
> > serving a loadshared PS2, are essentially telling NodeA to
> > loadshare all the
> > traffic
> > for PS2, between IPSP2 and IPSP3.
> >
> > The above concepts are also illustrated below....(I have purposefully
> > avoided AS-ACTIVE notification)
> >
> >
> >
> >          NodeA                   <------------NodeB------------>
> >
> >          PS1-IPSP1               PS2-IPSP2                 PS2-IPSP3
> >           |                        |                          |
> >           |<-----ASP Up------------|                          |
> >           |-------ASP Up Ack------>| (Assoc #1)               |
> >           |                        |                          |
> >           |                        |                          |
> >           |<--------------------ASP Up------------------------|
> (Assoc #2)
> >           |----------------------------ASP Up Ack------------>|
> >           |                        |                          |
> >           |                        |                          |
> >           |                        |                          |
> >           |<--ASP Active(Ldshr)----|                          |
> >           |------ASP Active Ack--->|                          |
> >           |                        |                          |
> >           |                        |                          |
> >           |                        |                          |
> >           |<--------------------ASP Active(Ldshr)-------------|
> >           |----------------------------ASP Up Ack------------>|
> >           |                        |                          |
> >           |                        |                          |
> >           |---NOTIFY(AS-ACTIVE)--->|                          |
> >           |--------------------------NOTIFY(AS-ACTIVE)------->|
> >           |                        |                          |
> >
> >
> >
> > Questions:
> > Assuming a single exchange scenario, would the traffic towards
> > PS1 on NodeA,
> >
> > be also loadshared across 2 associations ?
> >
> > I thought it would and hence another follow-up question:
> > It looks like a loadshared peer (NodeB in our case) with
> multiple IPSPs,
> > is putting a constraint on the NodeA, to ALSO be ready to
> receive data on
> > multiple associations and possibly loadshared. Is this a fair
> > understanding
> > ?
> >
> >
> > shashank
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

3	May 2013
1	April 2013
5	March 2013
1	February 2013
3	January 2013
2	December 2012
8	October 2012
6	July 2012
9	April 2012
6	December 2011
2	November 2011
8	October 2011
21	September 2011
16	August 2011
19	July 2011
6	June 2011
2	May 2011
38	April 2011
25	March 2011
20	February 2011
29	January 2011
25	November 2010
28	October 2010
29	September 2010
2	August 2010
2	July 2010
11	June 2010
11	May 2010
16	April 2010
63	March 2010
7	February 2010
6	January 2010
27	December 2009
20	November 2009
27	October 2009
4	September 2009
3	August 2009
55	July 2009
18	June 2009
5	May 2009
9	April 2009
39	March 2009
31	February 2009
8	January 2009
24	December 2008
7	November 2008
21	October 2008
24	September 2008
5	August 2008
30	July 2008
18	June 2008
19	May 2008
16	April 2008
30	March 2008
33	February 2008
16	January 2008
38	December 2007
48	November 2007
26	October 2007
22	September 2007
37	August 2007
81	July 2007
76	June 2007
76	May 2007
85	April 2007
43	March 2007
51	February 2007
72	January 2007
70	December 2006
173	November 2006
168	October 2006
107	September 2006
43	August 2006
64	July 2006
120	June 2006
99	May 2006
6	April 2006
38	March 2006
266	February 2006
201	January 2006
205	December 2005
169	November 2005
303	October 2005
69	September 2005
13	August 2005
53	July 2005
42	June 2005
10	May 2005
48	April 2005
54	March 2005
38	February 2005
18	January 2005
46	December 2004
12	November 2004
38	October 2004
65	September 2004
95	August 2004
60	July 2004
83	June 2004
118	May 2004
43	April 2004
44	March 2004
105	February 2004
77	January 2004
54	December 2003
15	November 2003
76	October 2003
207	September 2003
112	August 2003
336	July 2003
192	June 2003
182	May 2003
168	April 2003
330	March 2003
453	February 2003
551	January 2003
355	December 2002
186	November 2002
218	October 2002
245	September 2002
127	August 2002
223	July 2002
371	June 2002
453	May 2002
373	April 2002

Re: RFC3332: RC in DAVA Message

Re: RFC3332: RC in DAVA Message

M2PA busy/lpo questions

Re: M2PA busy/lpo questions

RE: M2PA busy/lpo questions

Doubt regarding Error codes

M3UA: 1IPSP - multiple IPSPs traffic flow

RE: M3UA: 1IPSP - multiple IPSPs traffic flow

RE: M3UA: 1IPSP - multiple IPSPs traffic flow

RE: M3UA: 1IPSP - multiple IPSPs traffic flow