WO2009046622A1 - Procédé et appareil de commande de paquets ip multidiffusion dans un réseau d'accès - Google Patents

Procédé et appareil de commande de paquets ip multidiffusion dans un réseau d'accès Download PDF

Info

Publication number
WO2009046622A1
WO2009046622A1 PCT/CN2008/001624 CN2008001624W WO2009046622A1 WO 2009046622 A1 WO2009046622 A1 WO 2009046622A1 CN 2008001624 W CN2008001624 W CN 2008001624W WO 2009046622 A1 WO2009046622 A1 WO 2009046622A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
multicast
predetermined
user terminal
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2008/001624
Other languages
English (en)
French (fr)
Inventor
Chunyan Yao
Haibo Wen
Jun Zheng
Fanxiang Bin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Priority to KR1020107008922A priority Critical patent/KR101503677B1/ko
Priority to US12/733,703 priority patent/US8923181B2/en
Priority to EP08800617.6A priority patent/EP2197161B1/en
Publication of WO2009046622A1 publication Critical patent/WO2009046622A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2878—Access multiplexer, e.g. DSLAM
    • H04L12/2879—Access multiplexer, e.g. DSLAM characterised by the network type on the uplink side, i.e. towards the service provider network
    • H04L12/2881—IP/Ethernet DSLAM
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • 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/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems

