tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7222

 
 
 

Quality-of-Service Option for Proxy Mobile IPv6

Part 3 of 3, p. 39 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 39 
6.  QoS Services in Integrated WLAN-3GPP Networks

6.1.  Technical Scope and Procedure

   The QoS option specified in this document can provide the equivalent
   level of QoS information defined in 3GPP, which is used to enforce
   QoS policies for IP flows that have been established while the mobile
   node is attached to WLAN access or moved from 3GPP to WLAN access.
   The QoS classification defined by the 3GPP specification [TS23.207]
   [TS29.212] is provided by Differentiated Services techniques in the
   IP transport network.  The QoS classification used in the IP
   transport network is further translated to WLAN QoS-specific
   techniques in the WLAN access using appropriate WLAN QoS
   specifications [IEEE802.11aa-2012] [WMM1.2.0].  The details are
   described in Appendix A and Appendix B.

   Figure 6 illustrates a generalized architecture where the QoS option
   can be used.  The QoS policies could be retrieved from a Policy
   Control Function (PCF), such as defined in current cellular mobile
   communication standards, which aims to assign an appropriate QoS

Top      Up      ToC       Page 40 
   class to a mobile node's individual flows.  Alternatively, more
   static and default QoS rules could be made locally available, e.g.,
   on a local mobility anchor, through administration.

           Non-cellular access       |  Cellular Core Network   Cellular
              (e.g., WLAN)           |      (e.g., EPC)           Access
                                     |                        (e.g.,
                                     |         +-----------+     EUTRAN)
                                     |         |    PCF    |
                                     |         |(e.g.,PCRF)|
             +----+                  |         +-----+-----+
             |WiFi|           (I)    |               |
             | AP |---+    +---+---+ |               |             ((O))
             +----+   |    |WiFi AR| |  PMIPv6    +-----+     +---+  |
                      +----+ (MAG) +=|============| LMA |=====|MAG+--|
                      |    |  WLC  | |  tunnel    +-----+     +---+  |
             +----+   |    +-------+ |             //
             |WiFi|---+              |            //
             | AP |                  |           //
             +----+           (II)   |          //
                           +-------+ |         //
   +----+    +------+      |WiFi AR| |        //
   |WiFi+----+  WLC +------+ (MAG) |=|=======//
   | AP |    |      |      |       | |
   +----+    +------+      +------ + |
                 ^            ^      |
                 |            |      |
                 +------------+
                QoS inter-working

   Figure 6: Architecture for QoS Inter-Working between Cellular Access
                          and Non-Cellular Access

   During a mobile node's handover from cellular access to non-cellular
   access, e.g., a wireless LAN (WLAN) radio access network, the mobile
   node's QoS policy rules, as previously established on the local
   mobility anchor for the mobile node's communication through the
   cellular access network, are moved to the handover target mobile
   access gateway serving the non-cellular access network.  Such a non-
   cellular mobile access gateway can have an access-technology-specific
   controller or function co-located, e.g., a Wireless LAN Controller
   (WLC), as depicted in option (I) of Figure 6.  Alternatively, the
   access-specific architecture can be distributed, and the access-
   technology-specific control function is located external to the
   mobile access gateway, as depicted in option (II).  In this case, the
   mobile access gateway and the access-technology-specific control

Top      Up      ToC       Page 41 
   function (e.g., the WLC) must provide some protocol for QoS inter-
   working.  Details of such inter-working are out of the scope of this
   specification.

6.2.  Relevant QoS Attributes

   The QoS Option shall at least contain a DSCP value being associated
   with IP flows of a mobility session.  The DSCP value should
   correspond to the 3GPP QoS Class Index (QCI), which identifies the
   type of service in terms of QoS characteristics (e.g., conversational
   voice, streaming video, signaling, and best effort); more details on
   DSCP and QCI mapping are given in Appendix A.  Optional QoS
   information could also be added.  For instance, in order to comply
   with the bearer model defined in 3GPP [TS23.203], the following QoS
   parameters are conveyed for each PMIPv6 mobility session:

   o  Default, non-GBR bearer (QCI=5-9)

      *  DSCP=(BE, AF11, AF21, AF31, AF32)

      *  Per-MN AMBR-UL/DL

      *  Per-Session AMBR-UL/DL {S=1,E=1}

      *  AARP

      APN (Access Point Name) is provided via the Service Selection ID
      defined in [RFC5149].  If APN is not interpreted by Wi-Fi AP, the
      latter will police only based on Per-MN AMBR-UL/DL (without Per-
      Session AMBR-UL/DL) on the Wi-Fi link.

   o  Dedicated, GBR bearer (QCI=1-4)

      *  DSCP=(EF, AF41)

      *  GBR-UL/DL

      *  MBR-UL/DL

      *  AARP

      *  TS

      Wi-Fi AP will perform the policy enforcement with the minimum bit
      rate=GBR and the maximum bit rate=MBR.

