idnits 2.17.1 draft-ietf-detnet-ip-over-mpls-08.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 (September 10, 2020) is 1322 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-11 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-11 ** 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: March 14, 2021 D. Fedyk 6 LabN Consulting, L.L.C. 7 S. Bryant 8 Futurewei Technologies 9 J. Korhonen 10 September 10, 2020 12 DetNet Data Plane: IP over MPLS 13 draft-ietf-detnet-ip-over-mpls-08 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 March 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 . 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 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 5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation 325 Procedures 327 A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a 328 DetNet MPLS network MUST map a DetNet IP flow, as identified in 329 [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process 330 it in accordance to the procedures defined in [I-D.ietf-detnet-mpls]. 331 PRF MAY be supported at the MPLS level for DetNet IP flows sent over 332 an DetNet MPLS network. Aggregation MAY be supported as defined in 333 [I-D.ietf-detnet-mpls] Section 4.4. Aggregation considerations in 334 [I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP 335 flow. The provisioning of the mapping of DetNet IP flows to DetNet 336 MPLS flows MUST be supported via configuration, e.g., via the 337 controller plane. 339 A DetNet relay node (egress T-PE) MAY be provisioned to handle 340 packets received via the DetNet MPLS data plane as DetNet IP flows. 341 A single incoming DetNet MPLS flow MAY be treated as a single DetNet 342 IP flow, without examination of IP headers. Alternatively, packets 343 received via the DetNet MPLS data plane MAY follow the normal DetNet 344 IP flow identification procedures defined in [I-D.ietf-detnet-ip] 345 Section 5.1. 347 An implementation MUST support the provisioning for handling any 348 received DetNet MPLS data plane as DetNet IP flows via configuration. 349 Note that such configuration MAY include support from PREOF on the 350 incoming DetNet MPLS flow. 352 Note: using Layer-4 (L4) transport protocols e.g., for multipath are 353 out of scope of this document both for a single flow and aggregate 354 flows. 356 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures 358 The traffic treatment required for a particular DetNet IP flow is 359 provisioned via configuration or the controller plane. When a DetNet 360 IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure 361 that the provisioned DetNet IP traffic treatment is provided at the 362 forwarding sub-layer as described in [I-D.ietf-detnet-mpls] 363 Section 5.2. Note that the PRF function MAY be utilized when sending 364 IP over MPLS. 366 Traffic treatment for DetNet IP flows received over the DetNet MPLS 367 data plane MUST follow Section 5.3 DetNet IP Traffic Treatment 368 Procedures in [I-D.ietf-detnet-ip]. 370 6. Management and Control Information Summary 372 The following summarizes the set of information that is needed to 373 support DetNet IP over DetNet MPLS at the MPLS ingress node: 375 o Each MPLS App-Flow is identified using the IP flow identification 376 information as defined in [I-D.ietf-detnet-ip]. The information 377 is summarized in Section 5.1 of that document, and includes all 378 wildcards, port ranges and the ability to ignore specific IP 379 fields. 381 o The DetNet MPLS service that is to be used to send the matching IP 382 traffic. This matching information is provided in 383 [I-D.ietf-detnet-mpls] Section 5.1, and includes both service and 384 traffic delivery information. 386 The following summarizes the set of information that is needed to 387 support DetNet IP over DetNet MPLS at the MPLS egress node: 389 o S-Label values that are carrying MPLS over IP encapsulated 390 traffic. 392 o For each S-Label, how the received traffic is to be handled. The 393 traffic may be processed according as any other DetNet IP traffic 394 as defined in this document or in [I-D.ietf-detnet-ip], or the 395 traffic may be directly treated as an MPLS App-flow for additional 396 processing according to [I-D.ietf-detnet-mpls]. 398 It is the responsibility of the DetNet controller plane to properly 399 provision both flow identification information and the flow-specific 400 resources needed to provide the traffic treatment to meet each flow's 401 service requirements. This applies for aggregated and individual 402 flows. 404 7. Security Considerations 406 General security considerations for DetNet are described in detail in 407 [I-D.ietf-detnet-security]. DetNet MPLS and DetNet IP security 408 considerations equally apply to this document and are described in 409 [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. 411 Security aspects which are unique to DetNet are those whose aim is to 412 protect the support of specific quality of service aspects of DetNet, 413 which are primarily to deliver data flows with extremely low packet 414 loss rates and bounded end-to-end delivery latency. 416 The primary considerations for the data plane are to maintain 417 integrity of data and delivery of the associated DetNet service 418 traversing the DetNet network. Application flows can be protected 419 through whatever means is provided by the underlying technology. For 420 example, encryption may be used, such as that provided by IPSec 421 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 422 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 424 From a data plane perspective this document does not add or modify 425 any header information. 427 At the management and control level DetNet flows are identified on a 428 per-flow basis, which may provide controller plane attackers with 429 additional information about the data flows (when compared to 430 controller planes that do not include per-flow identification). This 431 is an inherent property of DetNet which has security implications 432 that should be considered when determining if DetNet is a suitable 433 technology for any given use case. 435 To provide uninterrupted availability of the DetNet service, 436 provisions can be made against DOS attacks and delay attacks. To 437 protect against DOS attacks, excess traffic due to malicious or 438 malfunctioning devices can be prevented or mitigated, for example 439 through the use of existing mechanism such as policing and shaping 440 applied at the input of a DetNet domain. To prevent DetNet packets 441 from being delayed by an entity external to a DetNet domain, DetNet 442 technology definition can allow for the mitigation of Man-In-The- 443 Middle attacks, for example through use of authentication and 444 authorization of devices within the DetNet domain. 446 8. IANA Considerations 448 This document makes no IANA requests. 450 9. Acknowledgements 452 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 453 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 454 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 455 Bernardos for their various contributions to this work. 457 10. Contributors 459 RFC7322 limits the number of authors listed on the front page of a 460 draft to a maximum of 5. The editor wishes to thank and acknowledge 461 the follow authors for contributing text to this draft. 463 Janos Farkas 464 Ericsson 465 Email: janos.farkas@ericsson.com 467 Andrew G. Malis 468 Malis Consulting 469 Email: agmalis@gmail.com 471 Janos Farkas contributed substantially to the content of this 472 document. 474 11. References 476 11.1. Normative references 478 [I-D.ietf-detnet-data-plane-framework] 479 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 480 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 481 data-plane-framework-06 (work in progress), May 2020. 483 [I-D.ietf-detnet-ip] 484 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 485 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 486 (work in progress), July 2020. 488 [I-D.ietf-detnet-mpls] 489 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 490 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 491 detnet-mpls-11 (work in progress), August 2020. 493 [I-D.ietf-detnet-security] 494 Mizrahi, T. and E. Grossman, "Deterministic Networking 495 (DetNet) Security Considerations", draft-ietf-detnet- 496 security-11 (work in progress), August 2020. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 505 May 2017, . 507 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 508 "Deterministic Networking Architecture", RFC 8655, 509 DOI 10.17487/RFC8655, October 2019, 510 . 512 11.2. Informative references 514 [IEEE802.1AE-2018] 515 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 516 Security (MACsec)", 2018, 517 . 519 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 520 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 521 December 2005, . 523 Authors' Addresses 525 Balazs Varga (editor) 526 Ericsson 527 Magyar Tudosok krt. 11. 528 Budapest 1117 529 Hungary 531 Email: balazs.a.varga@ericsson.com 533 Lou Berger 534 LabN Consulting, L.L.C. 536 Email: lberger@labn.net 538 Don Fedyk 539 LabN Consulting, L.L.C. 541 Email: dfedyk@labn.net 543 Stewart Bryant 544 Futurewei Technologies 546 Email: stewart.bryant@gmail.com 547 Jouni Korhonen 549 Email: jouni.nospam@gmail.com