[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-conex-mobile

IETF                                                         D. Kutscher
Internet-Draft                                                    F. Mir
Intended status: Informational                                 R. Winter
Expires: September 8, 2011                                           NEC
                                                             S. Krishnan
                                                                Y. Zhang
                                                                Ericsson
                                                           March 7, 2011


           Mobile Communication Congestion Exposure Scenario
                     draft-kutscher-conex-mobile-00

Abstract

   This memo describes a mobile communications use case for congestion
   exposure (CONEX) with a particular focus on mobile communication
   networks such as 3GPP LTE.  The draft describes the architecture of
   these networks (access and core networks), current QoS mechanisms and
   then discusses how congestion exposure concepts could be applied.
   Based on this, this memo suggests a set of requirements for CONEX
   mechanisms that particularly apply to mobile networks.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 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



Kutscher, et al.        Expires September 8, 2011               [Page 1]


Internet-Draft            CONEX Mobile Scenario               March 2011


   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
   2.  Overview of 3GPP's Evolved Packet System (EPS) . . . . . . . .  3
   3.  CONEX Use Cases in the Mobile Communication Scenario . . . . .  5
     3.1.  CONEX as a basis for traffic management  . . . . . . . . .  6
     3.2.  CONEX to incentivize scavenger transports  . . . . . . . .  6
     3.3.  Accounting for Congestion Volume . . . . . . . . . . . . .  7
     3.4.  CONEX as a form of differential QoS  . . . . . . . . . . .  7
     3.5.  Partial vs. Full Deployment  . . . . . . . . . . . . . . .  8
     3.6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Possible Deployment Scenarios  . . . . . . . . . . . . . .  9
     4.2.  Implementing CONEX Functions in the EPS  . . . . . . . . . 11
   5.  Implications for CONEX . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
























Kutscher, et al.        Expires September 8, 2011               [Page 2]


Internet-Draft            CONEX Mobile Scenario               March 2011


1.  Introduction

   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].

   Mobile data traffic continues to grows rapidly.  The challenge
   wireless operators face is to support more subscribers with higher
   bandwidth requirements.  To meet the bandwidth demand, operators need
   to seek for new technologies to efficiently utilize the available
   network resources, in particular, this concerns resource allocation
   and flow management.  Ample statistics for network traffic from
   cellular networks are available, stating that many short flows exist,
   but that a few large flows constitute a large part of the overall
   traffic volume.  Measurement studies have shown that a small number
   of users is responsible for the most part of the traffic in cellular
   networks.  With the highly skewed network access behavior, more
   expensive resources in cellular networks as compared to other
   networks and the rapidly increasing network utilization, resource
   allocation and usage accountability are two important issues for
   operators to solve in order to achieve a better, accountable network
   resource utilization.  CONEX, as described in
   [I-D.ietf-conex-concepts-uses] is a technology to base this upon.

   The CONEX congestion exposure mechanism is intended as a general
   technology that could be applied as a key element of congestion
   management solutions in a variety of use cases.  The IETF CONEX WG
   will however work on a specific use case, where the end hosts and the
   network that contains the destination end host 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 LTE network, where the UE (User Equipment,
   i.e. mobile end host), its access network and possibly an operator's
   core network can be CONEX-enabled.  This draft describes the
   architecture of such networks (access and core networks), current QoS
   mechanisms and then discusses how congestion exposure concepts could
   be applied.  Using this use case as a basis, a set of requirements
   for CONEX mechanisms are described.


2.  Overview of 3GPP's Evolved Packet System (EPS)

   This section provides an overview of 3GPP's "Evolved Packet System"
   (EPS [3GPP.36.300]) as a specific example of a mobile communication
   architecture in order to illustrate congestion exposure applicability
   in this memo.  There are other mobile communication architectures.




Kutscher, et al.        Expires September 8, 2011               [Page 3]


