Subject: [Pce] Updated proposed response liaison to ITU-T Study Group 15

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 May 2005 08:25:43 +0100

Hi, 

Thanks for comments on and off the list.
Here is an update to the proposal. 

Final comments soon, please. 

Thanks,
Adrian 

==== 

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. 

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

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce