Page 1 RSVP-TE based evidence signaling protocol Zafar Ali, Roberto Cassata (Cisco Systems) Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco

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)

Page 272nd IETF Meeting, Dublin 2008

Outline

• Scope

• Evidence Identification and Collection

• Optical Evidence Classification

• Proposed RSVP-TE extensions

• Evidence signaling scenarios


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 da

ta 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.


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.


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.


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.


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.


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.


• 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


• 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


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.


Non-blocking evidence collection

PXC1 PXC2

Path Message Path Message Path Message

Resv Message Resv MessageResv Message

Evidence Collection TLV

Evidences Recording TLV

Free

Evidence Reading


Blocking evidence collection (all nodes ready for evidence collection)

PXC1 PXC2

B=1C=1R=1

B=1C=1R=1

B=1C=1R=1

B=1C=1R=0

B=1C=1R=0

B=1C=1R=0

Free

Locked

Lock Required


PXC1 PXC2

B=1C=1R=1

B=1C=0R=1

B=1C=1R=1

B=1C=0R=0

B=1C=0R=0

B=1C=0R=0

Free

Locked

Lock Required

Blocking evidence collection (some node(s) blocked by another evidence collection)


Thank You.

Documents

Page 1 RSVP-TE based evidence signaling protocol Zafar Ali, Roberto Cassata (Cisco Systems) Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco