WO2006069511A1 - Procede pour empecher un flux de donnees multidiffusion ip de surcharger un systeme de telecommunication grace a la distinction de differents services - Google Patents
Procede pour empecher un flux de donnees multidiffusion ip de surcharger un systeme de telecommunication grace a la distinction de differents services Download PDFInfo
- Publication number
- WO2006069511A1 WO2006069511A1 PCT/CN2005/001152 CN2005001152W WO2006069511A1 WO 2006069511 A1 WO2006069511 A1 WO 2006069511A1 CN 2005001152 W CN2005001152 W CN 2005001152W WO 2006069511 A1 WO2006069511 A1 WO 2006069511A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- key
- multicast
- forwarding
- protocol
- policy
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/20—Traffic policing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
Definitions
- the present invention relates to the implementation of IP multicast in an IP communication system such as wired and wireless, and more particularly to a method for preventing a large-flow multicast data stream from impacting a communication system.
- IP multicast technology effectively solves the problem of single-point transmission and multi-point reception, and achieves efficient point-to-multipoint data transmission in IP networks, which can save a lot of network bandwidth and reduce network load.
- the significance of multicast is not only here. More importantly, the network's multicast features can be used to easily provide some new value-added services, including online live broadcast, Internet TV, distance education, telemedicine, Internet radio, real-time video conferencing and other Internet information services. Due to the above characteristics of IP multicast, it has great application prospects in the wired network and wireless cable field.
- routing implementation in IP communication systems is divided into two modes: one, protocol and forwarding serial processing; second, protocol and forwarding parallel processing.
- protocol and forwarding serial processing In order to achieve fast forwarding, a design pattern of parallel processing of forwarding and protocol is widely used. Whether it is a parallel processing mode or a serial processing mode, protocol processing and forwarding are required to be handled by different processes. The complexity of protocol processing and the resource usage of the CPU are much higher than the forwarding processing.
- the protocol and the forwarding serial processing mode For the IP communication device adopting the protocol and the forwarding serial processing mode, when the multicast stream drive occurs, the data message is completely handed over to the multicast protocol for processing. If the multicast data stream is large at this time, the Cpu needs to process each data packet according to the multicast protocol, which will occupy a large amount of cpu resources, resulting in a linear decline in overall system performance.
- IP communication devices that use protocol and forwarding parallel processing they are divided into two architectures: one is centralized architecture; the other is distributed architecture. Both forwarding are independent of the protocol, and forwarding runs on a dedicated network processor. In a centralized architecture, the protocol processor and the forwarding processor share the same memory area.
- the protocol processor and the forwarding processor have their own memory regions, and there is inter-board communication.
- the impact of the multicast stream driver on the system is similar to the serial processing mode, but for the distributed parallel processing mode, on the basis of this, the multicast stream driver will also lead to inter-board communication. The impact of the system, if not handled properly, will have a greater impact on the system.
- IP multicast protocol is a routing protocol that is closely related to the application. Different multicast service flows may have different requirements for forwarding service quality. Therefore, different traffic limiting messages are required for different service quality multicast data packets. Strategy, in order to minimize the negatives caused by current limiting.
- the technical problem to be solved by the present invention is to provide a method for distinguishing multi-service anti-IP multicast data stream impact communication system, which can distinguish different multicast service flows and adopt corresponding strategies to avoid large-flow multi-service IP multicast data flow. Load impact on IP communication equipment.
- the present invention provides a method for distinguishing a multi-service anti-IP multicast data stream impact communication system, comprising the following steps:
- the protocol layer drives the protocol state machine according to the received multicast data message to generate a multicast routing forwarding entry M (key); and the forwarding layer searches for the case in the configured multicast traffic limiting policy.
- the traffic restriction policy corresponding to the key generates a temporary forwarding route entry T_M (key), and uses the entry to limit the subsequent multicast data packet (key);
- the protocol layer is capable of generating a normal forwarding entry M(key) of the key value
- the entry is synchronized to the forwarding layer, and the forwarding layer updates T-M (key) with M (key) to enter normal forwarding; otherwise, the forwarding layer According to the current limiting strategy attached to T-M (key), the current limit is continued, and when the current limit is terminated.
- the above method may also have the following features: the forwarding flag of the temporary forwarding route entry T_M (key) generated in the step (a2) is N, and the subsequent multicast data packet (key) will be discarded. .
- the present invention further provides a method for distinguishing a multi-service anti-IP multicast data stream impact communication system, including the following steps -
- the protocol layer generates a multicast routing entry M(key) according to the protocol state machine. If the entry has an upload flag Upsend, the next step is performed; otherwise, the M(key) is synchronized to the forwarding layer, generating or updating the forwarding.
- the routing table enters the normal route forwarding process, and the multicast flow control ends.
- the protocol layer retrieves the traffic limiting policy corresponding to the key in the configured multicast traffic limiting policy, and applies it to the M (key) to make it a P-M (key) with a limited traffic policy, and then It is synchronized to the forwarding layer;
- the above method may have the following feature: after the step (b3) further comprises the step of (B4): If you need to P-M (key) limiting policy multicast packet pa C ket (key) After being sent to the protocol processor, it is returned to the execution step (M) after being sent. Further, the above method may also have the following features: In the step (b2), the searched current limiting flag is applied to the uploading flag Upsend to obtain the policy sending flag Upsend', thereby obtaining the corresponding P. — M(key).
- the foregoing method may further have the following features:
- the multicast data packet is sent to the protocol processor after being sent to the protocol processor. , discard the subsequent related multicast data packet (key).
- the present invention also provides a method for distinguishing a multi-service anti-IP multicast data stream impact communication system, comprising the following steps:
- (c2) directly use the pre-set assertion mechanism current limiting policy at the forwarding layer to determine whether the policy requires the packet (ke y ) to be sent to the multicast protocol processor, for example, to send the data packet (key), Then, the protocol layer forms a new multicast routing entry according to the protocol state machine, and synchronizes to the forwarding layer. If the uplink is not required, the multicast data packet pa C ket(key:) is masked.
- the assertion mechanism current limiting policy is a fixed current limiting manner that does not distinguish key values.
- the assertion mechanism current limiting policy is a corresponding current limiting policy in the case that is retrieved according to the key value.
- the method introduces a current limiting flag capable of distinguishing an assertion mechanism, and sets and clears the flag according to the assertion mechanism current limiting policy, and limits the multicast used to trigger the assertion mechanism state machine. Impact of data packets on the CPU of the multicast protocol.
- the present invention further provides a method for distinguishing a multi-service anti-IP multicast data stream impact communication system, comprising the following steps:
- the (dl) multicast data packet (key) of the key value arrives at the forwarding layer, and the forwarding layer determines whether it can match the corresponding forwarding route. If yes, perform the next step, otherwise, perform step (d8);
- step (d2) judging whether the forwarding condition is met. If yes, the forwarding layer first enters the normal forwarding process to forward the pa C k e t (key), and then performs the next step, otherwise step (d6) is performed;
- (d3) determining whether the protocol requires the multicast data packet to be sent to the protocol processor. If yes, the forwarding layer sends the packet (key) to the protocol layer to perform the next step. Otherwise, the traffic limiting is not performed. ;
- the protocol layer receives the multicast data packet (packet) sent by the forwarding layer, and the driver protocol state machine generates a new multicast routing entry M (key). If the M (key) has the upload flag Upsend, The next step is performed; otherwise, the M(key) is synchronized to the forwarding layer, and the forwarding layer forwards the received multicast data packet (key) according to the new multicast routing entry M (key), and ends;
- the protocol layer retrieves the current limiting policy corresponding to the key in this case and applies it to M(key), To the P-M (key) with the finite-flow policy and synchronize it to the forwarding layer, the forwarding layer implements the multicast data packet (key) to the protocol processor according to the P-M (key) traffic limiting policy.
- Current limit
- the forwarding layer updates the T-M (key) with the entry, and enters the normal forwarding process, ending; if the M (key) cannot be generated, the forwarding layer is based on The current limiting policy attached to T-M (key) continues to limit the current, and determines when the current limit ends according to the policy.
- the foregoing method may further have the following feature: in the step (d5), if the multicast data packet (key) needs to be sent to the protocol processor according to the P_M (key) current limiting policy, after the delivery, return to step (D4), as the current limiting policy requested start time stream i.e., the forwarding layer subsequent multicast packets associated pa C ket (key) is discarded.
- the foregoing method may further have the following features:
- the following further includes the following method for configuring a multicast traffic limiting policy:
- a different traffic limiting requirement is obtained by artificial setting or by a predefined policy algorithm, and a multicast traffic limiting policy table LI (type, key) indexed by the current limiting type typet and the key value is formed at the multicast protocol layer. ) ;
- the protocol layer synchronizes the formed multicast traffic limiting policy to the forwarding layer
- the above method may further have the following features: In the steps (d7) and (d8), when the protocol layer generates a new multicast routing entry, if the new entry has an upload flag Upsend, the protocol layer also retrieves the In this case, the traffic limiting policy corresponding to the key is applied to the new routing entry M(key), and the P_M(key) with the limited traffic policy is obtained, and then synchronized to the forwarding layer.
- the above method may also have the following features: the forwarding flag of the temporary forwarding route entry T_M (key) generated in the step (d8) is N, and the subsequent multicast data packet (key) will be discarded. .
- the foregoing method may further have the following features: the assertion mechanism current limiting policy is a fixed current limiting manner that does not distinguish the key value; or the assertion mechanism current limiting policy is a corresponding limit in the case that is retrieved according to the key value.
- the assertion mechanism current limiting policy is a fixed current limiting manner that does not distinguish the key value; or the assertion mechanism current limiting policy is a corresponding limit in the case that is retrieved according to the key value.
- the present invention adopts a policy-based multicast traffic limiting processing method, which can distinguish different multicast service flows and according to different causes of the multicast service flow impact protocol Cpu, respectively adopt corresponding current limiting. method.
- a policy-based multicast traffic limiting processing method which can distinguish different multicast service flows and according to different causes of the multicast service flow impact protocol Cpu, respectively adopt corresponding current limiting. method.
- it has the following advantages: A, preventing the entire IP communication device system from being overloaded due to the multicast stream drive; B, reducing the impact of multicast protocol processing on multicast forwarding, and improving The efficiency of multicast forwarding; C.
- Policy-based traffic limiting method for distinguishing multicast traffic flow types, that is, preventing small traffic multicast flows from being blocked due to traffic limiting, and providing different traffic flows according to different services
- the characteristics and requirements provide different current limiting strategies, which increases the flexibility of the system. D. Due to reasonable current limiting, the burden on the multicast routing processing of the communication device is reduced, so that the communication device requires hardware such as CPU and memory. It will be reduced, which will reduce the cost of the equipment.
- FIG. 1 is a schematic diagram of a multicast routing system according to an embodiment of the present invention.
- FIG. 2 is a schematic diagram of an overall processing method for current limiting according to an embodiment of the present invention.
- FIG. 3 is a flowchart of processing of a first multicast traffic limiting sub-module when there is no multicast forwarding entry in the embodiment of the present invention.
- 4 is a flowchart of processing of a second multicast traffic limiting sub-module when there is a corresponding multicast routing entry in the embodiment of the present invention, but a protocol needs to send a normal multicast data packet to the protocol Cpu.
- FIG. 5 is a flowchart of processing a third multicast traffic limiting sub-module when there is a corresponding multicast routing entry in the embodiment of the present invention, and the multicast protocol Assert state machine requests the multicast data packet to be sent to the protocol Cpu.
- FIG. 6 is a schematic diagram of a process of configuring a multicast traffic limiting policy according to an embodiment of the present invention.
- the traditional multicast routing system includes a multicast forwarding layer and a multicast protocol layer.
- the multicast forwarding layer has a multicast routing table that can receive multicast protocol packets and multicast data packets.
- the broadcast route is forwarded and sent to the multicast protocol layer for processing when needed.
- the multicast protocol layer can process multicast data messages to form a new multicast routing table and synchronize to the forwarding layer.
- the multicast current limiting module is embedded in the system, and is composed of a protocol part embedded in the multicast protocol layer and a forwarding part embedded in the multicast forwarding layer.
- the multicast traffic limiting module is used in the forwarding layer to trigger and perform multicast routing forwarding after the traffic limiting policy is applied.
- the multicast traffic limiting module is used in the protocol layer to form an IP multicast forwarding routing table based on the traffic limiting policy that can distinguish multiple services.
- the multicast current limiting module can be divided into first, second, and third current limiting sub-modules for processing in different current limiting situations. Each module will be described in detail below, and a multicast traffic limiting policy is also required.
- a control module configured to complete a traffic limiting policy, and generate a multicast traffic limiting policy table LI (type, key) and L2 (type, key) indexed by a key value and a traffic limiting type on the protocol layer and the forwarding layer,
- LI type, key
- L2 type, key
- the result of the traffic limiting policy is that the data packet of the service type whose key value is the key is limited to the size of the CPU to be sent and the size of the data sent, and the granularity of the delivery is performed in the current limiting function. Time, the longer the current limit time, the larger the granularity of the current limit.
- the multicast data is forwarded by using the source address and the group address as the key value.
- different multicast service flows are distinguished by the source address and the group address, that is, the multicast service flow type is distinguished by the key value.
- the key is used to retrieve and search for policies, so that in various situations where current limiting is required, the traffic limiting policy can be applied to distinguish different traffic flows.
- the specific current limiting policy is defined and set according to different network environments and different requirements.
- the cause of the multicast data packet being sent to the protocol CPU is different, resulting in different current limiting processing.
- the reason for sending the protocol Cpu to the three multicast data packets that may exist in the IP multicast using the PIM-SM protocol is to call different current limiting submodules for processing.
- the overall processing method of the current limiting process in this embodiment includes the following steps: Step 110: A multicast data packet with a key value of (S, G) is forwarded to the multicast forwarding layer; Step 120, multicast routing The forwarding system first determines whether the forwarding key value of the multicast data packet can be matched to the corresponding forwarding route. If the matching does not match, the multicast forwarding entry for the key is not formed at this time.
- the driving mode is such that the multicast protocol layer can form a suitable multicast forwarding route entry, in this case, step 130 is performed; if the corresponding forwarding route can be matched, step 140 is performed;
- Step 130 After the traffic restriction of the protocol Cpu is sent to the multicast data packet, the first multicast traffic limiting submodule is called to be processed (the first type of traffic limiting is required), and then the process ends.
- Step 140 continue to determine whether the forwarding conditions are met, such as Rpf (reverse path forwarding) check, if yes, go to step 150, otherwise go to step 170;
- Rpf reverse path forwarding
- Step 150 Forward the multicast data packet, and determine whether the forwarding entry itself needs to be sent to the protocol Cpu while forwarding the data packet. If the packet needs to be sent, perform the next step, otherwise, no flow restriction is required, and the process ends;
- Step 160 After the second multicast traffic limiting submodule is processed (the second type of traffic limiting is required), the process ends.
- Step 170 If the forwarding entry is matched, it is determined whether the Assert state machine is required to be met (the Rpf check fails and the outbound interface receives the data packet). If yes, the multicast data packet is sent to the protocol Cpu. Perform the next step; otherwise, go to step 190;
- Step 180 After the third multicast current limiting submodule is processed (the third type of current limiting is required), the process ends.
- Step 190 Discard the multicast data packet and end.
- the current limit type is also divided into three types, corresponding to the above three current limit cases.
- the method for limiting the flow of the protocol Cpu is sent by the multicast data packet.
- the multicast transmission data packet cannot match any multicast forwarding route entry, the multicast data packet needs to be forwarded to the multicast protocol for processing, which is used to drive the PIM-SM register process.
- the multicast routing table is formed not by the multicast protocol packet, but by the multicast protocol. In this case, if the multicast data packet traffic that meets the above conditions is large, it will cause an impact on the Cpu where the multicast protocol resides.
- the first multicast traffic limiting sub-module is processed according to the following steps in FIG. 3, that is, step 130 in FIG. 2 can be further divided into the following steps:
- Step 210 Send the packet (key) of the multicast data packet arriving at the forwarding layer to the protocol Cpu. Then, the forwarding layer and the protocol layer are simultaneously processed:
- Step 220a The forwarding layer searches the multicast traffic limiting policy table L2 (type, key) according to the key value and the current limiting type, and generates a temporary forwarding routing entry T_M with an inbound interface with a limited flow policy of Null and a forwarding flag of N. (key), the subsequent related multicast data packet (key) is discarded, and is not sent to the protocol CPU to implement current limiting.
- the protocol layer drives the protocol state machine according to the received multicast data message, and is used to generate a multicast routing forwarding entry M (key);
- Step 230 if the normal forwarding entry M(key) of the key value can be generated, step 240 is performed, otherwise step 250 is performed;
- step 240 the entry is synchronized to the forwarding layer, and the forwarding layer updates the T_M (key) with the newly generated M (key) routing entry to enter the normal multicast routing forwarding, and the processing ends;
- Step 250 When no new M (key) routing entry is generated, the forwarding layer continues to limit the current according to the current limiting policy attached to the T-M (key), and determines when to delete the T-M (key) according to the policy. After the time T), the current limit is ended. • It can be seen that the multicast routing table is introduced in the multicast forwarding mode, and the service flow can be differentiated by the policy operation of the routing table. The multicast protocol process that blocks large-traffic multicast data packets is sent and reduced. The impact of the agreement in the Cpu.
- the multicast data packet When the multicast data packet can be matched to the multicast forwarding route entry, the multicast data packet is forwarded according to certain rules. However, if the protocol requires that the multicast data message at this time also be handled by the multicast protocol, for example, when a switch between Spt and Rpt occurs. If the traffic of the multicast data packets that meet the conditions is large at this time, the impact on the Cpu where the multicast protocol resides is also caused. In this case, the second multicast traffic limiting sub-module implements the traffic limiting process for different multicast service flows by the following steps, as shown in Figure 4:
- Step 310 After receiving the data packet whose key value is Key, the multicast protocol layer generates a multicast routing entry M(key) according to the protocol state machine.
- Step 320 If the multicast routing entry needs to notify the forwarding layer to send the multicast data packet with the key key value, that is, the Upsend flag is set in the routing entry M (key), go to step 340, if the routing entry M (key) Without the Upsend flag, go to step 330;
- Step 330 Synchronize M (key) to the multicast forwarding layer, use M (key) to generate or update the forwarding routing table, and enter the normal routing forwarding process.
- the multicast data stream whose key value is key is no longer sent to the multicast protocol Cpu. End multicast flow control;
- Step 340 the protocol layer searches the multicast traffic limiting policy table L1 (type, key) according to the key value and the current limiting type, and queries the traffic limiting policy F that matches the key value;
- P-M (key) of the strategy
- the result of the current limiting strategy is whether to limit the flow and the granularity of the current limit. This is indicated by the setting and recovery of the Upsend flag, and the length of the set time.
- the Upsend flag is attached to the forwarding routing table of the type of service data flow, thereby informing the forwarding layer to receive the data packet of the type. After that, whether to send and how many data messages are sent.
- Step 360 Synchronize P-M (key) to the multicast forwarding layer, and after receiving the P-M(ke y ) entry, the multicast forwarding layer forms a multicast routing forwarding entry.
- Step 370 When the forwarding layer receives the multicast data packet (key) whose forwarding key value is key, it matches the P-M (key) route forwarding entry.
- Step 380 when forwarding pa C ket (k e y) , according P- M (key) limiting policy also need to decide whether to send the protocol Cpu, i.e. start time and whether the feed stream, the feed if desired, Perform the next step, otherwise, perform step 400;
- Step 390 The multicast data packet whose key value is the key is sent to the multicast protocol Cpu, and the process returns to step 310, and the foregoing process is repeated, but the generated M (key) content and the used current limiting policy are different; If the current limiting policy is required to start the traffic limiting, the forwarding layer discards the subsequent multicast data packet (key).
- the third case that is, the current limiting method that matches the corresponding multicast forwarding entry and meets the requirements of the Assert state machine of the multicast protocol to send the multicast data packet to the protocol Cpu.
- the interface that receives the multicast data packet is not the inbound interface of the routing entry, but the outgoing multicast routing entry.
- the interface fails to pass the Rpf check, that is, it meets the Assert state machine requirements of the multicast protocol.
- the multicast protocol is used to trigger the multicast Assert state machine, and is not used for forwarding. Therefore, the multicast data packet may be impacted on the multicast protocol CPU.
- the third multicast traffic limiting sub-module is processed according to the following steps in FIG. 5, that is, step 180 in FIG. 2 can be further divided into the following steps:
- the Assert traffic limiting policy is directly used in the forwarding layer.
- the policy can be a fixed traffic limiting function, and the key traffic limiting policy table L2 can be retrieved according to the key value and the current limiting type. (type 5 key) obtain the corresponding current limiting policy;
- Step 520 determining whether the policy requires packet (key) to be sent to the multicast protocol Cpu, if yes, send the packet (key), perform the next step, otherwise step 540;
- Step 530 The multicast protocol layer receives the pa C k e t (key), forms a new multicast routing entry M′(key:) according to the normal protocol state machine, and synchronizes the M′ (key) to the multicast forwarding. Layer, the forwarding layer forwards and forwards according to the entry, and ends;
- Step 540 masking packet(key), and ending.
- a current limiting flag capable of distinguishing the Assert condition may be introduced, according to the setting.
- the Assert traffic limiting policy sets and clears the flag to limit the impact of the multicast data packets used to trigger the Assert state machine on the Cpu where the multicast protocol resides.
- Figure 6 shows the multicast traffic limiting policy configuration method, including the following steps:
- Step 610 Configure a multicast traffic limiting policy (type, key) for distinguishing the service flow at the multicast protocol layer, and form a multicast traffic limiting policy table LI (type 5 key) of the protocol layer indexed by the key and the current limiting type;
- the traffic limiting policy can be set by artificial configuration, or different current limiting requirements can be obtained through a predefined policy algorithm. Different traffic limiting granularities can be adopted for different service flows.
- Step 620 The protocol layer synchronizes the formed multicast traffic limiting policy to the forwarding layer.
- Step 630 Form a multicast traffic limiting policy table indexed by a key and a current limiting type in the forwarding layer.
- the traffic limiting policy is applied to the multicast forwarding layer in two ways: First, the traffic limiting policy is directly applied to the related multicast routing entries prepared for synchronization to the forwarding layer through the protocol layer, so that the multicast The routing entry used by the forwarding layer for forwarding is already an entry with a traffic limiting policy.
- the second multicast traffic limiting sub-module implements this function.
- the other is that the multicast protocol directly synchronizes the traffic limiting policy to the forwarding layer.
- the layer forms a multicast traffic limiting policy table L (type, key), and the first and third multicast traffic limiting submodules perform current limiting by calling the policy table.
- the protocol layer forms a new multicast routing entry P_M(key) with a differentiated service type (key) and a traffic limiting policy (L) and synchronizes to the forwarding layer, and then the forwarding layer directly according to the key.
- the method is the same as the above embodiment only for the first case, that is, because the multicast data packet sent by the multicast routing entry is sent to the protocol Cpu for traffic limiting.
- the protocol requires that the multicast data packet sent by the protocol Cpu is sent to the protocol CPU to perform current limiting. .
- the method is the same as the above embodiment.
- the multicast data packet is sent to the protocol Cpu for current limiting. .
- the method is the same as the above embodiment.
- the present invention is directed to IP multicast using the Sparse Mode Independent Multicast Protocol (PIM-SM), the state machine, processing flow, and message format of the protocol are not changed without changing the protocol itself.
- PIM-SM Sparse Mode Independent Multicast Protocol
- the present invention can also be applied to IP protocols and communication devices (including wired and wireless devices) of various routing processing modes.
- the present invention introduces a policy-based multicast traffic limiting processing method, which can distinguish different multicast service flows and according to different multicast traffic flow impact protocols.
- the reason for the Cpu is to adopt a current limiting method.
- A preventing the entire IP communication device system from being overloaded due to the multicast stream drive
- B reducing the impact of multicast protocol processing on multicast forwarding, and improving The efficiency of multicast forwarding
- C Policy-based traffic limiting method for distinguishing multicast traffic types, that is, preventing small-flow multicast flows from being blocked due to traffic limiting, and also according to characteristics of different traffic flows Different current limiting strategies are provided with the requirements, which increases the flexibility of the system.
- D Due to reasonable current limiting, the burden on the multicast routing processing of the communication device is reduced, so that the communication device has lower requirements on hardware such as CPU and memory, thereby reducing the cost of the device.
- the invention can be applied to a communication system adopting the IP multicast mode, and different strategies for different multicast service flows are adopted to avoid the load impact of the large-flow multi-service IP multicast data stream on the IP communication device.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
区分多业务的抗 IP组播数据流冲击通信系统的方法 技术领域
本发明涉及 IP组播在有线和无线等 IP通信系统中的实现, 尤其涉及防 止大流量组播数据流冲击通讯系统的方法。
背景技术
IP组播技术有效地解决了单点发送多点接收的问题,实现了 IP 网络中 点到多点的高效数据传送, 能够大量节约网络带宽、 降低网络负载。 作为一 种与单播和广播并列的通信方式, 组播的意义不仅在于此。 更重要的是, 可 以利用网络的组播特性方便地提供一些新的增值业务, 包括在线直播、 网络 电视、 远程教育、 远程医疗、 网络电台、 实时视频会议等互联网的信息服务 领域。由于 IP组播的上述特性使其在有线网络和无线有线领域都有巨大的应 用前景。
目前 IP通信系统中路由实现分为两种模式: 一, 协议与转发串行处理; 二, 协议与转发并行处理。 为实现快速转发, 普遍采用转发与协议并行处理 的设计模式。 无论是并行处理模式还是串行处理模式, 都要求协议处理和转 发要由不同的进程处理。协议处理的复杂度和对 Cpu的资源占用率要远远高 于转发处理。
由于 PIM-SM (稀疏模式独立协议组播) 的数据流驱动特征, 会造成对
Cpu的冲击, 导致系统性能受到影响, 其原因如下:
对于采用协议和转发串行处理模式的 IP通信设备, 当发生组播流驱动 时, 数据报文被全部上交给组播协议处理。 如果此时的组播数据流很大时, Cpu需要根据组播协议对每一个数据报文进行相应处理, 会占用大量的 cpu 资源, 导致系统整体性能直线下降。 对于釆用协议和转发并行处理的 IP通讯设备,又分为两种架构:一是集 中式架构; 二是分布式架构。 二者的转发都独立于协议, 转发运行在专用的 网络处理器上。 在集中式架构中, 协议处理器和转发处理器共用同一内存区
域; 在分布式架构中, 协议处理器和转发处理器有各自的内存区域, 存在着 板间通信。 对于集中式的并行处理模式, 组播流驱动对系统带来的影响与串 行处理模式相近, 但对于分布式的并行处理模式, 在此基础上, 组播流驱动 还会导致对板间通信的冲击, 如果处理的不恰当, 对系统的影响会更大。
因此,如果采用简单的不区分组播数据流的组播数据流上送 Cpu的流量 控制方法, 会产生不同的组播业务流同时发生流驱动时, 大流量的组播数据 流淹没小流量的组播数据流, 从而导致组播转发断流。
限流是一种防止 IP通讯设备过载运行的方法,但必然会由于限流而损失 部分数据报文。 IP组播协议是一种同应用紧密相关的路由协议, 不同的组播 业务流可能对转发服务质量的要求是不同的, 因此需要对不同服务质量的组 播数据报文, 采用不同的限流策略, 这样才能将由于限流带来的负面降低到 最低。
发明内容
本发明要解决的技术问题是提供一种区分多业务的抗 IP组播数据流冲 击通信系统的方法, 能够区分不同的组播业务流采有相应策略, 避免大流量 多业务 IP组播数据流对 IP通讯设备的负载冲击。
为了解决上述技术问题,本发明提供了一种区分多业务的抗 IP组播数据 流冲击通信系统的方法, 包括以下步骤:
(al )键值为 key的组播数据报文 packet(key)到达转发层, 没有找到匹 配的组播路由条目, 将组播数据报文 paCket(key)上送协议处理器;
(a2)协议层根据收到的组播数据报文驱动协议状态机, 用于生成组播 路由转发条目 M (key) ; 同时, 转发层在配置的组播限流策略中检索该情 况下与 key对应的限流策略, 生成临时转发路由条目 T— M(key),利用该条目 对后续的组播数据报文 packet(key)进行限流;
(a3 )如果协议层能够生成 key值的正常转发条目 M(key), 将该条目同 步到转发层, 转发层用 M (key)更新 T— M(key), 进入正常转发; 否则, 转 发层根据 T—M(key)附带的限流策略, 继续限流, 并决定何时结束限流。
进一步地, 上述方法还可具有以下特点: 所述 骤 (a2) 中生成的临时 转发路由条目 T—M(key)的转发标志为 N, 后续的组播数据报文 packet(key) 将被丢弃。
为了解决上述技术问题,本发明又提供了一种区分多业务的抗 IP组播数 据流冲击通信系统的方法, 包括以下步骤-
(bl )协议层根据协议状态机生成组播路由条目 M(key),如果该条目中 置有上送标志 Upsend, 执行下一步; 否则, 将 M(key)同步到转发层, 生成 或更新转发路由表, 进入正常路由转发流程, 组播流控结束;
(b2)协议层在配置的组播限流策略中检索该情况下与 key对应的限流 策略, 应用于 M(key), 使其成为带有限流策略的 P— M(key), 然后将其同步 到转发层;
(b3 )转发层收到组播数据报文 packet(key)时, 找到匹配的组播路由条 目,如果满足转发条件,首先转发 paCket(key),并根据组播数据报文 P—M(key) 的限流策略实现对其上送协议处理器的限流。
进一步地, 上述方法还可具有以下特点: 所述步骤(b3 )后还包括步骤 (b4):如果根据 P—M(key)的限流策略需要将组播数据报文 paCket(key)上送 到协议处理器, 则在上送后, 返回执行步骤(M ) 。 ' 进一步地, 上述方法还可具有以下特点: 所述步骤(b2) 中, 是通过将 检索到的限流策略应用于上送标志 Upsend 得到具有策略的上送标志 Upsend' , 从而得到相应的 P— M(key)。
进一步地, 上述方法还可具有以下特点: 所述步骤(b4) 中, 如该限流 策略还要求启动即时限流, 则在将组播数据报文 packet(key)上送到协议处理 器后, 将后续相关的组播数据报文 packet(key)丢弃。
为了解决上述技术问题,本发明还提供了一种区分多业务的抗 IP组播数 据流冲击通信系统的方法, 包括以下步骤:
(cl )键值为 key的组播数据报文 packet(key)到达转发层, 匹配到相应
的组播转发条目, 且满足组播协议的 Assert (断言机制)状态机要求;
(c2)在转发层直接使用预先设置的断言机制限流策略, 判断策略是否 要求 packet(key)上送到组播协议处理器, 如要求上送, 上送数据报文 packet(key), 然后协议层按照协议状态机形成新的组播路由条目, 同步到转 发层; 如不要求上送, 则屏蔽组播数据报文 paCket(key:)。
进一步地, 上述方法还可具有以下特点: 所述断言机制限流策略是不区 分键值的固定限流方式。
进一步地, 上述方法还可具有以下特点: 所述断言机制限流策略是根据 key值检索到的该情况下相应的限流策略。
进一步地, 上述方法还可具有以下特点: 该方法引入了能够区分断言机 制情况的限流标志, 根据所述断言机制限流策略设置和清除该标志, 限制用 于触发断言机制状态机的组播数据报文对组播协议所在 Cpu的冲击。
为了解决上述技术问题,本发明又提供了一种区分多业务的抗 IP组播数 据流冲击通信系统的方法, 包括以下步骤:
(dl )键值为 key的组播数据报文 pack key)到达转发层, 转发层判断 其是否能够匹配到相应的转发路由, 如果能, 执行下一步, 否则, 执行步骤 (d8) ;
(d2)判断是否满足转发条件, 如满足, 转发层首先进入正常转发流程 转发该 paCket(key), 然后执行下一步, 否则执行步骤 (d6) ;
(d3 )判断协议是否要求将组播数据报文 packet(key)上送协议处理器, 如果是, 转发层将 packet(key)上送协议层, 执行下一步, 否则, 不进行限流, 结束;
(d4)协议层接收到转发层上送的组播数据报文 packet(key), 驱动协议 状态机生成新的组播路由条目 M (key),如果 M(key)置有上送标志 Upsend, 执行下一步; 否则, 将 M(key)同步到转发层, 转发层根据新的组播路由条目 M (key)对收到的组播数据报文 packet(key)进行转发, 结束;
(d5)协议层检索该情况下与 key对应的限流策略并应用到 M(key), 得
到带有限流策略的 P—M(key)并将其同步到转发层, 转发层根据 P— M(key)的 限流策略实现对组播数据报文 packet(key)上送协议处理器的限流, 结束;
(d6)判断是否满足组播协议的断言机制状态机要求, 如果满足, 执行 下一步; 如果不满足, 丢弃组播数据报文 packet(key), 结束;
( d7 ) 在转发层使用预先设置的断言机制限流策略, 如果策略要求 packet(key)上送协议处理器, 则上送数据报文 packet(key), 协议层按照协议 状态机形成新的组播路由条目同步到转发层, 转发层再根据该条目进行转发 和上送, 结束; 如果策略不要求上送, 则屏蔽该组播数据报文 packet key:), 结束;
(d8)将组播数据报文 packet(key)上送协议处理器, 协议层驱动协议状 态机以生成新的组播路由转发条目; 同时转发层检索该情况下与 key对应的 限流策略,生成临时转发路由条目 T—M(key),根据该条目对后续的组播数据 报文 packet(key)进行限流;
(d9)如果生成了新的组播路由转发条目, 同步到转发层, 转发层用该 条目更新 T—M(key), 进入正常转发流程, 结束; 如果不能生成 M(key), 转 发层根据 T— M(key)附带的限流策略继续限流, 并根据策略决定何时限流结 束。
进一步地, 上述方法还可具有以下特点: 所述步骤(d5 ) 中, 如果根据 P— M(key)的限流策略需要将组播数据报文 packet(key)上送到协议处理器, 则 在上送后, 返回执行步骤(d4) , 如该限流策略还要求启动即时限流, 则转 发层将后续相关的组播数据报文 paCket(key)丢弃。
进一步地, 上述方法还可具有以下特点: 还包括以下对组播限流策略的 配置方法:
( el ) 通过人为设定或者通过预先定义的策略算法获得不同的限流需 求, 在组播协议层形成以限流类型 typet和键值 key为索引的组播限流策略 表 LI (type,key) ;
(e2)协议层将形成的组播限流策略同步到转发层;
(e3 )在转发层形成以键值 key和限流类型 type为索引的组播限流策略
¾ L2 (type,key) 。
进一步地, 上述方法还可具有以下特点: 所述步骤 (d7)和 (d8) 中, 协议层生成新的组播路由条目时,如果该新条目置有上送标志 Upsend,协议 层也检索该情况下与 key对应的限流策略并应用到该新的路由条目 M(key), 得到带有限流策略的 P_M(key), 再将其同步到转发层。
进一步地, 上述方法还可具有以下特点: 所述步骤(d8) 中生成的临时 转发路由条目 T—M(key)的转发标志为 N, 后续的组播数据报文 packet(key) 将被丢弃。
进一步地, 上述方法还可具有以下特点: 所述断言机制限流策略是不区 分键值的固定限流方式; 或者所述断言机制限流策略是根据 key值检索到的 该情况下相应的限流策略。
由上可知, 本发明通过引入基于策略的组播限流处理方法, 能够区分不 同的组播业务流和根据不同的导致组播业务流冲击协议 Cpu的原因,分别采 取与之相适应的限流方法。 与传统的 PIM— SM组播实现相比具有以下优点: A, 防止了因为组播流驱动原因导致的整个 IP通讯设备系统过载; B, 降低 了组播协议处理对组播转发的影响, 提高了组播转发的效率; C, 基于策略 的区分组播业务流类型的限流方法, 即防止了小流量组播流因为限流被屏蔽 形成断流的, 也提供了能够根据不同的业务流的特性和需求提供不同的限流 策略, 增加了系统的灵活性; D, 由于合理的限流, 使得通讯设备对组播路 由处理的负担降低, 这样就通讯设备对 CPU和内存等硬件的要求就会降低, 从而可以降低设备的成本。
附图概述
图 1是本发明实施例组播路由系统的示意图。
图 2是本发明实施例限流的整体处理方法的示意图。
图 3是本发明实施例没有组播转发条目时, 第一组播限流子模块的处理 流程图。
图 4是本发明实施例有相应组播路由条目, 但有协议需要正常组播数据 报文上送协议 Cpu时, 第二组播限流子模块的处理流程图。
图 5是本发明实施例有相应组播路由条目, 且组播协议 Assert状态机要 求组播数据报文上送协议 Cpu时, 第三组播限流子模块的处理流程图。
图 6是本发明实施例组播限流策略配置过程的示意图。
本发明的最佳实施方式
下面结合附图对本实施例基于策略的区分多业务 IP组播数据流的抗组 播数据流冲击 IP通讯设备的方法进行具体的说明。
如图 1所示, 传统的组播路由系统包括组播转发层和组播协议层, 组播 转发层中有组播路由表, 可接收组播协议报文和组播数据报文, 按组播路由 进行转发, 需要时须上送到组播协议层处理。 组播协议层可处理组播数据报 文形成新的组播路由表并同步到转发层。 为实现对组播数据报文上送协议
Cpu的限流, 本实施例在系统中嵌入了组播限流模块, 由嵌入在组播协议层 的协议部分和嵌入在组播转发层的转发部分组成。 组播限流模块在转发层的 部分主要用于触发并执行运用了限流策略后形成的组播路由转发。 组播限流 模块在协议层的部分用于形成能够区分多业务的基于限流策略的 IP组播转 发路由表。 针对在不同限流情况下的处理, 可将该组播限流模块分为第一、 第二和第三限流子模块, 各模块将在下面详细介绍, 此外还需要一个组播限 流策略控制模块, 用于完成限流策略的配置, 在协议层和转发层上生成以键 值和限流类型为索引的组播限流策略表 LI (type,key)和 L2 (type,key) , 供上述限流子模块调用, 限流策略作用的结果是决定对键值为 key的业务类 型的数据报文是否限制其上送 Cpu处理以及上送的粒度,上送粒度表现在限 流的作用时间, 限流时间越长, 限流的粒度就越大。
组播数据是以源地址和组地址为键值进行路由转发的,同时,区分不同的 组播业务流也是通过源地址和组地址, 即通过键值来区分组播业务流类型, 本实施例通过 key来检索和査找策略, 从而使得需要限流的各种情况下, 限 流策略能够区分不同的业务流而应用。具体的限流策略根据不同的网络环境 和不同的需求定义和设置。
引起组播数据报文上送协议 Cpu的原因是不同的,导致了限流处理的不 同。 本实施例针对采用 PIM-SM协议的 IP组播中可能存在的三种组播数据 报文上送协议 Cpu的原因, 分别调用不同的限流子模块进行处理。如图 2所 示, 本实施例限流的整体处理方法包括以下步骤- 步骤 110, 一个转发 key值为 (S,G) 的组播数据报文到达组播转发层; 步骤 120, 组播路由转发系统首先判断根据该组播数据报文的转发 key 值是否能够匹配到相应的转发路由, 如果匹配不到, 说明此时还没有形成用 于该 key的组播转发项, 需要通过组播流驱动方式, 使得组播协议层能够形 成合适的组播转发路由条目, 在这种情况下, 执行步骤 130; 如果能够匹配 到相应的转发路由, 执行步骤 140;
步骤 130, 为实现对组播数据报文上送协议 Cpu的限流, 调用第一组播 限流子模块处理 (第一种需限流的情况) 后, 结束;
步骤 140, 继续判断是否满足转发条件, 如进行 Rpf (逆向路径转发) 检查, 如果满足, 执行步骤 150, 否则执行步骤 170;
步骤 150, 转发组播数据报文, 并判断该转发条目本身是否需要在转发 数据报文的同时依然上送协议 Cpu, 如果需要上送, 执行下一步, 否则无需 限流, 结束;
步骤 160, 调用第二组播限流子模块处理 (第二种需限流的情况)后, 结束;
步骤 170,如果匹配到转发条目,则判断是否满足 Assert状态机要求(指 Rpf检查不通过且出接口收到数据报文) , 如果满足, 则需将该组播数据报 文上送协议 Cpu, 执行下一步; 否则, 执行步骤 190;
步骤 180, 调用第三组播限流子模块处理 (第三种需限流的情况)后, 结束;
步骤 190, 丢弃组播数据报文, 结束。
在以上三种情况下, 为实现组播限流的策略化, 组播限流模块的几个子 模块都需调用组播限流策略表, 调用时, 除键值外, 还要根据限流类型进行
检索, 限流类型也分为三种, 分别对应于以上三种限流情况。
下面分别说明在引起组播数据流冲击 Cpu的三种不同情况下,各个组播 限流子模块的处理方法。
第一种情况, 因没有组播路由条目导致的组播数据报文上送协议 Cpu的 限流方法。
由于该组播传送数据包不能匹配任何组播转发路由条目, 则需要将该组 播数据报文交给组播协议进行处理, 用于驱动 PIM-SM的 Register过程。 从 路由协议层面看, 此时组播路由表的形成不是通过组播协议报文驱动形成 的, 而是由组播协议通过处理组播数据报文形成。 在此情况下, 如果满足上 述条件的组播数据报文流量很大时, 会造成对组播协议所在 Cpu的冲击。 为 解决该问题, 第一组播限流子模块按图 3中以下步骤进行处理, 即图 2中的 步骤 130可以进一步分为以下步骤:
步骤 210, 将到达转发层的组播数据报文 packet(key)上送协议 Cpu; 然后, 转发层和协议层将同时进行处理:
步骤 220a, 转发层根据 key 值和限流类型检索组播限流策略表 L2 (type,key) , 生成一个附带有限流策略的入接口为 Null且转发标志为 N的 临时转发路由条目 T— M(key), 后续相关的组播数据报文 packet(key)被丢弃, 不再上送协议 Cpu, 实现限流;
同时, 步骤 220b, 协议层根据收到的组播数据报文驱动协议状态机, 用 于生成组播路由转发条目 M (key) ;
步骤 230, 如果能够生成 key值的正常转发条目 M(key), 执行步骤 240, 否则执行步骤 250;
步骤 240, 将该条目同步到转发层, 转发层用新生成的 M (key)路由条 目更新 T_M(key), 进入正常的组播路由转发, 处理结束;
步骤 250, 没有生成新的 M(key)路由条目时,转发层根据 T— M(key)附带 的限流策略, 继续限流, 并根据策略决定何时删除 T— M(key) (如延时时间 T 后) , 结束限流。
• 可见, 通过在组播转发时引入了临时组播路由表, 通过该路由表的策略 操作, 可区分业务流, 屏蔽大流量组播数据报文的组播协议进程上送, 降低 对组播协议所在 Cpu的冲击。
第二种情况, 即有相应组播路由条目, 但协议要求正常组播数据报文上 送协议 Cpu导致的组播数据报文上送协议 Cpu的限流方法。
当组播传送数据报文能够匹配到组播转发路由条目时, 组播数据报文依 一定规则转发。 但如果协议要求此时的组播数据报文同时也要交由组播协议 处理, 比如在发生 Spt和 Rpt间的相互切换等情况下。 如果此时满足条件的 组播数据报文的流量很大, 也会造成对组播协议所在 Cpu的冲击。这种情况 下, 由第二组播限流子模块通过以下步骤实现区分不同的组播业务流的限流 处理, 如图 4所示:
步骤 310, 组播协议层收到键值为 Key的数据报文后, 根据协议状态机 生成组播路由条目 M(key);
步骤 320, 如果该组播路由条目需要通知转发层上送 key键值的组播数 据报文, 即路由条目 M(key)中置有 Upsend标志, 执行步骤 340, 如果路由 条目 M(key)中没有 Upsend标志, 执行步骤 330;
步骤 330, 将 M(key)同步给组播转发层, 用 M(key)生成或更新转发路由 表, 进入正常路由转发流程, 键值为 key 的组播数据流不再上送组播协议 Cpu, 结束组播流控;
步骤 340, 协议层根据 key 值和限流类型检索组播限流策略表 L1 (type,key) , 查询与 key值匹配的限流策略 F;
步骤 350, 将限流策略 F应用于上送标志 Upsend, 得到具有策略的上送 标志 Upsend' , 即 Upsend,=F(Upsend), 相应地, 此时的 M(key)已经成为了带 有限流策略的 P— M(key);
限流策略的结果是是否限流以及限流的粒度。 这里是通过对 Upsend标 志的置位和恢复, 以及置位的时间的长短等表示。 Upsend标志被附加到该类 型业务数据流的转发路由表上, 从而通知转发层在接收到该类型的数据报文
后, 是否上送以及上送多少数据报文。
步骤 360, 同步 P—M(key)到组播转发层, 组播转发层接收到 P— M(key) 条目后, 形成组播路由转发条目;
步骤 370,当转发层收到转发键值为 key的组播数据报文 packet(key)时, 匹配到 P— M(key)路由转发条目;
步骤 380, 在转发 paCket(key)时, 根据 P— M(key)的限流策略决定是否同 时需要上送协议 Cpu, 以及上送后是否启动即时限流, 如果需要上送, 执行 下一步, 否则, 执行步骤 400;
步骤 390, 键值为 Key的组播数据报文被上送到组播协议 Cpu, 返回步 骤 310, 重复上述流程, 只是生成的 M(key)的内容和运用的限流策略会有所 不同; 如该限流策略还要求启动即时限流, 则转发层将后续相关的组播数据 报文 packet(key)丢弃;
步骤 400, 策略性地屏蔽键值为 key的组播数据报文上送协议 Cpu。 可以看出, 本实施例在传统的 UpSend上送机制基础上, 引入了区分业 务流的上送限流策略, 协议的 UpSend标志用于维持正常的状态机, 而协议 同步到转发层的 Upsend'是基于某种策略 F 的 Upsend 的函数, 即 Upsend'=F(Upsend), 转发通过应用已经具有某种限流策略的 UpSend'实现此 种情况下, 防止组播数据流对组播协议所在 Cpu的冲击的功能。
需要说明的是, 本实施例中, 对于第一种情况下(步骤 220b)或者后面 的第三种情况下 (步骤 530) 或者其它情况下在协议层产生的路由条目, 如 果满足应用第二种限流策略的条件, 即 M(key)带有了 upsend标志, 则当它 产生时, 也为它赋予了第二种限流策略, 此时 M(key)就变成了 P— M(key)。 P_M(key)再同步到转发层作为转发条目。
第三种情况, 即匹配到相应的组播转发条目, 且满足组播协议的 Assert 状态机要求所导致的组播数据报文上送协议 Cpu处理的限流方法。
当组播转发收到的组播数据报文, 虽然匹配到组播路由条目, 但由于收 到组播数据报文的接口不是该路由条目的入接口, 而是该组播路由条目的出
接口, Rpf检査未通过, 即满足组播协议的 Assert状态机要求。 对于这种组 播数据报文, 要交给组播协议用于触发组播 Assert状态机, 并不用于转发, 因而也可能会产生组播数据报文对组播协议 Cpu的冲击。为解决该问题, 第 三组播限流子模块按图 5中以下步骤进行处理, 即图 2中的步骤 180可以进 一步分为以下步骤:
步骤 510, 在转发层直接使用预先定义和设置的 Assert限流策略, 该策 略可以是固定限流, 不区分 key, 也可根据需要实现根据 key值和限流类型 检索组播限流策略表 L2 (type5key)获取相应的限流策略;
步骤 520, 判断策略是否要求 packet(key)上送到组播协议 Cpu, 如果是, 上送 packet(key), 执行下一步, 否则执行步骤 540;
步骤 530, 组播协议层收到 paCket(key), 按照正常的协议状态机形成新 的组播路由条目 M'(key:), 并将 M'(key)同步到组播转发层, 转发层根据该条 目进行转发和上送, 结束;
步骤 540, 屏蔽 packet(key), 结束。
具体地, 限流时可以引入能够区分 Assert情况的限流标志, 根据设置的
Assert限流策略设置和清除该标志, 从而限制用于触发 Assert状态机的组播 数据报文对组播协议所在 Cpu的冲击。
图 6示出了组播限流策略配置方法, 包括以下步骤:
步骤 610, 在组播协议层配置区分业务流的组播限流策略 (type,key) , 形成协议层以 key和限流类型为索引的组播限流策略表 LI (type5key) ; 组 播限流策略可以通过人为配置来设定, 也可以通过预先定义的策略算法获得 不同的限流需求, 对于不同业务流可以采用不同的限流粒度;
步骤 620, 协议层将形成的组播限流策略同步到转发层;
步骤 630, 在转发层形成以 key和限流类型为索引的组播限流策略表 L2
(type,key) 。
本实施例通过两种方式将限流策略应用到组播转发层: 一种是通过协议 层将限流策略直接应用于准备同步到转发层的相关组播路由条目, 使得组播
转发层用于转发的路由条目就已经是具有限流策略的条目, 第二组播限流子 模块实现了该功能; 另一种是组播协议将限流策略直接同步到转发层, 在转 发层形成组播限流策略表 L (type, key),第一和第三组播限流子模块就是通 过调用该策略表进行限流。
可见, 本实施例在组播数据报文 paCket(key)到达转发层时, 根据当前组 播转发的情况进行不同的处理, 对于上述第一种情况和第三种情况, 根据键 值 key, 检索组播限流策略表得到已有的限流策略 L(type,key), 将检索到的 限流策略作用于组播转发和报文上送。 对于上述第二种情况, 协议层形成具 有区分业务类型(key)、具有限流策略(L)的新的组播路由条目 P— M(key) 并同步到转发层, 然后转发层直接根据 key值, 利用已经形成的 P—M(key) 转发和上送, 并可根据策略再次修改 P_M(key)。因此, 这三种情况的处理为 流驱动导致的对协议 Cpu冲击的各种情况分别找到了对应的处理方法,但是 其共同点在于: 能够区分不同的组播业务流而采用相应的限流策略。
需要强调的是, 对于不同的使用需求和网络环境, 上述三种情况下采用 的限流处理方法完全可以分别单独使用, 或者同时采用其中的任意二种。
在另一实施例中, 只针对上述第一种情况, 即因为没有组播路由条目导 致的组播数据报文上送协议 Cpu进行限流, 方法同上述实施例。
在另一实施例中, 只针对上述第二种情况, 即有相应组播路由条目, 但 协议要求正常组播数据报文上送协议 Cpu导致的组播数据报文上送协议 Cpu 进行限流。 方法同上述实施例。
在另一实施例中, 只针对上述第三种情况, 即匹配到相应的组播转发条 目, 且满足组播协议的 Assert状态机要求所导致的组播数据报文上送协议 Cpu进行限流。 方法同上述实施例。
另外, 虽然以上实施例针对的是采用稀疏模式独立组播协议(PIM-SM) 的 IP组播,但在不改变协议本身的前提下(即不改变协议的状态机、处理流 程和报文格式),本发明也能够应用于各种路由处理模式的 IP协议和通讯设 备(包括有线和无线设备)上。
综上所述, 与现有技术相比较, 本发明引入了基于策略的组播限流处理 方法, 能够区分不同的组播业务流和根据不同的导致组播业务流冲击协议
Cpu的原因, 分别采取与之相适应的限流方法。与传统的 PIM—SM组播实现 相比具有以下优点: A, 防止了因为组播流驱动原因导致的整个 IP通讯设备 系统过载; B, 降低了组播协议处理对组播转发的影响, 提高了组播转发的 效率; C, 基于策略的区分组播业务流类型的限流方法, 即防止了小流量组 播流因为限流被屏蔽形成断流的, 也能够根据不同的业务流的特性和需求提 供不同的限流策略, 增加了系统的灵活性。 D, 由于合理的限流, 使得通讯 设备对组播路由处理的负担降低, 这样就通讯设备对 CPU和内存等硬件的 要求就会降低, 从而可以降低设备的成本。
工业实用性
本发明可应用于采用了 IP组播方式的通信系统,区分不同的组播业务流 采有相应策略,避免大流量多业务 IP组播数据流对 IP通讯设备的负载冲击。
Claims
1、 一种区分多业务的抗 IP组播数据流冲击通信系统的方法, 包括以下 步骤:
(al ) 键值为 key的组播数据报文 paCket(key)到达转发层, 没有找到匹 配的组播路由条目, 将组播数据报文 packet(key)上送协议处理器;
(a2) 协议层根据收到的组播数据报文驱动协议状态机以生成组播路由 转发条目 M (key) ; 同时, 转发层在配置的组播限流策略中检索该情况下 与 key对应的限流策略, 生成临时转发路由条目 T— M(key), 利用该条目对后 续的组播数据报文 packet(key)进行限流;
(a3 )如果协议层能够生成 key值的正常转发条目 M(key), 将该条目同 步到转发层, 转发层用 M (key) 更新 T— M(key), 进入正常转发; 否则, 转 发层根据 T—M(key)附带的限流策略, 继续限流, 并决定何时结束限流。
2、 如权利要求 1所述的方法,
其特征在于, 所述步骤(a2)中生成的临时转发路由条目 T—M(key)的转发标 志为 N, 后续的组播数据报文 packet(key)将被丢弃。
3、 一种区分多业务的抗 IP组播数据流冲击通信系统的方法, 包括以下 步骤:
(bl )协议层根据协议状态机生成组播路由条目 M(key), 如果该条目中 置有上送标志 Upsend, 执行下一步; 否则, 将 M(key)同步到转发层, 生成 或更新转发路由表, 进入正常路由转发流程, 组播流控结束;
(b2) 协议层在配置的组播限流策略中检索该情况下与 key对应的限流 策略, 应用于 M(key), 使其成为带有限流策略的 P_M(key), 然后将其同步 到转发层;
(b3 )转发层收到组播数据报文 packet(key)时, 找到匹配的组播路由条 目,如果满足转发条件,首先转发 paCket(key),并根据组播数据报文 P— M(key) 的限流策略实现对其上送协议处理器的限流。
4、 如权利要求 3所述的方法,
其特征在于, 所述步骤(b3 )后还包括步骤(b4) : 如果根据 P— M(key)的限 流策略需要将组播数据报文 packet(key)上送到协议处理器, 则在上送后, 返 回执行步骤 (bl ) 。
5、 如权利要求 3所述的方法,
其特征在于, 所述步骤(b2) 中, 是通过将检索到的限流策略应用于上送标 志 Upsend得到具有策略的上送标志 Upsend', 得到相应的 P—M(key)。
6、 如权利要求 4所述的方法,
其特征在于, 所述步骤(b4) 中, 如该限流策略还要求启动即时限流, 则在 将组播数据报文 paCket(key)上送到协议处理器后, 将后续相关的组播数据报 文 packet(key)丢弃。
7、 一种区分多业务的抗 IP组播数据流冲击通信系统的方法, 包括以下 步骤:
(cl )键值为 key的组播数据报文 packet(key)到达转发层, 匹配到相应 的组播转发条目, 且满足组播协议的断言机制状态机要求;
(c2)在转发层直接使用预先设置的断言机制限流策略, 判断策略是否 要求 packet(key)上送到组播协议处理器, 如要求上送, 上送数据报文 packet(key), 然后协议层按照协议状态机形成新的组播路由条目, 同步到转 发层; 如不要求上送, 则屏蔽组播数据报文 packet(key:)。
8、 如权利要求 7所述的方法,
其特征在于, 所述断言机制限流策略是不区分键值的固定限流方式。
9、 如权利要求 7所述的方法,
其特征在于, 所述断言机制限流策略是根据 key值检索到的该情况下相应的 限流策略。
10、 如权利要求 7所述的方法,
其特征在于, 该方法引入了能够区分断言机制情况的限流标志, 根据所述断 言机制限流策略设置和清除该标志, 限制用于触发断言机制状态机的组播数 据报文对组播协议所在 Cpu的冲击。
11、 一种区分多业务的抗 IP组播数据流冲击通信系统的方法, 包括以 下步骤:
(dl )键值为 key的组播数据报文 packet(key)到达转发层, 转发层判断 是否能够匹配到相应的转发路由,如果能,执行下一步,否则,执行步骤 (d8 ) ;
(d2)判断是否满足转发条件, 如满足, 转发层首先进入正常转发流程 转发该 packet(key), 然后执行下一步, 否则执行步骤 (d6) ;
( d3 )判断协议是否要求将组播数据报文 paCket(key)上送协议处理器, 如果是,转发层将 paCket(key)上送协议层,执行下一步, 否则, 不进行限流, 结束;
(d4)协议层接收到转发层上送的组播数据报文 paCket(key:), 驱动协议 状态机生成新的组播路由条目 M (key),如果 M(key)置有上送标志 Upsend, 执行下一步; 否则, 将 M(key)同步到转发层, 转发层根据新的组播路由条目 M (key)对收到的组播数据报文 packet(key)进行转发, 结束;
(d5 )协议层检索该情况下与 key对应的限流策略并应用到 M(key), 得 到带有限流策略的 P— M(key)并将其同步到转发层, 转发层根据 P— M(key)的 限流策略实现对组播数据报文 packet(key)上送协议处理器的限流, 结束;
(d6)判断是否满足组播协议的断言机制状态机要求, 如果满足, 执行 下一步; 如果不满足, 丢弃组播数据报文 packet(key), 结束;
( d7 ) 在转发层使用预先设置的断言机制限流策略, 如果策略要求 paCket(key)上送协议处理器, 则上送数据报文 paCket(key), 协议层按照协议 状态机形成新的组播路由条目同步到转发层, 转发层再根据该条目进行转发 和上送, 结束; 如果策略不要求上送, 则屏蔽该组播数据报文 packet(key), 结束;
(d8)将组播数据报文 packet(key)上送协议处理器, 协议层驱动协议状 态机以生成新的组播路由转发条目; 同时转发层检索该情况下与 key对应的 限流策略,生成临时转发路由条目 T— M(key),根据该条目对后续的组播数据 报文 packet(key)进行限流;
(d9)如果生成了新的组播路由转发条目, 同步到转发层, 转发层用该
条目更新 T— M(key), 进入正常转发流程, 结束; 如果不能生成 M(key), 转 发层根据 T— M(key)附带的限流策略继续限流, 并根据策略决定何时限流结 束。
12、 如权利要求 11所述的方法,
其特征在于, 所述步骤(d5)中, 如果根据 P—M(key)的限流策略需要将组播 数据报文 packet(key)上送到协议处理器, 则在上送后, 返回执行步骤(d4), 如该限流策略还要求启动即时限流, 则转发层将后续相关的组播数据报文 packet(key)丢弃。
13、 如权利要求 11所述的方法,
其特征在于, 还包括以下对组播限流策略的配置方法:
(el ) 通过人为设定或者通过预先定义的策略算法获得不同的限流需 求, 在组播协议层配置以限流类型 typet和键值 key为索引的组播限流策略 表 LI (type, key) ;
(e2) 协议层将形成的组播限流策略同步到转发层;
(e3 )转发层根据键值 key和限流类型 type为索引形成组播限流策略表
L2 (t pe,key) 。
14、 如权利要求 11所述的方法,
其特征在于, 所述步骤(d7)和(d8)中, 协议层生成新的组播路由条目时, 如果该新条目置有上送标志 Upsend,协议层也检索该情况下与 key对应的限 流策略并应用到该新的路由条目 M(key), 得到带有限流策略的 P_M(key), 再将其同步到转发层。
15、 如权利要求 11所述的方法,
其特征在于,所述步骤(d8)中生成的临时转发路由条目 T— M(key)的转发标 志为 N, 后续的组播数据报文 packet(key)将被丢弃。
16、 如权利要求 11所述的方法,
其特征在于, 所述断言机制限流策略是不区分键值的固定限流方式; 或者所 述断言机制限流策略是根据 key值检索到的该情况下相应的限流策略。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/813,187 US7830802B2 (en) | 2004-12-29 | 2005-07-29 | Method for preventing IP multicast data stream to overload communication system by distinguishing all kinds of services |
ES05772721T ES2398244T3 (es) | 2004-12-29 | 2005-07-29 | Un método para evitar un flujo de datos de multidifusión IP sobrecargue un sistema de comunicación por distinción de todos los tipos de servicios |
EP05772721A EP1838049B1 (en) | 2004-12-29 | 2005-07-29 | A method for preventing ip multicast data stream to overload communication system by distinguishing all kinds of services |
HK07111014.2A HK1106634A1 (en) | 2004-12-29 | 2007-10-11 | A method for preventing ip multicast data stream to overload communication system by distinguishing all kinds of services |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2004101034020A CN100393069C (zh) | 2004-12-29 | 2004-12-29 | 区分多业务的抗ip组播数据流冲击通信系统的方法 |
CN200410103402.0 | 2004-12-29 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2006069511A1 true WO2006069511A1 (fr) | 2006-07-06 |
Family
ID=36614484
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2005/001152 WO2006069511A1 (fr) | 2004-12-29 | 2005-07-29 | Procede pour empecher un flux de donnees multidiffusion ip de surcharger un systeme de telecommunication grace a la distinction de differents services |
Country Status (6)
Country | Link |
---|---|
US (1) | US7830802B2 (zh) |
EP (1) | EP1838049B1 (zh) |
CN (1) | CN100393069C (zh) |
ES (1) | ES2398244T3 (zh) |
HK (1) | HK1106634A1 (zh) |
WO (1) | WO2006069511A1 (zh) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7379990B2 (en) * | 2002-08-12 | 2008-05-27 | Tsao Sheng Ted Tai | Distributed virtual SAN |
CN101159664B (zh) * | 2007-11-01 | 2011-11-30 | 中兴通讯股份有限公司 | 一种在同步组播路由信息时减少同步信息量的方法 |
CN101388850B (zh) * | 2008-11-05 | 2010-12-22 | 北京星网锐捷网络技术有限公司 | 一种组播报文转发方法及装置 |
US9274851B2 (en) | 2009-11-25 | 2016-03-01 | Brocade Communications Systems, Inc. | Core-trunking across cores on physically separated processors allocated to a virtual machine based on configuration information including context information for virtual machines |
US8411129B2 (en) | 2009-12-14 | 2013-04-02 | At&T Intellectual Property I, L.P. | Video conference system and method using multicast and unicast transmissions |
US8769155B2 (en) | 2010-03-19 | 2014-07-01 | Brocade Communications Systems, Inc. | Techniques for synchronizing application object instances |
US8576703B2 (en) | 2010-03-19 | 2013-11-05 | Brocade Communications Systems, Inc. | Synchronization of multicast information using bicasting |
US8495418B2 (en) | 2010-07-23 | 2013-07-23 | Brocade Communications Systems, Inc. | Achieving ultra-high availability using a single CPU |
US9104619B2 (en) | 2010-07-23 | 2015-08-11 | Brocade Communications Systems, Inc. | Persisting data across warm boots |
US9143335B2 (en) | 2011-09-16 | 2015-09-22 | Brocade Communications Systems, Inc. | Multicast route cache system |
US10581763B2 (en) | 2012-09-21 | 2020-03-03 | Avago Technologies International Sales Pte. Limited | High availability application messaging layer |
US9967106B2 (en) | 2012-09-24 | 2018-05-08 | Brocade Communications Systems LLC | Role based multicast messaging infrastructure |
US9203690B2 (en) | 2012-09-24 | 2015-12-01 | Brocade Communications Systems, Inc. | Role based multicast messaging infrastructure |
US9619349B2 (en) | 2014-10-14 | 2017-04-11 | Brocade Communications Systems, Inc. | Biasing active-standby determination |
CN113381937B (zh) * | 2021-06-09 | 2022-09-13 | 烽火通信科技股份有限公司 | 一种信息状态上报方法和网络设备 |
CN114615202B (zh) * | 2022-03-10 | 2024-06-21 | 中国银行股份有限公司 | 流量访问控制方法及装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001197110A (ja) * | 2000-01-11 | 2001-07-19 | Nippon Telegr & Teleph Corp <Ntt> | トラヒック制御方法 |
US6598034B1 (en) * | 1999-09-21 | 2003-07-22 | Infineon Technologies North America Corp. | Rule based IP data processing |
JP2004320380A (ja) * | 2003-04-15 | 2004-11-11 | Furukawa Electric Co Ltd:The | 帯域制御方法およびその帯域制御装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6483832B1 (en) * | 1997-04-17 | 2002-11-19 | At&T Corp. | IP multicast over routed ATM network using lane |
JP3812239B2 (ja) * | 1999-10-04 | 2006-08-23 | 株式会社日立製作所 | ネットワーク中継装置 |
US20030099198A1 (en) * | 2001-11-27 | 2003-05-29 | Amplify.Net, Inc. | Multicast service delivery in a hierarchical network |
US7734812B2 (en) * | 2002-06-06 | 2010-06-08 | International Business Machines Corporation | Method and apparatus for processing outgoing internet protocol packets |
US7644177B2 (en) * | 2003-02-28 | 2010-01-05 | Cisco Technology, Inc. | Multicast-routing-protocol-independent realization of IP multicast forwarding |
-
2004
- 2004-12-29 CN CNB2004101034020A patent/CN100393069C/zh not_active Expired - Fee Related
-
2005
- 2005-07-29 EP EP05772721A patent/EP1838049B1/en not_active Not-in-force
- 2005-07-29 WO PCT/CN2005/001152 patent/WO2006069511A1/zh active Application Filing
- 2005-07-29 ES ES05772721T patent/ES2398244T3/es active Active
- 2005-07-29 US US11/813,187 patent/US7830802B2/en not_active Expired - Fee Related
-
2007
- 2007-10-11 HK HK07111014.2A patent/HK1106634A1/xx not_active IP Right Cessation
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6598034B1 (en) * | 1999-09-21 | 2003-07-22 | Infineon Technologies North America Corp. | Rule based IP data processing |
JP2001197110A (ja) * | 2000-01-11 | 2001-07-19 | Nippon Telegr & Teleph Corp <Ntt> | トラヒック制御方法 |
JP2004320380A (ja) * | 2003-04-15 | 2004-11-11 | Furukawa Electric Co Ltd:The | 帯域制御方法およびその帯域制御装置 |
Non-Patent Citations (1)
Title |
---|
See also references of EP1838049A4 * |
Also Published As
Publication number | Publication date |
---|---|
CN100393069C (zh) | 2008-06-04 |
EP1838049A1 (en) | 2007-09-26 |
HK1106634A1 (en) | 2008-03-14 |
US20080165681A1 (en) | 2008-07-10 |
CN1798098A (zh) | 2006-07-05 |
US7830802B2 (en) | 2010-11-09 |
EP1838049A4 (en) | 2011-05-11 |
EP1838049B1 (en) | 2012-10-24 |
ES2398244T3 (es) | 2013-03-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2006069511A1 (fr) | Procede pour empecher un flux de donnees multidiffusion ip de surcharger un systeme de telecommunication grace a la distinction de differents services | |
US20070165633A1 (en) | Multicast packet control apparatus | |
WO2008080314A1 (fr) | Procédé, moteur de retransmission et dispositif de communication pour la commande d'accès aux messages | |
CN107124366B (zh) | 一种实现服务质量控制的方法、装置及系统 | |
CA2289070A1 (en) | Multicast switching | |
WO2006063513A1 (fr) | Procede de multidiffusion dans un reseau prive virtuel utilisant un routeur virtuel | |
WO2006002596A1 (fr) | Procede pour la mise en oeuvre d'une multidiffusion en fonction d'une structure de transmission multiservices | |
WO2008017270A1 (fr) | Procédé, dispositif et système ethernet supportant un acheminement multidiffusion à source spécifique | |
WO2014183518A1 (zh) | 一种实现数据包转发的方法及系统 | |
US7688819B2 (en) | Faster routing protocol convergence using efficient message markup | |
WO2014032413A1 (zh) | 数据包的处理方法、控制器及系统 | |
CN1523850A (zh) | 用于分布式处理边界网关协议的设备和方法 | |
JP6627964B2 (ja) | Sdnベースのarp実装方法および装置 | |
WO2007059679A1 (fr) | Procede pour le traitement de service multidiffusion anormal et equipement de reseau associe | |
WO2009152702A1 (zh) | 一种流量控制的方法和系统及承载层设备 | |
WO2005125104A1 (fr) | Procede de transmission securisee de flux de services sur un reseau ip | |
WO2012163032A1 (zh) | 处理组播的方法和装置 | |
WO2007054006A1 (fr) | Station de base de système d’accès sans fil large bande et système pour réaliser un service de diffusion de groupe | |
WO2003084129A1 (fr) | Procede de collecte de donnees de topologie de reseau | |
WO2011103759A1 (zh) | 关联的双向标签交换路径的创建方法及系统 | |
US9270593B2 (en) | Prediction based methods for fast routing of IP flows using communication/network processors | |
WO2007041942A1 (fr) | Système pour ethernet de support de la transmission de la multidiffusion spécifique à une source et procédé idoine | |
WO2015074423A1 (zh) | 一种接入网关中数据报文的转发处理方法 | |
WO2016177058A1 (zh) | 数据流调度方法及装置 | |
WO2011113358A1 (zh) | 用于ip网络的路由转发方法及网络设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11813187 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2005772721 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2005772721 Country of ref document: EP |