idnits 2.17.1 draft-ietf-detnet-ip-over-mpls-02.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 16, 2019) is 1644 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 175, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-02 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 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 J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: April 18, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 Independent 10 S. Bryant 11 Futurewei Technologies 12 J. Korhonen 13 October 16, 2019 15 DetNet Data Plane: IP over MPLS 16 draft-ietf-detnet-ip-over-mpls-02 18 Abstract 20 This document specifies the Deterministic Networking data plane when 21 operating in an IP over MPLS packet switched network. 23 Status of This Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 18, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 63 4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5 65 4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6 66 5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8 67 5.1. DetNet IP over DetNet MPLS Flow Identification 68 Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 8 70 6. Management and Control Information Summary . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative references . . . . . . . . . . . . . . . . . . 10 76 10.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 [I-D.ietf-detnet-architecture]. 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 [I-D.ietf-detnet-architecture] 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 [I-D.ietf-detnet-architecture] and 104 [I-D.ietf-detnet-data-plane-framework]. This document uses the 105 following abbreviations: 107 CE Customer Edge equipment. 109 DetNet Deterministic Networking. 111 DF DetNet Flow. 113 DN DetNet. 115 L2 Layer-2. 117 L3 Layer-3. 119 LSP Label-switched path. 121 MPLS Multiprotocol Label Switching. 123 PE Provider Edge. 125 PREOF Packet Replication, Ordering and Elimination Function. 127 PSN Packet Switched Network. 129 PW Pseudowire. 131 TE Traffic Engineering. 133 TSN Time-Sensitive Networking, TSN is a Task Group of the 134 IEEE 802.1 Working Group. 136 2.3. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. DetNet IP Data Plane Overview 146 Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network 147 as a sub-network between the relay nodes. It shows a more complex 148 DetNet enabled IP network where an IP flow is mapped to one or more 149 PWs and MPLS (TE) LSPs. The end systems still originate IP 150 encapsulated traffic that are identified as DetNet flows. The relay 151 nodes follow procedures defined in Section 4 to map each DetNet flow 152 to MPLS LSPs. While not shown, relay nodes can provide service sub- 153 layer functions such as PREOF using DetNet over MPLS, and this is 154 indicated by the solid line for the MPLS facing portion of the 155 Service component. Note that the Transit node is MPLS (TE) LSP aware 156 and performs switching based on MPLS labels, and need not have any 157 specific knowledge of the DetNet service or the corresponding DetNet 158 flow identification. See Section 4 for details on the mapping of IP 159 flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of 160 DetNet services using MPLS. 162 DetNet IP Relay Transit Relay DetNet IP 163 End System Node Node Node End System 165 +----------+ +----------+ 166 | Appl. |<------------- End to End Service ---------->| Appl. | 167 +----------+ .....-----+ +-----..... +----------+ 168 | Service |<--: Service |--DetNet flow ---| Service :-->| Service | 169 | | : |<-DN MPLS flow ->| : | | 170 +----------+ +---------+ +----------+ +---------+ +----------+ 171 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 172 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 173 : Link : / ,-----. \ : Link : / ,-----. \ 174 +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ 175 [Network] [Network] 176 `-----' `-----' 178 |<---- DetNet MPLS ---->| 179 |<--------------------- DetNet IP ------------------>| 181 Figure 1: DetNet IP Over DetNet MPLS Network 183 4. IP over DetNet MPLS 185 This section defines how IP encapsulated flows are carried over a 186 DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since 187 both Non-DetNet and DetNet IP packet are identical on the wire, this 188 section is applicable to any node that supports IP over DetNet MPLS, 189 and this section refers to both cases as DetNet IP over DetNet MPLS. 191 4.1. IP Over DetNet MPLS Data Plane Scenarios 193 An example use of DetNet IP over DetNet MPLS is presented here. 195 Figure 1 illustrated DetNet enabled End Systems (hosts), connected to 196 DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS 197 network. iUsing this figure we can have a case where the Relay nodes 198 act as T-PEs and sit at the boundary of the MPLS domain since the 199 non-MPLS domain is DetNet aware. This case is very similar to the 200 DetNet MPLS Network figure 2 in [I-D.ietf-detnet-mpls]. However in 201 [I-D.ietf-detnet-mpls] figure 2 the T-PEs are located at the end 202 syetem and MPLS spans the whole DetNet service. The primary 203 difference in this document is that the Relay nodes are at the edges 204 of the MPLS domain and therefore function as T-PEs, and that iMPLS 205 service sub-layer functions are not provided over the DetNet IP 206 network. The transit node functions show above are identical to 207 those described in [I-D.ietf-detnet-mpls]. 209 Figure 2 illustrates how relay nodes can provide service protection 210 over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end 211 systems which are interconnected via a MPLS domain such as described 212 in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of 213 an MPLS domain and therefore are similar to T-PEs, while R2 sits in 214 the middle of the domain and is therefore similar to an S-PE. 216 DetNet DetNet 217 IP Service Transit Transit Service IP 218 DetNet |<-Tnl->| |<-Tnl->| DetNet 219 End | V 1 V V 2 V | End 220 System | +--------+ +--------+ +--------+ | System 221 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 222 | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| | 223 |CE1| | | \ | | X | | / | | |CE2| 224 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 225 +---+ | |=======| |=======| | +---+ 226 ^ +--------+ +--------+ +--------+ ^ 227 | Relay Node Relay Node Relay Node | 228 | (T-PE) (S-PE) (T-PE) | 229 | | 230 |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| 231 | | 232 |<-------------- End to End DetNet Service --------------->| 234 -------------------------- Data Flow -------------------------> 236 X = Service protection (PRF, PREOF, PEF/POF) 237 DFx = DetNet member flow x over a TE LSP 239 Figure 2: DetNet IP Over DetNet MPLS Network 241 Figure 1 illustrates DetNet enabled End Systems (hosts), connected to 242 DetNet (DN) enabled MPLS network. A similar situation occurs when 243 end systems are are not DetNet aware. In this case, edge nodes sit 244 at the boundary of the MPLS domain since it is also a DetNet domain 245 boundary. The edge nodes provide DetNet service proxies for the end 246 applications by initiating and terminating DetNet service for the 247 application's IP flows. While the node types differ, there is 248 essentially no difference in data plane processing between relay and 249 edges. There are likely to be differences in controller plane 250 operation, particularly when distributed control plane protocols are 251 used. 253 It is still possible to provided DetNet service protection for non- 254 DetNet aware end systems. case is basically the same as Figure 2, 255 with the exception that CE1 and CE2 are non-DetNet aware end systems 256 and R1 and R3 become edge nodes. 258 4.2. DetNet IP over DetNet MPLS Encapsulation 260 The basic encapsulation approach is to treat a DetNet IP flow as an 261 app-flow from the DetNet MPLS perspective. The corresponding example 262 DetNet Sub-Network format is shown in Figure 3. 264 /-> +------+ +------+ +------+ ^ ^ 265 | | X | | X | | X |<- App-Flow : : 266 | +------+ +------+ +------+ : : 267 App-Flow <-+ |NProto| |NProto| |NProto| : :(1) 268 for MPLS | +------+ +------+ +------+ : : 269 | | IP | | IP | | IP | : v 270 \-> +---+======+--+======+--+======+-----+ : 271 DetNet-MPLS | d-CW | | d-CW | | d-CW | : 272 +------+ +------+ +------+ :(2) 273 |Labels| |Labels| |Labels| v 274 +---+======+--+======+--+======+-----+ 275 Link/Sub-Network | L2 | | TSN | | UDP | 276 +------+ +------+ +------+ 277 | IP | 278 +------+ 279 | L2 | 280 +------+ 281 (1) DetNet IP Flow (or simply IP flow) 282 (2) DetNet MPLS Flow 284 Figure 3: Example DetNet IP over MPLS Sub-Network Formats 286 In the figure, "App-Flow" indicates the payload carried by the DetNet 287 IP data plane. "IP" and "NProto" indicate the fields described in 288 Section 7.1.1. IP Header Information and Section 7.1.2. Other 289 Protocol Header Information in [I-D.ietf-detnet-ip], respectively. 290 "MPLS App-Flow" indicates that an individual DetNet IP flow is the 291 payload from the perspective of the DetNet MPLS data plane defined in 292 [I-D.ietf-detnet-mpls]. 294 Per [I-D.ietf-detnet-mpls], the DetNet MPLS data plane uses a single 295 S-Label to support a single app flow. Section 7.1. DetNet IP Flow 296 Identification Procedures in [I-D.ietf-detnet-ip] states that a 297 single DetNet flow is identified based on IP, and next level 298 protocol, header information. Section 7.4. Aggregation 299 Considerations in [I-D.ietf-detnet-ip] defines that aggregation is 300 supported through the use of prefixes, wildcards, lists, and port 301 ranges. Collectively, this results in the fairly straight forward 302 procedures defined in this section. 304 As shown in Figure 2, DetNet relay nodes are responsible for the 305 mapping of a DetNet flow, at the service sub-layer, from the IP to 306 MPLS DetNet data planes and back again. Their related DetNet IP over 307 DetNet MPLS data plane operation is comprised of two sets of 308 procedures: the mapping of flow identifiers; and ensuring proper 309 traffic treatment. 311 Mapping of IP to the MPLS Detnet is similar for IP Detnet flows and 312 IP flows. The six-tuple of IP is mapped to the S-Label in both 313 cases. The various fields may be mapped or ignored when going from 314 IP to MPLS. 316 5. IP over DetNet MPLS Procedures 318 5.1. DetNet IP over DetNet MPLS Flow Identification Procedures 320 A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a 321 DetNet MPLS network MUST map a DetNet IP flow, as identified in 322 [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process 323 it in accordance to the procedures defined in [I-D.ietf-detnet-mpls] 324 Section 6.1. PRF MAY be supported at the MPLS level for DetNet IP 325 flows sent over an DetNet MPLS network. Aggregation MAY be supported 326 as defined in [I-D.ietf-detnet-mpls] Section 5.4. Aggregation 327 considerations in [I-D.ietf-detnet-ip] MAY be used to identify an 328 individual DetNet IP flow. The provisioning of the mapping of DetNet 329 IP flows to DetNet MPLS flows MUST be supported via configuration, 330 e.g., via the controller plane. 332 A DetNet relay node (egress T-PE) MAY be provisioned to handle 333 packets received via the DetNet MPLS data plane as DetNet IP flows. 334 A single incoming DetNet MPLS flow MAY be treated as a single DetNet 335 IP flow, without examination of IP headers. Alternatively, packets 336 received via the DetNet MPLS data plane MAY follow the normal DetNet 337 IP flow identification procedures defined in [I-D.ietf-detnet-ip] 338 Section 7.1. 340 An implementation MUST support the provisioning for handling any 341 received DetNet MPLS data plane as DetNet IP flows via configuration. 342 Note that such configuration MAY include support from PEOF on the 343 incoming DetNet MPLS flow. 345 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures 347 The traffic treatment required for a particular DetNet IP flow is 348 provisioned via configuration or the controller plane. When an 349 DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST 350 ensure that the provisioned DetNet IP traffic treatment is provided 351 at the forwarding sub-layer as described in [I-D.ietf-detnet-mpls] 352 Section 5.2. Note that the PRF function MAY be utilized when sending 353 IP over MPLS. 355 Traffic treatment for DetNet IP flows received over the DetNet MPLS 356 data plane MUST follow Section 7.3 DetNet IP Traffic Treatment 357 Procedures in [I-D.ietf-detnet-ip]. 359 6. Management and Control Information Summary 361 The following summarizes the set of information that is needed to 362 support DetNet IP over DetNet MPLS at the MPLS ingress node: 364 o Each MPLS App-Flow is identified using the IP flow identification 365 information as defined in [I-D.ietf-detnet-ip]. The information 366 is summarized in Section 6 of that document, and includes all 367 wildcards, port ranges and ability to ignore specific IP fields. 369 o The DetNet MPLS service that is to be used to send the matching IP 370 traffic. Logically this is a pointer to the information provided 371 in [I-D.ietf-detnet-mpls] Section 5.1, and includes both service 372 and traffic delivery information. 374 The following summarizes the set of information that is needed to 375 support DetNet IP over DetNet MPLS at the MPLS egress node: 377 o S-Label values that are carrying MPLS over IP encapsulated 378 traffic. 380 o For each S-Label, how the received traffic is to be handled. The 381 traffic may be processed according as any other DetNet IP traffic 382 as defined in this document or in [I-D.ietf-detnet-ip], or the 383 traffic may be directly treated as an MPLS App-flow for additional 384 processing according to [I-D.ietf-detnet-mpls]. 386 It is the responsibility of the DetNet controller plane to properly 387 provision both flow identification information and the flow specific 388 resources needed to provided the traffic treatment needed to meet 389 each flow's service requirements. This applies for aggregated and 390 individual flows. 392 7. Security Considerations 394 This draft does not have additional security considerations. 395 Security considerations for DetNet are described in detail in 396 [I-D.ietf-detnet-security]. General security considerations are 397 described in [I-D.ietf-detnet-architecture]. MPLS and IP specific 398 considerations are described in [I-D.ietf-detnet-mpls] and 399 [I-D.ietf-detnet-ip]. 401 Security aspects which are unique to DetNet are those whose aim is to 402 provide the specific quality of service aspects of DetNet, which are 403 primarily to deliver data flows with extremely low packet loss rates 404 and bounded end-to-end delivery latency. 406 The primary considerations for the data plane is to maintain 407 integrity of data and delivery of the associated DetNet service 408 traversing the DetNet network. Application flows can be protected 409 through whatever means is provided by the underlying technology. For 410 example, encryption may be used, such as that provided by IPSec 411 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 412 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 414 From a data plane perspective this document does not add or modify 415 any header information. 417 At the management and control level DetNet flows are identified on a 418 per-flow basis, which may provide controller plane attackers with 419 additional information about the data flows (when compared to 420 controller planes that do not include per-flow identification). This 421 is an inherent property of DetNet which has security implications 422 that should be considered when determining if DetNet is a suitable 423 technology for any given use case. 425 To provide uninterrupted availability of the DetNet service, 426 provisions can be made against DOS attacks and delay attacks. To 427 protect against DOS attacks, excess traffic due to malicious or 428 malfunctioning devices can be prevented or mitigated, for example 429 through the use of existing mechanism such as policing and shaping 430 applied at the input of a DetNet domain. To prevent DetNet packets 431 from being delayed by an entity external to a DetNet domain, DetNet 432 technology definition can allow for the mitigation of Man-In-The- 433 Middle attacks, for example through use of authentication and 434 authorization of devices within the DetNet domain. 436 8. IANA Considerations 438 This document makes no IANA requests. 440 9. Acknowledgements 442 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 443 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 444 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 445 Bernardos for their various contributions to this work. 447 10. References 449 10.1. Normative references 451 [I-D.ietf-detnet-architecture] 452 Finn, N., Thubert, P., Varga, B., and J. Farkas, 453 "Deterministic Networking Architecture", draft-ietf- 454 detnet-architecture-13 (work in progress), May 2019. 456 [I-D.ietf-detnet-ip] 457 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 458 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 459 draft-ietf-detnet-ip-01 (work in progress), July 2019. 461 [I-D.ietf-detnet-mpls] 462 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 463 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 464 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 10.2. Informative references 477 [I-D.ietf-detnet-data-plane-framework] 478 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 479 Bryant, S., and J. Korhonen, "DetNet Data Plane 480 Framework", draft-ietf-detnet-data-plane-framework-02 481 (work in progress), September 2019. 483 [I-D.ietf-detnet-security] 484 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 485 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 486 Networking (DetNet) Security Considerations", draft-ietf- 487 detnet-security-05 (work in progress), August 2019. 489 [IEEE802.1AE-2018] 490 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 491 Security (MACsec)", 2018, 492 . 494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 495 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 496 December 2005, . 498 Authors' Addresses 500 Balazs Varga (editor) 501 Ericsson 502 Magyar Tudosok krt. 11. 503 Budapest 1117 504 Hungary 506 Email: balazs.a.varga@ericsson.com 508 Janos Farkas 509 Ericsson 510 Magyar Tudosok krt. 11. 511 Budapest 1117 512 Hungary 514 Email: janos.farkas@ericsson.com 516 Lou Berger 517 LabN Consulting, L.L.C. 519 Email: lberger@labn.net 521 Don Fedyk 522 LabN Consulting, L.L.C. 524 Email: dfedyk@labn.net 526 Andrew G. Malis 527 Independent 529 Email: agmalis@gmail.com 531 Stewart Bryant 532 Futurewei Technologies 534 Email: stewart.bryant@gmail.com 536 Jouni Korhonen 538 Email: jouni.nospam@gmail.com