idnits 2.17.1 draft-song-ippm-segment-ioam-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2017) is 2376 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 (-03) exists of draft-brockners-inband-oam-requirements-02 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-00 Summary: 0 errors (**), 0 flaws (~~), 3 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: April 20, 2018 October 17, 2017 7 Control In-situ OAM Overhead with Segment IOAM 8 draft-song-ippm-segment-ioam-00 10 Abstract 12 This document describes a proposal to segment an in-situ OAM domain 13 in order to control the iOAM data overhead, adapt to the path MTU 14 limitations, and enable new applications. We provide use cases to 15 motivate our proposal and base the necessary modifications on the 16 current in-situ OAM header format 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 April 20, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Segment In-situ OAM . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Segment and Hops . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Considerations for Data Handling . . . . . . . . . . . . 4 56 2.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Informative References . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 In-situ OAM (iOAM) [I-D.brockners-inband-oam-requirements] records 67 OAM information within user packets while the packets traverse a 68 network. The data types and data formats for in-situ OAM data 69 records have been defined in [I-D.ietf-ippm-ioam-data]. 71 iOAM may incur significant overhead on user packets. The overhead 72 includes the iOAM header and the node data list for each network 73 element. 75 The total size of data is limited by the MTU. When the number of 76 required data types is large and the forwarding path length is long, 77 it is possible that there is not enough space in the iOAM header to 78 save the data. The current proposal is to label the overflow status 79 and stop adding new node data to the packet, leading to loss of 80 information. 82 Even if the header has enough space to hold the iOAM data, the 83 overhead may be too large and consume too much bandwidth. For 84 example, if we assume moderate 20 bytes of data per node, a path with 85 length of 10 will need 200 bytes to hold the data. This will inflate 86 small 64-byte packets by more than four times. Even for the largest 87 packet size (e.g., 1500 bytes), the overhead (>10%) is not 88 negligible. Therefore, we need to limit the iOAM data overhead 89 without sacrificing the data collection capability. 91 Here we have another interesting related issue. Packets can be 92 dropped anywhere in a network for various reasons. If we can only 93 collect iOAM data at the path end, we lose all data from the dropped 94 packets and have no idea where the packets are dropped. This defies 95 the purpose of iOAM and makes those iOAM-enabled nodes work in vain. 97 2. Segment In-situ OAM 99 Based on the observation in Section 1, we propose a method to limit 100 the size of the node data list. 102 2.1. Segment and Hops 104 A hop is a node on a flow's forwarding path which is capable of 105 processing iOAM data. A segment is a fixed number hops on a flow's 106 forwarding path. While working in the "per hop" trace mode, the 107 segment size (SSize) and the remaining hops (RHop), is added to the 108 iOAM header at the edge. Initially, RHop is equal to SSize. At each 109 hop, if RH is not zero, the node data is added to the node data list 110 at the corresponding location and then RH is decremented by 1. If RH 111 is equal to 0 when receiving the packet, the node needs to remove (in 112 incremental trace option) or clear (in pre-allocated trace option) 113 the iOAM node data list and reset RHop to SSize. Then the node will 114 add its data to the node data list as if it is the edge node. 116 The stripped iOAM data at the segement edge can be immediately 117 exported to a collector. 119 Figure 1 shows the proposed in-situ OAM header format. The bit 23 in 120 the Flags field is used to indicate the current header is a segment 121 iOAM header. In this context, the last octet in the iOAM header is 122 partitioned into two 4-bit nibbles. The first nibble (SSize) is used 123 to save the segment size and the second nibble (RHop) is used to save 124 the remaining hops. This limits the maximum segment size to 15. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Base OAM Trace Type |NodeLen|Flags|1| SSize | RHop | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | 132 | Node Data List [] | 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: Segment iOAM Header Format 138 In the special case when SSize is set to 0, no data will be recorded 139 in the node data list. The requested data listed in the OAM Trace 140 Type will be immediately exported to the collector. This way the 141 iOAM overhead is minimized. 143 2.2. Considerations for Data Handling 145 At any hop when RHop is equal to 0, the node data list is copied from 146 the iOAM header. The data can be encapsulated and reported to the 147 controller or the edge node as configured. The encapsulation and 148 report method is beyond the scope of this draft but should be comply 149 with the method used by the iOAM edge node. 151 The actual size of the last segment may not be equal to SSize but 152 this is not a problem. 154 2.3. Use Cases 156 Segment iOAM is necessary in the following example scenarios: 158 o Segment iOAM can be used to detect at which segment the flow 159 packet is dropped. If the SSize is set to 1, then the exact drop 160 node can be identified. The iOAM data before the dropping point 161 is also retained. 163 o The path MTU allows to add at most k node data in the list to 164 avoid fragmentation. Therefore SSize is set to k and at each hop 165 where RHop is 0, the node data list is retrieved and sent in a 166 standalone packet. 168 o A flow contains mainly short packets and travels a long path. It 169 would be inefficient to keep a large node data list in the packet 170 so the network bandwidth utilization rate is low. In this case, 171 segment iOAM can be used to limit the ratio of the iOAM data to 172 the flow packet payload. 174 o The network allows at most n bytes budget for the iOAM data. 175 There is a tradeoff between the number of data types that can be 176 collected and the number of hops for data collecting. The segment 177 size is therefore necessary to meet the application's data 178 requirement (i.e., SSize * Node Data Size < n). 180 3. Security Considerations 182 There is no extra security considerations beyond those have been 183 identified by in-situ OAM protocol. 185 4. IANA Considerations 187 This memo includes no request to IANA. 189 5. Acknowledgments 191 We would like to thank Frank Brockners, Carlos Pignataro, and Shwetha 192 Bhandari for helpful comments and suggestions. 194 6. Contributors 196 The document is inspired by numerous discussions with James N. 197 Guichard. He also provided significant comments and suggestions to 198 help improve this document. 200 7. Informative References 202 [I-D.brockners-inband-oam-requirements] 203 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 204 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 205 T., <>, P., and r. remy@barefootnetworks.com, 206 "Requirements for In-situ OAM", draft-brockners-inband- 207 oam-requirements-02 (work in progress), October 2016. 209 [I-D.ietf-ippm-ioam-data] 210 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 211 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 212 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 213 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 214 progress), September 2017. 216 Authors' Addresses 218 Haoyu Song (editor) 219 Huawei 220 2330 Central Expressway 221 Santa Clara, 95050 222 USA 224 Email: haoyu.song@huawei.com 226 Tianran Zhou 227 Huawei 228 156 Beiqing Road 229 Beijing, 100095 230 P.R. China 232 Email: zhoutianran@huawei.com