Re: [Dime] Application-id reuse

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

Hi Jacob,

Jacob Martin wrote:
> Jouni,
> On 9/12/08, jouni.korhonen at teliasonera.com
> <jouni.korhonen at teliasonera.com> wrote:
>   
>> Hi Jacob,
>>
>>     
>>> Hi Hannes,
>>>
>>>    My problem relates to the second question which you have raised i.e
>>> "How does Diameter routing work with a Diameter application like Wm?"
>>>
>>>    From the implementor's point of view, it is difficult to keep one
>>> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ
>>> requests(Please look at the diagram in my initial post).
>>>       
>> Dictionaries..
>>     
> How? If my base Diameter process has received a DER request from peer
> for WLAN application, then how could it be routed to Wm application.
> Please refer the diagram in my initial post.
>   

I believe the terminology would be rather "... how could it be handed 
over to the Wm application within ."

This is largely an implementation specific issue. You need to enhance 
your existing application logical to handle the additional AVPs that are 
defined on top of EAP/NASREQ.

Does this help?

>   
>>>    This problem could be avoided if we have a seperate app-id for Wm.
>>>
>>> As per section 1.2.3 of RFC 3588,
>>> =====
>>>   "
>>>     .........it may be desirable to create a new Diameter
>>>    application.  Major changes to an application include:
>>>
>>>    -  Adding new AVPs to the command, which have the "M" bit set.
>>>  "
>>> =====
>>>
>>> In Wm, protocol designers have added AVPs which have M bit 'on' ex:
>>> 3GPP-WLAN-APN-Id, Routing-Policy etc.
>>>       
>> These are known deficiencies in TS29.234 and will stay there until
>> someone makes a CR to fix them. Anyway, the Information Element with
>> a category 'M' means that the said AVP must be present in the Diameter
>> message.. thus defining the exact "profile". It does not say anything
>> about the M-bit setting. See section 10.2 of TS 29.234. You can send
>> 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end
>> understands the AVP. (you are now entering into a gray area in 3GPP,
>> which has recently been tried to fix with clear guidelines..)
>>     
>
> I think table 10.1.1 in TS29.234 has the AVP flag details for all the AVPs.
>
>   
Someone should fix this.

>> Cheers,
>> 	Jouni
>>     

Ciao
Hannes

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime