Subject: Re: M3UA: Routing Context

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 22:55:49 -0500

Greg,

I would like to reopen the issue of adding Routing Context to
DATA messages.  It appears that a number of people were strongly
in favor of this addition.  (John had objections, but those
worm-holed into the Network Appearance discussion.)

Without RC in the DATA message when multiple RCs are multiplexed
over the same association, the ASP is forced to maintain a set
of Routing Keys which must then be applied to the data payload
to determine to which AS the message corresponds.

Including RC in the message means that the ASP does not need to
maintain this RK list.

The reason that there is a problem with ASPs maintaining RK
lists is for the static configuration case.  In the static
configuration case, the SG is permitted by M3UA to have an
arbitrarily complex routing key format (maybe even SSN, TID,
CIC, etc.)  For complex routing keys not supported by the RKM
messages, the ASP will need to be statically provisioned with
Routing Keys.  Because the RK in this case at the SG is
undefined by M3UA, the ASP implementer has little idea what
formats of RK need be supported my M3UA at the ASP.

The AS, on the other hand, as MTP-User knows what RK it needs to
support, but there is no common mechanism for M3UA to record it.
The AS could simply communicate a provisioned RC value to the
ASP when it goes active.

If RC is included in DATA messages as proposed, the ASP does not
need to maintain RK lists in any format other than those
supported by RKM.  Complicated RKs would not need to be applied
by the ASP to the DATA payload to determine the AS and messages
can be simply demultiplexed.

Placing RC in DATA where multiple RC are multiplexed on a single
SCTP association increases interoperability by permitting M3UA
ASP implementations to implicitly support all RK combinations
conceivable at the SG, because the ASP M3UA never has to apply a
RK to the DATA payload, but can still perform its function.
This permits the ASP M3UA implementation to be RK neutral.  RK
need only be understood by AS and SG.

Coupled with the DATA Payload changes on the other thread, this
would permit the ASP M3UA to be protocol variant neutral as
well, further increasing interoperability and easing the burden
from the ASP implementation.

I therefore propose again that we add Routing Context as an
optional parameter to DATA messages which MUST be included when
multiple Routing Contexts are multiplexed over a single SCTP
association.

--brian

BAND,RICHARD (HP-France,ex1) wrote:       (Tue, 24 Jul 2001 17:11:40)
> Brian, all,
> 
> I like the idea of including the RC in a DATA. 
> I agree that it avoids redoing the routing work of the SGP at the ASP, and
> simplifies demultiplexing of traffic for multiple AS.
> So please, do include the RC in the DATA message.
> 
> Regards,
> 
> Richard Band
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: mardi 24 juillet 2001 00:08
> > To: sigtran
> > Cc: [email-masked]; Greg Sidebottom
> > Subject: Re: M3UA: Routing Context
> > 
> > 
> > John,
> > 
> > Please see comments below...
> > 
> > Schantz, John wrote:                                     
> > (Mon, 23 Jul 2001 13:04:29)
> > > Brian,
> > > 	This doesn't really make any sense and I don't see the need.
> > > 
> > > 	Why would you need a routing context in a DATA from SGP 
> > to ASP.  The
> > > ASP should be determining where the message goes locally in 
> > the AS(s) based
> > > on parameters from the SS7 message.
> > > 
> > > 	Requiring it in the DATA from the AS to SG doesn't make 
> > any sense.
> > > The SG should be determining how to forward route the 
> > message based on the
> > > SS7 message parameters (Routing Label).  Why would the 
> > responding AS even
> > > know the RC of a remote node.  Or are you proposing that a 
> > backward RC be
> > > included.  Forward routing should not be based on backward 
> > information.
> > > 
> > > 	Hence, the answer to your question of whether there is 
> > an objection
> > > to including the RC in the DATA message, YES I object.
> > 
> > Is your objection based on the fact that you don't see a need?
> > 
> > Certainly the Routing Context identifies the AS, because there is a
> > one to one correspondence between the AS and the Routing Context.
> > The AS is the basis on which all data traffic is managed.
> > 
> > If the ASP is going to forward messages based on anything other than
> > the AS for which it is configured/registered, there is no need to
> > have multiple AS per ASP supported at all and the Routing Context
> > can always be implied by the ASP Id (the instance of the SCTP
> > association).
> > 
> > In the current scheme, where an ASP can register for multiple AS,
> > it is convenient to organize the AS and RK such that each AS
> > corresponds to a demultiplexed stream.  It is then very efficient
> > to demultiplex by Routing Context which is what I (and it seems
> > others) would like to do.
> > 
> > For example, I have 4 processes running at my ASP.  These might
> > even be subtending processors.  I distribute ISUP CIC ranges over
> > the processes for load balancing.  I assign a Routing Key to each
> > of the 4 traffic flows by, say, OPC-DPC-CIC-range and either 
> > statically
> > configure or register them that way.  If the SGP places the RC in the
> > message when it sends the traffic, it will be saying "here's that
> > data AS-n asked for" and the ASP will not have to examine the contents
> > whatsoever to send it to the subtending process.  The examination of
> > the contents was done once in the SGP.
> > 
> > Should I go on?
> > 
> > --Brian
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]