rsvp te based evidence signaling protocol n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
RSVP-TE based evidence signaling protocol PowerPoint Presentation
Download Presentation
RSVP-TE based evidence signaling protocol

Loading in 2 Seconds...

play fullscreen
1 / 15

RSVP-TE based evidence signaling protocol - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

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). Outline. Scope Evidence Identification and Collection

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'RSVP-TE based evidence signaling protocol' - anisa


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
rsvp te based evidence signaling protocol

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)

outline
Outline

Scope

Evidence Identification and Collection

Optical Evidence Classification

Proposed RSVP-TE extensions

Evidence signaling scenarios

scope i
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.
scope ii
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
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
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
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
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.
evidence collection request tlv
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
evidence recording 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
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
Non-blocking evidence collection

Evidence Collection TLV

Evidences Recording TLV

Path Message

Path Message

Path Message

PXC2

PXC1

Resv Message

Resv Message

Resv Message

Free

Evidence Reading

blocking evidence collection all nodes ready for evidence collection
Blocking evidence collection (all nodes ready for evidence collection)

B=1

C=1

R=1

B=1

C=1

R=1

B=1

C=1

R=1

PXC2

PXC1

B=1

C=1

R=0

B=1

C=1

R=0

B=1

C=1

R=0

Free

Lock Required

Locked

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

B=1

C=0

R=1

B=1

C=1

R=1

B=1

C=1

R=1

PXC2

PXC1

B=1

C=0

R=0

B=1

C=0

R=0

B=1

C=0

R=0

Free

Lock Required

Locked