Re: [bcause] PFCP not equal to FMC, Why not choose PFCP

David Sinicrope <david.sinicrope@ericsson.com> Fri, 29 March 2019 16:22 UTC

Return-Path: <david.sinicrope@ericsson.com>
X-Original-To: bcause@ietfa.amsl.com
Delivered-To: bcause@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0066B12004C for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 09:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_06=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 (1024-bit key) header.d=ericsson.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 1z_bve8eOVX3 for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 09:22:16 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DE4120048 for <bcause@ietf.org>; Fri, 29 Mar 2019 09:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NSDJiZYNhJZ3hHJYwfDViWoZOe41JxtzWm3MLqMPx4c=; b=F5RbTitGEOw1t9TVtA0PU/6Zjtejm3SHrxu270o4mrpc4X/Bu7LmfqxvJ8bm64WR2VfJsWXbB36h5AwRa7xr6wDt71dmqRPKgvXCyMrI2IVu+u0zMoUf89DZe3ejk6fBIRG7aBO3vGBLr0jUMfkW9UMt8L0G7zvguhiKNKS3l5Q=
Received: from BN8PR15MB3154.namprd15.prod.outlook.com (20.179.72.89) by BN8PR15MB3299.namprd15.prod.outlook.com (20.179.74.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Fri, 29 Mar 2019 16:22:11 +0000
Received: from BN8PR15MB3154.namprd15.prod.outlook.com ([fe80::b427:8bf6:3c7b:e1d2]) by BN8PR15MB3154.namprd15.prod.outlook.com ([fe80::b427:8bf6:3c7b:e1d2%7]) with mapi id 15.20.1730.019; Fri, 29 Mar 2019 16:22:11 +0000
From: David Sinicrope <david.sinicrope@ericsson.com>
To: "Songjun (Network)" <song.jun@huawei.com>
CC: "bcause@ietf.org" <bcause@ietf.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>
Thread-Topic: [bcause] PFCP not equal to FMC, Why not choose PFCP
Thread-Index: AQHU5kuPpFcnZgJiLUiKMX5lum8A/w==
Date: Fri, 29 Mar 2019 16:22:10 +0000
Message-ID: <D88B9809-9082-4C64-B4B0-30CF99647B80@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.sinicrope@ericsson.com;
x-originating-ip: [62.168.35.68]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 688b1f92-9c2e-4cad-34e6-08d6b462b268
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN8PR15MB3299;
x-ms-traffictypediagnostic: BN8PR15MB3299:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BN8PR15MB32998D3C00732BC2CF182EFF8F5A0@BN8PR15MB3299.namprd15.prod.outlook.com>
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(189003)(199004)(102836004)(58126008)(54556002)(6246003)(54906003)(478600001)(53936002)(6916009)(2906002)(186003)(4326008)(14454004)(36756003)(86362001)(25786009)(26005)(5660300002)(256004)(44832011)(14444005)(81156014)(2616005)(81166006)(8676002)(486006)(68736007)(8936002)(476003)(97736004)(82746002)(83716004)(105586002)(71190400001)(71200400001)(7736002)(66066001)(3846002)(6116002)(790700001)(106356001)(316002)(33656002)(6506007)(53546011)(99286004)(229853002)(733005)(6486002)(99936001)(6436002)(6306002)(6512007)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB3299; H:BN8PR15MB3154.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nvqNDGu5cBlv50/zy5Ji1D28BCO4Qx5JfmEbe4AIs1dWcTqL6+0pQNqWp075lFuR2M6mbc2Xw5xV6rJdADSxJ0s8TevFh4k/AhO6UN/9UvBmHBC2vHK40nTxtMX/KqMfh9V5D4tZ95lAp9fU5wP/8W29SXt95EwjJ/0tDtU34fU1hIiMpwy/N7QyQn0RFo0l32/NBtk3gG2HvQWj/v35oLYFBGzdJLHoB4F217Dq9FfYOHnwQ4mP8ujoPjXWhpAKpDWcqnfwV9yE9c+vgyF2hGEhAINs7ps6jO3NVqeRedkJsNpp0/eHRlfWlWHPaH1aLNjPwkiiGIKtoX4R1vAJ2TlecOfkr2xt8U4+dI1C2TRfvKszy6b7KubT0jYV3mIdStAc5vaw8TjoKpx6CP0VRnQr3EYQ/BO618MRSk1Xdj8=
Content-Type: multipart/related; boundary="_008_D88B980990824C64B4B030CF99647B80ericssoncom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 688b1f92-9c2e-4cad-34e6-08d6b462b268
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 16:22:11.0020 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB3299
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/LiaHGDWocjev58fB_IbUGL5bIAw>
Subject: Re: [bcause] PFCP not equal to FMC, Why not choose PFCP
X-BeenThere: bcause@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <bcause.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bcause>, <mailto:bcause-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bcause/>
List-Post: <mailto:bcause@ietf.org>
List-Help: <mailto:bcause-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bcause>, <mailto:bcause-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 16:22:20 -0000

(IETF Liaison Manager to the BBF hat on)

As I emphasized in the presentation during the BoF, the Broadband Forum is a membership organization. As such,  BBF contributions and work in progress are restricted to members except where the material is liaised (via BBF process) to other organizations.  The BBF contribution material and meeting proceedings information in the email below has not been liaised by BBF to IETF.  Any statements concerning the BBF meetings, contributions, work in progress, etc. do not represent statements from the BBF unless conveyed in a liaison from the BBF or via authorized BBF liaison representatives.

Please, when discussing the BBF and its work, those who are affiliated with BBF member companies should be mindful of the information they distribute, respecting and adhering to their BBF membership agreement that has granted them access to the BBF information.   Each organization works according to its own rules, agreements, processes and procedures – please respect this.

Thank-you,
Dave


[cid:image001.png@01D4E653.EF787530]

From: bcause <bcause-bounces@ietf.org> on behalf of "Songjun (Network)" <song.jun@huawei.com>
Date: Friday, March 29, 2019 at 2:24 PM
To: "bcause@ietf.org" <bcause@ietf.org>
Subject: [bcause] PFCP not equal to FMC, Why not choose PFCP



1.       PFCP is not important for FMC

[cid:image002.png@01D4E675.B2309F00]

Mobile core is keeping evolution. PFCP must follow on it.



The CUPS interfaces are different between mobile core and BNG.

[cid:image004.png@01D4E675.B2309F00]

vBNG-UP and vEPC-UP will run in VM or Container independently. We can do FMC now basing on large-scale deployed protocols (PFCP and S-CUSP), and keep smooth evolution following the development of mobile network and fixed network.

[cid:image006.png@01D4E675.B2309F00]

We can guarantee there is PFCP in 6G and 7G. The latest information from 3GPP, they are discussing to change the mechanism between UPF and SMF.

Using PFCP is not equal to implement FMC.



2.       Why not choose PFCP
Why 3GPP not reuse Openflow?

ü  PFCP use the openflow mechanism, openflow was a mature protocol then.

ü  3GPP has its own requirements, using UDP for high throughput.

ü  Defining mobile standard in ONF makes no sense.
Why we did not choose PFCP?

ü  In 2016, we studied Openflow and PFCP, and discussed with PFCP editor (Peter from Huawei).

ü  We found that nearly all requirements of BNG were needed to extended in current protocol. That seems to rewrite a new protocol.

ü  Reusing Openflow and PFCP, the CUSP will be heavily affected by ONF and 3GPP. Discussing BNG in ONF and 3GPP makes no sense.

ü  We decided to define a new protocol with good points from Openflow and PFCP in IETF for BNG.

ü  Mobile core can not use PFCP for interworking with different vendors now in technical reason.

ü  When talking about using PFCP, let me recall the story of T-MPLS(MPLS-TP).  IETF asked ITU-T to stop using MPLS or standardize T-MPLS in IETF.  ITU-T lost the control of T-MPLS, and the standard process was delayed.


3.       DBNG story in BBF

ü  I attended last two BBF meetings.  I found that they want to put everything into MS-BNG, as the following picture. According to Nokia’s IETF Draft, EPC and 5GC will also be input into it.

ü  If just put all function together without any changes of outside interfaces and protocols, it is an implementation issues, not a standard issues. We can do it now because we have all related products.

ü  If needing converging functions and changing protocols, someone said that the work could be finished in 5 month.  I do not believe that it can be finished based on running code instead of paperwork.

ü  There are about 20 people attend ATA meeting, with more than 1/3 from Huawei and ZTE.


[cid:image008.png@01D4E675.B2309F00]
BTW, this picture was rejected in BBF. It is not easy to draw a clear picture including all functions, even to me.


4.       Suggest IETF  start CUPS protocols for BNG

ü  CU separation is an internal mechanism, unaware to outside, without adding new functions and changing current protocols. TR-384 shows how to separate the functions into CP and UP, it is enough to start the protocols design, basing on running code and scale deployment.

ü  Most BNG in current and in near future, will be used for fixed network users. Requirements on fixed BNG is clear and urgent. How to do FMC is still in discussion, with multiple ways to support it.

ü  S-CUSP’s running code is 1/10 of PFCP, because of the different service requirement. CUSP for BNG is a very lightweight protocol, because fixed user does not migrate, always on line, very simple billing. BNG-UP can still forwarding, without BNG-CP. Mobile core reverses. Of cause, we can absorb the good points of Openflow and PFCP.

ü  IETF is the right place to define a protocol for BNG, 3GPP is the right place to extend PFCP.

ü  If using PFCP and including unclear FMC functions, we will mesh 3 SDOs together, many device functions(BNG,AC,TWAF,HAG,EPC,5GC) together. When can we meet the real IP network requirements?





5.       How to deal with FWA requirements, such as HAG?

ü  HAG can be deployed independently or with BNG. CUPS HAG can be added in WT378, with its owner CUSP..

ü  Venders can provide independent HAG or integrated HAG with BNG according Carrier’s requirements.

ü  Optimization on integrated HAG is a kind of vendor’s implementation, not standard issues.

ü  CUSP for HAG can be defined according to HAG requirements, with smooth independent evolution.


Simple and Flexible are the keys for success of IP network, when you think about Ethernet/IP against ATM.