From nobody Mon Oct 1 03:01:08 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4985B130DDE for ; Mon, 1 Oct 2018 03:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xhOqLtW2K1lg for ; Mon, 1 Oct 2018 03:01:03 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1809130DEE for ; Mon, 1 Oct 2018 03:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AA105103AAD; Mon, 1 Oct 2018 12:01:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSrsZb0QiJ9Z; Mon, 1 Oct 2018 12:01:00 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 788EDFFCD7; Mon, 1 Oct 2018 12:00:56 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.168]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Mon, 1 Oct 2018 12:00:56 +0200 From: Marco Liebsch To: John Kaippallimalil , "dmm@ietf.org" Thread-Topic: extended data plane discussion - N6 traffic steering Thread-Index: AdRRGRnBtxPDxfwaSnKL4ooJUaTbgwGIoG1AAIubaLA= Date: Mon, 1 Oct 2018 10:00:55 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DE58147F0@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26DE580AA88@PALLENE.office.hd> <6561EABF52675C45BCDACA1B4D7AA1171F9DB92D@sjceml521-mbx.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171F9DB92D@sjceml521-mbx.china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26DE58147F0PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] extended data plane discussion - N6 traffic steering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 10:01:07 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DE58147F0PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, thanks for the feedback. Please see inline [ml]. From: John Kaippallimalil [mailto:John.Kaippallimalil@huawei.com] Sent: Freitag, 28. September 2018 21:59 To: Marco Liebsch; dmm@ietf.org Subject: RE: extended data plane discussion - N6 traffic steering Hi, Marco, N6 aspects are generally underspecified in 3GPP - as it is an interface to= an external data network (IP network) but sometimes have specific route an= d QoS requirements. Descriptions in a draft like this can help to clarify aspects that are not = well specified for a local N6 interface. [ml] yes, we thought the same. This was a quick read - assuming that the focus is on local network N6, the= discussion in section 4 about traffic treatment looks good. The abstract does confuse me a bit. It goes over GTP-U and other motivation= around anchoring, etc. - N3, N9 (interfaces inside 5G system). While the focus of the draft (section 4) seems to be about N6. [ml] Ok, this document mainly addresses IETF folks so far and the abstract = tries to position this draft within in a set of other drafts of the data plane discussion. Most drafts discuss the mobile d= ata plane on N9 and N3 and the use of protocol candidates as alternative to the GTP overlay This draft complemen= ts the data plane discussion by including N6. Having the possibility to apply policies to N6 traffic tre= atment enables very interesting use cases as all data plane segments from an application server's network t= o the UE is covered. However, the abstract may be adjusted to be more focusses in future revisions. That's do be discu= ssed. Some more specific comments: 1. in section 3.2 - the UE to edge data network use case is clear, i.e= ., the need for traffic steering policy (along with description in section = 4) However, use case UE to UE communication is not clear. If this is about opt= imal routing between 2 UEs in a 3GPP network, that would be in the scope of= 3GPP. If it is UEs in 2 PLMNs, the solution would need much more than just traffi= c steering. [ml] I see and agree that UE-to-UE seems to be a bit off-topic. It's more t= o be complete and to cover the UE-to-service as well as the UE-to-UE communication as it's addressed in draft-gundavelli-dmm-mfa-01. Dependent on the= use cases for UE-to-UE communication, N6 policies are needed. 3GPP has an interface in scope, which can be used, = this is N4. Maybe only the semantics need to be extended in support of the target use case. Key aspect of draft-fattore is to cover a policy co= ntrol interface to the data network, which holds the DPN/AS for N6 policing. Ad such interface is not covered in 3GPP- 2. Local data network/N6 issues around asymmetric return route are no= t discussed in the draft. In 5G, UE flows to edge network AS can bypass UPF-PSA (IP anchor) as a resu= lt of an intermediate UPF routing directly to a local UPF-PSA (not IP ancho= r) using flow filters. This can result in asymmetric paths - where the return path is still via th= e IP address anchor UPF-PSA. Note that this is different from N6 next to UPF-PSA that is an IP anchor (F= igures 3 & 4 and the descriptions do not cover this) [ml] well, it's covered but maybe we need to spend a few more sentences to = make it more obvious. So far we write that downlink traffic should traverse the most suitable UPF_a in case of multiple choices. More t= ext could describe that asymmetric routing can be avoided by solutions in this draft. Asymmetry here is uplink to a local data networ= k traverses UPF_i/UPF_a2, whereas downlink traffic from the local data network traverses UPF_a1. This is what you mean, correct? 2. Section 5 /only includes control plane aspects and binding between = 3GPP and N6 control plane (AF ->DPN) There would probably be some specification for the user plane as well. For = example - the N6 user plane is probably an IP tunnel between local UPF-PSA = and AS? And what if there is a load balancer that removes the tunnel before selecti= ng the AS instance. The return path would not work as expected (i.e., asymm= etric path). Should there be requirements to LB - to retain the outer source IP address?= Or some explicit header (like NSH) for the AS to route return packet to lo= cal UPF (not the anchor). [ml] So far we thought about keeping the protocol out of N6 for traffic ste= ering, which can be ILA or SRv6, or any encap protocol. For us it's just a question of traffic treatment policies. Any of them allows us to ach= ieve the flexibility we want. Important is 'how' and 'when' policies can be enforced on data networks' DPN/AS. But we can include a pro= tocol example as well, no problem. 4. Motivation and introduction sections have a lot of references that= are perhaps not needed in the context of the N6 focus of this draft. I would be willing to clarify further and help with details of the draft. [ml] sounds good. Thanks, John. I hope we can schedule a few side meetings = in Bangkok. To elaborate on some more details. Best regards, marco BR, John From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Thursday, September 20, 2018 2:37 PM To: dmm@ietf.org Subject: [DMM] extended data plane discussion - N6 traffic steering Folks, we submitted a new ID which extends the current data plane discussion from = N9/N3 to N6 interfaces of the mobile system's architecture. We could discuss the use cases, problem statement and principles with some = before submission, but post this initial draft to get the larger community's feedback before we up= date with more details and the received feedback. Your comments are appreciated. Best regards, marco Name: draft-fattore-dmm-n6-cpdp-trafficsteering Revision: 00 Title: Control-/Data Plane Aspects for N6 Traffic Steeri= ng Document date: 2018-09-20 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-c= pdp-trafficsteering-00.txt Status: https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-= trafficsteering/ Htmlized: https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-traff= icsteering-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-= cpdp-trafficsteering Abstract: Current standardization effort on the evolution of the mobile communication system reconsiders the mobile data plane protocol. The IETF DMM Working Group has work that proposes and analyzes various protocols as alternative to the GPRS Tunneling Protocol for User Plane (GTP-U) for an overlay deployment in between the mobile device's assigned data plane anchor and its current radio base station, which are denoted as N9 and N3 interfaces. In the view of some future deployment and the original intent per the very early DMM WG charter, a mobile device's data plane anchor may be highly distributed and re-selected for optimization throughout a mobile device's communication with one or more correspondent services. Such re-configuration has impact on the packet routing in between the mobile device's data plane anchor and the one or multiple data networks hosting the services, which is denoted as N6 interface. This draft proposes and discusses a solution to control, setup and maintain traffic treatment policy on the cellular communication system's N6 interface while taking the UE's PDU session settings per the cellular system's control plane, such as QoS and locator information, into account. --_000_69756203DDDDE64E987BC4F70B71A26DE58147F0PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John= ,

thanks for the feedback. Please see inline [ml].

&n= bsp;

&n= bsp;

From: John Kaippallimalil [mailto:John.Kaippallimalil@huawe= i.com]
Sent: Freitag, 28. September 2018 21:59
To: Marco Liebsch; dmm@ietf.org
Subject: RE: extended data plane discussion - N6 traffic steering

 

Hi, Mar= co,

N6 &nbs= p;aspects are generally underspecified in 3GPP – as it is an interfac= e to an external data network (IP network) but sometimes have specific rout= e and QoS requirements.

Descrip= tions in a draft like this can help to clarify aspects that are not well sp= ecified for a local  N6 interface.

&n= bsp;

[ml] ye= s, we thought the same.

&n= bsp;

This wa= s a quick read – assuming that the focus is on local network N6, the = discussion in section 4 about traffic treatment  looks good.

The abs= tract does confuse me a bit. It goes over GTP-U and other motivation around= anchoring, etc. - N3, N9 (interfaces inside 5G system).<= /p>

While t= he focus of the draft (section 4) seems to be about N6.

&n= bsp;

[ml] Ok= , this document mainly addresses IETF folks so far and the abstract tries t= o position this draft within in a set of

other d= rafts of the data plane discussion. Most drafts discuss the mobile data pla= ne on N9 and N3 and the use of
protocol candidates as alternative to the GTP overlay  This draft comp= lements the data plane discussion
by including N6. Having the possibility to apply policies to N6 traffic tre= atment enables very interesting
use cases as all data plane segments from an application server’s net= work to the UE is covered. However, the abstract
may be adjusted to be more focusses in future revisions. That’s do be= discussed.

&n= bsp;

Some mo= re specific comments:

= 1.      in section 3.2 – the UE to edge data network use case is clear, i.e.= , the need for traffic steering policy (along with description in section 4= )
However, use case UE to UE communication is not clear. If this is about opt= imal routing between 2 UEs in a 3GPP network, that would be in the scope of= 3GPP.
If it is UEs in 2 PLMNs, the solution would need much more than just traffi= c steering.

&n= bsp;

[ml] I = see and agree that UE-to-UE seems to be a bit off-topic. It’s more to= be complete and to cover the UE-to-service as well as the
UE-to-UE communication as it’s addressed in d= raft-gundavelli-dmm-mfa-01.  Dependent on the use cases for UE-to-UE= communication,
N6 policies are needed. 3GPP has an interface in scope, which can be used, = this is N4. Maybe only the semantics need to be extended in support
of the target use case. Key aspect of draft-fattore is to cover a policy control interface = to the data network, which holds the DPN/AS for
N6 policing. Ad such interface is not covered in 3GPP-

&n= bsp;

2.       Local data network/N6 i= ssues around asymmetric return route are not discussed in the draft.
In 5G, UE flows to edge network AS can bypass UPF-PSA (IP anchor) as a resu= lt of an intermediate UPF routing directly to a local UPF-PSA (not IP ancho= r) using flow filters.

= This can result in asymmetric paths - where the return path is still via th= e IP address anchor UPF-PSA.
Note that this is different from N6 next to UPF-PSA that is an IP anchor (F= igures 3 & 4 and the descriptions do not cover this)<= /p>

 

[ml] well, it’s covered but maybe we need t= o spend a few more sentences to make it more obvious. So far we write that = downlink traffic
should traverse the most suitable UPF_a in case of multiple choices. More t= ext could describe that asymmetric routing can be avoided
by solutions in this draft. Asymmetry here is uplink to a local data networ= k traverses UPF_i/UPF_a2, whereas downlink traffic from the local
data network traverses UPF_a1. This is what you mean, correct?

 

= 2.      Section 5 /only includes control plane aspects and binding between 3GPP an= d N6 control plane (AF ->DPN)
There would probably be some specification for the user plane as well. For = example – the N6 user plane is probably an IP tunnel between local UP= F-PSA and AS?
And what if there is a load balancer that removes the tunnel before selecti= ng the AS instance. The return path would not work as expected (i.e., asymm= etric path).
Should there be requirements to LB – to retain the outer source IP ad= dress? Or some explicit header (like NSH) for the AS to route return packet= to local UPF (not the anchor).

&n= bsp;

[ml] So= far we thought about keeping the protocol out of N6 for traffic steering, = which can be ILA or SRv6, or any encap protocol. For us it’s
just a question of traffic treatment policies. Any of them allows us to ach= ieve the flexibility we want. Important is ‘how’ and ‘whe= n’
policies can be enforced on data networks’ DPN/AS. But we can include= a protocol example as well, no problem.

&n= bsp;

4.       Motivation and introduc= tion sections have a lot of references that are perhaps not needed in the c= ontext of the N6 focus of this draft.

&n= bsp;

I would= be willing to clarify further and help with details of the draft.

&n= bsp;

[ml] so= unds good. Thanks, John. I hope we can schedule a few side meetings in Bang= kok. To elaborate on some more details.

&n= bsp;

Best re= gards,

marco

&n= bsp;

BR,

John

 

&n= bsp;

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Thursday, September 20, 2018 2:37 PM
To: dmm@ietf.org
Subject: [DMM] extended data plane discussion - N6 traffic steering<= o:p>

 

Folks,

we submitted a new ID which extends the current data plane discussion from = N9/N3 to N6 interfaces
of the mobile system’s architecture.

 

We could discuss the use cases,= problem statement and principles with some before submission, but
post this initial draft to get the larger community’s feedback before= we update with more details and the
received feedback.

 

Your comments are appreciated.<= o:p>

 

Best regards,=

marco

 

 

Name:    = ;             d= raft-fattore-dmm-n6-cpdp-trafficsteering

Revision:   &= nbsp;         00<= /p>

Title:   &nbs= p;            &= nbsp;   Control-/Data Plane Aspects for N6 Traffic Steering<= /o:p>

Document date:  &n= bsp;            2018= -09-20

Group:   &nbs= p;             = Individual Submission

Pages:   &nbs= p;            &= nbsp; 12

URL:    =         https://www.ietf.org/internet-drafts/draft-fattore-dmm-n= 6-cpdp-trafficsteering-00.txt

Status:   &nb= sp;     https:= //datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/

Htmlized:   &= nbsp;   https://tools.ietf.= org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00

Htmlized:   &= nbsp;   https://data= tracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering<= /a>

 

 

Abstract:<= /p>

   Current standar= dization effort on the evolution of the mobile

   communication s= ystem reconsiders the mobile data plane protocol.  The

   IETF DMM Workin= g Group has work that proposes and analyzes various

   protocols as al= ternative to the GPRS Tunneling Protocol for User

   Plane (GTP-U) f= or an overlay deployment in between the mobile

   device's assign= ed data plane anchor and its current radio base

   station, which = are denoted as N9 and N3 interfaces.  In the view of=

   some future dep= loyment and the original intent per the very early DMM

   WG charter, a m= obile device's data plane anchor may be highly

   distributed and= re-selected for optimization throughout a mobile

   device's commun= ication with one or more correspondent services.  Such

   re-configuratio= n has impact on the packet routing in between the

   mobile device's= data plane anchor and the one or multiple data

   networks hostin= g the services, which is denoted as N6 interface.

   This draft prop= oses and discusses a solution to control, setup and

   maintain traffi= c treatment policy on the cellular communication

   system's N6 int= erface while taking the UE's PDU session settings per

   the cellular sy= stem's control plane, such as QoS and locator

   informat= ion, into account.

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26DE58147F0PALLENEofficehd_-- From nobody Mon Oct 1 04:22:30 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F41130E5C for ; Mon, 1 Oct 2018 04:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4wq6H2FNxwP4 for ; Mon, 1 Oct 2018 04:22:24 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B91120072 for ; Mon, 1 Oct 2018 04:22:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w91BMLOl023491 for ; Mon, 1 Oct 2018 13:22:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8B78D2059AF for ; Mon, 1 Oct 2018 13:22:21 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F91A200EB4 for ; Mon, 1 Oct 2018 13:22:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w91BMLCn004086 for ; Mon, 1 Oct 2018 13:22:21 +0200 To: dmm@ietf.org References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> From: Alexandre Petrescu Message-ID: <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> Date: Mon, 1 Oct 2018 13:22:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:22:29 -0000 Le 01/10/2018 à 05:50, Shunsuke Homma a écrit : > Hi all, > # Sorry for my late response... > > Thank you for your lively discussion. It is very helpful for > understanding points which need supplemental explanation and more > consideration. > > Following the discussion, we're planning to update the I-D for covering > the points below: > > - termination points of GTP-U >   (RANs and UPFs terminate GTP-U in 5GS.) What is UPF? I understand UPF stands for User-Plane Function. Is my smartphone supposed to implement UPF? Alex > - setting QoS parameter of outer IP header >   (Note that it's not just copy of inner to outer.) > - problems related to IP connectivity (e.g., MTU in IPv6 networks, IPv4 > address duplication) > - summary of network slicing in 5GS >   (E.g., "slice is composed of SMF and UPFs. AMF selects SMF depending > on NSSAI sent from UE, and SMF indicates to the UE the UPF that it is > allocated.") > - case studies on UPF selection >   (E.g., parameters used for deciding destination UPF) > # Optimizing forwarding paths solution might be realized with UPF > selection mechanism in 3GPP architecture. (ID-LOC may be applied as such > mechanism.) > > > If you have any request for us on this updating, please let us know. > > Best regards, > > Shunsuke > > On 2018/09/08 3:28, Dino Farinacci wrote: >>> I understand your point, but there is no guarantee for a precise QoS >>> without using some sort of encapsulation being it GTP, RSVP, etc. >>> Even with tunnels, there is no guarantee that all nodes along the >>> path have the same hardware capability and can provide the same QoS >>> treatment. >> >> There is existing hardware where the encapsulator copies inner QoS to >> outer QoS. All routers along the path just process the outer QoS, no >> changes to or new processing requirements for them. >> >>> For example, the code points in routers need to be configured to >>> correctly handle the EXP bits in MPLS labels. But there is no >>> guarantee that all routers can support all values. The EXP values get >>> mapped to code points but the mapping is not always one to one. >>> 3-bit EXPs can map to 4 code points on those routers with less >>> capable H/W. >> >> That is a completely different matter. The discussion is about >> remarking. And if one remarks to what the path cannot support, well >> things don’t work as expected. >> >>> Slicing is almost the same. It allows user traffic to be mapped to >>> what the operator provides. >>> I agree with you that network should not touch/change original header >>> bits. GTP or any other encapsulation easily allow for this. The >>> question is whether we can provide for this without using >>> encapsulation. IPv6 might be the answer. But as Tom pointed out, flow >>> labels can still change in the middle. Is there any room for >>> improvement. SIDs might present an opportunity. >> >> Not if they are encapsulated and routers don’t touch packets inside. >> >> Dino >> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: 07 September 2018 13:08 >>>> To: Arashmid Akhavain >>>> Cc: Tom Herbert ; ta-miyasaka@kddi-research.jp; >>>> dmm >>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>> >>>> I think you’ll still have the PHB re-marking issues I mentioned in >>>> previous >>>> emails. The question is, should the network touch/change any header >>>> bits of >>>> the packet the source has built. The answer should probably be no. >>>> >>>> Having said that, GTP did it the right way, even though it cost in >>>> header >>>> length. >>>> >>>> Dino >>>> >>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain >>>> wrote: >>>>> >>>>> Correct, flow labels can change along the path. That's why I like >>>>> the slicing >>>> concept. >>>>> UEs can request services with different attributes, operators >>>>> control how >>>> service request are mapped into slices. I should look into the air >>>> side of the >>>> business and see what happens there. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Tom Herbert [mailto:tom@quantonium.net] >>>>>> Sent: 07 September 2018 11:13 >>>>>> To: Arashmid Akhavain >>>>>> Cc: Dino Farinacci ; >>>>>> ta-miyasaka@kddi-research.jp; dmm >>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>>>> >>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Sent: 06 September 2018 18:59 >>>>>>>> To: Arashmid Akhavain >>>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi- >>>> research.jp; >>>>>>>> dmm >>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis- >>>> 01 >>>>>>>> >>>>>>>>> Dino brought up a good point. Here is my two cents worth: >>>>>>>> >>>>>>>> Not sure which point. >>>>>>>> >>>>>>>>> As it was explained by Sridhar,  each UE can have multiple >>>>>>>>> contexts. For >>>>>>>> example, today some operators provide Data and VoLTE service to >>>>>>>> their customers. These two services are represented by separate GTP >>>>>>>> tunnels in the core with each tunnel tied up to a particular QoS. >>>>>>>>> >>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it >>>>>>>>> couldn't uniquely identify multiple UE >>>>>>>> >>>>>>>> There is no reason why it shouldn’t. And IPv6, for this use-case >>>>>>>> doesn’t add anything new other than a 28 bit >>>>>>>> traffic-class/flow-label that can provide more bits for “new >>>> functionality”. >>>>>>> >>>>>>> >>>>>>> [Arashmid]  And that's what I meant. Having a flow label is handy. >>>>>>> We can perhaps use it to identify different UE sessions. >>>>>>> >>>>>> Careful if you use the flow label to identify flows. It should be >>>>>> considered "soft identification" since it might not always be correct >>>>>> (it can be changed en route, isn't protected by any checksum, anyone >>>>>> can set it however they want, etc.). It's useful for things like ECMP >>>>>> that don't require 100% accuracy in identifying flow. The flow label >>>>>> was briefly considered for holding VNIs in network virtualization, >>>>>> but we >>>> talked them out of that. >>>>>> >>>>>> Tom >>>>>> >>>>>>>> >>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I agree >>>>>>>>> with >>>>>>>> Dino that IPv6 is much more versatile and is definitely worth >>>>>>>> looking at as an alternative. >>>>>>>> >>>>>>>> That is not what I said. I said “IP could have solved this >>>>>>>> problem”. And >>>> “IP” >>>>>>>> means either IPv4 or IPv6, or both at the same time. >>>>>>> >>>>>>> >>>>>>> [Arashmid] >>>>>>> How would we employ IPv4 to distinguish between different UE >>>>>>> sessions. >>>>>> TOS? >>>>>>> Or you mean using encapsulation? >>>>>>> >>>>>>>> >>>>>>>>> A factor worth considering though is that the use of GTP and TEID >>>>>>>>> in mobile >>>>>>>> core allows operators to deal with QoS on their own terms. The >>>>>>>> tunnels with specific operator-controlled QoS are established by >>>>>>>> the control plane between eNB, SGW, and PGW. UEs or applications >>>>>>>> sitting in the UEs have no say in this. Well at least till the >>>>>>>> packet exits operator's >>>>>> network. >>>>>>>> >>>>>>>> The problem with one header, is that if you re-mark (known as PHB >>>>>>>> markign in the ole days) you lose the original value. Encapsulation >>>>>>>> is useful here because you can map the inner to outer and anywhere >>>>>>>> along the path you can PHB remark on the outer header. And then the >>>>>>>> destination can see the orignal source’s ToS/QoS/TC/flow-label >>>> whatever. >>>>>>> >>>>>>> >>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. >>>>>>> Encapsulation certainly makes things easier and the inner to outer >>>>>>> mapping trick has been widely used in IP and MPLS(multiple labels >>>>>>> like service and transport) >>>>>>> >>>>>>>> >>>>>>>>> Using the information in UE's IP packet header can jeopardise the >>>>>>>>> above tight QoS control. I think going >>>>>>>> >>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly retain >>>>>>>> the original flow-label if the SID can retain those bits before >>>>>>>> overwriting the destination address from the option’s value. >>>>>>> >>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why GTP >>>>>>> has worked well and served the purpos in the mobile back-haul so >>>>>>> far. >>>>>>> >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>>> down this path, operators need proof that they will be still in >>>>>>>>> the driving >>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any >>>>>>>> application running in it. >>>>>>>>> >>>>>>>>> Now, here is an interesting question for the operators. Would any >>>>>>>>> operator >>>>>>>> be interested in allowing QoS  to be set by the UE or by >>>>>>>> applications running in the UE and charged for by the network? >>>>>>>> "Yes" could potentially imply impacts on the air interface, UE >>>>>>>> resource block allocation and can make scheduling on the RAN side >>>> much more complex. >>>>>>>>> >>>>>>>>> Arashmid >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino >>>>>>>>>> Farinacci >>>>>>>>>> Sent: 06 September 2018 12:45 >>>>>>>>>> To: Tom Herbert >>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; dmm >>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- >>>> analysis- >>>>>> 01 >>>>>>>>>> >>>>>>>>>>> Behcet, >>>>>>>>>>> >>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a >>>>>>>>>>> locator easily enough. >>>>>>>>>>> >>>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. >>>>>>>>>> >>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, that >>>>>>>>>> could have been the UE’s IP address. And with IPv6 it can be >>>>>>>>>> unique and not the issue that Sridhar brought up. >>>>>>>>>> >>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. >>>>>>>>>> >>>>>>>>>> Dino >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dmm mailing list >>>>>>>>>> dmm@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > > From nobody Mon Oct 1 04:33:14 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13000130E5F for ; Mon, 1 Oct 2018 04:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=lkZr+r+g; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=wiyLTgo0 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 31op7_46UPcb for ; Mon, 1 Oct 2018 04:33:08 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A35F130E60 for ; Mon, 1 Oct 2018 04:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1538393587; x=1569929587; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=A2upy/zidlEEMUfIWL7Q0AEFXfgNzwMuf8KgglSONSI=; b=lkZr+r+g9wD8niHKfHlymRnNPvoRHHbw1yUgPIl6R0Y1HxPDcM16dmeF T4BqhOn9rCnh3k1+jz6bSltQjo7fIMKOaLqpfM68r+lbvkf0OPdZz45Dm xN7usxzXbzEV3Ck3ouZHmk4Agz8umFofMebXZ7nunFF8tfZjSKUgvR12Q WB4tMirohO18U+QW2W9xNrcyPEOT6EYHDCJAwIyTWNxsiHJ7xdiE5RzV8 YkQaMCiaS/NO3mdi7VLQ+fqoJnm8Wq6PbBluBNzy3Oxriwnc6ex+N2F36 hBS1dfvbTchoixlm0m7FWGBPU/2z94RqCBXKvuq0u5quxZbfC0zryeZCu Q==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 13:33:02 +0200 X-IronPort-AV: E=Sophos;i="5.54,327,1534802400"; d="scan'208";a="134352921" Received: from he105689.emea1.cds.t-internal.com ([10.169.119.67]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 01 Oct 2018 13:33:01 +0200 Received: from HE105690.EMEA1.cds.t-internal.com (10.169.119.68) by HE105689.emea1.cds.t-internal.com (10.169.119.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 13:33:00 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE105690.EMEA1.cds.t-internal.com (10.169.119.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 1 Oct 2018 13:33:00 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.23) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 1 Oct 2018 13:30:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A2upy/zidlEEMUfIWL7Q0AEFXfgNzwMuf8KgglSONSI=; b=wiyLTgo0w5smOxRm1Tjs6rqm1B4QMYuGADUMlgoSv3Fe1EYBAvH43Q+L46sm0oWcycCArQa8CUzttJjOlvj1n11O6XMs4xHi9x9ak7fLRUrjLKNsz9W1C1OmlrZcAvsn4fXztKREZ4DseUIkqE5N4/TyNy6GJoJeXqeOgXXcbao= Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) by FRAPR01MB0804.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.23; Mon, 1 Oct 2018 11:32:59 +0000 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::f9db:3735:9a47:49bc]) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::f9db:3735:9a47:49bc%5]) with mapi id 15.20.1185.024; Mon, 1 Oct 2018 11:32:59 +0000 From: To: , Thread-Topic: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 Thread-Index: AQHURG5UVXWcpFDayESNaEiNoemAyaThY56AgAB7JQCAAS/agIAAWF4AgAAKk4CAAAEIAIAABlAAgABVNICAABN+gIABDMYAgAADM4CAAAP9gIAAHGCAgAAKNwCAAAw5gIAkwpAAgAB+PgCAAAFEUA== Date: Mon, 1 Oct 2018 11:32:59 +0000 Message-ID: References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> In-Reply-To: <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0804; 6:dZi7/bhpTYY6Q9VN8cU/9XQ3Sf4Q2YhhrpzaaGZ0pz5sLz+elbZmAkDHPTmCo5xbxhYX4eejENWjBp1pWVen1DFMoVijwApFsz2jpz3HtGze27NCLTyEbidQ+VDUyGPm9ZZ7uX4htqe8FDJO32Q0jHDQ+wc5+LYgBKkcIRu0MN4Koj9ZjxMzB3RytZHUMHwmIjpKYQV/e3zdxFBD2z1bzmpkpTFGkos7Vfb7o5kTyixhirkeHIEvltqQm7s2SbotBIwCAVCvc36MiafqrbTZWDgzO9Q8vqqaUUxp/LlL3gHGrACgLEDlyMm/WUc95qmxQrjzweMyynvaw723vxrSj9jeK1CSlbrEZAcM1wnHqkoW3rmZcQGi14pJ1ArloFQw7vlvit7sQ9s/8rdxSf5xAMwP35BI947Bi1BT1EJsF2lURPrUt7CEyZY8hWz24iV6Jv/LTTvrZk8BQpiqgmskyA==; 5:9PDhhFW7hgHYpoSPnAdHso5PSgW1MtXWGiRgU352/6sK3qD6M6nglYRKUC1ZW1UJ1z1LTACXjpyuTpCN/VJoywYfDxDVTIT11sUR95v2R4eiZr3TK6IO4EV435Eq8XQV3DTBCfxGDUNDhQPeXXpZPJQGn+rzR7dRstWM6oQSTR4=; 7:uNXyYvivrhi1K8Lenjr25FccFBvXvqS8VSDW6oG5jC7FFAdw6n9c6GuFXvSK158BehoZE/6dV+aiCU/e3koahoSFwMsqeKZGJl7sdbMSY9nIVIVdBx/bgYhOOpQpyXDEGeUCwL9lmlY24P6amSkIuhB8QoYx0Qbj9QcqRMlBAE5j8KfJ460s+8t3eMKudE2a3H0+/MlxvAizRSNovvJmdJupzRbnfQq05gtoaIRwkYH3vEwWceSNq5CbSbuRL/Ey x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a4c2455e-7879-4a84-e740-08d62791a402 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0804; x-ms-traffictypediagnostic: FRAPR01MB0804: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(278428928389397)(50582790962513); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:FRAPR01MB0804; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0804; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(136003)(346002)(39860400002)(199004)(189003)(37854004)(53754006)(13464003)(2501003)(68736007)(97736004)(2900100001)(5660300001)(72206003)(8676002)(966005)(8936002)(305945005)(7736002)(66066001)(478600001)(14454004)(81166006)(81156014)(345774005)(33656002)(55016002)(3846002)(2906002)(53936002)(229853002)(446003)(9686003)(486006)(476003)(6306002)(186003)(105586002)(106356001)(102836004)(39060400002)(11346002)(53546011)(14444005)(256004)(75402003)(86362001)(34290500001)(71200400001)(71190400001)(316002)(6246003)(6116002)(5250100002)(76176011)(110136005)(7696005)(74482002)(26005)(52396003)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0804; H:FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: 33aEGFHFOAVaGWsccA629Q0ouuS/8UN5PXDgZbqVVw1gUBNH9e4LI5La+IBnrkaex2NsC0VbPIiodkR4ERgCU3eTqvsc80JQDRbMEV9amv4dpjBj011Plg1oxab4J71wKVHBl9F4RbkQ1cdck+sCH2kFGRigj9IR5CNgfD0QmgklbKL+8Ka5H0mSRwG40tn6wxIw75EYLhlEqx0u5NjG5gyPRTO05/UAAh/Q5ZHCh+WM7d0a28Jo3XtNTjIE7xBazwo3nR9Mdhpi9IX7Lp4d0k+dDMt/s1dZWX0gjvOXibhiCjK8u+hbUKg8MVyjdL7vHG1m8bmv7bTLZxyv6ffFYNEuEjbNKHT800hElkPfhBI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a4c2455e-7879-4a84-e740-08d62791a402 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 11:32:59.3927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0804 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:33:13 -0000 SGkgQWxleCwNCmFuZCBzb3JyeSBmb3IganVtcGluZyBpbnRvIHRoZSBkaXNjdXNzaW9uLi4uDQpG cm9tIG15IGFuZCAoQUZBSUspIDNHUFBzIHVuZGVyc3RhbmRpbmcgeW91ciBzbWFydHBob25lIGlz IGEgVUUgLSBzaXR0aW5nIG9uIHRoZSBvdGhlciBzaWRlIG9mIFJBTiAoZ05CKSAtIHdoZXJlYXMg YSBVUEYgbm9ybWFsbHkgaXMgc2VlbiBhcyBVUCBlbnRyeSAoYW5kIGV4aXQpIG9mIHRoZSA1RyBj b3JlIChpLmUuIGhhbmRsaW5nIGFsbCBVUCB0cmFmZmljIGluIGEgdHJ1ZSBDUC9VUCBzcGxpdCBm YXNoaW9uKS4NCkFueSBvdGhlciBpZGVhcyBvbiB0aGlzPyBDYW4gc29tZW9uZSBpbWFnaW5lIGFu eSBzY2VuYXJpbyB3aGVyZSBVRSBpbXBsZW1lbnRzIFVQRj8NClRoYW5rcyENCkJlc3QgUmVnYXJk cw0KRGlyayANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtbSBbbWFpbHRv OmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1DQpT ZW50OiBNb250YWcsIDEuIE9rdG9iZXIgMjAxOCAxMzoyMg0KVG86IGRtbUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5 c2lzLTAxDQoNCg0KDQpMZSAwMS8xMC8yMDE4IMOgIDA1OjUwLCBTaHVuc3VrZSBIb21tYSBhIMOp Y3JpdMKgOg0KPiBIaSBhbGwsDQo+ICMgU29ycnkgZm9yIG15IGxhdGUgcmVzcG9uc2UuLi4NCj4g DQo+IFRoYW5rIHlvdSBmb3IgeW91ciBsaXZlbHkgZGlzY3Vzc2lvbi4gSXQgaXMgdmVyeSBoZWxw ZnVsIGZvciANCj4gdW5kZXJzdGFuZGluZyBwb2ludHMgd2hpY2ggbmVlZCBzdXBwbGVtZW50YWwg ZXhwbGFuYXRpb24gYW5kIG1vcmUgDQo+IGNvbnNpZGVyYXRpb24uDQo+IA0KPiBGb2xsb3dpbmcg dGhlIGRpc2N1c3Npb24sIHdlJ3JlIHBsYW5uaW5nIHRvIHVwZGF0ZSB0aGUgSS1EIGZvciANCj4g Y292ZXJpbmcgdGhlIHBvaW50cyBiZWxvdzoNCj4gDQo+IC0gdGVybWluYXRpb24gcG9pbnRzIG9m IEdUUC1VDQo+ICDCoCAoUkFOcyBhbmQgVVBGcyB0ZXJtaW5hdGUgR1RQLVUgaW4gNUdTLikNCg0K V2hhdCBpcyBVUEY/DQoNCkkgdW5kZXJzdGFuZCBVUEYgc3RhbmRzIGZvciBVc2VyLVBsYW5lIEZ1 bmN0aW9uLg0KDQpJcyBteSBzbWFydHBob25lIHN1cHBvc2VkIHRvIGltcGxlbWVudCBVUEY/DQoN CkFsZXgNCg0KPiAtIHNldHRpbmcgUW9TIHBhcmFtZXRlciBvZiBvdXRlciBJUCBoZWFkZXINCj4g IMKgIChOb3RlIHRoYXQgaXQncyBub3QganVzdCBjb3B5IG9mIGlubmVyIHRvIG91dGVyLikNCj4g LSBwcm9ibGVtcyByZWxhdGVkIHRvIElQIGNvbm5lY3Rpdml0eSAoZS5nLiwgTVRVIGluIElQdjYg bmV0d29ya3MsIA0KPiBJUHY0IGFkZHJlc3MgZHVwbGljYXRpb24pDQo+IC0gc3VtbWFyeSBvZiBu ZXR3b3JrIHNsaWNpbmcgaW4gNUdTDQo+ICDCoCAoRS5nLiwgInNsaWNlIGlzIGNvbXBvc2VkIG9m IFNNRiBhbmQgVVBGcy4gQU1GIHNlbGVjdHMgU01GIA0KPiBkZXBlbmRpbmcgb24gTlNTQUkgc2Vu dCBmcm9tIFVFLCBhbmQgU01GIGluZGljYXRlcyB0byB0aGUgVUUgdGhlIFVQRiANCj4gdGhhdCBp dCBpcw0KPiBhbGxvY2F0ZWQuIikNCj4gLSBjYXNlIHN0dWRpZXMgb24gVVBGIHNlbGVjdGlvbg0K PiAgwqAgKEUuZy4sIHBhcmFtZXRlcnMgdXNlZCBmb3IgZGVjaWRpbmcgZGVzdGluYXRpb24gVVBG KSAjIE9wdGltaXppbmcgDQo+IGZvcndhcmRpbmcgcGF0aHMgc29sdXRpb24gbWlnaHQgYmUgcmVh bGl6ZWQgd2l0aCBVUEYgc2VsZWN0aW9uIA0KPiBtZWNoYW5pc20gaW4gM0dQUCBhcmNoaXRlY3R1 cmUuIChJRC1MT0MgbWF5IGJlIGFwcGxpZWQgYXMgc3VjaA0KPiBtZWNoYW5pc20uKQ0KPiANCj4g DQo+IElmIHlvdSBoYXZlIGFueSByZXF1ZXN0IGZvciB1cyBvbiB0aGlzIHVwZGF0aW5nLCBwbGVh c2UgbGV0IHVzIGtub3cuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiBTaHVuc3VrZQ0KPiAN Cj4gT24gMjAxOC8wOS8wOCAzOjI4LCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCj4+PiBJIHVuZGVy c3RhbmQgeW91ciBwb2ludCwgYnV0IHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBmb3IgYSBwcmVjaXNl IFFvUyANCj4+PiB3aXRob3V0IHVzaW5nIHNvbWUgc29ydCBvZiBlbmNhcHN1bGF0aW9uIGJlaW5n IGl0IEdUUCwgUlNWUCwgZXRjLg0KPj4+IEV2ZW4gd2l0aCB0dW5uZWxzLCB0aGVyZSBpcyBubyBn dWFyYW50ZWUgdGhhdCBhbGwgbm9kZXMgYWxvbmcgdGhlIA0KPj4+IHBhdGggaGF2ZSB0aGUgc2Ft ZSBoYXJkd2FyZSBjYXBhYmlsaXR5IGFuZCBjYW4gcHJvdmlkZSB0aGUgc2FtZSBRb1MgDQo+Pj4g dHJlYXRtZW50Lg0KPj4NCj4+IFRoZXJlIGlzIGV4aXN0aW5nIGhhcmR3YXJlIHdoZXJlIHRoZSBl bmNhcHN1bGF0b3IgY29waWVzIGlubmVyIFFvUyB0byANCj4+IG91dGVyIFFvUy4gQWxsIHJvdXRl cnMgYWxvbmcgdGhlIHBhdGgganVzdCBwcm9jZXNzIHRoZSBvdXRlciBRb1MsIG5vIA0KPj4gY2hh bmdlcyB0byBvciBuZXcgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMgZm9yIHRoZW0uDQo+Pg0KPj4+ IEZvciBleGFtcGxlLCB0aGUgY29kZSBwb2ludHMgaW4gcm91dGVycyBuZWVkIHRvIGJlIGNvbmZp Z3VyZWQgdG8gDQo+Pj4gY29ycmVjdGx5IGhhbmRsZSB0aGUgRVhQIGJpdHMgaW4gTVBMUyBsYWJl bHMuIEJ1dCB0aGVyZSBpcyBubyANCj4+PiBndWFyYW50ZWUgdGhhdCBhbGwgcm91dGVycyBjYW4g c3VwcG9ydCBhbGwgdmFsdWVzLiBUaGUgRVhQIHZhbHVlcyANCj4+PiBnZXQgbWFwcGVkIHRvIGNv ZGUgcG9pbnRzIGJ1dCB0aGUgbWFwcGluZyBpcyBub3QgYWx3YXlzIG9uZSB0byBvbmUuDQo+Pj4g My1iaXQgRVhQcyBjYW4gbWFwIHRvIDQgY29kZSBwb2ludHMgb24gdGhvc2Ugcm91dGVycyB3aXRo IGxlc3MgDQo+Pj4gY2FwYWJsZSBIL1cuDQo+Pg0KPj4gVGhhdCBpcyBhIGNvbXBsZXRlbHkgZGlm ZmVyZW50IG1hdHRlci4gVGhlIGRpc2N1c3Npb24gaXMgYWJvdXQgDQo+PiByZW1hcmtpbmcuIEFu ZCBpZiBvbmUgcmVtYXJrcyB0byB3aGF0IHRoZSBwYXRoIGNhbm5vdCBzdXBwb3J0LCB3ZWxsIA0K Pj4gdGhpbmdzIGRvbuKAmXQgd29yayBhcyBleHBlY3RlZC4NCj4+DQo+Pj4gU2xpY2luZyBpcyBh bG1vc3QgdGhlIHNhbWUuIEl0IGFsbG93cyB1c2VyIHRyYWZmaWMgdG8gYmUgbWFwcGVkIHRvIA0K Pj4+IHdoYXQgdGhlIG9wZXJhdG9yIHByb3ZpZGVzLg0KPj4+IEkgYWdyZWUgd2l0aCB5b3UgdGhh dCBuZXR3b3JrIHNob3VsZCBub3QgdG91Y2gvY2hhbmdlIG9yaWdpbmFsIA0KPj4+IGhlYWRlciBi aXRzLiBHVFAgb3IgYW55IG90aGVyIGVuY2Fwc3VsYXRpb24gZWFzaWx5IGFsbG93IGZvciB0aGlz LiANCj4+PiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBjYW4gcHJvdmlkZSBmb3IgdGhpcyB3 aXRob3V0IHVzaW5nIA0KPj4+IGVuY2Fwc3VsYXRpb24uIElQdjYgbWlnaHQgYmUgdGhlIGFuc3dl ci4gQnV0IGFzIFRvbSBwb2ludGVkIG91dCwgDQo+Pj4gZmxvdyBsYWJlbHMgY2FuIHN0aWxsIGNo YW5nZSBpbiB0aGUgbWlkZGxlLiBJcyB0aGVyZSBhbnkgcm9vbSBmb3IgDQo+Pj4gaW1wcm92ZW1l bnQuIFNJRHMgbWlnaHQgcHJlc2VudCBhbiBvcHBvcnR1bml0eS4NCj4+DQo+PiBOb3QgaWYgdGhl eSBhcmUgZW5jYXBzdWxhdGVkIGFuZCByb3V0ZXJzIGRvbuKAmXQgdG91Y2ggcGFja2V0cyBpbnNp ZGUuDQo+Pg0KPj4gRGlubw0KPj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IERpbm8gRmFyaW5hY2NpIFttYWlsdG86 ZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4+Pj4gU2VudDogMDcgU2VwdGVtYmVyIDIwMTggMTM6MDgN Cj4+Pj4gVG86IEFyYXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29t Pg0KPj4+PiBDYzogVG9tIEhlcmJlcnQgPHRvbUBxdWFudG9uaXVtLm5ldD47IHRhLW1peWFzYWth QGtkZGktcmVzZWFyY2guanA7IA0KPj4+PiBkbW0gPGRtbUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVj dDogUmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lz LTAxDQo+Pj4+DQo+Pj4+IEkgdGhpbmsgeW914oCZbGwgc3RpbGwgaGF2ZSB0aGUgUEhCIHJlLW1h cmtpbmcgaXNzdWVzIEkgbWVudGlvbmVkIGluIA0KPj4+PiBwcmV2aW91cyBlbWFpbHMuIFRoZSBx dWVzdGlvbiBpcywgc2hvdWxkIHRoZSBuZXR3b3JrIHRvdWNoL2NoYW5nZSANCj4+Pj4gYW55IGhl YWRlciBiaXRzIG9mIHRoZSBwYWNrZXQgdGhlIHNvdXJjZSBoYXMgYnVpbHQuIFRoZSBhbnN3ZXIg DQo+Pj4+IHNob3VsZCBwcm9iYWJseSBiZSBuby4NCj4+Pj4NCj4+Pj4gSGF2aW5nIHNhaWQgdGhh dCwgR1RQIGRpZCBpdCB0aGUgcmlnaHQgd2F5LCBldmVuIHRob3VnaCBpdCBjb3N0IGluIA0KPj4+ PiBoZWFkZXIgbGVuZ3RoLg0KPj4+Pg0KPj4+PiBEaW5vDQo+Pj4+DQo+Pj4+PiBPbiBTZXAgNywg MjAxOCwgYXQgODoyNiBBTSwgQXJhc2htaWQgQWtoYXZhaW4NCj4+Pj4gPGFyYXNobWlkLmFraGF2 YWluQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IENvcnJlY3QsIGZsb3cgbGFiZWxz IGNhbiBjaGFuZ2UgYWxvbmcgdGhlIHBhdGguIFRoYXQncyB3aHkgSSBsaWtlIA0KPj4+Pj4gdGhl IHNsaWNpbmcNCj4+Pj4gY29uY2VwdC4NCj4+Pj4+IFVFcyBjYW4gcmVxdWVzdCBzZXJ2aWNlcyB3 aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVzLCBvcGVyYXRvcnMgDQo+Pj4+PiBjb250cm9sIGhvdw0K Pj4+PiBzZXJ2aWNlIHJlcXVlc3QgYXJlIG1hcHBlZCBpbnRvIHNsaWNlcy4gSSBzaG91bGQgbG9v ayBpbnRvIHRoZSBhaXIgDQo+Pj4+IHNpZGUgb2YgdGhlIGJ1c2luZXNzIGFuZCBzZWUgd2hhdCBo YXBwZW5zIHRoZXJlLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AcXVhbnRv bml1bS5uZXRdDQo+Pj4+Pj4gU2VudDogMDcgU2VwdGVtYmVyIDIwMTggMTE6MTMNCj4+Pj4+PiBU bzogQXJhc2htaWQgQWtoYXZhaW4gPGFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb20+DQo+Pj4+ Pj4gQ2M6IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPjsgDQo+Pj4+Pj4gdGEt bWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDsgZG1tIDxkbW1AaWV0Zi5vcmc+DQo+Pj4+Pj4gU3Vi amVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvIA0KPj4+Pj4+IGRyYWZ0LWhtbS1kbW0tNWctdXBs YW5lLWFuYWx5c2lzLTAxDQo+Pj4+Pj4NCj4+Pj4+PiBPbiBGcmksIFNlcCA3LCAyMDE4IGF0IDg6 MDEgQU0sIEFyYXNobWlkIEFraGF2YWluIA0KPj4+Pj4+IDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3 ZWkuY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiBGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmlu YWNjaUBnbWFpbC5jb21dDQo+Pj4+Pj4+PiBTZW50OiAwNiBTZXB0ZW1iZXIgMjAxOCAxODo1OQ0K Pj4+Pj4+Pj4gVG86IEFyYXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWku Y29tPg0KPj4+Pj4+Pj4gQ2M6IFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5uZXQ+OyB0YS1t aXlhc2FrYUBrZGRpLQ0KPj4+PiByZXNlYXJjaC5qcDsNCj4+Pj4+Pj4+IGRtbSA8ZG1tQGlldGYu b3JnPg0KPj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvIA0KPj4+Pj4+Pj4g ZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtDQo+Pj4+IDAxDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IERpbm8gYnJvdWdodCB1cCBhIGdvb2QgcG9pbnQuIEhlcmUgaXMgbXkgdHdvIGNlbnRz IHdvcnRoOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE5vdCBzdXJlIHdoaWNoIHBvaW50Lg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBBcyBpdCB3YXMgZXhwbGFpbmVkIGJ5IFNyaWRoYXIswqAgZWFjaCBVRSBj YW4gaGF2ZSBtdWx0aXBsZSANCj4+Pj4+Pj4+PiBjb250ZXh0cy4gRm9yDQo+Pj4+Pj4+PiBleGFt cGxlLCB0b2RheSBzb21lIG9wZXJhdG9ycyBwcm92aWRlIERhdGEgYW5kIFZvTFRFIHNlcnZpY2Ug dG8gDQo+Pj4+Pj4+PiB0aGVpciBjdXN0b21lcnMuIFRoZXNlIHR3byBzZXJ2aWNlcyBhcmUgcmVw cmVzZW50ZWQgYnkgc2VwYXJhdGUgDQo+Pj4+Pj4+PiBHVFAgdHVubmVscyBpbiB0aGUgY29yZSB3 aXRoIGVhY2ggdHVubmVsIHRpZWQgdXAgdG8gYSBwYXJ0aWN1bGFyIFFvUy4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IElQdjQgZGlkbid0IGZpdCB0aGUgYmlsbCB3aGVuIEdUUCB3b3JrIHdhcyB1bmRl ciB3YXkgYXMgaXQgDQo+Pj4+Pj4+Pj4gY291bGRuJ3QgdW5pcXVlbHkgaWRlbnRpZnkgbXVsdGlw bGUgVUUNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGVyZSBpcyBubyByZWFzb24gd2h5IGl0IHNob3Vs ZG7igJl0LiBBbmQgSVB2NiwgZm9yIHRoaXMgDQo+Pj4+Pj4+PiB1c2UtY2FzZSBkb2VzbuKAmXQg YWRkIGFueXRoaW5nIG5ldyBvdGhlciB0aGFuIGEgMjggYml0IA0KPj4+Pj4+Pj4gdHJhZmZpYy1j bGFzcy9mbG93LWxhYmVsIHRoYXQgY2FuIHByb3ZpZGUgbW9yZSBiaXRzIGZvciDigJxuZXcNCj4+ Pj4gZnVuY3Rpb25hbGl0eeKAnS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FyYXNobWlk XcKgIEFuZCB0aGF0J3Mgd2hhdCBJIG1lYW50LiBIYXZpbmcgYSBmbG93IGxhYmVsIGlzIGhhbmR5 Lg0KPj4+Pj4+PiBXZSBjYW4gcGVyaGFwcyB1c2UgaXQgdG8gaWRlbnRpZnkgZGlmZmVyZW50IFVF IHNlc3Npb25zLg0KPj4+Pj4+Pg0KPj4+Pj4+IENhcmVmdWwgaWYgeW91IHVzZSB0aGUgZmxvdyBs YWJlbCB0byBpZGVudGlmeSBmbG93cy4gSXQgc2hvdWxkIGJlIA0KPj4+Pj4+IGNvbnNpZGVyZWQg InNvZnQgaWRlbnRpZmljYXRpb24iIHNpbmNlIGl0IG1pZ2h0IG5vdCBhbHdheXMgYmUgDQo+Pj4+ Pj4gY29ycmVjdCAoaXQgY2FuIGJlIGNoYW5nZWQgZW4gcm91dGUsIGlzbid0IHByb3RlY3RlZCBi eSBhbnkgDQo+Pj4+Pj4gY2hlY2tzdW0sIGFueW9uZSBjYW4gc2V0IGl0IGhvd2V2ZXIgdGhleSB3 YW50LCBldGMuKS4gSXQncyB1c2VmdWwgDQo+Pj4+Pj4gZm9yIHRoaW5ncyBsaWtlIEVDTVAgdGhh dCBkb24ndCByZXF1aXJlIDEwMCUgYWNjdXJhY3kgaW4gDQo+Pj4+Pj4gaWRlbnRpZnlpbmcgZmxv dy4gVGhlIGZsb3cgbGFiZWwgd2FzIGJyaWVmbHkgY29uc2lkZXJlZCBmb3IgDQo+Pj4+Pj4gaG9s ZGluZyBWTklzIGluIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGJ1dCB3ZQ0KPj4+PiB0YWxrZWQg dGhlbSBvdXQgb2YgdGhhdC4NCj4+Pj4+Pg0KPj4+Pj4+IFRvbQ0KPj4+Pj4+DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IHNlc3Npb25zL2NvbnRleHQvYmVhcmVyLiBTbywgR1RQIGFuZCBURUlEIGRpZCB0 aGUgam9iLiBCdXQgSSANCj4+Pj4+Pj4+PiBhZ3JlZSB3aXRoDQo+Pj4+Pj4+PiBEaW5vIHRoYXQg SVB2NiBpcyBtdWNoIG1vcmUgdmVyc2F0aWxlIGFuZCBpcyBkZWZpbml0ZWx5IHdvcnRoIA0KPj4+ Pj4+Pj4gbG9va2luZyBhdCBhcyBhbiBhbHRlcm5hdGl2ZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBU aGF0IGlzIG5vdCB3aGF0IEkgc2FpZC4gSSBzYWlkIOKAnElQIGNvdWxkIGhhdmUgc29sdmVkIHRo aXMgDQo+Pj4+Pj4+PiBwcm9ibGVt4oCdLiBBbmQNCj4+Pj4g4oCcSVDigJ0NCj4+Pj4+Pj4+IG1l YW5zIGVpdGhlciBJUHY0IG9yIElQdjYsIG9yIGJvdGggYXQgdGhlIHNhbWUgdGltZS4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FyYXNobWlkXQ0KPj4+Pj4+PiBIb3cgd291bGQgd2UgZW1w bG95IElQdjQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBkaWZmZXJlbnQgVUUgDQo+Pj4+Pj4+IHNl c3Npb25zLg0KPj4+Pj4+IFRPUz8NCj4+Pj4+Pj4gT3IgeW91IG1lYW4gdXNpbmcgZW5jYXBzdWxh dGlvbj8NCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQSBmYWN0b3Igd29ydGggY29uc2lk ZXJpbmcgdGhvdWdoIGlzIHRoYXQgdGhlIHVzZSBvZiBHVFAgYW5kIA0KPj4+Pj4+Pj4+IFRFSUQg aW4gbW9iaWxlDQo+Pj4+Pj4+PiBjb3JlIGFsbG93cyBvcGVyYXRvcnMgdG8gZGVhbCB3aXRoIFFv UyBvbiB0aGVpciBvd24gdGVybXMuIFRoZSANCj4+Pj4+Pj4+IHR1bm5lbHMgd2l0aCBzcGVjaWZp YyBvcGVyYXRvci1jb250cm9sbGVkIFFvUyBhcmUgZXN0YWJsaXNoZWQgDQo+Pj4+Pj4+PiBieSB0 aGUgY29udHJvbCBwbGFuZSBiZXR3ZWVuIGVOQiwgU0dXLCBhbmQgUEdXLiBVRXMgb3IgDQo+Pj4+ Pj4+PiBhcHBsaWNhdGlvbnMgc2l0dGluZyBpbiB0aGUgVUVzIGhhdmUgbm8gc2F5IGluIHRoaXMu IFdlbGwgYXQgDQo+Pj4+Pj4+PiBsZWFzdCB0aWxsIHRoZSBwYWNrZXQgZXhpdHMgb3BlcmF0b3In cw0KPj4+Pj4+IG5ldHdvcmsuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlIHByb2JsZW0gd2l0aCBv bmUgaGVhZGVyLCBpcyB0aGF0IGlmIHlvdSByZS1tYXJrIChrbm93biBhcyANCj4+Pj4+Pj4+IFBI QiBtYXJraWduIGluIHRoZSBvbGUgZGF5cykgeW91IGxvc2UgdGhlIG9yaWdpbmFsIHZhbHVlLiAN Cj4+Pj4+Pj4+IEVuY2Fwc3VsYXRpb24gaXMgdXNlZnVsIGhlcmUgYmVjYXVzZSB5b3UgY2FuIG1h cCB0aGUgaW5uZXIgdG8gDQo+Pj4+Pj4+PiBvdXRlciBhbmQgYW55d2hlcmUgYWxvbmcgdGhlIHBh dGggeW91IGNhbiBQSEIgcmVtYXJrIG9uIHRoZSANCj4+Pj4+Pj4+IG91dGVyIGhlYWRlci4gQW5k IHRoZW4gdGhlIGRlc3RpbmF0aW9uIGNhbiBzZWUgdGhlIG9yaWduYWwgDQo+Pj4+Pj4+PiBzb3Vy Y2XigJlzIFRvUy9Rb1MvVEMvZmxvdy1sYWJlbA0KPj4+PiB3aGF0ZXZlci4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gW0FyYXNobWlkXSBZZXMsIEkgYWdyZWUuIFRoZSBvcmlnaW5hbCB2YWx1 ZSBpcyBsb3N0IHdpdGggUEhCLg0KPj4+Pj4+PiBFbmNhcHN1bGF0aW9uIGNlcnRhaW5seSBtYWtl cyB0aGluZ3MgZWFzaWVyIGFuZCB0aGUgaW5uZXIgdG8gDQo+Pj4+Pj4+IG91dGVyIG1hcHBpbmcg dHJpY2sgaGFzIGJlZW4gd2lkZWx5IHVzZWQgaW4gSVAgYW5kIE1QTFMobXVsdGlwbGUgDQo+Pj4+ Pj4+IGxhYmVscyBsaWtlIHNlcnZpY2UgYW5kIHRyYW5zcG9ydCkNCj4+Pj4+Pj4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gVXNpbmcgdGhlIGluZm9ybWF0aW9uIGluIFVFJ3MgSVAgcGFja2V0IGhlYWRl ciBjYW4gamVvcGFyZGlzZSANCj4+Pj4+Pj4+PiB0aGUgYWJvdmUgdGlnaHQgUW9TIGNvbnRyb2wu IEkgdGhpbmsgZ29pbmcNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBOb3QgaWYgeW91IGVuY2Fwc3VsYXRl LiBCdXQgbm90ZSB3aXRoIFNSdjYsIHlvdSBjYW4gcG9zc2libHkgDQo+Pj4+Pj4+PiByZXRhaW4g dGhlIG9yaWdpbmFsIGZsb3ctbGFiZWwgaWYgdGhlIFNJRCBjYW4gcmV0YWluIHRob3NlIGJpdHMg DQo+Pj4+Pj4+PiBiZWZvcmUgb3ZlcndyaXRpbmcgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgZnJv bSB0aGUgb3B0aW9u4oCZcyB2YWx1ZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FyYXNobWlkXSBBZ3Jl ZS4gRW5jYXBzdWxhdGlvbiBkb2VzIHRoZSB0cmljayBhZ2Fpbi4gVGhhdCdzIHdoeSANCj4+Pj4+ Pj4gR1RQIGhhcyB3b3JrZWQgd2VsbCBhbmQgc2VydmVkIHRoZSBwdXJwb3MgaW4gdGhlIG1vYmls ZSANCj4+Pj4+Pj4gYmFjay1oYXVsIHNvIGZhci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBEaW5vDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IGRvd24gdGhpcyBwYXRoLCBvcGVyYXRvcnMgbmVl ZCBwcm9vZiB0aGF0IHRoZXkgd2lsbCBiZSBzdGlsbCANCj4+Pj4+Pj4+PiBpbiB0aGUgZHJpdmlu Zw0KPj4+Pj4+Pj4gc2VhdCBhbmQgUW9TIGNhbm5vdCBiZSBkaWN0YXRlZC90YW1wZXJlZCBieSB0 aGUgVUUgb3IgYW55IA0KPj4+Pj4+Pj4gYXBwbGljYXRpb24gcnVubmluZyBpbiBpdC4NCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IE5vdywgaGVyZSBpcyBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiBmb3Ig dGhlIG9wZXJhdG9ycy4gV291bGQgDQo+Pj4+Pj4+Pj4gYW55IG9wZXJhdG9yDQo+Pj4+Pj4+PiBi ZSBpbnRlcmVzdGVkIGluIGFsbG93aW5nIFFvU8KgIHRvIGJlIHNldCBieSB0aGUgVUUgb3IgYnkg DQo+Pj4+Pj4+PiBhcHBsaWNhdGlvbnMgcnVubmluZyBpbiB0aGUgVUUgYW5kIGNoYXJnZWQgZm9y IGJ5IHRoZSBuZXR3b3JrPw0KPj4+Pj4+Pj4gIlllcyIgY291bGQgcG90ZW50aWFsbHkgaW1wbHkg aW1wYWN0cyBvbiB0aGUgYWlyIGludGVyZmFjZSwgVUUgDQo+Pj4+Pj4+PiByZXNvdXJjZSBibG9j ayBhbGxvY2F0aW9uIGFuZCBjYW4gbWFrZSBzY2hlZHVsaW5nIG9uIHRoZSBSQU4gDQo+Pj4+Pj4+ PiBzaWRlDQo+Pj4+IG11Y2ggbW9yZSBjb21wbGV4Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQXJh c2htaWQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+IEZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRGlubyANCj4+Pj4+Pj4+Pj4gRmFyaW5hY2NpDQo+Pj4+Pj4+Pj4+ IFNlbnQ6IDA2IFNlcHRlbWJlciAyMDE4IDEyOjQ1DQo+Pj4+Pj4+Pj4+IFRvOiBUb20gSGVyYmVy dCA8dG9tQHF1YW50b25pdW0ubmV0Pg0KPj4+Pj4+Pj4+PiBDYzogdGEtbWl5YXNha2FAa2RkaS1y ZXNlYXJjaC5qcDsgZG1tIDxkbW1AaWV0Zi5vcmc+DQo+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBb RE1NXSBDb21tZW50cyB0byBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS0NCj4+Pj4gYW5hbHlzaXMt DQo+Pj4+Pj4gMDENCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEJlaGNldCwNCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiBJIHdhcyB0aGlua2luZyBpZiBURUlEIGlzIG5lZWQgdGhlbiB0aGF0IGNh biBiZSBlbmNvZGVkIGluIGEgDQo+Pj4+Pj4+Pj4+PiBsb2NhdG9yIGVhc2lseSBlbm91Z2guDQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gVG9tDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE5vdCBp ZiBhIGxvY2F0b3IgaXMgYSBQR1cgdGhhdCBpcyBzaGFyZWQgYnkgbWFueSBVRXMuDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+IDNHUFAgd2FudHMgcGVyIGJlYXJlciBhd2FyZW5lc3Mgc28gdGhleSBu ZWVkIGEgc3BlY2lmaWMgSUQsIA0KPj4+Pj4+Pj4+PiB0aGF0IGNvdWxkIGhhdmUgYmVlbiB0aGUg VUXigJlzIElQIGFkZHJlc3MuIEFuZCB3aXRoIElQdjYgaXQgDQo+Pj4+Pj4+Pj4+IGNhbiBiZSB1 bmlxdWUgYW5kIG5vdCB0aGUgaXNzdWUgdGhhdCBTcmlkaGFyIGJyb3VnaHQgdXAuDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+IElmIElMQSB3YXMgaW4gdXNlLCBqdXN0IHVzZSB0aGUgSUxBLUlEIGZv ciB0aGlzIHB1cnBvc2UuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IERpbm8NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+PiBkbW1AaWV0Zi5vcmcN Cj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4+ Pj4+Pj4NCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBkbW0gbWFpbGluZyBsaXN0DQo+PiBkbW1AaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+Pg0KPiANCj4gDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBs aXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQo= From nobody Mon Oct 1 07:14:38 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D2F130DFA for ; Mon, 1 Oct 2018 07:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com 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 K0sVMLZC3ptv for ; Mon, 1 Oct 2018 07:14:33 -0700 (PDT) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 1E448130DDC for ; Mon, 1 Oct 2018 07:14:33 -0700 (PDT) Received: by mail-it1-x141.google.com with SMTP id 134-v6so11456953itz.2 for ; Mon, 01 Oct 2018 07:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S6NFvExybclyDiUD1otMcupKckAYe2KjN/+b9ybtQ4s=; b=Dfo2NyantBkLtNEdCdfCokT+cvpQIwaXdwcfPa1E9m1bNzSyXYHKKTk1K9fLl4hfZe 81k3/Rw55YBiP5aelq50qX6EX5dPh/dQEc1B8U3MfEmFggNmRe1rEYVVZXpmVo4xiS3p iVm3iWk09L0UluDQvJ1EWgKUGf6InaP2qQuj4KXEg4Hl8iu6gltzj7gi7btFWqRaWXBR KiAoa3J27AJysUUvVlfAO1P14bkMyQ8O9tF8HO6UXIbdJynbBjWFJqFjlGQE1vCi+tpn Wok2R6GRWyTnT4zG3hcbnHBpqBbm6rjG/ggDTHOmBG3TYMrNPrvknU+oNaJXUEE2lAgp OOXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S6NFvExybclyDiUD1otMcupKckAYe2KjN/+b9ybtQ4s=; b=EoVQ8JqD2yOzkRP3EfXVmX1Isae3cfWJdHl8pUCyTGt7AHb5pi2K4MnFGU5i9q9ajk xUKldIIelTzF1SpOqnlBE/I5oOBxFMMrDTLYd0tBlYiTfhCGhZdYfF08R/+hO2aDWoiO FliBhT/gRgrr/bZT1FizkVdnm+ncEw3s/IJkkpt7kmzCvI+wq4O3xvGMul7qlcnfn3ej ZEZQzrSpd8l/XPPZZXAOrYOsnW8Aru81v1TysnbaUtgNoABh4Q51146lgHzhLrEUHgMe PLP9c30ainFt8Rq6YbJQqfVgCtjyj7sTvwiDtRT1mGMlW/Y6Wc8wJDyUffmrhc5q0Ms3 nc+g== X-Gm-Message-State: ABuFfogWjHeNCUxTMib0ML0TCOXr3zDfTMmRhBK0v5bwuQd2DYCydCpI uslWcHFiegeSk+Lt2Pf1pAxJ7ZqsQ9EcobF8TzceSA== X-Google-Smtp-Source: ACcGV60xrLGQP870gyNlrOhPDbtuk4hLL5xfrlolfLG8Naru+1d5hadUnxDx1wfXYWWcbPSjN/uDfqE6Qs4ljXIgiIc= X-Received: by 2002:a02:a40b:: with SMTP id c11-v6mr8572954jal.116.1538403272094; Mon, 01 Oct 2018 07:14:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7a59:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 07:14:31 -0700 (PDT) In-Reply-To: References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> From: Tom Herbert Date: Mon, 1 Oct 2018 07:14:31 -0700 Message-ID: To: Dirk.von-Hugo@telekom.de Cc: Alexandre Petrescu , dmm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:14:37 -0000 On Mon, Oct 1, 2018 at 4:32 AM, wrote: > Hi Alex, > and sorry for jumping into the discussion... > From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting= on the other side of RAN (gNB) - whereas a UPF normally is seen as UP entr= y (and exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP s= plit fashion). > Any other ideas on this? Can someone imagine any scenario where UE implem= ents UPF? Dirk, I am wondering what a UE that has thousands of downstream nodes and is multi-homed with attachments to several networks is called. It seems like it would be making UPF-like decisions in routing, QoS, and cost as to how forward uplink traffic. I don't think it can be a UPF of any attached network, but it seems like it's maybe acting as a "UPF" for it's own network (I think in IETF terminology we would just call it a glorified router). Tom > Thanks! > Best Regards > Dirk > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Montag, 1. Oktober 2018 13:22 > To: dmm@ietf.org > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit : >> Hi all, >> # Sorry for my late response... >> >> Thank you for your lively discussion. It is very helpful for >> understanding points which need supplemental explanation and more >> consideration. >> >> Following the discussion, we're planning to update the I-D for >> covering the points below: >> >> - termination points of GTP-U >> (RANs and UPFs terminate GTP-U in 5GS.) > > What is UPF? > > I understand UPF stands for User-Plane Function. > > Is my smartphone supposed to implement UPF? > > Alex > >> - setting QoS parameter of outer IP header >> (Note that it's not just copy of inner to outer.) >> - problems related to IP connectivity (e.g., MTU in IPv6 networks, >> IPv4 address duplication) >> - summary of network slicing in 5GS >> (E.g., "slice is composed of SMF and UPFs. AMF selects SMF >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF >> that it is >> allocated.") >> - case studies on UPF selection >> (E.g., parameters used for deciding destination UPF) # Optimizing >> forwarding paths solution might be realized with UPF selection >> mechanism in 3GPP architecture. (ID-LOC may be applied as such >> mechanism.) >> >> >> If you have any request for us on this updating, please let us know. >> >> Best regards, >> >> Shunsuke >> >> On 2018/09/08 3:28, Dino Farinacci wrote: >>>> I understand your point, but there is no guarantee for a precise QoS >>>> without using some sort of encapsulation being it GTP, RSVP, etc. >>>> Even with tunnels, there is no guarantee that all nodes along the >>>> path have the same hardware capability and can provide the same QoS >>>> treatment. >>> >>> There is existing hardware where the encapsulator copies inner QoS to >>> outer QoS. All routers along the path just process the outer QoS, no >>> changes to or new processing requirements for them. >>> >>>> For example, the code points in routers need to be configured to >>>> correctly handle the EXP bits in MPLS labels. But there is no >>>> guarantee that all routers can support all values. The EXP values >>>> get mapped to code points but the mapping is not always one to one. >>>> 3-bit EXPs can map to 4 code points on those routers with less >>>> capable H/W. >>> >>> That is a completely different matter. The discussion is about >>> remarking. And if one remarks to what the path cannot support, well >>> things don=E2=80=99t work as expected. >>> >>>> Slicing is almost the same. It allows user traffic to be mapped to >>>> what the operator provides. >>>> I agree with you that network should not touch/change original >>>> header bits. GTP or any other encapsulation easily allow for this. >>>> The question is whether we can provide for this without using >>>> encapsulation. IPv6 might be the answer. But as Tom pointed out, >>>> flow labels can still change in the middle. Is there any room for >>>> improvement. SIDs might present an opportunity. >>> >>> Not if they are encapsulated and routers don=E2=80=99t touch packets in= side. >>> >>> Dino >>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: 07 September 2018 13:08 >>>>> To: Arashmid Akhavain >>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-research.jp; >>>>> dmm >>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>>> >>>>> I think you=E2=80=99ll still have the PHB re-marking issues I mention= ed in >>>>> previous emails. The question is, should the network touch/change >>>>> any header bits of the packet the source has built. The answer >>>>> should probably be no. >>>>> >>>>> Having said that, GTP did it the right way, even though it cost in >>>>> header length. >>>>> >>>>> Dino >>>>> >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain >>>>> wrote: >>>>>> >>>>>> Correct, flow labels can change along the path. That's why I like >>>>>> the slicing >>>>> concept. >>>>>> UEs can request services with different attributes, operators >>>>>> control how >>>>> service request are mapped into slices. I should look into the air >>>>> side of the business and see what happens there. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net] >>>>>>> Sent: 07 September 2018 11:13 >>>>>>> To: Arashmid Akhavain >>>>>>> Cc: Dino Farinacci ; >>>>>>> ta-miyasaka@kddi-research.jp; dmm >>>>>>> Subject: Re: [DMM] Comments to >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 >>>>>>> >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>> Sent: 06 September 2018 18:59 >>>>>>>>> To: Arashmid Akhavain >>>>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi- >>>>> research.jp; >>>>>>>>> dmm >>>>>>>>> Subject: Re: [DMM] Comments to >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- >>>>> 01 >>>>>>>>> >>>>>>>>>> Dino brought up a good point. Here is my two cents worth: >>>>>>>>> >>>>>>>>> Not sure which point. >>>>>>>>> >>>>>>>>>> As it was explained by Sridhar, each UE can have multiple >>>>>>>>>> contexts. For >>>>>>>>> example, today some operators provide Data and VoLTE service to >>>>>>>>> their customers. These two services are represented by separate >>>>>>>>> GTP tunnels in the core with each tunnel tied up to a particular = QoS. >>>>>>>>>> >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it >>>>>>>>>> couldn't uniquely identify multiple UE >>>>>>>>> >>>>>>>>> There is no reason why it shouldn=E2=80=99t. And IPv6, for this >>>>>>>>> use-case doesn=E2=80=99t add anything new other than a 28 bit >>>>>>>>> traffic-class/flow-label that can provide more bits for =E2=80=9C= new >>>>> functionality=E2=80=9D. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid] And that's what I meant. Having a flow label is handy. >>>>>>>> We can perhaps use it to identify different UE sessions. >>>>>>>> >>>>>>> Careful if you use the flow label to identify flows. It should be >>>>>>> considered "soft identification" since it might not always be >>>>>>> correct (it can be changed en route, isn't protected by any >>>>>>> checksum, anyone can set it however they want, etc.). It's useful >>>>>>> for things like ECMP that don't require 100% accuracy in >>>>>>> identifying flow. The flow label was briefly considered for >>>>>>> holding VNIs in network virtualization, but we >>>>> talked them out of that. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>>>> >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I >>>>>>>>>> agree with >>>>>>>>> Dino that IPv6 is much more versatile and is definitely worth >>>>>>>>> looking at as an alternative. >>>>>>>>> >>>>>>>>> That is not what I said. I said =E2=80=9CIP could have solved thi= s >>>>>>>>> problem=E2=80=9D. And >>>>> =E2=80=9CIP=E2=80=9D >>>>>>>>> means either IPv4 or IPv6, or both at the same time. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid] >>>>>>>> How would we employ IPv4 to distinguish between different UE >>>>>>>> sessions. >>>>>>> TOS? >>>>>>>> Or you mean using encapsulation? >>>>>>>> >>>>>>>>> >>>>>>>>>> A factor worth considering though is that the use of GTP and >>>>>>>>>> TEID in mobile >>>>>>>>> core allows operators to deal with QoS on their own terms. The >>>>>>>>> tunnels with specific operator-controlled QoS are established >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or >>>>>>>>> applications sitting in the UEs have no say in this. Well at >>>>>>>>> least till the packet exits operator's >>>>>>> network. >>>>>>>>> >>>>>>>>> The problem with one header, is that if you re-mark (known as >>>>>>>>> PHB markign in the ole days) you lose the original value. >>>>>>>>> Encapsulation is useful here because you can map the inner to >>>>>>>>> outer and anywhere along the path you can PHB remark on the >>>>>>>>> outer header. And then the destination can see the orignal >>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label >>>>> whatever. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. >>>>>>>> Encapsulation certainly makes things easier and the inner to >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple >>>>>>>> labels like service and transport) >>>>>>>> >>>>>>>>> >>>>>>>>>> Using the information in UE's IP packet header can jeopardise >>>>>>>>>> the above tight QoS control. I think going >>>>>>>>> >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly >>>>>>>>> retain the original flow-label if the SID can retain those bits >>>>>>>>> before overwriting the destination address from the option=E2=80= =99s value. >>>>>>>> >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why >>>>>>>> GTP has worked well and served the purpos in the mobile >>>>>>>> back-haul so far. >>>>>>>> >>>>>>>>> >>>>>>>>> Dino >>>>>>>>> >>>>>>>>>> down this path, operators need proof that they will be still >>>>>>>>>> in the driving >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any >>>>>>>>> application running in it. >>>>>>>>>> >>>>>>>>>> Now, here is an interesting question for the operators. Would >>>>>>>>>> any operator >>>>>>>>> be interested in allowing QoS to be set by the UE or by >>>>>>>>> applications running in the UE and charged for by the network? >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE >>>>>>>>> resource block allocation and can make scheduling on the RAN >>>>>>>>> side >>>>> much more complex. >>>>>>>>>> >>>>>>>>>> Arashmid >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino >>>>>>>>>>> Farinacci >>>>>>>>>>> Sent: 06 September 2018 12:45 >>>>>>>>>>> To: Tom Herbert >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; dmm >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- >>>>> analysis- >>>>>>> 01 >>>>>>>>>>> >>>>>>>>>>>> Behcet, >>>>>>>>>>>> >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a >>>>>>>>>>>> locator easily enough. >>>>>>>>>>>> >>>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. >>>>>>>>>>> >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, >>>>>>>>>>> that could have been the UE=E2=80=99s IP address. And with IPv6= it >>>>>>>>>>> can be unique and not the issue that Sridhar brought up. >>>>>>>>>>> >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. >>>>>>>>>>> >>>>>>>>>>> Dino >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dmm mailing list >>>>>>>>>>> dmm@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Oct 1 20:47:20 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8E127B92 for ; Mon, 1 Oct 2018 20:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bE-QW_VCiIT1 for ; Mon, 1 Oct 2018 20:47:16 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2011C12F1A5 for ; Mon, 1 Oct 2018 20:47:15 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w923lDNw015852; Tue, 2 Oct 2018 12:47:13 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id DC5A7EA77AE; Tue, 2 Oct 2018 12:47:13 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id D03F2EA7776; Tue, 2 Oct 2018 12:47:13 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id CA96C40019E; Tue, 2 Oct 2018 12:47:13 +0900 (JST) References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> From: Shunsuke Homma Message-ID: Date: Tue, 2 Oct 2018 12:47:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit To: Dirk.von-Hugo@telekom.de, alexandre.petrescu@gmail.com, dmm@ietf.org X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 03:47:20 -0000 Thanks Dark for your explaining what is UPF instead of me. Alex, brief definitions of UPF are described in the section 4.1.1.1 of this draft. Also, you can find more details in 3GPP TS23.501. Regards, Shunsuke On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de wrote: > Hi Alex, > and sorry for jumping into the discussion... > From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting on the other side of RAN (gNB) - whereas a UPF normally is seen as UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP split fashion). > Any other ideas on this? Can someone imagine any scenario where UE implements UPF? > Thanks! > Best Regards > Dirk > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Montag, 1. Oktober 2018 13:22 > To: dmm@ietf.org > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > Le 01/10/2018 à 05:50, Shunsuke Homma a écrit : >> Hi all, >> # Sorry for my late response... >> >> Thank you for your lively discussion. It is very helpful for >> understanding points which need supplemental explanation and more >> consideration. >> >> Following the discussion, we're planning to update the I-D for >> covering the points below: >> >> - termination points of GTP-U >>   (RANs and UPFs terminate GTP-U in 5GS.) > > What is UPF? > > I understand UPF stands for User-Plane Function. > > Is my smartphone supposed to implement UPF? > > Alex > >> - setting QoS parameter of outer IP header >>   (Note that it's not just copy of inner to outer.) >> - problems related to IP connectivity (e.g., MTU in IPv6 networks, >> IPv4 address duplication) >> - summary of network slicing in 5GS >>   (E.g., "slice is composed of SMF and UPFs. AMF selects SMF >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF >> that it is >> allocated.") >> - case studies on UPF selection >>   (E.g., parameters used for deciding destination UPF) # Optimizing >> forwarding paths solution might be realized with UPF selection >> mechanism in 3GPP architecture. (ID-LOC may be applied as such >> mechanism.) >> >> >> If you have any request for us on this updating, please let us know. >> >> Best regards, >> >> Shunsuke >> >> On 2018/09/08 3:28, Dino Farinacci wrote: >>>> I understand your point, but there is no guarantee for a precise QoS >>>> without using some sort of encapsulation being it GTP, RSVP, etc. >>>> Even with tunnels, there is no guarantee that all nodes along the >>>> path have the same hardware capability and can provide the same QoS >>>> treatment. >>> >>> There is existing hardware where the encapsulator copies inner QoS to >>> outer QoS. All routers along the path just process the outer QoS, no >>> changes to or new processing requirements for them. >>> >>>> For example, the code points in routers need to be configured to >>>> correctly handle the EXP bits in MPLS labels. But there is no >>>> guarantee that all routers can support all values. The EXP values >>>> get mapped to code points but the mapping is not always one to one. >>>> 3-bit EXPs can map to 4 code points on those routers with less >>>> capable H/W. >>> >>> That is a completely different matter. The discussion is about >>> remarking. And if one remarks to what the path cannot support, well >>> things don’t work as expected. >>> >>>> Slicing is almost the same. It allows user traffic to be mapped to >>>> what the operator provides. >>>> I agree with you that network should not touch/change original >>>> header bits. GTP or any other encapsulation easily allow for this. >>>> The question is whether we can provide for this without using >>>> encapsulation. IPv6 might be the answer. But as Tom pointed out, >>>> flow labels can still change in the middle. Is there any room for >>>> improvement. SIDs might present an opportunity. >>> >>> Not if they are encapsulated and routers don’t touch packets inside. >>> >>> Dino >>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: 07 September 2018 13:08 >>>>> To: Arashmid Akhavain >>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-research.jp; >>>>> dmm >>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>>> >>>>> I think you’ll still have the PHB re-marking issues I mentioned in >>>>> previous emails. The question is, should the network touch/change >>>>> any header bits of the packet the source has built. The answer >>>>> should probably be no. >>>>> >>>>> Having said that, GTP did it the right way, even though it cost in >>>>> header length. >>>>> >>>>> Dino >>>>> >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain >>>>> wrote: >>>>>> >>>>>> Correct, flow labels can change along the path. That's why I like >>>>>> the slicing >>>>> concept. >>>>>> UEs can request services with different attributes, operators >>>>>> control how >>>>> service request are mapped into slices. I should look into the air >>>>> side of the business and see what happens there. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net] >>>>>>> Sent: 07 September 2018 11:13 >>>>>>> To: Arashmid Akhavain >>>>>>> Cc: Dino Farinacci ; >>>>>>> ta-miyasaka@kddi-research.jp; dmm >>>>>>> Subject: Re: [DMM] Comments to >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 >>>>>>> >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>> Sent: 06 September 2018 18:59 >>>>>>>>> To: Arashmid Akhavain >>>>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi- >>>>> research.jp; >>>>>>>>> dmm >>>>>>>>> Subject: Re: [DMM] Comments to >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- >>>>> 01 >>>>>>>>> >>>>>>>>>> Dino brought up a good point. Here is my two cents worth: >>>>>>>>> >>>>>>>>> Not sure which point. >>>>>>>>> >>>>>>>>>> As it was explained by Sridhar,  each UE can have multiple >>>>>>>>>> contexts. For >>>>>>>>> example, today some operators provide Data and VoLTE service to >>>>>>>>> their customers. These two services are represented by separate >>>>>>>>> GTP tunnels in the core with each tunnel tied up to a particular QoS. >>>>>>>>>> >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it >>>>>>>>>> couldn't uniquely identify multiple UE >>>>>>>>> >>>>>>>>> There is no reason why it shouldn’t. And IPv6, for this >>>>>>>>> use-case doesn’t add anything new other than a 28 bit >>>>>>>>> traffic-class/flow-label that can provide more bits for “new >>>>> functionality”. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid]  And that's what I meant. Having a flow label is handy. >>>>>>>> We can perhaps use it to identify different UE sessions. >>>>>>>> >>>>>>> Careful if you use the flow label to identify flows. It should be >>>>>>> considered "soft identification" since it might not always be >>>>>>> correct (it can be changed en route, isn't protected by any >>>>>>> checksum, anyone can set it however they want, etc.). It's useful >>>>>>> for things like ECMP that don't require 100% accuracy in >>>>>>> identifying flow. The flow label was briefly considered for >>>>>>> holding VNIs in network virtualization, but we >>>>> talked them out of that. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>>>> >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I >>>>>>>>>> agree with >>>>>>>>> Dino that IPv6 is much more versatile and is definitely worth >>>>>>>>> looking at as an alternative. >>>>>>>>> >>>>>>>>> That is not what I said. I said “IP could have solved this >>>>>>>>> problem”. And >>>>> “IP” >>>>>>>>> means either IPv4 or IPv6, or both at the same time. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid] >>>>>>>> How would we employ IPv4 to distinguish between different UE >>>>>>>> sessions. >>>>>>> TOS? >>>>>>>> Or you mean using encapsulation? >>>>>>>> >>>>>>>>> >>>>>>>>>> A factor worth considering though is that the use of GTP and >>>>>>>>>> TEID in mobile >>>>>>>>> core allows operators to deal with QoS on their own terms. The >>>>>>>>> tunnels with specific operator-controlled QoS are established >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or >>>>>>>>> applications sitting in the UEs have no say in this. Well at >>>>>>>>> least till the packet exits operator's >>>>>>> network. >>>>>>>>> >>>>>>>>> The problem with one header, is that if you re-mark (known as >>>>>>>>> PHB markign in the ole days) you lose the original value. >>>>>>>>> Encapsulation is useful here because you can map the inner to >>>>>>>>> outer and anywhere along the path you can PHB remark on the >>>>>>>>> outer header. And then the destination can see the orignal >>>>>>>>> source’s ToS/QoS/TC/flow-label >>>>> whatever. >>>>>>>> >>>>>>>> >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. >>>>>>>> Encapsulation certainly makes things easier and the inner to >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple >>>>>>>> labels like service and transport) >>>>>>>> >>>>>>>>> >>>>>>>>>> Using the information in UE's IP packet header can jeopardise >>>>>>>>>> the above tight QoS control. I think going >>>>>>>>> >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly >>>>>>>>> retain the original flow-label if the SID can retain those bits >>>>>>>>> before overwriting the destination address from the option’s value. >>>>>>>> >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why >>>>>>>> GTP has worked well and served the purpos in the mobile >>>>>>>> back-haul so far. >>>>>>>> >>>>>>>>> >>>>>>>>> Dino >>>>>>>>> >>>>>>>>>> down this path, operators need proof that they will be still >>>>>>>>>> in the driving >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any >>>>>>>>> application running in it. >>>>>>>>>> >>>>>>>>>> Now, here is an interesting question for the operators. Would >>>>>>>>>> any operator >>>>>>>>> be interested in allowing QoS  to be set by the UE or by >>>>>>>>> applications running in the UE and charged for by the network? >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE >>>>>>>>> resource block allocation and can make scheduling on the RAN >>>>>>>>> side >>>>> much more complex. >>>>>>>>>> >>>>>>>>>> Arashmid >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino >>>>>>>>>>> Farinacci >>>>>>>>>>> Sent: 06 September 2018 12:45 >>>>>>>>>>> To: Tom Herbert >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; dmm >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- >>>>> analysis- >>>>>>> 01 >>>>>>>>>>> >>>>>>>>>>>> Behcet, >>>>>>>>>>>> >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a >>>>>>>>>>>> locator easily enough. >>>>>>>>>>>> >>>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. >>>>>>>>>>> >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, >>>>>>>>>>> that could have been the UE’s IP address. And with IPv6 it >>>>>>>>>>> can be unique and not the issue that Sridhar brought up. >>>>>>>>>>> >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. >>>>>>>>>>> >>>>>>>>>>> Dino >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dmm mailing list >>>>>>>>>>> dmm@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Oct 2 08:44:22 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F07130E16 for ; Tue, 2 Oct 2018 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4Pun2L6PFB9l for ; Tue, 2 Oct 2018 08:44:17 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 CBE06130E9C for ; Tue, 2 Oct 2018 08:44:16 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id z4-v6so2793826wrb.1 for ; Tue, 02 Oct 2018 08:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=kLwfv/eYcIDfem4c8EjKSLKFyeRasrmfJuGk+7stYBs=; b=EtO5bGTqI01OkMZP7K0ee9tLRZ1n5VIaqaU3+bzmvBLQg2Wbn0huvJpRrL7eRwODUw A6oRxfnNf9SPExpLFBjSMMTHaDlILxvHhNlz1/AiJXCN7B3dIv7LjqE7mrzMfM+lntex KyspAbYgoqO6sXJOXI9yVGyJBDj1Fbed4jR9Xe73eC3w6+BmvmrZDRN9jErE/xPnO1Gy P59e/pj8weY9wokSJhyjbqgQSLn+V09XNB0RgVSyafWlSWPap2q61KBmUwNaEOH2Epyb j9LpDHGqB1gy2G2l23lXHQfoubXjFEn6WjEvnPYmelFdg9ojj3jssfA54SdJaDf9kj1Z pOuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=kLwfv/eYcIDfem4c8EjKSLKFyeRasrmfJuGk+7stYBs=; b=Z4PP2DtIkbJGv0KawnYNqrAVBneix2HyBzBYMDdStKjcdhoTe6AXyXB7wRtkvP5jxQ WCZJVjuemwpSTwVYf+E3OD3czqsA8PWe3CKHaoq5pQdQq/SoF8Bo4MBSVndeGmGSJzJ2 uE1DbOa/6vLJrvTyWFI2jgWHn9Wx8qHOp7tcHUpdzXbQJ5qosUDyWypobM+9OBs30Bgc 3QrHrucBvmQ1abcwgY01MjGHO22LSl63wWHjLULgY2nCvPx7yXgF3DHhN81r7m0vQrtx bOCVMNrG0xILdaExlxtfRhkss/FDLZ1NaGpOvaE73OWDerNL+b+WkDVnJQIwq7Vx2EkW 0OXw== X-Gm-Message-State: ABuFfohL7G9vdTOMYfyL1/PDJybuQVqr1aIyCBq3yovzzfhbBJXRnG7w foTbQT6szC23rkR03CnTQ4/ePwaKyUKy9atVz+0= X-Google-Smtp-Source: ACcGV62k8bo7KdoULqxNHvMM/eukYqVPuZHcphrfpWM5TpfNr8W4lu6AdXUMeNzYdgxMJnVWG2Lr23vVsBfiv1XeHps= X-Received: by 2002:a5d:50cf:: with SMTP id f15-v6mr10384071wrt.128.1538495054957; Tue, 02 Oct 2018 08:44:14 -0700 (PDT) MIME-Version: 1.0 References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Tue, 2 Oct 2018 10:44:03 -0500 Message-ID: To: Shunsuke Homma Cc: Dirk.von-Hugo@telekom.de, Alexandre Petrescu , dmm Content-Type: multipart/alternative; boundary="0000000000003d575a057740cb05" Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 15:44:20 -0000 --0000000000003d575a057740cb05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable UPF is virtualized PGW, folks. While PGW is fixed in location and possibly serving a large number of UE which are geographically in the area, that part of the city and that city itself, UPF can be deployed closer to the UE and thus probably serving smaller number of UEs Behcet On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma wrote: > Thanks Dark for your explaining what is UPF instead of me. > > Alex, brief definitions of UPF are described in the section 4.1.1.1 of > this draft. Also, you can find more details in 3GPP TS23.501. > > Regards, > > Shunsuke > > On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de wrote: > > Hi Alex, > > and sorry for jumping into the discussion... > > From my and (AFAIK) 3GPPs understanding your smartphone is a UE - > sitting on the other side of RAN (gNB) - whereas a UPF normally is seen a= s > UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a tru= e > CP/UP split fashion). > > Any other ideas on this? Can someone imagine any scenario where UE > implements UPF? > > Thanks! > > Best Regards > > Dirk > > > > -----Original Message----- > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Montag, 1. Oktober 2018 13:22 > > To: dmm@ietf.org > > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > > > > > Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit : > >> Hi all, > >> # Sorry for my late response... > >> > >> Thank you for your lively discussion. It is very helpful for > >> understanding points which need supplemental explanation and more > >> consideration. > >> > >> Following the discussion, we're planning to update the I-D for > >> covering the points below: > >> > >> - termination points of GTP-U > >> (RANs and UPFs terminate GTP-U in 5GS.) > > > > What is UPF? > > > > I understand UPF stands for User-Plane Function. > > > > Is my smartphone supposed to implement UPF? > > > > Alex > > > >> - setting QoS parameter of outer IP header > >> (Note that it's not just copy of inner to outer.) > >> - problems related to IP connectivity (e.g., MTU in IPv6 networks, > >> IPv4 address duplication) > >> - summary of network slicing in 5GS > >> (E.g., "slice is composed of SMF and UPFs. AMF selects SMF > >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF > >> that it is > >> allocated.") > >> - case studies on UPF selection > >> (E.g., parameters used for deciding destination UPF) # Optimizing > >> forwarding paths solution might be realized with UPF selection > >> mechanism in 3GPP architecture. (ID-LOC may be applied as such > >> mechanism.) > >> > >> > >> If you have any request for us on this updating, please let us know. > >> > >> Best regards, > >> > >> Shunsuke > >> > >> On 2018/09/08 3:28, Dino Farinacci wrote: > >>>> I understand your point, but there is no guarantee for a precise QoS > >>>> without using some sort of encapsulation being it GTP, RSVP, etc. > >>>> Even with tunnels, there is no guarantee that all nodes along the > >>>> path have the same hardware capability and can provide the same QoS > >>>> treatment. > >>> > >>> There is existing hardware where the encapsulator copies inner QoS to > >>> outer QoS. All routers along the path just process the outer QoS, no > >>> changes to or new processing requirements for them. > >>> > >>>> For example, the code points in routers need to be configured to > >>>> correctly handle the EXP bits in MPLS labels. But there is no > >>>> guarantee that all routers can support all values. The EXP values > >>>> get mapped to code points but the mapping is not always one to one. > >>>> 3-bit EXPs can map to 4 code points on those routers with less > >>>> capable H/W. > >>> > >>> That is a completely different matter. The discussion is about > >>> remarking. And if one remarks to what the path cannot support, well > >>> things don=E2=80=99t work as expected. > >>> > >>>> Slicing is almost the same. It allows user traffic to be mapped to > >>>> what the operator provides. > >>>> I agree with you that network should not touch/change original > >>>> header bits. GTP or any other encapsulation easily allow for this. > >>>> The question is whether we can provide for this without using > >>>> encapsulation. IPv6 might be the answer. But as Tom pointed out, > >>>> flow labels can still change in the middle. Is there any room for > >>>> improvement. SIDs might present an opportunity. > >>> > >>> Not if they are encapsulated and routers don=E2=80=99t touch packets = inside. > >>> > >>> Dino > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>> Sent: 07 September 2018 13:08 > >>>>> To: Arashmid Akhavain > >>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-research.jp; > >>>>> dmm > >>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > >>>>> > >>>>> I think you=E2=80=99ll still have the PHB re-marking issues I menti= oned in > >>>>> previous emails. The question is, should the network touch/change > >>>>> any header bits of the packet the source has built. The answer > >>>>> should probably be no. > >>>>> > >>>>> Having said that, GTP did it the right way, even though it cost in > >>>>> header length. > >>>>> > >>>>> Dino > >>>>> > >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain > >>>>> wrote: > >>>>>> > >>>>>> Correct, flow labels can change along the path. That's why I like > >>>>>> the slicing > >>>>> concept. > >>>>>> UEs can request services with different attributes, operators > >>>>>> control how > >>>>> service request are mapped into slices. I should look into the air > >>>>> side of the business and see what happens there. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net] > >>>>>>> Sent: 07 September 2018 11:13 > >>>>>>> To: Arashmid Akhavain > >>>>>>> Cc: Dino Farinacci ; > >>>>>>> ta-miyasaka@kddi-research.jp; dmm > >>>>>>> Subject: Re: [DMM] Comments to > >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 > >>>>>>> > >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>>>>> Sent: 06 September 2018 18:59 > >>>>>>>>> To: Arashmid Akhavain > >>>>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi- > >>>>> research.jp; > >>>>>>>>> dmm > >>>>>>>>> Subject: Re: [DMM] Comments to > >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- > >>>>> 01 > >>>>>>>>> > >>>>>>>>>> Dino brought up a good point. Here is my two cents worth: > >>>>>>>>> > >>>>>>>>> Not sure which point. > >>>>>>>>> > >>>>>>>>>> As it was explained by Sridhar, each UE can have multiple > >>>>>>>>>> contexts. For > >>>>>>>>> example, today some operators provide Data and VoLTE service to > >>>>>>>>> their customers. These two services are represented by separate > >>>>>>>>> GTP tunnels in the core with each tunnel tied up to a particula= r > QoS. > >>>>>>>>>> > >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it > >>>>>>>>>> couldn't uniquely identify multiple UE > >>>>>>>>> > >>>>>>>>> There is no reason why it shouldn=E2=80=99t. And IPv6, for this > >>>>>>>>> use-case doesn=E2=80=99t add anything new other than a 28 bit > >>>>>>>>> traffic-class/flow-label that can provide more bits for =E2=80= =9Cnew > >>>>> functionality=E2=80=9D. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] And that's what I meant. Having a flow label is hand= y. > >>>>>>>> We can perhaps use it to identify different UE sessions. > >>>>>>>> > >>>>>>> Careful if you use the flow label to identify flows. It should be > >>>>>>> considered "soft identification" since it might not always be > >>>>>>> correct (it can be changed en route, isn't protected by any > >>>>>>> checksum, anyone can set it however they want, etc.). It's useful > >>>>>>> for things like ECMP that don't require 100% accuracy in > >>>>>>> identifying flow. The flow label was briefly considered for > >>>>>>> holding VNIs in network virtualization, but we > >>>>> talked them out of that. > >>>>>>> > >>>>>>> Tom > >>>>>>> > >>>>>>>>> > >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I > >>>>>>>>>> agree with > >>>>>>>>> Dino that IPv6 is much more versatile and is definitely worth > >>>>>>>>> looking at as an alternative. > >>>>>>>>> > >>>>>>>>> That is not what I said. I said =E2=80=9CIP could have solved t= his > >>>>>>>>> problem=E2=80=9D. And > >>>>> =E2=80=9CIP=E2=80=9D > >>>>>>>>> means either IPv4 or IPv6, or both at the same time. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] > >>>>>>>> How would we employ IPv4 to distinguish between different UE > >>>>>>>> sessions. > >>>>>>> TOS? > >>>>>>>> Or you mean using encapsulation? > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> A factor worth considering though is that the use of GTP and > >>>>>>>>>> TEID in mobile > >>>>>>>>> core allows operators to deal with QoS on their own terms. The > >>>>>>>>> tunnels with specific operator-controlled QoS are established > >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or > >>>>>>>>> applications sitting in the UEs have no say in this. Well at > >>>>>>>>> least till the packet exits operator's > >>>>>>> network. > >>>>>>>>> > >>>>>>>>> The problem with one header, is that if you re-mark (known as > >>>>>>>>> PHB markign in the ole days) you lose the original value. > >>>>>>>>> Encapsulation is useful here because you can map the inner to > >>>>>>>>> outer and anywhere along the path you can PHB remark on the > >>>>>>>>> outer header. And then the destination can see the orignal > >>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label > >>>>> whatever. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. > >>>>>>>> Encapsulation certainly makes things easier and the inner to > >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple > >>>>>>>> labels like service and transport) > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> Using the information in UE's IP packet header can jeopardise > >>>>>>>>>> the above tight QoS control. I think going > >>>>>>>>> > >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly > >>>>>>>>> retain the original flow-label if the SID can retain those bits > >>>>>>>>> before overwriting the destination address from the option=E2= =80=99s > value. > >>>>>>>> > >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why > >>>>>>>> GTP has worked well and served the purpos in the mobile > >>>>>>>> back-haul so far. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Dino > >>>>>>>>> > >>>>>>>>>> down this path, operators need proof that they will be still > >>>>>>>>>> in the driving > >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any > >>>>>>>>> application running in it. > >>>>>>>>>> > >>>>>>>>>> Now, here is an interesting question for the operators. Would > >>>>>>>>>> any operator > >>>>>>>>> be interested in allowing QoS to be set by the UE or by > >>>>>>>>> applications running in the UE and charged for by the network? > >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE > >>>>>>>>> resource block allocation and can make scheduling on the RAN > >>>>>>>>> side > >>>>> much more complex. > >>>>>>>>>> > >>>>>>>>>> Arashmid > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino > >>>>>>>>>>> Farinacci > >>>>>>>>>>> Sent: 06 September 2018 12:45 > >>>>>>>>>>> To: Tom Herbert > >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; dmm > >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- > >>>>> analysis- > >>>>>>> 01 > >>>>>>>>>>> > >>>>>>>>>>>> Behcet, > >>>>>>>>>>>> > >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a > >>>>>>>>>>>> locator easily enough. > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>> > >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. > >>>>>>>>>>> > >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, > >>>>>>>>>>> that could have been the UE=E2=80=99s IP address. And with IP= v6 it > >>>>>>>>>>> can be unique and not the issue that Sridhar brought up. > >>>>>>>>>>> > >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. > >>>>>>>>>>> > >>>>>>>>>>> Dino > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> dmm mailing list > >>>>>>>>>>> dmm@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > >> > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > ---------------------------------- > Shunsuke Homma > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 > > NTT Network Service Systems Labs. > Musashino city, Tokyo, Japan > ---------------------------------- > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --0000000000003d575a057740cb05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
UPF is virtualized PGW, folks.
While PGW is fixed in l= ocation and possibly serving a large number of UE which are geographically = in the area, that part of the city and that city itself, UPF can be deploye= d closer to the UE and thus probably serving smaller number of UEs

Behcet

Thanks Dark for your explaining w= hat is UPF instead of me.

Alex, brief definitions of UPF are described in the section 4.1.1.1 of
this draft. Also, you can find more details in 3GPP TS23.501.

Regards,

Shunsuke

On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de wrote:
> Hi Alex,
> and sorry for jumping into the discussion...
>=C2=A0 From my and (AFAIK) 3GPPs understanding your smartphone is a UE = - sitting on the other side of RAN (gNB) - whereas a UPF normally is seen a= s UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a tru= e CP/UP split fashion).
> Any other ideas on this? Can someone imagine any scenario where UE imp= lements UPF?
> Thanks!
> Best Regards
> Dirk
>
> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org=
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
>
>
> Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit=C2=A0:
>> Hi all,
>> # Sorry for my late response...
>>
>> Thank you for your lively discussion. It is very helpful for
>> understanding points which need supplemental explanation and more<= br> >> consideration.
>>
>> Following the discussion, we're planning to update the I-D for=
>> covering the points below:
>>
>> - termination points of GTP-U
>>=C2=A0 =C2=A0=C2=A0 (RANs and UPFs terminate GTP-U in 5GS.)
>
> What is UPF?
>
> I understand UPF stands for User-Plane Function.
>
> Is my smartphone supposed to implement UPF?
>
> Alex
>
>> - setting QoS parameter of outer IP header
>>=C2=A0 =C2=A0=C2=A0 (Note that it's not just copy of inner to o= uter.)
>> - problems related to IP connectivity (e.g., MTU in IPv6 networks,=
>> IPv4 address duplication)
>> - summary of network slicing in 5GS
>>=C2=A0 =C2=A0=C2=A0 (E.g., "slice is composed of SMF and UPFs.= AMF selects SMF
>> depending on NSSAI sent from UE, and SMF indicates to the UE the U= PF
>> that it is
>> allocated.")
>> - case studies on UPF selection
>>=C2=A0 =C2=A0=C2=A0 (E.g., parameters used for deciding destination= UPF) # Optimizing
>> forwarding paths solution might be realized with UPF selection
>> mechanism in 3GPP architecture. (ID-LOC may be applied as such
>> mechanism.)
>>
>>
>> If you have any request for us on this updating, please let us kno= w.
>>
>> Best regards,
>>
>> Shunsuke
>>
>> On 2018/09/08 3:28, Dino Farinacci wrote:
>>>> I understand your point, but there is no guarantee for a p= recise QoS
>>>> without using some sort of encapsulation being it GTP, RSV= P, etc.
>>>> Even with tunnels, there is no guarantee that all nodes al= ong the
>>>> path have the same hardware capability and can provide the= same QoS
>>>> treatment.
>>>
>>> There is existing hardware where the encapsulator copies inner= QoS to
>>> outer QoS. All routers along the path just process the outer Q= oS, no
>>> changes to or new processing requirements for them.
>>>
>>>> For example, the code points in routers need to be configu= red to
>>>> correctly handle the EXP bits in MPLS labels. But there is= no
>>>> guarantee that all routers can support all values. The EXP= values
>>>> get mapped to code points but the mapping is not always on= e to one.
>>>> 3-bit EXPs can map to 4 code points on those routers with = less
>>>> capable H/W.
>>>
>>> That is a completely different matter. The discussion is about=
>>> remarking. And if one remarks to what the path cannot support,= well
>>> things don=E2=80=99t work as expected.
>>>
>>>> Slicing is almost the same. It allows user traffic to be m= apped to
>>>> what the operator provides.
>>>> I agree with you that network should not touch/change orig= inal
>>>> header bits. GTP or any other encapsulation easily allow f= or this.
>>>> The question is whether we can provide for this without us= ing
>>>> encapsulation. IPv6 might be the answer. But as Tom pointe= d out,
>>>> flow labels can still change in the middle. Is there any r= oom for
>>>> improvement. SIDs might present an opportunity.
>>>
>>> Not if they are encapsulated and routers don=E2=80=99t touch p= ackets inside.
>>>
>>> Dino
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>>>>> Sent: 07 September 2018 13:08
>>>>> To: Arashmid Akhavain <arashmid.akhavain@huawei.com><= br> >>>>> Cc: Tom Herbert <tom@quantonium.net>; ta-miyasaka@kddi-research.jp;<= br> >>>>> dmm <dmm@ietf.org>
>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane= -analysis-01
>>>>>
>>>>> I think you=E2=80=99ll still have the PHB re-marking i= ssues I mentioned in
>>>>> previous emails. The question is, should the network t= ouch/change
>>>>> any header bits of the packet the source has built. Th= e answer
>>>>> should probably be no.
>>>>>
>>>>> Having said that, GTP did it the right way, even thoug= h it cost in
>>>>> header length.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
>>>>> <arashmid.akhavain@huawei.com> wrote:
>>>>>>
>>>>>> Correct, flow labels can change along the path. Th= at's why I like
>>>>>> the slicing
>>>>> concept.
>>>>>> UEs can request services with different attributes= , operators
>>>>>> control how
>>>>> service request are mapped into slices. I should look = into the air
>>>>> side of the business and see what happens there.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Tom Herbert [mailto:tom@quantonium.net]
>>>>>>> Sent: 07 September 2018 11:13
>>>>>>> To: Arashmid Akhavain <arashmid.akhavain@huawei.com<= /a>>
>>>>>>> Cc: Dino Farinacci <farinacci@gmail.com>;
>>>>>>> ta-miyasaka@kddi-research.jp; dmm <dmm@ietf.org>
>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>> draft-hmm-dmm-5g-uplane-analysis-01
>>>>>>>
>>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhav= ain
>>>>>>> <arashmid.akhavain@huawei.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com]<= br> >>>>>>>>> Sent: 06 September 2018 18:59
>>>>>>>>> To: Arashmid Akhavain <arashmid.akhavain@hua= wei.com>
>>>>>>>>> Cc: Tom Herbert <tom@quantonium.net>; ta-miyasa= ka@kddi-
>>>>> research.jp;
>>>>>>>>> dmm <dmm@ietf.org>
>>>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>>>> draft-hmm-dmm-5g-uplane-analysis-
>>>>> 01
>>>>>>>>>
>>>>>>>>>> Dino brought up a good point. Here= is my two cents worth:
>>>>>>>>>
>>>>>>>>> Not sure which point.
>>>>>>>>>
>>>>>>>>>> As it was explained by Sridhar,=C2= =A0 each UE can have multiple
>>>>>>>>>> contexts. For
>>>>>>>>> example, today some operators provide = Data and VoLTE service to
>>>>>>>>> their customers. These two services ar= e represented by separate
>>>>>>>>> GTP tunnels in the core with each tunn= el tied up to a particular QoS.
>>>>>>>>>>
>>>>>>>>>> IPv4 didn't fit the bill when = GTP work was under way as it
>>>>>>>>>> couldn't uniquely identify mul= tiple UE
>>>>>>>>>
>>>>>>>>> There is no reason why it shouldn=E2= =80=99t. And IPv6, for this
>>>>>>>>> use-case doesn=E2=80=99t add anything = new other than a 28 bit
>>>>>>>>> traffic-class/flow-label that can prov= ide more bits for =E2=80=9Cnew
>>>>> functionality=E2=80=9D.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid]=C2=A0 And that's what I mea= nt. Having a flow label is handy.
>>>>>>>> We can perhaps use it to identify differen= t UE sessions.
>>>>>>>>
>>>>>>> Careful if you use the flow label to identify = flows. It should be
>>>>>>> considered "soft identification" sin= ce it might not always be
>>>>>>> correct (it can be changed en route, isn't= protected by any
>>>>>>> checksum, anyone can set it however they want,= etc.). It's useful
>>>>>>> for things like ECMP that don't require 10= 0% accuracy in
>>>>>>> identifying flow. The flow label was briefly c= onsidered for
>>>>>>> holding VNIs in network virtualization, but we=
>>>>> talked them out of that.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>>>
>>>>>>>>>> sessions/context/bearer. So, GTP a= nd TEID did the job. But I
>>>>>>>>>> agree with
>>>>>>>>> Dino that IPv6 is much more versatile = and is definitely worth
>>>>>>>>> looking at as an alternative.
>>>>>>>>>
>>>>>>>>> That is not what I said. I said =E2=80= =9CIP could have solved this
>>>>>>>>> problem=E2=80=9D. And
>>>>> =E2=80=9CIP=E2=80=9D
>>>>>>>>> means either IPv4 or IPv6, or both at = the same time.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid]
>>>>>>>> How would we employ IPv4 to distinguish be= tween different UE
>>>>>>>> sessions.
>>>>>>> TOS?
>>>>>>>> Or you mean using encapsulation?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> A factor worth considering though = is that the use of GTP and
>>>>>>>>>> TEID in mobile
>>>>>>>>> core allows operators to deal with QoS= on their own terms. The
>>>>>>>>> tunnels with specific operator-control= led QoS are established
>>>>>>>>> by the control plane between eNB, SGW,= and PGW. UEs or
>>>>>>>>> applications sitting in the UEs have n= o say in this. Well at
>>>>>>>>> least till the packet exits operator&#= 39;s
>>>>>>> network.
>>>>>>>>>
>>>>>>>>> The problem with one header, is that i= f you re-mark (known as
>>>>>>>>> PHB markign in the ole days) you lose = the original value.
>>>>>>>>> Encapsulation is useful here because y= ou can map the inner to
>>>>>>>>> outer and anywhere along the path you = can PHB remark on the
>>>>>>>>> outer header. And then the destination= can see the orignal
>>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label=
>>>>> whatever.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid] Yes, I agree. The original valu= e is lost with PHB.
>>>>>>>> Encapsulation certainly makes things easie= r and the inner to
>>>>>>>> outer mapping trick has been widely used i= n IP and MPLS(multiple
>>>>>>>> labels like service and transport)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Using the information in UE's = IP packet header can jeopardise
>>>>>>>>>> the above tight QoS control. I thi= nk going
>>>>>>>>>
>>>>>>>>> Not if you encapsulate. But note with = SRv6, you can possibly
>>>>>>>>> retain the original flow-label if the = SID can retain those bits
>>>>>>>>> before overwriting the destination add= ress from the option=E2=80=99s value.
>>>>>>>>
>>>>>>>> [Arashmid] Agree. Encapsulation does the t= rick again. That's why
>>>>>>>> GTP has worked well and served the purpos = in the mobile
>>>>>>>> back-haul so far.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dino
>>>>>>>>>
>>>>>>>>>> down this path, operators need pro= of that they will be still
>>>>>>>>>> in the driving
>>>>>>>>> seat and QoS cannot be dictated/tamper= ed by the UE or any
>>>>>>>>> application running in it.
>>>>>>>>>>
>>>>>>>>>> Now, here is an interesting questi= on for the operators. Would
>>>>>>>>>> any operator
>>>>>>>>> be interested in allowing QoS=C2=A0 to= be set by the UE or by
>>>>>>>>> applications running in the UE and cha= rged for by the network?
>>>>>>>>> "Yes" could potentially impl= y impacts on the air interface, UE
>>>>>>>>> resource block allocation and can make= scheduling on the RAN
>>>>>>>>> side
>>>>> much more complex.
>>>>>>>>>>
>>>>>>>>>> Arashmid
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On = Behalf Of Dino
>>>>>>>>>>> Farinacci
>>>>>>>>>>> Sent: 06 September 2018 12:45<= br> >>>>>>>>>>> To: Tom Herbert <tom@quantonium.net> >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; d= mm <dmm@ietf.org&g= t;
>>>>>>>>>>> Subject: Re: [DMM] Comments to= draft-hmm-dmm-5g-uplane-
>>>>> analysis-
>>>>>>> 01
>>>>>>>>>>>
>>>>>>>>>>>> Behcet,
>>>>>>>>>>>>
>>>>>>>>>>>> I was thinking if TEID is = need then that can be encoded in a
>>>>>>>>>>>> locator easily enough.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Not if a locator is a PGW that= is shared by many UEs.
>>>>>>>>>>>
>>>>>>>>>>> 3GPP wants per bearer awarenes= s so they need a specific ID,
>>>>>>>>>>> that could have been the UE=E2= =80=99s IP address. And with IPv6 it
>>>>>>>>>>> can be unique and not the issu= e that Sridhar brought up.
>>>>>>>>>>>
>>>>>>>>>>> If ILA was in use, just use th= e ILA-ID for this purpose.
>>>>>>>>>>>
>>>>>>>>>>> Dino
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> dmm mailing list
>>>>>>>>>>> dmm@ietf.org
>>>>>>>>>>> https://www.ie= tf.org/mailman/listinfo/dmm
>>>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/dmm<= br> >>>
>>
>>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


--
----------------------------------
Shunsuke Homma
<homma= .shunsuke@lab.ntt.co.jp>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--0000000000003d575a057740cb05-- From nobody Tue Oct 2 10:14:24 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC221312CA for ; Tue, 2 Oct 2018 10:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iDb_f0GuvlDZ for ; Tue, 2 Oct 2018 10:14:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FC5131368 for ; Tue, 2 Oct 2018 10:10:02 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2170B5F684E2 for ; Tue, 2 Oct 2018 18:09:56 +0100 (IST) Received: from YYZEML706-CHM.china.huawei.com (10.218.33.91) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 2 Oct 2018 18:09:54 +0100 Received: from YYZEML704-CHM.china.huawei.com ([169.254.1.141]) by yyzeml706-chm.china.huawei.com ([169.254.3.170]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 13:09:51 -0400 From: Arashmid Akhavain To: "sarikaya@ieee.org" , Shunsuke Homma CC: dmm Thread-Topic: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 Thread-Index: AQHUWTnje1ehGQuh0kug3/4QbZgenaUKgqMAgAAC+YCAARBGgIAAyDWA///TY6A= Date: Tue, 2 Oct 2018 17:09:51 +0000 Message-ID: References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.51.47] Content-Type: multipart/alternative; boundary="_000_D57109449177B54F8B9C093953AC5BCD755E4D4Byyzeml704chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 17:14:23 -0000 --_000_D57109449177B54F8B9C093953AC5BCD755E4D4Byyzeml704chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IG5lY2Vzc2FyaWx5LA0KDQpZb3UgYXJlIGNvcnJlY3QgaW4gdGhhdCBQR1cgaXMgYSBVUEYs IGJ1dCBhIFVQRiBpcyBieSBubyBtZWFucyBsaW1pdGVkIHRvIFBHVy4gQSBVUEYgaXMgYW55IGZ1 bmN0aW9uIHRoYXQgY2FuIGJlIGV4ZWN1dGVkIG9uIHVzZXIgdHJhZmZpYyBpbiBtb2JpbGUgbmV0 d29yay4gSGF2aW5nIHNhaWQgdGhhdCBob3dldmVyLCBJIHRoaW5rIHRoZSBmaXJzdCBVUEZzIHRo YXQgd2Ugd2lsbCBzZWUgd2lsbCBiZSBpbiB0aGUgZm9ybSBvZiBTR1csIFBHVy4NCg0KQXJhc2ht aWQNCg0KRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBCZWhjZXQgU2FyaWtheWENClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDIsIDIwMTggMTE6NDQg QU0NClRvOiBTaHVuc3VrZSBIb21tYSA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCkNj OiBkbW0gPGRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRE1NXSBDb21tZW50cyB0byBkcmFm dC1obW0tZG1tLTVnLXVwbGFuZS1hbmFseXNpcy0wMQ0KDQpVUEYgaXMgdmlydHVhbGl6ZWQgUEdX LCBmb2xrcy4NCldoaWxlIFBHVyBpcyBmaXhlZCBpbiBsb2NhdGlvbiBhbmQgcG9zc2libHkgc2Vy dmluZyBhIGxhcmdlIG51bWJlciBvZiBVRSB3aGljaCBhcmUgZ2VvZ3JhcGhpY2FsbHkgaW4gdGhl IGFyZWEsIHRoYXQgcGFydCBvZiB0aGUgY2l0eSBhbmQgdGhhdCBjaXR5IGl0c2VsZiwgVVBGIGNh biBiZSBkZXBsb3llZCBjbG9zZXIgdG8gdGhlIFVFIGFuZCB0aHVzIHByb2JhYmx5IHNlcnZpbmcg c21hbGxlciBudW1iZXIgb2YgVUVzDQoNCkJlaGNldA0KDQpPbiBNb24sIE9jdCAxLCAyMDE4IGF0 IDEwOjQ3IFBNIFNodW5zdWtlIEhvbW1hIDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPG1h aWx0bzpob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPj4gd3JvdGU6DQpUaGFua3MgRGFyayBm b3IgeW91ciBleHBsYWluaW5nIHdoYXQgaXMgVVBGIGluc3RlYWQgb2YgbWUuDQoNCkFsZXgsIGJy aWVmIGRlZmluaXRpb25zIG9mIFVQRiBhcmUgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIDQuMS4x LjEgb2YNCnRoaXMgZHJhZnQuIEFsc28sIHlvdSBjYW4gZmluZCBtb3JlIGRldGFpbHMgaW4gM0dQ UCBUUzIzLjUwMS4NCg0KUmVnYXJkcywNCg0KU2h1bnN1a2UNCg0KT24gMjAxOC8xMC8wMSAyMDoz MiwgRGlyay52b24tSHVnb0B0ZWxla29tLmRlPG1haWx0bzpEaXJrLnZvbi1IdWdvQHRlbGVrb20u ZGU+IHdyb3RlOg0KPiBIaSBBbGV4LA0KPiBhbmQgc29ycnkgZm9yIGp1bXBpbmcgaW50byB0aGUg ZGlzY3Vzc2lvbi4uLg0KPiAgRnJvbSBteSBhbmQgKEFGQUlLKSAzR1BQcyB1bmRlcnN0YW5kaW5n IHlvdXIgc21hcnRwaG9uZSBpcyBhIFVFIC0gc2l0dGluZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiBS QU4gKGdOQikgLSB3aGVyZWFzIGEgVVBGIG5vcm1hbGx5IGlzIHNlZW4gYXMgVVAgZW50cnkgKGFu ZCBleGl0KSBvZiB0aGUgNUcgY29yZSAoaS5lLiBoYW5kbGluZyBhbGwgVVAgdHJhZmZpYyBpbiBh IHRydWUgQ1AvVVAgc3BsaXQgZmFzaGlvbikuDQo+IEFueSBvdGhlciBpZGVhcyBvbiB0aGlzPyBD YW4gc29tZW9uZSBpbWFnaW5lIGFueSBzY2VuYXJpbyB3aGVyZSBVRSBpbXBsZW1lbnRzIFVQRj8N Cj4gVGhhbmtzIQ0KPiBCZXN0IFJlZ2FyZHMNCj4gRGlyaw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzxtYWls dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1 DQo+IFNlbnQ6IE1vbnRhZywgMS4gT2t0b2JlciAyMDE4IDEzOjIyDQo+IFRvOiBkbW1AaWV0Zi5v cmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRv IGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAxDQo+DQo+DQo+DQo+IExlIDAxLzEw LzIwMTggw6AgMDU6NTAsIFNodW5zdWtlIEhvbW1hIGEgw6ljcml0IDoNCj4+IEhpIGFsbCwNCj4+ ICMgU29ycnkgZm9yIG15IGxhdGUgcmVzcG9uc2UuLi4NCj4+DQo+PiBUaGFuayB5b3UgZm9yIHlv dXIgbGl2ZWx5IGRpc2N1c3Npb24uIEl0IGlzIHZlcnkgaGVscGZ1bCBmb3INCj4+IHVuZGVyc3Rh bmRpbmcgcG9pbnRzIHdoaWNoIG5lZWQgc3VwcGxlbWVudGFsIGV4cGxhbmF0aW9uIGFuZCBtb3Jl DQo+PiBjb25zaWRlcmF0aW9uLg0KPj4NCj4+IEZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiwgd2Un cmUgcGxhbm5pbmcgdG8gdXBkYXRlIHRoZSBJLUQgZm9yDQo+PiBjb3ZlcmluZyB0aGUgcG9pbnRz IGJlbG93Og0KPj4NCj4+IC0gdGVybWluYXRpb24gcG9pbnRzIG9mIEdUUC1VDQo+PiAgICAgKFJB TnMgYW5kIFVQRnMgdGVybWluYXRlIEdUUC1VIGluIDVHUy4pDQo+DQo+IFdoYXQgaXMgVVBGPw0K Pg0KPiBJIHVuZGVyc3RhbmQgVVBGIHN0YW5kcyBmb3IgVXNlci1QbGFuZSBGdW5jdGlvbi4NCj4N Cj4gSXMgbXkgc21hcnRwaG9uZSBzdXBwb3NlZCB0byBpbXBsZW1lbnQgVVBGPw0KPg0KPiBBbGV4 DQo+DQo+PiAtIHNldHRpbmcgUW9TIHBhcmFtZXRlciBvZiBvdXRlciBJUCBoZWFkZXINCj4+ICAg ICAoTm90ZSB0aGF0IGl0J3Mgbm90IGp1c3QgY29weSBvZiBpbm5lciB0byBvdXRlci4pDQo+PiAt IHByb2JsZW1zIHJlbGF0ZWQgdG8gSVAgY29ubmVjdGl2aXR5IChlLmcuLCBNVFUgaW4gSVB2NiBu ZXR3b3JrcywNCj4+IElQdjQgYWRkcmVzcyBkdXBsaWNhdGlvbikNCj4+IC0gc3VtbWFyeSBvZiBu ZXR3b3JrIHNsaWNpbmcgaW4gNUdTDQo+PiAgICAgKEUuZy4sICJzbGljZSBpcyBjb21wb3NlZCBv ZiBTTUYgYW5kIFVQRnMuIEFNRiBzZWxlY3RzIFNNRg0KPj4gZGVwZW5kaW5nIG9uIE5TU0FJIHNl bnQgZnJvbSBVRSwgYW5kIFNNRiBpbmRpY2F0ZXMgdG8gdGhlIFVFIHRoZSBVUEYNCj4+IHRoYXQg aXQgaXMNCj4+IGFsbG9jYXRlZC4iKQ0KPj4gLSBjYXNlIHN0dWRpZXMgb24gVVBGIHNlbGVjdGlv bg0KPj4gICAgIChFLmcuLCBwYXJhbWV0ZXJzIHVzZWQgZm9yIGRlY2lkaW5nIGRlc3RpbmF0aW9u IFVQRikgIyBPcHRpbWl6aW5nDQo+PiBmb3J3YXJkaW5nIHBhdGhzIHNvbHV0aW9uIG1pZ2h0IGJl IHJlYWxpemVkIHdpdGggVVBGIHNlbGVjdGlvbg0KPj4gbWVjaGFuaXNtIGluIDNHUFAgYXJjaGl0 ZWN0dXJlLiAoSUQtTE9DIG1heSBiZSBhcHBsaWVkIGFzIHN1Y2gNCj4+IG1lY2hhbmlzbS4pDQo+ Pg0KPj4NCj4+IElmIHlvdSBoYXZlIGFueSByZXF1ZXN0IGZvciB1cyBvbiB0aGlzIHVwZGF0aW5n LCBwbGVhc2UgbGV0IHVzIGtub3cuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+IFNodW5z dWtlDQo+Pg0KPj4gT24gMjAxOC8wOS8wOCAzOjI4LCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCj4+ Pj4gSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQsIGJ1dCB0aGVyZSBpcyBubyBndWFyYW50ZWUgZm9y IGEgcHJlY2lzZSBRb1MNCj4+Pj4gd2l0aG91dCB1c2luZyBzb21lIHNvcnQgb2YgZW5jYXBzdWxh dGlvbiBiZWluZyBpdCBHVFAsIFJTVlAsIGV0Yy4NCj4+Pj4gRXZlbiB3aXRoIHR1bm5lbHMsIHRo ZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IGFsbCBub2RlcyBhbG9uZyB0aGUNCj4+Pj4gcGF0aCBo YXZlIHRoZSBzYW1lIGhhcmR3YXJlIGNhcGFiaWxpdHkgYW5kIGNhbiBwcm92aWRlIHRoZSBzYW1l IFFvUw0KPj4+PiB0cmVhdG1lbnQuDQo+Pj4NCj4+PiBUaGVyZSBpcyBleGlzdGluZyBoYXJkd2Fy ZSB3aGVyZSB0aGUgZW5jYXBzdWxhdG9yIGNvcGllcyBpbm5lciBRb1MgdG8NCj4+PiBvdXRlciBR b1MuIEFsbCByb3V0ZXJzIGFsb25nIHRoZSBwYXRoIGp1c3QgcHJvY2VzcyB0aGUgb3V0ZXIgUW9T LCBubw0KPj4+IGNoYW5nZXMgdG8gb3IgbmV3IHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzIGZvciB0 aGVtLg0KPj4+DQo+Pj4+IEZvciBleGFtcGxlLCB0aGUgY29kZSBwb2ludHMgaW4gcm91dGVycyBu ZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdG8NCj4+Pj4gY29ycmVjdGx5IGhhbmRsZSB0aGUgRVhQIGJp dHMgaW4gTVBMUyBsYWJlbHMuIEJ1dCB0aGVyZSBpcyBubw0KPj4+PiBndWFyYW50ZWUgdGhhdCBh bGwgcm91dGVycyBjYW4gc3VwcG9ydCBhbGwgdmFsdWVzLiBUaGUgRVhQIHZhbHVlcw0KPj4+PiBn ZXQgbWFwcGVkIHRvIGNvZGUgcG9pbnRzIGJ1dCB0aGUgbWFwcGluZyBpcyBub3QgYWx3YXlzIG9u ZSB0byBvbmUuDQo+Pj4+IDMtYml0IEVYUHMgY2FuIG1hcCB0byA0IGNvZGUgcG9pbnRzIG9uIHRo b3NlIHJvdXRlcnMgd2l0aCBsZXNzDQo+Pj4+IGNhcGFibGUgSC9XLg0KPj4+DQo+Pj4gVGhhdCBp cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IG1hdHRlci4gVGhlIGRpc2N1c3Npb24gaXMgYWJvdXQN Cj4+PiByZW1hcmtpbmcuIEFuZCBpZiBvbmUgcmVtYXJrcyB0byB3aGF0IHRoZSBwYXRoIGNhbm5v dCBzdXBwb3J0LCB3ZWxsDQo+Pj4gdGhpbmdzIGRvbuKAmXQgd29yayBhcyBleHBlY3RlZC4NCj4+ Pg0KPj4+PiBTbGljaW5nIGlzIGFsbW9zdCB0aGUgc2FtZS4gSXQgYWxsb3dzIHVzZXIgdHJhZmZp YyB0byBiZSBtYXBwZWQgdG8NCj4+Pj4gd2hhdCB0aGUgb3BlcmF0b3IgcHJvdmlkZXMuDQo+Pj4+ IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBuZXR3b3JrIHNob3VsZCBub3QgdG91Y2gvY2hhbmdlIG9y aWdpbmFsDQo+Pj4+IGhlYWRlciBiaXRzLiBHVFAgb3IgYW55IG90aGVyIGVuY2Fwc3VsYXRpb24g ZWFzaWx5IGFsbG93IGZvciB0aGlzLg0KPj4+PiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBj YW4gcHJvdmlkZSBmb3IgdGhpcyB3aXRob3V0IHVzaW5nDQo+Pj4+IGVuY2Fwc3VsYXRpb24uIElQ djYgbWlnaHQgYmUgdGhlIGFuc3dlci4gQnV0IGFzIFRvbSBwb2ludGVkIG91dCwNCj4+Pj4gZmxv dyBsYWJlbHMgY2FuIHN0aWxsIGNoYW5nZSBpbiB0aGUgbWlkZGxlLiBJcyB0aGVyZSBhbnkgcm9v bSBmb3INCj4+Pj4gaW1wcm92ZW1lbnQuIFNJRHMgbWlnaHQgcHJlc2VudCBhbiBvcHBvcnR1bml0 eS4NCj4+Pg0KPj4+IE5vdCBpZiB0aGV5IGFyZSBlbmNhcHN1bGF0ZWQgYW5kIHJvdXRlcnMgZG9u 4oCZdCB0b3VjaCBwYWNrZXRzIGluc2lkZS4NCj4+Pg0KPj4+IERpbm8NCj4+Pg0KPj4+Pg0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+IEZyb206IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbTxtYWls dG86ZmFyaW5hY2NpQGdtYWlsLmNvbT5dDQo+Pj4+PiBTZW50OiAwNyBTZXB0ZW1iZXIgMjAxOCAx MzowOA0KPj4+Pj4gVG86IEFyYXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3 ZWkuY29tPG1haWx0bzphcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPj4NCj4+Pj4+IENjOiBU b20gSGVyYmVydCA8dG9tQHF1YW50b25pdW0ubmV0PG1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQ+ PjsgdGEtbWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDxtYWlsdG86dGEtbWl5YXNha2FAa2RkaS1y ZXNlYXJjaC5qcD47DQo+Pj4+PiBkbW0gPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3Jn Pj4NCj4+Pj4+IFN1YmplY3Q6IFJlOiBbRE1NXSBDb21tZW50cyB0byBkcmFmdC1obW0tZG1tLTVn LXVwbGFuZS1hbmFseXNpcy0wMQ0KPj4+Pj4NCj4+Pj4+IEkgdGhpbmsgeW914oCZbGwgc3RpbGwg aGF2ZSB0aGUgUEhCIHJlLW1hcmtpbmcgaXNzdWVzIEkgbWVudGlvbmVkIGluDQo+Pj4+PiBwcmV2 aW91cyBlbWFpbHMuIFRoZSBxdWVzdGlvbiBpcywgc2hvdWxkIHRoZSBuZXR3b3JrIHRvdWNoL2No YW5nZQ0KPj4+Pj4gYW55IGhlYWRlciBiaXRzIG9mIHRoZSBwYWNrZXQgdGhlIHNvdXJjZSBoYXMg YnVpbHQuIFRoZSBhbnN3ZXINCj4+Pj4+IHNob3VsZCBwcm9iYWJseSBiZSBuby4NCj4+Pj4+DQo+ Pj4+PiBIYXZpbmcgc2FpZCB0aGF0LCBHVFAgZGlkIGl0IHRoZSByaWdodCB3YXksIGV2ZW4gdGhv dWdoIGl0IGNvc3QgaW4NCj4+Pj4+IGhlYWRlciBsZW5ndGguDQo+Pj4+Pg0KPj4+Pj4gRGlubw0K Pj4+Pj4NCj4+Pj4+PiBPbiBTZXAgNywgMjAxOCwgYXQgODoyNiBBTSwgQXJhc2htaWQgQWtoYXZh aW4NCj4+Pj4+IDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPG1haWx0bzphcmFzaG1pZC5h a2hhdmFpbkBodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBDb3JyZWN0LCBmbG93 IGxhYmVscyBjYW4gY2hhbmdlIGFsb25nIHRoZSBwYXRoLiBUaGF0J3Mgd2h5IEkgbGlrZQ0KPj4+ Pj4+IHRoZSBzbGljaW5nDQo+Pj4+PiBjb25jZXB0Lg0KPj4+Pj4+IFVFcyBjYW4gcmVxdWVzdCBz ZXJ2aWNlcyB3aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVzLCBvcGVyYXRvcnMNCj4+Pj4+PiBjb250 cm9sIGhvdw0KPj4+Pj4gc2VydmljZSByZXF1ZXN0IGFyZSBtYXBwZWQgaW50byBzbGljZXMuIEkg c2hvdWxkIGxvb2sgaW50byB0aGUgYWlyDQo+Pj4+PiBzaWRlIG9mIHRoZSBidXNpbmVzcyBhbmQg c2VlIHdoYXQgaGFwcGVucyB0aGVyZS4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogVG9tIEhlcmJlcnQgW21h aWx0bzp0b21AcXVhbnRvbml1bS5uZXQ8bWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldD5dDQo+Pj4+ Pj4+IFNlbnQ6IDA3IFNlcHRlbWJlciAyMDE4IDExOjEzDQo+Pj4+Pj4+IFRvOiBBcmFzaG1pZCBB a2hhdmFpbiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbTxtYWlsdG86YXJhc2htaWQuYWto YXZhaW5AaHVhd2VpLmNvbT4+DQo+Pj4+Pj4+IENjOiBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2Np QGdtYWlsLmNvbTxtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbT4+Ow0KPj4+Pj4+PiB0YS1taXlh c2FrYUBrZGRpLXJlc2VhcmNoLmpwPG1haWx0bzp0YS1taXlhc2FrYUBrZGRpLXJlc2VhcmNoLmpw PjsgZG1tIDxkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+DQo+Pj4+Pj4+IFN1Ympl Y3Q6IFJlOiBbRE1NXSBDb21tZW50cyB0bw0KPj4+Pj4+PiBkcmFmdC1obW0tZG1tLTVnLXVwbGFu ZS1hbmFseXNpcy0wMQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiBGcmksIFNlcCA3LCAyMDE4IGF0IDg6 MDEgQU0sIEFyYXNobWlkIEFraGF2YWluDQo+Pj4+Pj4+IDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3 ZWkuY29tPG1haWx0bzphcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuLmNvbT4+IHdyb3RlOg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+Pj4+PiBGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb208 bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+XQ0KPj4+Pj4+Pj4+IFNlbnQ6IDA2IFNlcHRlbWJl ciAyMDE4IDE4OjU5DQo+Pj4+Pj4+Pj4gVG86IEFyYXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5h a2hhdmFpbkBodWF3ZWkuY29tPG1haWx0bzphcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPj4N Cj4+Pj4+Pj4+PiBDYzogVG9tIEhlcmJlcnQgPHRvbUBxdWFudG9uaXVtLm5ldDxtYWlsdG86dG9t QHF1YW50b25pdW0ubmV0Pj47IHRhLW1peWFzYWthQGtkZGktDQo+Pj4+PiByZXNlYXJjaC5qcDxo dHRwOi8vcmVzZWFyY2guanA+Ow0KPj4+Pj4+Pj4+IGRtbSA8ZG1tQGlldGYub3JnPG1haWx0bzpk bW1AaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbRE1NXSBDb21tZW50cyB0bw0K Pj4+Pj4+Pj4+IGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLQ0KPj4+Pj4gMDENCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBEaW5vIGJyb3VnaHQgdXAgYSBnb29kIHBvaW50LiBIZXJlIGlz IG15IHR3byBjZW50cyB3b3J0aDoNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE5vdCBzdXJlIHdoaWNo IHBvaW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFzIGl0IHdhcyBleHBsYWluZWQgYnkgU3Jp ZGhhciwgIGVhY2ggVUUgY2FuIGhhdmUgbXVsdGlwbGUNCj4+Pj4+Pj4+Pj4gY29udGV4dHMuIEZv cg0KPj4+Pj4+Pj4+IGV4YW1wbGUsIHRvZGF5IHNvbWUgb3BlcmF0b3JzIHByb3ZpZGUgRGF0YSBh bmQgVm9MVEUgc2VydmljZSB0bw0KPj4+Pj4+Pj4+IHRoZWlyIGN1c3RvbWVycy4gVGhlc2UgdHdv IHNlcnZpY2VzIGFyZSByZXByZXNlbnRlZCBieSBzZXBhcmF0ZQ0KPj4+Pj4+Pj4+IEdUUCB0dW5u ZWxzIGluIHRoZSBjb3JlIHdpdGggZWFjaCB0dW5uZWwgdGllZCB1cCB0byBhIHBhcnRpY3VsYXIg UW9TLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJUHY0IGRpZG4ndCBmaXQgdGhlIGJpbGwgd2hl biBHVFAgd29yayB3YXMgdW5kZXIgd2F5IGFzIGl0DQo+Pj4+Pj4+Pj4+IGNvdWxkbid0IHVuaXF1 ZWx5IGlkZW50aWZ5IG11bHRpcGxlIFVFDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGVyZSBpcyBu byByZWFzb24gd2h5IGl0IHNob3VsZG7igJl0LiBBbmQgSVB2NiwgZm9yIHRoaXMNCj4+Pj4+Pj4+ PiB1c2UtY2FzZSBkb2VzbuKAmXQgYWRkIGFueXRoaW5nIG5ldyBvdGhlciB0aGFuIGEgMjggYml0 DQo+Pj4+Pj4+Pj4gdHJhZmZpYy1jbGFzcy9mbG93LWxhYmVsIHRoYXQgY2FuIHByb3ZpZGUgbW9y ZSBiaXRzIGZvciDigJxuZXcNCj4+Pj4+IGZ1bmN0aW9uYWxpdHnigJ0uDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IFtBcmFzaG1pZF0gIEFuZCB0aGF0J3Mgd2hhdCBJIG1lYW50LiBIYXZp bmcgYSBmbG93IGxhYmVsIGlzIGhhbmR5Lg0KPj4+Pj4+Pj4gV2UgY2FuIHBlcmhhcHMgdXNlIGl0 IHRvIGlkZW50aWZ5IGRpZmZlcmVudCBVRSBzZXNzaW9ucy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+IENh cmVmdWwgaWYgeW91IHVzZSB0aGUgZmxvdyBsYWJlbCB0byBpZGVudGlmeSBmbG93cy4gSXQgc2hv dWxkIGJlDQo+Pj4+Pj4+IGNvbnNpZGVyZWQgInNvZnQgaWRlbnRpZmljYXRpb24iIHNpbmNlIGl0 IG1pZ2h0IG5vdCBhbHdheXMgYmUNCj4+Pj4+Pj4gY29ycmVjdCAoaXQgY2FuIGJlIGNoYW5nZWQg ZW4gcm91dGUsIGlzbid0IHByb3RlY3RlZCBieSBhbnkNCj4+Pj4+Pj4gY2hlY2tzdW0sIGFueW9u ZSBjYW4gc2V0IGl0IGhvd2V2ZXIgdGhleSB3YW50LCBldGMuKS4gSXQncyB1c2VmdWwNCj4+Pj4+ Pj4gZm9yIHRoaW5ncyBsaWtlIEVDTVAgdGhhdCBkb24ndCByZXF1aXJlIDEwMCUgYWNjdXJhY3kg aW4NCj4+Pj4+Pj4gaWRlbnRpZnlpbmcgZmxvdy4gVGhlIGZsb3cgbGFiZWwgd2FzIGJyaWVmbHkg Y29uc2lkZXJlZCBmb3INCj4+Pj4+Pj4gaG9sZGluZyBWTklzIGluIG5ldHdvcmsgdmlydHVhbGl6 YXRpb24sIGJ1dCB3ZQ0KPj4+Pj4gdGFsa2VkIHRoZW0gb3V0IG9mIHRoYXQuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFRvbQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IHNlc3Npb25zL2NvbnRl eHQvYmVhcmVyLiBTbywgR1RQIGFuZCBURUlEIGRpZCB0aGUgam9iLiBCdXQgSQ0KPj4+Pj4+Pj4+ PiBhZ3JlZSB3aXRoDQo+Pj4+Pj4+Pj4gRGlubyB0aGF0IElQdjYgaXMgbXVjaCBtb3JlIHZlcnNh dGlsZSBhbmQgaXMgZGVmaW5pdGVseSB3b3J0aA0KPj4+Pj4+Pj4+IGxvb2tpbmcgYXQgYXMgYW4g YWx0ZXJuYXRpdmUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCB3aGF0IEkgc2Fp ZC4gSSBzYWlkIOKAnElQIGNvdWxkIGhhdmUgc29sdmVkIHRoaXMNCj4+Pj4+Pj4+PiBwcm9ibGVt 4oCdLiBBbmQNCj4+Pj4+IOKAnElQ4oCdDQo+Pj4+Pj4+Pj4gbWVhbnMgZWl0aGVyIElQdjQgb3Ig SVB2Niwgb3IgYm90aCBhdCB0aGUgc2FtZSB0aW1lLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBbQXJhc2htaWRdDQo+Pj4+Pj4+PiBIb3cgd291bGQgd2UgZW1wbG95IElQdjQgdG8gZGlz dGluZ3Vpc2ggYmV0d2VlbiBkaWZmZXJlbnQgVUUNCj4+Pj4+Pj4+IHNlc3Npb25zLg0KPj4+Pj4+ PiBUT1M/DQo+Pj4+Pj4+PiBPciB5b3UgbWVhbiB1c2luZyBlbmNhcHN1bGF0aW9uPw0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBIGZhY3RvciB3b3J0aCBjb25zaWRlcmluZyB0aG91 Z2ggaXMgdGhhdCB0aGUgdXNlIG9mIEdUUCBhbmQNCj4+Pj4+Pj4+Pj4gVEVJRCBpbiBtb2JpbGUN Cj4+Pj4+Pj4+PiBjb3JlIGFsbG93cyBvcGVyYXRvcnMgdG8gZGVhbCB3aXRoIFFvUyBvbiB0aGVp ciBvd24gdGVybXMuIFRoZQ0KPj4+Pj4+Pj4+IHR1bm5lbHMgd2l0aCBzcGVjaWZpYyBvcGVyYXRv ci1jb250cm9sbGVkIFFvUyBhcmUgZXN0YWJsaXNoZWQNCj4+Pj4+Pj4+PiBieSB0aGUgY29udHJv bCBwbGFuZSBiZXR3ZWVuIGVOQiwgU0dXLCBhbmQgUEdXLiBVRXMgb3INCj4+Pj4+Pj4+PiBhcHBs aWNhdGlvbnMgc2l0dGluZyBpbiB0aGUgVUVzIGhhdmUgbm8gc2F5IGluIHRoaXMuIFdlbGwgYXQN Cj4+Pj4+Pj4+PiBsZWFzdCB0aWxsIHRoZSBwYWNrZXQgZXhpdHMgb3BlcmF0b3Incw0KPj4+Pj4+ PiBuZXR3b3JrLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIHByb2JsZW0gd2l0aCBvbmUgaGVh ZGVyLCBpcyB0aGF0IGlmIHlvdSByZS1tYXJrIChrbm93biBhcw0KPj4+Pj4+Pj4+IFBIQiBtYXJr aWduIGluIHRoZSBvbGUgZGF5cykgeW91IGxvc2UgdGhlIG9yaWdpbmFsIHZhbHVlLg0KPj4+Pj4+ Pj4+IEVuY2Fwc3VsYXRpb24gaXMgdXNlZnVsIGhlcmUgYmVjYXVzZSB5b3UgY2FuIG1hcCB0aGUg aW5uZXIgdG8NCj4+Pj4+Pj4+PiBvdXRlciBhbmQgYW55d2hlcmUgYWxvbmcgdGhlIHBhdGggeW91 IGNhbiBQSEIgcmVtYXJrIG9uIHRoZQ0KPj4+Pj4+Pj4+IG91dGVyIGhlYWRlci4gQW5kIHRoZW4g dGhlIGRlc3RpbmF0aW9uIGNhbiBzZWUgdGhlIG9yaWduYWwNCj4+Pj4+Pj4+PiBzb3VyY2XigJlz IFRvUy9Rb1MvVEMvZmxvdy1sYWJlbA0KPj4+Pj4gd2hhdGV2ZXIuDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IFtBcmFzaG1pZF0gWWVzLCBJIGFncmVlLiBUaGUgb3JpZ2luYWwgdmFsdWUg aXMgbG9zdCB3aXRoIFBIQi4NCj4+Pj4+Pj4+IEVuY2Fwc3VsYXRpb24gY2VydGFpbmx5IG1ha2Vz IHRoaW5ncyBlYXNpZXIgYW5kIHRoZSBpbm5lciB0bw0KPj4+Pj4+Pj4gb3V0ZXIgbWFwcGluZyB0 cmljayBoYXMgYmVlbiB3aWRlbHkgdXNlZCBpbiBJUCBhbmQgTVBMUyhtdWx0aXBsZQ0KPj4+Pj4+ Pj4gbGFiZWxzIGxpa2Ugc2VydmljZSBhbmQgdHJhbnNwb3J0KQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBVc2luZyB0aGUgaW5mb3JtYXRpb24gaW4gVUUncyBJUCBwYWNrZXQgaGVh ZGVyIGNhbiBqZW9wYXJkaXNlDQo+Pj4+Pj4+Pj4+IHRoZSBhYm92ZSB0aWdodCBRb1MgY29udHJv bC4gSSB0aGluayBnb2luZw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTm90IGlmIHlvdSBlbmNhcHN1 bGF0ZS4gQnV0IG5vdGUgd2l0aCBTUnY2LCB5b3UgY2FuIHBvc3NpYmx5DQo+Pj4+Pj4+Pj4gcmV0 YWluIHRoZSBvcmlnaW5hbCBmbG93LWxhYmVsIGlmIHRoZSBTSUQgY2FuIHJldGFpbiB0aG9zZSBi aXRzDQo+Pj4+Pj4+Pj4gYmVmb3JlIG92ZXJ3cml0aW5nIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNz IGZyb20gdGhlIG9wdGlvbuKAmXMgdmFsdWUuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gW0FyYXNobWlk XSBBZ3JlZS4gRW5jYXBzdWxhdGlvbiBkb2VzIHRoZSB0cmljayBhZ2Fpbi4gVGhhdCdzIHdoeQ0K Pj4+Pj4+Pj4gR1RQIGhhcyB3b3JrZWQgd2VsbCBhbmQgc2VydmVkIHRoZSBwdXJwb3MgaW4gdGhl IG1vYmlsZQ0KPj4+Pj4+Pj4gYmFjay1oYXVsIHNvIGZhci4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBEaW5vDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gZG93biB0aGlzIHBhdGgsIG9w ZXJhdG9ycyBuZWVkIHByb29mIHRoYXQgdGhleSB3aWxsIGJlIHN0aWxsDQo+Pj4+Pj4+Pj4+IGlu IHRoZSBkcml2aW5nDQo+Pj4+Pj4+Pj4gc2VhdCBhbmQgUW9TIGNhbm5vdCBiZSBkaWN0YXRlZC90 YW1wZXJlZCBieSB0aGUgVUUgb3IgYW55DQo+Pj4+Pj4+Pj4gYXBwbGljYXRpb24gcnVubmluZyBp biBpdC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gTm93LCBoZXJlIGlzIGFuIGludGVyZXN0aW5n IHF1ZXN0aW9uIGZvciB0aGUgb3BlcmF0b3JzLiBXb3VsZA0KPj4+Pj4+Pj4+PiBhbnkgb3BlcmF0 b3INCj4+Pj4+Pj4+PiBiZSBpbnRlcmVzdGVkIGluIGFsbG93aW5nIFFvUyAgdG8gYmUgc2V0IGJ5 IHRoZSBVRSBvciBieQ0KPj4+Pj4+Pj4+IGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIHRoZSBVRSBh bmQgY2hhcmdlZCBmb3IgYnkgdGhlIG5ldHdvcms/DQo+Pj4+Pj4+Pj4gIlllcyIgY291bGQgcG90 ZW50aWFsbHkgaW1wbHkgaW1wYWN0cyBvbiB0aGUgYWlyIGludGVyZmFjZSwgVUUNCj4+Pj4+Pj4+ PiByZXNvdXJjZSBibG9jayBhbGxvY2F0aW9uIGFuZCBjYW4gbWFrZSBzY2hlZHVsaW5nIG9uIHRo ZSBSQU4NCj4+Pj4+Pj4+PiBzaWRlDQo+Pj4+PiBtdWNoIG1vcmUgY29tcGxleC4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gQXJhc2htaWQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+PiBGcm9tOiBkbW0gW21h aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgRGlubw0KPj4+Pj4+Pj4+Pj4gRmFyaW5hY2NpDQo+Pj4+Pj4+Pj4+PiBTZW50 OiAwNiBTZXB0ZW1iZXIgMjAxOCAxMjo0NQ0KPj4+Pj4+Pj4+Pj4gVG86IFRvbSBIZXJiZXJ0IDx0 b21AcXVhbnRvbml1bS5uZXQ8bWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldD4+DQo+Pj4+Pj4+Pj4+ PiBDYzogdGEtbWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDxtYWlsdG86dGEtbWl5YXNha2FAa2Rk aS1yZXNlYXJjaC5qcD47IGRtbSA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+Pg0K Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0t NWctdXBsYW5lLQ0KPj4+Pj4gYW5hbHlzaXMtDQo+Pj4+Pj4+IDAxDQo+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+IEJlaGNldCwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEkgd2FzIHRoaW5r aW5nIGlmIFRFSUQgaXMgbmVlZCB0aGVuIHRoYXQgY2FuIGJlIGVuY29kZWQgaW4gYQ0KPj4+Pj4+ Pj4+Pj4+IGxvY2F0b3IgZWFzaWx5IGVub3VnaC4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ IFRvbQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IE5vdCBpZiBhIGxvY2F0b3IgaXMgYSBQR1cg dGhhdCBpcyBzaGFyZWQgYnkgbWFueSBVRXMuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gM0dQ UCB3YW50cyBwZXIgYmVhcmVyIGF3YXJlbmVzcyBzbyB0aGV5IG5lZWQgYSBzcGVjaWZpYyBJRCwN Cj4+Pj4+Pj4+Pj4+IHRoYXQgY291bGQgaGF2ZSBiZWVuIHRoZSBVReKAmXMgSVAgYWRkcmVzcy4g QW5kIHdpdGggSVB2NiBpdA0KPj4+Pj4+Pj4+Pj4gY2FuIGJlIHVuaXF1ZSBhbmQgbm90IHRoZSBp c3N1ZSB0aGF0IFNyaWRoYXIgYnJvdWdodCB1cC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJ ZiBJTEEgd2FzIGluIHVzZSwganVzdCB1c2UgdGhlIElMQS1JRCBmb3IgdGhpcyBwdXJwb3NlLg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IERpbm8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+ Pj4gZG1tIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4gZG1tQGlldGYub3JnPG1haWx0bzpkbW1A aWV0Zi5vcmc+DQo+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RtbQ0KPj4+Pj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPj4+IGRtbUBp ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1tDQo+Pj4NCj4+DQo+Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBp ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K Pg0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTaHVuc3VrZSBI b21tYQ0KPGhvbW1hLi5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPG1haWx0bzpob21tYS5zaHVuc3Vr ZUBsYWIubnR0LmNvLmpwPj4NClRFTDogKzgxIDQyMiA1OSAzNDg2DQpGQVg6ICs4MSA0MjIgNjAg NzQ2MA0KDQpOVFQgTmV0d29yayBTZXJ2aWNlIFN5c3RlbXMgTGFicy4NCk11c2FzaGlubyBjaXR5 LCBUb2t5bywgSmFwYW4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5n IGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg== --_000_D57109449177B54F8B9C093953AC5BCD755E4D4Byyzeml704chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IG5l Y2Vzc2FyaWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91 IGFyZSBjb3JyZWN0IGluIHRoYXQgUEdXIGlzIGEgVVBGLCBidXQgYSBVUEYgaXMgYnkgbm8gbWVh bnMgbGltaXRlZCB0byBQR1cuIEEgVVBGIGlzIGFueSBmdW5jdGlvbiB0aGF0IGNhbiBiZSBleGVj dXRlZCBvbiB1c2VyIHRyYWZmaWMgaW4gbW9iaWxlIG5ldHdvcmsuIEhhdmluZw0KIHNhaWQgdGhh dCBob3dldmVyLCBJIHRoaW5rIHRoZSBmaXJzdCBVUEZzIHRoYXQgd2Ugd2lsbCBzZWUgd2lsbCBi ZSBpbiB0aGUgZm9ybSBvZiBTR1csIFBHVy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkFyYXNobWlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZWhjZXQgU2FyaWtheWE8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxOCAxMTo0NCBBTTxicj4NCjxiPlRvOjwvYj4g U2h1bnN1a2UgSG9tbWEgJmx0O2hvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanAmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBkbW0gJmx0O2RtbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAx PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VVBGIGlzIHZpcnR1YWxpemVk IFBHVywgZm9sa3MuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hpbGUgUEdXIGlzIGZpeGVkIGluIGxvY2F0aW9uIGFuZCBwb3NzaWJseSBzZXJ2aW5nIGEgbGFy Z2UgbnVtYmVyIG9mIFVFIHdoaWNoIGFyZSBnZW9ncmFwaGljYWxseSBpbiB0aGUgYXJlYSwgdGhh dCBwYXJ0IG9mIHRoZSBjaXR5IGFuZCB0aGF0IGNpdHkgaXRzZWxmLCBVUEYgY2FuIGJlIGRlcGxv eWVkIGNsb3NlciB0byB0aGUgVUUgYW5kIHRodXMgcHJvYmFibHkgc2VydmluZyBzbWFsbGVyIG51 bWJlciBvZg0KIFVFczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CZWhjZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMSwgMjAxOCBhdCAxMDo0NyBQTSBTaHVuc3VrZSBI b21tYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanAiPmhv bW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgRGFyayBmb3IgeW91ciBleHBsYWluaW5nIHdo YXQgaXMgVVBGIGluc3RlYWQgb2YgbWUuPGJyPg0KPGJyPg0KQWxleCwgYnJpZWYgZGVmaW5pdGlv bnMgb2YgVVBGIGFyZSBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24gNC4xLjEuMSBvZiA8YnI+DQp0 aGlzIGRyYWZ0LiBBbHNvLCB5b3UgY2FuIGZpbmQgbW9yZSBkZXRhaWxzIGluIDNHUFAgVFMyMy41 MDEuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpTaHVuc3VrZTxicj4NCjxicj4NCk9u IDIwMTgvMTAvMDEgMjA6MzIsIDxhIGhyZWY9Im1haWx0bzpEaXJrLnZvbi1IdWdvQHRlbGVrb20u ZGUiIHRhcmdldD0iX2JsYW5rIj5EaXJrLnZvbi1IdWdvQHRlbGVrb20uZGU8L2E+IHdyb3RlOjxi cj4NCiZndDsgSGkgQWxleCw8YnI+DQomZ3Q7IGFuZCBzb3JyeSBmb3IganVtcGluZyBpbnRvIHRo ZSBkaXNjdXNzaW9uLi4uPGJyPg0KJmd0OyZuYnNwOyBGcm9tIG15IGFuZCAoQUZBSUspIDNHUFBz IHVuZGVyc3RhbmRpbmcgeW91ciBzbWFydHBob25lIGlzIGEgVUUgLSBzaXR0aW5nIG9uIHRoZSBv dGhlciBzaWRlIG9mIFJBTiAoZ05CKSAtIHdoZXJlYXMgYSBVUEYgbm9ybWFsbHkgaXMgc2VlbiBh cyBVUCBlbnRyeSAoYW5kIGV4aXQpIG9mIHRoZSA1RyBjb3JlIChpLmUuIGhhbmRsaW5nIGFsbCBV UCB0cmFmZmljIGluIGEgdHJ1ZSBDUC9VUCBzcGxpdCBmYXNoaW9uKS48YnI+DQomZ3Q7IEFueSBv dGhlciBpZGVhcyBvbiB0aGlzPyBDYW4gc29tZW9uZSBpbWFnaW5lIGFueSBzY2VuYXJpbyB3aGVy ZSBVRSBpbXBsZW1lbnRzIFVQRj88YnI+DQomZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7IEJlc3QgUmVn YXJkczxicj4NCiZndDsgRGlyazxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogZG1tIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRt bS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1PGJyPg0KJmd0OyBTZW50OiBNb250 YWcsIDEuIE9rdG9iZXIgMjAxOCAxMzoyMjxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpk bW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBT dWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5h bHlzaXMtMDE8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExlIDAx LzEwLzIwMTggw6AgMDU6NTAsIFNodW5zdWtlIEhvbW1hIGEgw6ljcml0Jm5ic3A7Ojxicj4NCiZn dDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0OyAjIFNvcnJ5IGZvciBteSBsYXRlIHJlc3BvbnNl Li4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIHlvdXIgbGl2ZWx5 IGRpc2N1c3Npb24uIEl0IGlzIHZlcnkgaGVscGZ1bCBmb3I8YnI+DQomZ3Q7Jmd0OyB1bmRlcnN0 YW5kaW5nIHBvaW50cyB3aGljaCBuZWVkIHN1cHBsZW1lbnRhbCBleHBsYW5hdGlvbiBhbmQgbW9y ZTxicj4NCiZndDsmZ3Q7IGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24sIHdlJ3JlIHBsYW5uaW5nIHRvIHVwZGF0ZSB0aGUg SS1EIGZvcjxicj4NCiZndDsmZ3Q7IGNvdmVyaW5nIHRoZSBwb2ludHMgYmVsb3c6PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAtIHRlcm1pbmF0aW9uIHBvaW50cyBvZiBHVFAtVTxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyAoUkFOcyBhbmQgVVBGcyB0ZXJtaW5hdGUgR1RQLVUg aW4gNUdTLik8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hhdCBpcyBVUEY/PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEkgdW5kZXJzdGFuZCBVUEYgc3RhbmRzIGZvciBVc2VyLVBsYW5lIEZ1bmN0aW9uLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBJcyBteSBzbWFydHBob25lIHN1cHBvc2VkIHRvIGltcGxlbWVu dCBVUEY/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsZXg8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7 IC0gc2V0dGluZyBRb1MgcGFyYW1ldGVyIG9mIG91dGVyIElQIGhlYWRlcjxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyZuYnNwOyAoTm90ZSB0aGF0IGl0J3Mgbm90IGp1c3QgY29weSBvZiBpbm5l ciB0byBvdXRlci4pPGJyPg0KJmd0OyZndDsgLSBwcm9ibGVtcyByZWxhdGVkIHRvIElQIGNvbm5l Y3Rpdml0eSAoZS5nLiwgTVRVIGluIElQdjYgbmV0d29ya3MsPGJyPg0KJmd0OyZndDsgSVB2NCBh ZGRyZXNzIGR1cGxpY2F0aW9uKTxicj4NCiZndDsmZ3Q7IC0gc3VtbWFyeSBvZiBuZXR3b3JrIHNs aWNpbmcgaW4gNUdTPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IChFLmcuLCAmcXVv dDtzbGljZSBpcyBjb21wb3NlZCBvZiBTTUYgYW5kIFVQRnMuIEFNRiBzZWxlY3RzIFNNRjxicj4N CiZndDsmZ3Q7IGRlcGVuZGluZyBvbiBOU1NBSSBzZW50IGZyb20gVUUsIGFuZCBTTUYgaW5kaWNh dGVzIHRvIHRoZSBVRSB0aGUgVVBGPGJyPg0KJmd0OyZndDsgdGhhdCBpdCBpczxicj4NCiZndDsm Z3Q7IGFsbG9jYXRlZC4mcXVvdDspPGJyPg0KJmd0OyZndDsgLSBjYXNlIHN0dWRpZXMgb24gVVBG IHNlbGVjdGlvbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyAoRS5nLiwgcGFyYW1l dGVycyB1c2VkIGZvciBkZWNpZGluZyBkZXN0aW5hdGlvbiBVUEYpICMgT3B0aW1pemluZzxicj4N CiZndDsmZ3Q7IGZvcndhcmRpbmcgcGF0aHMgc29sdXRpb24gbWlnaHQgYmUgcmVhbGl6ZWQgd2l0 aCBVUEYgc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgbWVjaGFuaXNtIGluIDNHUFAgYXJjaGl0ZWN0 dXJlLiAoSUQtTE9DIG1heSBiZSBhcHBsaWVkIGFzIHN1Y2g8YnI+DQomZ3Q7Jmd0OyBtZWNoYW5p c20uKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiB5b3UgaGF2 ZSBhbnkgcmVxdWVzdCBmb3IgdXMgb24gdGhpcyB1cGRhdGluZywgcGxlYXNlIGxldCB1cyBrbm93 Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgU2h1bnN1a2U8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDIw MTgvMDkvMDggMzoyOCwgRGlubyBGYXJpbmFjY2kgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBJIHVuZGVyc3RhbmQgeW91ciBwb2ludCwgYnV0IHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBmb3Ig YSBwcmVjaXNlIFFvUzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91dCB1c2luZyBzb21lIHNv cnQgb2YgZW5jYXBzdWxhdGlvbiBiZWluZyBpdCBHVFAsIFJTVlAsIGV0Yy48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEV2ZW4gd2l0aCB0dW5uZWxzLCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCBh bGwgbm9kZXMgYWxvbmcgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIGhhdmUgdGhlIHNh bWUgaGFyZHdhcmUgY2FwYWJpbGl0eSBhbmQgY2FuIHByb3ZpZGUgdGhlIHNhbWUgUW9TPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyB0cmVhdG1lbnQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IFRoZXJlIGlzIGV4aXN0aW5nIGhhcmR3YXJlIHdoZXJlIHRoZSBlbmNhcHN1bGF0b3Ig Y29waWVzIGlubmVyIFFvUyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyBvdXRlciBRb1MuIEFsbCByb3V0 ZXJzIGFsb25nIHRoZSBwYXRoIGp1c3QgcHJvY2VzcyB0aGUgb3V0ZXIgUW9TLCBubzxicj4NCiZn dDsmZ3Q7Jmd0OyBjaGFuZ2VzIHRvIG9yIG5ldyBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cyBmb3Ig dGhlbS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBleGFtcGxl LCB0aGUgY29kZSBwb2ludHMgaW4gcm91dGVycyBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdG88YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvcnJlY3RseSBoYW5kbGUgdGhlIEVYUCBiaXRzIGluIE1QTFMg bGFiZWxzLiBCdXQgdGhlcmUgaXMgbm88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGd1YXJhbnRlZSB0 aGF0IGFsbCByb3V0ZXJzIGNhbiBzdXBwb3J0IGFsbCB2YWx1ZXMuIFRoZSBFWFAgdmFsdWVzPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBnZXQgbWFwcGVkIHRvIGNvZGUgcG9pbnRzIGJ1dCB0aGUgbWFw cGluZyBpcyBub3QgYWx3YXlzIG9uZSB0byBvbmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAzLWJp dCBFWFBzIGNhbiBtYXAgdG8gNCBjb2RlIHBvaW50cyBvbiB0aG9zZSByb3V0ZXJzIHdpdGggbGVz czxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgY2FwYWJsZSBIL1cuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IFRoYXQgaXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBtYXR0ZXIuIFRo ZSBkaXNjdXNzaW9uIGlzIGFib3V0PGJyPg0KJmd0OyZndDsmZ3Q7IHJlbWFya2luZy4gQW5kIGlm IG9uZSByZW1hcmtzIHRvIHdoYXQgdGhlIHBhdGggY2Fubm90IHN1cHBvcnQsIHdlbGw8YnI+DQom Z3Q7Jmd0OyZndDsgdGhpbmdzIGRvbuKAmXQgd29yayBhcyBleHBlY3RlZC48YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNsaWNpbmcgaXMgYWxtb3N0IHRoZSBzYW1lLiBJ dCBhbGxvd3MgdXNlciB0cmFmZmljIHRvIGJlIG1hcHBlZCB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgd2hhdCB0aGUgb3BlcmF0b3IgcHJvdmlkZXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGFn cmVlIHdpdGggeW91IHRoYXQgbmV0d29yayBzaG91bGQgbm90IHRvdWNoL2NoYW5nZSBvcmlnaW5h bDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaGVhZGVyIGJpdHMuIEdUUCBvciBhbnkgb3RoZXIgZW5j YXBzdWxhdGlvbiBlYXNpbHkgYWxsb3cgZm9yIHRoaXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBU aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBjYW4gcHJvdmlkZSBmb3IgdGhpcyB3aXRob3V0IHVz aW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBlbmNhcHN1bGF0aW9uLiBJUHY2IG1pZ2h0IGJlIHRo ZSBhbnN3ZXIuIEJ1dCBhcyBUb20gcG9pbnRlZCBvdXQsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBm bG93IGxhYmVscyBjYW4gc3RpbGwgY2hhbmdlIGluIHRoZSBtaWRkbGUuIElzIHRoZXJlIGFueSBy b29tIGZvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaW1wcm92ZW1lbnQuIFNJRHMgbWlnaHQgcHJl c2VudCBhbiBvcHBvcnR1bml0eS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg Tm90IGlmIHRoZXkgYXJlIGVuY2Fwc3VsYXRlZCBhbmQgcm91dGVycyBkb27igJl0IHRvdWNoIHBh Y2tldHMgaW5zaWRlLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBEaW5vPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IERpbm8gRmFyaW5hY2NpIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5mYXJpbmFjY2lAZ21haWwuY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50 OiAwNyBTZXB0ZW1iZXIgMjAxOCAxMzowODxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBB cmFzaG1pZCBBa2hhdmFpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyYXNobWlkLmFraGF2YWluQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5hcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPC9h PiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogVG9tIEhlcmJlcnQgJmx0OzxhIGhy ZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQiIHRhcmdldD0iX2JsYW5rIj50b21AcXVhbnRv bml1bS5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzp0YS1taXlhc2FrYUBrZGRpLXJlc2Vh cmNoLmpwIiB0YXJnZXQ9Il9ibGFuayI+dGEtbWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDwvYT47 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG1tICZsdDs8YSBocmVmPSJtYWlsdG86ZG1tQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRt bS01Zy11cGxhbmUtYW5hbHlzaXMtMDE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgeW914oCZbGwgc3RpbGwgaGF2ZSB0aGUgUEhCIHJl LW1hcmtpbmcgaXNzdWVzIEkgbWVudGlvbmVkIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg cHJldmlvdXMgZW1haWxzLiBUaGUgcXVlc3Rpb24gaXMsIHNob3VsZCB0aGUgbmV0d29yayB0b3Vj aC9jaGFuZ2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnkgaGVhZGVyIGJpdHMgb2YgdGhl IHBhY2tldCB0aGUgc291cmNlIGhhcyBidWlsdC4gVGhlIGFuc3dlcjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHNob3VsZCBwcm9iYWJseSBiZSBuby48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEdUUCBkaWQgaXQg dGhlIHJpZ2h0IHdheSwgZXZlbiB0aG91Z2ggaXQgY29zdCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGhlYWRlciBsZW5ndGguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBEaW5vPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gU2VwIDcsIDIwMTgsIGF0IDg6MjYgQU0sIEFyYXNobWlk IEFraGF2YWluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzph cmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXJhc2htaWQuYWto YXZhaW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDb3JyZWN0LCBmbG93IGxhYmVscyBj YW4gY2hhbmdlIGFsb25nIHRoZSBwYXRoLiBUaGF0J3Mgd2h5IEkgbGlrZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc2xpY2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNv bmNlcHQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVFcyBjYW4gcmVxdWVzdCBzZXJ2 aWNlcyB3aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVzLCBvcGVyYXRvcnM8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgY29udHJvbCBob3c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2 aWNlIHJlcXVlc3QgYXJlIG1hcHBlZCBpbnRvIHNsaWNlcy4gSSBzaG91bGQgbG9vayBpbnRvIHRo ZSBhaXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzaWRlIG9mIHRoZSBidXNpbmVzcyBhbmQg c2VlIHdoYXQgaGFwcGVucyB0aGVyZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBUb20gSGVyYmVydCBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQiIHRhcmdldD0iX2JsYW5r Ij50b21AcXVhbnRvbml1bS5uZXQ8L2E+XTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgU2VudDogMDcgU2VwdGVtYmVyIDIwMTggMTE6MTM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRvOiBBcmFzaG1pZCBBa2hhdmFpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyYXNo bWlkLmFraGF2YWluQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5hcmFzaG1pZC5ha2hhdmFp bkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENj OiBEaW5vIEZhcmluYWNjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5mYXJpbmFjY2lAZ21haWwuY29tPC9hPiZndDs7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86dGEtbWl5YXNha2FAa2RkaS1y ZXNlYXJjaC5qcCIgdGFyZ2V0PSJfYmxhbmsiPnRhLW1peWFzYWthQGtkZGktcmVzZWFyY2guanA8 L2E+OyBkbW0gJmx0OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kbW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg U3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS1hbmFseXNpcy0wMTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9u IEZyaSwgU2VwIDcsIDIwMTggYXQgODowMSBBTSwgQXJhc2htaWQgQWtoYXZhaW48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXJhc2htaWQuYWto YXZhaW5AaHVhd2VpLi5jb20iIHRhcmdldD0iX2JsYW5rIj5hcmFzaG1pZC5ha2hhdmFpbkBodWF3 ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBEaW5vIEZhcmluYWNj aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IDA2IFNlcHRlbWJlciAyMDE4IDE4OjU5PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBcmFzaG1pZCBBa2hhdmFpbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj5hcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IFRvbSBIZXJiZXJ0ICZsdDs8YSBocmVmPSJt YWlsdG86dG9tQHF1YW50b25pdW0ubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9tQHF1YW50b25pdW0u bmV0PC9hPiZndDs7IHRhLW1peWFzYWthQGtkZGktPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cDovL3Jlc2VhcmNoLmpwIiB0YXJnZXQ9Il9ibGFuayI+cmVzZWFyY2guanA8 L2E+Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkbW0gJmx0Ozxh IGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogW0RNTV0gQ29tbWVudHMgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgMDE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpbm8gYnJvdWdo dCB1cCBhIGdvb2QgcG9pbnQuIEhlcmUgaXMgbXkgdHdvIGNlbnRzIHdvcnRoOjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBOb3Qgc3VyZSB3aGljaCBwb2ludC48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEFzIGl0IHdhcyBleHBsYWluZWQgYnkgU3JpZGhhciwmbmJzcDsgZWFjaCBV RSBjYW4gaGF2ZSBtdWx0aXBsZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY29udGV4dHMuIEZvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBleGFtcGxlLCB0b2RheSBzb21lIG9wZXJhdG9ycyBwcm92aWRlIERhdGEgYW5kIFZv TFRFIHNlcnZpY2UgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhlaXIgY3VzdG9tZXJzLiBUaGVzZSB0d28gc2VydmljZXMgYXJlIHJlcHJlc2VudGVkIGJ5IHNl cGFyYXRlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdUUCB0dW5u ZWxzIGluIHRoZSBjb3JlIHdpdGggZWFjaCB0dW5uZWwgdGllZCB1cCB0byBhIHBhcnRpY3VsYXIg UW9TLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElQdjQgZGlkbid0IGZpdCB0 aGUgYmlsbCB3aGVuIEdUUCB3b3JrIHdhcyB1bmRlciB3YXkgYXMgaXQ8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvdWxkbid0IHVuaXF1ZWx5IGlkZW50aWZ5 IG11bHRpcGxlIFVFPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIG5vIHJlYXNv biB3aHkgaXQgc2hvdWxkbuKAmXQuIEFuZCBJUHY2LCBmb3IgdGhpczxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1c2UtY2FzZSBkb2VzbuKAmXQgYWRkIGFueXRoaW5n IG5ldyBvdGhlciB0aGFuIGEgMjggYml0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRyYWZmaWMtY2xhc3MvZmxvdy1sYWJlbCB0aGF0IGNhbiBwcm92aWRlIG1vcmUg Yml0cyBmb3Ig4oCcbmV3PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25hbGl0eeKA nS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgW0FyYXNobWlkXSZuYnNwOyBBbmQgdGhhdCdzIHdoYXQgSSBtZWFudC4gSGF2aW5nIGEgZmxv dyBsYWJlbCBpcyBoYW5keS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBX ZSBjYW4gcGVyaGFwcyB1c2UgaXQgdG8gaWRlbnRpZnkgZGlmZmVyZW50IFVFIHNlc3Npb25zLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBDYXJlZnVsIGlmIHlvdSB1c2UgdGhlIGZsb3cgbGFiZWwgdG8gaWRlbnRp ZnkgZmxvd3MuIEl0IHNob3VsZCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Y29uc2lkZXJlZCAmcXVvdDtzb2Z0IGlkZW50aWZpY2F0aW9uJnF1b3Q7IHNpbmNlIGl0IG1pZ2h0 IG5vdCBhbHdheXMgYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcnJlY3Qg KGl0IGNhbiBiZSBjaGFuZ2VkIGVuIHJvdXRlLCBpc24ndCBwcm90ZWN0ZWQgYnkgYW55PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGVja3N1bSwgYW55b25lIGNhbiBzZXQgaXQg aG93ZXZlciB0aGV5IHdhbnQsIGV0Yy4pLiBJdCdzIHVzZWZ1bDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZm9yIHRoaW5ncyBsaWtlIEVDTVAgdGhhdCBkb24ndCByZXF1aXJlIDEw MCUgYWNjdXJhY3kgaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5 aW5nIGZsb3cuIFRoZSBmbG93IGxhYmVsIHdhcyBicmllZmx5IGNvbnNpZGVyZWQgZm9yPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob2xkaW5nIFZOSXMgaW4gbmV0d29yayB2aXJ0 dWFsaXphdGlvbiwgYnV0IHdlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGFsa2VkIHRoZW0g b3V0IG9mIHRoYXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG9tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vzc2lvbnMvY29udGV4dC9iZWFy ZXIuIFNvLCBHVFAgYW5kIFRFSUQgZGlkIHRoZSBqb2IuIEJ1dCBJPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZ3JlZSB3aXRoPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpbm8gdGhhdCBJUHY2IGlzIG11Y2ggbW9yZSB2ZXJz YXRpbGUgYW5kIGlzIGRlZmluaXRlbHkgd29ydGg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbG9va2luZyBhdCBhcyBhbiBhbHRlcm5hdGl2ZS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhhdCBpcyBub3Qgd2hhdCBJIHNhaWQuIEkgc2FpZCDigJxJUCBjb3Vs ZCBoYXZlIHNvbHZlZCB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHByb2JsZW3igJ0uIEFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IOKAnElQ4oCdPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lYW5zIGVpdGhlciBJUHY0 IG9yIElQdjYsIG9yIGJvdGggYXQgdGhlIHNhbWUgdGltZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0FyYXNobWlkXTxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyB3b3VsZCB3ZSBlbXBsb3kgSVB2NCB0byBk aXN0aW5ndWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBVRTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHNlc3Npb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg VE9TPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9yIHlvdSBtZWFuIHVz aW5nIGVuY2Fwc3VsYXRpb24/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEgZmFjdG9yIHdvcnRoIGNvbnNpZGVyaW5n IHRob3VnaCBpcyB0aGF0IHRoZSB1c2Ugb2YgR1RQIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVEVJRCBpbiBtb2JpbGU8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29yZSBhbGxvd3Mgb3BlcmF0b3JzIHRvIGRlYWwgd2l0 aCBRb1Mgb24gdGhlaXIgb3duIHRlcm1zLiBUaGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdHVubmVscyB3aXRoIHNwZWNpZmljIG9wZXJhdG9yLWNvbnRyb2xsZWQg UW9TIGFyZSBlc3RhYmxpc2hlZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBieSB0aGUgY29udHJvbCBwbGFuZSBiZXR3ZWVuIGVOQiwgU0dXLCBhbmQgUEdXLiBVRXMg b3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwbGljYXRpb25z IHNpdHRpbmcgaW4gdGhlIFVFcyBoYXZlIG5vIHNheSBpbiB0aGlzLiBXZWxsIGF0PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXN0IHRpbGwgdGhlIHBhY2tldCBl eGl0cyBvcGVyYXRvcidzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3Jr Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgcHJvYmxlbSB3aXRoIG9uZSBoZWFkZXIs IGlzIHRoYXQgaWYgeW91IHJlLW1hcmsgKGtub3duIGFzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBIQiBtYXJraWduIGluIHRoZSBvbGUgZGF5cykgeW91IGxvc2Ug dGhlIG9yaWdpbmFsIHZhbHVlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBFbmNhcHN1bGF0aW9uIGlzIHVzZWZ1bCBoZXJlIGJlY2F1c2UgeW91IGNhbiBtYXAgdGhl IGlubmVyIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG91dGVy IGFuZCBhbnl3aGVyZSBhbG9uZyB0aGUgcGF0aCB5b3UgY2FuIFBIQiByZW1hcmsgb24gdGhlPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG91dGVyIGhlYWRlci4gQW5k IHRoZW4gdGhlIGRlc3RpbmF0aW9uIGNhbiBzZWUgdGhlIG9yaWduYWw8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc291cmNl4oCZcyBUb1MvUW9TL1RDL2Zsb3ctbGFi ZWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGF0ZXZlci48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0FyYXNobWlkXSBZZXMsIEkg YWdyZWUuIFRoZSBvcmlnaW5hbCB2YWx1ZSBpcyBsb3N0IHdpdGggUEhCLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEVuY2Fwc3VsYXRpb24gY2VydGFpbmx5IG1ha2VzIHRo aW5ncyBlYXNpZXIgYW5kIHRoZSBpbm5lciB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG91dGVyIG1hcHBpbmcgdHJpY2sgaGFzIGJlZW4gd2lkZWx5IHVzZWQgaW4gSVAg YW5kIE1QTFMobXVsdGlwbGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBs YWJlbHMgbGlrZSBzZXJ2aWNlIGFuZCB0cmFuc3BvcnQpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVzaW5nIHRoZSBp bmZvcm1hdGlvbiBpbiBVRSdzIElQIHBhY2tldCBoZWFkZXIgY2FuIGplb3BhcmRpc2U8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBhYm92ZSB0aWdodCBR b1MgY29udHJvbC4gSSB0aGluayBnb2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb3Qg aWYgeW91IGVuY2Fwc3VsYXRlLiBCdXQgbm90ZSB3aXRoIFNSdjYsIHlvdSBjYW4gcG9zc2libHk8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmV0YWluIHRoZSBvcmln aW5hbCBmbG93LWxhYmVsIGlmIHRoZSBTSUQgY2FuIHJldGFpbiB0aG9zZSBiaXRzPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlZm9yZSBvdmVyd3JpdGluZyB0aGUg ZGVzdGluYXRpb24gYWRkcmVzcyBmcm9tIHRoZSBvcHRpb27igJlzIHZhbHVlLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgW0FyYXNobWlkXSBBZ3JlZS4gRW5jYXBzdWxhdGlvbiBkb2VzIHRoZSB0cmljayBh Z2Fpbi4gVGhhdCdzIHdoeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdU UCBoYXMgd29ya2VkIHdlbGwgYW5kIHNlcnZlZCB0aGUgcHVycG9zIGluIHRoZSBtb2JpbGU8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiYWNrLWhhdWwgc28gZmFyLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IERpbm88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvd24gdGhpcyBwYXRoLCBv cGVyYXRvcnMgbmVlZCBwcm9vZiB0aGF0IHRoZXkgd2lsbCBiZSBzdGlsbDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gdGhlIGRyaXZpbmc8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VhdCBhbmQgUW9TIGNhbm5vdCBiZSBk aWN0YXRlZC90YW1wZXJlZCBieSB0aGUgVUUgb3IgYW55PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcGxpY2F0aW9uIHJ1bm5pbmcgaW4gaXQuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm93LCBoZXJlIGlzIGFuIGludGVyZXN0aW5nIHF1ZXN0 aW9uIGZvciB0aGUgb3BlcmF0b3JzLiBXb3VsZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW55IG9wZXJhdG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGJlIGludGVyZXN0ZWQgaW4gYWxsb3dpbmcgUW9TJm5ic3A7IHRvIGJl IHNldCBieSB0aGUgVUUgb3IgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYXBwbGljYXRpb25zIHJ1bm5pbmcgaW4gdGhlIFVFIGFuZCBjaGFyZ2VkIGZvciBieSB0 aGUgbmV0d29yaz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1 b3Q7WWVzJnF1b3Q7IGNvdWxkIHBvdGVudGlhbGx5IGltcGx5IGltcGFjdHMgb24gdGhlIGFpciBp bnRlcmZhY2UsIFVFPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJl c291cmNlIGJsb2NrIGFsbG9jYXRpb24gYW5kIGNhbiBtYWtlIHNjaGVkdWxpbmcgb24gdGhlIFJB Tjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzaWRlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbXVjaCBtb3JlIGNvbXBsZXguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQXJhc2htaWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgRnJvbTogZG1tIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YgRGlubzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEZhcmluYWNjaTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFNlbnQ6IDA2IFNlcHRlbWJlciAyMDE4IDEyOjQ1PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IFRvbSBIZXJiZXJ0ICZsdDs8 YSBocmVmPSJtYWlsdG86dG9tQHF1YW50b25pdW0ubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9tQHF1 YW50b25pdW0ubmV0PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnRhLW1peWFzYWthQGtkZGktcmVzZWFy Y2guanAiIHRhcmdldD0iX2JsYW5rIj50YS1taXlhc2FrYUBrZGRpLXJlc2VhcmNoLmpwPC9hPjsg ZG1tICZsdDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1t QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRtbS01 Zy11cGxhbmUtPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5hbHlzaXMtPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAwMTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEJlaGNldCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSB3YXMgdGhpbmtpbmcgaWYgVEVJRCBpcyBuZWVkIHRoZW4gdGhh dCBjYW4gYmUgZW5jb2RlZCBpbiBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxvY2F0b3IgZWFzaWx5IGVub3VnaC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG9tPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb3QgaWYgYSBsb2NhdG9yIGlzIGEgUEdXIHRoYXQg aXMgc2hhcmVkIGJ5IG1hbnkgVUVzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgM0dQUCB3YW50cyBwZXIgYmVhcmVyIGF3YXJlbmVzcyBzbyB0aGV5IG5lZWQgYSBz cGVjaWZpYyBJRCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGF0IGNvdWxkIGhhdmUgYmVlbiB0aGUgVUXigJlzIElQIGFkZHJlc3MuIEFuZCB3aXRo IElQdjYgaXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBjYW4gYmUgdW5pcXVlIGFuZCBub3QgdGhlIGlzc3VlIHRoYXQgU3JpZGhhciBicm91Z2h0IHVw Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgSUxBIHdhcyBp biB1c2UsIGp1c3QgdXNlIHRoZSBJTEEtSUQgZm9yIHRoaXMgcHVycG9zZS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpbm88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZG1tIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RtbTwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0 OyZndDsgZG1tIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IGRtbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t PC9hPjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IGRtbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0 bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9h Pjxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NClNodW5zdWtlIEhvbW1hPGJyPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzpob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+aG9tbWEu LnNodW5zdWtlQGxhYi5udHQuY28uanA8L2E+Jmd0Ozxicj4NClRFTDogJiM0Mzs4MSA0MjIgNTkg MzQ4Njxicj4NCkZBWDogJiM0Mzs4MSA0MjIgNjAgNzQ2MDxicj4NCjxicj4NCk5UVCBOZXR3b3Jr IFNlcnZpY2UgU3lzdGVtcyBMYWJzLjxicj4NCk11c2FzaGlubyBjaXR5LCBUb2t5bywgSmFwYW48 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D57109449177B54F8B9C093953AC5BCD755E4D4Byyzeml704chmchi_-- From nobody Wed Oct 3 09:29:40 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027AC131386 for ; Wed, 3 Oct 2018 09:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2qUdd4ydKBfO for ; Wed, 3 Oct 2018 09:29:28 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4C5301313A2 for ; Wed, 3 Oct 2018 09:29:28 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id v18-v6so4853898edq.12 for ; Wed, 03 Oct 2018 09:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fgsF+Wvyxnb92TIVvoohzlgBCbct4BfveqpvLf4T46c=; b=WKT4C+OfFlTosN0Bi/FDT5mh+vrM7nw36CtZwH9xKHlS+4BlCu6mDuF9C+W8A+cI0I Iaat+pOH28GsnpbXUhRtiD+XzIpYyve8d9iCmvcrMQGY68cV8U+/TLWYZ0EkBdxiITdG qhYO2zdqxXEwjAqfApo2fsOJgE3Bf9t3k1+QAVDZ6lB2VVxGOgMZWMRoVQ79CGfEXRSn V0xe558B1ZyRVn/cwMqtdeMIQc8pqRPo/XdRlMAHtMLf5EI+EoD7w2phbBaE02AhAoDl 1z0LJ1AU9T8cg7NZSrWGo4jV//EsAMGdItTcvClq+e3RpF7d3L9Iw+VjO4jMpHdzCwzX BNPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fgsF+Wvyxnb92TIVvoohzlgBCbct4BfveqpvLf4T46c=; b=rmWOqEXc/gAlqpDIW5zrG5NbLsaRVTi8NrZbxnf1nUdGdhIVsP16bJbx/DsEuQMcrV TCTnUIexYDTyvTNbShmvzfLvRYWB+M5p/rbv1QMOrNhSLXoHWTa7a1zyHkLMQM/ZIzG/ xYoFhQt1a14W3fWdiXd0USVknQztjizkJBf7W5KH7gQqcdmqA5QNriQz4TtQlBmZ34Rn gM3jvsvKH9aDskkRHRTk7jpH5wG10oO7VIFbJr929dq6k1RtXky1KnxQpZS96JyBn/+k CohYx8EgzU1GBXL1HY6s7Vbguu79jB3nUlK9zadk7F0enTxEUlk6bEAyAW1IEIUYOSx7 r4CQ== X-Gm-Message-State: ABuFfoiArpvTAJxTFVmT4bgWiTl5+sX6xAxSsefCtU6nGzkK+BVp6icV Y5JD4s76k4gWn00cS5cd8aihcehjv3y682EG9xE= X-Google-Smtp-Source: ACcGV619zaGR4VZZqZLgRh98Ar7wg536yh6ZXwsqSGnxSScqMevBbmlFzlC2hZhCUFjOmx0GGLmKnFtlJ21zD6Q4ixY= X-Received: by 2002:a17:906:40cd:: with SMTP id a13-v6mr2764274ejk.14.1538584166497; Wed, 03 Oct 2018 09:29:26 -0700 (PDT) MIME-Version: 1.0 References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> In-Reply-To: From: Sridhar Bhaskaran Date: Wed, 3 Oct 2018 21:59:10 +0530 Message-ID: To: arashmid.akhavain@huawei.com Cc: sarikaya@ieee.org, homma.shunsuke@lab.ntt.co.jp, dmm@ietf.org Content-Type: multipart/alternative; boundary="000000000000b382250577558a0b" Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:29:38 -0000 --000000000000b382250577558a0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >>A UPF is any function that can be executed on user traffic in mobile network. Having said that however, I think the first UPFs that we will see will be in the form of SGW, PGW. Even this is not accurate. A UPF is a *5G system core network* entity whereas the SGW-U and PGW-U are EPC core network entities. 5G core network has many differences from EPC. To avoid confusion it should be noted that 5G NR radio can be deployed with EPC as the core network and technically such deployments can also be called as 5G deployments. But an UPF has no role in such deployments. Some of the user plane functionalities of an UPF are completely different from SGW-U or PGW-U. Here are few differences (not exhaustive) 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session. Different QoS flows within that PDU session are identified based on the QFI marking. So a UPF has to support QFI marking. 2. An UPF can support classification and encapsulation Ethernet frames whereas a SGW-U/PGW-U has no requirement to support classification and encapsulation of Ethernet frames. 3. An UPF supporting Ethernet PDU session type may support ARP proxying / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement. 4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no such requirement. One may say that SGW-U / PGW-U also plays a role in user plane forwarding and hence why not call it a UPF? For the lack of a better terminology, 3GPP has called the entity that performs the user plane functionalities and features within a *5G core network* as UPF. Those functionalities are not exactly similar to EPC. Thanks Sridhar On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain < arashmid.akhavain@huawei.com> wrote: > Not necessarily, > > > > You are correct in that PGW is a UPF, but a UPF is by no means limited to > PGW. A UPF is any function that can be executed on user traffic in mobile > network. Having said that however, I think the first UPFs that we will se= e > will be in the form of SGW, PGW. > > > > Arashmid > > > > *From:* dmm [mailto:dmm-bounces@ietf.org] *On Behalf Of *Behcet Sarikaya > *Sent:* Tuesday, October 02, 2018 11:44 AM > *To:* Shunsuke Homma > *Cc:* dmm > *Subject:* Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > UPF is virtualized PGW, folks. > > While PGW is fixed in location and possibly serving a large number of UE > which are geographically in the area, that part of the city and that city > itself, UPF can be deployed closer to the UE and thus probably serving > smaller number of UEs > > > > Behcet > > > > On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma < > homma.shunsuke@lab.ntt.co.jp> wrote: > > Thanks Dark for your explaining what is UPF instead of me. > > Alex, brief definitions of UPF are described in the section 4.1.1.1 of > this draft. Also, you can find more details in 3GPP TS23.501. > > Regards, > > Shunsuke > > On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de wrote: > > Hi Alex, > > and sorry for jumping into the discussion... > > From my and (AFAIK) 3GPPs understanding your smartphone is a UE - > sitting on the other side of RAN (gNB) - whereas a UPF normally is seen a= s > UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a tru= e > CP/UP split fashion). > > Any other ideas on this? Can someone imagine any scenario where UE > implements UPF? > > Thanks! > > Best Regards > > Dirk > > > > -----Original Message----- > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Montag, 1. Oktober 2018 13:22 > > To: dmm@ietf.org > > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > > > > > Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit : > >> Hi all, > >> # Sorry for my late response... > >> > >> Thank you for your lively discussion. It is very helpful for > >> understanding points which need supplemental explanation and more > >> consideration. > >> > >> Following the discussion, we're planning to update the I-D for > >> covering the points below: > >> > >> - termination points of GTP-U > >> (RANs and UPFs terminate GTP-U in 5GS.) > > > > What is UPF? > > > > I understand UPF stands for User-Plane Function. > > > > Is my smartphone supposed to implement UPF? > > > > Alex > > > >> - setting QoS parameter of outer IP header > >> (Note that it's not just copy of inner to outer.) > >> - problems related to IP connectivity (e.g., MTU in IPv6 networks, > >> IPv4 address duplication) > >> - summary of network slicing in 5GS > >> (E.g., "slice is composed of SMF and UPFs. AMF selects SMF > >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF > >> that it is > >> allocated.") > >> - case studies on UPF selection > >> (E.g., parameters used for deciding destination UPF) # Optimizing > >> forwarding paths solution might be realized with UPF selection > >> mechanism in 3GPP architecture. (ID-LOC may be applied as such > >> mechanism.) > >> > >> > >> If you have any request for us on this updating, please let us know. > >> > >> Best regards, > >> > >> Shunsuke > >> > >> On 2018/09/08 3:28, Dino Farinacci wrote: > >>>> I understand your point, but there is no guarantee for a precise QoS > >>>> without using some sort of encapsulation being it GTP, RSVP, etc. > >>>> Even with tunnels, there is no guarantee that all nodes along the > >>>> path have the same hardware capability and can provide the same QoS > >>>> treatment. > >>> > >>> There is existing hardware where the encapsulator copies inner QoS to > >>> outer QoS. All routers along the path just process the outer QoS, no > >>> changes to or new processing requirements for them. > >>> > >>>> For example, the code points in routers need to be configured to > >>>> correctly handle the EXP bits in MPLS labels. But there is no > >>>> guarantee that all routers can support all values. The EXP values > >>>> get mapped to code points but the mapping is not always one to one. > >>>> 3-bit EXPs can map to 4 code points on those routers with less > >>>> capable H/W. > >>> > >>> That is a completely different matter. The discussion is about > >>> remarking. And if one remarks to what the path cannot support, well > >>> things don=E2=80=99t work as expected. > >>> > >>>> Slicing is almost the same. It allows user traffic to be mapped to > >>>> what the operator provides. > >>>> I agree with you that network should not touch/change original > >>>> header bits. GTP or any other encapsulation easily allow for this. > >>>> The question is whether we can provide for this without using > >>>> encapsulation. IPv6 might be the answer. But as Tom pointed out, > >>>> flow labels can still change in the middle. Is there any room for > >>>> improvement. SIDs might present an opportunity. > >>> > >>> Not if they are encapsulated and routers don=E2=80=99t touch packets = inside. > >>> > >>> Dino > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>> Sent: 07 September 2018 13:08 > >>>>> To: Arashmid Akhavain > >>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-research.jp; > >>>>> dmm > >>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > >>>>> > >>>>> I think you=E2=80=99ll still have the PHB re-marking issues I menti= oned in > >>>>> previous emails. The question is, should the network touch/change > >>>>> any header bits of the packet the source has built. The answer > >>>>> should probably be no. > >>>>> > >>>>> Having said that, GTP did it the right way, even though it cost in > >>>>> header length. > >>>>> > >>>>> Dino > >>>>> > >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain > >>>>> wrote: > >>>>>> > >>>>>> Correct, flow labels can change along the path. That's why I like > >>>>>> the slicing > >>>>> concept. > >>>>>> UEs can request services with different attributes, operators > >>>>>> control how > >>>>> service request are mapped into slices. I should look into the air > >>>>> side of the business and see what happens there. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net] > >>>>>>> Sent: 07 September 2018 11:13 > >>>>>>> To: Arashmid Akhavain > >>>>>>> Cc: Dino Farinacci ; > >>>>>>> ta-miyasaka@kddi-research.jp; dmm > >>>>>>> Subject: Re: [DMM] Comments to > >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 > >>>>>>> > >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain > >>>>>>> > > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>>>>> Sent: 06 September 2018 18:59 > >>>>>>>>> To: Arashmid Akhavain > >>>>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi- > >>>>> research.jp; > >>>>>>>>> dmm > >>>>>>>>> Subject: Re: [DMM] Comments to > >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- > >>>>> 01 > >>>>>>>>> > >>>>>>>>>> Dino brought up a good point. Here is my two cents worth: > >>>>>>>>> > >>>>>>>>> Not sure which point. > >>>>>>>>> > >>>>>>>>>> As it was explained by Sridhar, each UE can have multiple > >>>>>>>>>> contexts. For > >>>>>>>>> example, today some operators provide Data and VoLTE service to > >>>>>>>>> their customers. These two services are represented by separate > >>>>>>>>> GTP tunnels in the core with each tunnel tied up to a particula= r > QoS. > >>>>>>>>>> > >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it > >>>>>>>>>> couldn't uniquely identify multiple UE > >>>>>>>>> > >>>>>>>>> There is no reason why it shouldn=E2=80=99t. And IPv6, for this > >>>>>>>>> use-case doesn=E2=80=99t add anything new other than a 28 bit > >>>>>>>>> traffic-class/flow-label that can provide more bits for =E2=80= =9Cnew > >>>>> functionality=E2=80=9D. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] And that's what I meant. Having a flow label is hand= y. > >>>>>>>> We can perhaps use it to identify different UE sessions. > >>>>>>>> > >>>>>>> Careful if you use the flow label to identify flows. It should be > >>>>>>> considered "soft identification" since it might not always be > >>>>>>> correct (it can be changed en route, isn't protected by any > >>>>>>> checksum, anyone can set it however they want, etc.). It's useful > >>>>>>> for things like ECMP that don't require 100% accuracy in > >>>>>>> identifying flow. The flow label was briefly considered for > >>>>>>> holding VNIs in network virtualization, but we > >>>>> talked them out of that. > >>>>>>> > >>>>>>> Tom > >>>>>>> > >>>>>>>>> > >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I > >>>>>>>>>> agree with > >>>>>>>>> Dino that IPv6 is much more versatile and is definitely worth > >>>>>>>>> looking at as an alternative. > >>>>>>>>> > >>>>>>>>> That is not what I said. I said =E2=80=9CIP could have solved t= his > >>>>>>>>> problem=E2=80=9D. And > >>>>> =E2=80=9CIP=E2=80=9D > >>>>>>>>> means either IPv4 or IPv6, or both at the same time. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] > >>>>>>>> How would we employ IPv4 to distinguish between different UE > >>>>>>>> sessions. > >>>>>>> TOS? > >>>>>>>> Or you mean using encapsulation? > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> A factor worth considering though is that the use of GTP and > >>>>>>>>>> TEID in mobile > >>>>>>>>> core allows operators to deal with QoS on their own terms. The > >>>>>>>>> tunnels with specific operator-controlled QoS are established > >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or > >>>>>>>>> applications sitting in the UEs have no say in this. Well at > >>>>>>>>> least till the packet exits operator's > >>>>>>> network. > >>>>>>>>> > >>>>>>>>> The problem with one header, is that if you re-mark (known as > >>>>>>>>> PHB markign in the ole days) you lose the original value. > >>>>>>>>> Encapsulation is useful here because you can map the inner to > >>>>>>>>> outer and anywhere along the path you can PHB remark on the > >>>>>>>>> outer header. And then the destination can see the orignal > >>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label > >>>>> whatever. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. > >>>>>>>> Encapsulation certainly makes things easier and the inner to > >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple > >>>>>>>> labels like service and transport) > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> Using the information in UE's IP packet header can jeopardise > >>>>>>>>>> the above tight QoS control. I think going > >>>>>>>>> > >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly > >>>>>>>>> retain the original flow-label if the SID can retain those bits > >>>>>>>>> before overwriting the destination address from the option=E2= =80=99s > value. > >>>>>>>> > >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why > >>>>>>>> GTP has worked well and served the purpos in the mobile > >>>>>>>> back-haul so far. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Dino > >>>>>>>>> > >>>>>>>>>> down this path, operators need proof that they will be still > >>>>>>>>>> in the driving > >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any > >>>>>>>>> application running in it. > >>>>>>>>>> > >>>>>>>>>> Now, here is an interesting question for the operators. Would > >>>>>>>>>> any operator > >>>>>>>>> be interested in allowing QoS to be set by the UE or by > >>>>>>>>> applications running in the UE and charged for by the network? > >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE > >>>>>>>>> resource block allocation and can make scheduling on the RAN > >>>>>>>>> side > >>>>> much more complex. > >>>>>>>>>> > >>>>>>>>>> Arashmid > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino > >>>>>>>>>>> Farinacci > >>>>>>>>>>> Sent: 06 September 2018 12:45 > >>>>>>>>>>> To: Tom Herbert > >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; dmm > >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- > >>>>> analysis- > >>>>>>> 01 > >>>>>>>>>>> > >>>>>>>>>>>> Behcet, > >>>>>>>>>>>> > >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a > >>>>>>>>>>>> locator easily enough. > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>> > >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. > >>>>>>>>>>> > >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, > >>>>>>>>>>> that could have been the UE=E2=80=99s IP address. And with IP= v6 it > >>>>>>>>>>> can be unique and not the issue that Sridhar brought up. > >>>>>>>>>>> > >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. > >>>>>>>>>>> > >>>>>>>>>>> Dino > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> dmm mailing list > >>>>>>>>>>> dmm@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > >> > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > ---------------------------------- > Shunsuke Homma > > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 > > NTT Network Service Systems Labs. > Musashino city, Tokyo, Japan > ---------------------------------- > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --=20 o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran --000000000000b382250577558a0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>A UPF is any function tha= t can be executed on user traffic in mobile network. Having said that however, I think the first UPFs that we will see will be in the = form of SGW, PGW.

Even this is not accurate= .

A UPF is a 5G system core network = entity whereas the SGW-U and PGW-U are EPC core network entities. 5G core n= etwork has many differences from EPC. To avoid confusion it should be noted= that 5G NR radio can be deployed with EPC as the core network and technica= lly such deployments can also be called as 5G deployments. But an UPF has n= o role in such deployments.

Some of the user p= lane functionalities of an UPF are completely different from SGW-U or PGW-U= . Here are few differences (not exhaustive)

1.= SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any QFI= marking. UPF on the other hand has one GTP-U tunnel per PDU session. Diffe= rent QoS flows within that PDU session are identified based on the QFI mark= ing. So a UPF has to support QFI marking.
2. An UPF can support c= lassification and encapsulation Ethernet frames whereas a SGW-U/PGW-U has n= o requirement to support classification and encapsulation of Ethernet frame= s.
3. An UPF supporting Ethernet PDU session type may support ARP= proxying / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement= .
4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW= -U has no such requirement.

One may say that S= GW-U / PGW-U also plays a role in user plane forwarding and hence why not c= all it a UPF?=C2=A0 For the lack of a better terminology, 3GPP has called t= he entity that performs the user plane functionalities and features within = a 5G core network as UPF. Those functionalities are not exact= ly similar to EPC.

Thanks
Sridhar
<= div>
On Tue, Oct 2, 20= 18 at 10:45 PM Arashmid Akhavain <arashmid.akhavain@huawei.com> wrote:

Not necessarily,=

=C2=A0

You are correct in that PGW is a UPF,= but a UPF is by no means limited to PGW. A UPF is any function that can be= executed on user traffic in mobile network. Having said that however, I think the first UPFs that we will see will be in the = form of SGW, PGW.

=C2=A0

Arashmid

=C2=A0

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma <homma.shunsuke@lab.ntt.co.jp>
Cc: dmm <dmm@ie= tf.org>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

=C2=A0

UPF is virtualized PGW, folks.

While PGW is fixed in location and possibly serving = a large number of UE which are geographically in the area, that part of the= city and that city itself, UPF can be deployed closer to the UE and thus p= robably serving smaller number of UEs

=C2=A0

Behcet

=C2=A0

On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma <<= a href=3D"mailto:homma.shunsuke@lab.ntt.co.jp" target=3D"_blank">homma.shun= suke@lab.ntt.co.jp> wrote:

Thanks Dark for your explaining what is UPF instead = of me.

Alex, brief definitions of UPF are described in the section 4.1.1.1 of
this draft. Also, you can find more details in 3GPP TS23.501.

Regards,

Shunsuke

On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de wrote:
> Hi Alex,
> and sorry for jumping into the discussion...
>=C2=A0 From my and (AFAIK) 3GPPs understanding your smartphone is a UE = - sitting on the other side of RAN (gNB) - whereas a UPF normally is seen a= s UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a tru= e CP/UP split fashion).
> Any other ideas on this? Can someone imagine any scenario where UE imp= lements UPF?
> Thanks!
> Best Regards
> Dirk
>
> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org=
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
>
>
> Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit=C2=A0:
>> Hi all,
>> # Sorry for my late response...
>>
>> Thank you for your lively discussion. It is very helpful for
>> understanding points which need supplemental explanation and more<= br> >> consideration.
>>
>> Following the discussion, we're planning to update the I-D for=
>> covering the points below:
>>
>> - termination points of GTP-U
>>=C2=A0 =C2=A0=C2=A0 (RANs and UPFs terminate GTP-U in 5GS.)
>
> What is UPF?
>
> I understand UPF stands for User-Plane Function.
>
> Is my smartphone supposed to implement UPF?
>
> Alex
>
>> - setting QoS parameter of outer IP header
>>=C2=A0 =C2=A0=C2=A0 (Note that it's not just copy of inner to o= uter.)
>> - problems related to IP connectivity (e.g., MTU in IPv6 networks,=
>> IPv4 address duplication)
>> - summary of network slicing in 5GS
>>=C2=A0 =C2=A0=C2=A0 (E.g., "slice is composed of SMF and UPFs.= AMF selects SMF
>> depending on NSSAI sent from UE, and SMF indicates to the UE the U= PF
>> that it is
>> allocated.")
>> - case studies on UPF selection
>>=C2=A0 =C2=A0=C2=A0 (E.g., parameters used for deciding destination= UPF) # Optimizing
>> forwarding paths solution might be realized with UPF selection
>> mechanism in 3GPP architecture. (ID-LOC may be applied as such
>> mechanism.)
>>
>>
>> If you have any request for us on this updating, please let us kno= w.
>>
>> Best regards,
>>
>> Shunsuke
>>
>> On 2018/09/08 3:28, Dino Farinacci wrote:
>>>> I understand your point, but there is no guarantee for a p= recise QoS
>>>> without using some sort of encapsulation being it GTP, RSV= P, etc.
>>>> Even with tunnels, there is no guarantee that all nodes al= ong the
>>>> path have the same hardware capability and can provide the= same QoS
>>>> treatment.
>>>
>>> There is existing hardware where the encapsulator copies inner= QoS to
>>> outer QoS. All routers along the path just process the outer Q= oS, no
>>> changes to or new processing requirements for them.
>>>
>>>> For example, the code points in routers need to be configu= red to
>>>> correctly handle the EXP bits in MPLS labels. But there is= no
>>>> guarantee that all routers can support all values. The EXP= values
>>>> get mapped to code points but the mapping is not always on= e to one.
>>>> 3-bit EXPs can map to 4 code points on those routers with = less
>>>> capable H/W.
>>>
>>> That is a completely different matter. The discussion is about=
>>> remarking. And if one remarks to what the path cannot support,= well
>>> things don=E2=80=99t work as expected.
>>>
>>>> Slicing is almost the same. It allows user traffic to be m= apped to
>>>> what the operator provides.
>>>> I agree with you that network should not touch/change orig= inal
>>>> header bits. GTP or any other encapsulation easily allow f= or this.
>>>> The question is whether we can provide for this without us= ing
>>>> encapsulation. IPv6 might be the answer. But as Tom pointe= d out,
>>>> flow labels can still change in the middle. Is there any r= oom for
>>>> improvement. SIDs might present an opportunity.
>>>
>>> Not if they are encapsulated and routers don=E2=80=99t touch p= ackets inside.
>>>
>>> Dino
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>>>>> Sent: 07 September 2018 13:08
>>>>> To: Arashmid Akhavain <arashmid.akhavain@huawei.com><= br> >>>>> Cc: Tom Herbert <tom@quantonium.net>; ta-miyasa= ka@kddi-research.jp;
>>>>> dmm <dmm@ietf.org>
>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane= -analysis-01
>>>>>
>>>>> I think you=E2=80=99ll still have the PHB re-marking i= ssues I mentioned in
>>>>> previous emails. The question is, should the network t= ouch/change
>>>>> any header bits of the packet the source has built. Th= e answer
>>>>> should probably be no.
>>>>>
>>>>> Having said that, GTP did it the right way, even thoug= h it cost in
>>>>> header length.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
>>>>> <arashmid.akhavain@huawei.com> wrote:
>>>>>>
>>>>>> Correct, flow labels can change along the path. Th= at's why I like
>>>>>> the slicing
>>>>> concept.
>>>>>> UEs can request services with different attributes= , operators
>>>>>> control how
>>>>> service request are mapped into slices. I should look = into the air
>>>>> side of the business and see what happens there.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Tom Herbert [mailto:tom@quantonium.net]
>>>>>>> Sent: 07 September 2018 11:13
>>>>>>> To: Arashmid Akhavain <arashmid.akhavain@huawei.com<= /a>>
>>>>>>> Cc: Dino Farinacci <farinacci@gmail.com>;
>>>>>>> ta-miyasaka@kddi-research.jp; dmm <dmm@ietf.org>
>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>> draft-hmm-dmm-5g-uplane-analysis-01
>>>>>>>
>>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhav= ain
>>>>>>> <arashmid.akhavain@huawei.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com]<= br> >>>>>>>>> Sent: 06 September 2018 18:59
>>>>>>>>> To: Arashmid Akhavain <arashmid.akhavain@hua= wei.com>
>>>>>>>>> Cc: Tom Herbert <tom@quantonium.net>; ta-miyasa= ka@kddi-
>>>>> resea= rch.jp;
>>>>>>>>> dmm <dmm@ietf.org>
>>>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>>>> draft-hmm-dmm-5g-uplane-analysis-
>>>>> 01
>>>>>>>>>
>>>>>>>>>> Dino brought up a good point. Here= is my two cents worth:
>>>>>>>>>
>>>>>>>>> Not sure which point.
>>>>>>>>>
>>>>>>>>>> As it was explained by Sridhar,=C2= =A0 each UE can have multiple
>>>>>>>>>> contexts. For
>>>>>>>>> example, today some operators provide = Data and VoLTE service to
>>>>>>>>> their customers. These two services ar= e represented by separate
>>>>>>>>> GTP tunnels in the core with each tunn= el tied up to a particular QoS.
>>>>>>>>>>
>>>>>>>>>> IPv4 didn't fit the bill when = GTP work was under way as it
>>>>>>>>>> couldn't uniquely identify mul= tiple UE
>>>>>>>>>
>>>>>>>>> There is no reason why it shouldn=E2= =80=99t. And IPv6, for this
>>>>>>>>> use-case doesn=E2=80=99t add anything = new other than a 28 bit
>>>>>>>>> traffic-class/flow-label that can prov= ide more bits for =E2=80=9Cnew
>>>>> functionality=E2=80=9D.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid]=C2=A0 And that's what I mea= nt. Having a flow label is handy.
>>>>>>>> We can perhaps use it to identify differen= t UE sessions.
>>>>>>>>
>>>>>>> Careful if you use the flow label to identify = flows. It should be
>>>>>>> considered "soft identification" sin= ce it might not always be
>>>>>>> correct (it can be changed en route, isn't= protected by any
>>>>>>> checksum, anyone can set it however they want,= etc.). It's useful
>>>>>>> for things like ECMP that don't require 10= 0% accuracy in
>>>>>>> identifying flow. The flow label was briefly c= onsidered for
>>>>>>> holding VNIs in network virtualization, but we=
>>>>> talked them out of that.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>>>
>>>>>>>>>> sessions/context/bearer. So, GTP a= nd TEID did the job. But I
>>>>>>>>>> agree with
>>>>>>>>> Dino that IPv6 is much more versatile = and is definitely worth
>>>>>>>>> looking at as an alternative.
>>>>>>>>>
>>>>>>>>> That is not what I said. I said =E2=80= =9CIP could have solved this
>>>>>>>>> problem=E2=80=9D. And
>>>>> =E2=80=9CIP=E2=80=9D
>>>>>>>>> means either IPv4 or IPv6, or both at = the same time.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid]
>>>>>>>> How would we employ IPv4 to distinguish be= tween different UE
>>>>>>>> sessions.
>>>>>>> TOS?
>>>>>>>> Or you mean using encapsulation?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> A factor worth considering though = is that the use of GTP and
>>>>>>>>>> TEID in mobile
>>>>>>>>> core allows operators to deal with QoS= on their own terms. The
>>>>>>>>> tunnels with specific operator-control= led QoS are established
>>>>>>>>> by the control plane between eNB, SGW,= and PGW. UEs or
>>>>>>>>> applications sitting in the UEs have n= o say in this. Well at
>>>>>>>>> least till the packet exits operator&#= 39;s
>>>>>>> network.
>>>>>>>>>
>>>>>>>>> The problem with one header, is that i= f you re-mark (known as
>>>>>>>>> PHB markign in the ole days) you lose = the original value.
>>>>>>>>> Encapsulation is useful here because y= ou can map the inner to
>>>>>>>>> outer and anywhere along the path you = can PHB remark on the
>>>>>>>>> outer header. And then the destination= can see the orignal
>>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label=
>>>>> whatever.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Arashmid] Yes, I agree. The original valu= e is lost with PHB.
>>>>>>>> Encapsulation certainly makes things easie= r and the inner to
>>>>>>>> outer mapping trick has been widely used i= n IP and MPLS(multiple
>>>>>>>> labels like service and transport)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Using the information in UE's = IP packet header can jeopardise
>>>>>>>>>> the above tight QoS control. I thi= nk going
>>>>>>>>>
>>>>>>>>> Not if you encapsulate. But note with = SRv6, you can possibly
>>>>>>>>> retain the original flow-label if the = SID can retain those bits
>>>>>>>>> before overwriting the destination add= ress from the option=E2=80=99s value.
>>>>>>>>
>>>>>>>> [Arashmid] Agree. Encapsulation does the t= rick again. That's why
>>>>>>>> GTP has worked well and served the purpos = in the mobile
>>>>>>>> back-haul so far.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dino
>>>>>>>>>
>>>>>>>>>> down this path, operators need pro= of that they will be still
>>>>>>>>>> in the driving
>>>>>>>>> seat and QoS cannot be dictated/tamper= ed by the UE or any
>>>>>>>>> application running in it.
>>>>>>>>>>
>>>>>>>>>> Now, here is an interesting questi= on for the operators. Would
>>>>>>>>>> any operator
>>>>>>>>> be interested in allowing QoS=C2=A0 to= be set by the UE or by
>>>>>>>>> applications running in the UE and cha= rged for by the network?
>>>>>>>>> "Yes" could potentially impl= y impacts on the air interface, UE
>>>>>>>>> resource block allocation and can make= scheduling on the RAN
>>>>>>>>> side
>>>>> much more complex.
>>>>>>>>>>
>>>>>>>>>> Arashmid
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On = Behalf Of Dino
>>>>>>>>>>> Farinacci
>>>>>>>>>>> Sent: 06 September 2018 12:45<= br> >>>>>>>>>>> To: Tom Herbert <tom@quantonium.net> >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp; d= mm <dmm@ietf.org&g= t;
>>>>>>>>>>> Subject: Re: [DMM] Comments to= draft-hmm-dmm-5g-uplane-
>>>>> analysis-
>>>>>>> 01
>>>>>>>>>>>
>>>>>>>>>>>> Behcet,
>>>>>>>>>>>>
>>>>>>>>>>>> I was thinking if TEID is = need then that can be encoded in a
>>>>>>>>>>>> locator easily enough.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Not if a locator is a PGW that= is shared by many UEs.
>>>>>>>>>>>
>>>>>>>>>>> 3GPP wants per bearer awarenes= s so they need a specific ID,
>>>>>>>>>>> that could have been the UE=E2= =80=99s IP address. And with IPv6 it
>>>>>>>>>>> can be unique and not the issu= e that Sridhar brought up.
>>>>>>>>>>>
>>>>>>>>>>> If ILA was in use, just use th= e ILA-ID for this purpose.
>>>>>>>>>>>
>>>>>>>>>>> Dino
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> dmm mailing list
>>>>>>>>>>> dmm@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/list= info/dmm
>>>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


--
----------------------------------
Shunsuke Homma
<homma= ..shunsuke@lab.ntt.co.jp>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


--
=C2=A0o= __
=C2=A0_> =C2=A0/__
(_) \(_)... Burn fat not fuel - Bike alo= ng to a healthier life and cleaner
world! :)

Sridhar Bhaskaran=

--000000000000b382250577558a0b-- From nobody Thu Oct 4 14:39:28 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CDD130E9A for ; Thu, 4 Oct 2018 14:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 t56iNPHSF7D2 for ; Thu, 4 Oct 2018 14:39:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5FE130934 for ; Thu, 4 Oct 2018 14:39:21 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 14B71E86ACA02 for ; Thu, 4 Oct 2018 22:39:16 +0100 (IST) Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 4 Oct 2018 22:39:17 +0100 Received: from YYZEML704-CHM.china.huawei.com ([169.254.1.141]) by YYZEML702-CHM.china.huawei.com ([169.254.6.111]) with mapi id 14.03.0399.000; Thu, 4 Oct 2018 17:39:12 -0400 From: Arashmid Akhavain To: Sridhar Bhaskaran CC: "sarikaya@ieee.org" , "homma.shunsuke@lab.ntt.co.jp" , "dmm@ietf.org" Thread-Topic: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 Thread-Index: AQHUWTnje1ehGQuh0kug3/4QbZgenaUKgqMAgAAC+YCAARBGgIAAyDWA///TY6CAAcuNAIABgj7w Date: Thu, 4 Oct 2018 21:39:11 +0000 Message-ID: References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <186A00D0-0D8E-4B8F-BC3F-81E45A184289@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: multipart/alternative; boundary="_000_D57109449177B54F8B9C093953AC5BCD755E5415yyzeml704chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:39:27 -0000 --_000_D57109449177B54F8B9C093953AC5BCD755E5415yyzeml704chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCBwdXQgU3JpZGhhcuKApiBUaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCBjbGFyaWZpY2F0 aW9uLg0KDQpTcGVha2luZyBvZiBRb1MgRmxvdyBJZGVudGlmaWVycywgSSBhbSBhc3N1bWluZyB0 aGF0IG1hcHBpbmcgdGhlIFFvUyByZXF1aXJlbWVudHMgZnJvbSA1RyBjb3JlIHRvIHRoZSB1bmRl cmx5aW5nIHRyYW5zcG9ydCBub2RlcyAocm91dGVycywgc3dpdGNoZXMpIGFuZCB2aWNlIHZlcnNh IGhhcyBub3QgYmVlbiBjaGFuZ2VkLiBJcyB0aGlzIGNvcnJlY3QgU3JpZGhhcj8NCg0KQXJhc2ht aWQNCg0KRnJvbTogU3JpZGhhciBCaGFza2FyYW4gW21haWx0bzpzcmlkaGFyLmJoYXNrYXJhbkBn bWFpbC5jb21dDQpTZW50OiAwMyBPY3RvYmVyIDIwMTggMTI6MjkNClRvOiBBcmFzaG1pZCBBa2hh dmFpbiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT4NCkNjOiBzYXJpa2F5YUBpZWVlLm9y ZzsgaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcDsgZG1tQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtMDEN Cg0KPj5BIFVQRiBpcyBhbnkgZnVuY3Rpb24gdGhhdCBjYW4gYmUgZXhlY3V0ZWQgb24gdXNlciB0 cmFmZmljIGluIG1vYmlsZSBuZXR3b3JrLiBIYXZpbmcgc2FpZCB0aGF0IGhvd2V2ZXIsIEkgdGhp bmsgdGhlIGZpcnN0IFVQRnMgdGhhdCB3ZSB3aWxsIHNlZSB3aWxsIGJlIGluIHRoZSBmb3JtIG9m IFNHVywgUEdXLg0KDQpFdmVuIHRoaXMgaXMgbm90IGFjY3VyYXRlLg0KDQpBIFVQRiBpcyBhIDVH IHN5c3RlbSBjb3JlIG5ldHdvcmsgZW50aXR5IHdoZXJlYXMgdGhlIFNHVy1VIGFuZCBQR1ctVSBh cmUgRVBDIGNvcmUgbmV0d29yayBlbnRpdGllcy4gNUcgY29yZSBuZXR3b3JrIGhhcyBtYW55IGRp ZmZlcmVuY2VzIGZyb20gRVBDLiBUbyBhdm9pZCBjb25mdXNpb24gaXQgc2hvdWxkIGJlIG5vdGVk IHRoYXQgNUcgTlIgcmFkaW8gY2FuIGJlIGRlcGxveWVkIHdpdGggRVBDIGFzIHRoZSBjb3JlIG5l dHdvcmsgYW5kIHRlY2huaWNhbGx5IHN1Y2ggZGVwbG95bWVudHMgY2FuIGFsc28gYmUgY2FsbGVk IGFzIDVHIGRlcGxveW1lbnRzLiBCdXQgYW4gVVBGIGhhcyBubyByb2xlIGluIHN1Y2ggZGVwbG95 bWVudHMuDQoNClNvbWUgb2YgdGhlIHVzZXIgcGxhbmUgZnVuY3Rpb25hbGl0aWVzIG9mIGFuIFVQ RiBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbSBTR1ctVSBvciBQR1ctVS4gSGVyZSBhcmUg ZmV3IGRpZmZlcmVuY2VzIChub3QgZXhoYXVzdGl2ZSkNCg0KMS4gU0dXLVUgYW5kIFBHVy1VIC0t PiBvbmUgR1RQLVUgdHVubmVsIHBlciBFUFMgYmVhcmVyLiBObyBuZWVkIG9mIGFueSBRRkkgbWFy a2luZy4gVVBGIG9uIHRoZSBvdGhlciBoYW5kIGhhcyBvbmUgR1RQLVUgdHVubmVsIHBlciBQRFUg c2Vzc2lvbi4gRGlmZmVyZW50IFFvUyBmbG93cyB3aXRoaW4gdGhhdCBQRFUgc2Vzc2lvbiBhcmUg aWRlbnRpZmllZCBiYXNlZCBvbiB0aGUgUUZJIG1hcmtpbmcuIFNvIGEgVVBGIGhhcyB0byBzdXBw b3J0IFFGSSBtYXJraW5nLg0KMi4gQW4gVVBGIGNhbiBzdXBwb3J0IGNsYXNzaWZpY2F0aW9uIGFu ZCBlbmNhcHN1bGF0aW9uIEV0aGVybmV0IGZyYW1lcyB3aGVyZWFzIGEgU0dXLVUvUEdXLVUgaGFz IG5vIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgY2xhc3NpZmljYXRpb24gYW5kIGVuY2Fwc3VsYXRp b24gb2YgRXRoZXJuZXQgZnJhbWVzLg0KMy4gQW4gVVBGIHN1cHBvcnRpbmcgRXRoZXJuZXQgUERV IHNlc3Npb24gdHlwZSBtYXkgc3VwcG9ydCBBUlAgcHJveHlpbmcgLyBJUHY2IE5EIFByb3h5aW5n IHdoZXJlYXMgYSBTR1ctVS9QR1ctVSBoYXZlIG5vIHN1Y2ggcmVxdWlyZW1lbnQuDQo0LiBBbiBV UEYgc2hhbGwgc3VwcG9ydCBSUUkgYml0IGZvciByZWZsZWN0aXZlIFFvUy4gQSBQR1ctVS9TR1ct VSBoYXMgbm8gc3VjaCByZXF1aXJlbWVudC4NCg0KT25lIG1heSBzYXkgdGhhdCBTR1ctVSAvIFBH Vy1VIGFsc28gcGxheXMgYSByb2xlIGluIHVzZXIgcGxhbmUgZm9yd2FyZGluZyBhbmQgaGVuY2Ug d2h5IG5vdCBjYWxsIGl0IGEgVVBGPyAgRm9yIHRoZSBsYWNrIG9mIGEgYmV0dGVyIHRlcm1pbm9s b2d5LCAzR1BQIGhhcyBjYWxsZWQgdGhlIGVudGl0eSB0aGF0IHBlcmZvcm1zIHRoZSB1c2VyIHBs YW5lIGZ1bmN0aW9uYWxpdGllcyBhbmQgZmVhdHVyZXMgd2l0aGluIGEgNUcgY29yZSBuZXR3b3Jr IGFzIFVQRi4gVGhvc2UgZnVuY3Rpb25hbGl0aWVzIGFyZSBub3QgZXhhY3RseSBzaW1pbGFyIHRv IEVQQy4NCg0KVGhhbmtzDQpTcmlkaGFyDQoNCk9uIFR1ZSwgT2N0IDIsIDIwMTggYXQgMTA6NDUg UE0gQXJhc2htaWQgQWtoYXZhaW4gPGFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb208bWFpbHRv OmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb20+PiB3cm90ZToNCk5vdCBuZWNlc3NhcmlseSwN Cg0KWW91IGFyZSBjb3JyZWN0IGluIHRoYXQgUEdXIGlzIGEgVVBGLCBidXQgYSBVUEYgaXMgYnkg bm8gbWVhbnMgbGltaXRlZCB0byBQR1cuIEEgVVBGIGlzIGFueSBmdW5jdGlvbiB0aGF0IGNhbiBi ZSBleGVjdXRlZCBvbiB1c2VyIHRyYWZmaWMgaW4gbW9iaWxlIG5ldHdvcmsuIEhhdmluZyBzYWlk IHRoYXQgaG93ZXZlciwgSSB0aGluayB0aGUgZmlyc3QgVVBGcyB0aGF0IHdlIHdpbGwgc2VlIHdp bGwgYmUgaW4gdGhlIGZvcm0gb2YgU0dXLCBQR1cuDQoNCkFyYXNobWlkDQoNCkZyb206IGRtbSBb bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBCZWhjZXQgU2FyaWtheWENClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDIs IDIwMTggMTE6NDQgQU0NClRvOiBTaHVuc3VrZSBIb21tYSA8aG9tbWEuc2h1bnN1a2VAbGFiLm50 dC5jby5qcDxtYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4+DQpDYzogZG1tIDxk bW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0RNTV0gQ29t bWVudHMgdG8gZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtMDENCg0KVVBGIGlzIHZp cnR1YWxpemVkIFBHVywgZm9sa3MuDQpXaGlsZSBQR1cgaXMgZml4ZWQgaW4gbG9jYXRpb24gYW5k IHBvc3NpYmx5IHNlcnZpbmcgYSBsYXJnZSBudW1iZXIgb2YgVUUgd2hpY2ggYXJlIGdlb2dyYXBo aWNhbGx5IGluIHRoZSBhcmVhLCB0aGF0IHBhcnQgb2YgdGhlIGNpdHkgYW5kIHRoYXQgY2l0eSBp dHNlbGYsIFVQRiBjYW4gYmUgZGVwbG95ZWQgY2xvc2VyIHRvIHRoZSBVRSBhbmQgdGh1cyBwcm9i YWJseSBzZXJ2aW5nIHNtYWxsZXIgbnVtYmVyIG9mIFVFcw0KDQpCZWhjZXQNCg0KT24gTW9uLCBP Y3QgMSwgMjAxOCBhdCAxMDo0NyBQTSBTaHVuc3VrZSBIb21tYSA8aG9tbWEuc2h1bnN1a2VAbGFi Lm50dC5jby5qcDxtYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4+IHdyb3RlOg0K VGhhbmtzIERhcmsgZm9yIHlvdXIgZXhwbGFpbmluZyB3aGF0IGlzIFVQRiBpbnN0ZWFkIG9mIG1l Lg0KDQpBbGV4LCBicmllZiBkZWZpbml0aW9ucyBvZiBVUEYgYXJlIGRlc2NyaWJlZCBpbiB0aGUg c2VjdGlvbiA0LjEuMS4xIG9mDQp0aGlzIGRyYWZ0LiBBbHNvLCB5b3UgY2FuIGZpbmQgbW9yZSBk ZXRhaWxzIGluIDNHUFAgVFMyMy41MDEuDQoNClJlZ2FyZHMsDQoNClNodW5zdWtlDQoNCk9uIDIw MTgvMTAvMDEgMjA6MzIsIERpcmsudm9uLUh1Z29AdGVsZWtvbS5kZTxtYWlsdG86RGlyay52b24t SHVnb0B0ZWxla29tLmRlPiB3cm90ZToNCj4gSGkgQWxleCwNCj4gYW5kIHNvcnJ5IGZvciBqdW1w aW5nIGludG8gdGhlIGRpc2N1c3Npb24uLi4NCj4gIEZyb20gbXkgYW5kIChBRkFJSykgM0dQUHMg dW5kZXJzdGFuZGluZyB5b3VyIHNtYXJ0cGhvbmUgaXMgYSBVRSAtIHNpdHRpbmcgb24gdGhlIG90 aGVyIHNpZGUgb2YgUkFOIChnTkIpIC0gd2hlcmVhcyBhIFVQRiBub3JtYWxseSBpcyBzZWVuIGFz IFVQIGVudHJ5IChhbmQgZXhpdCkgb2YgdGhlIDVHIGNvcmUgKGkuZS4gaGFuZGxpbmcgYWxsIFVQ IHRyYWZmaWMgaW4gYSB0cnVlIENQL1VQIHNwbGl0IGZhc2hpb24pLg0KPiBBbnkgb3RoZXIgaWRl YXMgb24gdGhpcz8gQ2FuIHNvbWVvbmUgaW1hZ2luZSBhbnkgc2NlbmFyaW8gd2hlcmUgVUUgaW1w bGVtZW50cyBVUEY/DQo+IFRoYW5rcyENCj4gQmVzdCBSZWdhcmRzDQo+IERpcmsNCj4NCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFsZXhh bmRyZSBQZXRyZXNjdQ0KPiBTZW50OiBNb250YWcsIDEuIE9rdG9iZXIgMjAxOCAxMzoyMg0KPiBU bzogZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbRE1N XSBDb21tZW50cyB0byBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS1hbmFseXNpcy0wMQ0KPg0KPg0K Pg0KPiBMZSAwMS8xMC8yMDE4IMOgIDA1OjUwLCBTaHVuc3VrZSBIb21tYSBhIMOpY3JpdCA6DQo+ PiBIaSBhbGwsDQo+PiAjIFNvcnJ5IGZvciBteSBsYXRlIHJlc3BvbnNlLi4uDQo+Pg0KPj4gVGhh bmsgeW91IGZvciB5b3VyIGxpdmVseSBkaXNjdXNzaW9uLiBJdCBpcyB2ZXJ5IGhlbHBmdWwgZm9y DQo+PiB1bmRlcnN0YW5kaW5nIHBvaW50cyB3aGljaCBuZWVkIHN1cHBsZW1lbnRhbCBleHBsYW5h dGlvbiBhbmQgbW9yZQ0KPj4gY29uc2lkZXJhdGlvbi4NCj4+DQo+PiBGb2xsb3dpbmcgdGhlIGRp c2N1c3Npb24sIHdlJ3JlIHBsYW5uaW5nIHRvIHVwZGF0ZSB0aGUgSS1EIGZvcg0KPj4gY292ZXJp bmcgdGhlIHBvaW50cyBiZWxvdzoNCj4+DQo+PiAtIHRlcm1pbmF0aW9uIHBvaW50cyBvZiBHVFAt VQ0KPj4gICAgIChSQU5zIGFuZCBVUEZzIHRlcm1pbmF0ZSBHVFAtVSBpbiA1R1MuKQ0KPg0KPiBX aGF0IGlzIFVQRj8NCj4NCj4gSSB1bmRlcnN0YW5kIFVQRiBzdGFuZHMgZm9yIFVzZXItUGxhbmUg RnVuY3Rpb24uDQo+DQo+IElzIG15IHNtYXJ0cGhvbmUgc3VwcG9zZWQgdG8gaW1wbGVtZW50IFVQ Rj8NCj4NCj4gQWxleA0KPg0KPj4gLSBzZXR0aW5nIFFvUyBwYXJhbWV0ZXIgb2Ygb3V0ZXIgSVAg aGVhZGVyDQo+PiAgICAgKE5vdGUgdGhhdCBpdCdzIG5vdCBqdXN0IGNvcHkgb2YgaW5uZXIgdG8g b3V0ZXIuKQ0KPj4gLSBwcm9ibGVtcyByZWxhdGVkIHRvIElQIGNvbm5lY3Rpdml0eSAoZS5nLiwg TVRVIGluIElQdjYgbmV0d29ya3MsDQo+PiBJUHY0IGFkZHJlc3MgZHVwbGljYXRpb24pDQo+PiAt IHN1bW1hcnkgb2YgbmV0d29yayBzbGljaW5nIGluIDVHUw0KPj4gICAgIChFLmcuLCAic2xpY2Ug aXMgY29tcG9zZWQgb2YgU01GIGFuZCBVUEZzLiBBTUYgc2VsZWN0cyBTTUYNCj4+IGRlcGVuZGlu ZyBvbiBOU1NBSSBzZW50IGZyb20gVUUsIGFuZCBTTUYgaW5kaWNhdGVzIHRvIHRoZSBVRSB0aGUg VVBGDQo+PiB0aGF0IGl0IGlzDQo+PiBhbGxvY2F0ZWQuIikNCj4+IC0gY2FzZSBzdHVkaWVzIG9u IFVQRiBzZWxlY3Rpb24NCj4+ICAgICAoRS5nLiwgcGFyYW1ldGVycyB1c2VkIGZvciBkZWNpZGlu ZyBkZXN0aW5hdGlvbiBVUEYpICMgT3B0aW1pemluZw0KPj4gZm9yd2FyZGluZyBwYXRocyBzb2x1 dGlvbiBtaWdodCBiZSByZWFsaXplZCB3aXRoIFVQRiBzZWxlY3Rpb24NCj4+IG1lY2hhbmlzbSBp biAzR1BQIGFyY2hpdGVjdHVyZS4gKElELUxPQyBtYXkgYmUgYXBwbGllZCBhcyBzdWNoDQo+PiBt ZWNoYW5pc20uKQ0KPj4NCj4+DQo+PiBJZiB5b3UgaGF2ZSBhbnkgcmVxdWVzdCBmb3IgdXMgb24g dGhpcyB1cGRhdGluZywgcGxlYXNlIGxldCB1cyBrbm93Lg0KPj4NCj4+IEJlc3QgcmVnYXJkcywN Cj4+DQo+PiBTaHVuc3VrZQ0KPj4NCj4+IE9uIDIwMTgvMDkvMDggMzoyOCwgRGlubyBGYXJpbmFj Y2kgd3JvdGU6DQo+Pj4+IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LCBidXQgdGhlcmUgaXMgbm8g Z3VhcmFudGVlIGZvciBhIHByZWNpc2UgUW9TDQo+Pj4+IHdpdGhvdXQgdXNpbmcgc29tZSBzb3J0 IG9mIGVuY2Fwc3VsYXRpb24gYmVpbmcgaXQgR1RQLCBSU1ZQLCBldGMuDQo+Pj4+IEV2ZW4gd2l0 aCB0dW5uZWxzLCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCBhbGwgbm9kZXMgYWxvbmcgdGhl DQo+Pj4+IHBhdGggaGF2ZSB0aGUgc2FtZSBoYXJkd2FyZSBjYXBhYmlsaXR5IGFuZCBjYW4gcHJv dmlkZSB0aGUgc2FtZSBRb1MNCj4+Pj4gdHJlYXRtZW50Lg0KPj4+DQo+Pj4gVGhlcmUgaXMgZXhp c3RpbmcgaGFyZHdhcmUgd2hlcmUgdGhlIGVuY2Fwc3VsYXRvciBjb3BpZXMgaW5uZXIgUW9TIHRv DQo+Pj4gb3V0ZXIgUW9TLiBBbGwgcm91dGVycyBhbG9uZyB0aGUgcGF0aCBqdXN0IHByb2Nlc3Mg dGhlIG91dGVyIFFvUywgbm8NCj4+PiBjaGFuZ2VzIHRvIG9yIG5ldyBwcm9jZXNzaW5nIHJlcXVp cmVtZW50cyBmb3IgdGhlbS4NCj4+Pg0KPj4+PiBGb3IgZXhhbXBsZSwgdGhlIGNvZGUgcG9pbnRz IGluIHJvdXRlcnMgbmVlZCB0byBiZSBjb25maWd1cmVkIHRvDQo+Pj4+IGNvcnJlY3RseSBoYW5k bGUgdGhlIEVYUCBiaXRzIGluIE1QTFMgbGFiZWxzLiBCdXQgdGhlcmUgaXMgbm8NCj4+Pj4gZ3Vh cmFudGVlIHRoYXQgYWxsIHJvdXRlcnMgY2FuIHN1cHBvcnQgYWxsIHZhbHVlcy4gVGhlIEVYUCB2 YWx1ZXMNCj4+Pj4gZ2V0IG1hcHBlZCB0byBjb2RlIHBvaW50cyBidXQgdGhlIG1hcHBpbmcgaXMg bm90IGFsd2F5cyBvbmUgdG8gb25lLg0KPj4+PiAzLWJpdCBFWFBzIGNhbiBtYXAgdG8gNCBjb2Rl IHBvaW50cyBvbiB0aG9zZSByb3V0ZXJzIHdpdGggbGVzcw0KPj4+PiBjYXBhYmxlIEgvVy4NCj4+ Pg0KPj4+IFRoYXQgaXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBtYXR0ZXIuIFRoZSBkaXNjdXNz aW9uIGlzIGFib3V0DQo+Pj4gcmVtYXJraW5nLiBBbmQgaWYgb25lIHJlbWFya3MgdG8gd2hhdCB0 aGUgcGF0aCBjYW5ub3Qgc3VwcG9ydCwgd2VsbA0KPj4+IHRoaW5ncyBkb27igJl0IHdvcmsgYXMg ZXhwZWN0ZWQuDQo+Pj4NCj4+Pj4gU2xpY2luZyBpcyBhbG1vc3QgdGhlIHNhbWUuIEl0IGFsbG93 cyB1c2VyIHRyYWZmaWMgdG8gYmUgbWFwcGVkIHRvDQo+Pj4+IHdoYXQgdGhlIG9wZXJhdG9yIHBy b3ZpZGVzLg0KPj4+PiBJIGFncmVlIHdpdGggeW91IHRoYXQgbmV0d29yayBzaG91bGQgbm90IHRv dWNoL2NoYW5nZSBvcmlnaW5hbA0KPj4+PiBoZWFkZXIgYml0cy4gR1RQIG9yIGFueSBvdGhlciBl bmNhcHN1bGF0aW9uIGVhc2lseSBhbGxvdyBmb3IgdGhpcy4NCj4+Pj4gVGhlIHF1ZXN0aW9uIGlz IHdoZXRoZXIgd2UgY2FuIHByb3ZpZGUgZm9yIHRoaXMgd2l0aG91dCB1c2luZw0KPj4+PiBlbmNh cHN1bGF0aW9uLiBJUHY2IG1pZ2h0IGJlIHRoZSBhbnN3ZXIuIEJ1dCBhcyBUb20gcG9pbnRlZCBv dXQsDQo+Pj4+IGZsb3cgbGFiZWxzIGNhbiBzdGlsbCBjaGFuZ2UgaW4gdGhlIG1pZGRsZS4gSXMg dGhlcmUgYW55IHJvb20gZm9yDQo+Pj4+IGltcHJvdmVtZW50LiBTSURzIG1pZ2h0IHByZXNlbnQg YW4gb3Bwb3J0dW5pdHkuDQo+Pj4NCj4+PiBOb3QgaWYgdGhleSBhcmUgZW5jYXBzdWxhdGVkIGFu ZCByb3V0ZXJzIGRvbuKAmXQgdG91Y2ggcGFja2V0cyBpbnNpZGUuDQo+Pj4NCj4+PiBEaW5vDQo+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBn bWFpbC5jb208bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+XQ0KPj4+Pj4gU2VudDogMDcgU2Vw dGVtYmVyIDIwMTggMTM6MDgNCj4+Pj4+IFRvOiBBcmFzaG1pZCBBa2hhdmFpbiA8YXJhc2htaWQu YWtoYXZhaW5AaHVhd2VpLmNvbTxtYWlsdG86YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT4+ DQo+Pj4+PiBDYzogVG9tIEhlcmJlcnQgPHRvbUBxdWFudG9uaXVtLm5ldDxtYWlsdG86dG9tQHF1 YW50b25pdW0ubmV0Pj47IHRhLW1peWFzYWthQGtkZGktcmVzZWFyY2guanA8bWFpbHRvOnRhLW1p eWFzYWthQGtkZGktcmVzZWFyY2guanA+Ow0KPj4+Pj4gZG1tIDxkbW1AaWV0Zi5vcmc8bWFpbHRv OmRtbUBpZXRmLm9yZz4+DQo+Pj4+PiBTdWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJh ZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtMDENCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rIHlv deKAmWxsIHN0aWxsIGhhdmUgdGhlIFBIQiByZS1tYXJraW5nIGlzc3VlcyBJIG1lbnRpb25lZCBp bg0KPj4+Pj4gcHJldmlvdXMgZW1haWxzLiBUaGUgcXVlc3Rpb24gaXMsIHNob3VsZCB0aGUgbmV0 d29yayB0b3VjaC9jaGFuZ2UNCj4+Pj4+IGFueSBoZWFkZXIgYml0cyBvZiB0aGUgcGFja2V0IHRo ZSBzb3VyY2UgaGFzIGJ1aWx0LiBUaGUgYW5zd2VyDQo+Pj4+PiBzaG91bGQgcHJvYmFibHkgYmUg bm8uDQo+Pj4+Pg0KPj4+Pj4gSGF2aW5nIHNhaWQgdGhhdCwgR1RQIGRpZCBpdCB0aGUgcmlnaHQg d2F5LCBldmVuIHRob3VnaCBpdCBjb3N0IGluDQo+Pj4+PiBoZWFkZXIgbGVuZ3RoLg0KPj4+Pj4N Cj4+Pj4+IERpbm8NCj4+Pj4+DQo+Pj4+Pj4gT24gU2VwIDcsIDIwMTgsIGF0IDg6MjYgQU0sIEFy YXNobWlkIEFraGF2YWluDQo+Pj4+PiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbTxtYWls dG86YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4g Q29ycmVjdCwgZmxvdyBsYWJlbHMgY2FuIGNoYW5nZSBhbG9uZyB0aGUgcGF0aC4gVGhhdCdzIHdo eSBJIGxpa2UNCj4+Pj4+PiB0aGUgc2xpY2luZw0KPj4+Pj4gY29uY2VwdC4NCj4+Pj4+PiBVRXMg Y2FuIHJlcXVlc3Qgc2VydmljZXMgd2l0aCBkaWZmZXJlbnQgYXR0cmlidXRlcywgb3BlcmF0b3Jz DQo+Pj4+Pj4gY29udHJvbCBob3cNCj4+Pj4+IHNlcnZpY2UgcmVxdWVzdCBhcmUgbWFwcGVkIGlu dG8gc2xpY2VzLiBJIHNob3VsZCBsb29rIGludG8gdGhlIGFpcg0KPj4+Pj4gc2lkZSBvZiB0aGUg YnVzaW5lc3MgYW5kIHNlZSB3aGF0IGhhcHBlbnMgdGhlcmUuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206IFRv bSBIZXJiZXJ0IFttYWlsdG86dG9tQHF1YW50b25pdW0ubmV0PG1haWx0bzp0b21AcXVhbnRvbml1 bS5uZXQ+XQ0KPj4+Pj4+PiBTZW50OiAwNyBTZXB0ZW1iZXIgMjAxOCAxMToxMw0KPj4+Pj4+PiBU bzogQXJhc2htaWQgQWtoYXZhaW4gPGFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb208bWFpbHRv OmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb20+Pg0KPj4+Pj4+PiBDYzogRGlubyBGYXJpbmFj Y2kgPGZhcmluYWNjaUBnbWFpbC5jb208bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+PjsNCj4+ Pj4+Pj4gdGEtbWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDxtYWlsdG86dGEtbWl5YXNha2FAa2Rk aS1yZXNlYXJjaC5qcD47IGRtbSA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+Pg0K Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8NCj4+Pj4+Pj4gZHJhZnQtaG1t LWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtMDENCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gRnJpLCBTZXAg NywgMjAxOCBhdCA4OjAxIEFNLCBBcmFzaG1pZCBBa2hhdmFpbg0KPj4+Pj4+PiA8YXJhc2htaWQu YWtoYXZhaW5AaHVhd2VpLmNvbTxtYWlsdG86YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLi5jb20+ PiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJpbmFj Y2lAZ21haWwuY29tPG1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPl0NCj4+Pj4+Pj4+PiBTZW50 OiAwNiBTZXB0ZW1iZXIgMjAxOCAxODo1OQ0KPj4+Pj4+Pj4+IFRvOiBBcmFzaG1pZCBBa2hhdmFp biA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbTxtYWlsdG86YXJhc2htaWQuYWtoYXZhaW5A aHVhd2VpLmNvbT4+DQo+Pj4+Pj4+Pj4gQ2M6IFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5u ZXQ8bWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldD4+OyB0YS1taXlhc2FrYUBrZGRpLQ0KPj4+Pj4g cmVzZWFyY2guanA8aHR0cDovL3Jlc2VhcmNoLmpwPjsNCj4+Pj4+Pj4+PiBkbW0gPGRtbUBpZXRm Lm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPj4NCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0RNTV0g Q29tbWVudHMgdG8NCj4+Pj4+Pj4+PiBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS1hbmFseXNpcy0N Cj4+Pj4+IDAxDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRGlubyBicm91Z2h0IHVwIGEgZ29vZCBw b2ludC4gSGVyZSBpcyBteSB0d28gY2VudHMgd29ydGg6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBO b3Qgc3VyZSB3aGljaCBwb2ludC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBcyBpdCB3YXMgZXhw bGFpbmVkIGJ5IFNyaWRoYXIsICBlYWNoIFVFIGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+Pj4+Pj4+ IGNvbnRleHRzLiBGb3INCj4+Pj4+Pj4+PiBleGFtcGxlLCB0b2RheSBzb21lIG9wZXJhdG9ycyBw cm92aWRlIERhdGEgYW5kIFZvTFRFIHNlcnZpY2UgdG8NCj4+Pj4+Pj4+PiB0aGVpciBjdXN0b21l cnMuIFRoZXNlIHR3byBzZXJ2aWNlcyBhcmUgcmVwcmVzZW50ZWQgYnkgc2VwYXJhdGUNCj4+Pj4+ Pj4+PiBHVFAgdHVubmVscyBpbiB0aGUgY29yZSB3aXRoIGVhY2ggdHVubmVsIHRpZWQgdXAgdG8g YSBwYXJ0aWN1bGFyIFFvUy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSVB2NCBkaWRuJ3QgZml0 IHRoZSBiaWxsIHdoZW4gR1RQIHdvcmsgd2FzIHVuZGVyIHdheSBhcyBpdA0KPj4+Pj4+Pj4+PiBj b3VsZG4ndCB1bmlxdWVseSBpZGVudGlmeSBtdWx0aXBsZSBVRQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gVGhlcmUgaXMgbm8gcmVhc29uIHdoeSBpdCBzaG91bGRu4oCZdC4gQW5kIElQdjYsIGZvciB0 aGlzDQo+Pj4+Pj4+Pj4gdXNlLWNhc2UgZG9lc27igJl0IGFkZCBhbnl0aGluZyBuZXcgb3RoZXIg dGhhbiBhIDI4IGJpdA0KPj4+Pj4+Pj4+IHRyYWZmaWMtY2xhc3MvZmxvdy1sYWJlbCB0aGF0IGNh biBwcm92aWRlIG1vcmUgYml0cyBmb3Ig4oCcbmV3DQo+Pj4+PiBmdW5jdGlvbmFsaXR54oCdLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBbQXJhc2htaWRdICBBbmQgdGhhdCdzIHdoYXQg SSBtZWFudC4gSGF2aW5nIGEgZmxvdyBsYWJlbCBpcyBoYW5keS4NCj4+Pj4+Pj4+IFdlIGNhbiBw ZXJoYXBzIHVzZSBpdCB0byBpZGVudGlmeSBkaWZmZXJlbnQgVUUgc2Vzc2lvbnMuDQo+Pj4+Pj4+ Pg0KPj4+Pj4+PiBDYXJlZnVsIGlmIHlvdSB1c2UgdGhlIGZsb3cgbGFiZWwgdG8gaWRlbnRpZnkg Zmxvd3MuIEl0IHNob3VsZCBiZQ0KPj4+Pj4+PiBjb25zaWRlcmVkICJzb2Z0IGlkZW50aWZpY2F0 aW9uIiBzaW5jZSBpdCBtaWdodCBub3QgYWx3YXlzIGJlDQo+Pj4+Pj4+IGNvcnJlY3QgKGl0IGNh biBiZSBjaGFuZ2VkIGVuIHJvdXRlLCBpc24ndCBwcm90ZWN0ZWQgYnkgYW55DQo+Pj4+Pj4+IGNo ZWNrc3VtLCBhbnlvbmUgY2FuIHNldCBpdCBob3dldmVyIHRoZXkgd2FudCwgZXRjLikuIEl0J3Mg dXNlZnVsDQo+Pj4+Pj4+IGZvciB0aGluZ3MgbGlrZSBFQ01QIHRoYXQgZG9uJ3QgcmVxdWlyZSAx MDAlIGFjY3VyYWN5IGluDQo+Pj4+Pj4+IGlkZW50aWZ5aW5nIGZsb3cuIFRoZSBmbG93IGxhYmVs IHdhcyBicmllZmx5IGNvbnNpZGVyZWQgZm9yDQo+Pj4+Pj4+IGhvbGRpbmcgVk5JcyBpbiBuZXR3 b3JrIHZpcnR1YWxpemF0aW9uLCBidXQgd2UNCj4+Pj4+IHRhbGtlZCB0aGVtIG91dCBvZiB0aGF0 Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUb20NCj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBz ZXNzaW9ucy9jb250ZXh0L2JlYXJlci4gU28sIEdUUCBhbmQgVEVJRCBkaWQgdGhlIGpvYi4gQnV0 IEkNCj4+Pj4+Pj4+Pj4gYWdyZWUgd2l0aA0KPj4+Pj4+Pj4+IERpbm8gdGhhdCBJUHY2IGlzIG11 Y2ggbW9yZSB2ZXJzYXRpbGUgYW5kIGlzIGRlZmluaXRlbHkgd29ydGgNCj4+Pj4+Pj4+PiBsb29r aW5nIGF0IGFzIGFuIGFsdGVybmF0aXZlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhhdCBpcyBu b3Qgd2hhdCBJIHNhaWQuIEkgc2FpZCDigJxJUCBjb3VsZCBoYXZlIHNvbHZlZCB0aGlzDQo+Pj4+ Pj4+Pj4gcHJvYmxlbeKAnS4gQW5kDQo+Pj4+PiDigJxJUOKAnQ0KPj4+Pj4+Pj4+IG1lYW5zIGVp dGhlciBJUHY0IG9yIElQdjYsIG9yIGJvdGggYXQgdGhlIHNhbWUgdGltZS4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gW0FyYXNobWlkXQ0KPj4+Pj4+Pj4gSG93IHdvdWxkIHdlIGVtcGxv eSBJUHY0IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gZGlmZmVyZW50IFVFDQo+Pj4+Pj4+PiBzZXNz aW9ucy4NCj4+Pj4+Pj4gVE9TPw0KPj4+Pj4+Pj4gT3IgeW91IG1lYW4gdXNpbmcgZW5jYXBzdWxh dGlvbj8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQSBmYWN0b3Igd29ydGggY29u c2lkZXJpbmcgdGhvdWdoIGlzIHRoYXQgdGhlIHVzZSBvZiBHVFAgYW5kDQo+Pj4+Pj4+Pj4+IFRF SUQgaW4gbW9iaWxlDQo+Pj4+Pj4+Pj4gY29yZSBhbGxvd3Mgb3BlcmF0b3JzIHRvIGRlYWwgd2l0 aCBRb1Mgb24gdGhlaXIgb3duIHRlcm1zLiBUaGUNCj4+Pj4+Pj4+PiB0dW5uZWxzIHdpdGggc3Bl Y2lmaWMgb3BlcmF0b3ItY29udHJvbGxlZCBRb1MgYXJlIGVzdGFibGlzaGVkDQo+Pj4+Pj4+Pj4g YnkgdGhlIGNvbnRyb2wgcGxhbmUgYmV0d2VlbiBlTkIsIFNHVywgYW5kIFBHVy4gVUVzIG9yDQo+ Pj4+Pj4+Pj4gYXBwbGljYXRpb25zIHNpdHRpbmcgaW4gdGhlIFVFcyBoYXZlIG5vIHNheSBpbiB0 aGlzLiBXZWxsIGF0DQo+Pj4+Pj4+Pj4gbGVhc3QgdGlsbCB0aGUgcGFja2V0IGV4aXRzIG9wZXJh dG9yJ3MNCj4+Pj4+Pj4gbmV0d29yay4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZSBwcm9ibGVt IHdpdGggb25lIGhlYWRlciwgaXMgdGhhdCBpZiB5b3UgcmUtbWFyayAoa25vd24gYXMNCj4+Pj4+ Pj4+PiBQSEIgbWFya2lnbiBpbiB0aGUgb2xlIGRheXMpIHlvdSBsb3NlIHRoZSBvcmlnaW5hbCB2 YWx1ZS4NCj4+Pj4+Pj4+PiBFbmNhcHN1bGF0aW9uIGlzIHVzZWZ1bCBoZXJlIGJlY2F1c2UgeW91 IGNhbiBtYXAgdGhlIGlubmVyIHRvDQo+Pj4+Pj4+Pj4gb3V0ZXIgYW5kIGFueXdoZXJlIGFsb25n IHRoZSBwYXRoIHlvdSBjYW4gUEhCIHJlbWFyayBvbiB0aGUNCj4+Pj4+Pj4+PiBvdXRlciBoZWFk ZXIuIEFuZCB0aGVuIHRoZSBkZXN0aW5hdGlvbiBjYW4gc2VlIHRoZSBvcmlnbmFsDQo+Pj4+Pj4+ Pj4gc291cmNl4oCZcyBUb1MvUW9TL1RDL2Zsb3ctbGFiZWwNCj4+Pj4+IHdoYXRldmVyLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBbQXJhc2htaWRdIFllcywgSSBhZ3JlZS4gVGhlIG9y aWdpbmFsIHZhbHVlIGlzIGxvc3Qgd2l0aCBQSEIuDQo+Pj4+Pj4+PiBFbmNhcHN1bGF0aW9uIGNl cnRhaW5seSBtYWtlcyB0aGluZ3MgZWFzaWVyIGFuZCB0aGUgaW5uZXIgdG8NCj4+Pj4+Pj4+IG91 dGVyIG1hcHBpbmcgdHJpY2sgaGFzIGJlZW4gd2lkZWx5IHVzZWQgaW4gSVAgYW5kIE1QTFMobXVs dGlwbGUNCj4+Pj4+Pj4+IGxhYmVscyBsaWtlIHNlcnZpY2UgYW5kIHRyYW5zcG9ydCkNCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVXNpbmcgdGhlIGluZm9ybWF0aW9uIGluIFVFJ3Mg SVAgcGFja2V0IGhlYWRlciBjYW4gamVvcGFyZGlzZQ0KPj4+Pj4+Pj4+PiB0aGUgYWJvdmUgdGln aHQgUW9TIGNvbnRyb2wuIEkgdGhpbmsgZ29pbmcNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE5vdCBp ZiB5b3UgZW5jYXBzdWxhdGUuIEJ1dCBub3RlIHdpdGggU1J2NiwgeW91IGNhbiBwb3NzaWJseQ0K Pj4+Pj4+Pj4+IHJldGFpbiB0aGUgb3JpZ2luYWwgZmxvdy1sYWJlbCBpZiB0aGUgU0lEIGNhbiBy ZXRhaW4gdGhvc2UgYml0cw0KPj4+Pj4+Pj4+IGJlZm9yZSBvdmVyd3JpdGluZyB0aGUgZGVzdGlu YXRpb24gYWRkcmVzcyBmcm9tIHRoZSBvcHRpb27igJlzIHZhbHVlLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IFtBcmFzaG1pZF0gQWdyZWUuIEVuY2Fwc3VsYXRpb24gZG9lcyB0aGUgdHJpY2sgYWdhaW4u IFRoYXQncyB3aHkNCj4+Pj4+Pj4+IEdUUCBoYXMgd29ya2VkIHdlbGwgYW5kIHNlcnZlZCB0aGUg cHVycG9zIGluIHRoZSBtb2JpbGUNCj4+Pj4+Pj4+IGJhY2staGF1bCBzbyBmYXIuDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRGlubw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IGRvd24g dGhpcyBwYXRoLCBvcGVyYXRvcnMgbmVlZCBwcm9vZiB0aGF0IHRoZXkgd2lsbCBiZSBzdGlsbA0K Pj4+Pj4+Pj4+PiBpbiB0aGUgZHJpdmluZw0KPj4+Pj4+Pj4+IHNlYXQgYW5kIFFvUyBjYW5ub3Qg YmUgZGljdGF0ZWQvdGFtcGVyZWQgYnkgdGhlIFVFIG9yIGFueQ0KPj4+Pj4+Pj4+IGFwcGxpY2F0 aW9uIHJ1bm5pbmcgaW4gaXQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE5vdywgaGVyZSBpcyBh biBpbnRlcmVzdGluZyBxdWVzdGlvbiBmb3IgdGhlIG9wZXJhdG9ycy4gV291bGQNCj4+Pj4+Pj4+ Pj4gYW55IG9wZXJhdG9yDQo+Pj4+Pj4+Pj4gYmUgaW50ZXJlc3RlZCBpbiBhbGxvd2luZyBRb1Mg IHRvIGJlIHNldCBieSB0aGUgVUUgb3IgYnkNCj4+Pj4+Pj4+PiBhcHBsaWNhdGlvbnMgcnVubmlu ZyBpbiB0aGUgVUUgYW5kIGNoYXJnZWQgZm9yIGJ5IHRoZSBuZXR3b3JrPw0KPj4+Pj4+Pj4+ICJZ ZXMiIGNvdWxkIHBvdGVudGlhbGx5IGltcGx5IGltcGFjdHMgb24gdGhlIGFpciBpbnRlcmZhY2Us IFVFDQo+Pj4+Pj4+Pj4gcmVzb3VyY2UgYmxvY2sgYWxsb2NhdGlvbiBhbmQgY2FuIG1ha2Ugc2No ZWR1bGluZyBvbiB0aGUgUkFODQo+Pj4+Pj4+Pj4gc2lkZQ0KPj4+Pj4gbXVjaCBtb3JlIGNvbXBs ZXguDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFyYXNobWlkDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4g RnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERpbm8NCj4+Pj4+Pj4+Pj4+IEZhcmluYWNjaQ0KPj4+ Pj4+Pj4+Pj4gU2VudDogMDYgU2VwdGVtYmVyIDIwMTggMTI6NDUNCj4+Pj4+Pj4+Pj4+IFRvOiBU b20gSGVyYmVydCA8dG9tQHF1YW50b25pdW0ubmV0PG1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQ+ Pg0KPj4+Pj4+Pj4+Pj4gQ2M6IHRhLW1peWFzYWthQGtkZGktcmVzZWFyY2guanA8bWFpbHRvOnRh LW1peWFzYWthQGtkZGktcmVzZWFyY2guanA+OyBkbW0gPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t QGlldGYub3JnPj4NCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbRE1NXSBDb21tZW50cyB0byBk cmFmdC1obW0tZG1tLTVnLXVwbGFuZS0NCj4+Pj4+IGFuYWx5c2lzLQ0KPj4+Pj4+PiAwMQ0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBCZWhjZXQsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ PiBJIHdhcyB0aGlua2luZyBpZiBURUlEIGlzIG5lZWQgdGhlbiB0aGF0IGNhbiBiZSBlbmNvZGVk IGluIGENCj4+Pj4+Pj4+Pj4+PiBsb2NhdG9yIGVhc2lseSBlbm91Z2guDQo+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+PiBUb20NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBOb3QgaWYgYSBsb2Nh dG9yIGlzIGEgUEdXIHRoYXQgaXMgc2hhcmVkIGJ5IG1hbnkgVUVzLg0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+IDNHUFAgd2FudHMgcGVyIGJlYXJlciBhd2FyZW5lc3Mgc28gdGhleSBuZWVkIGEg c3BlY2lmaWMgSUQsDQo+Pj4+Pj4+Pj4+PiB0aGF0IGNvdWxkIGhhdmUgYmVlbiB0aGUgVUXigJlz IElQIGFkZHJlc3MuIEFuZCB3aXRoIElQdjYgaXQNCj4+Pj4+Pj4+Pj4+IGNhbiBiZSB1bmlxdWUg YW5kIG5vdCB0aGUgaXNzdWUgdGhhdCBTcmlkaGFyIGJyb3VnaHQgdXAuDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gSWYgSUxBIHdhcyBpbiB1c2UsIGp1c3QgdXNlIHRoZSBJTEEtSUQgZm9yIHRo aXMgcHVycG9zZS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBEaW5vDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+Pj4+IGRtbSBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+IGRtbUBpZXRmLm9y ZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbW0NCj4+Pj4+Pj4+DQo+Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGRtbSBtYWlsaW5nIGxp c3QNCj4+PiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPj4+DQo+Pg0KPj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1tIG1haWxpbmcg bGlzdA0KPiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1tIG1haWxpbmcgbGlzdA0KPiBkbW1AaWV0Zi5v cmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbW0NCj4NCg0KDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KU2h1bnN1a2UgSG9tbWENCjxob21tYS4uc2h1bnN1a2VAbGFiLm50dC5jby5qcDxtYWlsdG86 aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4+DQpURUw6ICs4MSA0MjIgNTkgMzQ4Ng0KRkFY OiArODEgNDIyIDYwIDc0NjANCg0KTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW1zIExhYnMuDQpN dXNhc2hpbm8gY2l0eSwgVG9reW8sIEphcGFuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGll dGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RtbQ0KDQoNCi0tDQogb19fDQogXz4gIC9fXw0KKF8pIFwoXykuLi4gQnVybiBm YXQgbm90IGZ1ZWwgLSBCaWtlIGFsb25nIHRvIGEgaGVhbHRoaWVyIGxpZmUgYW5kIGNsZWFuZXIN CndvcmxkISA6KQ0KDQpTcmlkaGFyIEJoYXNrYXJhbg0K --_000_D57109449177B54F8B9C093953AC5BCD755E5415yyzeml704chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PldlbGwgcHV0IFNyaWRoYXLigKYgVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgY2xhcmlmaWNh dGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3BlYWtpbmcg b2YgUW9TIEZsb3cgSWRlbnRpZmllcnMsIEkgYW0gYXNzdW1pbmcgdGhhdCBtYXBwaW5nIHRoZSBR b1MgcmVxdWlyZW1lbnRzIGZyb20gNUcgY29yZSB0byB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQg bm9kZXMgKHJvdXRlcnMsDQogc3dpdGNoZXMpIGFuZCB2aWNlIHZlcnNhIGhhcyBub3QgYmVlbiBj aGFuZ2VkLiBJcyB0aGlzIGNvcnJlY3QgU3JpZGhhcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkFyYXNobWlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTcmlkaGFyIEJoYXNrYXJhbiBbbWFpbHRv OnNyaWRoYXIuYmhhc2thcmFuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwMyBPY3Rv YmVyIDIwMTggMTI6Mjk8YnI+DQo8Yj5Ubzo8L2I+IEFyYXNobWlkIEFraGF2YWluICZsdDthcmFz aG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2FyaWtheWFAaWVl ZS5vcmc7IGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA7IGRtbUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRtbS01Zy11cGxh bmUtYW5hbHlzaXMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkEgVVBGIGlzIGFueSBmdW5jdGlvbiB0aGF0IGNhbiBiZSBleGVjdXRlZCBvbiB1c2VyIHRyYWZm aWMgaW4gbW9iaWxlIG5ldHdvcmsuIEhhdmluZyBzYWlkIHRoYXQgaG93ZXZlciwgSSB0aGluayB0 aGUgZmlyc3QgVVBGcyB0aGF0IHdlIHdpbGwgc2VlIHdpbGwgYmUgaW4gdGhlDQogZm9ybSBvZiBT R1csIFBHVy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkV2ZW4gdGhpcyBpcyBub3QgYWNjdXJhdGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgVVBGIGlzIGEgPGI+PHU+NUcg c3lzdGVtIGNvcmUgbmV0d29yazwvdT48L2I+IGVudGl0eSB3aGVyZWFzIHRoZSBTR1ctVSBhbmQg UEdXLVUgYXJlIEVQQyBjb3JlIG5ldHdvcmsgZW50aXRpZXMuIDVHIGNvcmUgbmV0d29yayBoYXMg bWFueSBkaWZmZXJlbmNlcyBmcm9tIEVQQy4gVG8gYXZvaWQgY29uZnVzaW9uIGl0IHNob3VsZCBi ZSBub3RlZCB0aGF0IDVHIE5SIHJhZGlvIGNhbiBiZSBkZXBsb3llZCB3aXRoDQogRVBDIGFzIHRo ZSBjb3JlIG5ldHdvcmsgYW5kIHRlY2huaWNhbGx5IHN1Y2ggZGVwbG95bWVudHMgY2FuIGFsc28g YmUgY2FsbGVkIGFzIDVHIGRlcGxveW1lbnRzLiBCdXQgYW4gVVBGIGhhcyBubyByb2xlIGluIHN1 Y2ggZGVwbG95bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvbWUgb2YgdGhlIHVzZXIgcGxhbmUgZnVuY3Rpb25hbGl0aWVzIG9mIGFu IFVQRiBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbSBTR1ctVSBvciBQR1ctVS4gSGVyZSBh cmUgZmV3IGRpZmZlcmVuY2VzIChub3QgZXhoYXVzdGl2ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gU0dXLVUgYW5kIFBHVy1VIC0tJmd0 OyBvbmUgR1RQLVUgdHVubmVsIHBlciBFUFMgYmVhcmVyLiBObyBuZWVkIG9mIGFueSBRRkkgbWFy a2luZy4gVVBGIG9uIHRoZSBvdGhlciBoYW5kIGhhcyBvbmUgR1RQLVUgdHVubmVsIHBlciBQRFUg c2Vzc2lvbi4gRGlmZmVyZW50IFFvUyBmbG93cyB3aXRoaW4gdGhhdCBQRFUgc2Vzc2lvbiBhcmUg aWRlbnRpZmllZCBiYXNlZCBvbiB0aGUgUUZJIG1hcmtpbmcuIFNvIGEgVVBGDQogaGFzIHRvIHN1 cHBvcnQgUUZJIG1hcmtpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yLiBBbiBVUEYgY2FuIHN1cHBvcnQgY2xhc3NpZmljYXRpb24gYW5kIGVu Y2Fwc3VsYXRpb24gRXRoZXJuZXQgZnJhbWVzIHdoZXJlYXMgYSBTR1ctVS9QR1ctVSBoYXMgbm8g cmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBjbGFzc2lmaWNhdGlvbiBhbmQgZW5jYXBzdWxhdGlvbiBv ZiBFdGhlcm5ldCBmcmFtZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4zLiBBbiBVUEYgc3VwcG9ydGluZyBFdGhlcm5ldCBQRFUgc2Vzc2lvbiB0 eXBlIG1heSBzdXBwb3J0IEFSUCBwcm94eWluZyAvIElQdjYgTkQgUHJveHlpbmcgd2hlcmVhcyBh IFNHVy1VL1BHVy1VIGhhdmUgbm8gc3VjaCByZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIEFuIFVQRiBzaGFsbCBzdXBwb3J0 IFJRSSBiaXQgZm9yIHJlZmxlY3RpdmUgUW9TLiBBIFBHVy1VL1NHVy1VIGhhcyBubyBzdWNoIHJl cXVpcmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbmUgbWF5IHNheSB0aGF0IFNHVy1VIC8gUEdXLVUgYWxzbyBwbGF5cyBhIHJvbGUg aW4gdXNlciBwbGFuZSBmb3J3YXJkaW5nIGFuZCBoZW5jZSB3aHkgbm90IGNhbGwgaXQgYSBVUEY/ Jm5ic3A7IEZvciB0aGUgbGFjayBvZiBhIGJldHRlciB0ZXJtaW5vbG9neSwgM0dQUCBoYXMgY2Fs bGVkIHRoZSBlbnRpdHkgdGhhdCBwZXJmb3JtcyB0aGUgdXNlciBwbGFuZSBmdW5jdGlvbmFsaXRp ZXMgYW5kIGZlYXR1cmVzIHdpdGhpbg0KIGEgPGI+PHU+NUcgY29yZSBuZXR3b3JrPC91PjwvYj4g YXMgVVBGLiBUaG9zZSBmdW5jdGlvbmFsaXRpZXMgYXJlIG5vdCBleGFjdGx5IHNpbWlsYXIgdG8g RVBDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNyaWRoYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDIsIDIwMTggYXQgMTA6NDUgUE0gQXJhc2htaWQg QWtoYXZhaW4gJmx0OzxhIGhyZWY9Im1haWx0bzphcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29t Ij5hcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IG5lY2Vzc2FyaWx5LDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PllvdSBhcmUgY29ycmVjdCBpbiB0aGF0IFBHVyBpcyBhIFVQRiwgYnV0IGEgVVBGIGlzIGJ5IG5v IG1lYW5zIGxpbWl0ZWQgdG8gUEdXLiBBIFVQRiBpcw0KIGFueSBmdW5jdGlvbiB0aGF0IGNhbiBi ZSBleGVjdXRlZCBvbiB1c2VyIHRyYWZmaWMgaW4gbW9iaWxlIG5ldHdvcmsuIEhhdmluZyBzYWlk IHRoYXQgaG93ZXZlciwgSSB0aGluayB0aGUgZmlyc3QgVVBGcyB0aGF0IHdlIHdpbGwgc2VlIHdp bGwgYmUgaW4gdGhlIGZvcm0gb2YgU0dXLCBQR1cuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXJhc2htaWQ8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBkbW0NCiBbbWFpbHRvOjwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kbW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5CZWhjZXQgU2FyaWtheWE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAwMiwg MjAxOCAxMTo0NCBBTTxicj4NCjxiPlRvOjwvYj4gU2h1bnN1a2UgSG9tbWEgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcCIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmhvbW1hLnNodW5zdWtlQGxhYi5udHQu Y28uanA8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IGRtbSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kbW1AaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFu YWx5c2lzLTAxPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+VVBGIGlzIHZpcnR1YWxpemVkIFBHVywgZm9sa3MuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPldo aWxlIFBHVyBpcyBmaXhlZCBpbiBsb2NhdGlvbiBhbmQgcG9zc2libHkgc2VydmluZyBhIGxhcmdl IG51bWJlciBvZiBVRSB3aGljaCBhcmUgZ2VvZ3JhcGhpY2FsbHkgaW4gdGhlIGFyZWEsIHRoYXQg cGFydCBvZiB0aGUgY2l0eSBhbmQgdGhhdCBjaXR5IGl0c2VsZiwgVVBGDQogY2FuIGJlIGRlcGxv eWVkIGNsb3NlciB0byB0aGUgVUUgYW5kIHRodXMgcHJvYmFibHkgc2VydmluZyBzbWFsbGVyIG51 bWJlciBvZiBVRXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5CZWhjZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBNb24sIE9jdCAxLCAyMDE4IGF0IDEwOjQ3IFBNIFNodW5zdWtlIEhvbW1h ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanAi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aG9tbWEuc2h1bnN1a2VAbGFiLm50 dC5jby5qcDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsNCiB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhhbmtzIERhcmsgZm9yIHlvdXIgZXhwbGFpbmluZyB3aGF0IGlzIFVQRiBpbnN0ZWFkIG9m IG1lLjxicj4NCjxicj4NCkFsZXgsIGJyaWVmIGRlZmluaXRpb25zIG9mIFVQRiBhcmUgZGVzY3Jp YmVkIGluIHRoZSBzZWN0aW9uIDQuMS4xLjEgb2YgPGJyPg0KdGhpcyBkcmFmdC4gQWxzbywgeW91 IGNhbiBmaW5kIG1vcmUgZGV0YWlscyBpbiAzR1BQIFRTMjMuNTAxLjxicj4NCjxicj4NClJlZ2Fy ZHMsPGJyPg0KPGJyPg0KU2h1bnN1a2U8YnI+DQo8YnI+DQpPbiAyMDE4LzEwLzAxIDIwOjMyLCA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkRpcmsudm9uLUh1Z29AdGVsZWtvbS5kZSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5EaXJrLnZvbi1IdWdvQHRlbGVrb20uZGU8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4gd3JvdGU6PGJyPg0KJmd0OyBIaSBBbGV4LDxicj4NCiZn dDsgYW5kIHNvcnJ5IGZvciBqdW1waW5nIGludG8gdGhlIGRpc2N1c3Npb24uLi48YnI+DQomZ3Q7 Jm5ic3A7IEZyb20gbXkgYW5kIChBRkFJSykgM0dQUHMgdW5kZXJzdGFuZGluZyB5b3VyIHNtYXJ0 cGhvbmUgaXMgYSBVRSAtIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgUkFOIChnTkIpIC0g d2hlcmVhcyBhIFVQRiBub3JtYWxseSBpcyBzZWVuIGFzIFVQIGVudHJ5IChhbmQgZXhpdCkgb2Yg dGhlIDVHIGNvcmUgKGkuZS4gaGFuZGxpbmcgYWxsIFVQIHRyYWZmaWMgaW4gYSB0cnVlIENQL1VQ IHNwbGl0IGZhc2hpb24pLjxicj4NCiZndDsgQW55IG90aGVyIGlkZWFzIG9uIHRoaXM/IENhbiBz b21lb25lIGltYWdpbmUgYW55IHNjZW5hcmlvIHdoZXJlIFVFIGltcGxlbWVudHMgVVBGPzxicj4N CiZndDsgVGhhbmtzITxicj4NCiZndDsgQmVzdCBSZWdhcmRzPGJyPg0KJmd0OyBEaXJrPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9t OiBkbW0gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbS1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBl dHJlc2N1PGJyPg0KJmd0OyBTZW50OiBNb250YWcsIDEuIE9rdG9iZXIgMjAxOCAxMzoyMjxicj4N CiZndDsgVG86IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvIGRyYWZ0 LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBMZSAwMS8xMC8yMDE4IMOgIDA1OjUwLCBTaHVuc3VrZSBIb21tYSBh IMOpY3JpdCZuYnNwOzo8YnI+DQomZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZndDsgIyBTb3Jy eSBmb3IgbXkgbGF0ZSByZXNwb25zZS4uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhh bmsgeW91IGZvciB5b3VyIGxpdmVseSBkaXNjdXNzaW9uLiBJdCBpcyB2ZXJ5IGhlbHBmdWwgZm9y PGJyPg0KJmd0OyZndDsgdW5kZXJzdGFuZGluZyBwb2ludHMgd2hpY2ggbmVlZCBzdXBwbGVtZW50 YWwgZXhwbGFuYXRpb24gYW5kIG1vcmU8YnI+DQomZ3Q7Jmd0OyBjb25zaWRlcmF0aW9uLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uLCB3ZSdyZSBw bGFubmluZyB0byB1cGRhdGUgdGhlIEktRCBmb3I8YnI+DQomZ3Q7Jmd0OyBjb3ZlcmluZyB0aGUg cG9pbnRzIGJlbG93Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLSB0ZXJtaW5hdGlvbiBw b2ludHMgb2YgR1RQLVU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgKFJBTnMgYW5k IFVQRnMgdGVybWluYXRlIEdUUC1VIGluIDVHUy4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoYXQg aXMgVVBGPzxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHVuZGVyc3RhbmQgVVBGIHN0YW5kcyBmb3Ig VXNlci1QbGFuZSBGdW5jdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXMgbXkgc21hcnRwaG9u ZSBzdXBwb3NlZCB0byBpbXBsZW1lbnQgVVBGPzxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGV4PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAtIHNldHRpbmcgUW9TIHBhcmFtZXRlciBvZiBvdXRlciBJ UCBoZWFkZXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgKE5vdGUgdGhhdCBpdCdz IG5vdCBqdXN0IGNvcHkgb2YgaW5uZXIgdG8gb3V0ZXIuKTxicj4NCiZndDsmZ3Q7IC0gcHJvYmxl bXMgcmVsYXRlZCB0byBJUCBjb25uZWN0aXZpdHkgKGUuZy4sIE1UVSBpbiBJUHY2IG5ldHdvcmtz LDxicj4NCiZndDsmZ3Q7IElQdjQgYWRkcmVzcyBkdXBsaWNhdGlvbik8YnI+DQomZ3Q7Jmd0OyAt IHN1bW1hcnkgb2YgbmV0d29yayBzbGljaW5nIGluIDVHUzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyZuYnNwOyAoRS5nLiwgJnF1b3Q7c2xpY2UgaXMgY29tcG9zZWQgb2YgU01GIGFuZCBVUEZz LiBBTUYgc2VsZWN0cyBTTUY8YnI+DQomZ3Q7Jmd0OyBkZXBlbmRpbmcgb24gTlNTQUkgc2VudCBm cm9tIFVFLCBhbmQgU01GIGluZGljYXRlcyB0byB0aGUgVUUgdGhlIFVQRjxicj4NCiZndDsmZ3Q7 IHRoYXQgaXQgaXM8YnI+DQomZ3Q7Jmd0OyBhbGxvY2F0ZWQuJnF1b3Q7KTxicj4NCiZndDsmZ3Q7 IC0gY2FzZSBzdHVkaWVzIG9uIFVQRiBzZWxlY3Rpb248YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgKEUuZy4sIHBhcmFtZXRlcnMgdXNlZCBmb3IgZGVjaWRpbmcgZGVzdGluYXRpb24g VVBGKSAjIE9wdGltaXppbmc8YnI+DQomZ3Q7Jmd0OyBmb3J3YXJkaW5nIHBhdGhzIHNvbHV0aW9u IG1pZ2h0IGJlIHJlYWxpemVkIHdpdGggVVBGIHNlbGVjdGlvbjxicj4NCiZndDsmZ3Q7IG1lY2hh bmlzbSBpbiAzR1BQIGFyY2hpdGVjdHVyZS4gKElELUxPQyBtYXkgYmUgYXBwbGllZCBhcyBzdWNo PGJyPg0KJmd0OyZndDsgbWVjaGFuaXNtLik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgSWYgeW91IGhhdmUgYW55IHJlcXVlc3QgZm9yIHVzIG9uIHRoaXMgdXBkYXRp bmcsIHBsZWFzZSBsZXQgdXMga25vdy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlc3Qg cmVnYXJkcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNodW5zdWtlPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBPbiAyMDE4LzA5LzA4IDM6MjgsIERpbm8gRmFyaW5hY2NpIHdyb3Rl Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQsIGJ1dCB0aGVy ZSBpcyBubyBndWFyYW50ZWUgZm9yIGEgcHJlY2lzZSBRb1M8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IHdpdGhvdXQgdXNpbmcgc29tZSBzb3J0IG9mIGVuY2Fwc3VsYXRpb24gYmVpbmcgaXQgR1RQLCBS U1ZQLCBldGMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBFdmVuIHdpdGggdHVubmVscywgdGhlcmUg aXMgbm8gZ3VhcmFudGVlIHRoYXQgYWxsIG5vZGVzIGFsb25nIHRoZTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgcGF0aCBoYXZlIHRoZSBzYW1lIGhhcmR3YXJlIGNhcGFiaWxpdHkgYW5kIGNhbiBwcm92 aWRlIHRoZSBzYW1lIFFvUzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdHJlYXRtZW50Ljxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGVyZSBpcyBleGlzdGluZyBoYXJkd2FyZSB3 aGVyZSB0aGUgZW5jYXBzdWxhdG9yIGNvcGllcyBpbm5lciBRb1MgdG88YnI+DQomZ3Q7Jmd0OyZn dDsgb3V0ZXIgUW9TLiBBbGwgcm91dGVycyBhbG9uZyB0aGUgcGF0aCBqdXN0IHByb2Nlc3MgdGhl IG91dGVyIFFvUywgbm88YnI+DQomZ3Q7Jmd0OyZndDsgY2hhbmdlcyB0byBvciBuZXcgcHJvY2Vz c2luZyByZXF1aXJlbWVudHMgZm9yIHRoZW0uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBGb3IgZXhhbXBsZSwgdGhlIGNvZGUgcG9pbnRzIGluIHJvdXRlcnMgbmVlZCB0 byBiZSBjb25maWd1cmVkIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBjb3JyZWN0bHkgaGFuZGxl IHRoZSBFWFAgYml0cyBpbiBNUExTIGxhYmVscy4gQnV0IHRoZXJlIGlzIG5vPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBndWFyYW50ZWUgdGhhdCBhbGwgcm91dGVycyBjYW4gc3VwcG9ydCBhbGwgdmFs dWVzLiBUaGUgRVhQIHZhbHVlczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZ2V0IG1hcHBlZCB0byBj b2RlIHBvaW50cyBidXQgdGhlIG1hcHBpbmcgaXMgbm90IGFsd2F5cyBvbmUgdG8gb25lLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgMy1iaXQgRVhQcyBjYW4gbWFwIHRvIDQgY29kZSBwb2ludHMgb24g dGhvc2Ugcm91dGVycyB3aXRoIGxlc3M8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNhcGFibGUgSC9X Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGF0IGlzIGEgY29tcGxldGVs eSBkaWZmZXJlbnQgbWF0dGVyLiBUaGUgZGlzY3Vzc2lvbiBpcyBhYm91dDxicj4NCiZndDsmZ3Q7 Jmd0OyByZW1hcmtpbmcuIEFuZCBpZiBvbmUgcmVtYXJrcyB0byB3aGF0IHRoZSBwYXRoIGNhbm5v dCBzdXBwb3J0LCB3ZWxsPGJyPg0KJmd0OyZndDsmZ3Q7IHRoaW5ncyBkb27igJl0IHdvcmsgYXMg ZXhwZWN0ZWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTbGljaW5n IGlzIGFsbW9zdCB0aGUgc2FtZS4gSXQgYWxsb3dzIHVzZXIgdHJhZmZpYyB0byBiZSBtYXBwZWQg dG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQgdGhlIG9wZXJhdG9yIHByb3ZpZGVzLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IG5ldHdvcmsgc2hvdWxkIG5v dCB0b3VjaC9jaGFuZ2Ugb3JpZ2luYWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGhlYWRlciBiaXRz LiBHVFAgb3IgYW55IG90aGVyIGVuY2Fwc3VsYXRpb24gZWFzaWx5IGFsbG93IGZvciB0aGlzLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2UgY2FuIHByb3Zp ZGUgZm9yIHRoaXMgd2l0aG91dCB1c2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBzdWxh dGlvbi4gSVB2NiBtaWdodCBiZSB0aGUgYW5zd2VyLiBCdXQgYXMgVG9tIHBvaW50ZWQgb3V0LDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgZmxvdyBsYWJlbHMgY2FuIHN0aWxsIGNoYW5nZSBpbiB0aGUg bWlkZGxlLiBJcyB0aGVyZSBhbnkgcm9vbSBmb3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGltcHJv dmVtZW50LiBTSURzIG1pZ2h0IHByZXNlbnQgYW4gb3Bwb3J0dW5pdHkuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE5vdCBpZiB0aGV5IGFyZSBlbmNhcHN1bGF0ZWQgYW5kIHJv dXRlcnMgZG9u4oCZdCB0b3VjaCBwYWNrZXRzIGluc2lkZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgRGlubzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBG cm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZmFyaW5h Y2NpQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5mYXJpbmFj Y2lAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFNlbnQ6IDA3IFNlcHRlbWJlciAyMDE4IDEzOjA4PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgVG86IEFyYXNobWlkIEFraGF2YWluICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJFTi1VUyI+YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbTwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogVG9tIEhlcmJl cnQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dG9tQHF1YW50b25pdW0ubmV0IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPnRvbUBxdWFudG9uaXVtLm5ldDwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRhLW1peWFz YWthQGtkZGktcmVzZWFyY2guanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ dGEtbWl5YXNha2FAa2RkaS1yZXNlYXJjaC5qcDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi Pjs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkbW0gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBp ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW0RNTV0gQ29tbWVudHMgdG8gZHJhZnQtaG1tLWRtbS01 Zy11cGxhbmUtYW5hbHlzaXMtMDE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgeW914oCZbGwgc3RpbGwgaGF2ZSB0aGUgUEhCIHJlLW1h cmtpbmcgaXNzdWVzIEkgbWVudGlvbmVkIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJl dmlvdXMgZW1haWxzLiBUaGUgcXVlc3Rpb24gaXMsIHNob3VsZCB0aGUgbmV0d29yayB0b3VjaC9j aGFuZ2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnkgaGVhZGVyIGJpdHMgb2YgdGhlIHBh Y2tldCB0aGUgc291cmNlIGhhcyBidWlsdC4gVGhlIGFuc3dlcjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHNob3VsZCBwcm9iYWJseSBiZSBuby48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEdUUCBkaWQgaXQgdGhl IHJpZ2h0IHdheSwgZXZlbiB0aG91Z2ggaXQgY29zdCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGhlYWRlciBsZW5ndGguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBEaW5vPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgT24gU2VwIDcsIDIwMTgsIGF0IDg6MjYgQU0sIEFyYXNobWlkIEFr aGF2YWluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IkVOLVVTIj5hcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ29ycmVjdCwgZmxvdyBsYWJlbHMgY2FuIGNoYW5n ZSBhbG9uZyB0aGUgcGF0aC4gVGhhdCdzIHdoeSBJIGxpa2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhlIHNsaWNpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25jZXB0Ljxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBVRXMgY2FuIHJlcXVlc3Qgc2VydmljZXMgd2l0 aCBkaWZmZXJlbnQgYXR0cmlidXRlcywgb3BlcmF0b3JzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNvbnRyb2wgaG93PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSByZXF1 ZXN0IGFyZSBtYXBwZWQgaW50byBzbGljZXMuIEkgc2hvdWxkIGxvb2sgaW50byB0aGUgYWlyPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2lkZSBvZiB0aGUgYnVzaW5lc3MgYW5kIHNlZSB3aGF0 IGhhcHBlbnMgdGhlcmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IkVOLVVTIj50b21AcXVhbnRvbml1bS5uZXQ8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj5dPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiAwNyBT ZXB0ZW1iZXIgMjAxOCAxMToxMzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86 IEFyYXNobWlkIEFraGF2YWluICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFyYXNobWlkLmFr aGF2YWluQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+YXJh c2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiBEaW5vIEZhcmluYWNjaSAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmZhcmluYWNjaUBnbWFpbC5jb208L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0YS1taXlhc2FrYUBrZGRpLXJlc2VhcmNoLmpwIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPnRhLW1peWFzYWthQGtkZGktcmVzZWFyY2gu anA8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj47IGRtbSAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtETU1dIENvbW1lbnRzIHRvPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS1h bmFseXNpcy0wMTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEZyaSwgU2VwIDcsIDIwMTggYXQgODowMSBBTSwgQXJh c2htaWQgQWtoYXZhaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS4uY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmFyYXNobWlkLmFraGF2YWluQGh1YXdlaS5jb208 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg RnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmZhcmlu YWNjaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ZmFyaW5h Y2NpQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPl08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogMDYgU2VwdGVtYmVyIDIwMTggMTg6 NTk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IEFyYXNobWlk IEFraGF2YWluICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFyYXNobWlkLmFraGF2YWluQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+YXJhc2htaWQuYWto YXZhaW5AaHVhd2VpLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IFRvbSBIZXJiZXJ0ICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IkVOLVVTIj50b21AcXVhbnRvbml1bS5uZXQ8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7OyB0YS1taXlhc2FrYUBrZGRpLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vcmVzZWFyY2guanAiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBsYW5nPSJFTi1VUyI+cmVzZWFyY2guanA8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT Ij47PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRtbSAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJFTi1VUyI+ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTog W0RNTV0gQ29tbWVudHMgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUtYW5hbHlzaXMtPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgMDE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpbm8gYnJvdWdodCB1cCBh IGdvb2QgcG9pbnQuIEhlcmUgaXMgbXkgdHdvIGNlbnRzIHdvcnRoOjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBOb3Qgc3VyZSB3aGljaCBwb2ludC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEFzIGl0IHdhcyBleHBsYWluZWQgYnkgU3JpZGhhciwmbmJzcDsgZWFjaCBVRSBjYW4g aGF2ZSBtdWx0aXBsZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY29udGV4dHMuIEZvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBleGFtcGxlLCB0b2RheSBzb21lIG9wZXJhdG9ycyBwcm92aWRlIERhdGEgYW5kIFZvTFRFIHNl cnZpY2UgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlaXIg Y3VzdG9tZXJzLiBUaGVzZSB0d28gc2VydmljZXMgYXJlIHJlcHJlc2VudGVkIGJ5IHNlcGFyYXRl PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdUUCB0dW5uZWxzIGlu IHRoZSBjb3JlIHdpdGggZWFjaCB0dW5uZWwgdGllZCB1cCB0byBhIHBhcnRpY3VsYXIgUW9TLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElQdjQgZGlkbid0IGZpdCB0aGUgYmls bCB3aGVuIEdUUCB3b3JrIHdhcyB1bmRlciB3YXkgYXMgaXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvdWxkbid0IHVuaXF1ZWx5IGlkZW50aWZ5IG11bHRp cGxlIFVFPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIG5vIHJlYXNvbiB3aHkg aXQgc2hvdWxkbuKAmXQuIEFuZCBJUHY2LCBmb3IgdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1c2UtY2FzZSBkb2VzbuKAmXQgYWRkIGFueXRoaW5nIG5ldyBv dGhlciB0aGFuIGEgMjggYml0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRyYWZmaWMtY2xhc3MvZmxvdy1sYWJlbCB0aGF0IGNhbiBwcm92aWRlIG1vcmUgYml0cyBm b3Ig4oCcbmV3PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25hbGl0eeKAnS48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0Fy YXNobWlkXSZuYnNwOyBBbmQgdGhhdCdzIHdoYXQgSSBtZWFudC4gSGF2aW5nIGEgZmxvdyBsYWJl bCBpcyBoYW5keS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBjYW4g cGVyaGFwcyB1c2UgaXQgdG8gaWRlbnRpZnkgZGlmZmVyZW50IFVFIHNlc3Npb25zLjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBDYXJlZnVsIGlmIHlvdSB1c2UgdGhlIGZsb3cgbGFiZWwgdG8gaWRlbnRpZnkgZmxv d3MuIEl0IHNob3VsZCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2lk ZXJlZCAmcXVvdDtzb2Z0IGlkZW50aWZpY2F0aW9uJnF1b3Q7IHNpbmNlIGl0IG1pZ2h0IG5vdCBh bHdheXMgYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcnJlY3QgKGl0IGNh biBiZSBjaGFuZ2VkIGVuIHJvdXRlLCBpc24ndCBwcm90ZWN0ZWQgYnkgYW55PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGVja3N1bSwgYW55b25lIGNhbiBzZXQgaXQgaG93ZXZl ciB0aGV5IHdhbnQsIGV0Yy4pLiBJdCdzIHVzZWZ1bDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZm9yIHRoaW5ncyBsaWtlIEVDTVAgdGhhdCBkb24ndCByZXF1aXJlIDEwMCUgYWNj dXJhY3kgaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5aW5nIGZs b3cuIFRoZSBmbG93IGxhYmVsIHdhcyBicmllZmx5IGNvbnNpZGVyZWQgZm9yPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob2xkaW5nIFZOSXMgaW4gbmV0d29yayB2aXJ0dWFsaXph dGlvbiwgYnV0IHdlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGFsa2VkIHRoZW0gb3V0IG9m IHRoYXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVG9tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vzc2lvbnMvY29udGV4dC9iZWFyZXIuIFNv LCBHVFAgYW5kIFRFSUQgZGlkIHRoZSBqb2IuIEJ1dCBJPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZ3JlZSB3aXRoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpbm8gdGhhdCBJUHY2IGlzIG11Y2ggbW9yZSB2ZXJzYXRpbGUg YW5kIGlzIGRlZmluaXRlbHkgd29ydGg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbG9va2luZyBhdCBhcyBhbiBhbHRlcm5hdGl2ZS48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhhdCBpcyBub3Qgd2hhdCBJIHNhaWQuIEkgc2FpZCDigJxJUCBjb3VsZCBoYXZl IHNvbHZlZCB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBy b2JsZW3igJ0uIEFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IOKAnElQ4oCdPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lYW5zIGVpdGhlciBJUHY0IG9yIElQ djYsIG9yIGJvdGggYXQgdGhlIHNhbWUgdGltZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0FyYXNobWlkXTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyB3b3VsZCB3ZSBlbXBsb3kgSVB2NCB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBVRTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHNlc3Npb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVE9TPzxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9yIHlvdSBtZWFuIHVzaW5nIGVu Y2Fwc3VsYXRpb24/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEgZmFjdG9yIHdvcnRoIGNvbnNpZGVyaW5nIHRob3Vn aCBpcyB0aGF0IHRoZSB1c2Ugb2YgR1RQIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVEVJRCBpbiBtb2JpbGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgY29yZSBhbGxvd3Mgb3BlcmF0b3JzIHRvIGRlYWwgd2l0aCBRb1Mg b24gdGhlaXIgb3duIHRlcm1zLiBUaGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdHVubmVscyB3aXRoIHNwZWNpZmljIG9wZXJhdG9yLWNvbnRyb2xsZWQgUW9TIGFy ZSBlc3RhYmxpc2hlZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi eSB0aGUgY29udHJvbCBwbGFuZSBiZXR3ZWVuIGVOQiwgU0dXLCBhbmQgUEdXLiBVRXMgb3I8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwbGljYXRpb25zIHNpdHRp bmcgaW4gdGhlIFVFcyBoYXZlIG5vIHNheSBpbiB0aGlzLiBXZWxsIGF0PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXN0IHRpbGwgdGhlIHBhY2tldCBleGl0cyBv cGVyYXRvcidzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgcHJvYmxlbSB3aXRoIG9uZSBoZWFkZXIsIGlzIHRo YXQgaWYgeW91IHJlLW1hcmsgKGtub3duIGFzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFBIQiBtYXJraWduIGluIHRoZSBvbGUgZGF5cykgeW91IGxvc2UgdGhlIG9y aWdpbmFsIHZhbHVlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBF bmNhcHN1bGF0aW9uIGlzIHVzZWZ1bCBoZXJlIGJlY2F1c2UgeW91IGNhbiBtYXAgdGhlIGlubmVy IHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG91dGVyIGFuZCBh bnl3aGVyZSBhbG9uZyB0aGUgcGF0aCB5b3UgY2FuIFBIQiByZW1hcmsgb24gdGhlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG91dGVyIGhlYWRlci4gQW5kIHRoZW4g dGhlIGRlc3RpbmF0aW9uIGNhbiBzZWUgdGhlIG9yaWduYWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc291cmNl4oCZcyBUb1MvUW9TL1RDL2Zsb3ctbGFiZWw8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGF0ZXZlci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0FyYXNobWlkXSBZZXMsIEkgYWdyZWUu IFRoZSBvcmlnaW5hbCB2YWx1ZSBpcyBsb3N0IHdpdGggUEhCLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEVuY2Fwc3VsYXRpb24gY2VydGFpbmx5IG1ha2VzIHRoaW5ncyBl YXNpZXIgYW5kIHRoZSBpbm5lciB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG91dGVyIG1hcHBpbmcgdHJpY2sgaGFzIGJlZW4gd2lkZWx5IHVzZWQgaW4gSVAgYW5kIE1Q TFMobXVsdGlwbGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYWJlbHMg bGlrZSBzZXJ2aWNlIGFuZCB0cmFuc3BvcnQpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVzaW5nIHRoZSBpbmZvcm1h dGlvbiBpbiBVRSdzIElQIHBhY2tldCBoZWFkZXIgY2FuIGplb3BhcmRpc2U8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBhYm92ZSB0aWdodCBRb1MgY29u dHJvbC4gSSB0aGluayBnb2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb3QgaWYgeW91 IGVuY2Fwc3VsYXRlLiBCdXQgbm90ZSB3aXRoIFNSdjYsIHlvdSBjYW4gcG9zc2libHk8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmV0YWluIHRoZSBvcmlnaW5hbCBm bG93LWxhYmVsIGlmIHRoZSBTSUQgY2FuIHJldGFpbiB0aG9zZSBiaXRzPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlZm9yZSBvdmVyd3JpdGluZyB0aGUgZGVzdGlu YXRpb24gYWRkcmVzcyBmcm9tIHRoZSBvcHRpb27igJlzIHZhbHVlLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgW0FyYXNobWlkXSBBZ3JlZS4gRW5jYXBzdWxhdGlvbiBkb2VzIHRoZSB0cmljayBhZ2Fpbi4g VGhhdCdzIHdoeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdUUCBoYXMg d29ya2VkIHdlbGwgYW5kIHNlcnZlZCB0aGUgcHVycG9zIGluIHRoZSBtb2JpbGU8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiYWNrLWhhdWwgc28gZmFyLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERp bm88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvd24gdGhpcyBwYXRoLCBvcGVyYXRv cnMgbmVlZCBwcm9vZiB0aGF0IHRoZXkgd2lsbCBiZSBzdGlsbDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gdGhlIGRyaXZpbmc8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VhdCBhbmQgUW9TIGNhbm5vdCBiZSBkaWN0YXRl ZC90YW1wZXJlZCBieSB0aGUgVUUgb3IgYW55PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFwcGxpY2F0aW9uIHJ1bm5pbmcgaW4gaXQuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgTm93LCBoZXJlIGlzIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGZv ciB0aGUgb3BlcmF0b3JzLiBXb3VsZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYW55IG9wZXJhdG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGJlIGludGVyZXN0ZWQgaW4gYWxsb3dpbmcgUW9TJm5ic3A7IHRvIGJlIHNldCBi eSB0aGUgVUUgb3IgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YXBwbGljYXRpb25zIHJ1bm5pbmcgaW4gdGhlIFVFIGFuZCBjaGFyZ2VkIGZvciBieSB0aGUgbmV0 d29yaz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7WWVz JnF1b3Q7IGNvdWxkIHBvdGVudGlhbGx5IGltcGx5IGltcGFjdHMgb24gdGhlIGFpciBpbnRlcmZh Y2UsIFVFPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlc291cmNl IGJsb2NrIGFsbG9jYXRpb24gYW5kIGNhbiBtYWtlIHNjaGVkdWxpbmcgb24gdGhlIFJBTjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzaWRlPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgbXVjaCBtb3JlIGNvbXBsZXguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgQXJhc2htaWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRnJvbTogZG1tIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW0tYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5kbW0tYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPl0gT24gQmVoYWxmIE9m IERpbm88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBG YXJpbmFjY2k8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBTZW50OiAwNiBTZXB0ZW1iZXIgMjAxOCAxMjo0NTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBUb20gSGVyYmVydCAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1VUyI+dG9tQHF1YW50b25pdW0ubmV0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENj OiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRhLW1peWFzYWthQGtkZGktcmVzZWFyY2guanAiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+dGEtbWl5YXNha2FAa2RkaS1yZXNlYXJj aC5qcDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjsgZG1tICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtE TU1dIENvbW1lbnRzIHRvIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFuYWx5c2lzLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMDE8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCZWhjZXQsPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgd2FzIHRo aW5raW5nIGlmIFRFSUQgaXMgbmVlZCB0aGVuIHRoYXQgY2FuIGJlIGVuY29kZWQgaW4gYTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb2NhdG9y IGVhc2lseSBlbm91Z2guPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRvbTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Tm90IGlmIGEgbG9jYXRvciBpcyBhIFBHVyB0aGF0IGlzIHNoYXJlZCBieSBtYW55IFVFcy48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDNHUFAgd2FudHMgcGVyIGJl YXJlciBhd2FyZW5lc3Mgc28gdGhleSBuZWVkIGEgc3BlY2lmaWMgSUQsPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBjb3VsZCBoYXZlIGJlZW4g dGhlIFVF4oCZcyBJUCBhZGRyZXNzLiBBbmQgd2l0aCBJUHY2IGl0PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FuIGJlIHVuaXF1ZSBhbmQgbm90IHRo ZSBpc3N1ZSB0aGF0IFNyaWRoYXIgYnJvdWdodCB1cC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIElMQSB3YXMgaW4gdXNlLCBqdXN0IHVzZSB0aGUgSUxBLUlE IGZvciB0aGlzIHB1cnBvc2UuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBEaW5vPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRtbSBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVO LVVTIj5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbW08L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgZG1tIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7 Jmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IkVOLVVTIj5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQomZ3Q7Jmd0OyZndDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4t VVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgZG1tIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJFTi1VUyI+ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KJmd0OyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBkbW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQomZ3Q7IDwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RtbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCiZn dDsgPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NClNodW5zdWtlIEhvbW1hPGJyPg0KJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IkVOLVVTIj5ob21tYS4uc2h1bnN1a2VAbGFiLm50dC5jby5qcDwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDs8YnI+DQpURUw6ICYjNDM7ODEgNDIyIDU5IDM0ODY8YnI+DQpGQVg6 ICYjNDM7ODEgNDIyIDYwIDc0NjA8YnI+DQo8YnI+DQpOVFQgTmV0d29yayBTZXJ2aWNlIFN5c3Rl bXMgTGFicy48YnI+DQpNdXNhc2hpbm8gY2l0eSwgVG9reW8sIEphcGFuPGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCjwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iRU4tVVMiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RtbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 b19fIDxicj4NCiZuYnNwO18mZ3Q7ICZuYnNwOy9fXyA8YnI+DQooXykgXChfKS4uLiBCdXJuIGZh dCBub3QgZnVlbCAtIEJpa2UgYWxvbmcgdG8gYSBoZWFsdGhpZXIgbGlmZSBhbmQgY2xlYW5lciA8 YnI+DQp3b3JsZCEgOikgPGJyPg0KPGJyPg0KU3JpZGhhciBCaGFza2FyYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D57109449177B54F8B9C093953AC5BCD755E5415yyzeml704chmchi_-- From nobody Thu Oct 4 22:25:30 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A611130DD6 for ; Thu, 4 Oct 2018 22:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XvSf9yq-hwzP for ; Thu, 4 Oct 2018 22:25:25 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25D0130DD2 for ; Thu, 4 Oct 2018 22:25:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w955PFwc012508; Fri, 5 Oct 2018 07:25:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4C99200C4E; Fri, 5 Oct 2018 07:25:15 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 93882200BEA; Fri, 5 Oct 2018 07:25:15 +0200 (CEST) Received: from [10.8.68.17] ([10.8.68.17]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w955PEBx027872; Fri, 5 Oct 2018 07:25:14 +0200 To: Sridhar Bhaskaran , arashmid.akhavain@huawei.com Cc: dmm@ietf.org References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> From: Alexandre Petrescu Message-ID: <291c20ae-6ce2-7002-cbb8-88ee9d19a1a1@gmail.com> Date: Fri, 5 Oct 2018 07:25:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 05:25:29 -0000 Thank you very much for the clarification. I understand now that GTP is a user-plane function run in the network. - the UE (smartphone) never runs GTP. I think this is worth putting in the draft and state it as such, if we so believe. - it is strange for me to call it a User-Plane Function while the user has no impact on it. I think this abbreviation deserves clarification. We can suggest to 3GPP to change the name. (terms like data-plane/control-plane (not user-plane) are already in widespread use, and could be improved). Alex Le 03/10/2018 à 18:29, Sridhar Bhaskaran a écrit : > >>A UPF is any function that can be executed on user traffic in mobile > network. Having said that however, I think the first UPFs that we will > see will be in the form of SGW, PGW. > > Even this is not accurate.. > > A UPF is a _*5G system core network*_ entity whereas the SGW-U and PGW-U > are EPC core network entities. 5G core network has many differences from > EPC. To avoid confusion it should be noted that 5G NR radio can be > deployed with EPC as the core network and technically such deployments > can also be called as 5G deployments. But an UPF has no role in such > deployments. > > Some of the user plane functionalities of an UPF are completely > different from SGW-U or PGW-U.. Here are few differences (not exhaustive) > > 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any > QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session. > Different QoS flows within that PDU session are identified based on the > QFI marking. So a UPF has to support QFI marking. > 2. An UPF can support classification and encapsulation Ethernet frames > whereas a SGW-U/PGW-U has no requirement to support classification and > encapsulation of Ethernet frames. > 3. An UPF supporting Ethernet PDU session type may support ARP proxying > / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement.. > 4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no > such requirement. > > One may say that SGW-U / PGW-U also plays a role in user plane > forwarding and hence why not call it a UPF?  For the lack of a better > terminology, 3GPP has called the entity that performs the user plane > functionalities and features within a _*5G core network*_ as UPF. Those > functionalities are not exactly similar to EPC. > > Thanks > Sridhar > > On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain > > wrote: > > Not necessarily,____ > > __ __ > > You are correct in that PGW is a UPF, but a UPF is by no means > limited to PGW. A UPF is any function that can be executed on user > traffic in mobile network. Having said that however, I think the > first UPFs that we will see will be in the form of SGW, PGW.____ > > __ __ > > Arashmid____ > > __ __ > > *From:*dmm [mailto:dmm-bounces@ietf.org > ] *On Behalf Of *Behcet Sarikaya > *Sent:* Tuesday, October 02, 2018 11:44 AM > *To:* Shunsuke Homma > > *Cc:* dmm > > *Subject:* Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01____ > > __ __ > > UPF is virtualized PGW, folks.____ > > While PGW is fixed in location and possibly serving a large number > of UE which are geographically in the area, that part of the city > and that city itself, UPF can be deployed closer to the UE and thus > probably serving smaller number of UEs____ > > __ __ > > Behcet____ > > __ __ > > On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma > > > wrote:____ > > Thanks Dark for your explaining what is UPF instead of me. > > Alex, brief definitions of UPF are described in the section > 4.1.1.1 of > this draft. Also, you can find more details in 3GPP TS23.501. > > Regards, > > Shunsuke > > On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de > wrote: > > Hi Alex, > > and sorry for jumping into the discussion... > >  From my and (AFAIK) 3GPPs understanding your smartphone is a > UE - sitting on the other side of RAN (gNB) - whereas a UPF > normally is seen as UP entry (and exit) of the 5G core (i.e. > handling all UP traffic in a true CP/UP split fashion). > > Any other ideas on this? Can someone imagine any scenario > where UE implements UPF? > > Thanks! > > Best Regards > > Dirk > > > > -----Original Message----- > > From: dmm [mailto:dmm-bounces@ietf.org > ] On Behalf Of Alexandre Petrescu > > Sent: Montag, 1. Oktober 2018 13:22 > > To: dmm@ietf.org > > Subject: Re: [DMM] Comments to > draft-hmm-dmm-5g-uplane-analysis-01 > > > > > > > > Le 01/10/2018 à 05:50, Shunsuke Homma a écrit : > >> Hi all, > >> # Sorry for my late response... > >> > >> Thank you for your lively discussion. It is very helpful for > >> understanding points which need supplemental explanation and > more > >> consideration. > >> > >> Following the discussion, we're planning to update the I-D for > >> covering the points below: > >> > >> - termination points of GTP-U > >>     (RANs and UPFs terminate GTP-U in 5GS.) > > > > What is UPF? > > > > I understand UPF stands for User-Plane Function. > > > > Is my smartphone supposed to implement UPF? > > > > Alex > > > >> - setting QoS parameter of outer IP header > >>     (Note that it's not just copy of inner to outer.) > >> - problems related to IP connectivity (e.g., MTU in IPv6 > networks, > >> IPv4 address duplication) > >> - summary of network slicing in 5GS > >>     (E.g., "slice is composed of SMF and UPFs. AMF selects SMF > >> depending on NSSAI sent from UE, and SMF indicates to the UE > the UPF > >> that it is > >> allocated.") > >> - case studies on UPF selection > >>     (E.g., parameters used for deciding destination UPF) # > Optimizing > >> forwarding paths solution might be realized with UPF selection > >> mechanism in 3GPP architecture. (ID-LOC may be applied as such > >> mechanism.) > >> > >> > >> If you have any request for us on this updating, please let > us know. > >> > >> Best regards, > >> > >> Shunsuke > >> > >> On 2018/09/08 3:28, Dino Farinacci wrote: > >>>> I understand your point, but there is no guarantee for a > precise QoS > >>>> without using some sort of encapsulation being it GTP, > RSVP, etc. > >>>> Even with tunnels, there is no guarantee that all nodes > along the > >>>> path have the same hardware capability and can provide the > same QoS > >>>> treatment. > >>> > >>> There is existing hardware where the encapsulator copies > inner QoS to > >>> outer QoS. All routers along the path just process the > outer QoS, no > >>> changes to or new processing requirements for them. > >>> > >>>> For example, the code points in routers need to be > configured to > >>>> correctly handle the EXP bits in MPLS labels. But there is no > >>>> guarantee that all routers can support all values. The EXP > values > >>>> get mapped to code points but the mapping is not always > one to one. > >>>> 3-bit EXPs can map to 4 code points on those routers with less > >>>> capable H/W. > >>> > >>> That is a completely different matter. The discussion is about > >>> remarking. And if one remarks to what the path cannot > support, well > >>> things don’t work as expected. > >>> > >>>> Slicing is almost the same. It allows user traffic to be > mapped to > >>>> what the operator provides. > >>>> I agree with you that network should not touch/change original > >>>> header bits. GTP or any other encapsulation easily allow > for this. > >>>> The question is whether we can provide for this without using > >>>> encapsulation. IPv6 might be the answer. But as Tom > pointed out, > >>>> flow labels can still change in the middle. Is there any > room for > >>>> improvement. SIDs might present an opportunity. > >>> > >>> Not if they are encapsulated and routers don’t touch > packets inside. > >>> > >>> Dino > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com > ] > >>>>> Sent: 07 September 2018 13:08 > >>>>> To: Arashmid Akhavain > > >>>>> Cc: Tom Herbert >; ta-miyasaka@kddi-research.jp > ; > >>>>> dmm > > >>>>> Subject: Re: [DMM] Comments to > draft-hmm-dmm-5g-uplane-analysis-01 > >>>>> > >>>>> I think you’ll still have the PHB re-marking issues I > mentioned in > >>>>> previous emails. The question is, should the network > touch/change > >>>>> any header bits of the packet the source has built. The > answer > >>>>> should probably be no. > >>>>> > >>>>> Having said that, GTP did it the right way, even though > it cost in > >>>>> header length. > >>>>> > >>>>> Dino > >>>>> > >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain > >>>>> > wrote: > >>>>>> > >>>>>> Correct, flow labels can change along the path. That's > why I like > >>>>>> the slicing > >>>>> concept. > >>>>>> UEs can request services with different attributes, > operators > >>>>>> control how > >>>>> service request are mapped into slices. I should look > into the air > >>>>> side of the business and see what happens there. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net > ] > >>>>>>> Sent: 07 September 2018 11:13 > >>>>>>> To: Arashmid Akhavain > > >>>>>>> Cc: Dino Farinacci >; > >>>>>>> ta-miyasaka@kddi-research.jp > ; dmm > > >>>>>>> Subject: Re: [DMM] Comments to > >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 > >>>>>>> > >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain > >>>>>>> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com > ] > >>>>>>>>> Sent: 06 September 2018 18:59 > >>>>>>>>> To: Arashmid Akhavain > > >>>>>>>>> Cc: Tom Herbert >; ta-miyasaka@kddi- > >>>>> research.jp ; > >>>>>>>>> dmm > > >>>>>>>>> Subject: Re: [DMM] Comments to > >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- > >>>>> 01 > >>>>>>>>> > >>>>>>>>>> Dino brought up a good point. Here is my two cents > worth: > >>>>>>>>> > >>>>>>>>> Not sure which point. > >>>>>>>>> > >>>>>>>>>> As it was explained by Sridhar,  each UE can have > multiple > >>>>>>>>>> contexts. For > >>>>>>>>> example, today some operators provide Data and VoLTE > service to > >>>>>>>>> their customers. These two services are represented > by separate > >>>>>>>>> GTP tunnels in the core with each tunnel tied up to a > particular QoS. > >>>>>>>>>> > >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under way > as it > >>>>>>>>>> couldn't uniquely identify multiple UE > >>>>>>>>> > >>>>>>>>> There is no reason why it shouldn’t. And IPv6, for this > >>>>>>>>> use-case doesn’t add anything new other than a 28 bit > >>>>>>>>> traffic-class/flow-label that can provide more bits > for “new > >>>>> functionality”. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid]  And that's what I meant. Having a flow > label is handy. > >>>>>>>> We can perhaps use it to identify different UE sessions. > >>>>>>>> > >>>>>>> Careful if you use the flow label to identify flows. It > should be > >>>>>>> considered "soft identification" since it might not > always be > >>>>>>> correct (it can be changed en route, isn't protected by any > >>>>>>> checksum, anyone can set it however they want, etc.). > It's useful > >>>>>>> for things like ECMP that don't require 100% accuracy in > >>>>>>> identifying flow. The flow label was briefly considered for > >>>>>>> holding VNIs in network virtualization, but we > >>>>> talked them out of that. > >>>>>>> > >>>>>>> Tom > >>>>>>> > >>>>>>>>> > >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the > job. But I > >>>>>>>>>> agree with > >>>>>>>>> Dino that IPv6 is much more versatile and is > definitely worth > >>>>>>>>> looking at as an alternative. > >>>>>>>>> > >>>>>>>>> That is not what I said. I said “IP could have solved > this > >>>>>>>>> problem”. And > >>>>> “IP” > >>>>>>>>> means either IPv4 or IPv6, or both at the same time. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] > >>>>>>>> How would we employ IPv4 to distinguish between > different UE > >>>>>>>> sessions. > >>>>>>> TOS? > >>>>>>>> Or you mean using encapsulation? > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> A factor worth considering though is that the use of > GTP and > >>>>>>>>>> TEID in mobile > >>>>>>>>> core allows operators to deal with QoS on their own > terms. The > >>>>>>>>> tunnels with specific operator-controlled QoS are > established > >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or > >>>>>>>>> applications sitting in the UEs have no say in this. > Well at > >>>>>>>>> least till the packet exits operator's > >>>>>>> network. > >>>>>>>>> > >>>>>>>>> The problem with one header, is that if you re-mark > (known as > >>>>>>>>> PHB markign in the ole days) you lose the original value. > >>>>>>>>> Encapsulation is useful here because you can map the > inner to > >>>>>>>>> outer and anywhere along the path you can PHB remark > on the > >>>>>>>>> outer header. And then the destination can see the > orignal > >>>>>>>>> source’s ToS/QoS/TC/flow-label > >>>>> whatever. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] Yes, I agree. The original value is lost > with PHB. > >>>>>>>> Encapsulation certainly makes things easier and the > inner to > >>>>>>>> outer mapping trick has been widely used in IP and > MPLS(multiple > >>>>>>>> labels like service and transport) > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> Using the information in UE's IP packet header can > jeopardise > >>>>>>>>>> the above tight QoS control. I think going > >>>>>>>>> > >>>>>>>>> Not if you encapsulate. But note with SRv6, you can > possibly > >>>>>>>>> retain the original flow-label if the SID can retain > those bits > >>>>>>>>> before overwriting the destination address from the > option’s value. > >>>>>>>> > >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. > That's why > >>>>>>>> GTP has worked well and served the purpos in the mobile > >>>>>>>> back-haul so far. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Dino > >>>>>>>>> > >>>>>>>>>> down this path, operators need proof that they will > be still > >>>>>>>>>> in the driving > >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any > >>>>>>>>> application running in it. > >>>>>>>>>> > >>>>>>>>>> Now, here is an interesting question for the > operators. Would > >>>>>>>>>> any operator > >>>>>>>>> be interested in allowing QoS  to be set by the UE or by > >>>>>>>>> applications running in the UE and charged for by the > network? > >>>>>>>>> "Yes" could potentially imply impacts on the air > interface, UE > >>>>>>>>> resource block allocation and can make scheduling on > the RAN > >>>>>>>>> side > >>>>> much more complex. > >>>>>>>>>> > >>>>>>>>>> Arashmid > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org > ] On Behalf Of Dino > >>>>>>>>>>> Farinacci > >>>>>>>>>>> Sent: 06 September 2018 12:45 > >>>>>>>>>>> To: Tom Herbert > > >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp > ; dmm > > >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- > >>>>> analysis- > >>>>>>> 01 > >>>>>>>>>>> > >>>>>>>>>>>> Behcet, > >>>>>>>>>>>> > >>>>>>>>>>>> I was thinking if TEID is need then that can be > encoded in a > >>>>>>>>>>>> locator easily enough. > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>> > >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. > >>>>>>>>>>> > >>>>>>>>>>> 3GPP wants per bearer awareness so they need a > specific ID, > >>>>>>>>>>> that could have been the UE’s IP address. And with > IPv6 it > >>>>>>>>>>> can be unique and not the issue that Sridhar > brought up. > >>>>>>>>>>> > >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this > purpose. > >>>>>>>>>>> > >>>>>>>>>>> Dino > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> dmm mailing list > >>>>>>>>>>> dmm@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > >> > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > ---------------------------------- > Shunsuke Homma > > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 > > NTT Network Service Systems Labs. > Musashino city, Tokyo, Japan > ---------------------------------- > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm____ > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > > > -- >  o__ >  _>  /__ > (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner > world! :) > > Sridhar Bhaskaran > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Oct 5 07:34:09 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C311292AD for ; Fri, 5 Oct 2018 07:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GPqPJVqUt93N for ; Fri, 5 Oct 2018 07:34:03 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 B76D0124C04 for ; Fri, 5 Oct 2018 07:34:02 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id a13-v6so13786500wrt.5 for ; Fri, 05 Oct 2018 07:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=wTutgKlsEBR501iIf+Ag1nRmLuNmRB+rURwAEOCljB4=; b=oO/iKRRj6mv6QFNa2imKdvoU5Iz09iaYeTbtUv7VD/NY4ViFXk76Z7fYV0M8Yq8LLP Xj+4kxJrJ77tTWH0qa1ydtY17CvnPJMVeL1avXYIsEtgfcGbBL/mshLAENT3f8K8SjSp Vm1Slvaqe2TgfKFjk3j390X/OQp7wTOtiTpKnU3xYX/MK0MlrSX67nDcTFqh1psVzagi mOxM+lfsXQwcKFbo+aMvFsL8vLVsNyP9tVpracqMBMTAPe6S8jr50pGzc4Owm17IRTqV QrKiPCRtOMjmsAp6h9r1lEzZlC5uW6XcxwPEOMqzar1uU3STrhr+7BFqgYAP1cKyr0N2 M1jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=wTutgKlsEBR501iIf+Ag1nRmLuNmRB+rURwAEOCljB4=; b=A2hkxqOo1RIS+3AYtfUHgJ8A2twd98J8Y5xXCj63zvWPgkcr6Hv5ZxUldxO80XAxco ts1ss7jEHWEGQERoLe9jatZfPzl1tQkXiGaRFAA+b2YWSiQXCPpPGBgrevsSzMFClgkk zXKkOkyYilgUrMSJs2/uSS2KmdGUg9Lmer2MmcOnPdkd/Vqa0INBo2yXXnEPZ6aY6vHf m0f2qFdZHCZBUnmejh4T6X60HF0SB2xdin/BsGOJ93IYKgtE+55NZzMc5vB7zk1GP2qP L3dxN1da66Nea+BemIW7rHT9ne5gaFn5Dx3X4lR8HuFeD7zyr7poRjXSFJ0LUwZX1auH GrLQ== X-Gm-Message-State: ABuFfoiaWkMFbx5Ero5nKlTXcsbU2MiFmq8kT6bq4sy90J/P+Q+UYRjB Zv5cnurqbCeBOGdKVAG0lxrqxhNE4EtVqKdSbSI= X-Google-Smtp-Source: ACcGV60lzPqjN/TYwSt5cevmODne+gXXQZ8g0QIyl+uvBQskWU7MsXgiytMUFR0+MJVCk36FpgE+lDqqIVsKVqx/UsM= X-Received: by 2002:a5d:6490:: with SMTP id r16-v6mr7843670wru.99.1538750040968; Fri, 05 Oct 2018 07:34:00 -0700 (PDT) MIME-Version: 1.0 References: <11B710EE-FEBA-47FC-AE6B-EC58E824D864@gmail.com> <178B5F73-C71C-4C5C-A2D4-64D9989656DE@gmail.com> <1E459413-9569-4EF6-BD52-2C8A37812491@gmail.com> <7ecba086-50a0-7856-6841-23ec72c7803b@lab.ntt.co.jp> <9ad8cc9e-2330-f5b1-a3b2-fa91d2d02039@gmail.com> <291c20ae-6ce2-7002-cbb8-88ee9d19a1a1@gmail.com> In-Reply-To: <291c20ae-6ce2-7002-cbb8-88ee9d19a1a1@gmail.com> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 5 Oct 2018 09:33:46 -0500 Message-ID: To: Alexandre Petrescu Cc: Sridhar Bhaskaran , Arashmid Akhavain , dmm Content-Type: multipart/alternative; boundary="000000000000970fd305777c292f" Archived-At: Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 14:34:08 -0000 --000000000000970fd305777c292f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alex, user plane means data plane in 3GPP terminology. Data plane versus control plane separation to my knowledge has first been introduced by 3GPP. Behcet PS. Maybe Sridhar can add some 3GPP standard quotes/references here. On Fri, Oct 5, 2018 at 12:25 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Thank you very much for the clarification. > > I understand now that GTP is a user-plane function run in the network. > > - the UE (smartphone) never runs GTP. I think this is worth putting in > the draft and state it as such, if we so believe. > > - it is strange for me to call it a User-Plane Function while the user > has no impact on it. I think this abbreviation deserves > clarification. We can suggest to 3GPP to change the name. > > (terms like data-plane/control-plane (not user-plane) are already in > widespread use, and could be improved). > > Alex > > > > Le 03/10/2018 =C3=A0 18:29, Sridhar Bhaskaran a =C3=A9crit : > > >>A UPF is any function that can be executed on user traffic in mobile > > network. Having said that however, I think the first UPFs that we will > > see will be in the form of SGW, PGW. > > > > Even this is not accurate.. > > > > A UPF is a _*5G system core network*_ entity whereas the SGW-U and PGW-= U > > are EPC core network entities. 5G core network has many differences fro= m > > EPC. To avoid confusion it should be noted that 5G NR radio can be > > deployed with EPC as the core network and technically such deployments > > can also be called as 5G deployments. But an UPF has no role in such > > deployments. > > > > Some of the user plane functionalities of an UPF are completely > > different from SGW-U or PGW-U.. Here are few differences (not exhaustiv= e) > > > > 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any > > QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session= . > > Different QoS flows within that PDU session are identified based on the > > QFI marking. So a UPF has to support QFI marking. > > 2. An UPF can support classification and encapsulation Ethernet frames > > whereas a SGW-U/PGW-U has no requirement to support classification and > > encapsulation of Ethernet frames. > > 3. An UPF supporting Ethernet PDU session type may support ARP proxying > > / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement.. > > 4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has n= o > > such requirement. > > > > One may say that SGW-U / PGW-U also plays a role in user plane > > forwarding and hence why not call it a UPF? For the lack of a better > > terminology, 3GPP has called the entity that performs the user plane > > functionalities and features within a _*5G core network*_ as UPF. Those > > functionalities are not exactly similar to EPC. > > > > Thanks > > Sridhar > > > > On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain > > > > wrote: > > > > Not necessarily,____ > > > > __ __ > > > > You are correct in that PGW is a UPF, but a UPF is by no means > > limited to PGW. A UPF is any function that can be executed on user > > traffic in mobile network. Having said that however, I think the > > first UPFs that we will see will be in the form of SGW, PGW.____ > > > > __ __ > > > > Arashmid____ > > > > __ __ > > > > *From:*dmm [mailto:dmm-bounces@ietf.org > > ] *On Behalf Of *Behcet Sarikaya > > *Sent:* Tuesday, October 02, 2018 11:44 AM > > *To:* Shunsuke Homma > > > > *Cc:* dmm > > > *Subject:* Re: [DMM] Comments to > draft-hmm-dmm-5g-uplane-analysis-01____ > > > > __ __ > > > > UPF is virtualized PGW, folks.____ > > > > While PGW is fixed in location and possibly serving a large number > > of UE which are geographically in the area, that part of the city > > and that city itself, UPF can be deployed closer to the UE and thus > > probably serving smaller number of UEs____ > > > > __ __ > > > > Behcet____ > > > > __ __ > > > > On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma > > = > > > wrote:____ > > > > Thanks Dark for your explaining what is UPF instead of me. > > > > Alex, brief definitions of UPF are described in the section > > 4.1.1.1 of > > this draft. Also, you can find more details in 3GPP TS23.501. > > > > Regards, > > > > Shunsuke > > > > On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de > > wrote: > > > Hi Alex, > > > and sorry for jumping into the discussion... > > > From my and (AFAIK) 3GPPs understanding your smartphone is = a > > UE - sitting on the other side of RAN (gNB) - whereas a UPF > > normally is seen as UP entry (and exit) of the 5G core (i.e. > > handling all UP traffic in a true CP/UP split fashion). > > > Any other ideas on this? Can someone imagine any scenario > > where UE implements UPF? > > > Thanks! > > > Best Regards > > > Dirk > > > > > > -----Original Message----- > > > From: dmm [mailto:dmm-bounces@ietf.org > > ] On Behalf Of Alexandre Petrescu > > > Sent: Montag, 1. Oktober 2018 13:22 > > > To: dmm@ietf.org > > > Subject: Re: [DMM] Comments to > > draft-hmm-dmm-5g-uplane-analysis-01 > > > > > > > > > > > > Le 01/10/2018 =C3=A0 05:50, Shunsuke Homma a =C3=A9crit : > > >> Hi all, > > >> # Sorry for my late response... > > >> > > >> Thank you for your lively discussion. It is very helpful fo= r > > >> understanding points which need supplemental explanation an= d > > more > > >> consideration. > > >> > > >> Following the discussion, we're planning to update the I-D > for > > >> covering the points below: > > >> > > >> - termination points of GTP-U > > >> (RANs and UPFs terminate GTP-U in 5GS.) > > > > > > What is UPF? > > > > > > I understand UPF stands for User-Plane Function. > > > > > > Is my smartphone supposed to implement UPF? > > > > > > Alex > > > > > >> - setting QoS parameter of outer IP header > > >> (Note that it's not just copy of inner to outer.) > > >> - problems related to IP connectivity (e.g., MTU in IPv6 > > networks, > > >> IPv4 address duplication) > > >> - summary of network slicing in 5GS > > >> (E.g., "slice is composed of SMF and UPFs. AMF selects > SMF > > >> depending on NSSAI sent from UE, and SMF indicates to the U= E > > the UPF > > >> that it is > > >> allocated.") > > >> - case studies on UPF selection > > >> (E.g., parameters used for deciding destination UPF) # > > Optimizing > > >> forwarding paths solution might be realized with UPF > selection > > >> mechanism in 3GPP architecture. (ID-LOC may be applied as > such > > >> mechanism.) > > >> > > >> > > >> If you have any request for us on this updating, please let > > us know. > > >> > > >> Best regards, > > >> > > >> Shunsuke > > >> > > >> On 2018/09/08 3:28, Dino Farinacci wrote: > > >>>> I understand your point, but there is no guarantee for a > > precise QoS > > >>>> without using some sort of encapsulation being it GTP, > > RSVP, etc. > > >>>> Even with tunnels, there is no guarantee that all nodes > > along the > > >>>> path have the same hardware capability and can provide th= e > > same QoS > > >>>> treatment. > > >>> > > >>> There is existing hardware where the encapsulator copies > > inner QoS to > > >>> outer QoS. All routers along the path just process the > > outer QoS, no > > >>> changes to or new processing requirements for them. > > >>> > > >>>> For example, the code points in routers need to be > > configured to > > >>>> correctly handle the EXP bits in MPLS labels. But there i= s > no > > >>>> guarantee that all routers can support all values. The EX= P > > values > > >>>> get mapped to code points but the mapping is not always > > one to one. > > >>>> 3-bit EXPs can map to 4 code points on those routers with > less > > >>>> capable H/W. > > >>> > > >>> That is a completely different matter. The discussion is > about > > >>> remarking. And if one remarks to what the path cannot > > support, well > > >>> things don=E2=80=99t work as expected. > > >>> > > >>>> Slicing is almost the same. It allows user traffic to be > > mapped to > > >>>> what the operator provides. > > >>>> I agree with you that network should not touch/change > original > > >>>> header bits. GTP or any other encapsulation easily allow > > for this. > > >>>> The question is whether we can provide for this without > using > > >>>> encapsulation. IPv6 might be the answer. But as Tom > > pointed out, > > >>>> flow labels can still change in the middle. Is there any > > room for > > >>>> improvement. SIDs might present an opportunity. > > >>> > > >>> Not if they are encapsulated and routers don=E2=80=99t tou= ch > > packets inside. > > >>> > > >>> Dino > > >>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com > > ] > > >>>>> Sent: 07 September 2018 13:08 > > >>>>> To: Arashmid Akhavain > > > > >>>>> Cc: Tom Herbert > >; ta-miyasaka@kddi-research.jp > > ; > > >>>>> dmm > > > >>>>> Subject: Re: [DMM] Comments to > > draft-hmm-dmm-5g-uplane-analysis-01 > > >>>>> > > >>>>> I think you=E2=80=99ll still have the PHB re-marking iss= ues I > > mentioned in > > >>>>> previous emails. The question is, should the network > > touch/change > > >>>>> any header bits of the packet the source has built. The > > answer > > >>>>> should probably be no. > > >>>>> > > >>>>> Having said that, GTP did it the right way, even though > > it cost in > > >>>>> header length. > > >>>>> > > >>>>> Dino > > >>>>> > > >>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain > > >>>>> > > wrote: > > >>>>>> > > >>>>>> Correct, flow labels can change along the path. That's > > why I like > > >>>>>> the slicing > > >>>>> concept. > > >>>>>> UEs can request services with different attributes, > > operators > > >>>>>> control how > > >>>>> service request are mapped into slices. I should look > > into the air > > >>>>> side of the business and see what happens there. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Tom Herbert [mailto:tom@quantonium.net > > ] > > >>>>>>> Sent: 07 September 2018 11:13 > > >>>>>>> To: Arashmid Akhavain > > > > >>>>>>> Cc: Dino Farinacci > >; > > >>>>>>> ta-miyasaka@kddi-research.jp > > ; dmm > > > > >>>>>>> Subject: Re: [DMM] Comments to > > >>>>>>> draft-hmm-dmm-5g-uplane-analysis-01 > > >>>>>>> > > >>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain > > >>>>>>> > > wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com > > ] > > >>>>>>>>> Sent: 06 September 2018 18:59 > > >>>>>>>>> To: Arashmid Akhavain > > > > >>>>>>>>> Cc: Tom Herbert > >; ta-miyasaka@kddi- > > >>>>> research.jp ; > > >>>>>>>>> dmm > > > >>>>>>>>> Subject: Re: [DMM] Comments to > > >>>>>>>>> draft-hmm-dmm-5g-uplane-analysis- > > >>>>> 01 > > >>>>>>>>> > > >>>>>>>>>> Dino brought up a good point. Here is my two cents > > worth: > > >>>>>>>>> > > >>>>>>>>> Not sure which point. > > >>>>>>>>> > > >>>>>>>>>> As it was explained by Sridhar, each UE can have > > multiple > > >>>>>>>>>> contexts. For > > >>>>>>>>> example, today some operators provide Data and VoLTE > > service to > > >>>>>>>>> their customers. These two services are represented > > by separate > > >>>>>>>>> GTP tunnels in the core with each tunnel tied up to = a > > particular QoS. > > >>>>>>>>>> > > >>>>>>>>>> IPv4 didn't fit the bill when GTP work was under wa= y > > as it > > >>>>>>>>>> couldn't uniquely identify multiple UE > > >>>>>>>>> > > >>>>>>>>> There is no reason why it shouldn=E2=80=99t. And IPv= 6, for > this > > >>>>>>>>> use-case doesn=E2=80=99t add anything new other than= a 28 bit > > >>>>>>>>> traffic-class/flow-label that can provide more bits > > for =E2=80=9Cnew > > >>>>> functionality=E2=80=9D. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> [Arashmid] And that's what I meant. Having a flow > > label is handy. > > >>>>>>>> We can perhaps use it to identify different UE > sessions. > > >>>>>>>> > > >>>>>>> Careful if you use the flow label to identify flows. I= t > > should be > > >>>>>>> considered "soft identification" since it might not > > always be > > >>>>>>> correct (it can be changed en route, isn't protected b= y > any > > >>>>>>> checksum, anyone can set it however they want, etc.). > > It's useful > > >>>>>>> for things like ECMP that don't require 100% accuracy = in > > >>>>>>> identifying flow. The flow label was briefly considere= d > for > > >>>>>>> holding VNIs in network virtualization, but we > > >>>>> talked them out of that. > > >>>>>>> > > >>>>>>> Tom > > >>>>>>> > > >>>>>>>>> > > >>>>>>>>>> sessions/context/bearer. So, GTP and TEID did the > > job. But I > > >>>>>>>>>> agree with > > >>>>>>>>> Dino that IPv6 is much more versatile and is > > definitely worth > > >>>>>>>>> looking at as an alternative. > > >>>>>>>>> > > >>>>>>>>> That is not what I said. I said =E2=80=9CIP could ha= ve solved > > this > > >>>>>>>>> problem=E2=80=9D. And > > >>>>> =E2=80=9CIP=E2=80=9D > > >>>>>>>>> means either IPv4 or IPv6, or both at the same time. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> [Arashmid] > > >>>>>>>> How would we employ IPv4 to distinguish between > > different UE > > >>>>>>>> sessions. > > >>>>>>> TOS? > > >>>>>>>> Or you mean using encapsulation? > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> A factor worth considering though is that the use o= f > > GTP and > > >>>>>>>>>> TEID in mobile > > >>>>>>>>> core allows operators to deal with QoS on their own > > terms. The > > >>>>>>>>> tunnels with specific operator-controlled QoS are > > established > > >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs = or > > >>>>>>>>> applications sitting in the UEs have no say in this. > > Well at > > >>>>>>>>> least till the packet exits operator's > > >>>>>>> network. > > >>>>>>>>> > > >>>>>>>>> The problem with one header, is that if you re-mark > > (known as > > >>>>>>>>> PHB markign in the ole days) you lose the original > value. > > >>>>>>>>> Encapsulation is useful here because you can map the > > inner to > > >>>>>>>>> outer and anywhere along the path you can PHB remark > > on the > > >>>>>>>>> outer header. And then the destination can see the > > orignal > > >>>>>>>>> source=E2=80=99s ToS/QoS/TC/flow-label > > >>>>> whatever. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> [Arashmid] Yes, I agree. The original value is lost > > with PHB. > > >>>>>>>> Encapsulation certainly makes things easier and the > > inner to > > >>>>>>>> outer mapping trick has been widely used in IP and > > MPLS(multiple > > >>>>>>>> labels like service and transport) > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> Using the information in UE's IP packet header can > > jeopardise > > >>>>>>>>>> the above tight QoS control. I think going > > >>>>>>>>> > > >>>>>>>>> Not if you encapsulate. But note with SRv6, you can > > possibly > > >>>>>>>>> retain the original flow-label if the SID can retain > > those bits > > >>>>>>>>> before overwriting the destination address from the > > option=E2=80=99s value. > > >>>>>>>> > > >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. > > That's why > > >>>>>>>> GTP has worked well and served the purpos in the mobi= le > > >>>>>>>> back-haul so far. > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Dino > > >>>>>>>>> > > >>>>>>>>>> down this path, operators need proof that they will > > be still > > >>>>>>>>>> in the driving > > >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE o= r > any > > >>>>>>>>> application running in it. > > >>>>>>>>>> > > >>>>>>>>>> Now, here is an interesting question for the > > operators. Would > > >>>>>>>>>> any operator > > >>>>>>>>> be interested in allowing QoS to be set by the UE o= r > by > > >>>>>>>>> applications running in the UE and charged for by th= e > > network? > > >>>>>>>>> "Yes" could potentially imply impacts on the air > > interface, UE > > >>>>>>>>> resource block allocation and can make scheduling on > > the RAN > > >>>>>>>>> side > > >>>>> much more complex. > > >>>>>>>>>> > > >>>>>>>>>> Arashmid > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org > > ] On Behalf Of Dino > > >>>>>>>>>>> Farinacci > > >>>>>>>>>>> Sent: 06 September 2018 12:45 > > >>>>>>>>>>> To: Tom Herbert > > > > >>>>>>>>>>> Cc: ta-miyasaka@kddi-research.jp > > ; dmm > > > > >>>>>>>>>>> Subject: Re: [DMM] Comments to > draft-hmm-dmm-5g-uplane- > > >>>>> analysis- > > >>>>>>> 01 > > >>>>>>>>>>> > > >>>>>>>>>>>> Behcet, > > >>>>>>>>>>>> > > >>>>>>>>>>>> I was thinking if TEID is need then that can be > > encoded in a > > >>>>>>>>>>>> locator easily enough. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Tom > > >>>>>>>>>>> > > >>>>>>>>>>> Not if a locator is a PGW that is shared by many > UEs. > > >>>>>>>>>>> > > >>>>>>>>>>> 3GPP wants per bearer awareness so they need a > > specific ID, > > >>>>>>>>>>> that could have been the UE=E2=80=99s IP address. = And with > > IPv6 it > > >>>>>>>>>>> can be unique and not the issue that Sridhar > > brought up. > > >>>>>>>>>>> > > >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this > > purpose. > > >>>>>>>>>>> > > >>>>>>>>>>> Dino > > >>>>>>>>>>> > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> dmm mailing list > > >>>>>>>>>>> dmm@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > > >>>>>>>> > > >>>> > > >>> > > >>> _______________________________________________ > > >>> dmm mailing list > > >>> dmm@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dmm > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > dmm mailing list > > > dmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ > > > dmm mailing list > > > dmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > -- > > ---------------------------------- > > Shunsuke Homma > > > > > > TEL: +81 422 59 3486 > > FAX: +81 422 60 7460 > > > > NTT Network Service Systems Labs. > > Musashino city, Tokyo, Japan > > ---------------------------------- > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm____ > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > -- > > o__ > > _> /__ > > (_) \(_)... Burn fat not fuel - Bike along to a healthier life and > cleaner > > world! :) > > > > Sridhar Bhaskaran > > > > > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --000000000000970fd305777c292f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alex, user plane means data plane in 3GPP terminology.Data plane versus control plane =C2=A0separation to my knowledge has first= been introduced by 3GPP.

Behcet
PS. May= be Sridhar can add some 3GPP standard quotes/references here.


On Fri, Oct 5, 2018 at 12:25 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Thank you very much for the clarifica= tion.

I understand now that GTP is a user-plane function run in the network.

- the UE (smartphone) never runs GTP.=C2=A0 I think this is worth putting i= n
=C2=A0 =C2=A0the draft and state it as such, if we so believe.

- it is strange for me to call it a User-Plane Function while the user
=C2=A0 =C2=A0has no impact on it.=C2=A0 I think this abbreviation deserves<= br> =C2=A0 =C2=A0clarification.=C2=A0 We can suggest to 3GPP to change the name= .

(terms like data-plane/control-plane (not user-plane) are already in
widespread use, and could be improved).

Alex



Le 03/10/2018 =C3=A0 18:29, Sridhar Bhaskaran a =C3=A9crit=C2=A0:
>=C2=A0 >>A UPF is any function that can be executed on user traff= ic in mobile
> network. Having said that however, I think the first UPFs that we will=
> see will be in the form of SGW, PGW.
>
> Even this is not accurate..
>
> A UPF is a _*5G system core network*_ entity whereas the SGW-U and PGW= -U
> are EPC core network entities. 5G core network has many differences fr= om
> EPC. To avoid confusion it should be noted that 5G NR radio can be > deployed with EPC as the core network and technically such deployments=
> can also be called as 5G deployments. But an UPF has no role in such <= br> > deployments.
>
> Some of the user plane functionalities of an UPF are completely
> different from SGW-U or PGW-U.. Here are few differences (not exhausti= ve)
>
> 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of = any
> QFI marking. UPF on the other hand has one GTP-U tunnel per PDU sessio= n.
> Different QoS flows within that PDU session are identified based on th= e
> QFI marking. So a UPF has to support QFI marking.
> 2. An UPF can support classification and encapsulation Ethernet frames=
> whereas a SGW-U/PGW-U has no requirement to support classification and=
> encapsulation of Ethernet frames.
> 3. An UPF supporting Ethernet PDU session type may support ARP proxyin= g
> / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement.. > 4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has = no
> such requirement.
>
> One may say that SGW-U / PGW-U also plays a role in user plane
> forwarding and hence why not call it a UPF?=C2=A0 For the lack of a be= tter
> terminology, 3GPP has called the entity that performs the user plane <= br> > functionalities and features within a _*5G core network*_ as UPF. Thos= e
> functionalities are not exactly similar to EPC.
>
> Thanks
> Sridhar
>
> On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain
> <= arashmid.akhavain@huawei.com <mailto:arashmid.akhavain@huawei.com>>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Not necessarily,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0You are correct in that PGW is a UPF, but a UPF is = by no means
>=C2=A0 =C2=A0 =C2=A0limited to PGW. A UPF is any function that can be e= xecuted on user
>=C2=A0 =C2=A0 =C2=A0traffic in mobile network. Having said that however= , I think the
>=C2=A0 =C2=A0 =C2=A0first UPFs that we will see will be in the form of = SGW, PGW.____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Arashmid____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0*From:*dmm [mailto:dmm-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:dmm-bounces@ietf.org>] *On Behalf Of *Behcet Sarik= aya
>=C2=A0 =C2=A0 =C2=A0*Sent:* Tuesday, October 02, 2018 11:44 AM
>=C2=A0 =C2=A0 =C2=A0*To:* Shunsuke Homma <homma.shunsuke@lab.ntt.co.jp >=C2=A0 =C2=A0 =C2=A0<mailto:homma.shunsuke@lab.ntt.co.jp>>
>=C2=A0 =C2=A0 =C2=A0*Cc:* dmm <dmm@ietf.org <mailto:dmm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [DMM] Comments to draft-hmm-dmm-5g-u= plane-analysis-01____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0UPF is virtualized PGW, folks.____
>
>=C2=A0 =C2=A0 =C2=A0While PGW is fixed in location and possibly serving= a large number
>=C2=A0 =C2=A0 =C2=A0of UE which are geographically in the area, that pa= rt of the city
>=C2=A0 =C2=A0 =C2=A0and that city itself, UPF can be deployed closer to= the UE and thus
>=C2=A0 =C2=A0 =C2=A0probably serving smaller number of UEs____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Behcet____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma
>=C2=A0 =C2=A0 =C2=A0<homma.shunsuke@lab.ntt.co.jp <mailto:homma.shunsuke@lab.nt= t.co.jp>>
>=C2=A0 =C2=A0 =C2=A0wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks Dark for your explaining what = is UPF instead of me.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alex, brief definitions of UPF are de= scribed in the section
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04.1.1.1 of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this draft. Also, you can find more d= etails in 3GPP TS23.501.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Shunsuke
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 2018/10/01 20:32, Dirk.von-Hugo@telekom.de<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Dirk.von-Hugo@telekom.de> wrote:=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Hi Alex,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > and sorry for jumping into the = discussion...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 From my and (AFAIK) 3GPPs= understanding your smartphone is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UE - sitting on the other side of RAN= (gNB) - whereas a UPF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0normally is seen as UP entry (and exi= t) of the 5G core (i.e.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handling all UP traffic in a true CP/= UP split fashion).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Any other ideas on this? Can so= meone imagine any scenario
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where UE implements UPF?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Thanks!
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Best Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Dirk
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > From: dmm [mailto:dmm-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dmm-bounces@ietf.org>] On Behalf Of = Alexandre Petrescu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Sent: Montag, 1. Oktober 2018 1= 3:22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > To: dmm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Subject: Re: [DMM] Comments to<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hmm-dmm-5g-uplane-analysis-01 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Le 01/10/2018 =C3=A0 05:50, Shu= nsuke Homma a =C3=A9crit=C2=A0:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Hi all,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> # Sorry for my late respons= e...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Thank you for your lively d= iscussion. It is very helpful for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> understanding points which = need supplemental explanation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> consideration.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Following the discussion, w= e're planning to update the I-D for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> covering the points below:<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> - termination points of GTP= -U
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0=C2=A0 (RANs an= d UPFs terminate GTP-U in 5GS.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > What is UPF?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I understand UPF stands for Use= r-Plane Function.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Is my smartphone supposed to im= plement UPF?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Alex
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> - setting QoS parameter of = outer IP header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0=C2=A0 (Note th= at it's not just copy of inner to outer.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> - problems related to IP co= nnectivity (e.g., MTU in IPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> IPv4 address duplication) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> - summary of network slicin= g in 5GS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0=C2=A0 (E.g., &= quot;slice is composed of SMF and UPFs. AMF selects SMF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> depending on NSSAI sent fro= m UE, and SMF indicates to the UE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the UPF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> that it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> allocated.")
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> - case studies on UPF selec= tion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0=C2=A0 (E.g., p= arameters used for deciding destination UPF) #
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optimizing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> forwarding paths solution m= ight be realized with UPF selection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> mechanism in 3GPP architect= ure. (ID-LOC may be applied as such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> mechanism.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> If you have any request for= us on this updating, please let
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0us know.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Best regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Shunsuke
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> On 2018/09/08 3:28, Dino Fa= rinacci wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> I understand your p= oint, but there is no guarantee for a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0precise QoS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> without using some = sort of encapsulation being it GTP,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RSVP, etc.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> Even with tunnels, = there is no guarantee that all nodes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0along the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> path have the same = hardware capability and can provide the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same QoS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> treatment.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> There is existing hardw= are where the encapsulator copies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inner QoS to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> outer QoS. All routers = along the path just process the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0outer QoS, no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> changes to or new proce= ssing requirements for them.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> For example, the co= de points in routers need to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> correctly handle th= e EXP bits in MPLS labels. But there is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> guarantee that all = routers can support all values. The EXP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> get mapped to code = points but the mapping is not always
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one to one.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> 3-bit EXPs can map = to 4 code points on those routers with less
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> capable H/W.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> That is a completely di= fferent matter. The discussion is about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> remarking. And if one r= emarks to what the path cannot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support, well
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> things don=E2=80=99t wo= rk as expected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> Slicing is almost t= he same. It allows user traffic to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mapped to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> what the operator p= rovides.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> I agree with you th= at network should not touch/change original
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> header bits. GTP or= any other encapsulation easily allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for this.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> The question is whe= ther we can provide for this without using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> encapsulation. IPv6= might be the answer. But as Tom
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pointed out,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> flow labels can sti= ll change in the middle. Is there any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0room for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> improvement. SIDs m= ight present an opportunity.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> Not if they are encapsu= lated and routers don=E2=80=99t touch
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets inside.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> Dino
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> -----Original M= essage-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> From: Dino Fari= nacci [mailto:fari= nacci@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:farinacci@gmail.com>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> Sent: 07 Septem= ber 2018 13:08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> To: Arashmid Ak= havain <arashmid.akhavain@huawei.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arashmid.akhavain@huawei.com>= ;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> Cc: Tom Herbert= <tom@quantonium= .net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tom@quantonium.net>>; ta-miyasaka@kddi-resea= rch.jp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ta-miyasaka@kddi-research.jp>= ;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> dmm <dmm@ietf.org <mailto:dmm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> Subject: Re: [D= MM] Comments to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hmm-dmm-5g-uplane-analysis-01 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> I think you=E2= =80=99ll still have the PHB re-marking issues I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mentioned in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> previous emails= . The question is, should the network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0touch/change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> any header bits= of the packet the source has built. The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0answer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> should probably= be no.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> Having said tha= t, GTP did it the right way, even though
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it cost in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> header length.<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> Dino
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>> On Sep 7, 2= 018, at 8:26 AM, Arashmid Akhavain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> <arashmid.akhavain@hu= awei.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arashmid.akhavain@huawei.com>= ;> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>> Correct, fl= ow labels can change along the path. That's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0why I like
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>> the slicing=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> concept.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>> UEs can req= uest services with different attributes,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>> control how=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> service request= are mapped into slices. I should look
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into the air
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> side of the bus= iness and see what happens there.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> -----Or= iginal Message-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> From: T= om Herbert [mailto:= tom@quantonium.net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tom@quantonium.net>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> Sent: 0= 7 September 2018 11:13
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> To: Ara= shmid Akhavain <arashmid.akhavain@huawei.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arashmid.akhavain@huawei.com>= ;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> Cc: Din= o Farinacci <fa= rinacci@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:farinacci@gmail.com>>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> ta-miyasaka@kddi= -research.jp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ta-miyasaka@kddi-research.jp>= ;; dmm <dmm@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dmm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> Subject= : Re: [DMM] Comments to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> draft-h= mm-dmm-5g-uplane-analysis-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> On Fri,= Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> <arashmid.akh= avain@huawei.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arashmid.akhavain@huawei...com>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= From: Dino Farinacci [mailto:farinacci@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:farinacci@gmail.com>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Sent: 06 September 2018 18:59
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= To: Arashmid Akhavain <arashmid.akhavain@huawei.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arashmid.akhavain@huawei.com>= ;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Cc: Tom Herbert <tom@quantonium.net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tom@quantonium.net>>; ta-miyasaka@k= ddi-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> research.jp <http://re= search.jp>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= dmm <dmm@ietf.org= <mailto:dmm@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Subject: Re: [DMM] Comments to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= draft-hmm-dmm-5g-uplane-analysis-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> 01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > Dino brought up a good point. Here is my two cents
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0worth:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Not sure which point.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > As it was explained by Sridhar,=C2=A0 each UE can have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > contexts. For
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= example, today some operators provide Data and VoLTE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= their customers. These two services are represented
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by separate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= GTP tunnels in the core with each tunnel tied up to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular QoS.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > IPv4 didn't fit the bill when GTP work was under way
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > couldn't uniquely identify multiple UE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= There is no reason why it shouldn=E2=80=99t. And IPv6, for this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= use-case doesn=E2=80=99t add anything new other than a 28 bit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= traffic-class/flow-label that can provide more bits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for =E2=80=9Cnew
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> functionality= =E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> [Ar= ashmid]=C2=A0 And that's what I meant. Having a flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0label is handy.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> We = can perhaps use it to identify different UE sessions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> Careful= if you use the flow label to identify flows. It
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> conside= red "soft identification" since it might not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0always be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> correct= (it can be changed en route, isn't protected by any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> checksu= m, anyone can set it however they want, etc.).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It's useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> for thi= ngs like ECMP that don't require 100% accuracy in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> identif= ying flow. The flow label was briefly considered for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> holding= VNIs in network virtualization, but we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> talked them out= of that.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> Tom
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > sessions/context/bearer. So, GTP and TEID did the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0job. But I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > agree with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Dino that IPv6 is much more versatile and is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0definitely worth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= looking at as an alternative.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= That is not what I said. I said =E2=80=9CIP could have solved
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= problem=E2=80=9D. And
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> =E2=80=9CIP=E2= =80=9D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= means either IPv4 or IPv6, or both at the same time.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> [Ar= ashmid]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> How= would we employ IPv4 to distinguish between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different UE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> ses= sions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> TOS? >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> Or = you mean using encapsulation?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > A factor worth considering though is that the use of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GTP and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > TEID in mobile
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= core allows operators to deal with QoS on their own
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0terms. The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= tunnels with specific operator-controlled QoS are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0established
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= by the control plane between eNB, SGW, and PGW. UEs or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= applications sitting in the UEs have no say in this.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= least till the packet exits operator's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> network= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= The problem with one header, is that if you re-mark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(known as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= PHB markign in the ole days) you lose the original value.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Encapsulation is useful here because you can map the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inner to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= outer and anywhere along the path you can PHB remark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= outer header. And then the destination can see the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0orignal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= source=E2=80=99s ToS/QoS/TC/flow-label
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> whatever.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> [Ar= ashmid] Yes, I agree. The original value is lost
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with PHB.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> Enc= apsulation certainly makes things easier and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inner to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> out= er mapping trick has been widely used in IP and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS(multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> lab= els like service and transport)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > Using the information in UE's IP packet header can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jeopardise
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > the above tight QoS control. I think going
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Not if you encapsulate. But note with SRv6, you can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possibly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= retain the original flow-label if the SID can retain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0those bits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= before overwriting the destination address from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option=E2=80=99s value.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> [Ar= ashmid] Agree. Encapsulation does the trick again.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That's why
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> GTP= has worked well and served the purpos in the mobile
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>> bac= k-haul so far.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= Dino
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > down this path, operators need proof that they will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be still
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > in the driving
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= seat and QoS cannot be dictated/tampered by the UE or any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= application running in it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > Now, here is an interesting question for the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operators. Would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > any operator
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= be interested in allowing QoS=C2=A0 to be set by the UE or by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= applications running in the UE and charged for by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= "Yes" could potentially imply impacts on the air
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface, UE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= resource block allocation and can make scheduling on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the RAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= side
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> much more compl= ex.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= > Arashmid
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> From: dmm [mailto:dmm-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dmm-bounces@ietf.org>] On Behalf Of = Dino
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Farinacci
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Sent: 06 September 2018 12:45
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> To: Tom Herbert <tom@quantonium.net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tom@quantonium.net>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Cc: ta-miyasaka@kddi-research.jp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ta-miyasaka@kddi-research.jp>= ;; dmm <dmm@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dmm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>> analysis-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>> 01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>> Behcet,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>> I was thinking if TEID is need then that can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encoded in a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>> locator easily enough.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>> Tom
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Not if a locator is a PGW that is shared by many UEs.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> 3GPP wants per bearer awareness so they need a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specific ID,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> that could have been the UE=E2=80=99s IP address. And with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> can be unique and not the issue that Sridhar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0brought up.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> If ILA was in use, just use the ILA-ID for this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purpose.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> Dino
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> _______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> dmm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> dmm@ietf.org= <mailto:dmm@ietf.org<= /a>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>>= >> https://www.ietf.org/mailman/listinfo/dmm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>>>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> _______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> dmm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> dmm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> https:/= /www.ietf.org/mailman/listinfo/dmm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _______________________________= ________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > dmm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > dmm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.iet= f.org/mailman/listinfo/dmm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _______________________________= ________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > dmm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > dmm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.iet= f.org/mailman/listinfo/dmm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------------------------- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Shunsuke Homma
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<homma...shunsuke@lab.ntt.co.jp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:homma.shunsuke@lab.ntt.co.jp>= ;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TEL: +81 422 59 3486
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FAX: +81 422 60 7460
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NTT Network Service Systems Labs.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Musashino city, Tokyo, Japan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------------------------- >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dmm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dmm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.= org/mailman/listinfo/dmm____
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0dmm mailing list
>=C2=A0 =C2=A0 =C2=A0d= mm@ietf.org <mailto:dmm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/dmm
>
>
>
> --
>=C2=A0 =C2=A0o__
>=C2=A0 =C2=A0_> =C2=A0/__
> (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cle= aner
> world! :)
>
> Sridhar Bhaskaran
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--000000000000970fd305777c292f-- From nobody Mon Oct 8 13:15:19 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC54130F67 for ; Mon, 8 Oct 2018 13:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2pOM1CweubDM for ; Mon, 8 Oct 2018 13:15:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C616F130FCE for ; Mon, 8 Oct 2018 13:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=515; q=dns/txt; s=iport; t=1539029715; x=1540239315; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0YHFa95OEVJ3sgBXCCUSRPTKM8SbS7K7go/8ffn5Wtg=; b=LRE0+KIxks9gU216aqAmATLfwd4ve9pBWurciJbHvpNIV+JNj+W/t1HS n/YMQ0IDW0cg6qfgFvlEW0rBz5wub71CmyhEkN+CYb2vN4+YuShL2KUEH mdlfq1Eb/v3lum7qwY5PWThZdmo3cFFZRNLJ/sSwb8okSEu4+oRF/GK8/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAABKurtb/4gNJK1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwQBAQELAYIFZn8oCrEmFIFmCwEBI4RJhD8hNgsNAQMBAQIBAQJ?= =?us-ascii?q?tHAELhTsEHh1EDQE+QicEgzWBeQgPpgyDQGsBS4UTBYs5F4FBP4VlgVoCAQK?= =?us-ascii?q?BKwESAVGFJgKOJY9JCQKGTIl7F4E/D4RliUSCXYlLiSMCERSBJSQELWRxcBW?= =?us-ascii?q?DJ4IyiGWFPm8BizmBH4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,357,1534809600"; d="scan'208";a="182417302" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2018 20:15:14 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w98KFEQO011007 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Oct 2018 20:15:14 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Oct 2018 15:15:14 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 8 Oct 2018 15:15:14 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IETF103 - Call for agenda items Thread-Index: AQHUX0OfdYqwJuBZPEuL4DUPSSwZOg== Date: Mon, 8 Oct 2018 20:15:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [DMM] IETF103 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:15:18 -0000 Folks: The DMM working group is planning to meet in Bangkok, on Thursday, Nov 8th, 2018, for a 2.5 hour session (subject to change). The IETF 103 Preliminary Agenda has been posted and you can see it at, https://datatracker.ietf.org/meeting/103/agenda.html If you need a presentation slot, please send your request to the chairs (as a response to this email) with the following information. > Topic Name: > Presenter Name: > Time: > Draft Reference:=20 Regards Dapeng & Sri >>> >> > From nobody Tue Oct 9 12:24:38 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4E61293FB for ; Tue, 9 Oct 2018 12:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fwtHO_Ez4JDL for ; Tue, 9 Oct 2018 12:24:34 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DF312D7F8 for ; Tue, 9 Oct 2018 12:24:34 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 273956025940B for ; Tue, 9 Oct 2018 20:24:29 +0100 (IST) Received: from YYZEML701-CHM.china.huawei.com (10.218.33.71) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 20:24:31 +0100 Received: from YYZEML704-CHM.china.huawei.com ([169.254.1.6]) by YYZEML701-CHM.china.huawei.com ([169.254.4.46]) with mapi id 14.03.0415.000; Tue, 9 Oct 2018 15:24:21 -0400 From: Arashmid Akhavain To: "dmm@ietf.org" CC: TongWen , "Liyungang (WT Lab)" , "Lujianmin (Jianmin Lu)" , liuchenchen , Hassan Halabian Thread-Topic: Live demo: SRv6 user plane in mobile core Thread-Index: AdRgBaZtLgANhONxSA+VuMI2AdBw6A== Date: Tue, 9 Oct 2018 19:24:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: multipart/alternative; boundary="_000_D57109449177B54F8B9C093953AC5BCD755EB1A8yyzeml704chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Live demo: SRv6 user plane in mobile core X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:24:37 -0000 --_000_D57109449177B54F8B9C093953AC5BCD755EB1A8yyzeml704chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZXZlcnlvbmUsDQoNCkxhc3QgeWVhciwgSSBwcmVzZW50ZWQgYSBsaXZlIGRlbW8gdG8gYSBm ZXcgZ3JvdXBzIG9mIHRoZSBhdWRpZW5jZSBmcm9tIHRoZSBETU0gV0cgYW5kIHNob3dlZCB0aGUg Y29uY2VwdCBiZWhpbmQgdGhlIGFuY2hvcmxlc3MgbW9iaWxpdHkgKGRhdGEgcGxhbmUpIHRocm91 Z2ggdGhlIHVzZSBvZiBJRC1MT0MgYXJjaGl0ZWN0dXJlIGFuZCBjb21tb24gY2xvdWQgUFVCL1NV QiB0ZWNobm9sb2dpZXMuDQoNCkR1cmluZyBJRVRGIDEwMiBpbiBNb250cmVhbCwgd2UgcHJlc2Vu dGVkIGRyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2JpbGUtcG9jcyBhbmQgdGFsa2VkIGFib3V0 IHB1dHRpbmcgdG9nZXRoZXIgYSBwcm9vZiBvZiBjb25jZXB0IHRvIHNob3cgdGhlIHVzZSBvZiBT UnY2IGluIGluIGJvdGggNEcgRVBDIGFuZCA1ZyBtb2JpbGUgY29yZSB1c2VyIHBsYW5lLiBXZSBo YXZlIGJlZW4gd29ya2luZyBvbiB0aGlzIHByb29mIG9mIGNvbmNlcHQgYW5kIHdlcmUgd29uZGVy aW5nIGlmIHRoZXJlIGlzIGludGVyZXN0IG9uIHRoZSBtYWlsaW5nIGxpc3QgdG8gc2VlIHRoaXMg UE9DIGxpdmUgdmlhIGEgcmVtb3RlIFdlYkV4IGNvbmZlcmVuY2UgY2FsbC4gVGhlIGRlbW8gaXMg bm90IGxvbmcgYW5kIHdpbGwgdGFrZSBhYm91dCAzMC00NSBtaW51dGVzLiBIb3dldmVyLCB3ZSB3 aWxsIGdsYWRseSByZXNlcnZlIG1vcmUgdGltZSBvbiBXZWJFeCBpZiB0aGVyZSBhcmUgcGVvcGxl IHdobyB3b3VsZCBsaWtlIHRvIHByZXNlbnQgc2xpZGUgbWF0ZXJpYWxzIG9yIGhhdmUgZnVydGhl ciBkaXNjdXNzaW9ucyBvbiB0aGUgc3ViamVjdC4NCg0KV2UgYXJlIGN1cnJlbnRseSBhaW1pbmcg dG8gc2V0dXAgdGhpcyBjb25mZXJlbmNlIGNhbGwgc29tZXRpbWUgYmV0d2VlbiBPY3QgMTUtMTku IFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgYXJlIGludGVyZXN0ZWQgc28gdGhhdCB3ZSBjYW4g c2VjdXJlIHN1ZmZpY2llbnQgY29uZmVyZW5jZSBwb3J0cyBvbiBXZWJFeC4gIE1lYW53aGlsZSBo ZXJlIGlzIGEgYnJpZWYgZGVzY3JpcHRpb24gb2YgdGhlIGRlbW86DQoNCldlIHVzZSBPQUkgb3Bl biBzb3VyY2UgTFRFIHNvZnR3YXJlIGluIGNvbmp1bmN0aW9uIHdpdGggYSBtb2RpZmllZCB2ZXJz aW9uIG9mIHRoZSBWUFAgU1J2NiBzdGFjayBpbiBvdXIgZGVtby4gVGhlIGZpcnN0IHBoYXNlIG9m IG91ciB3b3JrIGZvY3VzZXMgb24gdGhlIG1pZ3JhdGlvbiBwYXRoIGZyb20gZXhpc3RpbmcgR1RQ IElQdjQgYmFzZWQgdXNlciBwbGFuZSB0byBTUnY2IGJhc2VkIHVzZXIgcGxhbmUuIFdlIGVtcGxv eSBTUnY2IGdhdGV3YXlzIChib3RoIHBoeXNpY2FsLCAgYW5kIHZpcnR1YWwpIGFsb25nIHRoZSB1 c2VyIHBsYW5lIGFkamFjZW50IHRvIGVOb2RlQiBhbmQgU1BHVyB0byBzZWFtbGVzc2x5IGNhcnJ5 IHRoZSB1c2VyIHRyYWZmaWMgb3ZlciBTUnY2LCBlbGltaW5hdGluZyBVRFAgYW5kIEdUUCBoZWFk ZXIgYW5kIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMgdG8gM0dQUCBjb250cm9sIHBsYW5lLg0K DQpUaGUgZGVtbyBpcyB1cCBhbmQgcnVubmluZyBpbiBvdXIgbGFiIGFuZCB3ZSBjYW4gYXJyYW5n ZSBmb3IgbXVsdGlwbGUgc2Vzc2lvbnMgaWYgbmVlZCBiZS4NCg0KTG9va2luZyBmb3J3YXJkIHRv IHlvdXIgcmVzcG9uc2UsDQpCZXN0IHJlZ2FyZHMsDQpBcmFzaG1pZCBBa2hhdmFpbg0KDQoNCg0K DQoNCg0KDQoNCg== --_000_D57109449177B54F8B9C093953AC5BCD755EB1A8yyzeml704chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgZXZlcnlvbmUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5MYXN0IHllYXIsIEkgcHJlc2Vu dGVkIGEgbGl2ZSBkZW1vIHRvIGEgZmV3IGdyb3VwcyBvZiB0aGUgYXVkaWVuY2UgZnJvbSB0aGUg RE1NIFdHIGFuZCBzaG93ZWQgdGhlIGNvbmNlcHQgYmVoaW5kIHRoZSBhbmNob3JsZXNzIG1vYmls aXR5DQogKGRhdGEgcGxhbmUpIHRocm91Z2ggdGhlIHVzZSBvZiBJRC1MT0MgYXJjaGl0ZWN0dXJl IGFuZCBjb21tb24gY2xvdWQgUFVCL1NVQiB0ZWNobm9sb2dpZXMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkR1cmluZyBJRVRGIDEwMiBpbiBNb250cmVhbCwgd2Ug cHJlc2VudGVkIGRyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2JpbGUtcG9jcyBhbmQgdGFsa2Vk IGFib3V0PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPg0KcHV0dGluZyB0b2dldGhlciBhIHByb29mIG9mIGNvbmNlcHQgdG8g c2hvdyB0aGUgdXNlIG9mIFNSdjYgaW4gaW4gYm90aCA0RyBFUEMgYW5kIDVnIG1vYmlsZSBjb3Jl IHVzZXIgcGxhbmUuIFdlIGhhdmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgcHJvb2Ygb2YgY29uY2Vw dCBhbmQgd2VyZSB3b25kZXJpbmcgaWYgdGhlcmUgaXMgaW50ZXJlc3Qgb24gdGhlIG1haWxpbmcg bGlzdCB0byBzZWUgdGhpcyBQT0MgbGl2ZSB2aWEgYSByZW1vdGUgV2ViRXggY29uZmVyZW5jZQ0K IGNhbGwuIFRoZSBkZW1vIGlzIG5vdCBsb25nIGFuZCB3aWxsIHRha2UgYWJvdXQgMzAtNDUgbWlu dXRlcy4gSG93ZXZlciwgd2Ugd2lsbCBnbGFkbHkgcmVzZXJ2ZSBtb3JlIHRpbWUgb24gV2ViRXgg aWYgdGhlcmUgYXJlIHBlb3BsZSB3aG8gd291bGQgbGlrZSB0byBwcmVzZW50IHNsaWRlIG1hdGVy aWFscyBvciBoYXZlIGZ1cnRoZXIgZGlzY3Vzc2lvbnMgb24gdGhlIHN1YmplY3QuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBhcmUgY3VycmVudGx5IGFpbWluZyB0 byBzZXR1cCB0aGlzIGNvbmZlcmVuY2UgY2FsbCBzb21ldGltZSBiZXR3ZWVuIE9jdCAxNS0xOS4g UGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBzbyB0aGF0DQogd2UgY2Fu IHNlY3VyZSBzdWZmaWNpZW50IGNvbmZlcmVuY2UgcG9ydHMgb24gV2ViRXguICZuYnNwO01lYW53 aGlsZSBoZXJlIGlzIGEgYnJpZWYgZGVzY3JpcHRpb24gb2YgdGhlIGRlbW86PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSB1c2UgT0FJIG9wZW4gc291cmNlIExURSBz b2Z0d2FyZSBpbiBjb25qdW5jdGlvbiB3aXRoIGEgbW9kaWZpZWQgdmVyc2lvbiBvZiB0aGUgVlBQ IFNSdjYgc3RhY2sgaW4gb3VyIGRlbW8uIFRoZSBmaXJzdCBwaGFzZSBvZiBvdXINCiB3b3JrIGZv Y3VzZXMgb24gdGhlIG1pZ3JhdGlvbiBwYXRoIGZyb20gZXhpc3RpbmcgR1RQIElQdjQgYmFzZWQg dXNlciBwbGFuZSB0byBTUnY2IGJhc2VkIHVzZXIgcGxhbmUuIFdlIGVtcGxveSBTUnY2IGdhdGV3 YXlzIChib3RoIHBoeXNpY2FsLCZuYnNwOyBhbmQgdmlydHVhbCkgYWxvbmcgdGhlIHVzZXIgcGxh bmUgYWRqYWNlbnQgdG8gZU5vZGVCIGFuZCBTUEdXIHRvIHNlYW1sZXNzbHkgY2FycnkgdGhlIHVz ZXIgdHJhZmZpYyBvdmVyIFNSdjYsIGVsaW1pbmF0aW5nDQogVURQIGFuZCBHVFAgaGVhZGVyIGFu ZCB3aXRob3V0IGFueSBtb2RpZmljYXRpb25zIHRvIDNHUFAgY29udHJvbCBwbGFuZS4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZGVtbyBpcyB1cCBhbmQgcnVu bmluZyBpbiBvdXIgbGFiIGFuZCB3ZSBjYW4gYXJyYW5nZSBmb3IgbXVsdGlwbGUgc2Vzc2lvbnMg aWYgbmVlZCBiZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkxvb2tp bmcgZm9yd2FyZCB0byB5b3VyIHJlc3BvbnNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkFyYXNobWlkIEFraGF2YWluPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D57109449177B54F8B9C093953AC5BCD755EB1A8yyzeml704chmchi_-- From nobody Wed Oct 10 07:40:56 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34A2130EE5 for ; Wed, 10 Oct 2018 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 64wI9YfJbpSK for ; Wed, 10 Oct 2018 07:40:52 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707B6130DD9 for ; Wed, 10 Oct 2018 07:40:52 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 38DE54941EC3D for ; Wed, 10 Oct 2018 15:40:47 +0100 (IST) Received: from YYZEML701-CHM.china.huawei.com (10.218.33.71) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 15:40:49 +0100 Received: from YYZEML704-CHM.china.huawei.com ([169.254.1.6]) by YYZEML701-CHM.china.huawei.com ([169.254.4.46]) with mapi id 14.03.0415.000; Wed, 10 Oct 2018 10:40:42 -0400 From: Arashmid Akhavain To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: IETF103 - Call for agenda items Thread-Index: AQHUX0OfdYqwJuBZPEuL4DUPSSwZOqUYj73A Date: Wed, 10 Oct 2018 14:40:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] IETF103 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 14:40:55 -0000 Hi Sri, I would like to ask for 15 min. I will either present remotely myself or ha= ve someone present on my behalf.=20 Here are the details of the presentation. Thank you, Arashmid Topic Name: A Smooth Migration of Mobile Core User Plane from GTP to SRv6 Presenter Name: Arashmid Akhavian Time: 15 min. Draft Reference: draft-camarillo-dmm-srv6-mobile-pocs > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > (sgundave) > Sent: 08 October 2018 16:15 > To: dmm@ietf.org > Subject: [DMM] IETF103 - Call for agenda items >=20 > Folks: >=20 > The DMM working group is planning to meet in Bangkok, on Thursday, Nov > 8th, 2018, for a 2.5 hour session (subject to change). The IETF 103 > Preliminary Agenda has been posted and you can see it at, > https://datatracker.ietf.org/meeting/103/agenda.html >=20 >=20 >=20 > If you need a presentation slot, please send your request to the chairs (= as a > response to this email) with the following information. >=20 >=20 > > Topic Name: > > Presenter Name: > > Time: > > Draft Reference: >=20 >=20 > Regards > Dapeng & Sri > >>> > >> > > >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Oct 11 19:29:11 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD05130DCF for ; Thu, 11 Oct 2018 19:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XOjvf_b-NRMe for ; Thu, 11 Oct 2018 19:29:07 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 91255130DCE for ; Thu, 11 Oct 2018 19:29:07 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w9C2T4UI020753; Fri, 12 Oct 2018 11:29:04 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id A44D6638500; Fri, 12 Oct 2018 11:29:04 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 98F686384B3; Fri, 12 Oct 2018 11:29:04 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 8A105400193; Fri, 12 Oct 2018 11:29:04 +0900 (JST) References: From: Shunsuke Homma Message-ID: Date: Fri, 12 Oct 2018 11:29:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] IETF103 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 02:29:10 -0000 Hi Sri, I'd like to ask for 10 min for reporting update of draft-hmm-dmm-5g-uplane-analysis. The details of the presentation is described below. Topic Name: Update of User Plane Protocol and Architectural Analysis on 3GPP 5G System Presenter Name: Shunsuke Homma Time: 10 min. Draft Reference: draft-hmm-dmm-5g-uplane-analysis Best regards, Shunsuke On 2018/10/09 5:15, Sri Gundavelli (sgundave) wrote: > Folks: > > The DMM working group is planning to meet in Bangkok, on Thursday, Nov > 8th, 2018, for a 2.5 hour session (subject to change). The IETF 103 > Preliminary Agenda has been posted and you can see it at, > https://datatracker.ietf.org/meeting/103/agenda.html > > > > If you need a presentation slot, please send your request to the chairs > (as a response to this email) with the following information. > > >> Topic Name: >> Presenter Name: >> Time: >> Draft Reference: > > > Regards > Dapeng & Sri >>>> >>> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Fri Oct 12 04:29:56 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5774E12F1A6 for ; Fri, 12 Oct 2018 04:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O1SiVf97rPAD for ; Fri, 12 Oct 2018 04:29:51 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id C4EFF1293FB for ; Fri, 12 Oct 2018 04:29:50 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w9CBThan024941; Fri, 12 Oct 2018 20:29:43 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 7DD3DEA7C8B; Fri, 12 Oct 2018 20:29:43 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 730B0EA7BB8; Fri, 12 Oct 2018 20:29:43 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 6F073400278; Fri, 12 Oct 2018 20:29:43 +0900 (JST) References: <69756203DDDDE64E987BC4F70B71A26DE580AA88@PALLENE.office.hd> From: Shunsuke Homma Message-ID: <3faeda33-551e-f210-c11d-a4891e11fa33@lab.ntt.co.jp> Date: Fri, 12 Oct 2018 20:30:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DE580AA88@PALLENE.office.hd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit To: Marco Liebsch , "dmm@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] extended data plane discussion - N6 traffic steering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 11:29:54 -0000 FYI, I discussed this topic with Marco as P2P, and copied my comments/questions and his answers below. Best regards, Shunsuke -- General Comments and questions: [SH] I assume that 3GPP 5G architecture is designed to provide basic control of user plane traffic with UPFs (and corresponded SMFs), and policy enforcements, such as QoS control, steering, or charging, would be done at UPF(s) in bi-direction. In other words, a UPF is deployed at place where some traffic handling is needed. Then, do you have any requirements to handle user plane traffic on N6 interface? [ml] that depends a lot on the deployment. Today all policies are in the UPFs and these are associated with data networks, hence N6 is potentially short. If we think about scenarios where we decouple the binding of a UPF to a data network, e.g. by sharing a UPF for traffic from multiple data networks, these data networks should have policies to route downlink traffic to the right UPF, in particular if there a more than one. Also, relocation of a UPF while maintaining the UE's IP address changes the IP address from a routable to a non-routable address. Hence, ID-LOC protocols, for example, can be used to steer traffic to the new UPF by using default routes in the transport network. We see this not necessarily required for all traffic, but for some deployments, in particular for future industry verticals. Moving the UPF while maintaining the session may in some cases more efficient (signaling costs, etc) than adding more and more UPFs which serve as PSAs, or adding more ULCL UPFs to route to a local data network. [SH] The current user plane protocol study proceeded in 3GPP CT4 mainly focuses on N9 interface, and N3 and N6 are out of scope. Do you have any plan to propose to expand the scope to 3GPP CT4? [ml] well, it would be nice, hence we want to extend the data plane discussion to N6 in the IETF first. We tried to being some of these cases to 3GPP SA2 some years ago, but the reaction was obvious that SGi/N6 is out of scope. Let me say this way: I am not sure how CT4 will treat the new protocols for N9/N3, hence nothing may change. Bringing in N6 allows us to apply IETF protocols and enable new use cases. Small comments: [SH] Regarding some figures representing 5G architecture, UPFs should be connected with N9 interface and every UPF must have N4 interface. [ml] Absolutely, but we did not want to sketch the complete architecture as it's already in many other IETF drafts we refer to. If you think it's confusing, we can add N4, no problem. [SH] As you may know, there is some difference between definition of data/user plane on 3GPP and IETF, and thus it's better to describe the definition in this document. [ml] good point. We can describe it, but let's see if in any of the existing drafts there is a definition, so we can align it. On 2018/09/21 4:37, Marco Liebsch wrote: > Folks, > > we submitted a new ID which extends the current data plane discussion > from N9/N3 to N6 interfaces > of the mobile systems architecture. > > We could discuss the use cases, problem statement and principles with > some before submission, but > post this initial draft to get the larger communitys feedback before we > update with more details and the > received feedback. > > Your comments are appreciated. > > Best regards, > > marco > > Name: draft-fattore-dmm-n6-cpdp-trafficsteering > > Revision: 00 > > Title: Control-/Data Plane Aspects for N6 Traffic > Steering > > Document date: 2018-09-20 > > Group: Individual Submission > > Pages: 12 > > URL: > https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/ > > Htmlized: > https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering > > Abstract: > > Current standardization effort on the evolution of the mobile > > communication system reconsiders the mobile data plane protocol. The > > IETF DMM Working Group has work that proposes and analyzes various > > protocols as alternative to the GPRS Tunneling Protocol for User > > Plane (GTP-U) for an overlay deployment in between the mobile > > device's assigned data plane anchor and its current radio base > > station, which are denoted as N9 and N3 interfaces. In the view of > > some future deployment and the original intent per the very early DMM > > WG charter, a mobile device's data plane anchor may be highly > > distributed and re-selected for optimization throughout a mobile > > device's communication with one or more correspondent services. Such > > re-configuration has impact on the packet routing in between the > > mobile device's data plane anchor and the one or multiple data > > networks hosting the services, which is denoted as N6 interface. > > This draft proposes and discusses a solution to control, setup and > > maintain traffic treatment policy on the cellular communication > > system's N6 interface while taking the UE's PDU session settings per > > the cellular system's control plane, such as QoS and locator > > information, into account. > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Fri Oct 19 12:03:06 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 829D41310D5; Fri, 19 Oct 2018 11:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh@kaloom.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539853.6592.12889542539631595439.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:38 -0700 Archived-At: Subject: [DMM] dmm - Requested session has been scheduled for IETF 103 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:47 -0000 Dear Sri Gundavelli, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmm Session 1 (2:00 requested) Thursday, 8 November 2018, Afternoon Session I 1350-1550 Room Name: Boromphimarn 1/2 size: 75 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/dmm.ics Request Information: --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: intarea Second Priority: ipwave People who must be present: Sri Gundavelli Suresh Krishnan Dapeng Liu Resources Requested: Special Requests: Preferred day: Monday --------------------------------------------------------- From nobody Sat Oct 20 03:37:56 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E7128A6E; Sat, 20 Oct 2018 03:37:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <154003187506.13770.775851391725108237@ietfa.amsl.com> Date: Sat, 20 Oct 2018 03:37:55 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-pmipv6-dlif-03.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 10:37:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : Proxy Mobile IPv6 extensions for Distributed Mobility Management Authors : Carlos J. Bernardos Antonio de la Oliva Fabio Giust Juan Carlos Zuniga Alain Mourad Filename : draft-ietf-dmm-pmipv6-dlif-03.txt Pages : 33 Date : 2018-10-20 Abstract: Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as a local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 20 03:40:55 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4996129BBF for ; Sat, 20 Oct 2018 03:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 U6ExsClV5K-r for ; Sat, 20 Oct 2018 03:40:50 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 6FB471294D0 for ; Sat, 20 Oct 2018 03:40:50 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id y144-v6so5854532wmd.4 for ; Sat, 20 Oct 2018 03:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=6y9EnNHJ6imDMB+0dHrCsQMktclNjCM+7qL/Z57B+eA=; b=pT9ff0jjDAOdIyKD8W0EAIniAby2xmEmJBhEQhoJ5X1JyS45sdRf3NEWPSj1gn9mjA MXXR1fNX7z7VIEJhe3YGcuFAo8bJCq8gbpVESJVC0fDoRB/p+tzrp9apWYOPe58rRehk kZRAIYuyo3KF7lkGsaGTinZ6dirv17V59jqO2nCXJ5H4UFkVjfjfLXZbhoDcY7gh6U2r iw+RcLKIh9iecdGI7jvSgG1tR3IIuC+NTPCf9qRz4Goczz8JRkXRDQGIYZ5swPlWJCmt 5P7fUMysybmii02az1BUQHfXKjiPjxh1f44Kk4bykDzhsIQOhERUxKG135m9o6L/Gfc0 udMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=6y9EnNHJ6imDMB+0dHrCsQMktclNjCM+7qL/Z57B+eA=; b=PS/2LLU//kcqbhkAcoHuztIDL38x7+iLtB7xG4OKFIySqnZkMjmMkTQUj/W4Nm5A7D oK92cICqfwQ3706MQoHHrXUcE+3+DGCBXgYSSwBgbkNdIYKBsH2z6aLCy8juXIOkvbIz xl9KrEkNB09Iyh2B1nf1ngHYuCJMVhCCTWPS/I0yKRxFzwiWXjYnL4XMVobx0voCWodn HJ9NVPwBhnKN1joWICcEXb9MfRJKIxZmxbEmCqJRc/jDte3ahSRARfEF87EWUw/POmCR oYk6gH+eqSW+tWEn5BbFNtRiBMqBxcIYBqUx+hwnT9+XVWWdBh4PcGIs+0ByA5re1adZ eKVQ== X-Gm-Message-State: ABuFfogEgr5+qbCUDnGBK9j+4jnrclo9B05zkryD2HEZYxQQ1DAs+bHm 7FCnKWyUnVfkw7RH0PINX98eRA== X-Google-Smtp-Source: ACcGV63YkAX0VZeSFUejLAmzHreH2xfw9XZ31WBgKN/BLAYLKV/+igeTN2Oo2g2+AKEHFj50sTdLZg== X-Received: by 2002:a1c:c1c7:: with SMTP id r190-v6mr8340761wmf.72.1540032048556; Sat, 20 Oct 2018 03:40:48 -0700 (PDT) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id p1-v6sm21347888wrs.40.2018.10.20.03.40.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 20 Oct 2018 03:40:47 -0700 (PDT) Message-ID: From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "Moses, Danny" , "dmm@ietf.org" Date: Sat, 20 Oct 2018 12:40:46 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Comments on draft-ietf-dmm-pmipv6-dlif-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 10:40:55 -0000 Hi Danny, Thanks a lot for the very good review you provided. We've just posted revision -03 addressing your comments. Rev -02 was also submitted after Montreal, addressing Lyle's also very good review. We'd like to ask the WG for feedback on current version. From authors' point of view the document is quite ready. Thanks, Carlos On Mon, 2018-09-10 at 14:34 +0000, Moses, Danny wrote: > > Hi guys, > > In the last DMM session I committed to review draft-ietf-dmm-pmipv6- > dlif and provide comments. > So here they are in the attached PDF file. > > Regards, > Danny > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Oct 21 17:25:14 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9D130DED for ; Sun, 21 Oct 2018 17:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 m-P_dNnEBY_C for ; Sun, 21 Oct 2018 17:25:09 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3D112D4EE for ; Sun, 21 Oct 2018 17:25:09 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w9M0P2IY006703 for ; Mon, 22 Oct 2018 09:25:02 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 62CBA638669 for ; Mon, 22 Oct 2018 09:25:02 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 57ECB638604 for ; Mon, 22 Oct 2018 09:25:02 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 4A910400BDB for ; Mon, 22 Oct 2018 09:25:02 +0900 (JST) References: <154016595394.10704.13334893710719482239.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <154016595394.10704.13334893710719482239.idtracker@ietfa.amsl.com> Message-ID: <7c2fe66a-c991-9250-0696-ef021fb32667@lab.ntt.co.jp> Date: Mon, 22 Oct 2018 09:25:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154016595394.10704.13334893710719482239.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: dmm@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 00:25:12 -0000 Hi folks, We polished the content of draft-homma-dmm-5gs-id-loc-coexistence, mainly case study on LISP. Your feedback would be appreciated. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-02.txt Date: Sun, 21 Oct 2018 16:52:33 -0700 From: internet-drafts@ietf.org To: Alberto Rodriguez-Natal , Kenta Kawakami , Ravi Shekhar , Arashmid Akhavain , Shunsuke Homma A new version of I-D, draft-homma-dmm-5gs-id-loc-coexistence-02.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-dmm-5gs-id-loc-coexistence Revision: 02 Title: Co-existence of 3GPP 5GS and Identifier-Locator Separation Architecture Document date: 2018-10-22 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-02.txt Status: https://datatracker.ietf.org/doc/draft-homma-dmm-5gs-id-loc-coexistence/ Htmlized: https://tools.ietf.org/html/draft-homma-dmm-5gs-id-loc-coexistence-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-homma-dmm-5gs-id-loc-coexistence Diff: https://www.ietf.org/rfcdiff?url2=draft-homma-dmm-5gs-id-loc-coexistence-02 Abstract: This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specifications, and shows the features and considerations of this approach. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Oct 21 23:52:44 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020B0120072 for ; Sun, 21 Oct 2018 23:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcn-ssu-ac-kr.20150623.gappssmtp.com 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 As2lB3hpWYDn for ; Sun, 21 Oct 2018 23:52:34 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 45AE9130EB8 for ; Sun, 21 Oct 2018 23:52:33 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id i4-v6so18557807pgq.9 for ; Sun, 21 Oct 2018 23:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dcn-ssu-ac-kr.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=1cd4tz35NxEQ8xr6PGmxW7oXTatlQNVgk1j86qsJwZ0=; b=zu2eBE630GT/jfqwr76gjL19PaDK17DMOC1suwXjKv5NyFk/fC+XU+PBhTJbJf5PtG nNVX8/wOUCkj6QIrwR9ee/H7qSkIG6A+YkNgJxvYtEA/tgQ9uAqKOHzASnNOu3E7qAYd U0iMkBtoD3XVqn0ITpsLntt/3CGVfr3X3I5qSHpsbtd19zXCq2Nl0kANecvHn9FTtJ3f x6GYWC9olOuJh493+GW/LfTH5FKpIQ8YorcltBGTqbVTYYVcABTIg+WC86fZj8S0fsGb jv/yxawWcTdY4Xve6G3KUUUOJ0b+j/98LqrWEkn0MzZiAo/8+o0PhNHjUtvgcpN4Xxaw p4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=1cd4tz35NxEQ8xr6PGmxW7oXTatlQNVgk1j86qsJwZ0=; b=UQv0IIkqtbIwksniTGj6+duZ32pHPRJammaajnoLCVXkrbkCDTEdXlPLTZlbQP5U1L dREdb66N6SvZo+9sa7bbCe3b9kkGnz0y70aMU71N38JlzmkqByPap8l120sw2nD63ZSF jrpHRYwvz/MEUiJiIzjABvu5QRln0533v+YsXQ80XVp5s0P0ulDxvNgEJKYAoOANENzk FcmfpEQGV6GOaGRgPJony162OB5CnF7LFrkAnRt5GgMvZe5nWJN/sWEWAtztE+GdBbuT 87hKF8OMi40PmTeoX4mLNSGKgEIG6rCKkaIdUtCRCteP9eIP4rnTKhuiTYbmjCgo+2NU toGQ== X-Gm-Message-State: ABuFfojsHsqrxIIyflm19XR4lecdNYLphzfbs3/CvRepTYFQIapkTPfU e46CoT21swrtJqGZfqB7MKt6iZFH+xI= X-Google-Smtp-Source: ACcGV63daN1/JfXwwhH5BTGnFe4Ic59/kF+HuGrfBuZp141k29cw+2w0s3yw+0YedOwK5cf3DnQThA== X-Received: by 2002:a63:5949:: with SMTP id j9-v6mr41945856pgm.210.1540191152329; Sun, 21 Oct 2018 23:52:32 -0700 (PDT) Received: from [172.20.10.3] ([110.70.27.176]) by smtp.gmail.com with ESMTPSA id w2-v6sm41441222pfk.140.2018.10.21.23.52.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Oct 2018 23:52:31 -0700 (PDT) From: =?utf-8?B?7ISg6rK97J6s?= Content-Type: multipart/alternative; boundary="Apple-Mail=_188B6998-C68D-47D2-BB41-96ECCC1E6F5B" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <587095ED-C9C2-456A-AE0D-20D0BCFDDDFD@dcn.ssu.ac.kr> References: <154019057036.10673.12129930135036472488.idtracker@ietfa.amsl.com> To: dmm@ietf.org Date: Mon, 22 Oct 2018 15:52:25 +0900 X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-sun-dmm-ondemand-cp-orchestration-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 06:52:43 -0000 --Apple-Mail=_188B6998-C68D-47D2-BB41-96ECCC1E6F5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks, we updated "On-demand DMM control plane orchestration=E2=80=9D = individual draft. In this draft, we try to define roles of mobility controller when = =E2=80=98on-demand CP-orchestation mode=E2=80=99 is using (defined in = draft-ietf-dmm-deployment-models). 01 version is minor updated from 00 version. We will welcome any of your review, comments or feedbacks to this I-D. Best Regards, KJ Kyoungjae Sun / K. J. SUN (Ph. D. Student) = --------------------------------------------------------------------------= -- Distributed Computing & Network laboratory (DCN Lab) School of Electronic Engineering, Soongsil Univ. 369 Sangdo-ro, Dongjak-gu, Seoul. = --------------------------------------------------------------------------= -- Tel. +82-2-814-0151 Mobile +82-10-3643-5627 Email gomjae@dcn.ssu.ac.kr > =EC=A0=84=EB=8B=AC=EB=90=9C =EB=A9=94=EC=8B=9C=EC=A7=80 =EC=8B=9C=EC=9E=91= : >=20 > =EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C: internet-drafts@ietf.org > =EC=A0=9C=EB=AA=A9: New Version Notification for = draft-sun-dmm-ondemand-cp-orchestration-01.txt > =EB=82=A0=EC=A7=9C: 2018=EB=85=84 10=EC=9B=94 22=EC=9D=BC =EC=98=A4=ED=9B= =84 3=EC=8B=9C 42=EB=B6=84 50=EC=B4=88 GMT+9 > =EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C: "Kyoungjae Sun" = , "Younghan Kim" , "KJ Sun" = , "Seil Jeon" , "Young-Han = Kim" >=20 >=20 > A new version of I-D, draft-sun-dmm-ondemand-cp-orchestration-01.txt > has been successfully submitted by Kyoungjae Sun and posted to the > IETF repository. >=20 > Name: draft-sun-dmm-ondemand-cp-orchestration > Revision: 01 > Title: On-demand DMM control plane orchestration > Document date: 2018-10-22 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-sun-dmm-ondemand-cp-orchestrati= on-01.txt > Status: = https://datatracker.ietf.org/doc/draft-sun-dmm-ondemand-cp-orchestration/ > Htmlized: = https://tools.ietf.org/html/draft-sun-dmm-ondemand-cp-orchestration-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-sun-dmm-ondemand-cp-orchestrat= ion > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sun-dmm-ondemand-cp-orchestratio= n-01 >=20 > Abstract: > This document describes the required functionalities of mobility > controller in the management and orchestration perspective for the > on-demand DMM service. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_188B6998-C68D-47D2-BB41-96ECCC1E6F5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi folks,

we updated "On-demand DMM control plane = orchestration=E2=80=9D individual draft.

In this draft, we try to define roles = of mobility controller when =E2=80=98on-demand CP-orchestation mode=E2=80=99= is using (defined in draft-ietf-dmm-deployment-models).

01 version is minor = updated from 00 version.

We will welcome any of your review, comments or feedbacks to = this I-D.

Best = Regards,

KJ



Kyoungjae Sun / K. J. SUN (Ph. D. Student)
---------------------------------------------------------------= -------------
Distributed Computing & Network = laboratory (DCN Lab)
School of Electronic Engineering, = Soongsil Univ.
369 Sangdo-ro, Dongjak-gu, Seoul.
---------------------------------------------------------------= -------------
Tel. +82-2-814-0151
Mobile +82-10-3643-5627
Email gomjae@dcn.ssu.ac.kr



=EC=A0=84=EB=8B=AC=EB=90=9C =EB=A9=94=EC=8B=9C=EC=A7=80 = =EC=8B=9C=EC=9E=91:

=EB=B3=B4=EB=82=B8 = =EC=82=AC=EB=9E=8C: internet-drafts@ietf.org
=EC=A0=9C=EB=AA=A9: = New Version = Notification for draft-sun-dmm-ondemand-cp-orchestration-01.txt
=EB=82=A0=EC= =A7=9C: 2018=EB=85=84 10=EC=9B=94= 22=EC=9D=BC =EC=98=A4=ED=9B=84 3=EC=8B=9C 42=EB=B6=84 50=EC=B4=88 = GMT+9
=EB=B0=9B=EB= =8A=94 =EC=82=AC=EB=9E=8C: "Kyoungjae Sun" <gomjae@dcn.ssu.ac.kr>, "Younghan Kim" <younghak@ssu.ac.kr>, = "KJ Sun" <gomjae@dcn.ssu.ac.kr>, "Seil Jeon" <sijeon@dcn.ssu.ac.kr>, "Young-Han Kim" <younghak@ssu.ac.kr>


A new version = of I-D, draft-sun-dmm-ondemand-cp-orchestration-01.txt
has = been successfully submitted by Kyoungjae Sun and posted to the
IETF repository.

Name: = draft-sun-dmm-ondemand-cp-orchestration
Revision: 01
Title: On-demand = DMM control plane orchestration
Document date: = 2018-10-22
Group: Individual Submission
Pages:= = 7
URL: =            https://www.ietf.org/internet-drafts/draft-sun-dmm-ondemand-cp-= orchestration-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-sun-dmm-ondemand-cp-orch= estration/
Htmlized: =       https://tools.ietf.org/html/draft-sun-dmm-ondemand-cp-orchestra= tion-01
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-sun-dmm-ondemand-cp= -orchestration
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-sun-dmm-ondemand-cp-o= rchestration-01

Abstract:
=   This document describes the required functionalities of = mobility
  controller in the management and = orchestration perspective for the
  on-demand = DMM service.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_188B6998-C68D-47D2-BB41-96ECCC1E6F5B-- From nobody Mon Oct 22 00:30:06 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623F9130DF4 for ; Mon, 22 Oct 2018 00:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aSXTq0LYsh_b for ; Mon, 22 Oct 2018 00:30:02 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id E7A21130DE1 for ; Mon, 22 Oct 2018 00:30:01 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w9M7Txe6021410 for ; Mon, 22 Oct 2018 16:29:59 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 0516B639623 for ; Mon, 22 Oct 2018 16:29:59 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id EE35B639610 for ; Mon, 22 Oct 2018 16:29:58 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id EA6FA40078E for ; Mon, 22 Oct 2018 16:29:58 +0900 (JST) References: <154019302848.15304.1048259136186298264.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <154019302848.15304.1048259136186298264.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 22 Oct 2018 16:30:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154019302848.15304.1048259136186298264.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: dmm@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 07:30:04 -0000 Hi folks, We reflected the discussion on this ML. Your review and feedback would be greatly appreciated. Main changes are described below: - termination points of GTP-U - setting QoS parameter of outer IP header - problems related to IP connectivity - summary of network slicing in 5GS - case studies on UPF selection Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-02.txt Date: Mon, 22 Oct 2018 00:23:48 -0700 From: internet-drafts@ietf.org To: daniel.voyer@bell.ca , Daniel Voyer , Takuya Miyasaka , Satoru Matsushima , Shunsuke Homma A new version of I-D, draft-hmm-dmm-5g-uplane-analysis-02.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-hmm-dmm-5g-uplane-analysis Revision: 02 Title: User Plane Protocol and Architectural Analysis on 3GPP 5G System Document date: 2018-10-22 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-02.txt Status: https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/ Htmlized: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-hmm-dmm-5g-uplane-analysis Diff: https://www.ietf.org/rfcdiff?url2=draft-hmm-dmm-5g-uplane-analysis-02 Abstract: This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 22 11:13:41 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D8D128B14; Mon, 22 Oct 2018 11:13:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <154023201972.7050.9808892102448120075@ietfa.amsl.com> Date: Mon, 22 Oct 2018 11:13:39 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-03.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 18:13:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : Segment Routing IPv6 for Mobile User Plane Authors : Satoru Matsushima Clarence Filsfils Miya Kohno Pablo Camarillo Garvia Daniel Voyer Charles E. Perkins Filename : draft-ietf-dmm-srv6-mobile-uplane-03.txt Pages : 28 Date : 2018-10-22 Abstract: This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility and SLA control for various applications. This document describes the SRv6 mobile user plane behavior and defines the SID functions for that. It also provides a mechanism for end-to-end network slicing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 24 00:07:40 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530C7130DF7 for ; Wed, 24 Oct 2018 00:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Ynz0zi9XLsHt for ; Wed, 24 Oct 2018 00:07:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0564130DD8 for ; Wed, 24 Oct 2018 00:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2094; q=dns/txt; s=iport; t=1540364855; x=1541574455; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Q3yxRquRUBtlklZMKAh7y/TYsCYN9idItaaoXJoqdSQ=; b=E57w/ro0JeSxYpdW7qX8K8B8ncJrfzFmG53EhVO+r/RXCx5W5qG6btzT IqJ0qid40RFmEjWu6lghJi8zas7ArnOPI/L32hmelcJMLak1k0yo1W63J vgl0jzcLu4xWs1v5MiNUgpQhju3i8q8qSAc3nkyE9HmNzE82UmoNCrzFa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAABkGdBb/4cNJK1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYIEZn8oCoNriBiMHoFolz2BegsBASWERwIXgnIhNA0?= =?us-ascii?q?NAQMBAQIBAQJtHAELhTsGIxFDEgIBCBoCJgICAjAVBgEGAwIEE4MhAYIBD6g?= =?us-ascii?q?AgS6EMAIMQD2Ea4ELilcXgUE/gTgME4JMgxsBAQIBARaBXoJsMYImAohfhXO?= =?us-ascii?q?QDAkChmSKEheBUkyEKYlvjGCJbgIRFIEmHTiBVXAVGksBgkEJixCFPm8BiyK?= =?us-ascii?q?BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,419,1534809600"; d="scan'208";a="190702109" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 07:07:34 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9O77YnZ018515 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Oct 2018 07:07:34 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 02:07:33 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 02:07:33 -0500 From: "Pablo Camarillo (pcamaril)" To: "dmm@ietf.org" Thread-Topic: New Version Notification for draft-camarillo-dmm-srv6-mobile-pocs-01.txt Thread-Index: AQHUakjWsOQZONJQ4E2loRckjG/PSqUucT4A Date: Wed, 24 Oct 2018 07:07:33 +0000 Message-ID: <34188FC9-5FE2-4537-BB0E-3089477C6802@cisco.com> References: <154024140943.13532.10832705429654806748.idtracker@ietfa.amsl.com> In-Reply-To: <154024140943.13532.10832705429654806748.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.164.3] Content-Type: text/plain; charset="utf-8" Content-ID: <39EB09158B2A9C4283B3BE2A8E05AF8F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [DMM] FW: New Version Notification for draft-camarillo-dmm-srv6-mobile-pocs-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 07:07:38 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBvZiB0aGlzIGRyYWZ0 IHdpdGggZnVydGhlciBkZXRhaWxzIG9uIHRoZSBQb0NzLg0KDQpUaGFua3MsDQpQYWJsby4NCg0K 77u/T24gMjIvMTAvMjAxOCwgMjI6NTAsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2JpbGUtcG9jcy0wMS50eHQNCiAgICBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhYmxvIENhbWFyaWxsbyBHYXJ2aWEg YW5kIHBvc3RlZCB0byB0aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJ CWRyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2JpbGUtcG9jcw0KICAgIFJldmlzaW9uOgkwMQ0K ICAgIFRpdGxlOgkJU2VnbWVudCBSb3V0aW5nIElQdjYgZm9yIG1vYmlsZSB1c2VyLXBsYW5lIFBv Q3MNCiAgICBEb2N1bWVudCBkYXRlOgkyMDE4LTEwLTIyDQogICAgR3JvdXA6CQlJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCiAgICBQYWdlczoJCTgNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2Jp bGUtcG9jcy0wMS50eHQNCiAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtY2FtYXJpbGxvLWRtbS1zcnY2LW1vYmlsZS1wb2NzLw0KICAgIEh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtYXJpbGxv LWRtbS1zcnY2LW1vYmlsZS1wb2NzLTAxDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtY2FtYXJpbGxvLWRtbS1zcnY2LW1vYmls ZS1wb2NzDQogICAgRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1jYW1hcmlsbG8tZG1tLXNydjYtbW9iaWxlLXBvY3MtMDENCiAgICANCiAgICBB YnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgb25nb2luZyBwcm9v ZiBvZiBjb25jZXB0cyBvZg0KICAgICAgIFtJLUQuaWV0Zi1kbW0tc3J2Ni1tb2JpbGUtdXBsYW5l XSBhbmQgdGhlaXIgcHJvZ3Jlc3MuDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K ICAgIA0KICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgDQogICAgDQoNCg== From nobody Thu Oct 25 11:40:02 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0544130E7B for ; Thu, 25 Oct 2018 11:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kWt_iBdS-fUX for ; Thu, 25 Oct 2018 11:39:58 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A0E128A6E for ; Thu, 25 Oct 2018 11:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2517; q=dns/txt; s=iport; t=1540492798; x=1541702398; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Rn7SR3CmZkUxDWv8FwsJbGp9SJODrMYFGLMMkAGgw1Y=; b=RnoMmIKU8XXTi0+5Iq99KY+/NxVH6eUsY6uGpRGZXvH+CuLYc0yThY+r 5WgDhJ9t9xo7Q/FJEWjKvJrs7zbM2ZOAp25LoHowFf1SihfLXBr1dora6 vXKWSexhE/FOtu2pvS8jqscenTIqXlLwxlhObvorS8kQP2ZbdPTmadzAv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACODdJb/4ENJK1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYIEZn8oCowDjBiZKYF6CwEBJYdaITQNDQEDAQECAQE?= =?us-ascii?q?CbRwBC4ZMARxkJwSDNYIBD6kLhDAECkA9hF0Fi2YXgUE/hWSBWgEBAwGHNwK?= =?us-ascii?q?IdoVkQY9bCQKGZooVGIFSjnGCZ4ZKgzmJeAIRFIEmHTiBVXAVGoMNgjKIZ4U?= =?us-ascii?q?+bwGMCIEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,425,1534809600"; d="scan'208";a="191032835" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 18:39:57 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9PIdv7I004057 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Oct 2018 18:39:57 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Oct 2018 13:39:56 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Thu, 25 Oct 2018 13:39:56 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IETF103 - DMM WG Meeting Agenda Thread-Index: AQHUbJIg0OucuKMb00mNybjNEhZkpw== Date: Thu, 25 Oct 2018 18:39:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.33.22] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4BEDE206F00A794C8803F87AA2A814E9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [DMM] IETF103 - DMM WG Meeting Agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 18:40:01 -0000 Its now posted. There will be changes w.r.t time allocations for each of the presentations.=20 https://datatracker.ietf.org/doc/agenda-103-dmm/ Sri ----------------------------------------------------------------- DMM Working Group Agenda =AD IETF103 Date: Thursday, November 8th, 2018 Time: 13:50-15:50; Thursday Afternoon session I Location: Bangkok=20 Chairs: Dapeng Liu (Alibaba) and Sri Gundavelli (Cisco) 1. Title: Administrivia & Intro, WG organization & milestones Time: 15 minutes Description: Agenda, Note-taker negotiation and WG Progress Update Presenters: Chairs 2.=20 Topic Name: SRv6 Mobile Userplane Presenter: Satoru Matsushima Time: 10 mins Draft reference:=20 https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane 3. Topic Name: Distributed Mobility Anchoring Presenter Name: Carlos J. Bernardos Time: 5 min Draft Reference:=20 https://www.ietf.org/id/draft-ietf-dmm-distributed-mobility-anchoring.txt 4. Topic Name: Proxy Mobile IPv6 extensions for Distributed Mobility Management Presenter Name: Carlos J. Bernardos Time: 10 min Draft Reference: https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif 5. Topic Name: FPC Update Presenter: Lyle Bertz Time: 10 minutes Draft Reference: https://www.ietf.org/id/draft-ietf-dmm-fpc-cpdp.txt =20 6. Topic Name: Traffic Steering Presenter: Umberto Fattore / Marco Liebsch Time: 10 minutes Draft Reference:=20 https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering 7. Topic Name: User Plane Protocol and Architectural Analysis on 3GPP 5G System=20 Presenter: Shunsuke Homma Time: 10 minutes Draft Reference:=20 https://www.ietf.org/id/draft-hmm-dmm-5g-uplane-analysis.txt 8.=20 Topic Name: A Smooth Migration of Mobile Core User Plane from GTP to SRv6 Presenter: Arashmid Akhavain / Pablo Camarillo Time: 10 minutes Draft Reference:=20 https://tools.ietf.org/html/draft-camarillo-dmm-srv6-mobile-pocs 9. Topic Name: Time Sensitive Networking for 5G Presenter: Kasu Venkat Reddy Time: 10 minutes Draft Reference: To be published 10. Topic Name: Transport Network aware mobility in 5G Presenter Name: Uma Chunduri Time: 10 mins Draft Reference:=20 https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility 11. Topic Name: SRv6 Mobile Use-cases Presenter: Satoru Matsushima / Pablo Camarillo Time: 10 mins Draft reference: draft-camarilloelmalky-springdmm-srv6-mob-usecases 12. Meeting Closure From nobody Tue Oct 30 11:27:57 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B740130DBE for ; Tue, 30 Oct 2018 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 T3N3DJFe9pIS for ; Tue, 30 Oct 2018 11:27:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EED9127333 for ; Tue, 30 Oct 2018 11:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4052; q=dns/txt; s=iport; t=1540924073; x=1542133673; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Z4DhNn4/aUUHlZ6rGDAzbrUO9lAYBEKcVJCpl4T+jpc=; b=PnyP/HW6u3zLPoopzrMJDTezX63+gBrY1W2ensDKwPzuaIUTmUdJrhle Ilx+GtcFEuwq2LxQDaNj9fe8qw7VCW6GISpZrF/lojCBPYDLcXnu7yNDI eGQNF18hDmqeSZDdf8U6MOg1/Vk8X1MZ/vynV/6Y0YhCfqJDE3z6CpXz0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAABvodhb/4MNJK1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBggRmfygKg2yIGIwZgg2XIIF6CwEBGA2ERxmDDSI0DQ0BAwE?= =?us-ascii?q?BAgEBAm0cAQuFOwYBATI6HQEIFAgoBCULJwQTgyKCAQ+NbJtGBoEwhDEECkA?= =?us-ascii?q?9hGcFgQWKYheBQT+EI4FBgVoBAQMBgXSCZ4JdAoh9hWeQLAkChmmKHBiBUoR?= =?us-ascii?q?3iX+CaoZPgz2KCQIRFIEmHTiBVXAVGiGCbIIyiGeFPm8BiliBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,445,1534809600"; d="scan'208";a="193498444" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 18:27:52 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9UIRqQV000623 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Oct 2018 18:27:52 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 13:27:51 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Tue, 30 Oct 2018 13:27:51 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] IETF103 - DMM WG Meeting Agenda Thread-Index: AQHUcH5EkwXLyKOUhE28V95aOB2Rdw== Date: Tue, 30 Oct 2018 18:27:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.51] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.19, xch-aln-009.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [DMM] IETF103 - DMM WG Meeting Agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 18:27:56 -0000 UHJlc2VudGVycyAtIFBsZWFzZSBzZW5kIHlvdXIgcHJlc2VudGF0aW9uIHNsaWRlcyBieSBTdW5k YXkgOVBNLCBJQ1QNCihsb2NhbCB0aW1lKS4NCg0KU3JpDQoNCg0KDQoNCg0KT24gMTAvMjUvMTgs IDExOjM5IEFNLCAiZG1tIG9uIGJlaGFsZiBvZiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIg0K PGRtbS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzZ3VuZGF2ZUBjaXNjby5jb20+IHdy b3RlOg0KDQo+DQo+SXRzIG5vdyBwb3N0ZWQuIFRoZXJlIHdpbGwgYmUgY2hhbmdlcyB3LnIudCB0 aW1lIGFsbG9jYXRpb25zIGZvciBlYWNoIG9mDQo+dGhlIHByZXNlbnRhdGlvbnMuDQo+DQo+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLTEwMy1kbW0vDQo+DQo+DQo+DQo+ U3JpDQo+DQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ETU0gV29ya2luZyBHcm91cCBBZ2VuZGEgoakgSUVU RjEwMw0KPg0KPg0KPkRhdGU6ICBUaHVyc2RheSwgTm92ZW1iZXIgOHRoLCAyMDE4DQo+VGltZTog IDEzOjUwLTE1OjUwOyBUaHVyc2RheSBBZnRlcm5vb24gc2Vzc2lvbiBJDQo+TG9jYXRpb246IEJh bmdrb2sgDQo+Q2hhaXJzOiBEYXBlbmcgTGl1IChBbGliYWJhKSBhbmQgU3JpIEd1bmRhdmVsbGkg KENpc2NvKQ0KPg0KPg0KPjEuDQo+VGl0bGU6IEFkbWluaXN0cml2aWEgJiBJbnRybywgV0cgb3Jn YW5pemF0aW9uICYgbWlsZXN0b25lcw0KPlRpbWU6IDE1IG1pbnV0ZXMNCj5EZXNjcmlwdGlvbjog QWdlbmRhLCBOb3RlLXRha2VyIG5lZ290aWF0aW9uIGFuZCBXRyBQcm9ncmVzcyBVcGRhdGUNCj5Q cmVzZW50ZXJzOiBDaGFpcnMNCj4NCj4yLiANCj5Ub3BpYyBOYW1lOiBTUnY2IE1vYmlsZSBVc2Vy cGxhbmUNCj5QcmVzZW50ZXI6IFNhdG9ydSBNYXRzdXNoaW1hDQo+VGltZTogMTAgbWlucw0KPkRy YWZ0IHJlZmVyZW5jZTogDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZG1tLXNydjYtbW9iaWxlLXVwbGFuZQ0KPg0KPjMuDQo+VG9waWMgTmFtZTogRGlzdHJpYnV0ZWQg TW9iaWxpdHkgQW5jaG9yaW5nDQo+UHJlc2VudGVyIE5hbWU6IENhcmxvcyBKLiBCZXJuYXJkb3MN Cj5UaW1lOiA1IG1pbg0KPkRyYWZ0IFJlZmVyZW5jZTogDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1kbW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLnR4dA0KPg0K PjQuDQo+VG9waWMgTmFtZTogUHJveHkgTW9iaWxlIElQdjYgZXh0ZW5zaW9ucyBmb3IgRGlzdHJp YnV0ZWQgTW9iaWxpdHkNCj5NYW5hZ2VtZW50DQo+UHJlc2VudGVyIE5hbWU6IENhcmxvcyBKLiBC ZXJuYXJkb3MNCj5UaW1lOiAxMCBtaW4NCj5EcmFmdCBSZWZlcmVuY2U6IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZg0KPg0KPjUuDQo+VG9waWMg TmFtZTogRlBDIFVwZGF0ZQ0KPlByZXNlbnRlcjogTHlsZSBCZXJ0eg0KPlRpbWU6IDEwIG1pbnV0 ZXMNCj5EcmFmdCBSZWZlcmVuY2U6IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt ZG1tLWZwYy1jcGRwLnR4dA0KPiAgICAgICAgICAgICAgICAgDQo+Ni4NCj5Ub3BpYyBOYW1lOiBU cmFmZmljIFN0ZWVyaW5nDQo+UHJlc2VudGVyOiBVbWJlcnRvIEZhdHRvcmUgLyBNYXJjbyBMaWVi c2NoDQo+VGltZTogMTAgbWludXRlcw0KPkRyYWZ0IFJlZmVyZW5jZTogDQo+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhdHRvcmUtZG1tLW42LWNwZHAtdHJhZmZpY3N0ZWVyaW5n DQo+DQo+Ny4NCj5Ub3BpYyBOYW1lOiBVc2VyIFBsYW5lIFByb3RvY29sIGFuZCBBcmNoaXRlY3R1 cmFsIEFuYWx5c2lzIG9uIDNHUFAgNUcNCj5TeXN0ZW0gDQo+UHJlc2VudGVyOiBTaHVuc3VrZSBI b21tYQ0KPlRpbWU6IDEwIG1pbnV0ZXMNCj5EcmFmdCBSZWZlcmVuY2U6IA0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLnR4dA0KPg0KPjgu IA0KPlRvcGljIE5hbWU6IEEgU21vb3RoIE1pZ3JhdGlvbiBvZiBNb2JpbGUgQ29yZSBVc2VyIFBs YW5lIGZyb20gR1RQIHRvIFNSdjYNCj5QcmVzZW50ZXI6IEFyYXNobWlkIEFraGF2YWluIC8gUGFi bG8gQ2FtYXJpbGxvDQo+VGltZTogMTAgbWludXRlcw0KPkRyYWZ0IFJlZmVyZW5jZTogDQo+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbWFyaWxsby1kbW0tc3J2Ni1tb2JpbGUt cG9jcw0KPg0KPjkuDQo+VG9waWMgTmFtZTogVGltZSBTZW5zaXRpdmUgTmV0d29ya2luZyBmb3Ig NUcNCj5QcmVzZW50ZXI6IEthc3UgVmVua2F0IFJlZGR5DQo+VGltZTogMTAgbWludXRlcw0KPkRy YWZ0IFJlZmVyZW5jZTogVG8gYmUgcHVibGlzaGVkDQo+DQo+MTAuDQo+VG9waWMgTmFtZTogVHJh bnNwb3J0IE5ldHdvcmsgYXdhcmUgbW9iaWxpdHkgaW4gNUcNCj5QcmVzZW50ZXIgTmFtZTogVW1h IENodW5kdXJpDQo+VGltZTogMTAgbWlucw0KPkRyYWZ0IFJlZmVyZW5jZTogDQo+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsdC1kbW0tdG4tYXdhcmUtbW9iaWxpdHkNCj4NCj4x MS4NCj5Ub3BpYyBOYW1lOiBTUnY2IE1vYmlsZSBVc2UtY2FzZXMNCj5QcmVzZW50ZXI6IFNhdG9y dSBNYXRzdXNoaW1hIC8gUGFibG8gQ2FtYXJpbGxvDQo+VGltZTogMTAgbWlucw0KPkRyYWZ0IHJl ZmVyZW5jZTogZHJhZnQtY2FtYXJpbGxvZWxtYWxreS1zcHJpbmdkbW0tc3J2Ni1tb2ItdXNlY2Fz ZXMNCj4NCj4NCj4xMi4gTWVldGluZyBDbG9zdXJlDQo+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5kbW0gbWFpbGluZyBsaXN0DQo+ZG1tQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0K