Top      Up      ToC       Page 42 
   o  Dedicated, non-GBR bearer (QCI=5-9)

      *  DSCP=(BE, AF11, AF21, AF31, AF32)

      *  Per-MN AMBR-UL/DL

      *  Per-Session AMBR-UL/DL {S=1,E=1}

      *  AARP

      *  TS

      If APN is not interpreted by Wi-Fi AP, it will police based only
      on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi
      link.

   If DSCP values follow the 3GPP specification and deployment, the code
   point can carry intrinsically additional attributes according to
   Figure 7 in Appendix A.

   For some optional QoS attributes, the signaling can differentiate
   enforcement per mobility session and per IP flow.  For the latter, as
   long as the AMBR constraints are met, the rule associated with the
   identified flow(s) overrules the aggregated rules that apply per
   mobile node or per mobility session.  Additional attributes can be
   appended to the QoS option, but their definition and specification is
   out of scope of this document and are left as considerations for
   actual deployment.

7.  IANA Considerations

   IANA has completed the following actions:

   o  Action-1: This specification defines a new mobility option, the
      Quality-of-Service (QoS) option.  The format of this option is
      described in Section 4.1.  The type value 58 for this mobility
      option has been allocated from the "Mobility Options" registry at
      <http://www.iana.org/assignments/mobility-parameters>.

   o  Action-2: This specification defines a new mobility attribute
      format, the Quality-of-Service attribute.  The format of this
      attribute is described in Section 4.2.  This attribute can be
      carried in the Quality-of-Service mobility option.  The type
      values for this attribute are managed by IANA in a new registry,
      the "Quality-of-Service Attribute Registry".  This registry is
      maintained under the "Mobile IPv6 parameters" registry at
      <http://www.iana.org/assignments/mobility-parameters>.  This
      specification reserves the type values listed below.  All other

Top      Up      ToC       Page 43 
      values (12 - 254) are unassigned and may be assigned by IANA using
      the Specification Required policy [RFC5226].  The Designated
      Expert reviewing the value assignment is expected to verify that
      the protocol extension follows the Proxy Mobile IPv6 architecture
      and does not raise backward-compatibility issues with existing
      deployments.

   +=====+=================================+=================+
   |Value|       Description               |   Reference     |
   +=====+=================================+=================+
   | 0   | Reserved                        |   RFC 7222      |
   +=====+===================================================+
   | 1   | Per-MN-Agg-Max-DL-Bit-Rate      |   RFC 7222      |
   +=====+===================================================+
   | 2   | Per-MN-Agg-Max-UL-Bit-Rate      |   RFC 7222      |
   +=====+===================================================+
   | 3   | Per-Session-Agg-Max-DL-Bit-Rate |   RFC 7222      |
   +=====+===================================================+
   | 4   | Per-Session-Agg-Max-UL-Bit-Rate |   RFC 7222      |
   +=====+===================================================+
   | 5   | Allocation-Retention-Priority   |   RFC 7222      |
   +=====+===================================================+
   | 6   | Aggregate-Max-DL-Bit-Rate       |   RFC 7222      |
   +=====+===================================================+
   | 7   | Aggregate-Max-UL-Bit-Rate       |   RFC 7222      |
   +=====+===================================================+
   | 8   | Guaranteed-DL-Bit-Rate          |   RFC 7222      |
   +=====+===================================================+
   | 9   | Guaranteed-UL-Bit-Rate          |   RFC 7222      |
   +=====+===================================================+
   | 10  | QoS-Traffic-Selector            |   RFC 7222      |
   +=====+===================================================+
   | 11  | QoS-Vendor-Specific-Attribute   |   RFC 7222      |
   +=====+===================================================+
   | 255 | Reserved                        |   RFC 7222      |
   +=====+===================================================+

   o  Action-3: This document defines a new status code,
      CANNOT_MEET_QOS_SERVICE_REQUEST (179), for use in Proxy Binding
      Acknowledgement messages, as described in Section 4.3.  This value
      has been assigned from the "Status Codes" registry at
      <http://www.iana.org/assignments/mobility-parameters>.

   o  Action-4: This document defines a new Notification Reason,
      QOS_SERVICE_REQUEST (5), for use in Update Notification messages
      [RFC7077] as described in Section 4.4.  This value has been
      assigned from the "Update Notification Reasons Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.

Top      Up      ToC       Page 44 
   o  Action-5: This document defines a new status code,
      CANNOT_MEET_QOS_SERVICE_REQUEST (130), for use in Update
      Notification Acknowledgement messages [RFC7077] as described in
      Section 4.5.  This value has been assigned from the "Update
      Notification Acknowledgement Status Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.

8.  Security Considerations

   The Quality-of-Service option defined in this specification is for
   use in Proxy Binding Update, Proxy Binding Acknowledgement, Update
   Notification, and Update Notification Acknowledgement messages.  This
   option is carried in these messages like any other mobility header
   option.  [RFC5213] and [RFC7077] identify the security considerations
   for these signaling messages.  When included in these signaling
   messages, the Quality-of-Service option does not require additional
   security considerations.

9.  Acknowledgements

   The authors of this document thank the members of NetExt working
   group for the valuable feedback to different versions of this
   specification.  In particular, the authors want to thank Basavaraj
   Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson,
   Tricci So, Ahmad Muhanna, Pete McCann, Byju Pularikkal, John
   Kaippallimalil, Rajesh Pazhyannur, Carlos J. Bernardos Cano, Michal
   Hoeft, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, and Georgios
   Karagiannis.

   The authors would like to thank all the IESG reviewers, especially,
   Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen
   Farrell, Ted Lemon, and Alia Atlas for their valuable comments and
   suggestions to improve this specification.

   Finally, the authors would like to express sincere and profound
   appreciation to our Internet Area Director, Brian Haberman, for his
   guidance and great support in allowing us to complete this work.

10.  References

10.1.  Normative References

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

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

Top      Up      ToC       Page 45 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088, January
              2011.

   [RFC7077]  Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              RFC 7077, November 2013.

10.2.  Informative References

   [GSMA.IR.34]
              GSMA, "Guidelines for IPX Provider networks (Previously
              Inter-Service Provider IP Backbone Guidelines)", Official
              Document PRD IR.34, May 2013.

   [IEEE802.11-2012]
              IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications", 2012.

   [IEEE802.11aa-2012]
              IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications, Amendment 2: MAC
              Enhancements for Robust Audio Video Streaming", 2012.

   [IEEE802.11e-2005]
              IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications, Amendment 8:
              Medium Access Control (MAC) Quality of Service (QoS)
              Enhancements", 2005.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

Top      Up      ToC       Page 46 
   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594, August
              2006.

   [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
              Selection for Mobile IPv6", RFC 5149, February 2008.

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089, January
              2011.

   [SMI]      IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
              Private Enterprise Codes, April 2014,
              <http://www.iana.org/assignments/enterprise-numbers>.

   [TS22.115] 3GPP, "Technical Specification Group Services and System
              Aspects; Service aspects; Charging and billing", 3GPP TS
              22.115, 2010.

   [TS23.203] 3GPP, "Technical Specification Group Services and System
              Aspects; Policy and charging control architecture", 3GPP
              TS 23.203, 2013.

   [TS23.207] 3GPP, "End-to-End Quality of Service (QoS) Concept and
              Architecture, Release 10", 3GPP TS 23.207, 2011.

   [TS23.402] 3GPP, "Technical Specification Group Services and System
              Aspects; Architecture enhancements for non-3GPP accesses",
              3GPP TS 23.402, 2012.

   [TS29.212] 3GPP, "Policy and Charging Control over Gx/Sd Reference
              Point, Release 11", 3GPP TS 29.212, 2011.

   [WMM1.2.0] Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification
              (with WMM-Power Save and WMM-Admission Control)", Version
              1.2.0.

Top      Up      ToC       Page 47 
Appendix A.  Information When Implementing 3GPP QoS in IP Transport
             Network

A.1.  Mapping Tables

   Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34]
   as follows.

   +=====+================+===========================+======+
   | QCI | Traffic Class  | DiffServ Per-Hop-Behavior | DSCP |
   +=====+================+===========================+======+
   |  1  | Conversational |              EF           |101110|
   +=====+===================================================+
   |  2  | Conversational |              EF           |101110|
   +=====+===================================================+
   |  3  | Conversational |              EF           |101110|
   +=====+===================================================+
   |  4  |   Streaming    |             AF41          |100010|
   +=====+===================================================+
   |  5  |  Interactive   |             AF31          |011010|
   +=====+===================================================+
   |  6  |  Interactive   |             AF32          |011100|
   +=====+===================================================+
   |  7  |  Interactive   |             AF21          |010010|
   +=====+===================================================+
   |  8  |  Interactive   |             AF11          |001010|
   +=====+===================================================+
   |  9  |   Background   |              BE           |000000|
   +=====+===================================================+

                     Figure 7: QCI/DSCP Mapping Table

   Mapping between QoS attributes defined in this document and 3GPP QoS
   parameters is as follows.

Top      Up      ToC       Page 48 
          +=======+===============================+=============+
          |Section|        PMIPv6 QoS             |  3GPP QoS   |
          |       |        Attribute              | Parameter   |
          +=======+===============================+=============+
          | 4.2.1 |   Per-MN-Agg-Max-DL-Bit-Rate  |  UE AMBR-DL |
          +-------+-------------------------------+-------------+
          | 4.2.2 |   Per-MN-Agg-Max-UL-Bit-Rate  |  UE AMBR-UL |
          +-------+-------------------------------+-------------+
          | 4.2.3 |Per-Session-Agg-Max-DL-Bit-Rate| APN AMBR-DL |
          |       |          Flags: (S=1, E=1)    |             |
          +-------+-------------------------------+-------------+
          | 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL |
          |       |          Flags: (S=1, E=1)    |             |
          +-------+-------------------------------+-------------+
          | 4.2.5 | Allocation-Retention-Priority |     ARP     |
          +-------+-------------------------------+-------------+
          | 4.2.6 |   Aggregate-Max-DL-Bit-Rate   |    MBR-DL   |
          +-------+-------------------------------+-------------+
          | 4.2.7 |   Aggregate-Max-UL-Bit-Rate   |    MBR-UL   |
          +-------+-------------------------------+-------------+
          | 4.2.8 |    Guaranteed-DL-Bit-Rate     |    GBR-DL   |
          +-------+-------------------------------+-------------+
          | 4.2.9 |    Guaranteed-UL-Bit-Rate     |    GBR-UL   |
          +-------+-------------------------------+-------------+
          | 4.2.10|     QoS-Traffic-Selector      |     TFT     |
          +-------+-------------------------------+-------------+

      Figure 8: QoS Attributes and 3GPP QoS Parameters Mapping Table

A.2.  Use Cases and Protocol Operations

   The following subsections provide example message flow charts for
   scenarios where the QoS option extensions will apply as described in
   Section 6.1 to the protocol operation for QoS rules establishment
   (Appendices A.2.1 and A.2.2) and to modification (Appendix A.2.3).

A.2.1.  Handover of Existing QoS Rules

   In Figure 9, the MN is first connected to the LTE network with a
   multimedia session, such as a video call, with appropriate QoS
   parameters set by the Policy Control Function.  Then, the MN
   discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it,
   provided that Wi-Fi access has a higher priority when available.  Not
   only is the session continued, but the QoS is also maintained after
   moving to the Wi-Fi access.  In order for that to happen, the LMA
   delivers the QoS parameters according to the bearer type on the 3GPP
   access to the MAG via the PMIPv6 signaling with the QoS option

Top      Up      ToC       Page 49 
   (OC=ALLOCATE, SR-ID, QoS attributes, etc.).  The equivalent QoS
   treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi
   link.

                                              +--------+
                                              |Policy  |
                                              |Control |
                                              |Function|
                                              +---+----+
                                                  |
          +----+       +-------+              +---+----+
    +--+  |LTE |_______|  SGW  |              |  PGW   |
    |MN|~~|eNB |       |       |==============| (LMA)  |
    +--+  +----+       +-------+            //+--------+
     :                                     //
     :                                    //
     V    +----+       +-------+ PMIPv6  //
    +--+  |WiFi|_______|  WLC  |=========
    |MN|~~| AP |       | (MAG) | tunnel
    +--+  +----+       +-------+

              Figure 9: Handover Scenario (from LTE to WLAN)

   Figure 10 shows an example of how the QoS rules can be conveyed and
   enforced between the LMA and MN in the case of a handover from 3GPP
   access to WLAN access.

Top      Up      ToC       Page 50 
   +--+            +--+             +---+                       +---+
   |MN|            |AP|             |MAG|                       |LMA|
   +--+            +--+             +---+                       +---+
    ||              |                 |     To                    |data
    |+--detach      |                 |  cellular<-==data[DSCP]==-|<----
    +----attach-----+                 |   access             [QoS rules]
    |               |-INFO[MNattach]->|                           |
    |               |                 |-------PBU[handover]------>|
    |               |                 |                           |
    |               |                 |<--PBA[QoS option(OC=1 )]--|
    |               |<-INFO[QoSrules]-|                           |
    |               |                 |                           |
    |             Apply            Establish                   Update
    |             mapped          MN's uplink              MN's downlink
    |            QoS rules        DSCP rules                 DSCP rules
    |               |                 +===========================+
    |               |                 |                           |
    |               |(B)              |(A)                        |data
    |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
    |               |                 |                           |
    |               |                 |                           |data
    |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|--->
    |               |(C)              |(D)                        |
    |               |                 |                           |

   (A): Apply DSCP at link to AP
   (B): Enforce mapped QoS rules to access technology
   (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or
        validate MN-indicated QC and apply DSCP on the AP-MAG link
        according to QoS rules
   (D): Validate received DSCP and apply DSCP according to QoS rules

                     Figure 10: Handover of QoS Rules

A.2.2.  Establishment of QoS Rules

   A single operator has deployed both a fixed access network and a
   mobile access network.  In this scenario, the operator may wish a
   harmonized QoS management on both accesses, but the fixed access
   network does not implement a QoS control framework.  So, the operator
   chooses to rely on the 3GPP policy control function, which is a
   standard framework to provide a QoS control, and to enforce the 3GPP
   QoS policy on the Wi-Fi access network.  The PMIP interface is used
   to realize this QoS policy provisioning.

   The use case is depicted on Figure 11.  The MN first attaches to the
   Wi-Fi network.  During the attachment process, the LMA, which may
   communicate with Policy Control Function (using procedures outside

Top      Up      ToC       Page 51 
   the scope of this document), provides the QoS parameters to the MAG
   via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e., PBA).
   Subsequently, an application on the MN may trigger the request for
   alternative QoS resources, e.g., by use of the WMM-API (Wi-Fi
   Multimedia - API).  The MN may request that traffic resources be
   reserved using L2 signaling, e.g., sending an Add Traffic System
   (ADDTS) message [IEEE802.11-2012].  The request is relayed to the
   MAG, which includes the QoS parameters in the QoS option
   (OC=ALLOCATE) on the PMIP signaling (i.e., the PBU initiated upon
   flow creation).  The LMA, in coordination with the PCF, can then
   authorize the enforcement of such QoS policy.  Then, the QoS
   parameters are provided to the MAG via the QoS option (OC=ALLOCATE,
   SR-ID, QoS attributes, etc.) in the PMIP signaling, and the
   equivalent QoS treatment is provided towards the MN on the Wi-Fi
   link.

                                            |
                                            |
                                            | +--------+
                                            | |Policy  |
                                            | |Control |
                                            | |Function|
                                            | +---+----+
                                            |     |
                                            | +---+----+
              +----+       +-------+ PMIPv6 | |  PGW   |
        +--+  |WiFi|_______|  WLC  |========|=| (LMA)  |
        |MN|~~| AP |       | (MAG) | tunnel | +--------+
        +--+  +----+       +-------+        |
                                            |
                         Wi-Fi Access       |
                          Network           |   Cellular
                                            |    Network
                                            |

                    Figure 11: QoS Policy Provisioning

   Figure 12 shows an example of how the QoS rules can be conveyed and
   enforced between the LMA and MN in the case of initial attachment to
   WLAN access.

Top      Up      ToC       Page 52 
   +--+            +--+             +---+                       +---+
   |MN|            |AP|-------------|MAG|-----------------------|LMA|
   +--+            +--+             +---+                       +---+
    |               |                 |                           |
    |               |                 |                           |
    +----attached---+                 |                      [QoS rules]
    |               |                 |                           |
   new session      |(E)              |(F)                        |data
    |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|--->
    |               |                 |--PBU[update,QoS option]-->|
    |               |                 |     (ReReg) (OC=1) Validate and
    |               |                 |                     add QoS rule
    |               |                 |<----PBA[QoS option]----|
    |               |<-INFO[QoSrules]-|        (OC=1, SR-ID)[QoS rules']
    |               |                 |                           |
    |             Apply           Establish                       |
    |            adapted         MN's uplink                      |
    |           QoS rules        DSCP rules                       |
    |               |                 |                           |
    |               |                 |                           |
    |               |                 |                           |data
    |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
    |               |                 |                           |
    |               |                 |                           |data
    |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|--->
    |               |                 |                           |
    |               |                 |                           |

   (E): AP may enforce uplink QoS rules according to priority class
        set by the MN
   (F): MAG can enforce a default QoS class until the local mobility
        anchor classifies the new flow (notified with PBA) or the mobile
        access gateway classifies new flow and proposes the associated
        QoS class to the local mobility anchor for validation (proposed
        with PBU, notification of validation result with PBA)

      Figure 12: Adding New QoS Service Request for MN-Initiated Flow

A.2.3.  Dynamic Update to QoS Policy

   A mobile node is attached to the WLAN access and has obtained QoS
   parameters from the LMA for that mobility session.  Having obtained
   the QoS parameters, a new application, e.g., IP Multimedia Subsystems
   (IMS) application, gets launched on the mobile node that requires
   certain QoS support.

Top      Up      ToC       Page 53 
   The application on the mobile node initiates the communications via a
   dedicated network function (e.g., IMS Call Session Control Function).
   Once the communication is established, the application network
   function notifies the PCF about the new IP flow.  The PCF function in
   turn notifies the LMA about the needed QoS parameters identifying the
   IP flow and QoS parameters.  LMA sends an Update Notification message
   [RFC7077] to the MAG with the Notification Reason value set to
   QOS_SERVICE_REQUEST.  On receiving the Update Notification message,
   the MAG completes the PBU/PBA signaling for obtaining the new QoS
   parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes,
   etc.).  The MAG provisions the newly obtained QoS parameters on the
   access network to ensure the newly established IP flow gets its
   requested network resources.

   Upon termination of the established IP flow, the application function
   again notifies the PCF function to remove the established QoS
   parameters.  The PCF notifies the LMA to withdraw the QoS resources
   established for that voice flow.  The LMA sends an Update
   Notification message to the MAG with the "Notification Reason" value
   set to "FORCE-REREGISTRATION".  On receiving this Update Notification
   Acknowledgement message, the MAG completes the PBU/PBA signaling for
   removing the existing QoS rules (OC=DE-ALLOCATE, SR-ID).  The MAG
   then removes the QoS parameters from the corresponding IP flow and
   releases the dedicated network resources on the access network.

Appendix B.  Information When Implementing PMIP-Based QoS Support with
             IEEE 802.11e

   This section shows, as an example, the end-to-end QoS management with
   a 802.11e-capable WLAN access link and a PMIP-based QoS support.

   The 802.11e, or Wi-Fi Multimedia (WMM), specification provides
   prioritization of packets for four types of traffic, or access
   categories (ACs):

      Voice (AC_VO): Very high-priority queue with minimum delay.  Time-
      sensitive data such as VoIP and streaming mode are automatically
      sent to this queue.

      Video (AC_VI): High-priority queue with low delay.  Time-sensitive
      video data is automatically sent to this queue.

      Best effort (AC_BE): Medium-priority queue with medium throughput
      and delay.  Most traditional IP data is sent to this queue.

      Background (AC_BK): Lowest-priority queue with high throughput.
      Bulk data that requires maximum throughput but is not time-
      sensitive (for example, FTP data) is sent to the queue.

