Re: Query regarding routing context (RC) value in dynamic registration

Chris Benson <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Hi folks,

The "unique" statement cited from RFC 4666 ONLY states that
the RC value is guaranteed to be different for each different 
AS/Routing Key.

Previous comments (including mine) were referring to different
SGPs (in the same SG). Each SGP can use different RC values for 
the same AS/Routing Key.

I would expect that one SGP would use the same RC value for
the same AS/Routing Key, but I don't think the RFC guarantees 
this, only that a different AS/RK gets a different RC value.

This shouldn't present a problem. The RC value returned
by an SGP should be considered applicable to the SGP/ASP 
pair through which it was received. Other SGP/ASP pairs
might need to store other RC values for the same AS/RK.

Strictly speaking, its scope would be an SGP/ASP/AS 
triple, when considering one ASP registering multiple ASs.

With thanks, from Chris Benson.

On Tue, 13 Apr 2010, [email protected] wrote:

>>  Date: Tue, 13 Apr 2010 12:53:47 -0700
>>  From:  <[email protected]>
>>  To:  <[email protected]>,  <[email protected]>
>>  Cc:  <[email protected]>,  <[email protected]>,
>>      <[email protected]>
>>  Subject: Re: [Sigtran] Query regarding routing context (RC) value in dynamic
>>       registration
>>  
>>  Hi Bryan,
>>  
>>  In order not to misinterpret your answer - this is the situation:
>>  Two ASPs are supporting the same AS. Registration is set to Dynamic. My understanding of spec is that Routing Context assigned to both ASPs should be the same, since they both register for the same Routing Key.
>>  
>>  >From sec 4.4.1
>>  
>>  The method of Routing Context value assignment at the SGP is implementation dependent but must be guaranteed to be unique for each Application Server or Routing Key supported by the SGP.
>>  
>>  The question below should have sound more like: can SGP assign different Routing Contexts to multiple ASPs in the same AS (when they all have the same Routing Key)?
>>  If you answer yes, then I will need more clarification on how the Traffic Loadsharing is going to be handled and how ASP Override mode is going to be handled?  Is SG going to use Routing Key for all those actions?  And what is the meaning of Routing Context in that case?
>>  
>>  
>>  Thanks a lot for your time,
>>  Arusyak.
>>  
>>  From: Sandeep Banglore Somashekar [mailto:[email protected]]
>>  Sent: Thursday, April 08, 2010 12:42 AM
>>  To: Sandeep Banglore Somashekar
>>  Subject: FW: [Sigtran] Query regarding routing context (RC) value in dynamic registration
>>  
>>  
>>  ---------- Forwarded message ----------
>>  From: Brian F. G. Bidulock <[email protected]<mailto:[email protected]>>
>>  Date: Wed, Apr 7, 2010 at 4:29 PM
>>  Subject: Re: [Sigtran] Query regarding routing context (RC) value in dynamic registration
>>  To: Sandy <[email protected]<mailto:[email protected]>>
>>  Cc: [email protected]<mailto:[email protected]>
>>  
>>  
>>  Sandy,
>>  
>>  It would be better to use the RC it receives.
>>  
>>  --brian
>>  
>>  Sandy wrote:                                                         (Wed, 07 Apr 2010 14:30:04)
>>  >
>>  >    Hi All,
>>  >    Consider a scenario where 2 ASPs register at SG for same routing key
>>  >    dynamically.
>>  >    Let ASP-1 has received RC1 in the registration response for the
>>  >    routing key dynamically registered at SG. Now if ASP2 registers for
>>  >    same Routing Key at SG, Should ASP-2 restrict itself to receive same
>>  >    RC1 in registration response?
>>  >    Thanks in advance.
>>  >    Regards,
>>  >    Sandeep B S
>>  > _______________________________________________
>>  > Sigtran mailing list
>>  > [email protected]<mailto:[email protected]>
>>  > https://www.ietf.org/mailman/listinfo/sigtran
>>  
>>  
>>  --
>>  Brian F. G. Bidulock
>>  [email protected]<mailto:[email protected]>
>>  http://www.openss7.org/
>>  
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.