Internet DRAFT - draft-mihaly-enablers-for-tlp-evolution
draft-mihaly-enablers-for-tlp-evolution
Internet Engineering Task Force Attila Mihaly
Internet-Draft Szilveszter Nadas
Intended status: Informational Ericsson
Expires: September 2015 March 9, 2015
Enablers for Transport Layer Protocol Evolution
draft-mihaly-enablers-for-tlp-evolution-00.txt
Abstract
In this document we collected requirements for TLP evolution. These
requirements are the consequence of removing obstacles of TLP
evolution. This results in a higher variety of expected TLP
implementations and lower trust level in these. Confidentiality of
communication and security is more and more important. Middleboxes
which today are one of the obstacles of the evolution shall be taken
into account and incentivized to cooperate in the future landscape.
Resulting from the requirements we propose areas for further
investigation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 9, 2015.
Mihaly Expires September 9, 2015 [Page 1]
Internet-Draft Enablers for TLP evolution March 2015
Copyright Notice
Copyright (c) 2015 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
(http://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.
Table of Contents
1. Introduction...................................................3
1.1. Main obstacles to TLP evolution...........................3
1.1.1. Kernel-based TLP implementations.....................3
1.1.2. Middleboxes..........................................4
2. Requirements on the TLP framework..............................4
2.1. Enforce expected TLP behavior.............................4
2.2. Enable application access to TLPs.........................5
2.3. Allow for consistent TLP selection........................5
2.4. Allow the path influencing TLP selection..................5
2.5. Ensure expected TLP performance characteristics...........5
2.6. Ensure that the access providers can be part of the value
chain..........................................................6
2.7. Ensure confidentiality of end-to-end communication........6
2.8. Ensure security of end-to-end communication...............6
2.9. Ensure user control.......................................7
3. Ideas for framework evolution..................................7
3.1. API definitions for TLP selection within the host.........7
3.2. Generic TLP related functions and APIs....................9
3.3. Mechanisms for consistent TLP selection...................9
3.4. Security solutions for multiple trust domains............10
3.5. In-band protocol for Middlebox communication.............10
4. On open source TLP implementations............................12
5. Related work..................................................12
6. Conventions used in this document.............................13
7. Security Considerations.......................................13
8. IANA Considerations...........................................13
9. Conclusions...................................................13
10. References...................................................14
10.1. Normative References....................................14
10.2. Informative References..................................14
Mihaly Expires September 9, 2015 [Page 2]
Internet-Draft Enablers for TLP evolution March 2015
11. Acknowledgments..............................................15
1. Introduction
In this document we collect requirements for TLP evolution. These
requirements are the consequence of removing obstacles of evolution.
Note that we are not after the requirements on the TLP development
as such, but rather the requirements on the eco-system that allow
fast evolution and deployment of new TLPs. When deriving the
requirements we consider the interest of all actors: users,
application developers, network operators, equipment vendors as well
as operating system vendors to result in an infrastructure where
cooperation between the parties becomes possible.
The premise of all the discussion is that TLPs need to evolve, and
potentially at a faster pace than it is allowed today. A few use
cases are collected to demonstrate the potential need for many
application and access network related TLP features that should be
available in a flexible way[FLEX].
Based on the requirements, in the second part we discuss the new
features that are needed and provide ideas to meet these
requirements.
1.1. Main obstacles to TLP evolution
The following obstacles were discussed at a related IAB workshop
[SEMI].
1.1.1. Kernel-based TLP implementations
One problem with the innovation in the TLP area is that the
transport protocols are currently implemented in the kernel. Kernel
updates are generally slow. The proprietary TLP implementations that
would require modifications of the existing transport protocols in
the clients are therefore not usable. Each new modification needs to
undergo a long standardization process, followed by a period until
it is deployed in the operating systems. This process may take
years.
The solution to this problem, which is also observed today in some
of the new TLP designs (QUIC, WebRTC), is that, instead of the
kernel, they are implemented in the application space on the top of
UDP. This is a way to speed up the innovation on the transport
protocol layer in the current eco-system.
Mihaly Expires September 9, 2015 [Page 3]
Internet-Draft Enablers for TLP evolution March 2015
1.1.2. Middleboxes
The ubiquitous deployment of middleboxes is another main reason of
what is called the 'ossification' of the transport layer. Firewalls
and NATs often inspect packets beyond the IP header and often drop
packets based on port numbers or other identified protocol and
application characteristics or, more commonly, because of non-
identified protocol characteristics. The only 100 percent 'safe'
protocol to be transmitted through middleboxes is HTTP and HTTPs
over TCP. Even the UDP-based traffic is often dropped or policed.
Note that there may be means to implement improved TLPs with framing
format embedded over the TCP layer to avoid potential problems with
middleboxes. However, this introduces additional complexity and
overhead.
Another, often neglected reason why the above approach is not
advisable is that middleboxes and the policies they enforce have an
important role in the eco-system. The internet is a critical
infrastructure a number of services are using from emergency
services to banking systems, which should therefore be protected
against misbehaving protocols. Middleboxes that filter out unknown
TLP implementations together with miss-behaving kernel-based TLP
implementations are the means to keep the Internet stable.
In conclusion, a solution is needed that lets the middleboxes not
block user space TLP implementations but in a way that protects
against miss-behaving TLPs.
2. Requirements on the TLP framework
Overcoming the abovementioned obstacles need changes in the TLP
framework. Also, when the above obstacles are overcome new
requirements result from the changed ecosystem.
2.1. Enforce expected TLP behavior
One conclusion that relates to both user space TLP implementations
and new TLP behavior is that protection is needed against buggy
and/or malicious TLP implementations. This serves the interest of
all parties and has two aspects:
. Protecting the other flows of the same user.
. Protecting the other customers using the network domain from
the potential negative effect of other traffic. One can always
gain a lot of capacity in a shared network just by being
Mihaly Expires September 9, 2015 [Page 4]
Internet-Draft Enablers for TLP evolution March 2015
aggressive. If there are no regulating network mechanisms then
both the overall network utility and fairness of assessing
network resources are compromised.
The behavior that needs to be verified in proprietary TLP
implementations is e.g., congestion control aggressiveness, packet
size, packet shaping.
2.2. Enable application access to TLPs
Introducing a proprietary TLP causes a 'walled-garden' effect, i.e.,
the new protocol with the new features is only available for the
services provided by the developer of the transport protocol.
Commercialization of the new TLPs and re-usage of open-source
implementations both support fast TLP innovation, but require that
the new TLPs SHOULD be selectable by different applications.
2.3. Allow for consistent TLP selection
While the previous requirement 2.2. relates to TLP selection within
the host, this requirement states that the framework SHOULD allow
for a consistent TLP selection for a given connection towards a
certain remote host through certain legacy paths. That is, the
finally selected TLP should be supported by the other endpoint as
well as the network domains on the path. This is to guarantee
interoperability during gradual deployment of new TLPs and their
support in the network.
2.4. Allow the path influencing TLP selection
Note that middleboxes on path may explicitly be part of the TLP
selection process. They may favor the usage of certain TLPs because
of some enhancement functions that they could offer (see discussion
in 2.6. )
2.5. Ensure expected TLP performance characteristics
By TLP performance characteristics we mean the non-functional, i.e.,
performance-related TLP features. Interactions needed for the
selection and usage of proper TLPs (including within-the-host
interactions as well as interactions with the other party and the
network domain) SHOULD not result in significant degradation of
expected TLP performance characteristics. For example, if a
transport protocol has been designed for low setup latency then this
should be preserved by introducing a framework that achieves the
above goals.
Mihaly Expires September 9, 2015 [Page 5]
Internet-Draft Enablers for TLP evolution March 2015
Note that the above requirement is strictly valid for the case when
communicating to a known party through a known network domain. In
other cases a more complex setup procedure (including e.g., the
exchange of security credentials with the other party or the
middlebox) may be needed. In some cases it MAY be also allowed that
the very first session is delayed until a proper TLP is downloaded
if one of the parties does not possess the required TLP. But such
cases should be as rare as possible, e.g., a browser downloading the
unsupported TLP once when first demand is encountered and then
storing it for future usage.
2.6. Ensure that the access providers can be part of the value chain
The framework SHALL allow access providers (ISPs and Mobile
operators) provide a cooperative middlebox environment for user
space TLP implementations. Middleboxes can generate value for the
hosts in a number of different scenarios; we direct the reader to
our recent position paper where we gave a summary of potential
middlebox roles for Mobile Broadband [MBC].
Naturally, content providers and users who are not willing to
participate in this cooperation and want to avoid any unwanted
traffic manipulation by middleboxes MUST be able to do that. Also,
the cooperation with middleboxes SHOULD be possible on different
trust levels. When there is a high trust level in a middlebox, the
middlebox should be able to access and manipulate higher layers,
i.e., TLP or application layers.
2.7. Ensure confidentiality of end-to-end communication
A valid demand from the end-users and content providers is that the
eco-system SHALL allow for confidentiality of end-to-end
communication. A trend in data communication is to encrypt
everything including the transport layer and above. However, if
middlebox communication requires access and manipulation of the TLP
fields, then object security solutions are needed to guarantee
confidentiality.
2.8. Ensure security of end-to-end communication
The framework SHOULD also make all possible actions to avoid that a
hostile entity along the path cannot cause any harm to the hosts by
exploiting the flaws in the user space TLP implementations (at least
not by using reasonable amount of processing resources).
Unfortunately it is very hard to prepare TLP implementations to be
robust against any harmful change in the protocol fields. Middlebox
interaction may however require that some of the TLP fields can be
accessed or modified by trusted middleboxes.
Mihaly Expires September 9, 2015 [Page 6]
Internet-Draft Enablers for TLP evolution March 2015
2.9. Ensure user control
It SHOULD be possible allow the users to control TLP behavior.
On the host side this means that the user may keep control on what
TLP should be selected for a certain application. Moreover, it
SHOULD be possible to control the transmission resource sharing
between the different applications or streams. Otherwise, specific
TLP behavior can override user expectations on the transmission
resource sharing and this may cause unwanted effect on the user
experience. Note that such resource sharing problems are also
apparent today e.g., file sharing using a broadband access may cause
bad Skype or video streaming experience.
The above requirement also has relevance for Middlebox
communication, i.e., the user SHOULD have the possibility to decide
what information is sent out related to a certain application or
TLP.
3. Ideas for framework evolution
3.1. API definitions for TLP selection within the host
New APIs are needed to support a consistent TLP selection as
specified in 2.3. Figure 1 depicts the new interfaces (shown by
question marks) that a user space TLP suite brings in, in addition
to the existing selection alternatives.
Mihaly Expires September 9, 2015 [Page 7]
Internet-Draft Enablers for TLP evolution March 2015
+---+ +---+ +---+ +---+ +----+
|APP| |APP| |APP| |APP| |APP |
+-^-+ +-^-+ +-^-+ +-^-+ +----+
| | | | +----+
| | | | |TLP3|
| +--v-------+ | | +-^--+
| |Middleware| | | |
| +^------^--+ | | |
| | | | | |
| | | | | |
| | +----v------------v----+ | |
| | |Protocol Selection API| | |
| | +^---------^-----------+ | |
| | | | | ? |
| | | | ? | |
| | | +-------v--------------v-+ |
| | | |(User Space TLPs) | |
| | | | | |
| | | | +----+ +----+ | |
| | | | |TLP1| |TLP2| ... | |
| | | | +----+ +----+ | |
| | | +-+----+^--+----+--------+ |
| | | | |
| | | | ? |
+-v-----v--v---------v----------------------v-+
| (Operating System) |
| +---+ +---+ |
| |TCP| |UDP| ... |
| +---+ +---+ |
+----------------------+---+---+---+----------+
Figure 1 : Transport protocol selection alternatives with User Space
transport protocol implementations
It is apparent that using middleware and high-level TLP selection
APIs (like that proposed in [TAPS]) is advantageous for a framework
involving user space TLPs since they separate application
development from TLP development and make new, innovative TLP
solutions possible also for legacy applications. However, direct
selection of TPLs by the applications should also be possible. Low-
level APIs to the new functions residing in the operating system are
also needed (see discussion in 3.2. )
Mihaly Expires September 9, 2015 [Page 8]
Internet-Draft Enablers for TLP evolution March 2015
3.2. Generic TLP related functions and APIs
It is apparent that there is some generic functionality needed
(i.e., transport layer functionality that applies on the top of the
different user space TLP flavors) in order to fulfill the
requirements in section 2. :
. Resource control component for the total transmission resources
in the host, to fulfill requirement 2.9.
. Trust API that enforces a certain trust level, i.e., controls
what different features and APIs a certain TLP has access to in
the operating system. For example, some TLPs may control the
resource control parameters, others not. This is needed because
TLPs may be designed by different parties and not every TLP
should be allowed to use all kernel functions.
. API in the operating system for time-critical processing, e.g.,
packet shaping. Time-critical processing is one functionality
that may only be done efficiently in the operating system
. A common policing function (needed to fulfill the requirements
in 2.1. and 2.9. on host side)
. Congestion control communication component with standard
framing on congestion control 'classes' (needed to fulfill the
requirements in 2.1. and 2.9. on the network side)
. Other middlebox communication component for exchanging
information about the 'service' required (to support
requirement 2.6. )
. A security function that verifies the different TLP
implementations requested and downloaded from remote sources
Note that there may be other common features and APIs required
besides those listed above. It is FFS to identify all necessary
functions.
3.3. Mechanisms for consistent TLP selection
There is a need for fast TLP identification and negotiation
mechanisms, which is derived from the requirements in 2.2. and 2.5.
, respectively. The selection mechanisms may potentially involve
middleboxes in the path. There can be many alternatives for this
which is outside the scope of this document.
The selection may include communication with a trusted part of code
at the other end, which provides some proof about the TLP
implementation.
Mihaly Expires September 9, 2015 [Page 9]
Internet-Draft Enablers for TLP evolution March 2015
3.4. Security solutions for multiple trust domains
As stipulated in 2.8. , it is important that the TLP fields should
not be easily changeable by nodes along the path because this can
help exploiting bugs in a TLP implementation. A potential solution
is to also authenticate the transport layer. However, network side
enhancements on different layers could lead to improved end-to-end
quality, as we discuss in 2.6. In some cases, this implies that the
middleboxes should be able to modify information on the transport
layer or above: transcoder proxies, parental control, TLP proxies
translating between an 'old' and a 'new' TLP, etc.
The conclusion from the above is that security solutions are needed
that enable that different entities have access to the information
at the different layers. If there is a hint on the expected
capabilities of the other end on a certain layer, the setup messages
for the different layers can be grouped together in order to speed
up the connection establishment, in the spirit of requirement 2.5.
3.5. In-band protocol for Middlebox communication
The smooth and fair networking so far has been highly aided by the
TCP/IP "narrow-waist", i.e., the assumption that all sources use
TCP-like congestion avoidance mechanisms. Misbehaving sources have
been possible to identify because of the fact that TCP wire format
(ACKs and sequence numbers) allows to identify both the congestion
signal and the congestion avoidance action, i.e., how many data is
sent upon the detection of packet losses. The proliferation of UDP-
based traffic in the network with many new features with unknown and
untested behavior could make even the simple traffic management that
guarantees that all users get their share quite troublesome.
Middleboxes may need to enforce expected behavior in the network
domain because of conflicting interests, as specified in the
requirement 2.1. A potential help in that is the identification of
the expected congestion behavior of TLPs (e.g., congestion control
used, constant bitrate flow, or chatty flow not adapting etc.) on
the network side. We recognize that any information from hosts that
would represent negative discrimination is useless, since all hosts
would evidently use the indication that implies the best treatment.
However this 'best treatment' is not obvious and the preferred
congestion treatment depends on application needs. For example, an
application using CBR-type of traffic would 'sacrifice' additional
bandwidth (e.g., by a rate-limiter in the network) for zero packet
loss provided by the network up to a certain congestion level. To
fully avoid misuse of certain congestion indicators, the network
should be able to ensure some kind of fairness for the different
Mihaly Expires September 9, 2015 [Page 10]
Internet-Draft Enablers for TLP evolution March 2015
congestion control mechanisms, to avoid scenarios where a certain
congestion behavior indicated would take more resources than others
over arbitrary period of time.
By default, when there is no indication on the congestion control
behavior used, the network could enforce a TCP-friendly behavior for
the flow, without requiring any specific knowledge about TLP
specifics (or apply a traffic treatment that result in comparable
congestion 'volumes'. However, we foresee that new TLPs providing
features tailored for specific application needs will have different
congestion control behavior. For these flows the network may enforce
a different congestion control behavior than default, given it
receives the needed information.
Middlebox communication shall be made in a way that does not impede
TLP evolution, which is likely faster than middlebox evolution. This
requires that the framework should not require that all middleboxes
should know all details (e.g., frame structure) of the TLPs. This
hints towards an in-band signaling solution as proposed in [SPUD],
where a new independent layer is introduced for middlebox
communication and where the parameters conveyed are independent from
the specific TLP used, but rather standardized information pointing
to a well-defined congestion behavior.
Communication from the middlebox towards the hosts is motivated by
the consistent TLP selection requirement 2.3. The end hosts may be
informed about middlebox capability on coping with a certain TLP to
be able to select a TLP that is supported by the network middleboxes
too.
In addition to communication about TLP congestion behavior, other
TLP capabilities could be exchanged and negotiated with a middlebox
in order to make use of some TLP enhancement functions. Such a
middlebox signaling layer also allows the endpoint convey additional
IP-layer (delay, loss targets, etc.) or application-layer (proxy,
transcoding feature negotiation etc.) information about their
traffic (if they want to) in order to enable additional services in
the spirit of the requirement 2.6. However, to support these
features, the framework should allow middleboxes to setup a
signaling connection in-band using the already setup user plane
connection in the end-to-end communication in an authenticated way
to advertise their services and communicate to the endpoints in a
secure way.
Requirement 2.5. implies that the performance overhead of the above
in-band signaling protocol should be minimal in the generic case,
and the communication setup should be fast. Certain scenarios may be
Mihaly Expires September 9, 2015 [Page 11]
Internet-Draft Enablers for TLP evolution March 2015
exception to the rule, e.g., setting up communication to a new
middlebox along a path, exchanging context to another middlebox due
to handovers, etc.
4. On open source TLP implementations
Open source implementation may facilitate TLP evolution. The user
space TLP (feature) implementations become faster, allowing smaller
players leverage on the existing features that are designed and
validated by bigger players. This may be further facilitated by pre-
agreed software design rules for TLPs.
However, the eco-system should allow also for non-open source.
Firstly, because nothing would prevent big players come out with
their own user space implementations. Further, it creates a
competitive eco-system allowing e.g., start-ups to design and
commercialize new proprietary TLP implementations. This helps
innovation.
In conclusion, open source does not bring in any specific
requirements to the eco-system compared to other user space
implementations. However, there could be TLP designs that facilitate
re-use of open source and thus contribute to faster TLP evolution.
5. Related work
There is an on-going activity and WG in IETF targeting the
definition of a transport-layer interface exposed to the
applications, on which, instead of specifying a protocol, a
'transport service' is specified [TAPS]. The primary scope for the
activity is to make it possible to select the best transport
protocol implementation for the applications, i.e., to use the
existing transport protocol implementations in the clients, which
are currently never of seldom used.
There is also an EU horizon 2020 activity proposal with similar
scope proposing to solve issues for NAT traversal, Path MTU
discovery and falling back to a semantically-equivalent service in
the selection layer, i.e., completely hidden from the application
[NEAT] . As mentioned above, TLP selection layers are advantageous
since they separate application development from TLP development.
However, they should consider the framework extensions identified in
this document.
The recently formed IAB program [SEMI] and resulting BoF discussions
[SPUD] started from the very same understanding that middleboxes in
the network have expectations on the packet and flow structures,
Mihaly Expires September 9, 2015 [Page 12]
Internet-Draft Enablers for TLP evolution March 2015
which block TLP evolution. The workshop held in January 2015
identified that a mechanism is needed for applications at the end as well
as boxes along the path to explicitly declare their assumptions and
intentions. The design goals identified in this document for such a
communication are intended to serve as input to the protocol discussion.
6. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
7. Security Considerations
We argue in 2.7. 2.8. and 3.4. that other means that end-to-end
encryption mechanisms involving the transport layer are necessary to
address middlebox communication and also ensure the confidentiality
and integrity of end-to-end communication.
Exposing additional information to kernel functions and also to the
network middleboxes raises a number of security questions about what
should be exposed, how should be exposed etc. The present document
does not address these issues, but they should be talked in future
framework discussions.
8. IANA Considerations
This draft presently does not pose any requirements to IANA.
9. Conclusions
In this document we collected requirements for TLP evolution. These
requirements are the consequence of removing obstacles of evolution.
This results in a higher variety of expected TLP implementations and
lower trust level in these. With the evolved TLPs even better
performance is expected. Confidentiality of communication and
security is more and more important. Middleboxes which today are one
of the obstacles of the evolution shall be taken into account and
incentivized to cooperate in the future landscape.
Mihaly Expires September 9, 2015 [Page 13]
Internet-Draft Enablers for TLP evolution March 2015
Resulting from the requirements we have identified the following
ideas for further investigation.
. API definitions for TLP selection within the host
. Generic TLP related functions and APIs
. Mechanisms for consistent TLP selection
. Security solutions for multiple trust domains
. In-band protocol for Middlebox communication
We would like to invite the community to complete this analysis
based on potential missing pieces of the problem space to address,
further requirements, or further design goals that are useful for
fast TLP evolution.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[FLEX] Flexibility of Transport Layer Protocols: Problem Statement
draft-mihaly-TP-flexibility-00.txt
[TAPS] Transport Services Charter,
https://datatracker.ietf.org/doc/charter-ietf-taps/
[NEAT] A New, Evolutive API and Transport Architecture for the
Internet (NEAT), project proposal to Call ICT 5-2014
'Smart Networks and Novel Internet Architectures", on the
Horizon 2020 Work programme
[SEMI] IAB Workshop on Stack Evolution in a Middlebox Internet
(SEMI), http://www.iab.org/activities/workshops/semi/
[SPUD] A new BoF called 'Session Protocol for User Datagrams'
(SPUD) is proposed for IETF92, see
http://trac.tools.ietf.org/bof/trac/#Transport Stack. The
background of it has been discussed in a recent IAB
workshop 'Evolution in a Middlebox Internet' (SEMI), see
https://www.iab.org/activities/workshops/semi/
Mihaly Expires September 9, 2015 [Page 14]
Internet-Draft Enablers for TLP evolution March 2015
[MBC] Nadas, S. and Loreto, S: Middleboxes in Cellular Networks,
position paper to SEMI WorkShop, https://www.iab.org/wp-
content/IAB-uploads/2014/12/semi2015_nadas.pdf
11. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2015 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Mihaly Expires September 9, 2015 [Page 15]
Internet-Draft Enablers for TLP evolution March 2015
Authors' Addresses
Attila Mihaly
Ericsson
H-1117 Budapest, Irinyi Jozsef u 4-20, Hungary
Email: Attila.Mihaly@ericsson.com
Szilveszter Nadas
Ericsson
H-1117 Budapest, Irinyi Jozsef u 4-20, Hungary
Email: Szilveszter.Nadas@ericsson.com
Mihaly Expires September 9, 2015 [Page 16]
