RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Tolga,
I agree with ur point. In a Single Ended exchange, the Traffic Mode in the
ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending
ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each
other.

Some more important points:
The ASPAC message can have multiple (n)  Routing Contexts.
And therefore the Traffic Mode sent in the ASP-Ack must also have the
Traffic Mode per Routing Context.

Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u
agree ?



However, there is still a catch.
The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages.
At present, M3UA has left to the implementators on how to interpret Traffic
Modes of each other, in case, the peers do NOT exchange Traffic Modes.

I was therefore suggesting that we could have M3UA suggest a default
implementation of Traffic Mode, and rather NOT leave to the implementation.
And I suggested Override, because, I would always believe that whenever a
node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our
discussion), without any Traffic Mode (since it is Optional), it shall
interpret that the peer intends to use this ASP for its communication.


At the same time, we ALSO have ur suggestion about IPSPs sending their
respective Traffic modes in ASPAC-Ack messages.


shashank


-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Tolga Asveren
Sent: Saturday, November 05, 2005 1:42 AM
To: [email protected]
Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow


Shashank,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Friday, November 04, 2005 2:08 PM
> To: [email protected]
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Reply embedded.
>
> shashank
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Tolga Asveren
> Sent: Friday, November 04, 2005 10:09 PM
> To: [email protected]
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Shashank,
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Prasad, Shashank S (Shashank)
> > Sent: Friday, November 04, 2005 11:07 AM
> > To: 'Tolga Asveren'; [email protected]
> > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Oh OK !
> > Looks like, it could potentially happen that NodeB can limit itself to
> > sending traffic for PS1 on only one of associations also, rather
> > than both.
> > However, IPSP1 has really to "listen" at both the associations.
> > Is that correct ?
> [TOLGA]Yes. Please also note that it is the M3UA-User which controls this
> behavior on Node-B, i.e. this is not loadhsaring on M3UA level
> but one layer
> above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When
> they receive a
> message from their user, they will send it to IPSP1.
>
> [SHASHANK] OK, I get ur point related to the role of M3UA User.
>
>
>
>
> >
> > A couple of more questions that now comes up:
> > 1. In a single ended scenario, how could have IPSP1 (at NodeA)
> determined
> > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent
> from IPSP1 to
> > IPSP2 and IPSP3 ? (Instead of what is shown my illustration)
> [TOLGA]Through local configuration, please note Traffic Mode parameter is
> optional. OTOH, I think that it could be an idea to modify the protocol a
> bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side
> about traffic mode on the peer side in case it is necessary.
> >
>
> [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to
> inform ASPAC
> sending side
> about traffic mode on the peer side in case it is necessary. That
> will help
> a
> great deal in the single exchange scenarios to exchange the Traffic Modes.
> At present, the M3UA protocol does NOT say anything explicitly on this.
>
> Alternatively, the protocol could also define a default Traffic Mode
> explicitly (possibly Override). And in case the peers do NOT exchange
> the Traffic mode, the default Traffic Mode (as specified in the specs) can
> be used.
>
> Now that we understand the need, do u think that this could be taken up
> further ?
[TOLGA]I am not sure whether it is a good idea to declare a default traffic
mode but allowing both sides to use Traffic Mode parameter makes sense to
me. Similar concept could be applied for SGPs as well, i.e. they declare
their traffic mode with Traffic Mode in ASPAC-ACK -actually this in
practicall life is probably less useful-. Any other opinions about this
issue? It looks like a useful feature to me to use Traffic Mode in both
directions.
>
>
> > 2. In a single exchange scenario, isn't it needed to have the peer ASs
> > having the same Traffic Mode ?
> [TOLGA]I believe what you mean as "AS traffic mode" is traffic
> mode of peer
> IPSPs in the context of an AS. As far as I can see different traffic modes
> shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE
> simultaneously at both sides.
> >
> [SHASHANK] I agree with the answer to my second question.
>
> > shashank
> >
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Tolga Asveren
> > Sent: Friday, November 04, 2005 8:51 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] 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:[email protected]]
> > > Sent: Friday, November 04, 2005 10:28 AM
> > > To: 'Tolga Asveren'; [email protected]
> > > 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: [email protected] [mailto:[email protected]]On
> > > Behalf Of Tolga Asveren
> > > Sent: Friday, November 04, 2005 8:13 PM
> > > To: [email protected]
> > > 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: [email protected] [mailto:[email protected]]On
> > > > Behalf Of Prasad, Shashank S (Shashank)
> > > > Sent: Friday, November 04, 2005 9:48 AM
> > > > To: '[email protected]'
> > > > 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
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>



_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran