idnits 2.17.00 (12 Aug 2021) /tmp/idnits3115/draft-song-ippm-ioam-data-extension-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2018) is 1489 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm H. Song, Ed. 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: October 18, 2018 April 16, 2018 7 In-situ OAM Data Type Extension 8 draft-song-ippm-ioam-data-extension-01 10 Abstract 12 This document describes a proposal which extends in-situ OAM to 13 support potential future standard tracing data in addition to those 14 currently defined. We provide use cases to motivate our proposal and 15 base the modifications on the latest in-situ OAM header format 16 specification. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 18, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Motivation for Data Type Extension . . . . . . . . . . . . . 2 53 2. Scalable Data Type Extension . . . . . . . . . . . . . . . . 3 54 2.1. Data Type Bitmap . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3. Consideration for Efficient Data Packing . . . . . . . . 5 57 2.4. Alternative Data Extension Possibilities . . . . . . . . 5 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Motivation for Data Type Extension 67 In-situ OAM (iOAM) [I-D.brockners-inband-oam-requirements] records 68 OAM information within user packets while the packets traverse a 69 network. The data types and data formats for in-situ OAM data 70 records have been defined in [I-D.ietf-ippm-ioam-data]. 72 Currently 12 data types and associated formats (including wide format 73 and short format of the same data) are defined in 74 [I-D.ietf-ippm-ioam-data] . The presence of data is indicated by a 75 16-bit bitmap in the "OAM-Trace-Type" field. 77 In the current specification only four bits are left to identify new 78 standard data types. Moreover, some data is forced to be bundled 79 together as a single unit to save bitmap space and pack data to the 80 ideal size (e.g., the hop limit and the node id are bundled, and the 81 ingress interface id and the egress interface id are bundled), 82 regardless of the fact that an application may only ask for a part of 83 the data. Last but not the least, each data is forced to be 4-byte 84 aligned for easier access, resulting in waste of header space in many 85 cases. 87 Since the data plane bandwidth, the data plane packet processing, and 88 the management plane data handling are all precious yet scarce 89 resource, the scheme should strive to be simple and precise. The 90 application should be able to control the exact type and format of 91 data it needs to collect and analyze. It is conceivable that more 92 types of data may be introduced in the future. However, the current 93 scheme cannot support it after all the bits in the bitmap are used 94 up. 96 For example, when a flow traverses a series of middleboxes (e.g., 97 Firewall, NAT, and load balancer), its identity (e.g., the 5-tuple) 98 is often altered, which makes the OAM system lose track of the flow 99 trace. In this case, we may want to copy some of the original packet 100 header fields into the iOAM header so the original flow can be 101 identified at any point of the network. 103 For another example, in wireless, mobile, and optical network 104 environments, some physical data associated with a flow (e.g., power, 105 temperature, signal strength, GPS location) need to be collected to 106 monitor the service performance. 108 For another example, some data may have different semantics and 109 formats in different networks and application scenarios. An example 110 is the timestamp data type in which NTP, PTP, or any other local 111 defined approaches can be used. 113 All the above cases require new iOAM data types. More examples are 114 listed in Section 2.2. 116 There are some other issues about the current specification. For 117 example, bit 7 is used to indicate the presence of variable length 118 opaque state snapshot data; Bit 5 and bit 10 are used to indicate the 119 presence of the application specific data. While these data fields 120 can be used to store arbitrary data, the data is difficult to be 121 standardized and another schema is needed to decode the data, which 122 may lead to low data plane performance as well as interoperability 123 issues. More important, the existence of the variable length data 124 complicates the data processing such as data packing and 125 encapsulation. It is preferred to know the data type and size in 126 advance for efficient hardware implementation. 128 2. Scalable Data Type Extension 130 Based on the observation in Section 1, we propose a method for data 131 type encoding which can solve the current limitation and address 132 future data requirements. 134 2.1. Data Type Bitmap 136 Bitmap is simple and efficient data structure for high performance 137 data plane implementation. The base bitmap size is kept to be 16 138 bits. We use one bit to indicate a single type of data in a single 139 format. The last bit in the bitmap (i.e., bit 15), if set, is used 140 to indicate the presence of the next data type bitmap, which is 32 141 bits long. In the second bitmap, bit 31 is again reserved to 142 indicate a third bitmap, and so on. With each extra bitmap, 31 more 143 data types can be defined. 145 Figure 1 shows an example of the in-situ OAM header format with two 146 extended OAM trace type fields. Except the OAM Trace Type fields, 147 all other fields remain the same as defined in 148 [I-D.ietf-ippm-ioam-data]. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Base OAM Trace Type |1|NodeLen| Flags | Octets-left | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Extended OAM Trace Type 1 |1| 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Extended OAM Trace Type 2 |0| 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | 160 | Node Data List [] | 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: Extended OAM Trace Type Header Format 166 The specification of the Base OAM Trace Type is the same as the OAM 167 Trace Type in [I-D.ietf-ippm-ioam-data] except the last bit, which is 168 defined as follows: 170 o Bit 15: When set indicates presence of next bit map. 172 The OAM trace type fields are labeled as Base OAM Trace Type, 173 Extended OAM Trace Type 1, Extended OAM Trace Type 2, and so on. The 174 Base OAM Trace Type is always present. If no data type is asked by 175 the application in Extended OAM Trace Type n and beyond, then the 176 last bit in the previous bitmap is set to 1 and these extended fields 177 are not included in the header. On the other hand, to eliminate 178 ambiguity, if any data is asked for by the application in Extended 179 OAM Trace Type n, then Extended OAM Trace Type 1 to (n-1) must be 180 included in the header, even though no data type in these bitmaps are 181 needed (i.e., all zero bitmap except the last bit). 183 The actual data in a node is packed together in the same order as 184 listed in the OAM Trace Type bitmap. Each node is padded to be the 185 multiple of 4 bytes. 187 2.2. Use Cases 189 New types of data can be potentially added and standardized, which 190 demand new bits allocated in the OAM Trace Type bitmaps. Some 191 examples are listed here. 193 o Metered flow bandwidth. 195 o Time gap between two consecutive flow packets. 197 o Remaining time budget to the packet delivery deadline. 199 o Buffer occupancy on the Node. 201 o Queue depth on each level of hierarchical QoS queues. 203 o Packet jitter at the Node. 205 o Current packet IP addresses. 207 o Current packet port numbers. 209 o Time using different network timing protocol. 211 o Other node statistics. 213 2.3. Consideration for Efficient Data Packing 215 The length of each data must be the multiple of 2 bytes. However, 216 allowing different data type to have different length, while 217 efficient in storage, makes data alignment and packing difficult. 219 If we can define the maximum number of data types that can be carried 220 per packet, the offset of each data in the node can be pre-calculated 221 and carried in the iOAM header. The overhead can be justified by the 222 overall space saving of the node data list. Otherwise, each data's 223 offset in the node must be calculated in each device, with the help 224 of a table which stores the size of each data type. We can also 225 arrange the bitmap to reflect the data availability order in the 226 system (e.g., the bit for egress_if_id must be after the bit for 227 ingress_if_id), so in a pipeline-based system, the required data can 228 be packed one after one. 230 2.4. Alternative Data Extension Possibilities 232 Bitmap is simple and support parallel processing in hardware. 233 However, it is not the only option to support data type extension. 234 For example, cascaded TLV can be used to support arbitrary number of 235 new data types. This can be implemented by using a flag bit to 236 indicate the presence of extra data types and packing the number of 237 types and the list of the type IDs after the trace option header. 238 The corresponding data is therefore added in each node data list in 239 the order as its type ID is listed in the extended trace option 240 header. 242 3. Security Considerations 244 There is no extra security considerations beyond those have been 245 identified by the original in-situ OAM proposals. 247 4. IANA Considerations 249 This memo includes no request to IANA. 251 5. Acknowledgments 253 We would like to thank Frank Brockners, Carlos Pignataro, and Shwetha 254 Bhandari for helpful comments and suggestions. 256 6. Contributors 258 The document is inspired by numerous discussions with James N. 259 Guichard. He also provided significant comments and suggestions to 260 help improve this document. 262 7. Informative References 264 [I-D.brockners-inband-oam-requirements] 265 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 266 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 267 T., <>, P., and r. remy@barefootnetworks.com, 268 "Requirements for In-situ OAM", draft-brockners-inband- 269 oam-requirements-03 (work in progress), March 2017. 271 [I-D.ietf-ippm-ioam-data] 272 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 273 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 274 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 275 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 276 progress), September 2017. 278 Authors' Addresses 279 Haoyu Song (editor) 280 Huawei 281 2330 Central Expressway 282 Santa Clara, 95050 283 USA 285 Email: haoyu.song@huawei.com 287 Tianran Zhou 288 Huawei 289 156 Beiqing Road 290 Beijing, 100095 291 P.R. China 293 Email: zhoutianran@huawei.com