Re: [Dime] Application-id reuse

[<jouni.korhonen at teliasonera.com>]

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..

>    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..)

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