Re: [Dime] Application-id reuse

["Jacob Martin" <jacobmartin80 at gmail.com>]

Hi Hannes,
On 9/12/08, Hannes Tschofenig <Hannes.Tschofenig at gmx.net> wrote:
> 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?
I have explained it in my previous post. Please have a look.
>
>
>>>    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.
This problem has been captured in 3GPP TR 29.909. In section 5.5, it
has few proposals to avoid such problem.

Cheers,
Jacob
>
> 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