From nobody Sun Jul 5 03:53:45 2015 Return-Path: X-Original-To: mpvdapi@ietfa.amsl.com Delivered-To: mpvdapi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F5F1A033A for ; Sun, 5 Jul 2015 03:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.989 X-Spam-Level: **** X-Spam-Status: No, score=4.989 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn1SHLAOgfN3 for ; Sun, 5 Jul 2015 03:53:40 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A571A0270 for ; Sun, 5 Jul 2015 03:53:40 -0700 (PDT) Received: by pddu5 with SMTP id u5so1539991pdd.3 for ; Sun, 05 Jul 2015 03:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=Uwpp5fde9WDsgm37qgtP12IwD6hsq7oe/4ALEHav/yQ=; b=YEAC/Lw5G+os9hQWX2Pqfi61W64G9CG/aJ5TC4LNFtZJ+vl+aPmFIUUXi806U+16tn aWuCgMxHTUgrJFneLqIL2n+0iYiUmSKzTzhgdU8cFYHG5xcqbz2GiIGl5bSplWXYpNXb 0KLYesz9fMxisC318nWOwSrUMcsq+ysYk8R6ab0PJE9aGT+km2ku9j+KJbLYu6X/UV7/ sJquyYReP+Z4H/ES6DCyP8x6yPZIYLO8OwjLYRSlUbTVggGi/aZT5vUl1Jz7YwOKIe5e DlC5VUkItraZM35HP9Nv9XppjRpT1NR1OjqYGIO27ZX5fNTjukiNfj9bUWmUGFiJIqBe yzhQ== X-Received: by 10.66.65.162 with SMTP id y2mr94452431pas.101.1436093620043; Sun, 05 Jul 2015 03:53:40 -0700 (PDT) Received: from [8.252.99.87] ([192.200.112.37]) by mx.google.com with ESMTPSA id c6sm14701077pas.39.2015.07.05.03.53.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 Jul 2015 03:53:38 -0700 (PDT) Date: Sun, 5 Jul 2015 18:53:32 +0800 From: Dapeng Liu To: Hui Deng Message-ID: <2DF18DBB97774B22A8D78C461ACED61B@gmail.com> In-Reply-To: References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <,> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="55990cac_66334873_1605" Archived-At: Cc: Erik Kline , Mikael Abrahamsson , Margaret , "=?utf-8?Q?mpvdapi=40ietf.org?=" , Ian Farrer Subject: [Mpvdapi] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= MIF API Design Team X-BeenThere: mpvdapi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 10:53:44 -0000 --55990cac_66334873_1605 Content-Type: multipart/alternative; boundary="55990cac_643c9869_1605" --55990cac_643c9869_1605 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Hui and Erik, =20 Attachment is the draft I mentioned during the discussion. It was written= before the Dallas meeting and it may not reflect the latest consensus we= have. =20 I am trying to update it. =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF= =BC=8C=E4=B8=8B=E5=8D=883:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A= > Hi Erik > =20 > I guess that everbody is busy with deadline, > could you kindly help to write down a draft about this proposal and the= n present it during coming MI=46 sesson, =20 > then we get more people to review on how Android implement this. > =20 > Thanks a lot for your kind work > Best regards, > =20 > DENG Hui > =20 > =20 > > =46rom: ek=40google.com (mailto:ek=40google.com) > > Date: Mon, 15 Jun 2015 19:55:15 +0900 > > Subject: Re: MI=46 API Design Team > > To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > CC: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com); mikael.abrahams= son=40t-systems.com (mailto:mikael.abrahamsson=40t-systems.com); mpvdapi=40= ietf.org (mailto:mpvdapi=40ietf.org) > > =20 > > Sorry about that: it's back to back 3GPP and now Android release issu= es. > > =20 > > I spent the weekend reworking some notes on the things I described in= > > Dallas. That's not coming together quickly enough so let me lay > > everything out here instead. In so doing I will try to describe more > > about the approach Android took to see if people even think it makes > > sense. > > =20 > > Let's assume for the sake of argument that C API definitions are > > nicely isolated, maybe in some =23include header file. > > =20 > > =5B1=5D Provisioning domains are represented by a =22handle=22 kind o= f class, > > android.net.Network: > > =20 > > https://developer.android.com/reference/android/net/Network.html > > =20 > > These are essentially handles to identify instances of attaches to > > provisioning domains. The underlying identifier values are not > > recycled (except after a really long time). Multiple temporally > > disparate attaches to the same network each get a new instance > > value--we have not yet found it of value to try to de-duplicate > > attaches. Applications that want to know if you're attached to > > =22Starbucks=22 so they can startup and auto-sign-in use the relevant= > > handle value to query parameters (like SSID). > > =20 > > I would propose that a C API would have something like > > =20 > > typedef uint64=5Ft pvd=5Fhandle=5Ft > > =23define PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0) > > =20 > > =5B2=5D Once an application has received a Network handle =5Blet's sa= ve how > > that happens for later=5D it can request that certain operations be > > performed specifically within the associated PVD. Currently these > > operations include: > > =20 > > =5Bbind a file descriptor to a PVD to force packets to be sent using > > the PVD's routing table=5D > > android.net.Network=23bindSocket() > > https://developer.android.com/reference/android/net/Network.html=23bi= ndSocket(java.net.Socket) > > =20 > > =5Bperform DNS lookups using a PVD's DNS servers=5D > > android.net.Network=23getAllByName() > > https://developer.android.com/reference/android/net/Network.html=23ge= tAllByName(java.lang.String) > > =20 > > =5Bset the PVD for all file descriptors and DNS lookups for a > > process, unless otherwise overridden=5D > > android.net.ConnectivityManager=23setProcessDefaultNetwork() > > https://developer.android.com/reference/android/net/ConnectivityManag= er.html=23setProcessDefaultNetwork(android.net.Network) > > =20 > > I would propose that a C API have at least the following: > > =20 > > =5Ba=5D get/setsockopt(int fd, SOL=5FSOCKET, SO=5FPVD=5FHANDLE, &pvd=5F= handle=5Ft); > > =5Bb=5D getaddrinfo/getnameinfo some taking a pvd=5Fhandle=5Ft > > =5Bc=5D discussion of recvmsg/sendmsg/accept semantics > > =20 > > Note that the last is particularly tricky. Operating systems need to > > know how to =22mark=22 incoming packets that would cause a new connec= tion > > such that they have the correct pvd=5Fhandle=5Ft associated. This has= > > lots of impact on suitable address selection as well. > > =20 > > The C API should also have at least the following: > > =20 > > =5Bd=5D system, process, and per-thread pvd=5Fhandle get/set calls > > =20 > > // These values are used by PVD-aware function calls when a PVD index= > > // is not explicitly specified. > > pvd=5Fhandle=5Ft pvd=5Fsystem=5Fdefault(); > > =20 > > // Same as above, but operates at a per-process level. If no > > // process-specific default has been set this MUST return the value > > // of a call to pvd=5Fsystem=5Fdefault(). > > pvd=5Fhandle=5Ft pvd=5Fprocess=5Fdefault(); > > =20 > > // Same as above, but operates at a per-thread level. If no > > // thread-specific default has been set this MUST return the value > > // of a call to pvd=5Fcurrent=5Fprocess=5Fdefault(). > > pvd=5Fhandle=5Ft pvd=5Fthread=5Fdefault(); > > =20 > > int pvd=5Fset=5Fsystem=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && err= no =3D E=46OO > > int pvd=5Fset=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && er= rno =3D E=46OO > > int pvd=5Fset=5Fthread=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && err= no =3D E=46OO > > =20 > > =5Be=5D good discussion of a variety of E=46OO errno return values. > > =20 > > When a PVD has gone away (e.g. we disconnected from WI=46I), subseque= nt > > operations on the associated pvd=5Fhandle should fail with errno =3D > > ENONET. > > =20 > > =5Bf=5D good discussion of how the process and thread default values > > behave across fork/exec > > =20 > > =46WIW, Android uses all of the above when NetworkMonitor is validati= ng > > a network--it does DNS lookups within the PVD, makes pvd-bound socket= s > > used for HTTP Direct or Proxy connections to check connectivity to a > > URL: > > =20 > > https://android.googlesource.com/platform/frameworks/base/+/master/se= rvices/core/java/com/android/server/connectivity/NetworkMonitor.java > > =20 > > =5B3=5D the device has to build up configuration data continuously ov= er > > time, as DHCP results come back, and RAs come in bringing new prefixe= s > > or new DNS servers. > > =20 > > Not that it's relevant, but Android accumulates these in an > > android.net.LinkProperties object: > > =20 > > https://developer.android.com/reference/android/net/LinkProperties.ht= ml > > =20 > > as we currently only support a 1:1 mapping of PVDs to physical interf= aces. > > =20 > > The means by which the operating system allocates pvd=5Fhandles, gath= ers > > this data and associates it with a pvd=5Fhandle (including marking > > incoming packets that would causes a new connection) might best be > > left for a separate document, since sections 1 and 2 and background > > theory will require a fair amount of text. > > =20 > > =5B4=5D Android lets processes register callbacks to be called when > > certain network properties change, or when a new network shows up, or= > > one goes away. This is how applications receive the handles (Network > > objects). > > =20 > > The UNIX way of doing these sorts of things...well, frequently leaves= > > much to be desired...but we should support multiple event-driven > > models, I think. > > =20 > > =5B5=5D we'll want an API for an application to pass in a handle and = get > > an ever expanding list of parameters (expanding as we think to add > > them and write documents about them). > > =20 > > The Android ConnectivityManager mitigates all this stuff and passes > > around NetworkInfo objects which encapsulate extra information like > > SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i, or whether i= t's > > metered, and so on. > > =20 > > The closest UNIX-style analogy here would be some interface that is > > getsockopt()-like, I think. Something like: > > =20 > > int pvd=5Fget=5Fattribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7CME= TERED=7C...), > > void *returned=5Fblob); > > =20 > > And then it will be possible for code to be written like > > =20 > > =23ifdef PVD=5FATTR=5FHTTP=5FPROXY=5FURL > > =20 > > char proxyString=5BPVD=5FATTR=5FHTTP=5FPROXY=5FURL=5FMAXLEN=5D; > > memset(proxyString, 0, sizeof(proxyString)); > > if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5FATTR=5FHTTP=5FPROXY=5F= URL, proxyString)) =7B > > perror(=22Sadness=21=22); > > return -1; > > =7D > > =20 > > =23endif > > =20 > > =20 > > --- > > =20 > > That's a massive brain dump, and I apologize for it and also that it'= s so late. > > =20 > > Let me know what y'all think. > > -Erik > > =20 > > On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng wrote: > > > Hi Erik > > > > > > We are waiting for your lead to start this work asap. =46eel free t= o us know > > > when you are ready. > > > > > > Hi Ian, thanks a lot for letting us know that you are going to work= with a > > > university on the implementations. > > > Erik was quite busy for 3GPP SA2 work recently, we are waiting for = his > > > return to lead the work. > > > > > > Best regards, > > > > > > DENG Hui > > > > > > > > >> =46rom: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com) > > >> Subject: MI=46 API Design Team > > >> Date: Mon, 8 Jun 2015 14:07:02 +0200 > > >> CC: mikael.abrahamsson=40t-systems.com (mailto:mikael.abrahamsson=40= t-systems.com) > > >> To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > >> > > >> Hi Hui, > > >> > > >> My apologies for not being in contact sooner. Things don=E2=80=99t= always move as > > >> quickly as hoped around here=21 > > >> > > >> The current status is that we have provisionally obtained the nece= ssary > > >> resources to start working on a proof of concept implementation of= the MI=46 > > >> architecture. We will be doing this in partnership with a Universi= ty. > > >> > > >> Tomorrow (9th July) we will start the scoping work with the implem= entor. > > >> What I want to come out of this work is a proof of concept impleme= ntation of > > >> the MI=46 architecture on a =E2=80=98generic=E2=80=99 Linux based = platform. As Eric is working > > >> on an Android implementation for the mobile use case, I think that= this > > >> should complement his work quite well and serve to provide some go= od > > >> implementation experience which can be fed back into the update of= the MI=46 > > >> API document. > > >> > > >> I=E2=80=99ve sent a subscription request to the MI=46 API design t= eam mailing list. > > >> Once we=E2=80=99ve got some firmer details agreed with the impleme= ntors, I=E2=80=99ll make > > >> an announcement on the m/l of what we=E2=80=99re doing and we can = discuss what the > > >> best way of aligning the two implementation efforts. > > >> > > >> Best regards, > > >> Ian > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Mpvdapi mailing list > Mpvdapi=40ietf.org (mailto:Mpvdapi=40ietf.org) > https://www.ietf.org/mailman/listinfo/mpvdapi > =20 > =20 > =20 --55990cac_643c9869_1605 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Hui and Erik,

Attachment is the draft I menti= oned during the discussion. It was written before the Dallas meeting and = it may not reflect the latest consensus we have. 

I am trying to update it.



--=  
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 7=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 3:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A

Hi Erik
 
I guess that everbody is busy w= ith deadline,
could you kindly help to write down a draft about this p= roposal and then present it during coming MI=46 sesson,
then we = get more people to review on how Android implement this.
 
Tha= nks a lot for your kind work
Best regards,
 
DENG Hui<= br>
 
> =46rom: ek=40google.com
> Date: Mon, 15 Jun 2015 19:55:15 +0900
>= ; Subject: Re: MI=46 API Design Team
> To: denghui02=40hotmail.com
> CC: ianfarrer=40gmx.com; mikael.abrahamsson=40t-systems= .com; mpvdapi=40ietf.org
>
> Sorry about that: it's back to back 3GPP and now Andro= id release issues.
>
> I spent the weekend reworking some no= tes on the things I described in
> Dallas. That's not coming toget= her quickly enough so let me lay
> everything out here instead. In= so doing I will try to describe more
> about the approach Android = took to see if people even think it makes
> sense.
>
>= Let's assume for the sake of argument that C API definitions are
>= nicely isolated, maybe in some =23include <netpvd.h> header file.<= br>>
> =5B1=5D Provisioning domains are represented by a =22han= dle=22 kind of class,
> android.net.Network:
>
> <= a href=3D=22https://developer.android.com/reference/android/net/Network.h= tml=22>https://developer.android.com/reference/android/net/Network.html
>
> These are essentially handles to identify instances o= f attaches to
> provisioning domains. The underlying identifier va= lues are not
> recycled (except after a really long time). Multipl= e temporally
> disparate attaches to the same network each get a ne= w instance
> value--we have not yet found it of value to try to de-= duplicate
> attaches. Applications that want to know if you're att= ached to
> =22Starbucks=22 so they can startup and auto-sign-in use= the relevant
> handle value to query parameters (like SSID).
&g= t;
> I would propose that a C API would have something like
>= ;
> typedef uint64=5Ft pvd=5Fhandle=5Ft
> =23define = PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0)
>
> =5B2=5D Once= an application has received a Network handle =5Blet's save how
> t= hat happens for later=5D it can request that certain operations be
>= ; performed specifically within the associated PVD. Currently these
&= gt; operations include:
>
> =5Bbind a file descriptor to= a PVD to force packets to be sent using
> the PVD's routing table=5D=
> android.net.Network=23bindSocket()
> https://developer.android.com/reference/android/n= et/Network.html=23bindSocket(java.net.Socket)
>
> =5B= perform DNS lookups using a PVD's DNS servers=5D
> android.net.= Network=23getAllByName()
> https://developer.android.com/reference/android/net/Network.html=23ge= tAllByName(java.lang.String)
>
> =5Bset the PVD for = all file descriptors and DNS lookups for a
> process, unless otherw= ise overridden=5D
> android.net.ConnectivityManager=23setProces= sDefaultNetwork()
> https://developer.android.com/reference/android/n= et/ConnectivityManager.html=23setProcessDefaultNetwork(android.net.Networ= k)
>
> I would propose that a C API have at least the fo= llowing:
>
> =5Ba=5D get/setsockopt(int fd, SOL=5FSOCKET= , SO=5FPVD=5FHANDLE, &pvd=5Fhandle=5Ft);
> =5Bb=5D getaddri= nfo/getnameinfo some taking a pvd=5Fhandle=5Ft
> =5Bc=5D discus= sion of recvmsg/sendmsg/accept semantics
>
> Note that the l= ast is particularly tricky. Operating systems need to
> know how t= o =22mark=22 incoming packets that would cause a new connection
> s= uch that they have the correct pvd=5Fhandle=5Ft associated. This has
= > lots of impact on suitable address selection as well.
>
&g= t; The C API should also have at least the following:
>
> = =5Bd=5D system, process, and per-thread pvd=5Fhandle get/set calls
&= gt;
> // These values are used by PVD-aware function calls whe= n a PVD index
> // is not explicitly specified.
> pvd= =5Fhandle=5Ft pvd=5Fsystem=5Fdefault();
>
> // Same as a= bove, but operates at a per-process level. If no
> // process-= specific default has been set this MUST return the value
> // o= f a call to pvd=5Fsystem=5Fdefault().
> pvd=5Fhandle=5Ft pvd=5F= process=5Fdefault();
>
> // Same as above, but operates = at a per-thread level. If no
> // thread-specific default has = been set this MUST return the value
> // of a call to pvd=5Fcur= rent=5Fprocess=5Fdefault().
> pvd=5Fhandle=5Ft pvd=5Fthread=5Fd= efault();
>
> int pvd=5Fset=5Fsystem=5Fdefault(pvd=5Fhan= dle=5Ft); // 0 or -1 && errno =3D E=46OO
> int pvd=5Fs= et=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && errno =3D= E=46OO
> int pvd=5Fset=5Fthread=5Fdefault(pvd=5Fhandle=5Ft); = // 0 or -1 && errno =3D E=46OO
>
> =5Be=5D good = discussion of a variety of E=46OO errno return values.
>
> W= hen a PVD has gone away (e.g. we disconnected from WI=46I), subsequent> operations on the associated pvd=5Fhandle should fail with errno =3D=
> ENONET.
>
> =5Bf=5D good discussion of how the = process and thread default values
> behave across fork/exec
>=
> =46WIW, Android uses all of the above when NetworkMonitor is va= lidating
> a network--it does DNS lookups within the PVD, makes pvd= -bound sockets
> used for HTTP Direct or Proxy connections to check= connectivity to a
> URL:
>
> https://andr= oid.googlesource.com/platform/frameworks/base/+/master/services/core/java= /com/android/server/connectivity/NetworkMonitor.java
>
>= =5B3=5D the device has to build up configuration data continuously over<= br>> time, as DHCP results come back, and RAs come in bringing new pre= fixes
> or new DNS servers.
>
> Not that it's relevant= , but Android accumulates these in an
> android.net.LinkProperties = object:
>
> https://developer.android.com= /reference/android/net/LinkProperties.html
>
> as we cur= rently only support a 1:1 mapping of PVDs to physical interfaces.
>=
> The means by which the operating system allocates pvd=5Fhandles= , gathers
> this data and associates it with a pvd=5Fhandle (includ= ing marking
> incoming packets that would causes a new connection) = might best be
> left for a separate document, since sections 1 and = 2 and background
> theory will require a fair amount of text.
&g= t;
> =5B4=5D Android lets processes register callbacks to be calle= d when
> certain network properties change, or when a new network s= hows up, or
> one goes away. This is how applications receive the = handles (Network
> objects).
>
> The UNIX way of doing= these sorts of things...well, frequently leaves
> much to be desir= ed...but we should support multiple event-driven
> models, I think.=
>
> =5B5=5D we'll want an API for an application to pass in= a handle and get
> an ever expanding list of parameters (expanding= as we think to add
> them and write documents about them).
>=
> The Android ConnectivityManager mitigates all this stuff and pa= sses
> around NetworkInfo objects which encapsulate extra informati= on like
> SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i, = or whether it's
> metered, and so on.
>
> The closest = UNIX-style analogy here would be some interface that is
> getsockop= t()-like, I think. Something like:
>
> int pvd=5Fget=5F= attribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7CMETERED=7C...),
>= ; void *returned=5Fblob);
>
> And then it will be possible f= or code to be written like
>
> =23ifdef PVD=5FATTR=5FHTT= P=5FPROXY=5FURL
>
> char proxyString=5BPVD=5FATTR=5FHTTP= =5FPROXY=5FURL=5FMAXLEN=5D;
> memset(proxyString, 0, sizeof(pro= xyString));
> if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5F= ATTR=5FHTTP=5FPROXY=5FURL, proxyString)) =7B
> perror(=22Sa= dness=21=22);
> return -1;
> =7D
>
>= =23endif
>
>
> ---
>
> That's a mas= sive brain dump, and I apologize for it and also that it's so late.
&g= t;
> Let me know what y'all think.
> -Erik
>
> = On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng <denghui02=40hotmail.com> wrote:
> > H= i Erik
> >
> > We are waiting for your lead to start th= is work asap. =46eel free to us know
> > when you are ready.
= > >
> > Hi Ian, thanks a lot for letting us know that yo= u are going to work with a
> > university on the implementations= .
> > Erik was quite busy for 3GPP SA2 work recently, we are wai= ting for his
> > return to lead the work.
> >
> &= gt; Best regards,
> >
> > DENG Hui
> >
>= >
> >> =46rom: ianfarrer=40gmx.com
> >> Subject: MI=46 API Design Team<= br>> >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> >> CC= : mikael.abraha= msson=40t-systems.com
> >> To: denghui02=40hotmail.com
> >>
>= >> Hi Hui,
> >>
> >> My apologies for not = being in contact sooner. Things don=E2=80=99t always move as
> >= > quickly as hoped around here=21
> >>
> >> Th= e current status is that we have provisionally obtained the necessary
= > >> resources to start working on a proof of concept implementa= tion of the MI=46
> >> architecture. We will be doing this in= partnership with a University.
> >>
> >> Tomorro= w (9th July) we will start the scoping work with the implementor.
>= >> What I want to come out of this work is a proof of concept impl= ementation of
> >> the MI=46 architecture on a =E2=80=98gener= ic=E2=80=99 Linux based platform. As Eric is working
> >> on = an Android implementation for the mobile use case, I think that this
&= gt; >> should complement his work quite well and serve to provide s= ome good
> >> implementation experience which can be fed back= into the update of the MI=46
> >> API document.
> >= >
> >> I=E2=80=99ve sent a subscription request to the MI=46= API design team mailing list.
> >> Once we=E2=80=99ve got so= me firmer details agreed with the implementors, I=E2=80=99ll make
>= >> an announcement on the m/l of what we=E2=80=99re doing and we c= an discuss what the
> >> best way of aligning the two impleme= ntation efforts.
> >>
> >> Best regards,
> = >> Ian
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Mpvdapi mailing list
 =20 =20 =20 =20

--55990cac_643c9869_1605-- --55990cac_66334873_1605 Content-Type: application/OCTET-STREAM Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-liu-mif-socket-api-00.txt" TUlGICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRC4gTGl1CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAg ICAgICAgICAgICAgICAgICAgRmVicnVhcnkgOSwgMjAxNQpFeHBpcmVzOiBBdWd1c3QgMTMsIDIw MTUKCgogICAgICAgICAgICAgU29ja2V0IEFQSSBFeHRlbnNpb24gZm9yIE1JRiBQdkQgQXJjaGl0 ZWN0dXJlCiAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1saXUtbWlmLXNvY2tldC1hcGktMDAK CkFic3RyYWN0CgogICBJRVRGIE1JRiB3b3JraW5nIGdyb3VwIGRlZmluZXMgdGhlIG11bHRpcGxl IHByb3Zpc2lvbmluZyBkb21haW4KICAgYXJjaGl0ZWN0dXJlLiAgVGhpcyBkb2N1bWVudCBkaXNj dWNzc2VzIEFQSSBleHRlbnNpb24gZm9yIHRoZSBQdkQtCiAgIGF3YXJlIG5vZGUgdG8gc3VwcG9y dCB0aGUgTUlGIFB2RCBhcmNoaXRlY3R1cmUuCgpSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIs IGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uCgpTdGF0dXMgb2YgVGhpcyBNZW1v CgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNl IHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IEF1Z3VzdCAxMywgMjAxNS4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAx NSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBS ZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGlj ZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwg YXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dAoKCgpMaXUgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTMsIDIwMTUgICAg ICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2 aWF0ZWQtVGl0bGUgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTUKCgogICB0byB0aGlzIGRvY3Vt ZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAog ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRl ZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEN1cnJl bnQgUHZELXJlbGF0ZWQgQVBJIGltcGxlbWVudGF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAyCiAgICAgMi4xLiAgUHZELXJlbGF0ZWQgQVBJIEltcGxlbWVudGF0aW9uIGluIFNvY2tldCBB UEkgIC4gLiAuIC4gLiAuICAgMgogICAzLiAgRXh0ZW5zaW9uIGZvciBQdkQgYWR2YW5jZWQgQVBJ ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAzLjEuICBHZXQgUHZEIENv bmZpZ3VyYXRpb24gQVBJIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAg My4yLiAgU2VsZWN0IFB2RCBBUEkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNQogICA0LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDYuICBBY2tub3ds ZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NQogICA3LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDUKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CgoxLiAgSW50cm9kdWN0aW9uCgogICBJ RVRGIE1JRiB3b3JraW5nIGdyb3VwIGRlZmluZXMgdGhlIG11bHRpcGxlIHByb3Zpc2lvbmluZyBk b21haW4KICAgYXJjaGl0ZWN0dXJlIGluIGRyYWZ0LWlldGYtbWlmLW1wdmQtYXJjaC0xMCBbbXB2 ZC1hcmNoaXRlY3R1cmVdIC4gSXQKICAgZGVmaW5lcyB0aHJlZSBsZXZlbHMgb2YgUHZEIHN1cHBv cnQgaW4gQVBJOiBiYXNpYywgaW50ZXJtZWRpYXRlIGFuZAogICBhZHZhbmNlZC4gIFRoaXMgZG9j dW1lbnQgZGlzY3Vzc2VzIHRoZSBhZHZhbmNlZCBQdkQgQVBJIGZvciB0aGUgUHZELQogICBhd2Fy ZSBub2RlLgoKMi4gIEN1cnJlbnQgUHZELXJlbGF0ZWQgQVBJIGltcGxlbWVudGF0aW9uCgogICBU aGlzIHNlY3Rpb24gc3VtbWFyaXplIHRoZSBQdkQgcmVsYXRlZCBBUEkgaW1wbGVtZW50YXRpb25z LiAgVGhlCiAgIHB1cnBvc2Ugb2YgdGhpcyBzZWN0aW9uIGlzIHRvIGhlbHAgYW5hbHl6aW5nIHRo ZSBleHRlbnNpb24gb2YgY3VycmVudAogICBBUEkgaW1wbGVtZW50YXRpb24gdG8gc3VwcG9ydCBQ dkQgYXJjaGl0ZWN0dXJlLgoKMi4xLiAgUHZELXJlbGF0ZWQgQVBJIEltcGxlbWVudGF0aW9uIGlu IFNvY2tldCBBUEkKCiAgIEluIExpbnV4LCB0aGVyZSBpcyBhIHNldCBvZiBzb2NrZXQgQVBJIHRo YXQgaGFzIGJlZW4gd2lkZWx5IHVzZWQuCiAgIFRoZSBiYXNpYyBzb2NrZXQgQVBJIGluIExpbnV4 IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmc6CgogICBTb2NrZXQgQVBJIGZvciBhIHR5cGljYWwgc2Vy dmVyOgoKICAgbyAgc29ja2V0KCkKCiAgIG8gIGJpbmQoKQoKICAgbyAgbGlzdGVuKCkKCiAgIG8g IHJlY3Ztc2coKQoKCgoKTGl1ICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEz LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIEFiYnJldmlhdGVkLVRpdGxlICAgICAgICAgICAgICBGZWJydWFyeSAyMDE1CgoKICAgbyAg c2VuZG1zZygpCgogICBvICBjbG9zZSgpCgogICBTb2NrZXQgQVBJIGZvciBhIHR5cGljYWwgY2xp ZW50OgoKICAgbyAgc29ja2V0KCkKCiAgIG8gIHNlbmRtc2coKQoKICAgbyAgcmVjdm1zZygpCgog ICBvICBjbG9zZSgpCgogICBbUkZDMzQ5M10gZXh0ZW5kcyB0aGUgYmFzaWMgTGludXggc29ja2V0 IEFQSSB0byBzdXBwb3J0IElQdjYuICBJdAogICBkZWZpbmVzIHRoZSBJUHY2IEFkZHJlc3MgRmFt aWx5IGFuZCBQcm90b2NvbCBGYW1pbHkgYW5kIGFsc28gdGhlCiAgIHNvY2tldCBhZGRyZXNzIHN0 cnVjdHVyZSwgc29ja2V0IG9wdGlvbnMgZXRjLgoKICAgW1JGQzM1NDJdIGRlZmluZXMgdGhlIGFk dmFuY2VkIHNvY2tldHMgQVBJIGZvciBJUHY2LiAgSXQgZGVmaW5lcyB0aGUKICAgc29ja2V0IEFQ SSB0byBhY2Nlc3MgSVB2NiBzcGVjaWZpYyBwYXJhbWV0ZXJzLiAgRm9yIGV4YW1wbGUsIHRoZSBJ UHY2CiAgIHJhdyBzb2NrZXQsIHRoZSBBUEkgdG8gYWNjZXNzIElQdjYgYW5kIGV4dGVuc2lvbiBo ZWFkZXJzIGV0Yy4KCiAgIFtSRkM1MDE0XSBkZWZpbmVzIHRoZSBJUHY2IHNvY2tldCBBUEkgZXh0 ZW5zaW9uIGZvciBzb3VyY2UgYWRkcmVzcwogICBzZWxlY3Rpb24uICBJdCBjYW4gYmUgdXNlZCB0 byBvdmVycmlkZSB0aGUgZGVmYXVsdCBzb3VyY2UgYWRkcmVzcwogICBzZWxlY3Rpb24gbWV0aG9k IGFzIGRlZmluZWQgaW4gW1JGQzM0ODRdIC4gSXQgZGVmaW5lcyBhbiBhZGRyZXNzCiAgIHByZWZl cmVuY2UgZmxhZ3MgdGhhdCB1c2VkIGZvciB0aGUgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uLgog ICBEZXZlbG9wZXJzIGNhbiB1c2UgdGhpcyBBUEkgdG8gZXhwbGljaXRseSBzcGVjaWZ5IHRoZSBz b3VyY2UgYWRkcmVzcwogICB0byBiZSB1c2VkIGluIHRoZSBjb21tdW5pY2F0aW9uLiAgRXhhbXBs ZSBvZiB1c2UgY2FzZXMgb2YgdGhpcyBzb3VyY2UKICAgYWRkcmVzcyBzZWxlY3Rpb24gQVBJIGlu Y2x1ZGVzIGFwcGxpY2F0aW9ucyB0aGF0IHN1cHBvcnRpbmcgTW9iaWxlCiAgIElQdjYsIElQdjYg UHJpdmFjeSBFeHRlbnNpb25zLCBDcnlwdG9ncmFwaGljYWxseSBHZW5lcmF0ZWQgQWRkcmVzc2Vz CiAgIGV0Yy4gIEl0IHVzZXMgcGVyLXNvY2tldCBhbmQgcGVyLXBhY2tldCBmbGFncyB0byBpbXBs ZW1lbnQgdGhlIHNvdXJjZQogICBhZGRyZXNzIHNlbGVjdGlvbi4gIEl0IGFkZHMgYSBuZXcgc29j a2V0IG9wdGlvbiBhdCB0aGUgSVBQUk9UT19JUFY2CiAgIGxldmVsLiAgVGhlIG5ldyBvcHRpb24g aXMgY2FsbGVkIElQVjZfQUREUl9QUkVGRVJFTkNFUy4gIEl0IGNhbiBiZQogICB1c2VkIHdpdGgg c2V0c29ja29wdCgpIGFuZCBnZXRzb2Nrb3B0KCkgY2FsbHMgdG8gc2V0IGFuZCBnZXQgdGhlCiAg IGFkZHJlc3Mgc2VsZWN0aW9uIHByZWZlcmVuY2VzIGFmZmVjdGluZyBhbGwgcGFja2V0cyBzZW50 IHZpYSBhIGdpdmVuCiAgIHNvY2tldC4KCjMuICBFeHRlbnNpb24gZm9yIFB2RCBhZHZhbmNlZCBB UEkKCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBleHRlbnNpb24gb2Ygc29ja2V0IEFQSSB0 byBzdXBwb3J0IFB2RAogICBhcmNoaXRlY3R1cmUgYXMgZGVmaW5lZCBpbiBbbXB2ZC1hcmNoaXRl Y3R1cmVdCgogICBJdCBiZWxvbmdzIHRvIHRoZSBhZHZhbmNlZCBQdkQgQVBJIGRpc2N1c3NlZCBp biBzZWN0aW9uIDYuMyBvZgogICBbbXB2ZC1hcmNoaXRlY3R1cmVdLiAgVGhlIGV4dGVuc2lvbiBw cm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGhhcyB0d28KICAgdHlwZXMgb2YgQVBJIGV4dGVuc2lv bjoKCiAgIG8gIEFQSSB0byBnZXQgY3VycmVudCBQdkRzIHRoYXQgYmVlbiBwcm92aWRlZCB0byB0 aGUgbm9kZQoKCgoKTGl1ICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEzLCAy MDE1ICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IEFiYnJldmlhdGVkLVRpdGxlICAgICAgICAgICAgICBGZWJydWFyeSAyMDE1CgoKICAgbyAgQVBJ IHRvIGV4cGxpY2l0bHkgc2VsZWN0IGEgUHZECgogICBUaGVyZSBhcmUgZGlmZmVyZW50IGRlc2ln biBhbHRlcm5hdGl2ZXMgZm9yIHRoZSBQdkQgQVBJLiAgSW5jbHVkaW5nOgoKICAgbyAgR2V0IFB2 RHMgYW5kIHNlbGVjdCBQdkQgcGVyLXNvY2tldC4KCiAgIG8gIEdldCBQdkRzIGFuZCBzZWxlY3Qg UHZEIHBlci1hcHBsaWNhdGlvbi4KCiAgIG8gIEdldCBQdkRzIGFuZCBzZWxlY3QgUHZEIHBlci1u b2RlLgoKICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlIHRoZSBwZXItc29ja2V0IGFwcHJvYWNoIHNp bmNlIGl0IGNhbiBwcm92aWRlCiAgIHRoZSBtYXhpbWFsIGZsZXhpYmlsaXR5IGZvciB0aGUgYXBw bGljYXRpb24gZGV2ZWxvcGVycyB0byBtZWV0IGFsbAogICB0aGUga2luZHMgb2YgdXNlIGNhc2Vz LgoKMy4xLiAgR2V0IFB2RCBDb25maWd1cmF0aW9uIEFQSQoKICAgVGhlIGZvbGxvd2luZyBBUEkg aXMgdXNlZCB0byBnZXQgdGhlIGN1cnJlbnQgUHZEIGNvbmZpZ3VyYXRpb24gb2YgdGhlCiAgIG5v ZGU6CgogICBvICBnZXRwdmRpbmZvKCkKCiAgIFRoZSBkZWZpbml0aW9uIG9mIHRoaXMgQVBJIGlz OgoKICAgaW50IGdldHB2ZGluZm8oY29uc3QgY2hhciAqbm9kZW5hbWUsIGNvbnN0IGNoYXIgKnNl cnZuYW1lLCBzdHJ1Y3QKICAgcHZkaW5mbyAqKnJlcyk7CgogICBUaGUgc3RydWN0dXJlIG9mIHN0 cnVjdCBwdmRpbmZvIGlzOgoKICAgc3RydWN0IHB2ZGluZm8gewoKICAgaW50IHNvY2thZGRyICph aV9hZGRyOwoKICAgaW50IHNvY2thZGRyICpnYXRld2F5X2FkZHI7CgogICBpbnQgc29ja2FkZHIg KiBkbnNfYWRkcjsKCiAgIHN0cnVjdCBhZGRyaW5mbyAqYWlfbmV4dDsKCiAgIH0KCiAgIFRoZSBk ZWZpbml0aW9uIG9mIHBhcmFtZXRlcnMgaXMgYXMgZm9sbG93czoKCiAgIG8gIG5vZGVuYW1lIGFu ZCBzZXJ2bmFtZTogVGhlIG5vZGVuYW1lIGFuZCBzZXJ2bmFtZSBhcmd1bWVudHMgYXJlCiAgICAg IHBvaW50ZXJzIHRvIG51bGwtdGVybWluYXRlZCBzdHJpbmdzIG9yIE5VTEwuICBPbmUgb3IgYm90 aCBvZiB0aGVzZQogICAgICBhcmd1bWVudHMgbXVzdCBiZSBhIG5vbi1udWxsIHBpbnRlci4gIEEg bm9uLW51bGwgbm9kZW5hbWUgc3RyaW5nCiAgICAgIGNhbiBiZSBhIG5vZGUgbmFtZSBvciBhIG51 bWVyaWMgaG9zdCBhZGRyZXNzIHN0cmluZy4KCgoKCgpMaXUgICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMTMsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQtVGl0bGUgICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTUKCgogICBvICByZXM6IFRoZSBwdmRpbmZvIHN0cnVjdHVyZS4gIFRoZSByZXN1bHQg aXMgcG9pbnRlZCB0byByZXMKICAgICAgc3RydWN0dXJlLgoKMy4yLiAgU2VsZWN0IFB2RCBBUEkK CiAgIFRoZSBmb2xsb3dpbmcgQVBJIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzcGVjaWZpYyBQdkQu CgogICBvICBzZXRzb2Nrb3B0KCkKCiAgIHNldHNvY2tvcHQoaW50IHMsIHN0cnVjdCAqIHB2ZGlu Zm8pCgogICBUaGUgcHZkaW5mbyBpcyBhIG5ldyBhcmd1bWVudCB0aGF0IHVzZWQgdG8gc3BlY2lm eSB0aGUgcHJlZmVycmVkIFB2RC4KICAgVGhlIHNvY2tldCBzIGNhbiBiZSBzZXQgdG8gc2VsZWN0 IHRoZSBQdkQgdGhhdCBzcGVjaWZpZWQgYnkgcHZkaW5mbwogICBhcmd1bWVudC4KCiAgIFRoZSBj b25uZWN0aW9uIHNob3VsZCB1c2UgdGhlIHNldCBvZiBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMg dGhhdAogICBjb250YWluZWQgaW4gdGhlIHB2ZGluZm8uICBGb3IgZXhhbXBsZSwgdGhlIHNvdXJj ZSBhZGRyZXNzLCBnYXRld2F5CiAgIGFuZCBETlMuCgo0LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoK ICAgVGhpcyBkb2N1bWVudCBtYWtlcyBubyByZXF1ZXN0IG9mIElBTkEuCgo1LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMKCiAgIFRCRC4KCjYuICBBY2tub3dsZWRnZW1lbnRzCgogICBUQkQuCgo3 LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1l bnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMzNDg0XSAg RHJhdmVzLCBSLiwgIkRlZmF1bHQgQWRkcmVzcyBTZWxlY3Rpb24gZm9yIEludGVybmV0CiAgICAg ICAgICAgICAgUHJvdG9jb2wgdmVyc2lvbiA2IChJUHY2KSIsIEZlYnJ1YXJ5IDIwMDMuCgogICBb UkZDMzQ5M10gIEdpbGxpZ2FuLCBSLiwgIkJhc2ljIFNvY2tldCBJbnRlcmZhY2UgRXh0ZW5zaW9u cyBmb3IKICAgICAgICAgICAgICBJUHY2IiwgRmVicnVhcnkgMjAwMy4KCiAgIFtSRkMzNTQyXSAg U3RldmVucywgVy4sICJBZHZhbmNlZCBTb2NrZXRzIEFwcGxpY2F0aW9uIFByb2dyYW0KICAgICAg ICAgICAgICBJbnRlcmZhY2UgKEFQSSkgZm9yIElQdjYiLCBNYXkgMjAwMy4KCiAgIFtSRkM1MDE0 XSAgTm9yZG1hcmssIEUuLCAiSVB2NiBTb2NrZXQgQVBJIGZvciBTb3VyY2UgQWRkcmVzcwogICAg ICAgICAgICAgIFNlbGVjdGlvbiIsIFNlcHRlbWJlciAyMDA3LgoKCgoKTGl1ICAgICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEzLCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDVd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEFiYnJldmlhdGVkLVRpdGxlICAgICAgICAg ICAgICBGZWJydWFyeSAyMDE1CgoKICAgW21wdmQtYXJjaGl0ZWN0dXJlXQogICAgICAgICAgICAg IEFuaXBrbywgRC4sICJNdWx0aXBsZSBQcm92aXNpb25pbmcgRG9tYWluIEFyY2hpdGVjdHVyZSIs CiAgICAgICAgICAgICAgRmVicnVhcnkgMjAxNS4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIERhcGVu ZyBMaXUKCiAgIEVtYWlsOiBtYXhwYXNzaW9uQGdtYWlsLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxpdSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAxMywgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSA2XQo= --55990cac_66334873_1605-- From nobody Sun Jul 5 23:25:25 2015 Return-Path: X-Original-To: mpvdapi@ietfa.amsl.com Delivered-To: mpvdapi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7C51A89C6 for ; Sun, 5 Jul 2015 23:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.689 X-Spam-Level: *** X-Spam-Status: No, score=3.689 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cj7ASdUP_Al for ; Sun, 5 Jul 2015 23:25:19 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039C51A89A9 for ; Sun, 5 Jul 2015 23:25:19 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so90225388pab.1 for ; Sun, 05 Jul 2015 23:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=s23EFHcL/s/P/IUZLyW7yedO2dD+QKqPVIF7+Dsa2MQ=; b=oXDTDER6ojgmNrWTWSjGJmGdS5MZb2QbKAUWEWQ1FRdqU0N/hHNRRvWKlSAOqhzlx7 U7NFt4XvCSY9/FaqNe3GoxCsYJeJYz94zk39YPdLhMw9VazARHlOZV1mQF9gH6X70Hxr 7hJLnjEolQi1oSW78BI/Ji570UFKCA92M1DZB48yQ6erusNdvVDfWxXRoyxcVb71Lhkj Qlpd1lVfF2o7TPkxHydho+UndQvo/lsshsS4OmPALWDGgSggbyWMqmg6cuEutB3ysvOy l5sT5dQvPVu7S7lHMfIvKC2eXMhW/zzrlCp0iF4escwxgo5Sy4Vini93CS0Ou7yKZk5Z 33OQ== X-Received: by 10.70.88.43 with SMTP id bd11mr100540912pdb.7.1436163918587; Sun, 05 Jul 2015 23:25:18 -0700 (PDT) Received: from [10.1.50.207] ([202.55.20.10]) by mx.google.com with ESMTPSA id ho10sm16847666pbc.27.2015.07.05.23.25.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 Jul 2015 23:25:17 -0700 (PDT) Date: Mon, 6 Jul 2015 14:25:12 +0800 From: Dapeng Liu To: Hui Deng Message-ID: In-Reply-To: <2DF18DBB97774B22A8D78C461ACED61B@gmail.com> References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <,> <2DF18DBB97774B22A8D78C461ACED61B@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="559a1f48_74b0dc51_1656" Archived-At: Cc: Erik Kline , Mikael Abrahamsson , Margaret , "=?utf-8?Q?mpvdapi=40ietf.org?=" , Ian Farrer Subject: [Mpvdapi] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= MIF API Design Team X-BeenThere: mpvdapi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 06:25:23 -0000 --559a1f48_74b0dc51_1656 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-api= -00 =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF= =BC=8C=E4=B8=8B=E5=8D=886:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC=9A= > Hi Hui and Erik, =20 > =20 > Attachment is the draft I mentioned during the discussion. It was writt= en before the Dallas meeting and it may not reflect the latest consensus = we have. =20 > =20 > I am trying to update it. =20 > =20 > =20 > =20 > -- =20 > Dapeng Liu > =20 > =20 > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=883:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC= =9A > =20 > > Hi Erik > > =20 > > I guess that everbody is busy with deadline, > > could you kindly help to write down a draft about this proposal and t= hen present it during coming MI=46 sesson, =20 > > then we get more people to review on how Android implement this. > > =20 > > Thanks a lot for your kind work > > Best regards, > > =20 > > DENG Hui > > =20 > > =20 > > > =46rom: ek=40google.com (mailto:ek=40google.com) > > > Date: Mon, 15 Jun 2015 19:55:15 +0900 > > > Subject: Re: MI=46 API Design Team > > > To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > > CC: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com); mikael.abraha= msson=40t-systems.com (mailto:mikael.abrahamsson=40t-systems.com); mpvdap= i=40ietf.org (mailto:mpvdapi=40ietf.org) > > > =20 > > > Sorry about that: it's back to back 3GPP and now Android release is= sues. > > > =20 > > > I spent the weekend reworking some notes on the things I described = in > > > Dallas. That's not coming together quickly enough so let me lay > > > everything out here instead. In so doing I will try to describe mor= e > > > about the approach Android took to see if people even think it make= s > > > sense. > > > =20 > > > Let's assume for the sake of argument that C API definitions are > > > nicely isolated, maybe in some =23include header file. > > > =20 > > > =5B1=5D Provisioning domains are represented by a =22handle=22 kind= of class, > > > android.net.Network: > > > =20 > > > https://developer.android.com/reference/android/net/Network.html > > > =20 > > > These are essentially handles to identify instances of attaches to > > > provisioning domains. The underlying identifier values are not > > > recycled (except after a really long time). Multiple temporally > > > disparate attaches to the same network each get a new instance > > > value--we have not yet found it of value to try to de-duplicate > > > attaches. Applications that want to know if you're attached to > > > =22Starbucks=22 so they can startup and auto-sign-in use the releva= nt > > > handle value to query parameters (like SSID). > > > =20 > > > I would propose that a C API would have something like > > > =20 > > > typedef uint64=5Ft pvd=5Fhandle=5Ft > > > =23define PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0) > > > =20 > > > =5B2=5D Once an application has received a Network handle =5Blet's = save how > > > that happens for later=5D it can request that certain operations be= > > > performed specifically within the associated PVD. Currently these > > > operations include: > > > =20 > > > =5Bbind a file descriptor to a PVD to force packets to be sent usin= g > > > the PVD's routing table=5D > > > android.net.Network=23bindSocket() > > > https://developer.android.com/reference/android/net/Network.html=23= bindSocket(java.net.Socket) > > > =20 > > > =5Bperform DNS lookups using a PVD's DNS servers=5D > > > android.net.Network=23getAllByName() > > > https://developer.android.com/reference/android/net/Network.html=23= getAllByName(java.lang.String) > > > =20 > > > =5Bset the PVD for all file descriptors and DNS lookups for a > > > process, unless otherwise overridden=5D > > > android.net.ConnectivityManager=23setProcessDefaultNetwork() > > > https://developer.android.com/reference/android/net/ConnectivityMan= ager.html=23setProcessDefaultNetwork(android.net.Network) > > > =20 > > > I would propose that a C API have at least the following: > > > =20 > > > =5Ba=5D get/setsockopt(int fd, SOL=5FSOCKET, SO=5FPVD=5FHANDLE, &pv= d=5Fhandle=5Ft); > > > =5Bb=5D getaddrinfo/getnameinfo some taking a pvd=5Fhandle=5Ft > > > =5Bc=5D discussion of recvmsg/sendmsg/accept semantics > > > =20 > > > Note that the last is particularly tricky. Operating systems need t= o > > > know how to =22mark=22 incoming packets that would cause a new conn= ection > > > such that they have the correct pvd=5Fhandle=5Ft associated. This h= as > > > lots of impact on suitable address selection as well. > > > =20 > > > The C API should also have at least the following: > > > =20 > > > =5Bd=5D system, process, and per-thread pvd=5Fhandle get/set calls > > > =20 > > > // These values are used by PVD-aware function calls when a PVD ind= ex > > > // is not explicitly specified. > > > pvd=5Fhandle=5Ft pvd=5Fsystem=5Fdefault(); > > > =20 > > > // Same as above, but operates at a per-process level. If no > > > // process-specific default has been set this MUST return the value= > > > // of a call to pvd=5Fsystem=5Fdefault(). > > > pvd=5Fhandle=5Ft pvd=5Fprocess=5Fdefault(); > > > =20 > > > // Same as above, but operates at a per-thread level. If no > > > // thread-specific default has been set this MUST return the value > > > // of a call to pvd=5Fcurrent=5Fprocess=5Fdefault(). > > > pvd=5Fhandle=5Ft pvd=5Fthread=5Fdefault(); > > > =20 > > > int pvd=5Fset=5Fsystem=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && e= rrno =3D E=46OO > > > int pvd=5Fset=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && = errno =3D E=46OO > > > int pvd=5Fset=5Fthread=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && e= rrno =3D E=46OO > > > =20 > > > =5Be=5D good discussion of a variety of E=46OO errno return values.= > > > =20 > > > When a PVD has gone away (e.g. we disconnected from WI=46I), subseq= uent > > > operations on the associated pvd=5Fhandle should fail with errno =3D= > > > ENONET. > > > =20 > > > =5Bf=5D good discussion of how the process and thread default value= s > > > behave across fork/exec > > > =20 > > > =46WIW, Android uses all of the above when NetworkMonitor is valida= ting > > > a network--it does DNS lookups within the PVD, makes pvd-bound sock= ets > > > used for HTTP Direct or Proxy connections to check connectivity to = a > > > URL: > > > =20 > > > https://android.googlesource.com/platform/frameworks/base/+/master/= services/core/java/com/android/server/connectivity/NetworkMonitor.java > > > =20 > > > =5B3=5D the device has to build up configuration data continuously = over > > > time, as DHCP results come back, and RAs come in bringing new prefi= xes > > > or new DNS servers. > > > =20 > > > Not that it's relevant, but Android accumulates these in an > > > android.net.LinkProperties object: > > > =20 > > > https://developer.android.com/reference/android/net/LinkProperties.= html > > > =20 > > > as we currently only support a 1:1 mapping of PVDs to physical inte= rfaces. > > > =20 > > > The means by which the operating system allocates pvd=5Fhandles, ga= thers > > > this data and associates it with a pvd=5Fhandle (including marking > > > incoming packets that would causes a new connection) might best be > > > left for a separate document, since sections 1 and 2 and background= > > > theory will require a fair amount of text. > > > =20 > > > =5B4=5D Android lets processes register callbacks to be called when= > > > certain network properties change, or when a new network shows up, = or > > > one goes away. This is how applications receive the handles (Networ= k > > > objects). > > > =20 > > > The UNIX way of doing these sorts of things...well, frequently leav= es > > > much to be desired...but we should support multiple event-driven > > > models, I think. > > > =20 > > > =5B5=5D we'll want an API for an application to pass in a handle an= d get > > > an ever expanding list of parameters (expanding as we think to add > > > them and write documents about them). > > > =20 > > > The Android ConnectivityManager mitigates all this stuff and passes= > > > around NetworkInfo objects which encapsulate extra information like= > > > SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i, or whether= it's > > > metered, and so on. > > > =20 > > > The closest UNIX-style analogy here would be some interface that is= > > > getsockopt()-like, I think. Something like: > > > =20 > > > int pvd=5Fget=5Fattribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7C= METERED=7C...), > > > void *returned=5Fblob); > > > =20 > > > And then it will be possible for code to be written like > > > =20 > > > =23ifdef PVD=5FATTR=5FHTTP=5FPROXY=5FURL > > > =20 > > > char proxyString=5BPVD=5FATTR=5FHTTP=5FPROXY=5FURL=5FMAXLEN=5D; > > > memset(proxyString, 0, sizeof(proxyString)); > > > if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5FATTR=5FHTTP=5FPROX= Y=5FURL, proxyString)) =7B > > > perror(=22Sadness=21=22); > > > return -1; > > > =7D > > > =20 > > > =23endif > > > =20 > > > =20 > > > --- > > > =20 > > > That's a massive brain dump, and I apologize for it and also that i= t's so late. > > > =20 > > > Let me know what y'all think. > > > -Erik > > > =20 > > > On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng wrote: > > > > Hi Erik > > > > > > > > We are waiting for your lead to start this work asap. =46eel free= to us know > > > > when you are ready. > > > > > > > > Hi Ian, thanks a lot for letting us know that you are going to wo= rk with a > > > > university on the implementations. > > > > Erik was quite busy for 3GPP SA2 work recently, we are waiting fo= r his > > > > return to lead the work. > > > > > > > > Best regards, > > > > > > > > DENG Hui > > > > > > > > > > > >> =46rom: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com) > > > >> Subject: MI=46 API Design Team > > > >> Date: Mon, 8 Jun 2015 14:07:02 +0200 > > > >> CC: mikael.abrahamsson=40t-systems.com (mailto:mikael.abrahamsso= n=40t-systems.com) > > > >> To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > > >> > > > >> Hi Hui, > > > >> > > > >> My apologies for not being in contact sooner. Things don=E2=80=99= t always move as > > > >> quickly as hoped around here=21 > > > >> > > > >> The current status is that we have provisionally obtained the ne= cessary > > > >> resources to start working on a proof of concept implementation = of the MI=46 > > > >> architecture. We will be doing this in partnership with a Univer= sity. > > > >> > > > >> Tomorrow (9th July) we will start the scoping work with the impl= ementor. > > > >> What I want to come out of this work is a proof of concept imple= mentation of > > > >> the MI=46 architecture on a =E2=80=98generic=E2=80=99 Linux base= d platform. As Eric is working > > > >> on an Android implementation for the mobile use case, I think th= at this > > > >> should complement his work quite well and serve to provide some = good > > > >> implementation experience which can be fed back into the update = of the MI=46 > > > >> API document. > > > >> > > > >> I=E2=80=99ve sent a subscription request to the MI=46 API design= team mailing list. > > > >> Once we=E2=80=99ve got some firmer details agreed with the imple= mentors, I=E2=80=99ll make > > > >> an announcement on the m/l of what we=E2=80=99re doing and we ca= n discuss what the > > > >> best way of aligning the two implementation efforts. > > > >> > > > >> Best regards, > > > >> Ian > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Mpvdapi mailing list > > Mpvdapi=40ietf.org (mailto:Mpvdapi=40ietf.org) > > https://www.ietf.org/mailman/listinfo/mpvdapi > > =20 > > =20 > > =20 > =20 > =20 > =20 > =E9=99=84=E4=BB=B6=EF=BC=9A =20 > - draft-liu-mif-socket-api-00.txt > =20 --559a1f48_74b0dc51_1656 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 7=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 6:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC=9A

Hi Hui and Erik,

Attachment is the draft I menti= oned during the discussion. It was written before the Dallas meeting and = it may not reflect the latest consensus we have. 

I am trying to update it.



--=  
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 7=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 3:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A

Hi Erik
 
I guess that everbody is busy w= ith deadline,
could you kindly help to write down a draft about this p= roposal and then present it during coming MI=46 sesson,
then we = get more people to review on how Android implement this.
 
Tha= nks a lot for your kind work
Best regards,
 
DENG Hui<= br>
 
> =46rom: ek=40google.com
> Date: Mon, 15 Jun 2015 19:55:15 +0900
>= ; Subject: Re: MI=46 API Design Team
> To: denghui02=40hotmail.com
> CC: ianfarrer=40gmx.com; mikael.abrahamsson=40t-systems= .com; mpvdapi=40ietf.org
>
> Sorry about that: it's back to back 3GPP and now Andro= id release issues.
>
> I spent the weekend reworking some no= tes on the things I described in
> Dallas. That's not coming toget= her quickly enough so let me lay
> everything out here instead. In= so doing I will try to describe more
> about the approach Android = took to see if people even think it makes
> sense.
>
>= Let's assume for the sake of argument that C API definitions are
>= nicely isolated, maybe in some =23include <netpvd.h> header file.<= br>>
> =5B1=5D Provisioning domains are represented by a =22han= dle=22 kind of class,
> android.net.Network:
>
> <= a href=3D=22https://developer.android.com/reference/android/net/Network.h= tml=22>https://developer.android.com/reference/android/net/Network.html
>
> These are essentially handles to identify instances o= f attaches to
> provisioning domains. The underlying identifier va= lues are not
> recycled (except after a really long time). Multipl= e temporally
> disparate attaches to the same network each get a ne= w instance
> value--we have not yet found it of value to try to de-= duplicate
> attaches. Applications that want to know if you're att= ached to
> =22Starbucks=22 so they can startup and auto-sign-in use= the relevant
> handle value to query parameters (like SSID).
&g= t;
> I would propose that a C API would have something like
>= ;
> typedef uint64=5Ft pvd=5Fhandle=5Ft
> =23define = PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0)
>
> =5B2=5D Once= an application has received a Network handle =5Blet's save how
> t= hat happens for later=5D it can request that certain operations be
>= ; performed specifically within the associated PVD. Currently these
&= gt; operations include:
>
> =5Bbind a file descriptor to= a PVD to force packets to be sent using
> the PVD's routing table=5D=
> android.net.Network=23bindSocket()
> https://developer.android.com/reference/android/n= et/Network.html=23bindSocket(java.net.Socket)
>
> =5B= perform DNS lookups using a PVD's DNS servers=5D
> android.net.= Network=23getAllByName()
> https://developer.android.com/reference/android/net/Network.html=23ge= tAllByName(java.lang.String)
>
> =5Bset the PVD for = all file descriptors and DNS lookups for a
> process, unless otherw= ise overridden=5D
> android.net.ConnectivityManager=23setProces= sDefaultNetwork()
> https://developer.android.com/reference/android/n= et/ConnectivityManager.html=23setProcessDefaultNetwork(android.net.Networ= k)
>
> I would propose that a C API have at least the fo= llowing:
>
> =5Ba=5D get/setsockopt(int fd, SOL=5FSOCKET= , SO=5FPVD=5FHANDLE, &pvd=5Fhandle=5Ft);
> =5Bb=5D getaddri= nfo/getnameinfo some taking a pvd=5Fhandle=5Ft
> =5Bc=5D discus= sion of recvmsg/sendmsg/accept semantics
>
> Note that the l= ast is particularly tricky. Operating systems need to
> know how t= o =22mark=22 incoming packets that would cause a new connection
> s= uch that they have the correct pvd=5Fhandle=5Ft associated. This has
= > lots of impact on suitable address selection as well.
>
&g= t; The C API should also have at least the following:
>
> = =5Bd=5D system, process, and per-thread pvd=5Fhandle get/set calls
&= gt;
> // These values are used by PVD-aware function calls whe= n a PVD index
> // is not explicitly specified.
> pvd= =5Fhandle=5Ft pvd=5Fsystem=5Fdefault();
>
> // Same as a= bove, but operates at a per-process level. If no
> // process-= specific default has been set this MUST return the value
> // o= f a call to pvd=5Fsystem=5Fdefault().
> pvd=5Fhandle=5Ft pvd=5F= process=5Fdefault();
>
> // Same as above, but operates = at a per-thread level. If no
> // thread-specific default has = been set this MUST return the value
> // of a call to pvd=5Fcur= rent=5Fprocess=5Fdefault().
> pvd=5Fhandle=5Ft pvd=5Fthread=5Fd= efault();
>
> int pvd=5Fset=5Fsystem=5Fdefault(pvd=5Fhan= dle=5Ft); // 0 or -1 && errno =3D E=46OO
> int pvd=5Fs= et=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && errno =3D= E=46OO
> int pvd=5Fset=5Fthread=5Fdefault(pvd=5Fhandle=5Ft); = // 0 or -1 && errno =3D E=46OO
>
> =5Be=5D good = discussion of a variety of E=46OO errno return values.
>
> W= hen a PVD has gone away (e.g. we disconnected from WI=46I), subsequent> operations on the associated pvd=5Fhandle should fail with errno =3D=
> ENONET.
>
> =5Bf=5D good discussion of how the = process and thread default values
> behave across fork/exec
>=
> =46WIW, Android uses all of the above when NetworkMonitor is va= lidating
> a network--it does DNS lookups within the PVD, makes pvd= -bound sockets
> used for HTTP Direct or Proxy connections to check= connectivity to a
> URL:
>
> https://andr= oid.googlesource.com/platform/frameworks/base/+/master/services/core/java= /com/android/server/connectivity/NetworkMonitor.java
>
>= =5B3=5D the device has to build up configuration data continuously over<= br>> time, as DHCP results come back, and RAs come in bringing new pre= fixes
> or new DNS servers.
>
> Not that it's relevant= , but Android accumulates these in an
> android.net.LinkProperties = object:
>
> https://developer.android.com= /reference/android/net/LinkProperties.html
>
> as we cur= rently only support a 1:1 mapping of PVDs to physical interfaces.
>=
> The means by which the operating system allocates pvd=5Fhandles= , gathers
> this data and associates it with a pvd=5Fhandle (includ= ing marking
> incoming packets that would causes a new connection) = might best be
> left for a separate document, since sections 1 and = 2 and background
> theory will require a fair amount of text.
&g= t;
> =5B4=5D Android lets processes register callbacks to be calle= d when
> certain network properties change, or when a new network s= hows up, or
> one goes away. This is how applications receive the = handles (Network
> objects).
>
> The UNIX way of doing= these sorts of things...well, frequently leaves
> much to be desir= ed...but we should support multiple event-driven
> models, I think.=
>
> =5B5=5D we'll want an API for an application to pass in= a handle and get
> an ever expanding list of parameters (expanding= as we think to add
> them and write documents about them).
>=
> The Android ConnectivityManager mitigates all this stuff and pa= sses
> around NetworkInfo objects which encapsulate extra informati= on like
> SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i, = or whether it's
> metered, and so on.
>
> The closest = UNIX-style analogy here would be some interface that is
> getsockop= t()-like, I think. Something like:
>
> int pvd=5Fget=5F= attribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7CMETERED=7C...),
>= ; void *returned=5Fblob);
>
> And then it will be possible f= or code to be written like
>
> =23ifdef PVD=5FATTR=5FHTT= P=5FPROXY=5FURL
>
> char proxyString=5BPVD=5FATTR=5FHTTP= =5FPROXY=5FURL=5FMAXLEN=5D;
> memset(proxyString, 0, sizeof(pro= xyString));
> if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5F= ATTR=5FHTTP=5FPROXY=5FURL, proxyString)) =7B
> perror(=22Sa= dness=21=22);
> return -1;
> =7D
>
>= =23endif
>
>
> ---
>
> That's a mas= sive brain dump, and I apologize for it and also that it's so late.
&g= t;
> Let me know what y'all think.
> -Erik
>
> = On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng <denghui02=40hotmail.com> wrote:
> > H= i Erik
> >
> > We are waiting for your lead to start th= is work asap. =46eel free to us know
> > when you are ready.
= > >
> > Hi Ian, thanks a lot for letting us know that yo= u are going to work with a
> > university on the implementations= .
> > Erik was quite busy for 3GPP SA2 work recently, we are wai= ting for his
> > return to lead the work.
> >
> &= gt; Best regards,
> >
> > DENG Hui
> >
>= >
> >> =46rom: ianfarrer=40gmx.com
> >> Subject: MI=46 API Design Team<= br>> >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> >> CC= : mikael.abraha= msson=40t-systems.com
> >> To: denghui02=40hotmail.com
> >>
>= >> Hi Hui,
> >>
> >> My apologies for not = being in contact sooner. Things don=E2=80=99t always move as
> >= > quickly as hoped around here=21
> >>
> >> Th= e current status is that we have provisionally obtained the necessary
= > >> resources to start working on a proof of concept implementa= tion of the MI=46
> >> architecture. We will be doing this in= partnership with a University.
> >>
> >> Tomorro= w (9th July) we will start the scoping work with the implementor.
>= >> What I want to come out of this work is a proof of concept impl= ementation of
> >> the MI=46 architecture on a =E2=80=98gener= ic=E2=80=99 Linux based platform. As Eric is working
> >> on = an Android implementation for the mobile use case, I think that this
&= gt; >> should complement his work quite well and serve to provide s= ome good
> >> implementation experience which can be fed back= into the update of the MI=46
> >> API document.
> >= >
> >> I=E2=80=99ve sent a subscription request to the MI=46= API design team mailing list.
> >> Once we=E2=80=99ve got so= me firmer details agreed with the implementors, I=E2=80=99ll make
>= >> an announcement on the m/l of what we=E2=80=99re doing and we c= an discuss what the
> >> best way of aligning the two impleme= ntation efforts.
> >>
> >> Best regards,
> = >> Ian
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Mpvdapi mailing list
 =20 =20 =20 =20

=20 =20

=20
=E9=99=84=E4=BB=B6=EF=BC=9A
=20 =20 =20 =20 =20 =20 =20
=20
- draft-liu-mif-socket-api-00.txt=
=20
=20 =20 =20
=20

--559a1f48_74b0dc51_1656-- From nobody Mon Jul 6 00:21:04 2015 Return-Path: X-Original-To: mpvdapi@ietfa.amsl.com Delivered-To: mpvdapi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E41A3B9F for ; Mon, 6 Jul 2015 00:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.299 X-Spam-Level: **** X-Spam-Status: No, score=4.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yFOoaIhnZfc for ; Mon, 6 Jul 2015 00:21:00 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD3E1A1EEE for ; Mon, 6 Jul 2015 00:21:00 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so144079611wib.1 for ; Mon, 06 Jul 2015 00:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RURT9q7bWqNcvzVa6gDTKVlWbw+9tRsOsxIajfXlaP0=; b=T/OVld2QRxQihs14SyJppntOuy+RZv+O47VPWgwHjPXUmhWPxBOmYX1Fe1z1TxbjNA u1CiYGw1duDVE/+7CvuOSGrMWrAmFepa4226vMwDKGwNmRz+s0BDryCMFL1TkWq8Ix+g aANjOcr8vMDpHk+O198l665HTbVcRXfn90zyBCUFL1lpXQIyzu0s3AGCiuVLK6ujrrIK mo2+37Yupk4AIoFP8pr2oW00FTVOTGysY/K9hAiuvjgiP4cgDvj8UhYXS0V61jXkGpvr MEk/TsTRencVuNKYlnuOiIL7Ym27OSadYmUKG3TdoxeJixDsC4NCtkZ3NBHv65aZhFyK QmUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=RURT9q7bWqNcvzVa6gDTKVlWbw+9tRsOsxIajfXlaP0=; b=HOVYTra6XE4Y/DWc7iaH8ZeXrYZBYjDFqYXPC/drNqIePXd6oSzudQ34aghq7xPvkh uC4x3Q+P+Fgdy6HnlQBgpux2gI8NyJhkOsRuF/apGkLIgLPSqtFZ7AOZbTkAfDBagfNZ Cup3EAuHAB/HE9w0TTDg7/TBI7lBoWPNb3IEj4B77gzIiMuWjgOBOSpHTzy/zmkbNAJJ 5oIczcUThgqb3LqDPKUyBDuS7RlgRSc3A/3fnixwa5VfPkGwhjxoTV4TaOGzA2vM3uJH O0v6GQflcyT3SVz3nyKD1hF9Lds7PJIJnaHg/4mY8W30WIxJQGl+MBWvizkuNeXbHnba jpcg== X-Gm-Message-State: ALoCoQmPlFWxm/sGnZTaGt3MICMS5lMmkRZgBvYPtu8vkkBaSa9u7DtlmeLXaRWybvSOYJIu+AAf X-Received: by 10.180.78.136 with SMTP id b8mr48711311wix.89.1436167258991; Mon, 06 Jul 2015 00:20:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Mon, 6 Jul 2015 00:20:39 -0700 (PDT) In-Reply-To: References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <2DF18DBB97774B22A8D78C461ACED61B@gmail.com> From: Erik Kline Date: Mon, 6 Jul 2015 16:20:39 +0900 Message-ID: To: Hui Deng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mikael Abrahamsson , Ian Farrer , Margaret , "mpvdapi@ietf.org" , Dapeng Liu Subject: Re: [Mpvdapi] =?utf-8?b?5Zue5aSN77yaICBNSUYgQVBJIERlc2lnbiBUZWFt?= X-BeenThere: mpvdapi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:21:03 -0000 I will take the notes I sent out and reformat them into a draft before the deadline. We can sync up in Prague and decide what to do and how to merge, etc... On 6 July 2015 at 16:04, Hui Deng wrote: > Hi Dapeng > > At this moment, we would expect that Erik could lead this MIF MPVD API > design tem, please try to contribute the design team work from your draft= . > thanks a lot for your cooperation > > Best regards, > > DENG Hui > > > ________________________________ > Date: Mon, 6 Jul 2015 14:25:12 +0800 > From: maxpassion@gmail.com > To: denghui02@hotmail.com > CC: ek@google.com; margaretw42@gmail.com; mikael.abrahamsson@t-systems.co= m; > mpvdapi@ietf.org; ianfarrer@gmx.com > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [Mpvdapi] MIF API Design Team > > > The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-api= -00 > > -- > Dapeng Liu > > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=886:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC= =9A > > Hi Hui and Erik, > > Attachment is the draft I mentioned during the discussion. It was written > before the Dallas meeting and it may not reflect the latest consensus we > have. > > I am trying to update it. > > > > -- > Dapeng Liu > > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=883:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC= =9A > > Hi Erik > > I guess that everbody is busy with deadline, > could you kindly help to write down a draft about this proposal and then > present it during coming MIF sesson, > then we get more people to review on how Android implement this. > > Thanks a lot for your kind work > Best regards, > > DENG Hui > > >> From: ek@google.com >> Date: Mon, 15 Jun 2015 19:55:15 +0900 >> Subject: Re: MIF API Design Team >> To: denghui02@hotmail.com >> CC: ianfarrer@gmx.com; mikael.abrahamsson@t-systems.com; mpvdapi@ietf.or= g >> >> Sorry about that: it's back to back 3GPP and now Android release issues. >> >> I spent the weekend reworking some notes on the things I described in >> Dallas. That's not coming together quickly enough so let me lay >> everything out here instead. In so doing I will try to describe more >> about the approach Android took to see if people even think it makes >> sense. >> >> Let's assume for the sake of argument that C API definitions are >> nicely isolated, maybe in some #include header file. >> >> [1] Provisioning domains are represented by a "handle" kind of class, >> android.net.Network: >> >> https://developer.android.com/reference/android/net/Network.html >> >> These are essentially handles to identify instances of attaches to >> provisioning domains. The underlying identifier values are not >> recycled (except after a really long time). Multiple temporally >> disparate attaches to the same network each get a new instance >> value--we have not yet found it of value to try to de-duplicate >> attaches. Applications that want to know if you're attached to >> "Starbucks" so they can startup and auto-sign-in use the relevant >> handle value to query parameters (like SSID). >> >> I would propose that a C API would have something like >> >> typedef uint64_t pvd_handle_t >> #define PVD_HANDLE_UNSPEC ((pvd_handle_t)0) >> >> [2] Once an application has received a Network handle [let's save how >> that happens for later] it can request that certain operations be >> performed specifically within the associated PVD. Currently these >> operations include: >> >> [bind a file descriptor to a PVD to force packets to be sent using >> the PVD's routing table] >> android.net.Network#bindSocket() >> >> https://developer.android.com/reference/android/net/Network.html#bindSoc= ket(java.net.Socket) >> >> [perform DNS lookups using a PVD's DNS servers] >> android.net.Network#getAllByName() >> >> https://developer.android.com/reference/android/net/Network.html#getAllB= yName(java.lang.String) >> >> [set the PVD for all file descriptors and DNS lookups for a >> process, unless otherwise overridden] >> android.net.ConnectivityManager#setProcessDefaultNetwork() >> >> https://developer.android.com/reference/android/net/ConnectivityManager.= html#setProcessDefaultNetwork(android.net.Network) >> >> I would propose that a C API have at least the following: >> >> [a] get/setsockopt(int fd, SOL_SOCKET, SO_PVD_HANDLE, &pvd_handle_t); >> [b] getaddrinfo/getnameinfo some taking a pvd_handle_t >> [c] discussion of recvmsg/sendmsg/accept semantics >> >> Note that the last is particularly tricky. Operating systems need to >> know how to "mark" incoming packets that would cause a new connection >> such that they have the correct pvd_handle_t associated. This has >> lots of impact on suitable address selection as well. >> >> The C API should also have at least the following: >> >> [d] system, process, and per-thread pvd_handle get/set calls >> >> // These values are used by PVD-aware function calls when a PVD index >> // is not explicitly specified. >> pvd_handle_t pvd_system_default(); >> >> // Same as above, but operates at a per-process level. If no >> // process-specific default has been set this MUST return the value >> // of a call to pvd_system_default(). >> pvd_handle_t pvd_process_default(); >> >> // Same as above, but operates at a per-thread level. If no >> // thread-specific default has been set this MUST return the value >> // of a call to pvd_current_process_default(). >> pvd_handle_t pvd_thread_default(); >> >> int pvd_set_system_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> int pvd_set_process_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> int pvd_set_thread_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> >> [e] good discussion of a variety of EFOO errno return values. >> >> When a PVD has gone away (e.g. we disconnected from WIFI), subsequent >> operations on the associated pvd_handle should fail with errno =3D >> ENONET. >> >> [f] good discussion of how the process and thread default values >> behave across fork/exec >> >> FWIW, Android uses all of the above when NetworkMonitor is validating >> a network--it does DNS lookups within the PVD, makes pvd-bound sockets >> used for HTTP Direct or Proxy connections to check connectivity to a >> URL: >> >> >> https://android.googlesource.com/platform/frameworks/base/+/master/servi= ces/core/java/com/android/server/connectivity/NetworkMonitor.java >> >> [3] the device has to build up configuration data continuously over >> time, as DHCP results come back, and RAs come in bringing new prefixes >> or new DNS servers. >> >> Not that it's relevant, but Android accumulates these in an >> android.net.LinkProperties object: >> >> https://developer.android.com/reference/android/net/LinkProperties.html >> >> as we currently only support a 1:1 mapping of PVDs to physical interface= s. >> >> The means by which the operating system allocates pvd_handles, gathers >> this data and associates it with a pvd_handle (including marking >> incoming packets that would causes a new connection) might best be >> left for a separate document, since sections 1 and 2 and background >> theory will require a fair amount of text. >> >> [4] Android lets processes register callbacks to be called when >> certain network properties change, or when a new network shows up, or >> one goes away. This is how applications receive the handles (Network >> objects). >> >> The UNIX way of doing these sorts of things...well, frequently leaves >> much to be desired...but we should support multiple event-driven >> models, I think. >> >> [5] we'll want an API for an application to pass in a handle and get >> an ever expanding list of parameters (expanding as we think to add >> them and write documents about them). >> >> The Android ConnectivityManager mitigates all this stuff and passes >> around NetworkInfo objects which encapsulate extra information like >> SSIDs, whether the Network is Ethernet, Mobile, Wi-Fi, or whether it's >> metered, and so on. >> >> The closest UNIX-style analogy here would be some interface that is >> getsockopt()-like, I think. Something like: >> >> int pvd_get_attribute(pvd_handle_t, PVD_ATTR_(HWTYPE|METERED|...), >> void *returned_blob); >> >> And then it will be possible for code to be written like >> >> #ifdef PVD_ATTR_HTTP_PROXY_URL >> >> char proxyString[PVD_ATTR_HTTP_PROXY_URL_MAXLEN]; >> memset(proxyString, 0, sizeof(proxyString)); >> if (!pvg_get_attribute(pvd_handle, PVD_ATTR_HTTP_PROXY_URL, proxyString)= ) >> { >> perror("Sadness!"); >> return -1; >> } >> >> #endif >> >> >> --- >> >> That's a massive brain dump, and I apologize for it and also that it's s= o >> late. >> >> Let me know what y'all think. >> -Erik >> >> On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng wrote: >> > Hi Erik >> > >> > We are waiting for your lead to start this work asap. Feel free to us >> > know >> > when you are ready. >> > >> > Hi Ian, thanks a lot for letting us know that you are going to work wi= th >> > a >> > university on the implementations. >> > Erik was quite busy for 3GPP SA2 work recently, we are waiting for his >> > return to lead the work. >> > >> > Best regards, >> > >> > DENG Hui >> > >> > >> >> From: ianfarrer@gmx.com >> >> Subject: MIF API Design Team >> >> Date: Mon, 8 Jun 2015 14:07:02 +0200 >> >> CC: mikael.abrahamsson@t-systems.com >> >> To: denghui02@hotmail.com >> >> >> >> Hi Hui, >> >> >> >> My apologies for not being in contact sooner. Things don=E2=80=99t al= ways move >> >> as >> >> quickly as hoped around here! >> >> >> >> The current status is that we have provisionally obtained the necessa= ry >> >> resources to start working on a proof of concept implementation of th= e >> >> MIF >> >> architecture. We will be doing this in partnership with a University. >> >> >> >> Tomorrow (9th July) we will start the scoping work with the >> >> implementor. >> >> What I want to come out of this work is a proof of concept >> >> implementation of >> >> the MIF architecture on a =E2=80=98generic=E2=80=99 Linux based platf= orm. As Eric is >> >> working >> >> on an Android implementation for the mobile use case, I think that th= is >> >> should complement his work quite well and serve to provide some good >> >> implementation experience which can be fed back into the update of th= e >> >> MIF >> >> API document. >> >> >> >> I=E2=80=99ve sent a subscription request to the MIF API design team m= ailing >> >> list. >> >> Once we=E2=80=99ve got some firmer details agreed with the implemento= rs, I=E2=80=99ll >> >> make >> >> an announcement on the m/l of what we=E2=80=99re doing and we can dis= cuss what >> >> the >> >> best way of aligning the two implementation efforts. >> >> >> >> Best regards, >> >> Ian > _______________________________________________ > Mpvdapi mailing list > Mpvdapi@ietf.org > https://www.ietf.org/mailman/listinfo/mpvdapi > > > > =E9=99=84=E4=BB=B6=EF=BC=9A > - draft-liu-mif-socket-api-00.txt > > From nobody Mon Jul 6 00:31:46 2015 Return-Path: X-Original-To: mpvdapi@ietfa.amsl.com Delivered-To: mpvdapi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892261A8AEC for ; Mon, 6 Jul 2015 00:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.689 X-Spam-Level: *** X-Spam-Status: No, score=3.689 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-ErQTiqYMUk for ; Mon, 6 Jul 2015 00:31:39 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE041A6ED9 for ; Mon, 6 Jul 2015 00:31:39 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so101071548pdb.2 for ; Mon, 06 Jul 2015 00:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=4x/18MgGPRjD9fQGYk7LasDkz/5ZFLLyzSpI5WzVbk0=; b=QksRVNVDbx8NSKxklwgfVP7qnB27i1bZxDgvSbCnAC5E5kN7AvowW4T4PJyHKTOONE cQZaUskXuDQJVrzJPrgYb3o2ug9wz5lVkWn2b/905o22ucGRpIYhNEXjDluYZqEpI/VS dDXopFOvm8DeghGzhToFpwEqCwS4+A6Eo7Ehqmj558qYn18P0Vw4Y9N2PLDkbBCZBwwp I46eMkjuS2JYE5C1UzHcO/rkKbkyaQxUeF1GcRGnOTCg45KEcqJZMoqr/66OaKKds0OF G/SLO/tluujfZ08CmBuCRpj02YAyzVNM2zDe6R16XlGDAvkwSnT8LMG7A4CIuoOBAZ6X PoeQ== X-Received: by 10.66.132.81 with SMTP id os17mr102464684pab.153.1436167899020; Mon, 06 Jul 2015 00:31:39 -0700 (PDT) Received: from [10.1.50.207] ([202.55.20.10]) by mx.google.com with ESMTPSA id yr3sm6890877pbb.60.2015.07.06.00.31.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 06 Jul 2015 00:31:37 -0700 (PDT) Date: Mon, 6 Jul 2015 15:31:32 +0800 From: Dapeng Liu To: Hui Deng Message-ID: In-Reply-To: References: X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="559a2ed4_70a64e2a_1656" Archived-At: Cc: Erik Kline , Mikael Abrahamsson , Margaret , "=?utf-8?Q?mpvdapi=40ietf.org?=" , Ian Farrer Subject: [Mpvdapi] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= MIF API Design Team X-BeenThere: mpvdapi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:31:43 -0000 --559a2ed4_70a64e2a_1656 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B47=E6=9C=886=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=883:04=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A= > Hi Dapeng > =20 > At this moment, we would expect that Erik could lead this MI=46 MPVD AP= I design tem, please try to contribute the design team work from your dra= ft. > thanks a lot for your cooperation Hi Hui, =20 Sure. =20 The draft is used used for the design team=E2=80=99s reference since it h= as some similarity with what Eric proposed in the list. =20 Thanks, Dapeng Liu > =20 > Best regards, > =20 > DENG Hui > =20 > =20 > Date: Mon, 6 Jul 2015 14:25:12 +0800 > =46rom: maxpassion=40gmail.com (mailto:maxpassion=40gmail.com) > To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > CC: ek=40google.com (mailto:ek=40google.com); margaretw42=40gmail.com (= mailto:margaretw42=40gmail.com); mikael.abrahamsson=40t-systems.com (mail= to:mikael.abrahamsson=40t-systems.com); mpvdapi=40ietf.org (mailto:mpvdap= i=40ietf.org); ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com) > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BMpvdapi=5D MI=46 API Design Tea= m > =20 > The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-a= pi-00 =20 > =20 > -- =20 > Dapeng Liu > =20 > =20 > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=886:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC= =9A > =20 > > Hi Hui and Erik, =20 > > =20 > > Attachment is the draft I mentioned during the discussion. It was wri= tten before the Dallas meeting and it may not reflect the latest consensu= s we have. =20 > > =20 > > I am trying to update it. =20 > > =20 > > =20 > > =20 > > -- =20 > > Dapeng Liu > > =20 > > =20 > > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=883:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC= =9A > > =20 > > > Hi Erik > > > =20 > > > I guess that everbody is busy with deadline, > > > could you kindly help to write down a draft about this proposal and= then present it during coming MI=46 sesson, =20 > > > then we get more people to review on how Android implement this. > > > =20 > > > Thanks a lot for your kind work > > > Best regards, > > > =20 > > > DENG Hui > > > =20 > > > =20 > > > > =46rom: ek=40google.com (mailto:ek=40google.com) > > > > Date: Mon, 15 Jun 2015 19:55:15 +0900 > > > > Subject: Re: MI=46 API Design Team > > > > To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > > > CC: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com); mikael.abra= hamsson=40t-systems.com (mailto:mikael.abrahamsson=40t-systems.com); mpvd= api=40ietf.org (mailto:mpvdapi=40ietf.org) > > > > =20 > > > > Sorry about that: it's back to back 3GPP and now Android release = issues. > > > > =20 > > > > I spent the weekend reworking some notes on the things I describe= d in > > > > Dallas. That's not coming together quickly enough so let me lay > > > > everything out here instead. In so doing I will try to describe m= ore > > > > about the approach Android took to see if people even think it ma= kes > > > > sense. > > > > =20 > > > > Let's assume for the sake of argument that C API definitions are > > > > nicely isolated, maybe in some =23include header file.= > > > > =20 > > > > =5B1=5D Provisioning domains are represented by a =22handle=22 ki= nd of class, > > > > android.net.Network: > > > > =20 > > > > https://developer.android.com/reference/android/net/Network.html > > > > =20 > > > > These are essentially handles to identify instances of attaches t= o > > > > provisioning domains. The underlying identifier values are not > > > > recycled (except after a really long time). Multiple temporally > > > > disparate attaches to the same network each get a new instance > > > > value--we have not yet found it of value to try to de-duplicate > > > > attaches. Applications that want to know if you're attached to > > > > =22Starbucks=22 so they can startup and auto-sign-in use the rele= vant > > > > handle value to query parameters (like SSID). > > > > =20 > > > > I would propose that a C API would have something like > > > > =20 > > > > typedef uint64=5Ft pvd=5Fhandle=5Ft > > > > =23define PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0) > > > > =20 > > > > =5B2=5D Once an application has received a Network handle =5Blet'= s save how > > > > that happens for later=5D it can request that certain operations = be > > > > performed specifically within the associated PVD. Currently these= > > > > operations include: > > > > =20 > > > > =5Bbind a file descriptor to a PVD to force packets to be sent us= ing > > > > the PVD's routing table=5D > > > > android.net.Network=23bindSocket() > > > > https://developer.android.com/reference/android/net/Network.html=23= bindSocket(java.net.Socket (https://developer.android.com/reference/andro= id/net/Network.html=23bindSocket%28java.net.Socket)) > > > > =20 > > > > =5Bperform DNS lookups using a PVD's DNS servers=5D > > > > android.net.Network=23getAllByName() > > > > https://developer.android.com/reference/android/net/Network.html=23= getAllByName(java.lang.String (https://developer.android.com/reference/an= droid/net/Network.html=23getAllByName%28java.lang.String)) > > > > =20 > > > > =5Bset the PVD for all file descriptors and DNS lookups for a > > > > process, unless otherwise overridden=5D > > > > android.net.ConnectivityManager=23setProcessDefaultNetwork() > > > > https://developer.android.com/reference/android/net/ConnectivityM= anager.html=23setProcessDefaultNetwork(android.net.Network (https://devel= oper.android.com/reference/android/net/ConnectivityManager.html=23setProc= essDefaultNetwork%28android.net.Network)) > > > > =20 > > > > I would propose that a C API have at least the following: > > > > =20 > > > > =5Ba=5D get/setsockopt(int fd, SOL=5FSOCKET, SO=5FPVD=5FHANDLE, &= pvd=5Fhandle=5Ft); > > > > =5Bb=5D getaddrinfo/getnameinfo some taking a pvd=5Fhandle=5Ft > > > > =5Bc=5D discussion of recvmsg/sendmsg/accept semantics > > > > =20 > > > > Note that the last is particularly tricky. Operating systems need= to > > > > know how to =22mark=22 incoming packets that would cause a new co= nnection > > > > such that they have the correct pvd=5Fhandle=5Ft associated. This= has > > > > lots of impact on suitable address selection as well. > > > > =20 > > > > The C API should also have at least the following: > > > > =20 > > > > =5Bd=5D system, process, and per-thread pvd=5Fhandle get/set call= s > > > > =20 > > > > // These values are used by PVD-aware function calls when a PVD i= ndex > > > > // is not explicitly specified. > > > > pvd=5Fhandle=5Ft pvd=5Fsystem=5Fdefault(); > > > > =20 > > > > // Same as above, but operates at a per-process level. If no > > > > // process-specific default has been set this MUST return the val= ue > > > > // of a call to pvd=5Fsystem=5Fdefault(). > > > > pvd=5Fhandle=5Ft pvd=5Fprocess=5Fdefault(); > > > > =20 > > > > // Same as above, but operates at a per-thread level. If no > > > > // thread-specific default has been set this MUST return the valu= e > > > > // of a call to pvd=5Fcurrent=5Fprocess=5Fdefault(). > > > > pvd=5Fhandle=5Ft pvd=5Fthread=5Fdefault(); > > > > =20 > > > > int pvd=5Fset=5Fsystem=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 &&= errno =3D E=46OO > > > > int pvd=5Fset=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 &= & errno =3D E=46OO > > > > int pvd=5Fset=5Fthread=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 &&= errno =3D E=46OO > > > > =20 > > > > =5Be=5D good discussion of a variety of E=46OO errno return value= s. > > > > =20 > > > > When a PVD has gone away (e.g. we disconnected from WI=46I), subs= equent > > > > operations on the associated pvd=5Fhandle should fail with errno = =3D > > > > ENONET. > > > > =20 > > > > =5Bf=5D good discussion of how the process and thread default val= ues > > > > behave across fork/exec > > > > =20 > > > > =46WIW, Android uses all of the above when NetworkMonitor is vali= dating > > > > a network--it does DNS lookups within the PVD, makes pvd-bound so= ckets > > > > used for HTTP Direct or Proxy connections to check connectivity t= o a > > > > URL: > > > > =20 > > > > https://android.googlesource.com/platform/frameworks/base/+/maste= r/services/core/java/com/android/server/connectivity/NetworkMonitor.java > > > > =20 > > > > =5B3=5D the device has to build up configuration data continuousl= y over > > > > time, as DHCP results come back, and RAs come in bringing new pre= fixes > > > > or new DNS servers. > > > > =20 > > > > Not that it's relevant, but Android accumulates these in an > > > > android.net.LinkProperties object: > > > > =20 > > > > https://developer.android.com/reference/android/net/LinkPropertie= s.html > > > > =20 > > > > as we currently only support a 1:1 mapping of PVDs to physical in= terfaces. > > > > =20 > > > > The means by which the operating system allocates pvd=5Fhandles, = gathers > > > > this data and associates it with a pvd=5Fhandle (including markin= g > > > > incoming packets that would causes a new connection) might best b= e > > > > left for a separate document, since sections 1 and 2 and backgrou= nd > > > > theory will require a fair amount of text. > > > > =20 > > > > =5B4=5D Android lets processes register callbacks to be called wh= en > > > > certain network properties change, or when a new network shows up= , or > > > > one goes away. This is how applications receive the handles (Netw= ork > > > > objects). > > > > =20 > > > > The UNIX way of doing these sorts of things...well, frequently le= aves > > > > much to be desired...but we should support multiple event-driven > > > > models, I think. > > > > =20 > > > > =5B5=5D we'll want an API for an application to pass in a handle = and get > > > > an ever expanding list of parameters (expanding as we think to ad= d > > > > them and write documents about them). > > > > =20 > > > > The Android ConnectivityManager mitigates all this stuff and pass= es > > > > around NetworkInfo objects which encapsulate extra information li= ke > > > > SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i, or wheth= er it's > > > > metered, and so on. > > > > =20 > > > > The closest UNIX-style analogy here would be some interface that = is > > > > getsockopt()-like, I think. Something like: > > > > =20 > > > > int pvd=5Fget=5Fattribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7C= METERED=7C...), > > > > void *returned=5Fblob); > > > > =20 > > > > And then it will be possible for code to be written like > > > > =20 > > > > =23ifdef PVD=5FATTR=5FHTTP=5FPROXY=5FURL > > > > =20 > > > > char proxyString=5BPVD=5FATTR=5FHTTP=5FPROXY=5FURL=5FMAXLEN=5D; > > > > memset(proxyString, 0, sizeof(proxyString)); > > > > if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5FATTR=5FHTTP=5FPR= OXY=5FURL, proxyString)) =7B > > > > perror(=22Sadness=21=22); > > > > return -1; > > > > =7D > > > > =20 > > > > =23endif > > > > =20 > > > > =20 > > > > --- > > > > =20 > > > > That's a massive brain dump, and I apologize for it and also that= it's so late. > > > > =20 > > > > Let me know what y'all think. > > > > -Erik > > > > =20 > > > > On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng wrote: > > > > > Hi Erik > > > > > > > > > > We are waiting for your lead to start this work asap. =46eel fr= ee to us know > > > > > when you are ready. > > > > > > > > > > Hi Ian, thanks a lot for letting us know that you are going to = work with a > > > > > university on the implementations. > > > > > Erik was quite busy for 3GPP SA2 work recently, we are waiting = for his > > > > > return to lead the work. > > > > > > > > > > Best regards, > > > > > > > > > > DENG Hui > > > > > > > > > > > > > > >> =46rom: ianfarrer=40gmx.com (mailto:ianfarrer=40gmx.com) > > > > >> Subject: MI=46 API Design Team > > > > >> Date: Mon, 8 Jun 2015 14:07:02 +0200 > > > > >> CC: mikael.abrahamsson=40t-systems.com (mailto:mikael.abrahams= son=40t-systems.com) > > > > >> To: denghui02=40hotmail.com (mailto:denghui02=40hotmail.com) > > > > >> > > > > >> Hi Hui, > > > > >> > > > > >> My apologies for not being in contact sooner. Things don=E2=80= =99t always move as > > > > >> quickly as hoped around here=21 > > > > >> > > > > >> The current status is that we have provisionally obtained the = necessary > > > > >> resources to start working on a proof of concept implementatio= n of the MI=46 > > > > >> architecture. We will be doing this in partnership with a Univ= ersity. > > > > >> > > > > >> Tomorrow (9th July) we will start the scoping work with the im= plementor. > > > > >> What I want to come out of this work is a proof of concept imp= lementation of > > > > >> the MI=46 architecture on a =E2=80=98generic=E2=80=99 Linux ba= sed platform. As Eric is working > > > > >> on an Android implementation for the mobile use case, I think = that this > > > > >> should complement his work quite well and serve to provide som= e good > > > > >> implementation experience which can be fed back into the updat= e of the MI=46 > > > > >> API document. > > > > >> > > > > >> I=E2=80=99ve sent a subscription request to the MI=46 API desi= gn team mailing list. > > > > >> Once we=E2=80=99ve got some firmer details agreed with the imp= lementors, I=E2=80=99ll make > > > > >> an announcement on the m/l of what we=E2=80=99re doing and we = can discuss what the > > > > >> best way of aligning the two implementation efforts. > > > > >> > > > > >> Best regards, > > > > >> Ian > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Mpvdapi mailing list > > > Mpvdapi=40ietf.org (mailto:Mpvdapi=40ietf.org) > > > https://www.ietf.org/mailman/listinfo/mpvdapi > > > =20 > > > =20 > > > =20 > > =20 > > =20 > > =20 > > =E9=99=84=E4=BB=B6=EF=BC=9A =20 > > - draft-liu-mif-socket-api-00.txt > > =20 > =20 > =20 --559a2ed4_70a64e2a_1656 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=E5=9C= =A8 2015=E5=B9=B47=E6=9C=886=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C= =E4=B8=8B=E5=8D=883:04=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A
Hi Dapeng
 
