<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-penno-pcp-mobile-qos-00" ipr="trust200902">
  <front>
    <title abbrev="PCP in Mobile Network for QOS">PCP Usage for Quality of
    Service (QoS) in Mobile Networks</title>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region></region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>repenno@cisco.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Bill VerSteeg" initials="B." surname="VerSteeg">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>5030 Sugarloaf Parkway</street>

          <city>Lawrenceville</city>

          <code>30044</code>

          <country>USA</country>
        </postal>

        <email>billvs@cisco.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date />

    <workgroup>PCP</workgroup>

    <abstract>
      <t>There are challenges to request quality of service for an application
      or network flow that is not part of a mobile network's Evolved Packet
      Core (EPC). This document addresses this issue by defining a mechanism
      to signal the desired characteristics of a flow to the Mobile Network
      from a User Equipment (UE) using Port Control Protocol (PCP). The
      signaled characteristics allow the Mobile Network to enforce appropriate
      policies such as prioritize that flow accordingly and trigger dedicated
      bearer activation or bearer modification procedure.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The use of Mobile Network for accessing the Internet and other data
      services via smartphones, tablets, and notebook/netbook computers has
      increased rapidly as a result of high-speed packet data networks such as
      HSPA and HSPA+; and now Long-Term Evolution (LTE) is being deployed.
      Mobile devices are becoming similar in capability to their desktop
      counterparts. From that perspective, it is feasible to run WebRTC, HTTP
      Adaptive Streaming (HAS), P2P applications on mobile devices. Mobile
      network needs to have a mechanism to prioritize such packet flows in
      both directions.</t>

      <t>The Web Real-Time communication (WebRTC) framework <xref
      target="I-D.ietf-rtcweb-overview"></xref> provides the protocol building
      blocks to support direct, interactive, real-time communication using
      audio, video, collaboration, games, etc., between peer web-browsers.
      WebRTC application use Interactive Connectivity Establishment (ICE)
      protocol <xref target="RFC5245"></xref> for gathering candidates,
      prioritizing them, choosing default ones, exchanging them with the
      remote party, pairing them and ordering them into check lists. Once all
      of the above steps have been completed the participating ICE agents can
      begin a phase of connectivity checks and eventually select a pair of
      candidates that will be used for real-time communication. The P2P
      streams (audio, video, data-channel) are dynamic, time-bound, encrypted
      and have different priorities. When WebRTC server is deployed in a 3rd
      party network trusted by the Mobile Network and the media session need
      to be prioritized, a mechanism is required to signal the flow
      characteristics (i.e., traffic performance requirements) of the media
      streams to the Mobile Network. However, the Mobile Network may not trust
      the host (UE) to signal the correct flow characteristics permitted by
      the WebRTC server.</t>

      <t>PCP <xref target="RFC6887"></xref> provides a mechanism to describe a
      given flow to the network prior to actual session establishment. The
      primary driver for PCP has been creating port mappings on NAT and
      firewall devices. When doing this, PCP pushes flow information from the
      host into the network (specifically to the network's NAT or firewall
      device), and receives information back from the network (from the NAT or
      firewall device). This document uses PCP FLOWDATA option defined in
      <xref target="I-D.wing-pcp-flowdata"></xref> to convey the flow
      characteristics from the host to the Mobile Network, and allow the
      Mobile Network to prioritize that flow accordingly and trigger dedicated
      bearer activation or bearer modification procedure. This document also
      explains how the PCP Server in the Evolved Packet Core (EPC) maps the
      fields in PCP FLOWDATA option to 3GPP QCI, GBR values.</t>

      <t>The mechanism described in this document has several useful
      properties :</t>

      <t><list style="letters">
          <t>Differentiated QoS services can be offered to third party
          applications. For third party applications differentiated QoS
          services can be installed even if the UE is behind NAT provided by
          the Mobile Network. In contrast, other mechanisms struggle to
          install differentiated QOS if the UE is behind NAT.</t>

          <t>Mobile Network can authorize the differentiated service request
          from third party application because the proposed mechanism is
          compliant with the 3GPP's network-triggered QoS policy enforcement
          model.</t>

          <t>This mechanism does not rely on DPI.</t>

          <t>A UE can use single protocol no matter of the access technology;
          Abstracts layer 2 specifics, so host and applications can avoid
          layer 2-specific signaling even if their Internet connection is via
          3G/4G or DOCSIS.</t>

          <t>Usable at the application level, without needing operating system
          support</t>

          <t>Robust metadata support, to convey sufficient information to the
          network about the flow;</t>

          <t>Provides differentiated service for both directions of a flow,
          including flows that cross administrative boundaries (such as the
          Internet).</t>

          <t>Both high-priority and low-priority flows can be signalled, so
          that in overload situations operators can make low-priority flows
          yield to other flows through policing.</t>
        </list></t>

      <t>Note :</t>

      <t><list style="numbers">
          <t>It is out of scope of this document to discuss the trade-offs
          between the proposed approach vs. deploying local WebRTC-IMS
          Gateways within the Mobile Network.</t>

          <t>The mechanism described in this document provides QoS and network
          feedback for a variety of applications including interactive
          audio/video application such as WebRTC, streaming video, and network
          backup. The value is provided for the applications that are
          orchestrated through EPC and for applications that are delivered
          over the top.</t>

          <t>Administrative-related considerations between the administrative
          entity managing the third party application server and the Mobile
          Network are out of scope of this document.</t>
        </list></t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>This note uses terminology defined in <xref target="RFC5245"></xref>,
      <xref target="RFC6459"></xref>.</t>

      <t>WebRTC Server : Web Server that supports WebRTC.</t>

      <t>High-Speed Packet Access : The High-Speed Packet Access (HSPA) and
      HSPA+ are enhanced versions of the Wideband Code Division Multiple
      Access (WCDMA) and UTRAN, thus providing more data throughput and lower
      latencies.</t>
    </section>

    <section anchor="cell" title="QoS in Cellular Networks">
      <t>3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release
      8 <xref target="TS23.107"> </xref>. 3GPP QoS policy configuration
      defines access agnostic QoS parameters that can be used to provide
      service differentiation in multi vendor and operator deployments. The
      concept of a bearer is used as the basic construct for which QoS
      treatment is applied for uplink and downlink packet flows between the
      Mobile Node (MN) and gateway <xref target="TS23.401"> </xref>. A bearer
      may have more than one packet filter associated and this is called a
      Traffic Flow Template (TFT). IP source address, source port, IP
      destination, destination port, L4 protocol, Type of service/Traffic
      class type, Security parameter index etc identify a packet filter. Each
      UE can have one or multiple bearers associated with its registration,
      each supporting different QoS characteristics. An UpLink Traffic Flow
      Template (UL TFT) is the set of uplink packet filters in a TFT. A
      DownLink Traffic Flow Template (DL TFT) is the set of downlink packet
      filters in a TFT.</t>

      <t>The access agnostic QoS parameters associated with each bearer are
      QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), MBR
      (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate) explained in
      <xref target="TS23.203"></xref>. QCI is a scalar that defines packet
      forwarding criteria in the network. Mapping of QCI values to DSCP is
      well understood and GSMA has defined standard means of mapping between
      these scalars <xref target="GSMA-IR34"> </xref>. 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 bearer,
      e.g., best effort traffic for web access etc. Packets mapped to the same
      EPS bearer receive the same bearer level packet forwarding treatment.
      For example QCI value 1 is typically used for Conversational Voice and
      the standardized flow characteristics for QCI value 1 are Packet delay
      of 100 ms and Packet error loss Rate of 10 to the power -2.</t>

      <t>3G and LTE networks also provide extensive support for accounting and
      charging already, for example using the Policy Charging Control (PCC)
      architecture. In the EPS, per-user information is normally part of the
      user profile (stored in the Home Subscriber Server) that would be
      accessed by PCC entities such as the PCRF for dynamic updates,
      enforcement etc.</t>
    </section>

    <section anchor="problem_stmt" title="Solution Overview">
      <t>In the below topology, The main involved functional elements
      are:<list style="symbols">
          <t>UE (User Equipment) is a mobile node.</t>

          <t>The evolved NodeB (eNB) is a base station entity that supports
          the Long-Term Evolution (LTE) air interface. It 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.</t>

          <t>The Serving gateway, SGW, 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.</t>

          <t>Policy and Charging Rule Function (PCRF) which is responsible for
          determining which policy and charging control rules are to be
          applied <xref target="TS23.203"> </xref>.</t>

          <t>Policy and Charging Enforcement Function (PCEF) which performs
          policy enforcement (e.g., Quality of Service (QoS)) and flow-based
          charging <xref target="TS23.203"> </xref>. PCEF is co-located with
          PDN-GW. PDN-GW is also responsible for IP address allocation to the
          UE, packet filtering, and policy-based control of flows.</t>

          <t>Application Function (AF) is an element offering applications
          that require dynamic policy and/or charging control <xref
          target="TS23.203"></xref>.</t>

          <t>The Home Subscriber Server, HSS, is a database that contains user
          subscriptions and QoS profiles. The Mobility Management Entity, MME,
          is responsible for user authentication, bearer establishment and
          modification and maintenance of the UE context.</t>
        </list><figure title="PCP interdomain - WebRTC">
          <artwork align="left"><![CDATA[                        +--------+
                        |  HSS   |
                        +--------+
                             |                      +-------+
                             |                      | PCRF  | 
                             |                      +-------+
                          +-------+                     |       
                        / | MME   |\                    |
                       /  +-------+ \                   |
                      /              \                  |   
                     /                \                 | 
    +----+        +-------+            +-------+      +-------+
    |UE  |        |  eNB  |            | SGW   |      |PDN-GW |
    |    |========|       |============|       |======|       |
    +----+        +-------+            +-------+      +-------+
     ^  .                                                  ^
     |  .                     PCP  request/response        . 
     |  .................................................... 
     |                                                                                                                                                           
     |  WebRTC Signalling
     +-------------------------------------------------------+
Mobile Network                                               |      
                                                             |                                                                                           
==================================================================
3rd Party Network                                            |
                                                             |
                                                             V   
                                        =========================
                                        |  WebRTC Server        |
                                        =========================   

]]></artwork>
        </figure></t>

      <section title="Network-triggered QoS">
        <t>This section describes the existing steps applicable to any other
        network that requires authorization from third party application to
        permit differentiated QOS service request from UE which has been
        discussed in <xref
        target="I-D.wing-pcp-third-party-authz"></xref>.</t>

        <t><list style="numbers">
            <t>PCP client determines the PCP server to use by using the
            mechanisms explained in section 8.1 of <xref
            target="RFC6887"></xref>. In case of the GTP-based S5/S8
            interface, the PDN-GW is the first-hop router for the UE, and in
            the case of PMIPv6-based S5/S8, the SGW is the first-hop router.
            PCP server could be co-located with the PDN-GW. For instance PCP
            client can also learn the PCP server address using DHCP <xref
            target="I-D.ietf-pcp-dhcp"></xref> and behavior to be followed by
            the PCP client to contact its PCP server(s) is explained in <xref
            target="I-D.ietf-pcp-server-selection"></xref>. The other benefits
            of using PCP are explained in <xref
            target="I-D.penno-rtcweb-pcp"></xref>.</t>

            <t>Once ICE <xref target="RFC5245"></xref> processing has
            completed, an updated offer/answer exchange takes place. WebRTC
            server is aware of the active media path after the controlling ICE
            endpoint follows the procedures in Section 11.1 of <xref
            target="RFC5245"> </xref>, specifically to send updated offer if
            the candidates in the m and c lines for the media stream (called
            the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES
            (also see Appendix B.9 of <xref target="RFC5245"> </xref>).</t>

            <t>To provide differentiated QOS, the WebRTC server generates
            cryptographic token and metadata for prioritizing the media
            streams which is passed to the WebRTC endpoint. In this scenario
            PCP client on the UE is the third-party application obtaining
            limited access to an PCP server (resource server) on behalf of the
            WebRTC server (resource owner). The PCP TOKEN_ACCESS option
            defined in <xref target="I-D.wing-pcp-third-party-authz"></xref>
            must be included in the PCP request sent to the PCP server. This
            TOKEN_ACCESS option is created by the PCP client using the access
            token, key id etc received from the authorization server using
            OAuth 2.0 <xref target="RFC6749"></xref>. The PCP client populates
            the fields in FLOWDATA option using the metadata provided by the
            authorization server. The PCP client sends the PCP request with
            MAP or PEER opcodes with the above PCP options to the PCP server.
            This mechanism is required so that the PCP server in the Evolved
            Packet (EPC) can validate that the PCP request for specific flow
            characteristics is initiated by the UE because of using a trusted
            3rd party WebRTC Server.</t>

            <t>The PCP server identifies the authorization server using the
            Domain Name in the PCP ACCESS_TOKEN option. The PCP server
            validates the fields in TOKEN_ACCESS option using the mechanism
            explained in section 5.2 of <xref
            target="I-D.wing-pcp-third-party-authz"></xref>. If the token is
            successfully validated then the authorization server returns the
            token bound authorization data in response. The token bound
            authorization data would be flow characteristics like upstream and
            downstream minimum bandwidth, delay, loss etc. The PCP server then
            matches this token bound authorization data with what is requested
            in the PCP FLOWDATA option. If the authorization sets match, the
            PCP server honors the PCP request made by the PCP client.</t>
          </list></t>
      </section>

      <section title="PCP to 3GPP ">
        <t>This section describes steps involved with processing PCP FLOWDATA
        option to initiate bearer activation for each media stream.</t>

        <t><list style="numbers">
            <t>The PCP FLOWDATA option has all the required fields to trigger
            dedicated bearer activation or modification with relevant QCI, GBR
            values. UpLink Traffic Flow Template (UL TFT) and DownLink Traffic
            Flow Template (DL TFT) would be installed in both directions for
            the media stream. For example IP source address, source port, IP
            destination address, destination port, L4 protocol will be used
            from the PCP request (PEER opcode) to create packet filter which
            is associated with UL TFT. The advantage of this technique is no
            changes are required to TFT definition. PCP success response would
            be sent without waiting for network-initiated bearer activation or
            modification to be complete: i.e., PCP success response would be
            sent based on the resource availability to setup or modify
            bearers.</t>

            <t>Using the fields in PCP FLOWDATA option listed in the below
            table, relevant QCI value will be determined to initiate bearer
            activation or modification procedure. Upstream and Downstream
            Bandwidth Minimum values will be set to zero in PCP FLOWDATA
            option to indicate QCI values in the range 5-8. Non-zero Bandwidth
            Minimum value in FLOWDATA option will be mapped to GBR to
            determine if the requested bitrate can be provided or not. GBR is
            provided only for QCI values 1 to 4.<figure
                title="PCP FLOWDATA to QCI Mapping">
                <artwork align="left"><![CDATA[             
         (Fields in PCP FLOWDATA option - uDT, uLT, dDT, dLT)

+---------------------------------------------------------------+ 
| QCI  |  Delay    |  Loss    |   Example Services              |
|---------------------------------------------------------------| 
| 1    |  Low      |  Medium  |  Conversational Voice           |
+---------------------------------------------------------------+
| 2    |  Medium   |  Low     |  Conversational Video           |
+---------------------------------------------------------------+
| 3    |  Very Low |  Low     |  Real Time Gaming               |
+---------------------------------------------------------------+ 
| 4    |  Medium   | Very Low |  Non-conversational Video,      |   
|      |           |          |  buffered streaming             |
+---------------------------------------------------------------+
| 5    |  Low      | Very Low |  IMS Signalling                 |
+---------------------------------------------------------------+ 
| 6    |  Medium   | Very Low |  Video (Buffered Streaming)     |
+---------------------------------------------------------------+
| 7    |  Low      |  Low     |  Voice, Video (Live streaming)  |
+---------------------------------------------------------------+
| 8    |  Medium   |  Low     |  web access                     |
+---------------------------------------------------------------+
| 9    |  High     |  Low     |  e-mail                         |
+---------------------------------------------------------------+

]]></artwork>
              </figure></t>

            <t>The PDN-GW will communicate with the PCRF to trigger the
            appropriate Policy charging and control (PCC) decision based on
            which PDN-GW will initiate bearer activation or modification
            procedure.</t>

            <t>If PCP authentication <xref
            target="I-D.ietf-pcp-authentication"></xref> is used then the PCP
            server can also provide identity of the UE to PCRF.</t>

            <t>After the call is terminated PCP client informs the PCP server
            to close the mapping. The Authorization Server also informs the
            PCP server to revoke the access token after the call is terminated
            which is discussed in section 5.2 of <xref
            target="I-D.wing-pcp-third-party-authz"></xref>. This step
            triggers bearer deactivation procedure discussed in section
            5.4.4.1 of <xref target="TS23.401"></xref>.</t>
          </list></t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"></xref>
      and PCP authentication <xref
      target="I-D.ietf-pcp-authentication"></xref> are to be taken into
      account.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Authors would like to thank Harold Lassers, Basavraj Patil, Thomas
      Anderson for their comments and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include='reference.RFC.6887'?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include="reference.RFC.5389"?>

      <?rfc include="reference.RFC.6407"?>

      <?rfc include="reference.RFC.6459"
?>

      <?rfc include="reference.RFC.6749"?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-rtcweb-security-arch' 
?>

      <?rfc include="reference.RFC.6342"?>

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc include='reference.I-D.reddy-rtcweb-mobile' ?>

      <?rfc include='reference.I-D.wing-pcp-third-party-authz'?>

      <?rfc include='reference.I-D.ietf-pcp-authentication'
?>

      <?rfc include='reference.I-D.ietf-pcp-server-selection'?>

      <?rfc include='reference.I-D.penno-rtcweb-pcp'  ?>

      <?rfc include='reference.I-D.wing-pcp-flowdata'  ?>

      <reference anchor="TS23.401" target="">
        <front>
          <title>General Packet Radio Service (GPRS) enhancements for Evolved
          Universal Terrestrial Radio Access Network (E- UTRAN) access
          (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 06).</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <reference anchor="TS23.107" target="">
        <front>
          <title>End-to-End Quality of Service (QoS) Concept and Architecture,
          Release 10, 3GPP TS 23.207, V10.0.0 (2011- 03)</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <reference anchor="TS23.203" target="">
        <front>
          <title>3GPP, "Policy and charging control architecture", 3GPP TS
          23.203 10.5.0, December 2011.</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <reference anchor="GSMA-IR34" target="">
        <front>
          <title>Inter-Service Provider Backbone Guidelines 5.0, 22 December
          2010</title>

          <author fullname="" surname="">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <!---->
    </references>

    <section title="">
      <t></t>

      <section anchor="compare" title="Other techniques">
        <t><list style="symbols">
            <t>UE can also request bearer resource modification for an E-UTRAN
            as explained in Section 5.4.5 of <xref target="TS23.401"> </xref>.
            The procedure allows the UE to request modification of bearer
            resources (e.g., allocation or release of resources) for one
            traffic flow aggregate with a specific QoS demand. Alternatively,
            the procedure allows the UE to request modification of the packet
            filters used for an active traffic flow aggregate, without
            changing QoS. If accepted by the network, the request invokes
            either the Dedicated Bearer Activation Procedure or the Bearer
            Modification Procedure. However this technique is not widely
            deployed and only network-controlled quality of service is widely
            used.</t>

            <t>After certain QoS parameters are established, the UE or the
            network may want to change those QoS parameters. This is supported
            in both 3GPP <xref target="TS23.401"></xref> and PCP FLOWDATA.</t>

            <t>Bearers modification, creation procedures when Application
            Server like WebRTC is deployed in 3GPP network is explained in
            section 4.3 of <xref target="I-D.reddy-rtcweb-mobile"></xref>.</t>

            <t>TODO : OneAPI.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