Definitions

  • the present invention relates to the field of IP packet transmission in an access network, and particularly relates to uplink transmission control of a multicast IP packet whose multicast source is a user terminal. Background technique
  • the user terminal requests the mobile agent in its current subnet by actively sending a proxy request message (AS, which is an ICMP router discovery message) (for the user terminal, the movement within its home subnet)
  • AS which is an ICMP router discovery message
  • the agent is called a home agent, abbreviated as HA; and the mobile agent in a foreign subnet is called a foreign agent, abbreviated as FA).
  • FACOA care-of address
  • RRQ registration request message
  • the IP packet is first sent to the HA of the user terminal, and then the HA encapsulates the IP packet through a network layer tunneling technology (for example, encapsulating the IP packet based on the IP protocol).
  • the packet is sent to the corresponding FA.
  • the FA decapsulates it accordingly, and finally forwards it to the user terminal according to the address of the user terminal carried in the IP packet.
  • One subnet usually includes multiple mobile agents, and when the user terminal does not know the unicast address of any FA in the subnet on which it is currently located, the AS is sent in the form of a unicast packet. Feasible. To this end, in the prior art, all mobile agents in a subnet are assigned a specific multicast address. When the user terminal moves to any subnet, as long as the AS is sent with the multicast address, The incoming device recognizes all mobile agents it needs to send to that subnet.
  • the access device taking the DSLAM as an example discards all multicast sources as IP packets of the user terminal.
  • the request message cannot reach its location.
  • Any mobile agent in the network cannot trigger the transmission of AA in time, which may result in interruption of the service.
  • the RRQ sent by the user terminal in the form of a multicast IP packet cannot reach any of the mobile agents, and registration cannot be completed in time.
  • the present invention improves the access device in the communication network so that after receiving the multicast IP packet from the user terminal, it judges and selects the multicast device, and allows the eligible multicast.
  • the IP packet passes, for example, only allows the advertisement request message and the registration request message to pass, so that the user terminal can receive the care-of address of the network in time and register, and maintain the uninterrupted connection of the service.
  • a method for controlling an IP packet from a user terminal at an access device of an access network includes the following steps: receiving an IP packet from the user terminal; The IP packet is detected to determine whether the IP packet is a multicast IP packet that is allowed to access.
  • a control apparatus for controlling an IP packet from a user terminal at an access device of an access network, comprising: receiving means for receiving an IP from the user terminal a first determining device, configured to detect the IP packet, determine whether the IP packet is a multicast IP packet that is allowed to be accessed, and the multicast sending device is configured to: The packet is sent in multicast mode.
  • the access device will allow a legitimate multicast IP packet. (For example, the announcement request message and the registration request message), by, preferably, judging and performing interception processing on malicious attacks using certain multicast IP packets, thereby ensuring support for mobile IPv4 by the DSL access device, so that When a user terminal moves in a different subnet, its business is not interrupted.
  • DRAWINGS For example, the announcement request message and the registration request message
  • Figure 1 is a schematic diagram of a communication network using DSL access technology
  • FIG. 2 is a flow chart of a system method for multicast IP packet transmission control in the communication network shown in FIG. 1 according to an embodiment of the present invention
  • FIG. 3 is a flow chart of a method for controlling an IP packet from a user terminal at an access device of an access network according to an embodiment of the present invention
  • FIG. 4 is a block diagram of a control device for controlling an IP packet from a user terminal at an access device of an access network, in accordance with an embodiment of the present invention.
  • the present invention will be described from a system perspective with reference to FIG. 1 and FIG. 2 and an IP-based communication network as an example. Those skilled in the art understand that the present invention should not be limited to an IP-based communication network.
  • Peer node The two user terminals that are communicating with each other are the peer nodes of each other. Permanent address of the user terminal: A network address uniquely uniquely assigned by the operator to each user terminal. When communicating, the destination address of the IP packet sent by a user terminal is the permanent address of the peer node.
  • Care-of address After a user terminal moves to a foreign subnet, in order for its home agent to accurately forward the IP packet from its peer node, the user terminal needs to have its current The care-of address used is registered at its home agent. After registration, the IP packet sent to the user terminal will be encapsulated at the home agent, and the destination address in the added IP header is the care-of address.
  • the user terminals a, b are all assigned to the subnet A, and the user terminal a is located in the subnet A, and the user terminal b is moved to the other subnet B.
  • the network device and related link between the peer node c and the gateway as the user terminal a or b are not shown, and are replaced by broken lines, and those skilled in the art understand that the above omission is not Any effect on the invention.
  • the user terminal can determine whether it is moved from one subnet to another in one of the following ways:
  • Judgment mode 1 The user terminal judges by the survival time of the AA. Specifically, the user terminal records the time respectively elapsed after receiving the AA from each mobile agent last time. If the user terminal does not receive another AA from the same agent until the lifetime of one AA expires, the user terminal will It is determined that it has lost contact with the mobile agent, that is, it has left the subnet where the mobile agent is located.
  • Judgment mode 2 The user terminal uses the network prefix of the source address in the AA message to judge. This method is applicable to the case where the prefix prefix extension (Prefix-Lengths Extension) is used in the AA message. Specifically, after receiving the AA sent by the mobile agent, the user terminal compares the source address network prefix of the AA with the source address network prefix of the previously received AA, if different (usually, each mobile in a subnet) The agents have the same network prefix, and the mobile agents in different subnets have different network prefixes, and it is determined that the user terminal has moved from the previous subnet to another subnet.
  • the prefix prefix extension Prefix-Lengths Extension
  • the user terminal a is determined to be still in the home subnet (subnet A), and the user terminal b determines that it has moved to a foreign subnet.
  • the home agent forwards the IP packet to the correspondent node c according to the routing protocol.
  • a forwarding address needs to be obtained through a DHCP (Dynamic Host Configuration Protocol) server or AA in the foreign subnet to register with its home agent (HA, Mobile Agent 1 in Figure 1).
  • DHCP Dynamic Host Configuration Protocol
  • AA Mobile Agent 1 in Figure 1
  • the care-of address is COCOA (Co-located COA) -
  • the user terminal b requests the DHCP server to assign a COCOA to it. After obtaining COCOA, the user terminal b can directly send an RRQ message to the mobile agent I to register, and then move.
  • the mapping between the permanent address of user terminal b and its current COCOA is generated.
  • the mobile agent I will be registered in the registration information according to the destination address (ie, the permanent address of the user terminal b, such as 162.105.203.16) contained in the IP packet.
  • the destination address ie, the permanent address of the user terminal b, such as 162.105.203.16
  • - User terminal b requests the DHCP server to assign a COCOA to it, after acquiring COCOA, user terminal b is again a foreign agent in subnet b (FA, such as Mobile Agent II or Mobile Agent III or Mobile Agent IV shown in Figure 1)
  • FA foreign agent in subnet b
  • An AA message is received, and the "R" in the AA message (registration Required requires registration, indicating that even if the COCOA address is used, the mobile agent needs to be registered). If the bit is set, it means that the mobile agent still needs to pass through (or III or IV) Register with its ⁇ (Mobile Agent I).
  • the transfer agent is FACOA at the mobile agent in the FACOA network to register with Mobile Agent I. details as follows:
  • step A If the lifetime of the AA from the mobile agent 1 previously received by the user terminal b has expired and the AA from any of the mobile agents in the subnet B has not been received, the user terminal b needs to discover the mobile agent that can be registered, and proceeds to step A:
  • step A the user terminal b requests to send AA to all mobile agents (11, III, IV) in the subnet in which it is currently located by sending a proxy request message (AS) to Get FACOA.
  • AS proxy request message
  • the IP source address of the AS has the following conditions:
  • the IP source address is the COCOA
  • the IP source address is the permanent address of the mobile terminal b;
  • the IP source address is 0.0.0.0.
  • the destination address of the AS message is a unified multicast address that can point to all mobile agents in the subnet B (for example, 224.0. 0.1 1 ) , in addition, it can also be a unicast address.
  • the DSLAM2 when the DSLAM2 receives the IP packet sent by the user terminal, it does not simply allow the pass, but needs to perform the following operations:
  • the received IP packet is discriminated to determine whether the IP packet is a unicast IP packet or a multicast IP packet. If the unicast IP packet sent by the user terminal is received, it is allowed to pass directly. If the received IP packet is a multicast IP packet, it needs to be selectively filtered.
  • the dependent policies include but are not limited to the following manners. :
  • the access device in the access network (such as DSLAM2 in FIG. 1) is configured with a legal multicast address list in advance or dynamically.
  • the DSLAM2 parses out the group.
  • the broadcast address is compared with the legal multicast address list. If the multicast address of the IP packet is in the legal multicast address list, the multicast address belongs to a legal multicast address, and DSLAM2 will allow the address.
  • the multicast IP packet passes and is forwarded to the multicast address. If DSLAM2 cannot find the multicast address of the multicast IP packet in the multicast address list, the multicast IP packet is discarded.
  • the foregoing method for filtering according to the multicast address of the multicast IP packet is applicable to various access devices including a base station in the radio access network and a DSLAM in the fixed access network.
  • the present invention provides the following preferred solutions:
  • Each legal multicast address list corresponds to one or more user-side ports of the DSLAM2.
  • the DSLAM2 After a multicast IP packet is sent from a user-side port of the DSLAM2, the DSLAM2 searches for a legal multicast address list corresponding to the user-side port, only when the multicast address of the multicast IP packet exists in the legal group. DSLAM2 allows the multicast IP packet to pass when it is broadcast in the address list. Otherwise, the multicast IP packet is discarded.
  • both AS and RRQ are sent to a unified multicast address (for example, 224.0.0.11) corresponding to all mobile agents in the subnet, in this example, all mobile agents in the subnet will be corresponding at DSLAM2.
  • the unified multicast address (for example, 224.0.0.11) can be used as a legal multicast address to enable the AS and RRQ sent in multicast mode to pass.
  • the value of the protocol field of the packet header part of the IP packet indicates the protocol type carried by the IP packet. For example, when the IPv4 packet protocol field value is 17, it indicates that the IPv4 packet header carries the UDP packet, and when the UDP packet header Indicates the RRQ message when the destination port field value is 434.
  • a list of multicast IP packet types that are allowed to pass can be configured at the DSLAM2, and after the multicast IP packet from the user side arrives, the protocol domain is detected (for example, the identification information in the packet header is obtained), and then The list of types is compared to determine whether the multicast IP packet is allowed to pass.
  • the filtering is performed separately according to the multicast IP packet protocol domain, in order to enable the AS and the RRQ to pass through and block other multicast IP packets from the user side, you can configure only the AS and RRQ to pass through the DSLAM2.
  • the packet header is parsed, as follows:
  • IPv4+ICMP+AS IPv4+ICMP+AS
  • ICMP messages are encapsulated in IPv4 packets
  • AS messages are one of many ICMP messages.
  • protocol field value of the IPv4 packet header is 1, it indicates that the data part of the IPv4 packet includes an ICMP message, and when the type field in the ICMP message is 10 and the code field is 0,
  • the ICMP message is an AS message;
  • the RRQ message is usually encapsulated in the following form: IP V4+UDP+RRQ, that is, the UDP packet is encapsulated in the IPv4 packet, and the UDP header is followed by the mobile IPv4 control message.
  • IP V4+UDP+RRQ the UDP packet is encapsulated in the IPv4 packet
  • the UDP header is followed by the mobile IPv4 control message.
  • the type field of the control message is 1
  • the protocol field value of the IPv4 header is 17
  • the indication data part includes the UDP packet.
  • the port number in the UDP header is 434 and the type field of the mobile IPv4 control message is 1, the RRQ message can be determined.
  • the DSLAM2 When it is determined that the incoming multicast IP packet is an AS message or an RRQ message, the DSLAM2 allows the multicast IP packet to pass, otherwise, it is discarded.
  • the DSLAM2 may not specifically determine whether the IP packet is an AS or RRQ message, but determine whether the IP packet is allowed to pass according to some field (or domain) value in the IP packet, for example.
  • DSLAM2 finds that the protocol field value of the IPv4 header is 17 or the protocol field value of the IPv4 header is 17 and the port number of the UDP header is 434, it can be judged as the allowed IP packet; or when the IPv4 header is found.
  • the protocol field value is 1, or when the protocol field value of the IPv4 header is found to be 1, and the type field in the ICMP message is 10, the IP packet that is allowed to pass can be determined.
  • Such a restriction condition is less than the limitation condition for determining the specific AS or RRQ message, which may cause some non-AS and non-RRQ messages satisfying the above conditions to pass, but still within the fault tolerance range of the system, and the system is greatly reduced.
  • the complexity of the implementation a preferred embodiment described below may be combined, i.e., DSLAM2 is used in conjunction with attacks against malicious users based on the frequency of transmission of a particular type of multicast IP packet.
  • IP packet filtering is performed according to the multicast address and type of the multicast IP packet. For example, only if the IPv4 header protocol field value is 17 or the port number in the UDP header is 434 or the UDP packet contains an RRQ message, or when the IPv4 header protocol field value is 1 or the ICMP message type field is 10 or the code field is 0. If the multicast address of the multicast IP packet is a unified multicast address corresponding to all mobile agents in the subnet (for example, 224.0.0.11), the multicast IP packet is allowed to pass, otherwise, the group is Broadcast IP packets are discarded. No longer.
  • DSLAM2 is based on a specific type of multicast
  • the transmission frequency of the IP packet is used to defend against the attack of the malicious user.
  • the AS message is taken as an example to illustrate as follows: Those skilled in the art understand that one user side port of the DSLAM is connected to a user network via a physical link. Based on this, the DSLAM2 can detect the number of AS messages received via the user side port i (connected to the user network where the user terminal b is located) for a predetermined length of time, and the AS message received within the predetermined length of time. When the number exceeds a second predetermined threshold, the subsequent access of the AS message from the port is rejected for the predetermined length of time.
  • a DSLAM or an access device in a wireless network such as a base station, etc.
  • the subsequent access of the AS message from the user terminal is rejected within the another predetermined length of time.
  • the predetermined time and the other predetermined time and the first and second predetermined thresholds may be determined manually based on the empirical data or the requirements of the operator, which should be understood by those skilled in the art, and will not be described herein.
  • the DSLAM 2 allows it to pass in step B and sends it to each mobile agent in the subnet.
  • step C After each mobile agent receives the AS, the method proceeds to step C, and at least one of the mobile agents II, III, IV sends an AA message as a response.
  • the user terminal b obtains authentication by interacting with the authentication server, the authentication server allows the user terminal b to enter the subnet where the mobile agents II, III, IV are located, and the authentication server configures a mobile agent for the user terminal b as the user terminal b.
  • the Mobile Agent II sends an AA message as a response.
  • the rule of selecting which one or more of the mobile agents receiving the AS message to send the AA message to the user terminal b is not limited thereto, and is merely an example here.
  • step D the user terminal b sends an RRQ message to the DSLAM2.
  • the DSLAM 2 will perform a corresponding check on the basis of the present invention to determine whether to allow the pass.
  • DSLAM detects the RRQ message and checks the above AS The measurement process is the same except that the IP packet encapsulation format is different, and will not be described here.
  • RFC 3344 defines two different registration procedures, one of which is that the user terminal registers with its home agent via a foreign agent (the user terminal sends the RRQ message to the foreign agent, which is forwarded by the foreign agent) To the home agent); the second is to register directly with the home agent by the user terminal (the user terminal directly sends the RRQ message to its home agent).
  • the system can determine which registration method to apply to a user terminal based on the following rules:
  • the user terminal is to be registered via the foreign agent
  • a user terminal registers with its home agent using COCOA and the user terminal receives an AA message from a foreign agent in its current subnet, and the R bit in the AA message is set, the user The terminal shall be registered by the foreign agent (or other foreign agent in its current subnet);
  • the IP packet sent by the correspondent node c to the user terminal b will arrive at the home agent (HA, as shown in Figure 1 of the mobile agent I). Thereafter, the home agent is based on the network layer tunneling technology (IP-in-IP). ) Forward the IP packet.
  • IP-in-IP network layer tunneling technology
  • the entry of the network layer tunnel is a home agent, and the exit has two cases: when the user terminal b directly registers its COCOA with the home agent, the exit of the network layer tunnel is the user terminal b; when the user terminal b passes the subnet B When a foreign agent in the registration is indirectly registered with the home agent, the exit of the network layer tunnel is the foreign agent.
  • the access device receives the IP packet from the user terminal b.
  • the IP packet may be a multicast IP packet or a unicast IP packet.
  • the DSLAM 2 needs to analyze the IP packet to determine whether it is allowed to pass. Specifically, in step S11, the DSLAM 2 determines whether the IP packet is a multicast IP packet that is allowed to be accessed. Of course, if the IP packet is a unicast IP packet, access can be allowed; if it is a multicast IP packet, it can be allowed to access when any one or more of the following two conditions are met, and The multicast IP packet is forwarded in the form of:
  • the destination multicast address of the multicast IP packet belongs to a predetermined legal multicast address.
  • a multicast access control list (MACL) is maintained in DSLAM2. If the destination multicast address of the multicast IP packet is the pre-stored address in the MACL (for example, it corresponds to all the subnets).
  • the unified multicast address of the mobile agent for example, 224.0.0.11)
  • all multicast IPs addressed to the address can be allowed. Packet access.
  • the multicast IP packet is a predetermined type of multicast IP packet, for example, a proxy request message or a registration request message sent in a multicast manner. If the multicast messages of the above type are all sent to the unified multicast address of all the foreign agents in the corresponding subnet (for example, 224.0.0.11), the multicast address may not need to be filtered, but only the After the type of the IP packet, it is multicast or discarded.
  • step S11 in order to prevent a malicious user from using a multicast message to attack, in step S11, before allowing the multicast IP packet to be accessed, further judgment is required, which is divided into two cases, as discussed below. :
  • the IP packet is used as a multicast IP packet that is allowed to access.
  • the cycle can be as long as infinite, Can be as short as one time unit (hours/minutes/seconds).
  • the IP packet received by one user side port is a multicast IP packet of a predetermined type
  • the number of times of the predetermined type of multicast IP packet exceeds a second predetermined value; when the number of times of the predetermined type of multicast IP packet received by the user side port in the second predetermined period does not exceed the second predetermined value, The IP packet is used as a multicast IP packet that is allowed to access.
  • the first and second predetermined periods and the first and second predetermined values may be determined based on empirical data or the requirements of the operator, which should be understood by those skilled in the art, and will not be described herein.
  • step S12 the multicast IP packet is sent in multicast form.
  • the process proceeds to step S12, and the multicast IP packet is discarded therein.
  • the control device 10 shown in Figure 4 Each of the access devices, which is exemplified by the DSLAM 2 shown in FIG. 1, includes: a receiving device 100, a first determining device 101, and a transmitting device 102. Specifically, the first determining device 101 includes: a second determining device 1010. The third determining device 1011, the fourth determining device 1012, and the fifth determining device 1013.
  • the receiving device 100 is responsible for receiving an IP packet from the user terminal b; the IP packet may be a multicast IP packet or a unicast IP packet.
  • the first determining means 101 of the access device detects the IP packet and determines whether the IP packet is a multicast IP packet that is allowed to be accessed. If the IP packet is a unicast IP packet, access is allowed; if the IP packet is a multicast IP packet, any one or both of the following two conditions are satisfied When it is selected, it is allowed to access:
  • the destination multicast address of the multicast IP packet belongs to a predetermined legal multicast address.
  • a multicast access control list is maintained in DSLAM2. If the destination multicast address of the multicast IP packet is the pre-stored address in the MACL (for example, a unified multicast address corresponding to all mobile agents in the subnet) (For example, 224.0.0.1 1 ) ), when the probability that the DSLAM2 is sent to the multicast IP address attack by the multicast address is low, all multicast packets to the address can be allowed to access.
  • the multicast IP packet is a predetermined type of multicast IP packet, for example, a proxy request message or a registration request message sent in a multicast manner. Then, when the default message of the above type is sent to the unified multicast address (for example, 224.0.0.11) corresponding to all the mobile agents in the subnet, it is no longer necessary to filter the multicast address, but only the IP is identified. After the type of the packet, it is multicast or discarded.
  • the unified multicast address for example, 224.0.0.11
  • the first determining means 101 in order to prevent a malicious user from using the multicast message for the attack, preferably further comprises the following two sub-devices:
  • the second judging device 1010 is configured to: when the received IP packet from a user equipment is a multicast IP packet of a predetermined type, determine the multicast IP packet of the predetermined type sent by the user equipment in the first predetermined period. Whether the number of times exceeds the first predetermined value.
  • the third judging device 1011 is configured to: when the number of times of the predetermined type of multicast IP packet sent by the user equipment in the first predetermined period does not exceed the first predetermined value, the IP packet is used as a group allowed to access Broadcast IP packets.
  • the period can be as long as infinite or as short as one time unit (hours per minute per second).
  • the first determining device 101 preferably may include the following sub-devices: a fourth determining device 1012 for when When the IP packet received by the user side port is a multicast IP packet of a predetermined type, it is determined whether the number of times of the predetermined type of multicast IP packet received by the user side port in the second predetermined period exceeds a second predetermined value.
  • a fourth determining device 1012 for when the IP packet received by the user side port is a multicast IP packet of a predetermined type, it is determined whether the number of times of the predetermined type of multicast IP packet received by the user side port in the second predetermined period exceeds a second predetermined value.
  • the fifth determining means 1013 receives the second predetermined period by the user side port When the number of times of the predetermined type of multicast IP packet does not exceed the second predetermined value, the IP packet is used as a multicast IP packet that is allowed to access.
  • the transmitting device 102 in the DSLAM 2 is responsible for transmitting the multicast IP packet and the unicast IP packet that are allowed to access, respectively.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

