Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Oct 2009 10:52:41 +0200

Hi,

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, September 30, 2009 6:54 PM
> To: 'Wes Hardaker'; Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR
> 
> Hi,
> 
> I don't think you can assume all deployemnts use one vendor's 
> tools just because there are no standard PIBs.
> My research showed support in the Juniper/Netscreen products, 
> and in Huawei/HuaweiSymantec products.
> I have no reason to believe all deployments use exclusively 
> one or the other's tools or PIBs.

What I meant to say is that in a given deployments, in the absence of
standards PIBs the agents and managers are probably originating from the
same vendor and using proprietary PIBs. Of course there may be more than
one such vendor in the market. 

> 
> It is safe to assume they may not interoperate across vendor 
> implementations, if that was your point. But that is our 
> fault, when we as a community decided not to allow PIBs onto 
> the standards-track, and effectively told the COPS-PR 
> developers to just go home.
> 

I would probably agree even before the first beer, but I am not sure if
this discussion is useful right now. We are trying to determine whether
to reclassify COPS-PR to Historic, we are not trying to make a
post-mortem. 
 
> In the absence of standard YANG models, any netconf 
> deployments are not all based on one vendor's tools.
> In the absence of standard YANG models, the Netconf 
> deployments using equipment from different vendors and 
> vendor-specific data models are also not interoperable. 
> 
> Is that the point you wanted to make? That interoperability 
> is hindered by not having standards-track models?
> 

Yes. 

