GMPLS extensions to communicate latency as a Traffic Engineering performance metric draft-wang-ccamp-latency-te-metric-00.txt draft-wang-ccamp-latency-te-metric-00.txt Xihua Fu Qilei Wang ZTE Corporation

Background Latency is a key requirement in OTN and MPLS-TP. – The key driver for this is stock/commodity trading applications that use data base mirroring. A few uS can impact a transaction. – Latency and latency SLA is one of the key parameters that these “high value” customers use to select a private line provider. – Therefore it is important to be able to measure latency and communicate latency as a traffic engineering performance metric.

The role of Control Plane Data plane is responsible for measure the latency, which can be provided by different technologies. It is out scope of this document. Control plane is responsible for advertising and collecting the latency value of links and nodes by IGP (e.g., OSPF-TE). Path computation entity is responsible for end-to- end path computation with latency constraint. It could collect latency information along the LSP by RSVP-TE signaling message to verify the total latency at the end node.

Extensions to OSPF-TE/RSVP-TE A new sub-TLV is added behind the top-TLV defined in [RFC 3630] to carry the latency information (e.g., node latency and link latency). This sub-TLV is also added into RRO to accumulate the latency of links and nodes along the E2E LSP. So souce (sink) node can verify the amount latency of the LSP.

Impact from the change of latency Restoration/protection can impact “provisioned” latency. If a provisioned end-to-end LSP latency could not meet the latency agreement between operator and its user, the re-routing could be triggered based on the local policy.

Next steps Refine the document according to the feedback of meeting and mailing list.