Kalyanaraman.Madhavan | 2 Nov 09:37 2005
Picon

Re: RFC3332: RC in DAVA Message

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
Samuel Dur D. Jeyaseelan | 2 Nov 09:54 2005
Picon

Re: RFC3332: RC in DAVA Message


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
> 
>     
> 
>   
> 
> 
> 
> 
Davidson, Mark | 2 Nov 15:21 2005

M2PA busy/lpo questions

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 | 2 Nov 18:27 2005

Re: M2PA busy/lpo questions

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/
Davidson, Mark | 2 Nov 19:41 2005

RE: M2PA busy/lpo questions

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/
arijit.dilip | 4 Nov 11:12 2005

Doubt regarding Error codes

Hi All,
 
In SUA(RFC 3868) ERR(Error message, Section 3.7.1) message it is written that

Routing Context           Mandatory *1

Network Appearance        Mandatory *1

Affected Point Code       Mandatory *1

Note 1: Only mandatory for specific error codes.

Can I please know for which error codes this parameters are mandatory.
 
Thanks and Regards,
Arijit
 
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Picon

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
Tolga Asveren | 4 Nov 15:43 2005

RE: 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
>
Picon

RE: 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
Tolga Asveren | 4 Nov 16:20 2005

RE: M3UA: 1IPSP - multiple IPSPs traffic flow

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
>

Gmane