> dbh
> 
> > -----Original Message-----
> > From: Wes Hardaker [mailto:[email-masked]]
> > Sent: Wednesday, September 30, 2009 11:51 AM
> > To: Romascanu, Dan (Dan)
> > Cc: David Harrington; [email-masked]; [email-masked]
> > Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR
> > 
> > >>>>> On Wed, 30 Sep 2009 13:14:14 +0200, "Romascanu, Dan
> > (Dan)" <[email-masked]> said:
> > 
> > DR> In the absence of standards PIBs I suspect that the
> > majority or all
> > DR> the deployments use one vendor tools
> > 
> > I don't think you can safely make that argument.  
> Personally, I have 
> > no knowledge about how well COPS or COPS-PR or 
> implementations of MIBs 
> > are/were used.  But I think since the IETF functionally 
> made all the 
> > COPS folks mad by refusing to let them standardize their work (I'm
> not
> > saying whether this was right or wrong; it's simply fact) the end 
> > result was all the COPS folks left the IETF.  If PIBs were indeed 
> > written they certainly wouldn't have been standardized within the 
> > IETF.  Maybe
> the
> > IETFs push-back did really cause the technology to become 
> unused.  I 
> > don't know.  But I don't think you can use any metrics affected by 
> > IETF actions to decide that.
> > --
> > Wes Hardaker
> > Cobham Analytic Solutions
> > 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Oct 2009 10:55:19 +0200

> Sent: Wednesday, September 30, 2009 7:07 PM
> To: Romascanu, Dan (Dan)
> Cc: Wes Hardaker; David Harrington; [email-masked]; [email-masked]
> >>>>> On Wed, 30 Sep 2009 18:01:04 +0200, "Romascanu, Dan 
> DR> I am not sure that I understand the point that you are making.
> 
> The point I was making was that your statement:
> 
> DR> the deployments use one vendor tools and agents
> 
> I don't think is safe to say.  Unless you're saying there are 
> no standard PIBs anywhere (I don't know, personally).  There 
> aren't any in the IETF because the IETF chose not to publish 
> them and actively discouraged their use.  So if there are 
> standard PIBs, we likely wouldn't know about them.
> --
> Wes Hardaker

Hi, 

I hope that I clarified what I meant to say already. Sorry for not being
clear enough. If there are standard PIBs developped out of the IETF
hopefully we shall learn now something about them. 

Dan

---

From: "David Harrington" <[email-masked]>
Date: Thu, 1 Oct 2009 09:55:34 -0400

> hopefully we shall learn now something about them. 

I personally know of no PIBs developed inside or outside the IETF that
are used by multiple vendors.

I don't know if the IETF Informational PIBs are used, or just
proprietary PIBs.
Maybe we can get implementers to contribute some helpful
implementation and deployment information.
That would help IETF make a more informed decision.

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Oct 2009 07:29:21 -0700

>>>>> On Thu, 1 Oct 2009 10:52:41 +0200, "Romascanu, Dan (Dan)" <[email-masked]> said:

DR> We are trying to determine whether to reclassify COPS-PR to
DR> Historic, we are not trying to make a post-mortem.

Trying to do a post-mortem without a body is difficult.  Trying to
determine if we should go historical based on conversations on an IETF
list for a protocol that was pushed out of the IETF is not likely to be
a complete source of information.

I suggest someone who desires to make it historical and wants to put in
the work to make it happen should go ask operators at a bunch of
operator conventions to see if anyone is using it.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 01 Oct 2009 10:43:42 -0400

Hi:
I know of COPS-PR work inside ITU-T (see ITU-T Y.2111).

I believe Juniper may be using COPS-PR in some of their products,
maybe using private PIBs.

CableLab have their way of using COPS in DOCSIS, which I believe
uses both push and pull models.  I don't believe they call it COPS-PR,
but DOCSIS uses some of the COPS-PR features.

Does IETF provide an alternative Policy Management Protocol?

Should IETF be the leader for Policy Management Protocol?

Personally I believe Policy Management is important.

-- Kwok --

At 09:55 AM 10/1/2009, David Harrington wrote:

>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 01 Oct 2009 11:12:08 -0400

I would like to add that Huawei uses COPS-PR.
-- Kwok --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Oct 2009 17:19:40 +0200

Thanks, 

Can you provide any details about the functionality, what devices and
what applications implement it, do they use proprietary PIBs, was
interoperability with other vendors devices and applications ever
tested? 

Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kwok Ho Chan
> Sent: Thursday, October 01, 2009 5:12 PM
> To: Kwok Ho Chan
> Cc: [email-masked]
> >I believe Juniper may be using COPS-PR in some of their 
> products, maybe 
> >using private PIBs.
> >
> >CableLab have their way of using COPS in DOCSIS, which I 
> believe uses 
> >both push and pull models.  I don't believe they call it 
> COPS-PR, but 
> >DOCSIS uses some of the COPS-PR features.
> >
> >> > I hope that I clarified what I meant to say already. 
> Sorry for not 
> >> > being clear enough. If there are standard PIBs developped out of 
> >> > the IETF hopefully we shall learn now something about them.
> >> >
> >> > Dan
> >> >
> >>

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 01 Oct 2009 11:41:13 -0400

I believe Huawei follows the ITU-T functionality requirements for
Policy Management.  Which are available from ITU-T.

-- Kwok --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Oct 2009 17:42:12 +0200

One aspect of this discussion is surprising me a little :-) 

For the record, since I am an AD (March 2006) I have never received a
request for chartering a new PIB work in the IETF. Neither have I
received any legacy instructions from my predecessor Bert Wijnen about
new COPS-PR or PIB being a taboo. I think that I know his position, but
this is not necessarily the same as mine. If I ever had received such a
request I would have considered it without prejudice. It's still true
even now. Probably everybody knows by now that I am not a 'one protocol
fits all' adept. 

Dan

> Sent: Wednesday, September 30, 2009 6:34 PM
> To: [email-masked]; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: [OPS-AREA] Present day reality of COPS-PR
> 
> Hi 
> 
> > From: Paul Duffy [mailto:[email-masked]]
> > Sent: Wednesday, September 30, 2009 9:57 AM
> > To: Romascanu, Dan (Dan)
> > Cc: David Harrington; [email-masked]
> > Subject: Re: [OPS-AREA] Present day reality of COPS-PR
> > 
> > Appreciate the investigation, but also agree it needs to be vetted 
> > (academic versus real world deployments).
> 
> I absolutely agree that the list needs vetting.
> I suspect the claims I have seen might blur the distinction 
> between COPS-PR and "COPS with some COPS-PR-like proprietary 
> extensions"
> 
> > 
> > For example...
> > 
> > - AFAIK COPS, not COPS-PR, is used for DOCSIS/PacketCable 
> DQoS. Hope 
> > the rest of the list correctly makes this distinction.
> 
> I seem to recall vaguely that COPS-PR was in DOCSIS 1.0, but 
> removed from 2.0, IIRC.
> (Or was that SNMPv3?)
> I don't work with DOCSIS standards, so I cannot vet this myself.
> 
> > - I've not been able to locate any open source community
> > - I've located a single vendor, Trillium, that offers support 
> > (embedded in an IMS suite).
> 
> I searched the web and found more than just Trillium. YMMV.
> 
> > - the word from my colleagues @ Cisco is that its time has passed.
> 
> Certainly Cisco pulled the plug on it a long time ago.
> 
> > - etc.
> > 
> > Its pretty clear its not massively deployed.
> 
> Neither is Netconf and YANG.
> And if the IESG refused to allow any YANG models to advance 
> to standards track, because the contents would duplicate MIB 
> content, YANG probably will never get wide deployment.
> Should we declare Netconf and YANG Historic as well?
> Let's use consistent comparisons if Netconf and YANG are the 
> replacement for COPS-PR.
> 
> Please understand. Up until recently I was fully convinced 
> COPS-PR was dead. I didn't think declaring it Historic would 
> make any difference because as far as I knew NOBODY was using 
> it anyway.
> 
> COPS-PR only came up when Washam Fan wrote a LOCK-MIB that 
> included a table for COPS-PR locks (which, as far as I knew, 
> nobody would ever use). It was there for completeness; 
> COPS-PR is an IETF standard that has a lock, and so is 
> Netconf. So they should both be included in the LOCK-MIB. We 
> have LOTS of things in MIB modules that are never used, so 
> having a potential COPS-PR lock represented was largely 
> meaningless and certainly not harmful.
> 
> But the Netconf community stepped up and said "Hey wait! 
> ****we**** have the only IETF-BLESSED solution for 
> configuration. We need to make sure this other thing gets 
> declared Historic so nobody will be tempted to use it instead 
> our solution." I don't think that's the best justification 
> for declaring something Historic.
> 
> At the same time, this WG has been developing a guidelines 
> document, and during IETF Last Call it was made very clear 
> that the OPS-approach to management seems too oriented toward 
> routers and device management, and that approach is NOT 
> IETF-BLESSED as the only approach to management. Netconf and 
> YANG very much follow that approach. So it seems apparent 
> that the Netconf/YANG approach is not IETF-BLESSED as the 
> ONLY way to do configuration management. In fact, the charter 
> for YANG was required to say that it was ONE language, but 
> not the only language, that could be used with netconf. And 
> other areas are working on alternative approaches to configuration.
> 
> So I have a real problem with the desire to declare COPS-PR 
> Historic because Netconf and YANG are BLESSED by the whole 
> IETF to replace COPS-PR. As the editor for the Guidleines 
> document, I had to deal directly with the feedback we got, 
> and I do not believe Netconf and YANG are the BLESSED 
> protocols for doing all configuration in the IETF.
> 
> If you look at COPS-PR, you will also see that COPS-PR does 
> MUCH more than Netconf. The COPS-PR approach is very oriented 
> toward policy-based management, with its policy decision 
> points and policy enforcement points and policy-server 
> discovery and so on. Netconf doesn't provide those features at all.
> 
> I have a history or questioning claims made by the netconf community.
> I actually support netconf and YANG, but I think they really 
> need to stop making inflated claims about what they can do. I 
> think netconf has standardized some very important aspects of 
> configuration, and I think YANG may be a very expressive 
> langugae for data modeling. But they are still unproven in 
> the marketplace. They do not have wide deployment yet. Cisco 
> doesn't seem at all committed to YANG. Huawei implemented 
> Netconf, but have no intention that I am aware of to implement YANG. 
> 
> I question whether Netconf and YANG replace the functionality 
> found in COPS-PR. I think it does not. I was around when 
> COPS-PR came out, and there were aspects that I thought would 
> be useful for management purposes. My background is in NMS 
> systems, and having to poll whole ranges of IP addresses to 
> try to find the devices to manage is a horrible design; 
> letting the devices come to the manager and ask to be managed 
> makes tremendous sense to me. COPS-PR has that; SNMP and 
> Netconf do not.
> 
> I don't want to throw out the baby with the bathwater in this 
> rush to declare COPS-PR Historic. There are features in 
> COPS-PR that we should be looking at to consider what might 
> be good to keep. Declaring the whole thing Historic is not 
> the right way to do that.
> 
> Technologies are converging. I think COPS-PR is more-telco 
> oriented than Netconf is. The OPS area and the IETF in 
> general are in the midst of a debate about allowing multiple 
> protocols to be used to manage networks, rather than trying 
> to force one protocol to be used for all purposes. We are 
> having a discussion of what OAM means in different 
> environments. When COPS-PR came out, we had a philosophy of 
> SNMP-to-do-all-management, and "write a MIB" for all IETF 
> standard protocols. We have grown significantly in our 
> viewpoints since then, and are moving toward a "pick the tool 
> that best does the job you need done". I don't think that 
> declaring COPS-PR Historic at this point in time helps that. 
> Maybe if we allowed PIBs to be standardized, COPS-PR would 
> actually get implemented and deployed on a wider basis. I 
> wouldn't bet on it, but we would be no worse off than we are now. 
> 
> I don't see the problem inherent in allowing COPS-PR and SPPI 
> to remain standards, and allowing PIBs to be standards-track, 
> as long as WGs are not required to write them. We are already 
> allowing WGs to
> "pick the tool    that best does the job you need done" - including
> SNMP, Netconf, Syslog, IPFIX, and others that are being 
> developed in other areas. Maybe WGs would find COPS-PR to be 
> a valuable tool for managing Internet resources, such as 
> applications and services, where Netconf may not be "the best 
> tool". Maybe if PIBs were allowed to be standards-track, 
> somebody would be willing to make the changes to COPS-PR to 
> make it more Netconf-compatible.
> 
> I just feel like we are trying to declare this Historic for 
> the wrong reasons.
> 
> dbh
> 
> > 
> > 
> > Romascanu, Dan (Dan) wrote:
> > > We can write a short cal for input about implementations
> > and deployments
> > > of COPS-PR on the general IETF list, pointing to the
> > discussion going on
> > > in OPSAWG. Certainly such input may also arrive at the time
> > of the IETF
> > > LC but it would be better to know about it earlier. 
> > >
> > > Dan
> > >
> > >
> > >   
> > >> Sent: Wednesday, September 30, 2009 2:22 PM
> > >> To: Romascanu, Dan (Dan); [email-masked]
> > >> Cc: [email-masked]
> > >> Subject: RE: [OPS-AREA] Present day reality of COPS-PR
> > >>
> > >> Hi,
> > >>
> > >> These claims were gathered by me from co-workers familiar with 
> > >> COPS-PR.
> > >> I have not checked any of the claims.
> > >>
> > >> The most interesting to me are the claims of deployment in FIOS, 
> > >> FT-Orange, and Comcast.
> > >> We should seek out people knowledgeable about the 
> technologies used 
> > >> in these networks, and ask about COPS-PR.
> > >> Does anybody have contacts within the IT departments of these 
> > >> companies?
> > >>
> > >> dbh
> > >>
> > >>     
> > >>> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > >>> Sent: Wednesday, September 30, 2009 7:14 AM
> > >>> To: David Harrington; [email-masked]
> > >>> Cc: [email-masked]
> > >>> Subject: RE: [OPS-AREA] Present day reality of COPS-PR
> > >>>
> > >>>  
> > >>> (moving the discussion to OPSAWG). 
> > >>>
> > >>>       
> > >>>> From: [email-masked]
> > >>>> [mailto:[email-masked]] On Behalf Of David
> Harrington
> > >>>>
> > >>>>         
> > >>>>> - there are few, if any, significant deployments.
> > >>>>>
> > >>>>> AFAIK, there is minimal commercial or open source support.
> > >>>>>           
> > >>>> I have not been able to research these claims, but I am
> > told that
> > >>>> COPS-PR is actually in use in a number of places. Here
> > >>>>         
> > >> are some of
> > >>     
> > >>>> the claims I have heard:
> > >>>>
> > >>>> 1) Juniper uses COPS-PR for their resource allocation,
> > using both
> > >>>> push and pull methods, at least in the access and aggregation 
> > >>>> network.
> > >>>> 2) COPS-PR may be deployed in the Verizon FIOS (FTTH)
> > >>>>         
> > >> access network
> > >>     
> > >>>> in the US.
> > >>>> 3) COPS-PR may be deployed in the FT-Orange IPTV access
> > >>>>         
> > >>> network in UK.
> > >>>       
> > >>>> 4) Comcast uses a mix of COPS and COPS-PR in cable TV video QoS
> 
> > >>>> control.
> > >>>> 5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used
> > in cable
> > >>>> deployments
> > >>>> 6) Huawei uses both COPS and COPS-PR in their Quidway RM9000 
> > >>>> Resource Manager and their Multi-Service Control Gateway
> > solution
> > >>>> (public documents show COPS, but I have not found
> > >>>>         
> > >> explicit mention
> > >>     
> > >>>> of COPS-PR; I am checking further)
> > >>>> 7) ITU-T has a proposal being considered that is based on
> COPS-PR
> > >>>>
> > >>>> Searching the Web I found some additional information that
> might 
> > >>>> bear further research (many items have no associated dates):
> > >>>> 8) MultiService Forum has an Implementation Agreement
> > for Dynamic
> > >>>> Policy Control Using COPS-PR (2005)
> > >>>>
> > >>>>         
> > >> 
> >
> http://www.msforum.org/techinfo/approved/MSF-IA-COPS-PR.001-FINAL.pdf
> > >>     
> > >>>> 9) IEEE Xplore has a paper that apparently was presented
> > >>>>         
> > >> at ICT 2008
> > >>     
> > >>>> comparing the performance of COPS-PR and Netconf.
> > >>>> The paper might identify some equipment that has COPS-PR
> support.
> > >>>> 10) A 2006 paper was published in the Proceedings of the IEEE 
> > >>>> International Workshop on Policies for Distributed Systems and 
> > >>>> Networks. The paper considers substituting Netconf and/or
> > >>>>         
> > >> SOAP for
> > >>     
> > >>>> COPS-PR
> > >>>> 11) I found discussion of COPS-PR in JUNOSe and the SAE
> > >>>>         
> > >> on the web,
> > >>     
> > >>>> apparently for the SDX line (dated 2008). Was this from
> > >>>>         
> > >> the Juniper
> > >>     
> > >>>> acquisition of netscreen and neoteris?
> > >>>> 12) Sejong University apparently has developed a COPS-PR lite
> > >>>>
> > >>>>         
> > >>
> http://ietcom.oxfordjournals.org/cgi/content/abstract/E90-B/11/3024
> > >>     
> > >>>> 13) EION has an implementation
> > >>>> http://www.eion.com/protocols/protocols_traffic_cops.html
> > >>>> 14) Cisco Catalyst has an implementation
> > >>>> 15) Wireshark apparently implements it
> > >>>> 16) ACSE Networks implements COPS-PR in their NeuTrans product
> > >>>>         
> > >> line
> > >>     
> > >>>> 17) ZNYX Networks implements COPS-PR in the ZX4900
> > >>>> 18) libsmi implemented it
> > >>>> 19) Operax AB implemented it
> > >>>> 20) MIB Smithy implemented it
> > >>>> 21) GridNet has implemented it in its products for managing
> > >>>>         
> > >> utility
> > >>     
> > >>>> (power) grids
> > >>>> 22) GE apparently embeds the GridNet implementation in its
> WiMax 
> > >>>> SmartMeter and SmartGrid Router family of products
> > >>>> 23) COPS-PR has been the subject of a tremendous number
> > >>>>         
> > >> of academic
> > >>     
> > >>>> papers
> > >>>>
> > >>>>         
> > >>> There claims need to be examined carefully. We need to
> > >>>       
> > >> differentiate
> > >>     
> > >>> between academic papers, code implementation and
> > deployment. It is
> > >>> probably true that a number of open source packages and tools 
> > >>> implemented COPS-PR after it was put on standards track, but the
> 
> > >>> question is to what extent this code was also used and deployed.
> > >>>       
> > >> Same
> > >>     
> > >>> for the vendors implementations - was COPS-PR deployed
> > and how?  In
> > >>> the absence of standards PIBs I suspect that the majority
> > >>>       
> > >> or all the
> > >>     
> > >>> deployments use one vendor tools and agents, but we need to give
> 
> > >>> enough time for these vendors to step ahead and explain in case 
> > >>> interoperability is impacted by the proposed standards action.
> > >>>
> > >>> Dan
> > >>>
> > >>>       
> > >>     
> > >
> > >   
> > 
> > 
> 
>

---

From: Paul Duffy <[email-masked]>
Date: Thu, 01 Oct 2009 13:03:40 -0400

> but DOCSIS uses some of the COPS-PR features.
CableLabs does not use COPS-PR, but they do use COPS.

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 01 Oct 2009 13:32:18 -0400

Does CableLabs usage of COPS include the usage of the Push Model,
the Pull Model, Both?
Thanks!
-- Kwok --

---

From: Paul Duffy <[email-masked]>
Date: Thu, 01 Oct 2009 14:06:34 -0400

I believe its pull

See   
http://www.cablelabs.com/specifications/PKT-SP-DQOS-C01-071129.pdf, 
section 5

Cheers

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Oct 2009 11:07:47 -0700

> even now. Probably everybody knows by now that I am not a 'one protocol

There doesn't seem to be complete consensus to
move this RFC to historic.

I don't really care, but COPS-PR seems to be in use
in places, so we should just go back to ignoring it
in the IETF, and not changing the standards track status at all.

> Dan

Andy

---

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 01 Oct 2009 13:29:37 -0600

A few clarifications regarding the usage of COPS within CableLabs
specifications (thanks to Karthik Sundaresan, cc-ed).

CableLabs does not reference COPS within the DOCSIS specification suite.
Instead it utilizes COPS within two different PacketCable specification
efforts: 
- PacketCable 1.5 Dynamic Quality of Service (DQoS); and,
- PacketCable Multimedia.