接入网中的组播 IP包发送控制方法及装置 技术领域
本发明涉及接入网中的 IP包传输领域， 尤其涉及组播源为用户 终端的组播 IP包的上行传输控制。 背景技术
在现有的移动通信中， 各移动代理 （Mobile Agent, 如， 边缘路 由器）在各自所处的子网内广播 "代理公告" （ Agent Advertisement, AA ) , 从而将 FACOA ( Foreign Agent Care-of-Address, 由移动代理 分配并对应于该移动代理的一种转交地址） 告知处于该子网内的各 个用户终端， 以支持必要的业务切换。 但是， 由于用户终端可能在 进行业务传输的过程中由其所归属的子网 （以下简称归属子网） 移 动到另一子网 （以下称为外地子网） 之中， 如果被动地等待广播的 AA, 很可能由于等待时间过长而导致业务中断。
为此，用户终端通过主动发送代理请求消息（ AS ,其为一种 ICMP 路由器发现消息） 来请求其当前所在的子网中的移动代理 （对于该 用户终端而言，其归属子网内的移动代理称为归属代理，简写为 HA; 而一外地子网中的移动代理称为外地代理， 简写为 FA )发送 AA。 并且， 用户终端通过发送注册请求消息 （RRQ， 其为一种移动 IP控 制消息） 来向其归属代理注册其所使用的转交地址（FACOA 或 COCOA)和用户终端的永久地址 (如， HOA)之间的对应关系。 这样， 对端节点在与该用户终端通信时， 将 IP 包先发送到该用户终端的 HA, 再由该 HA通过网络层隧道技术 （如， 基于 IP协议将该 IP包 进行封装）将该 IP包发给相应的 FA， 接到该 IP包后， FA对其进行 相应的解封装， 并根据该 IP包内所携带的用户终端的地址， 最终转 发给用户终端。
—个子网通常包括多个移动代理， 而当用户终端不知道其当前 所处的子网中任一个 FA的单播地址时， 以单播包形式发送 AS就不 可行。 为此， 现有技术中为一个子网中的所有移动代理分配了一个 特定的組播地址， 当用户终端移动到任意一个子网时， 只要其发出 的 AS中带有该组播地址，接入设备即能识别出其需发往该子网中的 所有移动代理。
随着固定、 移动网络融合的进一步深入， 移动 IPv4业务将会部 署在固定接入网络中， 然而， 由于运营商从经济和安全的角度考虑 而禁止固定接入网中的用户终端发送组播 IP 包， 因此， 以 DSLAM 为例的接入设备会丢弃所有组播源为用户终端的 IP包， 这样， 当用 户终端以组播 IP包的形式发送 AS时， 该请求消息将无法到达其所 处子网中的任一个移动代理， 也就不能及时触发 AA 的发送， 可能 将导致业务的中断。 同样， 用户终端以组播 IP包的形式发送的 RRQ 也同样不能到达任一个移动代理， 也就无法及时完成注册。 发明内容
鉴于现有技术存在上述问题， 本发明通过对通信网絡中的接入 设备进行改进， 使其在接收到来自用户终端的组播 IP包后， 对其进 行判断和 选， 允许符合条件的组播 IP包通过， 譬如， 仅允许公告 请求消息和注册请求消息的通过， 使用户终端能够及时地接收到所 在网络的转交地址并进行注册， 保持业务的无中断的连接。
根据本发明的第一方面， 提供了一种在接入网的接入设备处用 于对来自用户终端的 IP包进行控制的方法， 其中， 包括以下步骤， 接收来自用户终端的 IP包； 对所述 IP包进行检测， 判断该 IP包是 否为允许接入的组播 IP包。
根据本发明的第二方面， 提供了一种在接入网的接入设备处用 于对来自用户终端的 IP包进行控制的控制装置， 其中包括： 接收装 置， 用于接收来自用户终端的 IP包； 第一判断装置， 用于对所述 IP 包进行检测， 判断该 IP包是否为允许接入的组播 IP包； 组播发送装 置， 用于将所述的允许接入的组播 IP包以组播方式进行发送。
采用本发明提供的技术方案， 接入设备将允许合法的组播 IP包 (如， 公告请求消息和注册请求消息） 通过， 优选地， 对利用某些 组播 IP包所进行的恶意攻击进行判断并且做拦截处理， 保证了 DSL 接入设备对移动 IPv4的支持， 使一个用户终端在不同的子网中移动 时其业务不会中断。 附图说明
通过参照附图阅读以下所作的对非限制性实施例的详细描述，本发 明的其它特征、 目的和优点将会变得更明显。
图 1为一个采用 DSL接入技术的通信网络示意图；
图 2为根据本发明的一个具体实施方式的在图 1 所示通信网絡 中用于组播 IP包发送控制的系统方法流程图；
图 3 为根据本发明的一个具体实施方式的在接入网的接入设备 处用于对来自用户终端的 IP包进行控制的方法流程图；
图 4 为根据本发明的一个具体实施方式的在接入网的接入设备 处用于对来自用户终端的 IP包进行控制的控制装置的框图。
其中， 相同或相似的附图标记代表相同或相似的装置（模块）或 步骤。 具体实施方式
下面结合图 1、 图 2并以基于 IP协议的通信网络为例从系统角 度对本发明进行描述， 本领域技术人员理解， 本发明应不限于基于 IP协议的通信网络。
为方便描述， 对本文中出现的概念筒要介绍如下：
对端节点： 两个正在通信的用户终端互为对方的对端节点。 用户终端的永久地址： 由运营商分配给各个用户终端的具有全 局唯一性的网絡地址， 在通信时， 一个用户终端所发出的 IP包的目 的地址也即其对端节点的永久地址。
转交地址： 一个用户终端移动到外地子网后， 为使其归属代理 能够准确地转发来自其对端节点的 IP包， 该用户终端需要将其当前 所用的转交地址在其归属代理处进行注册， 注册之后， 发往该用户 终端的 IP包将在所述归属代理处进行封装，所加的 IP包头中的目的 地址即为所述转交地址。
假设用户终端 a、 b均归属于子网 A, 且用户终端 a位于子网 A 中， 而用户终端 b移动至另一子网 B中。 图 1 中， 为简明起见， 图 中未示出作为用户终端 a或 b的对端节点 c与网关之间的网络设备 和相关链路， 而以虛线代替， 本领域技术人员理解上述省略不对本 发明产生任何影响。
本发明中， 用户终端可通过以下方式之一判断出其是否由一个 子网移动到另一子网中：
判断方式 1 :用户终端通过 AA的生存时间来进行判断。具体地， 用户终端记录前次从各个移动代理处接收到 AA 后所分别经历的时 间， 如果直到一个 AA 的生存时间过期， 用户终端仍没有接收到来 自同一个代理的另一个 AA,用户终端将认定其与该移动代理失去联 系， 也即离开了该移动代理所在的子网。
判断方式 2: 用户终端利用 AA消息中源地址的网络前缀来进行 判断，此方式适用于 AA消息中带有"前缀长度扩展" （ Prefix-Lengths Extension ) 的情形。 具体地， 用户终端接收到一个移动代理发出的 AA后， 将该 AA的源地址网络前缀来与此前接收到的 AA的源地址 网络前缀进行比较， 如果不同 （通常， 一个子网中的各个移动代理 有相同的网络前缀， 而不同子网中的移动代理的网络前缀不同） ， 则判断该用户终端已由前一子网移动到了另一子网。
基于上述判断方式， 用户终端 a得以确定自身仍处于归属子网 (子网 A ) 中， 而用户终端 b则确定自身移动到了一个外地子网中。
对于用户终端 a， 由于其未移至外地子网， 因此， 只需固网中一 般的 IP路由协议运作，即用户终端 a所发出的 IP包将经由 DSLAM1 发送至归属代理（HA, 如图 1中的移动代理 I ) , 再由归属代理根据 路由协议将该 IP包转发给对端节点 c。
由于用户终端 b 移动到了一个外地子网， 为进行业务切换， 其 需要通过 DHCP (动态主机配置协议） 服务器或者所述外地子网中 的 AA来获取一个转发地址， 以向其归属代理 （HA, 如图 1 中的移 动代理 I ) 进行注册。 针对不同的转交地址对本发明讨论如下：
> 转交地址为 COCOA ( Co-located COA, 配置转交地址） - 用户终端 b请求 DHCP服务器为其分配一个 COCOA, 获得 COCOA后， 用户终端 b可直接向移动代理 I发送 RRQ消息进行注 册， 于是， 移动代理 I 处将生成用户终端 b 的永久地址与其当前 COCOA的映射关系。 此后， 当对端节点 c发来的 IP包到达移动代 理 I后， 移动代理 I将根据该 IP包所含的目的地址 （即用户终端 b 的永久地址， 如 162.105.203.16 )来由注册信息中查得用户终端 b的 COCOA。 于是， 在基于网络层隧道技术对该 IP包进行封装后， 将得 到以该 COCOA为目的地址的新的 IP包。 此后， 所述新的 IP 包将 被发往该 COCOA所指示的网络设备。
- 用户终端 b请求 DHCP服务器为其分配一个 COCOA, 获取 COCOA后， 用户终端 b又在子网 b的外地代理 （FA,如图 1 中所示 的移动代理 II或移动代理 III或移动代理 IV ) 处收到了 AA消息， 且 AA消息中的 "R" ( Registration Required 需要注册， 表示即使使 用了 COCOA地址， 仍需要向该移动代理注册） 比特置位， 则表示 仍需要通过该移动代理 Π(或 III或 IV) 向其 ΗΑ (移动代理 I ) 进行 注册。
> 转交地址为 FACOA 网 Β中的移动代理处获得 FACOA, 以向移动代理 I进行注册。 具体 如下：
如果用户终端 b此前接收到的来自移动代理 I的 AA的生存期已 过期且未接收到来自子网 B中任一移动代理的 AA,用户终端 b需要 发现可以注册的移动代理， 进入步骤 A:
在步骤 A中， 用户终端 b通过发送代理请求消息 （AS ) 来向其 当前所在的子网中的所有移动代理 （11、 III、 IV )请求发送 AA, 以 获得 FACOA。 该 AS的 IP源地址有以下情形：
- 若移动终端 b已获得 COCOA而仍发送 AS，则所述 IP源地址 为该 COCOA;
- 若移动终端 b未获得 COCOA, 则所述 IP源地址为移动终端 b 的永久地址；
- 移动终端 b未获得 COCOA且没有永久地址时， 所述 IP源地 址为 0.0.0.0。
由于移动终端 b不知道移动终端 II、 III、 IV中任一者的单播地 址， 因此， 该 AS消息的目的地址为能够指向子网 B 中所有移动代 理的统一组播地址（例如， 224.0.0.1 1 ) , 此外， 也可以是单播地址。
根据本发明， 当 DSLAM2接收到用户终端发来的 IP包后， 并非 简单地允许通过， 而需执行以下操作：
对接收到的 IP包进行甄别， 以确定该 IP包为单播 IP包还是组 播 IP包。 如果接收到用户终端发来的单播 IP包， 则直接允许通过， 而如果接收到的 IP包为组播 IP包， 则需要对其进行选择性过滤， 所 依赖的策略包括但不限于以下方式：
(一 ) 根据組播 IP包的组播地址进行 IP包的过滤
具体地， 访问网络中的接入设备 （如图 1 中的 DSLAM2 ) 处预 先或动态地配置有合法组播地址列表， 当接收到来自用户终端的组 播 IP包后， DSLAM2由其中解析出组播地址， 并与所述合法组播地 址列表进行比对， 如果该 IP包的组播地址位于该合法组播地址列表 中， 则说明该组播地址属于合法的组播地址， DSLAM2将允许该组 播 IP包通过， 并将其转发至该组播地址。如果 DSLAM2在所述组播 地址列表中找不到该组播 IP包的組播地址， 则丢弃该组播 IP包。
上述根据组播 I P包的组播地址进行过滤的方式适用于包括无线 接入网中的基站、 固定接入网中的 DSLAM等各种接入设备。
特别地， 针对 DSLAM, 本发明提供如下优选方案：
在 DSLAM2处配置多个合法组播地址列表， 每个合法组播地址 列表对应于 DSLAM2 的一个或多个用户侧端口， 当用户终端经由 DSLAM2的一个用户侧端口发来组播 IP包后， DSLAM2在与该用户 侧端口相对应的合法组播地址列表中查找， 仅当将该组播 IP包的組 播地址存在于所述合法组播地址列表中时， DSLAM2 才允许该组播 IP包通过。 否则， 丢弃该组播 IP包。
由于 AS、 RRQ均发往对应于该子网内所有移动代理的统一的组 播地址（例如， 224.0.0.11 ) , 因此， 在本例中， 在 DSLAM2处将对 应于该子网内所有移动代理的统一的组播地址 （例如， 224.0.0.11 ) 作为合法组播地址即可使以组播形式发送的 AS和 RRQ顺利通过。
除 AS、 RRQ外， 若还需允许发往其它组播地址的组播 IP包（譬 如， 承载上行组播业务的组播业务 IP包）通过， 可在 DSLAM2处将 相应的组播地址配置为合法组播地址。
(二）根据组播 IP包的类型进行 IP包的过滤
以移动 IPv4协议为例， IP 包的包头部分的协议域的值指示 IP 包所承载的协议类型， 譬如， 当 IPv4包协议域值为 17,指示 IPv4包 头承载的是 UDP报文， 当 UDP包头中的目的端口域值为 434时， 表示为 RRQ消息
于是， 可在 DSLAM2处配置允许通过的组播 IP包类型列表， 并 在来自用户侧的组播 IP包到来后， 对其协议域进行检测 （如， 获取 包头中的标识信息） ， 再与所述类型列表进行比对， 以确定是否允 许该组播 IP包通过。
本例中， 如果单独根据组播 IP包协议域来执行上述过滤， 为使 得 AS和 RRQ能够顺利通过而阻隔其它来自用户侧的组播 IP包，可 在 DSLAM2处配置仅允许 AS、 RRQ通过， 如， 在接到来自用户侧 的组播 IP包时， 对其包头进行解析， 具体说明如下：
- AS消息通常按照以下形式封装： IPv4+ICMP+AS , 即 ICMP消 息被封装在 IPv4包中， 而 AS消息是多种 ICMP消息中的一种。 具 体地： 当 IPv4包头的协议域值为 1时， 指示该 IPv4包数据部分包含 ICMP消息， 当 ICMP消息中的 type域为 10且 code域为 0时， 指 示 ICMP消息是 AS消息；
- RRQ消息通常按照以下形式封装： IP V4+UDP+RRQ , 即， UDP 报文被封装在 IPv4包中， UDP头后面紧跟着移动 IPv4控制消息， 当这个控制消息的 type域为 1时，表示是 RRQ消息。具体地，当 IPv4 包头的协议域值为 17时， 指示数据部分包含 UDP包， 当 UDP包头 中的端口号为 434且移动 IPv4控制消息的 type域为 1时， 即可判断 出为 RRQ消息。
当判断出到来的组播 IP包为 AS消息或者 RRQ消息时， DSLAM2 即允许该组播 IP包通过， 否则， 将其丢弃。
在一个变化的实施例中， DSLAM2可以不必具体地判断出该 IP 包是 AS或 RRQ消息， 而是根据 IP包中的一些字段 （或者称为域） 值来判断是否允许该 IP包通过， 例如， 当 DSLAM2发现 IPv4的包 头的协议域值为 17或者发现 IPv4的包头的协议域值为 17且 UDP 包头的端口号为 434时， 即可判断为允许通过的 IP包； 或者当发现 IPv4包头的协议域值为 1时， 或者当发现 IPv4包头的协议域值为 1 且 ICMP消息中的 type域为 10即可判断为允许通过的 IP包。 这样 的限制条件比判断出具体为 AS或 RRQ消息的限制条件少， 可能会 使一些满足上述条件的非 AS且非 RRQ的消息通过， 但是仍在系统 的容错范围内， 且极大地降低了系统实现的复杂度。 此外， 可以结 合下文所述的一个优选实施例， 即 DSLAM2根据特定类型的组播 IP 包的发送频率来防御恶意用户的攻击一起使用。
本领域技术人员理解， 上述两种 IP包的过滤方式可联合使用， 即根据组播 IP 包的组播地址和类型进行 IP 包的过滤。 譬如， 仅当 IPv4包头协议域值为 17或 UDP头中端口号为 434或 UDP包中包含 RRQ消息时， 或当 IPv4包头协议域值为 1或 ICMP消息的 type域 为 10或 code域为 0时， 如果该组播 IP包的组播地址为对应于该子 网内所有移动代理的统一的组播地址 （例如， 224.0.0.11 ) , 则允许 该组播 IP包通过， 否则， 将该组播 IP包丟弃。 不再赘述。
根据本发明的一个优选实施例， DSLAM2 根据特定类型的组播 IP包的发送频率来防御恶意用户的攻击， 以 AS消息为例说明如下： 本领域技术人员理解， DSLAM的一个用户侧端口经由物理链路 连接到一个用户网络。 基于此， DSLAM2 可以检测在预定时间长度 内经由用户侧端口 i (连向用户终端 b此时所处的用户网络）接收到 的 AS消息的个数， 在该预定时间长度内接收到的 AS消息个数超过 一个第二预定阔值时， 在该预定时间长度内拒绝此后的来自该端口 的 AS消息的接入。
对于 DSLAM 或无线网络中的接入设备如基站等， 还可以检测 某一个用户终端在另一预定时间长度内发来的 AS消息的个数，当在 该另一预定时间长度内接收到的来自该用户终端的 AS 消息个数超 出第一预定阈值后， 在该另一预定时间长度内拒绝此后的来自该用 户终端的 AS消息的接入。
所述预定时间和另一预定时间以及第一、 第二预定阈值可以人 为地基于经验数据或运营商的需求来确定， 这里本领域的技术人员 应能理解， 在此不做赘述。
当判定用户终端 b发来的 AS消息合法后， DSLAM2在步骤 B 中允许其通过， 并将其发往该子网内的各移动代理。
各个移动代理在接收到 AS后，该方法进入步骤 C,移动代理 II、 III、 IV中的其中至少一个发送 AA消息作为应答。 例如， 用户终端 b通过与认证服务器交互信息获得认证 ,则认证服务器允许用户终端 b进入移动代理 II、 III、 IV所在的子网， 并且认证服务器为用户终 端 b配置一个移动代理作为用户终端 b的外地代理， 例如， 移动代 理 II, 则移动代理 II发送 AA消息作为应答。 当然， 选择接收到 AS 消息的移动代理中的哪一个或哪多个移动代理向用户终端 b发送 AA 消息的规则不限于此， 此处仅为一个示例。
在步骤 D中， 用户终端 b发送 RRQ消息至 DSLAM2。 基于上 文中所作说明， 本领域技术人员能够理解， 如果该 RRQ消息以组播 方式发送， DSLAM2处将基于本发明对其进行相应的检查， 以确定 是否允许通过。 DSLAM对 RRQ消息的检测过程与上述对 AS的检 测过程除了 IP包封装格式不同， 其他均相同， 在此不再赘述。
以下对移动 IPv4中的注册方式作简要说明， 并请参照 RFC1256 以 及 RFC3344 协 议 （ htto：〃 www.ietf.orci/rfc/rfc1256.txt: http://www.ietf.orq/rfc/rfc3344.txt , 在此引用作为参考） ， 其中， RFC3344定义了 2种不同的注册程序， 其一是用户终端经由外地代 理来向其归属代理进行注册 （用户终端将 RRQ消息发给外地代理， 由外地代理转发至归属代理） ； 其二是直接由用户终端向其归属代 理进行注册（用户终端直接将 RRQ消息发送至其归属代理） 。 系统 可以基于以下规则来确定对一个用户终端应用何种注册方式：
- 如有一个用户终端需要向其归属代理注册外地代理所分配的
FACOA, 则该用户终端要经由该外地代理注册；
- 如果一个用户终端使用 COCOA 向其归属代理进行注册， 并 且，该用户终端由其当前所在子网中的一个外地代理处接收到了 AA 消息， 且该 AA消息中的 R比特置位， 则该用户终端应通过该外地 代理 （或者其当前所在子网中的其他外地代理） 来注册；
- 如果用户终端返回到其所归属子网，并且需要向其归属代理重 新进行注册， 则该用户终端必须直接向其归属代理注册。 以下结合图 1简要介绍注册完成后的业务数据转发过程。
注册完成后， 对端节点 c发往用户终端 b的 IP包将先到达归属 代理 （HA, 如图 1 中的移动代理 I ) ， 此后， 归属代理再基于网络 层隧道技术（IP-in-IP )转发该 IP包。 所述网络层隧道的入口是归属 代理， 而出口有 2 种情形： 当用户终端 b 直接向归属代理注册其 COCOA时， 该网络层隧道的出口为用户终端 b; 当用户终端 b经由 子网 B 中的某一外地代理间接向归属代理注册时， 该网络层隧道的 出口为该外地代理。
以下， 参照图 3并结合图 1对根据本发明第一方面的在接入网 的接入设备处用于对来自用户终端的 IP 包进行控制的方法进行描 述， 其中， 图 2及其相关描述在此一并作为参考。 在步骤 S10中， 接入设备（ DSLAM2 )接收来自用户终端 b的 IP包。 该 IP包可能是组播 IP包， 也可能是单播 IP包。
此后， DSLAM2需要对该 IP包进行分析， 以确定是否允许其通 过， 具体地， 在步骤 S11中， DSLAM2判断该 IP包是否为允许接入 的组播 IP包。 当然， 如果 IP包为单播 IP包， 则可允许接入； 如果 其为组播 IP包， 则在满足以下两种情况的任一项或任多项时， 可允 许其接入， 并以组播 IP包的形式将其转发：
i )所述组播 IP包的目的组播地址属于预先设定的合法的组播地 址。 本例中， DSLAM2 中维护了一张组播访问控制列表 （ Multicast Access Control List, MACL ) ，如果该组播 IP包的目的组播地址即为 MACL 中预存的地址 （例如， 对应于该子网内所有移动代理的统一 组播地址（例如， 224.0.0.11 ) ) ， 则当默认 DSLAM2被发往该组播 地址的组播 IP包攻击的概率很低时， 可以允许所有发往该地址的组 播 IP包接入。
ii ) 所述组播 IP包为预定类型的组播 IP包， 如， 以组播方式发 送的代理请求消息或注册请求消息等。 则当默认上述类型的组播消 息均发往对应子网内所有外地代理的统一的组播地址 （例如， 224.0.0.11 ) 时， 可无需再针对组播地址进行筛选， 而仅在识别出该 IP包的类型后， 即对其进行组播或将其丢弃。
本领域技术人员可以根据本申请文件的教导不经创造性劳动地 知晓将 i)、 ii ) 联合用于組播 IP包接入控制的情形， 不再赘述。
根据本发明的一个优选实施例， 为了防止恶意用户利用組播消 息进行攻击的情形， 在步骤 S11 中， 在允许组播 IP包接入之前， 还 需要进一步判断， 分为 2种情形， 讨论如下：
- 当所接收的来自一个用户设备的 IP包为预定类型的组播 IP包 时， 判断由该用户设备在第一预定周期内所发送的该预定类型的组 播 IP包的次数是否超过第一预定数值； 当由该用户设备在第一预定 周期内所发送的该预定类型的组播 IP包的次数未超过第一预定数值 时，将该 IP包作为允许接入的组播 IP包。所迷周期可以长至无限长， 可以短至一个时间单位 （小时 /分 /秒） 。
- 当所述接入网为固定接入网， 则当由一个用户侧端口所接收 的 IP包为预定类型的组播 IP包时，判断由该用户侧端口在第二预定 周期内所接收的该预定类型的组播 IP包的次数是否超过第二预定数 值； 当由该用户侧端口在第二预定周期内所接收的该预定类型的组 播 IP包的次数未超过第二预定数值时，将该 IP包作为允许接入的组 播 IP包。
所述第一、 第二预定周期以及第一、 第二预定数值可以人为地 基于经验数据或运营商的需求来确定， 这是本领域的技术人员应能 理解的， 在此不做赘述。
如果判断出用户终端发来的 IP包为允许接入的组播 IP包，则进 入步骤 S12， 并在其中将该组播 IP包以组播形式发送出去。
如果判断出该 IP包为不允许接入的組播 IP包，则进入步骤 S 12，， 并在其中将该组播 IP包丢弃。
如果该 IP包为单播 IP包，则 DSLAM2将在步驟 S12"中将该单 播 IP包转发。 以下， 参照图 4并结合图 1对根据本发明第二方面的在接入网 的接入设备处用于对来自用户终端的 IP包进行控制的控制装置的各 个具体实施例进行详细描述， 其中， 对图 2、 图 3所作说明在此一并 作为参考。 图 4所示的控制装置 10位于以图 1所示 DSLAM2为例 的各个接入设备中， 其中， 包括： 接收装置 100、 第一判断装置 101、 发送装置 102。 具体地， 所述第一判断装置 101 包括： 第二判断装置 1010、第三判断装置 1011、第四判断装置 1012和第五判断装置 1013。
所述接收装置 100负责接收来自用户终端 b的 IP包；该 IP包可 能是组播 IP包， 也可能是单播 IP包。
接入设备的第一判断装置 101对所述 IP包进行检测， 判断该 IP 包是否为允许接入的组播 IP包。 如果 IP包为单播 IP包， 则允许接 入； 如果 IP包为组播 IP包， 则在满足以下两种情况的任一项或任多 项时， 允许其接入：
i )所述组播 IP包的目的组播地址属于预先设定的合法的组播地 址。 本例中， DSLAM2 中维护了一张组播访问控制列表， 如果该组 播 IP包的目的组播地址即为 MACL中预存的地址（如， 对应于该子 网内所有移动代理的统一的组播地址 （例如， 224.0.0.1 1 ) ) , 则当 默认该 DSLAM2被发往该组播地址的组播 IP包攻击的概率很低时， 可以允许所有发往该地址的组播. IP包接入。
ii ) 所述组播 IP包为预定类型的组播 IP包， 如， 以组播方式发 送的代理请求消息或注册请求消息等。 则当默认上述类型的消息均 发往对应该子网内所有移动代理的统一的组播地址 （例如， 224.0.0.11 ) 时， 可无需再针对组播地址进行筛选， 而仅在识别出该 IP包的类型后， 即对其进行组播或将其丟弃。
本领域技术人员可以 居本申请文件的教导不经创造性劳动地 知晓将 i)、 ii )联合用于组播 IP包接入控制的情形， 不再赘述。
根据本发明的一个优选实施例， 为了防止恶意用户利用组播消 息进行攻击， 第一判断装置 101优选地还包括以下 2个子装置：
第二判断装置 1010，用于当所接收的来自一个用户设备的 IP包 为预定类型的组播 IP包时， 判断由该用户设备在第一预定周期内所 发送的该预定类型的组播 I P包的次数是否超过第一预定数值。
第三判断装置 1011 , 用于当由该用户设备在第一预定周期内所 发送的该预定类型的组播 IP包的次数未超过第一预定数值时， 将该 IP包作为允许接入的组播 IP包。 所述周期可以长至无限长， 也可短 至一个时间单位 （小时 /分 /秒） 。
当所述控制装置 10 位于固定接入网中的接入设备 （如， DSLAM2 ) 中时， 所述第一判断装置 101优选地可包括以下子装置： 第四判断装置 1012,用于当由一个用户侧端口所接收的 IP包为 预定类型的组播 IP包时， 判断由该用户侧端口在第二预定周期内所 接收的该预定类型的组播 IP包的次数是否超过第二预定数值。
第五判断装置 1013当由该用户侧端口在第二预定周期内所接收 的该预定类型的组播 IP 包的次数未超过第二预定数值时， 将该 IP 包作为允许接入的組播 IP包。
DSLAM2 中的发送装置 102 负责将被允许接入的组播 IP 包和 单播 IP包分别进行发送。
以上对本发明的实施例进行了描述， 但是本发明并不局限于特 定的系统、 设备和具体协议， 本领域内技术人员可以在所附权利要 求的范围内做出各种变形或修改。

