Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 - M2M

[Alexandru Petrescu <[e-mail]>]

Le 02/03/2015 10:35, [e-mail] a écrit :
[...]
>> Note that the term "[3GPP] cellular host" includes a wide variety
>> of devices, including those which are considered "IoT" or "M2M"
>> (such as tracking/locating devices, health monitors, eReaders,
>> automobiles, etc.). Some of these devices are intended (by the
>> service provider who procures them) to be used with a service that
>>  does not support roaming to other providers'  networks. Some are
>> single function devices, where the function is fully specified at
>> time of procurement. These devices are generally intended to be as
>>  low-complexity and energy-efficient as possible.
>
> [Med] M2M-specific considerations are out of scope of this I-D. We
> had this sentence in the draft
> (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00):
>
>
>"M2M devices profile is out of scope."
>
> I lost the context why this sentence was removed from the draft.

Med, I dont know either.  But I think we may have a more important
problem here that we try to overlook somehow by putting M2M devices out
of scope.

The problem is that these M2M devices connect to the same cellular
network, and practically in almost the same way, as the smartphones do.
  The main differences are in the way of billing, and the data rates
afforded.

Another problem lies in an apparent difficulty we have in defining what
an M2M device is with respect to IP networking, although we do know they
are full IP (as opposed to other IoT devices which are hardly IP or not
IP at all).

I think it would be advantageous to include M2M devices in this device
profile draft.

If so, we can start by conceptualizing in the text the fact that 3GPP is
just an interface, not a computer per se.  This interface can be added
to computers like a smartphone, larger computers like a laptop, or
smaller computers like the Sierra Wireless Air Prime (one notable
M2M-class device in wide use with open source; there are others).

It would be necessary also to describe how on the market M2M devices are
only IPv4, and only smartphones are IPv6, today.

Alex


>
> If a
>> service provider is creating an RFP for such a device, that
>> service provider would be best advised to figure out their IPv6
>> architecture before sending out an RFP with any of the requirements
>> in this draft. For a service provider to say "I have no clue what
>> my IPv6 architecture is going to be, so I want to require even the
>> simplest and lowest complexity cellular hosts to have support for
>> all possible IPv6 archit ectures" is not an approach I would
>> recommend.
>
> [Med] That exercise is needed anyway (including identifying which
> parts from RFC6434 and RFC7066 are to be included in the list) . The
>  question is whether this I-D helps in simplifying that exercise or
> not. This draft positions itself as follows:
>
> This profile is a superset of that of the IPv6 profile for 3GPP
> Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node
> Requirements [RFC6434].
>
> The service provider you are referring to needs to figure out which
> parts from RFC6434, RFC7066, and this I-D are to be included in his
> list. This I-D completes RFC6434 and RFC7066 with IPv6-related
> features lists functions that are not captured in existing RFCs
> (e.g., PDP part, TFT support, VoLTE profile, etc.).
>
> This I-D is a "helper" for SPs to customize their list. This is
> explicitly called out in the I-D:
>
> 2.  Help Operators with the detailed device requirement list
> preparation (to be exchanged with device suppliers).  This is also a
>  contribution to harmonize Operators' requirements towards device
> vendors.
>
>>
>> But that is exactly what this draft recommends: C_REC#1:  In order
>>  to allow each operator to select their own strategy regarding IPv6
>>  introduction, the cellular host must support both IPv6 and IPv4v6
>>  PDP-Contexts [TS.23060].
>>
>
> [Med] What's the problem with this recommendation?
>
>> There are also other requirements which appear to impose complexity
>> on low-end non-roaming/single-purpose cellular hosts in order to
>> allow the service provider maximum flexibility in ultimately
>> deciding on an IPv6 architecture. I'm not enough of a cellular
>> expert to be able to properly identify all of these.
>
> [Med] As said above, this kind of devices is not the target of this
> I-D. We can make this more clearer.
>
>>
>> As for cellular hosts that do roam, I think the service provider
>> needs to put some thought into how important it is for such devices
>> to support all IPv6 architectures. I'm not fully convinced that it
>> won't be acceptable to users of low-end cellular hosts that do roam
>> to just do IPv4 on networks with unsupported IPv6 architectures.
>
> [Med] I don't understand this point.
>
>>
>> ---------
>>
>> CPE (Customer Premises Equipment): The draft does provide the
>> acronym expansion of CPE, but does not define the term. Given the
>> context in which the draft uses the term, I suspect that the
>> authors are not intending a definition consistent with that at, for
>> example, [1] and [2].
>
> [Med] The I-D includes this sentence:
>
> There are several deployments, particularly in emerging countries,
> that relies on mobile networks to provide broadband services (e.g.,
> customers are provided with mobile CPEs).
>
>
> The first of
>> these references includes the sentence "CPE generally refers to
>> devices such as telephones, routers, switches, residential gateways
>> (RG), set-top boxes, fixed mobile convergence products, home
>> networking adapters and Internet access gateways that enable
>> consumers to access communications service providers' services and
>>  distribute them around their house via a local area network
>> (LAN)." The second includes the sentence "Today, almost any
>> end-user equipment can be called customer premise [sic] equipment
>> and it can be owned by the customer or by the provider." But the
>> set of CPE that could also reasonably be expected to include a
>> 3GPP interface are, of course, much smaller than this broad def
>> inition. One such piece of CPE, though, is a home
>> automation/security gateway that interfaces with various
>> monitoring, automation, and security devices. Such CPE have both an
>> Ethernet WAN interface (that allows them to be behind the CE
>> router) and a 3GPP interface (for backup and perhaps some other
>> management purposes). Since these are "CPE" and "cellular" and they
>> provide LAN connectivity to various home automation devices, they
>> would appear to fall under the requirements of Section 3, and
>> specifically those that apply to "cellular CPE". I would not
>> recommend applying RFC 7084 to such CPE.
>
> [Med] Can you elaborate why L_REC#2 is not recommended for those?
>
> FWIW, the I-D includes this text:
>
> This recommendation does not apply to handsets with tethering
> capabilities; it is specific to cellular CPEs in order to ensure the
>  same IPv6 functional parity for both fixed and cellular CPEs.  Note,
>  modern CPEs are designed with advanced functions such as link
> aggregation that consists in optimizing the network usage by
> aggregating the connectivity resources offered via various interfaces
> (e.g., DSL, LTE, WLAN, etc.) or offloading the traffic via a subset
> of interfaces. Mutualizing IPv6 features among these interface types
> is important for the sake of specification efficiency, service design
> simplification and validation effort optimization.
>
> If "CE router" is intended, instead of all devices that can be
>> classified as "CPE", then I suggest using the term "CE router".
>>
>> [1] http://en.wikipedia.org/wiki/Customer-premises_equipment [2]
>> http://searchnetworking.techtarget.com/definition/customer-premises-
>>
>>
>>
>>
equipment
>>
>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>