JP (and PCEP design co-authors),
I wonder if you ever considered using SIP (rfc 3261) as a transport for PCEP (note that I dont mean replacing PCEP with SIP, rather, running PCEP on top of SIP instead of TCP)? After all SIP is a protocol that can create and manage sessions between two or more parties and transfer opaque objects between them that presumably carry a payload of higher layer protocols such as Session Description Protocol (SDP, rfc 2327) or, as I believe, PCEP.
I am not a SIP specialist and, therefore, could be wrong; however, it does seem to me that SIP has a lot of machinery that falls straight under requirements for PCC-PCE communication protocol developed within the PCE WG. To name some of the mechanisms:
1. Authentication of parties and encrypted communication between them;
2. Protection against malicious attacks;
3. Party discovery capability enabled by intrinsic location service. In the context of PCEP it means that one or several PCEs with identical or similar capabilities could be registered under the same name (address-of-record), and PCCs could query one or more SIP registrars and learn about all PCEs on the network. There is a SIP method CAPABILITIES- that is specifically designed to help understanding the peculiarities of accessing a particular party (read PCE) without actually ringing the party. Such service would facilitate:
a) moving a PCE around the network in a transparent for PCCs and other PCEs manner;
b) easy support of backup PCEs;
c) natural computation load distribution (by forking INVITE requests between PCEs sharing the same AOR according to some policy). Note, that if a network has, say, 3 PCEs with identical capabilities and all of them known to PCCs, I dont know how current architecture can guarantee that all PCCs will not use (and possibly kill) one of PCEs with keeping all others idle;
4. Many useful services such as:
a) message forwarding;
b) message re-directing;
c) am_busy_now_will_call_as_soon_as_I_can service, etc.
5. Ability for a PCC to track the process of the request (via provisioning (1xx) messages). For instance, a PCC may receive a message that its request is received and queued, PCE waits for completion of local computations or response(s) from cooperating PCEs, etc.
6. SIP has a CANCEL method specifically design for canceling previously sent requests without causing race conditions, for instance, to avoid situation when the CANCEL request is processed by a PCE before the associated path computation request and, thus, dropped
7. SIP supports conferences, that is, association of many parties. For instance a group of cooperating PCEs could setup such a conference to split responsibilities in satisfying a particular path computation request, and then perform necessary computations in parallel, rather than sequentially with each PCE deciding on its own what paths, path or tree segments it must compute. Cooperation of PCEs is an important scenario described in the PCE architecture; however, there were no discussions so far how this could be achieved. I believe that there will be a need of strong protocol support for such cooperation to happen. Likewise, a PCC may setup a conference with several PCEs at once to decide which of them can satisfy a particular request best.
I also would like to make a couple of observations, which IMO makes SIP worth looking at. Firstly, SIP has a good likelihood to become a protocol of choice for (G)MPLS call control, so why not to reuse the same tool for other purposes? Secondly, SIP could be involved at some later stage of the PCEP development, I mean, we can start running PCEP over TCP and some time later switch to SIP.
What do you think?
Igor
