[netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt

[Ahmad Muhanna <[e-mail]>]

Hello,

Please find my review comments for Rev 01 of the I-D
(draft-ietf-netext-pmipv6-sipto-option) below:


I have mainly editorial comments that need clarification and a couple of minor technical ones below.

Regards,
Ahmad

>>>>>

1.  Introduction

   Mobile Operators are expanding their network coverage by integrating
   various access technology domains into a common IP mobile core.

   For
   providing IP mobility support to a mobile node irrespective of the
   access network to which it is attached, the 3GPP S2/a Proxy Mobile
   IPv6 [TS23402] interface, specified by the 3GPP system architecture,
   is providing the needed protocol glue.
[Ahmad-01]
why we are using S2/a rather than S2a?

[Ahmad-02]
Please replace 'is providing' with 'provides'

   When this protocol interface
   based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is
   topologically anchored on the local mobility anchor [RFC5213] in the
   home network.

[Ahmad-03]
when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, the mobile node ...

[Ahmad-04]
Is it "anchored on" or "anchored at"?

   The mobile node's IP traffic is always tunneled back
   from the mobile access gateway [RFC5213] in the access network to the
   local mobility anchor in the home network.

   However, with the exponential growth in the mobile data traffic,
   mobile operators are exploring new ways to offload some of the IP
   traffic flows at the nearest access edge where ever there is an
   internet peering point, as supposed to carrying it all the way to the
   mobility anchor in the home network.  Not all IP traffic needs to be
   routed back to the home network, some of the non-essential traffic
   which does not require IP mobility support can be offloaded at the
   mobile access gateway in the access network.  This approach provides
   greater leverage and efficient usage of the mobile packet core with
   increased overall network capacity and by lowering transport costs.

[Ahmad-06]
I have problem with the last sentence above... what are we trying to say?

May be something like follows:
"With increased overall network capacity, this approach provides greater leverage and efficient usage of the mobile packet core which help lowering transport cost" Hope it makes it read better! :-)


   The local mobility anchor in the home network can potentially deliver
   the IP flow selectors to the mobile access gateway in the access
   network, for identifying the IP flows that needs to be offloaded.

   This document defines a new mobility option, IP Traffic Offload
   Selector option for Proxy Mobile IPv6 (PMIPv6).  This option can be
   used by the local mobility anchor for notifying the flow selectors
   for that can be used by the local mobility anchor for notifying the
   mobile access gateway flows that can be offloaded at the access edge.

[Ahmad-07]
This is a little confusing; sounds as if the notification goes to the flow selectors. What about?
"This option can be used by the local mobility anchor to notify the mobile access gateway with the flow selectors that can be offloaded at the access edge."


   Since, the mobile node's IP address topologically belongs to the home
   network, the offloaded IP traffic flows need to be NAT [RFC2663]
   translated.  Given this NAT translation requirement for the offloaded
   traffic, this approach will be limited to mobile node's IPv4 flows.

   There are better ways to solve this problem for IPv6 and with the
   goal not to create NAT66 requirement,
[Ahmad-08]
Can we remove the above sentence? and start the sentence with the following portion.

  This specification does not
   support traffic offload support for IPv6 flows.  This document also
   does not define any new semantics for flow selectors.  The flow
   identification and the related semantics are all leveraged from
   [RFC6088].


2.  Conventions and Terminology

2.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in the base Proxy Mobile IPv6 specifications
   [RFC5213] and [RFC5844].  Additionally, this document uses the
   following abbreviations:

   IP Flow

      IP Flow represents a set of IP packets that match a traffic
      selector.  The selector is typically based on the source IP
      address, destination IP address, source port, destination port and
      other fields in upper layer headers.

   Selective IP Traffic Offload (SIPTO)

      The approach of selecting specific IP flows and routing them to
      the local network, as supposed to tunneling them to the home
      network.

   NAT (Network Address Translation)

      Network Address Translation [RFC2663] is a method by which IP
      addresses are mapped from one address realm to another, providing
      transparent routing to end hosts.
[Ahmad-09]
Do we need to include this terminology?