Claims

权 利 要 求 书
控制的方法， 包括：
a. 接收来自用户终端的 IP包；
b. 对所述 IP 包进行检测， 判断该 IP包是否为允许接入的组播 IP包；
c 将所述的允许接入的組播 IP包以组播方式进行发送。
2. 根据权利要求 1所述的方法， 其特征在于， 所述步骤 b包括： 当所述 IP 包为组播 IP 包， 且满足以下各项条件中的任一项或 任多项时， 则将该组播 IP包作为允许接入的组播 IP包：
- 所述组播 IP包的組播地址属于预先设定的合法的组播地址； - 所述组播 IP包为预定类型的组播 IP包。
3. 根据权利要求 2所述的方法， 其特征在于， 所述步骤 b之后 且在步骤 C之前还包括：
- 当所接收的来自一个用户设备的 IP包为预定类型的组播 IP包 时， 判断由该用户设备在第一预定周期内所发送的该预定类型的组 播 IP包的次数是否超过第一预定数值；
- 当由该用户设备在第一预定周期内所发送的该预定类型的组 播 IP包的次数未超过第一预定数值时，将该 IP包作为允许接入的组 播 IP包。
4. 根据权利要求 2或 3所述的方法， 其特征在于， 所述接入网 为固定接入网， 其中， 所述步骤 b之后且在步骤 c之前还包括：
- 当由一个用户侧端口所接收的 IP 包为预定类型的组播 IP 包 时， 判断由该用户侧端口在第二预定周期内所接收的该预定类型的 组播 IP包的次数是否超过第二预定数值；
- 当由该用户侧端口在第二预定周期内所接收的该预定类型的 组播 IP包的次数未超过第二预定数值时，将该 IP包作为允许接入的 组播 IP包。
5. 根据权利要求 1至 4中任一项所述的方法， 其特征在于， 所 述接入网为基于移动 IPv4协议的接入网， 其中， 所述预定类型的组 播 IP包包括组播 IP控制包。
6. 根据权利要求 5所述的方法， 其特征在于， 所述组播 IP控 制包包括移动 IP控制消息和 /或 ICMP路由器发现消息。
7. 根据权利要求 6所述的方法， 其特征在于， 所述移动 IP控 制消息包括注册请求消息， 所述 ICMP 路由器发现消息包括代理请 求消息。
8.一种在接入网的接入设备处用于对来自用户终端的 IP包进行 控制的控制装置， 包括：
接收装置， 用于接收来自用户终端的 IP包；
第一判断装置， 用于对所述 IP包进行检测， 判断该 IP包是否为 允许接入的组播 IP包；
发送装置， 用于将所述的允许接入的组播 IP包以组播方式进行 发送。
9. 根据权利要求 8所述的控制装置， 其特征在于， 所述第一判 断装置还用于， 当所述 IP包为组播 IP包， 满足以下各项条件中的任 一项或任多项时， 则将该组播 IP包作为允许接入的组播 IP包：
- 所述组播 IP包的组播地址属于预先设定的合法的组播地址；
- 所述組播 IP包为预定类型的组播 IP包。
10. 根据权利要求 9所述的控制装置， 其特征在于， 还包括： 第二判断装置， 用于当所接收的来自一个用户设备的 IP包为预 定类型的组播 IP包时， 判断由该用户设备在第一预定周期内所发送 的该预定类型的组播 IP包的次数是否超过第一预定数值；
第三判断装置， 用于当由该用户设备在第一预定周期内所发送 的该预定类型的组播 IP 包的次数未超过第一预定数值时， 将该 IP 包作为允许接入的组播 IP包。
1 1. 根据权利要求 9或 10所述的控制装置， 其特征在于， 所述 接入网为固定接入网， 其中， 还包括： 第四判断装置， 用于当由一个用户侧端口所接收的 IP包为预定 类型的组播 IP包时， 判断由该用户侧端口在第二预定周期内所接收 的该预定类型的组播 IP包的次数是否超过第二预定数值；
第五判断装置， 用于当由该用户侧端口在第二预定周期内所接 收的该预定类型的组播 IP包的次数未超过第二预定数值时， 将该 IP 包作为允许接入的组播 IP包。
12. 根据权利要求 8至 11中任一项所述的控制装置， 其特征在 于， 所述接入网为基于移动 IPv4协议的接入网， 其中， 所述预定类 型的组播 IP包包括组播 IP控制包。
13. 根据权利要求 12所述的控制装置， 其特征在于， 所述组播
IP控制包包括移动 IP控制消息和 /或 ICMP路由器发现消息。
14.根据权利要求 13 所述的控制装置， 其特征在于， 所述移动
IP控制消息包括注册请求消息， 所述 ICMP路由器发现消息包括代 理请求消息。
15. —种在接入网中的接入设备， 其特征在于， 包括根据权利 要求 8至 14中任一项所述的用于对来自用户终端的 IP包进行控制 的控制装置。
PCT/CN2008/001624 2007-09-26 2008-09-19 Procédé et appareil de commande de paquets ip multidiffusion dans un réseau d'accès Ceased WO2009046622A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020107008922A KR101503677B1 (ko) 2007-09-26 2008-09-19 액세스 네트워크에서 멀티캐스트 ｉｐ 패킷들을 제어하기 위한 방법 및 장치
US12/733,703 US8923181B2 (en) 2007-09-26 2008-09-19 Method and apparatus for controlling multicast IP packets in access network
EP08800617.6A EP2197161B1 (en) 2007-09-26 2008-09-19 Method and apparatus for controlling multicast ip packets in access network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710046438.3A CN101399717B (zh) 2007-09-26 2007-09-26 接入网中的组播ip包发送控制方法及装置
CN200710046438.3 2007-09-26

