idnits 2.17.1 draft-anand-ippm-po-ioam-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 46 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2019) is 1884 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group Madhukar Anand 3 Internet-Draft Ciena Corporation 4 Intended Status: Informational 5 Sanjoy Bardhan 6 Radhakrishna Valiveti 7 Infinera Corporation 9 Ramesh Subrahmaniam 10 Individual 12 Carlos Pignataro 13 Shwetha Bhandari 14 Randy Zhang 15 Rajiv Asati 16 Cisco Systems, Inc 18 Expires: August 29, 2019 February 25, 2019 20 Integrated Packet-Optical In-Situ OAM 21 draft-anand-ippm-po-ioam-02 23 Abstract 25 This document proposes a way to extend in-situ OAM techniques to 26 include operational data from multiple network layers with a view to 27 create an integrated record of OAM information as the data flows 28 between two network entities. An instance of this technique that is 29 elaborated here focuses on packet-optical networks that are 30 traditionally transport centric. The mechanisms described are general 31 enough to allow future extensibility of in-situ OAM techniques into 32 other non-packet domains. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as 48 Internet-Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/1id-abstracts.html 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 Copyright and License Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Reference Terminology . . . . . . . . . . . . . . . . . . . . 3 80 3. Packet Optical OAM Integration . . . . . . . . . . . . . . . . 4 81 4. Mechanism Assumptions and Overview . . . . . . . . . . . . . . 5 82 5. Packet-Optical IOAM Data Types and Formats . . . . . . . . . . 6 83 5.1 IOAM Packet-Optical Flow Tracing . . . . . . . . . . . . . 6 84 5.2 IOAM Optical Path Characteristics . . . . . . . . . . . . . 7 85 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 88 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 90 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1 Introduction 95 Packet and optical transport networks have evolved independently with 96 different OAM mechanisms that have to be managed separately. 97 Consequently, coordinating packet and optical networks for delivering 98 services such as end-to-end traffic engineering has proved 99 challenging. To address this challenge, a unified paradigm that 100 provides an integrated record of OAM information as the data flows 101 between two network entities that are connected by a multi-layer 102 network is needed. Further, such a paradigm should provide an 103 incremental path to complete packet-optical OAM integration while 104 leveraging existing OAM mechanisms as much as possible in either 105 domains. This document introduces such a paradigm by extending the 106 mechanisms defined in [I-D.ietf-ippm-ioam-data]. 108 The key construct to deliver an integrated IOAM across packet and 109 optical network layers is that of a Multi-layer Border Device 110 (MLBD). These are nodes in the network that map packet paths to the 111 optical paths that originate and terminate at the MLBDs. The concept 112 of MLBD allows for multiple realizations - depending on whether the 113 packet and optical functions are integrated or not. In one case, the 114 packet device is distinct from the optical transport device, and the 115 MLBD is a logical entity that spans these two devices. In this case, 116 the MLBD functionality is achieved with the help of external 117 coordination between the packet and optical devices. In another case, 118 the packet and optical components are integrated into one physical 119 device, and the co-ordination required for functioning of the MLBD is 120 performed by this integrated device. It must be noted that in either 121 case, it is the packet/optical data plane that is either 122 disaggregated or integrated. Control of the devices can be logically 123 centralized or distributed in either scenario. The focus of this 124 document is to define the logical functions of an MLBD without going 125 into the exact instantiations of the concept. 127 2. Reference Terminology 129 IOAM: In-situ Operations, Administration, and Maintenance 131 MLBD: Multi-layer Border Device 133 POT: Proof of Transit 135 FEC: Forward Error Correction 137 BER: Bit Error Rate 139 SRLG: Shared Risk Link Group 141 3. Packet Optical OAM Integration 143 Many operators build and operate their networks that are both multi- 144 layer and multi-domain and provide end-to-end services to their 145 customers. Due to the nature of the different domains, the 146 operations and management of the network has always been problematic 147 and time consuming. 149 `._ ,' 150 `. ,' 151 `-. ,' 152 P1`.----------------------------- P2 153 |\ /| 154 | \ / | Packet 155 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 156 | \ / | 157 | \ / | Transport 158 | \ / | 159 | ................./ | 160 | O1 O2 | 161 | | 162 | | 163 O3\ | O6 164 \ ,' 165 \ ,' 166 .......................- 167 O4 O5 169 Figure 1: Representation of a packet-optical network 171 Figure 1 represents a packet optical network in which P1 and P2 are 172 packet devices that are connected via two optical links comprising of 173 devices O1 and O2 and with devices O3,...,O6. Devices P1 and P2 are 174 MLBDs that communicate with other packet devices and also with the 175 devices in the optical transport domain. Each MLBD would maintain 176 operational data such as path latency, Bit Error Rate (BER), pre-FEC 177 counts, FEC corrected words, and Q-factor corresponding to active 178 optical paths such as {P1, O1, O2, P2}. An MLBD, by the virtue of being 179 a packet device, also participates in the in-situ OAM techniques as 180 described in [I-D.ietf-ippm-ioam-data]. To facilitate the OAM 181 integration of packet and optical network layers, an MLBD parses the 182 IOAM data fields in a packet earmarked for optical OAM data and inserts 183 the appropriate OAM information from the optical path corresponding to 184 that packet flow. The operations data corresponding to the optical 185 paths may be obtained by leveraging supported optical OAM techniques. 187 It must be noted that the IOAM changes proposed in this document are 188 limited to necessary optical characteristics that are of interest to the 189 packet domain applications and have the potential to be used for 190 routing/switching and traffic engineering. It is not intended to be a 191 mechanism to obtain all supported optical OAM information from optical 192 devices. 194 4. Mechanism Assumptions and Overview 196 The current proposal assumes that the packet and optical network 197 layers use respective OAM techniques without any modification. There are 198 also no modifications necessary to data forwarding across the layers. 199 The only requirement is that an MLBD supports an embodiment of IOAM 200 mechanisms. It is also assumed that the MLBD performs all functions of a 201 regular packet IOAM device and there are specific data types allocated 202 for querying optical OAM data (IOAM optical data type). The mechanism 203 for supporting the multi-layer IOAM is as follows. 205 1. An MLBD participates in an in-situ OAM-domain and thus behaves 206 either as an IOAM transit device, an IOAM encapsulating or an IOAM 207 decapsulating device as described in [I-D.ietf-ippm-ioam-data]. 209 2. An MLBD participates in all relevant optical OAM mechanisms and 210 obtains operational data. 212 3. MLBDs interpret the IOAM optical data type in a data flow, map it 213 to specific optical operational data, and attach the desired response to 214 the data packet in an appropriate manner. Specific data formats for 215 carrying the optical operational data are discussed in the subsequent 216 sections. There are typically multiple MLBDs at the edges of a optical 217 network that can process the IOAM optical data type, and depending on 218 the use-case and the type of optical data requested, a specific MLBD or 219 a set of MLBDs can respond to the requested data. 221 (a) Mapping of an optical data type to a specific optical operational 222 data is assumed to be programmed into an MLBD prior to its use. 224 (b) It is possible that multiple packets share the same optical 225 characteristics. In those circumstances, all the associated packet flows 226 will share the optical OAM data. For example, if traffic from two VLANs 227 is multiplexed into the same ODU, the ODU-level operational data is 228 applicable to both the VLANs. 230 (c) If a specific optical data type maps to multiple optical 231 operational data, an MLBD can determine how to communicate that suitably 232 in response to the request. Options for data consolidation may include 233 appending all responses, averaging the responses, or picking minimum or 234 maximum value, or keeping them separate. 236 Considering the topology in Figure 1, if there is a query for the 237 aggregate number of post-FEC errors in the optical path(s) between P1 238 and P2, P1 may choose to send the requested data as an appended list 239 {FEC1, FEC2} in response, where FEC1 are the aggregate number of post- 240 FEC errors along the optical path/circuit {P1,O1,O2,P2} and FEC2 are the 241 aggregate number of post-FEC errors along the path/circuit 242 {P1,O3,O4,O5,O6,P2}. 244 (d) If the requested data is not available immediately, the optical 245 device can request a collection of the requested data upon parsing the 246 request, and once it is available, the data could be included in a later 247 packet carrying the same data request. One option to communicate that 248 the requested data is delayed is by responding to the request with a 249 standardized special value such as 0xFFFFFFFF that indicates this 250 scenario. It is to be be noted that this special value is something that 251 is assumed to be standardized for the specific data queried and known in 252 advance by all participating IOAM devices. 254 Considering the example in Figure 1, if there is a query for the optical 255 path latency in the optical path(s) between P1 and P2, and if P1 only 256 has the data LAT1 available for the optical path/circuit {P1,O1,O2,P2} 257 and not for the path/circuit {P1,O3,O4,O5,O6,P2}, it can communicate 258 {LAT1, 0xFFFFFFFF} in response till the path latency data LAT2 is 259 available for the path {P1,O3,O4,O5,O6,P2}. Subsequently, it can 260 communicate {LAT1, LAT2} in response. 262 4. Optical OAM data collected in the packet is decapsulated and 263 exported using the same mechanism as that used in the packet IOAM 264 domain. 266 5. Finally, if an IOAM optical data type field cannot be interpreted 267 by a specific MLBD, it acts like a bypass for that data flow. 269 5. Packet-Optical IOAM Data Types and Formats 271 5.1 IOAM Packet-Optical Flow Tracing 273 Tracing of packet-optical flows can follow either the pre-allocated or 274 incremental trace options as defined in Section 4.1 of [I-D.ietf-ippm- 275 ioam-data]. The data type and format follow that specification with the 276 following modifications at an MLBD: 278 o Identification of the interface that a packet was received on, 280 i.e. ingress interface or optical path/circuit/wavelength ID(s) 282 o Identification of the interface that a packet was sent out on, 283 i.e. egress interface or optical path/circuit/wavelength ID(s) 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |Ingr. Opt. Type| Ingr. Opt. Len| Ingr. Opt. ID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Ingr. Opt. ID (contd) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |Egr. Opt. Type| Egr. Opt. Len | Egr. Opt. ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Egr. Opt. ID (contd) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Ingr. Opt. Type : 8-bit identifier that identifies the specific 298 type of ingress optical path/circuit/wavelength 299 identifier(s). 301 Ingr. Opt. Len : Length of data field in bytes (4-byte aligned). 303 Ingr. Opt. ID : Unsigned integer. Interface identifier of the 304 ingress optical path/circuit/wavelength identifier(s). 306 Egr. Opt. Type : 8-bit identifier that identifies the specific 307 type of egress optical path/circuit/wavelength 308 identifier(s). 310 Egr. Opt. Len : Length of data field in bytes (4-byte aligned). 312 Egr. Opt. ID : Unsigned integer. Interface identifier of the 313 egress optical path/circuit/wavelength identifier(s). 315 Considering the topology in Figure 1, in response to a query for path 316 tracing along the optical path/circuit {P1,O1,O2,P2}, the MLBD P1 could 317 insert 0x01 as the egress optical type, and egress optical length of 4 318 and path identifier of 0x0A010101 corresponding to path {P1,O1,O2,P2}. 320 5.2 IOAM Optical Path Characteristics 322 An MLBD can also be queried for any optical path related operational 323 data associated with a flow using a separate header. Optical data 324 queried may include Bit error rates (BER), Q-factor, pre-FEC counts, FEC 325 corrected words, and fiber latency as measured from the ingress optical 326 interface of a source MLBD to the egress optical interface on a 327 destination MLBD. This document defines the following list of IOAM OPT 328 types. 330 +-----------------+-------------------------------+-----------+ 331 | IOAM OPT Type | IOAM OPT Name | Reference | 332 +-----------------+-------------------------------+-----------+ 333 | 0 | FEC corrected bits | This Draft| 334 | 1 | FEC corrected bytes | This Draft| 335 | 2 | FEC uncorrectable words | This Draft| 336 | 3 | Unavailable seconds | This Draft| 337 | 4 | Pre-FEC errors | This Draft| 338 | 5 | Post-FEC errors | This Draft| 339 | 6 | Q-value | This Draft| 340 | 7 | ESNR | This Draft| 341 | 8 | Path Latency | This Draft| 342 | 9 | Optical SRLG | This Draft| 343 | 10 | Wavelength | This Draft| 344 | 11 | List of L0 Optical Node IDs | This Draft| 345 | 12 | List of L1 Optical Node IDs | This Draft| 346 | 13-127 | Reserved | TBD | 347 | 128-255 | Private | This Draft| 348 +-----------------+-------------------------------+-----------+ 350 Where: 352 FEC corrected bits : The number of bits that were corrected by 353 the FEC deployed along the optical path/circuit. 355 FEC corrected bytes : The number of bytes that were corrected by 356 the FEC deployed along the optical path/circuit. 358 FEC uncorrectable words : The number of words that were 359 uncorrectable by the FEC deployed along the 360 optical path/circuit. 362 Unavailable seconds : The number of seconds that the path was 363 unavailable due to a loss of sync, error, 364 or loss of signal. 366 Pre-FEC errors : The BER before FEC has been applied along the 367 optical path/circuit 369 Post-FEC errors : The BER after FEC has been applied along the 370 optical path/circuit 372 Q-value : The Quality value (in dB) the optical channel 374 measured along the path/circuit. 376 ESNR : The electric signal-to-noise ratio of the channel 377 measured along the path/circuit. 379 Path Latency : The overall latency to forward data along an 380 optical path/circuit. 382 Optical SRLG : The SRLG identifier associated with the 383 optical path/circuit. 385 Wavelength : The wavelength(s) information associated with 386 the optical path/circuit. 388 List of L0 Optical Node IDs: List of all L0 device identifiers along 389 the optical path/circuit. 391 List of L1 Optical Node IDs: List of all L1 device identifiers along 392 the optical path/circuit. 394 Note that types 128-255 are designated as private for carrying any 395 vendor-specific optical attributes. 397 The structure for carrying the OPT TLV is given below: 399 IOAM optical data option header: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< 403 | IOAM OPT Type |IOAM OPT Subtype | IOAM OPT Len | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Opt Data | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O 407 | Opt Data(contd) | P 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 409 | Opt Data(contd) | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 412 IOAM OPT Type: 8-bit identifier that identifies the specific 413 optical data type that has been requested. 415 IOAM OPT Subtype: 8-bit identifier that identifies the specific 417 subtype of the queried optical data type. A subtype 418 is intended to qualify the data collected with a 419 description of statistic used (min/max/instant/ 420 average/aggregate/list) in the data collection 421 process. 423 IOAM OPT Len: Length of data field (4-byte aligned). 425 IOAM OPT Data: Free flowing data field carrying the data value 426 corresponding to the type of data requested. 428 The Opt data field can be used to convey optical path characteristics 429 (e.g., wavelength, optical SRLG, and geography information). 431 6. Summary 433 The motivation for introducing a multi-layer IOAM is to integrate 434 transport and packet domain OAM data. This allows for operational 435 simplicity when it comes to gathering and correlating OAM data across an 436 end-to-end path. This document describes the mechanism to achieve this 437 IOAM integration and also some sample sample multi-layer IOAM data types 438 and formats. 440 7. Security Considerations 442 This document does not introduce any new security considerations. 444 8 IANA Considerations 446 A future revision of this document will lay down the exact IANA 447 request to create a new registry for "In-Situ OAM (IOAM) Optical 448 Interface Type" and "In-Situ OAM (IOAM) Optical Data type". This is the 449 common registry that will include registrations for all optical IOAM 450 types. 452 9 References 454 9.1 Normative References 456 [I-D.ietf-ippm-ioam-data] 457 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 458 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 459 P., Chang, R., D. Bernier, and Lemon, J. "Data Fields 460 for In-situ OAM", draft-ietf-ippm-ioam-data-04 (work in 461 progress), Apr 2019. 463 9.2 Informative References 465 [RFC2119] 466 Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 Authors' Addresses 473 Madhukar Anand 474 Ciena Corporation 475 3939, N 1st Street, San Jose, CA, 95134 476 Email: madanand@ciena.com 478 Sanjoy Bardhan 479 Infinera Corporation 480 169 W Java Dr, Sunnyvale, CA 94089 482 Email: sbardhan@infinera.com 484 Radhakrishna Valiveti 485 Infinera Corporation 486 169 W Java Dr, Sunnyvale, CA 94089 488 Email: rvaliveti@infinera.com 490 Ramesh Subrahmaniam 491 Email: svr_fremont@yahoo.com 493 Carlos Pignataro 494 Cisco Systems, Inc 495 Email: cpignata@cisco.com 497 Shwetha Bhandari 498 Cisco Systems, Inc 499 Email: shwethab@cisco.com 501 Randy Zhang 502 Cisco Systems, Inc 503 Email: ranzhang@cisco.com 505 Rajiv Asati 506 Cisco Systems, Inc 507 Email: rajiva@cisco.com