At this moment, we would expe= ct that Erik could lead this MI=46 MPVD API design tem, please try t= o contribute the design team work from your draft.
thanks a = lot for your cooperation
Hi Hui, 

Sure. 
The draft is used used for the design team=E2=80=99s reference since it = has some similarity with what Eric proposed in the list. 
=
Thanks,
Dapeng Liu

 
Best regards,
 
DENG Hui

 
= Date: Mon, 6 Jul 2015 14:25:12 +0800
=46rom: maxpassion=40gmail.com
To: denghui02=40hotmail.com
CC: ek=40google.com; margaretw42=40gmail.com; mikael.abrahamsson=40t-systems.com<= /a>; mpvdapi=40ietf.org; ianfarrer=40gmx.com
Subje= ct: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BMpvdapi=5D MI=46 API Design Team

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 7=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 6:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC=9A

Hi Hui and Erik,

Attachment is the draft I menti= oned during the discussion. It was written before the Dallas meeting and = it may not reflect the latest consensus we have. 

I am trying to update it.



--=  
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 7=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 3:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A

Hi Erik
 
I guess that everbody is busy w= ith deadline,
could you kindly help to write down a draft about this p= roposal and then present it during coming MI=46 sesson,
then we = get more people to review on how Android implement this.
 
Tha= nks a lot for your kind work
Best regards,
 