Internet-Draft            CONEX Mobile Scenario               March 2011


   The EPS architecture and its standardized interfaces are depicted in
   Figure 1.  The EPS provides IP connectivity to UEs (user equipment,
   i.e., mobile nodes) and access to operator services, such as global
   Internet access and voice communications.  The EPS comprises the
   access (evolved UMTS Terrestrial Radio Access Network, E-UTRAN) and
   the core network (Evolved Packet Core, EPC).  QoS is supported
   through an EPS bearer concept, providing hierarchical bindings within
   the network.

   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 LTE an 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
   different interfaces.

   The Home Subscriber Server, HSS, is a database that contains users
   subscription and QoS profile.  The Mobility Management Entity, MME,
   is responsible for user authentication, bearer establishment and
   modification and maintenance of the UE context.

   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 Packet Gateway, P-GW, is responsible for IP address allocation to
   the UE and is a tunnel endpoint for mobility 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 GWs.  Instead, every packet is sent
   in a tunneling protocol - the GPRS Tunneling Protocol (GTP
   [3GPP.29.060]) over UDP/IP.  A GTP path is identified in each node
   with the IP address and a UDP port number on the eNB/GWs.  The GTP
   protocol carries both the data traffic (GTP-U tunnels) and the
   control traffic (GTP-C tunnels [3GPP.29.274]).

   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 protocols.





Kutscher, et al.        Expires September 8, 2011               [Page 4]


Internet-Draft            CONEX Mobile Scenario               March 2011


                                                      +-------+
                             +-------+                | PCRF  |
                             |  HSS  |               /+-------+\
                             +-------+            Gx/           \Rx
                                 |                 /             \
                                 |                /               \
                                 |          +-------+    SGi  +-------+
                                 |          |  PDN  |=========|IP Svr |
                                 |          +-------+         +-------+
   HPMN                          |              |
   ------------------------------|--------------|----------------------
   VPLMN                         |              |
                             +-------+          |
                             |  MME  |          |
                            /+-------+\         |S8
                    S1-MME /           \        |
                          /             \S11    |
                         /               \      |
                 +-----------+            \     |
   +----+ LTE-Uu |           |             \    |
   | UE |========|           |    S1-U      +-------+
   +----+        |  E-UTRAN  |==============| S-GW  |
                 |           |              +-------+
                 |           |
                 +-----------+

                    Figure 1: EPS Architecture Overview


3.  CONEX Use Cases in the Mobile Communication Scenario

   Given the initial scope of CONEX, the problem that mobile operators
   are facing and large networks that are under tight operator control,
   including the mobile end devices to a certain extend, the LTE use
   case appears to be an ideal first target deployment scenario.  In
   addition, mobile networks already have many of the principle
   functions that the CONEX use cases require such as accounting.
   Mobile networks however have characteristics that differ
   significantly enough from fixed network architectures that these
   should be taken into account.

   [I-D.ietf-conex-concepts-uses] describes fundamental congestion
   exposure concepts and a set of use cases for applying congestion
   exposure mechanisms to achieve different functions in traffic
   management, accounting etc.  In this section, we relate these CONEX
   use cases to the general mobile communication scenario in order to
   validate the use cases for this scenario.




Kutscher, et al.        Expires September 8, 2011               [Page 5]


Internet-Draft            CONEX Mobile Scenario               March 2011


3.1.  CONEX as a basis for traffic management

   Traffic management is a very important function in mobile
   communication networks.  Since wireless resources have been
   considered scarce and since user mobility and shared bandwidth in the
   wireless access create a certain dynamics with respect to available
   bandwidth, these resources are traditionally managed very tightly
   (admission control for bearers establishment etc.)

   In LTE, the QoS requirements for different applications running on a
   UE is supported by a bearer concept which is managed by the network.
   Each bearer has an associated QoS Class identifier (QCI) and an
   Allocation and retention policy (ARP) that has been standardized for
   uniform traffic handling (across implementations).  For the necessary
   QoS across the mobile network, an EPS bearer is maintained that
   crosses different interfaces in the network and maps to lower layer
   bearers for packet forwarding.  A radio bearer transports traffic
   between a UE and eNB whereas S1 bearer transports traffic between the
   eNB and S-GW.  Primarily LTE offers two types of bearer: Guaranteed
   Bit rate bearer for real time communication, e.g., Voice calls etc
   and Non-Guaranteed bit rate, e.g., best effort traffic for web access
   etc.  Packets mapped to the same EPS bearer receive the same bearer
   level packet forwarding treatment.

   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 EPC -- on, for example, a PDN
   gateway, and some operators do in fact deploy DPI today. 3GPP has a
   current work item on "Service Awareness and Privacy Policies" that is
   chartered to add DPI-related extensions to the PCC architecture
   [3GPP.23.203].

   In summary, it can be said that traffic management in 3GPP EPS and
   other mobile communication architectures in very important.
   Previously more static approach based on admission control and static
   QoS have been applied, but recently, there has been a perceived need
   for more dynamic mechanisms such as DPI.  Adding CONEX support might
   thus require revisiting the PCC architecture, depending on the scope
   and impact of a CONEX-based traffic management approach.

3.2.  CONEX to incentivize scavenger transports

   As 3G and LTE networks are turning into universal access networks
   that are shared between mobile (smart) phone users, mobile users with
   laptop PC, home users with LTE access etc., the mobile communication
   network will be used like any other access network, i.e., different
   applications from different users compete for bandwidth.




Kutscher, et al.        Expires September 8, 2011               [Page 6]


Internet-Draft            CONEX Mobile Scenario               March 2011


   Most of this traffic is likely to be classified as best-effort
   traffic, so that it will eventually be difficult to distinguish
   periodic OS updates, application store downloads from web (browser)-
   based communication (this is reflected by the current DPI activities
   in 3GPP).  Having said that, the general argument for scavenger
   transports apply.  Especially when wireless and backhaul resources
   are scarce, incentivizing users to use less-than best effort
   transport for non-interactive background communication would improve
   the overall utility of the network.  It can be argued that, if this
   would be done with a CONEX approach, much of the envisioned DPI
   mechanisms would not be needed.

   This would work best, if the network did not do any traffic class
   segregation below the IP layer, i.e., if all traffic would be in the
   same traffic class.  With current specifications, that would be
   possible in principle.

3.3.  Accounting for Congestion Volume

   3G and LTE networks provide extensive support for accounting and
   charging already, for example cf. the PCC architecture.  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 their data contractual volume budget for the charging period.

   Changing this data volume-based accounting to a congestion-based
   accounting would be possible in principle, especially since there
   already is an elaborated per-user accounting system available.  Also,
   an operator-provided mobile communication network can be seen as a
   network domain within such congestion volume accounting would be
   possible, without requiring any support from the global Internet.
   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, the user is accounted for both received and sent data,
   which would facilitate congestion volume accounting as well.

3.4.  CONEX as a form of differential QoS

   As mentioned above, 3GPP mobile communication networks provide an
   elaborate QoS architecture.  In LTE, the idea is to map different
   traffic classes onto different logical channels (bearers) with
   individual QoS configuration.




Kutscher, et al.        Expires September 8, 2011               [Page 7]


Internet-Draft            CONEX Mobile Scenario               March 2011


   It can be argued whether this approach is sufficient in a world where
   most traffic is on TCP port 80 and whether some more application
   control would be useful.

   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.

3.5.  Partial vs. Full Deployment

   A 3GPP mobile communication network can be seen as separate network
   domain that would enable the introduction of CONEX through a careful
   standardization of interfaces and behavior of its system elements.
   While it can be possible to deploy CONEX in a single operator's
   network only, it may in fact not be practical, since support on
   mobile nodes (UEs) may be required to actually implement the host end
   transport mechanisms.

   Aspects such as roaming have to be considered, i.e., what happens if
   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.

   Another aspect to consider is the addition of Selected IP Traffic
   Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829],
   i.e., the idea that some traffic (e.g., 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.

3.6.  Summary

   In summary, the 3GPP EPS in a system architecture that can benefit
   from congestion exposure in multiple ways, as we have shown by this
   brief description of CONEX use cases in this environment.  Dynamic
   traffic and congestion management is an acknowledged important
   requirement for the EPS, also illustrated by the current DPI work for
   EPS.

   Moreover, we believe that networks such as an LTE mobile
   communication networks 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), a single mobile network deployment is under full
   control of a single operator, which can enable operator-local
   enhancement without the need to change the complete architecture.