3.  Solution Overview

   The following illustrates the scenario where the mobile access
   gateway in an access network having the ability to offload some of
   the IPv4 traffic flows, based on the traffic selectors it received
   from the local mobility anchor in the home network.  For example, all
   the HTTP flows may be be offloaded at the mobile access gateway and
   all the other flows for that mobility session are tunneled back to
   the local mobility anchor.




            _----_
          _(      )_
         ( Internet )
          (_      _)
            '----'
              |
   (IPv4 Traffic Offload Point
    at access edge gateway for
    non-essential traffic
    Ex: HTTP Traffic Offloaded)
              |
   ......................................................
              |               .        +----------------+
            +---+             .        | Operator Value |
            |NAT|             .        | Added Services |
            +---+             .        +----------------+
              |            _----_             |
           +-----+       _(      )_       +-----+
   [MN]----| MAG |======(    IP    )======| LMA |-- Internet
           +-----+       (_      _)       +-----+
                           '----'      (
                              .
                              .
                              .
       [Access Network]       .        [Home Network]
   ......................................................

                 Figure 1: Access Networks attached to MAG



3.1.  LMA Considerations

   The following considerations apply to the local mobility anchor and
   the mobile access gateway.
[Ahmad-10]
Is this a common section then?

   Figure 1 explains the operational sequence of the IP Traffic Offload
   selectors between the mobile access gateway and the local mobility
   anchor.


   MN    MAG(NAT)   LMA
   |------>|        |    1. Mobile Node Attach
   |       |------->|    2. Proxy Binding Update
   |       |<-------|    3. Proxy Binding Acknowledgement (IPTS Option)
   |       |========|    4. Tunnel/Route Setup
   |       +        |    5. Installing the traffic offload rules
   |------>|        |    6. IPv4 packet from mobile node
   |       |        |    7. Forwarding rule - Tunnel home/offload
   |       |        |



            Figure 2: Exchange of IP Traffic Offload Selectors

   o  If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option Section 4, but if the configuration
      variable, EnableIPTrafficOffloadSupport on the local mobility
      anchor is set to a value of (0), then the local mobility anchor
      MUST ignore the IP Traffic Offload Selector Option and process the
      rest of the packet.  This would not have no effect on the
      operation of the rest of the protocol.

   o  If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option Section 4, and if the configuration
      variable, EnableIPTrafficOffloadSupport on the local mobility
      anchor is set to a value of (1), then the local mobility anchor
      can construct the traffic selectors based on the offload policy
      and deliver those selectors in the Proxy Binding Acknowledgement
      message using the IP Traffic Offload Selector Option.
[Ahmad-11]
Why NOT use the following: "the local mobility anchor (identify/or acquire) the traffic selectors based on.... This will encompass the possibility for the LMA to receive the offload policy via a different infrastructure node, e.g., PCRF. Just a suggestion.

      However, if
      the received Proxy Binding Update included a proposed Offload
      traffic selectors, the local mobility anchor MAY choose to honor
      that request and include the proposed selectors in the reply.

3.2.  MAG Considerations

   o  If the configuration variable, EnableIPTrafficOffloadSupport on
      the mobile access gateway is set to a value of (0), then the
      mobile access gateway MUST NOT include the IP Traffic Offload
      Selector Option Section 4 in the Proxy Binding Update message that
      it sends to the local mobility anchor.  Otherwise, the option MUST
      be included in the Proxy Binding Update message.

      When this option
      is included, it is an indication to the local mobility anchor that
      the mobile access gateway is capable of supporting IP Traffic
      Offload support.  The TS format field of the IP Traffic Offload

[Ahmad-12]
Have we defined what TS before now?

      Selector Option MUST be set to a value of (0), indicating that the
      mobile access gateway is not proposing any specific offload policy
      for that mobility session, but a request to the local mobility
      anchor to provide the IP traffic offload flow selectors for that
      mobility session.

   o  The mobility access gateway MAY choose to include its proposed IP
      traffic offload flow selectors in the IP Traffic Offload Selector
      Option Section 4.  Including this offload traffic spec serves as a
[Ahmad-13]
"Including this offload traffic selectors serves ..."

      proposal to the local mobility anchor, which the local mobility
      anchor can override with its own offload policy, or agree to the
      proposed policy.  When including the offload traffic selectors,
      the TS format field of the IP Traffic Offload Selector Option MUST
      be set to the respective flow specification type.

   o  If there is no IP Traffic Offload Selector Option in the
      corresponding Proxy Binding Acknowledgement message, that the
      mobile access gateway receives in response to a Proxy Binding
      Update, it serves as an indication that the local mobility anchor
      does not support IP Traffic Offload support for that mobility
      session, and it implies the local mobility anchor cannot deliver
      IP flow selectors for that mobility session.

      The mobility access
[Ahmad-14]
What the mobility access means here? is that a term that is defined somewhere?

      upon accepting the Proxy Binding Acknowledgement message MUST NOT
      enable any offload policy for that mobility session.  All the
      mobile node's IP flows MUST be tunneled back to the local mobility
      anchor.

   o  If there is IP Traffic Offload Selector Option in the
      corresponding Proxy Binding Acknowledgement message, it is an
      indication that the local mobility anchor has provided the IP
      traffic Offload selectors for that mobility session and the
      identified IP flows have to be offloaded.  Considerations related
      to (M) flag MUST be applied.
[Ahmad-15]
what about MAG handling of the TS option in BA when the MAG has not sent it in the BU? I believe this is a valid scenario that needs to be addressed.



4.  IP Traffic Offload Selector Option

   A new mobility option, IP Traffic Offload Selector option, is defined
   for using it in Proxy Binding Update (PBU) and Proxy Binding
   Acknowledgement (PBA) messages exchanged between a local mobility
   anchor and a mobile access gateway.

[Ahmad-16]
"A new mobility option, IP Traffic Offload Selector option, is defined
   for using it in Proxy Binding Update (PBU) and Proxy Binding
   Acknowledgement (PBA) messages exchanged between a mobile access gateway and a local mobility anchor." seems that the draft always mentions LMA first! :-)


   This option is used for carrying
   the flow selectors for supporting IP traffic offload function at the
   mobile access gateway.
[Ahmad-17]
I think we should use the word enforcing/or enabling rather than supporting for the sentence to read as follows:
"This option is used for carrying the flow selectors for enforcing/enabling IP traffic offload function at the mobile access gateway."


   The alignment requirement for this option is 4n.


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Type     |   Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|             Reserved                        |    TS Format  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Traffic Selector ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: IP Traffic Offload Selector Option


   Type
      <IANA-1>

   Length
      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.

   Reserved
[Ahmad-18] Insert line.
      This field is unused for now.  The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

   IP Traffic Offload Mode Flag
[Ahmad-19] Insert line.

      This field indicates the offload mode.
      If the (M) flag value is set to a value of (1), it is an
      indication that all the flows except the identified IP flow(s) in
      this mobility option needs to be offloaded at the mobile access
      gateway.  If the (M) flag value is set to a value of (0), it is an
      indication that the identified IP flow(s) needs to be offloaded at
      the mobile access gateway and all other IP flows associated with
      that mobility session needs to be tunneled to the local mobility
      anchor.
[Ahmad-20]
We need to add >>some text<< under the MAG consideration to mention that despite the M flag value in the TS Option in the BU, the setting by the LMA in the BA overrides. something like that.

   TS Format
[Ahmad-21] Insert line.

      An 8-bit unsigned integer indicating the Traffic Selector
      Format.  The value of "0" is reserved and is used when there are
      no selectors to carry, relevant when the option is used as a
      capability indicator.  The value of (1) is assigned for IPv4
      Binary Traffic Selector [RFC6088].
[Ahmad-22]
should not we mention that all other values are reserved?

   TS Selector
[Ahmad-23] Insert line.

      A variable-length opaque field for including the traffic
      specification identified by the TS format field.
[Ahmad-24]
Should not we say: " ... identified by the TS format field and the IP Traffic Offload Mode Flag" Just wondering. the key word here "identified"


      When the value
      of TS Format field is set to (1), the format that follows is the
      IPv4 Binary Traffic Selector specified in section 3.1 of
      [RFC6088].