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

[Ahmad Muhanna <[e-mail]>]

Thanks Sri.

Just one minor follow-up:

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


You meant "mobility session" ? Its defined in the base spec. Let me add a
reference.

[Ahmad]
Hmmmm; it seems that there is a "gateway" word missing.
The original text below.


"

                                                     The mobility access
      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.
 "

Thanks Sri for the quick reply.

Regards,
Ahmad

-----Original Message-----
From: Sri Gundavelli [mailto:[e-mail]]
Sent: Monday, January 30, 2012 6:30 PM
To: Ahmad Muhanna; [e-mail]
Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt

Hi Ahmad,

Thanks for the review. Please see inline.



On 1/30/12 8:19 AM, "Ahmad Muhanna" <[e-mail]> wrote:

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

Yes, it should be s2a.


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

Ok

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

I can rephrase.


>    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?
>
Without offload, all the user plane traffic is going through the PGW. With the approach specified in this document, some of the non-essential traffic can be offloaded at the access edge, as supposed to carrying it through EPC.
In essence this results in:

- Efficient usage of the packet core; by virtue or carrying select traffic
- Lowers the transport cost; if the packet core is considered as a premium resource and using it only for select traffic and offloading all the other traffic through the cheaper access, say WLAN.



> 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! :-)
>

Ok. I can rephrase the text.


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

Ok. I can rephrase it.


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

Well, the scope of the document is only for IPv4. If we say it applies for
IPv6 user flows, we need a NAT66 gateway. I'm not sure, chairs will agree :), Raj made sure we put this line.



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

True. May be its too obvious. Can get rid of that. Fine, either way.



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

Oops. Copy paste error. The explanation needs to go to the main section.
Thanks for pointing this.



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

That's a good point. The policy can come from PCRF. Sure.



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

Will add a reference to the later section, where its defined.





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

Ok.


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


You meant "mobility session" ? Its defined in the base spec. Let me add a
reference.



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

So, we used TS as a means to notify the capability and also as a means to
exchange the offload flow selectors. If the capable of supporting SIPTO, it
can include this option and the LMA can deliver the offload flow selectors.
Now, if the MAG is not capable (Ex: a residential gateway withno scope for
offload, or have internet peering points), then it will not include the TS
and the LMA will not deliver those selectors. But, there is also the other
question which you are pointing too. Should the LMA notify the offload flow
selectors dynamically, this is an open question.


>
> 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!
> :-)
>

I can switch :)

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

OK.

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

Ok.


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

Ok.

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

Sure. This is a good point. We missed few considerations on the override
part.



>    TS Format
> [Ahmad-21] Insert line.
>

Ok.


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

Sure


>    TS Selector
> [Ahmad-23] Insert line.
>

Sure

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

The selectors still apply for both the state values of the (M) flag. Its
more an inverse rule, if the identified traffic is offloaded, or if the
identified traffic is allowed to come in.



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

Thanks a lot Ahmad for the review. We will work on a revision. Let me know
if these comments address all the review comments.


Regards
Sri



> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext