RSVP-TE%20based%20evidence%20signaling%20protocol - PowerPoint PPT Presentation

View by Category
About This Presentation



Marco Anisetti, Valerio Bellandi, Ernesto Damiani, ... Evidence identifier, for instance: 0 as Signal power, 1 as OSNR, 2 as Pilot Tone. ... – PowerPoint PPT presentation

Number of Views:32
Avg rating:3.0/5.0
Slides: 16
Provided by: yamaguch3
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: RSVP-TE%20based%20evidence%20signaling%20protocol

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 RD

  • 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 data plane technology MUST be used,
    whenever possible. However, G.709 OAM mechanisms
    are only applicable to OEO (Optical-Electrical-Opt
    ical) 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
  • 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
  • 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
  • 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 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.

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

Non-blocking evidence collection
Evidence Collection TLV
Evidences Recording TLV
Path Message
Path Message
Path Message
Resv Message
Resv Message
Resv Message
Evidence Reading
Blocking evidence collection (all nodes ready for
evidence collection)
B1 C1 R1
B1 C1 R1
B1 C1 R1
B1 C1 R0
B1 C1 R0
B1 C1 R0
Lock Required
Blocking evidence collection (some node(s)
blocked by another evidence collection)
B1 C0 R1
B1 C1 R1
B1 C1 R1
B1 C0 R0
B1 C0 R0
B1 C0 R0
Lock Required
  • Thank You.