Re: [Dime] Application-id reuse

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

Hi Jacob,

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..
>
>   
There are many ways todo so from an implementation point of view. 
Typically, you are going to have some business logic at the AAA server. 
Could you be more specific about the problems you see?


>>    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 would like to reinforce what Jouni said. If the application designer 
does not want to create new application then all the functionality they 
define has to be optional. If there is mandatory and required 
functionality in the extension then a Diameter application should have 
been defined. This wasn't done in the 3GPP and I hope that someone is 
going to fix it.

Ciao
Hannes

> Cheers,
> 	Jouni
>
>   
>> Cheers,
>> Jacob
>>
>> On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo)
>> <hannes.tschofenig at nsn.com> wrote:
>>     
>>> Hi Jacob,
>>>
>>> Your question addresses different aspects, namely
>>>
>>> * How does Diameter routing work in general?
>>>
>>> This is described in Section 6.1 and Section 6.2 of
>>>
>>>       
>> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt
>>     
>>> This should give you an idea how the right node is found 
>>>       
>> and how messages
>>     
>>> travel back and forth.
>>>
>>> * How does Diameter routing work with a Diameter 
>>>       
>> application like Wm?
>>     
>>> This very much depends on how the protocol designers of Wm 
>>>       
>> want it to work.
>>     
>>> I have to read Wm again to recall the details but based on 
>>>       
>> what you describe
>>     
>>> it seems that the protocol designers of Wm did not want to 
>>>       
>> create a new
>>     
>>> Diameter application and hence the additionally specified 
>>>       
>> AVPs are just
>>     
>>> optional extensions to Diameter EAP and Diameter NASREQ. As 
>>>       
>> such, they
>>     
>>> should be routed to the respective EAP/NASREQ code and the 
>>>       
>> optional AVPs are
>>     
>>> interpreted in case that they are understood.
>>>
>>> Ciao
>>> Hannes
>>>
>>>       
>>>> -----Original Message-----
>>>> From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On
>>>> Behalf Of ext Sebastien Decugis
>>>> Sent: 09 September, 2008 14:02
>>>> To: Jacob Martin
>>>> Cc: dime at ietf.org
>>>> Subject: Re: [Dime] Application-id reuse
>>>>
>>>> Hello,
>>>>
>>>> I think the Application Id in the command header will contain
>>>> the appropriate identifier to route the message to the correct
>>>> handler...
>>>>
>>>> Best regards,
>>>> Sebastien.
>>>>
>>>> Jacob Martin a écrit :
>>>>         
>>>>> Hi,
>>>>>
>>>>>     I am a bit confused about the feasibility of one specific
>>>>> configuration in Diameter.
>>>>>
>>>>>     Please look at the diagram below:
>>>>>
>>>>>
>>>>>                                 |
>>>>>                                 |
>>>>>                                 |
>>>>>                                 |
>>>>>    Local Node                   |
>>>>>                                 |        +----+       +-------+
>>>>>                                 |        |NAS |       |  Wm   |
>>>>>     +--------+   +--------+     |        +----+       +-------+
>>>>>     |        |   |        |     |            |            ---
>>>>>     |NASREQ  |   |  Wm    |     |             |        ---
>>>>>     +----\---+   +---/----+     |             +----- --
>>>>>           \        //           |         ////      \\\\\
>>>>>           \      //             |       |/               |
>>>>>            \   //               |      |        PEER     |
>>>>>         +---\-/------+          |      |                  |
>>>>>         |            |          |       |\               |
>>>>>         |Diameter    |          |         \\\\      /////
>>>>>         |Base process|          |             ------
>>>>>         +----+-------+          |             |
>>>>>              |                  |             |
>>>>>              |                  |             |
>>>>>              +------------------+-------------+
>>>>>
>>>>>    I wish to provide support for two applications on my
>>>>>           
>>>> local node i.e
>>>>         
>>>>> NASREQ and Wm. As per Wm specifications, Wm should reuse the
>>>>> application identifier of EAP/NASREQ. So, in CEA, I have 
>>>>>           
>> advertised
>>     
>>>>> '1' and '5' as the applications supported.
>>>>>
>>>>>    Assume that peer node also has the same configuration 
>>>>>           
>> as of mine
>>     
>>>>> i.e it also support Wm and NAS applications.
>>>>>
>>>>>   Now, peer Wm application issues an AAR. After receiving 
>>>>>           
>> this AAR,
>>     
>>>>> how could my Diameter base process determine that this AAR is for
>>>>> local Wm application, but not for local NASREQ application?
>>>>>
>>>>>
>>>>>   Thanks in anticipation,
>>>>>   Martin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> ------------------------------------------------------------
>>>>         
>> ----------
>>     
>>>>> --
>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>
>>>>>           
>>>> --
>>>> Sebastien Decugis
>>>> Research fellow
>>>> Network Architecture Group
>>>> NICT (nict.go.jp)
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>>>         
>> _______________________________________________
>> DiME mailing list
>> DiME at ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>>     
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>   

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