idnits 2.17.1 draft-foschiano-erspan-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 : ---------------------------------------------------------------------------- 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 (January 2016) is 3024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft M. Foschiano 4 Category: Informational Cisco Systems 5 Expires: July 2016 January 2016 7 Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN) 8 draft-foschiano-erspan-01.txt 10 Abstract 12 This document describes an IP-based packet capture format that can 13 be used to transport exact copies of packets to a network probe to 14 analyze and characterize the operational load and protocol 15 distribution of a network as well as to detect anomalies such as 16 network-based worms or viruses. This replication and transport 17 mechanism operates over one or multiple switch or router ports whose 18 traffic can be mirrored and forwarded to a destination device in 19 charge of traffic analysis and reporting. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire in July 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. 50 Table of Contents 52 1. Introduction..................................................3 53 2. ERSPAN's Basic Principles of Operation........................3 54 3. ERSPAN's Common Encapsulation Components......................4 55 4. ERSPAN Types and Specific Sub-Headers.........................5 56 4.1 ERSPAN Type II............................................5 57 4.2 ERSPAN Type III...........................................7 58 5. ERSPAN Session Numbers.......................................12 59 6. Ethernet and IP fields.......................................13 60 7. Use of Other Relevant ERSPAN Fields..........................13 61 8. Routing and Security Considerations..........................14 62 9. IANA Considerations..........................................15 63 10. Changes from the Previous Version..........................15 64 11. Acknowledgements...........................................15 65 12. Normative References.......................................15 67 1. Introduction 69 Today one of the most common network monitoring and troubleshooting 70 tools is the so-called Switch Port Analyzer (SPAN) feature, also 71 known as port mirroring. It allows a user to monitor network traffic 72 non-intrusively and send a copy of the monitored traffic to a local 73 or remote device, which can be a sniffer, an intrusion detection 74 system (IDS), or other type of network analysis tool. 76 Some of the most popular use cases of SPAN are: 78 1. Debugging network problems by tracking control/data frames 80 2. Monitoring Voice-over-IP (VoIP) packets for delay and jitter 81 analysis 83 3. Monitoring network transactions for latency analysis 85 4. Monitoring network traffic for anomaly detection 87 SPAN can operate locally and mirror traffic to other ports of the 88 same source device, or it can operate remotely mirroring traffic to 89 a different network device that is layer-2 adjacent to the source. 91 This document describes the frame formats used by the "encapsulated 92 remote" extension of the SPAN feature, which supports remote 93 monitoring of network traffic across a generic IP transport. 95 2. ERSPAN's Basic Principles of Operation 97 The ERSPAN feature enables a network device to deliver a copy of the 98 monitored traffic to a destination system through an IP network. 100 To do so, a source network device filters the portion of the traffic 101 the user is interested in, makes a copy of it and then encapsulates 102 each replicated frame into the payload of a special "container 103 super-frame". Such frame carries enough additional information for 104 it to be properly routed all the way to the receiver device and for 105 such device to be able to extract and fully restore the original 106 monitored Ethernet frame (or a selected portion of it). 108 The receiver device can be another networking device that supports 109 ERSPAN decapsulation or, when direct connectivity is available, even 110 a (non passive) network probe. 112 The frame formats used to enable such capabilities are described in 113 the following sections. 115 3. ERSPAN's Common Encapsulation Components 117 The ERSPAN packet format is GRE-based [RFC1701], and for it most 118 legacy implementations assume an underlying IPv4 [RFC791] over 119 Ethernet [802.3] transport. However, even though IPv4 is normally 120 used, IPv6 support has become a requirement too. 122 The use of the IP protocol as part of the transport is critical to 123 be able to carry the mirrored traffic across any IP-based network. 124 The GRE component instead is particularly important to be able to 125 piggyback different data formats along with the copy of the original 126 frame. 128 The ERSPAN frame format's common components are described below: 130 802.3 Ethernet MAC header (14 octets [0:13]) 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Destination MAC Address | 135 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 138 | Source MAC Address | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Ethertype/Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 IPv4 header (20 octets [14:33]) 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |Version| IHL |Type of Service| Total Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Identification |Flags| Fragment Offset | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Time to Live | Protocol | Header Checksum | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Source IP Address | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Destination IP Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 (Above, for simplicity's sake the described frame format is IPv4's, 159 yet IPv6 can be supported too in certain implementations.) 160 GRE header for ERSPAN encapsulation (8 octets [34:41]) 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |0|0|0|1|0| 000 | 00000 | 000 | Protocol Type for ERSPAN | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Sequence Number (increments per packet per session) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Note that in the above GRE header [RFC1701] out of the C, R, K, S, 170 s, Recur, Flags, Version fields only S (bit 03) is set to 1. The 171 other fields are set to zero, so only a sequence number follows. 173 4. ERSPAN Types and Specific Sub-Headers 175 On top of the GRE header, the ERSPAN format includes an additional 176 "feature" header chosen from two variants known as "ERSPAN Types". 178 They can be distinguished based on the GRE Protocol Type value: Type 179 II's value is 0x88BE while Type III's is 0x22EB [ETYPES]. 181 4.1 ERSPAN Type II 183 ERSPAN Type II's 8-octet feature header was the first variant to be 184 extensively used by Cisco Systems products. 186 The ERSPAN Type II feature header is described below: 188 ERSPAN Type II header (8 octets [42:49]) 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Ver | VLAN | COS | En|T| Session ID | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Reserved | Index | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 The above 8-octet header is immediately followed by the original 198 mirrored frame and then by the standard 4-octet Ethernet CRC: 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Original Mirrored Frame | 202 | ... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | CRC | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Therefore, the ERSPAN Type II encapsulation adds to the original 208 frame a composite header comprising: 14 (802.3) + 20 (IP) + 8 (GRE) 209 + 8 (ERSPAN) octets, in addition to a trailing 4-octet Ethernet CRC. 210 (Note that an 802.1Q encapsulation [802.1Q] would add 4 additional 211 octets but not reduce the Ethernet MTU size of the container frame.) 213 The various fields of the above header are described in this table: 215 Field Position Length Definition 216 [octet:bit] (bits) 218 Ver [42:0] 4 ERSPAN Encapsulation version. 219 This indicates the version of 220 the ERSPAN encapsulation 221 specification. Set to 0x1 for 222 Type II. (Version 0x0 is 223 obsoleted.) 225 VLAN [42:4] 12 Original VLAN of the frame, 226 mirrored from the source. 227 If the En field is set to 11, 228 the value of VLAN is undefined. 230 COS [44:0] 3 Original class of service of the 231 frame, mirrored from the source. 233 En [44:3] 2 The trunk encapsulation type 234 associated with the ERSPAN source 235 port for ingress ERSPAN traffic. 237 The possible values are: 238 00-originally without VLAN tag 239 01-originally ISL encapsulated 240 10-originally 802.1Q encapsulated 241 11-VLAN tag preserved in frame. 243 T [44:5] 1 This bit indicates that the frame 244 copy encapsulated in the ERSPAN 245 packet has been truncated. This 246 occurs if the ERSPAN encapsulated 247 frame exceeds the configured MTU. 249 Session ID [44:6] 10 Identification associated with 250 (ERSPAN ID) each ERSPAN session. Must be 251 unique between the source and the 252 receiver(s). (See section below.) 254 Reserved [46:0] 12 All bits are set to zero 255 Index [47:4] 20 A 20 bit index/port number 256 associated with the ERSPAN 257 traffic's source port and 258 direction (ingress/egress). This 259 field is platform dependent. 261 4.2 ERSPAN Type III 263 Type III introduces a larger and more flexible composite header to 264 support additional fields useful for applications such as network 265 management, intrusion detection, performance and latency analysis 266 etc. that require to know all the original parameters of the 267 mirrored frame, including those not present in the original frame 268 itself. 270 The ERSPAN Type III composite header includes a mandatory 12-octet 271 portion followed by an optional 8-octet platform specific sub-header 272 as described below: 274 ERSPAN Type III header (12 octets) 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Ver | VLAN | COS |BSO|T| Session ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Timestamp | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SGT |P| FT | Hw ID |D|Gra|O| 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Platform Specific SubHeader (8 octets, optional) 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Platf ID | Platform Specific Info | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Platform Specific Info | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The above composite header is immediately followed by the original 293 mirrored frame and then by the standard 4-octet Ethernet CRC. 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Original Mirrored Frame | 297 | ... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | CRC | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 The various fields of the above header are described in this table: 304 Header Fields in Common with ERSPAN Type II 306 Field Length (bits) Definition 308 Ver 4 ERSPAN Encapsulation version. 309 For Type-III packets it is set to 0x2. 311 VLAN 12 VLAN of the frame monitored by an ERSPAN 312 source session: for ingress monitor this 313 will be the original source VLAN whereas 314 for egress monitor this will be the 315 destination VLAN. 317 COS 3 Class of Service of the monitored frame. 318 Ingress or egress CoS value is to be used 319 depending on the monitor type/direction. 321 T 1 This bit indicates that the frame copy 322 encapsulated in the ERSPAN packet has 323 been truncated. This occurs if the ERSPAN 324 encapsulated frame exceeds the configured 325 MTU and hence has to be truncated. 327 Session ID 10 Identification associated with each ERSPAN 328 (ERSPAN ID) session. Must be unique between the source 329 and the receiver(s). (See section below.) 331 ERSPAN Type-III Header Specific Fields 333 Field Length Definition 334 (bits) 336 BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of 337 Oversized) the payload carried by ERSPAN: 338 00 --> Good frame with no error, or 339 unknown integrity 340 11 --> Payload is a Bad Frame with CRC or 341 Alignment Error 342 01 --> Payload is a Short Frame 343 10 --> Payload is an Oversized Frame 345 Timestamp 32 The timestamp value needs to be derived 346 from a hardware clock which is 347 synchronized to the system-clock. This 32- 348 bit field must support at least a 349 timestamp granularity of 100 microseconds 350 (see the Timestamp Granularity field). 352 SGT 16 Security Group Tag of the monitored frame. 354 P 1 This bit indicates that the ERSPAN payload 355 is an Ethernet protocol frame (PDU frame). 357 FT (Frame Type) 5 This field can be used to reconstruct the 358 original frame's encapsulation if it is 359 supported by the receiver. 360 This field may also be used by ERSPAN 361 engines to indicate that the mirrored 362 frame's L2 encapsulation header (or a 363 portion of it) was skipped and not 364 included in the ERSPAN packet. 365 00000 --> Ethernet frame (802.3 frame) 366 00010 --> IP Packet 367 Other values --> Reserved for future use 369 Hw (Hardware) ID 6 Unique identifier of an ERSPAN engine 370 within a system. 372 D (Direction) 1 Indicates whether the original frame was 373 SPAN'ed in ingress or in egress. 374 Ingress (0) or Egress (1). 376 Gra (Timestamp 377 Granularity) 2 Time unit to be supported for time- 378 stamping: 379 00b --> granularity = 100 microseconds 380 01b --> granularity = 100 nanoseconds 381 10b --> granularity = IEEE 1588 382 TimeRepresentation format (see definition 383 below; with nanoseconds portion stored in 384 the Timestamp field and seconds portion 385 stored in the ERSPAN platform-dependent 386 sub-header) 388 struct TimeRepresentation 389 { 390 UInteger32 seconds; 391 UInteger32 nanoseconds; 392 }; 393 11b --> user configurable time unit 394 (platform dependent, for example specific 395 to an isolated non-synchronized system 396 with very high local accuracy) 398 O (Optional 399 Sub-header) 1 The O flag indicates whether or not the 400 optional platform-specific sub-header is 401 present. If it's present, the next octet 402 indicates the platform specific format 403 used (Platf ID). The ERSPAN payload starts 404 after the O flag when O == 0b or after 8 405 octets when O == 1b. 407 Platf ID 6 Platform identifier that needs to be 408 recognized in order to parse the optional 409 platform-specific sub-header that follows. 411 Platform 412 Specific Info 58 Platform Specific Information field. It 413 is a container for data that is used by 414 a specific set of devices only. 416 Currently only the following Platform ID values are used and 417 correspond to defined Platform Specific Info field formats: 419 Platf ID Value Description 421 0x0 Reserved 423 0x1 Corresponds to the following format: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | 0x1 | Reserved | VSM Domain ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Port_ID/Index | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 When the 0x1 value is used, the timestamp 434 in the base header is in 100 microseconds 435 and the Gra field is set to '00'. 436 The VSM Domain ID field is the identifier 437 of a Cisco Nexus VSM domain. 439 0x2 Reserved 440 0x3 Corresponds to the following format: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | 0x3 | Reserved | Port ID/Index | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Timestamp (upper 4 octets of a UInteger64 value) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 The granularities supported when the 451 Platform ID is set to 0x3 are 00b 452 (100 microseconds), 01b (100 nanoseconds) 453 and 11b (nanoseconds). 454 An unsigned 64-bit timestamp value can be 455 derived from combining the base ERSPAN 456 header's 32-bit value (lower 4 octets) 457 with the Platform Specific Info's 32-bit 458 value (upper 4 octets) and can be 459 interpreted based on the granularity value 460 set in the Gra field. 462 0x4 Corresponds to the following format: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | 0x4 | Reserved | Reserved | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Reserved | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 When the 0x4 value is used, the timestamp 473 value in the base header represents a 474 UInteger32 timestamp value expressed in 475 100 microsecond units (Gra field = '00'). 477 0x5-0x6 Correspond to the following format: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0x5 or 0x6 | Switch ID | Port ID/Index | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Timestamp (seconds) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 When the 0x5 or the 0x6 value is used, 487 the timestamp value in the base header 488 represents the IEEE 1588 nanoseconds field 489 while the timestamp value in the Platform 490 Specific Info represents the IEEE 1588 491 seconds. The Gra field is set to '10'. 492 Switch ID is a value configurable in the 493 CLI to identify a source switch at the 494 receiving end. Port ID identifies the 495 source switch port for the SPAN'd traffic. 497 0x7-0x63 Reserved 499 It should be noted that the various supported header fields above 500 can be used in regular ERSPAN applications to mirror even an errored 501 frame or a bridge PDU (BPDU) frame and to preserve the original 502 trunking encapsulation and VLAN number. In addition, crucial 503 time-stamping information as well as other informational fields can 504 be added to each ERSPAN frame on the source device during the frame 505 mirroring/replication process. 507 The use of various feature header fields is discussed in the 508 following sections. 510 5. ERSPAN Session Numbers 512 An ERSPAN session is a configuration parameter that the user can 513 employ to differentiate between mirrored traffic. It is typically 514 associated to a single or to a group of physical or logical 515 entities, such as one or more ports or one or more VLANs, whose 516 traffic requires mirroring. In general, a session number identifies 517 a subset of the traffic of a source device that a user wishes to 518 replicate and analyze. Session numbers therefore represent a context 519 in which a particular stream of mirrored frames can be placed and by 520 which it can be identified. Such context is usually meaningful when 521 associated to a particular source-destination device pair. 523 As a matter of fact, within the ERSPAN IP header two key 524 identification parameters are the source IP address and the 525 destination IP address of the ERSPAN packets: the former uniquely 526 identifies the source device of the mirrored frames while the latter 527 uniquely identifies the destination device, which is to terminate 528 the flow of ERSPAN packets. 530 Different source-destination device pairs can reuse session numbers 531 as long as they represent fully disjoint ERSPAN contexts. 533 6. Ethernet and IP fields 535 Noteworthy parameters in the Ethernet and IP portion of an ERSPAN 536 frame are its Quality of Service (QoS) fields, CoS and ToS, which 537 users can program on a per session basis in such a way as to meet 538 the priority and delay requirements of their traffic analysis 539 applications. 541 For example, in certain conditions of network congestion it may be 542 desirable to configure a higher QoS priority for ERSPAN frames to 543 allow them to reach the analysis device despite congestion and so 544 allow the network administrator to troubleshoot potential bandwidth 545 utilization issues. In other cases, instead, dropping of ERSPAN 546 traffic may not constitute a problem for the network administrator 547 and therefore lowering of the ERSPAN QoS priority can be considered 548 completely acceptable. 550 In addition, the IP Identification field of ERSPAN Type II packets 551 is sometimes used to distinguish between different ERSPAN source 552 engines by writing in the field's upper 6 bits a unique fixed ERSPAN 553 Engine ID value while incrementing the remaining 10 bits for each 554 mirrored frame. This parameter provides an additional level of 555 granularity for traffic identification (and therefore feature 556 flexibility) in addition to the source device's IP address and the 557 ERSPAN session number, as described above. 558 On the other hand, for the purpose of identifying different ERSPAN 559 source engines, ERSPAN Type III uses the dedicated Hardware ID field 560 instead. 562 7. Use of Other Relevant ERSPAN Fields 564 The En(capsulation) field is used to distinguish the VLAN 565 encapsulation format of the original mirrored frame: IEEE 566 802.3/untagged (no VLAN number in the frame), IEEE 802.1Q tagging 567 format or Cisco Systems' ISL tagging format. 569 The T(runcated) field is an indication of whether the original frame 570 had to be truncated to fit into the MTU used for ERSPAN transmission. 571 (Note that currently ERSPAN recalculates and overwrites the CRC of 572 the original Ethernet frame when adding the ERSPAN L2/IP/GRE 573 encapsulation, so even truncated frames can reach the analysis 574 device with a good CRC.) 576 8. Security Considerations 578 Source and destination IP addresses used for ERSPAN must be fully 579 routable addresses, so that for example in certain implementations 580 users could even ping such addresses to ascertain the aliveness of 581 the corresponding source or destination device. 583 Moreover, specifically in the case of a destination ERSPAN device, 584 its IP address oftentimes represents a "front end" or proxy to an 585 IP-less device such as a passive sniffer or other analysis tool. 586 This proxying capability is extremely beneficial when the end device 587 acts in stealth mode and cannot appear as an active and reachable 588 node of the network. 590 Although ERSPAN does not offer specific capabilities for security 591 such as authentication or encryption, the IP TTL of the ERSPAN 592 packets is configurable and can be used to limit the reach of ERSPAN 593 packets within an IP cloud. In addition, as any standard IP packet, 594 ERSPAN packets could be transported in regular tunnels, such as 595 IPSec or MPLS tunnels, however by design they have the IP Don't 596 Fragment bit set to avoid the need for packet reassembly. 598 9. IANA Considerations 600 This document has no actions for IANA. 602 10. Changes from the Previous Version 604 Initial revision. 606 11. Acknowledgements 608 Various people have contributed to the definition of the ERSPAN 609 format and have provided input and reviewed this document. For both 610 contributions the author would like to thank, in alphabetical order, 611 Ian Cox, Kalyan Ghosh, Archana Kamath, Munish Mehta and 612 Nageswara Ponugoti, as well as Liangda Ho for finding a typo. 613 For fundamental contributions to the invention of the various ERSPAN 614 types the author would also like to thank Tom Edsall and Suresh 615 Gurajapu. Last but not least, a special thanks goes to Nicolas 616 Delecroix, without whom this document would not have been possible. 618 12. Normative References 620 [802.3] IEEE Std 802.3 -2012, IEEE Standard for Ethernet. 622 [802.1Q] IEEE Std 802.1Q-2003, IEEE Standards for Local and 623 Metropolitan Area Networks: Virtual Bridged Local Area 624 Networks. 626 [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet 627 Program Protocol Specification," RFC 791, USC/Information 628 Sciences Institute, September 1981. 630 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 631 Routing Encapsulation", RFC 1701, October 1994. 633 [ETYPES] IEEE Ethertype List: 634 http://standards.ieee.org/develop/regauth/ethertype/eth.txt. 636 Author's Address 638 Marco Foschiano, Cisco Systems, Inc., Via Torri Bianche 7, Vimercate, 639 MI, 20059, Italy, email address: foschia@cisco.com