Top      Up      ToC       Page 54 
   The access point uses the 802.11e indicator to prioritize traffic on
   the WLAN interface.  On the wired side, the access point uses the
   802.1p priority tag and DSCP.  To allow consistent QoS management on
   both wireless and wired interfaces, the access point relies on the
   802.11e specification, which defines mapping between the 802.11e
   access categories and the IEEE 802.1D priority (802.1p tag).  The
   end-to-end QoS architecture is depicted in Figure 13, and the 802.11e
   /802.1D priority mapping is shown in the following table:

                     +-----------+------------------+
                     | 802.1e AC | 802.1D priority  |
                     +-----------+------------------+
                     |  AC_VO    |       7,6        |
                     +-----------+------------------+
                     |  AC_VI    |       5,4        |
                     +-----------+------------------+
                     |  AC_BE    |       0,3        |
                     +-----------+------------------+
                     |  AC_BK    |       2,1        |
                     +-----------+------------------+


                +=============+                          +-----+
                 DSCP/802.1p                             | PDP |
                 mapping table                           +-----+
                +=============+     PEP                     |
                         `._     +---+---+                  |
                            `._  |WiFi AR|    PMIPv6     +-----+
                               - + (MAG) +===============| LMA |
                                 |  WLC  |    tunnel     +-----+
                                 +-------+                 PEP
                                     |
                    ==Video==   802.1p/DSCP
                    ==Voice==        |
                    == B.E.==     +----+
             +----+               |WLAN| PEP
             | MN |----802.11e----| AP |
             +----+               +----+

             Figure 13: End-to-End QoS Management with 802.11e

   When receiving a packet from the MN, the AP checks whether the frame
   contains 802.11e markings in the L2 header.  If not, the AP checks
   the DSCP field.  If the uplink packet contains the 802.11e marking,
   the access point maps the access categories to the corresponding
   802.1D priority as per the table above.  If the frame does not
   contain 802.11e marking, the access point examines the DSCP field.

Top      Up      ToC       Page 55 
   If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e.,
   802.1D priority).  This mapping is not standardized and may differ
   between operators; a mapping example is given in the following table.

                +-------------------+--------+------------+
                | Type of traffic   | 802.1p | DSCP value |
                +-------------------+--------+------------+
                |  Network Control  |   7    |     56     |
                +-------------------+--------+------------+
                |  Voice            |   6    |  46 (EF)   |
                +-------------------+--------+------------+
                |  Video            |   5    | 34 (AF 41) |
                +-------------------+--------+------------+
                |  Voice Control    |   4    | 26 (AF 31) |
                +-------------------+--------+------------+
                | Background Gold   |   2    | 18 (AF 21) |
                +-------------------+--------+------------+
                | Background Silver |   1    | 10 (AF 11) |
                +-------------------+--------+------------+
                |  Best Effort      |  0,3   |  0 (BE)    |
                +-------------------+--------+------------+

   The access point prioritizes ingress traffic on the Ethernet port
   based on the 802.1p tag or the DSCP value.  If the 802.1p priority
   tag is not present, the access point checks the DSCP/802.1p mapping
   table.  The next step is to map the 802.1p priority to the
   appropriate egress queue.  When 802.11e support is enabled on the
   wireless link, the access point uses the IEEE standardized 802.1p/
   802.11e correspondence table to map the traffic to the appropriate
   hardware queues.

   When the 802.11e-capable client sends traffic to the AP, it usually
   marks packets with a DSCP value.  In that case, the MAG/LMA can come
   into play for QoS renegotiation and call flows depicted in Appendix A
   apply.  Sometimes, when communication is initiated on the WLAN
   access, the application does not mark upstream packets.  If the
   uplink packet does not contain any QoS marking, the AP/MAG could
   determine the DSCP field according to traffic selectors received from
   the LMA.  Figure 14 gives the call flow corresponding to that use
   case and shows where QoS tags mapping does come into play.  The main
   steps are as follows:

      (A): During the MN attachment process, the MAG fetches QoS
      policies from the LMA.  After this step, both the MAG and LMA are
      provisioned with QoS policies.

Top      Up      ToC       Page 56 
      (B): The MN starts a new IP communication without making IP
      packets with DSCP tags.  The MAG uses the traffic selector to
      determine the DSCP value; it then marks the IP packet and forwards
      within the PMIP tunnel.

      (C): The LMA checks the DSCP value with respect to the traffic
      selector.  If the QoS policies are valid, the LMA forwards the
      packet without renegotiating the QoS rules.

      (D): When receiving a marked packet, the MAG, the AP, and the MN
      use 802.11e (or WMM), 802.1p tags, and DSCP values to prioritize
      the traffic.

     +--+            +--+             +---+                     +---+
     |MN|            |AP|             |MAG|                     |LMA|
     +--+            + -+             +---+                     +---+
   (A)|----attach-----|---------------->|-----------PBU---------->|
      |<--------------|---------------- |<----PBA[QoS option]-----|
      .               .            [QoS rules]              [QoS rules]
   (B).               .                 .                         |
     new session      |                 |                         |
      |----data[]---->|----data[]------>|-======data[DSCP]======->|
      |               |                 |                         |
   (C)|               |                 |              Validate QoS rule
      |               |                 |                         |--->
      |               |                 |<======data[DSCP]========|<----
      |               |                 |                         |
      |               |               mapping                     |
   (D)|               |            DSCP/802.1p                    |
      |               |<----data--------|                         |
      |               |  [802.1p/DSCP]  |                         |
      |               |                 |                         |
      |             mapping             |                         |
      |          802.1p/802.11e         |                         |
      |<--data[WMM]---|                 |                         |
      |               |                 |                         |
      |---data[WMM]-->|------data------>|=======data[DSCP]=======>|--->
      |               |  [802.1p/DSCP]  |                         |
      |               |                 |                         |

      Figure 14: Prioritization of a Flow Created on the WLAN Access

Top      Up      ToC       Page 57 
Appendix C.  Information When Implementing with a Broadband Network
             Gateway

   This section shows an example of QoS interworking between the PMIPv6
   domain and the broadband access.  The Broadband Network Gateway (BNG)
   or Broadband Remote Access Server (BRAS) has the MAG function, and
   the CPE (Customer Premise Equipment) or Residential Gateway (RG) is
   connected via the broadband access network.  The MN is attached to
   the RG via, e.g., Wi-Fi AP in the broadband home network.  In the
   segment of the broadband access network, the BNG and RG are the
   Policy Enforcement Point (PEP) for the downlink and uplink traffic,
   respectively.  The QoS information is downloaded from the LMA to the
   BNG via the PMIPv6 with the QoS option defined in this document.
   Based on the received QoS parameters (e.g., DSCP values), the
   broadband access network and the RG provide appropriate QoS treatment
   to the downlink and uplink traffic to/from the MN.

                                                         +-----+
                                                         | PDP |
                                                         +-----+
                                    PEP                     |
                                 +-------+                  |
                                 | BNG/  |    PMIPv6     +-----+
                                 | BRAS  +===============| LMA |
                                 | (MAG) |    tunnel     +-----+
                                 +-------+                 PEP
                      Broadband  (   |   )
                        Access  (   DSCP  )
                       Network   (   |   )
                                  +-----+
               +----+             | CPE | PEP
               | MN |-------------| /RG |
               +----+  Broadband  +-----+
                      Home Network

      Figure 15: End-to-End QoS Management with the Broadband Access
                                  Network

   In the segment of the broadband access network, QoS mapping between
   3GPP QCI values and DSCP described in Section 6.2 is applied.  In the
   segment of the broadband home network, if the MN is attached to the
   RG via Wi-Fi, the same QoS mapping as described in Appendix B can be
   applied.

Top      Up      ToC       Page 58 
Authors' Addresses

   Marco Liebsch
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  D-69115
   Germany

   EMail: liebsch@neclab.eu


   Pierrick Seite
   Orange
   4, rue du Clos Courtel, BP 91226
   Cesson-Sevigne  35512
   France

   EMail: pierrick.seite@orange.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Saitama, Fujimino  356-8502
   Japan

   EMail: yokota@kddilabs.jp


   Jouni Korhonen
   Broadcom Communications
   Porkkalankatu 24
   Helsinki  FIN-00180
   Finland

   EMail: jouni.nospam@gmail.com


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   EMail: sgundave@cisco.com