From nobody Thu Aug 2 11:42:54 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 5E526131277; Thu, 26 Jul 2018 09:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Dapeng Liu" , "The IETF Chair" , "Sri Gundavelli" Cc: Dapeng Liu , The IESG , Terry Manderson , Sri Gundavelli , 3GPPLiaison@etsi.org, georg.mayer.huawei@gmx.com, The IETF Chair , Distributed Mobility Management Discussion List , Suresh Krishnan X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153262344537.25888.10807663760750626065.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2018 09:44:05 -0700 Archived-At: X-Mailman-Approved-At: Thu, 02 Aug 2018 11:42:53 -0700 Subject: [DMM] New Liaison Statement, "LS OUT on User Plane Analysis" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 16:44:14 -0000 Title: LS OUT on User Plane Analysis Submission Date: 2018-07-26 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1590/ From: Sridhar Bhaskaran To: The IETF Chair ,Sri Gundavelli ,Dapeng Liu Cc: Dapeng Liu ,The IESG ,Terry Manderson ,Sri Gundavelli ,The IETF Chair ,Distributed Mobility Management Discussion List ,Suresh Krishnan Response Contacts: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org Technical Contacts: Purpose: For information Body: 1. Overall Description: CT4 reviewed the IETF draft-hmm-dmm-5g-uplane-analysis-00 based on the input discussion paper submitted to CT4 in C4-185292. CT4 thanks IETF DMM for their analysis. CT4 would like to provide the following initial feedback on the same. CT4 intends to do further analysis and provide any additional feedback, if any, in future. CT4 would like to emphasize that the evaluation criteria for the user plane protocol study (FS_UPPS) in 5GC shall be defined by 3GPP CT4 and the work has just now started in 3GPP. 2. Actions: To IETF DMM Group. ACTION: CT4 kindly requests IETF DMM to take the above initial feedback into consideration. 3. Date of Next CT and CT4 Meetings: CT4#86 20th – 24th Aug 2018 West Palm Beach, US CT#81 10th - 11th Sep 2018 Gold Coast, Australia CT4#86bis 15th - 19th Oct 2018 Vilnius, Lithuania Attachments: C4-185491-LSOUT-IETF-GTP-U https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-07-26-3gpp-tsgct-ct4-ietf-dmm-ls-out-on-user-plane-analysis-attachment-1.doc From nobody Wed Aug 8 07:17:12 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 AAE92130DE0 for ; Wed, 8 Aug 2018 07:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 5haDiaoCARqp for ; Wed, 8 Aug 2018 07:17:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1C2130DCC for ; Wed, 8 Aug 2018 07:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3350; q=dns/txt; s=iport; t=1533737827; x=1534947427; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b44RCemuWlhosxUegZ4QMrAPOVT/K01Rs9UT5kUJ5lo=; b=aD8R2npfsvWjzGHxhYRpmuBYBzu3Ejwaf2tW6sAj+67rh9rYV4+tenf5 MR3ityvGWIdallax+NT9B/gyW/e1ynpZYnukboH05c1i5mkkJRrfFzIrH lJaezkS3+1GixtNdvgfHTWC3189vs54qWuor+dSbJGBBzl1V5tV/EZM2K 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAAt+2pb/5FdJa1dGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNOY38oCot+jEGCDYhHjSoUgWYLGA2EAUYCgxIhNBgBAgEBAgE?= =?us-ascii?q?BAm0cAQuFNwEBAQEDAQFsGwIBCBQBAy4hBgsbAQYDAgQTgyGBaAMVD6xVhCg?= =?us-ascii?q?BPYI6DYMlBYkUF4FBP4ERAYMSglZFAQEDgSIEXgaFKgKHfIU4jGYrCQKGGoY?= =?us-ascii?q?egw+BT4Qmhx2BGogjglJXhwICERSBJB04gVJwFRohgmmLFYU+bwGNIIEbAQE?= X-IronPort-AV: E=Sophos;i="5.51,457,1526342400"; d="scan'208";a="154085708" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2018 14:17:06 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w78EH6Hu030656 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Aug 2018 14:17:06 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 8 Aug 2018 09:17:05 -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.1320.000; Wed, 8 Aug 2018 09:17:05 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "LS OUT on User Plane Analysis" Thread-Index: AQHULyJ7MmDe6NDt10mtNdq0OLYAiw== Date: Wed, 8 Aug 2018 14:17:05 +0000 Message-ID: References: <153262344537.25888.10807663760750626065.idtracker@ietfa.amsl.com> In-Reply-To: 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="iso-8859-1" Content-ID: <3A373A62FAB7C54CABE974F02904512B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [DMM] FW: New Liaison Statement, "LS OUT on User Plane Analysis" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 14:17:11 -0000 Thank you Shunsuke for your comments. Folks - Please review the new liaison request from CT4 (posted last week) and send your feedback to the DMM mailer. Sri On 8/6/18, 11:52 PM, "Shunsuke Homma" wrote: >Dear 3GPP CT4 folks, > >The authors appreciate the kind review and beneficial feedback from CT4. >We are proceeding the update of draft-hmm-dmm-5g-uplane-analysis for >reflecting the feedback. We will complete the updating and publish the >next version within few days. > >As you may know, this analysis is being done for helping for IETF folks >to understand 3GPP specifications and to improve contents of proposals >from IETF. Also, we understand that evaluation criteria must be decided >by 3GPP side, and the evaluation aspects described in this analysis >draft are just references. > >We hope that we can take more close communication with CT4 on this study. > >Best regards, > >Shunsuke > > >On 2018/07/27 1:44, Liaison Statement Management Tool wrote: >> Title: LS OUT on User Plane Analysis >> Submission Date: 2018-07-26 >> URL of the IETF Web page: https://datatracker.ietf.org/liaison/1590/ >>=20 >> From: Sridhar Bhaskaran >> To: The IETF Chair ,Sri Gundavelli >>,Dapeng Liu >> Cc: Dapeng Liu ,The IESG ,Terry >>Manderson ,Sri Gundavelli >>,The IETF Chair ,Distributed >>Mobility Management Discussion List ,Suresh Krishnan >> >> Response Contacts: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org >> Technical Contacts: >> Purpose: For information >>=20 >> Body: 1. Overall Description: >> CT4 reviewed the IETF draft-hmm-dmm-5g-uplane-analysis-00 based on the >>input discussion paper submitted to CT4 in C4-185292. CT4 thanks IETF >>DMM for their analysis. CT4 would like to provide the following initial >>feedback on the same. CT4 intends to do further analysis and provide any >>additional feedback, if any, in future. CT4 would like to emphasize that >>the evaluation criteria for the user plane protocol study (FS_UPPS) in >>5GC shall be defined by 3GPP CT4 and the work has just now started in >>3GPP. >>=20 >>=20 >>=20 >>=20 >>=20 >> 2. Actions: >> To IETF DMM Group. >> ACTION: >> CT4 kindly requests IETF DMM to take the above initial feedback into >>consideration. >>=20 >> 3. Date of Next CT and CT4 Meetings: >> CT4#86 20th =AD 24th Aug 2018 West Palm Beach, US >> CT#81 10th - 11th Sep 2018 Gold Coast, Australia >> CT4#86bis 15th - 19th Oct 2018 Vilnius, Lithuania >> Attachments: >>=20 >> C4-185491-LSOUT-IETF-GTP-U >> =20 >>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-07-26-3gpp-tsg >>ct-ct4-ietf-dmm-ls-out-on-user-plane-analysis-attachment-1.doc >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 > > >--=20 >---------------------------------- >Shunsuke Homma > >TEL: +81 422 59 3486 >FAX: +81 422 60 7460 > >NTT Network Service Systems Labs. >Musashino city, Tokyo, Japan >---------------------------------- From nobody Fri Aug 10 02:24:18 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 0F1A0130F32 for ; Fri, 10 Aug 2018 02:24:09 -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 K50CbbL3-eDB for ; Fri, 10 Aug 2018 02:24:04 -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 0652F130F7E for ; Fri, 10 Aug 2018 02:24:03 -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 w7A9O3fx010926 for ; Fri, 10 Aug 2018 18:24:03 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 5DFE0638E12 for ; Fri, 10 Aug 2018 18:24:03 +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 52CED638DB3 for ; Fri, 10 Aug 2018 18:24:03 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 4FA724007E5 for ; Fri, 10 Aug 2018 18:24:03 +0900 (JST) References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> Message-ID: <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> Date: Fri, 10 Aug 2018 18:24:10 +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: <153389066068.1543.4964118743607776580.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-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 09:24:15 -0000 Hi DMM folks, We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis and uploaded the new version. We need more reviews from both IETF and 3GPP for further improvement. We will appreciate if you can give comments or feedback to this I-D. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt Date: Fri, 10 Aug 2018 01:44:20 -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-01.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-hmm-dmm-5g-uplane-analysis Revision: 01 Title: User Plane Protocol and Architectural Analysis on 3GPP 5G System Document date: 2018-08-10 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.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-01 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-01 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 Sat Aug 11 11:49: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 3A00A1310CC for ; Sat, 11 Aug 2018 11:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 GYxAKKxOINc7 for ; Sat, 11 Aug 2018 11:49:18 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 57FB8130E8C for ; Sat, 11 Aug 2018 11:49:18 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id f12-v6so10884688wrv.12 for ; Sat, 11 Aug 2018 11:49:18 -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; bh=qDPc5dNErxCPX2xFzaH3pJST0Fgtpwm8Ma4ORqRVaGI=; b=JpqkNL/8ysvxBC2tCmRzRkG78yjAaA4DCA6fhcuIEmkYxio6nyvJHmHt0ncMaLAJzF KVQ6HRlQep/j0qcLGuE14MDLa1AGGKMWA0Q6OBUc5VJYQ+1m/l2PjnXB6JnGvfNIzMc+ Ro0z4L2i7smXZQNSjqQ4UNOq/xD6Xg8tVoBNqZORsjgkdrNoHgNN/H+5a5gDLYs70v8V 26QMZjm3nXdXz3K0Qec13QjcKdqxvza7Xof/y6vnLRSq2hmhBFIxZANTqZUgDxxG0HX/ pEqjOS1aQjG4jh/vA+WCeGHPmAoySYaILQgKloW0jahPl8AQffyTgrzyVoDcVTkcSMqs B5QA== 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; bh=qDPc5dNErxCPX2xFzaH3pJST0Fgtpwm8Ma4ORqRVaGI=; b=XGuLcWPSRVrUp6YkOllRlQ4EcToITNDPEL7jLkprDuz97JJzYz/FkNNgHoA/F30Vjj dEkARvyqS9uHRisbo/we3S1QXFaissBUge2OlgZvo3F/znjKkWkViRxI44GWUxyQ113u 1eOuSZgbBm7cuKW8gO10CVky8tH8GvcdPQMticAh723ssQIvO3ABVZDovN+ADywOCns6 X9KZxVFPsaZswg2RZwy+wEVOXOOnRCAwxX09sgdLLjLbwIZRn4S4l4tItnevN7ySVYey dB+4Tm1c/Rls29hcf80xkRY+diM5PU8IdQWCLQqFeyaqx54Gna8InPKfK+G+D8k/MS+K iz/w== X-Gm-Message-State: AOUpUlEoIFNFVewC7XYUcUsLALb0mjJTuWp2TwaHGIPp9c/7BxNWmBZK 9RktEQg8A98gz7MrzjkBRSJ5KmIJw6sMoyNMdbAScz6DVBo= X-Google-Smtp-Source: AA+uWPzb02DcfKO5ENFNiw7VpM2dL6fU1+KessUa53j+3A36egGivfhHwi2s08NlkFJ7X/he2IbyxT2AsFSkjq0fD38= X-Received: by 2002:adf:a963:: with SMTP id u90-v6mr7182468wrc.248.1534013356487; Sat, 11 Aug 2018 11:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:fa86:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 11:49:16 -0700 (PDT) In-Reply-To: <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> From: Tom Herbert Date: Sat, 11 Aug 2018 11:49:16 -0700 Message-ID: To: Shunsuke Homma Cc: dmm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 18:49:21 -0000 Hi Shunsuke, Thanks for the draft! It does a very good job of describing and framing GTP-U using IETF terminology. This should help significantly to bridge that gap of understanding between IETF and 3GPP. Some comments: General comment: Please look at "Encapsulation Considerations" (https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02). There's a lot of material there that might be relevant to encapsulation aspects of GTP-U. General comment: There are a number of recommendations that could be extracted and made to improve GTP (in section 3 in particular). Does it make sense to these in their own document as a recommendation to 3GPP for a future update of GTP? Section 1: "Another aspects of user plane requirements couldn't be found." - I'm not sure what this means Section 3: "Allocation of UDP source port depends on sender tunnel endpoint node and GTP-U supports dynamic allocation of UDP source port for load balancing objective." - How is this done in practice. In most UDP encapsulation protocols the UDP source is set to value from the hash over a tuple of the encapsulated packet. This way, the outer packet can ECMP router each encapsulated flow for load balancing. If this were done in GTP-U this would probably mean that the source port is not consistent for all packets sent on a tunnel. Would this be consistent with 3GPP specifications? "GTP-U does not support IPv6 flow label for load balancing in case of IPv6 transport." - does the spec say anything about flow label, does it need to be set to zero otherwise? This should be an easy fix since setting flow label isn't a wire protocol change and setting flow label has already commonly implemented in other encapsulations. "UDP zero checksum is not available in case of IPv6 transport." - Setting a UDPv6 zero checksum is a little tricky. RFC6935 and RFC6936 need to be considered, but also the specifics and conditions of the protocol an conditions of deployment. For instance, RFC8086 goes into inordinate detail on requirements to set a zero UDPv6 checksum. "GTP-U does not support to response ICMP PTB for Path MTU Discovery." - I'm not sure what this means. Is this saying that if a GTP-U endpoint receives an ICMP PTB error for a packet sent over tunnel, it doesn't handle that; or is this saying that if a packet from a UE is dropped at a GTP tunnel ingress point because of MTU exceeded then no ICMP PTB is sent? If it's the first case, then that's not much a problem. I doubt PMTU discovery has been implemented for many tunnels. Usually one of the suggestions in RFC4459 is used (that RFC should be referenced in the draft). If it's the second case, then that is more of a bug in the protocol that should be fixed (this is IP layer requirements, should not be specific to GTP-U). "Following list summarizes every extension header which is used for user plane protocol." - Used or defined? It would be good to know which, if any extension headers are commonly used in the data path. This will also be input to the issued raised later on about the efficiency of extension header processing. "DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel endpoint node based on the QFI." - This should be rectified with RFC2983. "In general, multiple GTP-U extension headers are able to contained in one GTP-U packet and the order of those extension headers is not specified by [TS.29.281-3GPP]." - That is the combinatoric nature of TLVs. There has been much discussion on that. A potentially related question would be does GTP-U limit the number or size of extension headers (unlimited TLVs in a packet could be used as a potential denial of service attack. "GTP-U does not support to indicate next protocol type." - A bit unfortunate, IMO an encapsulation should also have a type field. Conceptually, there is a way around this by defining the the first nibble after GTP-U headers to be a type field (similar to GUEv1). 0x4 and 0x6 are IPv4 and IPv6, which is convenient since this coincides with the version number of an overlaid encapsulated IP packet. Other values could be used for different types. "GTP-U supports active OAM as a path management message "Echo Request/Response"" - Does GTP-U support in-situ OAM? Header format "DSCP=0" in inner packet. Is this a requirement? There should be some discussion about how ECN is handled. RFC6040 should probably be referenced. Section 4: "Then, the content information of the PDU may be mapped into UDP port number" - I don't follow this. Does this mean that different destination port numbers are used to determine the protocol of the T-PDU? "For this, the expected evaluation points from this aspect should be whether there is substitutional means to cover other PDU session types. And how much it makes simple the system than deploying original PDU session types." - Is this another way of saying the encapsulation protocols should have type field? :-) "However it increases header size from 20bytes to 40bytes compare to IPv4." - That's also an overhead problem. In a bandwidth constrained IoT network where average packet sizes might be as little at 100 bytes, the overhead of two IPv6 headers, GTP-U header and extensions, and an eight byte UDP header becomes significant to the extent that overhead packet becomes majority portion of bytes. Techniques to reduce the overhead could be warranted (ILA is one optimization that does that). Section 5 is good, but it would be nice to highlight whether or not GTP-U can satisfy the evaluation aspects. Most of the problems of GTP-U listed in section 3 are relatively minor and can be addressed without significant protocol change (e.g. turning on flow label should be trivial). The biggest feature touted by the candidate protocols seems to be anchor-less mobility (might be a topic worth mentioning in the draft). AFAICT, GTP-U is sufficiently generic and extensible so that it could be used a the user plane of anchor-less mobility without much change. Control plane would need major changes, but that is probably similar to what needed in the control plane for other user plane protocols to provide anchorless mobility. Tom On Fri, Aug 10, 2018 at 2:24 AM, Shunsuke Homma wrote: > Hi DMM folks, > > We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis and > uploaded the new version. We need more reviews from both IETF and 3GPP for > further improvement. We will appreciate if you can give comments or feedback > to this I-D. > > Best regards, > > Shunsuke > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-hmm-dmm-5g-uplane-analysis-01.txt > Date: Fri, 10 Aug 2018 01:44:20 -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-01.txt > has been successfully submitted by Shunsuke Homma and posted to the > IETF repository. > > Name: draft-hmm-dmm-5g-uplane-analysis > Revision: 01 > Title: User Plane Protocol and Architectural Analysis on 3GPP 5G > System > Document date: 2018-08-10 > Group: Individual Submission > Pages: 30 > URL: > https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.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-01 > 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-01 > > 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 > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Aug 20 03:47:52 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 62DC412F1A5 for ; Mon, 20 Aug 2018 03:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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] 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 NFU6aHZWob0a for ; Mon, 20 Aug 2018 03:47:47 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 795A3126F72 for ; Mon, 20 Aug 2018 03:47:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w7KAljPn184151 for ; Mon, 20 Aug 2018 12:47:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C839204BF0 for ; Mon, 20 Aug 2018 12:47:45 +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 025D9202624 for ; Mon, 20 Aug 2018 12:47:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w7KAliXf012407 for ; Mon, 20 Aug 2018 12:47:44 +0200 To: dmm@ietf.org References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> From: Alexandre Petrescu Message-ID: <8076cb7d-3fd5-aa6d-bb3e-13f9c2be6e72@gmail.com> Date: Mon, 20 Aug 2018 12:47:44 +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: <4bb86015-b18b-d899-079d-3b893b6bb9e6@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] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 10:47:50 -0000 Hi, thanks for the draft. I am happy you wrote and published it. I am looking forward for a packet capture from a live cellular network that illustrates this outer packet header format described in the draft. In particular, the Source and Destination IPv6 addresses (not IPv4). I can suppose that the two addresses would have same prefix, because that would be a point-to-point link and these links would have same prefix. (i.e. if the src is 2001:db8:1:1::1 then dst would be 2001:db8:1:1::2 and not 2001:db8:1:2::1). This is only supposition from my side, because I have never seen a packet capture of this. > 3.5. Packet Format > > Figure 4 shows a packet format example of GTP-U over IPv6 that > carries an extension header for QFI and an IPv6 PDU. All values in > the example are illustration purpose only. The encoding of PDU > Session Container for QFI refers to [TS.38.415-3GPP]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > Outer IPv6 Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| DSCP=EF | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | NxtHdr=17(UDP)| Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source IPv6 Address + > | 2001:db8:1:1::1 | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination IPv6 Address + > | 2001:db8:1:2::1 | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alex Le 10/08/2018 à 11:24, Shunsuke Homma a écrit : > Hi DMM folks, > > We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis > and uploaded the new version. We need more reviews from both IETF and > 3GPP for further improvement. We will appreciate if you can give > comments or feedback to this I-D. > > Best regards, > > Shunsuke > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-hmm-dmm-5g-uplane-analysis-01.txt > Date: Fri, 10 Aug 2018 01:44:20 -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-01.txt > has been successfully submitted by Shunsuke Homma and posted to the > IETF repository. > > Name:        draft-hmm-dmm-5g-uplane-analysis > Revision:    01 > Title:        User Plane Protocol and Architectural Analysis on 3GPP 5G > System > Document date:    2018-08-10 > Group:        Individual Submission > Pages:        30 > URL: > https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.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-01 > 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-01 > > 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 > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Mon Aug 20 07:58:16 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 44868130FF8 for ; Mon, 20 Aug 2018 07:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ijPh8nw8-stJ for ; Mon, 20 Aug 2018 07:58:08 -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 F301E130F72 for ; Mon, 20 Aug 2018 07:58:07 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7BDAEC34545D4 for ; Mon, 20 Aug 2018 15:58:04 +0100 (IST) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 20 Aug 2018 15:58:05 +0100 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.41]) by YYZEML703-CHM.china.huawei.com ([169.254.5.252]) with mapi id 14.03.0399.000; Mon, 20 Aug 2018 10:58:02 -0400 From: Arashmid Akhavain To: Alexandre Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt Thread-Index: AQHUOHNSWR0kOJSa7E+eQykEmOzHjaTIucuw Date: Mon, 20 Aug 2018 14:58:02 +0000 Message-ID: References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> <8076cb7d-3fd5-aa6d-bb3e-13f9c2be6e72@gmail.com> In-Reply-To: <8076cb7d-3fd5-aa6d-bb3e-13f9c2be6e72@gmail.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:58:15 -0000 QWxleCwNCkkgdGhpbmsgeW91IG1pc3NlZCB0aGlzIGRpc2NsYWltZXIgaW4gDQoiQWxsIHZhbHVl cyBpbiB0aGUgZXhhbXBsZSBhcmUgaWxsdXN0cmF0aW9uIHB1cnBvc2Ugb25seSINCg0KR2VuZXJh bGx5IHNwZWFraW5nLCB0aGVyZSBpcyBubyBndWFyYW50ZWUgZm9yIGEgcG9pbnQgdG8gcG9pbnQg bGluay4NCg0KDQpBcmFzaG1pZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFu ZHJlDQo+IFBldHJlc2N1DQo+IFNlbnQ6IDIwIEF1Z3VzdCAyMDE4IDA2OjQ4DQo+IFRvOiBkbW1A aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtETU1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1obW0tZG1tLTVnLQ0KPiB1cGxhbmUtYW5hbHlzaXMtMDEudHh0DQo+IA0K PiBIaSwgdGhhbmtzIGZvciB0aGUgZHJhZnQuICBJIGFtIGhhcHB5IHlvdSB3cm90ZSBhbmQgcHVi bGlzaGVkIGl0Lg0KPiANCj4gSSBhbSBsb29raW5nIGZvcndhcmQgZm9yIGEgcGFja2V0IGNhcHR1 cmUgZnJvbSBhIGxpdmUgY2VsbHVsYXIgbmV0d29yayB0aGF0DQo+IGlsbHVzdHJhdGVzIHRoaXMg b3V0ZXIgcGFja2V0IGhlYWRlciBmb3JtYXQgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCj4gDQo+ IEluIHBhcnRpY3VsYXIsIHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIElQdjYgYWRkcmVzc2Vz IChub3QgSVB2NCkuDQo+IA0KPiBJIGNhbiBzdXBwb3NlIHRoYXQgdGhlIHR3byBhZGRyZXNzZXMg d291bGQgaGF2ZSBzYW1lIHByZWZpeCwgYmVjYXVzZSB0aGF0DQo+IHdvdWxkIGJlIGEgcG9pbnQt dG8tcG9pbnQgbGluayBhbmQgdGhlc2UgbGlua3Mgd291bGQgaGF2ZSBzYW1lIHByZWZpeC4gIChp LmUuIGlmDQo+IHRoZSBzcmMgaXMgMjAwMTpkYjg6MToxOjoxIHRoZW4gZHN0IHdvdWxkIGJlDQo+ IDIwMDE6ZGI4OjE6MTo6MiBhbmQgbm90IDIwMDE6ZGI4OjE6Mjo6MSkuDQo+IA0KPiBUaGlzIGlz IG9ubHkgc3VwcG9zaXRpb24gZnJvbSBteSBzaWRlLCBiZWNhdXNlIEkgaGF2ZSBuZXZlciBzZWVu IGEgcGFja2V0DQo+IGNhcHR1cmUgb2YgdGhpcy4NCj4gDQo+ID4gMy41LiAgUGFja2V0IEZvcm1h dA0KPiA+DQo+ID4gICAgRmlndXJlIDQgc2hvd3MgYSBwYWNrZXQgZm9ybWF0IGV4YW1wbGUgb2Yg R1RQLVUgb3ZlciBJUHY2IHRoYXQNCj4gPiAgICBjYXJyaWVzIGFuIGV4dGVuc2lvbiBoZWFkZXIg Zm9yIFFGSSBhbmQgYW4gSVB2NiBQRFUuICBBbGwgdmFsdWVzIGluDQo+ID4gICAgdGhlIGV4YW1w bGUgYXJlIGlsbHVzdHJhdGlvbiBwdXJwb3NlIG9ubHkuICBUaGUgZW5jb2Rpbmcgb2YgUERVDQo+ ID4gICAgU2Vzc2lvbiBDb250YWluZXIgZm9yIFFGSSByZWZlcnMgdG8gW1RTLjM4LjQxNS0zR1BQ XS4NCj4gPg0KPiA+ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMw0KPiA+ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ID4gICAgICBPdXRlciBJ UHY2IEhlYWRlcg0KPiA+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgIHxWZXJzaW9ufCAgICAgRFND UD1FRiAgIHwgICAgICAgICAgICAgICBGbG93IExhYmVsICAgICAgICAgICAgICB8DQo+ID4gICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiA+ICAgICAgfCAgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICB8IE54 dEhkcj0xNyhVRFApfCAgICBIb3AgTGltaXQgIHwNCj4gPiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCj4gPiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAg ICArICAgICAgICAgICAgICAgICAgIFNvdXJjZSBJUHY2IEFkZHJlc3MgICAgICAgICAgICAgICAg ICAgICAgICAgKw0KPiA+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDIwMDE6ZGI4OjE6 MTo6MSAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDQo+ID4gICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAg ICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKw0KPiA+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICsgICAgICAgICAgICAgIERl c3RpbmF0aW9uIElQdjYgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgICArDQo+ID4gICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgMjAwMTpkYjg6MToyOjoxICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCj4gPiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiANCj4gDQo+IEFsZXgNCj4gDQo+IExlIDEwLzA4LzIwMTggw6AgMTE6MjQs IFNodW5zdWtlIEhvbW1hIGEgw6ljcml0wqA6DQo+ID4gSGkgRE1NIGZvbGtzLA0KPiA+DQo+ID4g V2UgcmVmbGVjdGVkIGZlZWRiYWNrIGZyb20gM0dQUCBDVDQgb24NCj4gPiBkcmFmdC1obW0tZG1t LTVnLXVwbGFuZS1hbmFseXNpcyBhbmQgdXBsb2FkZWQgdGhlIG5ldyB2ZXJzaW9uLiBXZQ0KPiBu ZWVkDQo+ID4gbW9yZSByZXZpZXdzIGZyb20gYm90aCBJRVRGIGFuZCAzR1BQIGZvciBmdXJ0aGVy IGltcHJvdmVtZW50LiBXZSB3aWxsDQo+ID4gYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGdpdmUgY29t bWVudHMgb3IgZmVlZGJhY2sgdG8gdGhpcyBJLUQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ ID4NCj4gPiBTaHVuc3VrZQ0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2Fn ZSAtLS0tLS0tLQ0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4g PiBkcmFmdC1obW0tZG1tLTVnLXVwbGFuZS1hbmFseXNpcy0wMS50eHQNCj4gPiBEYXRlOiBGcmks IDEwIEF1ZyAyMDE4IDAxOjQ0OjIwIC0wNzAwDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnDQo+ID4gVG86wqAgZGFuaWVsLnZveWVyQGJlbGwuY2EgPGRhbmllbC52b3llckBiZWxs LmNhPiwgRGFuaWVsIFZveWVyDQo+ID4gPGRhbmllbC52b3llckBiZWxsLmNhPiwgVGFrdXlhIE1p eWFzYWthDQo+ID4gPHRhLW1peWFzYWthQGtkZGktcmVzZWFyY2guanA+LCBTYXRvcnUgTWF0c3Vz aGltYQ0KPiA+IDxzYXRvcnUubWF0c3VzaGltYUBnLnNvZnRiYW5rLmNvLmpwPiwgU2h1bnN1a2Ug SG9tbWENCj4gPiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4gPg0KPiA+DQo+ID4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAx LnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2h1bnN1a2UgSG9t bWEgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1l OsKgwqDCoMKgwqDCoMKgIGRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzDQo+ID4gUmV2 aXNpb246wqDCoMKgIDAxDQo+ID4gVGl0bGU6wqDCoMKgwqDCoMKgwqAgVXNlciBQbGFuZSBQcm90 b2NvbCBhbmQgQXJjaGl0ZWN0dXJhbCBBbmFseXNpcyBvbiAzR1BQDQo+ID4gNUcgU3lzdGVtIERv Y3VtZW50IGRhdGU6wqDCoMKgIDIwMTgtMDgtMTANCj4gPiBHcm91cDrCoMKgwqDCoMKgwqDCoCBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdlczrCoMKgwqDCoMKgwqDCoCAzMA0KPiA+IFVS TDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG1tLWRt bS01Zy11cGxhbmUtYW5hbHlzaXMtDQo+ID4gMDEudHh0DQo+ID4NCj4gPiBTdGF0dXM6DQo+ID4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG1tLWRtbS01Zy11cGxhbmUt YW5hbHlzaXMvDQo+ID4gSHRtbGl6ZWQ6DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAxDQo+ID4gSHRtbGl6ZWQ6DQo+ID4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1obW0tZG1tLTVnLXVw bGFuZS1hbmFseXNpcw0KPiA+IERpZmY6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAxDQo+ID4NCj4gPiBBYnN0 cmFjdDoNCj4gPiAgwqDCoCBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRoZSBtb2JpbGUgdXNlciBw bGFuZSBwcm90b2NvbCBhbmQgdGhlDQo+ID4gIMKgwqAgYXJjaGl0ZWN0dXJlIHNwZWNpZmllZCBp biAzR1BQIDVHIGRvY3VtZW50cy7CoCBUaGUgYW5hbHlzaXMgd29yayBpcw0KPiA+IHRvDQo+ID4g IMKgwqAgY2xhcmlmeSB0aG9zZSBzcGVjaWZpY2F0aW9ucywgZXh0cmFjdCBwcm90b2NvbCBhbmQg YXJjaGl0ZWN0dXJhbA0KPiA+ICDCoMKgIHJlcXVpcmVtZW50cyBhbmQgZGVyaXZlIGV2YWx1YXRp b24gYXNwZWN0cyBmb3IgdXNlciBwbGFuZQ0KPiA+IHByb3RvY29scw0KPiA+ICDCoMKgIG9uIElF VEYgc2lkZS7CoCBUaGlzIHdvcmsgaXMgY29ycmVzcG9uZGluZyB0byB0aGUgVXNlciBQbGFuZQ0K PiA+IFByb3RvY29sDQo+ID4gIMKgwqAgU3R1ZHkgd29yayBvbiAzR1BQIHNpZGUuDQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+IHRvb2xzLmlldGYub3Jn Lg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRtbSBtYWls aW5nIGxpc3QNCj4gPiBkbW1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K From nobody Fri Aug 24 05:30: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 28E51130E6C for ; Fri, 24 Aug 2018 05:30:22 -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 TzzZeuC7p7oU for ; Fri, 24 Aug 2018 05:30:18 -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 D9D05130E9B for ; Fri, 24 Aug 2018 05:30:17 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w7OCUGEI027171; Fri, 24 Aug 2018 21:30:16 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id D6B3FEA858C; Fri, 24 Aug 2018 21:30:16 +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 CBCE6EA7E05; Fri, 24 Aug 2018 21:30:16 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id B93A94003E3; Fri, 24 Aug 2018 21:30:16 +0900 (JST) References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> From: Shunsuke Homma Message-ID: Date: Fri, 24 Aug 2018 21:30:36 +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: Tom Herbert Cc: dmm X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 12:30:22 -0000 Hi Tom, Firstly, I'd like to apologize for my late reply because of summer vacation. We greatly appreciate your detailed review and feedback. We'll reflect your feedback on the I-D at the next update. Please find my replies to your comments in-line. (They are tagged with [SH]) By the way, please note that the purpose of this I-D is not denigrating GTP-U but introducing what is GTP-U protocol to IETF folks. Therefore, we consider that this document should describe just facts derived from 3GPP docs or general aspects. Best regards, Shunsuke On 2018/08/12 3:49, Tom Herbert wrote: > Hi Shunsuke, > > Thanks for the draft! It does a very good job of describing and > framing GTP-U using IETF terminology. This should help significantly > to bridge that gap of understanding between IETF and 3GPP. > > Some comments: > > General comment: Please look at "Encapsulation Considerations" > (https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02). There's a > lot of material there that might be relevant to encapsulation aspects > of GTP-U. > [SH] Thanks. We'll refer the document and update the content of GTP-U section if there are points should be added. > General comment: There are a number of recommendations that could be > extracted and made to improve GTP (in section 3 in particular). Does > it make sense to these in their own document as a recommendation to > 3GPP for a future update of GTP? [SH] It's out of scope, however 3GPP folks may be able to use this I-D to improve GTP. > > Section 1: > > "Another aspects of user plane requirements couldn't be found." - I'm > not sure what this means > [SH] It means the fact that the capture of TR 29 891 describes only "how to carry 5G specific QoS information between UPF and access networks", however, as you pointed out, it is not necessarily needed and we can remove it at the next update. > Section 3: > > "Allocation of UDP source port depends on sender tunnel endpoint node > and GTP-U supports dynamic allocation of UDP source port for load > balancing objective." - How is this done in practice. In most UDP > encapsulation protocols the UDP source is set to value from the hash > over a tuple of the encapsulated packet. This way, the outer packet > can ECMP router each encapsulated flow for load balancing. If this > were done in GTP-U this would probably mean that the source port is > not consistent for all packets sent on a tunnel. Would this be > consistent with 3GPP specifications? > [SH] As we described "however specific procedure, e.g., 5-tuple hashing, is not described in the document" in the draft, GTP-U spec described in TS29.281 just allows dynamic UDP src port allocation depend on network deployment and network node implementation. So it could also be consistent with the spec when the allocated src ports are inconsistent on a tunnel. > "GTP-U does not support IPv6 flow label for load balancing in case of > IPv6 transport." - does the spec say anything about flow label, does > it need to be set to zero otherwise? This should be an easy fix since > setting flow label isn't a wire protocol change and setting flow label > has already commonly implemented in other encapsulations. > [SH] It is not also defined specific procedure in TS29.281. > "UDP zero checksum is not available in case of IPv6 transport." - > Setting a UDPv6 zero checksum is a little tricky. RFC6935 and RFC6936 > need to be considered, but also the specifics and conditions of the > protocol an conditions of deployment. For instance, RFC8086 goes into > inordinate detail on requirements to set a zero UDPv6 checksum. > [SH] Thanks, it looks useful. > "GTP-U does not support to response ICMP PTB for Path MTU Discovery." > - I'm not sure what this means. Is this saying that if a GTP-U > endpoint receives an ICMP PTB error for a packet sent over tunnel, it > doesn't handle that; or is this saying that if a packet from a UE is > dropped at a GTP tunnel ingress point because of MTU exceeded then no > ICMP PTB is sent? If it's the first case, then that's not much a > problem. I doubt PMTU discovery has been implemented for many tunnels. > Usually one of the suggestions in RFC4459 is used (that RFC should be > referenced in the draft). If it's the second case, then that is more > of a bug in the protocol that should be fixed (this is IP layer > requirements, should not be specific to GTP-U). > [SH] Both of what you pointed out are possibly to occur. As Sridhar, 3GPP folk, described in the LS-OUT, 3GPP has assumption that MTU between RAN and the P-GW or UPF is discovered by offline means and the operator takes into account the MTU that is transferrable on the radio interface and based on this the operator configures the right MTU to be used. Therefore they don't consider there are any MTU issues. We'll add this supplemental description about why it would be a problem at the next update. > "Following list summarizes every extension header which is used for > user plane protocol." - Used or defined? It would be good to know > which, if any extension headers are commonly used in the data path. > This will also be input to the issued raised later on about the > efficiency of extension header processing. > [SH] It means defined extension headers. Of course, some extension headers are used in the real networks. > "DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel > endpoint node based on the QFI." - This should be rectified with > RFC2983. > [SH] What this observation means is that UPF remark DSCP value of outer IP header based on QFI of GTP extension header, and how to handle GTP-U packets with DSCP is out of scope. > "In general, multiple GTP-U extension headers are able to contained in > one GTP-U packet and the order of those extension headers is not > specified by [TS.29.281-3GPP]." - That is the combinatoric nature of > TLVs. There has been much discussion on that. A potentially related > question would be does GTP-U limit the number or size of extension > headers (unlimited TLVs in a packet could be used as a potential > denial of service attack. > [SH] Yes, you're correct. Meanwhile, the problem that we indicated here is ambiguity of 3GPP spec and effect on hardware performance caused by the ambiguity. Maybe, each vendor implementation would have its own specification about limit on the number, order, and capable types of extension headers. Nevertheless, do you think we should add the concern related to limit the number of extension headers? > "GTP-U does not support to indicate next protocol type." - A bit > unfortunate, IMO an encapsulation should also have a type field. > Conceptually, there is a way around this by defining the the first > nibble after GTP-U headers to be a type field (similar to GUEv1). 0x4 > and 0x6 are IPv4 and IPv6, which is convenient since this coincides > with the version number of an overlaid encapsulated IP packet. Other > values could be used for different types. > [SH] It's also good point. We'll add the aspect. > "GTP-U supports active OAM as a path management message "Echo > Request/Response"" - Does GTP-U support in-situ OAM? > [SH] No, it doesn't. GTP-U supports only keep-alive by using Echo Request/Response sent regular basis. > Header format "DSCP=0" in inner packet. Is this a requirement? > [SH] There are no definitions on inner IP packet. The figure describes "DSCP=0" as just an example. > There should be some discussion about how ECN is handled. RFC6040 > should probably be referenced. > [SH] Thanks. We'll consider how to mention ECN handling at the next update. > Section 4: > > "Then, the content information of the PDU may be mapped into UDP port > number" - I don't follow this. Does this mean that different > destination port numbers are used to determine the protocol of the > T-PDU? > [SH] Sorry, if this description is misleading. The section 9.2 of TS29.561 defines that IPv6 address and UDP port number for unstructured PDU type data is pre-configured at UPF, and the UPF associates GTP-U tunnels with N6 PtP tunnel based on the UDP port destination. Although we couldn't find concrete definitions about unstructured PDU type data, some variations of UDP port numbers might be needed if there are some types in unstructured PDU data. > "For this, the expected evaluation points from this aspect should be > whether there is substitutional means to cover other PDU session > types. And how much it makes simple the system than deploying > original PDU session types." - Is this another way of saying the > encapsulation protocols should have type field? :-) > [SH] Type field seems good point to simplify the system. We'll add the aspect as an example. > "However it increases header size from 20bytes to 40bytes compare to > IPv4." - That's also an overhead problem. In a bandwidth constrained > IoT network where average packet sizes might be as little at 100 > bytes, the overhead of two IPv6 headers, GTP-U header and extensions, > and an eight byte UDP header becomes significant to the extent that > overhead packet becomes majority portion of bytes. Techniques to > reduce the overhead could be warranted (ILA is one optimization that > does that). > [SH] As you described, overhead problem would be a point to evaluate candidate protocols. Although there seems to be no clear requirements for overhead of encapsulation in 3GPP 5G, we can add such aspect if it is general problem and useful for comparing candidate protocols. > Section 5 is good, but it would be nice to highlight whether or not > GTP-U can satisfy the evaluation aspects. Most of the problems of > GTP-U listed in section 3 are relatively minor and can be addressed > without significant protocol change (e.g. turning on flow label should > be trivial). The biggest feature touted by the candidate protocols > seems to be anchor-less mobility (might be a topic worth mentioning in > the draft). AFAICT, GTP-U is sufficiently generic and extensible so > that it could be used a the user plane of anchor-less mobility without > much change. Control plane would need major changes, but that is > probably similar to what needed in the control plane for other user > plane protocols to provide anchorless mobility. > [SH] Such highlight is a good idea, but 3GPP folks may not hope that IETF evaluates GTP-U that is 3GPP protocol. Please let us consider whether it can be added in this I-D. Also, as I described at the beginning of this email, the purpose of this I-D is clarifying and introducing GTP-U protocol and we assume that we don't need to provide shorts of GTP-U intentionally. > Tom > > On Fri, Aug 10, 2018 at 2:24 AM, Shunsuke Homma > wrote: >> Hi DMM folks, >> >> We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis and >> uploaded the new version. We need more reviews from both IETF and 3GPP for >> further improvement. We will appreciate if you can give comments or feedback >> to this I-D. >> >> Best regards, >> >> Shunsuke >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-hmm-dmm-5g-uplane-analysis-01.txt >> Date: Fri, 10 Aug 2018 01:44:20 -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-01.txt >> has been successfully submitted by Shunsuke Homma and posted to the >> IETF repository. >> >> Name: draft-hmm-dmm-5g-uplane-analysis >> Revision: 01 >> Title: User Plane Protocol and Architectural Analysis on 3GPP 5G >> System >> Document date: 2018-08-10 >> Group: Individual Submission >> Pages: 30 >> URL: >> https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.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-01 >> 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-01 >> >> 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 >> >> >> >> _______________________________________________ >> 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 Aug 24 05:35:36 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 9D089130E6C for ; Fri, 24 Aug 2018 05:35:33 -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 ePfWw7hfvp3y for ; Fri, 24 Aug 2018 05:35:31 -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 D2688130E2B for ; Fri, 24 Aug 2018 05:35:30 -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 w7OCZO24007553; Fri, 24 Aug 2018 21:35:24 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 794F4639606; Fri, 24 Aug 2018 21:35:24 +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 6DC9663928D; Fri, 24 Aug 2018 21:35:24 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 64DD44003E3; Fri, 24 Aug 2018 21:35:24 +0900 (JST) References: <153389066068.1543.4964118743607776580.idtracker@ietfa.amsl.com> <4bb86015-b18b-d899-079d-3b893b6bb9e6@lab.ntt.co.jp> <8076cb7d-3fd5-aa6d-bb3e-13f9c2be6e72@gmail.com> From: Shunsuke Homma Message-ID: Date: Fri, 24 Aug 2018 21:35:45 +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: Arashmid Akhavain , Alexandre Petrescu , "dmm@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 12:35:34 -0000 Hi Alex, Thank you for reviewing our I-D. Regarding GTP-U packet format described in the I-D, as Arashmid pointed out, all of the values are examples. (Thanks Arashmid!) If they are confusable, we can change such values to symbols (e.g., IP = xxx). Best regards, Shunsuke On 2018/08/20 23:58, Arashmid Akhavain wrote: > Alex, > I think you missed this disclaimer in > "All values in the example are illustration purpose only" > > Generally speaking, there is no guarantee for a point to point link. > > > Arashmid > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandre >> Petrescu >> Sent: 20 August 2018 06:48 >> To: dmm@ietf.org >> Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g- >> uplane-analysis-01.txt >> >> Hi, thanks for the draft. I am happy you wrote and published it. >> >> I am looking forward for a packet capture from a live cellular network that >> illustrates this outer packet header format described in the draft. >> >> In particular, the Source and Destination IPv6 addresses (not IPv4). >> >> I can suppose that the two addresses would have same prefix, because that >> would be a point-to-point link and these links would have same prefix. (i.e. if >> the src is 2001:db8:1:1::1 then dst would be >> 2001:db8:1:1::2 and not 2001:db8:1:2::1). >> >> This is only supposition from my side, because I have never seen a packet >> capture of this. >> >>> 3.5. Packet Format >>> >>> Figure 4 shows a packet format example of GTP-U over IPv6 that >>> carries an extension header for QFI and an IPv6 PDU. All values in >>> the example are illustration purpose only. The encoding of PDU >>> Session Container for QFI refers to [TS.38.415-3GPP]. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> Outer IPv6 Header >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Version| DSCP=EF | Flow Label | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Payload Length | NxtHdr=17(UDP)| Hop Limit | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + + >>> | | >>> + Source IPv6 Address + >>> | 2001:db8:1:1::1 | >>> + + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + + >>> | | >>> + Destination IPv6 Address + >>> | 2001:db8:1:2::1 | >>> + + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Alex >> >> Le 10/08/2018 à 11:24, Shunsuke Homma a écrit : >>> Hi DMM folks, >>> >>> We reflected feedback from 3GPP CT4 on >>> draft-hmm-dmm-5g-uplane-analysis and uploaded the new version. We >> need >>> more reviews from both IETF and 3GPP for further improvement. We will >>> appreciate if you can give comments or feedback to this I-D. >>> >>> Best regards, >>> >>> Shunsuke >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-hmm-dmm-5g-uplane-analysis-01.txt >>> Date: Fri, 10 Aug 2018 01:44:20 -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-01.txt >>> has been successfully submitted by Shunsuke Homma and posted to the >>> IETF repository. >>> >>> Name:        draft-hmm-dmm-5g-uplane-analysis >>> Revision:    01 >>> Title:        User Plane Protocol and Architectural Analysis on 3GPP >>> 5G System Document date:    2018-08-10 >>> Group:        Individual Submission >>> Pages:        30 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis- >>> 01.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-01 >>> 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-01 >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Aug 29 02:05:25 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 B72C91277C8; Wed, 29 Aug 2018 02:05:19 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <153553351969.14925.16880716264606857378@ietfa.amsl.com> Date: Wed, 29 Aug 2018 02:05:19 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-11.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 09:05:20 -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 : Distributed Mobility Anchoring Authors : H. Anthony Chan Xinpeng Wei Jong-Hyouk Lee Seil Jeon Carlos J. Bernardos Filename : draft-ietf-dmm-distributed-mobility-anchoring-11.txt Pages : 17 Date : 2018-08-29 Abstract: This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In the distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or re- started using a new IP address configured from the new IP prefix which is anchored to the new network. The mobility functions and their operations and parameters are general for different configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-11 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-distributed-mobility-anchoring-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobility-anchoring-11 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 Aug 29 02:10:17 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 83292129C6B for ; Wed, 29 Aug 2018 02:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 TYyTQqPsaaUX for ; Wed, 29 Aug 2018 02:10:12 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 A208F1277C8 for ; Wed, 29 Aug 2018 02:10:11 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id c14-v6so4503038wmb.4 for ; Wed, 29 Aug 2018 02:10:11 -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=gSyYns2t9/JMd0MT3lLChkXTMYXwFPIRlRF+zPGruXM=; b=1XENifDCKTp9O3WWuWzll6ppyhMSwelyhm7BLHPI0wi4dqmhc4FGDR7EYe7kTSvK9m ICRsVIOME/cFaredGfZAyxSlSx8bLF9nvDorc0t39oy+ytIVBUECpYMeuj2wXY6CVgUo GXPQF23Pou4y/GIImGTeGe+xp1Ficj6G/PsB7bhP49x20vL3LInrKoe/BRZ3Z5LSCBuR LuE1aVnFGAX0wpW2Z33ss4/tEcaYkWgpwRR0yzLzJsvWe8ky3Bi0oUUqeywTp+LpTffM VWY6YmB1rU0TGv2wlIufvDexvlgBMzXbuBDI/brfKB4a/vSnLYRohZ17j3BRehYuIwHy aNnw== 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=gSyYns2t9/JMd0MT3lLChkXTMYXwFPIRlRF+zPGruXM=; b=THn2iyysQ76kkrmpsBMTb6LwMWSwqid6Sf74Ni3z8xNsGWQMlQ9+jKAoPJiGHLkOv2 yVpVyYsLqKrsV62Gvm79YVGDbp+BERXMHeVOywrBkPLk7LtLLbruh7PqG6SvPKsXuzT4 qjyu0BNI0AuKvBvT2NI4z8a773FyRtamHAZVyWmIBxFSe5DAnuDGQ0uFZLG7St442ur+ Mw7u+3Xv10MP0vDqJp45o72tzK0EAV87yIltW4YgRzFL/1VTwYeFAI0uvyKlDhRGdeoe 7Pywa+n6MPyvnX04VQ3ENztuqB2LPTASXQptwNshGgLXbncmqao+a8ZqwBLttuj/D3wB SsZQ== X-Gm-Message-State: APzg51Dfm6zqWVJ91wVJx8l2ld8FYWJxB8qHCpoHCsRy+ygQBpRbw8v7 Sp7k+y8fOaC/5J7FHJcwyw2QbufudQY= X-Google-Smtp-Source: ANB0VdaDq66mHrgwsbHaHUV/CM+7Fn8keCmi8M5xh4IEE9AFn+BbHjaCOr9KERuJMwHLCqQBMmTdWQ== X-Received: by 2002:a1c:cf08:: with SMTP id f8-v6mr3804457wmg.27.1535533809845; Wed, 29 Aug 2018 02:10:09 -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 w3-v6sm2263679wrn.16.2018.08.29.02.10.08 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Aug 2018 02:10:08 -0700 (PDT) Message-ID: From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: dmm@ietf.org Date: Wed, 29 Aug 2018 11:10:07 +0200 In-Reply-To: <153553351969.14925.16880716264606857378@ietfa.amsl.com> References: <153553351969.14925.16880716264606857378@ietfa.amsl.com> 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] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-11.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 09:10:16 -0000 Hi, We've just posted a new version addressing comments received from a very good review from Lyle. We need more reviews! Any volunteer? It's a short document to read. Thanks! Carlos On Wed, 2018-08-29 at 02:05 -0700, internet-drafts@ietf.org wrote: > 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 : Distributed Mobility Anchoring > Authors : H. Anthony Chan > Xinpeng Wei > Jong-Hyouk Lee > Seil Jeon > Carlos J. Bernardos > Filename : draft-ietf-dmm-distributed-mobility- > anchoring-11.txt > Pages : 17 > Date : 2018-08-29 > > Abstract: > This document defines distributed mobility anchoring in terms of > the > different configurations and functions to provide IP mobility > support. A network may be configured with distributed mobility > anchoring functions for both network-based or host-based mobility > support according to the needs of mobility support. In the > distributed mobility anchoring environment, multiple anchors are > available for mid-session switching of an IP prefix anchor. To > start > a new flow or to handle a flow not requiring IP session continuity > as > a mobile node moves to a new network, the flow can be started or > re- > started using a new IP address configured from the new IP prefix > which is anchored to the new network. The mobility functions and > their operations and parameters are general for different > configurations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-distributed-mobility-anchoring-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobility-anchoring-11 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Aug 29 02:17:00 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 DA91C130DDB; Wed, 29 Aug 2018 02:16:58 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <153553421885.14627.6713252575591546209@ietfa.amsl.com> Date: Wed, 29 Aug 2018 02:16:58 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-pmipv6-dlif-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 09:16:59 -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-02.txt Pages : 32 Date : 2018-08-29 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-02 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 Aug 29 02:19:10 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 1FBBC130EFC for ; Wed, 29 Aug 2018 02:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 6ntZmzM-PC9J for ; Wed, 29 Aug 2018 02:18:56 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6F2130E44 for ; Wed, 29 Aug 2018 02:18:55 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id t25-v6so4730987wmi.3 for ; Wed, 29 Aug 2018 02:18:55 -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=i4u+pCEnnkauTBgza72nhpP8Ze2gzCN993MdGVWJrMg=; b=2M4f/NrTrcBrnjenbZmFka7xwUrVj8d69LmOonIZhPTtgVtUqfvlC5H4oCEgkqZdE/ aJEuZrEYK2ODsCuHulD4rSKSlV43/MCOO6KqVh4U2gsbt8l7xJspnVT8cJQn7fxjt/7U rI9QANXNSbA8qgxYLT6cwIAlMiiHjGfycmh5Iad7OrXYgNG9VMM2tRIcldKz+brbVzmu bX/uBILSPXabf+FKvh4+LlfKm1Db/ikfyP64/NdkC8F4BPm+G6WIH207JMHrgMWwWSzA Rex3KK5qGq0Txk14W33ti35mJDutoAOsHPQ25n9sFtBuj+FpoSpX+MllibD/CVwa7nmM sWxg== 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=i4u+pCEnnkauTBgza72nhpP8Ze2gzCN993MdGVWJrMg=; b=miusukYPV4Om/8La1p55ccrVKv53PXUXhGmVbRyndyeczdK+BMf4uufEtgFcDXEMbG 2JhmiRSWEZFPyZa4USugfklKUoGeBT1frezyWTYbUc9tyQzXqgUpFlV6uJJmizldDAz2 M0MDvJxpjJ/v77usAo3IMxRu5F5rYp1h7Bg9SuXxi283WF2vM42fppwzyWUjHx0ncT0S 0x7GSEMwlA0DkThaLk/Ad+4q1FZ0I9xTsPJANpR3Y32+zjdUVg3iLhkEZMpsz1pP8O64 Dez9+XN0DGKp1p+HqsoDLrQ6gQE4YobEnlXIxoyc/mDmZFSNEQXQFZW2zbXpuOuvvbhi gxVg== X-Gm-Message-State: APzg51CuWTbMwvwgIe4XfUrbBnI9YhzjLkJsV4kT+O74Qj5WUhCncvWS HjjCfWtykbh8/aqs/EW19vRG5bokhg8= X-Google-Smtp-Source: ANB0VdaZPW5SluQZFADeYjfBhN5F/7q1aeiL3PCnLr6eMzxi9kkC4r205JB4WAF+1y0en4cUUO1/yg== X-Received: by 2002:a1c:2283:: with SMTP id i125-v6mr3760468wmi.28.1535534333971; Wed, 29 Aug 2018 02:18:53 -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 f18-v6sm4071052wru.51.2018.08.29.02.18.52 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Aug 2018 02:18:53 -0700 (PDT) Message-ID: From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: dmm@ietf.org Date: Wed, 29 Aug 2018 11:18:52 +0200 In-Reply-To: <153553421885.14627.6713252575591546209@ietfa.amsl.com> References: <153553421885.14627.6713252575591546209@ietfa.amsl.com> 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] I-D Action: draft-ietf-dmm-pmipv6-dlif-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 09:19:10 -0000 Hi, We've just posted a new version addressing a very detailed review from Lyle (thanks!). Please, check and provide comments on the mailing list. Thanks, Carlos On Wed, 2018-08-29 at 02:16 -0700, internet-drafts@ietf.org wrote: > 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-02.txt > Pages : 32 > Date : 2018-08-29 > > 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-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-02 > > > 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/ > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Aug 30 15:27:21 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 A838E128CE4; Thu, 30 Aug 2018 15:27:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dmm-chairs@ietf.org, suresh@kaloom.com, dmm@ietf.org, sgundave@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153566803964.3258.1615360607096139927.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2018 15:27:19 -0700 Archived-At: Subject: [DMM] dmm - New Meeting Session Request for IETF 103 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.27 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 22:27:20 -0000 A new meeting session request has just been submitted by Sri Gundavelli, a Chair of the dmm working group. --------------------------------------------------------- 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 ---------------------------------------------------------