Re: M3UA, Routing Context parameter in SSNM

Hi, brian

Thanks for your reply.
I have other question about this problem.

We use the RKM function between ASP and SGP.
And, We send a Routing Key to SGP and We receive a Routing Context  
value from SGP.
So, I think the Routing Context in SSNM message is required
because Routing Key has been coordinated between SGP and ASP.
is it right?

RFP 3332,
"Where a Routing Key has not been coordinated between the SGP and ASP,
sending of Routing Context is not required. "

Regards!
-- Kim


* NOTICE:
    Change the Text Encoding to UTF-8 if you can't read the text in  
this mail.


Moo-hyoung Kim
Core Technology / Network BIZ. Division
UANGEL Corporation
Tel   : +82-31-710-6240
Mobile: +82-11-9052-1122
E-mail: [email protected]



2006. 07. 03, 오후 12:15, Brian F. G. Bidulock 작성:

> ±è,
>
> ±è ¹«Çü wrote:                                (Mon, 03 Jul  
> 2006 11:17:46)
>> but, there is single Routing Key and Routing Context between ASP and
>> SGP.
>>
>> In RFC 3332,
>>        Routing Context is not required.  Where multiple Routing  
>> Keys and
>>        Routing Contexts are used across a common association, the   
>> Routing
>>        Context(s) MUST be sent to identify the concerned traffic  
>> flows
>>        for which the DUNA message applies, assisting in outgoing  
>> traffic
>>        management and internal distribution of MTP-PAUSE  
>> indications to
>>        MTP3-Users at the receiver.
>>
>> if there is single Routing Key and Routing Context between the SGP
>> and ASP as our configuration,
>> is the Routing Context parameter in SSNM message optional? or  
>> mandatory?
>
> Optional: because there are not "multiple Routing Keys and Routing  
> Contexts
> used accross a common association" and, therefore, the MUST does  
> not apply.
>
> As there is only one routing context for the entire association, the
> implementation should not have a problem discerning that.  OTOH, an
> implementation could choose to send one anyway (if one was even  
> assigned).
>
> --brian
>
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>