From dime-bounces@ietf.org Tue Jul 03 02:50:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5cD7-0000I4-9w; Tue, 03 Jul 2007 02:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5cD5-0000Hn-JU for dime@ietf.org; Tue, 03 Jul 2007 02:50:03 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5cCB-0006m3-6i for dime@ietf.org; Tue, 03 Jul 2007 02:50:03 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL002MIBROLG@szxga02-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 14:38:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL00E80BRM8H@szxga02-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 14:38:12 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKL00KIWBRMQ3@szxml04-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 14:38:10 +0800 (CST) Date: Tue, 03 Jul 2007 14:38:10 +0800 From: Tina TSOU Subject: Re: [Dime] Re: FW: First draft on the integration of QoS application To: dime@ietf.org, "Asveren, Tolga" , McCann Peter-A001034 , "Sun, Dong (Dong)" Message-id: <00b801c7bd3c$b92a6800$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com> <9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> <09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7187FBE@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520946@ILEXC2U01.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dong, Probably NE is needed to report a Transport ID to the authorizing entity to differentiate which kind of procedure it is going to use. B. R. Tina ----- Original Message ----- From: "Sun, Dong (Dong)" To: "McCann Peter-A001034" ; "Asveren, Tolga" ; Sent: Thursday, June 21, 2007 6:57 AM Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Hi Pete, Tolga, I agree that this QoS application does not need to cover the interface between Application Server and Policy Server, which is the Rx in the 3GPP term. Although the protocol wise the same command codes can be used for both inter/intra-domain cases, I think there are some differences from the (policy control) functional perspective, such as security requirement; and the information exchanged through the interface - in the inter-domain case the information would be more abstract and generic e.g. independent of network technology; and the routing mechanism - in the inter-domain case an anchor point would be used instead of disclosing the internal topology. As I said, I am open to cover both inter-domain and intra-domain scenarios in the same application, but it makes sense to elaborate on the difference in the functional modeling. Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: Wednesday, June 20, 2007 12:26 PM To: Asveren, Tolga; dime@ietf.org Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Hi, Tolga, Dong, The existing text assumes that the Authorizing Entity is either a static subscriber database or is itself an Application Server. The term "Authorizing Entity" was introduced to abstract away from either of these two implementations. I would rather not introduce an additional interface, especially if it goes unspecified for now. I would rather have just one protocol that can serve as an inter-domain or intra-domain interface depending on the business model, as Tolga says. In 3GPP terms, this would be one application that can serve as either Gx or Rx. The "Diameter Cloud" shown in Figure 1 implies the location of the inter-domain interface. We could write into the draft some considerations for how proxies can handle Diameter QoS messages, in case they want to impose their own policies. As the base protocol allows, intermediate proxies can add AVPs to a command to indicate such local policies. -Pete Asveren, Tolga wrote: > Hi Dong, > > I personally don't see any conceptual difference between interdomain > and intradomain requests regarding Diameter QoS. Both interfaces are > used to communicate the desire to reserve QoS with characteristics as > described by the AVPs in the corresponding messages. The rest is > probably dependent on policy, e.g. how interdomain requests are > handled v.s. > intradomain requests. > > IMHO, authorization can be treated as an integral part of QoS > reservation. It could be optionally omitted depending on the business > model. Probably, from QoS application point of view, the impact would > be to have an AVP identifying the user/subscriber in the message. > IMHO, the rest (whether and how the value in this AVP is used by the > server/proxy etc..., e.g. consulting an external database) is > implementation dependent. > > Thanks, > Tolga > > > >> -----Original Message----- >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] >> Sent: Tuesday, June 19, 2007 6:27 PM >> To: McCann Peter-A001034; Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS >> application >> >> Pete, et al, >> >> Although I have no objection to define the inter-domain interface, it >> seems to me the Rx in 3GPP does not fit well with the modeling >> defined in QoS application: - Rx is defined between Application >> Function and Policy Decision function (i.e. part of Authorizing >> entity in QoS application) - QoS application concerns the control of >> policy enforcement, the interface between authorizing entity and >> Network element, which is the Gx in 3GPP term. >> >> If we really like to cover both inter-domain and intra-domain >> scenarios in the single QoS application, I think it should be a >> Gx-like interface. In the inter-domain case, the Gx-like interface >> will be used between home PCRF and visited PCRF as well; besides it >> can be used between PCRF and PCEF for intra-domain case. >> >> In addition, I think we should allow the flexibility to have >> Application Server separated from the Authorizing entity (but not >> mandatory), and maybe no need to standardize that interface between >> AS and Authorizing entity in this QoS application. >> >> If you agree on this proposal, I'd like to edit the latest draft I >> sent out to reflect this notion. >> >> Dong >> >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, June 19, 2007 12:14 PM >> To: Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS >> application >> >> Hi, Christian, >> >> Thanks for your comments, I would certainly like to take a look at >> your paper. >> >> I suppose I could be convinced that local policy should be taken care >> of with a separate interface, but I think it's important that IETF >> standardize the inter-domain case as a first priority. >> The local interface is less important to standardize now, because it >> could easily be taken care of with a proprietary interface based on >> purchasing decisions made by the operator, or it could easily be >> incorporated in to the Network Element itself. One of my goals for >> the diameter-qos draft has been to facilitate the inter-working of >> disparate application functions in different networks, and I think >> that should be the focus of this draft. >> >> If we really want to add a new local PDP element to the draft I would >> be ok with a modified Figure 1 that shows this. However, the >> Diameter cloud would then need to be shown between that entity and >> the application server, and the document should focus on this latter >> interface. In other words, we should be standardizing Rx now. >> >> -Pete >> >> Christian Esteve wrote: >>> Hi folks, >>> >>> the discussion thread reflects once again the confrontation between >>> the operator SDO and the IETF worlds, and as it usually happens, >>> disagreements are not only motivated by network engineering issues >>> but by scope and nomenclature divergences. >>> >>>>> I guess I don't see why we need two separate interfaces. They are >>>>> each transporting roughly the same information and doing the same >>>>> sort of job. >>> >>> It is true that the job and type of infomation are similar, however >>> the separation of the interfaces makes sense to me. While one >>> interface is used only to request QoS, the other is expected to >>> carry and install QoS policy information (with different QoS >>> descriptors). >>> >>> The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the >>> architecture evolution of the SDOs that introduce policy-based >>> resource control functions. >>> >>> It has been said that: >>>>>>> There may be proxies in the >>>>>>> Diameter cloud that enforce their own policy decisions, some of >>>>>>> which will be local to the Network Element's administrative >>>>>>> domain. >>> >>> To my understanding that is why the separated interfaces make sense. >>> >>> An intermediate PDP (also referred to as PDF) may enforce further >>> policies (network type specific, user profile related, >>> operator-based) in conjunction with other network elements (resource >>> information, user database). >>> >>> Furthermore, the QoS description over the AF-PDP interface is likely >>> to differ from the QoS information describing the policy to be >>> instaslled in the NE, harmonizing and easing AF QoS requests and >>> enabling the QoS policy installation mechanism to evolve separately >>> in accordance to the transport network specifics. >>> >>> The PDP would certainly have an inter-domain interface to AFs and >>> other inter- an intra PDPs. I bnelieve that the Diameter QoS >>> application running between the AF and the PDP could be defined in a >>> way that it could be applied for the inter-domain PDP-PDP peering >>> interface. >>> >>> Unfortunately my contribution to the discussion at this point is not >>> enriching the discussion regarding the implications to the Diameter >>> functionality (e.g. command and AVPs, realm routing, discovery >>> schemes, etc.). >>> >>> However, I am sharing under >>> http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ >>> some figures depicting the abstracted SDOs architectures that could >>> help in the following discussions around the Diameter QoS >>> application. The figures have been extracted from the the paper "A >>> review on policy-based resource and admission control functions in >>> evolving access and next generation networks", recently accepted for >>> publication (draft copy can be provided if interested). >>> >>> >>> Best regards, >>> Christian >>>> >>>> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 03 05:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5f8q-0002Q8-BA; Tue, 03 Jul 2007 05:57:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5f8p-0002Pu-R1 for dime@ietf.org; Tue, 03 Jul 2007 05:57:51 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5f8o-0003Dc-FT for dime@ietf.org; Tue, 03 Jul 2007 05:57:51 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l639qUfD026392 for ; Tue, 3 Jul 2007 15:22:30 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l639qSiq026341; Tue, 3 Jul 2007 15:22:29 +0530 In-Reply-To: <46854C0C.3090007@tari.toshiba.com> To: Victor Fajardo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Himanshu Bahl Date: Tue, 3 Jul 2007 15:27:10 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 03/07/2007 03:31:06 PM, Serialize complete at 03/07/2007 03:31:06 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Amit Kumar PNGN , Preeti Shandilya , dime@ietf.org Subject: [Dime] Question Regarding Failed AVP. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1972067383==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1972067383== Content-Type: multipart/alternative; boundary="=_alternative 0036AC716525730D_=" This is a multipart message in MIME format. --=_alternative 0036AC716525730D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20all,=0D=0AIn=20the=20section=207.5=20of=20draft-ietf-dime-rfc3588bis= -04.txt=20it=20states=20that=20=0D=0A"=20A=20Diameter=20message=20SHOULD= =20contain=20only=20one=20Failed-AVP=20that=20corresponds=20=0D=0Ato=20th= e=20error=20indicated=20by=20the=20Result-Code=20AVP."=0D=0A=0D=0AThe=20d= ocument=20also=20states=20in=20the=20same=20section=20that=20=0D=0A"For= =20practical=20purposes,=20this=20Failed-AVP=20would=20typically=20refer= =20to=20the=20=0D=0Afirst=20AVP=20processing=20error=20that=20a=20Diamete= r=20node=20encounters."=0D=0A=0D=0Amy=20question=20is=20that=20if=20the= =20message=20is=20supposed=20to=20contain=20only=20one=20failed=20=0D=0AA= VP=20then=20why=20does=20the=20ABNF=20of=20messages=20CEA,DPA=20and=20DWA= =20have=20=20=20*[=20=0D=0AFailed-AVP=20].=0D=0A=0D=0ASecondly,=0D=0Aif= =20the=20failed=20AVP=20is=20supposed=20to=20contain=20the=20first=20erro= neous=20AVP=20in=20it=20why=20=0D=0Adoes=20its=20ABNF=20have=20=201*=20{A= VP}=20.=0D=0A=0D=0AThanks=20in=20advance,=0D=0A=0D=0ASincerely,=0D=0AHima= nshu=20Bahl=0D=0ASoftware=20Engineer=0D=0A=20=0D=0AA=20R=20I=20C=20E=20N= =20T=0D=0A?You=20can't=20shake=20hands=20with=20a=20clenched=20fist.?=0D= =0A=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Private=20=20= =20***********************=0D=0A"DISCLAIMER:=20This=20message=20is=20prop= rietary=20to=20Aricent=20=20and=20is=20intended=20solely=20for=20the=20us= e=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20ma= y=20contain=20privileged=20or=20confidential=20information=20and=20should= =20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20t= han=20for=20what=20it=20is=20intended.=20If=20you=20have=20received=20thi= s=20message=20in=20error,=20=0Aplease=20notify=20the=20originator=20immed= iately.=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are= =20notified=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20= copying,=20altering,=20or=20disclosing=20the=20contents=20of=20this=20mes= sage.=20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20da= mage=20arising=20from=20the=20use=20of=20the=20information=20transmitted= =20by=20this=20email=20including=20damage=20from=20virus."=0A --=_alternative 0036AC716525730D_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20all,=0D=0AIn=20the=20section=207.5=20of=0D=0Adraft-ietf-dime-rfc3588bis-04.txt=20it=20states= =20that=20=0D=0A
"= =20A=20Diameter=0D=0Amessage=20SHOULD=20conta= in=20only=20one=20Failed-AVP=20that=20corresponds=20to=20the=20error=0D= =0Aindicated=20by=20the=20Result-Code=20AVP."=0D=0A
=0D=0A
The=20document=20also=20states=20in=20the=20same= =0D=0Asection=20that=20=0D=0A
"For=20practical=0D=0Apurposes,=20= this=20Failed-AVP=20would=20typically=20refer=20to=20the=20first=20AVP=20= processing=0D=0Aerror=20that=20a=20Diameter=20node=20encounters."=0D=0A
=0D=0Amy=20question=20is=20that=20if= =20the=20message=20is=0D=0Asupposed=20to=20contain=20only=20one=20failed= =20AVP=20then=20why=20does=20the=20ABNF=20of=20messages=0D=0ACEA,DPA=20an= d=20DWA=20have=20 =20*[=20Failed-AVP=20]= .=0D=0A
=0D= =0A
Secondly,=0D=0A
<= font=20size=3D2=20face=3D"sans-serif">if=20the=20failed=20AVP=20is=20supp= osed=20to=20contain=0D=0Athe=20first=20erroneous=20AVP=20in=20it=20why=20= does=20its=20ABNF=20have=20 1*=0D=0A{AVP= }=20.=0D=0A
= =0D=0A
Thanks=20in=20advance,=0D=0A
=0D=0A
Sincerely= ,=0D=0A=0D=0A=0D=0AHimanshu=20Bahl<= /font>=0D=0A=0D=0ASoftware=20Engineer=0D=0A= =0D=0A =0D=0A=0D=0AA=20R=20I=20C=20E=20N=20T=0D=0A

“You=20can't=20shake=20hands=20with=20a=20clenched= =20fist.”=0D=0A
=0D=0A

=0D=0A
=0D=0A***********************=20 Aricent-Priva= te=20 =20***********************=0D=0A
"DISCLAIMER:=20This=20message=20=
is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20for=
=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed=
.=20It=20may=20contain=20privileged=20or=20confidential=20information=20a=
nd=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=
=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20have=20re=
ceived=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20origin=
ator=20immediately.=20If=20you=20are=20not=20the=20intended=20recipient,=
=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20from=
=20using,=20copying,=20altering,=20or=20disclosing=20the=20contents=20of=
=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for=20=0Al=
oss=20or=20damage=20arising=20from=20the=20use=20of=20the=20information=
=20transmitted=20by=20this=20email=20including=20damage=20from=20virus."=
=0A
--=_alternative 0036AC716525730D_=-- --===============1972067383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1972067383==-- From dime-bounces@ietf.org Tue Jul 03 06:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fHk-0006BR-4O; Tue, 03 Jul 2007 06:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fHj-0006BM-3X for dime@ietf.org; Tue, 03 Jul 2007 06:07:03 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5fHA-0002qr-5x for dime@ietf.org; Tue, 03 Jul 2007 06:07:03 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL00J0DLD9VY@szxga01-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 18:05:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL0034ULD80P@szxga01-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 18:05:33 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKL00LTULD31Q@szxml03-in.huawei.com> for dime@ietf.org; Tue, 03 Jul 2007 18:05:32 +0800 (CST) Date: Tue, 03 Jul 2007 15:35:27 +0530 From: Rajith R Subject: RE: [Dime] Question Regarding Failed AVP. In-reply-to: To: 'Himanshu Bahl' Message-id: <003c01c7bd59$aefdb4f0$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace9WKLVn/4GzxmcQ2SRMchkG6WROAAAMPsQ X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'Amit Kumar PNGN' , dime@ietf.org, 'Preeti Shandilya' X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060002693==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2060002693== Content-type: multipart/alternative; boundary="Boundary_(ID_Mg0fHpG9+UEh0hO2K2go1Q)" This is a multi-part message in MIME format. --Boundary_(ID_Mg0fHpG9+UEh0hO2K2go1Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT pls see inline _____ From: Himanshu Bahl [mailto:himanshu.bahl@aricent.com] Sent: Tuesday, July 03, 2007 3:27 PM To: Victor Fajardo Cc: Amit Kumar PNGN; Preeti Shandilya; dime@ietf.org Subject: [Dime] Question Regarding Failed AVP. Hi all, In the section 7.5 of draft-ietf-dime-rfc3588bis-04.txt it states that " A Diameter message SHOULD contain only one Failed-AVP that corresponds to the error indicated by the Result-Code AVP." The document also states in the same section that "For practical purposes, this Failed-AVP would typically refer to the first AVP processing error that a Diameter node encounters." my question is that if the message is supposed to contain only one failed AVP then why does the ABNF of messages CEA,DPA and DWA have *[ Failed-AVP ]. Rajith >> I think it should be [Failed-AVP] Secondly, if the failed AVP is supposed to contain the first erroneous AVP in it why does its ABNF have 1* {AVP} . Rajith>> For eg., in case of CONTRADICTING_AVPS result code, you could add those avp"s" to this grouped AVP Thanks in advance, Sincerely, Himanshu Bahl Software Engineer A R I C E N T "You can't shake hands with a clenched fist." *********************** Aricent-Private *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --Boundary_(ID_Mg0fHpG9+UEh0hO2K2go1Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

pls see inline

From: Himanshu Bahl [mailto:himanshu.bahl@aricent.com]
Sent: Tuesday, July 03, 2007 3:27 PM
To: Victor Fajardo
Cc: Amit Kumar PNGN; Preeti Shandilya; dime@ietf.org
Subject: [Dime] Question Regarding Failed AVP.


Hi all,
In the section 7.5 of draft-ietf-dime-rfc3588bis-04.txt it states that
" A Diameter message SHOULD contain only one Failed-AVP that corresponds to the error indicated by the Result-Code AVP."

The document also states in the same section that
"For practical purposes, this Failed-AVP would typically refer to the first AVP processing error that a Diameter node encounters."

my question is that if the message is supposed to contain only one failed AVP then why does the ABNF of messages CEA,DPA and DWA have   *[ Failed-AVP ].  
 
Rajith >>   I think it should be [Failed-AVP]

Secondly,
if the failed AVP is supposed to contain the first erroneous AVP in it why does its ABNF have  1* {AVP} .  
 
Rajith>> For eg., in case of CONTRADICTING_AVPS result code, you could add those avp"s" to this grouped AVP

Thanks in advance,

Sincerely,
Himanshu Bahl
Software Engineer
 
A R I C E N T

“You can't shake hands with a clenched fist.”



***********************  Aricent-Private   *********************** 
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."

--Boundary_(ID_Mg0fHpG9+UEh0hO2K2go1Q)-- --===============2060002693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2060002693==-- From dime-bounces@ietf.org Tue Jul 03 08:23:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hQ3-0007l6-Vd; Tue, 03 Jul 2007 08:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hQ1-0007l0-NC for dime@ietf.org; Tue, 03 Jul 2007 08:23:46 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5hPp-0003K8-Tv for dime@ietf.org; Tue, 03 Jul 2007 08:23:45 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l63CMKfh015103; Tue, 3 Jul 2007 08:22:20 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468A3F7C.5090509@tari.toshiba.com> Date: Tue, 03 Jul 2007 08:22:20 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Question Regarding Failed AVP. References: <003c01c7bd59$aefdb4f0$3a17120a@china.huawei.com> In-Reply-To: <003c01c7bd59$aefdb4f0$3a17120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dime@ietf.org, 'Amit Kumar PNGN' , 'Preeti Shandilya' X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > states that > " A Diameter message SHOULD contain only one Failed-AVP that > corresponds to the error indicated by the Result-Code AVP." > > The document also states in the same section that > "For practical purposes, this Failed-AVP would typically refer to > the first AVP processing error that a Diameter node encounters." > > my question is that if the message is supposed to contain only one > failed AVP then why does the ABNF of messages CEA,DPA and DWA have > *[ Failed-AVP ]. > > Rajith >> I think it should be [Failed-AVP] > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST" was based on backward compatibility concerns. I'm not sure if this is still a valid concern or not so it maybe best to hear from others as well. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 03 12:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5lb9-00061W-PF; Tue, 03 Jul 2007 12:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5lb8-00061K-Po; Tue, 03 Jul 2007 12:51:30 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5laJ-0006Xb-Cc; Tue, 03 Jul 2007 12:51:30 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 71600328EF; Tue, 3 Jul 2007 13:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5iDe-0004C3-Bk; Tue, 03 Jul 2007 09:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 09:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-qos-attributes-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter and RADIUS Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-00.txt Pages : 17 Date : 2007-7-3 This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-attributes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-attributes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-3085630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3085630.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jul 03 13:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5lyW-0008FL-II; Tue, 03 Jul 2007 13:15:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5lyO-00083E-D0; Tue, 03 Jul 2007 13:15:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5lyO-0000dB-4m; Tue, 03 Jul 2007 13:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D8BE417637; Tue, 3 Jul 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5lxt-00010l-F7; Tue, 03 Jul 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 13:15:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-split-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Bournelle, et al. Filename : draft-ietf-dime-mip6-split-03.txt Pages : 18 Date : 2007-7-3 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document that specifies the interaction between the Home Agent and the Diameter server. Two different mechanisms for authentication of a MN to the HA are supported. The first method consists of performing the Internet Key Exchange v2 (IKEv2) protocol along with the Extensible Authentication Protocol (EAP) with the Diameter server, while the second method utilizes the Mobile IPv6 Authentication option, as defined in RFC 4285. For Internet Key Exchange v2 with EAP-based authentication, the Diameter Mobile IPv6 application, defined in this document, reuses the commands defined in the Diameter EAP application, while for supporting the RFC 4285-style MIPv6 Authentication Options, a new Diameter application is defined that reuses the Diameter Mobile IPv4 application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-split-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-split-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-3124814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3124814.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jul 04 01:29:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5xQz-0007ba-NO; Wed, 04 Jul 2007 01:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5xQy-0007bV-Hu for dime@ietf.org; Wed, 04 Jul 2007 01:29:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5xPt-0002D0-RS for dime@ietf.org; Wed, 04 Jul 2007 01:29:48 -0400 Received: by ug-out-1314.google.com with SMTP id u2so662490uge for ; Tue, 03 Jul 2007 22:28:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=iJeCAN9QFk5TIT4fY7i6Q6bWL+ZnRx3l9nQ2Et8OX3sxU2PvBF6uIMcUjPFFW+cFpFMRkMsg6zQFO4AhxXs4SuZZhzEGrKRECeDG2WEg4P9qccp/qvWg0ykk3Y3rU9Wbvmsyt18ym50QalcPZhlfbqxT71J4PRYsQfPpdwgw3E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=QetzaJnPkJtXHTqdm20u7yR0nmSvu+7/VlOU+tuuBfiHDvJfbyMXkJOTzKaaiEv9Ma+lBNK3kfsPqo35+Fv6Mwk7AFV3/J0067mNS9AWxmoabDvbSyQsYtLFEZaQQ1aaBt9ZCFpXHKG5Bj9ryH7j2IJJdS90k2cNwhCs50+/dFk= Received: by 10.78.130.6 with SMTP id c6mr3914146hud.1183526920784; Tue, 03 Jul 2007 22:28:40 -0700 (PDT) Received: by 10.78.175.16 with HTTP; Tue, 3 Jul 2007 22:28:40 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 10:58:40 +0530 From: "naveen sarma" To: dime@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Dime] Re: DiME Digest, Vol 19, Issue 1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1988937602==" Errors-To: dime-bounces@ietf.org --===============1988937602== Content-Type: multipart/alternative; boundary="----=_Part_63265_890714.1183526920761" ------=_Part_63265_890714.1183526920761 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Victor, I have a question, for backward compatilibity means, is it related to the dictionary configuration of the base protocol? It seems to be more logical to have [Failed-AVP] instead of *[Failed-AVP], which i have already mentioned in the Jun27 mail with subject *"**Reg the Failed-AVP in CEA, DWA and DPA".* ** Regards, Naveen Date: Tue, 03 Jul 2007 08:22:20 -0400 > From: Victor Fajardo > Subject: Re: [Dime] Question Regarding Failed AVP. > To: rajithr@huawei.com > Cc: dime@ietf.org, 'Amit Kumar PNGN' , > 'Preeti Shandilya' > Message-ID: <468A3F7C.5090509@tari.toshiba.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > > states that > > " A Diameter message SHOULD contain only one Failed-AVP that > > corresponds to the error indicated by the Result-Code AVP." > > > > The document also states in the same section that > > "For practical purposes, this Failed-AVP would typically refer to > > the first AVP processing error that a Diameter node encounters." > > > > my question is that if the message is supposed to contain only one > > failed AVP then why does the ABNF of messages CEA,DPA and DWA have > > *[ Failed-AVP ]. > > > > Rajith >> I think it should be [Failed-AVP] > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST" > was based on backward compatibility concerns. I'm not sure if this is > still a valid concern or not so it maybe best to hear from others as well. > > -- victor > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 19, Issue 1 > *********************************** ------=_Part_63265_890714.1183526920761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Victor,
 
I have a question, for backward compatilibity means, is it related to the dictionary configuration of the base protocol?  It seems to be more logical to have [Failed-AVP] instead of *[Failed-AVP], which i have already mentioned in the Jun27 mail with subject "Reg the Failed-AVP in CEA, DWA and DPA".
 
Regards,
Naveen

Date: Tue, 03 Jul 2007 08:22:20 -0400
From: Victor Fajardo < vfajardo@tari.toshiba.com>
Subject: Re: [Dime] Question Regarding Failed AVP.
To: rajithr@huawei.com
Cc: dime@ietf.org, 'Amit Kumar PNGN' < amit8.kumar@aricent.com>,
       'Preeti Shandilya' <preeti.shandilya@aricent.com>
Message-ID: < 468A3F7C.5090509@tari.toshiba.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

>     In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it
>     states that
>     " A Diameter message SHOULD contain only one Failed-AVP that
>     corresponds to the error indicated by the Result-Code AVP."
>
>     The document also states in the same section that
>     "For practical purposes, this Failed-AVP would typically refer to
>     the first AVP processing error that a Diameter node encounters."
>
>     my question is that if the message is supposed to contain only one
>     failed AVP then why does the ABNF of messages CEA,DPA and DWA have
>       *[ Failed-AVP ].
>
>     Rajith >>   I think it should be [Failed-AVP]
>

Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST"
was based on backward compatibility concerns. I'm not sure if this is
still a valid concern or not so it maybe best to hear from others as well.

-- victor



------------------------------

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime


End of DiME Digest, Vol 19, Issue 1
***********************************
------=_Part_63265_890714.1183526920761-- --===============1988937602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1988937602==-- From dime-bounces@ietf.org Wed Jul 04 03:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ywu-0005FY-Jn; Wed, 04 Jul 2007 03:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ywt-0005FQ-Gp for dime@ietf.org; Wed, 04 Jul 2007 03:06:51 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ywR-0002jU-O6 for dime@ietf.org; Wed, 04 Jul 2007 03:06:51 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l6476MtR013238 for ; Wed, 4 Jul 2007 09:06:22 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l6476M4F012868 for ; Wed, 4 Jul 2007 09:06:22 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:06:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7BE09.D3BB638D" Date: Wed, 4 Jul 2007 09:06:22 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A407580224165B@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-muhanna-diameter-mip4-performance-00.txt Thread-Index: Ace9gDJ7/TBveY8vTGWCH4BSxG4kUgAC4GOAAB+EETA= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Jul 2007 07:06:22.0330 (UTC) FILETIME=[D3F3C5A0:01C7BE09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Dime] WG: [Mip4] FW: I-D ACTION:draft-muhanna-diameter-mip4-performance-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BE09.D3BB638D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document might be of interest for you.=20 -----Urspr=FCngliche Nachricht----- Von: ext Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Gesendet: Dienstag, 3. Juli 2007 19:02 An: mip4@ietf.org Cc: Mohamed Khalil; Ahmad Muhanna Betreff: [Mip4] FW: I-D = ACTION:draft-muhanna-diameter-mip4-performance-00.txt =20 Hello folks, We tried to make some comparison between the Diameter Mobile IPv4 Application and RADIUS based MIPv4 authentication and authorization procedures and their impact on the initial MIPv4 session setup. We tried to cover all scenarios but for sure we are looking forward for your feedback and comments to enhance this humble study. Many thanks in advance for your feedback. Regards, Ahmad -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, July 03, 2007 9:15 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-muhanna-diameter-mip4-performance-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 Author(s) : A. Muhanna, M. Khalil Filename : draft-muhanna-diameter-mip4-performance-00.txt Pages : 16 Date : 2007-7-3 =09 Current Mobile IPv4 deployments use RADIUS based MIPv4 user authentication and authorization. Diameter Mobile IPv4 Application [RFC4004] offers another method for MIPv4 authentication, authorization, and dynamic mobility security association allocation, e.g. MN-HA SA allocation. Some SDOs are considering the use of Diameter Mobile IPv4 Application to replace RADIUS based mechanism. This document presents an analysis of the performance and impact of Diameter MIPv4 Application and RADIUS based solutions on the time the mobile node uses during the initial session setup. Some common MIPv4 scenarios which require the mobile node to retransmit its initial RRQ message have been identified and used. The set of assumptions and requirements used for this study has been clearly documented under section 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-diameter-mip4-performa nce-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-muhanna-diameter-mip4-performance-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-muhanna-diameter-mip4-performance-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C7BE09.D3BB638D Content-Type: application/octet-stream; name="draft-muhanna-diameter-mip4-performance-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-diameter-mip4-performance-00.URL Content-Disposition: attachment; filename="draft-muhanna-diameter-mip4-performance-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLWRpYW1ldGVyLW1pcDQtcGVyZm9ybWFuY2UtMDAudHh0DQo= ------_=_NextPart_001_01C7BE09.D3BB638D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7BE09.D3BB638D-- From dime-bounces@ietf.org Wed Jul 04 03:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zVE-0004lx-B2; Wed, 04 Jul 2007 03:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zVD-0004lr-JU for dime@ietf.org; Wed, 04 Jul 2007 03:42:19 -0400 Received: from mail2.telenet-ag.de ([213.188.99.163] helo=proxy2.ip3k.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zV5-0004JF-KH for dime@ietf.org; Wed, 04 Jul 2007 03:42:19 -0400 Received: from [193.96.234.249] ([193.96.234.249]) (authenticated bits=0) by proxy2.ip3k.de (8.12.8/8.12.8) with ESMTP id l647g8pP017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 09:42:10 +0200 Message-ID: <468B4F4F.6040008@telenet-ag.de> Date: Wed, 04 Jul 2007 09:42:07 +0200 From: Michael Hillier User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------000705030005050705060203" X-Spam-Score: 0.6 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [Dime] Failover problems with Relays and crashed applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------000705030005050705060203 Content-Type: multipart/alternative; boundary="------------090007040602030106030105" --------------090007040602030106030105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss). All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops. Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason, however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp. Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue. Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed. Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness. Can anybody point out where I have gone wrong? Many thanks Mike Michael Hillier Telenet AG Rhein-Main M.Hillier@telenet-ag.de --------------090007040602030106030105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

another question has come up in practice.  Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running.  The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e  no CCAs are  returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx,  may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary:  client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de


 --------------090007040602030106030105-- --------------000705030005050705060203 Content-Type: text/x-vcard; charset=utf-8; name="m.hillier.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="m.hillier.vcf" begin:vcard fn:Michael Hillier n:Hillier;Michael email;internet:m.hillier@telenet-ag.de tel;work:+49 6151 733 333 tel;home:+49 6155 77456 tel;cell:+49 170 5454 121 x-mozilla-html:TRUE url:Michael.Hillier@web.de version:2.1 end:vcard --------------000705030005050705060203 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --------------000705030005050705060203-- From dime-bounces@ietf.org Wed Jul 04 04:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60i9-0003Wl-6T; Wed, 04 Jul 2007 04:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60i7-0003LO-6L for dime@ietf.org; Wed, 04 Jul 2007 04:59:43 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I60i2-0001Y9-Uk for dime@ietf.org; Wed, 04 Jul 2007 04:59:43 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00M6DCXUAZ@szxga02-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 16:58:42 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN0064LCXT3M@szxga02-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 16:58:42 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKN00L9FCXP80@szxml03-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 16:58:41 +0800 (CST) Date: Wed, 04 Jul 2007 14:28:37 +0530 From: Rajith R Subject: RE: [Dime] Failover problems with Relays and crashed applications In-reply-to: <468B4F4F.6040008@telenet-ag.de> To: 'Michael Hillier' , dime@ietf.org Message-id: <007d01c7be19$82df4a80$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace+DuEtXu9nFEfiRj+OY9r2NzhksgACTOTg X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1555323375==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1555323375== Content-type: multipart/alternative; boundary="Boundary_(ID_IQmaxTLkbiqNY0HH/VmtbA)" This is a multi-part message in MIME format. --Boundary_(ID_IQmaxTLkbiqNY0HH/VmtbA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update. AFAIK, DMT does not recommend/require a transaction time out based fail over. Regards Rajith _____ From: Michael Hillier [mailto:m.hillier@telenet-ag.de] Sent: Wednesday, July 04, 2007 1:12 PM To: dime@ietf.org Subject: [Dime] Failover problems with Relays and crashed applications Hi all, another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss). All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops. Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason, however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp. Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue. Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed. Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness. Can anybody point out where I have gone wrong? Many thanks Mike Michael Hillier Telenet AG Rhein-Main M.Hillier@telenet-ag.de --Boundary_(ID_IQmaxTLkbiqNY0HH/VmtbA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update.
AFAIK, DMT does not recommend/require a transaction time out based fail over.
 
Regards
 
Rajith

From: Michael Hillier [mailto:m.hillier@telenet-ag.de]
Sent: Wednesday, July 04, 2007 1:12 PM
To: dime@ietf.org
Subject: [Dime] Failover problems with Relays and crashed applications

Hi all,

another question has come up in practice.  Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running.  The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e  no CCAs are  returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx,  may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary:  client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de


--Boundary_(ID_IQmaxTLkbiqNY0HH/VmtbA)-- --===============1555323375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1555323375==-- From dime-bounces@ietf.org Wed Jul 04 05:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I612d-0001O3-5g; Wed, 04 Jul 2007 05:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I612b-0001Nx-Pk for dime@ietf.org; Wed, 04 Jul 2007 05:20:53 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I612X-0004ct-B7 for dime@ietf.org; Wed, 04 Jul 2007 05:20:53 -0400 Received: by wa-out-1112.google.com with SMTP id k17so3627063waf for ; Wed, 04 Jul 2007 02:20:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=MjOZytD4DvFU71c47v2MI2ZF2r8+kucu8eYB23wf1DwzOeZVGq+YY0SXGlkQVbzrPZ3wu9eTHi1vPZHIhPCaMaRuFTZt7WKr68h78+azZ80sX8AcecJQbttbkXPCvRmhgts7JaKAK8mQOBpqP6G7wHhZ+uupxes/S76Ej7K5U18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HIp7OJgjUHND2kDIeLprL2XPlbYGCZxEGS5Hi3sOK7VQSOlFza1r4OcSd9au6Fk0SriZGoyBJUinKP+Au5ooqje5mczt1GFHBLl0sQWtPxPx8nh0ohSQ50dDNL0V7ZOnd7+ntM7UEci9gp9Lcx+BgU3Y23Ib+DWHaJcH2cF4zo8= Received: by 10.114.169.2 with SMTP id r2mr7065035wae.1183540848446; Wed, 04 Jul 2007 02:20:48 -0700 (PDT) Received: by 10.115.79.17 with HTTP; Wed, 4 Jul 2007 02:20:48 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 11:20:48 +0200 From: "Thomas Lindgren" To: dime@ietf.org Subject: Re: [Dime] Question Regarding Failed AVP. In-Reply-To: <468A3F7C.5090509@tari.toshiba.com> MIME-Version: 1.0 References: <003c01c7bd59$aefdb4f0$3a17120a@china.huawei.com> <468A3F7C.5090509@tari.toshiba.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651244717==" Errors-To: dime-bounces@ietf.org --===============0651244717== Content-Type: multipart/alternative; boundary="----=_Part_128276_27049003.1183540848425" ------=_Part_128276_27049003.1183540848425 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/3/07, Victor Fajardo wrote: > > Hi, > > > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > > states that > > " A Diameter message SHOULD contain only one Failed-AVP that > > corresponds to the error indicated by the Result-Code AVP." > > > > The document also states in the same section that > > "For practical purposes, this Failed-AVP would typically refer to > > the first AVP processing error that a Diameter node encounters." > > > > my question is that if the message is supposed to contain only one > > failed AVP then why does the ABNF of messages CEA,DPA and DWA have > > *[ Failed-AVP ]. > > > > Rajith >> I think it should be [Failed-AVP] > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST" > was based on backward compatibility concerns. I'm not sure if this is > still a valid concern or not so it maybe best to hear from others as well. Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? That one allows returning two or more Failed-AVPs if necessary. It's not mentioned in 7.5 though. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_128276_27049003.1183540848425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/3/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi,

>     In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it
>     states that
>     " A Diameter message SHOULD contain only one Failed-AVP that
>     corresponds to the error indicated by the Result-Code AVP."
>
>     The document also states in the same section that
>     "For practical purposes, this Failed-AVP would typically refer to
>     the first AVP processing error that a Diameter node encounters."
>
>     my question is that if the message is supposed to contain only one
>     failed AVP then why does the ABNF of messages CEA,DPA and DWA have
>       *[ Failed-AVP ].
>
>     Rajith >>   I think it should be [Failed-AVP]
>

Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST"
was based on backward compatibility concerns. I'm not sure if this is
still a valid concern or not so it maybe best to hear from others as well.

Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? That one allows returning two or more Failed-AVPs if necessary. It's not mentioned in 7.5 though.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd



------=_Part_128276_27049003.1183540848425-- --===============0651244717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0651244717==-- From dime-bounces@ietf.org Wed Jul 04 05:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I617S-00063e-7W; Wed, 04 Jul 2007 05:25:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I617R-00063R-Ai for dime@ietf.org; Wed, 04 Jul 2007 05:25:53 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I617M-000547-90 for dime@ietf.org; Wed, 04 Jul 2007 05:25:53 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00MGNE5IWV@szxga02-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 17:24:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN005UKE5H7O@szxga02-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 17:24:54 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKN00LHTE5D83@szxml03-in.huawei.com> for dime@ietf.org; Wed, 04 Jul 2007 17:24:53 +0800 (CST) Date: Wed, 04 Jul 2007 14:54:49 +0530 From: Rajith R Subject: RE: [Dime] Question Regarding Failed AVP. In-reply-to: To: 'Thomas Lindgren' , dime@ietf.org Message-id: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace+HKPPHIPh5/u7StSMgD5prCmfEwAADLIQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0414364388==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0414364388== Content-type: multipart/alternative; boundary="Boundary_(ID_32qSMPE2sCgwq/UmdcIpeA)" This is a multi-part message in MIME format. --Boundary_(ID_32qSMPE2sCgwq/UmdcIpeA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In this case, you may include those AVPs as the "sub" AVPs of Failed-AVP. Failed-AVP AVP is a "grouped" AVP. As I have mentioned earlier, Failed-AVP AVP corresponds to Result Code, and as long as you have just one result code, it makes sense to have just one Failed-AVP AVP. This AVP itself might include one or more sub AVPs. _____ From: Thomas Lindgren [mailto:u.thomas.lindgren@gmail.com] Sent: Wednesday, July 04, 2007 2:51 PM To: dime@ietf.org Subject: Re: [Dime] Question Regarding Failed AVP. On 7/3/07, Victor Fajardo wrote: Hi, > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > states that > " A Diameter message SHOULD contain only one Failed-AVP that > corresponds to the error indicated by the Result-Code AVP." > > The document also states in the same section that > "For practical purposes, this Failed-AVP would typically refer to > the first AVP processing error that a Diameter node encounters." > > my question is that if the message is supposed to contain only one > failed AVP then why does the ABNF of messages CEA,DPA and DWA have > *[ Failed-AVP ]. > > Rajith >> I think it should be [Failed-AVP] > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST" was based on backward compatibility concerns. I'm not sure if this is still a valid concern or not so it maybe best to hear from others as well. Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? That one allows returning two or more Failed-AVPs if necessary. It's not mentioned in 7.5 though. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd --Boundary_(ID_32qSMPE2sCgwq/UmdcIpeA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
In this case, you may include those AVPs as the "sub" AVPs of Failed-AVP. Failed-AVP AVP is a "grouped" AVP.
As I have mentioned earlier, Failed-AVP AVP corresponds to Result Code, and as long as you have just one result code, it makes sense to have just one Failed-AVP AVP. This AVP itself might include one or more sub AVPs.

From: Thomas Lindgren [mailto:u.thomas.lindgren@gmail.com]
Sent: Wednesday, July 04, 2007 2:51 PM
To: dime@ietf.org
Subject: Re: [Dime] Question Regarding Failed AVP.



On 7/3/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi,

>     In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it
>     states that
>     " A Diameter message SHOULD contain only one Failed-AVP that
>     corresponds to the error indicated by the Result-Code AVP."
>
>     The document also states in the same section that
>     "For practical purposes, this Failed-AVP would typically refer to
>     the first AVP processing error that a Diameter node encounters."
>
>     my question is that if the message is supposed to contain only one
>     failed AVP then why does the ABNF of messages CEA,DPA and DWA have
>       *[ Failed-AVP ].
>
>     Rajith >>   I think it should be [Failed-AVP]
>

Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST"
was based on backward compatibility concerns. I'm not sure if this is
still a valid concern or not so it maybe best to hear from others as well.

Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? That one allows returning two or more Failed-AVPs if necessary. It's not mentioned in 7.5 though.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd



--Boundary_(ID_32qSMPE2sCgwq/UmdcIpeA)-- --===============0414364388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0414364388==-- From dime-bounces@ietf.org Wed Jul 04 06:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I627W-0006AB-KJ; Wed, 04 Jul 2007 06:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I627V-0006A5-5Z for dime@ietf.org; Wed, 04 Jul 2007 06:30:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I627N-0006eN-08 for dime@ietf.org; Wed, 04 Jul 2007 06:30:01 -0400 Received: by ug-out-1314.google.com with SMTP id u2so722622uge for ; Wed, 04 Jul 2007 03:29:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Ii5mCU3AFds9EuHAVB7eVJ9SxytWjU4ZDyxrV+JK3NL+etygWtfnzjufHmgRk8BNew1E+Hqn5nuDZSKFHWaaKxJw8mT0zzSpzt8Di/2H9AcYDJ91BUkMNUxlfRa51ER5dCbADvpcXxF3WJQbRsJwHyqSAPwnQsjFQh8Bdr531i8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ZiUlBi6UC1rqN0d7SgTm6knQv/S86tRO7MLW9oT9WPeKaJuBNyCck88/HkXfFCOxuMtzA8RwZ6zi0ZNAeKJp0Nwn5A7zDBlGmgLQxSauSri22dqS8OPHTer3rZuxSSuqqzuQ+HMeNd4yrVMMDlQ+7LnGUse2btQUL19fzfOJf2I= Received: by 10.82.151.14 with SMTP id y14mr17524893bud.1183544991876; Wed, 04 Jul 2007 03:29:51 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Wed, 4 Jul 2007 03:29:51 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 15:59:51 +0530 From: "harish raghuveer" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] accounting-sub-session-id avp code X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727187560==" Errors-To: dime-bounces@ietf.org --===============1727187560== Content-Type: multipart/alternative; boundary="----=_Part_116189_4631745.1183544991524" ------=_Part_116189_4631745.1183544991524 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I see that in the sections 4.5 and 9.8.6 of RFC 3588 and the draft-ietf-dime-rfc3588bis-04.txt the code for Acct-Sub-Session-Id AVP is given as 287 where as IANA registry ( http://www.iana.org/assignments/aaa-parameters) shows the code for the AVP as 487. Which one is correct? thanks, Harish R Prabhu ------=_Part_116189_4631745.1183544991524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I see that in the sections 4.5 and 9.8.6 of RFC 3588 and the draft-ietf-dime-rfc3588bis-04.txt the code for Acct-Sub-Session-Id AVP is given as 287 where as IANA registry ( http://www.iana.org/assignments/aaa-parameters) shows the code for the AVP as 487. Which one is correct?

thanks,
Harish R Prabhu
------=_Part_116189_4631745.1183544991524-- --===============1727187560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1727187560==-- From dime-bounces@ietf.org Wed Jul 04 07:52:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63PK-0003qD-PT; Wed, 04 Jul 2007 07:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63PK-0003pj-AO for dime@ietf.org; Wed, 04 Jul 2007 07:52:30 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I63P8-00084m-Fj for dime@ietf.org; Wed, 04 Jul 2007 07:52:30 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1452617nzf for ; Wed, 04 Jul 2007 04:52:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=OfeDKgX4A65qWtZr4MGhcujBZZ8Xgm3XmEAnPOV42lSgElQh0GzPDLnXGn+3ioBKaAM1wxh+2rTO40czlOawR3sY4+nSzebPatAKpD0RzQLMBoycphuYMJJcmWprl0zI6gmhac3buyBu/0l9JFacOdQzXgTzSMkFpZamhaMPVYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=peHqFxr7i5YQzf8N6YIJ8fXSCWGzHfjNy89+7mbXBXP5iBcBlLCzEoZAS3V5HrwjlXONA/ijByJe6K31Lk+Xq8Lg7L3BRTOfvivAwKwWdCc1ctEtt/NnCkEKIffqXvZndOK5Y4/+yxFlaCW07PGYE3mYKdEPbOumaNVd7GPE3U0= Received: by 10.114.177.1 with SMTP id z1mr7178642wae.1183549937449; Wed, 04 Jul 2007 04:52:17 -0700 (PDT) Received: by 10.115.79.17 with HTTP; Wed, 4 Jul 2007 04:52:17 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 13:52:17 +0200 From: "Thomas Lindgren" To: rajithr@huawei.com Subject: Re: [Dime] Question Regarding Failed AVP. In-Reply-To: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> MIME-Version: 1.0 References: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0604616287==" Errors-To: dime-bounces@ietf.org --===============0604616287== Content-Type: multipart/alternative; boundary="----=_Part_129376_33157638.1183549937418" ------=_Part_129376_33157638.1183549937418 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/4/07, Rajith R wrote: > > In this case, you may include those AVPs as the "sub" AVPs of Failed-AVP. > Failed-AVP AVP is a "grouped" AVP. > As I have mentioned earlier, Failed-AVP AVP corresponds to Result Code, > and as long as you have just one result code, it makes sense to have just > one Failed-AVP AVP. This AVP itself might include one or more sub AVPs. > Right, though in that case 7.1.5/5007 also needs to be updated since it explicitly permits more than one Failed-AVP. I'm not sure which is the best choice -- it's tempting to make things more elegant, but there's something to be said for nailing down the status quo too. Either way, some clarification seems useful. Best, Thomas ------------------------------ > *From:* Thomas Lindgren [mailto:u.thomas.lindgren@gmail.com] > *Sent:* Wednesday, July 04, 2007 2:51 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] Question Regarding Failed AVP. > > > > On 7/3/07, Victor Fajardo wrote: > > > > Hi, > > > > > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > > > states that > > > " A Diameter message SHOULD contain only one Failed-AVP that > > > corresponds to the error indicated by the Result-Code AVP." > > > > > > The document also states in the same section that > > > "For practical purposes, this Failed-AVP would typically refer to > > > the first AVP processing error that a Diameter node encounters." > > > > > > my question is that if the message is supposed to contain only one > > > failed AVP then why does the ABNF of messages CEA,DPA and DWA have > > > *[ Failed-AVP ]. > > > > > > Rajith >> I think it should be [Failed-AVP] > > > > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST" > > was based on backward compatibility concerns. I'm not sure if this is > > still a valid concern or not so it maybe best to hear from others as > > well. > > > Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? > That one allows returning two or more Failed-AVPs if necessary. It's not > mentioned in 7.5 though. > > Best, > Thomas > -- > Thomas Lindgren, Millpond Services Ltd > > > > ------=_Part_129376_33157638.1183549937418 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 7/4/07, Rajith R <rajithr@huawe= i.com> wrote:
In=20 this case, you may include those AVPs as the "sub" AVPs of Failed= -AVP.=20 Failed-AVP AVP is a "grouped" AVP.
As I=20 have mentioned earlier, Failed-AVP AVP corresponds to Result Code, and as l= ong=20 as you have just one result code, it makes sense to have just one Failed-AV= P=20 AVP. This AVP itself might include one or more sub AVPs.

Right, though in that case 7.1.5/5007 also nee= ds to be updated since it explicitly permits more than one Failed-AVP. I= 9;m not sure which is the best choice -- it's tempting to make things m= ore elegant, but there's something to be said for nailing down the stat= us quo too. Either way, some clarification seems useful.

Best,
Thomas
 

From: Thomas Lindgren=20 [mailto: u.thomas.lindgren@gmail.com<= /a>]
Sent: Wednesday, July 04, 2007=20 2:51 PM
To: dime@ietf.org
Subject: Re: [= Dime] Question=20 Regarding Failed AVP.



On 7/3/07, Victor=20 Fajardo < vfajardo@tari.toshiba.com&= gt;=20 wrote:
Hi,

>=     =20 In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/=20 it
>     states=20 that
>     " A Diameter message SHOULD c= ontain=20 only one Failed-AVP that
>     corresponds to= the=20 error indicated by the Result-Code AVP."=20
>
>     The document also states in th= e=20 same section that
>     "For practical p= urposes,=20 this Failed-AVP would typically refer to
>    = ; the=20 first AVP processing error that a Diameter node encounters."=20
>
>     my question is that if the mes= sage=20 is supposed to contain only one
>     failed = AVP=20 then why does the ABNF of messages CEA,DPA and DWA=20 have
>       *[ Failed-AVP=20 ].
>
>     Rajith >>   = I=20 think it should be [Failed-AVP]
>

Keeping the *[Failed-AV= P]=20 ABNF and using a "SHOULD" instead of a "MUST"
wa= s based on backward=20 compatibility concerns. I'm not sure if this is
still a valid co= ncern or=20 not so it maybe best to hear from others as well.

Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007)= =20 occur? That one allows returning two or more Failed-AVPs if necessary. It= 's=20 not mentioned in 7.5 though.

Best,
Thomas
--
Thomas Lindg= ren,=20 Millpond Services Ltd




------=_Part_129376_33157638.1183549937418-- --===============0604616287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0604616287==-- From dime-bounces@ietf.org Wed Jul 04 07:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63Pt-0003xt-8M; Wed, 04 Jul 2007 07:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63Ps-0003xm-Hs for dime@ietf.org; Wed, 04 Jul 2007 07:53:04 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I63Ph-0008By-4t for dime@ietf.org; Wed, 04 Jul 2007 07:53:04 -0400 Received: by wr-out-0506.google.com with SMTP id i23so76858wra for ; Wed, 04 Jul 2007 04:52:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ech449ZlIPkx7wSeWA1nq2xoySgj8BGmlQKHwJCUMSh0zKFAMvSIEkMlnZ0WVdRoqDkzQVxlG+9S8meZimk6wEXuwakxOVf9MGje59srL72Rs1EhNo/2ZNp9k7Yq4ABFrskoFTtcYVQPHrjPP7BPUljv/ocdEwW936urIgti6lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ml8dXfblfKgd0unDwyyLulamYCcQajiXyIrMvreJlwp7PS88QIAwRHTmIGGfLaEy1vsPqeoQC+MMw10QC1OfEB8qgVbPPzoCZAPIto4GMhGW2LsKco8t1WUgkEwEsjx+mFDfVK530V27D7bgjgV97NewRzYnO+6m6ITCVAeXg7Q= Received: by 10.78.178.5 with SMTP id a5mr4077762huf.1183549971889; Wed, 04 Jul 2007 04:52:51 -0700 (PDT) Received: by 10.78.175.16 with HTTP; Wed, 4 Jul 2007 04:52:51 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 17:22:51 +0530 From: "naveen sarma" To: "Michael Hillier" , dime@ietf.org Subject: Re: [Dime] Failover problems with Relays and crashed applications In-Reply-To: <468B4F4F.6040008@telenet-ag.de> MIME-Version: 1.0 References: <468B4F4F.6040008@telenet-ag.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1038550738==" Errors-To: dime-bounces@ietf.org --===============1038550738== Content-Type: multipart/alternative; boundary="----=_Part_64482_32328774.1183549971867" ------=_Part_64482_32328774.1183549971867 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, Failover will be done only in case of the peer node is in suspect state and not even responding for the DWR message. In your case it might happen that Rp is still in open state (Rp is responding for DWR from C), so the messages are re-sent to the same Rp. As per the 3588, base protocol need not start any timer for each message sent to peer. So inorder to test failover with the existing relay setup, kill or suspend (in gdb) Rp. Regards, Naveen On 7/4/07, Michael Hillier wrote: > > Hi all, > > another question has come up in practice. Again we are in the context of Credit > Control Application, but the issue must be applicable to all such > applications which define their own failover mechanisms > > > Given a client (C) communicating via a primary and secondary relay (Rp, > Rs) towards a primary and secondary server (Sp, Ss). > > All Diameter connections are up and running. The client selects Rp and Rp > selects Sp, being the primary next hops. > > Now the primary Server stops answering the application requests (i.e no > CCAs are returned) - for what ever reason, > however the connection Rp <=> Sp is still ticking over, i.e. DWRs are > being answered by Sp. > > Short timers, like Tx, may expire in the client, possibly allowing > service to be delivered, but that is a side issue. > > Now the transaction timer expires causing the client to failover to the > secondary relay (Rs), i.e. re-sending the CCR with T-bit > Rs selects the primary Server, because it does not know any reason not to, > and thus the CCR(with T-bit) is sent to the same server which has failed. > > Summary: client failover to secondary next hop works nicely when directly > connected to the Diameter servers, but does not achieve the desired effect > when relays are used, which have no "application timer" awareness. > > Can anybody point out where I have gone wrong? > > Many thanks > > Mike > > Michael Hillier > Telenet AG Rhein-Main > M.Hillier@telenet-ag.de > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > -- Yours Naveen. ------=_Part_64482_32328774.1183549971867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Mike,
 
Failover will be done only in case of the peer node is in suspect state and not even responding for the DWR message.  In your case it might happen that Rp is still in open state (Rp is responding for DWR from C), so the messages are re-sent to the same Rp.  As per the 3588, base protocol need not start any timer for each message sent to peer.  So inorder to test failover with the existing relay setup, kill or suspend (in gdb) Rp.
 
Regards,
Naveen

 
On 7/4/07, Michael Hillier <m.hillier@telenet-ag.de> wrote:
Hi all,

another question has come up in practice.  Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running.  The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e  no CCAs are  returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx,  may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary:  client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime





--
Yours
Naveen. ------=_Part_64482_32328774.1183549971867-- --===============1038550738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1038550738==-- From dime-bounces@ietf.org Wed Jul 04 08:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I644K-0006js-9o; Wed, 04 Jul 2007 08:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I644J-0006jn-9g for dime@ietf.org; Wed, 04 Jul 2007 08:34:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I644C-000281-63 for dime@ietf.org; Wed, 04 Jul 2007 08:34:50 -0400 Received: by ug-out-1314.google.com with SMTP id u2so752068uge for ; Wed, 04 Jul 2007 05:34:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=X2I+s7Ljol1xpN7dnmc57ncy3ojoDYTsxabksleh7y/TRdctUvTHgq29S/AYo7nczTtVTwysMItlJpoegutCj/cFrhkTBuuJr0CGZ2UJgzo3A5/6ZaMdpGkbB6PTHu/RvfNdpzN9qcDITylYxK/4BtRL6ABvzzypCiTdJv+xdaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ItPyjgrQvZd4RXhHH7V/GoIXPID5S+QRGzhpTvn5eO57Gn5hmChu33tVvzoQdFhrkwCmdJnWj0mVcAdvzheiVpD5yvkCEP7rvmUxtVxiD15RNyFIDdZ0my5J3SGAXr4Yurlwml054f84ojrbTMhP1A14mlVgPKR1XE6dXvpeS6s= Received: by 10.82.152.16 with SMTP id z16mr17784732bud.1183552483071; Wed, 04 Jul 2007 05:34:43 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Wed, 4 Jul 2007 05:34:43 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 18:04:43 +0530 From: "harish raghuveer" To: dime@ietf.org Subject: Re: [Dime] Question Regarding Failed AVP. In-Reply-To: MIME-Version: 1.0 References: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160577097==" Errors-To: dime-bounces@ietf.org --===============0160577097== Content-Type: multipart/alternative; boundary="----=_Part_116922_6556732.1183552483045" ------=_Part_116922_6556732.1183552483045 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I also had the thought that a single Failed-AVP corresponds to a single result code. If the parser implementation can report multiple errors (consider a case where a request message with multiple unsupported AVPs and a few enum type AVPs with invalid values), it definitely makes sense to have multiple Failed-AVPs, each corresponding to a specific type of error. But that would need the inclusion of "*1 {Result-Code}" in Failed-AVPs ABNF. IMHO, the new ABNF definition would also be backward compatible because there is no requirement on min. number of occurrences of Result-Code AVP. The receiver of the response with Failed-AVP can either use the common Result-code in the message or Failed-AVP specific result code to isolate the cause of error (for debugging purposes). My $0.02. thanks, Harish On 7/4/07, Thomas Lindgren wrote: > > > > On 7/4/07, Rajith R wrote: > > > > In this case, you may include those AVPs as the "sub" AVPs of > > Failed-AVP. Failed-AVP AVP is a "grouped" AVP. > > As I have mentioned earlier, Failed-AVP AVP corresponds to Result Code, > > and as long as you have just one result code, it makes sense to have just > > one Failed-AVP AVP. This AVP itself might include one or more sub AVPs. > > > > Right, though in that case 7.1.5/5007 also needs to be updated since it > explicitly permits more than one Failed-AVP. I'm not sure which is the best > choice -- it's tempting to make things more elegant, but there's something > to be said for nailing down the status quo too. Either way, some > clarification seems useful. > > Best, > Thomas > > > ------------------------------ > > *From:* Thomas Lindgren [mailto: u.thomas.lindgren@gmail.com] > > *Sent:* Wednesday, July 04, 2007 2:51 PM > > *To:* dime@ietf.org > > *Subject:* Re: [Dime] Question Regarding Failed AVP. > > > > > > > > On 7/3/07, Victor Fajardo < vfajardo@tari.toshiba.com> wrote: > > > > > > Hi, > > > > > > > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > > > > states that > > > > " A Diameter message SHOULD contain only one Failed-AVP that > > > > corresponds to the error indicated by the Result-Code AVP." > > > > > > > > The document also states in the same section that > > > > "For practical purposes, this Failed-AVP would typically refer > > > to > > > > the first AVP processing error that a Diameter node encounters." > > > > > > > > > > > my question is that if the message is supposed to contain only > > > one > > > > failed AVP then why does the ABNF of messages CEA,DPA and DWA > > > have > > > > *[ Failed-AVP ]. > > > > > > > > Rajith >> I think it should be [Failed-AVP] > > > > > > > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a > > > "MUST" > > > was based on backward compatibility concerns. I'm not sure if this is > > > still a valid concern or not so it maybe best to hear from others as > > > well. > > > > > > Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? > > That one allows returning two or more Failed-AVPs if necessary. It's not > > mentioned in 7.5 though. > > > > Best, > > Thomas > > -- > > Thomas Lindgren, Millpond Services Ltd > > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- Harish R Prabhu Bangalore, India. ------=_Part_116922_6556732.1183552483045 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I also had the thought that a single Failed-AVP corresponds to a single result code. If the parser implementation can report multiple errors (consider a case where a request message with multiple unsupported AVPs and a few enum type AVPs with invalid values), it definitely makes sense to have multiple Failed-AVPs, each corresponding to a specific type of error. But that would need the inclusion of "*1 {Result-Code}" in Failed-AVPs  ABNF.  IMHO, the new ABNF definition would also be backward compatible because there is no requirement on min. number of occurrences of Result-Code AVP. The receiver of the response with Failed-AVP can either use the common Result-code in the message or Failed-AVP specific result code to isolate the cause of error (for debugging purposes).

My $0.02.

thanks,
Harish

On 7/4/07, Thomas Lindgren <u.thomas.lindgren@gmail.com> wrote:


On 7/4/07, Rajith R <rajithr@huawei.com> wrote:
In this case, you may include those AVPs as the "sub" AVPs of Failed-AVP. Failed-AVP AVP is a "grouped" AVP.
As I have mentioned earlier, Failed-AVP AVP corresponds to Result Code, and as long as you have just one result code, it makes sense to have just one Failed-AVP AVP. This AVP itself might include one or more sub AVPs.

Right, though in that case 7.1.5/5007 also needs to be updated since it explicitly permits more than one Failed-AVP. I'm not sure which is the best choice -- it's tempting to make things more elegant, but there's something to be said for nailing down the status quo too. Either way, some clarification seems useful.

Best,
Thomas
 

From: Thomas Lindgren [mailto: u.thomas.lindgren@gmail.com]
Sent: Wednesday, July 04, 2007 2:51 PM
To: dime@ietf.org
Subject: Re: [Dime] Question Regarding Failed AVP.



On 7/3/07, Victor Fajardo < vfajardo@tari.toshiba.com> wrote:
Hi,

>     In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it
>     states that
>     " A Diameter message SHOULD contain only one Failed-AVP that
>     corresponds to the error indicated by the Result-Code AVP."
>
>     The document also states in the same section that
>     "For practical purposes, this Failed-AVP would typically refer to
>     the first AVP processing error that a Diameter node encounters."
>
>     my question is that if the message is supposed to contain only one
>     failed AVP then why does the ABNF of messages CEA,DPA and DWA have
>       *[ Failed-AVP ].
>
>     Rajith >>   I think it should be [Failed-AVP]
>

Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a "MUST"
was based on backward compatibility concerns. I'm not sure if this is
still a valid concern or not so it maybe best to hear from others as well.

Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no 5007) occur? That one allows returning two or more Failed-AVPs if necessary. It's not mentioned in 7.5 though.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd





_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime




--
Harish R Prabhu
Bangalore, India. ------=_Part_116922_6556732.1183552483045-- --===============0160577097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0160577097==-- From dime-bounces@ietf.org Wed Jul 04 16:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6B4s-0001kX-Fn; Wed, 04 Jul 2007 16:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6B4r-0001hU-7S for dime@ietf.org; Wed, 04 Jul 2007 16:03:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6B4n-0001cU-1U for dime@ietf.org; Wed, 04 Jul 2007 16:03:53 -0400 Received: (qmail invoked by alias); 04 Jul 2007 20:03:46 -0000 Received: from p549877AB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.119.171] by mail.gmx.net (mp032) with SMTP; 04 Jul 2007 22:03:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199R3Qw6Rh978TAC6Udc0IXHS8r1YSXHEeR6veSPo b6bBCi3WL9M11L Message-ID: <468BFD22.1020501@gmx.net> Date: Wed, 04 Jul 2007 22:03:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------040108000007020302040504" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a1acaa54b4cde5ab4439a319e9b7f91 Subject: [Dime] Diameter Classifier Document X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------040108000007020302040504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Avi has written a document that defines classifiers with a binary encoding instead of a textual encoding currently being investigated in the RADEXT working group with http://tools.ietf.org/wg/radext/draft-ietf-radext-filter-rules/. One of the benefits is better extensibility. You can find the document in the attachment. It would be great to hear your thoughts about this issue. Btw, there is impact on the QoS attribute document. Ciao Hannes --------------040108000007020302040504 Content-Type: text/plain; name="draft-lior-diameter-classifier-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-lior-diameter-classifier-00.txt" Network Working Group A. Lior Internet-Draft Bridgewater Systems Intended status: Standards Track June 27, 2007 Expires: December 29, 2007 Diameter Classifier draft-lior-diameter-classifier-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lior Expires December 29, 2007 [Page 1] Internet-Draft Diameter Classifier June 2007 Abstract Many Diameter applications require classifying packets. Diameter base protocols provides an IP Filter Rule type and a QoS Filter Rule type that is being used to classify packets. However, because these types were defined for specific uses and defined in ways that are hard to extend and therefore are not generally applicable for those applications that require packet classifiers. This document describes a set of Diameter types that are useful to create packet classifiers. The packet classier type can be used by various applications to express packet classifiers that best match the application's specific needs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Classifier Attribute Overview . . . . . . . . . . . . . . . . 5 4. Classifier AVP . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Source and Destination Attributes . . . . . . . . . . . . 9 5.1.1. Inverted AVP . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. IPAddress AVP . . . . . . . . . . . . . . . . . . . . 9 5.1.3. Port AVP . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.4. IPAddressRange AVP . . . . . . . . . . . . . . . . . . 9 5.1.5. IPAddressMask AVP . . . . . . . . . . . . . . . . . . 10 5.1.6. PortRange AVP . . . . . . . . . . . . . . . . . . . . 10 5.1.7. Assigned AVP . . . . . . . . . . . . . . . . . . . . . 10 5.2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. FragFlag AVP . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. IPOptions AVP . . . . . . . . . . . . . . . . . . . . 10 5.2.3. TCPOptions AVP . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Established AVP . . . . . . . . . . . . . . . . . . . 11 5.2.5. Setup AVP . . . . . . . . . . . . . . . . . . . . . . 11 5.2.6. TCPFlags AVP . . . . . . . . . . . . . . . . . . . . . 11 5.2.7. ICMPTypes . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Lior Expires December 29, 2007 [Page 2] Internet-Draft Diameter Classifier June 2007 1. Introduction The Diameter base protocol [2] defines two data formats, IPFilterRule and QoSFilterRule. IPFilterRule is designed to implement packet filters and QoSFilterRule tagging and metering of packets. Both of these data formats are expressed as an ASCII string which makes it impossible to extend and also makes it difficult to parse and thus equipment suffer a performance hit. Many applications require to express packet classifiers. QoS based applications need to be able to express which packets to apply a certain QoS treatment. Charging applications need to be able to express which packets should be have certain charging rules applied to them. Some applications need to be able to redirect certain packets. The packet classifiers need to be able to classify packets at the various layers and various protocols. For example, it should be possible to build a classifier to work on layer 2 protocols and build another classifier that works on layer 3 protocols such as IPv4 or IPv6. Classifiers must also be able to utilize various attributes that are utilized in these layers and protocols. Lior Expires December 29, 2007 [Page 3] Internet-Draft Diameter Classifier June 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Lior Expires December 29, 2007 [Page 4] Internet-Draft Diameter Classifier June 2007 3. Classifier Attribute Overview Classifiers are used in many applications to specify how to classify packets. For example in a QoS application, if a packet matches a classifier then that packet will be treated in accordance with a QoS specification associated with that classifier. The Classifiers are sent to on on-path element (e.g. a router) which uses the classifier to match packets. Figure 1 shows a typical deployment. +-----------+ +-----------+| +--------+ +-------------+ +------------+|| | | IN | | | ||| | +--------->| +------------->| ||| |Managed | | Classifier | | Unmanaged ||| |Terminal| OUT | Entity | | Terminal ||| | |<---------+ |<-------------+ ||+ | | | | | |+ +--------+ +-------------+ +------------+ ^ | Classifiers | +------+-------+ | | | AAA | | | +--------------+ Figure 1: Example of a Classifier Architecture The managed terminal, the terminal for which the classifiers are being specified is located on the left of the Classifier Entity. The unmanaged terminal, the terminal that receives packets from the Managed terminal or sends packets to the managed terminal is located to the right side of the Classifier Entity. The Classifier Entity is responsible for classifying packets that are incoming (IN) from the Managed Terminal or packets outgoing (OUT) to the Managed Terminal. A Classifier consists of a group of attributes that specify how to match a packet. Each attributes expresses values about aspects of the packet - typically the packet header. Different protocols therefore would use different attributes. In general a Classifier consists of the following: Lior Expires December 29, 2007 [Page 5] Internet-Draft Diameter Classifier June 2007 Identifier: The identifier uniquely identifies this classifier and maybe used to reference the classifier from another structure. From: Specifies the rule for matching the source part of the packet. To: Specifies the rule for matching the destination part of the packet. Protocol Specifies the matching protocol of the packet. Direction: Specifies whether the classifier is to apply to packets flowing from the Managed Terminal (IN) or to packets flowing to the Managed Terminal (OUT), or packets flowing in both direction. Options: Associated with each protocol or layer, or various values specific to the header of the protocol or layer. Options allow matching on those values. Each protocol type will have a specific set of attributes that can be used to specify a classifier for that protocol. These attributes will be grouped under a grouped AVP called a Classifier AVP. Lior Expires December 29, 2007 [Page 6] Internet-Draft Diameter Classifier June 2007 4. Classifier AVP The Classifier AVP is a grouped AVP that consists of the following: ClassifierID AVP: The ClassifierID AVP is of type OctetString that uniquely identifies the classifier. Each Classifier MUST have a single instance of the attribute. Each application will define whether this identifier is unique per terminal or globally unique. Exactly one ClassierID AVP MUST be contained within a Classifier AVP. Protocol AVP The Protocol AVP is of type enumeration that specifies the protocol being matched. The attributes included in the Classifier AVP must be consistent with this value of the Protocol AVP. Exactly one of Protocol AVP MUST be contained within a Classifier AVP. Direction AVP: The Direction AVP is of type enumeration that specifies in which direction to apply the Classifier. The values of the enumeration are: "IN","OUT","INOUT". In the "IN" and "INOUT" directions, the From-Spec refers to the address of the Managed Terminal and the To-Spec refers to the unmanaged terminal. In the "OUT" direction, the From-Spec refers to the Unmanaged Terminal whereas the To-Spec refers to the Managed Terminal. From-Spec AVP: This grouped AVP specifies the Source Specification used to match the packet. Zero or more of these attributes may appear in the classifier. If the attribute is absent from the classifier then the source address is not being matched (wild card). If more then one attribute of this type appears in the Classifier then the attributes are used in the order specified. The contents of this AVP are protocol specific. To-Spec: This grouped AVP specifies the Destination Specification used to match the packet. Zero or more of these attributes may appear in the classifier. If the attribute is absent from the classifier then the destination address is not being matched (wild card). If more then one attribute of this type appears in the Classifier Lior Expires December 29, 2007 [Page 7] Internet-Draft Diameter Classifier June 2007 then the attributes are used in the order specified. The contents of this AVP are protocol specific. Lior Expires December 29, 2007 [Page 8] Internet-Draft Diameter Classifier June 2007 5. IP Classifiers The following specifies the attribute types that can be used to build classifiers for IP based protocols. 5.1. Source and Destination Attributes For IP classification the contents of the From-Spec and To-Spec can contain the following attributes. Combining several of this attributes within a From-Spec and To-Spec and using more then one From-Spec and To-Spec AVP one can express many different types IP address pools. 5.1.1. Inverted AVP This attribute is of Enumerated [2] containing the values of True or False. Exactly zero or one of these attributes may appear in a From- Spec of a To-Spec. When set to True the meaning of the match in the To-Spec and From-Spec are inverted, causing all other addresses to be matched instead. When set to False, or when the attribute is not included in the From- Spec and To-Spec then the meaning of the match is not inverted, causing only the addresses specified to be matched. This is equivalent to the '!' character of the IPFilterRule. Note that inversion does not impact the ports matchers. 5.1.2. IPAddress AVP The IPAddress AVP is of type Address [2] and specifies an exactly IP address (IPv4 or IPv6) address to match. Zero or more of these attributes may appear in the From-Spec and the To-Spec grouped AVP. 5.1.3. Port AVP The Port AVP is of type Integer32 and has a maximum value of 65535 and specifies the port to match. Note the port attribute is not impacted by the Invertion AVP. 5.1.4. IPAddressRange AVP The IPAddressRange is a grouped AVP containing an IPAddressStart and IPAddressStop AVP of type Address that specifies an inclusive IP address range. Lior Expires December 29, 2007 [Page 9] Internet-Draft Diameter Classifier June 2007 If the IPAddressStart is not included then the address range starts from the first valid IP address to and including the specified IPAddressStop address. If the IPAddressStop is not included then the address range starts at the address specified by the IPAddressStart AVP and includes all the remaining valid IP addresses. 5.1.5. IPAddressMask AVP The IPAddressMask AVP is a grouped AVP expressing an IP address range using a base IP address and a bit-mask as in: 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit-mask width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the bit-mask. 5.1.6. PortRange AVP The PortRange is a grouped AVP containing a PortStart and PortEnd AVPs of type Integer32 which specify an inclusive range of ports. If the PortStart range is omitted then port 0 is assumed. If PortEnd is omitted then port 65535 is assumed. Port Range is not impacted by the Inversion AVP. 5.1.7. Assigned AVP Often, the AAA does not know the IP address assigned to the Managed Terminal. The Assigned AVP is of type Enumeration and consist of the value "Assigned". When present, it represents the IP address assigned to the Managed Terminal. 5.2. IP Options The Classifier Grouped AVP may contain one or of the following AVP used to match on the various possible IP options. 5.2.1. FragFlag AVP Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. 5.2.2. IPOptions AVP Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source Lior Expires December 29, 2007 [Page 10] Internet-Draft Diameter Classifier June 2007 route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'. 5.2.3. TCPOptions AVP Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. 5.2.4. Established AVP TCP packets only. Match packets that have the RST or ACK bits set. 5.2.5. Setup AVP TCP packets only. Match packets that have the SYN bit set but no ACK bit. 5.2.6. TCPFlags AVP TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. 5.2.7. ICMPTypes ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). Lior Expires December 29, 2007 [Page 11] Internet-Draft Diameter Classifier June 2007 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Lior Expires December 29, 2007 [Page 12] Internet-Draft Diameter Classifier June 2007 Author's Address Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario Canada K2K 3J1 Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Lior Expires December 29, 2007 [Page 13] Internet-Draft Diameter Classifier June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lior Expires December 29, 2007 [Page 14] --------------040108000007020302040504 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --------------040108000007020302040504-- From dime-bounces@ietf.org Wed Jul 04 16:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6BfF-0001eN-6B; Wed, 04 Jul 2007 16:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6BfE-0001aa-Fd for dime@ietf.org; Wed, 04 Jul 2007 16:41:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6BfA-0008Ei-5F for dime@ietf.org; Wed, 04 Jul 2007 16:41:28 -0400 Received: (qmail invoked by alias); 04 Jul 2007 20:41:23 -0000 Received: from p549877AB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.119.171] by mail.gmx.net (mp019) with SMTP; 04 Jul 2007 22:41:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JkAIGrtAJxDdGAgZuYxXy3of0oCs8HufMmnXBml tTKetFLIVuCyiW Message-ID: <468C05F2.2060008@gmx.net> Date: Wed, 04 Jul 2007 22:41:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: keyprov@ietf.org, ECRIT , dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Dime] Submission cut-off date before Chicago X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Please note the submission dates for Internet-Drafts before Chicago. July 9, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 04 20:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6EuM-0002w1-Er; Wed, 04 Jul 2007 20:09:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6EuL-0002qY-FB for dime@ietf.org; Wed, 04 Jul 2007 20:09:17 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6EuD-0007g4-Hv for dime@ietf.org; Wed, 04 Jul 2007 20:09:17 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l650835P022031; Wed, 4 Jul 2007 20:08:03 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468C3663.5060509@tari.toshiba.com> Date: Wed, 04 Jul 2007 20:08:03 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Thomas Lindgren Subject: Re: [Dime] Question Regarding Failed AVP. References: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Thomas, > > Right, though in that case 7.1.5/5007 also needs to be updated since > it explicitly permits more than one Failed-AVP. I'm not sure which is > the best choice -- it's tempting to make things more elegant, but > there's something to be said for nailing down the status quo too. > Either way, some clarification seems useful. I agree. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 04 20:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FDJ-00009U-6u; Wed, 04 Jul 2007 20:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FDI-00009P-KT for dime@ietf.org; Wed, 04 Jul 2007 20:28:52 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FDF-0002Zf-2o for dime@ietf.org; Wed, 04 Jul 2007 20:28:52 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l650RsUI022074; Wed, 4 Jul 2007 20:27:54 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468C3B0A.6020208@tari.toshiba.com> Date: Wed, 04 Jul 2007 20:27:54 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: harish raghuveer Subject: Re: [Dime] Question Regarding Failed AVP. References: <008e01c7be1d$2be845c0$3a17120a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Harish, Sounds ok to me. BTW, this should also cover STA, ASA, RAA. regards, victor > Hi all, > > I also had the thought that a single Failed-AVP corresponds to a > single result code. If the parser implementation can report multiple > errors (consider a case where a request message with multiple > unsupported AVPs and a few enum type AVPs with invalid values), it > definitely makes sense to have multiple Failed-AVPs, each > corresponding to a specific type of error. But that would need the > inclusion of "*1 {Result-Code}" in Failed-AVPs ABNF. IMHO, the new > ABNF definition would also be backward compatible because there is no > requirement on min. number of occurrences of Result-Code AVP. The > receiver of the response with Failed-AVP can either use the common > Result-code in the message or Failed-AVP specific result code to > isolate the cause of error (for debugging purposes). > > My $0.02. > > thanks, > Harish > > On 7/4/07, *Thomas Lindgren* > wrote: > > > > On 7/4/07, * Rajith R* > wrote: > > In this case, you may include those AVPs as the "sub" AVPs of > Failed-AVP. Failed-AVP AVP is a "grouped" AVP. > As I have mentioned earlier, Failed-AVP AVP corresponds to > Result Code, and as long as you have just one result code, it > makes sense to have just one Failed-AVP AVP. This AVP itself > might include one or more sub AVPs. > > > Right, though in that case 7.1.5/5007 also needs to be updated > since it explicitly permits more than one Failed-AVP. I'm not sure > which is the best choice -- it's tempting to make things more > elegant, but there's something to be said for nailing down the > status quo too. Either way, some clarification seems useful. > > Best, > Thomas > > > ------------------------------------------------------------------------ > *From:* Thomas Lindgren [mailto: [send email to > u.thomas.lindgren@gmail.com via gmail] > u.thomas.lindgren@gmail.com > ] > *Sent:* Wednesday, July 04, 2007 2:51 PM > *To:* [send email to dime@ietf.org via gmail] > dime@ietf.org > *Subject:* Re: [Dime] Question Regarding Failed AVP. > > > > On 7/3/07, *Victor Fajardo* < [send email to > vfajardo@tari.toshiba.com via gmail] > vfajardo@tari.toshiba.com > > wrote: > > Hi, > > > In the */section 7.5/* of > /draft-ietf-dime-rfc3588bis-04.txt/ it > > states that > > " A Diameter message SHOULD contain only one > Failed-AVP that > > corresponds to the error indicated by the > Result-Code AVP." > > > > The document also states in the same section that > > "For practical purposes, this Failed-AVP would > typically refer to > > the first AVP processing error that a Diameter > node encounters." > > > > my question is that if the message is supposed to > contain only one > > failed AVP then why does the ABNF of messages > CEA,DPA and DWA have > > *[ Failed-AVP ]. > > > > Rajith >> I think it should be [Failed-AVP] > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" > instead of a "MUST" > was based on backward compatibility concerns. I'm not > sure if this is > still a valid concern or not so it maybe best to hear > from others as well. > > > Could an error like DIAMETER_CONTRADICTING_AVPS (7.1.5, no > 5007) occur? That one allows returning two or more > Failed-AVPs if necessary. It's not mentioned in 7.5 though. > > Best, > Thomas > -- > Thomas Lindgren, Millpond Services Ltd > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > > -- > Harish R Prabhu > Bangalore, India. > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 04 20:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FIr-0003gw-Hm; Wed, 04 Jul 2007 20:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FIq-0003gk-Rh for dime@ietf.org; Wed, 04 Jul 2007 20:34:36 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FIl-0004J5-PH for dime@ietf.org; Wed, 04 Jul 2007 20:34:36 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l650Xb31022108; Wed, 4 Jul 2007 20:33:38 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468C3C61.6070908@tari.toshiba.com> Date: Wed, 04 Jul 2007 20:33:37 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: naveen sarma Subject: Re: [Dime] Re: DiME Digest, Vol 19, Issue 1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Pls. see the current thread on this issue. A rough consensus is to update the ABNF to [Failed-AVP]. regards, victor > Hi Victor, > > I have a question, for backward compatilibity means, is it related to > the dictionary configuration of the base protocol? It seems to be > more logical to have [Failed-AVP] instead of *[Failed-AVP], which i > have already mentioned in the Jun27 mail with subject *"**Reg the > Failed-AVP in CEA, DWA and DPA".* > ** > Regards, > Naveen > > Date: Tue, 03 Jul 2007 08:22:20 -0400 > From: Victor Fajardo < vfajardo@tari.toshiba.com > > > Subject: Re: [Dime] Question Regarding Failed AVP. > To: rajithr@huawei.com > Cc: dime@ietf.org , 'Amit Kumar PNGN' < > amit8.kumar@aricent.com >, > 'Preeti Shandilya' > > Message-ID: < 468A3F7C.5090509@tari.toshiba.com > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > > In the */section 7.5/* of /draft-ietf-dime-rfc3588bis-04.txt/ it > > states that > > " A Diameter message SHOULD contain only one Failed-AVP that > > corresponds to the error indicated by the Result-Code AVP." > > > > The document also states in the same section that > > "For practical purposes, this Failed-AVP would typically > refer to > > the first AVP processing error that a Diameter node encounters." > > > > my question is that if the message is supposed to contain > only one > > failed AVP then why does the ABNF of messages CEA,DPA and > DWA have > > *[ Failed-AVP ]. > > > > Rajith >> I think it should be [Failed-AVP] > > > > Keeping the *[Failed-AVP] ABNF and using a "SHOULD" instead of a > "MUST" > was based on backward compatibility concerns. I'm not sure if this is > still a valid concern or not so it maybe best to hear from others > as well. > > -- victor > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > End of DiME Digest, Vol 19, Issue 1 > *********************************** > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 04 20:48:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FVz-00040k-3M; Wed, 04 Jul 2007 20:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FVx-00040V-Nt for dime@ietf.org; Wed, 04 Jul 2007 20:48:09 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FVu-0007jx-Df for dime@ietf.org; Wed, 04 Jul 2007 20:48:09 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l650lCU0022152; Wed, 4 Jul 2007 20:47:13 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468C3F90.2090002@tari.toshiba.com> Date: Wed, 04 Jul 2007 20:47:12 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: harish raghuveer Subject: Re: [Dime] accounting-sub-session-id avp code References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thanks for catching this. 3588 seems consistent with the value of 287 so I'm suspecting the problem is in the IANA registry. We can do some background checks and see. I put this issue under #58 of http://www.tschofenig.priv.at:8080/diameter-interop. regards, victor > Hi, > > I see that in the sections 4.5 and 9.8.6 of RFC 3588 and the > draft-ietf-dime-rfc3588bis-04.txt the code for Acct-Sub-Session-Id AVP > is given as 287 where as IANA registry ( > http://www.iana.org/assignments/aaa-parameters) shows the code for the > AVP as 487. Which one is correct? > > thanks, > Harish R Prabhu > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 05 00:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6J6S-0002mu-Ge; Thu, 05 Jul 2007 00:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6J6R-0002mp-1K for dime@ietf.org; Thu, 05 Jul 2007 00:38:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6J6M-0006pr-Mg for dime@ietf.org; Thu, 05 Jul 2007 00:38:02 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1036326uge for ; Wed, 04 Jul 2007 21:37:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=dy8Oey7ciFJo12ylOE6qKTLvTI9Jyg8QDP5MSWICEx/RVWIhAKnzVfuWCCp9wfbtrMx1OHFN+drXOWYv3+L6Ml1T00IabD3Wu2tmM8lJUJ2Pxc7i4jX4GjHRqNSRhousWqYlWgY5Y0yIvXfqDwiZvPhcQywdYnedYhMFWNDEoZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=k3Z1XJ6yw/GsGbJyUDyab19l3/FZQ5B6eV85UVlThiZ7Bas+VdBG6QhP/s1I4Wk7607KlLWSCumAvTfReEBetPD4O/3jtflI0HYiocJtHiN5PyddqZJeZPU76VBPcGa2+RdrkM6igIm+rvUq7miCHyp+kK+wUI/gOsuIqtJwu3g= Received: by 10.82.186.5 with SMTP id j5mr19284519buf.1183610277634; Wed, 04 Jul 2007 21:37:57 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Wed, 4 Jul 2007 21:37:57 -0700 (PDT) Message-ID: Date: Thu, 5 Jul 2007 10:07:57 +0530 From: "harish raghuveer" To: dime@ietf.org Subject: Re: [Dime] Diameter Classifier Document In-Reply-To: <468BFD22.1020501@gmx.net> MIME-Version: 1.0 References: <468BFD22.1020501@gmx.net> X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0694444827==" Errors-To: dime-bounces@ietf.org --===============0694444827== Content-Type: multipart/alternative; boundary="----=_Part_123166_9500495.1183610277616" ------=_Part_123166_9500495.1183610277616 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Currently the document does not describe any AVP to support DSCP/TOS field based classification (Or did I miss it in the document? :-)). IMHO, it will be good to add support for this too. thanks and regards, Harish ------=_Part_123166_9500495.1183610277616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Currently the document does not describe any AVP to support DSCP/TOS field based classification (Or did I miss it in the document? :-)). IMHO, it will be good to add support for this too.

thanks and regards,
Harish


------=_Part_123166_9500495.1183610277616-- --===============0694444827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0694444827==-- From dime-bounces@ietf.org Thu Jul 05 04:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6MLN-0000xa-3V; Thu, 05 Jul 2007 04:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6MLM-0000uN-5R for dime@ietf.org; Thu, 05 Jul 2007 04:05:40 -0400 Received: from web55302.mail.re4.yahoo.com ([206.190.58.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6MLA-00022n-30 for dime@ietf.org; Thu, 05 Jul 2007 04:05:40 -0400 Received: (qmail 23375 invoked by uid 60001); 5 Jul 2007 08:05:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=vNdNqyHiBUQq/G3GQrSOYYWTgR3LEY/NpVgRDnXpI+xg8hBon++iNne0yfkllDxeESpMGq2LkbAsFNfaioPYVdEotIw6AME2bzOaCPbwnCQztjX+N134yY6HYMfCOe+kBbVrbmSAjzH0uwyN3OnNUmLcslGN5eyK55J7qRAHf90=; X-YMail-OSG: Lmx0.QkVM1l3H7_FQtVbRSTZeW6lduAFMjXi0tVGjH9ZKTN_lDRTrtMIccR5Zlanfs2PQjDDwqvpvqD1G.OypJVWxo6OO3_q2dvv9EUvisGkCcqXLXK7I6FUTPHfz0q8Ne8nKagZXfrdQI1sCZ8wrdUh Received: from [203.197.120.150] by web55302.mail.re4.yahoo.com via HTTP; Thu, 05 Jul 2007 01:05:27 PDT Date: Thu, 5 Jul 2007 01:05:27 -0700 (PDT) From: Arijeet Pal To: dime@ietf.org MIME-Version: 1.0 Message-ID: <944075.22987.qm@web55302.mail.re4.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] Requirement of transaction maintenance in DIAMETER X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760675599==" Errors-To: dime-bounces@ietf.org --===============0760675599== Content-Type: multipart/alternative; boundary="0-1465538755-1183622727=:22987" Content-Transfer-Encoding: 8bit --0-1465538755-1183622727=:22987 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Everyone, I am new to this group and have just started upon the study of the DIAMETER base protocol. I have a very basic question: Why is the conception of a transaction (and maintaining transaction states) required in DIAMETER agents when this protocol uses only reliable transmission options (e.g. SCTP and/or TCP) for exchanges messages between peers? Thanks and Regards, Arijeet --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. --0-1465538755-1183622727=:22987 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Everyone,
 
I am new to this group and have just started upon the study of the DIAMETER base protocol.
 
I have a very basic question:
 
Why is the conception of a transaction (and maintaining transaction states) required in DIAMETER agents when this protocol uses only reliable transmission options (e.g. SCTP and/or TCP) for exchanges messages between peers?
 
Thanks and Regards,
Arijeet

Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search. --0-1465538755-1183622727=:22987-- --===============0760675599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0760675599==-- From dime-bounces@ietf.org Thu Jul 05 05:13:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6NPD-00038w-EY; Thu, 05 Jul 2007 05:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6NPB-00038f-GU; Thu, 05 Jul 2007 05:13:41 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6NP7-0006ry-0V; Thu, 05 Jul 2007 05:13:41 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:13:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7BEE4.C2623B87" Date: Thu, 5 Jul 2007 11:13:32 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F2713D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Thread-Index: Ace5wQxYHK4bJeb1RMaJz2oMBfP+KgEUDxEg From: To: , X-OriginalArrivalTime: 05 Jul 2007 09:13:33.0477 (UTC) FILETIME=[C2E22550:01C7BEE4] X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BEE4.C2623B87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility=20 > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > =09 > This specification defines the Diameter support for the=20 > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the=20 > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt >=20 ------_=_NextPart_001_01C7BEE4.C2623B87 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-dime-pmip6-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-dime-pmip6-00.txt Content-Disposition: attachment; filename="draft-korhonen-dime-pmip6-00.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfa29yaG9uZW5fZGltZV9wbWlwNl8wMC5VUkwiDQpG aWx0ZXIgbmFtZTogIkZJTEUgRklMVEVSPSB1bm5hbWVkOiAqLnVybCINCg== ------_=_NextPart_001_01C7BEE4.C2623B87 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7BEE4.C2623B87-- From dime-bounces@ietf.org Thu Jul 05 08:11:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QAo-0000JF-TS; Thu, 05 Jul 2007 08:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QAl-0000Id-Dx for dime@ietf.org; Thu, 05 Jul 2007 08:10:59 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Q9l-0006sy-L0 for dime@ietf.org; Thu, 05 Jul 2007 08:10:59 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l65C9uWa010215; Thu, 5 Jul 2007 08:09:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Requirement of transaction maintenance in DIAMETER Date: Thu, 5 Jul 2007 08:09:56 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718801E@sonusmail04.sonusnet.com> In-Reply-To: <944075.22987.qm@web55302.mail.re4.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Requirement of transaction maintenance in DIAMETER Thread-Index: Ace+201lr6sGCr+9TriJmFiZK+JbhQAIaejA References: <944075.22987.qm@web55302.mail.re4.yahoo.com> From: "Asveren, Tolga" To: "Arijeet Pal" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Arijeet, SCTP/TCP provides reliable transport between two nodes as long as the = nodes are up and running, but when a node fails, messages which are sent = via this node and for which no reply has been received yet need to be = retransmitted by Diameter base protocol to an alternate next-hop. Thanks, Tolga ________________________________________ From: Arijeet Pal [mailto:arijeetpal@yahoo.com]=20 Sent: Thursday, July 05, 2007 4:05 AM To: dime@ietf.org Subject: [Dime] Requirement of transaction maintenance in DIAMETER=20 Hello Everyone, =A0 I am new to this group and have just started upon the study of the = DIAMETER base protocol.=20 =A0 I have a very basic question: =A0 Why is the conception of a transaction (and maintaining transaction = states) required in DIAMETER agents when this protocol uses only = reliable transmission options (e.g. SCTP and/or TCP) for exchanges = messages between peers? =A0 Thanks and Regards, Arijeet =20 ________________________________________ Luggage? GPS? Comic books?=20 Check out fitting gifts for grads at Yahoo! Search. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 05 08:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QDN-0002Kf-U9; Thu, 05 Jul 2007 08:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QDN-0002IZ-1f for dime@ietf.org; Thu, 05 Jul 2007 08:13:41 -0400 Received: from web55307.mail.re4.yahoo.com ([206.190.58.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6QCr-0007OJ-UX for dime@ietf.org; Thu, 05 Jul 2007 08:13:41 -0400 Received: (qmail 13046 invoked by uid 60001); 5 Jul 2007 12:13:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PXouFmndUpjRNrjha92ShgCjK2bsS+CY2HHJV04lNivNjgJzqA4pLc3VrOUAxWK1oN1U0Z0S4eym36ukp66s3cxI9t+0mNJZYcqM1PdovmxQ0kTeXml0odCVO+nGyJlx9NINDDBbwxZ1P5bVJcO5BZydrxjoJp7lWLgLYeOy9tg=; X-YMail-OSG: Q8cOTHAVM1mb1foIGm9LLOG1LV3IqPhhD5yIthpEwKGLAg3Y96J1WOZT9Jh3nZRmJOXidFz4pKtYNpCi0C_9GC9HkACRvmav9RgLC3zX2x5qXKnjE6Sul4m9Zu_Bfg-- Received: from [203.200.173.42] by web55307.mail.re4.yahoo.com via HTTP; Thu, 05 Jul 2007 05:13:09 PDT Date: Thu, 5 Jul 2007 05:13:09 -0700 (PDT) From: Arijeet Pal Subject: RE: [Dime] Requirement of transaction maintenance in DIAMETER To: "Asveren, Tolga" , dime@ietf.org In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718801E@sonusmail04.sonusnet.com> MIME-Version: 1.0 Message-ID: <765868.12988.qm@web55307.mail.re4.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678960484==" Errors-To: dime-bounces@ietf.org --===============0678960484== Content-Type: multipart/alternative; boundary="0-1917327680-1183637589=:12988" Content-Transfer-Encoding: 8bit --0-1917327680-1183637589=:12988 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Understood - thanks a lot Tolga. Regards, Arijeet "Asveren, Tolga" wrote: Arijeet, SCTP/TCP provides reliable transport between two nodes as long as the nodes are up and running, but when a node fails, messages which are sent via this node and for which no reply has been received yet need to be retransmitted by Diameter base protocol to an alternate next-hop. Thanks, Tolga ________________________________________ From: Arijeet Pal [mailto:arijeetpal@yahoo.com] Sent: Thursday, July 05, 2007 4:05 AM To: dime@ietf.org Subject: [Dime] Requirement of transaction maintenance in DIAMETER Hello Everyone, I am new to this group and have just started upon the study of the DIAMETER base protocol. I have a very basic question: Why is the conception of a transaction (and maintaining transaction states) required in DIAMETER agents when this protocol uses only reliable transmission options (e.g. SCTP and/or TCP) for exchanges messages between peers? Thanks and Regards, Arijeet ________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-1917327680-1183637589=:12988 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Understood - thanks a lot Tolga.
 
Regards,
Arijeet

"Asveren, Tolga" <tasveren@sonusnet.com> wrote:
Arijeet,

SCTP/TCP provides reliable transport between two nodes as long as the nodes are up and running, but when a node fails, messages which are sent via this node and for which no reply has been received yet need to be retransmitted by Diameter base protocol to an alternate next-hop.

Thanks,
Tolga

________________________________________
From: Arijeet Pal [mailto:arijeetpal@yahoo.com]
Sent: Thursday, July 05, 2007 4:05 AM
To: dime@ietf.org
Subject: [Dime] Requirement of transaction maintenance in DIAMETER

Hello Everyone,
 
I am new to this group and have just started upon the study of the DIAMETER base protocol.
 
I have a very basic question:
 
Why is the conception of a transaction (and maintaining transaction states) required in DIAMETER agents when this protocol uses only reliable transmission options (e.g. SCTP and/or TCP) for exchanges messages between peers?
 
Thanks and Regards,
Arijeet

________________________________________
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.

Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-1917327680-1183637589=:12988-- --===============0678960484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0678960484==-- From dime-bounces@ietf.org Thu Jul 05 08:57:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QtU-0002Np-OV; Thu, 05 Jul 2007 08:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QtT-0002Ni-KX for dime@ietf.org; Thu, 05 Jul 2007 08:57:11 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Qt8-0006kc-Eb for dime@ietf.org; Thu, 05 Jul 2007 08:57:11 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l65CumBf020993; Thu, 5 Jul 2007 08:56:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Classifier Document Date: Thu, 5 Jul 2007 08:56:48 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188021@sonusmail04.sonusnet.com> In-Reply-To: <468BFD22.1020501@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Classifier Document Thread-Index: Ace+dnZIipldpkx9RzGTPMBzwz348wAh4o/Q References: <468BFD22.1020501@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org It makes sense to use grouped AVPs rather than some text encoding (actually in general not just for this case). Would that require using a new "version" of Diameter, i.e. incrementing version value in the header? Or should there be a new grouped AVP used during capability exchange to advertise supported "extensions" (where each extension is indicated as a sub-AVP) A dirty workaround could be to use (or better said to abuse) Supported-Vendor-Id AVP and define a pseudo vendor for each new extension.=20 A fourth alternative is probably not to signal anything during capability exchange, and let a node which uses the "old" encoding to (hopefully) fail during the parsing. If the sender is able to switch to the old encoding, it can retry the request to the same server or can try an alternate server. Any ideas? Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, July 04, 2007 4:04 PM > To: dime@ietf.org > Subject: [Dime] Diameter Classifier Document >=20 > Hi all, >=20 > Avi has written a document that defines classifiers with a binary > encoding instead of a textual encoding currently being investigated in > the RADEXT working group with > http://tools.ietf.org/wg/radext/draft-ietf-radext-filter-rules/. > One of the benefits is better extensibility. >=20 > You can find the document in the attachment. >=20 > It would be great to hear your thoughts about this issue. Btw, there is > impact on the QoS attribute document. >=20 > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 05 11:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TiH-0002RJ-T7; Thu, 05 Jul 2007 11:57:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TiF-00021d-NQ for dime@ietf.org; Thu, 05 Jul 2007 11:57:47 -0400 Received: from web84109.mail.mud.yahoo.com ([68.142.206.196]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6ThJ-0008H0-H1 for dime@ietf.org; Thu, 05 Jul 2007 11:57:47 -0400 Received: (qmail 23003 invoked by uid 60001); 5 Jul 2007 15:56:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ZMhzPD/5xeIAZik5oItkL+FjSKPMeWHxOqdBNRsQUVdX/d1pLvjC0BKLeoTDdRzOip87EBR3qlqcOVSwNe52kCNQQ52a71M23S7A5/Elw8TKveDTkXp5rvE5eMLyoyZEoYdo1Uw+Dh6JArfZaTBo+hT6QYzv8+VDTNv0jXoI/Uc=; X-YMail-OSG: wLYy6J8VM1nrTSpS113KiLtG_0QWCWdcugA8A_WCpjnngZh.JMhBhOWW0FgX4ZS3JD_WpLje6TYIfEredGkttuKhGUQ9386SXiCAChyMa3Vf5WJQs_E- Received: from [206.16.17.212] by web84109.mail.mud.yahoo.com via HTTP; Thu, 05 Jul 2007 08:56:49 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Thu, 5 Jul 2007 08:56:49 -0700 (PDT) From: Behcet Sarikaya To: jouni.korhonen@teliasonera.com MIME-Version: 1.0 Message-ID: <81185.22587.qm@web84109.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org, netlmm@ietf.org Subject: [Dime] Re: [netlmm] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0765763369==" Errors-To: dime-bounces@ietf.org --===============0765763369== Content-Type: multipart/alternative; boundary="0-783611730-1183651009=:22587" --0-783611730-1183651009=:22587 Content-Type: text/plain; charset=ascii Hi all, We have a draft on AAA Interface for PMIPv6 currently using Radius. This draft is at: http://tools.ietf.org/wg/netlmm/draft-xia-netlmm-radius-00.txt Comments are welcome. Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: netlmm@ietf.org; dime@ietf.org Sent: Thursday, July 5, 2007 4:13:32 AM Subject: [netlmm] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > > This specification defines the Diameter support for the > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt > --0-783611730-1183651009=:22587 Content-Type: text/html; charset=ascii
Hi all,
  We have a draft on AAA Interface for PMIPv6 currently using Radius. This draft is at:
http://tools.ietf.org/wg/netlmm/draft-xia-netlmm-radius-00.txt

  Comments are welcome.

Behcet

----- Original Message ----
From: "jouni.korhonen@teliasonera.com" <jouni.korhonen@teliasonera.com>
To: netlmm@ietf.org; dime@ietf.org
Sent: Thursday, July 5, 2007 4:13:32 AM
Subject: [netlmm] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt


FYI.. this Dime I-D might be of interest for PMIPv6 folks. The
I-D describes MAG-AAA and LMA-AAA Diameter interactions for
PMIPv6. Comments are welcome as a lot more work is still ahead.

Cheers,
    Jouni


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, June 28, 2007 10:50 PM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>     Title        : Diameter Proxy Mobile IPv6: Support For
>                           Mobility Access Gateway and Local Mobility
>                           Anchor to Diameter Server Interaction
>     Author(s)    : J. Korhonen, et al.
>     Filename    : draft-korhonen-dime-pmip6-00.txt
>     Pages        : 20
>     Date        : 2007-6-28
>     
>    This specification defines the Diameter support for the
> Proxy Mobile
>    IPv6.  The policy information needed by the Proxy Mobile IPv6 is
>    defined in mobile node's policy profile, which gets downloaded from
>    the Diameter server to the Mobile Access Gateway once the
> mobile node
>    roams into a Proxy Mobile IPv6 Domain and performs the access
>    authentication.  The access authentication procedure into the Proxy
>    Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario
>    bootstrapping.  Rather than defining a completely new set of
>    attributes or a new Diameter application this specification only
>    leverages the work already done for the Mobile IPv6 bootstrapping.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt
>

--0-783611730-1183651009=:22587-- --===============0765763369== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0765763369==-- From dime-bounces@ietf.org Thu Jul 05 12:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tsr-0002Wo-O6; Thu, 05 Jul 2007 12:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tsq-0002Sk-NH for dime@ietf.org; Thu, 05 Jul 2007 12:08:44 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Ts0-0002s2-TU for dime@ietf.org; Thu, 05 Jul 2007 12:08:44 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l65G7qF4005062 for ; Thu, 5 Jul 2007 12:07:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2007 12:07:52 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188023@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN relay with push mode QoS reservation Thread-Index: Ace/HpAVyVvc4Z1+TC6F+yEanr2xNg== From: "Asveren, Tolga" To: X-Spam-Score: 2.0 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Dime] STUN relay with push mode QoS reservation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Let me ping about this first in the friendly neighborhood WG (actually I guess this topic may be more relevant to SIPPING and/or BEHAVE WGs): Consider the following configuration (QoS reservation for access network with push model): +----+ +-----+ +------+ | | | | | | | UA +------+ NAT +---------------------+ AF | | |xxxxxx| | | | +----+ +-----+ +---"--+ x(IP1) " x +--------+ " +----+ x | STUN | " | | x | Relay |xxxxxxxxxxxxxxxxx| UA | x | |(IP3) " (IP4)| | x +--------+ " +----+ x x(IP2) " +-----+ x +---"--+ | |xxxxxxxx | | | PEF | | PDF | | """"""""""""""""""""""" | +-----+ +------+ --- Call Signaling (SIP) """ QoS Signaling (Diameter QoS application) xxx Media =20 UA would use IP3 as its media address in the SDP, so AF would know only IP3 and IP4 from the far end UA. What PEF needs is IP2 and IP1. One solution is probably PEF consulting STUN Relay to learn the actual IP addresses (STUN Relay has the binding between IP1-IP2/IP3-IP4).=20 Another approach could be to signal IP1/IP2 in some newly defined SDP fields. Any ideas?=20 Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 05 21:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cPG-0008Eq-6B; Thu, 05 Jul 2007 21:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cPF-0008Ei-L9 for dime@ietf.org; Thu, 05 Jul 2007 21:14:45 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6cPB-00019P-BM for dime@ietf.org; Thu, 05 Jul 2007 21:14:45 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l661Eauj011914; Thu, 5 Jul 2007 21:14:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Failover problems with Relays and crashed applications Date: Thu, 5 Jul 2007 21:14:36 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188029@sonusmail04.sonusnet.com> In-Reply-To: <007d01c7be19$82df4a80$3a17120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Failover problems with Relays and crashed applications Thread-Index: Ace+DuEtXu9nFEfiRj+OY9r2NzhksgACTOTgAFRsEzA= References: <468B4F4F.6040008@telenet-ag.de> <007d01c7be19$82df4a80$3a17120a@china.huawei.com> From: "Asveren, Tolga" To: , "Michael Hillier" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree that this would be faulty behavior. OTOH, it is always a good = idea to be protected against misbehaving nodes. By applying a local = check, where neighbors, from which no Diameter application level reply = has been received for a while, are no more used to send messages to = could be a good idea (or disconnecting connection to such nodes). Thanks, Tolga ________________________________________ From: Rajith R [mailto:rajithr@huawei.com]=20 Sent: Wednesday, July 04, 2007 4:59 AM To: 'Michael Hillier'; dime@ietf.org Subject: RE: [Dime] Failover problems with Relays and crashed = applications IMO, there seems to be an implementation issue in the primary server not = responding to "application" requests (like CCR), but the connection = still ticking with DWR-DWA exchanges. Either DWR should not be replied = or the connection layer should understand that the application layer = crashed (or to that effect) and indicate this to its peers in a CER = update. AFAIK, DMT does not recommend/require a transaction time out based fail = over. =A0 Regards =A0 Rajith ________________________________________ From: Michael Hillier [mailto:m.hillier@telenet-ag.de]=20 Sent: Wednesday, July 04, 2007 1:12 PM To: dime@ietf.org Subject: [Dime] Failover problems with Relays and crashed applications Hi all, another question has come up in practice.=A0 Again we are in the context = of Credit Control Application, but the issue must be applicable to all = such applications which define their own failover mechanisms Given a client (C) communicating via a primary and secondary relay (Rp, = Rs) towards a primary and secondary server (Sp, Ss). All Diameter connections are up and running.=A0 The client selects Rp = and Rp selects Sp, being the primary next hops. Now the primary Server stops answering the application requests (i.e=A0 = no CCAs are=A0 returned) - for what ever reason,=20 however the connection Rp <=3D> Sp is still ticking over, i.e. DWRs are = being answered by Sp. Short timers, like Tx,=A0 may expire in the client, possibly allowing = service to be delivered, but that is a side issue. Now the transaction timer expires causing the client to failover to the = secondary relay (Rs), i.e. re-sending the CCR with T-bit Rs selects the primary Server, because it does not know any reason not = to, and thus the CCR(with T-bit) is sent to the same server which has = failed. Summary:=A0 client failover to secondary next hop works nicely when = directly connected to the Diameter servers, but does not achieve the = desired effect when relays are used, which have no "application timer" = awareness. Can anybody point out where I have gone wrong? Many thanks Mike Michael Hillier Telenet AG Rhein-Main M.Hillier@telenet-ag.de _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 06 02:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hWy-0005Lo-20; Fri, 06 Jul 2007 02:43:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hWx-0005F7-1D for dime@ietf.org; Fri, 06 Jul 2007 02:43:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6hWw-0000WW-KM for dime@ietf.org; Fri, 06 Jul 2007 02:43:02 -0400 Received: (qmail invoked by alias); 06 Jul 2007 06:42:21 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp046) with SMTP; 06 Jul 2007 08:42:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+YfnhoUB6YtuTp+/vJ/k+bK0PnyFRFt8JySxMtDH sew5Fc1DMEMNpf Message-ID: <468DE44C.6030107@gmx.net> Date: Fri, 06 Jul 2007 08:42:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] STUN relay with push mode QoS reservation References: <033458F56EC2A64E8D2D7B759FA3E7E7188023@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188023@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, you need to explain where you want to install what type of QoS reservation. In essence, you might consider two scenarios: * QoS reservation only in the access * QoS reservation along the path of the media traffic (with a couple of routers) In the former case that's the plan of most SDOs. For the later case you seem to be describing the interworking between Diameter QoS, STUN to trigger a proxy RSVP/NSIS scenario. See http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-01.txt For NSIS the functionality is built into the main specification: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-14.txt Ciao Hannes Asveren, Tolga wrote: > Let me ping about this first in the friendly neighborhood WG (actually I > guess this topic may be more relevant to SIPPING and/or BEHAVE WGs): > > Consider the following configuration (QoS reservation for access network > with push model): > > +----+ +-----+ +------+ > | | | | | | > | UA +------+ NAT +---------------------+ AF | > | |xxxxxx| | | | > +----+ +-----+ +---"--+ > x(IP1) " > x +--------+ " +----+ > x | STUN | " | | > x | Relay |xxxxxxxxxxxxxxxxx| UA | > x | |(IP3) " (IP4)| | > x +--------+ " +----+ > x x(IP2) " > +-----+ x +---"--+ > | |xxxxxxxx | | > | PEF | | PDF | > | """"""""""""""""""""""" | > +-----+ +------+ > > > --- Call Signaling (SIP) > > """ QoS Signaling (Diameter QoS application) > > xxx Media > > > UA would use IP3 as its media address in the SDP, so AF would know only > IP3 and IP4 from the far end UA. What PEF needs is IP2 and IP1. > > One solution is probably PEF consulting STUN Relay to learn the actual > IP addresses (STUN Relay has the binding between IP1-IP2/IP3-IP4). > > Another approach could be to signal IP1/IP2 in some newly defined SDP > fields. > > Any ideas? > > Thanks, > Tolga > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 06 02:43:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hXk-0002b1-Ez; Fri, 06 Jul 2007 02:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hXj-0002Ym-Bk for dime@ietf.org; Fri, 06 Jul 2007 02:43:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6hXe-0002GN-Jl for dime@ietf.org; Fri, 06 Jul 2007 02:43:51 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1712538uge for ; Thu, 05 Jul 2007 23:43:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=JSXOM4493h7/zX2Tt/jDrNmBM2ztaaz9Cs/6cB4UBW4EECfXEakjf5EANPPlYeZQAsm7rzVYS38shr7TmQSP5fOD9mdKK+xRuZusPjJAvOMbSEKO3YJS7OE/cD507xvOmGVmyDWX86QHYypx553s86EFaBWdguTqw7y2uk01/Pk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=lRHjRHwxHSEqfLPk04wTqXuNuhoTZ/XlWH8VlUBQxJxF66hu2UcI6jBq9XWNZU8kKO7f+FIGDgSrOnEBM44xm39rTWJmV76gXWIovLMHA6PvUsZzegjTbR7iC6sqRn2IZhqcrKYqktJ49XiLPpxpAI7cFF+pID3m4QlTe9Zak/s= Received: by 10.82.178.11 with SMTP id a11mr1012979buf.1183704225682; Thu, 05 Jul 2007 23:43:45 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Thu, 5 Jul 2007 23:43:45 -0700 (PDT) Message-ID: Date: Fri, 6 Jul 2007 12:13:45 +0530 From: "harish raghuveer" To: dime@ietf.org Subject: Re: [Dime] Failover problems with Relays and crashed applications In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188029@sonusmail04.sonusnet.com> MIME-Version: 1.0 References: <468B4F4F.6040008@telenet-ag.de> <007d01c7be19$82df4a80$3a17120a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E7188029@sonusmail04.sonusnet.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0698510637==" Errors-To: dime-bounces@ietf.org --===============0698510637== Content-Type: multipart/alternative; boundary="----=_Part_135656_88365.1183704225661" ------=_Part_135656_88365.1183704225661 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I feel that this could be achieved by including some re-negotiation facility to the existing capability exchange mechanism of the base protocol. This would need state machine modifications though. But definite advantage I can see in a service provider scenario will be: 1. new applications can be added to a server in a hit-less manner 2. misbehaving applications (detected by some local implementation dependent means) can be removed from the list of locally supported applications and can be re-advertised. this can cause a client to re-trigger to some backup server that can currently serve the application. This should work in either case (direct connection as well as connection through proxies). thanks and regards, Harish On 7/6/07, Asveren, Tolga wrote: > > I agree that this would be faulty behavior. OTOH, it is always a good idea > to be protected against misbehaving nodes. By applying a local check, where > neighbors, from which no Diameter application level reply has been received > for a while, are no more used to send messages to could be a good idea (or > disconnecting connection to such nodes). > > Thanks, > Tolga > > ________________________________________ > From: Rajith R [mailto:rajithr@huawei.com] > Sent: Wednesday, July 04, 2007 4:59 AM > To: 'Michael Hillier'; dime@ietf.org > Subject: RE: [Dime] Failover problems with Relays and crashed applications > > IMO, there seems to be an implementation issue in the primary server not > responding to "application" requests (like CCR), but the connection still > ticking with DWR-DWA exchanges. Either DWR should not be replied or the > connection layer should understand that the application layer crashed (or to > that effect) and indicate this to its peers in a CER update. > AFAIK, DMT does not recommend/require a transaction time out based fail > over. > > Regards > > Rajith > > ________________________________________ > From: Michael Hillier [mailto:m.hillier@telenet-ag.de] > Sent: Wednesday, July 04, 2007 1:12 PM > To: dime@ietf.org > Subject: [Dime] Failover problems with Relays and crashed applications > Hi all, > > another question has come up in practice. Again we are in the context of > Credit Control Application, but the issue must be applicable to all such > applications which define their own failover mechanisms > > > Given a client (C) communicating via a primary and secondary relay (Rp, > Rs) towards a primary and secondary server (Sp, Ss). > > All Diameter connections are up and running. The client selects Rp and Rp > selects Sp, being the primary next hops. > > Now the primary Server stops answering the application requests (i.e no > CCAs are returned) - for what ever reason, > however the connection Rp <=> Sp is still ticking over, i.e. DWRs are > being answered by Sp. > > Short timers, like Tx, may expire in the client, possibly allowing service > to be delivered, but that is a side issue. > > Now the transaction timer expires causing the client to failover to the > secondary relay (Rs), i.e. re-sending the CCR with T-bit > Rs selects the primary Server, because it does not know any reason not to, > and thus the CCR(with T-bit) is sent to the same server which has failed. > > Summary: client failover to secondary next hop works nicely when directly > connected to the Diameter servers, but does not achieve the desired effect > when relays are used, which have no "application timer" awareness. > > Can anybody point out where I have gone wrong? > > Many thanks > > Mike > > Michael Hillier > Telenet AG Rhein-Main > M.Hillier@telenet-ag.de > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- Harish R Prabhu Bangalore, India. ------=_Part_135656_88365.1183704225661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I feel that this could be achieved by including some re-negotiation facility to the existing capability exchange mechanism of the base protocol. This would need state machine modifications though. But definite advantage I can see in a service provider scenario will be:
1. new applications can be added to a server in a hit-less manner
2. misbehaving applications (detected by some local implementation dependent means) can be removed from the list of locally supported applications and can be re-advertised. this can cause a client to re-trigger to some backup server that can currently serve the application.

This should work in either case (direct connection as well as connection through proxies).

thanks and regards,
Harish

On 7/6/07, Asveren, Tolga <tasveren@sonusnet.com> wrote:
I agree that this would be faulty behavior. OTOH, it is always a good idea to be protected against misbehaving nodes. By applying a local check, where neighbors, from which no Diameter application level reply has been received for a while, are no more used to send messages to could be a good idea (or disconnecting connection to such nodes).

   Thanks,
   Tolga

________________________________________
From: Rajith R [mailto:rajithr@huawei.com]
Sent: Wednesday, July 04, 2007 4:59 AM
To: 'Michael Hillier'; dime@ietf.org
Subject: RE: [Dime] Failover problems with Relays and crashed applications

IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update.
AFAIK, DMT does not recommend/require a transaction time out based fail over.

Regards

Rajith

________________________________________
From: Michael Hillier [mailto: m.hillier@telenet-ag.de]
Sent: Wednesday, July 04, 2007 1:12 PM
To: dime@ietf.org
Subject: [Dime] Failover problems with Relays and crashed applications
Hi all,

another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India. ------=_Part_135656_88365.1183704225661-- --===============0698510637== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0698510637==-- From dime-bounces@ietf.org Fri Jul 06 04:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6j4n-00016X-9F; Fri, 06 Jul 2007 04:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6j4k-000166-4u for dime@ietf.org; Fri, 06 Jul 2007 04:22:02 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6j4e-0007ZS-Ay for dime@ietf.org; Fri, 06 Jul 2007 04:22:02 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKR00FDM0J0DO@szxga04-in.huawei.com> for dime@ietf.org; Fri, 06 Jul 2007 16:21:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKR007GG0IYQ8@szxga04-in.huawei.com> for dime@ietf.org; Fri, 06 Jul 2007 16:21:00 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKR00MQQ0IULM@szxml03-in.huawei.com> for dime@ietf.org; Fri, 06 Jul 2007 16:20:58 +0800 (CST) Date: Fri, 06 Jul 2007 13:50:54 +0530 From: Rajith R Subject: RE: [Dime] Failover problems with Relays and crashed applications In-reply-to: To: 'harish raghuveer' , dime@ietf.org Message-id: <002d01c7bfa6$92ef9680$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace/mQW17YNncahRRlO7zkbX3fzFUQADUSKQ X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0836754260==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0836754260== Content-type: multipart/alternative; boundary="Boundary_(ID_VlPT5NK45COjCAXpgpiQ8Q)" This is a multi-part message in MIME format. --Boundary_(ID_VlPT5NK45COjCAXpgpiQ8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Doesn't the section 5.6.5 of the 3588-bis-04 describe this "facility"? _____ From: harish raghuveer [mailto:harish.r.prabhu@gmail.com] Sent: Friday, July 06, 2007 12:14 PM To: dime@ietf.org Subject: Re: [Dime] Failover problems with Relays and crashed applications I feel that this could be achieved by including some re-negotiation facility to the existing capability exchange mechanism of the base protocol. This would need state machine modifications though. But definite advantage I can see in a service provider scenario will be: 1. new applications can be added to a server in a hit-less manner 2. misbehaving applications (detected by some local implementation dependent means) can be removed from the list of locally supported applications and can be re-advertised. this can cause a client to re-trigger to some backup server that can currently serve the application. This should work in either case (direct connection as well as connection through proxies). thanks and regards, Harish On 7/6/07, Asveren, Tolga wrote: I agree that this would be faulty behavior. OTOH, it is always a good idea to be protected against misbehaving nodes. By applying a local check, where neighbors, from which no Diameter application level reply has been received for a while, are no more used to send messages to could be a good idea (or disconnecting connection to such nodes). Thanks, Tolga ________________________________________ From: Rajith R [mailto:rajithr@huawei.com] Sent: Wednesday, July 04, 2007 4:59 AM To: 'Michael Hillier'; dime@ietf.org Subject: RE: [Dime] Failover problems with Relays and crashed applications IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update. AFAIK, DMT does not recommend/require a transaction time out based fail over. Regards Rajith ________________________________________ From: Michael Hillier [mailto: m.hillier@telenet-ag.de] Sent: Wednesday, July 04, 2007 1:12 PM To: dime@ietf.org Subject: [Dime] Failover problems with Relays and crashed applications Hi all, another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss). All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops. Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason, however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp. Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue. Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed. Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness. Can anybody point out where I have gone wrong? Many thanks Mike Michael Hillier Telenet AG Rhein-Main M.Hillier@telenet-ag.de _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime -- Harish R Prabhu Bangalore, India. --Boundary_(ID_VlPT5NK45COjCAXpgpiQ8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Doesn't the section 5.6.5 of the 3588-bis-04 describe this "facility"?

From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Friday, July 06, 2007 12:14 PM
To: dime@ietf.org
Subject: Re: [Dime] Failover problems with Relays and crashed applications

I feel that this could be achieved by including some re-negotiation facility to the existing capability exchange mechanism of the base protocol. This would need state machine modifications though. But definite advantage I can see in a service provider scenario will be:
1. new applications can be added to a server in a hit-less manner
2. misbehaving applications (detected by some local implementation dependent means) can be removed from the list of locally supported applications and can be re-advertised. this can cause a client to re-trigger to some backup server that can currently serve the application.

This should work in either case (direct connection as well as connection through proxies).

thanks and regards,
Harish

On 7/6/07, Asveren, Tolga <tasveren@sonusnet.com> wrote:
I agree that this would be faulty behavior. OTOH, it is always a good idea to be protected against misbehaving nodes. By applying a local check, where neighbors, from which no Diameter application level reply has been received for a while, are no more used to send messages to could be a good idea (or disconnecting connection to such nodes).

   Thanks,
   Tolga

________________________________________
From: Rajith R [mailto:rajithr@huawei.com]
Sent: Wednesday, July 04, 2007 4:59 AM
To: 'Michael Hillier'; dime@ietf.org
Subject: RE: [Dime] Failover problems with Relays and crashed applications

IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update.
AFAIK, DMT does not recommend/require a transaction time out based fail over.

Regards

Rajith

________________________________________
From: Michael Hillier [mailto: m.hillier@telenet-ag.de]
Sent: Wednesday, July 04, 2007 1:12 PM
To: dime@ietf.org
Subject: [Dime] Failover problems with Relays and crashed applications
Hi all,

another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India.
--Boundary_(ID_VlPT5NK45COjCAXpgpiQ8Q)-- --===============0836754260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0836754260==-- From dime-bounces@ietf.org Fri Jul 06 04:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jSn-0004Xr-R9; Fri, 06 Jul 2007 04:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jSm-0004Xh-0U for dime@ietf.org; Fri, 06 Jul 2007 04:46:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jSh-0001Fw-4y for dime@ietf.org; Fri, 06 Jul 2007 04:46:51 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1740426uge for ; Fri, 06 Jul 2007 01:46:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nToCMro4B0QBmVH0UQWjJumJcCN4wabeFRACE6bAa0vKFpkaN+UtG1d2lmUQeWLNOjy94UId1adP1sq6CFUPxIIuCziPwJujjUh/heMyGNrTwFrO6oklI0D/G++9MKhMq3NAlf61hpIyp/dk0HSEIyllQWPC8i5rsmrseQjolkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=NE9raIW1ez1K7Pz1n7ctUf5NAVM6kV1lY644ZE6DsqCgTiJEg2BMw3Yj+jzWoLnqTrZxt1ocBIjMzjHwoYke1Zds2iV+I9cIwIrAp8VUYA616P2KIJ60u6C6jgvg3+TXyL8hBNIXlPMrVtajubigh0So8W4VxoKpWquLJuNIotg= Received: by 10.82.106.14 with SMTP id e14mr1250844buc.1183711606121; Fri, 06 Jul 2007 01:46:46 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Fri, 6 Jul 2007 01:46:46 -0700 (PDT) Message-ID: Date: Fri, 6 Jul 2007 14:16:46 +0530 From: "harish raghuveer" To: dime@ietf.org Subject: Re: [Dime] Failover problems with Relays and crashed applications In-Reply-To: <002d01c7bfa6$92ef9680$3a17120a@china.huawei.com> MIME-Version: 1.0 References: <002d01c7bfa6$92ef9680$3a17120a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1537633747==" Errors-To: dime-bounces@ietf.org --===============1537633747== Content-Type: multipart/alternative; boundary="----=_Part_136448_23242840.1183711606086" ------=_Part_136448_23242840.1183711606086 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, it does - thanks for pointed it out! I am still using 3588 as reference - I probably should upgrade.. :-) On 7/6/07, Rajith R wrote: > > Doesn't the section 5.6.5 of the 3588-bis-04 describe this "facility"? > > ------------------------------ > *From:* harish raghuveer [mailto:harish.r.prabhu@gmail.com] > *Sent:* Friday, July 06, 2007 12:14 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] Failover problems with Relays and crashed > applications > > I feel that this could be achieved by including some re-negotiation > facility to the existing capability exchange mechanism of the base protocol. > This would need state machine modifications though. But definite advantage I > can see in a service provider scenario will be: > 1. new applications can be added to a server in a hit-less manner > 2. misbehaving applications (detected by some local implementation > dependent means) can be removed from the list of locally supported > applications and can be re-advertised. this can cause a client to re-trigger > to some backup server that can currently serve the application. > > This should work in either case (direct connection as well as connection > through proxies). > > thanks and regards, > Harish > > On 7/6/07, Asveren, Tolga wrote: > > > > I agree that this would be faulty behavior. OTOH, it is always a good > > idea to be protected against misbehaving nodes. By applying a local check, > > where neighbors, from which no Diameter application level reply has been > > received for a while, are no more used to send messages to could be a good > > idea (or disconnecting connection to such nodes). > > > > Thanks, > > Tolga > > > > ________________________________________ > > From: Rajith R [mailto:rajithr@huawei.com] > > Sent: Wednesday, July 04, 2007 4:59 AM > > To: 'Michael Hillier'; dime@ietf.org > > Subject: RE: [Dime] Failover problems with Relays and crashed > > applications > > > > IMO, there seems to be an implementation issue in the primary server not > > responding to "application" requests (like CCR), but the connection still > > ticking with DWR-DWA exchanges. Either DWR should not be replied or the > > connection layer should understand that the application layer crashed (or to > > that effect) and indicate this to its peers in a CER update. > > AFAIK, DMT does not recommend/require a transaction time out based fail > > over. > > > > Regards > > > > Rajith > > > > ________________________________________ > > From: Michael Hillier [mailto: m.hillier@telenet-ag.de] > > Sent: Wednesday, July 04, 2007 1:12 PM > > To: dime@ietf.org > > Subject: [Dime] Failover problems with Relays and crashed applications > > Hi all, > > > > another question has come up in practice. Again we are in the context of > > Credit Control Application, but the issue must be applicable to all such > > applications which define their own failover mechanisms > > > > > > Given a client (C) communicating via a primary and secondary relay (Rp, > > Rs) towards a primary and secondary server (Sp, Ss). > > > > All Diameter connections are up and running. The client selects Rp and > > Rp selects Sp, being the primary next hops. > > > > Now the primary Server stops answering the application requests (i.e no > > CCAs are returned) - for what ever reason, > > however the connection Rp <=> Sp is still ticking over, i.e. DWRs are > > being answered by Sp. > > > > Short timers, like Tx, may expire in the client, possibly allowing > > service to be delivered, but that is a side issue. > > > > Now the transaction timer expires causing the client to failover to the > > secondary relay (Rs), i.e. re-sending the CCR with T-bit > > Rs selects the primary Server, because it does not know any reason not > > to, and thus the CCR(with T-bit) is sent to the same server which has > > failed. > > > > Summary: client failover to secondary next hop works nicely when > > directly connected to the Diameter servers, but does not achieve the desired > > effect when relays are used, which have no "application timer" awareness. > > > > Can anybody point out where I have gone wrong? > > > > Many thanks > > > > Mike > > > > Michael Hillier > > Telenet AG Rhein-Main > > M.Hillier@telenet-ag.de > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > Harish R Prabhu > Bangalore, India. > > -- Harish R Prabhu Bangalore, India. ------=_Part_136448_23242840.1183711606086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, it does - thanks for pointed it out! I am still using 3588 as reference - I probably should upgrade.. :-)

On 7/6/07, Rajith R < rajithr@huawei.com> wrote:
Doesn't the section 5.6.5 of the 3588-bis-04 describe this "facility"?

From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Friday, July 06, 2007 12:14 PM
To: dime@ietf.org
Subject: Re: [Dime] Failover problems with Relays and crashed applications

I feel that this could be achieved by including some re-negotiation facility to the existing capability exchange mechanism of the base protocol. This would need state machine modifications though. But definite advantage I can see in a service provider scenario will be:
1. new applications can be added to a server in a hit-less manner
2. misbehaving applications (detected by some local implementation dependent means) can be removed from the list of locally supported applications and can be re-advertised. this can cause a client to re-trigger to some backup server that can currently serve the application.

This should work in either case (direct connection as well as connection through proxies).

thanks and regards,
Harish

On 7/6/07, Asveren, Tolga <tasveren@sonusnet.com> wrote:
I agree that this would be faulty behavior. OTOH, it is always a good idea to be protected against misbehaving nodes. By applying a local check, where neighbors, from which no Diameter application level reply has been received for a while, are no more used to send messages to could be a good idea (or disconnecting connection to such nodes).

   Thanks,
   Tolga

________________________________________
From: Rajith R [mailto:rajithr@huawei.com]
Sent: Wednesday, July 04, 2007 4:59 AM
To: 'Michael Hillier'; dime@ietf.org
Subject: RE: [Dime] Failover problems with Relays and crashed applications

IMO, there seems to be an implementation issue in the primary server not responding to "application" requests (like CCR), but the connection still ticking with DWR-DWA exchanges. Either DWR should not be replied or the connection layer should understand that the application layer crashed (or to that effect) and indicate this to its peers in a CER update.
AFAIK, DMT does not recommend/require a transaction time out based fail over.

Regards

Rajith

________________________________________
From: Michael Hillier [mailto: m.hillier@telenet-ag.de]
Sent: Wednesday, July 04, 2007 1:12 PM
To: dime@ietf.org
Subject: [Dime] Failover problems with Relays and crashed applications
Hi all,

another question has come up in practice. Again we are in the context of Credit Control Application, but the issue must be applicable to all such applications which define their own failover mechanisms


Given a client (C) communicating via a primary and secondary relay (Rp, Rs) towards a primary and secondary server (Sp, Ss).

All Diameter connections are up and running. The client selects Rp and Rp selects Sp, being the primary next hops.

Now the primary Server stops answering the application requests (i.e no CCAs are returned) - for what ever reason,
however the connection Rp <=> Sp is still ticking over, i.e. DWRs are being answered by Sp.

Short timers, like Tx, may expire in the client, possibly allowing service to be delivered, but that is a side issue.

Now the transaction timer expires causing the client to failover to the secondary relay (Rs), i.e. re-sending the CCR with T-bit
Rs selects the primary Server, because it does not know any reason not to, and thus the CCR(with T-bit) is sent to the same server which has failed.

Summary: client failover to secondary next hop works nicely when directly connected to the Diameter servers, but does not achieve the desired effect when relays are used, which have no "application timer" awareness.

Can anybody point out where I have gone wrong?

Many thanks

Mike

Michael Hillier
Telenet AG Rhein-Main
M.Hillier@telenet-ag.de


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India.



--
Harish R Prabhu
Bangalore, India. ------=_Part_136448_23242840.1183711606086-- --===============1537633747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1537633747==-- From dime-bounces@ietf.org Fri Jul 06 08:01:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6mUj-0000vS-BB; Fri, 06 Jul 2007 08:01:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6mUi-0000vG-1w for dime@ietf.org; Fri, 06 Jul 2007 08:01:04 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6mUh-0003FO-NA for dime@ietf.org; Fri, 06 Jul 2007 08:01:03 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l66C0TRf008998; Fri, 6 Jul 2007 08:00:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] STUN relay with push mode QoS reservation Date: Fri, 6 Jul 2007 08:00:28 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718802A@sonusmail04.sonusnet.com> In-Reply-To: <468DE44C.6030107@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] STUN relay with push mode QoS reservation Thread-Index: Ace/mM9lstabnnQ+T/yEsqTtjuH61QALFXGA References: <033458F56EC2A64E8D2D7B759FA3E7E7188023@sonusmail04.sonusnet.com> <468DE44C.6030107@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" X-Spam-Score: 2.0 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, I was considering the scenario where QoS reservation is done only for the access. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, July 06, 2007 2:42 AM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] STUN relay with push mode QoS reservation >=20 > Hi Tolga, >=20 > you need to explain where you want to install what type of QoS > reservation. >=20 > In essence, you might consider two scenarios: >=20 > * QoS reservation only in the access > * QoS reservation along the path of the media traffic (with a couple of > routers) >=20 > In the former case that's the plan of most SDOs. >=20 > For the later case you seem to be describing the interworking between > Diameter QoS, STUN to trigger a proxy RSVP/NSIS scenario. > See > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy- > approaches-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto- > 01.txt >=20 > For NSIS the functionality is built into the main specification: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-14.txt >=20 > Ciao > Hannes >=20 > Asveren, Tolga wrote: > > Let me ping about this first in the friendly neighborhood WG (actually I > > guess this topic may be more relevant to SIPPING and/or BEHAVE WGs): > > > > Consider the following configuration (QoS reservation for access network > > with push model): > > > > +----+ +-----+ +------+ > > | | | | | | > > | UA +------+ NAT +---------------------+ AF | > > | |xxxxxx| | | | > > +----+ +-----+ +---"--+ > > x(IP1) " > > x +--------+ " +----+ > > x | STUN | " | | > > x | Relay |xxxxxxxxxxxxxxxxx| UA | > > x | |(IP3) " (IP4)| | > > x +--------+ " +----+ > > x x(IP2) " > > +-----+ x +---"--+ > > | |xxxxxxxx | | > > | PEF | | PDF | > > | """"""""""""""""""""""" | > > +-----+ +------+ > > > > > > --- Call Signaling (SIP) > > > > """ QoS Signaling (Diameter QoS application) > > > > xxx Media > > > > > > UA would use IP3 as its media address in the SDP, so AF would know only > > IP3 and IP4 from the far end UA. What PEF needs is IP2 and IP1. > > > > One solution is probably PEF consulting STUN Relay to learn the actual > > IP addresses (STUN Relay has the binding between IP1-IP2/IP3-IP4). > > > > Another approach could be to signal IP1/IP2 in some newly defined SDP > > fields. > > > > Any ideas? > > > > Thanks, > > Tolga > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 08 17:15:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7e6a-0000QS-0O; Sun, 08 Jul 2007 17:15:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7e6P-0008Tr-9p; Sun, 08 Jul 2007 17:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7e6P-0006Ag-1h; Sun, 08 Jul 2007 17:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BFC32175E3; Sun, 8 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7e5u-0006xo-Bi; Sun, 08 Jul 2007 17:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 08 Jul 2007 17:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-05.txt Pages : 158 Date : 2007-7-8 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-8163206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8163206.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Jul 09 01:28:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lnU-00074P-2A; Mon, 09 Jul 2007 01:28:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lnR-000729-9J for dime@ietf.org; Mon, 09 Jul 2007 01:28:30 -0400 Received: from 66.88.142.84.ptr.us.xo.net ([66.88.142.84] helo=sd-smtp.ccpu.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7lnQ-0004k5-V3 for dime@ietf.org; Mon, 09 Jul 2007 01:28:29 -0400 Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 2936B184A27 for ; Sun, 8 Jul 2007 22:27:24 -0700 (PDT) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 0450A184A25 for ; Sun, 8 Jul 2007 22:27:24 -0700 (PDT) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 22:27:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jul 2007 10:57:19 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F00187552F@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 'P' bit in AVP flag Thread-Index: AcfB6dG36cfDW3V1ReyXZVnLNVHKhQ== From: "Soji VP" To: X-OriginalArrivalTime: 09 Jul 2007 05:27:23.0728 (UTC) FILETIME=[D455C500:01C7C1E9] X-TM-AS-Product-Ver: IMSS-7.0.0.1640-3.8.0.1026-15282.001 X-TM-AS-Result: No--8.861-5.0-3-1 X-imss-scan-details: No--8.861-5.0-3-1;No--8.861-5.0-3-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Dime] 'P' bit in AVP flag X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875997685==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1875997685== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C1E9.D20F1961" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C1E9.D20F1961 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi friends, =20 'P' bit has been removed from AVP header (from 3588bis-03 onwards) but it's still being referred in the table given in section "4.5 Diameter Base protocol AVPs". I feel it can be safely removed as it's no more relevant there. =20 Thanks & Rgds, Soj. =20 ------_=_NextPart_001_01C7C1E9.D20F1961 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi friends,

 

‘P’ bit has been removed from AVP header = (from 3588bis-03 onwards) but it’s still being referred in the table given in = section “4.5 Diameter Base protocol AVPs”. I feel it can be safely removed as = it’s no more relevant there.

 

Thanks & Rgds,

Soj.

 

------_=_NextPart_001_01C7C1E9.D20F1961-- --===============1875997685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1875997685==-- From dime-bounces@ietf.org Mon Jul 09 01:45:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7m3q-0007UC-F3; Mon, 09 Jul 2007 01:45:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7m3p-0007T9-4G for dime@ietf.org; Mon, 09 Jul 2007 01:45:25 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7m3l-0004yc-Td for dime@ietf.org; Mon, 09 Jul 2007 01:45:25 -0400 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1183959867!21365962!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14781 invoked from network); 9 Jul 2007 05:44:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 9 Jul 2007 05:44:27 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l695iQWV016091 for ; Sun, 8 Jul 2007 22:44:26 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l695iP56015172 for ; Mon, 9 Jul 2007 00:44:25 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l695iNxx015149 for ; Mon, 9 Jul 2007 00:44:24 -0500 (CDT) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM70.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 9 Jul 2007 13:44:22 +0800 Message-ID: <4691CA95.20005@motorola.com> Date: Mon, 09 Jul 2007 11:11:41 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: dime@ietf.org X-OriginalArrivalTime: 09 Jul 2007 05:44:22.0452 (UTC) FILETIME=[338AB740:01C7C1EC] X-Vontu: Pass X-Spam-Score: 1.7 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Tolga Asveren Subject: [Dime] RFC 4006: Tariff Change Usage X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0898149146==" Errors-To: dime-bounces@ietf.org --===============0898149146== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I had a query regarding the usage of traiff-change-usage AVP.

Sec 8.16 of RFC 4006 states that, "When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate instances of the Multiple-Services-Credit-Control AVP with the Granted-Service-Unit AVP associated to the same service-identifier and/or rating-group."
and also "The Tariff-Change-Usage AVP MUST NOT be included in request commands to report used units before, and after tariff time change the Used- Service-Unit AVP MUST be used."

>From this, quiet clearly, I can infer that the Tariff-Change-Usage AVP must be added only in USU in a CCR.
My question is, when there is a potential tariff change and the server sends two MSCCs in a CCA, itemizing the granted units to be used before and after the tariff change, should the client report back the used units in two different MSCCs or in a single MSCC with two USUs? Is this behavior mentioned anywhere else?

i would appreciate if anybody can provide any input on this. 
-- 
Cheers,
Liyaqatali G Nadaf
--===============0898149146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0898149146==-- From dime-bounces@ietf.org Mon Jul 09 05:28:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7pXt-0002vD-N2; Mon, 09 Jul 2007 05:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7pXq-0002v5-Vk for dime@ietf.org; Mon, 09 Jul 2007 05:28:38 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7pXm-0000f3-6e for dime@ietf.org; Mon, 09 Jul 2007 05:28:38 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKW007F1NM3ZJ@szxga03-in.huawei.com> for dime@ietf.org; Mon, 09 Jul 2007 17:27:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKW00D8TNM26B@szxga03-in.huawei.com> for dime@ietf.org; Mon, 09 Jul 2007 17:27:39 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKW00699NM2F3@szxml04-in.huawei.com> for dime@ietf.org; Mon, 09 Jul 2007 17:27:38 +0800 (CST) Date: Mon, 09 Jul 2007 17:27:38 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <008201c7c20b$64755b70$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Dime] Diameter QoS Appl. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0756701709==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0756701709== Content-type: multipart/alternative; boundary="Boundary_(ID_bIXSGilZ6PeOXSEmrp5g3A)" This is a multi-part message in MIME format. --Boundary_(ID_bIXSGilZ6PeOXSEmrp5g3A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, I suggest that some texts could be added in the beginning of 3.3 to smooth with the texts in 3.3.1 and 3.3.2. [snipped] 3.3. Authorization schemes Three basic authorization models for QoS reservations exist: one two -party and two three party models. In the three party QoS model (Figure 3), the authorization entity may be composed of two separate functional entities - Application Server which interacts with the QoS requesting entity and Authorizing Entity. The Application Server MAY indicate the access network related information in a service request to Authorizing Entity which can be used by the Authorizing Entity to select the appropriate resource admission and control policies. The service request from Application Server to Authorizing Entity MAY also indicate the admission control mode (i.e., "pull" or "push" model) in terms of which Authorizing Entity performs QoS authorization and then sends the policy decisions to the NE which performs QoS reservation. Authorization schemes for both pull and push mode will be described below in detail. 3.3.1. Authorization schemes for pull mode [snipped] B. R. Tina --Boundary_(ID_bIXSGilZ6PeOXSEmrp5g3A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
I suggest that some texts could be added in the beginning of 3.3 to smooth
with the texts in 3.3.1 and 3.3.2.
 
[snipped]
3.3.  Authorization schemes

   Three basic authorization models for QoS reservations exist: one two
   -party and two three party models.  In the three party QoS model
   (Figure 3), the authorization entity may be composed of two separate
   functional entities - Application Server which interacts with the QoS
   requesting entity and Authorizing Entity.  The Application Server MAY
   indicate the access network related information in a service request
   to Authorizing Entity which can be used by the Authorizing Entity to
   select the appropriate resource admission and control policies.  The
   service request from Application Server to Authorizing Entity MAY
   also indicate the admission control mode (i.e., "pull" or "push"
   model) in terms of which Authorizing Entity performs QoS
   authorization and then sends the policy decisions to the NE which
   performs QoS reservation. Authorization schemes for both pull
   and push mode will be described below in detail.

3.3.1.  Authorization schemes for pull mode
[snipped]
B. R.
Tina
--Boundary_(ID_bIXSGilZ6PeOXSEmrp5g3A)-- --===============0756701709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0756701709==-- From dime-bounces@ietf.org Mon Jul 09 08:05:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rzs-0008MO-6l; Mon, 09 Jul 2007 08:05:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rzS-0007cf-9N for dime@ietf.org; Mon, 09 Jul 2007 08:05:18 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7rzS-0005Ob-1Z for dime@ietf.org; Mon, 09 Jul 2007 08:05:18 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l69C4bd8039175; Mon, 9 Jul 2007 08:04:37 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46922454.2060708@tari.toshiba.com> Date: Mon, 09 Jul 2007 08:04:36 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Soji VP Subject: Re: [Dime] 'P' bit in AVP flag References: <22F058C3ED9D784E90CE473F2A9847F00187552F@in-exchange> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F00187552F@in-exchange> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l69C4bd8039175 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thanks for catching that. It will be removed in the next rev. -- victor > Hi friends, > > =91P=92 bit has been removed from AVP header (from 3588bis-03 onwards) = but=20 > it=92s still being referred in the table given in section =934.5 Diamet= er=20 > Base protocol AVPs=94. I feel it can be safely removed as it=92s no mor= e=20 > relevant there. > > Thanks & Rgds, > > Soj. > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 09 09:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7ssO-0002ft-01; Mon, 09 Jul 2007 09:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7srP-0000YS-Dt for dime@ietf.org; Mon, 09 Jul 2007 09:01:03 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7srJ-0006kc-JS for dime@ietf.org; Mon, 09 Jul 2007 09:01:03 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 2585F3600B4; Mon, 9 Jul 2007 18:29:06 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid 0FE6036003F; Mon, 9 Jul 2007 18:29:06 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 18:30:53 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 'P' bit in AVP flag Date: Mon, 9 Jul 2007 18:30:50 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601C3336A@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 'P' bit in AVP flag Thread-Index: AcfCI5x4q2H+e8OYSLmc/xu9diuWcQABIFDg From: "Balamurugan T, TLS-Chennai" To: "Victor Fajardo" , "Soji VP" X-OriginalArrivalTime: 09 Jul 2007 13:00:53.0385 (UTC) FILETIME=[2E8DEF90:01C7C229] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-9.0666 TC:1F TRN:26 TV:3.6.1039(15282.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, From my understanding P bit means for end to end security. If this bit= is no more available in diameter RFC, then how can we achieve end-to-end security. Regards, Bala -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Monday, July 09, 2007 5:35 PM To: Soji VP Cc: dime@ietf.org Subject: Re: [Dime] 'P' bit in AVP flag Thanks for catching that. It will be removed in the next rev. -- victor > Hi friends, > > =91P=92 bit has been removed from AVP header (from 3588bis-03 onwards)= but=20 > it=92s still being referred in the table given in section =934.5 Diameter= =20 > Base protocol AVPs=94. I feel it can be safely removed as it=92s no more= =20 > relevant there. > > Thanks & Rgds, > > Soj. > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 09 09:05:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7svv-0005nV-HT; Mon, 09 Jul 2007 09:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7svs-0005nD-82 for dime@ietf.org; Mon, 09 Jul 2007 09:05:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7svn-0006vP-Oi for dime@ietf.org; Mon, 09 Jul 2007 09:05:40 -0400 Received: (qmail invoked by alias); 09 Jul 2007 13:05:34 -0000 Received: from p549844BC.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.68.188] by mail.gmx.net (mp053) with SMTP; 09 Jul 2007 15:05:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+zBPE9lfmzoI76hXMQYkdEMvayYkRCrZRBmLiFbd HvcATLXl8btaV7 Message-ID: <46923296.6020804@gmx.net> Date: Mon, 09 Jul 2007 15:05:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Balamurugan T, TLS-Chennai" Subject: Re: [Dime] 'P' bit in AVP flag References: <66E8AEE9980BB44CA5FCAD39EBA56AC601C3336A@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601C3336A@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The concept of end-to-end security was once described in Diameter CMS Security Application, see for example http://www3.ietf.org/proceedings/02jul/I-D/draft-ietf-aaa-diameter-cms-sec-04.txt Since the work on that document was stopped we don't have E2E security in Diameter anymore (unless someone finds a need for it and continues that document). In this case that document would re-introduce the P bit. Ciao Hannes Balamurugan T, TLS-Chennai wrote: > Hi All, > > From my understanding P bit means for end to end security. If this bit is no more > available in diameter RFC, then how can we achieve end-to-end security. > > Regards, > Bala > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, July 09, 2007 5:35 PM > To: Soji VP > Cc: dime@ietf.org > Subject: Re: [Dime] 'P' bit in AVP flag > > > Thanks for catching that. It will be removed in the next rev. > > -- victor > > >> Hi friends, >> >> ‘P’ bit has been removed from AVP header (from 3588bis-03 onwards) but >> it’s still being referred in the table given in section “4.5 Diameter >> Base protocol AVPs”. I feel it can be safely removed as it’s no more >> relevant there. >> >> Thanks & Rgds, >> >> Soj. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 09 10:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uRS-0003di-As; Mon, 09 Jul 2007 10:42:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uRR-0003dY-6R for dime@ietf.org; Mon, 09 Jul 2007 10:42:21 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7uRJ-0000kG-DF for dime@ietf.org; Mon, 09 Jul 2007 10:42:21 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id C46DC360037 for ; Mon, 9 Jul 2007 20:09:35 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id B9B1B360022for ; Mon, 9 Jul 2007 20:09:35 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 20:11:23 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jul 2007 20:11:07 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601C334C2@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need info on CxDx interface Thread-Index: AcfCNy9s0PDDloXeSDS8NyZVvFvKZw== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 09 Jul 2007 14:41:23.0026 (UTC) FILETIME=[38802320:01C7C237] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-3.6469 TC:1F TRN:29 TV:3.6.1039(15288.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_vazyCa0mOkLn4g38CM10" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Dime] Need info on CxDx interface X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_vazyCa0mOkLn4g38CM10 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Need info on CxDx interface

Hi Guys,

     I want = to know some info regarding CxDx interface functionality. I would be = helpful if
     = somebody give some information regarding the diameter commands to be = used in each
     = interface.

     Among = the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used = in
     Cx and = which are all comes under Dx.

     Thanks = in Advance.

Regards,
Bala

 =20

--=_Boundary_vazyCa0mOkLn4g38CM10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_vazyCa0mOkLn4g38CM10 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_Boundary_vazyCa0mOkLn4g38CM10-- From dime-bounces@ietf.org Mon Jul 09 12:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vhf-00089W-Gd; Mon, 09 Jul 2007 12:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vhe-00089M-FX for dime@ietf.org; Mon, 09 Jul 2007 12:03:10 -0400 Received: from mail12.opentransfer.com ([76.162.254.12]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7vhZ-0003mO-4k for dime@ietf.org; Mon, 09 Jul 2007 12:03:10 -0400 Received: (qmail 20903 invoked by uid 399); 9 Jul 2007 16:03:01 -0000 Received: from unknown (HELO KRISHNA) (122.167.145.92) by mail12.opentransfer.com with SMTP; 9 Jul 2007 16:03:01 -0000 From: To: "'Balamurugan T, TLS-Chennai'" , Subject: RE: [Dime] Need info on CxDx interface Date: Mon, 9 Jul 2007 21:33:05 +0530 Message-ID: <000901c7c242$a4a69880$5901a8c0@KRISHNA> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601C334C2@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 0.2 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493293649==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0493293649== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C7C270.BE5ED480" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C7C270.BE5ED480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bala, You may need to post this on 3gpp.org mailing list ( in particular CT4) for better response. Just as a note the related specs are 29.229 and 29.228, Dx interface is nothing but Cx which is used towards SLF (Redirect agent in diameter terminology) to get the subscribers' HSS. It is just a virtual interface and in all aspects it is similar to Cx. Broadly you can say Dx is nothing but Cx interface with Redirect Agent functionality support. Hope this helps. Prasad. -----Original Message----- From: Balamurugan T, TLS-Chennai [mailto:tbalamurugan@hcl.in] Sent: Monday, July 09, 2007 8:11 PM To: dime@ietf.org Subject: [Dime] Need info on CxDx interface Hi Guys, I want to know some info regarding CxDx interface functionality. I would be helpful if somebody give some information regarding the diameter commands to be used in each interface. Among the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used in Cx and which are all comes under Dx. Thanks in Advance. Regards, Bala ------=_NextPart_000_000A_01C7C270.BE5ED480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Need info on CxDx interface

Hi Bala,

        = ;    You may need to post this on 3gpp.org mailing list ( in particular CT4) for = better response. Just as a note the related specs are 29.229 and 29.228, Dx interface is nothing but Cx which is used = towards SLF (Redirect agent in diameter terminology) to get the subscribers’ = HSS. It is just a virtual interface and in all aspects it is similar to Cx. = Broadly you can say Dx is nothing but Cx interface with = Redirect Agent functionality support.

 

Hope this = helps.

Prasad.

=

 

-----Original = Message-----
From: Balamurugan T, = TLS-Chennai [mailto:tbalamurugan@hcl.in]
Sent: Monday, July 09, = 2007 8:11 PM
To: dime@ietf.org
Subject: [Dime] Need info = on CxDx interface

 

Hi = Guys,

     I want to know some info regarding CxDx interface functionality. I would = be helpful if
     somebody give some information regarding the diameter commands to be = used in each
     interface.

     Among the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used = in
     Cx and which are all comes under Dx.

     Thanks in Advance.

Regards,
Bala

 

------=_NextPart_000_000A_01C7C270.BE5ED480-- --===============0493293649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0493293649==-- From dime-bounces@ietf.org Mon Jul 09 14:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y1P-0000Uq-8V; Mon, 09 Jul 2007 14:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y1N-0000Tg-OJ for dime@ietf.org; Mon, 09 Jul 2007 14:31:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7y1J-0000hO-C7 for dime@ietf.org; Mon, 09 Jul 2007 14:31:41 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 11:31:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIYbkkarR7PD/2dsb2JhbACCYQ X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208,217"; a="384411038:sNHT105259504" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l69IValp028267; Mon, 9 Jul 2007 11:31:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69IVamo005967; Mon, 9 Jul 2007 18:31:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 11:31:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Need info on CxDx interface Date: Mon, 9 Jul 2007 11:31:34 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504496B3E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601C334C2@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Need info on CxDx interface Thread-Index: AcfCNy9s0PDDloXeSDS8NyZVvFvKZwAIAuXA References: <66E8AEE9980BB44CA5FCAD39EBA56AC601C334C2@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Glen Zorn \(gwz\)" To: "Balamurugan T, TLS-Chennai" , X-OriginalArrivalTime: 09 Jul 2007 18:31:36.0027 (UTC) FILETIME=[61B0D2B0:01C7C257] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2524; t=1184005896; x=1184869896; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Need=20info=20on=20CxDx=20interface |Sender:=20; bh=NU+ut4mAmWc8oKlUb9XPzKhpWCGCuPFQI4LKAew0Qw8=; b=Os1zPzNoY+6bEXDGHK14r9m1JW711C7KjfEfoUdOh+YsUi6Avi9r3UvZ8lE/1AkJH/tXwcoU dQd1sAt2WC20HOX8HZNsDhveterPCx8lQwciYG+cUFrtxoAmMJ4gInkI; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225332453==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1225332453== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C257.616913C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C257.616913C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys,=20 I want to know some info regarding CxDx interface functionality. I would be helpful if=20 somebody give some information regarding the diameter commands to be used in each=20 interface.=20 Among the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used in=20 Cx and which are all comes under Dx. =20 If you want to know about 3GPP-specific Diameter usage, I suggest that you inquire of 3GPP.=20 Thanks in Advance.=20 Regards,=20 Bala=20 ------_=_NextPart_001_01C7C257.616913C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Need info on CxDx interface
Hi = Guys,

     I want = to know some=20 info regarding CxDx interface functionality. I would be helpful if=20
     = somebody=20 give some information regarding the diameter commands to be used in each =
    =20 interface.

     Among = the possible=20 commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used in =
     Cx and which are = all comes=20 under Dx.  

If you=20 want to know about 3GPP-specific Diameter usage, I suggest = that you=20 inquire of 3GPP. 

     Thanks = in=20 Advance.

Regards,
Bala

------_=_NextPart_001_01C7C257.616913C4-- --===============1225332453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1225332453==-- From dime-bounces@ietf.org Tue Jul 10 00:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I87jl-00023X-LM; Tue, 10 Jul 2007 00:54:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I87jk-00023S-OU for dime@ietf.org; Tue, 10 Jul 2007 00:54:08 -0400 Received: from mglblrmail.mgl.com ([61.95.163.15] helo=mglblrmail.blr.mgl.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I87jj-0001b4-Qm for dime@ietf.org; Tue, 10 Jul 2007 00:54:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Need info on CxDx interface Date: Tue, 10 Jul 2007 10:23:33 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Need info on CxDx interface Thread-Index: AcfCNy9s0PDDloXeSDS8NyZVvFvKZwAIAuXAABUgcnA= From: "Tushar Kanti Panda" To: "Glen Zorn \(gwz\)" , "Balamurugan T, TLS-Chennai" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1742493965==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1742493965== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2AE.4473B601" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C2AE.4473B601 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hello Bala, CxDx messages are not classified based on the interface. We can't group them under Cx / Dx interface. All messages are equally applicable to both Cx as well as Dx interface. If you refer 3GPP spec 29.228, it is evident that Cx interface is between I-CSCF / S-CSCF and HSS. Similarly Dx is between I-CSCF / S-CSCF and SLF. Any messages originated by CSCF will be sent across Cx interface if it has the fixed destination host. In the absence of destination host, CSCF will query SLF across the Dx interface by sending the same message. SLF in turn returns HSS host name to which CSCF later forwards the request. =20 Regards Tushar=20 =20 ________________________________ From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: Tuesday, July 10, 2007 12:02 AM To: Balamurugan T, TLS-Chennai; dime@ietf.org Subject: RE: [Dime] Need info on CxDx interface =20 Hi Guys,=20 I want to know some info regarding CxDx interface functionality. I would be helpful if=20 somebody give some information regarding the diameter commands to be used in each=20 interface.=20 Among the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used in=20 Cx and which are all comes under Dx. =20 If you want to know about 3GPP-specific Diameter usage, I suggest that you inquire of 3GPP.=20 Thanks in Advance.=20 Regards,=20 Bala=20 EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.=0A=0AWhilst Mascon takes steps to prevent the transmission of viru= ses via e-mail, we can not guarantee that any email or attachment is free= from computer viruses and you are strongly advised to undertake your own= anti-virus precautions. Mascon grants no warranties regarding performanc= e, use or quality of any e-mail or attachment and undertakes no liability= for loss or damage, howsoever caused. =0A=0A ------_=_NextPart_001_01C7C2AE.4473B601 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Need info on CxDx interface

Hello Bala,=

      =         CxDx messages are not classified based on the interface. We can’t g= roup them under Cx / Dx interface. All messages are equally applicable to both= Cx as well as Dx interface. If you refer 3GPP spec 29.228, it is evident that C= x interface is between I-CSCF / S-CSCF and HSS. Similarly Dx is between I-C= SCF / S-CSCF and SLF. Any messages originated by CSCF will be sent across Cx interface if it has the fixed destination host. In the absence of destina= tion host, CSCF will query SLF across the Dx interface by sending the same mes= sage. SLF in turn returns HSS host name to which CSCF later forwards the reques= t.

 

Regards

Tushar

 

From: Glen Z= orn (gwz) [mailto:gwz@cisco.com]
Sent: Tuesday, July 10, 20= 07 12:02 AM
To: Balamurugan T, TLS-Che= nnai; dime@ietf.org
Subject: RE: [Dime] Need i= nfo on CxDx interface

 

Hi Guys,

     I want to know some info regardin= g CxDx interface functionality. I would be helpful if
     somebody give some information regarding the diameter commands to be used= in each
     interface.

     Among the possible commands in CxDx(UAR,LIR,MAR,PPR,PNR) ,which messages used in
     Cx and which are all comes under Dx.  

If you want to know about 3GPP-specific Diameter u= sage, I suggest that you inquire of 3GPP. 

     Thanks in Advance. =

Regards,
Bala

EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.
=0A
=0AWhilst Mascon takes steps to prevent the transmission= of viruses via e-mail, we can not guarantee that any email or attachment= is free from computer viruses and you are strongly advised to undertake = your own anti-virus precautions. Mascon grants no warranties regarding pe= rformance, use or quality of any e-mail or attachment and undertakes no l= iability for loss or damage, howsoever caused.
=0A
=0A

------_=_NextPart_001_01C7C2AE.4473B601-- --===============1742493965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1742493965==-- From dime-bounces@ietf.org Tue Jul 10 02:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89dP-0003yJ-VT; Tue, 10 Jul 2007 02:55:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89dO-0003pZ-1a for dime@ietf.org; Tue, 10 Jul 2007 02:55:42 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I89dJ-0001bk-P2 for dime@ietf.org; Tue, 10 Jul 2007 02:55:42 -0400 Received: by py-out-1112.google.com with SMTP id f31so4004850pyh for ; Mon, 09 Jul 2007 23:55:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=pLlwBYiG51S5qYEa/AL8T2zOE7RatFyTA47nm+DmUKbjmp9RTe5k0i4gESqw2gqoyoP7v7fNNj9Wit0GXKU1y8pXxvJRWgOBJ5F+9AeoiZPia1AmzP8eZOcs09UnNWgKs2o7tyB9+o9qpXq1d5PJPmur5tv/gLiuM5E59eNy+vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qJzOJRahOyKHHZjZtEpAM/QQC1ddL8ECMS8uTJ3r2pjPfzaN7mN8NvS0l0052lKHv69dr0iBn5mmQEopnaDYdynSo1UsBwdlHMAtWu0gQl3K6pwffsD49tni3B1OASRDlTqRvz+KOrAHk7tI1Qa70pFmqgxkKJMYie9fIg11MV4= Received: by 10.64.148.8 with SMTP id v8mr3019786qbd.1184050536994; Mon, 09 Jul 2007 23:55:36 -0700 (PDT) Received: by 10.64.210.14 with HTTP; Mon, 9 Jul 2007 23:55:36 -0700 (PDT) Message-ID: Date: Tue, 10 Jul 2007 12:25:36 +0530 From: "harish raghuveer" To: dime@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Dime] Fwd: ip address reconfiguration and Host-Ip-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268424159==" Errors-To: dime-bounces@ietf.org --===============1268424159== Content-Type: multipart/alternative; boundary="----=_Part_75307_13545266.1184050536964" ------=_Part_75307_13545266.1184050536964 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have a couple of questions regarding the usage of Host-IP-Address AVP in the Diameter messages. Would really appreciate pointers in this regard (if this already has come up in the group). 1. Is any specific address validation procedure expected of Diameter base protocol whenever a session specific message is received? (for example, check if the session message is received from a known address of the peer etc.,). The base protocol spec is not very clear about this. 2. If validation is not expected, what is the utility of this AVP in CER/CEA messages? 3. If validation is expected, how would we handle interface address reconfiguration in the scenario of SCTP? My understanding is that SCTP is expected to work in this case, but if peer Diameter application is not informed wont it fail (because the message may be originating at a new IP address and my validations fail)? thanks and regards, Harish R Prabhu ------=_Part_75307_13545266.1184050536964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I have a couple of questions regarding the usage of Host-IP-Address AVP in the Diameter messages. Would really appreciate pointers in this regard (if this already has come up in the group).

1. Is any specific address validation procedure expected of Diameter base protocol whenever a session specific message is received? (for example, check if the session message is received from a known address of the peer etc.,). The base protocol spec is not very clear about this.

2. If validation is not expected, what is the utility of this AVP in CER/CEA messages?

3. If validation is expected, how would we handle interface address reconfiguration in the scenario of SCTP? My understanding is that SCTP is expected to work in this case, but if peer Diameter application is not informed wont it fail (because the message may be originating at a new IP address and my validations fail)?

thanks and regards,
Harish R Prabhu

------=_Part_75307_13545266.1184050536964-- --===============1268424159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1268424159==-- From dime-bounces@ietf.org Tue Jul 10 03:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8A2i-0007EP-Pg; Tue, 10 Jul 2007 03:21:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8A2e-0007E8-8K for dime@ietf.org; Tue, 10 Jul 2007 03:21:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8A2d-0004dy-Ve for dime@ietf.org; Tue, 10 Jul 2007 03:21:48 -0400 Received: (qmail invoked by alias); 10 Jul 2007 07:21:15 -0000 Received: from p54985C02.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.92.2] by mail.gmx.net (mp045) with SMTP; 10 Jul 2007 09:21:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZgpthhhYZQu/9P2+XhmtI2IZBucP98vj0lypE0R CUbMk4LAWuiljb Message-ID: <46933368.4000701@gmx.net> Date: Tue, 10 Jul 2007 09:21:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Dime] Tentative Agenda for DIME meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here is the first try: http://www3.ietf.org/proceedings/07jul/agenda/dime.txt I need feedback regarding the time estimate for each presentation and what items are missing. What about auditing and the MIBs? Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 04:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BKH-0006ku-TZ; Tue, 10 Jul 2007 04:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BKH-0006kp-D7 for dime@ietf.org; Tue, 10 Jul 2007 04:44:05 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8BKA-0004lp-NQ for dime@ietf.org; Tue, 10 Jul 2007 04:44:05 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY009Q3G7R43@szxga01-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 16:43:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY007HOG7RG3@szxga01-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 16:43:03 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKY003SZG7QOF@szxml03-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 16:43:03 +0800 (CST) Date: Tue, 10 Jul 2007 16:43:02 +0800 From: Tina TSOU Subject: Re: [Dime] Tentative Agenda for DIME meeting To: dime@ietf.org, Hannes Tschofenig Message-id: <002501c7c2ce$540406b0$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46933368.4000701@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes and Dave, Thanks for the agenda. Is it possible to add a couple minutes in the end to show the topic "Diameter Explicit Routing and Re-direct"? There are some discussions in the ML and an update of I-D -03 about Diameter Explicit Routing was submitted by Victor, Jouni, Tolga and I. The Re-direct topic will be provided in separate I-D. But we are going to show the technical relationships between them and the progress of discussion in ML and offline. Ciao Tina ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Tuesday, July 10, 2007 3:21 PM Subject: [Dime] Tentative Agenda for DIME meeting > Here is the first try: > http://www3.ietf.org/proceedings/07jul/agenda/dime.txt > > I need feedback regarding the time estimate for each presentation and what > items are missing. What about auditing and the MIBs? > > Ciao > Hannes & Dave > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 04:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BPL-0002R0-VK; Tue, 10 Jul 2007 04:49:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BPL-0002Og-CE for dime@ietf.org; Tue, 10 Jul 2007 04:49:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8BPK-000783-Tv for dime@ietf.org; Tue, 10 Jul 2007 04:49:19 -0400 Received: (qmail invoked by alias); 10 Jul 2007 08:49:01 -0000 Received: from p5498565A.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.86.90] by mail.gmx.net (mp001) with SMTP; 10 Jul 2007 10:49:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+MsC51wNmMXMI7vqxYUW/7pTknlvOncmX5WWSdYF BiC7w8dXXi1ICa Message-ID: <469347FA.3050806@gmx.net> Date: Tue, 10 Jul 2007 10:48:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] Tentative Agenda for DIME meeting References: <46933368.4000701@gmx.net> <002501c7c2ce$540406b0$864c460a@china.huawei.com> In-Reply-To: <002501c7c2ce$540406b0$864c460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I found one document: http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 where is the second one? How is going to present? How much time to you need? Ciao Hannes Tina TSOU wrote: > Hi Hannes and Dave, > Thanks for the agenda. > Is it possible to add a couple minutes in the end to show the topic > "Diameter Explicit Routing and Re-direct"? > There are some discussions in the ML and an update of I-D -03 about > Diameter Explicit Routing was submitted by Victor, Jouni, Tolga and I. > The Re-direct topic will be provided in separate I-D. But we are going > to show the technical relationships between them and the progress of > discussion in ML and offline. > > Ciao > Tina > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: > Sent: Tuesday, July 10, 2007 3:21 PM > Subject: [Dime] Tentative Agenda for DIME meeting > > >> Here is the first try: >> http://www3.ietf.org/proceedings/07jul/agenda/dime.txt >> >> I need feedback regarding the time estimate for each presentation and >> what items are missing. What about auditing and the MIBs? >> >> Ciao >> Hannes & Dave >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 04:51:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BRe-00054a-7I; Tue, 10 Jul 2007 04:51:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BRc-0004xf-Nr for dime@ietf.org; Tue, 10 Jul 2007 04:51:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8BRc-0007Bq-AN for dime@ietf.org; Tue, 10 Jul 2007 04:51:40 -0400 Received: (qmail invoked by alias); 10 Jul 2007 08:51:22 -0000 Received: from p5498565A.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.86.90] by mail.gmx.net (mp003) with SMTP; 10 Jul 2007 10:51:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/N7cwYccnNIbp9subiYqfzNtsD5/Z5uKJ1c7lkIH UmRTZh+Wwly+G9 Message-ID: <46934887.4050709@gmx.net> Date: Tue, 10 Jul 2007 10:51:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] Tentative Agenda for DIME meeting References: <46933368.4000701@gmx.net> <002501c7c2ce$540406b0$864c460a@china.huawei.com> <469347FA.3050806@gmx.net> In-Reply-To: <469347FA.3050806@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Fix: Who is going to give the presentation? How much time do you need? Hannes Tschofenig wrote: > I found one document: > http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 > where is the second one? > > How is going to present? > How much time to you need? > > Ciao > Hannes > > Tina TSOU wrote: >> Hi Hannes and Dave, >> Thanks for the agenda. >> Is it possible to add a couple minutes in the end to show the topic >> "Diameter Explicit Routing and Re-direct"? >> There are some discussions in the ML and an update of I-D -03 about >> Diameter Explicit Routing was submitted by Victor, Jouni, Tolga and >> I. The Re-direct topic will be provided in separate I-D. But we are >> going to show the technical relationships between them and the >> progress of discussion in ML and offline. >> >> Ciao >> Tina >> >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: >> Sent: Tuesday, July 10, 2007 3:21 PM >> Subject: [Dime] Tentative Agenda for DIME meeting >> >> >>> Here is the first try: >>> http://www3.ietf.org/proceedings/07jul/agenda/dime.txt >>> >>> I need feedback regarding the time estimate for each presentation >>> and what items are missing. What about auditing and the MIBs? >>> >>> Ciao >>> Hannes & Dave >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 05:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Bjr-0002w6-2l; Tue, 10 Jul 2007 05:10:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Bjo-0002nB-De for dime@ietf.org; Tue, 10 Jul 2007 05:10:29 -0400 Received: from in-smtp.ccpu.com ([61.95.244.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Bjn-0007ce-Gx for dime@ietf.org; Tue, 10 Jul 2007 05:10:28 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 232FCB3EA2 for ; Tue, 10 Jul 2007 14:35:43 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id EA38CB3EA8 for ; Tue, 10 Jul 2007 14:35:42 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jul 2007 14:38:45 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F00187591B@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQ== From: "Soji VP" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [Dime] Backward Capability Propagation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136535231==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2136535231== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2D1.EBC8A25D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C2D1.EBC8A25D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Friends, =20 Just give a thought of having backward capability propagation feature while exchanging capability negotiation with the peers (b/w a node and a relay node). As per current definitions a Diameter relay must advertise its relay application id "0xffffffff" (also any application id relay node is supporting) with its peers.=20 But when a node is sending CER to a relay to get it's capability, relay can always advertise union of application id's of all of its peers (except the node which sends CER) in CEA. BCP shall be applied between relays also (if relay chain exists). This backward propagation will help a diameter node to ensure if it's useful to send request or response via this particular relay and send error message without sending message to relay if it's any of the peer or its subsequent relay's doesn't support the application id. This will make a node to take decision of sending messages much earlier (by caching the capability of path to a known level).=20 =20 I'm new to dime and not sure if this is already been thought of. Ignore in that case else let's float some comments. =20 Thanks & Rgds, --soj =20 =20 =20 ------_=_NextPart_001_01C7C2D1.EBC8A25D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Friends,

 

Just give a thought of having backward capability propagation feature while exchanging capability negotiation with the = peers (b/w a node and a relay node).

As per current definitions =
a Diameter relay must advertise its relay application id =
“0xffffffff” (also any application id =
relay node is supporting) with its peers. =

But when a node is sending =
CER to a relay to get it’s capability, relay can always advertise =
union of application id’s of all of its peers (except the node =
which sends CER) in CEA. BCP shall be applied between relays also (if =
relay chain exists).
This backward propagation =
will help a diameter node to ensure if it’s useful to send request =
or response via this particular relay and send error message without =
sending message to relay if it’s any of the peer or its subsequent =
relay’s doesn’t support the application =
id.
This will make a node to =
take decision of sending messages much earlier (by caching the =
capability of path to a known level). =

 
I’m new to dime and =
not sure if this is already been thought of. Ignore in that case else =
let’s float some =
comments.
 
Thanks & =
Rgds,
--soj

 

 

 

------_=_NextPart_001_01C7C2D1.EBC8A25D-- --===============2136535231== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2136535231==-- From dime-bounces@ietf.org Tue Jul 10 05:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CLA-0000cA-Se; Tue, 10 Jul 2007 05:49:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CL9-0000bx-MF for dime@ietf.org; Tue, 10 Jul 2007 05:49:03 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8CKr-000057-Ov for dime@ietf.org; Tue, 10 Jul 2007 05:49:03 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 9D57A37CF73; Tue, 10 Jul 2007 14:52:29 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 3E4F237CF97; Tue, 10 Jul 2007 14:29:33 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 14:34:44 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jul 2007 14:33:07 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601C6499E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. the IPSEC Usage section. Thread-Index: AcfC0SG2B+zFTAgPTUCp2AOVU6CDmQ== From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 10 Jul 2007 09:04:44.0881 (UTC) FILETIME=[5BE18C10:01C7C2D1] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.7852 TC:1F TRN:50 TV:3.6.1039(15288.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Subject: [Dime] Reg. the IPSEC Usage section. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0509137112==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0509137112== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2D1.2BF82014" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C2D1.2BF82014 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I was just going through the draft-ietf-dime-rfc3588bis-04 I find that the IPSEC Usage (Section 13.1 in the RFC 3588) has been removed in the new bis. Is it intentionally removed? If so please let me know the reason. Thx -Arun =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7C2D1.2BF82014 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Victor,

         I was= just going through the draft-ietf-dime-rfc3588bis-04 I find that the IPSEC Usage= (Section 13.1 in the RFC 3588) has been removed in the new bis.  Is it= intentionally removed?  If so please let me know the= reason.

Thx

-Arun

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7C2D1.2BF82014-- --===============0509137112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0509137112==-- From dime-bounces@ietf.org Tue Jul 10 06:24:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CtL-000151-Fa; Tue, 10 Jul 2007 06:24:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CtK-00014v-BL for dime@ietf.org; Tue, 10 Jul 2007 06:24:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8CtJ-0000yG-Rc for dime@ietf.org; Tue, 10 Jul 2007 06:24:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY00DNFKSYBP@szxga01-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 18:22:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY002T0KSYDZ@szxga01-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 18:22:10 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKY007SYKSXXK@szxml03-in.huawei.com> for dime@ietf.org; Tue, 10 Jul 2007 18:22:10 +0800 (CST) Date: Tue, 10 Jul 2007 18:22:09 +0800 From: Tina TSOU Subject: Re: [Dime] Tentative Agenda for DIME meeting To: Hannes Tschofenig Message-id: <001501c7c2dc$2cab3580$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46933368.4000701@gmx.net> <002501c7c2ce$540406b0$864c460a@china.huawei.com> <469347FA.3050806@gmx.net> <46934887.4050709@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ----- Original Message ----- From: "Hannes Tschofenig" To: "Tina TSOU" Cc: Sent: Tuesday, July 10, 2007 4:51 PM Subject: Re: [Dime] Tentative Agenda for DIME meeting > Fix: > > Who is going to give the presentation? [Tina: Tolga will be happy to give the presentation, I guess:)] > How much time do you need? [Tina: 5~10 minutes.] > > Hannes Tschofenig wrote: >> I found one document: >> http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 >> where is the second one? [Tina: we don't make the second one in time, based on the discussion is not crystal yet.] >> >> How is going to present? [Tina: we will send u the slides later.] >> How much time to you need? >> >> Ciao >> Hannes >> >> Tina TSOU wrote: >>> Hi Hannes and Dave, >>> Thanks for the agenda. >>> Is it possible to add a couple minutes in the end to show the topic >>> "Diameter Explicit Routing and Re-direct"? >>> There are some discussions in the ML and an update of I-D -03 about >>> Diameter Explicit Routing was submitted by Victor, Jouni, Tolga and I. >>> The Re-direct topic will be provided in separate I-D. But we are going >>> to show the technical relationships between them and the progress of >>> discussion in ML and offline. >>> >>> Ciao >>> Tina >>> >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: >>> Sent: Tuesday, July 10, 2007 3:21 PM >>> Subject: [Dime] Tentative Agenda for DIME meeting >>> >>> >>>> Here is the first try: >>>> http://www3.ietf.org/proceedings/07jul/agenda/dime.txt >>>> >>>> I need feedback regarding the time estimate for each presentation and >>>> what items are missing. What about auditing and the MIBs? >>>> >>>> Ciao >>>> Hannes & Dave >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 07:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8EJe-00067z-77; Tue, 10 Jul 2007 07:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8EJd-00067u-2L for dime@ietf.org; Tue, 10 Jul 2007 07:55:37 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8EJc-0001nT-TW for dime@ietf.org; Tue, 10 Jul 2007 07:55:37 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6ABtY5N031662; Tue, 10 Jul 2007 07:55:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Tentative Agenda for DIME meeting Date: Tue, 10 Jul 2007 07:55:34 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188045@sonusmail04.sonusnet.com> In-Reply-To: <46933368.4000701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Tentative Agenda for DIME meeting Thread-Index: AcfCwwPOxL4A5AqNQDuC2zw8TPRh0AAJd8CA References: <46933368.4000701@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, If possible, I would like to present the congestion draft: http://tools.ietf.org/wg/dime/draft-asveren-dime-cong-02.txt I probably would need ~15 minutes.=20 Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, July 10, 2007 3:21 AM > To: dime@ietf.org > Subject: [Dime] Tentative Agenda for DIME meeting >=20 > Here is the first try: > http://www3.ietf.org/proceedings/07jul/agenda/dime.txt >=20 > I need feedback regarding the time estimate for each presentation and > what items are missing. What about auditing and the MIBs? >=20 > Ciao > Hannes & Dave >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 08:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Esa-00041M-Ty; Tue, 10 Jul 2007 08:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Esa-00041H-0o for dime@ietf.org; Tue, 10 Jul 2007 08:31:44 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8EsZ-0002ve-Kr for dime@ietf.org; Tue, 10 Jul 2007 08:31:44 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6ACVPfZ030463; Tue, 10 Jul 2007 08:31:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Backward Capability Propagation Date: Tue, 10 Jul 2007 08:31:25 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188048@sonusmail04.sonusnet.com> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F00187591B@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQAGo+Fg References: <22F058C3ED9D784E90CE473F2A9847F00187591B@in-exchange> From: "Asveren, Tolga" To: "Soji VP" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Soj, You should be able to do this already, i.e. advertising App-Id only for the applications for which the node is able to provide relaying. Thanks, Tolga ________________________________________ From: Soji VP [mailto:soji.vp@ccpu.com]=20 Sent: Tuesday, July 10, 2007 5:09 AM To: dime@ietf.org Subject: [Dime] Backward Capability Propagation Hi Friends, Just give a thought of having backward capability propagation feature while exchanging capability negotiation with the peers (b/w a node and a relay node). As per current definitions a Diameter relay must advertise its relay application id "0xffffffff" (also any application id relay node is supporting) with its peers.=20 But when a node is sending CER to a relay to get it's capability, relay can always advertise union of application id's of all of its peers (except the node which sends CER) in CEA. BCP shall be applied between relays also (if relay chain exists). This backward propagation will help a diameter node to ensure if it's useful to send request or response via this particular relay and send error message without sending message to relay if it's any of the peer or its subsequent relay's doesn't support the application id. This will make a node to take decision of sending messages much earlier (by caching the capability of path to a known level).=20 I'm new to dime and not sure if this is already been thought of. Ignore in that case else let's float some comments. Thanks & Rgds, --soj _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 08:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Etv-0006xT-2e; Tue, 10 Jul 2007 08:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ett-0006t6-Ax for dime@ietf.org; Tue, 10 Jul 2007 08:33:05 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Ett-0002wb-4d for dime@ietf.org; Tue, 10 Jul 2007 08:33:05 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6ACVl0m044632; Tue, 10 Jul 2007 08:31:47 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46937C33.7060200@tari.toshiba.com> Date: Tue, 10 Jul 2007 08:31:47 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" References: <66E8AEE9980BB44CA5FCAD39EBA56AC601C6499E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601C6499E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: dime@ietf.org Subject: [Dime] Re: Reg. the IPSEC Usage section. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Yes this has been removed intentionally. The idea is to simplify the spec. Since IPSec can be used independent of diameter protocol (i.e.; diameter protocol itself does not have internal working dependency on it), the IPsec usage section can be safely removed without harming the protocol. -- victor > Hi Victor, > > I was just going through the draft-ietf-dime-rfc3588bis-04 I > find that the IPSEC Usage (Section 13.1 in the RFC 3588) has been > removed in the new bis. Is it intentionally removed? If so please > let me know the reason. > > Thx > > -Arun > > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 09:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Fzz-00014w-Kf; Tue, 10 Jul 2007 09:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Fzy-00014r-Mg for dime@ietf.org; Tue, 10 Jul 2007 09:43:26 -0400 Received: from in-smtp.ccpu.com ([61.95.244.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Fzx-00050e-R7 for dime@ietf.org; Tue, 10 Jul 2007 09:43:26 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id EFB1BB3E8B for ; Tue, 10 Jul 2007 19:09:57 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id 95A11B3E8A for ; Tue, 10 Jul 2007 19:09:54 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: Reg. the IPSEC Usage section. Date: Tue, 10 Jul 2007 19:13:16 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F001875A14@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Reg. the IPSEC Usage section. Thread-Index: AcfC7n4MPWgvKLqgTUyHd4Dwq7y6PwABubpQ From: "Soji VP" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, I've a follow-up question on this. Consider a scenario where node A and node B is trying to exchange CER/A and both of them doesn't support TLS. Node A support IpSec but node B doesn't.=20 In this case, what would be the inband-security-id avp in CER/A?=20 Again, what would be the inband-security-id AVP in CER/A if both of them support IpSec? Can I assume NO_INBAND_SECURITY only if both of them doesn't support TLS and IPSec?=20 As security is mandatory for Diameter (sec 2.2), transmission should be able to proceed further with IPSec support, eventhough nodes doesn't support TLS. But how can I exchange security capability with inband-security-id avp? Thanks, -Soj. -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Tuesday, July 10, 2007 6:02 PM To: Arun Santhanam, TLS-Chennai Cc: dime@ietf.org Subject: [Dime] Re: Reg. the IPSEC Usage section. Yes this has been removed intentionally. The idea is to simplify the=20 spec. Since IPSec can be used independent of diameter protocol (i.e.;=20 diameter protocol itself does not have internal working dependency on=20 it), the IPsec usage section can be safely removed without harming the=20 protocol. -- victor > Hi Victor, > > I was just going through the draft-ietf-dime-rfc3588bis-04 I=20 > find that the IPSEC Usage (Section 13.1 in the RFC 3588) has been=20 > removed in the new bis. Is it intentionally removed? If so please=20 > let me know the reason. > > Thx > > -Arun > > =20 > > DISCLAIMER: > ------------------------------------------------------------------------ ----------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily=20 > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of > this message without the prior written consent of the author of this=20 > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender=20 > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ------------------------------------------------------------------------ ----------------------------------------------- > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 09:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GCA-0005pz-3a; Tue, 10 Jul 2007 09:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GC8-0005po-MR for dime@ietf.org; Tue, 10 Jul 2007 09:56:00 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8GC8-0005Lt-GU for dime@ietf.org; Tue, 10 Jul 2007 09:56:00 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6ADso8c045098; Tue, 10 Jul 2007 09:54:50 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46938FAA.4040004@tari.toshiba.com> Date: Tue, 10 Jul 2007 09:54:50 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Soji VP Subject: Re: [Dime] Re: Reg. the IPSEC Usage section. References: <22F058C3ED9D784E90CE473F2A9847F001875A14@in-exchange> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F001875A14@in-exchange> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Soji, > I've a follow-up question on this. Consider a scenario where node A and > node B is trying to exchange CER/A and both of them doesn't support TLS. > Node A support IpSec but node B doesn't. > In this case, what would be the inband-security-id avp in CER/A? > > Again, what would be the inband-security-id AVP in CER/A if both of them > support IpSec? > > Can I assume NO_INBAND_SECURITY only if both of them doesn't support TLS > and IPSec? > You can check-out sec 13 of bis-05. Let me know if the text is still unclear. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 10:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ge6-0007pg-6X; Tue, 10 Jul 2007 10:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ge4-0007pU-Iu for dime@ietf.org; Tue, 10 Jul 2007 10:24:52 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Ge4-0006AG-Ai for dime@ietf.org; Tue, 10 Jul 2007 10:24:52 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6AENxBh045274; Tue, 10 Jul 2007 10:23:59 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46939680.3090108@tari.toshiba.com> Date: Tue, 10 Jul 2007 10:24:00 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Victor Fajardo References: <4666A15A.30305@tari.toshiba.com> In-Reply-To: <4666A15A.30305@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org Subject: [Dime] rfc3588bis document update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The following is a continuation of 3588bis change summary below. The latest version of rfc3588bis is now available: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-05.txt The deltas between 04 and 05 versions are as follows: * 05 includes proposals for 20, 56, 57 * Open issues: 35, 39, 55, 58 #35 and #39 are still open from previous revs. We probably need to get this resolved soon. Suggestions on how to do this is described below. #55 A change in command code allocation process. See editor's note in the bis document #58 Possible error in IANA registration. Should be easily fixed. Diff's are available at: * between 05 from 04: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-05-from-4.diff.html Previous diffs and delta histories are below. regards, victor > Hi all, > > The latest version of rfc3588bis is now available: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt > > As a short summary, the change history of this document are as follows: > > * 00 and rfc3588 are identical > * 01 incorporates the changes proposed in > http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt > * 02 includes proposals for 32, 36, 44, 49, 41, 40, 31, 26 > * 03 includes proposals for 28, 33, 37, 38, 51, 52, 50 (partially) > * 04 includes proposals for 34, 50, 54, 53 > * Open issues remain: 35, 39 > > Suggested approaches for open issues: > > #35 - Representation/Encoding of diameter identities (FQDN's). We may > need to consult with DNS folks on how to properly support > internationalization etc for FQDN names (if needed). This is in > addition to the default ascii representation. > > #39 - How to do TLS certificate validation against peer names. We may > need to consult with security folks on how to properly support sanity > checks on certificates; i.e, use of CN, SN etc against a diameter > identity. > > For easier reading the relevant diffs are: > > * between 01 from 3588: > http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01-from-rfc3588.diff.html > > * between 02 from 01: > http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02-from-1.diff.html > > * between 03 from 02: > http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03-from-2.diff.html > > * between 04 from 03: > http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-04-from-3.diff.html > > > The issue tracker can be found in: > http://www.tschofenig.priv.at:8080/diameter-interop/index > > regards, > victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 10:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Gwt-0005Ww-7o; Tue, 10 Jul 2007 10:44:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Gws-0005Wr-QC for dime@ietf.org; Tue, 10 Jul 2007 10:44:18 -0400 Received: from 66.88.142.84.ptr.us.xo.net ([66.88.142.84] helo=sd-smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Gws-0006ey-7x for dime@ietf.org; Tue, 10 Jul 2007 10:44:18 -0400 Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 8E1CE184A28; Tue, 10 Jul 2007 07:44:17 -0700 (PDT) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 7691F184A1E; Tue, 10 Jul 2007 07:44:17 -0700 (PDT) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 07:44:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: Reg. the IPSEC Usage section. Date: Tue, 10 Jul 2007 20:14:12 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F001875A31@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Reg. the IPSEC Usage section. Thread-Index: AcfC+mll94vgJnXfTz2yp75rwQDlGQAAVnTw From: "Soji VP" To: "Victor Fajardo" X-OriginalArrivalTime: 10 Jul 2007 14:44:16.0662 (UTC) FILETIME=[CA68A360:01C7C300] X-TM-AS-Product-Ver: IMSS-7.0.0.1640-3.8.0.1026-15288.002 X-TM-AS-Result: No--9.583-5.0-31-1 X-imss-scan-details: No--9.583-5.0-31-1;No--9.583-5.0-31-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Its ok, but need one more clarification. Are we assuming default support of IpSec by a node?. i.e if node A support both TLS and IPSec and it set value of inband-security-id to "TLS" in CER to its peer node B. But node B supports only IPSec and should it send CEA with result code DIAMETER_NO_COMMON_SECURITY and disconnect the connection (As per section 5.3)? or should it send CEA with NO_INBAND_SECURITY for inband-security-id AVP? So what's action node A ideally should be taking? Considering the fact that, they can still continue transaction further as both of them support IPSec. Thanks=20 -Soj -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Tuesday, July 10, 2007 7:25 PM To: Soji VP Cc: dime@ietf.org Subject: Re: [Dime] Re: Reg. the IPSEC Usage section. Hi Soji, > I've a follow-up question on this. Consider a scenario where node A and > node B is trying to exchange CER/A and both of them doesn't support TLS. > Node A support IpSec but node B doesn't.=20 > In this case, what would be the inband-security-id avp in CER/A?=20 > > Again, what would be the inband-security-id AVP in CER/A if both of them > support IpSec? > > Can I assume NO_INBAND_SECURITY only if both of them doesn't support TLS > and IPSec?=20 > =20 You can check-out sec 13 of bis-05. Let me know if the text is still=20 unclear. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 11:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HCI-0003ZY-Ew; Tue, 10 Jul 2007 11:00:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HCH-0003ZP-AO for dime@ietf.org; Tue, 10 Jul 2007 11:00:13 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8HC2-0007KB-2L for dime@ietf.org; Tue, 10 Jul 2007 11:00:13 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6AEx1ho045463; Tue, 10 Jul 2007 10:59:01 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46939EB5.3060908@tari.toshiba.com> Date: Tue, 10 Jul 2007 10:59:01 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Soji VP Subject: Re: [Dime] Re: Reg. the IPSEC Usage section. References: <22F058C3ED9D784E90CE473F2A9847F001875A31@in-exchange> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F001875A31@in-exchange> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline: > Its ok, but need one more clarification. Are we assuming default support > of IpSec by a node?. I think the idea of simplifying the spec is so that the protocol internals does not interact with IPsec. Hence, inband security deals only with TLS and is oblivious to IPsec. I think a diameter implementation should not force itself on trying to represent IPsec anywhere. IPsec is more of a deployment policy. > i.e if node A support both TLS and IPSec and it set > value of inband-security-id to "TLS" in CER to its peer node B. But node > B supports only IPSec and should it send CEA with result code > DIAMETER_NO_COMMON_SECURITY and disconnect the connection (As per > section 5.3)? Yes. > or should it send CEA with NO_INBAND_SECURITY for > inband-security-id AVP? Since 5.3 already defines a behavior then we should not assume this. hope this helps, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 11:18:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HUM-0007wI-Ia; Tue, 10 Jul 2007 11:18:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HUL-0007vq-EN for dime@ietf.org; Tue, 10 Jul 2007 11:18:53 -0400 Received: from in-smtp.ccpu.com ([61.95.244.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8HTr-0007nx-4o for dime@ietf.org; Tue, 10 Jul 2007 11:18:53 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 45CBAB3E98; Tue, 10 Jul 2007 20:44:13 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id EF8D9B3E8B; Tue, 10 Jul 2007 20:44:09 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Backward Capability Propagation Date: Tue, 10 Jul 2007 20:47:13 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F001875A36@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQAGo+FgAAVB1/A= From: "Soji VP" To: "Asveren, Tolga" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, When we do a CER/A exchange, as per current RFC 3588 protocol, node advertises application ids supported by that node only. It will not consider supported application id's of its subsequent peers. CER/A definition specifies capability negotiation confined between to nodes and should consider the supported application of the particular node only. i.e=20 CER/A exchanged between node A and node B should bother only supported application id's in node A and node B. But as per my understanding from RFC (Sec 5.3 para 3), a relay will advertise application id's supported by that relay node only (in addition to 0xffffffff).=20 Obviously we can do this by advertising App-Id only for the applications for which the node is able to provide relaying. But I think, it'd be better if we specify so in nex rev. Please correct me if I'm wrong. Thanks -Soj. Note that receiving a CER or CEA from a peer advertising itself as a Relay (see Section 2.4) MUST be interpreted as having common applications with the peer. -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Tuesday, July 10, 2007 6:01 PM To: Soji VP; dime@ietf.org Subject: RE: [Dime] Backward Capability Propagation Soj, You should be able to do this already, i.e. advertising App-Id only for the applications for which the node is able to provide relaying. Thanks, Tolga ________________________________________ From: Soji VP [mailto:soji.vp@ccpu.com]=20 Sent: Tuesday, July 10, 2007 5:09 AM To: dime@ietf.org Subject: [Dime] Backward Capability Propagation Hi Friends, Just give a thought of having backward capability propagation feature while exchanging capability negotiation with the peers (b/w a node and a relay node). As per current definitions a Diameter relay must advertise its relay application id "0xffffffff" (also any application id relay node is supporting) with its peers.=20 But when a node is sending CER to a relay to get it's capability, relay can always advertise union of application id's of all of its peers (except the node which sends CER) in CEA. BCP shall be applied between relays also (if relay chain exists). This backward propagation will help a diameter node to ensure if it's useful to send request or response via this particular relay and send error message without sending message to relay if it's any of the peer or its subsequent relay's doesn't support the application id. This will make a node to take decision of sending messages much earlier (by caching the capability of path to a known level).=20 I'm new to dime and not sure if this is already been thought of. Ignore in that case else let's float some comments. Thanks & Rgds, --soj _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 13:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JHU-0007zl-78; Tue, 10 Jul 2007 13:13:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JHT-0007vu-9b for dime@ietf.org; Tue, 10 Jul 2007 13:13:43 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8JHQ-0002Eh-9H for dime@ietf.org; Tue, 10 Jul 2007 13:13:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2007 10:13:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADpbk0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="7641575:sNHT12752868" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6AHDdnZ022209; Tue, 10 Jul 2007 10:13:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6AHDRXH014671; Tue, 10 Jul 2007 17:13:27 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 10:13:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Backward Capability Propagation Date: Tue, 10 Jul 2007 10:13:22 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504496FF3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F001875A36@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQAGo+FgAAVB1/AABMGyYA== References: <22F058C3ED9D784E90CE473F2A9847F001875A36@in-exchange> From: "Glen Zorn \(gwz\)" To: "Soji VP" X-OriginalArrivalTime: 10 Jul 2007 17:13:27.0367 (UTC) FILETIME=[A171D570:01C7C315] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=594; t=1184087619; x=1184951619; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Backward=20Capability=20Propagation |Sender:=20; bh=JvJhBE3MJtt8Jo0JMzn3QxYq0hnjI2xQffpVXH2Oiow=; b=Mzp3B/gPW82+4woH+DCJAd/Xqs2NXRpK6MhYC+QALSeCln/K4whhVwzdMmVA8WKAIaTX+fTI DVQegQOFtE5vpbShCaER+8mJyn+/aayIvCphF7ROfbLdT17DwjKTpUfU; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Soji VP allegedly scribbled on Tuesday, July 10, 2007 8:17 AM: ... > Obviously we can do this by advertising App-Id only for the > applications for which the node is able to provide relaying.=20 What happens if the one of the peers the relay is advertising on behalf of goes down, or one or more links goes down? What you are suggesting is to base forwarding decisions upon a second-hand snapshot of network connectivity that may be inaccurate as soon as it is propagated. Diameter peers advertise only their own capabilities for a reason... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 10 16:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mnj-0004K2-GG; Tue, 10 Jul 2007 16:59:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mni-0004J2-3Z for dime@ietf.org; Tue, 10 Jul 2007 16:59:14 -0400 Received: from male.eservglobal.co.nz ([203.118.128.140] helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Mnh-0005XU-80 for dime@ietf.org; Tue, 10 Jul 2007 16:59:14 -0400 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6AKxB0m000573 for ; Wed, 11 Jul 2007 08:59:12 +1200 Message-ID: <4693F31F.2090701@eservglobal.co.nz> Date: Wed, 11 Jul 2007 08:59:11 +1200 From: Ralph Loader User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.3/3627/Wed Jul 11 08:21:16 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [Dime] Several rfc 3588 issues. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Following is a list of issues I've come across in rfc3588. I think all are current in the 3588bis-05 draft. Many are cases where taking the text at face value does not match what appears to be intended. A few actually concern how the protocol operates. Apologies for any due to me not RTFM well enough. Cheers, Ralph. 1. 'Home Server' in section 1.3, is defined with 'See Diameter Server'. But looking at the definition of 'Diameter Server', I do not see any indication of what a 'Home Server' is. Is the intention that 'Home Server' is a synonym for 'Diameter Server', or is there some other meaning? (E.g., a 'Diameter Server' serving a 'Home Realm'). 2. If multiple Inband-Security-Ids are shared in the CER/CEA exchange, the spec does not say how to choose which one to use. 3. "minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or DIAMETER_MISSING_AVP) has several possible interpretations: Minimum required for the basic datatype? Minimum required for the derived datatype? Minimum required for successful processing? If it's minimum required for the datatype, and the datatype is Grouped, is the minimum length the minimum for any grouped AVP (i.e., empty payload) or the minimum for this particular AVP (in which case zero-filling may generate a corrupt AVP)? 4. Re DIAMETER_INVALID_AVP_LENGTH again, if the length received is less than 12 but the AVP is vendor-specific, what should be put in the Vendor-Id when creating the Failed-AVP? 5. The (defined under 7.2. Error Bit) has just [Proxy-Info] whereas everything else has *[Proxy-Info]. Presumably, *[Proxy-Info] is intended. Also, ironically does not include [Error-Message], and [Failed-AVP], unlike all other answers. Although the inclusion of *[AVP] makes their omission formally harmless, it would seem sensible to include them. 6. The Vendor-Specific-Application-Id definition in rfc3588bis-draft-05 does not use the grammar that according to that document MUST be used. Assuming that the intention is that one and only one of Auth-Application-Id or Acct-Application-Id is present, the best thing to do would be to make both optional in the grammar and include the additional constraint in the text that exactly one MUST be present. 7. I don't think that the text "AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included." is really what is intended. I assume that the absense of *[AVP] in a message definition means that unlisted AVPs may not be added arbitrarily to that message, but I can see no text by which that is 'explicitly excluded'. The current text makes the presence or absence of *[AVP] in a message definition meaningless. 8. Even ignoring the previous item, the meaning of *[AVP] (or *{AVP}) in a message (or grouped-avp) format definition is unclear, and RFC 3588 contradicts itself. The description in 3.2 is ; The string "AVP" stands for *any* arbitrary ; AVP Name, which does not conflict with the ; required or fixed position AVPs defined in ; the command code definition. According to this wording e.g., (a) Product-Name is allowed in Abort-Session-Request, (b) multiple occurrences of User-Name are allowed in Abort-Session-Request. Both of these are contradicted in section 10. Taking section 10 a face value: (a) Product-Name must not occur in an Abort-Session-Request, according to section 10, despite the presence of *[AVP] in the message format, and (b) User-Name must occur at most once in an ASR. My guess as to the actual intent of the spec, is that: The string "AVP" stands for *any* arbitrary AVP Name, not otherwise listed in that command code grammar. [This allows case (a) above but not case (b)] The wording of section 10 then needs adjustment, to note that it does not cover AVPs allowed because of *[AVP] in the grammar. It would also make sense to me to remove all MUSTs/MAYs from section 10, and instead to state that it is a non-normative summary of what is implied in the command code definitions. 9. The section 10 table lists Result-Code as not being present in ASA, contradicting the definition of that command. 10. The section 10 wording "Note that AVPs that can only be present within a Grouped AVP are not represented in this table" is imprecise. E.g., it could be taken to cover User-Name within a Failed-AVP, on the grounds that it is not the case that User-Name "can only be present within a Grouped AVP". A better wording would be "Note that AVPs occurrences contained within a Grouped AVP are not represented in this table". 11. If a TCP connection is established with a 4-way handshake (i.e., both ends send SYNs simultaneously), then both ends will think they are the initiator for CER/CEA exchange, and the exchange then fails. Is it intended to not allow this? The wording A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and strongly suggests that also a node may initiate connections with the source port being the one on which it accepts incoming connections (i.e., 3868), in which case 4-way TCP handshake is a realistic possibility. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 01:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Uwd-0008Ui-A3; Wed, 11 Jul 2007 01:40:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Uwb-0008S0-Fk for dime@ietf.org; Wed, 11 Jul 2007 01:40:57 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Uwa-0006jD-39 for dime@ietf.org; Wed, 11 Jul 2007 01:40:57 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000F9J2EHFJ@szxga04-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 13:39:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000E042EG3T@szxga04-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 13:39:53 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL000LFK2ECLZ@szxml03-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 13:39:52 +0800 (CST) Date: Wed, 11 Jul 2007 11:09:48 +0530 From: Rajith R Subject: RE: [Dime] Several rfc 3588 issues. In-reply-to: <4693F31F.2090701@eservglobal.co.nz> To: 'Ralph Loader' , dime@ietf.org Message-id: <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfDNTQ2wJX7FGwtTmekboXvU2EkqQASAVvQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org >4. > >Re DIAMETER_INVALID_AVP_LENGTH again, if the length received >is less than 12 but the AVP is vendor-specific, what should be >put in the Vendor-Id when creating the Failed-AVP? In this case, how could we determine the "minimum required length"? Since we don't have the complete vendor Id, we will not know the type of the AVP. >-----Original Message----- >From: Ralph Loader [mailto:rloader@eservglobal.com] >Sent: Wednesday, July 11, 2007 2:29 AM >To: dime@ietf.org >Subject: [Dime] Several rfc 3588 issues. > >Hi, > >Following is a list of issues I've come across in rfc3588. > >I think all are current in the 3588bis-05 draft. > >Many are cases where taking the text at face value does not >match what appears to be intended. A few actually concern how >the protocol operates. > >Apologies for any due to me not RTFM well enough. > >Cheers, >Ralph. > >1. > >'Home Server' in section 1.3, is defined with 'See Diameter >Server'. But looking at the definition of 'Diameter Server', >I do not see any indication of what a 'Home Server' is. > >Is the intention that 'Home Server' is a synonym for 'Diameter >Server', or is there some other meaning? (E.g., a 'Diameter >Server' serving a 'Home Realm'). > > >2. > >If multiple Inband-Security-Ids are shared in the CER/CEA >exchange, the spec does not say how to choose which one to use. > > >3. > >"minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or >DIAMETER_MISSING_AVP) has several possible interpretations: >Minimum required for the basic datatype? Minimum required for >the derived datatype? Minimum required for successful processing? > >If it's minimum required for the datatype, and the datatype is >Grouped, is the minimum length the minimum for any grouped AVP >(i.e., empty payload) or the minimum for this particular AVP >(in which case zero-filling may generate a corrupt AVP)? > > >4. > >Re DIAMETER_INVALID_AVP_LENGTH again, if the length received >is less than 12 but the AVP is vendor-specific, what should be >put in the Vendor-Id when creating the Failed-AVP? > > >5. > >The (defined under 7.2. Error Bit) has just >[Proxy-Info] whereas everything else has *[Proxy-Info]. >Presumably, *[Proxy-Info] is intended. > >Also, ironically does not include >[Error-Message], and [Failed-AVP], unlike all other answers. > >Although the inclusion of *[AVP] makes their omission formally >harmless, it would seem sensible to include them. > > >6. > >The Vendor-Specific-Application-Id definition in >rfc3588bis-draft-05 does not use the grammar that according to >that document MUST be used. > >Assuming that the intention is that one and only one of >Auth-Application-Id or Acct-Application-Id is present, the >best thing to do would be to make both optional in the grammar >and include the additional constraint in the text that exactly >one MUST be present. > > >7. > >I don't think that the text > > "AVPs may be added arbitrarily to Diameter messages, so long > as the required AVPs are included and AVPs that are > explicitly excluded are not included." > >is really what is intended. > >I assume that the absense of *[AVP] in a message definition >means that unlisted AVPs may not be added arbitrarily to that >message, but I can see no text by which that is 'explicitly excluded'. > >The current text makes the presence or absence of *[AVP] in a >message definition meaningless. > > >8. > >Even ignoring the previous item, the meaning of *[AVP] (or >*{AVP}) in a message (or grouped-avp) format definition is >unclear, and RFC 3588 contradicts itself. > >The description in 3.2 is > > ; The string "AVP" stands for *any* arbitrary > ; AVP Name, which does not conflict with the > ; required or fixed position AVPs defined in > ; the command code definition. > >According to this wording e.g., (a) Product-Name is allowed in >Abort-Session-Request, (b) multiple occurrences of User-Name >are allowed in Abort-Session-Request. Both of these are >contradicted in section 10. > >Taking section 10 a face value: (a) Product-Name must not >occur in an Abort-Session-Request, according to section 10, >despite the presence of *[AVP] in the message format, and (b) >User-Name must occur at most once in an ASR. > >My guess as to the actual intent of the spec, is that: > > The string "AVP" stands for *any* arbitrary AVP Name, > not otherwise listed in that command code grammar. > >[This allows case (a) above but not case (b)] > >The wording of section 10 then needs adjustment, to note that >it does not cover AVPs allowed because of *[AVP] in the grammar. > >It would also make sense to me to remove all MUSTs/MAYs from >section 10, and instead to state that it is a non-normative >summary of what is implied in the command code definitions. > > >9. > >The section 10 table lists Result-Code as not being present in >ASA, contradicting the definition of that command. > > >10. > >The section 10 wording > > "Note that AVPs that can only be present within a Grouped AVP > are not represented in this table" > >is imprecise. E.g., it could be taken to cover User-Name >within a Failed-AVP, on the grounds that it is not the case >that User-Name "can only be present within a Grouped AVP". > >A better wording would be "Note that AVPs occurrences >contained within a Grouped AVP are not represented in this table". > > >11. > >If a TCP connection is established with a 4-way handshake >(i.e., both ends send SYNs simultaneously), then both ends >will think they are the initiator for CER/CEA exchange, and >the exchange then fails. Is it intended to not allow this? >The wording > > A Diameter node MAY initiate connections from a source port > other than the one that it declares it accepts incoming > connections on, and > >strongly suggests that also a node may initiate connections >with the source port being the one on which it accepts >incoming connections (i.e., 3868), in which case 4-way TCP >handshake is a realistic possibility. > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 03:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WJA-0006iN-50; Wed, 11 Jul 2007 03:08:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WJ9-0006fH-0Y for dime@ietf.org; Wed, 11 Jul 2007 03:08:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8WIv-0008I7-PI for dime@ietf.org; Wed, 11 Jul 2007 03:08:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Jul 2007 00:08:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAK4elEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,525,1175497200"; d="scan'208"; a="180017413:sNHT340682985" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6B784Se013164; Wed, 11 Jul 2007 00:08:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6B77uXH009762; Wed, 11 Jul 2007 07:07:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 00:07:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Backward Capability Propagation Date: Wed, 11 Jul 2007 00:07:53 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504497380@xmb-sjc-215.amer.cisco.com> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F001875B34@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQAGo+FgAAVB1/AABMGyYAAYpXLgAASDClA= References: <22F058C3ED9D784E90CE473F2A9847F001875B34@in-exchange> From: "Glen Zorn \(gwz\)" To: "Soji VP" X-OriginalArrivalTime: 11 Jul 2007 07:07:56.0404 (UTC) FILETIME=[34EA9340:01C7C38A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2016; t=1184137684; x=1185001684; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Backward=20Capability=20Propagation |Sender:=20; bh=H5efrrayF0j7AOpfXx90xuGiqIXLK1B+FU2kJGZuy8g=; b=TDRQhe6blvHr3y35PqHcQ78V/8zokqll6nhBEM2YPtqAYP4iMn+DEgmQalqRLZsJeE7JtOhR kxY60DcHim/sET3EHEjRePQItGFKZpgy1rUCx4tP/4Z+4mPvdLAPqok1; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Soji VP allegedly scribbled on Tuesday, July 10, 2007 10:20 PM: > Hi Glen, >=20 > CER/A should be confined only between peers and it should exchange > capabilities of the node. But still, when one of the peers the relay > is advertising on behalf goes down, the relay has to exchange a CER/A > with rest of the peers with its updated capability.=20 We are talking about relays, here, right? They advertise that they will relay anything they get, they specifically do not advertise on behalf of any other node. What you're suggesting seems to add a lot of complexity for little (to be generous) benefit. =20 >=20 > I agree the point that it would be inaccurate as soon as the > connectivity gets propagated, but the same situation would be > persisting now also; consider a case, where peer removed it's > supported application and a node send a message to that peer before > updated capability being negotiated to the node. In this case, little > inaccuracy exists atleast for one hop connectivity. =20 >=20 > I'd appreciate any comments on this. >=20 > Thanks, > Soj >=20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Tuesday, July 10, 2007 10:43 PM > To: Soji VP > Cc: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] Backward Capability Propagation >=20 > Soji VP allegedly scribbled on Tuesday, > July 10, 2007 8:17 AM:=20 >=20 > ... >=20 >> Obviously we can do this by advertising App-Id only for the >> applications for which the node is able to provide relaying. >=20 > What happens if the one of the peers the relay is advertising on > behalf=20 > of goes down, or one or more links goes down? What you are > suggesting=20 > is to base forwarding decisions upon a second-hand snapshot of > network connectivity that may be inaccurate as soon as it is > propagated. =20 > Diameter peers advertise only their own capabilities for a reason... >=20 > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 03:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WJd-0006mn-0f; Wed, 11 Jul 2007 03:08:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WJb-0006mi-7h for dime@ietf.org; Wed, 11 Jul 2007 03:08:47 -0400 Received: from male.eservglobal.co.nz ([203.118.128.140] helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8WJa-0008IQ-1u for dime@ietf.org; Wed, 11 Jul 2007 03:08:47 -0400 Received: from webmail.eservglobal.co.nz (www-data@localhost.localdomain [127.0.0.1]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6B784sP030344; Wed, 11 Jul 2007 19:08:04 +1200 Received: from 203.173.189.191 (SquirrelMail authenticated user rloader) by webmail.eservglobal.co.nz with HTTP; Wed, 11 Jul 2007 19:08:05 +1200 (NZST) Message-ID: <55348.203.173.189.191.1184137685.squirrel@webmail.eservglobal.co.nz> In-Reply-To: <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> References: <4693F31F.2090701@eservglobal.co.nz> <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> Date: Wed, 11 Jul 2007 19:08:05 +1200 (NZST) Subject: RE: [Dime] Several rfc 3588 issues. From: rloader@eservglobal.com To: rajithr@huawei.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.90.3/3634/Wed Jul 11 13:14:01 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org >>4. >> >>Re DIAMETER_INVALID_AVP_LENGTH again, if the length received >>is less than 12 but the AVP is vendor-specific, what should be >>put in the Vendor-Id when creating the Failed-AVP? > > In this case, how could we determine the "minimum required length"? Since > we > don't have the complete vendor Id, we will not know the type of the AVP. Good point. How about adding the following to the description of DIAMETER_INVALID_AVP_LENGTH, immediately after the current draft-05 text: "In the cases where the offending AVP code (or vendor id) is unknown to the peer, the payload [of the AVP included in the Failed-AVP] may be empty. In the cases where the offending AVP has the V-bit set but does not contain a complete vendor id, the vendor id included inside the Failed-AVP may be set to zero." Does that cover the required cases? R. > > > >>-----Original Message----- >>From: Ralph Loader [mailto:rloader@eservglobal.com] >>Sent: Wednesday, July 11, 2007 2:29 AM >>To: dime@ietf.org >>Subject: [Dime] Several rfc 3588 issues. >> >>Hi, >> >>Following is a list of issues I've come across in rfc3588. >> >>I think all are current in the 3588bis-05 draft. >> >>Many are cases where taking the text at face value does not >>match what appears to be intended. A few actually concern how >>the protocol operates. >> >>Apologies for any due to me not RTFM well enough. >> >>Cheers, >>Ralph. >> >>1. >> >>'Home Server' in section 1.3, is defined with 'See Diameter >>Server'. But looking at the definition of 'Diameter Server', >>I do not see any indication of what a 'Home Server' is. >> >>Is the intention that 'Home Server' is a synonym for 'Diameter >>Server', or is there some other meaning? (E.g., a 'Diameter >>Server' serving a 'Home Realm'). >> >> >>2. >> >>If multiple Inband-Security-Ids are shared in the CER/CEA >>exchange, the spec does not say how to choose which one to use. >> >> >>3. >> >>"minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or >>DIAMETER_MISSING_AVP) has several possible interpretations: >>Minimum required for the basic datatype? Minimum required for >>the derived datatype? Minimum required for successful processing? >> >>If it's minimum required for the datatype, and the datatype is >>Grouped, is the minimum length the minimum for any grouped AVP >>(i.e., empty payload) or the minimum for this particular AVP >>(in which case zero-filling may generate a corrupt AVP)? >> >> >>4. >> >>Re DIAMETER_INVALID_AVP_LENGTH again, if the length received >>is less than 12 but the AVP is vendor-specific, what should be >>put in the Vendor-Id when creating the Failed-AVP? >> >> >>5. >> >>The (defined under 7.2. Error Bit) has just >>[Proxy-Info] whereas everything else has *[Proxy-Info]. >>Presumably, *[Proxy-Info] is intended. >> >>Also, ironically does not include >>[Error-Message], and [Failed-AVP], unlike all other answers. >> >>Although the inclusion of *[AVP] makes their omission formally >>harmless, it would seem sensible to include them. >> >> >>6. >> >>The Vendor-Specific-Application-Id definition in >>rfc3588bis-draft-05 does not use the grammar that according to >>that document MUST be used. >> >>Assuming that the intention is that one and only one of >>Auth-Application-Id or Acct-Application-Id is present, the >>best thing to do would be to make both optional in the grammar >>and include the additional constraint in the text that exactly >>one MUST be present. >> >> >>7. >> >>I don't think that the text >> >> "AVPs may be added arbitrarily to Diameter messages, so long >> as the required AVPs are included and AVPs that are >> explicitly excluded are not included." >> >>is really what is intended. >> >>I assume that the absense of *[AVP] in a message definition >>means that unlisted AVPs may not be added arbitrarily to that >>message, but I can see no text by which that is 'explicitly excluded'. >> >>The current text makes the presence or absence of *[AVP] in a >>message definition meaningless. >> >> >>8. >> >>Even ignoring the previous item, the meaning of *[AVP] (or >>*{AVP}) in a message (or grouped-avp) format definition is >>unclear, and RFC 3588 contradicts itself. >> >>The description in 3.2 is >> >> ; The string "AVP" stands for *any* arbitrary >> ; AVP Name, which does not conflict with the >> ; required or fixed position AVPs defined in >> ; the command code definition. >> >>According to this wording e.g., (a) Product-Name is allowed in >>Abort-Session-Request, (b) multiple occurrences of User-Name >>are allowed in Abort-Session-Request. Both of these are >>contradicted in section 10. >> >>Taking section 10 a face value: (a) Product-Name must not >>occur in an Abort-Session-Request, according to section 10, >>despite the presence of *[AVP] in the message format, and (b) >>User-Name must occur at most once in an ASR. >> >>My guess as to the actual intent of the spec, is that: >> >> The string "AVP" stands for *any* arbitrary AVP Name, >> not otherwise listed in that command code grammar. >> >>[This allows case (a) above but not case (b)] >> >>The wording of section 10 then needs adjustment, to note that >>it does not cover AVPs allowed because of *[AVP] in the grammar. >> >>It would also make sense to me to remove all MUSTs/MAYs from >>section 10, and instead to state that it is a non-normative >>summary of what is implied in the command code definitions. >> >> >>9. >> >>The section 10 table lists Result-Code as not being present in >>ASA, contradicting the definition of that command. >> >> >>10. >> >>The section 10 wording >> >> "Note that AVPs that can only be present within a Grouped AVP >> are not represented in this table" >> >>is imprecise. E.g., it could be taken to cover User-Name >>within a Failed-AVP, on the grounds that it is not the case >>that User-Name "can only be present within a Grouped AVP". >> >>A better wording would be "Note that AVPs occurrences >>contained within a Grouped AVP are not represented in this table". >> >> >>11. >> >>If a TCP connection is established with a 4-way handshake >>(i.e., both ends send SYNs simultaneously), then both ends >>will think they are the initiator for CER/CEA exchange, and >>the exchange then fails. Is it intended to not allow this? >>The wording >> >> A Diameter node MAY initiate connections from a source port >> other than the one that it declares it accepts incoming >> connections on, and >> >>strongly suggests that also a node may initiate connections >>with the source port being the one on which it accepts >>incoming connections (i.e., 3868), in which case 4-way TCP >>handshake is a realistic possibility. >> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 03:27:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Wbm-0001Ee-Gn; Wed, 11 Jul 2007 03:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Wbl-0001EY-7u for dime@ietf.org; Wed, 11 Jul 2007 03:27:33 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Wbh-0007Pe-PZ for dime@ietf.org; Wed, 11 Jul 2007 03:27:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so5280045pyh for ; Wed, 11 Jul 2007 00:27:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=AlY+d8rFY+kjWRHKo5xeYX+p1mOA7dECQjh1JjPhIGv10g/LXZBQuuKWtPN/XWuRmTqeVXww9g9PacpQzc1fkztR0h9IqkumvFaGHWxPdCgdq195ddvDgT4QLdtsUobCQ0DixXeN6MHQJhQfixGnl3LeffRkRT4t6Kt4e/00AyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=JzuzaRBefsN08KaCbfoL8McR05rRk1ixMYsKB50VNYxBwdMqTf4ah0FQBT5dfHxXc8eL+lBsLmJJvt99cKFuTqtQhkBeoJ6P1LZ8N+psnbFfePNl7Jowv6hv5Kf2+pkPzn03s/WoPRrldzhr+j/zfOFQ/5HnIzEDK9dLYtL9mFA= Received: by 10.64.76.15 with SMTP id y15mr6010445qba.1184138849032; Wed, 11 Jul 2007 00:27:29 -0700 (PDT) Received: by 10.64.213.10 with HTTP; Wed, 11 Jul 2007 00:27:28 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 12:57:28 +0530 From: "harish raghuveer" To: dime@ietf.org Subject: Re: [Dime] Backward Capability Propagation In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504497380@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 References: <22F058C3ED9D784E90CE473F2A9847F001875B34@in-exchange> <4C0FAAC489C8B74F96BEAD85EAEB262504497380@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006975904==" Errors-To: dime-bounces@ietf.org --===============1006975904== Content-Type: multipart/alternative; boundary="----=_Part_846_28357666.1184138848983" ------=_Part_846_28357666.1184138848983 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Soji: I tend to agree with Glen. This can be a scaling bottleneck at relays. cheers, Harish On 7/11/07, Glen Zorn (gwz) wrote: > > Soji VP allegedly scribbled on Tuesday, July > 10, 2007 10:20 PM: > > > Hi Glen, > > > > CER/A should be confined only between peers and it should exchange > > capabilities of the node. But still, when one of the peers the relay > > is advertising on behalf goes down, the relay has to exchange a CER/A > > with rest of the peers with its updated capability. > > We are talking about relays, here, right? They advertise that they will > relay anything they get, they specifically do not advertise on behalf of > any other node. What you're suggesting seems to add a lot of complexity > for little (to be generous) benefit. > > > > > I agree the point that it would be inaccurate as soon as the > > connectivity gets propagated, but the same situation would be > > persisting now also; consider a case, where peer removed it's > > supported application and a node send a message to that peer before > > updated capability being negotiated to the node. In this case, little > > inaccuracy exists atleast for one hop connectivity. > > > > I'd appreciate any comments on this. > > > > Thanks, > > Soj > > > > -----Original Message----- > > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > > Sent: Tuesday, July 10, 2007 10:43 PM > > To: Soji VP > > Cc: Asveren, Tolga; dime@ietf.org > > Subject: RE: [Dime] Backward Capability Propagation > > > > Soji VP allegedly scribbled on Tuesday, > > July 10, 2007 8:17 AM: > > > > ... > > > >> Obviously we can do this by advertising App-Id only for the > >> applications for which the node is able to provide relaying. > > > > What happens if the one of the peers the relay is advertising on > > behalf > > of goes down, or one or more links goes down? What you are > > suggesting > > is to base forwarding decisions upon a second-hand snapshot of > > network connectivity that may be inaccurate as soon as it is > > propagated. > > Diameter peers advertise only their own capabilities for a reason... > > > > ... > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- Harish R Prabhu Bangalore, India. ------=_Part_846_28357666.1184138848983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Soji: I tend to agree with Glen. This can be a scaling bottleneck at relays.

cheers,
Harish

On 7/11/07, Glen Zorn (gwz) < gwz@cisco.com> wrote:
Soji VP <mailto:soji.vp@ccpu.com > allegedly scribbled on Tuesday, July
10, 2007 10:20 PM:

> Hi Glen,
>
> CER/A should be confined only between peers and it should exchange
> capabilities of the node. But still, when one of the peers the relay
> is advertising on behalf goes down, the relay has to exchange a CER/A
> with rest of the peers with its updated capability.

We are talking about relays, here, right?  They advertise that they will
relay anything they get, they specifically do not advertise on behalf of
any other node.  What you're suggesting seems to add a lot of complexity
for little (to be generous) benefit.

>
> I agree the point that it would be inaccurate as soon as the
> connectivity gets propagated, but the same situation would be
> persisting now also; consider a case, where peer removed it's
> supported application and a node send a message to that peer before
> updated capability being negotiated to the node. In this case, little
> inaccuracy exists atleast for one hop connectivity.
>
> I'd appreciate any comments on this.
>
> Thanks,
> Soj
>
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> Sent: Tuesday, July 10, 2007 10:43 PM
> To: Soji VP
> Cc: Asveren, Tolga; dime@ietf.org
> Subject: RE: [Dime] Backward Capability Propagation
>
> Soji VP <mailto:soji.vp@ccpu.com> allegedly scribbled on Tuesday,
> July 10, 2007 8:17 AM:
>
> ...
>
>> Obviously we can do this by advertising App-Id only for the
>> applications for which the node is able to provide relaying.
>
> What happens if the one of the peers the relay is advertising on
> behalf
> of goes down, or one or more links goes down?    What you are
> suggesting
> is to base forwarding decisions upon a second-hand snapshot of
> network connectivity that may be inaccurate as soon as it is
> propagated.
> Diameter peers advertise only their own capabilities for a reason...
>
> ...

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India. ------=_Part_846_28357666.1184138848983-- --===============1006975904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1006975904==-- From dime-bounces@ietf.org Wed Jul 11 06:09:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Z8r-0007Za-E4; Wed, 11 Jul 2007 06:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Z8q-0007ZS-3F for dime@ietf.org; Wed, 11 Jul 2007 06:09:52 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Z8l-00032K-Of for dime@ietf.org; Wed, 11 Jul 2007 06:09:52 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000LKXEUT4O@szxga03-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 18:08:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL0006QLEUSTF@szxga03-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 18:08:53 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL0007Z8EURZ3@szxml04-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 18:08:52 +0800 (CST) Date: Wed, 11 Jul 2007 18:08:51 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. - "PULL/PUSH/Access network related information" To: dime@ietf.org, Tina TSOU Message-id: <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <008201c7c20b$64755b70$864c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1413092958==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1413092958== Content-type: multipart/alternative; boundary="Boundary_(ID_60CzjV7aaeHVZ3PiEv9pbA)" This is a multi-part message in MIME format. --Boundary_(ID_60CzjV7aaeHVZ3PiEv9pbA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Guys, After discussion with Hannes and Dong, I think it might be better to modify like this. It is the recovering of the texts about "PULL/PUSH/Access network related information" deleted by mistake or misunderstanding 3 Framework [snipped] In some deployment scenarios, QoS aware network elements may request authorization through the AAA cloud based on an incoming QoS reservation request. The network element will route the request to a designated authorizing entity. The authorizing entity will return the result of the authorization decision. In other deployment scenarios, the authorization will be initiated upon dynamic application state, so that the request must be authenticated and authorized based on information from one or more application servers. /*start of added*/In terms of the resource request sent from the application server to Authorizing Entity, the Authorizing Entity could identify the access network related information and select appropriate resource admission and control policies. The Push or pull mode also can be dynamically triggered based on the information in the request from application server, or statically configured according to operator's demand./*end of added*/ [snipped] B. R. Tina ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: Monday, July 09, 2007 5:27 PM Subject: [Dime] Diameter QoS Appl. Hi all, I suggest that some texts could be added in the beginning of 3.3 to smooth with the texts in 3.3.1 and 3.3.2. [snipped] 3.3. Authorization schemes Three basic authorization models for QoS reservations exist: one two -party and two three party models. In the three party QoS model (Figure 3), the authorization entity may be composed of two separate functional entities - Application Server which interacts with the QoS requesting entity and Authorizing Entity. The Application Server MAY indicate the access network related information in a service request to Authorizing Entity which can be used by the Authorizing Entity to select the appropriate resource admission and control policies. The service request from Application Server to Authorizing Entity MAY also indicate the admission control mode (i.e., "pull" or "push" model) in terms of which Authorizing Entity performs QoS authorization and then sends the policy decisions to the NE which performs QoS reservation. Authorization schemes for both pull and push mode will be described below in detail. 3.3.1. Authorization schemes for pull mode [snipped] B. R. Tina ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_60CzjV7aaeHVZ3PiEv9pbA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Guys,
After discussion with Hannes and Dong, I think it might be better to modify like this. It is the recovering of the texts about
"PULL/PUSH/Access network related information" deleted by mistake or misunderstanding
 
3    Framework
[snipped]

<t>In some deployment scenarios, QoS aware network elements may request

      authorization through the AAA cloud based on an incoming QoS reservation

      request. The network element will route the request to a designated

      authorizing entity. The authorizing entity will return the result of the

      authorization decision. In other deployment scenarios, the authorization

      will be initiated upon dynamic application state, so that the request

      must be authenticated and authorized based on information from one or

      more application servers. /*start of added*/In terms of the resource request sent from

      the application server to Authorizing Entity, the Authorizing Entity

      could identify the access network related information and select appropriate

      resource admission and control policies. The Push or pull mode also can be

      dynamically triggered based on the information in the request from application

   server, or statically configured according to operator's demand./*end of added*/</t>

[snipped]

 

B. R.

Tina

----- Original Message -----
From: Tina TSOU
Sent: Monday, July 09, 2007 5:27 PM
Subject: [Dime] Diameter QoS Appl.

Hi all,
I suggest that some texts could be added in the beginning of 3.3 to smooth
with the texts in 3.3.1 and 3.3.2.
 
[snipped]
3.3.  Authorization schemes

   Three basic authorization models for QoS reservations exist: one two
   -party and two three party models.  In the three party QoS model
   (Figure 3), the authorization entity may be composed of two separate
   functional entities - Application Server which interacts with the QoS
   requesting entity and Authorizing Entity.  The Application Server MAY
   indicate the access network related information in a service request
   to Authorizing Entity which can be used by the Authorizing Entity to
   select the appropriate resource admission and control policies.  The
   service request from Application Server to Authorizing Entity MAY
   also indicate the admission control mode (i.e., "pull" or "push"
   model) in terms of which Authorizing Entity performs QoS
   authorization and then sends the policy decisions to the NE which
   performs QoS reservation. Authorization schemes for both pull
   and push mode will be described below in detail.

3.3.1.  Authorization schemes for pull mode
[snipped]
B. R.
Tina

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_60CzjV7aaeHVZ3PiEv9pbA)-- --===============1413092958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1413092958==-- From dime-bounces@ietf.org Wed Jul 11 06:43:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Zfp-0001hX-Fo; Wed, 11 Jul 2007 06:43:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Zfn-0001hO-HV for dime@ietf.org; Wed, 11 Jul 2007 06:43:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8Zfn-0004bl-0l for dime@ietf.org; Wed, 11 Jul 2007 06:43:55 -0400 Received: (qmail invoked by alias); 11 Jul 2007 10:43:21 -0000 Received: from p54987C44.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.68] by mail.gmx.net (mp031) with SMTP; 11 Jul 2007 12:43:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18y/l1bfDsySi8baKqBMJpz+FXRsnbgHMzCGbSXjq yJVYom1QAbQUhq Message-ID: <4694B447.8080800@gmx.net> Date: Wed, 11 Jul 2007 12:43:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org, Tina TSOU Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Subject: [Dime] Diameter QoS Appl.- terminal working mode X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI ------ This is without the attachment. B. R. Tina ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: Wednesday, July 11, 2007 6:26 PM Subject: Diameter QoS Appl.- terminal working mode Hi Guys, To converge different kind of authorizing entities and performing NEs, terminal-Mode can tell the performing NE how to choose the interface working mode. First, we can find which mode the terminal is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi-mode, and each mode may have different QoS profile, so the terminal-mode AVP can help to the operation on match QoS request and QoS control. The following changes are proposed. (You can also find the changes in the attachment.) section 6.2
The QoS-Authorization-Answer message (QAA), indicated by the Command- Code field set to TBD and 'R' bit cleared in the Command Flags field is sent in response to the QoS-Authorization-Request message (QAR). To converge different kind of authorizing entities and performing NEs, terminal-Mode can tell the performing NE how to choose the interface working mode. If the QoS authorization request is successfully authorized, the response will include the AVPs to allow authorization of the QoS resources as well as accounting and transport plane gating information. The message format is defined as follows:
::= < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ Terminal-Mode ] * [ QoS-Resources ] [ CC-Time ] [ Acc-Multisession-Id ] [ Session-Timeout ] [ Authz-Session-Lifetime ] [ Authz-Grace-Period ] * [ AVP ] ]]>
section 6.3
The QoS-Install Request message (QIR), indicated by the Command-Code field set to TDB and 'R' bit set in the Command Flags field is used by Authorizing entity to install or update the QoS parameters and the flow state of an authorized flow at the transport plane element. The message MUST carry information for signaling session identification or identification of the flow to which the provided QoS rules apply, working mode of the terminal, identity of the transport plane element, description of provided QoS parameters, flow state and duration of the provided authorization. The message format is defined as follows:
::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } [ Terminal-Mode ] { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] * [ QoS-Resources ] [ Session-Timeout ] [ Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ Authz-Session-Volume ] * [ AVP ] ]]>
[snipped] section 7.1
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Zi8-00029s-4Z; Wed, 11 Jul 2007 06:46:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Zi7-00028k-C7 for dime@ietf.org; Wed, 11 Jul 2007 06:46:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8Zi6-0004fn-O1 for dime@ietf.org; Wed, 11 Jul 2007 06:46:19 -0400 Received: (qmail invoked by alias); 11 Jul 2007 10:46:13 -0000 Received: from p54987C44.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.68] by mail.gmx.net (mp026) with SMTP; 11 Jul 2007 12:46:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+t/hJvGAWtniXniT848haZ44iAPuCRNq5/9LxH3b WN+Y0lU6ThMvYp Message-ID: <4694B4F0.5060804@gmx.net> Date: Wed, 11 Jul 2007 12:46:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org, Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode References: <4694B447.8080800@gmx.net> In-Reply-To: <4694B447.8080800@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, who translates high-level QoS information used at the application layer into information that is appropriate for a QoS model that is used in a particular access network. In your model it seems that the AF is in charge of assisting whereas the PDF does the final translation. In any case, it is not the NE that does it. Correct? But how should the AF know anything about the access network characteristics? (unless it is in the access network itself) What information would you put into the Terminal-Mode AVP? Ciao Hannes Hannes Tschofenig wrote: > FYI > > ------ > > This is without the attachment. > > B. R. > Tina > > ----- Original Message ----- From: Tina TSOU To: dime@ietf.org > Sent: Wednesday, July 11, 2007 6:26 PM > Subject: Diameter QoS Appl.- terminal working mode > > > Hi Guys, > To converge different kind of authorizing entities and performing > NEs, terminal-Mode can tell the performing NE how to choose the > interface working mode. First, we can find which mode the terminal is > by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user > terminal may be multi-mode, and each mode may have different QoS > profile, so the terminal-mode AVP can help to the operation on match > QoS request and QoS control. > The following changes are proposed. (You can also find the changes in > the attachment.) > section 6.2 > >
> > The QoS-Authorization-Answer message (QAA), indicated by the > > Command- Code field set to TBD and 'R' bit cleared in the > Command > > Flags field is sent in response to the QoS-Authorization-Request > > message (QAR). To converge different kind of authorizing > entities > and performing NEs, terminal-Mode can tell the performing NE how > to choose the interface working mode. If the QoS > authorization request > > is successfully authorized, the response will include the > AVPs to > allow authorization of the QoS resources as well as > accounting and > transport plane gating information. > > The message format is defined as follows: > > >
> > > ::= < Diameter Header: XXX, PXY > > < Session-Id > > { Auth-Application-Id } > { Auth-Request-Type } > { Result-Code } > { Origin-Host } > { Origin-Realm } > [ Terminal-Mode ] > * [ QoS-Resources ] > [ CC-Time ] > [ Acc-Multisession-Id ] > [ Session-Timeout ] > [ Authz-Session-Lifetime ] > [ Authz-Grace-Period ] > * [ AVP ] > ]]> > >
> >
> > > section 6.3 > >
> > The QoS-Install Request message (QIR), indicated by the > > Command-Code field set to TDB and 'R' bit set in the Command > Flags > > field is used by Authorizing entity to install or update the QoS > > parameters and the flow state of an authorized flow at the > transport > > plane element. > > > The message MUST carry information for signaling session > > identification or identification of the flow to which the > provided QoS > > rules apply, working mode of the terminal, identity of the > transport > plane element, description of provided QoS parameters, flow > state and > duration of the provided authorization. > > > The message format is defined as follows: > > >
> > > ::= < Diameter Header: XXX, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > [ Terminal-Mode ] > { Destination-Realm } > { Auth-Request-Type } > [ Destination-Host ] > * [ QoS-Resources ] > [ Session-Timeout ] > [ Authz-Session-Lifetime ] > [ Authz-Grace-Period ] > [ Authz-Session-Volume ] > * [ AVP ] > ]]> > >
> >
> > > > [snipped] > > > > section 7.1 > >
> > > Attribute Name AVP Code Reference [RFC3588] > > Origin-Host 264 Section 6.3 > > Origin-Realm 296 Section 6.4 > > Terminal-Mode TBD > > > B. R. > > Tina > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 07:24:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aIz-0007mJ-Ht; Wed, 11 Jul 2007 07:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aIz-0007m8-1n for dime@ietf.org; Wed, 11 Jul 2007 07:24:25 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8aIv-0004v4-ON for dime@ietf.org; Wed, 11 Jul 2007 07:24:25 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6BBO5fX026630; Wed, 11 Jul 2007 07:24:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Backward Capability Propagation Date: Wed, 11 Jul 2007 07:24:05 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188052@sonusmail04.sonusnet.com> In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F001875A36@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Backward Capability Propagation Thread-Index: AcfC0etKuq5RDEXUR7GZuQlOMhMijQAGo+FgAAVB1/AAKu9mAA== References: <22F058C3ED9D784E90CE473F2A9847F001875A36@in-exchange> From: "Asveren, Tolga" To: "Soji VP" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Soj, That a node is called relay/proxy etc... is really more for naming purposes. The behavior you want matches with what is called as a proxy in the specification. OTOH, I think what is important is procedures/on-the-wire protocol rather than naming of nodes. The protocol allows a node to advertise 0xFFFFFFFF or specific application-Ids. What you need seems to advertise a set of application-Ids, which is allowed by the protocol. Thanks, Tolga > -----Original Message----- > From: Soji VP [mailto:soji.vp@ccpu.com] > Sent: Tuesday, July 10, 2007 11:17 AM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] Backward Capability Propagation >=20 > Hi Tolga, >=20 > When we do a CER/A exchange, as per current RFC 3588 protocol, node > advertises application ids supported by that node only. It will not > consider supported application id's of its subsequent peers. CER/A > definition specifies capability negotiation confined between to nodes > and should consider the supported application of the particular node > only. i.e > CER/A exchanged between node A and node B should bother only supported > application id's in node A and node B. >=20 > But as per my understanding from RFC (Sec 5.3 para 3), a relay will > advertise application id's supported by that relay node only (in > addition to 0xffffffff). >=20 > Obviously we can do this by advertising App-Id only for > the applications for which the node is able to provide relaying. But I > think, it'd be better if we specify so in nex rev. >=20 > Please correct me if I'm wrong. >=20 > Thanks > -Soj. >=20 >=20 > Note that receiving a CER or CEA from a peer > advertising itself as a Relay (see Section 2.4) MUST be interpreted > as having common applications with the peer. >=20 > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 10, 2007 6:01 PM > To: Soji VP; dime@ietf.org > Subject: RE: [Dime] Backward Capability Propagation >=20 > Soj, >=20 > You should be able to do this already, i.e. advertising App-Id only for > the applications for which the node is able to provide relaying. >=20 > Thanks, > Tolga >=20 > ________________________________________ > From: Soji VP [mailto:soji.vp@ccpu.com] > Sent: Tuesday, July 10, 2007 5:09 AM > To: dime@ietf.org > Subject: [Dime] Backward Capability Propagation >=20 > Hi Friends, >=20 > Just give a thought of having backward capability propagation feature > while exchanging capability negotiation with the peers (b/w a node and a > relay node). > As per current definitions a Diameter relay must advertise its relay > application id "0xffffffff" (also any application id relay node is > supporting) with its peers. > But when a node is sending CER to a relay to get it's capability, relay > can always advertise union of application id's of all of its peers > (except the node which sends CER) in CEA. BCP shall be applied between > relays also (if relay chain exists). > This backward propagation will help a diameter node to ensure if it's > useful to send request or response via this particular relay and send > error message without sending message to relay if it's any of the peer > or its subsequent relay's doesn't support the application id. > This will make a node to take decision of sending messages much earlier > (by caching the capability of path to a known level). >=20 > I'm new to dime and not sure if this is already been thought of. Ignore > in that case else let's float some comments. >=20 > Thanks & Rgds, > --soj >=20 >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 07:32:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aQo-0004VM-Qp; Wed, 11 Jul 2007 07:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aQo-0004VG-89 for dime@ietf.org; Wed, 11 Jul 2007 07:32:30 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8aQk-00057F-7J for dime@ietf.org; Wed, 11 Jul 2007 07:32:30 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000IGKIOKIJ@szxga02-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:31:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000KLNIOJAU@szxga02-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:31:32 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL00072ZIOJZ3@szxml04-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:31:31 +0800 (CST) Date: Wed, 11 Jul 2007 19:31:31 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode To: dime@ietf.org, Hannes Tschofenig Message-id: <032001c7c3af$07676c20$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ----- Original Message ----- From: "Hannes Tschofenig" To: ; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > What information would you put into the Terminal-Mode AVP? [Tina: First, we can find which mode the terminal is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi-mode, and each mode may have different QoS profile, so the terminal-mode AVP can help to the operation on match QoS request and QoS control.] > > Ciao > Hannes > > Hannes Tschofenig wrote: >> FYI >> >> ------ >> >> This is without the attachment. >> >> B. R. >> Tina >> >> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: >> Wednesday, July 11, 2007 6:26 PM >> Subject: Diameter QoS Appl.- terminal working mode >> >> >> Hi Guys, >> To converge different kind of authorizing entities and performing NEs, >> terminal-Mode can tell the performing NE how to choose the interface >> working mode. First, we can find which mode the terminal is by >> Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may >> be multi-mode, and each mode may have different QoS >> profile, so the terminal-mode AVP can help to the operation on match QoS >> request and QoS control. >> The following changes are proposed. (You can also find the changes in >> the attachment.) >> section 6.2 >> >>
>> >> The QoS-Authorization-Answer message (QAA), indicated by the >> >> Command- Code field set to TBD and 'R' bit cleared in the >> Command >> >> Flags field is sent in response to the QoS-Authorization-Request >> >> message (QAR). To converge different kind of authorizing >> entities >> and performing NEs, terminal-Mode can tell the performing NE how >> to choose the interface working mode. If the QoS authorization >> request >> >> is successfully authorized, the response will include the AVPs >> to >> allow authorization of the QoS resources as well as accounting >> and >> transport plane gating information. >> >> The message format is defined as follows: >> >>
>> >> > >> ::= < Diameter Header: XXX, PXY > < >> Session-Id > { Auth-Application-Id } >> { Auth-Request-Type } { Result-Code } >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] * [ QoS-Resources ] >> [ CC-Time ] [ Acc-Multisession-Id ] >> [ Session-Timeout ] [ >> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >> * [ AVP ] ]]> >> >>
>> >>
>> >> section 6.3 >> >>
>> >> The QoS-Install Request message (QIR), indicated by the >> >> Command-Code field set to TDB and 'R' bit set in the Command >> Flags >> >> field is used by Authorizing entity to install or update the QoS >> >> parameters and the flow state of an authorized flow at the >> transport >> >> plane element. >> >> The message MUST carry information for signaling session >> >> identification or identification of the flow to which the >> provided QoS >> >> rules apply, working mode of the terminal, identity of the >> transport >> plane element, description of provided QoS parameters, flow >> state and >> duration of the provided authorization. >> >> The message format is defined as follows: >> >>
>> >> > >> ::= < Diameter Header: XXX, REQ, PXY > < >> Session-Id > { Auth-Application-Id } >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] >> { Destination-Realm } { >> Auth-Request-Type } [ Destination-Host ] >> * [ QoS-Resources ] [ Session-Timeout ] [ >> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >> [ Authz-Session-Volume ] * [ >> ]]> >> >>
>> >>
>> >> >> >> [snipped] >> >> >> >> section 7.1 >> >>
>> >> > >> Attribute Name AVP Code Reference [RFC3588] >> >> Origin-Host 264 Section 6.3 >> >> Origin-Realm 296 Section 6.4 >> >> Terminal-Mode TBD >> >> >> B. R. >> >> Tina >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 07:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aTi-0007tE-TV; Wed, 11 Jul 2007 07:35:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aTh-0007t6-Te for dime@ietf.org; Wed, 11 Jul 2007 07:35:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8aTS-0005h3-EH for dime@ietf.org; Wed, 11 Jul 2007 07:35:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000JYFIT10L@szxga03-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:34:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL0004GSIT0YB@szxga03-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:34:13 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL0007XAIT0Z3@szxml04-in.huawei.com> for dime@ietf.org; Wed, 11 Jul 2007 19:34:12 +0800 (CST) Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-id: <032c01c7c3af$67904630$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ----- Original Message ----- From: "Hannes Tschofenig" To: ; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 09:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cCJ-0001z3-UD; Wed, 11 Jul 2007 09:25:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cCI-0001ys-JD for dime@ietf.org; Wed, 11 Jul 2007 09:25:38 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cC3-0000Ij-2z for dime@ietf.org; Wed, 11 Jul 2007 09:25:38 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6BDO9o0050238; Wed, 11 Jul 2007 09:24:11 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4694D9FA.9080002@tari.toshiba.com> Date: Wed, 11 Jul 2007 09:24:10 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Ralph Loader Subject: Re: [Dime] Several rfc 3588 issues. References: <4693F31F.2090701@eservglobal.co.nz> In-Reply-To: <4693F31F.2090701@eservglobal.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ralph, Thanks for the good review. Comments inline: > 'Home Server' in section 1.3, is defined with 'See Diameter > Server'. But looking at the definition of 'Diameter Server', I > do not see any indication of what a 'Home Server' is. > > Is the intention that 'Home Server' is a synonym for 'Diameter > Server', or is there some other meaning? (E.g., a 'Diameter > Server' serving a 'Home Realm'). how about we use empty payload ? > Yes its suppose to be a synonym. Though I'm not sure what you mean by empty payload. If you want we can just say: "A Diameter Server which serves the Home Realm". > > 2. > > If multiple Inband-Security-Ids are shared in the CER/CEA > exchange, the spec does not say how to choose which one to use. I'm guessing it co-relates with Host-IP-Address when using TLS over several bi-directional streams in SCTP (rfc3436). I hope others can verify this and we can add clarifying text. > > > 3. > > "minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or > DIAMETER_MISSING_AVP) has several possible interpretations: > Minimum required for the basic datatype? Minimum required for > the derived datatype? Minimum required for successful > processing? Its suppose to be the former - derived datatype. We can add text based on both scenarios and your comments below to describe what "minimum req length" means. > > If it's minimum required for the datatype, and the datatype is > Grouped, is the minimum length the minimum for any grouped AVP > (i.e., empty payload) or the minimum for this particular AVP (in > which case zero-filling may generate a corrupt AVP)? For simplicity (and to make sense), we can just use a grouped AVP with an empty payload. > 5. > > The (defined under 7.2. Error Bit) has just > [Proxy-Info] whereas everything else has *[Proxy-Info]. > Presumably, *[Proxy-Info] is intended. Ok. We should probably also note in 7.2 that e-bit answer messages can be sent for permanent errors as well. > > Also, ironically does not include > [Error-Message], and [Failed-AVP], unlike all other answers. > > Although the inclusion of *[AVP] makes their omission formally > harmless, it would seem sensible to include them. Make sense, this was probably missed when we allowed permanent failures to be sent with e-bit answer messages. > > > 6. > > The Vendor-Specific-Application-Id definition in > rfc3588bis-draft-05 does not use the grammar that according to > that document MUST be used. > > Assuming that the intention is that one and only one of > Auth-Application-Id or Acct-Application-Id is present, the best > thing to do would be to make both optional in the grammar and > include the additional constraint in the text that exactly one MUST be > present. Mmmm ... I think that was the original grammar (as well as text) and people where confused about that also. The new grammar: ::= < AVP Header: 260 > { Vendor-Id } { Auth-Application-Id } / { Acct-Application-Id } has them as OR (Note the "/" after auth-app-id). I'm assuming thats the correct ABNF representation for OR. Maybe some grouping is needed (rfc4234), like: ::= < AVP Header: 260 > { Vendor-Id } ( { Auth-Application-Id } / { Acct-Application-Id } ) > > > 7. > > I don't think that the text > > "AVPs may be added arbitrarily to Diameter messages, so long > as the required AVPs are included and AVPs that are > explicitly excluded are not included." > > is really what is intended. > > I assume that the absense of *[AVP] in a message definition > means that unlisted AVPs may not be added arbitrarily to that > message, but I can see no text by which that is 'explicitly excluded'. > > The current text makes the presence or absence of *[AVP] in a > message definition meaningless. make sense. How about re-wording from: "AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included." to: "AVPs may be added arbitrarily to Diameter messages, so long as the requirements of a messages ABNF are met and the ABNF allows for it." > > > 8. > > Even ignoring the previous item, the meaning of *[AVP] (or > *{AVP}) in a message (or grouped-avp) format definition is > unclear, and RFC 3588 contradicts itself. > > The description in 3.2 is > > ; The string "AVP" stands for *any* arbitrary > ; AVP Name, which does not conflict with the > ; required or fixed position AVPs defined in > ; the command code definition. > > According to this wording e.g., (a) Product-Name is allowed in > Abort-Session-Request, (b) multiple occurrences of User-Name are > allowed in Abort-Session-Request. Both of these are > contradicted in section 10. > > Taking section 10 a face value: (a) Product-Name must not occur > in an Abort-Session-Request, according to section 10, despite > the presence of *[AVP] in the message format, and (b) User-Name > must occur at most once in an ASR. > > My guess as to the actual intent of the spec, is that: > > The string "AVP" stands for *any* arbitrary AVP Name, > not otherwise listed in that command code grammar. > > [This allows case (a) above but not case (b)] Yes this was the intent. Luckily most folks understood it that way or ignored the text :). We can re-word based on your suggestion. If we do so, would'nt a commands ABNF already cover (b) ? > > The wording of section 10 then needs adjustment, to note that it > does not cover AVPs allowed because of *[AVP] in the grammar. > > It would also make sense to me to remove all MUSTs/MAYs from > section 10, and instead to state that it is a non-normative > summary of what is implied in the command code definitions. Not sure if that will make the table any more readable. Some of those MUST/MAY sentences describes how to read the table. > > > 9. > > The section 10 table lists Result-Code as not being present in > ASA, contradicting the definition of that command. Ok. > > > 10. > > The section 10 wording > > "Note that AVPs that can only be present within a Grouped AVP > are not represented in this table" > > is imprecise. E.g., it could be taken to cover User-Name within > a Failed-AVP, on the grounds that it is not the case that > User-Name "can only be present within a Grouped AVP". > > A better wording would be "Note that AVPs occurrences contained > within a Grouped AVP are not represented in this table". Ok. Though both sentence look similar. Can we make it plain and simple: "AVPs that occur only inside a Grouped AVP are not shown in this table". > > > 11. > > If a TCP connection is established with a 4-way handshake (i.e., > both ends send SYNs simultaneously), then both ends will think > they are the initiator for CER/CEA exchange, and the exchange > then fails. Is it intended to not allow this? The wording > > A Diameter node MAY initiate connections from a source port > other than the one that it declares it accepts incoming > connections on, and > > strongly suggests that also a node may initiate connections with the > source port being the one on which it accepts incoming > connections (i.e., 3868), in which case 4-way TCP handshake is a > realistic possibility. The "MAY" in the statement above does not restrict you from using source port 3868. Is this still a problem ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 10:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d5f-0005ns-IH; Wed, 11 Jul 2007 10:22:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d5e-0005nm-AH for dime@ietf.org; Wed, 11 Jul 2007 10:22:50 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8d5Z-0001XY-O1 for dime@ietf.org; Wed, 11 Jul 2007 10:22:50 -0400 Received: by ug-out-1314.google.com with SMTP id u2so259000uge for ; Wed, 11 Jul 2007 07:22:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oqAVf2zFBQi7lRBZL1m7rp5/fhEXhS2/LR8mpo8akEe/lN0AJWryQrfoXiYJZJkfQCDByBP4H5WGbukBb4B8o5N8rAUCHi8iqJ+gLgYdTjG1BGvO5EcJvOe1I3AflfyXH2XmIEaYFqObfT0fexN+50hUOg+f+zjkjDlMKWo20UU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TEbSsBAnDt4pqg4YWySYhh9x9msQqfMvQqBHOihii49OoIUglje5Joii4BwCvMTa66nFmNUIk2ADNYqjxcQNNCvb/NlWhobvebXuIYvvv6cpUS1VjS+QgQHo6JUTznY/CLpmDjxYH+fwxWUmwI4CmjAMH1J6hWYsAU6279diN6Y= Received: by 10.82.126.5 with SMTP id y5mr10928109buc.1184163764429; Wed, 11 Jul 2007 07:22:44 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Wed, 11 Jul 2007 07:22:44 -0700 (PDT) Message-ID: <9cf5ced20707110722r34373c52u5aa884f036c70490@mail.gmail.com> Date: Wed, 11 Jul 2007 10:22:44 -0400 From: "David Frascone" To: "Tina TSOU" Subject: Re: [Dime] Tentative Agenda for DIME meeting In-Reply-To: <002501c7c2ce$540406b0$864c460a@china.huawei.com> MIME-Version: 1.0 References: <46933368.4000701@gmx.net> <002501c7c2ce$540406b0$864c460a@china.huawei.com> X-Google-Sender-Auth: ec5af729c43e8135 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0016303815==" Errors-To: dime-bounces@ietf.org --===============0016303815== Content-Type: multipart/alternative; boundary="----=_Part_6848_3768152.1184163764336" ------=_Part_6848_3768152.1184163764336 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/10/07, Tina TSOU wrote: > > Hi Hannes and Dave, > Thanks for the agenda. > Is it possible to add a couple minutes in the end to show the topic > "Diameter Explicit Routing and Re-direct"? > There are some discussions in the ML and an update of I-D -03 about > Diameter > Explicit Routing was submitted by Victor, Jouni, Tolga and I. The > Re-direct > topic will be provided in separate I-D. But we are going to show the > technical relationships between them and the progress of discussion in ML > and offline. I had a discussion with Victor about this at the last ietf. I did have one concern: Explicit Routing effectively disables failover for existing conversations. Since the nodes maintain state, if a node goes down, the particular conversation will not be able to fail over. (New conversations, however, would be able to find a new route through the cloud, and would be unaffected) I think this caveat needs to be presented in the draft. In bold letters. I think it needs to be very obvious to implementers that they're giving up some reliability if they choose this option. -Dave -- David Frascone A big enough hammer fixes anything ------=_Part_6848_3768152.1184163764336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 7/10/07, Tina TSOU <tena@huawei.com> wrote:
Hi Hannes and Dave,
Thanks for the agenda.
Is it possible to add a couple minutes in the end to show the topic
"Diameter Explicit Routing and Re-direct"?
There are some discussions in the ML and an update of I-D -03 about Diameter
Explicit Routing was submitted by Victor, Jouni, Tolga and I. The Re-direct
topic will be provided in separate I-D. But we are going to show the
technical relationships between them and the progress of discussion in ML
and offline.

I had a discussion with Victor about this at the last ietf.  I did have one  concern:

<ChairHatOff>
Explicit Routing effectively disables failover for existing conversations.  Since the nodes maintain state, if a node goes down, the particular conversation will not be able to fail over.  (New conversations, however, would be able to find a new route through the cloud, and would be unaffected)

I think this caveat needs to be presented in the draft.  In bold letters.  I think it needs to be very obvious to implementers that they're giving up some reliability if they choose this option.

</ChairHatOff>

-Dave


--
David Frascone

A big enough hammer fixes anything ------=_Part_6848_3768152.1184163764336-- --===============0016303815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0016303815==-- From dime-bounces@ietf.org Wed Jul 11 10:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d7e-0008TR-Ud; Wed, 11 Jul 2007 10:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d7e-0008TM-JT for dime@ietf.org; Wed, 11 Jul 2007 10:24:54 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8d7Z-0001aq-BN for dime@ietf.org; Wed, 11 Jul 2007 10:24:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 11 Jul 2007 10:24:48 -0400 X-IronPort-AV: i="4.16,527,1175486400"; d="scan'208"; a="41079591:sNHT23376696" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 16:24:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "LS on Y.ngn-account" Thread-Index: AcfDr4+e4VB4Cv3fS1GANHNpk0SXxwAF4qgg From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Dime] FW: New Liaison Statement, "LS on Y.ngn-account" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 =20 -----Original Message----- From: Susanna Kooistra (3GPP) [mailto:Susanna.Kooistra@etsi.org]=20 Sent: Wednesday, July 11, 2007 2:24 PM To: chair@ietf.org Cc: iesg@ietf.org; hannu.hietalahti@nokia.com Subject: New Liaison Statement, "LS on Y.ngn-account"=20 Title: LS on Y.ngn-account Submission Date: 2007-07-11 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D347=20 From: Susanna Kooistra(3GPP) To: The IETF(chair@ietf.org) Cc: iesg@ietf.org Reponse Contact: hannu.hietalahti@nokia.com Technical Contact:=20 Purpose: For information=20 Body: 3GPP TSG-SA5 (Telecom Management) S5-071300 Meeting SA5#54, 25 - 29 June 2007, Orlando, FL USA=09 Title: LS on Y.ngn-account Response to: LS (COM13-LS178-E / S5-071122) on 'Sharing the latest version of Y.ngn-account' from ITU-T Study Group 13 Release: N/A Work Item: N/A Source: 3GPP SA5 To: ITU-T SG13 Question 2 Cc: ATIS TMOC, ETSI TISPAN WG2, ITU-T SG3, SG4 and NGNMFG Cc: 3GPP/IETF & 3GPP/ITU-T Co-ordinator, Hannu HIETALAHTI - 3GPP TSG CT Chair (hannu.hietalahti@nokia.com) Contact Person Name: Julian MITCHELL E-mail Address: julianm@nortel.com Approval Date: 29 June 2007 Reply by (if required): None For: Action: X Information: X Attachments: None. 1. Overall Description: 3GPP SA5 thanks ITU-T SG13 for their liaison informing SA5 of the latest version of Y.ngn-account. 3GPP SA5 also thanks ITU-T Q8/4 for inviting SA5 to participate in their teleconferences held in early June 2007 for review of Y.ngn-account. SA5 has reviewed the latest version of Y.ngn-account and has the following comments (some of these have been discussed on the Q8/4 call, but are included here for completeness): * 8.2.1 - SA5 fully agrees with the need to be able to configure policy on the CTF, however SA5 takes the view that the CCF should not be the functional entity responsible for configuring policy on the CTF. The Ct reference point should be for the purpose of extracting charging data from the CTF, not pushing policy to the CTF. * 8.2.2 - The n:1 relationship of CTF to CCF (i.e. each CTF has to duplicate its charging information to multiple CDFs) is of concern to SA5. SA5 uses IETF-defined Diameter between its CTF and CCF equivalent functions, and Diameter does not support an n:1 relationship, yet despite this, the SA5 charging solution has been widely deployed with no concerns about lack of 'backup and high availability' as other mechanisms can address these issues. The duplication of data to multiple destinations also raises concerns about excessive usage of network resources (bandwidth and processing power). The n:1 should at most be made an option if it needs to be mentioned at all. * 8.2.2 - The reference to the CCF performing analysis functions needs to be clarified to confirm that the analysis is concerned with correct packaging for data with any more detailed analysis, including correlation, being performed in the CGF or Billing System. 3GPP SA5 suggests that changing the name of the function from Charging Collection Function (defined in 3GPP Release 5) to Charging Data Function (defined in 3GPP Release 6 onwards) would help to reduce the confusion. * 8.2.4 - The last two paragraphs about why a rating function is part of billing domain and why it's only used for online charging are confusing and unnecessary and should be removed. * 8.2.7 - The Inter-provider Charging Gateway Function is not a function that exists in SA5's charging solution as such data is transferred using GSMA-defined TAP procedures in the billing domain. It is suggested that the requirements for the IPCGF be analyzed in more depth to confirm if it is really needed as a function in the charging domain or if the functions it provides would be better included as part of the billing domain. It should be noted that TISPAN have been looking at providing dynamic inter-operator rating information in the SIP signalling between Online Charging Functions. * 8.3.2 - The on-line charging reference point needs to allow data to be transferred from the OCF to the CTF in addition to from the CTF to OCF. As such, it is suggested that the term 'acknowledgement' be replaced by 'response' in this section. * 9.1 - This call flows in this section show a PCRF. This is in line with the 3GPP Policy and Charging Control (PCC) solution, so is welcomed by 3GPP SA5. The PCRF functionality is not defined elsewhere within the document, so it is recommended to add references to the PCC architecture specified in 3GPP TS 23.203. 2. Actions: To ITU SG13 ACTION: 3GPP SA5 asks ITU-T SG13 to take into account the comments in this liaison when updating Y ngn-account. 3. Date of Next SA5 Meetings: TITLE TYPE DATES LOCATION CTRY=20 3GPPSA5#55 OR 27 - 31 Aug 2007 Bucharest RO =20 3GPPSA5#56 OR 22 - 26 Oct 2007 Guangzhou CN Attachment(s): No document has been attached _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 12:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ess-0004ys-Gx; Wed, 11 Jul 2007 12:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8esr-0004yd-Gj for dime@ietf.org; Wed, 11 Jul 2007 12:17:45 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8esr-0004u0-65 for dime@ietf.org; Wed, 11 Jul 2007 12:17:45 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6BGFiH3050983; Wed, 11 Jul 2007 12:15:45 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46950232.1050906@tari.toshiba.com> Date: Wed, 11 Jul 2007 12:15:46 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: rloader@eservglobal.com Subject: Re: [Dime] Several rfc 3588 issues. References: <4693F31F.2090701@eservglobal.co.nz> <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> <55348.203.173.189.191.1184137685.squirrel@webmail.eservglobal.co.nz> In-Reply-To: <55348.203.173.189.191.1184137685.squirrel@webmail.eservglobal.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi folks, >>> 4. >>> >>> Re DIAMETER_INVALID_AVP_LENGTH again, if the length received >>> is less than 12 but the AVP is vendor-specific, what should be >>> put in the Vendor-Id when creating the Failed-AVP? >>> >> In this case, how could we determine the "minimum required length"? Since >> we >> don't have the complete vendor Id, we will not know the type of the AVP. >> > > Good point. > > How about adding the following to the description of > DIAMETER_INVALID_AVP_LENGTH, immediately after the current draft-05 text: > > "In the cases where the offending AVP code (or vendor id) is unknown to > the peer, the payload [of the AVP included in the Failed-AVP] may be > empty. In the cases where the offending AVP has the V-bit set but does not > contain a complete vendor id, the vendor id included inside the Failed-AVP > may be set to zero." > > Does that cover the required cases? > Just to summarize the cases for INVALID_AVP_LENGTH: a. length >= 12: the receiver can probably decode the header since it can tell whether the length field is incorrect in the first place. In this the existing scheme works. If it cannot decode the AVP (corruption) then this falls under (b). b. length < 12: Likely possibility that the AVP header cannot be decoded. This is regardless and whether the AVP is vendor specific or not, or whether initial portions of the header are still parsable. In this case, I would suggest doing a best-effort, catch-all scheme where the reporter of the error sends the set of offending octects with additional padding for a total of 12-octets (header size). It is preferable if avoid specifying special conditions for corner case scenarios that adds very little value. Comments ? best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 12:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fM2-0001J9-1g; Wed, 11 Jul 2007 12:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fM0-0001IN-27 for dime@ietf.org; Wed, 11 Jul 2007 12:47:52 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8fLv-0006OI-8e for dime@ietf.org; Wed, 11 Jul 2007 12:47:52 -0400 Received: by py-out-1112.google.com with SMTP id f31so5735414pyh for ; Wed, 11 Jul 2007 09:47:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=D3v4577jIezbxywrEaDfi2usa8QX684yBN0W9lDQTEv9QG6fUC2uSqydcJ8ve8OzbC9XQaplYNy5Nr2RLUcgmWygaZDl7ig6CRYCxI9loeFetCnvugKJ6cs2xbqEuE+k5XJyWGJeAFuKIL9cBwICPX8kOk397eGk/3qNHZc98Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Qq5uXKAsQjqzSH4XItPL+8AvV+e0v3ZwYQ7SmWVsop/T5mBaKDwrzUCGWULaW3QcDdhLYePEU++7Df8Fb4K/Zw3rppyh7cdrz3YLP0g2ADg1Nn9zRbuvxDpupdZBIWG1qIF/cD6maiKXsY6ehlMd+OaS+MA5L08FNt0nPy4833Q= Received: by 10.65.153.10 with SMTP id f10mr9091465qbo.1184172466160; Wed, 11 Jul 2007 09:47:46 -0700 (PDT) Received: by 10.64.213.10 with HTTP; Wed, 11 Jul 2007 09:47:46 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 22:17:46 +0530 From: "harish raghuveer" To: "Ralph Loader" Subject: Re: [Dime] Several rfc 3588 issues. In-Reply-To: <4693F31F.2090701@eservglobal.co.nz> MIME-Version: 1.0 References: <4693F31F.2090701@eservglobal.co.nz> X-Spam-Score: 0.6 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773618920==" Errors-To: dime-bounces@ietf.org --===============1773618920== Content-Type: multipart/alternative; boundary="----=_Part_8204_31788131.1184172466102" ------=_Part_8204_31788131.1184172466102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have a couple of points/questions regarding Issue #11. If there is a TCP connection establishment collision, wont the election process decide who would be the initiator and who would be the responder and break the tie? Consider two peers A and B, both trying to set up TCP connection simultaneously. Both receive the CER, but the election process would have put one of the node in responder state and the other in initiator state. The CER received at the (elected) initiator side would be dropped ideally and connection closed . Isnt the statemachine handling this collision scenario currently? Or did I get Ralph incorrectly? thanks, Harish On 7/11/07, Ralph Loader wrote: > > Hi, > > Following is a list of issues I've come across in rfc3588. > > I think all are current in the 3588bis-05 draft. > > Many are cases where taking the text at face value does not match what > appears to be intended. A few actually concern how the protocol operates. > > Apologies for any due to me not RTFM well enough. > > Cheers, > Ralph. > > 1. > > 'Home Server' in section 1.3, is defined with 'See Diameter > Server'. But looking at the definition of 'Diameter Server', I > do not see any indication of what a 'Home Server' is. > > Is the intention that 'Home Server' is a synonym for 'Diameter > Server', or is there some other meaning? (E.g., a 'Diameter > Server' serving a 'Home Realm'). > > > 2. > > If multiple Inband-Security-Ids are shared in the CER/CEA > exchange, the spec does not say how to choose which one to use. > > > 3. > > "minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or > DIAMETER_MISSING_AVP) has several possible interpretations: > Minimum required for the basic datatype? Minimum required for > the derived datatype? Minimum required for successful > processing? > > If it's minimum required for the datatype, and the datatype is > Grouped, is the minimum length the minimum for any grouped AVP > (i.e., empty payload) or the minimum for this particular AVP (in > which case zero-filling may generate a corrupt AVP)? > > > 4. > > Re DIAMETER_INVALID_AVP_LENGTH again, if the length received is > less than 12 but the AVP is vendor-specific, what should be put > in the Vendor-Id when creating the Failed-AVP? > > > 5. > > The (defined under 7.2. Error Bit) has just > [Proxy-Info] whereas everything else has *[Proxy-Info]. > Presumably, *[Proxy-Info] is intended. > > Also, ironically does not include > [Error-Message], and [Failed-AVP], unlike all other answers. > > Although the inclusion of *[AVP] makes their omission formally > harmless, it would seem sensible to include them. > > > 6. > > The Vendor-Specific-Application-Id definition in > rfc3588bis-draft-05 does not use the grammar that according to > that document MUST be used. > > Assuming that the intention is that one and only one of > Auth-Application-Id or Acct-Application-Id is present, the best > thing to do would be to make both optional in the grammar and > include the additional constraint in the text that exactly one MUST be > present. > > > 7. > > I don't think that the text > > "AVPs may be added arbitrarily to Diameter messages, so long > as the required AVPs are included and AVPs that are > explicitly excluded are not included." > > is really what is intended. > > I assume that the absense of *[AVP] in a message definition > means that unlisted AVPs may not be added arbitrarily to that > message, but I can see no text by which that is 'explicitly excluded'. > > The current text makes the presence or absence of *[AVP] in a > message definition meaningless. > > > 8. > > Even ignoring the previous item, the meaning of *[AVP] (or > *{AVP}) in a message (or grouped-avp) format definition is > unclear, and RFC 3588 contradicts itself. > > The description in 3.2 is > > ; The string "AVP" stands for *any* arbitrary > ; AVP Name, which does not conflict with the > ; required or fixed position AVPs defined in > ; the command code definition. > > According to this wording e.g., (a) Product-Name is allowed in > Abort-Session-Request, (b) multiple occurrences of User-Name are > allowed in Abort-Session-Request. Both of these are > contradicted in section 10. > > Taking section 10 a face value: (a) Product-Name must not occur > in an Abort-Session-Request, according to section 10, despite > the presence of *[AVP] in the message format, and (b) User-Name > must occur at most once in an ASR. > > My guess as to the actual intent of the spec, is that: > > The string "AVP" stands for *any* arbitrary AVP Name, > not otherwise listed in that command code grammar. > > [This allows case (a) above but not case (b)] > > The wording of section 10 then needs adjustment, to note that it > does not cover AVPs allowed because of *[AVP] in the grammar. > > It would also make sense to me to remove all MUSTs/MAYs from > section 10, and instead to state that it is a non-normative > summary of what is implied in the command code definitions. > > > 9. > > The section 10 table lists Result-Code as not being present in > ASA, contradicting the definition of that command. > > > 10. > > The section 10 wording > > "Note that AVPs that can only be present within a Grouped AVP > are not represented in this table" > > is imprecise. E.g., it could be taken to cover User-Name within > a Failed-AVP, on the grounds that it is not the case that > User-Name "can only be present within a Grouped AVP". > > A better wording would be "Note that AVPs occurrences contained > within a Grouped AVP are not represented in this table". > > > 11. > > If a TCP connection is established with a 4-way handshake (i.e., > both ends send SYNs simultaneously), then both ends will think > they are the initiator for CER/CEA exchange, and the exchange > then fails. Is it intended to not allow this? The wording > > A Diameter node MAY initiate connections from a source port > other than the one that it declares it accepts incoming > connections on, and > > strongly suggests that also a node may initiate connections with the > source port being the one on which it accepts incoming > connections (i.e., 3868), in which case 4-way TCP handshake is a > realistic possibility. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- Harish R Prabhu Bangalore, India. ------=_Part_8204_31788131.1184172466102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I have a couple of points/questions regarding Issue #11.

If there is a TCP connection establishment collision, wont
the election process decide who would be the initiator and who would
be the responder and break the tie?

Consider two peers A and B, both trying to set up TCP connection simultaneously.
Both receive the CER, but the election process would have put one of
the node in responder state and the other in initiator state. The
CER received at the (elected) initiator side would be dropped ideally and connection closed .

Isnt the statemachine handling this collision scenario currently?

Or did I get Ralph incorrectly?

thanks,
Harish

On 7/11/07, Ralph Loader <rloader@eservglobal.com> wrote:
Hi,

Following is a list of issues I've come across in rfc3588.

I think all are current in the 3588bis-05 draft.

Many are cases where taking the text at face value does not match what
appears to be intended.  A few actually concern how the protocol operates.

Apologies for any due to me not RTFM well enough.

Cheers,
Ralph.

1.

'Home Server' in section 1.3, is defined with 'See Diameter
Server'.  But looking at the definition of 'Diameter Server', I
do not see any indication of what a 'Home Server' is.

Is the intention that 'Home Server' is a synonym for 'Diameter
Server', or is there some other meaning?  (E.g., a 'Diameter
Server' serving a 'Home Realm').


2.

If multiple Inband-Security-Ids are shared in the CER/CEA
exchange, the spec does not say how to choose which one to use.


3.

"minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or
DIAMETER_MISSING_AVP) has several possible interpretations:
Minimum required for the basic datatype?  Minimum required for
the derived datatype?  Minimum required for successful
processing?

If it's minimum required for the datatype, and the datatype is
Grouped, is the minimum length the minimum for any grouped AVP
(i.e., empty payload) or the minimum for this particular AVP (in
which case zero-filling may generate a corrupt AVP)?


4.

Re DIAMETER_INVALID_AVP_LENGTH again, if the length received is
less than 12 but the AVP is vendor-specific, what should be put
in the Vendor-Id when creating the Failed-AVP?


5.

The <answer-message> (defined under 7.2. Error Bit) has just
[Proxy-Info] whereas everything else has *[Proxy-Info].
Presumably, *[Proxy-Info] is intended.

Also, <answer-message> ironically does not include
[Error-Message], and [Failed-AVP], unlike all other answers.

Although the inclusion of *[AVP] makes their omission formally
harmless, it would seem sensible to include them.


6.

The Vendor-Specific-Application-Id definition in
rfc3588bis-draft-05 does not use the grammar that according to
that document MUST be used.

Assuming that the intention is that one and only one of
Auth-Application-Id or Acct-Application-Id is present, the best
thing to do would be to make both optional in the grammar and
include the additional constraint in the text that exactly one MUST be
present.


7.

I don't think that the text

   "AVPs may be added arbitrarily to Diameter messages, so long
    as the required AVPs are included and AVPs that are
    explicitly excluded are not included."

is really what is intended.

I assume that the absense of *[AVP] in a message definition
means that unlisted AVPs may not be added arbitrarily to that
message, but I can see no text by which that is 'explicitly excluded'.

The current text makes the presence or absence of *[AVP] in a
message definition meaningless.


8.

Even ignoring the previous item, the meaning of *[AVP] (or
*{AVP}) in a message (or grouped-avp) format definition is
unclear, and RFC 3588 contradicts itself.

The description in 3.2 is

                       ; The string "AVP" stands for *any* arbitrary
                       ; AVP Name, which does not conflict with the
                       ; required or fixed position AVPs defined in
                       ; the command code definition.

According to this wording e.g., (a) Product-Name is allowed in
Abort-Session-Request, (b) multiple occurrences of User-Name are
allowed in Abort-Session-Request.  Both of these are
contradicted in section 10.

Taking section 10 a face value: (a) Product-Name must not occur
in an Abort-Session-Request, according to section 10, despite
the presence of *[AVP] in the message format, and (b) User-Name
must occur at most once in an ASR.

My guess as to the actual intent of the spec, is that:

         The string "AVP" stands for *any* arbitrary AVP Name,
         not otherwise listed in that command code grammar.

[This allows case (a) above but not case (b)]

The wording of section 10 then needs adjustment, to note that it
does not cover AVPs allowed because of *[AVP] in the grammar.

It would also make sense to me to remove all MUSTs/MAYs from
section 10, and instead to state that it is a non-normative
summary of what is implied in the command code definitions.


9.

The section 10 table lists Result-Code as not being present in
ASA, contradicting the definition of that command.


10.

The section 10 wording

    "Note that AVPs that can only be present within a Grouped AVP
    are not represented in this table"

is imprecise.  E.g., it could be taken to cover User-Name within
a Failed-AVP, on the grounds that it is not the case that
User-Name "can only be present within a Grouped AVP".

A better wording would be "Note that AVPs occurrences contained
within a Grouped AVP are not represented in this table".


11.

If a TCP connection is established with a 4-way handshake (i.e.,
both ends send SYNs simultaneously), then both ends will think
they are the initiator for CER/CEA exchange, and the exchange
then fails.  Is it intended to not allow this?  The wording

      A Diameter node MAY initiate connections from a source port
      other than the one that it declares it accepts incoming
      connections on, and

strongly suggests that also a node may initiate connections with the
source port being the one on which it accepts incoming
connections (i.e., 3868), in which case 4-way TCP handshake is a
realistic possibility.


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India. ------=_Part_8204_31788131.1184172466102-- --===============1773618920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1773618920==-- From dime-bounces@ietf.org Wed Jul 11 13:20:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8frW-0001kL-5I; Wed, 11 Jul 2007 13:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8frT-0001gu-DV for dime@ietf.org; Wed, 11 Jul 2007 13:20:23 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8fr2-0007bi-6f for dime@ietf.org; Wed, 11 Jul 2007 13:20:23 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2723223waf for ; Wed, 11 Jul 2007 10:19:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tqd32M4Edk9kLBwSttGH7sfs2xg2E2ulshfzJAAoOgwo0PFjZYy1x4FZ7JYSkcJWysVwLy92hnTpGOFvPLWcuFbfDRtUMnd49f2wde4SBO1CUXBgo3cw7i9oj63JHEZ46URxkHWp/Yr75IFs14CLL9RgHNhsMldiTi05Uk1vgek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=N2T0dIVzwM9Fiz9Bkqte+UYXSOgXgIEIpw3HC3jN0UkdUMjgkGVS9FMKJuly5U9w9+derGekVFJ+dUI7UGGDMMldPo13+bg5ecI1SvcqNMX6O1YGtgecho9cpcFY4a2DCWllMHsuFvuillZutMfZTzj4h/Oo7FG5zJQYAWQXViI= Received: by 10.115.106.7 with SMTP id i7mr5331286wam.1184174394804; Wed, 11 Jul 2007 10:19:54 -0700 (PDT) Received: by 10.115.79.17 with HTTP; Wed, 11 Jul 2007 10:19:54 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 19:19:54 +0200 From: "Thomas Lindgren" To: dime@ietf.org Subject: Re: [Dime] Several rfc 3588 issues. In-Reply-To: <46950232.1050906@tari.toshiba.com> MIME-Version: 1.0 References: <4693F31F.2090701@eservglobal.co.nz> <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> <55348.203.173.189.191.1184137685.squirrel@webmail.eservglobal.co.nz> <46950232.1050906@tari.toshiba.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1561669071==" Errors-To: dime-bounces@ietf.org --===============1561669071== Content-Type: multipart/alternative; boundary="----=_Part_7834_412844.1184174394762" ------=_Part_7834_412844.1184174394762 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/11/07, Victor Fajardo wrote: > > > Just to summarize the cases for INVALID_AVP_LENGTH: > > a. length >= 12: the receiver can probably decode the header since it > can tell whether the length field is incorrect in the first place. In > this the existing scheme works. If it cannot decode the AVP (corruption) > then this falls under (b). > b. length < 12: Likely possibility that the AVP header cannot be > decoded. This is regardless and whether the AVP is vendor specific or > not, or whether initial portions of the header are still parsable. In > this case, I would suggest doing a best-effort, catch-all scheme where > the reporter of the error sends the set of offending octects with > additional padding for a total of 12-octets (header size). It is > preferable if avoid specifying special conditions for corner case > scenarios that adds very little value. Comments ? Here is a suggestion: One simple, straightforward approach is to define Failed-AVP to have the type OctetString instead of 1*{AVP}. This approach means there is no need for special cases when the bad AVP is malformed. Instead, when there is an error just wrap the offending data and let the originator figure out what went wrong when the reply arrives (using Failed-AVP, Result-Code, Error-Message and so on). Note that it might furthermore be _nice_ to cleanly separate multiple AVPs in the Failed-AVP body, but it's not strictly necessary as far as I can tell: instead, as part of error processing just try to decode the OctetString contents as one or more AVPs. The code for doing that would basically be the same as for decoding the current Failed-AVP. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_7834_412844.1184174394762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/11/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:

Just to summarize the cases for INVALID_AVP_LENGTH:

a. length >= 12: the receiver can probably decode the header since it
can tell whether the length field is incorrect in the first place. In
this the existing scheme works. If it cannot decode the AVP (corruption)
then this falls under (b).
b. length < 12: Likely possibility that the AVP header cannot be
decoded. This is regardless and whether the AVP is vendor specific or
not, or whether initial portions of the header are still parsable. In
this case, I would suggest doing a best-effort, catch-all scheme where
the reporter of the error sends the set of offending octects with
additional padding for a total of 12-octets (header size). It is
preferable if avoid specifying special conditions for corner case
scenarios that adds very little value. Comments ?

Here is a suggestion: One simple, straightforward approach is to define Failed-AVP to have the type OctetString instead of 1*{AVP}. This approach means there is no need for special cases when the bad AVP is malformed. Instead, when there is an error just wrap the offending data and let the originator figure out what went wrong when the reply arrives (using Failed-AVP, Result-Code, Error-Message and so on).

Note that it might furthermore be _nice_ to cleanly separate multiple AVPs in the Failed-AVP body, but it's not strictly necessary as far as I can tell: instead, as part of error processing just try to decode the OctetString contents as one or more AVPs. The code for doing that would basically be the same as for decoding the current Failed-AVP.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd





------=_Part_7834_412844.1184174394762-- --===============1561669071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1561669071==-- From dime-bounces@ietf.org Wed Jul 11 13:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g8s-0008Ll-Nq; Wed, 11 Jul 2007 13:38:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g8q-0008LO-S9 for dime@ietf.org; Wed, 11 Jul 2007 13:38:20 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8g8l-0000Fg-Ju for dime@ietf.org; Wed, 11 Jul 2007 13:38:20 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6BHbUGh051428; Wed, 11 Jul 2007 13:37:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4695155C.30103@tari.toshiba.com> Date: Wed, 11 Jul 2007 13:37:32 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Thomas Lindgren Subject: Re: [Dime] Several rfc 3588 issues. References: <4693F31F.2090701@eservglobal.co.nz> <008a01c7c37d$e55268a0$3a17120a@china.huawei.com> <55348.203.173.189.191.1184137685.squirrel@webmail.eservglobal.co.nz> <46950232.1050906@tari.toshiba.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Thomas, Comments inline: > a. length >= 12: the receiver can probably decode the header since it > can tell whether the length field is incorrect in the first place. In > this the existing scheme works. If it cannot decode the AVP > (corruption) > then this falls under (b). > b. length < 12: Likely possibility that the AVP header cannot be > decoded. This is regardless and whether the AVP is vendor specific or > not, or whether initial portions of the header are still parsable. In > this case, I would suggest doing a best-effort, catch-all scheme where > the reporter of the error sends the set of offending octects with > additional padding for a total of 12-octets (header size). It is > preferable if avoid specifying special conditions for corner case > scenarios that adds very little value. Comments ? > > > Here is a suggestion: One simple, straightforward approach is to > define Failed-AVP to have the type OctetString instead of 1*{AVP}. > This approach means there is no need for special cases when the bad > AVP is malformed. Instead, when there is an error just wrap the > offending data and let the originator figure out what went wrong when > the reply arrives (using Failed-AVP, Result-Code, Error-Message and so > on). Theoretically, its straightforward. Though what would happen to errors like contradicting AVPs, invalid avp values etc. Failed-AVP was designed to indicate which is the offending avps in these cases. Another issue maybe is backward compatibility with existing implementation (if people care about it). Maybe the octetstring scheme can be useful for malformed AVPs/messages only ... -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 14:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gio-0006LM-DH; Wed, 11 Jul 2007 14:15:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8giN-0005YF-Ae; Wed, 11 Jul 2007 14:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8giN-0001FA-2F; Wed, 11 Jul 2007 14:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B158B1761B; Wed, 11 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8giM-0003DL-7x; Wed, 11 Jul 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 14:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-split-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Bournelle, et al. Filename : draft-ietf-dime-mip6-split-04.txt Pages : 22 Date : 2007-7-11 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and the Diameter server. Two different mechanisms for authentication of a MN to the HA are supported. The first method consists of performing the Internet Key Exchange v2 (IKEv2) protocol along with the Extensible Authentication Protocol (EAP) with the Diameter server, while the second method utilizes the Mobile IPv6 Authentication option, as defined in RFC 4285. For Internet Key Exchange v2 with EAP-based authentication, the Diameter Mobile IPv6 application, defined in this document, reuses the commands defined in the Diameter EAP application, while for supporting the RFC 4285-style MIPv6 Authentication Options, a new Diameter application and new command codes are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-split-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-split-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11134712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11134712.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jul 11 14:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hFn-0000uR-3f; Wed, 11 Jul 2007 14:49:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hFl-0000uF-Sq for dime@ietf.org; Wed, 11 Jul 2007 14:49:33 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8hFl-0003zX-Ia for dime@ietf.org; Wed, 11 Jul 2007 14:49:33 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6BInH9r016162 for ; Wed, 11 Jul 2007 14:49:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Date: Wed, 11 Jul 2007 14:49:17 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718805B@sonusmail04.sonusnet.com> In-Reply-To: <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Thread-Index: AcfDo7vKoRNQNLFXR7CXfedELG6gagARyFtw References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, One question about the proposed addition: What type of scenarios would require pull-mode of operation, if = authorizing entity receives a request from an application server? Thanks, Tolga ________________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, July 11, 2007 6:09 AM To: dime@ietf.org; Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network = related information" Hi Guys, After discussion with Hannes and Dong, I think it might be better to = modify like this. It is the recovering of the texts about=20 "PULL/PUSH/Access network related information" deleted by mistake or = misunderstanding =A0 3=A0=A0=A0 Framework [snipped] In some deployment scenarios, QoS aware network elements may request authorization through the AAA cloud based on an incoming QoS = reservation request. The network element will route the request to a = designated authorizing entity. The authorizing entity will return the result = of the authorization decision. In other deployment scenarios, the = authorization will be initiated upon dynamic application state, so that the = request must be authenticated and authorized based on information from one = or more application servers. /*start of added*/In terms of the = resource request sent from=20 the application server to Authorizing Entity, the Authorizing = Entity=20 could identify the access network related information and select = appropriate=20 resource admission and control policies. The Push or pull mode = also can be=20 dynamically triggered based on the information in the request from = application server, or statically configured according to operator's demand./*end = of added*/ [snipped] =A0 B. R. Tina ----- Original Message -----=20 From: Tina TSOU=20 To: dime@ietf.org=20 Sent: Monday, July 09, 2007 5:27 PM Subject: [Dime] Diameter QoS Appl. Hi all, I suggest that some texts=A0could be added in the beginning of 3.3 to = smooth with the texts in 3.3.1 and 3.3.2. =A0 [snipped] 3.3.=A0 Authorization schemes =A0=A0 Three basic authorization models for QoS reservations exist: one = two =A0=A0 -party and two three party models.=A0 In the three party QoS = model =A0=A0 (Figure 3), the authorization entity may be composed of two = separate =A0=A0 functional entities - Application Server which interacts with the = QoS =A0=A0 requesting entity and Authorizing Entity.=A0 The Application = Server MAY =A0=A0 indicate the access network related information in a service = request =A0=A0 to Authorizing Entity which can be used by the Authorizing Entity = to =A0=A0 select the appropriate resource admission and control = policies.=A0 The =A0=A0 service request from Application Server to Authorizing Entity MAY =A0=A0 also indicate the admission control mode (i.e., "pull" or "push" =A0=A0 model) in terms of which Authorizing Entity performs QoS =A0=A0 authorization and then sends the policy decisions to the NE which =A0=A0 performs QoS reservation. Authorization schemes for both pull =A0=A0 and push mode will be described below in detail. 3.3.1.=A0 Authorization schemes for pull mode [snipped] B. R. Tina ________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 15:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hR7-0005tJ-0R; Wed, 11 Jul 2007 15:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hR6-0005t9-1w for dime@ietf.org; Wed, 11 Jul 2007 15:01:16 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8hR2-0003mv-MI for dime@ietf.org; Wed, 11 Jul 2007 15:01:16 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6BJ1CpC024622 for ; Wed, 11 Jul 2007 15:01:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode Date: Wed, 11 Jul 2007 15:01:12 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718805C@sonusmail04.sonusnet.com> In-Reply-To: <4694B447.8080800@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.- terminal working mode Thread-Index: AcfDqGRhq49MoRLcQZ6fGwUOlcyaMAARPHlw References: <4694B447.8080800@gmx.net> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, I have one question/concern about this: The value of Terminal-Mode would have an implicit (and not defined by this specification) meaning with it, i.e. each element may interpret it differently. Maybe an approach, where we have separate AVPs for all pieces of information which we think could be extracted from Terminal-Type, could be less ambiguous. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, July 11, 2007 6:43 AM > To: dime@ietf.org; Tina TSOU > Subject: [Dime] Diameter QoS Appl.- terminal working mode >=20 > FYI >=20 > ------ >=20 > This is without the attachment. >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: Tina TSOU > To: dime@ietf.org > Sent: Wednesday, July 11, 2007 6:26 PM > Subject: Diameter QoS Appl.- terminal working mode >=20 >=20 > Hi Guys, > To converge different kind of authorizing entities and performing NEs, > terminal-Mode can tell the performing NE how to choose the interface > working mode. First, we can find which mode the terminal is by Terminal- > mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi- > mode, and each mode may have different QoS > profile, so the terminal-mode AVP can help to the operation on match QoS > request and QoS control. > The following changes are proposed. (You can also find the changes in > the attachment.) > section 6.2 >=20 >
>=20 > The QoS-Authorization-Answer message (QAA), indicated by the >=20 > Command- Code field set to TBD and 'R' bit cleared in the > Command >=20 > Flags field is sent in response to the QoS-Authorization-Request >=20 > message (QAR). To converge different kind of authorizing > entities >=20 > and performing NEs, terminal-Mode can tell the performing NE how >=20 > to choose the interface working mode. If the QoS authorization > request >=20 > is successfully authorized, the response will include the AVPs > to >=20 > allow authorization of the QoS resources as well as accounting > and >=20 > transport plane gating information. >=20 > The message format is defined as follows: >=20 >=20 >=20 >
>=20 > =20 > ::=3D < Diameter Header: XXX, PXY > >=20 > < Session-Id > >=20 > { Auth-Application-Id } >=20 > { Auth-Request-Type } >=20 > { Result-Code } >=20 > { Origin-Host } >=20 > { Origin-Realm } >=20 > [ Terminal-Mode ] >=20 > * [ QoS-Resources ] >=20 > [ CC-Time ] >=20 > [ Acc-Multisession-Id ] >=20 > [ Session-Timeout ] >=20 > [ Authz-Session-Lifetime ] >=20 > [ Authz-Grace-Period ] >=20 > * [ AVP ] >=20 > ]]> >=20 >
>=20 >
>=20 >=20 >=20 > section 6.3 >=20 >
>=20 > The QoS-Install Request message (QIR), indicated by the >=20 > Command-Code field set to TDB and 'R' bit set in the Command > Flags >=20 > field is used by Authorizing entity to install or update the QoS >=20 > parameters and the flow state of an authorized flow at the > transport >=20 > plane element. >=20 >=20 >=20 > The message MUST carry information for signaling session >=20 > identification or identification of the flow to which the > provided QoS >=20 > rules apply, working mode of the terminal, identity of the > transport >=20 > plane element, description of provided QoS parameters, flow > state and >=20 > duration of the provided authorization. >=20 >=20 >=20 > The message format is defined as follows: >=20 >=20 >=20 >
>=20 > =20 > ::=3D < Diameter Header: XXX, REQ, PXY > >=20 > < Session-Id > >=20 > { Auth-Application-Id } >=20 > { Origin-Host } >=20 > { Origin-Realm } >=20 > [ Terminal-Mode ] >=20 > { Destination-Realm } >=20 > { Auth-Request-Type } >=20 > [ Destination-Host ] >=20 > * [ QoS-Resources ] >=20 > [ Session-Timeout ] >=20 > [ Authz-Session-Lifetime ] >=20 > [ Authz-Grace-Period ] >=20 > [ Authz-Session-Volume ] >=20 > * [ AVP ] >=20 > ]]> >=20 >
>=20 >
>=20 >=20 >=20 > [snipped] >=20 >=20 >=20 > section 7.1 >=20 >
>=20 > =20 > Attribute Name AVP Code Reference [RFC3588] >=20 > Origin-Host 264 Section 6.3 >=20 > Origin-Realm 296 Section 6.4 >=20 > Terminal-Mode TBD >=20 >=20 > B. R. >=20 > Tina >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 15:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hVc-0000C4-Td; Wed, 11 Jul 2007 15:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hVb-0000Bl-MW for dime@ietf.org; Wed, 11 Jul 2007 15:05:55 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8hVX-0003sH-8A for dime@ietf.org; Wed, 11 Jul 2007 15:05:55 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1404426nzf for ; Wed, 11 Jul 2007 12:05:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=RfRyqqbUo3yx7mPQAeJHY3c1Tke+MTI+amqdUboXoEMTBG4sujay8RyZ9/oP9Nu2AbQFjjZqtltrZyBaEGmeTo3eHFWKJr8Vt65aMG+XO4NyXaF6TpojI4d1bAqFknY3xcdtJ/7jL5hVogYljLMCJ8FTebsUKZRNe07ZBBpKpo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=CMDMLyCaJ6+3IB63Xi1SN3onAneLNXtKTflIZiv3FcmK5T9hwhycW2Io3s3I2tFHBq9elApwwNzvxunMGkPmihSdwLcn84idTRo5UIn36yGF4DJWC9PiH+UO6Cc8UdSzZ2uKRpCnE6WTLV/WhlrCZGBNL0j64VSXX0Cw0t0IgpA= Received: by 10.143.41.12 with SMTP id t12mr424968wfj.1184180748228; Wed, 11 Jul 2007 12:05:48 -0700 (PDT) Received: by 10.143.41.21 with HTTP; Wed, 11 Jul 2007 12:05:48 -0700 (PDT) Message-ID: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> Date: Wed, 11 Jul 2007 16:05:48 -0300 From: "Christian Esteve" To: dime@ietf.org, "Tina TSOU" , "Hannes Tschofenig" Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" MIME-Version: 1.0 X-Google-Sender-Auth: 56aaff32d8820211 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1846762830==" Errors-To: dime-bounces@ietf.org --===============1846762830== Content-Type: multipart/alternative; boundary="----=_Part_7026_20574462.1184180748207" ------=_Part_7026_20574462.1184180748207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! My 2 cents: > But how should the AF know anything about the access network > characteristics? (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] [Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used to optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain. To my understasnding this information can be used by the AF to choose the appropriate QoS template. E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 ] Best regards, Christian ------------------------------ Message: 4 Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-ID: <032c01c7c3af$67904630$864c460a@china.huawei.com> Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response ----- Original Message ----- From: "Hannes Tschofenig" To: ; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes ------=_Part_7026_20574462.1184180748207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi!

My 2 cents:

> But how should the AF know anything about the access network
> characteristics? (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]

[Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the  P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used  to   optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain.
To my understasnding this information can be used by the AF to choose the appropriate QoS template.

E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
]

Best regards,
Christian

------------------------------

Message: 4
Date: Wed, 11 Jul 2007 19:34:12 +0800
From: Tina TSOU < tena@huawei.com>
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
       related information"
To: dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com>
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
       reply-type=response


----- Original Message -----
From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net>
To: < dime@ietf.org>; "Tina TSOU" <tena@huawei.com>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-  "PULL/PUSH/Access network related
information"


> Hi Tina,
>
> who translates high-level QoS information used at the application layer
> into information that is appropriate for a QoS model that is used in a
> particular access network. In your model it seems that the AF is in charge
> of assisting whereas the PDF does the final translation. In any case, it
> is not the NE that does it.
>
> Correct?
[Tina: Correct.]
>
> But how should the AF know anything about the access network
> characteristics?
> (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]
>
>
> Ciao
> Hannes ------=_Part_7026_20574462.1184180748207-- --===============1846762830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1846762830==-- From dime-bounces@ietf.org Wed Jul 11 15:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hef-00064J-Io; Wed, 11 Jul 2007 15:15:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8heR-0005MJ-9l; Wed, 11 Jul 2007 15:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8heR-0004dx-25; Wed, 11 Jul 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 60ED9175FB; Wed, 11 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8heP-0006oX-Vo; Wed, 11 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-qos-attributes-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter and RADIUS Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-01.txt Pages : 23 Date : 2007-7-11 This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-attributes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-attributes-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11141751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11141751.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jul 11 15:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hej-0006Hq-6a; Wed, 11 Jul 2007 15:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8heR-0005MU-CF; Wed, 11 Jul 2007 15:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8heQ-00041Z-3t; Wed, 11 Jul 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 16E5E329F8; Wed, 11 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8heP-0006oR-UQ; Wed, 11 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 15:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-qos-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Quality of Service Application Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-diameter-qos-01.txt Pages : 53 Date : 2007-7-11 This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-qos-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-qos-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11141325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11141325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jul 11 15:16:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hfb-0002L8-Qa; Wed, 11 Jul 2007 15:16:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hfb-0002Kn-CI for dime@ietf.org; Wed, 11 Jul 2007 15:16:15 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8hfa-0004il-P5 for dime@ietf.org; Wed, 11 Jul 2007 15:16:15 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6BJG20P001800; Wed, 11 Jul 2007 15:16:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 15:16:02 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718805D@sonusmail04.sonusnet.com> In-Reply-To: <9cf5ced20707110722r34373c52u5aa884f036c70490@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redundancy for Explicit Routing Thread-Index: AcfDxvrsqPuGBHoIQiG0rfsi+imCAgAJ22aw References: <46933368.4000701@gmx.net><002501c7c2ce$540406b0$864c460a@china.huawei.com> <9cf5ced20707110722r34373c52u5aa884f036c70490@mail.gmail.com> From: "Asveren, Tolga" To: "David Frascone" , "Tina TSOU" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: dime@ietf.org Subject: [Dime] Redundancy for Explicit Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org (changed subject line) I guess, this can be fixed/made better. Any proxy which wants to stay in = the path during the session may insert the identity of a backup proxy as = well in addition to its own identity, if such a proxy exists. This would = require some type of data synchronization between active/backup proxies, = but at least it is possible to provide support for such cases from = Diameter signaling perspective. This actually would be similar to "Redundancy Improvements" (Issue 25 in = the tracker). Thanks, Tolga=20 ________________________________________ From: David Frascone [mailto:dave@frascone.com]=20 Sent: Wednesday, July 11, 2007 10:23 AM To: Tina TSOU Cc: dime@ietf.org Subject: Re: [Dime] Tentative Agenda for DIME meeting On 7/10/07, Tina TSOU wrote: Hi Hannes and Dave, Thanks for the agenda. Is it possible to add a couple minutes in the end to show the topic "Diameter Explicit Routing and Re-direct"? There are some discussions in the ML and an update of I-D -03 about = Diameter=20 Explicit Routing was submitted by Victor, Jouni, Tolga and I. The = Re-direct topic will be provided in separate I-D. But we are going to show the technical relationships between them and the progress of discussion in = ML=20 and offline. I had a discussion with Victor about this at the last ietf.=A0 I did = have one=A0 concern: Explicit Routing effectively disables failover for existing = conversations.=A0 Since the nodes maintain state, if a node goes down, = the particular conversation will not be able to fail over.=A0 (New = conversations, however, would be able to find a new route through the = cloud, and would be unaffected)=20 I think this caveat needs to be presented in the draft.=A0 In bold = letters.=A0 I think it needs to be very obvious to implementers that = they're giving up some reliability if they choose this option. =20 -Dave --=20 David Frascone A big enough hammer fixes anything=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 15:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8iCC-0003mb-6Y; Wed, 11 Jul 2007 15:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8iCB-0003mQ-0T for dime@ietf.org; Wed, 11 Jul 2007 15:49:55 -0400 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8iC6-0005tW-E4 for dime@ietf.org; Wed, 11 Jul 2007 15:49:54 -0400 Received: (qmail 58397 invoked by uid 60001); 11 Jul 2007 19:49:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=0JZrgRwuXopRw8t7R/sSmQY5y/6xqaORnhcdGyIFNZKR9WYvn9I1mveyW2XLaXSrZN8OyVmu73MvhSJiUN5CrVSRrTrB9aBDGQt0AZJMKqKtGVQB3bJor/kB8PsKPiIarLZIJCNouzSz96wrBE8Xe+1Iidp2T5oLnuY/n/wt2xA=; X-YMail-OSG: xOHADk8VM1lEsdM9EUATL3OHkVCQYXRHPahNFGwRBPcwgl_el6KEP_WJ2RmE6H_KGm.KB.L9PoL5E66hqVGEbiRXuelULs6uTKCiAV_ImxvJCYE- Received: from [206.16.17.212] by web84107.mail.mud.yahoo.com via HTTP; Wed, 11 Jul 2007 12:49:49 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Wed, 11 Jul 2007 12:49:49 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt To: jouni.korhonen@teliasonera.com MIME-Version: 1.0 Message-ID: <989668.57921.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org, netlmm@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1266840640==" Errors-To: dime-bounces@ietf.org --===============1266840640== Content-Type: multipart/alternative; boundary="0-974971352-1184183389=:57921" --0-974971352-1184183389=:57921 Content-Type: text/plain; charset=ascii Hi Jouni, I read the draft and have some comments: Given the fact that Radius is still around and in Diameter it is possible to make things quite Radius compatible, I wonder why you have not used already existing attributes? I mean the attributes defined in draft-ietf-mip6-radius-02? Regards, Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: netlmm@ietf.org; dime@ietf.org Sent: Thursday, July 5, 2007 4:13:32 AM Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > > This specification defines the Diameter support for the > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt > --0-974971352-1184183389=:57921 Content-Type: text/html; charset=ascii
Hi Jouni,
  I read the draft and have some comments:
Given the fact that Radius is still around and in Diameter it is possible to make things quite Radius compatible, I wonder why you have not used already existing attributes? I mean the attributes defined in draft-ietf-mip6-radius-02?

Regards,

Behcet

----- Original Message ----
From: "jouni.korhonen@teliasonera.com" <jouni.korhonen@teliasonera.com>
To: netlmm@ietf.org; dime@ietf.org
Sent: Thursday, July 5, 2007 4:13:32 AM
Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt


FYI.. this Dime I-D might be of interest for PMIPv6 folks. The
I-D describes MAG-AAA and LMA-AAA Diameter interactions for
PMIPv6. Comments are welcome as a lot more work is still ahead.

Cheers,
    Jouni


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, June 28, 2007 10:50 PM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>     Title        : Diameter Proxy Mobile IPv6: Support For
>                           Mobility Access Gateway and Local Mobility
>                           Anchor to Diameter Server Interaction
>     Author(s)    : J. Korhonen, et al.
>     Filename    : draft-korhonen-dime-pmip6-00.txt
>     Pages        : 20
>     Date        : 2007-6-28
>     
>    This specification defines the Diameter support for the
> Proxy Mobile
>    IPv6.  The policy information needed by the Proxy Mobile IPv6 is
>    defined in mobile node's policy profile, which gets downloaded from
>    the Diameter server to the Mobile Access Gateway once the
> mobile node
>    roams into a Proxy Mobile IPv6 Domain and performs the access
>    authentication.  The access authentication procedure into the Proxy
>    Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario
>    bootstrapping.  Rather than defining a completely new set of
>    attributes or a new Diameter application this specification only
>    leverages the work already done for the Mobile IPv6 bootstrapping.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt
>

--0-974971352-1184183389=:57921-- --===============1266840640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1266840640==-- From dime-bounces@ietf.org Wed Jul 11 17:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jjX-00077r-6z; Wed, 11 Jul 2007 17:28:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jjW-00077Z-35 for dime@ietf.org; Wed, 11 Jul 2007 17:28:26 -0400 Received: from male.eservglobal.co.nz ([203.118.128.140] helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8jjH-0001DU-RW for dime@ietf.org; Wed, 11 Jul 2007 17:28:26 -0400 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6BLQFwu011368; Thu, 12 Jul 2007 09:26:25 +1200 Message-ID: <46954AF7.3020101@eservglobal.co.nz> Date: Thu, 12 Jul 2007 09:26:15 +1200 From: Ralph Loader User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Several rfc 3588 issues. References: <4693F31F.2090701@eservglobal.co.nz> <4694D9FA.9080002@tari.toshiba.com> In-Reply-To: <4694D9FA.9080002@tari.toshiba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.3/3639/Thu Jul 12 08:24:04 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor Fajardo wrote: > Hi Ralph, > > Thanks for the good review. Comments inline: > >> 'Home Server' in section 1.3, is defined with 'See Diameter >> Server'. But looking at the definition of 'Diameter Server', I >> do not see any indication of what a 'Home Server' is. >> >> Is the intention that 'Home Server' is a synonym for 'Diameter >> Server', or is there some other meaning? (E.g., a 'Diameter >> Server' serving a 'Home Realm'). how about we use empty payload ? >> > > Yes its suppose to be a synonym. Though I'm not sure what you mean by > empty payload. Looks like I hit the paste key by accident... > has them as OR (Note the "/" after auth-app-id). I'm assuming thats the This use of "/" is not described in the rfc3588 section 3.2 and section 4.4 description of the grammars. The phrasing: Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [RFC4234] (with modifications), as defined below. seems to make it clear that the section 4.4 grammar, not RFC4234, is normative. The use of "/" could be added to section 4.4, although it would seem preferable to me to treat the exceptional case ad. hoc. > make sense. How about re-wording from: > > "AVPs may be added arbitrarily to Diameter messages, > so long as the required AVPs are included and AVPs that are > explicitly excluded are not included." > > to: > > "AVPs may be added arbitrarily to Diameter messages, > so long as the requirements of a messages ABNF are > met and the ABNF allows for it." Much clearer. "message's ABNF" if I'm getting apostrophes correct today. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 18:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8l22-0004z5-Mg; Wed, 11 Jul 2007 18:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8l21-0004lL-7s for dime@ietf.org; Wed, 11 Jul 2007 18:51:37 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8l1w-0001TB-9N for dime@ietf.org; Wed, 11 Jul 2007 18:51:36 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6BMpNDi022360; Wed, 11 Jul 2007 17:51:27 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 17:51:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Date: Wed, 11 Jul 2007 17:51:24 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209A4@ILEXC2U01.ndc.lucent.com> In-Reply-To: <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Thread-Index: AcfDo73k3SgYy8YrThiuda+bxqRo5wAaKOVA References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> From: "Sun, Dong \(Dong\)" To: "Tina TSOU" , X-OriginalArrivalTime: 11 Jul 2007 22:51:25.0283 (UTC) FILETIME=[02700330:01C7C40E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1109143561==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1109143561== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C40E.020C0ABC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C40E.020C0ABC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tina, =20 It's ok to me to add the last sentence marked in red. but I am not sure about the first sentence in red.=20 It seems to me that the authorizing entity (i.e. policy server) is better to map the service attribute (from application server) into a set of generic network layer QoS parameters rather than translating into specific access technologies QoS. The mapping from generic QoS into access specific QoS is more appropriate to be executed in NE, IMO. =20 Moreover, as you stated, they are two irrelevant issues - the trigger of push/pull and access specific QoS mapping. It would be better to discuss them separately, i.e., make two separate proposals. =20 Regards, Dong ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, July 11, 2007 6:09 AM To: dime@ietf.org; Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" =09 =09 Hi Guys, After discussion with Hannes and Dong, I think it might be better to modify like this. It is the recovering of the texts about=20 "PULL/PUSH/Access network related information" deleted by mistake or misunderstanding =20 3 Framework [snipped] In some deployment scenarios, QoS aware network elements may request authorization through the AAA cloud based on an incoming QoS reservation request. The network element will route the request to a designated authorizing entity. The authorizing entity will return the result of the authorization decision. In other deployment scenarios, the authorization will be initiated upon dynamic application state, so that the request must be authenticated and authorized based on information from one or more application servers. /*start of added*/In terms of the resource request sent from=20 the application server to Authorizing Entity, the Authorizing Entity=20 could identify the access network related information and select appropriate=20 resource admission and control policies. The Push or pull mode also can be=20 dynamically triggered based on the information in the request from application server, or statically configured according to operator's demand./*end of added*/ [snipped] =20 B. R. Tina ----- Original Message -----=20 From: Tina TSOU =20 To: dime@ietf.org=20 Sent: Monday, July 09, 2007 5:27 PM Subject: [Dime] Diameter QoS Appl. Hi all, I suggest that some texts could be added in the beginning of 3.3 to smooth with the texts in 3.3.1 and 3.3.2. =20 [snipped] 3.3. Authorization schemes =09 Three basic authorization models for QoS reservations exist: one two -party and two three party models. In the three party QoS model (Figure 3), the authorization entity may be composed of two separate functional entities - Application Server which interacts with the QoS requesting entity and Authorizing Entity. The Application Server MAY indicate the access network related information in a service request to Authorizing Entity which can be used by the Authorizing Entity to select the appropriate resource admission and control policies. The service request from Application Server to Authorizing Entity MAY also indicate the admission control mode (i.e., "pull" or "push" model) in terms of which Authorizing Entity performs QoS authorization and then sends the policy decisions to the NE which performs QoS reservation. Authorization schemes for both pull and push mode will be described below in detail. =09 3.3.1. Authorization schemes for pull mode [snipped] =09 B. R. Tina =09 ________________________________ =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 ------_=_NextPart_001_01C7C40E.020C0ABC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
It's ok to me to add the last sentence = marked in red.=20 but I am not sure about the first sentence in red.
It seems to me that the authorizing entity = (i.e. policy=20 server) is better to map the service attribute (from application=20 server) into a set of generic network layer QoS parameters = rather than=20 translating into specific access technologies QoS. The mapping from = generic=20 QoS into access specific QoS is more appropriate to be executed in = NE,=20 IMO.
 
Moreover, as you stated, they are two = irrelevant issues - the trigger of push/pull and access = specific QoS=20 mapping. It would be better to discuss them separately, i.e., make two = separate=20 proposals.
 
Regards,
Dong

From: Tina TSOU = [mailto:tena@huawei.com]=20
Sent: Wednesday, July 11, 2007 6:09 AM
To: = dime@ietf.org;=20 Tina TSOU
Subject: Re: [Dime] Diameter QoS Appl. = -"PULL/PUSH/Access=20 network related information"

Hi Guys,
After discussion with Hannes and = Dong, I think it=20 might be better to modify like this. It is the recovering of the texts about
"PULL/PUSH/Access network = related=20 information" deleted by mistake or misunderstanding
 
3    = Framework
[snipped]

<t>In some deployment scenarios, QoS aware network = elements=20 may request

     =20 authorization through the AAA cloud based on an incoming QoS=20 reservation

     =20 request. The network element will route the request to a=20 designated

     =20 authorizing entity. The authorizing entity will return the = result of=20 the

     =20 authorization decision. In other deployment scenarios, the=20 authorization

     =20 will be initiated upon dynamic application state, so that the=20 request

     =20 must be authenticated and authorized based on information from = one=20 or

     =20 more application servers. /*start of=20 added*/In terms of the resource = request sent=20 from

     =20 the application server to Authorizing Entity, the Authorizing = Entity=20

     =20 could identify the access network related information and = select=20 appropriate

     =20 resource admission and control policies. The Push or pull mode = also can=20 be

     =20 dynamically triggered based on the information in the request = from=20 application

   server, or = statically=20 configured according to operator's demand./*end of added*/</t>

[snipped]

 

B. R.

Tina

----- Original Message -----
From:=20 Tina = TSOU
Sent: Monday, July 09, 2007 = 5:27=20 PM
Subject: [Dime] Diameter QoS=20 Appl.

Hi all,
I suggest that some = texts could be added=20 in the beginning of 3.3 to smooth
with the texts in 3.3.1 and = 3.3.2.
 
[snipped]
3.3.  Authorization = schemes

  =20 Three basic authorization models for QoS reservations exist: one=20 two
   -party and two three party models.  In the = three=20 party QoS model
   (Figure 3), the authorization entity = may be=20 composed of two separate
   functional entities - = Application=20 Server which interacts with the QoS
   requesting = entity and=20 Authorizing Entity.  The Application Server MAY
   = indicate the access network related information in a service=20 request
   to Authorizing Entity which can be used by = the=20 Authorizing Entity to
   select the appropriate = resource=20 admission and control policies.  The
   service = request=20 from Application Server to Authorizing Entity MAY
   = also=20 indicate the admission control mode (i.e., "pull" or = "push"
  =20 model) in terms of which Authorizing Entity performs = QoS
  =20 authorization and then sends the policy decisions to the NE=20 which
   performs QoS reservation. Authorization = schemes for=20 both pull
   and push mode will be described below in=20 detail.

3.3.1.  Authorization schemes for pull=20 mode
[snipped]
B. R.
Tina

_______________________________________________
DiME = mailing=20 = list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
<= /BLOCKQUOTE>
------_=_NextPart_001_01C7C40E.020C0ABC-- --===============1109143561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1109143561==-- From dime-bounces@ietf.org Wed Jul 11 19:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lG9-00053z-FD; Wed, 11 Jul 2007 19:06:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lG8-00053p-NN for dime@ietf.org; Wed, 11 Jul 2007 19:06:12 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8lG7-00035b-UU for dime@ietf.org; Wed, 11 Jul 2007 19:06:12 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6BN40vs013701; Wed, 11 Jul 2007 18:04:05 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 18:04:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" Date: Wed, 11 Jul 2007 18:04:02 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209A5@ILEXC2U01.ndc.lucent.com> In-Reply-To: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" Thread-Index: AcfD7o2YZLk+UtUsScq/VsYBo3kpgwAH6oSg References: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> From: "Sun, Dong \(Dong\)" To: "Christian Esteve" , , "Tina TSOU" , "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 23:04:03.0203 (UTC) FILETIME=[C6316D30:01C7C40F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1791283431==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1791283431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C40F.C59165CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C40F.C59165CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chirstian, =20 I agree, in certain circumstance e.g. IMS AF, it is possible to identify the access network as you described.=20 Maybe, I guess, there is some confusion (to me) on the terminology used here. If you are saying that AF may determine the service profile/attributes upon access type, it would be fine in certain case (but it is out of the scope in this doc). However, not sure if it is good idea to make the application server involved in network level QoS selection, even it is worse to make the AS select access specific QoS profile.=20 =20 Regards, Dong ________________________________ From: Christian Esteve [mailto:chesteve@gmx.net]=20 Sent: Wednesday, July 11, 2007 3:06 PM To: dime@ietf.org; Tina TSOU; Hannes Tschofenig Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" =09 =09 Hi! =09 My 2 cents: =09 > But how should the AF know anything about the access network > characteristics? (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.]=20 =09 [Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used to optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain.=20 To my understasnding this information can be used by the AF to choose the appropriate QoS template. =09 E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=3D234151D0FCE11 ] =09 Best regards, Christian =09 ------------------------------ =09 Message: 4 Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU < tena@huawei.com > Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com > Content-Type: text/plain; format=3Dflowed; charset=3Diso-8859-1; reply-type=3Dresponse =09 =09 ----- Original Message ----- From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net> To: < dime@ietf.org >; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related=20 information" =09 =09 > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge=20 > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network=20 > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes=20 ------_=_NextPart_001_01C7C40F.C59165CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chirstian,
 
I agree, in certain circumstance e.g. IMS AF, = it is=20 possible to identify the access network as you described. =
Maybe, I guess, there is some confusion (to = me) on the=20 terminology used here. If you are saying that AF may determine = the=20 service profile/attributes upon access type, it would be fine in certain = case=20 (but it is out of the scope in this doc). However, not sure if it is = good idea=20 to make the application server involved in network level QoS selection, = even it=20 is worse to make the AS select access specific QoS profile.=20
 
Regards,
Dong

From: Christian Esteve=20 [mailto:chesteve@gmx.net]
Sent: Wednesday, July 11, 2007 = 3:06=20 PM
To: dime@ietf.org; Tina TSOU; Hannes=20 Tschofenig
Subject: Re: [Dime] Diameter QoS Appl.- = "PULL/PUSH/Access=20 network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access = network=20 relatedinformation"

Hi!

My 2 cents:

> But how should the = AF know=20 anything about the access network
> characteristics? (unless it = is in=20 the access network itself)
[Tina: it is configured by the=20 operator/administrator.]

[Christian: Agree that the = configuration of=20 the AF is provided by the administrative domain. Additionally, the AF = may know=20 through application level user signaling (UE-AF) aboout the access = network=20 type for which the session authorization applies. E.g.the  = P-Access-=20 Network-Info [RFC 3455] used in the IMS SIP signaling relays = information about=20 the access technology that may then be used  to   = optimize=20 services (e.g. location-based, bw optimized) for the UA at the home = domain and=20 it could be useful to perform accurate access network resource = authorization=20 requests at the visited domain.
To my understasnding this = information can=20 be used by the AF to choose the appropriate QoS=20 template.

E.g. P-Access-Network-Info: = 3GPP-UTRAN-TDD;=20 utran-cell-id-3gpp=3D234151D0FCE11
]

Best=20 = regards,
Christian

------------------------------
Message:=20 4
Date: Wed, 11 Jul 2007 19:34:12 +0800
From: Tina TSOU < tena@huawei.com>
Subject: = Re: [Dime]=20 Diameter QoS Appl.- "PULL/PUSH/Access network
     =20  related information"
To: dime@ietf.org, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net&g= t;
Message-ID:=20 <=20 = 032c01c7c3af$67904630$864c460a@china.huawei.com>
Content-Type: = text/plain; format=3Dflowed; charset=3Diso-8859-1;
    =  =20  reply-type=3Dresponse


----- Original Message = -----
From:=20 "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net&g= t;
To:=20 < dime@ietf.org>; "Tina TSOU" = <tena@huawei.com>
Sent: = Wednesday, July=20 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-=20  "PULL/PUSH/Access network related =
information"


> Hi=20 Tina,
>
> who translates high-level QoS information used = at the=20 application layer
> into information that is appropriate for a = QoS model=20 that is used in a
> particular access network. In your model it = seems=20 that the AF is in charge
> of assisting whereas the PDF does = the final=20 translation. In any case, it
> is not the NE that does=20 it.
>
> Correct?
[Tina: Correct.]
>
> But = how=20 should the AF know anything about the access network
>=20 characteristics?
> (unless it is in the access network = itself)
[Tina:=20 it is configured by the = operator/administrator.]
>
>
>=20 Ciao
> Hannes
------_=_NextPart_001_01C7C40F.C59165CE-- --===============1791283431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1791283431==-- From dime-bounces@ietf.org Wed Jul 11 19:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lPV-000844-FY; Wed, 11 Jul 2007 19:15:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lPU-00083i-8r; Wed, 11 Jul 2007 19:15:52 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8lPT-0003gg-T5; Wed, 11 Jul 2007 19:15:52 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 01:15:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Date: Thu, 12 Jul 2007 01:15:09 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F27269@SEHAN021MB.tcad.telia.se> In-Reply-To: <989668.57921.qm@web84107.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Thread-Index: AcfD9KmUVfxaHm57Qii5/U6rnwspjAAGezCQ References: <989668.57921.qm@web84107.mail.mud.yahoo.com> From: To: X-OriginalArrivalTime: 11 Jul 2007 23:15:10.0166 (UTC) FILETIME=[53BBE760:01C7C411] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: dime@ietf.org, netlmm@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Behcet, =20 Because I want to have a clean separation from NAS (i.e. MAG) and AAA point of view which AVPs belong to PMIP6 side and which to e.g. MIP6 side. The same NAS/AAA may be used to bootstrap MIP6, or bootstrap PMIP6.. or do both at the same time (and I am not defining new applications to do the separation). There are some AVPs from rfc4004 that I am looking forward to reuse, if just feasible. =20 Cheers, Jouni=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Wednesday, July 11, 2007 10:50 PM To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc: netlmm@ietf.org; dime@ietf.org Subject: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt =09 =09 Hi Jouni, I read the draft and have some comments: Given the fact that Radius is still around and in Diameter it is possible to make things quite Radius compatible, I wonder why you have not used already existing attributes? I mean the attributes defined in draft-ietf-mip6-radius-02? =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: netlmm@ietf.org; dime@ietf.org Sent: Thursday, July 5, 2007 4:13:32 AM Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt=20 =09 =09 FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. =09 Cheers, Jouni =09 =09 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility=20 > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > =20 > This specification defines the Diameter support for the=20 > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the=20 > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt >=20 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 19:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lXd-0008QH-Fn; Wed, 11 Jul 2007 19:24:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lXb-0008Q6-Pm for dime@ietf.org; Wed, 11 Jul 2007 19:24:15 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8lXb-0003wN-6F for dime@ietf.org; Wed, 11 Jul 2007 19:24:15 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6BNM97f007698; Wed, 11 Jul 2007 18:22:10 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 18:22:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode Date: Wed, 11 Jul 2007 18:22:09 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209A6@ILEXC2U01.ndc.lucent.com> In-Reply-To: <032001c7c3af$07676c20$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.- terminal working mode Thread-Index: AcfDrzckNy9Rc3D3ThWqFGYllwDe7gAYSpLw References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> <032001c7c3af$07676c20$864c460a@china.huawei.com> From: "Sun, Dong \(Dong\)" To: "Tina TSOU" , , "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 23:22:09.0933 (UTC) FILETIME=[4DEF43D0:01C7C412] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, It seems you intend to make use of this new AVP to indicate the access network type, or more specific - QoS profile to facilitate the authorizing entity on the policy decision, is it correct? Then this proposal is more or less related to the access network related info issue in another thread, better to consolidate them together.=20 As stated in another email, I am not sure if it is good idea to make authorizing entity specific to each access technologies in the context of QoS mapping and policy control, especially for inter-domain scenario. Maybe I misunderstood your point... Regards, Dong -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, July 11, 2007 7:32 AM To: dime@ietf.org; Hannes Tschofenig Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode ----- Original Message ----- From: "Hannes Tschofenig" To: ; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > Hi Tina, > > who translates high-level QoS information used at the application layer=20 > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge=20 > of assisting whereas the PDF does the final translation. In any case, it=20 > is not the NE that does it. > > Correct? [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > > But how should the AF know anything about the access network=20 > characteristics? > (unless it is in the access network itself) [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > What information would you put into the Terminal-Mode AVP? [Tina: First, we can find which mode the terminal is by Terminal-mode, for=20 example 3GPP, WiFi, Wimax, etc. The user terminal may be multi-mode, and each mode may have different QoS profile, so the terminal-mode AVP can help to the operation on match QoS request and QoS control.] > > Ciao > Hannes > > Hannes Tschofenig wrote: >> FYI >> >> ------ >> >> This is without the attachment. >> >> B. R. >> Tina >> >> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent:=20 >> Wednesday, July 11, 2007 6:26 PM >> Subject: Diameter QoS Appl.- terminal working mode >> >> >> Hi Guys, >> To converge different kind of authorizing entities and performing NEs,=20 >> terminal-Mode can tell the performing NE how to choose the interface=20 >> working mode. First, we can find which mode the terminal is by=20 >> Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may=20 >> be multi-mode, and each mode may have different QoS >> profile, so the terminal-mode AVP can help to the operation on match QoS=20 >> request and QoS control. >> The following changes are proposed. (You can also find the changes in=20 >> the attachment.) >> section 6.2 >> >>
>> >> The QoS-Authorization-Answer message (QAA), indicated by the >> >> Command- Code field set to TBD and 'R' bit cleared in the=20 >> Command >> >> Flags field is sent in response to the QoS-Authorization-Request >> >> message (QAR). To converge different kind of authorizing=20 >> entities >> and performing NEs, terminal-Mode can tell the performing NE how >> to choose the interface working mode. If the QoS authorization=20 >> request >> >> is successfully authorized, the response will include the AVPs=20 >> to >> allow authorization of the QoS resources as well as accounting=20 >> and >> transport plane gating information. >> >> The message format is defined as follows: >> >>
>> >> > >> ::=3D < Diameter Header: XXX, PXY > = < >> Session-Id > { Auth-Application-Id }=20 >> { Auth-Request-Type } { Result-Code }=20 >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] * [ QoS-Resources ]=20 >> [ CC-Time ] [ Acc-Multisession-Id ]=20 >> [ Session-Timeout ] [=20 >> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >> * [ AVP ] ]]> >> >>
>> >>
>> >> section 6.3 >> >>
>> >> The QoS-Install Request message (QIR), indicated by the >> >> Command-Code field set to TDB and 'R' bit set in the Command >> Flags >> >> field is used by Authorizing entity to install or update the QoS >> >> parameters and the flow state of an authorized flow at the=20 >> transport >> >> plane element. >> >> The message MUST carry information for signaling session >> >> identification or identification of the flow to which the=20 >> provided QoS >> >> rules apply, working mode of the terminal, identity of the=20 >> transport >> plane element, description of provided QoS parameters, flow=20 >> state and >> duration of the provided authorization. >> >> The message format is defined as follows: >> >>
>> >> > >> ::=3D < Diameter Header: XXX, REQ, PXY > = < >> Session-Id > { Auth-Application-Id }=20 >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] >> { Destination-Realm } { >> Auth-Request-Type } [ Destination-Host ]=20 >> * [ QoS-Resources ] [ Session-Timeout ] [=20 >> Authz-Session-Lifetime ] [ Authz-Grace-Period ]=20 >> [ Authz-Session-Volume ] * [=20 >> ]]> >> >>
>> >>
>> >> >> >> [snipped] >> >> >> >> section 7.1 >> >>
>> >> > >> Attribute Name AVP Code Reference [RFC3588] >> >> Origin-Host 264 Section 6.3 >> >> Origin-Realm 296 Section 6.4 >> >> Terminal-Mode TBD >> >> >> B. R. >> >> Tina >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 23:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8oyR-0007Rg-Ut; Wed, 11 Jul 2007 23:04:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8oyQ-0007P3-Ha for dime@ietf.org; Wed, 11 Jul 2007 23:04:10 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8oyP-00027k-5A for dime@ietf.org; Wed, 11 Jul 2007 23:04:10 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL10071WPSW2A@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:02:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL1003LCPSSCE@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:02:56 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100J6KPSSMQ@szxml03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:02:52 +0800 (CST) Date: Thu, 12 Jul 2007 11:02:52 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode To: Hannes Tschofenig , dime@ietf.org, "Sun, Dong (Dong)" Message-id: <00aa01c7c431$23482240$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> <032001c7c3af$07676c20$864c460a@china.huawei.com> <09C9068466B79E4C938DC7737562404D5209A6@ILEXC2U01.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dong, Yes, kind of, not exactly the access network, but the terminal working mode. Moreover, it helps the interface between the authorizing entity and the NEs. B. R. Tina ----- Original Message ----- From: "Sun, Dong (Dong)" To: "Tina TSOU" ; ; "Hannes Tschofenig" Sent: Thursday, July 12, 2007 7:22 AM Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode Hi Tina, It seems you intend to make use of this new AVP to indicate the access network type, or more specific - QoS profile to facilitate the authorizing entity on the policy decision, is it correct? Then this proposal is more or less related to the access network related info issue in another thread, better to consolidate them together. As stated in another email, I am not sure if it is good idea to make authorizing entity specific to each access technologies in the context of QoS mapping and policy control, especially for inter-domain scenario. Maybe I misunderstood your point... Regards, Dong -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Wednesday, July 11, 2007 7:32 AM To: dime@ietf.org; Hannes Tschofenig Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode ----- Original Message ----- From: "Hannes Tschofenig" To: ; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: this question belongs to another thread "PULL/PUSH/Access network related information".] > What information would you put into the Terminal-Mode AVP? [Tina: First, we can find which mode the terminal is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi-mode, and each mode may have different QoS profile, so the terminal-mode AVP can help to the operation on match QoS request and QoS control.] > > Ciao > Hannes > > Hannes Tschofenig wrote: >> FYI >> >> ------ >> >> This is without the attachment. >> >> B. R. >> Tina >> >> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: >> Wednesday, July 11, 2007 6:26 PM >> Subject: Diameter QoS Appl.- terminal working mode >> >> >> Hi Guys, >> To converge different kind of authorizing entities and performing NEs, >> terminal-Mode can tell the performing NE how to choose the interface >> working mode. First, we can find which mode the terminal is by >> Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may >> be multi-mode, and each mode may have different QoS >> profile, so the terminal-mode AVP can help to the operation on match QoS >> request and QoS control. >> The following changes are proposed. (You can also find the changes in >> the attachment.) >> section 6.2 >> >>
>> >> The QoS-Authorization-Answer message (QAA), indicated by the >> >> Command- Code field set to TBD and 'R' bit cleared in the >> Command >> >> Flags field is sent in response to the QoS-Authorization-Request >> >> message (QAR). To converge different kind of authorizing >> entities >> and performing NEs, terminal-Mode can tell the performing NE how >> to choose the interface working mode. If the QoS authorization >> request >> >> is successfully authorized, the response will include the AVPs >> to >> allow authorization of the QoS resources as well as accounting >> and >> transport plane gating information. >> >> The message format is defined as follows: >> >>
>> >> > >> ::= < Diameter Header: XXX, PXY > < >> Session-Id > { Auth-Application-Id } >> { Auth-Request-Type } { Result-Code } >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] * [ QoS-Resources ] >> [ CC-Time ] [ Acc-Multisession-Id ] >> [ Session-Timeout ] [ >> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >> * [ AVP ] ]]> >> >>
>> >>
>> >> section 6.3 >> >>
>> >> The QoS-Install Request message (QIR), indicated by the >> >> Command-Code field set to TDB and 'R' bit set in the Command >> Flags >> >> field is used by Authorizing entity to install or update the QoS >> >> parameters and the flow state of an authorized flow at the >> transport >> >> plane element. >> >> The message MUST carry information for signaling session >> >> identification or identification of the flow to which the >> provided QoS >> >> rules apply, working mode of the terminal, identity of the >> transport >> plane element, description of provided QoS parameters, flow >> state and >> duration of the provided authorization. >> >> The message format is defined as follows: >> >>
>> >> > >> ::= < Diameter Header: XXX, REQ, PXY > < >> Session-Id > { Auth-Application-Id } >> { Origin-Host } { Origin-Realm } >> [ Terminal-Mode ] >> { Destination-Realm } { >> Auth-Request-Type } [ Destination-Host ] >> * [ QoS-Resources ] [ Session-Timeout ] [ >> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >> [ Authz-Session-Volume ] * [ >> ]]> >> >>
>> >>
>> >> >> >> [snipped] >> >> >> >> section 7.1 >> >>
>> >> > >> Attribute Name AVP Code Reference [RFC3588] >> >> Origin-Host 264 Section 6.3 >> >> Origin-Realm 296 Section 6.4 >> >> Terminal-Mode TBD >> >> >> B. R. >> >> Tina >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 23:09:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p3V-0005Qb-Ko; Wed, 11 Jul 2007 23:09:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p3U-0005QS-0a for dime@ietf.org; Wed, 11 Jul 2007 23:09:24 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8p3S-0002Ez-MQ for dime@ietf.org; Wed, 11 Jul 2007 23:09:23 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL1003LGQ1WLI@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:08:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100BVCQ1V12@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:08:20 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100D56Q1USS@szxml04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:08:19 +0800 (CST) Date: Thu, 12 Jul 2007 11:08:18 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode To: Hannes Tschofenig , dime@ietf.org, Tina TSOU Message-id: <00d401c7c431$e5bf9c90$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> <032001c7c3af$07676c20$864c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > ----- Original Message ----- > From: "Hannes Tschofenig" > To: ; "Tina TSOU" > Sent: Wednesday, July 11, 2007 6:46 PM > Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode [snipped] >> What information would you put into the Terminal-Mode AVP? [Tina: Just a mode value in Terminal-Mode AVP.] B. R. Tina ----- Original Message ----- From: "Tina TSOU" To: ; "Hannes Tschofenig" Sent: Wednesday, July 11, 2007 7:31 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > ----- Original Message ----- > From: "Hannes Tschofenig" > To: ; "Tina TSOU" > Sent: Wednesday, July 11, 2007 6:46 PM > Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > >> Hi Tina, >> >> who translates high-level QoS information used at the application layer >> into information that is appropriate for a QoS model that is used in a >> particular access network. In your model it seems that the AF is in >> charge of assisting whereas the PDF does the final translation. In any >> case, it is not the NE that does it. >> >> Correct? > [Tina: this question belongs to another thread "PULL/PUSH/Access network > related information".] >> >> But how should the AF know anything about the access network >> characteristics? >> (unless it is in the access network itself) > [Tina: this question belongs to another thread "PULL/PUSH/Access network > related information".] >> What information would you put into the Terminal-Mode AVP? > [Tina: First, we can find which mode the terminal is by Terminal-mode, for > example > 3GPP, WiFi, Wimax, etc. > The user terminal may be multi-mode, and each mode may have different QoS > profile, so the terminal-mode AVP can help to the operation on match QoS > request and QoS control.] >> >> Ciao >> Hannes >> >> Hannes Tschofenig wrote: >>> FYI >>> >>> ------ >>> >>> This is without the attachment. >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: >>> Wednesday, July 11, 2007 6:26 PM >>> Subject: Diameter QoS Appl.- terminal working mode >>> >>> >>> Hi Guys, >>> To converge different kind of authorizing entities and performing NEs, >>> terminal-Mode can tell the performing NE how to choose the interface >>> working mode. First, we can find which mode the terminal is by >>> Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may >>> be multi-mode, and each mode may have different QoS >>> profile, so the terminal-mode AVP can help to the operation on match >>> QoS request and QoS control. >>> The following changes are proposed. (You can also find the changes in >>> the attachment.) >>> section 6.2 >>> >>>
>>> >>> The QoS-Authorization-Answer message (QAA), indicated by the >>> >>> Command- Code field set to TBD and 'R' bit cleared in the >>> Command >>> >>> Flags field is sent in response to the >>> QoS-Authorization-Request >>> >>> message (QAR). To converge different kind of authorizing >>> entities >>> and performing NEs, terminal-Mode can tell the performing NE >>> how >>> to choose the interface working mode. If the QoS authorization >>> request >>> >>> is successfully authorized, the response will include the AVPs >>> to >>> allow authorization of the QoS resources as well as accounting >>> and >>> transport plane gating information. >>> >>> The message format is defined as follows: >>> >>>
>>> >>> >> >>> ::= < Diameter Header: XXX, PXY > < >>> Session-Id > { Auth-Application-Id } >>> { Auth-Request-Type } { Result-Code } { >>> Origin-Host } { Origin-Realm } >>> [ Terminal-Mode ] * [ QoS-Resources ] [ >>> CC-Time ] [ Acc-Multisession-Id ] >>> [ Session-Timeout ] [ >>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] * >>> [ AVP ] ]]> >>> >>>
>>> >>>
>>> >>> section 6.3 >>> >>>
>>> >>> The QoS-Install Request message (QIR), indicated by the >>> >>> Command-Code field set to TDB and 'R' bit set in the Command >>> Flags >>> >>> field is used by Authorizing entity to install or update the >>> QoS >>> >>> parameters and the flow state of an authorized flow at the >>> transport >>> >>> plane element. >>> >>> The message MUST carry information for signaling session >>> >>> identification or identification of the flow to which the >>> provided QoS >>> >>> rules apply, working mode of the terminal, identity of the >>> transport >>> plane element, description of provided QoS parameters, flow >>> state and >>> duration of the provided authorization. >>> >>> The message format is defined as follows: >>> >>>
>>> >>> >> >>> ::= < Diameter Header: XXX, REQ, PXY > < >>> Session-Id > { Auth-Application-Id } { >>> Origin-Host } { Origin-Realm } >>> [ Terminal-Mode ] >>> { Destination-Realm } { >>> Auth-Request-Type } [ Destination-Host ] * [ >>> QoS-Resources ] [ Session-Timeout ] [ >>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ >>> Authz-Session-Volume ] * [ ]]> >>> >>>
>>> >>>
>>> >>> >>> >>> [snipped] >>> >>> >>> >>> section 7.1 >>> >>>
>>> >>> >> >>> Attribute Name AVP Code Reference [RFC3588] >>> >>> Origin-Host 264 Section 6.3 >>> >>> Origin-Realm 296 Section 6.4 >>> >>> Terminal-Mode TBD >>> >>> >>> B. R. >>> >>> Tina >>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 11 23:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p4a-0007V5-Am; Wed, 11 Jul 2007 23:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p4Z-0007Uv-5b for dime@ietf.org; Wed, 11 Jul 2007 23:10:31 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8p4U-0001Su-Ss for dime@ietf.org; Wed, 11 Jul 2007 23:10:31 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL10038LQ3XLI@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:09:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100BWXQ3V12@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:09:32 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100DEIQ3VSS@szxml04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 11:09:31 +0800 (CST) Date: Thu, 12 Jul 2007 11:09:31 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode To: dime@ietf.org, "Asveren, Tolga" Message-id: <00db01c7c432$11378a90$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4694B447.8080800@gmx.net> <033458F56EC2A64E8D2D7B759FA3E7E718805C@sonusmail04.sonusnet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I can use this value to separate the different type NEs, I think, up to now. B. R. Tina ----- Original Message ----- From: "Asveren, Tolga" To: Sent: Thursday, July 12, 2007 3:01 AM Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode Hi Tina, I have one question/concern about this: The value of Terminal-Mode would have an implicit (and not defined by this specification) meaning with it, i.e. each element may interpret it differently. Maybe an approach, where we have separate AVPs for all pieces of information which we think could be extracted from Terminal-Type, could be less ambiguous. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, July 11, 2007 6:43 AM > To: dime@ietf.org; Tina TSOU > Subject: [Dime] Diameter QoS Appl.- terminal working mode > > FYI > > ------ > > This is without the attachment. > > B. R. > Tina > > ----- Original Message ----- > From: Tina TSOU > To: dime@ietf.org > Sent: Wednesday, July 11, 2007 6:26 PM > Subject: Diameter QoS Appl.- terminal working mode > > > Hi Guys, > To converge different kind of authorizing entities and performing NEs, > terminal-Mode can tell the performing NE how to choose the interface > working mode. First, we can find which mode the terminal is by Terminal- > mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi- > mode, and each mode may have different QoS > profile, so the terminal-mode AVP can help to the operation on match QoS > request and QoS control. > The following changes are proposed. (You can also find the changes in > the attachment.) > section 6.2 > >
> > The QoS-Authorization-Answer message (QAA), indicated by the > > Command- Code field set to TBD and 'R' bit cleared in the > Command > > Flags field is sent in response to the QoS-Authorization-Request > > message (QAR). To converge different kind of authorizing > entities > > and performing NEs, terminal-Mode can tell the performing NE how > > to choose the interface working mode. If the QoS authorization > request > > is successfully authorized, the response will include the AVPs > to > > allow authorization of the QoS resources as well as accounting > and > > transport plane gating information. > > The message format is defined as follows: > > > >
> > > ::= < Diameter Header: XXX, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Auth-Request-Type } > > { Result-Code } > > { Origin-Host } > > { Origin-Realm } > > [ Terminal-Mode ] > > * [ QoS-Resources ] > > [ CC-Time ] > > [ Acc-Multisession-Id ] > > [ Session-Timeout ] > > [ Authz-Session-Lifetime ] > > [ Authz-Grace-Period ] > > * [ AVP ] > > ]]> > >
> >
> > > > section 6.3 > >
> > The QoS-Install Request message (QIR), indicated by the > > Command-Code field set to TDB and 'R' bit set in the Command > Flags > > field is used by Authorizing entity to install or update the QoS > > parameters and the flow state of an authorized flow at the > transport > > plane element. > > > > The message MUST carry information for signaling session > > identification or identification of the flow to which the > provided QoS > > rules apply, working mode of the terminal, identity of the > transport > > plane element, description of provided QoS parameters, flow > state and > > duration of the provided authorization. > > > > The message format is defined as follows: > > > >
> > > ::= < Diameter Header: XXX, REQ, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Origin-Host } > > { Origin-Realm } > > [ Terminal-Mode ] > > { Destination-Realm } > > { Auth-Request-Type } > > [ Destination-Host ] > > * [ QoS-Resources ] > > [ Session-Timeout ] > > [ Authz-Session-Lifetime ] > > [ Authz-Grace-Period ] > > [ Authz-Session-Volume ] > > * [ AVP ] > > ]]> > >
> >
> > > > [snipped] > > > > section 7.1 > >
> > > Attribute Name AVP Code Reference [RFC3588] > > Origin-Host 264 Section 6.3 > > Origin-Realm 296 Section 6.4 > > Terminal-Mode TBD > > > B. R. > > Tina > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 02:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rio-0002sX-1H; Thu, 12 Jul 2007 02:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rim-0002sQ-1x for dime@ietf.org; Thu, 12 Jul 2007 02:00:12 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8rig-0007h1-Fg for dime@ietf.org; Thu, 12 Jul 2007 02:00:12 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100HEXXYLIS@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 13:59:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL1003G7XYKCE@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 13:59:09 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL1002LUXYKAV@szxml03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 13:59:08 +0800 (CST) Date: Thu, 12 Jul 2007 13:59:08 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" To: dime@ietf.org, "Asveren, Tolga" Message-id: <013101c7c449$c31ec9a0$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E718805B@sonusmail04.sonusnet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Pull mode is needed in the mobile network scenario and push mode is needed in the fixed network scenario. When the interfaces are converged, we have to distinguish which mode to use. ] B. R. Tina ----- Original Message ----- From: "Asveren, Tolga" To: Sent: Thursday, July 12, 2007 2:49 AM Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Hi Tina, One question about the proposed addition: What type of scenarios would require pull-mode of operation, if authorizing entity receives a request from an application server? Thanks, Tolga ________________________________________ From: Tina TSOU [mailto:tena@huawei.com] Sent: Wednesday, July 11, 2007 6:09 AM To: dime@ietf.org; Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Hi Guys, After discussion with Hannes and Dong, I think it might be better to modify like this. It is the recovering of the texts about "PULL/PUSH/Access network related information" deleted by mistake or misunderstanding 3 Framework [snipped] In some deployment scenarios, QoS aware network elements may request authorization through the AAA cloud based on an incoming QoS reservation request. The network element will route the request to a designated authorizing entity. The authorizing entity will return the result of the authorization decision. In other deployment scenarios, the authorization will be initiated upon dynamic application state, so that the request must be authenticated and authorized based on information from one or more application servers. /*start of added*/In terms of the resource request sent from the application server to Authorizing Entity, the Authorizing Entity could identify the access network related information and select appropriate resource admission and control policies. The Push or pull mode also can be dynamically triggered based on the information in the request from application server, or statically configured according to operator's demand./*end of added*/ [snipped] B. R. Tina ----- Original Message ----- From: Tina TSOU To: dime@ietf.org Sent: Monday, July 09, 2007 5:27 PM Subject: [Dime] Diameter QoS Appl. Hi all, I suggest that some texts could be added in the beginning of 3.3 to smooth with the texts in 3.3.1 and 3.3.2. [snipped] 3.3. Authorization schemes Three basic authorization models for QoS reservations exist: one two -party and two three party models. In the three party QoS model (Figure 3), the authorization entity may be composed of two separate functional entities - Application Server which interacts with the QoS requesting entity and Authorizing Entity. The Application Server MAY indicate the access network related information in a service request to Authorizing Entity which can be used by the Authorizing Entity to select the appropriate resource admission and control policies. The service request from Application Server to Authorizing Entity MAY also indicate the admission control mode (i.e., "pull" or "push" model) in terms of which Authorizing Entity performs QoS authorization and then sends the policy decisions to the NE which performs QoS reservation. Authorization schemes for both pull and push mode will be described below in detail. 3.3.1. Authorization schemes for pull mode [snipped] B. R. Tina ________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 02:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ruo-0001um-D8; Thu, 12 Jul 2007 02:12:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rum-0001ua-82 for dime@ietf.org; Thu, 12 Jul 2007 02:12:36 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ruW-00089J-M7 for dime@ietf.org; Thu, 12 Jul 2007 02:12:36 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100JEPYIULE@szxga03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:11:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100BVNYISVU@szxga03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:11:18 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL1004HRYISN9@szxml03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:11:16 +0800 (CST) Date: Thu, 12 Jul 2007 14:11:16 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: Hannes Tschofenig , dime@ietf.org, Christian Esteve Message-id: <015e01c7c44b$74f14a30$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0734503294==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0734503294== Content-type: multipart/alternative; boundary="Boundary_(ID_yLWtIPOq6NxTTMu8o+N6EQ)" This is a multi-part message in MIME format. --Boundary_(ID_yLWtIPOq6NxTTMu8o+N6EQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Christian, Actually, the QoS template is not chosen by AF (mapping to Application Server here). It is determined by the policy in SPDF (mapping to Authorizing Entity here) according to related information sent from AF to SPDF. There is no need for AF to see the template information. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message ----- From: Christian Esteve To: dime@ietf.org ; Tina TSOU ; Hannes Tschofenig Sent: Thursday, July 12, 2007 3:05 AM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" Hi! My 2 cents: > But how should the AF know anything about the access network > characteristics? (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] [Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used to optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain. To my understasnding this information can be used by the AF to choose the appropriate QoS template. E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 ] Best regards, Christian ------------------------------ Message: 4 Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU < tena@huawei.com> Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com> Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response ----- Original Message ----- From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net> To: < dime@ietf.org>; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes --Boundary_(ID_yLWtIPOq6NxTTMu8o+N6EQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Christian,
Actually, the QoS template is not chosen by AF (mapping to Application Server here). It is determined by the policy in SPDF (mapping to Authorizing Entity here) according to related information sent from AF to SPDF. There is no need for AF to see the template information.
 
B. R.
Tina
Messengers:
MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com
----- Original Message -----
Sent: Thursday, July 12, 2007 3:05 AM
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information"

Hi!

My 2 cents:

> But how should the AF know anything about the access network
> characteristics? (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]

[Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the  P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used  to   optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain.
To my understasnding this information can be used by the AF to choose the appropriate QoS template.

E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
]

Best regards,
Christian

------------------------------

Message: 4
Date: Wed, 11 Jul 2007 19:34:12 +0800
From: Tina TSOU < tena@huawei.com>
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
       related information"
To: dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com>
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
       reply-type=response


----- Original Message -----
From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net>
To: < dime@ietf.org>; "Tina TSOU" <tena@huawei.com>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-  "PULL/PUSH/Access network related
information"


> Hi Tina,
>
> who translates high-level QoS information used at the application layer
> into information that is appropriate for a QoS model that is used in a
> particular access network. In your model it seems that the AF is in charge
> of assisting whereas the PDF does the final translation. In any case, it
> is not the NE that does it.
>
> Correct?
[Tina: Correct.]
>
> But how should the AF know anything about the access network
> characteristics?
> (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]
>
>
> Ciao
> Hannes
--Boundary_(ID_yLWtIPOq6NxTTMu8o+N6EQ)-- --===============0734503294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0734503294==-- From dime-bounces@ietf.org Thu Jul 12 02:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sM3-0001yn-SO; Thu, 12 Jul 2007 02:40:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sM2-0001yf-8j for dime@ietf.org; Thu, 12 Jul 2007 02:40:46 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8sM0-0000Da-PH for dime@ietf.org; Thu, 12 Jul 2007 02:40:46 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL1000W7ZU609@szxga03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:39:42 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100BUFZU5MK@szxga03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:39:42 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL1004DKZU4M6@szxml03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:39:41 +0800 (CST) Date: Thu, 12 Jul 2007 14:39:40 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" To: Christian Esteve , dime@ietf.org, Hannes Tschofenig , Tina TSOU Message-id: <01a601c7c44f$6cc99840$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> <015e01c7c44b$74f14a30$864c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594374953==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0594374953== Content-type: multipart/alternative; boundary="Boundary_(ID_YyKb3XIGGf/QEfm9HV+97g)" This is a multi-part message in MIME format. --Boundary_(ID_YyKb3XIGGf/QEfm9HV+97g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Christian, Moreover, For mobile terminals, AF can get access network identifier from SIP message header. For fix terminals, AF can query the access network identifier via e2 interface. The way carried by SIP is not granted by consensus. B. R. Tina ----- Original Message ----- From: Tina TSOU To: Hannes Tschofenig ; dime@ietf.org ; Christian Esteve Sent: Thursday, July 12, 2007 2:11 PM Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Hi Christian, Actually, the QoS template is not chosen by AF (mapping to Application Server here). It is determined by the policy in SPDF (mapping to Authorizing Entity here) according to related information sent from AF to SPDF. There is no need for AF to see the template information. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message ----- From: Christian Esteve To: dime@ietf.org ; Tina TSOU ; Hannes Tschofenig Sent: Thursday, July 12, 2007 3:05 AM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" Hi! My 2 cents: > But how should the AF know anything about the access network > characteristics? (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] [Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used to optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain. To my understasnding this information can be used by the AF to choose the appropriate QoS template. E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 ] Best regards, Christian ------------------------------ Message: 4 Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU < tena@huawei.com> Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com> Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response ----- Original Message ----- From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net> To: < dime@ietf.org>; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_YyKb3XIGGf/QEfm9HV+97g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Christian,
Moreover,
For mobile terminals, AF can get access network identifier from SIP message header.
For fix terminals, AF can query the access network identifier via e2 interface. The way carried by SIP is not granted by consensus.
 
B. R.
Tina
----- Original Message -----
From: Tina TSOU
Sent: Thursday, July 12, 2007 2:11 PM
Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information"

Hi Christian,
Actually, the QoS template is not chosen by AF (mapping to Application Server here). It is determined by the policy in SPDF (mapping to Authorizing Entity here) according to related information sent from AF to SPDF. There is no need for AF to see the template information.
 
B. R.
Tina
Messengers:
MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com
----- Original Message -----
Sent: Thursday, July 12, 2007 3:05 AM
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information"

Hi!

My 2 cents:

> But how should the AF know anything about the access network
> characteristics? (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]

[Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the  P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used  to   optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain.
To my understasnding this information can be used by the AF to choose the appropriate QoS template.

E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
]

Best regards,
Christian

------------------------------

Message: 4
Date: Wed, 11 Jul 2007 19:34:12 +0800
From: Tina TSOU < tena@huawei.com>
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
       related information"
To: dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com>
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
       reply-type=response


----- Original Message -----
From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net>
To: < dime@ietf.org>; "Tina TSOU" <tena@huawei.com>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-  "PULL/PUSH/Access network related
information"


> Hi Tina,
>
> who translates high-level QoS information used at the application layer
> into information that is appropriate for a QoS model that is used in a
> particular access network. In your model it seems that the AF is in charge
> of assisting whereas the PDF does the final translation. In any case, it
> is not the NE that does it.
>
> Correct?
[Tina: Correct.]
>
> But how should the AF know anything about the access network
> characteristics?
> (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]
>
>
> Ciao
> Hannes

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_YyKb3XIGGf/QEfm9HV+97g)-- --===============0594374953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0594374953==-- From dime-bounces@ietf.org Thu Jul 12 02:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sOR-0004Pa-Fp; Thu, 12 Jul 2007 02:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sOQ-0004PV-Nj for dime@ietf.org; Thu, 12 Jul 2007 02:43:14 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8sOL-0000MN-Cs for dime@ietf.org; Thu, 12 Jul 2007 02:43:14 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100K9EZYFZ1@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:42:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100LRNZYEYA@szxga02-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:42:15 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL1004PHZYE9D@szxml04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 14:42:14 +0800 (CST) Date: Thu, 12 Jul 2007 14:42:14 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" To: "Asveren, Tolga" , dime@ietf.org, Tina TSOU Message-id: <01ab01c7c44f$c82b7460$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E718805B@sonusmail04.sonusnet.com> <013101c7c449$c31ec9a0$864c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi again:) In addition, PULL mode can be also used in Fix network; the precondition is that the terminal is QoS aware, therefore the mobile terminals for mobile network use PULL mode more frequently. I drew a picture but it exceeds 40 KB, so it is not able to be sent through the ML, so I will send it to you personally;-) B. R. Tina ----- Original Message ----- From: "Tina TSOU" To: ; "Asveren, Tolga" Sent: Thursday, July 12, 2007 1:59 PM Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" > Hi Tolga, > Pull mode is needed in the mobile network scenario and push mode is needed > in the fixed network scenario. When the interfaces are converged, we have > to distinguish which mode to use. > B. R. > Tina > > ----- Original Message ----- > From: "Asveren, Tolga" > To: > Sent: Thursday, July 12, 2007 2:49 AM > Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related > information" > > > Hi Tina, > > One question about the proposed addition: > What type of scenarios would require pull-mode of operation, if > authorizing entity receives a request from an application server? > > Thanks, > Tolga > > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, July 11, 2007 6:09 AM > To: dime@ietf.org; Tina TSOU > Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related > information" > > Hi Guys, > After discussion with Hannes and Dong, I think it might be better to > modify like this. It is the recovering of the texts about > "PULL/PUSH/Access network related information" deleted by mistake or > misunderstanding > > 3 Framework > [snipped] > In some deployment scenarios, QoS aware network elements may request > authorization through the AAA cloud based on an incoming QoS > reservation > request. The network element will route the request to a designated > authorizing entity. The authorizing entity will return the result of > the > authorization decision. In other deployment scenarios, the > authorization > will be initiated upon dynamic application state, so that the request > must be authenticated and authorized based on information from one or > more application servers. /*start of added*/In terms of the resource > request sent from > the application server to Authorizing Entity, the Authorizing Entity > could identify the access network related information and select > appropriate > resource admission and control policies. The Push or pull mode also > can be > dynamically triggered based on the information in the request from > application > server, or statically configured according to operator's demand./*end of > added*/ > [snipped] > > B. R. > Tina > ----- Original Message ----- > From: Tina TSOU > To: dime@ietf.org > Sent: Monday, July 09, 2007 5:27 PM > Subject: [Dime] Diameter QoS Appl. > > Hi all, > I suggest that some texts could be added in the beginning of 3.3 to smooth > with the texts in 3.3.1 and 3.3.2. > > [snipped] > 3.3. Authorization schemes > > Three basic authorization models for QoS reservations exist: one two > -party and two three party models. In the three party QoS model > (Figure 3), the authorization entity may be composed of two separate > functional entities - Application Server which interacts with the QoS > requesting entity and Authorizing Entity. The Application Server MAY > indicate the access network related information in a service request > to Authorizing Entity which can be used by the Authorizing Entity to > select the appropriate resource admission and control policies. The > service request from Application Server to Authorizing Entity MAY > also indicate the admission control mode (i.e., "pull" or "push" > model) in terms of which Authorizing Entity performs QoS > authorization and then sends the policy decisions to the NE which > performs QoS reservation. Authorization schemes for both pull > and push mode will be described below in detail. > > 3.3.1. Authorization schemes for pull mode > [snipped] > B. R. > Tina > ________________________________________ > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 03:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8t6B-0000nD-D8; Thu, 12 Jul 2007 03:28:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8t6A-0000n8-0N for dime@ietf.org; Thu, 12 Jul 2007 03:28:26 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8t68-0001G2-Dm for dime@ietf.org; Thu, 12 Jul 2007 03:28:25 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200HPC21LIS@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 15:27:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200BKZ21KS5@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 15:27:21 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL2004VK21J9D@szxml04-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 15:27:20 +0800 (CST) Date: Thu, 12 Jul 2007 15:27:19 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" To: Hannes Tschofenig , dime@ietf.org, Christian Esteve , "Sun, Dong (Dong)" Message-id: <01f801c7c456$14e1ea90$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <9b0e41640707111205t50732220l47e5373f2e4bd054@mail.gmail.com> <09C9068466B79E4C938DC7737562404D5209A5@ILEXC2U01.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139417415==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0139417415== Content-type: multipart/alternative; boundary="Boundary_(ID_OzmNeQ8dPKMJ5jS0sgSvlQ)" This is a multi-part message in MIME format. --Boundary_(ID_OzmNeQ8dPKMJ5jS0sgSvlQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Dong, Answer for Push/Pull mode: Policy Server needs to know which mode to choose (push or pull) in the converged scenario (similar to the first question from Christian). Answer for Access network related information: When the interfaces (e.g. Gq', Gq, Rx, Rs) between AS and Policy Server are converged but the procedures are separated as before, Policy Server needs to identify which procedure to perform. Of course, NE can do some identification, but we just propose a more general method for the Policy Server to identify. So AS will send access network related information to Policy Server. However, if the procedures are also converged in the future, there is no need for the Policy Server to identify. B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: Christian Esteve ; dime@ietf.org ; Tina TSOU ; Hannes Tschofenig Sent: Thursday, July 12, 2007 7:04 AM Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" Hi Chirstian, I agree, in certain circumstance e.g. IMS AF, it is possible to identify the access network as you described. Maybe, I guess, there is some confusion (to me) on the terminology used here. If you are saying that AF may determine the service profile/attributes upon access type, it would be fine in certain case (but it is out of the scope in this doc). However, not sure if it is good idea to make the application server involved in network level QoS selection, even it is worse to make the AS select access specific QoS profile. Regards, Dong ---------------------------------------------------------------------------- From: Christian Esteve [mailto:chesteve@gmx.net] Sent: Wednesday, July 11, 2007 3:06 PM To: dime@ietf.org; Tina TSOU; Hannes Tschofenig Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation" Hi! My 2 cents: > But how should the AF know anything about the access network > characteristics? (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] [Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used to optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain. To my understasnding this information can be used by the AF to choose the appropriate QoS template. E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 ] Best regards, Christian ------------------------------ Message: 4 Date: Wed, 11 Jul 2007 19:34:12 +0800 From: Tina TSOU < tena@huawei.com> Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" To: dime@ietf.org, Hannes Tschofenig Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com> Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response ----- Original Message ----- From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net> To: < dime@ietf.org>; "Tina TSOU" Sent: Wednesday, July 11, 2007 6:46 PM Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related information" > Hi Tina, > > who translates high-level QoS information used at the application layer > into information that is appropriate for a QoS model that is used in a > particular access network. In your model it seems that the AF is in charge > of assisting whereas the PDF does the final translation. In any case, it > is not the NE that does it. > > Correct? [Tina: Correct.] > > But how should the AF know anything about the access network > characteristics? > (unless it is in the access network itself) [Tina: it is configured by the operator/administrator.] > > > Ciao > Hannes --Boundary_(ID_OzmNeQ8dPKMJ5jS0sgSvlQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Dong,
Answer for Push/Pull mode: Policy Server needs to know which mode to choose (push or pull) in the converged scenario (similar to the first question from Christian).
Answer for Access network related information: When the interfaces (e.g. Gq', Gq, Rx, Rs) between AS and Policy Server are converged but the procedures are separated as before, Policy Server needs to identify which procedure to perform. Of course, NE can do some identification, but we just propose a more general method for the Policy Server to identify.  So AS will send access network related information to Policy Server. However, if the procedures are also converged in the future, there is no need for the Policy Server to identify.
 
B. R.
Tina
----- Original Message -----
Sent: Thursday, July 12, 2007 7:04 AM
Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation"

Hi Chirstian,
 
I agree, in certain circumstance e.g. IMS AF, it is possible to identify the access network as you described.
Maybe, I guess, there is some confusion (to me) on the terminology used here. If you are saying that AF may determine the service profile/attributes upon access type, it would be fine in certain case (but it is out of the scope in this doc). However, not sure if it is good idea to make the application server involved in network level QoS selection, even it is worse to make the AS select access specific QoS profile.
 
Regards,
Dong

From: Christian Esteve [mailto:chesteve@gmx.net]
Sent: Wednesday, July 11, 2007 3:06 PM
To: dime@ietf.org; Tina TSOU; Hannes Tschofenig
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation"

Hi!

My 2 cents:

> But how should the AF know anything about the access network
> characteristics? (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]

[Christian: Agree that the configuration of the AF is provided by the administrative domain. Additionally, the AF may know through application level user signaling (UE-AF) aboout the access network type for which the session authorization applies. E.g.the  P-Access- Network-Info [RFC 3455] used in the IMS SIP signaling relays information about the access technology that may then be used  to   optimize services (e.g. location-based, bw optimized) for the UA at the home domain and it could be useful to perform accurate access network resource authorization requests at the visited domain.
To my understasnding this information can be used by the AF to choose the appropriate QoS template.

E.g. P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
]

Best regards,
Christian

------------------------------

Message: 4
Date: Wed, 11 Jul 2007 19:34:12 +0800
From: Tina TSOU < tena@huawei.com>
Subject: Re: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
       related information"
To: dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: < 032c01c7c3af$67904630$864c460a@china.huawei.com>
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
       reply-type=response


----- Original Message -----
From: "Hannes Tschofenig" < Hannes.Tschofenig@gmx.net>
To: < dime@ietf.org>; "Tina TSOU" <tena@huawei.com>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-  "PULL/PUSH/Access network related
information"


> Hi Tina,
>
> who translates high-level QoS information used at the application layer
> into information that is appropriate for a QoS model that is used in a
> particular access network. In your model it seems that the AF is in charge
> of assisting whereas the PDF does the final translation. In any case, it
> is not the NE that does it.
>
> Correct?
[Tina: Correct.]
>
> But how should the AF know anything about the access network
> characteristics?
> (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]
>
>
> Ciao
> Hannes
--Boundary_(ID_OzmNeQ8dPKMJ5jS0sgSvlQ)-- --===============0139417415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0139417415==-- From dime-bounces@ietf.org Thu Jul 12 04:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tyS-0006aq-Ag; Thu, 12 Jul 2007 04:24:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tyR-0006ak-Lc for dime@ietf.org; Thu, 12 Jul 2007 04:24:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8tyM-0002gU-Tx for dime@ietf.org; Thu, 12 Jul 2007 04:24:31 -0400 Received: (qmail invoked by alias); 12 Jul 2007 08:24:09 -0000 Received: from p549862D4.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.98.212] by mail.gmx.net (mp032) with SMTP; 12 Jul 2007 10:24:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19OjLQF3ElOCDfEHKb491zl9WJ9H/e+ZHty+R7qE2 q36JJ2taFJElVt Message-ID: <4695E525.1010800@gmx.net> Date: Thu, 12 Jul 2007 10:24:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode References: <4694B447.8080800@gmx.net> <4694B4F0.5060804@gmx.net> <032001c7c3af$07676c20$864c460a@china.huawei.com> <00d401c7c431$e5bf9c90$864c460a@china.huawei.com> In-Reply-To: <00d401c7c431$e5bf9c90$864c460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, thanks for the discussion. I believe that the concrete values in the Terminal-Mode AVP matter. When you work on the document you need to list values and you need to setup a registry (or refer to an existing registry). You also need to explain where the values come from and what type of quality they have when they are used as input to some decision making process. Christian suggested the usage of the P-Access- Network-Info AVP that is added by a SIP proxy in the access network. Do you want to use P-Access- Network-Info? Could you explain a bit more about the flow of information? Who is supposed todo what and when? Ciao Hannes Tina TSOU wrote: >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: ; "Tina TSOU" >> Sent: Wednesday, July 11, 2007 6:46 PM >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > [snipped] >>> What information would you put into the Terminal-Mode AVP? > [Tina: Just a mode value in Terminal-Mode AVP.] > > B. R. > Tina > > ----- Original Message ----- From: "Tina TSOU" > To: ; "Hannes Tschofenig" > Sent: Wednesday, July 11, 2007 7:31 PM > Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > >> >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: ; "Tina TSOU" >> Sent: Wednesday, July 11, 2007 6:46 PM >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >> >> >>> Hi Tina, >>> >>> who translates high-level QoS information used at the application >>> layer into information that is appropriate for a QoS model that is >>> used in a particular access network. In your model it seems that the >>> AF is in charge of assisting whereas the PDF does the final >>> translation. In any case, it is not the NE that does it. >>> >>> Correct? >> [Tina: this question belongs to another thread "PULL/PUSH/Access >> network related information".] >>> >>> But how should the AF know anything about the access network >>> characteristics? >>> (unless it is in the access network itself) >> [Tina: this question belongs to another thread "PULL/PUSH/Access >> network related information".] >>> What information would you put into the Terminal-Mode AVP? >> [Tina: First, we can find which mode the terminal is by >> Terminal-mode, for example >> 3GPP, WiFi, Wimax, etc. >> The user terminal may be multi-mode, and each mode may have different >> QoS >> profile, so the terminal-mode AVP can help to the operation on match QoS >> request and QoS control.] >>> >>> Ciao >>> Hannes >>> >>> Hannes Tschofenig wrote: >>>> FYI >>>> >>>> ------ >>>> >>>> This is without the attachment. >>>> >>>> B. R. >>>> Tina >>>> >>>> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org >>>> Sent: Wednesday, July 11, 2007 6:26 PM >>>> Subject: Diameter QoS Appl.- terminal working mode >>>> >>>> >>>> Hi Guys, >>>> To converge different kind of authorizing entities and performing >>>> NEs, terminal-Mode can tell the performing NE how to choose the >>>> interface working mode. First, we can find which mode the terminal >>>> is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user >>>> terminal may be multi-mode, and each mode may have different QoS >>>> profile, so the terminal-mode AVP can help to the operation on >>>> match QoS request and QoS control. >>>> The following changes are proposed. (You can also find the changes >>>> in the attachment.) >>>> section 6.2 >>>> >>>>
>>>> >>>> The QoS-Authorization-Answer message (QAA), indicated >>>> by the >>>> >>>> Command- Code field set to TBD and 'R' bit cleared in the >>>> Command >>>> >>>> Flags field is sent in response to the >>>> QoS-Authorization-Request >>>> >>>> message (QAR). To converge different kind of authorizing >>>> entities >>>> and performing NEs, terminal-Mode can tell the performing >>>> NE how >>>> to choose the interface working mode. If the QoS >>>> authorization request >>>> >>>> is successfully authorized, the response will include the >>>> AVPs to >>>> allow authorization of the QoS resources as well as >>>> accounting and >>>> transport plane gating information. >>>> >>>> The message format is defined as follows: >>>> >>>>
>>>> >>>> >>> >>>> ::= < Diameter Header: XXX, PXY > >>>> < Session-Id > { >>>> Auth-Application-Id } { Auth-Request-Type >>>> } { Result-Code } { Origin-Host >>>> } { Origin-Realm } >>>> [ Terminal-Mode ] * [ QoS-Resources ] [ >>>> CC-Time ] [ >>>> Acc-Multisession-Id ] [ Session-Timeout >>>> ] [ Authz-Session-Lifetime >>>> ] [ Authz-Grace-Period ] * [ AVP >>>> ] ]]> >>>> >>>>
>>>> >>>>
>>>> >>>> section 6.3 >>>> >>>>
>>>> >>>> The QoS-Install Request message (QIR), indicated by the >>>> >>>> Command-Code field set to TDB and 'R' bit set in the >>>> Command Flags >>>> >>>> field is used by Authorizing entity to install or update >>>> the QoS >>>> >>>> parameters and the flow state of an authorized flow at the >>>> transport >>>> >>>> plane element. >>>> >>>> The message MUST carry information for signaling session >>>> >>>> identification or identification of the flow to which the >>>> provided QoS >>>> >>>> rules apply, working mode of the terminal, identity of the >>>> transport >>>> plane element, description of provided QoS parameters, >>>> flow state and >>>> duration of the provided authorization. >>>> >>>> The message format is defined as follows: >>>> >>>>
>>>> >>>> >>> >>>> ::= < Diameter Header: XXX, REQ, PXY > >>>> < Session-Id > { Auth-Application-Id } { >>>> Origin-Host } { Origin-Realm } >>>> [ Terminal-Mode ] >>>> { Destination-Realm } >>>> { Auth-Request-Type } [ Destination-Host ] * [ >>>> QoS-Resources ] [ Session-Timeout ] [ >>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ >>>> Authz-Session-Volume ] * [ ]]> >>>> >>>>
>>>> >>>>
>>>> >>>> >>>> >>>> [snipped] >>>> >>>> >>>> >>>> section 7.1 >>>> >>>>
>>>> >>>> >>> >>>> Attribute Name AVP Code Reference [RFC3588] >>>> >>>> Origin-Host 264 Section 6.3 >>>> >>>> Origin-Realm 296 Section 6.4 >>>> >>>> Terminal-Mode TBD >>>> >>>> >>>> B. R. >>>> >>>> Tina >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 07:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wk6-0001Qo-0B; Thu, 12 Jul 2007 07:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wk3-0001P5-UL for dime@ietf.org; Thu, 12 Jul 2007 07:21:51 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8wjy-0007Eu-GN for dime@ietf.org; Thu, 12 Jul 2007 07:21:51 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200JNWCUR4F@szxga01-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 19:20:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL2008HLCUQX7@szxga01-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 19:20:51 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL200ARQCUQ7J@szxml03-in.huawei.com> for dime@ietf.org; Thu, 12 Jul 2007 19:20:50 +0800 (CST) Date: Thu, 12 Jul 2007 19:20:50 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" To: dime@ietf.org, "Asveren, Tolga" , Tina TSOU Message-id: <025c01c7c476$b3e012a0$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E718805B@sonusmail04.sonusnet.com> <013101c7c449$c31ec9a0$864c460a@china.huawei.com> <01ab01c7c44f$c82b7460$864c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The picture of the scenario is in http://www.tschofenig.priv.at/TEMP/pull.jpg now. Thanks a lot for Hannes uploading it:) B. R. Tina ----- Original Message ----- From: "Tina TSOU" To: "Asveren, Tolga" ; ; "Tina TSOU" Sent: Thursday, July 12, 2007 2:42 PM Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" > Hi again:) > In addition, PULL mode can be also used in Fix network; the precondition > is > that the terminal is QoS aware, therefore the mobile terminals for mobile > network use PULL mode more frequently. > > I drew a picture but it exceeds 40 KB, so it is not able to be sent > through the ML, so I will send it to you personally;-) > > B. R. > Tina > > ----- Original Message ----- > From: "Tina TSOU" > To: ; "Asveren, Tolga" > Sent: Thursday, July 12, 2007 1:59 PM > Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related > information" > > >> Hi Tolga, >> Pull mode is needed in the mobile network scenario and push mode is >> needed >> in the fixed network scenario. When the interfaces are converged, we have >> to distinguish which mode to use. >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Asveren, Tolga" >> To: >> Sent: Thursday, July 12, 2007 2:49 AM >> Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related >> information" >> >> >> Hi Tina, >> >> One question about the proposed addition: >> What type of scenarios would require pull-mode of operation, if >> authorizing entity receives a request from an application server? >> >> Thanks, >> Tolga >> >> ________________________________________ >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Wednesday, July 11, 2007 6:09 AM >> To: dime@ietf.org; Tina TSOU >> Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related >> information" >> >> Hi Guys, >> After discussion with Hannes and Dong, I think it might be better to >> modify like this. It is the recovering of the texts about >> "PULL/PUSH/Access network related information" deleted by mistake or >> misunderstanding >> >> 3 Framework >> [snipped] >> In some deployment scenarios, QoS aware network elements may request >> authorization through the AAA cloud based on an incoming QoS >> reservation >> request. The network element will route the request to a designated >> authorizing entity. The authorizing entity will return the result of >> the >> authorization decision. In other deployment scenarios, the >> authorization >> will be initiated upon dynamic application state, so that the >> request >> must be authenticated and authorized based on information from one >> or >> more application servers. /*start of added*/In terms of the resource >> request sent from >> the application server to Authorizing Entity, the Authorizing Entity >> could identify the access network related information and select >> appropriate >> resource admission and control policies. The Push or pull mode also >> can be >> dynamically triggered based on the information in the request from >> application >> server, or statically configured according to operator's demand./*end >> of >> added*/ >> [snipped] >> >> B. R. >> Tina >> ----- Original Message ----- >> From: Tina TSOU >> To: dime@ietf.org >> Sent: Monday, July 09, 2007 5:27 PM >> Subject: [Dime] Diameter QoS Appl. >> >> Hi all, >> I suggest that some texts could be added in the beginning of 3.3 to >> smooth >> with the texts in 3.3.1 and 3.3.2. >> >> [snipped] >> 3.3. Authorization schemes >> >> Three basic authorization models for QoS reservations exist: one two >> -party and two three party models. In the three party QoS model >> (Figure 3), the authorization entity may be composed of two separate >> functional entities - Application Server which interacts with the QoS >> requesting entity and Authorizing Entity. The Application Server MAY >> indicate the access network related information in a service request >> to Authorizing Entity which can be used by the Authorizing Entity to >> select the appropriate resource admission and control policies. The >> service request from Application Server to Authorizing Entity MAY >> also indicate the admission control mode (i.e., "pull" or "push" >> model) in terms of which Authorizing Entity performs QoS >> authorization and then sends the policy decisions to the NE which >> performs QoS reservation. Authorization schemes for both pull >> and push mode will be described below in detail. >> >> 3.3.1. Authorization schemes for pull mode >> [snipped] >> B. R. >> Tina >> ________________________________________ >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 08:33:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xrS-0000Yl-UP; Thu, 12 Jul 2007 08:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xrR-0000Yg-UE for dime@ietf.org; Thu, 12 Jul 2007 08:33:33 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8xrN-0000je-9M for dime@ietf.org; Thu, 12 Jul 2007 08:33:33 -0400 Received: by wr-out-0506.google.com with SMTP id i23so80532wra for ; Thu, 12 Jul 2007 05:33:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=Y08SX/i9pVJzZdbfE0Sdcr5DSJl8cfGO8NRyX5t8qXSXwQEXB6JpV0/a6RFEW1ybt4IIH4HuKT9AlDEaDsrMy6CdnE/51gU0wp4Fjb5btctFFopANZAy1esDpda1G5gMws2KZTnjC5RJfRKUl7ojMBdcdmK8CGfIBO+ASyn/rL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=mVcJyKfLlmDMUWMFdh0xeSYuHzAx0hMcgP/QM5kgYpqpCUz5gQZyHd8c8PAMXf33juYNON6AaHHT+lRSeMtXRU9u3hUgnvK456CyMa9VE49GvXG2TexVPUbG3P4rSqQDTlmxgc1yWLTgywCpXKDFuMHcyZOYI+7RMQvNqHN2pKU= Received: by 10.142.155.4 with SMTP id c4mr42646wfe.1184243608195; Thu, 12 Jul 2007 05:33:28 -0700 (PDT) Received: by 10.143.41.21 with HTTP; Thu, 12 Jul 2007 05:33:28 -0700 (PDT) Message-ID: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> Date: Thu, 12 Jul 2007 09:33:28 -0300 From: "Christian Esteve" To: dime@ietf.org Subject: Re: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" MIME-Version: 1.0 X-Google-Sender-Auth: 17e88c65adf7dd1f X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1998726662==" Errors-To: dime-bounces@ietf.org --===============1998726662== Content-Type: multipart/alternative; boundary="----=_Part_13668_9839773.1184243608083" ------=_Part_13668_9839773.1184243608083 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tina, Agree that the AF should not be involved at network level QoS, I should be more careful when explaining my thoughts, actually what I wanted to point out is that some kind of access network information (obtained by P-header, NASS query, or other means.) could be used to assist the AE with regards to its mode of operation and the appropriate service/QoS mapping. Agree that the NE is better suited to map generic QoS into access specific QoS. Handling with generic QoS at the AE enables inter-domain AE communications. I was thinking on the following scenario: A single Application Server is supposed to interact with various Authorization Entities (1:n relationship between AS and AE, actually m:n should be the general case), each of them responsible for the NEs belonging to different access network technologies. AS: : AF (P-CSCF) / | \ AEs: PDF(3GPP) PDF (WLAN) PDF (WiMax) . NEs: x x x x x x x x x These are my thoughts: 1. The AS needs to know which is the AE responsible for authorizing the current session. The AS can query another entity (NASS) or based its AE selection on information provided at application level signaling (e.g. SIP P-headers.). Furthermore, the service attribute provided by the AS may differ (e.g. due to different capabilities or semantics supported) depending on the correspondent AE. Is this out-of-scope of the dime-qos doc? Any relation to the discovery mechanisms under study for Diameter? 2. The AE needs to know in which mode to operate (push or pull) for the session being authorized based on information coming from the AS and/or the NE. What information should be defined with these regards? Is there a convergent set of AVPs for both the AS-AE and AE-NE communications to inform about the mode of operation (push/pull, e.g. Operation-Mode AVP) and carry access network info (also referred to as Terminal-Mode AVP by Tina)? 3. I think the last version of the Framework description covers the discussed topics or do we still miss something? Regards, Christian > 3 Framework > [snipped] > In some deployment scenarios, QoS aware network elements may request > authorization through the AAA cloud based on an incoming QoS > reservation > request. The network element will route the request to a designated > authorizing entity. The authorizing entity will return the result of > the > authorization decision. In other deployment scenarios, the > authorization > will be initiated upon dynamic application state, so that the request > must be authenticated and authorized based on information from one or > more application servers. /*start of added*/In terms of the resource > request sent from > the application server to Authorizing Entity, the Authorizing Entity > could identify the access network related information and select > appropriate > resource admission and control policies. The Push or pull mode also > can be > dynamically triggered based on the information in the request from > application > server, or statically configured according to operator's demand./*end of > added*/ > [snipped] ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Jul 2007 14:39:40 +0800 > From: Tina TSOU > Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network > related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network > related information" > To: Christian Esteve , dime@ietf.org, Hannes > Tschofenig , Tina TSOU > > Message-ID: < 01a601c7c44f$6cc99840$864c460a@china.huawei.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Christian, > Moreover, > For mobile terminals, AF can get access network identifier from SIP > message header. > For fix terminals, AF can query the access network identifier via e2 > interface. The way carried by SIP is not granted by consensus. > > B. R. > Tina > > ----- Original Message ----- > From: Tina TSOU > To: Hannes Tschofenig ; dime@ietf.org ; Christian Esteve > Sent: Thursday, July 12, 2007 2:11 PM > Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related > Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" > > > > Hi Christian, > Actually, the QoS template is not chosen by AF (mapping to Application > Server here). It is determined by the policy in SPDF (mapping to Authorizing > Entity here) according to related information sent from AF to SPDF. There is > no need for AF to see the template information. > > B. R. > Tina > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: > tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > > > ----- Original Message ----- > From: Sun, Dong (Dong) > To: Christian Esteve ; dime@ietf.org ; Tina TSOU ; Hannes Tschofenig > Sent: Thursday, July 12, 2007 7:04 AM > Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network > related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network > relatedinformation" > > > Hi Chirstian, > > I agree, in certain circumstance e.g. IMS AF, it is possible to identify > the access network as you described. > Maybe, I guess, there is some confusion (to me) on the terminology used > here. If you are saying that AF may determine the service profile/attributes > upon access type, it would be fine in certain case (but it is out of the > scope in this doc). However, not sure if it is good idea to make the > application server involved in network level QoS selection, even it is worse > to make the AS select access specific QoS profile. > > Regards, > Dong > > > ------=_Part_13668_9839773.1184243608083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tina,

Agree that the AF should not be involved at network level QoS, I  should be more careful when explaining my thoughts, actually what I wanted to point out is that some kind of access network information (obtained by P-header, NASS query, or other means.) could be used to assist the AE with regards to its mode of operation and the appropriate service/QoS mapping. Agree that the NE is better suited to map generic QoS into access specific QoS. Handling with generic QoS at the AE enables inter-domain AE communications.

I was thinking on the following scenario: A single Application Server is supposed to interact with various Authorization Entities (1:n relationship between AS and AE, actually m:n should be the general case), each of them responsible for the NEs belonging to different access network technologies.

AS:                        : AF (P-CSCF)

                   /                      |                       \

AEs:     PDF(3GPP)     PDF (WLAN)      PDF (WiMax)
.
NEs:           x  x  x                  x x x                  x x x


These are my thoughts:

1. The AS needs to know which is the AE responsible for authorizing the current session. The AS can query another entity (NASS) or based its AE selection on information provided at application level signaling ( e.g. SIP P-headers.). Furthermore, the service attribute provided by the AS may differ (e.g. due to different capabilities or semantics supported) depending on the correspondent AE.
Is this out-of-scope of the dime-qos doc? Any relation to the discovery mechanisms under study for Diameter?

2. The AE needs to know in which mode to operate (push or pull) for the session being authorized based on information coming from the AS and/or the NE.
What information should be defined with these regards? Is there a convergent set of AVPs for both the AS-AE and AE-NE communications to inform about the mode of operation (push/pull, e.g. Operation-Mode AVP) and carry access network info (also referred to as Terminal-Mode AVP by Tina)?

3. I think the last version of the Framework description covers the discussed topics or do we still miss something?

Regards,
Christian

> 3 Framework
> [snipped]
> <t>In some deployment scenarios, QoS aware network elements may request
>      authorization through the AAA cloud based on an incoming QoS
> reservation
>      request. The network element will route the request to a designated
>      authorizing entity. The authorizing entity will return the result of
> the
>      authorization decision. In other deployment scenarios, the
> authorization
>      will be initiated upon dynamic application state, so that the request
>      must be authenticated and authorized based on information from one or
>      more application servers. /*start of added*/In terms of the resource
> request sent from
>      the application server to Authorizing Entity, the Authorizing Entity
>      could identify the access network related information and select
> appropriate
>      resource admission and control policies. The Push or pull mode also
> can be
>      dynamically triggered based on the information in the request from
> application
>   server, or statically configured according to operator's demand./*end of
> added*/</t>
> [snipped]


----------------------------------------------------------------------

Message: 1
Date: Thu, 12 Jul 2007 14:39:40 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: [Dime] Diameter QoS        Appl.-"PULL/PUSH/Access network
        related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network
        related information"
To: Christian Esteve < chesteve@gmx.net>, dime@ietf.org, Hannes
        Tschofenig <Hannes.Tschofenig@gmx.net>, Tina TSOU < tena@huawei.com>
Message-ID: < 01a601c7c44f$6cc99840$864c460a@china.huawei.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Christian,
Moreover,
For mobile terminals, AF can get access network identifier from SIP message header.
For fix terminals, AF can query the access network identifier via e2 interface. The way carried by SIP is not granted by consensus.

B. R.
Tina

  ----- Original Message -----
  From: Tina TSOU
  To: Hannes Tschofenig ; dime@ietf.org ; Christian Esteve
  Sent: Thursday, July 12, 2007 2:11 PM
  Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information"


  Hi Christian,
  Actually, the QoS template is not chosen by AF (mapping to Application Server here). It is determined by the policy in SPDF (mapping to Authorizing Entity here) according to related information sent from AF to SPDF. There is no need for AF to see the template information.

  B. R.
  Tina
  Messengers:
  MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com

  
  ----- Original Message -----
  From: Sun, Dong (Dong)
  To: Christian Esteve ; dime@ietf.org ; Tina TSOU ; Hannes Tschofenig
  Sent: Thursday, July 12, 2007 7:04 AM
  Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network relatedinformation"


  Hi Chirstian,

  I agree, in certain circumstance e.g. IMS AF, it is possible to identify the access network as you described.
  Maybe, I guess, there is some confusion (to me) on the terminology used here. If you are saying that AF may determine the service profile/attributes upon access type, it would be fine in certain case (but it is out of the scope in this doc). However, not sure if it is good idea to make the application server involved in network level QoS selection, even it is worse to make the AS select access specific QoS profile.

  Regards,
  Dong


------=_Part_13668_9839773.1184243608083-- --===============1998726662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1998726662==-- From dime-bounces@ietf.org Thu Jul 12 10:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zbE-0003N5-N1; Thu, 12 Jul 2007 10:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zbD-0003Mi-4w for dime@ietf.org; Thu, 12 Jul 2007 10:24:55 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8zb9-00040M-JN for dime@ietf.org; Thu, 12 Jul 2007 10:24:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1184250290!3358347!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32538 invoked from network); 12 Jul 2007 14:24:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 12 Jul 2007 14:24:50 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6CEOnEZ015148 for ; Thu, 12 Jul 2007 07:24:50 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l6CEOmiH005397 for ; Thu, 12 Jul 2007 09:24:49 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l6CEOlTj005367 for ; Thu, 12 Jul 2007 09:24:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Date: Thu, 12 Jul 2007 10:24:45 -0400 Message-ID: In-Reply-To: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfEgONIJIZTaPdZSpOemtvDfwEUWQADodkA References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> From: "McCann Peter-A001034" To: "Christian Esteve" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I don't think we should be designing a protocol that behaves differently depending on the type of access link. Everything in the Diameter cloud should be dealing exclusively with link-neutral QoS specifications, which will enable inter-domain operation and simplify settlement. Solutions that assume some SIP signaling from the endpoint to identify / classify the first-hop NE are limited. The QoS enforcement point may not be the first hop; in general any NE along the path between the two hosts involved in the call might need to play this role. I think the push model has some serious problems with discovering this=20 type of NE. The right solution is to require end-to-end, path-coupled signaling like NSIS with the pull mode of operation. =20 -Pete Christian Esteve wrote: > Hi Tina, >=20 > Agree that the AF should not be involved at network level QoS, I=20 > should be more careful when explaining my thoughts, actually what I > wanted to point out is that some kind of access network information > (obtained by P-header, NASS query, or other means.) could be used to > assist the AE with regards to its mode of operation and the > appropriate service/QoS mapping. Agree that the NE is better suited > to map generic QoS into access specific QoS. Handling with generic > QoS at the AE enables inter-domain AE communications. =20 >=20 > I was thinking on the following scenario: A single Application Server > is supposed to interact with various Authorization Entities (1:n > relationship between AS and AE, actually m:n should be the general > case), each of them responsible for the NEs belonging to different > access network technologies. =20 >=20 > AS: : AF (P-CSCF) >=20 > / | \ >=20 > AEs: PDF(3GPP) PDF (WLAN) PDF (WiMax) > . > NEs: x x x x x x x x x >=20 >=20 > These are my thoughts: >=20 > 1. The AS needs to know which is the AE responsible for authorizing > the current session. The AS can query another entity (NASS) or based > its AE selection on information provided at application level > signaling ( e.g. SIP P-headers.). Furthermore, the service attribute > provided by the AS may differ (e.g. due to different capabilities or > semantics supported) depending on the correspondent AE. =20 > Is this out-of-scope of the dime-qos doc? Any relation to the > discovery mechanisms under study for Diameter?=20 >=20 > 2. The AE needs to know in which mode to operate (push or pull) for > the session being authorized based on information coming from the AS > and/or the NE. =20 > What information should be defined with these regards? Is there a > convergent set of AVPs for both the AS-AE and AE-NE communications to > inform about the mode of operation (push/pull, e.g. Operation-Mode > AVP) and carry access network info (also referred to as Terminal-Mode > AVP by Tina)? =20 >=20 > 3. I think the last version of the Framework description covers the > discussed topics or do we still miss something?=20 >=20 > Regards, > Christian >=20 >> 3 Framework >> [snipped] >> In some deployment scenarios, QoS aware network elements may >> request authorization through the AAA cloud based on an >> incoming QoS reservation request. The network element will >> route the request to a designated authorizing entity. The >> authorizing entity will return the result=20 >> of the >> authorization decision. In other deployment scenarios, the >> authorization will be initiated upon dynamic application state, >> so that the request must be authenticated and authorized based >> on information from one or more application servers. /*start of >> added*/In terms of the=20 >> resource request sent from >> the application server to Authorizing Entity, the Authorizing >> Entity could identify the access network related information >> and select appropriate resource admission and control policies. >> The Push or pull mode=20 >> also can be >> dynamically triggered based on the information in the request >> from application >> server, or statically configured according to operator's >> demand./*end of added*/ [snipped] >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Thu, 12 Jul 2007 14:39:40 +0800 > From: Tina TSOU > Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access > network related Re: [Dime] Diameter QoS > Appl.-"PULL/PUSH/Access network related information" > To: Christian Esteve < chesteve@gmx.net >, > dime@ietf.org , Hannes Tschofenig > , Tina TSOU < tena@huawei.com > > Message-ID: < > 01a601c7c44f$6cc99840$864c460a@china.huawei.com > > > Content-Type: text/plain; charset=3D"iso-8859-1" =20 >=20 > Hi Christian, > Moreover, > For mobile terminals, AF can get access network identifier from SIP > message header. For fix terminals, AF can query the access network > identifier via e2 interface. The way carried by SIP is not granted by > consensus. =20 >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: Tina TSOU > To: Hannes Tschofenig ; dime@ietf.org ; Christian Esteve > Sent: Thursday, July 12, 2007 2:11 PM > Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network > related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network > related information" =20 >=20 >=20 > Hi Christian, > Actually, the QoS template is not chosen by AF (mapping to > Application Server here). It is determined by the policy in SPDF > (mapping to Authorizing Entity here) according to related information > sent from AF to SPDF. There is no need for AF to see the template > information. =20 >=20 > B. R. > Tina > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU =20 > Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com=20 >=20 >=20 > ----- Original Message ----- > From: Sun, Dong (Dong) > To: Christian Esteve ; dime@ietf.org ; Tina TSOU ; Hannes > Tschofenig Sent: Thursday, July 12, 2007 7:04 AM > Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network > related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network > relatedinformation" =20 >=20 >=20 > Hi Chirstian, >=20 > I agree, in certain circumstance e.g. IMS AF, it is possible to > identify the access network as you described. Maybe, I guess, > there is some confusion (to me) on the terminology used here. If you > are saying that AF may determine the service profile/attributes upon > access type, it would be fine in certain case (but it is out of the > scope in this doc). However, not sure if it is good idea to make the > application server involved in network level QoS selection, even it > is worse to make the AS select access specific QoS profile. =20 >=20 > Regards, > Dong _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 11:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90qm-0001fQ-6N; Thu, 12 Jul 2007 11:45:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90qk-0001ZV-Vt for dime@ietf.org; Thu, 12 Jul 2007 11:45:03 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I90qk-0004v2-Jq for dime@ietf.org; Thu, 12 Jul 2007 11:45:02 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6CFiPTU009125; Thu, 12 Jul 2007 11:44:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Date: Thu, 12 Jul 2007 11:44:25 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DECE@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network related information" Thread-Index: AcfET81VQZ8qxV1wT6u2VczyFsnC+gASuIT6 References: <008201c7c20b$64755b70$864c460a@china.huawei.com> <029b01c7c3a3$7b5d8300$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E718805B@sonusmail04.sonusnet.com> <013101c7c449$c31ec9a0$864c460a@china.huawei.com> <01ab01c7c44f$c82b7460$864c460a@china.huawei.com> From: "Asveren, Tolga" To: "Tina TSOU" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, What I was wondering was not the need for push/pull mode but whether we = foresee any scenario where application server would initiate a session = to authorizing entity for pull-mode (seems unlikely to me, probably it = will be the other way around)? Thanks, Tolga -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Thu 7/12/2007 2:42 AM To: Asveren, Tolga; dime@ietf.org; Tina TSOU Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network = related information" =20 Hi again:) In addition, PULL mode can be also used in Fix network; the precondition = is that the terminal is QoS aware, therefore the mobile terminals for = mobile network use PULL mode more frequently. I drew a picture but it exceeds 40 KB, so it is not able to be sent = through=20 the ML, so I will send it to you personally;-) B. R. Tina ----- Original Message -----=20 From: "Tina TSOU" To: ; "Asveren, Tolga" Sent: Thursday, July 12, 2007 1:59 PM Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network = related information" > Hi Tolga, > Pull mode is needed in the mobile network scenario and push mode is = needed > in the fixed network scenario. When the interfaces are converged, we = have > to distinguish which mode to use. > B. R. > Tina > > ----- Original Message -----=20 > From: "Asveren, Tolga" > To: > Sent: Thursday, July 12, 2007 2:49 AM > Subject: RE: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network = related > information" > > > Hi Tina, > > One question about the proposed addition: > What type of scenarios would require pull-mode of operation, if > authorizing entity receives a request from an application server? > > Thanks, > Tolga > > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, July 11, 2007 6:09 AM > To: dime@ietf.org; Tina TSOU > Subject: Re: [Dime] Diameter QoS Appl. -"PULL/PUSH/Access network = related > information" > > Hi Guys, > After discussion with Hannes and Dong, I think it might be better to > modify like this. It is the recovering of the texts about > "PULL/PUSH/Access network related information" deleted by mistake or > misunderstanding > > 3 Framework > [snipped] > In some deployment scenarios, QoS aware network elements may = request > authorization through the AAA cloud based on an incoming QoS > reservation > request. The network element will route the request to a = designated > authorizing entity. The authorizing entity will return the result = of > the > authorization decision. In other deployment scenarios, the > authorization > will be initiated upon dynamic application state, so that the = request > must be authenticated and authorized based on information from = one or > more application servers. /*start of added*/In terms of the = resource > request sent from > the application server to Authorizing Entity, the Authorizing = Entity > could identify the access network related information and select > appropriate > resource admission and control policies. The Push or pull mode = also > can be > dynamically triggered based on the information in the request = from > application > server, or statically configured according to operator's = demand./*end of > added*/ > [snipped] > > B. R. > Tina > ----- Original Message -----=20 > From: Tina TSOU > To: dime@ietf.org > Sent: Monday, July 09, 2007 5:27 PM > Subject: [Dime] Diameter QoS Appl. > > Hi all, > I suggest that some texts could be added in the beginning of 3.3 to = smooth > with the texts in 3.3.1 and 3.3.2. > > [snipped] > 3.3. Authorization schemes > > Three basic authorization models for QoS reservations exist: one two > -party and two three party models. In the three party QoS model > (Figure 3), the authorization entity may be composed of two separate > functional entities - Application Server which interacts with the QoS > requesting entity and Authorizing Entity. The Application Server MAY > indicate the access network related information in a service request > to Authorizing Entity which can be used by the Authorizing Entity to > select the appropriate resource admission and control policies. The > service request from Application Server to Authorizing Entity MAY > also indicate the admission control mode (i.e., "pull" or "push" > model) in terms of which Authorizing Entity performs QoS > authorization and then sends the policy decisions to the NE which > performs QoS reservation. Authorization schemes for both pull > and push mode will be described below in detail. > > 3.3.1. Authorization schemes for pull mode > [snipped] > B. R. > Tina > ________________________________________ > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 12:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91GX-0007Xg-8T; Thu, 12 Jul 2007 12:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91GW-0007XK-8M for dime@ietf.org; Thu, 12 Jul 2007 12:11:40 -0400 Received: from web84103.mail.mud.yahoo.com ([68.142.206.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I91GS-0007E5-Jx for dime@ietf.org; Thu, 12 Jul 2007 12:11:40 -0400 Received: (qmail 91809 invoked by uid 60001); 12 Jul 2007 16:11:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=njOFNTVO1G7eYJcb3n6dr2RW/i8ztW+xZZgzvsoW7Jz6F7yDzMHgtU9Nk9U9YL50ZZ3VCiXNxWN90o3bhcBslmNUybCKR3hXOtkiNKWKo/0CyeSnCeg5r6WkF8ITbY48enot8OhSwx6xemJ6k2v1nM1tiV8TseDQ2UcPxcNnbnQ=; X-YMail-OSG: lwu4pg0VM1lnlnDUbBJNZBZRgfc5bxB78H09Zkn0N8oACBKZkhQnBs7PJYDIjqA30FjIEph1ctllR9oEps43J3ArbkZl8KI1ILNflUEoXEph5Y8- Received: from [206.16.17.212] by web84103.mail.mud.yahoo.com via HTTP; Thu, 12 Jul 2007 09:11:36 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Thu, 12 Jul 2007 09:11:36 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt To: jouni.korhonen@teliasonera.com MIME-Version: 1.0 Message-ID: <68589.88262.qm@web84103.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: dime@ietf.org, netlmm@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0888884754==" Errors-To: dime-bounces@ietf.org --===============0888884754== Content-Type: multipart/alternative; boundary="0-831683792-1184256696=:88262" --0-831683792-1184256696=:88262 Content-Type: text/plain; charset=ascii Hi Jouni, So you're saying that Radius compatibility is not a requirement for you. I thought that it should be. Given the fact that the number of new AVPs needed are not so high and PMIP is MIP extension, shouldn't it be nice to be able to define compatible applications for Radius and Diameter? Any ways, this was what we had in mind in draft-xia-netlmm-radius, believe it or not. Kind regards, Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: sarikaya@ieee.org Cc: netlmm@ietf.org; dime@ietf.org Sent: Wednesday, July 11, 2007 6:15:09 PM Subject: RE: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Hi Behcet, Because I want to have a clean separation from NAS (i.e. MAG) and AAA point of view which AVPs belong to PMIP6 side and which to e.g. MIP6 side. The same NAS/AAA may be used to bootstrap MIP6, or bootstrap PMIP6.. or do both at the same time (and I am not defining new applications to do the separation). There are some AVPs from rfc4004 that I am looking forward to reuse, if just feasible. Cheers, Jouni ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Wednesday, July 11, 2007 10:50 PM To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc: netlmm@ietf.org; dime@ietf.org Subject: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Hi Jouni, I read the draft and have some comments: Given the fact that Radius is still around and in Diameter it is possible to make things quite Radius compatible, I wonder why you have not used already existing attributes? I mean the attributes defined in draft-ietf-mip6-radius-02? Regards, Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: netlmm@ietf.org; dime@ietf.org Sent: Thursday, July 5, 2007 4:13:32 AM Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > > This specification defines the Diameter support for the > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt > --0-831683792-1184256696=:88262 Content-Type: text/html; charset=ascii
Hi Jouni,
  So you're saying that Radius compatibility is not a requirement for you. I thought that it should be. Given the fact that the number of new AVPs needed are not so high and PMIP is MIP extension, shouldn't it be nice to be able to define compatible applications  for Radius and Diameter?
  Any ways, this was what we had in mind in draft-xia-netlmm-radius, believe it or not.

Kind regards,

Behcet
----- Original Message ----
From: "jouni.korhonen@teliasonera.com" <jouni.korhonen@teliasonera.com>
To: sarikaya@ieee.org
Cc: netlmm@ietf.org; dime@ietf.org
Sent: Wednesday, July 11, 2007 6:15:09 PM
Subject: RE: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt

Hi Behcet,

Because I want to have a clean separation from NAS (i.e. MAG) and AAA
point of
view which AVPs belong to PMIP6 side and which to e.g. MIP6 side. The
same
NAS/AAA may be used to bootstrap MIP6, or bootstrap PMIP6.. or do both
at the
same time (and I am not defining new applications to do the separation).
There
are some AVPs from rfc4004 that I am looking forward to reuse, if just
feasible.

Cheers,
    Jouni


________________________________

    From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
    Sent: Wednesday, July 11, 2007 10:50 PM
    To: Korhonen, Jouni /TeliaSonera Finland Oyj
    Cc: netlmm@ietf.org; dime@ietf.org
    Subject: Re: [Dime] FW: I-D
ACTION:draft-korhonen-dime-pmip6-00.txt
    
    
    Hi Jouni,
      I read the draft and have some comments:
    Given the fact that Radius is still around and in Diameter it is
possible to make things quite Radius compatible, I wonder why you have
not used already existing attributes? I mean the attributes defined in
draft-ietf-mip6-radius-02?
    
    Regards,
    
    Behcet
    
    
    ----- Original Message ----
    From: "jouni.korhonen@teliasonera.com"
<jouni.korhonen@teliasonera.com>
    To: netlmm@ietf.org; dime@ietf.org
    Sent: Thursday, July 5, 2007 4:13:32 AM
    Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt
    
    

    FYI.. this Dime I-D might be of interest for PMIPv6 folks. The
    I-D describes MAG-AAA and LMA-AAA Diameter interactions for
    PMIPv6. Comments are welcome as a lot more work is still ahead.
    
    Cheers,
        Jouni
    
    
    > -----Original Message-----
    > From: Internet-Drafts@ietf.org
[mailto:Internet-Drafts@ietf.org]
    > Sent: Thursday, June 28, 2007 10:50 PM
    > To: i-d-announce@ietf.org
    > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt
    >
    > A New Internet-Draft is available from the on-line
    > Internet-Drafts directories.
    >
    >
    >     Title        : Diameter Proxy Mobile IPv6: Support For
    >                           Mobility Access Gateway and Local
Mobility
    >                           Anchor to Diameter Server
Interaction
    >     Author(s)    : J. Korhonen, et al.
    >     Filename    : draft-korhonen-dime-pmip6-00.txt
    >     Pages        : 20
    >     Date        : 2007-6-28
    >    
    >    This specification defines the Diameter support for the
    > Proxy Mobile
    >    IPv6.  The policy information needed by the Proxy Mobile
IPv6 is
    >    defined in mobile node's policy profile, which gets
downloaded from
    >    the Diameter server to the Mobile Access Gateway once the
    > mobile node
    >    roams into a Proxy Mobile IPv6 Domain and performs the
access
    >    authentication.  The access authentication procedure into
the Proxy
    >    Mobile IPv6 Domain resembles the Mobile IPv6 integrated
scenario
    >    bootstrapping.  Rather than defining a completely new set
of
    >    attributes or a new Diameter application this specification
only
    >    leverages the work already done for the Mobile IPv6
bootstrapping.
    >
    >
    > A URL for this Internet-Draft is:
    >
http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt
    >
    



--0-831683792-1184256696=:88262-- --===============0888884754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0888884754==-- From dime-bounces@ietf.org Thu Jul 12 12:17:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91MS-0000U1-KR; Thu, 12 Jul 2007 12:17:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91KS-000413-Pd; Thu, 12 Jul 2007 12:15:46 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91KS-0007ON-GV; Thu, 12 Jul 2007 12:15:44 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 788ED329DA; Thu, 12 Jul 2007 16:15:14 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jx-0003GX-HI; Thu, 12 Jul 2007 12:15:13 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:13 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-05.txt Pages : 20 Date : 2007-7-12 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-integrated-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-integrated-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12113356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12113356.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jul 12 12:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91eA-00038D-1T; Thu, 12 Jul 2007 12:36:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91e9-00037e-2C for dime@ietf.org; Thu, 12 Jul 2007 12:36:05 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I91e7-0002Pf-5Q for dime@ietf.org; Thu, 12 Jul 2007 12:36:04 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1184258122!15303265!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 1534 invoked from network); 12 Jul 2007 16:35:22 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-128.messagelabs.com with SMTP; 12 Jul 2007 16:35:22 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l6CGZLPo023485 for ; Thu, 12 Jul 2007 09:35:21 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l6CGZK1h027987 for ; Thu, 12 Jul 2007 11:35:20 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6CGZJq7027970 for ; Thu, 12 Jul 2007 11:35:19 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Date: Thu, 12 Jul 2007 12:35:18 -0400 Message-ID: In-Reply-To: <4696556E.8020809@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Thread-Index: AcfEoLYHKETnaTx1QACewa7FNukoBwAAFqUQ References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> From: "McCann Peter-A001034" To: "Tom Taylor" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dime@ietf.org, Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tom Taylor wrote: > I think you have a few premises mixed up. See comments marked with > [PTT].=20 >=20 > McCann Peter-A001034 wrote: >> I don't think we should be designing a protocol that behaves >> differently depending on the type of access link. Everything in the >> Diameter cloud should be dealing exclusively with link-neutral QoS >> specifications, which will enable inter-domain operation and simplify >> settlement. >=20 > [PTT] Push/pull is a question of terminal technology, not link > technology.=20 There was a proposal to put link type (3GPP, 3GPP2, WiFi, Wimax etc)=20 into the QoS application as a new AVP, and to select different user profiles based on the link type. My point is, there should be one profile for any given user and it should be based on link-neutral QoS specifications. >> Solutions that assume some SIP signaling from the endpoint to >> identify / classify the first-hop NE are limited. The QoS >> enforcement point may not be the first hop; in general any NE along >> the path between the two hosts involved in the call might need to >> play this role. I think the push model has some serious problems >> with discovering this type of NE. The right solution is to require >> end-to-end, path-coupled signaling like NSIS with the pull mode of >> operation.=20 >>=20 > [PTT] Which NE is it that you are worried about discovering? And in > the ITU-T architecture at least, provision is being made for > discovery at the RACF level. All the AF needs is the right entry > point, and it can be configured with that. =20 In general any router along the path might need to reserve resources for a given flow, and to request authorization from the Diameter cloud. I don't think we should limit ourselves to an architecture that only supports discovery of the first hop (or something near the first hop) as part of a Diameter application intended to support the Internet architecture. >> -Pete >>=20 > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 12:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91l9-0005BR-72; Thu, 12 Jul 2007 12:43:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Qd-0006wi-2h for dime@ietf.org; Thu, 12 Jul 2007 12:22:07 -0400 Received: from smtp106.rog.mail.re2.yahoo.com ([68.142.225.204]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I91QR-0007R6-Ar for dime@ietf.org; Thu, 12 Jul 2007 12:22:06 -0400 Received: (qmail 98386 invoked from network); 12 Jul 2007 16:21:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XX8rUBU/sLFsmVaG9S5TIefp+JPrd7psEjSqXH2jp+BkGO+mXezJV5wLN30yNLyXWeTrJuHauAkKY6d8+MSGjVy8cKFq+pyIjw4HlU5H6cLIZ5jLlWgBYMLVo672VBtIMuB+6Dr0c6nPIAgODDi+mHkuQaLArCxcd4pKHGifqy8= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 12 Jul 2007 16:21:26 -0000 X-YMail-OSG: srcSz18VM1mFk1sKoX21r2r92YC8NvJ2iWPZiP.LmClHpwJqOX9Kug8ZZdx9m_j5cA-- Message-ID: <4696556E.8020809@rogers.com> Date: Thu, 12 Jul 2007 12:23:10 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dime@ietf.org, Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think you have a few premises mixed up. See comments marked with [PTT]. McCann Peter-A001034 wrote: > I don't think we should be designing a protocol that > behaves differently depending on the type of access > link. Everything in the Diameter cloud should be > dealing exclusively with link-neutral QoS specifications, > which will enable inter-domain operation and simplify > settlement. [PTT] Push/pull is a question of terminal technology, not link technology. > > Solutions that assume some SIP signaling from the endpoint > to identify / classify the first-hop NE are limited. The > QoS enforcement point may not be the first hop; in general > any NE along the path between the two hosts involved in > the call might need to play this role. I think the push > model has some serious problems with discovering this > type of NE. The right solution is to require end-to-end, > path-coupled signaling like NSIS with the pull mode of > operation. > [PTT] Which NE is it that you are worried about discovering? And in the ITU-T architecture at least, provision is being made for discovery at the RACF level. All the AF needs is the right entry point, and it can be configured with that. > -Pete > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 14:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93VI-0002AF-2h; Thu, 12 Jul 2007 14:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93VG-0002A5-Q0 for dime@ietf.org; Thu, 12 Jul 2007 14:35:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I93VC-0000F3-AZ for dime@ietf.org; Thu, 12 Jul 2007 14:35:02 -0400 Received: (qmail invoked by alias); 12 Jul 2007 18:34:56 -0000 Received: from p54986E40.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.110.64] by mail.gmx.net (mp009) with SMTP; 12 Jul 2007 20:34:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fpwA2byTf13aKAplCjdadE3wo805B/oYmjYohvN fud6zIsdzPAD4G Message-ID: <4696744D.30005@gmx.net> Date: Thu, 12 Jul 2007 20:34:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> In-Reply-To: <4696556E.8020809@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: dime@ietf.org, McCann Peter-A001034 , Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tom, Tom Taylor wrote: > I think you have a few premises mixed up. See comments marked with [PTT]. > > McCann Peter-A001034 wrote: >> I don't think we should be designing a protocol that >> behaves differently depending on the type of access >> link. Everything in the Diameter cloud should be >> dealing exclusively with link-neutral QoS specifications, >> which will enable inter-domain operation and simplify >> settlement. > > [PTT] Push/pull is a question of terminal technology, not link > technology. > That's probably only a terminology problem. Still, there is the question which entity needs to understand the QoS model of the specific node being configured. There are essentially three possibilities: * AF * PDF * NE >> >> Solutions that assume some SIP signaling from the endpoint >> to identify / classify the first-hop NE are limited. The >> QoS enforcement point may not be the first hop; in general >> any NE along the path between the two hosts involved in >> the call might need to play this role. I think the push >> model has some serious problems with discovering this type of NE. >> The right solution is to require end-to-end, >> path-coupled signaling like NSIS with the pull mode of >> operation. > [PTT] Which NE is it that you are worried about discovering? And in > the ITU-T architecture at least, provision is being made for discovery > at the RACF level. All the AF needs is the right entry point, and it > can be configured with that. > In a push model, in the end the AF needs to contact a specific PDF related to the access network or a NE directly. Pete calls this discovery and I agree that this is a valid term in this context. Consider an arbitrary AF, like a streaming server installed on my webserver. Then, you click on it -- how would it know where to push QoS policies to? I know that with the assumptions being made in some architectures, for example with the 3GPP IMS, this discovery step is obviously a lot easier since the application server is a) either in the access network (e.g., the P-CSCF), or b) associated with the operator of the access network using some business relationship >> -Pete >> Ciao Hannes > ... > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 15:04:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93xi-0006R1-TI; Thu, 12 Jul 2007 15:04:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93xg-0006Oj-Jb; Thu, 12 Jul 2007 15:04:24 -0400 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I93xg-0004IG-2u; Thu, 12 Jul 2007 15:04:24 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l6CJ3YFR011019; Thu, 12 Jul 2007 22:03:35 +0300 (EEST) Received: from [131.177.101.87] ([131.177.101.87]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l6CJ3Oqd011002; Thu, 12 Jul 2007 22:03:27 +0300 (EEST) From: jouni.korhonen@teliasonera.com To: Behcet Sarikaya Subject: VS: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Date: Thu, 12 Jul 2007 22:03:22 +0300 Message-ID: <443n9d01KSY3.mf28TKYQ@smtp.dave.sonera.fi> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.1 (++) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: dime@ietf.org, netlmm@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jouni.korhonen@teliasonera.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Behcet, Aren't you drawing your conclusions slightly too quickly now..? I was only = saying that those MIP6 attributes do not necessarily fit as-is to all = deployment scenarios we might have.=20 Cheers, Jouni -- alkuper. viesti -- Aihe: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt L=C3=A4hett=C3=A4j=C3=A4: Behcet Sarikaya P=C3=A4iv=C3=A4m=C3=A4=C3=A4r=C3=A4: 12.07.2007 16:12 Hi Jouni, So you're saying that Radius compatibility is not a requirement for you. = I thought that it should be. Given the fact that the number of new AVPs = needed are not so high and PMIP is MIP extension, shouldn't it be nice to = be able to define compatible applications for Radius and Diameter? Any ways, this was what we had in mind in draft-xia-netlmm-radius, = believe it or not. Kind regards, Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" = To: sarikaya@ieee.org Cc: netlmm@ietf.org; dime@ietf.org Sent: Wednesday, July 11, 2007 6:15:09 PM Subject: RE: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt Hi Behcet, =20 Because I want to have a clean separation from NAS (i.e. MAG) and AAA point of view which AVPs belong to PMIP6 side and which to e.g. MIP6 side. The same NAS/AAA may be used to bootstrap MIP6, or bootstrap PMIP6.. or do = both at the same time (and I am not defining new applications to do the = separation). There are some AVPs from rfc4004 that I am looking forward to reuse, if = just feasible. =20 Cheers, Jouni=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Wednesday, July 11, 2007 10:50 PM To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc: netlmm@ietf.org; dime@ietf.org Subject: Re: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt =20 =20 Hi Jouni, I read the draft and have some comments: Given the fact that Radius is still around and in Diameter it is possible to make things quite Radius compatible, I wonder why you = have not used already existing attributes? I mean the attributes defined = in draft-ietf-mip6-radius-02? =20 Regards, =20 Behcet =20 =20 ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: netlmm@ietf.org; dime@ietf.org Sent: Thursday, July 5, 2007 4:13:32 AM Subject: [Dime] FW: I-D ACTION:draft-korhonen-dime-pmip6-00.txt = =20 =20 FYI.. this Dime I-D might be of interest for PMIPv6 folks. The I-D describes MAG-AAA and LMA-AAA Diameter interactions for PMIPv6. Comments are welcome as a lot more work is still ahead. =20 Cheers, Jouni =20 =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, June 28, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-dime-pmip6-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Diameter Proxy Mobile IPv6: Support For > Mobility Access Gateway and Local Mobility=20 > Anchor to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-00.txt > Pages : 20 > Date : 2007-6-28 > =20 > This specification defines the Diameter support for the=20 > Proxy Mobile > IPv6. The policy information needed by the Proxy Mobile IPv6 is > defined in mobile node's policy profile, which gets downloaded from > the Diameter server to the Mobile Access Gateway once the=20 > mobile node > roams into a Proxy Mobile IPv6 Domain and performs the access > authentication. The access authentication procedure into the Proxy > Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario > bootstrapping. Rather than defining a completely new set of > attributes or a new Diameter application this specification only > leverages the work already done for the Mobile IPv6 bootstrapping. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-00.txt >=20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 16:47:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95Zj-0007Cr-U5; Thu, 12 Jul 2007 16:47:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95Zg-00070m-D5 for dime@ietf.org; Thu, 12 Jul 2007 16:47:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I95Zf-0000qk-UV for dime@ietf.org; Thu, 12 Jul 2007 16:47:44 -0400 Received: (qmail invoked by alias); 12 Jul 2007 20:47:02 -0000 Received: from p54987AC0.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.192] by mail.gmx.net (mp037) with SMTP; 12 Jul 2007 22:47:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/PCApSXbDPDKq8+tWcLhevnS3XZ8aqjRJ6Dj4IWZ nWiq238UobS+XG Message-ID: <4696933F.3050108@gmx.net> Date: Thu, 12 Jul 2007 22:46:55 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Scott O Bradner Subject: [Dime] [Fwd: RADEXT & DIME review of a MBONED ID] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi folks, there is a review request for a document developed within another working group that seems to have AAA related content. Is someone willing todo a review? Ciao Hannes -------- Original Message -------- Subject: RADEXT & DIME review of a MBONED ID Date: Thu, 12 Jul 2007 16:25:03 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) To: Bernard_Aboba@hotmail.com, d.b.nelson@comcast.net, dave@frascone.com, Hannes.Tschofenig@gmx.net MBONED has been working on "AAA Framework for Multicasting" (draft-ietf-mboned-multiaaa-framework-04.txt) - the topic seems to overlap the work in both of your WGs can you take a quick look to see if it would be reasonable to have a working group last call type of review of the document in both the radext and dime WGs? Tnx Scott -------- Forwarded Message -------- Subject: I-D ACTION:draft-ietf-mboned-multiaaa-framework-04.txt Date: Thu, 12 Jul 2007 12:15:18 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mboned@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : AAA Framework for Multicasting Author(s) : H. Satou, et al. Filename : draft-ietf-mboned-multiaaa-framework-04.txt Pages : 20 Date : 2007-7-12 IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify (if not authenticate, especially within the context of enforcing electronic payment schemes) and to invoice such customers in a reliable and efficient manner. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in draft-ietf-mboned- maccnt-req-04.txt, "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services". The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 18:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I97IT-0005eT-Kp; Thu, 12 Jul 2007 18:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I97IS-0005eJ-Lm for dime@ietf.org; Thu, 12 Jul 2007 18:38:04 -0400 Received: from smtp103.rog.mail.re2.yahoo.com ([206.190.36.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I97IO-0008Lr-Bh for dime@ietf.org; Thu, 12 Jul 2007 18:38:04 -0400 Received: (qmail 34474 invoked from network); 12 Jul 2007 22:38:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fOgJTKvScHkkfe5ZcnqzEn6B4Vjpyt8GBuDTBK6XH3/wd8X/UmvCvgvcjDxZq9ithbNsRuvfrNPAgn+d/GbhuQFoipkxBVJAxpJqFuYOclS5H/4y/OE22Xofwn6co28DDZsCk7/ZARKS6mjwvQEoHuGvGCojV+bvIFuOhE0WnYg= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 12 Jul 2007 22:38:00 -0000 X-YMail-OSG: m1FhsDEVM1mM8LqrpjAIUx2PHK8Kr3ApYBf7oWrgDIsc1nj3aJv.q4plwdQ.bXQVmA-- Message-ID: <4696ADC0.2080201@rogers.com> Date: Thu, 12 Jul 2007 18:40:00 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org, Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org See at end. McCann Peter-A001034 wrote: > Tom Taylor wrote: ... > >>> Solutions that assume some SIP signaling from the endpoint to >>> identify / classify the first-hop NE are limited. The QoS >>> enforcement point may not be the first hop; in general any NE along >>> the path between the two hosts involved in the call might need to >>> play this role. I think the push model has some serious problems >>> with discovering this type of NE. The right solution is to require >>> end-to-end, path-coupled signaling like NSIS with the pull mode of >>> operation. >>> >> [PTT] Which NE is it that you are worried about discovering? And in >> the ITU-T architecture at least, provision is being made for >> discovery at the RACF level. All the AF needs is the right entry >> point, and it can be configured with that. > > In general any router along the path might need to reserve resources > for a given flow, and to request authorization from the Diameter cloud. > I don't think we should limit ourselves to an architecture that only > supports discovery of the first hop (or something near the first hop) > as part of a Diameter application intended to support the Internet > architecture. > [PTT] Thinking about this a bit more, I guess the choice (making the assumption that the Diameter protocol is used) is between a network of Diameter servers (not a "Diameter cloud") in the RACF layer, versus a network of routers using NSIS between them with vertical relationships to local PDFs. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 12 19:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I984R-0006TQ-1V; Thu, 12 Jul 2007 19:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I984Q-0006Sn-7u for dime@ietf.org; Thu, 12 Jul 2007 19:27:38 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I984M-0000uj-R4 for dime@ietf.org; Thu, 12 Jul 2007 19:27:38 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6CNRWYf002911; Thu, 12 Jul 2007 18:27:32 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 18:27:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Date: Thu, 12 Jul 2007 18:27:31 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209AF@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfEoLYHKETnaTx1QACewa7FNukoBwAAFqUQAA12b1A= References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Tom Taylor" X-OriginalArrivalTime: 12 Jul 2007 23:27:32.0027 (UTC) FILETIME=[3854A8B0:01C7C4DC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Christian Esteve , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org See my comment as [DS]=20 -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, July 12, 2007 12:35 PM To: Tom Taylor Cc: dime@ietf.org; Christian Esteve Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" [snip] >> Solutions that assume some SIP signaling from the endpoint to=20 >> identify / classify the first-hop NE are limited. The QoS=20 >> enforcement point may not be the first hop; in general any NE along=20 >> the path between the two hosts involved in the call might need to=20 >> play this role. I think the push model has some serious problems=20 >> with discovering this type of NE. The right solution is to require=20 >> end-to-end, path-coupled signaling like NSIS with the pull mode of=20 >> operation. >>=20 > [PTT] Which NE is it that you are worried about discovering? And in=20 > the ITU-T architecture at least, provision is being made for discovery > at the RACF level. All the AF needs is the right entry point, and it=20 > can be configured with that. In general any router along the path might need to reserve resources for a given flow, and to request authorization from the Diameter cloud. I don't think we should limit ourselves to an architecture that only supports discovery of the first hop (or something near the first hop) as part of a Diameter application intended to support the Internet architecture. >> -Pete [snip] [DS] not sure whether any router along the path has to reserve resources on per micro-flow level in reality (don't want to repeat the scalability and cost issues of per flow IntServ model). I can see the need for certain resource scarce bottleneck links e.g. air interface, but don't perceive the necessity in the high capacity aggregation network segment. In other words, the NE for per flow policy enforcement would be taken in certain anchor points or overlay nodes typically, which may result in the discovery requirement in the Push model. (Otherwise, why the policy server needs to discover the right spot if every NE would perform the enforcement).=20 However, I don't think the path-coupled signaling is the best solution for all kind of scenarios.(hope no need to harp on the reasoning :-). Just like to point out one truth, even the path-coupled signaling is used with pull model, the NE still needs to identify the right server for authorization, sort of discovery. Although the discovery for Push mode is a bit complex, but don't think it would be more difficult compared to mandate every terminal support the intelligence of full-blown Qos and path coupled signaling, from e2e perspective.=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 05:57:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HuF-0000pK-6k; Fri, 13 Jul 2007 05:57:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HuD-0000os-6a for dime@ietf.org; Fri, 13 Jul 2007 05:57:45 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9HuA-0003We-LO for dime@ietf.org; Fri, 13 Jul 2007 05:57:45 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL400DDE3E28X@szxga02-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 17:51:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL4000YI3E0FC@szxga02-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 17:51:38 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL400LZ93E0FE@szxml04-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 17:51:36 +0800 (CST) Date: Fri, 13 Jul 2007 17:51:35 +0800 From: Tina TSOU To: Hannes Tschofenig Message-id: <00ba01c7c533$66d9eb30$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_/Mqvl2OCacbndpIHMJ13iA)" X-Priority: 3 X-MSMail-priority: Normal References: +ADw-4694B447.8080800+AEA-gmx.net+AD4- +ADw-4694B4F0.5060804+AEA-gmx.net+AD4- +ADw-032001c7c3af+ACQ-07676c20+ACQ-864c460a+AEA-china.huawei.com+AD4- +ADw-00d401c7c431+ACQ-e5bf9c90+ACQ-864c460a+AEA-china.huawei.com+AD4- +ADw-4695E525.1010800+AEA-gmx.net+AD4- X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: dime@ietf.org Subject: [Dime] Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_/Mqvl2OCacbndpIHMJ13iA) Content-type: text/plain; format=flowed; charset=utf-7; reply-type=response Content-transfer-encoding: 7BIT Hi Hannes, (If you are not able to see the picture in good shape, please look at the attachment.) financial settlement ...........................+- Application V ------- . signaling msg +---------------+- / QoS AAA +AFw- . +---------------+AD4AfA- +AHw- / protocol +AFw- . +AHw- +AHw- Authorizing +---------------+- +AFw- . +AHw- +AHw- Entity +AHw- +AHw- +AHw- +AHw- . +AHw- +- +AHwAPA---+-----+- +AHw- +AHw- . +AHw- +---------------+- +AHw-QoS +AHw- +AHw-QoS +AHw-. +AHw- install+AHw- +AHw-install +AHw- +AHw-rsp. +AHw- +AHw-req. +AHw-. +AHw- +AHw- +AHw- +AHw- +AHw-. +AHw- +AHw- +AHw- +AHw- . +AHw- . +AHw- +AFw- +AHw- +AHw- . / . +AHw- +AFw- +AHw- +AHw- / . V +AHw------V . . +--------------+- +---------+------+- . +AHw- Entity +AHw- +AHw- NE +AHw- . +AHw- requesting +AHw- +AHw- performing +AHw- . +AHw- resource +AHw-QoS rsrc granted +AHw- QoS +AHw- +ADw-....+- +AHw- +AHwAPA------------------+AHw- reservation +AHw- +--------------+- +---------------+- Figure 5: Authorization Scheme for Push Mode Push, Authorizing entity gets access info including access type in the P-Access-Network-Info header, and translates the P-Access-Network-Info header into QIR message. NE so knows which QoS control interface to select between Authorizing entity and NE. +---------------+- +AHw- Entity +AHw- +AHw- authorizing +AHw- +ADw-......+- +AHw- resource +AHw- . +AHw- request +AHw- . +-------------+--+- . --+AF4-----------+AHw--- . . ///// +AHw- +AHw- +AFwAXABcAFwAXA- . // +AHw- +AHw- +AFwAXA- . +AHw- QoS +AHw- QoS AAA +AHw- QoS +AHw-. +AHw- authz+AHw- protocol +AHw-authz +AHw-. +AHw- req.+AHw- +AHw- res. +AHw-. +AFwAXA- +AHw- +AHw- // . +AFwAXABcAFwAXA- +AHw- +AHw- ///// . QoS --+AHw-----------v-- . . +--------------+- request +--+-------------+- . +AHw- Entity +AHw------------------+AD4AfA- NE +AHw- . +AHw- requesting +AHw- +AHw- performing +AHw- . +AHw- resource +AHw-granted / rejected+AHw- QoS +AHw- +ADw-.....+- +AHw- +AHwAPA------------------+AHw- reservation +AHw- financial +--------------+- +---------------+- settlement Figure 3: Three Party Scheme Pull, Authorizing entity gets Origin-host in the QAR message, and translates the Origin-host into terminal mode or access type in QAA message. NE so knows which QoS control interface to select between Authorizing entity and NE. B. R. Tina ----- Original Message ----- From: +ACI-Hannes Tschofenig+ACI- +ADw-Hannes.Tschofenig+AEA-gmx.net+AD4- To: +ACI-Tina TSOU+ACI- +ADw-tena+AEA-huawei.com+AD4- Cc: +ADw-dime+AEA-ietf.org+AD4- Sent: Thursday, July 12, 2007 4:24 PM Subject: Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode +AD4- Hi Tina, +AD4- +AD4- thanks for the discussion. +AD4- +AD4- I believe that the concrete values in the Terminal-Mode AVP matter. When +AD4- you work on the document you need to list values and you need to setup a +AD4- registry (or refer to an existing registry). You also need to explain +AD4- where the values come from and what type of quality they have when they +AD4- are used as input to some decision making process. +AD4- +AD4- Christian suggested the usage of the P-Access- Network-Info AVP that is +AD4- added by a SIP proxy in the access network. +AD4- +AD4- Do you want to use P-Access- Network-Info? +AD4- Could you explain a bit more about the flow of information? Who is +AD4- supposed todo what and when? +AD4- +AD4- Ciao +AD4- Hannes +AD4- +AD4- Tina TSOU wrote: +AD4APgA+- ----- Original Message ----- From: +ACI-Hannes Tschofenig+ACI- +AD4APgA+- +ADw-Hannes.Tschofenig+AEA-gmx.net+AD4- +AD4APgA+- To: +ADw-dime+AEA-ietf.org+AD4AOw- +ACI-Tina TSOU+ACI- +ADw-tena+AEA-huawei.com+AD4- +AD4APgA+- Sent: Wednesday, July 11, 2007 6:46 PM +AD4APgA+- Subject: Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode +AD4APg- +AFs-snipped+AF0- +AD4APgA+AD4- What information would you put into the Terminal-Mode AVP? +AD4APg- +AFs-Tina: Just a mode value in Terminal-Mode AVP.+AF0- +AD4APg- +AD4APg- B. R. +AD4APg- Tina +AD4APg- +AD4APg- ----- Original Message ----- From: +ACI-Tina TSOU+ACI- +ADw-tena+AEA-huawei.com+AD4- +AD4APg- To: +ADw-dime+AEA-ietf.org+AD4AOw- +ACI-Hannes Tschofenig+ACI- +ADw-Hannes.Tschofenig+AEA-gmx.net+AD4- +AD4APg- Sent: Wednesday, July 11, 2007 7:31 PM +AD4APg- Subject: Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode +AD4APg- +AD4APg- +AD4APgA+- +AD4APgA+- ----- Original Message ----- From: +ACI-Hannes Tschofenig+ACI- +AD4APgA+- +ADw-Hannes.Tschofenig+AEA-gmx.net+AD4- +AD4APgA+- To: +ADw-dime+AEA-ietf.org+AD4AOw- +ACI-Tina TSOU+ACI- +ADw-tena+AEA-huawei.com+AD4- +AD4APgA+- Sent: Wednesday, July 11, 2007 6:46 PM +AD4APgA+- Subject: Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode +AD4APgA+- +AD4APgA+- +AD4APgA+AD4- Hi Tina, +AD4APgA+AD4- +AD4APgA+AD4- who translates high-level QoS information used at the application layer +AD4APgA+AD4- into information that is appropriate for a QoS model that is used in a +AD4APgA+AD4- particular access network. In your model it seems that the AF is in +AD4APgA+AD4- charge of assisting whereas the PDF does the final translation. In any +AD4APgA+AD4- case, it is not the NE that does it. +AD4APgA+AD4- +AD4APgA+AD4- Correct? +AD4APgA+- +AFs-Tina: this question belongs to another thread +ACI-PULL/PUSH/Access network +AD4APgA+- related information+ACI-.+AF0- +AD4APgA+AD4- +AD4APgA+AD4- But how should the AF know anything about the access network +AD4APgA+AD4- characteristics? +AD4APgA+AD4- (unless it is in the access network itself) +AD4APgA+- +AFs-Tina: this question belongs to another thread +ACI-PULL/PUSH/Access network +AD4APgA+- related information+ACI-.+AF0- +AD4APgA+AD4- What information would you put into the Terminal-Mode AVP? +AD4APgA+- +AFs-Tina: First, we can find which mode the terminal is by Terminal-mode, +AD4APgA+- for example +AD4APgA+- 3GPP, WiFi, Wimax, etc. +AD4APgA+- The user terminal may be multi-mode, and each mode may have different +AD4APgA+- QoS +AD4APgA+- profile, so the terminal-mode AVP can help to the operation on match QoS +AD4APgA+- request and QoS control.+AF0- +AD4APgA+AD4- +AD4APgA+AD4- Ciao +AD4APgA+AD4- Hannes +AD4APgA+AD4- +AD4APgA+AD4- Hannes Tschofenig wrote: +AD4APgA+AD4APg- FYI +AD4APgA+AD4APg- +AD4APgA+AD4APg- ------ +AD4APgA+AD4APg- +AD4APgA+AD4APg- This is without the attachment. +AD4APgA+AD4APg- +AD4APgA+AD4APg- B. R. +AD4APgA+AD4APg- Tina +AD4APgA+AD4APg- +AD4APgA+AD4APg- ----- Original Message ----- From: Tina TSOU To: dime+AEA-ietf.org +AD4APgA+AD4APg- Sent: Wednesday, July 11, 2007 6:26 PM +AD4APgA+AD4APg- Subject: Diameter QoS Appl.- terminal working mode +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- Hi Guys, +AD4APgA+AD4APg- To converge different kind of authorizing entities and performing +AD4APgA+AD4APg- NEs, terminal-Mode can tell the performing NE how to choose the +AD4APgA+AD4APg- interface working mode. First, we can find which mode the terminal is +AD4APgA+AD4APg- by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user +AD4APgA+AD4APg- terminal may be multi-mode, and each mode may have different QoS +AD4APgA+AD4APg- profile, so the terminal-mode AVP can help to the operation on match +AD4APgA+AD4APg- QoS request and QoS control. +AD4APgA+AD4APg- The following changes are proposed. (You can also find the changes in +AD4APgA+AD4APg- the attachment.) +AD4APgA+AD4APg- section 6.2 +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-section title+AD0AIg-QoS-Authorization Answer (QAA)+ACIAPg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4-The QoS-Authorization-Answer message (QAA), indicated by +AD4APgA+AD4APg- the +AD4APgA+AD4APg- +AD4APgA+AD4APg- Command- Code field set to TBD and 'R' bit cleared in the +AD4APgA+AD4APg- Command +AD4APgA+AD4APg- +AD4APgA+AD4APg- Flags field is sent in response to the +AD4APgA+AD4APg- QoS-Authorization-Request +AD4APgA+AD4APg- +AD4APgA+AD4APg- message (QAR). To converge different kind of authorizing +AD4APgA+AD4APg- entities +AD4APgA+AD4APg- and performing NEs, terminal-Mode can tell the performing NE +AD4APgA+AD4APg- how +AD4APgA+AD4APg- to choose the interface working mode. If the QoS +AD4APgA+AD4APg- authorization request +AD4APgA+AD4APg- +AD4APgA+AD4APg- is successfully authorized, the response will include the +AD4APgA+AD4APg- AVPs to +AD4APgA+AD4APg- allow authorization of the QoS resources as well as +AD4APgA+AD4APg- accounting and +AD4APgA+AD4APg- transport plane gating information.+ADw-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4-The message format is defined as follows:+ADw-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4APA-figure+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-artwork+AD4APAAhAFs-CDATA+AFs- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-QoS-Answer+AD4- ::+AD0- +ADw- Diameter Header: XXX, PXY +AD4- +ADw- +AD4APgA+AD4APg- Session-Id +AD4- +AHs- Auth-Application-Id +AH0- +AD4APgA+AD4APg- +AHs- Auth-Request-Type +AH0- +AHs- Result-Code +AH0- +AHs- +AD4APgA+AD4APg- Origin-Host +AH0- +AHs- Origin-Realm +AH0- +AD4APgA+AD4APg- +AFs- Terminal-Mode +AF0- +ACo- +AFs- QoS-Resources +AF0- +AFs- +AD4APgA+AD4APg- CC-Time +AF0- +AFs- Acc-Multisession-Id +AF0- +AD4APgA+AD4APg- +AFs- Session-Timeout +AF0- +AFs- +AD4APgA+AD4APg- Authz-Session-Lifetime +AF0- +AFs- Authz-Grace-Period +AF0- +AD4APgA+AD4APg- +ACo- +AFs- AVP +AF0- +AF0AXQA+ADw-/artwork+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-/figure+AD4APA-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-/section+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- section 6.3 +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-section title+AD0AIg-QoS-Install Request (QIR)+ACIAPg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4-The QoS-Install Request message (QIR), indicated by the +AD4APgA+AD4APg- +AD4APgA+AD4APg- Command-Code field set to TDB and 'R' bit set in the Command +AD4APgA+AD4APg- Flags +AD4APgA+AD4APg- +AD4APgA+AD4APg- field is used by Authorizing entity to install or update the +AD4APgA+AD4APg- QoS +AD4APgA+AD4APg- +AD4APgA+AD4APg- parameters and the flow state of an authorized flow at the +AD4APgA+AD4APg- transport +AD4APgA+AD4APg- +AD4APgA+AD4APg- plane element.+ADw-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4-The message MUST carry information for signaling session +AD4APgA+AD4APg- +AD4APgA+AD4APg- identification or identification of the flow to which the +AD4APgA+AD4APg- provided QoS +AD4APgA+AD4APg- +AD4APgA+AD4APg- rules apply, working mode of the terminal, identity of the +AD4APgA+AD4APg- transport +AD4APgA+AD4APg- plane element, description of provided QoS parameters, flow +AD4APgA+AD4APg- state and +AD4APgA+AD4APg- duration of the provided authorization.+ADw-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4-The message format is defined as follows:+ADw-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4APA-figure+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-artwork+AD4APAAhAFs-CDATA+AFs- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-QoS-Install-Request+AD4- ::+AD0- +ADw- Diameter Header: XXX, REQ, PXY +AD4- +ADw- +AD4APgA+AD4APg- Session-Id +AD4- +AHs- Auth-Application-Id +AH0- +AHs- +AD4APgA+AD4APg- Origin-Host +AH0- +AHs- Origin-Realm +AH0- +AD4APgA+AD4APg- +AFs- Terminal-Mode +AF0- +AD4APgA+AD4APg- +AHs- Destination-Realm +AH0- +AD4APgA+AD4APg- +AHs- Auth-Request-Type +AH0- +AFs- Destination-Host +AF0- +ACo- +AFs- +AD4APgA+AD4APg- QoS-Resources +AF0- +AFs- Session-Timeout +AF0- +AFs- +AD4APgA+AD4APg- Authz-Session-Lifetime +AF0- +AFs- Authz-Grace-Period +AF0- +AFs- +AD4APgA+AD4APg- Authz-Session-Volume +AF0- +ACo- +AFs- +AF0AXQA+ADw-/artwork+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-/figure+AD4APA-/t+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-/section+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AFs-snipped+AF0- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- section 7.1 +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-t+AD4APA-figure+AD4- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +ADw-artwork+AD4APAAhAFs-CDATA+AFs- +AD4APgA+AD4APg- +AD4APgA+AD4APg- Attribute Name AVP Code Reference +AFs-RFC3588+AF0- +AD4APgA+AD4APg- +AD4APgA+AD4APg- Origin-Host 264 Section 6.3 +AD4APgA+AD4APg- +AD4APgA+AD4APg- Origin-Realm 296 Section 6.4 +AD4APgA+AD4APg- +AD4APgA+AD4APg- Terminal-Mode TBD +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- B. R. +AD4APgA+AD4APg- +AD4APgA+AD4APg- Tina +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AD4APgA+AD4APg- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4APgA+AD4APg- DiME mailing list +AD4APgA+AD4APg- DiME+AEA-ietf.org +AD4APgA+AD4APg- https://www1.ietf.org/mailman/listinfo/dime +AD4APgA+AD4- +AD4APgA+- +AD4APgA+- +AD4APgA+- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4APgA+- DiME mailing list +AD4APgA+- DiME+AEA-ietf.org +AD4APgA+- https://www1.ietf.org/mailman/listinfo/dime +AD4- --Boundary_(ID_/Mqvl2OCacbndpIHMJ13iA) Content-type: text/plain; format=flowed; name="terminal working mode.txt"; reply-type=response Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="terminal working mode.txt" financial settlement ...........................+ Application V ------- . signaling msg +--------------+ / QoS AAA \ . +-------------->| | / protocol \ . | | Authorizing +--------------+ \ . | | Entity | | | | . | + |<--+----+ | | . | +--------------+ |QoS | |QoS |. | install| |install | |rsp. | |req. |. | | | | |. | | | | . | . | \ | | . / . | \ | | / . V |-----V . . +-------------+ +--------+-----+ . | Entity | | NE | . | requesting | | performing | . | resource |QoS rsrc granted | QoS | <....+ | |<-----------------| reservation | +-------------+ +--------------+ Figure 5: Authorization Scheme for Push Mode Push, Authorizing entity gets access info including access type in the P-Access-Network-Info header, and translates the P-Access-Network-Info header into QIR message. NE so knows which QoS control interface to select between Authorizing entity and NE. +--------------+ | Entity | | authorizing | <......+ | resource | . | request | . +------------+-+ . --^----------|-- . . ///// | | \\\\\ . // | | \\ . | QoS | QoS AAA | QoS |. | authz| protocol |authz |. | req.| | res. |. \\ | | // . \\\\\ | | ///// . QoS --|----------v-- . . +-------------+ request +-+------------+ . | Entity |----------------->| NE | . | requesting | | performing | . | resource |granted / rejected| QoS | <.....+ | |<-----------------| reservation | financial +-------------+ +--------------+ settlement Figure 3: Three Party Scheme Pull, Authorizing entity gets Origin-host in the QAR message, and translates the Origin-host into terminal mode or access type in QAA message. NE so knows which QoS control interface to select between Authorizing entity and NE. --Boundary_(ID_/Mqvl2OCacbndpIHMJ13iA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_/Mqvl2OCacbndpIHMJ13iA)-- From dime-bounces@ietf.org Fri Jul 13 06:07:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9I3N-0007j2-QY; Fri, 13 Jul 2007 06:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9I3L-0007im-Rm for dime@ietf.org; Fri, 13 Jul 2007 06:07:11 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9I3G-0001Mi-Ts for dime@ietf.org; Fri, 13 Jul 2007 06:07:11 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL400DFF42B8X@szxga02-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 18:06:12 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL400FYX42BT9@szxga02-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 18:06:11 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL400MHN42AAE@szxml03-in.huawei.com> for dime@ietf.org; Fri, 13 Jul 2007 18:06:11 +0800 (CST) Date: Fri, 13 Jul 2007 18:06:10 +0800 From: Tina TSOU Subject: Re: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network related information" To: Tom Taylor , Hannes Tschofenig Message-id: <010d01c7c535$703fdac0$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696744D.30005@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dime@ietf.org, McCann Peter-A001034 , Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org See comment with [Tina: ...] in line. Ciao Tina ----- Original Message ----- From: "Hannes Tschofenig" To: "Tom Taylor" Cc: ; "McCann Peter-A001034" ; "Christian Esteve" Sent: Friday, July 13, 2007 2:34 AM Subject: Re: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network relatedinformation" > Hi Tom, > > Tom Taylor wrote: >> I think you have a few premises mixed up. See comments marked with [PTT]. >> >> McCann Peter-A001034 wrote: >>> I don't think we should be designing a protocol that >>> behaves differently depending on the type of access >>> link. Everything in the Diameter cloud should be >>> dealing exclusively with link-neutral QoS specifications, >>> which will enable inter-domain operation and simplify >>> settlement. >> >> [PTT] Push/pull is a question of terminal technology, not link >> technology. >> > That's probably only a terminology problem. > > Still, there is the question which entity needs to understand the QoS > model of the specific node being configured. > There are essentially three possibilities: > * AF > * PDF > * NE [Tina: AF needs to understand the QoS model of the specific node being configured. In 3GPP which supports pull mode only, AF may identify the QoS model based on the access network type. While in TISPAN and ITU-T which both support pull mode and push mode, the QoS model should be understood by AF which is configured in AF.] > >>> >>> Solutions that assume some SIP signaling from the endpoint >>> to identify / classify the first-hop NE are limited. The >>> QoS enforcement point may not be the first hop; in general >>> any NE along the path between the two hosts involved in >>> the call might need to play this role. I think the push >>> model has some serious problems with discovering this type of NE. The >>> right solution is to require end-to-end, >>> path-coupled signaling like NSIS with the pull mode of >>> operation. >> [PTT] Which NE is it that you are worried about discovering? And in the >> ITU-T architecture at least, provision is being made for discovery at the >> RACF level. All the AF needs is the right entry point, and it can be >> configured with that. >> > In a push model, in the end the AF needs to contact a specific PDF > related to the access network or a NE directly. > Pete calls this discovery and I agree that this is a valid term in this > context. Consider an arbitrary AF, like a streaming server installed on my > webserver. Then, you click on it -- how would it know where to push QoS > policies to? > > I know that with the assumptions being made in some architectures, for > example with the 3GPP IMS, this discovery step is obviously a lot easier > since the application server is > a) either in the access network (e.g., the P-CSCF), or > b) associated with the operator of the access network using some business > relationship [Tina: In the non-IMS scenario, there may be a service manager which corresponds to the PDF in the IMS. The scenario with PDF is based on the session, but the non-IMS scenario as you cited is based on the service. The service QoS profile will be pushed to the service manager. ] > >>> -Pete >>> > > Ciao > Hannes > >> ... >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 11:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NSS-0002e2-Vs; Fri, 13 Jul 2007 11:53:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NSR-0002ds-UH for dime@ietf.org; Fri, 13 Jul 2007 11:53:27 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9NSC-0006lj-IE for dime@ietf.org; Fri, 13 Jul 2007 11:53:27 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1184341959!2851429!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17463 invoked from network); 13 Jul 2007 15:52:39 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-153.messagelabs.com with SMTP; 13 Jul 2007 15:52:39 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l6DFqY1S005747 for ; Fri, 13 Jul 2007 08:52:38 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6DFqX1Z019631 for ; Fri, 13 Jul 2007 10:52:34 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Date: Fri, 13 Jul 2007 11:52:32 -0400 Message-ID: In-Reply-To: <4696ADC0.2080201@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Thread-Index: AcfE1U61GyQG7jCQSMSI5k3qlkbKeQAj6B9Q References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696ADC0.2080201@rogers.com> From: "McCann Peter-A001034" To: "Tom Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org, Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tom, Tom Taylor wrote: > See at end. >=20 > McCann Peter-A001034 wrote: >> Tom Taylor wrote: >> In general any router along the path might need to reserve resources >> for a given flow, and to request authorization from the Diameter >> cloud. I don't think we should limit ourselves to an architecture >> that only supports discovery of the first hop (or something near the >> first hop) as part of a Diameter application intended to support the >> Internet architecture.=20 >>=20 > [PTT] Thinking about this a bit more, I guess the choice (making the > assumption that the Diameter protocol is used) is between a network > of Diameter servers (not a "Diameter cloud") in the RACF layer, > versus a network of routers using NSIS between them with vertical > relationships to local PDFs. =20 I think I agree with this assessment - but I don't quite know what you have in mind when you say "network of Diameter servers". Do you mean a set of path-coupled entities through which the signaling must pass? I think the "Diameter cloud" should be constructed based on business agreements between operators, possibly with the help of brokers that make the relationships scalable. A given NE should be able to contact its local Diameter server with a request for authentication/authorization, and there should be enough information in the request to route to the user's "home" realm, according to standard Diameter routing using the Destination-Realm AVP. The path taken by the Diameter routing will not necessarily be along the same path as the NSIS signaling. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 13:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9P6s-0005T7-HX; Fri, 13 Jul 2007 13:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9P6q-0005Nw-Su for dime@ietf.org; Fri, 13 Jul 2007 13:39:17 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9P6m-0008Vc-JA for dime@ietf.org; Fri, 13 Jul 2007 13:39:16 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1184348348!29959764!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9811 invoked from network); 13 Jul 2007 17:39:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 13 Jul 2007 17:39:09 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6DHd8x7010809 for ; Fri, 13 Jul 2007 10:39:08 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l6DHd6qc014796 for ; Fri, 13 Jul 2007 12:39:07 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l6DHd5S9014783 for ; Fri, 13 Jul 2007 12:39:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Date: Fri, 13 Jul 2007 13:39:04 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D5209AF@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfEoLYHKETnaTx1QACewa7FNukoBwAAFqUQAA12b1AAI76KAA== References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com> <09C9068466B79E4C938DC7737562404D5209AF@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , "Tom Taylor" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Christian Esteve , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Sun, Dong (Dong) wrote: > See my comment as [DS] > In general any router along the path might need to reserve resources > for a given flow, and to request authorization from the Diameter > cloud. =20 > I don't think we should limit ourselves to an architecture that only > supports discovery of the first hop (or something near the first hop) > as part of a Diameter application intended to support the Internet > architecture. =20 >=20 >>> -Pete > [snip] > [DS] not sure whether any router along the path has to reserve > resources on per micro-flow level in reality (don't want to repeat > the scalability and cost issues of per flow IntServ model). I can see > the need for certain resource scarce bottleneck links e.g. air > interface, but don't perceive the necessity in the high capacity > aggregation network segment. =20 It all depends on how much traffic you are trying to put through a given aggregation link; I can imagine deployments where these resources are scarce enough to warrant per-flow reservation. We will likely be dealing with thousands of RTP connections that won't do end-to-end congestion control as TCP does for us today. I think anywhere there is a bottleneck, the need for reservation is there. Even a high-speed router might want to charge for=20 resources on a per-call basis. =20 > In other words, the NE for per flow policy enforcement would be taken > in certain anchor points or overlay nodes typically, which may result > in the discovery requirement in the Push model.=20 Even if the core network doesn't accept per-flow reservations, I can imagine that an NE just a few hops away from the access link might. In this case the requester (end host) doesn't have=20 any helpful information to put in the P-header. > (Otherwise, why the > policy server needs to discover the right spot if every NE would > perform the enforcement). =20 In general, the NEs along the path would be from different administrative domains. Each domain might want to perform authentication/authorization of the request, and accounting so they can get paid. > However, I don't think the path-coupled signaling is the best > solution for all kind of scenarios.(hope no need to harp on the > reasoning :-). =20 Some sort of path-coupled signaling will be necessary to support the general model. In some people's minds, this might be a network of SIP proxies, each one tied to the domain through which the RTP traffic will flow. Personally, I find this approach limits flexibility because you can't use something other than SIP to establish the session. > Just like to point out one truth, even the path-coupled signaling is > used with pull model, the NE still needs to identify the right server > for authorization, sort of discovery.=20 Yes, and it can do this if the end host puts its own home realm into the path-coupled signaline. > Although the discovery for Push > mode is a bit complex, but don't think it would be more difficult > compared to mandate every terminal support the intelligence of > full-blown Qos and path coupled signaling, from e2e perspective. =20 If we want to support an open architecture then there needs to be a universal layer-3 path coupled signaling that can be used with any application (not just SIP). -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 13:54:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PLo-0000B3-E3; Fri, 13 Jul 2007 13:54:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PLm-0000Ai-IF for dime@ietf.org; Fri, 13 Jul 2007 13:54:42 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9PLg-0002kN-7L for dime@ietf.org; Fri, 13 Jul 2007 13:54:42 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1184349218!3270679!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 11597 invoked from network); 13 Jul 2007 17:53:38 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-2.tower-153.messagelabs.com with SMTP; 13 Jul 2007 17:53:38 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l6DHrclw020517 for ; Fri, 13 Jul 2007 10:53:38 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l6DHrbPv000132 for ; Fri, 13 Jul 2007 12:53:37 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6DHrZ1O000122 for ; Fri, 13 Jul 2007 12:53:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network related information" Date: Fri, 13 Jul 2007 13:53:34 -0400 Message-ID: In-Reply-To: <010d01c7c535$703fdac0$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network related information" Thread-Index: AcfFNXbx4sPRnRtEQ+KopZ3YoaXsjwAQD5JA References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696744D.30005@gmx.net> <010d01c7c535$703fdac0$864c460a@china.huawei.com> From: "McCann Peter-A001034" To: "Tina TSOU" , "Tom Taylor" , "Hannes Tschofenig" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dime@ietf.org, Christian Esteve X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tina, See inline. Tina TSOU wrote: > See comment with [Tina: ...] in line. >=20 > Ciao > Tina > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Tom Taylor" > Cc: ; "McCann Peter-A001034" > ; "Christian Esteve" =20 > Sent: Friday, July 13, 2007 2:34 AM > Subject: Re: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network > relatedinformation"=20 >=20 >> That's probably only a terminology problem. >>=20 >> Still, there is the question which entity needs to understand the QoS >> model of the specific node being configured. >> There are essentially three possibilities: >> * AF >> * PDF >> * NE > [Tina: AF needs to understand the QoS model of the specific node > being configured.=20 > In 3GPP which supports pull mode only, AF may identify the QoS model > based on the access network type. While in TISPAN and ITU-T which > both support pull mode and push mode, the QoS model should be > understood by AF which is configured in AF.] =20 When you say "QoS model" do you mean the style of operations (Push vs. Pull) or the allowed QoS attributes that might be=20 defined in a user profile? If the latter, I think that the QoS profile understood by the AF should be a link-agnostic one, so that the application can run over any link technology. >> In a push model, in the end the AF needs to contact a specific PDF >> related to the access network or a NE directly. >> Pete calls this discovery and I agree that this is a valid term in >> this context. Consider an arbitrary AF, like a streaming server >> installed on my webserver. Then, you click on it -- how would it >> know where to push QoS policies to?=20 >>=20 >> I know that with the assumptions being made in some architectures, >> for example with the 3GPP IMS, this discovery step is obviously a >> lot easier since the application server is >> a) either in the access network (e.g., the P-CSCF), or >> b) associated with the operator of the access network using some >> business relationship > [Tina: In the non-IMS scenario, there may be a service manager which > corresponds to the PDF in the IMS. The scenario with PDF is based on > the=20 > session, but the non-IMS scenario as you cited is based on the > service. The=20 > service QoS profile will be pushed to the service manager. ] How would the sender of the QoS profile know where to find the service manager? How would it fill in the Destination-Host and Destination-Realm fields of the push message? -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 14:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PXo-0000vJ-SG; Fri, 13 Jul 2007 14:07:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PXn-0000v8-Ef for dime@ietf.org; Fri, 13 Jul 2007 14:07:07 -0400 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9PXj-0001Aa-2Y for dime@ietf.org; Fri, 13 Jul 2007 14:07:07 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l6DI71Jq067942 for ; Fri, 13 Jul 2007 18:07:01 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6DI71Aj3010656 for ; Fri, 13 Jul 2007 19:07:01 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6DI6sdD023694 for ; Fri, 13 Jul 2007 19:06:55 +0100 Received: from d06ml067.portsmouth.uk.ibm.com (d06ml067.portsmouth.uk.ibm.com [9.149.38.140]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6DI6s4Z023562 for ; Fri, 13 Jul 2007 19:06:54 +0100 From: Matteo Candaten To: dime@ietf.org Message-ID: Date: Fri, 13 Jul 2007 19:06:39 +0100 X-MIMETrack: Serialize by Router on D06ML067/06/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 13/07/2007 19:06:53 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Dime] Matteo Candaten is out of the office. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I will be out of the office starting 13/07/2007 and will not return until 23/07/2007. I will respond to your message when I return. For any urgent issues, please contact Andrew Morgan. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 16:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Rtx-0005lx-Uk; Fri, 13 Jul 2007 16:38:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Rtv-0005lW-SZ for dime@ietf.org; Fri, 13 Jul 2007 16:38:07 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Rtr-0006fj-Hu for dime@ietf.org; Fri, 13 Jul 2007 16:38:07 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6DKbEFQ008837; Fri, 13 Jul 2007 16:37:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network relatedinformation" Date: Fri, 13 Jul 2007 16:37:14 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188065@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfFNXbx4sPRnRtEQ+KopZ3YoaXsjwAQD5JAAAB+SwA= References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com> <4696744D.30005@gmx.net><010d01c7c535$703fdac0$864c460a@china.huawei.com> From: "Asveren, Tolga" To: "McCann Peter-A001034" , "Tina TSOU" , "Tom Taylor" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Christian Esteve , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Pete, > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Friday, July 13, 2007 1:54 PM > To: Tina TSOU; Tom Taylor; Hannes Tschofenig > Cc: dime@ietf.org; Christian Esteve > Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network > relatedinformation" >=20 > Hi, Tina, >=20 > See inline. >=20 > Tina TSOU wrote: > > See comment with [Tina: ...] in line. > > > > Ciao > > Tina > > ----- Original Message ----- > > From: "Hannes Tschofenig" > > To: "Tom Taylor" > > Cc: ; "McCann Peter-A001034" > > ; "Christian Esteve" > > Sent: Friday, July 13, 2007 2:34 AM > > Subject: Re: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network > > relatedinformation" > > > >> That's probably only a terminology problem. > >> > >> Still, there is the question which entity needs to understand the QoS > >> model of the specific node being configured. > >> There are essentially three possibilities: > >> * AF > >> * PDF > >> * NE > > [Tina: AF needs to understand the QoS model of the specific node > > being configured. > > In 3GPP which supports pull mode only, AF may identify the QoS model > > based on the access network type. While in TISPAN and ITU-T which > > both support pull mode and push mode, the QoS model should be > > understood by AF which is configured in AF.] >=20 > When you say "QoS model" do you mean the style of operations > (Push vs. Pull) or the allowed QoS attributes that might be > defined in a user profile? If the latter, I think that the > QoS profile understood by the AF should be a link-agnostic > one, so that the application can run over any link technology. [TOLGA] I also think that the mechanism should be link-agnostic, or better said should be agnostic about details of lower layers (if I recall correctly, there was a desire to use QoS application possibly for layer2 reservations as well, but nonetheless for an IP network, I agree that AF shouldn't know details about layer2) >=20 > >> In a push model, in the end the AF needs to contact a specific PDF > >> related to the access network or a NE directly. > >> Pete calls this discovery and I agree that this is a valid term in > >> this context. Consider an arbitrary AF, like a streaming server > >> installed on my webserver. Then, you click on it -- how would it > >> know where to push QoS policies to? > >> > >> I know that with the assumptions being made in some architectures, > >> for example with the 3GPP IMS, this discovery step is obviously a > >> lot easier since the application server is > >> a) either in the access network (e.g., the P-CSCF), or > >> b) associated with the operator of the access network using some > >> business relationship > > [Tina: In the non-IMS scenario, there may be a service manager which > > corresponds to the PDF in the IMS. The scenario with PDF is based on > > the > > session, but the non-IMS scenario as you cited is based on the > > service. The > > service QoS profile will be pushed to the service manager. ] >=20 > How would the sender of the QoS profile know where to find the > service manager? How would it fill in the Destination-Host and > Destination-Realm fields of the push message? [TOLGA]This probably would require an initial lookup by the AF to figure out at least the Destination-Realm based on the IP address of the user (or alternatively based on Subscriber-Id if the service and access providers are the same organization). Another approach could be for AF to initiate the session always with a preconfigured Destination-Realm, where the server terminates the Diameter session, performs a query to find the actual Destination-Realm, and initiate a corresponding session. IMHO, how AF(or some other entity) performs this lookup is out of scope of Diameter QoS application (but an important part of the of the overall solution though). I think pull mode wouldn't require a query to discover the Destination-Realm. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 16:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S7c-0004Tq-GX; Fri, 13 Jul 2007 16:52:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S7a-0004Qk-Np for dime@ietf.org; Fri, 13 Jul 2007 16:52:14 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9S7L-0000PP-CG for dime@ietf.org; Fri, 13 Jul 2007 16:52:14 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1184359862!6049404!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 12857 invoked from network); 13 Jul 2007 20:51:02 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-128.messagelabs.com with SMTP; 13 Jul 2007 20:51:02 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l6DKoxPg018056 for ; Fri, 13 Jul 2007 13:51:01 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l6DKowcO013083 for ; Fri, 13 Jul 2007 15:50:58 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l6DKouEc013075 for ; Fri, 13 Jul 2007 15:50:57 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network relatedinformation" Date: Fri, 13 Jul 2007 16:50:55 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188065@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfFNXbx4sPRnRtEQ+KopZ3YoaXsjwAQD5JAAAB+SwAABZKA4A== References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com> <4696744D.30005@gmx.net><010d01c7c535$703fdac0$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E7188065@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , "Tina TSOU" , "Tom Taylor" , "Hannes Tschofenig" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Christian Esteve , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tolga, Asveren, Tolga wrote: [...deleting part where we agree...] >>> [Tina: In the non-IMS scenario, there may be a service manager which >>> corresponds to the PDF in the IMS. The scenario with PDF is based on >>> the session, but the non-IMS scenario as you cited is based on the >>> service. The service QoS profile will be pushed to the service >>> manager. ] >>=20 >> How would the sender of the QoS profile know where to find the >> service manager? How would it fill in the Destination-Host and >> Destination-Realm fields of the push message? > > [TOLGA]This probably would require an initial lookup by the AF to > figure out at least the Destination-Realm based on the IP address of > the user (or alternatively based on Subscriber-Id if the service and > access providers are the same organization).=20 This sounds unscalable, especially if we take roaming users into account. Who maintains this database? How is it updated? For roaming users, the access and service providers will not be the same. > Another approach could > be for AF to initiate the session always with a preconfigured > Destination-Realm, where the server terminates the Diameter session, > performs a query to find the actual Destination-Realm, and initiate a > corresponding session.=20 It sounds like we are just pushing the problem to another node in the network. > IMHO, how AF(or some other entity) performs > this lookup is out of scope of Diameter QoS application (but an > important part of the of the overall solution though).=20 I think it's important that this be specified somewhere, so that we can have an end-to-end solution that actually works. If nothing else, we should put big disclaimers around the push mode to say that it only works when AE and NE are in the same domain. If it turns out to be impractical or impossible to implement discovery for inter-domain push mode, we should consider taking push mode out of the document. > I think pull > mode wouldn't require a query to discover the Destination-Realm. =20 Right, I think we can augment path-coupled signaling with a realm name to give the NE the information it needs to find the home server. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 17:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Sq4-0000WQ-FF; Fri, 13 Jul 2007 17:38:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Sq3-0000WF-Ep for dime@ietf.org; Fri, 13 Jul 2007 17:38:11 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Sq2-0001ss-RK for dime@ietf.org; Fri, 13 Jul 2007 17:38:11 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6DLaHQM020795 for ; Fri, 13 Jul 2007 16:36:17 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 16:36:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access networkrelatedinformation" Date: Fri, 13 Jul 2007 16:36:17 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209B9@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access networkrelatedinformation" Thread-Index: AcfFNXbx4sPRnRtEQ+KopZ3YoaXsjwAQD5JAAAB+SwAABZKA4AABCqSg References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com><4696744D.30005@gmx.net><010d01c7c535$703fdac0$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E7188065@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 13 Jul 2007 21:36:17.0620 (UTC) FILETIME=[D87CB940:01C7C595] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Pete, It seems two issues are mixed up here: the interaction between Application server (e.g. AF) and policy server (i.e. authorizing entity (AE), and the interaction between the entities (e.g. between two AE instances in different domains or between AE and NE).=20 Based on your previous comment, this application doesn't intend to cover the interface/interaction between AS and AE. However, in the attached email, you made some comments on the push model based on the discussion for the interaction between AS and AE, which is totally irrelevant to the scope of this spec. In fact, the push model defined in this application concentrates on the interaction between entities within this application (e.g. AE->AE and AE->NE). Hope this clarify the scope of work. Moreover, if look at some real implementation e.g. 3GPP, the model they're using can be viewed as sort of pull model according to the definition in this QoS application. as a matter of fact, it still requires the "Push" approach from AF to PDF for service based policy authorization. This is sth exactly Tolga described. This approach is also used by the whole world, including TISPAN, WiMAX, Cablelabs, ITU (in the NGN defined by TISPAN and ITU, the AF and PDF can be in different provider domain as a mandatory requirement)... It is one of cornerstone in NGN and makes the network neutrality realistic. I don't think we can make any disclaimer to limit the usage of this mechanism. In addition, I don't understand why AF can not discover the right anchor point of PDF based on the realm info (for instance, some anchor PDF can be preprovisoned between application service provider and network provider according to SLA and business agreement). It is essentially the same as the one you are advocating for NE based approach. Regards, Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Friday, July 13, 2007 4:51 PM To: Asveren, Tolga; Tina TSOU; Tom Taylor; Hannes Tschofenig Cc: Christian Esteve; dime@ietf.org Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access networkrelatedinformation" Hi, Tolga, Asveren, Tolga wrote: [...deleting part where we agree...] >>> [Tina: In the non-IMS scenario, there may be a service manager which >>> corresponds to the PDF in the IMS. The scenario with PDF is based on >>> the session, but the non-IMS scenario as you cited is based on the=20 >>> service. The service QoS profile will be pushed to the service=20 >>> manager. ] >>=20 >> How would the sender of the QoS profile know where to find the=20 >> service manager? How would it fill in the Destination-Host and=20 >> Destination-Realm fields of the push message? > > [TOLGA]This probably would require an initial lookup by the AF to=20 > figure out at least the Destination-Realm based on the IP address of=20 > the user (or alternatively based on Subscriber-Id if the service and=20 > access providers are the same organization). This sounds unscalable, especially if we take roaming users into account. Who maintains this database? How is it updated? For roaming users, the access and service providers will not be the same. > Another approach could > be for AF to initiate the session always with a preconfigured=20 > Destination-Realm, where the server terminates the Diameter session,=20 > performs a query to find the actual Destination-Realm, and initiate a=20 > corresponding session. It sounds like we are just pushing the problem to another node in the network. > IMHO, how AF(or some other entity) performs this lookup is out of=20 > scope of Diameter QoS application (but an important part of the of the > overall solution though). I think it's important that this be specified somewhere, so that we can have an end-to-end solution that actually works. If nothing else, we should put big disclaimers around the push mode to say that it only works when AE and NE are in the same domain. If it turns out to be impractical or impossible to implement discovery for inter-domain push mode, we should consider taking push mode out of the document. > I think pull > mode wouldn't require a query to discover the Destination-Realm. =20 Right, I think we can augment path-coupled signaling with a realm name to give the NE the information it needs to find the home server. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 18:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TUL-0005mM-13; Fri, 13 Jul 2007 18:19:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TUI-0005gO-Ap for dime@ietf.org; Fri, 13 Jul 2007 18:19:46 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9TUH-00035m-HH for dime@ietf.org; Fri, 13 Jul 2007 18:19:46 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6DMHg1I020299; Fri, 13 Jul 2007 17:17:42 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 17:17:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Date: Fri, 13 Jul 2007 17:17:42 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209BA@ILEXC2U01.ndc.lucent.com> In-Reply-To: <00ba01c7c533$66d9eb30$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Thread-Index: AcfFNErXbnvWXZTuSzis/W8trTbhlgAY2gPg References: +ADw-4694B447.8080800+AEA-gmx.net+AD4-+ADw-4694B4F0.5060804+AEA-gmx.net+AD4-+ADw-032001c7c3af+ACQ-07676c20+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-00d401c7c431+ACQ-e5bf9c90+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-4695E525.1010800+AEA-gmx.net+AD4- <00ba01c7c533$66d9eb30$864c460a@china.huawei.com> From: "Sun, Dong \(Dong\)" To: "Tina TSOU" , "Hannes Tschofenig" X-OriginalArrivalTime: 13 Jul 2007 22:17:43.0391 (UTC) FILETIME=[A21F46F0:01C7C59B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, Thanks for drawing those beautiful pictures. Looks like you would be better to be a artist instead of engineer :-). To be honest, I am a bit confused by the intent of this terminal working mode. Would it be used for: - Indication of push or pull mode operated by AE - Indication of policy profile used by AE - or both I support to have a indicator to tell AE which operation model - Push or Pull should be used, which can be determined by AS (e.g. IMS AF), or just simply pre-provisoned. However, I am not yet convinced why the different policy profile should be used according to access technologies. A good example would be helpful. One example in my mind is that we may need access network type for correlating charging related data. However, I don't think this spec should make the charging function as mandatory requirement and it should be defined separately, such as in 4006. Another example, it would be used for resource based admission control, but obviously, the terminal working mode is not sufficient to serve that purpose. I can see the need to have a parameter to indicate the Push or Pull mode, which will be sent from AF to PDF or between two AE instances for inter-domain case, not from AE to NE within the same domain. (BTW, the current architecture does not perfectly reflect the inter-domain and intra-domain cases. I don't think the NE as enforcement point can be controlled by an AE in another administrative domain in reality. We should add a local AE and remote AE to justify the business model commonly used in the real network. See additional comment inline... Regards, Dong -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Friday, July 13, 2007 5:52 AM To: Hannes Tschofenig Cc: dime@ietf.org Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Hi Hannes, (If you are not able to see the picture in good shape, please look at the attachment.) financial settlement ...........................+ Application V ------- . signaling msg +--------------+ / QoS AAA \ . +-------------->| | / protocol \ . | | Authorizing +--------------+ \ . | | Entity | | | | . | + |<--+----+ | | . | +--------------+ |QoS | |QoS |. | install| |install | |rsp. | |req. |. | | | | |. | | | | . | . | \ | | . / . | \ | | / . V |-----V . . +-------------+ +--------+-----+ . | Entity | | NE | . | requesting | | performing | . | resource |QoS rsrc granted | QoS | <....+ | |<-----------------| reservation | +-------------+ +--------------+ Figure 5: Authorization Scheme for Push Mode Push, Authorizing entity gets access info including access type in the P-Access-Network-Info header, and translates the P-Access-Network-Info header into QIR message. NE so knows which QoS control interface to select between Authorizing entity and NE. [DS] Why NE as policy enforcement point needs to know it is a push or pull mode, the push or pull is the matter of AE (policy server)'s operation. I think, we can specify the state machine properly to indicate the push or pull in NE, for instance, When NE receives QIR for new session establishment, it goes to Push mode; when the NE receives the path coupled signaling from end host, it goes to Pull mode and trigger the QAR to AE. I can draw some detailed state mechanism later. +--------------+ | Entity | | authorizing | <......+ | resource | . | request | . +------------+-+ . --^----------|-- . . ///// | | \\\\\ . // | | \\ . | QoS | QoS AAA | QoS |. | authz| protocol |authz |. | req.| | res. |. \\ | | // . \\\\\ | | ///// . QoS --|----------v-- . . +-------------+ request +-+------------+ . | Entity |----------------->| NE | . | requesting | | performing | . | resource |granted / rejected| QoS | <.....+ | |<-----------------| reservation | financial +-------------+ +--------------+ settlement Figure 3: Three Party Scheme Pull, Authorizing entity gets Origin-host in the QAR message, and translates the Origin-host into terminal mode or access type in QAA message. NE so knows which QoS control interface to select between Authorizing entity and NE. [DS] when NE receives the path coupled signaling from end host, it implied a Pull mode by default. Is there any need to send back any thing from AE to NE in QAA? B. R. Tina ----- Original Message ----- From: "Hannes Tschofenig" To: "Tina TSOU" Cc: Sent: Thursday, July 12, 2007 4:24 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > Hi Tina, > > thanks for the discussion. > > I believe that the concrete values in the Terminal-Mode AVP matter. When=20 > you work on the document you need to list values and you need to setup a=20 > registry (or refer to an existing registry). You also need to explain=20 > where the values come from and what type of quality they have when they=20 > are used as input to some decision making process. > > Christian suggested the usage of the P-Access- Network-Info AVP that is=20 > added by a SIP proxy in the access network. > > Do you want to use P-Access- Network-Info? > Could you explain a bit more about the flow of information? Who is=20 > supposed todo what and when? > > Ciao > Hannes > > Tina TSOU wrote: >>> ----- Original Message ----- From: "Hannes Tschofenig"=20 >>> >>> To: ; "Tina TSOU" >>> Sent: Wednesday, July 11, 2007 6:46 PM >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >> [snipped] >>>> What information would you put into the Terminal-Mode AVP? >> [Tina: Just a mode value in Terminal-Mode AVP.] >> >> B. R. >> Tina >> >> ----- Original Message ----- From: "Tina TSOU" >> To: ; "Hannes Tschofenig" >> Sent: Wednesday, July 11, 2007 7:31 PM >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >> >> >>> >>> ----- Original Message ----- From: "Hannes Tschofenig"=20 >>> >>> To: ; "Tina TSOU" >>> Sent: Wednesday, July 11, 2007 6:46 PM >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >>> >>> >>>> Hi Tina, >>>> >>>> who translates high-level QoS information used at the application layer=20 >>>> into information that is appropriate for a QoS model that is used in a=20 >>>> particular access network. In your model it seems that the AF is in >>>> charge of assisting whereas the PDF does the final translation. In any=20 >>>> case, it is not the NE that does it. >>>> >>>> Correct? >>> [Tina: this question belongs to another thread "PULL/PUSH/Access network=20 >>> related information".] >>>> >>>> But how should the AF know anything about the access network=20 >>>> characteristics? >>>> (unless it is in the access network itself) >>> [Tina: this question belongs to another thread "PULL/PUSH/Access network=20 >>> related information".] >>>> What information would you put into the Terminal-Mode AVP? >>> [Tina: First, we can find which mode the terminal is by Terminal-mode,=20 >>> for example >>> 3GPP, WiFi, Wimax, etc. >>> The user terminal may be multi-mode, and each mode may have different=20 >>> QoS >>> profile, so the terminal-mode AVP can help to the operation on match QoS >>> request and QoS control.] >>>> >>>> Ciao >>>> Hannes >>>> >>>> Hannes Tschofenig wrote: >>>>> FYI >>>>> >>>>> ------ >>>>> >>>>> This is without the attachment. >>>>> >>>>> B. R. >>>>> Tina >>>>> >>>>> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org=20 >>>>> Sent: Wednesday, July 11, 2007 6:26 PM >>>>> Subject: Diameter QoS Appl.- terminal working mode >>>>> >>>>> >>>>> Hi Guys, >>>>> To converge different kind of authorizing entities and performing >>>>> NEs, terminal-Mode can tell the performing NE how to choose the=20 >>>>> interface working mode. First, we can find which mode the terminal is=20 >>>>> by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user=20 >>>>> terminal may be multi-mode, and each mode may have different QoS >>>>> profile, so the terminal-mode AVP can help to the operation on match=20 >>>>> QoS request and QoS control. >>>>> The following changes are proposed. (You can also find the changes in=20 >>>>> the attachment.) >>>>> section 6.2 >>>>> >>>>>
>>>>> >>>>> The QoS-Authorization-Answer message (QAA), indicated by=20 >>>>> the >>>>> >>>>> Command- Code field set to TBD and 'R' bit cleared in the >>>>> Command >>>>> >>>>> Flags field is sent in response to the=20 >>>>> QoS-Authorization-Request >>>>> >>>>> message (QAR). To converge different kind of authorizing >>>>> entities >>>>> and performing NEs, terminal-Mode can tell the performing NE=20 >>>>> how >>>>> to choose the interface working mode. If the QoS=20 >>>>> authorization request >>>>> >>>>> is successfully authorized, the response will include the >>>>> AVPs to >>>>> allow authorization of the QoS resources as well as=20 >>>>> accounting and >>>>> transport plane gating information. >>>>> >>>>> The message format is defined as follows: >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> ::=3D < Diameter Header: XXX, PXY > <=20 >>>>> Session-Id > { Auth-Application-Id }=20 >>>>> { Auth-Request-Type } { Result-Code } { >>>>> Origin-Host } { Origin-Realm } >>>>> [ Terminal-Mode ] * [ QoS-Resources ] [=20 >>>>> CC-Time ] [ Acc-Multisession-Id ]=20 >>>>> [ Session-Timeout ] [=20 >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ]=20 >>>>> * [ AVP ] ]]> >>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> section 6.3 >>>>> >>>>>
>>>>> >>>>> The QoS-Install Request message (QIR), indicated by the >>>>> >>>>> Command-Code field set to TDB and 'R' bit set in the Command=20 >>>>> Flags >>>>> >>>>> field is used by Authorizing entity to install or update the=20 >>>>> QoS >>>>> >>>>> parameters and the flow state of an authorized flow at the=20 >>>>> transport >>>>> >>>>> plane element. >>>>> >>>>> The message MUST carry information for signaling session >>>>> >>>>> identification or identification of the flow to which the >>>>> provided QoS >>>>> >>>>> rules apply, working mode of the terminal, identity of the=20 >>>>> transport >>>>> plane element, description of provided QoS parameters, flow=20 >>>>> state and >>>>> duration of the provided authorization. >>>>> >>>>> The message format is defined as follows: >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> ::=3D < Diameter Header: XXX, REQ, PXY > <=20 >>>>> Session-Id > { Auth-Application-Id } {=20 >>>>> Origin-Host } { Origin-Realm } >>>>> [ Terminal-Mode ] >>>>> { Destination-Realm }=20 >>>>> { Auth-Request-Type } [ Destination-Host ] * [=20 >>>>> QoS-Resources ] [ Session-Timeout ] [=20 >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] [=20 >>>>> Authz-Session-Volume ] * [ ]]> >>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> >>>>> >>>>> [snipped] >>>>> >>>>> >>>>> >>>>> section 7.1 >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> Attribute Name AVP Code Reference [RFC3588] >>>>> >>>>> Origin-Host 264 Section 6.3 >>>>> >>>>> Origin-Realm 296 Section 6.4 >>>>> >>>>> Terminal-Mode TBD >>>>> >>>>> >>>>> B. R. >>>>> >>>>> Tina >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 13 23:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9YSk-0000gb-MO; Fri, 13 Jul 2007 23:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9YSj-0000gJ-C3 for dime@ietf.org; Fri, 13 Jul 2007 23:38:29 -0400 Received: from smtp102.rog.mail.re2.yahoo.com ([206.190.36.80]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9YSf-0003sT-3s for dime@ietf.org; Fri, 13 Jul 2007 23:38:29 -0400 Received: (qmail 22783 invoked from network); 14 Jul 2007 03:38:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GXv50Ue18MaFVGPgnqDGrlmPR2qU/s/lgllwQGvQAI/KT8fqataFNnZWnt+VqNxMsXcd1Zxetpg/C7C3PLZ8rZoLVBf432yTGrfE4V7RYSiI+h1djEtP6WTwSuyAX9rX8TDS8bsTHmwY1x6S/HpwuK/vhzInE/dARCVTNCQib0I= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 14 Jul 2007 03:38:24 -0000 X-YMail-OSG: dxCxBKAVM1m_BODTYXcUvVGRqdEMV1pJ2Xzvxhq32da2vV0s8jnIOIM_.thLWuJu0g-- Message-ID: <469845AD.5070402@rogers.com> Date: Fri, 13 Jul 2007 23:40:29 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696ADC0.2080201@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Marked with [PTT2] at the end. McCann Peter-A001034 wrote: > Hi, Tom, > > Tom Taylor wrote: >> See at end. >> >> McCann Peter-A001034 wrote: >>> Tom Taylor wrote: >>> In general any router along the path might need to reserve resources >>> for a given flow, and to request authorization from the Diameter >>> cloud. I don't think we should limit ourselves to an architecture >>> that only supports discovery of the first hop (or something near the >>> first hop) as part of a Diameter application intended to support the >>> Internet architecture. >>> >> [PTT] Thinking about this a bit more, I guess the choice (making the >> assumption that the Diameter protocol is used) is between a network >> of Diameter servers (not a "Diameter cloud") in the RACF layer, >> versus a network of routers using NSIS between them with vertical >> relationships to local PDFs. > > I think I agree with this assessment - but I don't quite know what > you have in mind when you say "network of Diameter servers". Do > you mean a set of path-coupled entities through which the signaling > must pass? I think the "Diameter cloud" should be constructed based > on business agreements between operators, possibly with the help of > brokers that make the relationships scalable. A given NE should be > able to contact its local Diameter server with a request for > authentication/authorization, and there should be enough information > in the request to route to the user's "home" realm, according to > standard Diameter routing using the Destination-Realm AVP. The path > taken by the Diameter routing will not necessarily be along the same > path as the NSIS signaling. > > -Pete > > [PTT2] I have in mind something more like domain-by-domain authorization, which is why I speak of a network of Diameter servers. Policy in each domain determines which domain is the next one. Thus the AF can contact one Diameter server and get the path authorized all along its length. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jul 14 18:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pfg-0002Nw-G0; Sat, 14 Jul 2007 18:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pff-0002Np-9B for dime@ietf.org; Sat, 14 Jul 2007 18:00:59 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9pfa-0005wP-Ut for dime@ietf.org; Sat, 14 Jul 2007 18:00:59 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1184450453!15501889!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 838 invoked from network); 14 Jul 2007 22:00:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 14 Jul 2007 22:00:54 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6EM0rZ5008852 for ; Sat, 14 Jul 2007 15:00:53 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l6EM0qo3004366 for ; Sat, 14 Jul 2007 17:00:52 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l6EM0pjL004342 for ; Sat, 14 Jul 2007 17:00:51 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Date: Sat, 14 Jul 2007 18:00:49 -0400 Message-ID: In-Reply-To: <469845AD.5070402@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Thread-Index: AcfFyHPUh9MJMPB1TsiQq9TY2f5FMgAl/i4g References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696ADC0.2080201@rogers.com> <469845AD.5070402@rogers.com> From: "McCann Peter-A001034" To: "Tom Taylor" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tom Taylor wrote: > [PTT2] I have in mind something more like domain-by-domain > authorization, which is why I speak of a network of Diameter servers. > Policy in each domain determines which domain is the next one. Thus > the AF can contact one Diameter server and get the path authorized > all along its length. =20 I think the NEs in the data path will be in the best position to do policy-based routing, and the on-path signaling (such as NSIS) will follow this routing. In the pull model, each of the NEs would send a request toward the "home" Diameter server, and this request would get routed based on the realm name sent inband in the signaling. In the push model, finding the right NEs along the path is a challenge. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jul 14 18:12:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9prG-0008UW-QI; Sat, 14 Jul 2007 18:12:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9prG-0008SS-24 for dime@ietf.org; Sat, 14 Jul 2007 18:12:58 -0400 Received: from smtp108.rog.mail.re2.yahoo.com ([68.142.225.206]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9pr0-00058I-PJ for dime@ietf.org; Sat, 14 Jul 2007 18:12:57 -0400 Received: (qmail 21737 invoked from network); 14 Jul 2007 22:11:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Cd1D3+9fAk/KF03s9uOwnfU/44dSldK3SlGPuEn58gZFSKagouJpmci3WGMDooCh2up+l9GXESiTH92aCvS81yAB4EjT32tjaeDYGUzs+cNAqLhYmRhiCwYqYM+NDTytLZQNoWkyP8aw1YxChDzx4ZxOoDVzvToERkdEXOQ9RJM= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 14 Jul 2007 22:11:49 -0000 X-YMail-OSG: YNEpnssVM1kuDGEo16BULH_oqE4YE3AI5VgTjvX9rx27Yv5K3qWzFxkXWiLRJfUj7A-- Message-ID: <46994A9F.8020708@rogers.com> Date: Sat, 14 Jul 2007 18:13:51 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696ADC0.2080201@rogers.com> <469845AD.5070402@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Below. McCann Peter-A001034 wrote: > Tom Taylor wrote: > >> [PTT2] I have in mind something more like domain-by-domain >> authorization, which is why I speak of a network of Diameter servers. >> Policy in each domain determines which domain is the next one. Thus >> the AF can contact one Diameter server and get the path authorized >> all along its length. > ... > > In the push model, finding the right NEs along the path is a challenge. > [PTT3] Not so bad if policy is imposed at the edge of each network. Think of each domain's server pushing admission and policing policy to the ingress router, which is either predetermined from topology or chosen by the server and reported back to the upstream domain. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 15 14:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA9GD-00028V-1s; Sun, 15 Jul 2007 14:56:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA9GB-00028K-Ei for dime@ietf.org; Sun, 15 Jul 2007 14:55:59 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IA9GA-0007rM-St for dime@ietf.org; Sun, 15 Jul 2007 14:55:59 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1184525701!6326440!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1104 invoked from network); 15 Jul 2007 18:55:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 15 Jul 2007 18:55:01 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6FIt1A9012409 for ; Sun, 15 Jul 2007 11:55:01 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l6FIt0eT029059 for ; Sun, 15 Jul 2007 13:55:00 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l6FIsxmX029043 for ; Sun, 15 Jul 2007 13:54:59 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Accessnetworkrelatedinformation" Date: Sun, 15 Jul 2007 14:54:57 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D5209B9@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoSAppl.-"PULL/PUSH/Accessnetworkrelatedinformation" Thread-Index: AcfFNXbx4sPRnRtEQ+KopZ3YoaXsjwAQD5JAAAB+SwAABZKA4AABCqSgAF73ViA= References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com><4696744D.30005@gmx.net><010d01c7c535$703fdac0$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E7188065@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D5209B9@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Dong, See inline. Sun, Dong (Dong) wrote: > Hi Pete, >=20 > It seems two issues are mixed up here: the interaction between > Application server (e.g. AF) and policy server (i.e. authorizing > entity (AE), and the interaction between the entities (e.g. between > two AE instances in different domains or between AE and NE). =20 In my mind we are working on *one* Diameter application where the Authorizing Entity can be either a static home subscriber database or a dynamic Application Server. > Based on your previous comment, this application doesn't intend to > cover the interface/interaction between AS and AE. However, in the > attached email, you made some comments on the push model based on the > discussion for the interaction between AS and AE, which is totally > irrelevant to the scope of this spec. In fact, the push model defined > in this application concentrates on the interaction between entities > within this application (e.g. AE->AE and AE->NE). Hope this clarify > the scope of work. =20 I disagree with this scope of work. The Diameter QoS application=20 should be usable all the way to the AS. > Moreover, if look at some real implementation e.g. 3GPP, the model > they're using can be viewed as sort of pull model according to the > definition in this QoS application.=20 Yes, I think they pull authorization based on a PDP Context Activation. > as a matter of fact, it still > requires the "Push" approach from AF to PDF for service based policy > authorization. This is sth exactly Tolga described. This approach is > also used by the whole world, including TISPAN, WiMAX, Cablelabs, ITU > (in the NGN defined by TISPAN and ITU, the AF and PDF can be in > different provider domain as a mandatory requirement)... It is one of > cornerstone in NGN and makes the network neutrality realistic. I > don't think we can make any disclaimer to limit the usage of this > mechanism. =20 If we want to have a neutral network, we need to have the ability to place the AS anywhere, and we need an open, standardized interface between the AS and all of the NEs along the path. This is the reason why the Diameter QoS application was created and I don't think we should limit its scope to just a local PDF talking to a local NE. > In addition, I don't understand why AF can not discover the right > anchor point of PDF based on the realm info (for instance, some > anchor PDF can be preprovisoned between application service provider > and network provider according to SLA and business agreement). It is > essentially the same as the one you are advocating for NE based > approach. =20 At best, the Endpoint node can convey information about the first hop domain to the AS. This might allow for authorization to that first domain, but it certainly doesn't give the entire path followed by the flow, and there might be NEs that want to do QoS Authorization along that path. In the Internet, this routing will be done based on BGP and the Diameter servers are not in a position to influence this policy-based routing. -Pete > Regards, > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Friday, July 13, 2007 4:51 PM > To: Asveren, Tolga; Tina TSOU; Tom Taylor; Hannes Tschofenig > Cc: Christian Esteve; dime@ietf.org > Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access > networkrelatedinformation"=20 >=20 > Hi, Tolga, >=20 > Asveren, Tolga wrote: >=20 > [...deleting part where we agree...] >>>> [Tina: In the non-IMS scenario, there may be a service manager >>>> which=20 >=20 >>>> corresponds to the PDF in the IMS. The scenario with PDF is based >>>> on=20 >=20 >>>> the session, but the non-IMS scenario as you cited is based on the >>>> service. The service QoS profile will be pushed to the service >>>> manager. ] >>>=20 >>> How would the sender of the QoS profile know where to find the >>> service manager? How would it fill in the Destination-Host and >>> Destination-Realm fields of the push message? >>=20 >> [TOLGA]This probably would require an initial lookup by the AF to >> figure out at least the Destination-Realm based on the IP address of >> the user (or alternatively based on Subscriber-Id if the service and >> access providers are the same organization). >=20 > This sounds unscalable, especially if we take roaming users into > account. Who maintains this database? How is it updated?=20 > For roaming users, the access and service providers will not be the > same.=20 >=20 >> Another approach could >> be for AF to initiate the session always with a preconfigured >> Destination-Realm, where the server terminates the Diameter session, >> performs a query to find the actual Destination-Realm, and initiate a >> corresponding session. >=20 > It sounds like we are just pushing the problem to another node in the > network.=20 >=20 >> IMHO, how AF(or some other entity) performs this lookup is out of >> scope of Diameter QoS application (but an important part of the of >> the=20 >=20 >> overall solution though). >=20 > I think it's important that this be specified somewhere, so that we > can have an end-to-end solution that actually works. If nothing > else, we should put big disclaimers around the push mode to say that > it only works when AE and NE are in the same domain. If it turns out > to be impractical or impossible to implement discovery for > inter-domain push mode, we should consider taking push mode out of > the document. =20 >=20 >> I think pull >> mode wouldn't require a query to discover the Destination-Realm. >=20 > Right, I think we can augment path-coupled signaling with a realm > name to give the NE the information it needs to find the home server.=20 >=20 > -Pete >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 15 15:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAACH-000487-FB; Sun, 15 Jul 2007 15:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAACG-000482-R9 for dime@ietf.org; Sun, 15 Jul 2007 15:56:00 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAACC-00047s-EY for dime@ietf.org; Sun, 15 Jul 2007 15:56:00 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l6FJtu6m002041 for ; Sun, 15 Jul 2007 15:55:56 -0400 Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Date: Sun, 15 Jul 2007 15:55:55 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188067@sonusmail04.sonusnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <46994A9F.8020708@rogers.com> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network relatedinformation" Thread-Index: AcfGZCfRS48np5FxRNyQm4TW1Qh7kQAnbNhw References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com><4696556E.8020809@rogers.com><4696ADC0.2080201@rogers.com><469845AD.5070402@rogers.com> <46994A9F.8020708@rogers.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Although it would be nice to have a generic solution which scales/works well for any type of deployment, I feel that we will need to optimize for the most-common use case at the end (probably even that is going to be challenging).=20 I believe it could be useful to go over concrete use cases to validate different models and to make sure that we have a common understanding at least in terms of problem description: For push-mode: Let's assume the customer is subscriber of a VoIP provider in US and is currently in his home in Dubai. The customer is subscriber of local cable company for broadband connectivity. The first question is, how does the SIP proxy learn about the PDF in cable operator's network? Let's say the cable operator has a gateway PDF to receive QoS requests from the outside word, still the address of this entity needs to be discovered. AFAICS, there should be a globally administrated database mapping IP address ranges used by access providers to their gateway PDFs to make this work(we just removed support for NAPT queries in the bis document :-) ). If VoIP provider and access provider are the same company, this wouldn't be a hard to solve issue.=20 Second question is how the reservation for the whole path could be performed, if there is such a need. If PDF for the cable company is aware of the topology of its IP network, it can try to reserve bandwidth for the whole path under its own control. That it needs to know the IP network topology is not a desirable thing IMHO. Secondly, PDF needs to determine the route to be followed for this session, i.e. which routers the corresponding IP packets will traverse in its own network, and furthermore it somehow needs to feed this routing decision to the routers; I don't know whether this is even possible at all(or maybe some type of static routing will be used between routers so PDF can use the same preconfigured routes while determining the set of routers on the path). Secondly, QoS needs to be reserved in other administrative domains. PDF can contact the PDF of the next-hop administrative domain and that PDF can try to reserve QoS in its own domain as well (discovery of PDF of next administrative domain could be achieved relatively easily, because this is a peering relationship between two companies) For pull-mode: End point asks for QoS. The router in the access network queries the local Authorizing entity (the access user is always the local user of the access provider company). Any other router trying to satisfy the QoS reservation can always contact its own authorization entity, and authorization entity can decide based on the IP address of the customer whether it is a local customer and apply the policy corresponding to this customer; or otherwise can decide for the peering partner based on the IP address of the previous hop and apply the policy corresponding to this peering relationship. So, AFAICS, there is no need for a global database for this solution. Overall, it seems push-mode is easier applicable if QoS is reserved only on the access side and if the service and access is provided by the same organization (I think this second issue can be addressed with DNS/DNS like database). For pull-mode, one important problem is acceptance in the industry. It needs endpoint involvement and support in the network. As an example, AFAIK, RSVP is not supported in any of the Windows versions. Thanks, Tolga=20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Saturday, July 14, 2007 6:14 PM > To: McCann Peter-A001034 > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network > relatedinformation" >=20 > Below. >=20 > McCann Peter-A001034 wrote: > > Tom Taylor wrote: > > > >> [PTT2] I have in mind something more like domain-by-domain > >> authorization, which is why I speak of a network of Diameter servers. > >> Policy in each domain determines which domain is the next one. Thus > >> the AF can contact one Diameter server and get the path authorized > >> all along its length. > > > ... > > > > In the push model, finding the right NEs along the path is a challenge. > > > [PTT3] Not so bad if policy is imposed at the edge of each network. Think > of > each domain's server pushing admission and policing policy to the ingress > router, which is either predetermined from topology or chosen by the > server and > reported back to the upstream domain. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 15 17:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IABSP-00005B-Iy; Sun, 15 Jul 2007 17:16:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IABSN-000056-Tt for dime@ietf.org; Sun, 15 Jul 2007 17:16:43 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IABS8-0002Zj-Mn for dime@ietf.org; Sun, 15 Jul 2007 17:16:43 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1184534122!15358026!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 490 invoked from network); 15 Jul 2007 21:15:22 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-2.tower-119.messagelabs.com with SMTP; 15 Jul 2007 21:15:22 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l6FLFMqA010862 for ; Sun, 15 Jul 2007 14:15:22 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l6FLFLcG027392 for ; Sun, 15 Jul 2007 16:15:21 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6FLFKte027388 for ; Sun, 15 Jul 2007 16:15:20 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Date: Sun, 15 Jul 2007 17:15:17 -0400 Message-ID: In-Reply-To: <46994A9F.8020708@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information" Thread-Index: AcfGY/47zUvXJ9Z+TpGqaLcFhVS+ngAwQ+ew References: <9b0e41640707120533l3ae2705xb6669a51bb58b832@mail.gmail.com> <4696556E.8020809@rogers.com> <4696ADC0.2080201@rogers.com> <469845AD.5070402@rogers.com> <46994A9F.8020708@rogers.com> From: "McCann Peter-A001034" To: "Tom Taylor" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tom Taylor wrote: > Below. >=20 > McCann Peter-A001034 wrote: >> Tom Taylor wrote: >>=20 >>> [PTT2] I have in mind something more like domain-by-domain >>> authorization, which is why I speak of a network of Diameter >>> servers. Policy in each domain determines which domain is the next >>> one. Thus the AF can contact one Diameter server and get the path >>> authorized all along its length. >>=20 > ... >>=20 >> In the push model, finding the right NEs along the path is a >> challenge.=20 >>=20 > [PTT3] Not so bad if policy is imposed at the edge of each network. > Think of each domain's server pushing admission and policing policy > to the ingress router, which is either predetermined from topology or > chosen by the server and reported back to the upstream domain. =20 The next-hop domain will be chosen by BGP. I don't know if it is practical or feasible to mirror this state in the "Diameter Network" so that the Diameter servers can choose the right next-domain. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 16 16:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXCS-0001KZ-4K; Mon, 16 Jul 2007 16:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXCR-0001KE-1u for dime@ietf.org; Mon, 16 Jul 2007 16:29:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAXCM-0001O2-Oy for dime@ietf.org; Mon, 16 Jul 2007 16:29:43 -0400 Received: (qmail invoked by alias); 16 Jul 2007 20:29:37 -0000 Received: from p549864A5.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.100.165] by mail.gmx.net (mp031) with SMTP; 16 Jul 2007 22:29:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+uIEwDhN+unLyO1Lyeizet5AEy8FGI868iD1jvlK RbmS7r+5+VUBw+ Message-ID: <469BD530.4000607@gmx.net> Date: Mon, 16 Jul 2007 22:29:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Dime] DIME WG Status Update (July 2007) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, a new DIME WG status update is available: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 16 17:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYJS-0003J8-Pa; Mon, 16 Jul 2007 17:41:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYJS-0003Ig-A9 for dime@ietf.org; Mon, 16 Jul 2007 17:41:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAYJR-0004bZ-ST for dime@ietf.org; Mon, 16 Jul 2007 17:41:02 -0400 Received: (qmail invoked by alias); 16 Jul 2007 21:40:28 -0000 Received: from p549864A5.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.100.165] by mail.gmx.net (mp036) with SMTP; 16 Jul 2007 23:40:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+biNQCG3GbRPitrpvmwfX0B6Vt9tjHYrRvOCEEia I7NpVOu4KQRub6 Message-ID: <469BE5C8.1000704@gmx.net> Date: Mon, 16 Jul 2007 23:40:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Dime] Diameter Application Design Guidelines document X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, based on review comments (particularly by Mark Jones) and based on our experience with extending Diameter a new version of the Diameter Application Design Guidelines document is available. Before it gets posted it is available here: http://www.opendiameter.org/public/draft-ietf-dime-app-design-guide-02.txt Everyone who is currently working extensions, plans to make extensions or has worked on extensions to Diameter should take a look at the document and send us comments whether this document makes sense and helps protocol designers. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 18 10:56:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAwe-0001c2-LP; Wed, 18 Jul 2007 10:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAwd-0001br-50 for dime@ietf.org; Wed, 18 Jul 2007 10:56:03 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAwb-0003JO-EU for dime@ietf.org; Wed, 18 Jul 2007 10:56:03 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id CBBBB37C06A; Wed, 18 Jul 2007 20:20:26 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid B02C137C03C; Wed, 18 Jul 2007 20:20:26 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 20:25:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 20:24:49 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601D70C6B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding Error code 4003.(Election lost) Thread-Index: AcfJS5ah60dXtqBcTGCotK1zv4KFyw== From: "Balamurugan T, TLS-Chennai" To: , X-OriginalArrivalTime: 18 Jul 2007 14:55:58.0734 (UTC) FILETIME=[C02E52E0:01C7C94B] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-11.9222 TC:1F TRN:37 TV:3.6.1039(15306.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_AScxG32B9HtJWZxX2p9R" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [Dime] Clarification regarding Error code 4003.(Election lost) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_AScxG32B9HtJWZxX2p9R Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Clarification regarding Error code 4003.(Election lost)

Hi All,

    I need some = clarification regarding Error code 4003.

    RFC says = " ELECTION_LOST 4003  = The peer has determined that it has lost the election process and has =
    therefore = disconnected the transport connection. "

    In Peer state = machine, the Initiator of a connection disconnects it on election win = and sending CEA over responding

    connection. Do we = need to send CEA in Initiated connection before closing the connection?. = If the answer is no,
    which CEA will add = this error code.
 
    Can anyone explain = the actual   usage of this error code.

Thanks in Advance,
Bala





--=_Boundary_AScxG32B9HtJWZxX2p9R Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_AScxG32B9HtJWZxX2p9R Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_Boundary_AScxG32B9HtJWZxX2p9R-- From dime-bounces@ietf.org Wed Jul 18 18:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBHiD-0004nZ-Np; Wed, 18 Jul 2007 18:09:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBHiA-0004nR-GK for dime@ietf.org; Wed, 18 Jul 2007 18:09:36 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBHi9-0000sp-4r for dime@ietf.org; Wed, 18 Jul 2007 18:09:34 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00DOYAWCP1@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 18 Jul 2007 23:09:49 +0100 (BST) Received: from jys3105121962 (host16-218-dynamic.5-87-r.retail.telecomitalia.it [87.5.218.16]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLE00GAQAW963@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 18 Jul 2007 23:09:48 +0100 (BST) Date: Thu, 19 Jul 2007 00:09:16 +0200 From: Tina TSOU Subject: Re: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode To: Hannes Tschofenig , "Sun, Dong (Dong)" Message-id: <008f01c7c988$49f4e570$e7b6a8c0@jys3105121962> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: "+ADw-4694B447.8080800+AEA-gmx.net+AD4-+ADw-4694B4F0.5060804+AEA-gmx.net+AD4-+ADw-032001c7c3af+ACQ-07676c20+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-00d401c7c431+ACQ-e5bf9c90+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-4695E525.1010800+AEA-gmx.net+AD4 <00ba01c7c533$66d9eb30$864c460a@china.huawei.com> <09C9068466B79E4C938DC7737562404D5209BA@ILEXC2U01.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dong, I am afraid you have a misunderstanding about the terminal working mode, in this thread I don't expect it to distinguish the pull/push mode, but to tell the QoS control interface mode like Rw, Gx, etc. B.R. Tina ----- Original Message ----- From: "Sun, Dong (Dong)" To: "Tina TSOU" ; "Hannes Tschofenig" Cc: Sent: Saturday, July 14, 2007 12:17 AM Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Hi Tina, Thanks for drawing those beautiful pictures. Looks like you would be better to be a artist instead of engineer :-). To be honest, I am a bit confused by the intent of this terminal working mode. Would it be used for: - Indication of push or pull mode operated by AE - Indication of policy profile used by AE - or both I support to have a indicator to tell AE which operation model - Push or Pull should be used, which can be determined by AS (e.g. IMS AF), or just simply pre-provisoned. However, I am not yet convinced why the different policy profile should be used according to access technologies. A good example would be helpful. One example in my mind is that we may need access network type for correlating charging related data. However, I don't think this spec should make the charging function as mandatory requirement and it should be defined separately, such as in 4006. Another example, it would be used for resource based admission control, but obviously, the terminal working mode is not sufficient to serve that purpose. I can see the need to have a parameter to indicate the Push or Pull mode, which will be sent from AF to PDF or between two AE instances for inter-domain case, not from AE to NE within the same domain. (BTW, the current architecture does not perfectly reflect the inter-domain and intra-domain cases. I don't think the NE as enforcement point can be controlled by an AE in another administrative domain in reality. We should add a local AE and remote AE to justify the business model commonly used in the real network. See additional comment inline... Regards, Dong -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Friday, July 13, 2007 5:52 AM To: Hannes Tschofenig Cc: dime@ietf.org Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Hi Hannes, (If you are not able to see the picture in good shape, please look at the attachment.) financial settlement ...........................+ Application V ------- . signaling msg +--------------+ / QoS AAA \ . +-------------->| | / protocol \ . | | Authorizing +--------------+ \ . | | Entity | | | | . | + |<--+----+ | | . | +--------------+ |QoS | |QoS |. | install| |install | |rsp. | |req. |. | | | | |. | | | | . | . | \ | | . / . | \ | | / . V |-----V . . +-------------+ +--------+-----+ . | Entity | | NE | . | requesting | | performing | . | resource |QoS rsrc granted | QoS | <....+ | |<-----------------| reservation | +-------------+ +--------------+ Figure 5: Authorization Scheme for Push Mode Push, Authorizing entity gets access info including access type in the P-Access-Network-Info header, and translates the P-Access-Network-Info header into QIR message. NE so knows which QoS control interface to select between Authorizing entity and NE. [DS] Why NE as policy enforcement point needs to know it is a push or pull mode, the push or pull is the matter of AE (policy server)'s operation. I think, we can specify the state machine properly to indicate the push or pull in NE, for instance, When NE receives QIR for new session establishment, it goes to Push mode; when the NE receives the path coupled signaling from end host, it goes to Pull mode and trigger the QAR to AE. I can draw some detailed state mechanism later. +--------------+ | Entity | | authorizing | <......+ | resource | . | request | . +------------+-+ . --^----------|-- . . ///// | | \\\\\ . // | | \\ . | QoS | QoS AAA | QoS |. | authz| protocol |authz |. | req.| | res. |. \\ | | // . \\\\\ | | ///// . QoS --|----------v-- . . +-------------+ request +-+------------+ . | Entity |----------------->| NE | . | requesting | | performing | . | resource |granted / rejected| QoS | <.....+ | |<-----------------| reservation | financial +-------------+ +--------------+ settlement Figure 3: Three Party Scheme Pull, Authorizing entity gets Origin-host in the QAR message, and translates the Origin-host into terminal mode or access type in QAA message. NE so knows which QoS control interface to select between Authorizing entity and NE. [DS] when NE receives the path coupled signaling from end host, it implied a Pull mode by default. Is there any need to send back any thing from AE to NE in QAA? B. R. Tina ----- Original Message ----- From: "Hannes Tschofenig" To: "Tina TSOU" Cc: Sent: Thursday, July 12, 2007 4:24 PM Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > Hi Tina, > > thanks for the discussion. > > I believe that the concrete values in the Terminal-Mode AVP matter. When > you work on the document you need to list values and you need to setup a > registry (or refer to an existing registry). You also need to explain > where the values come from and what type of quality they have when they > are used as input to some decision making process. > > Christian suggested the usage of the P-Access- Network-Info AVP that is > added by a SIP proxy in the access network. > > Do you want to use P-Access- Network-Info? > Could you explain a bit more about the flow of information? Who is > supposed todo what and when? > > Ciao > Hannes > > Tina TSOU wrote: >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: ; "Tina TSOU" >>> Sent: Wednesday, July 11, 2007 6:46 PM >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >> [snipped] >>>> What information would you put into the Terminal-Mode AVP? >> [Tina: Just a mode value in Terminal-Mode AVP.] >> >> B. R. >> Tina >> >> ----- Original Message ----- From: "Tina TSOU" >> To: ; "Hannes Tschofenig" >> Sent: Wednesday, July 11, 2007 7:31 PM >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >> >> >>> >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: ; "Tina TSOU" >>> Sent: Wednesday, July 11, 2007 6:46 PM >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >>> >>> >>>> Hi Tina, >>>> >>>> who translates high-level QoS information used at the application layer >>>> into information that is appropriate for a QoS model that is used in a >>>> particular access network. In your model it seems that the AF is in >>>> charge of assisting whereas the PDF does the final translation. In any >>>> case, it is not the NE that does it. >>>> >>>> Correct? >>> [Tina: this question belongs to another thread "PULL/PUSH/Access network >>> related information".] >>>> >>>> But how should the AF know anything about the access network >>>> characteristics? >>>> (unless it is in the access network itself) >>> [Tina: this question belongs to another thread "PULL/PUSH/Access network >>> related information".] >>>> What information would you put into the Terminal-Mode AVP? >>> [Tina: First, we can find which mode the terminal is by Terminal-mode, >>> for example >>> 3GPP, WiFi, Wimax, etc. >>> The user terminal may be multi-mode, and each mode may have different >>> QoS >>> profile, so the terminal-mode AVP can help to the operation on match QoS >>> request and QoS control.] >>>> >>>> Ciao >>>> Hannes >>>> >>>> Hannes Tschofenig wrote: >>>>> FYI >>>>> >>>>> ------ >>>>> >>>>> This is without the attachment. >>>>> >>>>> B. R. >>>>> Tina >>>>> >>>>> ----- Original Message ----- From: Tina TSOU To: dime@ietf.org >>>>> Sent: Wednesday, July 11, 2007 6:26 PM >>>>> Subject: Diameter QoS Appl.- terminal working mode >>>>> >>>>> >>>>> Hi Guys, >>>>> To converge different kind of authorizing entities and performing >>>>> NEs, terminal-Mode can tell the performing NE how to choose the >>>>> interface working mode. First, we can find which mode the terminal is >>>>> by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user >>>>> terminal may be multi-mode, and each mode may have different QoS >>>>> profile, so the terminal-mode AVP can help to the operation on match >>>>> QoS request and QoS control. >>>>> The following changes are proposed. (You can also find the changes in >>>>> the attachment.) >>>>> section 6.2 >>>>> >>>>>
>>>>> >>>>> The QoS-Authorization-Answer message (QAA), indicated by >>>>> the >>>>> >>>>> Command- Code field set to TBD and 'R' bit cleared in the >>>>> Command >>>>> >>>>> Flags field is sent in response to the >>>>> QoS-Authorization-Request >>>>> >>>>> message (QAR). To converge different kind of authorizing >>>>> entities >>>>> and performing NEs, terminal-Mode can tell the performing NE >>>>> how >>>>> to choose the interface working mode. If the QoS >>>>> authorization request >>>>> >>>>> is successfully authorized, the response will include the >>>>> AVPs to >>>>> allow authorization of the QoS resources as well as >>>>> accounting and >>>>> transport plane gating information. >>>>> >>>>> The message format is defined as follows: >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> ::= < Diameter Header: XXX, PXY > < >>>>> Session-Id > { Auth-Application-Id } >>>>> { Auth-Request-Type } { Result-Code } { >>>>> Origin-Host } { Origin-Realm } >>>>> [ Terminal-Mode ] * [ QoS-Resources ] [ >>>>> CC-Time ] [ Acc-Multisession-Id ] >>>>> [ Session-Timeout ] [ >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] >>>>> * [ AVP ] ]]> >>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> section 6.3 >>>>> >>>>>
>>>>> >>>>> The QoS-Install Request message (QIR), indicated by the >>>>> >>>>> Command-Code field set to TDB and 'R' bit set in the Command >>>>> Flags >>>>> >>>>> field is used by Authorizing entity to install or update the >>>>> QoS >>>>> >>>>> parameters and the flow state of an authorized flow at the >>>>> transport >>>>> >>>>> plane element. >>>>> >>>>> The message MUST carry information for signaling session >>>>> >>>>> identification or identification of the flow to which the >>>>> provided QoS >>>>> >>>>> rules apply, working mode of the terminal, identity of the >>>>> transport >>>>> plane element, description of provided QoS parameters, flow >>>>> state and >>>>> duration of the provided authorization. >>>>> >>>>> The message format is defined as follows: >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> ::= < Diameter Header: XXX, REQ, PXY > < >>>>> Session-Id > { Auth-Application-Id } { >>>>> Origin-Host } { Origin-Realm } >>>>> [ Terminal-Mode ] >>>>> { Destination-Realm } >>>>> { Auth-Request-Type } [ Destination-Host ] * [ >>>>> QoS-Resources ] [ Session-Timeout ] [ >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ >>>>> Authz-Session-Volume ] * [ ]]> >>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> >>>>> >>>>> [snipped] >>>>> >>>>> >>>>> >>>>> section 7.1 >>>>> >>>>>
>>>>> >>>>> >>>> >>>>> Attribute Name AVP Code Reference [RFC3588] >>>>> >>>>> Origin-Host 264 Section 6.3 >>>>> >>>>> Origin-Realm 296 Section 6.4 >>>>> >>>>> Terminal-Mode TBD >>>>> >>>>> >>>>> B. R. >>>>> >>>>> Tina >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 19 03:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQOV-0002J8-Fa; Thu, 19 Jul 2007 03:25:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQOU-00023j-1P for dime@ietf.org; Thu, 19 Jul 2007 03:25:50 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBQOS-0006ji-5J for dime@ietf.org; Thu, 19 Jul 2007 03:25:49 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6J7PEk5019280; Thu, 19 Jul 2007 09:25:14 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 19 Jul 2007 09:25:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Date: Thu, 19 Jul 2007 09:25:32 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EA54D022@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <008f01c7c988$49f4e570$e7b6a8c0@jys3105121962> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Thread-Index: AcfJiFzMs15RgtdSSkyFN2jrp77r1AAS6k3Q References: "+ADw-4694B447.8080800+AEA-gmx.net+AD4-+ADw-4694B4F0.5060804+AEA-gmx.net+AD4-+ADw-032001c7c3af+ACQ-07676c20+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-00d401c7c431+ACQ-e5bf9c90+ACQ-864c460a+AEA-china.huawei.com+AD4-+ADw-4695E525.1010800+AEA-gmx.net+AD4<00ba01c7c533$66d9eb30$864c460a@china.huawei.com><09C9068466B79E4C938DC7737562404D5209BA@ILEXC2U01.ndc.lucent.com> <008f01c7c988$49f4e570$e7b6a8c0@jys3105121962> From: "Schwarz Albrecht" To: "Tina TSOU" , "Hannes Tschofenig" , "SUN D" X-OriginalArrivalTime: 19 Jul 2007 07:25:34.0059 (UTC) FILETIME=[FEA1EBB0:01C7C9D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > ...the QoS control interface mode like Rw, Gx, etc. Like to note that the "QoS control interface mode" at H.248-based policy control interfaces is addressed by an implicit mechanism: "Context-created" vs "Context-less" pull modes (see Draft H.248.55; T05-SG16-070626-TD-WP2-0459!R1). There's thus then a different pull request, dependent on the "QoS control interface mode". There isn't any provisioning/configuration action required, it's just a local method. The PDP is either receiving the pull request (=3D H.248 event) on Root or on non-Root termination level. (I.e., this allows the discrimination between the different "operation models" or "QoS control interface modes"). -Albrecht =20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com]=20 > Sent: Donnerstag, 19. Juli 2007 00:09 > To: Hannes Tschofenig; SUN D > Cc: dime@ietf.org > Subject: Re: [Dime] Re: [Dime] Diameter QoS Appl.- terminal=20 > working mode >=20 > Hi Dong, >=20 > I am afraid you have a misunderstanding about the terminal=20 > working mode, in this thread I don't expect it to distinguish=20 > the pull/push mode, but to tell the QoS control interface=20 > mode like Rw, Gx, etc. >=20 > B.R. > Tina >=20 > ----- Original Message ----- > From: "Sun, Dong (Dong)" > To: "Tina TSOU" ; "Hannes Tschofenig"=20 > > Cc: > Sent: Saturday, July 14, 2007 12:17 AM > Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal=20 > working mode >=20 >=20 > Hi Tina, >=20 > Thanks for drawing those beautiful pictures. Looks like you would be > better to be a artist instead of engineer :-). >=20 > To be honest, I am a bit confused by the intent of this=20 > terminal working > mode. Would it be used for: > - Indication of push or pull mode operated by AE > - Indication of policy profile used by AE > - or both >=20 > I support to have a indicator to tell AE which operation=20 > model - Push or > Pull should be used, which can be determined by AS (e.g. IMS AF), or > just simply pre-provisoned. However, I am not yet convinced why the > different policy profile should be used according to access > technologies. A good example would be helpful. One example in=20 > my mind is > that we may need access network type for correlating charging related > data. However, I don't think this spec should make the=20 > charging function > as mandatory requirement and it should be defined separately,=20 > such as in > 4006. Another example, it would be used for resource based admission > control, but obviously, the terminal working mode is not sufficient to > serve that purpose. >=20 > I can see the need to have a parameter to indicate the Push or Pull > mode, which will be sent from AF to PDF or between two AE=20 > instances for > inter-domain case, not from AE to NE within the same domain. (BTW, the > current architecture does not perfectly reflect the inter-domain and > intra-domain cases. I don't think the NE as enforcement point can be > controlled by an AE in another administrative domain in reality. We > should add a local AE and remote AE to justify the business model > commonly used in the real network. >=20 > See additional comment inline... >=20 > Regards, > Dong >=20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Friday, July 13, 2007 5:52 AM > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode >=20 > Hi Hannes, > (If you are not able to see the picture in good shape, please look at > the > attachment.) > financial settlement > ...........................+ > Application V ------- . > signaling msg +--------------+ / QoS AAA \ . > +-------------->| | / protocol \ . > | | Authorizing +--------------+ \ . > | | Entity | | | | . > | + |<--+----+ | | . > | +--------------+ |QoS | |QoS |. > | install| |install > | |rsp. | |req. |. > | | | | |. > | | | | . | . > | \ | | . / . > | \ | | / . > V |-----V . . > +-------------+ +--------+-----+ . > | Entity | | NE | . > | requesting | | performing | . > | resource |QoS rsrc granted | QoS | <....+ > | |<-----------------| reservation | > +-------------+ +--------------+ >=20 > Figure 5: Authorization Scheme for Push Mode Push, > Authorizing entity gets access info including access type in the > P-Access-Network-Info header, and translates the P-Access-Network-Info > header into QIR message. NE so knows which QoS control interface to > select between Authorizing entity and NE. >=20 > [DS] Why NE as policy enforcement point needs to know it is a push or > pull mode, the push or pull is the matter of AE (policy server)'s > operation. I think, we can specify the state machine properly to > indicate the push or pull in NE, for instance, When NE=20 > receives QIR for > new session establishment, it goes to Push mode; when the NE receives > the path coupled signaling from end host, it goes to Pull mode and > trigger the QAR to AE. I can draw some detailed state mechanism later. >=20 >=20 >=20 > +--------------+ > | Entity | > | authorizing | <......+ > | resource | . > | request | . > +------------+-+ . > --^----------|-- . . > ///// | | \\\\\ . > // | | \\ . > | QoS | QoS AAA | QoS |. > | authz| protocol |authz |. > | req.| | res. |. > \\ | | // . > \\\\\ | | ///// . > QoS --|----------v-- . . > +-------------+ request +-+------------+ . > | Entity |----------------->| NE | . > | requesting | | performing | . > | resource |granted / rejected| QoS | <.....+ > | |<-----------------| reservation | financial > +-------------+ +--------------+ settlement >=20 > Figure 3: Three Party Scheme Pull, Authorizing > entity gets Origin-host in the QAR message, and translates the > Origin-host into terminal mode or access type in QAA message. > NE so knows which QoS control interface to select between Authorizing > entity and NE. >=20 > [DS] when NE receives the path coupled signaling from end host, it > implied a Pull mode by default. Is there any need to send=20 > back any thing > from AE to NE in QAA? >=20 >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Tina TSOU" > Cc: > Sent: Thursday, July 12, 2007 4:24 PM > Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode >=20 >=20 > > Hi Tina, > > > > thanks for the discussion. > > > > I believe that the concrete values in the Terminal-Mode AVP matter. > When > > you work on the document you need to list values and you=20 > need to setup > a > > registry (or refer to an existing registry). You also need=20 > to explain > > where the values come from and what type of quality they have when > they > > are used as input to some decision making process. > > > > Christian suggested the usage of the P-Access- Network-Info AVP that > is > > added by a SIP proxy in the access network. > > > > Do you want to use P-Access- Network-Info? > > Could you explain a bit more about the flow of information? Who is > > supposed todo what and when? > > > > Ciao > > Hannes > > > > Tina TSOU wrote: > >>> ----- Original Message ----- From: "Hannes Tschofenig" > >>> > >>> To: ; "Tina TSOU" > >>> Sent: Wednesday, July 11, 2007 6:46 PM > >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > >> [snipped] > >>>> What information would you put into the Terminal-Mode AVP? > >> [Tina: Just a mode value in Terminal-Mode AVP.] > >> > >> B. R. > >> Tina > >> > >> ----- Original Message ----- From: "Tina TSOU" > >> To: ; "Hannes Tschofenig"=20 > > >> Sent: Wednesday, July 11, 2007 7:31 PM > >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > >> > >> > >>> > >>> ----- Original Message ----- From: "Hannes Tschofenig" > >>> > >>> To: ; "Tina TSOU" > >>> Sent: Wednesday, July 11, 2007 6:46 PM > >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > >>> > >>> > >>>> Hi Tina, > >>>> > >>>> who translates high-level QoS information used at the application > layer > >>>> into information that is appropriate for a QoS model that is used > in a > >>>> particular access network. In your model it seems that=20 > the AF is in >=20 > >>>> charge of assisting whereas the PDF does the final=20 > translation. In > any > >>>> case, it is not the NE that does it. > >>>> > >>>> Correct? > >>> [Tina: this question belongs to another thread "PULL/PUSH/Access > network > >>> related information".] > >>>> > >>>> But how should the AF know anything about the access network > >>>> characteristics? > >>>> (unless it is in the access network itself) > >>> [Tina: this question belongs to another thread "PULL/PUSH/Access > network > >>> related information".] > >>>> What information would you put into the Terminal-Mode AVP? > >>> [Tina: First, we can find which mode the terminal is by > Terminal-mode, > >>> for example > >>> 3GPP, WiFi, Wimax, etc. > >>> The user terminal may be multi-mode, and each mode may have > different > >>> QoS > >>> profile, so the terminal-mode AVP can help to the=20 > operation on match > QoS > >>> request and QoS control.] > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> Hannes Tschofenig wrote: > >>>>> FYI > >>>>> > >>>>> ------ > >>>>> > >>>>> This is without the attachment. > >>>>> > >>>>> B. R. > >>>>> Tina > >>>>> > >>>>> ----- Original Message ----- From: Tina TSOU To:=20 > dime@ietf.org > >>>>> Sent: Wednesday, July 11, 2007 6:26 PM > >>>>> Subject: Diameter QoS Appl.- terminal working mode > >>>>> > >>>>> > >>>>> Hi Guys, > >>>>> To converge different kind of authorizing entities and=20 > performing >=20 > >>>>> NEs, terminal-Mode can tell the performing NE how to choose the > >>>>> interface working mode. First, we can find which mode=20 > the terminal > is > >>>>> by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user > >>>>> terminal may be multi-mode, and each mode may have different QoS > >>>>> profile, so the terminal-mode AVP can help to the operation on > match > >>>>> QoS request and QoS control. > >>>>> The following changes are proposed. (You can also find the > changes in > >>>>> the attachment.) > >>>>> section 6.2 > >>>>> > >>>>>
> >>>>> > >>>>> The QoS-Authorization-Answer message (QAA),=20 > indicated > by > >>>>> the > >>>>> > >>>>> Command- Code field set to TBD and 'R' bit=20 > cleared in the >=20 > >>>>> Command > >>>>> > >>>>> Flags field is sent in response to the > >>>>> QoS-Authorization-Request > >>>>> > >>>>> message (QAR). To converge different kind of=20 > authorizing >=20 > >>>>> entities > >>>>> and performing NEs, terminal-Mode can tell the=20 > performing > NE > >>>>> how > >>>>> to choose the interface working mode. If the QoS > >>>>> authorization request > >>>>> > >>>>> is successfully authorized, the response will=20 > include the >=20 > >>>>> AVPs to > >>>>> allow authorization of the QoS resources as well as > >>>>> accounting and > >>>>> transport plane gating information. > >>>>> > >>>>> The message format is defined as follows: > >>>>> > >>>>>
> >>>>> > >>>>> >>>>> > >>>>> ::=3D < Diameter Header: XXX, PXY > > < > >>>>> Session-Id > { > Auth-Application-Id } > >>>>> { Auth-Request-Type } {=20 > Result-Code } { >=20 > >>>>> Origin-Host } { Origin-Realm } > >>>>> [ Terminal-Mode ] * [ QoS-Resources ] [ > >>>>> CC-Time ] [ > Acc-Multisession-Id ] > >>>>> [ Session-Timeout ] [ > >>>>> Authz-Session-Lifetime ] [ > Authz-Grace-Period ] > >>>>> * [ AVP ] ]]> > >>>>> > >>>>>
> >>>>> > >>>>>
> >>>>> > >>>>> section 6.3 > >>>>> > >>>>>
> >>>>> > >>>>> The QoS-Install Request message (QIR), indicated by > the > >>>>> > >>>>> Command-Code field set to TDB and 'R' bit set in the > Command > >>>>> Flags > >>>>> > >>>>> field is used by Authorizing entity to install=20 > or update > the > >>>>> QoS > >>>>> > >>>>> parameters and the flow state of an authorized flow at > the > >>>>> transport > >>>>> > >>>>> plane element. > >>>>> > >>>>> The message MUST carry information for signaling session > >>>>> > >>>>> identification or identification of the flow=20 > to which the >=20 > >>>>> provided QoS > >>>>> > >>>>> rules apply, working mode of the terminal, identity of > the > >>>>> transport > >>>>> plane element, description of provided QoS parameters, > flow > >>>>> state and > >>>>> duration of the provided authorization. > >>>>> > >>>>> The message format is defined as follows: > >>>>> > >>>>>
> >>>>> > >>>>> >>>>> > >>>>> ::=3D < Diameter Header: XXX, REQ, PXY > > < > >>>>> Session-Id > { Auth-Application-Id } { > >>>>> Origin-Host } { Origin-Realm } > >>>>> [ Terminal-Mode ] > >>>>> { Destination-Realm } > >>>>> { Auth-Request-Type } [=20 > Destination-Host ] * [ > >>>>> QoS-Resources ] [ Session-Timeout ] =20 > [ > >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ > >>>>> Authz-Session-Volume ] * [ ]]> > >>>>> > >>>>>
> >>>>> > >>>>>
> >>>>> > >>>>> > >>>>> > >>>>> [snipped] > >>>>> > >>>>> > >>>>> > >>>>> section 7.1 > >>>>> > >>>>>
> >>>>> > >>>>> >>>>> > >>>>> Attribute Name AVP Code Reference [RFC3588] > >>>>> > >>>>> Origin-Host 264 Section 6.3 > >>>>> > >>>>> Origin-Realm 296 Section 6.4 > >>>>> > >>>>> Terminal-Mode TBD > >>>>> > >>>>> > >>>>> B. R. > >>>>> > >>>>> Tina > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> DiME mailing list > >>>>> DiME@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/dime > >>>> > >>> > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 22 21:39:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICmt6-0006dI-8R; Sun, 22 Jul 2007 21:39:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICmt4-0006dC-N6 for dime@ietf.org; Sun, 22 Jul 2007 21:39:02 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICmt3-00079S-69 for dime@ietf.org; Sun, 22 Jul 2007 21:39:02 -0400 Received: (qmail 23072 invoked by uid 0); 23 Jul 2007 01:31:27 -0000 Received: by simscan 1.2.0 ppid: 23038, pid: 23054, t: 2.5894s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: ****** X-Spam-Status: No, score=6.2 required=6.5 tests=ALL_TRUSTED,BAYES_99, FAKE_REPLY_C,STOX_REPLY_TYPE autolearn=disabled version=3.2.1 Received: from unknown (HELO jys3105121962) (z24109@67.97.210.2) by hiltonsmtp.worldspice.net with ESMTPA; 23 Jul 2007 01:31:24 -0000 Message-ID: <02be01c7ccca$3605ac30$4fa81cac@jys3105121962> From: "Tina TSOU" To: Subject: Re: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode Date: Sun, 22 Jul 2007 20:38:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Albrecht, The T05-SG16-070626-TD-WP2-0459!R1 just figures out the H.248 based issue, but diameter-based issue needs a terminal working mode still. Moreover, the diameter is the trend and direction on the QoS control interface. BTW, it is not good for MG to be involved in such operation in the draft above. After all, it is the less limiting to the UE the better. B. R. Tina > ----- Original Message ----- > From: "Schwarz Albrecht" > To: "Tina TSOU" ; "Hannes Tschofenig" > ; "SUN D" > Cc: > Sent: Thursday, July 19, 2007 9:25 AM > Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal > working mode > > > > ...the QoS control interface mode like Rw, Gx, etc. > > Like to note that the "QoS control interface mode" at H.248-based > policycontrol interfaces is addressed by an implicit mechanism: > "Context-created" vs "Context-less" pull modes (see Draft H.248.55; > T05-SG16-070626-TD-WP2-0459!R1). > There's thus then a different pull request, dependent on the "QoS > control interface mode". > There isn't any provisioning/configuration action required, it's > just a > local method. The PDP is either receiving the pull request (= H.248 > event) on Root or on non-Root termination level. (I.e., this > allows the > discrimination between the different "operation models" or "QoS > controlinterface modes"). > > -Albrecht > > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: Donnerstag, 19. Juli 2007 00:09 > > To: Hannes Tschofenig; SUN D > > Cc: dime@ietf.org > > Subject: Re: [Dime] Re: [Dime] Diameter QoS Appl.- terminal > > working mode > > > > Hi Dong, > > > > I am afraid you have a misunderstanding about the terminal > > working mode, in this thread I don't expect it to distinguish > > the pull/push mode, but to tell the QoS control interface > > mode like Rw, Gx, etc. > > > > B.R. > > Tina > > > > ----- Original Message ----- > > From: "Sun, Dong (Dong)" > > To: "Tina TSOU" ; "Hannes Tschofenig" > > > > Cc: > > Sent: Saturday, July 14, 2007 12:17 AM > > Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal > > working mode > > > > > > Hi Tina, > > > > Thanks for drawing those beautiful pictures. Looks like you > would be > > better to be a artist instead of engineer :-). > > > > To be honest, I am a bit confused by the intent of this > > terminal working > > mode. Would it be used for: > > - Indication of push or pull mode operated by AE > > - Indication of policy profile used by AE > > - or both > > > > I support to have a indicator to tell AE which operation > > model - Push or > > Pull should be used, which can be determined by AS (e.g. IMS > AF), or > > just simply pre-provisoned. However, I am not yet convinced why the > > different policy profile should be used according to access > > technologies. A good example would be helpful. One example in > > my mind is > > that we may need access network type for correlating charging > related> data. However, I don't think this spec should make the > > charging function > > as mandatory requirement and it should be defined separately, > > such as in > > 4006. Another example, it would be used for resource based admission > > control, but obviously, the terminal working mode is not > sufficient to > > serve that purpose. > > > > I can see the need to have a parameter to indicate the Push or Pull > > mode, which will be sent from AF to PDF or between two AE > > instances for > > inter-domain case, not from AE to NE within the same domain. > (BTW, the > > current architecture does not perfectly reflect the inter-domain and > > intra-domain cases. I don't think the NE as enforcement point > can be > > controlled by an AE in another administrative domain in reality. We > > should add a local AE and remote AE to justify the business model > > commonly used in the real network. > > > > See additional comment inline... > > > > Regards, > > Dong > > > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: Friday, July 13, 2007 5:52 AM > > To: Hannes Tschofenig > > Cc: dime@ietf.org > > Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode > > > > Hi Hannes, > > (If you are not able to see the picture in good shape, please > look at > > the > > attachment.) > > financial settlement > > ...........................+ > > Application V ------- . > > signaling msg +--------------+ / QoS AAA \ . > > +-------------->| | / protocol \ . > > | | Authorizing +--------------+ \ . > > | | Entity | | | | . > > | + |<--+----+ | | . > > | +--------------+ |QoS | |QoS |. > > | install| |install > > | |rsp. | |req. |. > > | | | | |. > > | | | | . | . > > | \ | | . / . > > | \ | | / . > > V |-----V . . > > +-------------+ +--------+-----+ . > > | Entity | | NE | . > > | requesting | | performing | . > > | resource |QoS rsrc granted | QoS | <....+ > > | |<-----------------| reservation | > > +-------------+ +--------------+ > > > > Figure 5: Authorization Scheme for Push Mode Push, > > Authorizing entity gets access info including access type in the > > P-Access-Network-Info header, and translates the P-Access- > Network-Info > > header into QIR message. NE so knows which QoS control interface to > > select between Authorizing entity and NE. > > > > [DS] Why NE as policy enforcement point needs to know it is a > push or > > pull mode, the push or pull is the matter of AE (policy server)'s > > operation. I think, we can specify the state machine properly to > > indicate the push or pull in NE, for instance, When NE > > receives QIR for > > new session establishment, it goes to Push mode; when the NE > receives> the path coupled signaling from end host, it goes to > Pull mode and > > trigger the QAR to AE. I can draw some detailed state mechanism > later.> > > > > > > +--------------+ > > | Entity | > > | authorizing | <......+ > > | resource | . > > | request | . > > +------------+-+ . > > --^----------|-- . . > > ///// | | \\\\\ . > > // | | \\ . > > | QoS | QoS AAA | QoS |. > > | authz| protocol |authz |. > > | req.| | res. |. > > \\ | | // . > > \\\\\ | | ///// . > > QoS --|----------v-- . . > > +-------------+ request +-+------------+ . > > | Entity |----------------->| NE | . > > | requesting | | performing | . > > | resource |granted / rejected| QoS | <.....+ > > | |<-----------------| reservation | financial > > +-------------+ +--------------+ settlement > > > > Figure 3: Three Party Scheme Pull, > Authorizing> entity gets Origin-host in the QAR message, and > translates the > > Origin-host into terminal mode or access type in QAA message. > > NE so knows which QoS control interface to select between > Authorizing> entity and NE. > > > > [DS] when NE receives the path coupled signaling from end host, it > > implied a Pull mode by default. Is there any need to send > > back any thing > > from AE to NE in QAA? > > > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: "Hannes Tschofenig" > > To: "Tina TSOU" > > Cc: > > Sent: Thursday, July 12, 2007 4:24 PM > > Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > > > > > > Hi Tina, > > > > > > thanks for the discussion. > > > > > > I believe that the concrete values in the Terminal-Mode AVP > matter.> When > > > you work on the document you need to list values and you > > need to setup > > a > > > registry (or refer to an existing registry). You also need > > to explain > > > where the values come from and what type of quality they have when > > they > > > are used as input to some decision making process. > > > > > > Christian suggested the usage of the P-Access- Network-Info > AVP that > > is > > > added by a SIP proxy in the access network. > > > > > > Do you want to use P-Access- Network-Info? > > > Could you explain a bit more about the flow of information? > Who is > > > supposed todo what and when? > > > > > > Ciao > > > Hannes > > > > > > Tina TSOU wrote: > > >>> ----- Original Message ----- From: "Hannes Tschofenig" > > >>> > > >>> To: ; "Tina TSOU" > > >>> Sent: Wednesday, July 11, 2007 6:46 PM > > >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > >> [snipped] > > >>>> What information would you put into the Terminal-Mode AVP? > > >> [Tina: Just a mode value in Terminal-Mode AVP.] > > >> > > >> B. R. > > >> Tina > > >> > > >> ----- Original Message ----- From: "Tina TSOU" > > >> To: ; "Hannes Tschofenig" > > > > >> Sent: Wednesday, July 11, 2007 7:31 PM > > >> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > >> > > >> > > >>> > > >>> ----- Original Message ----- From: "Hannes Tschofenig" > > >>> > > >>> To: ; "Tina TSOU" > > >>> Sent: Wednesday, July 11, 2007 6:46 PM > > >>> Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode > > >>> > > >>> > > >>>> Hi Tina, > > >>>> > > >>>> who translates high-level QoS information used at the > application> layer > > >>>> into information that is appropriate for a QoS model that > is used > > in a > > >>>> particular access network. In your model it seems that > > the AF is in > > > > >>>> charge of assisting whereas the PDF does the final > > translation. In > > any > > >>>> case, it is not the NE that does it. > > >>>> > > >>>> Correct? > > >>> [Tina: this question belongs to another thread "PULL/PUSH/Access > > network > > >>> related information".] > > >>>> > > >>>> But how should the AF know anything about the access network > > >>>> characteristics? > > >>>> (unless it is in the access network itself) > > >>> [Tina: this question belongs to another thread "PULL/PUSH/Access > > network > > >>> related information".] > > >>>> What information would you put into the Terminal-Mode AVP? > > >>> [Tina: First, we can find which mode the terminal is by > > Terminal-mode, > > >>> for example > > >>> 3GPP, WiFi, Wimax, etc. > > >>> The user terminal may be multi-mode, and each mode may have > > different > > >>> QoS > > >>> profile, so the terminal-mode AVP can help to the > > operation on match > > QoS > > >>> request and QoS control.] > > >>>> > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> Hannes Tschofenig wrote: > > >>>>> FYI > > >>>>> > > >>>>> ------ > > >>>>> > > >>>>> This is without the attachment. > > >>>>> > > >>>>> B. R. > > >>>>> Tina > > >>>>> > > >>>>> ----- Original Message ----- From: Tina TSOU To: > > dime@ietf.org > > >>>>> Sent: Wednesday, July 11, 2007 6:26 PM > > >>>>> Subject: Diameter QoS Appl.- terminal working mode > > >>>>> > > >>>>> > > >>>>> Hi Guys, > > >>>>> To converge different kind of authorizing entities and > > performing > > > > >>>>> NEs, terminal-Mode can tell the performing NE how to > choose the > > >>>>> interface working mode. First, we can find which mode > > the terminal > > is > > >>>>> by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user > > >>>>> terminal may be multi-mode, and each mode may have > different QoS > > >>>>> profile, so the terminal-mode AVP can help to the > operation on > > match > > >>>>> QoS request and QoS control. > > >>>>> The following changes are proposed. (You can also find the > > changes in > > >>>>> the attachment.) > > >>>>> section 6.2 > > >>>>> > > >>>>>
> > >>>>> > > >>>>> The QoS-Authorization-Answer message (QAA), > > indicated > > by > > >>>>> the > > >>>>> > > >>>>> Command- Code field set to TBD and 'R' bit > > cleared in the > > > > >>>>> Command > > >>>>> > > >>>>> Flags field is sent in response to the > > >>>>> QoS-Authorization-Request > > >>>>> > > >>>>> message (QAR). To converge different kind of > > authorizing > > > > >>>>> entities > > >>>>> and performing NEs, terminal-Mode can tell the > > performing > > NE > > >>>>> how > > >>>>> to choose the interface working mode. If the QoS > > >>>>> authorization request > > >>>>> > > >>>>> is successfully authorized, the response will > > include the > > > > >>>>> AVPs to > > >>>>> allow authorization of the QoS resources as well as > > >>>>> accounting and > > >>>>> transport plane gating information. > > >>>>> > > >>>>> The message format is defined as follows: > > >>>>> > > >>>>>
> > >>>>> > > >>>>> > >>>>> > > >>>>> ::= < Diameter Header: XXX, PXY > > > < > > >>>>> Session-Id > { > > Auth-Application-Id } > > >>>>> { Auth-Request-Type } { > > Result-Code } { > > > > >>>>> Origin-Host } { Origin- > Realm } > > >>>>> [ Terminal-Mode ] * [ QoS- > Resources ] [ > > >>>>> CC-Time ] [ > > Acc-Multisession-Id ] > > >>>>> [ Session-Timeout ] [ > > >>>>> Authz-Session-Lifetime ] [ > > Authz-Grace-Period ] > > >>>>> * [ AVP ] ]]> > > >>>>> > > >>>>>
> > >>>>> > > >>>>>
> > >>>>> > > >>>>> section 6.3 > > >>>>> > > >>>>>
> > >>>>> > > >>>>> The QoS-Install Request message (QIR), > indicated by > > the > > >>>>> > > >>>>> Command-Code field set to TDB and 'R' bit set in the > > Command > > >>>>> Flags > > >>>>> > > >>>>> field is used by Authorizing entity to install > > or update > > the > > >>>>> QoS > > >>>>> > > >>>>> parameters and the flow state of an authorized > flow at > > the > > >>>>> transport > > >>>>> > > >>>>> plane element. > > >>>>> > > >>>>> The message MUST carry information for signaling session > > >>>>> > > >>>>> identification or identification of the flow > > to which the > > > > >>>>> provided QoS > > >>>>> > > >>>>> rules apply, working mode of the terminal, > identity of > > the > > >>>>> transport > > >>>>> plane element, description of provided QoS > parameters,> flow > > >>>>> state and > > >>>>> duration of the provided authorization. > > >>>>> > > >>>>> The message format is defined as follows: > > >>>>> > > >>>>>
> > >>>>> > > >>>>> > >>>>> > > >>>>> ::= < Diameter Header: XXX, REQ, > PXY > > > < > > >>>>> Session-Id > { Auth-Application- > Id } { > > >>>>> Origin-Host } { Origin-Realm } > > >>>>> [ Terminal-Mode ] > > >>>>> { Destination-Realm } > > >>>>> { Auth-Request-Type } [ > > Destination-Host ] * [ > > >>>>> QoS-Resources ] [ Session-Timeout ] > > [ > > >>>>> Authz-Session-Lifetime ] [ Authz-Grace-Period > ] [ > > >>>>> Authz-Session-Volume ] * [ ]]> > > >>>>> > > >>>>>
> > >>>>> > > >>>>>
> > >>>>> > > >>>>> > > >>>>> > > >>>>> [snipped] > > >>>>> > > >>>>> > > >>>>> > > >>>>> section 7.1 > > >>>>> > > >>>>>
> > >>>>> > > >>>>> > >>>>> > > >>>>> Attribute Name AVP Code Reference > [RFC3588]> >>>>> > > >>>>> Origin-Host 264 Section 6.3 > > >>>>> > > >>>>> Origin-Realm 296 Section 6.4 > > >>>>> > > >>>>> Terminal-Mode TBD > > >>>>> > > >>>>> > > >>>>> B. R. > > >>>>> > > >>>>> Tina > > >>>>> > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> DiME mailing list > > >>>>> DiME@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/dime > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> DiME mailing list > > >>> DiME@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 24 05:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDGXo-0004YM-9k; Tue, 24 Jul 2007 05:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDGXm-0004PO-Kb for dime@ietf.org; Tue, 24 Jul 2007 05:19:02 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDGXj-0001N3-L4 for dime@ietf.org; Tue, 24 Jul 2007 05:19:02 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 6C7E937C048; Tue, 24 Jul 2007 14:43:09 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 2DAC637C033; Tue, 24 Jul 2007 14:43:09 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 14:48:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jul 2007 14:47:41 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601E439BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Reg. the "E" bit for the Protocol Error Thread-Index: AcfNzikN7Jy2X6e3SRKIpHsdEr1wawABTHdg From: "Arun Santhanam, TLS-Chennai" To: "Victor Fajardo" X-OriginalArrivalTime: 24 Jul 2007 09:18:55.0191 (UTC) FILETIME=[A87D0E70:01C7CDD3] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-15.7184 TC:1F TRN:72 TV:3.6.1039(15318.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.0 (+) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: dime@ietf.org Subject: [Dime] Reg. the "E" bit for the Protocol Error X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1918553145==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1918553145== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7CDD3.858E932B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CDD3.858E932B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7CDD3.858E932B" ------_=_NextPart_002_01C7CDD3.858E932B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Victor, I have a Query with respect to "E" bit for protocol Error's. Why "E" bit is set only for the Protocol Errors and not in general for all Errors Responses? As per RFC all 3xxx range errors will be considered as protocol error, then what is the Significance of the "E" bit? =20 Thanks & Regards Arun Santhanam Lead Engineer- VOIP HCL Technologies Ltd. No 8, Mth Road Ambattur Industial estate Chennai (T.N) 600058 Tel: +91-044-439672000 Extn. (7278) Direct: +91-044-43967278=20 Mob: +91-9841951234 www.hcltech.com www.hcl.in =20 =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_002_01C7CDD3.858E932B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Victor,

         &n= bsp;     I have a Query with respect to “E” bit for protocol= Error’s.

         &n= bsp;     Why “E” bit is set only for the Protocol Errors and not= in general for all Errors Responses?

         &n= bsp;     As per RFC all 3xxx range errors will be considered as protocol= error, then what is the Significance of the “E” bit?                         =

 

Than= ks & Regards

Arun Santhanam

Lead Engineer-= VOIP

HCL Technologies Ltd.

No 8, Mth Road Ambattur Industial= estate

Chennai (T.N)= 600058

Tel: +91-044-439672000  Extn.= (7278)

Direct: +91-044-43967278=

Mob:= +91-9841951234

www.hcltech.com

www.= hcl.in

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_002_01C7CDD3.858E932B-- ------_=_NextPart_001_01C7CDD3.858E932B Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAZARwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aisf /hLfD3/QXtf+/go/4S3w9/0F7X/v4K09lU/lf3Gftaf8y+82KKx/+Et8Pf8AQXtf+/go/wCEt8Pf 9Bi1/wC/go9lU/lf3B7Wn/MvvNiisf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+ 82KKx/8AhLfD3/QYtf8Av4KP+Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4K P+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf 3B7Wn/MvvNiisf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QY tf8Av4KP+Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj 2VT+V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf3B7Wn/MvvNiisf8A 4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QYtf8Av4Kv2WoWepQG eyuY7iMHaWjbIB9KThKKu0NTjJ2TLNc1491Q6Z4YmEblJrlhChBwRnkn8ga6WuK8d+H9a8QXVqlj FG1tAhJLSBcufb6AfnWmHUXVXM9DLEuSpPkV2cL4e10aZrMN5qEt1PDFkiNZCctjA6mt/wAUfECD WNI+xadFc27tIC7sQPlHOBg+uK6TwT4UfRdPn/tOCFrmaTOOHAUDjn86yPGHhHWdZ1rzrC1t0tY4 wifOq57k4+p/SvRdWhOvd9Ot9DzlSxFOhp16W1MbwdfvY/b9dvpp5YbGIKiGQnfI5wBz+P51ENY8 Q+M9ZSxjvGgWUn93ExVEUdSccn8a7DS/BJHguXR71hFc3EhlZ0O7awPy/XgD8zXN2ng/xb4e1IXe mxwzOmQHSRSGB7ENiqVWjKU5Jrm6X2JdKtGMItPl623NO4+FgFsXtdVka7HIMi4Un8OR+tX/AA1o XiXQbwPfanBPp4U+bGZXbbx1XI4qlPb/ABE1UorvFp6KescgTP1wSa1n0HW7bwzeW/8AaU2o6hdJ 5YMsmEQHg7c+2ea551JuPLOad/63OiFOClzQg1b+tjzPUdYvtT1i4niuJx9omPloshGAThRj8q9r 0uzNhpdtaFizRRqrMxySccn868vtPAXieyu4rqGC28yFw6bpQRkdOK6P/i4//Tj/AOO1piuSooxh JWXmZ4TnpuUqkXd+R3FFQWa3C2UIu3V7gIPNZRgFsc4/Gp68lnrLVHz39kuf+fab/v2f8KPslz/z 7Tf9+z/hX0JRXq/2k/5fxPK/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8 Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8A Cj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+ X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+ /Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQl FH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCf ab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+Ff QlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACtXQ9Z1vw88rWEUgWUDekkLMpx0OPWvb6KUsw5la UNCo5dyu8Z2Z5R/wsDxV/wA+0f8A4DN/jR/wsDxV/wA+0f8A4DN/jXq9FY/WaX/PtG31Wr/z9Z5R /wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8Vf8APtH/AOAz f40f8LA8Vf8APtH/AOAzf416vRR9Zpf8+0H1Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+ Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8Vf8APtH/AOAzf40f8LA8Vf8APtH/AOAzf416vRR9Zpf8 +0H1Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/Wf/Z ------_=_NextPart_001_01C7CDD3.858E932B-- --===============1918553145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1918553145==-- From dime-bounces@ietf.org Tue Jul 24 06:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDHUd-0006e4-T6; Tue, 24 Jul 2007 06:19:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDHUd-0006dy-1F for dime@ietf.org; Tue, 24 Jul 2007 06:19:51 -0400 Received: from mglblrmail.mgl.com ([61.95.163.15] helo=mglblrmail.blr.mgl.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDHUb-0001k5-MH for dime@ietf.org; Tue, 24 Jul 2007 06:19:50 -0400 Received: from [172.16.25.60] ([172.16.25.60]) by mglblrmail.blr.mgl.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jul 2007 15:49:43 +0530 Message-ID: <46A5D231.9040502@mgl.com> Date: Tue, 24 Jul 2007 15:49:29 +0530 From: Oviaprasad D User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" Subject: Re: [Dime] Reg. the "E" bit for the Protocol Error References: <66E8AEE9980BB44CA5FCAD39EBA56AC601E439BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601E439BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-OriginalArrivalTime: 24 Jul 2007 10:19:43.0206 (UTC) FILETIME=[26DFF860:01C7CDDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1141629512==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1141629512== Content-Type: multipart/alternative; boundary="------------090109060801020505040500" This is a multi-part message in MIME format. --------------090109060801020505040500 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi Arun As per Rfc bellow quote tells the reason why E-bit set only for=20 protocol error 7. Error Handling There are two different types of errors in Diameter; protocol and application errors. A protocol error is one that occurs at the base protocol level, and MAY require per hop attention (e.g., message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, Missing AVP). Also I will suggest you to see the same section and Figure 8=20 provides an example for Application errors not sets E-bit. regards Oviya Arun Santhanam, TLS-Chennai wrote: > > =20 > > Hi Victor, > > I have a Query with respect to "E" bit for protocol=20 > Error's. > > Why "E" bit is set only for the Protocol Errors and not=20 > in general for all Errors Responses? > > As per RFC all 3xxx range errors will be considered as=20 > protocol error, then what is the Significance of the "E" bit? =20 > =20 > > =20 > > *Thanks & Regards* > > *Arun Santhanam* > > Lead Engineer- VOIP > > *HCL Technologies Ltd*. > > No 8, Mth Road Ambattur Industial estate > > Chennai (T.N) 600058 > > Tel: +91-044-439672000 Extn. (7278) > > Direct: +91-044-43967278 > > Mob: +91-9841951234 > > www.hcltech.com > > *www.hcl.in* > > =20 > > DISCLAIMER: > -----------------------------------------------------------------------= ------------------------------------------------ > > The contents of this e-mail and any attachment(s) are confidential and=20 > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily=20 > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of > this message without the prior written consent of the author of this=20 > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender=20 > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -----------------------------------------------------------------------= ------------------------------------------------ > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.=0A=0AWhilst Mascon takes steps to prevent the transmission of viru= ses via e-mail, we can not guarantee that any email or attachment is free= from computer viruses and you are strongly advised to undertake your own= anti-virus precautions. Mascon grants no warranties regarding performanc= e, use or quality of any e-mail or attachment and undertakes no liability= for loss or damage, howsoever caused. =0A=0A --------------090109060801020505040500 Content-Type: multipart/related; boundary="------------070706040308080108020401" --------------070706040308080108020401 Content-Type: text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi Arun
    As per Rfc bellow quote tells the reason why E-bit set= only for protocol error
<rfc>
      7.  Error Handling

   There are two different types of errors in Diameter; protoco= l and
   application errors.  A protocol error is one that occur= s at the base
   protocol level, and MAY require per hop attention (e.g., mes= sage
   routing error).  Application errors, on the other hand,= generally
   occur due to a problem with a function specified in a Diamet= er
   application (e.g., user authentication, Missing AVP).
</rfc>
    Also I will suggest you to see the same section and Fi= gure 8 provides an example
for Application errors not sets E-bit.


regards
Oviya

Arun Santhanam, TLS-Chennai wrote:

 

Hi Victor,

    &= nbsp;          I have a Query with respect to “E” bit for protocol ErrorR= 17;s.

    &= nbsp;          Why “E” bit is set only for the Protocol Errors and not= in general for all Errors Responses?

    &= nbsp;          As per RFC all 3xxx range errors will be considered as protocol err= or, then what is the Significance of the “E” bit?                          <= /o:p>

 <= /font>

Thanks & Regards

Arun Santhanam=

= Lead Engineer- VOIP

HCL Technologies Ltd= =2E=

= No 8, Mth Road Ambattur Industial estate

= Chennai (T.N) 600058

= Tel: +91-044-439672000  Extn. (7278)

= Direct: +91-044-43967278

= Mob: +91-9841951234

= www.hcltech.com=

www.hcl.in

=

 

DISCLAIMER:
-------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-------------------------------------------------------------------------= ----------------------------------------------
 

_______________________________________________
DiME mailing list
DiME@=
ietf.org
https://www1.ietf.org/mailman/listinfo/dime

EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.
=0A
=0AWhilst Mascon takes steps to prevent the transmission= of viruses via e-mail, we can not guarantee that any email or attachment= is free from computer viruses and you are strongly advised to undertake = your own anti-virus precautions. Mascon grants no warranties regarding pe= rformance, use or quality of any e-mail or attachment and undertakes no l= iability for loss or damage, howsoever caused.
=0A
=0A

--------------070706040308080108020401 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAZARwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aisf/hLfD3/QXtf+/go/4S3w9/0F7X/v 4K09lU/lf3Gftaf8y+82KKx/+Et8Pf8AQXtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf3B7Wn/Mv vNiisf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QYtf8A v4KP+Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj 2VT+V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf3B7Wn/MvvNii sf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QYtf8Av4KP +Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+ V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf3B7Wn/MvvNiisf8A 4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QYtf8Av4Kv2WoW epQGeyuY7iMHaWjbIB9KThKKu0NTjJ2TLNc1491Q6Z4YmEblJrlhChBwRnkn8ga6WuK8d+H9 a8QXVqljFG1tAhJLSBcufb6AfnWmHUXVXM9DLEuSpPkV2cL4e10aZrMN5qEt1PDFkiNZCctj A6mt/wAUfECDWNI+xadFc27tIC7sQPlHOBg+uK6TwT4UfRdPn/tOCFrmaTOOHAUDjn86yPGH hHWdZ1rzrC1t0tY4wifOq57k4+p/SvRdWhOvd9Ot9DzlSxFOhp16W1MbwdfvY/b9dvpp5YbG IKiGQnfI5wBz+P51ENY8Q+M9ZSxjvGgWUn93ExVEUdSccn8a7DS/BJHguXR71hFc3EhlZ0O7 awPy/XgD8zXN2ng/xb4e1IXemxwzOmQHSRSGB7ENiqVWjKU5Jrm6X2JdKtGMItPl623NO4+F gFsXtdVka7HIMi4Un8OR+tX/AA1oXiXQbwPfanBPp4U+bGZXbbx1XI4qlPb/ABE1UorvFp6K escgTP1wSa1n0HW7bwzeW/8AaU2o6hdJ5YMsmEQHg7c+2ea551JuPLOad/63OiFOClzQg1b+ tjzPUdYvtT1i4niuJx9omPloshGAThRj8q9r0uzNhpdtaFizRRqrMxySccn868vtPAXieyu4 rqGC28yFw6bpQRkdOK6P/i4//Tj/AOO1piuSooxhJWXmZ4TnpuUqkXd+R3FFQWa3C2UIu3V7 gIPNZRgFsc4/Gp68lnrLVHz39kuf+fab/v2f8KPslz/z7Tf9+z/hX0JRXq/2k/5fxPK/sxfz fgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/w o+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQl FH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5 /wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/Pt N/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8 Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v 2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+Ff QlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACtXQ9Z1vw88rWEUgWUDekkLMpx0OPWvb6KUs w5laUNCo5dyu8Z2Z5R/wsDxV/wA+0f8A4DN/jR/wsDxV/wA+0f8A4DN/jXq9FY/WaX/PtG31 Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8 Vf8APtH/AOAzf40f8LA8Vf8APtH/AOAzf416vRR9Zpf8+0H1Wr/z9Z5R/wALA8Vf8+0f/gM3 +NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8Vf8APtH/AOAzf40f8LA8Vf8A PtH/AOAzf416vRR9Zpf8+0H1Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vR R9Zpf8+0H1Wr/wA/Wf/Z --------------070706040308080108020401-- --------------090109060801020505040500-- --===============1141629512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1141629512==-- From dime-bounces@ietf.org Tue Jul 24 06:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDI1x-0004pt-1d; Tue, 24 Jul 2007 06:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDI1v-0004po-Va for dime@ietf.org; Tue, 24 Jul 2007 06:54:15 -0400 Received: from mglblrmail.mgl.com ([61.95.163.15] helo=mglblrmail.blr.mgl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDI1t-0003Rs-S4 for dime@ietf.org; Tue, 24 Jul 2007 06:54:15 -0400 Received: from [172.16.25.60] ([172.16.25.60]) by mglblrmail.blr.mgl.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jul 2007 16:24:09 +0530 Message-ID: <46A5DA46.9040005@mgl.com> Date: Tue, 24 Jul 2007 16:23:58 +0530 From: Oviaprasad D User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Balamurugan T, TLS-Chennai" , dime@ietf.org Subject: Re: [Dime] Clarification regarding Error code 4003.(Election lost) References: <66E8AEE9980BB44CA5FCAD39EBA56AC601DA3533@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601DA3533@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-OriginalArrivalTime: 24 Jul 2007 10:54:09.0995 (UTC) FILETIME=[F6C6F1B0:01C7CDE0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1100775507==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1100775507== Content-Type: multipart/alternative; boundary="------------090501090903060400000302" This is a multi-part message in MIME format. --------------090501090903060400000302 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi Bala Sorry for the late reply. As per RFC 3588 the state machine shows at the Responder side Once it win the election its Initiator Disconnects and Responder will=20 send CEA and the connection is open for further communication. please refer bellow. =20 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open at the same time whoever receives CEA(ie Initiator of the other end)=20 should disconnects Responder and keep Initiator connection for further communication. This is more=20 than enough I mean no need to send CEA with error code saying election Lost. please refer the state=20 machine bellow. I-Rcv-CEA R-Disc I-Open The state machine says both I-Disc and R-Disc happens hence the other=20 connection is close and no use of error code 4003. but if you see section 7.1.4 7.1.4. Transient Failures ELECTION_LOST 4003 The peer has determined that it has lost the election process and has therefore disconnected the transport connection. The peer who lost the election can convey with error code=20 ELECTION_LOST in his CEA. Since RFC is not candidate anything about who is need to send this is=20 upto Implementation specific we can follow either of above this is my view if I am wrong please=20 correct me. regards Oviya Balamurugan T, TLS-Chennai wrote: > Hi Oviys, > > Thanks for your reply. > > In Peer state FSm, > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > The above has no glue to send the CEA send with error code in Actio= n function. > It simply say I-Disc. > > Regards, > Bala > > > -----Original Message----- > From: Oviaprasad D [mailto:oviaprasad.d@mgl.com] > Sent: Thursday, July 19, 2007 11:45 AM > To: Balamurugan T, TLS-Chennai > Subject: Re: [Dime] Clarification regarding Error code 4003.(Election > lost) > > > Hi Bala > As per the RFC 3588 [Page 66] Sec 5.6 says > =20 > > A CER message is always sent on the initiating connection immediatel= y > after the connection request is successfully completed. In the case > of an election, one of the two connections will shut down. The > responder connection will survive if the Origin-Host of the local > Diameter entity is higher than that of the peer; the initiator > connection will survive if the peer's Origin-Host is higher. > > > Basically the Origin-Host of Initiator and the peer compared, the=20 > Higher > of the responder connection will survive that is sent CEA(port) and=20 > close his > CER (port)connection by sending ELECTION_LOST 4003. > > Hope this solve your issue. > > regards > Oviys > > > > Balamurugan T, TLS-Chennai wrote: > =20 >> Hi All, >> >> I need some clarification regarding Error code 4003. >> >> RFC says " ELECTION_LOST 4003 The peer has determined that it has= =20 >> lost the election process and has >> therefore disconnected the transport connection. " >> >> In Peer state machine, the Initiator of a connection disconnects=20 >> it on election win and sending CEA over responding >> >> connection. Do we need to send CEA in Initiated connection before=20 >> closing the connection?. If the answer is no, >> which CEA will add this error code. >> =20 >> Can anyone explain the actual usage of this error code. >> >> Thanks in Advance, >> Bala >> >> >> >> >> >> ----------------------------------------------------------------------= -- >> >> DISCLAIMER: >> ----------------------------------------------------------------------= ------------------------------------------------- >> >> The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. >> It shall not attach any liability on the originator or HCL or its affi= liates. Any views or opinions presented in=20 >> this email are solely those of the author and may not necessarily refl= ect the opinions of HCL or its affiliates. >> Any form of reproduction, dissemination, copying, disclosure, modifica= tion, distribution and / or publication of=20 >> this message without the prior written consent of the author of this e= -mail is strictly prohibited. If you have >> received this email in error please delete it and notify the sender im= mediately. Before opening any mail and=20 >> attachments please check them for viruses and defect. >> >> ----------------------------------------------------------------------= ------------------------------------------------- >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> =20 >> =20 > > > > EMAIL DISCLAIMER : This email and any files transmitted with it are con= fidential and intended solely for the use of the individual or entity to = whom they are addressed. Any unauthorised distribution or copying is stri= ctly prohibited. If you receive this transmission in error, please notify= the sender by reply email and then destroy the message. Opinions, conclu= sions and other information in this message that do not relate to officia= l business of Mascon shall be understood to be neither given nor endorsed= by Mascon. Any information contained in this email, when addressed to Ma= scon clients is subject to the terms and conditions in governing client c= ontract. > > Whilst Mascon takes steps to prevent the transmission of viruses via e-= mail, we can not guarantee that any email or attachment is free from comp= uter viruses and you are strongly advised to undertake your own anti-viru= s precautions. Mascon grants no warranties regarding performance, use or = quality of any e-mail or attachment and undertakes no liability for loss = or damage, howsoever caused.=20 > > > > =20 EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.=0A=0AWhilst Mascon takes steps to prevent the transmission of viru= ses via e-mail, we can not guarantee that any email or attachment is free= from computer viruses and you are strongly advised to undertake your own= anti-virus precautions. Mascon grants no warranties regarding performanc= e, use or quality of any e-mail or attachment and undertakes no liability= for loss or damage, howsoever caused. =0A=0A --------------090501090903060400000302 Content-Type: text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi Bala
    Sorry for the late reply.

As per RFC 3588 the state machine shows at the Responder side
Once it win the election its Initiator Disconnects and Responder will send CEA and the connection
is open for further communication. please refer bellow.
 
   Wait-Returns     Win-Election  = ;   I-Disc,R-Snd-CEA R-Open

at the same time whoever receives CEA(ie Initiator of the other end) should disconnects Responder
and keep Initiator connection for further communication.  This is mo= re than enough I mean no need to
send CEA with error code saying election Lost. please refer the state machine bellow.

            &= nbsp;       I-Rcv-CEA   &nbs= p;    R-Disc       &nbs= p;   I-Open

The state machine says both I-Disc and R-Disc happens hence the other connection is close and no use of
error code 4003.

but if you see section 7.1.4

<rfc>
7.1.4.  Transient Failures

ELECTION_LOST          =             4003       The peer has determined that it has lost t= he election process and
      has therefore disconnected the transport c= onnection.
</rfc>

    The peer who lost the election can convey with error c= ode ELECTION_LOST in his CEA.
Since RFC is not candidate anything about who is need to send this is upto Implementation specific
we can follow either of above this is my view if I am wrong please correct me.


regards
Oviya


Balamurugan T, TLS-Chennai wrote: 
Hi Oviys,

   Thanks for your reply.

   In Peer state FSm,

     Wait-Returns     Win-Election     I-Disc,R-Snd-CEA R-Open

    The above has no glue to send the CEA send with error code in Action =
function.
    It simply say I-Disc.

Regards,
Bala


-----Original Message-----
From: Oviaprasad D [mailto:oviaprasad.d@mgl.com]
Sent: Thursday, July 19, 2007 11:45 AM
To: Balamurugan T, TLS-Chennai
Subject: Re: [Dime] Clarification regarding Error code 4003.(Election
lost)


Hi Bala
    As per the RFC 3588 [Page 66] Sec 5.6 says
<begin quote> =20

   A CER message is always sent on the initiating connection immediately
   after the connection request is successfully completed.  In the case
   of an election, one of the two connections will shut down.  The
   responder connection will survive if the Origin-Host of the local
   Diameter entity is higher than that of the peer; the initiator
   connection will survive if the peer's Origin-Host is higher.
<end quote>

    Basically the Origin-Host of Initiator and the peer compared, the=20
Higher
of the responder connection will survive that is sent CEA(port) and=20
close his
CER (port)connection by sending ELECTION_LOST 4003.

Hope this solve your issue.

regards
Oviys



Balamurugan T, TLS-Chennai wrote:
  
Hi All,

    I need some clarification regarding Error code 4003.

    RFC says " ELECTION_LOST 4003  The peer has determined that it has=20
lost the election process and has
    therefore disconnected the transport connection. "

    In Peer state machine, the Initiator of a connection disconnects=20
it on election win and sending CEA over responding

    connection. Do we need to send CEA in Initiated connection before=20
closing the connection?. If the answer is no,
    which CEA will add this error code.
=20
    Can anyone explain the actual   usage of this error code.

Thanks in Advance,
Bala





------------------------------------------------------------------------

DISCLAIMER:
-------------------------------------------------------------------------=
----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and in=
tended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affilia=
tes. Any views or opinions presented in=20
this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modificatio=
n, distribution and / or publication of=20
this message without the prior written consent of the author of this e-ma=
il is strictly prohibited. If you have
received this email in error please delete it and notify the sender immed=
iately. Before opening any mail and=20
attachments please check them for viruses and defect.

-------------------------------------------------------------------------=
----------------------------------------------
------------------------------------------------------------------------

_______________________________________________
DiME mailing list
DiME@=
ietf.org
https://www1.ietf.org/mailman/listinfo/dime
 =20
    



EMAIL DISCLAIMER : This email and any files transmitted with it are confi=
dential and intended solely for the use of the individual or entity to wh=
om they are addressed. Any unauthorised distribution or copying is strict=
ly prohibited. If you receive this transmission in error, please notify t=
he sender by reply email and then destroy the message. Opinions, conclusi=
ons and other information in this message that do not relate to official =
business of Mascon shall be understood to be neither given nor endorsed b=
y Mascon. Any information contained in this email, when addressed to Masc=
on clients is subject to the terms and conditions in governing client con=
tract.

Whilst Mascon takes steps to prevent the transmission of viruses via e-ma=
il, we can not guarantee that any email or attachment is free from comput=
er viruses and you are strongly advised to undertake your own anti-virus =
precautions. Mascon grants no warranties regarding performance, use or qu=
ality of any e-mail or attachment and undertakes no liability for loss or=
 damage, howsoever caused.=20

EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.
=0A
=0AWhilst Mascon takes steps to prevent the transmission= of viruses via e-mail, we can not guarantee that any email or attachment= is free from computer viruses and you are strongly advised to undertake = your own anti-virus precautions. Mascon grants no warranties regarding pe= rformance, use or quality of any e-mail or attachment and undertakes no l= iability for loss or damage, howsoever caused.
=0A
=0A

--------------090501090903060400000302-- --===============1100775507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1100775507==-- From dime-bounces@ietf.org Tue Jul 24 11:15:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM74-0008SL-80; Tue, 24 Jul 2007 11:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM72-0008Lk-7I for dime@ietf.org; Tue, 24 Jul 2007 11:15:48 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDM6v-00017i-Us for dime@ietf.org; Tue, 24 Jul 2007 11:15:47 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6OFEwdu007122; Tue, 24 Jul 2007 11:14:58 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46A61772.2040902@tari.toshiba.com> Date: Tue, 24 Jul 2007 11:14:58 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Oviaprasad D Subject: Re: [Dime] Reg. the "E" bit for the Protocol Error References: <66E8AEE9980BB44CA5FCAD39EBA56AC601E439BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46A5D231.9040502@mgl.com> In-Reply-To: <46A5D231.9040502@mgl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l6OFEwdu007122 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org If you guys would like to review the revised Sec 7. of rfc3588bis-05,=20 then that would be useful as well ... > Hi Arun > As per Rfc bellow quote tells the reason why E-bit set only for=20 > protocol error > > 7. Error Handling > > There are two different types of errors in Diameter; protocol and > application errors. A protocol error is one that occurs at the base > protocol level, and MAY require per hop attention (e.g., message > routing error). Application errors, on the other hand, generally > occur due to a problem with a function specified in a Diameter > application (e.g., user authentication, Missing AVP). > > Also I will suggest you to see the same section and Figure 8 provides=20 > an example > for Application errors not sets E-bit. > > > regards > Oviya > > Arun Santhanam, TLS-Chennai wrote: >> >> Hi Victor, >> >> I have a Query with respect to =93E=94 bit for protocol Error=92s. >> >> Why =93E=94 bit is set only for the Protocol Errors and not in general= =20 >> for all Errors Responses? >> >> As per RFC all 3xxx range errors will be considered as protocol=20 >> error, then what is the Significance of the =93E=94 bit? >> >> *Thanks & Regards* >> >> *Arun Santhanam* >> >> Lead Engineer- VOIP >> >> *HCL Technologies Ltd*. >> >> No 8, Mth Road Ambattur Industial estate >> >> Chennai (T.N) 600058 >> >> Tel: +91-044-439672000 Extn. (7278) >> >> Direct: +91-044-43967278 >> >> Mob: +91-9841951234 >> >> www.hcltech.com >> >> *www.hcl.in* >> >> DISCLAIMER: >> ----------------------------------------------------------------------= ------------------------------------------------- >> >> The contents of this e-mail and any attachment(s) are confidential=20 >> and intended for the named recipient(s) only. >> It shall not attach any liability on the originator or HCL or its=20 >> affiliates. Any views or opinions presented in >> this email are solely those of the author and may not necessarily=20 >> reflect the opinions of HCL or its affiliates. >> Any form of reproduction, dissemination, copying, disclosure,=20 >> modification, distribution and / or publication of >> this message without the prior written consent of the author of this=20 >> e-mail is strictly prohibited. If you have >> received this email in error please delete it and notify the sender=20 >> immediately. Before opening any mail and >> attachments please check them for viruses and defect. >> >> ----------------------------------------------------------------------= ------------------------------------------------- >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> =20 > > -----------------------------------------------------------------------= - > EMAIL DISCLAIMER : This email and any files transmitted with it are=20 > confidential and intended solely for the use of the individual or=20 > entity to whom they are addressed. Any unauthorised distribution or=20 > copying is strictly prohibited. If you receive this transmission in=20 > error, please notify the sender by reply email and then destroy the=20 > message. Opinions, conclusions and other information in this message=20 > that do not relate to official business of Mascon shall be understood=20 > to be neither given nor endorsed by Mascon. Any information contained=20 > in this email, when addressed to Mascon clients is subject to the=20 > terms and conditions in governing client contract. > > Whilst Mascon takes steps to prevent the transmission of viruses via=20 > e-mail, we can not guarantee that any email or attachment is free from=20 > computer viruses and you are strongly advised to undertake your own=20 > anti-virus precautions. Mascon grants no warranties regarding=20 > performance, use or quality of any e-mail or attachment and undertakes=20 > no liability for loss or damage, howsoever caused. > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 24 12:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2R-0002hw-JA; Tue, 24 Jul 2007 12:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2N-0002gu-8a; Tue, 24 Jul 2007 12:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDN2M-00032I-Q3; Tue, 24 Jul 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9789B26EB3; Tue, 24 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005W1-Cc; Tue, 24 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-02.txt Pages : 19 Date : 2007-7-24 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-app-design-guide-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-app-design-guide-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-24112909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-24112909.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jul 24 12:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNLY-0007xa-JS; Tue, 24 Jul 2007 12:34:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNLX-0007wq-GV for dime@ietf.org; Tue, 24 Jul 2007 12:34:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDNLX-00089R-3J for dime@ietf.org; Tue, 24 Jul 2007 12:34:51 -0400 Received: (qmail invoked by alias); 24 Jul 2007 16:34:49 -0000 Received: from dhcp-1462.ietf69.org (EHLO [130.129.20.98]) [130.129.20.98] by mail.gmx.net (mp041) with SMTP; 24 Jul 2007 18:34:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197S+0k3BJ7tzK8VFWIj3NKlg+NSDHzIQTiXObUaW 5PiEgzqLPuC1LG Message-ID: <46A62A2A.8000002@gmx.net> Date: Tue, 24 Jul 2007 18:34:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] Meeting on Quality of Service for Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, the authors of the Diameter QoS draft plan to meet and to chat about the open issues of the document. If someone else is interested to participate in this discussion please add your name and your preference for a date here: http://www.doodle.ch/dpKtdti79X9k Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 24 16:56:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRQc-0007EL-CW; Tue, 24 Jul 2007 16:56:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRQa-0007Ck-EL for dime@ietf.org; Tue, 24 Jul 2007 16:56:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDRQZ-0006er-QV for dime@ietf.org; Tue, 24 Jul 2007 16:56:20 -0400 Received: (qmail invoked by alias); 24 Jul 2007 20:56:18 -0000 Received: from dhcp-1462.ietf69.org (EHLO [130.129.20.98]) [130.129.20.98] by mail.gmx.net (mp042) with SMTP; 24 Jul 2007 22:56:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19N7alIeQNNUYoLUSxx4EQ/9xvaQ3Xq3V7isjFRLC Ou72rNnhDJHiM0 Message-ID: <46A66773.8080301@gmx.net> Date: Tue, 24 Jul 2007 22:56:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Dime] Diameter QoS Discussion: 26th July 2007, 7-8am X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We are going to meet at the IETF Registration Desk _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 25 11:23:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDii3-0002OS-Ct; Wed, 25 Jul 2007 11:23:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDii1-0002OE-TF for dime@ietf.org; Wed, 25 Jul 2007 11:23:29 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDii1-0006Fk-E3 for dime@ietf.org; Wed, 25 Jul 2007 11:23:29 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 08:23:28 -0700 Message-ID: <46A76AE5.5090909@azairenet.com> Date: Wed, 25 Jul 2007 08:23:17 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 15:23:28.0199 (UTC) FILETIME=[C03AF570:01C7CECF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Dime] Review of draft-ietf-dime-mip6-split-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I reviewed draft-ietf-dime-mip6-split-04.txt recently. The document needs a lot of work. At a high level, I suggest splitting the document into two. One document to address the use of IKEv2/IPsec with MIPv6 and the other to address the use of RFC 4285 with MIPv6. There are numerous reasons for this. The document seems to define a new app-id for use only when RFC 4285 is used. But throughout the document, it seems to indicate that the AAA servers must support this app-id and indicate support for it. There are few places in the document which says for use with IKEv2/IPsec, the Diameter EAP application is re-used. No new app-id. The second issue is process related. RFC 4285 is Informational. If this document needs to be on the Standards Track, it can't have normative dependency on RFC 4285. So you are better off with Dime extensions for RFC 4285 being in a separate Informational document. This document only addresses the use of EAP-based authentication between the mobile node and the home agent. This is not adequate. RFC 4877 says other authentication methods are possible, more specifically the use of pre-shared keys and certificates for IKEv2 authentication. The HA - AAA interface must support delivering the shared key, that can be used for IKEv2 authentication, at the minimum. This would need some extensions. Obviously the Diameter EAP application cannot be used. There are a couple of sentences about support for accounting on the home agent. I understand having text in the document that says the HA - AAA interface must provide accounting support. But the document says the HA must support accounting and must collect "accounting records". :) Regarding support for RFC 4285, I don't understand how the AVPs from MIPv4 Diameter application can be re-used. For example, the MIP-MN-to-HA-MSA talks about a nonce. Will the timestamp from the RFC 4285 binding update be used as a nonce? In MIPv4, the nonce is sent from the AAA server to the mobile node. There is no similar thing in RFC 4285. (I could be wrong). You would need to define a new AVP that carries the MIPv6 home address, since we now have a 128-bit address. The MIP-Mobile-Node-Address from 4004 cannot be used. Vijay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 25 11:28:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDimV-0005lo-PB; Wed, 25 Jul 2007 11:28:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDimV-0005lj-0Z for dime@ietf.org; Wed, 25 Jul 2007 11:28:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDimU-0006Lc-4z for dime@ietf.org; Wed, 25 Jul 2007 11:28:06 -0400 Received: (qmail invoked by alias); 25 Jul 2007 15:28:04 -0000 Received: from dhcp-15f4.ietf69.org (EHLO [130.129.21.244]) [130.129.21.244] by mail.gmx.net (mp034) with SMTP; 25 Jul 2007 17:28:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qJKB0s3aqTKskQBnfNpHQsF2R7NrsTRRk7z/yT8 KTyOKdvoCEMujS Message-ID: <46A76C06.2050406@gmx.net> Date: Wed, 25 Jul 2007 17:28:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Dime] Review of draft-ietf-dime-mip6-split-04 References: <46A76AE5.5090909@azairenet.com> In-Reply-To: <46A76AE5.5090909@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thanks for the review. I will respond to your detailed comments a bit later. I also noticed that including the IKEv2/IPsec and RFC 4285 made the document far more complex to read and understand. Vijay Devarapalli wrote: > Hello, > > I reviewed draft-ietf-dime-mip6-split-04.txt recently. The document > needs a lot of work. > > At a high level, I suggest splitting the document into two. One > document to address the use of IKEv2/IPsec with MIPv6 and the other > to address the use of RFC 4285 with MIPv6. There are numerous > reasons for this. The document seems to define a new app-id for use > only when RFC 4285 is used. But throughout the document, it seems to > indicate that the AAA servers must support this app-id and indicate > support for it. There are few places in the document which says for > use with IKEv2/IPsec, the Diameter EAP application is re-used. No > new app-id. > > The second issue is process related. RFC 4285 is Informational. If > this document needs to be on the Standards Track, it can't have > normative dependency on RFC 4285. So you are better off with Dime > extensions for RFC 4285 being in a separate Informational document. > > This document only addresses the use of EAP-based authentication > between the mobile node and the home agent. This is not adequate. > RFC 4877 says other authentication methods are possible, more > specifically the use of pre-shared keys and certificates for IKEv2 > authentication. The HA - AAA interface must support delivering the > shared key, that can be used for IKEv2 authentication, at the > minimum. This would need some extensions. Obviously the Diameter EAP > application cannot be used. > > There are a couple of sentences about support for accounting on the > home agent. I understand having text in the document that says > the HA - AAA interface must provide accounting support. But the > document says the HA must support accounting and must collect > "accounting records". :) > > Regarding support for RFC 4285, I don't understand how the AVPs >> from MIPv4 Diameter application can be re-used. For example, the > MIP-MN-to-HA-MSA talks about a nonce. Will the timestamp from the > RFC 4285 binding update be used as a nonce? In MIPv4, the nonce is > sent from the AAA server to the mobile node. There is no similar > thing in RFC 4285. (I could be wrong). You would need to define a > new AVP that carries the MIPv6 home address, since we now have a > 128-bit address. The MIP-Mobile-Node-Address from 4004 cannot be > used. > > Vijay > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 25 11:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDioo-0006Lc-M2; Wed, 25 Jul 2007 11:30:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDion-0006Kv-6E for dime@ietf.org; Wed, 25 Jul 2007 11:30:29 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDioi-0006Nz-GH for dime@ietf.org; Wed, 25 Jul 2007 11:30:29 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id AE69937C087 for ; Wed, 25 Jul 2007 20:54:29 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id 775FE37C029for ; Wed, 25 Jul 2007 20:54:29 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 21:00:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jul 2007 20:59:27 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601E70250@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding election process Thread-Index: AcfO0JaUrfTAWcBvSU2FVIManpJkMA== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 25 Jul 2007 15:30:19.0215 (UTC) FILETIME=[B53705F0:01C7CED0] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-11.8800 TC:1F TRN:70 TV:3.6.1039(15322.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Subject: [Dime] Clarification regarding election process X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1828597620==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1828597620== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CED0.989E5435" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CED0.989E5435 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I need some clarification regarding the statements for election process. =20 (1) In 5.6.4. The Election Process =20 "The election is performed on the responder. The responder compares the Origin-Host received in the CER sent by its peer with its own Origin-Host. If the local Diameter entity's Origin-Host is higher than the peer's, a Win-Election event is issued locally." =20 =20 (2)In 5.6 Peer State Machine =20 "The responder connection will survive if the Origin-Host of the local Diameter entity is higher than that of the peer; the initiator connection will survive if the peer's Origin-Host is higher." =20 =20 But In state machine, =20 state event action next state ----------------------------------------------------------------- Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open =20 =20 According to this the responder who wins the election has to disconnect his I(initiated) connection. This seems to be contradict with point (2). =20 Also section 7.1.4 says, =20 "ELECTION_LOST 4003 The peer has determined that it has lost the election process and has therefore disconnected the transport connection." =20 =20 Please clarify, which one is correct. =20 Thanks in advance, Bala DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7CED0.989E5435 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

      I need some clarification= regarding the statements for election process.

    

     =
 (1) In 5.6.4.  The=
 Election Process
 
 =
    “The election is performed on the responder. =
 The responder compares
  =
 the Origin-Host received in the CER sent by its peer with its=
 own
  =
 Origin-Host.  If the local Diameter entity's Origin-Host is=
 higher
   than the peer's, a=
 Win-Election event is issued=
 locally.”
 
 
  =
 (2)In 5.6  Peer State=
 Machine
 
      “The  responder connection will survive if=
 the Origin-Host of the=
 local
   Diameter entity is=
 higher than that of the peer; the=
 initiator
  =
 connection will survive if the peer's Origin-Host is=
 higher.”
 
 
  =
 But In state machine,
 
   =
    state        &nb=
sp;  =
 event           &nb=
sp;  action         next=
 state
  =
 -----------------------------------------------------------------
  =
  Wait-Returns    =
 Win-Election     I-Disc,R-Snd-CEA=
 R-Open
  =

 

      According to this the responder who= wins the election  has to disconnect his I(initiated)= connection.

      This seems to be contradict with= point (2).

 =

     = Also section 7.1.4 says,

 

    =
 “ELECTION_LOST         =
            =
 4003
      The peer has=
 determined that it has lost the election process=
 and
      has therefore=
 disconnected the transport=
 connection.”

 

 

      Please clarify, which one is= correct.

 

Thanks in advance,

Bala

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7CED0.989E5435-- --===============1828597620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1828597620==-- From dime-bounces@ietf.org Wed Jul 25 11:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDizB-0007PO-El; Wed, 25 Jul 2007 11:41:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiz9-0007PE-Q2 for dime@ietf.org; Wed, 25 Jul 2007 11:41:11 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDiz8-0006g0-FL for dime@ietf.org; Wed, 25 Jul 2007 11:41:11 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 2584F36002C for ; Wed, 25 Jul 2007 21:09:06 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id 040AF360003for ; Wed, 25 Jul 2007 21:09:06 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 21:11:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jul 2007 21:11:03 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601E70263@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding the I-PeerDisc event Thread-Index: AcfO0jT6VYDSkugITdeZ8/1Gt1YWvg== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 25 Jul 2007 15:41:07.0862 (UTC) FILETIME=[37D6B360:01C7CED2] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-4.4939 TC:1F TRN:48 TV:3.6.1039(15322.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Subject: [Dime] Clarification regarding the I-PeerDisc event X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0975066585==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0975066585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CED2.37BCA467" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CED2.37BCA467 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 According to RFC 3588, Peer state machine receives I-PeerDisc event in wait-returns state. If one=20 peer closes the connection other side peer will receive (R-PeerDisc). =20 Any one, please clarify the scenario in which the I-PeerDisc event is possible. =20 Regards, Bala =20 =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7CED2.37BCA467 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

      According to RFC 3588,= Peer state machine receives I-PeerDisc event in wait-returns state.= If one

      peer closes the= connection other side peer will receive (R-PeerDisc).

 

      Any one, please clarify= the scenario in which the I-PeerDisc event is possible.

 

Regards,

Bala

     =

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7CED2.37BCA467-- --===============0975066585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0975066585==-- From dime-bounces@ietf.org Wed Jul 25 11:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDizO-0007UD-Te; Wed, 25 Jul 2007 11:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDizN-0007U5-4c for dime@ietf.org; Wed, 25 Jul 2007 11:41:25 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDizL-00022m-Ku for dime@ietf.org; Wed, 25 Jul 2007 11:41:25 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 17:41:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-ietf-dime-mip6-split-04 Date: Wed, 25 Jul 2007 17:41:20 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F2732E@SEHAN021MB.tcad.telia.se> In-Reply-To: <46A76AE5.5090909@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-mip6-split-04 Thread-Index: AcfOz8U8sJFQZ0clSUWkTuPimQyqSAAAWNFw From: To: , X-OriginalArrivalTime: 25 Jul 2007 15:41:22.0455 (UTC) FILETIME=[40896A70:01C7CED2] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I do agree most of the Vijay's findings here. The addition of=20 RFC4285 did mess up the doc for good. Maybe a split of the draft would be the way to go. RFC4004 MIP-Mobile-Node-Address can be used actually. The AVP type is Address that can carry both IPv4 or IPv6 addresses. The RFC3588 encoding provides native support for this. Cheers, Jouni > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: 25. hein=E4kuuta 2007 18:23 > To: dime@ietf.org > Subject: [Dime] Review of draft-ietf-dime-mip6-split-04 >=20 >=20 > Hello, >=20 > I reviewed draft-ietf-dime-mip6-split-04.txt recently. The=20 > document needs a lot of work. >=20 > At a high level, I suggest splitting the document into two.=20 > One document to address the use of IKEv2/IPsec with MIPv6 and=20 > the other to address the use of RFC 4285 with MIPv6. There=20 > are numerous reasons for this. The document seems to define a=20 > new app-id for use only when RFC 4285 is used. But throughout=20 > the document, it seems to indicate that the AAA servers must=20 > support this app-id and indicate support for it. There are=20 > few places in the document which says for use with=20 > IKEv2/IPsec, the Diameter EAP application is re-used. No new app-id. >=20 > The second issue is process related. RFC 4285 is=20 > Informational. If this document needs to be on the Standards=20 > Track, it can't have normative dependency on RFC 4285. So you=20 > are better off with Dime extensions for RFC 4285 being in a=20 > separate Informational document. >=20 > This document only addresses the use of EAP-based=20 > authentication between the mobile node and the home agent.=20 > This is not adequate. > RFC 4877 says other authentication methods are possible, more=20 > specifically the use of pre-shared keys and certificates for=20 > IKEv2 authentication. The HA - AAA interface must support=20 > delivering the shared key, that can be used for IKEv2=20 > authentication, at the minimum. This would need some=20 > extensions. Obviously the Diameter EAP application cannot be used. >=20 > There are a couple of sentences about support for accounting=20 > on the home agent. I understand having text in the document=20 > that says the HA - AAA interface must provide accounting=20 > support. But the document says the HA must support accounting=20 > and must collect "accounting records". :) >=20 > Regarding support for RFC 4285, I don't understand how the=20 > AVPs from MIPv4 Diameter application can be re-used. For=20 > example, the MIP-MN-to-HA-MSA talks about a nonce. Will the=20 > timestamp from the RFC 4285 binding update be used as a=20 > nonce? In MIPv4, the nonce is sent from the AAA server to the=20 > mobile node. There is no similar thing in RFC 4285. (I could=20 > be wrong). You would need to define a new AVP that carries=20 > the MIPv6 home address, since we now have a 128-bit address.=20 > The MIP-Mobile-Node-Address from 4004 cannot be used. >=20 > Vijay >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 25 16:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnwx-0003tc-UB; Wed, 25 Jul 2007 16:59:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnww-0003tW-O3 for dime@ietf.org; Wed, 25 Jul 2007 16:59:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDnww-0000vB-73 for dime@ietf.org; Wed, 25 Jul 2007 16:59:14 -0400 Received: (qmail invoked by alias); 25 Jul 2007 20:59:12 -0000 Received: from dhcp-15f4.ietf69.org (EHLO [130.129.21.244]) [130.129.21.244] by mail.gmx.net (mp004) with SMTP; 25 Jul 2007 22:59:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18LR44b/+ULa3e7XiM5E9zvEeUjx41xCB+Pr2Psby dwS8z+AQm8RAkC Message-ID: <46A7B9A1.3050100@gmx.net> Date: Wed, 25 Jul 2007 22:59:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: Subject: [Dime] Slides for DIME Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Please send us your slides for the DIME meeting! _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 25 17:22:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoIz-0005pj-U2; Wed, 25 Jul 2007 17:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoIx-0005ns-LF for dime@ietf.org; Wed, 25 Jul 2007 17:21:59 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDoIv-0004qC-DL for dime@ietf.org; Wed, 25 Jul 2007 17:21:59 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l6PLLosr053879 for ; Wed, 25 Jul 2007 23:21:50 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jul 2007 23:21:47 +0200 Message-ID: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99A== From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 25 Jul 2007 23:21:50 +0200 (CEST) X-Spam-Status: No, score=-152.1 required=4.7 tests=ALL_TRUSTED,BAYES_00, HTML_40_50, HTML_MESSAGE, USER_IN_BLACKLIST, USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3764/Wed Jul 25 21:13:25 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Dime] The usage of ACR/ACA for the QoS application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784640308==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0784640308== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF01.D09E567A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF01.D09E567A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All,=20 This might be an uneducated question from someone that just now have read the draft, but the usage of the ACR/ACA messages for the QoS application confuses me somewhat. To my understanding the current draft mandates the use of those messages and thereby manadate the authorizing entity to also handle accounting. I'm not sure that's always the case. E.g. in the 3GPP architecture the PCRF and the online charging system are possible to instasiate separately in a physical deplyment. If my understanding is correct I would then actually suggest to allow for separating authorization and accounting in the QoS application. Comments/thoughts? Again, I may miss the point completely here and then I clearly need someone to enlight me ;-).=20 Best regards,=20 Ulf=20 ------_=_NextPart_001_01C7CF01.D09E567A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The usage of ACR/ACA for the QoS application

All,

This might be an = uneducated question from someone that just now have read the draft, but = the usage of the ACR/ACA messages for the QoS application confuses me = somewhat. To my understanding the current draft mandates the use of = those messages and thereby manadate the authorizing entity to also = handle accounting. I'm not sure that's always the case. E.g. in the 3GPP = architecture the PCRF and the online charging system are possible to = instasiate separately in a physical deplyment. If my understanding is = correct I would then actually suggest to allow for separating = authorization and accounting in the QoS application. Comments/thoughts? = Again, I may miss the point completely here and then I clearly need = someone to enlight me ;-).

Best regards, =
Ulf

------_=_NextPart_001_01C7CF01.D09E567A-- --===============0784640308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0784640308==-- From dime-bounces@ietf.org Thu Jul 26 02:07:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDwVd-0007YI-JJ; Thu, 26 Jul 2007 02:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDwVb-0007YA-QU for dime@ietf.org; Thu, 26 Jul 2007 02:07:35 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDwVb-0004r7-3R for dime@ietf.org; Thu, 26 Jul 2007 02:07:35 -0400 Received: by py-out-1112.google.com with SMTP id f31so1486495pyh for ; Wed, 25 Jul 2007 23:07:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=d9XVvu4tAHVGS78wj5gO1AMoRMBVrFdRK/Qyjz09Gudt3CCPungyEObDk1YoHlaA3NUyfx0lg4X5KVpYKnKKltNwBxOULYxaNARHUPJZPziq+eYJDbCa/oTk9g/dZ1MrEmjp2nt5lvZ77j6WfXzhgGt5p2bwZvE2a1rb3QljtVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KO306ScG1hhvbMRTMvZulGWWIwvBsTqzG80jtguAebDrkGPgXWGieSPw0xKO/oHgQM6+PWNFa8883oz19cit3KZV+xFsBP3XmKNc/MyQXkLTQd07Uy+wv2kVrW4V1jJ//00K8ihtdmijsjXKedTFu2Ouy3jfoa2w74+hkP6SaCM= Received: by 10.64.148.8 with SMTP id v8mr2394032qbd.1185430054273; Wed, 25 Jul 2007 23:07:34 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Wed, 25 Jul 2007 23:07:34 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 11:37:34 +0530 From: "Harish R Prabhu" To: dime@ietf.org Subject: Re: [Dime] Clarification regarding the I-PeerDisc event In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601E70263@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> MIME-Version: 1.0 References: <66E8AEE9980BB44CA5FCAD39EBA56AC601E70263@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1670018523==" Errors-To: dime-bounces@ietf.org --===============1670018523== Content-Type: multipart/alternative; boundary="----=_Part_138867_455954.1185430054225" ------=_Part_138867_455954.1185430054225 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Balamurugan, My understanding/interpretation of the situation is as follows: Look at Wait-Returns state from a node (lets say A) that initiates a transport connection. I-Peer-Disc event would probably mean peer has closed the transport connection that was initiated from A (due to election win at the other end perhaps?). In this case the same transport connection has to be marked closed by A also, that's what I-Disc does in this case. However, I tend to agree that the state machine description is very terse. Folks, please feel free to correct any discrepancies in the explanation. cheers, Harish On 7/25/07, Balamurugan T, TLS-Chennai wrote: > > Hi All, > > > > According to RFC 3588, Peer state machine receives *I-PeerDisc*event in > *wait-returns* state. If one > > peer closes the connection other side peer will receive > (R-PeerDisc). > > > > Any one, please clarify the scenario in which the I-PeerDisc event > is possible. > > > > Regards, > > Bala > > > > > DISCLAIMER: > > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > > ----------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > ------=_Part_138867_455954.1185430054225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Balamurugan,
My understanding/interpretation of the situation is as follows:
Look at Wait-Returns state from a node (lets say A) that initiates a transport connection. I-Peer-Disc event would probably mean peer has closed the transport connection that was initiated from A (due to election win at the other end perhaps?). In this case the same transport connection has to be marked closed by A also, that's what I-Disc does in this case. However, I tend to agree that the state machine description is very terse. Folks, please feel free to correct any discrepancies in the explanation.
cheers,
Harish

On 7/25/07, Balamurugan T, TLS-Chennai <tbalamurugan@hcl.in> wrote:

Hi All,

 

      According to RFC 3588, Peer state machine receives I-PeerDisc event in wait-returns state. If one

      peer closes the connection other side peer will receive (R-PeerDisc).

 

      Any one, please clarify the scenario in which the I-PeerDisc event is possible.

 

Regards,

Bala

     

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

------=_Part_138867_455954.1185430054225-- --===============1670018523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1670018523==-- From dime-bounces@ietf.org Thu Jul 26 10:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE41n-0006yP-Fx; Thu, 26 Jul 2007 10:09:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE41l-0006xt-Lg for dime@ietf.org; Thu, 26 Jul 2007 10:09:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE41k-0004uG-Tb for dime@ietf.org; Thu, 26 Jul 2007 10:09:17 -0400 Received: (qmail invoked by alias); 26 Jul 2007 14:09:15 -0000 Received: from dhcp-15f4.ietf69.org (EHLO [130.129.21.244]) [130.129.21.244] by mail.gmx.net (mp019) with SMTP; 26 Jul 2007 16:09:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19AkgN3pipAfrtBlXMpSDIvdWCb7XSzI1k90qKnLw /ulxIQRl+2FbFp Message-ID: <46A8AB0C.4060709@gmx.net> Date: Thu, 26 Jul 2007 16:09:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Dime] Slides missing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We still don't have slides for the following presentations: * Quality of Service - Quality of Service Parameters for Usage with the AAA Framework http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-parameters/ Moderator: Jouni Korhonen - Quality of Service Attributes for Diameter and RADIUS http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/ Moderator: Jouni Korhonen - Diameter QoS application http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-qos/ Moderator: Glen Zorn * Diameter Mobility - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction http://tools.ietf.org/wg/dime/draft-ietf-dime-mip6-integrated/ Moderator: Jouni Korhonen - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction http://tools.ietf.org/wg/dime/draft-ietf-dime-mip6-split/ Moderator: Gerardo Giaretta - Diameter Proxy Mobile IPv6: Support For Mobility Access Gateway and Local Mobility Anchor to Diameter Server Interaction http://tools.ietf.org/wg/dime/draft-korhonen-dime-pmip6-00.txt Presenter: Jouni Korhonen _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 15:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8uK-0002gG-Cx; Thu, 26 Jul 2007 15:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8uJ-0002g9-6p for dime@ietf.org; Thu, 26 Jul 2007 15:21:55 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IE8uH-0006tv-Ft for dime@ietf.org; Thu, 26 Jul 2007 15:21:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1185477706!16091086!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 20734 invoked from network); 26 Jul 2007 19:21:47 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-2.tower-119.messagelabs.com with SMTP; 26 Jul 2007 19:21:47 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l6QJLkUD014318 for ; Thu, 26 Jul 2007 12:21:46 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6QJHIfM006927 for ; Thu, 26 Jul 2007 14:17:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 15:17:16 -0400 Message-ID: In-Reply-To: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hA References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> From: "McCann Peter-A001034" To: "Ulf Bodin" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Ulf, The current draft puts some cost-information AVPs in the QAR, and the Authorizing Entity gets to see those before authorization. So, it just seems logical to me that the accounting should go to the same place. In theory, we could put an AVP into the QAR containing the destination for subsequent ACRs. However, it seems like the recipient of an ACR will want to verify that the session was indeed authorized, so this would imply some non-standard=20 interface between the two. All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use accounting in this way, and I don't see a good reason to break with that. -Pete Ulf Bodin wrote: > All, >=20 > This might be an uneducated question from someone that just now have > read the draft, but the usage of the ACR/ACA messages for the QoS > application confuses me somewhat. To my understanding the current > draft mandates the use of those messages and thereby manadate the > authorizing entity to also handle accounting. I'm not sure that's > always the case. E.g. in the 3GPP architecture the PCRF and the > online charging system are possible to instasiate separately in a > physical deplyment. If my understanding is correct I would then > actually suggest to allow for separating authorization and accounting > in the QoS application. Comments/thoughts? Again, I may miss the > point completely here and then I clearly need someone to enlight me > ;-). =20 >=20 > Best regards, > Ulf _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 15:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8wO-0004wk-Nq; Thu, 26 Jul 2007 15:24:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8wN-0004wO-C7 for dime@ietf.org; Thu, 26 Jul 2007 15:24:03 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE8wM-0005qZ-Iu for dime@ietf.org; Thu, 26 Jul 2007 15:24:03 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1185477841!3013881!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17654 invoked from network); 26 Jul 2007 19:24:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 26 Jul 2007 19:24:01 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6QJO08b021417 for ; Thu, 26 Jul 2007 12:24:00 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l6QJO0wr010410 for ; Thu, 26 Jul 2007 14:24:00 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6QJNxKo010397 for ; Thu, 26 Jul 2007 14:23:59 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 15:23:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hAAABfcHA= References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> From: "McCann Peter-A001034" To: "Ulf Bodin" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org McCann Peter-A001034 wrote: > Hi, Ulf, >=20 > The current draft puts some cost-information AVPs in the QAR, and the > Authorizing Entity gets to see those before authorization.=20 > So, it just seems logical to me that the accounting should go to the > same place.=20 >=20 > In theory, we could put an AVP into the QAR containing the Sorry, meant to say "into the QAA". > destination for subsequent ACRs. However, it seems like the > recipient of an ACR will want to verify that the session was indeed > authorized, so this would imply some non-standard interface between > the two. =20 >=20 > All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use > accounting in this way, and I don't see a good reason to break with > that. =20 >=20 > -Pete >=20 > Ulf Bodin wrote: >> All, >>=20 >> This might be an uneducated question from someone that just now have >> read the draft, but the usage of the ACR/ACA messages for the QoS >> application confuses me somewhat. To my understanding the current >> draft mandates the use of those messages and thereby manadate the >> authorizing entity to also handle accounting. I'm not sure that's >> always the case. E.g. in the 3GPP architecture the PCRF and the >> online charging system are possible to instasiate separately in a >> physical deplyment. If my understanding is correct I would then >> actually suggest to allow for separating authorization and >> accounting in the QoS application. Comments/thoughts? Again, I may >> miss the point completely here and then I clearly need someone to >> enlight me ;-).=20 >>=20 >> Best regards, >> Ulf >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 16:03:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9Z1-0003Eq-5Q; Thu, 26 Jul 2007 16:03:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9Z0-0003DX-35 for dime@ietf.org; Thu, 26 Jul 2007 16:03:58 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE9Yz-0006tn-CK for dime@ietf.org; Thu, 26 Jul 2007 16:03:58 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l6QK3npB064136 for ; Thu, 26 Jul 2007 22:03:49 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 22:03:48 +0200 Message-ID: <33656995C5C5094A983DE84DA649A924017F8E34@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hAAABfcHAAAQMIQA== References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 26 Jul 2007 22:03:49 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3779/Thu Jul 26 21:33:22 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Pete,=20 Thanks for the clearification. I'm however still a little confused. Looking at the credit control application I found that the accounting protocol and the credit control protocol can be used in parallel more or less in the manner I'm envisioning and how I understand the usage of the 3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP though and may be on thin ice here). From that I would have expected the QoS application to also allow for a similar parallelism. Or, is there a fundamental difference I have missed here? Best regards,=20 Ulf=20 -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: den 26 juli 2007 21:24 To: Ulf Bodin; dime@ietf.org Subject: RE: [Dime] The usage of ACR/ACA for the QoS application=20 McCann Peter-A001034 wrote: > Hi, Ulf, >=20 > The current draft puts some cost-information AVPs in the QAR, and the=20 > Authorizing Entity gets to see those before authorization. > So, it just seems logical to me that the accounting should go to the=20 > same place. >=20 > In theory, we could put an AVP into the QAR containing the Sorry, meant to say "into the QAA". > destination for subsequent ACRs. However, it seems like the recipient > of an ACR will want to verify that the session was indeed authorized,=20 > so this would imply some non-standard interface between > the two. =20 >=20 > All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use=20 > accounting in this way, and I don't see a good reason to break with=20 > that. >=20 > -Pete >=20 > Ulf Bodin wrote: >> All, >>=20 >> This might be an uneducated question from someone that just now have=20 >> read the draft, but the usage of the ACR/ACA messages for the QoS=20 >> application confuses me somewhat. To my understanding the current=20 >> draft mandates the use of those messages and thereby manadate the=20 >> authorizing entity to also handle accounting. I'm not sure that's=20 >> always the case. E.g. in the 3GPP architecture the PCRF and the=20 >> online charging system are possible to instasiate separately in a=20 >> physical deplyment. If my understanding is correct I would then=20 >> actually suggest to allow for separating authorization and accounting >> in the QoS application. Comments/thoughts? Again, I may miss the=20 >> point completely here and then I clearly need someone to enlight me=20 >> ;-). >>=20 >> Best regards, >> Ulf >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 16:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9rb-0002cv-69; Thu, 26 Jul 2007 16:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9rZ-0002cM-DF for dime@ietf.org; Thu, 26 Jul 2007 16:23:09 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE9rY-0008IR-Qk for dime@ietf.org; Thu, 26 Jul 2007 16:23:09 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6QKN51h015177 for ; Thu, 26 Jul 2007 15:23:05 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 15:23:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 15:23:04 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209ED@ILEXC2U01.ndc.lucent.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924017F8E34@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hAAABfcHAAAQMIQAAAmRGw References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com> <33656995C5C5094A983DE84DA649A924017F8E34@lulex02.ad.operax.com> From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 26 Jul 2007 20:23:06.0301 (UTC) FILETIME=[C66D5ED0:01C7CFC2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have similar confusion as Ulf. It looks like QoS authorization, accounting and credit control functions are mixed in this QoS application, and it is a bit awkward to mandate accounting server capability within an QoS application.=20 It seems in reality the accounting server and QoS authorization server are independent entities although they might be collocated if needed, and the credit and accounting permission may not be necessary to be prerequisite for QoS authorization. Would it be more flexible to separate the accounting server and credit control function from QoS authorization server/application?=20 Certainly, if some QoS info is needed for policy decision, it can be carried by an QoS message such as QAR/QIA to QoS authorization server instead of ACR. Regards, Dong =20 -----Original Message----- From: Ulf Bodin [mailto:Ulf.Bodin@operax.com]=20 Sent: Thursday, July 26, 2007 4:04 PM To: dime@ietf.org Subject: RE: [Dime] The usage of ACR/ACA for the QoS application=20 Hi Pete,=20 Thanks for the clearification. I'm however still a little confused. Looking at the credit control application I found that the accounting protocol and the credit control protocol can be used in parallel more or less in the manner I'm envisioning and how I understand the usage of the 3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP though and may be on thin ice here). From that I would have expected the QoS application to also allow for a similar parallelism. Or, is there a fundamental difference I have missed here? Best regards, Ulf=20 -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: den 26 juli 2007 21:24 To: Ulf Bodin; dime@ietf.org Subject: RE: [Dime] The usage of ACR/ACA for the QoS application=20 McCann Peter-A001034 wrote: > Hi, Ulf, >=20 > The current draft puts some cost-information AVPs in the QAR, and the=20 > Authorizing Entity gets to see those before authorization. > So, it just seems logical to me that the accounting should go to the=20 > same place. >=20 > In theory, we could put an AVP into the QAR containing the Sorry, meant to say "into the QAA". > destination for subsequent ACRs. However, it seems like the recipient > of an ACR will want to verify that the session was indeed authorized,=20 > so this would imply some non-standard interface between > the two. =20 >=20 > All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use=20 > accounting in this way, and I don't see a good reason to break with=20 > that. >=20 > -Pete >=20 > Ulf Bodin wrote: >> All, >>=20 >> This might be an uneducated question from someone that just now have=20 >> read the draft, but the usage of the ACR/ACA messages for the QoS=20 >> application confuses me somewhat. To my understanding the current=20 >> draft mandates the use of those messages and thereby manadate the=20 >> authorizing entity to also handle accounting. I'm not sure that's=20 >> always the case. E.g. in the 3GPP architecture the PCRF and the=20 >> online charging system are possible to instasiate separately in a=20 >> physical deplyment. If my understanding is correct I would then=20 >> actually suggest to allow for separating authorization and accounting >> in the QoS application. Comments/thoughts? Again, I may miss the=20 >> point completely here and then I clearly need someone to enlight me=20 >> ;-). >>=20 >> Best regards, >> Ulf >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 19:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECfE-0003v1-Ar; Thu, 26 Jul 2007 19:22:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECfD-0003uu-4C for dime@ietf.org; Thu, 26 Jul 2007 19:22:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IECfC-0002G2-FH for dime@ietf.org; Thu, 26 Jul 2007 19:22:35 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1185492153!10958311!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 18989 invoked from network); 26 Jul 2007 23:22:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-128.messagelabs.com with SMTP; 26 Jul 2007 23:22:33 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l6QNMWbY010349 for ; Thu, 26 Jul 2007 16:22:32 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l6QNISvl000858 for ; Thu, 26 Jul 2007 18:18:28 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 19:18:26 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D5209ED@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hAAABfcHAAAQMIQAAAmRGwAASzrHA= References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com><33656995C5C5094A983DE84DA649A924017F8E34@lulex02.ad.operax.com> <09C9068466B79E4C938DC7737562404D5209ED@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Dong, Ulf, The mechanism described in the draft is simple and self-contained, only referring to some AVPs defined by the credit control application. RFC 4006 is more complicated than necessary. We decided to include a simple, per-minute charging system that can support time of tarrif changes, allows the NE to specify the cost, and send the accounting records into the Diameter network. Section 5 is really simple and I think it provides all the functionality we need for QoS accounting. -Pete Sun, Dong (Dong) wrote: > I have similar confusion as Ulf. It looks like QoS authorization, > accounting and credit control functions are mixed in this QoS > application, and it is a bit awkward to mandate accounting server > capability within an QoS application. =20 >=20 > It seems in reality the accounting server and QoS authorization > server are independent entities although they might be collocated if > needed, and the credit and accounting permission may not be necessary > to be prerequisite for QoS authorization. Would it be more flexible > to separate the accounting server and credit control function from > QoS authorization server/application? =20 >=20 > Certainly, if some QoS info is needed for policy decision, it can be > carried by an QoS message such as QAR/QIA to QoS authorization server > instead of ACR. =20 >=20 > Regards, > Dong >=20 > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Thursday, July 26, 2007 4:04 PM > To: dime@ietf.org > Subject: RE: [Dime] The usage of ACR/ACA for the QoS application >=20 > Hi Pete, >=20 > Thanks for the clearification. I'm however still a little confused. > Looking at the credit control application I found that the accounting > protocol and the credit control protocol can be used in parallel more > or less in the manner I'm envisioning and how I understand the usage > of the 3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP > though and may be on thin ice here). From that I would have expected > the QoS application to also allow for a similar parallelism. Or, is > there a fundamental difference I have missed here? =20 >=20 > Best regards, > Ulf >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: den 26 juli 2007 21:24 > To: Ulf Bodin; dime@ietf.org > Subject: RE: [Dime] The usage of ACR/ACA for the QoS application >=20 > McCann Peter-A001034 wrote: >> Hi, Ulf, >>=20 >> The current draft puts some cost-information AVPs in the QAR, and the >> Authorizing Entity gets to see those before authorization. >> So, it just seems logical to me that the accounting should go to the >> same place.=20 >>=20 >> In theory, we could put an AVP into the QAR containing the >=20 > Sorry, meant to say "into the QAA". >=20 >> destination for subsequent ACRs. However, it seems like the >> recipient=20 >=20 >> of an ACR will want to verify that the session was indeed authorized, >> so this would imply some non-standard interface between >> the two. >>=20 >> All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use >> accounting in this way, and I don't see a good reason to break with >> that.=20 >>=20 >> -Pete >>=20 >> Ulf Bodin wrote: >>> All, >>>=20 >>> This might be an uneducated question from someone that just now have >>> read the draft, but the usage of the ACR/ACA messages for the QoS >>> application confuses me somewhat. To my understanding the current >>> draft mandates the use of those messages and thereby manadate the >>> authorizing entity to also handle accounting. I'm not sure that's >>> always the case. E.g. in the 3GPP architecture the PCRF and the >>> online charging system are possible to instasiate separately in a >>> physical deplyment. If my understanding is correct I would then >>> actually suggest to allow for separating authorization and >>> accounting=20 >=20 >>> in the QoS application. Comments/thoughts? Again, I may miss the >>> point completely here and then I clearly need someone to enlight me >>> ;-).=20 >>>=20 >>> Best regards, >>> Ulf _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 26 19:36:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECsN-0007a6-Vm; Thu, 26 Jul 2007 19:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECsN-0007a1-5R for dime@ietf.org; Thu, 26 Jul 2007 19:36:11 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IECsL-0003Im-T2 for dime@ietf.org; Thu, 26 Jul 2007 19:36:11 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6QNa8bH008806; Thu, 26 Jul 2007 18:36:09 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 18:36:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The usage of ACR/ACA for the QoS application Date: Thu, 26 Jul 2007 18:36:08 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D5209F0@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The usage of ACR/ACA for the QoS application Thread-Index: AcfPAc6qATIURnxeTLi0ItSuaQN99AAtx+hAAABfcHAAAQMIQAAAmRGwAASzrHAAAjzP8A== References: <33656995C5C5094A983DE84DA649A924017F8D79@lulex02.ad.operax.com><33656995C5C5094A983DE84DA649A924017F8E34@lulex02.ad.operax.com> <09C9068466B79E4C938DC7737562404D5209ED@ILEXC2U01.ndc.lucent.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , X-OriginalArrivalTime: 26 Jul 2007 23:36:08.0893 (UTC) FILETIME=[BE30A6D0:01C7CFDD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 Hi Pete, It's ok to me to carry certain accounting info for QoS authorization, but not sure if it is good approach to maintain an accounting entity and session for it. Looks like a bit overshot.=20 In addition, what's the relationship between this mini accounting entity and full-blown accounting server? What's the problem to just carry the QoS accounting info via QoS commands if needed? Regards, Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, July 26, 2007 7:18 PM To: Sun, Dong (Dong); dime@ietf.org Subject: RE: [Dime] The usage of ACR/ACA for the QoS application=20 Hi, Dong, Ulf, The mechanism described in the draft is simple and self-contained, only referring to some AVPs defined by the credit control application. RFC 4006 is more complicated than necessary. We decided to include a simple, per-minute charging system that can support time of tarrif changes, allows the NE to specify the cost, and send the accounting records into the Diameter network. Section 5 is really simple and I think it provides all the functionality we need for QoS accounting. -Pete Sun, Dong (Dong) wrote: > I have similar confusion as Ulf. It looks like QoS authorization,=20 > accounting and credit control functions are mixed in this QoS=20 > application, and it is a bit awkward to mandate accounting server > capability within an QoS application. =20 >=20 > It seems in reality the accounting server and QoS authorization server > are independent entities although they might be collocated if needed,=20 > and the credit and accounting permission may not be necessary to be=20 > prerequisite for QoS authorization. Would it be more flexible to=20 > separate the accounting server and credit control function from > QoS authorization server/application? =20 >=20 > Certainly, if some QoS info is needed for policy decision, it can be=20 > carried by an QoS message such as QAR/QIA to QoS authorization server=20 > instead of ACR. >=20 > Regards, > Dong >=20 > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Thursday, July 26, 2007 4:04 PM > To: dime@ietf.org > Subject: RE: [Dime] The usage of ACR/ACA for the QoS application >=20 > Hi Pete, >=20 > Thanks for the clearification. I'm however still a little confused. > Looking at the credit control application I found that the accounting=20 > protocol and the credit control protocol can be used in parallel more=20 > or less in the manner I'm envisioning and how I understand the usage=20 > of the 3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP=20 > though and may be on thin ice here). From that I would have expected=20 > the QoS application to also allow for a similar parallelism. Or, is > there a fundamental difference I have missed here? =20 >=20 > Best regards, > Ulf >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: den 26 juli 2007 21:24 > To: Ulf Bodin; dime@ietf.org > Subject: RE: [Dime] The usage of ACR/ACA for the QoS application >=20 > McCann Peter-A001034 wrote: >> Hi, Ulf, >>=20 >> The current draft puts some cost-information AVPs in the QAR, and the >> Authorizing Entity gets to see those before authorization. >> So, it just seems logical to me that the accounting should go to the=20 >> same place. >>=20 >> In theory, we could put an AVP into the QAR containing the >=20 > Sorry, meant to say "into the QAA". >=20 >> destination for subsequent ACRs. However, it seems like the=20 >> recipient >=20 >> of an ACR will want to verify that the session was indeed authorized, >> so this would imply some non-standard interface between the two. >>=20 >> All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use >> accounting in this way, and I don't see a good reason to break with=20 >> that. >>=20 >> -Pete >>=20 >> Ulf Bodin wrote: >>> All, >>>=20 >>> This might be an uneducated question from someone that just now have >>> read the draft, but the usage of the ACR/ACA messages for the QoS=20 >>> application confuses me somewhat. To my understanding the current=20 >>> draft mandates the use of those messages and thereby manadate the=20 >>> authorizing entity to also handle accounting. I'm not sure that's=20 >>> always the case. E.g. in the 3GPP architecture the PCRF and the=20 >>> online charging system are possible to instasiate separately in a=20 >>> physical deplyment. If my understanding is correct I would then=20 >>> actually suggest to allow for separating authorization and=20 >>> accounting >=20 >>> in the QoS application. Comments/thoughts? Again, I may miss the=20 >>> point completely here and then I clearly need someone to enlight me=20 >>> ;-). >>>=20 >>> Best regards, >>> Ulf _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 27 13:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IETOn-0001By-W2; Fri, 27 Jul 2007 13:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IETOn-0001Bs-3R for dime@ietf.org; Fri, 27 Jul 2007 13:14:45 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IETOm-00013e-Ls for dime@ietf.org; Fri, 27 Jul 2007 13:14:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2007 13:14:41 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] Vendor-Specific Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The Diameter command header originally contained a Vendor Id to allow vendor-specific commands. If I remember correctly, it was removed following IESG review due to interop concerns. However, the command mangling that is occurring now due to the lack of vendor-specific commands is complicating command routing and will lead to interop issues. The least invasive way to bring back vendor-specific commands is to sub-divide the Command code namespace (as was done for Application Id) to allow a vendor-specific range that is allocated by IANA on a 'First Come First Served' basis. We should take the opportunity to address this in 3588bis. Vendor-specific applications are allocated by IANA on a 'First Come First Served' basis. Vendor-specific AVPs just require a vendor id (also 'First Come First Served'). The 'IETF Consensus' policy for new Command codes is so incongruous that it looks like a 'bug' in RFC3588 to me. I suspect this restrictive policy was originally just intended for IETF commands and we should also fix this in 3588bis. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 27 15:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVVD-0007UU-PI; Fri, 27 Jul 2007 15:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVVC-0007UN-Av for dime@ietf.org; Fri, 27 Jul 2007 15:29:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEVVB-0004lX-JZ for dime@ietf.org; Fri, 27 Jul 2007 15:29:30 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2352803uge for ; Fri, 27 Jul 2007 12:29:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=IHYzi+U1M80GELbYSfIJIBpUSjJpzJ3VDjDmLaavKQcVWakgDEgv1AO+g5PgLzn7DbVAD905pwzfpkjP1jZCWVboh5Z7F9V7T2P6FvLBlqL95RclAxZNRLpjluov7pDXgYJXclgBIZ5y7WDoyDHGr4TFBe+ygrpwq31FMN4q0lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=nsoAeGMo+v1OT7XXry9lb0FFc5NhhPlLkIf4IFovcg0WOFHrMMRbFNmk6ZZT5H5jdiyzHKl+5HgbLg8AP9OOlfvRdXZXdg4/5oOZUwoLGlRWZ+V4/dgP/XRvvL1h/b44fbqmdvghF3KSukf7zJkOZ4o+PFMyQnK4kXZ7ty6DT9U= Received: by 10.82.186.5 with SMTP id j5mr2972100buf.1185564568579; Fri, 27 Jul 2007 12:29:28 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Fri, 27 Jul 2007 12:29:28 -0700 (PDT) Message-ID: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> Date: Fri, 27 Jul 2007 15:29:28 -0400 From: "David Frascone" To: "Mark Jones" Subject: Re: [Dime] Vendor-Specific Commands In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 2fcb84fab1624035 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680203858==" Errors-To: dime-bounces@ietf.org --===============0680203858== Content-Type: multipart/alternative; boundary="----=_Part_10825_9823569.1185564568556" ------=_Part_10825_9823569.1185564568556 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I do think that leaving out vendor specific command codes was a mistake. And, I think asking for any kind of command code 'request', when the vendor-specific application has already been requested, is a huge waste of time. Given this, I'm for allocating a range of codes to be considered vendor specific, and not regulated beyond that. That way, in a vendor specific aplication, vendors don't have unnecessary waiting when developing custom applications. Just my $0.02 worth, -Dave (Dave the guy, not Dave the WG Chair) On 7/27/07, Mark Jones wrote: > > The Diameter command header originally contained a Vendor Id to allow > vendor-specific commands. If I remember correctly, it was removed > following IESG review due to interop concerns. However, the command > mangling that is occurring now due to the lack of vendor-specific > commands is complicating command routing and will lead to interop > issues. > > The least invasive way to bring back vendor-specific commands is to > sub-divide the Command code namespace (as was done for Application Id) > to allow a vendor-specific range that is allocated by IANA on a 'First > Come First Served' basis. We should take the opportunity to address this > in 3588bis. > > Vendor-specific applications are allocated by IANA on a 'First Come > First Served' basis. Vendor-specific AVPs just require a vendor id (also > 'First Come First Served'). The 'IETF Consensus' policy for new Command > codes is so incongruous that it looks like a 'bug' in RFC3588 to me. I > suspect this restrictive policy was originally just intended for IETF > commands and we should also fix this in 3588bis. > > Regards > Mark > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- David Frascone Oxymoron: Safe Sex. ------=_Part_10825_9823569.1185564568556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I do think that leaving out vendor specific command codes was a
mistake.  And, I think asking for any kind of command code 'request',
when the vendor-specific application has already been requested, is a
huge waste of time.

Given this, I'm for allocating a range of codes to be considered
vendor specific, and not regulated beyond that.  That way, in a vendor
specific aplication, vendors don't have unnecessary waiting when
developing custom applications.

Just my $0.02 worth,

-Dave
(Dave the guy, not Dave the WG Chair)



On 7/27/07, Mark Jones <mark.jones@bridgewatersystems.com> wrote:
The Diameter command header originally contained a Vendor Id to allow
vendor-specific commands. If I remember correctly, it was removed
following IESG review due to interop concerns. However, the command
mangling that is occurring now due to the lack of vendor-specific
commands is complicating command routing and will lead to interop
issues.

The least invasive way to bring back vendor-specific commands is to
sub-divide the Command code namespace (as was done for Application Id)
to allow a vendor-specific range that is allocated by IANA on a 'First
Come First Served' basis. We should take the opportunity to address this
in 3588bis.

Vendor-specific applications are allocated by IANA on a 'First Come
First Served' basis. Vendor-specific AVPs just require a vendor id (also
'First Come First Served'). The 'IETF Consensus' policy for new Command
codes is so incongruous that it looks like a 'bug' in RFC3588 to me. I
suspect this restrictive policy was originally just intended for IETF
commands and we should also fix this in 3588bis.

Regards
Mark


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



--
David Frascone

Oxymoron: Safe Sex. ------=_Part_10825_9823569.1185564568556-- --===============0680203858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0680203858==-- From dime-bounces@ietf.org Sat Jul 28 02:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfw2-0004Ip-Se; Sat, 28 Jul 2007 02:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfw1-0004Ii-L1 for dime@ietf.org; Sat, 28 Jul 2007 02:37:53 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEfw0-0004PC-De for dime@ietf.org; Sat, 28 Jul 2007 02:37:53 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6S6bhKL005014; Sat, 28 Jul 2007 08:37:43 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 28 Jul 2007 08:37:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Vendor-Specific Commands Date: Sat, 28 Jul 2007 08:37:42 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EA691AC9@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfQhJv3qsrUAauUQMqx9sBqws3jEAAWv85A References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> From: "Schwarz Albrecht" To: "David Frascone" , "Mark Jones" X-OriginalArrivalTime: 28 Jul 2007 06:37:45.0718 (UTC) FILETIME=[CEAF9160:01C7D0E1] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1220344330==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1220344330== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D0E1.CE665286" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D0E1.CE665286 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any signalling protocol should support the possibility of private extensions. Just due to intra-vendor deployment scenarios, etc. However, the "vendor role" must be specified, it could be a e.g. manufacturer or an operator, but it shouldn't be any other standardization development organization (SDO) besides IETF. Non-IETF SDO's with own vendor-IDs will create interop issues in my opinion. Another issue is the development of similar protocol functionality (syntax/semantic) under different vendor-ID name spaces. The IETF is the owner of the Diameter. Any strict control of technology extensions is a prerequisite for minimization of interop issues, protocol redundancy and semantical unclearness. =20 Thus, could imagine that a stricter policy concerning vendor-ID usage might be a compromise. =20 ________________________________ From: David Frascone [mailto:dave@frascone.com]=20 Sent: Freitag, 27. Juli 2007 21:29 To: Mark Jones Cc: dime@ietf.org Subject: Re: [Dime] Vendor-Specific Commands =09 =09 I do think that leaving out vendor specific command codes was a mistake. And, I think asking for any kind of command code 'request',=20 when the vendor-specific application has already been requested, is a huge waste of time. =09 Given this, I'm for allocating a range of codes to be considered vendor specific, and not regulated beyond that. That way, in a vendor=20 specific aplication, vendors don't have unnecessary waiting when developing custom applications. =09 Just my $0.02 worth, =09 -Dave (Dave the guy, not Dave the WG Chair) =09 =09 =09 =09 On 7/27/07, Mark Jones wrote:=20 The Diameter command header originally contained a Vendor Id to allow vendor-specific commands. If I remember correctly, it was removed following IESG review due to interop concerns. However, the command mangling that is occurring now due to the lack of vendor-specific=20 commands is complicating command routing and will lead to interop issues. =09 The least invasive way to bring back vendor-specific commands is to sub-divide the Command code namespace (as was done for Application Id)=20 to allow a vendor-specific range that is allocated by IANA on a 'First Come First Served' basis. We should take the opportunity to address this in 3588bis. =09 Vendor-specific applications are allocated by IANA on a 'First Come=20 First Served' basis. Vendor-specific AVPs just require a vendor id (also 'First Come First Served'). The 'IETF Consensus' policy for new Command codes is so incongruous that it looks like a 'bug' in RFC3588 to me. I=20 suspect this restrictive policy was originally just intended for IETF commands and we should also fix this in 3588bis. =09 Regards Mark =09 =09 _______________________________________________ DiME mailing list=20 DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 --=20 David Frascone=20 =09 Oxymoron: Safe Sex.=20 ------_=_NextPart_001_01C7D0E1.CE665286 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Any signalling protocol should support the = possibility=20 of private extensions.
Just due to intra-vendor deployment = scenarios,=20 etc.
However, the "vendor role" must be specified, = it could=20 be a e.g. manufacturer or an operator, but it shouldn't be any=20 other standardization development organization (SDO) besides=20 IETF.
Non-IETF SDO's with own vendor-IDs will = create interop=20 issues in my opinion.
Another issue is the development of similar = protocol=20 functionality (syntax/semantic) under different vendor-ID name=20 spaces.
The IETF is the owner of the Diameter. Any = strict=20 control of technology extensions is a prerequisite for minimization of = interop=20 issues, protocol redundancy and semantical = unclearness.
 
Thus, could imagine that a stricter policy = concerning=20 vendor-ID usage might be a compromise.
 

From: David Frascone=20 [mailto:dave@frascone.com]
Sent: Freitag, 27. Juli 2007=20 21:29
To: Mark Jones
Cc: = dime@ietf.org
Subject:=20 Re: [Dime] Vendor-Specific Commands

I do think that leaving = out vendor=20 specific command codes was a
mistake.  And, I think asking for = any=20 kind of command code 'request',
when the vendor-specific = application has=20 already been requested, is a
huge waste of time.

Given this, = I'm for=20 allocating a range of codes to be considered
vendor specific, and = not=20 regulated beyond that.  That way, in a vendor
specific = aplication,=20 vendors don't have unnecessary waiting when
developing custom=20 applications.

Just my $0.02 worth,

-Dave
(Dave the = guy, not=20 Dave the WG Chair)



On 7/27/07, Mark=20 Jones <mark.jones@bridgewaters= ystems.com>=20 wrote:
The=20 Diameter command header originally contained a Vendor Id to=20 allow
vendor-specific commands. If I remember correctly, it was=20 removed
following IESG review due to interop concerns. However, = the=20 command
mangling that is occurring now due to the lack of = vendor-specific=20
commands is complicating command routing and will lead to=20 interop
issues.

The least invasive way to bring back=20 vendor-specific commands is to
sub-divide the Command code = namespace (as=20 was done for Application Id)
to allow a vendor-specific range = that is=20 allocated by IANA on a 'First
Come First Served' basis. We should = take=20 the opportunity to address this
in = 3588bis.

Vendor-specific=20 applications are allocated by IANA on a 'First Come
First = Served' basis.=20 Vendor-specific AVPs just require a vendor id (also
'First Come = First=20 Served'). The 'IETF Consensus' policy for new Command
codes is so = incongruous that it looks like a 'bug' in RFC3588 to me. I =
suspect this=20 restrictive policy was originally just intended for IETF
commands = and we=20 should also fix this in=20 = 3588bis.

Regards
Mark


______________________________= _________________
DiME=20 mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime


--
David Frascone

Oxymoron: Safe Sex.=20 ------_=_NextPart_001_01C7D0E1.CE665286-- --===============1220344330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1220344330==-- From dime-bounces@ietf.org Sun Jul 29 04:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF423-0008OZ-3J; Sun, 29 Jul 2007 04:21:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF421-0008OU-6c for dime@ietf.org; Sun, 29 Jul 2007 04:21:41 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IF420-0006rE-BB for dime@ietf.org; Sun, 29 Jul 2007 04:21:40 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l6T8LULP097147 for ; Sun, 29 Jul 2007 10:21:31 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Jul 2007 10:21:30 +0200 Message-ID: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwA== From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Sun, 29 Jul 2007 10:21:31 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3804/Sun Jul 29 06:09:31 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] Update on Diameter Auditing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org All,=20 As requested I'm giving a brief update on the Diameter Auditing work at the list (basically the update I gave verbally on Friday's WG meeting): There are two individual drafts on the topic; the Diameter Auditing requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and the State recovery draft, SR (draft-asveren-dime-state-recovery-01). AR gives high level requirements for Diameter auditing and contains previous work done by Pat Calhoun on defining commads and AVPs for auditing. SR provides an analyze of what protocol assisted mechanisms can be helfull in performing state recovery.=20 Some mails have been exchanged in June studying which commands and AVPs either defined in Calhouns original work or that exists in other Dimeter specificaitons that could be used or enhanced for protocol assisted state recovery (i.e. auditing). My intention is to proceed that work and before the next IETF meeting collect what then have been done on the mailing list into a draft presenting desired extensions to Dimaeter for protocol assisted state recovery. Based on that work it'd in my view make sence considering taking on Diameter protocol assisted state recovery as a WG work item.=20 BR Ulf=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 29 12:26:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFBau-0005ln-Cd; Sun, 29 Jul 2007 12:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFBas-0005lh-OR for dime@ietf.org; Sun, 29 Jul 2007 12:26:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFBar-0006c5-TB for dime@ietf.org; Sun, 29 Jul 2007 12:26:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2007 09:26:09 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADRcrEarR7MV/2dsb2JhbACCZQ X-IronPort-AV: i="4.19,196,1183359600"; d="scan'208,217"; a="190675022:sNHT45359955" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6TGQ9lU003471; Sun, 29 Jul 2007 09:26:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6TGPxA0014289; Sun, 29 Jul 2007 16:25:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 09:25:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Vendor-Specific Commands Date: Sun, 29 Jul 2007 09:26:04 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A35@xmb-sjc-215.amer.cisco.com> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EA691AC9@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfQhJv3qsrUAauUQMqx9sBqws3jEAAWv85AAEbgGJA= References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> <8BB8AD9870081C42B2B309E00352E4EA691AC9@FRVELSMBS15.ad2.ad.alcatel.com> From: "Glen Zorn \(gwz\)" To: "Schwarz Albrecht" , "David Frascone" , "Mark Jones" X-OriginalArrivalTime: 29 Jul 2007 16:25:59.0025 (UTC) FILETIME=[258C9610:01C7D1FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6165; t=1185726369; x=1186590369; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Vendor-Specific=20Commands |Sender:=20; bh=6jU5nuXIRw+aILUAMfPM2somdgMAE5J/LT8m60NsxoU=; b=Eyg/VTMkkgsrdFfjU4Ulqym++wvYMUkMeZQX6KtUUrQp0ZNMad3V5pH8KJ2lSXFSYaLPa11A +KwbyHEPKhFWgjKu3YlWX8jrQg7izrcCi/2S+D8RAwNaa6tEtmNDnLT9CGoWzW9/hqd1WfdRXJ uwYwTPFJkwcmyd/WDxbxnk0O4=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0692755810==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0692755810== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D1FD.25541DD7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D1FD.25541DD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any signalling protocol should support the possibility of private extensions. Just due to intra-vendor deployment scenarios, etc. However, the "vendor role" must be specified, it could be a e.g. manufacturer or an operator, but it shouldn't be any other standardization development organization (SDO) besides IETF. Non-IETF SDO's with own vendor-IDs will create interop issues in my opinion.=20 Why? What specific issues? Don't exactly know how you can say that, given the fact that DSLF, 3GPP & 3GPP2 (at least) have & use their own vendor IDs; further, the fact that there are already many, many SDO-specific RADIUS attribute that hasn't seemed to have harmed RADIUS interoperability and finally, there are already vendor (which may be SDOs) specific applications and AVPs in Diameter -- in essence, everything needed to build an application except a vendor-specific command code .=20 Another issue is the development of similar protocol functionality (syntax/semantic) under different vendor-ID name spaces. The IETF is the owner of the Diameter. =20 That is extremely questionable. Any strict control of technology extensions is a prerequisite for minimization of interop issues, protocol redundancy and semantical unclearness. Unfortunately, this hasn't proven to be the case thus far; what has happened is that seriously broken protocols have been published under the IETF imprimatur. That doesn't really help the IETF; it does allow the sponsoring SDO to claim no responsibility, though, because the IETF "approved" it. Thus, could imagine that a stricter policy concerning vendor-ID usage might be a compromise. =20 ....=20 ------_=_NextPart_001_01C7D1FD.25541DD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Any signalling protocol should support the = possibility=20 of private extensions.
Just due to intra-vendor deployment = scenarios,=20 etc.
However, the "vendor role" must be specified, = it could=20 be a e.g. manufacturer or an operator, but it shouldn't be any=20 other standardization development organization (SDO) besides=20 IETF.
Non-IETF = SDO's with=20 own vendor-IDs will create interop issues in my opinion. 
Why?  What specific issues?  Don't = exactly=20 know how you can say that, given the fact that DSLF, 3GPP & 3GPP2 = (at least)=20 have & use their own vendor IDs; further, the fact that there = are=20 already many, many SDO-specific RADIUS attribute that hasn't seemed to = have=20 harmed RADIUS interoperability and finally, there are already vendor = (which may=20 be SDOs) specific applications and AVPs in Diameter -- in essence, = everything=20 needed to build an application except a vendor-specific command=20 code . 
Another issue is the development of similar = protocol=20 functionality (syntax/semantic) under different vendor-ID name=20 spaces.
The IETF is the owner of the = Diameter.  
That is = extremely=20 questionable.
Any strict control of technology extensions = is a=20 prerequisite for minimization of interop issues, protocol redundancy and = semantical unclearness.
Unfortunately, this=20 hasn't proven to be the case thus far; what has happened is = that=20 seriously broken protocols have been published under the IETF = imprimatur. =20 That doesn't really help the IETF;  it does allow the sponsoring = SDO to=20 claim no responsibility, though, because the IETF "approved"=20 it.
Thus, could imagine that a stricter policy = concerning=20 vendor-ID usage might be a compromise.
 
....=20 ------_=_NextPart_001_01C7D1FD.25541DD7-- --===============0692755810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0692755810==-- From dime-bounces@ietf.org Sun Jul 29 17:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFGBy-0001yx-9d; Sun, 29 Jul 2007 17:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFGBx-0001ys-9d for dime@ietf.org; Sun, 29 Jul 2007 17:20:45 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFGBw-0005js-Qv for dime@ietf.org; Sun, 29 Jul 2007 17:20:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2007 14:20:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOagrEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,196,1183359600"; d="scan'208"; a="190738558:sNHT26644896" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6TLKiAk022731; Sun, 29 Jul 2007 14:20:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6TLKZSb010823; Sun, 29 Jul 2007 21:20:35 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 14:20:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Vendor-Specific Commands Date: Sun, 29 Jul 2007 14:20:41 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A6E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfQhIvS49J4njF6Q6Cq/fDLuObYhABnUjzw References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> From: "Glen Zorn \(gwz\)" To: "David Frascone" , "Mark Jones" X-OriginalArrivalTime: 29 Jul 2007 21:20:35.0315 (UTC) FILETIME=[4D706430:01C7D226] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1555; t=1185744044; x=1186608044; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Vendor-Specific=20Commands |Sender:=20; bh=F7ayudWMxmBJD1w5xeDU+GGSFAz7wfg2063gMMbkT0A=; b=ze4iKkP3aLscTlp7khJiowuhrPmj5rx2BEE4QC98XVAbq4nvr12Quq9+4U6ycEW8q1TNVluJ 6agF9vllpKOFEUplmkF/o4yHr36KR1tqw/smJivdnu/v0wSB0bnOt5r0; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I do think that leaving out vendor specific command codes was a mistake. And, I think asking for any kind of command code 'request', when the vendor-specific application has already been requested, is a huge waste of time. Given this, I'm for allocating a range of codes to be considered vendor specific, and not regulated beyond that. That way, in a vendor specific application, vendors don't have unnecessary waiting when developing custom applications. I agree. Let me offer this text: 11.2.1. Command Codes The Command Code namespace is used to identify Diameter commands. The values 0-255 (0x00-0xff) are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256 - 16,777,213 (0x100 - 0xfffffd) are for permanent, standard commands, allocated by IETF Consensus [RFC2434]. This document defines the Command Codes 257, 258, 271, 274-275, 280 and 282. See Section 3.1 for the assignment of the namespace in this specification. The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [IANA-EXP]. The values 16,777,216 - 4,294,967,295 (0x1000000 - 0xffffffff) are reserved for vendor-specific command codes, to be allocated on a First Come, First Served basis by IANA [RFC2434]. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 29 18:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFH9t-0003By-JW; Sun, 29 Jul 2007 18:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFH9s-000350-ER for dime@ietf.org; Sun, 29 Jul 2007 18:22:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFH9s-0006m3-39 for dime@ietf.org; Sun, 29 Jul 2007 18:22:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2007 15:22:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJiwrEarR7O6/2dsb2JhbACCZw X-IronPort-AV: i="4.19,196,1183359600"; d="scan'208,217"; a="190751267:sNHT36343791" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6TMMd9H012537 for ; Sun, 29 Jul 2007 15:22:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6TMMdSb000046 for ; Sun, 29 Jul 2007 22:22:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 15:22:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 29 Jul 2007 15:22:45 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A79@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: author list on RFC 3588bis Thread-Index: AcfSLvzI5VJjN14wT4aAbn+IOZK1ZA== From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 29 Jul 2007 22:22:39.0210 (UTC) FILETIME=[F90DACA0:01C7D22E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1086; t=1185747759; x=1186611759; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20author=20list=20on=20RFC=203588bis |Sender:=20; bh=MMUG3jYnTk3YHxRdJxA1hN/pw4rqA3rLnCCH8Rax3Pg=; b=NtUKCO8l9VXBBXjh3fooLlioJFKk7u95TOBJg75KsC9fD/QjYXDPwcIWIBYYuz7Km//vsnC+ yKXG4hpi6f3Y0kHDOtdQqwuRvvUO4B5KbdBnck96/7SZbPWgVvD9a1Vh; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Dime] author list on RFC 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1467699178==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1467699178== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D22E.F8DC75C9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D22E.F8DC75C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just out of curiosity, how were the two surviving authors of 3588 chosen to survive? Nuclear power: more toxic than Britney Spears ~gwz ------_=_NextPart_001_01C7D22E.F8DC75C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable author list on RFC 3588bis

Just out of curiosity, how were the two = surviving authors of 3588 chosen to survive?

Nuclear power: more toxic than Britney = Spears

~gwz

------_=_NextPart_001_01C7D22E.F8DC75C9-- --===============1467699178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1467699178==-- From dime-bounces@ietf.org Sun Jul 29 19:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIFy-00030d-Qw; Sun, 29 Jul 2007 19:33:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIFy-00030Y-88 for dime@ietf.org; Sun, 29 Jul 2007 19:33:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFIFx-00084D-Ov for dime@ietf.org; Sun, 29 Jul 2007 19:33:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 29 Jul 2007 16:33:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPzArEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,196,1183359600"; d="scan'208"; a="7442567:sNHT14246196" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6TNX0gS011497; Sun, 29 Jul 2007 16:33:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6TNWuSb021894; Sun, 29 Jul 2007 23:33:00 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 16:32:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Update on Diameter Auditing Date: Sun, 29 Jul 2007 16:33:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hA References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> From: "Glen Zorn \(gwz\)" To: "Ulf Bodin" X-OriginalArrivalTime: 29 Jul 2007 23:32:56.0160 (UTC) FILETIME=[CA8D2E00:01C7D238] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2256; t=1185751980; x=1186615980; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Update=20on=20Diameter=20Auditing=20 |Sender:=20; bh=I7i+Gm45B908MRinAT3uE8qZlSQWvd90BhmzkBCi/XY=; b=iWygkSpHSOBQCbxy1mbNi7oLTNgjY7q+hnEkddfEGwU+rvS5O2lHOxFnutde3LnIpEgmcett 5ibg+OUG5p3U6EWdTxIPt/5M05gQ/OF4MAyRhM3qQXsfj8a0UWgmUaSt; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Ulf Bodin allegedly scribbled on Sunday, July 29, 2007 1:22 AM: > All, >=20 > As requested I'm giving a brief update on the Diameter Auditing work > at the list (basically the update I gave verbally on Friday's WG > meeting): =20 >=20 >=20 > There are two individual drafts on the topic; the Diameter Auditing > requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and the > State recovery draft, SR (draft-asveren-dime-state-recovery-01). AR > gives high level requirements for Diameter auditing and contains > previous work done by Pat Calhoun on defining commads and AVPs for > auditing.=20 This draft is largely indecipherable. Although there may be requirements in there, I can't find them and there seems to be no actual description of the problem it's trying to solve. My _guess_ is that for some unknown reason you are trying to use the network as a state repository so that it can recover state after a failure. Is that right? If so, why is this scheme better than, say, NVRAM? > SR provides an analyze of what protocol assisted mechanisms > can be helfull in performing state recovery. =20 >=20 > Some mails have been exchanged in June studying which commands and > AVPs either defined in Calhouns original work or that exists in other > Dimeter specificaitons that could be used or enhanced for protocol > assisted state recovery (i.e. auditing).=20 Maybe part of the problem is the (mis)use of the word auditing. Thinking that I was ignorant I made a rather extensive search of dictionaries and was unable to find a definition of the word "auditing" that remotely resembled "protocol assisted (sic) state recovery". > My intention is to proceed > that work and before the next IETF meeting collect what then have > been done on the mailing list into a draft presenting desired > extensions to Dimaeter for protocol assisted state recovery. Based on > that work it'd in my view make sence considering taking on Diameter > protocol assisted state recovery as a WG work item. =20 Why? =20 >=20 > BR Ulf >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 01:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFNkB-0002W6-9V; Mon, 30 Jul 2007 01:24:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFNk9-0002VO-VV; Mon, 30 Jul 2007 01:24:34 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFNk8-0007Jr-Ud; Mon, 30 Jul 2007 01:24:33 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm246ad830f; Mon, 30 Jul 2007 13:36:25 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4946a778e4; Wed, 25 Jul 2007 19:58:54 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 25 Jul 2007 19:58:54 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2U-0002kC-IB; Tue, 24 Jul 2007 12:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2N-0002gu-8a; Tue, 24 Jul 2007 12:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDN2M-00032I-Q3; Tue, 24 Jul 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9789B26EB3; Tue, 24 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005W1-Cc; Tue, 24 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-02.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-02.txt Pages : 19 Date : 2007-7-24 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-app-design-guide-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-app-design-guide-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-24112909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-24112909.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Jul 30 03:58:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQ9Y-0000tp-M5; Mon, 30 Jul 2007 03:58:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQ9X-0000tk-HT for dime@ietf.org; Mon, 30 Jul 2007 03:58:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFQ9W-0002MU-Ot for dime@ietf.org; Mon, 30 Jul 2007 03:58:55 -0400 Received: (qmail invoked by alias); 30 Jul 2007 07:58:53 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 30 Jul 2007 09:58:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/QzHFRAAHQ7Cq5firNSOlltLe7g7/PUYxqrrj1TT Hj0iaSJyVieVG7 Message-ID: <46AD9A3C.3000909@gmx.net> Date: Mon, 30 Jul 2007 09:58:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] author list on RFC 3588bis References: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A79@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A79@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Very easy answer: When we started the work on the document I sent a mail to the previous authors and asked whether they are willing to spend time working on the document. A couple of months I resend that mail because only John and Jari replied. If I recall it correctly then I never got a response from anyone else. In my mail I furthermore said: "If you say YES now and you don't do work then I will remove you." My impression was that if someone does not want to reply to my mail then he might not be able to spend too much time on working with the draft update either. So far, Victor did an extremely good job in working through the issues in a very transparent fashion. Hence, he is the editor of the document. Ciao Hannes Glen Zorn (gwz) wrote: > Just out of curiosity, how were the two surviving authors of 3588 chosen > to survive? > > Nuclear power: more toxic than Britney Spears > > ~gwz > > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 04:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQL7-0007YW-D5; Mon, 30 Jul 2007 04:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQL5-0007YO-Bn for dime@ietf.org; Mon, 30 Jul 2007 04:10:51 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFQL3-0003pT-Qk for dime@ietf.org; Mon, 30 Jul 2007 04:10:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6U89uGf019542; Mon, 30 Jul 2007 11:10:44 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 11:10:38 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 03:10:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] author list on RFC 3588bis Date: Mon, 30 Jul 2007 03:10:32 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A54AE4D@daebe104.NOE.Nokia.com> In-Reply-To: <46AD9A3C.3000909@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] author list on RFC 3588bis Thread-Index: AcfSf4RpZFBEo1P/TWSZgQgyq4DNggAAX75Q References: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A79@xmb-sjc-215.amer.cisco.com> <46AD9A3C.3000909@gmx.net> From: To: , X-OriginalArrivalTime: 30 Jul 2007 08:10:36.0913 (UTC) FILETIME=[1C33F610:01C7D281] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Hannes on this. I was expecting to be a bit more active on the -bis document, but I'll try to pick up the slack now. John=20 >-----Original Message----- >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: 30 July, 2007 10:59 >To: Glen Zorn (gwz) >Cc: dime@ietf.org >Subject: Re: [Dime] author list on RFC 3588bis > >Very easy answer: > >When we started the work on the document I sent a mail to the=20 >previous authors and asked whether they are willing to spend=20 >time working on the document. >A couple of months I resend that mail because only John and=20 >Jari replied. If I recall it correctly then I never got a=20 >response from anyone else. >In my mail I furthermore said: "If you say YES now and you=20 >don't do work then I will remove you." > >My impression was that if someone does not want to reply to my=20 >mail then he might not be able to spend too much time on=20 >working with the draft update either. > >So far, Victor did an extremely good job in working through=20 >the issues in a very transparent fashion. Hence, he is the=20 >editor of the document. > >Ciao >Hannes > >Glen Zorn (gwz) wrote: >> Just out of curiosity, how were the two surviving authors of 3588=20 >> chosen to survive? >> >> Nuclear power: more toxic than Britney Spears >> >> ~gwz >> >> >> =20 >>=20 >---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> =20 > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 05:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFR7J-0008Jo-9L; Mon, 30 Jul 2007 05:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFR7H-0008Iz-FX for dime@ietf.org; Mon, 30 Jul 2007 05:00:39 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFR7F-0005qt-9B for dime@ietf.org; Mon, 30 Jul 2007 05:00:39 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLZ00LXZIBSLN@szxga03-in.huawei.com> for dime@ietf.org; Mon, 30 Jul 2007 16:59:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLZ009OTIBPGS@szxga03-in.huawei.com> for dime@ietf.org; Mon, 30 Jul 2007 16:59:52 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLZ007OQIBLDN@szxml03-in.huawei.com> for dime@ietf.org; Mon, 30 Jul 2007 16:59:49 +0800 (CST) Date: Mon, 30 Jul 2007 14:29:45 +0530 From: Rajith R Subject: RE: [Dime] Vendor-Specific Commands In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A6E@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , 'David Frascone' , 'Mark Jones' Message-id: <000001c7d287$fa0f8ed0$3a17120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfQhIvS49J4njF6Q6Cq/fDLuObYhABnUjzwABl+noA= X-Spam-Score: 1.7 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > The values 16,777,216 - 4,294,967,295 (0x1000000 - >0xffffffff) are reserved for vendor-specific command codes, to be > allocated on a First Come, First Served basis by IANA [RFC2434]. But command code is only 3 bytes ... >-----Original Message----- >From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >Sent: Monday, July 30, 2007 2:51 AM >To: David Frascone; Mark Jones >Cc: dime@ietf.org >Subject: RE: [Dime] Vendor-Specific Commands > >I do think that leaving out vendor specific command codes was >a mistake. And, I think asking for any kind of command code >'request', when the vendor-specific application has already >been requested, is a huge waste of time. > >Given this, I'm for allocating a range of codes to be >considered vendor specific, and not regulated beyond that. >That way, in a vendor specific application, vendors don't have >unnecessary waiting when developing custom applications. > >I agree. Let me offer this text: > >11.2.1. Command Codes > > The Command Code namespace is used to identify Diameter commands. >The values 0-255 (0x00-0xff) are reserved for > RADIUS backward compatibility, and are defined as "RADIUS >Packet Type Codes" in [RADTYPE]. Values 256 - 16,777,213 > (0x100 - 0xfffffd) are for permanent, standard commands, >allocated by IETF Consensus [RFC2434]. This document defines > the Command Codes 257, 258, 271, 274-275, 280 and 282. See Section >3.1 for the assignment of the namespace in this > specification. > > The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - >0xffffff) are reserved for experimental commands. > As these codes are only for experimental and testing >purposes, no guarantee is made for interoperability between > Diameter peers using experimental commands, as outlined in >[IANA-EXP]. > > The values 16,777,216 - 4,294,967,295 (0x1000000 - >0xffffffff) are reserved for vendor-specific command codes, to be > allocated on a First Come, First Served basis by IANA [RFC2434]. > >... > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 08:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUea-0006yf-TT; Mon, 30 Jul 2007 08:47:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUeY-0006yX-Uc for dime@ietf.org; Mon, 30 Jul 2007 08:47:14 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFUeY-00043x-Kv for dime@ietf.org; Mon, 30 Jul 2007 08:47:14 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6UCkoAU029880; Mon, 30 Jul 2007 08:46:50 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46ADDDBA.4030605@tari.toshiba.com> Date: Mon, 30 Jul 2007 08:46:50 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] Vendor-Specific Commands References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A6E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A6E@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thanks for the proposal. I am in favor of allocating a vendor-specific command as well though I'm waiting to hear legitimate concerns before closing the issue. > The values 16,777,216 - 4,294,967,295 (0x1000000 - 0xffffffff) are > reserved for vendor-specific command codes, to be > allocated on a First Come, First Served basis by IANA [RFC2434]. > Some adjustments to the proposed vendor-specific command space: range can be between 8,388,607 - 16,777,213 (7fffff - 0xfffffd) . Half the command space should be sufficient unless some folks have reasonable objections. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 08:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUpT-0004zK-KV; Mon, 30 Jul 2007 08:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUpS-0004zE-9F for dime@ietf.org; Mon, 30 Jul 2007 08:58:30 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFUpR-0005sN-Vr for dime@ietf.org; Mon, 30 Jul 2007 08:58:30 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6UCw215029924; Mon, 30 Jul 2007 08:58:02 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46ADE058.5050901@tari.toshiba.com> Date: Mon, 30 Jul 2007 08:58:00 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Schwarz Albrecht Subject: Re: [Dime] Vendor-Specific Commands References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> <8BB8AD9870081C42B2B309E00352E4EA691AC9@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EA691AC9@FRVELSMBS15.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > The IETF is the owner of the Diameter. Any strict control of > technology extensions is a prerequisite for minimization of interop > issues, protocol redundancy and semantical unclearness. This strict control strategy is not helpful since other SDO's will find ways to circumvent these rules when they are not convenient. This resulted in some bad design choices and from experience, it is what's causing "real" interop issues. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 09:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUyK-000123-Ml; Mon, 30 Jul 2007 09:07:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUyJ-00011x-MA for dime@ietf.org; Mon, 30 Jul 2007 09:07:39 -0400 Received: from smtp101.rog.mail.re2.yahoo.com ([206.190.36.79]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFUyJ-0004gj-9c for dime@ietf.org; Mon, 30 Jul 2007 09:07:39 -0400 Received: (qmail 90020 invoked from network); 30 Jul 2007 13:07:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YMOaY+HMqiE35y0/M9hwWpu9Bd+wHtLWC2pkFmDXwBE2mko1rJXzD7forUgCx8v54LieurrvxcWFKNFBwPyS9TbjaNujLSGDlUaddDPrQc/ki9mD7zzV8v84jrRczA9roEhT00rF2CB/SBzxJiN124deP8DPDlf4X75tvsbOiws= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2007 13:07:38 -0000 X-YMail-OSG: IV9hax0VM1nBzHrtdoxOSNWxXti54x2IMW95sWwgU5lnbhbj6Dg3vt0KmXxwYh8L7g-- Message-ID: <46ADE29C.4080609@rogers.com> Date: Mon, 30 Jul 2007 09:07:40 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: David Frascone Subject: Re: [Dime] Vendor-Specific Commands References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> In-Reply-To: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Just a bit of history here. The IESG originally wanted to keep fairly tight control of the protocol architecture because Diameter was being promoted as the vehicle for all sorts of applications, not just AAA. As an example, in 1998 a group of us convened by Level 3 used it as the basis for IPDC, a forerunner to MGCP and Megaco/H.248. It is quite possible that the IESG would take a more relaxed view of the situation now that Diameter's role is more clearly established. David Frascone wrote: > I do think that leaving out vendor specific command codes was a > mistake. And, I think asking for any kind of command code 'request', > when the vendor-specific application has already been requested, is a > huge waste of time. > > Given this, I'm for allocating a range of codes to be considered > vendor specific, and not regulated beyond that. That way, in a vendor > specific aplication, vendors don't have unnecessary waiting when > developing custom applications. > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 11:34:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXGI-0001xL-HG; Mon, 30 Jul 2007 11:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXGH-0001xC-4W for dime@ietf.org; Mon, 30 Jul 2007 11:34:21 -0400 Received: from dhcp-76-216.netzwert.ag ([192.108.76.216] helo=noir.netzwert.ag) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXGE-0000nC-Uo for dime@ietf.org; Mon, 30 Jul 2007 11:34:21 -0400 Received: by noir.netzwert.ag (Postfix, from userid 531) id 1656BA00A4D; Mon, 30 Jul 2007 17:34:16 +0200 (CEST) Date: Mon, 30 Jul 2007 17:34:16 +0200 From: Alexis Hildebrandt To: dime@ietf.org Message-ID: <20070730153415.GD32476@noir.netzwert.ag> Mail-Followup-To: dime@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Subject: [Dime] Review of draft-ietf-dime-app-design-guide-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Dear all, please find attached the patch of an editorial review of draft-ietf-dime-app-design-guide-02.txt. The reviewed document, the attached patch, as well as the rfcdiff is also available at: http://www.surryhill.net/ietf/dime/ Note, that some corrections suggested in the review are merely stylistic to improve readability from my point of view. Victor: In case the draft is also available in rfc2629 format I'd gladly provide patches containing the suggestions for the XML. Best regards, Alexis. -- Alexis Hildebrandt, Software Development Voice: +49 30 590080-1172 Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany Fax: +49.30.5900800700, http://www.netzwert.ag Vorstand: Ralf U. Holighaus, Ralf Moritz Aufsichtsrat: Clemens Schrimpe (Vorsitzender) Steuernr.: 37/491/20570 Ust-IdNr.: DE 813 06 78 94 Sitz: Berlin Handelsregister: Amtsgericht Charlottenburg HRB 72960 --Ycz6tD7Th1CMF4v7 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="draft-ietf-dime-app-design-guide-02-reviewed.patch" --- draft-ietf-dime-app-design-guide-02.txt 2007-07-27 12:56:30.368692000 +0200 +++ draft-ietf-dime-app-design-guide-02-reviewed.txt 2007-07-30 15:32:51.706292255 +0200 @@ -81,7 +81,7 @@ 5.1. Rules in Allocating new Command Codes . . . . . . . . . . 10 5.2. Justifying the Allocation of Application-Id . . . . . . . 11 5.3. Use of Application-Id in a Message . . . . . . . . . . . . 11 - 5.4. Application Specific Session Statemachine . . . . . . . . 11 + 5.4. Application Specific Session State Machine . . . . . . . . 11 5.5. End-to-End Applications Capabilities Exchange . . . . . . 12 6. Other Design Considerations . . . . . . . . . . . . . . . . . 12 6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 12 @@ -125,20 +125,20 @@ 2. A new Diameter application is being defined by reusing an existing application. - 3. A completely new application is being defined that has no + 3. An entirely new application is being defined that has no dependencies to any existing applications. 4. A new generic functionality is being defined that can be reused across different applications. - All of these choices are design decisions that can done by any + All of these choices are design decisions that can be done by any combination of reusing existing or defining new commands, AVPs or AVP values. The objective of this document is the following: o Clarify updated Diameter extensibility rules in the Diameter Base - Protocol. + protocol. - o Clarify usage of certain Diameter functionality which are not + o Clarify usage of certain Diameter functionality which is not explicitly described in the Diameter Base specification. o Discuss design choices and provide guidelines when defining @@ -147,11 +147,11 @@ o Present tradeoffs of design choices. These guidelines are necessary since the existing rules do not cover - the ambiguity that exist when some of the design choices overlap. A + the ambiguity that exists when some of the design choices overlap. A typical example would be deciding between item one(1) and two(2) above when an application designer requires a new application functionality which has many things in common with an existing - application. Certain ambiguous aspects of such cases was not + application. Certain ambiguous aspects of such cases were not foreseen in the existing extensibility rules; i.e., use of optional AVPs to differentiate new functionality in the old application versus defining a new application and importing the existing set of @@ -170,10 +170,10 @@ to create a new application would result in the allocation of a new - application ID which often times is foreseen as cumbersome by - application designers because of the lengthy process. Designers - therefore tend to circumvent the better approach leading to many - compromises in the design that eventually lead to interoperability + application ID which is often considered as cumbersome by + application designers because of the lengthy process involved. + Designers therefore tend to evade the better approach leading to many + compromises in the design that will eventually lead to interoperability issues (See Section 5.1). The basic issue is that the rules defined in the Diameter Base @@ -183,7 +183,7 @@ no clear answer on whether to even define a new application or not. At worst, some existing Diameter applications that had purposely been derived from another existing application resulted in some in- - appropriate design decision where both the existing application and + appropriate design decision where both the existing applications and the derived applications are no longer interoperable under certain conditions. Note that it is not always possible to offer a complete and concise answer to certain design choices but at the least, this @@ -201,7 +201,7 @@ protocol is a two-layer protocol. The lower layer is mainly responsible for managing connections between neighboring peers and for message routing. The upper layer is where the Diameter - applications reside. This model is inline with a Diameter node + applications reside. This model is in line with a Diameter node having an application layer and a peer-to-peer delivery layer. The Diameter Base protocol document completely defines the architecture and behavior of the message delivery layer and then provides the @@ -225,39 +225,39 @@ Internet-Draft Diameter Applications Design Guidelines July 2007 - of an existing Diameter applications. This section discusses the + of an existing Diameter application. This section discusses the rules on how such reuse can be done. - When reusing existing applications, the requirements of the new - applications are typically not completely unique and there are - existing application's that can be reused to solve some or all of the - application requirements. Therefore, there is a greater likelihood + When reusing existing applications, the requirements for the new + application are typically not completely unique and there are + existing applications that can be reused to solve some or all of the + application's requirements. Thus, there is a greater likelihood of ambiguity on how much of the existing application can be reused, to what extent and what the implications for both the new and - existing application. To broadly categorize, the rules for reusing + existing application are. To broadly categorize, the rules for reusing existing applications can be either: 1. Minimal - which typically means adding optional AVPs to existing commands. 2. Invasive - where addition or deletion of commands and/or AVPs, - and/or AVP values. + and/or AVP values is necessary. Because it can fundamentally change the application, the latter approach has strict repercussions. Specifically, it would result in the definition of a new application and therefore allocation of a new application ID is required. Discussion about the specific Diameter - Base protocol rules associated with this approach are covered + Base protocol rules associated with this approach are covered in subsequent sections. The former approach, although simple, has pitfalls. The problems arise when there is a tendency by applications designers to keep - adding optional AVPs to existing command so they can circumvent the + adding optional AVPs to existing commands so they can circumvent the rules associated with the latter approach. Specifically, some - designers want to circumvent the standardization process associated + designers merely want to avoid the standardization process associated with these rules and not necessarily the rules themselves. The - pitfalls associated with this approach is described further in + pitfalls associated with this approach are described further in Section 4.2.1. Additionally, if designers choose this approach, all of the functionality of the existing application will be inherited even if the new usage has no intent of using some of the existing @@ -267,7 +267,7 @@ This section discusses the reuse of existing applications by adding and/or deleting commands from the application. This scenario is - categorize as "Invasive" in Section 4 and would always result in the + categorized as "Invasive" in Section 4 and would always result in the creation of new applications when the rules are applied. @@ -284,17 +284,17 @@ 4.1.1. Adding a new command The rules are strict in this case. Adding a command to an - application is not allowed and doing so will force a definition of a + application is not allowed and doing so will force the definition of a new application. However, if this is the intent, then the new application can be created by defining a new command for an existing application or importing an existing command from another application so as to inherit some or all of the functionality of that application. In the former case, the decision is straight forward - since this is typically a result of adding new functionality that + since this is typically the result of adding new functionality that does not yet exist. See Section 5.1 for rules on how to allocate new command codes for new applications. The latter case would result in a new application but it has a more subtle issue such as deciding - whether importing of commands and functionality is really better than + whether importing commands and functionality is really better than simply using the existing application as it is in conjunction with any new application. @@ -303,7 +303,7 @@ during the design phase; one model would reuse existing Diameter EAP application combined with a new Diameter MIPv6 application to form a complete authentication and authorization scheme and another would be - to reuse Diameter EAP like commands within the new Diameter MIPv6 + to reuse Diameter EAP-like commands within the new Diameter MIPv6 application to accomplish the same result. In this case, the latter model was chosen which would permit the reuse of commands and/or AVPs from one application to another. Other applications such as Diameter @@ -317,17 +317,17 @@ o Can the new functionality be fulfilled by creating a new application independent from the existing applications ? In this case, a deployment architecture could be designed such that both - old and new application can work independent of but cooperating - with each other. + the old and new application can work independently while still + cooperating with each other. - o Can the existing application be reused as is without fundamental + o Can an existing application be reused as is without fundamental changes; i.e. a non-mandatory optional AVP is sufficient to indicate support for new optional functionality if any. There are pitfalls to this as well. See Section 4.2.1 o Care should be taken to avoid a liberal method of importing many commands that results in a monolithic and hard to manage - application which supports many different functionality. + application which supports a lot of different functionality. @@ -337,33 +337,34 @@ Internet-Draft Diameter Applications Design Guidelines July 2007 - o Will the new feature or functionality refers only to semantic or - statemachine changes in the application requiring extra message + o Will the new feature or functionality refer only to semantic or + state machine changes in the application requiring extra message round-trips ? In such cases, definition of new commands may not - be necessary and use of existing commands maybe sufficient. + be necessary and use of existing commands might be sufficient. + o Reuse of existing applications would result in a distributed environment which may not be conducive to certain requirements of the applications; i.e. security and or deployment difficulties - because of Diameter routing, messages for different applications providing service to the same user may end up in different servers - would then need to be co-related. This could mean extra signaling + would then need to be co-related. This could imply extra signaling between application servers. A typical example would be the initial proposal for Diameter MIPv6 split scenario (see [2]) where - authorization and authentication is separated. + authorization and authentication are separated. Note that accounting commands normally require special treatment and would not necessarily fall into this category. See Section 6.1. 4.1.2. Deleting a command - Although this is not typical, deleting an command from an existing + Although this is not typical, deleting a command from an existing application is fundamentally changing the application. In general, - the implications of this approach is the same as Section 4.1.1 + the implications of this approach are the same as in Section 4.1.1 regardless of whether new commands will also be added to the resulting application. In general, it is unusual to delete an - existing command from an existing for the sake of deleting it or the - functionality it represents. This design decision would normally be - an indication of a flawed designed. An exception might be if the + existing command from an existing application for the sake of deleting it + or the functionality it represents. This design decision would normally be + an indication of a flawed design. An exception might be if the intent of the deletion is to create a newer version of the same application which is somehow simpler than the previous version. In that case, the considerations in Section 6.3 should apply instead. @@ -374,16 +375,17 @@ Specifically, it discusses rules in adding and/or deleting AVPs from an existing command of an existing application. Unlike Section 4.1, the cases in this section may not necessarily result in the creation - of new application(s). In some cases, there are a lot of ambiguity. - So design considerations have been outline to ease the decision + of new application(s). In some cases, there is a lot of ambiguity. + So design considerations have been outlined to ease the decision making process. 4.2.1. Adding AVPs to a command Based on the rules in [1], AVPs that are added to an existing command can be categorized into: + o Mandatory to understand AVPs. As defined in [1], these are AVPs - which has their M-bit flag set which means Diameter nodes that + that have their M-bit flag set which means a Diameter node that receives these AVPs has to understand not only their values but @@ -394,12 +396,13 @@ their semantics and usage as well. This is regardless of whether - these AVPs are required or optional to appear in the command; as - specified by the commands ABNF. - o Non-mandatory AVPs that are also optional in the commands ABNF. + these AVPs are required or optional within the command; as + specified by the command's ABNF. - The rules are strict in the case where the AVPs to be added is - mandatory. A mandatory cannot be added to or deleted from an + o Non-mandatory AVPs that are also optional in the command's ABNF. + + The rules are strict in the case where the AVPs to be added are + mandatory. A mandatory AVP cannot be added to or deleted from an existing command. [1] states that doing so would require the definition of a new application. This falls into the "Invasive" category described in Section 4. Despite the clarity of the rule, @@ -407,9 +410,9 @@ added should be mandatory to begin with. There are several questions that application designers should contemplate when trying to decide: - o Does the AVPs change the state machine of the application ? + o Does the AVP change the state machine of the application ? - o Would the presence of the AVPs cause additional message round- + o Would the presence of the AVP cause additional message round- trips; effectively changing the state machine of the application ? o Will the AVP be used to fulfill new required functionality ? @@ -421,18 +424,18 @@ application related information as well as be used to indicate that the message is for a new application ? - If one or more of the above conditions are true, the AVP is consider + If one or more of the above conditions are true, the AVP is considered mandatory. These questions are not comprehensive in any way but in all cases the semantics of the application must change to justify the use of mandatory AVPs. - The rules are less restrictive when adding Non-mandatory, optional + The rules are less restrictive when adding non-mandatory, optional AVPs. This falls into the "Minimal" category described in Section 4. However, care should also be taken when opting for optional AVPs instead of mandatory AVPs simply to avoid the process of creating a - new applications. Optional AVPs that answers any of the questions - above also have consequences. Some of the issues associated with - using optional AVPs are: + new application. Optional AVPs that answer any of the questions + above affirmatively also have consequences. Some of the issues + associated with using optional AVPs are: o Use of optional AVPs with intersecting meaning; one AVP has partially the same usage and/or meaning as another AVP. The @@ -462,7 +465,7 @@ Although this scenario is not as common, the deletion of AVPs from a command ABNF is significant when trying to extend an existing application. Deletion can again be categorized between mandatory and - non-mandatory optional AVPs described in Section 4.2.1. + non-mandatory, optional AVPs as described in Section 4.2.1. In the unlikely event that an application designer would require that mandatory AVPs must be deleted then it constitutes a fundamental @@ -471,23 +474,23 @@ application since it dictates changes in the behavior and semantics of an application. - Instead of deleting commands, a better alternative would be to define + Instead of deleting AVPs, a better alternative would be to define a new command that would represent the new behavior. Reusing the same command code for different use cases can lead to more confusion - since the command will have different semantics depending on usage. - This is especially true to base protocol commands (session related + since the command will have different semantics depending on its usage. + This is especially true for base protocol commands (session related commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are being used by many different applications. The deletion of an optional AVP may not necessarily indicate - allocation of a new application. Deletion of non-mandatory optional - AVPs with a zero(0) minimum occurrence in the commands ABNF would not + allocation of a new application. Deletion of non-mandatory, optional + AVPs with a zero(0) minimum occurrence in the command's ABNF would not require a new application. In the case where an optional AVP has a - minimum occurrence of at least one(1) in the commands ABNF, then + minimum occurrence of at least one(1) in the command's ABNF, then deletion of the AVP would effectively change the behavior of the application. It would be similar to the deletion of mandatory AVPs. Such cases are highly dubious to begin with since those AVPs already - exhibits properties of mandatory AVPs. Extra consideration should be + exhibit properties of mandatory AVPs. Additional consideration should be given as to why it was not defined as mandatory in the first place and that decision may have to be corrected as well. @@ -508,20 +511,20 @@ 4.3. Reusing Existing AVPs This section deals with even more granularity than Section 4.1 and - Section 4.2. Specifically, it discusses rules in adding, deleting or + Section 4.2. Specifically, it discusses rules for adding, deleting or modifying the specified values of an AVP. The rules state that modifying the value of an AVP is allowed only if it does not change - the semantics of the AVP and the application using it. Otherwise, - the change can be consider "Invasive" as described in Section 4 and - require definition of a new application. Note that designers should + the semantics of the AVP and the applications using it. Otherwise, + the change can be considered "Invasive" as described in Section 4 and + requires definition of a new application. Note that designers should consider Section 5.2 when contemplating on these types of changes. Typically, the data types of the AVPs in question are scalar in - nature and each ordinal value represent a specific semantic behavior - of the application. An example is CC-Request-Type AVP of [4]. + nature and each ordinal value represents a specific semantic behavior + of the application. An example is the CC-Request-Type AVP of [4]. Adding, deleting or modifying known values of this AVP can modify the behavior of the application itself. Additionally, the mandatory and - optional AVPs rules are inherited from Section 4.2. So this affects + optional AVP rules are inherited from Section 4.2. So this affects the decision for defining new applications as well. @@ -530,19 +533,19 @@ The general theme of Diameter extensibility is to reuse commands, AVPs and AVP values as much as possible. However, some of the extensibility rules described in the previous section also apply to - scenarios where a designer is trying to define a completely new + scenarios where a designer is trying to define an entirely new Diameter application. This section discusses the case where new applications have - requirements that cannot be filled by existing applications and would - require definition of completely new commands, AVPs and/or AVP + requirements that cannot be fulfilled by existing applications and + would require definition of whole new commands, AVPs and/or AVP values. Typically, there is little ambiguity about the decision to create these types of applications. Some examples are the interfaces defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and [6]), Sh ([7] and [8]) etc. Application design should also follow the theme of Diameter - extensibility which in this case may mean importing of existing AVPs + extensibility which in this case may mean importing existing AVPs and AVP values for any newly defined commands. In certain cases where accounting will be used, the models described in Section 6.1 should also be considered. Though some decisions may be clear, @@ -563,15 +566,15 @@ Hopefully this will lessen the tendency to circumvent this process. The core rules for this process will be introduced in rfc3588bis and - full description will be added in this section in the next rev of + a full description will be added in this section in the next rev of this document] 5.2. Justifying the Allocation of Application-Id Application designers should avoid justifying the allocation of an application ID for each new functionality or any change that is made - to an existing application. Proliferation of application ID can lead - to confusion and an in-efficient use of the application ID + to an existing application. Proliferation of application IDs can lead + to confusion and an inefficient use of the application ID namespaces. Application designers should always use Section 4 as a basis for justifying allocation of a new application ID. @@ -593,18 +596,18 @@ its meaning and usage should be segregated only within the application. -5.4. Application Specific Session Statemachine +5.4. Application Specific Session State Machine - Section 8 of [1] provides session statemachines for authentication, + Section 8 of [1] provides session state machines for authentication, authorization and accounting (AAA) services. When a new application is being defined that cannot clearly be categorized into any of these services it is recommended that the application itself defines its - own session statemachine. The existing session statemachines defined - by [1] is not intended for general use beyond AAA services therefore + own session state machine. The existing session state machines defined + by [1] are not intended for general use beyond AAA services therefore any behavior not covered by that category would not fit well. - Support for server initiated request is a clear example where an - application specific session statemachine would be needed; i.e. Rw - interface for ITU-T push model. + Support for server initiated requests is a clear example where an + application specific session state machine would be needed; i.e. Rw + interface for the ITU-T push model. @@ -619,31 +622,31 @@ 5.5. End-to-End Applications Capabilities Exchange - It is also possible that applications can use a type of optional + It is also possible that applications can use some sort of optional capabilities exchange AVPs as a way to convey support for specific application features. These AVPs are exchanged on an end-to-end - basis and known only by the application supporting them. The use of + basis and known only by the applications supporting them. The use of such AVPs must obviously be limited to convey functionality of the applications itself. Examples of this can be found in [2] and [3]. This method can be used to resolve some of the problems described in Section 6.3 and Section 6.2. It is also useful in providing some restrictions and/or guidelines on the how the other functionality - related AVPs can be include in a command to avoid issues described in - Section 4.2.1. Such end-to-end capabilities AVPs can aid in the - following cases: + related AVPs can be included in a command to avoid issues described in + Section 4.2.1. Such end-to-end capabilities exchange AVPs can aid in + the following cases: o Formalizing the way new functionality is added to existing applications by announcing support for it. This makes determining - support for one or more specific functionality less ambiguous. + support for one or more specific functional features less ambiguous. o Provide a way to further negotiate capabilities if allowed by the applications. - o Applications that do not understand the capabilities AVP can - safely ignore it upon receipt. In such case, senders of the AVP + o Applications that do not understand the capabilities exchange AVPs can + safely ignore them upon receipt. In such case, senders of the AVPs can also safely assume the receiving end-point does not support - any functionality carried by the AVP if it is not present in + any functionality carried by the AVPs if they are not present in subsequent responses. Note that this list is not meant to be comprehensive. @@ -659,8 +662,8 @@ Accounting can be treated as an auxiliary application which is used in support of other applications. In most cases, accounting support is required when defining new applications. However, the lack of - clarity in the base protocol document has prevented easy use the base - accounting messages (ACR/ACA). This document provides two(2) + clarity in the base protocol document has prevented easy use of the + base accounting messages (ACR/ACA). This document provides two(2) possible models for using accounting: @@ -685,10 +688,10 @@ accounting server. A split accounting model is a good design choice when: - * The application itself will not define its own unique + o The application itself will not define its own unique accounting commands. - * The overall system architecture permits the use of centralized + o The overall system architecture permits the use of centralized accounting for one or more Diameter applications. From a Diameter architecture perspective, this model should be the @@ -702,20 +705,20 @@ In this model, the accounting messages will use the application ID of the application using the accounting service. The design - implication for this is that the accounting messages is tightly + implication for this is that the accounting messages are tightly coupled with the application itself; meaning that accounting messages will be routed like any other application messages. It would then be the responsibility of the application server - (application entity receiving the ACR message) to send the + (application entity receiving the ACR messages) to send the accounting records carried by the accounting messages to the proper accounting server. The application server is also responsible for formulating a proper response (ACA). A coupled accounting model is a good design choice when: - * The system architecture or deployment will not provide an + o The system architecture or deployment will not provide an accounting server that supports Diameter. - * The system architecture or deployment requires that the + o The system architecture or deployment requires that the accounting service for the specific application should be handled by the application itself. @@ -729,9 +732,9 @@ Internet-Draft Diameter Applications Design Guidelines July 2007 - * The application server is provisioned to use a different + o The application server is provisioned to use a different protocol to access the accounting server; i.e., via LDAP, XML - etc. This includes attempting to supporting older accounting + etc. This includes attempting to support older accounting systems that are not Diameter aware. In all cases above, there will generally be no direct Diameter @@ -745,7 +748,7 @@ specific accounting records. Additionally, the application ID in the message header and - Accounting-Application-Id AVP are populated depending on the + Acct-Application-Id AVP are populated depending on the accounting model used for a specific application, as described in [1]. Therefore, application designers have to specify the accounting model used to guarantee proper routing of accounting requests. @@ -766,7 +769,7 @@ o Backward compatibility: Dealing with existing applications that do not understand the new extension. Designers also have to make - sure that new extensions do not break expected message delivery + sure that new extensions do not break the expected message delivery layer behavior. o Forward compatibility: Making sure that the design will not @@ -800,7 +803,7 @@ 6.3. Updating an existing Application An application that is being upgraded must follow the same rules - mentioned Section 4. Even if the new version is fundamentally the + mentioned in Section 4. Even if the new version is fundamentally the same application, allocation of a new application ID is possible if it meets those criteria. @@ -808,12 +811,12 @@ this approach is chosen, it is recommended that the optional AVP is used specifically to indicate version information only and nothing else. Additionally, the use of too many optional AVPs to carry - application enhancements should be avoided since such approach has a + application enhancements should be avoided since such an approach has a tendency to become unmanageable and introduce interoperability issues. These pitfalls are discussed in Section 4.2.1 For the same reason, care should be taken in attempting to justify - allocation of new application ID for every change. The pitfalls of + allocation of a new application ID for every change. The pitfalls of this approach is discussed in Section 5.3. Acceptable techniques can be used to provide feature upgrades to @@ -850,7 +853,7 @@ o Application design should consider some form of redundancy. Session state information is the primary data necessary for - backup/recovering endpoints to continue processing for an + backup/recovering endpoints to continue processing of an previously existing session. Carrying enough information in the messages to reconstruct session state facilitates redundant implementations and is highly recommended. @@ -858,18 +861,19 @@ o Application design should segregate message delivery layer processing from application level processing. An example is the use of timers to detect lack of a response for a previously sent - requests. Although the Diameter base protocol defines a watchdog + request. Although the Diameter Base protocol defines a watchdog timer Tw, its use on application level is discouraged since Tw is a hop-by-hop timer and it would not be relevant for end-to-end message delivery error detection. In such a case, it is recommended that applications should define their own set of - timers for such purpose. + timers for such a purpose. + o Applications should specify AVPs which could be used to further - aid in duplication detection. In some cases, when extending an + aid in duplicate detection. In some cases, when extending an application, existing AVPs can be reused to provide additional - duplication detection indicators; i.e., combination of Session-Id + duplicate detection indicators; i.e., combination of Session-Id and CC-Request-Number AVPs in the Diameter Credit Control - application [4]. In cases where the extensions needs to define + application [4]. In cases where the extensions need to define new AVPs, it is recommended that the new AVPs be used only for this purpose. @@ -881,9 +885,9 @@ 8. Security Considerations - This document does provides guidelines and considerations for - extending Diameter and Diameter applications. It does not define nor - address security related protocols or schemes. + This document provides guidelines and considerations for + extending Diameter and Diameter applications. It neither defines + nor addresses security related protocols or schemes. 9. Acknowledgments --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Ycz6tD7Th1CMF4v7-- From dime-bounces@ietf.org Mon Jul 30 12:00:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXfe-0007g4-Cl; Mon, 30 Jul 2007 12:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXfX-0007Tx-8m for dime@ietf.org; Mon, 30 Jul 2007 12:00:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXfW-0001KL-13 for dime@ietf.org; Mon, 30 Jul 2007 12:00:27 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 09:00:24 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKKnrUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="191156525:sNHT3058822602" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UG0Mcm026084; Mon, 30 Jul 2007 09:00:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UG0MA8022511; Mon, 30 Jul 2007 16:00:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 09:00:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Vendor-Specific Commands Date: Mon, 30 Jul 2007 09:00:27 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63BD3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <46ADDDBA.4030605@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfSp8Mbio2lB2fxRsO6mX10uHPHLAAGtM5w References: <9cf5ced20707271229r34608ba6m2151e8083230e764@mail.gmail.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A6E@xmb-sjc-215.amer.cisco.com> <46ADDDBA.4030605@tari.toshiba.com> From: "Glen Zorn \(gwz\)" To: "Victor Fajardo" X-OriginalArrivalTime: 30 Jul 2007 16:00:22.0306 (UTC) FILETIME=[BC01A020:01C7D2C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=812; t=1185811223; x=1186675223; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Vendor-Specific=20Commands |Sender:=20; bh=BbynfcUB8n/q5ryg0B2gReISdMoB7OgTd5Dma66KW/s=; b=QRx1PEtmvwF4rjVd+PzqUnoXtM9XQPI1QbrI+ADvMg+4KF99NK52/DtUdlNFTQMFBicqj+Jq 4z/qyc2AMCSsWwq7NgW20O9IJFUj2uLTvmij9HfLFarAlk8I8PGdE86E; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor Fajardo allegedly scribbled on Monday, July 30, 2007 5:47 AM: > Thanks for the proposal. I am in favor of allocating a > vendor-specific command as well though I'm waiting to hear legitimate > concerns before closing the issue. =20 >=20 >> The values 16,777,216 - 4,294,967,295 (0x1000000 - 0xffffffff) are >> reserved for vendor-specific command codes, to be >> allocated on a First Come, First Served basis by IANA [RFC2434]. >>=20 >=20 > Some adjustments to the proposed vendor-specific command space: range > can be between 8,388,607 - 16,777,213 (7fffff - 0xfffffd) .=20 Okee-dokee. > Half the command space should be sufficient=20 I would expect so. >unless some folks have reasonable objections. =20 >=20 > regards, > victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 13:28:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ2I-0001db-IB; Mon, 30 Jul 2007 13:28:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ2H-0001dP-1f for dime@ietf.org; Mon, 30 Jul 2007 13:28:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZ2G-0003cU-Db for dime@ietf.org; Mon, 30 Jul 2007 13:28:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 10:28:00 -0700 X-IronPort-AV: i="unknown"; a="389062607:sNHT0" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UHRxOf018244; Mon, 30 Jul 2007 10:27:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UHRqAO018700; Mon, 30 Jul 2007 17:27:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:27:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] author list on RFC 3588bis Date: Mon, 30 Jul 2007 10:28:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B63C70@xmb-sjc-215.amer.cisco.com> In-Reply-To: <46AD9A3C.3000909@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] author list on RFC 3588bis Thread-Index: AcfSf3tcVDG/HFloQTuIW7iNCjIhcgATg9SA References: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A79@xmb-sjc-215.amer.cisco.com> <46AD9A3C.3000909@gmx.net> From: "Glen Zorn \(gwz\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jul 2007 17:27:56.0103 (UTC) FILETIME=[F7836D70:01C7D2CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2198; t=1185816479; x=1186680479; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20author=20list=20on=20RFC=203588bis |Sender:=20; bh=7Sd6Ubc6rcwIEVl+3LtQ1JvMhfvAaHPJQMwEJ3raxG4=; b=GyRCrAysIYforaUo5R/RixjwZI6oiTIZVppWlnrjdNPjGJBxnQZrdrukt5Ssb31PisXaPFvT 4KqFGuzNOb8SmOfNO67STLx/ik1smzI8ckWpgMt7e/CdDSY6eU91Ch09; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes Tschofenig allegedly scribbled on Monday, July 30, 2007 12:59 AM: > Very easy answer: >=20 > When we started the work on the document I sent a mail to the > previous authors and asked whether they are willing to spend time > working on the document. =20 > A couple of months I resend that mail because only John and Jari > replied. If I recall it correctly then I never got a response from > anyone else. =20 > In my mail I furthermore said: "If you say YES now and you don't do > work then I will remove you."=20 >=20 > My impression was that if someone does not want to reply to my mail > then he might not be able to spend too much time on working with the > draft update either.=20 What are the criteria for adding or deleting authors? It might be better to add/remove authors based upon what they _actually_ do, rather than what they claim they will do ;-). FYI, these are the criteria I have used for documents:=20 1) if you provide actual text that is used, you are an Author 2) if you provide text that is not used or extensive comments (basically showing that you have spent some serious time on the doc), you are a Contributor 3) if you do any work at all (reviewing the document, finding typos, etc.), you get an Acknowledgement It might seem that this policy would lead to an explosion of authors but in my experience this has not been the case, just because so few people are actually willing to spend time on word craft. >=20 > So far, Victor did an extremely good job in working through the > issues in a very transparent fashion. Hence, he is the editor of the > document.=20 Undoubtedly the right thing. =20 >=20 > Ciao > Hannes >=20 > Glen Zorn (gwz) wrote: >> Just out of curiosity, how were the two surviving authors of 3588 >> chosen to survive?=20 >>=20 >> Nuclear power: more toxic than Britney Spears >>=20 >> ~gwz >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> --=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 30 15:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFaq0-0000am-1P; Mon, 30 Jul 2007 15:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFapy-0000aH-K1 for dime@ietf.org; Mon, 30 Jul 2007 15:23:26 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFapx-0006sG-5L for dime@ietf.org; Mon, 30 Jul 2007 15:23:26 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l6UJN3UH031486 for ; Mon, 30 Jul 2007 15:23:03 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46AE3A97.20003@tari.toshiba.com> Date: Mon, 30 Jul 2007 15:23:03 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-app-design-guide-02.txt References: <20070730153415.GD32476@noir.netzwert.ag> In-Reply-To: <20070730153415.GD32476@noir.netzwert.ag> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: e05124dbe0e171b371ff9d88326a1ab7 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Alexis, Thanks for the review. I'm also waiting on reviews from others. Hopefully, we can get a better looking material in the next rev. regards, victor > Dear all, > please find attached the patch of an editorial review of > draft-ietf-dime-app-design-guide-02.txt. The reviewed document, the > attached patch, as well as the rfcdiff is also available at: > http://www.surryhill.net/ietf/dime/ > > Note, that some corrections suggested in the review are merely > stylistic to improve readability from my point of view. > > > Victor: In case the draft is also available in rfc2629 format I'd > gladly provide patches containing the suggestions for the XML. > > Best regards, Alexis. > > ------------------------------------------------------------------------ > > --- draft-ietf-dime-app-design-guide-02.txt 2007-07-27 12:56:30.368692000 +0200 > +++ draft-ietf-dime-app-design-guide-02-reviewed.txt 2007-07-30 15:32:51.706292255 +0200 > @@ -81,7 +81,7 @@ > 5.1. Rules in Allocating new Command Codes . . . . . . . . . . 10 > 5.2. Justifying the Allocation of Application-Id . . . . . . . 11 > 5.3. Use of Application-Id in a Message . . . . . . . . . . . . 11 > - 5.4. Application Specific Session Statemachine . . . . . . . . 11 > + 5.4. Application Specific Session State Machine . . . . . . . . 11 > 5.5. End-to-End Applications Capabilities Exchange . . . . . . 12 > 6. Other Design Considerations . . . . . . . . . . . . . . . . . 12 > 6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 12 > @@ -125,20 +125,20 @@ > 2. A new Diameter application is being defined by reusing an > existing application. > > - 3. A completely new application is being defined that has no > + 3. An entirely new application is being defined that has no > dependencies to any existing applications. > > 4. A new generic functionality is being defined that can be reused > across different applications. > > - All of these choices are design decisions that can done by any > + All of these choices are design decisions that can be done by any > combination of reusing existing or defining new commands, AVPs or AVP > values. The objective of this document is the following: > > o Clarify updated Diameter extensibility rules in the Diameter Base > - Protocol. > + protocol. > > - o Clarify usage of certain Diameter functionality which are not > + o Clarify usage of certain Diameter functionality which is not > explicitly described in the Diameter Base specification. > > o Discuss design choices and provide guidelines when defining > @@ -147,11 +147,11 @@ > o Present tradeoffs of design choices. > > These guidelines are necessary since the existing rules do not cover > - the ambiguity that exist when some of the design choices overlap. A > + the ambiguity that exists when some of the design choices overlap. A > typical example would be deciding between item one(1) and two(2) > above when an application designer requires a new application > functionality which has many things in common with an existing > - application. Certain ambiguous aspects of such cases was not > + application. Certain ambiguous aspects of such cases were not > foreseen in the existing extensibility rules; i.e., use of optional > AVPs to differentiate new functionality in the old application versus > defining a new application and importing the existing set of > @@ -170,10 +170,10 @@ > > > to create a new application would result in the allocation of a new > - application ID which often times is foreseen as cumbersome by > - application designers because of the lengthy process. Designers > - therefore tend to circumvent the better approach leading to many > - compromises in the design that eventually lead to interoperability > + application ID which is often considered as cumbersome by > + application designers because of the lengthy process involved. > + Designers therefore tend to evade the better approach leading to many > + compromises in the design that will eventually lead to interoperability > issues (See Section 5.1). > > The basic issue is that the rules defined in the Diameter Base > @@ -183,7 +183,7 @@ > no clear answer on whether to even define a new application or not. > At worst, some existing Diameter applications that had purposely been > derived from another existing application resulted in some in- > - appropriate design decision where both the existing application and > + appropriate design decision where both the existing applications and > the derived applications are no longer interoperable under certain > conditions. Note that it is not always possible to offer a complete > and concise answer to certain design choices but at the least, this > @@ -201,7 +201,7 @@ > protocol is a two-layer protocol. The lower layer is mainly > responsible for managing connections between neighboring peers and > for message routing. The upper layer is where the Diameter > - applications reside. This model is inline with a Diameter node > + applications reside. This model is in line with a Diameter node > having an application layer and a peer-to-peer delivery layer. The > Diameter Base protocol document completely defines the architecture > and behavior of the message delivery layer and then provides the > @@ -225,39 +225,39 @@ > Internet-Draft Diameter Applications Design Guidelines July 2007 > > > - of an existing Diameter applications. This section discusses the > + of an existing Diameter application. This section discusses the > rules on how such reuse can be done. > > - When reusing existing applications, the requirements of the new > - applications are typically not completely unique and there are > - existing application's that can be reused to solve some or all of the > - application requirements. Therefore, there is a greater likelihood > + When reusing existing applications, the requirements for the new > + application are typically not completely unique and there are > + existing applications that can be reused to solve some or all of the > + application's requirements. Thus, there is a greater likelihood > of ambiguity on how much of the existing application can be reused, > to what extent and what the implications for both the new and > - existing application. To broadly categorize, the rules for reusing > + existing application are. To broadly categorize, the rules for reusing > existing applications can be either: > > 1. Minimal - which typically means adding optional AVPs to existing > commands. > > 2. Invasive - where addition or deletion of commands and/or AVPs, > - and/or AVP values. > + and/or AVP values is necessary. > > > Because it can fundamentally change the application, the latter > approach has strict repercussions. Specifically, it would result in > the definition of a new application and therefore allocation of a new > application ID is required. Discussion about the specific Diameter > - Base protocol rules associated with this approach are covered > + Base protocol rules associated with this approach are covered in > subsequent sections. > > The former approach, although simple, has pitfalls. The problems > arise when there is a tendency by applications designers to keep > - adding optional AVPs to existing command so they can circumvent the > + adding optional AVPs to existing commands so they can circumvent the > rules associated with the latter approach. Specifically, some > - designers want to circumvent the standardization process associated > + designers merely want to avoid the standardization process associated > with these rules and not necessarily the rules themselves. The > - pitfalls associated with this approach is described further in > + pitfalls associated with this approach are described further in > Section 4.2.1. Additionally, if designers choose this approach, all > of the functionality of the existing application will be inherited > even if the new usage has no intent of using some of the existing > @@ -267,7 +267,7 @@ > > This section discusses the reuse of existing applications by adding > and/or deleting commands from the application. This scenario is > - categorize as "Invasive" in Section 4 and would always result in the > + categorized as "Invasive" in Section 4 and would always result in the > creation of new applications when the rules are applied. > > > @@ -284,17 +284,17 @@ > 4.1.1. Adding a new command > > The rules are strict in this case. Adding a command to an > - application is not allowed and doing so will force a definition of a > + application is not allowed and doing so will force the definition of a > new application. However, if this is the intent, then the new > application can be created by defining a new command for an existing > application or importing an existing command from another application > so as to inherit some or all of the functionality of that > application. In the former case, the decision is straight forward > - since this is typically a result of adding new functionality that > + since this is typically the result of adding new functionality that > does not yet exist. See Section 5.1 for rules on how to allocate new > command codes for new applications. The latter case would result in > a new application but it has a more subtle issue such as deciding > - whether importing of commands and functionality is really better than > + whether importing commands and functionality is really better than > simply using the existing application as it is in conjunction with > any new application. > > @@ -303,7 +303,7 @@ > during the design phase; one model would reuse existing Diameter EAP > application combined with a new Diameter MIPv6 application to form a > complete authentication and authorization scheme and another would be > - to reuse Diameter EAP like commands within the new Diameter MIPv6 > + to reuse Diameter EAP-like commands within the new Diameter MIPv6 > application to accomplish the same result. In this case, the latter > model was chosen which would permit the reuse of commands and/or AVPs > from one application to another. Other applications such as Diameter > @@ -317,17 +317,17 @@ > o Can the new functionality be fulfilled by creating a new > application independent from the existing applications ? In this > case, a deployment architecture could be designed such that both > - old and new application can work independent of but cooperating > - with each other. > + the old and new application can work independently while still > + cooperating with each other. > > - o Can the existing application be reused as is without fundamental > + o Can an existing application be reused as is without fundamental > changes; i.e. a non-mandatory optional AVP is sufficient to > indicate support for new optional functionality if any. There are > pitfalls to this as well. See Section 4.2.1 > > o Care should be taken to avoid a liberal method of importing many > commands that results in a monolithic and hard to manage > - application which supports many different functionality. > + application which supports a lot of different functionality. > > > > @@ -337,33 +337,34 @@ > Internet-Draft Diameter Applications Design Guidelines July 2007 > > > - o Will the new feature or functionality refers only to semantic or > - statemachine changes in the application requiring extra message > + o Will the new feature or functionality refer only to semantic or > + state machine changes in the application requiring extra message > round-trips ? In such cases, definition of new commands may not > - be necessary and use of existing commands maybe sufficient. > + be necessary and use of existing commands might be sufficient. > + > o Reuse of existing applications would result in a distributed > environment which may not be conducive to certain requirements of > the applications; i.e. security and or deployment difficulties - > because of Diameter routing, messages for different applications > providing service to the same user may end up in different servers > - would then need to be co-related. This could mean extra signaling > + would then need to be co-related. This could imply extra signaling > between application servers. A typical example would be the > initial proposal for Diameter MIPv6 split scenario (see [2]) where > - authorization and authentication is separated. > + authorization and authentication are separated. > > Note that accounting commands normally require special treatment and > would not necessarily fall into this category. See Section 6.1. > > 4.1.2. Deleting a command > > - Although this is not typical, deleting an command from an existing > + Although this is not typical, deleting a command from an existing > application is fundamentally changing the application. In general, > - the implications of this approach is the same as Section 4.1.1 > + the implications of this approach are the same as in Section 4.1.1 > regardless of whether new commands will also be added to the > resulting application. In general, it is unusual to delete an > - existing command from an existing for the sake of deleting it or the > - functionality it represents. This design decision would normally be > - an indication of a flawed designed. An exception might be if the > + existing command from an existing application for the sake of deleting it > + or the functionality it represents. This design decision would normally be > + an indication of a flawed design. An exception might be if the > intent of the deletion is to create a newer version of the same > application which is somehow simpler than the previous version. In > that case, the considerations in Section 6.3 should apply instead. > @@ -374,16 +375,17 @@ > Specifically, it discusses rules in adding and/or deleting AVPs from > an existing command of an existing application. Unlike Section 4.1, > the cases in this section may not necessarily result in the creation > - of new application(s). In some cases, there are a lot of ambiguity. > - So design considerations have been outline to ease the decision > + of new application(s). In some cases, there is a lot of ambiguity. > + So design considerations have been outlined to ease the decision > making process. > > 4.2.1. Adding AVPs to a command > > Based on the rules in [1], AVPs that are added to an existing command > can be categorized into: > + > o Mandatory to understand AVPs. As defined in [1], these are AVPs > - which has their M-bit flag set which means Diameter nodes that > + that have their M-bit flag set which means a Diameter node that > receives these AVPs has to understand not only their values but > > > @@ -394,12 +396,13 @@ > > > their semantics and usage as well. This is regardless of whether > - these AVPs are required or optional to appear in the command; as > - specified by the commands ABNF. > - o Non-mandatory AVPs that are also optional in the commands ABNF. > + these AVPs are required or optional within the command; as > + specified by the command's ABNF. > > - The rules are strict in the case where the AVPs to be added is > - mandatory. A mandatory cannot be added to or deleted from an > + o Non-mandatory AVPs that are also optional in the command's ABNF. > + > + The rules are strict in the case where the AVPs to be added are > + mandatory. A mandatory AVP cannot be added to or deleted from an > existing command. [1] states that doing so would require the > definition of a new application. This falls into the "Invasive" > category described in Section 4. Despite the clarity of the rule, > @@ -407,9 +410,9 @@ > added should be mandatory to begin with. There are several questions > that application designers should contemplate when trying to decide: > > - o Does the AVPs change the state machine of the application ? > + o Does the AVP change the state machine of the application ? > > - o Would the presence of the AVPs cause additional message round- > + o Would the presence of the AVP cause additional message round- > trips; effectively changing the state machine of the application ? > > o Will the AVP be used to fulfill new required functionality ? > @@ -421,18 +424,18 @@ > application related information as well as be used to indicate > that the message is for a new application ? > > - If one or more of the above conditions are true, the AVP is consider > + If one or more of the above conditions are true, the AVP is considered > mandatory. These questions are not comprehensive in any way but in > all cases the semantics of the application must change to justify the > use of mandatory AVPs. > > - The rules are less restrictive when adding Non-mandatory, optional > + The rules are less restrictive when adding non-mandatory, optional > AVPs. This falls into the "Minimal" category described in Section 4. > However, care should also be taken when opting for optional AVPs > instead of mandatory AVPs simply to avoid the process of creating a > - new applications. Optional AVPs that answers any of the questions > - above also have consequences. Some of the issues associated with > - using optional AVPs are: > + new application. Optional AVPs that answer any of the questions > + above affirmatively also have consequences. Some of the issues > + associated with using optional AVPs are: > > o Use of optional AVPs with intersecting meaning; one AVP has > partially the same usage and/or meaning as another AVP. The > @@ -462,7 +465,7 @@ > Although this scenario is not as common, the deletion of AVPs from a > command ABNF is significant when trying to extend an existing > application. Deletion can again be categorized between mandatory and > - non-mandatory optional AVPs described in Section 4.2.1. > + non-mandatory, optional AVPs as described in Section 4.2.1. > > In the unlikely event that an application designer would require that > mandatory AVPs must be deleted then it constitutes a fundamental > @@ -471,23 +474,23 @@ > application since it dictates changes in the behavior and semantics > of an application. > > - Instead of deleting commands, a better alternative would be to define > + Instead of deleting AVPs, a better alternative would be to define > a new command that would represent the new behavior. Reusing the > same command code for different use cases can lead to more confusion > - since the command will have different semantics depending on usage. > - This is especially true to base protocol commands (session related > + since the command will have different semantics depending on its usage. > + This is especially true for base protocol commands (session related > commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are > being used by many different applications. > > The deletion of an optional AVP may not necessarily indicate > - allocation of a new application. Deletion of non-mandatory optional > - AVPs with a zero(0) minimum occurrence in the commands ABNF would not > + allocation of a new application. Deletion of non-mandatory, optional > + AVPs with a zero(0) minimum occurrence in the command's ABNF would not > require a new application. In the case where an optional AVP has a > - minimum occurrence of at least one(1) in the commands ABNF, then > + minimum occurrence of at least one(1) in the command's ABNF, then > deletion of the AVP would effectively change the behavior of the > application. It would be similar to the deletion of mandatory AVPs. > Such cases are highly dubious to begin with since those AVPs already > - exhibits properties of mandatory AVPs. Extra consideration should be > + exhibit properties of mandatory AVPs. Additional consideration should be > given as to why it was not defined as mandatory in the first place > and that decision may have to be corrected as well. > > @@ -508,20 +511,20 @@ > 4.3. Reusing Existing AVPs > > This section deals with even more granularity than Section 4.1 and > - Section 4.2. Specifically, it discusses rules in adding, deleting or > + Section 4.2. Specifically, it discusses rules for adding, deleting or > modifying the specified values of an AVP. The rules state that > modifying the value of an AVP is allowed only if it does not change > - the semantics of the AVP and the application using it. Otherwise, > - the change can be consider "Invasive" as described in Section 4 and > - require definition of a new application. Note that designers should > + the semantics of the AVP and the applications using it. Otherwise, > + the change can be considered "Invasive" as described in Section 4 and > + requires definition of a new application. Note that designers should > consider Section 5.2 when contemplating on these types of changes. > > Typically, the data types of the AVPs in question are scalar in > - nature and each ordinal value represent a specific semantic behavior > - of the application. An example is CC-Request-Type AVP of [4]. > + nature and each ordinal value represents a specific semantic behavior > + of the application. An example is the CC-Request-Type AVP of [4]. > Adding, deleting or modifying known values of this AVP can modify the > behavior of the application itself. Additionally, the mandatory and > - optional AVPs rules are inherited from Section 4.2. So this affects > + optional AVP rules are inherited from Section 4.2. So this affects > the decision for defining new applications as well. > > > @@ -530,19 +533,19 @@ > The general theme of Diameter extensibility is to reuse commands, > AVPs and AVP values as much as possible. However, some of the > extensibility rules described in the previous section also apply to > - scenarios where a designer is trying to define a completely new > + scenarios where a designer is trying to define an entirely new > Diameter application. > > This section discusses the case where new applications have > - requirements that cannot be filled by existing applications and would > - require definition of completely new commands, AVPs and/or AVP > + requirements that cannot be fulfilled by existing applications and > + would require definition of whole new commands, AVPs and/or AVP > values. Typically, there is little ambiguity about the decision to > create these types of applications. Some examples are the interfaces > defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and > [6]), Sh ([7] and [8]) etc. > > Application design should also follow the theme of Diameter > - extensibility which in this case may mean importing of existing AVPs > + extensibility which in this case may mean importing existing AVPs > and AVP values for any newly defined commands. In certain cases > where accounting will be used, the models described in Section 6.1 > should also be considered. Though some decisions may be clear, > @@ -563,15 +566,15 @@ > > Hopefully this will lessen the tendency to circumvent this process. > The core rules for this process will be introduced in rfc3588bis and > - full description will be added in this section in the next rev of > + a full description will be added in this section in the next rev of > this document] > > 5.2. Justifying the Allocation of Application-Id > > Application designers should avoid justifying the allocation of an > application ID for each new functionality or any change that is made > - to an existing application. Proliferation of application ID can lead > - to confusion and an in-efficient use of the application ID > + to an existing application. Proliferation of application IDs can lead > + to confusion and an inefficient use of the application ID > namespaces. Application designers should always use Section 4 as a > basis for justifying allocation of a new application ID. > > @@ -593,18 +596,18 @@ > its meaning and usage should be segregated only within the > application. > > -5.4. Application Specific Session Statemachine > +5.4. Application Specific Session State Machine > > - Section 8 of [1] provides session statemachines for authentication, > + Section 8 of [1] provides session state machines for authentication, > authorization and accounting (AAA) services. When a new application > is being defined that cannot clearly be categorized into any of these > services it is recommended that the application itself defines its > - own session statemachine. The existing session statemachines defined > - by [1] is not intended for general use beyond AAA services therefore > + own session state machine. The existing session state machines defined > + by [1] are not intended for general use beyond AAA services therefore > any behavior not covered by that category would not fit well. > - Support for server initiated request is a clear example where an > - application specific session statemachine would be needed; i.e. Rw > - interface for ITU-T push model. > + Support for server initiated requests is a clear example where an > + application specific session state machine would be needed; i.e. Rw > + interface for the ITU-T push model. > > > > @@ -619,31 +622,31 @@ > > 5.5. End-to-End Applications Capabilities Exchange > > - It is also possible that applications can use a type of optional > + It is also possible that applications can use some sort of optional > capabilities exchange AVPs as a way to convey support for specific > application features. These AVPs are exchanged on an end-to-end > - basis and known only by the application supporting them. The use of > + basis and known only by the applications supporting them. The use of > such AVPs must obviously be limited to convey functionality of the > applications itself. Examples of this can be found in [2] and [3]. > > This method can be used to resolve some of the problems described in > Section 6.3 and Section 6.2. It is also useful in providing some > restrictions and/or guidelines on the how the other functionality > - related AVPs can be include in a command to avoid issues described in > - Section 4.2.1. Such end-to-end capabilities AVPs can aid in the > - following cases: > + related AVPs can be included in a command to avoid issues described in > + Section 4.2.1. Such end-to-end capabilities exchange AVPs can aid in > + the following cases: > > o Formalizing the way new functionality is added to existing > applications by announcing support for it. This makes determining > - support for one or more specific functionality less ambiguous. > + support for one or more specific functional features less ambiguous. > > o Provide a way to further negotiate capabilities if allowed by the > applications. > > - o Applications that do not understand the capabilities AVP can > - safely ignore it upon receipt. In such case, senders of the AVP > + o Applications that do not understand the capabilities exchange AVPs can > + safely ignore them upon receipt. In such case, senders of the AVPs > can also safely assume the receiving end-point does not support > - any functionality carried by the AVP if it is not present in > + any functionality carried by the AVPs if they are not present in > subsequent responses. > > Note that this list is not meant to be comprehensive. > @@ -659,8 +662,8 @@ > Accounting can be treated as an auxiliary application which is used > in support of other applications. In most cases, accounting support > is required when defining new applications. However, the lack of > - clarity in the base protocol document has prevented easy use the base > - accounting messages (ACR/ACA). This document provides two(2) > + clarity in the base protocol document has prevented easy use of the > + base accounting messages (ACR/ACA). This document provides two(2) > possible models for using accounting: > > > @@ -685,10 +688,10 @@ > accounting server. A split accounting model is a good design > choice when: > > - * The application itself will not define its own unique > + o The application itself will not define its own unique > accounting commands. > > - * The overall system architecture permits the use of centralized > + o The overall system architecture permits the use of centralized > accounting for one or more Diameter applications. > > From a Diameter architecture perspective, this model should be the > @@ -702,20 +705,20 @@ > > In this model, the accounting messages will use the application ID > of the application using the accounting service. The design > - implication for this is that the accounting messages is tightly > + implication for this is that the accounting messages are tightly > coupled with the application itself; meaning that accounting > messages will be routed like any other application messages. It > would then be the responsibility of the application server > - (application entity receiving the ACR message) to send the > + (application entity receiving the ACR messages) to send the > accounting records carried by the accounting messages to the > proper accounting server. The application server is also > responsible for formulating a proper response (ACA). A coupled > accounting model is a good design choice when: > > - * The system architecture or deployment will not provide an > + o The system architecture or deployment will not provide an > accounting server that supports Diameter. > > - * The system architecture or deployment requires that the > + o The system architecture or deployment requires that the > accounting service for the specific application should be > handled by the application itself. > > @@ -729,9 +732,9 @@ > Internet-Draft Diameter Applications Design Guidelines July 2007 > > > - * The application server is provisioned to use a different > + o The application server is provisioned to use a different > protocol to access the accounting server; i.e., via LDAP, XML > - etc. This includes attempting to supporting older accounting > + etc. This includes attempting to support older accounting > systems that are not Diameter aware. > > In all cases above, there will generally be no direct Diameter > @@ -745,7 +748,7 @@ > specific accounting records. > > Additionally, the application ID in the message header and > - Accounting-Application-Id AVP are populated depending on the > + Acct-Application-Id AVP are populated depending on the > accounting model used for a specific application, as described in > [1]. Therefore, application designers have to specify the accounting > model used to guarantee proper routing of accounting requests. > @@ -766,7 +769,7 @@ > > o Backward compatibility: Dealing with existing applications that do > not understand the new extension. Designers also have to make > - sure that new extensions do not break expected message delivery > + sure that new extensions do not break the expected message delivery > layer behavior. > > o Forward compatibility: Making sure that the design will not > @@ -800,7 +803,7 @@ > 6.3. Updating an existing Application > > An application that is being upgraded must follow the same rules > - mentioned Section 4. Even if the new version is fundamentally the > + mentioned in Section 4. Even if the new version is fundamentally the > same application, allocation of a new application ID is possible if > it meets those criteria. > > @@ -808,12 +811,12 @@ > this approach is chosen, it is recommended that the optional AVP is > used specifically to indicate version information only and nothing > else. Additionally, the use of too many optional AVPs to carry > - application enhancements should be avoided since such approach has a > + application enhancements should be avoided since such an approach has a > tendency to become unmanageable and introduce interoperability > issues. These pitfalls are discussed in Section 4.2.1 > > For the same reason, care should be taken in attempting to justify > - allocation of new application ID for every change. The pitfalls of > + allocation of a new application ID for every change. The pitfalls of > this approach is discussed in Section 5.3. > > Acceptable techniques can be used to provide feature upgrades to > @@ -850,7 +853,7 @@ > > o Application design should consider some form of redundancy. > Session state information is the primary data necessary for > - backup/recovering endpoints to continue processing for an > + backup/recovering endpoints to continue processing of an > previously existing session. Carrying enough information in the > messages to reconstruct session state facilitates redundant > implementations and is highly recommended. > @@ -858,18 +861,19 @@ > o Application design should segregate message delivery layer > processing from application level processing. An example is the > use of timers to detect lack of a response for a previously sent > - requests. Although the Diameter base protocol defines a watchdog > + request. Although the Diameter Base protocol defines a watchdog > timer Tw, its use on application level is discouraged since Tw is > a hop-by-hop timer and it would not be relevant for end-to-end > message delivery error detection. In such a case, it is > recommended that applications should define their own set of > - timers for such purpose. > + timers for such a purpose. > + > o Applications should specify AVPs which could be used to further > - aid in duplication detection. In some cases, when extending an > + aid in duplicate detection. In some cases, when extending an > application, existing AVPs can be reused to provide additional > - duplication detection indicators; i.e., combination of Session-Id > + duplicate detection indicators; i.e., combination of Session-Id > and CC-Request-Number AVPs in the Diameter Credit Control > - application [4]. In cases where the extensions needs to define > + application [4]. In cases where the extensions need to define > new AVPs, it is recommended that the new AVPs be used only for > this purpose. > > @@ -881,9 +885,9 @@ > > 8. Security Considerations > > - This document does provides guidelines and considerations for > - extending Diameter and Diameter applications. It does not define nor > - address security related protocols or schemes. > + This document provides guidelines and considerations for > + extending Diameter and Diameter applications. It neither defines > + nor addresses security related protocols or schemes. > > > 9. Acknowledgments > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 31 06:37:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFp6k-0008S7-HX; Tue, 31 Jul 2007 06:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFp6j-0008S1-JB for dime@ietf.org; Tue, 31 Jul 2007 06:37:41 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFp6h-000198-Uv for dime@ietf.org; Tue, 31 Jul 2007 06:37:41 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 31 Jul 2007 12:37:32 +0200 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Jul 2007 12:37:32 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Dime] Update on Diameter Auditing Date: Tue, 31 Jul 2007 12:37:30 +0200 Message-Id: <75404C7727619C4E81A6DABE442E42DD02461FC4@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAEhi/NA= References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> From: Steigerwaldw To: X-OriginalArrivalTime: 31 Jul 2007 10:37:32.0433 (UTC) FILETIME=[CD135010:01C7D35E] X-Spam-Score: -1.0 (-) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, IMHO auditing means not "state recovery". Auditing is more to get the = current state of a system or organisation. A good definition I found on = Wikipedia. Wolfgang T-Systems Enterprise Services GmbH Systems Integration Project & Design, Business Unit Telco Line of Business Products & Services Goslarer Ufer 35, 10589 Berlin=20 Tel. +49 30 -3497 2058=20 Fax +49 391 53475396=20 Mobil +49 171 5664350=20 E-Mail: wolfgang.steigerwald@t-systems.com=20 =20 T-Systems Business Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder*, Albert Henn*, Olaf Heyden, Katrin = Horstmann, Ulrich Kemp*, Axel Knobe, Wilfried Peters*,=20 Dr. Herbert Schaaff, Zvezdana Seeger Handelsregister: Amtsgericht Bonn HRB 6787 Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr. DE50335567 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Gesendet: Montag, 30. Juli 2007 01:33 > An: Ulf Bodin > Cc: dime@ietf.org > Betreff: RE: [Dime] Update on Diameter Auditing=20 >=20 > Ulf Bodin allegedly scribbled=20 > on Sunday, July 29, 2007 1:22 AM: >=20 > > All, > >=20 > > As requested I'm giving a brief update on the Diameter=20 > Auditing work=20 > > at the list (basically the update I gave verbally on Friday's WG > > meeting): =20 > >=20 > >=20 > > There are two individual drafts on the topic; the Diameter Auditing=20 > > requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and the=20 > > State recovery draft, SR (draft-asveren-dime-state-recovery-01). AR=20 > > gives high level requirements for Diameter auditing and contains=20 > > previous work done by Pat Calhoun on defining commads and AVPs for=20 > > auditing. >=20 > This draft is largely indecipherable. Although there may be=20 > requirements in there, I can't find them and there seems to=20 > be no actual description of the problem it's trying to solve.=20 > My _guess_ is that for some unknown reason you are trying to=20 > use the network as a state repository so that it can recover=20 > state after a failure. Is that right? > If so, why is this scheme better than, say, NVRAM? >=20 > > SR provides an analyze of what protocol assisted mechanisms > > can be helfull in performing state recovery. =20 > >=20 > > Some mails have been exchanged in June studying which commands and=20 > > AVPs either defined in Calhouns original work or that=20 > exists in other=20 > > Dimeter specificaitons that could be used or enhanced for protocol=20 > > assisted state recovery (i.e. auditing). >=20 > Maybe part of the problem is the (mis)use of the word auditing. > Thinking that I was ignorant I made a rather extensive search=20 > of dictionaries and was unable to find a definition of the=20 > word "auditing" > that remotely resembled "protocol assisted (sic) state recovery". >=20 > > My intention is to proceed > > that work and before the next IETF meeting collect what=20 > then have been=20 > > done on the mailing list into a draft presenting desired=20 > extensions to=20 > > Dimaeter for protocol assisted state recovery. Based on=20 > that work it'd=20 > > in my view make sence considering taking on Diameter > > protocol assisted state recovery as a WG work item. =20 >=20 > Why? > =20 > >=20 > > BR Ulf > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 31 07:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpj8-0003fg-L6; Tue, 31 Jul 2007 07:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpj6-0003fa-Iu for dime@ietf.org; Tue, 31 Jul 2007 07:17:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFpj3-0002kv-ML for dime@ietf.org; Tue, 31 Jul 2007 07:17:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM100CPVJBMCK@szxga03-in.huawei.com> for dime@ietf.org; Tue, 31 Jul 2007 19:16:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM1008TFJBL4E@szxga03-in.huawei.com> for dime@ietf.org; Tue, 31 Jul 2007 19:16:34 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM100ELBJBKLJ@szxml03-in.huawei.com> for dime@ietf.org; Tue, 31 Jul 2007 19:16:33 +0800 (CST) Date: Tue, 31 Jul 2007 19:16:33 +0800 From: Tina TSOU Subject: Re: [Dime] Update on Diameter Auditing To: gwz@cisco.com, Steigerwaldw Message-id: <012c01c7d364$40594110$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> <75404C7727619C4E81A6DABE442E42DD02461FC4@S4DE9JSAANL.ost.t-com.de> X-Spam-Score: 1.2 (+) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Wolfgang, I agree with you. B. R. Tina +86-755-28972912 (Office) +86-13922884380 (Mobile) Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU J= abber:=20 tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message -----=20 =46rom: "Steigerwaldw" To: Cc: Sent: Tuesday, July 31, 2007 6:37 PM Subject: AW: [Dime] Update on Diameter Auditing Hi Glen, IMHO auditing means not "state recovery". Auditing is more to get the= =20 current state of a system or organisation. A good definition I found = on=20 Wikipedia. Wolfgang T-Systems Enterprise Services GmbH Systems Integration Project & Design, Business Unit Telco Line of Business Products & Services Goslarer Ufer 35, 10589 Berlin Tel. +49 30 -3497 2058 Fax +49 391 53475396 Mobil +49 171 5664350 E-Mail: wolfgang.steigerwald@t-systems.com T-Systems Business Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder*, Albert Henn*, Olaf Heyden, Katri= n=20 Horstmann, Ulrich Kemp*, Axel Knobe, Wilfried Peters*, Dr. Herbert Schaaff, Zvezdana Seeger Handelsregister: Amtsgericht Bonn HRB 6787 Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr. DE50335567 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or=20 confidential. If you are not the intended recipient, you are hereby n= otified=20 that you have received this transmittal in error; any review, dissemi= nation,=20 or copying is strictly prohibited. If you received this transmittal i= n=20 error, please notify us immediately by reply and immediately delete t= his=20 message and all its attachments. Thank you. > -----Urspr=FCngliche Nachricht----- > Von: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Gesendet: Montag, 30. Juli 2007 01:33 > An: Ulf Bodin > Cc: dime@ietf.org > Betreff: RE: [Dime] Update on Diameter Auditing > > Ulf Bodin allegedly scribbled > on Sunday, July 29, 2007 1:22 AM: > > > All, > > > > As requested I'm giving a brief update on the Diameter > Auditing work > > at the list (basically the update I gave verbally on Friday's WG > > meeting): > > > > > > There are two individual drafts on the topic; the Diameter Auditi= ng > > requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and th= e > > State recovery draft, SR (draft-asveren-dime-state-recovery-01). = AR > > gives high level requirements for Diameter auditing and contains > > previous work done by Pat Calhoun on defining commads and AVPs fo= r > > auditing. > > This draft is largely indecipherable. Although there may be > requirements in there, I can't find them and there seems to > be no actual description of the problem it's trying to solve. > My _guess_ is that for some unknown reason you are trying to > use the network as a state repository so that it can recover > state after a failure. Is that right? > If so, why is this scheme better than, say, NVRAM? > > > SR provides an analyze of what protocol assisted mechanisms > > can be helfull in performing state recovery. > > > > Some mails have been exchanged in June studying which commands an= d > > AVPs either defined in Calhouns original work or that > exists in other > > Dimeter specificaitons that could be used or enhanced for protoco= l > > assisted state recovery (i.e. auditing). > > Maybe part of the problem is the (mis)use of the word auditing. > Thinking that I was ignorant I made a rather extensive search > of dictionaries and was unable to find a definition of the > word "auditing" > that remotely resembled "protocol assisted (sic) state recovery". > > > My intention is to proceed > > that work and before the next IETF meeting collect what > then have been > > done on the mailing list into a draft presenting desired > extensions to > > Dimaeter for protocol assisted state recovery. Based on > that work it'd > > in my view make sence considering taking on Diameter > > protocol assisted state recovery as a WG work item. > > Why? > > > > > BR Ulf > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime