idnits 2.17.1 draft-kumar-mpls-mint-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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The maximum length in a MINT header, if set to 0, MAY trigger the metadata fragmentation special function. This mechanism can be used to generate MINT reports at each hop and never insert metadata in the packet. If the maximum length is set to 0, a node MAY NOT insert MINT metadata, SHOULD create a MINT report or copy of the packet including its own metadata, and MUST increment the MINT MDF header fragment identifier field. -- The document date (March 11, 2019) is 1874 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) == Missing Reference: 'RFC 6790' is mentioned on line 184, but not defined == Unused Reference: 'RFC6790' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC7274' is defined on line 817, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-kumar-ippm-ifa-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Kumar 3 Intended Status: Standards Track J. Lemon 4 Y. Peleg 5 Broadcom Inc. 6 K. Kompella 7 Juniper Networks 8 Expires: September 12, 2019 March 11, 2019 10 MPLS Inband Network Telemetry 11 draft-kumar-mpls-mint-00 13 Abstract 15 MPLS Inband Network Telemetry (MINT) records flow specific 16 information from end stations and/or switches across a network. This 17 document describes the method to collect data on a per hop basis 18 across a network and perform localized or end to end analytics 19 operations on the data. This document also describes the use of the 20 Extension Label, value 15, for specifying extended special purpose 21 labels for specifying presence of MINT data. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1 Encapsulation Requirements . . . . . . . . . . . . . . . . . 6 67 2.2 Operational Requirements . . . . . . . . . . . . . . . . . . 6 68 3. MINT Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1 MINT Domain . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2 MINT Function Nodes . . . . . . . . . . . . . . . . . . . . 8 71 3.2.1 Initiating Function Node . . . . . . . . . . . . . . . . 8 72 3.2.2 Transit Function Node . . . . . . . . . . . . . . . . . 9 73 3.2.3 Terminating Function Node . . . . . . . . . . . . . . . 9 74 3.2.4 Metadata Fragmentation Function . . . . . . . . . . . . 9 75 3.3 MINT Cloning, Truncation, and Drop . . . . . . . . . . . . . 10 76 3.4 MINT Label Stack . . . . . . . . . . . . . . . . . . . . . . 10 77 3.4.1 MINT Metadata Header . . . . . . . . . . . . . . . . . . 12 78 3.4.2 MINT Checksum Header . . . . . . . . . . . . . . . . . . 13 79 3.4.3 MINT Metadata Fragmentation (MF) Header . . . . . . . . 14 80 3.5 MINT Metadata . . . . . . . . . . . . . . . . . . . . . . . 15 81 3.5.1 Global Name Space (GNS) Identifier . . . . . . . . . . . 15 82 3.5.2 Local Name Space (LNS) Identifier . . . . . . . . . . . 16 83 3.5.3 Device ID . . . . . . . . . . . . . . . . . . . . . . . 16 84 3.6 MINT Network Overhead . . . . . . . . . . . . . . . . . . . 16 85 3.7 MINT Analytics . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.8 MINT Packet Format . . . . . . . . . . . . . . . . . . . . . 17 87 3.8.1 MINT Packet Format with TS Flag Set . . . . . . . . . . 17 88 3.9 MINT Load Balancing . . . . . . . . . . . . . . . . . . . . 18 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 90 4.1. Extended Special-Purpose MPLS Label Values Registry . . . 19 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 19 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.1 Normative References . . . . . . . . . . . . . . . . . . . 19 95 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 This document describes MPLS Inband Network Telemetry (MINT), which 101 is a mechanism to enable the collection of metadata for an analyzed 102 MPLS flow. 104 The sequence of per hop metadata in the packet preceded by a MINT 105 header is referred to as a MINT stack. The presence of a MINT stack 106 is indicated by an extended special purpose label. The "Extension 107 Label", value 15, is used to indicate a following label, which will 108 be the MINT label in this case. 110 The MINT header and metadata definition are the same as defined in 111 [I-D.draft-kumar-ippm-ifa-01]. 113 1.1 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 LSP: Label Switched Path 121 MPLS: Multi Path Label Switching 123 MINT: MPLS Inband Network Telemetry 125 MTU: Maximum Transmit Unit 127 MINT Domain: A set of MPLS nodes within a single administration with 128 all nodes participating in MINT. 130 MINT Node: A single node in a MINT domain. 132 MINT Metadata: Information inserted by a MINT node. 134 MINT Stack: Ordered collection of per hop metadata. 136 MINT Label: IANA allocated extended special purpose label. Indicates 137 the presence of a MINT stack. 139 MINT Initiator: A MINT node at the beginning edge of a MINT domain 140 that is responsible for inserting an Extension label, a MINT label, 141 and the initial MINT metadata. 143 MINT Transit: A MINT node within the MINT domain, responsible for 144 adding MINT metadata for the current node. 146 MINT Terminator: A MINT node at the ending edge of a MINT domain that 147 is responsible for removing the Extension label, the MINT label, and 148 the MINT Stack and exporting the MINT Stack to a collector. 150 1.2 Scope 152 This document describes MINT deployment, header definitions, packet 153 format, and data path functions. 155 MINT deployment involves defining a MINT Domain and understanding the 156 requirements in terms of traffic overhead and points of data 157 collection. Given that MINT inserts two extra labels in the label 158 stack, consideration MUST be given to network devices' capability to 159 parse the depth of the label stack. The scope of MINT is from an end 160 station and/or ToR, through any/all nodes in the MPLS path, and 161 terminating in a network switch and/or an end station. In case of a 162 service provider network, the scope of MINT MAY encompass one carrier 163 to another carrier. Special care MUST be taken for leaking the MINT 164 stack across a MINT domain for security reasons. 166 MINT can create a synthetic stream of MPLS traffic and use it to 167 collect metadata along the path. This sampled stream is later 168 discarded. MINT can also insert metadata on a per packet basis in 169 live traffic. 171 This draft defines an identification mechanism using a extended 172 special purpose label for MINT packets. 174 1.3 Applicability 176 MINT is capable of providing traffic analysis for a given LSP. The 177 LSP may be tunneled in another LSP in part of the MINT domain. In 178 such cases more then one MINT stack MAY be present in the MINT 179 packet. 181 A very important requirement of MINT traffic is preserving the same 182 path for the flow. Since inserting a MINT label will change the 183 label stack and possibly keys to load balancing functions, a MINT 184 domain SHOULD use an entropy label as defined in [RFC 6790] to 185 preserve the flow path. 187 Inserting additional an label and metadata will increase the packet 188 size and may impact path MTU. MINT provides a metadata fragmentation 189 function to keep the packet size below path MTU. 191 1.4 Motivation 193 The main motivation for MINT is to collect analyzed metadata from 194 packets within a flow for a given application. 196 Each hop in the flow path MAY insert metadata in the packet or MAY 197 export metadata to a collector. 199 2. Requirements 201 MINT requirements are the same as IFA requirements and are defined 202 with operational efficiency, performance of the network, and cost of 203 hardware in mind. 205 2.1 Encapsulation Requirements 207 MINT packets MUST be clearly marked and identifiable so that a 208 networking element in the flow path can insert metadata or perform 209 other MINT operations. 211 MINT packets need to be easily identified for performance reasons. A 212 new extended special purpose label is requested for MINT. 214 MINT encapsulation MAY support the ability to fragment metadata. 216 MINT encapsulation MAY support direct export of metadata instead of 217 inserting it into the packet. 219 2.2 Operational Requirements 221 MINT MUST preserve the flow path across the network. This can be 222 done either by using specific key fields for load balancing functions 223 or by using an entropy label. 225 MINT MUST support cloning, live traffic, checksum, fragmentation, 226 global name spaces, and local name spaces using the MINT header 227 definitions. 229 3. MINT Domains 231 MINT performs flow analysis, and possible actions on the flow data, 232 in-band. Once a flow is enabled for analysis, a MINT node with the 233 role of "Initiator" makes a copy of the flow or samples the live 234 traffic flow, or tags a live traffic flow for analysis and data 235 collection. Copying of a flow is done by sampling or cloning the 236 flow. These new packets are representative packets of the original 237 flow and possess the exact same characteristics as the original flow. 238 This means that MINT packets traverse the same path in the network 239 and same queues in the networking element as the original packet 240 would. Figure 1 shows the MINT based Telemetry Framework. The 241 terminating node is responsible for terminating the MINT flow by 242 summarizing the metadata of the entire path and sending it to a 243 collector. 245 +----------+ 246 | | 247 |Collector |--------------+ 248 | | | 249 +----------+ | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 +--------------+ +------------+ +----+-----------+ 259 |Initiator Node| |Transit Node| |Terminating Node| 260 | +------+ | | +------+ | | +------+ | 261 | | MINT | |------->| | MINT | |------->| | MINT | | 262 | +------+ |MINTflow| +------+ |MINTflow| +------+ | 263 +--------------+ +------------+ +----------------+ 265 Figure 1 MINT Domain Framework without fragmentation 266 +----------+ 267 | | 268 |Collector |<-------------+ 269 +----->| | | 270 | +----------+ | 271 | | 272 | | 273 | | 274 | | 275 | | 276 | | 277 | | 278 | | 279 +--------------+ | +------------+ +----+----------+ 280 |Initiator Node| | |Transit Node| |Fragmenter Node| 281 | +------+ | | | +------+ | | +------+ | 282 | | MINT | |------->| | MINT | |------->| | MINT | | 283 | +------+ |MINTflow| +------+ |MINTflow| +------+ | 284 +--------------+ | +------------+ +---------------+ 285 | |MINT 286 | |flow 287 | v 288 | +---------------+ +------+-----+ 289 | |Terminator Node| |Transit Node| 290 +--| +------+ | | +------+ | 291 | | MINT | |<-------| | MINT | | 292 | +------+ |MINTflow| +------+ | 293 +---------------+ +------------+ 294 Figure 2 MINT Domain Framework with metadata fragmentation 295 3.1 MINT Domain 297 A MINT Domain is the domain of interest where MINT monitoring is 298 enabled. A MINT Domain MUST have designated MINT function nodes. 299 Initiating and Terminating function MINT nodes are always at the edge 300 of the MINT domain. Internal nodes in the MINT Domain are always 301 Transit function nodes. 303 3.2 MINT Function Nodes 305 There are three types of MINT functional nodes with respect to a 306 specific set of flows. Each node MAY perform metadata fragmentation 307 function as well. 309 3.2.1 Initiating Function Node 311 An end station, a switch, or any other middleware can perform the 312 MINT initiating function. It is advantageous to keep this role 313 closest to the application to maximize flow visibility. A MINT 314 initiating function node performs the following functions for a flow: 316 - Samples the flow traffic of interest based on a configuration. 317 - Converts the traffic into a MINT flow by adding a MINT header to 318 each sample. 319 - Updates the packet with initiating function node metadata. 320 - MAY mandate a specific template ID metadata by all networking 321 elements. 322 - MAY mandate tail stamping of metadata by all networking elements. 324 3.2.2 Transit Function Node 326 A MINT transit node is responsible for inserting transit node 327 metadata in the MINT packets in the specified flow. 329 3.2.3 Terminating Function Node 331 A MINT terminating node is responsible for the following for a flow: 332 - Inserts terminating node metadata in a MINT packet. 333 - Performs a local analytics function on one or more segments of 334 metadata, e.g., threshold breach for residence time, congestion 335 notifications, and so on. 336 - Filters a MINT flow in case of cloned traffic. 337 - Sends a copy or report of the packet to a collector. 338 - Removes the MINT headers and forwards the packet in case of live 339 traffic. 341 3.2.4 Metadata Fragmentation Function 342 There are cases where the size of metadata may grow too big for link 343 MTU or path MTU, or where it imposes excessive overhead for the 344 terminating function node to remove it. This is especially true in 345 networks with a large number of hops between the initiator function 346 node and the terminating function node. This is also true where the 347 size of per hop metadata itself is large. For such cases, MINT 348 defines a metadata fragmentation function. The metadata 349 fragmentation function allows removal of metadata from the packet and 350 the sending of a copy/report of the packet to the collector. 351 Correlation of metadata fragments and recreation of metadata stack 352 for the entire flow path is done by the collector. 354 There is no dedicated node performing the metadata fragmentation 355 function. As a MINT packet traverses the hops in a MINT Domain, any 356 node MAY detect the need to fragment the packet's metadata stack and 357 perform metadata fragmentation. 359 Metadata fragmentation is done if the MINT header in the packet has 360 "MDF" bit set and the current length of the metadata would exceed the 361 maximum length after the addition of metadata by the current node. A 362 node MAY create a copy of the packet or create a MINT report, remove 363 the existing metadata stack from the packet, insert its own metadata, 364 and finally forward the packet. A node MAY also update the MINT MDF 365 (Meta Data Fragment) header, fragment identifier, and current length. 367 The maximum length in a MINT header, if set to 0, MAY trigger the 368 metadata fragmentation special function. This mechanism can be used 369 to generate MINT reports at each hop and never insert metadata in the 370 packet. If the maximum length is set to 0, a node MAY NOT insert 371 MINT metadata, SHOULD create a MINT report or copy of the packet 372 including its own metadata, and MUST increment the MINT MDF header 373 fragment identifier field. 375 3.3 MINT Cloning, Truncation, and Drop 377 MINT allows cloning of live traffic. It is expected that cloned 378 traffic will have the same network path characterization as the 379 original traffic, i.e., follow the same network path, use the same 380 queues, etc. 382 Cloned traffic can be truncated to accommodate the MTU of the MINT 383 Domain. 385 Cloned traffic MUST be dropped by the terminating function node of 386 the MINT Domain. 388 3.4 MINT Label Stack 390 The MINT label stack is described below. An extended special-purpose 391 label (ESPL) is used to identify a MINT packet in the MPLS label 392 stack at the level to be measured. 394 0 1 2 3 395 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 396 ESPL: 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Label = 15 (ESPL) |0 0 0|0| TTL=0 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 MINT Extension Label: 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Label = 16 (MINTi) |0 0 0|1| TTL=0 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 MINT Header: 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |Ver=2 | GNS |NextHdr = IP_xx|R|R|R|M|T|I|T|C| Max Length | 409 | | | | | | |F|S| |A| | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 3 MINT Label Headers Format 414 ESPL: 415 A label value of 15 identifies an extended special-purpose label 416 (ESPL), which indicates that the following label is an extension 417 label. The EXP bits SHOULD be set to 0. The S bit MUST be set to 0 418 to indicate that more labels follow. The TTL for the ESPL MUST be 419 zero to ensure that it is not used inadvertently for forwarding. 421 MINT Extension Label: 422 A label value of 16 identifies an MINT extension label, which 423 indicates that header following this label is a MINT header. The EXP 424 bits SHOULD be set to 0. The S bit MUST be set to 1 to indicate that 425 no more labels follow. The TTL for the MINT extension label MUST be 426 zero to ensure that it is not used inadvertently for forwarding. 428 MINT Header: 429 (1) Version (4 bits). Specifies the version of MINT header. The 430 version MUST be set to 2 for this. 432 (2) GNS (4 bits) - Global Name Space. Specifies the MINT Domain 433 scoped name space for the MINT metadata. 435 (3) Protocol Type (8 bits) - IP Header protocol type. This indicates 436 what protocol follows MINT. 438 (4) Flags (8 bits) 439 0: R - Reserved. MUST be initialized to 0 on transmission and 440 ignored on receipt. 442 1: R - Reserved. MUST be initialized to 0 on transmission and 443 ignored on receipt. 445 2: R - Reserved. MUST be initialized to 0 on transmission and 446 ignored on receipt. 448 3: MF - Metadata Fragment. Indicates the presence of the 449 optional metadata fragment header. This header is inserted and 450 initialized by the initiator node. If the MF bit is set, nodes 451 in the path MAY perform fragmentation of metadata stack if the 452 current length exceeds the maximum length. 454 4: TS - Tail Stamp. Indicates the MINT Domain is requiring tail 455 stamping of metadata. 457 5: I - Inband. Indicates this is live traffic. Strip and 458 forward MUST be performed by the terminator node if this bit is 459 set. 461 6: TA - Turn Around. Indicates that the MINT packet needs to be 462 turned around at the terminating node of the MINT Domain and 463 sent back to the source if a return path is known. This bit MAY 464 be used for probe packets where probes are collection 465 bidirectional information in the network. This is analogous to 466 an echo request and echo reply. A packet with the TA bit set 467 collects metadata in one direction, and after it is turned 468 around by the terminating function node, collects metadata in 469 the reverse direction. 471 7: C - Checksum. Indicates the presence of the optional 472 checksum header. The checksum MUST be computed and updated for 473 the MINT header and metadata at each node that modifies the 474 header and/or metadata. A node MAY perform checksum validation 475 before updating the checksum. 477 (5) Max Length (8 bits). Specifies the maximum allowed length of the 478 metadata stack in multiples of 4 octets. This field is initialized 479 by the initiator node. Each node in the path MUST compare the 480 current length with the max length, and if the current length equals 481 or exceeds the max length, the transit nodes MUST stop inserting 482 metadata. 484 3.4.1 MINT Metadata Header 486 The MINT metadata header is always present. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Request Vector| Action Vector | Hop Limit | Current Length| 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 4 MINT Metadata Header Format 496 Request Vector (8 bits) - This vector specifies the presence of 497 fields as specified by GNS. Fields are always 4-octet aligned. This 498 field can be made extensible by defining a new GNS for a MINT Domain. 500 Action Vector (8 bits) - This vector specifies node-local or end-to- 501 end action on the MINT packets. 503 Hop Limit (8 bits) - Specifies the maximum allowed hops in a MINT 504 Domain. This field is initialized by the initiator node. The hop 505 limit MUST be decremented at each hop. If the incoming hop limit is 506 0, current nodes MUST NOT insert metadata. A value of 0xFF means 507 that the Hop limit check MUST be ignored. 509 Current Length (8 bits) - Specifies the current length of the 510 metadata in multiples of 4 octets. 512 3.4.2 MINT Checksum Header 514 The MINT checksum header is optional. Presence of the checksum 515 header is indicated by the C bit in the flags field of the MINT 516 header. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Checksum | Reserved | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 5 MINT Checksum Header Format 526 Checksum (16 bits) - The checksum covers the MINT header and metadata 527 stack. An initiator function node MAY compute the full checksum 528 including MINT header and metadata. Other nodes MAY compute delta 529 checksum for the inserted/deleted metadata. 531 Reserved (16 bits) - Reserved. MUST be initialized to 0 on 532 transmission and ignored on receipt. 534 3.4.3 MINT Metadata Fragmentation (MF) Header 536 The MINT metadata fragmentation (MF) header is optional. Presence of 537 the fragmentation header is indicated by the MF bit in the flags 538 field of the MINT header. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Packet ID | MF ID |L| 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 6 MINT MF Header Format 548 Packet ID (26 bits) - Packet identification value generated by the 549 initiator node. This value is node scoped. 551 Metadata Fragment ID (5 bits) - The initiator MUST initialize this 552 value to 0. A node performing metadata fragmentation function MUST 553 increment the value by 1. 555 L (1 bit) - This bit is set by the node creating the last metadata 556 fragment. This will ALWAYS be the terminating function node. If 557 incoming hop limit is 0, the terminating function node will still 558 generate a copy/report of the packet and MUST set the L bit. A 559 collector MUST implement mechanism to recover from lost 560 packets/reports with L bit set. 562 The MF header is a fixed overhead of 4 octets per packet. A network 563 operator MUST identify the need for using MINT metadata 564 fragmentation. The following network conditions can be considered: 566 - If a MINT packet may exceed the link or path MTU of the flow path 568 - If there are large number of hops in a flow path that could trigger 569 link or path MTU breach 571 - If the length of metadata creates excessive overhead for 572 terminating function node to delete the metadata 574 - If each hop needs to generate its own MINT report (postcard 575 mechanism) 577 With 26 bits of packet id, a maximum datagram lifetime (MDL) of 3 578 seconds, and an average Internet mix (IMIX) packet size of 512 bytes, 579 we get 183.25 Gbps of MINT traffic bit rate per node before the 580 packet identifier wraps around. The collector can use [device id, 581 packet id, MF id, L] to rebuild the fragmented packet. 583 5 bits of MF id will support 32 metadata fragments. 585 3.5 MINT Metadata 587 The MINT metadata is the information inserted by each hop after the 588 MINT header. The MINT metadata can be inserted at the following 589 offsets: 591 - Payload Stamping: Immediately after the layer 4 header. This is 592 the default setting. 593 - Tail Stamping: After the end of the packet, but before the FCS. 594 This is controlled by the TS bit in the flags field of the MINT 595 header. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | LNS | Device ID | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 | | 604 ~ LNS/GNS defined metadata (contd) ~ 605 . . 606 . . 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 7 MINT Metadata Format 611 The MINT metadata header contains a set fields as defined by the name 612 space identifier. Two types of name space identifiers are proposed. 614 3.5.1 Global Name Space (GNS) Identifier 616 A Global Name Space (GNS) is specified in the MINT header by the 617 initiator node. The scope of a GNS is a MINT Domain. All networking 618 elements in a MINT Domain MUST insert metadata as per the GNS ID 619 specified in the MINT header. This is defined as the "Uniform Mode" 620 of deployment. 622 A GNS value of 0xF indicates that metadata in a MINT Domain is 623 defined by the LNS of each hop. 625 The advantage of using the uniform mode is having a simple and 626 uniform metadata stack. This means less load on a collector for 627 parsing. 629 The disadvantage is that metadata fields are supported based on the 630 least capable networking element in the MINT Domain. 632 3.5.2 Local Name Space (LNS) Identifier 634 A Local Name Space (LNS) is specified in the metadata header. A GNS 635 value of 0xF in the MINT header indicates the presence of an LNS. 636 This is defined as the "Non-uniform Mode" of deployment. 638 A switch pipeline MUST parse the GNS field in the MINT header. The 639 parsing result will dictate the name space ID that the hop needs to 640 comply with. 642 The advantage of using the non-uniform mode is having a flexible 643 metadata stack. This allows each hop to include the most relevant 644 data for that hop. 646 The disadvantage is more complex parsing by a collector. 648 3.5.3 Device ID 650 A 28-bit unique identifier for the device inserting the metadata. If 651 a GNS other than 0xF is present, then the device ID can be expanded 652 to a 32 bit value. This is to support including an IPv4 loopback 653 address as a Device ID. 655 3.6 MINT Network Overhead 657 A common problem associated with inserting metadata on a per packet 658 per flow basis is the amount of traffic overhead on the network. 659 MINT is defined to minimize the overhead on the network. 661 MINT Base Header : 4 octets 662 MINT Metadata Header : 4 octets 663 MINT Checksum Header : 4 octets 664 MINT Fragmentation Header : 4 octets 666 Minimum Overhead: 667 MINT header : 4 octets 668 MINT Metadata Header : 4 octets 670 Total Min Overhead : 8 octets per packet 672 3.7 MINT Analytics 673 There are two kinds of actions considered in this proposal. 675 (1) Action Bit MAP in MINT Header - This is encoded in the MINT 676 header. Each node in the path MAY use the action bitmap to insert or 677 not insert the metadata based on exceeding a locally-specified 678 threshold. Not inserting the metadata is indicated by setting the 679 field value to -1 (all 1s). 681 (2) Terminating Node Actions - A terminating node may decide to 682 perform threshold or other actions on the set of metadata in the 683 packet. This information is not encoded in the MINT header. 685 3.8 MINT Packet Format 687 The MINT header is treated as a layer 3 extension header. MINT 688 header and metadata stack length is reflected in IP total length 689 field. IPv6 extension headers are ordered. The MINT header MUST be 690 the last extension header in the IPv6 extension header chain. 691 Similarly in case of IPv4 AH/ESP/WESP extension headers, MINT header 692 MUST be the last extension header. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 ~ ~ 698 | MPLS Label Stack | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | ESPL | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | MINT Extension Label | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | MINT Header | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 ~ ~ 707 | MINT Metadata Header | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ~ ~ 710 | MINT Metadata Stack | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 ~ ~ 713 | Payload | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | FCS | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 8 MINT Packet Format 719 3.8.1 MINT Packet Format with TS Flag Set 720 In case the Tail Stamp flag is set in the MINT header, the MINT 721 metadata header and metadata stack are inserted at the end of the 722 packet just before the FCS. Each node inserts metadata at the bottom 723 of MINT metadata stack. 725 One of the key advantages of using TS is to support legacy devices 726 and/or appliances that need to look at the layer 5 data. The IP 727 length and IP header checksum are updated at each hop inserting 728 metadata. This is the same as without the TS flag. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 ~ ~ 734 | MPLS Label Stack | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | ESPL | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | MINT Extension Label | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | MINT Header | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 ~ ~ 743 | Payload | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 ~ ~ 746 | MINT Metadata Stack | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 ~ ~ 749 | MINT Metadata Header | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | FCS | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 9 MINT Packet Format with TS 756 3.9 MINT Load Balancing 758 As stated in [RFC7325], regarding use of MPLS fields in multipath 759 load balancing: 761 Special-purpose labels (label values 0-15) MUST NOT be used. 762 Extended special-purpose labels (any label following label 15) MUST 763 NOT be used. 765 Accordingly, the addition of an ESPL and a MINT Extension Label will 766 not cause a different multipath computation from that which is 767 calculated in absence of these labels. 769 4. IANA Considerations 771 This document requests the following IANA Actions. 773 4.1. Extended Special-Purpose MPLS Label Values Registry 775 This registry defines a new code point to be added to the Extended 776 Special-Purpose MPLS Label Values Registry to identify that a MINT 777 extension label is present. 778 The following new code point is defined in this draft: 780 16 MINT Extension Label 782 5. Security Considerations 784 A successful attack on an OAM protocol can prevent the detection of 785 failures or anomalies, or create a false illusion of nonexistent 786 ones. 788 The metadata elements of MINT can be used by attackers to collect 789 information about the network hops. 791 Adding MINT headers or adding to MINT metadata can be used to consume 792 resources within the path being monitored or by a collector. 794 Adding MINT headers or adding to MINT metadata can be used to force 795 exceeding the MTU for the path being monitored resulting in 796 fragmentation and/or packet drops. 798 MINT is expected to be deployed within controlled network domains, 799 containing attacks to that controlled domain. Limiting or preventing 800 monitoring or attacks using IFA requires limiting or preventing 801 unauthorized access to the domain in which MINT is to be used, and 802 preventing leaking IFA metadata beyond the controlled domain. 804 6. References 806 6.1 Normative References 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 6.2 Informative References 813 [RFC6790] Kompella, K., "The Use of Entropy Labels in MPLS 814 Forwarding", RFC 6790, November 2012, . 817 [RFC7274] Kompella, K., "Allocating and Retiring Special-Purpose 818 MPLS Labels", RFC 7274, June 2014, . 821 [RFC7325] Villamizar, C., "MPLS Forwarding Compliance and 822 Performance Requirements", RFC 7325, August 2014, . 825 [I-D.draft-kumar-ippm-ifa-01] Kumar, J., "Inband Flow Analyzer", 826 March 2019, 827 (work in progress). 829 Authors' Addresses 831 Jai Kumar 832 Broadcom Inc. 833 Email: jai.kumar@broadcom.com 835 John Lemon 836 Broadcom Inc. 837 Email: john.lemon@broadcom.com 839 Yoav Peleg 840 Broadcom Inc. 841 Email: yoav.peleg@broadcom.com 843 Kireeti Kompella 844 Juniper Networks 845 Email: kireeti@juniper.net