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

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 RD
  Laboratories)

2
Outline

• Scope
• Evidence Identification and Collection
• Optical Evidence Classification
• Proposed RSVP-TE extensions
• Evidence signaling scenarios

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

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

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

11
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
Non-blocking evidence collection
Evidence Collection TLV
Evidences Recording TLV
Path Message
Path Message
Path Message
PXC1
PXC2
Resv Message
Resv Message
Resv Message
Free
Evidence Reading
13
Blocking evidence collection (all nodes ready for
evidence collection)
B1 C1 R1
B1 C1 R1
B1 C1 R1
PXC1
PXC2
B1 C1 R0
B1 C1 R0
B1 C1 R0
Free
Lock Required
Locked
14
Blocking evidence collection (some node(s)
blocked by another evidence collection)
B1 C0 R1
B1 C1 R1
B1 C1 R1
PXC1
PXC2
B1 C0 R0
B1 C0 R0
B1 C0 R0
Free
Lock Required
Locked
15

• Thank You.