idnits 2.17.1 draft-ietf-detnet-ip-over-mpls-09.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 11, 2020) is 1283 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: 'Network' is mentioned on line 181, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-data-plane-framework (ref. 'I-D.ietf-detnet-data-plane-framework') == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-12 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-12 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-security (ref. 'I-D.ietf-detnet-security') Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track L. Berger 5 Expires: April 14, 2021 D. Fedyk 6 LabN Consulting, L.L.C. 7 S. Bryant 8 Futurewei Technologies 9 J. Korhonen 10 October 11, 2020 12 DetNet Data Plane: IP over MPLS 13 draft-ietf-detnet-ip-over-mpls-09 15 Abstract 17 This document specifies the Deterministic Networking data plane when 18 encapsulating IP over an MPLS packet switched network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 14, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 2 57 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 60 4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5 62 4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6 63 5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8 64 5.1. DetNet IP over DetNet MPLS Flow Identification 65 and Aggregation Procedures . . . . . . . . . . . . . . . 8 66 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 9 67 6. Management and Control Information Summary . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 11.1. Normative references . . . . . . . . . . . . . . . . . . 11 74 11.2. Informative references . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 Deterministic Networking (DetNet) is a service that can be offered by 80 a network to DetNet flows. DetNet provides a capability for the 81 delivery of data flows with extremely low packet loss rates and 82 bounded end-to-end delivery latency. General background and concepts 83 of DetNet can be found in the DetNet Architecture [RFC8655]. 85 This document specifies use of the IP DetNet encapsulation over an 86 MPLS network. It maps the IP data plane encapsulation described in 87 [I-D.ietf-detnet-ip] to the DetNet MPLS data plane defined in 88 [I-D.ietf-detnet-mpls]. 90 2. Terminology 92 2.1. Terms Used In This Document 94 This document uses the terminology and concepts established in the 95 DetNet architecture [RFC8655] and 97 [I-D.ietf-detnet-data-plane-framework], the reader is assumed to be 98 familiar with these documents and their terminology. 100 2.2. Abbreviations 102 This document uses the abbreviations defined in the DetNet 103 architecture [RFC8655] and [I-D.ietf-detnet-data-plane-framework]. 104 This document uses the following abbreviations: 106 CE Customer Edge equipment. 108 d-CW DetNet Control Word. 110 DetNet Deterministic Networking. 112 DF DetNet Flow. 114 DN DetNet. 116 L2 Layer-2. 118 LSP Label-switched path. 120 MPLS Multiprotocol Label Switching. 122 PEF Packet Elimination Function. 124 PRF Packet Replication Function. 126 PREOF Packet Replication, Elimination and Ordering Functions. 128 POF Packet Ordering Function. 130 PW Pseudowire. 132 S-Label DetNet "service" label. 134 S-PE Switching Provider Edge. 136 T-PE Terminating Provider Edge. 138 TE Traffic Engineering. 140 TSN Time-Sensitive Networking, TSN is a Task Group of the 141 IEEE 802.1 Working Group. 143 2.3. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. DetNet IP Data Plane Overview 153 Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network 154 as a sub-network between the relay nodes. An IP flow is mapped to 155 one or more PWs and MPLS (TE) LSPs. The end systems still originate 156 IP encapsulated traffic, identified as DetNet flows. The relay nodes 157 follow procedures defined in Section 4 to map each DetNet flow to 158 MPLS LSPs. While not shown, relay nodes can provide service sub- 159 layer functions such as PREOF using DetNet over MPLS, and this is 160 indicated by the solid line for the MPLS facing portion of the 161 Service component. Note that the Transit node is MPLS (TE) LSP aware 162 and performs switching based on MPLS labels, and need not have any 163 specific knowledge of the DetNet service or the corresponding DetNet 164 flow identification. See Section 4 for details on the mapping of IP 165 flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of 166 DetNet services using MPLS. 168 DetNet IP Relay Transit Relay DetNet IP 169 End System Node Node Node End System 171 +----------+ +----------+ 172 | Appl. |<------------- End to End Service ---------->| Appl. | 173 +----------+ .....-----+ +-----..... +----------+ 174 | Service |<--: Service |--DetNet flow ---| Service :-->| Service | 175 | | : |<-DN MPLS flow ->| : | | 176 +----------+ +---------+ +----------+ +---------+ +----------+ 177 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 178 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 179 : Link : / ,-----. \ : Link : / ,-----. \ 180 +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ 181 [Network] [Network] 182 `-----' `-----' 184 |<---- DetNet MPLS ---->| 185 |<--------------------- DetNet IP ------------------>| 187 Figure 1: Architecture: DetNet IP Over DetNet MPLS Network 189 4. IP over DetNet MPLS 191 This section defines how IP encapsulated flows are carried over a 192 DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since 193 both Non-DetNet and DetNet IP packet are identical on the wire, this 194 section is applicable to any node that supports IP over DetNet MPLS, 195 and this section refers to both cases as DetNet IP over DetNet MPLS. 197 4.1. IP Over DetNet MPLS Data Plane Scenarios 199 An example use of DetNet IP over DetNet MPLS is presented here. 201 Figure 1 illustrates IP DetNet enabled End Systems (hosts) connected 202 to DetNet (DN) enabled IP networks, operating over a DetNet aware 203 MPLS network. In this Figure we have a case where the Relay nodes 204 act as T-PEs and sit at the boundary of the MPLS domain since the 205 non-MPLS domain is DetNet aware. This case is very similar to the 206 DetNet MPLS Network Figure 2 in [I-D.ietf-detnet-mpls]. However, in 207 [I-D.ietf-detnet-mpls] Figure 2, the T-PEs are located at the end 208 system and MPLS spans the whole DetNet service. The primary 209 difference in this document is that the Relay nodes are at the edges 210 of the MPLS domain and therefore function as T-PEs, and that MPLS 211 service sub-layer functions are not provided over the DetNet IP 212 network. The transit node functions shown above are identical to 213 those described in [I-D.ietf-detnet-mpls]. 215 Figure 2 illustrates how relay nodes can provide service protection 216 over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end 217 systems which are interconnected via a MPLS domain such as described 218 in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of 219 an MPLS domain and therefore are similar to T-PEs, while R2 sits in 220 the middle of the domain and is therefore similar to an S-PE. 222 DetNet DetNet 223 IP Service Transit Transit Service IP 224 DetNet |<-Tnl->| |<-Tnl->| DetNet 225 End | V 1 V V 2 V | End 226 System | +--------+ +--------+ +--------+ | System 227 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 228 | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| | 229 |CE1| | | \ | | X | | / | | |CE2| 230 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 231 +---+ | |=======| |=======| | +---+ 232 ^ +--------+ +--------+ +--------+ ^ 233 | Relay Node Relay Node Relay Node | 234 | (T-PE) (S-PE) (T-PE) | 235 | | 236 |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| 237 | | 238 |<-------------- End to End DetNet Service --------------->| 240 -------------------------- Data Flow -------------------------> 242 X = Service protection (PRF, PREOF, PEF/POF) 243 DFx = DetNet member flow x over a TE LSP 245 Figure 2: Service Protection Over DetNet MPLS Network for DetNet IP 247 Figure 1 illustrates DetNet enabled End Systems connected to DetNet 248 (DN) enabled MPLS network. A similar situation occurs when end 249 systems are not DetNet aware. In this case, edge nodes sit at the 250 boundary of the MPLS domain since it is also a DetNet domain 251 boundary. The edge nodes provide DetNet service proxies for the end 252 applications by initiating and terminating DetNet service for the 253 application's IP flows. While the node types differ, there is 254 essentially no difference in data plane processing between relay and 255 edges. There are likely to be differences in controller plane 256 operation, particularly when distributed control plane protocols are 257 used. 259 It is still possible to provide DetNet service protection for non- 260 DetNet aware end systems. This case is basically the same as 261 Figure 2, with the exception that CE1 and CE2 are non-DetNet aware 262 end systems and R1 and R3 become edge nodes. 264 4.2. DetNet IP over DetNet MPLS Encapsulation 266 The basic encapsulation approach is to treat a DetNet IP flow as an 267 app-flow from the DetNet MPLS perspective. The corresponding example 268 DetNet Sub-Network format is shown in Figure 3. 270 /-> +------+ +------+ +------+ ^ ^ 271 | | X | | X | | X |<- App-Flow : : 272 | +------+ +------+ +------+ : : 273 App-Flow <-+ |NProto| |NProto| |NProto| : :(1) 274 for MPLS | +------+ +------+ +------+ : : 275 | | IP | | IP | | IP | : v 276 \-> +---+======+--+======+--+======+-----+ : 277 DetNet-MPLS | d-CW | | d-CW | | d-CW | : 278 +------+ +------+ +------+ :(2) 279 |Labels| |Labels| |Labels| v 280 +---+======+--+======+--+======+-----+ 281 Link/Sub-Network | L2 | | TSN | | UDP | 282 +------+ +------+ +------+ 283 | IP | 284 +------+ 285 | L2 | 286 +------+ 287 (1) DetNet IP Flow (or simply IP flow) 288 (2) DetNet MPLS Flow 290 Figure 3: Example DetNet IP over MPLS Sub-Network Formats 292 In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP 293 data plane. "IP" and "NProto" indicate the fields described in 294 Section 5.1.1. (IP Header Information) and Section 5.1.2. (Other 295 Protocol Header Information) of [I-D.ietf-detnet-ip], respectively. 296 "App-Flow for MPLS" indicates that an individual DetNet IP flow is 297 the payload from the perspective of the DetNet MPLS data plane 298 defined in [I-D.ietf-detnet-mpls]. 300 Per Section 5.1 of [I-D.ietf-detnet-mpls], the DetNet MPLS data plane 301 uses a single S-Label to support a single app flow. DetNet IP Flow 302 Identification Procedures in Section 4.4 of [I-D.ietf-detnet-ip] 303 states that a single DetNet flow is identified based on IP, and next 304 level protocol, header information. Section 4.4. (Aggregation 305 Considerations) of [I-D.ietf-detnet-ip] defines the ways in which 306 aggregation is supported through the use of prefixes, wildcards, 307 lists, and port ranges. Collectively, this results in the fairly 308 straightforward procedures defined in the next section. 310 As shown in Figure 2, DetNet relay nodes are responsible for the 311 mapping of a DetNet flow, at the service sub-layer, from the IP to 312 MPLS DetNet data planes and back again. Their related DetNet IP over 313 DetNet MPLS data plane operation is comprised of two sets of 314 procedures: the mapping of flow identifiers, and ensuring proper 315 traffic treatment. 317 Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP 318 flows. The six-tuple of IP is mapped to the S-Label in both cases. 319 The various fields may be mapped or ignored when going from IP to 320 MPLS. 322 5. IP over DetNet MPLS Procedures 324 The main differences of mapping IP to DetNet MPLS (compared to plain 325 MPLS) are that (1) there is a mandatory flow identification to make 326 the forwarding decision (i.e., forwarding is not based on FEC), (2) 327 the d-CW (DetNet Control Word) is mandatory for the MPLS 328 encapsulation and (3) during forwarding over the DetNet MPLS network 329 DetNet flow specific treatment is needed. 331 5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation 332 Procedures 334 A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a 335 DetNet MPLS network MUST map a DetNet IP flow, as identified in 336 [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process 337 it in accordance to the procedures defined in [I-D.ietf-detnet-mpls]. 338 PRF MAY be supported at the MPLS level for DetNet IP flows sent over 339 an DetNet MPLS network. Aggregation MAY be supported as defined in 340 [I-D.ietf-detnet-mpls] Section 4.4. Aggregation considerations in 341 [I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP 342 flow. The provisioning of the mapping of DetNet IP flows to DetNet 343 MPLS flows MUST be supported via configuration, e.g., via the 344 controller plane. 346 A DetNet relay node (egress T-PE) MAY be provisioned to handle 347 packets received via the DetNet MPLS data plane as DetNet IP flows. 348 A single incoming DetNet MPLS flow MAY be treated as a single DetNet 349 IP flow, without examination of IP headers. Alternatively, packets 350 received via the DetNet MPLS data plane MAY follow the normal DetNet 351 IP flow identification procedures defined in [I-D.ietf-detnet-ip] 352 Section 5.1. 354 An implementation MUST support the provisioning for handling any 355 packet flows received via DetNet MPLS data plane as DetNet IP flows 356 via configuration. Note that such configuration MAY include support 357 from PREOF on the incoming DetNet MPLS flow. 359 Note: using Layer-4 (L4) transport protocols e.g., for multipath are 360 out of scope of this document both for a single flow and aggregate 361 flows. 363 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures 365 The traffic treatment required for a particular DetNet IP flow is 366 provisioned via configuration or the controller plane. When a DetNet 367 IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure 368 that the provisioned DetNet IP traffic treatment is provided at the 369 forwarding sub-layer as described in [I-D.ietf-detnet-mpls] 370 Section 5.2. Note that the PRF function MAY be utilized when sending 371 IP over MPLS. 373 Traffic treatment for DetNet IP flows received over the DetNet MPLS 374 data plane MUST follow Section 5.3 DetNet IP Traffic Treatment 375 Procedures in [I-D.ietf-detnet-ip]. 377 6. Management and Control Information Summary 379 The following summarizes the set of information that is needed to 380 support DetNet IP over DetNet MPLS at the MPLS ingress node: 382 o Each MPLS App-Flow is identified using the IP flow identification 383 information as defined in [I-D.ietf-detnet-ip]. The information 384 is summarized in Section 5.1 of that document, and includes all 385 wildcards, port ranges and the ability to ignore specific IP 386 fields. 388 o The DetNet MPLS service that is to be used to send the matching IP 389 traffic. This matching information is provided in 390 [I-D.ietf-detnet-mpls] Section 5.1, and includes both service and 391 traffic delivery information. 393 The following summarizes the set of information that is needed to 394 support DetNet IP over DetNet MPLS at the MPLS egress node: 396 o S-Label values that are carrying MPLS over IP encapsulated 397 traffic. 399 o For each S-Label, how the received traffic is to be handled. The 400 traffic may be processed according as any other DetNet IP traffic 401 as defined in this document or in [I-D.ietf-detnet-ip], or the 402 traffic may be directly treated as an MPLS App-flow for additional 403 processing according to [I-D.ietf-detnet-mpls]. 405 It is the responsibility of the DetNet controller plane to properly 406 provision both flow identification information and the flow-specific 407 resources needed to provide the traffic treatment to meet each flow's 408 service requirements. This applies for aggregated and individual 409 flows. 411 7. Security Considerations 413 General security considerations for DetNet are described in detail in 414 [I-D.ietf-detnet-security]. DetNet MPLS and DetNet IP security 415 considerations equally apply to this document and are described in 416 [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. 418 Security aspects which are unique to DetNet are those whose aim is to 419 protect the support of specific quality of service aspects of DetNet, 420 which are primarily to deliver data flows with extremely low packet 421 loss rates and bounded end-to-end delivery latency. 423 The primary considerations for the data plane are to maintain 424 integrity of data and delivery of the associated DetNet service 425 traversing the DetNet network. Application flows can be protected 426 through whatever means is provided by the underlying technology. For 427 example, encryption may be used, such as that provided by IPSec 428 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 429 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 431 From a data plane perspective this document does not add or modify 432 any header information. 434 At the management and control level DetNet flows are identified on a 435 per-flow basis, which may provide controller plane attackers with 436 additional information about the data flows (when compared to 437 controller planes that do not include per-flow identification). This 438 is an inherent property of DetNet which has security implications 439 that should be considered when determining if DetNet is a suitable 440 technology for any given use case. 442 To provide uninterrupted availability of the DetNet service, 443 provisions can be made against DOS attacks and delay attacks. To 444 protect against DOS attacks, excess traffic due to malicious or 445 malfunctioning devices can be prevented or mitigated, for example 446 through the use of existing mechanism such as policing and shaping 447 applied at the input of a DetNet domain. To prevent DetNet packets 448 from being delayed by an entity external to a DetNet domain, DetNet 449 technology definition can allow for the mitigation of Man-In-The- 450 Middle attacks, for example through use of authentication and 451 authorization of devices within the DetNet domain. 453 8. IANA Considerations 455 This document makes no IANA requests. 457 9. Acknowledgements 459 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 460 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 461 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 462 Bernardos for their various contributions to this work. 464 10. Contributors 466 RFC7322 limits the number of authors listed on the front page of a 467 draft to a maximum of 5. The editor wishes to thank and acknowledge 468 the follow authors for contributing text to this draft. 470 Janos Farkas 471 Ericsson 472 Email: janos.farkas@ericsson.com 474 Andrew G. Malis 475 Malis Consulting 476 Email: agmalis@gmail.com 478 Janos Farkas contributed substantially to the content of this 479 document. 481 11. References 483 11.1. Normative references 485 [I-D.ietf-detnet-data-plane-framework] 486 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 487 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 488 data-plane-framework-06 (work in progress), May 2020. 490 [I-D.ietf-detnet-ip] 491 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 492 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 493 (work in progress), July 2020. 495 [I-D.ietf-detnet-mpls] 496 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 497 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 498 detnet-mpls-12 (work in progress), September 2020. 500 [I-D.ietf-detnet-security] 501 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 502 Networking (DetNet) Security Considerations", draft-ietf- 503 detnet-security-12 (work in progress), October 2020. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, 507 DOI 10.17487/RFC2119, March 1997, 508 . 510 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 511 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 512 May 2017, . 514 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 515 "Deterministic Networking Architecture", RFC 8655, 516 DOI 10.17487/RFC8655, October 2019, 517 . 519 11.2. Informative references 521 [IEEE802.1AE-2018] 522 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 523 Security (MACsec)", 2018, 524 . 526 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 527 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 528 December 2005, . 530 Authors' Addresses 532 Balazs Varga (editor) 533 Ericsson 534 Magyar Tudosok krt. 11. 535 Budapest 1117 536 Hungary 538 Email: balazs.a.varga@ericsson.com 540 Lou Berger 541 LabN Consulting, L.L.C. 543 Email: lberger@labn.net 545 Don Fedyk 546 LabN Consulting, L.L.C. 548 Email: dfedyk@labn.net 549 Stewart Bryant 550 Futurewei Technologies 552 Email: stewart.bryant@gmail.com 554 Jouni Korhonen 556 Email: jouni.nospam@gmail.com