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