diff options
Diffstat (limited to 'doc/rfc/rfc9024.txt')
| -rw-r--r-- | doc/rfc/rfc9024.txt | 657 |
1 files changed, 657 insertions, 0 deletions
diff --git a/doc/rfc/rfc9024.txt b/doc/rfc/rfc9024.txt new file mode 100644 index 0000000..5bef2f6 --- /dev/null +++ b/doc/rfc/rfc9024.txt @@ -0,0 +1,657 @@ + + + + +Internet Engineering Task Force (IETF) B. Varga, Ed. +Request for Comments: 9024 J. Farkas +Category: Standards Track Ericsson +ISSN: 2070-1721 A. Malis + Malis Consulting + S. Bryant + Futurewei Technologies + D. Fedyk + LabN Consulting, L.L.C. + June 2021 + + +Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive + Networking over MPLS + +Abstract + + This document specifies the Deterministic Networking data plane when + Time-Sensitive Networking (TSN) networks are interconnected over a + DetNet MPLS network. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9024. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 2.1. Terms Used in This Document + 2.2. Abbreviations + 2.3. Requirements Language + 3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario + 4. DetNet MPLS Data Plane + 4.1. Overview + 4.2. TSN over DetNet MPLS Encapsulation + 5. TSN over MPLS Data Plane Procedures + 5.1. Edge Node TSN Procedures + 5.2. Edge Node DetNet Service Proxy Procedures + 5.3. Edge Node DetNet Service and Forwarding Sub-Layer + Procedures + 6. Controller Plane (Management and Control) Considerations + 7. Security Considerations + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + The Time-Sensitive Networking Task Group (TSN TG) within the IEEE + 802.1 Working Group deals with deterministic services through IEEE + 802 networks. Deterministic Networking (DetNet) defined by the IETF + is a service that can be offered by an L3 network to DetNet flows. + General background and concepts of DetNet can be found in [RFC8655]. + + This document specifies the use of a DetNet MPLS network to + interconnect TSN nodes/network segments. The DetNet MPLS data plane + is defined in [RFC8964]. + +2. Terminology + +2.1. Terms Used in This Document + + This document uses the terminology and concepts established in the + DetNet architecture [RFC8655] [RFC8938] [RFC8964]. TSN-specific + terms are defined in the TSN TG of the IEEE 802.1 Working Group. The + reader is assumed to be familiar with these documents and their + terminology. + +2.2. Abbreviations + + The following abbreviations are used in this document: + + AC Attachment Circuit + + CE Customer Edge equipment + + d-CW DetNet Control Word + + DetNet Deterministic Networking + + DF DetNet Flow + + FRER Frame Replication and Elimination for Redundancy (TSN + function) + + L2 Layer 2 + + L2VPN Layer 2 Virtual Private Network + + L3 Layer 3 + + LSP Label Switched Path + + LSR Label Switching Router + + MPLS Multiprotocol Label Switching + + MPLS-TE Multiprotocol Label Switching - Traffic Engineering + + NSP Native Service Processing + + OAM Operations, Administration, and Maintenance + + PE Provider Edge + + PREOF Packet Replication, Elimination and Ordering Functions + + PW Pseudowire + + S-PE Switching Provider Edge + + T-PE Terminating Provider Edge + + TSN Time-Sensitive Network + +2.3. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario + + Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN-aware + DetNet service running over an MPLS network. DetNet edge nodes sit + at the boundary of a DetNet domain. They are responsible for mapping + non-DetNet-aware L2 traffic to DetNet services. They also support + the imposition and disposition of the required DetNet encapsulation. + These are functionally similar to PW T-PE nodes, which use MPLS-TE + LSPs. In this example, TSN Streams are simple applications over + DetNet flows. The specifics of this operation are discussed later in + this document. + + TSN Edge Transit Edge TSN + End System Node Node Node End System + (T-PE) (LSR) (T-PE) + + +----------+ +----------+ + | TSN | <-------- End-to-End TSN Service ---------> | TSN | + | Applic. | | Applic. | + +----------+ +.........+ +.........+ +----------+ + | | | \S-Proxy: :S-Proxy/ | | | + | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN | + | | |TSN| |Svc| |Svc| |TSN| | | + +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ + | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | + +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ + : Link : / ,-----. \ : Link : / ,-----. \ + +........+ +-[ Sub- ]-+ +........+ +-[ TSN ]-+ + [Network] [Network] + `-----' `-----' + + |<------ DetNet MPLS ------>| + |<---------------------- TSN --------------------->| + + Figure 1: A TSN over DetNet MPLS-Enabled Network + + In this example, edge nodes provide a service proxy function that + "associates" the DetNet flows and native flows (i.e., TSN Streams) at + the edge of the DetNet domain. TSN Streams are treated as App-flows + for DetNet. The whole DetNet domain behaves as a TSN relay node for + the TSN Streams. The service proxy behaves as a port of that TSN + relay node. + + Figure 2 illustrates how DetNet can provide services for IEEE 802.1 + TSN end systems, CE1 and CE2, over a DetNet-enabled MPLS network. + Edge nodes E1 and E2 insert and remove the required DetNet data plane + encapsulation. The 'X' in the edge nodes and relay node, R1, + represent a potential DetNet compound flow packet replication and + elimination point. This conceptually parallels L2VPN services and + could leverage existing related solutions as discussed below. + + TSN |<------- End-to-End DetNet Service ------>| TSN + Service | Transit Transit | Service + TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN + End | V V 1 V V 2 V V | End + System | +--------+ +--------+ +--------+ | System + +---+ | | E1 |=======| R1 |=======| E2 | | +---+ + | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | + |CE1| | | \ | | X | | / | | |CE2| + | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | + +---+ | |=======| |=======| | +---+ + ^ +--------+ +--------+ +--------+ ^ + | Edge Node Relay Node Edge Node | + | (T-PE) (S-PE) (T-PE) | + | | + |<- TSN -> <------- TSN over DetNet MPLS -------> <- TSN ->| + | | + |<-------- Time-Sensitive Networking (TSN) Service ------->| + + X = Service protection + DFx = DetNet member flow x over a TE LSP + AC = Attachment Circuit + Tnl = Tunnel + + Figure 2: IEEE 802.1TSN over DetNet + +4. DetNet MPLS Data Plane + +4.1. Overview + + The basic approach defined in [RFC8964] supports the DetNet service + sub-layer based on existing PW encapsulations and mechanisms and + supports the DetNet forwarding sub-layer based on existing MPLS + Traffic Engineering encapsulations and mechanisms. + + A node operating on a DetNet flow in the DetNet service sub-layer, + i.e., a node processing a DetNet packet that has the S-Label as top + of stack, uses the local context associated with that S-Label. For + example, a received F-Label can be used to determine what local + DetNet operation(s) is applied to that packet. An S-Label may be + unique when taken from the platform label space [RFC3031], which + would enable correct DetNet flow identification regardless of which + input interface or LSP the packet arrives on. The service sub-layer + functions (i.e., PREOF) use a DetNet control word (d-CW). + + The DetNet MPLS data plane builds on MPLS Traffic Engineering + encapsulations and mechanisms to provide a forwarding sub-layer that + is responsible for providing resource allocation and explicit routes. + The forwarding sub-layer is supported by one or more forwarding + labels (F-Labels). + + DetNet edge/relay nodes are DetNet service sub-layer aware, + understand the particular needs of DetNet flows, and provide both + DetNet service and forwarding sub-layer functions. They add, remove, + and process d-CWs, S-Labels, and F-Labels as needed. MPLS DetNet + nodes and transit nodes include DetNet forwarding sub-layer functions + -- notably, support for explicit routes and resource allocation to + eliminate (or reduce) congestion loss and jitter. Unlike other + DetNet node types, transit nodes provide no service sub-layer + processing. + +4.2. TSN over DetNet MPLS Encapsulation + + The basic encapsulation approach is to treat a TSN Stream as an App- + flow from the DetNet MPLS perspective. The corresponding example is + shown in Figure 3. Note that three example flows are shown in the + figure. + + /-> +------+ +------+ +------+ TSN ^ ^ + MPLS | | X | | X | | X |<- Appli : : + App-Flow <-+ +------+ +------+ +------+ cation : :(1) + | |TSN-L2| |TSN-L2| |TSN-L2| : v + \-> +---+======+--+======+--+======+-----+ : + | d-CW | | d-CW | | d-CW | : + DetNet-MPLS +------+ +------+ +------+ :(2) + |Labels| |Labels| |Labels| v + +---+======+--+======+--+======+-----+ + Link/Sub-Network | L2 | | TSN | | UDP | + +------+ +------+ +------+ + | IP | + +------+ + | L2 | + +------+ + (1) TSN Stream + (2) DetNet MPLS Flow + + Figure 3: Examples of TSN over MPLS Encapsulation Formats + + In the figure, "Application" indicates the application payload + carried by the TSN network. "MPLS App-Flow" indicates that the TSN + Stream is the payload from the perspective of the DetNet MPLS data + plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate + multiple TSN Streams. + + | Note: Network fragmentation for DetNet is not supported and + | MUST be avoided. The reason for this is that network + | fragmentation is not consistent with the packet delivery times + | needed for DetNet. Therefore, when IP is used as the sub- + | network, IPv6 fragmentation MUST NOT be used, and IPv4 packets + | MUST be sent with the DF bit set. This means that the network + | operator MUST ensure that all the DetNet encapsulation overhead + | plus the maximum TSN App-flow frame size does not exceed the + | DetNet network's MTU. + +5. TSN over MPLS Data Plane Procedures + + The description of edge node procedures and functions for TSN over + DetNet MPLS scenarios follows the concepts from [RFC3985] and covers + the edge node components shown in Figure 1. In this section, the + following procedures of DetNet edge nodes are described: + + * TSN related (Section 5.1) + + * DetNet Service Proxy (Section 5.2) + + * DetNet service and forwarding sub-layer (Section 5.3) + + The subsections describe procedures for forwarding packets by DetNet + edge nodes, where such packets are received from either directly + connected CEs (TSN nodes) or some other DetNet edge nodes. + +5.1. Edge Node TSN Procedures + + The TSN TG of the IEEE 802.1 Working Group has defined (and is + defining) a number of amendments to [IEEE8021Q] that provide zero + congestion loss and bounded latency in bridged networks. + [IEEE8021CB] defines packet replication and elimination functions for + a TSN network. + + The implementation of a TSN entity (i.e., TSN packet processing + functions) must be compliant with the relevant IEEE 802.1 standards. + + TSN-specific functions are executed on the data received by the + DetNet edge node from the connected CE before being forwarded to + connected CE(s) or presented to the DetNet service proxy function for + transmission across the DetNet domain. TSN-specific functions are + also executed on the data received from a DetNet PW by a PE before + the data is output on the AC(s). + + The TSN packet processing function(s) of edge nodes (T-PE) belongs to + the NSP [RFC3985] block. This is similar to other functionalities + being defined by standards bodies other than the IETF (for example, + in the case of Ethernet, stripping, overwriting, or adding VLAN tags, + etc.). Depending on the TSN role of the edge node in the end-to-end + TSN service, selected TSN functions are supported. + + When a PE receives a packet from a CE on a given AC with DetNet + service, it first checks via Stream identification (see Clause 6 of + [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a + configured TSN Stream (i.e., App-flow from the DetNet perspective). + If no Stream ID is matched and no other (VPN) service is configured + for the AC, then the packet MUST be dropped. If there is a matching + TSN Stream, then the Stream-ID-specific TSN functions are executed + (e.g., ingress policing, header field manipulation in the case of + active Stream identification, FRER, etc.). Source Media Access + Control (MAC) lookup may also be used for local MAC address learning. + + If the PE decides to forward the packet, the packet MUST be forwarded + according to the TSN-Stream-specific configuration to connected CE(s) + (in case of local bridging) and/or to the DetNet service proxy (in + case of forwarding to remote CE(s)). If there are no TSN-Stream- + specific forwarding configurations, the PE MUST flood the packet to + other locally attached CE(s) and to the DetNet service proxy. If the + administrative policy on the PE does not allow flooding, the PE MUST + drop the packet. + + When a TSN entity of the PE receives a packet from the DetNet service + proxy, it first checks via Stream identification (see Clause 6 of + [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a + configured TSN Stream. If no Stream ID is matched, then the packet + is dropped. If there is a matching TSN Stream, then the Stream-ID- + specific TSN functions are executed (e.g., header field manipulation + in case of active Stream identification, FRER, etc.). Source MAC + lookup may also be used for local MAC address learning. + + If the PE decides to forward the packet, the packet is forwarded + according to the TSN-Stream-specific configuration to connected + CE(s). If there are no TSN-Stream-specific forwarding + configurations, the PE floods the packet to locally attached CE(s). + If the administrative policy on the PE does not allow flooding, the + PE drops the packet. + + Implementations of this document SHALL use management and control + information to ensure TSN-specific functions of the edge node + according to the expectations of the connected TSN network. + +5.2. Edge Node DetNet Service Proxy Procedures + + The service proxy function maps between App-flows and DetNet flows. + The DetNet edge node TSN entity MUST support the TSN Stream + identification functions (as defined in Clause 6 of [IEEE8021CB] and + [IEEEP8021CBdb]) and the related managed objects (as defined in + Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb]) to recognize the + packets related to App-flow. The service proxy presents TSN Streams + as an App-flow to a DetNet flow. + + When a DetNet service proxy receives a packet from the TSN entity, it + MUST check whether such an App-flow is present in its mapping table. + If present, it associates the internal DetNet flow ID to the packet + and MUST forward it to the DetNet service and forwarding sub-layers. + If no match is found, it MUST drop the packet. + + When a DetNet service proxy receives a packet from the DetNet service + and forwarding sub-layers, it MUST be forwarded to the edge node TSN + entity. + + Implementations of this document SHALL use management and control + information to map a TSN Stream to a DetNet flow. N:1 mapping + (aggregating multiple TSN Streams in a single DetNet flow) SHALL be + supported. The management or control function that provisions flow + mapping SHALL ensure that adequate resources are allocated and + configured to fulfill the service requirements of the mapped flows. + + Due to the (intentional) similarities of the DetNet PREOF and TSN + FRER functions, service protection function interworking is possible + between the TSN and the DetNet domains. Such service protection + interworking scenarios might require copying of sequence number + fields from TSN (L2) to PW (MPLS) encapsulation. However, such + interworking is out of scope in this document and is left for further + study. + +5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures + + In the design presented in [RFC8964], an MPLS service label (the + S-Label), similar to a PW label [RFC3985], is used to identify both + the DetNet flow identity and the MPLS payload type. The DetNet + sequence number is carried in the d-CW, which carries the Data/OAM + discriminator as well. In [RFC8964], two sequence number sizes are + supported: a 16-bit sequence number and a 28-bit sequence number. + + PREOF functions and the provided service recovery are available only + within the DetNet domain as the DetNet flow ID and the DetNet + sequence number are not valid outside the DetNet network. MPLS + (DetNet) edge nodes terminate all related information elements + encoded in the MPLS labels. + + When a PE receives a packet from the service proxy function, it MUST + handle the packet as defined in [RFC8964]. + + When a PE receives an MPLS packet from a remote PE, then, after + processing the MPLS label stack, if the top MPLS label ends up being + a DetNet S-Label that was advertised by this node, then the PE MUST + forward the packet according to the configured DetNet service and + forwarding sub-layer rules to other PE nodes or via the DetNet + service proxy function towards locally connected CE(s). + + For further details on DetNet service and forwarding sub-layers, see + [RFC8964]. + +6. Controller Plane (Management and Control) Considerations + + Information related to TSN Stream(s) to DetNet flow mapping is + required only for the service proxy function of MPLS (DetNet) edge + nodes. From the data plane perspective, there is no practical + difference based on the origin of flow-mapping-related information + (management plane or control plane). + + The following summarizes the set of information that is needed to + configure TSN over DetNet MPLS: + + * TSN-related configuration information according to the TSN role of + the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB], and + [IEEEP8021CBdb]. + + * DetNet MPLS-related configuration information according to the + DetNet role of the DetNet MPLS node, as per [RFC8964]. + + * App-flow identification information to map received TSN Stream(s) + to the DetNet flow. Parameters of TSN Stream identification are + defined in [IEEE8021CB] and [IEEEP8021CBdb]. + + This information MUST be provisioned per DetNet flow. + + Mappings between DetNet and TSN management and control planes are out + of scope of the document. Some of the challenges are highlighted + below. + + MPLS DetNet edge nodes are a member of both the DetNet domain and the + connected TSN network. From the TSN network perspective, the MPLS + (DetNet) edge node has a "TSN relay node" role, so TSN-specific + management and control plane functionalities must be implemented. + There are many similarities in the management plane techniques used + in DetNet and TSN, but that is not the case for the control plane + protocols. For example, RSVP-TE and MSRP behave differently. + Therefore, management and control plane design is an important aspect + of scenarios where mapping between DetNet and TSN is required. + + Note that as the DetNet network is just a portion of the end-to-end + TSN path (i.e., single hop from the Ethernet perspective), some + parameters (e.g., delay) may differ significantly. Since there is no + interworking function, the bandwidth of the DetNet network is assumed + to be set large enough to handle all TSN flows it will support. At + the egress of the DetNet domain, the MPLS headers are stripped, and + the TSN flow continues on as a normal TSN flow. + + In order to use a DetNet network to interconnect TSN segments, TSN- + specific information must be converted to DetNet-domain-specific + information. TSN Stream ID(s) and stream-related parameters/ + requirements must be converted to a DetNet flow ID and flow-related + parameters/requirements. + + In some cases, it may be challenging to determine some information + related to the egress-node. For example, it may be not trivial to + locate the egress point/interface of a TSN Stream with a multicast + destination MAC address. Such scenarios may require interaction + between control and management plane functions and between DetNet and + TSN domains. + + Mapping between DetNet flow identifiers and TSN Stream identifiers, + if not provided explicitly, can be done by the service proxy function + of an MPLS (DetNet) edge node locally based on information provided + for the configuration of the TSN Stream identification functions + (e.g., Mask-and-Match Stream identification). + + Triggering the setup/modification of a DetNet flow in the DetNet + network is an example where management and/or control plane + interactions are required between the DetNet and the TSN network. + + Configuration of TSN-specific functions (e.g., FRER) inside the TSN + network is a TSN-domain-specific decision and may not be visible in + the DetNet domain. Service protection interworking scenarios are + left for further study. + +7. Security Considerations + + Security considerations for DetNet are described in detail in + [DETNET-SEC]. General security considerations are described in + [RFC8655]. + + Considerations specific to the DetNet MPLS data plane are summarized + and described in [RFC8964], including any application flow types. + This document focuses on a scenario where TSN Streams are the + application flows for DetNet, which is already covered by those + DetNet MPLS data plane security considerations. + +8. IANA Considerations + + This document has no IANA actions. + +9. References + +9.1. Normative References + + [IEEE8021CB] + IEEE, "Standard for Local and metropolitan area networks + -- Frame Replication and Elimination for Reliability", + IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, + October 2017, + <https://ieeexplore.ieee.org/document/8091139>. + + [IEEEP8021CBdb] + IEEE, "Draft Standard for Local and metropolitan area + networks - Frame Replication and Elimination for + Reliability - Amendment: Extended Stream Identification + Functions", IEEE P802.1CBdb D1.3, April 2021, + <https://1.ieee802.org/tsn/802-1cbdb>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + <https://www.rfc-editor.org/info/rfc3031>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, + "Deterministic Networking Architecture", RFC 8655, + DOI 10.17487/RFC8655, October 2019, + <https://www.rfc-editor.org/info/rfc8655>. + + [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. + Bryant, "Deterministic Networking (DetNet) Data Plane + Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, + <https://www.rfc-editor.org/info/rfc8938>. + + [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, + S., and J. Korhonen, "Deterministic Networking (DetNet) + Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January + 2021, <https://www.rfc-editor.org/info/rfc8964>. + +9.2. Informative References + + [DETNET-SEC] + Grossman, E., Ed., Mizrahi, T., and A. Hacker, + "Deterministic Networking (DetNet) Security + Considerations", Work in Progress, Internet-Draft, draft- + ietf-detnet-security-16, 2 March 2021, + <https://tools.ietf.org/html/draft-ietf-detnet-security- + 16>. + + [IEEE8021Q] + IEEE, "Standard for Local and Metropolitan Area Networks-- + Bridges and Bridged Networks", IEEE Std. 802.1Q-2018, + DOI 10.1109/IEEESTD.2018.8403927, July 2018, + <https://ieeexplore.ieee.org/document/8403927>. + + [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, + DOI 10.17487/RFC3985, March 2005, + <https://www.rfc-editor.org/info/rfc3985>. + +Acknowledgements + + The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, + Christophe Mangin, and Jouni Korhonen for their various contributions + to this work. + +Authors' Addresses + + Balázs Varga (editor) + Ericsson + Budapest + Magyar Tudosok krt. 11. + 1117 + Hungary + + Email: balazs.a.varga@ericsson.com + + + János Farkas + Ericsson + Budapest + Magyar Tudosok krt. 11. + 1117 + Hungary + + Email: janos.farkas@ericsson.com + + + Andrew G. Malis + Malis Consulting + + Email: agmalis@gmail.com + + + Stewart Bryant + Futurewei Technologies + + Email: sb@stewartbryant.com + + + Don Fedyk + LabN Consulting, L.L.C. + + Email: dfedyk@labn.net |