Yi Zhou, Liang, Peng, and Peter, We have 4 IETF drafts describing the different aspect of the solutions to 5G Edge computing, which can cover your use cases and requirement described in draft-geng-rtgwg-cfn-dyncast-ps-usecase:
Through working on the 3GPP Release 17’s 5G Edge Computing project (3GPP TR23.748), we noticed that IP Layer can do more to optimize the 5G Edge computing services. https://datatracker.ietf.org/doc/draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1yyVDIoM4pRjqoaLcFtGBohA3Our0GjTsZTI_OhhRqrwPug8uB8BZCGk2WVCYZmJMutbzptopfG2ACz4AxfZxeUgnDWbBu1hcHyGnNbsDXzkStp9bntK0rpjjQPBgg-1jY8eRWaAcB_V85O45nB_MzOBkHjs9r0q1sGjDHKPhx7WjEaZgiAzZ4IsIMfmKhXFfCy_LUF9yMT24QsWdp66L9H5a1h0hA_940C_gOSIQDClYCc_3NcAcy2w665SAxX4zkbf9KrUNoa2w1tIurssNadIg0Miqo-Q9jwqwCGrZhRa3Zf94d0HVx-aI4KJrBQi3%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-ippm-5g-edge-compute-ip-layer-metrics%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903951448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1oMRUMShQ8Q8fA9JDhv7pyDVLRPpKamyqLvNHMb51qU%3D&reserved=0> describes the IP Layer metrics and methods to measure the Edge Computing Servers running status and environment for IP networks to select the optimal Edge Computing server location in 5G Edge Computing (EC) environment. This document also describes the method of incorporating those measurements with IP routing cost to come up with a more optimal criteria in selecting ANYCAST locations. https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F10q2K1AolUwnJQxE-1zdp20SZ9dJ4nGbrfheOMCk6FhMP7cll-lnH4Ele1vAAkXjvGYaXHnAl_WGczRan0zDSIF25BUg7bs9aWtE1gnvQvPt8_qGMdw5gmM3jpAWOXC6_N_neane1LGU-tFdSie6E94aD3LmVxBQnkkB_qnp3glPLwHgMYiU3hGmAJ_yuBK1a2SBOFdr3VmeUxXESfiXy-k0CflGKYdeAnYHNoIGMvbqPWVpWhjEVqqxUpLISwkvVznxIeTcYl6IGePA_y9uGFwvnl_jqU3tClFSPvy1DDEp12JvdoAa6ygDA_rvVmbfW%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-6man-5g-edge-compute-sticky-service%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2cZoGaNIOEVm6twNUFp9aBP%2BYDbWnhEQrPYVVL8Alrg%3D&reserved=0> describes a solution of using IPv6 extension header to help Ingress router to stick traffic from a UE to the original App Server when the UE moves from one 5G Site to another. https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/ describes a new BGP Network Layer Reachability Information (BGP NLRI) Path Attribute, AppMetaData, that can distribute the 5G Edge Computing App running status and environment, so that other routers in the 5G Local Data Network can make intelligent decision on optimized forwarding of flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services. The extension enables a feature, called soft anchoring, which makes one Edge Computing Server at one specific location to be more preferred than others for the same application to receive packets from a specific source (UE). https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1pN4xFsbZmNhUqdhLGnTREMAj8uivXtc4wzAe5JqGqd4rZrJsKGRniQQp0KpmomwEWdnRGFimTXd3kCsWrCfJZK1_IK7-mzNZpLXCnmLbwhM011N3KS_V9ZTbJBsQCpIAz2Se2NJ7c77M8n1w1vTCMA3Mmv9L5yO4SlFI32zj70F_87C-scozGGga61PK-wDmL2JV_2BVvpfnK0YA0ez8WpbnSvQZQsks3bCUl7SQxG2IcuZI4PxNLhA2Y_22SSoaankWjg0sU58se1h4tDt7SrAao_ZcFqSTge-iZYmOyFN996wqXhPh5ZLzGa52Gh2j%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qb1rHSngDnQYOSDfVH5xyCRnZ9U2WoQ3knWGrUDNcm8%3D&reserved=0> describe OSPF extension for the Routers that collect the IP Layer Metrics to propagate to all other routers. Please let us know if the proposed solutions can solve your use cases. Thank you Linda Dunbar From: rtgwg <rtgwg-boun...@ietf.org<mailto:rtgwg-boun...@ietf.org>> On Behalf Of Liyizhou Sent: Monday, November 2, 2020 1:17 AM To: rt...@ietf.org<mailto:rt...@ietf.org> Cc: Lifeng (Frank) <frank.lif...@huawei.com<mailto:frank.lif...@huawei.com>>; Peng Liu <liupeng...@chinamobile.com<mailto:liupeng...@chinamobile.com>>; gengli...@chinamobile.com<mailto:gengli...@chinamobile.com> Subject: Dyncast (dynamic anycast) Hi folks, We submitted two drafts about dyncast (dynamic anycast). draft-geng-rtgwg-cfn-dyncast-ps-usecase<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-geng-rtgwg-cfn-dyncast-ps-usecase%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C868abea8ec7b458427ad08d87f5aa4e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637399374577973883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pkJ6LwZfAAZCHBJpDuRo1dZLFJM1pa2H83S5BZM75UQ%3D&reserved=0> draft-li-rtgwg-cfn-dyncast-architecture<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-rtgwg-cfn-dyncast-architecture%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C868abea8ec7b458427ad08d87f5aa4e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637399374577973883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FcVca03mICRivpgTP6%2FvUIqZnXs47iU%2BJ%2B6XZQUFgf4%3D&reserved=0> Edge computing puts the potential requirements on better load balancing among the computing resources hosted on different edges. The number of such edges could be thousand or even more depending on where the computing resources are located. The expected approach is to consider both network status and computing resources at the same time to determine the best place to forward a new computing demand to. Current solution usually uses DNS-like approach, select the service instance first (the lowest load or roughly the geographically closest instance) and then direct the demand to it regardless how good or bad the network path reaching it. Anycast based service addressing methodology could be used here to reach the best edge in terms of both computation resource and network status at the same time. Flow affinity and computing aware routing needs to be enhanced in such an anycast architecture. It is called dynamic anycast in the drafts. If you have any comments or suggestions, please drop us an email. Appreciated. Regards, Yizhou
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
