Subject: RE: Proposal for message formatting (sec. 9).

From: <[email-masked]>
Date: Wed, 16 Apr 2003 13:35:06 +0300

Alper,

Diameter compatibility is not a requirement, but a possibility :). I don't see it causing udesirable side effects. App-Id is not causing problems, but making the header a bit bigger. It can help PANA to become more popular/useful and to cope with possible future extensions/capabilities (list of app-ids supported). Do you see any drawbacks in this, or issues why we should not be compatible with Diameter? 

We should ask other's opinions too.

- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 16 April, 2003 03:15
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: Proposal for message formatting (sec. 9).
> 
> 
> Hi Dan,
> 
> It seems like you are treating Diameter compatibility as if it is a
> requirement. It might be a desirable feature at best. Sure it 
> helps with
> some code reuse or implimentation shortcuts, but these are 
> not necessary
> for the protocol design, and should not cause undesirable 
> side effects.
> PANA is not really meant to be an appendix to Diameter. 
> Diameter is one of
> the possible backend AAA protocols only.
> 
> For example, addition of the "application id" field is not 
> justifiable for
> PANA imo. I didn't quite understand the future application 
> support. For
> future extensions a reserved field might be more than 
> sufficient. Actually
> AVPs might be good enough too.
> 
> 64-bit alignment is a nice feature too. I'm not sure which 
> one is better
> though: Diameter harmonization or this.
> 
> Alper
> 
> 
> > Alper,
> > 
> > Thank you for your comments.
> > 
> >> -----Original Message-----
> >> From: ext Alper Yegin [mailto:[email-masked]]
> >> Sent: 14 April, 2003 23:54
> >> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> >> Subject: Re: Proposal for message formatting (sec. 9).
> >> 
> >> 
> >> 
> >> Hi Dan,
> >> 
> >> Thank you for putting together the Message Format section.
> >> 
> >> Here are some comments on the current design:
> >> 
> >> - I see the message formats includes some protocol features
> >> we have not
> >> fully discussed yet. For example: session-id, add-device-id,
> >> remove-device-id. I recommend we separately discuss them
> >> first, and than
> >> incorporate into the message formats if necessary.
> > 
> > Sure.
> > 
> >> - I understand the desire to re-use DIAMETER code, but let's
> >> not overdo it.
> >> From "PANA design perspective", I don't see why we should
> >> have "Application
> >> ID" field in the header.
> > 
> > To make the header structure similar to Diameter. If we 
> break it, then it
> > doesn't matter what kind of format we use, because 
> implementations must be
> > different then. 
> > 
> > We have a prototype that uses Diameter message formatting 
> (testing SeNAA) on
> > top of UDP. This is a very nice feature, because the 
> Diameter stack callbacks
> > can be used with PANA messages too. The interaction with 
> the AAA backend
> > becomes very smooth. This means of course that Diameter and 
> PANA id values
> > don't overlap.
> > 
> > With Diameter PANA could have Application-Id 4 and the new 
> AVPs could be
> > registered from the Diameter number space (or then we could 
> use Vendor-Id for
> > PANA). I talked with John Loughney (one of the authors of 
> Diameter base spec)
> > about this and he didn't see any problems with this approach.
> > 
> > PANA could support different applications in the future 
> too. A preshared SA
> > between PaC and PAA and extensible message types sounds 
> compelling. And if the
> > protocol works smoothly with AAA backends (one doesn't have 
> to specify
> > different AVPs with Diameter and PANA) the scenario looks  
> interesting.
> > 
> >> - Device ID can also include various link-layer address
> >> types. Let's reflect
> >> that onto the design (currently only IP addresses are included).
> > 
> > Sure.
> > 
> >>  - How about alignment requirements? I'd say we should 
> require 8-octet
> >> alignment for AVPs.
> > 
> > If that doesn't break the Diameter compatibility.
> > 
> >> 
> >> Alper
> >> 
> >>> Hi,
> >>> 
> >>> Attached you can find a proposal section (9 Message Formats)
> >>> for the draft-ietf-pana-pana-00.txt. It contains some changes
> >>> that affect the whole draft.
> >>> 
> >>> There are no error messages defined, which I think should be
> >>> fixed. This is not only a message format issue, but a protocol
> >>> issue.
> >>> 
> >>> Changes to the pana draft in general:
> >>> 
> >>> - Message naming convention changed (*_ack --> *-Answer,
> >>> * --> *-Request) to better reflect the Diameter style
> >>> and the nature of the protocol: answers contain data,
> >>> but for acks it is not so clear. Requests and answers
> >>> describe better the protocol.
> >>> 
> >>> - Thus, 2 messages instead of 1:
> >>>  - PANA-Auth-Request & PANA-Auth-Answer.
> >>>    PAA always sends PANA-Auth-Request and requires an
> >>>    answer to it.
> >>>  - PANA-Start-Request & PANA-Start-Answer.
> >>>    PANA-Start messages are different depending on the sender.
> >>>  - PANA-Success-Request/Answer: PANA requires answer to success,
> >>>    because he PANA SA is not otherwise established properly.
> >>>    And for sake of simplicity, the same naming convention
> >>>    should be used.
> >>> 
> >>> - Flag change: A flag to R flag to better reflect Diameter style.
> >>> Requests have the R flag set, answers unset.
> >>> 
> >>> - Name change: Data-Protection --> Protection-Capability.
> >>> Data-Protection is misleading term.
> >>> 
> >>> - Name change: Revocation-Status --> Termination-Cause (Diameter).
> >>> There is already an AVP that suits for this purpose.
> >>> 
> >>> - PANA-Disconnect-Request now contains Termination-Cause AVP.
> >>> There are different reasons for the user to disconnect.
> >>> 
> >>> 
> >>> 
> >>> Comments welcome,
> >>> - Dan
> >>> 
> >> 
> >> 
> > 
> > 
> 
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Apr 2003 16:43:20 -0700

Dan,

Not having that Diameter-specific field in the PANA header does not mean
that PANA will be incompatible with Diameter. I'm afraid the level of
compatibility you are aiming is "source code compatibility".

I'm not concerned about the header size, but I'm concerned about
incorporating headers into PANA that currently does not mean anything to
PANA. Is there an explanation of what "application ID" means to PANA?
Do we have this field in other applications of Diameter, such as in the
Mobile IPv4 header, or PPP or 802.1x headers?

Alper

> Alper,
> 
> Diameter compatibility is not a requirement, but a possibility :). I don't see
> it causing udesirable side effects. App-Id is not causing problems, but making
> the header a bit bigger. It can help PANA to become more popular/useful and to
> cope with possible future extensions/capabilities (list of app-ids supported).
> Do you see any drawbacks in this, or issues why we should not be compatible
> with Diameter? 
>