本发明专利技术公开了一种操作、管理和维护OAM报文处理方法及装置，其中，该方法包括：源端业务节点确定用于在业务功能链SFC上发送的OAM报文，其中，OAM报文包括：载荷Payload、OAM报文头、业务功能报文头，其中，OAM报文采用预定的SFC OAM网络端口号承载；源端业务节点将承载在预定的SFC OAM网络端口号上的OAM报文发送给SFC上的目的业务节点处理，通过本发明专利技术，解决了相关技术中存在无法确定SFC OAM报文内容，以及基于什么协议承载该报文的问题，进而达到了确定了一种完整SFC OAM报文，以及提高SFC OAM扩展性的效果。
【技术实现步骤摘要】
本专利技术涉及通信领域，具体而言，涉及一种操作、管理和维护(Operat1nAdministrat1n and Maintenance,简称为0AM)报文处理方法及装置。
技术介绍
自从数据中心网络向Overlay网络发展以后，网络边缘成为了虚拟网络与物理网络的分界点，其中，网络边缘可以为Server或者ToR,以及可能为Gateway。然而Overlay技术并没有解决所有问题，数据中心中还有很多Middleware，如防火墙/负载均衡器等，这些设备都是基于用户业务来处理数据的，如果通过隧道而穿越这些设备，显然是不行的。数据中心的这种部署模型，要求虚拟防火墙/负载均衡器可以在网络中任意部署，也就是与网络拓扑无关。这样新问题是，如何将流量能够灵活的通过虚拟防火墙/负载均衡器进行处理？这些虚拟防火墙/负载均衡器等业务处理功能，独立于原网络拓扑，由标准服务器来实现。在相关技术中，把虚拟防火墙/负载均衡器/网关等业务处理功能，称为业务功能(Service Funct1n,简称为SF),而流量经过一系列的SF的处理，形成业务功能链(Service Funct1n Chaining,简称为SFC)。业务功能链是一系列抽象的业务功能的有序排列，具体业务流量转发时到底经过的哪些SFFs和/或哪些SFs的有序组合，SFC是不定义的。图1是相关技术中SFC的示例图，如图1所示，实线与虚线表示两条SFC，有时也叫业务链Service Chain。下面对SFC的框架进行说明。该SFC可以分为如下组件:1.业务叠加(Service Overlay),即各个业务功能节点需要通信的Overlay (叠加)技术；2.通用业务控制平面(Generic Service Control Plane,简称为 GSCP),形成 SFC的控制器；3.业务分类器(Service Classif ier,简称为SC),即需要进行者流识别，然后特定的流，进行特定的SFC处理；4、业务功能(Service Funct1n,简称为SF),对数据报文进行业务处理的组件；5.业务功能转发器(Service Funct1n Forwarder,简称为SFF),负责同一业务节点的内部多个SFs之间的转发。Overlay的数据报文经过业务节点的网络转发器NF封装、解封装外层overlay层后，主要在SFF组件上进行封装、解封装、更新业务功能报文头(Network Service Header,简称为NSH)。图2是相关技术中业务功能报文头的报文格式示意图，如图2所示；6.网络转发器(Network Forwarder,简称为NF),负责同一业务节点的内部多个SFFs之间的转发；以及对Overlay的数据报文进行封装、解封装Overlay层；同时，处理不同业务节点之间的转发；7.业务功能路径(Service Funct1n Path,简称为SFP),图3是相关技术中业务功能路径的示意图，如图3所示，SFP是从分类器开始，经过若干有序的具体的业务功能实例，达到目的地的一条业务处理路径。在某些情况下，通用业务控制平台GSCP并不能知晓沿途经过的所有业务功能实例，比如负荷分担场景或者业务服务等级场景等，此时，位于抽象的业务功能链SFC和真实具体的流量转发经过的有序业务实例构成的路径之间的这种业务功能链的描述，也称之为业务功能路径。一条业务功能链可能包括多个业务功能路径，不同的业务功能路径对应于不同的策略。8.控制平面元数据(Dataplane Metadata),这是一大特点，元数据(Metadata)允许各个业务功能节点，能够互相交换信息，达到某种业务处理目的。综上所述，SFC能够将网络设备业务功能和转发分离开来，从而实现了业务功能的独立运算和处理，提升网络设备的转发性能。OAM技术是针对网络连通性检测、故障定位、排查的网络传输技术，以及出现故障的时候，能够提供保护倒换的触发机制。它包含了链路连通性检测(ConnectivityVerificat1n,简称为CV)机制、Ping机制以及Trace机制。对于不同的承载网协议,均有相应的OAM机制。例如，以太网有以太OAM协议，IP网络有IP OAM协议，MPLS网络有MPLSOAM0其中，IP OAM中的IP Ping和IP Traceroute机制是基于ICMP协议的。其中，IP Ping通过扩展ICMP协议的type的字段实现请求request和应答reply消息；IPTraceroute 通过修改 IP Ping request 消息中的 TTL 值实现 Traceroute 的请求 request报文，通过TTL超期的ICMP差错报文实现Traceroute的应答reply报文；但是通过ICMP承载存在两大问题:1.涉及两种IP层的协议，分别是ICMPv4和ICMPv6，当扩展SFC OAM时，从两个协议层面都去扩展显得略微繁琐；2.1CMP报文不方便用于扩展来携带Trace响应信肩、O另夕卜，MPLS OAM的LSP Ping和LSP Trace机制是基于UDP协议的，使用目的端口号3503。因为需要考虑到对不同类型的LSP(比如，IPv4 LDP LSP、IPv6LDP LSP、IPv4 RSVPLSP、IPv6 RSVP LSP、Pff LSP 等)进行不同的 LSP Ping 和 LSP Trace，为了方便扩展，LSPPing和LSP Trace没有使用基于ICMP机制的Ping和Traceroute扩展，而是基于UDP协议进行扩展。图4是相关技术中SFC OAM技术框架示意图,如图4所示，SFC OAM的技术框架主要用于诊断业务功能链或者业务功能之间的链路状况。其中的一种实现方式如图5所示，图5是相关技术中SFC OAM报文格式一的示意图，如图5所示，在业务功能报文头NSH中预留一个字段，用于标识是OAM报文以及OAM报文类型；另一种实现方式如图6所示，图6是相关技术中SFC OAM报文格式二的示意图，如图6所示，在业务功能报文头NSH中预留I个BH，用于标识是OAM报文，至于是哪种类型的OAM报文，放在业务功能报文头NSH以外的报文中。但是无论哪种方案，都没有涉及到具体的SFC OAM报文内容，到底承载在什么协议报文之上，是ICMP报文的扩展呢，还是UDP报文的扩展呢，还是其他。因此，在相关技术中，存在无法确定SFC OAM报文内容，以及基于什么协议承载该报文的问题。
技术实现思路
本专利技术提供了一种操作、管理和维护OAM报文处理方法及装置，以至少解决相关技术中存在无法确定SFC OAM报文内容，以及基于什么协议承载该报文的问题。根据本专利技术的一个方面，提供了一种操作、管理和维护OAM报文处理方法，包括:源端业务节点确定用于在业务功能链SFC上发送的OAM报文，其中，所述OAM报文包括:载荷Payload、OAM报文头、业务功能报文头，其中，所述OAM报文采用预定的SFC OAM网络端口号承载；所述源端业务节点将承载在所述预定的SFC OAM网络端口号上的所述OAM报文发送给所述SFC上的目的业务节点处理。优选地，所述OAM报文采用以下格式至少之一:Payload、OAM报文头、业务本文档来自技高网...
【技术保护点】
一种操作、管理和维护OAM报文处理方法，其特征在于，包括：源端业务节点确定用于在业务功能链SFC上发送的OAM报文，其中，所述OAM报文包括：载荷Payload、OAM报文头、业务功能报文头，其中，所述OAM报文采用预定的SFC OAM网络端口号承载；所述源端业务节点将承载在所述预定的SFC OAM网络端口号上的所述OAM报文发送给所述SFC上的目的业务节点处理。
【技术特征摘要】
【专利技术属性】
技术研发人员：王翠，孟伟，赵俊，
申请(专利权)人：中兴通讯股份有限公司，
类型：发明
国别省市：广东;44
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。