Transcript PowerPoint Presentation - スライド 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 1
Outline
•
•
•
•
•
Scope
Evidence Identification and Collection
Optical Evidence Classification
Proposed RSVP-TE extensions
Evidence signaling scenarios
72nd IETF Meeting, Dublin 2008
Page 2
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.
72nd IETF Meeting, Dublin 2008
Page 3
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 RSVPTE [RFC3209], [RFC3473] and do not require any
extension to the data plane.
72nd IETF Meeting, Dublin 2008
Page 4
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.
72nd IETF Meeting, Dublin 2008
Page 5
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.
72nd IETF Meeting, Dublin 2008
Page 6
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.
72nd IETF Meeting, Dublin 2008
Page 7
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.
72nd IETF Meeting, Dublin 2008
Page 8
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].
72nd IETF Meeting, Dublin 2008
Page 9
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.
72nd IETF Meeting, Dublin 2008
Page 10
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.
72nd IETF Meeting, Dublin 2008
Page 11
Non-blocking evidence collection
Evidence Collection TLV
Evidences Recording TLV
Path Message
Path Message
PXC2
PXC1
Resv Message
Path Message
Resv Message
Resv Message
Free
Evidence Reading
72nd IETF Meeting, Dublin 2008
Page 12
Blocking evidence collection (all nodes
ready for evidence collection)
B=1
C=1
R=1
PXC2
PXC1
Free
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
Lock Required
Locked
72nd IETF Meeting, Dublin 2008
Page 13
Blocking evidence collection (some node(s)
blocked by another evidence collection)
B=1
C=1
R=1
PXC2
PXC1
Free
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
Lock Required
Locked
72nd IETF Meeting, Dublin 2008
Page 14
Thank You.
72nd IETF Meeting, Dublin 2008
Page 15