1. Page 1 RSVP-TE based evidence signaling protocol Zafar Ali, Roberto Cassata (Cisco Systems) Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco Diana, Umberto Raimondi (University of Milan) T. Otani (KDDI R&D Laboratories)

2. Page 2 72 nd IETF Meeting, Dublin 2008 Outline Scope Evidence Identification and Collection Optical Evidence Classification Proposed RSVP-TE extensions Evidence signaling scenarios

3. Page 3 72 nd IETF Meeting, Dublin 2008 Scope (I) When a GMPLS LSP fails to deliver user traffic, the failure cannot always be detected by the GMPLS control plane. The scope of this draft focuses where data plane does not provide the OAM functions addressed by this draft. –We assume that OAM mechanisms provided by the underlying data plane technology MUST be used, whenever possible. However, G.709 OAM mechanisms are only applicable to OEO (Optical-Electrical-Optical) capable node. Our draft fills in such gaps; in particular it addresses GMPLS OAM functionality in optical networks with wavelength routers, ROADMs nodes, etc. with no OEO conversion capability.

4. Page 4 72 nd IETF Meeting, Dublin 2008 Scope (II) For this purpose, the draft relies on control plane mechanisms to provide required OAM functions. We propose to add a signaling evidence protocol inside GMPLS based on RSVP-TE to collect and evaluate optical evidence measured over each optical node along the light-path. Specifically the proposed solutions are based on RSVP- TE [RFC3209], [RFC3473] and do not require any extension to the data plane.

5. Page 5 72 nd IETF Meeting, Dublin 2008 Evidence Collection (I) The solution proposed in this draft is control plane based and provides an isolation mechanism for data channel faults. It is based on the idea that for successful fault detection on an optical path, the fault isolation mechanism must be aware of all physical evidence (consisting of optical measurements such as signal power, OSNR, Optical Channel Monitor, etc.) that have effect on the light-path. Such evidence can consist of real optical measurements or estimates computed via a prediction model.

6. Page 6 72 nd IETF Meeting, Dublin 2008 Evidence Collection (II) We extend the RSVP-TE to perform the evidence collection hop by hop. In evidences collection process some evidence may require a mutually exclusive access. –In this case the entire LSP needs to be locked until the evidence collection process is performed. – if another evidence collection process tries to retrieve evidence on the same node-resource already in use, it MUST be aborted. This draft uses RSVP-TE Admin status object to define an Administrative Evidences Locking status for LSP and to make sure that all nodes are ready to collect the evidence in a blocking fashion.

7. Page 7 72 nd IETF Meeting, Dublin 2008 Evidence Collection (III) The collection mode of physical evidence that have effect on the light-path are classified as: –Blocking. In general blocking evidence collection is a physical measurement that may require a mutually exclusive access to hardware resources while performing the measurement. –Non blocking. All physical values that can be probed in parallel with different RSVP-TE. When collection is blocking every optical node can be in one of three states related to a certain resource: unlock, lock-required or lock.

8. Page 8 72 nd IETF Meeting, Dublin 2008 Optical Evidence Encoding Identifies the binary encoding of the specific optical measure to be collected and transported by the protocol Based on ITU Optical Impairments and related measures classification (ITU G.697) Preliminary encoding presented to ITU Q6 on June 25° 2008 (Munich meeting) as WD6-23 –Preliminarily approved by Q6; confirmation requested to Q11 –Single source for all protocols dealing with evidence transport –Final wording on encoding probably to be added to G.697 The present proposal will support the final ITU standard on evidence encoding.

9. Page 9 72 nd IETF Meeting, Dublin 2008 This TLV defines which type of evidence needs to be collected in the Path message. Type: Can be blocking or non blocking type. E-type (Evidence Type, 8 bits): Evidence identifier, for instance: 0 as Signal power, 1 as OSNR, 2 as Pilot Tone. This field is structured according to upcoming ITU standard for encoding [WD6 - 23]. Evidence Collection Request TLV

10. Page 10 72 nd IETF Meeting, Dublin 2008 This TLV encodes the evidence's values of the LSP associated to the evidence type defined in the Evidence Collection Request TLV. WavelengthID: According to [WD6-23], This field identifies the wavelength. If it is measured/estimated aggregate evidence, this field is set to 0. IPv4/IPv6 Address: The address of the Node. Evidence Value: Estimated or measured evidence value according to [WD6-23]. E.g., the Signal Optical Power as 32-bit IEEE 754 floating point number. Will be padded as necessary. Evidence recording TLV

11. Page 11 72 nd IETF Meeting, Dublin 2008 Administrative Status Object extension We propose and extension to Administrative status object by adding two bits for locking purpose Blocking node (B): 1 bit. When set, indicates that locking procedure is ongoing. Confirm blocking (C): 1 bit. When set, indicates that the locking procedure is successfully ongoing.

12. Page 12 72 nd IETF Meeting, Dublin 2008 Non-blocking evidence collection PXC1 PXC2 Path Message Resv Message Evidence Collection TLV Evidences Recording TLV Free Evidence Reading

13. Page 13 72 nd IETF Meeting, Dublin 2008 Blocking evidence collection (all nodes ready for evidence collection) PXC1 PXC2 B=1 C=1 R=1 B=1 C=1 R=1 B=1 C=1 R=1 B=1 C=1 R=0 B=1 C=1 R=0 B=1 C=1 R=0 Free Locked Lock Required

14. Page 14 72 nd IETF Meeting, Dublin 2008 PXC1 PXC2 B=1 C=1 R=1 B=1 C=0 R=1 B=1 C=1 R=1 B=1 C=0 R=0 B=1 C=0 R=0 B=1 C=0 R=0 Free Locked Lock Required Blocking evidence collection (some node(s) blocked by another evidence collection)

15. Page 15 72 nd IETF Meeting, Dublin 2008 Thank You.