Publications (1)

Publication Number Publication Date
WO2009046622A1 true WO2009046622A1 (fr) 2009-04-16

Family

ID=40517991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/001624 Ceased WO2009046622A1 (fr) 2007-09-26 2008-09-19 Procédé et appareil de commande de paquets ip multidiffusion dans un réseau d'accès

Country Status (5)

Country Link
US (1) US8923181B2 (zh)
EP (1) EP2197161B1 (zh)
KR (1) KR101503677B1 (zh)
CN (1) CN101399717B (zh)
WO (1) WO2009046622A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118254A (zh) * 2010-01-05 2011-07-06 上海贝尔股份有限公司 一种上行组播控制方法及其装置

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5048105B2 (ja) * 2010-06-29 2012-10-17 レノボ・シンガポール・プライベート・リミテッド コンピュータへのアクセス方法およびコンピュータ
US9264370B1 (en) 2015-02-10 2016-02-16 Centripetal Networks, Inc. Correlating packets in communications networks
US10321395B2 (en) 2015-04-10 2019-06-11 Huawei Technologies Co., Ltd. Data packet processing method and related device
US9866576B2 (en) 2015-04-17 2018-01-09 Centripetal Networks, Inc. Rule-based network-threat detection
US10305879B2 (en) * 2017-04-29 2019-05-28 Cisco Technology, Inc. Restricting fake multicast service announcements
CN107181971A (zh) * 2017-05-22 2017-09-19 华为软件技术有限公司 一种iptv终端的升级方法及相关设备
CN106993279A (zh) * 2017-06-13 2017-07-28 深圳市伊特利网络科技有限公司 终端组播组的建立方法及系统
US11233777B2 (en) 2017-07-24 2022-01-25 Centripetal Networks, Inc. Efficient SSL/TLS proxy

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012394A1 (en) * 2002-07-31 2004-02-05 Ktfreetel Co., Ltd. Method and apparatus for receivability test and reachability test of explicit multicast
JP2004260317A (ja) * 2003-02-24 2004-09-16 Nippon Telegr & Teleph Corp <Ntt> ＭｏｂｉｌｅＩＰマルチキャスト方法、ホームエージェント、モビリティアンカーポイント、およびＭｏｂｉｌｅＩＰマルチキャストプログラム
CN1665219A (zh) * 2004-03-06 2005-09-07 鸿富锦精密工业（深圳）有限公司 组播流量控制管理系统及方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7079499B1 (en) 1999-09-08 2006-07-18 Nortel Networks Limited Internet protocol mobility architecture framework
US6988146B1 (en) * 2000-07-13 2006-01-17 Alcatel Simple multicast extension for mobile IP SMM
US7346053B1 (en) * 2002-05-07 2008-03-18 Cisco Technology, Inc. Methods and apparatus for supporting IP multicast for a mobile router
US7493652B2 (en) * 2003-08-06 2009-02-17 Microsoft Corporation Verifying location of a mobile node
KR100523490B1 (ko) * 2003-12-17 2005-10-24 한국전자통신연구원 이더넷 기반 수동형 광가입자망에서의 멀티캐스트 서비스지원 방법
FI20040444A0 (fi) * 2004-03-23 2004-03-23 Nokia Corp Verkkoliitäntäkokonaisuuden valitseminen viestintäjärjestelmässä
WO2006071055A1 (en) 2004-12-28 2006-07-06 Samsung Electronics Co., Ltd. A system and method for providing secure mobility and internet protocol security related services to a mobile node roaming in a foreign network
KR100636273B1 (ko) * 2005-01-11 2006-10-19 삼성전자주식회사 이더넷을 통한 ｍｐｌｓ 멀티캐스트 패킷 전송 장치 및 방법
KR101210340B1 (ko) 2005-10-13 2012-12-10 삼성전자주식회사 무선 통신 시스템에서 멀티캐스트/브로드캐스트를 지원하기위한 방법 및 장치
CN1960321B (zh) * 2005-10-31 2011-03-16 中兴通讯股份有限公司 一种实现组播安全的控制方法
EP1798900A1 (en) 2005-12-15 2007-06-20 Alcatel Lucent Access multiplexer
CN101414919B (zh) 2007-10-19 2012-11-28 上海贝尔阿尔卡特股份有限公司 上行组播业务的控制方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012394A1 (en) * 2002-07-31 2004-02-05 Ktfreetel Co., Ltd. Method and apparatus for receivability test and reachability test of explicit multicast
JP2004260317A (ja) * 2003-02-24 2004-09-16 Nippon Telegr & Teleph Corp <Ntt> ＭｏｂｉｌｅＩＰマルチキャスト方法、ホームエージェント、モビリティアンカーポイント、およびＭｏｂｉｌｅＩＰマルチキャストプログラム
CN1665219A (zh) * 2004-03-06 2005-09-07 鸿富锦精密工业（深圳）有限公司 组播流量控制管理系统及方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
C.PERKINS ET AL.: "RFC3220:IP Mobility Support for IPv4", January 2002 *
S. CHAKRABARTI ET AL.: "IPv4 Mobility extension for Multicast and Broadcast Packets", IPV4 MOBILITY EXTENSION FOR MULTICAST AND BROADCAST PACKETS, 8 July 2007 (2007-07-08), Retrieved from the Internet <URL:http://tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01> *
See also references of EP2197161A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118254A (zh) * 2010-01-05 2011-07-06 上海贝尔股份有限公司 一种上行组播控制方法及其装置

