Integrated Packet-Optical In-Situ OAM
draft-anand-ippm-po-ioam-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Madhukar Anand , Sanjoy Bardhan , Radha Valiveti , Ramesh Subrahmaniam , Carlos Pignataro , Shwetha Bhandari , Randy Zhang , Rajiv Asati | ||
| Last updated | 2018-02-26 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-anand-ippm-po-ioam-00
IPPM Working Group Madhukar Anand
Internet-Draft Sanjoy Bardhan
Intended Status: Informational Radhakrishna Valiveti
Infinera Corporation
Ramesh Subrahmaniam
Individual
Carlos Pignataro
Shwetha Bhandari
Randy Zhang
Rajiv Asati
Cisco Systems, Inc
Expires: August 30, 2018 February 26, 2018
Integrated Packet-Optical In-Situ OAM
draft-anand-ippm-po-ioam-00
Abstract
This document proposes a way to extend in-situ OAM techniques to
include operational data from multiple network layers with a view to
create an integrated record of OAM information as the data flows
between two network entities. An instance of this technique that is
elaborated here focuses on packet-optical networks that are
traditionally transport centric. The mechanisms described are general
enough to allow future extensibility of in-situ OAM techniques into
other non-packet domains.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Anand et al., Expires August 30, 2018 [Page 1]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Terminology . . . . . . . . . . . . . . . . . . . . 3
3. Packet Optical OAM Integration . . . . . . . . . . . . . . . . 4
4. Mechanism Assumptions and Overview . . . . . . . . . . . . . . 5
5. Packet-Optical IOAM Data Types and Formats . . . . . . . . . . 6
5.1 IOAM Packet-Optical Flow Tracing . . . . . . . . . . . . . 6
5.2 IOAM Optical Path Characteristics . . . . . . . . . . . . . 7
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1 Normative References . . . . . . . . . . . . . . . . . . . 10
9.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Anand et al., Expires August 30, 2018 [Page 2]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
1 Introduction
Packet and optical transport networks have evolved independently with
different OAM mechanisms that have to be managed separately.
Consequently, coordinating packet and optical networks for delivering
services such as end-to-end traffic engineering has proved
challenging. To address this challenge, a unified paradigm that
provides an integrated record of OAM information as the data flows
between two network entities that are connected by a multi-layer
network is needed. Further, such a paradigm should provide an
incremental path to complete packet-optical OAM integration while
leveraging existing OAM mechanisms as much as possible in either
domains. This document introduces such a paradigm by extending the
mechanisms defined in [I-D.ietf-ippm-ioam-data].
The key construct to deliver an integrated IOAM across packet and
optical network layers is that of a Multi-layer Border Device
(MLBD). These are nodes in the network that map packet paths to the
optical paths that originate and terminate at the MLBDs. The concept
of MLBD allows for multiple realizations - depending on whether the
packet and optical functions are integrated or not. In one case, the
packet device is distinct from the optical transport device, and the
MLBD is a logical entity that spans these two devices. In this case,
the MLBD functionality is achieved with the help of external
coordination between the packet and optical devices. In another case,
the packet and optical components are integrated into one physical
device, and the co-ordination required for functioning of the MLBD is
performed by this integrated device. It must be noted that in either
case, it is the packet/optical data plane that is either
disaggregated or integrated. Control of the devices can be logically
centralized or distributed in either scenario. The focus of this
document is to define the logical functions of an MLBD without going
into the exact instantiations of the concept.
2. Reference Terminology
IOAM: In-situ Operations, Administration, and Maintenance
MLBD: Multi-layer Border Device
POT: Proof of Transit
FEC: Forward Error Correction
BER: Bit Error Rate
SRLG: Shared Risk Link Group
Anand et al., Expires August 30, 2018 [Page 3]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
3. Packet Optical OAM Integration
Many operators build and operate their networks that are both multi-
layer and multi-domain and provide end-to-end services to their
customers. Due to the nature of the different domains, the
operations and management of the network has always been problematic
and time consuming.
`._ ,'
`. ,'
`-. ,'
P1`.----------------------------- P2
|\ /|
| \ / | Packet
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| \ / |
| \ / | Transport
| \ / |
| ................./ |
| O1 O2 |
| |
| |
O3\ | O6
\ ,'
\ ,'
.......................-
O4 O5
Figure 1: Representation of a packet-optical network
Figure 1 represents a packet optical network in which P1 and P2 are
packet devices that are connected via two optical links comprising of
devices O1 and O2 and with devices O3,...,O6. Devices P1 and P2 are
MLBDs that communicate with other packet devices and also with the
devices in the optical transport domain. Each MLBD would maintain
operational data such as path latency, Bit Error Rate (BER), pre-FEC
counts, FEC corrected words, and Q-factor corresponding to active
optical paths such as {P1, O1, O2, P2}. An MLBD, by the virtue of being
a packet device, also participates in the in-situ OAM techniques as
described in [I-D.ietf-ippm-ioam-data]. To facilitate the OAM
integration of packet and optical network layers, an MLBD parses the
IOAM data fields in a packet earmarked for optical OAM data and inserts
the appropriate OAM information from the optical path corresponding to
Anand et al., Expires August 30, 2018 [Page 4]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
that packet flow. The operations data corresponding to the optical
paths may be obtained by leveraging supported optical OAM techniques.
It must be noted that the IOAM changes proposed in this document are
limited to necessary optical characteristics that are of interest to the
packet domain applications and have the potential to be used for
routing/switching and traffic engineering. It is not intended to be a
mechanism to obtain all supported optical OAM information from optical
devices.
4. Mechanism Assumptions and Overview
The current proposal assumes that the packet and optical network
layers use respective OAM techniques without any modification. There are
also no modifications necessary to data forwarding across the layers.
The only requirement is that an MLBD supports an embodiment of IOAM
mechanisms. It is also assumed that the MLBD performs all functions of a
regular packet IOAM device and there are specific data types allocated
for querying optical OAM data (IOAM optical data type). The mechanism
for supporting the multi-layer IOAM is as follows.
1. An MLBD participates in an in-situ OAM-domain and thus behaves
either as an IOAM transit device, an IOAM encapsulating or an IOAM
decapsulating device as described in [I-D.ietf-ippm-ioam-data].
2. An MLBD participates in all relevant optical OAM mechanisms and
obtains operational data.
3. MLBDs interpret the IOAM optical data type in a data flow, map it
to specific optical operational data, and attach the desired response to
the data packet in an appropriate manner. Specific data formats for
carrying the optical operational data are discussed in the subsequent
sections. There are typically multiple MLBDs at the edges of a optical
network that can process the IOAM optical data type, and depending on
the use-case and the type of optical data requested, a specific MLBD or
a set of MLBDs can respond to the requested data.
(a) Mapping of an optical data type to a specific optical operational
data is assumed to be programmed into an MLBD prior to its use.
(b) It is possible that multiple packets share the same optical
characteristics. In those circumstances, all the associated packet flows
will share the optical OAM data. For example, if traffic from two VLANs
is multiplexed into the same ODU, the ODU-level operational data is
applicable to both the VLANs.
(c) If a specific optical data type maps to multiple optical
Anand et al., Expires August 30, 2018 [Page 5]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
operational data, an MLBD can determine how to communicate that suitably
in response to the request. Options for data consolidation may include
appending all responses, averaging the responses, or picking minimum or
maximum value, or keeping them separate.
Considering the topology in Figure 1, if there is a query for the
aggregate number of post-FEC errors in the optical path(s) between P1
and P2, P1 may choose to send the requested data as an appended list
{FEC1, FEC2} in response, where FEC1 are the aggregate number of post-
FEC errors along the optical path/circuit {P1,O1,O2,P2} and FEC2 are the
aggregate number of post-FEC errors along the path/circuit
{P1,O3,O4,O5,O6,P2}.
(d) If the requested data is not available immediately, the optical
device can request a collection of the requested data upon parsing the
request, and once it is available, the data could be included in a later
packet carrying the same data request. One option to communicate that
the requested data is delayed is by responding to the request with a
standardized special value such as 0xFFFFFFFF that indicates this
scenario. It is to be be noted that this special value is something that
is assumed to be standardized for the specific data queried and known in
advance by all participating IOAM devices.
Considering the example in Figure 1, if there is a query for the optical
path latency in the optical path(s) between P1 and P2, and if P1 only
has the data LAT1 available for the optical path/circuit {P1,O1,O2,P2}
and not for the path/circuit {P1,O3,O4,O5,O6,P2}, it can communicate
{LAT1, 0xFFFFFFFF} in response till the path latency data LAT2 is
available for the path {P1,O3,O4,O5,O6,P2}. Subsequently, it can
communicate {LAT1, LAT2} in response.
4. Optical OAM data collected in the packet is decapsulated and
exported using the same mechanism as that used in the packet IOAM
domain.
5. Finally, if an IOAM optical data type field cannot be interpreted
by a specific MLBD, it acts like a bypass for that data flow.
5. Packet-Optical IOAM Data Types and Formats
5.1 IOAM Packet-Optical Flow Tracing
Tracing of packet-optical flows can follow either the pre-allocated or
incremental trace options as defined in Section 4.1 of [I-D.ietf-ippm-
ioam-data]. The data type and format follow that specification with the
following modifications at an MLBD:
o Identification of the interface that a packet was received on,
Anand et al., Expires August 30, 2018 [Page 6]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
i.e. ingress interface or optical path/circuit/wavelength ID(s)
o Identification of the interface that a packet was sent out on,
i.e. egress interface or optical path/circuit/wavelength ID(s)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ingr. Opt. Type| Ingr. Opt. Len| Ingr. Opt. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingr. Opt. ID (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Egr. Opt. Type| Egr. Opt. Len | Egr. Opt. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egr. Opt. ID (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ingr. Opt. Type : 8-bit identifier that identifies the specific
type of ingress optical path/circuit/wavelength
identifier(s).
Ingr. Opt. Len : Length of data field in bytes (4-byte aligned).
Ingr. Opt. ID : Unsigned integer. Interface identifier of the
ingress optical path/circuit/wavelength identifier(s).
Egr. Opt. Type : 8-bit identifier that identifies the specific
type of egress optical path/circuit/wavelength
identifier(s).
Egr. Opt. Len : Length of data field in bytes (4-byte aligned).
Egr. Opt. ID : Unsigned integer. Interface identifier of the
egress optical path/circuit/wavelength identifier(s).
Considering the topology in Figure 1, in response to a query for path
tracing along the optical path/circuit {P1,O1,O2,P2}, the MLBD P1 could
insert 0x01 as the egress optical type, and egress optical length of 4
and path identifier of 0x0A010101 corresponding to path {P1,O1,O2,P2}.
5.2 IOAM Optical Path Characteristics
An MLBD can also be queried for any optical path related operational
data associated with a flow using a separate header. Optical data
queried may include Bit error rates (BER), Q-factor, pre-FEC counts, FEC
Anand et al., Expires August 30, 2018 [Page 7]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
corrected words, and fiber latency as measured from the ingress optical
interface of a source MLBD to the egress optical interface on a
destination MLBD. This document defines the following list of IOAM OPT
types.
+-----------------+-------------------------------+-----------+
| IOAM OPT Type | IOAM OPT Name | Reference |
+-----------------+-------------------------------+-----------+
| 0 | FEC corrected bits | This Draft|
| 1 | FEC corrected bytes | This Draft|
| 2 | FEC uncorrectable words | This Draft|
| 3 | Unavailable seconds | This Draft|
| 4 | Pre-FEC errors | This Draft|
| 5 | Post-FEC errors | This Draft|
| 6 | Q-value | This Draft|
| 7 | ESNR | This Draft|
| 8 | Path Latency | This Draft|
| 9 | Optical SRLG | This Draft|
| 10 | Wavelength | This Draft|
| 11 | List of L0 Optical Node IDs | This Draft|
| 12 | List of L1 Optical Node IDs | This Draft|
| 13-127 | Reserved | TBD |
| 128-255 | Private | This Draft|
+-----------------+-------------------------------+-----------+
Where:
FEC corrected bits : The number of bits that were corrected by
the FEC deployed along the optical path/circuit.
FEC corrected bytes : The number of bytes that were corrected by
the FEC deployed along the optical path/circuit.
FEC uncorrectable words : The number of words that were
uncorrectable by the FEC deployed along the
optical path/circuit.
Unavailable seconds : The number of seconds that the path was
unavailable due to a loss of sync, error,
or loss of signal.
Pre-FEC errors : The BER before FEC has been applied along the
optical path/circuit
Post-FEC errors : The BER after FEC has been applied along the
optical path/circuit
Q-value : The Quality value (in dB) the optical channel
Anand et al., Expires August 30, 2018 [Page 8]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
measured along the path/circuit.
ESNR : The electric signal-to-noise ratio of the channel
measured along the path/circuit.
Path Latency : The overall latency to forward data along an
optical path/circuit.
Optical SRLG : The SRLG identifier associated with the
optical path/circuit.
Wavelength : The wavelength(s) information associated with
the optical path/circuit.
List of L0 Optical Node IDs: List of all L0 device identifiers along
the optical path/circuit.
List of L1 Optical Node IDs: List of all L1 device identifiers along
the optical path/circuit.
Note that types 128-255 are designated as private for carrying any
vendor-specific optical attributes.
The structure for carrying the OPT TLV is given below:
IOAM optical data option header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<
| IOAM OPT Type |IOAM OPT Subtype | IOAM OPT Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Data | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O
| Opt Data(contd) | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Opt Data(contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
IOAM OPT Type: 8-bit identifier that identifies the specific
optical data type that has been requested.
IOAM OPT Subtype: 8-bit identifier that identifies the specific
Anand et al., Expires August 30, 2018 [Page 9]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
subtype of the queried optical data type. A subtype
is intended to qualify the data collected with a
description of statistic used (min/max/instant/
average/aggregate/list) in the data collection
process.
IOAM OPT Len: Length of data field (4-byte aligned).
IOAM OPT Data: Free flowing data field carrying the data value
corresponding to the type of data requested.
The Opt data field can be used to convey optical path characteristics
(e.g., wavelength, optical SRLG, and geography information).
6. Summary
The motivation for introducing a multi-layer IOAM is to integrate
transport and packet domain OAM data. This allows for operational
simplicity when it comes to gathering and correlating OAM data across an
end-to-end path. This document describes the mechanism to achieve this
IOAM integration and also some sample sample multi-layer IOAM data types
and formats.
7. Security Considerations
This document does not introduce any new security considerations.
8 IANA Considerations
A future revision of this document will lay down the exact IANA
request to create a new registry for "In-Situ OAM (IOAM) Optical
Interface Type" and "In-Situ OAM (IOAM) Optical Data type". This is the
common registry that will include registrations for all optical IOAM
types.
9 References
9.1 Normative References
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
Anand et al., Expires August 30, 2018 [Page 10]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
P., Chang, R., and D. Bernier, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in
progress), September 2017.
9.2 Informative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Madhukar Anand
Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089
Email: manand@infinera.com
Sanjoy Bardhan
Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089
Email: sbardhan@infinera.com
Radhakrishna Valiveti
Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089
Email: rvaliveti@infinera.com
Ramesh Subrahmaniam
Email: svr_fremont@yahoo.com
Anand et al., Expires August 30, 2018 [Page 11]
Internet-Draft draft-anand-ippm-po-ioam-00 February 26, 2018
Carlos Pignataro
Cisco Systems, Inc
Email: cpignata@cisco.com
Shwetha Bhandari
Cisco Systems, Inc
Email: shwethab@cisco.com
Randy Zhang
Cisco Systems, Inc
Email: ranzhang@cisco.com
Rajiv Asati
Cisco Systems, Inc
Email: rajiva@cisco.com
Anand et al., Expires August 30, 2018 [Page 12]