idnits 2.17.1 draft-mymb-sfc-nsh-allocation-timestamp-12.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 (20 December 2021) is 852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-10 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Mizrahi 3 Internet-Draft Huawei 4 Intended status: Informational I.Y. Yerushalmi 5 Expires: 23 June 2022 D.M. Melman 6 Marvell 7 R.B. Browne 8 Intel 9 20 December 2021 11 Network Service Header (NSH) Fixed-Length Context Header Allocation: 12 Timestamp 13 draft-mymb-sfc-nsh-allocation-timestamp-12 15 Abstract 17 The Network Service Header (NSH) specification defines two possible 18 methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD 19 Type 0x1 uses a fixed-length Context Header. The allocation of this 20 Context Header, i.e., its structure and semantics, has not been 21 standardized. This memo presents an allocation for the fixed Context 22 Headers of NSH, which incorporates the packet's timestamp, a sequence 23 number, and a source interface identifier. 25 Although the allocation that is presented in this document has not 26 been standardized by the IETF it has been implemented in silicon by 27 several manufacturers and is published here to allow other 28 interoperable implementations and to facilitate debugging if it is 29 seen in the network. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 23 June 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3. NSH Timestamp Context Header Allocation . . . . . . . . . . . 4 69 4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 6 70 4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 7 73 5. Synchronization Considerations . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The Network Service Header (NSH), defined in [RFC8300], is an 85 encapsulation header that is used as the service encapsulation in the 86 Service Function Chains (SFC) architecture [RFC7665]. 88 In order to share metadata along a service path, the NSH 89 specification [RFC8300] supports two methods: a fixed-length Context 90 Header (MD Type 0x1) and a variable-length Context Header (MD Type 91 0x2). When using MD Type 0x1 the NSH includes 16 octets of Context 92 Header fields. 94 The NSH specification [RFC8300] has not defined the semantics of the 95 16-octet Context Header, nor how it is used by NSH-aware service 96 functions, SFFs and proxies. Several context header formats are 97 defined in [I-D.ietf-sfc-nsh-tlv]. Furthermore, some allocation 98 schemes were proposed in the past to acoommodate specific use cases, 99 e.g., [I-D.ietf-sfc-nsh-dc-allocation], 100 [I-D.ietf-sfc-nsh-broadband-allocation], and [RFC8592]. 102 This memo presents an allocation for the MD Type 0x1 Context Header, 103 which incorporates the timestamp of the packet, a sequence number, 104 and a source interface identifier. It is noted that other MD Type 105 0x1 allocations might be specified in the future. Although MD Type 106 0x1 allocations are currently not being standardized by the SFC 107 working group, a consistent format (allocation) should be used in an 108 SFC-enabled domain in order to allow interoperability. 110 In a nutshell, packets that enter the SFC-enabled domain are 111 timestamped by a Classifier [RFC7665]. Thus, the timestamp, sequence 112 number and source interface are incorporated in the NSH Context 113 Header. As defined in [RFC8300], if reclassification is used, it may 114 result in an update to the NSH metadata. Specifically, when the 115 Timestamp Context Header is used, a reclassifier may either leave it 116 unchanged, or update the three fields: timestamp, sequence number and 117 source interface. 119 The Timestamp Context Header includes three fields that may be used 120 for various purposes. The timestamp field may be used for logging, 121 troubleshooting, delay measurement, packet marking for performance 122 monitoring, and timestamp-based policies. The source interface 123 identifier indicates the interface through which the packet was 124 received at the classifier. This identifier may specify a physical 125 or a virtual interface. The sequence numbers can be used by Service 126 Functions (SFs) to detect out-of-order delivery or duplicate 127 transmissions. Note that out-of-order and duplicate packet detection 128 is possible when packets are received by the same SF, but is not 129 necessarily possible when there are multiple instances of the same SF 130 and multiple packets are spread across different instances of the SF. 131 The sequence number is maintained on a per-source-interface basis. 133 This document presents the Timestamp Context Header, but does not 134 specify the functionality of the SFs that receive the Context Header. 135 Although a few possible use cases are described in the document, the 136 SF behavior and application are outside the scope of this document. 138 KPI-stamping [RFC8592] defines an NSH timestamping mechanism that 139 uses the MD Type 0x2 format. The current memo defines a compact MD 140 Type 0x1 Context Header that does not require the packet to be 141 extended beyond the NSH header. Furthermore, the mechanisms of 142 [RFC8592] and of this memo can be used in concert, as further 143 discussed in Section 4.1. 145 Although the allocation that is presented in this document has not 146 been standardized by the IETF it has been implemented in silicon by 147 several manufacturers and is published here to allow other 148 interoperable implementations and to facilitate debugging if it is 149 seen in the network. 151 2. Terminology 153 2.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2.2. Abbreviations 163 The following abbreviations are used in this document: 165 KPI Key Performance Indicators [RFC8592] 167 NSH Network Service Header [RFC8300] 169 MD Metadata [RFC8300] 171 SF Service Function [RFC7665] 173 SFC Service Function Chaining [RFC7665] 175 3. NSH Timestamp Context Header Allocation 177 This memo defines the following fixed-length Context Header 178 allocation, as presented in Figure 1. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Source Interface | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Timestamp | 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: NSH Timestamp Allocation. 193 The NSH Timestamp Allocation that is defined in this memo MUST 194 include the following fields: 196 * Sequence Number - a 32-bit sequence number. The sequence number 197 is maintained on a per-source-interface basis. Sequence numbers 198 can be used by SFs to detect out-of-order delivery, or duplicate 199 transmissions. The Classifier increments the sequence number by 1 200 for each packet received through the source interface. This 201 requires the classifier to maintain a per-source-interface 202 counter. The sequence number is initialized to a random number on 203 startup. After it reaches its maximal value (2^32-1) the sequence 204 number wraps around back to zero. 206 * Source Interface - a 32-bit source interface identifier that is 207 assigned by the Classifier. The combination of the source 208 interface and the classifier identity is unique within the context 209 of an SFC-enabled domain. Thus, in order for an SF to be able to 210 use the source interface as a unique identifier, the identity of 211 the classifier needs to be known for each packet. The source 212 interface is unique in the context of the given classifier. 214 * Timestamp - this field is 64 bits long, and specifies the time at 215 which the packet was received by the Classifier. Two possible 216 timestamp formats can be used for this field: the two 64-bit 217 recommended formats specified in [RFC8877]. One of the formats is 218 based on the [IEEE1588] timestamp format, and the other is based 219 on the [RFC5905] format. 221 The NSH specification [RFC8300] does not specify the possible 222 coexistence of multiple MD Type 0x1 Context Header formats in a 223 single SFC-enabled domain. It is assumed that the Timestamp Context 224 Header will be deployed in an SFC-enabled domain that uniquely uses 225 this Context Header format. Thus, operators SHOULD ensure that 226 either a consistent Context Header format is used in the SFC-enabled 227 domain, or that there is a clear policy that allows SFs to know the 228 Context Header format of each packet. Specifically, operators are 229 expected to ensure the consistent use of a timestamp format across 230 the whole SFC-enabled domain. 232 The two timestamp formats that can be used in the timestamp field 233 are: 235 * IEEE 1588 Truncated Timestamp Format: this format is specified in 236 Section 4.3 of [RFC8877]. For the reader's convenience this 237 format is illustrated in Figure 2. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Seconds | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Nanoseconds | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. 249 * NTP [RFC5905] 64-bit Timestamp Format: this format is specified in 250 Section 4.4 of [RFC8877]. For the reader's convenience this 251 format is illustrated in Figure 3. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Seconds | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Fraction | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 3: NTP [RFC5905] 64-bit Timestamp Format 263 Synchronization aspects of the timestamp format in the context of the 264 NSH timestamp allocation are discussed in Section 5. 266 4. Timestamping Use Cases 267 4.1. Network Analytics 269 Per-packet timestamping enables coarse-grained monitoring of the 270 network delay along the Service Function Chain. Once a potential 271 problem or bottleneck is detected, for example when the delay exceeds 272 a certain policy, a highly-granular monitoring mechanism can be 273 triggered, for example using the hop-by-hop measurement data of 274 [RFC8592] or [I-D.ietf-ippm-ioam-data], allowing to analyze and 275 localize the problem. 277 Timestamping is also useful for logging, troubleshooting and for flow 278 analytics. It is often useful to maintain the timestamp of the first 279 and last packet of the flow. Furthermore, traffic mirroring and 280 sampling often requires a timestamp to be attached to analyzed 281 packets. Attaching the timestamp to the NSH provides an in-band 282 common time reference that can be used for various network analytics 283 applications. 285 4.2. Alternate Marking 287 A possible approach for passive performance monitoring is to use an 288 alternate marking method [RFC8321]. This method requires data 289 packets to carry a field that marks (colors) the traffic, and enables 290 passive measurement of packet loss, delay, and delay variation. The 291 value of this marking field is periodically toggled between two 292 values. 294 When the timestamp is incorporated in the NSH, it can natively be 295 used for alternate marking. For example, the least significant bit 296 of the timestamp Seconds field can be used for this purpose, since 297 the value of this bit is inherently toggled every second. 299 4.3. Consistent Updates 301 The timestamp can be used for taking policy decisions such as 302 'Perform action A if timestamp>=T_0'. This can be used for enforcing 303 time-of-day policies or periodic policies in service functions. 304 Furthermore, timestamp-based policies can be used for enforcing 305 consistent network updates, as discussed in [DPT]. It should be 306 noted that, as in the case of Alternate Marking, this use case alone 307 does not require a full 64-bit timestamp, but could be implemented 308 with a significantly smaller number of bits. 310 5. Synchronization Considerations 312 Some of the applications that make use of the timestamp require the 313 Classifier and SFs to be synchronized to a common time reference, for 314 example using the Network Time Protocol [RFC5905] or the Precision 315 Time Protocol [IEEE1588]. Although it is not a requirement to use a 316 clock synchronization mechanism, it is expected that depending on the 317 applications that use the timestamp, such synchronization mechanisms 318 will be used in most deployments that use the timestamp allocation. 320 6. IANA Considerations 322 This memo includes no request to IANA. 324 7. Security Considerations 326 The security considerations of NSH in general are discussed in 327 [RFC8300]. NSH is typically run within a confined trust domain. 328 However, if a trust domain is not enough to provide the operator with 329 the protection against the timestamp threats described below, then 330 the operator SHOULD use transport-level protection between SFC 331 processing nodes as described in [RFC8300]. 333 The security considerations of in-band timestamping in the context of 334 NSH is discussed in [RFC8592], and the current section is based on 335 that discussion. 337 The use of in-band timestamping, as defined in this document, can be 338 used as a means for network reconnaissance. By passively 339 eavesdropping to timestamped traffic, an attacker can gather 340 information about network delays and performance bottlenecks. A man- 341 in-the-middle attacker can maliciously modify timestamps in order to 342 attack applications that use the timestamp values, such as 343 performance monitoring applications. 345 Since the timestamping mechanism relies on an underlying time 346 synchronization protocol, by attacking the time protocol an attack 347 can potentially compromise the integrity of the NSH timestamp. A 348 detailed discussion about the threats against time protocols and how 349 to mitigate them is presented in [RFC7384]. 351 8. Acknowledgments 353 The authors thank Mohamed Boucadair and Greg Mirsky for their 354 thorough reviews and detailed comments. 356 9. References 357 9.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 365 Chaining (SFC) Architecture", RFC 7665, 366 DOI 10.17487/RFC7665, October 2015, 367 . 369 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 370 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 371 May 2017, . 373 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 374 "Network Service Header (NSH)", RFC 8300, 375 DOI 10.17487/RFC8300, January 2018, 376 . 378 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 379 Defining Packet Timestamps", RFC 8877, 380 DOI 10.17487/RFC8877, September 2020, 381 . 383 9.2. Informative References 385 [DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane 386 Timestamping in SDN", IEEE INFOCOM Workshop on Software- 387 Driven Flexible and Agile Networking (SWFAN), 2016. 389 [I-D.ietf-ippm-ioam-data] 390 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 391 for In-situ OAM", Work in Progress, Internet-Draft, draft- 392 ietf-ippm-ioam-data-17, 13 December 2021, 393 . 396 [I-D.ietf-sfc-nsh-broadband-allocation] 397 Napper, J., Kumar, S., Muley, P., Hendericks, W., and M. 398 Boucadair, "NSH Context Header Allocation for Broadband", 399 Work in Progress, Internet-Draft, draft-ietf-sfc-nsh- 400 broadband-allocation-01, 19 June 2018, 401 . 404 [I-D.ietf-sfc-nsh-dc-allocation] 405 Guichard, J., Smith, M., Kumar, S., Majee, S., and T. 406 Mizrahi, "Network Service Header (NSH) MD Type 1: Context 407 Header Allocation (Data Center)", Work in Progress, 408 Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25 409 September 2018, . 412 [I-D.ietf-sfc-nsh-tlv] 413 Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E. 414 Eastlake, "Network Service Header Metadata Type 2 415 Variable-Length Context Headers", Work in Progress, 416 Internet-Draft, draft-ietf-sfc-nsh-tlv-10, 3 December 417 2021, . 420 [IEEE1588] IEEE, "IEEE 1588 Standard for a Precision Clock 421 Synchronization Protocol for Networked Measurement and 422 Control Systems Version 2", 2008. 424 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 425 "Network Time Protocol Version 4: Protocol and Algorithms 426 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 427 . 429 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 430 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 431 October 2014, . 433 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 434 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 435 "Alternate-Marking Method for Passive and Hybrid 436 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 437 January 2018, . 439 [RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance 440 Indicator (KPI) Stamping for the Network Service Header 441 (NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019, 442 . 444 Authors' Addresses 446 Tal Mizrahi 447 Huawei 448 Israel 450 Email: tal.mizrahi.phd@gmail.com 451 Ilan Yerushalmi 452 Marvell 453 6 Hamada 454 Yokneam 2066721 455 Israel 457 Email: yilan@marvell.com 459 David Melman 460 Marvell 461 6 Hamada 462 Yokneam 2066721 463 Israel 465 Email: davidme@marvell.com 467 Rory Browne 468 Intel 469 Dromore House 470 Shannon, Co.Clare 471 Ireland 473 Email: rory.browne@intel.com