Subject: [Dime] Re: DiME Digest, Vol 9, Issue 31

From: "Rashmi Rath" <[email-masked]>
Date: Tue, 19 Sep 2006 08:50:02 -0400

Hi Chandu,

Your understanding is absolutely right. A diameter peer can accept message
from more one peer. ie multiple instance  of  diameter is possible in a
single host.

Thanks & Regds

Rashmi Rath
Software Engineer

IntelliNet Technologies

On 9/19/06, [email-masked] <[email-masked]> wrote:
>
> Send DiME mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www1.ietf.org/mailman/listinfo/dime
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DiME digest..."
>
>
> Today's Topics:
>
>    1. receving connections from 3868 with multiple instances.
>       (Valesh  Chandu)
>    2. DiME Digest, Vol 9, Issue 30 (Rashmi Rath)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 19 Sep 2006 09:13:57 -0000
> From: "Valesh  Chandu" <[email-masked]>
> Subject: [Dime] receving connections from 3868 with multiple
>         instances.
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> I have a doubt regarding receiving connection requests/listening on port
> 3868 in case of multiple instances on a single host with one interface.
>
> Snippet from sec 2.1 of RFC 3588:
> A Diameter node MAY initiate connections from a source port other   than
> the one that it declares it accepts incoming connections on, and MUST be
> prepared to receive connections on port 3868.A given Diameter instance of
> the peer state machine MUST NOT use more than one transport connection to
> communicate with a given peer, unless multiple instances exist on the peer
> in which case a separate connection per process is allowed.
> Diameter Node is defined as :
> A Diameter node is a host process that implements the Diameter
> protocol, and acts either as a Client, Agent or Server.
>
> My understanding of the above section is that multiple instances of the
> diameter stack is possible on the same host machine.
>
> So, if we have multiple instances on a single host then how it is possible
> to listen on the same port 3868 from all the instances?
>
>
> Please any one clarify my doubt?
>
> Best Regards,
> Chandu
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/dime/attachments/20060919/2fa54a99/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 Sep 2006 16:17:07 +0530
> From: "Rashmi Rath" <[email-masked]>
> Subject: [Dime] DiME Digest, Vol 9, Issue 30
> To: [email-masked]
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi All,
>
> I have a question.
> In Disconnect Peer Request, If i put disconnect cause other than BUSY,
> REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer
> connection.
>
>
>
> Thanks & Regds
>
> Rashmi Rath
> Software Engineer
> IntelliNet Technologies
>
>
> On 9/18/06, [email-masked] <[email-masked]> wrote:
> >
> > Send DiME mailing list submissions to
> >        [email-masked]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        https://www1.ietf.org/mailman/listinfo/dime
> > or, via email, send a message with subject or body 'help' to
> >        [email-masked]
> >
> > You can reach the person managing the list at
> >        [email-masked]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of DiME digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: Error Code issues for bis (Victor Fajardo)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 18 Sep 2006 11:34:18 -0400
> > From: Victor Fajardo <[email-masked]>
> > Subject: Re: [Dime] Error Code issues for bis
> > To: Yoshihiro Ohba <[email-masked]>
> > Cc: [email-masked]
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset=ISO-2022-JP
> >
> > I've updated issue 14 to reflect the current opinion of which I also
> > agree. Pls review the text if it is appropriate or if other folks has
> > other opinions.
> >
> > regards,
> > victor
> >
> >
> > > I support Tolga's proposal on using E-bit and grammar described in 7.2
> > > for permanent errors in addition to protocol errors.
> > >
> > > Yoshihiro Ohba
> > >
> > > On Mon, Sep 18, 2006 at 05:33:31AM +0300, [email-masked]:
> > >
> > >> Tolga,
> > >>
> > >> I think that seems reasonable - does anyone else have comments
> > >> on this - supporting or otherwise?  It would be good to wrap
> > >> this issue up.
> > >>
> > >> John
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: ext Tolga Asveren [mailto:[email-masked]]
> > >>> Sent: 15 September, 2006 15:50
> > >>> To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
> > >>> Subject: RE: [Dime] Error Code issues for bis
> > >>>
> > >>> John,
> > >>>
> > >>> My only goal is being able to use the grammar described in 7.2
> > >>> for permanent answers as well. For certain situations it is
> > >>> impossible to continue decoding a message, e.g. invalid AVP
> > >>> length for an AVP which is of type OctetString. In such a
> > >>> case, it may not be possible to generate an answer message
> > >>> based on the command's answer grammar, nor does it seem
> > >>> necessary to me.
> > >>>
> > >>> What I suggest is allowing E-bit to be set for permanent
> > >>> failures as well, so that grammar in 7.2 can be used.
> > >>>
> > >>> It is not important that all implementations follow that path,
> > >>> only the ones which consider it necessary/usefull for certain
> > >>> cases can use it.
> > >>>
> > >>> On receiver end, this shouldn't be a problem because if the
> > >>> E-bit is set, receiver will decode the message based on 7.2
> > >>> grammar, otherwise command answer grammar will be used. this
> > >>> rule is already there in RFC3588.
> > >>>
> > >>> After thinking a bit more, the only possible backward
> > >>> compatibility issue I see is, if some implementation checks
> > >>> whether E-bit is set for an answer with Result-Code other than
> > >>> Protocol Error. Considering that for some Permanent Failures
> > >>> 7.2 grammar is really necessary, I believe that shouldn't be a
> > >>> big issue.
> > >>>
> > >>>     Thanks,
> > >>>     Tolga
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: [email-masked] [mailto:[email-masked]]
> > >>>> Sent: Thursday, September 14, 2006 11:34 PM
> > >>>> To: [email-masked]; [email-masked]
> > >>>> Subject: RE: [Dime] Error Code issues for bis
> > >>>>
> > >>>>
> > >>>> Tolga,
> > >>>>
> > >>>> If it is optional, that means you can't count that any
> > >>>>
> > >>> implementations
> > >>>
> > >>>> will support it.
> > >>>>
> > >>>> However, are you suggesting the E-bit could be used as a hint for
> > >>>> permantant failures?
> > >>>>
> > >>>> John
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: ext Tolga Asveren [mailto:[email-masked]]
> > >>>>> Sent: 14 September, 2006 21:14
> > >>>>> To: [email-masked]
> > >>>>> Subject: RE: [Dime] Error Code issues for bis
> > >>>>>
> > >>>>> Hi Victor,
> > >>>>>
> > >>>>> I had a look to Issue14. I already thought that use of E-bit is
> > >>>>> exclusively for protocol errors based on "Note that these and only
> > >>>>> these erors MUST only be used in answer messages whose 'E' bit is
> > >>>>> set." in 7.1.3. The proposed text further supports this idea.
> > >>>>>
> > >>>>> I see a value of using E-bit for permanent failures as I tried to
> > >>>>> explain before. I think your concern is that people may
> > >>>>>
> > >>> choose not to
> > >>>
> > >>>>> use error answer-message grammar defined in 7.2 for certain
> > >>>>>
> > >>> permanent
> > >>>
> > >>>>> failures. To address both concerns, I suggest we allow use of
> E-bit
> > >>>>> for permanent failures but leave it as an implementation choice to
> > >>>>> use it or not. This again would be backward compatible AFAICS.
> > >>>>>
> > >>>>>    Thanks,
> > >>>>>    Tolga
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Victor Fajardo [mailto:[email-masked]]
> > >>>>>> Sent: Thursday, September 14, 2006 10:17 AM
> > >>>>>> To: Tolga Asveren
> > >>>>>> Cc: [email-masked]
> > >>>>>> Subject: Re: [Dime] Error Code issues for bis
> > >>>>>>
> > >>>>>>
> > >>>>>> Hi Tolga,
> > >>>>>>
> > >>>>>> Comments inline:
> > >>>>>>
> > >>>>>>>> This maybe an easy way of performing error handling with just
> > >>>>>>>> sending the error grammar but it maybe to harsh (??). A node
> > >>>>>>>> receiving a result code set to some non-protocol failure
> > >>>>>>>>
> > >>>>> value may
> > >>>>>
> > >>>>>>>> find it more useful to receive the application specific answer
> > >>>>>>>> message rather than just the error message in 7.2 since the
> > >>>>>>>> error may not be grave and the both end-point application can
> > >>>>>>>>
> > >>>>> attempt to recover and continue on.
> > >>>>>
> > >>>>>> An example
> > >>>>>>
> > >>>>>>>> would be when the result code is set to MISSING_AVP or
> > >>>>>>>>
> > >>>>>> INVALID_AVP_VALUE
> > >>>>>>
> > >>>>>>>> and the answer message carries a Failed-AVP. Depending on the
> > >>>>>>>> application, the sender of the error may choose to continue
> > >>>>>>>> processing the remainder of the request if the offending
> > >>>>>>>>
> > >>>>> AVP is not
> > >>>>>
> > >>>>>>>> crucial. The receiver of the error would view the error as a
> > >>>>>>>> hint maybe able to compensate/recover and continue on also.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>> [TOLGA]This is an interesting point but if such an answer is
> > >>>>>>>
> > >>>>>> generated, how
> > >>>>>>
> > >>>>>>> could the peer know the real result of the request
> > >>>>>>>
> > >>>>> processing? Let's
> > >>>>>
> > >>>>>>> say Result-Code contains MISSING_AVP, how could the request
> > >>>>>>>
> > >>>>>> originator determine
> > >>>>>>
> > >>>>>>> whether the request processing is done successfully?
> > >>>>>>>
> > >>>>>> I was thinking through other avp's in the application
> > >>>>>>
> > >>>>> specific answer
> > >>>>>
> > >>>>>> grammar ... though that maybe stretching the success/failure
> > >>>>>> significance of the result-code avp against other avps in
> > >>>>>>
> > >>>>> the message
> > >>>>>
> > >>>>>> so may not as advisable.
> > >>>>>>
> > >>>>>>
> > >>>>>>>> I guess this would depend if the implementation is doing full
> > >>>>>>>>
> > >>>>>> or partial
> > >>>>>>
> > >>>>>>>> parsing in the base protocol layer.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>> [TOLGA]I think I was not clear about this one. The message
> > >>>>>>>
> > >>>>> is parsed
> > >>>>>
> > >>>>>>> (or parsed as much as possible depending the type of the error).
> > >>>>>>>
> > >>>>>> Now an answer
> > >>>>>>
> > >>>>>>> message needs to be generated. If the grammar of the
> > >>>>>>>
> > >>>>> answer for that
> > >>>>>
> > >>>>>>> specific command code is used, all mandatory AVPs which are
> > >>>>>>>
> > >>>>>> specified in the
> > >>>>>>
> > >>>>>>> grammar need to be present. Those AVPs possibly could be filled
> > >>>>>>> without application logic involvement, but I would think this
> > >>>>>>> would
> > >>>>>>>
> > >>>>>> require to put
> > >>>>>>
> > >>>>>>> some dummy values there. In such a case, what is the point of
> > >>>>>>> inserting them?
> > >>>>>>>
> > >>>>>>>
> > >>>>>> I was thinking in the case where the base protocol part of the
> > >>>>>> implementation does only partial parsing of message header
> > >>>>>>
> > >>>>> and avps it
> > >>>>>
> > >>>>>> requires and leaves full parsing of the remaining
> > >>>>>>
> > >>>>> application specific
> > >>>>>
> > >>>>>> avps to the applications themselves. The scenario you mentioned
> > >>>>>> fits well when the failure occurs during the partial parsing.
> > >>>>>> During full parsing, application logic can be introduced.
> > >>>>>>
> > >>>>>> best regards,
> > >>>>>> victor
> > >>>>>>
> > >>>>> _______________________________________________
> > >>>>> DiME mailing list
> > >>>>> [email-masked]
> > >>>>> https://www1.ietf.org/mailman/listinfo/dime
> > >>>>>
> > >>>>>
> > >>>
> > >> _______________________________________________
> > >> DiME mailing list
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/dime
> > >>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > > ______________________________________________________________________
> > > This email has been scanned by the MessageLabs Email Security System.
> > > For more information please visit http://www.messagelabs.com/email
> > > ______________________________________________________________________
> > >
> > >
> > >
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> > End of DiME Digest, Vol 9, Issue 29
> > ***********************************
> >
>
>
>
> --
> Regards
>
> Rashmi Ranjan Rath
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/dime/attachments/20060919/defcaa8b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
> End of DiME Digest, Vol 9, Issue 31
> ***********************************
>

-- 
Regards

Rashmi Ranjan Rath
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime