RE: DRN and TID Label Issues - Issue #2
"Haresign Lincoln" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB04E8BD1C@us-nj-mail1.comverse.com> |
Brian, When dealing with loadshare, the ASPs are in control of the TID values. I don't see the issue. Regards, Lincoln -----Original Message----- From: Brian F. G. Bidulock [mailto:[email protected]] Sent: Wednesday, October 11, 2006 4:41 PM To: Haresign Lincoln Cc: Barry Nagelberg; [email protected] Subject: Re: DRN and TID Label Issues - Issue #2 Lincoln, The last two sentences speak to Loadshare as well. --brian Haresign Lincoln wrote: (Wed, 11 Oct 2006 16:31:48) > Brian, > > Again, I don't believe Broadcast mode is relevant to TID routing. It > seemed obvious to me. If you feel it is necessary to specify this in > the IG, please indicate and I'm sure we can all agree on some wording. > > Regards, > Lincoln > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:[email protected]] > Sent: Wednesday, October 11, 2006 3:43 PM > To: Haresign Lincoln > Cc: Barry Nagelberg; [email protected] > Subject: DRN and TID Label Issues - Issue #2 > > Lincoln, > > RFC 3868 says: > > 4.1.1. Receipt of Primitives from SCCP > > ... > corresponding SCTP association. If more than one ASP is in the ASP- > ACTIVE state (i.e., traffic is to be load-shared across more than one > ASP), one of the ASPs in the ASP_ACTIVE state is selected from the > list. If the ASPs are in Broadcast Mode, all active ASPs will be > selected and the message sent to each of the active ASPs. The > selection algorithm is implementation dependent but could, for > example, be round robin or based on the SLS. The appropriate > selection algorithm must be chosen carefully as it is dependent on > application assumptions and understanding of the degree of state > coordination between the ASP_ACTIVE ASPs in the AS. > > These last to sentences are in conflict with the use of DRN/TID label. > > --brian > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ -- Brian F. G. Bidulock [email protected] http://www.openss7.org/