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