GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7778

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

  1. —————————————————-

| +—-+ +——-+ +——-+ +——-+ |

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

  1. —————————————————-

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc7778.txt · Last modified: 2016/03/11 23:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki