Internet DRAFT - draft-anand-ippm-po-ioam

draft-anand-ippm-po-ioam



 



IPPM Working Group                                        Madhukar Anand
Internet-Draft                                         Ciena Corporation
Intended Status: Informational                                          
                                                          Sanjoy Bardhan
                                                   Radhakrishna Valiveti
                                                    Infinera Corporation

                                                     Ramesh Subrahmaniam
                                                              Individual

                                                        Carlos Pignataro
                                                        Shwetha Bhandari
                                                             Randy Zhang
                                                             Rajiv Asati
                                                      Cisco Systems, Inc

Expires: August 29, 2019                               February 25, 2019


                 Integrated Packet-Optical In-Situ OAM
                      draft-anand-ippm-po-ioam-02


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
 


Anand et al.,           Expires August 29, 2019                 [Page 1]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


   Internet-Drafts.

   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) 2019 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 29, 2019                 [Page 2]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                 [Page 3]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                 [Page 4]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                 [Page 5]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                 [Page 6]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


 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 29, 2019                 [Page 7]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                 [Page 8]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


			   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 29, 2019                 [Page 9]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


		   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,
           P., Chang, R., D. Bernier, and Lemon, J. "Data Fields
 


Anand et al.,           Expires August 29, 2019                [Page 10]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


           for In-situ OAM", draft-ietf-ippm-ioam-data-04 (work in
           progress), Apr 2019.


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
Ciena Corporation
3939, N 1st Street, San Jose, CA, 95134
Email: madanand@ciena.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



Carlos Pignataro
Cisco Systems, Inc
 


Anand et al.,           Expires August 29, 2019                [Page 11]

Internet-Draft        draft-anand-ippm-po-ioam-02      February 25, 2019


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 29, 2019                [Page 12]