CN102377602A - 数据流处理方法及系统 - Google Patents

Abstract

本发明提供一种数据流处理方法及系统。其中，方法包括：部署于业务平台的管控节点单元为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型；部署于传输网中的管控节点单元拦截所述数据流，并对所述数据流的业务标识进行一致性检查和分类深度检查，以判断所述数据流对应的业务是否发生异常；当判断出所述业务发生异常时，部署于传输网中的管控节点单元根据监控策略对所述数据流进行处理。本发明技术方案实现了对不同运营商、业务源、本地或异地业务的识别，提高了对于业务控制的精细程度，降低了彼此业务之间的影响。

Description

数据流处理方法及系统

技术领域

本发明涉及广播电视技术，尤其涉及一种数据流处理方法及系统。

背景技术

下一代广播电视网(Next Generation Broadcasting Network；简称为：NGB)是具有统一技术标准的、可管可控可信的、全程全网的宽带交互式下一代广播电视网络。传统的广播电视网主要以广播业务为主，在有线电视前端设置专门人员24小时严密监视播出信号，对可能遭受攻击的卫星节目源进行安全监播，随着三网融合的演进，广播电视网不断引入新的业务形态，网络架构和传输体制也发生了重大的转变，终端类型也随之增加。

面向三网融合的安全管控体系的目标是：杜绝与防范非法内容的传播、确保业务合法性传播、保障业务的服务质量、确保网络传输质量、保障用户/终端的合法性使用。然而，随着网络承载业务形态的不断增加，多种业务共用链路，不同业务的服务质量(Quality of Service；简称为：QoS)需求与流量模式也不同，如果没有完善的技术处理机制来识别不同业务流量，可能发生资源抢占，造成业务之间的干扰，严重情况下，会造成服务异常，这给业务管控系统带来极大的挑战。

发明内容

本发明提供一种数据流处理方法及系统，用以实现对不同运营商、业务源、本地或异地业务的识别，提高对于业务控制的精细程度，降低彼此业务之间的影响。

本发明提供一种数据流处理方法，包括：

部署于业务平台的管控节点单元为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型；

部署于传输网中的管控节点单元拦截所述数据流，并对所述数据流的业务标识进行一致性检查和分类深度检查，以判断所述数据流对应的业务是否发生异常；

当判断出所述业务发生异常时，部署于传输网中的管控节点单元根据监控策略对所述数据流进行处理。

本发明提供一种数据流处理系统，包括：部署于业务平台的管控节点单元和部署于传输网中的管控节点单元；

所述部署于业务平台的管控节点单元，用于为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型；

所述部署于传输网中的管控节点单元，用于拦截所述数据流，并对所述数据流的业务标识进行一致性检查和分类深度检查，以判断所述数据流对应的业务是否发生异常，并在判断出所述业务发生异常时，根据监控策略对所述数据流进行处理。

本发明提供的数据流处理方法及系统，由部署于业务平台的管控节点单元为业务平台输出的数据流封装业务标识，数据流在整个传输过程中都携带业务标识，而部署于传输网的管控节点单元通过对数据流中的业务标识进行一致性检测和分类深度检查，来判断数据流对应的业务是否发生异常，并在检测到异常时，管控节点单元根据监控策略对数据流进行处理，保证了数据流的安全和传输质量。进一步，在本发明技术方案中，部署于业务平台的管控节点单元同时使用业务来源、业务类型、业务运营区域、业务优先级和终端类型作为业务标识，达到了对同一链路上传输的不同运营商、业务源、本地或异地业务的精细识别，提高对于业务控制的精细程度，降低彼此业务之间的影响。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为IPv4分组头部包含8位TOS字段的示意图；

图2为IPv6分组头部中DSCP字段的示意图；

图3A为本发明一实施例提供的数据流处理方法的流程图；

图3B为IPv4报文头部的格式示意图；

图3C为本发明一实施例提供的封装业务标识的IPv4选项字段的示意图；

图3D为IPv6报文头部的格式示意图；

图3E为本发明一实施例提供的封装业务标识的IPv6扩展字段的示意图；

图4为本发明另一实施例提供的数据流处理方法的流程图；

图5为本发明一实施例提供的数据流处理系统的结构示意图；

图6为本发明另一实施例提供的数据流处理系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明技术方案重点在于对业务流进行标识，故在对本发明各实施进行说明之前，先简单介绍一些业务标识机制。

起初，根据当时IP QoS的研究进展，引入流标识(Flow Label)机制用来处理QoS。由于受到当时网络技术发展水平的限制，第一个比较成熟的成果在1994年前后才推出，即所谓的IntServ模型。该IntServ模型在信息传递之前，使用资源预留协议(Resource Reservation Protocol；简称为：RSVP)建立一个可以保证QoS各项指标的一个通道。这种想法似乎是可行的，因为和它相类似的异步传输模式(Asynchronous Transfer Mode；简称为：ATM)技术在QoS上获得了较大的成功，或者说后者的一个主要特点就是解决了QoS问题。但是，由于ATM网络支持的电路/流的数量，基本上是以千条(thousands)为单位实施扩展的，而IP网络，特别是互联网(Internet)这样的全球网络，其业务流基本上是以百万条(millions)为基本单位的，这对于网络中的路由器设备来说，很难支持如此大量的软状态，故IntServ模型并没有获得广泛的应用。另外，IntServ模型也无法解决跨多个运营商进行资源预留管理等问题。后来进一步发展了DiffServ模型，它基于对网络业务的分类来简化处理的类别，从而解决了可扩展性问题，为IP网络的QoS提供了一个可行的解决方案。