Within these specifications COPS is used in conjunction with DOCSIS to
provide Quality of Service to PacketCable components. Both the
specifications mentioned above specify the use of COPS messages, and
normatively reference COPS and COPS-PR. The COPS objects used are according
to COPS. In addition the PCMM specification also aligns with COPS-PR.
 
To clarify the usage:
= PacketCable 1.5 DQoS uses a hybrid push-pull model.
= PacketCable Multimedia uses the Push model.

References:
http://www.cablelabs.com/specifications/PKT-SP-DQOS1.5-I04-090624.pdf
http://www.cablelabs.com/specifications/PKT-SP-MM-I04-080522.pdf

- S

---

From: Tina TSOU <[email-masked]>
Date: Tue, 06 Oct 2009 20:37:54 +0800

Hi,
ITU-T COPS-PR PIB is in ITU-T Q.3303.1.
Tom was the editor. I was the rapporteur, and am the working party  
vice chair and rapporteur.
The link is below.

http://www.itu.int/ITU-T/recommendations/index_sg.aspx?sg=11

Q.3303.1 (08/2007)
Q SERIES: SWITCHING AND SIGNALLING
Signalling requirements and protocols for the NGN - Resource control  
protocols
Title:	
Resource control protocol No. 3 – Protocol at the interface between a  
Policy Decision Physical Entity (PD-PE) and a Policy Enforcement  
Physical Entity (PE-PE): COPS alternative
Provisional name:	Q.rcp3.1
Approval date:	2007-08-06
Status:	In force
Maintenance responsibility:	ITU-T study group 11

B. R.
Tina
http://tinatsou.weebly.com/contact.html