doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc7778.txt b/doc/rfc/rfc7778.txt
new file mode 100644
index 0000000..ae13815
--- /dev/null
+++ b/doc/rfc/rfc7778.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       D. Kutscher
+Request for Comments: 7778                                        F. Mir
+Category: Informational                                        R. Winter
+ISSN: 2070-1721                                                      NEC
+                                                             S. Krishnan
+                                                                Ericsson
+                                                                Y. Zhang
+                                                    Hewlett Packard Labs
+                                                           CJ. Bernardos
+                                                                    UC3M
+                                                              March 2016
+
+
+           Mobile Communication Congestion Exposure Scenario
+
+Abstract
+
+   This memo describes a mobile communications use case for congestion
+   exposure (ConEx) with a particular focus on those mobile
+   communication networks that are architecturally similar to the 3GPP
+   Evolved Packet System (EPS).  This memo provides a brief overview of
+   the architecture of these networks (both access and core networks)
+   and current QoS mechanisms and then discusses how congestion exposure
+   concepts could be applied.  Based on this discussion, this memo
+   suggests a set of requirements for ConEx mechanisms that particularly
+   apply to these mobile networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7778.
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 1]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  ConEx Use Cases in Mobile Communication Networks  . . . . . .   4
+     2.1.  ConEx as a Basis for Traffic Management . . . . . . . . .   5
+     2.2.  ConEx to Incentivize Scavenger Transports . . . . . . . .   7
+     2.3.  Accounting for Congestion Volume  . . . . . . . . . . . .   7
+     2.4.  Partial vs. Full Deployment . . . . . . . . . . . . . . .   8
+     2.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   9
+   3.  ConEx in the EPS  . . . . . . . . . . . . . . . . . . . . . .   9
+     3.1.  Possible Deployment Scenarios . . . . . . . . . . . . . .   9
+     3.2.  Implementing ConEx Functions in the EPS . . . . . . . . .  14
+       3.2.1.  ConEx Protocol Mechanisms . . . . . . . . . . . . . .  15
+       3.2.2.  ConEx Functions in the Mobile Network . . . . . . . .  15
+   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
+   6.  Informative References  . . . . . . . . . . . . . . . . . . .  19
+   Appendix A.  Overview of 3GPP's EPS . . . . . . . . . . . . . . .  22
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 2]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+1.  Introduction
+
+   Mobile data traffic continues to grow rapidly.  The challenge
+   wireless operators face is to support more subscribers with an
+   increasing bandwidth demand.  To meet these bandwidth requirements,
+   there is a need for new technologies that assist the operators in
+   efficiently utilizing the available network resources.  Two specific
+   areas where such new technologies could be deemed useful are resource
+   allocation and flow management.
+
+   Analysis of data traffic in cellular networks has shown that most
+   flows are short lived and low volume, but a comparatively small
+   number of high-volume flows constitute a large fraction of the
+   overall traffic volume [lte-sigcomm2013].  That means that
+   potentially a small fraction of users is responsible for the majority
+   of traffic in cellular networks.  In view of such highly skewed user
+   behavior and limited and expensive resources (e.g., the wireless
+   spectrum), resource allocation and usage accountability are two
+   important issues for operators to solve in order to achieve both a
+   better network resource utilization and fair resource sharing.
+   ConEx, as described in [RFC6789], is a technology that can be used to
+   achieve these goals.
+
+   The ConEx mechanism is designed to be a general technology that could
+   be applied as a key element of congestion management solutions for a
+   variety of use cases.  In particular, use cases that are of interest
+   for initial deployment are those in which the end hosts and the
+   network that contains the destination end hosts are ConEx-enabled but
+   other networks need not be.
+
+   A specific example of such a use case can be a mobile communication
+   network such as a 3GPP EPS networks where UEs (User Equipment) (i.e.,
+   mobile end hosts), servers and caches, the access network, and
+   possibly an operator's core network can be ConEx-enabled; that is,
+   hosts support the ConEx mechanisms, and the network provides
+   policing/auditing functions at its edges.
+
+   This document provides a brief overview of the architecture of such
+   networks (access and core networks) and current QoS mechanisms.  It
+   further discusses how such networks can benefit from congestion
+   exposure concepts and how they should be applied.  Using this use
+   case as a basis, a set of requirements for ConEx mechanisms are
+   described.
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 3]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+1.1.  Acronyms
+
+   In this section, we expand some acronyms that are used throughout the
+   text.  Most are explained and put in a system context in Appendix A
+   and the 3GPP, ECN, and ConEx specifications referenced there.
+
+   eNB
+      Evolved NodeB: LTE base station
+
+   HSS
+      Home Subscriber Server
+
+   S-GW
+      Serving Gateway: mobility anchor and tunnel endpoint
+
+   P-GW
+      Packet Data Network (PDN) Gateway: tunnel endpoint for user-plane
+      and control-plane protocols -- typically the GW to the Internet or
+      an operator's service network
+
+   UE
+      User Equipment: mobile terminals
+
+   GTP
+      GPRS Tunneling Protocol [TS29060]
+
+   GTP-U
+      GTP User Data Tunneling [TS29060]
+
+   GTP-C
+      GTP Control [TS29060]
+
+2.  ConEx Use Cases in Mobile Communication Networks
+
+   In general, quality of service and good network resource utilization
+   are important requirements for mobile communication network
+   operators.  Radio access and backhaul capacity are considered scarce
+   resources, and bandwidth (and radio resource) demand is difficult to
+   predict precisely due to user mobility, radio propagation effects,
+   etc.  Hence, today's architectures and protocols go to significant
+   lengths in order to provide network-controlled quality of service.
+   These efforts often lead to complexity and cost.  ConEx could be a
+   simpler and more capable approach to efficient resource sharing in
+   these networks.
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 4]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   In the following sections, we discuss ways that congestion exposure
+   could be beneficial for supporting resource management in such mobile
+   communication networks.  [RFC6789] describes fundamental congestion
+   exposure concepts and a set of use cases for applying congestion
+   exposure mechanisms to realize different traffic management functions
+   such as flow policy-based traffic management or traffic offloading.
+   Readers that are not familiar with the 3GPP EPS should refer to
+   Appendix A first.
+
+2.1.  ConEx as a Basis for Traffic Management
+
+   Traffic management is a very important function in mobile
+   communication networks.  Since wireless resources are considered
+   scarce and since user mobility and shared bandwidth in the wireless
+   access create certain dynamics with respect to available bandwidth,
+   commercially operated mobile networks provide mechanisms for tight
+   resource management (admission control for bearer establishment).
+   However, sometimes these mechanisms are not easily applicable to IP-
+   and HTTP-dominated traffic mixes; for example, most Internet traffic
+   in today's mobile network is transmitted over the (best-effort)
+   default bearer.
+
+   Given the above, and in the light of the significant increase of
+   overall data volume in 3G networks, Deep Packet Inspection (DPI) is
+   often considered a desirable function to have in the Evolved Packet
+   Core (EPC) -- despite its cost and complexity.  However, with the
+   increase of encrypted data traffic, traffic management using DPI
+   alone will become even more challenging.
+
+   Congestion exposure can be employed to address resource management
+   requirements in different ways:
+
+   1.  It can enable or enhance flow policy-based traffic management.
+       At present, DPI-based resource management is often used to
+       prioritize certain application classes with respect to others in
+       overload situations, so that more users can be served effectively
+       on the network.  In overload situations, operators use DPI to
+       identify dispensable flows and make them yield to other flows (of
+       different application classes) through policing.  Such traffic
+       management is thus based on operator decisions, using partly
+       static configuration and some estimation about the future per-
+       flow bandwidth demand.  With congestion exposure, it would be
+       possible to assess the contribution to congestion of individual
+       flows.  This information can then be used as input to a policer
+       that can optimize network utilization more accurately and
+       dynamically.  By using ConEx congestion contribution as a metric,
+       such policers would not need to be aware of specific link loads
+       (e.g., in wireless base stations) or flow application types.
+
+
+
+Kutscher, et al.              Informational                     [Page 5]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   2.  It can reduce the need for complex DPI by allowing for a bulk
+       packet traffic management system that does not have to consider
+       either the application classes flows belong to or the individual
+       sessions.  Instead, traffic management would be based on the
+       current cost (contribution to congestion) incurred by different
+       flows and enable operators to apply policing/accounting depending
+       on their preference.  Such traffic management would be simpler
+       and more robust (no real-time flow application type
+       identification required, no static configuration of application
+       classes); it would also perform better as decisions can be made
+       based on real-time actual cost contribution.  With ConEx,
+       accurate downstream path information would be visible to ingress
+       network operators, which can respond to incipient congestion in
+       time.  This can be equivalent to offering different levels of
+       QoS, e.g., premium service with zero congestion response.  For
+       that, ConEx could be used in two different ways:
+
+       A.  as additional information to assist network functions to
+           impose different QoS for different application sessions; and
+
+       B.  as a tool to let applications decide on their response to
+           congestion notification while incentivizing them to react (in
+           general) appropriately, e.g., by enforcing overall limits for
+           congestion contribution or by accounting and charging for
+           such congestion contribution.  Note that this level of
+           responsiveness would be on a different level than, say,
+           application-layer responsiveness in protocols such as Dynamic
+           Adaptive Streaming over HTTP (DASH) [dash]; however, it could
+           interwork with such protocols, for example, by triggering
+           earlier responses.
+
+   3.  It can further be used to more effectively trigger the offload of
+       selected traffic to a non-3GPP network.  Nowadays, it is common
+       that users are equipped with dual-mode mobile phones (e.g.,
+       integrating third/fourth generation cellular and Wi-Fi radio
+       devices) capable of attaching to available networks either
+       sequentially or simultaneously.  With this scenario in mind, 3GPP
+       is currently looking at mechanisms to seamlessly and selectively
+       switch over a single IP flow (e.g., user application) to a
+       different radio access while keeping all other ongoing
+       connections untouched.  The decision on when and which IP flows
+       move is typically based on statically configured rules, whereas
+       the use of ConEx mechanisms could also factor real-time
+       congestion information into the decision.
+
+   In summary, it can be said that traffic management in the 3GPP EPS
+   and other mobile communication architectures is very important.
+   Currently, more static approaches based on admission control and
+
+
+
+Kutscher, et al.              Informational                     [Page 6]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   static QoS are in use, but recently, there has been a perceived need
+   for more dynamic mechanisms based on DPI.  Introducing ConEx could
+   make these mechanisms more efficient or even remove the need for some
+   of the DPI functions deployed today.
+
+2.2.  ConEx to Incentivize Scavenger Transports
+
+   3G and LTE networks are turning into universal access networks that
+   are shared between mobile (smart) phone users, mobile users with
+   laptop PCs, home users with LTE access, and others.  Capacity sharing
+   among different users and application flows becomes increasingly
+   important in these mobile communication networks.
+
+   Most of this traffic is likely to be classified as best-effort
+   traffic without differentiating, for example, periodic OS updates and
+   application store downloads from web-based (i.e., browser-based)
+   communication or other real-time communication.  For many of the bulk
+   data transfers, completion times are not important within certain
+   bounds; therefore, if scavenger transports (or transports that are
+   less than best effort) such as Low Extra Delay Background Transport
+   (LEDBAT) [RFC6817] were used, it would improve the overall utility of
+   the network.  The use of these transports by the end user, however,
+   needs to be incentivized.  ConEx could be used to build an incentive
+   scheme, e.g., by giving a larger bandwidth allowance to users that
+   contribute less to congestion or lowering the next monthly
+   subscription fee.  In principle, this would be possible to implement
+   with current specifications.
+
+2.3.  Accounting for Congestion Volume
+
+   3G and LTE networks provide extensive support for accounting and
+   charging already, for example, see the Policy Charging Control (PCC)
+   architecture [TS23203].  In fact, most operators today account
+   transmitted data volume on a very fine granular basis and either
+   correlate monthly charging to the exact number of packets/bytes
+   transmitted or employ some form of flat rate (or flexible flat rate),
+   often with a so-called fair-use policy.  With such policies, users
+   are typically limited to an administratively configured maximum
+   bandwidth limit after they have used up their contractual data volume
+   budget for the charging period.
+
+   Changing this data from volume-based accounting to congestion-based
+   accounting would be possible in principle, especially since there
+   already is an elaborate per-user accounting system available.  Also,
+   an operator-provided mobile communication network can be seen as a
+   network domain that would allow for such congestion volume
+   accounting.  This would not require any support from the global
+   Internet, especially since the typical scarce resources such as the
+
+
+
+Kutscher, et al.              Informational                     [Page 7]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   wireless access and the mobile backhaul are all within this domain.
+   Traffic normally leaves/enters the operator's network via well-
+   defined egress/ingress points that would be ideal candidates for
+   policing functions.  Moreover, in most commercially operated
+   networks, accounting is performed for both received and sent data,
+   which would facilitate congestion volume accounting as well.
+
+   With respect to the current Path Computation Client (PCC) framework,
+   accounting for congestion volume could be added as another feature to
+   the "Usage Monitoring Control" capability that is currently based on
+   data volume.  This would not require a new interface (reference
+   points) at all.
+
+2.4.  Partial vs. Full Deployment
+
+   In general, ConEx lends itself to partial deployment as the mechanism
+   does not require all routers and hosts to support congestion
+   exposure.  Moreover, assuming a policing infrastructure has been put
+   in place, it is not required to modify all hosts.  Since ConEx is
+   about senders exposing congestion contribution to the network,
+   senders need to be made ConEx-aware (assuming a congestion
+   notification mechanism such as Explicit Congestion Notification (ECN)
+   is in place).
+
+   When moving towards full deployment in a specific operator's network,
+   different ways for introducing ConEx support on UEs are feasible.
+   Since mobile communication networks are multi-vendor networks,
+   standardizing ConEx support on UEs (e.g., in 3GPP specifications)
+   appears useful.  Still, not all UEs would have to support ConEx, and
+   operators would be free to choose their policing approach in such
+   deployment scenarios.  Leveraging existing PCC architectures, 3GPP
+   network operators could, for example, decide policing/accounting
+   approaches per UE -- i.e., apply fixed volume caps for non-ConEx UEs
+   and more flexible schemes for ConEx-enabled UEs.
+
+   Moreover, it should be noted that network support for ConEx is a
+   feature that some operators may choose to deploy if they wish, but it
+   is not required that all operators (or all other networks) do so.
+
+   Depending on the extent of ConEx support, specific aspects such as
+   roaming have to be taken into account, i.e., what happens when a user
+   is roaming in a ConEx-enabled network but their UE is not ConEx-
+   enabled and vice versa.  Although these may not be fundamental
+   problems, they need to be considered.  For supporting mobility in
+   general, it can be required to shift users' policing state during a
+   handover.  There is existing work on distributed rate limiting (see
+   [raghavan2007]) and on specific optimizations (see [nec.euronf-2011])
+   for congestion exposure and policing in mobility scenarios.
+
+
+
+Kutscher, et al.              Informational                     [Page 8]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   Another aspect to consider is the addition of Selected IP Traffic
+   Offload (SIPTO) and Local IP Access (LIPA) [TR23829]), i.e., the idea
+   that some traffic such as high-volume Internet traffic is actually
+   not passed through the EPC but is offloaded at a "break-out point"
+   closer to (or in) the access network.  On the other hand, ConEx can
+   also enable more dynamic decisions on what traffic to actually
+   offload by considering congestion exposure in bulk traffic
+   aggregates, thus making traffic offload more effective.
+
+2.5.  Summary
+
+   In summary, the 3GPP EPS is a system architecture that can benefit
+   from congestion exposure in multiple ways.  Dynamic traffic and
+   congestion management is an acknowledged and important requirement
+   for the EPS; this is also illustrated by the current DPI-related work
+   for EPS.
+
+   Moreover, networks such as an EPS mobile communication network would
+   be quite amenable for deploying ConEx as a mechanism, since they
+   represent clearly defined and well-separated operational domains in
+   which local ConEx deployment would be possible.  Aside from roaming
+   (which needs to be considered for a specific solution), such a
+   deployment is fully under the control of a single operator, which can
+   enable operator-local enhancement without the need for major changes
+   to the architecture.
+
+   In 3GPP EPS, interfaces between all elements of the architecture are
+   subject to standardization, including UE interfaces and eNB
+   interfaces, so that a more general approach, involving more than a
+   single operator's network, can be feasible as well.
+
+3.  ConEx in the EPS
+
+   In this section, we discuss a few options for how such a mechanism
+   (and possibly additional policing functions) could eventually be
+   deployed in the 3GPP EPS.  Note that this description of options is
+   not intended to be a complete set of possible approaches; it merely
+   discusses the most promising options.
+
+3.1.  Possible Deployment Scenarios
+
+   There are different possible ways for how ConEx functions on hosts
+   and network elements can be used.  For example, ConEx could be used
+   for a limited part of the network only (e.g., for the access
+   network), congestion exposure and sender adaptation could involve the
+   mobile nodes or not, or, finally, the ConEx feedback loop could
+   extend beyond a single operator's domain or not.
+
+
+
+
+Kutscher, et al.              Informational                     [Page 9]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   We present four different deployment scenarios for congestion
+   exposure in the figures below:
+
+   1.  In Figure 1, ConEx is supported by servers for sending data (web
+       servers in the Internet and caches in an operator's network) but
+       not by UEs (neither for receiving nor sending).  An operator who
+       chooses to run a policing function on the network ingress, e.g.,
+       on the P-GW, can still benefit from congestion exposure without
+       requiring any change on UEs.
+
+   2.  ConEx is universally employed between operators (as depicted in
+       Figure 2) with an end-to-end ConEx feedback loop.  Here,
+       operators could still employ local policies, congestion
+       accounting schemes, etc., and they could use information about
+       congestion contribution for determining interconnection
+       agreements.  This deployment scenario would imply the willingness
+       of operators to expose congestion to each other.
+
+   3.  For Isolated ConEx domains as depicted in Figure 3, ConEx is
+       solely applied locally in the operator network, and there is no
+       end-to-end congestion exposure.  This could be the case when
+       ConEx is only implemented in a few networks or when operators
+       decide to not expose ECN and account for congestion for inter-
+       domain traffic.  Independent of the actual scenario, it is likely
+       that there will be border gateways (as in today's deployments)
+       that are associated with policing and accounting functions.
+
+   4.  [conex-lite] describes an approach called "ConEx Lite" for mobile
+       networks that is intended for initial deployment of congestion
+       exposure concepts in LTE, specifically in the backhaul and core
+       network segments.  As depicted in Figure 4, ConEx Lite allows a
+       tunnel receiver to monitor the volume of bytes that has been
+       lost, dropped, or ECN-CE (Congestion Experienced) marked between
+       the tunnel sender and receiver.  For that purpose, a new field
+       called the Byte Sequence Marker (BSN) is introduced to the tunnel
+       header to identify the byte in the flow of data from the tunnel
+       sender to the tunnel receiver.  A policer at the tunnel sender is
+       expected to react according to the tunnel congestion volume (see
+       [conex-lite] for details).
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 10]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+                                     +------------+
+                                     | Web server |
+                                     | w/ ConEx   |
+                                     +------------+
+                                               |
+                                               |
+                                               |
+                            -----------------------
+                            |                  |  |
+                            |     Internet     |  |
+                            |                  |  |
+                            -----------------------
+                                               |
+   --------------------------------------------|--------
+   |                                           |       |
+   |                                     +-----------+ |
+   |                                     | Web cache | |
+   |                                     | w/ ConEx  | |
+   |                                     +-----------+ |
+   |                                           |       |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |  | UE |=====|  eNB  |=====|  S-GW |=====|  P-GW | |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |                                                   |
+   |              Operator A                           |
+   -----------------------------------------------------
+
+               Figure 1: ConEx Support on Servers and Caches
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 11]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   -----------------------------------------------------
+   |  +----+     +-------+     +-------+     +-------+ |
+   |  | UE |=====|  eNB  |=====|  S-GW |=====|  P-GW | |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |                                           |       |
+   |              Operator A                   |       |
+   --------------------------------------------|--------
+                                               |
+                            -----------------------
+                            |                     |
+                            |     Internet        |
+                            |                     |
+                            -----------------------
+                                               |
+   --------------------------------------------|--------
+   |  +----+     +-------+     +-------+     +-------+ |
+   |  | UE |=====|  eNB  |=====|  S-GW |=====|  P-GW | |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |                                                   |
+   |              Operator B                           |
+   -----------------------------------------------------
+
+            Figure 2: ConEx Deployment across Operator Domains
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 12]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   -----------------------------------------------------
+   |   |---            ConEx path            ---|      |
+   |   v                                        v      |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |  | UE |=====|  eNB  |=====|  S-GW |=====|  P-GW | |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |                                           |       |
+   |              Operator A                   |       |
+   --------------------------------------------|--------
+                                               |
+                            -----------------------
+                            |                     |
+                            |     Internet        |
+                            |                     |
+                            -----------------------
+                                               |
+   --------------------------------------------|--------
+   |  +----+     +-------+     +-------+     +-------+ |
+   |  | UE |=====|  eNB  |=====|  S-GW |=====|  P-GW | |
+   |  +----+     +-------+     +-------+     +-------+ |
+   |                                                   |
+   |              Operator B                           |
+   -----------------------------------------------------
+
+          Figure 3: ConEx Deployment in a Single Operator Domain
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 13]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+                   Backhaul Network     Core Network
+                  +---------------+  +--------------+
+                  |               |  |              |
+                  | BSN or ECN-CE |  |              |
+                  | marked        |  |              |
+                  | packets       |  |              |
+                  |    <---       |  |              |
+   +----+     +-------+       +----------+       +-------+  +--------+
+   |    |     |       | GTP-U |          | GTP-U |       |  |        |
+   | UE |=====|  eNB  |=======|   S-GW   |=======|  P-GW |==|Internet|
+   |    |     |       | Tunnel|          | Tunnel|       |  |        |
+   +----+     +-------+       +----------+       +-------+  +--------+
+                  |    --->       |  |              |
+                  | User/control  |  | User/control |
+                  | packets with  |  | packet with  |
+                  | DL congestion |  | DL congestion|
+                  | vol counters  |  | vol counters |
+                  |               |  |              |
+                  +---------------+  +--------------+
+
+                      Figure 4: ConEx Lite Deployment
+
+   Note: DL stands for "downlink".
+
+3.2.  Implementing ConEx Functions in the EPS
+
+   We expect a ConEx solution to consist of different functions that
+   should be considered when implementing congestion exposure in the
+   3GPP EPS.  [RFC7713] describes the following congestion exposure
+   components:
+
+   o  Modified senders that send congestion exposure information in
+      response to congestion feedback.
+
+   o  Receivers that generate congestion feedback (leveraging existing
+      behavior or requiring new functions).
+
+   o  Audit functions that audit ConEx signals against actual
+      congestion, e.g., by monitoring flows or aggregate of flows.
+
+   o  Policy devices that monitor congestion exposure information and
+      act on the flows according to the operator's policy.
+
+   Two aspects are important to consider: 1) how the ConEx protocol
+   mechanisms would be implemented and what modifications to existing
+   networks would be required, and 2) where ConEx functional entities
+   would be placed best (to allow for a non-invasive addition).  We
+   discuss these two aspects in the following sections.
+
+
+
+Kutscher, et al.              Informational                    [Page 14]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+3.2.1.  ConEx Protocol Mechanisms
+
+   The most important step in introducing ConEx (initially) is adding
+   the congestion exposure functionality to senders.  For an initial
+   deployment, no further modification to senders and receivers would be
+   required.  Specifically, there is no fundamental dependency on ECN,
+   i.e., ConEx can be introduced without requiring ECN to be
+   implemented.
+
+   Congestion exposure information for IPv6 [CONEX-DESTOPT] is contained
+   in a destination option header field, which requires minimal changes
+   at senders and nodes that want to assess path congestion.  The
+   destination option header field does not affect non-ConEx nodes in a
+   network.
+
+   In 3GPP networks, IP tunneling is used intensively, i.e., using
+   either IP-in-GTP-U or Proxy Mobile IPv6 (PMIPv6) (i.e., IP-in-IP)
+   tunnels.  In general, the ConEx destination option of encapsulated
+   packets should be made available for network nodes on the tunnel
+   path, i.e., a tunnel ingress should copy the ConEx destination option
+   field to the outer header.
+
+   For effective and efficient capacity sharing, we envisage the
+   deployment of ECN in conjunction with ConEx so that ECN-enabled
+   receivers and senders get more accurate and more timely information
+   about the congestion contribution of their flows.  ECN is already
+   partially introduced into 3GPP networks: Section 11.6 in [TS36300]
+   specifies the usage of ECN for congestion notification on the radio
+   link (between eNB and UE), and [TS26114] specifies how this can be
+   leveraged for voice codec adaptation.  A complete, end-to-end support
+   of ECN would require specification of tunneling behaviour, which
+   should be based on [RFC6040] (for IP-in-IP tunnels).  Specifically, a
+   specification for tunneling ECN in GTP-U will be needed.
+
+3.2.2.  ConEx Functions in the Mobile Network
+
+   In this section, we discuss some possible placement strategies for
+   ConEx functional entities (addressing both policing and auditing
+   functions) in the EPS and for possible optimizations for both the
+   uplink and the downlink.
+
+   In general, ConEx information (exposed congestion) is declared by a
+   sender and remains unchanged on the path; hence, reading ConEx
+   information (e.g., by policing functions) is placement-agnostic.
+   Auditing ConEx normally requires assessing declared congestion
+   contribution and current actual congestion.  If the latter is, for
+   example, done using ECN, such a function would best be placed at the
+   end of the path.
+
+
+
+Kutscher, et al.              Informational                    [Page 15]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   In order to provide a comprehensive ConEx-based capacity management
+   framework for the EPS, it would be advantageous to consider user
+   contribution to congestion for both the radio access and the core
+   network.  For a non-invasive introduction of ConEx, it can be
+   beneficial to combine ConEx functions with existing logical EPS
+   entities.  For example, potential places for ConEx policing and
+   auditing functions would then be eNBs, S-GWs, or the P-GWs.  Operator
+   deployments may, of course, still provide additional intermediary
+   ConEx-enabled IP network elements.
+
+   For a more specific discussion, it will be beneficial to distinguish
+   downlink and uplink traffic directions (also see [nec.globecom2010]
+   for a more detailed discussion).  In today's networks and usage
+   models, downlink traffic is dominating (also reflected by the
+   asymmetric capacity provided by the LTE radio interface).  That does
+   not, however, imply that uplink congestion is not an issue, since the
+   asymmetric maximum bandwidth configuration can create a smaller
+   bottleneck for uplink traffic.  There are, of course, backhaul links,
+   gateways, etc., that could be overloaded as well.
+
+   For managing downlink traffic (e.g., in scenarios such as the one
+   depicted in Figure 1), operators can have different requirements for
+   policing traffic.  Although policing is, in principle, location-
+   agnostic, it is important to consider requirements related to the EPS
+   architecture (Figure 5) such as tunneling between P-GWs and eNBs.
+   Policing can require access to subscriber information (e.g.,
+   congestion contribution quota) or user-specific accounting, which
+   suggests that the ConEx function could be co-located with the P-GW
+   that already has an interface towards the Policy and Charging Rule
+   Function (PCRF).
+
+   Still, policing can serve different purposes.  For example, if the
+   objective is to police bulk traffic induced by peer networks,
+   additional monitoring functions can be placed directly at
+   corresponding ingress points to monitor traffic and possibly drive
+   out-of-band functions such as triggering border contract penalties.
+
+   The auditing function, which should be placed at the end of the path
+   (at least after/at the last bottleneck), would likely be placed best
+   on the eNB (wireless base station).
+
+   For the uplink direction, there are naturally different options for
+   designing monitoring and policy enforcement functions.  A likely
+   approach can be to monitor congestion exposure on central gateway
+   nodes (such as P-GWs) that provide the required interfaces to the
+   PCRF but to perform policing actions in the access network (i.e., in
+   eNBs).  For example, the traffic is policed at the ingress before it
+   reaches concentration points in the core network.
+
+
+
+Kutscher, et al.              Informational                    [Page 16]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   Such a setup would enable all the ConEx use cases described in
+   Section 2 without requiring significant changes to the EPS
+   architecture.  It would also enable operators to re-use existing
+   infrastructure, specifically wireless base stations, PCRF, and Home
+   Subscriber Server (HSS) systems.
+
+   For ConEx functions on elements such as the S-GWs and P-GWs, it is
+   important to consider mobility and tunneling protocol requirements.
+   LTE provides two alternative approaches: PMIPv6 [TS23402] and the
+   GPRS Tunneling Protocol (GTP).  For the propagation of congestion
+   information (responses), tunneling considerations are therefore very
+   important.
+
+   In general, policing will be done based on per-user (per-subscriber)
+   information such as congestion quota, current quota usage, etc., and
+   network operator policies, e.g., specifying how to react to
+   persistent congestion contribution.  In the EPS, per-user information
+   is normally part of the user profile (stored in the HSS) that would
+   be accessed by PCC entities such as the PCRF for dynamic updates,
+   enforcement, etc.
+
+4.  Summary
+
+   We have shown how congestion exposure can be useful for efficient
+   resource management in mobile communication networks.  The premise
+   for this discussion was the observation that data communication,
+   specifically best-effort bulk data transmission, is becoming a
+   commodity service, whereas resources are obviously still limited.
+   This calls for efficient, scalable, and yet effective capacity
+   sharing in such networks.
+
+   ConEx can be a mechanism that enables such capacity sharing while
+   allowing operators to apply these mechanisms in different ways, e.g.,
+   for implementing different use cases as described in Section 2.  It
+   is important to note that ConEx is fundamentally a mechanism that can
+   be applied in different ways to realize the policies of different
+   operators.
+
+   ConEx may also be used to complement 3GPP-based mechanisms for
+   congestion management that are currently under development, such as
+   in the User Plane Congestion Management (UPCON) work item described
+   in [TR23705].
+
+   We have described a few possibilities for adding ConEx as a mechanism
+   to 3GPP LTE-based networks and have shown how this could be done
+   incrementally (starting with partial deployment).  It is quite
+   feasible that such partial deployments be done on a per-operator-
+   domain basis without requiring changes to standard 3GPP interfaces.
+
+
+
+Kutscher, et al.              Informational                    [Page 17]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   For network-wide deployment, e.g., with congestion exposure between
+   operators, more considerations might be needed.
+
+   We have also identified a few implications/requirements that should
+   be taken into consideration when enabling congestion exposure in such
+   networks:
+
+   Performance:  In mobile communication networks with more expensive
+      resources and more stringent QoS requirements, the feasibility of
+      applying ConEx as well as its performance and deployment scenarios
+      need to be examined closer.  For instance, a mobile communication
+      network may encounter longer delay and higher loss rates, which
+      can impose specific requirements on the timeliness and accuracy of
+      congestion exposure information.
+
+   Mobility:  One of the unique characteristics of cellular networks
+      when compared to wired networks is the presence of user mobility.
+      As the user location changes, the same device can be connected to
+      the network via different base stations (eNBs) or even go through
+      switching gateways.  Thus, the ConEx scheme must to be able to
+      carry the latest congestion information per user/flow across
+      multiple network nodes in real time.
+
+   Multi-access:  In cellular networks, multiple access technologies can
+      co-exist.  In such cases, a user can use multiple access
+      technologies for multiple applications or even a single
+      application simultaneously.  If the congestion policies are set
+      based on each user, then ConEx should have the capability to
+      enable information exchange across multiple access domains.
+
+   Tunneling:  Both 3G and LTE networks make extensive usage of
+      tunneling.  The ConEx mechanism should be designed in a way to
+      support usage with different tunneling protocols such as PMIPv6
+      and GTP.  For ECN-based congestion notification, [RFC6040]
+      specifies how the ECN field of the IP header should be constructed
+      on entry and exit from IP-in-IP tunnels.
+
+   Roaming:  Independent of the specific architecture, mobile
+      communication networks typically differentiate between non-roaming
+      and roaming scenarios.  Roaming scenarios are typically more
+      demanding regarding implementing operator policies, charging, etc.
+      It can be expected that this would also hold for deploying ConEx.
+      A more detailed analysis of this problem will be provided in a
+      future revision of this document.
+
+   It is important to note that ConEx is intended to be used as a
+   supplement and not a replacement to the existing QoS mechanisms in
+   mobile networks.  For example, ConEx deployed in 3GPP mobile networks
+
+
+
+Kutscher, et al.              Informational                    [Page 18]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   can provide useful input to the existing 3GPP PCC mechanisms by
+   supplying more dynamic network information to supplement the fairly
+   static information used by the PCC.  This would enable the mobile
+   network to make better policy control decisions than is possible with
+   only static information.
+
+5.  Security Considerations
+
+   For any ConEx deployment, it is important to apply appropriate
+   mechanisms to preclude applications and senders from misstating their
+   congestion contribution.  [RFC7713] discusses this problem in detail
+   and introduces the ConEx auditing concept.  ConEx auditing can be
+   performed in different ways -- for example, flows can be constantly
+   audited or only audited on demand when network operators decide to do
+   so.  Also, coarse-grained auditing may operate on flow aggregates for
+   efficiency reasons, whereas fine-grained auditing would inspect
+   individual flows.  In mobile networks, there may be deployment
+   strategies that favor efficiency over very exact auditing.  It is
+   important to understand the trade-offs and to apply ConEx auditing
+   appropriately.
+
+   The ConEx protocol specifications [CONEX-DESTOPT] and [TCP-MOD]
+   discuss additional security considerations that would also apply to
+   mobile network deployments.
+
+6.  Informative References
+
+   [CONEX-DESTOPT]
+              Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli,
+              "IPv6 Destination Option for Congestion Exposure (ConEx)",
+              Work in Progress, draft-ietf-conex-destopt-12, January
+              2016.
+
+   [conex-lite]
+              Baillargeon, S. and I. Johansson, "ConEx Lite for Mobile
+              Networks", In Proceedings of the 2014 ACM SIGCOMM Capacity
+              Sharing Workshop, DOI 10.1145/2630088.2630091, August
+              2014.
+
+   [dash]     ISO/IEC, "Information Technology -- Dynamic Adaptive
+              Streaming over HTTP (DASH) -- Part 1: Media presentation
+              description and segment formats", ISO/IEC 23009-1:2014,
+              May 2014.
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 19]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   [lte-sigcomm2013]
+              Huang, J., Qian, F., Guo, Y., Zhou, Y., Xu, Q., Mao, Z.,
+              Sen, S., and O. Spatscheck, "An In-depth Study of LTE:
+              Effect of Network Protocol and Application Behavior on
+              Performance", In Proceedings of the 2013 ACM SIGCOMM
+              Conference, DOI 10.1145/2486001.2486006, August 2013.
+
+   [nec.euronf-2011]
+              Mir, F., Kutscher, D., and M. Brunner, "Congestion
+              Exposure in Mobility Scenarios", In Proceedings of the 7th
+              Euro-NF Conference on Next Generation Internet (NGI),
+              DOI 10.1109/NGI.2011.5985948, June 2011.
+
+   [nec.globecom2010]
+              Kutscher, D., Lundqvist, H., and F. Mir, "Congestion
+              Exposure in Mobile Wireless Communications", In
+              Proceedings of 2010 IEEE Global Telecommunications
+              Conference (GLOBECOM), DOI 10.1109/GLOCOM.2010.5684362,
+              December 2010.
+
+   [raghavan2007]
+              Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K.,
+              and A. Snoeren, "Cloud Control with Distributed Rate
+              Limiting", ACM SIGCOMM Computer Communication Review,
+              DOI 10.1145/1282427.1282419, October 2007.
+
+   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
+              Notification", RFC 6040, DOI 10.17487/RFC6040, November
+              2010, <http://www.rfc-editor.org/info/rfc6040>.
+
+   [RFC6789]  Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed.,
+              "Congestion Exposure (ConEx) Concepts and Use Cases",
+              RFC 6789, DOI 10.17487/RFC6789, December 2012,
+              <http://www.rfc-editor.org/info/rfc6789>.
+
+   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
+              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
+              DOI 10.17487/RFC6817, December 2012,
+              <http://www.rfc-editor.org/info/rfc6817>.
+
+   [RFC7713]  Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
+              Concepts, Abstract Mechanism, and Requirements", RFC 7713,
+              DOI 10.17487/RFC7713, December 2015,
+              <http://www.rfc-editor.org/info/rfc7713>.
+
+   [TCP-MOD]  Kuehlewind, M. and R. Scheffenegger, "TCP modifications
+              for Congestion Exposure", Work in Progress, draft-ietf-
+              conex-tcp-modifications-10, October 2015.
+
+
+
+Kutscher, et al.              Informational                    [Page 20]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   [TR23705]  3GPP, "System Enhancements for User Plane Congestion
+              Management", 3GPP TR 23.705 13.0.0, December 2015.
+
+   [TR23829]  3GPP, "Local IP Access and Selected IP Traffic Offload
+              (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011.
+
+   [TS23203]  3GPP, "Policy and charging control architecture", 3GPP
+              TS 23.203 13.6.0, December 2015.
+
+   [TS23401]  3GPP, "General Packet Radio Service (GPRS) enhancements
+              for Evolved Universal Terrestrial Radio Access Network
+              (E-UTRAN) access", 3GPP TS 23.401 13.5.0, December 2015.
+
+   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
+              3GPP TS 23.402 13.4.0, December 2015.
+
+   [TS26114]  3GPP, "IP Multimedia Subsystem (IMS); Multimedia
+              telephony; Media handling and interaction", 3GPP TS 26.114
+              13.2.0, December 2015.
+
+   [TS29060]  3GPP, "General Packet Radio Service (GPRS); GPRS
+              Tunnelling Protocol (GTP) across the Gn and Gp interface",
+              3GPP TS 29.060 13.3.0, December 2015.
+
+   [TS29274]  3GPP, "3GPP Evolved Packet System (EPS); Evolved General
+              Packet Radio Service (GPRS) Tunnelling Protocol for
+              Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 13.4.0,
+              December 2015.
+
+   [TS36300]  3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
+              and Evolved Universal Terrestrial Radio Access Network
+              (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300
+              13.2.0, January 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 21]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+Appendix A.  Overview of 3GPP's EPS
+
+   This section provides an overview of the 3GPP "Evolved Packet System"
+   (EPS [TS36300] [TS23401]) as a specific example of a mobile
+   communication architecture.  Of course, other architectures exist,
+   but the EPS is used as one example to demonstrate the applicability
+   of congestion exposure concepts and mechanisms.
+
+   The EPS architecture and some of its standardized interfaces are
+   depicted in Figure 5.  The EPS provides IP connectivity to UE (i.e.,
+   mobile nodes) and access to operator services, such as global
+   Internet access and voice communications.  The EPS comprises the
+   radio access network called Evolved Universal Terrestrial Radio
+   Access Network (E-UTRAN) and the core network called the Evolved
+   Packet Core (EPC).  QoS is supported through an EPS bearer concept,
+   providing bindings to resource reservation within the network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 22]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+                                                      +-------+
+                             +-------+                | PCRF  |
+                             |  HSS  |               /+-------+\
+                             +-------+            Gx/           \Rx
+                                 |                 /             \
+                                 |                /               \
+                                 |          +-------+    SGi  +-------+
+                                 |          |  P-GW |=========|   AF  |
+                                 |          +-------+         +-------+
+   HPLMN                         |              |
+   ------------------------------|--------------|----------------------
+   VPLMN                         |              |
+                             +-------+          |
+                             |  MME  |          |
+                            /+-------+\         |S8
+                    S1-MME /           \        |
+                          /             \S11    |
+                         /               \      |
+                 +-----------+            \     |
+   +----+ LTE-Uu |           |             \    |
+   | UE |========|           |    S1-U      +-------+
+   +----+        |  E-UTRAN  |==============| S-GW  |
+                 |   (eNBs)  |              +-------+
+                 |           |
+                 +-----------+
+
+            Figure 5: EPS Architecture Overview (Roaming Case)
+
+   Note:
+   HPLMN - Home Public Land Mobile Network
+   VPLMN - Visited Public Land Mobile Network
+   AF - Application Function
+   SGi - Service Gateway Interface
+   LTE-Uu - LTE Radio Interface
+
+   The Evolved NodeB (eNB), the LTE base station, is part of the access
+   network that provides radio resource management, header compression,
+   security, and connectivity to the core network through the S1
+   interface.  In an LTE network, the control-plane signaling traffic
+   and the data traffic are handled separately.  The eNBs transmit the
+   control traffic and data traffic separately via two logically
+   separate interfaces.
+
+   The Home Subscriber Server (HSS) is a database that contains user
+   subscriptions and QoS profiles.  The Mobility Management Entity (MME)
+   is responsible for mobility management, user authentication, bearer
+   establishment and modification, and maintenance of the UE context.
+
+
+
+
+Kutscher, et al.              Informational                    [Page 23]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   The Serving Gateway (S-GW) is the mobility anchor and manages the
+   user-plane data tunnels during the inter-eNB handovers.  It tunnels
+   all user data packets and buffers downlink IP packets destined for
+   UEs that happen to be in idle mode.
+
+   The PDN Gateway (P-GW) is responsible for IP address allocation to
+   the UE and is a tunnel endpoint for user-plane and control-plane
+   protocols.  It is also responsible for charging, packet filtering,
+   and policy-based control of flows.  It interconnects the mobile
+   network to external IP networks, e.g., the Internet.
+
+   In this architecture, data packets are not sent directly on an IP
+   network between the eNB and the gateways.  Instead, every packet is
+   tunneled over a tunneling protocol -- the GPRS Tunneling Protocol
+   (GTP) [TS29060] over UDP/IP.  A GTP path is identified in each node
+   with the IP address and a UDP port number on the eNB/gateways.  The
+   GTP protocol carries both the data traffic (GTP-U tunnels) and the
+   control traffic (GTP-C tunnels [TS29274]).  Alternatively, PMIPv6 is
+   used on the S5 interface between S-GW and P-GW.
+
+   The above is very different from an end-to-end path on the Internet
+   where the packet forwarding is performed at the IP level.
+   Importantly, we observe that these tunneling protocols give the
+   operator a large degree of flexibility to control the congestion
+   mechanism incorporated with the GTP/PMIPv6 protocols.
+
+Acknowledgements
+
+   We would like to thank Bob Briscoe and Ingemar Johansson for their
+   support in shaping the overall idea and in improving the document by
+   providing constructive comments.  We would also like to thank Andreas
+   Maeder and Dirk Staehle for reviewing the document and for providing
+   helpful comments.
+
+Authors' Addresses
+
+   Dirk Kutscher
+   NEC
+   Kurfuersten-Anlage 36
+   Heidelberg
+   Germany
+
+   Email: kutscher@neclab.eu
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 24]
+
+RFC 7778                  ConEx Mobile Scenario               March 2016
+
+
+   Faisal Ghias Mir
+   NEC
+   Kurfuersten-Anlage 36
+   Heidelberg
+   Germany
+
+   Email: faisal.mir@gmail.com
+
+
+   Rolf Winter
+   NEC
+   Kurfuersten-Anlage 36
+   Heidelberg
+   Germany
+
+   Email: rolf.winter@neclab.eu
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Blvd Decarie
+   Town of Mount Royal, Quebec
+   Canada
+
+   Email: suresh.krishnan@ericsson.com
+
+
+   Ying Zhang
+   Hewlett Packard Labs
+   3000 Hannover Street
+   Palo Alto, CA  94304
+   United States
+
+   Email: ying.zhang13@hp.com
+
+
+   Carlos J. Bernardos
+   Universidad Carlos III de Madrid
+   Av. Universidad, 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34 91624 6236
+   Email: cjbc@it.uc3m.es
+   URI:   http://www.it.uc3m.es/cjbc/
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 25]
+