Also Published As

Publication number Publication date
KR101503677B1 (ko) 2015-03-24
CN101399717A (zh) 2009-04-01
KR20100087124A (ko) 2010-08-03
US8923181B2 (en) 2014-12-30
EP2197161A4 (en) 2012-04-25
CN101399717B (zh) 2014-03-12
EP2197161B1 (en) 2019-11-06
US20100290463A1 (en) 2010-11-18
EP2197161A1 (en) 2010-06-16

Similar Documents

Publication Publication Date Title
EP1927228B1 (en) Multiple interface mobile node with simultaneous home- and foreign network connection
US8488557B2 (en) Method for detecting a duplicate address, mobile station, network element and communication system
US7616615B2 (en) Packet forwarding apparatus for connecting mobile terminal to ISP network
EP2377363B1 (en) PROXY MOBILE IPv6 SUPPORT IN RESIDENTIAL NETWORKS
KR101503677B1 (ko) 액세스 네트워크에서 멀티캐스트 ｉｐ 패킷들을 제어하기 위한 방법 및 장치
CN101803329A (zh) 移动节点中实施的移动性功能的检测
US7269166B2 (en) Transmission of a binding update message indicating a care of address for delivering data packets to a mobile node via a unidirectional interface
JP2009521143A (ja) 通信ネットワークにおけるルート最適化のための方法および装置
US20090106831A1 (en) IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO
EP1988679B1 (en) A new flow based Layer 2 handover mechanism for mobile node with multi network interfaces
WO2006132723A1 (en) System and method for reducing unnecessary traffic in a network
CN1998193B (zh) 移动终端管理设备和归属代理切换方法
WO2007112806A1 (en) Efficient handover of a mobile node within a network with multiple anchor points
Kuntz et al. Multiple mobile routers in nemo: How neighbor discovery can assist default router selection
JP4823053B2 (ja) 異種通信インタフェース間の切替方法、移動端末および管理装置
Bernardos et al. RFC 8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management
Dhraief et al. The impact of mobile ipv6 on transport protocols an experimental investigation
Li et al. Improvement of the mobile e-health wireless networks based on the IPv6 protocol
Baumann et al. A macro mobility and multihoming notification protocol for wireless mesh networks implementing mobile IP and SHIM6
El Malki RFC 4881: Low-Latency Handoffs in Mobile IPv4
Lemon et al. MIF WG H. Deng Internet-Draft China Mobile Intended status: Informational S. Krishnan Expires: January 2, 2015 Ericsson
Chauhan Mobility Management For Wireless Systems: Challenges and Future of Mobile IP

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08800617

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008800617

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2281/CHENP/2010

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 20107008922

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 12733703

Country of ref document: US