通用的区分服务(Differentiated Service；简称为：DiffServ)体系结构是一种保证QoS的网络技术。DiffServ模型定义了一种可以在互联网上实施可扩展的服务分类的体系结构。一种“服务”是由在一个网络内，在同一个传输方向上，通过一条或几条路径传输数据包时的某些重要特征所定义的。这些特征可能包括吞吐率、时延、时延抖动和/或丢包率的量化值或统计值等，也可能是指其获取网络资源的相对优先权。服务分类要求能适应不同应用程序和用户的需求，并且允许对互联网服务的分类收费。

DiffServ体系结构由许多在网络节点上实现的功能要素组成，包括每一跳转发小集合、数据包归类功能和交通调节功能。其中，交通调节功能又包含测量、标记、整形和监察策略四部分。在DiffServ体系结构，只在网络的边界节点上实现复杂的分类和调节功能，并且通过在IPv4和IPv6包头的数据段(Data Segment；简称为：DS)做适当的标记，聚合流量，然后根据所做的标记，采取不同的每一跳转发策略。因此，DiffServ体系结构具备可扩展性。“每一跳行为”保证了在互相竞争资源的数据流中为每个网络节点分配缓冲区和带宽资源时，有一个合理的处理力度。在核心网络节点上，无需维护每个应用程序流或每个用户的转发状态。

实现Diffserv模型主要包括三部分功能部件：1.通信量分类器和调节器(Traffic Conditioner；简称为：TC)：在入节点，分组到达时先经过分类器分类，然后分组根据分类的结果到达不同的调节器。通信量调节器的作用是对输入的通信量进行调节，如果到达分组没有标注，则要根据协定对分组进行标注，或者进行重标注。在出节点，通信量调节器的作用是根据协定对发送到下端DS域的通信量进行调节，使其不超过协定的资源。内部节点可以不需要通信量调节器。2.PHB：PHB是对行为集合(Behavior Aggregate；简称为：BA)分配缓冲器和带宽资源的方法，是实现Diffserv模型的核心，其实现机制包括缓冲管理技术和分组调度技术。3.资源管理部件：资源管理部件完成两部分功能，一部分是负责域内的资源管理，主要是完成对每个节点的通信量调节器和PHB的相关参数的设置；管理部件的另一部分是完成域间的资源管理，这一部分主要在不同域之间进行相互通信时，用于域之间的资源协商。

基于上述各功能部件，Diffserv模型的工作流程主要包括：在通信量进入网络之前，先在网络边界处进行分类，并在必要时对通信量进行约束，使其符合一定的规范，然后通信量被聚集到不同的BA中，BA为通过某一链路的具有相同转发方向和差分服务代码点(Differentiated Services Code Point；简称为：DSCP)的分组的集合。在网络内部，分组根据其标注的DSCP值，选择不同的PHB来处理，不同的PHB决定了分组的转发性能。从本质上讲，Diffserv模型是一种基于相对优先级的服务模型，不同要求的分组用不同的优先级处理，相同优先级的分组汇聚到同一类中，在适当的控制下，高优先级的分组将比低优先级的分组得到更好的服务性能。

在传统的Internet协议中，IPv4分组头部包含8位服务类型标记(Type OfService；简称为：TOS)字段，如图1所示。其中，Prec为三位优先级字段，这一优先级定义了不同分组之间的相对优先级，从O级(正常优先级)到第7级(用于网络控制)。DTR三位的含义如下：

D＝O，正常延迟；D＝1，低延迟。

T＝O，正常吞吐量；T＝1，高吞吐量。

R＝O，正常可靠性；R＝1，高可靠性。

在Diffserv模型中，为提供行为集合的汇聚标示，重新定义了TOS字段的含义，将其称为DSCP。不同的DSCP对应于不同的服务级别，网络对不同DSCP的分组进行不同的处理。对IPv6，DSCP域占用了通信量类型字段，如图2所示。

在图2中，CU(Current Unused)两位当前未定义。理论上DSCP有64种选择，但如何应用互联网数字分配机构(The Internet Assigned NumbersAuthority；简称为：IANA)做了规定，将64种DSCP值分为三个应用范围，每一范围称为一DSCP池。DSCP空间划分如表1所示。

表1

其中，池1的资源由互联网工程任务组(Internet Engineering Task Force；简称为：IETF)统一安排，作为全局的标准化的应用。池3在池1的资源耗尽后，可应用于标准应用。

在网络中，支持Diffserv服务的节点(主机或路由器)称为DS节点，具有共同的服务协定和支持相同PHB集合的相邻DS节点的集合称为DS域。一个DS域的节点可以分为边界节点和内部节点。边界节点的作用是对到达的分组进行分类，并在必要的时候对到达的通信量进行调节，以对通过DS域转发的分组进行适当的处理。DS域的内部节点根据到达分组的DSCP选择适当的PHB，DSCP到PHB的映射可以根据推荐的DSCP→PHB映射，也可以根据局部定义的DSCP→PHB映射。如果DS域边界节点与其它DS域连接，则相连接的两个节点之间通过服务等级协议(Service-Level Agreement；简称为：SLA)协商服务水平，这种协议是双边的。边界节点如果是通信量输入节点，则称为入节点；如果是通信量输出节点，则称为出节点。

Diffserv模型在域的范围内工作，在一个域内，网络管理者可以独立的定义相关的服务和资源配置策略，以及相应的Diffserv模型的定义和映射。不同的域之间可能采用不同的定义和策略，但是互不影响。当端到端的服务不在一个DS域内时，则通过域和域的互连来提供服务。由于域之间不要求统一的策略，因此在提供服务之前，相邻域之间必须通过SLA来实现协商，根据协商的结果来设置边界节点，对服务请求域，设置其出节点，以约束发送的数据符合协定的规范。对服务提供域，设置其入节点，以调节到达的不同类的分组使其符合事先协定的规范。

QoS是服务质量的总效果，目前通用的DiffServ模型基于对网络业务的分类来简化处理的类别，从而解决了可扩展性问题，为IP网络的QoS提供了一个可行的解决方案。但是，随着新兴业务的不断出现，多运营商及跨域业务的出现，要求对运营商、业务源、本地或异地业务进行标识。QoS对业务的识别仅仅是针对某一类业务，无法识别不同运营商，对于业务的控制精细程度不够高，容易影响到其他业务的正常服务。所以制定完善的业务标识可以在发生安全事故时，及时溯源并采取措施。对同一链路传输的多种业务，进行精细化识别。满足对全网业务的精细化管控要求。

针对上述问题，本发明提供一种基于管控系统实现的双栈(双栈技术是在指在终端设备和网络节点上既运行互联网协议版本4(Internet Protocol version4；简称为：IPv4)又运行互联网协议版本6(Internet Protocol version 6；简称为：IPv6)的协议栈，从而实现IPv4与IPv6网络节点间的正常通信。)标识技术，通过在IPv4报头的选项字段或IPv6基本报头的下一报头字段和扩展报头中封装自定义的业务标识，通过制定高效、安全的标识格式以及编码规范，可以实现对业务的唯一标识，有利于扩展QoS，提升传输质量，满足NGB对于业务的可管可控可信要求。下面首先介绍本发明各实施例所基于的管控系统，然后介绍基于管控系统的数据流处理方法。

首先，在本发明各实施例中，NGB具有三大平面：业务平面、网络平面和管控层面。网络平面上的承载网根据网络层次划分为城域网、接入网和楼内网；业务平面的业务平台是在承载网之上的开放平台，可以接入不同类型的、不同业务提供商的业务，实现业务无缝接入，所实现的业务包括多种业务应用和传统的电视广播业务。管控平面即为NGB的管控系统，其对应于网络平面和业务平面，主要包括内容管控、业务管控、网络管控、用户安全管控。其中，内容管控负责对全网各层次的内容进行管控，包括对内容的接入审查、内容的传输安全，对内容进行实时监测，及时过滤非法信息；业务管控负责保证全网业务的安全性，包括业务的接入、根据业务类型进行分级管控等；网络管控负责对网络状态进行监控，分析出合理的网络资源策略，及时调配网络资源，保障业务的安全、高质量传输；用户安全管控负责保证用户的安全，防止非法人员通过终端进行攻击行为，保证全网用户正常享受业务。

本实施例提供的管控系统是跨全网多层次的系统，由管控中心和部署于各业务平台、主要服务系统、主要链路和主要网络设备处的管控节点单元组成的独立于业务平台和承载网的管控系统。本实施例的管控系统能够实现业务、网络、终端等各个层次的管理与控制，包括综合业务控制、用户安全控制、网络测量信息反馈机制以及各层面的自适应调整等方面，确保业务内容的安全可信、网络的可管可控可靠和用户行为的可管可控可追溯。

在本实施例中，管控中心主要具有以下功能：

1、管控中心可以远程监控各个管控节点单元的状态。

具体的，管控中心可以获取所有管控节点单元的状态信息，进而根据每个管控节点单元的状态信息来监控每个管控节点单元的状态。

一种获取管控节点单元的状态信息的方式包括：管控中心通过浏览器/服务器(Browser/Server；简称为：B/S)方式登录各个管控节点单元，并从管控节点单元上获取其状态信息，进而实现对管控节点单元的状态监控。

另一种获取管控节点单元的状态信息的方式包括：管控节点单元根据预设上报周期主动上报自己的状态信息，管控中心接收管控节点单元主动上报的状态信息，进而实现对管控节点单元的状态监控。其中，上报周期可以结合各个管控节点单元所在层面的相关信息进行适应性设置，对于每个管控节点单元的上报周期具体为多少，是否相同等，在本实施例中均不做限定。本实施例提供一种各个管控节点单元的上报周期的优选值为1分钟。

进一步，在本实施例中，管控中心还可以根据各个管控节点单元的状态对各个管控节点单元进行控制，例如控制各个管控节点单元是否执行监控操作，又例如控制各个管控节点单元对某一数据流进行放行、过滤或关断等操作。

另外，本实施例的管控中心还具有接收管控节点单元上报的处理请求，然后控制管控节点单元进行相应的监控操作。其中，管控节点单元在遇到无法处理的情况时，会主动向管控中心上报处理请求，由管控中心决定如何进行处理，并向管控节点单元下发相应的处理操作指令，以控制管控节点单元进行监控操作。

2、管控中心负责制定和更新监控策略，并负责向各个管控节点单元下发监控策略。

在本实施例中，管控中心会存储用户信息及一段时间之内的网络状态、业务状态和用户行为等信息。其中，上述用户信息、网络状态、业务状态以及用户行为等信息是由业务平台、承载网、运营支撑系统等提供。另外，管控中心还会存储管控节点单元上传的状态信息。

管控中心会根据上述用户信息、近期的网络状态、业务状态和管控节点单元的状态信息等，制定监控策略。其中，管控中心会将制定出的监控策略存储到策略库中。当上述各种信息发生变化时，管控中心会对监控策略进行更新，例如修改某个监控策略、增加新的监控策略或者删除某个监控策略等。另外，为了保证监控策略能够与当前的网络状态、业务状态、用户信息、管控节点单元的状态等相适应，管控中心还会预设更新周期，当更新周期到达时，管控中心对监控策略进行更新。本实施例并不限定更新周期的具体数值，其可以根据实际应用环境进行适应性设置。

在此说明，上述根据信息变化和根据更新周期对监控策略进行更新的操作是两种不同的方法，管控中心可以采用其中一种方法，也可以同时采用两种方法。

为了使各管控节点单元能够及时获取到监控策略，管控中心可以根据预设下发周期，定期将策略数据库中的监控策略发送给各个管控节点单元。另外，当监控策略有更新时，管控中心可以在更新监控策略后，将更新后的监控策略发送给各个管控节点单元。本实施例并不限定下发周期的具体数值，其可以根据实际应用环境进行适应性设置。

另外，管控节点单元可以主动向管控中心发送策略获取请求，而管控中心根据管控节点单元发送的策略获取请求向管控节点单元下发监控策略。其中，各个管控节点单元主动请求监控策略的操作彼此独立，互不影响，管控中心只需要向主动请求的管控节点单元发送监控策略即可。

进一步，本发明实施例的管控中心还可以具有以下功能：

3、管控中心与NGB中的业务平台、NGB的承载网和运营支撑系统等连接并进行信息交互。

在本实施例中，管控中心与业务平台、承载网、运营支撑系统等连接，分别获取业务平台的业务状态信息、承载网的网络状态信息和运营支撑系统的用户信息等，对获取的信息进行统计分析，为业务平台和/或承载网等制定资源调配策略或生成告警信息，并将资源调配策略或告警信息发送给业务平台和/或承载网等，以辅助业务平台、和/或承载网开展服务。

例如：管控中心可以根据获取的上述信息为业务平台制定包括业务运营带宽需求和用户接入端不同业务的带宽限制策略等。又例如：管控中心还可以根据从承载网中获取的链路状态异常或饱和(例如：网管系统主动上报的链路状态异常或饱和)等信息，通知业务平台进行相关操作，最大限度保证现有用户享受正常服务。

另外，管控中心从业务平台、承载网、运营支撑系统等获取业务状态信息、网络状态信息以及用户行为等信息，为管控中心制定监控策略提供了条件。

4、管控中心负责记录相关操作的日志信息，并根据日志信息进行用户识别、用户区域识别、业务识别等，实现事故回溯。

其中，相关操作包括：业务状态查询、网络状态查询、接收到策略请求、下发策略等；相应地日志信息包括：事件发生的时间、操作方式、业务标识、用户标识等信息。例如：管控中心可以根据业务标识进行业务识别。又例如：管控中心可以根据用户标识进行用户识别和用户区域识别。再例如：管控中心还可以根据事件发生的事件、业务标识、用户标识等信息实现事故回溯等。

本实施例的管控节点单元主要具有以下功能：

1、接收管控中心下发的监控策略，并根据监控策略对所在层面上的数据流进行监控操作。

在本实施例中，管控中心下发给管控节点单元的监控策略包括：截断策略、过滤策略、替换策略等。管控节点单元对所在层面的数据流进行监控，并可以直接根据上述策略对检测到的非法数据流进行截断、过滤或替换等操作。另外，本实施例的管控节点单元也可以通知管控中心，由管控中心下发处理操作指令，然后根据处理操作指令进行相应处理。

2、向管控中心提供其自身状态信息。

其中，管控节点单元可以定期或及时主动向管控中心提供自身的状态信息，以及保存的日志信息(例如用户信息、业务信息等)，为事故回溯提供依据。另外，管控节点单元还可以允许管控中心登录并获取其状态信息以及所保存的日志信息等。

进一步，本实施例的管控节点单元还具有以下功能：

3、根据事故的敏感度决定是否可直接关断链路。

例如：当事故敏感度较高时，管控节点单元可直接关断链路，然后再通知管控中心；反之，管控节点单元直接将事故上报给管控中心，由管控中心下发处理操作指令，然后根据处理操作指令进行相应处理操作。

本实施例的管控节点单元与管控中心交互，根据监控策略执行数据流过滤、截断、替换等操作，保证了网络的安全。

图3A为本发明一实施例提供的数据流处理方法的流程图。如图3A所示，本实施例的方法包括：

步骤301、部署于业务平台的管控节点单元为业务平台输出的数据流封装对应的业务标识，并将封装业务标识的数据流发送出去。

在本发明各实施例中，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型。

当业务平台有数据流输出时，部署于业务平台的管控节点单元根据管控中心的统一标识，为业务平台输出的数据流定义和生成具有唯一性的业务标识，将所生成的业务标识封装到数据流之上。

当数据流采用IPv4报文传输时，部署于业务平台的管控节点单元将业务标识封装在数据流的IPv4选项字段中，然后将封装有业务标识的数据流发送出去。管控节点单元在IPv4选项字段中封装业务标识的方法主要包括：在选项代码字段的保留值1或3中选取一个值，用来标识自定义业务标识的类型；通过长度字段指明封装该自定义业务标识的选项字段的大小；通过指针字段指明下一个可使用空间的位置；在选项字段中封装自定义的业务标识；如果自定义的业务标识有固定格式，定义一定长度的标识格式；如果自定义的业务标识长度可变，采用采用类型-长度-值(Type-Length-Value；简称为：TLV)三元组进行编码。其中，IPv4报文头部的格式如图3B所示，封装业务标识的IPv4选项字段的格式如图3C所示。

当数据流采用IPv6报文传输时，部署于业务平台的管控节点单元将业务标识封装在IPv6的扩展报头中，然后将封装业务标识的数据流发送出去。管控节点单元在IPv6的扩展报头中封装业务标识的方法主要包括：在下一报头字段的未分配的133-254范围中选取一个值，作为自定义标识扩展报头类型；在扩展报头中封装自定义的业务标识；在扩展报头中，通过下一报头字段定义紧接着的下一报头的类型，通过长度字段指明封装该自定义业务标识的扩展报头的长度；如果自定义的业务标识有固定格式，定义一定长度的标识格式；如果自定义的业务标识长度可变，采用采用TLV(类型-长度-值)三元组进行编码。图3D所示为IPv6基本报头格式，封装业务标识的IPv6的扩展报头格式如图3E所示。

步骤302、部署于传输网中的管控节点单元拦截数据流，并对数据流的业务标识进行一致性检查和分类深度检查，以判断数据流对应的业务是否发生异常；当判断结果为是，即判断出业务发生异常时，执行步骤303；反之，当判断结果为否，即判断出业务未发生异常时，执行步骤304。

在本实施例中，在传输网的各链路或节点上部署有管控节点单元，具有业务状态探测和事故处理等功能，为业务服务器提供业务标识插件，保证数据流在下发过程中携带业务标识。具体的，部署于传输网上的管控节点单元拦截到数据流后，对数据流进行解析，获取数据流携带的业务标识；然后根据一定的判断机制判断数据流对应的业务是否发生异常。部署于传输网的管控节点单元可以采用以下任一判断机制或其任意组合来判断业务是否发生异常：

例如：部署于传输网的管控节点单元判断数据流携带的业务标识是否存在于预设标识列表中；当判断结果为否时，确定数据流对应的业务发生异常。其中，标识列表中存储有整个广播电视网中应该使用的所有业务标识，如果某个数据流携带的业务标识不属于标识列表中的标识，说明该业务标识是非法的，进而说明该业务标识所标识的业务发生了异常。

例如：部署于传输网的管控节点单元判断数据流中各个数据包所携带的业务标识是否相同，当判断结果为否时，确定数据流对应的业务发生异常。其中，同一数据流中各个数据包所携带的业务标识应该相同，如果发现同一数据流中各个数据包携带的业务标识不同，或者在同一数据流中发现携带有不同业务标识的数据包时，说明该数据流发生了异常，可能遭到攻击或者被篡改过等，故可以确定所对应的业务发生异常。

上述两种判断机制主要是对业务标识的一致性进行检查。

又例如：因为不同的业务种类对安全级别的要求不同，当节点管控单元收到一个诸如HTTP的数据包时，便可以根据业务标识中的业务类型和相应的应用层协议对该数据包进行检查，检测该数据包的操作行为是否符合请求评论(Request For Comments；简称为：RFC)标准或预先约定的私有协议，以此判断该数据包是否是恶意的或未经授权的。如果不符合RFC标准或预先约定的私有协议，则该数据包是经过恶意伪装的，即非HTTP数据包被封装进了目的端口号为TCP 80的HTTP数据包，确定业务发生异常。该判断机制主要是根据业务标识中的业务类型对负载内容进行分类深度检查。

步骤303、部署于传输网中的管控节点单元根据监控策略对数据流进行处理。

当确定数据流对应的业务发生异常时，部署于传输网中的管控节点单元就需要根据异常行为对数据流进行处理。例如：部署于传输网中的管控节点单元根据监控策略对数据流进行处理，其中监控策略与异常行为相适应。

具体的，每个管控节点单元上都存储有管控中心预先下发的监控策略，当监控策略中存在与异常行为对应的处理方式时，部署于传输网的管控节点单元根据管控中心预先下发的监控策略对数据流进行截断、丢弃或替换处理。例如：若符合替换原则，则有选择地替换TCP或UDP数据包。例如：若符合过滤原则，则有选择地过滤TCP或UDP数据包。例如：若符合截断原则，为防止内嵌在数据包有效载荷内的恶意行为，则管控节点单元就会截断该数据包。

当监控策略中没有与异常行为对应的处理方式时，部署于传输网的管控节点单元向管控中心上报业务异常信息，管控中心根据业务异常信息进行统计分析，生成解决方案并将解决方案下发给部署于传输网的管控节点单元，部署于传输网的管控节点单元根据解决方案对数据流进行处理。

进一步，在本实施例中，管控中心负责制定、生成、更新监控策略。当管控中心生成解决方案后，还会将该解决方案更新监控策略，例如直接将该解决方案作为新的监控策略存储起来，并会将更新后的监控策略下发给部署于业务平台和传输网的管控节点单元，以使部署于业务平台和传输网的管控节点单元更新所存储的监控策略。另外，管控中心还可以向管理员进行告警，根据业务运营商和业务编号溯源，根据业务运营区域及时采取管控措施，根据终端类型采取不同级别的管控措施等。

在对数据流进行处理后，根据对数据流的处理情况，例如替换或删除部分数据包之后，部署于传输网的管控节点单元将处理后的数据流输出到广播电视网的传输链路上，以使数据流继续传输。

步骤304、部署于传输网中的管控节点单元直接将数据流输出到广播电视网络的链路上。

当业务未发生异常时，部署于传输网中的管控节点单元直接将数据流输出到广播电视网的链路上，以使数据流继续传输，直至传输到用户端。

本实施例的数据流处理方法，由业务平台的管控节点单元为数据流打上业务标识，使得数据流在整个传输过程中都携带业务标识，而传输网上的管控节点单元通过对业务标识进行一致性检查，并根据业务标识中的业务类型对负载内容进行分类深度检查，可以识别数据流对应的业务是否发生异常，在业务发生异常时对业务进行替换、过滤或删除等处理，通过识别传输内容的安全性和网络流量的异常，保障了业务的高质量传输；进一步，在本实施例中，使用至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型等信息的业务标识，实现了对不同运营商、业务源、本地或异地业务的识别，降低彼此业务之间的影响，足对全网业务的精细化管控的要求，满足NGB对于业务的可管可控可信要求，而通过对业务的唯一标识，有利于扩展QoS，提升传输质量，完善的业务标识可以在发生安全事故时，及时溯源并采取措施提高对于业务控制的精细程度。

其中，交互类业务是NGB广播电视网重要的组成部分，为用户提供了大量的媒体内容。对于交互类业务，NGB的监控需要考虑多方面，包括用户端的合法性、业务服务器的合法性、数据在传输过程中的完整性，业务服务器所提供内容的合法性等。在交互类业务中，用户主要是内容的接收者，因此该类业务的监控主要在于内容合法性和传输过程中的完整性两方面。

交互类业务包括：视频点播业务、频道回放业务、时移电视业务、推送业务和准视频点播业务。以推送业务为例，推送业务将内容(包括数据、音视频和广告)直接传送到机顶盒终端。推送以单播或组播的形式将用户选定的内容被动推送到用户的本地机顶盒终端，或者以组播的形式将用户群的热点相关内容主动推送到这些用户的本地机顶盒终端，终端通过本地存储介质接收并储存内容。用户在随时访问的过程当中，只是访问本地终端存储的内容，而不需再到网络和系统上去做远程调用。推送业务使得用户获得业务内容及时响应的使用感受，运营商也节省了资源。下面以推送业务为例，详细说明推送业务中数据流的处理过程。

图4为本发明另一实施例提供的数据流处理方法的流程图。如图4所示，本实施例的方法包括：

步骤401、管控中心为推送业务定制管控策略，并将为推送业务定制的管控策略同步给管控节点单元的策略分库。

其中，管控节点单元包括部署于业务平台的管控节点单元，也包括部署于传输网的管控节点单元。

步骤402、管控中心制定资源调配策略，并将资源调配策略同步给网管系统。

其中，资源调配策略包括推送业务的运营带宽需求和用户接入端不同业务的带宽限制策略等。

步骤403、在推送业务之前，部署于业务平台的管控节点单元根据管控中心的统一标识，为推送业务定义和生成业务标识，将推送业务对应的业务标识封装到推送业务的数据流中各个数据包上。

其中，业务标识至少包括业务来源、业务类型，业务运营区域、业务优先级和终端类型等。

当数据流采用IPv4报文时，管控节点单元主要将由业务来源、业务类型，业务运营区域、业务优先级和终端类型等构成的业务标识封装在IPv4数据包的选项字段中。

当数据流采用IPv6报文时，管控节点单元主要将由业务来源、业务类型，业务运营区域、业务优先级和终端类型等构成的业务标识封装在IPv6数据包的扩展报头中。

这样在整个推送过程中，推送业务的数据流就会携带具有唯一性的业务标识，为管控系统提供了精确的数据支持，可以较大程度保障业务源和业务的合法性和安全性。

步骤404、在推送过程中，部署于传输网中的管控节点单元对推送业务的状态进行监控。

具体的，管控节点单元判断推送业务是否发生异常，例如：是否发生黑场，静帧等各种故障，并保存推送过程中的故障或异常日志，以作为日后查询分析的依据。

进一步，由于业务标识在推送业务的从源头到终端的整个传输过程中始终存在，故管控节点单元可以通过实时监测或定时抽查业务标识的方式对业务标识进行一致性检测，并根据业务标识中的业务类型对负载内容进行分类深度检查，从而判断推送业务是否发生异常。例如：判断推送业务是否合法以及是否被恶意篡改等。具体判断基于可参见步骤302中的详细描述，在此不再赘述。

当监测到故障或异常时，管控节点单元可以通过执行步骤405，即根据策略分库中的监控策略或解决方案，对推送业务的数据流中的非法内容进行截断、过滤或替换，从而截断非法内容造成的对传输网络的攻击，防止推送业务的内容被非法篡改或攻击，保证推送业务的数据流的安全。当策略分库中没有相应的处理策略时，管控节点单元可以执行步骤406-步骤408，即通知管控中心，由管控中心生成相应的处理策略。

步骤405、部署于传输网的管控节点单元根据策略分库中的监控策略或解决方案，对推送业务的数据流中的非法内容进行截断、过滤或替换。

步骤406、如果管控节点的策略分库没有相应的解决方案，管控节点单元通过信令通知管控中心。

步骤407、管控中心对事故进行统计分析并生成解决方案和告警，升级策略库，管控中心将解决方案通过信令方式通知管控节点单元。

步骤408、管控节点单元根据解决方案执行相应的处理操作。

在该实施例方式中，管控中心还会用生成的解决方案更新策略库中的监控策略，并将更新的策略库同步给管控节点单元。

步骤409、网管系统检测到推送业务的链路状态异常或饱和后，通知给管控中心。

网管系统对前端到机顶盒终端之间的推送链路进行管控，保证链路始终通畅和安全。

步骤410、管控中心收到网关系统发送的推送业务的链路状态异常或饱和通知后，通过通信接口协调业务平台进行相关操作。

步骤411、在整个推送过程中，部署于各层次的管控节点单元管控节点定期同步日志信息给管控中心；管控中心定期对日志信息进行统计分析，保证事故回溯。

本实施例以推送业务为例详细说明了管控系统是如何通过对数据流添加业务标识对数据流进行监测的，管控系统通过业务标识对数据流进行监测的流程并不限于推送业务，其他交互类业务同样适用。

本实施例通过对推送业务的数据流添加业务标识，并通过对业务标识对数据流进行监测，防止了数据流被篡改或攻击，保证了广播电视网的安全和业务的传输质量。进一步，通过适用业务来源、业务类型，业务运营区域、业务优先级和终端类型等作为业务标识，能够区分不同运营商、业务类型、本地或异地业务，达到了对业务更加精细的识别，降低彼此业务之间的影响，足对全网业务的精细化管控的要求，满足NGB对于业务的可管可控可信要求。

图5为本发明一实施例提供的数据流处理系统的结构示意图。如图5所示，本实施例的系统包括：部署于业务平台的管控节点单元51和部署于传输网中的管控节点单元52。

本实施例的数据流处理系统可由前述的管控系统实现，主要应用于NGB中。其中，本实施例中部署于业务平台的管控节点单元51和部署于传输网的管控节点单元52除具有管控系统中管控节点单元的功能之外，还具有以下功能：

部署于业务平台的管控节点单元51，用于为业务平台输出的数据流封装对应的业务标识，并将封装业务标识的数据流发送出去。所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型。

部署于传输网中的管控节点单元52，用于拦截数据流，并对数据流的业务标识进行一致性检查和分类深度检查，以判断数据流对应的业务是否发生异常，并在判断出业务发生异常时，根据监控策略对数据流进行处理。

本实施例的数据流处理系统可用于执行图3A所示数据流处理方法的流程，其具体工作原理不再赘述，详见方法实施例的描述。

在本实施例中，由部署于业务平台的管控节点单元为业务平台输出的数据流封装业务标识，数据流在整个传输过程中都携带业务标识，而部署于传输网的管控节点单元通过对数据流中的业务标识进行一致性检测和分类深度检查，来判断数据流对应的业务是否发生异常，并在检测到异常时，管控节点单元根据监控策略对数据流进行处理，保证了数据流的安全和传输质量。进一步，在本实施例中，部署于业务平台的管控节点单元同时使用业务来源、业务类型、业务运营区域、业务优先级和终端类型作为业务标识，达到了对同一链路上传输的不同运营商、业务源、本地或异地业务的精细识别，提高对于业务控制的精细程度，降低彼此业务之间的影响。

图6为本发明另一实施例提供的数据流处理系统的结构示意图。本实施例基于图5所示，在本实施例中，部署于传输网中的管控节点单元52，还用于在判断出业务未发生异常时，将数据流输出到广播电视网络的链路上。

进一步，在本实施例中，部署于业务平台的管控节点单元51具体用于为业务平台输出的数据流定义具有唯一性的业务标识，将所定义的业务标识封装在数据流的IPv4选项字段或IPv6扩展报头中，然后将封装业务标识的数据流发送出去。

其中，部署于传输网的管控节点单元52具体用于判断业务标识是否存在于预设标识列表中，当判断结果为否时，确定数据流对应的业务发生异常。或者，部署于传输网的管控节点单元52具体用于判断数据流的各个数据包所携带的业务标识是否相同，当判断结果为否时，确定数据流对应的业务发生异常。部署于传输网的管控节点单元52还具体用于根据业务标识中的业务类型和相应的应用层协议判断所述数据流中各个数据包的操作行为是否符合请求评论RFC标准或预先约定的私有协议，当判断结果为否时，确定所述数据流对应的业务发生异常。

如图6所示，本实施例的系统还包括：管控中心53。

在本实施例中其中，本实施例的管控中心53可由前述管控系统中的管控中心实现，除了具有前述功能之外还具有以下功能：

管控中心53预先向各管控节点单元下发监控策略。相应地，部署于传输网的管控节点单元52具体用于根据管控中心53预先下发的监控策略对数据流进行截断、丢弃或替换处理。

另外，部署于传输网的管控节点单元52还具体用于向管控中心53上报业务异常信息，并接收管控中心53下发的解决方案，然后根据解决方案对数据流进行处理。

而管控中心53还用于接收部署于传输网的管控节点单元52上报的业务异常信息，根据业务异常信息进行统计分析，生成解决方案并将解决方案下发给部署于传输网的管控节点单元52。

进一步，本实施例的管控中心53还用于根据解决方案更新监控策略，并将更新后的监控策略下发给部署于业务平台的管控节点单元51和部署于传输网的管控节点单元52，以使部署于业务平台的管控节点单元51和部署于传输网的管控节点单元52更新所存储的监控策略。

本实施例的数据流处理系统可用于执行图3A或图4所示数据流处理方法的流程，其具体工作原理不再赘述，详见方法实施例的描述。另外，关于数据流处理系统中各模块之间的协作关系以及其他功能均可参见前述管控系统中的描述，在此亦不再赘述。

在本实施例中，由部署于业务平台的管控节点单元为业务平台输出的数据流封装业务标识，数据流在整个传输过程中都携带业务标识，而部署于传输网的管控节点单元通过对数据流中的业务标识进行一致性检测，并根据业务标识中的业务类型对负载内容进行分类深度检查，以判断数据流对应的业务是否发生异常，并在检测到异常时，管控节点单元根据监控策略对数据流进行处理，保证了数据流的安全和传输质量。进一步，在本实施例中，部署于业务平台的管控节点单元同时使用业务来源、业务类型、业务运营区域、业务优先级和终端类型作为业务标识，达到了对同一链路上传输的不同运营商、业务源、本地或异地业务的精细识别，提高对于业务控制的精细程度，降低彼此业务之间的影响。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (12)

1.一种数据流处理方法，其特征在于，包括：

部署于业务平台的管控节点单元为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型；

部署于传输网中的管控节点单元拦截所述数据流，并对所述数据流的业务标识进行一致性检查和分类深度检查，以判断所述数据流对应的业务是否发生异常；

当判断出所述业务发生异常时，部署于传输网中的管控节点单元根据监控策略对所述数据流进行处理。

2.根据权利要求1所述的数据流处理方法，其特征在于，还包括：

当判断出所述业务未发生异常时，部署于传输网中的管控节点单元将所述数据流输出到广播电视网络的链路上。

3.根据权利要求1所述的数据流处理方法，其特征在于，所述部署于业务平台的管控节点单元为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去包括：

所述部署于业务平台的管控节点单元为所述业务平台输出的数据流定义具有唯一性的业务标识；

所述部署于业务平台的管控节点单元将所述业务标识封装在所述数据流的互联网协议版本4IPv4选项字段或互联网协议版本6IPv6扩展报头中；

所述部署于业务平台的管控节点单元将封装所述业务标识的数据流发送出去。

4.根据权利要求1所述的数据流处理方法，其特征在于，所述部署于传输网中的管控节点单元对所述数据流的业务标识进行一致性检查，以判断所述数据流对应的业务是否发生异常包括：

所述部署于传输网的管控节点单元判断所述业务标识是否存在于预设标识列表中，当判断结果为否时，确定所述数据流对应的业务发生异常；或者

所述部署于传输网的管控节点单元判断所述数据流的各个数据包所携带的业务标识是否相同，当判断结果为否时，确定所述数据流对应的业务发生异常；

所述部署于传输网中的管控节点单元对所述数据流的业务标识进行分类深度检查，以判断所述数据流对应的业务是否发生异常包括：所述部署于传输网的管控节点单元根据所述业务标识中的业务类型和相应的应用层协议判断所述数据流中各个数据包的操作行为是否符合请求评论RFC标准或预先约定的私有协议，以此判断所述数据包是否是恶意的或未经授权的，当判断结果为否时，确定所述数据流对应的业务发生异常。

5.根据权利要求4所述的数据流处理方法，其特征在于，所述部署于传输网中的管控节点单元根据监控策略对所述数据流进行处理包括：

所述部署于传输网的管控节点单元根据管控中心预先下发的监控策略对所述数据流进行截断、丢弃或替换处理；或者

所述部署于传输网的管控节点单元向管控中心上报业务异常信息，所述管控中心根据所述业务异常信息进行统计分析，生成解决方案并将所述解决方案下发给所述部署于传输网的管控节点单元，所述部署于传输网的管控节点单元根据所述解决方案对所述数据流进行处理。

6.根据权利要求5所述的数据流处理方法，其特征在于，还包括：

所述管控中心根据所述解决方案更新监控策略，并将更新后的监控策略下发给所述部署于业务平台和传输网的管控节点单元，以使所述部署于业务平台和传输网的管控节点单元更新所存储的监控策略。

7.一种数据流处理系统，其特征在于，包括：部署于业务平台的管控节点单元和部署于传输网中的管控节点单元；

所述部署于业务平台的管控节点单元，用于为所述业务平台输出的数据流封装对应的业务标识，并将封装所述业务标识的数据流发送出去，所述业务标识至少包括业务来源、业务类型、业务运营区域、业务优先级和终端类型；

所述部署于传输网中的管控节点单元，用于拦截所述数据流，并对所述数据流的业务标识进行一致性检查和分类深度检查，以判断所述数据流对应的业务是否发生异常，并在判断出所述业务发生异常时，根据监控策略对所述数据流进行处理。

8.根据权利要求7所述的数据流处理系统，其特征在于，所述部署于传输网中的管控节点单元，还用于在判断出所述业务未发生异常时，将所述数据流输出到广播电视网络的链路上。

9.根据权利要求7所述的数据流处理系统，其特征在于，所述部署于业务平台的管控节点单元具体用于为所述业务平台输出的数据流定义具有唯一性的业务标识，将所定义的业务标识封装在所述数据流的互联网协议版本4IPv4选项字段或互联网协议版本6IPv6扩展报头中，然后将封装所述业务标识的数据流发送出去。

10.根据权利要求7所述的数据流处理系统，其特征在于，所述部署于传输网的管控节点单元具体用于判断所述业务标识是否存在于预设标识列表中，当判断结果为否时，确定所述数据流对应的业务发生异常；或者具体用于判断所述数据流的各个数据包所携带的业务标识是否相同，当判断结果为否时，确定所述数据流对应的业务发生异常；所述部署于传输网的管控节点单元还具体用于根据所述业务标识中的业务类型和相应的应用层协议判断所述数据流中各个数据包的操作行为是否符合请求评论RFC标准或预先约定的私有协议，当判断结果为否时，确定所述数据流对应的业务发生异常。

11.根据权利要求10所述的数据流处理系统，其特征在于，还包括：管控中心；

所述部署于传输网的管控节点单元具体用于根据所述管控中心预先下发的监控策略对所述数据流进行截断、丢弃或替换处理；或者

所述部署于传输网的管控节点单元具体用于向所述管控中心上报业务异常信息，并接收所述管控中心下发的解决方案，然后根据所述解决方案对所述数据流进行处理；

所述管控中心用于根据所述业务异常信息进行统计分析，生成解决方案并将所述解决方案下发给所述部署于传输网的管控节点单元。

12.根据权利要求11所述的数据流处理系统，其特征在于，所述管控中心还用于根据所述解决方案更新监控策略，并将更新后的监控策略下发给所述部署于业务平台和传输网的管控节点单元，以使所述部署于业务平台和传输网的管控节点单元更新所存储的监控策略。

Images