Kutscher, et al.        Expires September 8, 2011               [Page 8]


Internet-Draft            CONEX Mobile Scenario               March 2011


   In 3GPP EPS, interfaces between all elements of the architecture are
   subject to standardization, including UE interfaces and eNodeB
   interfaces, so that a standardized approach can be feasible as well.


4.  CONEX in the EPS

   The CONEX mechanism is still work in progress in the IETF working
   group.  Still, we would like to discuss a few options for how such a
   mechanism (and possibly additional policing functions) could
   eventually be deployed in 3GPP's EPS.  Note that this description of
   options is not intended as a complete set of possible approaches --
   it is merely intended for discussing a few options.  More details
   will be provided in a future revision of this document.

4.1.  Possible Deployment Scenarios

   There are different possible ways 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.

   We can differentiate two fundamental deployment scenarios for
   congestion exposure as depicted in the figures below: 1) 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.  For 2), 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 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.












Kutscher, et al.        Expires September 8, 2011               [Page 9]


Internet-Draft            CONEX Mobile Scenario               March 2011


   -----------------------------------------------------
   |  +----+     +-------+     +-------+     +-------+ |
   |  | 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.        Expires September 8, 2011              [Page 10]


Internet-Draft            CONEX Mobile Scenario               March 2011


   -----------------------------------------------------
   |   |---            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

   We consider both scenarios to be relevant and believe that both of
   them are within the scope of the CONEX WG charter.  A more detailed
   description of these descriptions will be provided in a future
   version of this document.

4.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 3GPP's
   EPS.

   o  The CONEX mechanism defines how congestion is actually indicated,
      how hosts can re-act to it, and how congestion contribution is
      finally declared.  For ECN-based mechanisms, ECN marking in
      routers would be part of the mechanism.

   o  Policing functions are normally expected to manage the
      experienced/declared congestion in the network.  They are
      considered important functions in an overall CONEX framework, as
      they provide incentives to users/applications to actually re-act
      to congestion indication.  Also, it is assumed that accounting is
      performed based on function related to policing.  Finally,



Kutscher, et al.        Expires September 8, 2011              [Page 11]


Internet-Draft            CONEX Mobile Scenario               March 2011


      implementations of CONEX may require the network to enforce proper
      congestion contribution declaration (i.e., as droppers in the Re-
      ECN proposal).

   In the following, we discuss some possible placement strategies for
   CONEX functional entities in the EPS and for possible optimizations
   for both the uplink and the downlink.  In order to provide a
   comprehensive CONEX-based capacity management framework for LTE, it
   would be advantageous to consider user contribution to congestion for
   both the radio access and the core network.  Potential places for
   CONEX functions are e.g. the eNBs, the S-GWs or the P-GWs.  Operator
   deployments may provide additional intermediary CONEX-enabled IP
   network elements.

   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: Proxy-Mobile-IP (PMIP,
   [3GPP.23.402]) and 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 re-act to
   persistent congestion contribution etc.  In the EPS, per-user
   information is normally part of the user profile (stored in HSS) that
   would be accessed by PCC entities such as the PCRF for dynamic
   updates, enforcement etc.

   The Conex mechanism allows operators to either have congestion based
   policing in the uplink/downlink or in both directions.  With the
   given flexibility, the functional entities can further be divided
   into uplink and downlink directions e.g. uplink/downlink policer etc.

   Policers may be placed at different network locations (also see
   [nec.globecom2010]).  E.g., placing an uplink Policer at the base
   station can be beneficial, because if there is congestion in the
   backhaul, traffic would be policed before reaching the congested
   segments.  On the other hand, considering user mobility, operating
   uplink policers on base stations may not be the optimal approach.

   Downlink Policers would also be positioned best at border gateways
   where they can process ingress traffic.  Depending on the specific
   architecture, up- and downlink policers could also be collocated.

   A more detailed description of the different approaches and their
   respective advantages will be provided in a future revision of this
   document.



Kutscher, et al.        Expires September 8, 2011              [Page 12]


