As for COPS, its application environment is somewhat similar
to that of PCE but has some problems (if used for PCE applciation)
due to much optimization around its specifics such as:
1) The PEP (client) is the one required to initiate the
connection with a PDP (server). Whereas for PCE
application, either PCE (server) or PCC may initiate
the connection.
2) There requires a synchronization between PEP and PDP for
the policy application with states maintained on both places.
For PCE application, the PCE server is only required to
perform a one-time service for each LSP, without the need
maintain any subsequent states.
3) It requires some work to support a PDP functions as a PEP
and communicates with another PDP. PCEP supports this model
fully.
4) COPS is a server-client protocol, but with code point
heavily dedicated for a specific application. It does not
serve general purpose if any, and to support PCE application,
there would be a large number of extensions, thus defeating
the purpose of reusage.
As a result, I'd favor PECP as a PCE-specific protocol; it is much
cleaner and also light-weighted.
Dean
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Dean Cheng (dcheng)
>Sent: Monday, October 03, 2005 3:30 PM
>To: Adrian Farrel; [EMAIL PROTECTED]
>Subject: RE: [Pce] Choosing the PCE protocol
>
>Hi,
>
> I don't think HTTP is a good candidate for the PCE application
> and here are some weakness one could think of, if it used for
> PCE application:
>
> 1) The HTTP is specifically designed for communications between
> web server and its client, or applications in that nature.
> Although it is possible to add extensions to support PCE
> application, it would require a considerable amount of work.
> That is not worth of the effort given the much smaller and
> narrower application scope of PCE.
>
> 2) The payload of HTTP messages (both request and response)
> is in form of byte stream, which is unstructured comparing
> to the PCEP proposal, where the content is structured
>with objects.
> For the PCE application, the object based format is more
> efficient in terms of processing.
>
> 3) The HTTP does not have unsolicited messages such as Notification
> message and Error message that are defined by PCEP.
>
> 4) PCE architecture allows a PCE functions as a server but also as
> a client communicating with another PCE server. In both cases,
> the same protocol is used. PCEP supports this scenario. There
> requires some work to make HTTP behavior as such.
>
>Dean
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Adrian Farrel
>>Sent: Thursday, September 29, 2005 7:27 AM
>>To: [EMAIL PROTECTED]
>>Subject: [Pce] Choosing the PCE protocol
>>
>>Hi,
>>
>>Three candidate protocols have been brought to my attention for us to
>>consider. These are (in no specific order):
>>- HTTP
>>- PCECP (as draft-vasseur-pce-pcep-02.txt)
>>- COPS
>>
>>I would like to close the nomination period, and move on to
>select our
>>protocol.
>>
>>The best approach will be if supporters of the candidate protocols
>>indicate (briefly) why their proposed protocol is suitable. It would
>>also be helpful if they were frank about what the weaknesses of their
>>proposal are.
>>
>>And please - this is not an election, it is an interview process.
>>
>>Thanks,
>>Adrian
>>
>>PS The reason why JP is keeping quite on this is that he is an author
>>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not
>>occupying the chair during this discussion.
>>
>>
>>
>>
>>_______________________________________________
>>Pce mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/pce
>>
>
>_______________________________________________
>Pce mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
