idnits 2.17.00 (12 Aug 2021) /tmp/idnits65089/draft-ietf-detnet-mpls-over-tsn-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 (March 6, 2020) is 806 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 == Outdated reference: draft-ietf-detnet-mpls has been published as RFC 8964 == Outdated reference: draft-ietf-detnet-ip has been published as RFC 8939 == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 7, 2020 A. Malis 6 Independent 7 S. Bryant 8 Futurewei Technologies 9 March 6, 2020 11 DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-mpls-over-tsn-02 14 Abstract 16 This document specifies the Deterministic Networking MPLS data plane 17 when operating over a TSN sub-network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 7, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 56 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 4 59 4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks . . . 5 60 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 7 61 4.2. TSN requirements of MPLS DetNet nodes . . . . . . . . . . 7 62 4.3. Service protection within the TSN sub-network . . . . . . 9 63 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 9 64 5. Management and Control Implications . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Deterministic Networking (DetNet) is a service that can be offered by 76 a network to DetNet flows. DetNet provides these flows with a low 77 packet loss rates and assured maximum end-to-end delivery latency. 78 General background and concepts of DetNet can be found in [RFC8655]. 80 The DetNet Architecture decomposes the DetNet related data plane 81 functions into two sub-layers: a service sub-layer and a forwarding 82 sub-layer. The service sub-layer is used to provide DetNet service 83 protection and reordering. The forwarding sub-layer is used to 84 provides congestion protection (low loss, assured latency, and 85 limited reordering) leveraging MPLS Traffic Engineering mechanisms. 87 [I-D.ietf-detnet-mpls] specifies the DetNet data plane operation for 88 MPLS-based Packet Switched Network (PSN). MPLS encapsulated DetNet 89 flows can be carried over network technologies that can provide the 90 DetNet required level of service. This document focuses on the 91 scenario where MPLS (DetNet) nodes are interconnected by a IEEE 802.1 92 TSN sub-network. 94 2. Terminology 96 2.1. Terms Used in This Document 98 This document uses the terminology established in the DetNet 99 architecture [RFC8655] and [I-D.ietf-detnet-mpls], and the reader is 100 assumed to be familiar with that document and its terminology. 102 2.2. Abbreviations 104 The following abbreviations are used in this document: 106 CW Control Word. 108 DetNet Deterministic Networking. 110 DF DetNet Flow. 112 FRER Frame Replication and Elimination for Redundancy (TSN 113 function). 115 L2 Layer 2. 117 L3 Layer 3. 119 LSR Label Switching Router. 121 MPLS Multiprotocol Label Switching. 123 PE Provider Edge. 125 PREOF Packet Replication, Elimination and Ordering Functions. 127 PSN Packet Switched Network. 129 PW PseudoWire. 131 S-PE Switching Provider Edge. 133 T-PE Terminating Provider Edge. 135 TSN Time-Sensitive Network. 137 2.3. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. DetNet MPLS Data Plane Overview 147 The basic approach defined in [I-D.ietf-detnet-mpls] supports the 148 DetNet service sub-layer based on existing pseudowire (PW) 149 encapsulations and mechanisms, and supports the DetNet forwarding 150 sub-layer based on existing MPLS Traffic Engineering encapsulations 151 and mechanisms. 153 A node operating on a DetNet flow in the Detnet service sub-layer, 154 i.e. a node processing a DetNet packet which has the S-Label as top 155 of stack uses the local context associated with that S-Label, for 156 example a received F-Label, to determine what local DetNet 157 operation(s) are applied to that packet. An S-Label may be unique 158 when taken from the platform label space [RFC3031], which would 159 enable correct DetNet flow identification regardless of which input 160 interface or LSP the packet arrives on. The service sub-layer 161 functions (i.e., PREOF) use a DetNet control word (d-CW). 163 The DetNet MPLS data plane builds on MPLS Traffic Engineering 164 encapsulations and mechanisms to provide a forwarding sub-layer that 165 is responsible for providing resource allocation and explicit routes. 166 The forwarding sub-layer is supported by one or more forwarding 167 labels (F-Labels). 169 Edge Transit Relay 170 Node Node Node 171 (T-PE) (LSR) (S-PE) 172 +---------+ 173 <--|Svc Proxy|-- End to End Service -----------> 174 +---------+ +---------+ 175 |IP | |Svc|<-- DetNet flow ---| Service |---> 176 +---+ +---+ +---------+ +---------+ 177 |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| 178 +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ 179 : / ,-----. \ : Link : : 180 .....+ +-[TSN Sub]-+ +........+ +..... 181 [Network] 182 `-----' 183 |<----------- LSP ---------->| |<--- LSP -->| 184 |<------------- DetNet MPLS ------------ 186 Figure 1: Part of a Simple DetNet MPLS Network using a TSN sub-net 188 Figure 1 illustrates an extract of a DetNet enabled MPLS network. 189 Edge/relay nodes sit at MPLS LSP boundaries and transit nodes are 190 LSRs. In this figure, two MPLS nodes (the edge node and the transit 191 node) are interconnected by a TSN sub-network. 193 DetNet edge/relay nodes are DetNet service sub-layer aware, 194 understand the particular needs of DetNet flows and provide both 195 DetNet service and forwarding sub-layer functions. They add, remove 196 and process d-CWs, S-Labels and F-labels as needed. MPLS enabled 197 DetNet nodes can enhance the reliability of delivery by enabling the 198 replication of packets where multiple copies, possibly over multiple 199 paths, are forwarded through the DetNet domain. They can also 200 eliminate surplus previously replicated copies of DetNet packets. 201 MPLS (DetNet) nodes also include DetNet forwarding sub-layer 202 functions, support for notably explicit routes, and resources 203 allocation to eliminate (or reduce) congestion loss and jitter. 205 DetNet transit nodes reside wholly within a DetNet domain, and also 206 provide DetNet forwarding sub-layer functions in accordance with the 207 performance required by a DetNet flow carried over an LSP. Unlike 208 other DetNet node types, transit nodes provide no service sub-layer 209 processing. 211 4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks 213 The DetNet WG collaborates with IEEE 802.1 TSN in order to define a 214 common architecture for both Layer 2 and Layer 3, what maintains 215 consistency across diverse networks. Both DetNet MPLS and TSN use 216 the same techniques to provide their deterministic service: 218 o Service protection. 220 o Resource allocation. 222 o Explicit routes. 224 As described in the DetNet architecture [RFC8655] and also 225 illustrated here in Figure 1 a sub-network provides from MPLS 226 perspective a single hop connection between MPLS (DetNet) nodes. 227 Functions used for resource allocation and explicit routes are 228 treated as domain internal functions and does not require function 229 interworking across the DetNet MPLS network and the TSN sub-network. 231 In case of the service protection function due to the similarities of 232 the DetNet PREOF and TSN FRER functions some level of interworking is 233 possible. However, such interworking is out-of-scope in this 234 document and left for further study. 236 Figure 2 illustrates a scenario, where two MPLS (DetNet) nodes are 237 interconnected by a TSN sub-network. Node-1 is single homed and 238 Node-2 is dual-homed to the TSN sub-network. 240 MPLS (DetNet) MPLS (DetNet) 241 Node-1 Node-2 243 +----------+ +----------+ 244 <--| Service* |-- DetNet flow ---| Service* |--> 245 +----------+ +----------+ 246 |Forwarding| |Forwarding| 247 +--------.-+ <-TSN Str-> +-.-----.--+ 248 \ ,-------. / / 249 +----[ TSN-Sub ]---+ / 250 [ Network ]--------+ 251 `-------' 252 <---------------- DetNet MPLS ---------------> 254 Note: * no service sub-layer required for transit nodes 256 Figure 2: DetNet Enabled MPLS Network Over a TSN Sub-Network 258 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 259 Working Group have defined (and are defining) a number of amendments 260 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 261 bounded latency in bridged networks. Furthermore IEEE 802.1CB 262 [IEEE8021CB] defines frame replication and elimination functions for 263 reliability that should prove both compatible with and useful to, 264 DetNet networks. All these functions have to identify flows those 265 require TSN treatment. 267 TSN capabilities of the TSN sub-network are made available for MPLS 268 (DetNet) flows via the protocol interworking function defined in IEEE 269 802.1CB [IEEE8021CB]. For example, applied on the TSN edge port it 270 can convert an ingress unicast MPLS (DetNet) flow to use a specific 271 Layer-2 multicast destination MAC address and a VLAN, in order to 272 direct the packet through a specific path inside the bridged network. 273 A similar interworking function pair at the other end of the TSN sub- 274 network would restore the packet to its original Layer-2 destination 275 MAC address and VLAN. 277 Placement of TSN functions depends on the TSN capabilities of nodes. 278 MPLS (DetNet) Nodes may or may not support TSN functions. For a 279 given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated 280 as a Talker or a Listener inside the TSN sub-network. 282 4.1. Functions for DetNet Flow to TSN Stream Mapping 284 Mapping of a DetNet MPLS flow to a TSN Stream is provided via the 285 combination of a passive and an active stream identification function 286 that operate at the frame level. The passive stream identification 287 function is used to catch the MPLS label(s) of a DetNet MPLS flow and 288 the active stream identification function is used to modify the 289 Ethernet header according to the ID of the mapped TSN Stream. 291 IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-and-Match Stream 292 identification function that can be used as a passive function for 293 MPLS DetNet flows. 295 IEEE 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN 296 Stream identification function, what can replace some Ethernet header 297 fields namely (1) the destination MAC-address, (2) the VLAN-ID and 298 (3) priority parameters with alternate values. Replacement is 299 provided for the frame passed down the stack from the upper layers or 300 up the stack from the lower layers. 302 Active Destination MAC and VLAN Stream identification can be used 303 within a Talker to set flow identity or a Listener to recover the 304 original addressing information. It can be used also in a TSN bridge 305 that is providing translation as a proxy service for an End System. 307 4.2. TSN requirements of MPLS DetNet nodes 309 This section covers required behavior of a TSN-aware MPLS (DetNet) 310 node using a TSN sub-network. 312 From the TSN sub-network perspective MPLS (DetNet) nodes are treated 313 as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 315 In cases of TSN-unaware MPLS DetNet nodes the TSN relay nodes within 316 the TSN sub-network must modify the Ethernet encapsulation of the 317 DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, Sequence 318 number addition, etc.) to allow proper TSN specific handling inside 319 the sub-network. There are no requirements defined for TSN-unaware 320 MPLS DetNet nodes in this document. 322 MPLS (DetNet) nodes being TSN-aware can be treated as a combination 323 of a TSN-unaware Talker/Listener and a TSN-Relay, as shown in 324 Figure 3. In such cases the MPLS (DetNet) node must provide the TSN 325 sub-network specific Ethernet encapsulation over the link(s) towards 326 the sub-network. 328 MPLS (DetNet) 329 Node 330 <----------------------------------> 332 +----------+ 333 <--| Service* |-- DetNet flow ------------------ 334 +----------+ 335 |Forwarding| 336 +----------+ +---------------+ 337 | L2 | | L2 Relay with |<--- TSN --- 338 | | | TSN function | Stream 339 +-----.----+ +--.------.---.-+ 340 \__________/ \ \______ 341 \_________ 342 TSN-unaware 343 Talker / TSN-Bridge 344 Listener Relay 345 <----- TSN Sub-network ----- 346 <------- TSN-aware Tlk/Lstn -------> 348 Note: * no service sub-layer required for transit nodes 350 Figure 3: MPLS (DetNet) Node with TSN Functions 352 A TSN-aware MPLS (DetNet) node impementations MUST support the Stream 353 Identification TSN component for recognizing flows. 355 A Stream identification component MUST be able to instantiate the 356 following functions (1) Active Destination MAC and VLAN Stream 357 identification function, (2) Mask-and-Match Stream identification 358 function and (3) the related managed objects in Clause 9 of IEEE 359 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]. 361 A TSN-aware MPLS (DetNet) node implementations MUST support the 362 Sequencing function and the Sequence encode/decode function as 363 defined in IEEE 802.1CB [IEEE8021CB] if FRER is used inside the TSN 364 sub-network. 366 The Sequence encode/decode function MUST support the Redundancy tag 367 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 369 A TSN-aware MPLS (DetNet) node implementations MUST support the 370 Stream splitting function and the Individual recovery function as 371 defined in IEEE 802.1CB [IEEE8021CB] when the node is a replication 372 or elimination point for FRER. 374 4.3. Service protection within the TSN sub-network 376 TSN Streams supporting DetNet flows may use Frame Replication and 377 Elimination for Redundancy (FRER) as defined in IEEE 802.1CB 378 [IEEE8021CB] based on the loss service requirements of the TSN 379 Stream, which is derived from the DetNet service requirements of the 380 DetNet mapped flow. The specific operation of FRER is not modified 381 by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 383 FRER function and the provided service recovery is available only 384 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 385 number are not valid outside the sub-network. An MPLS (DetNet) node 386 represents a L3 border and as such it terminates all related 387 information elements encoded in the L2 frames. 389 As the Stream-ID and the TSN sequence number are paired with the 390 similar MPLS flow parameters, FRER can be combined with PREOF 391 functions. Such service protection interworking scenarios may 392 require to move sequence number fields among TSN (L2) and PW (MPLS) 393 encapsulations and they are left for further study. 395 4.4. Aggregation during DetNet flow to TSN Stream mapping 397 Implementations of this document SHALL use management and control 398 information to map a DetNet flow to a TSN Stream. N:1 mapping 399 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 400 The management or control function that provisions flow mapping SHALL 401 ensure that adequate resources are allocated and configured to 402 provide proper service requirements of the mapped flows. 404 5. Management and Control Implications 406 DetNet flow and TSN Stream mapping related information are required 407 only for TSN-aware MPLS (DetNet) nodes. From the Data Plane 408 perspective there is no practical difference based on the origin of 409 flow mapping related information (management plane or control plane). 411 TSN-aware MPLS DetNet nodes are member of both the DetNet domain and 412 the TSN sub-network. Within the TSN sub-network the TSN-aware MPLS 413 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 414 management and control plane functionalities must be implemented. 415 There are many similarities in the management plane techniques used 416 in DetNet and TSN, but that is not the case for the control plane 417 protocols. For example, RSVP-TE and MSRP behaves differently. 418 Therefore management and control plane design is an important aspect 419 of scenarios, where mapping between DetNet and TSN is required. 421 In order to use a TSN sub-network between DetNet nodes, DetNet 422 specific information must be converted to TSN sub-network specific 423 ones. DetNet flow ID and flow related parameters/requirements must 424 be converted to a TSN Stream ID and stream related parameters/ 425 requirements. Note that, as the TSN sub-network is just a portion of 426 the end2end DetNet path (i.e., single hop from MPLS perspective), 427 some parameters (e.g., delay) may differ significantly. Other 428 parameters (like bandwidth) also may have to be tuned due to the L2 429 encapsulation used within the TSN sub-network. 431 In some case it may be challenging to determine some TSN Stream 432 related information. For example, on a TSN-aware MPLS (DetNet) node 433 that acts as a Talker, it is quite obvious which DetNet node is the 434 Listener of the mapped TSN stream (i.e., the MPLS Next-Hop). However 435 it may be not trivial to locate the point/interface where that 436 Listener is connected to the TSN sub-network. Such attributes may 437 require interaction between control and management plane functions 438 and between DetNet and TSN domains. 440 Mapping between DetNet flow identifiers and TSN Stream identifiers, 441 if not provided explicitly, can be done by a TSN-aware MPLS (DetNet) 442 node locally based on information provided for configuration of the 443 TSN Stream identification functions (Mask-and-match Stream 444 identification and active Stream identification function). 446 Triggering the setup/modification of a TSN Stream in the TSN sub- 447 network is an example where management and/or control plane 448 interactions are required between the DetNet and TSN sub-network. 449 TSN-unaware MPLS (DetNet) nodes make such a triggering even more 450 complicated as they are fully unaware of the sub-network and run 451 independently. 453 Configuration of TSN specific functions (e.g., FRER) inside the TSN 454 sub-network is a TSN domain specific decision and may not be visible 455 in the DetNet domain. Service protection interworking scenarios are 456 left for further study. 458 6. Security Considerations 460 The security considerations of DetNet in general are discussed in 461 [RFC8655] and [I-D.ietf-detnet-security]. DetNet IP data plane 462 specific considerations are summarized in [I-D.ietf-detnet-ip]. 463 Encryption may provided by an underlying sub-net using MACSec 464 [IEEE802.1AE-2018] for DetNet IP over TSN flows. 466 7. IANA Considerations 468 This document makes no IANA requests. 470 8. Acknowledgements 472 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 473 Christophe Mangin and Jouni Korhonen for their various contributions 474 to this work. 476 9. References 478 9.1. Normative References 480 [I-D.ietf-detnet-mpls] 481 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 482 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 483 draft-ietf-detnet-mpls-05 (work in progress), February 484 2020. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 492 Label Switching Architecture", RFC 3031, 493 DOI 10.17487/RFC3031, January 2001, 494 . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 498 May 2017, . 500 9.2. Informative References 502 [I-D.ietf-detnet-ip] 503 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 504 and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- 505 ip-05 (work in progress), February 2020. 507 [I-D.ietf-detnet-security] 508 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 509 J., Austad, H., and N. Finn, "Deterministic Networking 510 (DetNet) Security Considerations", draft-ietf-detnet- 511 security-08 (work in progress), February 2020. 513 [IEEE802.1AE-2018] 514 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 515 Security (MACsec)", 2018, 516 . 518 [IEEE8021CB] 519 Finn, N., "Draft Standard for Local and metropolitan area 520 networks - Seamless Redundancy", IEEE P802.1CB 521 /D2.1 P802.1CB, December 2015, 522 . 525 [IEEE8021Q] 526 IEEE 802.1, "Standard for Local and metropolitan area 527 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 528 2014)", 2014, . 530 [IEEEP8021CBdb] 531 Mangin, C., "Extended Stream identification functions", 532 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 533 . 536 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 537 "Deterministic Networking Architecture", RFC 8655, 538 DOI 10.17487/RFC8655, October 2019, 539 . 541 Authors' Addresses 543 Balazs Varga (editor) 544 Ericsson 545 Magyar Tudosok krt. 11. 546 Budapest 1117 547 Hungary 549 Email: balazs.a.varga@ericsson.com 551 Janos Farkas 552 Ericsson 553 Magyar Tudosok krt. 11. 554 Budapest 1117 555 Hungary 557 Email: janos.farkas@ericsson.com 558 Andrew G. Malis 559 Independent 561 Email: agmalis@gmail.com 563 Stewart Bryant 564 Futurewei Technologies 566 Email: stewart.bryant@gmail.com