idnits 2.17.1 draft-ietf-detnet-ip-over-mpls-06.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 (May 6, 2020) is 1450 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 186, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-05 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-05 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-04 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-09 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: November 7, 2020 D. Fedyk 6 LabN Consulting, L.L.C. 7 S. Bryant 8 Futurewei Technologies 9 J. Korhonen 10 May 6, 2020 12 DetNet Data Plane: IP over MPLS 13 draft-ietf-detnet-ip-over-mpls-06 15 Abstract 17 This document specifies the Deterministic Networking data plane when 18 operating in an IP over 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 November 7, 2020. 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 . . . . . . . . 7 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 . 8 67 6. Management and Control Information Summary . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 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 these flows extremely low 81 packet loss rates and assured maximum end-to-end delivery latency. 82 General background and concepts of DetNet can be found in the DetNet 83 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], 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 d-CW DetNet Control Word. 110 DetNet Deterministic Networking. 112 DF DetNet Flow. 114 DN DetNet. 116 L2 Layer-2. 118 L3 Layer-3. 120 LSP Label-switched path. 122 MPLS Multiprotocol Label Switching. 124 PE Provider Edge. 126 PEF Packet Elimination Function. 128 PRF Packet Replication Function. 130 PREOF Packet Replication, Elimination and Ordering Functions. 132 POF Packet Ordering Function. 134 PSN Packet Switched Network. 136 PW Pseudowire. 138 S-Label DetNet "service" label. 140 T-PE Terminating Provider Edge. 142 TE Traffic Engineering. 144 TSN Time-Sensitive Networking, TSN is a Task Group of the 145 IEEE 802.1 Working Group. 147 2.3. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. DetNet IP Data Plane Overview 157 Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network 158 as a sub-network between the relay nodes. It shows a more complex 159 DetNet enabled IP network where an IP flow is mapped to one or more 160 PWs and MPLS (TE) LSPs. The end systems still originate IP 161 encapsulated traffic that are identified as DetNet flows. The relay 162 nodes follow procedures defined in Section 4 to map each DetNet flow 163 to MPLS LSPs. While not shown, relay nodes can provide service sub- 164 layer functions such as PREOF using DetNet over MPLS, and this is 165 indicated by the solid line for the MPLS facing portion of the 166 Service component. Note that the Transit node is MPLS (TE) LSP aware 167 and performs switching based on MPLS labels, and need not have any 168 specific knowledge of the DetNet service or the corresponding DetNet 169 flow identification. See Section 4 for details on the mapping of IP 170 flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of 171 DetNet services using MPLS. 173 DetNet IP Relay Transit Relay DetNet IP 174 End System Node Node Node End System 176 +----------+ +----------+ 177 | Appl. |<------------- End to End Service ---------->| Appl. | 178 +----------+ .....-----+ +-----..... +----------+ 179 | Service |<--: Service |--DetNet flow ---| Service :-->| Service | 180 | | : |<-DN MPLS flow ->| : | | 181 +----------+ +---------+ +----------+ +---------+ +----------+ 182 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 183 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 184 : Link : / ,-----. \ : Link : / ,-----. \ 185 +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ 186 [Network] [Network] 187 `-----' `-----' 189 |<---- DetNet MPLS ---->| 190 |<--------------------- DetNet IP ------------------>| 192 Figure 1: Architecture: DetNet IP Over DetNet MPLS Network 194 4. IP over DetNet MPLS 196 This section defines how IP encapsulated flows are carried over a 197 DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since 198 both Non-DetNet and DetNet IP packet are identical on the wire, this 199 section is applicable to any node that supports IP over DetNet MPLS, 200 and this section refers to both cases as DetNet IP over DetNet MPLS. 202 4.1. IP Over DetNet MPLS Data Plane Scenarios 204 An example use of DetNet IP over DetNet MPLS is presented here. 206 Figure 1 illustrated DetNet enabled End Systems (hosts), connected to 207 DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS 208 network. Using this figure we can have a case where the Relay nodes 209 act as T-PEs and sit at the boundary of the MPLS domain since the 210 non-MPLS domain is DetNet aware. This case is very similar to the 211 DetNet MPLS Network figure 2 in [I-D.ietf-detnet-mpls]. However in 212 [I-D.ietf-detnet-mpls] figure 2 the T-PEs are located at the end 213 system and MPLS spans the whole DetNet service. The primary 214 difference in this document is that the Relay nodes are at the edges 215 of the MPLS domain and therefore function as T-PEs, and that MPLS 216 service sub-layer functions are not provided over the DetNet IP 217 network. The transit node functions show above are identical to 218 those described in [I-D.ietf-detnet-mpls]. 220 Figure 2 illustrates how relay nodes can provide service protection 221 over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end 222 systems which are interconnected via a MPLS domain such as described 223 in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of 224 an MPLS domain and therefore are similar to T-PEs, while R2 sits in 225 the middle of the domain and is therefore similar to an S-PE. 227 DetNet DetNet 228 IP Service Transit Transit Service IP 229 DetNet |<-Tnl->| |<-Tnl->| DetNet 230 End | V 1 V V 2 V | End 231 System | +--------+ +--------+ +--------+ | System 232 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 233 | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| | 234 |CE1| | | \ | | X | | / | | |CE2| 235 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 236 +---+ | |=======| |=======| | +---+ 237 ^ +--------+ +--------+ +--------+ ^ 238 | Relay Node Relay Node Relay Node | 239 | (T-PE) (S-PE) (T-PE) | 240 | | 241 |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| 242 | | 243 |<-------------- End to End DetNet Service --------------->| 245 -------------------------- Data Flow -------------------------> 247 X = Service protection (PRF, PREOF, PEF/POF) 248 DFx = DetNet member flow x over a TE LSP 250 Figure 2: Service Protection Over DetNet MPLS Network for DetNet IP 252 Figure 1 illustrates DetNet enabled End Systems, connected to DetNet 253 (DN) enabled MPLS network. A similar situation occurs when end 254 systems are are not DetNet aware. In this case, edge nodes sit at 255 the boundary of the MPLS domain since it is also a DetNet domain 256 boundary. The edge nodes provide DetNet service proxies for the end 257 applications by initiating and terminating DetNet service for the 258 application's IP flows. While the node types differ, there is 259 essentially no difference in data plane processing between relay and 260 edges. There are likely to be differences in controller plane 261 operation, particularly when distributed control plane protocols are 262 used. 264 It is still possible to provided DetNet service protection for non- 265 DetNet aware end systems. This case is basically the same as 266 Figure 2, with the exception that CE1 and CE2 are non-DetNet aware 267 end systems and R1 and R3 become edge nodes. 269 4.2. DetNet IP over DetNet MPLS Encapsulation 271 The basic encapsulation approach is to treat a DetNet IP flow as an 272 app-flow from the DetNet MPLS perspective. The corresponding example 273 DetNet Sub-Network format is shown in Figure 3. 275 /-> +------+ +------+ +------+ ^ ^ 276 | | X | | X | | X |<- App-Flow : : 277 | +------+ +------+ +------+ : : 278 App-Flow <-+ |NProto| |NProto| |NProto| : :(1) 279 for MPLS | +------+ +------+ +------+ : : 280 | | IP | | IP | | IP | : v 281 \-> +---+======+--+======+--+======+-----+ : 282 DetNet-MPLS | d-CW | | d-CW | | d-CW | : 283 +------+ +------+ +------+ :(2) 284 |Labels| |Labels| |Labels| v 285 +---+======+--+======+--+======+-----+ 286 Link/Sub-Network | L2 | | TSN | | UDP | 287 +------+ +------+ +------+ 288 | IP | 289 +------+ 290 | L2 | 291 +------+ 292 (1) DetNet IP Flow (or simply IP flow) 293 (2) DetNet MPLS Flow 295 Figure 3: Example DetNet IP over MPLS Sub-Network Formats 297 In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP 298 data plane. "IP" and "NProto" indicate the fields described in 299 Section 5.1.1. (IP Header Information) and Section 5.1.2. (Other 300 Protocol Header Information) of [I-D.ietf-detnet-ip], respectively. 301 "App-Flow for MPLS" indicates that an individual DetNet IP flow is 302 the payload from the perspective of the DetNet MPLS data plane 303 defined in [I-D.ietf-detnet-mpls]. 305 Per Section 5.1 of [I-D.ietf-detnet-mpls], the DetNet MPLS data plane 306 uses a single S-Label to support a single app flow. DetNet IP Flow 307 Identification Procedures in Section 4.4 of [I-D.ietf-detnet-ip] 308 states that a single DetNet flow is identified based on IP, and next 309 level protocol, header information. Section 4.4. (Aggregation 310 Considerations) of [I-D.ietf-detnet-ip] defines the ways in which 311 aggregation is supported through the use of prefixes, wildcards, 312 lists, and port ranges. Collectively, this results in the fairly 313 straightforward procedures defined in this section. 315 As shown in Figure 2, DetNet relay nodes are responsible for the 316 mapping of a DetNet flow, at the service sub-layer, from the IP to 317 MPLS DetNet data planes and back again. Their related DetNet IP over 318 DetNet MPLS data plane operation is comprised of two sets of 319 procedures: the mapping of flow identifiers, and ensuring proper 320 traffic treatment. 322 Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP 323 flows. The six-tuple of IP is mapped to the S-Label in both cases. 324 The various fields may be mapped or ignored when going from IP to 325 MPLS. 327 5. IP over DetNet MPLS Procedures 329 5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation 330 Procedures 332 A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a 333 DetNet MPLS network MUST map a DetNet IP flow, as identified in 334 [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process 335 it in accordance to the procedures defined in [I-D.ietf-detnet-mpls]. 336 PRF MAY be supported at the MPLS level for DetNet IP flows sent over 337 an DetNet MPLS network. Aggregation MAY be supported as defined in 338 [I-D.ietf-detnet-mpls] Section 4.4. Aggregation considerations in 339 [I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP 340 flow. The provisioning of the mapping of DetNet IP flows to DetNet 341 MPLS flows MUST be supported via configuration, e.g., via the 342 controller plane. 344 A DetNet relay node (egress T-PE) MAY be provisioned to handle 345 packets received via the DetNet MPLS data plane as DetNet IP flows. 346 A single incoming DetNet MPLS flow MAY be treated as a single DetNet 347 IP flow, without examination of IP headers. Alternatively, packets 348 received via the DetNet MPLS data plane MAY follow the normal DetNet 349 IP flow identification procedures defined in [I-D.ietf-detnet-ip] 350 Section 5.1. 352 An implementation MUST support the provisioning for handling any 353 received DetNet MPLS data plane as DetNet IP flows via configuration. 354 Note that such configuration MAY include support from PREOF on the 355 incoming DetNet MPLS flow. 357 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures 359 The traffic treatment required for a particular DetNet IP flow is 360 provisioned via configuration or the controller plane. When a DetNet 361 IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure 362 that the provisioned DetNet IP traffic treatment is provided at the 363 forwarding sub-layer as described in [I-D.ietf-detnet-mpls] 364 Section 5.2. Note that the PRF function MAY be utilized when sending 365 IP over MPLS. 367 Traffic treatment for DetNet IP flows received over the DetNet MPLS 368 data plane MUST follow Section 5.3 DetNet IP Traffic Treatment 369 Procedures in [I-D.ietf-detnet-ip]. 371 6. Management and Control Information Summary 373 The following summarizes the set of information that is needed to 374 support DetNet IP over DetNet MPLS at the MPLS ingress node: 376 o Each MPLS App-Flow is identified using the IP flow identification 377 information as defined in [I-D.ietf-detnet-ip]. The information 378 is summarized in Section 5.1 of that document, and includes all 379 wildcards, port ranges and the ability to ignore specific IP 380 fields. 382 o The DetNet MPLS service that is to be used to send the matching IP 383 traffic. This matching information is provided in 384 [I-D.ietf-detnet-mpls] Section 5.1, and includes both service and 385 traffic delivery information. 387 The following summarizes the set of information that is needed to 388 support DetNet IP over DetNet MPLS at the MPLS egress node: 390 o S-Label values that are carrying MPLS over IP encapsulated 391 traffic. 393 o For each S-Label, how the received traffic is to be handled. The 394 traffic may be processed according as any other DetNet IP traffic 395 as defined in this document or in [I-D.ietf-detnet-ip], or the 396 traffic may be directly treated as an MPLS App-flow for additional 397 processing according to [I-D.ietf-detnet-mpls]. 399 It is the responsibility of the DetNet controller plane to properly 400 provision both flow identification information and the flow specific 401 resources needed to provided the traffic treatment needed to meet 402 each flow's service requirements. This applies for aggregated and 403 individual flows. 405 7. Security Considerations 407 Generals security considerations for DetNet are described in detail 408 in [I-D.ietf-detnet-security]. DetNet MPLS and DetNet IP security 409 considerations equally apply to this document and are described in 410 [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. 412 Security aspects which are unique to DetNet are those whose aim is to 413 provide the specific quality of service aspects of DetNet, which are 414 primarily to deliver data flows with extremely low packet loss rates 415 and bounded end-to-end delivery latency. 417 The primary considerations for the data plane is to maintain 418 integrity of data and delivery of the associated DetNet service 419 traversing the DetNet network. Application flows can be protected 420 through whatever means is provided by the underlying technology. For 421 example, encryption may be used, such as that provided by IPSec 422 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 423 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 425 From a data plane perspective this document does not add or modify 426 any header information. 428 At the management and control level DetNet flows are identified on a 429 per-flow basis, which may provide controller plane attackers with 430 additional information about the data flows (when compared to 431 controller planes that do not include per-flow identification). This 432 is an inherent property of DetNet which has security implications 433 that should be considered when determining if DetNet is a suitable 434 technology for any given use case. 436 To provide uninterrupted availability of the DetNet service, 437 provisions can be made against DOS attacks and delay attacks. To 438 protect against DOS attacks, excess traffic due to malicious or 439 malfunctioning devices can be prevented or mitigated, for example 440 through the use of existing mechanism such as policing and shaping 441 applied at the input of a DetNet domain. To prevent DetNet packets 442 from being delayed by an entity external to a DetNet domain, DetNet 443 technology definition can allow for the mitigation of Man-In-The- 444 Middle attacks, for example through use of authentication and 445 authorization of devices within the DetNet domain. 447 8. IANA Considerations 449 This document makes no IANA requests. 451 9. Acknowledgements 453 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 454 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 455 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 456 Bernardos for their various contributions to this work. 458 10. Contributors 460 RFC7322 limits the number of authors listed on the front page of a 461 draft to a maximum of 5. The editor wishes to thank and acknowledge 462 the follow authors for contributing text to this draft. 464 Janos Farkas 465 Ericsson 466 Email: janos.farkas@ericsson.com 468 Andrew G. Malis 469 Malis Consulting 470 Email: agmalis@gmail.com 472 Janos Farkas contributed substantially to the content of this 473 document. 475 11. References 477 11.1. Normative references 479 [I-D.ietf-detnet-ip] 480 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 481 and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- 482 ip-05 (work in progress), February 2020. 484 [I-D.ietf-detnet-mpls] 485 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 486 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 487 draft-ietf-detnet-mpls-05 (work in progress), February 488 2020. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, 492 DOI 10.17487/RFC2119, March 1997, 493 . 495 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 496 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 497 May 2017, . 499 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 500 "Deterministic Networking Architecture", RFC 8655, 501 DOI 10.17487/RFC8655, October 2019, 502 . 504 11.2. Informative references 506 [I-D.ietf-detnet-data-plane-framework] 507 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 508 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 509 data-plane-framework-04 (work in progress), February 2020. 511 [I-D.ietf-detnet-security] 512 Mizrahi, T. and E. Grossman, "Deterministic Networking 513 (DetNet) Security Considerations", draft-ietf-detnet- 514 security-09 (work in progress), March 2020. 516 [IEEE802.1AE-2018] 517 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 518 Security (MACsec)", 2018, 519 . 521 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 522 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 523 December 2005, . 525 Authors' Addresses 527 Balazs Varga (editor) 528 Ericsson 529 Magyar Tudosok krt. 11. 530 Budapest 1117 531 Hungary 533 Email: balazs.a.varga@ericsson.com 535 Lou Berger 536 LabN Consulting, L.L.C. 538 Email: lberger@labn.net 540 Don Fedyk 541 LabN Consulting, L.L.C. 543 Email: dfedyk@labn.net 545 Stewart Bryant 546 Futurewei Technologies 548 Email: stewart.bryant@gmail.com 549 Jouni Korhonen 551 Email: jouni.nospam@gmail.com