IP网络未来演进技术白皮书 4.0

IP网络未来演进技术白皮书4.0_服务感知网络（SAN） 第1页 IP网络未来演进技术白皮书4.0 ——服务感知网络（SAN） 中兴通讯股份有限公司 IP网络未来演进技术白皮书4.0——服务感知网络(SAN) 版本 日期 作者 备注 V1.0 2021/05/22 ZTE 新建 V2.0 2022/08/28 ZTE 更新：提出开放服务互联网络解决方案和三大关键技术：服务感知网络（SAN）、增强确定性网络（EDN）、网络内生安全 V3.0 2023/08/22 ZTE 更新：提出增强确定性网络（EDN）架构及其关键技术 V4.0 2024/09/27 ZTE 更新：提出服务感知网络（SAN）架构及其关键技术 中国信息通信研究院中国电信研究院 中国联通研究院北京交通大学 ©2024ZTECorporation.Allrightsreserved. 2024版权所有中兴通讯股份有限公司保留所有权利版权声明： 本文档著作权由中兴通讯股份有限公司享有。文中涉及中兴通讯股份有限公司的专有信息，未经中兴通讯股份有限公司书面许可，任何单位和个人不得使用和泄漏该文档以及该文档包含的任何图片、表格、数据及其他信息。 目录 1前言1 2IP网络未来演进趋势1 3SAN关键场景及需求2 3.1算网融合2 3.1.1算网融合下的广域服务部署与协同场景2 3.1.2算网融合下广域服务协同的需求与挑战8 3.2算网一体调度和运维9 3.2.1OTT和智能边缘服务调度主要问题和痛点9 3.2.2算网一体调度和运维场景和需求10 3.2.3算网一体调度和运维主要挑战11 3.3网络能力和业务需求协同13 3.3.1未来IP网络中业务和网络协同13 3.3.2业网协同应用场景16 3.3.3业网协同功能的设计需求17 3.4智算网络端网协同19 3.4.1网络多路径控制问题及需求19 3.4.2拥塞控制问题及需求20 4SAN整体架构及设计理念21 4.1算网一体流量工程21 4.1.1算网一体TE三要素22 4.1.2算网一体TE转控分离技术架构23 4.1.3算网一体TE部署和应用演进24 4.2SAN核心设计理念25 4.2.1独立语义服务标识26 4.2.2位置和归属无关28 4.2.3端到端服务29 4.2.4数据面轻量化29 4.2.5控制面极简化30 4.3SAN参考架构31 4.4SAN与现有技术的GAP分析32 4.4.1基于DNS和GSLB（全局负载均衡）服务调度模式32 4.4.2基于ICN的服务调度33 5SAN关键技术34 5.1HFC（HybridFunctionChain）混合功能链34 5.1.1HFC技术特征与内涵34 5.1.2HFC系统架构35 5.1.3基于SRv6的HFC技术36 5.2FSP(FlexibleSchedulingPolicy)灵活调度策略36 5.2.1支持多种约束条件的TE计算36 5.2.2业务调度和负载均衡技术37 5.3FS-OAM(Full-StackOAM)全栈算网OAM39 5.3.1网络和计算可观测现状39 5.3.2FS-OAM关键目标和技术39 5.4端到端网络业务协同服务系统43 5.4.1基于SAN的增强型业务控制层43 5.4.2业网协同功能层的接口需求44 5.5基于统一标识的智算端网协同45 5.5.1基于统一标识的智算端网协同架构45 5.5.2基于统一标识的多路径控制46 5.5.3基于统一标识的拥塞控制参数适配46 6SAN样机及测试总结47 6.1SAN算力路由样机试点47 6.2SAN服务治理测试验证50 7技术及产业展望54 8参考文献56 图 图1异构服务集群的互联4 图2多边缘多实例的服务路由6 图3处在不同请求与调用链路的服务实例7 图4算力网络TE和运维示意图11 图5传统互联网基于“尽力而为”的无差别传输服务13 图6overlay应用层和专线提供差异化内容交付服务14 图7业网协同功能协同模式为应用层提供匹配业务特征和传输需求的差异化网络服务15图8算网TE计算模型21 图9网络流量工程和算网流量工程22 图10集中式算力采集+分布式/集中式计算架构24 图11分布式算力采集+分布式/集中式计算架构24 图12服务感知网络关键设计理念26 图13服务感知网络参考架构32 图14DNS+GSLB的算力服务调度33 图15混合功能链（HFC，HybridFunctionChain）架构35 图16算网OAM需求和目标40 图17融合SAN的业网协同层的功能框架43 图18业网协同功能层和SAN网络的系统工作模式44 图19基于统一标识的智算端网协同总体架构46 图20SAN样机实践历程47 图21SAN2.0样机试点组网和目标49 中兴通讯版权所有未经许可不得扩散 图22集成SAN的服务互联测试方案52 图23Istio的Ambient模式服务互联测试方案52 图24Istio的Sidecar模式服务互联测试方案53 图25不同方案服务完成时延分布53 图26不同方案平均服务完成时延54 1前言 云计算、大数据、AI训练等新型业务驱动下，算网融合成为新型数字基础设施的典型场景和核心需求。算网融合在资源协同调度效率、业务性能优化等方面的需求和收益，近年来已经成为行业初步共识。随着云原生、AI训练等新型业务的飞速发展，对基础网络增量需求的内涵和外延，均出现了全新的变化。本文延续此前系列白皮书，聚焦算网融合场景的技术和架构演进视角，并就数据中心内及数据中心间东西向业务流量场景进行延伸覆盖，同时扩展了算网层次化性能检测、业网协同、独立语义服务标识等方向的架构和方案阐述。从服务感知网络整体架构视角来看，本文将继承基于服务标识索引的算力路由和精细化网络连接这两大基础功能。其中，服务标识的独立语义将会得到强化表述，即基于服务标识构建覆盖多场景的统一技术架构。服务标识是算力与网络、业务与网络、端侧与网络融合的关键功能单元和架构接口。 2IP网络未来演进趋势 从分组网络的业务承载类型来看，纯话音业务模式下，业务和网络一体化融合，网络内生支撑话音业务，业务得到确定性保障，业务就是网络，网络就是业务。互联网数据业务模式下，业务和网络在架构和协议层面分离，多种业务流量在承载网络之上混合共存，网络不再感知和识别业务，而是对所有业务流量进行基于统计复用的“尽力而为”转发，网络成为纯粹中立的承载基础设施，这种简明清晰的架构和部署模式，凭借其优异的可扩展性和成本优势，助推了互联网业务的爆发式增长。云计算的兴起和广泛部署，改变了业务数据的流量模型和算网交互模式，并对网络提出了延伸感知算力和业务的新型需求。网络、算力和业务从彼此独立割裂到适度融合以因应新型应用场景，遂成为新型数字基础设施模式下的演进趋 势。 尽管过去20年以来，业界涌现出多种试图替代IP网络的技术架构（如NDN/ICN等），但由于牵涉海量的网络基础设施存量投资，颠覆性替代方案很难被广泛接受并部署。更重要的是，IP网络架构并非封闭和一成不变，IPv6提供了丰富的扩展机制，支持平滑演进的功能增强，SRv6、BIER（新型组播）等即为经典案例。同时，IETF也已经正式启动MPLS2.0 （又称MNA）的标准推进工作，基于MPLS的扩展和增强也将成为现实可能。因此，基于轻量级数据面和智能控制面的功能增强和扩展，将是IP网络技术平滑演进的主流趋势。 本白皮书在《IP网络未来演进技术白皮书2.0》提出的开放服务互联网络及其关键技术的基础上，详细阐述服务感知网络（SAN）的场景需求、架构理念、关键技术、测试验证、技术及产业展望等内容。 3SAN关键场景及需求 3.1算网融合 3.1.1算网融合下的广域服务部署与协同场景 当前，构成互联网的两大基础设施——IT基础设施和CT基础设施都在经历重大的融合演进变化，即“云化”和“网络化”。“云化”是指包括应用、网络和云设施等都在虚拟化，通过虚拟化实现应用、云和网共享基础资源池，如计算、存储、转发等，实现一体化编排和调度。而“网络化”可以理解为去中心化、分布式计算、边缘计算等。网络化主要是应对广泛部署的无线网络和IoT设施，原来基于集中式架构的云化模型无法满足泛在的应用需求和分布式的云资源部署，从而向由网络连接的分布式算力和存储等虚拟化云资源提供模式演进。 一方面，云原生作为一种面向云计算时代的软件架构和开发理念，旨在充分利用云服务的弹性、可伸缩性和高可用性，为应对云计算环境下的复杂性和需求提供全新的解决方案和开发范式，其自身具备丰富、鲜明和独特的特性，如容器化，微服务架构，自动化部署与调度，弹性资源伸缩，故障隔离及高可用性，服务网格等。 随着云原生应用开发和运维模式的成熟，未来上云的应用将可以分解为更细颗粒度的原子服务，通过调用分布式的原子服务，或者原子服务的组合，从而可以支持更复杂的应用场景，如元宇宙等。因此，以原子服务为颗粒度的服务和感知技术，将能够在精确服务能力和分布式资源调度方面满足未来云原生应用发展的需要。另一方面，边缘计算作为一种分布式计算范式，其核心思想是将计算、存储和应用程序的处理能力尽可能靠近数据源和最终用户，以降低延迟、提高响应速度和数据安全性。其特征与优势包括分布式部署，低时延，高资源利用率，带宽成本优势等。应用的原子化解构与基于广域的服务与算力部署、连接和协同，共同组成了新时代下的算网融合新场景。 3.1.1.1广域跨边缘的服务连接场景 子场景1：跨集群服务连接的边车与代理拦截 以Istio为例，其作为一种服务网格架构，使用Envoy代理服务网格中的所有服务协调入站和出站流量。Istio使用Envoy的各种特性，如动态服务发现、负载均衡、TLS终止、HTTP/2和gRPC远程过程调用（gRPC）代理、熔断、健康检查、分阶段推出基于百分比的流量划分等。当存在流量流入或从应用和服务容器流出时，流量总是会被边车和代理拦截，进而由边车和代理根据控制面管理的路由和路由规则引导流量。 可以预料到，当部署在多个边缘云和集群中的服务需要连接和通信时，服务的拦截和引导将会变得更加复杂。数次的边车与代理拦截也将使得服务的连接能力下降。 子场景2：异构集群的部署与广域协同 当处在不同连接域的资源和服务之间存在连接和协同的需要时，如图1所示，数个K8S集群中和另一个虚机集群中部署的服务存在连接需要，如何适应性地管理多种连接域的资源和服务实例成为了亟待解决的问题，其中包括但不限于：数个集群中的部分实例存在连接需要，但另一部分实例不被允许通信时，如何能够更高效地为每个集群配置规则；当处在K8S连接域的服务实例希望访问处在一个虚机集群中的实例中，如何统一服务语义。 图1异构服务集群的互联 3.1.1.2广域多边缘的服务调度场景 子场景1：管理大量、动态的远端服务实例 在云原生的背景下，应用程序往往通过名称（例如ServiceIP）对服务进行寻址，来避免直接通过IP地址对服务进行寻址的脆弱性。以集群1访问集群2中的服务为例，需要在集群1中配置集群2中的服务名以及其所对应的的endpoints中，如集群2的IngressGateway地址。即，该将集群1访问该服务名的流量路由到集群2的IngressGateway。 而Serverless技术是一种云计算服务模型，其核心理念是开发者无需关心服务器的管理和维护，可以专注于编写和部署代码。其中，云服务提供商会根据负载自动扩展和收缩函数实例，以满足当前的服务请求量，而开发者则无需手动干预。当请求进入FaaS平台后，请求处理模块会在实例管理模块中查询是否有可用（空闲）状态的实例，如有空闲实例，则将对应的请求调度到该实例中，相应的加载和运行业务代码，并返回结果。当业务请求激增时，资源池中无可用实例，则去资源调度模块中申请扩容，资源调度模块相应创建新的实例加入资源池。 因此，在算网融合的背景下，网络连接的多边缘系统中可能存在着大量的、动态唤起或释放的远端服务实例。由于本集群访问远端集