DENG Hui<= br>
 
> =46rom: ek=40google.com
> Date: Mon, 15 Jun 2015 19:55:15 +0900
>= ; Subject: Re: MI=46 API Design Team
> To: denghui02=40hotmail.com
> CC: ianfarrer=40gmx.com; mikael.abrahamsson=40t-systems= .com; mpvdapi=40ietf.org
>
> Sorry about that: it's back to back 3GPP and now Andro= id release issues.
>
> I spent the weekend reworking some no= tes on the things I described in
> Dallas. That's not coming toget= her quickly enough so let me lay
> everything out here instead. In= so doing I will try to describe more
> about the approach Android = took to see if people even think it makes
> sense.
>
>= Let's assume for the sake of argument that C API definitions are
>= nicely isolated, maybe in some =23include <netpvd.h> header file.<= br>>
> =5B1=5D Provisioning domains are represented by a =22han= dle=22 kind of class,
> android.net.Network:
>
> <= a href=3D=22https://developer.android.com/reference/android/net/Network.h= tml=22 target=3D=22=5Fblank=22>https://developer.android.com/reference/an= droid/net/Network.html
>
> These are essentially handles= to identify instances of attaches to
> provisioning domains. The = underlying identifier values are not
> recycled (except after a rea= lly long time). Multiple temporally
> disparate attaches to the sa= me network each get a new instance
> value--we have not yet found i= t of value to try to de-duplicate
> attaches. Applications that wa= nt to know if you're attached to
> =22Starbucks=22 so they can star= tup and auto-sign-in use the relevant
> handle value to query param= eters (like SSID).
>
> I would propose that a C API would ha= ve something like
>
> typedef uint64=5Ft pvd=5Fhandle=5F= t
> =23define PVD=5FHANDLE=5FUNSPEC ((pvd=5Fhandle=5Ft)0)
&g= t;
> =5B2=5D Once an application has received a Network handle =5B= let's save how
> that happens for later=5D it can request that cert= ain operations be
> performed specifically within the associated PV= D. Currently these
> operations include:
>
> =5Bb= ind a file descriptor to a PVD to force packets to be sent using
> = the PVD's routing table=5D
> android.net.Network=23bindSocket()=
> https://developer.android.com/reference/android/net/Network.html=23bindS= ocket(java.net.Socket)
>
> =5Bperform DNS lookups us= ing a PVD's DNS servers=5D
> android.net.Network=23getAllByName= ()
> https://developer.android.com/reference/android/net/Network.html=23= getAllByName(java.lang.String)
>
> =5Bset the PVD fo= r all file descriptors and DNS lookups for a
> process, unless othe= rwise overridden=5D
> android.net.ConnectivityManager=23setProc= essDefaultNetwork()
> https://developer.and= roid.com/reference/android/net/ConnectivityManager.html=23setProcessDefau= ltNetwork(android.net.Network)
>
> I would propose that = a C API have at least the following:
>
> =5Ba=5D get/set= sockopt(int fd, SOL=5FSOCKET, SO=5FPVD=5FHANDLE, &pvd=5Fhandle=5Ft);<= br>> =5Bb=5D getaddrinfo/getnameinfo some taking a pvd=5Fhandle=5F= t
> =5Bc=5D discussion of recvmsg/sendmsg/accept semantics
&= gt;
> Note that the last is particularly tricky. Operating system= s need to
> know how to =22mark=22 incoming packets that would caus= e a new connection
> such that they have the correct pvd=5Fhandle=5F= t associated. This has
> lots of impact on suitable address select= ion as well.
>
> The C API should also have at least the fol= lowing:
>
> =5Bd=5D system, process, and per-thread pvd=5F= handle get/set calls
>
> // These values are used by PVD= -aware function calls when a PVD index
> // is not explicitly s= pecified.
> pvd=5Fhandle=5Ft pvd=5Fsystem=5Fdefault();
> =
> // Same as above, but operates at a per-process level. If n= o
> // process-specific default has been set this MUST return t= he value
> // of a call to pvd=5Fsystem=5Fdefault().
> = pvd=5Fhandle=5Ft pvd=5Fprocess=5Fdefault();
>
> // Sam= e as above, but operates at a per-thread level. If no
> // thr= ead-specific default has been set this MUST return the value
> = // of a call to pvd=5Fcurrent=5Fprocess=5Fdefault().
> pvd=5Fha= ndle=5Ft pvd=5Fthread=5Fdefault();
>
> int pvd=5Fset=5Fs= ystem=5Fdefault(pvd=5Fhandle=5Ft); // 0 or -1 && errno =3D E=46O= O
> int pvd=5Fset=5Fprocess=5Fdefault(pvd=5Fhandle=5Ft); // 0 = or -1 && errno =3D E=46OO
> int pvd=5Fset=5Fthread=5Fde= fault(pvd=5Fhandle=5Ft); // 0 or -1 && errno =3D E=46OO
> =
> =5Be=5D good discussion of a variety of E=46OO errno return = values.
>
> When a PVD has gone away (e.g. we disconnected f= rom WI=46I), subsequent
> operations on the associated pvd=5Fhandle= should fail with errno =3D
> ENONET.
>
> =5Bf=5D = good discussion of how the process and thread default values
> beha= ve across fork/exec
>
> =46WIW, Android uses all of the abov= e when NetworkMonitor is validating
> a network--it does DNS lookup= s within the PVD, makes pvd-bound sockets
> used for HTTP Direct or= Proxy connections to check connectivity to a
> URL:
>
&g= t; https://android.googlesource.com/p= latform/frameworks/base/+/master/services/core/java/com/android/server/co= nnectivity/NetworkMonitor.java
>
> =5B3=5D the device ha= s to build up configuration data continuously over
> time, as DHCP = results come back, and RAs come in bringing new prefixes
> or new D= NS servers.
>
> Not that it's relevant, but Android accumula= tes these in an
> android.net.LinkProperties object:
>
&g= t; https://developer.android.c= om/reference/android/net/LinkProperties.html
>
> as we c= urrently only support a 1:1 mapping of PVDs to physical interfaces.
&g= t;
> The means by which the operating system allocates pvd=5Fhandl= es, gathers
> this data and associates it with a pvd=5Fhandle (incl= uding marking
> incoming packets that would causes a new connection= ) might best be
> left for a separate document, since sections 1 an= d 2 and background
> theory will require a fair amount of text.
= >
> =5B4=5D Android lets processes register callbacks to be cal= led when
> certain network properties change, or when a new network= shows up, or
> one goes away. This is how applications receive th= e handles (Network
> objects).
>
> The UNIX way of doi= ng these sorts of things...well, frequently leaves
> much to be des= ired...but we should support multiple event-driven
> models, I thin= k.
>
> =5B5=5D we'll want an API for an application to pass = in a handle and get
> an ever expanding list of parameters (expandi= ng as we think to add
> them and write documents about them).
&g= t;
> The Android ConnectivityManager mitigates all this stuff and = passes
> around NetworkInfo objects which encapsulate extra informa= tion like
> SSIDs, whether the Network is Ethernet, Mobile, Wi-=46i= , or whether it's
> metered, and so on.
>
> The closes= t UNIX-style analogy here would be some interface that is
> getsock= opt()-like, I think. Something like:
>
> int pvd=5Fget=5F= attribute(pvd=5Fhandle=5Ft, PVD=5FATTR=5F(HWTYPE=7CMETERED=7C...),
>= ; void *returned=5Fblob);
>
> And then it will be possible f= or code to be written like
>
> =23ifdef PVD=5FATTR=5FHTT= P=5FPROXY=5FURL
>
> char proxyString=5BPVD=5FATTR=5FHTTP= =5FPROXY=5FURL=5FMAXLEN=5D;
> memset(proxyString, 0, sizeof(pro= xyString));
> if (=21pvg=5Fget=5Fattribute(pvd=5Fhandle, PVD=5F= ATTR=5FHTTP=5FPROXY=5FURL, proxyString)) =7B
> perror(=22Sa= dness=21=22);
> return -1;
> =7D
>
>= =23endif
>
>
> ---
>
> That's a mas= sive brain dump, and I apologize for it and also that it's so late.
&g= t;
> Let me know what y'all think.
> -Erik
>
> = On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng <denghui02=40hotmail.com> wrote:
> > H= i Erik
> >
> > We are waiting for your lead to start th= is work asap. =46eel free to us know
> > when you are ready.
= > >
> > Hi Ian, thanks a lot for letting us know that yo= u are going to work with a
> > university on the implementations= .
> > Erik was quite busy for 3GPP SA2 work recently, we are wai= ting for his
> > return to lead the work.
> >
> &= gt; Best regards,
> >
> > DENG Hui
> >
>= >
> >> =46rom: ianfarrer=40gmx.com
> >> Subject: MI=46 API Design Team<= br>> >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> >> CC= : mikael.abraha= msson=40t-systems.com
> >> To: denghui02=40hotmail.com
> >>
>= >> Hi Hui,
> >>
> >> My apologies for not = being in contact sooner. Things don=E2=80=99t always move as
> >= > quickly as hoped around here=21
> >>
> >> Th= e current status is that we have provisionally obtained the necessary
= > >> resources to start working on a proof of concept implementa= tion of the MI=46
> >> architecture. We will be doing this in= partnership with a University.
> >>
> >> Tomorro= w (9th July) we will start the scoping work with the implementor.
>= >> What I want to come out of this work is a proof of concept impl= ementation of
> >> the MI=46 architecture on a =E2=80=98gener= ic=E2=80=99 Linux based platform. As Eric is working
> >> on = an Android implementation for the mobile use case, I think that this
&= gt; >> should complement his work quite well and serve to provide s= ome good
> >> implementation experience which can be fed back= into the update of the MI=46
> >> API document.
> >= >
> >> I=E2=80=99ve sent a subscription request to the MI=46= API design team mailing list.
> >> Once we=E2=80=99ve got so= me firmer details agreed with the implementors, I=E2=80=99ll make
>= >> an announcement on the m/l of what we=E2=80=99re doing and we c= an discuss what the
> >> best way of aligning the two impleme= ntation efforts.
> >>
> >> Best regards,
> = >> Ian
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Mpvdapi mailing list
 =20 =20 =20 =20

