The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] "Path Computation Server" Definition and Functionality Description
As Jean Philippe has meantioned there are a number of ways how to get the required information to a central place, therefore is is pretty solution/implementation specific and therefore should not be standardized. The information you need heavily depends on the algorithm you want to run in the PCS. The algorithm on the other hand might depend on the type of service request (currently this naturally out-of-scope of the WG) Marcus --On Montag, 25. November 2002 15:08 -0700 Jean Philippe Vasseur <jvasseur@cisco.com> wrote: > Hi, > > At 19:38 25/11/2002 +0200, Chopin He wrote: >> Hi! folks! >> >> I hope this is the right place to ask this stupid MPLS question. >> >> I read couple of I-Ds mentioning "Path Computation Server", But I am a >> bit unclear about its definition and functionality. >> >> So far, PCS is mentioned in many documents [1][2][3][4][5], one example >> of its definition is found as:[1] >> >> "PCS: Path Computation Server (may be any kind of LSR (ABR, ASBR, ...) >> or a centralized path computation server " >> >> This is quite a detailed explaination, but I understand the LSR or ABR >> or ASBR are control plane components; while the centralised path >> computaton server is a management plane component. In some case, (e.g. >> network management), their roles are lardgely different. Is that >> possible to define them seperately? >> >> >> Additionaly, it seems to me that PCS's functionality is to response the >> PCC's Path Computation Request, thus compute the path, and send the >> result back to PCC. This sounds perfect. While I am still a bit >> unclear. What kind of information the PCS need to know? How can the >> PCS get the relevant information? And so on. >> >> E.g. Brunner said in [3]: >> "Definitely the path computation server needs topology information in >> order to perform its task. But how to get that information is out of >> scope of this document. " >> >> I wonder if there are some specification which defines the PCS's >> functionality explicitly? >> >> If not, can somebody take the initiative? >> > > The PCS's role is to compute TE LSP path for which it is not the HE. > Basically, the PCS needs: > - to get information about the topology, the TE resources, .... This can > be done in several ways: downloading those informations from a router > using a Telnet session, having a routing adjacency with a router, ... - > some algorithm(s) to perform TE LSP path computation, > - to provide the computed TE LSP path to the PCC (routers) using Telnet, > a signalling protocol (Ex: [1]) Example 1: PCS= a UNIX station being able > to receive request from routers to compute TE LSP path for primary TE LSP > placement, inter-area TE LSPs, non packet TE LSP paths, bypass tunnel > path computation, ... Example 2: PCS= an ABR (scenario 2 or 4 of draft > http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.t > xt)) for inter-area TE LSP path computation, Example 3: any router is a > PCS to compute the bypass tunnel(s) path for each of its neighbors to > their respective (N)NHOP(s) LSRs. See the distributed bypass tunnel path > computation scenario of > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation > -01.txt > > JP. > > >> Thanks for your time to read this mail. >> >> >> >> Best wishes! >> >> >> -- >> Chopin >> >> >> >> [1] Vasseur JP, et al., "RSVP Path computation request and reply >> messages", <draft-vasseur-mpls-computation-rsvp-03.txt>, IETF work in >> progress, Jun 2002. >> >> [2] JP Vasseur, "IS-IS Path Computation Server discovery TLV", >> <draft-vasseur-mpls-isis-pcsd-discovery-01.txt>, IETF work in progress, >> June, 2002 >> >> [3] M. Brunner, " COPS usage for Path Computation Servers (COPS-PCS)", >> <draft-brunner-mpls-cops-pcs-00.txt>, IETF work in progress, September, >> 2002 >> >> [4] JP Vasseur, Peter Psenak, "OSPF Path Computation Server discovery", >> <draft-vasseur-mpls-ospf-pcsd-discovery-00.txt>, IETF work in progress, >> June, 2002 >> >> [5] JP Vasseur, Peter Psenak, "OSPF Traffic Engineering capability TLVs >> ", <draft-vasseur-mpls-ospf-te-cap-00.txt>, IETF work in progress, >> October, 2002 >> >> >> >> >> > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus
|
|