idnits 2.17.1 draft-ietf-detnet-ip-07.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 (July 3, 2020) is 1393 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 269, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-data-plane-framework (ref. 'I-D.ietf-detnet-data-plane-framework') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-10 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-06 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-03 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-07 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-10 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-03 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-06 Summary: 2 errors (**), 0 flaws (~~), 9 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: January 4, 2021 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 S. Bryant 9 Futurewei Technologies 10 July 3, 2020 12 DetNet Data Plane: IP 13 draft-ietf-detnet-ip-07 15 Abstract 17 This document specifies the DetNet data plane operation for IP hosts 18 and routers that provide DetNet service to IP encapsulated data. No 19 DetNet-specific encapsulation is defined to support IP flows; instead 20 the existing IP and higher layer protocol header information is used 21 to support flow identification and DetNet service delivery. This 22 document builds on the DetNet Architecture and Data Plane Framework. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 64 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7 65 4.1. End System Specific Considerations . . . . . . . . . . . 8 66 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 8 67 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 11 68 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 11 69 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 11 70 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 12 71 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 12 72 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 13 73 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 13 74 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 14 75 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 14 76 5.1.2. Other Protocol Header Information . . . . . . . . . . 15 77 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 17 78 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 17 79 6. Management and Control Information Summary . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 11.1. Normative references . . . . . . . . . . . . . . . . . . 20 86 11.2. Informative references . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 Deterministic Networking (DetNet) is a service that can be offered by 92 a network to DetNet flows. DetNet provides these flows with 93 extremely low packet loss rates and assured maximum end-to-end 94 delivery latency. General background and concepts of DetNet can be 95 found in the DetNet Architecture [RFC8655]. 97 This document specifies the DetNet data plane operation for IP hosts 98 and routers that provide DetNet service to IP encapsulated data. No 99 DetNet-specific encapsulation is defined to support IP flows; instead 100 the existing IP and higher layer protocol header information is used 101 to support flow identification and DetNet service delivery. Common 102 data plane procedures and control information for all DetNet data 103 planes can be found in [I-D.ietf-detnet-data-plane-framework]. 105 The DetNet Architecture models the DetNet related data plane 106 functions as two sub-layers: a service sub-layer and a forwarding 107 sub-layer. The service sub-layer is used to provide DetNet service 108 protection (e.g., by packet replication and packet elimination 109 functions) and reordering. The forwarding sub-layer is used to 110 provide congestion protection (low loss, assured latency, and limited 111 out-of-order delivery). The service sub-layer generally requires 112 additional header fields to provide its service; for example see 113 [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to 114 support DetNet IP flows, only the forwarding sub-layer functions are 115 supported using the DetNet IP defined by this document. Service 116 protection can be provided on a per sub-net basis using technologies 117 such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified 118 in the IEEE 802.1 TSN (Time-Sensitive Networking) task group 119 (referred to in this document simply as IEEE802.1 TSN). 121 This document provides an overview of the DetNet IP data plane in 122 Section 3, and considerations that apply to providing DetNet services 123 via the DetNet IP data plane in Section 4. Section 5 provides the 124 procedures for hosts and routers that support IP-based DetNet 125 services. Section 6 summarizes the set of information that is needed 126 to identify an individual DetNet flow. 128 2. Terminology 130 2.1. Terms Used In This Document 132 This document uses the terminology and concepts established in the 133 DetNet architecture [RFC8655], and the reader is assumed to be 134 familiar with that document and its terminology. 136 2.2. Abbreviations 138 The following abbreviations used in this document: 140 CoS Class of Service 142 DetNet Deterministic Networking 144 DN DetNet 145 DiffServ Differentiated Services 147 DSCP Differentiated Services Code Point 149 L2 Layer-2 151 L3 Layer-3 153 LSP Label-switched path 155 MPLS Multiprotocol Label Switching 157 PREOF Packet Replication, Elimination and Ordering Function 159 QoS Quality of Service 161 TSN Time-Sensitive Networking, TSN is a Task Group of the 162 IEEE 802.1 Working Group. 164 2.3. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 3. DetNet IP Data Plane Overview 174 This document describes how IP is used by DetNet nodes, i.e., hosts 175 and routers, to identify DetNet flows and provide a DetNet service 176 using an IP data plane. From a data plane perspective, an end-to-end 177 IP model is followed. As mentioned above, existing IP and higher 178 layer protocol header information is used to support flow 179 identification and DetNet service delivery. Common data plane 180 procedures and control information for all DetNet data planes can be 181 found in [I-D.ietf-detnet-data-plane-framework]. 183 The DetNet IP data plane primarily uses 6-tuple based flow 184 identification, where "6-tuple" refers to information carried in IP 185 and higher layer protocol headers. The 6-tuple referred to in this 186 document is the same as that defined in [RFC3290]. Specifically 187 6-tuple is destination address, source address, IP protocol, source 188 port, destination port, and differentiated services (DiffServ) code 189 point (DSCP). General background on the use of IP headers, and 190 5-tuples, to identify flows and support Quality of Service (QoS) can 191 be found in [RFC3670]. [RFC7657] also provides useful background on 192 the delivery of DiffServ and "tuple" based flow identification. Note 193 that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP 194 component. 196 For some of the protocols 5-tuples and 6-tuples cannot be used 197 because the port information is not available (e.g., ICMP, IPSec 198 ESP). This is also the case for flow aggregates. In such cases, 199 using fewer fields is appropriate, e.g., a 3-tuple (2 IP addresses, 200 IP protocol) or even a 2-tuple (all IP traffic between two IP 201 addresses). 203 The DetNet IP data plane also allows for optional matching on the 204 IPv6 flow label field, as defined in [RFC8200]. 206 Non-DetNet and DetNet IP packets have the same protocol header format 207 on the wire. Generally the fields used in flow identification are 208 forwarded unmodified. However, standard modification of the DSCP 209 field [RFC2474] is not precluded. 211 DetNet flow aggregation may be enabled via the use of wildcards, 212 masks, lists, prefixes and ranges. IP tunnels may also be used to 213 support flow aggregation. In these cases, it is expected that 214 DetNet-aware intermediate nodes will provide DetNet service on the 215 aggregate through resource allocation and congestion control 216 mechanisms. 218 The specific procedures that are required to be implemented by a 219 DetNet node supporting this document can be found in Section 5. The 220 DetNet controller plane, as defined in [RFC8655], is responsible for 221 providing each node with the information needed to identify and 222 handle each DetNet flow. 224 DetNet IP Relay Relay DetNet IP 225 End System Node Node End System 227 +----------+ +----------+ 228 | Appl. |<------------ End to End Service ----------->| Appl. | 229 +----------+ ............ ........... +----------+ 230 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 231 +----------+ +----------+ +----------+ +----------+ 232 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 233 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 234 : Link : \ ,-----. / \ ,-----. / 235 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 236 [Network] [Network] 237 `-----' `-----' 239 |<--------------------- DetNet IP --------------------->| 241 Figure 1: A Simple DetNet (DN) Enabled IP Network 243 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 244 end systems originate IP encapsulated traffic that is identified 245 within the DetNet domain as DetNet flows based on IP header 246 information. Relay nodes understand the forwarding requirements of 247 the DetNet flow and ensure that node, interface and sub-network 248 resources are allocated to ensure DetNet service requirements. The 249 dotted line around the Service component of the Relay Nodes indicates 250 that the transit routers are DetNet service aware but do not perform 251 any DetNet service sub-layer function, e.g., PREOF (Packet 252 Replication, Elimination and Ordering Function). 254 Note: The sub-network can represent a TSN, MPLS network or other 255 network technology that can carry DetNet IP traffic. 257 IP Edge Edge IP 258 End System Node Node End System 260 +----------+ +.........+ +.........+ +----------+ 261 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 262 +----------+ +.........+ +.........+ +----------+ 263 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 264 +----------+ +---+ +---+ +---+ +---+ +----------+ 265 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 266 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 267 : Link : \ ,-----. / / ,-----. \ 268 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 269 [Network] [Network] 270 `-----' `-----' 272 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 274 Figure 2: Non-DetNet-aware IP end systems with DetNet IP Domain 276 Figure 2 illustrates a variant of Figure 1 where the end systems are 277 not DetNet aware. In this case, edge nodes sit at the boundary of 278 the DetNet domain and provide DetNet service proxies for the end 279 applications by initiating and terminating DetNet service for the 280 application's IP flows. The existing header information or an 281 approach such as described in Section 4.4 can be used to support 282 DetNet flow identification. 284 Note that Figure 1 and Figure 2 can be collapsed, so IP DetNet End 285 Systems can communicate over a DetNet IP network with IP End Systems. 287 As non-DetNet and DetNet IP packets have the same protocol header 288 format on the wire, from a data plane perspective, the only 289 difference is that there is flow-associated DetNet information on 290 each DetNet node that defines the flow related characteristics and 291 required forwarding behavior. As shown above, edge nodes provide a 292 Service Proxy function that "associates" one or more IP flows with 293 the appropriate DetNet flow-specific information and ensures that the 294 flow receives the proper traffic treatment within the domain. 296 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 297 IP networks is not described in this document. TSN over MPLS is 298 described in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 300 4. DetNet IP Data Plane Considerations 302 This section provides considerations related to providing DetNet 303 service to flows which are identified based on their header 304 information. 306 4.1. End System Specific Considerations 308 Data-flows requiring DetNet service are generated and terminated on 309 end systems. This document deals only with IP end systems. The 310 protocols used by an IP end system are specific to an application, 311 and end systems peer with other end systems. DetNet's use of 6-tuple 312 IP flow identification means that DetNet must be aware of not only 313 the format of the IP header, but also of the next protocol value 314 carried within an IP packet (see Section 5.1.1.3). 316 For DetNet unaware IP end systems service-level proxy functions are 317 needed inside the DetNet domain. 319 When IP end systems are DetNet-aware, no application-level or 320 service-level proxy functions are needed inside the DetNet domain. 321 End systems need to ensure that DetNet service requirements are met 322 when processing packets associated to a DetNet flow. When sending 323 packets, this means that packets are appropriately shaped on 324 transmission and receive appropriate traffic treatment on the 325 connected sub-network; see Section 4.3.2 and Section 4.2 for more 326 details. When receiving packets, this means that there are 327 appropriate local node resources, e.g., buffers, to receive and 328 process the packets of that DetNet flow. 330 An important additional consideration for DetNet-aware end systems is 331 avoiding IP fragmentation. Full 6-tuple flow identification is not 332 possible on IP fragments as fragments don't include the transport 333 headers or their port information. As such, it is important that 334 applications and/or end-systems use an IP packet size that will avoid 335 fragmentation within the network when sending DetNet flows. The 336 maximum size can be learned via path MTU discovery, [RFC1192] and 337 [RFC8201], or via the controller plane. Note that path MTU discovery 338 relies on ICMP, which may not follow the same path as an individual 339 DetNet flow. 341 In order to maximize reuse of existing mechanisms, DetNet-aware 342 applications and end systems SHOULD NOT mix DetNet and non-DetNet 343 traffic within a single 5-tuple. 345 4.2. DetNet Domain-Specific Considerations 347 As a general rule, DetNet IP domains need to be able to forward any 348 DetNet flow identified by the IP 6-tuple. Doing otherwise would 349 limit the number of 6-tuple flow ID combinations that could be used 350 by the end systems. From a practical standpoint this means that all 351 nodes along the end-to-end path of DetNet flows need to agree on what 352 fields are used for flow identification. Possible consequences of 353 not having such an agreement include some flows interfering with 354 other flows, and the traffic treatment expected for a service not 355 being provided. 357 From a connection type perspective two scenarios are identified: 359 1. DN attached: the end system is directly connected to an edge 360 node, or the end system is behind a sub-network (See ES1 and ES2 361 in figure below) 363 2. DN integrated: the end system is part of the DetNet domain. (See 364 ES3 in figure below) 366 L3 (IP) end systems may use any of these connection types. A DetNet 367 domain allows communication between any end systems using the same 368 encapsulation format, independent of their connection type and DetNet 369 capability. DN attached end systems have no knowledge about the 370 DetNet domain and its encapsulation format. See Figure 3 for L3 end 371 system connection examples. 373 ____+----+ 374 +----+ _____ / | ES3| 375 | ES1|____ / \__/ +----+___ 376 +----+ \ / \ 377 + | 378 ____ \ _/ 379 +----+ __/ \ +__ DetNet IP domain / 380 | ES2|____/ L2/L3 |___/ \ __ __/ 381 +----+ \_______/ \_______/ \___/ 383 Figure 3: Connection types of L3 end systems 385 Within a DetNet domain, the DetNet-enabled IP Routers are 386 interconnected by links and sub-networks to support end-to-end 387 delivery of DetNet flows. From a DetNet architecture perspective, 388 these routers are DetNet relays, as they must be DetNet service 389 aware. Such routers identify DetNet flows based on the IP 6-tuple, 390 and ensure that the DetNet service required traffic treatment is 391 provided both on the node and on any attached sub-network. 393 This solution provides DetNet functions end-to-end, but does so on a 394 per link and sub-network basis. Congestion protection and latency 395 control and the resource allocation (queuing, policing, shaping) are 396 supported using the underlying link/sub-network specific mechanisms. 397 However, service protection (packet replication and packet 398 elimination functions) is not provided at the DetNet layer end-to- 399 end. Instead service protection can be provided on a per underlying 400 L2 link and sub-network basis. 402 The DetNet Service Flow is mapped to the link/sub-network specific 403 resources using an underlying system-specific means. This implies 404 each DetNet-aware node on path looks into the forwarded DetNet 405 Service Flow packet and utilize e.g., a 6-tuple to find out the 406 required mapping within a node. 408 As noted earlier, service protection must be implemented within each 409 link/sub-network independently, using the domain specific mechanisms. 410 This is due to the lack of unified end-to-end sequencing information 411 that could be used by the intermediate nodes. Therefore, service 412 protection (if enabled) cannot be provided end-to-end, only within 413 sub-networks. This is shown for a three sub-network scenario in 414 Figure 4, where each sub-network can provide service protection 415 between its borders. "R" and "E" denote replication and elimination 416 points within the sub-network. 418 <-------------------- DenNet IP ------------------------> 419 ______ 420 ____ / \__ 421 ____ / \__/ \___ ______ 422 +----+ __/ +====+ +==+ \ +----+ 423 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 424 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 425 \_ _/ 426 \ __ __/ 427 \_______/ \___/ 429 +---+ +---------E--------+ +-----+ 430 +----+ | | | | | | | +----+ 431 |src |----R E--------R +---+ E------R E------+ dst| 432 +----+ | | | | | | | +----+ 433 +---+ +-----R------------+ +-----+ 435 Figure 4: Replication and elimination in sub-networks for DetNet IP 436 networks 438 If end-to-end service protection is desired, it can be implemented, 439 for example, by the DetNet end systems using Layer-4 (L4) transport 440 protocols or application protocols. However, these protocols are out 441 of scope of this document. 443 Note that not mixing DetNet and non-DetNet traffic within a single 444 5-tuple, as described above, enables simpler 5-tuple filters to be 445 used (or re-used) at the edges of a DetNet network to prevent non- 446 congestion-responsive DetNet traffic from escaping the DetNet domain. 448 4.3. Forwarding Sub-Layer Considerations 450 4.3.1. Class of Service 452 Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is 453 provided using the standard differentiated services (DSCP) field 454 [RFC2474] and related mechanisms. 456 One additional consideration for DetNet nodes which support CoS 457 services is that they must ensure that the CoS service classes do not 458 impact the congestion protection and latency control mechanisms used 459 to provide DetNet QoS. This requirement is similar to the 460 requirement for MPLS LSRs that CoS LSPs cannot impact the resources 461 allocated to TE LSPs [RFC3473]. 463 4.3.2. Quality of Service 465 Quality of Service (QoS) for DetNet service flows carried in IP must 466 be provided locally by the DetNet-aware hosts and routers supporting 467 DetNet flows. Such support leverages the underlying network layer 468 such as 802.1 TSN. The node-internal traffic control mechanisms used 469 to deliver QoS for IP encapsulated DetNet flows are outside the scope 470 of this document. From an encapsulation perspective, the combination 471 of the 6-tuple (the typical 5-tuple enhanced with the DSCP) and 472 optionally the flow label uniquely identifies a DetNet IP flow. 474 Packets that are identified as part of a DetNet IP flow but that have 475 not been the subject of a completed reservation can disrupt the QoS 476 offered to properly reserved DetNet flows by using resources 477 allocated to the reserved flows. Therefore, the network nodes of a 478 DetNet network MUST ensure that no DetNet allocated resources, e.g., 479 queue or shaper, is used by such flows. There are multiple methods 480 that may be used by an implementation to defend service delivery to 481 reserved DetNet flows, including but not limited to: 483 o Treating packets associated with an incomplete reservation as non- 484 DetNet traffic. 486 o Discarding packets associated with an incomplete reservation. 488 o Re-marking packets associated with an incomplete reservation. Re- 489 marking can be accomplished by changing the value of the DSCP 490 field to a value that results in the packet no longer matching any 491 other reserved DetNet IP flow. 493 4.3.3. Path Selection 495 While path selection algorithms and mechanisms are out of scope of 496 the DetNet data plane definition, it is important to highlight the 497 implications of DetNet IP flow identification on path selection and 498 next hops. As mentioned above, the DetNet IP data plane identifies 499 flows using "6-tuple" header information as well as the optional 500 (flow label) header field. DetNet generally allows for both flow- 501 specific traffic treatment and flow-specific next-hops. 503 In non-DetNet IP forwarding, it is generally assumed that the same 504 series of next hops, i.e., the same path, will be used for a 505 particular 5-tuple or, in some cases, e.g., [RFC5120], for a 506 particular 6-tuple. Using different next hops for different 5-tuples 507 does not take any special consideration for DetNet-aware 508 applications. 510 Care should be taken when using different next hops for the same 511 5-tuple. As discussed in [RFC7657], unexpected behavior can occur 512 when a single 5-tuple application flow experiences reordering due to 513 being split across multiple next hops. Understanding of the 514 application and transport protocol impact of using different next 515 hops for the same 5-tuple is required. Again, this impacts path 516 selection for DetNet flows and this document only indirectly. 518 4.4. DetNet Flow Aggregation 520 As described in [I-D.ietf-detnet-data-plane-framework], the ability 521 to aggregate individual flows, and their associated resource control, 522 into a larger aggregate is an important technique for improving 523 scaling by reducing the state per hop. DetNet IP data plane 524 aggregation can take place within a single node, when that node 525 maintains state about both the aggregated and individual flows. It 526 can also take place between nodes, where one node maintains state 527 about only flow aggregates while the other node maintains state on 528 all or a portion of the component flows. In either case, the 529 management or control function that provisions the aggregate flows 530 must ensure that adequate resources are allocated and configured to 531 provide combined service requirements of the individual flows. As 532 DetNet is concerned about latency and jitter, more than just 533 bandwidth needs to be considered. 535 From a single node perspective, the aggregation of IP flows impacts 536 DetNet IP data plane flow identification and resource allocation. As 537 discussed above, IP flow identification uses the IP "6-tuple" for 538 flow identification. DetNet IP flows can be aggregated using any of 539 the 6-tuple fields and optionally also by the flow label. The use of 540 prefixes, wildcards, lists, and value ranges allows a DetNet node to 541 identify aggregate DetNet flows. From a resource allocation 542 perspective, DetNet nodes ought to provide service to an aggregate 543 rather than on a component flow basis. 545 It is the responsibility of the DetNet controller plane to properly 546 provision the use of these aggregation mechanisms. This includes 547 ensuring that aggregated flows have compatible (e.g., the same or 548 very similar) QoS and/or CoS characteristics, see Section 4.3.2. It 549 also includes ensuring that per component-flow service requirements 550 are satisfied by the aggregate, see Section 5.3. 552 The DetNet controller plane MUST ensure that non-congestion- 553 responsive DetNet traffic is not forwarded outside a DetNet domain. 555 4.5. Bidirectional Traffic 557 While the DetNet IP data plane must support bidirectional DetNet 558 flows, there are no special bidirectional features within the data 559 plane. The special case of co-routed bidirectional DetNet flows are 560 solely represented at the management and control plane levels, 561 without specific support or knowledge within the DetNet data plane. 562 Fate sharing and associated or co-routed bidirectional flows can be 563 managed at the control level. 565 Control and management mechanisms need to support bidirectional 566 flows, but the specification of such mechanisms are out of scope of 567 this document. An example control plane solution for MPLS can be 568 found in [RFC7551]. 570 5. DetNet IP Data Plane Procedures 572 This section provides DetNet IP data plane procedures. These 573 procedures have been divided into the following areas: flow 574 identification, forwarding and traffic treatment. Flow 575 identification includes those procedures related to matching IP and 576 higher layer protocol header information to DetNet flow (state) 577 information and service requirements. Flow identification is also 578 sometimes called Traffic classification; for example see [RFC5777]. 579 Forwarding includes those procedures related to next hop selection 580 and delivery. Traffic treatment includes those procedures related to 581 providing an identified flow with the required DetNet service. 583 DetNet IP data plane establishment and operational procedures also 584 have requirements on the control and management systems for DetNet 585 flows and these are referred to in this section. Specifically this 586 section identifies a number of information elements that require 587 support via the management and control interfaces supported by a 588 DetNet node. The specific mechanism used for such support is out of 589 the scope of this document. A summary of the requirements for 590 management and control related information is included. Conformance 591 language is not used in the summary since it applies to future 592 mechanisms such as those that may be provided in YANG models 593 [I-D.ietf-detnet-yang]. 595 5.1. DetNet IP Flow Identification Procedures 597 IP and higher layer protocol header information is used to identify 598 DetNet flows. All DetNet implementations that support this document 599 MUST identify individual DetNet flows based on the set of information 600 identified in this section. Note that additional flow identification 601 requirements, e.g., to support other higher layer protocols, may be 602 defined in the future. 604 The configuration and control information used to identify an 605 individual DetNet flow MUST be ordered by an implementation. 606 Implementations MUST support a fixed order when identifying flows, 607 and MUST identify a DetNet flow by the first set of matching flow 608 information. 610 Implementations of this document MUST support DetNet flow 611 identification when the implementation is acting as a DetNet end 612 systems, a relay node, or as an edge node. 614 5.1.1. IP Header Information 616 Implementations of this document MUST support DetNet flow 617 identification based on IP header information. The IPv4 header is 618 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 620 5.1.1.1. Source Address Field 622 Implementations of this document MUST support DetNet flow 623 identification based on the Source Address field of an IP packet. 624 Implementations SHOULD support longest prefix matching for this field 625 (see [RFC1812] and [RFC7608].) Note that a prefix length of zero (0) 626 effectively means that the field is ignored. 628 5.1.1.2. Destination Address Field 630 Implementations of this document MUST support DetNet flow 631 identification based on the Destination Address field of an IP 632 packet. Implementations SHOULD support longest prefix matching for 633 this field (see [RFC1812] and [RFC7608].) Note that a prefix length 634 of zero (0) effectively means that the field is ignored. 636 Note: Any IP address value is allowed, including an IP multicast 637 destination address. 639 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 641 Implementations of this document MUST support DetNet flow 642 identification based on the IPv4 Protocol field when processing IPv4 643 packets, and the IPv6 Next Header Field when processing IPv6 packets. 644 This includes the next protocol values defined in Section 5.1.2 and 645 any other value, including zero. Implementations SHOULD allow for 646 these fields to be ignored for a specific DetNet flow. 648 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 650 These fields are used to support Differentiated Services [RFC2474] 651 [RFC2475]. Implementations of this document MUST support DetNet flow 652 identification based on the DSCP field in the IPv4 Type of Service 653 field when processing IPv4 packets, and the DSCP field in the IPv6 654 Traffic Class Field when processing IPv6 packets. Implementations 655 MUST support list-based matching of DSCP values, where the list is 656 composed of possible field values that are to be considered when 657 identifying a specific DetNet flow. Implementations SHOULD allow for 658 this field to be ignored for a specific DetNet flow. 660 5.1.1.5. IPv6 Flow Label Field 662 Implementations of this document SHOULD support identification of 663 DetNet flows based on the IPv6 Flow Label field. Implementations 664 that support matching based on this field MUST allow for it to be 665 ignored for a specific DetNet flow. When this field is used to 666 identify a specific DetNet flow, implementations MAY exclude the IPv6 667 Next Header field and next header information as part of DetNet flow 668 identification. 670 5.1.2. Other Protocol Header Information 672 Implementations of this document MUST support DetNet flow 673 identification based on header information identified in this 674 section. Support for TCP, UDP, ICMP and IPsec flows is defined. 675 Future documents are expected to define support for other protocols. 677 5.1.2.1. TCP and UDP 679 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 680 achieved based on the Source and Destination Port fields carried in 681 each protocol's header. These fields share a common format and 682 common DetNet flow identification procedures. 684 The rules defined in this section only apply when the IPv4 Protocol 685 or IPv6 Next Header Field contains the IANA defined value for UDP or 686 TCP. 688 5.1.2.1.1. Source Port Field 690 Implementations of this document MUST support DetNet flow 691 identification based on the Source Port field of a TCP or UDP packet. 692 Implementations MUST support flow identification based on a 693 particular value carried in the field, i.e., an exact value. 694 Implementations SHOULD support range-based port matching. 695 Implementation MUST also allow for the field to be ignored for a 696 specific DetNet flow. 698 5.1.2.1.2. Destination Port Field 700 Implementations of this document MUST support DetNet flow 701 identification based on the Destination Port field of a TCP or UDP 702 packet. Implementations MUST support flow identification based on a 703 particular value carried in the field, i.e., an exact value. 704 Implementations SHOULD support range-based port matching. 705 Implementation MUST also allow for the field to be ignored for a 706 specific DetNet flow. 708 5.1.2.2. ICMP 710 DetNet flow identification for ICMP [RFC0792] is achieved based on 711 the protocol number in the IP header. Note that ICMP type is not 712 included in the flow definition. 714 5.1.2.3. IPsec AH and ESP 716 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 717 Payload (ESP) [RFC4303] share a common format for the Security 718 Parameters Index (SPI) field. Implementations MUST support flow 719 identification based on a particular value carried in the field, 720 i.e., an exact value. Implementation SHOULD also allow for the field 721 to be ignored for a specific DetNet flow. 723 The rules defined in this section only apply when the IPv4 Protocol 724 or IPv6 Next Header Field contains the IANA defined value for AH or 725 ESP. 727 5.2. Forwarding Procedures 729 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 730 and [RFC8504], and are not modified by this document. The typical 731 next-hop selection process is impacted by DetNet. Specifically, 732 implementations of this document SHALL use management and control 733 information to select the one or more outgoing interfaces and next 734 hops to be used for a packet associated with a DetNet flow. Specific 735 management and control information will be defined in future 736 documents, e.g., [I-D.ietf-detnet-yang]. 738 The use of multiple paths or links, e.g., ECMP, to support a single 739 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 740 flows within a DetNet domain. 742 The above implies that management and control functions will be 743 defined to support this requirement, e.g., see 744 [I-D.ietf-detnet-yang]. 746 5.3. DetNet IP Traffic Treatment Procedures 748 Implementations of this document must ensure that a DetNet flow 749 receives the traffic treatment that is provisioned for it via 750 configuration or the controller plane, e.g., via 751 [I-D.ietf-detnet-yang]. General information on DetNet service can be 752 found in [I-D.ietf-detnet-flow-information-model]. Typical 753 mechanisms used to provide different treatment to different flows 754 includes the allocation of system resources (such as queues and 755 buffers) and provisioning of related parameters (such as shaping, and 756 policing). Support can also be provided via an underlying network 757 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1 758 TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones 759 used in the TSN case are outside the scope of this document. 761 6. Management and Control Information Summary 763 The following summarizes the set of information that is needed to 764 identify individual and aggregated DetNet flows: 766 o IPv4 and IPv6 source address field. 768 o IPv4 and IPv6 source address prefix length, where a zero (0) value 769 effectively means that the address field is ignored. 771 o IPv4 and IPv6 destination address field. 773 o IPv4 and IPv6 destination address prefix length, where a zero (0) 774 effectively means that the address field is ignored. 776 o IPv4 protocol field. A limited set of values is allowed, and the 777 ability to ignore this field is desirable. 779 o IPv6 next header field. A limited set of values is allowed, and 780 the ability to ignore this field is desirable. 782 o For the IPv4 Type of Service and IPv6 Traffic Class Fields: 784 * Whether or not the DSCP field is used in flow identification. 785 Use of the DSCP field for flow identification is optional. 787 * If the DSCP field is used to identify a flow, then the flow 788 identification information (for that flow) includes a list of 789 DSCPs used by that flow. 791 o IPv6 flow label field. This field can be optionally used for 792 matching. When used, this field can be used instead of matching 793 against the Next Header field. 795 o TCP and UDP Source Port. Support for both exact and wildcard 796 matching is required. Port ranges can optionally be used. 798 o TCP and UDP Destination Port. Support for both exact and wildcard 799 matching is required. Port ranges can optionally be used. 801 o IPsec Header SPI field. Exact matching is required. Support for 802 wildcard matching is recommended. 804 o For end systems, an optional maximum IP packet size that should be 805 used for that outgoing DetNet IP flow. 807 This information MUST be provisioned per DetNet flow via 808 configuration, e.g., via the controller or management plane. 810 An implementation MUST support ordering of the set of information 811 information used to identify an individual DetNet flow. This can, 812 for example, be used to provide a DetNet service for a specific UDP 813 flow, with unique Source and Destination Port field values, while 814 providing a different service for the aggregate of all other flows 815 with that same UDP Destination Port value. 817 It is the responsibility of the DetNet controller plane to properly 818 provision both flow identification information and the flow specific 819 resources needed to provided the traffic treatment needed to meet 820 each flow's service requirements. This applies for aggregated and 821 individual flows. 823 7. Security Considerations 825 Detailed security considerations for DetNet are cataloged in 826 [I-D.ietf-detnet-security], and more general security considerations 827 are described in [RFC8655]. This section considers exclusively 828 security considerations which are specific to the DetNet IP data 829 plane. 831 Security aspects which are unique to DetNet are those whose aim is to 832 provide the specific quality of service aspects of DetNet, which are 833 primarily to deliver data flows with extremely low packet loss rates 834 and bounded end-to-end delivery latency. Achieving such loss rates 835 and bounded latency may not be possible in the face of a highly 836 capable adversary, such as the one envisioned by the Internet Threat 837 Model of BCP 72 that can arbitrarily drop or delay any or all 838 traffic. In order to present meaningful security considerations, we 839 consider a somewhat weaker attacker who does not control the physical 840 links of the DetNet domain, but may have the ability to control a 841 network node within the boundary of the DetNet domain. 843 The primary consideration for the DetNet data plane is to maintain 844 integrity of data and delivery of the associated DetNet service 845 traversing the DetNet network. Since no DetNet-specific fields are 846 available in the DetNet IP data plane, the integrity and 847 confidentiality of application flows can be protected through 848 whatever means are provided by the underlying technology. For 849 example, encryption may be used, such as that provided by IPSec 850 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 851 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 853 From a data plane perspective this document does not add or modify 854 any header information. 856 At the management and control level DetNet flows are identified on a 857 per-flow basis, which may provide controller plane attackers with 858 additional information about the data flows (when compared to 859 controller planes that do not include per-flow identification). This 860 is an inherent property of DetNet which has security implications 861 that should be considered when determining if DetNet is a suitable 862 technology for any given use case. 864 To provide uninterrupted availability of the DetNet service, 865 provisions can be made against DOS attacks and delay attacks. To 866 protect against DOS attacks, excess traffic due to malicious or 867 malfunctioning devices can be prevented or mitigated, for example 868 through the use of existing mechanism such as policing and shaping 869 applied at the input of a DetNet domain or within an edge IEEE802.1 870 TSN domain. To prevent DetNet packets from being delayed by an 871 entity external to a DetNet domain, DetNet technology definition can 872 allow for the mitigation of Man-In-The-Middle attacks, for example 873 through use of authentication and authorization of devices within the 874 DetNet domain. 876 8. IANA Considerations 878 This document does not require an action from IANA. 880 9. Acknowledgements 882 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 883 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 884 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 885 Bernardos for their various contributions to this work. David Black 886 served as technical advisor to the DetNet working group during the 887 development of this document and provided many valuable comments. 888 IESG comments were provided by Murray Kucherawy, Roman Danyliw, 889 Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Erik Vyncke. 891 10. Contributors 893 RFC7322 limits the number of authors listed on the front page of a 894 draft to a maximum of 5. The editor wishes to thank and acknowledge 895 the follow authors for contributing text to this draft. 897 Jouni Korhonen 898 Email: jouni.nospam@gmail.com 900 Andrew G. Malis 901 Malis Consulting 902 Email: agmalis@gmail.com 904 11. References 906 11.1. Normative references 908 [I-D.ietf-detnet-data-plane-framework] 909 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 910 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 911 data-plane-framework-06 (work in progress), May 2020. 913 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 914 DOI 10.17487/RFC0768, August 1980, 915 . 917 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 918 DOI 10.17487/RFC0791, September 1981, 919 . 921 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 922 RFC 792, DOI 10.17487/RFC0792, September 1981, 923 . 925 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 926 RFC 793, DOI 10.17487/RFC0793, September 1981, 927 . 929 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 930 RFC 1812, DOI 10.17487/RFC1812, June 1995, 931 . 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, 935 DOI 10.17487/RFC2119, March 1997, 936 . 938 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 939 "Definition of the Differentiated Services Field (DS 940 Field) in the IPv4 and IPv6 Headers", RFC 2474, 941 DOI 10.17487/RFC2474, December 1998, 942 . 944 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 945 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 946 December 2005, . 948 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 949 DOI 10.17487/RFC4302, December 2005, 950 . 952 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 953 RFC 4303, DOI 10.17487/RFC4303, December 2005, 954 . 956 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 957 Length Recommendation for Forwarding", BCP 198, RFC 7608, 958 DOI 10.17487/RFC7608, July 2015, 959 . 961 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 962 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 963 May 2017, . 965 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 966 (IPv6) Specification", STD 86, RFC 8200, 967 DOI 10.17487/RFC8200, July 2017, 968 . 970 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 971 "Deterministic Networking Architecture", RFC 8655, 972 DOI 10.17487/RFC8655, October 2019, 973 . 975 11.2. Informative references 977 [I-D.ietf-detnet-dp-sol-mpls] 978 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 979 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 980 progress), March 2019. 982 [I-D.ietf-detnet-flow-information-model] 983 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 984 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 985 flow-information-model-10 (work in progress), May 2020. 987 [I-D.ietf-detnet-ip-over-mpls] 988 Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. 989 Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- 990 detnet-ip-over-mpls-06 (work in progress), May 2020. 992 [I-D.ietf-detnet-ip-over-tsn] 993 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 994 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 995 (TSN)", draft-ietf-detnet-ip-over-tsn-03 (work in 996 progress), June 2020. 998 [I-D.ietf-detnet-mpls] 999 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 1000 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 1001 detnet-mpls-07 (work in progress), June 2020. 1003 [I-D.ietf-detnet-security] 1004 Mizrahi, T. and E. Grossman, "Deterministic Networking 1005 (DetNet) Security Considerations", draft-ietf-detnet- 1006 security-10 (work in progress), May 2020. 1008 [I-D.ietf-detnet-tsn-vpn-over-mpls] 1009 Varga, B., Farkas, J., Malis, A., Bryant, S., and D. 1010 Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive 1011 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 1012 mpls-03 (work in progress), June 2020. 1014 [I-D.ietf-detnet-yang] 1015 Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. 1016 Fedyk, "Deterministic Networking (DetNet) Configuration 1017 YANG Model", draft-ietf-detnet-yang-06 (work in progress), 1018 June 2020. 1020 [IEEE802.1AE-2018] 1021 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 1022 Security (MACsec)", 2018, 1023 . 1025 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1026 Communication Layers", STD 3, RFC 1122, 1027 DOI 10.17487/RFC1122, October 1989, 1028 . 1030 [RFC1192] Kahin, B., "Commercialization of the Internet summary 1031 report", RFC 1192, DOI 10.17487/RFC1192, November 1990, 1032 . 1034 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1035 and W. Weiss, "An Architecture for Differentiated 1036 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1037 . 1039 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 1040 Informal Management Model for Diffserv Routers", RFC 3290, 1041 DOI 10.17487/RFC3290, May 2002, 1042 . 1044 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1045 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1046 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1047 DOI 10.17487/RFC3473, January 2003, 1048 . 1050 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 1051 W. Weiss, "Information Model for Describing Network Device 1052 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 1053 January 2004, . 1055 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1056 Topology (MT) Routing in Intermediate System to 1057 Intermediate Systems (IS-ISs)", RFC 5120, 1058 DOI 10.17487/RFC5120, February 2008, 1059 . 1061 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 1062 Ed., and A. Lior, "Traffic Classification and Quality of 1063 Service (QoS) Attributes for Diameter", RFC 5777, 1064 DOI 10.17487/RFC5777, February 2010, 1065 . 1067 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1068 Extensions for Associated Bidirectional Label Switched 1069 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1070 . 1072 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1073 (Diffserv) and Real-Time Communication", RFC 7657, 1074 DOI 10.17487/RFC7657, November 2015, 1075 . 1077 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1078 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1079 DOI 10.17487/RFC8201, July 2017, 1080 . 1082 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1083 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1084 January 2019, . 1086 Authors' Addresses 1088 Balazs Varga (editor) 1089 Ericsson 1090 Magyar Tudosok krt. 11. 1091 Budapest 1117 1092 Hungary 1094 Email: balazs.a.varga@ericsson.com 1095 Janos Farkas 1096 Ericsson 1097 Magyar Tudosok krt. 11. 1098 Budapest 1117 1099 Hungary 1101 Email: janos.farkas@ericsson.com 1103 Lou Berger 1104 LabN Consulting, L.L.C. 1106 Email: lberger@labn.net 1108 Don Fedyk 1109 LabN Consulting, L.L.C. 1111 Email: dfedyk@labn.net 1113 Stewart Bryant 1114 Futurewei Technologies 1116 Email: stewart.bryant@gmail.com