=20 =20

=20
=E9=99= =84=E4=BB=B6=EF=BC=9A
=20 =20 =20 =20 =20 =20 =20
=20
- draft-liu-mif-socket-api-00.txt=
=20
=20 =20 =20

=20 =20 =20 =20 =20

--559a2ed4_70a64e2a_1656-- From nobody Mon Jul 6 06:46:27 2015 Return-Path: X-Original-To: mpvdapi@ietfa.amsl.com Delivered-To: mpvdapi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5993B1A90B3 for ; Mon, 6 Jul 2015 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.498 X-Spam-Level: **** X-Spam-Status: No, score=4.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qjw3brMlKo4 for ; Mon, 6 Jul 2015 06:46:23 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3532D1A6EDE for ; Mon, 6 Jul 2015 06:46:23 -0700 (PDT) Received: by wgck11 with SMTP id k11so140879683wgc.0 for ; Mon, 06 Jul 2015 06:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+60Bpe/co+tDfru9j3wSDp4b777OjluMiOAw0bFoiok=; b=kpatt3xKcNHA0z0LRJZy6AtNGSlxYL6YixwpBBCHpFaAKazVbTGDmdJE57WaNYVRw0 qhK7St+b0h/9/GxC70OJEoxyI1659UGM+q8iPoob0GDzaItQWzGnM+WYwHH5czNohs7P f7iJ4zuqk66tF8e40n2sjklXc4wBynQAoyIgg27WUUCSS0dfSWEYWxmShkeJQFyKhb7O QspC9QI4rxXfbYPtJyPIQs/51mo54lGrMUbwTekw1NFNCC5LcUcQ7Nk7M5Vr8L76/Elu rQKj4CSI27scBaZeZ4Qy/osii6AMpiyQvxecnavY4dUMuZlKV6grmS10KDJf8rynKV7N IFQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+60Bpe/co+tDfru9j3wSDp4b777OjluMiOAw0bFoiok=; b=Pccr9UrR/OypbdNN731b45Qb9yslWSncI4deOD93+vOT+4UWUmt8HAPLZJWCaRjzWS WWVJDfc2gyJyQ5hxBMngW2kjGzH8DfiYICWLwtO4FJ34S3u6yWGujfAmJHnTVnu9ljVp zQtlV74E7MsVR4N1s+pEzsjTlwidQ+pTfiVJJfQUB6c+AlwoenjAqs1p22ipKwtjz/Mu LwhSQVdxabaN6gWjaT72LJyBf40nfhsdHHFT+K4Jrnw4amRjmwuargPzz6jYBaPMsbMz 0rrdkomh1X2PsV/SboxnyeEtTflbrM8Uk0ukoWpxWkZNKAf3revJ6HA+LRNbpvBy3nvm o2vQ== X-Gm-Message-State: ALoCoQnQJr3ZyAY3KYVXjuNqskIrJpoAl2TE1IS9YyVYhlgURexct1RXVMlIdPivmmvVLnjHMLQC X-Received: by 10.181.27.131 with SMTP id jg3mr87649379wid.89.1436190381871; Mon, 06 Jul 2015 06:46:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Mon, 6 Jul 2015 06:46:02 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Mon, 6 Jul 2015 22:46:02 +0900 Message-ID: To: Dapeng Liu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Margaret , Mikael Abrahamsson , Hui Deng , "mpvdapi@ietf.org" , Ian Farrer Subject: Re: [Mpvdapi] MIF API Design Team X-BeenThere: mpvdapi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:46:26 -0000 Alright, I'm not gonna make it by tomorrow morning (too many work issues). Dapeng's document explicitly describes a struct pvdinfo. I like it, but I fear it won't be extensible if we, for example, decide in the future that a Foo Protocol Server is an essential piece of configuration information. Did you get a chance to think about the pvd_handle_t idea? It means we might end up with an ioctl-like call, were you would write: getpvdinfo(pvd_handle_t, PVD_INFO_FOOSERVERS, (void*)&foo_struct) and portable code can test for the existence of PVD_INFO_FOOSERVERS. Not the prettiest though. :( Some of the things are not trivially represented, either. Consider how you would represent routes learned from various RIOs that make up the pvd configuration. On 6 July 2015 at 16:31, Dapeng Liu wrote: > =E5=9C=A8 2015=E5=B9=B47=E6=9C=886=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8C=E4=B8=8B=E5=8D=883:04=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC= =9A > > Hi Dapeng > > At this moment, we would expect that Erik could lead this MIF MPVD API > design tem, please try to contribute the design team work from your draft= . > thanks a lot for your cooperation > > > Hi Hui, > > Sure. > The draft is used used for the design team=E2=80=99s reference since it h= as some > similarity with what Eric proposed in the list. > > Thanks, > Dapeng Liu > > > Best regards, > > DENG Hui > > > ________________________________ > Date: Mon, 6 Jul 2015 14:25:12 +0800 > From: maxpassion@gmail.com > To: denghui02@hotmail.com > CC: ek@google.com; margaretw42@gmail.com; mikael.abrahamsson@t-systems.co= m; > mpvdapi@ietf.org; ianfarrer@gmx.com > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [Mpvdapi] MIF API Design Team > > The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-api= -00 > > -- > Dapeng Liu > > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=886:53=EF=BC=8CDapeng Liu =E5=86=99=E9=81=93=EF=BC= =9A > > Hi Hui and Erik, > > Attachment is the draft I mentioned during the discussion. It was written > before the Dallas meeting and it may not reflect the latest consensus we > have. > > I am trying to update it. > > > > -- > Dapeng Liu > > =E5=9C=A8 2015=E5=B9=B47=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5= =EF=BC=8C=E4=B8=8B=E5=8D=883:27=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC= =9A > > Hi Erik > > I guess that everbody is busy with deadline, > could you kindly help to write down a draft about this proposal and then > present it during coming MIF sesson, > then we get more people to review on how Android implement this. > > Thanks a lot for your kind work > Best regards, > > DENG Hui > > >> From: ek@google.com >> Date: Mon, 15 Jun 2015 19:55:15 +0900 >> Subject: Re: MIF API Design Team >> To: denghui02@hotmail.com >> CC: ianfarrer@gmx.com; mikael.abrahamsson@t-systems.com; mpvdapi@ietf.or= g >> >> Sorry about that: it's back to back 3GPP and now Android release issues. >> >> I spent the weekend reworking some notes on the things I described in >> Dallas. That's not coming together quickly enough so let me lay >> everything out here instead. In so doing I will try to describe more >> about the approach Android took to see if people even think it makes >> sense. >> >> Let's assume for the sake of argument that C API definitions are >> nicely isolated, maybe in some #include header file. >> >> [1] Provisioning domains are represented by a "handle" kind of class, >> android.net.Network: >> >> https://developer.android.com/reference/android/net/Network.html >> >> These are essentially handles to identify instances of attaches to >> provisioning domains. The underlying identifier values are not >> recycled (except after a really long time). Multiple temporally >> disparate attaches to the same network each get a new instance >> value--we have not yet found it of value to try to de-duplicate >> attaches. Applications that want to know if you're attached to >> "Starbucks" so they can startup and auto-sign-in use the relevant >> handle value to query parameters (like SSID). >> >> I would propose that a C API would have something like >> >> typedef uint64_t pvd_handle_t >> #define PVD_HANDLE_UNSPEC ((pvd_handle_t)0) >> >> [2] Once an application has received a Network handle [let's save how >> that happens for later] it can request that certain operations be >> performed specifically within the associated PVD. Currently these >> operations include: >> >> [bind a file descriptor to a PVD to force packets to be sent using >> the PVD's routing table] >> android.net.Network#bindSocket() >> >> https://developer.android.com/reference/android/net/Network.html#bindSoc= ket(java.net.Socket) >> >> [perform DNS lookups using a PVD's DNS servers] >> android.net.Network#getAllByName() >> >> https://developer.android.com/reference/android/net/Network.html#getAllB= yName(java.lang.String) >> >> [set the PVD for all file descriptors and DNS lookups for a >> process, unless otherwise overridden] >> android.net.ConnectivityManager#setProcessDefaultNetwork() >> >> https://developer.android.com/reference/android/net/ConnectivityManager.= html#setProcessDefaultNetwork(android.net.Network) >> >> I would propose that a C API have at least the following: >> >> [a] get/setsockopt(int fd, SOL_SOCKET, SO_PVD_HANDLE, &pvd_handle_t); >> [b] getaddrinfo/getnameinfo some taking a pvd_handle_t >> [c] discussion of recvmsg/sendmsg/accept semantics >> >> Note that the last is particularly tricky. Operating systems need to >> know how to "mark" incoming packets that would cause a new connection >> such that they have the correct pvd_handle_t associated. This has >> lots of impact on suitable address selection as well. >> >> The C API should also have at least the following: >> >> [d] system, process, and per-thread pvd_handle get/set calls >> >> // These values are used by PVD-aware function calls when a PVD index >> // is not explicitly specified. >> pvd_handle_t pvd_system_default(); >> >> // Same as above, but operates at a per-process level. If no >> // process-specific default has been set this MUST return the value >> // of a call to pvd_system_default(). >> pvd_handle_t pvd_process_default(); >> >> // Same as above, but operates at a per-thread level. If no >> // thread-specific default has been set this MUST return the value >> // of a call to pvd_current_process_default(). >> pvd_handle_t pvd_thread_default(); >> >> int pvd_set_system_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> int pvd_set_process_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> int pvd_set_thread_default(pvd_handle_t); // 0 or -1 && errno =3D EFOO >> >> [e] good discussion of a variety of EFOO errno return values. >> >> When a PVD has gone away (e.g. we disconnected from WIFI), subsequent >> operations on the associated pvd_handle should fail with errno =3D >> ENONET. >> >> [f] good discussion of how the process and thread default values >> behave across fork/exec >> >> FWIW, Android uses all of the above when NetworkMonitor is validating >> a network--it does DNS lookups within the PVD, makes pvd-bound sockets >> used for HTTP Direct or Proxy connections to check connectivity to a >> URL: >> >> >> https://android.googlesource.com/platform/frameworks/base/+/master/servi= ces/core/java/com/android/server/connectivity/NetworkMonitor.java >> >> [3] the device has to build up configuration data continuously over >> time, as DHCP results come back, and RAs come in bringing new prefixes >> or new DNS servers. >> >> Not that it's relevant, but Android accumulates these in an >> android.net.LinkProperties object: >> >> https://developer.android.com/reference/android/net/LinkProperties.html >> >> as we currently only support a 1:1 mapping of PVDs to physical interface= s. >> >> The means by which the operating system allocates pvd_handles, gathers >> this data and associates it with a pvd_handle (including marking >> incoming packets that would causes a new connection) might best be >> left for a separate document, since sections 1 and 2 and background >> theory will require a fair amount of text. >> >> [4] Android lets processes register callbacks to be called when >> certain network properties change, or when a new network shows up, or >> one goes away. This is how applications receive the handles (Network >> objects). >> >> The UNIX way of doing these sorts of things...well, frequently leaves >> much to be desired...but we should support multiple event-driven >> models, I think. >> >> [5] we'll want an API for an application to pass in a handle and get >> an ever expanding list of parameters (expanding as we think to add >> them and write documents about them). >> >> The Android ConnectivityManager mitigates all this stuff and passes >> around NetworkInfo objects which encapsulate extra information like >> SSIDs, whether the Network is Ethernet, Mobile, Wi-Fi, or whether it's >> metered, and so on. >> >> The closest UNIX-style analogy here would be some interface that is >> getsockopt()-like, I think. Something like: >> >> int pvd_get_attribute(pvd_handle_t, PVD_ATTR_(HWTYPE|METERED|...), >> void *returned_blob); >> >> And then it will be possible for code to be written like >> >> #ifdef PVD_ATTR_HTTP_PROXY_URL >> >> char proxyString[PVD_ATTR_HTTP_PROXY_URL_MAXLEN]; >> memset(proxyString, 0, sizeof(proxyString)); >> if (!pvg_get_attribute(pvd_handle, PVD_ATTR_HTTP_PROXY_URL, proxyString)= ) >> { >> perror("Sadness!"); >> return -1; >> } >> >> #endif >> >> >> --- >> >> That's a massive brain dump, and I apologize for it and also that it's s= o >> late. >> >> Let me know what y'all think. >> -Erik >> >> On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng wrote: >> > Hi Erik >> > >> > We are waiting for your lead to start this work asap. Feel free to us >> > know >> > when you are ready. >> > >> > Hi Ian, thanks a lot for letting us know that you are going to work wi= th >> > a >> > university on the implementations. >> > Erik was quite busy for 3GPP SA2 work recently, we are waiting for his >> > return to lead the work. >> > >> > Best regards, >> > >> > DENG Hui >> > >> > >> >> From: ianfarrer@gmx.com >> >> Subject: MIF API Design Team >> >> Date: Mon, 8 Jun 2015 14:07:02 +0200 >> >> CC: mikael.abrahamsson@t-systems.com >> >> To: denghui02@hotmail.com >> >> >> >> Hi Hui, >> >> >> >> My apologies for not being in contact sooner. Things don=E2=80=99t al= ways move >> >> as >> >> quickly as hoped around here! >> >> >> >> The current status is that we have provisionally obtained the necessa= ry >> >> resources to start working on a proof of concept implementation of th= e >> >> MIF >> >> architecture. We will be doing this in partnership with a University. >> >> >> >> Tomorrow (9th July) we will start the scoping work with the >> >> implementor. >> >> What I want to come out of this work is a proof of concept >> >> implementation of >> >> the MIF architecture on a =E2=80=98generic=E2=80=99 Linux based platf= orm. As Eric is >> >> working >> >> on an Android implementation for the mobile use case, I think that th= is >> >> should complement his work quite well and serve to provide some good >> >> implementation experience which can be fed back into the update of th= e >> >> MIF >> >> API document. >> >> >> >> I=E2=80=99ve sent a subscription request to the MIF API design team m= ailing >> >> list. >> >> Once we=E2=80=99ve got some firmer details agreed with the implemento= rs, I=E2=80=99ll >> >> make >> >> an announcement on the m/l of what we=E2=80=99re doing and we can dis= cuss what >> >> the >> >> best way of aligning the two implementation efforts. >> >> >> >> Best regards, >> >> Ian > _______________________________________________ > Mpvdapi mailing list > Mpvdapi@ietf.org > https://www.ietf.org/mailman/listinfo/mpvdapi > > > > =E9=99=84=E4=BB=B6=EF=BC=9A > - draft-liu-mif-socket-api-00.txt > > >