Title: Response Liaison Statement on the PCE Working group Date: 22 May 2005 From: Adrian Farrel To: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors Subject: Response Liaison Statement on the PCE Working group For: Action Deadline: July 30th 2005 The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of ITU-T Study Group 15 for their response liaison on the PCE working group. We welcome the prospect of cooperation between our organisations on this subject. Although this liaison may be too late for consideration in your current meeting, we hope that it may be circulated for information, perhaps as a WD, and considered more fully at later meetings. We note your reference to Recommendation G.8080 and observe that there is, indeed, mention of the 'Route Table Query interface' that is used to allow a Signaling Controller to resolve an 'unresolved portion of the route.' Nevertheless, our reading of G.8080 is that the 'Route Table Query interface' exists between the Signaling Controller and the Routing Controller. If this is the case, it does not match the architectural model that we are proposing within the PCE working group. That is, we are making a distinction between the distribution and maintenance of TE routing information by the Routing Controller, and the computation of paths as performed by the Path Computation Element. Thus, in the PCE architecture, there may be a physical separation between the Routing Controller responsible for the routing-plane management of a transport entity (that is the RC entity responsible for announcing local topology information generated by the NE), and the PCE responsible for satisfying Path Computation Requests issued by the Signaling Controller responsible for the signaling-plane management of the transport entity. This means that we are implying a functional separation between the items listed at the head of section 7.3.2 of G.8080 where such a separation is not recognized within the ASON architecture as currently stated. If we have misunderstood the architecture as stated in G.8080 we would appreciate clarification from you. In any case, we would welcome your review and comments on our architecture draft which can be found at http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt Question 6 asked a specific question about the objective metrics referred to in the PCE charter... > Q.6/15 (Characteristics of optical systems for terrestrial transport > networks) noted that your charter contains the following item: > "- Definition of objective metrics to evaluate various criteria such > as the measurement of path quality, response time, robustness and > scalability of path computation models." > > Could you please clarify the meaning of "path quality" in the above > definition? If this includes optical monitoring aspects, please be > aware that ITU-T Q.6/15 has developed a Recommendation, G.697, > Optical monitoring for DWDM systems which may be of interest to the > PCE working group. This Recommendation is currently in force. Path quality in this context is intended to describe what is sometimes termed the 'optimality' of the path ('route' in G.8080 terminology). Measures of path quality reflect the ability of a PCE model to deliver a path that satisfies the constraints specified by the requesting client. One such quality might be 'shortest path', and it should be clear that once Routing Areas or Layered Networks are in use, different computation models will have different abilities to compute shortest paths. Thus, there is no intention to measure the active quality of the 'path' within the data plane: This is out side the scope of the PCE working group. Note that there is also no intention to measure the effectiveness of the algorithms in use (although there is a clear requirement to control the effectiveness according to the requirements of the requester), but rather to measure the likely ability of a particular interaction between PCEs to produce an adequate path. Your liaison goes on to ask a further question about the intentions of the PCE working group with respect to optical path quality. > In addition, we would appreciate a better understanding of whether > the PCE working group will study mechanisms by which optical path > quality can be calculated or only mechanisms for communicating the > results of such calculations. We assume that here, too, you are refering the quality parameters of an established optical trail, and not to the quality of the computed path as expressed above. The PCE working group is limited to the architectural models for computation of paths ('routes') through networks, and will not examine the measurement of optical characteristics. Note, however, that path computation as applied to GMPLS systems falls within the scope of the PCE working group. It is likely that future GMPLS control planes will require to compute paths bearing in mind optical constraints such as (but not limited to) wavelength continuity, dispersion characteristics, etc. In these cases, it will possibly be necessary for some optical characteristic information to be gathered from the data plane, and distributed within the routing plane. These two functions will remain outside the scope of the PCE working group, but may be the responsiblity of other IETF working groups. In this regard, Quesiton 6 may be interested in a new RFC that has been published: RFC 4054 is titled "Impairments and Other Constraints on Optical Layer Routing" and can be found at http://www.ietf.org/rfc/rfc4054.txt Anyone interested in discussing the work of the PCE working group further is invited to join the PCE mailing list. Details can be found at http://www.ietf.org/html.charters/pce-charter.html Best regards, Adrian Farrel and JP Vasseur