Internet-Draft            CONEX Mobile Scenario               March 2011


5.  Implications for CONEX

   Our description of possible CONEX use cases and deployment options in
   the previous sections has yielded a set of implications/requirements
   for the CONEX mechanism that we summarize in this section.

   Performance:  CONEX's capability of ensuring fairness could be used
      for ensuring fairness in cellular networks.  However, although the
      idea looks promising, its advantages and performance have been not
      yet been verified thoroughly yet.  In the context of cellular
      networks, which has more expensive resources and more stringent
      QoS requirements, the feasibility of applying Conex to cellular
      network as well as its performance and deployment scenarios need
      to be examined.  For instance, the mobile network may encounter
      longer delay and higher loss rate but most of the flows are short-
      lived.  In the network with fast changing conditions, it requires
      Conex to expose latest congestion information in time.  In
      addition, it is significant if it has the capability to indicate
      out-of-date congestion information to avoid misusage of such
      information.

   Mobility:  One of the unique characteristics in cellular network is
      the presence of user mobility compared to wired networks.  As the
      user location changes, the same device can be connected to the
      network via different base stations (eNodeBs) or even go through
      switching gateways.  Thus, the CONEX scheme must to be able to
      carry latest congestion information per user/flow across multiple
      network nodes in real time.

   Multi-access:  In cellular network, multiple access technologies can
      co-exist.  In such cases, a user can use multiple access
      technologies for multiple applications or even a single
      application simutaneously.  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 PMIP and
      GTP.

   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.



Kutscher, et al.        Expires September 8, 2011              [Page 13]


Internet-Draft            CONEX Mobile Scenario               March 2011


6.  IANA Considerations

   No IANA considerations.


7.  Security Considerations

   Security considerations will be provided in a future version of this
   document.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [3GPP.23.203]
              3GPP, "Policy and charging control architecture", 3GPP
              TS 23.203 10.2.1, January 2011.

   [3GPP.23.402]
              3GPP, "Architecture enhancements for non-3GPP accesses",
              3GPP TS 23.402 10.2.1, January 2011.

   [3GPP.23.829]
              3GPP, "Local IP Access & Selected IP Traffic Offload
              (LIPA-SIPTO)", 3GPP TR 23.829 1.3.0, September 2010.

   [3GPP.29.060]
              3GPP, "General Packet Radio Service (GPRS); GPRS
              Tunnelling Protocol (GTP) across the Gn and Gp interface",
              3GPP TS 29.060 3.19.0, March 2004.

   [3GPP.29.274]
              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 10.1.0,
              December 2010.

   [3GPP.36.300]
              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
              10.2.0, December 2010.



Kutscher, et al.        Expires September 8, 2011              [Page 14]


Internet-Draft            CONEX Mobile Scenario               March 2011


   [I-D.ietf-conex-concepts-uses]
              Briscoe, B., Woundy, R., Moncaster, T., and J. Leslie,
              "ConEx Concepts and Use Cases",
              draft-ietf-conex-concepts-uses-00 (work in progress),
              November 2010.

   [nec.globecom2010]
              Kutscher, Lundqvist, and Mir, "Congestion Exposure in
              Mobile Wireless Communications", in proceedings of IEEE
              GLOBECOM 2010, December 2010.


Appendix A.  Acknowledgments

   We would like to thank Ingemar Johansson for his support in shaping
   the overall idea and in improving the draft.


Authors' Addresses

   Dirk Kutscher
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: kutscher@neclab.eu


   Faisal Ghias Mir
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: faisal.mir@neclab.eu













Kutscher, et al.        Expires September 8, 2011              [Page 15]


Internet-Draft            CONEX Mobile Scenario               March 2011


   Rolf Winter
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: winter@neclab.eu


   Suresh Krishnan
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Phone:
   Email: suresh.krishnan@ericsson.com


   Ying Zhang
   Ericsson
   200 Holger Way
   San Jose, CA  95134
   USA

   Phone:
   Email: ying.zhang@ericsson.com























Kutscher, et al.        Expires September 8, 2011              [Page 16]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/