Re: [bcause] interest and scope?

["Wadhwa, Sanjay (Nokia - US/Mountain View)" <[e-mail]>]

Tim
 Of course, extending PFCP involves work. Your perception is a bit misplaced on existing PCFP capabilities though. PFCP supports steering. It allows CP to specify steering policy if UP signals support for steering in its capabilities. The steering can actually be controlled not only on per-session basis, but also per-flow or application basis.
PFCP has reliability mechanism built in that guarantees reliable delivery to the PFCP application on the peer (not just to the peer).

It seems pre-mature to discuss protocol details before scope and requirements.

-Sanjay

From: Yu Tianpeng <[e-mail]>
Sent: Friday, March 22, 2019 10:16 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[e-mail]>
Cc: Miaofuyou (Miao Fuyou) <[e-mail]>; [e-mail]
Subject: Re: [bcause] interest and scope?

Hi Sanjay,
I had a read on PFCP, I am glad that I find there are some points inside matching with my thoughts (e.g. the concept of PDR, PDI, FAR).
I wrote sth before reading PFCP (draft-cups-rtgwg-cu-separation-requirement), with some similar ideas inside (GSF).
But I also realize that there is pretty much work to do even we re-use the current PFCP. There are a couple of points:
1. Current PFCP lacks considerations of many scenarios: e.g. 3-play, service chaining (e.g. NAT, DPI, both intra-chassis and inter-chassis chaining), network programming (e.g. segment routing)
2. Current PFCP design philosophy is “OpenFlow” like which makes co-working with existing technologies listed above difficult
The challenge of CUPS protocol I believe is the service model between CP and UP. But what PFCP has done so far is a very basic model (basic IP forwarding with QoS parameters and some monitoring, there is no concept of service inside even), but many functions not needed in BNG CUPS.
I have concerns on if PFCP is the right way if we consider co-working with the technologies going on in IETF.
I also have a concern that PFCP chooses UDP as the transport protocol, which lacks of congestion control and different from control protocols we see usually. And in order to guarantee reliability, extra complexity has to be introduced to PFCP protocol itself and its application.
Glad to hear your options on these.
Thanks in advance.
Regards,
Tim

On Fri, 22 Mar 2019, 15:40 Wadhwa, Sanjay (Nokia - US/Mountain View), <[e-mail]<mailto:[e-mail]>> wrote:
Miao
 We have gone well beyond Wikipedia and analyzed  PFCP in detail. It has the right constructs to convey forwarding, traffic-management, and usage related state between CP and UP as required by a fully featured BNG for both fixed and fixed-wireless access. It is very extensible with the encodings defined for IEs and grouped IEs conveyed in PFCP objects. The natural order of addressing a problem space is to start with requirements and architecture, which is what we did with our drafts. That said, we have scoped the PFCP extensions for multiple functions in BNG, including dual-stack IPoE, PPPoE, L2TP LAC, H-QOS, LI, NAT. Lot of this is incremental.
We have a draft on applicability of PFCP to BNG that can terminate multiple access and transport encapsulations. It details relevant PFCP extensions and is waiting to be submitted. We are just following the right order. Requirements and architecture framework first, before bringing in protocol work that maps to the architecture and requirements.

-Sanjay


-----Original Message-----
From: bcause <[e-mail]<mailto:[e-mail]>> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Friday, March 22, 2019 2:34 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [bcause] 答复: interest and scope?

Hi Sanjay,

Wikipedia says: "PFCP's scope is similar to that of OpenFlow, however it was engineered to serve the particular use-case of Mobile Core Networks. PFCP lacks the same general-purpose targets, describing well the 3GPP-specific functional basic blocks of packet forwarding used in 2G, 3G, 4G/LTE, Non-3GPP WiFi and 5G networks."

https://en.wikipedia.org/wiki/PFCP

Even so, it doesn't mean PFCP could not to be extended or changed to do more. However, there have to be an thorough analysis to PFCP to figure out what extension or change is needed. Otherwise, it's only intention expression rather than facts statement, which is not helpful to progress the work.

- Miao

-----邮件原件-----
发件人: bcause [mailto:[e-mail]<mailto:[e-mail]>] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月21日 23:39
收件人: [e-mail]<mailto:[e-mail]>
主题: Re: [bcause] interest and scope?

Hi
>From most of the posts, it is quite clear convergence is an important consideration.
To be specific, with the right interfaces and functions on BNG, one can use current BNG deployed base to offer existing residential services over any of fixed-access, fixed-wireless (e.g. with LTE, LTE/CBRS, 5G NSA) or hybrid-access. Additionally, as mentioned in another post there is ongoing work for integrating fixed-access with 5GC via an adaptation function (AGF) to use a multi-access SMF/UPF.
Using a particular option at a given time may be a decision based on ROI, state of the network or other constraints. However, going from one access to another on BNGs or 5GC SMF/UPF should not require a new baseline CUPS protocol, but rather extensions to a common protocol. The extensions mainly confine to the state information carried by the protocol based on access-facing and network-facing interface encapsulations on the network-element. Network elements can include BNG, AGF, SGW/PGW, TDF, 5GC SMF/UPF. Some of the functions provided by these network elements may be combined or instantiated on the same platform.
Therefore, an access or use-case specific CUPS protocol is a dead-end. A common CUPS protocol that enables convergence will provide flexibility to evolve the network without worrying about yet another variable. Extending an existing standard protocol that is already purpose built for large scale state exchange is a sound way forward for BNG CUPS. With above in mind, we have considered PFCP applicability for BNG CUPS (irrespective of access) for some time now, including required PFCP IEs. Existing IETF drafts have covered BNG CUPS architecture and requirements that are addressed by PFCP.

Thanks
-Sanjay

--
bcause mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bcause
--
bcause mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bcause
--
bcause mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bcause